讀資料工程之道：設計和構建健壯的資料系統31安全和隱私

1. 安全和隱私

1.1. 安全在資料工程的執行層面至關重要

• 1.1.1. 安全需要成為一種思想和行動的習慣

• 1.1.2. 安全是隱私立足的根本

1.2. 資料安全是資料工程師在其工作和資料工程生命週期的每個階段需要考慮的首要問題

• 1.2.1. 資料工程師的安全和隱私職責在不同的組織中會有很大的不同

• 1.2.2. 對待資料應當像對待錢包或智慧手機那樣

• 1.2.3. 雖然你不可能負責你公司的安全，但瞭解基本的安全措施並將安全放在首位，將有助於減少你的組織發生資料安全漏洞的風險

1.3. 一個安全漏洞或資料洩露就會使業務陷入困境

1.4. 隱私對於企業資訊科技領域的可信任度一直都很重要

• 1.4.1. 包括財務資訊、私人通訊資料（電子郵件、簡訊、電話）​、醫療記錄、教育記錄和工作經歷

1.5. 隱私逐漸成為具有重要法律意義的問題

• 1.5.1. 由於資料系統與教育、醫療和商業的結構交織在一起，資料工程師處理的很多敏感資料與這些法律相關

2. 人員

2.1. 安全和隱私中最薄弱的環節是操作者本身

2.2. 安全防線往往在人面前失效，所以要從盯防自己開始

2.3. 惡意的程式或人類會時刻試圖滲透你的敏感證書和資訊，這就是雷打不動的現實

2.4. 線上上和線下的一切操作都要多加小心，並堅持發揮逆向思維的力量

2.5. 逆向思維的力量

• 2.5.1. 正向思維會使我們對恐怖襲擊或緊急救護情況準備不足

• 2.5.2. 逆向思維使我們能夠考慮災難的發生，並採取相應行動

• 2.5.3. 保護私人和敏感資料的最好方法就是避免獲取它們

• 2.5.4. 在決定安全策略時要確保策略能真正保證安全，而不僅是看起來安全

2.6. 永遠多想一步

• 2.6.1. 當被索要憑證時，一定要謹慎

• 2.6.1.1. 對索要憑證的行為應該持充分懷疑態度並詢問同事和朋友的意見

• 2.6.1.2. 當被索要憑證、敏感資料或機密資訊時，不要輕易相信任何人

• 2.6.2. 要確保工作內容既合法又符合道德

• 2.6.2.1. 作為尊重隱私和道德的第一道防線，如果你對所負責收集的敏感資料感到不舒服，對專案中處理資料的方式有道德上的疑問，那就向同事和領導提出你的擔憂

3. 流程

3.1. 當人們遵循常規的安全流程時，工作內容就變得更安全

• 3.1.1. 讓安全成為一種習慣，多進行真正的安全實踐，遵守最小特權原則，並理解雲的責任共擔模式

3.2. 企業客戶普遍關注合規性（內部規則、法律、標準機構的建議）​，但對潛在的不利因素關注不夠

3.3. 表演式的安全

• 3.3.1. 按照合規性（SOC-2、ISO 27001等）的劇本表演，根本沒有落實責任

3.4. 安全需要足夠簡單有效，從而能夠在整個組織持續推行

• 3.4.1. 要追求真正的和習慣性的安全精神，將安全思想融入文化中

• 3.4.2. 安全不需要太複雜

• 3.4.3. 踐行安全，人人有責，責任重於泰山

3.5. 主動安全

• 3.5.1. 運用逆向思維，實施主動安全需要在動態和不斷變化的世界中思考和研究安全威脅

• 3.5.2. 研究成功的網路釣魚攻擊來反思組織內的安全漏洞，而不是簡單地進行打好招呼的模擬網路釣魚攻擊

• 3.5.3. 積極排查組織內部的漏洞，研究潛在的員工洩露或濫用私人資訊誘因，而不是簡單地填寫死板的合規性檢查表

3.6. 最小特權原則

• 3.6.1. 意味著人或系統應該只有必要的許可權和資料

• 3.6.2. 只需要少量的IAM角色就足夠了

• 3.6.2.1. 只為使用者（或他們所屬的組）提供需要的IAM角色，不需要這些角色時就收回

• 3.6.3. 只在需要的時候給予必要的許可權和資料

• 3.6.4. 最小特權原則對隱私也很關鍵

• 3.6.4.1. 他們的敏感資料只在必要的時候才能訪問到

• 3.6.4.2. 對敏感資料實施列、行和單元格級別的訪問控制

• 3.6.4.3. 建立只包含檢視者需要訪問的資訊的檢視

