過剰な権限がついているIAMを洗い出してみた【Security Command Center】

こんにちは、SCSKの齋藤です。

本記事では、IAMのセキュリティ分析情報を用いて、権限整理を行った事例について紹介します。

 

はじめに、なぜIAMの権限整理が必要なのか？

クラウドサービスの普及により、企業は以前にも増して迅速にアプリケーションを開発し、多様なサービスを展開できるようになりました。その一方で、クラウド環境におけるセキュリティの重要性も飛躍的に高まっています。特に、Google Cloud (GCP) におけるIdentity and Access Management (IAM) は、リソースへのアクセスを制御するまさに「要」となる機能であり、その適切な管理はセキュリティ確保の最優先事項と言えるでしょう。

しかし、実際の運用現場では、IAM権限の管理はしばしば複雑化し、気付かないうちに「過剰な権限」が付与されているケースが散見されます。なぜこのような状況が生まれるのでしょうか？ 緊急の対応で一時的に広い権限を付与したままにしてしまう、権限付与の基準が曖昧なままプロジェクトが進む、担当者の異動や役割変更に合わせて権限が見直されない、といった要因が挙げられます。

過剰なIAM権限がもたらすリスク

過剰なIAM権限は、想像以上に深刻なリスクをもたらします。

  1. セキュリティ侵害のリスク増大: 最も重大なリスクです。悪意のある攻撃者や、内部の不正行為者が、必要以上の権限を利用して機密情報にアクセスしたり、システム設定を改ざんしたりする可能性があります。例えば、本番データベースの削除権限を持つ開発者アカウントが乗っ取られた場合、サービス停止やデータ消失といった壊滅的な被害につながる恐れがあります。
  2. 誤操作による影響の拡大: 意図せずして、重要なリソースを削除したり、設定を変更したりする「ヒューマンエラー」のリスクが高まります。例えば、開発環境だと思って操作していたつもりが、本番環境のデータを誤って消去してしまった、といった事態は避けたいものです。最小権限の原則を守ることで、このような事故発生時の影響範囲を限定できます。
  3. コンプライアンス違反: GDPR、HIPAA、PCI DSS、日本の個人情報保護法など、多くの規制や業界標準では、データへのアクセス制御に関する厳格な要件が定められています。過剰な権限は、これらのコンプライアンス要件を満たさない状態を生み出し、監査での指摘や法的な問題に発展する可能性があります。
  4. 監査対応の複雑化と負担増: 誰が、いつ、どこに、どのようなアクセス権を持っているかを正確に把握できないと、監査対応時に膨大な時間と労力を要します。透明性の低い権限管理は、企業全体のガバナンス低下にも繋がります。

IAMの重要性 – クラウドセキュリティの要

クラウド環境におけるセキュリティは、「責任共有モデル」に基づいて構築されています。クラウドプロバイダ（Google Cloud）はインフラストラクチャやプラットフォームのセキュリティを担当しますが、ユーザーは自身のデータ、アプリケーション、そして「IAM設定」に関するセキュリティに責任を持ちます。IAMは、このユーザー側の責任範囲において、最も基本的ながら最も重要なセキュリティ制御点なのです。

ここで不可欠なのが「最小権限の原則 (Principle of Least Privilege)」です。これは、ユーザーやサービスがその職務を遂行するために必要な最小限の権限のみを付与すべきである、というセキュリティの基本原則です。この原則を徹底することで、万が一アカウントが侵害された場合でも、その被害を最小限に抑えることができます。

本記事で扱う課題と解決策の概要

本記事では、GCP環境における過剰なIAM権限という課題に対し、Security Command Center (SCC) の先進的なセキュリティ分析機能を活用した具体的な解決策を提示します。

SCCは、GCP環境全体にわたる脅威、脆弱性、設定ミスを検出・管理するための統合プラットフォームです。その中でも、特にPremiumプランで利用可能な「IAMセキュリティ分析（Policy Intelligence）」は、IAMポリシーの構成を詳細に分析し、過剰な権限や未使用の権限といった「洞察（Insights）」を提供してくれます。

 

Google CloudのIAMとその複雑性

Google Cloud IAMは、GCPリソースへのアクセスをきめ細かく制御するための強力なフレームワークです。しかし、その強力さゆえに、適切に理解し管理しなければ、あっという間に複雑化し、手に負えない状況に陥る可能性があります。

IAMの基本概念

