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 landskap ancaman moden, perisian tebusan (ransomware) telah berkembang daripada penyulitan oportunistik kepada kempen berbilang peras ugut yang sangat disasarkan. Ancaman Berterusan Lanjutan (APT) dan sindiket perisian tebusan kini secara aktif memburu infrastruktur sandaran dan arkib pangkalan data semasa tempoh pencerobohan mereka. Jika penyerang mengkompromi pangkalan data utama anda dan pada masa yang sama memadam atau menyulitkan repositori sandaran anda, organisasi anda akan menghadapi kehilangan data yang membawa bencana.

Bagi Pentadbir Pangkalan Data (DBA) dan jurutera DevOps, strategi sandaran 3-2-1 tradisional tidak lagi mencukupi. Untuk menjamin kemandirian data, pasukan infrastruktur mesti menggunakan peraturan 3-2-1-1, di mana “1” yang terakhir mewakili storan tidak boleh ubah (immutable storage).

Artikel ini menyediakan analisis teknikal yang komprehensif tentang cara mereka bentuk, melaksanakan dan mengurus storan tidak boleh ubah untuk arkib pangkalan data bagi memastikan daya tahan mutlak terhadap perisian tebusan.

Mekanisme Storan Tidak Boleh Ubah

Storan tidak boleh ubah bergantung pada seni bina Tulis-Sekali-Baca-Banyak (WORM). Sebaik sahaja data ditulis ke sasaran yang tidak boleh ubah, ia tidak boleh diubah suai, disulitkan atau dipadamkan oleh mana-mana pengguna—termasuk pentadbir dengan keistimewaan root atau akaun perkhidmatan yang dikompromi—sehingga kunci masa yang dikuatkuasakan secara matematik tamat tempoh.

Mod Pematuhan lwn. Mod Tadbir Urus

Apabila melaksanakan ketidakbolehubahan, terutamanya dalam storan objek awan seperti AWS S3, Azure Blob atau SAN dalam premis yang serasi dengan S3, anda mesti memahami perbezaan antara mod pengekalan:

  • Mod Tadbir Urus (Governance Mode): Menghalang pengguna biasa daripada memadam atau mengubah objek. Walau bagaimanapun, pengguna dengan kebenaran IAM tertentu (contohnya, s3:BypassGovernanceRetention) boleh mengatasi kunci tersebut. Ini berguna untuk ujian tetapi tidak mencukupi untuk perlindungan perisian tebusan, kerana penyerang sering meningkatkan keistimewaan kepada pentadbir domain atau root.
  • Mod Pematuhan (Compliance Mode): Standard emas untuk pertahanan perisian tebusan. Sebaik sahaja objek dikunci dalam Mod Pematuhan, tempoh pengekalan tidak boleh dipendekkan, dan objek tersebut tidak boleh dipadamkan oleh sesiapa pun, termasuk akaun root AWS. Kunci dikuatkuasakan pada peringkat kluster storan.

Mereka Bentuk Talian Paip Sandaran Tidak Boleh Ubah

Seni bina pengarkiban pangkalan data yang teguh memisahkan operasi pangkalan data aktif daripada lapisan arkib tidak boleh ubah. Anda tidak boleh menggunakan ketidakbolehubahan pada fail pangkalan data aktif (seperti .mdf/.ldf dalam SQL Server atau direktori pg_data dalam PostgreSQL) kerana pangkalan data memerlukan akses baca/tulis yang berterusan.

Sebaliknya, ketidakbolehubahan digunakan pada:
1. Fail Sandaran Penuh dan Berbeza: Syot kilat asas pangkalan data.
2. Log Transaksi / Fail WAL: Aliran berterusan perubahan pangkalan data yang diperlukan untuk Pemulihan Titik-dalam-Masa (PITR).

Sasaran Storan untuk Ketidakbolehubahan

Anda boleh melaksanakan storan tidak boleh ubah merentas lapisan infrastruktur yang berbeza:
* Storan Objek Awan: AWS S3 Object Lock, Azure Blob Immutable Storage, Google Cloud Storage Retention Policies.
* Storan Objek Dalam Premis: MinIO, Cloudian, atau Pure Storage FlashBlade yang menyokong API S3 Object Lock.
* Storan Blok/Fail: ZFS dengan syot kilat baca-sahaja dan pentadbiran yang diwakilkan, atau atribut fail Linux.

