先日行われました AWS JAPAN SUMMIT ONLINE 2020 にて、「大規模な組織変遷と100以上のAWSアカウントの横断的セキュリティガードレール運用について」のテーマにて、私たちのグループで取り組んでいる全ての AWS に対する横断的な取り組みを ビジョナル CTO 竹内 と ビジョナル CIO 園田 より発表させていただきました。

今回は、その発表内容について、発表の中で伝えきれていない内容などより詳細にお話しさせていただきます。

こんにちは、システム本部 プラットフォーム基盤推進室 ORE (Organizational Reliability Engineering) グループ の 長原 です。
私が在籍するグループでは、 Visional グループの全事業のクラウドや非機能要件等に対して、横断的にエンジニアリングによる課題解決に取り組んでいます。

複数事業・マルチアカウント運用で生まれた課題

株式会社ビズリーチは、2020年2月よりグループ経営体制に移行し、新たに Visional グループとして、「新しい可能性を、次々と。」というミッションのもと、様々な領域で事業創出を続けています。
グループ全体で運用している AWS アカウントの数は 100 を超えています。

多くの AWS アカウントを運用する中で、以下のような課題がありました。

管理対象の AWS アカウントが増加するにつれ、課題感は顕在化してきました。

ソリューション

以下の大きく 2 つのソリューションにて解決を図りました。

ガードレール

アカウントに対して硬すぎる制限を設けるのではなく、できるだけ自由を確保しつつ望ましくない領域のみ制限、または発見できるソリューション

従来多く行われていた「ゲート」によるブロッカーとなる制御から、「ガードレール」として禁止操作を制限して危険な設定を検出することでアジリティを維持してガバナンスコントロールを実現することができます。

ガードレールには2つの種類が存在します。

アカウントベースライン

マルチアカウント/マルチリージョン環境の共通リソースの設定を自動化するソリューション

組織内の AWS アカウントにおけるガードレールを実現するために、複数の AWS アカウントそれぞれに必要とされる共通の設定を一括で導入することを可能にします。
新規作成アカウントの初期セットアップやベースラインの更新に伴う一括変更を可能とし、効率的かつ確実性の高いマルチアカウント運用を実現することができます。

取り組みの全体像

前述したソリューションを実現するため、以下の取り組みを 1 年程度の期間で進めてきました。

No ソリューション 概要 概説
1 Visional-Baseline アカウントベースライン管理 ・ AWSアカウントに対して、ベースラインとなる共通設定項目を管理・適用する仕組み。ベースラインの構成管理及び、構成ドリフトを定期的に確認して差分を検出して通知する。
2 AWS Organizations 組織アカウントの一元管理

予防的ガードレール		 ・ AWS Organizations にて組織のアカウントや一括設定が可能なものは、Visional-Baseline と併用して組織の設定を管理・適用する仕組み。
・ 組織全体で禁止する一部の操作のポリシーを管理/反映し、予防的ガードレールを実現。
3 Amazon GuardDuty + AWS SecurityHub 発見的ガードレール (セキュリティ脅威検知) ・ 全アカウントのセキュリティ脅威をAmazon GuardDutyにて自動検出し、AWS SecurityHub経由で結果を集約して可視化及び重要度の高いものは通知する発見的ガードレールの実現。
4 AWS Config 発見的ガードレール (コンプライアンス遵守) ・ 全アカウントに対して予め規定したルールへのリソースの準拠状況を自動評価し、評価結果を集約して可視化及び重要度の高いものは通知する発見的ガードレールの実現。
5 Trusted Advisor Dashboard 発見的ガードレール (AWSベストプラクティス評価) ・ 全アカウントに対してAWS Trusted AdvisorによるAWSのベストプラクティスに則ったチェックを自動的に行い、チェック結果を集約して可視化及び一部通知する発見的ガードレールの実現。

※ AWS SUMMIT の発表内容から No.2 “AWS Organizations 予防的ガードレール” を追加しています。

各々の取り組みの概略図は以下の通りです。

当社の AWS のマルチアカウント構成は以下の通りです。1

また、AWS Organizations など組織レベルで扱う AWS サービスや構築する機能検証のために、当社では2つの AWS の組織を構成しています。
検証用の組織には、上の Core Accounts の検証用アカウントを用意して、グループ全体のアカウントへの影響を排除した環境にて私たちの部署のみで利用しています。

ここからは、それぞれの取り組みの詳細について説明します。

アカウントベースライン

Visional-Baseline

Visional-Baseline は、マルチアカウント/マルチリージョンの組織内アカウント共通設定を管理するための独自の仕組みです。2

マルチアカウントの構成管理としては、 AWS Organizations と Visional-Baseline の 2 つの機能を利用して実現しています。

  1. AWS Organizations による構成管理
    • AWS Organizations の機能で、AWS Config のルール管理 / SCP (Service Control Policy) の禁止ポリシーの制御など AWS の組織に対してマスターアカウントで適用可能なものについては、AWS Organizations の機能を優先して利用しています。
  2. Visional-Baseline による構成管理
    • AWS Organizations でサポートされていない AWS サービスの有効化や設定、リソースの作成などは、Visional-Baseline を利用して独自に構成管理を実現しています。

実現方式

Visional-Baseline は、構成管理 (IaC) の手段として Terraform を採用しています。
Terraform にてアカウントベースラインとなる設定を 1 つのリポジトリにて一元的に管理し、ターゲットとなるアカウントを指定してマルチアカウントへ並列実行できる仕組みにしています。

概略の構成と動作イメージは以下の通りです。

Visional-Baseline の機能は、AWS のマスターアカウントに配置しており、実行は AWS Systems Manager の Automation にて、実行の種類 (plan / apply) と対象アカウントを指定して実行します。
マスターアカウントは組織全体の AWS への変更の権限を持つため、実際のオペレーションは厳格なプロセスによって内部不正のリスクを回避できるように設計しています。
私の所属する部門 (図の Platform-Team) はマスターアカウントの参照権限のみを保持するようにしており、ベースラインのコードの開発を行っています。アカウントベースラインの設定が事業のサービスや運用へ影響がないことを予め考慮するため、主要事業部の SRE のレビューを行い、マージ後に適用可能な状態となるようにしています。
実行のオペレーションは AWS の ROOT アカウントの管理などマスターアカウントの全権限を持つ情シス部門 (図の Corporate-IT) が行い、Automation の承認ステップにて許可された承認者の承認後に実際の適用が行われます。

Automation の承認リクエストの送信や各アカウントへ適用後の結果は、Slack への通知を組み合わせてオペレーションの簡略化と操作の透明性を高める工夫を行っています。
実際のオペレーションは以下流れとなります。

続いては、 Visional-Baseline のアーキテクチャです。

マスターアカウントの構成管理 (aggregator-provisioner)

マスターアカウントの Terraform の CI/CD の仕組みです。
ベースラインの仕組み (baseline-deliverer) の構成管理などを含みます。

ベースラインの実行機能 (baseline-deliverer 左部)

オペレーションの実行 I/F には前述した Automation を利用しており、実行後ははじめに Approve Phase として、 approval-request の AWS Lambda にて入力値の検証や AWS アカウント ID からアカウント名の逆引きを行い、ターゲットアカウントリストの情報など含めて承認リクエストを Slack で通知します。

承認処理が行われると、 Automation より Execution Phase として、 baseline-deliverer の AWS Lambda が invoke されます。

baseline-deliverer では、ターゲットとなる複数のアカウントへ並列で Terraform 実行して効率化するため、 AWS CodeBuild をアカウント数分実行しています。

AWS CodeBuild の実行は非同期の呼び出しで時間を要するため、 Automation は実行開始が確認できたら完了となります。

