SEC03-BP02 最小特権のアクセスを付与します - AWS Well-Architected Framework
実装のガイダンスリソース

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

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

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

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

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

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

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

  • アクセス許可をレビューして、最小特権アクセスを許可するかどうかを把握しない。

このベストプラクティスが確立されていない場合のリスクレベル: 高

実装のガイダンス

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

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

IAM ポリシーの作成では、AWS がアクセスを許可または拒否するために必要なサービスアクション、リソース、条件を指定できます。AWS では、アクセスを最小限にするために役立つさまざまな条件を用意しています。例えば、依頼者が AWS 組織に属していない場合、PrincipalOrgID 条件キーを使用して、アクションを拒否できます。

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

実装手順

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

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

  • 必要でないアクセス許可を削除する: 必要でないアクセス許可を削除し、過度に寛容なポリシーを削ります。IAM Access Analyzer ポリシー生成は、アクセス許可ポリシーの微調整に役立ちます。

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

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

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

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

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

  • アクセス許可をレビューする定期的スケジュールを確立し、不要なアクセス許可を削除する: ユーザーアクセスを定期的にレビューして、過度に寛容なアクセスがないことを検証する必要があります。AWS Config および IAM Access Analyzer は、ユーザーアクセス許可を監査するときに役立ちます。

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

リソース

関連するドキュメント:

関連動画:

関連する例: