[レポート]SEC303 – Architecting Security & Governance across your AWS Landing Zone #reinvent

AWS re:Invent 2018

#AWS

中山順博

2018.11.28

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

中山（順）です

本記事は、re:Invent 2018のセッションレポートになります。

セッション内容

タイトル

SEC303 - Architecting Security & Governance across your AWS Landing Zone

概要

Whether it is per business unit or per application, many AWS customers use multiple accounts to meet their infrastructure isolation, separation of duties, and billing requirements to establish their AWS Landing Zone. In this session, formerly called "Architecting Security & Governance across a Multi-Account Strategy," we discuss the latest updates around establishing your AWS Landing Zone. We cover considerations, limitations, and security patterns when building a multi-account strategy. We explore topics such as thought pattern, identity federation, cross-account roles, consolidated logging, and account governance. In addition, BP shares its journey and approach to establishing its AWS Landing Zone. At the end of the session, we present an enterprise-ready landing zone framework and provide the background needed to implement an AWS Landing Zone. We encourage you to attend the full AWS Landing Zone track; search for #awslandingzone in the session catalog. Please join us for a speaker meet-and-greet following this session at the Speaker Lounge (ARIA East, Level 1, Willow Lounge). The meet-and-greet starts 15 minutes after the session and runs for half an hour.

登壇者

Sam Elmalak - Solutions Architect, AWS
David Ninnis - Senior Enterprise Architect, Cloud, BP

Agenda

An Enterprise Ready Landing Zone Framework
BP's Landing Zone Journey
Action Plan & Checklist

An Enterprise Ready Landing Zone Framework

Landing Zoneが必要な背景

ITが事業に欠かせないものになって久しいですが、事業サイド/開発者からの多くの要請に応えるためにはITインフラを管理する担当者が一定数は必要です。 AWSによってインフラの管理負担を下げることはできますが、課題がないわけではありません。

例えば、1つのアカウントを多目的に利用すると、以下のような課題が発生します。

責任の境界が曖昧になる
時間の経過とともに構成が複雑になる
リソースの変更をトラッキングすることが難しい

ということで、弊社の案件でもよく提案するマルチアカウント戦略というアプローチがあります。本番環境/ステージング環境/開発環境などに分けることがありますが、それだけだと課題があります。

リソースの変更や利用をトラッキングすることは難しい
インフラ管理者との責任分解はまだ不十分/突然高額な課金が発生するリスク
開発者に歩み寄ってもらっている
VPCなどのネットワークリソースはインフラ管理者が管理する必要がある

オンプレミスからクラウドに移行するケースでは以下のようなことがよくあります。

オンプレミスと同じ考えでクラウドを利用
オンプレでのやり方を継承
インフラ管理者が開発者に十分な権限を付与しない

これらが変わらない限り、開発者は十分に実力を発揮できませんし、DevOpsなどの取り組みもうまくいかないでしょう。

AWSをうまく活用するためには以下のような考え方が必要です。

AWSのサービスにアクセスするための障壁を取り除く
実害を回避しつつ、早く失敗できるようになる
突然高額な課金が発生するリスクを極小化
オペレーションチームからクラウドアーキテクトへ
リソースやコストを個別に追跡できるようにする
コードをAWSに最適化

実際にAWSアカウントをどのように分けるべきか

先ほどの考え方に沿うには以下のように分けることが考えられると思います。

Production
Staging
Dev/UAT（開発／ユーザー受け入れテスト環境）
Team/Group（チーム毎にアカウントを提供）
Developer（開発者毎にアカウントを提供）
Core/Shared（各アカウントに必要なサービスを共用できるようにするための環境）

Core/Sharedでは以下のようなサービスを提供する必要があると考えられます。必要に応じて、これらの用途別にアカウントを分けるといいでしょう。

ログのアーカイブ
ネットワーク（Direct ConnectのConnectionを所有、Transitなど）
セキュリティ（パッチの配信など）
その他共用サービス（ID管理、DNS、制限のモニタリングなど）

ProductionやProduction、Dev/UATは、チーム単位に必要になることもあると考えられますので、ビジネス的な要件／チームのミッションなどを踏まえて柔軟に検討しましょう。

AWSアカウントを分けることで、以下の要素を分離できます。

セキュリティ、AWSリソースへのアクセス
各種制限（リソース数やAPIコールのスロットリング）
料金

1つのAWSアカウントでは管理上の理想とはほど遠い状態になることが想像できるかと思います。「そのサービス、みんなで利用してるけど、だれが費用負担するの？」など・・・

このアプローチを採用するにあたり、以下の点を考慮する必要があります。単純にAWSアカウントを増やしてしまうと、逆に管理が大変になってしまいます。

自動化
拡張性
セルフサービス化
ブロッカーではなく、ガードレールに（リスクを排除するのではなく、緩和する？）
監査可能性
柔軟性

アカウントを分離を検討するにあたっては、以下の点に注意が必要なので押さえておきましょう。基本要件として必ず考慮するべきでしょう。

