1. はじめに
1-1. 背景
お客様が利用するAWS環境のセキュリティを確保することは重要で、特にお客様がマネコン・CLI等を経由してAWSサービスを用いた分析や開発等を行うための環境を提供する場合は、あらかじめ組織の管理者側で、業務データの持ち出しや既存リソースの設定変更、その他セキュリティリスクのある動作ができないように統制を行う必要があります。
AWS Organizationsの一機能であるSCP（サービスコントロールポリシー）は組織内のAWSアカウントを統制するために有用な機能ですが、扱う機会が少なく、知見を持っている人も少ない印象を覚えます。
1-2. 目的
本記事では、SCPを用いたセキュリティの統制を行えるように、SCPの概念や利用方法、注意点について説明いたします。
2. 一般的なセキュリティ確保手法
セキュリティを統制するためのアプローチとしては、一般的に以下の二つが挙げられます。
予防的統制
⇒セキュリティインシデントを未然に防ぐために、逸脱行為を予めできないように権限を拒否すること。
発見的統制
⇒設定ミスや異常なふるまいを検知して、通知もしくは健全な状態へ自動復元すること。
基本的に予防的統制のほうが、発見的統制と比較して逸脱行為を強く制限できるため、まずは予防的統制を実現できないか検討します。
上記2つの統制のために利用されるAWSサービスの例はそれぞれ以下の通りにマッピングされます。
本書では、主に以下のSCPについて記載します。
| 統制手法 | AWSサービス例 |
|---|---|
| 予防的統制 | AWS IAM、AWS Organizations - SCP |
| 発見的統制 | AWS Config、AWS IAM Access Analyzer |
3. SCPについて
3-1. SCPの概要
SCPはAWS Organizationsで管理している組織内のアカウント群に対し、アクセス許可を一元的に管理する機能です。
IAMポリシーはAWSアカウント内のリソースごとに個別にアタッチされるのに対し、SCPはOU単位（組織内のAWSアカウントをグルーピングしたもの）、またはAWSアカウント単位でアタッチされるため、容易に複数のアカウントのアクセス許可を制御可能です。
以下がSCP（＋IAM）の概念図です。
OUはツリー構造になっており、上位OUにアタッチされたSCPの制限が下位OUやAWSアカウントに適用されるイメージです。
3-2. SCPとIAMの用途の違い
SCPとIAMポリシーはどちらもアクセス制御を行うサービスですが、以下のような用途の違いがあります。
①IAMの使用だけで十分なケース：組織管理がされていない環境
⇒組織管理をしていない環境でシステム管理者がシステムの管理を行い、AWSリソースを全て作成・管理する環境の場合、IAMだけで問題ない。
②SCPも使用する必要があるケース：組織管理されており、各システムの管理者が限られた権限の範囲内で開発や操作を行う環境
⇒組織の管理者がセキュリティリスクのある操作（外部へのデータ持出等）を一定制限しつつ、システムの管理者が限られた権限の範囲内でAWSの開発や操作を行うための環境を提供したい場合、システム管理者側でIAMを自由に設定可能にする必要があるため、IAMよりもさらに強力なSCPを利用する必要がある。
3-3. アクセス許可の概念 - SCPとIAM
SCPを使用している場合、AWSアカウント内のリソースへのアクセス許可は主にSCPとIAMポリシーによって決定されます。
SCPとIAMポリシー内ではAllow（許可する操作）とDeny（禁止する操作）の二種類に大別されますが、SCPとIAMポリシーの両方でAllowされた操作のみが可能となります。
SCPは新たに許可を与えるものではなく、AWSアカウント内で実行可能な最大権限を定義するものであることに注意してください。
以下に例を示します。
例1: SCPでEC2の作成が許可されているが、IAMポリシーではEC2の作成が明示的に禁止されている
⇒EC2の作成はできない
例2: SCPでEC2の作成が明示的に禁止されているが、IAMポリシーではEC2の作成が許可されている
⇒EC2の作成はできない
例3: SCPでEC2の作成が許可されており、IAMポリシーでもEC2の作成が許可されている
⇒EC2の作成はできる
例4: SCPでEC2の作成が許可されているが、IAMポリシーではEC2の作成が暗黙的に禁止されている
⇒EC2の作成はできない
例5: SCPでEC2の作成が暗黙的に禁止されているが、IAMポリシーではEC2の作成が許可されている
⇒EC2の作成はできない
要するに、禁止の方法が明示的（Denyポリシーで定義）であろうが暗黙的（DenyでもAllowでも定義しない）であろうが、IAMとSCPの両方でAllowの設定を行った操作しか実行できません。
3-4. アクセス許可の概念 - OU階層
3-1. に示した通り、上位のOUにアタッチされたSCP内で定義されたアクセス許可は下位に配置されている全てのOU・AWSアカウントに適用されます。
各組織構造におけるアクセス許可の評価結果は以下の通りです。
3-5. アクセス許可方式の決定
SCPで権限制御を行う際、開発するシステムの要件に合わせて以下の2通りのアクセス許可方式から選択します。
①ホワイトリスト形式
⇒SCP内で必要な操作権限の許可のみを定義し、それ以外の操作はすべて禁止する方式。
必要最小限の操作しかAWSアカウントに許可しないため、セキュリティ強度が向上する反面、AWSアカウントで可能な操作の自由度が低下する。
②ブラックリスト形式
⇒SCP内で禁止する操作のみを定義し、それ以外の操作はすべて許可する方式。
明示的に禁止されている操作以外はAWSアカウントに許可されるため、セキュリティ強度が低下する反面、AWSアカウントで可能な操作の自由度が向上する。
SCPでの実装方法
上記のアクセス許可方式をSCPで実装する方法を説明します。
各OUやアカウントにはFullAWSAccessというAWSマネージドのSCPが、唯一デフォルトでアタッチされています。
（SCP有効化時に、存在するすべてのOUおよびAWSアカウントにアタッチされます。OU・AWSアカウントを新規作成した場合も自動でアタッチされます）
FullAWSAccess内では、AWSアカウント上での全ての操作を許可するポリシーが定義されており、それに加えて、ユーザ側でカスタムのSCPを作成して組み合わせることで、組織内のアクセス制御を行うができます。
FullAWSAccessとカスタムのSCPを以下のように併用して、ホワイトリスト形式とブラックリスト形式を実現できます。
3-6. IAMとSCPの仕様の違い
IAMとSCPはポリシーの文法が同じであり基本的に制御できる内容も同じですが、一部機能に細かい違いがあるため、下表に示します。※下表に示すものが全てではありません。
SCPとIAMはポリシーの文法が同じであり、細かい仕様も同じだと思って使いがち（筆者も最初はそう思いながら使っていました。。）ですが、思わぬところに仕様の違いがあります。
特に、IAMポリシーのエディタ上でSCPに使用するポリシーを作成していた場合、IAMポリシーのほうでは文字数の上限に達していなかったのに、SCPに適用しようとすると文字数オーバーになって設定できない！などの事態に陥ることがありますので、あらかじめ仕様の違いを頭に入れておきましょう。
4. まとめ
SCPは組織内のアカウントのセキュリティを向上させるための強力な機能ですが、概念や細かい仕様に若干違いがあります。利用の前にあらかじめ違いを調査したうえで、システムの設計を行いましょう。
また、SCPは万能ではなくSCPだけではシステムを統制しきることはできないので、Config、IAM Access Analyzer、Firewall Manager等の他サービスを併用することを念頭に置いて設計を行うことも大切です。