Google Cloud的資料安全與合規性

這一篇我們針對GCP上的資料安全與合規性介紹幾個關鍵的議題。例如GCP的IAM服務，資料加密與加密金鑰的管理還有DLP(data loss prevention)。

我們在進行處理資料的作業時必然的一定會處理到資料安全的議題，不論在地端或雲端都是一樣的。而在雲端平台的資料安全問題最讓大多數想用公有雲服務的人卻步。這一篇文章我們會來談關於要達到在GCP上的資料保護與資料的合規性在GCP上是怎麼做的，談論的重點如下表列

• Identity and access management(IAM)
• Data security, 包含加密與金鑰的管理
• Data loss prevention (DLP)
• Compliance

Identity and access management with Cloud IAM

用過其他Public的人或對使用GCP的人一定知道IAM這一個類似帳號控管的服務。User and Roles是這個IAM服務最基本的概念。然而Cloud IAM還可以再加上一些額外的attribute在resource or identities裡面，像是Ip address 與日期/時間等這些因素會被考慮進到access control decision; 這個稱作 context-aware access.

Cloud IAM同時會有根據權限的異動會有audit log,包含authorizing, removing, and delegating permission.下面我們會介紹關於Cloud IAM的一些 key aspects

• Predefined roles
• Custom roles
• Using roles with service accounts
• Access controls with policies

以上這一些構成了有助於你可以保護你的GCP resource.

在GCP中， 這些身分角色users, groups, service account 還有G Suite domains都是可以被授權access resource。roles是一組權限的集合。當一個具有permission的role被分配給一個identity，這個identity就會有這個role裡具有的權限。在GCP你不可以將permission直接分配給identity, 所有的權限都必需經過role之後再分配給identity.

GCP有下三種類型的roles:

• Primitive roles
• Predefined roles
• Customer roles

Primitive roles

包含了Owner, Editor, and Viewer. 這些roles是被apply在 project level的並且是考量到coarse-grained access controls.

• Viewer role對resource 只有 read-only access
• Editor role包含了Viewer role的權限加上可以更改resource的狀態
• Owner role這是最高權限並且還有設定該project的billing的權限

一般來說我們應該不要使用Primitive roles, 除非公司的security policy可以接受這種coarse-grained access controls的管理方式。例如，開發部門有一個自己的GCP環境(可能是一個獨立的project). 開發人員就是這個環境的管理者，所以他們有責任要管理好這個環境。

Predefined Roles

這種roles通常都會伴隨著GCP service，像是 App engine or Bigquery，並且設定相關允許的操作，類似edit data in DB或是有deploy到App engine的權限。

roles命名的方式是以 “roles/”開頭的，後面跟個service名稱像是appengine;再來跟著role會apply的entity的類型，像是instance or table; 後面再跟著可以執行的動作，類如get, list , create等。

讓我們來看一個範例。 role/appengine.deployer 的這個role被賦予read-only 到所有application跟configuration setting並且可以write access to new versions. 這個role不行去更動現有所有的Application,除了可以刪除不再有流量的version。所以這個role(role/appengine.deployer)的permission會有如下清單

• appengine.applications.get
• appengine.instance.get
• appengine.instance.list
• appengine.operations.*
• appengine.services.get
• appengine.services.list
• appengine.versions.create
• appengine.versions.delete
• appengine.versions.get
• appengine.versions.list
• resourcemanager.projects.get
• resourcemanager.projects.list

我們可以從上面permission命名規則可以看到，權限的命名方式是service name後跟特定於該service的resource type以及對該類型resource的操作。 此範例中的星號表示適用於操作resource的所有類型的動作，例如 get、list 和 create。

我們再來看第二個例子， BigQuery有一個user roles叫做 roles/bigquery.user,這個role的權限可以對該project裡的BigQuery執行query跟其他的工作。Users可以list屬於他們的job and datasets也可以create 新的dataset.

