ڈیٹا بیس آرکائیوز کے لیے ناقابل تغیر اسٹوریج کی تعمیر تاکہ رینسم ویئر کو شکست دی جا سکے

جدید دور کے خطرات کے منظر نامے میں، رینسم ویئر (ransomware) موقع پرست انکرپشن سے ترقی کر کے انتہائی ہدف شدہ، کثیر بھتہ خوری (multi-extortion) کی مہمات میں تبدیل ہو چکا ہے۔ ایڈوانسڈ پرسسٹنٹ تھریٹس (APTs) اور رینسم ویئر سنڈیکیٹس اب اپنے قیام کے دوران بیک اپ انفراسٹرکچر اور ڈیٹا بیس آرکائیوز کی فعال تلاش کرتے ہیں۔ اگر کوئی حملہ آور آپ کے بنیادی ڈیٹا بیس کو سمجھوتہ کر لے اور ساتھ ہی آپ کے بیک اپ ریپوزٹریز کو حذف یا انکرپٹ کر دے، تو آپ کی تنظیم کو تباہ کن ڈیٹا کے نقصان کا سامنا کرنا پڑ سکتا ہے۔

ڈیٹا بیس ایڈمنسٹریٹرز (DBAs) اور ڈیواپس (DevOps) انجینئرز کے لیے، روایتی 3-2-1 بیک اپ حکمت عملی اب کافی نہیں ہے۔ ڈیٹا کی بقا کی ضمانت دینے کے لیے، انفراسٹرکچر ٹیموں کو 3-2-1-1 اصول اپنانا ہوگا، جہاں آخری "1” کا مطلب غیر متغیر اسٹوریج (immutable storage) ہے۔

یہ مضمون ڈیٹا بیس آرکائیوز کے لیے غیر متغیر اسٹوریج کو ڈیزائن کرنے، لاگو کرنے اور منظم کرنے کے بارے میں ایک جامع، تکنیکی گہرائی فراہم کرتا ہے تاکہ رینسم ویئر کے خلاف مکمل تحفظ کو یقینی بنایا جا سکے۔

غیر متغیر اسٹوریج کے میکانکس

غیر متغیر اسٹوریج ایک رائٹ-ونس-ریڈ-مینی (WORM) فن تعمیر پر انحصار کرتی ہے۔ ایک بار جب ڈیٹا کو غیر متغیر ہدف پر لکھ دیا جاتا ہے، تو اسے کوئی بھی صارف—بشمول روٹ مراعات کے حامل ایڈمنسٹریٹرز یا سمجھوتہ شدہ سروس اکاؤنٹس—تب تک تبدیل، انکرپٹ یا حذف نہیں کر سکتا جب تک کہ ریاضیاتی طور پر نافذ کردہ ٹائم لاک ختم نہ ہو جائے۔

کمپلائنس موڈ بمقابلہ گورننس موڈ

غیر متغیریت کو لاگو کرتے وقت، خاص طور پر کلاؤڈ آبجیکٹ اسٹوریج جیسے AWS S3، Azure Blob، یا S3 کے ساتھ مطابقت رکھنے والے آن-پریمیسس SANs میں، آپ کو ریٹینشن موڈز کے درمیان فرق کو سمجھنا ہوگا:

• گورننس موڈ: عام صارفین کو اشیاء کو حذف کرنے یا تبدیل کرنے سے روکتا ہے۔ تاہم، مخصوص IAM اجازتوں والے صارفین (مثلاً s3:BypassGovernanceRetention) لاک کو اوور رائیڈ کر سکتے ہیں۔ یہ جانچ کے لیے مفید ہے لیکن رینسم ویئر سے تحفظ کے لیے ناکافی ہے، کیونکہ حملہ آور اکثر ڈومین ایڈمن یا روٹ تک مراعات بڑھا لیتے ہیں۔
• کمپلائنس موڈ: رینسم ویئر کے دفاع کے لیے سنہری معیار۔ ایک بار جب کوئی آبجیکٹ کمپلائنس موڈ میں لاک ہو جاتا ہے، تو اس کی ریٹینشن مدت کو کم نہیں کیا جا سکتا، اور اس آبجیکٹ کو کوئی بھی حذف نہیں کر سکتا، بشمول AWS روٹ اکاؤنٹ کے۔ لاک کو اسٹوریج کلسٹر کی سطح پر نافذ کیا جاتا ہے۔

