🔖

Professional Cloud Security Engineer 試験対策してみる

に公開
資格
idea

なにこれ

参考（前回取得時に参考にしていた情報）

Professional Cloud Security Engineer 認定試験ガイド(Google)

解説文

  • Cloud Security Engineer は、組織が Google Cloud で安全なワークロードとインフラストラクチャを設計して実装できるように支援します。セキュリティに関するベスト プラクティスと業界の要件についての知識を活かしながら、Google のセキュリティ技術を利用して安全なソリューションを設計、開発、管理します。
  • Cloud Security Engineer は、ID とアクセスの管理、組織のセキュリティ構造とポリシーの定義、Google Cloud テクノロジーを使用したデータ保護の提供、ネットワーク セキュリティの防御の構成、脅威に対応するための環境のモニタリング、セキュリティの自動化、AI セキュリティ、安全なソフトウェア サプライ チェーン、規制管理の適用に習熟しています。

セクション 1: クラウド ソリューション環境内のアクセスの構成（試験内容の約 27%）

1.1 Cloud Identity の管理。以下のような点を考慮します。

  • Google Cloud Directory Sync とサードパーティ コネクタの構成
    • Google Cloud Directory Sync (GCDS) は、オンプレミスのディレクトリ（例: Microsoft Active Directory）と Google Workspace または Cloud Identity を同期するツールです。
    • GCDS を使用することで、ユーザーアカウント、グループ、エイリアスなどを自動的に同期できます。
    • サードパーティコネクタ（例: Okta や OneLogin）は、Google Cloud と他のアイデンティティプロバイダー間で認証やプロビジョニングを統合する役割を果たします。
  • Google Cloud Directory Sync の構成
    • GCDS を構成する手順:
      1. インストールとセットアップ: GCDS をダウンロードして、サーバーにインストール。
      2. 接続設定: LDAP サーバーと Google Directory API の接続を設定。
      3. 同期設定: ユーザー、グループ、エイリアスの同期ルールを定義。
      4. テスト同期: 実際に同期を行う前に、設定が正しいかをテスト。
      5. スケジュール設定: 定期的な同期タスクをスケジューリング。
  • 特権管理者アカウントの管理

    • 特権管理者アカウントは、ディレクトリ全体にわたる高度な権限を持つため、厳重に管理する必要があります。以下のベストプラクティスを守ることが推奨されます:

      • 最小特権の原則: 不必要に特権を持たせない。
      • MFA（多要素認証）: 特権アカウントには MFA を必ず適用。
      • 監査ログの有効化: アクティビティを記録して、不正な操作を検出。
      • 専用のアカウントを使用: 特権操作は通常のアカウントと分けて管理。
  • ユーザー ライフサイクル管理プロセスの自動化

    • ユーザーのライフサイクル（入社、異動、退職）に伴うアカウント管理を自動化することで、セキュリティと効率性が向上します。

      • プロビジョニング: 新規ユーザーアカウントを自動作成。
      • デプロビジョニング: 退職時のアカウント削除やアクセス権限の削除。
      • ワークフローの設定: ユーザー属性に基づいたグループへの自動割り当て。
  • プログラムを使用したユーザー アカウントとグループの管理

    • Google Cloud では、プログラム（スクリプトや API）を使用してユーザーやグループの管理を自動化できます。

      • Directory API: ユーザーとグループを管理するための API を提供。
      • スクリプトの自動化: Python や Apps Script を使用して、アカウントの作成や更新を効率化。
      • サービスアカウントの利用: プログラムが IAM の役割を持ち、安全に操作を実行。

1.2 サービス アカウントを管理する。以下のような点を考慮します。

  • サービス アカウントとキーの保護と監査

    • サービス アカウントキーは、サービス間で安全な認証を提供します。
    • 認証情報（キー）は慎重に管理する必要があり、以下を実施するのが推奨されます:
      • IAM の最小権限原則: サービス アカウントに必要最低限の権限を付与。
      • キーの安全な保存: 秘密鍵は安全な場所（例: Secret Manager）に保存。
      • 監査ログの有効化: キーの使用状況や操作を記録。

  • ユーザーが管理するサービス アカウント キーのローテーションの自動化

    • 手動でキーを管理すると、漏洩や人為ミスのリスクがあります。自動化することでリスクを軽減。
    • 方法:
      • 古いキーを削除する前に新しいキーを作成。
      • スクリプトや Cloud Scheduler を使用して定期的にローテーション。
    • 推奨:
      • API や Terraform でのキー作成・削除の自動化。
      • 使用していないキーを削除。

  • サービス アカウントが必要なシナリオの特定

    • サービス アカウントは、人間以外のリソースやアプリケーションが GCP にアクセスする際に使用されます。

    • シナリオ例:

      • Cloud Run や Compute Engine から Cloud Storage へデータを書き込む。
      • BigQuery へのプログラムアクセス。
      • 他のプロジェクトや GCP サービス間でリソースを共有。

  • サービス アカウントの作成、無効化、保護

    • 作成: IAM 権限を指定してサービス アカウントを作成。

    • 無効化: 使われなくなったサービス アカウントは無効化してリスクを低減。

    • 保護: 不必要な権限を付与しない。Secret Manager や環境変数でキーを安全に管理。

    • 手順例:

      • gcloud コマンドでサービス アカウントを作成。
      • 必要な IAM ロールを付与。
      • 定期的に不要なアカウントを確認。

  • 有効期間の短い認証情報の管理と作成

    • セキュリティを強化するため、長期間有効なキーの使用を避け、有効期間の短いトークン（例: OAuth トークンや ID トークン）を使用。
    • 方法:
      • Google の gcloud auth コマンドでトークンを生成。
      • 短期間の認証情報を生成するために Workload Identity を使用。

  • Workload Identity 連携の構成

    • Workload Identity は、Kubernetes ワークロードがサービス アカウントを使用して GCP にアクセスするためのセキュアな方法。
    • 特徴:
      • サービス アカウントキーを使用しないため、キー管理の負担を削減。
      • Kubernetes サービス アカウントと GCP サービス アカウントを関連付け。
    • 設定例:
      • Kubernetes サービス アカウントを作成。
      • IAM の権限を付与。
      • ワークロードを GCP サービス アカウントに紐付け。

  • デフォルト サービス アカウントの保護

    • デフォルトのサービス アカウントは自動的に作成されますが、広範な権限を持つ場合があるため注意が必要。
    • 推奨:
      • デフォルト アカウントに過剰な権限を与えない。
      • 必要でない場合は無効化する。
      • 専用のサービス アカウントを作成して使用。

  • サービス アカウントの権限借用を管理する

    • サービス アカウントの権限借用（impersonation）は、他のリソースがサービス アカウントの権限を使用して操作を実行することを意味します。
    • ベストプラクティス:
      • 最小特権を適用。
      • Impersonation の使用状況を監査ログで確認。
      • 必要な場合のみ、roles/iam.serviceAccountTokenCreator を付与。

