クラウドネイティブセキュリティの7大神話を暴く #aqua #コンテナ #セキュリティ #kubernetes #クラウド #CSPM #クラウドネイティブ

本ブログは「Aqua Security」社の技術ブログで2021年2月8日に公開された「 Debunking the Top Cloud Native Security Myths 」の日本語翻訳です。

クラウドネイティブセキュリティの7大神話を暴く

---

クラウドネイティブセキュリティには、まるで神話のような話がたくさんあります。私たちはこれらの神話トップ７を独自にリストアップしました。そのうちトップ2は、クラウド環境でのコンプライアンスと、クラウドプロバイダーの責任に関するものです。

神話１：旧来と同じ手法でも、クラウドネイティブ環境でのコンプライアンスは達成できる

多くのコンプライアンス規制者は、クラウドネイティブ環境特有のプロセスや成果物に関連する具体的なガイドラインを盛り込んでいません。皮肉なことに、このようなガイダンスがないにもかかわらず、他の環境でコンプライアンス要件を満たすことが出来た旧来の手法が、クラウドネイティブアーキテクチャでも同じ要件を満たすと考えてしまう傾向があります。規制当局が定めた概念に沿った「ベストエフォート」を、十分な情報に基づいて実証することが望ましい目標です。

クラウドネイティブ環境では、一般的にコンポーネントやレイヤーのコントロールが互いに別々に更新されることになります。例えば、以前は VM のみを堅牢にしてマルウェアをスキャンしていましたが、今では VM に加えてコンテナイメージのスキャンも必要であり、さらにオーケストレーターもスキャンして堅牢にすることが重要になります。また、イベントを監視してログを記録し、セキュリティ制御が適切に行われていることを証明する必要があります。

具体的な例として PCI DSS のガイドラインでは、PCI システムと非 PCI システムを分離することが求められています。このガイドラインでは、「スコープ外のシステムがスコープ内のシステムコンポーネントを危険にさらすために使用できないことを合理的に保証する」方法として、ファイアウォール・物理的アクセス制御・多要素認証・アクティブモニタリングおよび管理者アクセスの制限が挙げられています。

マルチテナントの Kubernetes クラスタで PCI DSS が要求する分離レベルを達成するためには、個別のレジストリとパイプラインを用意し、Kubernetes Namespace でエンティティを分離し、管理者ごとにリソースを分割する必要があります。分離をさらに強化するために、これらの Namespace 内で適切なラベル付けとタグ付けを行う必要があります。また、RBAC は希望するセグメンテーションの違反を防ぐために、セキュリティツールが使用するランタイムとファイアウォールポリシーへのアクセスを制御する必要があります。解釈は自由ですが、これらの制御が行われていることを証明できれば、ほとんどの監査人は完全に満足するでしょう。

神話２：アカウント設定とクラウドで実行されるワークロードの両方を、クラウドプロバイダーが保護してくれる

クラウドプロバイダーが負うことになる責任とそうでない責任、そしてどこにグレーゾーンが存在するのかを理解することは非常に重要です。例えば、AWS の責任共有モデルでは、クラウドの保護はクラウドプロバイダーの責任であり、「内側」の保護はユーザの責任であると簡潔に表現しています。これには、ユーザには次の2つの重要な責任があることが見て取れます。

1. クラウドプロバイダーは、ユーザのアカウントやサービスの安全な構成について責任を負いません。クラウドプロバイダーは多くのデフォルトのセキュリティ設定を提供していますが、その設定を確認し、アプリケーションのセキュリティ要件などに応じて追加の保護をするのはユーザの責任としています。ここでのセキュリティに対する誤った認識は、一連のサービスを適切に設定するのに必要な時間と労力を寡少に見積もってしまうことにつながります。ガートナーは、「How to Respond to the 2020 Threat Landscape」というレポートの中で、「2023年までに、クラウドのセキュリティ障害の 99％ 以上はユーザの責任によるものになるだろう」と述べています。

   EC2 インスタンス・S3バケット・Lambda function、監査用の CloudTrail を使用するだけで、これらのサービスは潜在的なデータ漏洩やセキュリティ侵害を防ぐために、すでに何十もの重要な設定を必要とします。しかし、組織内のクラウドアカウントにアクセスできる人なら誰でも設定できる Cloud Security Posture Management(CSPM)ソリューションを使えば、これらのミスを簡単に防ぐことができます。こちらからトライアル版をお試し頂くことができます。

2. クラウド上における「保護」のための公式は1つだけではなく、ユーザはそれに関わるニュアンスを学び、理解する必要があります。例えばクラウド上の Kubernetes は、EKS やオープンソースを介して AWS デフォルトの EC2 Amazon Linux 2 OS や、ユーザが選択した Linux OS を使って実現できます。これらの選択肢の間では共有責任モデルが大きく異なり、セキュリティ責任のフルセットを理解するためには、ユーザ側の学習が必要となります。上記のユーザが選択した Linux の例では、ユーザがゲスト OS とアプリケーションにパッチを適応しなければいけません。しかしEKSなどを使用する場合は、AWS がパッチを適用しなければいけません。

一般的によく言われている神話のような話がなぜ当てはまらないのかを基本的に理解するだけでも、効果的なクラウドネイティブセキュリティ戦略やクラウドネイティブジャーニー全体の計画の立て方をより正確に把握できるようになります。

７つの神話に関するホワイトペーパーは以下から入手できます。