র‍্যানসমওয়্যার মোকাবিলায় ডেটাবেস আর্কাইভের জন্য ইমিউটেবল স্টোরেজ আর্কিটেকচার তৈরি

আধুনিক হুমকির প্রেক্ষাপটে, র‍্যানসমওয়্যার এখন কেবল সুযোগসন্ধানী এনক্রিপশন থেকে অত্যন্ত লক্ষ্যভেদী, মাল্টি-এক্সটর্শন ক্যাম্পেইনে বিবর্তিত হয়েছে। অ্যাডভান্সড পারসিস্টেন্ট থ্রেটস (APTs) এবং র‍্যানসমওয়্যার সিন্ডিকেটগুলো এখন তাদের ডওয়েল টাইমের (dwell time) মধ্যে সক্রিয়ভাবে ব্যাকআপ ইনফ্রাস্ট্রাকচার এবং ডাটাবেস আর্কাইভ খুঁজে বের করে। যদি কোনো আক্রমণকারী আপনার প্রাথমিক ডাটাবেসকে আপস (compromise) করে এবং একই সাথে আপনার ব্যাকআপ রিপোজিটরিগুলো মুছে ফেলে বা এনক্রিপ্ট করে, তবে আপনার প্রতিষ্ঠান ভয়াবহ ডাটা হারানোর ঝুঁকির মুখে পড়বে।

ডাটাবেস অ্যাডমিনিস্ট্রেটর (DBAs) এবং ডেভঅপস (DevOps) ইঞ্জিনিয়ারদের জন্য, প্রচলিত ৩-২-১ ব্যাকআপ কৌশল এখন আর যথেষ্ট নয়। ডাটা টিকে থাকার নিশ্চয়তা দিতে, ইনফ্রাস্ট্রাকচার টিমগুলোকে অবশ্যই ৩-২-১-১ নিয়ম গ্রহণ করতে হবে, যেখানে শেষ “১” প্রতিনিধিত্ব করে ইমিউটেবল স্টোরেজ (Immutable Storage) বা অপরিবর্তনীয় স্টোরেজকে।

এই নিবন্ধটি র‍্যানসমওয়্যারের বিরুদ্ধে চূড়ান্ত সুরক্ষা নিশ্চিত করতে ডাটাবেস আর্কাইভের জন্য ইমিউটেবল স্টোরেজ ডিজাইন, বাস্তবায়ন এবং পরিচালনার ওপর একটি বিস্তারিত প্রযুক্তিগত আলোচনা প্রদান করে।

ইমিউটেবল স্টোরেজের কার্যপদ্ধতি

ইমিউটেবল স্টোরেজ একটি রাইট-ওয়ানস-রিড-মেনি (WORM) আর্কিটেকচারের ওপর নির্ভর করে। একবার ডাটা একটি ইমিউটেবল টার্গেটে লেখা হয়ে গেলে, গাণিতিকভাবে নির্ধারিত টাইম লক শেষ না হওয়া পর্যন্ত কোনো ব্যবহারকারী—এমনকি রুট প্রিভিলেজ থাকা অ্যাডমিনিস্ট্রেটর বা আপস হওয়া সার্ভিস অ্যাকাউন্টও—সেটিকে পরিবর্তন, এনক্রিপ্ট বা মুছে ফেলতে পারে না।

কমপ্লায়েন্স মোড বনাম গভর্নেন্স মোড

ইমিউটেবিলিটি বাস্তবায়ন করার সময়, বিশেষ করে AWS S3, Azure Blob বা S3-সামঞ্জস্যপূর্ণ অন-প্রিমিস SAN-এর মতো ক্লাউড অবজেক্ট স্টোরেজে, আপনাকে রিটেনশন মোডগুলোর মধ্যে পার্থক্য বুঝতে হবে:

