はじめのProfessional Security Operations Engineer 認定取得講座③データRBACの概要、Cloud Identity を使用したユーザーマッピングと認証、サードパーティ ID プロバイダ（Okta/Azure AD等）との連携設定を説明します！

クラウド

今回は、Google SecOpsのデータRBAC（Data RBAC）と認証・認可の仕組みについて解説します。

Google SecOpsでは、ユーザーが利用できる機能だけでなく、閲覧・操作できるログデータまで細かく制御できる仕組みが提供されています。また、Cloud IdentityやGoogle Workspace、さらにOktaやMicrosoft Entra ID（旧Azure AD）などのサードパーティIDプロバイダと連携することで、組織全体の認証・アクセス管理を安全かつ効率的に実現できます。

本記事では、データRBACの基本的な仕組み、Cloud Identityを利用したユーザーマッピング、そしてWorkforce Identity連携によるサードパーティIDプロバイダとのSSO構成について解説します。これらはGoogle SecOpsを安全に運用するための重要な知識であり、Professional Security Operations Engineer認定試験でも押さえておきたいポイントです。

是非、最後までご覧いただけると嬉しいです。

データRBACの概要

Google Security Operations (Google SecOps) では、プラットフォームの機能へのアクセスを制御する「機能RBAC」とは別に、特定のデータそのものへのアクセスを制限する「データRBAC（ロールベースのアクセス制御）」を提供しています。これにより、組織内のユーザーの職務に応じて、閲覧または操作できるログデータを詳細に制限することが可能になります。

データRBACと機能RBACの違い

包括的なアクセス制御を実現するために、Google SecOps では性質の異なる2つのRBACを組み合わせて使用します。

  • 機能RBAC (Feature RBAC)：ユーザーが「どの機能（例：ダッシュボードの作成、ルールの編集）」を使用できるかを制御します。
  • データRBAC (Data RBAC)：ユーザーが「どのデータ（例：特定のネットワークのログ、機密性の高い財務データ）」を表示・編集できるかを制御します。

例えば、「ジュニアアナリストはダッシュボードを表示できる（機能権限）」が、「表示されるデータは自分の担当部署のログのみに限定される（データ権限）」といった運用が可能になります。

スコープとラベルによる詳細な制御

データRBACの中核となる概念は「スコープ」と「ラベル」です。

  1. ラベル (Labels)：取り込まれたデータに付与されるメタデータです。ログタイプ（必須）や名前空間（任意）などのデフォルトラベルに加え、特定のIPアドレスやイベントタイプに基づくカスタムラベルを作成することもできます。
  2. スコープ (Scopes)：1つ以上のラベルを組み合わせて定義される「データの境界」です。
    • 許可ラベル：そのラベルに関連付けられたデータへのアクセスを許可します。
    • 拒否ラベル：そのラベルに関連付けられたデータへのアクセスを拒否します。拒否ラベルは許可ラベルよりも優先されます。

ユーザーロールの種類

ユーザーには、その職務に応じて以下のいずれかのデータアクセス権が割り当てられます。

  • グローバルユーザー：インスタンス内のすべてのデータに無制限にアクセスできます。
  • スコープ設定されたユーザー：割り当てられた特定のスコープに基づいて、表示や操作できるデータが制限されます。

ユーザーを特定のスコープに制限するには、Google Cloud IAMで対象のユーザーに roles/chronicle.restrictedDataAccess ロールを割り当て、IAM条件を使用して特定のスコープ名を紐付けます。

各機能への影響

データRBACが有効になると、プラットフォームの各機能で表示される結果が自動的にフィルタリングされます。

  • 検索：ユーザーのスコープに一致するデータのみが検索結果に表示されます。
  • ルールと検出：ユーザーは自分がアクセス権を持つスコープに関連付けられたルールのみを表示・管理でき、そこから発生した検出（アラート）のみを確認できます。
  • ダッシュボード：グラフやウィジェットには、ユーザーのスコープに一致するデータのみが集計・表示されます。
  • 未加工ログ：解析前の生ログへのアクセスは、原則としてグローバルスコープを持つユーザーのみに制限されます。

注意点：現在、データRBACは主にSIEM側の機能に適用されます。SOAR側（ケース管理など）ではデータが表示される可能性があるため、別途適切なアクセス制御を確立することが重要です。

データRBACの概要のまとめ

Google SecOpsのデータRBACは、ユーザーごとにアクセス可能なログデータを細かく制御し、最小権限の原則に基づいたセキュリティ運用を実現する重要な機能です。
機能RBACと組み合わせることで、「利用できる機能」と「閲覧・操作できるデータ」の両方を柔軟に管理できます。
また、スコープやラベルを活用することで、組織や部門ごとのアクセス制御を効率的に実装でき、機密データの保護やコンプライアンスの強化にも役立ちます。
Google SecOpsを安全に運用するためには、データRBACの仕組みを理解し、適切なアクセス権限を設計・運用することが重要です。

Cloud Identity を使用したユーザーマッピングと認証

