AWS IAM Roles Anywhereの危険性に迫る。

エグゼクティブ サマリー

ハイブリッド環境で機能するアプリケーション、デバイス、サービスへの組織の依存度が高まるにつれ、人間以外のアイデンティティが一般的になりつつあります。Amazon Web Services (AWS)では、組織内のこれらのアイデンティティに対するセキュアなアクセスにむけて、AWS Identity and Access Management (IAM) Roles Anywhereサービスを導入することで、AWS外のワークロードが従来のアクセス キーの代わりにデジタル証明書を使用して認証できるように取り組んでいます。

AWS IAM Roles Anywhereサービスは、組織にいくつかのセキュリティ上の利点を提供するもので、特に公開鍵基盤(PKI)を既に持っている組織にとっては、比較的簡単に設定することが可能とされていますが、通常この種のサービスを導入するには、インフラを設計する際に、最小特権とアクセス許可を慎重に検討する必要があるものです。これは、適切なセキュリティ管理と実践的な深層防御アーキテクチャを欠いていた場合、組織は不注意にもクラウド環境を不測のリスクにさらすことになりかねないからです。

本記事は、Roles Anywhereサービスを使用する際の不適切な設定やアーキテクチャ設計に関連する主なリスクについて説明するものです。これらのリスクは、共通の根本原因から生じるものとされており、当該サービスのデフォルト設定は、サービスの対象となるAWSアカウントとリージョンのコンテキスト内で比較的寛容なものとされています。

本記事では、これらのリスクを脅威アクターの視点と組織の視点の両方から分析を行いました。調査結果について理解することで、本サービスの利用を設計する際に伴う潜在的なリスクと、組織がそれを軽減する方法について学習することができます。

Cortex Cloudは、本記事で詳述する公開鍵基盤(PKI)の設定ミスに対する保護を提供することが可能です。Cloud XDR Agentベースのルールと振る舞い分析ルールの両方を使用して、IAMポリシーが悪用されたことを検知すると、Cortex CloudはXSOARプラットフォームの自動化機能を使って悪意のある操作を検出し阻止します。

Unit 42 Cloud Security Assessmentを導入いただくことで、クラウド セキュリティ体制の評価に関する支援を受けることができます。

情報漏えいの可能性がある場合、または喫緊の事態の場合は、Unit 42インシデントレスポンス チームまでご連絡ください。

はじめに

Roles Anywhereは、2022年に初めて導入されたアクセス管理サービスです。外部ワークロードがX.509デジタル証明書を使用してAWSに認証できるようにするもので、ワークロードで長期的な認証情報を作成・管理する必要がなくなり、最終的にAWS環境内でのクラウドAPI運用がよりセキュアかつ管理しやすくなることを意図しています。

簡単に言うと、Roles Anywhereを使用することで、クライアントの証明書を検証する資格がある認証局(CA)証明書を定義することができます。このようなCAによって署名されたクライアント証明書は、以下の用途に使用することができます。

• AWSへの認証
• 証明書ベースのIDを対応するクラウド ネイティブのIDと交換(一時的なクレデンシャ ルのセットとして)。
• 一時的なAWS認証情報でリクエストに署名し、通常通りAWSクラウドAPIを呼び出す。

主要コンポーネントとコンセプト

認証プロセスは、以下のコア コンポーネントで構成されています。

• トラスト アンカー: トラスト アンカーは、Roles AnywhereのCA証明書を表すリソースです。トラスト アンカーが作成されると、CA証明書を添付する必要性が生じます。トラスト アンカーは2種類あります。
  • AWS Certificate Manager-Private Certificate Authority(ACM-PCA)証明書: これはマネージドAWSリソースです。
  • 証明書バンドル: トラスト アンカーに直接添付される、プライバシー拡張メール(PEM)ASCII形式でエンコードされたX.509証明書です。
