実践クラウドセキュリティ 第2版

第5章 脆弱性管理 脆弱性管理

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

ギリシャ神話では、アキレスは唯一の弱点であるかかとに矢を受けて死んだ。アキレスには明らかに、より優れた脆弱性管理計画が必要だった！¹ 脆弱な部分が1つしかなかったアキレスとは異なり、クラウド環境には脆弱性が現れる可能性のあるさまざまな領域が存在する。アクセス制御をロックダウンした後、潜在的な脆弱性を管理するための継続的なプロセスをセットアップすることは、通常、セキュリティを向上させるためにできる、集中力、時間、お金をかけた最善の投資である。

脆弱性管理とパッチ管理にはかなりの重複がある。多くの組織にとって、パッチをインストールする最も重要な理由は、機能のバグを修正したり機能を追加したりすることよりも、むしろ脆弱性を修正することである。 また、脆弱性管理とコンフィギュレーション管理にはかなりの重複がある。なぜなら、たとえすべてのセキュリティパッチを忠実にインストールしたとしても、誤ったコンフィギュレーションが脆弱性につながることがよくあるからだ。脆弱性、コンフィギュレーション、パッチを管理するためのツールやプロ セスは、それぞれ異なることがあるが、実用性の観点から、この章ではこれらをまとめて取り 扱うことにする。

残念ながら、脆弱性管理は、自動パッチ適用をオンにして立ち去るほど簡単なものではない。 クラウド環境では、脆弱性は物理的な設備、計算ハードウェア、オペレーティングシステム、あなたが書いたコード、あなたが入れたライブラリなど、様々なレイヤーで発見される可能性がある。第1章で説明したクラウド共有モデルは、クラウドプロバイダーが脆弱性に対してどのような責任を負っているかを理解するのに役立ち、本章の内容は責任を管理するのに役立つ。ほとんどの場合、異なるタイプの脆弱性に対処するために、いくつかの異なるツールやプロセスが必要になる。

脆弱性管理とパッチ管理

脆弱性管理」と「パッチ管理」という言葉はしばしば同じ意味で使われるが、両者は異なる。ソフトウエアのパッチは、セキュリティ上の脆弱性に加えて機能上の問題も修正することが多く、また、すべての脆弱性がパッチの適用によって修正されるわけではない。例えば、脆弱性管理プロセスは、パッチを適用せずに修正される安全でない設定を特定するかもしれないし、パッチを適用するのではなく、機能をオフにすることによって脆弱性を緩和するかもしれない。

従来のITとの違い

クラウド環境では、オンプレミスと比べて変化の速度がはるかに速いことが多く、こうした絶え間ない変化によって、従来の脆弱性管理プロセスが埃をかぶってしまう可能性がある。第3章で議論したように、新しいシステムがオンラインになったときにそれを見逃さないように、クラウドAPIからのインベントリを使用して、各システムが作成されるたびに脆弱性管理ツールに投入する必要がある。

変化の速度に加え、コンテナやサーバーレスホストなど、現代の一般的なホスティングモデルは、既存のツールが適用できないか効率的でないため、脆弱性管理の方法を変える。コンテナをたくさん使っている場合、仮想マシンのようにCPUの数パーセントを使うようなヘビー級の脆弱性管理ツールをすべてのコンテナに入れることはできない。 おそらく、システム上でエージェントのコピーを何百も実行することになり、実際の作業のためのCPU時間は残らないだろう！

さらに、継続的インテグレーション（CI）、継続的デリバリ（CD）、マイクロサービスアーキテクチャでは、クラウドコンピューティングとは別のものであるにもかかわらず、クラウドの採用とともに発生することが多い。これらのテクニックを採用することで、脆弱性管理も根本的に変わる可能性がある。 ...