AWS再入門2023 Organizations SCP編

川原征大

2023.11.14

AWS Organizations を使ってマルチアカウント管理を推進されている方の多くは、 SCPを活用されているのではないでしょうか。 SCPは組織のセキュリティ統制、特に予防的ガードレールとして役立つ便利な機能です。

そんなSCPについて、概要や設計・運用のポイントを改めておさらいしてみます。

本ブログがSCPを活用している、もしくはこれから活用しようとされている方への参考になれば幸いです。

SCPの概要
- SCPとは
- SCPの実体
設計前のインプット
- SCPの効果範囲
- SCPはアクセス許可を与えない
- SCPの評価のされかた
- ほか細かい制限/仕様
設計のポイント
- 拒否リスト形式を採用する
- 使わないリージョンを制限する
- 管理者が作成した設定を保護する
- セキュアな利用を強制する
運用のポイント
- SCPをコードで管理する
- SCPを検証できるようにする
- SCP管理をメンバーアカウントに委任する

SCPの概要

SCPとは

Service Control Policy(SCP) は AWS Organizationsの1機能です。 SCPにより、組織内のIAMユーザー/IAMロールのアクションを制限します。

AWS環境の「予防的ガードレール」として活用できます。

📌Tips: 予防的ガードレールについて

そもそものガードレールはセキュリティ統制の考え方です。「利用者の手を止めること無く」セキュアな状態で開発できるように目指します。

ガードレールには大きく2種類あります。 実施してはいけない操作を禁止する「予防的ガードレール」 と、リスクのあるイベントを発見してアラートを行う「発見的ガードレール」です。

SCPの実体

SCPの実体はIAMポリシーです。組織のルート、OU、またはAWSアカウントへSCPをアタッチします。

デフォルトでは全てのルート、OU、アカウントに FullAWSAccess SCPがアタッチされています。

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

設計前のインプット

設計前に押さえておきたい、SCPの仕様や制限を記載します。

SCPの効果範囲

冒頭で言ったとおり、 SCPはルート、OU、またはAWSアカウントへアタッチできます。

そしてアタッチした効果はメンバーアカウントの、 IAMユーザー、IAMロール、そしてルートユーザーに及びます。

管理アカウントはSCPの影響を受けません 。

SCPはアクセス許可を与えない

SCP自体はIAMユーザーやロールに対して、 新たに許可を与えません 。 SCPはAWSアカウント内で実行可能な最大権限を制限するものです。

少し詳細を話します。以下はIAMの評価論理を表したフローです。

– 画像引用: ポリシーの評価論理 - AWS Identity and Access Management

枠で囲った部分がSCPによる評価パートです。 SCPパートで判決されるのは Deny のみですね。そうでない場合は次のポリシーへ判断を委ねています。ここからも SCPが許可を与えないことが分かります。

イメージとしては SCPは単なる許可 "フィルター" と考えると良いです。フィルターなので許可を通しますが、新規には与えません。

SCPの評価のされかた

あるAWSアカウント上で特定のアクションをリクエストしたとします。

そのアクションが許可されるには、 以下要素のそれぞれに明示的なAllowが必要 となります。

AWSアカウント自身
AWSアカウントの上位にあるOU
組織のルート

つまり、明示的なAllowが無いと拒否されます。デフォルトで拒否されるモデル(暗黙的な拒否)ということです。

もちろん明示的なDenyがあったときは、Allowを書いていたとしても拒否されます。

🎨 SCP評価のイメージ

例を交えてイメージを載せていきます。

(例1) SCPを有効化した際のデフォルトです。メンバーアカウントに対する制限は特にありません。

(例2) OUにアタッチした SCP(Deny IAM Actions) により、配下にあるメンバーアカウント上でIAMアクションが拒否されます。

(例3) OUでは SCP(Allow EC2 Actions) のみアタッチされています。暗黙的な拒否により、それ以外のアクションが拒否されます。

(例4) やってはいけない例です。暗黙的な拒否により、メンバーアカウント上で全てのサービス/アクションが拒否されます。

ほか細かい制限/仕様

以下の制限/仕様を押さえておきましょう。

✅ アタッチ数

各要素(OUやAWSアカウント)へアタッチできるSCPは 5個までです。

✅ 文字数制限

SCPの上限サイズは 5120文字 です。もし上限サイズに近づいている場合、空白文字を削除してスペースを節約できます。

✅ ポリシー構文

SCPはIAMアクセス許可ポリシーとほぼ同じ構文を取ります。ただ、一部表現できない記述がありします。

