AWS Organizationsとは？rootユーザも制御するその強力さを手を動かして体感してみる

あまり馴染みがないかもしれない、けれどごっつ強力なAWS Organizationsの機能をさくっと体感するチュートリアルでございます。

#IAM Policy

#AWS Organizations

#AWS IAM

#AWS

濱田孝治

2020.11.12

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

「AWS Organizationsやばい、めっちゃ強力。でもこれ、一歩間違ったらすべてが破壊される…」

皆さん、AWS Organizaions使ってますか？複数のAWSアカウントを管理していく上で非常に重要かつ便利な機能なのですが、普段の開発運用では意識することはあまり多くないかもしれません。

今回、ひょんなことからAWS Organizationsをあれこれ触っているんですが、まぁこれ、超絶便利で強力ですね。すごい全能感を感じるというか、自分が大好きなCloudFormation以上に、AWSを思うがままに操っている感がするというか、とにかくその強さに驚きっぱなしです。

このブログでは、普段あまり触れられることが少ないAWS Organizationsについて、基本的な部分を手を動かしてその強力さを体感することを目的に、チュートリアル的にその手順をまとめました。

「あまり馴染みがないけれど、一回触ってみたいんだよなぁ」と考えている方にはバッチリハマる内容だと思うので、ぜひこの記事をきっかけに、AWS Organizationsの思想や強力さについて体感いただければと思います。

