هاردنینگ پایگاه داده: امن‌سازی SQL Server، Oracle و MySQL

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

پایگاه داده همان جایی است که داده‌ی ارزشمند واقعاً در آن قرار دارد: اطلاعات مشتریان، داده‌های پرداخت و اعتبارنامه‌ها. بسیاری از رخدادهای امنیتی به اکسپلویت پیچیده‌ای نیاز ندارند؛ کافی است پورت دیتابیس از شبکه‌ی اشتباه در دسترس باشد، برنامه با sa یا root وصل شود یا قابلیتی فراموش‌شده مثل xp_cmdshell یک تزریق SQL ساده را به تسخیر کامل سرور تبدیل کند. اصول امن‌سازی SQL Server، Oracle، MySQL و PostgreSQL یکسان است و فقط نام تنظیمات فرق می‌کند.

اصول هاردنینگ پایگاه داده در همه‌ی موتورها

جدول زیر کنترل‌های اصلی را برای هر موتور نشان می‌دهد. این جدول نقطه‌ی شروع است و CIS Benchmark برای هر چهار موتور بررسی‌های دقیق و وابسته به نسخه ارائه می‌کند.

کنترل	SQL Server	Oracle	MySQL	PostgreSQL
حساب مدیریتی داخلی	sa	SYS و SYSTEM	root	postgres
احراز هویت پیشنهادی	Windows Authentication	Profile و Verifier قوی رمز	caching_sha2_password	scram-sha-256
رمزنگاری در حالت سکون	TDE	TDE (گزینه‌ی Advanced Security)	رمزنگاری داده‌ی InnoDB	رمزنگاری دیسک یا فایل‌سیستم
ممیزی داخلی	SQL Server Audit	Unified Auditing	افزونه‌های Audit یا Enterprise Audit	افزونه‌ی pgaudit و لاگ

حساب‌ها، احراز هویت و حداقل دسترسی

حساب‌های پیش‌فرض و نمونه

هر حسابی را که استفاده نمی‌شود غیرفعال یا قفل کنید. در SQL Server لاگین sa را غیرفعال کنید و به‌جای آن از حساب‌های مدیریتی با نام مشخص استفاده کنید. در Oracle با پرس‌وجو از نمای DBA_USERS_WITH_DEFPWD حساب‌هایی را که هنوز رمز پیش‌فرض دارند پیدا کنید و اسکیماهای نمونه مانند SCOTT را قفل کنید. در MySQL ابزار mysql_secure_installation کاربران ناشناس و پایگاه داده‌ی test را حذف و ورود root از راه دور را غیرفعال می‌کند.

روش احراز هویت

تا جای ممکن از احراز هویت یکپارچه استفاده کنید: SQL Server در حالت Windows Authentication و لاگین SQL فقط وقتی برنامه واقعاً به آن نیاز دارد. در PostgreSQL روش scram-sha-256 را به کار ببرید و هرگز برای اتصال شبکه‌ای در pg_hba.conf از trust استفاده نکنید. در MySQL 8 افزونه‌ی پیش‌فرض caching_sha2_password را نگه دارید. برای هر لاگین داخلی باقی‌مانده، سیاست رمز و قفل حساب را اعمال کنید.

اصل حداقل دسترسی (Least Privilege)

• هر برنامه لاگین مخصوص خودش را داشته باشد و فقط روی اسکیمای خودش مجوز بگیرد.
• هیچ برنامه‌ای با sa، root، postgres، SYS یا کاربری با نقش DBA وصل نشود.
• مجوزها را به نقش‌ها (Role) بدهید نه به کاربران، و عضویت نقش‌ها را مرتب بازبینی کنید.
• مجوزهای غیرضروری PUBLIC را حذف کنید و کاربر guest را در پایگاه‌های داده‌ی کاربری SQL Server غیرفعال کنید.
• وظایف DBA را از وظایف ممیزی جدا کنید تا مدیر نتواند ردپای خودش را پاک کند.

رمزنگاری در حال انتقال و در حالت سکون

همه‌ی اتصال‌های کلاینت را با TLS رمزنگاری کنید و گواهی سرور را در سمت کلاینت اعتبارسنجی کنید. تنظیمات کلیدی عبارت‌اند از Force Encryption در SQL Server، require_secure_transport = ON در MySQL، ssl = on همراه با ورودی‌های hostssl در PostgreSQL و رمزنگاری شبکه‌ی Oracle در فایل sqlnet.ora.