1.3 認証を管理する。以下のような点を考慮します。

  • ユーザー アカウントのパスワードとセッション管理ポリシーの作成

    • ユーザーのパスワードとセッション管理は、認証システムの重要なセキュリティ要素です。以下のポイントを考慮してポリシーを作成します：

      • パスワードポリシー:

        • 強力なパスワードを要求（例: 12文字以上、数字、記号、大文字/小文字の組み合わせ）。
        • パスワードの有効期限を設定（例: 90日）。
        • パスワードの再利用を制限。

      • セッション管理ポリシー:

        • セッションの有効期限を短く設定（例: 30分間の非アクティブ状態でログアウト）。
        • 信頼されていないデバイスまたは IP アドレスからのログインをブロック。
        • シングルサインアウト（SSO）を実装し、セッション終了時に他のアクティブセッションも終了。

  • Security Assertion Markup Language（SAML）と OAuth の設定

    • SAML: エンタープライズ環境で広く使用される認証プロトコルで、シングルサインオン（SSO）を実現します。ユーザーが一度ログインすれば、他のアプリケーションやサービスにもアクセス可能。

      • 設定手順:
        • Google Workspace または Cloud Identity を ID プロバイダー（IdP）として設定。
        • サードパーティアプリケーション（SP）の SAML 設定を Google に統合。
        • 証明書（X.509）を交換してセキュアな接続を確立。

    • OAuth: ユーザー認証とリソースアクセスを分離するための認可フレームワーク。アプリケーションがユーザーのアクセス許可を得てリソースを操作可能。

      • 設定手順:
        • Google Cloud Console で OAuth 2.0 クライアント ID を作成。
        • リダイレクト URI を指定。
        • アクセストークンを利用して API を呼び出す。

    • 比較:

    特徴 SAML OAuth
    主な用途 シングルサインオン（SSO） 認可とリソースアクセス
    主な利用対象 エンタープライズ環境 サードパーティアプリ
    認証情報の管理 IdP（アイデンティティプロバイダー） ユーザー（アクセストークン）

  • 2 要素認証プロセスの構成と適用

    • 2 要素認証（2FA）は、パスワードに加えて第2の認証要素を追加することで、認証プロセスを強化します。GCP では、多要素認証（MFA）が広く使用されています。

    • 構成方法:

      • 要素の種類:
        • 知識: パスワード、PIN。
        • 所有: ハードウェアトークン、スマートフォン。
        • 生体: 指紋、顔認証。
      • Google Cloud Console で有効化:
        • Google Cloud Identity または Workspace のセキュリティ設定で 2FA を強制。
        • ユーザーに Google Authenticator などのアプリを登録させる。
      • バックアップコード:
        • 認証デバイスの紛失時に備えて一時的なバックアップコードを発行。

    • 適用範囲:

      • 特権管理者アカウント。
      • 高度な権限を持つリソースやアクション。
      • センシティブなデータへのアクセス。

    • ベストプラクティス:

      • ユーザー教育を実施し、認証デバイスの管理についての意識を高める。
      • ユーザー体験を考慮しつつ、全体的なセキュリティ強化を図る。

1.4 承認制御を管理、実装する。 以下のような点を考慮します。

  • Identity and Access Management（IAM）のロールと権限による特権ロールと職掌分散の管理

    • Google Cloud の Identity and Access Management (IAM) は、特定のリソースに対するアクセス権限を管理します。IAM ロールと権限を使用して、特権を最小化し職掌分散（職務の分離）を実現します。

    • ロールの種類:

      • プリンシパル（Principal）ロール:
      • ユーザー、グループ、サービスアカウント、ドメインなど。

    • ロールのタイプ:

      • 基本ロール: Owner, Editor, Viewer。
      • プリンシパルロール: 特定のサービスの操作を細かく制御。
      • カスタムロール: 特定の権限のみを付与。

  • 職掌分散の実現:

    • 重要なタスクを複数のユーザーに分散。
      • 例: セキュリティ管理者は IAM ポリシーの管理、運用チームは VM 作成の権限のみ付与。

  • 異なるタイプの ID に対する権限の付与

    • IAM では、次の ID タイプごとに適切な権限を割り当てます。

      • ユーザー: 個々の従業員や管理者。
      • グループ: 共通のタスクを共有する複数のユーザー。
      • サービスアカウント: アプリケーションやワークロード。
      • ドメイン: 組織全体（例: example.com）。
      • Google グループ: ユーザー管理を簡素化。

    • 実例:

      • サービスアカウントに BigQuery データセットへの「roles/bigquery.dataViewer」を付与。
      • 特定のグループにプロジェクトレベルで「roles/viewer」を付与。

  • IAM とアクセス制御リスト（ACL）の権限の管理

    • IAM と ACL は異なるレベルでアクセス制御を提供します。

      • IAM:
        • リソース全体に対する権限を設定（例: Cloud Storage バケット全体）。
      • ACL:
        • リソース内の特定のオブジェクトに対する詳細な権限を設定（例: Cloud Storage 内の特定のファイル）。

    • ポイント:

      • IAM を優先して使用し、必要に応じて ACL を補助的に利用。
      • ACL 設定は複雑になりやすいため、過剰な使用を避ける。

  • 組織、フォルダ、プロジェクト、リソースレベルでの ID ロールの設計

    • Google Cloud では階層構造を使用してリソースを管理します。それぞれのレベルで IAM ポリシーを適用できます。

      • 組織レベル:
        • 全体に共通のポリシーを適用。
        • 例: 組織全体で「roles/securityAdmin」をセキュリティチームに付与。
      • フォルダレベル:
        • 関連するプロジェクトをまとめて管理。
        • 例: 開発用フォルダ内のプロジェクトに開発者用ロールを適用。
      • プロジェクトレベル:
        • プロジェクトごとに異なるポリシーを設定。
      • リソースレベル:
        • 特定のリソースに権限を適用。

  • Access Context Manager の構成

    • Access Context Manager（以前は Context-Aware Access）は、条件付きアクセス制御を提供します。

    • 特徴:

      • デバイス、IP アドレス、地理的場所などの条件に基づいてアクセスを制御。
      • 特定のリソースに対して詳細なポリシーを適用。

    • 構成例:

      1. アクセスポリシーを作成。
      2. 条件を定義（例: 社内ネットワークからのみアクセスを許可）。
      3. ポリシーをリソースに適用。

  • Policy Inteligence を適用した権限管理の改善

    • Policy Intelligence は、IAM 設定の最適化とセキュリティリスク軽減を支援するツールです。

    • 主要機能:

      • IAM リコメンダー: 使用されていない権限を特定して最小化。
      • アクセスバインディング分析: ポリシー設定の影響を視覚化。
      • ログベースのロール提案: ユーザーの活動ログに基づいて最適なロールを提案。

  • グループを通じた権限の管理

    • Google グループを使用して IAM 権限を一元管理することで、個々のユーザーに直接権限を付与する煩雑さを軽減。

    • メリット:

      • グループメンバーの変更が直接 IAM ポリシーに反映。
      • チームの役割ごとに権限を一括管理。

    • 実例:

      • 「roles/editor」を開発チーム用グループに付与。
      • 新しい開発者がチームに参加した場合、グループに追加するだけで権限が付与される。

