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) ਅਤੇ ਰੈਨਸਮਵੇਅਰ ਸਿੰਡੀਕੇਟ ਹੁਣ ਆਪਣੇ ਡਵੈਲ ਟਾਈਮ (dwell time) ਦੌਰਾਨ ਬੈਕਅੱਪ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਅਤੇ ਡੇਟਾਬੇਸ ਆਰਕਾਈਵਜ਼ ਦੀ ਸਰਗਰਮੀ ਨਾਲ ਭਾਲ ਕਰਦੇ ਹਨ। ਜੇਕਰ ਕੋਈ ਹਮਲਾਵਰ ਤੁਹਾਡੇ ਪ੍ਰਾਇਮਰੀ ਡੇਟਾਬੇਸ ਨਾਲ ਸਮਝੌਤਾ ਕਰਦਾ ਹੈ ਅਤੇ ਨਾਲ ਹੀ ਤੁਹਾਡੇ ਬੈਕਅੱਪ ਰਿਪੋਜ਼ਟਰੀਆਂ ਨੂੰ ਮਿਟਾ ਜਾਂ ਇਨਕ੍ਰਿਪਟ ਕਰ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੀ ਸੰਸਥਾ ਨੂੰ ਭਿਆਨਕ ਡੇਟਾ ਨੁਕਸਾਨ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈ ਸਕਦਾ ਹੈ।

ਡੇਟਾਬੇਸ ਐਡਮਿਨਿਸਟ੍ਰੇਟਰਾਂ (DBAs) ਅਤੇ DevOps ਇੰਜੀਨੀਅਰਾਂ ਲਈ, ਰਵਾਇਤੀ 3-2-1 ਬੈਕਅੱਪ ਰਣਨੀਤੀ ਹੁਣ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ। ਡੇਟਾ ਦੀ ਸੁਰੱਖਿਆ ਦੀ ਗਾਰੰਟੀ ਦੇਣ ਲਈ, ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਟੀਮਾਂ ਨੂੰ 3-2-1-1 ਨਿਯਮ ਅਪਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਿੱਥੇ ਅੰਤਿਮ “1” ਦਾ ਅਰਥ ਹੈ ਅਟੱਲ ਸਟੋਰੇਜ (immutable storage)।

ਇਹ ਲੇਖ ਡੇਟਾਬੇਸ ਆਰਕਾਈਵਜ਼ ਲਈ ਅਟੱਲ ਸਟੋਰੇਜ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਨ, ਲਾਗੂ ਕਰਨ ਅਤੇ ਪ੍ਰਬੰਧਿਤ ਕਰਨ ਬਾਰੇ ਇੱਕ ਵਿਆਪਕ, ਤਕਨੀਕੀ ਡੂੰਘਾਈ ਨਾਲ ਜਾਣਕਾਰੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਰੈਨਸਮਵੇਅਰ ਦੇ ਵਿਰੁੱਧ ਪੂਰੀ ਲਚਕਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਇਆ ਜਾ ਸਕੇ।

ਅਟੱਲ ਸਟੋਰੇਜ (Immutable Storage) ਦੀ ਕਾਰਜਪ੍ਰਣਾਲੀ

ਅਟੱਲ ਸਟੋਰੇਜ ਇੱਕ ਰਾਈਟ-ਵਨਸ-ਰੀਡ-ਮੈਨੀ (WORM) ਆਰਕੀਟੈਕਚਰ ‘ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਇੱਕ ਵਾਰ ਜਦੋਂ ਡੇਟਾ ਨੂੰ ਇੱਕ ਅਟੱਲ ਟਾਰਗੇਟ ‘ਤੇ ਲਿਖ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਕਿਸੇ ਵੀ ਉਪਭੋਗਤਾ ਦੁਆਰਾ—ਰੂਟ ਅਧਿਕਾਰਾਂ ਵਾਲੇ ਪ੍ਰਸ਼ਾਸਕਾਂ ਜਾਂ ਸਮਝੌਤਾ ਕੀਤੇ ਗਏ ਸਰਵਿਸ ਅਕਾਉਂਟਸ ਸਮੇਤ—ਬਦਲਿਆ, ਇਨਕ੍ਰਿਪਟ ਜਾਂ ਮਿਟਾਇਆ ਨਹੀਂ ਜਾ ਸਕਦਾ, ਜਦੋਂ ਤੱਕ ਕਿ ਗਣਿਤਿਕ ਤੌਰ ‘ਤੇ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਸਮਾਂ ਲੌਕ ਖਤਮ ਨਹੀਂ ਹੋ ਜਾਂਦਾ।