برای داده در حالت سکون، Transparent Data Encryption یا TDE فایل‌های داده و لاگ را رمزنگاری می‌کند تا دیسک یا فایل بکاپ سرقت‌شده بدون کلید بی‌ارزش باشد. نمونه در SQL Server:

USE master;
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<strong-password>';
CREATE CERTIFICATE TDE_Cert WITH SUBJECT = 'TDE certificate';
BACKUP CERTIFICATE TDE_Cert TO FILE = 'D:\Keys\TDE_Cert.cer'
  WITH PRIVATE KEY (FILE = 'D:\Keys\TDE_Cert.pvk',
  ENCRYPTION BY PASSWORD = '<another-strong-password>');
USE SalesDB;
CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256
  ENCRYPTION BY SERVER CERTIFICATE TDE_Cert;
ALTER DATABASE SalesDB SET ENCRYPTION ON;

از گواهی و کلید خصوصی در مکانی جدا و محافظت‌شده بکاپ بگیرید؛ بدون آن‌ها بازیابی پایگاه داده‌ی رمزنگاری‌شده ممکن نیست. نسخه‌ی Community پایگاه داده‌ی PostgreSQL قابلیت TDE داخلی ندارد و باید از رمزنگاری کامل دیسک یا فایل‌سیستم استفاده کرد.

غیرفعال کردن قابلیت‌های پرخطر

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

EXEC sp_configure 'show advanced options', 1; RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 0;
EXEC sp_configure 'Ole Automation Procedures', 0;
EXEC sp_configure 'Ad Hoc Distributed Queries', 0;
RECONFIGURE;
EXEC sp_configure 'show advanced options', 0; RECONFIGURE;

• SQL Server: یکپارچگی CLR، گزینه‌ی cross db ownership chaining، ویژگی TRUSTWORTHY روی پایگاه‌های داده‌ی کاربری و Linked Serverهایی که به لاگین پرمجوز نگاشت شده‌اند را هم بازبینی کنید.
• Oracle: پس از بررسی وابستگی برنامه‌ها، مجوز EXECUTE روی پکیج‌هایی مانند UTL_FILE، UTL_TCP، UTL_HTTP و UTL_SMTP را از PUBLIC بگیرید.
• MySQL: مقدار local_infile = OFF را تنظیم کنید، secure_file_priv را به یک پوشه‌ی اختصاصی محدود کنید و مجوزهای FILE و SUPER را به کسی ندهید.
• PostgreSQL: تعداد حساب‌های Superuser را محدود کنید، از زبان‌های Untrusted مانند plpython3u پرهیز کنید و مراقب دارندگان نقش pg_execute_server_program باشید که اجرای COPY ... PROGRAM را ممکن می‌کند.

دسترسی شبکه، وصله و ممیزی

محدودسازی دسترسی شبکه

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

# MySQL (my.cnf)
[mysqld]
bind-address = 10.20.0.15
require_secure_transport = ON
local_infile = OFF

# PostgreSQL pg_hba.conf
hostssl  appdb  appuser  10.20.0.0/24  scram-sha-256
host     all    all      0.0.0.0/0     reject

اگر Named Instanceها به سرویس SQL Server Browser نیاز ندارند آن را غیرفعال کنید و دسترسی به Listener در Oracle را با Valid Node Checking محدود کنید.

وصله‌ی امنیتی (Patch)

Cumulative Updateهای SQL Server، Critical Patch Updateهای فصلی Oracle و نسخه‌های Minor در MySQL و PostgreSQL را از طریق یک فرایند آزموده‌ی مدیریت وصله نصب کنید. نسخه‌هایی که پشتیبانی‌شان تمام شده باید با برنامه‌ی مشخص از محیط عملیاتی خارج شوند.

ممیزی (Auditing)

ورودهای موفق و ناموفق، تغییر مجوزها و نقش‌ها، تغییرات اسکیما، استفاده از حساب‌های مدیریتی و دسترسی به جداول حساس را ممیزی کنید. رکوردهای ممیزی را به SIEM بفرستید؛ لاگی که فقط روی خود سرور دیتابیس ذخیره شود، به دست کسی که سرور را تسخیر کرده قابل تغییر است. چارچوب‌هایی مانند PCI DSS 4.0 چنین لاگ‌برداری را برای داده‌ی کارت پرداخت صراحتاً انتظار دارند.

امنیت بکاپ پایگاه داده

بکاپ یک نسخه‌ی کامل از داده‌های شماست و به همان اندازه‌ی خود دیتابیس محافظت لازم دارد:

