Open in app

Sign in

Write

Sign in

Google Cloud — 安全服務簡介

在談及GCP的一些安全服務之前，我們會提到一些資訊安全的概念。但多的資訊安全知識參閱本部落格的其他資訊安全文章。

IAM(Identity and Access Management)身分識別與存取管理

基本上就是甚麼(人/機器)根據甚麼權限(write/read)存取甚麼資源(VM/GCS等)。所以我們會有一種identity(身分)要去存取某個資源。在GCP裡，這稱為Cloud IAM。Cloud IAM基本上有三個基本元素:

  1. Identities(這可能是GCP account/group, 運行在GCP內外部的程式等)
  2. Authentication — 這是經過授權的identities嗎?
  3. Authorization — 經過驗證後，這個identities可以執行那些動作

而在執行的動作上，Cloud IAM可以針對不同的role配置非常細緻化的權限。以下我們用一個範例來說明整個IAM的設定流程。

假設我們有一個GCS buckts要當作部門的share folder。我們需要認識以下三種基本概念:

  • Member(也可以稱principal或identity):同部門的人
  • Resource: 要存取的bucket
  • Action: 部門同事可以做些甚麼動作(Upload/Delete Objects)

在Cloud IAM中，Role：是一組權限（對特定資源執行特定操作）。Role不用知道member，因為role代表的就是權限的。所以我們就是把部門成員加到role中，再對role設定權限。所以有兩個步驟:

  1. 選擇具有正確權限的role（例如：Storage Object Admin）
  2. 建立具有role（權限）的policy並綁定member（部門同事）

GCP的IAM role與AWS IAM的 role有著以下不同的分別:

角色命名方式（Role Naming Convention）:

  • AWS IAM: AWS role通常以完整的 Amazon 資源名稱 (ARN) 進行命名，例如 arn:aws:iam::account-ID-without-hyphens:role/RoleName。
  • Cloud IAM: Google Cloud 的角色通常以完整的資源名稱 (Resource ID) 進行命名，例如 projects/{project-id}/roles/RoleName。

JSON 設定的差異:

  • AWS IAM: 在 AWS 中，IAM role的設定通常以 JSON 格式表示，包括一系列的policy陳述，這些陳述定義了role的權限。
  • Cloud IAM: 在 Google Cloud 中，IAM role的設定同樣以 JSON 格式表示，但它們使用稱為 bindings 的層次結構，其中包含role和member之間的對映。

Pre-defined role的名稱和用途:

  • AWS IAM: AWS 提供一組預定義的角色，如 AmazonS3FullAccess 或 AWSLambdaRole，用於特定服務或任務。
  • Cloud IAM: Google Cloud 也提供一系列預定義的角色，如 roles/storage.admin 或 roles/cloudfunctions.developer，用於不同的權限需求。

跨帳戶存取的不同處:

  • AWS IAM: AWS 允許帳戶之間的角色信任 (cross-account role trust)，使一個 AWS 帳戶中的實體可以假裝是另一個 AWS 帳戶中的角色。
  • Cloud IAM: Google Cloud 通常使用service account來實現跨專案或跨組織的角色委派，而不是直接的角色信任。

IAM 資源的分類差異:

  • AWS IAM: AWS 的 IAM 資源主要集中在 users、groups、roles、和 policies。
  • Cloud IAM: Google Cloud 的 IAM 資源包括 service accounts、roles、和 permissions。

Role的類型

IAM的role有以下三種:

Basic Roles (或稱 Primitive roles) — 有Owner/Editor/Viewer這三種role。這個在我們啟用一個GCP project之後就會存在了。(建議不要在Production環境中使用)

  • Viewer(roles.viewer) — Read-only
  • Editor(roles.editor) — Viewer + Edit
  • Owner(roles.owner) — Editor + Manage Roles and Permissions + Billing

Predefined Roles — 由 GCP 預先定義和管理的權限細緻化的role。依據不同的目的有不同的role。如Storage Admin, Storage Object Admin, Storage Object Viewer, Storage Object Creator

Custom Roles — 當我們覺得Predefined Roles的權限細緻度還不夠用時，我們可以客製自己的role。

