新機能「サービス(シャドーIT)検知」における技術選定

こんにちは！エンジニアの内山です。
12/16(金)に社内の利用サービスを可視化できる「サービス検知」、導入後のサービスを管理するための「サービス台帳」機能をリリースしました。 assured.jp

今回はこれらの機能を開発した背景と、サービス検知機能における技術選定について書いていきたいと思います。

サービス検知機能とは

昨今、SaaS/ASPなどのクラウドサービスの利用が加速していることに加えて、コロナ禍によるリモートワーク普及も重なり、「シャドーIT」と呼ばれる、会社に無許可で利用されるサービスの存在が問題視されています。

サービス検知機能では、ブラウザ拡張機能でアクセス履歴を収集して、Assured内のデータベース情報を元にサービスを特定し、利用中のサービスを可視化することで、シャドーITの存在を検知したり、導入済みのサービスの利用実態を把握することができます。

また、社内のクラウドサービス利用が増えると、すべてのサービスの利用状況を可視化し、管理することが困難になってきます。
これらの課題を解決するために、サービス台帳機能ではサービス検知機能によって可視化されたサービスを含め、利用中のサービスをAssured上で一元管理することができます。

具体的には、各サービスの利用人数を把握したり、リスク評価スコアの推移、管理時に必要な項目を追加した上で随時情報を更新することで、社内におけるサービスの利用状況を漏れなく正確に把握し、管理することが可能になります。

そして、サービス検知、サービス台帳機能が増えたことで、既存のリスク評価機能と併せて、利用中のサービスの把握、評価、管理のサイクルを一気通貫で行えるようになりました。

さて、ここからが本題のサービス検知における技術選定のお話になりますが、サービス検知機能を実現するためにはいくつかの方法がありました。その中で私達が検討したのは以下の方法です。

各手法の概要

各手法の比較

※1. MDM (Mobile Device Management)
※2. SSO (Single Sign On)

いずれもメリット、デメリットがある中で、いち早く機能を提供できて、「クラウドサービスの利用状況の可視化」という目的を実現できるという観点で選定した結果、以下の理由でブラウザ拡張機能を利用することにしました。

ブラウザ拡張機能の利用が決定した上で、次は大量のログをどのように扱うかが課題になってきました。

ログの量はブラウザ内の通信に限定されるとしても、
ユーザーあたりのWebページ閲覧数 x ユーザー数
のログを扱う必要があります。
加えて、「クラウドサービスの利用状況の可視化」という特性上、導入するとなると組織全体に一括で導入することが多いため、急激にログ量が増える可能性があります。

また、既存のAssuredの機能とはアクセス傾向が全く異なるため、既存の機能に影響を与えない様に独立したインフラをもつ必要がありました。

これらの課題を解決するために、サービス検知では以下のような工夫を行っています。

クライアント側でのバッファリング
- ブラウザ拡張機能の実装で訪問時にログを送信するのではなく、ログをまとめた上で送信する
ログストレージ
- Big QueryのストレージにBig Query Storage Write APIを利用して直接書き込み
  - 300MB/s (※東京リージョン 2023年1月時点) の書き込みが可能でデータの反映も高速
    - (仮にBig QueryのQuotaを超える場合は) ログ収集サーバーとBigQueryの間にログ集約サーバーを設けることでBigQueryへの流量制限を行う予定
- 直接データ分析が可能
バックエンド側のスケール
- 並列処理の容易さ、立ち上がりの速さ、リソース効率の高さでGoを採用
  - ログ集約の際にメインスレッドとは別スレッドでバッファリングが可能
  - 数百ms程度でコンテナの立ち上げが可能
  - メモリ効率が高い
- 軽量なサーバーを高速かつ大量に並べられるようにCloud Runを利用
  - Goとの組み合わせで軽量のコンテナを高速かつ大量に立ち上げが可能
  - 既存のAssuredの機能とは別ネットワークとなるため、既存の機能には影響を与えない