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

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

最小権限は、Amazon Web Services (AWS) のお客様にとって重要なセキュリティの論点です。以前のブログ投稿では、最小権限ポリシーの記載方法について実践的なアドバイスを提供しました。ぜひご覧いただくことをお勧めします。自分のためだけに少数の最小権限ポリシーを書くことには慣れていても、数千人の開発者や数百の AWS アカウントに拡張するには、必要な労力を最小限に抑えるための戦略が必要になります。

re:Inforce 2022 では、最小権限を広く実現するための 9 つの戦略をご紹介しました。戦略が変わるわけではありませんが、本ブログシリーズでは一部の戦略についてより深く議論し、更新された内容を提供します。また、アプリケーションやインフラストラクチャのアイデンティティではなく、AWS Identity and Access Management (IAM) のみに焦点を当てています。AWS における最小権限について、9 つの戦略それぞれについて詳しく説明した後、重要なポイントをおさらいします。パート 1 では最初の 5 つの戦略を取り上げ、パート 2 では残りの 4 つの戦略を取り上げます。

最小権限の概要

最小権限の原則とは、ユーザーやシステムに必要なタスクを完了するために最小限の権限のみを付与するという概念を指します。理想的ではありますが、常に変化を伴う場合、そう簡単ではありません (スタッフやユーザーが代わり、システムが変わり、新しい技術が利用可能になります)。AWS は継続的に新しいサービスや機能を追加しており、あなたのチームのメンバーはそれらを採用したいと思うかもしれません。ユーザーに割り当てられたポリシーが完全に最小権限である場合、ユーザーがより多くの、または異なるアクセスを要求するたびに、権限を常に更新する必要があります。多くの場合、最小限の権限セットを適用することは制限が厳しすぎる可能性があります。皮肉なことに、完全な最小権限は最大の労力を伴う可能性があります。

そこで、より実用的なアプローチを見つけたいと思います。まず、図 1 に示すように、“Things you don’t want (望まないこと) “ と ”Things you do want (実現したいこと) “ という 2 つの相反する目標があることを認識しなければなりません。例えば、高価なリソースが作成されることは望みませんが、ビルダーに対してはリソース選択の自由度を持たせたいと考えています。

Figure 1: Tension between two competing goals

図 1：相反する2つの目標

最小権限について考える際、目標が相反することは自然なことです。そして、安全性を確保しつつ俊敏性を確保するためには多くのコントロールを利用することができます。この話題について何百ものお客様と話をしてきましたが、多くのお客様は主に、ビルダーやマシンに割り当てるほぼ完璧な許可ポリシーを作成することに焦点を当て、力ずくで最小権限を実現しようとしています。

しかし、そのアプローチはあまり効果的ではありません。では、どこから始めるべきでしょうか？この質問に答えるために、戦略、ツール、メンタルモデルという 3 つの要素に分解していきます。最初の 2 つは明確かもしれませんが、「メンタルモデルとは何か」と疑問に思うかもしれません。メンタルモデルは、複雑なものを比較的単純なものとして概念化するために使用します。ただし、当然ながらこの単純化されたモデルでは一部の情報が省略されることがあります。

チーム

チームは通常、組織の規模によって異なります。それぞれのお客様が独自の特性を持ち、企業、政府機関、スタートアップなど、ニーズが多様であることも認識しています。以下のシナリオが現在のあなたに当てはまらない、あるいはこれほど多くのチームが共存するような大きな組織ではないと感じる場合は、組織の成長に伴って将来的にこれらのシナリオに直面する可能性があります。それでは、最小権限を検討する前に、いくつかの一般的なシナリオを考えてみましょう。

クラウドで運用を行うお客様内のチームは、通常、分散型と集中型の 2 つのカテゴリーのいずれかに分類される傾向があります。分散型チームは、クラウド環境で作業する開発者や開発者グループ、オペレーター、請負業者などです。集中型チームは多くの場合、管理者で構成されています。例えば、クラウド環境チーム、インフラストラクチャチーム、セキュリティチーム、ネットワークチーム、ID 管理チームなどが挙げられます。

シナリオ

組織内で最小権限を効果的に実現するには、チーム間の連携が不可欠です。以下の 3 つの一般的なシナリオを考えてみましょう：

