[レポート] Setting up controls at scale in your AWS environment #COP318 #reinvent

みなさん、こんにちは。

re:Invent2022に現地参戦しております、AWS事業本部コンサルティング部の芦沢(＠ashi_ssan)です。

普段業務で扱うことが多いControl Towerについてのセッションに参加しましたので、レポートしていきます。

セッション概要

Session Title

Setting up controls at scale in your AWS environment

Session Description

Today, customers are challenged with balancing compliance and security requirements with the desire to allow engineers to make their own design choices. Many customers take an allow list approach: restricting developer access to AWS services until risks are defined and controls are implemented. In this session, learn how to use AWS Control Tower features to meet control objectives and reduce the time it takes to approve AWS services for use.

Session level

300 - Advanced

Session type

Breakout Session

レポート

スピーカー：Jeff Jacobson, user researcher with AWS control tower

Introduction

• スピーカーはお客様からできるだけ多くのことを学ぶために毎年re:Inventでユーザーリサーチャーとして研究している。
• 昨年は、AWSにある息をするようなコントロールを組織を完全に停滞させることなくカバーするためにはどうしたらいいか、という点についてかなり苦悩していることを伺い知った。
• 調査に参加されるお客様に毎回「答えは誰にもわからない」とよく言う
  • ただし、今年の調査が未来につながる可能性はあります

Agenda

• AWS Cloud Ops
• AWS Control tower overview
• Customer journeys
• Governance challenges
• Demo

AWS Cloud Ops

• クラウドの弾力性を保ちながら、安全性と効率性を維持するためにはどうしたらいいか？
  • AWSは高い生産性、回復力、ビジネス、俊敏性、環境保全のために最善を尽くす
• クラウドガバナンスやキャリブレーションシステムのセットアップは多くの要素があるため簡単ではない
  • AWSがControl Towerから始めることを推奨しているのは、私がコントロール権限を使い果たしているからではなく、AWSで一般的に言えること
  • Control Towerが可能にするベーシックなクイックスタートがお客様に喜ばれることがわかった

• お客様がクラウドに求めるもの = 過去の実績や変化への迅速な対応能力 & 同時に安全なコンプライアンスの維持 & 利用費を予算内に収めること
  • これをどのように行うのか？
• Control Towerの背後にある考え方
  • 開発者や内部ユーザーに安全な作業環境を与えたい
  • 適切な構成と適切なコントロールが実施された環境を効率的に提供し、特定のフレームワークの中で作業させたい
  • このような目的でAWSを利用する場合、Control Towerを利用することをおすすめしたい
    • 既に運用を始めている場合もControl Towerを導入することができ、ガバナンスの拡張が可能

AWS Control tower overview

• Control Towerとは
  • マルチアカウントのクラウド環境を構築し、ベストプラクティスの設計図と制御を展開するフルマネージドサービス
  • 適切なコントロールと設定が行われたユーザーに対して、新しいアカウントを発行できる
  • ダッシュボードを作成して監視できる

• 本日のアップデートでアカウントプロビジョニングの一環としてのカスタマイズ機能のサポートが発表された
  • 完全にカスタマイズされたアカウントブループリントを作成し、2000あるブループリントのうちの1つとしてアカウントに導入することが可能に
  • これに伴いパートナーが12人増えた

• ここからはコントロールの話
• コントロールとは基本的なルールでガバナンスのルールをカプセル化したもので、応急処置として考えている。誰にも触られないようにするためのものです。
• 予防的統制(コントロール)はSCPやOUを用いて実装され、基本的には誰かが何かをすることを阻止するもの、これらは常にコンプライアンスに準拠している
• 検知型の発見的統制(コントロール)は、Control Towerのダッシュボードには出ないが、最高の信頼性をもって実施される
• 3つ目の謎コントロールは後ほど解説

• これはControl TowerがGAしてから3年間でAWSが提供してきた機能の一覧表
• あなたのフィードバックがすべての新機能に反映されていて、実際に機能するのか？のような疑問の余地がない

Customer journeys

ここからはスピーカーを交代して、事例のセッションになります。

PIMCOの例

スピーカー：　（メモ忘れのため確認中、確認出来次第埋めます）

• PIMCO（パシフィック・インベストメント・マネジメント・カンパニー）のControl Tower Jornyの例
• 8年間かけてターゲットプラットフォームの移行を進めたが、2023年に向けて皆が使用しているようなより多くのAWSサービスの利用の検討を始めた。
• アプリケーション開発者は、より本質的にワークロードをカスタマイズして最適化できるようなサービスや構成を求めている
  • 教育やイノベーションはもちろんだが、ガバナンスも同時に望んでいる
  • 予防的な検出制御が組み込まれた安全でベストプラクティスの環境を求めている
  • 本質的にそのコンプライアンス違反が起きそうな場合はすぐ検出できるようにしたい
  • そして、チームによってはContorol Towerや組織のポリシーをカスタマイズしてベースラインの上書きなしで、環境をより安全にするチームも存在した

