セキュリティは企業の競争力へ

野渡：近年、企業のセキュリティ体制は経営の根幹とも言える重要な課題となっています。クラウドサービスが社会基盤となっている現代においては、プロダクトごとに様々な技術要素が利用されているため、セキュリティ対策状況を十分に可視化できません。

このような状況の中でプロダクトごとの個別対策では限界が生じており、全社的な統一基準の構築が求められます。

こういった背景の中、サイバーエージェントがAWSを利用するようになり約15年が経ちました。この間、さまざまなサービスが誕生し、それに伴いセキュリティ対策もその都度進化してきました。

まずはクラウドとセキュリティの変遷を振り返りながら、セキュリティ戦略にどんな変化があったのかをディスカッションしていきましょう。

船ヶ山：サイバーエージェントがAWSを導入した2010年頃は、クラウドのセキュリティ機能も限られており、対策は手探りの状態でしたね。当時は、ログの可視化やリソース管理が難しく、必要な機能を社内で独自に実装しながら運用していました。

その後「AWS CloudTrail」による操作履歴の可視化や「AWS Config」による構成管理など、セキュリティに関する機能が充実していきました。他にも「Amazon CloudWatch」によるリソースとアプリケーションのモニタリングが可能になったり、「Amazon CloudFront」への「AWS WAF」のシンプルな導入も進むなど、監視や防御の仕組みが強化され、セキュリティ運用の最適化が進んできました。

野渡：確かに。かつてはクラウドを導入する際、「オンプレミスの方がセキュリティを担保しやすいのでは？」という議論もありましたね。AWSのセキュリティ機能が強化されるにつれ、クラウドのマネージドサービスを活用した運用性に優れたセキュリティ対策が可能になり、社内の認識も変わっていきました。

現在ではOSSの脆弱性対応においてもAWSのセキュリティアドバイザリを参考にすることもあり、リスク対応のスピードも格段に上がりました。フルマネージドなセキュリティ機能は標準化しつつあり、プロダクトで活用する機会が増えていると感じています。

塚田氏：御社が全社的にAWSを導入したのは2011年でしたね。当時は東京リージョンもまだ登場前で、国内では大規模プロダクトにおけるパブリッククラウドの活用事例も少なく、オンプレミスが主流の時代でした。

その後の15年間で、クラウドの活用が急速に広がり、クラウドのセキュリティ機能も飛躍的に進化しました。

仰るとおり、当初は企業が個別にセキュリティ対策を講じる必要もありましたが、現在ではAWS自身が提供するセキュリティ機能を活用することで、標準化された高水準のセキュリティ対策を容易に導入できるようになっています。

野渡：クラウドが当たり前の選択肢になった今、「セキュリティは専門チームだけが対応するもの」ではなく、「開発や運用に携わるすべてのエンジニアが意識すべき課題」 になったと言えます。

塚田氏：昨今のセキュリティインシデントの事例や、クラウドサービスにおけるセキュリティ製品の強化の流れの中、社内の認識にどんな変化が見られましたか？

野渡：以前は、セキュリティは「リスクをゼロにするための守り」という意識が強かったのですが、今では「プロダクトの競争力を左右する要素」になっているのが現状です。

例えば、以前はUIやコストがプロダクトの差別化要因でしたが、現在では「このサービスはセキュリティが強固だから選ぶ」というユーザーも増えてきています。これは特定の事業領域に限らず、企業全体として広がっている流れです。

また、社内での開発においても、個人情報を扱うサービスに限らず、すべてのプロダクトで高いセキュリティ基準が求められる時代になりました。そのため、各プロダクトごとに個別に対応するのではなく、組織全体で統制を取りながらセキュリティ基準を引き上げる必要を感じています。

塚田氏：なるほど。確かに、セキュリティの最低限のベースラインを標準化しつつ、個別のプロダクトごとの裁量を設けるというアプローチは、企業価値の向上や、開発チームの負担を大幅に軽減できるというお話、非常に共感いたします。

例えば「AWS Config」の活用により、リソースの継続的なコンプライアンスチェックを自動化する仕組みを提供しています。これにより、エンジニアが手動でのチェック作業に煩わされることなく、全体として高いセキュリティ基準を維持できる環境が実現されていたりします。

野渡：そうですね。他にも「AWS CloudTrail」の有効化は、以前はオプション的な位置付けでしたが、今では標準の選択肢になっています。また、データベースのディスク暗号化も、本来は非常に手間のかかる作業ですが、ワンクリックで「Amazon Relational Database Service (Amazon RDS)」リソースの暗号化が可能になり、セキュリティ実装のハードルが下がりました。

ふりかえってみると、以前はセキュリティ対策は「後から追加するもの」でしたが、今では開発プロセスの中で自然に組み込まれるようになりました。そのため、開発チームも「追加の負担」と感じることなく、セキュリティ対応を進められるようになっています。

ただし、セキュリティオプションを追加すればするほど、コストが上昇するのも事実です。特に、立ち上げたばかりの子会社や新規プロジェクトでは、「どこまでセキュリティ対策に投資すべきか？」というバランスが課題になります。