• プロフィール: これらは、Roles Anywhereで認証されたエンティティのアクセス レベルを決定するリソースです。プロファイルには、アクセス許可を定義するIDおよびアクセス管理(IAM)ロールが割り当てられ、さらにアクセス許可を微調整するメカニズムが追加されます。
• IAMロール: IAMロールは、パーミッションを付与(または削除)する実際のIAMポリシーとともに割り当てられます。

実際には、Roles Anywhereを使用した認証は、/sessionsエンドポイントにリクエストを送信することで行われます。リクエストは証明書の秘密鍵で署名され、トラスト アンカーのAmazon Resource Name (ARN)、ProfileとRoleのARNをパラメータとして受け取ります。

リクエストを構成する簡単な方法はaws_signing_helperツールを使うことです。このツールは認証プロセスを自動化し、Amazon Elastic Compute Cloud(EC2)インスタンスが機能するのとほぼ同じ方法でインスタンス メタデータ サービスのエンドポイントをエミュレートすることで、認証情報をローカルで利用可能にすることもできます。

図2に、Roles Anywhereを使用したリクエストとレスポンスの例を示します。

Roles Anywhereの通常利用

Roles Anywhereの設定フローをより理解するために、次のシナリオを考えてみましょう。

• AWS外のKubernetesポッドでは、Simple Storage Service(S3)バケット内のオブジェクトを読み取るためのアクセスが必要とされています。
• クラウド エンジニアは証明書を発行し、トラスト アンカーの証明書を使って署名します。署名された証明書は、秘密鍵とともにポッドに格納されます。
• エンジニアは、関連するS3権限を含むIAMロールを作成し、それをRoles Anywhereプロファイルにアタッチします。
• これでKubernetesポッドは、証明書と関連するロールの認証情報を該当鍵と使用して、設定されたS3バケット内のオブジェクトに署名、認証、読み取りを行うことができます。

デフォルト認証プロセスの保護

この認証プロセスの興味深い点は、デフォルトではトラスト アンカーと特定のプロファイルの間に相関関係がない点にあります。組織はこのセットアップに伴うリスクを理解し、それに応じてRoles AnywhereリソースとIAMロール信頼ポリシーを構成することが極めて重要です。

言い換えれば、組織はクライアント証明書が特定のトラスト アンカーによって署名され、特定のプロファイルに宛てたものとなるように設定する必要があります。これにより、同じAWSアカウントとリージョンの他のプロファイルやトラスト アンカーからのアクセスを防ぐことができます。

この過程で起こりうる結果を示すために、上記のポッド シナリオを考えてみましょう。ここまでの流れは正当なものです。どこから見ても、ポッドには必要な許可が正確に与えられています。

しかし、もし攻撃者がポッドにアクセスしたらどうなるでしょうか？同じAWSアカウントとリージョンで他のプロファイルが作成された場合、攻撃者は証明書を使用して以下のプロファイルのロールにアクセスすることができるようになります。

• 攻撃者は、同じプロファイルにアタッチされている別のIAMロールのARN、または別のプロファイルのARNとアタッチされているロールを推測します。これらのARNを推測するのは複雑なタスクで、AWS環境への追加権限を必要とするものです。これらのテクニックについては本記事の後半で説明します。
• 必要な情報をすべて入手した攻撃者は、異なるロールの認証情報を取得するリクエストを作成し、その権限を使用して悪意のある操作を行うことができます。

AWSでは、ロールのトラスト ポリシーの条件を使用して、Roles Anywhereからのアクセスを制限するいくつかの方法が公開されています。しかし、Roles Anywhereのデフォルトのトラスト ポリシーには、そのステートメントに条件がありません。つまり、デフォルトのポリシーを使用する環境では、アクセス制限が課されないのです。なお、Roles Anywhereの設定にデフォルト設定を使用していないことを確認するのは、組織の責任とされています。

Roles Anywhereで使用されるデフォルトのロールが作成されると、以下のトラスト ポリシーが設定されます。

