助け合いフォーラム

AWS

AWS ソリューションアーキテクト - アソシエイト(SAA-C03)
問題ID : 30444
問題を開く
複数のAWSアカウントを管理している組織において、チームごとに利用可能なサービスやアクションを制限したい。
もっとも適切なアプローチはどれか。

正解

組織単位にサービスコントロールポリシーを設定する

解説

複数のAWSアカウントをまとめて管理する機能に「AWS Organizations」があります。AWS Organizationsでは、管理するAWSアカウントに対して権限を設定したり、管理するAWSアカウントへの請求情報をひとまとめにすることができます。
Organizationsでは複数の組織を階層構造で管理します。


Organizationsに属している個々のアカウントや組織(OU)に対して、利用できるAWSサービスやアクションを制限する「サービスコントロールポリシー(Service Control Policy:SCP)」を設定することもできます。SCPを用いると、例えばテスト用のアカウント(群)は特定のサービスにしかアクセスできないようにしたり、全てのアカウントに対してMFA(多要素認証)を強制するように設定することなどができます。

以上より正解は
・組織単位にサービスコントロールポリシーを設定する
です。

その他の選択肢については以下の通りです。

・AWS Organizationsで複数のAWSアカウントを管理する。各アカウントのIAMユーザーにIAMポリシーを設定する
要件の実現は可能ですが、アカウント数が多い場合は一つ一つのアカウントの設定を行うのは手間でありミスが発生しやすいため適切なアプローチとはいえません。したがって、誤りです。
サービスコントロールポリシーを使用することにより、これらの手間やミスを軽減できます。

・IAMグループで複数のAWSアカウントを管理する。IAMグループにIAMポリシーを設定する
IAMグループは複数のIAMユーザーを管理します。
AWSアカウントは管理できないので、誤りです。

・サービスやアクションの制限をしたIAMポリシーを作成し、各AWSアカウントにアタッチする
IAMポリシーをアタッチできる対象は、IAMユーザー、IAMグループ、IAMロールや、IAMリソース(S3バケットなど)です。
AWSアカウントは対象外なので、誤りです。

参考

【AWS IAM(Identity and Access Management)】
AWS IAMとは、AWSにおいて「どのユーザーが」「どのAWSリソースに対して」「どのような操作ができるか(できないか)」を定義する、「認証」「認可」の仕組みを提供するサービスです。IAMを適切に運用することにより、例えばユーザーの操作ミスによりEC2インスタンスを削除してしまう事故を防げたり、アカウントが乗っ取られた際の影響を限定することができます。AWSではIAMの機能を無料で提供しています。

以下はIAMの概要です。

IAMでは、AWSのリソースに対する権限を「IAMポリシー」として定義します。定義したIAMポリシーは、「IAMユーザー(IAMグループ)」やAWSリソースに対してアタッチ(付与)・デタッチ(剥奪)することができます。IAMユーザーやAWSリソースはアタッチされているIAMポリシーの範囲で操作を行うことができ、IAMポリシーによって許可されていない操作は実行できません。

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

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


これらのユーザーは「ユーザーIDとパスワード」または「アクセスキーとシークレットアクセスキー」を用いて認証することで、WebやコマンドなどからAWSリソースへアクセスします。
○ユーザーIDとパスワード ... 任意のIDと自分で設定したパスワードを用いた認証方法。マネジメントコンソールにログインする際に使用する。
○アクセスキーとシークレットアクセスキー ... AWSによって作成されるアクセスキーID(例:AKIA3MQXZYKOAYRZ33OR)と、対になるシークレットアクセスキーを用いた認証方法。AWS CLIやAWS APIからAWSリソースにアクセスする際に使用する。