1.5 リソース階層を定義する。以下のような点を考慮します。

  • 組織の作成と管理

    • Google Cloud のリソースは階層的に管理されます。組織は最上位レベルであり、以下の目的で利用されます：

      • ポリシーの統一管理: 組織レベルで IAM 権限や組織ポリシーを適用。
      • リソースの管理範囲を制御: すべてのプロジェクトやフォルダを組織に関連付けることで、統一管理。

    • 手順

      1. 組織の作成:
      • Google Workspace または Cloud Identity を設定すると、自動的に組織リソースが作成。
      • 管理者は「Super Admin」として自動的に割り当てられる。
      1. 組織の管理:
      • 組織リソース内でのアクセス制御（IAM ポリシー）を設定。
      • 組織レベルでのポリシー（例: ドメイン制約やリソースの場所制限）を適用。

  • 組織のフォルダ、プロジェクト、リソースの組織のポリシーの管理

    • 組織階層は、以下のレベルに分けられます：

      • 組織:

        • 階層の最上位。
        • 組織全体に適用されるポリシー（例: 組織の場所制限）を管理。

      • フォルダ:

        • 部門やチーム単位でプロジェクトをまとめる。
        • 特定のフォルダにのみ適用されるポリシーを設定可能。
        • フォルダ内のプロジェクトやリソースはフォルダポリシーを継承。

      • プロジェクト:

        • GCP リソース（VM、データベース、ストレージなど）が含まれる単位。
        • プロジェクトレベルで特定の IAM 権限やポリシーを適用。

      • リソース:

        • プロジェクト内の個々のリソース（例: Compute Engine VM、Cloud Storage バケットなど）。

    • 組織ポリシーの管理:

      • 組織ポリシーサービスを使用して、構成制約（constraints）を設定。
      • 例:
        • 「Cloud Storage バケットを特定のリージョン内に制限する」。
        • 「外部 IP の使用を禁止する」。

  • リソース階層を使用したアクセス制御と権限の継承

    • Google Cloud のリソース階層では、上位レベルの権限やポリシーが下位レベルに継承されます。

    • 権限の継承の仕組み:

      • 組織レベルで設定した IAM ポリシーは、すべてのフォルダ、プロジェクト、リソースに継承。
      • フォルダレベルで設定した IAM ポリシーは、そのフォルダ内のプロジェクトとリソースに継承。
      • プロジェクトレベルでの IAM ポリシーは、そのプロジェクト内のリソースに継承。

    • 継承の例:

      • 組織レベルで「roles/viewer」を付与されたユーザーは、すべてのプロジェクトで閲覧権限を持つ。
      • フォルダレベルで「roles/editor」を付与された場合、そのフォルダ内のプロジェクトでは編集権限を持つ。

    • 例外:

      • 特定のリソースにカスタム権限を設定すると、継承が上書きされる。

    • アクセス制御の利点:

      • 階層的な権限管理で設定の重複を防ぐ。
      • ポリシーの一括適用が可能（例: 組織全体でセキュリティ管理を統一）。

セクション 2: 境界と境界のセキュリティの構成（試験内容の約 21%）

2.1 境界セキュリティを設計する。以下のような点を考慮します。

  • ネットワークの境界制御（ファイアウォール ルール、階層型ファイアウォール、Identity-Aware Proxy（IAP）、ロードバランサ、Certi cate Authority Service）の構成

    • Google Cloud では、境界セキュリティを強化するために以下の構成要素を使用します。

      • ファイアウォールルール:

        • 仮想ネットワーク内のトラフィックを制御。
        • 構成例: 特定の IP アドレスからのポート 80 (HTTP) へのアクセスを許可。
        gcloud compute firewall-rules create allow-http \
--direction=INGRESS \
--action=ALLOW \
--rules=tcp:80 \
--source-ranges=203.0.113.0/24 \
--network=default

      • 階層型ファイアウォール:

        • 組織やフォルダレベルでポリシーを適用し、プロジェクト内のファイアウォールルールより優先。
        • 利点: 組織全体で一貫性のあるセキュリティポリシー。

      • Identity-Aware Proxy (IAP):

        • アプリケーションへのアクセスを、ユーザーの ID とコンテキストに基づいて制御。
        • 使用例: 特定の Google アカウントを持つユーザーのみ Web アプリにアクセス許可。

      • ロードバランサ:

        • トラフィックを分散し、境界セキュリティとして SSL/TLS を適用可能。
        • 構成例: HTTPS ロードバランサを使用して、暗号化された接続を確保。

      • Certificate Authority Service:

        • 自社の認証局を管理し、TLS 証明書を発行。
        • 使用例: 内部システム間の通信を暗号化する証明書を生成。

  • プライベート アドレスとパブリック アドレスの違いの特定

    • プライベートアドレス:

      • ローカルネットワーク内で使用されるアドレス。
      • インターネットに直接アクセス不可（NAT 必須）。
      • 例: 10.0.0.0/8、192.168.0.0/16。

    • パブリックアドレス:

      • インターネット上でグローバルにユニークなアドレス。
      • 外部から直接アクセス可能。
      • 例: 203.0.113.1。

    • 比較ポイント:

      • プライベートアドレスはセキュリティ向上（外部からの直接アクセスを防止）。
      • パブリックアドレスはグローバルなサービス提供に必要。

  • ウェブ アプリケーション ファイアウォールの構成（Google Cloud Armor）

    • Google Cloud Armor は、DDoS 攻撃や OWASP トップ 10 脆弱性（例: SQL インジェクション、XSS）からアプリケーションを保護する WAF 機能を提供。

    • 構成例:

      • セキュリティポリシー作成:

        gcloud compute security-policies create my-security-policy \
