大規模に最小権限を実現するための戦略 – パート 2

本ブログは 2024 年 7 月 9 日に公開された Blog “Strategies for achieving least privilege at scale – Part 2” を翻訳したものです。

この投稿では、AWS Identity and Access Management (IAM) を使用して、大規模に最小権限を実現するための推奨事項を引き続き紹介します。この 2 部構成のシリーズのパート 1 では、IAM で最小権限を大規模に実装するための 9 つの戦略のうち最初の 5 つについて説明しました。また、アプローチを拡張するのに役立ついくつかのメンタルモデルも紹介しました。この投稿 (パート 2) では、組織全体に最小権限を拡張するための残りの 4 つの戦略と関連するメンタルモデルを引き続き見ていきます。

6. 開発者がアプリケーションポリシーを作成できるようにする

もし、クラウド環境で作業する開発者が自分だけであれば、自然と自身で自分用の IAM ポリシーを書くことになります。しかし、クラウド利用を拡大している組織でよく見られる傾向として、中央のセキュリティ、ID 管理、またはクラウドチームの管理者が、開発チームに代わってカスタマイズした IAM ポリシー を作成したり、作成の支援をすることがあります。これは、開発チームがポリシー言語に不慣れであったり、過剰な権限を付与することで潜在的なセキュリティリスクを生み出す恐れがあるためかもしれません。IAM ポリシーの一元的な作成は一時的にはうまくいくかもしれませんが、チームやビジネスが成長するにつれて、図 1 に示すように、この方法がボトルネックになることがよくあります。

このメンタルモデルは「制約条件の理論」として知られています。このモデルを念頭に置いて、チームや組織が直面する制約やボトルネックを積極的に探し、根本原因を特定し、制約を解決する必要があります。これは当たり前のことのように聞こえるかもしれませんが、早いペースで動いていると、アジリティが損なわれるまで制約が現れない場合があります。組織が成長するにつれて、何年も前に有効だったプロセスが、今日では効果的でなくなっている可能性があります。

ソフトウェア開発者は一般的に、自身が構築するアプリケーションの目的や、必要な権限をある程度理解しています。同時に、中央のクラウド、ID 管理、またはセキュリティチームは、自分たちが安全なポリシーを作成する専門家であると感じる傾向がありますが、アプリケーションのコードに関する深い知識が不足しています。ここでの目標は、開発者がボトルネックを軽減するためのポリシーを書けるようにすることです。

問題は、開発者に適切なツールとスキルを身につけさせ、アプリケーションに必要なポリシーを自信を持って安全に作成できるようにするためにはどうすればよいかということです。まずはトレーニングに投資することから始めるのが簡単な方法です。AWS は、さまざまな正式なトレーニングオプションとランプアップガイドを提供しており、これによりチームは IAM を含む AWS サービスをより深く理解できます。ただし、組織内で小規模なハッカソンやワークショップセッションを自分たちで主催するだけでも、成果を向上させることができます。自分たちで主催するための学習コースの簡単な選択肢として、次の 3 つのワークショップを利用できます。

• How and when to use different IAM policy types workshop – どのポリシータイプをいつ使用するか、そして誰がポリシーを所有し管理すべきかを学びます。
• IAM policy learning experience workshop – 様々なタイプの IAM ポリシーの書き方と、条件を使用してアクセスを制限しながらプリンシパルとリソースにアクセス制御を実装する方法を学びます。
• Refining IAM Permissions Like A Pro – IAM Access Analyzer をプログラムで使用する方法や、CI/CD パイプラインと AWS Lambda 関数で IAM ポリシーをチェックするツールの使用方法を学び、セキュリティチームと DevOps チームの両方の視点からツールを使用したハンズオン実践を行います。

次のステップとして、コラボレーションを促進し、品質を向上させるプロセスを設定することで、チームを支援できます。例えば、ピアレビューを強く推奨しており、これについては後ほど説明します。さらに、管理者はアクセス許可の境界 (permissions boundaries) や IAM Access Analyzer ポリシー生成 などの AWS ネイティブのツールを使用して、開発者がより安全に独自のポリシーを作成できるように支援できます。

