SRE × Dynatrace - AI活用による脆弱性対応の効率化 [DeNA インフラ SRE]

はじめに

こんにちは、 IT 本部 IT 基盤部第三グループの渡邊です。IT 基盤部では、組織横断的に様々なサービスのインフラ運用を行っています。

現在、DeNA では AI オールインのスローガンのもと、全社的に AI を活用した生産性の向上に取り組んでいます。¹

そんな中、IT 基盤部では AI によるインフラ運用の効率化を目指し、AI 機能を駆使したオブザーバビリティに強みを持つプラットフォーム Dynatrace の PoC (Proof of Concept) を進めています。

インフラエンジニア / SRE (Site Reliability Engineer) の重要な業務の 1 つに、日々報告される脆弱性の対応があります。この対応は、影響の調査やリスクの評価、関係者との調整など、多くの時間と労力を要する複雑な業務です。

本記事では、PoC で得た知見を元に Dynatrace のセキュリティ機能を活用することで従来の脆弱性対応の課題をどのように解決し効率化できるのかと、その機能の評価結果についてご紹介します。

そもそも Dynatrace とは？

本題に入る前に、まずは Dynatrace について簡単にご紹介します。

Dynatrace を一言で表すなら、「AI を搭載したオールインワンのオブザーバビリティプラットフォーム」です。アプリケーション、インフラ、ユーザー体験、そしてセキュリティに至るまで、システム全体の状態を統合的に監視・分析できます。

Dynatrace の最大の特徴は、一度インストールするだけで対象の環境を自動的に認識し、データの収集を行ってくれるデータ収集エージェント OneAgent と、収集された膨大なデータの依存関係を自動でマッピング・解析し、問題の根本原因を特定してくれる AI エンジン Davis AI にあります。

これらにより、従来はログやメトリクスを長時間かけて分析していたような複雑な問題も、迅速に発見・解決できるようになります。

従来の脆弱性対応について

それでは、まず私たちがどのように脆弱性対応を行っているのか、その対応プロセスと直面している課題について、ステップごとにご説明します。

ステップ 1 : 脆弱性情報の入手と確認

まずは脆弱性情報を入手することから始まります。私たちのチームでは、主に以下の 2 つの経路で脆弱性情報を入手し、内容を確認しています。

内製のパッチ管理システムからの通知: 内製のパッチ管理システムが、稼働中のサーバーやコンテナイメージに含まれるパッケージの脆弱性を検知し、アラートを通知します
セキュリティ部門からの日次通知: 社内のセキュリティ部門から全社向けに毎日展開される、広範な脆弱性情報です

内製のパッチ管理システムの監視対象はサーバーやコンテナにインストールされたパッケージの脆弱性に限られており、アプリケーションで使用中のライブラリの脆弱性には対応されていません。また、別の社内システムとの連携も必要になっているため、一部導入されていないサービスもあります。

一方、セキュリティ部門からの日次通知はアプリケーションのライブラリの脆弱性も通知してくれますが、通知されるのは脆弱性情報だけであり、実際にサービス影響があるかは各々が調査する必要があります。

このステップは、日次の定常業務となっており、約 10 時間/月の工数が必要となっています。

ステップ 2 : 影響の調査とリスクの評価

ステップ 1 で確認した脆弱性の影響を受けるかは、追加の調査が必要です。

私たちが管理するサービスは、技術スタックが多様なだけでなく、チームの関わり方も一様ではありません。立ち上げ当初から運用に携わっているサービスもあれば、他部署から引き継いだサービスもあり、それぞれ開発チームとの連携体制も異なります。

また、私たちはサーバー、OS、ミドルウェアといったインフラ領域を担当しているため、アプリケーションで使用されているライブラリやバージョンをリアルタイムで追従できているわけではありません。そのため、利用している可能性のあるライブラリの脆弱性が報告された際は、開発チームに使用有無を確認したり、場合によっては我々が直接コードを読んで調査します。

影響を調査した後は、リスクを評価して対応の優先順位を決定します。優先順位を決める際、例えば「サーバーが外部からアクセス可能か」といった点は重要な評価基準ですが、現状ではこの確認作業も人力で行っています。

さらに、「脆弱性を含むコードが実際に実行されているか」といった、より詳細なリスクを自動判定する手段もありません。そのため、実際にはそのコードが使われておらずリスクがない場合でも、「脆弱性のあるライブラリが含まれている」という事実だけでリスクを過大評価してしまう可能性があります。