AWSアカウントは非常に強力な権限を持つため、AWSではAWSアカウントを極力使用しないことを推奨しています。AWSアカウントの運用は、強力なパスワードの採用や定期的なパスワード変更に加えてMFA(多要素認証)を有効にするなど、厳重なセキュリティ対策を取る必要があります。
なお、多要素認証とは、パスワードやアクセスキーによる認証に加えて認証コードやワンタイムパスワードなどの複数の要素を使う認証方式です。AWSでは、AWSアカウントのほかIAMユーザーにも多要素認証を有効にできます。
また、AWSアカウントはIAMユーザーに対するパスワードポリシーも設定できます。パスワードポリシーとは、パスワードの文字列長や大文字・数字・記号を含むか、パスワードの有効期限などの設定のことで、IAMユーザーをセキュアに運用するために使用します。ただし、IAMユーザーに対するパスワードポリシーはAWSアカウントには適用されません。

■複数のAWSアカウントの管理(AWS Organizations)
複数のAWSアカウントをまとめて管理する機能に「AWS Organizations」があります。AWS Organizationsでは、管理するAWSアカウントに対して権限を設定したり、管理するAWSアカウントへの請求情報をひとまとめにすることができます。
Organizationsでは複数の組織を階層構造で管理します。


Organizationsに属している個々のアカウントや組織(OU)に対して、利用できるAWSサービスやアクションを制限する「サービスコントロールポリシー(Service Control Policy:SCP)」を設定することもできます。SCPを用いると、例えばテスト用のアカウント(群)は特定のサービスにしかアクセスできないようにしたり、全てのアカウントに対してMFA(多要素認証)を強制するように設定することなどができます。

■複数のIAMユーザーの管理(IAMグループ)
IAMグループは複数のIAMユーザーをまとめたもののことです。複数のIAMユーザーに対してまとめてアクセス制御を行う際に使用します。

個別のユーザーに一つ一つポリシーを設定すると、不要な権限を設定してしまったり必要な権限が不足しているなどのミスが発生しやすいですが、IAMグループを使用することにより組織的に権限の設定ができるようになります。
ただし、グループにグループを所属させることはできませんので、IAMグループを使った階層的な管理はできません。

【IAMロール】
IAMロールは、AWSのリソースやアプリケーション、他のAWSアカウントに対して一時的にAWSリソースへのアクセス権限を付与する際に利用します。


AWSのリソースはユーザーが利用するものだけではなく、AWSサービスやアプリケーションが使用するものもあります。例えばEC2インスタンス上で動作するアプリケーションがS3バケットを利用する場合、アプリケーションはアクセスキーおよびシークレットアクセスキーを使用して認証したのちにS3バケットへアクセスします。しかしアプリケーションプログラムに認証情報を埋め込むのはセキュリティリスクが高く危険です。
IAMロールを使用すると、このようなリスクを回避できます。IAMロールでは一時的なアクセスキーを生成・使用することにより認証します。生成したアクセスキーは短時間で使用できなくなるため、漏洩してもリスクは高くありません。

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

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

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

【IAMポリシー】
IAMポリシーとはAWSリソースに対する権限を定義したものです。Resource(どのAWSリソースに対して)、Action(どのAWSサービスのどの操作を)、Effect(許可または拒否)の3つの要素で定義します。
例えば「S3バケットMyBucketに対する書き込み・読み込みを許可する」というIAMポリシーを作成しIAMユーザーにアタッチすることで、対象のユーザーはMyBucketのオブジェクトを読み書きできるようになります。一方、許可されていない削除等のアクションは実行できません。

以下は実際にIAMポリシーを定義する際の画面の例です。

さらに、ポリシーを適用する条件(送信元IPアドレスの指定など)も加えることができます。

IAMポリシーには「アイデンティティ(ユーザー)ベースのポリシー」と「リソースベースのポリシー」があります。
アイデンティティベースのポリシーは、IAMユーザー、IAMグループ、IAMロールにアタッチするポリシーのことをいいます。
アイデンティティベースのポリシーには以下の種類があります。


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

それぞれのポリシーには以下のような違いがあります。


■インラインポリシーの記述例
IAMポリシーはマネジメントコンソールのビジュアルエディタのほか、JSON形式で定義することもできます。以下はJSON形式の定義例です。

