【テクニカル・上級編】 CASBにおけるシャドーIT（未承認クラウドサービス）の検出と評価アルゴリズム – ゼロトラスト＆エンタープライズセキュリティ実践ガイド

境界防御の崩壊と「見えないクラウド」の現実

ネットワークエンジニアとして長年、企業の要塞ネットワークを構築してきた私にとって、近年の「社内ネットワークは安全である」という前提の崩壊は、ある種のロマンと絶望が入り混じった壮大なパラダイムシフトだった。境界型防御という堅牢な城壁は、リモートワークの普及とSaaSの爆発的な浸透によって無力化され、今やトラフィックの大部分は企業の管理外へとダイレクトに流出している。

その最たるものが、情シス部門のあずかり知らぬところで現場の社員が業務利用する「シャドーIT」だ。
「ちょっとしたデータ共有に」「便利なタスク管理だから」という現場の善意の裏で、暗号化されたTLSセッションの海に隠れ、機密データが野良のクラウドストレージへと吸い上げられていく。これを検知・統御するために現れたのがCASB（Cloud Access Security Broker）であるが、単に「怪しいドメインをブロックする」という昭和のファイアウォール的なアプローチは、モダンなWebの構造の前には完全に無力だ。

本稿では、CASBがプロキシやファイアウォールのログ、あるいはフォワードプロキシのインスペクションを通じて、どのようにシャドーITを検出し、数多のクラウドサービスを多角的な評価アルゴリズムでランク付けしているのか。そのパケットレベルの挙動から、Linuxカーネルチューニング、さらにはTLSハンドシェイクの裏側まで、妥協なきエンジニアの視点で徹底的に解剖していこう。

—

シャドーIT検出の起点は「ログの海」とパケットインスペクション

CASBがシャドーITをあぶり出すアプローチは、大別して「ログ解析型（API/Log Analysis）」と「インライン型（Forward Proxy / CASB Gateway）」の2つに分かれる。前者はファイアウォール、セキュアWebゲートウェイ（SWG）、あるいはDNSサーバーのクエリログを非同期で回収し、後者はユーザーとSaaSの間にインラインで割り込んでTLSを終端する。

特に、膨大なログからシャドーITの芽を見つけ出すログ解析型のアルゴリズムは、単なるURLのブラックリストマッチングではない。実務の現場では、次のようなパイプラインでパケットのメタデータが処理されている。

[クライアント端末] --(HTTPS / TCP 443)---> [次世代FW / SWG]
                                                    │
                                           (Syslog / NetFlow)
                                                    ▼
                                          [CASBコレクター]
                                                    │
             ┌──────────────────────────────────────┴──────────────────────────────────────┐
             ▼                                             ▼                               ▼
     [SNI/DNS逆引き正規化]                        [TLS JA3/JA4 フィンガープリント]      [トラフィック量・頻度時系列分析]
             └──────────────────────────────────────┬──────────────────────────────────────┘
                                                    ▼
                                    [AI駆動型リスクスコアリングエンジン]

ここで重要になるのが、HTTPS通信の暗号化の壁をどう突破して「どのサービスか」を特定するかだ。Client Helloに含まれるSNI (Server Name Indication)、あるいはDNSのA/CNAMEレコード、そしてTLSセッション初期の暗号スイートの並び順から算出されるJA3/JA4フィンガープリントを組み合わせることで、たとえIPアドレスが頻繁に変わるCDN上のSaaSであっても、正確なサービス名を特定する。

—

リスクスコアリングの裏側：何を基準に「危険」と判定するか

検出された無数のSaaS群に対し、CASBは独自の評価アルゴリズムを用いてリスクスコア（通常0〜100点、あるいはA〜Fのグレード）を付与する。このスコアリングは、単に「知られていないサービスだから危険」という稚拙なものではない。

評価アルゴリズムは、主に以下の3つの軸で構成されている。

1. コンプライアンスと法規制への準拠度

  • SOC 2 Type II、ISO/IEC 27001、GDPR、HIPAAなどの第三者認証を取得しているか。
  • データの暗号化（保存時・転送時）が標準実装されているか。

