Immutable Database Storage to Defeat Ransomware

ในภูมิทัศน์ภัยคุกคามสมัยใหม่ แรนซัมแวร์ได้วิวัฒนาการจากการเข้ารหัสแบบฉวยโอกาสไปสู่แคมเปญการกรรโชกทรัพย์หลายรูปแบบที่มุ่งเป้าหมายอย่างชัดเจน ภัยคุกคามขั้นสูงที่ติดตัวอยู่ตลอดเวลา (APTs) และกลุ่มแรนซัมแวร์ในปัจจุบันกำลังไล่ล่าโครงสร้างพื้นฐานสำรองข้อมูลและคลังข้อมูลฐานข้อมูลในช่วงเวลาที่พวกมันแฝงตัวอยู่ในระบบ หากผู้โจมตีเจาะระบบฐานข้อมูลหลักของคุณและลบหรือเข้ารหัสที่เก็บข้อมูลสำรองของคุณไปพร้อมกัน องค์กรของคุณจะต้องเผชิญกับการสูญเสียข้อมูลครั้งใหญ่

สำหรับผู้ดูแลระบบฐานข้อมูล (DBAs) และวิศวกร DevOps กลยุทธ์การสำรองข้อมูลแบบ 3-2-1 แบบเดิมนั้นไม่เพียงพออีกต่อไป เพื่อรับประกันความอยู่รอดของข้อมูล ทีมโครงสร้างพื้นฐานต้องนำกฎ 3-2-1-1 มาใช้ โดยที่เลข “1” ตัวสุดท้ายหมายถึง ที่เก็บข้อมูลแบบแก้ไขไม่ได้ (Immutable Storage)

บทความนี้จะให้ข้อมูลเชิงลึกทางเทคนิคที่ครอบคลุมเกี่ยวกับการออกแบบ การนำไปใช้ และการจัดการที่เก็บข้อมูลแบบแก้ไขไม่ได้สำหรับคลังข้อมูลฐานข้อมูล เพื่อให้มั่นใจถึงความยืดหยุ่นต่อแรนซัมแวร์อย่างสมบูรณ์

กลไกของที่เก็บข้อมูลแบบแก้ไขไม่ได้ (Immutable Storage)

ที่เก็บข้อมูลแบบแก้ไขไม่ได้อาศัยสถาปัตยกรรมแบบเขียนครั้งเดียวอ่านได้หลายครั้ง (WORM) เมื่อข้อมูลถูกเขียนลงในเป้าหมายที่แก้ไขไม่ได้แล้ว ข้อมูลนั้นจะไม่สามารถถูกแก้ไข เข้ารหัส หรือลบโดยผู้ใช้คนใดได้ รวมถึงผู้ดูแลระบบที่มีสิทธิ์ระดับ root หรือบัญชีบริการที่ถูกบุกรุก จนกว่าการล็อกเวลาที่บังคับใช้ทางคณิตศาสตร์จะหมดอายุลง

โหมดการปฏิบัติตามข้อกำหนด (Compliance Mode) กับ โหมดการกำกับดูแล (Governance Mode)

เมื่อนำความสามารถในการแก้ไขไม่ได้มาใช้ โดยเฉพาะในที่เก็บข้อมูลแบบ Object Storage บนคลาวด์ เช่น AWS S3, Azure Blob หรือ SAN ภายในองค์กรที่รองรับ S3 คุณต้องเข้าใจความแตกต่างระหว่างโหมดการเก็บรักษา:

โหมดการกำกับดูแล (Governance Mode): ป้องกันไม่ให้ผู้ใช้ทั่วไปลบหรือเปลี่ยนแปลงวัตถุ อย่างไรก็ตาม ผู้ใช้ที่มีสิทธิ์ IAM เฉพาะ (เช่น s3:BypassGovernanceRetention) สามารถข้ามการล็อกได้ ซึ่งมีประโยชน์สำหรับการทดสอบ แต่ ไม่เพียงพอสำหรับการป้องกันแรนซัมแวร์ เนื่องจากผู้โจมตีมักจะยกระดับสิทธิ์เป็นผู้ดูแลระบบโดเมนหรือ root
โหมดการปฏิบัติตามข้อกำหนด (Compliance Mode): มาตรฐานทองคำสำหรับการป้องกันแรนซัมแวร์ เมื่อวัตถุถูกล็อกในโหมดนี้ ระยะเวลาการเก็บรักษาจะไม่สามารถลดลงได้ และวัตถุนั้นจะไม่สามารถถูกลบโดย ใครก็ตาม รวมถึงบัญชี root ของ AWS การล็อกจะถูกบังคับใช้ในระดับคลัสเตอร์ของที่เก็บข้อมูล

การออกแบบไปป์ไลน์การสำรองข้อมูลแบบแก้ไขไม่ได้

