آسیب‌پذیری PostgreSQL؛ اصلاح ۵۲ مورد و پایان عمر نسخه ۱۴

این فناوری چیست؟

PostgreSQL یک سامانه مدیریت پایگاه‌داده رابطه‌ای متن‌باز است که برای نگهداری داده‌های برنامه‌ها، سرویس‌های سازمانی و زیرساخت‌های تحلیلی استفاده می‌شود. امنیت PostgreSQL فقط به رمز عبور محدود نیست؛ هسته، افزونه‌ها، ابزارهای پشتیبان‌گیری و دسترسی‌های فایل هم در سطح ریسک نقش دارند.

PostgreSQL یک سامانه مدیریت پایگاه‌داده رابطه‌ای متن‌باز است که داده‌های برنامه‌ها و سرویس‌های سازمانی را نگهداری می‌کند؛ امنیت آن به هسته، افزونه‌ها و ابزارهای جانبی هم وابسته است.

گروه توسعه جهانی PostgreSQL در ۱۲ نوامبر ۲۰۲۶ به‌روزرسانی‌های ۱۸.۷، ۱۷.۱۲، ۱۶.۱۶، ۱۵.۲۰ و ۱۴.۲۵ را منتشر کرد. طبق اطلاعیه رسمی، این انتشار ۵۲ آسیب‌پذیری امنیتی و بیش از ۱۴۰ باگ را اصلاح می‌کند. هم‌زمان PostgreSQL ۱۹ RC2 نیز منتشر شده، اما نسخه کاندیدای انتشار را نباید بدون آزمون سازگاری جایگزین نسخه تولید کرد.

برای تیم‌هایی که مسئول چند سرور هستند، این خبر فقط به معنای نصب یک بسته نیست. باید مشخص شود کدام نمونه‌ها مستقیماً از اینترنت قابل دسترسی‌اند، کدام برنامه‌ها به افزونه‌های حساس وابسته‌اند و کدام image یا محصول داخلی نسخه‌ای bundle‌شده از PostgreSQL دارد. ثبت این inventory، اولویت‌بندی آسیب‌پذیری و زمان‌بندی maintenance را دقیق‌تر می‌کند. برای مرور مطالب فنی مرتبط، مقالات فنی تکتاز نیز در دسترس است.

مهم‌ترین ریسک‌های این انتشار

در فهرست اصلاحات، چند نقص با پیامد جدی دیده می‌شود. برخی خطاهای type confusion و use-after-free در شرایط خاص می‌توانند به اجرای کد دلخواه منجر شوند. این آسیب‌پذیری‌ها به نسخه، افزونه و نقش کاربر وابسته‌اند و باید در inventory امنیتی جداگانه ثبت شوند. آسیب‌پذیری‌های دیگری به اجرای SQL ناخواسته، نوشتن فایل از مسیر dblink یا subscription، افشای حافظه، دورزدن کنترل‌های row-level security و تزریق SQL در ابزارهای مدیریتی مربوط‌اند.

شدت هر مورد به نسخه، افزونه فعال، نقش کاربر و تنظیمات سامانه وابسته است؛ بنابراین نباید همه نصب‌ها را به یک شکل ارزیابی کرد. برای هر آسیب‌پذیری، وجود پیش‌شرط‌ها را در محیط خود بررسی کنید. بااین‌حال، اجرای پایگاه‌داده در محیط در معرض شبکه یا استفاده از ابزارهایی مانند pg_restore، pg_dump، pg_basebackup، dblink و logical replication، بررسی این به‌روزرسانی را در اولویت قرار می‌دهد.

PostgreSQL ۱۴ به پایان عمر رسید

نسخه ۱۴ آخرین انتشار خود را دریافت کرده و دیگر وصله امنیتی یا رفع باگ رسمی نخواهد داشت. اگر سرویس شما روی PostgreSQL ۱۴ است، ارتقا به یک شاخه پشتیبانی‌شده را به پروژه‌ای زمان‌دار تبدیل کنید. ارتقای minor release با ارتقای major release یکسان نیست؛ برای رفتن به شاخه جدید باید مسیر سازگار با معماری، افزونه‌ها و حجم داده انتخاب شود و معمولاً pg_upgrade یا dump/restore در برنامه قرار می‌گیرد.

چک‌لیست ارتقای امن

ابتدا نسخه واقعی همه نمونه‌ها، replicaها، محیط‌های staging و PostgreSQLهای bundle‌شده در محصولات داخلی را فهرست کنید. سپس release notes نسخه موردنظر و فهرست افزونه‌ها را بخوانید و از backup قابل بازیابی، نه فقط backup موفق، اطمینان بگیرید. در محیط staging، restore واقعی، migrationها، queryهای پرتکرار، اتصال برنامه و jobهای پشتیبان‌گیری را آزمایش کنید.

برای releaseهای پشتیبانی‌شده، به‌روزرسانی minor معمولاً به dump و reload یا pg_upgrade نیاز ندارد، اما توقف کنترل‌شده سرویس و جایگزینی باینری‌ها باید طبق روش توزیع و معماری انجام شود. پس از ارتقا، سلامت replicaها، لاگ خطا، نقش‌ها، افزونه‌ها و ابزارهای جانبی را بررسی کنید.

برخی اصلاحات نیازمند اقدام تکمیلی هستند: در صورت اثرپذیری از مشکلات index، reindex را طبق release notes بررسی کنید؛ اگر از pg_trgm یا GIN استفاده می‌کنید، شاخص‌های مرتبط را ارزیابی کنید؛ برای محیط‌هایی که incremental backup دارند، یک full backup تازه بسازید و بازیابی آن را تست کنید. این کارها را بدون بررسی اثر روی production و بدون برنامه rollback اجرا نکنید.

جمع‌بندی

این انتشار فقط یک به‌روزرسانی عادی نیست؛ هم‌زمان ۵۲ نقص امنیتی، بیش از ۱۴۰ باگ و پایان عمر PostgreSQL ۱۴ را پوشش می‌دهد. اولویت عملی، ارتقای کنترل‌شده شاخه‌های پشتیبانی‌شده، آزمایش restore و سازگاری، بررسی ابزارهای bundle‌شده و برنامه‌ریزی خروج از نسخه ۱۴ است. هر آسیب‌پذیری را بر اساس نسخه و قابلیت فعال ارزیابی کنید و قبل از تغییر production، مسیر بازگشت را مستند کنید. منبع اصلی برای جزئیات هر CVE و اقدام پس از به‌روزرسانی، اطلاعیه رسمی PostgreSQL و release notes همان نسخه است.

منبع خارجی: اطلاعیه رسمی PostgreSQL