2. 企業のセキュリティポリシーとの合致

  • 多要素認証（MFA）の強制をサポートしているか。
  • 細粒度なアクセス制御（RBAC/ABAC）や、データロス防止（DLP）機能を提供しているか。

3. ベンダーの信頼性と運用の透明性

  • 過去のセキュリティインシデント（データ漏洩など）の有無。
  • 脆弱性開示ポリシー（VDP）やバグ報奨金プログラムの有無。

これらの要素を重み付け計算し、企業にとって許容できるリスク閾値を超えたサービスを「シャドーITの温床」としてアラートを上げる仕組みだ。

—

高負荷環境に耐えるインフラ設計：RTT削減とカーネルチューニング

インライン型CASBや、膨大なログをリアルタイムで処理するコレクターをオンプレミスまたはIaaS上に構築する場合、ネットワークの遅延（RTT）とスループットのボトルネックは常にエンジニアの頭痛の種となる。

CASBがプロキシとして振る舞う場合、クライアントからのTCPコネクションを一度終端し、クラウドサービス側へ新しいコネクションを張る（リバース/フォワードプロキシの挙動）。この過程でTCPの3ウェイハンドシェイクやTLSハンドシェイクが二重に行われ、ミリ秒単位の遅延がユーザー体験を確実に悪化させる。

このレイテンシーを極限まで削ぎ落とすためには、Linuxカーネルレベルのチューニングが不可欠だ。以下に、高スループットなCASBプロキシノードで実際に適用すべき/etc/sysctl.confの設定例を示す。

# ==========================================
# CASBプロキシ/コレクター向け Linuxカーネルチューニング
# ==========================================

# 1. TCPウィンドウサイズとバッファの動的チューニング
# 高BDP（Bandwidth-Delay Product）環境下でパイプラインを最大化
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# 2. TIME_WAITソケットの迅速な再利用と recicling の無効化（現代のLinuxではtw_recycleは推奨されないためtw_reuseを使用）
net.ipv4.tcp_tw_reuse = 1

# 3. SYNバックログの拡張（DDoSや突発的な大量セッション確立への備え）
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535

# 4. TCP BBR混雑制御アルゴリズムの有効化
# パケットロスが多いネットワークでもスループットを限界まで引き出す
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

# 5. TCPキープアライブの最適化（ゴーストコネクションの早期切断）
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_keepalive_probes = 5

特に tcp_congestion_control = bbr の採用は、世界各地に点在するSaaSエンドポイントと通信するCASBプロキシにおいて、従来のCUBIC算法に比べてスループットの劇的な改善をもたらす。パケットロスを「混雑」ではなく「利用可能な帯域の限界」と誤認させないBBRの挙動は、セキュアなインスペクションを通過するトラフィックの遅延を最小化する上で極めて強力だ。

—

TLSハンドシェイクの最適化と暗号解読のジレンマ

インライン型CASBの最大の技術的課題は、「SSL/TLS可視化（SSL Decryption）」に伴うCPU負荷とプライバシーのジレンマだ。

エンドユーザーが社給端末から未知のSaaSにアクセスする際、CASBは中間者（MitM）として振る舞い、動的に生成したルート証明書で署名した偽のサーバー証明書をクライアントに提示する。これによりトラフィックを復号して検査するわけだが、この処理は強烈な暗号演算能力（AES-NIやIntel QATなどのハードウェアアクセラレーション）を消費する。

さらに、TLS 1.3の普及に伴い、ハンドシェイクの暗号化方式やプライバシー保護機能（ECH: Encrypted Client Hello、旧ESNI）が強化されたことで、従来の単純なパケットインスペクションは急速に通用しなくなっている。
ECHが有効な場合、外側のClient Helloすら暗号化されるため、プロキシはSNIを覗き見ることができなくなる。

これに対抗するため、モダンなCASBアーキテクチャでは以下の複合的なアプローチが採られる。

1. ネットワーク層でのDNS階層ブロック: ECHによる暗号化の前に、社内DNSフォワーダーやCASBエージェントがDNSクエリレベルで未承認サービスの名前解決をブラックホール化する。
2. EDR（Endpoint Detection and Response）連携: ネットワーク上のプロキシだけでなく、エンドポイントのブラウザプロセスから直接APIフックや証明書ストアを監視し、ブラウザがアクセスしようとしている実際のURLをインラインでキャプチャする。
3. セッションキャッシュとチケットの最適化: TLS Session Resumption（Session ID / Session Tickets）を積極的に活用し、ハンドシェイクのオーバーヘッドを削減する。