สถาปัตยกรรมการจัดเก็บข้อมูลฐานข้อมูลที่แข็งแกร่งจะแยกการทำงานของฐานข้อมูลที่ใช้งานอยู่ (Active) ออกจากชั้นคลังข้อมูลแบบแก้ไขไม่ได้ คุณไม่สามารถใช้คุณสมบัติการแก้ไขไม่ได้กับไฟล์ฐานข้อมูลที่ใช้งานอยู่ (เช่น .mdf/.ldf ใน SQL Server หรือไดเรกทอรี pg_data ใน PostgreSQL) เนื่องจากฐานข้อมูลต้องการการเข้าถึงแบบอ่าน/เขียนตลอดเวลา

แต่จะใช้คุณสมบัตินี้กับ:
1. ไฟล์สำรองข้อมูลแบบเต็มและแบบส่วนต่าง (Full and Differential Backup Files): สแนปชอตพื้นฐานของฐานข้อมูล
2. บันทึกธุรกรรม / ไฟล์ WAL (Transaction Logs / WAL Files): กระแสการเปลี่ยนแปลงของฐานข้อมูลอย่างต่อเนื่องที่จำเป็นสำหรับการกู้คืน ณ จุดเวลาใดเวลาหนึ่ง (PITR)

เป้าหมายการจัดเก็บข้อมูลสำหรับความสามารถในการแก้ไขไม่ได้

คุณสามารถใช้ที่เก็บข้อมูลแบบแก้ไขไม่ได้ในระดับโครงสร้างพื้นฐานต่างๆ ได้:
* Cloud Object Storage: AWS S3 Object Lock, Azure Blob Immutable Storage, Google Cloud Storage Retention Policies
* On-Premises Object Storage: MinIO, Cloudian หรือ Pure Storage FlashBlade ที่รองรับ S3 Object Lock APIs
* Block/File Storage: ZFS พร้อมสแนปชอตแบบอ่านอย่างเดียวและการมอบหมายสิทธิ์การดูแลระบบ หรือแอตทริบิวต์ไฟล์ของ Linux

การนำที่เก็บข้อมูลแบบแก้ไขไม่ได้ไปใช้: คำแนะนำทางเทคนิค

1. Cloud Object Storage: AWS S3 Object Lock

เพื่อปกป้องไฟล์ดัมพ์ฐานข้อมูลและบันทึกธุรกรรมใน AWS คุณต้องเปิดใช้งาน Object Lock ในขณะที่สร้าง Bucket

ขั้นแรก สร้าง Bucket โดยเปิดใช้งาน Object Lock:

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

ถัดไป กำหนดค่านโยบายการเก็บรักษาเริ่มต้น สำหรับคลังข้อมูลฐานข้อมูล การล็อกแบบ Compliance 30 วันเป็นมาตรฐานพื้นฐาน เพื่อให้มั่นใจว่าคุณมีการสำรองข้อมูลที่ไม่สามารถเปลี่ยนแปลงได้เป็นเวลาหนึ่งเดือน

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

เมื่อสคริปต์หรือเอเจนต์สำรองข้อมูลฐานข้อมูลของคุณส่งไฟล์ไปยัง Bucket นี้ S3 จะคำนวณ Retain Until Date โดยอัตโนมัติตามเวลาที่สร้างวัตถุบวกเพิ่มอีก 30 วัน

2. การแก้ไขไม่ได้ภายในองค์กร: ZFS และแอตทริบิวต์ Linux

หากคุณกำลังจัดเก็บฐานข้อมูลไปยังเซิร์ฟเวอร์สำรองข้อมูล Linux ภายในองค์กร คุณสามารถบรรลุความสามารถในการแก้ไขไม่ได้แบบจำลองโดยใช้คำสั่ง chattr หรือความสามารถที่แท้จริงโดยใช้ ZFS snapshots

การใช้ Linux chattr:
แฟล็ก +i (immutable) ป้องกันการแก้ไขไฟล์ การลบ หรือการเปลี่ยนชื่อ

# Dump the database
pg_dump -U postgres -Fc mydb > /backups/mydb_$(date +%F).dump

# Make the backup immutable
sudo chattr +i /backups/mydb_$(date +%F).dump

# Verify the attribute
lsattr /backups/mydb_$(date +%F).dump
# Output: ----i---------e------- /backups/mydb_2023-10-27.dump

หมายเหตุ: แม้ว่า chattr จะหยุดสคริปต์แรนซัมแวร์พื้นฐานได้ แต่ผู้โจมตีที่มีทักษะสูงซึ่งมีสิทธิ์ root สามารถรัน chattr -i ได้ง่ายๆ ดังนั้นจึงต้องใช้ร่วมกับการควบคุม RBAC ที่เข้มงวดและเครือข่ายสำรองข้อมูลที่แยกส่วน

