寄稿：株式会社ドワンゴによる「AWS で実現するニコニコの大規模セキュリティ改革の概観」

本稿は、株式会社ドワンゴ（以下、ドワンゴ）におけるクラウド環境のセキュリティ改革をリードされた青木 良樹様/結城 清太郎様/坂井 薫平様に寄稿いただきました。

はじめに

株式会社ドワンゴ は（以下、ドワンゴ）、デジタルテクノロジーによって新たな価値を生み出し続けるエンターテインメント企業です。当社の事業の中でもニコニコ事業は国内有数の動画・生放送配信プラットフォームとして多くのユーザーおよびクリエイターの皆様に愛され、ご利用いただいています。本稿はそんなニコニコ事業における従来のセキュリティ対策に加え、2024年6月初旬に発生したサイバー攻撃を契機に取り組んだセキュリティ改革の概観を紹介するものです。

改革の経緯

ニコニコ事業はインフラストラクチャの大改革として従来のオンプレミスから AWS への全面移行を推し進めてきており、その過程の一部を過去の AWS Summit でも発表してきました。AWS への全面移行には「開発・運用効率の向上」「多種多様な技術的選択肢の獲得」といった目的がありつつも、これまでのオンプレミスを前提としたインフラストラクチャ技術とは異なる観点での技術的な投資が必要になります。とりわけセキュリティ分野については2022年の移行開始当初より優先度の高い技術領域として、積極的な取り組みを進めてきました。その甲斐もあって、2024年6月初旬に発生したサイバー攻撃では、AWS 環境への攻撃者による侵害行為を未然に防ぐことができたものと考えています。サイバー攻撃以前より推し進めてきた取り組みについて、具体例をいくつか紹介します。

・社内標準となる「セキュリティガイドライン」の策定・展開
・AWS Trusted Advisor や AWS Security Hub を用いた「予防」的な攻撃対策の導入
・重要度の高いサービスにおける Amazon GuardDuty を用いたインシデント管理フローの策定・運用
・AWS CloudTrail による AWS Organizations 内のユーザーアクティビティの監視

「セキュリティガイドライン」についてはサービスにおけるセキュリティ対策の社内標準として現在も活用されています。これらの取り組みの一部は AWS Summit Tokyo 2023 での当社 七田によるセッションでも触れられているため、興味のある方は参照いただければと思います。

事前の対策が奏功したと考えられる一方、サイバー攻撃はニコニコの AWS 全面移行の道半ばで起こった出来事です。ニコニコを復旧するにはオンプレミスで稼働していたシステムを AWS 上で再構築する必要があることに鑑みれば、AWS 環境の重要度がこれまで以上に増していくことは明らかです。私たちはこれを契機に AWS 環境における大規模なセキュリティ改革に取り組むこととしました。

採用ソリューションと構成

サイバー攻撃の発生時、私たちは直ちにオンプレミスと AWS の間のネットワークを切断し、一部のメンバーを除くすべての開発者によるサインインを無効化すると共に、当時の AWS 環境において侵害行為と思しき挙動が見られないことを確かめるべく、AWS 環境の総点検を実施しました。総点検の結果、幸いにして AWS 環境に攻撃者の侵害が及んでいないと判断することができました。総点検によって安全性を確認した後も予断は許さない状況です。先述の通りニコニコの AWS 全面移行は道半ばであり、ニコニコを復旧するには AWS への移行が完了していない全てのシステムについて、それらを AWS 環境上で再構築する必要があることが早い段階で明らかになっていました。これは言い換えると「従来以上に AWS 環境のセキュリティが事業に与える影響が増すこと」を意味します。また、一度安全性を確認した後も私たちを取り巻く環境は常に変化していくことから、継続的にセキュリティ対策を維持・向上させていく必要があると考えました。

そこで、社内の AWS チーム・セキュリティチームに加え、アマゾン ウェブ サービス ジャパン合同会社（以下、AWS ジャパン）のアカウントチーム・スペシャリストチームが一丸となって、AWS 環境のセキュリティレベルの向上に取り組むこととなりました。セキュリティレベル向上に取り組んだ結果として作り上げられたのが次に示すセキュリティプラットフォームです。従前のセキュリティ対策を拡張する形で実現されたものになります。