ベースラインの実行結果通知 (baseline-deliverer 右部)

各アカウント分複数呼び出した AWS CodeBuild の実行結果の確認を簡略化するため、 Slack へ実行結果を通知しています。
全ての AWS CodeBuild が完了したことを検出するために、 Amazon CloudWatch Events の 終了のイベントを トリガに AWS Lambda を実行しています。予め、 AWS CodeBuild 呼び出し時に Automation 実行単位の ID と AWS CodeBuild の開始されたビルド ID を DynamoDB へ保管し、 AWS Lambda では、終了した AWS CodeBuild のビルド ID を突き合わせることで実行全体の完了を判断しています。3

個々の AWS CodeBuild の実行完了後、変更結果を Slack にて通知します。
Terraform の実行結果のログをメンバーアカウントの担当者へ閲覧可能とするため、 AWS CodeBuild の実行結果の Amazon CloudWatch Logs を S3 へエクスポートし、変更結果の通知メッセージへそのログへのリンクを含めています。S3 バケットは社内限定で参照可能としています。

また、全ての AWS CodeBuild の実行が完了した際には、実行全体の結果サマリを Slack へ通知し、ベースライン実行の結果を確認しています。

考慮点

Terraform のマルチアカウントサポート

Terraform にてマルチアカウントの構成管理を行っています。
マスターアカウントから、ターゲットのアカウントへ Terraform を実行するには、 AWS Provider を定義する際に assume_role にてターゲットのアカウントの IAM Role を指定することで、クロスアカウントでの実行を実現しています。

1
2
3
4
5
6
7
8

provider "aws" {
  region = "ap-northeast-1"
  alias  = "ap-northeast-1"
  assume_role {
    role_arn     = local.assume_role_arn
    session_name = local.assume_role_session_name
  }
}

Terraform の State ファイルをマルチアカウントで管理するには、Terraform の Workspaces の機能を利用しています。
実行前に、ターゲットの AWS アカウント ID で workspace を切り替えてから実行します。
State ファイルを管理するバックエンドは、S3 Backend にて全てのアカウントの State ファイルを管理しています。

構成ドリフトの検出

ベースラインでセットアップする設定がメンバーアカウントにて意図せずに変わった場合、ベースラインで設定する機能動作に支障をきたす恐れがあります。
そのため、日次で自動的に Terraform の plan を全アカウントへ実行することで、構成ドリフト (構成管理と実環境との設定差分) が発生している場合には、Slack 通知を通じて検知しています。
この機能によって、ベースラインの設定が常に組織全体に対して適用されている状態を確認することが可能となっています。
また、完全に変更を禁止すべきものについては、後述する防御的ガードレールの SCP の機能によって対象リソースの変更操作を禁止することができます。

Terraform の採用理由

Terraform 以外に、AWS では AWS CloudFormation をマルチアカウント/マルチリージョン向けに展開するための StackSets が提供されています。
StackSets では、CloudFormation テンプレートを指定したアカウントとリージョンに対して、一括で展開することができます。
ベースラインを導入した 2019 年時点では、StackSets と Terraform を比較し、 以下の理由などから Terraform での独自の展開の仕組みを構築することを選びました。

また、StackSets を内包して後述するガードレールを含めたランディングゾーンを構築する AWS Control Tower のサービスもありますが、AWS Control Tower は、東京リージョンではサービスが提供されていないこと、及び 2019 年時点では既存の AWS 組織やアカウントの管理ができなかったため、採用は見送りました。5

効果

予防的ガードレール

サービスコントロールポリシー (SCP)

対象の操作を実施できないようにするガードレールとしては、AWS Organizations の SCP (サービスコントロールポリシー) を活用しています。
発見的ガードレールにて望ましくない操作を検出しますが、明確に禁止された一定の操作を制限することで、リスクを回避することができます。

当社で禁止しているポリシーの一部は以下の通りです。

