こんにちは。クラウドリードチームのフクナガです。
2022年5月25日から26日にかけて開催されたAWS Summit Japan 2022で「テンプレートによる AWS環境のガバナンス〜 Baseline Environment on AWS 徹底解説」というセッションを視聴しました。
このセッションを視聴して得られた知見などをレポートします。

セッション概要

タイトル

テンプレートによる AWS環境のガバナンス〜 Baseline Environment on AWS 徹底解説 〜(AWS-22)

スピーカー

アマゾン ウェブ サービス ジャパン合同会社
技術統括本部 シニアソリューションアーキテクト
大村 幸敬さん

概要

AWS 上に多様なシステムを構築するにあたって、全社共通のセキュリティ設定を行いたい場合があります。どうやって展開およびチェックするのがよいでしょうか？ このセッションではテンプレートを使ってAWS環境のガバナンスを実現する考え方をご紹介します。その実装例であるオープンソース “Baseline Environment on AWS (BLEA)”について、その設計思想や実装の詳細、さらに AWS Cloud Development Kit (CDK)コードを使うことのメリットについて、開発者が解説します。
出典：テンプレートによる AWS環境のガバナンス〜 Baseline Environment on AWS 徹底解説 〜(AWS-22)

前提条件

前提知識

• AWSセキュリティサービス群の基礎知識
  AWS CloudTrail、AWS Security Hub、AWS Configなど
• AWS CloudFormationやAWS CDKの基礎知識

レポート

1. クラウド活用に必要なガバナンスの考え方

(1) 中央集権型（ゲートキーパー)

ツールの利用を管理者が承認することが必要な方式になります。
変更作業の手順の事前作成/承認や作業再鑑など、この方式を利用するケースが多いと思います。
管理者の業務が発生する限り、管理者がボトルネックになりアカウント数の増大が難しくなってくるため
AWSでは推奨されないという説明がありました。
ただ、権限のコントロールが完璧にできている（できていると証明できる）場合でない限り
承認を挟まざるを得ないかなと感じてしまいました。

(2) 分散管理型（ガードレール)

利用者が自由に利用可能な代わりに、利用可能な範囲を事前に設定する方式になります。
以下の2つの統制方式を組み合わせながら、セキュリティを高めていきます。
1. 予防的統制
利用できない操作をあらかじめ設定で禁止する方式です。
SCPなどを利用して実施することを想定していて、ガードレールを敷く作業にあたります。
2. 発見的統制
望ましい状態を定義し、そこから外れた操作が行われた場合検知する仕組みで、
AWS Config、AWS CloudTrailなどを利用して実施することを想定しています。
実際に、道を走っていく中で「ここ危ないよね。」っていう場所を見つける作業にあたります。

発見的統制にあたる設定を実施し、運用しながら予防的統制をすべき項目を洗い出していくのが推奨です。
※あらかじめ禁止すべきと想定できるもの（CloudTrailログの無効化など）については予防的統制として制限すべき

先ほど、「やっぱ承認フロー挟むしかないよね」と伝えてしまいましたが、
ガードレールを整備していくことは偶発的な事故を防ぐために必要なので、
分散管理型の考え方はしっかりと覚えておくべきでしょう。

2. テンプレートによるガバナンス実現方法

ガバナンス観点で利用するAWSマネージドサービスをテンプレートで構築する場合に推奨される手順が以下のように説明されていました。

[用語]
共通運用チーム：全アカウントを共通して管理するチーム
利用者：アカウントを発行されて利用する開発/運用者

[手順]
(1) 共通運用チームはアカウントの払い出しと最低限のガードレール設定のみを行う
最低限とは…CloudTrailによる証跡の保持やAWS Configによる管理設定を壊さないための設定
(2) 「実行可能なセキュリティガイド」としてのテンプレートの配布
ガイドや手順書ではなく、テンプレートを配布することで確実に意図した設定を構築されることを担保
(3) 各アカウントの管理責任は各チームが負い、テンプレートも各チームの責任で管理する
ポリシーなどの更新も各チームが担当するイメージ
(4) セキュリティイベントの即時通知は各チームで対処
(5) 重要なセキュリティイベントや定期的な順守状況の確認（SecurityHubなど）の確認は共通運用チームが実施

AWS Organizationsを利用して、AWS CloudFormation StackSetsを利用したり、CloudTrailで組織の証跡を有効にするなど共通運用チームが一括で管理することも可能ですし、各アカウントの管理責任を各チームが負うモデルだと、セキュリティへの知識レベルによって差が生まれてしまいそうです。
知識レベルが生まれても問題ないように、必要最低限のセキュリティレベルをテンプレートで担保することが大事ということでしょうかね。
利用者の知識レベルによりますが、責任範囲や運用手順（管理方法）については共通運用チームから連携/教育していく必要があります。

3. テンプレートによるガバナンスの考え方

テンプレートを用いる場合のガバナンスの考え方について、以下のように説明されていました。
(1) 許可されたサービスを使うより（ゲートキーパー）、アカウントの中で自由にサービスを使える環境を（ガードレール）
(2) 集中管理で設定を強制するより、テンプレートによる同一設定の展開と分散管理を
共通のリソースが展開されることをテンプレートを利用することで確認、また適応状況などはSecurity Hubなどで管理
(3) 未然に防ぐより、逸脱の検知と迅速な修復を
(4) 初期構築の自動化だけでなく、コードによる継続的なメンテナンスを
(5) 自社に最適化した仕組みを作るより、AWSサービス拡充の柔軟な取り込みを

上記は、あくまで「推奨」で各利用者の状況に合わせて仕組みづくりをしていきましょうという内容だそうです。
「逸脱の検知と迅速な修復」はAWS Configの非準拠AWSリソースを修復アクションで修復するのが知られています。
https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/remediation.html
逸脱した場合の修復方法を用意するのはなかなか難易度が高いため、まずは逸脱を検知する仕組みを構築することを目指すとよいと思います。

4. Baseline Environment on AWS(BLEA)

AWSのセキュリティベストプラクティスを実装したオープンソースのサンプルテンプレート
AWS CDKを利用して開発されていて、下記Githubで公開されています。
https://github.com/aws-samples/baseline-environment-on-aws
ファイルやドキュメントがかなりあり、利用方法についても説明が記載あります。

Githubにて公開されているテンプレートを各要件に合わせてカスタマイズを実施し、独自のテンプレートとして利用することを想定されているそうなので、利用するまではかなり勉強が必要です。
また、AWS CDK以外のコード化ツールを利用する想定の案件では管理が煩雑になるため利用を検討することが必要と考えています。
例えば、Terraformでコード化する想定の案件ではこのテンプレートを利用する場合ガバナンス観点のリソースはAWS CDK、その他はTerraformという煩雑な構成になってしまいます。
管理を簡単にするためにはAWS CDKで実装されたBLEAを勉強してリソースの設定を把握し、利用するコード化ツールで実装しなおすことが必要です。

まとめ

AWSにおいてインフラ構築テンプレートを用いたAWS環境のガバナンスについて実現方法や考え方についてご解説いただきました。
セキュリティ関連設定については、アカウント間での差異も少ないのでテンプレートをうまく活用し、社内でのレベルを合わせていくことが重要だなと感じました。
BLEAについては、内部の実装についても勉強し社内でのAWS利用に生かせればと思います。