クラウドネイティブセキュリティの5つの重要な要素

「クラウド コンピューティング」という用語はかつてテクノロジー業界の議論の定番でしたが、「クラウド ネイティブ」と「クラウド ネイティブ セキュリティ」がその代わりになっています。ますます多くの組織がクラウドで IT とセキュリティを構築し始めていますが、注意すべき要素は数多くあります。組織がさまざまな要素を理解しようとする場合、考慮すべき重要な要素が 5 つあります。

1. クラウドネイティブセキュリティはクラウドアクセスセキュリティブローカーとは無関係です

人々がクラウドでの作業に重点を置き始めると、多くの組織はビジネス モデルを切り替えて、サービスとしてのソフトウェアの使用を開始する必要があることに気付きました。この変化の結果、パブリック クラウドのセキュリティに関する懸念が生じ、Salesforce データなどのタスクの処理によく使用されるクラウド アクセス セキュリティ ブローカー (CASB) の時代が到来しました。

これはクラウドの初期の頃には当てはまるかもしれませんが、近年発展してきた別のテーマとは関係ありません。最近では、顧客を引き付け、新しいビジネス モデルを実現するために優れた新しいソフトウェアを作成する必要があるため、より多くのソフトウェア開発チームが実稼働クラウド ソフトウェアの開発に移行しています。これらすべては、「すべての企業がソフトウェア企業になりつつある」というテーマを強調しています。

ただし、顧客向けのアプリを構築し、データを漏洩する Equifax になりたくない場合は、アプリにさらにセキュリティを追加する必要があります。これはクラウドネイティブ セキュリティであり、クラウド アクセス セキュリティ ブローカー (CASB) の役割とは根本的に異なります。どちらもクラウド コンピューティングに関連していますが、解決する問題は完全に異なります。

2. クラウドネイティブセキュリティは、既存のアプリケーションのプロアクティブな脅威保護対策に代わるものである

企業がクラウドネイティブ ソフトウェアをどのように保護するかという問題に初めて直面したとき、最初の対応は既存のセキュリティ ツールを使用することです。これは選択肢の一つですが、効率が異なり、企業は多くの手動操作を実行する必要があります。そうしないと、企業が直面するリスクが企業のイノベーションのボトルネックになります。

次のセキュリティ概念は、クラウド ネイティブの世界では適用が困難です。

• IT チームに各製品アップデートの部品表を確認してもらい、コンプライアンスを検証してもらいます。
• 開発チームと運用チームが協力して仮想マシンを構築することで、ソフトウェアへの頻繁な変更や修正によって問題が発生するリスクなしに、仮想マシンを迅速に移行できるようになります。
• IT チームがパッチを適用し、仮想マシンを更新し、すべての環境が本番環境に適していることを確認できるようにします。
• 開発者と運用チームは、自分たちでパッチを適用できるように DevOps をセットアップします。

（１）ウェブサイトセキュリティ保護（WAF）の役割

企業では、ワークロードが攻撃されるのを防ぐために、Web サイト ファイアウォール (WAF) を使用することがよくあります。すべての変更に加えて、Web サイト セキュリティ ファイアウォール (WAF) を実行している人は、すべてのマイクロ ワークロードを追跡することが困難になっています。

（２）ネットワークのセグメンテーション

企業は、脆弱性をもたらす可能性のあるワークロードを分離するために、ネットワークをセグメント化またはマイクロセグメント化しようとした可能性があります。これは素晴らしい概念ですが、実際には小規模なアジャイルワークロードでは機能せず、ルールに従わなければネットワークセグメンテーションは効果がありません。

しかし、クラウドネイティブ セキュリティの適用範囲は根本的に拡大しています。アプリケーションに関する詳細な情報が含まれており、それを使用して以下で説明するすべての要素を自動化します。

自動化により、企業はより強力できめ細かいセキュリティを実現できるようになり、ワークロードが変更/更新されるたびにセキュリティ メカニズムを手動で構成するのではなく、アプリケーションに基づいてセキュリティ ポリシーを表現することに集中できるようになります。また、企業はポリシーを最新の導入ツールに統合し、開発者と直接話し合うことも可能になります。

3. クラウドネイティブセキュリティには依然として多層防御が必要

従来のセキュリティの観点からすると、企業は複数層のセキュリティを考えます。企業は、コード セキュリティ、パッケージ管理、オペレーティング システム パッチ、サーバー エンドポイント セキュリティなどの側面を考慮する場合があります。しかし、今ではこれらはもう必要ありません。しかし、クラウド ネイティブ ワークロードを使用しても、この観点からは近道にはならないことを理解することが重要です。企業は、この観点から、依然としてソフトウェアを必要なすべてのセキュリティ レイヤーでラップする必要があります。

4. クラウドネイティブセキュリティはエンドツーエンドのセキュリティです

DevOps の適用により、従来の専門チームは 2 つのカテゴリに分けられます。1 つはマイクロサービスを展開する開発者であり、もう 1 つはクラウド コンピューティング専用のインフラストラクチャ チームです。多くの場合、これら 2 つのチームでさえ、複数の責任を負う単一の「クラウド」チームになります。

この環境のセキュリティを考慮すると、次の 2 つのグループに分ける方が合理的です。

• （1）クラウドネイティブインフラストラクチャ：これには、エンタープライズクラウドで使用されるサービスのセキュリティ（L3-4ファイアウォール、サーバーセキュリティ、ネットワーク暗号化、ストレージ暗号化など）が含まれます。
• （2）クラウドネイティブアプリケーション：これには、アプリケーションの認識を必要とするセキュリティ要素（L7ファイアウォール、セキュリティ侵入テスト、イメージセキュリティ、アプリケーションのマイクロセグメンテーションなど）が含まれます。

これにより、市場で目にするセキュリティ製品の種類が変わります。クラウド コンピューティング ベンダーは、プラットフォームの魅力を高め、インフラストラクチャのセキュリティに関するあらゆるニーズに対応する包括的な製品を提供するために、クラウド サービスに従来のインフラストラクチャ機能をさらに追加します。一方、セキュリティ プロバイダーは、主にアプリケーション レベルのセキュリティに重点を置き、エンドツーエンドのセキュリティ ソリューションも提供する必要があり、これには前述の複数の要素も含める必要があります。

5. クラウドネイティブセキュリティはクラウドチームによって運営される

従来、セキュリティ レイヤーには、さまざまな人またはチーム (エンドポイント、サーバー、ネットワーク、ID、PKI、ストレージ、ソフトウェア開発など) の専門知識が必要でした。企業は、インフラストラクチャが割り当てられ、アプリケーションが展開されるときに、これらのセキュリティ レイヤーを手動で追加し、チーム内の専門家に依頼して必要なクラウド コンセプトを構成することができます。しかし、これらのリソースの割り当ては即時に行う必要があり、セキュリティの提供も改善する必要があります。

クラウドネイティブ セキュリティは大きな変化をもたらしました。セキュリティ層に関するポリシーは、セキュリティおよびインフラストラクチャ アーキテクトによって定義される必要があると判断されます。ただし、これらのポリシーを適用するためのセキュリティ メカニズムは、クラウドおよびプロビジョニング プロセスに自動的に接続される必要があります。これにより、DevOps チームまたはクラウド チームが可能な限りシームレスに運用できるようになり、プロセス全体が完全に完了します。