クラウドでのデータのセキュリティ
- 14 分
データを完全に保護するには、その資格を持つユーザーまたはエンティティのみがアクセスできるようにする必要があります。 その理由によって、データのセキュリティに実際に関係する内容について、さらに明らかになることになります。 データの侵害は、資格のない関係者がデータにアクセスしたときに発生します。 しかし、侵害はレコードを偶発的に公開するのと同じくらい簡単な場合があります。その場合、ユーザーが求めなかった可能性があり、取得するためにシステムに "ハッキング" する必要がなかった可能性があります。 データへのアクセスに通常使用されるツール以外の方法で、データベース、データ ストリーム、データウェア ハウス、またはデータ レイクにアクセスすると、悪意のあるユーザーがデータの内容を読み取ったり、変更したりできる可能性があります。
クラウドに格納されているデータには、正当なソースからのみアクセスできる必要があります。これにより、クエリを検証し、監査できるようになります。 アプリケーションは、攻撃ベクトルとして使用される可能性を排除するために詳しく調べる必要があります。たとえば、通常は漏えいしないデータを攻撃者が取得できるようにする、SQL インジェクションの脆弱性が確実に含まれないようにするためです。 また、承認されていないユーザーがアクセスできないように、データを保護する必要があります。 この保護を実現する最善の方法は、承認されていないアクセスに対して複数の障壁を築き、データ ソースをリアル タイムで監視するツールとサービスを採用し、データへのアクセスをログに記録し、疑わしいまたは不正な動作に対応することです。
多層セキュリティ
絶対的なセキュリティが保証されることはないため、ほとんどの組織では、"多層防御" ともいう多層セキュリティ戦略を使用して、クラウドに格納されたデータを保護します。 核となる原則は、攻撃者が防御の 1 つを突破した場合、次の防御でそれを阻止できることです。 また、多層セキュリティ戦略では、さまざまな、関連がない可能性のある攻撃ベクトルに対する保護が提供されます。 たとえば、IAM でデータベースを保護し、指定されたユーザーのみがクラウド ポータルからアクセスできるようにすると、攻撃者がデータベースをホストするサーバーにアクセスし、データベース ファイルのコピーを作成した場合、データベースを保護することはできません。 しかし、これらのファイルを暗号化するための追加手順を行うことはできます。
図 4 は、クラウド データベースの多層セキュリティを構築する方法を示しています。 データは、その場で暗号化 ("保存時に暗号化") され、ネットワーク経由で送信されるときに TLS で暗号化 ("移動中に暗号化") されます。 その外側の層には、監査証跡が維持されるように、データへのすべてのアクセスのログが記録されます。 この層では、データベースへのアクセスを継続的に監視し、管理者に疑わしいアクティビティを警告するアクティブな脅威検出エージェントをホストすることもできます。 次の層では、IAM を使用して、確実に承認されたユーザーとアプリケーションのみがデータベースに接続できるようにします。 最後に、最も外側の層では、ネットワーク経由でのデータベースへのアクセスが制限されます。 たとえば、特定の VNet または VNet のセットからのみデータベースにアクセスでき、外部からの接続を許可リストに登録された IP アドレスのセットに制限するように指定できます。
図 4: 多層データ セキュリティ (多層防御)。
クラウド内の保存データを暗号化することは、そのデータをセキュリティで保護するうえで重要な要素です。 ほとんどのパブリック クラウド プラットフォームでは、そのストレージ サービスに格納されているデータの透過的な暗号化がサポートされます。 このコンテキストでは、"透過的" とは、データがストレージに書き込まれるときに自動的に暗号化され、読み戻されるときに自動的に暗号化が解除されることを意味します。 したがって、アプリケーションではデータ自体の暗号化またはその解除を行う必要はありません (暗号化されていることさえ認識されていない可能性があります)。ただし、(たとえば、データが保存されているサーバーに誰かが不正にアクセスして) データが盗まれても、暗号化の解除キーが取得されない限り、それは使い物になりません。 通常、キーは、Azure Key Vault や AWS キー管理サービスなどのサービスによって管理される、高度なセキュリティで保護された場所に個別に格納されます。
たとえば、Azure Storage では、AES-256 暗号化を使用して格納するすべてのデータが自動的かつ透過的に暗号化されます。 暗号化と暗号化の解除に使用されるキーは、Azure によって提供される場合もあれば、顧客から (Azure Key Vault を通じて) 支給される場合もあります。 同様に、Azure SQL Database では、データベース、関連付けられたバックアップ、およびトランザクション ログ ファイルのリアルタイムの暗号化と暗号化の解除がサポートされていて、これは透過的に行われるため、それを使用するアプリケーションに変更を加える必要はありません。 同様の暗号化オプションが、Amazon と Google によって提供されています。
保存時の暗号化は、ストレージ サービスとデータベースに限定されるものではありません。仮想マシンを提供する仮想ハード ディスクにも適用されます。 たとえば、Azure では、VM を Azure Disk Encryption によって保護することができます。この場合は、Windows VM 用の Windows BitLocker テクノロジと Linux VM 用の Linux DM-Crypt を使用して、オペレーティング システム ディスクとデータ ディスクが完全に暗号化されます。 AWS では、EC2 Instance Store Encryption を通じて同等のオプションが提供されます。
データ セキュリティ プラットフォーム
データ セキュリティ プラットフォーム (DSP) を使用してデータ ストレージと使用を監視すれば、セキュリティを補完することができます。 完全な DSP はツールのクラスであり、適切に実装すると、次のような利点が組織にもたらされます。
各クラウドまたはネットワーク テナントの分離と共に、そのテナントがアクセスを許可されているデータ ソースの分離を確実に行えます (テナントの観点から見たネットワークに、アクセスが許可されていない、またはアクセスが禁止されているデータ ソースのアドレスが含まれていない限りにおいて)。
監査およびコンプライアンスの目的で、データ関連の管理者アクティビティをすべてログに記録できます。
確定されたアクセス制御特権に基づいて、機密性の高い機密データを自動的に検出して分類できます。
データ ストレージの整合性に影響する可能性があるインフラストラクチャへの変更をログに記録できます。
最新のデータ センターでは、データがパスワードの背後で、またはトークンの交換によって保護される単純な "要塞ウォール" モデルを使用しても真のデータ セキュリティを実現することはできません。 真のデータ セキュリティ プラットフォームでは、要求されているデータの機密性と、要求を行う個人またはサービスの承認レベルに基づいて、すべての条件でアクセス ポリシーが確立されます。
テナントの分離
プライベート クラウドを含むクラウド プラットフォームの主な目的の 1 つは、複数のテナント (登録済みの課金可能なアカウントを持つ認定組織) に共有インフラストラクチャへの仮想化アクセスを提供することです。 そのような最も単純なプラットフォームでは、仮想マシンをホストするハイパーバイザー ソフトウェア コンポーネントによって、共同テナント間の分離が可能になります。 ハイパーバイザーは、仮想マシンとそれらをホストする物理サーバーとの間でアクセスを仲介する抽象化レイヤーです。 単一のサーバー上では、各ハイパーバイザーによって、基になるシステム サービスへのアクセスが分割されます。 一方、サーバー クラスター上では、複数のハイパーバイザーによって仮想機能のプールが提供され、それらをサポートするハードウェアの構成は、通常、ネットワーク アドレスを仮想化する "ネットワーク ハイパーバイザー" を利用して、完全に隠されます。
コンテナー化された環境 (Docker や Kubernetes など) では、仮想化されたエンティティ、またはコンテナーが多数、サーバー クラスター内に存在する可能性があります。 各コンテナーでは、プロセスが他のコンテナーから分離して実行されます。 それぞれに独自の "名前空間" が個別に用意されているため、近隣のリソースを列挙することはできず、もちろんそれらにアクセスすることもできません。 ただし、コンテナーでは、ホスト オペレーティング システムが、またはオペレーティング システムの代理として機能するプロキシが共有されます。 理論的には、そのルートが悪用される可能性がある共に、あるコンテナー内のコードによって、同じ OS でホストされている別のコンテナーに属するリソースにアクセスされる可能性があります。
コンテナー化された名前空間または VM の名前空間では、データ ソースまたはボリュームに複数の同時実行ユーザーが存在する場合があります。 ネットワーク内でのこれらのユーザーの場所は、この名前空間の外にあり、彼らのアクセス権は認証を通じて付与されます。 この名前空間の所有者は、テナントです。 クラウド ネットワークでは、あるテナントから、別のテナントで使用されるメモリやデータベースなどのインフラストラクチャ リソースにアクセスすることができないように、テナントの分離を比較的容易に可能にすることができます。 DSP には、このような試行が決して行われないようにするためのツールが含まれている場合があります。
さらに難しいのは、ユーザーの分離を可能にした上で、各単一ユーザーに表示される論理ネットワークの幅を、それぞれのユーザーが権利を持ち、アクセスが許可されているリソースのみに確実に制限することです。 VMware の vSphere 仮想化環境では、「マイクロセグメンテーション」と呼ばれる手法を使用してこのレベルで分離することが可能です。この技術に関する詳細は次の記事で説明されています：The New Stack、『Microsegmentation: How VMware Addresses the Container Security Issue』。 サーバー クラスターまたは名前空間の内部で最大限に利用される多くのファイアウォールと同様に、マイクロセグメンテーション システムでは、ネットワークおよびセキュリティのポリシーがユーザーごとに適用されます。 その結果、ユーザーが通信するサーバーのネットワーク内では、未承認リソースが非表示になります。
VMware の NSX などのネットワーク仮想化プラットフォームでは、物理ワークロード (Hadoop や Apache Spark などの "ビッグ データ" 機能を含む) 用のマイクロセグメンテーションが実装されます。これを行うために、論理ルーター (物理的ではなく仮想的なアプライアンス) を使用して、それらのワークロードを構成するコンポーネントの制限付きビューが VM に提供されます。 図 5 に、このプロセスの動作を示します。 VM の観点から見ると、ネットワークは、ワークロードを構成する仮想名前空間内のルートのみに制限されます。
![図 5: マイクロセグメンテーションが物理ワークロードのアドレス指定能力に与える影響。[VMware 提供]](../../cmu-cloud-admin/cmu-cloud-security/media/fig8-5.png)
図 5:マイクロセグメンテーションが物理ワークロードのアドレス指定能力に与える影響。 [VMware 提供]
最新のデータ セキュリティ プラットフォームはマイクロセグメンテーション サービスに関連付けることが可能なので、任意のユーザーがアクセスできるデータベースを各ユーザーがアクセスできるレコードのみに制限することができます。 その後、表示可能なデータベースは、物理データベースのビューになり、ネットワーク上でそのプロキシとして機能します。 ユーザーは、自分のネットワーク上に存在しないレコードに誤ってアクセスすることがなくなり、意図的にアクセスすることもできません。
データの検出と分類
リモート エージェントを分散アプリケーションや Web アプリに挿入すれば、重要なマイルストーン間の時間間隔を観察することができます。 IBM Smart Data Discovery、Veronis、Netwrix などのデータ検出プラットフォームでも、エンタープライズ ネットワーク全体でデータがアクセスされるパターンについて同様の分析が行われます。 多くの場合、この分析では、レコードがアクセスされるときにそれらにメタデータベースの "フィンガー プリント" を導入する必要があります。それにより、プラットフォームではそれらのレコードにタグを付けて追跡できるようになります。
プラットフォームでは、タグ付けされたレコードの慎重な動作分析により、特定のレコードが他のレコードよりも、機密性が高いかどうか、または機密性保護に値するかどうかを判断できます。 一部のレコードまたはデータ ソースは、限られた数のユーザー アカウントによってアクセスされる場合がありますが、これは当然のことです。 ただし、そのデータが本当に機密性の高いものである場合、保護されていなければ、未承認または悪意のあるアクセスにさらされる可能性があります。
環境変化の監査
現在、クラウドベースのリソースのほとんどは、仮想ネットワーク内でホストされています。これは、物理ネットワークか、別のそのようなオーバーレイかの上にあるオーバーレイです。 その目的は、リソースをユーザーの名前空間内のリソースに対してより直接的にアドレス指定できるようにすることです。そのためには、それらにローカル名前空間に固有の、かつ限定した IP アドレスを割り当てます。
仮想ネットワーク オーバーレイには、そのアドレスがマップされている基になる物理ネットワーク内での変更をマスクする傾向があります。 これらの物理的な変更は、多くの場合、ソリューションの進化と、そのコンポーネントを接続する物理ネットワークによるものです。 パフォーマンスの低下と、ネットワークの脅威プロファイルに対する変更は、脆弱性と、最悪の場合、悪用可能性につながることが考えられる、仮想ネットワークのオーバーレイでの不一致の証拠となる場合があります。
Netwrix などの変更監査プラットフォームによって生成される時系列レコードは、パフォーマンス アクティビティ ログと組み合わせることで、IT 管理者がパフォーマンスの異常または低下を特定のインフラストラクチャ変更イベントに関連付けるのに役立ちます。 CSP のビルドアウトと構成に関する情報が公開されていないクラウドベースのインフラストラクチャの場合、このクラスのツールを使用することで、組織はクラウド インフラストラクチャが変更されたことを容易に検出できます。 この証拠があれば、独自の構成に変更を加えて補正するタイミングと場所を容易に決定することができます。
統合されたセキュリティ ツール
DSP は、パブリック クラウドに格納されているデータを保護するのに使用できますが、オンプレミスのデータ ストアでも役に立ちます。 クラウド サービス プロバイダーは、DSP と同じ機能の多くを実行する統合データセキュリティ ツールを提供しています。 たとえば、Azure SQL Database インスタンスを管理する人は、Azure portal 内のデータの検出および分類機能を使用して、クレジット カード番号、社会保障番号、ログイン資格情報などの機密データが含まれている可能性がある列がないか、データベースをスキャンすることができます (図 6)。 また、Azure には、データベースをスキャンして潜在的な脆弱性が存在していないかを調べ、それらを解決するための実用的な手順を提示する無料の脆弱性評価サービスも用意されています。
図 6: Azure SQL Database でのデータの検出と分類。
現在、ほぼすべてのクラウド ストレージ サービスにおいて、データ アクセスをドキュメント化する監査証跡が作成され、多くのものが (特にデータベース サービス) アクティブな脅威の検出もサポートしています。 さらに、Microsoft、Amazon、Google などの主要なクラウド サービス プロバイダーは、データ ストアに限定されない幅広いクラウド リソースを監視できる包括的な脅威検出サービスを提供しています。 たとえば、AWS では Amazon GuardDuty を使用して、悪意のあるアクティビティや不正な動作を継続的に監視することで AWS アカウント、ワークロード、およびデータを保護することができます。 マネージド ルール セットを、AWS で発生する数十億のイベントに基づく機械学習と組み合わせることで、リアルタイムで脅威が検出されます。さらに、Amazon CloudWatch などの他のサービスと統合することで、脅威の検出時にはアラートがトリガーされ、(AWS Lambda を介して) 修復アクションも実行されます。
参考文献
- The New Stack。 Microsegmentation: How VMware Addresses the Container Security Issue (マイクロセグメンテーション: VMware でコンテナーのセキュリティ問題に対処する方法)。 https://thenewstack.io/microsegmentation-how-vmware-addresses-the-container-security-issue/。