هندسة التخزين غير القابل للتغيير لأرشيفات قواعد البيانات للتصدي لبرامج الفدية

في مشهد التهديدات الحديث، تطورت برامج الفدية من التشفير الانتهازي إلى حملات ابتزاز متعددة وموجهة للغاية. تبحث التهديدات المستمرة المتقدمة (APTs) وعصابات برامج الفدية الآن بنشاط عن البنية التحتية للنسخ الاحتياطي وأرشيفات قواعد البيانات خلال فترة وجودها في النظام. إذا قام المهاجم باختراق قاعدة بياناتك الأساسية وقام في الوقت نفسه بحذف أو تشفير مستودعات النسخ الاحتياطي الخاصة بك، فستواجه مؤسستك فقدانًا كارثيًا للبيانات.

بالنسبة لمسؤولي قواعد البيانات (DBAs) ومهندسي DevOps، لم تعد استراتيجية النسخ الاحتياطي التقليدية 3-2-1 كافية. ولضمان بقاء البيانات، يجب على فرق البنية التحتية اعتماد قاعدة 3-2-1-1، حيث يمثل الرقم “1” الأخير التخزين غير القابل للتغيير (Immutable Storage).

تقدم هذه المقالة نظرة تقنية شاملة ومتعمقة حول تصميم وتنفيذ وإدارة التخزين غير القابل للتغيير لأرشيفات قواعد البيانات لضمان المرونة المطلقة ضد برامج الفدية.

آليات التخزين غير القابل للتغيير

يعتمد التخزين غير القابل للتغيير على بنية “الكتابة لمرة واحدة والقراءة لعدة مرات” (WORM). بمجرد كتابة البيانات في هدف غير قابل للتغيير، لا يمكن تعديلها أو تشفيرها أو حذفها من قبل أي مستخدم—بما في ذلك المسؤولون الذين لديهم صلاحيات الجذر (root) أو حسابات الخدمة المخترقة—حتى تنتهي صلاحية قفل زمني مفروض رياضيًا.

وضع الامتثال مقابل وضع الحوكمة

عند تنفيذ خاصية عدم القابلية للتغيير، خاصة في تخزين الكائنات السحابية مثل AWS S3 أو Azure Blob أو أنظمة SAN المحلية المتوافقة مع S3، يجب أن تفهم الفرق بين أوضاع الاحتفاظ:

• وضع الحوكمة (Governance Mode): يمنع المستخدمين العاديين من حذف الكائنات أو تغييرها. ومع ذلك، يمكن للمستخدمين الذين لديهم أذونات IAM محددة (مثل s3:BypassGovernanceRetention) تجاوز القفل. هذا مفيد للاختبار ولكنه غير كافٍ للحماية من برامج الفدية، حيث يقوم المهاجمون غالبًا بتصعيد الصلاحيات إلى مسؤول النطاق (domain admin) أو الجذر (root).
• وضع الامتثال (Compliance Mode): المعيار الذهبي للدفاع ضد برامج الفدية. بمجرد قفل الكائن في وضع الامتثال، لا يمكن تقصير فترة الاحتفاظ به، ولا يمكن حذف الكائن من قبل أي شخص، بما في ذلك حساب الجذر في AWS. يتم فرض القفل على مستوى مجموعة التخزين (storage cluster).

تصميم خط أنابيب نسخ احتياطي غير قابل للتغيير

تفصل بنية أرشفة قواعد البيانات القوية بين عمليات قاعدة البيانات النشطة وطبقة الأرشيف غير القابلة للتغيير. لا يمكنك تطبيق خاصية عدم القابلية للتغيير على ملفات قاعدة البيانات النشطة (مثل .mdf/.ldf في SQL Server أو دليل pg_data في PostgreSQL) لأن قواعد البيانات تتطلب وصولاً مستمرًا للقراءة والكتابة.

