D05 - セキュリティコンテキストの維持
強力なハードウェアへの投資を回収するためには、一つのホスト上にできるだけ多くのコンテナを直接配置することが適切に思えるかもしれません。
セキュリティの観点からすると、コンテナごとにセキュリティコンテキストやセキュリティステータスが異なる可能性があるため、これは多くの場合疑わしいものです。
同じホスト上のバックエンドコンテナとフロントエンドコンテナは情報セキュリティの価値が異なるため一つの懸念事項となるでしょう。より大きな問題は本運用環境とテストや開発環境などが混在していることです。本運用システムは利用可能である必要があり、開発コンテナには必ずしもセキュアではないコードが含まれているかもしれません。一方が他方に影響を与えるべきではありません。
マルチテナント環境では最大限の配慮が必要です。
脅威シナリオ
大学生がある会社でアルバイトをしています。彼は PHP プログラミングを学んだばかりで、自分の成果物を会社の CD チェーンにデプロイしています。この会社のリソースは限られており、すべてのコンテナを提供する非常に少数の大きく強固なホストしか購入していませんでした。この環境は急速かつ歴史的に成長してきたため、本運用環境とテスト環境やプレイグラウンド領域を分けるリソースを誰も持っていませんでした。残念なことに、この学生のアプリケーションにはリモート実行の脆弱性があり、インターネットスキャンボットが発見してフィンガースナップエクスプロイトを行いました。つまり、アプリケーションから抜け出してコンテナに入ってしまったのです。この脆弱性を利用して、攻撃者はネットワーク上で買い物をし、オーケストレーションツールのセキュアではない etcd または http(s) インタフェースのいずれかにアクセスしました。あるいは Dirty COW [1] と同様の脆弱性を持つエクスプロイトをダウンロードして、すべてのコンテナを含む大きく強固なマシンへの即時ルートアクセスを付与します。
これは少し誇張したシナリオです。大学生を社内開発者に入れ替えてみてください。外部からそのアプリケーションを見ると明らかですが、彼には見えてない一つの間違いをしただけです。
また、会社をコンテナサービスを提供する別の会社に入れ替えてみてください。さらに開発者を CaaS (Container as a Service) 会社のクライアントに入れ替えます。 CaaS を提供している会社のあるクライアントが学生と同じような間違いをしたとすると、最悪の場合 CaaS 環境全体の可用性、機密性、完全性に影響を与えるかもしれません。
どうすれば防ぐことができるのか？
脅威シナリオの一部が意図的に誇張されているように見えたとしても、以下のことを理解しておく必要があります。
一般的な経験則として、異なるセキュリティステータスやコンテキストを持つコンテナを混在させることはお勧めできません。
本運用コンテナを別のホストシステムに配置し、このホストにデプロイする権限を誰が持っているかに注意します。このホストには他のコンテナを置いてはいけません。
データの情報セキュリティの価値を考えると、コンテキストに応じてコンテナを分けることも検討すべきです。データベース、ミドルウェア、認証サービス、フロントエンド、マスターコンポーネント (Kubernetes などのクラスタのコントロールプレーン) を同じホスト上に置いてはいけません。
VM (仮想マシン) は本運用とテストなどさまざまなセキュリティコンテキストを互いに分離するために一般的に使用できます。これは物理的なハードウェアが不足しており、一つのハードウェアで異なるテナントを実行する必要がある場合の最低要件です。
どうすれば見つけ出せるのか？
外部監査員としてはシステムのアーキテクチャを説明してもらうのが一番です。 さらにベアメタルシステムにログインすることで VM プロセス (例 qemu-system-x86_64) や docker プロセスのみが実行されているかどうかを確認できます。 QEMU プロセスや virsh list --all は少なくとも仮想化 KVM が実行されていることを示唆します。これらの VM の内部に何があるかは VM にログインして解析するのが一番です。 QEMU を含む KVM/libvirt は独自のカーネルを使用する Linux での仮想化テクノロジの一つです。他にも VirtualBox, VMWare, Xen があります。
いずれにしてもシステムの分離がセキュリティコンテキストを反映しているかどうかを見極めることが重要です。
参考情報
Last updated