船ヶ山：確かに、セキュリティ対策には終わりがなく、脅威の進化に合わせて対応し続ける必要があります。その一方、インフラコストも膨らみやすく、特にクラウド環境では費用対効果を考慮した最適化が求められます。

例えば、AWSではログの記録や分析が重要ですが「AWS CloudTrail」や「Amazon CloudWatch Logs」、「VPC Flow Logs」などをフル活用すると、そのストレージやデータ転送コストが高額になりがちです。実際、[Amazon Elastic Compute Cloud (Amazon EC2)」のコストに加え、ログ管理のために約20%の追加コストがかかるケースもあり、ログの保持期間や保存先を最適化し、ストレージコストを抑える設計が重要になります。

塚田氏：貴重なご意見、ありがとうございます。AWS ではこれまでお客様に還元するために何度も値下げを行っていますが、引き続きよりリーズナブルにご利用いただけるよう努力してまいります。

一方、クラウドのコストメリットを考えるときには、単なる利用料のみでなく TCO（Total Cost of Ownership、総所有コスト）を考慮、評価する必要があります。本来はインフラの構築・運用にかかる様々な費用、例えばデータセンターの確保、電源といった物理的なものから、構築運用を行う人材採用や教育コストなども、AWS にオフロードできているわけです。 

船ヶ山：総合的な投資対効果の観点は重要ですね。社内でのセキュリティ対策には、開発費だけでなく、人材採用コストや運用負担、設備投資も含まれます。クラウドの利用料だけを見ると高く感じることもありますが、開発コストや運用負担を含めて考えれば、クラウドのメリットは明らかです。特に、フルマネージドで提供されるセキュリティ機能をすぐに活用できるため、導入スピードが向上するのも大きな利点です。
 

塚田氏：企業が自社のセキュリティポリシーを明確に定め、統一された基準を持つことは、ますます重要になっています。しかし、どこまで対策を行うべきか迷う企業も多いのが実情です。特に、プロダクトの数が多い企業では、各チームのセキュリティ意識や対応レベルにばらつきが出やすく、統一的なフレームワークを設けるのは簡単ではありません。

その点、御社は「Security CREST」制度を通じて、全社的なセキュリティフレームワークを確立しながら、各チームの自律性も保つ仕組みを実践されていますね。

野渡：サイバーエージェントではビジネス領域も多様で、かつ開発チームごとの裁量も大きいのが特徴です。すべての事業ごとにゼロからセキュリティの仕組みを構築するのは現実的ではないため、まずは共通のフレームワークを定め、標準化すべき部分とプロダクトごとのリスク評価を整理することが必要でした。

そこで、組織全体のセキュリティ施策として策定したのが「Security CREST」です。同制度はNIST CSF 2.0(※1) をベースに、サイバーエージェントが独自に策定したセキュリティ格付け制度です。「Security CREST」で用いるNIST CSF 2.0 Customは、セキュリティの実施状況を一元的に評価・可視化できる共通フレームワークです。また、エンジニアが NIST CSF 2.0 を自分のプロダクトに当てはめて考えやすくなるよう、参考例を充実させるなど独自のカスタマイズをしています。

※1  米国国立標準技術研究所（NIST：National Institute of Standards and Technology）が2024年2月26日に公開したセキュリティ対策を検討・推進するためのサイバーセキュリティのフレームワーク。

塚田氏：良い制度の設計と同じくらい、現場や組織への浸透も必要かと思います。社内の組織カルチャーへの浸透については、どんな工夫をされていますか？

野渡：セキュリティフレームワークを策定する際の課題は、「あらゆるリスクをカバーしようとすると、現場のエンジニアにとって抽象的で使いにくいものになってしまう」ことでした。その結果、現場のエンジニアにとって「具体的に何をすればいいのか？」「どこまで対応すればよいのか？」が見えにくくなってしまうからです。

サイバーエージェントではAWSをはじめとするパブリッククラウドを積極的に活用しているため、クラウド環境に最適化された「実践可能な具体的な指標」を設定しました。 エンジニアが「何をすればよいのか」を明確にし、適切なアクションを取れるようにすることで、「最初の一歩を踏み出しやすい仕組み」を作ることができたと感じています。

そのため、「Security CREST」は、ルールを定めるだけでなく、エンジニアが実践しやすい仕組みとして機能するフレームワークと言えます。

この点は「Security CREST」の相談時に、AWSに相談をした際「エンジニアが評価される仕組みを組み込むことが重要」というアドバイスを参考にしています。

塚田氏：ありがとうございます。もう1つ気になるのが「Security CREST」の発表後の、現場のエンジニアの反応です。船ヶ山さん、いかがでしょうか？

船ヶ山：想像以上に「自分たちのチームも参加したい」という声が寄せられました。中でも、小規模なプロダクトチームや新規事業チームから「導入したい！」という声があがったのは予想外でした。というのも、スタートアップフェーズのプロダクトは、ルールを義務化すると運用が難しくなるため、今回は導入の対象外としていたからです。

こういった声もあり、社内での正式な発表後は「プロダクトに導入したい」と手を挙げてくれるチームや開発責任者が増え、セキュリティを主体的に考えるカルチャーがより定着した印象です。

また、参加方法も「運営から依頼する」だけでなく、「エンジニアが自発的に申し出る」ケースが増えているのも大きな変化です。エンジニアがセキュリティ対策を実施することで評価が可視化されるため、「自分たちの現在のレベルを知りたい」「プロダクトをもっとセキュアにしたい」というモチベーションにつながっているようです。

船ヶ山：「Security CREST」はまだ始まったばかりの取り組みですが、自社で策定できたからこそ、プロダクトに最適化された形で中長期的にブラッシュアップしていきたいですよね。

野渡：そうですね。現在の段階でも基本的なフレームワークの構造は整っていますが、リスクの特定や評価の精度向上には、さらなる改善が必要です。

そのため、セキュリティリスクの識別範囲を拡張し、リスクごとに具体的な対応策を明確化することで、より実践的な運用が可能な仕組みへと進化させていけたらと考えています。

また、プロダクトごとのリスク特性を深く分析し、それぞれに適用できる柔軟な基準を設けることも必要ですね。統一されたルールを適用するだけでなく、各事業のリスクに合わせたアプローチを可能にすることで、実効性のあるフレームワークへと成長させていきたいと考えています。

中長期的には「Security CREST」が浸透し、定期的にブラッシュアップされることで、「Security CREST」自体がリスクアセスメントの役割を果たせれば、最新の脅威環境に常に適応できる開発組織になると思います。

船ヶ山：リスクアセスメントの一環になるのは良いですよね。そのためにも、フレームワークの基本方針や評価基準は確立されていますが、具体的な実装方法については各チームの特性に応じて柔軟に設計できるようにしています。これにより、状況に応じた最適な対応が可能となり、変化の激しい技術環境にも適応しやすくなるはずです。

あとは、社内で培われた知見を「ベストプラクティス」としてドキュメント化し、他のチームが容易に活用できるようなナレッジ共有の仕組みを整えることも重要です。すべての施策を統一するのではなく、実際に効果の高かった施策を優先的に展開し、組織全体にナレッジを共有していく方針です。

この考え方は、プラットフォームエンジニアリングとも共通しています。社内のナレッジ共有を促進し、効果的なプラクティスが迅速に展開される環境を整えることで、「このツールや仕組みを活用すれば業務が改善できる」といった自発的な選択がスムーズに行えるようになることが理想です。

塚田氏：AWSとしても、お客様との対話を通じて、単なるソリューションの提供にとどまらず、セキュリティの考え方や文化を共有することが重要だと考えています。

特に、御社での制度の浸透のための考え方には共感するところが多々ありました。AWSでも「ゲートキーパーではなくガードレール」という考え方を重視しています。これは、すべての行動を厳しく制限するのではなく、「この範囲であれば安全に進められる」という指針を示しながら、開発の自由度を確保するアプローチです。

こういったコンセプトにおける企業における具体例がまさに今回の「Security CREST」につながったので、AWSにとっても良い事例になりました。

船ヶ山：制度と自由度のバランスは非常に重要ですね。私も昨年、社内で「生成AIガイドライン」の策定に関わりましたが、同じ考え方をもっていました。最低限のルールを設定し、それ以外の部分はエンジニアの裁量と判断に委ねる形を取ることで、実際の運用現場に即した柔軟な対応が可能となることを目指しました。

一見すると性善説に基づいた運用に見えるかもしれませんが、このアプローチによって、「この使い方はガイドライン的に適切か？」「このAIツールはセキュリティ的に問題ないか？」といった議論や問い合わせが活発になり、ガイドラインのブラッシュアップにもつながりました。このカルチャーは、野渡をはじめとするセキュリティの啓蒙活動が続けられてきた結果によるもので、地道な活動によりエンジニアの当事者意識が根付いていたと言えます。

野渡：単に「セキュリティが重要だから対策をする」のではなく、「標準化された仕組みを前提に運用することで、運用負担を減らしながら安全性を確保する」という視点は大事にしてきたと思います。

塚田氏：その視点はとても重要ですね。AWSも、グローバルなクラウドサービスとして、さまざまな企業のセキュリティ強化を支援しています。

サイバーエージェントのように、技術とビジネスの両面からセキュリティを考える企業が増えることで、業界全体のセキュリティ意識もより高まっていくのではないでしょうか。

野渡：そうですね。私たちの取り組みが社内にとどまらず、他の企業にも参考にしてもらえるよう、継続的に改善を重ね、情報発信を続けていきたいと思います。

船ヶ山：今回、AWSの協力のもとNIST CSF 2.0をベースに「Security CREST」を作ったことで、セキュリティに関するグローバル標準を全社に広められたのが大きな成果だと思います。「セキュリティは負担ではなく、技術的な価値を生み出すもの」という考え方が、エンジニアにとって当たり前になるような環境を作りたいですね。

野渡：セキュリティは、「守るための仕組み」ではなく、「より良いシステムを生み出す基盤」となれたらと思います。今後も、エンジニアが主体的に取り組めるセキュリティカルチャーを醸成しながら、より良い環境づくりに貢献していきたいと思います。