[レポート] re:Invent 2019 Landing Zoneのセキュリティとガバナンスを考える #SEC325 #reinvent

こんにちは。
ご機嫌いかがでしょうか。
re:Invent2019 に参加するためラスベガスへ来ています吉井 亮です。

はじめに

本記事はAWS re:Invent 2019のセッション「SEC325-R1 - [REPEAT 1] Architecting security & governance across your landing zone」 のレポートです。

セッション概要

AWS環境の重要な要素は、リソースの分離、職務の分離、明確な課金分離（つまり、ランディングゾーン）を提供するフレームワークを持つことです。 このセッションでは、着陸ゾーンを確立するためのマルチアカウント戦略のベストプラクティスの更新、組織単位構造の構築に関する新しいガイダンス、および履歴コンテキストについて説明します。 IDフェデレーション、クロスアカウントロール、統合ログ、アカウントガバナンスなどのセキュリティパターンをカバーしています。 最後に、AWS Landing Zone、AWS Control Tower、またはAWS Organizationsの使用に関する考慮事項をまとめます。 すべてのランディングゾーンセッションに参加することをお勧めします。 セッションカタログで「ランディングゾーン」を検索します。

スピーカーはこの方。

Sam Elmalak - Worldwide Tech Leader, Enterprise Greenfield, Amazon Web Services

はじめに

お客様は AWS で何がしたいのでしょうか。

• Build
  • 差別化にフォーカス
• Move Fast
• Stay Secure

お客様が期待している環境は？

• セキュアで統制がとれている
• スケーラブルで弾力性がある
• 順応性が高く柔軟性がある

お客様が AWS アカウントを分割する理由は何でしょうか？
理由は多くあります。
たくさんのチームを持っている、支払いを分けたい、環境を独立させたい、セキュリティコントロールのため、
API リミットやストッろリングを避けたい、など様々です。
リソースコンテナ としての AWS を求めています。

一つのアカウントで IAM や VPC を分けて運用することは困難です。
境界があいまいになり、リソースのトラッキングが難しくなります。

Landing Zone

マルチアカウントを管理するにはオーケストレーションフレームワークが必要になります。
フレームワークにはこれらの能力を備えます。

• 請求管理
• IAM
• セキュリティログ
• 共用インフラストラクチャ
• リソースの分離
• 開発サイクルのサポート
• 中央ネットワーク接続性
• セキュリティツール

Landing Zone とは

AWS ベストプラクティスをベースに構成されたセキュアでスケーラブルなマルチアカウント環境です。
新しい開発を始めるときや、アプリケーションのマイグレーション時に活用します。
この環境は繰り返し利用可能でいつでも拡張することができます。

Landing Zone を簡単にセットアップできるサービスが AWS Control Tower です。

Service Control Policies (SCP)

AWS サービスの API 呼び出しをコントロールするために SCP を使います。
API 呼び出しを許可するホワイトリスト、拒否するブラックリストを作ってコントロールを行います。

子アカウントの全ユーザー (root を含む) のパーミッションをコントロールします。

Organizational Units (OU)

OU を使ってアカウントをグルーピングします。
このグルーピングはパーミッションのよるものです。(会社組織的なものではない)
そして OU に SCP を適用します。

パーミッションのよるグルーピングの例を示します。

Foundational OU

組織の基礎となる OU です。
セキュリティと共有インフラストラクチャを定義します。
この OU には以下のアカウントを含めます。

アカウント	説明
Log Archive	バージョニングされた S3 バケットを配置、他アカウントの CloudTrail や各種セキュリティログを集約します。
Security Read Only	他アカウントのリソースを閲覧、スキャンするセキュリティ監査のためのアカウント。
Security Break Glass	セキュリティ緊急時に使用、インフラストラクチャに対する権限を持ったアカウント。
Security Tooling	GuardDuty、Security Hub、Config Aggregation などのセキュリティツールを集中管理するためのアカウント。
Shared Service	DNS、LDAP/Active Directory、Golden AMI、Pipeline など他アカウントで共有するリソースを置くアカウント。
Network	ネットワークチーム用のアカウント。DX、DX Gateway、Transit Gateway、Shared VPC を置く。

Develoer Sandbox OU

開発者にある程度自由を与える OU です。
AWS 利用料金の制限を設定しておきます。
インターネットやデータセンターとは切り離したネットワークにします。

Workload OU

ワークロード用の OU です。
Dev、Pre-Prod、Prod などワークロードを稼働させるアカウントを含めます。

PolicyStaging OU

SCP で定義するポリシーをテストするための OU です。
ポリシーテスト用のアカウントを含めます。
ポリシー変更はこの OU でテストをしてから本来の OU に適用する運用とします。

Suspended OU

全ての権限を停止した OU です。
アカウント閉鎖やメンバーの離任などで使います。

例外的 OU

個別のビジネス事情やプロセスのために例外的に設定する OU です。
要件を満たす最小権限が与えられます。

Deployments OU

Build、Deploy などの Pipeline を実行する OU です。
Deploy を行うためだけのアカウントを含めます。

どのように導入すればいいか

新規ユーザーの場合：

• Control Tower を評価してみる
• Guardrails と blueprints を使う
• Account factory を使う

既存ユーザーの場合：

• Control Tower が提供する CloudWatch Events のモニタリングを使ってみる
• どこかのアカウントで試験的に Control Tower を使ってみる

AWS Landing Zone を使っている場合：

• 新しいバージョンへアップグレードする
• Control Tower へリプレースする
• フレームワークも同時に拡張する

マルチアカウント戦略 アイデアとガイドライン

• SCP を活用する
• ID フェデレーションを使う
• マルチアカウントへ段階移行
• ネットワーク活用 (Trangit Gateway、Shared VPC、Private Link、VPC Peering、etc)
• Firewall や IDS/IPS をどこでどのように使うか考慮する
• アラートを適切に設定する
• フォレンジック Landing Zone を作る
• QA、ステーjング Landing Zone を作る
• バックアップ/DR はアカウントレベルで考慮する
• アカウントのコストに気を配る
• マルチアカウント内で CI/CD を実現

所感

マルチアカウントが当たり前になってきたなかで
ガバナンスを効かせつつ機能性を向上させるような
マルチアカウント構成が必要になってきます。
Control Tower をそのまま使うもよし、
少しずつカスタマイズしながら使うもよしです。

以上、吉井 亮 がお届けしました。