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

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

برای مدیران پایگاه داده (DBAs) و مهندسان DevOps، استراتژی سنتی پشتیبان‌گیری ۳-۲-۱ دیگر کافی نیست. برای تضمین بقای داده‌ها، تیم‌های زیرساختی باید قانون ۳-۲-۱-۱ را اتخاذ کنند، که در آن «۱» نهایی نشان‌دهنده ذخیره‌سازی تغییرناپذیر (Immutable Storage) است.

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

مکانیسم‌های ذخیره‌سازی تغییرناپذیر

ذخیره‌سازی تغییرناپذیر بر معماری «یک‌بار نوشتن، چندین‌بار خواندن» (WORM) متکی است. هنگامی که داده‌ها در یک مقصد تغییرناپذیر نوشته می‌شوند، تا زمانی که قفل زمانیِ اعمال‌شده به صورت ریاضی منقضی نشود، توسط هیچ کاربری—از جمله مدیران دارای دسترسی ریشه (root) یا حساب‌های کاربریِ به خطر افتاده—قابل تغییر، رمزگذاری یا حذف نیستند.

حالت انطباق (Compliance Mode) در مقابل حالت حاکمیتی (Governance Mode)

هنگام پیاده‌سازی تغییرناپذیری، به‌ویژه در ذخیره‌سازی اشیاء ابری مانند AWS S3، Azure Blob یا SANهای داخلی سازگار با S3، باید تفاوت بین حالت‌های نگهداری را درک کنید:

• حالت حاکمیتی (Governance Mode): از حذف یا تغییر اشیاء توسط کاربران عادی جلوگیری می‌کند. با این حال، کاربرانی که مجوزهای IAM خاصی دارند (مانند s3:BypassGovernanceRetention) می‌توانند قفل را دور بزنند. این حالت برای تست مفید است اما برای محافظت در برابر باج‌افزار کافی نیست، زیرا مهاجمان اغلب امتیازات خود را به مدیر دامنه یا ریشه ارتقا می‌دهند.
• حالت انطباق (Compliance Mode): استاندارد طلایی برای دفاع در برابر باج‌افزار است. هنگامی که یک شیء در حالت انطباق قفل می‌شود، دوره نگهداری آن قابل کاهش نیست و شیء توسط هیچ‌کس، حتی حساب ریشه AWS، قابل حذف نمی‌باشد. این قفل در سطح کلاستر ذخیره‌سازی اعمال می‌شود.

معماری خط لوله پشتیبان‌گیری تغییرناپذیر

یک معماری آرشیو پایگاه داده قوی، عملیات فعال پایگاه داده را از لایه آرشیو تغییرناپذیر جدا می‌کند. شما نمی‌توانید تغییرناپذیری را بر فایل‌های فعال پایگاه داده (مانند .mdf/.ldf در SQL Server یا دایرکتوری pg_data در PostgreSQL) اعمال کنید، زیرا پایگاه‌های داده به دسترسی مداوم خواندن/نوشتن نیاز دارند.

در عوض، تغییرناپذیری بر موارد زیر اعمال می‌شود:
۱. فایل‌های پشتیبان کامل و تفاضلی: اسنپ‌شات‌های پایه از پایگاه داده.
۲. لاگ‌های تراکنش / فایل‌های WAL: جریان مداوم تغییرات پایگاه داده که برای بازیابی در لحظه خاص (PITR) مورد نیاز است.

مقاصد ذخیره‌سازی برای تغییرناپذیری

شما می‌توانید ذخیره‌سازی تغییرناپذیر را در لایه‌های مختلف زیرساختی پیاده‌سازی کنید:
* ذخیره‌سازی اشیاء ابری: AWS S3 Object Lock، Azure Blob Immutable Storage، سیاست‌های نگهداری Google Cloud Storage.
* ذخیره‌سازی اشیاء داخلی (On-Premises): MinIO، Cloudian یا Pure Storage FlashBlade که از APIهای S3 Object Lock پشتیبانی می‌کنند.
* ذخیره‌سازی بلوکی/فایلی: ZFS با اسنپ‌شات‌های فقط‌خواندنی و مدیریت تفویض‌شده، یا ویژگی‌های فایل در لینوکس.

