8 نکته سخت‌سازی امنیتی PostgreSQL برای پایگاه‌های داده تولید

PostgreSQL از بسیاری جهات به طور پیش فرض ایمن است، اما “ایمن به طور پیش فرض” به معنای “ایمن بودن کافی برای تولید” نیست. بیشتر نقض‌ها به این دلیل اتفاق می‌افتند که PostgreSQL دارای آسیب‌پذیری نیست، بلکه به دلیل پیکربندی نادرست است: دسترسی بیش از حد مجاز، احراز هویت ضعیف، اتصالات رمزگذاری نشده یا حساب‌هایی با امتیازات بیشتر از آنچه نیاز دارند.

این لیستی از موارد عملی است که باید قبل از اینکه پایگاه داده شما ترافیک واقعی را کنترل کند، بررسی و اصلاح کنید. بعضی از اینها پنج دقیقه طول می کشد. برخی دیگر نیاز به برنامه ریزی بیشتری دارند. همه آنها اهمیت دارند.

1. به احراز هویت SCRAM-SHA-256 بروید

روش احراز هویت پیش فرض در تنظیمات قدیمی PostgreSQL MD5 است. سال‌هاست که ضعیف در نظر گرفته می‌شود و اگر کسی ترافیک احراز هویت را بگیرد، تقریباً هیچ محافظت واقعی ارائه نمی‌کند. SCRAM-SHA-256 جایگزینی مدرن است – از مکانیزم مناسبی برای پاسخگویی به چالش استفاده می کند که هرگز رمز عبور واقعی را از طریق سیم ارسال نمی کند.

آنچه را که در حال حاضر استفاده می کنید بررسی کنید:

SHOW password_encryption;

اگر برگردد md5، آن را تغییر دهید postgresql.conf:

password_encryption = scram-sha-256

سپس آپدیت کنید pg_hba.conf برای نیاز به SCRAM:

host  all  all  0.0.0.0/0  scram-sha-256

رمزهای عبور موجود به صورت هش MD5 باقی می مانند تا زمانی که کاربران آنها را تغییر دهند. برای اجرای واقعی SCRAM باید گذرواژه‌های همه حساب‌ها را بازنشانی کنید. ابتدا این کار را برای کاربر برنامه انجام دهید، سپس بقیه کار را انجام دهید.

2. pg_hba.conf را با دقت پیکربندی کنید

pg_hba.conf فایلی است که کنترل می کند چه کسی می تواند از کجا و چگونه به پایگاه داده شما متصل شود. این یکی از مهم ترین کنترل های امنیتی در PostgreSQL و همچنین یکی از رایج ترین مواردی است که به اشتباه پیکربندی می شود.

روش های احراز هویت موجود عبارتند از:

را trust روش خطرناک ترین است این بدان معناست که هر کسی که می تواند به سوکت یا پورت دسترسی پیدا کند، وارد است. اغلب برای اتصالات محلی مانند زیر روشن می ماند:

local  all  all  trust

این برای یک لپ تاپ توسعه دهنده خوب است. در سروری که چندین کاربر یا پردازش از یک سیستم عامل مشترک استفاده می کنند، یک مشکل جدی است. آن را جایگزین کنید peer برای سوکت های یونیکس یا scram-sha-256 برای اتصالات TCP

با محدوده IP خاص باشید. فقط به هاست هایی که واقعاً نیاز به دسترسی دارند اجازه دهید:

host  mydb  myapp  10.0.1.50/32  scram-sha-256

3. از SSL برای همه اتصالات راه دور استفاده کنید

PostgreSQL به صورت بومی از SSL پشتیبانی می کند. بدون آن، اعتبارنامه ها و نتایج پرس و جو به صورت متن ساده در شبکه حرکت می کنند. در یک شبکه خصوصی که ممکن است کم خطر به نظر برسد، اما تقریباً هیچ ارزشی برای فعال کردن SSL ندارد، بنابراین دلیلی برای نادیده گرفتن آن وجود ندارد.

اینها را تنظیم کنید postgresql.conf:

ssl = on
ssl_cert_file="server.crt"
ssl_key_file="server.key"

سپس SSL را در آن اجرا کنید pg_hba.conf با استفاده از hostssl به جای host:

hostssl  all  all  0.0.0.0/0  scram-sha-256

را hostssl رکورد فقط با اتصالات SSL مطابقت دارد. هر گونه تلاش برای اتصال بدون SSL رد می شود. شما همچنین می توانید تنظیم کنید ssl_min_protocol_version = 'TLSv1.2' برای مسدود کردن نسخه های قدیمی تر TLS.

اگر از یک سرویس PostgreSQL مدیریت شده استفاده می کنید، SSL معمولاً از قبل فعال است. اما بررسی کنید که آیا اجرا شده است – برخی از ارائه دهندگان اتصالات غیر SSL را اجازه می دهند مگر اینکه شما صریحاً به آنها نیاز داشته باشید.