ਕੰਪਲਾਇੰਸ ਮੋਡ ਬਨਾਮ ਗਵਰਨੈਂਸ ਮੋਡ

ਅਟੱਲਤਾ ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਸਮੇਂ, ਖਾਸ ਤੌਰ ‘ਤੇ AWS S3, Azure Blob, ਜਾਂ S3-ਅਨੁਕੂਲ ਆਨ-ਪ੍ਰੀਮਿਸ SANs ਵਰਗੀ ਕਲਾਉਡ ਆਬਜੈਕਟ ਸਟੋਰੇਜ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਰਿਟੈਨਸ਼ਨ ਮੋਡਾਂ ਵਿਚਕਾਰ ਅੰਤਰ ਨੂੰ ਸਮਝਣਾ ਚਾਹੀਦਾ ਹੈ:

  • ਗਵਰਨੈਂਸ ਮੋਡ: ਆਮ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਆਬਜੈਕਟ ਨੂੰ ਮਿਟਾਉਣ ਜਾਂ ਬਦਲਣ ਤੋਂ ਰੋਕਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਖਾਸ IAM ਅਨੁਮਤੀਆਂ (ਜਿਵੇਂ ਕਿ s3:BypassGovernanceRetention) ਵਾਲੇ ਉਪਭੋਗਤਾ ਲੌਕ ਨੂੰ ਬਾਈਪਾਸ ਕਰ ਸਕਦੇ ਹਨ। ਇਹ ਟੈਸਟਿੰਗ ਲਈ ਉਪਯੋਗੀ ਹੈ ਪਰ ਰੈਨਸਮਵੇਅਰ ਸੁਰੱਖਿਆ ਲਈ ਨਾਕਾਫ਼ੀ ਹੈ, ਕਿਉਂਕਿ ਹਮਲਾਵਰ ਅਕਸਰ ਡੋਮੇਨ ਐਡਮਿਨ ਜਾਂ ਰੂਟ ਤੱਕ ਅਧਿਕਾਰ ਵਧਾ ਲੈਂਦੇ ਹਨ।
  • ਕੰਪਲਾਇੰਸ ਮੋਡ: ਰੈਨਸਮਵੇਅਰ ਰੱਖਿਆ ਲਈ ਸੋਨੇ ਦਾ ਮਿਆਰ। ਇੱਕ ਵਾਰ ਜਦੋਂ ਕੋਈ ਆਬਜੈਕਟ ਕੰਪਲਾਇੰਸ ਮੋਡ ਵਿੱਚ ਲੌਕ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਸਦੀ ਰਿਟੈਨਸ਼ਨ ਮਿਆਦ ਨੂੰ ਘਟਾਇਆ ਨਹੀਂ ਜਾ ਸਕਦਾ, ਅਤੇ ਆਬਜੈਕਟ ਨੂੰ ਕਿਸੇ ਦੁਆਰਾ ਵੀ ਮਿਟਾਇਆ ਨਹੀਂ ਜਾ ਸਕਦਾ, AWS ਰੂਟ ਅਕਾਉਂਟ ਸਮੇਤ। ਲੌਕ ਨੂੰ ਸਟੋਰੇਜ ਕਲੱਸਟਰ ਪੱਧਰ ‘ਤੇ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਇੱਕ ਅਟੱਲ ਬੈਕਅੱਪ ਪਾਈਪਲਾਈਨ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਨਾ

