S3 備份與版本控制和生命週期管理以防止惡意刪除備份?
我只是想由一些更聰明的人來執行這個想法,以確保我不會忽略一些明顯的事情:
我想使用允許自動修剪備份的眾多備份腳本之一將我的 Linux 伺服器備份到 S3。因此,我的 S3 IAM 策略顯然必須授予該使用者 GET、PUT 和 DELETE 權限。但由於 DELETE 權限將在那裡,我需要針對最壞的情況進行計劃,即黑客獲得對我的伺服器的 root 訪問權限並使用儲存的憑據刪除 S3 上的備份。為了消除這種可能性,我正在考慮以下配置:
- 在儲存桶上啟用了版本控制(黑客可以刪除文件,但它們僅在 S3 上標記為已刪除並且可由我恢復)
- 桶上啟用生命週期策略自動刪除舊版本(最終消除文件的所有版本以最小化儲存成本)
然後,唯一擁有儲存桶刪除或版本刪除權限的使用者將是我的主要 Amazon 賬戶使用者,我將使用 MFA 對其進行配置。
我在這裡遺漏了什麼明顯的東西嗎?
我確實發現這聲稱…
您可以使用對象過期功能
$$ … $$但是,您不能將它與 S3 版本控制結合使用
…我認為這是過時的資訊?在我的快速非正式實驗中,似乎可以將版本控制與對象過期一起使用。
非常感謝!
是的,您連結的博文(自 2011 年起)似乎包含過時的資訊。從文件:
如果儲存桶啟用了版本控制(或版本控制已暫停),則該
Expiration
操作通過添加刪除製造商作為新的目前版本來邏輯刪除目前版本。該NoncurrentVersionExpiration
操作將永久刪除非目前版本。http://docs.aws.amazon.com/AmazonS3/latest/dev/ObjectExpiration.html
您的計劃的唯一問題是刪除已刪除對象(以節省儲存空間)的生命週期策略與針對惡意刪除內容的災難恢復保護有些不一致。您必須快速發現漏洞,否則生命週期策略會清除您明顯已刪除但實際上隱藏的對象。
這並不是說您的策略在理論上不好——我建議它是,因為我使用了類似的東西——但是不再需要的對象的清除可能需要比生命週期策略所能提供的更複雜,並且可能需要按計劃執行並具有附加規則的自定義邏輯。