返回文章列表
玄貓（BlackCat）

資料安全治理入門與AWS實踐

本文探討現代資料安全與治理的挑戰，涵蓋個人資料保護、加密技術、匿名化和假名化資料處理，以及驗證機制。文章深入解釋了傳輸中加密和靜態加密的區別，並闡述匿名化和假名化資料處理的優缺點。此外，文章也討論了資料目錄的重要性，說明如何避免資料沼澤，並提供 AWS Glue 和 Lake Formation

資料工程 資安
資料安全 資料治理 AWS 加密 IAM 資料目錄

現代資料應用中，資料安全和資料治理至關重要。個人資料保護在 GDPR 等法規下受到嚴格規範，加密技術成為保護資料安全的關鍵。資料在傳輸和儲存過程中都應加密，以防止未經授權的存取。此外，匿名化和假名化技術可以降低資料洩露的風險，同時保留資料的分析價值。建立完善的驗證機制，確保只有授權使用者才能存取敏感資料。資料目錄的建立有助於避免資料沼澤，方便使用者查詢和理解資料集。最後，透過 AWS 等雲端服務，可以更有效地實施資料安全和治理策略，例如使用 KMS 管理金鑰、Macie 偵測敏感資料、GuardDuty 監控威脅，以及 IAM 管理身份和許可權。

資料安全與治理入門101：個人資料保護與加密技術

在現代數位時代，資料安全和治理成為企業與組織面臨的重要挑戰。其中，個人資料（Personal Data）的保護更是在GDPR（General Data Protection Regulation）等法規下被嚴格規範。本文將探討個人資料的定義、加密技術、匿名化與假名化資料處理，以及驗證機制等關鍵議題。

個人資料的定義與重要性

根據GDPR的定義，個人資料是指任何與已識別或可識別的自然人（資料主體）相關的資訊。可識別的自然人是指能夠直接或間接被識別的人，特別是透過諸如姓名、身份證號碼、位置資料、線上識別碼，或是與該自然人的生理、心理、基因、經濟、文化或社會身份相關的特定因素來識別。

加密技術：保護資料安全的關鍵

加密是一種數學技術，透過使用金鑰將資料編碼，使其變得不可辨認和無法使用。授權使用者擁有金鑰，可以解密資料並還原其原始形式。雖然理論上駭客可以在沒有金鑰的情況下透過計算資源、技能和時間來解密加密資料，但一個設計良好且安全的加密演算法可以大大增加解密的難度，從而提高資料的安全性。

傳輸中加密與靜態加密

  • 傳輸中加密（Encryption in Transit）：在資料從一個系統傳輸到另一個系統的過程中進行加密。例如，從資料函式庫遷移到資料湖的過程中，資料在傳輸前應被加密，並在目標端點被解密。這種方式確保即使資料在傳輸過程中被攔截，也無法被讀取或使用。常見的實作方法是使用傳輸層安全（TLS）協定。

  • 靜態加密（Encryption at Rest）：對寫入儲存媒體（如磁碟）的資料進行加密。在每個資料處理階段結束後，所有持久化到磁碟的資料都應被加密。

匿名化與假名化資料處理

匿名化資料

匿名化是指對資料進行修改，使個人資料不可逆轉地去識別化，從而無法識別出任何個人可識別資訊（PII）。例如，用隨機產生的資料替換PII，或移除大部分PII，只保留少數屬性。然而，這種方法存在風險，因為即使只保留少量資料，也可能足以識別出個人。

假名化資料/標記化

假名化是指對個人資料進行修改，使其無法直接被歸屬到特定資料主體，除非使用單獨儲存的「附加資訊」。常見的方法包括用隨機產生的標記替換PII，並在安全的資料函式庫中記錄真實資料與標記之間的對應關係。這種方式允許在需要時將標記化的資料還原為原始PII。

驗證機制