4. از اصل کمترین امتیاز پیروی کنید

اکثر برنامه ها با مجوزهای بسیار بیشتر از آنچه واقعاً نیاز دارند به PostgreSQL متصل می شوند. یک برنامه گزارش‌دهی خواندنی که به‌عنوان یک ابرکاربر متصل می‌شود، یا یک API که با نقشی مرتبط می‌شود که می‌تواند DROP TABLE – اینها حوادثی هستند که در انتظار وقوع هستند.

نقش های اختصاصی را فقط با آنچه لازم است ایجاد کنید:

-- Read-only role
CREATE ROLE app_readonly;
GRANT CONNECT ON DATABASE mydb TO app_readonly;
GRANT USAGE ON SCHEMA public TO app_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO app_readonly;

-- Read-write role
CREATE ROLE app_readwrite;
GRANT CONNECT ON DATABASE mydb TO app_readwrite;
GRANT USAGE ON SCHEMA public TO app_readwrite;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO app_readwrite;
GRANT USAGE ON ALL SEQUENCES IN SCHEMA public TO app_readwrite;

چند نکته که باید به آن توجه کرد:

• هرگز اجازه ندهید برنامه شما به عنوان متصل شود postgres یا هر ابرکاربری
• اعطا نکن SUPERUSER به نقش هایی که نیازی به آن ندارند
• استفاده کنید REVOKE برای حذف پیش فرض PUBLIC مجوزهای طرحواره اگر می خواهید انزوای سخت تری داشته باشید
• نقش‌های جداگانه برای هر میکروسرویس را در نظر بگیرید، نه یک نقش مشترک برای همه چیز

جدول زیر اشتباهات رایج امتیازات و جایگزین های امن تر را نشان می دهد:

حداقل امتیاز از همه حملات جلوگیری نمی کند، اما شعاع انفجار را در زمانی که مشکلی پیش می آید محدود می کند.

5. دسترسی در سطح شبکه را محدود کنید

PostgreSQL به طور پیش فرض گوش می دهد localhost فقط این خوب است. اما معمول است که آن را برای پذیرش اتصالات خارجی با تنظیم باز کنید listen_addresses="*"، و سپس آن را فراموش کنید.

به دقت در مورد آنچه واقعاً به دسترسی به شبکه نیاز دارد فکر کنید:

• اگر برنامه و پایگاه داده شما روی یک سرور هستند، فقط از سوکت های یونیکس استفاده کنید
• اگر آنها در میزبان جداگانه هستند، محدود کنید listen_addresses به رابط شبکه خاص و استفاده از قوانین فایروال برای محدود کردن IP هایی که می توانند به پورت 5432 برسند
• هرگز PostgreSQL را مستقیماً در معرض اینترنت عمومی قرار ندهید

حتی در شبکه های خصوصی، یک قانون فایروال در سطح سیستم عامل یا گروه امنیت ابری یک لایه مفید اضافه می کند. چیزی شبیه به:

# Allow only the app server
iptables -A INPUT -p tcp --dport 5432 -s 10.0.1.50 -j ACCEPT
iptables -A INPUT -p tcp --dport 5432 -j DROP

اسکن پورت بی اهمیت است. اگر پورت پایگاه داده شما برای اینترنت قابل مشاهده باشد، شما تحت بررسی قرار خواهید گرفت. حتی اگر احراز هویت کامل باشد، دلیلی برای تبلیغ وجود پایگاه داده وجود ندارد.

6. ثبت حسابرسی را با pgAudit فعال و نظارت کنید

گزارش پیش‌فرض PostgreSQL می‌تواند به شما بگوید که یک کوئری اجرا شده و چقدر طول کشیده است. به شما نمی گوید چه کسی چه داده هایی را تغییر داده است، این همان چیزی است که برای ممیزی های امنیتی و انطباق نیاز دارید.

pgAudit افزونه ای است که گزارش حسابرسی دقیق را اضافه می کند. به مجری PostgreSQL متصل می شود و فعالیت در سطح جلسه یا سطح شی را ثبت می کند. برای نصب آن:

CREATE EXTENSION pgaudit;

سپس آن را در پیکربندی کنید postgresql.conf:

pgaudit.log = 'write, ddl, role'

دسته بندی های ورود به سیستم عبارتند از:

• read – انتخاب و کپی از
• write – درج، به روز رسانی، حذف، کوتاه کردن، کپی کردن در
• function – فراخوانی تابع
• role – اعطا، لغو، ایجاد / رها کردن / تغییر نقش
• ddl – ایجاد، رها کردن، تغییر (هر چیزی که طرحواره را تغییر دهد)
• misc – دور انداختن، واکشی، نقطه بازرسی و غیره

