fbpx

クラウド環境でもセキュリティの不安をなくす方法を徹底解説

好きな所から読む

大手IaaSプロバイダーの自動化、プログラム化されたインフラストラクチャ、および組み込みのセキュリティ機能により、企業はパブリッククラウドのインフラ構成を改善し、規模を迅速に拡大することができます。適切に管理されていれば、パブリッククラウドであってもデータセンターよりも優れたセキュリティをクラウドで確保することができます。尚、本記事ではゼロトラストという考え方に則った形でセキュリティを強化する内容になっています。ゼロトラストの原理や原則をより詳しく知りたい方はこちらもご覧ください。

概要

業務上顕在化する課題課題

  • パブリッククラウドの採用とプロビジョニングのスピードは、必然的に組織の能力を上回る複雑さの拡大につながり、運用上未知のリスクにつながっています。
  • パブリッククラウドで発生した攻撃の多くは、顧客の設定ミスやミス、管理ミスによるものであり、クラウドプロバイダーのセキュリティ保護責任の根本的な失敗によるものではありません。
  • 従来のエンタープライズ・データセンターのセキュリティ・フレームワークは、パブリッククラウドへの適用が難しく、結果的にクラウドコンピューティングの導入が遅れたり、使用時の安全性が低下したりすることになります。
  • 従来のセキュリティベンダーは、パブリッククラウドの導入に遅れをとっており、その提供するサービスがクラウドプロバイダーの組み込み機能と重複していることが多く、顧客の混乱を招いています。

クラウドでセキュリティを強化するための必須項目

クラウドのセキュリティを向上させるためには、セキュリティとリスク管理のリーダーが次の項目を実現するべきです。

  • 攻撃対象のエリアを減らすための基礎的な方法としてID管理を使用する。
  • ネットワーク、ストレージ、コンピュート、PaaS サービスの構成基準を確立する。
  • 継続的なクラウド・セキュリティ態勢管理(CSPM)機能を導入する。
  • クラウドネイティブなモニタリングサービスを使用して、すべてのクラウド活動を広範囲に可視化し、リスクを分析する。
  • ワークロードを制御するシステムを使用して、仮想マシン(VM)とコンテナを内部から保護する。
  • すべてのアプリケーションをスキャンしてコードの脆弱性を調べ、実行時にクラウドネイティブ保護を使用する。
  • 漏洩した機密データやマルウェアなどのデータ関連のリスクを継続的にスキャンする。
  • すべてのクラウドインフラを追跡して、攻撃や違反を示す異常な動作がないかどうかを確認する。
  • クラウドネイティブな機能とベンダーを重視し、クラウドネイティブの考え方を採用する。
既存のシステムやネットワーク構成を生かしつつゼロトラストを実現するにはクラウド上のID基盤が必要です。
多要素認証でより堅牢になったゼロトラストソリューションが気になる方はLOCKEDのサービス概要もご覧ください。

戦略的計画の前提条件

2021年までに、50%の企業が知らず知らずのうちに、あるいは誤って、一部のIaaSストレージサービス、ネットワークセグメント、アプリケーション、またはAPIをパブリックインターネットに直接公開することになる。そして2023年までに、クラウドで発生するセキュリティインシデントの少なくとも99%が顧客の責任となる。さらに2024年までは、クラウドインフラのセキュリティ保護を向上させるワークロードは、従来のデータセンターと比較して、コンプライアンスの向上とセキュリティインシデントが少なくとも60%減少することが実証される。

はじめに

クラウドは安全です。基本的に、主要なクラウド・プロバイダーのセキュリティ姿勢は、ほとんどの企業データセンターと同等かそれ以上であると結論づけています。また、セキュリティだけがパブリック・クラウド採用の主な阻害要因であると考えるべきではないという結論に達しました。

勿論、オンプレミスのワークロードをパブリッククラウドに移行したからといって、自動的にワークロードのセキュリティが向上するわけではありません。しかし主要なパブリッククラウドのIaaSプレイヤーは、適切に活用すれば従来の企業データセンターよりも優れたセキュリティ機能を備えています。

オンプレミスのデータセンターと同様に、クラウドに対して発生しているセキュリティインシデントの大半は、設定ミス、パッチの欠落、インフラストラクチャの資格情報の管理ミスなどのミスによって引き起こされます。この記事では、パブリック・クラウドのIaaSを利用して、ワークロードを従来のデータセンターよりもセキュアにする方法の核心に迫ります。IaaSコンピューティングとネットワークファブリックから利用可能なビルトインセキュリティ機能と高度な自動化機能を明示的に活用することで、企業は誤設定、誤管理、ミスの可能性を大幅に減らすことができます。そうすることで、攻撃対象のエリアを減らし、クラウドのセキュリティを向上させることができます。クラウドベースのインフラストラクチャとプラットフォームサービスは、企業のデータセンターにあるものよりも安全性を高めることが可能です。

分析

強力なアイデンティティとアクセス管理(IDaaS)の規律を確立する

クラウドベースのユーザーや端末がパブリッククラウドベースのサービスにアクセスする世界では、レガシーな企業の境界線(境界型セキュリティ対策)の有用性が低下しています。アイデンティティが新たな境界線となる。具体的には、ユーザー、管理者、端末、ワークロード、サービス、API、コンテナのアイデンティティが、ポリシーを確立し、セキュリティとコンプライアンスを監視するための鍵となります。その基盤となるのが、クラウドプロバイダーに内蔵されたID機能です。そして特に次のような要素を含んでいる。

ユーザー認証のために、企業および/またはクラウドのアイデンティティ・プロバイダーにフェデレートする

クラウド用に別個の認証の島を作る必要はない。シングル・サインオン(SSO)を介した認証と、SAML を介したアイデンティティ・フェデレーションは、クラウド間で一貫したアイデンティティをユーザーに提供し、理想的には属性情報も交換することで、権限設定の粒度を高めることができる。

アカウントを使用して事業部や部署を分離することで、IDを境界線として使用します

IaaS/PaaSプロバイダーのインフラストラクチャは、あるテナントが別のテナントから強く隔離された状態を維持するようにマルチテナントに設計されています。異なるグループに異なるIaaSアカウント構造を使用させることで、これを有利に利用することができます。あるグループが攻撃や障害に見舞われても、他のアカウントには影響を与えず、全体的な回復力を向上させることができます。主要なIaaSプロバイダーは、統合された請求書と、セキュリティ監視のための読み取り専用アカウントの使用でこれをサポートしています。

すべてのクラウドアクセスに強力な認証を必要とする

クラウドサービスへのログインやクラウドベースのAPIへのアクセスを、ユーザー名とパスワードだけで有効にしてはいけません。強力な認証は必須と考えるべきであり、主要なクラウドプロバイダーはこの機能を内蔵している。理想的には、管理者によるアクセスの可視性と制御を強化するために、企業の特権付きアクセス管理システムを使用することです。管理者には常に必要最低限のアクセス権限が付与されるべきです。

粒度の高いパーミッションを使用し、IAMロールを使用する

初期設定以外では、特権IDのアカウントは使用しないこと。特定のユーザーの能力範囲を狭めるためにきめ細かいパーミッションを使用し、監査人や規制当局の職務分離要件を満たすために使用すべきです。さらに、標準化されたIDの権限割当を使用することで、クラウドセキュリティを大幅に簡素化することができ、その使用は必須とすべきです。クラウドプロバイダーの事前定義された役割を出発点として利用しましょう。

許可されたパーミッションと使用されたパーミッションを評価する

実行時にすべてのIAM原則(ユーザ、ネットワーク、ストレージなど)で使用されるパーミッションと、最初にプロビジョニングされたパーミッションとの比較を継続的に監視することは、レビューのために管理者に報告されるべきです。これは、攻撃の表面積を減らすためにパーミッションを積極的にトリミングするために行われます。例えば、Amazon Web Services(AWS)はAWS IAM Access Advisorでこの機能を提供しており、GoogleはRecommendations AIと呼ばれる同社のIAM製品でこの機能をテストしている。また、後述するいくつかのクラウドセキュリティ姿勢管理ベンダーもこれを提供しています。

IAMプログラムの範囲を拡大する

パブリッククラウドIAMのユーザー以外の多くのエンティティは、セキュリティ・プリンシパル(クラウド・プロバイダーのIAMシステムで定義された権限を持っていることを意味する)にもなります。クラウドネイティブなアプリケーションはすべてのVM、コンテナ、サーバーレス機能、APIなどは、IDと関連する権限を定義する必要があります。そしてあなたのIAMプログラムはこれを受け入れなければなりません。

クラウド・インフラストラクチャの構成基準の確立と施行

ネットワーク

エンタープライズ向けのデータセンターと同様に、明確に定義されたネットワークセキュリティ・アーキテクチャは、何が何に通信できるかを制御することでリスクを理解し、管理するために非常に重要です。しかし、従来のエンタープライズ・データセンターのネットワーク・セキュリティ・アプローチは、パブリッククラウドへの導入には適していません。

クラウドを企業のデータセンターの延長線上に置くことから始めよう

ほとんどの企業は、まず企業ネットワークをクラウドに接続し、クラウドのワークロードをパブリック・インターネットに直接通信させることなく、クラウドをリモート・データセンターのように扱うことから始めます。これにより、企業はクラウドセキュリティの経験を積みながら、既存のファイアウォールや侵入防止サービスを利用して攻撃から保護するためにオンプレミスのネットワーク・アプライアンスを使用することができます。

パブリック・インターネットとの間のネットワーク通信を厳重に制御する

長期的には、専門性が高まるにつれて、パブリッククラウドベースのワークロードはインターネットに直接通信するようになる。特定のオンプレミスのデータが必要な場合を除き、これらのクラウドアプリケーションは企業のデータセンターから隔離する必要があります。クラウド・プロバイダーに内蔵されたセキュリティ・グループとネットワーク制御により、このような分離と制御が十分に可能になります。

すべてのネットワーク通信をデフォルトで暗号化する

クラウドとの間の通信、クラウド・プロバイダー内のリージョン間の通信、理想的にはリージョン内の通信など、すべてのネットワーク通信はデフォルトで暗号化され、TLS(Transport Layer Security)などの有効な暗号化方法やプロトコルを使用する必要があります。さらに、通信の双方で相互認証の使用を確立する。

デフォルトでラテラル トラフィックをセグメント化します

ゼロトラスト・ネットワーク・セグメンテーション は、「マイクロセグメンテーション」または 「software-defined segmentation(ソフトウェア定義ネットワーク機能) 」とも呼ばれ、プロジェクトはワークロードにより細かい分離を適用します。クラウドIaaSプロバイダーに組み込まれたソフトウェア定義ネットワーク機能は、ワークロードのIDに基づいたきめ細かなネットワーク分離ポリシーを適用する機能を提供しています。企業は、デフォルトでセグメント化することで、企業のデータセンターに蔓延する「フラットネットワーク」の問題を回避する必要があります。

可視化ツールを使用して、ネットワークポリシーを理解、構築、最適化します

ゼロトラスト・ネットワーク・セグメンテーション戦略の課題の 1 つは、ネットワークフローをどのようにマッピングし、ネットワークポリシーに変換するかということです。フローを収集して可視化し、クラウド・プロバイダーのセキュリティポリシーにマッピングするには、サードパーティ製のCSPMやネットワーク・トラフィック分析ツールが必要になる場合があります。過度なパーミッションは、最初にプロビジョニングされているネットワーク接続と実際に使用されているネットワーク接続を比較することで切り詰めることができます。

トラフィック検査のためのインラインネットワークセキュリティアプライアンスは避けてください

VMベースのネットワーク・アプライアンスは、潜在的な単一障害点を生み出し、暗号化されたトラフィックが見えなくなることが増えています。場合によっては、サードパーティ製のクラウドネイティブ製品をトランジット・ネットワーク型アーキテクチャと組み合わせて、共通の検査要件を一元化することが必要になるかもしれません。あるいは、ワークロードベースの制御を使用することで、インラインネットワーク検査を各VMに分散させることもできます。

サードパーティ製のネットワーク・セキュリティ管理を使用する場合は、クラウドネイティブなアプローチを推奨する

オンプレミスの物理環境を仮想アプライアンスに置き換えただけのベンダーでは、クラウドネイティブな体験は提供されない。クラウドネイティブなセキュリティ製品は、ビルトインの自動回復力、スケールアウト・アーキテクチャ、クラウド・プロバイダのプログラマブル・ネットワークへの挿入の容易さ、トランジット仮想プライベート・クラウド(VPC)のような構成のサポートなどを提供しています。

レガシーな仮想プライベート・ネットワーク(VPN)および非武装地帯(DMZ)アーキテクチャをゼロトラスト・ネットワーク・アクセス(ZTNA)に置き換る

クラウドベースのアプリケーションやフロントエンドサービスに指名ユーザーアクセスが必要な場合は、従来のDMZ や VPNアーキテクチャを使用しないでください。ゼロトラスト・ネットワーク・アクセス(ZTNA)ソリューションは、スタンドアロンの提供として、またはセキュア・アクセス・サービス・エッジ(SASE)機能の広範なセットの一部として使用してください。

ストレージ

公表されているクラウドセキュリティインシデントのほとんどは、クラウドストレージサービスの設定ミスに関連しており、機密データがインターネット上に公開されています。

オープンなファイル共有をスキャンします

オープンファイル共有とオブジェクトストレージは、パブリッククラウドのセキュリティ暴露の最も一般的な形態を表しています。しかし、オープンファイル共有とオブジェクトストレージは、完全に、そして比較的簡単に防ぐことができます。

エンタープライズレベルのコンテンツコラボレーションプラットフォームの代用としてIaaSオブジェクトストレージリポジトリを使用しないでください

開発者はIaaS/PaaSのオブジェクトストアを使ってファイルを共有したくなるかもしれません。電子メールよりはマシですが、Box、Citrix、Dropbox、Google、Microsoft (OneDrive)などのソリューションなど、このために設計された商用コンテンツコラボレーションプラットフォームサービスほど安全ではありません。

顧客が管理する鍵を使用して、安静時のすべてのデータを暗号化する

デフォルトの拒否の原則をデータアクセスにも適用してください。休止時のデータ暗号化は万能ではありませんが、攻撃対象のエリアを減らし、攻撃者のレベルを上げることができます。クラウド・インフラストラクチャに組み込まれた暗号化機能により、これを簡単かつシームレスに行うことができますが、クラウド・ベースまたはオンプレミスのハードウェアの強度に根ざしたマスターキーの制御を顧客が維持することを強く推奨します。顧客が管理する鍵で暗号化されたデータは、データを削除する必要がある場合に非常に大きな価値があります。削除されたデータにアクセスできなくなったことを強く保証するために、マスターキー(およびバックアップキー)を削除してください。

性能

IaaSのコンピュートオファリングは、クラウド・ワークロードの重要な構成要素の一つです。

VM を作成する権利と、VM を削除する権利を分離する。

職務の分離は、マシンとストレージイメージを管理する権利にまで拡大すべきです。単一のアカウントがIaaSの企業資産のセット全体を削除できるようにすべきではありません。

サーバーにはIAMロールを使用してください。

サーバーにはアイデンティティとパーミッションが関連付けられています。IAMロールを使用することで、計算ベースのワークロードに権限を割り当てるスケーラブルな方法を提供します。

クラウド・プロバイダーのメタデータ・サービスをワークロードの秘密に使用する。

クラウドのワークロードは、多くのケースで機密情報(パスワード、APIキー、証明書など)へのアクセスを必要とします。これらはシステムイメージにハードコーディングしてはいけません。主要なクラウドプロバイダーはすべて、これらの秘密をマシンイメージの外部に保存し、必要に応じて照会できるメタデータサービスを提供しています。より高度な機能は、クラウドプロバイダーの秘密管理サービスで提供されています。マルチクラウド機能については、サードパーティの提供が必要になる場合があります。

本番環境のすべてのワークロードにタグを使用することを要求する。

多くのサードパーティ製セキュリティツールは、クラウドプロバイダーのネイティブなAPIを使用して、ワークロードの属性を直接照会することができます。マシンイメージ上のラベルとタグは、サードパーティのセキュリティコンソールからポリシーをマッピングして利用する簡単な方法を提供します。

PaaS

主要なクラウドプロバイダーは、開発者が利用できるプラットフォームサービスを相当数提供しています。これらのサービスには、それぞれ設定や権限の設定が含まれており、非常に複雑で、人為的な設定ミスを引き起こす可能性があります。

PaaSサービスがデータを保存している場合は、そのデータを一時的に暗号化する

ストレージサービスと同様にデフォルトのセキュリティ対策としては、顧客が管理する鍵を使用して、クラウドのデータを一時的に暗号化することです。

どのPaaSサービスを使用するかを標準化する

IaaSプロバイダーは継続的に新しいサービスを導入しています。ベストプラクティスとして、企業は組織のためのサービスの標準サブセットを定義します。このカタログは、開発者の需要とサービスの成熟度に基づいて定期的に再評価されます。

企業が使用する各PaaSのベストプラクティス構成を確立する

各サービスごとにこれを行うのは複雑なため、プロセスを自動化するツールを使用する必要があります。これについては次のセクションで説明します。

すべてのPaaSサービスを論理的なネットワーク構成に接続する

主要なIaaS/PaaSプロバイダーは、ネットワークセキュリティグループ、仮想ネットワーク、VPCエンドポイントなど、企業の論理的なネットワーク構成にPaaSサービスへのアクセスを制限する機能を提供しています(Amazon Web Services VPCエンドポイントを参照)。この機能を使用して、この機能が利用可能な場所であればどこでもPaaSサービスへのアクセスを制限することができます。こうすることで、PaaSへのアクセスや利用を特定のアプリケーションやワークロードに制限することができ、より広範囲に露出したネットワークセグメントにアクセスする必要がなくなります。

クラウドセキュリティの継続的な姿勢管理を実装する

ネットワーク、コンピュート、ストレージ、PaaSサービスの安全かつ準拠した構成は、絶対的に重要です。クラウドサービスに対するセキュリティインシデントや攻撃事例のほぼすべては、顧客の設定ミス、管理ミス、ミスの結果です。このレイヤーでは、必須と考えるべきCSPMへの規律ある、構造化されたアプローチを説明しています。セキュリティおよびリスク管理のリーダーは、これらのリスクをプロアクティブかつリアクティブに特定し、修正するために、クラウドセキュリティ姿勢管理プロセスとツールに投資をする必要があります。

この分野では、クラウド・ワークロード保護プラットフォーム(CWPP)やクラウドアクセス・セキュリティ・ブローカー(CASB)など、約25社のベンダーが競合しています。

  • 1 つの IaaS/プロバイダを使用しているだけの場合は、その組み込みの CSPM 機能を評価する。
  • クラウド・プロバイダーのビルトイン・セキュリティ・ダッシュボード/コンソールを、セキュリティ課題をハイライトするための一枚板として使用する。これと統合するためにサードパーティを要求する。
  • より複雑でハイブリッドなマルチクラウド展開の場合は、サードパーティの CSPM を使用する。
  • 業界標準のベストプラクティスを出発点として使用する。
  • 開発者にガードレールを設定することで、開発に残された CSPM の評価をシフトする。
  • CSPM の範囲をコンテナベースの環境、特に Kubernetes とマネージド Kubernetes サービスにまで拡大する。
  • クラウド構成のリスクとコンプライアンスの問題を継続的にスキャンする。

広範囲にわたる可視性とモニタリングの確立

大手クラウドプロバイダーのIaaS/PaaSを支えるプログラマブルなインフラストラクチャは、企業のデータセンターよりも優れた可視性を提供します。内蔵のAPIを使用することで、すべてのクラウドのワークロード、構成、権限をリアルタイムで列挙することができます。管理者やプログラムを問わず、あらゆるタイプのアクセスをログに記録する必要があります。あらゆるタイプのネットワークベースのアクセスはすべてログに記録する必要があります。これにより、これまでにない可視性が得られ、これを利用してセキュリティを向上させることができます。

ビルトインのアクティビティ監視を利用しましょう

主要なクラウドプロバイダーはすべて、人によるもの、スクリプトによるもの、APIベースのものなど、基本的には使用するストレージ以外のコストをかけずに、すべてのクラウドアクティビティをログに記録するように設定できます。これらのクラウドアクティビティのログは大容量で冗長なものになることがあるため、ほとんどの企業では、帯域コストを削減するためにクラウドにログを保存し、より大きなデータセットと長期間の保存を可能にしています。

可能な限りすべてのログを有効化し、最低でも1年間は保持しましょう

大手クラウドプロバイダーは、アクティビティログに加えて、ネットワーク、コンテナ、サーバーレス、その他のサービスなど、提供されるすべてのIaaS/PaaS機能について詳細なロギングを提供しています。ネットワーク・フロー・ログを含め、可能な限りすべてのログを記録することが最善の方法です。このような広範な可視性をベースライン化してパターンを分析することで、行動分析に基づく脅威検知の基盤を提供することができます。

不正な資産を継続的にスキャンする

企業のクラウドインフラストラクチャ全体を継続的にスキャンして、新しい資産や未知の資産(例えば、タグ付けされていないサーバーなど)がないかどうかを確認する必要があります。このスキャンは、ビジネスユニットや開発者による認可されていない(そして潜在的に安全ではない)個人的なIaaSの使用をスキャンするために拡張する必要があります。これは、ファイアウォールのログ、セキュアウェブゲートウェイ(SWG)のログ(主要なCASBはこの機能を提供しています)や会計記録を分析することで達成することができます。

脆弱性のあるシステムを継続的にスキャンする

前のセクションで説明した CSPMツールの大半は、VM やコンテナにパッチの欠落やOSやシステムファイルの設定ミスがないかどうかを調べていません。これらを実行時にスキャンして、本番環境に置かれたシステムが誤って本番環境に置かれたり、本番環境に置かれた後に脆弱性のあるシステムになったりしていないことを確認する必要がある。大手クラウドプロバイダーのいくつかは、この目的に特化したエージェントを提供しています。