実現方式

AWS Organizations の SCP は、ポリシーを作成して、Root / OU / Account に対してアタッチ可能となっています。
また、ヒエラルキーに従ってポリシーは配下の OU / Account へ継承されます。

当社では、これまで AWS Organizations でアカウントは管理していましたが、 OUs (Organizational Units) を活用しておりませんでした。
今後、OU を活用可能としていくため、現在ではトップレベルの OU (図のGlobal OU) を構成してそこに禁止ポリシー (図の DenyGlobal) をアタッチしています。

考慮点

ポリシーのアタッチ箇所について

SCP は、マスターアカウントで実行されたアクションについては制限することができません。
組織全体の禁止ポリシーは Root にアタッチすることも可能ですが、その場合には万一特定のユーザで禁止ポリシーを一時的に例外にしたい時に一時的に組織全体からデタッチする必要があります。
そのため、トップレベルの OU に全体の禁止ポリシーを付与しておくことにより、一時的に例外にするアカウントを Root 配下に移動させることで運用回避できる手段を用意しておくことができます。

特定のプリンシパルをポリシーの対象外とする

アカウントベースラインの適用は、Terraform にてメンバーアカウントへ Assume Role して操作するため、それも制限の対象となります。
SCP のポリシーの Condition にて aws:PrincipalARN で 除外する IAM ロールを指定することで対象外にすることが可能です。
対象の IAM ロール へ Assume Role を許可する信頼関係をマスターアカウントに限定し、その IAM ロールの変更についても SCP で制限をかけておくことで、アカウントベースラインからの操作のみ許可した状態でメンバーアカウントでの操作のみを制限することができます。

効果

発見的ガードレール

発見的ガードレールの仕組みにおいては、以下の共通の方針で設計しています。

セキュリティ脅威検知 (AWS SecurityHub / Amazon GuardDuty)

発見的ガードレールのうち、AWS アカウントのセキュリティの脅威となりえる悪意あるアクティビティや不正な動作を検出するための Amazon GuardDuty とセキュリティアラートの一元的な管理を行うための AWS Securityhub を活用しています。

これまでは、組織内の全ての AWS アカウントで脅威検知を行っていなかったため、脅威の事実把握が十分ではない状況でした。
過去に発生したセキュリティインシデントでも、検出までの時間を要していたことで対処が遅れるといった事例もありました。
そのため、組織全体で脅威検知を導入してセキュリティインシデントの情報を集約して可視化と通知の仕組みを導入することで、セキュリティの部署にて統合的にモニタリングして、適切な対応を取るプロセスの構築しました。

実現方式

Amazon GuardDuty の全体構成は以下の通りです。

検出結果集約

Security アカウントを組織内の AWS Securityhub マスターアカウントとして全てのセキュリティに関する情報を集約します。
Visional-Baseline によりメンバーアカウントの全リージョンの AWS SecurityHub 及び Amazon GuardDuty のサービス有効化と Security アカウントの AWS SecurityHub と連携設定を行います。
各 AWS アカウントでは、 Amazon GuardDuty と AWS SecurityHub を有効化することで、検出結果は自動的に AWS SecurityHub へ取り込まれます。
AWS SecurityHub のマスターアカウントへ連携しておくことで、自動的に Security アカウントへ結果が集約されます。
Security アカウントでは、 Amazon CloudWatch Events の AWS SecurityHub に関するイベントを全てのリージョンにて Amazon Kinesis Data Firehose で 1 つの S3 バケットに出力することで、リージョンを集約して組織全体の検出イベントを保存しています。

Slack 通知

Security アカウントの AWS SecurityHub へ連携された検出結果は、Amazon CloudWatch Events を通して SNS で東京リージョンへ全リージョンのイベントを集約して 東京リージョンの AWS Lambda で Slack の処理を行っています。

以下のイメージで Slack 通知を行っています。

Slack メッセージは、対象アカウントや検出結果にて構成し、スレッドにてイベントの raw データを閲覧可能としています。
AWS SecurityHub のSeverity Label (重要度ラベル) が HIGH 又は MEDIUM の検出結果のみを通知対象とし、 LOW は除外しています。

また、通知機能には検出の除外フィルタを独自で実装しています。
Amazon GuardDuty は、機械学習や行動モデルを用いた脅威検出のため、通常業務における操作を MEDIUM で検出することがしばしば発生します。組織全体の検出結果を一元管理して追跡する場合は、大量の通知により健全な運用を行うことができません。
Amazon GuardDuty では、抑制ルール によって自動アーカイブする機能が提供されていますが、 AWS SecurityHub にて集約した場合にはそれを利用することができません。
そのため、通知機能の AWS Lambda の処理にて、findings (調査結果) のフィールド条件に合致した場合は通知を抑制する除外フィルタを提供しています。

Kibana による可視化

AWS SecurityHub のマルチアカウントかつマルチリージョンの検出結果を一元的に Kibana にて可視化しています。
可視化は、ガードレールの取り組みで共用する Platform アカウントの Amazon Elasticsearch Service を利用しています。
Security アカウントの全イベント保存用の S3 バケットをレプリケーションして、PUT トリガーで VPC 内の AWS Lambda にてデータを加工して、Elasticsearch へ投入しています。

可視化したダッシュボードは以下の通りです。

組織の全てのアカウントやリージョンで検出された検出結果の集約結果を表示し、結果タイプ毎やアカウント毎の発生状況などを確認できるようになっています。

考慮点

AWS SecurityHub 経由の集約理由

Amazon GuardDuty でもマスター/メンバー構成を取ることで、マスターアカウントへ検出結果を集約することが可能ですが、AWS SecurityHub に集約して通知や可視化を行う手段を選択しています。
理由は、AWS のセキュリティ系のサービスでは、AWS SecurityHub にて AWS SecurityHub Findings Format (ASFF) と呼ばれる標準的な検出結果形式に自動変換して統合的に取り扱えるようにすることで、今後導入を拡大する場合に拡張しやすくするためです。
今回のガードレールには含まれていない Amazon Macie や Amazon Inspector 、IAM Access Analyzer などの AWS サービスを利用している AWS アカウントの検出結果は既に自動で AWS SecurityHub へ連携されてダッシュボードでも閲覧できる状態となっています。

Amazon Elasticsearch Service の活用方法

Amazon Elasticsearch Service (以下、AES) の Kibana は、社内エンジニアへ参照権限で閲覧可能としています。
RBAC を実現するために Amazon Cognito による認証認可を行っています。
当社では AES は VPC内部に立てるルールが設けられており、その構成を取るためには、こちら の構成を参考にしています。6

リバースプロキシ用の nginx 及び、参照のみのユーザでログインするためのカスタムログインページを返す Flask アプリケーション を ECS サービスで運用しています。

効果

コンプライアンス評価 (AWS Config)

AWS Config を利用して、AWS リソースの設定や関連性及び変更内容を記録し、規定のルールに基づいて AWS リソースを継続的に評価することで、セキュリティのリスクや信頼性を損なう可能性のある不適切な設定を特定して対処を促します。

AWS アカウントは、事業部の担当エンジニアにより適切に設計・運用されることが好ましいですが、全てのシステムで十分な対策を取ることは困難のため、不備や考慮漏れによる不適切な設定が影響した障害やインシデントは過去に度々発生していました。

そのため、はじめはチェックシートを導入してセルフチェックの評価にて対策してきましたが、チェックシートの運用は以下のような問題を抱えていました。

そこで、自動的な評価が可能な部分については、 AWS Config のルールを用いた継続的な評価によりルールに準拠しない場合は担当者へ通知し、適切に対応するプロセスを構築しました。
また、組織全体の AWS アカウントの評価結果を集約して可視化することで、状況把握に活用しています。