Google Security Operationsでは、Cloud Identity または Google Workspace を ID プロバイダ (IdP) として使用して、ユーザーの管理、認証、およびプラットフォーム内での権限マッピングを行うことができます。これにより、組織は既存の Google アカウントの仕組みを活用して、セキュリティ運用に必要なアクセス制御を統合的に構築できます。

Cloud Identity による認証の仕組み

Cloud Identity を使用する場合、管理対象ユーザーアカウントを作成して、Google Cloud リソースおよび Google SecOps インスタンスへのアクセスを制御します。

  1. IAM ポリシーの作成：Google SecOps の機能へのアクセス権を付与するユーザーやグループを定義する Identity and Access Management (IAM) ポリシーを作成します。これには、Google SecOps が提供する事前定義ロールやカスタムロールを使用します。
  2. ログイン権限の付与：ユーザーが Google SecOps にログインできるようにするには、対象のユーザーまたはグループに Chronicle API 閲覧者 (roles/chronicle.viewer) ロールを付与する必要があります。
  3. 直接統合：Google SecOps インスタンスは Cloud Identity と直接統合されており、構成された IAM ポリシーに基づいて認証とアクセス制御が適用されます。

SOAR 機能のためのユーザーマッピング

Google SecOps の SOAR 側 の機能 (ケース管理など) にアクセスするには、IAM ロールとは別に、プラットフォームの設定で「グループマッピング」を行う必要があります。これは、ユーザーがログインした際に、どの SOC ロール や 環境 にアクセスできるかを決定するためです。

マッピングの手順

  1. [設定] > [SOAR 設定] > [詳細設定] > [グループ マッピング] に移動します。
  2. メールグループの定義：「グループ名」 (例: Tier 1 Analysts) と、そのグループに属する「メンバーのメールアドレス」のリストを用意します。
  3. パラメータの割り当て：各グループを、以下のアクセス制御パラメータに紐付けます。
    • 権限グループ：表示・編集できるモジュールを制限します。
    • SOC ロール：ユーザーの役割 (Tier 1、管理者など) を定義し、タスク管理を効率化します。
    • 環境/環境グループ：アクセスできるデータ範囲 (特定の顧客やネットワーク) をセグメント化します。

ユースケース：職務に応じた詳細なプロビジョニング

Cloud Identity を活用することで、各メールグループに固有の権限を割り当て、組織のニーズに合わせた運用が可能です。

  • 例：「セキュリティ アナリスト」グループにはロンドン環境の Tier 1 ロールを割り当て、「SOC エンジニア」グループにはマンチェスター環境の Tier 1 ロールを割り当てるといった、場所や職務に基づいた柔軟な構成が可能です。
  • 一括マッピング：管理者はメールアドレスを使用して新しいユーザーをグループに追加することで、ユーザーをプラットフォームへ一括でプロビジョニングおよびマッピングできます。

運用のベストプラクティス

  • デフォルトのアクセス設定：初期のセットアップ中や、マッピングされていないユーザーの拒否を防ぐために「デフォルトのアクセス設定」を有効にできますが、設定完了後は 最小権限の原則 に基づき、権限を調整することが推奨されます。
  • API アクセスの自動化：サービスアカウントや Workload Identity 連携をマッピングすることで、自動化タスクや API 操作に必要な SOC ロールと環境へのアクセス権を安全に付与できます。
  • 一貫した ID 管理：プロジェクトの請求先アカウントがサブスクリプションの注文と一致していることを確認してください。これが一致しないと、認証や課金クレジットの適用に問題が生じる可能性があります。

Cloud Identity を使用したユーザーマッピングは、使い慣れた Google の管理コンソールと Google SecOps の詳細なアクセス制御を組み合わせることで、エンタープライズレベルの安全なセキュリティ運用基盤を実現します。

Cloud Identity を使用したユーザーマッピングと認証のまとめ

Cloud IdentityとGoogle SecOpsを連携することで、認証・認可を一元管理し、安全かつ効率的なセキュリティ運用を実現できます。
IAMロールによる機能アクセス制御に加え、SOARのグループマッピングを活用することで、ユーザーの役割や担当環境に応じた柔軟な権限管理が可能になります。
また、最小権限の原則に基づいたアクセス設計や、サービスアカウントを活用した安全な自動化を実践することで、運用効率とセキュリティを両立できます。
Google SecOpsを効果的に運用するためには、Cloud Identityを活用した適切なユーザー管理とアクセス制御の仕組みを理解しておくことが重要です。

サードパーティ ID プロバイダ（Okta/Azure AD等）との連携設定

Google Security Operationsでは、Google Cloud Workforce Identity 連携を活用することで、Okta、Microsoft Entra ID (旧 Azure AD)、Microsoft AD FS などのサードパーティ ID プロバイダ (IdP) を使用して、ユーザーやグループの認証を行うことが可能です。

これにより、組織の既存の認証基盤を維持したまま、Google SecOps への安全なアクセスと、Google Cloud IAM を介した高度なアクセス制御（機能 RBAC）を実現できます。