外部からのアクセスを許可しているパーミッションを継続的にスキャンし、調査する

ストレージ、鍵、読み取り専用/読み取り専用のセキュリティアカウントなどのIaaS/PaaSリソースが、アカウント外のリソースに権限を付与されている場合があります。クロスアカウント権限はリスクを表しており、発見して受け入れなければなりません。これらが誤って付与された場合や、必要性がなくなった場合もあります。これらをスキャンし、その正当性を理解することは、継続的なプロセスであるべきです。

企業のセキュリティ情報・イベント管理(SIEM)とセキュリティオーケストレーション、自動化、対応(SOAR)に統合する

分析なしに監視しても意味がありません。収集した可視性は、企業のSIEMやSOARと統合する必要があります。多くの場合、パブリッククラウドで生成されるデータ量が企業のデータセンターで生成されるデータ量を超えているため、これはクラウドまたはサービスとしてのSIEMを介して行われます。実際、大手クラウドプロバイダーが独自のSIEMを提供する方向に進んでいるのは、自社のクラウドにネイティブに統合されていることと、リスクを特定するための機械学習やAIの活用など、大規模データセットの管理/分析に関する専門知識があるからだ。SOARは新しいものではあるが、APIベースであることのメリットもあり、クラウドサービスを含む他のサードパーティ製APIを活用してポリシーや自動化機能をラップさせる機能を持っている。

ワークロードの確保

仮想マシンやコンテナ(およびサーバーレスPaaSのコード)のセキュリティは、クラウド・プロバイダーではなく顧客の責任である。企業データセンターの仮想マシンやコンテナと同様に、セキュリティの可視化と制御に最適な場所は、ワークロード自体の内部からです。

ワークロードの正しい構成/脆弱性管理から始める

クラウドのセキュリティ態勢には、企業のデータセンターと同様に、ハードニングとパッチ管理の規律が非常に重要です。パッチが適用されていないシステムや露出したシステムは、セキュリティ面で攻撃を受けることになります。幸いなことに、クラウドのソフトウェア主導の性質により、かつては困難だった多くのパッチ管理タスクが簡素化されています。VMを使用しても、企業のパッチ適用プロセスは改善され、より自動化されます。例えば、クラウド・プロバイダーの更新されたイメージを使用して、自社のゴールド・イメージではなく、VMを自動的に再構築することができます。

サードパーティのCWPPオファリングの利用を期待する

Microsoftは、WindowsとLinux向けに独自の保護エージェントを個別に有料で提供している唯一の大手IaaS/PaaSプロバイダーである(Azure Security Centerの提供)。他のクラウド・プロバイダーでは、サードパーティ製のCWPPサービスが、保護機能をレイヤー化して提供している。

デフォルトのアプリケーション制御の拒否に根ざしたセキュリティ戦略を採用してください

十分に管理されたサーバのワークロードでは、実行を許可するものを制御する方がはるかに効果的です。アプリケーション制御(「ホワイトリスト」または「許可リスト」とも呼ばれる)を使用して実行可能な実行ファイルを制御することは、非常に強力なセキュリティ保護戦略を提供します。これにより、企業は、実行可能ファイルに対してデフォルトの拒否/ゼロトラストのセキュリティ姿勢を採用することができます。実行されるファイルとして顕在化するすべてのマルウェアは、デフォルトでブロックされます。

ワークロード保護戦略をコンテナおよび管理されたコンテナサービスにまで拡張する

どのようなワークロード保護戦略やサービスを選択したとしても、その戦略は、Linuxコンテナと主要な IaaS/PaaS プロバイダが提供するマネージドコンテナサービスを保護するために拡張されなければなりません。具体的には、Kubernetesで動作するコンテナと、主要なクラウドプロバイダーのマネージドKubernetesサービスを明示的にサポートする必要があります。

ワークロード保護戦略の範囲をサーバーレスPaaSにまで拡大する

VMやコンテナと同様に、サーバーレスPaaSは、開発者の作業を基盤となるインフラストラクチャから抽象化した論理的な進行です。ワークロードの保護は開発段階から始まり、PaaSサービス全体のサブセットであるサーバーレスPaaSでも同じことが言えます。PaaSやクラウドアプリケーションのセキュリティについては、次項で説明します。

アプリケーション、PaaS、APIセキュリティの実装

現代のクラウドネイティブアプリケーションは、VM、コンテナ、サーバーレスPaaSなどのPaaSサービスを組み合わせて開発されたものよりも、組み立てられたものが多くなっています。これらのクラウドベースのアプリケーションとその機能の提供には、セキュリティ面での攻撃からの保護が必要です。

開発中の脆弱性のためにコードを積極的にスキャンする

エンタープライズ向けに開発されたアプリケーション(サーバーレスPaaSを含む)は、既知および未知の脆弱性をスキャンする必要があります。クラウドネイティブ・アプリケーションで最もよくある間違いは、既知の脆弱性を持つOSSコンポーネントやフレームワークの使用であり、これはクラウドネイティブ・アプリケーションのコードの約80%を占めています。さらに、公開されているすべての API も同様にスキャンする必要があります。

脆弱性のあるソフトウェアだけでなく、アプリケーション上のリスクスキャン対象を拡大する

