Categories
Database Backup

** Learn how to protect enterprise database archives from ransomware using immutable storage. Discover technical implementation steps for AWS S3 Object Lock, ZFS, PostgreSQL, and SQL Server.

Dalam lanskap ancaman modern, ransomware telah berevolusi dari enkripsi oportunistik menjadi kampanye multi-pemerasan yang sangat terarah. Advanced Persistent Threats (APT) dan sindikat ransomware kini secara aktif memburu infrastruktur cadangan dan arsip basis data selama masa tinggal mereka. Jika penyerang mengompromikan basis data utama Anda dan secara bersamaan menghapus atau mengenkripsi repositori cadangan Anda, organisasi Anda akan menghadapi kehilangan data yang katastrofik.

Bagi Administrator Basis Data (DBA) dan insinyur DevOps, strategi cadangan 3-2-1 tradisional tidak lagi memadai. Untuk menjamin kelangsungan data, tim infrastruktur harus mengadopsi aturan 3-2-1-1, di mana “1” terakhir mewakili penyimpanan yang tidak dapat diubah (immutable storage).

Artikel ini memberikan pembahasan teknis yang komprehensif mengenai perancangan, penerapan, dan pengelolaan penyimpanan immutable untuk arsip basis data guna memastikan ketahanan ransomware yang mutlak.

Mekanisme Penyimpanan Immutable

Penyimpanan immutable mengandalkan arsitektur Write-Once-Read-Many (WORM). Setelah data ditulis ke target immutable, data tersebut tidak dapat dimodifikasi, dienkripsi, atau dihapus oleh pengguna mana pun—termasuk administrator dengan hak akses root atau akun layanan yang disusupi—sampai kunci waktu yang diberlakukan secara matematis berakhir.

Mode Kepatuhan (Compliance) vs. Mode Tata Kelola (Governance)

Saat menerapkan immutability, khususnya pada penyimpanan objek cloud seperti AWS S3, Azure Blob, atau SAN on-premise yang kompatibel dengan S3, Anda harus memahami perbedaan antara mode retensi:

  • Mode Tata Kelola (Governance Mode): Mencegah pengguna standar menghapus atau mengubah objek. Namun, pengguna dengan izin IAM tertentu (misalnya, s3:BypassGovernanceRetention) dapat mengabaikan kunci tersebut. Ini berguna untuk pengujian tetapi tidak cukup untuk perlindungan ransomware, karena penyerang sering kali meningkatkan hak akses menjadi admin domain atau root.
  • Mode Kepatuhan (Compliance Mode): Standar emas untuk pertahanan ransomware. Setelah objek dikunci dalam Mode Kepatuhan, periode retensinya tidak dapat dipersingkat, dan objek tersebut tidak dapat dihapus oleh siapa pun, termasuk akun root AWS. Kunci diberlakukan di tingkat klaster penyimpanan.

Merancang Jalur Cadangan Immutable

Arsitektur pengarsipan basis data yang kuat memisahkan operasi basis data aktif dari tingkat arsip immutable. Anda tidak dapat menerapkan immutability pada file basis data aktif (seperti .mdf/.ldf di SQL Server atau direktori pg_data di PostgreSQL) karena basis data memerlukan akses baca/tulis yang konstan.

Sebaliknya, immutability diterapkan pada:
1. File Cadangan Penuh dan Diferensial: Snapshot dasar dari basis data.
2. Log Transaksi / File WAL: Aliran perubahan basis data berkelanjutan yang diperlukan untuk Point-in-Time Recovery (PITR).

Target Penyimpanan untuk Immutability

Anda dapat menerapkan penyimpanan immutable di berbagai tingkat infrastruktur:
* Penyimpanan Objek Cloud: AWS S3 Object Lock, Azure Blob Immutable Storage, Kebijakan Retensi Google Cloud Storage.
* Penyimpanan Objek On-Premise: MinIO, Cloudian, atau Pure Storage FlashBlade yang mendukung API S3 Object Lock.
* Penyimpanan Blok/File: ZFS dengan snapshot read-only dan administrasi yang didelegasikan, atau atribut file Linux.

Menerapkan Penyimpanan Immutable: Panduan Teknis

1. Penyimpanan Objek Cloud: AWS S3 Object Lock