現在は、30 個程度のマネージドルール 及び カスタムルールを採用しています。

実現方式

AWS Config の全体構成は以下の通りです。

組織のルール管理

組織全体の AWS Config のルールの管理は、マスターアカウントにて AWS Organizations の Organization Config Rule の機能を利用しています。
put-organization-config-rule で設定したルールは、組織の AWS アカウントの AWS Config へ自動的に反映されるため、ルールを一元的に管理する仕組みとなっています。

メンバーアカウントの AWS Config 設定

Visional-Baseline により、メンバーアカウントの全リージョンの AWS Config 設定を行っています。
AWS Config の有効化、及び Platform アカウントの東京リージョンを AWS Config のアグリゲート先として設定することで組織全体の評価結果を集約する設定を行います。
また、Amazon CloudWatch Events にて、 AWS Config のイベントを Platform アカウントの東京リージョンの Event Bridge のイベントバスへ送信する設定を行うことで、全リージョンの評価のイベントも集約しています。

Kibana による可視化

AWS Config はリージョナルサービスのため、マルチリージョンの評価結果を一元的に可視化するため、アグリゲートアカウントに集約された各リージョンの結果を AES へ投入して Kibana にて可視化しています。

可視化したダッシュボードの一部は以下です。

Overview Dashboard Account Detail Dashboard
組織全体の AWS Config 評価結果 アカウント毎の非準拠結果詳細

リアルタイム非準拠通知

メンバーアカウントにて自動的に評価結果がイベントとして、Platform アカウントのイベントバスへ送られています。
イベントバスの AWS Config のイベント発生をトリガーとして AWS Lambda を実行し、新規で非準拠となった場合には、 Slack にて以下のような通知を行っています。

考慮点

マネージドルールの選定

AWS Config では、 AWS より提供される マネージドルール と独自で AWS Lambda にて評価を実装する カスタムルール が存在します。
AWS Config をはじめに導入する際には、どの評価ルールを採用するか検討が必要となります。
現在は、コンフォーマンスパック と呼ばれるコンプライアンス基準や業界ベンチマークに合わせてマネージドルールの組合せの単位で選定することも可能です。適合パックは、選定時に提供されていなかったため、個別のマネージドルールから選定を行っています。
選定においては、主要事業部の SRE とセキュリティ部門と合同で、全社で共通して必ず守るべきルールを条件として選出しました。当時で 100 個程度のルールから30 個程を選出しています。
また、現状ではカスタムルールもいくつか運用しています。

カスタムルールの管理

カスタムルールは独自の評価を AWS Lambda にて実行してマスターアカウントに展開します。
カスタムルールは、特定のリソースタイプの設定変更でトリガーされて評価を実行するか、定期的にトリガーされて評価を実行するかを選択することができます。
各種アカウントの AWS Config より評価が実行されると、マスターアカウントの AWS Lambda がルールやリソースの情報をインプットとして実行されます。評価結果を AWS Config の putEvaluations API で送信します。

カスタムルールの関数を管理するものとして RDK (Rule Development Kit) が OSS で公開されています。 AWS Lambda のいくつかのランタイムをサポートしたロジックのテンプレートが公開されているため、ロジック部分を参考にしています。
RDK は Compliance as Code のためのクライアントとして動作するツールとなっており、直接展開や CloudFormation Template を出力する機能を備えています。 私たちは Terraform による一元化した構成管理を実現するため利用していませんが、そうでない場合は有益な選択肢となり得ます。

ルールの評価対象区分の管理

