望ましい成果を理解する：Cloud Defense Freeの機能セットを選定した経緯

当社がFireMon Cloud Defense の無償版の提供を決めた際、2 つの重要な課題を両立させる必要があることは分かっていました。

• 当社のプラットフォームがスケールできることはすでに分かっていましたが、大企業を長期にわたって支えられるよう、経済的にスケールさせることはできるのか。言うまでもなく、単にリリースして AWS の請求額が当社を破産管理に追い込まないことを願う、というわけにはいきませんでした。
• 経済的な制約があるなかで、ユーザーに真の価値をもたらす機能セットを提供できるのか。その価値とは何か。どのような課題を解決するのか。

実際のところ、何かを使うには時間と労力がかかる以上、（ビールのような意味での）「無料」が完全に無料であることはありません。当社は Cloud Defense の無償ティアを、テーブルの端からこぼれ落ちるパンくずのようなものとは考えていません。ユーザーに登録し、導入し、プラットフォームを活用していただくよう求める以上、ユーザーの業務遂行を支援できなければ、そうしていただけないと理解しています。

（当社にとっての利点は何か。一定の割合のユーザーが有償プランへ移行することは分かっていますが、それ以上に、無償プラットフォームによって、人々が CSPM に何を求め、どのように使っているのかについて極めて価値の高いフィードバックを得られ、新しいアイデアを検証できます。）

技術面については今後の記事で詳しく取り上げますが、本日は無償ティアにどの機能を組み込むかをどのように決定したか、そのプロセスを説明します。このバージョンのプラットフォームを独立した製品と捉えているため、当社の戦略の多くを導いているのと同じ方法論的アプローチを用いることにしました。

望ましい成果を定義する

FireMon では、製品戦略において Jobs to be Done フレームワークを高く評価しています。名称からも分かるとおり、このフレームワークは、顧客が成し遂げようとしている「ジョブ」と、顧客が期待する具体的な成果に着目して製品の意思決定を導きます。これは JTBD フレームワークのきわめて大まかな単純化ですが、趣旨はお分かりいただけるでしょう。機能に着目するのではなく、製品を使用する際に見込み顧客が望む成果に着目し、それをもとに機能を設計するのです。

調査、経験、インタビューを含む綿密なプロセスを経て、クラウドセキュリティの専門家にとって望ましいと考えられる成果のドラフトを次のように絞り込みました。

• クラウド環境全体にわたるクラウドポスチャに関する知識と理解を高める。（可視性）
• クラウド環境全体でクラウドの設定ミスが構成される可能性を最小化する。（予防）
• 分散型環境において、クラウド環境全体のクラウドセキュリティおよびコンプライアンス上のエクスポージャー（件数と時間）を削減する。（修復）
• 経営層および規制当局にクラウドセキュリティの課題を伝える能力を高める。
• クラウド環境に対する IAM アクセスの喪失や悪用の可能性を低減する。
• クラウドへの攻撃を予防、検知、対応する能力を高める
• 複数のプロバイダーにまたがるクラウドサービスやプラットフォームの変更に合わせて、セキュリティを最新の状態に保つ。
• セキュリティリスクを高めることなく、開発チームおよびクラウドチームにかかるセキュリティ上の摩擦とオーバーヘッドを軽減する。
• コンテナを用いて展開する際のセキュリティ侵害のリスクを低減する。
• 標準的な API とデータ構造により、クラウドセキュリティを自社のプログラムに統合する時間を短縮する。

これらの課題に対処する方法は数多くあります。そのため当社にとっての問いは、無償のホスト型プラットフォームを運用するという経済的制約のなかで、どれを提供できるのかということでした。これは、利用者が自ら導入・運用する必要のあるオープンソースソフトウェアを提供するのとはまったく異なります。当社は、商用製品と同じくらい高速で使いやすいもの（いえ、願わくはこれまで使われてきた多くの製品よりも高速で簡単なもの）を作りたいと考えました。

成果を機能に落とし込む

このリストをもとに、何を適応させ、何を構築できるかを検討しました。

• クラウド環境全体にわたるクラウドポスチャに関する知識と理解を高める。（可視性）

ポスチャとは必ずしもセキュリティだけを指すものではありません。ポスチャとは、物事がどのように構成されているかということです。設定ミスの一覧を示すだけではポスチャを伝えられないため、コスト上の制約のなかで、エンタープライズ規模のクラウドインベントリを構築する必要があると分かっていました。当社のプラットフォームはすでにリアルタイムのインベントリに対応していましたが、それを無償ティアにまで拡張するのは費用対効果が見合いませんでした。

検討の結果、1 日 1 回のスキャンと、変更追跡を伴う 30 日間のインベントリ履歴であれば、コストを抑えつつ価値を提供できると判断しました。まだセキュリティの設定ミスについては触れていませんが、後ほど説明します。コストモデリングを行ったところ、これをエンタープライズ規模（数千の監視対象アカウント）で予算内に運用できると分かり、価値の提供とコスト管理の両方の条件を満たしました。

商用製品は主に定期スキャンではなくリアルタイムのインベントリ更新に対応していたため、これには実際かなりのエンジニアリング工数を要しました。ただし、これらの更新は全体的な効率を高めるために当社が実施したかった他の変更と併せて実装でき、うまく整合したため、容易な判断となりました。

• クラウド環境全体でクラウドの設定ミスが構成される可能性を最小化する。（予防）