การใช้ ZFS Snapshots:
ZFS ให้การป้องกันที่แข็งแกร่งกว่ามาก โดยการทำสแนปชอตและวาง “hold” ไว้บนนั้น คุณจะป้องกันไม่ให้สแนปชอตถูกทำลาย

# Take a snapshot of the backup dataset
zfs snapshot tank/db_backups@archive_$(date +%F)

# Place a hold on the snapshot to prevent deletion
zfs hold keep_30_days tank/db_backups@archive_$(date +%F)

# Even root cannot destroy this snapshot without releasing the hold
zfs destroy tank/db_backups@archive_$(date +%F)
# Output: cannot destroy 'tank/db_backups@archive_...': dataset is busy

กลยุทธ์การจัดเก็บข้อมูลเฉพาะสำหรับฐานข้อมูล

เพื่อให้บรรลุการกู้คืน ณ จุดเวลาใดเวลาหนึ่ง (PITR) คุณต้องจัดเก็บบันทึกธุรกรรมไปยังที่เก็บข้อมูลแบบแก้ไขไม่ได้ของคุณอย่างต่อเนื่อง

การจัดเก็บ WAL ของ PostgreSQL ด้วย pgBackRest

pgBackRest เป็นเครื่องมือสำรองข้อมูลที่เชื่อถือได้สูงสำหรับ PostgreSQL ซึ่งรองรับที่เก็บข้อมูลที่เข้ากันได้กับ S3 โดยกำเนิด เพื่อปกป้อง Write-Ahead Logs (WAL) ของคุณ ให้กำหนดค่า pgBackRest ให้ส่งข้อมูลโดยตรงไปยัง S3 Bucket แบบแก้ไขไม่ได้ของคุณ

ในไฟล์ 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

# Ensure retention aligns with your S3 Object Lock configuration
repo1-retention-full=2
repo1-retention-archive=2

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

ข้อควรพิจารณาที่สำคัญ: หาก S3 Bucket ของคุณบังคับใช้การล็อกแบบ Compliance 30 วัน แต่ pgBackRest พยายามหมดอายุและลบไฟล์ WAL หลังจาก 14 วันตาม repo1-retention-archive การเรียก API ลบข้อมูลจะล้มเหลว คุณต้องตรวจสอบให้แน่ใจว่านโยบายการเก็บรักษาของซอฟต์แวร์สำรองข้อมูลของคุณมีระยะเวลามากกว่าหรือเท่ากับการล็อกแบบแก้ไขไม่ได้ในระดับที่เก็บข้อมูล

Microsoft SQL Server: การสำรองข้อมูลไปยัง URL

SQL Server รองรับการสำรองข้อมูลโดยตรงไปยัง Object Storage ที่เข้ากันได้กับ S3 คุณสามารถกำหนดค่า SQL Server Agent job เพื่อเขียนไฟล์ .bak และ .trn ไปยัง Bucket แบบแก้ไขไม่ได้โดยตรง

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 job หรือ API call อาจทำให้คลังข้อมูลของคุณเปิดเผยต่อความเสี่ยง หรือส่งผลให้ค่าใช้จ่ายในการจัดเก็บข้อมูลบนคลาวด์พุ่งสูงขึ้นเนื่องจากวัตถุที่ถูกล็อกและถูกทิ้งร้าง

แพลตฟอร์มสำรองข้อมูลระดับองค์กรอย่าง CloudSave ช่วยลดความซับซ้อนของสถาปัตยกรรมนี้ CloudSave ผสานรวมกับ AWS S3 Object Lock, Azure Blob Immutable Storage และ API ที่เข้ากันได้กับ S3 ภายในองค์กรโดยกำเนิด

เมื่อกำหนดค่าแผนการสำรองข้อมูลฐานข้อมูลใน CloudSave:
1. แพลตฟอร์มจะจัดการ VSS (Volume Shadow Copy Service) quiescence สำหรับ SQL Server หรือ pg_start_backup() API สำหรับ PostgreSQL โดยอัตโนมัติ
2. มันจะสตรีมข้อมูลสำรองที่ถูกลดความซ้ำซ้อนและเข้ารหัสไปยังเป้าหมายการจัดเก็บข้อมูลโดยตรง
3. CloudSave จะใช้การเรียก WORM API (เช่น PutObjectRetention) แบบไดนามิกในระดับวัตถุ ซึ่งสอดคล้องกับระยะเวลาการล็อกที่เก็บข้อมูลกับตารางการเก็บรักษาที่กำหนดไว้ในนโยบายอย่างสมบูรณ์แบบ
4. หากผู้โจมตีเจาะคอนโซลการจัดการของ CloudSave ได้ พวกเขาก็ยังไม่สามารถลบข้อมูลสำรองได้ เนื่องจากการล็อกแบบ Compliance ถูกบังคับใช้โดยโครงสร้างพื้นฐานการจัดเก็บข้อมูลเบื้องล่าง ไม่ใช่โดยซอฟต์แวร์สำรองข้อมูล

