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.

Στο σύγχρονο τοπίο απειλών, το ransomware έχει εξελιχθεί από ευκαιριακή κρυπτογράφηση σε εξαιρετικά στοχευμένες εκστρατείες πολλαπλού εκβιασμού. Οι Προηγμένες Επίμονες Απειλές (APTs) και τα συνδικάτα ransomware αναζητούν πλέον ενεργά υποδομές αντιγράφων ασφαλείας και αρχεία βάσεων δεδομένων κατά τη διάρκεια της παραμονής τους στο δίκτυο. Εάν ένας εισβολέας παραβιάσει την κύρια βάση δεδομένων σας και ταυτόχρονα διαγράψει ή κρυπτογραφήσει τα αποθετήρια αντιγράφων ασφαλείας σας, ο οργανισμός σας θα αντιμετωπίσει καταστροφική απώλεια δεδομένων.

Για τους Διαχειριστές Βάσεων Δεδομένων (DBAs) και τους μηχανικούς DevOps, η παραδοσιακή στρατηγική αντιγράφων ασφαλείας 3-2-1 δεν είναι πλέον επαρκής. Για να διασφαλιστεί η επιβίωση των δεδομένων, οι ομάδες υποδομής πρέπει να υιοθετήσουν τον κανόνα 3-2-1-1, όπου το τελευταίο «1» αντιπροσωπεύει τον αμετάβλητο αποθηκευτικό χώρο (immutable storage).

Αυτό το άρθρο παρέχει μια ολοκληρωμένη, τεχνική ανάλυση σχετικά με τον σχεδιασμό, την υλοποίηση και τη διαχείριση αμετάβλητου αποθηκευτικού χώρου για αρχεία βάσεων δεδομένων, ώστε να διασφαλιστεί η απόλυτη ανθεκτικότητα έναντι του ransomware.

Οι μηχανισμοί του αμετάβλητου αποθηκευτικού χώρου

Ο αμετάβλητος αποθηκευτικός χώρος βασίζεται σε μια αρχιτεκτονική Write-Once-Read-Many (WORM). Μόλις τα δεδομένα εγγραφούν σε έναν αμετάβλητο προορισμό, δεν μπορούν να τροποποιηθούν, να κρυπτογραφηθούν ή να διαγραφούν από κανέναν χρήστη—συμπεριλαμβανομένων των διαχειριστών με δικαιώματα root ή παραβιασμένων λογαριασμών υπηρεσιών—μέχρι να λήξει ένα μαθηματικά επιβεβλημένο χρονικό κλείδωμα.

Λειτουργία Συμμόρφωσης (Compliance Mode) έναντι Λειτουργίας Διακυβέρνησης (Governance Mode)

Κατά την υλοποίηση της αμεταβλητότητας, ιδιαίτερα σε αποθηκευτικό χώρο αντικειμένων (object storage) στο cloud όπως το AWS S3, το Azure Blob ή σε on-premises SANs συμβατά με S3, πρέπει να κατανοήσετε τη διαφορά μεταξύ των λειτουργιών διατήρησης:

  • Λειτουργία Διακυβέρνησης (Governance Mode): Εμποδίζει τους τυπικούς χρήστες από το να διαγράφουν ή να αλλάζουν αντικείμενα. Ωστόσο, χρήστες με συγκεκριμένα δικαιώματα IAM (π.χ. s3:BypassGovernanceRetention) μπορούν να παρακάμψουν το κλείδωμα. Αυτό είναι χρήσιμο για δοκιμές, αλλά ανεπαρκές για προστασία από ransomware, καθώς οι εισβολείς συχνά κλιμακώνουν τα προνόμιά τους σε domain admin ή root.
  • Λειτουργία Συμμόρφωσης (Compliance Mode): Το χρυσό πρότυπο για την άμυνα κατά του ransomware. Μόλις ένα αντικείμενο κλειδωθεί σε Λειτουργία Συμμόρφωσης, η περίοδος διατήρησής του δεν μπορεί να μειωθεί και το αντικείμενο δεν μπορεί να διαγραφεί από κανέναν, συμπεριλαμβανομένου του root λογαριασμού του AWS. Το κλείδωμα επιβάλλεται στο επίπεδο του αποθηκευτικού συμπλέγματος (storage cluster).

Σχεδιασμός μιας αμετάβλητης γραμμής αντιγράφων ασφαλείας

Μια ισχυρή αρχιτεκτονική αρχειοθέτησης βάσεων δεδομένων διαχωρίζει τις ενεργές λειτουργίες της βάσης δεδομένων από το αμετάβλητο επίπεδο αρχειοθέτησης. Δεν μπορείτε να εφαρμόσετε αμεταβλητότητα σε ενεργά αρχεία βάσεων δεδομένων (όπως τα .mdf/.ldf στον SQL Server ή τον κατάλογο pg_data στην PostgreSQL), επειδή οι βάσεις δεδομένων απαιτούν συνεχή πρόσβαση ανάγνωσης/εγγραφής.

