SEC03-BP02 最小特権のアクセスを付与する
ユーザーが特定の条件下で特定のリソースに対する特定のアクションを実行するために、必要なアクセス許可のみを付与します。グループと ID 属性を使用して、個々のユーザーのアクセス許可を定義するのではなく、スケールに応じてアクセス許可を動的に設定します。例えば、デベロッパーのグループに、プロジェクトのリソースのみを管理するためのアクセスを許可することができます。これにより、デベロッパーがプロジェクトを離れると、基盤となるアクセスポリシーに変更を加えることなく、そのデベロッパーのアクセスは自動的に取り消されます。
期待される成果: ユーザーには、それぞれの職務に必要な最低限のアクセス許可のみが付与されます。デベロッパーを本番環境から分離するには、別個の AWS アカウント を使用します。デベロッパーが特定のタスクの本番環境にアクセスする必要がある場合、それらのタスクの期間中のみ、管理された制限付きのアクセス許可が付与されます。本番環境へのアクセスは、必要な作業が完了するとすぐに取り消されます。アクセス許可の定期的な見直しを行い、ユーザーがロールを変更したり組織を離れたりするなど、不要になったらすぐに取り消します。管理者権限を信頼できる小さなグループに限定することにより、リスクを最小限に抑えます。マシンまたはシステムのアカウントには、意図したタスクの実行に必要な最小限のアクセス許可のみを付与します。
一般的なアンチパターン:
-
デフォルトで、ユーザーに管理者のアクセス許可を付与する。
-
通常のアクティビティには、ルートユーザーアカウントを使用する。
-
適切な範囲を指定せずに、過度に許容されたポリシーを作成する。
-
アクセス許可のレビューは頻繁に行われないため、アクセス許可のクリープが発生する。
-
環境の分離やアクセス許可の管理には、属性ベースのアクセスコントロールのみに依存している。
このベストプラクティスを活用しない場合のリスクレベル: 高
実装のガイダンス
最小特権の原則では、特定のタスクを実行するために必要な、最小限のアクションの実行のみを ID に許可する必要があると規定されています。これにより、使いやすさ、効率性、セキュリティのバランスが取れます。この原則の下に運用すると、意図しないアクセスを制限し、誰がどのリソースにアクセスできるかを追跡するのに役立ちます。デフォルトでは、IAM ユーザーやロールにアクセス許可はありません。ルートユーザーにはデフォルトでフルアクセスがありますが、厳密に制御、モニタリングされ、ルートアクセスを必要とするタスクにのみ使用する必要があります。
IAM ポリシーは、IAM ロールまたは特定のリソースに明示的にアクセス許可を付与するために使用します。例えば、アイデンティティベースのポリシーは IAM グループにアタッチでき、S3 バケットはリソースベースのポリシーで制御できます。
IAM ポリシーの作成時に、サービスアクション、リソース、および AWS がアクセスを許可または拒否するために true が必須な条件を指定できます。AWS は、アクセスの範囲を絞り込むのに役立つさまざまな条件をサポートしています。例えば、PrincipalOrgID 条件キーを使用すると、リクエスタが AWS Organization の一部でない場合にアクションを拒否できます。
また、CalledVia 条件キーを使用して、AWS Lambda 関数を作成する AWS CloudFormation など、AWS サービスがユーザーに代わって行うリクエストを制御できます。異なるポリシータイプを層にして深層防御を確立し、ユーザーの全体的なアクセス許可を制限できます。どのアクセス許可をどのような条件下で付与できるかも制限できます。例えば、ワークロードチームに対して、構築するシステムに独自の IAM ポリシーを作成することを許可できますが、その場合、付与できるアクセス許可の上限を制限するアクセス許可の境界を適用する必要があります。
実装手順
-
最小特権ポリシーを実装する: IAM グループおよびロールに最小特権のアクセスポリシーを割り当てて、定義したユーザーのロールまたは機能を反映させます。
-
別個の AWS アカウント を使用して開発環境と本番環境を分離する: 開発環境と本番環境には別個の AWS アカウント を使用し、サービスコントロールポリシー 、リソースポリシー、アイデンティティポリシーを使用して、開発環境と本番環境間のアクセスを制御します。
-
API の使用状況に基づくポリシー: 必要なアクセス許可を決定する 1 つの方法は、AWS CloudTrail ログを確認することです。このレビューを使用して、ユーザーが AWS 内で実際に実行するアクションに合わせて、カスタマイズしたアクセス許可を作成できます。IAM Access Analyzer は、アクセスアクティビティに基づいて IAM ポリシーを自動生成できます。組織またはアカウントレベルで IAM Access Advisor を使用し、特定のポリシーの最終アクセス情報を追跡できます。
-
ジョブ機能に AWS マネージドポリシーの使用を検討する: きめ細かいアクセス許可ポリシーの作成を開始する場合は、請求、データベース管理者、データサイエンティストなどの一般的なジョブのロールに AWS マネージドポリシーを使用することを推奨します。これらのポリシーは、最小特権ポリシーの実装方法を決定する際に、ユーザーの持つアクセスを絞り込むことができます。
-
不要なアクセス許可を削除する: 未使用の IAM エンティティ、認証情報、アクセス許可を検出して削除し、最小特権の原則を実現します。IAM Access Analyzer を使用すると、外部アクセスと未使用のアクセスを識別でき、IAM Access Analyzer ポリシーの生成によって、アクセス許可ポリシーのファインチューニングを行いやすくなります。
-
ユーザーの本番環境へのアクセスが制限されていることを確認する: ユーザーは、有効なユースケースを持つ本番環境にのみアクセスする必要があります。ユーザーが本番環境へのアクセスが必要な特定のタスクを実行した後で、アクセス許可を取り消す必要があります。本番環境へのアクセスを制限することは、本番に影響する想定外のイベントを回避するのに役立ち、意図しないアクセスの影響範囲を狭めます。
-
アクセス許可の境界を考慮する: アクセス許可の境界は、アイデンティティベースのポリシーが IAM エンティティに付与できるアクセス許可の上限を設定する、マネージドポリシーを使用するための機能です。エンティティのアクセス許可の境界により、エンティティは、アイデンティティベースのポリシーとそのアクセス許可の境界の両方で許可されているアクションのみを実行できます。
-
属性ベースのアクセス制御とリソースタグを使用したアクセスの絞り込み サポートされている場合、リソースタグを使用した属性ベースのアクセス制御 (ABAC) を使用して、アクセス許可を絞り込むことができます。ABAC モデルを使用して、プリンシパルタグとリソースタグを比較し、定義したカスタムディメンションに基づいてアクセスを絞り込むことができます。このアプローチにより、組織内のアクセス許可ポリシーを簡素化および削減できます。
-
ABAC は、プリンシパルとリソースの両方が AWS Organization によって所有されている場合にのみ、アクセス制御に使用することを推奨します。外部関係者は、自分のプリンシパルとリソースに対して、組織と同じタグ名と値を使用できます。外部のプリンシパルやリソースへのアクセス許可を付与する際に、これらの名前と値のペアのみに依存していると、意図しないアクセス許可を付与してしまう可能性があります。
-
-
AWS Organizations のサービスコントロールポリシーを使用する: サービスコントロールポリシーは、組織のメンバーアカウントで利用できる最大のアクセス許可を一元管理します。重要なのは、サービスコントロールポリシーを使用すると、メンバーアカウントでルートユーザーのアクセス許可を制限できることです。AWS Organizations を強化する規範的マネージドコントロールを提供する、AWS Control Tower の使用も検討してください。Control Tower 内で独自のコントロールを定義することもできます。
-
組織のユーザーライフサイクルポリシーを確立する: ユーザーライフサイクルポリシーは、ユーザーが AWS にオンボーディングされたとき、ジョブロールまたはスコープを変更したとき、または AWS へのアクセスが不要になったときに実行するタスクを定義します。ユーザーのライフサイクルの各段階でアクセス許可のレビューを行い、アクセス許可が適切に制限されていることを検証して、アクセス許可のクリープを回避する必要があります。
-
アクセス許可を見直して不要なアクセス許可を削除する: ユーザーアクセスを定期的に見直して、ユーザーに過剰なアクセス許可がないことを確認する必要があります。AWS Config および IAM Access Analyzer は、ユーザーのアクセス許可を監査する際に役立ちます。
-
ジョブロールマトリックスを確立する: ジョブロールマトリックスは、AWS フットプリント内に必要なさまざまなロールとアクセスレベルを視覚化します。ジョブロールマトリックスにより、組織内でのユーザーの責任に基づいてアクセス許可を定義し、分離できます。個々のユーザーまたはロールにアクセス許可を直接適用するのではなく、グループを使用します。
リソース
関連ドキュメント:
関連動画:
関連する例: