AWS IAM Roles Anywhere ‑ IAMのリスクについて

AWSは新たに、アイデンティティーとアクセス管理(IAM)のための革新的な機能であるIAM Roles Anywhereを発表しました。この機能により、AWSアカウント(オンプレミスまたは他のクラウド)の外部にあるワークロード(または任意の証明書保持エンティティー)が、お客様のAWSアカウントのロールを引き受けて(ロールの一時的な認証情報を取得して)、AWSリソースにアクセスできるようになります。この機能は、AWSリソースへの外部アクセスの管理を大幅に改善する一方で、適切に行われない限り、ワークロードのアイデンティティーのガバナンスと管理性を低下させる可能性があるというセキュリティの課題も抱えています。

新機能の仕組み

この機能が追加される前は、オンプレミス サーバーはAWSアカウントにIAMユーザーを作成し、そのIAMユーザーのアクセス キーを作成してオンプレミス サーバーにそのキーを配置するといった方法などで、AWSアカウントのS3バケットにアクセスしていました。しかし、アクセス キーを使用してワークロードを識別することは、次のような理由からあまり好ましくありません。

• アクセス キーを忘れて漏洩する可能性がある
• これらのキーを使用しているのが誰なのかを可視化できない
• 定期的なローテーションが必要になる

Roles Anywhereの登場

簡単に説明すると、この機能は、認識されていることを確認する証明書をワークロードに発行するCA(認証局)に依存しています。AWS内ではトラスト アンカーを作成しますが、基本的にこれはAWSに「これは私のCAで、私のワークロードを認証するために信頼している」と伝えるものです。このトラスト アンカーによって信頼が確立されると、引き受けることができるロールが集められた「プロファイル」を作成します。

ワークロードがAWSリソース(上記のS3バケットなど)にアクセスする場合、CAによって署名された証明書をAWSに提示し、プライベート キーを使用してリクエストに署名します。証明書が有効な場合、AWSはそのロールの一時的な認証情報を呼び出し元のワークロードに返します。

IAM Roles Anywhere (提供：AWS Identity):

ロールの信頼ポリシーの変更

Roles Anywhereを使用するワークロードが引き受けるロールは、rolesanywhereサービスを信頼ポリシーに追加して、「rolesanywhere」のサービスを信頼できるものと認識する必要があります。以下の信頼ポリシーの例には、ロールがRoles Anywhereに参加するための、ロールの信頼ポリシーの最小要件が示されています。

ワークロードを区別する方法

ワークロードは、証明書の組織単位(OU)とサブジェクト共通名(CN)によって区別できます。CNとOUの両方がaws:principalTagキーで使用でき、ロールの信頼ポリシーの条件として利用されます。

上記の例では、このロールを「pipeline.prod」という名前のワークロードによってのみ引き受ける必要がある場合、CAはワークロードにCN=「pipeline.prod」の証明書を発行し、ロールの信頼ポリシーには次の条件を含める必要があります。

セキュリティへの影響

クラウドでIAMを管理する際の最も大きな課題の1つは、「誰が自分のクラウドにアクセスできるのか？」を明確にすることです。別の言い方をすれば、自分のアイデンティティーがどこにあるのかを明らかにする必要があるのです。

どのクラウド環境においても、アイデンティティーはIAMユーザー、ワークロード、外部から引き受けたロール、フェデレーティッド アイデンティティーの組み合わせになります。IAMユーザーとアクセス キーの使用を排除する必要性は明らかですが、目指すべきは複雑さを増やすことではなく、むしろ軽減することです。

rolesanywhereにおけるCAと条件キーの組み合わせにより、クラウド アイデンティティー ストアとしてレンダリングされ、CAによって定義され、条件キーによって適用されるアイデンティティーがCNに隠されます。クラウド セキュリティの管理者が「誰がインターネットからこのロールを引き受けることができるのか」を割り出そうとしていると想像してみてください。信頼ポリシーのいくつもの複雑なJSONオブジェクトを調べながらCA構成を追跡し、ロールを引き受けてデータにアクセスするワークロードをマッピングするのです。

別の言い方をすれば、条件キーはインターネットからアカウントにアクセスできるアイデンティティーを管理する場所には適していません。

影響範囲の管理に関しては、環境内でrolesanywhereが使用されるとCAの侵害はAWS環境の侵害を意味することになるので、これは重要です。

さらに、このサービスを展開する際には、次のような重要な構成ギャップに注意する必要があります。

• CNはロールの信頼ポリシーの条件キーとして使用できるものの、使用自体は強制されず、rolesanywhereサービスを信頼ポリシーに条件なしで追加できるため、信頼されたCAからの有効な証明書を提示するすべてのエンティティーがロールを引き受けることができる。
• 信頼ポリシーの条件に複数のCN文字列を追加すると、職務の分離や最小特権のアプローチに違反する可能性がある。
• 同じロールはrolesanywhereだけでなく他のアイデンティティーも信頼できるため、rolesanywhereのサービスと他のエンティティーが並行して引き受ける結果、別の複雑さを持つレイヤーが作成される。
• ワークロードのソースIPは信頼ポリシーまたは添付のアクセス許可ポリシーの条件キーでは使用できない(アクセス キーとIAMユーザーを使用する場合には使用可)。これはリクエスト コンテキストのIPが呼び出し元サービス(rolesanywhere)として設定されているためで、ワークロードのIPをリクエスト コンテキストで渡すことができる場合は、制御の重要なレイヤーが追加される可能性がある。

ベスト プラクティスと推奨事項

次のベスト プラクティスは、ZscalerのPosture ControlであるCNAPPプラットフォームに組み込まれ、サポートされています。

• rolesanywhereで引き受ける専用のロールを指定し、rolesanywhere外で引き受ける既存のロールは再利用しない
• ワークロードごとに1つのロールを指定する
• 類似したワークロードをrolesanywhereプロファイルにグループ化して、管理性を向上させる
• プロファイルのセッション ポリシーを使用して侵害の影響範囲を制御する。例えば、セッションポリシーを使用して以下を実践します。
  • S3バケットとデータベース インスタンスの削除を拒否
  • IAMの動作をすべて拒否
  • 関連するサービスのみに動作を制限
• CNとOUを組織の命名規則に準拠し、説明責任を果たせる形式で使用

Posture Controlの詳細をご要望の場合はデモを依頼するか、お問い合わせください。