まず、アクセス許可の境界を見てみましょう。アクセス許可の境界は、一般的にポリシー作成の責任を開発チームに委譲するために使用されます。開発者の IAM ロールを設定して、新しいロールに特定のアクセス許可の境界が付いている場合のみ新しいロールを作成できるようにし、そのアクセス許可の境界によって、管理者は開発者が付与できる最大の権限を設定できます。この制限は、開発者のアイデンティティベースのポリシーの条件 (Condition 要素) によって実装され、iam:CreateRole や iam:CreatePolicy などの特定のアクションは、指定されたアクセス許可の境界がアタッチされている場合のみに許可されます。

このように、開発者がアプリケーションに必要な権限を付与するために IAM ロールまたはポリシーを作成する際、そのアプリケーションで利用できる権限の上限を「制限」する指定されたアクセス許可の境界を追加する必要があります。そのため、開発者が作成するポリシー (たとえば、AWS Lambda 関数用のもの) が十分に詳細でなくても、アクセス許可の境界により、組織のクラウド管理者は Lambda 関数のポリシーが事前に定義された最大の権限を超えないようにすることができます。そのため、アクセス許可の境界を使用することで、管理者が手動でポリシーを作成することによるボトルネックを解消し、開発チームは（制約付きで）新しいロールとポリシーを作成できるようになります。

開発者が使用できるもう 1 つのツールは、IAM Access Analyzer ポリシー生成です。IAM Access Analyzer は、CloudTrail ログを確認し、指定した期間のアクセスアクティビティに基づいて IAM ポリシーを自動生成します。これにより、エンドユーザーに AWS サービスへのアクセスを許可するためのきめ細かな IAM ポリシーを作成するプロセスが大幅に簡素化されます。

IAM Access Analyzer ポリシー生成の典型的なユースケースは、テスト環境内で IAM ポリシーを生成することです。これは、必要な権限を特定し、本番環境向けのポリシーを改善するための良い出発点となります。例えば、IAM Access Analyzer は使用されている本番環境のリソースを識別できないため、アプリケーションチームが必要とする具体的な HAQM Resource Names (ARNs) を修正して追加するためのリソースのプレースホルダを追加します。ただし、すべてのポリシーをカスタマイズする必要はないため、次の戦略では一部のポリシーの再利用に焦点を当てます。

7. 適切に記述されたポリシーを維持する

戦略 7 と 8 はプロセスに焦点を当てています。最初に焦点を当てるプロセスは、適切に作成されたポリシーを維持することです。まず、すべてのポリシーが芸術作品である必要はありません。適切に記述されたポリシーをアカウント間で再利用することは、権限管理を拡張する効果的な方法となります。このタスクに取り組むためには、次の 3 つのステップがあります：

1. ユースケースを特定する
2. ポリシーテンプレートを作成する
3. ポリシーテンプレートのリポジトリを整備する

例えば、AWS を初めて使用し、新しいアカウントを使用している場合、AWS 管理ポリシーを参考にして始めることをお勧めします。ただし、これらのポリシーの権限は、時間の経過とともにお客様のクラウドの使用方法に適合しない可能性があります。最終的には、自分のアカウントで反復的または一般的なユースケースを特定し、それらの状況に対応する共通のポリシーまたはテンプレートを作成したいと思うでしょう。

テンプレートを作成するときは、そのテンプレートが誰向けまたは何向けであるかを理解する必要があります。ここで注意すべき点の 1 つは、開発者のニーズはアプリケーションのニーズとは異なる傾向があることです。開発者がアカウント内のリソースを操作する場合、多くの場合、リソースの作成や削除が必要になります。例えば、アプリケーションが使用する HAQM Simple Storage Service (HAQM S3) バケットの作成や削除などが挙げられます。

逆に、ソフトウェアアプリケーションは一般的にデータの読み取りまたは書き込みが必要です。この例では、開発者が作成した S3 バケットにオブジェクトを読み書きします。開発者の権限の必要性 (バケットの作成) とアプリケーションの必要性 (バケット内のオブジェクトの読み取り) は異なります。これらは異なるアクセスパターンであるため、異なるユースケースとエンティティに応じた異なるポリシーテンプレートを作成する必要があります。

