前回は、昨今のランサムウェア攻撃を念頭においた、セキュリティ体制強化に向けた新たなリスク評価アプローチとそれを支える体制について紹介しましたが、あれから半年。今回はリスク評価の一環で取り入れた「ログやイベントデータに基づく実態調査や脅威検知の効率化」をテーマに、セキュリティアーキテクトの日比野と、事業部開発マネージャーと開発ユニットを兼務する座喜味が対談。ログやイベントデータに基づく「ファクト（事実）ベースのアプローチ」について、セキュリティ観点を持つことの難しさや運用に乗せるための難しさを語ります。

じげんのセキュリティ、「評価」から「実装」へ

まずはおふたりの役割について教えてください。

座喜味：じげんの住環境に関わるサービスを展開する事業部にて開発マネージャーをしています。プレイングマネージャー的な立場で、作業管理・実装・レビューを担っています。現在は開発ユニットと兼務という形で、AWS領域のセキュリティ対応にも関わっています。じげんのエンジニアは、基本的には事業部付のメンバーが多いのですが、私のようなマネジメントを担うメンバーは、事業部側と開発ユニットの兼務をすることが少なくありません。最近は、セキュリティ業務比率が上がってきていますが、まだ事業部側の業務がメインという形ですね。

日比野：セキュリティアーキテクトとして、プロダクト環境の技術面における対策推進と、社内に施策を根付かせるためのコンサルテーションを担当しています。
前回の記事でお話したリスク評価の取り組みもその一環です。今回は評価の中で進めてきた「ログ活用」と「CNAPP評価」について、お話できればと思います。

半年前のインタビューでリスク評価の手法をお話いただきました。その後の取り組みを教えてください。

日比野：前回はリスクベースアプローチの考え方と、ベトナムのオフショア拠点VeNturaを活用した評価体制をご紹介しました。当時は評価が終わりかけていたタイミングでしたが、そのリスク評価で採用した具体的な手法を2つご紹介します。
ひとつが「ログを使ったクラウド環境の実態調査」、もうひとつが「CNAPP（Cloud-Native Application Protection Platform）というカテゴリのセキュリティツールの評価」です。本来はリスク評価のためのツールではありませんが、それをリスク評価に活用することでよりリアルな実態を評価することができます。さらにはリスクを評価するだけで終わらせることなく、実際の環境を継続的にウォッチできる仕組みを作ることが、現在の主なテーマですね。

見えていなかったリスクを、ログでつかまえる

ログ活用について教えてください。取り組む前、ログはどのような状態でしたか？

座喜味：私が担当する組織は、2020年にM&Aでじげんグループにジョインした組織です。当初は、作業ログはほとんど取られておらず、障害が起きても原因を特定するのが難しい状態でした。
当時はまず、インフラ移行にあわせてアプリケーションログをクラウドに集約したり、New Relicを入れて可観測性を高めたりというところから積み上げてきました。
ただ、その頃のログの使い方は「障害が起きたときのトラブルシューティング」がメインでした。セキュリティの観点、つまり「正常な状態の中から異常が起きていないことを確認する」という使い方は、なかなか手がつけられていなかったんです。

日比野：これは多くの企業で共通する課題です。サービス監視としてのオブザーバビリティ（可観測性）とセキュリティでは、同じログでも観点が異なります。「誰がいつログインして、どんな操作をしたか、どんな脅威から攻撃を受けているのか」という監査ログの整備は、やりたいけれど意外とできていないです。
セキュリティアーキテクチャの設計が難しく、経験者もいない。優先度が上がらないまま時間が過ぎる——そういう状況がじげんにも確かにありました。

具体的にはどのような調査を行ったのでしょうか。

日比野：それでは、2つの取り組みをご紹介します。

① FTPサーバのアクセス調査
日比野：とあるプロダクトのIISで構築したFTPがフルオープンに近い状態になっていることが分かり、「本当にやられていないか」を確認する必要がありました。ログを調査した結果、海外からの不審なIPアドレスからのアクセスや、FTP・リモートデスクトップなどのポートへの不審なアクセスが発生していないことが確認できました。それをもとにポートの絞り込みや接続元の制限を実施し、具体的な対策につなげることができました。

② CloudFrontアクセスログを使ったS3アクセス調査
座喜味：こちらは私も一緒に取り組んだ内容です。
リスク評価の一環でS3とCloudFrontの連携設定を確認していたところ、一部のファイル群において、意図しないアクセス設定になっている箇所を発見しました。
すぐにアクセス制限の強化を行い、CloudFrontの標準ログを設定してモニタリングを開始しました。その後、ログ上でも該当ファイルへの不正なアクセスには至っていないことを確認できました。