Αντίθετα, η αμεταβλητότητα εφαρμόζεται σε:
1. Πλήρη και διαφορικά αρχεία αντιγράφων ασφαλείας: Τα βασικά στιγμιότυπα (snapshots) της βάσης δεδομένων.
2. Αρχεία καταγραφής συναλλαγών / WAL: Τη συνεχή ροή αλλαγών της βάσης δεδομένων που απαιτείται για την Ανάκτηση σε Χρονικό Σημείο (Point-in-Time Recovery – PITR).

Στόχοι αποθήκευσης για αμεταβλητότητα

Μπορείτε να υλοποιήσετε αμετάβλητο αποθηκευτικό χώρο σε διαφορετικά επίπεδα υποδομής:
* Cloud Object Storage: AWS S3 Object Lock, Azure Blob Immutable Storage, Πολιτικές Διατήρησης του Google Cloud Storage.
* 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

Για να προστατεύσετε τα dumps βάσεων δεδομένων και τα αρχεία καταγραφής συναλλαγών στο 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

Στη συνέχεια, ρυθμίστε την προεπιλεγμένη πολιτική διατήρησης. Για αρχεία βάσεων δεδομένων, ένα κλείδωμα συμμόρφωσης 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. On-Premises Αμεταβλητότητα: ZFS και Χαρακτηριστικά Linux

Εάν αρχειοθετείτε βάσεις δεδομένων σε έναν on-premises διακομιστή αντιγράφων ασφαλείας Linux, μπορείτε να επιτύχετε ψευδο-αμεταβλητότητα χρησιμοποιώντας την εντολή chattr, ή πραγματική αμεταβλητότητα χρησιμοποιώντας στιγμιότυπα ZFS.

Χρήση του Linux chattr:
Η σημαία +i (immutable) εμποδίζει την τροποποίηση, διαγραφή ή μετονομασία αρχείων.

# Dump της βάσης δεδομένων
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 σταματά βασικά σενάρια ransomware, ένας εξελιγμένος εισβολέας με πρόσβαση root μπορεί απλώς να εκτελέσει chattr -i. Επομένως, αυτό πρέπει να συνδυαστεί με αυστηρό RBAC και απομονωμένα δίκτυα αντιγράφων ασφαλείας.

Χρήση Στιγμιότυπων ZFS:
Το ZFS παρέχει πολύ ισχυρότερη άμυνα. Λαμβάνοντας ένα στιγμιότυπο και θέτοντας ένα «hold» σε αυτό, εμποδίζετε την καταστροφή του στιγμιότυπου.

# Λήψη στιγμιότυπου του συνόλου δεδομένων αντιγράφων ασφαλείας
zfs snapshot tank/db_backups@archive_$(date +%F)

# Τοποθέτηση hold στο στιγμιότυπο για αποτροπή διαγραφής
zfs hold keep_30_days tank/db_backups@archive_$(date +%F)

# Ακόμη και ο root δεν μπορεί να καταστρέψει αυτό το στιγμιότυπο χωρίς την απελευθέρωση του hold
zfs destroy tank/db_backups@archive_$(date +%F)
# Έξοδος: 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

# Βεβαιωθείτε ότι η διατήρηση ευθυγραμμίζεται με τη ρύθμιση S3 Object Lock
repo1-retention-full=2
repo1-retention-archive=2

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

Κρίσιμη παρατήρηση: Εάν το S3 bucket σας επιβάλλει κλείδωμα Συμμόρφωσης 30 ημερών, αλλά το pgBackRest προσπαθεί να λήξει και να διαγράψει αρχεία WAL μετά από 14 ημέρες βάσει του repo1-retention-archive, οι κλήσεις API διαγραφής θα αποτύχουν. Πρέπει να διασφαλίσετε ότι η πολιτική διατήρησης του λογισμικού αντιγράφων ασφαλείας σας είναι ίση ή μεγαλύτερη από το αμετάβλητο κλείδωμα σε επίπεδο αποθήκευσης.

Microsoft SQL Server: Backup to URL

Ο SQL Server υποστηρίζει εγγενή αντίγραφα ασφαλείας απευθείας σε αποθηκευτικό χώρο αντικειμένων συμβατό με S3. Μπορείτε να ρυθμίσετε μια εργασία SQL Server Agent για την εγγραφή αρχείων .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 μπορεί να αφήσει τα αρχεία σας εκτεθειμένα ή να οδηγήσει σε εκτόξευση του κόστους αποθήκευσης στο cloud λόγω ορφανών, κλειδωμένων αντικειμένων.

Πλατφόρμες αντιγράφων ασφαλείας επιπέδου επιχείρησης όπως το CloudSave απλοποιούν αυτή την αρχιτεκτονική. Το CloudSave ενσωματώνεται εγγενώς με το AWS S3 Object Lock, το Azure Blob Immutable Storage και on-premises APIs συμβατά με S3.