デフォルトのロールとポリシーの作成 (各チーム用とモニタリング用)
アプリケーション用のロールとポリシーの作成
既存の権限の検証と改善

最初のシナリオは、AWS の使用を開始するために必要な基本的な役割と権限のセットに焦点を当てています。集中型チーム (クラウド環境チームや ID 管理チームなど) は、アカウントファクトリー、AWS IAM Identity Center、または AWS Control Tower を使用してデプロイする、初期のデフォルトのロールとポリシーを通常作成します。これらのデフォルトの権限は、通常、ビルダーのフェデレーションを有効にしたり、監視やデプロイのためのツール等に関する一部の自動化を可能にしたりします。

2 つ目のシナリオでは、アプリケーション用のロールとポリシーを作成します。基本的なアクセスと権限が確立された後、次のステップではビルダーがクラウドを使用して構築を始めます。分散型チーム (ソフトウェア開発者、オペレーター、または請負業者) は、シナリオ 1 で作成したロールとポリシーを使用して、機能を実行するために独自の権限が必要なシステム、ソフトウェア、またはアプリケーションを作成します。これらのチームは、多くの場合、データベース、Amazon Simple Storage Service (Amazon S3)、Amazon Simple Queue Service (Amazon SQS) 、その他のリソースと通信するために、開発したソフトウェア用の新しいロールとポリシーを作成する必要があります。

最後に、3 つ目のシナリオは、既存の権限を検証し、改善することです。これは両方のチームが責任を持つべきタスクです。

最小権限のジャーニー

AWS では、常に変化を伴うことから、最小権限をジャーニーと表現することがあります。開発者が変わったり、システムが変わったり、使用するサービスを変更したり、使用しているサービスに新機能が追加されて、チームがより迅速かつ効率的な作業を行うために採用したいと考えたりすることがあります。つまり、今の時点で最小権限と考えていることが、明日にはユーザーにとって不十分と見なされる可能性があるのです。

このジャーニーは、権限の設定、検証、改善のライフサイクルで構成されています。クラウド管理者と開発者は権限を設定 (Set) し、次にその権限を検証 (Verify) し、そして時間の経過とともにそれらの権限を改善 (Refine) します。このサイクルは図 2 に示すように繰り返され、継続的な改善のフィードバックループが生まれることで、最小権限へのジャーニーが完成します。

Figure 2: Least privilege is a journey

図 2：最小権限へのジャーニー

最小権限を実装するための戦略

以下のセクションでは、大規模な最小権限の実装に関する 9 つの戦略について詳しく説明します：

パート 1 (本ブログ) :

(計画) 全体的な制御から着手する
(計画) アカウントをリソースの強力な境界として使用する
(計画) 短期的な認証情報を優先的に使用する
(ポリシー) 広範なセキュリティ不変条件を強制する
(ポリシー) 業務に適切なツールを特定する

パート 2：

(ポリシー) 開発者がアプリケーションポリシーを作成できるようにする
(プロセス) 適切に記述されたポリシーを維持する
(プロセス) ポリシーのピアレビューと検証を行う
(プロセス) 時間の経過とともに過剰な特権を削除する

議論の論理構造として、これらの戦略を計画、ポリシー、プロセスの 3 つのカテゴリーにグループ化しています。計画では、目標と達成したい成果を検討し、それらの成果を簡素化するようにクラウド環境を設計します。ポリシーでは、これらの目標の一部を IAM ポリシーまたはコード (例：Infrastructure as Code ) として実装するための方法論に焦点を当てています。プロセスでは、継続的な改善のための反復的なアプローチを検討します。それでは始めましょう。

1. 全体的な制御から着手する

ほとんどのシステムには関係性があり、これらの関係性は視覚化することができます。例えば、AWS アカウントの関係性は、図 3 に示すように、組織の管理アカウントとその階層内の AWS アカウントのグループ、そしてそれらのアカウント内のプリンシパルとポリシーという階層構造として視覚化できます。

Figure 3: Icicle diagram representing an account hierarchy

図 3：アカウント階層のイメージ図

