3月24日、サイバーエージェントのエンジニア・クリエイターによる技術カンファレンス「CyberAgent Developer Conference2022」を開催しました。本記事では、「1,000プロジェクトを越えるサイバーエージェントグループのクラウドセキュリティモニタリング」の様子をお届けします。

■クラウド利用の実態

サイバーエージェントグループのクラウド利用は主にAWSとGCPが中心で、アカウント数とプロジェクト数は2021年10月時点でAWSが636+、GCPは458+。現在は、ここから更に増えています。

クラウド利用は今後も増えていくことが予想され、アカウント管理やセキュリティが重要課題です。パブリッククラウドの特性上、インターネットから常に狙われるリスクがあり、サイバー攻撃の標的やポイントが増えるためセキュリティリスクも増加する可能性があります。安全に運用されていれば必ずしもリスクが高いわけではありませんが、安全性が担保されているかを確認するのにも労力が必要です。

サイバーエージェントには、CSIRT組織「CyberAgent CSIRT」が存在し、インシデント対応のフローは下記の通りになっています。

クラウドのセキュリティインシデント対応は特有の難しさがあります。私達セキュリティチームは、サービスの特性やクラウドの状況を知らずに対応に入るケースがほとんどであるため、非常にプレッシャーのかかる状況で、必要最小限の関係者で効率的に情報共有する必要があることです。

また、調査方法や対応はケース・バイ・ケースです。時にはセキュリティの経験や専門知識が必要になるため、該当するサービスをよく知る内部の人だけでは対応が難しくなるケースもあります。

対応段階では、例えば以下のようなクラウドリソースの変更を伴うケースでは非常に慎重な判断を行う必要があります。
– IAMのキーのローテーション（もしくはロールのパーミッション変更）
– ワークロードのNW隔離
– ソフトウェアバージョンの変更

その変更でサービス全体が停止する可能性がある場合は、サービス継続が優先か、それとも被害拡大防止を優先するかを判断する必要が出てきます。

ここでセキュリティチームに焦点を当てると、実態の把握に時間がかかること、セキュリティの担当者だけでは適切な判断ができないという課題があります。

一方、サイバーエージェント内部ではどのように対応しているか説明します。、サイバーエージェントでは事業拡大が最重要です。プロダクトチームがサービス開発に集中できるように、最適な組織設計を行ってきました。例えばインフラやセキュリティ専門チームを作るなど専門性を分離し、生産性、アジリティを維持して開発を進めています。

こういった考え方はとても重要ですが、パブリッククラウドでの開発は少し雰囲気が変わってきます。クラウド利用者は責任共有モデルを意識する必要があります。これは開発チームは今まで以上に責任の範囲が大きくなるということを意味します。インフラ、ネットワーク、セキュリティを「知らない」では済まされません。分かれた組織をどう巻き込むか、情報共有スピードをどう上げるか、透明性をどう担保するかがより重要になります。

昨年サイバーエージェントグループでは「P-SEC」という組織が設立され、PSIRT的な活動が始まりました。サイバーエージェントグループ内部でも、セキュリティ面における考え方の変化が生まれてきています。

セキュリティチームでは、セキュリティリスクを可視化するツール「RISKEN」を内製しました。（「RISKEN」はOSSとしても公開しています）この「RISKEN」はクラウドセキュリティの課題に着目し、セキュリティの脅威情報を継続的に収集してスコア化するものです。これにより、セキュリティの状態をサービス開発チーム、セキュリティチーム、クラウド管理者チームとすぐに共有ができ、問題発生時にすぐ検知・対応する体制を作る事ができました。ここで「RISKEN」を使い、AWS環境のセキュリティを評価する様子をデモ動画（約10分）をご覧ください。

デモ動画では以下のような流れで「RISKEN」を解説しました。
– RISKENのプロジェクトを作成する
– AWSの設定を行う
– セキュリティスキャンを実行し、結果を確認する
– アラート機能やダッシュボードを確認する

＊以下はRISKENの画面サンプルです

ここからは「RISKEN」を内製化した背景についてご紹介します。世の中には、クラウドの設定上の問題を検知するCSPMソリューションが存在します。サイバーエージェントグループでも、ニーズはあったので各種検証も行いました。ところが、全社規模で導入するとなると予想以上にコストがかかることも分かりました。また弊社のようにプロダクト数が多いと、アカウント数もかなり増え、導入作業や導入後の設定変更で、運用コストが高いという懸念も見えてきました。