--description "My WAF Policy"

      • ルール追加:

        • IP アドレスベースのアクセス制御:
        gcloud compute security-policies rules create 1000 \
--security-policy=my-security-policy \
--description="Allow specific IP" \
--src-ip-ranges=203.0.113.0/24 \
--action=allow
        • SQL インジェクション保護: OWASP プリセットルールを適用。

      • ロードバランサに適用: セキュリティポリシーをバックエンドサービスに関連付け。

  • Cloud DNS セキュリティ設定の構成

    • Cloud DNS は、Google Cloud のスケーラブルなドメイン名解決サービスであり、セキュリティを強化するための以下の設定が可能。

      • DNSSEC（DNS Security Extensions）:

        • DNS レコードにデジタル署名を適用し、なりすましや改ざんを防止。
        • 構成例:
          • DNSSEC を有効化:
          gcloud dns managed-zones update my-zone \
--dnssec-state=on
          • ドメイン登録機関に公開鍵を登録。

      • アクセス制御:

        • Google Cloud IAM を使用して、DNS ゾーンへの管理アクセスを制御。
        • 例: 「roles/dns.admin」を特定のグループに付与。

      • 監査ログ:

        • Cloud Logging を有効化し、DNS クエリや変更のログを記録。
        • メリット: 不正なアクセスを検出可能。

2.2 境界セグメントを構成する。以下のような点を考慮します。

  • VPC ネットワーク、VPC ピアリング、共有 VPC、ファイアウォール ルールのセキュリティ特性の構成

    • VPC ネットワーク

      • Google Cloud の Virtual Private Cloud (VPC) は、仮想ネットワークを提供し、プロジェクト内のリソースを接続します。
      • セキュリティ特性:
        • サブネット構成: 各サブネットにプライベート IP 範囲を割り当て。
        • リージョン設定: サブネットはリージョン単位で作成。
        • デフォルトの分離: VPC 間の通信はデフォルトで許可されない。

    • VPC ピアリング

      • 異なる VPC ネットワーク間での通信を確立します。
      • セキュリティ特性:
        • 双方向の通信を許可。
        • トラフィックは Google の内部ネットワーク上で暗号化。

    • 共有 VPC

      • 複数のプロジェクトが同じ VPC ネットワークを共有可能。
      • セキュリティ特性:
        • リソースを各プロジェクトに分割しながら、中央のネットワーク管理を維持。
        • 特定の IAM ロール（例: Network Admin）で管理を分離。

  • ファイアウォールルール

    • VPC 内外のトラフィックを制御します。
    • セキュリティ特性:
      • デフォルトの「allow-internal」ルールは、VPC 内部トラフィックを許可。
      • 「deny」ルールを明示的に設定して不必要なアクセスを遮断。
    • 構成例
    gcloud compute firewall-rules create block-external-ssh \
--network=default \
--action=DENY \
--rules=tcp:22 \
--direction=INGRESS \
--priority=1000 \
--source-ranges=0.0.0.0/0

  • N 層アプリケーションを設計する際のネットワークの隔離とデータのカプセル化の構成

    • N 層アプリケーション（例: フロントエンド、アプリケーション層、データベース層）は、各層をネットワーク的に分離することでセキュリティを向上させます。

    • ネットワークの隔離:

      • 各層を異なるサブネットに配置。
      • ファイアウォールルールで層間通信を制限。
      • 外部トラフィックはフロントエンド層にのみ許可。

    • データのカプセル化:

      • データベース層はプライベート IP のみ使用。
      • Cloud NAT を使用してインターネット接続をセキュアに構成。

    • 設計例:

      • フロントエンド層:

        • パブリック IP を持ち、外部からアクセス可能。
        • HTTPS ロードバランサを設定。

      • アプリケーション層:

        • プライベートサブネット内に配置。
        • フロントエンド層からの通信のみ許可。

      • データベース層:

        • プライベート IP のみ。
        • アプリケーション層からの接続のみ許可。

      • 構成例:

      # フロントエンド層サブネットの作成
gcloud compute networks subnets create frontend-subnet \
    --network=default \
    --range=10.0.0.0/24 \
    --region=us-central1

# アプリケーション層サブネットの作成
gcloud compute networks subnets create app-subnet \
    --network=default \
    --range=10.0.1.0/24 \
    --region=us-central1

# データベース層サブネットの作成
gcloud compute networks subnets create db-subnet \
    --network=default \
    --range=10.0.2.0/24 \
    --region=us-central1

  • VPC Service Controls の構成

    • VPC Service Controls は、Google Cloud のサービスを保護し、データ流出を防ぐための境界セキュリティを提供します。

    • 機能:

      • データの境界を設定し、外部ネットワークや不正アクセスから保護。
      • アクセスポリシーを定義し、信頼された条件下でのみリソースへのアクセスを許可。

    • セキュリティ特性:

      • サービス間通信の制限。
      • VPC 境界を越えたデータ移動をブロック。

    • 構成例:

      • 境界の作成:
      gcloud access-context-manager perimeters create my-perimeter \
--title="My VPC Service Perimeter" \
--resources=projects/PROJECT_ID \
--restricted-services=bigquery.googleapis.com,storage.googleapis.com
      • アクセスレベルの追加: 信頼された IP アドレス範囲を指定。
      gcloud access-context-manager access-levels create my-access-level \