ایک غیر متغیر بیک اپ پائپ لائن کا فن تعمیر

ایک مضبوط ڈیٹا بیس آرکائیونگ فن تعمیر فعال ڈیٹا بیس آپریشنز کو غیر متغیر آرکائیو ٹائر سے الگ کرتا ہے۔ آپ فعال ڈیٹا بیس فائلوں (جیسے SQL Server میں .mdf/.ldf یا PostgreSQL میں pg_data ڈائریکٹری) پر غیر متغیریت لاگو نہیں کر سکتے کیونکہ ڈیٹا بیس کو مسلسل پڑھنے/لکھنے کی رسائی کی ضرورت ہوتی ہے۔

اس کے بجائے، غیر متغیریت کا اطلاق ان پر ہوتا ہے:
1. مکمل اور تفریقی بیک اپ فائلیں: ڈیٹا بیس کے بنیادی اسنیپ شاٹس۔
2. ٹرانزیکشن لاگز / WAL فائلیں: پوائنٹ-ان-ٹائم ریکوری (PITR) کے لیے درکار ڈیٹا بیس تبدیلیوں کا مسلسل سلسلہ۔

غیر متغیریت کے لیے اسٹوریج کے اہداف

آپ مختلف انفراسٹرکچر ٹائرز پر غیر متغیر اسٹوریج لاگو کر سکتے ہیں:
* کلاؤڈ آبجیکٹ اسٹوریج: AWS S3 آبجیکٹ لاک، Azure Blob غیر متغیر اسٹوریج، گوگل کلاؤڈ اسٹوریج ریٹینشن پالیسیاں۔
* آن-پریمیسس آبجیکٹ اسٹوریج: MinIO، Cloudian، یا Pure Storage FlashBlade جو S3 آبجیکٹ لاک APIs کو سپورٹ کرتے ہیں۔
* بلاک/فائل اسٹوریج: ZFS جس میں صرف پڑھنے کے قابل اسنیپ شاٹس اور تفویض کردہ انتظامیہ، یا لینکس فائل کی خصوصیات۔

غیر متغیر اسٹوریج کا نفاذ: تکنیکی واک تھرو

1. کلاؤڈ آبجیکٹ اسٹوریج: AWS S3 آبجیکٹ لاک

AWS میں ڈیٹا بیس ڈمپ اور ٹرانزیکشن لاگز کی حفاظت کے لیے، آپ کو بکٹ بناتے وقت آبجیکٹ لاک کو فعال کرنا ہوگا۔

سب سے پہلے، آبجیکٹ لاک فعال کے ساتھ بکٹ بنائیں:

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 دن جمع کر کے Retain Until Date کا حساب لگاتا ہے۔

2. آن-پریمیسس غیر متغیریت: 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 بہت مضبوط دفاع فراہم کرتا ہے۔ اسنیپ شاٹ لے کر اور اس پر "ہولڈ” لگا کر، آپ اسنیپ شاٹ کو تباہ ہونے سے روکتے ہیں۔

# بیک اپ ڈیٹا سیٹ کا اسنیپ شاٹ لیں
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) حاصل کرنے کے لیے، آپ کو مسلسل ٹرانزیکشن لاگز کو اپنے غیر متغیر اسٹوریج میں آرکائیو کرنا ہوگا۔

pgBackRest کے ساتھ PostgreSQL WAL آرکائیونگ

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 آبجیکٹ لاک کنفیگریشن کے مطابق ہو
repo1-retention-full=2
repo1-retention-archive=2

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

اہم غور: اگر آپ کا S3 بکٹ 30 دن کا کمپلائنس لاک نافذ کرتا ہے، لیکن pgBackRest repo1-retention-archive کی بنیاد پر 14 دن بعد WAL فائلوں کی میعاد ختم کرنے اور حذف کرنے کی کوشش کرتا ہے، تو حذف کرنے کی API کالز ناکام ہو جائیں گی۔ آپ کو اس بات کو یقینی بنانا ہوگا کہ آپ کے بیک اپ سافٹ ویئر کی ریٹینشن پالیسی اسٹوریج کی سطح کے غیر متغیر لاک سے زیادہ یا اس کے برابر ہو۔

مائیکروسافٹ SQL سرور: URL پر بیک اپ