連携のメリットとユースケース

サードパーティ IdP との連携は、特に以下の要件を持つ組織に有効です。

  • 厳格なセキュリティ基準への準拠：SSO を安全に仲介することで、FedRAMP High などの高いコンプライアンス基準を満たすことができます。
  • エンタープライズ・アクセス制御の一元化：組織全体で一貫した ID 管理を行い、IAM を使用して Google SecOps 内の機能やデータへのアクセスを統合管理できます。
  • API アクセスの自動化：手動の管理オーバーヘッドを削減し、プログラムによる安全な認証情報管理が可能になります。

連携設定の主要なステップ

SAML ベースの IdP を使用した認証設定は、大きく分けて以下の 4 つのフェーズで進めます。

1. リソースの計画

まず、認証の仲介役となる Google Cloud 上のリソースを定義します。

  • Workforce プール：組織レベルで定義される、Google SecOps へのアクセスを許可する ID の集合体です。
  • Workforce プロバイダ：IdP の詳細設定（SAML 属性やメタデータ）を保持するプールのサブリソースです。

2. サードパーティ IdP 側の構成

IdP 側（Okta や Entra ID など）で、Google SecOps と統合するための SAML アプリケーションを作成します。

  • 必須属性の設定：first_name、last_name、user_email、groups などの属性を Google Cloud に渡すようにマッピングします。
  • URL の設定：Google Cloud 側で生成される Assertion Consumer Service (ACS) URL とエンティティ ID を IdP に登録します。

3. Google Cloud Workforce Identity 連携の構成

Google Cloud コンソールまたは gcloud CLI を使用して、プールとプロバイダを作成します。

  • メタデータのアップロード： IdP からダウンロードした XML メタデータファイルを Google Cloud に読み込ませます。
  • IAM ロールの付与：IdP のグループ（例：secops_admins）に対し、Google SecOps へのログイン権限（roles/chronicle.viewer など）を付与します。

4. Google SecOps インスタンスへの SSO 構成

最後に、Google SecOps の管理画面（または Google Cloud コンソール）で、作成したプロバイダを SSO オプションとして選択し、有効化します。

運用の注意点

  • ログイン方法：Google SecOps はサービスプロバイダ起点 (SP-initiated) の SSO をサポートしています。ユーザーは Google SecOps の URL に直接アクセスし、そこからサードパーティ IdP へリダイレクトされて認証を行います。※ IdP のダッシュボードからログインを開始する「IdP 起点」のログインは原則サポートされていません。
  • グループ名の整合性：Google SecOps の設定画面（グループマッピングなど）に入力するグループ名は、IdP 側から送られてくるグループ名と完全に一致している必要があります。
  • SOAR へのアクセス：SSO 設定後、SOAR 側の機能（ケース管理など）にアクセスするには、別途「グループマッピング」ページで IdP グループを SOC ロールや環境に紐付ける必要があります。

サードパーティ IdP との連携を適切に構成することで、ユーザーの利便性を損なうことなく、強固なガバナンスに基づいたセキュリティ運用を実現できます。

サードパーティ ID プロバイダ（Okta/Azure AD等）との連携設定のまとめ

Cloud IdentityとGoogle SecOpsを連携することで、認証・認可を一元管理し、安全かつ効率的なセキュリティ運用を実現できます。
IAMロールによる機能アクセス制御に加え、SOARのグループマッピングを活用することで、ユーザーの役割や担当環境に応じた柔軟な権限管理が可能になります。
また、最小権限の原則に基づいたアクセス設計や、サービスアカウントを活用した安全な自動化を実践することで、運用効率とセキュリティを両立できます。
Google SecOpsを効果的に運用するためには、Cloud Identityを活用した適切なユーザー管理とアクセス制御の仕組みを理解しておくことが重要です。

まとめ

今回は、下記３点について説明しました。

  1. データRBACの概要
  2. Cloud Identity を使用したユーザーマッピングと認証
  3. サードパーティ ID プロバイダ（Okta/Azure AD等）との連携設定

Google SecOpsでは、データRBACによってアクセス可能なログデータを細かく制御し、機能RBACと組み合わせることで最小権限の原則に基づいたセキュリティ運用を実現できます。

また、Cloud IdentityやGoogle Workspace、さらにOktaやMicrosoft Entra IDなどのサードパーティIDプロバイダと連携することで、認証・認可を一元管理し、エンタープライズレベルのアクセス制御を構築できます。

これらの仕組みを正しく理解することは、Google SecOpsの安全な運用だけでなく、Professional Security Operations Engineer認定試験で問われるIAM、RBAC、SSO、ユーザープロビジョニングの理解にも直結します。実務でも頻繁に利用される重要な機能であるため、それぞれの役割や設定方法をしっかり押さえておきましょう。

これからも、Macのシステムエンジニアとして、日々、習得した知識や経験を発信していきますので、是非、ブックマーク登録してくれると嬉しいです！

それでは、次回のブログで！

スポンサーリンク
タイトルとURLをコピーしました