Untuk melindungi dump basis data dan log transaksi di AWS, Anda harus mengaktifkan Object Lock pada saat pembuatan bucket.

Pertama, buat bucket dengan Object Lock diaktifkan:

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

Selanjutnya, konfigurasikan kebijakan retensi default. Untuk arsip basis data, kunci kepatuhan 30 hari adalah standar dasar, memastikan Anda memiliki cadangan yang tidak dapat diubah selama sebulan.

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

Ketika skrip atau agen cadangan basis data Anda mengirim file ke bucket ini, S3 secara otomatis menghitung Retain Until Date berdasarkan stempel waktu pembuatan objek ditambah 30 hari.

2. Immutability On-Premise: ZFS dan Atribut Linux

Jika Anda mengarsipkan basis data ke server cadangan Linux on-premise, Anda dapat mencapai pseudo-immutability menggunakan perintah chattr, atau immutability sejati menggunakan snapshot ZFS.

Menggunakan chattr Linux:
Flag +i (immutable) mencegah modifikasi, penghapusan, atau penggantian nama file.

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

# Buat cadangan menjadi immutable
sudo chattr +i /backups/mydb_$(date +%F).dump

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

Catatan: Meskipun chattr menghentikan skrip ransomware dasar, penyerang canggih dengan akses root dapat dengan mudah menjalankan chattr -i. Oleh karena itu, ini harus dikombinasikan dengan RBAC yang ketat dan jaringan cadangan yang terisolasi.

Menggunakan Snapshot ZFS:
ZFS memberikan pertahanan yang jauh lebih kuat. Dengan mengambil snapshot dan menempatkan “hold” padanya, Anda mencegah snapshot tersebut dihancurkan.

# Ambil snapshot dari dataset cadangan
zfs snapshot tank/db_backups@archive_$(date +%F)

# Tempatkan hold pada snapshot untuk mencegah penghapusan
zfs hold keep_30_days tank/db_backups@archive_$(date +%F)

# Bahkan root tidak dapat menghancurkan snapshot ini tanpa melepaskan hold
zfs destroy tank/db_backups@archive_$(date +%F)
# Output: cannot destroy 'tank/db_backups@archive_...': dataset is busy

Strategi Pengarsipan Khusus Basis Data

Untuk mencapai Point-in-Time Recovery (PITR), Anda harus terus mengarsipkan log transaksi ke penyimpanan immutable Anda.

Pengarsipan WAL PostgreSQL dengan pgBackRest

pgBackRest adalah alat cadangan yang sangat andal untuk PostgreSQL yang secara native mendukung penyimpanan yang kompatibel dengan S3. Untuk melindungi Write-Ahead Logs (WAL) Anda, konfigurasikan pgBackRest untuk mengirim langsung ke bucket S3 immutable Anda.

Dalam pgbackrest.conf Anda:

