多雲環境的安全維運 — Part 3

定義資料的資安政策

14 min readDec 26, 2022

雲端平台越來越適合企業儲存大量的資料。不管是資料封存，大數據運用，機器學習等。無疑的，根據不同雲端平台的特性，我們也將大量的資料分散在多雲環境中。而每一個雲端平台都有自己資料加密解決方案，但技術可能略有差異，從資料的加密方式到金鑰的儲存與管理。其最終目的都是要保護資料的安全，防止未經授權的人取得加密金鑰進而存取未經授權的資料存取。

在我們討論資料加密之前，我們需要先討論甚麼是資料模型(Data models)以及資料分類。我們會討論到不同雲端平台的資料儲存方案。接下來，我們將了解如何通過定義 DLP(Data loss prevention) 政策來保護資料，資訊標籤來控制存取和使用加密來保護資料。

本文中，我們將討論以下主題：

多雲架構下的資料儲存概念
資料儲存技術
資料加密
保護存取、加密和存儲金鑰
針對大數據的原始資料保護

多雲架構下的資料儲存概念

假如我們是CIO/CISO，我們捫心自問，組織內甚麼是最重要的資料我們需要保護。答案可能會是資料，不論是代碼或營業資料，都是要保護的。因為服務可以重建，唯獨資料無法重建回來，特別是歷史越悠久的難度越高。所以資料架構可能是整個企業組織與IT架構中最重要的部分，它也可能是組織架構中最困難的一部分。在這裡，我們將會簡單介紹資料架構的一般通用原則以及這將驅使在雲端的資料安全。

在企業架構(這一部分請參閱本部落格TOGAF系列文章)中，資料架構包含三個層次(或者說是資料架構流程)：

概念層次：這是指兩個商業實體之間的關係。例如產品與客戶就是兩個商業實體。而產品與客戶的關係是靠銷售這個行為來建立的。所以概念資料模型描述了兩個商業實體之間的業務流程相依性，而商業實體就是靠這個流程建立關係。
邏輯層次：這裡又比概念模式提供更多細節。因為邏輯上，一個產品不會是對一個客戶。它們可能是一對多或多對多的關係。概念模式提供了結構，而邏輯模式則是加上了一對多或多對多這種關係的資訊。像是客戶Ａ有甲乙丙三種產品之類的資訊。
實際層次：這是當我們有了資料結構與其關係之後實際的資料要存放在哪裡。實體層次包含特定資料庫的藍圖，資料庫位置、資料存儲或資料庫技術的架構。

下圖顯示了從資料的概念層次到真實資料儲存之間的關係。在業務層面產生的資料需求，引導出技術需求。

資料模型指的是將資料結構化。就此而言，它沒有說明任何有關資料類型或資料安全的資訊。至於甚麼是資料結構化與資料類型，相信有學習過資料庫概念人應該都知道，在此就不在贅述。

但對資料安全而言，經過結構化的資料與資料類型可以讓我們進行資料分類(Data classification)。一般企業可能會將資料分類成公開(public)/機密(confidential)/高度機密(sensitive)/個人資料。而根據這些類型，組織可能需要針對不同的內外部監管規則對其進行保護，例如組織如果在歐盟有業務，就要遵守GDPR，而該項監管規則對其個人資料又特別重視，所以可能需要高度的資安保護方式。

我們(大部分是架構師角色)必須考慮不同層次的安全性以保護資料，包括資料本身、存儲資料的資料庫以及運作資料庫的基礎設施。 如果資料模型架構良好，則可以很好地理解每個資料來源之間的相依性和關係。

資料儲存技術

決定了資料模型與資料型態，接下來就是要尋找符合我們技術要求的資料儲存技術。所有的雲端平台都提供了下列幾種類型的資料儲存技術：

Object storage: 這通常會儲存一些非結構化資料(影像/圖片)或是歸檔資料。AWS稱作S3，Azure稱Blob，而GCP稱為Cloud Storage。而這一類的儲存技術有分等級，如果為歸檔資料，則AWS稱 S3 Glacier 與Glacier Deep Archive，Azure稱為storage archive access tier，GCP有nearline/coldline。
Virtual Disk: 這個就是掛載給虛擬機的硬碟，也稱為block storage。這個還細分是暫時性的Virtual Disk或永久性的。AWS稱為EBS，Azure稱為managed disks，而GCP稱為persistent disks。
Shared files: 這就是我們熟知的檔案伺服器，只不過雲端平台提供的是PaaS服務。在AWS稱為EFS，Azure稱為Files，而GCP稱為Filestore。

下圖呈現了資料擁有者，資料使用者與不同儲存技術之間的關係：

雲端中的資料保護

數位轉型這一個口號開始在越來越多的企業進行，意味著要數位化就勢必要將越來越多資料存入電腦。哪也就意味著資料成長的速度也越來越快，但是絕大多數的企業也可能沒有能力去儲存與管理大量的資料。所以雲端運算的大量儲存能力就進入了企業的選項之一。

