助け合いフォーラム

AWS

AWS ソリューションアーキテクト - アソシエイト(SAA-C03)
問題ID : 30454
問題を開く
以下のIAMポリシーの効果として正しいのはどれか。

正解

192.0.2.0/24のネットワークからEC2インスタンスを起動・停止・再起動できる

解説

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


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

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

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

Amazon EC2のアクションの代表例は以下の通りです。


設問の定義を確認します。


1つ目のブロックではEC2インスタンスに対する再起動・起動・停止のアクションをIPアドレスの条件付きで許可しています。また、2つめのブロックは拒否の設定をしています。拒否の条件は定義されていないため、どのユーザーもEC2インスタンスを終了することはできません。

各選択肢を確認します。

・192.0.2.0/24のネットワークからEC2インスタンスを終了できる
・192.0.0.0/16のネットワークからEC2インスタンスを終了できる
EC2インスタンスの終了("Action": "ec2:TerminateInstances") は拒否("Effect":"Deny")が定義されているため、どのネットワークからもできません。したがって、誤りです。

・192.0.0.0/16のネットワークからEC2インスタンスを起動・停止・再起動できる
起動・停止・再起動のアクションは許可("Effect":"Allow")されていますが、条件(”Condition")として「ネットワーク192.0.2.0/24からのみ("aws:SourceIp": "192.0.2.0/24")」と定義されているため、192.0.0.0/16には実行権限がありません。
したがって、誤りです。

・192.0.2.0/24のネットワークからEC2インスタンスを起動・停止・再起動できる
Effect、Action、Resource および Condition についてポリシーの記述通りのため、正しい選択肢です。

参考

【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ユーザー(IAMグループ)やIAMロール、一部のAWSリソースにアタッチ(付与)やデタッチ(剥奪)が可能です。IAMユーザーやAWSリソースは、アタッチされているIAMポリシーが許可する範囲内でのみ操作を実行できます。IAMポリシーで許可されていない操作は実行できません。


本項では、以下のIAMの機能について説明します:
・ユーザーの種類
・ユーザーの管理
・IAMロール
・IAMポリシー

【ユーザーの種類】
AWSには「AWSアカウント(ルートユーザー)」「IAMユーザー」という2種類のユーザーがあります。


AWSアカウントやIAMユーザーは、AWSサービスへのアクセスに「ユーザー名とパスワード」または「アクセスキーとシークレットアクセスキー」を使用して認証します。これにより、AWSサービスへのアクセスをセキュアに保ち、適切な権限が与えられたユーザーのみがサービスを利用できるようになります。
○ユーザーIDとパスワード ... 任意のIDと自分で設定したパスワードを用いた認証方法です。マネジメントコンソールにログインするときに使用します。
○アクセスキーとシークレットアクセスキー ... AWSによって作成されるアクセスキーIDと、対になるシークレットアクセスキーを用いた認証方法です。AWS CLIやAWS SDKなどを使用してAWSサービスにプログラムでアクセスするときに使用します。アクセスキーとシークレットアクセスキーは、不正利用を防止するため定期的にローテーション(更新)することが推奨されています。

■AWSアカウント(ルートユーザー)
AWSアカウントは非常に強力な権限を持つので、日常的なAWSリソース操作にはIAMユーザーを使用し、極力AWSアカウントを使用しないことがAWSベストプラクティスで推奨されています。
AWSアカウントは可能な限り構築する環境(例えば本番環境、開発環境など)ごとに作成します。複数のアカウントで各環境のリソースを分離することで、管理対象のリソースを把握しやすくなり、リソース管理が効率化されます。また、ある環境でセキュリティ問題が発生しても、他の環境への影響を最小限に抑えられるため、全体的なセキュリティが向上します。

AWSアカウントの運用においては、強力なパスワードの使用や定期的なパスワード変更に加え、MFA(多要素認証※)を有効化するなど、厳格なセキュリティ対策が必要です。また、AWSアカウントのアクセスキーとシークレットアクセスキーは、不正利用防止のために無効化もしくは削除することが推奨されています。
(※)MFA(Multi-Factor Authentication:多要素認証)とは、ユーザーIDとパスワードでの認証の際に、追加でワンタイムパスワードや指紋などのバイオメトリクスを使用する認証方法です。MFAを有効にするには、MFAデバイスを入手してマネージメントコンソールもしくはAWS CLIでMFAデバイスをアクティブ化します。

■IAMユーザー
AWSリソースを操作する際は基本的にIAMユーザーで行います。IAMユーザーに適用するIAMポリシーには最小権限の原則を実装し、AWSリソースの使用に適切な認可をします。最小権限の原則とは、ユーザーやプログラムが作業を遂行するために必要な最小限のアクセス権限を付与することです。 IAMユーザーは複数人で共有せず、個々にIAMユーザーを作成します。

【ユーザーの管理】
AWSアカウントとIAMユーザーには、それぞれ複数のユーザーを一括して管理できる機能があります。

■複数のAWSアカウントの管理(AWS Organizations)
「AWS Organizations」は、複数のAWSアカウントを一元的に管理するためのサービスです。AWS Organizationsを使用することで、管理対象のAWSアカウントに対する権限の設定や、各アカウントの請求情報を集約した一括請求が利用できます。一括請求では複数のAWSアカウントにまたがった従量制割引が適用されます。

AWS Organizationsでは、利用したい機能に応じて2種類の機能セットから選択することができます。
○すべての機能 ... 一括請求だけでなく、AWSアカウントや組織ごとのサービスの利用制限といったすべての機能を利用できる。(デフォルト)
○一括請求 ... 複数のAWSアカウントにおける請求情報の一括管理機能のみを利用できる。

Organizationsでは複数の組織を階層構造で管理します。


〇サービスコントロールポリシー(SCP)
サービスコントロールポリシー(SCP)は、AWS Organizationsに属している組織(OU)または特定のアカウントに対して、AWSサービスへのアクセス権限や利用可能なリソースを制限できる機能です。例えば、組織に所属しているアカウントにMFA(多要素認証)を強制したり、特定のアカウントが利用できるサービスを制限したりできます。また、SCPを適用する条件(Condition)を設定することで、特定のIAMユーザーまたはIAMロールに対してのみ制限を適用するといった制御も可能です。
SCPをRootやOUに対して設定すると、その配下の要素に対してもSCPが適用(継承)されます。なお、SCPによる制限はAWSアカウントのルートユーザーに対しても有効です。

管理するAWSアカウントへの請求情報をひとまとめにすることで、コストの一元管理ができます。そのため、利用するサービスを個別に支払うより全体を合計することによりボリュームディスカウントができたり、メンバーアカウントが購入した割引されたサービスをメンバー間で共有することで他のメンバーにも割引サービスが適応されたりします。
割引されたサービスにはリザーブドインスタンスやCompute Savings Plans(※)があり、管理アカウントでリザーブドインスタンスやSavings Plansの割引共有を有効化することでOrganizations内のすべてのアカウントでの使用量に適応され有効活用ができます。
(※)Compute Savings Plans ... 1年または3年の期間、一定のサービス使用量(1時間あたりの利用料金)を決めて契約することで、通常よりも低価格になる購入オプション

■ マルチアカウント環境におけるセキュリティの統制(AWS Control Tower)
AWS Control Towerは、AWSにおけるベストプラクティスに基づいた、セキュアなマルチアカウント環境(ランディングゾーンと呼ばれます)のセットアップを自動化するマネージドサービスです。

Control Towerでは、AWSにおけるベストプラクティスに基づいた構成や設定、ルールの組み合わせをガードレール(コントロールとも呼ばれます)として提供しています。管理者は、セキュリティやコンプライアンスの要件にあわせてこれらを選択し適用することで、各アカウントに対する設定や適用するルールにばらつきが生じることを防ぎ、統制のとれたマルチアカウント環境を容易に展開することができます。

例えば、データレジデンシーガードレールは、データの保存や処理ができるリージョンに制限をかけることを主な目的としたガードレールです。このガードレールを用いることで、特定のリージョン以外の使用を禁止したり、VPCをインターネットから隔離するといった設定が可能です。これにより、企業のコンプライアンス要件や国際的な法規制などに準拠した環境を構築することができます。

AWSクラウド上にセキュアなマルチアカウント環境を構築するためには、さまざまなAWSサービス(例: AWS Organizations、AWS Config、AWS CloudFormation等)を組み合わせて実現する必要があります。Control Towerを使用することで、これらのサービスの有効化と構成が自動的に行われ、環境構築の手間を軽減することができます。


■ 認証処理の一元化(AWS IAM Identity Center)
AWS IAM Identity Center(旧: AWS Single Sign-on)は、複数のAWSアカウントやアプリケーションへのアクセスを効率的に一元管理するためのサービスです。Identity Centerを使用すると、一度の認証処理で複数のAWSアカウントやアプリケーションへのアクセスが可能になるシングルサインオンの環境を容易に実現することができます。
Identity CenterはAWS Organizationsと組み合わせて使用することが推奨されています。Organizationsで一元管理されているAWSアカウントに対するシングルサインオンを、Identity Centerを使用して実現することができます。
また、Identity Centerは、他の認証システム(例: Microsoft Active Directory)と連携させることが可能です。これにより、例えば、既存のDirectory Serviceの認証情報でログインするだけで、複数のAWSアカウントやアプリケーションへのアクセスが可能になります。

[Identity Centerを用いたシングルサインオンのイメージ]


■複数のIAMユーザーの管理(IAMグループ)
複数のIAMユーザーが所属するグループを「IAMグループ」といいます。IAMグループは、同一アカウント内の複数のIAMユーザーのアクセス権限を一元的に管理できます。

個々のIAMユーザーに対してIAMポリシーを設定するのではなく、IAMグループを活用することで権限管理を効率的に行えます。AWSベストプラクティスでもIAMグループを活用することが推奨されており、不必要な権限の設定や権限不足によるミスを防ぐことができます。
なお、IAMユーザーは複数のIAMグループに所属できますが、IAMグループは別のIAMグループに所属できないので、IAMグループを用いた階層的な権限管理は実現できません。

【IAMロール】
IAMロールは、AWSサービスやアプリケーション、他のAWSアカウントに対してAWSリソースへのアクセス権限を付与する際に利用します。
IAMロールを作成する際に、信頼されたエンティティとして、まず権限を付与する対象を指定します。その後、そのエンティティに付与するアクセス権限を設定します。


■AWSサービスやアプリケーションに対してアクセス権限を付与
AWSリソースはユーザーからアクセスされる他、AWSサービスやアプリケーションからもアクセスされます。例えば、EC2インスタンス上で実行されるアプリケーションがS3バケットにアクセスする場合、通常はアクセスキーとシークレットアクセスキーを用いて認証が行われます。しかし、アプリケーションコードに認証情報を直接埋め込むことは、セキュリティリスクが高いため推奨されません。
IAMロールの使用により、このようなリスクを軽減できます。IAMロールは一時的なアクセスキーを生成・利用して認証を行い、アプリケーションはこの一時的なキーを用いてAWSリソースにアクセスします。生成されるアクセスキーは有効期限が設定されており、もし漏洩した場合でもリスクは比較的低く抑えられます。

EC2インスタンスにIAMロールを付与することにより、一時的なアクセスキーを使ってS3バケットへアクセスします。

・インスタンスプロファイルについて
マネジメントコンソールからEC2のIAMロールを作成すると、「インスタンスプロファイル」が自動的に作成されます。インスタンスプロファイルとはIAMロールを格納する入れ物のようなもので、EC2インスタンスは起動時にインスタンスプロファイルを読み込み、設定されたIAMロールの権限で動作します。

マネジメントコンソールでIAMロールを作成した場合は同名のインスタンスプロファイルが作成されるため、通常は意識する必要はありません。AWS CLIなどからEC2のIAMロールを作成する場合は、「インスタンスプロファイルを作成し、作成したIAMロールをインスタンスプロファイルへアタッチ(格納)する」という作業が必要になります。

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


IAMポリシーはアタッチする対象によって「アイデンティティ(ID)ベースのポリシー」と「リソースベースのポリシー」に分かれます。

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

AWS管理ポリシーでは必要な権限を付与できない場合に、カスタマー管理ポリシーを作成して使用します。
インラインポリシーは特定の対象に限定したポリシーなので管理が煩雑になりやすく、AWSベストプラクティスでは推奨されていません。(後述のリソースベースのポリシーを除く)

〇リソースベースのポリシー
リソースベースのポリシーは、一部のAWSリソース(S3バケットやSQSキューなど)に対してアタッチするインラインポリシーです。例えば、S3のバケットポリシーがリソースベースのポリシーに該当し、S3バケットへのアクセスを特定のユーザーや特定のIPアドレスだけに許可する場合などに利用します。

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


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

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

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」など)

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


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


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


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