具体的には以下部分を押さえておくと良いでしょう。

Allowステートメントを使うとき
- NotAction と Condition は使えない
- Resource句には "*" (= 全てのリソース)しか指定できない
Action/NotAction でワイルドカードを使うとき、文字列の間には入れられない
- OKの例: "*" (= 要素自身)
- OKの例: "iam:*" , "iam:List*" (文字列の末尾)
- NGの例: iam:*Role (文字列の中間)
以下要素は使えない
- Principal/NotPrincipal
- NotResource

設計のポイント

拒否リスト形式を採用する

拒否(Deny)リスト形式は主に「Deny ステートメントのSCP」をアタッチしていく方式です。禁止させたいアクションをSCPに記述していきます。

▲ 拒否リスト形式の適用イメージ

拒否リスト形式のルールは以下のとおりです。

全ての要素には FullAWSAccess をアタッチする
各OUに「Deny ステートメントのSCP」をアタッチする

実際に適用する「DenyステートメントのSCP」のオススメについては次項で説明します。

📌Tips: 許可リスト形式

許可(Allow)リスト形式もSCP戦略の1つです。許可リスト形式では「Allow ステートメントのSCP」をアタッチしていきます。

▲ 許可リスト形式の適用イメージ

許可されるサービスやアクションを列挙します。明示的に記載したサービス、アクション以外は拒否されます。

セキュリティ要件が厳格で、使って良いAWSサービス/アクションが明示的にリストできる場合には活用できます。

ただし、一般には許可リスト形式のほうが メンテナンスコストが高い です。経験上「本来はアクセスさせたいアクションが、考慮漏れがありアクセスできない」事態が運用中に多発することが多いです。

使わないリージョンを制限する

特定リージョン上でのAWSアクセスを禁止できます。普段使わないリージョンで、意図しないリソースが作成されてコストもしくはセキュリティリスクになることを未然に防げます。

例えば東京リージョンと大阪リージョン以外で AWSアクセスを禁止したい場合は、以下のようなSCPを適用します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "GRREGIONDENY",
      "Effect": "Deny",
      "NotAction": [
        # ここに禁止させたくないサービス:アクション一覧を記載する
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "ap-northeast-1",
            "ap-northeast-3"
          ]
        },
        "ArnNotLike": {
          "aws:PrincipalARN": [
            "arn:aws:iam::*:role/ExampleOrgAdminRole"
          ]
        }
      }
    }
  ]
}

このSCPを日本語で説明すると以下のようになります。

Condition: リクエストされたリージョンが「東京、大阪」以外で
Condition: かつ、 ExampleOrgAdminRole ロールではないときに
Resource: 全リソースに対する
NotAction: 禁止させたくないサービス:アクション 以外のアクションを
Effect: 禁止する

禁止させたくないサービス:アクション には「例外なく全リージョンで必要なサービス」もしくは「グローバルサービス」を列挙します。

グローバルサービスを列挙する理由は、「これらのエンドポイントはバージニア北部 us-east-1 に設置されているものがあるため」です。例えば IAM や CloudFront などが当てはまります、

「具体的に何を列挙したほうが良いか」は Control Tower で使われているリージョン拒否コントロールの内容を参考にすると良いでしょう。

– 画像: リクエストされた AWS リージョンに基づいて AWS へのアクセスを拒否する - AWS Control Tower

※Control Tower 環境であれば、このリージョン拒否コントロールの有効化を Control Tower マネジメントコンソールから適用できます

リージョン拒否コントロールの設定 - AWS Control Tower

管理者が作成した設定を保護する

管理者が初期設定したサービスやリソースを破壊されないようにします。

例を紹介していきます。

AWSアカウントの初期設定として、AWS Configを有効化して Configルールを展開したとします。これらを無効化/削除されないようにしたいです。そんなときは以下のようなSCPをアタッチして保護できます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "config:DeleteConfigRule",
        "config:DeleteConfigurationRecorder",
        "config:DeleteDeliveryChannel",
        "config:StopConfigurationRecorder"
      ],
      "Resource": "*"
    }
  ]
}

– 引用元: ユーザーによる AWS Config の無効化またはルールの変更を禁止する - AWS Organizations

次の例は特定リソースを保護するSCPです。特定IAMロールを管理者以外は変更できないようにします。

