クラウド全面移行目前、DeNAが324のセキュリティ監査項目を8割減できた理由：特集：withコロナ時代のクラウドセキュリティ最前線（3）

DeNAは各種サービスのインフラ基盤のクラウド移行を進めており、クラウドセキュリティの対策が重要になってきていた。オンプレミス時代から実施している社内のセキュリティ監査の取り組みを、クラウドに適用した方法と、そこで見えてきた課題などが明かされた。

[谷崎朋子，＠IT]

クラウド移行で明らかになった既存のセキュリティ監査の限界

　モバイルゲームからEコマース、スポーツ、ヘルスケアまで多角的に事業を展開するディー・エヌ・エー（以下、DeNA）。その同社が2018年度から3カ年計画で取り組むのが、オンプレミス環境で運用する社内外サービスのパブリッククラウド全面移行だ。3年目となる2020年現在、約60の部門がクラウドを活用。Amazon Web Services（AWS）で250アカウント以上、Google Cloud Platform（GCP）で600プロジェクト以上が稼働しており、今も毎月10個のペースでアカウントやプロジェクトは増えているという。

　だが、移行が加速する中で、同社セキュリティ部はある重大な問題に直面した。それは、既存のセキュリティ監査方法が新しい環境にマッチしていないという課題だ。「ITmedia Security Week 2020冬」の講演「AWS/GCPのセキュリティ監査自動化の取り組みと課題」で、DeNAのセキュリティ部 セキュリティ推進グループの伊藤大地氏は既存のセキュリティ監査とその課題、改善と現状について詳しく語った。

ディー・エヌ・エー セキュリティ部 セキュリティ推進グループ 伊藤大地氏

　これまで同社のセキュリティ監査では、経済産業省の「サイバーセキュリティ経営ガイドライン」やNIST（米国国立標準技術研究所）の「サイバーセキュリティフレームワーク」を参考に作成したセキュリティポリシー「Group Information Security Policy」にのっとり、監査を実施していた。流れとしては、まずサービス担当者などから事前にシステム構成などの情報を入手し、併せてヒアリングシートへの回答を依頼。その後、対面で内容を深掘りしながら、事前情報と実態に乖離（かいり）がある場合は想定されるリスクや影響を洗い出し、対策案を案内。対応が完了するまでをサポートしていた。

セキュリティ監査の進め方（出典：DeNA）

　しかし、ヒアリングシートの内容はあくまでもオンプレミス環境が前提だ。クラウドに移行したことで、アカウント管理の対象がOSやデータベースだけではなく、「AWS Identity and Access Management」（IAM）も対象になった。また権限管理も、IAMのロールやポリシーなども設定する必要があり、クラウドサービス自体も「Amazon S3」「Amazon RDS」「Google BigQuery」「Google Cloud SQL」など多様化。「セキュリティ対策も、例えばAWSのファイアウォール設定ではセキュリティグループやVPCなど新しい機能や概念に対応する必要がある。これまでの監査内容では、実態を網羅的かつ詳細に把握できないことが判明した」（伊藤氏）

　また、クラウドサービスを利用する側のセキュリティ知識の差も問題だった。サービスを開発、運用する部署はデザイン部や人事部など幅広く、必ずしもセキュリティに詳しい人が担当しているとは限らない。つまり、セキュリティ上問題のある設定で運用される可能性があるということだ。だが、セキュリティ部が個別に対応するにはあまりに効率が悪い。

クラウド向けガイドラインを策定

　そこで伊藤氏たちは、AWSとGCPそれぞれのセキュリティガイドライン策定に着手した。目標は、ガイドラインに沿って設定すれば社内ポリシーに準拠できるというものだ。

　「例えばアカウント設定の場合、既存のセキュリティポリシーでは『必要な者にのみアカウントを付与する』『異動および退職などによって不要になった場合、速やかに無効化する』といったように、抽象的な表現で書かれていたが、クラウド版では『異動退職時にIAMユーザーの削除を実施する』『利用が完了し使われていないアクセスキーは無効化・削除する』など、具体的な内容を心掛けた」（伊藤氏）