Melaksanakan Storan Tidak Boleh Ubah: Panduan Teknikal

1. Storan Objek Awan: AWS S3 Object Lock

Untuk melindungi lambakan pangkalan data dan log transaksi dalam AWS, anda mesti mendayakan Object Lock semasa penciptaan baldi (bucket).

Pertama, cipta baldi dengan Object Lock didayakan:

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

Seterusnya, konfigurasikan dasar pengekalan lalai. Untuk arkib pangkalan data, kunci pematuhan 30 hari adalah garis dasar standard, memastikan anda mempunyai sandaran yang tidak boleh 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
            }
        }
    }'

Apabila skrip atau ejen sandaran pangkalan data anda menolak fail ke baldi ini, S3 secara automatik mengira Retain Until Date berdasarkan cap masa penciptaan objek ditambah 30 hari.

2. Ketidakbolehubahan Dalam Premis: ZFS dan Atribut Linux

Jika anda mengarkibkan pangkalan data ke pelayan sandaran Linux dalam premis, anda boleh mencapai pseudo-ketidakbolehubahan menggunakan arahan chattr, atau ketidakbolehubahan sebenar menggunakan syot kilat ZFS.

Menggunakan Linux chattr:
Bendera +i (tidak boleh ubah) menghalang pengubahsuaian, pemadaman atau penamaan semula fail.

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

# Jadikan sandaran tidak boleh ubah
sudo chattr +i /backups/mydb_$(date +%F).dump

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

Nota: Walaupun chattr menghentikan skrip perisian tebusan asas, penyerang yang canggih dengan akses root boleh menjalankan chattr -i dengan mudah. Oleh itu, ini mesti digabungkan dengan RBAC yang ketat dan rangkaian sandaran terpencil.

Menggunakan Syot Kilat ZFS:
ZFS menyediakan pertahanan yang jauh lebih kuat. Dengan mengambil syot kilat dan meletakkan “tahan” (hold) padanya, anda menghalang syot kilat daripada dimusnahkan.

# Ambil syot kilat set data sandaran
zfs snapshot tank/db_backups@archive_$(date +%F)

# Letakkan tahan pada syot kilat untuk menghalang pemadaman
zfs hold keep_30_days tank/db_backups@archive_$(date +%F)

# Malah root tidak boleh memusnahkan syot kilat ini tanpa melepaskan tahan
zfs destroy tank/db_backups@archive_$(date +%F)
# Output: cannot destroy 'tank/db_backups@archive_...': dataset is busy

Strategi Pengarkiban Khusus Pangkalan Data

Untuk mencapai Pemulihan Titik-dalam-Masa (PITR), anda mesti mengarkibkan log transaksi secara berterusan ke storan tidak boleh ubah anda.

Pengarkiban WAL PostgreSQL dengan pgBackRest

pgBackRest ialah alat sandaran yang sangat boleh dipercayai untuk PostgreSQL yang menyokong storan serasi S3 secara asli. Untuk melindungi Log Tulis-Dahulu (WAL) anda, konfigurasikan pgBackRest untuk menolak terus ke baldi S3 tidak boleh ubah 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 pengekalan 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 baldi S3 anda menguatkuasakan kunci Pematuhan 30 hari, tetapi pgBackRest cuba menamatkan tempoh dan memadam fail WAL selepas 14 hari berdasarkan repo1-retention-archive, panggilan API pemadaman akan gagal. Anda mesti memastikan dasar pengekalan perisian sandaran anda adalah lebih besar daripada atau sama dengan kunci tidak boleh ubah peringkat storan.

Microsoft SQL Server: Sandaran ke URL

SQL Server menyokong sandaran asli terus ke storan objek serasi S3. Anda boleh mengkonfigurasi kerja Ejen SQL Server untuk menulis fail .bak dan .trn terus ke baldi tidak boleh ubah.

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

Mengautomasikan dan Mengorkestra dengan CloudSave

Mengurus bendera pengekalan tidak boleh ubah, memutar kunci akses, dan memastikan penyegerakan antara dasar pengekalan pangkalan data dan kunci storan melalui skrip tersuai adalah sangat terdedah kepada ralat. Satu salah konfigurasi dalam kerja cron atau panggilan API boleh menyebabkan arkib anda terdedah atau mengakibatkan kos storan awan melambung tinggi disebabkan oleh objek terkunci yang terbiar.