AWS Config のルールを Organization Config Rule にて組織全体へ展開する場合、通常では全てのアカウントへルールが適用されます。
しかし、当社ではルールの評価対象アカウントとして、Production 用途のみに限定したいケースが存在しました。
例えば RDS インスタンスのバックアップ有効化 (db-instance-backup-enabled) のルールでは、 Production 用途以外のアカウントの一部の RDS においては、コスト観点や用途次第でバックアップを必要としないケースも存在するため、組織全体で必須とする評価対象としては Production 環境に限るといったものです。
そこで、AWS アカウントのタグに環境種別をアカウント開設時から設定しておき、そのタグに応じて put-organization-config-rule の excluded-accounts オプションを利用してルールの評価対象に含めるかどうかを制御しています。

ルールの重要度の管理

AWS Config で非準拠を検出した際には、担当者へ Slack で通知して対応を促しますが、多くのルールの中でも実際に重要度は異なります。
例えば RDS スナップショットパブリック禁止 (rds-snapshots-public-prohibited) のルールで非準拠が発生した場合には、データ次第で個人情報流出に繋がる可能性もあり、特にリスクが高いため早急に状況を確認すべき状況です。
しかし、全てのルールの非準拠検出時に同じ緊急度で対応を必要とするものではなく、また、導入当初は既存のリソースや設定に対する非準拠件数が一定量存在するためルール毎の重要度を設定して高いものから優先的に対応すべき方針として定めることにしました。
重要度は 3 つに分類し設定しています。

重要度の管理方式としては、 Organization Config Rule はタグをサポートしていないため、付加情報を持たせることができません。
そこで、ルールの構成管理は Terraform を利用しているため、ルール毎に付加情報を定義し、それらをセットで JSON で S3 へ出力し、可視化のための Elasticsearch へ投入する機能や通知の機能で読み込むことでルールの付加情報の利用を実現しています。

Config Rule List 社内公開

Config Rule をリスト化して社内公開することで、非準拠を検出した際に、担当者が検出理由やリスクを正しく理解できるようにしています。
また、対応方法に参考となるドキュメントや対応済みの Terraform のコードのリンクを載せることで、対応工数を減らす工夫を行っています。

リストの内容例

効果

ベストプラクティス評価 (Trusted Advisor)

AWS Trusted Advisor は、セキュリティ / フォールトトレランス / パフォーマンス / コストなどの観点で AWS のベストプラクティスに従っているかをチェックするサービスです。
AWS Config は利用者が定めたルールに従って評価を行いますが、 AWS Trusted Advisor は、AWS の推奨するチェックとなるため、AWS の最適な活用を支援するための位置付けで利用しています。
他のガードレールと同様に組織全体の AWS アカウントの結果集約と可視化、通知を実現しています。

実現方式

AWS Trusted Advisor の全体構成は以下の通りです。

導入時点では、Organizations View の機能は提供されていなかったため、各 AWS アカウントの AWS Trusted Advisor のチェック結果を StepFunctions のワークフローを利用して、定期的にクローリングして収集する仕組みを取っています。
収集した結果は DynamoDB へ書き出し、全ての結果を取得後にテンプレートへ結果をレンダリングしたファイルを S3 へ PUT し、 API Gateway を経由して開発者から閲覧します。

可視化ダッシュボード

可視化したダッシュボードは以下の通りです。

Slack への通知

新たに検出された結果は 以下のように Slack へ通知しています。

考慮点

AWS Trusted Advisor のチェック自動化

定期的にチェック結果をクロールするため、 メンバーアカウントでは定期的にチェックを実行する必要があります。
下記に記載の通り、個々のアカウントで AWS Trusted Advisor ダッシュボード へアクセスがない場合は最長で 1 週間前のチェック結果 (ビジネスまたはエンタープライズサポートを利用時) となってしまうことが理由です。

AWS サポート FAQ より

  • Trusted Advisor ダッシュボードにアクセスすると、直近の 24 時間以内に更新されなかったチェックは、自動的に更新されます。
  • ビジネスまたはエンタープライズサポートのお客様の場合、Trusted Advisor データは毎週自動で更新されます。