• গভর্নেন্স মোড (Governance Mode): সাধারণ ব্যবহারকারীদের অবজেক্ট মুছে ফেলা বা পরিবর্তন করা থেকে বিরত রাখে। তবে, নির্দিষ্ট IAM পারমিশন (যেমন: s3:BypassGovernanceRetention) থাকা ব্যবহারকারীরা এই লকটি ওভাররাইড করতে পারেন। এটি পরীক্ষার জন্য উপযোগী কিন্তু র‍্যানসমওয়্যার সুরক্ষার জন্য অপর্যাপ্ত, কারণ আক্রমণকারীরা প্রায়শই ডোমেইন অ্যাডমিন বা রুট লেভেলে প্রিভিলেজ বাড়িয়ে নেয়।
• কমপ্লায়েন্স মোড (Compliance Mode): র‍্যানসমওয়্যার প্রতিরক্ষার জন্য এটি গোল্ড স্ট্যান্ডার্ড। একবার কোনো অবজেক্ট কমপ্লায়েন্স মোডে লক হয়ে গেলে, এর রিটেনশন পিরিয়ড কমানো যায় না এবং AWS রুট অ্যাকাউন্টসহ কেউই অবজেক্টটি মুছে ফেলতে পারে না। এই লকটি স্টোরেজ ক্লাস্টার লেভেলে কার্যকর করা হয়।

একটি ইমিউটেবল ব্যাকআপ পাইপলাইন আর্কিটেকচার

একটি শক্তিশালী ডাটাবেস আর্কাইভিং আর্কিটেকচার সক্রিয় ডাটাবেস অপারেশনগুলোকে ইমিউটেবল আর্কাইভ টিয়ার থেকে আলাদা রাখে। আপনি সক্রিয় ডাটাবেস ফাইলগুলোতে (যেমন SQL Server-এ .mdf/.ldf বা PostgreSQL-এ pg_data ডিরেক্টরি) ইমিউটেবিলিটি প্রয়োগ করতে পারবেন না, কারণ ডাটাবেসের জন্য নিরবচ্ছিন্ন রিড/রাইট অ্যাক্সেস প্রয়োজন।

এর পরিবর্তে, ইমিউটেবিলিটি প্রয়োগ করা হয়:
১. ফুল এবং ডিফারেনশিয়াল ব্যাকআপ ফাইল: ডাটাবেসের বেসলাইন স্ন্যাপশট।
২. ট্রানজ্যাকশন লগ / WAL ফাইল: পয়েন্ট-ইন-টাইম রিকভারি (PITR)-এর জন্য প্রয়োজনীয় ডাটাবেস পরিবর্তনের নিরবচ্ছিন্ন প্রবাহ।

ইমিউটেবিলিটির জন্য স্টোরেজ টার্গেট

আপনি বিভিন্ন ইনফ্রাস্ট্রাকচার টিয়ার জুড়ে ইমিউটেবল স্টোরেজ বাস্তবায়ন করতে পারেন:
* ক্লাউড অবজেক্ট স্টোরেজ: AWS S3 অবজেক্ট লক, Azure Blob ইমিউটেবল স্টোরেজ, গুগল ক্লাউড স্টোরেজ রিটেনশন পলিসি।
* অন-প্রিমিস অবজেক্ট স্টোরেজ: MinIO, Cloudian, বা Pure Storage FlashBlade যা S3 অবজেক্ট লক API সমর্থন করে।
* ব্লক/ফাইল স্টোরেজ: রিড-অনলি স্ন্যাপশট এবং ডেলিগেটেড অ্যাডমিনিস্ট্রেশনসহ 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 অনেক শক্তিশালী সুরক্ষা প্রদান করে। একটি স্ন্যাপশট নিয়ে তাতে “হোল্ড” (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) অর্জনের জন্য, আপনাকে অবশ্যই আপনার ইমিউটেবল স্টোরেজে ট্রানজ্যাকশন লগগুলো ক্রমাগত আর্কাইভ করতে হবে।

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 কলগুলো ব্যর্থ হবে। আপনাকে নিশ্চিত করতে হবে যে আপনার ব্যাকআপ সফটওয়্যারের রিটেনশন পলিসি স্টোরেজ-লেভেল ইমিউটেবল লকের সমান বা তার চেয়ে বেশি।

মাইক্রোসফট এসকিউএল সার্ভার: ব্যাকআপ টু ইউআরএল

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 দিয়ে অটোমেশন এবং অর্কেস্ট্রেশন