ਇੱਕ ਮਜ਼ਬੂਤ ਡੇਟਾਬੇਸ ਆਰਕਾਈਵਿੰਗ ਆਰਕੀਟੈਕਚਰ ਸਰਗਰਮ ਡੇਟਾਬੇਸ ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਅਟੱਲ ਆਰਕਾਈਵ ਟਾਇਰ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਸਰਗਰਮ ਡੇਟਾਬੇਸ ਫਾਈਲਾਂ (ਜਿਵੇਂ ਕਿ SQL ਸਰਵਰ ਵਿੱਚ .mdf/.ldf ਜਾਂ PostgreSQL ਵਿੱਚ pg_data ਡਾਇਰੈਕਟਰੀ) ‘ਤੇ ਅਟੱਲਤਾ ਲਾਗੂ ਨਹੀਂ ਕਰ ਸਕਦੇ ਕਿਉਂਕਿ ਡੇਟਾਬੇਸ ਨੂੰ ਨਿਰੰਤਰ ਪੜ੍ਹਨ/ਲਿਖਣ ਦੀ ਪਹੁੰਚ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਇਸ ਦੀ ਬਜਾਏ, ਅਟੱਲਤਾ ਇਹਨਾਂ ‘ਤੇ ਲਾਗੂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ:
1. ਪੂਰੀ ਅਤੇ ਡਿਫਰੈਂਸ਼ੀਅਲ ਬੈਕਅੱਪ ਫਾਈਲਾਂ: ਡੇਟਾਬੇਸ ਦੇ ਬੇਸਲਾਈਨ ਸਨੈਪਸ਼ਾਟ।
2. ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗਸ / WAL ਫਾਈਲਾਂ: ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ (PITR) ਲਈ ਲੋੜੀਂਦੇ ਡੇਟਾਬੇਸ ਤਬਦੀਲੀਆਂ ਦੀ ਨਿਰੰਤਰ ਸਟ੍ਰੀਮ।

ਅਟੱਲਤਾ ਲਈ ਸਟੋਰੇਜ ਟਾਰਗੇਟ

ਤੁਸੀਂ ਵੱਖ-ਵੱਖ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਟਾਇਰਾਂ ਵਿੱਚ ਅਟੱਲ ਸਟੋਰੇਜ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹੋ:
* ਕਲਾਉਡ ਆਬਜੈਕਟ ਸਟੋਰੇਜ: AWS S3 ਆਬਜੈਕਟ ਲੌਕ, Azure Blob ਅਟੱਲ ਸਟੋਰੇਜ, Google ਕਲਾਉਡ ਸਟੋਰੇਜ ਰਿਟੈਨਸ਼ਨ ਨੀਤੀਆਂ।
* ਆਨ-ਪ੍ਰੀਮਿਸ ਆਬਜੈਕਟ ਸਟੋਰੇਜ: MinIO, Cloudian, ਜਾਂ Pure Storage FlashBlade ਜੋ S3 ਆਬਜੈਕਟ ਲੌਕ API ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ।
* ਬਲਾਕ/ਫਾਈਲ ਸਟੋਰੇਜ: ਰੀਡ-ਓਨਲੀ ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਡੈਲੀਗੇਟਿਡ ਐਡਮਿਨਿਸਟ੍ਰੇਸ਼ਨ ਦੇ ਨਾਲ ZFS, ਜਾਂ Linux ਫਾਈਲ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ।

ਅਟੱਲ ਸਟੋਰੇਜ ਲਾਗੂ ਕਰਨਾ: ਤਕਨੀਕੀ ਵਾਕਥਰੂ

1. ਕਲਾਉਡ ਆਬਜੈਕਟ ਸਟੋਰੇਜ: AWS S3 ਆਬਜੈਕਟ ਲੌਕ

AWS ਵਿੱਚ ਡੇਟਾਬੇਸ ਡੰਪ ਅਤੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗਸ ਦੀ ਸੁਰੱਖਿਆ ਲਈ, ਤੁਹਾਨੂੰ ਬਾਲਟੀ (bucket) ਬਣਾਉਣ ਦੇ ਸਮੇਂ ਆਬਜੈਕਟ ਲੌਕ ਨੂੰ ਸਮਰੱਥ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਪਹਿਲਾਂ, ਆਬਜੈਕਟ ਲੌਕ ਸਮਰੱਥ ਨਾਲ ਬਾਲਟੀ ਬਣਾਓ:

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
            }
        }
    }'

ਜਦੋਂ ਤੁਹਾਡੀ ਡੇਟਾਬੇਸ ਬੈਕਅੱਪ ਸਕ੍ਰਿਪਟ ਜਾਂ ਏਜੰਟ ਇਸ ਬਾਲਟੀ ਵਿੱਚ ਇੱਕ ਫਾਈਲ ਪੁਸ਼ ਕਰਦਾ ਹੈ, ਤਾਂ S3 ਆਟੋਮੈਟਿਕਲੀ ਆਬਜੈਕਟ ਬਣਾਉਣ ਦੇ ਟਾਈਮਸਟੈਂਪ ਵਿੱਚ 30 ਦਿਨ ਜੋੜ ਕੇ Retain Until Date ਦੀ ਗਣਨਾ ਕਰਦਾ ਹੈ।