以下は、NGINXベースのカスタムCASBフォワードプロキシにおいて、TLSセッションキャッシュを最適化し、ハンドシェイクのレイテンシーを極限まで削るための設定スニペットだ。

# ==========================================
# CASBフォワードプロキシ TLS最適化設定
# ==========================================

server {
    listen 443 ssl http2;
    server_name proxy.enterprise.internal;

    # 動的証明書生成モジュール（またはワイルドカード証明書）の適用
    ssl_certificate     /etc/ssl/certs/casb_mitm_chained.crt;
    ssl_certificate_key /etc/ssl/private/casb_mitm.key;

    # モダンかつ高速な暗号スイートの選定（AEAD系を優先）
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-FILE:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256;
    ssl_prefer_server_ciphers off;

    # TLSセッションキャッシュの有効化（ハンドシェイクのRTTを削減）
    ssl_session_cache shared:CASBSSL:50m;
    ssl_session_timeout 1d;
    ssl_session_tickets on;

    # OCSP Staplingの有効化による証明書検証の高速化
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;

    location / {
        # ここでパケットのインスペクション、DLPスキャン、シャドーIT判定を実施
        proxy_pass $scheme://$http_host$request_uri;
        proxy_set_header Host $http_host;
        proxy_ssl_server_name on;
        proxy_ssl_session_reuse on;
    }
}

この設定により、一度確立されたTLSセッションの再利用率が跳ね上がり、インライン検査を行いつつもユーザーにストレスを与えないスループットを維持することが可能になる。

—

現場で直面する「誤検知」と「検知すり抜け」の罠

シャドーIT検出と評価アルゴリズムを実運用に乗せると、必ずと言っていいほど現場のエンジニアを悩ませる2つの壁に突き当たる。

1. 業務正当性のある「野良SaaS」の誤検知

開発部隊が勝手に使い始めたGitHubやAWSの特定リージョン、あるいはマーケティング部門が導入したマイナーなデザインツールなど、「セキュリティリスクは高いが、業務上必須」というサービスが無数に存在する。
ここで全遮断（Block）をかけると、業務が完全に停止して現場から大ブーイングが起きる。
CASBの評価アルゴリズムは、単に「スコアが悪いからブロック」ではなく、「社内アプルーブド（承認済み）リストとの突合」「利用部門の権限管理」「アップロードされるデータの機密性（DLP連携）」を動的に加味し、「コーチング（警告を出した上で利用を許可する）」「読み取り専用での許可」「完全ブロック」へと柔軟にポリシーをグラデーションさせなければならない。

2. シャドーIT側の「巧妙な回避工作」

クラウドサービスの側も、企業のCASBやファイアウォールによる監視をかいくぐるための技術を次々と実装している。例えば、WebSocketを用いた常時接続トンネリングや、Domain Fronting技術を用いたCDN経由の通信などだ。
これらを検知するためには、静的なURLフィルタリングの枠を超え、パケットのペイロードサイズの変化パターン、通信のインタバル、そして前述したJA3/JA4フィンガープリントによる「挙動の異常検知（Anomaly Detection）」を機械学習パイプラインに組み込む必要がある。

—

ゼロトラストの完成形へ向けて

CASBにおけるシャドーITの検出と評価は、単なる「企業のポリシースキャナー」ではない。それは、境界が消え去ったクラウドの海において、企業が自らのデータの所在を把握し、コントロールを取り戻すための羅針盤である。

パケットの微細な挙動に目を凝らし、LinuxカーネルのバッファからTLSのハンドシェイク、そしてAI駆動のリスクスコアリングまでを一本のパイプラインとして美しく繋ぎ合わせること。それこそが、現代のインフラアーキテクトやセキュリティスペシャリストに求められる、泥臭くも最高に知的な仕事なのだ。

さあ、今夜も企業のログの海にダイブし、まだ見ぬシャドーITの息吹をあぶり出すとしよう。

スポンサーリンク

コメント

タイトルとURLをコピーしました