रैंसमवेयर को हराने के लिए डेटाबेस आर्काइव हेतु इम्यूटेबल स्टोरेज की आर्किटेक्चरिंग

आधुनिक खतरे के परिदृश्य में, रैंसमवेयर अवसरवादी एन्क्रिप्शन से विकसित होकर अत्यधिक लक्षित, बहु-जबरन वसूली (multi-extortion) अभियानों में बदल गया है। एडवांस्ड पर्सिस्टेंट थ्रेट्स (APTs) और रैंसमवेयर सिंडिकेट अब अपने ड्वेल टाइम (dwell time) के दौरान सक्रिय रूप से बैकअप इंफ्रास्ट्रक्चर और डेटाबेस आर्काइव की तलाश करते हैं। यदि कोई हमलावर आपके प्राथमिक डेटाबेस से समझौता करता है और साथ ही आपके बैकअप रिपॉजिटरी को हटा या एन्क्रिप्ट कर देता है, तो आपके संगठन को विनाशकारी डेटा हानि का सामना करना पड़ता है।

डेटाबेस एडमिनिस्ट्रेटर (DBAs) और DevOps इंजीनियरों के लिए, पारंपरिक 3-2-1 बैकअप रणनीति अब पर्याप्त नहीं है। डेटा की उत्तरजीविता (survivability) की गारंटी देने के लिए, इंफ्रास्ट्रक्चर टीमों को 3-2-1-1 नियम अपनाना होगा, जहाँ अंतिम “1” का अर्थ इम्यूटेबल स्टोरेज (अपरिवर्तनीय भंडारण) है।

यह लेख पूर्ण रैंसमवेयर लचीलापन सुनिश्चित करने के लिए डेटाबेस आर्काइव हेतु इम्यूटेबल स्टोरेज को आर्किटेक्ट करने, लागू करने और प्रबंधित करने के बारे में एक व्यापक, तकनीकी जानकारी प्रदान करता है।

इम्यूटेबल स्टोरेज की कार्यप्रणाली

इम्यूटेबल स्टोरेज ‘राइट-वन्स-रीड-मेनी’ (WORM) आर्किटेक्चर पर निर्भर करता है। एक बार जब डेटा को इम्यूटेबल लक्ष्य पर लिख दिया जाता है, तो इसे किसी भी उपयोगकर्ता द्वारा—रूट विशेषाधिकार वाले प्रशासकों या समझौता किए गए सर्विस अकाउंट्स सहित—तब तक संशोधित, एन्क्रिप्ट या हटाया नहीं जा सकता, जब तक कि गणितीय रूप से लागू किया गया टाइम लॉक समाप्त न हो जाए।

अनुपालन मोड (Compliance Mode) बनाम गवर्नेंस मोड (Governance Mode)

इम्यूटेबिलिटी लागू करते समय, विशेष रूप से AWS S3, Azure Blob, या S3-संगत ऑन-प्रिमाइसेस SAN जैसे क्लाउड ऑब्जेक्ट स्टोरेज में, आपको रिटेंशन मोड के बीच अंतर को समझना चाहिए:

• गवर्नेंस मोड: मानक उपयोगकर्ताओं को ऑब्जेक्ट्स को हटाने या बदलने से रोकता है। हालाँकि, विशिष्ट IAM अनुमतियों (जैसे s3:BypassGovernanceRetention) वाले उपयोगकर्ता लॉक को ओवरराइड कर सकते हैं। यह परीक्षण के लिए उपयोगी है लेकिन रैंसमवेयर सुरक्षा के लिए अपर्याप्त है, क्योंकि हमलावर अक्सर विशेषाधिकारों को डोमेन एडमिन या रूट तक बढ़ा लेते हैं।
• अनुपालन मोड: रैंसमवेयर सुरक्षा के लिए स्वर्ण मानक। एक बार जब कोई ऑब्जेक्ट अनुपालन मोड में लॉक हो जाता है, तो उसकी रिटेंशन अवधि को छोटा नहीं किया जा सकता है, और ऑब्जेक्ट को AWS रूट अकाउंट सहित किसी के भी द्वारा हटाया नहीं जा सकता है। लॉक को स्टोरेज क्लस्टर स्तर पर लागू किया जाता है।