図 2 は、この課題をより明確に表しています。利用可能な全ての AWS サービスと API アクションの中から、開発者 (もしくはより一般的には、開発者が利用する DevOps ビルド・デリバリーツール) に関連する一連の権限 (図 2 内の “Build tool permissions”) と、開発者が構築しているソフトウェアアプリケーションに関連する一連の権限 (図 2 内の “Possible set of application permissions”) があります。これら 2 つのセットは一部重複している場合もありますが、同一ではありません。

ポリシーの再利用について議論する際、チームメンバーのデフォルトのフェデレーション権限や、組織内の複数のアカウントにわたってセキュリティ監査を実行するための自動化ツールのための権限など、アカウント内の共通ポリシーについてお客様は既に考えている可能性があります。これらのポリシーの多くは、アカウント間で共通で、通常は変化しないデフォルトポリシーと見なすことができます。同様に、アクセス許可の境界ポリシー (前述のポリシー) も、アカウント間で変動が少なくアカウント間で共通性がある可能性があります。これらの両方のポリシーを再利用することに価値があります。しかし、ポリシーを広範に再利用しすぎると、変化が必要な場合に問題が発生する可能性があります。「再利用可能なポリシー」に変更を加えるには、1 つのアプリケーションでのみ必要な場合でも、そのポリシーの全てのインスタンスを変更する必要があります。

複数のチームが必要とする比較的一般的なリソースポリシー (例えば、S3 バケットポリシー) が、わずかな違いを伴って存在することがあります。このような場合、組織のセキュリティポリシーに準拠した繰り返し可能なテンプレートを作成し、チームがコピーできるようにすることが有用かもしれません。ここでは「テンプレート」と呼んでいますが、これはチームがリソースへのアクセスを許可するプリンシパルなど、いくつかの要素を変更する必要があるかもしれないからです。アプリケーションのポリシー (例えば、開発者が HAQM Elastic Compute Cloud (HAQM EC2) インスタンスロールにアタッチするために作成するポリシー) は、通常はより個別性が高くカスタマイズされており、テンプレートには適していないかもしれません。

図 3 は、一部のポリシーではバリエーションが少ない一方で、他のポリシーではよりカスタマイズされていることを示しています。

ポリシーの再利用とテンプレート化のどちらを選ぶかに関わらず、重要なステップは、これらの再利用可能なポリシーとテンプレートを安全なリポジトリに保存することです。多くのお客様は、infrastructure-as-code のモジュールを使用して、開発チームが独自のカスタマイズを入力し、セキュリティポリシーに適合する IAM ポリシーをプログラム的に生成することを簡単にできるようにしています。これらのポリシーやテンプレートを直接リポジトリに保存するお客様もいれば、他の関連情報と共に社内の Wiki に記載するお客様もいます。どのプロセスがお客様の組織に最適かを判断する必要があります。どのような方法を選択するにせよ、チームがアクセスしやすく、検索可能にすることが重要です。

8. ポリシーのピアレビューと検証を行う

パート 1 で述べたように、最小権限は継続的な取り組みであり、フィードバックループを持つことは重要な要素です。フィードバックは人間によるレビューを通じて実装することや、レビューを自動化して結果を検証することもできます。これは、デフォルトポリシーにとっても、カスタマイズされた専用のポリシーにとっても同様に重要です。

まず、使える自動化ツールをいくつか紹介しましょう。優れたツールの 1 つとして、AWS IAM Access Analyzer ポリシー検証とカスタムポリシーチェックの利用を推奨します。ポリシー検証は、安全で機能的なポリシーを設定するために、ポリシーをオーサリングする際に役立ちます。この機能は API と AWS マネジメントコンソールを通じて利用可能です。IAM Access Analyzer は、IAM ポリシーの文法と AWS のベストプラクティスに基づいてポリシーを検証します。ポリシーのセキュリティ警告、エラー、一般的な警告、および提案を含むポリシー検証の検出結果を表示できます。

検出結果の種類をいくつか確認してみましょう。

