讀資料保護：工作負載的可恢復性01資料所面臨的風險

躺柒發表於2024-12-02
負載

1. 3-2-1原則

1.1. 每份資料做三個副本

1.2. 放到兩種介質上

1.3. 其中一份放在遠處

1.4. 3-2-1原則是所有備份工作的基礎原則

2. 資料保護即服務

2.1. Data-Protection-as-a-Service,DPaaS

2.2. 資訊保安是一個跟資料保護完全不同的學科

3. 軟體即服務

3.1. Software as a Service

3.2. SaaS

4. 為什麼要把這麼多錢投到備份與災難恢復上？​

4.1. 資料備份是一件很重要的事

  • 4.1.1. 假如不做備份，那麼將無法恢復資料

4.2. 備份本身並不是重點，重點在於必須有備份，才能夠從中恢復資料

  • 4.2.1. 沒人關心你能不能備份

  • 4.2.2. 只關心你能不能從備份中恢復資料

4.3. 不做備份的人，不太可能在資料保護工作方面成功

4.4. 備份、恢復以及DR變得比原來更為重要，而且更復雜

4.5. 在設計資料保護系統之前，必須先把相關的需求收集到位

4.6. 人為錯誤

4.7. 機械故障或系統故障

4.8. 自然災害

5. 人為錯誤

5.1. 在大多數情況下，之所以要做資料恢復與災備，就是因為有人犯了錯誤，讓計算環境遭到破壞，這種錯誤可能是無心的，也可能是故意的

  • 5.1.1. 人難免犯錯

  • 5.1.2. 有時可能並沒有惡意，但卻把資料給刪除或破壞掉了，這就是我們要做備份的另一項原因

5.2. 操作失誤

  • 5.2.1. 人總是會失誤

    • 5.2.1.1. 可能會把錯誤的檔案複製到錯誤的地方

    • 5.2.1.2. 拿一份沒用的檔案把一份有用的檔案覆蓋掉

  • 5.2.2. user error

    • 5.2.2.1. 使用者錯誤或使用者操作失誤

    • 5.2.2.2. IT部門中的系統管理員、網路管理員與資料管理員，同樣容易出這種錯誤

      5.2.2.2.1. 拿到管理員許可權相當於擁有一把利劍，如果砍錯了方向，可能會造成嚴重的後果

      5.2.2.2.2. 之所以要備份資料，一個很重要的原因就在於應對管理員的失誤

  • 5.2.3. PEBKAC

    • 5.2.3.1. Problem Exists Between Keyboard And Chair

      5.2.3.1.1. 問題出在鍵盤和椅子之間

  • 5.2.4. 把資料裡面不該刪的資料表給刪了

  • 5.2.5. 把不該格式化的盤（即一個本來毫無問題的盤）給格式化了

  • 5.2.6. 把開發用的資料庫恢復到了生產用的資料庫（即給實際產品用的資料庫）上

  • 5.2.7. 本來想寫個指令碼把那些用不到的home目錄給刪掉，結果這個指令碼把每一位使用者的home目錄全都刪掉了

  • 5.2.8. 把不該刪的虛擬機器(Virtual Machine, VM)給刪了

5.3. 程式碼錯誤

  • 5.3.1. 程式碼錯誤到處都有

    • 5.3.1.1. 軟體通常也會執行在許可權較高的模式下，因此有可能會損壞大量資料

    • 5.3.1.2. 由於那種軟體會有成百上千的公司安裝，因此其中如果隱藏著什麼問題，那麼一旦爆發，就會造成相當大的危害

5.4. 惡意攻擊

  • 5.4.1. 有人故意要搞破壞

  • 5.4.2. 惡意攻擊資料中心，是經常發生的事情

  • 5.4.3. 真正的敵人就是那些想透過某種形式的電子攻擊來破壞這個組織的人

  • 5.4.4. 絕不會知道網路攻擊會從哪裡發起

  • 5.4.5. 每次更新軟體時都應該先驗證，看它是否有安全漏洞（或者說安全隱患）

  • 5.4.6. 備份資料保留得比現有計劃稍長一些

5.5. 恐怖攻擊

  • 5.5.1. 恐怖攻擊是你必須遵循3-2-1原則的另一個理由

  • 5.5.2. 如果放置資料庫副本的伺服器離主站只有數百碼（1碼=0.9144米）​，那這種DR方案就不夠穩妥

    • 5.5.2.1. 其中一套備份放在距離受保護的資料比較遠的地方

    • 5.5.2.2. Disaster Recovery，DR

      5.5.2.2.1. 災難恢復

5.6. 電子攻擊

  • 5.6.1. 你的組織更有可能遭受的，應該是某種形式的電子攻擊（也叫網路攻擊）

  • 5.6.2. 入侵手段根本就都沒有利用防火牆的漏洞，它們利用的都是人的某種弱點，以促使員工自己去開啟這個後門

    • 5.6.2.1. 透過網路釣魚(phishing)或者社交欺騙的手段安插的，攻擊者會利用這些手段，誘導員工把惡意程式碼直接下載到他的工作環境裡面

  • 5.6.3. 攻擊者透過給手機充電的線纜來部署惡意軟體

5.7. 勒索軟體

  • 5.7.1. ransomware

  • 5.7.2. 如果針對的是個人，那可能是幾百美元，如果針對的是比較大的組織，那可能是上百萬美元

  • 5.7.3. 惡意軟體與勒索病毒已經橫行很久了

  • 5.7.4. RaaS

    • 5.7.4.1. Ransomware-as-a-Service，勒索病毒即服務

    • 5.7.4.2. 讓很多人都能相當輕易地發起勒索攻擊

    • 5.7.4.3. 你只要說出自己想攻擊誰，並提供一些有助於入侵的資訊，他們就會幫你執行勒索攻擊

      5.7.4.3.1. 這樣的犯罪團伙完全是為了謀利，他們會從勒索到的錢財裡面分走很大一部分

    • 5.7.4.4. RaaS出現之後，就不再有這個障礙了，只要知道怎樣進入暗網(dark web)並聯絡到提供RaaS的團伙，就可以發動勒索攻擊

    • 5.7.4.5. 勒索病毒也隨著RaaS模式的興起變得越來越猖狂，這種攻擊對資料造成的風險與日俱增