2. ਆਨ-ਪ੍ਰੀਮਿਸ ਅਟੱਲਤਾ: ZFS ਅਤੇ Linux ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ

ਜੇਕਰ ਤੁਸੀਂ ਆਨ-ਪ੍ਰੀਮਿਸ Linux ਬੈਕਅੱਪ ਸਰਵਰ ‘ਤੇ ਡੇਟਾਬੇਸ ਆਰਕਾਈਵ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ chattr ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸੂਡੋ-ਅਟੱਲਤਾ, ਜਾਂ ZFS ਸਨੈਪਸ਼ਾਟ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸੱਚੀ ਅਟੱਲਤਾ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ।

Linux 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 ਬਹੁਤ ਮਜ਼ਬੂਤ ਸੁਰੱਖਿਆ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਇੱਕ ਸਨੈਪਸ਼ਾਟ ਲੈ ਕੇ ਅਤੇ ਉਸ ‘ਤੇ “ਹੋਲਡ” ਲਗਾ ਕੇ, ਤੁਸੀਂ ਸਨੈਪਸ਼ਾਟ ਨੂੰ ਨਸ਼ਟ ਹੋਣ ਤੋਂ ਰੋਕਦੇ ਹੋ।

# ਬੈਕਅੱਪ ਡੇਟਾਸੈਟ ਦਾ ਸਨੈਪਸ਼ਾਟ ਲਓ
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 ਬਾਲਟੀ 30-ਦਿਨਾਂ ਦਾ ਕੰਪਲਾਇੰਸ ਲੌਕ ਲਾਗੂ ਕਰਦੀ ਹੈ, ਪਰ pgBackRest repo1-retention-archive ਦੇ ਆਧਾਰ ‘ਤੇ 14 ਦਿਨਾਂ ਬਾਅਦ WAL ਫਾਈਲਾਂ ਨੂੰ ਮਿਆਦ ਪੁੱਗਣ ਅਤੇ ਮਿਟਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਮਿਟਾਉਣ ਵਾਲੀਆਂ API ਕਾਲਾਂ ਅਸਫਲ ਹੋ ਜਾਣਗੀਆਂ। ਤੁਹਾਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਬੈਕਅੱਪ ਸੌਫਟਵੇਅਰ ਦੀ ਰਿਟੈਨਸ਼ਨ ਨੀਤੀ ਸਟੋਰੇਜ-ਪੱਧਰ ਦੇ ਅਟੱਲ ਲੌਕ ਤੋਂ ਵੱਧ ਜਾਂ ਬਰਾਬਰ ਹੈ।

Microsoft SQL ਸਰਵਰ: URL ‘ਤੇ ਬੈਕਅੱਪ

SQL ਸਰਵਰ ਸਿੱਧੇ S3-ਅਨੁਕੂਲ ਆਬਜੈਕਟ ਸਟੋਰੇਜ ‘ਤੇ ਮੂਲ ਬੈਕਅੱਪ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ .bak ਅਤੇ .trn ਫਾਈਲਾਂ ਨੂੰ ਸਿੱਧੇ ਇੱਕ ਅਟੱਲ ਬਾਲਟੀ ਵਿੱਚ ਲਿਖਣ ਲਈ ਇੱਕ SQL ਸਰਵਰ ਏਜੰਟ ਜੌਬ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰ ਸਕਦੇ ਹੋ।

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 ਨਾਲ ਆਟੋਮੇਟਿੰਗ ਅਤੇ ਆਰਕੈਸਟ੍ਰੇਟਿੰਗ