{    
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAccessWithException",
      "Effect": "Deny",
      "Action": [
        "iam:AttachRolePolicy",
        "iam:DeleteRole",
        "iam:DeleteRolePermissionsBoundary",
        "iam:DeleteRolePolicy",
        "iam:DetachRolePolicy",
        "iam:PutRolePermissionsBoundary",
        "iam:PutRolePolicy",
        "iam:UpdateAssumeRolePolicy",
        "iam:UpdateRole",
        "iam:UpdateRoleDescription"
      ],
      "Resource": [
        "arn:aws:iam::*:role/name-of-role-to-deny"
      ],
      "Condition": {
        "StringNotLike": {
          "aws:PrincipalARN":"arn:aws:iam::*:role/name-of-admin-role-to-allow"
        }
      }
    }
  ]
}

– 引用元: 指定された管理者ロール以外の IAM ユーザーとロールが特定の変更を行うことを禁止する - AWS Organizations

特定リソースを保護したい場合は、リソースのARN(Resource句で指定)、もしくはリソースタグ(Condition句で指定)が役立ちます。

セキュアな利用を強制する

開発者にセキュリティベストプラクティスを強制して、リスク発生を未然に防ぎます。

例を1つ紹介します。以下はEBSスナップショットをパブリックに公開させないポリシーです。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyActionsPublicEbsSnapshotSharing",
      "Effect": "Deny",
      "Action": [
        "ec2:ModifySnapshotAttribute"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "ec2:Add/group": "all"
        }
      }
    }
  ]
}

– 引用元: 【小ネタ】EBSスナップショットをパブリックに公開させないポリシー | DevelopersIO

その他のユースケースは公式ドキュメントの例や DevelopersIOブログなどを参照ください。

⚠ SCP制限が強すぎると…

あまりにSCPによる制限が強すぎると、利用者の開発を阻害する事態になります。

開発の生産性を大きく下げない範囲で、効果的な制限を掛けていくことを意識します。「効果的な制限」は求められるセキュリティや利用者のスキルに応じて、異なります。

運用のポイント

SCPをコードで管理する

SCPで管理する情報は肥大化しがちです。 OUへアタッチできるSCPの制限(5個まで)があるため、 1つのSCPに複数のステートメントを入れることになります。結果として行数の多いJSONとなります。

この「大きなJSON」を、マネジメントコンソールで更新するのは少し手間です。ヒューマンエラーのリスクも大きいです。

そのため、SCPはコードで管理するのが良いでしょう。 CloudFormation や Terraform などで管理できます。

Git(や CodeCommit) などのバージョン管理ツールを併用することで、 SCPのバージョンを残せます。更新したい内容の差分を確認できるメリットが大きいです。

さらに GitHub(や CodeCommit) などのサービスを使って、更新内容をレビューするプロセスを確立するのも良いでしょう。具体的には Pull Request を使います。

SCPを検証できるようにする

SCPは運用しながら改善しつづけるものです。

SCP更新の影響を事前に把握できるようにしましょう。そのためのプロセスを管理者内で確立しておきます。

例えば、SCPをテストする用途のOU(PolicyStaging OU) を用意します。 PolicyStaging OU 配下にテスト用のAWSアカウントを所属させて、 SCP効果をテストできる環境を整えます。

参考: Policy Staging OU - Organizing Your AWS Environment Using Multiple Accounts

併せて、OU全体にSCP更新を適用させる前に、「どれか1つのAWSアカウントへ一時的にSCPをアタッチする」のも良いでしょう。意図した挙動になっていることが確認できたら、一時的なSCPアタッチを解除して、OU全体へSCPアタッチを行います。

SCP管理をメンバーアカウントに委任する

一部のOrganizations機能をメンバーアカウントに委任できます。

AWS Organizations の委任管理者 - AWS Organizations

管理アカウント上で実施するタスクを最小限にするために、 SCP管理もメンバーアカウントに委任することを推奨します。

具体的な委任の方法については以下ブログを参照ください。

【AWS Organizations】SCP更新(update-policy)をメンバーアカウントに委任してみる | DevelopersIO

おわりに

以上、AWS Organizations SCP の再入門ブログでした。

SCPは強力なツールですが、その分 AWSアカウントへ与える影響も大きいです。組織としてSCPをどう運用していくのかをしっかり決めて、継続的な改善を行っていくのが良いでしょう。

本ブログが参考になれば幸いです。

📖 [最後に宣伝] Classmethod Cloud Guidebook(CCG) について

クラスメソッドメンバーズのお客様向けに Classmethod Cloud Guidebook (CCG) を提供しております。