而將資料放在企業以外的環境也意味著企業需要保護不在自己管控環境之下的資料。而雲端業者也為此喊出共同責任(shared responsibility)，雲端業者提供了一些工具或解決方案來提供企業保護自己的資料。這跟企業使用傳統磁帶放到第三方廠商進行託管其實很類似，企業需要定義放到外面的資料需要怎樣的保護，甚麼樣的資料又可以放到託管的環境中。這還是跟企業要遵守的內外部監管規則有很大的關係。

資料保護應該是全面性的。也就是要保護的資料不只是在系統中或使用中的，歸檔性的資料也是需要依據資料的資安政策來進行保護。在架構中，我們必須有資料分類的對照表，並且必須有針對 DLP 的適當策略。資料分類搭配企業的內外部監管規則與資安政策套用到DLP中。甚麼資料可以出去甚麼資料能在企業內部環境都必須依據資料分類來定義，而這也是企業必須要先確定的事情。

而企業的資料保護政策要怎麼訂立呢?首先，企業需要進行DPIA(data protection impact assessment)，這出自GDPR所提出的要求。在 DPIA 中，企業評估其擁有的資料、這些資料的用途以及洩露時的風險。 DPIA 的結果將決定資料的處理方式、誰或什麼能夠存取它，以及必須如何保護它。這可以轉化為 DLP 政策。下表顯示了一個非常簡單的 DLP 矩陣的範例。它表明業務資料可以由業務應用程式存取，但不能從電子郵件存取。與社交媒體（在本例中為 FB）的連線在任何情況下都被阻止。

資料分類標籤和 DLP 與我們的資安政策有關：它們定義必須保護的內容以及保護的程度。下一個則是保護資料的技術面 — — 如何保護。

資料加密

相信看過電影:模仿遊戲(The Imitation Game)中，主角亞倫.圖靈為了破解德軍的訊息加密機的情節有深刻的印象。加密的基本原理就是，將訊息轉譯成人類無法看懂的訊息。而為了要看懂這個加密訊息，我們就需要對其解密。而加密的方式基本上可以分為兩種 — 非同步(也稱為public key)與同步。

不論是同步或非同步加密，都會有兩種元素出現，哪就是

加密演算法
加密金鑰

同步加密的資料加解密用的是同一把金鑰，而非同步則是加密與解密用的是不同金鑰。同步加密的問題在於: 金鑰在資料兩方之間的傳遞。因為不過用哪種方式傳遞金鑰都被竊取的可能。而企業的資料如此龐大與複雜，不可能都用同一把金鑰來加解密不同等級的資料，哪麼管理金鑰也變成是一個問題。

而非同步加密則解決了加密金鑰傳輸的問題，因為資料的加密用的是私鑰(private key)而解密則是用公鑰(public key)。企業只需要針對私鑰的保護即可。而不管是同步與非同步加密，其加密演算法用的都是一樣的。現今用得最多的演算法應該是AES(Advanced Encryption Standard)。

AES資料區塊的方式。這些區塊的加密是輪流進行的。在每一輪中，金鑰中都包含一個唯一的代碼。金鑰的長度決定了加密的強度。該長度可以是 128、192 或 256 bit。最近的研究證明 AES-256 甚至是可以抵抗量子運算破解的。下圖顯示了 AES 加密的原理：

RSA則是另一種很多人使用的非同步式加密。使用 RSA，資料被視為一個很大的數字，並使用特定的數學序列(稱為integer factorization)進行加密。在 RSA 中，加密金鑰是公開的，解密是使用高度安全的私鑰完成的。 RSA加密的原理如下圖所示：

不論是AES或RSA，金鑰的長度是最重要的。因為大多數的駭客還是用最簡單的暴力破解法來解密資料，也就是如果我們的金鑰長度越長(位元夠多)。駭客要使破暴力破解我們的資料代價就越高甚至解密資料的時間長於駭客的一生。

保護存取、加密和存儲金鑰

不管要使用雲端業者的哪一種工具或解決方案來保護資料。使用者(也就是企業)必需理解與同意雲端運算的共同責任模型，也就是保護資料不會全不都是雲端業者的責任。因為企業一旦有資料洩漏的情況，企業的客戶絕對不會怪雲端業者，而是資料的持有者或擁有者，也就是企業本身。

不管是台灣的個資法，或是國際上使用的GDPR著重的個人資料保護。ISO/IEC 27001與27002是一種資安框架，其中資料保護是其中的一部分。這些標準都需要定義出資料擁有者，而茲了擁有者有最終保護資料的責任。

為了在雲端資料上保護資料，企業有兩個方面需要注意:

資料加密
使用驗證(Authentication)與授權(authorization)的方式存取資料

這些只是安全問題。企業還需要能夠保證資料的可靠性。企業需要確保，例如，金鑰與資料的保存地是分開的，即使由於技術原因無法存取金鑰庫(key vault)，仍然有一種方法可以安全地存取資料。工程師不能簡單地帶著 USB 設備到資料中心來拿走資料。 Azure、AWS 和 GCP 如何處理這個問題？我們將在下一節中對此進行探討。

在Azure中的加密與金鑰

