[レポート]ソニーミュージックグループのセキュリティの取り組み ～300 を超える AWS アカウントのセキュリティ確保～ – AWS Security Forum Japan 2023 #aws #awssecurity

こんにちは、臼田です。

みなさん、AWSのセキュリティ対策してますか？(挨拶

今回は2023年10月12日にオフラインで行われたAWS 国内最大のセキュリティイベントであるAWS Security Forum Japan 2023の下記セッションのレポートです。

ソニーミュージックグループのセキュリティの取り組み ～300 を超える AWS アカウントのセキュリティ確保～

ソニーミュージックグループでは、多くの Web サイトやアプリケーションが AWS 上で稼働しており、現在 300 を超えるアカウントを管理しています。ビジネスのスピードとセキュリティの確保を両立するため、AWS セキュリティサービスを活用したセキュリティ施策・ポリシーを SMEJ Guardrail と命名し、設定の自動修復の仕組みや SIEM を構築してきました。本セッションでは、構築した仕組みと工夫、苦労についてお話します。

株式会社ソニー・ミュージックエンタテイメント 担当課長（セキュリティ戦略担当） 田代 雄亮氏

アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 エンタープライズソリューション本部 ソリューションアーキテクト 加藤 史也

レポート

• 前半はAWS加藤さん
  • 普段はソリューションアーキテクトとしてエンタープライズの企業を支援している
• マルチアカウント構成の必要性
  • なぜ必要なのか
  • 単一のアカウントので複数の環境を管理するとどうなるか
  • システムごとの開発・ステージング・本番環境がある
  • 1つのアカウントでたくさんのアクセスするユーザーが居る
    • メンバー数に応じて誰がどこにアクセスできるのかが複雑になる
    • 権限設定にミスが生じる
  • リソースやコスト管理にも弊害が出る
    • タグ付けなどの追加運用が必要になる
  • 環境ごとにAWSアカウントを分けるマルチアカウント構成がベストプラクティス
  • AWSアカウントが境界として機能する
  • 権限委譲や請求の分離などが簡単になる
• マルチアカウント構成の統制プラクティス
  • ここでは3つに絞って紹介
  • ガードレール
    • 統制の考え方の言葉
    • 対になる考え方としてゲートキーパー
    • サービスや機能を利用したいときに、事前申請を経てから利用する体制
    • これは開発に対するボトルネックになる
    • マルチアカウント環境ではガードレールが有効
    • 組織として必要なセキュリティを確保し、逸脱しないようにする
    • はみ出さない具体的な仕組み
      • 予防的ガードレール
        • ポリシー違反につながる操作を禁止する
        • SCPで実現する
      • 発見的ガードレール
        • 望ましくない操作を検出・通知する
        • AWS Security Hub
    • AWS Organizations Service Control Policy(SCP)
      • メンバーアカウントが可能な操作を定義するJSON形式のポリシードキュメント
      • 必ず禁止する必要がある操作のみ対象とする
      • これを細かくするとゲートキーパーになるのでやらない
      • ガードレールの設定を破壊するような操作を禁止するなどにとどめておく
    • AWS Security Hub
      • 発見的ガードレールを統括して始められる
      • 各セキュリティサービスの検知を一元管理できる
  • ログの保全と分析
    • 専用のAWSアカウントにセキュリティ関連ログを集約するのがベストプラクティス
    • AWSアカウントの侵害や内部不正、オペレーションミスへの体制を獲得する
    • インシデントレスポンスのための調査・分析をしやすくする
    • AWS CloudTrailの組織の証跡を使ってログを集約できる
    • 膨大なログが集まるのでどう扱うか
      • SIEMを利用するのが手段の1つ
      • AWSではSIEM on Amazon OpenSearch Serviceを提供している
      • CloudTrailやWAFなどの取り込みの仕組みやダッシュボードが用意されていてすぐに使い始められる
  • ベースラインの展開
    • ベースラインは全アカウントに共通で入れる設定
    • AWS Security Hubの有効化もベースライン
    • アカウントとリージョンの数だけ設定が必要なので効率的に設定をしていく必要がある
    • AWS CloudFormationのStackSetsを利用してテンプレートの設定を展開していける
• ソニーミュージックグループの取り組み
  • インシデント起きてますか？
  • 弊社では起きました「ルートユーザーのアクセスキー流出」
  • 被害範囲は詐欺用のドメインがいくつか作られた程度で済んだ
  • リスクとしては情報流出などが発生する可能性があった
• ほとんどのサービスがAWSで動いている
• 社内から感謝されている活動SMEJ Guardrailについて
  • Webサイトが1,300以上
  • ドメインは1,500以上
  • グループ会社・各部門においてセキュリティ対策にばらつきがある
  • SMEJ Guardrailを整備
  • 全力でアクセルを踏んでビジネスしてもらえる環境にした
  • 構成
    • Guardrailの開発はCodePipelineを組んでいる
    • 実行環境はCDKからFargateが展開される
    • メンバーには各種セキュリティ機能が展開される
  • SIEMを使って情報を集約している
  • アラートもSIEMから上げている
  • ログデータの集約アカウントのS3に保存して、誰も編集できないように保全している
    • 将来的にはAmazon Security Lakeを活用していきたい
  • SMEJのAWS利用状況
    • AWSアカウント数は303でガバナンス対象アカウントは240
  • AWS Organizations構成
    • 必須で最新のGuardrailを適用している環境と任意で一部のGuardrailを適用する環境を分けている
  • Guardrailの現状
    • 各種セキュリティサービス全リージョン有効化
    • すべてのrootアカウントを回収している
    • 自動修復適用範囲
      • IAM管理強化と各種パブリック設定禁止
      • S3.4、Lambda.1自動修復などをいれている
  • 最初にGuardrailを適用したらセキュリティスコアが3%だった
  • 担当役員に見せたら「低い方がいいの？」と言われた
  • SMEJ Guardrailロードマップ
    • スモールスタートでだんだん自動修復などを入れていった
    • 各アカウントオーナーと競技しながら調整している
    • SIEMで独自の計算で集約している
    • 準拠率は80%ぐらい
    • 現場から、やらなくていいことが増えて感謝されている
• SIEMの検知例
  • コンソールログインの失敗など監視している
  • SIEM再構築にはAWSのProfessional Serviceを活用した
  • 海外リージョンでのAmazon EC2起動の検知もしている
• 自動化によるメリット
  • 1アカウントからでもやった方がいい
  • オペミスが減って品質が向上する
  • アカウントが増えても人を増やさなくていい
  • 運用ノウハウが溜まった結果
    • 分析結果からフィードバックしてポリシーのアップデートをして、検知を見ながら運用できる
  • 事故事例
    • EC2.8のインスタンスIMDSv2対応を強制したところ一部webサイトで障害が起きた
    • 2,500環境のロールバックも30分程度で行えた
• AWSさんのサポート
  • Enterprise Support定例
  • AWSセキュリティ定例
  • オフィスアワー
  • EBC
• まとめ
  • 可視化をしてショックを受けることが重要
  • 走りながらポリシーを整備するほうが結果的に早い
  • PoCのフェーズで自動化の仕組みを作ると枠組みが大きくなっても対応可
  • Findingsを増やす人おテェラス人は別人が望ましい
  • AWSさんに可能な限りサポートしてもらう
• セキュリティはバランス！
  • ビジネスの足かせになってはならない
• さいごに
  • マルチアカウント統制の最初の一歩
  • 新規に始めるならまずはAWS Control Towerの利用を検討するといい
  • AWS Security Hubをオンにしてないなら、1アカウントでもいいのですぐにオンにするといい

感想

実践しているマルチアカウント管理とそのツラミを紹介してもらいました。

IMDSv2の強制による弊害など、知見になるのでこういうナレッジは活用していきたいですね。