このポリシーは、このロールがRoles Anywhereサービスによって引き受けられることを示すものです。しかし、それを引き受けることができる情報源に他の制限はありません。つまり、ロールがプロファイルに付加されている場合、同じリージョンのトラスト アンカーによって署名された証明書であれば、このロールを引き受けることができるようになります。

これに対処するため、AWSではポリシーに条件セクションを設けています。これは条件として、リソースに対する追加的な制限を可能にし、これらのリソースがアクションを実行するために満たさなければならない要件を指定するといったものです。

以下のポリシーは、デフォルトポリシーの上に条件セクションを追加し、特定のトラスト アンカーからのみRoles Anywhere認証のアクセスをロールに制限するものです。

署名付き証明書のアクセスをさらに制限する方法として、弊社では証明書の属性マッピングを活用することを推奨しています。AWSでもまた同様のことがRoles Anywhereドキュメントにて推奨されています。

基本的に、証明書の属性をトラスト ポリシーで評価される値にマッピングすることが可能とされています。これを使用して、証明書のコモン ネーム、組織単位、または証明書に含まれるその他の属性に基づいて、ロールにアクセスすることを指定することができます。

これは、Roles Anywhereを認証に使用しているリソースが侵害された場合、追加のロールにアクセスできないようにする保護策として推奨されています。

以下の条件は、前節のトラスト アンカー条件を使用し、さらに証明書の属性に基づいてアクセ スを制限するものです。

他のサービスと同様に、Roles Anywhereインフラストラクチャを実装する際には、最小特権の原則を考慮する必要があります。その際には証明書の属性マッピングが必要とされます。

脅威アクターの視点

シナリオ#1 - 攻撃者による有効な証明書と秘密鍵の使用

上記のように、Roles Anywhereを使用して認証するには、以下の情報が必要です。

• クライアント証明書
• クライアント証明書の秘密鍵
• 証明書に署名したトラスト アンカーのARN
• 同じ地域のプロファイルのARN
• プロファイルにアタッチされているIAMロールのARN

次のシナリオは、攻撃者が秘密鍵による認証に使用されるクライアント証明書のデフォルトのRoles Anywhereの設定を侵害するものです。デフォルトの設定を悪意を持って利用し、アカウント内の追加ロールにアクセスするためには、攻撃者はまだAWSに認証するための関連リソースのARNを発見する必要があります。ARNの取得は一筋縄ではいかず、アカウント内に独立した権限を追加する必要があるためです。

攻撃者はこの情報を得るために、以下のテクニックを用いることが可能とされています。

• Roles Anywhereアクションの使用
  Roles Anywhereサービスに対して十分な権限を得た攻撃者は、単純にアクションを実行して関連するARNを取得することができます。これはlist-trust-anchorsアクションとlist-profilesアクションを使用して行うことができ、それぞれrolesanywhere:ListTrustAnchorsパーミッションとrolesanywhere:ListProfilesパーミッションを必要とします。list-profilesコマンドはプロファイルにアタッチされているすべてのロールを返すため、これらのアクションの出力には、認証要求に必要なすべてのARNが含まれます。
• ログからのデータ取得

CloudTrailはAWSの主要なロギング メカニズムです。CloudTrailログの中で、CloudTrailログ(またはそれを含むストレージ サービス)に独立してアクセスできる攻撃者は、Roles Anywhereサービスによって作成されたアイテムを見つけることができます。CloudTrailのログには、認証プロセスに必要なすべてのARNが含まれているものがあり、Roles Anywhereサービスのログでは、いくつかのアクションのイベントでこれらのARNが開示されています。

最も関連性の高いログはCreateSessionです。このログは、Roles Anywhereが認証に使用されたとき、つまり一時的な認証情報を作成してユーザに送信したときに作成されます。図3で示しているのは、CreateSessionログエントリの例と関連するARNです。

