今回のブログ記事では、シリーズとして Azure Cosmos DB の活用事例を 2 回に分けて取り上げ、このサービスが企業に対し、いかに大きな変化をもたらしているかをご紹介します。パート 1 では、Microsoft Azure Advanced Threat Protection チームが Azure Cosmos DB を採用するに至った経緯と、このサービスの具体的な利用方法について詳しく説明します。さらにパート 2 では、同チームの取り組みの成果について検証していきます。

リアルタイム セキュリティ ソリューションの刷新 - オンプレミスからクラウドへ

Microsoft Azure Advanced Threat Protection はクラウド ベースのセキュリティ サービスで、お客様のオンプレミスの Active Directory シグナルを利用して、高度な脅威や ID の侵害、内部ユーザーによる悪意のあるアクションを特定、検出、調査します。2018 年にリリースされたこのサービスは、オンプレミス ソリューションの Microsoft Advanced Threat Analytics を、Azure 環境へと進化させたものです。オンプレミス版とクラウド版はいずれも、2 つの主要コンポーネントで構成されています。

1. センサー (エージェント): 組織の各ドメイン コントローラー上にインストールします。センサーは、ユーザーからドメイン コントローラーに送信されたトラフィックと、ドメイン コントローラーによって生成された Windows イベント トレーシング (ETW) イベントを検査し、その情報を集中管理されたバックエンドに送信します。
2. センター (集中管理されたバックエンド): 全センサーからの情報を集約し、組織内のユーザーとコンピューターのふるまいを分析し、悪意のある活動を示唆するような異常な動作がないかをチェックします。

Advanced Threat Analytics センターでは従来、メインのデータベースとしてオンプレミスの MongoDB インスタンスを使用しており、現在でもオンプレミスの導入環境では、その仕様に変更はありません。一方、クラウド内で管理サービスとして提供される Azure Advanced Threat Protection に関しては、センターの開発にあたり、オンプレミス版よりもパフォーマンスとスケーラビリティを高める必要がありました。マイクロソフトで Advanced Threat Analytics のプリンシパル グループ エンジニアリング マネージャーを務める Yaron Hagai はこう説明します。「Azure Advanced Threat Protection のバックエンドには絶大なスケーラビリティが必要で、週 1 回ペースのアップグレードに対応すると共に、絶えず変化を続ける高度な検出アルゴリズムを実行できなくてはなりません。要するに、Azure の持てるパワーとインテリジェンスをフル活用できる必要があります」

Azure Advanced Threat Protection のエンティティ データおよびプロファイル (全センサーからリアルタイムで取得される、各組織のユーザーとコンピューターに関するデータ) を格納するため、Hagai のチームは最適なデータベースを探すなかで、主な要件として次の項目をリストアップしました。

• 各お客様レベルでの弾力的なスケーラビリティ: Azure Advanced Threat Protection を採用した組織はそれぞれ数百のセンサーをインストールできるため、毎秒数万件にのぼるイベントが生成される可能性があります。Azure Advanced Threat Protection が各組織のベースラインを取得し、異常検出アルゴリズムをリアルタイムで適用するには、時間的にもコスト的にも効率よく拡張できるデータベースが必要でした。
• 移行の容易さ: 検出ロジックの変更をサポートするため、Azure Advanced Threat Protection のデータ モデルは常に進化しています。データ モデルが絶えず変化するので、そのたびにサービス コードを調整し、旧モデルとの互換性を維持するのはチームにとって負担が大きすぎます。そのため、Azure Advanced Threat Protection の更新でほぼ毎回必要になる、データ移行をすばやく簡単に行えるデータベースが必要でした。
• geo レプリケーション: Azure の他のサービス同様、Advanced Threat Protection では、お客様が特に重視する障害回復とビジネス継続性のニーズに応える必要があります。その一環として、発生する可能性は非常に低いものの、データセンター レベルの障害にも備えなくてはなりません。geo レプリケーションを使用すれば、プライマリ データセンターからバックアップ データセンターへとお客様のデータをレプリケートし、万一プライマリ データセンターで障害が発生しても、Azure Advanced Threat Protection のワークロードの実行をバックアップ データセンターに切り替えることができます。

クラウド内で管理サービスとして提供される、スケーラブルなスキーマレス データベース

Azure Advanced Threat Protection のバックエンド データベースとして、チームが採用したのは Azure Cosmos DB でした。Hagai はこう話します。「Azure 内で管理サービスとして提供される、他に類を見ないスケーラブルなスキーマレス データベースとして、Azure Cosmos DB 以外の選択は考えられませんでした。スケーラビリティに優れた Azure Cosmos DB なら、お客様の数が今後増えていっても問題ありませんし、それに伴って増大するバックエンド サービスへの負荷にも対処できます。各組織に格納されるデータと組織のコンピューターとユーザーに関して求められる自由度の高さもクリアしています。また、継続的に新たな検出パターンを追加し、既存のパターンに修正を加えるには、Azure Cosmos DB コンテナー内の格納データを頻繁に変更できなくてはなりませんが、そのために必要となる柔軟性も備えていました」

コンテナーとパーティション分割

Azure Cosmos DB は多くの API をサポートしますが、Azure Advanced Threat Protection で使用するため、開発チームが検討したのは SQL API と Azure Cosmos DB の MongoDB 用 API の 2 種類でした。最終的に SQL API を選択したのは、マイクロソフトが作成した機能豊富なクライアント SDK を利用できるためです。また、世界中のリージョンでマルチホーム機能がサポートされ、ダイレクト接続モードによって待機時間が抑えられることも決め手となりました。開発チームは各テナント (お客様) に対し、Azure Cosmos DB データベースを 1 つ割り当てることにしました。データベースはそれぞれ 5 つのコンテナーで構成され、いずれのコンテナーにも、初期構成では 1 つのパーティションが含まれます。Hagai はこう説明しています。「この構成にした理由の 1 つは、Azure Advanced Threat Protection の利用を終了した場合に、お客様のデータを削除しやすくするためです。ただし、それよりもさらに重要な理由があります。お客様のオンプレミスのセンサーが生成するスループットに基づいて、各コンテナーを個別に拡張できるようにするためです」

