やらないという選択肢はない　AWS Configを用いたマルチアカウント・マルチリージョンでのリソース把握とコンプライアンス維持

AWS Configでスケールする品質維持環境を作りましょう

光野達朗氏（以下、光野）：「AWS Configを用いたマルチアカウント・マルチリージョンでのリソース把握とコンプライアンス維持への取り組みについて」というテーマで、ZOZOテクノロジーズの光野が発表いたします。よろしくお願いいたします。

あらためまして自己紹介いたします。私はZOZOテクノロジーズの光野と申します。キャリアとしては、もともとヤフー株式会社でサーバサイドのエンジニアをしていたのですが、あるときAWSに出会いまして、AWSのサービスのエンジニアから徐々にマルチアカウントの管理に進んでいます。よろしくお願いいたします。

簡単に弊社がもつプロダクトを紹介します。弊社が運営するのはZOZOTOWNという日本最大級のファッション通販サイトで、1,300以上のショップ、7,400以上のブランドの取り扱いがあります。もし服が好きな方がおられましたら、ぜひともご利用ください。

2つ目にWEARというサービスも併せて開発をしています。こちらは日本最大級のファッションコーディネートアプリです。1,400万ダウンロードを突破して、多くの方々に利用していただいています。「何か服を探したい」「人が着ている状態で見たい」という方はぜひWEARをご利用ください。

今紹介したZOZOTOWNもWEARも、いずれも一部をAWSの上で動かしています。プロダクトにとってもAWSは現在非常に重要なポジションを占めています。

ただ、今からお話しする範囲は個々のプロダクトではなくて、そのプロダクト全体を支える組織全体のAWS運用に関するお話です。本日はマルチアカウント事例祭りということもありますし、個々のプロダクトに関する話は省略します。

この発表を通してお伝えしたいことは、この一言に集約されます。「AWS Configでスケールする品質維持環境を作りましょう！」。どうしても管理者というのは、アカウントが増えたとしても人数が少なくなりますので、自動化は非常に重要と感じています。

すべてのリソースがコンプライアンスを満たしていることを保証したい

まず簡単に前提として、（スライドを示し）弊社ZOZOテクノロジーズのAWSのアカウント体系はこのようになっています。AWS Organizationsを使い、マスターアカウントとメンバーアカウントの親子関係を持ってアカウント管理をしています。マスターアカウントは請求の管理などを行っており、主な運用者は私です。

続いてメンバーアカウントは、これが先ほどあったZOZOテクノロジーズのプロダクトを動かしているアカウントです。本番環境用とか事前環境用とか、そういったものもたくさんあり、主な運用者はプロダクトの担当者です。

ZOZOテクノロジーズでAWSの利用が普及するにつれて課題がありました。すべてのリソースがコンプライアンスを満たしていることを保証したいという課題です。ここで言うコンプライアンスというのは、AWSで有効にしたい設定・無効にしたい設定のことを指しており、そして守ることで品質が上がることを大事にしています。

もちろん、これはAWSベストプラクティスや社内の取り決め、または世の中のトレンドに基づいて策定をしています。例を挙げますと、非常にシンプルですが、セキュリティグループの22番ポートをインターネットに対して公開してはならないということが具体的な1項目になります。こういった基礎的な設定をすべてのリソースで保証したいというのが課題になります。

ただ「すべてのリソースって？」と言ってもAWSは24リージョンありますし、現在どうやら175サービスあるようで、そのどこかで作られるものすべてとなってしまいます。そしてそれをAWSアカウント分掛け算して考えなければなりません。

やらないという選択肢はないと思っています。まず絞るとしてもEC2、RDS、S3といった頻出のサービスについては網羅したいと考えています。1アカウントなら大変だと思いますが「がんばる」も可能だったかもしれません。弊社の場合、現在約60のアクティブアカウントを保有しており、どんどんと増加傾向にあります。

これを人力でやるのはほぼ不可能と考えています。もちろん、みんなで守るということができればよかったのですが、熟練者であれ強い操作権限を持てば絶対ゼロにはできません。何かミスをすることももちろんあると思います。ミスをするなというのもなかなか息苦しいですし現実的でもありません。「ルールを違反したリソースを自動的に検知してくれたらいいのに」と、先ほどの課題に対してどのように向き合うのかを考えていました。

やりたいことはすべてConfigでできた

実際にそういうサービスは存在します。本日の主役となる、AWS Configです。AWSのリソースの設定を記録して評価をしてくれるという、なかなか登場しないサービスかと思います。（スライドを示し）こちらが使っている様子なのですが、どんなリソースが何個あるのか。例えばこの場合、スクリーンショットですがS3のパケットが11個となっています。

右側の「ルール」は、これはコンプライアンスを具体化したものの評価結果がありまして、「S3 BucketのPublicReadを禁ずる」というルールに非準拠のパケットが1つあるということがこの画面からわかります。またリソースの変更履歴や現在の設定状況も見えるので、このConfigを使えばほとんどのことは叶えられると思っています。