（祭） ∧ ∧
　Y　 ( ﾟДﾟ)
　Φ[_ｿ__ｙ_l〉     Organizations ﾏﾂﾘﾀﾞﾜｯｼｮｲ
　　　 |_|＿|
　　　 し'´Ｊ

Organizationsを扱う上で最初にみておくべき情報

実際に手を動かして学ぶ前に、最低限の知識は入れておいたほうが話が早い。ので、いくらか学習に役立ちそうな情報リソースを纏めておきます。

最初の概要掴むにはやっぱりこれ。Black Belt資料

スライド形式で概要を学ぶには完全にオススメです。作成日が2018年2月14日とちょっと古いのがきになりますが、機能自体は大きくは変わっていないので、今でも十分通用する資料です。

20180214 AWS Black Belt Online Seminar AWS Organizations from Amazon Web Services Japan

公式サービスページで最新情報を取得

AWS Organizations（AWS アカウント全体の一元管理）| AWS

Black Belt資料のあとは、公式ページを一旦ななめ読みします。よくある質問（FAQ）は、機能の主要部分の把握には非常に良いコンテンツなので、Organizations触る時にも最初に流し見しておくことをオススメします。

よくある質問 - AWS Organizations | AWS

最初に組織ユニットとサービスコントロールポリシーを理解する

今回のチュートリアルをすすめるにあたっては、最低限組織ユニットとサービスコントロールポリシーについて理解しておくのが一番の近道です。下記公式ドキュメントを参考に、基本的な用語と概念をおさえておきましょう。

AWS Organizations の用語と概念 - AWS Organizations

※上記、公式ページより引用

AWS Organizationsの料金は？

AWS Organizationsの利用自体には料金はかかりません。無料です。気軽にあれこれ試せるのは良いですね！

Organizationsを実際に手を動かして体感してみよう！

それでは、ここからチュートリアルの始まりです。基本的な流れは公式ドキュメントのチュートリアルを踏襲しています。

AWS Organizations tutorials - AWS Organizations

チュートリアルは2種類ありますが、ここでは最初の「Creating and configuring an organization」を元に進めていきます。

Tutorial: Creating and configuring an organization - AWS Organizations

ただ、このブログでは、上記チュートリアルを参考にしながら、めんどくさそうなところは端折りつつ進めていくようにハマコーなりに改変していることご承知おき下さい。

手順の大きな流れ

体感する手順はこんな感じです。AWSアカウントも、Organizationsの機能を使って作成します。

rootユーザーでアクセス可能なAWSアカウントを用意する
Organizationsを作成する
OrganizationsからAWSアカウントを追加する
組織ユニット（OU）を作成する
サービスコントロールポリシー（SCP）を作成する
組織ユニットにサービスコントロールポリシーを適用する
AWSアカウントにアクセスし動作確認する

AWSアカウントへのrootユーザーでのログイン

前提として、Root権限にアクセス可能なAWSアカウントを一つ用意しておき、Rootユーザーでマネジメントコンソールにログインします。このアカウントがマネジメントアカウントとなり、Organizationsの全てを管理するアカウントとなります。

参考までに、2020年10月20日に、Organizationsのすべてを管理するアカウントの名前が「Master」から「Management」に変更されています。過去の資料などは、まだまだ「マスターアカウント」の呼称が残っていますが、このブログでは「マネジメントアカウント」に統一します。

Organizationsの作成

マネジメントコンソールからOrganizationsのメニューを開きます。

AWS Organizations

最初にOrganizationを作成するかどうか聞かれるので、そのまま「Create organization」をクリックし、Organizationsを作成します。

作成すると、Organizationsを作成したアカウントがマネジメントアカウントとして登録され、一覧に表示されます。

また、同時にマネジメントアカウントで設定されているメールアドレスに対して認証メールが送信されているので、その内容を確認しメールアドレスを認証しましょう。

Organizationsを利用したAWSアカウントの追加

次に、Organizationsを利用してAWSアカウントを作成していきます。

Organizationsの画面から、「アカウントの追加」ボタンをクリック。

「アカウントの作成」をクリック。

作成するアカウントの詳細を求められます。アカウント名はとりあえず「test」とし、アカウントに紐づけるメールアドレスを入力します。このメールアドレスは他のアカウントと共用できないので、独自のものを用意しましょう。IAMロール名はそのアカウントに対する管理者権限を持つロール名です。ここは非必須なので、空白にしておきます。

「作成」ボタンをクリックすると、設定したメールアドレス宛にAWSアカウント作成の通知がとび、アカウント一覧にAWSアカウントが追加されます。

この時、アカウントが表示されない場合は、アカウント作成に失敗しているので、上の「非表示」トグルボタンをクリックして、失敗原因を確認しましょう。

組織ユニット（OU）の作成

AWSアカウントの追加ができたら、いよいよOrganizationsの注目ポイント、組織ユニット（OU）を作成していきます。

Organizationsのコンソールから「アカウントの整理」タブをクリックすると、Organizationsの構造を表示することができます。マネジメントアカウントと、先程作成したtestアカウントが表示されていますね。ここで、「+新組織単位」をクリック。

組織単位の作成画面が表示されるので、組織名を入力。ここでは、「Production」として「組織単位の作成」をクリックします。

こんな感じでOUが作成されます。良ござんす。ここで、先ほど作成したtestアカウントを選択し、「移動」をクリックします。

アカウントの移動画面がポップアップするので、移動先の組織「Production」を選択して「移動」実施。

そうすると、左側の組織ツリーの中でProductionを選択することで、中に先程移動処理したtestアカウントが表示されています。

サービスコントロールポリシー（SCP）の作成

組織ユニットを作成する大きなメリットの一つに、サービスコントロールポリシー（SCP）により、組織ユニット単位での一括したポリシー制御が挙げられます。

ここでは、SCPで制御したいポリシーの代表例として、CloudTrailへのアクセスを制御します。AWSアカウント運用のベストプラクティスとしてCloudTrailの有効化はほぼマストですが、各AWSアカウントでAdministrator権限からCloudTrailの設定を変更されるのは、セキュリティ統制上、好ましく有りません。

ここでは、サービスコントロールポリシーを利用して、メンバーアカウントによるAWS CloudTrailログの作成または変更を禁止します。マネジメントアカウントは、SCPの影響を受けないため、CloudTrail用のSCP適用後、ログの作成はマネジメントアカウントでの実施が必須となります。

Organizationsコンソールの「ポリシー」タブをクリックし、作成するポリシータイプで、「サービスコントロールポリシー」をクリック。

「ポリシーの作成」ボタンをクリック。

サービスコントロールポリシー作成画面が表示されるので、必要な情報を入力していきます。

ポリシー名：Block CloudTrail Configuration Actions
ポリシー入力欄で、サービス名にCloudTrailを入力
- アクションを選択：AddTags, CreateTrail, DeleteTrail, RemoveTags, StartLogging, StopLogging, UpdateTrail.
「リソースを追加する」ボタンをクリックし、以下を設定し「リソースの追加」
- AWSサービス：CloudTrail
- Resource type：All Resources

ポリシー欄が下記のようになっていることを確認。

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "Statement1",
			"Effect": "Deny",
			"Action": [
				"cloudtrail:AddTags",
				"cloudtrail:CreateTrail",
				"cloudtrail:DeleteTrail",
				"cloudtrail:RemoveTags",
				"cloudtrail:StartLogging",
				"cloudtrail:StopLogging",
				"cloudtrail:UpdateTrail"
			],
			"Resource": [
				"*"
			]
		}
	]
}

次に、本番環境組織ユニットでユーザーアカウントにアクセスを許可するAWSのサービスを定義し、ポリシー設定します。これにより、本番環境組織ユニットに所属するユーザーアカウントは、利用できるAWSサービスが制限されます。

上と同様の手順で、ポリシーを作成していきます。

ポリシー名：Allow List for All Approved Services

ポリシーペインで下記を入力。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Stmt1111111111111",
            "Effect": "Allow",
            "Action": [ 
                "ec2:*",
                "elasticloadbalancing:*",
                "codecommit:*",
                "cloudtrail:*",
                "codedeploy:*"
              ],
            "Resource": [ "*" ]
        }
    ]
}