• bigquery.config.get
• bigquery.datasets.create
• bigquery.datasets.get
• bigquery.datasets.getIamPolicy
• bigquery.jobs.create
• bigquery.jobs.list
• bigquery.models.list
• bigquery.readsessions.*
• bigquery.routines.list
• bigquery.savedqueries.get
• bigquery.savedqueries.list
• bigquery.tables.list
• bigquery.transfers.get
• resourcemanager.projects.get
• resourcemanager.projects.list

其他GCP的service都有類似的role與permission,通常這些權限都會包含有 admins, viewers, 跟某些類型的worker roles. 例如以下GCP的其他服務

我們可以看到Bigquery還可以再做更細緻化的permission，像是connections, metadata, sessions。

Customer Roles

前面提到的兩種role都是GCP已經做好的，而Customer role就是可以客製化的roles. 這個customer roles可以被assign給 user, groups, service account.

這一類的role最大好處就是可以讓你實行資安的重要概念: principle of least privilege. 要能客製化role你本身的role需要有 iam.roles.create的權限。

下圖的是用GCP console來create 一個IAM的role的範例. 需要填寫要有 typical name, description, 還有identifier parameters,你同時也可以定義role launch stage, 有這幾種alpha, beta, general availability 或是deprecated. 這個帳號設測時前通常會在alpha or beta stage,完成帳號測試後才會進到general availability. deprecated這個role不會再被使用。

當使用customer roles時，你也可以把predefined roles裡的permission list加入customer roles.這是方便你想要修改predefined roles稍微修改成你想要的，不用自己從頭尾的一個一個加入(下圖範例參考)。

使用Service Account的Roles

Service Account是一種經常與 VM instance和Application一起使用的identity，它們能夠進行由分配給service account的角色授權的 API 調用。 service account由唯一的email address標識。 email address name因service account類型而異。 例如：

Service account是給機器用的，不是給人用的。意思是Service account沒有password也不能用service account login進GCP console. 這些service都是用 public/private keys來驗證的。

考量以下這個狀況，我們有一個Application run在GCP的VM，這個Application需要把message寫入到 Cloud Pub/Sub topic(要有publish 到topic的權限). 我們可以assign這個role “roles/projects.topics”給to pde-exam-project-98765@developer.gserviceaccount.com 這個service account. 該VM/Application(entity)使用這一個service account呼叫 Cloud Pub/Sub API來將message寫到 topic(在同一個project內)。

User-managed keys又稱為 external key，這是由使用者自行管理public/private keys的。GCP只會儲存public key. private key由user自行管理。這個通常是使用在server-to-server authentication.

Access Control with Policies

前面提及的都是賦予identities權限來在resource在執行一些actions, 但你也可以使用rules的方式來access 這些resource. 這樣的方式稱為policies.

Policy有三個部分

• Binding
• Metadata
• Audit configuration

Binding指定如何授予resource access權限。 Binding由members、roles和conditions組成。 members是一種identity，可以是user、group、service account或domain。 role只是一個命名的權限集合。 conditions是用於描述基於context-based restrictions的邏輯表達式。

Policy的metadata包含一個稱為etag的屬性，用於當要update policy的concurrecny control. 這是必需的，因為多個Application可以同時寫入一個policy。 檢索policy時，同時也檢索了 etag，編寫policy時，將檢索到的 etag 與policy的當前 etag 進行比較。 如果兩個 etag 不同，則在檢索policy後，另一個Application會寫入該policy。 在這些情況下，我們應該retry整個update operation。 metadata還包括一個版本，用於指示policy中使用的schema的迭代。

以下為一個將jason-kao@example.com binding到 roles/resourcemanager.projectCreate這一個role的範例

Audit configuration則是描述哪一個permission type需要被記錄下來與哪個idenities不需要被記錄。例如以下為jason-kao@example.com這一個帳號會有read operation的稽核紀錄。

Policy可以被assign到不同的level的resource層級上，包含了organization, folders, projects, 及單一的resource. 一次只能將一個Policy assign到包含了organization, folders, projects, 及單一的resource。

