サービスコントロールポリシー (SCP) とは
AWS Organizations における権限設定で出てくるサービスコントロールポリシー (SCP) について調べてみました。
SCPとは
サービスコントロールポリシー (SCP) - AWS Organizations
サービスコントロールポリシー (SCP) は、組織のアクセス許可の管理に使用できる組織ポリシーの一種です。SCPs では、組織のすべてのアカウントで使用可能な最大アクセス許可を一元的に制御できます。SCPs により、アカウントが組織のアクセスコントロールガイドラインに沿って活動することを確保できます。
より
IAM ユーザー単位ではなく、Organizations のアカウント単位でアクセス許可を一元管理できるということですね。
SCPによるアクセス許可
サービスコントロールポリシー (SCP) - AWS Organizations
IAMだけでは、組織のアカウントにアクセス許可を付与するには不十分です。SCPsSCP によって付与されるアクセス許可はありません。SCP は、アカウントの管理者が影響を受けるアカウントの IAM ユーザーおよびロールに委任できるアクションに対してガードレールを定義するか、制限を設定します。管理者は、実際にアクセス許可を付与するために、ユーザーまたはロール、またはアカウント内のリソースにアイデンティティベースまたはリソースベースのポリシーIAMをアタッチする必要があります。有効なアクセス許可は、SCP によって許可されるものと、 およびリソースベースのポリシーによって許可されるものとの論理的な共通部分です。
SCP によって付与されるアクセス許可はなく、実際のアクセス許可は SCP と IAM ポリシーの両方で許可されている部分だけになるようです。
SCPのアタッチ先
サービスコントロールポリシー (SCP) - AWS Organizations
AWS では、ポリシーがアカウントに与える影響を徹底的にテストせずに、SCPs を組織のルートにアタッチしないことを強くお勧めします。代わりに、お客様のアカウントを一度に 1 つずつ、または少なくとも少人数ずつ移動できる OU を作成し、誤って主要なサービスからユーザーを締め出すことのないようにします。
SCP は Organizations のルートではなく、OU (組織単位) を作って、OU にアタッチしましょうという内容です。OU 単位で SCP を設定することで、プロジェクトごとの権限設定も一元管理できるようになります。
SCPの影響範囲
サービスコントロールポリシー (SCP) - AWS Organizations
組織外のアカウントに属するユーザーやロールにも影響しません。
自分のアカウント内のみが対象です。
IAM ポリシーの AdministratorAccess と SCP
サービスコントロールポリシー (SCP) - AWS Organizations
アクセス許可が、暗黙的に (Allow ポリシーステートメントに含まれない)、または明示的に (Deny ポリシーステートメントに含まれる)、アカウントのレベルでブロックされている場合、影響を受けるアカウントのユーザーまたはロールは、アカウント管理者が / アクセス許可を持つ AdministratorAccess IAM ポリシーをユーザーにアタッチしても、そのアクセス許可を使用することはできません。
AdministratorAccess でも SCP でのアクセス権は無視できないようです。
ポリシーの影響範囲
AWS OrganizationsのSCP（サービスコントロールポリシー）を理解する | DevelopersIO
まずは、影響する範囲は以下の通りです。
- メンバーアカウントの以下のプリンシパル
- Root User
- IAM User
- IAM Role
逆に、以下のプリンシパルには影響しません。
- 組織のマスターアカウントに存在する全てのプリンシパル
- メンバーアカウントの以下のプリンシパル
- Service-linked Role
- リソースベースのポリシーで権限を付与された外部ユーザ
ここで注目すべきなのは、「Root Userの権限を制限できる」および「マスターアカウントの権限は制限できない」の2点です。
ルートユーザーの権限制限はできてもマスターアカウントの制限はできないんですね。
また、割愛しますがルートユーザーの権限でも制限できないアクションもあるので詳しくは上記ブログをご覧ください。
IAMとの関係
AWS OrganizationsのSCP（サービスコントロールポリシー）を理解する | DevelopersIO
SCPとIAMの両方で許可されている場合に実行可能です。 もう少し具体的に書くと、「双方で明示的に許可され」なおかつ「いずれでも明示的に拒否されていない」場合に権限を有していると評価されます。
両方で許可されていて、両方で拒否されていなければアクセス権を持つことができます。
SCPの継承について
[AWS Organizations] SCP(サービスコントロールポリシー)の継承の仕組みを学ぼう | DevelopersIO
ポイントは以下の 2 点です。
- 「暗黙の Deny」を把握する
- SCP 継承は「フィルター」である
明示的に Deny すればそのサービスには触れないのは分かりやすいですが、明示的に許可していないサービスにも触れないのは忘れがちなところでもあると思います。
まとめ
今回は AWS におけるアクセス権限管理の仕組みである SCP について調べてみました。
以下がポイントでした。
- Organizations のアカウント単位でアクセス許可を一元管理
- 実際のアクセス許可は SCP と IAM ポリシーの両方で許可されている部分
- OU 単位で SCP を設定することで、OU ごとの権限設定も一元管理
- 自分のアカウント内のみが対象
- AdministratorAccess でも SCP でのアクセス権は無視できない
- Root User の権限は一部を除いて制限可能だが、マスターアカウントの権限は制限不可
- 継承という仕組みがある
SCP はガードレールなので、本当にやってほしくない操作を禁止することに使用し、細かいアクセス制御は IAM で行うというのが一般的なのかもしれません。
今回の内容がどなたかの参考になれば幸いです。
Discussion