แนวทางปฏิบัติที่ดีที่สุดสำหรับคลังข้อมูลฐานข้อมูลแบบแก้ไขไม่ได้

เพื่อให้แน่ใจว่าสถาปัตยกรรมแบบแก้ไขไม่ได้ของคุณมีความยืดหยุ่นอย่างแท้จริง ให้ปฏิบัติตามแนวทางปฏิบัติทางวิศวกรรมระบบที่ดีที่สุดต่อไปนี้:

1. การซิงโครไนซ์ NTP ที่เข้มงวด

การล็อกแบบแก้ไขไม่ได้จะผูกติดอยู่กับเวลา หากบริการ NTP (Network Time Protocol) บนอาร์เรย์การจัดเก็บข้อมูลหรือเซิร์ฟเวอร์สำรองข้อมูลของคุณถูกบุกรุกหรือคลาดเคลื่อน อาจทำให้การล็อกหมดอายุก่อนกำหนดหรือไม่มีวันหมดอายุ ตรวจสอบให้แน่ใจว่าโครงสร้างพื้นฐานการจัดเก็บข้อมูลของคุณใช้แหล่ง NTP ที่ผ่านการตรวจสอบความถูกต้องและซ้ำซ้อน

2. การแยกบทบาท IAM และข้อมูลประจำตัว

ข้อมูลประจำตัวที่ใช้เขียนไปยัง Bucket แบบแก้ไขไม่ได้ต้องมีสิทธิ์ 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. การกำหนดขนาดระยะเวลาการเก็บรักษา

อย่าตั้งค่าการล็อกแบบ Compliance เป็นระยะเวลานานเกินไป (เช่น 7 ปีเพื่อการปฏิบัติตามข้อกำหนด) ในชั้นการกู้คืนที่รวดเร็วหลักของคุณ ฐานข้อมูลสร้างข้อมูล WAL/transaction log จำนวนมหาศาล การล็อกข้อมูลนี้ไว้นานหลายปีจะส่งผลให้ค่าใช้จ่ายในการจัดเก็บข้อมูลเพิ่มขึ้นแบบทวีคูณ
ให้ใช้วิธีการแบบแบ่งระดับแทน:
* ชั้นการกู้คืนเชิงปฏิบัติการ (Operational Recovery Tier): เก็บรักษาแบบแก้ไขไม่ได้ 14 ถึง 30 วันสำหรับไฟล์ Full และ Logs
* ชั้นคลังข้อมูลระยะยาว (Long-Term Archival Tier): ย้ายการสำรองข้อมูลเต็มรูปแบบรายเดือนไปยัง Glacier/Deep Archive พร้อม Vault Lock เป็นเวลา 1-7 ปี

4. การทดสอบการกู้คืนเป็นประจำใน Air-Gapped VPCs

ความสามารถในการแก้ไขไม่ได้รับประกันว่าข้อมูลจะไม่ถูกลบ แต่ไม่ได้รับประกันว่าข้อมูลจะปราศจากความเสียหายเชิงตรรกะ คุณต้องทำให้การกู้คืนคลังข้อมูลฐานข้อมูลแบบแก้ไขไม่ได้ของคุณเป็นอัตโนมัติใน VPC หรือ VLAN ที่แยกส่วน (Air-gapped) รัน DBCC CHECKDB (SQL Server) หรือ pg_amcheck (PostgreSQL) บนข้อมูลที่กู้คืนเพื่อตรวจสอบความสมบูรณ์ของโครงสร้าง

บทสรุป

การป้องกันแรนซัมแวร์คือการฝึกฝนโดยตั้งสมมติฐานว่าระบบถูกเจาะแล้ว ในขณะที่การแจ้งเตือนดังขึ้นใน SIEM ของคุณ ผู้โจมตีอาจพยายามเจาะโครงสร้างพื้นฐานการสำรองข้อมูลของคุณไปแล้ว การออกแบบคลังข้อมูลฐานข้อมูลของคุณโดยใช้ที่เก็บข้อมูลแบบแก้ไขไม่ได้ในโหมด Compliance จะทำให้ผู้โจมตีสูญเสียอำนาจต่อรองหลัก ไม่ว่าคุณจะใช้ API คลาวด์แบบเนทีฟ, ZFS holds หรือแพลตฟอร์มการจัดการระดับองค์กรอย่าง CloudSave การใช้ที่เก็บข้อมูลแบบ WORM ไม่ใช่ทางเลือกอีกต่อไป แต่เป็นเสาหลักที่จำเป็นของการดูแลระบบฐานข้อมูลและการกู้คืนจากภัยพิบัติในยุคปัจจุบัน