クラウドのリスクは、設定ミスやパッチの欠落だけでなく、埋め込まれた秘密(APIキー、ハードコードされたパスワード、暗号化キーなど)のようなものも含めて、さまざまな形で発生します。これらは、クラウドのスクリプトやテンプレート、開発者のソースコードに配置されています。また、権限やネットワーク接続性の点で、PaaSサービスの正しい設定を確認してください。これらのリスクはすべて、プロアクティブかつリアクティブにスキャンする必要があります。

クラウドネイティブ機能を使用してレジリエンスを構築する

オンプレミスのアプリケーションをクラウドで実行するだけでは、スケーラビリティやレジリエンスを高めることはできません。クラウド・ネイティブのロードバランサーと内蔵のオートスケーリング機能を使用して、スケールアウトできるアプリケーションを設計してください。アベイラビリティ・ゾーン間の回復力は、アプリケーションに組み込まれている必要があります。

クラウドネイティブのなWAFを使用しますが、サードパーティ製の製品を使用することを想定してください

これは、クラウド・プロバイダーのビルトイン機能が商用のものに比べて遅れている分野です。サードパーティのプロバイダやサードパーティのルールセットは、組み込みのIaaS/PaaSプロバイダのWAFサービスのポリシーを管理するために必要になるかもしれません。あるいは、動的な SASE 接続の一部として WAF サービスが自動的に挿入されることもあります。クラウドネイティブアプリケーション内のWAFフィルタリングには、何らかの形での組み込みWAFまたはマイクロWAF機能が必要になります。サービス拒否の保護については、クラウド・プロバイダーが提供しているものを内蔵したものを使用すれば十分です。

WAF以外にも、ウェブ・アプリケーションやAPIの保護機能が必要です

最新のクラウドネイティブ・アプリケーションを保護するには、WAF保護だけでは十分ではありません。WAFはユーザー・インターフェースを保護するように設計されていますが、最新のクラウドネイティブ・アプリケーションでは、公開されている機能の大部分はUIには反映されていません。具体的には、クラウドネイティブ・アプリケーションは、APIやアンチオートメーション(ボット)の保護機能も備えている必要があります。これは、私たちが Web アプリケーションと API 保護と呼んでいる機能の拡張セットです。

コントロールポイントとしてAPIゲートウェイまたはイベントバスを使用します

サーバーレス機能へのアクセスは、APIゲートウェイまたはイベントブローカーを使用してのみ有効にする必要があります。クラウド プロバイダ独自の API ゲートウェイを使用してもよいし、サードパーティの API ゲートウェイを使用してもよい。サーバーレスコードが内部でのみ使用される場合でも、APIゲートウェイ/イベントブローカーは、セキュリティ上の重要な可視性とコントロールポイントとして機能します。

運用監視とセキュリティ監視を統合する

アプリケーション層では、サービスの詳細な監視を行う2つのツール(1つはセキュリティ用、もう1つは運用用)を用意する必要はありません。最低限、データはチーム間で共有されますが、理想的には、アプリケーションのパフォーマンス監視とセキュリティ監視がアプリケーションの監視とパフォーマンスをサポートする単一のDevSecOpsチームに統合されます(「アプリケーションのパフォーマンス監視とアプリケーションのセキュリティ監視が統合される」を参照)。これは、より多くのマネージドコンテナやサーバーレスコードが使用され、情報セキュリティが計測すべきOSを持たなくなるにつれて、ますます重要になるでしょう。

PaaSセキュリティを根本的に異なる問題として扱わないでください

PaaSセキュリティは別個の問題や市場ではありません。これまでにこの研究で説明してきた能力の組み合わせを利用した創発的な規律なのです。PaaSセキュリティの規律は、強力なアイデンティティとアクセス管理の原則、適切なインフラストラクチャの構成とハードニング、継続的なクラウドセキュリティの姿勢評価、広汎な監視、アプリケーション層のスキャンとセキュリティに根ざしています。

データの認識と保護の拡大

機密データやマルウェアをスキャンします

すべてのデータは同じように作られているわけではなく、同じリスクを表しているわけでもありません。IaaS/PaaSストレージリポジトリは、データリスクを特定するためにスキャンする必要があります。データリスクには主に2つの形があります。クラウド上で許可されているかどうかわからないセンシティブなデータとマルウェアです。どちらもリスクを表しています。どちらもスキャンして、過剰なリスク、未知のリスク、または予期せぬリスクを特定する必要があります。ソリューションは「シングルパス」アーキテクチャを使用して、特定のファイルに埋め込まれた機密データまたは埋め込まれた脅威の形でリスクを同時にスキャンできるようにする必要があります。ここでは、IaaS/PaaS サービスをスキャンする CASB や CSPM などのサードパーティ製のサービスが必要になるかもしれません。

機密性の高いデータを扱う際には、機密性の高いコンピューティング技術を採用する

大手クラウド・プロバイダーの中には、現在、コンフィデンシャル・コンピューティングのオプションを提供しているところもあります。コンフィデンシャルコンピューティングは、CPUベースのハードウェア技術とCSPのVMイメージとソフトウェアツールを組み合わせたもので、クラウドを利用する組織が完全に隔離された信頼できる実行環境(エンクレイブと呼ばれる)を構築することを可能にします。エンクレーブは、使用中のデータを暗号化する形で提供されるため、ホストOS やクラウド プロバイダの管理者からは機密情報が見えなくなります。代替として、マルチパーティ計算やソフトウェアベースの信頼された実行環境などのソフトウェアベースの技術も利用できます。

クラウド・プロバイダーのデータ複製パターンとポリシーを理解し、管理する