加えてマルチクラウドの必要性です。例えばサービスがAWSで閉じていれば、AWSのSecurityHubを採用する事もできます。しかし最近ではCSP各社が様々な強みを持つサービスを提供しており、サイバーエージェントグループでも適材適所でマルチクラウドを採用するケースが増えています。そのためセキュリティ側もマルチクラウドに柔軟に対応できるようにしておきたいという要望がありました。

さらにはIaaSだけではなくSaaSも併せて見る必要が出てきます。例えばGitHubで保存されたソースコードを解析したり、OSINTツールでインターネット上のドメイン情報などを調査したり、というケースがありました。様々なデータを集めて解析できるようなものがほしいという要望が出てきたことなどを受け、内製化に至りました。

実際に「RISKEN」をサイバーエージェントグループ内に展開した効果についてご紹介します。現在はAWSを中心に利用しており「RISKEN」を導入したプロジェクトでは積極的にセキュリティに対応しています。予期せぬ効果としては、使用していないAWSアカウントやサービスを棚卸しできて、相当なコスト削減が実現できた事業部もありました。

「RISKEN」全体のアーキテクチャは下記の通りです。メインは小規模のEKSのクラスタで構築し、クラスタ内には複数のマイクロサービスが動いてます。

アーキテクチャの特徴的なポイントとしては、認証部分にはCognitoを利用し、社内のIdPとOpenID　Connectで連携してます。これで異動や退職などのユーザー管理をIdP側に任せる事ができて運用が非常に楽になります。OpenID Connectは標準的なプロトコルですので、例えばGoogle Workspaceも連携可能です。

マイクロサービス毎に細かいスペックチューニングが可能です。セキュリティのスキャンの対象によりサーバーのリソースを結構必要とする場合があるので、チューニングのしやすさでKubernetesは非常に良かったです。最後にデータストアなどステートフルなコンポーネントはマネージドサービスになるべく寄せて、可用性や運用面を向上できています。RISKENではRDSやSQSをよく使います。

クラウドの利用が増加するなか、1,000以上のクラウド環境のセキュリティスキャンを継続的に実行していくためにはスケーラビリティが非常に重要です。1個1個のスキャンは数秒で終わるものから数十分、数時間かかるものもあります。特にネットワーク系のスキャンはかなり時間がかかります。

簡単なスキャンの処理のフローを図示します。左下に人（オンデマンドスキャン）と時計（スケジュールスキャン）の2パターンがあり、どちらも同じフローです。各種スキャナーサービスは、すべてこの中央のメッセージキュー経由で実行します。それをワーカーのサービスが拾い、スキャンをかけるので、クラウドが増えればワーカーの数を調整してスケールアウトを実現しています。

例えばAWSの環境が多ければAWS関連のワーカーサービスを増やします。巨大なデータベースアカウントがあれば、ワーカーのスペックを調整したり、CPUやメモリのスケールアップで調整します。

次に、認可の仕組みです。「RISKEN」の利用拡大に欠かせないのが設定の簡単さです。大量のデータベースアカウントにスキャン設定を入れていくので、設定手順が簡単で、かつセキュアでなければいけません。

「RISKEN」ではAssumeRoleを使い、一時一次キー（STS）の仕組みを利用しています。これはDataDdogはじめ様々なクラウドサービスでも利用されている手法です。IAMユーザーなどのデータを集約するパターンもありましたが、それだとIAMユーザーならキーの管理の問題、データの収集ならエクスポートの設定の課題があるので、IAMロールを使う形が簡単かつセキュアです。

GCPではサービスアカウントを利用しています。「RISKEN」側でサービスアカウントを1つ発行してプロジェクト側のIAMに許可する設定を入れています。

プロジェクト側にVerificationCodeベリフィケーションコードというラベルを設定してもらう事でスキャンしています。スキャン時にこのコードの検証を行います。プロジェクト本人しか知り得ないコードと、GCPのプロジェクト権限があるか、プロジェクトの所有者確認を行います。この仕組みにより、プロジェクトごとに複数のサービスアカウントを発行、管理する必要やプロジェクト毎に分ける事なく、複数の環境でのGCPのスキャンを可能としています。