SEC03-BP02 最小特権のアクセスを付与する - AWS Well-Architected フレームワーク
実装のガイダンスリソース

SEC03-BP02 最小特権のアクセスを付与する

特定の条件下で特定のリソースに対する特定のアクションを実行するために、ID が必要とするアクセス許可のみを付与することが、ベストプラクティスです。グループと ID 属性を使用して、個々のユーザーのアクセス許可を定義するのではなく、スケールに応じてアクセス許可を動的に設定します。例えば、デベロッパーのグループに、プロジェクトのリソースのみを管理するためのアクセスを許可することができます。これにより、開発者がプロジェクトを離れると、基盤となるアクセスポリシーに変更を加えることなく、その開発者のアクセスは自動的に取り消されます。

期待される成果: ユーザーに、ジョブの実行に必要なアクセス許可のみが付与されます。ユーザーには、限られた時間内に特定のタスクを実行するためだけに本番環境へのアクセスを付与し、タスクが完了したらアクセスを取り消す必要があります。アクセス許可は、ユーザーが別のプロジェクトまたは職務に移った場合を含め、不要になったときに取り消す必要があります。管理者権限は、信頼できる管理者の少数のグループのみに付与する必要があります。アクセス許可の変化を避けるために、アクセス許可は定期的に見直す必要があります。マシンまたはシステムのアカウントには、タスクを完了するために必要な最小セットのアクセス許可を付与する必要があります。

一般的なアンチパターン:

  • デフォルトでユーザーに管理者アクセス許可を付与する

  • ルートユーザーを日常業務に使用する

  • 過度に寛容でありながら、完全な管理者権限がないポリシーを作成する。

  • 最小特権のアクセスを付与するかどうかを把握するためにアクセス許可を見直していない。

このベストプラクティスを活用しない場合のリスクレベル: 高

実装のガイダンス

最小特権の原則では、特定のタスクを実行するために必要な、最小限のアクションの実行のみを ID に許可する必要があると規定されています。これにより、使いやすさ、効率性、セキュリティのバランスが取れます。この原則の下に運用すると、意図しないアクセスを制限し、誰がどのリソースにアクセスできるかを追跡するのに役立ちます。デフォルトでは、IAM ユーザーやロールにアクセス許可はありません。ルートユーザーにはデフォルトでフルアクセスがありますが、厳密に制御、モニタリングされ、ルートアクセスを必要とするタスクにのみ使用する必要があります。

IAM ポリシーは、IAM ロールまたは特定のリソースに明示的にアクセス許可を付与するために使用します。例えば、アイデンティティベースのポリシーは IAM グループにアタッチでき、S3 バケットはリソースベースのポリシーで制御できます。

IAM ポリシーの作成時に、サービスアクション、リソース、および AWS がアクセスを許可または拒否するために true でなければならない条件を指定できます。AWS は、アクセスの範囲を絞り込むのに役立つさまざまな条件をサポートしています。例えば、PrincipalOrgID 条件キー を使用すると、リクエスタが AWS Organization の一部でない場合にアクションを拒否できます。

CalledVia 条件キーを使用して、AWS Lambda 関数を作成する AWS CloudFormation など、AWS サービスがユーザーに代わって行うリクエストを制御することもできます。異なるポリシータイプを層にして深層防御を確立し、ユーザーの全体的なアクセス許可を制限する必要があります。どのアクセス許可をどのような条件下で付与できるかも制限できます。例えば、アプリケーションチームに対して、構築するシステムに独自の IAM ポリシーを作成することを許可できますが、システムが受け取ることができる最大権限を制限するために、アクセス許可の境界を適用する必要もあります。