このイベント ログでは、トラスト アンカー、プロファイル、およびそれに付随するロールのARNが確認できます。攻撃者の証明書が、ログに表示されているトラスト アンカーによって署名されていれば、攻撃者はそれを使って認証を実行することができます。

図5は、攻撃者のステップをハイレベルで示したものです。

シナリオ#2 - Roles Anywhereへの直接権限を悪用する

Roles Anywhereサービスのデフォルト設定が悪用される可能性があるもう1つのシナリオは、攻撃者がRoles Anywhere権限を持つIDにアクセスした場合です。これらの許可は、サービス上で直接Allowステートメントによって、またはNotActionエレメントを通して付与されます。

以下の手順で、攻撃者はこれらの許可を利用することができます。

• 攻撃者は、Roles Anywhereのデフォルト設定と権限を持つIDにアクセスします。
• 攻撃者は、CA証明書とクライアント証明書の2つの証明書を作成し、CA証明書を使ってクライアント証明書に署名します。証明書を作成した攻撃者は、その秘密鍵も所有することになります。
• 攻撃者は侵害されたIDを使用してトラスト アンカーを作成し、CA証明書をアンカーに添付します。
• Roles Anywhereのリスト権限を使用して、攻撃者はプロファイルとIAMロールのARNを収集します。
• ARN、クライアント証明書、およびその秘密鍵を用いて、攻撃者はRoles Anywhereを使用して認証します。
• IAMロールのトラスト ポリシーがアクセスを拒否する場合、攻撃者はRoles Anywhereサブジェクトをチェックして、以前認証に使用された証明書の詳細を見つけることで、そのフィールドを新しいクライアント証明書にコピーして対処することができます。

より詳細には、攻撃者が十分なRoles Anywhere権限を持つ場合、証明書を作成し、攻撃者自身のCA証明書で署名することで、新規または既存のトラスト アンカーにアップロードすることができるとされています。これにはrolesanywhere:CreateTrustAnchorまたはrolesanywhere:UpdateTrustAnchorパーミッションが必要です。

攻撃者はクライアント証明書とCA証明書の両方を管理しているので、証明書は有効とされます。続くステップでは、Roles Anywhere list-profilesコマンドまたは上記で説明したその他のテクニックを使用して、利用可能なプロファイルとロールを把握する方法について記述しています。

この情報があれば、攻撃者は Roles Anywhere を使って認証情報を作成し、使用されたロールのコンテキストでその作戦を実行することができます。

標的となる組織のセキュリティ対策が悪意のある活動を検出できない場合、このプロセスは問題が解決されるまで有効なクレデンシャルを生成するためにトラスト アンカーを使用することができるため、攻撃者の持続性ベクトルとしても機能します。

緩和策と提言

1. Roles Anywhereで使用するロールのデフォルトのトラスト ポリシーに条件を追加することを強く推奨します。上述したように、デフォルトのポリシーでは、どのトラスト アンカーもその役割を引き受けることができるためです。特定のトラストアンカー(関連するワークロードを認証するために使用されるアンカー)からのみに、ロールへのアクセスを制限することが極めて重要とされます。

コモン ネームや組織など、特定の属性を持つ証明書のみにアクセスを制限する追加条件も実装することが重要です。しかし、これらの条件は特効薬ではなく、状況によっては回避することもできます。例えば、攻撃者が証明書から属性情報を引き出すことに成功した場合、バイパスが可能となります。

• ACM-PCAタイプのトラストアンカーを使用することが推奨されています。ACM-PCA を使用する場合、Roles Anywhereサービスへのフルアクセスを取得した攻撃者であっても、生成した独自のCA証明書をトラスト アンカーにアップロードすることはできません。トラスト アンカーのタイプは変更できないので、認証にはACM-PCAのパーミッション(これは一般的ではない)が必要ということになるためです。

これは極めて重要なポイントです。トラスト アンカーが引き受けるはずのロールが、前出の条件を使っている場合、そのロールにアクセスすることはできないからです。AWSのプライベートCAには、独自のセキュリティ上の考慮事項があり、正しく設定されていない場合、リスクをもたらす可能性があることに留意すべきです。

• 許可を常に最小特権の原則に基づいて割り当てられるようにします。Roles Anywhereで認証する能力は、通常、人間以外のIDに与えられるものであり、このサービスを使用するデバイスは、通常、実行する必要のある特定の事前決定されたタスクを持っているとされます。したがって、これらのIDのアクセス レベルは、割り当てられたタスクの要件を超えないようにすることが重要となります。IAMロール自体とは別に、セッション ポリシーをプロファイルに関連付けることができることができ、このポリシーは、Roles Anywhereを通じて想定される場合に、ロールが持つことのできる最大権限を定義します。
• AWS IAM Roles Anywhereリソースを定期的に監視および追跡します。トラスト アンカー、プロファイル、関連リソースを継続的に監視することは極めて重要です。トラスト アンカーとプロファイルは頻繁に作成されるものではないため、その作成や変更が疑わしいイベントとなるためです。これらのリソースに予期せぬ変更があった場合は、直ちに調査し、不正な活動が行われていないことを確認する必要があります。定期的な監査と自動化されたアラートは、潜在的なセキュリティ脅威をタイムリーに検出し、対応するのに役立ちます。
• Cortex Query Builderで以下のXQLクエリを実行することで、Roles Anywhereサービスを信頼するが条件を強制しないロールを識別することができます。

結論

本記事では、潜在的な攻撃者の観点と防御者の観点の両方から、AWSのRoles Anywhereサービスのデフォルト設定を使用することに関連する主要なリスクを調査しました。その後、関連するリスクをより適切に管理するために、組織が実施すべき緩和策をいくつか提示しました。本分析が、このサービスのデフォルト機能の使用に伴う潜在的な脆弱性と、それを軽減する最善の方法について、読者の理解を深める一助となれば幸いです。

この記事から得られる重要な教訓のひとつは、クラウド プロバイダーのサービスを利用する際には、無批判に頼るのではなく、その設定やアーキテクチャを十分に理解することが重要であるということです。

• セキュリティのベストプラクティス、最小権限、徹底的な防御戦略に従いましょう。
• これは、サービスが適切にアーキテクトされ、設定の変更を監視するのに役立ちます。
• ランタイム監視を維持することで、カスタマイズされたクラウド プラットフォームが安全に運用されるようになります。

Cortex Cloudは、本記事で詳述した公開鍵基盤(PKI)の設定ミスに対する保護を提供することが可能です。Cloud XDR Agentベースのルールと振る舞い分析ルールの両方を使用して、IAMポリシーが悪用されたことを検知すると、Cortex CloudはXSOARプラットフォームの自動化機能を使って悪意のある操作を検出し阻止します。

Unit 42 Cloud Security Assessmentを導入いただくことで、クラウド セキュリティ体制の評価に関する支援を受けることができます

情報漏えいの可能性がある場合、または緊急の案件がある場合は、以下の連絡先までご連絡ください。 Unit 42インシデント レスポンス チームまたはお電話ください。

• 北米: フリーダイヤル+1 (866) 486-4842 (866.4.unit42)
• 英国+44.20.3743.3660
• ヨーロッパおよび中東+31.20.299.3130
• アジア+65.6983.8730
• 日本+81.50.1790.0200
• オーストラリア+61.2.4062.7950
• インド: 00080005045107

パロアルトネットワークスは、この調査結果をサイバー脅威アライアンス(CTA)のメンバーと共有しています。CTAの会員は、この情報を利用して、その顧客に対して迅速に保護を提供し、悪意のあるサイバー アクターを組織的に排除しています。サイバー脅威アライアンスについてはサイトより詳細をご確認いただけます。

その他のリソース

• 最小特権の原則とは - パロアルトネットワークス
• IAM Roles Anywhereトラストモデル- Amazon Web Services公式ドキュメント