助け合いフォーラム

AWS

AWS ソリューションアーキテクト - アソシエイト(SAA-C03)
問題ID : 30453
問題を開く
Amazon S3にあるバケット「bucket-pingt」を管理するためのIAMポリシーを作成したい。このポリシーでは、オブジェクトの一覧表示、取得、削除を許可するが、アップロードは許可しない。この要件を満たすIAMポリシーとして、適切なものはどれか。

正解

解説

IAMのポリシーは、AWSリソースへのアクセスに対する権限を定義したものです。ポリシーはJSON形式のテキストで定義され、ユーザーやグループ、ロール、AWSリソースに対して、必要なアクセス権限の付与や制限ができます。
下記はJSON形式の定義例です。


Effect、Action、Resource ごとに、複数ある場合は "[]" のブロックで指定します。また、任意の値を示す場合は「*(アスタリスク)」で指定できます。上の図の「bucket-pingt/*」は「bucket-pingt」バケット配下の全てのオブジェクトが対象となります。

Resourceの記述はARN(Amazon Resource Name)形式で記述します。

階層表示が可能なリソースはスラッシュ(/)で区切って指定します(例:S3バケットの場合「bucket/folder/file」など)。また、S3バケット名などグローバルに一意なリソースは、リージョンやアカウントIDを省略できます。

設問の条件を確認します。
・S3バケット「bucket-pingt」の管理用IAMポリシーである
・オブジェクトの一覧表示、取得および削除は行うがアップロードは行わない

Amazon S3の代表的なアクションは以下の通りです。


アクセス対象のバケットを参照(一覧表示)するには、バケット「bucket-pingt」に対するアクション「ListBucket」を許可します。オブジェクトの取得および削除を行うという条件は、バケット「bucket-pingt/*」に対する「GetObject」「DeleteObject」を許可します。

従って正解は

です。


「s3:ListBucket」「s3:GetObject」「s3:DeleteObject」がすべて同じリソース「arn:aws:s3:::bucket-pingt/*」に対して行われてしまっているため、誤りです。
「ListBucket」はバケット内のオブジェクト「bucket-pingt/*」ではなく、バケットそのもの「bucket-pingt」に対して設定する必要があります。


設問中の条件「アップロードは行わない」という条件により、「s3:PutObject」は許可されてはいけません。よって、誤りです。


アクション「s3:ListBucket」が含まれないため誤りです。

学習テキスト

【AWS IAM(Identity and Access Management)】
AWS IAM(Identity and Access Management)は、AWSリソースへのアクセスを管理するためのサービスです。IAMでは「誰が」「どのリソースに対して」「どの操作を許可または制限するか」を定義し、認証と認可のプロセスを提供します。適切なIAM設定と運用により、認証情報の漏洩による被害を最小限に抑えることや、ユーザー操作によるEC2インスタンスの誤削除などの事故を防ぐことが可能です。AWSはIAMの機能を無料で提供しています。
なお、AWSサービスとは「Amazon EC2」や「Amazon S3」などサービス自体のことを指し、AWSリソースとは「EC2インスタンス」や「S3バケット」などサービス内で動作するリソースのことを指します。

IAMでは、AWSリソースへのアクセス権限を「ポリシー」として定義します。ポリシーは、IAMユーザー(IAMグループ)やIAMロール、一部のAWSリソースにアタッチ(付与)やデタッチ(剥奪)が可能です。IAMユーザーやAWSリソースは、アタッチされているポリシーが許可する範囲内でのみ操作を実行できます。ポリシーで許可されていない操作は実行できません。


【AWSアカウント】
AWSアカウントは可能な限り構築する環境(例えば本番環境、開発環境など)ごとに作成します。複数のアカウントで各環境のリソースを分離することで、管理対象のリソースを把握しやすくなり、リソース管理が効率化されます。また、ある環境でセキュリティ問題が発生しても、他の環境への影響を最小限に抑えられるため、全体的なセキュリティが向上します。

【ユーザーの種類】
AWSで利用する代表的なユーザーには、「AWSアカウントのルートユーザー」と「IAMユーザー」があります。


■AWSアカウントのルートユーザー
AWSアカウントを作成すると、そのアカウントに対して最初に存在する特権ユーザーとして、AWSアカウントのルートユーザーが作成されます。ルートユーザーは、アカウント内のすべてのAWSサービスとリソースに完全にアクセスできる、非常に強力な権限を持つユーザーです。そのため、日常的な操作には使用せず、ルートユーザーでしか実行できない操作に限定して使用することが、AWSのベストプラクティスとして推奨されています。
ルートユーザーの運用においては、強力なパスワードにするなど、厳格なセキュリティ対策が必要です。また、ルートユーザーのアクセスキーは、不正利用防止のため作成しないことが推奨されています。

■IAMユーザー
IAMユーザーは、AWSアカウント内で作成するユーザーです。IAMユーザーには、IAMポリシーを使用して必要な権限を付与できます。IAMユーザーは複数人で共有せず、利用者ごとに個別に作成します。
人間のユーザーがAWSへアクセスする方法には、IAMユーザーを使用する方法のほか、IAM Identity Center(複数のAWSアカウントやアプリケーションへのアクセスを一元管理するサービス)やIDプロバイダーとのフェデレーション(外部の認証システムと連携してAWSへアクセスする仕組み)を利用する方法もあります。IAM Identity Centerやフェデレーションを利用すると、一時的な認証情報を使用してAWSへアクセスできます。
AWSへのアクセス権限を付与する際は、最小権限の原則に基づいて必要な操作だけを許可します。最小権限の原則とは、ユーザーやプログラムが作業を遂行するために必要な最小限のアクセス権限を付与することです。

〇IAMグループ(複数のIAMユーザーの管理)
複数のIAMユーザーが所属するグループを「IAMグループ」といいます。IAMグループは、同一アカウント内の複数のIAMユーザーのアクセス権限をまとめて管理するために使用します。なお、IAMユーザーは複数のIAMグループに所属できますが、IAMグループは別のIAMグループに所属できないので、IAMグループを用いた階層的な権限管理は実現できません。


【認証情報】
AWSサービスへアクセスする際は、利用方法に応じてパスワード、アクセスキー、一時的なセキュリティ認証情報などを使用します。

○パスワード ... パスワードは、主にマネジメントコンソールにサインインするときに使用します。ルートユーザーは、AWSアカウントの作成時に登録したメールアドレスとパスワードを使用してサインインします。IAMユーザーはアカウントIDまたはアカウントエイリアス、IAMユーザー名、パスワードを使用してサインインします。アカウントIDは、AWSアカウントを識別する12桁の番号です。アカウントエイリアスは、アカウントIDの代わりに使用できる覚えやすい名前です。IAMユーザー名は、AWSアカウント内で各IAMユーザーを識別するための名前です。

○アクセスキー ... アクセスキーは、アクセスキーIDとシークレットアクセスキーで構成される認証情報です。AWS CLIやAWS SDKなどを使用して、AWSサービスにプログラムでアクセスするときに使用します。
アクセスキーは長期的な認証情報であるため、不要なアクセスキーは削除し、使用する場合も適切に管理する必要があります。可能な限りアクセスキーのような長期的な認証情報ではなく、IAMロールなどによる一時的なセキュリティ認証情報を使用することが推奨されています。やむを得ず使用する場合は、定期的にローテーション(更新)を行う必要があります。

○STSによる一時的なセキュリティ認証情報 ... AWS STS(AWS Security Token Service)は、一時的なセキュリティ認証情報を発行するサービスです。一時的なセキュリティ認証情報には有効期限があり、アクセスキーID、シークレットアクセスキー、セッショントークンで構成されます。IAMロールを引き受ける場合などに使用され、長期的なアクセスキーを保存せずにAWSリソースへアクセスできます。

【IAMロール】
IAMロールは、AWSサービス、アプリケーション、他のAWSアカウントなどに対して、AWSリソースへのアクセス権限を一時的に付与する際に利用します。IAMロール自体は長期的な認証情報を持たず、ロールを引き受けたエンティティ(AWSリソースへアクセスするユーザー、AWSサービス、アプリケーションなどの主体)に対して一時的なセキュリティ認証情報が発行されます。
IAMロールを作成する際は、信頼されたエンティティとして、まずそのロールを引き受ける対象を指定します。その後、そのエンティティに付与するアクセス権限を設定します。


■AWSサービスやアプリケーションに対してアクセス権限を付与
AWSリソースは、ユーザーからアクセスされるほか、AWSサービスやアプリケーションからもアクセスされます。例えば、EC2インスタンス上で実行されるアプリケーションがS3バケットにアクセスする場合、アクセスキーをアプリケーションコードや設定ファイルに直接保存する方法は、認証情報漏洩のリスクがあるため推奨されません。
このような場合は、EC2インスタンスにIAMロールを関連付け、アプリケーションが一時的なセキュリティ認証情報を使用してS3バケットへアクセスできるようにします。一時的なセキュリティ認証情報には有効期限があるため、長期的なアクセスキーを保存する場合と比べて、認証情報漏洩時のリスクを抑えられます。


○インスタンスプロファイル
インスタンスプロファイルは、EC2インスタンスにIAMロールを関連付けるために使用される入れ物のようなものです。EC2インスタンスは、関連付けられたインスタンスプロファイルを通じてIAMロールの一時的な認証情報を取得し、そのIAMロールに付与された権限でAWSサービスにアクセスします。IAMコンソールでEC2インスタンス用のIAMロールを作成すると、対応するインスタンスプロファイルが自動的に作成されます。AWS CLIやAPIで作成する場合は、インスタンスプロファイルを別途作成し、IAMロールと関連付ける必要があります。


■オンプレミスや他クラウドからAWSリソースへアクセスする場合
オンプレミスのサーバーや他クラウド上のアプリケーションからAWSのリソースにアクセスさせたい場合は、IAM Roles Anywhereを利用します。IAM Roles Anywhereでは、公開鍵基盤(PKI)で管理されているX.509証明書に基づいて一時的なセキュリティ認証情報を取得できるため、長期的なアクセスキーを保存する必要がなく、安全にAWS APIへアクセスできます。また、IAMロールの信頼ポリシーでIAM Roles Anywhereを信頼されたエンティティとして指定することで、既存の証明書管理プロセスを活用しながら、セキュリティと利便性を両立できます。

[IAM Roles Anywhereの設定画面]


【ポリシー】
ポリシーは、AWSリソースへのアクセスに対する権限を定義したものです。ポリシーはJSON形式のテキストで定義され、ユーザーやグループ、ロール、AWSリソースに対して、必要なアクセス権限の付与や制限ができます。ポリシーを適切に設定することで、AWSリソースへのセキュアなアクセス制御を実現できます。


■ポリシーの種類
○IDベースのポリシー(IAMポリシー)
IDベースのポリシーは、IAMユーザー、IAMグループ、IAMロールにアタッチするポリシーです。
IDベースのポリシーには以下の種類があります。

AWS管理ポリシーでは必要な権限を付与できない場合に、カスタマー管理ポリシーを作成して使用します。
インラインポリシーは、特定のIAMユーザー、IAMグループ、IAMロールに直接埋め込むポリシーです。特定の対象に強く紐づくため、管理が煩雑になりやすく、通常はカスタマー管理ポリシーの利用が推奨されます。

○リソースベースのポリシー
リソースベースのポリシーは、S3バケットなど一部のAWSリソースに直接アタッチするポリシーです。リソース自体にアクセス制御を定義できます。

「IDベースのポリシー(IAMポリシー)」と「リソースベースのポリシー」には次のような違いがあります。


■ポリシーの構成要素
ポリシーは主に次の要素で構成されます。
・Effect:許可または拒否の指定
・Action:AWSリソースに対して実行できる操作(例:s3:PutObject)
・Resource:Actionの対象とするAWSリソース(例:特定のS3バケット)
・Principal:権限のリクエスト元(例:特定のIAMユーザー)
・Condition:ポリシーが適用される条件(例:特定のIPアドレス範囲からのアクセス)

[リソースベースのポリシーの記述例]

Effect、Action、Resourceごとに、複数ある場合は "[]" のブロックで指定します。また、任意の値を示す場合は「*(アスタリスク)」で指定できます。上の図の「bucket-pingt/*」は「bucket-pingt」バケット配下の全てのオブジェクトが対象となります。全てのリソースを対象にする場合は「"Resource":"*"」と指定し、あらゆる書き込みアクションを指定したい場合は「PutObject*」と指定します。(「PutObject」に加えて「PutObjectAcl」「PutObjectTagging」なども含むようになります)

下記は代表的なアクションの例です。
・Amazon EC2

・Amazon S3


Resourceの記述はARN(Amazon Resource Name)形式で記述します。

階層表示が可能なリソースはスラッシュ(/)で区切って指定します(例:S3バケットの場合「bucket/folder/file」など)。また、S3バケット名などグローバルに一意なリソースは、リージョンやアカウントIDを省略できます。

Conditionは必須の要素ではありませんが、使用することでポリシーを適用する条件を指定できます。Conditionは下記の形式で記述します。


以下は代表的な条件の例です。


■Permissions Boundary(アクセス許可境界)
Permissions Boundary(アクセス許可境界)は、IAMユーザーやIAMロールの操作可能範囲を限定し、「指定された範囲内でのみ操作が可能」という制約を設ける機能です。この制約により、設定された範囲とIAMポリシーによって許可されたアクションのみが実行可能となります。


Permissions Boundaryの使用例として、開発者がEC2インスタンス上のアプリケーションに関わる作業を行う際には、必要なリソースへのアクセス権を柔軟に設定できるようにしたい場合があります。一方で、開発者が自身のアクセス権を変更することは望ましくありません。Permissions Boundaryを適用することで、開発者に必要な作業権限は与えつつも、組織のセキュリティポリシーに反する権限の乱用を防止できます。これにより、管理者の介入なしに開発者が作業を進められると同時に、セキュリティリスクも抑えられます。

【認証情報レポート】
IAMの認証情報レポートとは、AWSアカウント内に存在するIAMユーザーの一覧と各種認証情報のステータスが出力されたCSVファイルのことです。認証情報レポートは、アカウントのセキュリティ状態を監査、検証、および改善する際に役立ちます。

IAMの認証情報レポートに出力される情報には、主に以下の項目があります。
・ユーザーが作成された日時
・パスワードが使用された直近の日時
・パスワードが更新された直近の日時
・多要素認証(MFA)が有効または無効
・アクセスキーが有効または無効
・アクセスキーが使用された直近の日時
・アクセスキーが更新された直近の日時

【IAM Access Analyzer】
AWS IAM Access Analyzerは、AWSリソースのアクセス権限を継続的に監視・分析するサービスです。最小権限の原則に基づき、適切なアクセス制御の実現を支援します。
IAM Access Analyzerの主な機能は以下の通りです。

■外部アクセス分析(リソースベースポリシーの分析)
組織外に対する意図しないアクセス許可設定を検出する機能です。サービス有効化時に設定する「信頼ゾーン」(組織またはAWSアカウント)を基準として、信頼ゾーン外からのアクセスを「外部アクセス」として識別します。S3バケットやIAMロールなどのリソースベースポリシーを分析し、他のAWSアカウントや匿名ユーザーなど、外部からアクセス可能な設定を検出します。

■内部アクセス分析(リソースベースポリシー+IAMポリシーの分析)
組織内でのアクセス権限を可視化し、適切な権限管理を支援するための機能です。重要リソース(S3バケット、DynamoDBテーブル、RDSスナップショットなど)に対してどのIAMユーザーやロールがアクセス権限を持っているかを特定します。

■未使用アクセス分析(IAMポリシーの分析)
過剰な権限を特定し、セキュリティリスクを軽減するための機能です。IAMロールとユーザーに付与されたIAMポリシーを分析して権限を特定し、最終アクセス情報と比較することで、実際には使用されていないアクセス権限を特定します。また、CloudTrailログに基づく必要最小限の権限のみを含むポリシーの生成機能も備えています。

その他、ポリシーがAWSベストプラクティスに準拠しているかを確認できるポリシー検証機能を提供しています。また、統合ダッシュボードにより、外部・内部・未使用アクセスの状況を一元的に可視化が可能で、AWS Organizationsとの統合により組織全体のアクセス管理も実現できます。

[IAM Access Analyzerの設定画面]
上に戻る

ListBucketについて

投稿日 2023/05/23

>管理用IAMユーザーがマネジメントコンソールからもアクセスする という条件から、バケット内のオブジェクトが参照できる必要があります
解説のこの文章について、なぜパケット内のオブジェクトを参照できる必要があるのか分からないのですが、ご存知のかたいらしたらご教示下さい。

2023/05/25 11:21

バケット「bucket-pingt」をマネジメントコンソール上で管理するためには、バケット内のオブジェクトを一覧表示させる権限(ListBucket)が必要がある、という説明では納得できないでしょうか?


コメント

s sho330

2023/07/14 22:35

「ListBucket」はバケット内のオブジェクト「bucket-pingt/*」ではなく、バケットそのもの「bucket-pingt」に対して設定する必要があります。

この返信に対して
コメントを記入できます

2024/02/01 22:04

この問題がテーマとして挙げているのは「バケット内のオブジェクトの管理するIAMユーザーの作成」だと思います。
まず、オブジェクトを参照してからでないと、オブジェクトを選択して削除のような管理するための操作は実現できないのではないでしょうか?


コメント

この返信に対して
コメントを記入できます

この投稿に対して返信しませんか?