GCP IAMは、「誰が」「何をできるか」「どのリソースに対して」という3つの主要な要素で構成されます。これらが組み合わさって「ポリシー」を形成します。

  • プリンシパル (Principal)：

    • 誰がアクセスを許可されるかを示すエンティティです。
    • 種類としては、Googleアカウント（個々のユーザー）、サービスアカウント（アプリケーションやVMインスタンス）、Googleグループ（複数のGoogleアカウントの集合）、G Suiteドメイン、またはCloud Identityドメイン全体があります。
    • 例: user:alice@example.com, serviceAccount:my-app@my-project.iam.gserviceaccount.com, group:devs@example.com

  • ロール (Role)：

    • 何をできるか、つまりプリンシパルに付与される権限の集合です。
    • ロールは、一つ以上の「権限 (Permission)」を含みます。権限は、特定のアクション（例: compute.instances.start、storage.objects.get）を実行する能力を定義します。
    • 例: roles/compute.viewer (VMインスタンスを見る権限), roles/storage.objectAdmin (Cloud Storageオブジェクトを管理する権限)

  • リソース (Resource)：

    • 権限が適用される対象となるGCPリソースです。
    • プロジェクト、フォルダ、組織といった階層的なリソースから、Compute EngineのVMインスタンス、Cloud Storageのバケット、BigQueryのデータセットといった具体的なサービスリソースまで多岐にわたります。
    • IAMポリシーは、このリソース階層のいずれかのレベルで設定されます。下位のリソースは上位のリソースからポリシーを継承します。

  • ポリシー (Policy)：

    • 上記3つの要素を組み合わせたものです。特定のプリンシパルに、特定のロールを、特定のリソースに対して付与します。
    • 技術的にはJSON形式で表現され、以下のような構造を持ちます。
    • {
  "bindings": [
    {
      "role": "roles/viewer",
      "members": [
        "user:alice@example.com",
        "serviceAccount:my-app@my-project.iam.gserviceaccount.com"
      ]
    },
    {
      "role": "roles/editor",
      "members": [
        "group:developers@example.com"
      ],
      "condition": {
        "title": "Access only from trusted IPs",
        "expression": "request.time < timestamp(\"2024-12-31T23:59:59Z\") && caller.ip == \"203.0.113.0/24\""
      }
    }
  ],
  "etag": "...",
  "version": 3
}
    • 上記の例では、roles/viewerがAliceとサービスアカウントに、roles/editorがdevelopersグループに付与されており、後者にはさらに条件が指定されています。

ロールの種類と役割

GCP IAMには、主に以下の2種類のロールがあります。

  • プリセットロール (Predefined Roles)：

    • Googleが事前に定義しているロールで、一般的なユースケースに合わせて最適化されています。例: roles/viewer (閲覧者), roles/editor (編集者), roles/owner (オーナー) などが存在します。
    • 利便性が高く、多くのシナリオで利用できますが、含まれる権限が多すぎることが過剰な権限付与の原因となることがあります。

  • カスタムロール (Custom Roles)：

    • ユーザーが特定の要件に合わせて、必要な権限のみを厳選して作成できるロールです。
    • 最小権限の原則を徹底するために非常に有効です。例えば、特定のAPIの読み取り権限と、特定のファイルへの書き込み権限だけを組み合わせたカスタムロールを作成できます。
    • 手間はかかりますが、セキュリティを強化し、誤操作のリスクを減らす上で推奨されるアプローチです。

 

Security Command Center (SCC) とは

Security Command Center (SCC) は、Google Cloud環境全体のセキュリティ状態を包括的に可視化し、リスクを特定・管理するための統合プラットフォームです。脆弱性、設定ミス、脅威、コンプライアンス違反など、多岐にわたるセキュリティ上の問題を発見し、優先順位を付けて対応を促すことで、組織のセキュリティ体制を強化します。

Security Command Centerの概要

SCCは、以下のような広範なセキュリティ情報を集約し、一元的に管理します。

  • アセットの可視化: GCP環境内のすべてのリソース（VM、ストレージバケット、データベース、ネットワーク設定など）を自動的に検出し、インベントリとして表示します。
  • 検出結果の管理: さまざまなセキュリティ検出サービス（VMの脆弱性スキャン、ストレージの設定ミス、ネットワーク設定の異常、悪意のあるアクティビティなど）からの検出結果を一箇所に集約し、分析・管理できます。
  • 脅威の特定: Cloud LoggingやCloud DNSなどから収集したログデータを分析し、マルウェア、不正アクセス、データ流出などの脅威を検出します。
  • コンプライアンス状況のモニタリング: CISベンチマークやPCI DSSなど、業界標準のセキュリティ要件に対する準拠状況を評価します。
  • IAMセキュリティ分析: 本記事の主題である、IAM権限に関する過剰な付与や未使用の権限などを検出します。