Platform sandaran perusahaan seperti CloudSave memudahkan seni bina ini. CloudSave menyepadukan secara asli dengan AWS S3 Object Lock, Azure Blob Immutable Storage, dan API serasi S3 dalam premis.

Apabila mengkonfigurasi pelan sandaran pangkalan data dalam CloudSave:
1. Platform secara automatik mengendalikan ketenangan VSS (Volume Shadow Copy Service) untuk SQL Server atau API pg_start_backup() untuk PostgreSQL.
2. Ia menstrim data sandaran yang dinyahduplikasi dan disulitkan terus ke sasaran storan.
3. CloudSave menggunakan panggilan API WORM (contohnya, PutObjectRetention) secara dinamik pada setiap objek, menyelaraskan tempoh kunci storan dengan jadual pengekalan yang ditetapkan oleh dasar dengan sempurna.
4. Jika penyerang mengkompromi konsol pengurusan CloudSave, mereka masih tidak boleh memadamkan sandaran tersebut, kerana kunci pematuhan dikuatkuasakan oleh infrastruktur storan asas, bukan perisian sandaran.

Amalan Terbaik untuk Arkib Pangkalan Data Tidak Boleh Ubah

Untuk memastikan seni bina tidak boleh ubah anda benar-benar berdaya tahan, patuhi amalan terbaik kejuruteraan sistem berikut:

1. Penyegerakan NTP yang Ketat

Kunci tidak boleh ubah terikat secara matematik dengan cap masa. Jika perkhidmatan NTP (Protokol Masa Rangkaian) pada tatasusunan storan atau pelayan sandaran anda dikompromi atau hanyut, ia boleh menyebabkan kunci tamat tempoh lebih awal atau tidak pernah tamat tempoh langsung. Pastikan infrastruktur storan anda menggunakan sumber NTP yang disahkan dan berlebihan.

2. Asingkan Peranan dan Kelayakan IAM

Kelayakan yang digunakan untuk menulis ke baldi tidak boleh ubah hanya perlu mempunyai kebenaran s3:PutObject dan s3:PutObjectRetention. Ia tidak boleh mempunyai kebenaran s3:DeleteObject atau s3:PutBucketObjectLockConfiguration.

Contoh dasar IAM keistimewaan minimum untuk ejen sandaran pangkalan 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 Saiz Tempoh Pengekalan

Jangan tetapkan kunci pematuhan untuk tempoh yang terlalu lama (contohnya, 7 tahun untuk pematuhan) pada lapisan pemulihan pantas utama anda. Pangkalan data menjana sejumlah besar data log WAL/transaksi. Mengunci data ini selama bertahun-tahun akan mengakibatkan pertumbuhan kos storan yang eksponen.
Sebaliknya, gunakan pendekatan berperingkat:
* Lapisan Pemulihan Operasi: 14 hingga 30 hari pengekalan tidak boleh ubah untuk Penuh dan Log.
* Lapisan Pengarkiban Jangka Panjang: Sandaran penuh bulanan dipindahkan ke Glacier/Deep Archive dengan Vault Lock selama 1-7 tahun.

4. Ujian Pemulihan Berkala dalam VPC Terasing (Air-Gapped)

Ketidakbolehubahan menjamin data tidak boleh dipadamkan, tetapi ia tidak menjamin data bebas daripada kerosakan logik. Anda mesti mengautomasikan pemulihan arkib pangkalan data tidak boleh ubah anda ke dalam VPC atau VLAN yang terasing dan terputus daripada rangkaian (air-gapped). Jalankan DBCC CHECKDB (SQL Server) atau pg_amcheck (PostgreSQL) pada data yang dipulihkan untuk mengesahkan integriti struktur.

Kesimpulan

Pertahanan perisian tebusan adalah latihan dalam mengandaikan pencerobohan. Apabila amaran dicetuskan dalam SIEM anda, pelaku ancaman mungkin telah pun cuba mengkompromi infrastruktur sandaran anda. Dengan mereka bentuk arkib pangkalan data anda menggunakan storan tidak boleh ubah dalam Mod Pematuhan, anda melucutkan kuasa utama penyerang. Sama ada anda menggunakan API awan asli, tahanan ZFS, atau platform pengorkestraan perusahaan seperti CloudSave, melaksanakan storan WORM bukan lagi pilihan—ia adalah tonggak mandatori bagi pentadbiran pangkalan data dan pemulihan bencana moden.

Kategori