はじめに：出口戦略としてのクライアントサイド監視
私が普段から開発に携わっている、SaaS型ECプラットフォームの運用において、セキュリティは最優先事項の一つです。
特に、クライアントサイドで発生する外部通信は、XSS攻撃などによる情報詐取のリスクを内包しており、その監視体制の強化は常に求められます。
私たちは多層防御を前提に、WAF・Zabbix等によるインフラ／入口対策に加え、npmパッケージの導入フローを厳格化し、CI/CDでの日次npm auditにより脆弱性を継続観測しています。
それでもなお、依存ライブラリ内部から“意図しない外部通信”が発火するリスクはゼロにはできません。だからこそ「出口（ブラウザ発の外部通信）」の振る舞いを常時監視し、被害の実害化を抑え込む対策も併せて行う必要があります。
本記事では、大掛かりな専用ツールを導入する前に、私たちが活用しているNew Relicをハブとし、AWSサーバーレスを組み合わせた最小構成で構築する、「出口を監視する」仕組みについて、その経験と技術的な知見を共有します。
大掛かりな専用ツールを導入する前に、今あるツールで目の前の脅威に対して何ができるのかを探求した一つの実践例です。
当社は一次被害を一切受けていませんが、2025年9月、多数の開発者が日常的に使うdebugやchalkを含む人気npmパッケージ群が改ざんされ、悪性コードが公開される事件が発生しました。
攻撃者はソーシャルエンジニアリングでメンテナのアカウントを奪取し、複数バージョンにマルウェアを挿入した、と明らかになっています。
参考：
Aikido Security:npm debug and chalk packages compromised
Vercel:Critical npm supply chain attack response - September 8, 2025
特に悪質だったのは、ブラウザのfetchやXMLHttpRequestといったコアAPIをフックして送受信内容を書き換える挙動です。これにより、ユーザーが気づかないまま外部通信の行き先やペイロードが改ざんされうる状況が生まれました。
汚染された依存が組み込まれると、配布単位（ビルド／リリースの粒度）に応じて多数のテナントへ短時間で影響が波及し得ます。
共通コンポーネントが多く用いられている、SaaS型ECプラットフォーム事業者にとってこの手口は致命的となり得ます。
この事件は他人事ではありません。
入口をどれだけ固めても、クライアント側の挙動が乗っ取られれば外部通信はすり抜ける。プロアクティブな出口監視の必要性を象徴したこの事例を、私たちは教訓とするべきです。
本記事の対象読者
- Webアプリケーションのセキュリティ対策を検討しているエンジニア
- New Relicの応用的な活用法に興味がある方
- New Relic × AWSサーバーレスアーキテクチャの実践例を知りたい方
1. 出口監視の設計指針（可視性・評価・協働）
前提
繰り返しになりますが、当社は多層防御（WAF・Zabbix等によるインフラ／入口対策、npmパッケージの導入フローを厳格化、CI/CDでの日次 npm audit など）を実施しています。
それでも、依存ライブラリやサードパーティスクリプトの内部から「意図しない外部通信（ブラウザ発）」が発火する可能性は残ります。 出口監視は、侵入をゼロにできない前提で実害を抑え込む第二線として機能します。
それを踏まえ、今回のPoCでは既存の対策では効率的な対応が難しかった、以下の3つの課題を解決することを目的としました。
-
課題1: クライアントサイドの可視性の強化
WAFなどがサーバーへの入口を固める一方で、ユーザーのブラウザ上で実行されるスクリプトからの出口（外部への通信）を網羅的に監視するには、異なるアプローチが必要でした。この部分の可視性を強化し、リアルタイムで追跡する仕組みを求めていました -
課題2: 評価プロセスの効率化と基準の統一
たとえ不審なドメインを検知したとしても、その後のレピュテーション（評判）調査やリスク判断は、専門知識を持つエンジニアによる手動での対応に依存していました。この初動調査（トリアージ）を自動化し、迅速かつ一貫した基準で評価する必要がありました -
課題3: 調査結果の集約とコラボレーションの促進
調査結果や対応履歴が、各種ツールや担当者ごとに分散しがちでした。検知から評価、そして最終的な判断までの全プロセスをSlackという共通の場所に集約し、プロダクトに関わるエンジニアがスムーズに連携できる協調的なワークフローを目指しました
本PoCは"宛先と振る舞い"の異常検知が目的で、ペイロード内容の改ざん検知は対象外です。
2. システムの全体像とアーキテクチャ
今回の課題への対応案として構築したPoCシステムの全体像です。
このPoCは New Relicを監視ハブに据え、検知→評価→通知をサーバーレスで非同期処理する構成です。
処理の流れ
- Scripted API（New Relic）がNRQLを実行し、所定間隔でドメイン評価リストにある悪意あるドメインへの外部通信を抽出し、結果をAPI Gatewayへ送信します
- Lambda(A) が受信データをSQS FIFOへ投入します(外部APIのレート制限順守のため)
- Lambda(B) がキューから一定間隔で取り出し、マルチベンダー型のドメイン評価サービスのAPIでレピュテーションを評価、結果をS3に保存したうえでLookup Tableを更新します（ドメイン評価リストの更新）
- 更新後はSlack通知で「放置／要確認／即時対応」を提示し、必要に応じて人手で判断し、判断に応じた更新処理を行います
- ドメイン評価リストは EventBridge でLambda(C)を定期実行し再評価され、自己学習的に洗練されます
技術スタックの役割分担
-
検知・トリガー
New Relic (Scripted API, NRQL, Lookup Table) -
評価・処理・保管
AWS (API Gateway, Lambda, SQS FIFO, EventBridge, S3) -
脅威インテリジェンス
マルチベンダー型のドメイン評価サービス -
通知・手動介入
Slack (Block Kit)
3. 実装の勘所①：検知の起点となるNRQL
観測・処理の起点となるのは、New Relicで10分間隔で実行されるこのNRQLクエリです。
New Relic Browser（SPA/RUM）のAjaxRequestイベントを利用します。
capture関数でURLを正規表現でパースし、lookup関数で動的なドメイン評価リストと照合するのがポイントです。
harmlessは無害と評価されたドメインを表すフラグです。
-- ドメイン評価リストにある悪意ある・または未知のドメインへの外部リクエストを検知するNRQL
FROM AjaxRequest
WITH capture(pageUrl, r'https://(?P<baseUrl>[^/]+)(/.*)?') AS (baseUrl)
SELECT hostname, pageUrl
WHERE baseUrl != hostname
AND hostname NOT IN (FROM lookup(external_host_evaluation_list) SELECT domain WHERE evaluation = 'harmless')
SINCE 15 minutes AGO
LIMIT MAX
トリガーにEventBridgeではなくScripted APIを選んだ理由
AWS EventBridgeでLambdaを定期実行する方法も考えられますが、今回はNew RelicのScripted APIを起点としました。これにより、「何を(NRQL)」と「いつ(スケジュール)」という監視の根幹をなす要素をNew Relicプラットフォーム内で完結させることができ、監視ロジックの管理性と保守性の向上を目指しました。
4. 実装の勘所②：APIレート制限を考慮した堅牢なサーバーレス設計
利用するマルチベンダー型のドメイン評価サービスには、Public APIのレート制限（例: 1分間あたり数リクエスト）が仕様として定義されていることが一般的です。
今回のPoCでは、このAPI仕様に準拠しつつ、将来的なリクエスト増にもスケール可能なアーキテクチャを目指しました。そこで重要な役割を果たすのがSQS FIFOキューです。
処理フロー
-
Scripted API(New Relic)
10分間隔で実行され、直近15分間の外部通信の検知。宛先ドメインが既知のものであるかを評価し、API Gatewayへ通知します。 -
API Gateway → Lambda(A)
Scripted API起点のリクエストを一旦受け取り、SQSにエンキューします -
SQS FIFO
処理待ちのキューを順序通りに保持します -
Lambda(B)
SQSトリガーとして15秒間隔で実行し、API仕様の範囲内でマルチベンダー型のドメイン評価サービスのAPIを呼び出します
この構成により、短時間に多数の検知が発生した場合でも、リクエストを欠損させることなく、安定して処理を捌くことができます。
5. 実装の勘所③：独自のスコアリングによる評価の自動化
このシステムの核心は、検知したドメインの安全性をどう判断するかです。私たちは、マルチベンダー型のドメイン評価サービスが提供する、複数のセキュリティベンダーの評価結果を基に、独自のスコアリングロジックを実装しました。
マルチベンダー型のドメイン評価サービスからは、各ベンダーによる評価がmalicious(有害), suspicious(疑いあり), harmless(無害)などで返されます。これらの結果から「ネガティブ評価比率」を算出し、ドメインの最終評価を決定します。
- 10%超 → 悪意あるドメイン
- 5%以上, 10%未満 → 疑いのあるドメイン
- 5%未満 → 無害なドメイン
この評価結果に応じてSlack通知の内容と、エンジニアに求められるアクションが変わる点がポイントです。
6. 実装の勘所④：S3をオリジンとした自己成長する評価リスト
評価結果が反映されるドメイン評価リストは、New RelicのLookup Tableで管理していますが、その更新前には必ずS3バケットに最新の状態を保存しています。
S3をオリジンとすることで、キャッシュなどによる意図しないロールバックを防ぎ、常に最新の評価状態で監視を行うことができます。Lambda(B)は評価結果をS3に書き込み、その上でNew RelicのLookup Tableを更新します。これにより、一度「無害」と評価されたドメインは次回の監視から除外され、システムは自己成長していきます。
一度「無害」と評価されたドメインも、EventBridgeによる定期実行（Lambda(C)の処理）によって、一定期間をおいて再評価が行われます。
7. 実装の勘所⑤：評価スコアと連動するSlack通知とアクション
評価スコアに基づき、Slackには大きく3パターンの通知が届きます。それぞれでエンジニアに求められる対応が異なります。
※画像はテスト時の画像です。必要な箇所を修正しています
-
無害なドメインの場合
ネガティブ評価比率が5%未満だった場合に通知されます。新規ドメインでまだ評価が蓄積されていない場合もこれに含まれます。
アクション
基本的に対応不要です。情報は評価リストに自動登録されます
-
悪意あるドメインの場合
ネガティブ評価比率が10%を超えた、危険度の高い通知です。
アクション
即時調査が必要です
-
疑いのあるドメインの場合
ネガティブ評価比率が5%〜10%の、判断が分かれるドメインです。
アクション
エンジニアによる手動評価が必要です。この判断がS3とLookup Tableに反映され、システムの精度が向上していきます
8. PoCとしての成果と今後の展望
本システムはPoCとして稼働しており、その有効性を確認している段階です。
PoCで得られた成果
-
技術的実現性の証明
New Relicを起点とし、AWSサーバーレスコンポーネントを経由して外部APIと連携し、その結果をフィードバックするという一連のアーキテクチャが技術的に実現可能であることを証明できました。 -
運用の有効性の実証
これまで時間を要することもあった手動での調査フローを、検知からSlack通知まで15分以内で行う自動化プロセスの有効性を実証し、初動対応を大幅に迅速化できる見通しが立ちました。
今後の展望：評価情報の拡充による判断精度の向上
このPoCの成功を受け、次のステップとしてシステムの本格導入を見据えています。その際、エンジニアがSlack上でより精度の高い判断を下せるように、評価情報を拡充する方針です。
具体的には、ドメインのWHOIS情報（登録者情報や作成日など）を取得する処理をLambdaのフローに組み込むことを検討しています。ドメインの作成日などをSlack通知に含めることで、マルチベンダー型のドメイン評価サービスの評価スコアに加えて、ドメイン自体の信頼性という別の角度からもリスクを判断できるようになり、手動評価の精度向上に繋がると考えています。
9. まとめ
-
New Relicは、自動化ワークフローの起点として活用することで、単なる監視ツール以上の価値を発揮します
-
サーバーレスアーキテクチャは、API活用を容易にし、拡張性のあるシンプルなシステムを構築する上で非常に有効です
-
自動化と手動介入（Human-in-the-loop）を組み合わせることで、実用的でスケールする仕組みを作ることができます
この記事が、皆さんのアプリケーションセキュリティ向上のヒントになれば幸いです。