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

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

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

コンテナの正体

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

シノプシスの支援内容

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

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