クラウドの設定ミスの予防は、検知よりもはるかに難しい課題です。Infrastructure as Code を使用している場合、CI/CD パイプラインでブロックするのか。手動の変更はどうするのか。過度な摩擦を生んだり、動作を壊したりせずにワークフローをどう扱うのか。

現時点で、無償製品に完全な予防機能を実装することはできないと判断しました。現行のプラットフォームでは自動化によってこれを実現していますが、無償で大規模に運用するにはコストがかかりすぎます。とはいえ、実現できそうなアイデアはいくつかあり、現在は開発バックログに入っています。

• 分散型環境において、クラウド環境全体のクラウドセキュリティおよびコンプライアンス上のエクスポージャー（件数と時間）を削減する。（修復）

これは製品の初期バージョン以来、Cloud Defense の中核をなしてきた領域です。自動修復は無償ティアでは成立しませんが（ここでもコストと複雑性のバランスの問題です）、セキュリティチェックのフルスイートを実行しない理由はありませんでした。

しかし、潜在的なセキュリティ課題の長大なリストを受け取っても、必ずしも修復に役立つわけではありません。当社製品のもう一つの中核機能が、緊密な ChatOps 連携です。標準で Slack と Teams をサポートしていましたが、Teams は……まあ、Teams であるがゆえに、より多くのサポートを要します。そこで、当社側に実質的なコストがかからず、ユーザーにとって大きな価値がある、きめ細かな（アカウント単位またはプロジェクト単位の）Slack 通知を全面的に有効にすることにしました。

• 経営層および規制当局にクラウドセキュリティの課題を伝える能力を高める。

コンプライアンスレポートを実行する当社の内部コストは、大規模環境であってもごくわずかです。コンプライアンスについては、1 日 1 回の評価でこの望ましい成果を十分に満たす傾向があります。大規模な環境（数百アカウントなど）向けに、より優れた PDF レポートをサポートするための新たな開発工数は必要でしたが、これは商用のお客様のためにいずれにせよ必要なものでした。

• 複数のプロバイダーにまたがるクラウドサービスやプラットフォームの変更に合わせて、セキュリティを最新の状態に保つ。

無償製品と商用製品は、当社が継続的に更新している同一のチェックライブラリを使用しているため、これは標準で有効になっています。当初のエンジニアリングは AWS のコスト最適化に注力したため、開始時点では Azure および GCP のサポートなしでリリースすることにしました。Azure はまもなく準備が整うため、ユーザーは最終的に完全なマルチクラウドサポートを無償で利用できるようになります。

• クラウド環境に対する IAM アクセスの喪失や悪用の可能性を低減する。

当社には Authorization Control という非常に優れた機能があり、IAM セキュリティを大幅に向上させますが、これを無償製品に含めるのは採算が合いませんでした。

• クラウドへの攻撃を予防、検知、対応する能力を高める

当社の商用製品はリアルタイムの脅威検知に対応していますが、リアルタイムで監視すべきアクティビティの量が膨大であるため、これも無償プラットフォームで提供するには採算が合わない機能でした。

• セキュリティリスクを高めることなく、開発チームおよびクラウドチームにかかるセキュリティ上の摩擦とオーバーヘッドを軽減する。
• コンテナを用いて展開する際のセキュリティ侵害のリスクを低減する。
• 標準的な API とデータ構造により、クラウドセキュリティを自社のプログラムに統合する時間を短縮する。

これらの成果はいずれも、インフラ、サポート、または開発のコストの観点から、無償製品では十分に対応できないと判断したコストや複雑性を伴うものでした。

機能セットのパッケージ化

望ましい成果とコスト分析を組み合わせることで、どの機能をパッケージ化するかを決定できました。

• 1 日 1 回のスキャン
• 30 日間の履歴を備えたリソースインベントリ
• セキュリティチェックのフルスイート
• 基盤となるコンプライアンスレポート
• Slack 連携
• 現時点では AWS、プラットフォームの更新に伴い Azure および GCP

これらは必ずしも容易な判断ではありませんでした。たとえば、30 日間のインベントリでもコストは発生しますが、設定ミスのレポートを提供するだけでは、ユーザーの可視性のニーズに十分応えられないと考えました。また、セキュリティチェックを制限したり、コンプライアンスレポートのために商用製品への移行を求めたりすれば、十分な成果を提供できない製品になってしまうと判断しました。

この組み合わせは、セキュリティの中核的な可視性に関する望ましい成果と、レポーティングの改善および修復期間の短縮の両方をもたらすコミュニケーションの成果に対応するものです。そして、これらは人々が最初にクラウドセキュリティの OSS ツールを作って対処しようとした望ましい成果であり、Cloud Security Posture Management 市場全体の起点でもあるため、ここに価値があることは確かです。

JTBDフレームワークは、単に組み合わせても本当に誰の役にも立たないような機能をいくつか切り出すのではなく、お客様の成果を向上させることに焦点を当て続けるうえで大いに役立ちました。その結果として、実際の価値を提供しながら、長期にわたって提供を継続できるほどコスト効率の高い無償プラットフォームが実現したと考えています。

ぜひお試しいただき、ご意見をお聞かせください。 FireMon Cloud Defenseは現在も進化を続けており、クラウドセキュリティ担当者の業務遂行を支援する当社の能力を高めるための優れた手段です。