Google Cloudとコンテナの継続的なセキュリティ
本文の内容は、2020年3月31日にSysdigのPawan Shankarが投稿したブログ(https://sysdig.com/blog/challenges-scale-prometheus/)を元に日本語に翻訳・再構成した内容となっております。
このブログでは、PCIコンプライアンスを達成するために満たす必要があるさまざまな要件と、Sysdig SecureがコンテナとKubernetesのPCIコンプライアンスを継続的に検証するのにどのように役立つかについて説明します。
クラッカーはクレジットカードのデータを盗むことが上達してきており、企業は毎年数十億ドルの罰金を科されています。これらのタイプの攻撃を防ぐために、Payment Card Industry（PCI）セキュリティ標準が作成され、リスクを軽減するために満たす必要のある一連の要件が追加されました。
アプリケーションの多くは、クラウド内のコンテナで実行され始めており、そこにはさらに多くの攻撃ベクトルがあります。そのような状況において、クラウドアプリケーションのコンテナコンプライアンスをどのように検証すると良いのでしょうか？
アプリケーションがクラウドに移行するにつれ、PCIコンテナのコンプライアンスを困難にするコンテナ化された環境の3つの主要な属性があります：
コンテナのスプロール: 仮想化が始まったとき、仮想マシン（VM）のスプロールという概念があり、これはVMの密度が増加した結果として生じました。 より多くのアプリケーションがコンテナ化されるにつれて、コンテナの無秩序な増加のコンセプトは、本質的にステロイド上のVMの無秩序な増加です。現在、マイクロサービスは数千のノードに分散されており、数百万のコンテナによってサポートされています。コンテナは上がったり、下がったりし、IPアドレスは常に変化しているため、あらゆる形式のPCI監査は非常に困難です。
コンテナの寿命: Sysdigの2019コンテナ使用レポートでは、コンテナの52％が5分以下の寿命であるのに対し、コンテナの6％は1週間以上の寿命があることがわかりました。PCI-DSSの要件を満たすことは、高速で変化するコンテナ環境においてより複雑になる可能性があります。さらに、39％のコンテナが1分以下しか存続しないため、コンテナが消えた後のコンプライアンスの証拠として、コンテナの詳細なアクティビティを記録する方法を確立する必要があります。コンプライアンス違反が発生した場合は、生成されたプロセス、行われた接続、変更されたファイルなどを確認する必要があります。また、このシステムアクティビティをユーザーアクティビティと関連付け、誰が何にアクセスしたかを理解できる必要があります。この詳細なデータにアクセスすることで、サードパーティの評価者に監査証跡を効果的に提供できます。
オープンソースのパッケージ: 今日のソフトウェアは、一から構築されたものではなく、組み立てられたものです。今日、革新、スピード、および低コストを推進する最も速い方法は、オープンソースを採用することです。開発者はオープンソースのベースイメージをプルし、サードパーティのライブラリを利用して、コンテナ化されたアプリケーションを構築およびスケーリングさせます。ただし、オープンソースを使用するには、自社のコードを更新するのと同じように、オープンソースの依存関係を更新することにも注意を払う必要があります。ベースイメージまたはJava JAR、Python PIPなどのライブラリから継承された脆弱性がある場合、リスクは組織にあります。また、数千のマイクロサービスをサポートする数十万のコンテナがある場合、脆弱性が本番環境に入るのを防ぐにはどうすればよいでしょうか。既知の脆弱性を防ぎ、新たに特定された脆弱性にフラグを立てることは、リスクを軽減するだけでなく、PCI監査に合格するためのステップです。さらに、公開されたポート、埋め込まれたアクセスキー、トークンなどのdockerfileの設定ミスは、コンプライアンス違反につながる可能性があります。Gartnerによると、2023年までに、クラウドのセキュリティ障害の少なくとも99％がお客様の責任です。
従来のツールを使用してプロセスを管理する場合、コンテナとKubernetesでは機能しません。コンテナの内部を見ることも、ビヘイビアを評価することもできません。ほとんどのコンテナトラフィックは、実際にはeast-westであり、north-southではありません。つまり、従来のセキュリティコントロールではほとんどのコンテナアクティビティが確認されません。また、クラウドやKubernetes環境に関する適切なコンテキストがないため、脆弱性をアプリケーションやネームスペースに関連付けることができません。最後に、これらのレガシーツールはDevOps用に構築されておらず、アプリケーションのデプロイ後に適用されるように設計されています。
コンプライアンスの検証は、アプリケーションデリバリーを高速化するための最大の阻害要因です。規制当局は、違反した場合の金銭的罰則をますます強化しています。
研究はそれを示しました：
Kubernetesは動的な環境であり、アセットがPCIコンプライアンスから外れたことを検出することは困難です。PCIガイドラインをこの新しい環境に明確にマッピングしないと、チームはコンプライアンス要件を満たしていることを証明できません。その結果、PCI監査への対応は費用のかかるファイアドリルとなり、クラウドチームへのアプリケーションのデリバリーが遅くなります。 Kubernetesコンプライアンスには新しいアプローチが必要です。
チームは、コンテナ化されたワークロードへのコントロールの明確なマッピングと、時間の経過とともにコンプライアンスを継続的に追跡する機能が必要です。これにより、セキュリティリスクを管理し、セキュリティ監査に合格する能力に自信を持つことができます。最終的には、コンプライアンスがクラウドの採用を妨げないようにする必要があります。これにより、企業はクラウドアプリケーションをより速くリリースできます。
Sysdig Secureは、コンテナおよびKubernetesライフサイクルのすべての段階にわたってPCIコンプライアンスを検証するのに役立ち、コンプライアンスがクラウド導入のブロッカーではないことを保証します。 PCIへの取り組み方のいくつかの例：
アウトオブボックスのポリシー - PCI 1.1.6および6.1要件
SysdigはデフォルトのPCIスキャンポリシーを提供し、PCIコントロールに関連するスコープに基づいてポリシーをカスタマイズします。 これらのポリシーは、レジストリ、コンテナ、Kubernetesの脆弱性と設定ミスを検出するための単一のワークフローを提供します。
Sysdigは、インフラストラクチャー上のすべてのホスト、コンテナ、およびプロセスのトポロジーマップを動的に生成し、それらがネットワークの内外で行うネットワーク接続をマップします。これらのトポロジーマップは、論理サービスとそれらの接続方法を示すようにカスタマイズすることもできます。
Sysdigには、システムで実行されているメタデータによってグループ化されたすべてのホスト、コンテナ、またはプロセスのビューを提供するエクスプローラービューが付属しています。このテーブルを使用して、選択したすべてのシステムコンポーネントをスライスおよびダイスできます。
Sysdigは、デプロイメント定義のポッド仕様の要件を分析し、アプリケーションの最小特権PSPを作成します。これにより、特権付きポッド、ユーザーがコンテナ、ボリュームなどとして実行できるようにするかどうかをコントロールします
Sysdigは、すべてのコンテナインフラストラクチャーイベントの継続的な監査を提供して、インシデント対応とPCI-DSSコンプライアンスを促進します。これは、コンテナがなくなった後でも、第三者監査人のコンプライアンスの証明として使用いただけます。
Sysdig Secureがより多くのPCIコントロールをマップして対処する方法をさらに詳しく調べるには、以下のリソースのいくつかをチェックしてください。
