こんにちは!エンジニアの内山です。
12/16(金)に社内の利用サービスを可視化できる「サービス検知」、導入後のサービスを管理するための「サービス台帳」機能をリリースしました。
assured.jp
今回はこれらの機能を開発した背景と、サービス検知機能における技術選定について書いていきたいと思います。
サービス検知機能とは
昨今、SaaS/ASPなどのクラウドサービスの利用が加速していることに加えて、コロナ禍によるリモートワーク普及も重なり、「シャドーIT」と呼ばれる、会社に無許可で利用されるサービスの存在が問題視されています。
サービス検知機能では、ブラウザ拡張機能でアクセス履歴を収集して、Assured内のデータベース情報を元にサービスを特定し、利用中のサービスを可視化することで、シャドーITの存在を検知したり、導入済みのサービスの利用実態を把握することができます。
また、社内のクラウドサービス利用が増えると、すべてのサービスの利用状況を可視化し、管理することが困難になってきます。
これらの課題を解決するために、サービス台帳機能ではサービス検知機能によって可視化されたサービスを含め、利用中のサービスをAssured上で一元管理することができます。
具体的には、各サービスの利用人数を把握したり、リスク評価スコアの推移、管理時に必要な項目を追加した上で随時情報を更新することで、社内におけるサービスの利用状況を漏れなく正確に把握し、管理することが可能になります。
そして、サービス検知、サービス台帳機能が増えたことで、既存のリスク評価機能と併せて、利用中のサービスの把握、評価、管理のサイクルを一気通貫で行えるようになりました。
なぜブラウザ拡張機能という方法を選んだのか
さて、ここからが本題のサービス検知における技術選定のお話になりますが、サービス検知機能を実現するためにはいくつかの方法がありました。その中で私達が検討したのは以下の方法です。
各手法の概要
- ブラウザ拡張機能
- IdP (Identify Provider) API連携
- エージェント型
- PCにエージェント型のソフトをインストールして、通信ログを収集する
- ネットワーク型
- 通信をプロキシして、通信ログを収集する
- ルーターログ連携
各手法の比較
※1. MDM (Mobile Device Management)
※2. SSO (Single Sign On)
いずれもメリット、デメリットがある中で、いち早く機能を提供できて、「クラウドサービスの利用状況の可視化」という目的を実現できるという観点で選定した結果、以下の理由でブラウザ拡張機能を利用することにしました。
- 現在のチームの技術スタックから見て、実装難易度、コストが高くない
- PCブラウザでのシェア率が大きいEdge, Chromeが同じChromiumベースなので(ほぼ)同じ実装で実現可能
- SaaS/ASPなどのクラウドサービスはブラウザからの利用が大半
- ブラウザ内のアクセス履歴に関しては網羅的に取得可能
大量のログをどのように扱うか
ブラウザ拡張機能の利用が決定した上で、次は大量のログをどのように扱うかが課題になってきました。
ログの量はブラウザ内の通信に限定されるとしても、
ユーザーあたりのWebページ閲覧数 x ユーザー数
のログを扱う必要があります。
加えて、「クラウドサービスの利用状況の可視化」という特性上、導入するとなると組織全体に一括で導入することが多いため、急激にログ量が増える可能性があります。
また、既存のAssuredの機能とはアクセス傾向が全く異なるため、既存の機能に影響を与えない様に独立したインフラをもつ必要がありました。
これらの課題を解決するために、サービス検知では以下のような工夫を行っています。
- クライアント側でのバッファリング
- ブラウザ拡張機能の実装で訪問時にログを送信するのではなく、ログをまとめた上で送信する
- ログストレージ
- Big QueryのストレージにBig Query Storage Write APIを利用して直接書き込み
- 300MB/s (※東京リージョン 2023年1月時点) の書き込みが可能でデータの反映も高速
- (仮にBig QueryのQuotaを超える場合は) ログ収集サーバーとBigQueryの間にログ集約サーバーを設けることでBigQueryへの流量制限を行う予定
- 300MB/s (※東京リージョン 2023年1月時点) の書き込みが可能でデータの反映も高速
- 直接データ分析が可能
- Big QueryのストレージにBig Query Storage Write APIを利用して直接書き込み
- バックエンド側のスケール
- 並列処理の容易さ、立ち上がりの速さ、リソース効率の高さでGoを採用
- ログ集約の際にメインスレッドとは別スレッドでバッファリングが可能
- 数百ms程度でコンテナの立ち上げが可能
- メモリ効率が高い
- 軽量なサーバーを高速かつ大量に並べられるようにCloud Runを利用
- Goとの組み合わせで軽量のコンテナを高速かつ大量に立ち上げが可能
- 既存のAssuredの機能とは別ネットワークとなるため、既存の機能には影響を与えない
- 並列処理の容易さ、立ち上がりの速さ、リソース効率の高さでGoを採用
結果として、いち早く「クラウドサービスの利用状況の可視化」という目的を達成しつつ、以下の課題をクリアするためのインフラを実現できたかと思います。
- 大量のログ(アクセス)を処理可能
- 大量のログの保存、分析が可能
- 既存の機能には影響を与えない
また、副次的な効果ではありますが、技術スタックにGoが加わったことにより、システムの特性に合わせた言語の選択肢を増やすことができました。早速、いくつかのサブシステムではGoが採用され始めています。
さいごに
組織や事業のフェーズが変われば最善の方法も変わってくるかと思いますが、現在のAssuredのフェーズやチームの中で、お客様にいち早く「クラウドサービスの利用状況の可視化」を提供するという目的においては、良い技術選定ができたのではないかと思っています。
そして、新たな技術スタックや文化を作っていける楽しさは今のフェーズならではかと思います。
この記事を通してAssuredに興味がわきましたら、ぜひカジュアルにお話させてください!
forms.gle
careers.assured.jp