1．はじめに

SHIFTのナショナルセキュリティ事業部所属の松尾です。

前回（vol.1）は、初期ランディングゾーンの構築までを記載しました。本記事以降はAWS Control Towerの機能を解説しつつ、マルチアカウント統制環境の設計で一般的に悩みそうなことを私の業務経験を取り入れながら考察していきたいと思います。私の業務内容や初期ランディングゾーン構築方法などは前回の記事をご参照ください。

さて、AWS Control TowerはAWS Organaizationsなどの複数のAWSサービス機能からランディングゾーンを構成するため、どのサービス機能を切り口にAWS Contorol Towerを解説していこうかを考え、イメージのつきやすい設定周りから徐々に上流に向かおうと思いました。本記事では、ガードレール機能を解説し、以下の方向けとなっています。

なお、ガードレールはAWS Control Tower上では旧名称であり、現在は「コントロール」と置き換わっています...が、旧名称のほうがイメージがつきやすいのものあり、解説の便宜上、Control Towerシリーズでは「ガードレール」とさせていただきます。

2．ガードレールとは

AWS Control Towerでのガードレールの機能ですが、ニュアンスとしては道端にあるガードレールと同じで防御壁です。

ガードレールは、AWS Control Towerのマネージドにより初期ランディングゾーン構築時に自動作成されます。また、ガードレールは動作観点で以下のように3種類に分けられ、機能から、予防的およびプロアクティブなガードレールは"事前対策"である一方で、発見的ガードレールは"事後対策"と見ることができます。

初期ランディングゾーン構築時にデフォルトで有効化されているガードレールは計23個あり、これらのガードレールはAWS Control Tower上「必須」で無効化することはできません。

また、ガードレールは「必須」を含めて合計513個あり、ガイダンス観点でも以下のように3種類に分類できます。AWS Control Tower上では新名称の「コントロール」となっていることがわかります。

上記動作観点でのガードレール併せると以下のように分類を整理することができます。

3．ガードレールの設計

ガードレールの内容の整理がついたところで必須を除く、490個のガードレールについて要件に応じて有効にするものを採用しなければなりません。『2.ガードレールとは』で、予防的およびプロアクティブなガードレールは"事前対策"である一方で、発見的ガードレールは"事後対策"と述べました。まさにここがポイントであり、まずは事後対策にあたる発見的ガードレールの設計を優先する必要があります。

さて、ここで予防およびプロアクティブなガードレールを優先としたほうが、インシデントを事前に防止できてよいのでは？とも考えられます。運用保守の経験がある方なら既に気づいているかもしれませんが、運用上必要な操作が予防的およびプロアクティブなガードレールによって禁止されてしまうと業務継続不可となり、インシデントが発生してしまいます。このように本番環境がインシデントが発生すると、現状分析からシステムオーナーによるシステム変更設定の承認やインシデントレポート作成などで運用オーバーヘッドが大きくかかります。よって、操作が禁止されない発見的ガードレールを起点にガードレールを設計したほうがよいというわけです。

まとめると、ガードレールの設計時の基本的な段取りは以下のようになります。発見的ガードレールは操作禁止されないとはいえ、①の段階で運用上、必要以上に採用すると重要なアラートが監査アカウント（Audit）のメールで埋まってしまい、インシデントレスポンスなどが遅延します（「アラート疲れ」というようです）。発見的ガードレールも予防的・プロアクティブなガードレールと併せて運用上、必要最小限となるように設計しましょう。

②の段階で予防的・プロアクティブなガードレールの採用する際は、①で採用した発見的ガードレールに対して検知ではなく禁止・ブロックに移行する必要性があるかの検討をしながら行う必要があります。

4．ガードレールの設定検証

ガードレールの設定は、OU単位で実施します。ガイダンス観点でのガードレールの種別は、『必須』『強く推奨』『選択的』の3つがあると前述しました。必須ガードレールは最上部のRoot OUに対してデフォルトで有効化されており、Root OUに対しては強く推奨ガードレールおよび選択的ガードレールは有効化できない仕様になっています。

よって、必須以外のガードレールは、RootOU配下のOUに対して設定することになります。ガードレールの特性で親OUの設定が子OUに継承することを活かして、子OUとの共通設定は親OU側で有効化するようにし、設定変更を最小限とします。また、本番アカウントのProd OUなどの運用中のOUに対してガードレールの設定変更する場合は、事前に動作検証をする必要があり、ガードレールの動作検証用のOU（下図の場合、「Policy Staging OU」）を用意することを推奨します。