結果として、何か特別な仕組みを作る必要はなく、やりたいことはConfigだけですべてできました。ルールの策定と非準拠のリソースの通知、または組織全体のリソースの俯瞰についてもAWS Configアグリゲータという機能があります。（スライドを示し）この右側のスクリーンショットです。

弊社の場合、S3 BucketとかIAMリソースとか全部いろいろなものを数えるとどうやら5万のリソースがあるということが、Configを導入してわかりました。ここから特定の条件を満たすリソースを抽出して何か対応を行うということもAdvanced Queryで可能でした。

やりたいことはすべてConfigでできましたが、Configはリージョナルなサービスです。本日の主題になりますがマルチアカウント・マルチリージョンのこの2つを準備するには工夫が必要でした。ここからは実際にどのようなアプローチでこのマルチアカウント・マルチリージョンを実現したかについて紹介します。

活躍した3つのサービス

実際にこのAWS Configを設定する上で満たしたいことがありました。前提としてやはり組織管理者、統制担当の数はプロダクト担当のエンジニアに比べて圧倒的に少なくなります。これはそういうものかと思いますのでConfig自体の初期設定には手間をかけない。

特にアカウントが増減したときの手間をかけたくない。ルールとその評価結果だけに気を配りたい。設定と評価結果はそれぞれ1ヶ所に集約をしたいということを念頭において設定を進めていきました。

その中で活躍したのが、この3つのサービスです。AWS Organizations、CloudFormationのService Managed StackSets、そしてEventBridge。最終的にこれらを組み合わせることで、例えば自分でLambdaに何かスクリプトを入れたりということはなく、全体の構成を実現することができました。

ちなみにこの資料はあとで共有いたしますので、ご興味がありましたら細かいところについては、あとからゆっくりと閲覧していただければと思います。

いくつか重要なポイントをかいつまんで紹介しますと、Organizationsの機能を使うことで、統合されたサービスはIAM権限が組織内で解決され、設定の一括反映が非常に簡単になります。またCloudFormationはJSONやYAMLでリソースを定義するものですが、このService Managed StackSetsを使うことで、特定の組織全体に対して自動的に反映可能です。

一度設定すればアカウントが増えたとしても、そのアカウントに対して自動的に反映をしてくれます。そして最後にEventBridgeです。こちらを使うことでAWS内で発生したイベントを別のところに転送することができますので、通知の仕組みを非常にシンプルに作ることができました。

（スライドの）再掲になります。こちらはZOZOテクノロジーズのアカウント体系で、先ほどあったOrganizationsを使ったものです。これにサービスのアイコンを重ねますとこのようになります。左から順番に、まずAWS Organizationsでアカウント間連携を強化してやります。その次にCloudFormationのStackSetsでConfig等の有効化や初期設定を行ってやります。

その後、メンバーアカウント側で何かイベントが発生した場合は、EventBridgeを通じてマスターアカウントにすべて集約し、そこからSlackに送るという構成を取りました。

自動化設定の詳細

それを詳細にしますと、このようなかたちになっています。今回アカウントとリージョンが重要ですので青い枠でリージョンをくくっています。

最初に、マスターアカウントからメンバーアカウントに対しましてConfigの有効化を行います。CloudFormationのStackSetsを用いて有効化を行っています。Configの検証ログは専用のアカウントに集約して失われないようにしていますが、今回はこれ以上出番はありません。特に気にすることはない部分です。

Configの設定が全部のアカウント・リージョンにできたあとは、マスターアカウントがマスターアカウント自身に対してOrganization Config Ruleを作成します。これは非常に便利なもので、リージョナルなので東京リージョンに作るとその他のアカウントの東京リージョンにルールが作られます。

なのでこれをすべてのリージョンに対して実行します。そうするとルールがすべて同じものがマスターアカウントから配布されるという状況が実現します。

通知についても簡単に。通知の流れはEventBridgeでアカウントをつないでいます。Configのイベント「AWSリソースを評価」が発生するとEventBridgeでアカウント間のイベント連携を行います。最後にマスターアカウントからChatbotを経由してSlackに通知を行います。

なぜChatbotはこんなことをしているかと言うと、Chatbotはアカウント単位で連携を許可する必要があるため、自動化の妨げになります。それを1ヶ所に集約をしたいということで、わざわざこのようなかたちを取っています。（スライドを示し）こんな感じの通知がSlackに届きます。どこのアカウント、どこのリージョンでどんなルールに対してコンプライアンスが準拠したのか、非準拠になったのかという情報です。

先ほどの環境には今後解決することが、まだまだ残っています。まずルールの拡充が必要です。実は先ほどご覧いただいたものは、ようやく全体の仕組みが整いまして、運用を開始したばかりのかたちになります。効果的なConfigルールを策定し、全体の品質向上を図りたいと考えています。そもそも品質向上が目的ですので、そこにようやく着手できるようになったという状況です。

