セキュアな AWS アカウントを SMEJ Guardrail で実現

各アカウントそれぞれでセキュリティ対策を行うのではなく、自動修復も含めた Guardrail を適用したアカウントをユーザーに渡すことで一定のセキュリティ確保を行いました。各社の業種も違いますし、ビジネス規模も様々となっておりますので、まずは最低限の統制を効かせる形で対応を行いました。

例えば、絶対にやらないで欲しい設定を自動修復に入れたり、各種ログを中央に集約することでインシデント対応に備えました。そこをスタートにして今もバージョンアップを行い、よりセキュアな環境を提供できるようにしています。

ガバナンス対象の AWS アカウントが 200 ほどあり、利用できる全てのリージョンで Guardrail を適用しています。対象アカウント×リージョンで 3,000 以上の環境に適用されています。ちなみに 1 アカウントあたり月間平均数十ドルのコストでセキュアにしています。

また、完全内製で開発・運用を行っています。自動化の仕組みを最初から作っておくと、規模が大きくなっても少人数で対応が可能です。

下図は全体の運用に関する構成図です。

Guardrail が適用されたアカウントより吸い上げたログを元に日々 AWS Security Hub を確認したり、Kibana で分析したり、インシデントが起きた際には速やかに調査ができる構成にしています。

SMEJ Organizations では現在、ユーザーアカウントグループをまとめる OU と、Organizations を管理するための Core-OU を設置しました。先述の Security Admin アカウントと Guardrail Admin アカウントはこの Core-OU に属しています。

Guardrail システム全体のカテゴリーは大きく、「開発者領域」「オペレーター領域」「メンバーアカウント領域」の 3 つに分かれています。それぞれが独立して稼働できるよう、疎結合性を意識した設計です。「開発者領域」と「オペレーターに領域」は Guardrail Admin アカウント上に構築されています。

現在、オペレーター作業部分は SMEJ 独自の AWS アカウント発行プロセスに組み込まれており、Guardrail 環境の適応はほぼ完全に自動化されています (もちろん手動対応も可能です)。また、一般的なベストプラクティスとして CI/CD (継続的インテグレーションおよび継続的デプロイ) の観点から、開発チームがデプロイしたタイミングで全メンバーアカウントへデプロイするという考え方もありますが、ソニーミュージックグループの組織構成からそのようなプロセスは採用せず、定期的なタイミングでのデプロイを採用しています。

SMEJ Guardrail は、AWS でベストプラクティスとされている主要なセキュリティサービスをカバーします。

次にこれらを全アカウント全リージョンに展開するために便利なサービスを活用しています。

最後に、共通サービスとして下記のサービスが付随します。

もちろん最初からこのように設計できたわけではありません。SMEJ Guardrail 実装当初は対象アカウントが 90 アカウントかつ東京リージョンのみの対応でした。この環境における適用時間は、1 環境あたり約 5 分で適用できており、順次実行したとしても 450 分 = 7.5 時間ほどで完了するため、朝からゆっくり実行していれば営業時間内に完了するものでした。

ところが、グループ内で AWS 利用が促進されるなか、また Guardrail 適用リージョンを全リージョンに展開するなかで、実用に耐えうる時間内で適用が完了しないという問題が発生しました。また、全リージョン適用にあたっては、リージョナルサービスとグローバルサービスの差、特定のサービスが GA されていないリージョンが存在する、など複雑な条件分岐が発生いたしました。そこで、CloudFormation を並列実行する環境の構築をおこなう必要性がでてきたため、新たに設計しなおしたという経緯があります。

SMEJ Guardrail の開発環境はシンプルで、言語として TypeScript、フレームワークとして AWS CDK を採用しています。AWS CDK 自体の説明は割愛させていただきますが、CloudFormation テンプレートでは記述するのが大変なリージョン別の条件分岐などを、プログラミング言語レベルで論理実装可能という点がメリットのひとつです。また、CloudFormationでは記述できない、または記述しないほうが良いと思われる処理は AWS Lambdaで実装します。こちらも TypeScript で記述し、NodeJS で実行します。この CDK スクリプトと Lambda 関数のプログラミングをひとつのプロジェクトとしてまとめて実装することで、開発効率向上を実現しています。

プログラミング言語として実装することのメリットのひとつにソースコード管理があります。ソースコード管理のデファクトスタンダードとなっている Git ですが、レポジトリ管理サービスとして、AWS CodeCommit を利用でき、さらに AWS CodeBuild、 AWS CodePipeline と組み合わせることで簡単に CI/CD 環境を実現することができます。

SMEJ で管理する AWS Organizations 配下には、SMEJ Guardrail を管理する Guardrail Admin アカウントと、SIEM 用の Security Admin アカウントが配置されています。SMEJ Guardrail アカウントから各メンバーアカウントへ敷設した Guardrail の結果、AWS Security Hub で検知された Findings が Security Admin アカウントの Security Hub へ集約されます。その結果をもとにいくつかの脆弱性に対し自動修復を実施しています。

AWS 構成図はいわゆるベストプラクティスで示されているものと大差ないですが、こちらの開発環境とデプロイ環境についても、AWS CDK、CodeCommit、CodeBuild、CodePipeline を利用し Infrastructure as Code と CI/CD を実現しています。現在自動修復用の Lambda 関数は 21 個あり、Docker イメージとしてまとめ ECR 上に保管、Lambda コンテナランタイムでの実行を定義しています。

• 事象と対応
  上記対応したところ、一部 web サイトで障害が起きました。
  昔から起動しているインスタンスの場合 v2 の認証ができない場合があります。
  •  とある日 23:34 web サイトの障害発生検知
  • 26:20 対象アカウントの EC2.8 対応をロールバック
  • 翌日 18:30 全アカウント・全リージョンのロールバックを決定
  • 19:00 ロールバック完了

グループ各社の環境の認識不足により起こしてしまったトラブルでしたが、当時合計 2,500 ほどの環境に対するロールバックを 30 分でできたことは、クラウドの良さと並列実行可能な準備 (図 5) をしていて良かったと実感した瞬間でした。

今では最初から SMEJ Guardrail が適用されているセキュアなアカウントをグループの利用者に渡すことができるようになりました。

全ての準備を完璧にしてスタートするよりは、下記をおすすめします。

• まず可視化
• 走りながらポリシー整備、常にバージョンアップ
• 最初から自動化の仕組み (枠組みが大きくなっても対応可能)

ぜひ Guardrail を構築してビジネススピードを上げてみませんか ?