برای اکثر پایگاه های داده تولید، ورود به سیستم write، ddl و role نقطه شروع معقولی است. این تغییرات داده ها و اصلاحات طرحواره را بدون سیل کردن گزارش های شما با نویز SELECT ضبط می کند.

بدون نوعی ثبت حسابرسی، اغلب نمی توانید به سؤالات اساسی پس از یک حادثه پاسخ دهید: چه چیزی حذف شده است، چه زمانی و توسط کدام حساب. این هم برای اشکال زدایی و هم برای الزامات قانونی مهم است.

7. PostgreSQL را وصله نگه دارید

PostgreSQL نسخه های پچ را به طور منظم منتشر می کند. این‌ها نسخه‌های ویژگی نیستند – آنها باگ‌هایی از جمله آسیب‌پذیری‌های امنیتی را برطرف می‌کنند. اجرای یک نسخه بدون پچ یکی از رایج ترین و قابل اجتناب ترین خطرات است.

شماره گذاری نسخه ساده است: 16.2 به معنای نسخه اصلی 16، انتشار وصله 2 است. وصله های موجود در همان نسخه اصلی فقط با راه اندازی مجدد سرویس قابل اعمال هستند. بدون تخلیه و بازیابی مورد نیاز است.

پروژه PostgreSQL هر نسخه اصلی را به مدت 5 سال نگهداری می کند. پس از آن، دیگر پچ نیست. اگر از PostgreSQL 11 یا 12 استفاده می کنید، در حال حاضر پشتیبانی را پشت سر گذاشته اید یا به پایان آن نزدیک شده اید. برای مهاجرت برنامه ریزی کنید

نسخه فعلی خود را بررسی کنید:

SELECT version();

آن را با آخرین پچ های منتشر شده در postgresql.org/support/versioning مقایسه کنید. اگر بیش از یک پچ عقب هستید، یک به روز رسانی را برنامه ریزی کنید.

8. از نسخه های پشتیبان و تست بازیابی محافظت کنید

یک پایگاه داده با کنترل های دسترسی عالی اما پشتیبان های رمزگذاری نشده و محافظت نشده به مهاجمان هدف آسان تری می دهد. پشتیبان‌گیری‌ها اغلب به ذخیره‌سازی شی، دیسک‌های محلی یا مسیرهای شبکه مشترک با دسترسی مجازتر از خود پایگاه داده ختم می‌شوند.

چند نکته برای بررسی:

• آیا فایل های پشتیبان رمزگذاری شده اند؟ اگر نه، هر کسی که به فضای ذخیره‌سازی دسترسی دارد می‌تواند داده‌های شما را بخواند
• چه کسی به سطل ذخیره یا دایرکتوری دسترسی دارد؟
• آیا اصلا بک آپ گرفته می شود؟ و اخیرا؟
• آیا واقعاً یک بازیابی را آزمایش کرده اید؟

مورد آخر دست کم گرفته شده است. پشتیبان‌گیری‌هایی که هرگز آزمایش نکرده‌اید، فقط فایل‌هایی هستند که ممکن است کار کنند. یک ابزار پشتیبان‌گیری PostgreSQL مانند Databasus این کار را سرتاسر انجام می‌دهد – این استاندارد صنعتی برای پشتیبان‌گیری خودکار PostgreSQL است که هم توسط توسعه‌دهندگان فردی و هم تیم‌های سازمانی استفاده می‌شود. از رمزگذاری، پشتیبان‌گیری برنامه‌ریزی‌شده در S3، Google Drive، FTP و سایر حافظه‌ها، سیاست‌های حفظ و اعلان‌های خرابی پشتیبانی می‌کند، بنابراین به اسکریپت‌هایی که نوشته‌اید و فراموش کرده‌اید تکیه نمی‌کنید.

حتی بدون ابزار اختصاصی، بازیابی تست را به یک عادت معمولی تبدیل کنید. یک نسخه پشتیبان انتخاب کنید، آن را به یک محیط مرحله‌بندی بازیابی کنید، داده‌ها را تأیید کنید. حداقل هر سه ماه یکبار این کار را انجام دهید.

کنار هم گذاشتن

سخت شدن امنیتی چک لیست یک بار مصرف نیست. تغییر پیکربندی، اتصال سرویس‌های جدید به پایگاه داده، به‌روزرسانی‌های وابستگی – همه چیز تغییر می‌کند. یک یادآوری تنظیم کنید تا تنظیمات خود را به صورت دوره ای مرور کنید.

بزرگترین پیروزی ها از اصول اولیه حاصل می شود: احراز هویت قوی، امتیازات مناسب، SSL و محدودیت های شبکه. این موارد را درست انجام دهید و به بیشتر سطح حمله در دنیای واقعی پرداخته اید. بقیه – ثبت حسابرسی، وصله، بهداشت پشتیبان – در بالای آن پایه قرار می گیرند.

با آنچه امروز می توانید اصلاح کنید شروع کنید. اکثر اینها نیازی به خرابی ندارند.