SCCは、これらの情報を使いやすいダッシュボードに統合し、セキュリティチームが効率的にリスクを把握し、対策を講じることを可能にします。

SCCのプランと機能

SCCには、大きく分けて「Standardプラン」と「Premiumプラン」の2つのサービスティアがあります。

  • Standardプラン:

    • 基本的なセキュリティ評価と脅威検出機能を提供します。
    • Cloud Security Health Analytics (設定ミス検出)、Cloud DLP (機密データ検出)、Web Security Scanner (Webアプリ脆弱性スキャン)、Security Health Analytics for Kubernetes (Kubernetesセキュリティ評価) など、一部のサービスが利用可能です。
    • 重要なのは、IAMセキュリティ分析機能はStandardプランでは利用できないという点です。

  • Premiumプラン:

    • Standardプランの全機能に加え、より高度なセキュリティ分析と脅威インテリジェンスを提供します。
    • IAMセキュリティ分析（Policy Intelligence）は、このPremiumプランでのみ利用可能です。
    • これ以外にも、脅威の優先順位付け、セキュリティ調査ワークベンチ、コンプライアンスダッシュボード、高度な侵入検知（Event Threat Detection）など、エンタープライズレベルのセキュリティ運用に不可欠な機能が多数含まれています。
    • 過剰なIAM権限を自動的に洗い出すためには、SCC Premiumプランの有効化が必須となります。

IAMセキュリティ分析（Policy Intelligence/Policy Insights）

SCC Premiumプランが提供するIAMセキュリティ分析は、Google Cloudの「Policy Intelligence」機能群の一部です。Policy Intelligenceは、IAMポリシーの構成を分析し、より安全で効率的なポリシー管理を支援するAIベースのツールセットです。主なコンポーネントは以下の通りです。

  1. Policy Analyzer (Policy Insights)：

    • 「誰が、どのリソースに対して、どのようなアクセス権を持っているか」を分析し、過剰な権限や未使用の権限などの「洞察（Insights）」を提供します。
    • 例えば、「このサービスアカウントは過去90日間、付与された権限の一部しか使用していない」といった情報や、「このユーザーは、必要以上の広範な管理者権限を持っている」といった具体的な推奨事項を提示します。
    • SCCは、このPolicy Analyzerが生成する「Policy Insights」を、検出結果としてダッシュボードに表示します。これが、本記事の主題である「過剰な権限の洗い出し」の核となります。

  2. Policy Simulator：

    • IAMポリシーを変更した場合に、その変更が既存のアクセスにどのような影響を与えるかをシミュレーションできます。
    • 実際にポリシーをデプロイする前に、意図しないアクセス拒否や、予期せぬアクセス許可が発生しないかを確認できるため、安心して変更作業を進めることができます。

  3. Policy Troubleshooter：

    • 特定のプリンシパルが特定のリソースにアクセスできない、またはアクセスできるべきではないのにアクセスできてしまう、といったトラブルシューティングを支援します。
    • 与えられたプリンシパル、リソース、権限に基づいて、アクセスが許可された理由、または拒否された理由を詳細に分析してくれます。

SCC Premiumプランでは、これらのPolicy Intelligence機能、特にPolicy Analyzerの洞察を「検出結果」として一元的に可視化し、セキュリティ運用のワークフローに統合します。これにより、これまで手動では困難だった、大規模な環境におけるIAM権限の健全性チェックと改善が、はるかに効率的に行えるようになります。

実践！SCCで過剰なIAM権限を洗い出す

それでは実際に、Security Command Center Premiumプランを使用して、GCP環境における過剰なIAM権限を洗い出す手順を見ていきましょう。

SCC Premiumプランの有効化と設定

過剰なIAM権限の分析には、まずSCC Premiumプランを有効化する必要があります。

  1. 組織レベルでの有効化:

    • SCCは組織レベルで有効化するのが一般的です。これにより、組織内のすべてのフォルダとプロジェクトがSCCの監視対象となります。
    • Google Cloud Consoleで、組織リソースを選択し、ナビゲーションメニューから「Security Command Center」を選択します。
    • 初回アクセスの場合、「概要」ページで「有効化」ボタンが表示されます。StandardプランかPremiumプランかを選択する画面が表示されたら、「Premium」を選択して有効化を進めます。
    • 有効化には、roles/securitycenter.admin などの適切なIAM権限が必要です。通常は組織の管理者アカウントで行います。
    • 有効化後、SCCが組織内のアセットをスキャンし、検出結果を収集するまでに時間がかかる場合があります（数時間から24時間程度）。

  2. 必要なIAM権限の確認:

    • SCCのダッシュボードを閲覧し、検出結果を管理するためには、適切なIAM権限が必要です。
    • 一般的に、以下のロールが付与されたユーザーアカウントまたはサービスアカウントが必要です。
      • roles/securitycenter.admin (管理者の場合)
      • roles/securitycenter.viewer (検出結果を閲覧するのみの場合)
      • roles/securitycenter.findingsEditor (検出結果のステータス変更などを行う場合)
    • IAMセキュリティ分析（Policy Intelligence）に関する洞察を表示するためには、これらのSCCロールに加え、関連するリソースのIAMポリシーを参照する権限も間接的に必要となりますが、SCC Premiumが有効であれば、通常は自動的に権限が補完されます。
    • ポリシーの分析情報を管理するために必要な権限を取得するには、分析情報を管理するプロジェクト、フォルダ、または組織に対して次の IAM ロールを付与する必要があります。
      • roles/recommender.iamViewer（ポリシーの分析情報を表示する場合）
      • roles/recommender.iamAdmin（ポリシーの分析情報を変更する場合）