これらの複雑性のため、脆弱性の影響の調査とリスクの評価は時間と労力がかかる作業となっています。

このステップは、約 3 時間/月の工数が必要となっています。

ステップ 3 : 進捗の管理

影響の調査とリスクの評価が完了し、対応していくと判断されたものは、進捗の管理が必要となります。

管理には Google スプレッドシート、Jira、Github Issue を用いており、影響を受けるサーバーの名前、担当者、対応状況などをまとめています。

しかし、日々報告される脆弱性に応じて、シートやチケットを作成・更新する作業はそれ自体に管理コストが必要ですし、他チームへ対応を依頼しているケースでは、管理が煩雑になりがちです。

このステップは、約 1 時間/月の工数が必要となっています。

課題のまとめ

以上を整理すると、従来の対応プロセスには以下の課題があります。

調査プロセスが非効率: 確認や調査が人力であり、時間と労力がかかる
リスク評価が曖昧: 実行時のコンテキストを考慮できず、優先度付けが不正確になりがち
管理が非効率: シートやチケットの作成や更新、他チームの連携など、管理に時間がかかる

そして、調査・評価・管理だけで、約 14 時間/月もの工数が必要となっています。

Dynatrace を活用した脆弱性対応プロセス

それでは、前章で述べた課題を Dynatrace を活用することで、どのように効率化されるのかをご説明します。

Dynatrace による対応プロセスの中心となるのが、OneAgent、Workflow アプリ、Vulnerabilities アプリの 3 つです。

OneAgent には監視対象のレイヤーが異なる「Discovery」、「Infrastructure」、「Full-stack」の 3 つのモードが提供されています。すべての機能、特にアプリケーションレイヤーの脆弱性を検知するには「Full-stack」を選択する必要があります。²

Full-stack モードで導入された OneAgent はサーバー上で実行されているプロセスを監視し、Java、.NET、Node.js、PHP などで利用されるアプリケーションレイヤーのライブラリまでを自動的に検知します。これにより、これまで確認が難しかった領域の脆弱性も、網羅的に把握できるようになります。³

Workflow は、Dynatrace に収集されているデータを元にタスクの自動化を行うためのアプリです。

Vulnerabilities は、収集されているデータを元に検知された脆弱性を管理するためのアプリで、以下の特徴を持っています。

Davis AI によるリスクベースの優先度付け
影響範囲の即時特定と可視化
修正方法のレコメンド

検知された脆弱性は元々の CVE の深刻度 (CVSS) をベースに Davis AI が複数のコンテキストから総合的に分析した上で DSS (Davis Security Score) として再定義されます。

Davis AI は 4 つのリスクを評価します。このうち「Public internet exposure」と「Reachable data assets」が DSS を決定する際に考慮されます。⁴

Public internet exposure: 脆弱性を含んだプロセスが、外部からのアクセス経路に存在するか
Reachable data assets: 脆弱性を含んだプロセスが、データにアクセスできるか
Vulnerable functions: 脆弱性を含むライブラリがロードされているだけでなく、実際にその脆弱な関数が実行されているか
Public exploit: 攻撃コードが公開されているか

このスコアにより、脆弱性が実際の攻撃リスクに晒されているかを客観的かつ自動的に判断でき、真に対応すべき優先度の高い脆弱性を見極めることができます。

それでは、これらの機能を活用した実際の脆弱性対応プロセスを、設定や画面キャプチャとともに詳しく見ていきましょう。

脆弱性の確認

まずは、Dynatrace で検知された脆弱性がどのように表示されるかを見ていきましょう。ここからは Dynatrace から提供されている Playground 環境を使用して、Third-party vulnerabilities、つまりライブラリのようなソフトウェアコンポーネントで検知された脆弱性を例に説明します。

まずトップ画面です。Dynatrace の環境で検知されている脆弱性の一覧が表示されます。個別の脆弱性情報をクリックすると Overview ページが表示されます。

Dynatrace Vulnerabilities Top

Overview ページで注目すべきは Davis AI が評価したコンテキストの結果である Davis assessment と Davis AI の分析結果である Davis Security Score calculation です。

Davis AI はこの脆弱性を含むプロセスを「インターネットに公開されていない」、「データへアクセスしていない」、「悪用コードが公開されていない」と評価し、評価結果から CVSS のスコアよりも低いスコアを DSS として算出していることがわかります。

