本稿は、AWS Solution Architect Professional に出題される AWS Organizations について個人用にまとめた記事です。
目次
AWS Organizatins とは
組織で所有する AWS アカウントを一元管理する場合に役立ちます。請求の一元管理、アクセスコントロール、コンプライアンス、セキュリティ、アカウント間でのリソース共有に役立ちます。
AWS 環境をより効果的に制御するために、AWS Organizations を使用して、アカウントのグループを作成し、カスタムスクリプトや手動プロセスなしでも正しいポリシーがアカウント全体に適用されるようにグループにポリシーを適用できます。
アカウントの作成と管理を自動化
API を使用して、プログラムで新しいアカウントを作成し、作成されたアカウントをグループに追加することで、予め設定していたポリシーも自動的に新しいアカウントに適用されます。
概念
組織
AWS アカウントを統合するために作成するエンティティ。AWS Organizations コンソールを使用して、組織内のすべてのアカウントを一元的に表示および管理できます。組織には、1 つのマスターアカウントと、ゼロ以上のメンバーアカウントを含みます。最上部が ルートの階層ツリーを模擬した構造のアカウントや、ルート下に作られた組織単位を整理できます。各アカウントは、ルートに直接含めるか、階層内の OU のいずれかに配置することができます。組織には、有効にする機能セットによって決定された機能を含みます。
ルート
組織のすべてのアカウントが設定された親コンテナポリシーをルートに適用する場合は、組織内のすべての組織単位 (OU) とアカウントに適用されます。
マスターアカウント
Organizations を作成するために使用する AWS アカウントです。組織内のどのアカウントがマスターアカウントであるかを変更することはできません。
- 組織内で発生したすべての料金を支払う責任があります。
- 組織にアカウントを作成することができます。
- 組織に他の既存のアカウントを招待することができます。
- 組織からアカウントを削除することができます。
- 招待を管理することができます。
- 組織内のエンティティ (ルート、OU、またはアカウント) にポリシーを適用することができます。
メンバーアカウント
マスターアカウント以外のアカウントです。一度に一つの Organizations にのみ属することが可能です。
Administrative root アカウント
OU( 組織単位 )
ルート内のアカウントのコンテナです。また、OU は他の OU に含めることもでき、上下反転したツリーのような階層を作成できます。最上部にはルートがあり、下に向かって OU の枝が広がり、先端にはツリーの葉であるアカウントがあります。階層内のノードのいずれかにポリシーをアタッチすると、その配下にあるすべての枝 (OU) や葉 (アカウント) に適用されます。OU は、厳密に親を 1 つ持つことができ、現在、各アカウントを厳密に 1 つの OU のメンバーにすることができます。
Service Control Policy (SCP)
AWS Organizations のアカウントに対して、権限の制御が可能になります。ただし、SCP で作成するポリシーは通常の IAM ポリシーと比べ、出来る事が少なく、細かい制限は IAM で行います。SCP で大まかに設定して各アカウント、もしくは OU の IAM ポリシーで細かに設定するイメージです。
デフォルトでは、FullAWSAccess という名前の SCP がルートアカウント、その他のアカウントおよび OU に適用されます。このデフォルトの SCP はすべてのアクションとすべてのサービスの実行を許可します。
SCP で制限できないタスクおよびエンティティ
以下の項目は SCP で制限できません。
- マスターアカウントで実行されたアクション
- サービスにリンクされたロールにアタッチされたアクセス権限を使用して実行されるアクション
- ルート承認情報の管理。アカウントの root ユーザは以下の操作を実行可能
- ルートユーザのパスワード変更
- ルートアクセスキーの作成、更新、削除
- ルートユーザの多要素認証の有効・無効化
- ルートユーザの x.509 キーの作成、更新、削除
- ルートユーザとしてのエンタープライズサポートプランへの登録
- ルートユーザとしての AWS サポートレベルの変更
- CFn のキーの管理
- CloudFront プライベートコンテンツの信頼された署名者の機能
- AWS アカウントメールの上限/逆引き DNS の変更
- 一部の AWS 関連のサービスのタスクを実行する。
- Alexa Top Sites
- Alexa Web Information Service
- Amazon Mechanical Turk
- Amazon Product Marketing API
ルートユーザに対して、 SCP で制限できることがあまりないので、ルートユーザの使用はセキュリティ上よくありません。IAM を使用しましょう。また、サービスにリンクされたロールにも影響しません。
SCP と IAM の比較
SCP
- SCPは、主にAWS Organizationsの組織単位(OU)とともに使用されます。
- SCPは、実際のアクセス許可を提供しないようなIAMポリシーを置き換えません。アクションを実行するには、適切なIAMポリシーのアクセス許可を付与する必要があります。
- プリンシパルが特定のアクション(IAMポリシーを通じて付与)の実行を許可されている場合でも、アタッチされたSCPは、そのアクションに対して拒否を強制すると、その機能をオーバーライドします。
- SCPはIAMポリシーよりも優先されます。
- SCPは、組織のルートまたはOUの個々のアカウントに適用できます。
- SCPをOUまたは個々のAWSアカウントに適用する場合、指定したAWSサービスを有効化(ホワイトリスト)または無効化(ブラックリスト)することを選択します。アカウント、その親OU、またはマスターアカウントに関連付けられたSCPによって明示的に許可されていないサービスへのアクセスは、AWSアカウントまたはSCPに関連付けられたOUに対して拒否されます。
- どのアカウントにも、その上のすべての親によって許可された権限のみがあります。暗黙的に(許可ポリシーステートメントに含まれないことにより)または明示的に(拒否ポリシーステートメントに含まれることにより)アカウントの上の任意のレベルでアクセス許可がブロックされている場合、ユーザーに管理者権限を付与するIAMポリシーがアタッチされている場合でも、影響を受けるアカウントのユーザーまたはロールはその権限を使用できません。
- SCPは、組織の一部であるアカウントによって管理されているプリンシパルのみに影響します。
IAM
- IAMポリシーはプリンシパルレベルで動作します。 IAMポリシーには2つのタイプがあります。
1. アイデンティティベースのポリシー
IAMユーザー、グループ、またはロールに関連付けられています。
2. リソースベースのポリシー
S3バケットなどのAWSリソースに添付されます。 - IAMポリシーは、特定のリソースに対して特定のアクションを実行するためのプリンシパル許可を許可/拒否できます。 これをSCPと一緒に使用して、AWS組織でより厳密な制御を確保できます。 IAMポリシーはIAMユーザー、グループ、またはロールにのみ適用でき、AWSアカウントのルートIDを制限することはできません。
- IAMポリシーはOUに添付できません。
- IAMポリシーは、アクションを許可または拒否できます。 明示的な許可は、暗黙的な拒否をオーバーライドします。 明示的な拒否は、明示的な許可をオーバーライドします。
Organizations の変更監視
AWS Organizationsは、管理者が指定したアクションが組織で発生したときに、CloudWatchイベントと連携してイベントを発生させることができます。たとえば、誰かが組織内に新しいアカウントを作成するたび、またはメンバーアカウントの管理者が組織を離れようとするたびにアラートを受け取れます。これらのアクションを検索し、生成されたイベントを管理者が定義したターゲットに送信するCloudWatchイベントルールを設定し、Amazon SNSトピックでターゲットな送信することができます。これをAmazon CloudTrailと組み合わせて、一致するAPI呼び出しが受信されるたびにトリガーするイベントを設定できます。
AWS Configのマルチアカウント、マルチリージョンのデータ集約により、複数のアカウントおよびリージョンからのAWS Configデータを単一のアカウントに集約できます。マルチアカウント、マルチリージョンのデータ集約は、中央のIT管理者が企業内の複数のAWSアカウントのコンプライアンスを監視するのに役立ちます。
- CloudWatch イベントを使用する。
- CloudTrail で呼び出し API をトリガーする。
- SNS でターゲットに送信する。
- AWS Config でマルチアカウントのデータを収集する。