AWS の IAM Access Analyzer が、カスタムポリシーチェックを実施できる API を提供するようになりました。 Tenable Cloud Security では、この API をコードスキャン機能の一部として簡単に使用することができます。 その使用方法と重要性についてご紹介します。

AWS は本日、AWS の IAM Access Analyzer (AA) に対する大幅な機能強化を発表しました。この発表で特筆すべきことは、IAM とリソースベースのポリシーに対するカスタムポリシーチェックの実行が可能になり、セキュリティチームはポリシーに準拠しない更新を先行的に検出できるようになったことです。

IAM Access Analyzer は、アクセス分析、ポリシーチェック、ポリシー生成を通じて、AWS IAM 権限を設定、検証、改良するためのツールを提供します。 アクセス分析によって、視覚化が容易でアクションにつながるインサイトが得られます。 全体的に、IAM Access Analyzer はお客様を最小権限の実現へと導くツールといえます。

AWS のドキュメントに明記されているとおり、 AA によって「自組織内のリソース、および外部団体と共有されているアカウントを特定する」、「ポリシーの文法とベストプラクティスに照らして IAM ポリシーを検証する」、「AWS CloudTrail ログのアクセスアクティビティに基づいて IAM ポリシーを生成する」ことができます。

AWS は、組み込まれたルールベースによるチェックに加えてカスタムチェックをユーザーが実行できるようにする新しい機能を発表しました。 新しい IAM やリソースベースのポリシーを作成する際、または既存のポリシーを更新する際に、API に問い合わせて、ポリシーやその新バージョンに次の点がないかをチェックできるようになります。

• 前バージョンのポリシーにはなかったアクセスが追加されていないか
• 企業のセキュリティ基準で制限されている権限へのアクセスが許可されていないか
• あらかじめ定義された境界の外へのアクセスが許可されていないか

AWS によると、これは 「自動推論の力、つまり数学的証明で裏付けられたセキュリティ保証」を用いて行われるとのことです。

これは、あらゆる場所のセキュリティチームにとって重要なユーティリティ機能となる可能性があります。これに伴い、デプロイメント前の IAM ポリシーの検証をよりきめ細かく、(本記事で後述するように) 柔軟に実施できるようになります。

この新機能は Tenable Cloud Security と統合されていいることから、Tenable のお客様にはなおさら利用しやすくなっています。そしてこれを利用すると、コードを 1 行も追加することなく Tenable の既存のコードスキャン機能の一部として活用できます。

SCP が当てはまらない場合

この機能拡張がもたらす大きな可能性を理解するためには、この新しい機能と、(個人的に私が愛用する) 別のセキュリティコントロール、つまりサービスコントロールポリシー (SCP) の違いを理解する必要があります。 SCP を使えば、アカウント内のアイデンティティに与えられる権限の候補に制限を設定することができます (AWS のポリシー評価ロジックの一部として評価されます)。 このツールは、アカウント内のアイデンティティがアクセスできるサービス、アクション、リソースに上限を設けたり、アクセスを絶対に拒否したい機密情報を扱うアクティビティや潜在的に危険なアクティビティを同アイデンティに対して制限したりするのに優れています。 たとえば、よく使用されているとある SCP では、インスタンスメタデータサービスバージョン 1 (IMDSv1) が有効な Elastic Compute Cloud (EC2) インスタンスを起動する機能や、既存のインスタンスの既存のメタデータオプションを変更する機能が拒否されます (つまり IMDSv1 を有効にできません) 。例えば、以下のようなものです。

{ "Version": "2012-10-17", "Statement": [ { "Action": [ "ec2:RunInstances" ], "Resource": [ "arn:aws:ec2:*:*:instance/*" ], "Effect": "Deny", "Condition": { "StringNotEquals": { "ec2:MetadataHttpTokens": "required" } } }, { "Action": "ec2:ModifyInstanceMetadataOptions", "Resource": "*", "Effect": "Deny", "Condition": { "StringNotLike": { "aws:PrincipalArn": "<PRIVILEGED_ROLE>" } } } ] } 

なお、同様の機能が SCP なしで、アカウントレベルでもまもなくサポートされるようです。

SCP にはデータの境界の作成やセキュリティのベストプラクティスの適用に関する素晴らしいユースケースが多数ありますので、AWS の GitHub リポジトリでそういった SCP の例を確認することを強くお勧めします。