驗證是指確認聲稱身份確實是該身份的過程。例如，在登入電子郵件帳戶時，使用者提供身份（電子郵件地址），然後透過密碼和可能需要的第二因素（如手機簡訊驗證碼）來驗證身份。

資料目錄建立、安全性和治理

身份驗證並不指定你可以存取哪些資源，但它嘗試驗證你是否真的是你所聲稱的那個人。當然，身份驗證系統並非萬無一失。你的密碼可能在其他網站上被洩露，如果你為Gmail帳戶使用了相同的密碼，別人就可以冒充你。如果你啟用了多因素身份驗證（MFA），你會在手機或實體MFA裝置上收到一個登入時需要輸入的程式碼，這有助於進一步確保和驗證你的身份。

授權與聯合身份

授權是根據已驗證的身份來授權存取某個資源的過程。例如，當你登入Google帳戶（透過密碼和可能傳送到手機的第二個因素程式碼進行身份驗證）時，你可能被授權存取該身份的電子郵件，也可能存取Google日曆和該身份的Google搜尋歷史。

對於資料分析系統，一旦你透過身份驗證驗證了你的身份，你就需要被授權存取特定的資料集。資料湖管理員可以，例如，授權你存取資料湖中Conformed Zone的資料，但不授予你存取Raw Zone中的資料。

聯合身份的工作原理

聯合身份是一個與身份驗證相關的概念，意味著對使用者進行身份驗證的責任由另一個系統承擔。例如，當登入AWS管理主控台時，管理員可以設定聯合身份，以便使用Active Directory憑據透過組織的存取入口網站登入，並由組織的Active Directory伺服器進行身份驗證。一旦透過身份驗證，Active Directory伺服器會向AWS管理主控台確認你已成功以特定使用者的身份透過身份驗證。這意味著你不需要為登入AWS系統而設定另一個使用者名稱和密碼，而是可以使用現有的Active Directory憑據在AWS中進行身份驗證。

正確實施資料保護和治理

正確實施資料保護和治理並非自動發生。重要的是，你要計畫並周密地執行保護和治理資料的過程。這將涉及使用一些前面介紹的概念，例如：

  • 確保在擷取後的第一個處理步驟中將個人識別資訊（PII）資料替換為符記（token），並確保符記化系統是安全的。
  • 使用眾所周知且可靠的加密演算法對所有靜態資料進行加密，並確保所有連線都使用安全的加密通道（例如，使用TLS協定進行系統之間的通訊）。

實施細節

  • 實施聯合身份，使用中央企業身份提供者（如Active Directory）對分析系統的使用者進行授權。這樣可以確保，例如，當使用者離開公司，其Active Directory帳戶被終止時，他們對AWS中分析系統的存取權也會被終止。
  • 實施最小許可權存取，使用者被授權執行其工作所需的最低許可權級別。

這也不是資料工程師應該單獨完成的事情。你應該與組織的安全性和治理團隊合作，以確保瞭解處理和分析資料所需的任何法律要求。你還應該定期審查或稽核針對分析系統和資料的安全性政策。

避免資料沼澤：建立資料目錄

即使你正確地保護了資料並按照當地法規處理它，如果你不能讓使用者輕鬆找到分析資料集並瞭解這些資料集的更多資訊，你的分析資料可能會成為負債。

資料沼澤的問題

你可能聽說過沼澤，即使你從未真正去過那裡。一般來說，沼澤被認為是氣味難聞的濕地，有些樹木和其他植被可能會在那裡生長，但該地區通常不適合大多數用途（除非你像史萊克一樣是個怪物，並且在沼澤中安家）。

與沼澤相反，當大多數人想到湖泊時，他們會想像出美麗的景色，有清澈的水、美麗的日落，也許還有幾隻鴨子在水面上悠閒地遊著。大多數人如果認為自己要去一個美麗的湖，卻發現那是一個沼澤的話，會感到厭惡。

資料湖與資料沼澤

