助け合いフォーラム
もっとも適切なアプローチはどれか。
正解
OU(Organizational Unit)単位にサービスコントロールポリシー(SCP)を設定する
解説
AWS Organizationsでは組織を階層構造で管理します。
サービスコントロールポリシー(SCP)は、組織に属しているOU(Organizational Unit)またはAWSアカウントに対して、AWSサービスへのアクセス権限や利用可能なリソースを制限できる機能です。例えば、組織に所属しているアカウントにMFA(多要素認証)を強制したり、特定のアカウントが利用できるサービスを制限したりできます。
したがって正解は
・OU(Organizational Unit)単位にサービスコントロールポリシー(SCP)を設定する
です。
その他の選択肢については、以下のとおりです。
・AWS Organizationsで複数のAWSアカウントを管理する。各アカウントのIAMユーザーにIAMポリシーを設定する
要件の実現は可能ですが、アカウント数が多い場合は一つ一つのアカウントの設定を行うのは手間でありミスが発生しやすいため適切なアプローチとはいえません。したがって、誤りです。
サービスコントロールポリシーを使用することにより、これらの手間やミスを軽減できます。
・IAMグループで複数のAWSアカウントを管理する。IAMグループにIAMポリシーを設定する
IAMグループは複数のIAMユーザーを管理します。
AWSアカウントは管理できないので、誤りです。
・サービスやアクションの制限をしたIAMポリシーを作成し、各AWSアカウントにアタッチする
IAMポリシーをアタッチできる対象は、IAMユーザー、IAMグループ、IAMロールです。
AWSアカウントは対象外なので、誤りです。
参考
AWS Organizationsは、複数のAWSアカウントを一元的に管理するためのサービスです。AWS Organizationsを使用することで、管理対象のAWSアカウントに対する権限の設定や、各アカウントの請求情報を集約した一括請求が利用できます。
Organizationsでは複数の組織を階層構造で管理します。
◯一括請求
管理するAWSアカウントへの請求情報をひとまとめにすることで、コストの一元管理ができます。そのため、利用するサービスを個別に支払うより全体を合計することによりボリュームディスカウントができたり、メンバーアカウントが購入した割引されたサービスをメンバー間で共有することで他のメンバーにも割引サービスが適応されたりします。
割引されたサービスにはリザーブドインスタンスやCompute Savings Plans(※)があり、管理アカウントでリザーブドインスタンスやSavings Plansの割引共有を有効化することでOrganizations内のすべてのアカウントでの使用量に適応され有効活用ができます。
(※)Compute Savings Plans ... 1年または3年の期間、一定のサービス使用量(1時間あたりの利用料金)を決めて契約することで、通常よりも低価格になる購入オプション
◯タグポリシー
Organizationsのタグポリシーは、AWSリソースに適用されるタグの使用を管理および制御するためのポリシーです。これにより、特定のタグキーや値の命名規則を強制し、組織全体で一貫したタグ付けを実現できます。タグポリシーは、リソースの整理やコスト管理を効率化するために使用されます。
〇サービスコントロールポリシー(SCP)
サービスコントロールポリシー(SCP)は、組織(Root)に属しているOU(Organizational Unit)または特定のアカウントに対して、AWSサービスへのアクセス権限や利用可能なリソースを制限できる機能です。例えば、組織に所属しているアカウントにMFA(多要素認証)を強制したり、特定のアカウントが利用できるサービスを制限したりできます。また、SCPを適用する条件(Condition)を設定することで、特定のIAMユーザーまたはIAMロールに対してのみ制限を適用するといった制御も可能です。
SCPをRootやOUに対して設定すると、その配下の要素に対してもSCPが適用(継承)されます。なお、SCPによる制限はAWSアカウントのルートユーザーに対しても有効です。
◯条件キー
条件キーは、特定の条件に基づいてアクセス制御を行うためにポリシーのCondition要素の中で使用されます。条件キーを使用することで、ポリシーの許可や拒否を具体的な条件で細かく制御し、アクセス権を詳細に管理できます。条件キーのうち、グローバル条件キーは"aws:"で始まり、すべてのAWSサービスに対して共通して使用できます。一方、サービス固有の条件キーは、サービス固有の名前(例"s3:")で始まります。
グローバル条件キーには以下のようなものがあります。
・組織ID(aws:PrincipalOrgID) ... 組織全体にわたるアクセスを制御する
・組織パス(aws:PrincipalOrgPaths) ... 組織ユニットの階層を指定し特定の部門やグループに対する細かいアクセスを制御する
・プリンシパルタグ(aws:PrincipalTag) ... タグに基づいてアクセスを制御する
例えば、aws:PrincipalOrgIDを条件キーとして指定することで、特定の組織IDを持つアカウントのみにリソースへのアクセスを許可することができます。
以下のポリシーでは、AWS Organizationsの設定とS3バケットポリシーを組み合わせて、厳密なアクセス制御を実施できます。
誤答の理由について
初歩的な質問失礼いたします。
この問題に関して、正答が「組織単位にサービスコントロールポリシーを設定する」であること、
またIAMグループでの管理も有効であることは承知しています。
しかし誤答の選択肢の「サービスやアクションの制限をしたIAMロールを作成し、各アカウントにアタッチする」の、
解説欄の誤答の理由がいまいちピンときません。
多くのアカウントの管理が必要な時に各アカウントにアタッチするのは大変かもと考えたりしたのですが合ってますでしょうか?
解説内では、「IAMロールはAWSのリソースに対して付与するIAMポリシーのことですので誤りです。
例えば、EC2インスタンスからデータベース(RDSなど)を利用する際は、
RDSの権限が付与されたIAMロールをEC2インスタンスに対してアタッチします。」とありますが、サービスとリソースの違いがわかりません。
個別に利用可能なサービスやアクションの制限をしたい場合、IAMロールが使えると思っていました。
どなたかご教授いただけますと幸いです。
IAMロールは、ユーザ(アカウント)に付与するものではなくて、EC2やLambdaなどに付与します。
たとえばEC2からS3にアクセスしたい場合に、EC2にはS3にアクセスする権限が必要になります。それを付与するのがIAMロールです。
コメント
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
詳細詳しく教えて頂きありがとうございます!