クラウド全面移行目前、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）

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