在資料湖的世界裡，作為一名資料工程師，你希望提供一種類別似於前面描述的那種純淨而寧靜的湖泊的體驗，並且希望避免讓你的使用者發現這個湖更像是一個沼澤。然而，如果你不小心，你的資料湖可能會變成一個資料沼澤，那裡有很多不同的資料片段，但沒有人確定有什麼資料。那麼，當他們碰巧找到一些資料時，他們不知道這些資料從哪裡來，也不知道是否可以信任它。最終，資料沼澤可能成為一個對任何人都沒什麼用的資料傾倒場。

如何避免資料沼澤：資料目錄、安全性與治理

在進行大規模資料分析時，企業常常面臨著資料管理的挑戰。一個規劃良好的資料湖（data lake）可以提供結構清晰、易於導航的資料儲存，但如果缺乏適當的管理，很容易變成所謂的「資料沼澤」（data swamp）。要避免這種情況，需要仔細的前期規劃、合適的工具以及嚴格的政策。

避免資料沼澤的關鍵要素

要避免資料沼澤，主要需要兩個關鍵要素：

  1. 資料目錄（Data Catalog）：能夠對資料湖中的所有資料集進行可搜尋的記錄。
  2. 嚴格的後設資料管理政策：確保所有資料集在資料目錄中都有完整的後設資料。

資料目錄的功能與型別

資料目錄使業務使用者能夠輕鬆找到可能對他們有用的資料集，並透過後設資料更好地理解資料集的背景。廣義上，資料目錄分為兩種型別：業務目錄和技術目錄。

技術目錄

技術目錄主要對映資料湖中的資料檔案到資料函式庫和表格的邏輯表示。例如，AWS Glue是一種技術型的資料目錄工具，它能夠捕捉有關底層物理檔案和分割槽的資訊，使分析服務能夠理解資料集的結構，從而對資料進行查詢。

業務目錄

業務目錄則側重於捕捉有關資料集的業務後設資料，例如：

  • 資料集的所有者
  • 資料所屬的業務單位
  • 資料的來源系統
  • 資料的保密性分類別
  • 資料更新的頻率
  • 資料集之間的關聯性

大多數資料目錄工具都同時提供技術和業務目錄的功能，但通常會側重於其中一方面。例如，AWS Glue除了捕捉技術後設資料外，也可以透過鍵/值對來記錄業務屬性，如資料所有者、是否包含個人識別資訊（PII）等。

組織政策對於捕捉後設資料的重要性

雖然資料目錄提供了捕捉技術和業務後設資料的能力，但組織需要制定並執行相關政策，以確保每個資料集都有正確的後設資料被捕捉。例如，需要有政策確保所有新增到資料湖中的資料都被記錄在資料目錄中，並且包含必要的業務和技術後設資料。

AWS Glue/Lake Formation 資料目錄

AWS Glue和AWS Lake Formation都提供了與同一份資料目錄互動的介面。AWS Glue是一種技術型的資料目錄，可以透過鍵/值標籤捕捉一些業務屬性。瞭解這兩個服務分享同一份目錄對於有效地管理和使用資料至關重要。

圖示：AWS Glue 控制檯顯示表格屬性

此圖示顯示了在AWS Glue控制檯中，film_category 表格的詳細資訊，其中包含 zone:curated 標籤。

此圖示說明：

  • AWS Glue 控制檯中表格屬性的呈現方式
  • zone:curated 標籤表示該表格屬於 curated 區域

AWS 資料目錄、安全性與治理

資料目錄的重要性

AWS Glue/Lake Formation 的資料目錄是資料湖的核心元件，提供了一個集中式的元資料儲存函式庫，用於儲存和管理資料湖中的資料集的中繼資料。

Lake Formation 控制檯的功能

Lake Formation 控制檯提供了更現代化的設計和額外的功能，例如：

  • 在欄位層級新增鍵/值屬性（而 AWS Glue 只能在表格層級新增屬性）
  • 在資料函式庫、表格和欄位層級組態存取許可權