Policy通過resource hierarchy結構繼承。folder繼承organization的policy。如果一個folder是在另一個folder中create的，它會繼承上一層folder的policy。project繼承organization和任何更higher-level folder的policy。resource繼承層次結構中位於它們之上的organization、folder和project的policy。直接assign給resource的policy與resource層次結構中從上層結構繼承的policy的組合稱為effective policy。

重要的是 IAM 只能往上加。 例如，你無法撤銷在folder levele給予的project level權限。

Cloud IAM 是一項廣泛服務，它通過使用roles和policy提供fine-grained的訪access control。 Cloud IAM 中提供了predefined的role，旨在對常見use case（例如DB admin）所需的權限進行群組。 當predefiend的role不能滿足你的特定需求時，可以create自定義規則，尤其是在principle of least privilege。 role還可以與service account一起使用，以向 VM 和Application提供授權。 此外，access control policy可用於控制對resource的訪問。

將IAM用於Storage and Processing Services

前面提及的都是IAM的通用法則。這一段我們將會介紹一些IAM的predifiend roles用於以下服務的特定範例

• Cloud storage
• Cloud Bigtable
• BigQuery
• Cloud Dataflow

Cloud storage with IAM

有好幾種方式可以control access到Cloud storage resources, 包含buckets及在buckets的objects.

• Cloud IAM是一個最好的方式來control access到buckets and objects.
• 如果要使用到複雜邏輯的access control或當你需要control到單一個objects, 也許使用access control list(ACL)比較好
• Signed URLs是另外一種access control的方式。這些URL網址是你想要分享給其他有權限的人，而且這些網址是有存活時間的。
• 假如你想控制upload to a bucket, 你可以使用signed policy document

在這一段我們會聚焦在IAM在Cloud storage的使用。

Cloud Storage 權限被組織圍繞著resources，例如buckets、objects和Hash-based Message Authentication Code(HMAC) 密鑰。 buckets權限允許用戶create、delete和list buckets。 還有獲取和更新metadata以及設置和獲取 IAM policy的權限。

object permissions還具有create, delete, and list permission以及metadata and IAM policy的權限。

HMAC key是被使用在access Cloud storage 的驗證(authentication)上。HMAC key的權限包含了 像是create, delete, list還有 get 與update metadata。

以下有五種Cloud Storage會用到的標準roles

• roles/storage.objectCreateor: 可以create object
• roles/storage.objectViewer: 可以view object與它的metadata, 但不行看到ACL.可以list這個bucket裡的內容。
• roles/storage.objectAdmin: object最高管理者，對object想幹嘛都可以。
• roles/storage.hmacKeyAdmin: 在project level內，使用HMAC key可以對cloud storage進行任何動作。
• roles/storage.admin: 對buckets/objects有完全控制權，但當你把這個roles apply到單一個bukcet, 完全控制權只會在這個buckets中而已。

Cloud Bigtable and IAM

Cloud bigtable的access control層級可以在 project,instance, tables這三個層級來控制。

在Project level我們可以控制如下事項

• 可以讓user讀取在project中的任何instance的任何table的資料，但無法寫入。
• 可以讓user讀取與寫入在project中的任何instance的任何table的資料。
• 可以讓user管理在project內的任何instance.

在Instance level我們可以控制如下事項

• 限制user只能讀取development instance的資料但無法讀取production的。
• 讓user只能讀取與寫入development instance的資料但production的instance只能讀取。
• 讓user管理development instance但不行管理production的。

在table level我們可以控制如下事項

• 讓user讀取table的資料，但不能寫入。
• 讓user寫入資料到table，但不能讀取。

Cloud Bigtable具有access resource(像是 instance, application profiles, clusters與tables)的權限。

Cloud bigtable的predfined roles包含了Admin, User, Reader與Viwer. 使用 roles/bigtable.admin在project 中的bigtable服務有最高的控制管理權。roles/bigtable.user則可以read/write資料到table。roles/bigtable.readers只有read-only table裡的資料，如果使用roles/bigtable.viewer只能進到GCP的bigtable服務而已。

BigQuery with IAM

Bigquery就有很多的權限設定。這因為BQ有很多的resource(像是tables/datasets/jobs/connections/save queries等等)所以權限上的設定非常多。大部分的權限都是create/delete/update/list component。 有一些components像是tables還有其他的操作權限，例如export data.

BigQuery roles為以下清單

• roles/Bigquery.admin :在project內可以管控整個Bigquery 服務。
• roles/Bigquery.dataEditor: 當這個role apply到datasets時，可以datasets內的tables做list/create/update/delete 與read metadata; 如果是apply到project or organization level則除了上述權限外還可以create datasets.
• roles/Bigquery.dataOwner: 當這個role apply到datasets時可以對該datasets執行read/update/delete, 也可能create/update/get/delete 這個datasets裡的tablel;如果是apply到project or organization level則除了上述權限外還可以create datasets.
• roles/Bigquery.dataViewer: 當這個role apply到datasets時，可以read datasets的metadata. list這個dtasets裡的tables,與retable table的metadata;如果是apply到project or organization level, 則可以list這個project裡的所有datasets.
• roles/Bigquery.jobUser: 可以執行Job的作業，包含query;list jobs;取消user的jobs.
• roles/Bigquery.metadataViewer : Apply 到project or organization level，這個role可以list all datasets與read all datasets的metadata也可以list這個project內 all table/views跟 read這個project內 all table/views的metadata
• roles/Bigquery.user: 可以執行Jobs, 羅列與取消 user的jobs，還有也能羅列在project內的datasets.

Cloud Dataflow with IAM

IAM對Cloud dataflow的access control有jobs, messages 還有metrics.

Cloud dataflow的權限包含對jobs的create/list/update/cancel. 還有list messages / get metrics.因為cloud dataflow是 stream and batch processing system, 所以有一些與其他GCP storage service有不一樣的地方。Cloud Dataflow的 predfined roles有以下清單:

• roles/dataflow.admin: 可以create 跟manage jobs.
• roles/dataflow.developer: 可以執行與修改jobs
• roles/dataflow.viewer: 對cloud dataflow的resource只有read-only的權限
• roles/dataflow.worker: Compute Engine 服務帳號授予執行pipeline work units的權限

資料安全(Data Security)

除了使用IAM權限控管之外，GCP還提供了兩項基本功能來強化資料的安全性，分別是encryption(加密)與key management.

Encryption(加密)

加密是以一種方式對資料進行編碼的過程，它產生資料的編碼版本，如果沒有附加資訊，該版本實際上無法轉換回原始形式。 該附加資訊是用於加密資料的密鑰。 我們通常區分 encryption at rest and encryption in transit。

Encryption at rest

預設情況下，Google 會加密data at rest。我們不用配置任何policy即可啟用此功能。這用於所有 Google storage services，例如 Cloud Storage、Cloud SQL 和 Cloud Bigtable。encryption at rest會發生在多個level：

• Platform level, DB與file會用 AES256 和 AES128 進行加密。
• Infrastructure level, data在storage system會被分組為data chunks , 每個chunk都用AES256加密。
• Hardware level, storage devices用AES 256 or AES 128進行加密。

在platform，分佈式filesystem和DB對data進行加密。 加密的精細度因服務而異。 例如，Cloud SQL 使用相同的密鑰加密DB instance中的所有data，而 Cloud Spanner、Bigtable 和 Cloud Firestore 使用infrastructure level加密機制加密資料。

當 GCP 將data存儲在storage system中時，它會將data存儲在大小可達數 GB 的subfile chunks中。 每個subfile chunks都使用自己的密鑰加密，稱為data encryption key (DEK)。 如果chunks被更新，則使用新密鑰。 密鑰不用於多個chunk,它是一對一的。 此外，每個chunk都有一個unique identifier，由ACL 引用以限制對chunks的access，這些chunks存儲在不同的位置，使惡意行為者更難以將它們拼湊在一起。