5.8. 內部威脅

  • 5.8.1. 很多組織都沒有對從內部發起的攻擊做好準備，其實這種攻擊也會給資料帶來損失

  • 5.8.2. 就算某些攻擊不是從內部發起的，它也需要內部因素的配合才能實現

  • 5.8.3. 最常見的內部威脅，來自對本組織不滿的正式員工或合同工，他們會利用手中的許可權來損害公司的財產

  • 5.8.4. rogue admin（​“流氓”管理員）問題

    • 5.8.4.1. 擁有特權，因此能夠悄悄地對資料造成極大破壞

    • 5.8.4.2. 植入一些能夠在自己離職之後，繼續破壞原公司資料的程式碼

    • 5.8.4.3. Yung-Hsun Lin（音譯：林永勳）事件

      5.8.4.3.1. 2004年給公司的70臺伺服器安裝了所謂的“邏輯炸彈”(logic bomb)

      5.8.4.3.2. 是一個指令碼，他怕公司將其解僱，所以編寫了這個指令碼，一旦公司把他炒掉，他就透過觸發該指令碼來刪除伺服器中的所有資料，以此報復公司

      5.8.4.3.3. 於2006年獲罪

    • 5.8.4.4. 如果有人能不受限制地使用Windows系統的Administrator（管理員）賬戶、UNIX與Linux系統的root（根）賬戶或其他作業系統中的類似賬戶，那麼就能輕而易舉地變身為一個rogue admin，讓你很難追查他所造成的破壞

  • 5.8.5. 系統管理員擁有很高的許可權。因此你必須盡力限制這些擁有特權的人在做出惡意行為時有可能波及的範圍

    • 5.8.5.1. 讓他們總是以自己的身份登入系統

      5.8.5.1.1. 每個人都應該用自己的名字登入

      5.8.5.1.2. 就算要獲取root或Administrator許可權，也必須先以自己的名字登入，然後再透過某種留存有記錄的機制來獲取管理許可權

      5.8.5.1.3. 儘量限制或阻止他們使用那種必須以root或Administrator身份執行的工具

    • 5.8.5.2. 不要把root密碼告訴任何人

      5.8.5.2.1. 把root或Administrator賬戶的密碼設定成一個隨機的字串，沒有人知道這個字串具體是什麼

      5.8.5.2.2. 為了讓想要獲取root或Administrator許可權的人，必須先以自己的身份登入，然後再透過sudo或Run as Administrator（以系統管理員身份執行）等手段來獲取管理許可權

      5.8.5.2.3. 所有的操作都會留有記錄

    • 5.8.5.3. 刪除或禁用那種能夠提供shell環境（命令列執行環境）的程式

      5.8.5.3.1. 使用者以root身份執行vi，那麼就可以透過這個機制進入一個有root許可權的shell介面，並在其中不被記錄地執行任意命令

    • 5.8.5.4. 讓超級使用者只能透過控制檯登入

      5.8.5.4.1. 使用者只能透過控制檯(console)登入

      5.8.5.4.2. 一定要把能夠實際接觸到控制檯的訪問行為記錄下來

      5.8.5.4.3. 針對虛擬控制檯的訪問行為記錄下來

    • 5.8.5.5. 啟用主機之外的記錄機制

      5.8.5.5.1. 凡是有人訪問超級使用者的賬戶（無論這次訪問是否經過授權）​，都應該記錄成一次安全事件，並把相關資訊（例如影片監控畫面或針對虛擬控制檯而設的日誌）穩妥地儲存下來，讓網路入侵者無法刪除這份證據

      5.8.5.5.2. 就算有人想要破壞系統，他也不可能輕易地抹除自己的蹤跡

    • 5.8.5.6. 不讓計算機從其他啟動盤裡啟動

      5.8.5.6.1. 儘量設法阻止使用者從系統盤之外的其他啟動盤啟動伺服器或虛擬機器

  • 5.8.6. 將各種許可權分離

    • 5.8.6.1. 備份與DR系統是最後一道防線，因此應該由完全不同的一方來管理，而且你不能讓這個管理方有機會破壞你所要保護的基礎設施

  • 5.8.7. 基於角色的管理

    • 5.8.7.1. role-based administration

    • 5.8.7.2. 把資料保護系統裡面的各個部分交給不同的人來管理，這些人各自具備不同的權力

    • 5.8.7.3. 把備份策略的配置權（也就是定義權）與操作權（也就是執行權）分開，能夠限制其中一方所擁有的權力

      5.8.7.3.1. 一種角色可能擁有日常的備份操作權，也就是說，此類人員可以執行預先定義好的備份任務

      5.8.7.3.1.1. 這些人無權修改備份策略

      5.8.7.3.2. 備份策略的修改權，掌握在另一種角色的手裡，然而他們雖然能修改備份策略

      5.8.7.3.2.1. 無權執行這些策略

    • 5.8.7.4. 恢復工作可能會由一個與上述兩者完全不同的角色負責

      5.8.7.4.1. 以防止此類人員利用資料恢復功能，將資料洩漏到本組織之外

    • 5.8.7.5. 從安全形度看，最好能把備份系統中的每個角色指派給不同的人

      5.8.7.5.1. 並不能完全消除來自內部的威脅，但確實可以大幅降低這種機率

  • 5.8.8. 最低許可權

    • 5.8.8.1. 一定要保證每個人與每個程式都只獲得了執行其工作所必需的許可權，而沒有獲得與其工作無關的許可權

  • 5.8.9. 多人認證機制

    • 5.8.9.1. 多人認證/多人授權(multiperson authentication)機制

    • 5.8.9.2. 多重認證（multifactor authentication，也叫多因素認證）機制

      5.8.9.2.1. 在執行某項操作之前，必須同時獲得兩人同意

      5.8.9.2.2. 四眼授權(four-eyes authentication)，因為會有兩雙眼睛盯著這個事情

    • 5.8.9.3. 某些資料保護產品要求使用者同時獲得兩個人的許可，如此才能執行恢復操作、修改備份策略或減少某個備份的保留時間

6. 機械故障或系統故障

6.1. 關鍵的工作資料現在都儲存在某種形式的固態介質上

6.2. 儲存裝置比原來更加健壯，而且任何一個重視資料的資料中心，都會配備RAID這樣的冗餘儲存機制以及糾刪碼(erasure coding)技術

  • 6.2.1. 整個RAID陣列中的磁碟同時故障的情況相當少見，但也不是從來沒有發生過

6.3. 裝置的韌體裡面內建完整性檢查(integrity checking)邏輯，寧可讓資料無法儲存，也不讓磁碟發生故障

  • 6.3.1. 很少出現因為硬碟故障而恢復資料的情形，但這並不意味著這種情形絕不會發生

6.4. 目前的系統與資料庫已經能夠應對許多資料問題，因此由物理故障及系統故障所造成的資料損失，應該不會很常見

  • 6.4.1. 很少遇到這種因發生機械故障而必須恢復資料的情形，但這樣的情形確實存在