各お客様に割り当てられた一連のコンテナーのうち、次の 2 つについてはパーティションが 2 つ以上になるのが一般的です。

• UniqueEntity: 組織内のコンピューターとユーザーに関する、Active Directory と同期されたすべてのメタデータを格納
• UniqueEntityProfile: UniqueEntity コンテナー内の各エンティティに対応した、ふるまいに関するベースライン データを格納。ユーザーやコンピューターの侵害のほか、内部ユーザーの悪意のある活動を示唆するような、異常な行動を特定するための検出ロジックによって使用される

Hagai は「どちらのコンテナーも読み取り/書き込みスループットがきわめて高く、1 秒あたりの要求ユニット数 (RU/秒) を大量に消費します。Azure Cosmos DB ではコンテナーの拡大に合わせてストレージがシームレスに拡張されるため、規模の大きなお客様のなかには、各コンテナーのサイズが数テラバイトになっている例もあります。これは、仮想マシンをベースとする MongoDB では絶対に不可能でした」と説明します。

上記以外で各お客様に割り当てられる 3 つのコンテナーについては、格納されるドキュメント数は 1,000 件に満たず、パーティションも 1 つで済むのが一般的です。各コンテナーには次のような役割があります。

• SystemProfile: そのテナントのために取得され、ふるまいベースの異常検出に使用されるデータを格納
• SystemEntity: それぞれのテナントの構成に関する情報とデータを格納
• Alert: Azure Advanced Threat Protection によって、生成および更新されたアラートを格納

移行

Azure Advanced Threat Protection の検出ロジックが変更と改良を繰り返すのと同様に、各お客様の UniqueEntityProfile コンテナーに格納されている、ふるまいに関するデータも頻繁に更新されます。古くなったスキーマとの互換性維持の作業を解消するために、Azure Advanced Threat Protection では 2 種類の移行メカニズムが整備され、サービスのアップグレード (データ モデルの変更を含む) のたびに実行されています。

• オンザフライ: Azure Advanced Threat Protection では、Azure Cosmos DB からデータを読み取る際にバージョン フィールドをチェックしています。バージョンが古くなっていた場合は、Hagai の開発者チームが作成した明示的な変換ロジックを使用し、ドキュメントが最新のバージョンへと移行されます。
• バッチ: アップグレードが完了すると、Azure Advanced Threat Protection はスケジュールされたタスクを起動し、すべてのお客様のすべてのドキュメントを最新バージョンに移行します。ただし、オンザフライ メカニズムによって既に移行済みのドキュメントは除きます。

この 2 つの移行メカニズムを組み合わせることで、サービスがアップグレードされ、データ アクセス レイヤーのコードが変更されても、旧バージョンのドキュメントの解析に伴うエラーが発生することはありません。旧バージョンとの互換性維持のために必要なコードは、先ほど触れた明示的な移行コードのみです。こうしたコードは常に、後続のバージョンには引き継がれません。

弾力的な拡張と自動バックアップ

読み取り/書き込みスループットがきわめて高いコンテナーでは、コンテナーに対してプロビジョニングされた RU/秒の上限を要求数が上回り、レートの制限がかかることが少なくありません。サービス ノード (各ノードは仮想マシン) のいずれかがコンテナーに対して処理の実行を試み、「429 – 要求が多すぎます」というレート制限に伴う例外 (英語) を受け取ったとします。この場合、ノードは Azure Service Fabric のリモート処理を使い、集中管理されたエラスティック スケーリング サービスを通じて、スループットの引き上げを求める要求を送信します。前述の集中管理されたサービスは複数のノードからの要求を取りまとめ、短時間のうちに 2 回以上のスループットの引き上げを行わないよう調整します。これは、一時的なスループットの急増によって複数のノードが影響を受け、要求が集中している可能性があるためです。RU/秒の全体的なコストを最小限に抑えるには、たとえば各会社の勤務時間外などに、同様のスケールダウン処理を定期的に行い、プロビジョニングしたスループットを適宜減らします。

Azure Advanced Threat Protection では、Azure Cosmos DB の自動バックアップ機能を各コンテナーの保護に活用しています。作成したバックアップは Azure Blob Storage 内で保管され、geo 冗長ストレージ (GRS) を使用して別のリージョンへもレプリケートされます。Azure Advanced Threat Protection では、お客様の構成データも別のリージョンにレプリケートされているため、万一災害が発生してもすぐにサービスの復旧が可能です。Hagai はこう説明しています。「これは主に、センサーの構成データの保護を目的としています。元のデータベースが失われても、何百ものセンサーを IT 管理者が再構成しなくても済むようにするためです」

先日、Azure Advanced Threat Protection において、geo レプリケーションの完全な提供が開始されました。Hagai は言います。「geo レプリケーションへの対応を開始し、複数のリージョンへの書き込みを可能にしたことで、シームレスかつ手間をかけずに、実稼働データを別のリージョンへとレプリケートできるようになりました。これによって、さらに優れたサービスの可用性が保証されるでしょう。また、独自の高可用性メカニズムの維持や管理が不要のため、サービス提供がシンプルになります」

本ブログ記事のパート 2 では引き続き Azure Advanced Threat Protection チームの事例を取り上げ、Azure Cosmos DB の実装がもたらした成果をご紹介します。