最新の結果をダッシュボードで閲覧可能とするため、ワークフロー内で各メンバーアカウントの全てのチェック項目に対して RefreshTrustedAdvisorCheckRequest を送信しています。7

RefreshTrustedAdvisorCheckRequest 後のチェックは非同期処理となります。基本的に 1 時間以内にはチェックが行われることが確認できています。
そのため、ワークフローは現在 3 時間周期で実行し、3 時間以内の AWS 組織全体のチェック結果を可視化及び通知しています。

カスタム Slack 通知メッセージ

他の発見的ガードレールも同様ですが、Slack 通知は AWS Chatbot を利用することで、 AWS のマネージドサービスでの Slack 通知を実現することが可能です。
しかし、 AWS Chatbot の通知メッセージは、AWS アカウント ID を含むためマルチアカウントに対応できますが、 AWS アカウント ID だけでは可視性が悪いため、 AWS Organizations へ list-accounts の結果より AWS アカウント名を逆引きしてカスタムフォーマットのメッセージへ含めて通知しています。

効果

まとめ

AWS マルチアカウントの管理と運用の様々な課題に対して、AWS Organizations やアカウントベースライン、ガードレールを導入することで解決を図りました。

AWS Organizations やアカウントベースラインでは、効率的なマルチアカウントの管理を実現しました。
ガードレールでは、自動検出するセキュリティの脅威や望まない設定等へ適切に対処することで、適性なアカウントの運用の仕組みを実現しました。

これらのソリューションによって、従来トレードオフと考えられていた変化に柔軟かつ素早く対応する「アジリティ」と適切に統制された管理運用を行う「ガバナンス」を両立することができます。

変化の速い現代においてスピードを失わずにリスクを最小化することで、運用上の優秀性を向上させてビジネスを加速させることができると考えています。

今後の展開

今後もマルチアカウントを更に安全に効率的に運用していくために拡張・改良していきます。

また、今回の話では AWS をターゲットとしていますが、 GCP においても同様の課題感を抱えているため、そちらの整備も進めていきます。

  1. 当社のマルチアカウント構成における Core Accounts は、少しコンウェイの法則に寄った状態となっています。特に Platform Account は部署の意味合いが強く出ており、役割に沿った切り口で適切に構成することをお勧めします。AWS のマルチアカウントのベストプラクティスの推奨アカウントが設計の参考となります。 ↩︎

  2. 社内では、 AWS-Baseline という名前で提供していますが、AWS 公式のサービスの名称として誤認される恐れがあるため、社外向けには Visional-Baseline という名称で取り扱っております。 ↩︎

  3. 現在は AWS StepFunctions にて複数のエントリに対して動的並列処理を行うための Map の State が提供されているため、AWS CodeBuild のステータスを個別に管理せずに実行から完了までの一連の手続きを Step Function のワークフローで構築することでシンプルに実現できます。 ↩︎

  4. 2019年11月に StackSets の構成ドリフト検出をサポートしています。未確認ですが、 Change Sets 相当の変更点の確認についても確認できる可能性があります。 ↩︎ ↩︎

  5. 2020年4月に AWS Control Tower にて、既存の組織やアカウントを管理するをアップデートがリリースされました。東京リージョンは 2020年10月現在もサポートされていません。 ↩︎

  6. この nginx の設定ファイルでは upstream のエンドポイントを DNS キャッシュし続けるため、resolver ディレクティブの valid オプションで ttl を設定して、cognito-auth や AES のエンドポイントのインスタンスの切り替わりを考慮する必要があります。 ↩︎

  7. AWS Trusted Advisor を含む AWS Support API を使用するには、ビジネスまたはエンタープライズの AWS のサポートプランが必要です。 ↩︎

長原 佑紀
長原 佑紀

SIer からビズリーチへ転職し、ビズリーチサービスのインフラエンジニアを経て、現在はビジョナルのプロダクト横断の課題解決に勤しむ。 AWS の SAP と DOP を保持。