最小権限について議論する際は、階層の最下層にあるポリシーに過度に焦点を当ててしまうことがありますが、大規模に最小権限を実装するためには、逆転の発想が必要です。この戦略では全体的な制御に焦点を当てています。これは、トップレベルで用いる広範な制御セットを指しています。広範な制御の例として、マルチアカウント戦略、サービスコントロールポリシー、パブリックアクセスのブロック、データ境界などがあります。

全体的な制御を実装する前に、どの制御が達成したい結果に沿っているのかを検討する必要があります。関連する全体的な制御が整ったら、階層を下るにつれてより詳細な制御を使用することで、権限を調整できます。次の戦略では、我々が推奨する最初の全体的な制御について説明します。

2. アカウントをリソースの強力な境界として使用

単一の AWS アカウントから始めることもできますが、マルチアカウント戦略を採用することをお勧めします。お客様がクラウドの利用を続けるにつれて、明確なセキュリティ境界、制限を統制する能力、請求の分離が必要になることがよくあります。AWS アカウントに設計された分離機能は、これらのニーズを満たすのに役立ちます。

お客様は、AWS Organizations を使用して、個別のアカウントをさまざまなグループ (組織単位) にまとめることができます。お客様は、環境 (例: 開発、ステージング、テスト、本番) やビジネスユニット、コストセンター、あるいはその他のオプションに基づいてこのグループ化を行うことを選択する場合があります。組織の構成は自由に選択できます。AWS は、お客様がマルチアカウント戦略を採用する際に役立つ規範的なガイダンスを提供しています。

同様に、このアプローチをセキュリティコントロールのグループ化にも使用できます。予防または検出コントロールを階層化する際、それらを適用するアカウントグループを選択できます。これらのアカウントをどのようにグループ化するかを考える際は、権限に影響を与える可能性のあるセキュリティコントロールをどこに適用したいかを検討してください。

AWS アカウントは、アカウント間 (およびそれらのアカウント内に存在するエンティティ間) に強力な境界を提供します。図 4 に示すように、デフォルトではこれらのプリンシパルとリソースはアカウントの境界 (左側の赤い点線で表されています) を越えることができません。

Figure 4: Account hierarchy and account boundaries

図 4：アカウントの階層とアカウントの境界

これらのアカウントが互いに通信するためには、限定的な権限を追加して明示的にアクセスを有効にする必要があります。クロスアカウントのリソース共有や、クロス VPC ネットワーキング、クロスアカウントのロール引き受けなどのユースケースでは、必要な権限を作成して明示的に必要なアクセスを有効にする必要があります。その後、IAM Access Analyzer を使用してこれらの権限をレビューできます。