• 3.6.4.4. 把資料放在緊急情況才能啟用的程式之下，使用者只有在緊急審批後才能訪問這些資料，以解決問題或者查詢關鍵的歷史資訊等

>  3.6.4.4.1. 一旦工作完成，許可權就會立即收回

3.7. 雲服務的責任共擔

• 3.7.1. 安全是雲中的共同責任

• 3.7.2. 雲供應商負責確保其資料中心和硬體的物理層面的安全

• 3.7.3. 開發者也要對雲中建立和維護的應用程式和系統的安全負責

• 3.7.4. 漏洞發生的原因可能是無意間的錯誤配置、失誤、疏忽和馬虎

3.8. 始終備份資料

• 3.8.1. 資料是會消失的

• 3.8.1.1. 壞盤或者伺服器當機

• 3.8.1.2. 誤刪除資料庫或物件儲存桶

• 3.8.1.3. 惡意入侵者鎖住資料

>  3.8.1.3.1. 保險公司正在減少對這類事件的賠付，使你既要恢復資料，又要付贖金

• 3.8.2. 要定期備份資料，為了災備，也是為了業務連續性，防止某個版本的資料在勒索軟體攻擊中被破壞

• 3.8.2.1. 定期測試資料備份的恢復情況

• 3.8.3. 嚴格意義上講資料備份並不屬於安全和隱私實踐，它屬於災難預防這一更大的主題

3.9. 安全政策實踐

• 3.9.1. 保護你的憑證

• 3.9.1.1. 不惜一切代價保護你的憑證

• 3.9.1.2. 一切都使用單點登入

>  3.9.1.2.1. 儘可能避免使用密碼，並將SSO作為預設設定

• 3.9.1.3. 儘可能避免使用密碼，並將SSO作為預設設定

• 3.9.1.4. 不要共享密碼或憑證，包括客戶的密碼和憑證

• 3.9.1.5. 小心網路釣魚和詐騙電話，永遠不要透露密碼

• 3.9.1.6. 禁用或刪除舊的憑證，最好刪除

• 3.9.1.7. 不要把你的憑證放在程式碼中

• 3.9.1.8. 始終堅持最小特權原則

• 3.9.2. 保護裝置

• 3.9.2.1. 管理所有員工使用的裝置

>  3.9.2.1.1. 如果有員工離開公司或丟失裝置，可以遠端擦除裝置

• 3.9.2.2. 對所有裝置使用多因素認證

• 3.9.2.3. 使用你的公司電子郵件憑證登入到裝置

• 3.9.2.4. 所有涉及憑證和行為的政策都適用於你的裝置

• 3.9.2.5. 把你的裝置當作你自己的延伸

>  3.9.2.5.1. 不要讓你指定的裝置離開你的視線

• 3.9.2.6. 在螢幕共享時，要注意你到底在共享什麼，以保護敏感資訊和通訊

>  3.9.2.6.1. 只共享單個檔案、瀏覽器標籤或視窗，避免共享你的整個桌面

>  3.9.2.6.2. 只分享傳達你的觀點所需的內容

• 3.9.2.7. 在視訊通話時使用勿擾模式

>  3.9.2.7.1. 防止在通話或錄音中出現彈框、提示音等打擾

• 3.9.3. 軟體更新策略

• 3.9.3.1. 當你看到更新提示時，重新啟動瀏覽器

• 3.9.3.2. 在公司和個人裝置上執行小型作業系統更新

• 3.9.3.3. 讓公司來確定關鍵的主要作業系統更新並提供指導

• 3.9.3.4. 不要使用作業系統的測試版

• 3.9.3.5. 在作業系統重大版本釋出後等待1～2個星期再用

4. 技術

4.1. 系統補丁和更新

• 4.1.1. 軟體會變得陳舊，安全漏洞也不斷會被發現

• 4.1.2. 為了避免暴露所使用工具的舊版本的安全漏洞，當有新的更新時，一定要給作業系統與軟體打補丁和更新

• 4.1.3. 要更新程式碼和依賴關係，可以自動構建或者設定版本釋出和漏洞警報，以便提示手動執行更新

4.2. 加密

• 4.2.1. 加密不是萬能的，當人為的安全漏洞暴露了憑證時它就失效了

• 4.2.2. 加密是所有重視安全和隱私的組織的基本要求

• 4.2.2.1. 可以防止基本的攻擊，如網路流量攔截

• 4.2.3. 靜態加密

• 4.2.3.1. 確保資料在靜態（在儲存裝置上）時被加密

• 4.2.3.2. 公司筆記本計算機應該啟用全盤加密，可以在裝置被盜時保護資料

• 4.2.3.3. 對儲存在伺服器、檔案系統、資料庫和雲中物件儲存中的所有資料實施伺服器端加密