AWS利用ガイドラインのサンプルやマルチアカウント管理、AWS Security Hub 対応のナレッジをまとめた Web サイトです。メンバーズのお客様向けに無償で提供しています。本ブログで紹介したSCP含め、マルチアカウント管理でよく使う統制サービスの活用ノウハウもまとめております。

詳しくは以下CCG紹介ブログを参照ください。

AWS再入門2023 Organizations SCP編

目次

SCPの概要

SCPとは

SCPの実体

設計前のインプット

SCPの効果範囲

SCPはアクセス許可を与えない

SCPの評価のされかた

ほか細かい制限/仕様

設計のポイント

拒否リスト形式を採用する

使わないリージョンを制限する

管理者が作成した設定を保護する

セキュアな利用を強制する

運用のポイント

SCPをコードで管理する

SCPを検証できるようにする

SCP管理をメンバーアカウントに委任する

おわりに

📖 [最後に宣伝] Classmethod Cloud Guidebook(CCG) について

参考

イベント

EVENT【6/5（水）】QuickSightとTableauのデモで営業分析を解説！アクションに繋げるダッシュボード設計

EVENT【5/29（水）大阪】Alteryxの使い方から導入メリットまですべてがわかるセミナー＆ワークショップ

EVENT【5/15（水）リモート】クラスメソッドの会社説明会を開催します

EVENT【5/8リモート】クラスメソッドのフリーランスエンジニア会社説明会〜フィンテック / リテール業界案件特集〜を開催します

EVENT【5/28（火）】AWSを最大活用するための1dayカンファレンス

EVENT【5/17（金）】認証機能の開発工数削減をデモで体験！次世代認証基盤サービス『Auth0 by Okta』導入実践ウェビナー

EVENT【5/14（火）】アノテーションの中途向けオンライン会社説明会を開催します

EVENT【5/23（木）】ユースケースに学ぶAWS運用のノウハウ～可視化から統制まで～

EVENT【5/16（木）】Snowflakeを触ってみよう！初めての方向けハンズオンセミナー

EVENT【5/10（金）名古屋】クラスメソッドグループの会社説明会を開催します！

AWS再入門2023 Organizations SCP編

目次

SCPの概要

SCPとは

SCPの実体

設計前のインプット

SCPの効果範囲

SCPはアクセス許可を与えない

SCPの評価のされかた

ほか細かい制限/仕様

設計のポイント

拒否リスト形式を採用する

使わないリージョンを制限する

管理者が作成した設定を保護する

セキュアな利用を強制する

運用のポイント

SCPをコードで管理する

SCPを検証できるようにする

SCP管理をメンバーアカウントに委任する

おわりに

📖 [最後に宣伝] Classmethod Cloud Guidebook(CCG) について

参考

イベント

EVENT【6/5（水）】QuickSightとTableauのデモで営業分析を解説！アクションに繋げるダッシュボード設計

EVENT【5/29（水）大阪】Alteryxの使い方から導入メリットまですべてがわかるセミナー＆ワークショップ

EVENT【5/15（水）リモート】クラスメソッドの会社説明会を開催します

EVENT【5/8リモート】クラスメソッドのフリーランスエンジニア会社説明会 〜フィンテック / リテール 業界案件特集〜 を開催します

EVENT【5/28（火）】AWSを最大活用するための1dayカンファレンス

EVENT【5/17（金）】認証機能の開発工数削減をデモで体験！次世代認証基盤サービス『Auth0 by Okta』導入実践ウェビナー

EVENT【5/14（火）】アノテーションの中途向けオンライン会社説明会を開催します

EVENT【5/23（木）】ユースケースに学ぶAWS運用のノウハウ～可視化から統制まで～

EVENT【5/16（木）】Snowflakeを触ってみよう！初めての方向けハンズオンセミナー

EVENT【5/10（金） 名古屋】クラスメソッドグループの会社説明会を開催します！

関連記事

Organizations、ControlTowerでアカウントが作成されたことを通知してみた

組織下のAWSアカウントの名前や所属OUを一覧にしてCSV出力したい【Python, Boto3】

Savings Plans 返品操作を拒否するサービスコントロールポリシー（SCP）を試してみた

AWS Config の組織のサブスクリプション（信頼されたアクセス）が有効になっているときの対応（Audit アカウントは新規作成の場合）

EVENT【5/8リモート】クラスメソッドのフリーランスエンジニア会社説明会〜フィンテック / リテール業界案件特集〜を開催します

EVENT【5/10（金）名古屋】クラスメソッドグループの会社説明会を開催します！