資料目錄的應用

資料目錄可以被各種分析工具參照，以便在資料湖中處理資料。例如，Amazon Athena 可以參照資料目錄，以便對資料函式庫和表格執行查詢。Athena 使用目錄取得以下資訊：

  • 底層資料檔案儲存在 Amazon S3 的位置
  • 指示底層檔案格式的中繼資料（例如 CSV 或 Parquet）
  • 序列化程式函式庫的詳細資訊，用於序列化底層資料
  • 提供每個欄位資料型別資訊的中繼資料
  • 資料集的分割區資訊

自動化資料目錄更新

資料工程師應該建立自動化工作流程，以確保所有新增的資料集都被編目，並且新增適當的中繼資料。這可以透過使用 AWS Glue Crawlers 實作，該工具可以檢查資料來源、推斷資料來源的結構描述，並自動將資訊填入 Glue 資料目錄中。

自動化中繼資料新增

自動化方法也應該用於確保在新增資料時新增相關的中繼資料，例如：

  • 資料來源
  • 資料擁有者
  • 資料敏感度（公開、一般、敏感、機密、PII 等）
  • 資料湖區域（原始區域、轉換區域、豐富區域）
  • 費用分配標籤（業務單位名稱、部門等）

AWS 資料加密和安全監控服務

AWS Key Management Service (KMS)

AWS KMS 簡化了在 AWS 中建立和管理用於加密和解密資料的安全金鑰的過程。AWS KMS 是一項核心服務，讓使用者能夠輕鬆地在多個 AWS 服務中管理資料加密。

Amazon Macie

Amazon Macie 是一項受管理的服務，使用機器學習和模式匹配來發現和保護敏感資料。Macie 可以識別 Amazon S3 儲存桶中的敏感資料，例如 PII 資料，並提供警示以警告管理員。

Amazon GuardDuty

Amazon GuardDuty 是一項智慧型威脅偵測服務，使用機器學習來監控 AWS 帳戶並提供主動式警示關於惡意活動和未授權行為。GuardDuty 分析多個 AWS 生成的日誌，包括 CloudTrail S3 資料事件、CloudTrail 管理事件、VPC 流日誌和 DNS 日誌。

AWS 身份與許可權管理服務

在前面的章節中，我們定義了身份驗證（authentication）為驗證聲稱的身份是否為該身份的過程，以及授權（authorization）為根據已驗證的身份授權存取資源的過程。在 AWS 中，有多種方式可以驗證身份，而對於 AWS 上的分析，有兩種主要方式可以管理哪些身份可以存取哪些資源。

AWS Identity and Access Management (IAM) 服務

AWS IAM 是一種提供身份驗證和授權的服務，用於 AWS 控制檯、命令列介面（CLI）和應用程式程式設計介面（API）呼叫。AWS IAM 也支援身份聯合（federation of identities），這意味著您可以組態 IAM 使用其他身份提供者進行身份驗證，例如 Active Directory 或 Okta。

本章節的目的不是作為 AWS 上身份和存取管理的全面，但它提供了對於任何在 AWS 雲中工作的人員都重要的基礎概念的介紹。要更深入地瞭解 AWS IAM 服務，請參閱 AWS Identity and Access Management 使用者（https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html）。

重要的 IAM 身份