最後に、メインアプリケーション組織ユニットにおいて、ユーザーのアクセスを拒否するポリシーを設定します。ここでは、DynamoDBへのアクセスを拒否するポリシーを設定します。

ポリシー名： Deny List for MainApp Prohibited Services

ポリシーペインで下記を入力。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [ "dynamodb:*" ],
      "Resource": [ "*" ]
    }
  ]
}

組織ユニットへのサービスコントロールポリシーの適用

ここまでの手順で作成したサービスコントロールポリシーをいよいよ、組織ユニットへ適用していきます。組織ポリシーの階層構造表示画面で、先程作成した「Production」組織ユニットを選択し、右側の「サービスコントロールポリシー」をクリックします。

すると、組織ユニットに対して適用可能なサービスコントロールポリシーの一覧が表示されます。ここで、アタッチとデタッチをクリックすることで、適用ポリシーの選択が可能です。

初期状態では、RootからFullAWSAccessのみがアタッチされている状態。

ここから先程作成したポリシーをアタッチすると、このようになります。

アカウントにアクセスし動作確認する

ここまでで、Organizations周辺の設定は完了したので、最後に、Production組織ユニットに所属するtestアカウントにログインし、サービスコントロールポリシーが正常に動作しているか確認します。

で、ここでふと疑問に思うのですが、先程testアカウントを作成しましたが、rootユーザーのパスワードなどは何も設定していません。これに関して公式ドキュメント上、以下の記載があります。

When you create an account, AWS Organizations initially assigns a long (64 characters), complex, randomly generated password to the root user. You can't retrieve this initial password. To access the account as the root user for the first time, you must go through the process for password recovery. For more information, see Accessing a member account as the root user.
引用：Creating an AWS account in your organization - AWS Organizations

要約すると、AWS OrganizationsからAWSアカウントを作成した場合、rootユーザーにはランダムなパスワードが割り当てられこの初期パスワードは取得することができません。初めてルートユーザーとしてアカウントアクセスするには、パスワード復旧のプロセスを実行する必要があります。

詳細はこちら。

Accessing and administering the member accounts in your organization - AWS Organizations）

具体的には、AWSコンソールログイン画面（https://console.aws.amazon.com/）より、ルートユーザーでログインし、ログイン対象AWSアカウントのメールアドレスを入力後、「パスワードをお忘れですか？」から、パスワードをリセットする流れとなります。

詳細な手順は割愛しますが、パスワードリセット後、作成したAWSアカウントにRootユーザーでログインしてみて、試しにCloudTrailのメニューにアクセスします。

すると、上部に「組織の証跡を作成するオプションは、このAWSアカウントでは利用できません。」と表示されます。

なんとまぁ、ルートユーザーでアクセスしているにも関わらず、CloudTrailの設定変更さえできないとは！　これが、いわゆるひとつのサービスコントロールポリシーによる制御というわけです。

上で設定したBlock CloudTrail Configuration Actionsのポリシーが適用されているのがわかります。

サービスコントロールポリシーの変更は、どの程度のタイムラグで反映されるの？

気になるところですね。実際にマネジメントアカウント上で、サービスコントロールポリシーのアタッチとデタッチを実施してみましたが、サービスコントロールポリシー変更による組織ユニットアカウントへの反映は即時適用でした。

上の例だと、Production組織ユニットにアタッチされているBlock CloudTrail Configuration Actionsをデタッチすることにり、CloudTrailの設定が即可能となることが確認できました。このあたり便利ですね！

SCPの設計において必読の記事

今回は非常にシンプルなOU構成でSCPの権限についてのチュートリアルをまとめましたが、実際の運用においては、OUが多段構成になるのが通常だと思われます。複数階層におけるOUやそれぞれのSCPの設計などは、弊社の川原征大が、こちらの記事でめちゃくちゃ丁寧に解説しているので、ぜひあわせて御覧ください！

Organizationsの機能による組織ユニット単位でのポリシー適用は超絶強力！！

実際にこれら基本的なOrganizationsの機能を試して見て感じたのは、その威力。

簡単な作業で、対象アカウントへの一括ポリシー適用が可能なのは非常に強力なのと同時に、オペレーションミスによる影響範囲もものすごく大きくなるのがまざまざとわかります。

実際に、組織でこのOrganizationsの機能を利用したガバナンスを適用させていくには、実運用上考慮しないといけない点が山のようにあります。今回は、あくまでOrganizationsの基本的な機能を体感するチュートリアルとして作成していますが、次回以降、実運用に耐えうる設定や設計についてもご紹介してければと思います。

それでは、今日はこのへんで。濱田（@hamako9999）でした。