6.5. 電力中斷

  • 6.5.1. 任何一個頗具規模的資料中心，都會有冗餘電源與大型發電機

  • 6.5.2. 結構化的資料基本上應該不會受到破壞，因為資料庫有內建的資料完整性檢查機制，不會讓結構上有問題的資料寫到資料庫裡面

  • 6.5.3. 無結構的資料（也叫非結構化的資料）基本上也應該沒事，只是停電那一刻正在寫入的少數幾個檔案可能會有點問題

6.6. 雲平臺沒有那麼神奇

  • 6.6.1. 並沒有所謂雲(cloud)這個東西，它還是得依靠別人的計算機來實現

  • 6.6.2. 雲平臺沒有那麼神奇，它本質上還是一批給你提供服務的計算機而已

  • 6.6.3. 雲平臺所支援的各種資料儲存機制，從資料保護的角度看，是有所區別的

    • 6.6.3.1. 採用物件儲存(object storage)機制來儲存的資料，可以在多個位置上存留多份副本，因此能夠經受多次事故

    • 6.6.3.2. 採用塊儲存(block storage)機制來儲存的資料，則只是虛擬驅動器裡面的一個LUN（Logical Unit Number，邏輯單元號）​，這個虛擬的驅動器僅位於某一間資料中心的某一個儲存陣列裡面

      6.6.3.2.1. 這種儲存方式沒有任何冗餘機制，因此採用該方式儲存的資料必須加以備份

6.7. 系統故障

  • 6.7.1. 無論你用的是僅依賴某一個儲存陣列的單一伺服器（由不同位置的多個資料中心所構成的大型伺服器叢集）​，還是由雲端所提供的服務，都無法保證其完美無缺

  • 6.7.2. 軟體與硬體未必總是按照預想的方式運作，因此我們必須做備份

7. 自然災害

7.1. 自然災害是我們必須遵循3-2-1原則的一個重要原因

7.2. 計算機不僅怕水，它還怕火

7.3. 水災

  • 7.3.1. 資料中心可能受各種原因影響而發生水患

  • 7.3.2. 就洪水這一因素而言，資料儲存得越高越好

  • 7.3.3. 要確保DR站完全位於洪水的波及範圍之外

  • 7.3.4. 把DR站放在距離主站較近的位置，但是要保證它比主站更高

7.4. 火災

  • 7.4.1. 燒燬資料中心的不一定是山火，也有可能是那種因為短路而引發的火災

  • 7.4.2. 電路里面要有斷路器(breaker)，以便在短路時自動跳閘，然而這種斷路器未必總是能及時跳閘

  • 7.4.3. 火對資料中心會造成巨大損害

  • 7.4.4. 有許多種與備份及資料恢復無直接關係的辦法，均能防止資料中心失火

  • 7.4.5. 防火也是我們要備份資料的一項原因

7.5. 地震

  • 7.5.1. 應對地震，關鍵是要做好準備

    • 7.5.1.1. 建築方面的法規也要求建築物裡面的東西必須綁住。就連熱水器也是綁住的

    • 7.5.1.2. 資料中心的機架（rack，也叫機櫃）放在防震座上，讓我們可以在地板出現震動的情況下移動機架

  • 7.5.2. 確保DR站位於傷害範圍之外

    • 7.5.2.1. 由於地震的傷害範圍通常會侷限在某一個區域內，因此這一點並不是很難做到

7.6. 颶風、颱風、旋風

  • 7.6.1. 應對颶風的關鍵在於把DR計劃所依據的系統，放在完全不受颶風侵擾的地方

7.7. 龍捲風

  • 7.7.1. 龍捲風是一種猛烈的旋轉風暴，它會把巨大的破壞力集中在某一點上

  • 7.7.2. 應對龍捲風的關鍵，也在於讓DR站遠離頻發龍捲風的地帶

7.8. 落水洞

  • 7.8.1. 又叫滲穴、天坑

  • 7.8.2. 這種災害能夠像龍捲風那樣，對某地施以外科手術式的打擊，同時又像地震那樣無法預測

  • 7.8.3. 經歷過龍捲風的人，會說風颳得跟貨運車經過時一樣，而落水洞則是突然出現的，它不聲不響地帶來巨大傷害

  • 7.8.4. DR站一定要放在遠離主站的地方

  • 7.8.5. 從每平方英里的角度看，落水洞的出現數量似乎很少，但問題在於，這種現象隨時有可能發生

相關文章