カスタムポリシーチェックは、セキュリティチームがポリシー内の重要な権限を正確かつ積極的に特定するのに役立つ、IAM Access Analyzer の機能です。この機能を使用して、参照元となるポリシーと比較してチェック（例えば、更新されたポリシーを既存のバージョンのポリシーと比較して新しいアクセスを許可するかどうかの判断）したり、IAM アクションのリストと比較してチェック（つまり、ポリシーで特定の IAM アクションが許可されていないことを確認する）したりできます。カスタムポリシーチェックは、クラウドでより高いレベルのセキュリティ保証を提供するために、静的解析の一形態である自動推論を使用します。

ピアレビューと自動化の両方を支援するテクニックの 1 つに、infrastructure-as-code の使用があります。これは、IAM ポリシーを AWS CloudFormation テンプレート (CFT) または AWS Cloud Development Kit (AWS CDK) アプリケーション として実装し、デプロイすることを意味します。テンプレートにはソフトウェアのバージョン管理システムを使用することで、どのような変更が加えられたかを正確に把握できます。そして、デフォルトポリシーを複数のアカウントにわたってテストし、デプロイすることができます。これには、AWS CloudFormation StackSets を使用できます。

図 4 に典型的な開発ワークフローを示します。これは CI/CD パイプラインを簡略化したもので、3 つのステージがあります。コミットステージ (Commit stage)、検証ステージ (Validation stage)、デプロイステージ (Deploy stage)です。図では、開発者のコード (IAM ポリシーを含む) が複数のステップでチェックされます。

コミットステージでは、開発者がポリシーを作成している場合、ソースコードにコミットする際にピアレビューを迅速に組み込むことができ、これによりチーム内で最小権限ポリシーを作成する責任が生まれます。さらに、検証ステージで IAM Access Analyzer による自動的なポリシーの検証を導入することで、セキュリティ上の問題が検出されない場合にのみ作業を進めることができます。このアーキテクチャをアカウントにデプロイする方法について詳しくは、このブログ投稿をご覧ください。このプロセスの Terraform バージョンについては、この GitHub リポジトリをご確認いただくことをお勧めします。

9. 時間の経過とともに過剰な特権を削除する

最小権限を実現する最後の戦略は、既存の権限と、時間とともに過剰な権限を削除する方法に焦点を当てています。付与されている権限に関するデータを分析し、何が使用され、何が使用されていないかを特定することで、どの権限が過剰であるかを判断できます。新しいポリシーを開発している場合でも、後になって有効にした一部の権限が未使用であることがわかる可能性があり、後でそのアクセスを削除できます。これは、今日ポリシーを作成するときに 100% 完璧である必要はなく、時間の経過とともにポリシーを改善できることを意味します。これを支援するために、3 つの推奨事項を簡単に確認します：

1. サービスコントロールポリシー (SCP) を使用して未使用の権限を制限する
2. 未使用のアイデンティティを削除する
3. ポリシーから未使用のサービスとアクションを削除する

まず、このシリーズの パート 1 で説明したように、SCP は、AWS Organizations の組織、AWS アカウントのセット、または単一のアカウントに対して権限を制限できる、幅広いガードレールタイプのコントロールです。まず、SCP で許可されているにもかかわらず、チームで使用されていないサービスを特定することから始められます。また、組織が意図せずに使用しているサービスを特定したくもなるでしょう。その場合、それらのアクセスを制限することを検討し、アカウントで実際に必要とされるサービスへのアクセスのみを維持することができます。これに興味がある場合は、開始するために IAM ドキュメントの Refining permissions in AWS using last accessed information トピックを確認することをお勧めします。

次に、個別のアカウントレベルまたは組織全体のレベルで、未使用の IAM ロール、IAM ユーザーの未使用のアクセスキー、IAM ユーザーの未使用のパスワードをより詳細に特定することに注意を払うことができます。これを行うには、IAM Access Analyzer の未使用のアクセス機能を使用できます。