主要なクラウド・プロバイダは、データの複製先と複製方法を制御し、地理的な複製の制御も含めて、データの複製先と複製方法を制御しています。データの種類によっては、EUの一般データ保護規則(GDPR)など、法律で義務付けられている場合があります。この推奨事項は、先に説明した詳細な監査ログの保存と取り扱いにも適用される。しかし、クラウドプロバイダーのすべてのログがこの種の地理的制限をサポートしているわけではありません。この分析は、バックアップやバックアップサービスにまで及ぶべきです。最後に、クラウドプロバイダーのログやメタデータが地域に準拠して保存されていたとしても、データに対する分析サービスは、そうではないかもしれませんが、同様に理解されるべきです。

クラウド脅威の監視と検出

私たちの最善の努力にもかかわらず、完璧な攻撃防御は不可能であり、クラウドがそれを変えることはありません。IaaS/PaaSの包括的なセキュリティ戦略には、我々が導入している防御コントロールのレイヤーを迂回した攻撃を監視することが含まれている必要があります。これは企業向けSIEMの代替品ではない。むしろ、IaaS/PaaSプロバイダーが生成したクラウドのテレメトリをドメイン別に分析し、自社環境内のクラウドベースの脅威を特定するためのものと考えてください。

行動分析を適用するための基盤として可視性を使用します

可視性は、パブリッククラウドのテナントやサブスクリプション内のすべてのエンティティの通常のベースライン動作を確立するための基盤となります。ベースライン分析と行動分析を使用することで、ネットワークトラフィック、アイデンティティ、ワークロード、アプリケーション、データ関連の行動など、クラウドの可視性のすべてのレイヤーで脅威を検出することができます。

クラウド・プロバイダーのビルトイン脅威検知機能を活用する

現在、主要なクラウドプロバイダーは、着実に向上している独自のビルトイン型クラウド脅威検知機能を提供しています。これらのビルトインサービスを有効化して活用しましょう。ほとんどのプロバイダーは、分析を活用したネットワークフローログや、脅威インテリジェンスの補足的なソースなど、テレメトリソースを組み合わせて攻撃を特定しています。クラウドネイティブの脅威検知は、このユースケースに非常に関連性があります。なぜなら、このツールは、長年にわたって企業のデータセンターで使用されてきたものとポリシー的にはほぼ同じですが、クラウドの動的な性質をサポートすることでメリットがあるからです。さらに、セキュリティ・チームが期待する可視性を失うことなく、これを実現することができます。

最も重要なワークロードのみにネットワーク・タップを使用する

顧客の要望に基づき、大手クラウドプロバイダーは最近、クラウド内のトラフィックの仮想タップを受信する機能を追加しました。これにより、ネットワーク・フロー・ログよりもはるかに多くの可視性を得ることができ、さらにサードパーティのネットワーク・トラフィック解析サービスでは、この詳細な情報を活用することができます。しかし、生成されるデータ量は膨大であるため、この種の詳細なモニタリングをすべての資産で使用する必要はありません。

ネットワークの可視性を脅威インテリジェンスと関連付ける

クラウドベースのリソースの1つが既知のコマンド・アンド・コントロール・センターとアウトバウンドで通信している場合は、アラートを発する必要があります。そのためには、セキュリティソリューションをネットワークの可視性に適用する必要があります。理想的にはクラウド・プロバイダーから直接、または信頼できるサード・パーティとのパートナーシップを通じて提供されるべきです。例えば、分析に組み込むべき重要なテレメトリの1つは、クラウドベースのリソースからのDNSコールアウトです。IaaS/PaaSプロバイダーが公開している場合は、このDNSテレメトリを使用します。

挙動の異常とセンシティブなデータの認識を相互に関連付ける

クラウド攻撃の目的はデータを盗むことが大半です。ネットワークやアクティビティの挙動とデータのコンテキストを組み合わせることで(前節で説明した)、実際のイベントを検知する際の有効性を高めることができます。例えば、「機密情報を含むこのS3バケットの周辺で異常な動作が見られます」というアラートは、セキュリティ・オペレーション上非常に有用であり、リスクを検知した重要なアラートとなります。現在では、検知精度を向上させるためにこれを行っているクラウドプロバイダーもあります(例:Amazon Macie)。

脅威検知をKubernetesに拡張する

Kubernetesでオーケストレーションされたクラスタは、本質的に “クラウドの中のクラウド “です。クラスタ内のKubernetesログ、ネットワークフロー、アプリケーションの動作を監視し、可視化することで、危殆化の兆候がないかどうかをベースライン化して分析する必要があります。

人員やリソースが不足している場合は、マネージドの検知・対応サービスを利用しましょう

ほとんどの企業のセキュリティ部門は人員が不足しています。潜在的な攻撃を検出して対応するということは、それを行うスタッフがいることを意味します。リソースがない企業には、マネージド・クラウドの脅威検知・対応サービスが利用できます。クラウド・プロバイダーの中には、これを提供しているところもある。たとえば、MicrosoftはAzure Security Centerとの間で、マネージド検出・応答(MDR)のための別料金のサービスを提供しています。クラウドMDRは、Alert Logicなどのサードパーティからも提供されています。 ただし、パブリッククラウドをまだサポートしていないサービスプロバイダもあれば、IaaS(PaaSではなく)監視に限定しているサービスプロバイダもあるため、企業はサービスプロバイダに、パブリッククラウド機能との明確なサポートと統合について問い合わせる必要があります。

クラウドネイティブな考え方を受け入れる

