クラウドネイティブセキュリティに関する3つの誤解を解く

多くの組織が積極的にクラウドを導入していることは明らかです。しかし、疑問は、彼らがクラウドを完全に理解しているかどうかです。クラウドに構築されたアプリケーションを保護する方法を知っていますか?あらゆる新興テクノロジーと同様に、神話や誤解が自然に生じます。

セキュリティに関しては、ほんの小さなミスでも侵入やサイバー攻撃につながり、組織に多大な損害を与える可能性があります。このような事態が発生する可能性を最小限に抑えるには、クラウド ネイティブ セキュリティに関する最も一般的な誤解と対策を理解し、組織が不必要なリスクを回避できるようにすることが重要です。

クラウドネイティブの誤解がセキュリティを損なわせないようにする

より強固なセキュリティ体制を構築するための最初のステップは教育です。クラウド ネイティブ環境で何をすべきかを知ることと同じくらい、何をすべきでないかを知ることも重要です。

この記事の目的は、クラウド ネイティブ セキュリティに関する最も一般的な誤解を解き、実用的なアドバイスを提供することです。

誤解1: クラウドプロバイダーがすべてのセキュリティ対策に責任を持つ

多くの組織では、アプリケーションがクラウド サービス プロバイダー (CSP) でホストされているため、CSP がすべてのセキュリティ対策を提供していると想定していますが、これは事実ではありません。実際には、クラウド サービス プロバイダーと組織がセキュリティの責任を共有します。

簡単に言えば、CSP はアプリケーションが実行されるインフラストラクチャを保護し、組織はアプリケーション内のアクティビティとデータを保護する責任を負います。 CSP は、実行するコンピューティング、ストレージ、データベース サービスのセキュリティを確保します。 CSP は、多くのアプリケーションが同じサーバーを共有するマルチテナント モデルを採用しているため、企業間のハード分離も実現します。

クラウド プロバイダーは、組織のアプリケーション内でセキュリティ対策を実施することはできません。これは、各組織がアプリケーションを構築し、ストレージ スペースを使用し、システムを構成する方法がそれぞれ異なるためです。つまり、CSP がアプリケーション内セキュリティに対して万能のソリューションを用意することは不可能です。 AWS Control Tower など、一部のプロバイダーはすぐに使用できるセキュリティ機能を提供していますが、組織は追加料金を支払い、多くのカスタマイズを行う必要があります。

クラウドを使用するすべての組織は、アプリケーションと、オペレーティング システム、ソース コード、データを含むすべてのコンポーネントのセキュリティに責任を負います。組織が実行できる最も強力なセキュリティ対策の 1 つは、認証によるアクセス制御を実装することです。承認により、ユーザーやその他のテクノロジは、必要なときに必要なシステムとデータにのみアクセスできるようになります。認可を実装する方法について説明します。

誤解2: オンプレミスのセキュリティ対策をクラウドネイティブ環境でも使用できる

組織が犯すもう一つのよくある間違いは、オンプレミス環境からクラウドにセキュリティ対策をそのまま移行しようとすることです。ファイアウォールやブラウザ分離システムなどの境界ベースのセキュリティ対策はクラウドでは機能しません。ネットワークはもはや周囲に障壁を設置することで保護できる静的な環境ではなくなったためです。

代わりに、ハッカーがネットワークに侵入した場合にデータを安全に保つことに重点を置く必要があります。ここでも、アクセス制御と承認が役に立ちます。ただし、境界ベースのセキュリティと同様に、従来のオンプレミスのアクセス制御手段はクラウドには適用できません。

マイクロサービス アーキテクチャ、コンテナ化されたアプリケーション、アプリケーション プログラミング インターフェイス (API) により、独自の承認ポリシーとセキュリティ構成を必要とする個々のコンポーネントが劇的に増加しています。シングル サインオン、SAML、OIDC、OAuth2 などの従来のテクノロジーは、アプリケーションの認証の解決に役立ちますが、承認の解決には役立ちません。承認は依然として開発者に依存しています。

クラウド ネイティブ環境では、ポリシーをコードとして使用する必要があります。ポリシーをコードとして使用するということは、標準的なソフトウェア エンジニアリング手法を適用して、システムのルールと条件 (バージョン管理、コード レビュー、自動テスト、継続的デリバリーなど) を管理することを意味します。ポリシーをコードとして使用すると、ポリシーはアプリケーション クラウド プラットフォームから切り離されるため、アプリケーション コードを変更せずにポリシーを変更できます。ポリシーがコードとして分離されているため、チームによるポリシーの作成、拡張、監視、監査、共同作業が容易になります。

誤解3: 戦略の実行にはカスタムソリューションが必要

最後の神話は現実に由来しています。かつては個別のカスタム ポリシーを作成することがアクセスを制御する唯一の方法でしたが、今ではそうではありません。既存のテクノロジーにより、組織は多くのクラウドネイティブ アプリケーション、サービス、プラットフォームにわたって統一された承認ポリシーを適用できます。

組織が依然としてこの信念を抱いている理由は理解できます。ソフトウェア開発では、組織ごとにシステムやインフラストラクチャの構成が異なるため、問題を解決するために 1 回限りのカスタム ソリューションを作成することがよくあります。長年にわたるライセンス戦略についても同様です。しかし、クラウドネイティブ環境では、独立したコンポーネントの数が多いため、この方法でポリシー実行を処理すると、時間がかかり、面倒で、エラーが発生しやすくなります。

新しいポリシー要件のセットごとにカスタム ソリューションを実装するのではなく、ポリシーをコードとして利用してポリシー決定をビジネス ロジックの残りの部分から分離することを検討し、クラウド ネイティブ スタック全体で統合された承認を効率的に適用および拡張するのに役立つ追加のテクノロジを活用します。

Open Policy Agent (OPA) は、ポリシーをコードとして記述および検証できるオープン ソース ポリシー エンジンです。 Styra は 2018 年にこれを Cloud Native Computing Foundation に寄贈し、2021 年に卒業ステータスに達しました。OPA により、組織はクラウド ネイティブ テクノロジー スタック全体で同じ言語とポリシー フレームワークを使用できるため、ポリシーの作成と継続的なガバナンスが簡素化されます。ポリシーは、複雑な階層型データ構造に対するポリシーを表現するために特別に構築された Rego で記述されます。また、オープンソースであるため、組織が開発者向けのツールや統合にアクセスできる豊富なエコシステムと、アドバイスを提供できる実践者のコミュニティが存在します。

原題:クラウドネイティブセキュリティの 3 つの神話を暴く、著者: Torin Sandall