　最終的に、AWSは82項目、GCPは79項目に整理されたガイドラインが完成。既存のヒアリングシート（163項目）と足し合わせて、クラウドも網羅する新ヒアリングシートが出来上がった。

セキュリティ監査のクラウドへの対応（出典：DeNA）

　だが、合計324項目のヒアリングシートに回答するのはさすがにつらい。分かりやすく設定方法を説明していたとしても、知識や経験に差のあるユーザーが正確に準拠するのは難しい。量の問題は、監査側の負担にも影響した。

　「特にクラウドの設定ミスは深刻なインシデントに直結しやすい。例えば、ルートのアクセスキーは有効にしない、退職者が出たときはアクセスキーの情報をローテーションするといった要件が守られなかった場合、社外からのアクセスリスクが生まれ、侵害が発生する可能性もある。ユーザー側の負担を軽減し、監査工数を削減、危険な設定はすぐに見つけて対応するには、セキュリティ監査の自動化は必然だった」（伊藤氏）

　ポイントは、自動化すべきところと人間の確認が必要なところとをうまく切り分けて、対応を効率化することだ。

　「例えば、使われないアクセスキーが残っているかどうか、SSHの接続元が制限されているかどうかはクラウド情報として自動取得し、自動判定に任せられる。一方で、内部用S3バケットの公開リストを作成するまでは自動化できても、それが公開してもよいものなのか、そうでないのかは担当者の確認が必要だ」（伊藤氏）

　そこで、自動判定でNGが検出された場合はアカウント管理者にメールで通知し、修正を依頼する仕組みを作った。このとき、対応プロセスは大まかに2つに分岐する。1つ目は、通知を受けて修正、監査を再実行して修正を確認するプロセス。2つ目は、修正不要のため対応をスキップするプロセス。これは、例えば公開しても問題のないS3バケットについての対応などが該当する。対応不要であれば、その理由を明記してセキュリティ部に戻し、通知をストップする。

クラウド自動監査システムの概要（出典：DeNA）

クラウド自動監査システムを内製した理由と、その構成

　同システムの開発は内製した。当初は「AWS Config」を活用する案もあったが、アカウント別のビューと集約ビューがあり、アカウント管理者が対応した状況をセキュリティ部が集約ビューから確認できる点が評価された。しかし、NG通知のスキップ機能を実装するのが難しく、（2018年当時は）年額500万円以上というコストから見送ることにした。また、サードパーティー製のツールを使うことも検討したが、調査した範囲の製品には集約ビューしかなく、豊富な管理機能があるもののその分のライセンス費用が高額で、監査目的で採用するにはバランスが悪いと判断したという。

　「内製であればNG通知のスキップ機能を作り込める他、『Amazon EC2』で動かせば年額10万円程度にコストも抑えられる。特に機能面において、社内のセキュリティポリシーの改訂やクラウドサービスの新機能追加に対して柔軟に監査を対応させていくには、内製するのがベストと考えた」（伊藤氏）

　こうして出来上がったのが、EC2を中心としたクラウド自動監査システムだ。大まかには、EC2とアカウント情報管理サーバとでアカウント情報を同期し、AWSアカウントやGCPプロジェクトに対して監査するというもの。GCPプロジェクトについては、監査対象のプロジェクトでアカウントを発行し、EC2上に置いてアクセスできるようにした。

クラウド自動監査システムの構成（出典：DeNA）

　自動監査で検出できるルール、要件は、「AWS CloudTrail」の設定状況、IAM関連（パスワードポリシーの設定状況、多要素認証の設定の有無、IP制限の設定がされていないユーザーの有無）など、多岐にわたる。

クラウド自動監査で検出できる要件（一例）（出典：DeNA）

　この自動監査で判定がNGになった場合は、「Amazon Simple Email Service」（SES）経由でアカウントを管理するエイリアス宛てにメール通知。メールには、どんなリソースで何件問題が発生しているかを記載。確認したアカウント管理者はWeb UIにログインし、問題のある箇所を確認し、適宜対応するという流れだ。

クラウド自動監査システムのWeb UI（出典：DeNA）