IAM Access Analyzer 内の 1 つのアナライザータイプである外部アクセスは、組織やアカウント内のリソース (S3 バケット、IAM ロール、SQS キュー、その他）が外部エンティティと共有されているかを特定するのに役立ちます。これにより、組織のセキュリティリスクを引き起こす可能性がある意図しないアクセスを識別できます。IAM Access Analyzer (外部アクセス) は単一のアカウントでも使用できますが、組織レベルでの使用をお勧めします。組織を信頼ゾーンとして設定することで、組織全体のアクセスアナライザーを構成し、組織外からのアクセスを許可している箇所を特定できます。

初めに、アナライザーを作成すると、権限の分析が始まります。分析の結果、検出結果が生成され、意図したアクセスなのか意図しないアクセスであるかをレビューできます。意図したアクセスの検出結果はアーカイブできますが、意図しないアクセスについては、セキュリティリスクを軽減するために迅速に対処する必要があります。

要約すると、アカウントをリソースの強力な境界として使用し、IAM Access Analyzer を利用して想定を検証し、アカウントの境界を越える想定外のアクセス許可を自動化された方法で見つける必要があります。

3. 短期的な認証情報を優先的に使用する

アクセス制御に関しては、短期間であることが望ましいです。プレーンテキストで保存されたり、誤って共有されたりする可能性のある長期的なアクセスキーやパスワードと比較して、短期的な認証情報は強固な識別子を使用して動的にリクエストされます。認証情報は動的にリクエストされるため、一時的であり、自動的に期限切れになります。したがって、認証情報を明示的に取り消したりローテーションしたりする必要はなく、アプリケーション内に埋め込む必要もありません。

IAM の文脈では、短期的な認証情報について議論する場合、実質的に IAM ロールについて話しています。短期的な認証情報の適用可能なユースケースは、ビルダー向けの短期的な認証情報とアプリケーション向けの短期的な認証情報の 2 つのカテゴリに分けることができます。

ビルダー (人間のユーザー) は多くの場合、AWS クラウドを 2 つの方法のいずれかで操作します。1 つは AWS マネジメントコンソール経由、もう 1 つは AWS CLI 経由でプログラム的に実行します。コンソールアクセスの場合、ID プロバイダーから個々の AWS アカウントへの直接フェデレーション、または IAM Identity Center を通じてより一元化された方法を使用できます。ビルダーがプログラムからアクセスする場合、AWS CLI を使用して IAM Identity Centerを通して AWS アカウントへの短期的な認証情報を取得できます。

ビルダーが作成したアプリケーションにも、独自の権限が必要です。通常、アプリケーションの短期的な認証情報を考える場合、Amazon Elastic Compute Cloud (Amazon EC2) の IAM ロール、Amazon Elastic Container Service (Amazon ECS) タスクの IAM ロール、または AWS Lambda 実行ロールなどの機能を考えます。また、IAM Roles Anywhere を使用して、AWS 外部で実行されるワークロードやアプリケーションの一時的なセキュリティ認証情報を取得することもできます。クロスアカウントアクセスが必要なユースケースでも、短期的な認証情報を付与するために IAM ロールを使用できます。

しかし、組織にはデータベースの認証情報のような、どこかに保存する必要がある長期的なシークレットがあるかもしれません。これらのシークレットは AWS Secrets Manager に保存でき、AWS KMS 暗号化キーを使用してシークレットを暗号化できます。さらに、これらの長期的なシークレットのリスクを軽減するために、シークレットの自動ローテーションを設定することができます。

4. 広範なセキュリティ不変条件を強制する

セキュリティ不変条件は、お客様のビジネスや組織などにおいて常に真であるセキュリティの条件です。例えば、ある組織が強制したい主要なセキュリティ条件をいくつか特定したとします：

AWS アカウントのルートユーザーへのアクセスをブロックする
使用していない AWS リージョンへのアクセスを無効にする
AWS のログ記録および監視サービス (AWS CloudTrail や Amazon CloudWatch) の無効化を防止する

これらの条件は、組織レベルでサービスコントロールポリシー (SCP) を使用して、組織単位 (OU) を用いてアカウントのグループに対して、または個々のメンバーアカウントに対して有効にすることができます。

これらの言葉に注目してください — ブロック、無効化、防止。これらのアクションを、管理者を除く、すべてのユーザーやすべてのプリンシパルの文脈で検討している場合、そこから広範なセキュリティの不変的な条件の実装を始めることになります。一般的にはサービスコントロールポリシーを使用します。しかし、お客様にとってよくある課題は、適用すべき条件とその範囲を特定することです。これは、使用しているサービス、組織の規模、チームの数、組織が AWS クラウドをどのように利用しているかによって異なります。

一部のアクションは本質的にリスクが高く、一方でごくわずかなリスクしかないものや、より簡単に元に戻せるものもあります。これらの問題を検討する際に役立つメンタルモデルの 1 つが、図 5 の例に示すような XY グラフです。

Figure 5: Using an XY graph for analyzing potential risk versus frequency of use

図 5：XYグラフを使用して潜在的なリスクと使用頻度を分析する

このグラフの X 軸は、特定のアカウントまたは環境内でサービスの機能を使用することに関連する潜在的なリスクを表し、Y 軸はそのサービスの機能の使用頻度を表しています。この代表的な例では、グラフの左上部分は頻繁に実行され、比較的安全なアクション (例えば、読み取り専用のアクション) をカバーしています。

右下の領域の機能に時間を集中してみましょう。自分の環境で同様のグラフを作成するとしたら、環境内で高リスクであり、使用頻度が低いまたはまれだと考えられるアクションは何でしょうか？例えば、ログ記録のために CloudTrail を有効にする場合、誰かが CloudTrail の StopLogging API オペレーションを呼び出したり、CloudTrail ログを削除したりしないようにする必要があります。高リスクで使用頻度の低い別の例としては、AWS Direct Connect やネットワーク設定の変更をネットワーク管理者のみに制限することが挙げられます。

時間の経過とともに、XY グラフのメンタルモデルを使用して、決して起こってはならないアクションに対する予防的ガードレールと、状況に応じた使用ケースに対する条件付きまたは代替のガードレールのどちらを使用するかを判断できます。また、ユーザーペルソナや環境タイプ (本番、開発、テスト) などの要因を考慮しながら、予防的セキュリティコントロールから検出的セキュリティコントロールへ移行することもできます。最後に、機能ごとによりきめ細かく検討する前に、この演習をサービス単位で広く実行することを検討できます。

しかし、すべてのコントロールを組織独自のものにする必要はありません。迅速に開始するために、ドキュメント化された SCP の例やAWS Control Tower ガードレールのリファレンスが用意されています。これらをそのまま採用するか、必要に応じて環境に合わせて調整することができます。

5. 業務に適切なツールを特定する

IAM は、さまざまな種類の価値を提供する多くのツールを備えたツールボックスと考えることができます。これらのツールは、大きく 2 つのカテゴリに分類できます。ガードレールとアクセス許可です。

ガードレールは、アカウントへのアクセスを制限または拒否するのに役立つツールのセットです。概念的には、維持すべき権限の範囲を定義するのに役立ちます。SCP はガードレールの良い例です。なぜなら、アカウントや組織内のプリンシパルが実行できるアクションの範囲を制限できるからです。アクセス許可の境界も優れた例です。新しいアイデンティティに対して最大となる権限の範囲を設定することで、新しいプリンシパル (ロールまたはユーザー) と権限の作成を安全に委任できるからです。

ガードレールはアクセスを制限するのに役立ちますが、本質的にアクセスを許可するものではありません。アクセスを許可するには、アイデンティティベースのポリシーまたはリソースベースのポリシーのいずれかを使用します。アイデンティティベースのポリシーはプリンシパル (ロールまたはユーザー) にアタッチされ、リソースベースのポリシーは S3 バケットなどの特定のリソースに適用されます。

一般的な疑問として、アクセスを許可する際にアイデンティティベースのポリシーとリソースベースのポリシーのどちらを使用するべきかがあります。IAM は、端的に言えば、誰が何にアクセスできるのか？という問いに答えることを目的としています。以下のポリシー例のニュアンスの違いがわかりますか？

プリンシパルにアタッチされたポリシー

{
      "Effect": "Allow",
      "Action": "x",
      "Resource": "y",
      "Condition": "z"
    }

リソースにアタッチされたポリシー

{
      "Effect": "Allow",
      "Principal": "w",
      "Action": "x",
      "Resource": "y",
      "Condition": "z"
    }

ここでの主な違いは次の点です。アイデンティティベース (プリンシパル) ポリシーでは、プリンシパルは暗黙的です (つまり、ポリシーのプリンシパルはポリシーが適用されるエンティティです)。一方、リソースベースのポリシーでは、プリンシパルは明示的でなければなりません (つまり、プリンシパルはポリシーで指定する必要があります)。リソースベースのポリシーは、リソースへのクロスアカウントアクセスを可能にしたり (あるいはリソースを事実上パブリックにしたりする) ことができますが、アイデンティティベースのポリシーも同様に、そのクロスアカウントリソースへのアクセスを許可する必要があります。十分な権限を持つアイデンティティベースのポリシーは、「共有された」リソースにアクセスできます。つまり、プリンシパルとリソースの両方に十分なアクセス許可がされる必要があります。

アクセス許可について考える際、アイデンティティベースのポリシーに焦点を当てることで「誰が」という観点に、リソースベースのポリシーに焦点を当てることで「何を」という観点に対応できます。この話題についてさらに詳しく知りたい場合は、このブログ記事をご覧ください。ガードレールとアクセス許可がどのように評価されるかについては、ポリシー評価ロジックのドキュメントをご確認ください。

最後に、適切なツールを選択するための詳細な手順が必要な場合は、IAM policy types: How and when to use them のブログ記事をお読みいただくことをお勧めします。

まとめ

このブログ投稿では、大規模に最小権限を実現するための 9 つの戦略のうち、最初の 5 つについて説明しました。残りの 4 つの戦略については、このシリーズのパート 2 をご覧ください。

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

Cookie の設定を選択する

Amazon Web Services ブログ