はじめに
こんにちは。株式会社ソニー・ミュージックエンタテインメントの田代です。
ソニーミュージックグループのセキュリティを守る者です。
グループでは 200 を超える AWS アカウントがあり、各メンバーアカウントオーナーが安全・安心に各自のサービスを展開する為の環境を「Sony Music Entertainment Japan Guardrail (以降、SMEJ Guardrail)」として提供しております。
* 「Guardrail」については こちらの記事 をご覧ください。
builders.flash メールメンバー登録
課題
グループ各社にてそれぞれの担当者がサービス展開を行っていますので、セキュリティ対策にばらつきがあることが課題となっていました。
一例ですが、こちらの図 1 は、悪意のある攻撃に対し、B 社 web サイトはセキュリティ対策をしてないので攻撃をそのまま受けている状態です。C 社 web サイトは AWS WAF により、攻撃の一部は弾いている状態です。他に実例として、AWS CloudTrail のログファイルを長期保管しておらず、インシデントが起きた際に調査が困難だったこともありました。
図 1 : 各社セキュリティ対策
対応
各アカウントそれぞれでセキュリティ対策を行うのではなく、自動修復も含めた Guardrail を適用したアカウントをユーザーに渡すことで一定のセキュリティ確保を行いました。各社の業種も違いますし、ビジネス規模も様々となっておりますので、まずは最低限の統制を効かせる形で対応を行いました。
例えば、絶対にやらないで欲しい設定を自動修復に入れたり、各種ログを中央に集約することでインシデント対応に備えました。そこをスタートにして今もバージョンアップを行い、よりセキュアな環境を提供できるようにしています。
適用環境とコスト
ガバナンス対象の AWS アカウントが 200 ほどあり、利用できる全てのリージョンで Guardrail を適用しています。対象アカウント×リージョンで 3,000 以上の環境に適用されています。ちなみに 1 アカウントあたり月間平均数十ドルのコストでセキュアにしています。
また、完全内製で開発・運用を行っています。自動化の仕組みを最初から作っておくと、規模が大きくなっても少人数で対応が可能です。
AWS Security Hub スコア
Guardrail の運用面で中核をなしているのが AWS Security Hub です。適用当初の会社全体のスコアが下記になります。なかなか衝撃的でした。弊社セキュリティ責任者より「このスコア低い方がいいんだよね ?」と聞かれたレベルです。(100 % が満点で、それぞれの基準で 3 % と 2 % がスタートでした)
このスコアを急いで上げなければならない状態はおわかり頂けると思いますが、1 つ 1 つの項目を精査して、後のパートの自動修復等のチャレンジへとつながっていきます。
図 2 : Security Hub スコア
Guardrail 運用構成図
図は全体の運用に関する構成図です。 Guardrail が適用されたアカウントより吸い上げたログを元に日々 AWS Security Hub を確認したり、Kibana で分析したり、インシデントが起きた際には速やかに調査ができる構成にしています。
設計概要
株式会社ソニー・ミュージックエンタテインメント 白川です。SMEJ Guardrail の設計と実装を担当しております。
ここからは SMEJ Guardrail の設計概要を説明します。はじめに SMEJ における AWS Organizations の構成を図示いたします。(図 4 : SMEJ Organizations)
デプロイフロー
SMEJ Organizations では現在、ユーザーアカウントグループをまとめる OU と、Organizations を管理するための Core-OU を設置しました。先述の Security Admin アカウントと Guardrail Admin アカウントはこの Core-OU に属しています。
Guardrail システム全体のカテゴリーは大きく、「開発者領域」「オペレーター領域」「メンバーアカウント領域」の 3 つに分かれています。それぞれが独立して稼働できるよう、疎結合性を意識した設計です。「開発者領域」と「オペレーターに領域」は Guardrail Admin アカウント上に構築されています。
現在、オペレーター作業部分は SMEJ 独自の AWS アカウント発行プロセスに組み込まれており、Guardrail 環境の適応はほぼ完全に自動化されています (もちろん手動対応も可能です)。また、一般的なベストプラクティスとして CI/CD (継続的インテグレーションおよび継続的デプロイ) の観点から、開発チームがデプロイしたタイミングで全メンバーアカウントへデプロイするという考え方もありますが、ソニーミュージックグループの組織構成からそのようなプロセスは採用せず、定期的なタイミングでのデプロイを採用しています。
利用サービス
SMEJ Guardrail は、AWS でベストプラクティスとされている主要なセキュリティサービスをカバーします。
- AWS Config
- AWS CloudTrail
- Amazon Detective
- Amazon GuardDuty
- Amazon Inspector
- AWS Security Hub
- AWS IAM Access Analyzer
次にこれらを全アカウント全リージョンに展開するために便利なサービスを活用しています。
- AWS CloudFormation
- AWS CodeCommit
- AWS CodeBuild
- AWS CodePipeline
- AWS Cloud Development Kit (AWS CDK)
- Amazon ECS
- AWS Fargate
- AWS Lambda
最後に、共通サービスとして下記のサービスが付随します。
- AWS IAM
- AWS Key Management Service (AWS KMS)
- Amazon CloudWatch
- AWS Step Functions
- Amazon EventBridge
- Amazon SNS
- AWS Systems Manager
- AWS Chatbot
- Amazon VPC
- Amazon S3
- AWS SDK
- AWS CLI
- Amazon ECR
- AWS CodeStar
考えること
もちろん最初からこのように設計できたわけではありません。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 コンテナランタイムでの実行を定義しています。
図 6 : 自動修復の処理フロー
図 6 : 自動修復の処理フロー
Security Admin への連携について
トラブル
いくつかトラブルが起きましたが、影響が大きかった件を紹介します。下記の自動修復を適用した際に、全環境のロールバックを行うことになりました。
修復対象 : AWS Security Hub ベストプラクティス EC2.8 の自動修復適用時「EC2 インスタンスは IMDSv2 を使用する必要があります」という項目です。
修復内容 : こちらの図をご覧ください。(図 8 : EC2.8 を修復するための API コールをおこなうコード)
事象と対応
上記対応したところ、一部 web サイトで障害が起きました。
昔から起動しているインスタンスの場合 v2 の認証ができない場合があります。とある日 23:34 web サイトの障害発生検知
26:20 対象アカウントの EC2.8 対応をロールバック
翌日 18:30 全アカウント・全リージョンのロールバックを決定
19:00 ロールバック完了
グループ各社の環境の認識不足により起こしてしまったトラブルでしたが、当時合計 2,500 ほどの環境に対するロールバックを 30 分でできたことは、クラウドの良さと並列実行可能な準備 (図 5) をしていて良かったと実感した瞬間でした。
まとめ
今では最初から SMEJ Guardrail が適用されているセキュアなアカウントをグループの利用者に渡すことができるようになりました。
全ての準備を完璧にしてスタートするよりは、下記をおすすめします。
- まず可視化
- 走りながらポリシー整備、常にバージョンアップ
- 最初から自動化の仕組み (枠組みが大きくなっても対応可能)
ぜひ Guardrail を構築してビジネススピードを上げてみませんか ?
筆者プロフィール
田代 雄亮
株式会社ソニー・ミュージックエンタテインメント
情報セキュリティ部 プロデューサー
2001 年にソニーミュージックグループに入社。試聴機・デジタルジュークボックス開発、営業、社内情シスを経て、現在グループのセキュリティを確保しています。サーバーレス、Python、🍺が好きです。
白川 朋幸
株式会社ソニー・ミュージックエンタテインメント
情報セキュリティ部 チーフ
2010 年にソニーミュージックグループに入社。Linux 上での Web アプリケーションの設計・開発・実装に従事。2016 年よりグループ内の AWS 関連プロジェクトに携わる。AWS Certified DevOps Engineer - Professional (DOP), AWS Certified Security - Specialty (SCS), AWS Certified Solutions Architect - Professional (SAP)。カレーライスは飲み物です。
桐山 隼人
アマゾン ウェブ サービス ジャパン合同会社
セキュリティ事業本部本部長
様々な業界のスタートアップからエンタープライズまで、日本及びアジアパシフィックのお客様に、クラウドにおけるセキュリティとコンプライアンスの実現を支援しています。好きな食べ物はうどんです。薄味が好きです。