前提としてニコニコでは、AWS Control Tower と AWS Organizations を軸に据えたマルチアカウント・アーキテクチャを採用しています。マルチアカウント・アーキテクチャについては AWS Well-Architected フレームワークの考え方 に則り、システム・環境の組み合わせによって AWS アカウントを作成・管理するようにしています。

各 AWS アカウント上で採用される AWS サービス・技術スタックはニコニコの各システムを担当するチームの裁量に委ねられていますが、AWS 環境のセキュリティレベルを包括的に高めようとする場合、すべての AWS アカウントに対する統一的なセキュリティベースラインを敷くことが重要です。ニコニコではセキュリティ対策の基本思想として「予防 (Prevention)」と「検知 (Detection)」の二点に着目し、設計を推し進めました。

予防（Prevention）

「予防」のフェーズではニコニコをサイバー攻撃から守るために重要な役割を果たすソリューションを採用します。図中にもある通り、AWS Security Hub や AWS Trusted Advisor のような AWS におけるセキュリティ・ベストプラクティスに違反する項目を検査する AWS サービスを積極的に採用、すべての AWS アカウントの違反項目を精査し、セキュリティベースラインの底上げを図りました。これらのサービスはサイバー攻撃以前より導入しておりましたが、このタイミングで違反項目への対策をより一層強化しました。また、AWS Organizations の機能である Service Control Policy を導入することによって、各チームのアジリティは維持しつつ、 各 AWS アカウントにおける不必要かつセキュリティホールとなりがちな操作を一元的に制限しています。この方法によって、文字通りの越えてはならないガードレールのような境界を引きつつ、そのルールを逸脱しなければ、その内側での自由な往来を認めるような形での運用を取り、制限と運用効率に関するバランスを取ることができています。ここで触れられているのはあくまで一例ですが、サイバー攻撃による被害を未然に防ぐにはこうした従前の対策が最も重要であると考えられます。

検知（Detection）

しかし、いかなる対策も完全とは言えません。サイバー攻撃の手法は日夜研究されており、常に新しい手法が生まれ、世の様々なシステムに対してその手法が試行されています。いつの日にか攻撃者が、私たちの講じた多層防御を突破する可能性を完全に否定できるわけではありません。そこで、実際に攻撃が発生した場合にそれを速やかに「検知」し、その攻撃を封じ込める必要が生じます。このフェーズでは GuardDuty を用いた脅威の検知を基本線に置きつつ、CloudTrail によるすべての AWS アカウントのユーザーアクティビティの監視を通じ、不審な行動を即座に検知可能な仕組みを設計しています。何らかの不審な行動が見られた際には即座に社内外の連携先に通知が届き、速やかにインシデントの分析にあたることができるようなフローを設計しています。

インシデントを検知した際の分析・対処の流れについて

ここまで説明してきたセキュリティの基本設計を前提に、実際にインシデントが発生した際の対応にまつわる部分について説明します。

先述の通り、検知した不審な行動は複数の連絡手段に対して通知され、インシデントの分析が開始されます。インシデントの分析の結果、それが攻撃であると判断されれば、被害の拡大を防ぐために速やかに対処します。しかしながら、このような運用は常に新しい脅威へのキャッチアップを続け、更には24時間体制での迅速かつ高い精度での対処が求められるものです。こうした対処の品質にまつわる課題について、外部のセキュリティ事業者の協力による強化を図ることで、効率的かつ合理的な体制の構築を目指しました。メインのトラブルシューターは自社のエンジニアが担いつつも、外部のセキュリティ専門家による支援が受けられる体制を整備しました。

また AWS re:Invent 2024 では、検知の機能に加え、実際のインシデント分析を強化可能な AWS サービスとして、AWS Security Incident Response が発表されました。早速ニコニコではこのサービスの導入を進めています。このサービスを導入することで、単なる脅威の「検知」機能に留まらず、発生したセキュリティ検出結果のトリアージと調査を自動化し、AWS のセキュリティエンジニアと24時間連携できるなど、セキュリティインシデントの復旧に向けてサポートを受けることができます。AWS ・セキュリティの両分野における専門家が、実際に AWS アカウント上のリソースレベルで一緒に分析にあたってくれるなど、ニコニコのような24時間体制で事業を展開する企業にとって非常に心強いサービスになっています。