Κατά τη ρύθμιση ενός σχεδίου αντιγράφων ασφαλείας βάσης δεδομένων στο CloudSave:
1. Η πλατφόρμα διαχειρίζεται αυτόματα το VSS (Volume Shadow Copy Service) quiescence για τον SQL Server ή το API pg_start_backup() για την PostgreSQL.
2. Μεταδίδει τα αποδιπλότυπα (deduplicated), κρυπτογραφημένα δεδομένα αντιγράφων ασφαλείας απευθείας στον στόχο αποθήκευσης.
3. Το CloudSave εφαρμόζει δυναμικά τις κλήσεις WORM API (π.χ. PutObjectRetention) ανά αντικείμενο, ευθυγραμμίζοντας τέλεια τη διάρκεια κλειδώματος αποθήκευσης με το πρόγραμμα διατήρησης που ορίζεται από την πολιτική.
4. Εάν ένας εισβολέας παραβιάσει την κονσόλα διαχείρισης του CloudSave, εξακολουθεί να μην μπορεί να διαγράψει τα αντίγραφα ασφαλείας, καθώς το κλείδωμα συμμόρφωσης επιβάλλεται από την υποκείμενη υποδομή αποθήκευσης, όχι από το λογισμικό αντιγράφων ασφαλείας.

Βέλτιστες πρακτικές για αμετάβλητα αρχεία βάσεων δεδομένων

Για να διασφαλίσετε ότι η αμετάβλητη αρχιτεκτονική σας είναι πραγματικά ανθεκτική, ακολουθήστε τις παρακάτω βέλτιστες πρακτικές μηχανικής συστημάτων:

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. Καθορισμός της περιόδου διατήρησης

Μην ορίζετε κλειδώματα συμμόρφωσης για υπερβολικά μεγάλες περιόδους (π.χ. 7 χρόνια για συμμόρφωση) στο κύριο επίπεδο ταχείας ανάκτησης. Οι βάσεις δεδομένων παράγουν τεράστιες ποσότητες δεδομένων WAL/transaction log. Το κλείδωμα αυτών των δεδομένων για χρόνια θα οδηγήσει σε εκθετική αύξηση του κόστους αποθήκευσης.
Αντίθετα, χρησιμοποιήστε μια κλιμακωτή προσέγγιση:
* Επίπεδο Επιχειρησιακής Ανάκτησης: 14 έως 30 ημέρες αμετάβλητης διατήρησης για πλήρη αντίγραφα και αρχεία καταγραφής.
* Επίπεδο Μακροπρόθεσμης Αρχειοθέτησης: Μηνιαία πλήρη αντίγραφα ασφαλείας που μετακινούνται στο Glacier/Deep Archive με Vault Lock για 1-7 χρόνια.

4. Τακτικές δοκιμές ανάκτησης σε απομονωμένα (air-gapped) VPC

Η αμεταβλητότητα εγγυάται ότι τα δεδομένα δεν μπορούν να διαγραφούν, αλλά δεν εγγυάται ότι τα δεδομένα είναι απαλλαγμένα από λογική διαφθορά. Πρέπει να αυτοματοποιήσετε την αποκατάσταση των αμετάβλητων αρχείων της βάσης δεδομένων σας σε ένα απομονωμένο, air-gapped VPC ή VLAN. Εκτελέστε DBCC CHECKDB (SQL Server) ή pg_amcheck (PostgreSQL) στα αποκατεστημένα δεδομένα για να επαληθεύσετε τη δομική ακεραιότητα.

Συμπέρασμα

Η άμυνα κατά του ransomware είναι μια άσκηση που βασίζεται στην παραδοχή της παραβίασης. Μέχρι τη στιγμή που θα ενεργοποιηθεί μια ειδοποίηση στο SIEM σας, οι δράστες πιθανότατα έχουν ήδη προσπαθήσει να παραβιάσουν την υποδομή αντιγράφων ασφαλείας σας. Σχεδιάζοντας τα αρχεία της βάσης δεδομένων σας χρησιμοποιώντας αμετάβλητο αποθηκευτικό χώρο σε Λειτουργία Συμμόρφωσης, αφαιρείτε από τους εισβολείς το κύριο πλεονέκτημά τους. Είτε χρησιμοποιείτε εγγενή cloud APIs, ZFS holds ή μια πλατφόρμα ενορχήστρωσης επιπέδου επιχείρησης όπως το CloudSave, η υλοποίηση αποθηκευτικού χώρου WORM δεν είναι πλέον προαιρετική—είναι ένας υποχρεωτικός πυλώνας της σύγχρονης διαχείρισης βάσεων δεδομένων και της αποκατάστασης από καταστροφές.

Kατηγορίες