Zenn
🏢

個人でAWS Organizationsを使い始めてみた

2024/11/22に公開
AWS
awsorganizations
tech

タイトルの通りですが､AWS Organizationsで個人のアカウントを管理するようにしてみました｡

なんでAWS Organizationsを使おうと思った?

今自分のAWSアカウントの利用状況をまとめると2つあり､Route53など消えると困る物が動いているアカウントと､あんまり使ってないけど遊びに使えるアカウントがありました｡
遊びに使える方のアカウントは今後ハンズオンなどで使用して作ったものをaws-nukeで吹き飛ばせれば消し忘れとかも少なくなっていいだろうと考えています｡

そうなったときに､複数のアカウントを別々に管理したくなかったっていうのが表向きの理由で､AWS Organizationsを管理してみたかったっていう興味がリアルな理由です｡

やってみよう

管理アカウント発行

この記事を読まれている皆様はAWSアカウントを発行する手順はご存知かと思いますので詳細は省略いたします｡
新規にアカウントを発行する理由としては管理アカウント上にリソースを作るのはベストプラクティスに反するからです｡[1]
管理アカウントはそれ自体にAWS Organizationsのサービスコントロールポリシー(SCP)を反映することができず､他のアカウントに課している制限を受けないため本当に管理アカウントでなければならないもの以外は組織内の別アカウントにデプロイするべきです｡

管理アカウントでAWS Organizasionsの設定をしよう

管理アカウントでマネコンにログインしましょう｡
AWS Organizationsを開き組織を作成をクリックしましょう｡AWS Organizationsが有効になります｡(痛恨のスクショ忘れ)

AWS Organizationsを有効にしたあとは画面のようにAWS Organizationsで管理するアカウントを確認したり追加できる画面に遷移します｡
AWSアカウントを追加をクリックしましょう｡ここでAWS Organizationsへ参加するアカウントを作成したり､既存アカウントを招待したりできます｡

今回自分は既存のアカウントを追加したいので既存のAWSアカウントを招待を選択します｡

招待したいAWSアカウントのメールアドレスかアカウントIDを入力すればそのまま招待できます｡複数同時に招待もできそうです｡
タグで別々な値を設定したかったので今回は2つのアカウントを別々に招待しました｡

招待を受けたアカウントですること

招待を受けたアカウントのメールアドレス宛にAWSから招待メールが来ます｡本文中にどのアカウントから招待が来たか記載があるので確認して先ほど作業したアカウントからの招待であればAccept invitationをクリックしましょう｡
もしくは招待を受けたアカウントのマネコンからAWS Organizationsを開くと1件の招待を表示と表示されていますのでそこをクリックしても同じ画面へ遷移できます｡

リンクをクリックすると招待を承認するか拒否するかの画面が表示されますので､管理アカウントの名前､メールアドレス､組織IDを確認しましょう｡組織IDは管理アカウント側のAWS Organizationsの左側のメニューに表示されています｡

招待を承認すると組織の詳細と組織を離れる画面に遷移します｡これで招待を受けたアカウントが組織に参加できました｡

管理アカウント側のAWS OrganizationsのAWSアカウントの画面を更新するとさきほど追加したアカウントがRootに追加されていると思います｡

組織単位(OU)の作成

AWS OrganizationsはRootから木構造で組織単位(OU)をそれぞれの下に追加していくことで組織を表現しています｡
OUとはAWSアカウントアカウントをグループ化することを実現するための要素です｡
OUとAWSアカウントにはサービスコントロールポリシー(SCP)を設定することができ､それぞれ実行できるサービスやアクションを制限できます｡SCPを特定のOUにアタッチした場合､そのOUと子OUにあるAWSアカウントにポリシーが継承されます｡AWSアカウント自体にアタッチした場合アタッチされたAWSアカウントにのみ影響を与えます｡また､RootにアタッチすればすべてのOUとAWSアカウントに継承されます｡
つまり大規模な組織のOUの設計は途中で変更するのはとても辛い作業を伴うことが想像できますので､最初のOU設計が重要だと考えられます｡もし企業や団体で設計する際にはきちんと議論と検討を重ねて作成することをおすすめします｡[2]
ただ今回は全部自分の管理下にあるアカウントを管理するだけなのでOUは"prd"と"dev"の2つに分けます｡