ਅਟੱਲ ਰਿਟੈਨਸ਼ਨ ਫਲੈਗਸ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨਾ, ਐਕਸੈਸ ਕੁੰਜੀਆਂ ਨੂੰ ਘੁੰਮਾਉਣਾ, ਅਤੇ ਕਸਟਮ ਸਕ੍ਰਿਪਟਾਂ ਰਾਹੀਂ ਡੇਟਾਬੇਸ ਰਿਟੈਨਸ਼ਨ ਨੀਤੀਆਂ ਅਤੇ ਸਟੋਰੇਜ ਲੌਕਾਂ ਵਿਚਕਾਰ ਸਮਕਾਲੀਕਰਨ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣਾ ਬਹੁਤ ਗਲਤੀ-ਪ੍ਰੋਨ ਹੈ। ਇੱਕ ਕ੍ਰੋਨ ਜੌਬ ਜਾਂ API ਕਾਲ ਵਿੱਚ ਇੱਕ ਗਲਤ ਕੌਂਫਿਗਰੇਸ਼ਨ ਤੁਹਾਡੇ ਆਰਕਾਈਵਜ਼ ਨੂੰ ਖੁੱਲ੍ਹਾ ਛੱਡ ਸਕਦੀ ਹੈ ਜਾਂ ਅਨਾਥ, ਲੌਕ ਕੀਤੇ ਆਬਜੈਕਟਾਂ ਦੇ ਕਾਰਨ ਕਲਾਉਡ ਸਟੋਰੇਜ ਦੀਆਂ ਲਾਗਤਾਂ ਨੂੰ ਵਧਾ ਸਕਦੀ ਹੈ।

CloudSave ਵਰਗੇ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਬੈਕਅੱਪ ਪਲੇਟਫਾਰਮ ਇਸ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਸਰਲ ਬਣਾਉਂਦੇ ਹਨ। CloudSave ਮੂਲ ਰੂਪ ਵਿੱਚ AWS S3 ਆਬਜੈਕਟ ਲੌਕ, Azure Blob ਅਟੱਲ ਸਟੋਰੇਜ, ਅਤੇ ਆਨ-ਪ੍ਰੀਮਿਸ S3-ਅਨੁਕੂਲ APIs ਨਾਲ ਏਕੀਕ੍ਰਿਤ ਹੁੰਦਾ ਹੈ।

CloudSave ਵਿੱਚ ਡੇਟਾਬੇਸ ਬੈਕਅੱਪ ਯੋਜਨਾ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਦੇ ਸਮੇਂ:
1. ਪਲੇਟਫਾਰਮ ਆਟੋਮੈਟਿਕਲੀ SQL ਸਰਵਰ ਲਈ VSS (ਵਾਲੀਅਮ ਸ਼ੈਡੋ ਕਾਪੀ ਸਰਵਿਸ) ਕੁਇਸੈਂਸ ਜਾਂ PostgreSQL ਲਈ pg_start_backup() API ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ।
2. ਇਹ ਡੀਡੁਪਲੀਕੇਟ ਕੀਤੇ, ਇਨਕ੍ਰਿਪਟ ਕੀਤੇ ਬੈਕਅੱਪ ਡੇਟਾ ਨੂੰ ਸਿੱਧੇ ਸਟੋਰੇਜ ਟਾਰਗੇਟ ‘ਤੇ ਸਟ੍ਰੀਮ ਕਰਦਾ ਹੈ।
3. CloudSave ਗਤੀਸ਼ੀਲ ਤੌਰ ‘ਤੇ WORM API ਕਾਲਾਂ (ਜਿਵੇਂ ਕਿ PutObjectRetention) ਨੂੰ ਪ੍ਰਤੀ-ਆਬਜੈਕਟ ਆਧਾਰ ‘ਤੇ ਲਾਗੂ ਕਰਦਾ ਹੈ, ਜੋ ਸਟੋਰੇਜ ਲੌਕ ਦੀ ਮਿਆਦ ਨੂੰ ਨੀਤੀ-ਪ੍ਰਭਾਸ਼ਿਤ ਰਿਟੈਨਸ਼ਨ ਅਨੁਸੂਚੀ ਨਾਲ ਪੂਰੀ ਤਰ੍ਹਾਂ ਇਕਸਾਰ ਕਰਦਾ ਹੈ।
4. ਜੇਕਰ ਕੋਈ ਹਮਲਾਵਰ CloudSave ਮੈਨੇਜਮੈਂਟ ਕੰਸੋਲ ਨਾਲ ਸਮਝੌਤਾ ਕਰਦਾ ਹੈ, ਤਾਂ ਵੀ ਉਹ ਬੈਕਅੱਪ ਨੂੰ ਮਿਟਾ ਨਹੀਂ ਸਕਦੇ, ਕਿਉਂਕਿ ਕੰਪਲਾਇੰਸ ਲੌਕ ਅੰਡਰਲਾਈੰਗ ਸਟੋਰੇਜ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੁਆਰਾ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਨਾ ਕਿ ਬੈਕਅੱਪ ਸੌਫਟਵੇਅਰ ਦੁਆਰਾ।