--title="Trusted IPs" \
--basic-level-spec="ipSubnetworks: [203.0.113.0/24]"
      • ポリシーに適用: 境界にアクセスレベルを関連付け。
      gcloud access-context-manager perimeters update my-perimeter \
--add-access-levels=my-access-level

2.3 プライベート接続を確立する。以下のような点を考慮します。

  • VPC ネットワークと Google Cloud プロジェクト間のプライベート接続の設計と構成（共有VPC、VPC ピアリング、およびオンプレミス ホスト用の限定公開の Google アクセス）

    • 共有 VPC

      • 1つのホストプロジェクトで VPC ネットワークを作成し、複数のサービスプロジェクトでリソースを使用可能にする仕組み。
      • 利点:
        • ネットワーク管理を一元化。
        • 各サービスプロジェクトにアクセス権を細かく設定可能。
      • 構成例:
        • ホストプロジェクトで VPC を作成。
        • サービスプロジェクトに特定のサブネットを割り当て、IAM を使用してアクセスを制御。

    • VPC ピアリング

      • 異なるプロジェクトや組織の VPC 間で通信を可能にする。
      • 構成例:
      gcloud compute networks peerings create my-peering \
--network=network-1 \
--peer-network=network-2 \
--auto-create-routes

    • オンプレミスホスト用の限定公開の Google アクセス

      • オンプレミス環境から Google Cloud サービス（例: BigQuery, Cloud Storage）にアクセスを許可。
      • 構成例:
        • Cloud VPN または Interconnect を使用してオンプレミス環境を Google Cloud に接続。
        • NAT や Private Service Connect を設定し、インターネット経由せず Google API にアクセス。

  • データセンターと VPC ネットワーク間のプライベート接続の設計と構成（IPsec と Cloud Interconnect）

    • IPsec VPN

      • インターネット経由で VPC とオンプレミスをセキュアに接続。
      • 特徴:
        • 比較的低コスト。
        • 帯域幅は最大 3 Gbps（複数トンネルでスケール可能）。
      • 構成例:
        • Cloud VPN ゲートウェイを作成。
        • オンプレミスの VPN ゲートウェイとトンネルを構成。

    • Cloud Interconnect

      • 専用の高帯域幅接続を提供。
      • 種類:
        • Dedicated Interconnect:
          • 専用回線を提供（最大 100 Gbps）。
        • Partner Interconnect:
          • サードパーティプロバイダーを介した接続（柔軟な帯域幅）。
      • 構成例:
        • VLAN アタッチメントを作成し、オンプレミスネットワークに接続。
        • BGP を使用してルートを交換。

  • VPC と Google API 間のプライベート接続の確立（限定公開の Google アクセス、制限付きの Google アクセス、オンプレミス ホスト用の限定公開の Google アクセス、Private Service Connect）

    • 限定公開の Google アクセス

      • VPC 内のリソースが、外部 IP アドレスを持たずに Google API（例: Cloud Storage, BigQuery）にアクセス可能。
      • 構成例:
        • プライベートサブネットで「Private Google Access」を有効化。

    • 制限付きの Google アクセス

      • サービス制約を設けた限定アクセス。
      • 構成例:
        • Access Context Manager を使用して、特定の API サービスのみ許可。

    • Private Service Connect

      • プライベート IP を介して Google サービスや他の VPC 内のサービスにアクセス。
      • 構成例:
        • PSC エンドポイントを作成し、サービスへのプライベートアクセスを設定。

  • Cloud NAT を使用した送信トラフィックの有効化

    • Cloud NAT（Network Address Translation）は、外部 IP アドレスを持たない VPC 内リソースがインターネットにアクセスするためのセキュアな方法を提供します。

    • 特徴:

      • リソースがプライベート IP を維持しながら、インターネットにアクセス。
      • 接続を開始したトラフィックのみ許可（ステートフル NAT）。

    • 構成例:

      • Cloud Router を作成:
      gcloud compute routers create my-router \
--network=default \
--region=us-central1
      • Cloud NAT を作成:
      gcloud compute routers nats create my-nat \
--router=my-router \
--auto-allocate-nat-external-ips \
--nat-all-subnet-ip-ranges

セクション 3: データ保護の確保（試験内容の約 20%）

3.1 機密データの保護とデータ損失の防止。以下のような点を考慮します。

  • 個人情報（PII）の検査と秘匿化

    • PII（Personally Identifiable Information）は、データ漏洩時にリスクの高い情報です。GCP では、Cloud Data Loss Prevention (DLP) API を使用して以下を実現します：

      • 検査: データセット内の PII を検出。

      • 秘匿化: 必要に応じてデータをマスクまたは削除。

      • 機能例:

        • クレジットカード番号、電話番号、メールアドレスなどの自動検出。
        • レポート生成でリスクを可視化。

    • 構成例:

    gcloud dlp inspect content \
  --data="My phone number is 555-123-4567" \
  --info-types="PHONE_NUMBER"

  • 仮名化の構成

    • 仮名化は、PII を特定の形式で匿名化する方法です。具体的には、元データを可逆的または不可逆的に変換し、元データを直接参照できないようにします。

    • 例:

      • クレジットカード番号「1234-5678-9012-3456」を「xxxx-xxxx-xxxx-3456」に変換。
      • 名前をハッシュ化して匿名化。

    • Cloud DLP の仮名化機能:

      • フォーマット保持暗号化（FPE）やハッシュ化を使用。
      • 構成例:
      gcloud dlp deidentify \
