General
プラットフォーム開発本部 第三開発部の恩田です。もともと基盤開発チームで Gatewayやプロキシを設計・構築・運用してきましたが、最近は同じく第三開発部の不正対策チームのメンバーと一緒に、雇われアーキテクトとして次世代の不正対策基盤のアーキテクチャ検討から構築までを担当しています。今回は Blacklight と呼ばれるこの基盤のコンセプトと、それを実際に設計・構築・運用したお話をします。
Blacklight は Googleによる BeyondCorp の論文からエッセンスを抽出しつつ、MVPとしての価値を提供し、かつ段階的な強化・発展を可能にする次世代型のセキュリティ基盤となります。
[補足] Blacklight という名称
因みに名称の「Blacklight」とは、鮮魚から寄生虫のアニサキスを除去する際にブラックライトを用いることから付けられたものです。鮮魚をブラックライトで照射すると寄生虫が鮮やかに浮かび上がって検出可能になるのと同様に、一見何の変哲もないリクエストに潜む怪しい兆候を、このシステムで浮かび上がらせることを目的とする意味で命名しました。
背景
さて、DMM の不正対策チームでは、日々不正なアクセスを防ぎ、健全なサービスの運用を保証することを責務としています。
仮に 攻撃の兆候が見られた際は、早期にそれを検出し本格的な攻撃が始まる前に警報を上げること、およびその遮断が期待される部分です。これを BeyondCorp の構成をヒントに実現しようというのが Blacklight プロジェクトの目的となります。この企画は Gatewayがアクセスログを大量かつ構造的に吐き出すようになり、BeyondCorp の Paperを確認してからその相性に気づいて提案していたのですが、2024年から徐々に着手することになりました。
以前は一般教養として眺めていた BeyondCorp の 設計を、実稼働するシステムに落とし込むというフローは中々楽しいものです。
Zero Trust と BeyondCorp
まずは、BeyondCorp の概要から説明します。BeyondCorp は Google による Zero Trust の実装となります。Zero Trust というと社内ネットワークに保護された境界型セキュリティからの脱却という文脈や、それを踏まえた SaaSを積極的に利用することによる結果的なリモートワークの促進といったイメージが強くあります。
しかし、境界型セキュリティの脱却や SaaS推進は 間接的な結果でしかなく、Zero Trust の真に強力なところは「コンテキストを把握して最適な対応をする」というそのインテリジェントな判断能力にあります。そして、その判断能力の礎となるコンテキストを収集・把握する仕組みが BeyondCorp なのですが、まずはコンテキストベースという部分から話を進めたいと思います。
コンテキスト・ベースの必要性
「コンテキストを元にした最適な対応」と聞くと一見難しそうに聞こえますが、コンセプトは実に単純で、自動車の運転における「認知・判断・操作」の仕組みと同等です。自動車の運転における「認知・判断・操作」は道路の混雑状況や人の配置を認知し、それが安全な運転に及ぼす影響を判断し、その状況下で最適な操作をするという具合に実現されます。これを正確に行うために、自動車教習所では、学科教習や技能教習で状況の認知・正しい判断・正確な操作を訓練するわけです。
逆に「コンテキストを元にした最適な対応」が実現できない場合は、安全な環境に閉じ込もる必要が出てきます。自動車教習で言えば、教習所内のコースとなりますし、ネットワークの世界で言えば社内ネットワークになります。両者は境界セキュリティ的な考え方に基づいており、いずれも十分に成熟していない能力を環境で保護しようという考え方です。
不正対策領域への応用
さて、これらの考え方を踏まえて不正対策を俯瞰すると、不正対策におけるAPI監視も「認知・判断・操作」で成り立っていることが分かります。（不正対策に限らず、全ての業務は多かれ少なかれこの連続で成り立っていますが…）
| # | 要素 | 不正対策の内容 |
|---|---|---|
| 1 | 認知 | API の利用状況を把握する |
| 2 | 判断 | API の利用状況が不正なものかを判断する |
| 3 | 操作 | API の利用状況が不正なものである場合、関係者への警告や遮断等の対応を行う |
逆に、境界セキュリティ的な考え方では以下のようになります。
| # | 要素 | 不正対策の内容 |
|---|---|---|
| 1 | 認知 | 通信の送信元が 社内であるかを把握する |
| 2 | 判断 | 通信の送信元が 社内のものは安全、社外のものは脅威として捉える |
| 3 | 操作 | ルールは固定され 想定内のものは疎通させ、想定外のものはログを記録し遮断する |
こうみると境界セキュリティはとても単純です。なぜなら「認知」の情報量が本質的に社内外の 1bitであり「判断」もそれに紐づくからです。但し、API通信においてはここまで単純ではなく、一般的には OAuth2 等の仕組みで保護されているため、以下のようになります。
| # | 要素 | 不正対策の内容 |
|---|---|---|
| 1 | 認知 | API 通信が 有効な AccessToken を含むかを把握する |
| 2 | 判断 | API 通信の AccessToken が有効で操作がスコープ内であれば安全、それ以外は脅威として捉える |
| 3 | 操作 | ルールは固定され 想定内のものは疎通させ、想定外のものはログを記録し遮断する |
それでも、これらの仕組みが捉えるコンテキストは近視眼的で、段階的な侵略に対する防御は限定的です。例えば、以下の様な状況には上手く対応できないでしょう。
- 開発者の 社用PCが ウイルスに感染し、有効な AccessToken が定期的に流出していた
- 悪意を持った社内の 開発者・管理者が API経由で社内情報を収集し始めた
- API Client の中でも比較的広範な権限を持つ 社内サーバーが侵入され、そこを起点に多くの APIがコールされた
これらの脅威は大規模で一度に発生する場合もあれば、目立たず徐々に進行する場合もあります。従来の仕組みでも前者は発見しやすいですが、後者の発見は難しいでしょう。
後者の発見が難しい理由は、簡単です。コンテキストを知らないから です。逆に言えば、コンテキストを認知させれば、多くの知的な判断・操作をシステムに代行させることができます。
大量のデータを元にインテリジェントなシステムを構築するという流れは、BigData、機械学習、IoT、クラウド、そして AI という技術の流れにおいて、関連性の強弱こそあれ共通して持つ特徴です。
BeyondCorp
コンテキストベースの制御の必要性をいちはやく突きつけられたのが、世界規模でサービスを展開する Googleです。同社は2010年の中国からのサイバー攻撃で機密情報を奪われた事件を契機に、8年がかりで ZeroTrustを構築しました。その結果 2016年に「BeyondCorp - Design to Deployment at Google 」という記事を出しています。BeyondCorp の基本的なコンポーネント構成はこの記事に提示されています。設計書ではないので、情報は断片的な部分もありますが、全体を通してとても参考になります。
BeyondCorp の根幹を支えるのは Device Inventory Service, Trust Inferer, Access Policy, Access Control Engine と呼ばれる4種類のコンポーネントです。そして、これらのコンポーネントが最終的に行っている作業も「認知・判断・操作」に他なりません。それぞれのコンポーネントの詳細は後述しますが、まずは全体的なフローを説明したいと思います。
処理フローと 4種の主要コンポーネント
Device Inventory Service（DIS）は 認知するためのコンポーネントで、主に機器情報を管理します。例えば機器種別は ラップトップか、またはサーバーか。機器の持ち出し履歴はあるか。セキュリティソフトの導入や定義情報を更新したのは何日前か。サーバーならどのパッチが当たっているか。信用できるソフトウェアスタックで構成されているか。そして機器の管理者の信用度は高いのか？ これらの情報が溜まるほど、後段の認知は正確さを増します。
Trust Inferer（TI） は 認知を深める ためのコンポーネントです。深める認知の対象は Deviceの信用度です。Device Inventory Service が収集した客観的な事実を元に、総合的なデバイスの信用度を決定してきます。
Access Policy（AP） は 判断の基準となるポリシーを提供する コンポーネントです。どの程度の信用度のある Device なら どの程度の操作を許容するかといったルールを管理します。
Access Control Engine（ACE） は 以上の情報を取りまとめて、アクセス許可を判断する ためのコンポーネントです。 Device（詳細は DISで管理） がどの程度の 信用度（Trust Inferer で算出）を持っており、ポリシー（Access Policy）に照らし合わせればそのアクセスを許可は出せるのか…といった形で可否を判断します。
| # | コンポーネント名 | 役割 |
|---|---|---|
| 1 | Device Inventory Service | 機器情報の収集と管理 |
| 2 | Trust Inferer | 機器の信用測定 |
| 3 | Access Policy | 機器・信用階層・操作 等におけるアクセス基準の提示 |
| 4 | Access Control Engine | 総合的なアクセス可否の指示 |
余談ですが、正確には信用度は「信用階層」という階層で表現します。（以前は数値で管理していたのですが同僚に指摘されて設計を階層ベースに修正しました）細かく数値で信用を計測するより、大雑把な階層に割り当てた方が現実的な判断をしやすいという Googleの経験則もある様です。
最後の部品 Gateway
さて、4種の主要なコンポーネントを提示しましたが、よく見ると 操作 の責務を負うコンポーネントがありません。実は操作自体は Gateway に依頼することになります。Gateway というのは抽象的な表現で、実態は API Gateway かも知れませんし、L4 or L7 のProxy かも知れません。Proxy も Service Mesh における Side Car として分散対応するかも知れません。いずれにせよ、アクセスをコントロールできるコンポーネントを Gatewayとして利用します。我々の場合は、すでに API Gateway を保有していますので、そこが第一の選択肢となります。個人的には自分が設計・構築したのでよく知っています。この際に 求められる責務は Access Control Engine に通信判断を仰いで、必要に応じて遮断することだけです。遮断というのは API Gatewayの場合、 403 での応答で実現できます。
| # | コンポーネント名 | 役割 |
|---|---|---|
| 5 | Gateway | 総合的なアクセス可否の指示を実際の通信に適用 |
全体フロー
自然言語の説明だけだとイメージしづらい点もあると思うので、大まかな処理フローを提示しておきます。以下の図は、Blacklightにおける主要コンポーネントの連携フローを示しています。
Component 分割の価値
鋭い方はお気づきでしょうが、4種のコンポーネント + Gateway が適切に分割されていることで、各コンポーネントをマイクロサービスとして活用可能です。マイクロサービスとして分割されていれば、個別にスケール出来ますし、不要な時間は一部のコンポーネントを停止させてのコストを削減も可能です。例えば機器情報の収集やその信用測定が要求するリアルタイム性は状況に寄ります。一方で Gateway は常時稼働が必要でしょう。これに備え、各コンポーネントの結合度は十分に疎にしてあります。
Blacklight の API 制御における モデルと抽象化
以上でコンポーネントベースの責務は設計できましたが、内部で制御する情報は 機器情報だけでありません。モデリングの経験がある方ならおわかりだと思いますが、本質を崩さない程度まで扱う情報を抽象化できれば、そのソフトは長期間に渡って価値を生み出し続けます。今回のコンテキストで言えば、API-Client と API-Endpoint の関係ですが、Blacklight が将来的にそのコンテキストを広げるかも知れません。そのため、今回はアクセス元の API-Client を機器（Device）として、アクセス先の API-Server を資源（Resource）として抽象化し具象モデルの拡張に備えました。
またこれにより文脈を「Device (S) が - 操作 (V) を行う - Resource (O) に対し」という英語の五文型における第三文型（SVO）の文脈で捉えることができます。主語 (S)・動詞 (V)・目的語 (O) で事象を捉えるこの考え方は、非常にシンプルで本質的であり、シンプルで本質的な設計には大きな価値があります。最終的にはこの SVOに対し 許可するか否かを判断すればよいのです。
なお、複雑なものを簡易的に表現するのは職人技ですが、簡易的になった答えを見て理解したり、誰が考えてもこうなると主張するのは割と誰でもできます。
次に、Sを Device, OをResourceとして捉えることの実用性に関しても検証してみます。
API-Clientは何かしらの Device に所属しており、その信用性もその Deviceや Ownerに依存しますし、API-Endpoint は そこに管理される情報も含めて保護されるべき社内資源として考えることができます。今後 Webシステム等が資源として追加されることも想像されますが、API-EndpointとWebシステムは URN等を識別子として利用すれば共通の仕組みに統合可能です。この様な流れで様々なアクセス対象を資源として追加可能でしょう。BeyondCorp によればプリンターや VPNも資源として捉えられる様ですが、そこまで行くかは分かりません。
段階的な実現
この様な段階的な実現が可能というのは、製品としてとても重要なポイントです。特に巨大なプロダクトの場合、企画・設計・構築には時間が掛かるため、全て構築・テストしてからの運用開始となるとリードタイムが長すぎます。また、運用を開始して初めて発覚する問題や課題は間違いなく存在するため現実的とも言えません。そのため早期の運用開始とそこからのフィードバックが重要です。この発想は CI/CDや アジャイル開発と同じです。
今回は、主に以下の手順で段階的に構築する手順を立てました。
| # | 段階 | 構築内容 | 付加価値 |
|---|---|---|---|
| 1 | データ集計 | ・アクセスログから不要な属性を排除した 凝縮ログ を生成 ・凝縮ログから 各種分析に必要な 集計情報 を取得 |
・集計情報の整備 |
| 2 | 機器の信用評価 警報 |
・集計情報を元に 分析エンジンを実行 ・分析エンジンは 集計情報に異常があるかを判定 - ルールエンジンでの判定 - MLでの判定 |
・機器の信用評価 ・一次警報の発報 |
| 3 | 機器情報 強化 | ・定期的に各種システムから機器情報を抽出・取込 ・異常検知の際に提示される機器情報と連携 |
・機器情報の増強 ・状況判断の強化 |
| 4 | 通信の信用評価 警報・遮断 |
・アクセスポリシーを定義 ・コントロールエンジンを実装し Gatewayに連携 |
・通信の制御 ・即時の対応 |
以上の様に構築することで、各段階ごとに価値創出・問題修正を実施し、安全かつ確実に最終形を描くことができます。今までにないモノを作り上げていくプロセスは、不確実で不安が伴うものです。この様に段階的な構築と価値創出をデザインすることで、このプロセスを無理なく進めることができます。
技術要素
さて、技術要素としては詳細は控えますが、主に以下のものを利用しています。比較的 シンプルな割に拡張性に優れているのが特徴です。ログデータを扱う手前データ量は膨大ですが、技術要素自体の難易度はそれほど高くないと言えます。
| # | 分野 | 利用技術 |
|---|---|---|
| 1 | 設計・モデリング | ICONIX Process, Plant UML |
| 2 | 言語 | Golang |
| 3 | Tx, Batch サービス | Cloud Run |
| 4 | データストア | Google Big Query |
技術的な課題
以上の構成で基本的には実現できていますが、扱う情報が非常に大きいため以下の問題が発生しました。
- Cloud Run 上ではメモリ効率を意識しないと、Cloud Run の最大容量を超えエラーになる場合がある
- Google Big Query 上での処理も効率を意識しないと、コストが積み重なってしまう問題がある。これに関しては別の記事で公開される予定
アルゴリズム的な課題
また、技術要素とは直接関係ないのですが、どの様に分析をするか、どの程度の値をベースに問題として見るかという実運用の部分では、常に調整が必要になります。この部分は業務の特性上、詳細はお話できませんが、調整や改善に時間が掛かるのは事実ですので、その意味でも早期のリリースという観点が重要になってきます。
Blacklightの効果と今後の展望
Blacklight はまだまだ課題が多いものの、すでに運用が開始されています。全てが自動化された理想像にはまだ及んでいませんが、以下のような効果が出ています。
- 既存システムがサポートしていない観点での情報の凝縮と集計
- 長期的な変化の可視化と追跡
- 機器（デバイス）と資源（リソース）の特性に応じた判断
そして何よりも、あらゆる観点での情報をこの枠組みで解決できるという優れた BeyondCorp のコンポーネント設計が拡張性に優れています。具体的には既存システムの Blacklight に統合や、新たな観点での対策を追加したりと、その責務分担のシンプルさと最適な配置は今後の意思決定をとても容易にしてくれます。
また、Blacklight は全体で3名、開発者は2名という体制で作り上げているシステムであり、少人数でのコア開発という価値も出ていると考えます。5-6名以上での開発となるとどうしても意見が割れてしまい、その調整に時間を取ります。2-3名であればコミュニケーションのコストも少なく、お互いが一定のリスペクトを元に健全な議論と振る舞いをすれば、時間の問題はあれど健全にプロジェクトは進んでいきます。Blacklight というシステムが出来上がったのもそういった副次的な背景もあると考えています。
今後も 機能やシステムは拡張を続け、更に強力なものになっていくと思いますので、また別の記事を期待していてください。長文を読んでいただきありがとうございました。