ইমিউটেবল রিটেনশন ফ্ল্যাগ পরিচালনা করা, অ্যাক্সেস কি (keys) রোটেট করা এবং কাস্টম স্ক্রিপ্টের মাধ্যমে ডাটাবেস রিটেনশন পলিসি ও স্টোরেজ লকের মধ্যে সিঙ্ক্রোনাইজেশন নিশ্চিত করা অত্যন্ত ত্রুটিপূর্ণ হতে পারে। ক্রন জব বা API কলে একটি ছোট ভুল আপনার আর্কাইভগুলোকে অরক্ষিত করে দিতে পারে অথবা অনাথ (orphaned), লক করা অবজেক্টের কারণে ক্লাউড স্টোরেজের খরচ আকাশচুম্বী করে তুলতে পারে।

CloudSave-এর মতো এন্টারপ্রাইজ ব্যাকআপ প্ল্যাটফর্মগুলো এই আর্কিটেকচারকে সহজ করে। CloudSave নেটিভভাবে AWS S3 অবজেক্ট লক, Azure Blob ইমিউটেবল স্টোরেজ এবং অন-প্রিমিস S3-সামঞ্জস্যপূর্ণ API-এর সাথে ইন্টিগ্রেট করে।

CloudSave-এ ডাটাবেস ব্যাকআপ প্ল্যান কনফিগার করার সময়:
১. প্ল্যাটফর্মটি স্বয়ংক্রিয়ভাবে SQL Server-এর জন্য VSS (Volume Shadow Copy Service) কুইসেন্স বা PostgreSQL-এর জন্য pg_start_backup() API পরিচালনা করে।
২. এটি ডিডুপ্লিকেটেড, এনক্রিপ্ট করা ব্যাকআপ ডাটা সরাসরি স্টোরেজ টার্গেটে স্ট্রিম করে।
৩. CloudSave ডাইনামিকভাবে প্রতি-অবজেক্ট ভিত্তিতে WORM API কল (যেমন PutObjectRetention) প্রয়োগ করে, যা স্টোরেজ লকের সময়কালকে পলিসি-সংজ্ঞায়িত রিটেনশন শিডিউলের সাথে নিখুঁতভাবে সারিবদ্ধ করে।
৪. যদি কোনো আক্রমণকারী CloudSave ম্যানেজমেন্ট কনসোল আপস করে, তবুও তারা ব্যাকআপগুলো মুছে ফেলতে পারবে না, কারণ কমপ্লায়েন্স লকটি ব্যাকআপ সফটওয়্যার দ্বারা নয়, বরং অন্তর্নিহিত স্টোরেজ ইনফ্রাস্ট্রাকচার দ্বারা কার্যকর করা হয়।

ইমিউটেবল ডাটাবেস আর্কাইভের জন্য সর্বোত্তম অনুশীলন

আপনার ইমিউটেবল আর্কিটেকচার সত্যিই স্থিতিস্থাপক কিনা তা নিশ্চিত করতে, নিম্নলিখিত সিস্টেম ইঞ্জিনিয়ারিংয়ের সর্বোত্তম অনুশীলনগুলো মেনে চলুন:

১. কঠোর NTP সিঙ্ক্রোনাইজেশন

ইমিউটেবল লকগুলো গাণিতিকভাবে টাইমস্ট্যাম্পের সাথে আবদ্ধ। যদি আপনার স্টোরেজ অ্যারে বা ব্যাকআপ সার্ভারের NTP (Network Time Protocol) সার্ভিস আপস হয় বা সময় পরিবর্তিত হয়, তবে লকগুলো সময়ের আগেই শেষ হয়ে যেতে পারে বা কখনোই শেষ নাও হতে পারে। নিশ্চিত করুন যে আপনার স্টোরেজ ইনফ্রাস্ট্রাকচার প্রমাণীকৃত, রিডান্ড্যান্ট 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 স্টোরেজ বাস্তবায়ন করা এখন আর ঐচ্ছিক নয়—এটি আধুনিক ডাটাবেস প্রশাসন এবং দুর্যোগ পুনরুদ্ধারের একটি বাধ্যতামূলক স্তম্ভ।