自動監査システムで大幅な効率化を実現

　自動監査システムの効果は絶大だった。AWSでは82項目中51項目が、GCPは79項目中20項目が自動化された結果、担当者とのヒアリングで確認する項目が大幅に削減された。

　とはいえ、324項目が253項目になっただけで、依然として量は多い。さらなる効率化を目指して、伊藤氏たちはガイドラインを精査。結果、冗長的な質問項目が多いことに気付いた。例えばアカウント関連の質問は、OS、データベース、IAMでそれぞれパスワード強度やアカウント発行の承認および記録などを聞いていたが、大項目をパスワード強度にした上でOSやIAMなどの対応状況を確認する方式に変更。また、教育周知が適切な要件も除外した。

　「ヒアリングシートの記入は通常、サービス運用開発チームの1人が代表で行うが、50人のチームのうち1人に情報の取り扱いについて質問して、その人がルールを守っていたとしても、その他49人が同様に守っているとは限らない。これは教育を通じて、一人一人にアプローチする方が適切と考えた」（伊藤氏）

　努力の結果、ヒアリング項目は59項目まで削減された。

セキュリティ監査のヒアリング項目数の変化（出典：DeNA）

　現在は、日次で監査プログラムを走らせ、問題が検出されればすぐに担当者に通知し、対応を促せるようになったという。年次や3年に一度のセキュリティ監査では変化の激しいクラウド事情に対応し切れなかったところを、日次でカバーできることで、セキュリティレベルの向上に大きく寄与する形となった。

残された人的対応関連の課題

　それでも、課題は幾つか残った。例えば、「メール通知時の対応のムラ」だ。運用歴の長くて多数のサービスを利用しているアカウントの場合、100個単位のNGが検出されてしまう。それが日次で届いたら、通知を無視したくなるのも当然だ。

　「問題は、通知をスキップするとき、セキュリティ上妥当な理由が書かれていないこと。『S3バケットが公開されている』という通知で、『これは画像配信で利用しているから意図して公開している』とった“理由”を書いてくれれば問題ないが、『重要じゃないからスキップします』『後でやるからスキップします』など、判断の根拠が書かれていない場合は個別に確認が必要となり煩雑だ。往々にして緊急度の高いNGが対応されずに残るのも問題だ」（伊藤氏）

　そこで現在、自動監査プログラム側で緊急度の高いものをフィルター表示できるよう改修しているという。さらに、「文面を工夫して対応してもらいやすくする」「それでも対応しない人にはSlackのDMで促す」「対応スキップ理由に妥当な理由が書かれていないときはコミュニケーションをとる」などの策を進めている。

クラウド自動監査の対応フロー（対策案）（出典：DeNA）

　この他、3カ月に1回は各マネジャー陣に対応状況を共有し、セキュリティ監査のタイミングでNGがあれば対応を依頼したり、セキュリティポリシーを改訂して自動監査システムの存在と必要な対応を明記したりするなど運用の補強策も検討中だ。

　DeNAのクラウド全面移行の完了は目前。さらなるセキュリティ対策の強化に向けて、伊藤氏たちは今も理想を求めて日々取り組んでいる。

特集：withコロナ時代のクラウドセキュリティ最前線

withコロナ時代の今、テレワークの普及によりクラウドサービスの利用が広まっているが、CASB（Cloud Access Security Broker）では防げない新たな脆弱（ぜいじゃく）性が生まれているのをご存じだろうか。脆弱性というと、プログラムやフレームワーク／ライブラリのバグの話と思いがちだが、アカウントやデータ、API、ログの公開範囲、暗号化など、ユーザーが行う“設定”のミスに起因する脆弱性が増えているのだ。またクラウドサービスは、コマンドや管理画面が共通となるため、攻撃者も設定項目を理解している。悪意のある“設定の変更”が行われていないかどうかの確認も重要だ。このようなクラウドサービスのリスクを軽減するために、CSPM（Cloud Security Posture Management）が注目され始めている。本特集では、現在のクラウドリスクを解き明かし、CSPMを中心に、その打開策を紹介する。

特集：withコロナ時代のクラウドセキュリティ最前線