एक इम्यूटेबल बैकअप पाइपलाइन का आर्किटेक्चर

एक मजबूत डेटाबेस आर्काइविंग आर्किटेक्चर सक्रिय डेटाबेस ऑपरेशंस को इम्यूटेबल आर्काइव टियर से अलग करता है। आप सक्रिय डेटाबेस फ़ाइलों (जैसे SQL सर्वर में .mdf/.ldf या PostgreSQL में pg_data डायरेक्टरी) पर इम्यूटेबिलिटी लागू नहीं कर सकते क्योंकि डेटाबेस को निरंतर रीड/राइट एक्सेस की आवश्यकता होती है।

इसके बजाय, इम्यूटेबिलिटी इन पर लागू की जाती है:
1. पूर्ण और डिफरेंशियल बैकअप फ़ाइलें: डेटाबेस के बेसलाइन स्नैपशॉट।
2. ट्रांजैक्शन लॉग्स / WAL फ़ाइलें: पॉइंट-इन-टाइम रिकवरी (PITR) के लिए आवश्यक डेटाबेस परिवर्तनों की निरंतर स्ट्रीम।

इम्यूटेबिलिटी के लिए स्टोरेज लक्ष्य

आप विभिन्न इंफ्रास्ट्रक्चर टियर्स पर इम्यूटेबल स्टोरेज लागू कर सकते हैं:
* क्लाउड ऑब्जेक्ट स्टोरेज: AWS S3 ऑब्जेक्ट लॉक, Azure Blob इम्यूटेबल स्टोरेज, Google क्लाउड स्टोरेज रिटेंशन पॉलिसी।
* ऑन-प्रिमाइसेस ऑब्जेक्ट स्टोरेज: MinIO, Cloudian, या Pure Storage FlashBlade जो S3 ऑब्जेक्ट लॉक API का समर्थन करते हैं।
* ब्लॉक/फ़ाइल स्टोरेज: रीड-ओनली स्नैपशॉट और प्रत्यायोजित प्रशासन के साथ 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-संगत API के साथ एकीकृत होता है।

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 वर्षों के लिए वॉल्ट लॉक के साथ ग्लेशियर/डीप आर्काइव में ले जाया गया है।

4. एयर-गैप्ड VPCs में नियमित रिकवरी परीक्षण

इम्यूटेबिलिटी गारंटी देती है कि डेटा को हटाया नहीं जा सकता है, लेकिन यह गारंटी नहीं देती है कि डेटा तार्किक भ्रष्टाचार (logical corruption) से मुक्त है। आपको अपने इम्यूटेबल डेटाबेस आर्काइव को एक अलग, एयर-गैप्ड VPC या VLAN में पुनर्स्थापित करने को स्वचालित करना होगा। संरचनात्मक अखंडता को सत्यापित करने के लिए पुनर्स्थापित डेटा पर DBCC CHECKDB (SQL सर्वर) या pg_amcheck (PostgreSQL) चलाएं।

निष्कर्ष

रैंसमवेयर सुरक्षा उल्लंघन मान लेने का एक अभ्यास है। जब तक आपके SIEM में अलर्ट बजता है, तब तक खतरा पैदा करने वाले अभिनेताओं ने संभवतः आपके बैकअप इंफ्रास्ट्रक्चर से समझौता करने का प्रयास किया होगा। अनुपालन मोड में इम्यूटेबल स्टोरेज का उपयोग करके अपने डेटाबेस आर्काइव को आर्किटेक्ट करके, आप हमलावरों से उनका प्राथमिक लाभ छीन लेते हैं। चाहे आप मूल क्लाउड API, ZFS होल्ड्स, या CloudSave जैसे एंटरप्राइज़ ऑर्केस्ट्रेशन प्लेटफ़ॉर्म का उपयोग करें, WORM स्टोरेज को लागू करना अब वैकल्पिक नहीं है—यह आधुनिक डेटाबेस प्रशासन और आपदा रिकवरी का एक अनिवार्य स्तंभ है।