Rootアカウントの管理（通常は使用しない）
CloudTrailやGuardDutyの有効化（基本的には有効化するべし）
職務上の役割とAWS上の権限のマッピング
ID連携
アカウント間の連携のためのロールの設計
統制のために何を強制するか

で、実際にどのように分けるべきかが以下の通りになります。

Organization Account/Billing
Log Archive
Security
Shared Service
Network
Sandbox（必要に応じて複数）
Dev（必要に応じて複数）
Pre-Prod（必要に応じて複数）
Prod（必要に応じて複数）
Team Shared Services（必要に応じて複数）

Organization Account/Billing

既存のデータセンターとは接続しない
OrganizationでSCPを定義する
支払いを集約する
ボリュームディスカウントの適用
作成するリソースは最小限
アクセスは厳しく制限

SCPについては、CloudTrailの無効化をできないようにしたり、要件に応じてInternetGatewayのアタッチを禁止するなどの制限をするといいでしょう。

Log Archive

ログ保存用のS3バケットで削除処理を制限／バージョン管理を有効化
CloudTrailやその他セキュリティログの集約
アカウントへのログインを通知
アクセスは厳しく制限

ログの真正性を担保できるようにすることが重要です。

Security

既存データセンターと接続
セキュリティツールや監査機能をこのアカウントから提供
GuadDutyのマスターアカウント
アクセスは厳しく制限

Shared Service

既存データセンターと接続
DNS, LDAP/ActiveDirectory
開発のためのツールを提供（GoldenAMI, Pipeline）
Scanning Infrastructure（利用されていないインスタンス、不適切なタグ、スナップショットの世代管理）
監視
アクセスは厳しく制限

EC2などでサーバーを構築する必要がある場合にはこのアカウントにVPCを作成して環境を構築しましょう。

Network

ネットワークチームで管理
Direct Connectの管理（Connectionの所有）

Sandbox（必要に応じて複数）

既存データセンターと接続しない
革新的なこと／新しいことを試す場所
利用できる料金に制限をかける
自律的な運用

Dev（必要に応じて複数）

改善を素早く繰り返す
コラボレーションスペース
Stage of SDLC(Software Development Life cycle?)

Pre-Prod（必要に応じて複数）

既存データセンターと接続
Productionとほぼ同じ環境を構築
Staging / Testing
デプロイの自動化

Prod（必要に応じて複数）

既存データセンターと接続
Production環境を構築
アクセスは厳しく制限
デプロイの自動化

Team Shared Services（必要に応じて複数）

Data Lake
プロダクトやチームに関連する共通のツール、サービス

まとめると、以下のスライドのような構成になるかと思います。

PCIなどの監査を受ける場合には、必要に応じてより分離をするなど柔軟に対応しましょう。

BP's Landing Zone Journey

次に、BP社の事例が紹介されていました。

基本的には前述のフレームワークに沿ったAWSアカウントの分離を実現していました。しかし、最初から理想通りの構成だったわけではありません。どのように構成が変更していったのか、その際にどのような考え方で臨んだのかに注目してください。

BP社のAWSジャーニー

2011年頃からクラウドサービス（IaaS）の利用をはじめて、今日では"Self-Service Landing Zone Zolution"を適用するまでに至ったとのことです。

2016時点では、以下のようなAWSアカウントの構成だったとのことです。

この時点ではリソースの作成などはセルフサービスではあったもののリソースレベルでのアクセス制御を行っていたこともあり、現場からは「もっと使わせろ！」との声があがったそうです。ここでの反省点は「完璧を目指してしまったこと」とのことです。

また、このタイミングでOrganizationがリリースされたり、最近ではIAMのPermission Boundaryがリリースされるなどして活用しているとのことでした。実際に、利用できるリージョンを制限したり、VPC Peeringを制限するなどの目的でPermission Boundaryを活用しているようです。

また、AWS Landing Zone Solutionも活用しているとのことです。

AWS Landing Zone

といった感じで、今では以下のように改善したとのことです。

構成図からは、以下の主要な改善点が読み取れます。 AWSの提示するLanding Zoneの考え方にかなり寄っている（全く同じではない）ことが確認できます。

システム／チーム別にProd/Pre-prod/アカウントを分割
Sandboxアカウントの作成

これに合わせて、AWSアカウント作成の手続きを整備したりセキュリティイベントへの対応を自動化するなどの取り組みも行っているとのことです。

現状が完璧だとは思っておらず、AWSの進化をフォローしつつ利用者の要望に常に耳を傾ける必要がある、ということで事例紹介が締められました。

Action Plan & Checklist

最後にLanding Zoneを適用するためのアクションプランとチェックリストが紹介されていました。

これらのうち、Coreアカウント群の作成はLanding Zone Solutionに含まれるAccount Vending Machineで簡単に実施できるようです。これにより、多くのアクションアイテムを消化できるので活用しましょう。なお、Landing Zoneの利用はAWSの担当者より入手する必要があるようです。