こんにちは!ネットワークやセキュリティの世界へようこそ。インフラエンジニアの皆さん、日々の運用お疲れ様です。
会社でMicrosoft 365やGoogle Workspace、あるいはSalesforceやSlackといったクラウドサービスを使うのが、すっかり当たり前になりましたよね。「いつでも、どこからでも仕事ができる」というのは本当に便利ですが、セキュリティ担当者としては、ちょっと夜も眠れないほど頭を悩ませるポイントでもあります。
「社内のパソコン以外から、大量の機密データがこっそりダウンロードされていないだろうか?」
「退職間近の社員が、急に管理者権限を悪用して設定をいじっていないだろうか?」
こうしたクラウドの「見えない死角」を監視してくれる心強い味方が、今回スポットを当てる CASB(Cloud Access Security Broker:キャスブ) というセキュリティソリューションです。今回は、そのCASBが集める「監査ログ」を、私たちのセキュリティの司令塔である SIEM/SOAR に連携してリアルタイムに監視する仕組みについて、身近な例えを交えながら一歩ずつ優しく紐解いていきましょう!
—
1. 例え話でスッキリ理解!「CASBの監査ログ」と「SIEM」の関係
難解なセキュリティ用語が出てくると、どうしても身構えてしまいますよね。まずは、私たちの身の回りにある「郵便配達とマンションの管理体制」に例えて考えてみましょう。
- クラウドサービス(M365やSlackなど) = 住民が自由に使える「巨大なレンタルマンション」
- CASB(キャスブ) = そのマンションの入り口に常駐し、誰が・いつ・どんな荷物を持ち出し、どの部屋(管理者設定)に入ったかをすべて24時間体制でビデオカメラとノートに記録している 「超優秀なコンシェルジュ」
- 監査ログ(Audit Log) = コンシェルジュがノートにびっしり書き留めた 「今日の入退館・不審行動の記録メモ」
- SIEM / SOAR(シム/ソアー) = コンシェルジュのメモを全棟分集約し、「おや、この住民は夜中に大きなスーツケースを何度も持ち出しているぞ…?不審者警報を発令しよう!」と自動で判断する 「警備会社の最先端モニタリングルーム」
そう、CASBの監査ログ収集とは、クラウドという名のマンションで起きた出来事の「一部始終の記録」を、夜警の専門部隊(SIEM)にリアルタイムで共有する仕組みのことなんです。これならイメージしやすいですよね!
—
2. なぜ、CASBのログを外部(SIEM)に集める必要があるの?
「クラウドサービスの管理画面を見れば、ログなんていつでも確認できるのでは?」と思った方もいるかもしれません。確かにその通りです。
しかし、企業が利用するクラウドは1つだけではありません。Microsoft 365もあれば、Boxもあり、AWSもあり、GitHubもあります。それぞれの管理画面にわざわざログインして、バラバラにログを確認するのは、何十棟もあるマンションの監視カメラ映像を、管理人さんが1つずつ別々のモニターでチェックし続けるようなもので、どう考えても手が回りませんよね。
だからこそ、CASBという「一括通訳&記録係」がすべてのクラウドの動きをきれいに整理(正規化)して集約し、それをセキュリティの司令塔であるSIEMへ一網打尽に転送してあげる必要があるのです。
—
3. 監査ログがSIEMに届くまでのリアルな流れ
では、実際にクラウド上でユーザーが「怪しい動き」をしたとき、パケットやデータは裏側でどう流れているのでしょうか。その一連の流れを覗いてみましょう。
1. イベントの発生:ユーザーが社外からクラウド上に保管された顧客リスト(1万件)を一気にダウンロードしました。
2. CASBの検知:CASBのプロキシ、またはAPI連携(API Connector)が、この「大量ダウンロード」の挙動をピタリとキャッチします。
3. ログの整形(パース):CASBが、バラバラだったデータのフォーマットを、人間やシステムが読みやすい共通の形式(JSON形式など)に綺麗に整えます。
4. 外部転送(Syslog / REST API):整えられた監査ログが、ネットワーク経由で企業のSIEM基盤(SplunkやMicrosoft Sentinelなど)に向けて発射されます。
5. 検知・自動対応(SIEM/SOAR):SIEM側で「このユーザーの通常行動から逸脱している!」と判定され、SOARが連動して「即座に該当アカウントを一時ロックし、セキュリティチームのチャットに通知する」というアクションを瞬時に実行します。
この一連のドラマが、わずか数秒の出来事として裏側で繰り広げられているのです。
—
4. 実務で役立つ!監査ログ転送の設定サンプル
ここからは、少しだけ実践的なお話をしましょう。インフラエンジニアとして現場に出ると、CASBからSIEMへログを飛ばすための「転送設定」や「データフォーマット(JSON)」に触れる機会が必ずやってきます。
ここでは、最も一般的な Syslog(TCP/UDP) を使った転送イメージと、送られてくる実際の JSONログの構造 を見ていきましょう。
設定イメージ(Syslog転送の概念パラメータ)
CASBの管理コンソールで、外部のSIEMサーバーへログを飛ばすときは、次のような宛先情報を設定します。
# CASBからSIEM(Syslogサーバー)への転送設定例
転送プロトコル: TCP (暗号化のためにTLSを利用することが推奨されます)
送信先SIEMのIPアドレス: 192.168.100.50
送信先ポート番号: 514 または 6514 (TLS用)
ログフォーマット: JSON (標準化された形式)
フィルタリング条件: 管理者操作(Admin Activity) と 重大アラート(High Severity) のみ転送
監査ログのデータ構造(JSONサンプル)
SIEMに届いたログは、次のような構造(キーと値のペア)を持っています。この中身をSIEM側でパース(解析)し、「誰が、どこから、何をしたのか」を判別します。
{
"timestamp": "202X-10-24T08:30:00Z",
"vendor": "SampleCASB",
"product": "CloudSecurityGateway",
"event_type": "Data_Download",
"severity": "High",
"actor": {
"user_email": "taro.security@example.com",
"ip_address": "203.0.113.50",
"location": "Tokyo, Japan"
},
"target": {
"cloud_service": "Microsoft_SharePoint",
"resource_name": "202X年度顧客マスタ_秘密.xlsx",
"action": "Download"
},
"details": {
"file_size_bytes": 52428800,
"risk_score": 85,
"message": "通常とは異なる大量のデータダウンロードが検出されました。"
}
}
どうでしょうか?「user_email(誰が)」や「ip_address(どこから)」、「resource_name(何を)」といった項目が綺麗に整理されているおかげで、SIEM側で「このユーザーの危険度スコア(risk_score)が85と高いからアラートを鳴らそう!」と簡単にプログラムで判定できるわけですね。
—
5. 導入時の落とし穴?現場でよくあるトラブルと注意点
最後に、インフラの現場でCASBとSIEMの連携を構築する際、初心者のエンジニアが思わずハマりがちな「リアルな注意点」をいくつかシェアしておきますね。
- ログの「容量(ボリューム)」に圧倒される問題
- クラウドサービス全体のログをすべてリアルタイムで収集しようとすると、想像を絶するほどの巨大なデータ量が流れてきます。SIEMのライセンス費用(容量従量制など)が跳ね上がってしまう原因になるため、「本当に監視すべき重要イベント(管理者の特権操作や、大量ダウンロードなど)」だけにフィルターを絞るチューニングが不可欠です。
- タイムスタンプ(時刻)のズレに泣く問題
- CASB側、クラウド側、そしてSIEM側でタイムゾーン(UTCとJSTなど)の設定が食い違っていると、タイムラインの調査を行う際に「あれ、この操作どっちが先だっけ?」とパニックになります。必ず「UTC(協定世界時)」で統一してログを管理するのがプロの鉄則です。
—
まとめ
今回は、CASBの監査ログ収集と、それをSIEM/SOARへ連携する仕組みについて、身近な例えを交えながらお伝えしました。
- CASB はクラウドというマンションの「優秀なコンシェルジュ」。
- 監査ログ は、そこで起きたすべての行動を記録した「詳細な日誌」。
- SIEM/SOAR は、その日誌を集約して不審な動きを自動で検知・迎撃する「警備司令室」。
この3つがガッチリと手を取り合うことで、私たちのゼロトラストなセキュリティ環境はしっかりと守られています。最初は難しく見えるネットワークの仕組みも、一つひとつの役割を紐解いていけば、ちゃんと腑に落ちていきますよね。
「一歩ずつ理解していきましょう!」の精神で、これからも一緒にインフラ・セキュリティの世界を楽しく学んでいきましょう。それではまた次回の記事でお会いしましょう!
コメント