بدلاً من ذلك، يتم تطبيق خاصية عدم القابلية للتغيير على:
1. ملفات النسخ الاحتياطي الكامل والتفاضلي: اللقطات الأساسية لقاعدة البيانات.
2. سجلات المعاملات / ملفات WAL: التدفق المستمر لتغييرات قاعدة البيانات المطلوبة للاسترداد إلى نقطة زمنية محددة (PITR).

أهداف التخزين لخاصية عدم القابلية للتغيير

يمكنك تنفيذ التخزين غير القابل للتغيير عبر طبقات بنية تحتية مختلفة:
* تخزين الكائنات السحابية: AWS S3 Object Lock، وAzure Blob Immutable Storage، وسياسات الاحتفاظ في Google Cloud Storage.
* تخزين الكائنات المحلي: MinIO أو Cloudian أو Pure Storage FlashBlade التي تدعم واجهات برمجة تطبيقات S3 Object Lock.
* تخزين الكتل/الملفات: ZFS مع لقطات للقراءة فقط وإدارة مفوضة، أو سمات ملفات Linux.

تنفيذ التخزين غير القابل للتغيير: خطوات تقنية

1. تخزين الكائنات السحابية: AWS S3 Object Lock

لحماية نسخ قواعد البيانات وسجلات المعاملات في AWS، يجب عليك تمكين Object Lock عند إنشاء الحاوية (bucket).

أولاً، قم بإنشاء الحاوية مع تمكين Object Lock:

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

بعد ذلك، قم بتكوين سياسة الاحتفاظ الافتراضية. بالنسبة لأرشيفات قواعد البيانات، يعد قفل الامتثال لمدة 30 يومًا أساسًا قياسيًا، مما يضمن حصولك على شهر من النسخ الاحتياطية غير القابلة للتغيير.

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

عندما يقوم برنامج أو وكيل النسخ الاحتياطي لقاعدة البيانات بدفع ملف إلى هذه الحاوية، يقوم S3 تلقائيًا بحساب تاريخ الاحتفاظ حتى بناءً على الطابع الزمني لإنشاء الكائن مضافًا إليه 30 يومًا.

2. خاصية عدم القابلية للتغيير محليًا: ZFS وسمات Linux

إذا كنت تقوم بأرشفة قواعد البيانات إلى خادم نسخ احتياطي محلي يعمل بنظام Linux، يمكنك تحقيق خاصية عدم القابلية للتغيير الزائفة باستخدام أمر chattr، أو خاصية عدم القابلية للتغيير الحقيقية باستخدام لقطات ZFS.

