本記事では、AWS Organizationsを使用してSCP制限をメンバーAWSアカウントに設定する際、例外プリンシパルとして誰を設定しておくのかという課題を整理します。(自分の今の理解をダンプするだけですが。。。)

前提とやりたいこと

セキュリティ統制のキーとなる機能を厳格に保護するために、AWS Orgnizationsのサービスコントロールポリシー (SCP)を使用します。たとえば、Internet Gatewayの設置や、CloudTrailの無効化をSCPで禁止するようなことを想定します。
この制限を一律に禁止してしまうと開発や運用が回らなくなってしまうので、それぞれの禁止操作ごとに例外プリンシパルを設定して、『その操作は危ないから、許可された人しかやっちゃダメだよ。』と限定的な委譲を実現します。　これが本記事のゴールです。

ちなみに、今回ははSCPを中心に記事を書きましたが、多くの現場ではIAMプリンシパルごとに、やっていいこと、いけないことを設定できれば十分にセキュアに統制できると思います。IAM Permissions Boundaryもありますし。本書は『どうしてもSCPでやらねばならんのじゃ！』となってしまったシーン向けの記事です。

選択肢と考え方

さて、『誰を例外プリンシパルに設定するか』という課題への答えを探します。難しい課題ですが、とりえる選択肢はそんなに多くはないような気がします。

私の選択フローを以下にまとめます。基本的にメカニカルに実装が可能な構成基準違反の抑制等はControl TowerとかCICDパイプラインに担わせる、メカニズムに任せれらない運用オペレーションの統制は人に担わせるようなアウトラインで考えてます。

(1) Control Towerを例外プリンシパルに登録する。

大前提として、Control TowerのマネージドのSCPが使える状況なら積極的に使いたい。Control TowerマネージドのSCPの多くで、AWSControlTowerExecutionが例外プリンシパルに登録されるから、実装負担が少ないです。

Control Towerの管理者＝CCoEみたいな小さな統制組織なら、自作SCPの例外プリンシパルにもAWSControlTowerExecutionを登録して、CCoEもこれを使ってしまうという実装ができます。

(2) CICDパイプラインを例外プリンシパルに登録する。

構成基準の維持（無用なクロスアカウント許可は禁止とか）は、できるだけConfigルールとかSecurity Hubセキュリティ標準とかの監視（発見的統制）で実装するわけですが、どうしてもそれでは心配な場合もあります。そういう場合はCICDパイプラインを使います。

まず、その操作をSCPで禁止し、CICDパイプラインを例外プリンシパルとして登録します。
CICDパイプラインからなら当該リソースを作れるようになり、CICD以外からは当該リソースを作成変更できなくなります。
CICDパイプライン上で静的解析やコードレビュー＆承認を必須とすることで、構成基準違反をデプロイ前に（未然に）防ぎます。

以下の実装3でも同じようなことはできますが、AWS側だけでなくてパイプライン側でも認証や証跡が取れるメリットがあります。逆に、外部サービスの認証でAWSへのデプロイ特権（AdministratorAcessとか）が取れちゃうという点は、デメリットです。CIとCDの権限分離などのgitOps的な観点もセットで考えるといいかなと思います。

(3) User Teamの管理者を例外プリンシパルに登録する。

s3:PutBucketPolicyのような、プロダクション運用でしょっちゅう発生するようなオペレーションに関しては、User Teamが自ら実施できるようにしないと運用が回りません。そもそも、SCPで禁止する必要があるのか、IAMポリシーで条件付き許可や、Configルール等による基準違反の監視でカバーできないかよく検討したほうがいいです。

そういったオプションも検討した上で、それでもSCPで制限したい場合には、例外管理者にUser Teamの管理者を登録する選択肢も浮上します。いちいちCCoEに変更を依頼されるよりは迅速な運用が期待できます。

イメージ的には、User Teamの中に、PowerUserAccess（PUA）と、特権なしAdministratorAccess（AA）と、特権付きAdministratorAccess（AA＋）の3ロールが存在する感じ。AA＋さんをSCPに例外プリンシパル登録しておく感じです。
一般開発者はPUAやAAを普段使いしてもらって、ペリメタ変更や特権昇格等の統制に関わる操作だけUser Teamの管理者がAA+で実行する形になります。

(4) CCoEの管理者を例外プリンシパルに登録する。

『現場にはまかせられない！自分たちでやらなきゃ！』というように、上記の選択肢がいずれも取れないCCoEの場合、自分を例外プリンシパルに登録せざるを得ないかもしれません。運用がスムーズに回るように、そもそもSCPで制限する範囲と、他の予防的な統制や訂正的な統制でカバーする範囲を適正化する必要があります。

この実装だと、『そもそもこの機能は誰も使っちゃダメ。』のようにAWSサービスや機能の利用を組織として制限するケースもあります。組織が期待されるセキュリティレベルは様々なので、やむを得ない側面もあります。とはいえ、せっかくクラウドを使ってビジネスを変革するチャンスなので、ITがブレーキにならないように統制を実装したいものです。

(5) 例外プリンシパルには誰も登録しない。

(4)の亜種として、SCPに例外プリンシパルを登録しないという選択肢もあります。この場合、もしSCPで制限した操作を実施したくなったときは、SCPを一時的に外すか、SCPのないOU（ピットインOU）にAWSアカウントを一時退避することなります。

こういったSCPのON/OFF操作はCCoE的な中央管理になっているでしょうから、本当に低頻度のものなら実装上の負担を考慮して、実装4ではなくてこっちにしたほうがメリットがあります。

選択肢は択一ではない。考慮点も。

言わずもがななことですが、SCPではセクションを区切れば、権限ごとに例外プリンシパルを組み替えることができますし、複数のプリンシパルを並列で例外登録することもできます。だから、前述の5つの例外プリンシパルをうまく使い分けたり組み合わせたりして、組織の開発や運用にふさわしい制御を計画できます。

IAMの世界観でできることも多いし、ConfigやSecurity Hubによる構成基準監視もきちんと運用さえ回せれば効果があります。（運用回すのが大変なんですが。。。）

まとめ

まとめるとこんな感じ。

個人的には特権はできるだけCICDパイプラインに寄せて、構成基準に違反したインフラがデプロイされないように、メンバーやCCoEがパイプライン上で前捌きできるようにしていくのがベターかなと思ってます。パイプラインが神様になってしまう問題はあるので、パイプラインの保護もしっかりやりつつという感じです。

これは現時点の理解で、まだしばらくこの領域のベストプラクティスは変化しそうです。SCPへの例外プリンシパルの書き方にはご作法があります。文法などのご作法はこちらの記事もご利用ください。