SQL سرور براہ راست S3 کے ساتھ مطابقت رکھنے والے آبجیکٹ اسٹوریج پر مقامی بیک اپ کو سپورٹ کرتا ہے۔ آپ .bak اور .trn فائلوں کو براہ راست غیر متغیر بکٹ میں لکھنے کے لیے SQL سرور ایجنٹ جاب کنفیگر کر سکتے ہیں۔

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 کے ساتھ آٹومیشن اور آرکیسٹریشن

غیر متغیر ریٹینشن فلیگز کا انتظام کرنا، ایکسیس کیز کو تبدیل کرنا، اور کسٹم اسکرپٹس کے ذریعے ڈیٹا بیس ریٹینشن پالیسیوں اور اسٹوریج لاکس کے درمیان ہم آہنگی کو یقینی بنانا انتہائی غلطی کا شکار ہے۔ کرون جاب یا API کال میں ایک چھوٹی سی غلط کنفیگریشن آپ کے آرکائیوز کو بے نقاب کر سکتی ہے یا یتیم، لاک شدہ اشیاء کی وجہ سے کلاؤڈ اسٹوریج کے اخراجات میں تیزی سے اضافہ کر سکتی ہے۔

انٹرپرائز بیک اپ پلیٹ فارمز جیسے CloudSave اس فن تعمیر کو آسان بناتے ہیں۔ CloudSave مقامی طور پر AWS S3 آبجیکٹ لاک، Azure Blob غیر متغیر اسٹوریج، اور آن-پریمیسس S3 کے ساتھ مطابقت رکھنے والے APIs کے ساتھ ضم ہوتا ہے۔

CloudSave میں ڈیٹا بیس بیک اپ پلان کنفیگر کرتے وقت:
1. پلیٹ فارم خود بخود SQL سرور کے لیے VSS (والیوم شیڈو کاپی سروس) یا PostgreSQL کے لیے pg_start_backup() API کو سنبھالتا ہے۔
2. یہ ڈی ڈپلیکیٹڈ، انکرپٹڈ بیک اپ ڈیٹا کو براہ راست اسٹوریج ہدف پر اسٹریم کرتا ہے۔
3. CloudSave متحرک طور پر WORM API کالز (مثلاً 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 دن کی غیر متغیر ریٹینشن۔
* طویل مدتی آرکائیول ٹائر: ماہانہ مکمل بیک اپ جو 1-7 سال کے لیے والٹ لاک کے ساتھ Glacier/Deep Archive میں منتقل کیے جاتے ہیں۔

4. ایئر گیپڈ VPCs میں باقاعدہ ریکوری ٹیسٹنگ

غیر متغیریت اس بات کی ضمانت دیتی ہے کہ ڈیٹا کو حذف نہیں کیا جا سکتا، لیکن یہ اس بات کی ضمانت نہیں دیتی کہ ڈیٹا منطقی کرپشن سے پاک ہے۔ آپ کو اپنے غیر متغیر ڈیٹا بیس آرکائیوز کی بحالی کو ایک الگ تھلگ، ایئر گیپڈ VPC یا VLAN میں خودکار بنانا ہوگا۔ ساختی سالمیت کی تصدیق کے لیے بحال شدہ ڈیٹا پر DBCC CHECKDB (SQL سرور) یا pg_amcheck (PostgreSQL) چلائیں۔

نتیجہ

رینسم ویئر کا دفاع خلاف ورزی کو فرض کرنے کی ایک مشق ہے۔ جب تک آپ کے SIEM میں الرٹ بجتا ہے، تب تک خطرہ پیدا کرنے والے عناصر غالباً آپ کے بیک اپ انفراسٹرکچر سے سمجھوتہ کرنے کی کوشش کر چکے ہوتے ہیں۔ کمپلائنس موڈ میں غیر متغیر اسٹوریج کا استعمال کرتے ہوئے اپنے ڈیٹا بیس آرکائیوز کو ڈیزائن کر کے، آپ حملہ آوروں سے ان کا بنیادی فائدہ چھین لیتے ہیں۔ چاہے آپ مقامی کلاؤڈ APIs، ZFS ہولڈز، یا CloudSave جیسے انٹرپرائز آرکیسٹریشن پلیٹ فارم کا استعمال کریں، WORM اسٹوریج کو لاگو کرنا اب اختیاری نہیں ہے—یہ جدید ڈیٹا بیس ایڈمنسٹریشن اور ڈیزاسٹر ریکوری کا ایک لازمی ستون ہے۔