Dynatrace Vulnerabilities Overview

Details ページでは脆弱性に関する詳細情報が表示されるとともに Fix recommendation に対応方法が表示されます。

Dynatrace Vulnerabilities Details

Affected entities ページでは、影響を受けている Process Group の一覧が表示されます。Process Group は複数のサーバーで同じ機能を実行しているプロセスを自動的に検出し、グループ化されたものです。また、どの Database にアクセスされているのかも同じ画面で確認することができます。

Dynatrace Vulnerabilities Affected entities

Related entities ページでは、Hosts や Kubernetes Clusters といったエンティティが表示されており、クリックすれば影響を受けている対象を一覧で確認することができます。

Dynatrace Vulnerabilities Related entities

最後は Vulnerability evolution ページです。Dynatrace は定期的に脆弱性の評価を実行しており、 Vulnerability evolution ページでは評価の履歴を確認することができます。

Dynatrace Vulnerabilities Evolution

これまでの説明をまとめると、Vulnerabilities を使用することで、脆弱性の概要、リスク、対象、対応方法を瞬時に確認することが可能です。

脆弱性の通知

検知された脆弱性を確実にキャッチアップできるよう、Workflow を利用して通知を設定します。Workflow を設定していくステップは、大きく3つです。

Workflow の実行を開始するトリガーを選択する ⁵
実行アクションを選ぶ
成功時/失敗時のアクションを選ぶ

今回は、

毎朝 10:00 (JST) に
検知された脆弱性を抽出するクエリを実行して
新しい脆弱性が検知されていた場合にメールを送信する

というシンプルな Workflow を作ります。

次の画像は、作成した Workflow の画面です。

Dynatrace Vulnerabilities Workflow

まずは Workflow を実行するためのトリガーを選択します。今回は固定の時間で実行させるので Fixed time trigger を選択します。

次はアクションの選択です。検知された脆弱性を抽出するために Execute DQL Query アクションを選択してクエリを実行します。 DQL (Dynatrace Query Language) とは Dynatrace に蓄積されている膨大なデータを扱うためのクエリ言語です。

次のクエリは実際に設定している「前日に新たに発見された脆弱性」を抽出する DQL になります。

fetch security.events
// 1. 定期的に記録される脆弱性レポートから OPEN された脆弱性に絞る
| filter dt.system.bucket == "default_securityevents_builtin"
| filter event.type == "VULNERABILITY_STATE_REPORT_EVENT"
| filter event.level == "VULNERABILITY"
| filter vulnerability.resolution.status == "OPEN"
| filter vulnerability.mute.status == "NOT_MUTED"
| filter vulnerability.davis_assessment.level != "NONE"
// 2. 昨日に検知された脆弱性に絞る
| fieldsAdd
  first_seen_date = formatTimestamp(vulnerability.first_seen, format:"yyyy-MM-dd"),
  previous_day = formatTimestamp(timestamp - 1d, format: "yyyy-MM-dd"),
  cve = arrayFirst(vulnerability.references.cve)
| filter first_seen_date == previous_day
// 3. 重複を排除する
| dedup {
  cve,
  vulnerability.id,
  vulnerability.url
}
// 4. 通知に必要な情報にサマライズする。例: Davis AI による評価後のリスクレベルやスコア、詳細ページのURLなど
| summarize {
  vulnerability.davis_assessment.level = takeAny(vulnerability.davis_assessment.level),
  vulnerability.davis_assessment.score = takeAny(vulnerability.davis_assessment.score),
  vulnerabilites = collectArray(
    record(
      vulnerability.id,
      vulnerability.technology,
      vulnerability.stack,
      affected_entities.types,
      vulnerability.url
    )
  )
}, by: {vulnerability.display_id, cve}
| sort vulnerability.davis_assessment.score desc

最後にメールを送信するために Execute DQL Query アクションに枝を生やすようにアクションを追加します。メールの送信には Email Connector を使用します。

通知先、Subject、Message の入力項目に必要な情報を入力します。 Workflow ではテンプレートエンジンである Jinja の構文を使用することができます。

例えば先程の DQL の結果を使用するには次のようなテンプレート構文を使用できます。

========================================
# Dynatrace 脆弱性通知
========================================

システムにおいて脆弱性が検知されました。
以下のリストを確認し、各項目の Link より詳細を確認してください。