--input-file=sample.json \
--deidentify-template=deid_template \
--output-file=output.json

  • フォーマット保持置換の構成

    • フォーマット保持置換（FPE）は、データの元の形式を保ちながら暗号化を実施します。例えば、クレジットカード番号の形式を保ったまま匿名化。

    • 用途:

      • アプリケーションでフォーマットを変更せずにセキュアな処理を実現。
      • 復号化による元データの復元が可能。

    • Cloud DLP の FPE 構成例:

    gcloud dlp deidentify \
  --input-file=sample.json \
  --deidentify-template=fpe_template \
  --output-file=output.json

  • BigQuery、Cloud Storage、Cloud SQL のデータストアへのアクセスの制限

    • GCP では IAM を使用してリソースへのアクセスを制限します。

    • BigQuery:

      • データセット、テーブル、ビュー単位で IAM 権限を設定。
      • 例: 「roles/bigquery.dataViewer」で特定ユーザーに読み取りアクセスを付与。

    • Cloud Storage:

      • バケットレベルおよびオブジェクトレベルで IAM と ACL を設定。
      • 例: 特定のサービスアカウントに「roles/storage.objectViewer」を付与。

    • Cloud SQL:

      • ユーザーアカウントと IP アドレス制限を組み合わせてセキュリティを強化。
      • 例: Cloud SQL Auth プロキシを使用して認証を強化。

    • 設定例（IAM 権限の付与）:

    gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="user:example@example.com" \
  --role="roles/bigquery.dataViewer"

  • Secret Manager でのシークレットの保護

    • Secret Manager は、API キーやパスワードなどの機密情報を安全に保存・管理するためのサービスです。

    • 機能:

      • アクセス制御: IAM を使用してシークレットの読み取りを管理。
      • バージョニング: シークレットの複数バージョンを保存。
      • 暗号化: Google のマネージドキーで暗号化。

    • 構成例:

      • シークレットを作成:
      gcloud secrets create my-secret --replication-policy="automatic"
      • シークレットの値を設定:
      echo -n "my-secret-value" | gcloud secrets versions add my-secret --data-file=-
      • シークレットのアクセス制御:
      gcloud secrets add-iam-policy-binding my-secret \
--member="user:example@example.com" \
--role="roles/secretmanager.secretAccessor"

  • コンピューティング インスタンス メタデータの保護と管理

    • コンピューティングインスタンス（例: Compute Engine）には、メタデータサーバーを通じて重要な情報（例: API キーやサービスアカウント）が含まれています。この情報を適切に保護することが重要です。

    • ベストプラクティス:

      • IAM 制御: サービスアカウントに最小権限を付与。
      • Metadata Concealment: インスタンスメタデータへの不必要なアクセスを防止。
      • シークレット管理: 環境変数ではなく Secret Manager を使用。

    • 設定例（IAM 最小権限付与）:

    gcloud compute instances set-service-account INSTANCE_NAME \
  --scopes=https://www.googleapis.com/auth/cloud-platform \
  --zone=ZONE
    • 特定のメタデータキーを制限:
    gcloud compute instances add-metadata INSTANCE_NAME \
  --metadata="block-project-ssh-keys=true"

3.2 保存中、転送中、使用中の暗号化の管理。以下のような点を考慮します。

  • Google のデフォルトの暗号化、顧客管理の暗号鍵（CMEK）、顧客指定の暗号鍵（CSEK）、Cloud External Key Manager（EKM）、Cloud HSM のユースケースの確認

    • Google のデフォルトの暗号化

      • Google Cloud は、データ保存中（at rest）と転送中（in transit）にデフォルトで暗号化を適用。
      • ユースケース:
        • セキュリティが強化され、暗号化の管理を必要としない場合。

    • 顧客管理の暗号鍵（CMEK）

      • 暗号鍵を Google Cloud Key Management Service (KMS) で管理。
      • ユースケース:
        • 暗号鍵のライフサイクル管理を制御したい場合。
        • 例: BigQuery、Cloud Storage、Compute Engine ディスク。

    • 顧客指定の暗号鍵（CSEK）

      • ユーザーが暗号鍵を管理し、Google Cloud にアップロード。
      • ユースケース:
        • 鍵管理を完全に顧客が制御したい場合。
        • 例: 機密性が非常に高いプロジェクト。

    • Cloud External Key Manager（EKM）

      • 外部のキー管理システムと Google Cloud を統合。
      • ユースケース:
        • 既存のオンプレミスや外部キー管理システムを利用したい場合。

    • Cloud HSM

      • ハードウェア セキュリティ モジュール (HSM) で鍵を生成・管理。
      • ユースケース:
        • ハードウェアレベルで鍵のセキュリティを強化したい場合。

  • CMEK、CSEK、EKM の暗号鍵の作成と管理

    • CMEK の鍵作成:

      • 手順:
        • Cloud KMS で鍵リングと鍵を作成:
        gcloud kms keyrings create my-keyring --location=global
gcloud kms keys create my-key --location=global --keyring=my-keyring --purpose=encryption
        • 作成した鍵をリソース（例: Cloud Storage バケット）に関連付け。

    • CSEK の鍵作成:

      • 鍵をローカルで生成し、使用時に提供。
      • 手順:
        • オンプレミスで AES-256 暗号鍵を生成。
        • CSEK を指定してリソース作成。
        gcloud compute disks create my-disk --encryption-key-file=my-key.json

    • EKM の鍵管理:

      • 外部キー管理システムと連携。
      • 手順:
        • EKM を設定し、外部鍵を Google Cloud に統合。
        • 使用するリソースで EKM 鍵を指定。

  • ユースケースへの Google の暗号化アプローチの適用

    • 保存中のデータ:

      • デフォルト暗号化または CMEK を適用。
      • 例: Cloud Storage での大規模なデータ保存。

    • 転送中のデータ:

      • TLS を使用して暗号化。
      • 例: Cloud Interconnect を使用したデータ転送。

    • 使用中のデータ:

      • Confidential Computing を使用して、メモリ内のデータを暗号化。
      • 例: 機密性が高いアプリケーションワークロード。

  • Cloud Storage のオブジェクト ライフサイクル ポリシーの構成

    • Cloud Storage のライフサイクル管理を使用して、データ保存のコストとセキュリティを最適化します。

    • ユースケース:

      • 古いオブジェクトを削除。
      • アクセス頻度に応じてストレージクラスを変更。

    • 構成例:

      • ライフサイクルポリシーを JSON 形式で定義:
      {
  "rule": [
    {
      "action": { "type": "Delete" },
      "condition": { "age": 365 }
    },
    {
      "action": { "type": "SetStorageClass", "storageClass": "NEARLINE" },
      "condition": { "age": 30 }
    }
  ]
}
      • ポリシーを適用:
      gcloud storage buckets update BUCKET_NAME --lifecycle-file=lifecycle.json

  • Condential Computing の有効化

    • Confidential Computing は、データ使用中（in use）でも暗号化を提供します。これにより、クラウド環境でも機密データのセキュリティが向上します。

    • 使用例:

      • Confidential VM を使用して、メモリ内のデータを暗号化。
      • セキュアなアプリケーション処理。

    • 構成例:

    gcloud compute instances create confidential-vm \
  --confidential-compute \
  --zone=us-central1-a

  • 転送データの暗号化

    • データ転送中のセキュリティを確保するために、TLS（Transport Layer Security）を使用します。

    • ユースケース:

      • 外部クライアントと Google Cloud サービス間の通信。
      • Google Cloud 内のリソース間の通信（例: VM インスタンス間）。

    • 構成例:

      • HTTPS を使用して安全な通信を確立:
      gcloud compute ssl-certificates create my-cert \