• 4.2.3.4. 所有用於存檔的資料備份也應該加密

• 4.2.3.5. 在應用程式層面也進行加密

• 4.2.4. 傳輸加密

• 4.2.4.1. 傳輸加密是目前各種協議的預設配置

• 4.2.4.2. HTTPS通常是現代雲API的要求

• 4.2.4.3. 不當的金鑰使用是資料洩露的重要原因

>  4.2.4.3.1. 如果儲存桶的許可權對公網開放，則HTTPS對保護資料毫無幫助，這也是過去十年中幾起資料洩露醜聞發生的原因

• 4.2.4.4. FTP在公共網路上根本不安全

>  4.2.4.4.1. 最好的辦法是直接避免使用FTP

• 4.2.4.5. 要確保傳輸加密的全覆蓋，傳統協議也不例外

>  4.2.4.5.1. 如果不確定是否做到了加密，就使用那些帶有加密功能的穩定技術

4.3. 日誌、監控和警報

• 4.3.1. 駭客和入侵者通常不會宣佈他們正在滲透你的系統

• 4.3.1.1. 大多數公司在事後才發現安全事故

• 4.3.2. 觀測、檢測和警告事件是DataOps的組成部分

• 4.3.2.1. 設定自動監控、日誌和警報，以便能夠及時發現系統中的異常事件

• 4.3.3. 監控要點

• 4.3.3.1. 訪問

>  4.3.3.1.1. 誰在訪問什麼，什麼時候，從哪裡訪問？

>  4.3.3.1.2. 有哪些新的訪問許可權被授予？

>  4.3.3.1.3. 現有使用者的異常行為模式可能表明他們的賬戶被入侵了

• 4.3.3.2. 資源使用

>  4.3.3.2.1. 監控磁碟、CPU、記憶體和I/O，看看是否有不正常的使用模式

>  4.3.3.2.2. 資源使用是否有重大變動？

  >   4.3.3.2.2.1. 如果是的話，則很可能存在安全漏洞

• 4.3.3.3. 計費

>  4.3.3.3.1. 對於SaaS和雲託管服務，需要監督成本

>  4.3.3.3.2. 設定預算警報來確保不超支

>  4.3.3.3.3. 如果賬單中突然出現了計劃外的大筆花費，則可能有人或程式在竊取資源進行惡意操作

• 4.3.3.4. 過寬鬆的許可權

>  4.3.3.4.1. 越來越多的供應商提供工具來監控使用者或服務賬戶在一段時間內未使用的許可權

>  4.3.3.4.2. 最好在監控中結合這些方面的內容以獲得你的資源、訪問和計費概況的全景圖

>  4.3.3.4.3. 要定期演練，有備無患

4.4. 網路訪問控制

• 4.4.1. 原則上，網路安全應該由公司的安全專家來負責

• 4.4.2. 在實踐中，資料工程師可能需要在小公司裡承擔網路安全的責任

• 4.4.3. 資料工程師經常會用到資料庫、物件儲存和伺服器，因此至少應該瞭解一些簡單的措施確保符合網路訪問控制的安全實踐

• 4.4.3.1. 要鼓勵每個資料工程師積極參與安全工作，當他們在系統中發現潛在的安全風險時應該思考解決措施，並積極參與部署這些措施

• 4.4.4. 僅允許訪問這些埠的系統和使用者傳入IP地址（又稱白名單IP）​，並避免在任何情況下廣泛地開放連線

• 4.4.5. 當訪問雲或SaaS工具時使用加密的連線

• 4.4.6. 雲通常更接近於零信任安全

• 4.4.6.1. 每個操作都需要身份驗證

• 4.4.6.2. 對於大多陣列織來說，雲是一個更安全的選擇，因為它實踐了零信任，讓公司享受公有云的安全工程師團隊的服務

• 4.4.7. 有時強化邊界安全仍然是有意義的

• 4.4.7.1. 內網伺服器是強化邊界安全的最終例子

• 4.4.7.2. 即使是本地部署，內網伺服器同樣容易受到人為安全事故的影響

4.5. 資料工程底層系統的安全

• 4.5.1. 每一個元素的安全影響是至關重要的

• 4.5.1.1. 不能放鬆鏈條上的任何一個環節

• 4.5.2. 任何軟體庫、儲存系統或計算節點都是潛在的安全漏洞

• 4.5.2.1. 一個不明顯的日誌庫的缺陷可能允許攻擊者繞過訪問控制或加密

• 4.5.2.2. CPU架構和微程式碼也是潛在的漏洞

• 4.5.2.3. 敏感資料在記憶體或CPU快取中靜止時也可能受到攻擊