実践セキュリティ監視基盤構築(4): セキュリティ監視は内製するべきか
この記事はアドベントカレンダー実践セキュリティ監視基盤構築の4日目です。
このアドベントカレンダーではセキュリティ監視基盤を内製することを前提としていますが、セキュリティ監視基盤を内製するべきかどうかは、組織や事業規模、技術スタック、人材のスキルセットなどによって異なります。この記事では、セキュリティ監視基盤を内製するべきかどうかについて考察します。
既製と内製の比較
前回の記事で既製と内製のコスト比較について説明しましたが、今回は全体的な比較を以下の表で整理しました。やや大雑把な比較ですが、既製と内製の違いを理解するための参考にしてください。
| 既製プロダクト・サービス | 内製 | |
|---|---|---|
| メジャーなログの収集 | ✅ プラグインなどが揃っており容易に取り込める | 🟡 取り込みのために都度開発が必要 |
| マイナーなログの収集 | 🟡 拡張機能が用意されているが、対応できるとは限らない。製品・サービス自体を拡張しなければならない場合が多い | 🟡 開発は必要だが自分たちの都合で開発できる |
| ログスキーマの管理 | ✅ メジャーなものについては概ね管理されているので比較的楽 | 🟡 原則自分たちで管理しなければならず、ログの種類が増えるほど大変になる |
| 導入コスト（開発） | ✅ 導入設定なども簡略化されている場合が多く、スムーズに導入しやすい（ただしプロダクトによってはこの時点でライセンス料が発生する場合あり） | ❌ ほぼすべて作業しなければならないため、非常に工数がかかる |
| 運用コスト（開発） | ✅ 機能追加なども提供されている枠組みで実現できる | 🟡 機能追加には開発が必要で、トラブル対応が既製プロダクト・サービスに比べて多い |
| 運用コスト（システム） | ❌ 商用の場合、従量課金が高く内製の10〜1000倍の価格帯になることが多い。OSSでもインスタンスの利用が前提となるので高額になりやすい | ✅ クラウドプラットフォームを適切に利用して作れば大幅にコストを下げられる |
| 拡張性・柔軟性 | 🟡 セキュリティ監視のユースケースで設計されているものの、組織都合の細かい要求に答えきれないケースもある | ✅ 自分たちの制御下にあるので自由に拡張させたり、他システムと連携することができる |
- ✅ 問題なく対応できる
- 🟡 一部対応できるが課題はある
- ❌ 多大なコストがかかるなど大きな課題がある
ログの収集、管理
まず、ログの収集や管理の観点から見ると、既製プロダクトやサービスが圧倒的に優位です。特にクラウドサービスを利用する場合、メジャーなサービス・アプリのログを取り込むのであれば、ほぼノーコストで導入し、運用開始まで持っていくことができます。既製プロダクトを利用する場合、環境の構築にやや手間がかかることもありますが、それでも内製に比べると圧倒的に楽です。また、ログスキーマの管理についても、既製プロダクトやサービスが優位です。メジャーなログについてはログスキーマの管理がされていることが多く、自分たちで管理しなければならない内製に比べると容易に運用できます。
一方で内製の場合、ログの取り込みやスキーマ管理については、全て自分たちで開発・運用する必要があります。新しいログの取り込みをする場合も開発や作業が発生し、これは既製プロダクト・サービスに比べると確実に重くなります。また、ログの種類が増えるほど、スキーマの管理も大変になります。
既製プロダクト・サービスのほうがログの収集や管理においては優位であると言えますが、マイナーなサービス・アプリや独自のログを取り扱う場合、柔軟に対応しにくいというのが注意点です。既製でも何らかの拡張機能が用意されていることがほとんどですが、その拡張機能で要件を満たせない場合もあります。その場合は開発元にリクエストを出すなどの対応が考えられますが、対応できないケースも考慮する必要があります。
導入、運用コスト
コストについては「セキュリティ監視基盤をいつから始めるか」でも取り上げましたが、既製プロダクト・サービスの場合、導入コストは比較的低いと言えます。導入設定なども簡略化されている場合が多く、スムーズに導入しやすいです。ただし、プロダクトによってはこの時点でライセンス料が発生する場合もあるので、その点は注意が必要です。運用コストについても、機能追加なども提供されている枠組みで実現できるため、比較的低いと言えます。
内製の場合、そもそもセキュリティ監視基盤全体の構築をしなければならず、開発の規模感が一段階大きくなります。後述しますが、構築のためにも一定のスキルを持った人材が必要になるため、人材の確保と工数の両方の視点からコストがかかると言えます。
一方で運用コストについては、内製が大きく有利となりやすいです。既製プロダクト・サービスの場合、商用の場合は従量課金が高く、内製の10〜1000倍の価格帯を見込む必要があります。OSSの場合でもインスタンスなどの計算およびオンラインストレージリソースを常時稼働させることが前提となるものが多く、商用サービスほどではないものの、内製の数倍以上はコストを見込んだほうが良いでしょう。内製の場合は、クラウドプラットフォームを適切に利用して作れば大幅にコストを下げられるため、運用コストは低く抑えられ、これが内製を選択する大きなメリットの一つと言えます。
拡張性・柔軟性
内製をするもう一つの大きなメリットが拡張性・柔軟性です。既製プロダクト・サービスは一般化されたユースケースをもとに機能が実装されており、多くのセキュリティ監視の場面で役立ちます。しかし、組織都合の細かい要求に答えきれないケースもあります。内製の場合、自分たちの制御下にあるので自由に拡張させたり、他システムと連携することができます。これは実現したいユースケースを幅広く対応するだけでなく、非機能的な要件である、ログの保全期間、アラート検知のための許容遅延、アラート対応のSLOなどにも柔軟に対応しやすくなります。
また近年、ソフトウェア開発のベストプラクティスをセキュリティ監視の世界に適用する Detection Engineering [1] という概念が提唱されています。これは、特に検知に関するルールの管理、テスト、CI/CDをソフトウェア開発のように設計・実装することで、セキュリティ監視の業務をより効率的にするという考え方です。内製の場合、このような新しいアプローチを取り入れやすく、セキュリティ監視の効果を高めることができるでしょう。
内製するために必要なスキル
このアドベントカレンダーでいう内製とは、クラウドプラットフォーム（AWS、Google Cloudなど）を活用してセキュリティ監視基盤を構築することを指します。そのため、内製するためには様々な知識や経験、技能が必要となります。ここではこれらをまとめてスキルと呼びます。このようなスキルを持つ人材を基盤構築のために確保、あるいは協力を求めることができるかどうかも、内製するかどうかの判断材料となります。
クラウドプラットフォームに関するスキル
まず、クラウドプラットフォームに関するスキルが必要です。クラウドプラットフォームを活用してセキュリティ監視基盤を構築するためには、そのプラットフォームのサービスの種類、特性、使い方を理解しつつ、さらにサービスの組み合わせ方やアーキテクチャ、設計のベストプラクティスなどについて理解している必要があります。たとえクラウドプラットフォームを使っていたとしても、サービスの適切な利用や設計がなければ逆にコストが嵩んでしまうということもありえます。クラウドプラットフォームの各種サービスを有効に活用できてこそ、低コストかつ拡張性や柔軟性を備えたセキュリティの監視基盤を構築することができます。
ソフトウェアエンジニアリング（プログラミング）に関するスキル
次に、ソフトウェアエンジニアリングに関するスキルもある程度必要です。セキュリティ監視基盤を構築するためには、ログの収集、分析、アラート検知、対応などの機能を実装する必要があります。これらの機能はクラウドプラットフォームのサービスやOSSを利用することで一部を実現できますが、それらでサポートされていない部分については自分で実装をする必要があります。
機能の大部分はマネージドサービスなどで実現するため、大規模ソフトウェアの開発は必要ありません。しかし取り扱うデータの規模が大きいため、効率的に処理するための工夫や、データの取り扱い方法は全体のパフォーマンスに大きな影響を与えます。その観点から、ソフトウェアエンジニアリングのスキルが一定程度必要となります。
データエンジニアリング（DWHの構築）に関するスキル
セキュリティ監視基盤のログの収集、分析について内製するのは、いわゆるデータウェアハウス（DWH）の構築とほぼ同じような機能となります。そのため、大規模データを扱うためのデータエンジニアリングのスキルも必要です。データの取り込み、加工、分析、可視化などのプロセスを設計し、実装するためのスキルが必要です。
大規模データの取扱は実践してみないとわからないことも多く、特に知識と経験が必要となる分野です。データの処理や保存方法はシステムの利用コストに大きく影響するため、適切なアーキテクチャと設計が求められます。さらに一度貯めたデータをあとから別のアーキテクチャに移行することは作業的にもコスト的にも非常に困難であるため、なるべく初めから適切な設計を考えなければなりません。そのため、データエンジニアリングのスキルを持つ人材の協力があるととても助けになります。
結局どちらが良いのか
既製プロダクト・サービスと内製の比較をしてきましたが、結局どちらが良いのかというのは、組織の事情や状況によって異なります。あくまでひとつの見解にはなりますが、以下のような観点で判断しても良いかと思います。
- 既製プロダクト・サービスを選ぶべき場合
- セキュリティ監視をなるべく早く始めたい
- セキュリティ監視のユースケースが一般的
- 監視対象とするログがメジャーなものであり、流量もそれほど多くない（例：1日あたり数GB程度）
- セキュリティ監視を専任でできる人材がいない
- 内製を選ぶべき場合
- セキュリティ監視を長期的に継続してスケールさせたい
- セキュリティ監視を多様なユースケースに対応させたい
- 監視対象とするログがメジャーでないものが多い、あるいは流量が多い（例：1日あたり100GB以上）
- セキュリティ監視を専任でできる人材がいる
- セキュリティ監視基盤構築をできる人材がいる
まとめると、組織そのものやセキュリティ対策がまだ成熟していないうちは、既製プロダクト・サービスを利用してセキュリティ監視を始め、その後内製に移行するというのも一つの方法です。既製プロダクト・サービスを利用することで、セキュリティ監視の効果を早く得ることができます。その後、コストや要件などが実情に合わなくなってきたタイミングで内製に移行することで、より多様なユースケースに対応したセキュリティ監視基盤を構築することができます。移行のコストが必要になるという課題はありますが、効果的なステップの一つと言えると思います。
内製の実例
ここまでの話で、現実的にはセキュリティ監視基盤の内製の難易度が高いということを述べてきましたが、実際に内製を行っている企業もあります。以下にいくつかの事例を紹介します。
- Mercari: Detection Engineering and SOAR at Mercari
- Sansan: Sansan の成長を支えるセキュリティログの活用と Amazon Elasticsearch Service
- LayerX: SIEMからデータ基盤へ - Amazon Security Lakeを試してる話
- IERAE: IERAE DAYSトークセッションレポート 「イエラエが、今、SOCサービスを始める意義」
- Cookpad: Amazon Athena を使ったセキュリティログ検索基盤の構築
まとめ
セキュリティ監視基盤を内製するべきかどうかは、組織や事業規模、技術スタック、人材のスキルセットなどによって異なります。既製プロダクト・サービスと内製の比較を行い、内製するために必要なスキルについても触れました。組織の事情や状況によって異なりますが、既製プロダクト・サービスを利用してセキュリティ監視を始め、その後内製に移行するというのも一つの方法なので、あわせて検討してみると良いかと思います。
Discussion