استخدام chattr في Linux:
تمنع علامة +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. لحماية سجلات الكتابة المسبقة (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 تفرض قفل امتثال لمدة 30 يومًا، ولكن pgBackRest يحاول إنهاء صلاحية ملفات WAL وحذفها بعد 14 يومًا بناءً على repo1-retention-archive، فستفشل استدعاءات واجهة برمجة تطبيقات الحذف. يجب عليك التأكد من أن سياسة الاحتفاظ الخاصة ببرنامج النسخ الاحتياطي أكبر من أو تساوي قفل عدم القابلية للتغيير على مستوى التخزين.

Microsoft SQL Server: النسخ الاحتياطي إلى URL

يدعم SQL Server النسخ الاحتياطية الأصلية مباشرة إلى تخزين الكائنات المتوافق مع S3. يمكنك تكوين مهمة 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 أو استدعاء واجهة برمجة التطبيقات إلى ترك أرشيفاتك مكشوفة أو يؤدي إلى ارتفاع تكاليف التخزين السحابي بسبب الكائنات المقفلة المهجورة.

تعمل منصات النسخ الاحتياطي للمؤسسات مثل CloudSave على تبسيط هذه البنية. يتكامل CloudSave أصلاً مع AWS S3 Object Lock وAzure Blob Immutable Storage وواجهات برمجة تطبيقات S3 المحلية المتوافقة.

عند تكوين خطة نسخ احتياطي لقاعدة البيانات في CloudSave:
1. تتعامل المنصة تلقائيًا مع سكون VSS (خدمة نسخ الظل لوحدة التخزين) لـ SQL Server أو واجهة برمجة تطبيقات pg_start_backup() لـ PostgreSQL.
2. تقوم ببث بيانات النسخ الاحتياطي المشفرة والمزالة التكرار مباشرة إلى هدف التخزين.
3. يطبق CloudSave ديناميكيًا استدعاءات واجهة برمجة تطبيقات WORM (مثل PutObjectRetention) على أساس كل كائن، مما يطابق مدة قفل التخزين بشكل مثالي مع جدول الاحتفاظ المحدد بالسياسة.
4. إذا قام مهاجم باختراق وحدة تحكم إدارة CloudSave، فلا يزال بإمكانه حذف النسخ الاحتياطية، حيث يتم فرض قفل الامتثال بواسطة البنية التحتية للتخزين الأساسية، وليس بواسطة برنامج النسخ الاحتياطي.

أفضل الممارسات لأرشيفات قواعد البيانات غير القابلة للتغيير

لضمان أن بنيتك غير القابلة للتغيير مرنة حقًا، التزم بأفضل ممارسات هندسة النظم التالية:

1. مزامنة NTP الصارمة

ترتبط الأقفال غير القابلة للتغيير رياضيًا بالطوابع الزمنية. إذا تم اختراق خدمة NTP (بروتوكول وقت الشبكة) على مصفوفة التخزين أو خادم النسخ الاحتياطي أو انحرفت، فقد يتسبب ذلك في انتهاء صلاحية الأقفال قبل الأوان أو عدم انتهاء صلاحيتها على الإطلاق. تأكد من أن البنية التحتية للتخزين الخاصة بك تستخدم مصادر NTP موثوقة ومتكررة.

2. عزل أدوار 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/*"
            ]
        }
    ]
}

3. تحديد حجم فترة الاحتفاظ

لا تقم بتعيين أقفال امتثال لفترات طويلة بشكل مفرط (مثل 7 سنوات للامتثال) على طبقة الاسترداد السريع الأساسية الخاصة بك. تولد قواعد البيانات كميات هائلة من بيانات سجلات WAL/المعاملات. سيؤدي قفل هذه البيانات لسنوات إلى نمو أسي في تكاليف التخزين.
بدلاً من ذلك، استخدم نهجًا متدرجًا:
* طبقة الاسترداد التشغيلي: 14 إلى 30 يومًا من الاحتفاظ غير القابل للتغيير للنسخ الكاملة والسجلات.
* طبقة الأرشفة طويلة المدى: نسخ احتياطية كاملة شهرية يتم نقلها إلى Glacier/Deep Archive مع Vault Lock لمدة 1-7 سنوات.

4. اختبار الاسترداد المنتظم في VPCs معزولة

تضمن خاصية عدم القابلية للتغيير عدم إمكانية حذف البيانات، لكنها لا تضمن خلو البيانات من التلف المنطقي. يجب عليك أتمتة استعادة أرشيفات قاعدة البيانات غير القابلة للتغيير الخاصة بك إلى VPC أو VLAN معزولة. قم بتشغيل DBCC CHECKDB (SQL Server) أو pg_amcheck (PostgreSQL) على البيانات المستعادة للتحقق من السلامة الهيكلية.

الخلاصة

الدفاع ضد برامج الفدية هو تمرين على افتراض الاختراق. بحلول الوقت الذي يتم فيه إطلاق تنبيه في SIEM الخاص بك، من المحتمل أن يكون المهاجمون قد حاولوا بالفعل اختراق البنية التحتية للنسخ الاحتياطي الخاصة بك. من خلال تصميم أرشيفات قاعدة البيانات الخاصة بك باستخدام التخزين غير القابل للتغيير في وضع الامتثال، فإنك تجرد المهاجمين من ورقة ضغطهم الأساسية. سواء كنت تستخدم واجهات برمجة التطبيقات السحابية الأصلية، أو لقطات ZFS، أو منصة تنسيق للمؤسسات مثل CloudSave، فإن تنفيذ تخزين WORM لم يعد اختياريًا—بل هو ركيزة إلزامية لإدارة قواعد البيانات الحديثة والتعافي من الكوارث.