これからはクラウドネイティブのマインドセットを使用して実装する必要があります。オンプレミスのエンタープライズ・セキュリティ設計パターンをパブリック・クラウドの IaaS/PaaS に複製すると、非効率で効果的な導入ができなくなりっます。このパターンと関連ツールは、パブリック・クラウドの動的で刹那的な性質にはあまり適しておらず、パブリック・クラウドを採用する開発者やビジネス・ユニットのニーズを挫折させる可能性が高い。クラウド・セキュリティを担当するセキュリティとリスク管理のリーダーは、パブリッククラウドを導入する際には、新しいアプローチ、パターン、ベストプラクティス、ベンダーの採用に積極的でなければなりません。

組み込みのクラウドネイティブ機能を利用する

主要なクラウド・プロバイダーは、組み込み型のセキュリティおよびコンプライアンス機能を充実させているが、その機能や成熟度には大きな違いがある。成熟したクラウド・プログラムを導入している企業は、レガシーなセキュリティベンダーの製品がクラウドセキュリティベンダーのセキュリティ機能と重複しているため、レガシーセキュリティベンダーへの依存度が低くなっています。クラウド・プロバイダーの機能が商用製品に比べて遅れている場合には、クラウドネイティブなセキュリティの新興ベンダが、クラウド・コンピューティングの刹那的で弾力性のある性質を考慮した使用ベースのライセンス・モデルと、スケールアウトしたソフトウェアベースのアーキテクチャを採用し、それを理解していることを好ましく考えます。

DevSecOpsの原則を受け入れ、セキュリティとコンプライアンスを開発にシフトさせる

DXが進む現代では、開発者が支配しています。情報セキュリティは、ランタイムのセキュリティ実施のみに注目するのではなく、継続的インテグレーション/継続的デリバリ(CI/CD)パイプライン全体にセキュリティポリシーの実施を統合することに焦点を移す必要があります。セキュリティとコンプライアンスのテストと修復は、開発者のツールチェーンに透過的に統合されなければなりません。情報セキュリティポリシーと検査は、ゲートではなく、ガイドレールにならなければなりません。基本的に全てのセクションは、開発に拡張することが可能であり、拡張すべきである。

すべてのセキュリティインフラストラクチャをプログラム可能なものにする

パブリッククラウドは、プログラマブルなインフラストラクチャの上に構築されています。このインフラストラクチャへの統合をサポートし、上述の CI/CD パイプラインへの統合をサポートするためには、セキュリティインフラストラクチャ自体がプログラマブルになる必要があります。セキュリティインフラストラクチャのプロバイダは、スクリプトや自動化ツールでの使用を可能にするために、完全にAPIに対応していなければなりません。

不変のインフラストラクチャの概念を採用する

不変のインフラストラクチャでは、環境へのすべての変更は、DevSecOps スタイルのワークフローを使用した自動化によって推進されます。時代遅れのワークロードは、自動化された体系的な方法で新しいイメージに置き換えられます。不変のインフラストラクチャは、現在では最先端の組織によって確立されたベストプラクティスであり、主流の企業は特に新しいクラウドネイティブ・アプリケーションの採用に向けて動き出すべきです。このプラクティスでは、本番環境でインフラストラクチャを変更しないことが義務付けられています。その代わり、サーバーに計画的または計画外の変更が必要な場合は、新しいマスターを作成し、既存のサーバーを新しいサーバーに置き換え、テストを行い、満足した場合は古いサーバーを破棄します(または迅速にロールバックします)。さらに、潜在的に成功する可能性のある永続的攻撃を排除するために、パブリック・フェイスのクラウドネイティブ・ワークロードは、たとえ環境に変更がなかったとしても、体系的に再構築する必要があります。

ハイブリッド・マルチクラウドの計画

調査データによると、今後何年にもわたって企業データセンターの名残が残ることが明らかになっています。さらなる調査によると、約70%の企業が設計上複数のIaaS/PaaSプロバイダーを採用しています 。これを踏まえると、前述のCSPMやCWPPツールの場合は、サードパーティ製のツールが必要になる場合があります。

クラウドネイティブ・アプリケーションをサポートするように設計する

クラウドネイティブ・アプリケーションは、コンテナ、Kubernetes、サーバーレスPaaSをベースにしたマイクロサービスベースのアーキテクチャを使用し、レガシーVMとの統合を行うことが特徴です。情報セキュリティは、ワークロードの場所やフォームファクタ(VM、コンテナ、サーバーレス)に関係なく、クラウドネイティブ・アプリケーションのセキュリティとコンプライアンスをエンドツーエンドで一貫して設定、表示、管理、監視できるように設計する必要があります。

ベンダーの切り替えにも柔軟に対応する

市場をリードする複数のセキュリティ・ベンダーは、クラウドネイティブ・アプリケーションの保護ニーズへの対応に遅れをとっていたり、その機能がクラウド・プロバイダーと重複していたりします。確立されたビジネスモデルでは、オンプレミスのハードウェアを販売したり、ソフトウェアベースの仮想アプライアンスでレガシーハードウェアの機能を提供したりしていますが、クラウドネイティブになるように再設計したり、基盤となるクラウドプロバイダーのセキュリティ機能とのネイティブな統合を提供したりすることはありません。

ゼロトラスト・セキュリティ・アーキテクチャを採用する

ゼロトラスト・ネットワーキングは、企業の境界線の内外を問わず、異なるエンティティ間に暗黙の信頼関係を持たない初期のセキュリティ姿勢を持つ、安全なネットワーク接続のための概念です。ネットワーク機能へのリスク最適化されたアクセスは、エンティティ、システム、およびコンテキストのアイデンティティを評価した後にのみ動的に拡張される。これは、クラウドベースのアプリケーションへのユーザーベースの外部アクセスと、クラウドプロバイダー内でのセグメンテーションの両方に適用されます。

SNSでもご購読できます。

コメントを残す

*