AWS公式が提供しているハンズオン講座を実際にやってみて、気になった内容を整理したいと思います。
この記事はAWSを独学で勉強している私が特に気になった内容を留めておくものです。
インフラ素人、高校の情報のテストで赤点取った人が「なんとなく」AWSを理解することをテーマに勉強した内容や気になった内容をまとめてます。
SCPと許可セットとポリシーの関係性
SCPと許可セット、ポリシーの関係性について、いまいち理解ができなかったので整理したいと思います。想定するシステムは次のような構成です。
そもそも、SCPや許可セット、ポリシーがなんだっけ？という方は、次の記事をご覧ください。
自身のルートユーザーから作成した管理者用ユーザーを親にして、複数のAWSアカウントをまとめて管理するためにAWS Organizationsを利用して１つの組織（Organizations）を形成しています。
その中で、開発環境用のアカウントが属するOrganizations Units（OU）と、本番環境用アカウントが属するOUが構成されています。
そして、その複数のAWSアカウントに対して、アカウントの切り替えを行うことなくシームレスに接続するために、AWS Identity Centerというサービスを使って、SSO（シングルサインオン）を実現します。
さらに、開発用アカウントおよび、本番用アカウントはあくまでアカウントであるため、実際にAWSを操作するためのユーザをアカウントからユーザーを払い出しています。
今回は、上記のような構成の時に、Identity Cneterに対して設定する許可セット、OU及びOUに属するAWSアカウントに対して設定するSCP、そしてAWSアカウントから払い出される個別のユーザーに対して設定するポリシーの関係性についてまとめています。
結論
①SSOユーザに割り当てる許可セット、OU及びAWSアカウントに対して割り当てるSCP（サービスコントロールポリシー）で許可されているアクションのみ実行可能。
②SCPで拒否されているアクションは、AWSアカウントから払い出したユーザに対して割り当てるポリシーで許可しても、そのアクションは実行不可。
図にするとこんな感じです。
動作検証
ここからは動作検証のエビデンスのため、結論だけ確認したかった方は確認不要です。
備忘録的に残している内容になります。
①AWS OrganizationsでOrganizationsに所属させたいアカウントを設定・追加
今回は、アカウントを追加する。
②Service-a-prodアカウントを作成し、Workload OUに所属させる。
③Identity CenterからOUに属するService-a-prodアカウントと、SSOユーザ/SSOグループとを紐付ける。※SSOユーザの作成手順書は省略。
④Service-a-prodアカウントに、許可セット「AdministratorAccess」を割り当てる
⑤設定の確認。
service-a-prodは、SSOユーザのSSOできるようになるアカウントの１つとなり、更にその権限設定として許可セット「AdministratorAccess」が付与された。
⑥設定完了。
AWSアカウントをSSOユーザーに割り当て、SSOユーザーとして割り当てた時の権限（許可セット）を割り当てた。
今回は、service-a-prodアカウントの１つしか便宜上作成していないが、Service-a-prodアカウントを開発用、本番用のアカウントとして疑似的に切り替える検証を進める。
このService-a-prodアカウントに対して、この後SCP設定を行い、それぞれの設定の違いによる挙動の違いを確認する。
⑦SCP設定で拒否設定をしない場合を確認
AWS Organizationsから、Organizationsの管理アカウントとなっているservice-a-prodに対してSCPを設定する。ただし、今回は特別な設定（拒否設定）はせず、すべて許可した状態。
⑧SSOユーザでログインする
先ほど、SSOユーザで管理するアカウントとしてservide-a-prodを紐づけたため、SSOのアクセスポータルにアカウントが表示された状態になっている。
⑨service-a-prodアカウントにSSOでログインし、EC2を確認。
特にアクセス拒否はしていないので、問題なく確認可能。
⑩次に、SCP設定で拒否設定をした場合を確認
SCPとして、EC2へのアクセスを拒否するポリシーを作成（手順省略）し、Organizationsで管理されているSevice-a-prodアカウントに対して付与。
⑪再び、SSOユーザでログインする
⑫service-a-prodアカウントにSSOでログインし、EC2を確認。
今度は、SCPでservice-a-prodアカウントは、EC2へのアクセスが拒否されているため、APIエラーが発生する。
図解にするとこのような状態であるため、EC2へのアクセスができなかったことになる。
⑬さらに、この状態から、Service-a-prodアカウントをもとにservice-a-prod-user1というAWSユーザを払い出してみる。そして、このユーザーに対してEC2へのアクセス権限を付与してみる。
⑭作成したservice-a-prod-user1でログインし、EC2にアクセスする。
しかし、アクセスしてもEC2に対してAPIエラーが発生したまま。
これは、service-a-prod-user1のアカウントであるservice-a-prodアカウント自体（並びに所属するOU）そのものに対してSCP設定によってEC2へのアクセスが禁止されているため。
これが、まさにガードレール戦略であり、組織として拒否したい設定をOrganizationsという単位で設定しておくことで、個別設定で覆すことができないようにしている。
⑮さらなる動作検証として、service-a-prodアカウントに対して、SCP設定を変更してみる。
先ほど付与したEC2へのアクセスを禁ずる権限を削除してみる。
⑯再びservice-a-prod-user1でログインし、EC2にアクセスする。
すると、今度はEC2にアクセスしてもAPIエラーは発生しない。
つまり、先ほどAPIエラーが発生していた原因がSCPによるものであったことがわかる。
最後に
以上、いかがでしたでしょうか。
何かの理解の一助になれば大変光栄です。
最後に、あくまで勉強の記録を残すことが主な目的ですので、正確な内容を確認されたい方は公式ドキュメントなどをご確認ください。
コメント