--domains=my-example-domain.com

セクション 4: クラウド ソリューション環境内のオペレーションの管理（試験内容の約 22%）

4.1 安全なインフラストラクチャとアプリケーションを構築、デプロイする。以下のような点を考慮します。

  • 継続的インテグレーションと継続的デリバリー（CI/CD）のパイプラインによる、共通脆弱性識別子（CVE）に対するセキュリティ スキャンの自動化

    • CI/CD パイプラインにセキュリティスキャンを統合することで、アプリケーションの開発、ビルド、デプロイの各フェーズで脆弱性を検出できます。

    • 手法:

      • ソースコードスキャン:
        • 例: SonarQube や Snyk を使用して、コードの脆弱性を検出。
      • 依存関係スキャン:
        • 例: GitHub Dependabot や Trivy を使用して、ライブラリやパッケージの CVE を検出。
      • コンテナイメージスキャン:
        • 例: Google Cloud の Container Analysis を使用して、Docker イメージの脆弱性をチェック。

    • 実装例（Google Cloud Build の統合）:

      • Cloud Build にセキュリティスキャンステップを追加。
      steps:
- name: 'gcr.io/cloud-builders/gcloud'
  args: ['container', 'images', 'list-vulnerabilities', '--repository=REPO_NAME']

    • 利点:

      • 脆弱性の早期検出と修正。
      • セキュリティチェックの自動化により、運用負荷を軽減。

  • 仮想マシンイメージの作成、強化、メンテナンス、パッチ管理の自動化

    • 仮想マシン（VM）イメージは、最新のパッチやセキュリティ設定を適用して、安全性を確保する必要があります。

    • イメージの作成と強化:

      • Google Cloud の OS Config を使用して、イメージのパッチ適用やカスタマイズを自動化。

    • 強化の手法:

      • 不要なサービスやポートを無効化。
      • デフォルトアカウントの削除。

    • メンテナンスとパッチ管理:

      • Google Cloud の OS Patch Management を使用して、定期的にパッチを適用。

    • 構成例:

    gcloud compute os-config patch-jobs execute \
--instance-filter="zone:(us-central1-a)" \
--description="Patch critical updates"

  • コンテナ イメージの作成、検証、強化、メンテナンス、パッチ管理の自動化

    • コンテナイメージは、最小限のベースイメージを使用し、必要なセキュリティ強化を施すことが重要です。

    • イメージ作成と強化:

      • 最小イメージの使用:
        • 例: Alpine Linux や Distroless イメージを使用。
      • セキュリティベストプラクティス:
        • 必要なパッケージのみインストール。
        • RUN レイヤーの最小化。

    • 検証とパッチ管理:

      • Container Analysis を使用して脆弱性をスキャン。
      gcloud artifacts docker images list --repository=REPO_NAME

    • CI/CD パイプラインでの自動化例:

      • Build ステップで脆弱性スキャンを追加。
      • レジストリポリシーを設定し、基準を満たさないイメージのデプロイを禁止。

  • Policy as Code とドリフト検出の自動化

    • Policy as Code は、インフラポリシーをコードとして記述し、自動的に適用、監視する手法です。また、ドリフト検出は、実際のインフラがコードに記述された状態と一致しているかを検証します。

    • Policy as Code:

      • Google Cloud の Organization Policy Service を使用して、ポリシーを管理。
      • 例:
        • 外部 IP の使用を禁止。
        constraints:
- name: constraints/compute.disableExternalIp
  enforced: true

    • ドリフト検出:

      • Terraform や Config Connector を使用して、インフラの状態を定期的に検証。
      • 実装例:
      terraform plan -detailed-exitcode

    • 自動化の利点:

      • セキュリティポリシーの一貫性を維持。
      • 変更や設定ミスを早期に検出。