第三に、同じ未使用のアクセス機能により、付与されているが実際には使用されていない権限をさらに特定し、未使用の権限を削除するという目標を達成できます。IAM Access Analyzer は、未使用の権限に対して調査結果を作成します。付与されたアクセスが必要な意図的なものである場合、調査結果をアーカイブし、同様の調査結果を自動的にアーカイブするアーカイブルールを作成できます。しかし、付与されたアクセスが必要ない場合は、意図しないアクセスを許可するポリシーを変更または削除できます。図 5 は、IAM Access Analyzer の未使用のアクセスアナライザーの調査結果に関するダッシュボードの例です。

お客様と話す際、最小権限の原則は理論上は素晴らしいものの、十分な権限を持つことへ焦点を当てたいという声をよく耳にします。ここで関連する一つのメンタルモデルは 80/20 の法則 (パレートの法則としても知られています) で、これは 80% の結果が 20% の入力 (または努力) から得られるというものです。逆に、残りの 20% の結果を得るには 80% の努力が必要であり、これは追加の努力に対して効果が減少することを意味します。図 6 は、横軸を最大権限 (Max privilege) から完璧な最小権限 (Least privilege) までとしたときに、パレートの原則が最小権限の概念とどのように関連しているかを示しています。

80/20 ルールの権限管理への適用 (既存の権限の改善など) とは、許容可能なリスクの閾値を特定することと、そのリスクを排除するためにさらに努力をしても、得られる効果が次第に小さくなる可能性があることを認識するためです。ただし、最小権限の追求においては、残りの20%に対しても現実的なアプローチを取りながら、引き続き取り組んでいく必要があります。

最小権限は継続的な取り組みであることを忘れないでください。この取り組みを実現可能なものにするための 2 つの方法は、権限を改善する際にフィードバックループを使用することと、優先順位をつけることです。例えば、アカウントやチームにとっての機密性の高さに焦点を当てます。開発環境やテスト環境といったリスクの低い環境のことを考える前に、まずは本番環境のアイデンティティへのアクセスを制限してください。外部のクロスアカウントアクセスを可能にするロールやリソースの権限を確認することを優先し、それからあまり機密性の高くない領域で使用されるロールを検討します。その後、組織の次の優先事項に取り組みます。

まとめ

この 2 部構成のシリーズを読んでいただき、ありがとうございます。この 2 つのブログ投稿では、IAM で最小権限を大規模に実装するための 9 つの戦略を説明しました。これらの 9 つの戦略を通じて、最小権限を展開するために役立ついくつかのメンタルモデル、ツール、機能を紹介しました。権限の設定、検証、および改善のプロセスにおいて活用できる主要なポイントをいくつか考えてみましょう。

クラウド管理者と開発者は権限を設定 (set) し、アイデンティティベースのポリシーまたはリソースベースのポリシーを使用してアクセスを付与できます。また、管理者は複数のアカウントを境界として設定 (set) し、サービスコントロールポリシー (SCP)、アクセス許可の境界、パブリックアクセスのブロック、VPC エンドポイントポリシー、および データ境界 を使用して追加のガードレールを設定 (set) できます。クラウド管理者または開発者が新しいポリシーを作成する際、IAM Access Analyzer ポリシー生成機能を使用して、権限を付与する新しいポリシーを生成できます。

クラウド管理者と開発者は、その後 権限を検証 (verify) します。このタスクでは、IAM Access Analyzer の ポリシー検証とピアレビューの両方を使用して、設定された権限に問題やセキュリティリスクがないかを判断できます。これらのツールは、権限が設定される前の CI/CD パイプラインでも活用できます。IAM Access Analyzer のカスタムポリシーチェックは、ポリシーへの非準拠の更新を検出するために使用できます。

既存のアクセス権限を 検証 (verify) し、時間の経過とともにアクセス権限を改善 (refine) するために、クラウド管理者と開発者は IAM Access Analyzer の外部アクセスアナライザーを使用して、外部エンティティと共有されたリソースを特定できます。また、IAM の最終アクセス情報または IAM Access Analyzer の未使用のアクセスアナライザーを使用して、未使用のアクセスを見つけることもできます。要するに、最小権限への取り組みを効率化するための次のステップをお探しの場合は、ぜひ IAM Access Analyzer をご確認ください。

本ブログは プロフェッショナルサービス本部の 小泉、梅澤 が翻訳しました。