AWS Organizations連携サービス最新情報＆セットアップのコツ(27) 使ってみてわかったService Control Policyアップデートのポイント

はじめに

今回は、先日発表されたSCP(Service Control Policy)がIAMポリシー言語を完全にサポートしたというアップデートについて考察していきます。

アップデートの具体的な内容はAWSブログに紹介されており、具体的には下記の通りです。

Actionでの先頭や中間でのワイルドカードのサポート
NotActionでの先頭や中間でのワイルドカードのサポート
AllowステートメントでのNotResourceのサポート
AllowステートメントでのNotActionのサポート
AllowステートメントでのResource指定のサポート
AllowステートメントでのCondition指定のサポート

これらは一見多くのユースケースがサポートされるように見えますが、一方でSCPの設計思想から外れる可能性があるため、注意が必要です。以下で詳しく説明していきます。

SCPの設計思想を踏まえた本アップデートに対する考察

SCPは一般的に各社でのガバナンス向上を目的に利用されるものであり、AWS Organizations配下の複数のAWSアカウントに強制力を持って適用されるポリシーです。ガバナンスの観点で会社として利用を許可しないAWSサービスやアクションを定義したり、特定のリージョンでのリソース作成を禁止したりするために利用されます。

このようなSCPの利用目的を考慮すると、SCPはDenyステートメントを中心に設計されるべきであり、Allowステートメントは最小限に留めるべきです。Allowステートメントを多用すると、SCPのポリシー全体の理解が難しくなり、ガバナンスの観点で望ましくない設定が混入するリスクが高まります。

すでにSCPを利用している場合、ほぼすべてのOU（もしくはAWSアカウント）に対して、意図しない操作制限を防ぐため、AWS管理ポリシーである「FullAWSAccess」という全操作を許可するSCPがアタッチされている構成が一般的です。SCPでは、複数のAllowポリシーが存在する場合、そのいずれか一つでも許可されていればアクセスが許可されます。そのため、この構成のまま限定的な許可（Allow）を持つSCPを追加しても、すでに「FullAWSAccess」ですべてが許可されているため、許可範囲は変わらず実質的に意味を持ちません。

AWSブログでも触れられている通り、SCPは原則Denyステートメントを中心に設計を行うべきです。

We recommend using explicit Deny statements when authoring SCPs in most cases. Using Deny statements help make sure that each control works independently and remains enforceable. Relying solely on allow statements and the implicit deny-by-default model can lead to unintended access, because broader or overlapping Allow statements can override more restrictive ones.

では、実際の現場で今回のアップデートの最もうれしいユースケースは何でしょうか？筆者はワイルドカードの拡張による先頭や中間での柔軟な指定が可能になった点を挙げたいと思います。これにより、短くシンプルなSCPを作成しやすくなるのではないでしょうか。 CCoE（Cloud Center of Excellence。クラウド推進部門）などで中央集権的にAWSアカウントを管理している際には、以下のような制御を行うことがあります。

AWSサポートプランの変更を禁止する
請求関連の操作を禁止する
連絡先情報の変更を禁止する

これまではActionでワイルドカードを指定できるのは末尾のみであったため、これらの制御を実現するためには、多くのアクションを個別に列挙する必要がありました。


{
    "Sid": "DenyCCoEActions",
    "Effect": "Deny",
    "Action": [
        "supportplans:GetSupportPlanUpdateStatus",
        "supportplans:StartSupportPlanUpdate",
        "account:GetContactInformation",
        "account:GetAlternateContact",
        "account:PutContactInformation",
        "billing:CreateBillingView",
        "billing:DeleteBillingView",
        "billing:UpdateBillingView",
        "billing:GetCredits",
        "billing:RedeemCredits"
    ],
    "Resource": "*",
    "Condition": {
        "StringNotLike": {
            "aws:PrincipalArn": [
                "CCoEのIAMロールなど"
            ]
        }
    }
}

今回のアップデートにより、これらのアクションを以下のようにシンプルに記述できるようになります。


{
    "Sid": "DenyCCoEActions",
    "Effect": "Deny",
    "Action": [
        "supportplans:*SupportPlan*",
        "account:*Contact*",
        "billing:*BillingView*",
        "billing:*Credits*"
    ],
    "Resource": "*",
    "Condition": {
        "StringNotLike": {
            "aws:PrincipalArn": [
                "CCoEのIAMロールなど"
            ]
        }
    }
}

本稿執筆時点でSCPの最大サイズは5120文字となっているため、SCPのサイズ制限のため、SCPを分割している場合もあるのではないかと思います。このような場合にも、SCPをシンプルに記述できることで、SCPのサイズ削減に寄与する可能性があります。

このように便利なアップデートですが、特にAllowステートメントの利用には注意が必要です。AllowステートメントのSCPを利用するのは、デフォルトですべてを許可する「FullAWSAccess」をアタッチせず、許可したいサービス・アクションのみをAllowステートメントで記述したSCPを適用する、いわゆる「ホワイトリスト方式」でサンドボックス環境を構築する、といった限定的なユースケースになるのではないでしょうか。多くの場合は、今まで通りDenyステートメント中心のSCP設計を心がけることをお勧めします。

まとめ

今回は、SCPがIAMポリシー言語を完全にサポートしたというアップデートについて考察しました。SCPはガバナンス向上を目的とするため、Denyステートメント中心の設計が推奨されます。この思想を踏まえ、Allowステートメントの利用は最小限に留めるべきです。一方で、ワイルドカードの拡張により、SCPをシンプルに記述できるようになるユースケースもあります。SCPの設計思想を理解した上で、本アップデートの内容を適切に活用していきましょう。