現代の企業環境は、数十のSaaSアプリケーションと複雑なクラウドインフラストラクチャにまたがっており、それぞれに独自の権限モデル、役割階層、アクセス制御ロジックがあります。セキュリティチームには、インシデントの調査、アラートの優先順位付け、リスクの評価がすべて求められます。しかし、ほとんどのユーザーは、ID セキュリティにおける最も基本的な質問、つまり「このユーザーが実際にできること」に対する明確な答えを欠いています。その答えがなければ、 ブラスト半径 見積もりは当て推量で、アクセスレビューは不完全で、アラートのトリアージは事実ではなく直感に左右されます。このブログでは、効果的な権限とは何か、SaaS 環境と IaaS 環境の両方で実際に解決するのが非常に難しい理由、そしてこれを正しく行うことが SOC チームが行うことのできる運用上最も影響の大きい投資の 1 つである理由について説明します。
有効な権限とは
有効な権限とは、すべての付与、拒否、継承経路、およびポリシー制約を評価した後に ID が実行できる実際のアクションセットです。
一部のSaaS環境では、権限モデルが単純で役割ベースであるため、この評価は比較的簡単です。ほとんどの SaaS ツールには、チームが活用できる定義済みのロールとパーミッションが付属しているほか、カスタムロールを作成して、それぞれのユースケースにより適したパーミッションを再組み合わせて、ユーザーに過剰な権限が付与されないようにすることもできます。たとえば、 GitHub そして スラック 定義済みのロールの短いリストがありますが、カスタム権限も許可されています。これらは階層化された権限と見なされ、たとえば GitHub では、複数のロールを持つユーザがまとめて権限を取得しますが、組織や支店の保護ポリシーによって無効になることがあります。たとえば、リポジトリ管理者権限を持つユーザは強制的にプッシュできるように見えても、ブランチ保護ルールではそれを防ぐことができます。
しかし、IaaS 環境では、状況ははるかに複雑になります。
AWSを例にとってみましょう。ユーザー (SSO 経由でアクセスすることが多い) には、アカウント固有のポリシーを通じてアクセス権限が付与されます。これらのポリシーには役割が割り当てられ、ユーザーは役割を引き受けてアクションを実行します。権限セットはアカウント全体のポリシーを管理します。ポリシーは、ユーザーに直接付与することも、グループを通じて継承することもできます。同時に、リソースポリシーは、誰がリソースにアクセスできるか、どのようなアクションを許可するかを個別に定義します。さらに、サービスコントロールポリシー (SCP) は組織レベルの制約を課します。AWS 自体がこの階層化された権限モデルを文書化しており、アクセスを許可または拒否できる複数のレベルが浮き彫りになっています。
その結果、重複する許可、明示的な拒否、継承されたアクセスパス、および再帰的なロールチェインを含む、密で不透明な場合が多い権限グラフが生成されます。すべての条件を適切に検討し、評価方法論を開発するには、深い専門知識が必要です。たとえば AWS では、ポリシー内の deny ステートメントが allow ステートメントや allow アクセス権限よりも優先されます。この知識はポリシーの評価に不可欠であり、すべてのシステムに当てはまるわけではありません。同様に、複雑な環境では、複数のポリシーが同じアクセスを許可し、別のポリシーがアクセスを制限し、さらに別のリソースポリシーがアクセスをさらに絞り込んでいることがよくあります。権限を正確に評価するには、ポリシーの種類、ポリシーステートメント、およびそれらの評価順序を理解することが不可欠です。
以下に示す役割を考えてみましょう。AWS コンソールでは、Amazon SimpleDB に幅広くアクセスできるようです。ただし、組織の SCP は SimpleDB アクションを明示的に拒否しています。SCP は他のポリシーに付与された権限よりも優先されます。その結果、ロールには実際に SimpleDB へのアクセス権がありません。
一部のクラウドプロバイダーは、この情報を限定的に公開していますが、解決された結果は公開していません。AWS Access Analyzer では、ユーザーがアクセスできる情報をリクエストできますが、法外な料金がかかります。 リソースあたり月額 9 USD!数千または数百万のリソースがある平均的な環境では、これは法外です。その上、このサービスでは拒否ポリシーが考慮されていないため、有効な権限の出力が不完全です。 GCP にも同様の機能がありますが、権限の一部として SCP は無視されます。 分析。アズール 何も提供せず、サードパーティ製のツールを購入してこの情報を推測することをユーザーに提案している。これらすべてにより、アナリストはこの評価を手動で行うか、まったく行わないかのどちらかという難しい立場に置かれます。
ユーザーが実際に実行できること（実行できるアクションとリソース）を判断するには、アナリストはアイデンティティベース、グループベース、リソースベース、ロールベースのすべてのポリシーを評価し、明示的な拒否をすべて解決し、SCPの制約を組み込み、アカウント間のロールチェーンを考慮する必要があります。
この評価の最終結果は、以下のグラフのようになります。このグラフは、このユーザーがこれらの各サービスにアクセスできるようになるまでのプロセスを示しています。ランタイムトグルには、ID が実際に使用しているロールとサービスが簡単に表示されます。
この ID の権限をさらに分析すると、ID がどのアカウントでどのロールにアクセスできるか、再帰的にも、各サービスでどの権限が存在して使用されているか、各サービス内でどのリソースにどの程度アクセスできるかを詳細に把握できます。
だから誰が実際に何ができるかわかる。それがSOCでどのように役立つのか？
効果的な権限を理解することで、SOC チームにとって運用上のメリットがもたらされます。
簡略化
ほとんどの組織では、管理ユーザーの監査に関するコンプライアンス要件があります。しかし、いったい誰が「管理者」の資格を持つのでしょうか？
複雑な環境では、「admin」はタイトルではなく、権限の効果的な結果です。一部のツールはユーザーに代わって管理者を定義します。この概念を完全に省略しているものもあります。たとえば、AWS には管理者の正式な定義はありませんが、GCP や多くの SaaS ツールでは特定のロールと権限に Admin というタグが付けられています。監査、衛生、コンプライアンスのユースケースを標準化するために、Exaforce は管理者の簡単な定義を作成しますが、アプリでは定義していません。このようなアプリの場合、管理者とは、自分自身や他のユーザーのアクセスを増やす権限を持つすべてのアイデンティティを指します。
有効権限の分析により、これを計算し、この管理者タグを該当するすべてのIDに適用できるようになりました。これにより、Exaforce製品全体でそれらを簡単に検索またはフィルタリングできます。
「データアクセスがある」、「サードパーティである」、「クロスアカウントアクセスがある」などについても同様の簡略化が行われます。
これらの簡略化は、製品全体の装飾やフィルターとして表示されるだけでなく、複雑なロジックを単純なクエリにまとめるための検索にも使用できます。以下は、環境内の管理者 ID の一部を示しています。
簡略化には、ID のタグ付けだけでなく、有効な権限へのアクセス方法も含まれます。Exaforce では、すぐに使用できるダッシュボードとタグに加えて、(自然言語機能を備えた) クエリインターフェイスを公開しています。これにより、他の方法では複雑すぎるアクセスに関する質問をユーザーができるようになります。
有効な権限を計算することで、複雑な構成を単純なフィルターに簡略化し、プロセスと理解を標準化できます。これにより、監査がより簡潔になり、レビューへのアクセスの一貫性が向上し、調査が迅速になります。定義について議論する代わりに、計算された権限の理解に基づいて業務を行います。
修復
Exaforceを含む多くのIAMまたはリスクツールでは、「リスクの高いユーザー」に多くの権限または未使用の権限のフラグが付けられます。ただし、権限が本当に過剰かどうかを判断するには、コンテキストが必要です。
これらの権限は実際に使用されていますか？
このユーザーの行動は同業他社と比べてどうですか?
彼らの活動は彼らの役割と一致していますか？
効果的な権限と使用状況分析を組み合わせると、静的なアクセスレビューから行動を意識した権限管理に移行できます。同様の行動をとるユーザーを特定し、適切にクラスター化できます。チームの他のメンバーとは違う振る舞いをする外れ値を検出できます。より広範な運用パターンを正当に示す SRE など、役割のアーキタイプを認識できます。
最も重要なのは、何を変更する必要があるかを判断できることです。
AWSのような階層型システムでは、チームに「このユーザーには未使用の権限があります」と伝えることは実用的ではありません。効果的な権限分析により、リスクの原因となっている特定のポリシーを特定し、問題がロール、グループ、または権限セットレベルにあるかどうかを判断し、修正が必要なオブジェクトを正確に推奨することができます。このようなシステムは、Okta グループや同様の外部ツールでロールを管理している場合はさらに複雑になる可能性があります。
この AWS ユーザーに対してアクセスレビュー監査が行われたこの例を参照してください。システムがアクセス権限がどのように割り当てられ、どれが使用されているかを確認し、それに応じて推奨を行ったことがわかります。この推奨事項は、特に、グループによって付与された ID の権限とは別に、直接割り当てられたロールに関するものです。「是正」タブには、ポリシー、権限セット、グループなどを編集する方法、またはこの場合のようにこの ID から直接割り当てられたロールを削除する方法が段階的に説明されています。
ロールが事前定義されている SaaS プラットフォームでは、この方法がさらに実用的になります。使用パターンと比較した役割分析に基づいて、推測に頼らずに最適な役割を推奨し、過剰な権限付与を減らすことができます。
この GitHub ユーザーと、そのリポジトリ (repo) の役割と権限を見てみましょう。この ID がアクセスできるリポジトリのリスト、割り当てられたロールの概要、使用状況に応じて適切なロールサイズを確認できます。以下に、最適なロールの計算方法と、そのロール内の特定のアクションのうち、使用されたものと使用されなかったものの詳細な分析を示します。使用済み権限が 100% 含まれ、未使用の権限が最も少ないロールを特定して、最適なロールを算出します。この例では、GitHub はリポジトリごとに 5 つの既成のロール (書き込み、管理、保守、読み取り、トリアージ) を用意しています。各ロールには、使用可能なアクション権限が決まっています。ただし、環境によってはカスタムロールも用意されており、その場合は、カスタムロールを同様に評価して最適なものにすることができます。
インパクト
SOCの観点から見ると、調査中の最も重要な質問の1つは次のとおりです。
このIDが侵害された場合、どの程度悪くなる可能性がありますか？その答えは、効果的な権限です。
アイデンティティで何ができるかを理解することで、爆発半径の推定、アクセス、変更、削除が可能な機密リソースの特定、潜在的な横方向への移動経路の特定、アカウント間またはシステム間の影響の評価が可能になります。
すべてのアラートが同じというわけではありません。読み取り専用ユーザーによる疑わしいログインは、IAM ポリシーを変更したり、本番データベースにアクセスしたり、ロギングを無効にしたり、その他の権限の高い役割を引き受けたりできる ID からの疑わしいログインとは根本的に異なります。クロスソース権限も同様に考えることができます。アクティブなリポジトリで Github への管理者アクセス権限を持ち、AWS で高い権限を持っているユーザーは、侵害された場合の影響が重なることを考えると、はるかにリスクの高い従業員になる可能性があります。Exaforce はソースごとの権限を ID ごとに評価しますが、各ユーザーを一元的に把握できるように ID 解決も行います。Bob は、各アプリケーションにわたって多数のユーザー名を使用している場合がありますが、Exaforce を使用すれば、アプリケーション間の Bob のアクセス状況を一元的に把握し、それぞれを詳しく調べることができます。このクロスソースの可視性とスティッチングにより、リスクの全体像を把握できるようになり、脅威の優先順位を知らせるために利用しています。
逆に、ユーザーが自分自身に追加のポリシーを付与すると、追加の権限を持つロールへのアクセス権が付与されます。これは表面的には非常に疑わしいものです。しかし、よく見ると、特定の管理アクションの役割自体の範囲が非常に限られていたことがわかります。その結果、このアクションの重要度は中程度とコンテキスト化でき、そうでなければ非常に単純な検出だったものに彩りを添えることができます。
以下の例では、ユーザーが別のユーザーを作成し、広範なS3権限と、長期アクセスキー、具体的にはすべてのS3リソースへの無制限のアクセスを許可するAWS管理ポリシー「Amazons3FullAccess」を付与しています。GuardDuty はアラートをトリガーしませんでしたが、Exaforce はこのアクティビティが危険であると判断し、付与された権限の範囲を考慮してこの結果をトリガーしました。
権限分析は、アイデンティティアラートを単純なシグナルからリスク加重インシデントに変換します。SOCチームにとっては、より迅速なトリアージ、より正確な重要度スコア、より的確なエスカレーション判断、アラート疲れの軽減につながります。
権限の可視化から運用の明確化まで
SOCチームにとって、組織内のユーザーまたはIDの有効な権限を評価できないことは大変な作業です。これにより、実施される分析の有効性が大幅に制限され、起こり得る影響についての認識が歪んでしまいます。現代の企業環境におけるアプリケーションの数と、SOCが監視する多くの環境の複雑さを考えると、SOCチームにこの情報を手動で作成させるのは非常に時間がかかる可能性があります。
効果的な権限とそれがSecOpsに与える影響について詳しく知りたい場合は、 録画したウェビナーを視聴する。