• こういった経緯からベーシックなControl Towerの評価を開始した
• 2022年の初めに移行計画をたて、現在は移行が完了した
• ここから移行用のプラグインや、すでにコントロールが用意されているユースケースを強化するためのプラグインについて話していく
• 検討したもの
  • 既存のランディングゾーンのアーキテクチャとカスタマイズを見直す
  • 既存のコアアカウントを使うかどうか
  • Control　Towerカスタマイズ項目のどれを利用して、どの項目が残すのか
  • 構造からドキュメントを見て
• AWSアカウントはライフサイクル、Dev or Prod、公開エンドポイントなのか非公開なのかでグループ化することができる
  • 後から簡単かつコストもかけずに変更できる
• 既存のフレームワークやCfCTはカスタマイズをライフサイクルイベントと結びつけるための良いツール
• 新しいアカウントを作るたびに、ポリシーの適用やIAMロールの作成などを実行するライフサイクルイベントが実行される
• このような複雑なイベントを利用してControl Towerへの移行を促進するため、CI/CDの利用をおすすめする -　その他重要な教訓
  • Control Towerの構築後は利用可能なコントロールのレビュー、新しいコントロールの導入や有効化が必要
  • 既存のコントロールのライフサイクル管理などを定期的に計画し、運用モデルを作成する準備が必要がある
  • また、コンプライアンス上の問題があれば、その改善も計画する必要がある
• つまり、Control Towerに移行する際には新たな運用計画を計画する必要がある
• Control Towerにはリージョンコントロールのセットが付随している

• リージョンコントロールのユースケース
• バージョン管理が私たちが選んだ特定の領域へのアクセスのみをコントロールさせる必要があった。その理由はさまざま。
  • Landing Zoneまたは特定の地域のコントロールの排除の実装のための、カスタムレシピの実装
  • 各SCPを組織とアカウントレベルに適用する必要
  • そして新しいサービスやリージョンがAWSによって追加されるようにSCPを維持する必要があった
• 最も難しいところは、ここまでのオペレーションを本当に理解した非常のスキルの高い人々のセットが必要な点

• 続いてはロギングの話
• 免除リストのメンテナンスを管理ガードレールに委任する
• Landing Zone全体に適用されるためユニークなリージョン拒否設定で制御する
• 一度適用されると、コンテンツの作成、転送、リージョンの許可ができなくなる
• 個々の拒否設定コントロールに加えて、最も一般的なインターネットアクセスを制限するコントロールのホストがある

• ここからはWish list(叶えたいこと)について
• AWSのエンタープライズ環境におけるセキュリティコンプライアンスの監視方法は複数ある
  • Security HubによるCISのような自動化されたセキュリティ標準
  • AWS Config Ruleによるツールや依存行動に基づいた追跡および設定の修正
  • 複数あるせいでセキュリティとコンプライアンスを1箇所で確認することが難しい = ツールとエコシステムの統合が進むと嬉しい
• もう一点、Control Towerの素晴らしいところはダッシュボードですべてのOU, 組織, アカウントが提供されており、それぞれで有効になっているガードレールの数も表示される点
  • また、ガードレールに対する組織、アカウントのステータスも確認でき、コンプライアンスに問題があるときはドリルダウンして実際のリソースを確認できる
  • ダッシュボード上に多くのカスタムコントロール含んだコントロールが表示され、１枚のガラスの状態になるのが理想です。
• 組織アカウントに適用されるテーマ別ガードレールの詳細を共有する方法を用意する予定
  • ビューを作成して他のユーザーと共有できる点がいいところ
• 最後に、本質的に難しい問題の1つは「ガードレールを適用する前に適用した場合の影響がわからなかった場合、どのように分析するか」です。
  • この制御を有効にする前にシミュレーションできる機能があれば本当に素晴らしいアプリになる

DTCCの例

スピーカー: Tom Wolstencroft, Director, Cloud Solution Engineering

• DTCCは世界でも有数のホスト貿易金融機関で、93カ国で事業を展開しており、約6000の金融機関が利用している。
• すべての金融機関と毎日速いペースで取引を行なっているため、セキュリティ、監査能力、自動化に重きを置いている。
  • 何よりもセキュリティが大切

• 2012年にクラウドジャーニーを開始した
• アプリケーションのニーズの変化に迅速に対応するために自動化機能を検討し始め、2017年からその価値を見出した。
  • ここでAWSとのパートナーシップを構築し、規制や行政のコンプライアンスルールに対応するために実際に構築を行った
  • 以降、規制当局と協力して同じ規模で何かを行うために必要なことを教育してきた
• コスト管理も重要なポイント
• AWSプラットフォームをゼロから立ち上げ、自動化することに決めた
  • 2012年はControl Towerがなかったため、3rd Party製品を利用したセキュリティの構築、独自のカスタムツールセットの構築、そのための開発エンジニアの準備、コードセットの維持、規制対応などやることが膨大だった
  • Control Towerがあればこれらの自動化が簡単に行える

• やりたいことは、開発者、エンジニアが必要なことをなんでも素早く開発できるようにすること
  • 彼らの作業によって望まない新たな問題が発生しないことを保証すること