SCP は素晴らしいのですが、その拒否するアクションが実際に拒否すべきかどうかがあまり明確でない場合には、AWS アカウントへの適用には高いリスクを伴うことがあります。この適用によって、必要な機能がブロックされ、正当なアクティビティが危険にさらされるおそれがあります (基本的にこれはサービス拒否となります。そして、サービス拒否はおそらくセキュリティチームが最も避けたいことだと思います)。 こうした理由から、本番環境に導入する前に、SCP を確実に適切な形でテストすることが重要なのです。

これまでいくつかの事例で見てきたように、この教訓も以下のような苦い経験を経て得ることになるかもしれません。

そして時には、アクセス拒否エラーの原因が SCP であることを検出することさえ難しいかもしれません。 このような理由から、Tenable Cloud Security に携わる私の同僚 Noam Forman Dahan はオープンソースの CLI ツール Access Undenied を公開しています。ぜひご覧になることをお勧めします。

明示的な境界のない「境界」

そして今、この新しい AA 機能を使用すれば、明示的な境界を実際には設定せずに「境界」を構築することができます。

AWS の機能リリースの発表にもあるように、「セキュリティチームはこれらのチェックを使用してレビューを合理化できるようになり、セキュリティ基準に準拠するポリシーは自動的に承認し、準拠していない場合はより詳細に調査することが可能です」。

この API を使用することで、AWS でポリシーを作成または更新するプロセスに「ポリシーチェックステップ」を追加することができます。

これによりセキュリティチームは、厳格な境界の代わりに、カスタマイズして適用可能なロジックと手順を追加できるようになります。

Tenable Cloud Security の登場

Tenable ではこの新機能を活用して Tenable 製品との統合を作成し、Tenable のお客様が継続的インテグレーション/継続的デリバリー (CI/CD) 手順の一部としてこのステップをより簡単に実行できるようにしました。詳細を図 1 に示しますのでご参照ください。

図 1: カスタムポリシーチェックのデプロイメントプロセスへの統合

画像出典: AWS ブログ、Introducing IAM Access Analyzer custom policy checks (IAM Access Analyzer カスタムポリシーチェックの紹介)

Tenable では、セキュリティの潜在的な設定ミスを検出するためのスキャンをすでに提供していましたので、IAM ポリシーを AA の API に送信することのほか、これらのカスタムチェックを Tenable のセキュリティリサーチエンジニアが作成した事前設定済みルール (権限昇格を可能にする幅広い範囲やアクションなど) とお客様が設定したポリシーの両方に対して実行することが可能になりました。

図 2: AA を使用したカスタムポリシーチェックのために Tenable Cloud Security に組み込まれた高度なポリシー

画像出典: Tenable、2023 年 11 月

このようなスキャンの結果は、Tenable のスキャン結果と同じ場所に取り込まれます。

図 3: Tenable Cloud Security による IaC のスキャン結果

画像出典: Tenable、2023 年 11 月

これによりお客様は、ポリシーについての付加的な「標準装備の」インサイトをポリシー適用前に得られるようになります。というのも、Tenable のリサーチエンジニアが、機密情報を扱うアクションや重要なアクションに関するこだわりの強いチェックを統合しているためです。 また、お客様が特に高い関心を寄せるアクションに対して独自のチェックをご自身で設定することもできます。

この統合はお客様の CI/CD に拡張することができるので、セキュリティチームは、必ずしも全面的に拒否すべきではないアクションに対して、提案された権限の割り当てにどのように対応するかを非常に柔軟に決定できるようになります。

セキュリティチームは、単純にアイデンティティが権限を行使しようとした時点で拒否するのではなく、それよりはるかに早い段階、つまり権限の割り当てが検出された時点で、特定の環境 (本番環境など) でのビルドをブロックすることができます。 その後、セキュリティチームが介入と調査を行い、ルールから除外してとにかく権限を割り当てるか、あるいは低い権限の許可セットに置き換えて、提案された権限の割り当てを回避することになります。

別の方法としては、セキュリティチームは単にこの調査結果をもとに警告を生成することに決めて、DevOps チーム (もっと言えば開発者自身) が自らの裁量で最善の対策を決定できるようにすることも可能です。

図 4: Tenable Cloud Security と CI/CD パイプライン (GitHub Actions) との統合

画像出典: Tenable、2023 年 11 月

この機能は、Tenable Cloud Security の強力なツールと統合されることで、よりアクセスしやすく、簡単に使用できるようになります。

Tenable Cloud Security のデモをご覧になりたい方は、https://jp.tenable.com/products/tenable-cloud-security をご参照ください。