IAM-Deescalate: ユーザーが権限昇格のリスクを軽減できるよう支援するオープン ソース ツール

This post is also available in: English (英語)

概要

パロアルトネットワークスの脅威インテリジェンスチームUnit 42が、最近のクラウド脅威レポートで、200の異なる組織に属する18,000件のクラウドアカウントで680,000個以上のIDを分析したところ、クラウドのユーザー、ロール、サービスアカウントの99%において制限が緩すぎることが判明しました。一般に、クラウドユーザーは、実際に必要な権限以上の権限をIDに付与しています。このような過剰な権限によって、攻撃対象領域がいたずらに拡大され、権限昇格のリスクが高まります。セキュリティインシデントが発生した場合、攻撃者は過剰な権限を悪用して、管理者など、より大きな権限を持つロールへの昇格を行う可能性があります。

こうした懸念を考慮して、弊社は、AWSにおける制限が緩すぎるIDの権限昇格リスクの軽減に役立つオープン ソース ツールを開発しました。AWSのIDおよびアクセス管理(IAM)サービスが提供するきめ細かな制御機能は、クラウドリソースのセキュリティの向上に役立ちますが、権限ポリシーが適切に設定されていなかったり、ポリシーを通じて権限が過剰に付与されていたりすると、かえってリスク増大につながるおそれがあります。弊社のオープン ソース ツールは、ユーザーがリスクを軽減し、IAMサービスが提供するセキュリティ上のメリットをより適切に活用できるよう支援することを目的としています。

IAM-Deescalateと呼ばれるこのツールは、まずPMapperを使用して、権限昇格のリスクがあるユーザーとロールを特定します。リスクのあるプリンシパルごとに、IAM-Deescalateは、そのプリンシパルに付与されている権限のうち、無効にすることによってリスクを排除できる最小権限セットを計算します。特に、IAM-Deescalateは、プリンシパルが管理者権限への昇格を実行できるようにしてしまう可能性があるリスクのある権限を明示的に拒否するインラインポリシーを挿入します。

IAM-Deescalateは、PMapperによって特定されたすべての権限昇格リスクを修正することができます。この執筆時点で、IAM-DeescalateはIAM Vulnerableプロジェクトで管理されている既知の権限昇格手法について77%の修正に成功しています。IAM-Deescalateは軽量なので、あらゆるDevOpsワークフローで実行することができ、あらゆる高リスクIDを検出してデプロイを防止できます。今後のリリースでは、対象の手法の範囲を継続して拡大し、さらに多くの権限昇格手法に対応していく予定です。

目次

IAM-Deescalateの仕組み
評価
結論
追加リソース

IAM-Deescalateの仕組み

IAM-DeescalateはIDベースのポリシーのチェックと修正を行う必要があるため、十分なIAM権限を持つ承認されたユーザーによる使用を意図したツールとなっています。このポリシーに、必要な権限を示しています。

ユーザーとロールのグラフの構築

PMapperは、AWSアカウントにおけるプリンシパル(ユーザーとロール)を有向グラフとしてモデリングします。各ノードはプリンシパルを表し、各エッジは1つのプリンシパルから別のプリンシパルへの遷移を表します。プリンシパルAがプリンシパルBとして認証可能な場合、プリンシパルAからプリンシパルBに向かうエッジが存在することになります。あるプリンシパルが別のプリンシパルとして認証可能なのは、一定の条件が満たされたときに限られます。詳細については、AWS IAM Privilege Escalation (AWS IAMの権限昇格)、That Escalated Quickly (すばやい昇格)、Understanding Privilege Escalation (権限昇格について理解する)などの先行するリサーチを参照してください。図1は、5つのノードと4つの有向エッジを持つグラフの例を示しています。

• ユーザーAはロールBとして振る舞うことができます。したがって、ユーザーAからロールBへの有向エッジが存在します。
• ロールBは、このロールが制御するEC2インスタンスにロールDを渡すことができます。したがって、ロールBはEC2インスタンスを介して間接的にロールDとして認証を受けることができます。
• ロールBはユーザーCのログインプロファイルを更新することができます。したがって、ロールBはユーザーCの新しいパスワードを作成することで、ユーザーCとしてログインできます。
• ロールBはユーザーCの新しいアクセスキーを作成することができます。したがって、ロールBはこの新しいアクセスキーを使用することで、ユーザーCとして認証を受けることも可能です。
• ユーザーEは分離されています。ユーザーEは別のプリンシパルとして認証を受けるための条件をまったく満たしておらず、また他のどのプリンシパルもユーザーEとして認証を受けることはできません。

このグラフが完全に作成されると、任意の2つのプリンシパル間について可能なパスを検索できるようになります。2つのプリンシパル間のパスは、ゼロ個の場合もあれば、複数の場合もあります。あるプリンシパルが、管理者ではなく、しかし管理者プリンシパルへのパスを持っている場合、IAM-Deescalateはそのプリンシパルについて、権限昇格のリスクがあるとみなします。

権限昇格エッジの特定と切断

リスクのあるプリンシパルを検索するために、IAM-Deescalateはグラフを非管理者と管理者の2つの区分に分けます。非管理者区分から管理者区分への有向エッジはすべて権限昇格エッジと呼ばれます。図1で、赤いノードは管理者区分に属し、黒いノードは非管理者区分に属し、赤いエッジは権限昇格エッジです。この例では、ロールBのみがリスクのあるプリンシパルであり、このプリンシパルは権限昇格が起こり得るエッジを3つ持っています。