[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

# Pastikan retensi selaras dengan konfigurasi S3 Object Lock Anda
repo1-retention-full=2
repo1-retention-archive=2

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

Pertimbangan Penting: Jika bucket S3 Anda memberlakukan kunci Kepatuhan 30 hari, tetapi pgBackRest mencoba untuk mengakhiri dan menghapus file WAL setelah 14 hari berdasarkan repo1-retention-archive, panggilan API penghapusan akan gagal. Anda harus memastikan kebijakan retensi perangkat lunak cadangan Anda lebih besar dari atau sama dengan kunci immutable tingkat penyimpanan.

Microsoft SQL Server: Cadangan ke URL

SQL Server mendukung cadangan native langsung ke penyimpanan objek yang kompatibel dengan S3. Anda dapat mengonfigurasi pekerjaan SQL Server Agent untuk menulis file .bak dan .trn langsung ke bucket immutable.

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

Otomatisasi dan Orkestrasi dengan CloudSave

Mengelola flag retensi immutable, merotasi kunci akses, dan memastikan sinkronisasi antara kebijakan retensi basis data dan kunci penyimpanan melalui skrip kustom sangat rentan terhadap kesalahan. Satu kesalahan konfigurasi dalam cron job atau panggilan API dapat membuat arsip Anda terekspos atau mengakibatkan biaya penyimpanan cloud melonjak karena objek terkunci yang tidak terkelola.

Platform cadangan perusahaan seperti CloudSave menyederhanakan arsitektur ini. CloudSave secara native terintegrasi dengan AWS S3 Object Lock, Azure Blob Immutable Storage, dan API yang kompatibel dengan S3 on-premise.

Saat mengonfigurasi rencana cadangan basis data di CloudSave:
1. Platform secara otomatis menangani quiescence VSS (Volume Shadow Copy Service) untuk SQL Server atau API pg_start_backup() untuk PostgreSQL.
2. Platform mengalirkan data cadangan yang telah dideduplikasi dan dienkripsi langsung ke target penyimpanan.
3. CloudSave secara dinamis menerapkan panggilan API WORM (misalnya, PutObjectRetention) berdasarkan per-objek, menyelaraskan durasi kunci penyimpanan dengan jadwal retensi yang ditentukan kebijakan.
4. Jika penyerang mengompromikan konsol manajemen CloudSave, mereka tetap tidak dapat menghapus cadangan, karena kunci kepatuhan diberlakukan oleh infrastruktur penyimpanan yang mendasarinya, bukan oleh perangkat lunak cadangan.

Praktik Terbaik untuk Arsip Basis Data Immutable

Untuk memastikan arsitektur immutable Anda benar-benar tangguh, patuhi praktik terbaik rekayasa sistem berikut:

1. Sinkronisasi NTP yang Ketat

Kunci immutable terikat secara matematis pada stempel waktu. Jika layanan NTP (Network Time Protocol) pada array penyimpanan atau server cadangan Anda disusupi atau melenceng, hal itu dapat menyebabkan kunci kedaluwarsa sebelum waktunya atau tidak pernah kedaluwarsa sama sekali. Pastikan infrastruktur penyimpanan Anda menggunakan sumber NTP yang terautentikasi dan redundan.

2. Isolasi Peran dan Kredensial IAM

Kredensial yang digunakan untuk menulis ke bucket immutable hanya boleh memiliki izin s3:PutObject dan s3:PutObjectRetention. Kredensial tersebut tidak boleh memiliki izin s3:DeleteObject atau s3:PutBucketObjectLockConfiguration.

Contoh kebijakan IAM dengan hak akses minimum untuk agen cadangan basis data:

{
    "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. Menentukan Ukuran Periode Retensi

Jangan mengatur kunci kepatuhan untuk periode yang terlalu lama (misalnya, 7 tahun untuk kepatuhan) pada tingkat pemulihan cepat utama Anda. Basis data menghasilkan data log WAL/transaksi dalam jumlah besar. Mengunci data ini selama bertahun-tahun akan mengakibatkan pertumbuhan biaya penyimpanan yang eksponensial.
Sebaliknya, gunakan pendekatan bertingkat:
* Tingkat Pemulihan Operasional: 14 hingga 30 hari retensi immutable untuk Cadangan Penuh dan Log.
* Tingkat Pengarsipan Jangka Panjang: Cadangan penuh bulanan dipindahkan ke Glacier/Deep Archive dengan Vault Lock selama 1-7 tahun.

4. Pengujian Pemulihan Reguler di VPC Air-Gapped

Immutability menjamin data tidak dapat dihapus, tetapi tidak menjamin data bebas dari korupsi logis. Anda harus mengotomatiskan pemulihan arsip basis data immutable Anda ke dalam VPC atau VLAN yang terisolasi dan air-gapped. Jalankan DBCC CHECKDB (SQL Server) atau pg_amcheck (PostgreSQL) pada data yang dipulihkan untuk memverifikasi integritas struktural.

Kesimpulan

Pertahanan ransomware adalah latihan dalam mengasumsikan adanya pelanggaran. Pada saat peringatan muncul di SIEM Anda, pelaku ancaman kemungkinan besar sudah mencoba mengompromikan infrastruktur cadangan Anda. Dengan merancang arsip basis data Anda menggunakan penyimpanan immutable dalam Mode Kepatuhan, Anda melucuti daya tawar utama penyerang. Baik Anda menggunakan API cloud native, ZFS hold, atau platform orkestrasi perusahaan seperti CloudSave, menerapkan penyimpanan WORM bukan lagi pilihan—itu adalah pilar wajib dari administrasi basis data modern dan pemulihan bencana.

Kategori