導入の効果と所感

ここまでの説明から、サイバー攻撃に端を発する一連の流れの中で、従前の対策に加えて多くの AWS サービスを採用し、セキュリティ改革に取り組んできたことがご理解いただけたかと思います。セキュリティレベルの向上を目的に AWS サービスの採用を決めること自体は決して難しいことではありません。しかしそれに留まらず、採用を決めたサービスを中心としたアーキテクチャや運用フロー、更にはそのサービスの利用に伴い発生する費用などの要素についても考えを及ぼさねばなりません。

AWS のセキュリティ系サービスには、そのサービスの ON / OFF に加え、サービス内の機能を細かく制御できるオプションが豊富に用意されています。 GuardDuty を例にとると、同サービス内には「S3 プロテクション」「ランタイムモニタリング」のように複数の保護プランが用意されており、保護する対象を細かに制御することが可能です。このような機能レベルの柔軟性によって「いま自分たちにできること・必要なこと」に着目し、現実的な費用感でセキュリティレベルの向上を図ることができたのではないかと考えています。また、実際の導入に向けたアーキテクチャの設計では、最初に基礎となる運用フローを定義した後、メインの AWS サービスだけでなく Amazon Simple Notification Service などの接着剤となる AWS サービスを積極的に活用するよう努めました。これによって開発工数を削減でき、導入に至るまでのスピードを大幅に加速できたと感じています。導入時にはいくつもの工夫を凝らして構築を進めたため、それらのエピソードについてもいつか別の機会にお話できればと思います。

セキュリティレベルの向上という観点では、実際に攻撃と思しき挙動を未然に防ぐことができているのはもちろんのこと、ニコニコのセキュリティ対策の有効性を外部のセキュリティ事業者を交えて客観的に評価いただいています。加えて AWS Security Incident Response や GuardDuty といった AWS サービスによる不審な行動の検知については、現実的に起こり得る攻撃シナリオを想定した場合に有効なセキュリティ対策としてその価値を発揮してくれていると感じています。

むすび

幸いにしてニコニコの AWS 環境には、2024年6月初旬に発生したサイバー攻撃による侵害が及ぶことはありませんでした。しかし、AWS だからといって何もせずとも完全無欠なセキュリティ対策が実現可能なわけではありません。AWS の 責任共有モデル にもある通り、顧客が責任を負わねばならない領域については、顧客自身の手によってセキュリティ対策を講じる必要があります。AWS には、私たち自らがセキュリティ対策を講じる際に役立てることができる豊富なサービスがあり、また、その導入を手助けしてくれる強力なアカウントチームが存在します。紹介した事例は AWS を利用する立場にあるニコニコがセキュリティ改革に取り組んだものですが、この改革は AWS の豊富なサービス・アカウントチームによる協力なしには実現できなかったと考えられます。本稿をお読みいただいている皆様も、自身の担当するシステムのセキュリティ対策を考える際には AWS ジャパン に相談することを強くおすすめします。

KADOKAWA グループではグループを横断的にサポートするエンジニアリングチームが中心となって、今回紹介した事例を基にした包括的なセキュリティ対策を進めています。しかし、先述のようにセキュリティ分野における攻撃手法の多様性は増す一方です。ニコニコを含む KADOKAWA グループはここで歩みを止めることなく、今後も自社の展開するサービスのセキュリティレベル向上に持続的に取り組んでいきます。今後ともニコニコならびに KADOKAWA グループの提供するサービスをご愛顧いただけますと幸いです。

著者

青木 良樹
株式会社ドワンゴ　技術本部　クラウドエンジニアリング部　部長

結城 清太郎
株式会社ドワンゴ　グループ基盤サービス本部　クラウドサービス部　部長

坂井 薫平
株式会社ドワンゴ　技術本部　本部長