コンテナセキュリティに欠かせないもの

クラウドネイティブなアプリケーションが急増し続ける中、コンテナはアジリティと拡張性を備えていることから、こうしたアプリケーションをパッケージ化してデプロイするための手段として注目されています。事実、Gartnerの推定によると、世界中の組織の75%が、コンテナ化したアプリケーションを本番環境で稼働させています。

一方、コンテナの人気が高まっていることで、アプリケーションを悪用する新たな方法を探しているハッカーたちをも惹きつけています。コンテナが、組織のアタックサーフェスを拡大し、収容しているアプリケーションに対するリスクを増大させます。そのため、コンテナ化したアプリケーションとインフラストラクチャのリスクを低減するための総合的なセキュリティ・アプローチが必要不可欠です。

コンテナの正体

物理的なコンテナは本来、物資を貨物船で輸送しやすくするために作られたものですが、物資の梱包方法も標準化され、発達してきました。イタリア製のスポーツカーも、南アフリカ産のコーヒーも、コンテナに収められて出荷されます。このことによって標準化と簡素化が推進され、国際貿易と経済成長の爆発的な発展をもたらしました。

そして100年を経た現在、Dockerのエンジニアたちがアプリケーション向けのコンテナ技術を開発したのも、その目的は、開発者のノートパソコンから本番環境へのソフトウェアの「輸送」を簡素化することでした。コンテナは、ライブラリやシステムツールなど、アプリケーションが実行する必要があるあらゆる物を、複数の環境にデプロイできる単一のイメージにパッケージ化します。これは、クレーンとフォークリフトを使って貨物船や飛行機、列車に簡単に積み込める物理的なコンテナとまったく同じです。

しかしこの技術は、それ以前にも仮想マシンという形で存在していました。ではなぜ仮想マシンを使わないのでしょうか？ なぜコンテナなのでしょうか？

コンテナは、パッケージ化ツールとして開発されています。あるアプリケーションとその依存関係のあるコンポーネントだけを1つのコンテナに納め、コンテナ実行環境に配置して実行し、意図した通りに機能させることができます。しかし、コンテナは OS を含みません。これに対して仮想マシンは、完全なゲスト OS です。仮想マシンはアプリケーションと依存関係をその OS に階層化するため、ハードウェアの仮想化やその他の要因によって、オーバーヘッドが著しく増大します。

コンテナのオーケストレーション

オーケストレーションを使用すると、組織は大規模なコンテナ環境の構成、管理、デプロイを自動化し簡素化することができます。Kubernetesなどのオーケストレーション・プラットフォームが、コンテナ化したアプリケーションを大規模に管理するための事実上の標準となっています。

しかし多くの組織が、オーケストレーション・プラットフォームのセキュリティについて誤った思い込みをしていて、これがアプリケーションを危険にさらす可能性があります。Google GKEなどのサードパーティーのオーケストレーション・サービスプロバイダーを利用していても、ホスティング責任を共有している性質上、誰が何のセキュリティの責任を負うのかがわかりにくくなっています。

コンテナセキュリティのベストプラクティスのベンチマーキング

どのようなコンテナセキュリティのオーケストレーションプログラムも、コンテナ自体の作成とその中身のセキュリティとリスクが考慮されていなければなりません。コンテナセキュリティには、ベストプラクティスと、プログラムを分析するための基準がいくつかあります。例えば、ホストセキュリティの基本的要素、プラットフォームセキュリティ要素、コンテナとオーケストレータ自体の要素などです。

コンテナとコンテナオーケストレーションのセキュリティに取り組むときには、アプリケーションのアーキテクチャ、デプロイ、本番環境を網羅する全体的なアプローチを取ることが重要です。

コンテナのセキュリティを検討する際は、以下を含めてください

• 悪意のある、あるいは侵害されたコンテナ
• ローカルネットワークへの攻撃
• 外部ネットワークからの攻撃
• 悪意のある開発者／ユーザー
• 構成のベストプラクティス
• シークレットの管理
• コンテナのデリバリー
• ロールベースのアクセス制御の分析
• コンテキストに応じた包括的な攻撃シナリオの分析

検討すべき攻撃シナリオとして以下を含めてください

• パブリックネットワーク上の悪意のあるエンティティ
• 隣接ネットワーク上の悪意のあるエンティティ
• 悪意のある内部関係者／開発者
• 悪意のある／侵害されたアプリケーションコンテナ
  • コンテナからホストへ
  • コンテナからネットワークへ
  • コンテナからコンテナへ
  • 名前空間から名前空間へ
  • クラスタからクラスタへ

これらのシナリオを追跡し、整理するには、攻撃マトリックスを作成すると便利です。例えば、Kubernetesの攻撃マトリックスには、初回アクセス、実行、持続性、特権エスカレーション、防御回避手段、資格情報アクセス、検出、横移動、影響などの要素があります。

コンテナセキュリティの5つのリスク

Black Duckの評価で明らかになった一般的なコンテナの脆弱性は、以下のとおりです

• コンテナイメージのセキュリティ
• セキュアなデフォルト設定／ハードニング
• 機密情報の管理
• ネットワークセグメンテーション／ファイアウォール設置
• ポリシーの実施

これらの脆弱性とコンテナ・セキュリティに必要不可欠なものの詳細について、当社のオンデマンドのWebセミナーで学ぶことができます。

Black Duck の支援内容

社内に強力なコンテナのセキュリティプログラムを実装することは、簡単ではありません。コンテナセキュリティのベストプラクティスの詳細について、当社の次のオンデマンドWebセミナーで学ぶことができます：「Container Security Essentials（コンテナセキュリティに欠かせないもの）」および「Finding Your Way in Container Security（自社に合ったコンテナセキュリティの方法を見つける）」。

コンテナセキュリティを使い始めたばかりでも、何年も使っている場合であっても、堅牢でセキュアなコンテナのセキュリティプログラムを構築するには、主な機能を理解している必要があります。このホワイトペーパーは、どのような要素がセキュアなコンテナをもたらし、コンテナセキュリティの取り組みを推し進めるのに役立つのか、その青写真を示します。