■信頼ポリシー(信頼関係の設定)
信頼ポリシーは、AWSアカウント間でリソースへのアクセスを許可する際に、資格情報(ユーザー名とパスワードやアクセスキーとシークレットキーなど)の共有というセキュリティリスクを避けるための手段です。資格情報の共有は、漏洩リスクを伴うので推奨されません。IAMロールに信頼ポリシーを設定することで、他のAWSアカウントやサービスが指定されたロールの権限を一時的に利用することが可能になります。これにより、資格情報の直接共有なしに、安全な形で他のアカウントからリソースへのアクセスを実現できます。

ロールの引き受けを許可するため、AWS STS(Security Token Service:一時的なセキュリティ認証情報提供するサービス)のAPI「AssumeRole」を使用します。これをIAMポリシーのActionとして指定します。

以下の例では、アカウントA(111111111111)のIAMロール:RoleAに対して、アカウントB(999999999999)のIAMユーザ:UserBを信頼するポリシーを設定します。
さらに、アカウントBのUserBに対して、引き受けが可能なロールの指定(この例ではアカウントAのRoleA)と、AssumeRoleの許可を定義したポリシーを設定します。
これによりUserBは、RoleAに与えられた権限を引き受けて、アカウントA内のリソースにアクセスできるようになります。

[RoleAに設定する信頼ポリシー]


[UserBに設定するIAMポリシー]

上に戻る

IAMポリシーにて、IPが"210.75.12.75/16"からの操作を許可した場合、"210.75.0.0/24"からの操作も許可されませんか?

公開日 2023/02/25

問題IDが30454の問題にて、

・210.75.0.0/24のネットワークからEC2インスタンスを起動・停止・再起動できる
起動・停止・再起動のアクションは許可("Effect":"Allow")されていますが、条件(”Condition")として「ネットワーク 210.75.12.75/16からのみ("aws:SourceIp": "210.75.12.75/16")」と定義されているため、210.75.0.0/24には実行権限がありません。
したがって、誤りです。

と解説されていますが、210.75.0.0/24 は 210.75.12.75/16 の範囲内なので実行権限があると思うのですが。。。
いかがでしょうか。

2023/02/27 16:26

ご確認いただきありがとうございました!!


コメント

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

スタッフからの返信

s staff_satomi

2023/02/27 15:44

k_hana1103様 ご指摘の点を修正いたしました。 ご報告いただきまして、誠にありがとうございます。

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