پیاده‌سازی ذخیره‌سازی تغییرناپذیر: راهنمای فنی

۱. ذخیره‌سازی اشیاء ابری: AWS S3 Object Lock

برای محافظت از دامپ‌های پایگاه داده و لاگ‌های تراکنش در AWS، باید در زمان ایجاد باکت (Bucket)، گزینه Object Lock را فعال کنید.

ابتدا باکت را با فعال بودن Object Lock ایجاد کنید:

aws s3api create-bucket 
    --bucket prod-db-archive-immutable 
    --region us-east-1 
    --object-lock-enabled-for-bucket

سپس، سیاست نگهداری پیش‌فرض را پیکربندی کنید. برای آرشیوهای پایگاه داده، قفل انطباق ۳۰ روزه یک استاندارد پایه است که اطمینان می‌دهد یک ماه پشتیبان غیرقابل تغییر در اختیار دارید.

aws s3api put-object-lock-configuration 
    --bucket prod-db-archive-immutable 
    --object-lock-configuration '{
        "ObjectLockEnabled": "Enabled",
        "Rule": {
            "DefaultRetention": {
                "Mode": "COMPLIANCE",
                "Days": 30
            }
        }
    }'

هنگامی که اسکریپت یا عامل پشتیبان‌گیری پایگاه داده شما فایلی را به این باکت ارسال می‌کند، S3 به‌طور خودکار Retain Until Date را بر اساس زمان ایجاد شیء به اضافه ۳۰ روز محاسبه می‌کند.

۲. تغییرناپذیری داخلی: ZFS و ویژگی‌های لینوکس

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

استفاده از chattr در لینوکس:
فلگ +i (تغییرناپذیر) از تغییر، حذف یا تغییر نام فایل جلوگیری می‌کند.

# دامپ گرفتن از پایگاه داده
pg_dump -U postgres -Fc mydb > /backups/mydb_$(date +%F).dump

# تغییرناپذیر کردن پشتیبان
sudo chattr +i /backups/mydb_$(date +%F).dump

# تایید ویژگی
lsattr /backups/mydb_$(date +%F).dump
# خروجی: ----i---------e------- /backups/mydb_2023-10-27.dump

نکته: اگرچه chattr اسکریپت‌های باج‌افزاری ساده را متوقف می‌کند، یک مهاجم پیچیده با دسترسی ریشه می‌تواند به سادگی chattr -i را اجرا کند. بنابراین، این روش باید با کنترل دسترسی مبتنی بر نقش (RBAC) سخت‌گیرانه و شبکه‌های پشتیبان‌گیری ایزوله ترکیب شود.

استفاده از اسنپ‌شات‌های ZFS:
ZFS دفاع بسیار قوی‌تری ارائه می‌دهد. با گرفتن اسنپ‌شات و قرار دادن یک «نگهدارنده» (hold) روی آن، از حذف اسنپ‌شات جلوگیری می‌کنید.

# گرفتن اسنپ‌شات از دیتاست پشتیبان
zfs snapshot tank/db_backups@archive_$(date +%F)

# قرار دادن نگهدارنده روی اسنپ‌شات برای جلوگیری از حذف
zfs hold keep_30_days tank/db_backups@archive_$(date +%F)

# حتی ریشه هم نمی‌تواند بدون آزاد کردن نگهدارنده، این اسنپ‌شات را حذف کند
zfs destroy tank/db_backups@archive_$(date +%F)
# خروجی: cannot destroy 'tank/db_backups@archive_...': dataset is busy

استراتژی‌های آرشیو مخصوص پایگاه داده

برای دستیابی به بازیابی در لحظه خاص (PITR)، باید به‌طور مداوم لاگ‌های تراکنش را در ذخیره‌سازی تغییرناپذیر خود آرشیو کنید.

آرشیو WAL در PostgreSQL با pgBackRest

pgBackRest یک ابزار پشتیبان‌گیری بسیار قابل اعتماد برای PostgreSQL است که به‌طور بومی از ذخیره‌سازی سازگار با S3 پشتیبانی می‌کند. برای محافظت از لاگ‌های Write-Ahead (WAL)، pgBackRest را طوری پیکربندی کنید که مستقیماً به باکت S3 تغییرناپذیر شما ارسال شود.

در فایل pgbackrest.conf خود:

[global]
repo1-type=s3
repo1-s3-bucket=prod-db-archive-immutable
repo1-s3-region=us-east-1
repo1-s3-endpoint=s3.amazonaws.com
repo1-s3-key=AKIAIOSFODNN7EXAMPLE
repo1-s3-key-secret=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

# اطمینان حاصل کنید که نگهداری با پیکربندی S3 Object Lock شما همخوانی دارد
repo1-retention-full=2
repo1-retention-archive=2

[prod_cluster]
pg1-path=/var/lib/postgresql/14/main

ملاحظه حیاتی: اگر باکت S3 شما قفل انطباق ۳۰ روزه را اعمال می‌کند، اما pgBackRest تلاش می‌کند فایل‌های WAL را پس از ۱۴ روز بر اساس repo1-retention-archive منقضی و حذف کند، فراخوانی‌های API حذف با شکست مواجه خواهند شد. شما باید اطمینان حاصل کنید که سیاست نگهداری نرم‌افزار پشتیبان‌گیری شما بزرگتر یا مساوی با قفل تغییرناپذیر در سطح ذخیره‌سازی باشد.

Microsoft SQL Server: پشتیبان‌گیری به URL

SQL Server از پشتیبان‌گیری بومی مستقیماً به ذخیره‌سازی اشیاء سازگار با S3 پشتیبانی می‌کند. شما می‌توانید یک کار (Job) در SQL Server Agent پیکربندی کنید تا فایل‌های .bak و .trn را مستقیماً در یک باکت تغییرناپذیر بنویسد.

CREATE CREDENTIAL [s3://prod-db-archive-immutable.s3.us-east-1.amazonaws.com]
WITH IDENTITY = 'S3 Access Key',
SECRET = 'AccessKeyID:SecretAccessKey';
GO

BACKUP DATABASE [ProductionDB]
TO URL = 's3://prod-db-archive-immutable.s3.us-east-1.amazonaws.com/ProductionDB_Full.bak'
WITH FORMAT, COMPRESSION, STATS = 10;
GO

اتوماسیون و ارکستراسیون با CloudSave

مدیریت فلگ‌های نگهداری تغییرناپذیر، چرخش کلیدهای دسترسی و اطمینان از همگام‌سازی بین سیاست‌های نگهداری پایگاه داده و قفل‌های ذخیره‌سازی از طریق اسکریپت‌های سفارشی، بسیار مستعد خطا است. یک پیکربندی اشتباه در یک cron job یا فراخوانی API می‌تواند آرشیوهای شما را در معرض خطر قرار دهد یا به دلیل اشیاء قفل‌شده و یتیم، هزینه‌های ذخیره‌سازی ابری را به شدت افزایش دهد.

پلتفرم‌های پشتیبان‌گیری سازمانی مانند CloudSave این معماری را ساده می‌کنند. CloudSave به‌طور بومی با AWS S3 Object Lock، Azure Blob Immutable Storage و APIهای داخلی سازگار با S3 ادغام می‌شود.

هنگام پیکربندی یک برنامه پشتیبان‌گیری پایگاه داده در CloudSave:
۱. پلتفرم به‌طور خودکار quiescence سرویس VSS برای SQL Server یا API pg_start_backup() برای PostgreSQL را مدیریت می‌کند.
۲. داده‌های پشتیبان‌گیریِ کسر تکراری (deduplicated) و رمزگذاری‌شده را مستقیماً به مقصد ذخیره‌سازی ارسال می‌کند.
۳. CloudSave به‌صورت پویا فراخوانی‌های WORM API (مانند PutObjectRetention) را به ازای هر شیء اعمال می‌کند و مدت زمان قفل ذخیره‌سازی را کاملاً با برنامه نگهداری تعریف‌شده در سیاست هماهنگ می‌کند.
۴. اگر مهاجمی کنسول مدیریت CloudSave را به خطر بیندازد، همچنان نمی‌تواند پشتیبان‌ها را حذف کند، زیرا قفل انطباق توسط زیرساخت ذخیره‌سازی زیرین اعمال می‌شود، نه نرم‌افزار پشتیبان‌گیری.

بهترین شیوه‌ها برای آرشیوهای تغییرناپذیر پایگاه داده

برای اطمینان از اینکه معماری تغییرناپذیر شما واقعاً مقاوم است، از بهترین شیوه‌های مهندسی سیستم زیر پیروی کنید:

۱. همگام‌سازی دقیق NTP

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

۲. ایزوله‌سازی نقش‌ها و اعتبارنامه‌های IAM

اعتبارنامه‌هایی که برای نوشتن در باکت تغییرناپذیر استفاده می‌شوند، فقط باید مجوزهای s3:PutObject و s3:PutObjectRetention را داشته باشند. آن‌ها هرگز نباید مجوزهای s3:DeleteObject یا s3:PutBucketObjectLockConfiguration را داشته باشند.

نمونه‌ای از یک سیاست IAM با حداقل امتیاز برای یک عامل پشتیبان‌گیری پایگاه داده:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetBucketObjectLockConfiguration"
            ],
            "Resource": [
                "arn:aws:s3:::prod-db-archive-immutable",
                "arn:aws:s3:::prod-db-archive-immutable/*"
            ]
        }
    ]
}

