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

技術・クリエイティブ

AWSとサイバーエージェントが築く新たなセキュリティ標準

近年、ランサムウェアやDDoSなどの企業の機密性、事業継続性などに影響を及ぼすセキュリティイベントが増加する中で、企業の情報資産を守るための取り組みが重視されています。

当社は、AWSの協力のもと、全社的なセキュリティフレームワーク「Security CREST」を策定しました。クラウドの特性を活かし、セキュリティ基準を統一しながら運用の最適化を進めています。

本記事では「Security CREST」の推進責任者である主席エンジニアの野渡・船ヶ山が、AWS Japanの塚田氏とともに、その設計プロセスやAWSの活用方法、エンジニアが主体的に取り組める仕組みについて語ります。セキュリティを企業文化として根付かせるために、AWSとどのように連携し、どのような戦略を採ったのかを詳しく紹介します。

Profile

  • 船ヶ山 慶 (主席エンジニア / 株式会社WinTicket)
    2010年に入社し、主席エンジニアとして多岐にわたるメディア、ゲーム、エンターテインメント事業のバックエンドおよびインフラを支える。取締役として動画配信サービスを展開する子会社の立ち上げに参画。その後、2022年より子会社タップルのCTOに就任し、事業成長を牽引。2025年からは、子会社WINTICKETにてPlatform Engineeringを担い、技術戦略のさらなる革新に挑む。

  • 野渡 志浩 (主席エンジニア / システムセキュリティ推進グループ マネージャー)
    2011年入社。セキュリティベンダーやSIerにて脆弱性検査サービスの立ち上げやセキュリティコンサルティング業務を担当した後、セキュリティエンジニアとしてEC事業を運営する企業へ。当社入社後は、セキュリティ推進の各部門代表者からなる横断組織「ITセキュリティ戦略室(CyberAgent CSIRT)」の立ち上げや各種プロダクトのセキュリティ強化支援、インシデントハンドリングを担う。

  • 塚田 朗弘 氏 (アマゾン ウェブ サービス ジャパン合同会社 デジタルサービス技術本部 本部長)
    2015年8月よりアマゾン ウェブ サービス ジャパン合同会社のソリューションアーキテクト(SA)。現在は日本のデジタルネイティブなサービスや、ソフトウェア・SaaS ビジネスを展開するお客様を支援する SA チームをリードしている。AWS 以前は、金融系 SE、生放送系ウェブサービスのサーバーサイドエンジニアを経験した後、2013年よりスタートアップ企業に Join。CTO としてモバイルアプリ、サーバサイド、AWS上のインフラ管理を担当しつつ、採用やチームマネジメントを行った。

この15年で、セキュリティはすべてのエンジニアが意識すべき課題に変わった

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

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

こういった背景の中、サイバーエージェントが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」制度を通じて、全社的なセキュリティフレームワークを確立しながら、各チームの自律性も保つ仕組みを実践されていますね。

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

そこで、組織全体のセキュリティ施策として策定したのが「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日に公開したセキュリティ対策を検討・推進するためのサイバーセキュリティのフレームワーク。

NIST CSF 2.0 の理解を前提にした「Security CREST」
NIST CSF 2.0 の理解を前提にした「Security CREST」

塚田氏:当社も草案の段階から「Security CREST」で使用する「NIST CSF 2.0 Custom」の作成に協力させていただきました。「Security CREST」を設計する上で、一番大切にしたポイントは何でしょうか?

船ヶ山:「Security CREST」が目指したのは、エンジニアがセキュリティ対策を楽しみながら取り組めるカルチャーの形成です。最大のポイントは、「ミスを減点するのではなく、良い取り組みを加点する仕組み」を採用したことです。

一般的に、セキュリティ対策は「できていて当然。ミスをすれば減点されるもの」と捉えられがちです。結果として、「やらなければならないもの」という義務感しか生まれず、エンジニアの主体的な行動につながりません。

そこで、「Security CREST」では、「基準を満たせばプラス評価を得られる仕組み」 を明確に打ち出しました。例えば、セキュリティレビューの実施やログの可視化の強化によって、開発チームが評価される仕組みを導入しています。

特に制度設計では、開発メンバーの意見を積極的に取り入れ、現場で機能しないルールは極力見直しました。その結果、「これは確かに必要だ」「この基準なら納得できる」という共通認識が生まれ、「現場の負担にならず、納得感のある仕組み」を構築できたと感じています。

さらに、この取り組みは「一度作って終わり」ではなく、毎年アップデートする前提で運用しています。最初から完璧な形を目指すのではなく、セキュリティエンジニアと協力しながら必要な要素を見極め、翌年の状況に応じて新たな項目を追加しながら進めています。

こうすることで、過度な負担を抑えつつ、常に最新のリスク環境に適応するフレームワークを維持できます。

ルールを定めるだけでなく、エンジニアが納得し、主体的に実践できる仕組み

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

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

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

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

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

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

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

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

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

NIST CSF 2.0ではTier4が最も高い成熟度だが、エンジニアがイメージしやすいように Tier 1 を最も高い成熟度と定義した
NIST CSF 2.0ではTier4が最も高い成熟度だが、エンジニアがイメージしやすいように Tier 1 を最も高い成熟度と定義した

セキュリティカルチャーの醸成が企業の競争力になる

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

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

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

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

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

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

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

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

セキュリティは負担ではなく、企業価値を生み出すもの

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

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

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

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

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

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

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

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

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

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

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

サイバーエージェントグループ システムセキュリティ推進グループ の求人一覧

この記事をシェア

オフィシャルブログを見る

記事ランキング

ABEMAの期待値を上げていくーーコミュニケーションデザイン室が描く未来

技術・クリエイティブ

新しい未来のテレビ「ABEMA」は、ドラマや恋愛リアリティーショー、ニュースなど様々なオリジナルコンテンツを制作・放送しています。そのコンテンツを広げるためのブランドプロモーションを担うのがコミュニケーションデザイン室です。責任者・佐藤洋介と廣川拓郎の2名に、仕事内容や今後の展望について話を聞きました。

Page Top