430万人被害の「ブラウザ拡張機能」汚染 7年潜伏、ある日突然牙をむく
「禁止」か「管理」か――現実的な解を求めて
「公式ストアにあるから」「有名ベンダーだから」「導入時に審査したから」という性善説に基づいた運用は、もはや通用しない。情シス部門は、ブラウザ拡張機能を「潜在的な脅威」と見なし、ゼロトラストの原則で管理体制を再構築する必要がある。 まず認識すべき点は、導入時のセキュリティチェックには賞味期限があるということだ。ShadyPandaの事例が示すように、安全だった拡張機能が数年後にマルウェア化することは珍しくない。また、開発元の買収によって運営主体が変わり、データ利用ポリシーが改悪されるケースも多発している。 したがって、一度許可した拡張機能であっても「永久ライセンス」を与えてはならない。定期的な棚卸しを行い、更新履歴や権限変更の有無、ストアでの最新レビュー（「最近おかしい」といった報告がないかどうか）をモニタリングするプロセスが必要だ。
ホワイトリスト運用の徹底
技術的な防衛策として最も有効なのは、業務上必須のツール以外は原則禁止とするホワイトリスト運用への転換だ。管理ツール「Chrome Enterprise」「Microsoft Intune」の管理ポリシーを活用すれば、許可された拡張機能以外はインストールできないよう強制できる。 さらに、許可する際も「最小権限の原則」を適用すべきだ。特に「全てのウェブサイト上のデータへのアクセス」や「閲覧履歴の読み取り」といった広範な権限を要求する拡張機能は、情報漏えいのリスクが極めて高い。これらは業務上不可欠な理由がない限り、例外なくブロック対象とするポリシーを検討すべきである。また、特定の業務SaaSドメインに対しては、拡張機能の実行を一律ブロックする設定も有効だ。
EDR／NDRによる出口対策
ポリシー設定だけでは防ぎきれない未知の脅威、あるいはCyberhavenのように正規ツールが侵害されたケースに対しては、EDR（Endpoint Detection and Response）やNDR（Network Detection and Response）による「出口対策」が最後の砦となる。 これらを用いれば、拡張機能のプロセスが不審な外部ドメイン（C＆Cサーバ）と通信を行ったり、大量のデータを送信したりする「振る舞い」を検知できる可能性がある。拡張機能が生成する通信ログを監視し、業務に関係のない不審な宛先へのアクセスを早期に発見できる体制を整えることが、被害を最小限に抑える鍵となる。
