クラウドの方が安全なのに、なぜまだハッキングされるのでしょうか?

経験豊富なセキュリティ専門家なら誰でも知っているように、実行中のコンテナの多く、あるいはほとんどには、高リスクまたは深刻な脆弱性があります。さらに不可解なのは、これらの脆弱性の多くにはすでにパッチが用意されており、修正できる可能性がある（しかし、修正されていない）ことです。しかし、クラウドはもっと安全であるべきではないでしょうか?

クラウドでも悪い習慣は続く

ローカル情報システムをクラウドに移行しても、元の作業環境やプロセスが即座に効率的かつ使いやすくなるわけではなく、ましてや安全になるわけでもありません。実際、セキュリティはビジネスを遅らせたり、ビジネスに影響を与えたりする傾向があるため、人々が対処したくない最後の問題であることがよくあります。

多要素認証 (MFA) を例に挙げてみましょう。情報システムへの安全なアクセスのために MFA を実装する必要があることを知っている、または少なくとも聞いたことがある人は多すぎます。セキュリティ会社 Falcon の Sysdig のデータによると、48% の組織がルート権限を持つアカウントに対して MFA を有効にしていないことがわかりました。さらに、27% の組織が管理タスクにルート アカウントを使用していますが、これは明らかにすべてのセキュリティ ベンチマーク推奨事項に違反しています。

アイデンティティとアクセス管理 (IAM) は、最も重要なクラウド セキュリティ制御の 1 つであり、これを中心に新しいクラウド ネイティブ プロセスを開発する必要があります。クラウド チームは、特定のタスクに適した IAM ロールを作成し、追加の権限を禁止し、ロールについてユーザーをトレーニングする必要があります。いずれにせよ、MFA を有効にしてください。

不完全な安全シフトレフト

複雑なプロセス変換には時間がかかり、通常は段階的に実行されます。データによると、イメージの 48% は、デプロイされて実行される前に、まず CI/CD パイプラインまたはコンテナ レジストリの脆弱性がスキャンされます。

このデータは、多くの企業が「セキュリティを左にシフト」し始めたことを意味します。しかしその一方で、より多くの企業 (52%) がイメージの実行中に最初のスキャンを実行し、潜在的に重大な脆弱性の発見が遅れることを意味します。

その理由の 1 つは、時間を節約するためにセキュリティ評価を延期する傾向が依然としてあることです。もう 1 つの考えられる説明は、ワークロードのサブセットが「シフトレフト」タスクに含まれていないということです。具体的には、組織によって作成されたカスタム コードを含まない多くのサードパーティ アプリケーションがこのカテゴリに分類されます。たとえば、Kubernetes コンポーネント、Web サーバー、ロード バランサーは、ソフトウェア テスト フェーズが完了してからかなり経ってから構成される場合があります。

どちらの場合も、「シフトレフト」は発生していますが、完了していません。最も先進的なチームは、CI/CD パイプラインを使用して、ホスト、クラスター、コンテナーなどのデプロイメント マニフェストなどのインフラストラクチャ コンポーネントを含むすべてのワークロードのセキュリティをテストしています。

リスクも左にシフトするべき

リスクの受容について話すとき、私たちは通常、それを最後の手段として考えます。 「現時点では何もできないので、ただ書き留めて神に委ねるだけです。」

ただし、リスクの原因を早期に特定すればするほど、リスクに対する効果的な軽減策を講じられる可能性が高くなります。重大な脆弱性のあるコンテナを実行することになる可能性もありますが、それらの脆弱性に関連するリスクを積極的に検討し、リスクを軽減するための制御を実装すれば、セキュリティ体制はそれほど悪くないかもしれません。

ソフトウェア サプライ チェーンのセキュリティに対する懸念が高まる中、自社のソフトウェアでは使用されていない可能性のあるサードパーティ コンポーネントにランタイム脆弱性がいくつ存在するかを検討する価値があります。

ソフトウェア配信プロセスの早い段階で脆弱な依存関係を特定することで、多くの時間を節約し、リスクの露出を大幅に減らすことができます。すべての脆弱性を修正することはできませんが、追加のセキュリティ制御によって多くの脆弱性を管理できます。少なくとも、簡単に確認できるように文書化する必要があります。

レビュー

現在、クラウドでは数十億のコンテナが稼働しています。この数は今後も増加する一方であり、同様に攻撃対象領域と潜在的なリスクも増加するでしょう。実際、新しいツールや新しい環境はイノベーションの機会であると同時に、「技術的負債」の始まりとなることも少なくありません。しかし、過去の経験と教訓からこの問題を認識しているのであれば、なぜ最初からペースを落としてセキュリティをしっかり早期に実施できないのでしょうか?これがクラウド ネイティブ セキュリティの中心的な原動力です。