また、非準拠リソースの修復と自動修復の是非については、まだ議論が済んでおりません。Configには「修復」という設定があり、事前に定められたアクションを非準拠ルールに対して自動か手動かで反映することが可能です。これを自動にするほうが確実に修復されるとはいえ、自動化してしまっていいのか、するとしたら何をするのかという課題がまだ残っています。これらは今後どんどん運用していく中で考えていきたいと思っています。

ManagedRuleを使うだけでもベストプラクティスに沿うことが可能

まとめです。組織全体のAWSでコンプライアンスを満たしたいという課題がありました。本資料におけるコンプライアンスというのはAWSの設定レベルの項目で、特に守ることで品質が上がるものを指しています。これについては、リージョン単位であればAWS Configで可能でした。さらにそれをOrganizations、StackSets、EventBridgeを用いることでマルチアカウント・マルチリージョンの設定・通知自動化を実現することができました。

今後もAWS Configを使ってスケールする品質維持に取り組んでいきたいと思いますし、この発表を見て便利だなと思っていただければ何よりです。

弊社は常に採用活動をしています。プロダクトでAWSを使いたいという人はもちろん、特にAWSを使ってプロダクトを支えることに取り組みたいという方、ぜひ一緒に働きたいと思っています。ご興味ある方は採用ページをご覧いただければ幸いです。以上で私の発表を終わらせていただきたいと思います。ありがとうございました。

このまま引き続き質疑応答の時間に入りたいと思います。ではsli.doを見ていきましょう。まだ時間がありますので下から順番に答えていきたいと思います。

「資料は後日公開されますか？」はい。こちらは後日資料を公開いたしますのでお待ちください。SlideShareで公開後、Twitterでタグを付けて投稿を行う予定ですので、タグをウォッチしていただくのが一番早いと思います。

次に「通知を受け取った後の対応」。今はどのような通知がどれくらい来るのかというのを実験的に見ている段階というのもあり、私がすべて通知の内容を確認して必要であれば各プロダクトチームに直接連絡をしています。この辺りはもう少し賢く、プロダクトチームに直接通知ができるともっと対応がスムーズなのかなと今考えているところです。

では次の質問。「今後設定したいルールってなんですか」について。そうですね、今は非常に基本的なルール、特にセキュリティに対して強く効くSSHのポートの22番をインターネットに公開していないかどうか、そういったことを中心に設定しているのですが、その次に設定したいと思っているのがログに関する部分です。

やはり何かトラブルがあったときに、アカウントAではあるログが出ていたのでスムーズだったが、Bでは出していなかったというようなことがあると、非常に追跡が難しくなってしまいますので、どのアカウントでも同じようにログが出ている状態を担保したいなと考えています。以上です。

次は「ルールはcontroltowerをベースに設定されたのでしょうか？」という質問。ルールに関しては、まだcontroltowerをベースにはしていません。

ConfigにはManagedRuleと言われている、事前にプリセットで含まれているルールがありまして、それを使うだけでもベストプラクティスに沿うことが可能です。ですので、まずはそのManagedRuleの中から先ほど申し上げたような特にセキュリティを高めるようなものを抽出して、どんどん設定をしています。以上です。

アカウントすべての標準なものを満たすのは難しい

非常にたくさんの質問をいただきましてありがとうございます。「Config Rulesの標準化ルールだけでも……」について。ここに書かれている通りかと思います。アカウントすべての標準なものを満たそうと思うと非常にパラメータ設定が難しいと私も感じています。

ですので、現在はConfigを採用したばかりということもありまして、絶対に守ってほしいこと、ポート22番とかあとはS3 Bucketの公開のルールですね。PublicReadやPublicWriteの検知ということを中心にしています。あまり各アカウントの事情を細かく考慮しなくても、まずはこれを検知したいというものを中心に行っています。以上です。ありがとうございます。

「Security Hubのセキュリティ標準チェックも活用できそうでしょうか？」。そうですね。Security Hubはその名前の通りセキュリティの標準チェックも活用できそうだなと思いつつも、実はまだ細かく見れておらず、まずはConfigを終わらせてからSecurity Hubに取り組もうと思っているところです。

特にマルチアカウント・マルチリージョンできるというところが、弊社が非常に重要と考えているところなので、私もまだすべてを把握していませんが、確かSecurity Hubはリージョンに広く使えたように認識しています。こういった機能のセキュリティ標準チェックなどは採用していきたいと考えています。ありがとうございます。

質疑応答時間があと1分ほどですので、あと1つ選んで回答します。少々お待ちください。では「どれくらいの期間で、現在の状態まで構築出来ましたか？」についてお答えします。そうですね。トライ＆エラーも含めて足掛け1、2週間でしょうか。

特に苦労したのがConfigのリソースがリージョン単位なのか、それともアカウント単位なのかということを確認するのに少しサポートケースなどを起票して確認するのに時間を取られたのですが、それ以外にかかった時間は2週間ほどではないかと感じています。以上になります。

すみません、時間の都合ですべての質問を取り上げることができませんでしたが、たくさんの質問をいただきまして誠にありがとうございます。これで私のパートは終わりにいたします。