Effect、Action、Resource ごとに、複数ある場合は "[]" のブロックで指定します。また、任意の値を示す場合は「*(アスタリスク)」で指定することができます。全てのリソースを対象にする場合は「"Resource":"*"」とすることや、あらゆる書き込みアクションを指定したい場合は「PutObject*」とすることも可能です(「PutObject」のほか、「PutObjectAcl」「PutObjectTagging」なども含まれます)。
以下は代表的なアクションの例です。
・Amazon EC2

・Amazon S3


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

リージョンやアカウントは省略できます。また、階層表示が可能なリソースはスラッシュ(/)で区切って指定します。上図のS3バケットの例の「bucket-pingt/*」は、バケット配下の任意のオブジェクトを意味します。

■Permissions Boundary(アクセス許可境界)
IAMでは、IAMユーザーやIAMロールに対して「ここまでの範囲内であれば自由に操作を行える」という境界を設定できます。これを「Permissions Boundary(アクセス許可境界)」と呼びます。アクセス許可境界が設定されたユーザーは、境界で許可された範囲とIAMポリシーの両方で許可されている範囲でアクションを行えます。


アクセス許可境界は、例えばLambda関数の作成をしている開発者に対して、必要なリソースへのアクセス権は都度自由に設定できるようにしておきたいが、開発者自身のアクセス権を操作させたくないようなケースで有用です。開発者にある程度の権限を与えておくことにより、アクセス権が必要になった際にいちいち管理者が対応する必要がなくなります。一方、権限を超えた操作をしないようにアクセス許可境界を設定しておけば、セキュリティリスクも抑えられます。

上に戻る

誤答の理由について

公開日 2022/10/31

初歩的な質問失礼いたします。
この問題に関して、正答が「組織単位にサービスコントロールポリシーを設定する」であること、
またIAMグループでの管理も有効であることは承知しています。

しかし誤答の選択肢の「サービスやアクションの制限をしたIAMロールを作成し、各アカウントにアタッチする」の、
解説欄の誤答の理由がいまいちピンときません。
多くのアカウントの管理が必要な時に各アカウントにアタッチするのは大変かもと考えたりしたのですが合ってますでしょうか?
解説内では、「IAMロールはAWSのリソースに対して付与するIAMポリシーのことですので誤りです。
例えば、EC2インスタンスからデータベース(RDSなど)を利用する際は、
RDSの権限が付与されたIAMロールをEC2インスタンスに対してアタッチします。」とありますが、サービスとリソースの違いがわかりません。
個別に利用可能なサービスやアクションの制限をしたい場合、IAMロールが使えると思っていました。

どなたかご教授いただけますと幸いです。

2022/11/02 14:16

IAMロールは、ユーザ(アカウント)に付与するものではなくて、EC2やLambdaなどに付与します。
たとえばEC2からS3にアクセスしたい場合に、EC2にはS3にアクセスする権限が必要になります。それを付与するのがIAMロールです。


コメント

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

2022/11/02 16:02

AWS以外の一般的なロールではユーザーアカウントに紐づけて権限を付与することが多いですが、AWSのIAMロールではCafeLateさんの説明のように、AWSリソース(EC2やLambdaなど)に権限を付与します。なので、IAMロールではIAMユーザーへ権限の付与はできません。

参考にあるIAMロールの解説に

IAMロールは、AWSのリソースやアプリケーション、他のアカウントに対して一時的にAWSリソースへのアクセス権限を付与する際に利用します。

と、「他のアカウント」(IAMユーザーではなくAWSアカウント)に対しても権限を付与できる(厳密には権限委譲です)と書かれていますが、こちらも各アカウントに一つ一つ設定していくものなので、対象のアカウント数が多いと手間ということだと思います。

ちなみに解説内のサービスとリソースはほぼ同じ意味だと思います。(AWSサービス=AWSリソース=EC2やLambdaなど)私の解釈では、AWSサービス=EC2・Lambda、AWSリソース=EC2インスタンス・Lambda関数くらいの違いかなと思っています。


コメント

y ysatoag

2022/11/02 18:34

詳細詳しく教えて頂きありがとうございます!

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

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