除了加密chunks的data外，GCP 還使用第二個密鑰對data加密密鑰進行加密。 這稱為 envelope encryption。 用於加密 DEK 的密鑰稱為key encryption key (KEK)。

除了發生在infrastructure level的chunk-level加密之外，當data blocks寫入persistent storage時，storage device使用 AES128 或 AES256 加密這些blocks。 較舊的device使用 AES128，但新的storage device使用 AES256。

總結一下encryption at rest:

• data at rest加密在GCP是預設功能
• data的加密有多個level, 包括Application, infrastructure,device level
• data是加密到chunk的。每個chunk都有它相對應的encryption key稱作data encryption key(DEK)
• 加密DEK的key稱為key encryption key(KEK)

這些加密處理過程會由GCP一手包辦。不過有些公司的資安政策也許會把密鑰拉回來自行管理。之後的key management章節會提到這一段。我們先來看encryption in transit

Encryption in transit

encryption in transit又稱encryption in motion，這是為了保護資料在傳輸過程中不會因為資料被攔截而損及資料的confidentiality 與integrity. GCP會組合驗證資料來源與加密來保護在傳輸中的資料。

GCP會區分資料的傳輸是在google自己的網路或是Public internet. 資料如果是在google自己內部的網路是會被驗證，但也許就沒有加密。而資料離開google網路的實體邊界外就會被加密。

正常來說你的Application(如果是web service)跑在GCP上,通常接受來自Internet的traffic我們都會使用GCP的Google Fron End(GFE)的服務，這是一種google的globaly distributed proxy service. GFE接收https or http的trafic後會再將traffic 路由(透過google自己的網路)給你的Application。GEF同時也提供了一些其他安全性服務，例如防DDoS服務。也有global load balancer的功能。以上說的是理想狀況，也有可能你的Application不是跑http/https的。哪就要直連你的VM或其他服務的end-point.

所有的traffic到GCP預設都是加密的(理想狀況)。加密的方式可以使用Transport Layer Service (TLS) or Google開發的QUIC協定(一種基於UDP協定)。

GCP也使用Application Layer Transport Security(ALTS)的服務來做資料的驗證與加密。這一個加密程級是在OSI network model 的L7.

Key Management

既然有資料加密，不管是 Data at rest or in transit. key的管理非常的重要。因為key沒保存好你的加密方式再強大也沒有用。

預設的key management
預設上GCP會幫你管理所有key(DEK and KEK)的工作。雖然之前有提到每一個data chunk的加密都會對應一個獨立的key，但這一些獨立的key我們還是會用同一個key來對這些key做加密(KEK)。 KEK會被存放在集中式的key management service.

DEK的產生是靠著storage service使用通用的crytogaphic library. 用DEK加密data chunk之後，DEK會被送到集中式的key management service, 然後會再用KEK加密這些DEK。當storage system需要讀取資料時，它會傳送DEK(被KEK加密過的)到key management service，key management service會驗證這一個key然後會解密這一個DEK再送回storage system.

Customer-Managed Encryption Keys(CMEKs)
GCP KMS是一個託管式的key management的service。它允許使用者自行產生與儲存密鑰在GCP裡。這個好處是你想自行產生密鑰但又不想管密鑰系統的infra，哪麼這個服務就是適合你。CMEK常被用來指為 KMS-based keys.

Cloud KMS支援多種加密方法，包括 AES256, RSA 2048, TSA 3072, RSA 4096, EC P256, EC P384。它同時也會自動更換這些DEK並再次使用KEK加密這些新的keys. Cloud KMS的keys可以被銷毀，但你有24小時的時間可以後悔，以免key真的被刪除(可能有人手殘或是即將離職的不爽員工)後你還有些資料是用舊的key加密。哪這些資料連GCP都沒有辦法幫你救回來。

Cloud KMS的key也可以被使用在Application-levle的加密，像是compute engine, Bigquery, Cloud storage, Cloud dataproc.

Customer-Supplied Encryption Keys(CSEKs)

