現代の企業環境は、数多くの SaaS アプリケーションと複雑なクラウドインフラで構成されており、それぞれが独自の権限モデル、ロール階層、アクセス制御ロジックを持っています。セキュリティチームは、そのすべてを横断してインシデントを調査し、アラートをトリアージし、リスクを評価することが求められます。ところが、多くのチームは、アイデンティティセキュリティにおける最も基本的な問い、すなわち「このユーザーは実際に何ができるのか」に明確に答えられません。この問いに答えられなければ、影響範囲の見積もりは推測に頼ることになり、アクセスレビューは不完全になり、アラートのトリアージも事実ではなく勘に左右されます。本ブログでは、有効権限とは何か、なぜ SaaS 環境と IaaS 環境の両方で実務上その解決が難しいのか、そしてこれを正しく把握することが SOC チームにとって運用面で非常に大きな効果をもたらす理由を解説します。
有効権限とは何か
有効権限とは、すべての許可、拒否、継承経路、ポリシー制約を評価したうえで、あるアイデンティティが実際に実行できるアクションの正味の集合を指します。
一部の SaaS 環境では、権限モデルがシンプルでロールベースであるため、この評価は比較的容易です。多くの SaaS ツールには、チームが利用できる定義済みのロールや権限が用意されており、さらに、ユースケースに合わせて権限を組み替えたカスタムロールを作成し、ユーザーへの過剰な権限付与を防げる場合もあります。たとえば GitHub や Slack には、少数の定義済みロールがあり、カスタム権限も利用できます。これらは多層的な権限モデルとみなすことができます。たとえば GitHub では、複数のロールを持つユーザーにはそれらを合算した権限が付与されますが、組織ポリシーやブランチ保護ポリシーによってその権限が上書きされることがあります。たとえば、リポジトリ管理者権限を持つユーザーが強制プッシュできるように見えても、ブランチ保護ルールによってそれが禁止される場合があります。
一方、IaaS 環境では、状況ははるかに複雑になります。
AWS を例に取ると、ユーザーは多くの場合 SSO 経由でアクセスし、アカウント固有のポリシーを通じて権限を取得します。これらのポリシーはロールに関連付けられ、ユーザーはロールを引き受けてアクションを実行します。Permission Set はアカウント横断でポリシーを管理します。ポリシーはユーザーに直接付与される場合もあれば、グループを通じて継承される場合もあります。同時に、リソースポリシーは、誰がリソースにアクセスできるか、どのアクションが許可されるかを独立して定義します。さらにその上に、Service Control Policy（SCP）が組織レベルの制約を課します。AWS 自身も、この多層的な権限モデルを文書化しており、アクセスが許可または拒否される複数のレイヤーが存在することを示しています。
その結果、重複する許可、明示的な拒否、継承されたアクセス経路、再帰的なロールチェーンを含む、密で不透明になりがちな権限グラフが生まれます。すべての条件を正しく考慮し、適切な評価手法を構築するには、高度な専門知識が必要です。たとえば AWS では、ポリシー内の deny ステートメントは、あらゆる allow ステートメントや許可を上書きします。この知識はポリシー評価に不可欠ですが、すべてのシステムで同じとは限りません。同様に、複雑な環境では、複数のポリシーが同じアクセスを許可し、別のポリシーがそれを制限し、さらに別のリソースポリシーがその範囲をいっそう絞り込むことがよくあります。権限を正確に評価するには、ポリシーの種類、ポリシーステートメント、その評価順序を理解することが不可欠です。
以下のロールを見てみましょう。AWS コンソール上では、Amazon SimpleDB に広範なアクセス権を持っているように見えます。しかし、組織の SCP が SimpleDB のアクションを明示的に拒否しています。SCP は他のポリシーで付与された権限より優先されるため、このロールには実際には SimpleDB へのアクセス権がありません。
この情報の一部を限定的に可視化するクラウドプロバイダーもありますが、解決済みの最終結果までは示してくれません。AWS Access Analyzer では、ユーザーがアクセスできる対象を照会できますが、リソースごとに月額 9 ドルという非常に高額な料金がかかります。数千から数百万のリソースを持つ一般的な環境では、現実的ではありません。しかも、この機能は deny ポリシーを考慮しないため、有効権限の出力は不完全です。GCP にも同様の機能がありますが、権限分析の一環として SCP は考慮されません。Azure にはこれに相当する機能がなく、ユーザーにサードパーティツールの利用を促しています。その結果、アナリストは、この評価を手作業で行うか、あるいはまったく行わないかという難しい状況に置かれます。
ユーザーが実際に何を実行できるのか、つまりどのアクションをどのリソースに対して実行できるのかを判断するには、アナリストはアイデンティティベース、グループベース、リソースベース、ロールベースのあらゆるポリシーを評価し、明示的な拒否をすべて解決し、SCP の制約を組み込み、アカウント間のロールチェーンも考慮しなければなりません。
この評価の最終結果は、以下のグラフのようになります。このグラフは、このユーザーが各サービスへのアクセス権をどのように取得しているかを示しています。Runtime トグルを使うと、そのアイデンティティが実際に使用しているロールやサービスを簡単に確認できます。
このアイデンティティの権限をさらに分析すると、どのアカウントのどのロールにアクセスできるのかを再帰的に把握できるだけでなく、各サービスにどの権限が存在し、どれが実際に使われているのか、さらに各サービス内でどのリソースにどの程度アクセスできるのかを詳細に確認できます。
誰が実際に何をできるかが分かったとして、それが SOC にどう役立つのか？
有効権限を理解することで、SOC チームは運用上の大きなメリットを得られます。
簡素化
多くの組織では、管理者ユーザーの監査に関するコンプライアンス要件があります。では、誰が「管理者」に該当するのでしょうか。
複雑な環境では、「管理者」は肩書きではなく、権限の結果として定義されるものです。ツールによっては管理者を明示的に定義しているものもありますが、そもそもその概念が存在しないものもあります。たとえば AWS には管理者の標準的な定義はありませんが、GCP や多くの SaaS ツールでは、特定のロールや権限に Admin のラベルが付いています。Exaforce は、監査、衛生管理、コンプライアンスのユースケースを標準化するため、アプリ側に定義がない場合はシンプルな管理者定義を作成します。その場合の管理者とは、自分自身または他者のアクセス権を増やせる権限を持つすべてのアイデンティティを指します。
エクサフォースは有効権限の分析を通じてこれを計算し、該当するすべてのアイデンティティに管理者タグを付与できます。これにより、エクサフォース製品全体でこれらのアイデンティティを簡単に検索・フィルタリングできます。
同様に、「データアクセスあり」「サードパーティ」「クロスアカウントアクセスあり」などについても簡素化された属性を提供しています。
こうした簡素化は、製品全体の表示上の補助やフィルターにとどまりません。検索でも利用できるため、複雑なロジックをシンプルなクエリに落とし込めます。以下は、環境内の一部の管理者アイデンティティを表示した例です。
簡素化は、アイデンティティへのタグ付けだけでなく、有効権限へのアクセス方法にも及びます。エクサフォースでは、すぐに使えるダッシュボードやタグに加え、自然言語にも対応したクエリインターフェースを提供しており、通常なら非常に複雑になるアクセスに関する問いを、ユーザーが直接投げかけられます。
有効権限を計算することで、複雑な構成をシンプルなフィルターに変換し、プロセスと認識を標準化できます。これにより、監査はより明確になり、アクセスレビューの一貫性は高まり、調査も迅速になります。定義の解釈を議論するのではなく、計算された権限に基づいて運用できるようになります。
是正対応
エクサフォースを含む多くの IAM ツールやリスク管理ツールは、多数の権限や未使用の権限を持つ「高リスクユーザー」にフラグを付けます。しかし、その権限が本当に過剰なのかを判断するには、文脈が必要です。
これらの権限は実際に使われているのか。
このユーザーの行動は同僚と比べてどうか。
そのアクティビティは、その人の役割に見合っているか。
有効権限を利用状況分析と組み合わせることで、静的なアクセスレビューから、行動を踏まえた権限管理へと移行できます。似た行動を取るユーザーを特定し、適切にクラスタリングできます。チーム内の他のメンバーと異なる振る舞いをする外れ値も検出できます。また、より広範な運用パターンを正当に示す SRE のようなロールの典型像も把握できます。
そして最も重要なのは、何を変更すべきかを判断できることです。
AWS のような多層的なシステムでは、「このユーザーには未使用の権限があります」と伝えるだけでは、具体的な対応につながりません。有効権限分析を行えば、どのポリシーがリスクの原因なのかを特定し、その問題がロール、グループ、Permission Set のどこにあるのかを判断し、どのオブジェクトを修正すべきかを正確に示せます。さらに、Okta グループのような外部ツールでロールが管理されている場合は、こうしたシステムは一段と複雑になります。
以下は、この AWS ユーザーに対してアクセスレビュー監査を実施した例です。権限がどのように付与されたのか、どれが実際に使われているのかをシステムが確認し、それに基づいて推奨を行っていることが分かります。この推奨は、グループ経由で付与された権限とは別に直接割り当てられていたロールに対するものです。Remediations タブでは、ポリシー、Permission Set、グループなどの編集方法、あるいはこのケースのように、そのアイデンティティから直接割り当てられたロールを削除する方法を手順付きで確認できます。
定義済みロールを持つ SaaS プラットフォームでは、これはさらに実用的です。利用パターンとロール比較分析に基づき、推測に頼ることなく最適なロールを推奨し、過剰な権限付与を削減できます。
この GitHub ユーザーと、そのリポジトリ（repo）におけるロールと権限を見てみましょう。このアイデンティティがアクセスできるリポジトリの一覧、割り当てられたロールの概要、そして利用状況に基づく最適なロールを確認できます。さらに下には、最適ロールがどのように計算されたのか、そのロール内のどのアクションが使われ、どれが使われていないのかの詳細分析が表示されます。最適ロールは、使用済み権限を 100% 含みつつ、未使用権限が最も少ないロールとして算出されます。この例では、GitHub は各リポジトリに対して write、admin、maintain、read、triage の 5 つの標準ロールを提供しており、それぞれに固定のアクション権限セットがあります。環境によってはカスタムロールも利用可能であり、その場合は同様に最適ロールとして評価できます。
影響
SOC の観点で、調査時に最も重要な問いの一つは次のとおりです。
このアイデンティティが侵害された場合、被害はどこまで拡大し得るのか。その問いに答えるのが、有効権限です。
あるアイデンティティに何ができるかを把握することで、影響範囲を見積もり、アクセス・変更・削除可能な機密リソースを特定し、潜在的なラテラルムーブメントの経路を洗い出し、アカウント間やシステム間にまたがる影響を評価できます。
すべてのアラートが同じ重みを持つわけではありません。読み取り専用ユーザーによる不審なログインと、IAM ポリシーの変更、本番データベースへのアクセス、ログの無効化、あるいは他の高権限ロールの引き受けまで可能なアイデンティティによる不審なログインとでは、意味合いが根本的に異なります。複数ソースにまたがる権限も同様に考慮できます。たとえば、アクティブなリポジトリを持つ GitHub で管理者権限を持ち、さらに AWS でも高い権限を持つユーザーは、侵害時の複合的な影響を考えると、はるかに高リスクです。エクサフォースはソースごと・アイデンティティごとに権限を評価するだけでなく、アイデンティティ解決によって各ユーザーを統合的に可視化します。Bob がアプリごとに異なるユーザー名を使っていたとしても、Exaforce ならアプリ横断で Bob のアクセス権を統合的に把握し、各ソースを詳細に掘り下げられます。このクロスソースの可視性と結び付けによって、リスクの非常に包括的な全体像が得られ、脅威の優先順位付けに活用できます。
一方で、ユーザーが自分自身に追加ポリシーを付与し、その結果として追加権限を持つロールへのアクセスを得たとします。表面的には非常に疑わしい挙動です。しかし詳しく見ると、そのロール自体の権限範囲は、特定の管理アクションに限定されたごく狭いものかもしれません。その場合、このアクションは中程度の重要度として文脈化でき、単純な検知だけでは分からない実態を補足できます。
以下の例では、あるユーザーが別のユーザーを作成し、広範な S3 権限と長期アクセスキー、具体的にはすべての S3 リソースへの無制限アクセスを許可する AWS 管理ポリシー AmazonS3FullAccess を付与しています。GuardDuty はアラートを発報しませんでしたが、エクサフォースは付与された権限の大きさを踏まえてこのアクティビティを高リスクと判断し、この検出結果を生成しました。
権限分析は、アイデンティティ関連のアラートを単なるシグナルから、リスク加重されたインシデントへと変えます。SOC チームにとっては、トリアージの迅速化、重要度評価の精度向上、エスカレーション判断の改善、アラート疲れの軽減につながります。
権限の可視化を、運用の明確さへ
SOC チームにとって、組織内のユーザーやアイデンティティの有効権限を評価できないことは深刻な制約です。それにより、実施できる分析の有効性は大きく損なわれ、起こり得る影響の認識も歪められます。しかも、現代の企業環境では対象アプリケーション数が多く、SOC が監視する環境も複雑であるため、この情報を手作業で組み立てるのは現実的でないほど時間がかかります。
有効権限と、それが SecOps に与える影響についてさらに詳しく知りたい方は、録画済みウェビナーをご視聴ください。