ਅਟੱਲ ਡੇਟਾਬੇਸ ਆਰਕਾਈਵਜ਼ ਲਈ ਵਧੀਆ ਅਭਿਆਸ

ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕਿ ਤੁਹਾਡਾ ਅਟੱਲ ਆਰਕੀਟੈਕਚਰ ਸੱਚਮੁੱਚ ਲਚਕੀਲਾ ਹੈ, ਹੇਠਾਂ ਦਿੱਤੇ ਸਿਸਟਮ ਇੰਜੀਨੀਅਰਿੰਗ ਦੇ ਵਧੀਆ ਅਭਿਆਸਾਂ ਦੀ ਪਾਲਣਾ ਕਰੋ:

1. ਸਖ਼ਤ NTP ਸਮਕਾਲੀਕਰਨ

ਅਟੱਲ ਲੌਕ ਗਣਿਤਿਕ ਤੌਰ ‘ਤੇ ਟਾਈਮਸਟੈਂਪਾਂ ਨਾਲ ਬੰਨ੍ਹੇ ਹੋਏ ਹਨ। ਜੇਕਰ ਤੁਹਾਡੇ ਸਟੋਰੇਜ ਐਰੇ ਜਾਂ ਬੈਕਅੱਪ ਸਰਵਰ ‘ਤੇ NTP (ਨੈੱਟਵਰਕ ਟਾਈਮ ਪ੍ਰੋਟੋਕੋਲ) ਸੇਵਾ ਨਾਲ ਸਮਝੌਤਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਾਂ ਡ੍ਰਿਫਟ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇਹ ਲੌਕਾਂ ਨੂੰ ਸਮੇਂ ਤੋਂ ਪਹਿਲਾਂ ਖਤਮ ਕਰਨ ਜਾਂ ਕਦੇ ਵੀ ਖਤਮ ਨਾ ਹੋਣ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦਾ ਹੈ। ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡਾ ਸਟੋਰੇਜ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਪ੍ਰਮਾਣਿਤ, ਰਿਡੰਡੈਂਟ NTP ਸਰੋਤਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ।