{% for vs in result("execute_vulnerability_detection")["records"] %}
■ {{ vs.cve }}
----------------------------------------
Display ID : {{ vs["vulnerability.display_id"] }}
Level : {{ vs["vulnerability.davis_assessment.level"] }}
Score : {{ vs["vulnerability.davis_assessment.score"] }}

{% for v in vs.vulnerabilites %}
[詳細情報]
- ID : {{ v["vulnerability.id"] }}
- Technology : {{ v["vulnerability.technology"] }}
- Tech Stack : {{ v["vulnerability.stack"] }}
- Entities : {{ v["affected_entities.types"] | join(', ') }}
- Link : {{ v["vulnerability.url"] }}

{% endfor %}
----------------------------------------
{% endfor %}

入力が完了し、保存したあとは Workflow を Deploy します。

以上の設定で、クエリが毎朝実行され、新たな脆弱性が発見された時にメールが通知されるようになりました。実際に通知されたメールは次のようになります。

Dynatrace Vulnerabilities Mail

脆弱性対応の進捗管理

Vulnerabilities アプリ内でも管理は可能ですが、より可視性を上げたい、サービスごとに整理したいといった場合、Dynatrace の Dashboard アプリを使用することが可能です。

Dashboard では、前述の DQL を使用してデータを取得し、様々な形式でデータを可視化することが可能です。

Security Data を活用した Dashboard を作成するための DQL については、公式ドキュメントで DQL が提供されておりますので、 DQL examples for security data をご覧ください。

評価

Dynatrace での脆弱性対応では「調査プロセスが非効率」、「リスク評価が曖昧」、「進捗管理が非効率」という従来の課題に対しての解決策となりえます。

今回の PoC では、Davis AI が「インターネットへの公開状況」や「データへのアクセス」といったコンテキストを自動で分析し、リスク評価まで完了してくれる点を高く評価しました。この自動化により、担当者は Vulnerabilities 上で脆弱性の概要、影響を受けるエンティティ、対応方法だけを確認すればよくなり、迅速に脆弱性の修正に着手できるようになりました。結果として、従来の人力による調査とリスク評価の作業工数を 約 20 分まで短縮することができました。

しかし、いくつかの課題も見つかりました。

検知のために複雑な DQL を書く必要がある
執筆時点では OS レイヤーの脆弱性が未対応

Dynatrace には Query with AI という自然言語で DQL を生成する生成 AI の機能が提供されています。今回の検知用の複雑なクエリを生成しようとしてみたところ、要件を満たすクエリを生成することができませんでした。また、別の AI を使用しての生成も試みましたが、やはり要件を満たすクエリを生成することができず、結局自力でドキュメントを確認しながらクエリを作るような AI 登場以前と同様の作業が必要でした。

そして執筆時点では OS レイヤーの脆弱性が未対応であるため、従来の脆弱性検知の方法を完全に置き換えることができません。

今回の PoC で対応できたアプリケーションレイヤーの脆弱性対応だけでも工数削減効果は大きいですが、今後 OS レイヤーの脆弱性のサポートも期待しています。OS からアプリケーションまで網羅されることで、従来の脆弱性対応の調査や管理にかかる工数を 95% 削減 (約 14 時間/月 → 約 40 分/月) することができると見込んでいます。

おわりに

本記事では、Dynatrace のセキュリティ機能を活用することで従来の脆弱性対応の課題をどのように解決し効率化できるかの検証とその評価についてご紹介しました。

私たちインフラエンジニア / SRE の責務は、システムの信頼性を維持・向上させることです。脆弱性対応は、その信頼性を脅かすリスクを取り除くための重要な業務ですが、従来の方法では多くの人力による作業が発生していました。

AI を活用して従来の作業や意思決定までの時間を短縮することができれば、より創造的で価値の高い業務に集中できる環境を作ることができるようになると期待しています。

最後までお読みいただき、ありがとうございました。

脚注

DeNA ENGINEERRING BLOG #AI では DeNA のエンジニアによる AI 活用の事例をご紹介しておりますので、ぜひご覧になってください。 ↩︎
OneAgent のモードごとの違いは Infrastructure and Discovery monitoring modes をご覧ください。 ↩︎
OneAgent がサポートしている技術領域と対応バージョンについては Support technologies をご覧ください。 ↩︎
Davis の評価項目についての詳細は Davis Assessment をご覧ください。 ↩︎
トリガーについての詳細は Workflow triggers をご覧ください。 ↩︎