我們通常一開始會將資料放置在Azure的Blob Storage中。這個storage是被storage key所保護的。而這個金鑰則會放在金鑰庫中，跟storage屬不同網段。金鑰庫的功能還會定期更換金鑰，加強其安全性。這個定期更換的技術稱為SAS(shared access signature) token來存取該storage。其概念如下圖所示:

Azure強烈建議我們使用金鑰庫來管理加密金鑰。Azure提供了多種的加密服務針對不同的儲存服務。例如針對硬碟的加密: BitLocker或DM-Crypt(針對Linux)。在將資料寫入Blob storage之前也可以使用完全託管的資料資料加密 — SSE(Storage Service Encryption)，SSE使用AES-256加密演算法。而針對Azure SQL Database(PaaS服務)，Azure提供了TDE(Transparent Data Encryption，一樣基於AES-256)與3DES加密方式。

在AWS中的加密與金鑰

AWS與Azure一樣使用了金鑰庫的解決方案，AWS稱為KMS(Key Management Service)。再將資料寫入S3之前，可以使用與Azure一樣的全託管金鑰加密方案 — SSE(Server side encryption)-S3，AWS也提供了client encryption的選項(SSE-C)。

在S3的的加密選項我們除了有SSE-S3，AWS還提供SSE-KMS。針對每個資料的加密都會有一把DEK(data encryption keys)，而所有的DEK在KMS中都會有一把主金鑰(key encryption key)再一次加密。而這把主金鑰會定期重複的替換，AWS採用AES-256來進行加密。不過這一把主金鑰也可能自行產生，AWS稱為CMS(customer master key)，託管在KMS中。不論是哪種，只要使用KMS，我們就可以稽核金鑰的使用紀錄。

在GCP中的加密與金鑰

GCP與Azure/AWS提供object storage，稱為Cloud Storage。託管的金鑰庫服務稱為Cloud Key Management Service。GCP在Cloud storage的加密方式與原理跟AWS/Azure差不多，server-side/client-side加密，AES-256演算法。託管的金鑰庫也使用DEK/KEK的概念。

目前為止，我們從資料、資料儲存、資料加密到安全的存取資料都有一個概念性的介紹。要如何從這些概念性的東西轉換成符合企業的組織架構是一個重要的工作(通常是資安長、企業架構師與方案架構師的合作)。而最小的原則要求如下:

對傳輸的資料加密(end-to-end data encryption transit)
對儲存的業務資料或敏感資料進行加密(data encryption at rest)
使用 DLP 並套用一個對照表，清楚地顯示什麼是關鍵和敏感資料以及需要保護到什麼程度

最後，發展使用案例並測試資料保護場景。建立資料分類模型、定義 DLP 對照表並套到資料保護控制後，企業必須進行一連串的驗證測試，不論是對使用者或是系統。而數據整合測試也是必須的。然而這只是測試我們已知的已知，還有已知的未知與未知的未知我們也需要盡可能的探索。關於未知的未知探索，可以參考本部落格資安混沌工程一文。

資料的政策和加密很重要，但不應忽視一件事：加密並不是全部，錯誤的IAM配置也會導致資安事件發生。認為資料因為其加密和安全存儲而受到充分保護會給人一種錯誤的安全感。 安全真正始於身份驗證和授權。

針對大數據的原始資料保護

如我們前面提到，雲端運算(特別是公有雲)可以建立龐大的資料胡，儲存大料的原始資料。這是絕大多數企業所做不到或不願做的(因為可能不具成本效益)。而這麼大量的原始資料就為企業建立了大數據或是資料建模的能力。而所謂大數據有以下四個V特徵:

Volume: 資料的量
Variety: 不同型態的資料，文字/圖片/影像、結構化、非結構化、辦結構化
Veracity : 資料的質
Velocity: 資料變動的速度

資料分析師通常基於這四個V會加上第五個V — Value(價值)，如下圖。大數據其實就是把一大堆的原始資料(對我們沒有意義)變成對我們是有意義(經過一堆的轉換過程)。更多的大數據介紹可參閱本部落格AWS的大數據分析-part 1資料收集與Google Cloud的儲存服務介紹系列文章介紹。

而針對每個雲端業者也提供了自己的大數據加密方案，而且幾乎很多都是預設有加密的選項。不管是Azure的Data Factory、AWS的Redshift、GCP的Big Query。更多的AWS/Azure/GCP的大數據加密介紹，請參閱本部落格的其他文章介紹。

總結

本文是關於保護雲端環境中的資料。當我們將資料從地端機房的系統移動到雲端時，公司必須設置特定的控制措施來保護資料。資料持有者仍有責任保護資料；雲端業者只負責他該負責的。

企業需要首先考慮資料保護政策。需要保護哪些資料？哪些內外部監管規定與國際資安框架可以拿來做合規用？最佳做法是開始考慮資料分類模型，然後製作對照表，展示關鍵和敏感資料的政策。我們還使用資料分類和標籤探討了 DLP 的原理。

我們還探討了公司在雲端環境中資料儲存的不同選項，以及我們如何從技術角度保護資料。一連串到探討之後，我們應該對加密的工作原理以及 AWS、Azure 和 GCP 如何處理和加密資料有一個很好的概念。