2. 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/*"
            ]
        }
    ]
}

3. ਰਿਟੈਨਸ਼ਨ ਮਿਆਦ ਦਾ ਆਕਾਰ ਨਿਰਧਾਰਤ ਕਰਨਾ

ਆਪਣੇ ਪ੍ਰਾਇਮਰੀ ਰੈਪਿਡ-ਰਿਕਵਰੀ ਟਾਇਰ ‘ਤੇ ਬਹੁਤ ਲੰਬੇ ਸਮੇਂ (ਜਿਵੇਂ ਕਿ ਪਾਲਣਾ ਲਈ 7 ਸਾਲ) ਲਈ ਕੰਪਲਾਇੰਸ ਲੌਕ ਨਾ ਲਗਾਓ। ਡੇਟਾਬੇਸ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ WAL/ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਡੇਟਾ ਤਿਆਰ ਕਰਦੇ ਹਨ। ਇਸ ਡੇਟਾ ਨੂੰ ਸਾਲਾਂ ਲਈ ਲੌਕ ਕਰਨ ਨਾਲ ਸਟੋਰੇਜ ਦੀ ਲਾਗਤ ਵਿੱਚ ਤੇਜ਼ੀ ਨਾਲ ਵਾਧਾ ਹੋਵੇਗਾ।
ਇਸ ਦੀ ਬਜਾਏ, ਇੱਕ ਟਾਇਰਡ ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਕਰੋ:
* ਓਪਰੇਸ਼ਨਲ ਰਿਕਵਰੀ ਟਾਇਰ: ਫੁੱਲ ਅਤੇ ਲੌਗਸ ਲਈ 14 ਤੋਂ 30 ਦਿਨਾਂ ਦੀ ਅਟੱਲ ਰਿਟੈਨਸ਼ਨ।
* ਲੰਬੇ ਸਮੇਂ ਦਾ ਆਰਕਾਈਵਲ ਟਾਇਰ: ਮਾਸਿਕ ਪੂਰੇ ਬੈਕਅੱਪ ਜੋ 1-7 ਸਾਲਾਂ ਲਈ ਵਾਲਟ ਲੌਕ ਦੇ ਨਾਲ Glacier/Deep Archive ਵਿੱਚ ਭੇਜੇ ਜਾਂਦੇ ਹਨ।

4. ਏਅਰ-ਗੈਪਡ VPCs ਵਿੱਚ ਨਿਯਮਤ ਰਿਕਵਰੀ ਟੈਸਟਿੰਗ

ਅਟੱਲਤਾ ਗਾਰੰਟੀ ਦਿੰਦੀ ਹੈ ਕਿ ਡੇਟਾ ਨੂੰ ਮਿਟਾਇਆ ਨਹੀਂ ਜਾ ਸਕਦਾ, ਪਰ ਇਹ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦੀ ਕਿ ਡੇਟਾ ਤਰਕਪੂਰਨ ਭ੍ਰਿਸ਼ਟਾਚਾਰ ਤੋਂ ਮੁਕਤ ਹੈ। ਤੁਹਾਨੂੰ ਆਪਣੇ ਅਟੱਲ ਡੇਟਾਬੇਸ ਆਰਕਾਈਵਜ਼ ਨੂੰ ਇੱਕ ਅਲੱਗ, ਏਅਰ-ਗੈਪਡ VPC ਜਾਂ VLAN ਵਿੱਚ ਬਹਾਲ ਕਰਨ ਨੂੰ ਆਟੋਮੇਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਬਹਾਲ ਕੀਤੇ ਡੇਟਾ ‘ਤੇ DBCC CHECKDB (SQL ਸਰਵਰ) ਜਾਂ pg_amcheck (PostgreSQL) ਚਲਾਓ ਤਾਂ ਜੋ ਢਾਂਚਾਗਤ ਅਖੰਡਤਾ ਦੀ ਪੁਸ਼ਟੀ ਕੀਤੀ ਜਾ ਸਕੇ।

ਸਿੱਟਾ

ਰੈਨਸਮਵੇਅਰ ਰੱਖਿਆ ਉਲੰਘਣਾ ਨੂੰ ਮੰਨਣ ਦਾ ਇੱਕ ਅਭਿਆਸ ਹੈ। ਜਦੋਂ ਤੱਕ ਤੁਹਾਡੇ SIEM ਵਿੱਚ ਕੋਈ ਅਲਰਟ ਵੱਜਦਾ ਹੈ, ਖਤਰੇ ਵਾਲੇ ਅਦਾਕਾਰਾਂ ਨੇ ਸ਼ਾਇਦ ਪਹਿਲਾਂ ਹੀ ਤੁਹਾਡੇ ਬੈਕਅੱਪ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨਾਲ ਸਮਝੌਤਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਹੋਵੇਗੀ। ਕੰਪਲਾਇੰਸ ਮੋਡ ਵਿੱਚ ਅਟੱਲ ਸਟੋਰੇਜ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਆਪਣੇ ਡੇਟਾਬੇਸ ਆਰਕਾਈਵਜ਼ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਕੇ, ਤੁਸੀਂ ਹਮਲਾਵਰਾਂ ਤੋਂ ਉਨ੍ਹਾਂ ਦਾ ਮੁੱਖ ਲਾਭ ਖੋਹ ਲੈਂਦੇ ਹੋ। ਭਾਵੇਂ ਤੁਸੀਂ ਮੂਲ ਕਲਾਉਡ APIs, ZFS ਹੋਲਡਸ, ਜਾਂ CloudSave ਵਰਗੇ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਆਰਕੈਸਟ੍ਰੇਸ਼ਨ ਪਲੇਟਫਾਰਮ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ, WORM ਸਟੋਰੇਜ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਹੁਣ ਵਿਕਲਪਿਕ ਨਹੀਂ ਹੈ—ਇਹ ਆਧੁਨਿਕ ਡੇਟਾਬੇਸ ਪ੍ਰਸ਼ਾਸਨ ਅਤੇ ਆਫ਼ਤ ਰਿਕਵਰੀ ਦਾ ਇੱਕ ਲਾਜ਼ਮੀ ਥੰਮ੍ਹ ਹੈ।

Categories