IAM-Deescalateはこれらすべての権限昇格エッジの切断を試みます。前述のように、2つのプリンシパル間にエッジが作成されるのは、一定の条件が満たされたときに限られます。このような条件が成立しなくなると、エッジは除去されます。権限昇格エッジを切断するために、IAM-Deescalateは、非管理者プリンシパルから管理者プリンシパルへの遷移を可能にする条件を1つ以上無効にします。図1の例の場合、IAM-Deescalateは、以下の権限を明示的に拒否するポリシーをロールBに挿入することによって、赤いエッジを切断します。

• ユーザーCに対するiam:CreateAccessKeyの実行。
• ユーザーCに対するiam:UpdateLoginProfileの実行。
• ロールDに対するiam:passroleの実行。

既存のワークロードへの潜在的な影響を最小化するために、IAM-Deescalateは、エッジ切断のために必要な最小限の権限の無効化のみ行います。ユーザーは、提案された修正計画を確認して、どの権限を無効にし、どの権限を維持するかを手動で選択できます。「元に戻す」オプションを使って、IAM-Deescalateによって適用された修正ポリシーを元に戻すこともできます。

評価

弊社では、IAM-Deescalateを評価するためのベンチマークとしてIAM-Vulnerableプロジェクトを使用しました。本稿執筆時点で、IAM-Vulnerableでは31の既知の権限昇格手法が管理されており、それぞれが固有の権限昇格リスクを持つ31の異なるユーザーとロールを作成できます。そして、IAM-Deescalateによるこれらの31のプリンシパルへの修正ポリシーの適用の前後に、PMapper (v1.1.5)、Cloudsplaining (v0.5.0)、Pacu (v1.0.3)の3つのオープン ソース プロジェクトを使用して権限昇格リスクの有無をチェックしました。

表1は評価結果の詳細を示しています。「修正前」の下にある列は、3つの権限昇格スキャナーの有効性を示しています。PMapperは最も高い検出率(77%)を達成し、次がPacuの68%、Cloudsplainingの61%と続きます。これらの結果は、IAM-Vulnerableの評価に関するブログの調査結果と整合しています。

「修正後」の下にある列は、IAM-Deescalateによる修正ポリシーが適用された後、3つの権限昇格スキャナーの有効性を示しています。PMapperで特定された24のリスクのあるプリンシパルは、すべて適切に修正されました。CloudsplainingとPacuではいずれも、修正プロセスの後も引き続き権限リスクのあるプリンシパルが5つ特定されました。これらのリスクのあるプリンシパルは、PMapperでは特定されず、IAM-Deescalateによる修正が適用されなかったプリンシパルです。全体的には、IAM-Vulnerableで管理されている31の権限昇格手法のうち、24 (77%)の手法がIAM-Deescalateによって適切に修正されています。

興味深い調査結果の1つとして、Cloudsplainingは、すべてのプリンシパルで、修正後も引き続き権限昇格リスクをレポートしている点が挙げられます。これは、Cloudsplainingの場合、各権限ポリシーを個別に評価し、個々のプリンシパルに複数の権限ポリシーが付加されているときに有効な権限の計算を行わないためです。例えば、あるユーザーに3つのポリシー(AWS管理のポリシー2つと顧客管理のポリシー1つ)が付加されている場合があります。有効な権限は、3つすべてのポリシーの条件と権限を考慮した結果として得られる権限です。Cloudsplainingは、有効な権限の計算を行わないため、IAM-Deescalateが挿入したインラインポリシーによって、顧客管理のポリシー内の権限昇格リスクはすでに排除されていることを認識できません。

表1 各種オープン ソース ツールを使用した、IAM-Deescalateの有効性のテスト。

• 真陽性(TP: True Positive): 脆弱なプリンシパル(陽性)を正しく陽性とレポートした。
• 偽陰性(FN: False Negative): 脆弱なプリンシパル(陽性)を誤って陰性とレポートした。
• 真陰性(TN: True Negative): 修正後のプリンシパル(陰性)を正しく陰性とレポートした。
  • (TN*): 権限昇格手法を認識できないため修正後のプリンシパルを陰性とレポートした。脆弱性が存在するかどうかにかかわらず常に陰性としてレポートする。
• 偽陽性(FP: False Positive): 修正後のプリンシパル(陰性)を誤って陽性とレポートした。

結論

最小権限の原則という概念は新しいものではありませんが、弊社のクラウド脅威レポートが明らかにしている、制限が緩すぎるクラウドユーザー、ロール、サービスアカウントに関連する問題の多さは、現実と期待の間に大きなギャップがあることを示しています。攻撃者が過剰な権限を悪用して管理者権限への昇格を行うことが可能な場合、この状況がさらに悪化するおそれがあります。弊社は、AWSにおける権限昇格リスクを軽減するために、IAM-Deescalateを開発し、オープンソース化しました。IAM-Deescalateはリスクのあるプリンシパルを特定し、その後、無効にすることによって攻撃パスを切断できる最小権限セットを計算します。今後も引き続き新たな権限昇格手法が検出されると予想されるなか、弊社ではツールを継続的に改善していきます。オープン ソース コミュニティの皆様にもご協力いただければ幸いです。

追加リソース

IAM Access Analyzer: クラウド証跡ログに基づいてIAMポリシーの検証と最小権限ポリシーの生成を支援するAWSサービス。
AirIAM: IAMのアクティビティをスキャンし、最小権限による権限ポリシーのプロビジョニングが可能なTerraformテンプレートを作成するオープン ソース ツール。
クラウドインフラストラクチャ権限管理(CIEM): IAM権限の監視と最小権限によるアクセスの継続的な適用のためのマルチ クラウド ソリューションを提供するサービス。