• 私たちはプロアクティブな環境を目指し、問題が起きる前に既に解決している必要がある
  • 何か問題が発生したら問題に自動で対応し、問題がカタログに載るようなものにならないように監査を行い情報を確実に収集する
• クラウド投資のメリットは市場投入までの時間を短縮することだが、リスクは低減したい
  • Control Towerを使って絶対に望ましくないリスクが発生しないようにすることに、本当に重きを置いている
• ユーザーエクスペリエンスの向上は開発者にとっても重要なこと
  • 新しいアイデアを思いついた時に誰でもアイデアを追加できる
  • ゴルフ場で何かを聞いてそれを試してみる

Governance challenges

スピーカー：　Jamie St. Onge, AWS Control Tower Sr. Manaer Product UX

• 発表されたControl Towerの包括的管理について話す前に、まずはControl Towerがどのようなものか？についての基礎から話していく
• お客様が必要としているものは、あなたが必要としているもの
• どのような課題があるのか？
• 最も重要なものは「タイミングを計る」こと
  • みなさんは無限のリソースを持っているとは思えないので、ガバナンスのために多くの時間やリソースを投入することはできない
• リスクに対処するだけでなく、一般的なコンプライアンス要件に対応するためにどのような管理が必要かを把握しなければいけない
  • PCI、コントロールの定義、アカウントに対するコントロールの大規模実装。など、これは延々と続きます。
  • コントロールの定義だけえも特別なスキルセットが必要で、スキルがないとさらに難しくなる
  • コントロールの自動化はアカウント数が増えれば増えるほどオーバーヘッドが必要になって難しくなる
  • お客様によっては素晴らしいカスタムソリューションを構築しているが、負担長期にわたって使い続けることは望ましくない。負担は大きく、時間もかかる。
• 私たちはお客様にリスクアセスメントの再考、コントロールの見直しを求めています
  • 何を変える必要があるのか？新しいコントロールが必要なのか？変化への対応は非常に時間がかかる。
• コントロールのために複数のAWSサービスを使っていることは素晴らしいことで続けるべきだが、Security Hubでの制御を有効化するためにサービスをナビゲートしないといけない
  • これはControl Towerのガードレールなのか、環境のどこにあるものなのか、コントロールの観点で何をどこで有効化しているのか理解するために複数の異なる場所にあるサービスにアクセスしようとしている

• まず私たちは統制管理の責任から始めた
• 350以上の新しいAWS管理統制を作成し、多くの共通の管理目標を立ち上げた
• 既存のサービスや3rd Partyソリューションなどに対応するコントロールは複数のフレームワークで重なっている
  • フレームワークごとに管理ではその管理で推進していく意図が見えにくくなる
• パスワードのマルチアカウント環境を制御するために、他のAWSサービスをオーケストレーションし、モバイル環境全体の自動制御管理を提供する
  • 特定の組織単位にコントロールを適用できるため、コントロール内のすべてのアカウント、または組織単位のすべてのアカウントに適用される
• 包括的なガイダンスの提供
  • これは基本的な問題である
  • コントロールの依存関係がどこにあるのか？ コントロールの動作方法を変えるようなサービス関係がどこにあるのか？を確認できる

• 本日、新しいコントロールタイプ「プロアクティブコントロール」を発表した
• このコントロールは、非準拠のリソースのCloudFormationデプロイメントをブロックするもの
• 予防的コントロール(SCP)で予防し、検出的コントロール(Security Hubルール)で検出し、新しいプロアクティブコントロールはデプロイメントレベルで予防することができる

• ここからはプロアクティコントロールについての詳しい紹介
• プロアクティブコントロールは基本的なメカニズムであるCloudFormation hookに、CloudFormation Guard Policyで制御可能な要素がある場合、そして是正コントロールを有効化した場合、Control Towerは環境全体にCloudFormation hookを実装・登録し、その中にあるポリシーによって検査されることになる
• 実際は複数のCloudFormation hootを有効化すると、リージョン単位で構成される1つのhookとなる
  • リージョン間のオーケストレーションがより重要になるが、Control Towerはそのすべてを処理する
• hookを有効化すると新しいリソースをデプロイしようとするどのユーザーでも、そのアカウントで有効したコントロールでチェックされる
  • もし準拠されていない場合、失敗します。デプロイ前のチェックと捉えましょう

Demo

• 追加された新機能のデモンストレーションを行なった
• プロアクティブコントロールによって実際にCloudFormationスタックのデプロイが失敗する様子が見られました。

まとめ

Control Towerについての２社の事例やControl Towerの開発陣による非常に濃密なセッションでした。

特にControl Towerが登場する以前にAWSでガバナンスを実装されたDTCCの事例で、Control Towerがなかった世界で検討した内容の紹介があり、それを通じてなぜControl Towerが必要になるのか？という基本的なところを学ぶことができました。

また、Control TowerのProduct ManagerであるJamie氏の説明のおかげで、新機能についてより深く理解できました。とくに「プロアクティブコントロール」については別のブログにまとめたくなりました。

以上、AWS事業本部コンサルティング部の芦沢(＠ashi_ssan)でした。