Zenn
🗼

Control Towerによるガバナンスとマルチアカウント戦略

2024/08/26に公開
AWS
Control Tower
tech

組織における部門横断的なクラウド活用の推進役、つまりCCoEの役割のうち、ソフト面が人材育成や社内活動の促進等だとするならハード面は基盤・環境整備が主に挙げられるでしょう。
AWSにおけるそれは、アプリケーションやシステム開発とは別軸のサービス利用が求められます。
ここでは特にセキュリティやガバナンスのために考えるべきことやサービス、それらを一括で有効化できるAWS Control Towerについて書ければと思います。

AWSにおいて意識するガバナンスの観点

AWSのガバナンスの文脈で私がよく見聞きする話題は「予防的統制」、「発見的統制」です。

予防的統制

組織内のアカウントで好ましくない行為を事前に防ぐ統制方法です。公式では最近は予防的統制 ではなく 予防的コントロール という言葉を使ってますが、現場ではこっちのほうが通じがちです。

ここで言う好ましくない行為とは、

  1. セキュリティ的によろしくない行為を行うこと
  2. 組織内で使っていないリージョン(例えば東京・大阪リージョン以外)を使うこと
  3. 過剰に高価なインスタンスタイプを使用すること

等が挙げられます。
1.は、例えばMFAが有効になっていないユーザーでアクセスすることや、ルートユーザーのアクセスキーを発行すること等です。
2.は例えば観測範囲外の所で変なインスタンスが立ってて高額請求されたり、情報の取り扱いがセンシティブなリージョンに不用意に持ち出されてしまいかねないです。
3.についても高額請求のリスクがあります。性能をケチるというよりは「u-12tb1.112xlargeなどという100ドル/h 以上するものを、SAP製品を使わないのに開きっぱなしにするのは怖いよね」という文脈です。

これらのアクションがそもそもできないようにすることです。早い話がIAMポリシーでそれらのアクションをDenyすることでしょう。
また、AWS Organizationsのサービスコントロールポリシー(SCP)を利用することで、複数のアカウントに対して一括で、かつ、各アカウントの管理者が制御できない範囲で制限可能です。

具体的な例はドキュメントに記載があります。

https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_manage_policies_scps_examples_general.html#example-scp-deny-region

一例を抜粋、EUのリージョンを日本のリージョンに変更しました。
「東京・大阪リージョン以外で、IAMとかのグローバルサービスではないものは、全リソースの、あらゆるアクションを、拒否」といったポリシー内容になっています。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyAllOutsideJP",
            "Effect": "Deny", // 拒否する
            "NotAction": [
                ..., 
                "iam:*", // IAMではないアクションを対象に 
                ..., 
            ],
            "Resource": "*", // 全リソースに対して
            "Condition": {
                "StringNotEquals": {
                    "aws:RequestedRegion": [
                        "ap-northeast-1", // 東京リージョンと
                        "ap-northeast-3" // 大阪リージョン 以外は
                    ]
                },
                ...
                }
            }
        }
    ]
}

発見的統制

さきほどのような好ましくない行為が行われていることを発見(検知)し、対応する統制方法です。

基本的な対応は通知で、その通知を受けた側で確認・対処をするというものです。応用的には検知したらスクリプトが自動的に実行されるような仕組みを作り、検知から対応の時間的ロスを埋めるアプローチが取られます。
これらを実現するサービスの一つはAWS Configです。これはAWS内における設定状態を記録できるサービスで、特定のルールに準拠しない設定状態を検知できます。
ルールにはAWSがプリセット的に提供する「マネージドルール」が存在し、あるあるな要件を検知できます。(カスタムルールも設定可)

例としてVPC_SG_PORTRESTRICTION_CHECKを見てみましょう。

https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/vpc-sg-port-restriction-check.html

これはVPC内のリソースにおけるファイアウォール機能を担うセキュリティグループでよろしくない設定を検知するものです。
具体的には22番や3389番ポートの通信をCIDR 0.0.0.0/0 で受け付けるといった行為を検知できます。このようなセキュリティグループが存在するということは、全世界に「どうぞいくらでも遠隔操作しにきてください！」と声高に宣言する行為に等しいです。
それ以外のポート番号もオプションで指定できます。

Configルールで行ったあとEメール通知を行えるほか、Systems Manager Automtion と統合させることで、検知し次第自動修復を行う機能もあります。

GuardDuty、Inspector、Security Hubなどのセキュリティサービスもありますが、一旦は別の機会にさせてください。

Control Towerによる統制の手軽な有効化

ここまで各統制とそれを利かせるための機能を紹介してきましたが、これらのポリシーやルールはControl Towerで少なくない数を有効にできます。

AWS Control Tower はベストプラクティスに準拠したマルチアカウント環境を作成し、スケーリングさせるためのアカウント払い出し機能、シングルサインオン機能、ガバナンス機能を利用できるサービスです。
ガバナンスの観点では「コントロール」という機能によって予防的統制や発見的統制を有効にできます。

Configで紹介した「がら空きポート検知しよう」コントロールもあります。

https://docs.aws.amazon.com/ja_jp/controltower/latest/controlreference/strongly-recommended-controls.html#ssh-disallow-internet
https://docs.aws.amazon.com/ja_jp/controltower/latest/controlreference/strongly-recommended-controls.html#rdp-disallow-internet

It detects whether internet connections are enabled to Amazon EC2 instances through services such as Remote Desktop Protocol (RDP)

This control detects whether internet connections are allowed through remote services such as the Secure Shell (SSH) protocol.

予防的統制で出た「使わないリージョン全部拒否ポリシー」はリージョン拒否コントロールで設定できます。

https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/region-deny.html

リージョン拒否コントロールは、AWS Control Tower リージョン設定に基づいて、 AWS サービスへのアクセスを禁止します。管理対象外のステータスの AWS リージョンへのアクセスを拒否します。

おわりに

組織のガバナンスにおけるControl Towerは非常に有効です。その他のアカウント払い出しなどの機能もAWS管理基盤として非常に有効にはたらいてくれるものなのでおすすめです。

一方で紹介はしたものの発見的統制におけるControl Towerの役割は実は最近めちゃくちゃ食われているもので、影が薄くなってまして、代わりに存在感を大きくしているSecurity Hubについてはまた気が向いたら書こうとおもいます。

Discussion