有多種 IAM 身份需要了解：

  • AWS 帳戶根使用者：當您建立 AWS 帳戶時，您提供一個電子郵件地址與該帳戶相關聯，該電子郵件地址成為該帳戶的根使用者。您可以使用根使用者登入到 AWS 管理控制檯，並且該使用者具有對帳戶中所有資源的完全存取許可權。但是，強烈建議您不要使用此身份登入和執行日常任務，而是為日常使用建立 IAM 使用者。
  • IAM 使用者：這是一個您建立的身份，可以用於登入到 AWS 控制檯、執行 CLI 命令或進行 API 呼叫。IAM 使用者具有用於控制檯存取的登入名和密碼，並且最多可以有兩個相關聯的存取金鑰，用於在使用 AWS CLI 或 API 時驗證此身份。雖然您可以直接將 IAM 策略與 IAM 使用者相關聯，但建議的方法是將使用者新增到具有相關 IAM 策略的組中。
  • IAM 使用者組：IAM 組用於提供可以與多個 IAM 使用者相關聯的許可權。您向 IAM 組提供許可權（透過 IAM 策略），然後該組的所有成員都繼承這些許可權。
  • IAM 角色：IAM 角色最初可能會令人困惑，因為它與 IAM 使用者相似。但是，IAM 角色沒有使用者名稱或密碼，您不能直接登入或識別為 IAM 角色。然而，IAM 使用者可以假設 IAM 角色的身份，並獲得分配給該角色的許可權。IAM 角色也用於身份聯合，其中使用者由外部系統驗證，然後該使用者身份與 IAM 角色相關聯。最後，IAM 角色也可以用於向 AWS 資源提供許可權（例如，向 AWS Lambda 功能提供許可權，以便 Lambda 功能可以存取特定的 AWS 資源）。

授權存取 AWS 資源

要授權存取 AWS 資源，您可以將 IAM 策略附加到 IAM 使用者、IAM 組或 IAM 角色。這些策略授予或拒絕對特定 AWS 資源的存取，並且還可以使用條件陳述式進一步控制存取。這些根據身份的策略是 JSON 檔案，指定對 AWS 資源的存取詳細資訊。這些策略可以在 AWS 管理控制檯中組態，也可以手動建立 JSON 檔案。

有三種型別的根據身份的策略可以使用：

  • AWS 管理策略：這些是由 AWS 建立和管理的策略，提供常見使用案例的許可權。例如，AdministratorAccess 管理策略提供對 AWS 中每個服務和資源的完全存取許可權，而 DatabaseAdministrator 策略提供設定、組態和維護 AWS 中資料函式庫的許可權。
  • 客戶管理策略：這些是您建立和管理的策略，以提供對您的 AWS 資源更精確的控制。例如，您可以建立一個策略並將其附加到特定的 IAM 使用者/組/角色，提供對特定 S3 儲存桶列表的存取，並將該存取限制為僅在特定時間或特定 IP 地址有效。
  • 內聯策略：這些是直接為特定使用者、組或角色編寫的策略。這些策略直接與使用者、組或角色繫結，因此僅適用於一個特定的實體。

以下是一個客戶管理策略的示例，該策略授予對特定 S3 儲存桶的讀取存取許可權：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": "arn:aws:s3:::de-landing-zone"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": ["arn:aws:s3:::de-landing-zone/*"]
        }
    ]
}

內容解密：

此 JSON 檔案定義了一個客戶管理策略，做了以下幾件事：

  1. 允許存取：該策略允許（您也可以建立拒絕存取的策略）特定的 S3 操作。
  2. 允許的操作：允許 s3:GetObject 和 s3:ListBucket 操作，這意味著授權執行 Amazon S3 GetBucket 和 ListBucket 操作（透過控制檯、CLI 或 API）。
  3. 資源規範：對於 ListBucket 操作，資源被設定為 de-landing-zone 儲存桶。對於 GetObject 操作，資源被設定為 de-landing-zone/*，這導致主體被授予列出 de-landing-zone 儲存桶和讀取儲存桶內所有物件的許可權。
  4. 邏輯說明：此策略確保只有被授權的主體才能列出和讀取指定的 S3 儲存桶及其內容，從而實作對敏感資料的安全存取控制。
  5. 設計考量：在設計此類別策略時，需要考慮最小許可權原則，即僅授予必要的許可權，避免過度授權，以減少安全風險。