Rootにチェックマークを入れたあとにアクションの組織単位→新規作成からOUの作成画面へ遷移します｡
OUの名前と必要に応じてタグを設定します｡



OUへ移動

OUを作成したあとに追加したAWSアカウントをそれぞれのOUへ移動させます｡初期状態ではRootに直接ぶら下がっている状態です｡
移動させたいAWSアカウントのチェックマークを入れたあとにアクションのAWSアカウント→移動からAWSアカウントを移動させる画面へ遷移します｡

移動先のOUを選択してAWSアカウントを移動をクリックしましょう｡

正常に処理できれば組織構造から移動したOUの直下にAWSアカウントが移動したことを確認できます｡

サービスコントロールポリシー(SCP)の設定

サービスコントロールポリシー(SCP)については2個上の章で少し触れましたが､OUやAWSアカウントで実行できるサービスやアクションを制限することができます｡
IAMポリシーと同じような書き方で作成できます｡
AWSの Organizationsの左側のメニュー､ポリシーからサービスコントロールポリシーを有効にできます｡



デフォルト値はRoot,すべてのOU,アカウントに以下の FullAWSAccess ポリシーがアタッチされています｡

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

見た目からも分かる通り初期設定はすべてを許可しています｡

SCP設定時の注意点

SCPを設計する際にはいくつかの注意点があります｡IAMポリシーの設計時にも注意が必要な暗黙のDenyについては同様に注意が必要です｡
最も強い力を持つのは明示的なDeny､つまり拒否を明記しているものです｡次に明示的なAllow､これは許可を与えています｡最後に暗黙のDenyです｡これは該当するものに対して拒否も許可も明記されていない状態です｡この場合権限を与えられていない状態として拒否されます｡
例えば以下の様なポリシーのみがアタッチされているとします｡

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

これはS3への一切の操作を拒否するポリシーですが､これだけがアタッチされている場合､実際にはS3以外のリソースも操作することが拒否されます｡
暗黙のDenyにより明記されていないS3以外のリソースが拒否されているためです｡
これの対策として明示的なAllowとして例えばデフォルトのFullAWSAccessをアタッチしておくことでS3以外のリソースには触れることができます｡

もう一つの注意点が複数のポリシーが継承されることで許可される範囲が狭くなっていくことです｡
SCP自体は許可を与えるものではなく､拒否するものを決定するためにあります｡
IAMの評価論理フロー[3]の2番目がSCPによる評価ですが､Allowだった場合次のリソースベースのポリシーへ判断を委ねています｡Denyである場合ここで判定が決定されます｡
更に､SCPの中でもRootから順に継承されてくるSCPを評価していきます｡

例えば画像のNo.1の場合､FullAWSAccessがRoot,OU,AWSアカウントにアタッチされているため､最終的にAWSアカウントではFullAWSAccessのポリシーが適用されています｡
No.2の場合OUにAllowS3*(S3に関するすべての操作を許可)のポリシーのみがアタッチされているため､AWSアカウントにFullAWSAccessがアタッチされていても実際にはAWSアカウントにはS3以外の操作は拒否されてしまいます｡
No.3の場合は更に問題でOUにDenyS3*(S3に関するすべての操作を拒否)がアタッチされているため､AWSアカウントには何も権限が残されていない状態になっています｡(暗黙のDenyを継承している)
No.4はNo.3の問題点を修正するように設定しています｡DenyS3*で制限したかったのはS3の操作のみですので､FullAWSAccessと同時にアタッチすることでAWSアカウントにはFullAWSAccessで与えられている明示的なAllowとDenyS3*で与えられる明示的なDenyにより､S3以外の操作はSCPでは制限されないようになります｡

脚注

  1. 管理アカウントのベストプラクティス ↩︎

  2. AWS Organizations における組織単位のベストプラクティス ↩︎

  3. ポリシーの評価論理 ↩︎

Discussion