例如我們以Cloud storage的Predefined roles舉例

  • Storage Admin (roles/storage.admin)
    storage.buckets.*
    storage.objects.*
  • Storage Object Admin (roles/storage.objectAdmin)
    storage.objects.*
    Storage Object Creator (roles/storage.objectCreator) storage.objects.create
  • Storage Object Viewer (roles/storage.objectViewer)
    storage.objects.get storage.objects.list

因為bucket存在於project中，所以以上四種role一定會有以下project level的權限

  • resourcemanager.projects.get
  • resourcemanager.projects.list

整個權限的邏輯架構如下圖:

會有member/roles(permission)/policy(Assign Permissions to Members)。一個role可以有多個權限，而一個member也可以同時屬於多個role。

透過 IAM Policy document將roles指派給user。
policy object會呈現:

  • Policy object會有一個binding清單
  • binding指的是將role綁定到member list
  • member type由prefix標識：
    範例：user, serviceaccount, group 或domain

以下為一個Policy document的範例

{
    "bindings": [
      {
        "role": "roles/storage.objectAdmin",
         "members": [
             "user:jason@jasonkao.com",
             "serviceAccount:myAppName@appspot.gserviceaccount.com",
             "group:administrators@jasonkao.com",
             "domain:google.com"
        ]
},
{
    "role": "roles/storage.objectViewer",
    "members": [
        "user:jason@jasonkao.com"
],
    "condition": {
        "title": "Limited time access",
        "description": "Only upto Feb 2024",
        "expression": "request.time < timestamp('2024-02-01T00:00:00.000Z')",
        }
      }
    ]
}

Service Account

這一種account通常都是給機器用的(例如有一個Application run在GCE VM中)，通常不需要有密碼之類的東西。是用e-mail(如: id-compute@developer.gserviceaccount.com)來辨識是否為service account。雖然沒有類似密碼的東西，但是會有一個private/public RSA key-pairs。而且這個account不能拿來login在web console。Service account有以下三種類型:

  1. Default service account — 當我們啟用某個服務時，該服務會帶出一個service account。建議這一類的account不要有Editor role。
  2. User Managed — 使用者(也就是我們)建立的。通常用在需要高度細緻化權限的情況
  3. Google-managed service accounts — GCP建立與管理的。由 GCP 用於代表使用者執行操作，通常我們不太需要管它。
使用場景一
  1. 建立該VM所需要Service Account Role的權限(least privilege)
  2. 將該role assign給該台VM

當我們使用Cloud-managed keys時:

  • 當我們將service account指派給instance時，Key的產生和使用由 IAM 自動處理
  • key會自動roate
  • 這種方式不需要我們在該台VM或Apllication的configuration配置密碼之類的東西

這個service account不要在該台VM運作時刪除，不然會出事。

場景二 — 地端VM到Cloud Storage
不用給密碼的service account只適合identities在GCP中。但是若是GCP之外的，就要給key(裡面包含帳密之類的資訊)了。所以在create一個service account之後，我們就要去針對這個account去產生一個key。

可以用gcloud
gcloud iam service-accounts keys create
或是web console的方式產生(如下圖)。通常我們會選擇是JSON格式的檔案，這個檔案需要小心地保存，不然外洩會有資安問題。

如果是我們的Application就會需要使用GCP提供的client libraries(ADC — Application Default Credentials )，如果環境變數 GOOGLE_APPLICATION_CREDENTIALS 存在，ADC 將使用service account key file。

或是設定在環境變數中:
export GOOGLE_APPLICATION_CREDENTIALS=”/PATH_TO_KEY_FILE

場景三 — 地端VM呼叫Cloud APIs
這是風險比較低的方法。credential type有以下三種:

  • OAuth 2.0 access tokens
  • OpenID Connect ID tokens
  • Self-signed JSON Web Tokens (JWTs)

當member需要提升權限時，他可以assume這一個service account role（為service account建立 OAuth 2.0 access token）。如果是Service to Service，哪就建議使用OpenID Connect ID tokens，這是身份驗證：GCP 中的服務需要向其他雲端中的服務進行自身身份驗證。

以下是其他Service Account經常會用到的使用場景及解決方法