۳. تعیین اندازه دوره نگهداری

قفل‌های انطباق را برای دوره‌های بسیار طولانی (مثلاً ۷ سال برای انطباق) در لایه بازیابی سریع اصلی خود تنظیم نکنید. پایگاه‌های داده حجم عظیمی از داده‌های WAL/لاگ تراکنش تولید می‌کنند. قفل کردن این داده‌ها برای سال‌ها منجر به رشد نمایی هزینه‌های ذخیره‌سازی خواهد شد.
در عوض، از یک رویکرد لایه‌بندی شده استفاده کنید:
* لایه بازیابی عملیاتی: ۱۴ تا ۳۰ روز نگهداری تغییرناپذیر برای فایل‌های کامل و لاگ‌ها.
* لایه آرشیو بلندمدت: پشتیبان‌های کامل ماهانه که به Glacier/Deep Archive با Vault Lock برای ۱ تا ۷ سال منتقل می‌شوند.

۴. تست بازیابی منظم در VPCهای ایزوله (Air-Gapped)

تغییرناپذیری تضمین می‌کند که داده‌ها قابل حذف نیستند، اما تضمین نمی‌کند که داده‌ها عاری از فساد منطقی باشند. شما باید بازیابی آرشیوهای پایگاه داده تغییرناپذیر خود را در یک VPC یا VLAN ایزوله و Air-Gapped خودکار کنید. برای تایید یکپارچگی ساختاری، دستور DBCC CHECKDB (SQL Server) یا pg_amcheck (PostgreSQL) را روی داده‌های بازیابی شده اجرا کنید.

نتیجه‌گیری

دفاع در برابر باج‌افزار تمرینی برای فرضِ وقوع نفوذ است. تا زمانی که هشداری در SIEM شما فعال شود، مهاجمان احتمالاً قبلاً تلاش کرده‌اند زیرساخت پشتیبان‌گیری شما را به خطر بیندازند. با معماری آرشیوهای پایگاه داده خود با استفاده از ذخیره‌سازی تغییرناپذیر در حالت انطباق، شما اهرم فشار اصلی مهاجمان را از آن‌ها می‌گیرید. چه از APIهای بومی ابری، نگهدارنده‌های ZFS یا یک پلتفرم ارکستراسیون سازمانی مانند CloudSave استفاده کنید، پیاده‌سازی ذخیره‌سازی WORM دیگر اختیاری نیست—این یک رکن اجباری در مدیریت مدرن پایگاه داده و بازیابی فاجعه است.