実装手順

  • 最小特権ポリシーを実装する: IAM グループおよびロールに最小特権のアクセスポリシーを割り当てて、定義したユーザーのロールまたは機能を反映させます。

    • API の使用状況に基づくポリシー: 必要なアクセス許可を決定する 1 つの方法は、AWS CloudTrail ログを確認することです。このレビューでは、ユーザーが AWS 内で実際に実行するアクションに合わせて、カスタマイズしたアクセス許可を作成できます。IAM Access Analyzer は、アクティビティに基づいて IAM ポリシーを自動生成できます。組織またはアカウントレベルで IAM Access Advisor を使用し、特定のポリシーの最終アクセス情報を追跡できます。

  • ジョブ機能の AWS マネージドポリシーを使用することを検討してください。きめ細かいアクセス許可ポリシーの作成を開始するとき、どこから始めればよいかわからない場合があります。AWS には、請求、データベース管理者、データサイエンティストなど、一般的なジョブロールに対するマネージドポリシーがあります。これらのポリシーは、最小特権ポリシーの実装方法を判断する際に、ユーザーの持つアクセスを絞り込むことができます。

  • 不要なアクセス許可を削除する: 不要なアクセス許可と過度に許可されたポリシーを削除します。IAM Access Analyzer ポリシーの生成は、アクセス許可ポリシーの微調整に役立ちます。

  • ユーザーの本番環境へのアクセスが制限されていることを確認する: ユーザーは、有効なユースケースを持つ本番環境にのみアクセスする必要があります。ユーザーが本番環境へのアクセスが必要な特定のタスクを実行した後で、アクセス許可を取り消す必要があります。本番環境へのアクセスを制限することは、本番に影響する想定外のイベントを回避するのに役立ち、意図しないアクセスの影響範囲を狭めます。

  • アクセス許可の境界を考慮する: アクセス許可の境界は、アイデンティティベースのポリシーが IAM エンティティに付与できるアクセス許可の上限を設定する、マネージドポリシーを使用するための機能です。エンティティのアクセス許可の境界により、エンティティは、アイデンティティベースのポリシーとそのアクセス許可の境界の両方で許可されているアクションのみを実行できます。 

  • アクセス許可のリソースタグを検討する: リソースタグを使用する属性ベースのアクセスコントロールモデルを使用すると、リソースの目的、所有者、環境、その他の基準に基づいてアクセスを許可できます。例えば、リソースタグを使用して、開発環境と本番環境を区別することができます。これらのタグを使用して、開発者を開発環境に制限することができます。タグ付けとアクセス許可ポリシーを組み合わせることで、きめ細かいリソースアクセスを実現することができ、すべての職務に複雑なカスタムポリシーを定義する必要がなくなります。

  • AWS Organizations のサービスコントロールポリシーを使用する。サービスコントロールポリシーは、組織のメンバーアカウントで利用できる最大のアクセス許可を一元管理します。重要なのは、サービスコントロールポリシーでは、メンバーアカウントでルートユーザーのアクセス許可を制限できることです。AWS Organizations を強化する規範的マネージドコントロールを提供する、AWS Control Tower の使用も検討してください。Control Tower 内で独自のコントロールを定義することもできます。

  • 組織のユーザーライフサイクルポリシーを確立する: ユーザーライフサイクルポリシーは、ユーザーが AWS にオンボーディングされたとき、ジョブロールまたはスコープを変更したとき、または AWS へのアクセスが不要になったときに実行するタスクを定義します。アクセス許可レビューをユーザーライフサイクルの各ステップで実行し、アクセス許可が適切に制限されていることを検証して、アクセス許可の変化を回避する必要があります。

  • アクセス許可を見直して不要なアクセス許可を削除する: ユーザーアクセスを定期的に見直して、ユーザーに過剰なアクセス許可がないことを確認する必要があります。AWS Config および IAM Access Analyzer は、ユーザーのアクセス許可を監査する際に役立ちます。

  • ジョブロールマトリックスを確立する: ジョブロールマトリックスは、AWS フットプリント内に必要なさまざまなロールとアクセスレベルを視覚化します。ジョブロールマトリックスを使用して、組織内でのユーザーの責任に基づいてアクセス許可を定義し、分離できます。個々のユーザーまたはロールにアクセス許可を直接適用するのではなく、グループを使用します。

リソース

関連ドキュメント:

関連動画:

関連する例: