Immutable Database Storage to Defeat Ransomware

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

डाटाबेस प्रशासकहरू (DBAs) र DevOps इन्जिनियरहरूका लागि, परम्परागत ३-२-१ ब्याकअप रणनीति अब पर्याप्त छैन। डेटाको अस्तित्व सुनिश्चित गर्न, पूर्वाधार टोलीहरूले ३-२-१-१ नियम अपनाउनुपर्छ, जहाँ अन्तिम “१” ले अपरिवर्तनीय भण्डारण (immutable storage) लाई प्रतिनिधित्व गर्दछ।

यो लेखले पूर्ण र्यान्समवेयर लचिलोपन सुनिश्चित गर्न डाटाबेस अभिलेखहरूका लागि अपरिवर्तनीय भण्डारणको आर्किटेक्चर, कार्यान्वयन र व्यवस्थापनमा विस्तृत, प्राविधिक जानकारी प्रदान गर्दछ।

अपरिवर्तनीय भण्डारणको मेकानिक्स

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

अनुपालन मोड बनाम गभर्नेन्स मोड

अपरिवर्तनीयता लागू गर्दा, विशेष गरी AWS S3, Azure Blob, वा S3-कम्प्याटिबल अन-प्रिमाइसेस SANs जस्ता क्लाउड अब्जेक्ट स्टोरेजमा, तपाईंले रिटेन्सन मोडहरू बीचको भिन्नता बुझ्नुपर्छ:

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

अपरिवर्तनीय ब्याकअप पाइपलाइनको आर्किटेक्चर

एक बलियो डाटाबेस अभिलेख आर्किटेक्चरले सक्रिय डाटाबेस सञ्चालनहरूलाई अपरिवर्तनीय अभिलेख तहबाट अलग गर्दछ। तपाईं सक्रिय डाटाबेस फाइलहरूमा (जस्तै SQL Server मा .mdf/.ldf वा PostgreSQL मा pg_data डाइरेक्टरी) अपरिवर्तनीयता लागू गर्न सक्नुहुन्न किनभने डाटाबेसहरूलाई निरन्तर पढ्ने/लेख्ने पहुँच आवश्यक पर्दछ।

यसको सट्टा, अपरिवर्तनीयता निम्नमा लागू गरिन्छ:
१. पूर्ण र भिन्नता ब्याकअप फाइलहरू: डाटाबेसको आधारभूत स्न्यापसटहरू।
२. ट्रान्ज्याक्सन लगहरू / WAL फाइलहरू: पोइन्ट-इन-टाइम रिकभरी (PITR) को लागि आवश्यक डाटाबेस परिवर्तनहरूको निरन्तर प्रवाह।

अपरिवर्तनीयताका लागि भण्डारण लक्ष्यहरू

तपाईं विभिन्न पूर्वाधार तहहरूमा अपरिवर्तनीय भण्डारण लागू गर्न सक्नुहुन्छ:
* क्लाउड अब्जेक्ट स्टोरेज: AWS S3 अब्जेक्ट लक, Azure Blob अपरिवर्तनीय भण्डारण, Google क्लाउड स्टोरेज रिटेन्सन नीतिहरू।
* अन-प्रिमाइसेस अब्जेक्ट स्टोरेज: S3 अब्जेक्ट लक API हरूलाई समर्थन गर्ने MinIO, Cloudian, वा Pure Storage FlashBlade।
* ब्लक/फाइल स्टोरेज: रिड-ओनली स्न्यापसटहरू र प्रत्यायोजित प्रशासनको साथ ZFS, वा लिनक्स फाइल विशेषताहरू।

अपरिवर्तनीय भण्डारण कार्यान्वयन गर्दै: प्राविधिक वाकथ्रुहरू

१. क्लाउड अब्जेक्ट स्टोरेज: AWS S3 अब्जेक्ट लक

AWS मा डाटाबेस डम्प र ट्रान्ज्याक्सन लगहरू सुरक्षित गर्न, तपाईंले बकेट सिर्जना गर्दा अब्जेक्ट लक सक्षम गर्नुपर्छ।

पहिले, अब्जेक्ट लक सक्षम गरिएको बकेट सिर्जना गर्नुहोस्:

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 ले धेरै बलियो सुरक्षा प्रदान गर्दछ। स्न्यापसट लिएर र त्यसमा “होल्ड” राखेर, तपाईं स्न्यापसटलाई नष्ट हुनबाट रोक्न सक्नुहुन्छ।

# ब्याकअप डाटासेटको स्न्यापसट लिनुहोस्
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 बकेटले ३०-दिने अनुपालन लक लागू गर्छ, तर pgBackRest ले repo1-retention-archive को आधारमा १४ दिन पछि WAL फाइलहरू म्याद सकिने र मेटाउने प्रयास गर्छ भने, मेटाउने API कलहरू असफल हुनेछन्। तपाईंले आफ्नो ब्याकअप सफ्टवेयरको रिटेन्सन नीति भण्डारण-स्तरको अपरिवर्तनीय लक भन्दा बढी वा बराबर छ भनी सुनिश्चित गर्नुपर्छ।

Microsoft SQL Server: URL मा ब्याकअप

SQL Server ले सिधै S3-कम्प्याटिबल अब्जेक्ट स्टोरेजमा नेटिभ ब्याकअपहरूलाई समर्थन गर्दछ। तपाईं .bak र .trn फाइलहरू सिधै अपरिवर्तनीय बकेटमा लेख्न SQL Server एजेन्ट कार्य कन्फिगर गर्न सक्नुहुन्छ।

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 मा डाटाबेस ब्याकअप योजना कन्फिगर गर्दा:
१. प्लेटफर्मले स्वचालित रूपमा SQL Server को लागि VSS (भोल्युम स्याडो कपि सर्भिस) वा PostgreSQL को लागि pg_start_backup() API लाई ह्यान्डल गर्छ।
२. यसले डिडुप्लिकेटेड, इन्क्रिप्टेड ब्याकअप डेटालाई सिधै भण्डारण लक्ष्यमा स्ट्रिम गर्दछ।
३. 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 मा सारिएका मासिक पूर्ण ब्याकअपहरू।

४. एयर-ग्याप्ड VPC हरूमा नियमित रिकभरी परीक्षण

अपरिवर्तनीयताले डेटा मेटाउन सकिँदैन भन्ने ग्यारेन्टी दिन्छ, तर यसले डेटा तार्किक भ्रष्टाचारबाट मुक्त छ भन्ने ग्यारेन्टी दिँदैन। तपाईंले आफ्नो अपरिवर्तनीय डाटाबेस अभिलेखहरूको पुनर्स्थापनालाई एक पृथक, एयर-ग्याप्ड VPC वा VLAN मा स्वचालित गर्नुपर्छ। संरचनात्मक अखण्डता प्रमाणित गर्न पुनर्स्थापित डेटामा DBCC CHECKDB (SQL Server) वा pg_amcheck (PostgreSQL) चलाउनुहोस्।

निष्कर्ष

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

रेन्समवेयरलाई परास्त गर्न डाटाबेस अभिलेखका लागि इम्युटेबल स्टोरेजको आर्किटेक्चर निर्माण