ログは取るだけでは意味がない。じげんが挑む"運用の壁"

ログ活用の難しさはどこにあるのでしょうか。

座喜味：やはり、「運用に乗せ続けること」が一番難しいと思います。ダッシュボードを作って最初はこまめにウォッチしていても、だんだん優先順位が下がっていく——これはよくあるパターンだと思います。大量のログを人間が毎日確認するのは現実的ではないですし、何か起きない限り、運用開始時と同じレベルの緊張感を維持し続けるのは難しいと思います。

日比野：そこで検証・導入を進めているのが「LogEater」です。CloudTrailなどのクラウド環境で取得できる監査ログをAIエージェントが自動で解析し、異常なパターンを検出してレポートする仕組みです。
試験的に導入を進める中で、通常の運用では気づきにくいクラウド環境の潜在的なリスクや、人が普段わざわざ見に行かないような箇所での問題を拾い上げてくれることが確認できました。簡易なプロンプトを書くだけで大量のログからクラウド環境における異常検知ができるのは、セキュリティ運用における非常に大きな価値だと感じています。

座喜味：セキュリティ専門家のログの見方が、改めて勉強になりましたね。アプリケーションエンジニアとしては、障害が起きたときにログを見に行くことがほとんどです。でも、セキュリティの観点では「正常に見えるログの中から異常を見つけ出す」という視点が重要だと知りました。パターンの変化や微妙な兆候への感度がまったく違う。「何が起きていたか」ではなく「何が隠れているか」を見にいきます。一緒に取り組む中で、その視点が少しずつ身についてきた気がします。

もう一本の柱、CNAPPの評価についてはいかがでしたか？

日比野：CNAPPはクラウドネイティブなアプリケーション環境全体のセキュリティリスクを自動で可視化・管理するカテゴリのツールです。マルチクラウド環境において、AWSもGoogle Cloudもまとめてリスクを検出できる点が特徴です。
今回、複数製品の検証を行いました。評価で重視したのは「検出のノイズをいかに減らせるか」「セキュリティの専門家でなくても使いこなせるか」「コストをどう抑えるか」の3点です。この3点が導入後の運用を左右すると感じています。

座喜味：現場の立場から言うと、CNAPPは本当に欲しいです（笑）。
何が優先度の高いリスクなのかの判断が難しくて、都度確認に時間がかかることがある。CNAPPがあれば重要度（Critical/High/Medium/Low）が整理されるので、意思決定のスピードが上がります。特に、リモートコード実行ができるような脆弱性は「これはまずい」と直感的に分かります。
実害が明確なものをCriticalとして自動で上げてくれるだけでも、現場としてはかなり助かります。

日比野：CNAPPは一元管理できることでガバナンスが効くというメリットもあります。対応漏れや新たなリスクの混入を継続的に検知できる。これまで開発ユニットの責任者が各事業部に口頭で状況を確認してまわるような作業が発生していましたが、そういった属人的なプロセスをなくせる可能性があります。
IaaSのネイティブ機能を使うべきか、サードパーティー製品を使うべきかは引き続き検討中ですが、マルチクラウド環境を見渡せるサードパーティー製品の価値は高いと感じています。

リスクを知り、備え、動く──じげんが目指すセキュリティの姿

今後の取り組みについて教えてください。

日比野：来期は大きく2つのテーマで動きます。
ひとつはセキュリティ組織の再構築とガバナンスの強化です。リスク評価で全体像が見えてきた今、次は評価結果に基づいた具体的な対策フェーズへ移行します。組織として自律的にセキュリティを回せる体制を整備していくことが目標です。
もうひとつはインシデント発生時に備えた対策の整備です。万が一の際に影響範囲を最小限に抑えられるよう、レジリエンスの強化など、事業を止めないための備えをプロダクト面でも着実に進めていきます。

座喜味：ログやCNAPPを有効活用するためには、ツールを入れるだけでなく「運用として回る仕組み」を作ることが大事だと思っています。日比野の専門知識をうまく取り込みながら、現場のエンジニアがセキュリティを自分ごととして捉えられる状態を作っていくことが、自分のミッションでもあります。「何かやられてから動く」ではなく「見えているから動ける」チームに、じげんがなっていけるよう取り組んでいきたいです。