以下、簡単ではありますが任意のガードレールを使って、ポリシー違反を検証してみます。実運用上は複数のガードレールを組み合わせて実施することにはなりますが、段取りとしては同じになるはずです。

4.1．Policy Staging OUの作成

初期ランディングゾーン構築時の任意OUは、仮でSandbox OUを作成していたため、ここでは別途Policy Stagingとしてガードレールの動作検証用のOUを作成します。AWS Control Towerの左ペイン「組織」から「リソースを作成 - 組織単位を作成」を押下します。

OU名を「Policy Staging」とし、親OUにRoot OUを選択して、追加を押下します。

しばらくすると（5分ほど）、Policy Staging OUがRoot OU直下に作成されます。

4.2．Policy Staging OUでのガードレールの動作検証

Policy Staging OUにAWSアカウントを所属させる前に、当OUに対して以下の任意（検証が容易）で選んだ予防的ガードレールおよび発見的ガードレールを有効化しておきます。

• [AWS-GR_RESTRICT_ROOT_USER] ルートユーザーとしてのアクションを許可しない（予防的ガードレール）

• [AWS-GR_ROOT_ACCOUNT_MFA_ENABLED] ルートユーザーの MFA が有効になっているかどうかを検出する（発見的ガードレール）

Policy Staging OUにAWSアカウントが所属されていないので、AWS Control TowerのAccount FactoryからAWSアカウントを追加してみます。デフォルトでルートユーザーはMFA未設定のため、アカウント作成後、放置すれば上記の発見的ガードレールのチェックにかかるはずです。

新規AWSアカウント追加直後のPolicy Staging OU内の様子です。

しばらくすると、『ルートユーザーの MFA が有効になっているかどうかを検出する（発見的ガードレール）』にポリシー違反し、監査アカウント（Audit）のメールにSNS通知されました。

『ルートユーザーとしてのアクションを許可しない（予防的ガードレール）』にポリシー違反し、追加したAWSアカウント（awsmem01）のルートユーザーで操作が拒否エラーとなりました。下記画像は、ルートユーザーでIAMの画面を開いたときにエラーとなっている状態です。

今回は、Policy Staging OU内での検証で終わりにしますが、実運用ではこのあとに検証して問題ないことを確認したガードレール設定一式を対象のOUに反映することになります。

5．考察（ガードレール設定の見直しはいつやるか？）

AWS Control Towerで初期ランディングゾーン構築後、ガードレールの設定を設計どおりに反映したらそれで終わりなのでしょうか。いえ、運用をしていく中で見直しが必要です。一般的に組織やITガバナンス統制においては、規則類（ポリシー）の見直しを以下の時期をポイントに実施して形骸化を防止する仕組みが必要です。

【定期的な見直し】

• 会計期越え／定期的に組織改編が行われるタイミング（年1回）で現状のガードレール設定が実運用に合っているか見直し

【臨時の見直し】

• インシデント対応時など組織やITガバナンス統制に大きな影響が発生し得る場合（結果的に統制面が原因でなくても、必ず見直し）

• 会社合併など不定期に組織改編が行われるタイミング

• ソフトウェアやサービスのバージョンアップリリース時（AWS Control Towerはランディングゾーンのバージョンが該当）

AWS Control Towerはマルチアカウント統制環境のためのマネージドサービスであり、ガバナンスを主軸とおいていますので、ガードレールなどのガバナンスの見直しは必要に応じて実施する必要があると言えます。AWS Control Towerでのガバナンスの見直しに伴う課題については、AWS OrganaizationsのOUなどと関連しますので、別ブログで深掘りして記載したいと思います。

次回予告

次回（AWS Control Tower シリーズ vol.3）は、AWS Organaizationsでの組織単位（OU）の設計について記載します。OUの設計は組織の特性によって多くのパターンが考えられますので、悩まれる方はいるのではないでしょうか。

お問合せはお気軽に

SHIFTについて（コーポレートサイト）

SHIFTのサービスについて（サービスサイト）

SHIFTの導入事例

お役立ち資料はこちら

SHIFTの採用情報はこちら

PHOTO：UnsplashのChantha Pheuypraseuth