有効化後の分析情報例

SCC Premiumプランを有効化し、しばらく時間が経つと、Policy Intelligence (Policy Analyzer) が収集したIAMに関する分析情報が「検出結果 (Findings)」タブに表示され始めます。これらの分析情報は「洞察 (Insights)」として提供され、過剰な権限や未使用の権限が具体的に指摘されます。

この画像は、あるプリンシパルに付与された「Storage オブジェクト管理者」ロールが過剰な権限を持っていることを示しています。

  • 概要: 上部に表示されるメッセージ「Storage オブジェクト管理者 ロールを Storage オブジェクト閲覧者 ロールに置き換えると、プリンシパルの権限数が 28 から 8 に減少します。分析は過去 90 日間を基にしています。」が、この洞察の要点をまとめています。

    • 特定のプリンシパルに付与された「Storage オブジェクト管理者」ロールが、実際の使用状況と比較して広範すぎることを指摘。
    • より制限された「Storage オブジェクト閲覧者」ロールへの置き換えを推奨。
    • その結果、付与される権限の総数が28から8に大幅に削減されることを明示。
    • この分析が、過去90日間の権限使用履歴に基づいて行われたことを示しています。

  • 現在の権限 (左側):

    • 「Storage オブジェクト管理者 ロールの現在の権限」として、このロールが持つ広範な権限がリストアップされています。
    • 例として、storage.objects.get（オブジェクトの取得）のような読み取り権限に加え、monitoring.timeSeries.create、orgpolicy.policy.get、resourcemanager.projects.get/list、さらにはstorage.folders.create/delete/renameなどのストレージの管理・削除に関する権限や、storage.managedFolders（マネージドフォルダ）に関する権限など、多岐にわたる権限が含まれていることが分かります。
    • これらのうち、storage.objects.get 以外は、過去90日間で実際に使用されていない「過剰な権限」として青字の「過剰な権限」ラベルとともに表示されています。

  • 置き換え推奨のロール (右側):

    • 「Storage オブジェクト閲覧者 のロールの置き換えを推奨」セクションでは、提案されるロール（この場合はStorage オブジェクト閲覧者）に含まれる権限と、現在のロールとの差分が表示されます。
    • 赤いハイライトで示されているのは、現在のロール（Storage オブジェクト管理者）には含まれるが、推奨されるロール（Storage オブジェクト閲覧者）には含まれない、つまり削除されるべき権限です。これにより、一目でどの権限が不要と判断されたかを確認できます。
    • ここでは、storage.objects.get のみが必要な権限として残り、その他の監視、組織ポリシー、リソースマネージャー、およびストレージ管理に関する多くの権限が削除対象となっていることが明確に示されています。

この具体的な洞察は、権限整理の具体的なアクションに直結します。この情報に基づいて、対象のプリンシパルからStorage オブジェクト管理者ロールを削除し、代わりにStorage オブジェクト閲覧者ロール、またはより細かく制御されたカスタムロールを付与することで、最小権限の原則を適用し、セキュリティリスクを大幅に低減することができます。

まとめ

本記事では、GCP環境における過剰なIAM権限の危険性とその解決策として、Security Command Center Premiumの強力なIAMセキュリティ分析機能（Policy Intelligence）を解説しました。

IAMはクラウドセキュリティの基盤であり、その適切な管理は組織のデータとシステムを保護する上で不可欠です。SCC Premiumを導入し、本記事で紹介した手順とベストプラクティスを実践することで、これまで見過ごされがちだったIAMの「死角」を解消し、より堅牢で効率的なGCP運用を実現できるはずです。

本記事がGCP環境のセキュリティ強化の一助となれば幸いです。

参考

タイトルとURLをコピーしました