リアルタイムインベントリの詳細解説

FireMon の初期（正確には FireMon となる前）、お客様のクラウドアカウント（サブスクリプションやプロジェクトを含む）をライブで評価しようとする試みには問題があることが分かりました。それだけの数の評価を実行すると、すぐにサービス制限に達し、お客様の内部 API 呼び出しを妨げるおそれもあります。これは約 7 年前、CSPM がまだ存在しない時代に着手した取り組みであり、誰もが同じ教訓を学んでいた時期であったことを申し添えます。

最初に考案した解決策は、構成データを一度だけ収集して自社のインベントリに取り込み、その上で評価を実行するというものでした。これにより、API 呼び出しをメタデータの取得に必要な分だけに削減できました。そして、同じデータセットに基づいて複数の評価を実行できるようになりました。この方式はしばらくの間うまく機能しました。時間ベースの構成スキャンは引き続き実施していましたが、より均等に分散させ、API 呼び出しの過負荷を最小限に抑えるよう最適化できました。しかし、この方式にも固有の課題がありました。スキャンの時点と、実際に担当者がアラートに対応する時点との間に何かが変更されていたらどうなるでしょうか。さらに、ある AWS サービス全体を対象にそのサービス内の全リソースを走査すれば、サービスとリージョンに基づく API 制限を圧迫することに変わりはありません。

この状況をより適切に解決するため、私たちは 2 つの課題を自らに設定しました。第一に、インベントリをリアルタイムに更新し、特定のサービスへの API 呼び出しの急増を抑えるとともに、お客様が古いデータを扱うことが決してないようにすることです。第二に、履歴を保持し、お客様や調査担当者が何がどのように変更されたのかを正確に振り返れるようにすることです。技術アーキテクチャについては後ほど詳しく取り上げますが、クラウドプラットフォームごとに若干異なります。簡潔に言えば、クラウドプロバイダーのイベントストリームに直接接続することで、変更を伴う API 呼び出しを特定し、関係するリソースを抽出し、インベントリをリアルタイムに更新し、特定のインベントリタイプに対するすべての評価を同時に実行できるようになりました。

現在も 1 日 1 回・業務時間外の時間ベースの走査でこれを補完していますが、リアルタイム方式への移行によって多くの課題が解決され、興味深い効果も得られました。その効果は次のとおりです。

• お客様が古いデータに遭遇することはありません。プラットフォーム上のあらゆる情報が、実際の稼働中の構成・状態とほぼ一致します。
• API 呼び出しを監視しているため、誰がその呼び出しを行ったかを特定できます。これにより、インベントリ上で完全な ID 属性付与が実現します。
• 変更が行われた時点で何が変わったのかを容易に特定でき、包括的な変更追跡が可能になります。
• 変更の発生に合わせて、すべてのチェックと評価をリアルタイムに実行できます。これには新たな問題の検出だけでなく、誰かが外部で是正した際に問題を解決済みとする処理も含まれます。

これで、リアルタイムかつ変更追跡付き、ID 属性付与済みの完全な履歴インベントリが完成します。確かに、AWS Config のような機能はクラウドプロバイダー内で同様の機能をネイティブに提供しています。しかし当社のインベントリと評価は、コスト効率に優れているだけでなく、緊密に統合され、複数のクラウド環境とプロバイダーを網羅し、包括的な検索機能をはじめとする非常に優れた機能を備えています。

これを体感いただく最善の方法は、90 秒の動画ツアーです。以下に主要なスクリーンショットをいくつか掲載します。

メインページ。重要なデータを 1 つのビューに豊富に表示します。

こちらは変更履歴のビューで、変更内容を詳細情報と属性情報とともに提示します。関連イベント、関連リソース、例外設定、リソースの合否判定結果の履歴といった有用な機能も備えています。

この履歴ビューは、変更を時系列で追跡し、アクティビティの傾向をグラフで示します。タイムライン上をクリックすると、その日付に移動します。

特定の時点でログに現れた IP アドレスを、どの一時的なクラウドリソースが保有していたのかを知る必要に迫られたことはありませんか。インシデント対応担当者に特に好評の機能です。

以上が簡単な概要です。今後の投稿では、アーキテクチャの詳細と、マルチクラウド環境でこれをどのように実現しているかについてさらに詳しくご紹介します。