1. فایل‌های بکاپ را رمزنگاری کنید و کلیدها را جداگانه نگه دارید.
2. دسترسی به پوشه‌ها و حساب‌های بکاپ را محدود کنید.
3. دست‌کم یک نسخه‌ی آفلاین یا تغییرناپذیر (Immutable) برای مقاومت در برابر باج‌افزار نگه دارید.
4. بازیابی را طبق برنامه آزمایش کنید، از جمله برای پایگاه‌های داده‌ی رمزنگاری‌شده با TDE.
5. مراحل بازیابی و زمان مورد انتظار آن را مستند کنید.

نت‌گارد چگونه به هاردنینگ پایگاه داده کمک می‌کند

نت‌گارد با اسکن آسیب‌پذیری احراز هویت‌شده‌ی سرورهای پایگاه داده، وصله‌های نصب‌نشده و نسخه‌های بدون پشتیبانی را پیدا می‌کند و پیکربندی آن‌ها را با CIS Benchmark و خط مبنای اختصاصی سازمان مقایسه می‌کند؛ از جمله قابلیت‌های پرخطر فعال، روش احراز هویت و رمزنگاری. تشخیص انحراف پیکربندی تغییراتی را که پیکربندی امن را تضعیف می‌کنند نشان می‌دهد، یافته‌ها بر اساس اطلاعات اکسپلویت و اهمیت دارایی اولویت‌بندی می‌شوند و نتایج قابل نگاشت به ISO 27001، PCI DSS و NIST هستند. گزارش‌ها به فارسی و انگلیسی ارائه می‌شوند. برای برنامه‌ریزی ارزیابی با ما تماس بگیرید.

سوالات متداول

هاردنینگ پایگاه داده چیست؟

هاردنینگ پایگاه داده فرایند کاهش سطح حمله‌ی سرور دیتابیس است؛ شامل حذف یا قفل حساب‌های پیش‌فرض، اعمال حداقل دسترسی و احراز هویت قوی، رمزنگاری داده در حال انتقال و در حالت سکون، غیرفعال کردن قابلیت‌های پرخطر، محدودسازی دسترسی شبکه، ممیزی اقدامات حساس، نصب منظم وصله‌ها و محافظت از بکاپ. این اصول برای SQL Server، Oracle، MySQL، PostgreSQL و دیگر موتورها کاربرد دارند.

چطور SQL Server را امن کنیم؟

از حالت Windows Authentication استفاده کنید، لاگین sa را غیرفعال کنید و برای هر برنامه یک لاگین با حداقل دسترسی بسازید. قابلیت‌های xp_cmdshell، Ole Automation Procedures و Ad Hoc Distributed Queries را خاموش کنید، اتصال رمزنگاری‌شده را اجباری کنید، برای پایگاه‌های داده‌ی حساس TDE را فعال کنید و SQL Server Audit را پیکربندی کنید. نسخه را پشتیبانی‌شده و به‌روز نگه دارید و آن را با CIS Benchmark ممیزی کنید.

آیا TDE برای محافظت از پایگاه داده کافی است؟

خیر. TDE از فایل‌های داده، لاگ و بکاپ در برابر کپی یا سرقت محافظت می‌کند، اما جلوی مهاجمی را که با اعتبارنامه‌ی معتبر وصل می‌شود یا از تزریق SQL سوءاستفاده می‌کند نمی‌گیرد، چون موتور دیتابیس داده را برای پرس‌وجوهای مجاز رمزگشایی می‌کند. TDE باید همراه با حداقل دسترسی، احراز هویت قوی، TLS، ممیزی و کد امن برنامه به کار رود.

چرا xp_cmdshell خطرناک است؟

xp_cmdshell به SQL Server اجازه می‌دهد دستورهای سیستم‌عامل را با مجوزهای حساب سرویس SQL Server اجرا کند. اگر مهاجم به تزریق SQL یا یک لاگین پرمجوز دست پیدا کند، فعال بودن xp_cmdshell دسترسی به دیتابیس را به کنترل کامل سرور تبدیل می‌کند. این قابلیت به‌طور پیش‌فرض غیرفعال است و جز در صورت نیاز مستند کسب‌وکار باید غیرفعال بماند.

چطور اتصال‌های PostgreSQL را امن کنیم؟

مقدار listen_addresses را روی اینترفیس داخلی بگذارید، ssl را فعال کنید و در pg_hba.conf از ورودی‌های hostssl با روش scram-sha-256 استفاده کنید. برای اتصال شبکه‌ای هرگز روش trust را به کار نبرید، فایل را با یک قانون reject تمام کنید و پورت دیتابیس را با فایروال محدود کنید تا فقط میزبان‌های برنامه و مدیریت بتوانند وصل شوند.