ACL (Access Control Lists)

這是用在Cloud storage的Bucket/Object中，定義誰有權存取bucket和object，以及他們擁有什麼等級的存取權限。它與IAM不同之處在於:

  • IAM 最多只能設定在bucket level，所以該bucket裡的所有object的權限都會是一樣的
  • 但ACL可以權限等級縮小到單一個object之中
  • IAM與ACL兩種只能同時選一種使用

所以針對bukcet的存取控制:

  • 使用IAM(又稱為Uniform) — in bucket level
  • 使用ACL(又稱為Fine-grained) — in bucket/object level

當所有使用者對bucket中的所有object具有相同等級的存取權限時，使用Uniform存取權限，當需要在object level自訂存取權限時，請使用 ACL 進行Fine-grained access。

加密(Encryption)

為了達到資安的C.I.A中的機密性(confidential)，我們通常需要對資料進行加密(但需要先分級分類)。而在數位世界中，資料通常處於以下三種狀態:

  1. Data at rest(資料存放在某些地方):
    例如在HDD/DB/backup/archives等
  2. Data in motion或稱Data in transit(透過網路進行資料傳送):
    例如Application傳送資料到Database(這屬於內部LAN)，或者是地端傳送到GCP(透過Internet)
  3. Data in use(資料正在使用中):
    例如資料在memroy或是顯示在螢幕上

所以在這些資料的狀態中，為了達到機密性(也就是不該讓沒權限的人存取資料)。就需要進行加密(通常只有存放與傳送狀態可以加密)。所以我們就會到處都把資料加密，也有人稱"Defense in Depth"。從硬碟到資料庫到檔案通通都有加密機制存在。

對稱式加密(Symmetric Key Encryption)

簡單來說資料的加解密用的是同一把Key。使用這種加密方式，有三個因素我們需要考量到:

  1. 用哪種加密演算法
  2. 怎麼保護這一把Key
  3. 怎麼安全的與對方分享這一把Key

非同步式加密(Asymmetric Key Encryption)

簡單來說資料的加解密不是用同一把Key。會有: Public Key與Private Key之分，也稱做Public Key Cyptography。加密由Public key進行，解密由Private key或是反過來。

Cloud KMS(Key management Service)

這是GCP提供的金鑰託管服務，可以幫我們建立與管理cryptographic keys (symmetric與asymmetric)。並且使用API的方式對資料進行加解密與簽章，並且與大部分的GCP服務高度整合。KMS的金鑰管理模式有以下三種:

  1. Google-managed key: 不需要任何設定與管理，直接勾選使用
  2. Customer-managed key: 自行產生或在KMS產生金鑰後由KMS來管理
  3. Customer-supplied key: 自行產生的金鑰，KMS會用這一把Key來對由KMS產生的Key進行加密保護。通常用在Cloud stroage與GCE上。

Identity Platform

有用過AWS Cognito服務的人，可以跳過這一部分的功能介紹。它提供的就是一樣的功能。它跟Cloud IAM的不同點在於:

  • IAM用來對GCP中的resource進行存取控制
  • Identity Platform是對應用程式中的會有帳號登入的存取控制，著重在Authentication與Authorization。

主要功能

  • 針對web apps 與mobile apps (iOS, Android, ..)進行Authentication & authorization
  • 支援多種驗證方式，如:
    SAML, OIDC, email/password, 電話, 或與使用社交平台的帳號— Google/Facebook/Twitter/..
  • 可以User sign-up 與MFA等方式
  • 與 Identity-Aware Proxy高度整合

以下是根據一些使用場景來選擇驗證方式的範例。

雲端運算
Google Cloud Platform

--

--

運用"雲端服務"加速企業的數位轉型願景
運用"雲端服務"加速企業的數位轉型願景

Written by 運用"雲端服務"加速企業的數位轉型願景

405 Followers
1 Following

我們協助您駕馭名為"雲端運算"的怪獸，馴服它為您所用。諮詢請來信jason.kao@suros.com.tw. https://facebook.com/jason.kao.for.cloud

No responses yet

Help

Status

About

Careers

Press

Blog

Privacy

Terms

Text to speech

Teams