4.2 ロギング、モニタリング、検出を構成する。 以下のような点を考慮します。

  • ネットワーク ログの構成と分析（ファイアウォール ルールのログ、VPC フローログ、Packet Mirroring、Cloud Intrusion Detection System（Cloud IDS））

    • ファイアウォールルールのログ

      • Google Cloud ファイアウォールルールの適用結果を記録。
      • ユースケース:
        • 許可または拒否されたトラフィックの可視化。
        • 不審なトラフィックパターンの特定。
      • 構成例:
      gcloud compute firewall-rules update RULE_NAME --enable-logging

    • VPC フローログ

      • VPC 内のネットワークトラフィック（インスタンス間通信）を記録。
      • ユースケース:
        • トラフィックのトラブルシューティング。
        • セキュリティインシデントの監視。
      • 構成例:
      gcloud compute networks subnets update SUBNET_NAME --enable-flow-logs

    • Packet Mirroring

      • 特定のトラフィックをキャプチャし、セキュリティ解析ツールへ送信。
      • ユースケース:
        • 高度なセキュリティ解析や侵入検出。

    • Cloud Intrusion Detection System (Cloud IDS)

      • ネットワークレベルで脅威をリアルタイム検出。
      • ユースケース:
        • 既知の脅威や攻撃パターン（例: DDoS 攻撃）の検出。

  • 効果的なロギング戦略の設計

    • ポイント:

      • ログの優先順位付け:
        • 重要なリソースやサービスに焦点を当てる。
        • 例: IAM ポリシー変更ログ、ネットワークトラフィックログ。
      • 保持期間の設定:
        • 必要なログの保存期間をビジネス要件に応じて設定。
      • ログの構造化:
        • JSON 形式で記録することで解析を簡略化。

    • ベストプラクティス:

      • ログ量を最小化するためにフィルタリングを適用。
      • 例: Cloud Storage のアクセスログは「読み取り」イベントのみを記録。

  • セキュリティ インシデントのロギング、モニタリング、対応、修正

    • ロギング:

      • Cloud Audit Logs を有効化し、すべての管理アクティビティを記録。
      • 例: ユーザーが削除したリソースのログ。

    • モニタリング:

      • Cloud Monitoring を使用して、ログからカスタムメトリクスを作成。
      • 例: IAM ロールの変更を監視し、異常を検出。

    • 対応:

      • Event Threat Detection を使用して自動アラートを生成。
      • 例: 権限昇格や不正アクセスの通知。

    • 修正:

      • Cloud Functions を利用し、自動修正プロセスを実行。
      • 例: 許可されていないポートの自動閉鎖。

  • 外部セキュリティ システムへのログのエクスポート

    • 方法:

      • ログシンクを設定し、外部の SIEM（例: Splunk、Datadog）にログを転送。
      • 構成例:
      gcloud logging sinks create SINK_NAME STORAGE_DESTINATION --log-filter="resource.type=gce_instance"

    • ユースケース:

      • 外部ツールを使用して詳細なセキュリティ解析。
      • 長期保存や法令遵守のためのアーカイブ。

  • Google Cloud Audit Logs とデータアクセス ログの構成と分析

    • Audit Logs:

      • Google Cloud サービスのすべての管理操作を記録。
      • ログタイプ:
        • 管理アクティビティ。
        • データアクセス。
        • システムイベント。

    • データアクセス ログ:

      • ユーザーがデータにアクセスした際の詳細を記録。
      • ユースケース:
        • 機密データへのアクセス追跡。

  • ログのエクスポートの構成（ログシンクと集約シンク）

    • ログシンク:

      • 特定のログを指定された宛先（Cloud Storage、BigQuery、Pub/Sub）に転送。
      • 構成例:
      gcloud logging sinks create my-sink storage.googleapis.com/my-bucket

    • 集約シンク:

      • 複数のプロジェクトやフォルダのログを一括管理。
      • ユースケース:
      • 組織レベルでログを一元化。

  • Security Command Center の構成とモニタリング（Security Health Analytics、Event Threat Detection、Container Threat Detection、Web Security Scanner）

    • Security Health Analytics:

      • 設定ミスやセキュリティリスクを検出。
      • 例: 公開されたストレージバケットの特定。

    • Event Threat Detection:

      • 侵入試行やマルウェアをリアルタイムで検出。

    • Container Threat Detection:

      • コンテナ内の異常なアクティビティを監視。

    • Web Security Scanner:

      • アプリケーションの脆弱性（例: XSS、SQL インジェクション）を検出。

    • 構成例:

    gcloud scc settings update --organization=ORG_ID --enable-service=SECURITY_HEALTH_ANALYTICS

セクション 5: コンプライアンス要件のサポート（試験内容の約 10%）

5.1 クラウドの規制要件を決定する。 以下のような点を考慮します。

  • コンピューティング、データ、ネットワークに関する懸念事項の特定

    • クラウド環境では、以下の懸念事項を特定し、対策を講じることが重要です。

    • コンピューティング:

      • 仮想マシンの分離: マルチテナント環境でのリソース分離が適切か。
      • ワークロードのセキュリティ: コンフィデンシャルコンピューティングを利用してデータ使用中の保護を確保。

    • データ:

      • データの保管場所: 規制要件に基づいて、データが特定の地域に保存される必要がある場合。
      • データ暗号化: 保存中、転送中、使用中のデータ暗号化を実施。

    • ネットワーク:

      • アクセス制御: ネットワークレベルでの不正アクセスを防止。
      • トラフィック監視: VPC フローログや Cloud IDS を使用して異常なトラフィックを検出。

  • セキュリティの共有責任モデルの評価（アクセスの透明性）

    • クラウドセキュリティの責任は、プロバイダー（Google Cloud）と顧客で分担されます。このモデルを理解し、役割を明確にすることが必要です。

    • Google Cloud の責任:

      • インフラストラクチャのセキュリティ（物理データセンターの保護、ハードウェア管理）。
      • 基本的なサービスの暗号化とセキュリティ管理。

    • 顧客の責任:

      • データの分類と保護。
      • アクセス制御の適切な設定（IAM、ネットワークポリシー）。

    • アクセスの透明性:

      • Google の Access Transparency を使用して、Google のサポートチームがデータにアクセスした際の記録を確認可能。
      • ユースケース: 規制要件に基づきデータアクセスを監視。

  • クラウド環境内のセキュリティ管理の構成（データとサービスのリージョン化）

    • データとサービスのリージョン化により、規制要件を満たすことができます。

    • データリージョン化:

      • Cloud Storage や BigQuery でデータの保存場所を特定のリージョンに制限。
      • 構成例:
      gcloud storage buckets create BUCKET_NAME --location=asia-northeast1

    • サービスリージョン化:

      • Compute Engine や Cloud Functions を特定のリージョンで実行することで、データとワークロードのリージョン要件を満たす。

    • ユースケース:

      • ヨーロッパでの GDPR 準拠のため、データを EU 内に保持。
      • 日本国内法に準拠するため、データを「asia-northeast1」に保存。

  • 規制コンプライアンスのためのコンピューティングとデータの制限

    • 規制要件に基づき、以下の方法でコンピューティングとデータを制限します。

    • コンピューティング:

      • コンフィデンシャル VM を利用して、データ使用中の保護を強化。
      • 例: 医療データや金融データのワークロードに使用。

    • データ:

      • アクセス制御: IAM を使用して最小権限を適用。
      • 制限付き Google アクセス: データをインターネットに公開せず、特定の条件でのみアクセス許可。

  • 規制コンプライアンスのための Google Cloud 環境の決定

    • Google Cloud では、以下の機能を活用して規制コンプライアンスを実現します。

    • 監査対応機能:

      • Google Cloud Audit Logs を有効化し、すべてのアクティビティを記録。

    • データロケーション管理:

      • Google Cloud の「Data Residency」機能を使用して、データ保存場所を指定。

    • セキュリティツール:

      • Security Command Center で構成ミスや脅威を一元管理。
      • Policy Intelligence を使用して最小権限設定を提案。

    • ユースケース:

      • 医療データ（HIPAA 準拠）:

        • データを特定のリージョンに保存。
        • アクセス制御を厳格化。

      • 金融データ（PCI DSS 準拠）:

        • コンフィデンシャルコンピューティングを使用。
        • 監査ログを設定して、不正アクセスを検出。

公式の教材

Security Engineer Learning Path（Google Cloud Skills Boost）

GitHubで編集を提案

Discussion