CSEKs是第三種key management的選擇。customer-supplied keys 是連key management的整個infrastructure都會是由使用者自行管理。CSEKs常被用來指為 cunstomer-supplied keys.

在這個模式中，整個ky management system都在你的地端機房，你只是將DEK送上GCP去加密你的資料。這些key的傳送是透過呼叫APIs的方式來傳送上去。keys被傳送到GCP時，keys在使用時是被存放在memory裡。這些key並不會把key存放在storage裡。意思是GCP不會保存這些key.

Data Loss Prevention(DLP) API for Data privacy

DLP API是一種偵測敏感資料(text and image)的服務，能夠對敏感資料進行編輯或遮罩並進行風險分析。這種服務的job能夠對執行text or images做pattern detection。 Pattern 被定義為information type 或InfoType detectors.

偵測敏感資料

GCP提供數百種的InfoType detectors來辨認已知的敏感資料型態，包含以下:

• Credit Card numbers
• Dates of birth
• Email addresses
• Passport number
• Authentication tokens
• Passowords

也有特定國家所規定的敏感資料類型，如

• US Social Security numbers
• Indian GST identification numbers(GSTIN)
• Japanes bank account numbers
• Spanish national identity numbers
• Paraguacy civil identity card numbers

當然我們也可以create inspection job來製作我們自己的InfoType detectors。API則適用於test or base64-encoded images.

當 一個InfoType detectors 在text中有match一個我們有定義到的字串符號，API 返回匹配的 InfoType detector、 a likelihood score以及由byte range或record location指定的位置（如果text是結構化的）。當 InfoType detector匹配images中的某些內容時，API 會返回匹配的 InfoType、a likelihood score和pixel位置中指定的位置。

除了偵測patterns之外，DLP API也可以編輯敏感資料。例如你已經掃描到以下的email addresses文字:

“And my email addresses is jason.kao@suros.com.tw”

API就會返回一個混淆的資訊，像是如下資訊

“And my email addresses is [EMAIL_ADDRESSES]”

同樣的當敏感資訊在image中被找到時，被找到的部分就會蓋起來。如下圖所示

source image 來源為Google 文件庫

執行 DLP Jobs

DLP的job有兩種: inspection jobs and risk analysis jobs. inspection job主要是使用InfoType 掃描敏感資料的內容。完成之後會產生報表。該報表會顯示敏感資料的type與位置。Risk analysis jobs則是計算資料會被re-identity的可能性。

Jobs是使用 job triggers來排程的。來掃描GCP的storage service包括Cloud storage and BigQuery.

掃描工作完成後我們可以自動化的執行一些動作。有兩種類型的動作我們可以執行。掃描工作的結果可以被存放到BigQuery中你指定的table. 另一個則是掃描工作的結果 推送到 Cloud Pub/Sub topic中。

Inspection Best Practices

GCP定義了幾種使用DLP API的最佳實踐作法。

首先，你應該盤點並確定掃描內容的優先順序。特別是當你有大量積壓的資料需要掃描時。風險最高的敏感資料應該最優先掃描。

確認Cloud DLP service account有其相對應的role權限可以掃描GCP裡的storage services.

首先對data進行採樣並使用簡單的匹配標準。 這可以幫助我們確定應該使用哪些 InfoType detector。 我們可能會發現掃描產生的誤報(false positives)可能多到我們無法接受。 在這種情況下，我們可以create排除規則以減少誤報。

使用job triggersrrru進行掃描。 可以設定掃描工作只scan自上次scan後有異動的部分。

法令法規

Google Clod符合多種的法規法令來驗證 data的security, privacy, and compliance controls. 符合的法規法令如下

醫療產業的有美國的HIPAA(Health Insurance Portability and Accountability)與歐洲的HITECH(Health Information Technology for Economic and Clinical Health). GCP services 支援HIPAA的清單可以參考這個網址。

美國的COPPA(Childern’s Online Privacy Protection), FedRAMP(Federal risk and Authorization Management Program).還有歐盟的GDPR