コンテナセキュリティ入門【後編】

• 
• 

ビジネス開発本部 第３応用技術部
第２チーム
松尾 咲季

マイクロサービスの保護

コンテナセキュリティ入門【前編】 ではコンテナアーキテクチャの特性を踏まえ、インフラのセキュリティレベルを上げるために考慮が必要となる機能・設定について説明しました。後編は、コンテナ上で稼働するアプリケーション（ランタイム）に焦点を当てたいと思います。

コンテナも従来型のサーバと同様、コンピューティングリソースやネットワークリソース、データベースを活用しサービスを提供します。そういった意味で、想定されるサイバー攻撃、およびその対策が大きく異なるということはありません。インターネットから不特定ユーザのアクセスを受けるアプリケーションは、スクリプト攻撃、ポートスキャンなどの偵察、サービス不能攻撃、攻撃が成功した後のデータ抜き取りやボットネットなどが脅威です。それらに対して、ゲートウェイ型の UTM/Next Generation Firewallや、ロードバランサーと連携した IPS、WAF、Anti-virusなどの従来型の保護が一定の効果をもたらすでしょう。

しかしながら、コンテナの性質上、これらが必ずしも効果的・効率的に機能しない側面もあります。例えば、アプリケーションランタイムを格納するコンテナは頻繁に停止・削除、スケールされます。これをIPアドレスやポートベースでタイムリーに制御するのは困難です。加えて、保護対象のアプリケーションは恐らくクラウドネイティブな性質を持ち、SSLで暗号化されます。ここから脅威を見つけるには、トラフィックを復号化した上、対象となるアプリケーションのインテリジェンスを以ってアノマリーを見つける必要があるでしょう。

また、コンテナ上のアプリケーションは、従来のモノリシックな性質から、マイクロサービスへシフトしつつあります。マイクロサービスはコンテナをまたいだトラフィックが多く発生し、これらは前編で触れた Network PolicyなどでL3レベルの制御はできるものの、プロセス単位まで分割されたサービス間の複雑に入り組んだトラフィックを、手動作成のポリシーで制御するのは煩雑です。

攻撃者の侵入成功を想定した対策も必要です。アプリケーションのエクスプロイトに成功し、それを足がかりにホストOSや他のコンテナへの不正アクセスを行おうとした場合、或いはデプロイされたコンテナイメージの中にマルウェアが含まれており、感染を横展開するトラフィックを他のコンテナに向けたとき、それらを検知するには、コンテナ間の通信に対してUTM/Next Generation Firewallに相当するレベルの検査機能が必要でしょう。

コンテナアプリケーションの性質を踏まえ、これらの保護に求められる要件には以下が含まれます。

• スケーリングなどの構成変更に応じてセキュリティポリシーが自動で追従すること
• クラウドネイティブなアプリケーションを適切に識別・検査できること
• セキュリティ境界をランタイム寄りに配置し、垂直方向だけでなく水平方向のトラフィック制御も行えること

上記を部分的あるいは包括的に満たすには、コンテナセキュリティに特化したエンタープライズ向けサービス・製品を検討するのが近道です。例えば Palo Alto Networks社の Prisma Cloud Compute （旧Twistlock）のランタイム防御機能は、コンテナ内で稼働するイメージごとに典型的なプロセス動作、ネットワーク動作、ファイルアクセス、システムコールなどを機械学習にてモデル化し、逸脱する動作が検知された際はアラートやブロックなどのアクションを取ることができます。新規にコンテナがデプロイされると、ネットワーク制御やsyscallの制御を行うデーモンがコンテナ内に常駐し、管理者が手動でポリシーを設定せずともコンテナイメージの適正に合わせた制御をある程度自動で実装できる仕組みを持っています。

近年、IT業界ではコンテナセキュリティやクラウドネイティブアプリケーションの保護を一元的に提供する大規模ベンダが増えています。セキュリティベンダでは、クラウドワークロード保護プラットフォーム（cwpp）、脆弱性診断サービス、エンドポイントセキュリティなどで知られる大型ベンダにて、買収や機能強化の動きが見られます。他にもオンプレミスおよびパブリックのプラットフォームベンダや、ITインフラのモニタリングを専門とするベンダなどで、コンテナセキュリティ関連のソリューションが展開されており、今後も動向が注目されます。

コンテナイメージの保護

• DevOpsにおけるセキュリティ対策

コンテナは軽量、迅速、可搬性などの利点から、スピードとコラボレーションが重視されるDevOps環境の基盤として利用されることが多くなっています。DevOpsにおけるセキュリティと言えば、DevSecOpsや Shift Leftなどのキーワードがトレンドとしてありますが、これらは開発・運用の初期段階およびプロセスの中にセキュリティ対策を組み込むことで、手戻りによる追加工数を減らそうという考え方です。DevSecOpsが関連する要素には開発コードのセキュリティやAPIの保護などが含まれることもありますが、ここではアプリケーション実行環境となるコンテナイメージの保護と、それを格納するレジストリ・リポジトリの保護に絞って必要な対策を説明します。

• コンテナイメージと脆弱性

コンテナイメージの実態の多くは WebサーバやSQLサーバなどのベースイメージに、システムライブラリ、プログラミング言語、設定ファイル、その他依存性のある関連ファイルなど、プログラム実行に必要な依存関係がパッケージ化されたものです。イメージに含まれるほとんどのコンポーネントがオープンソースで構成されており、オープンなだけにそれぞれ何らかの脆弱性に該当することが既知であるか、未知の脆弱性が明日にでも公開されることを想定する必要があります。脆弱性はベースイメージに含まれる場合もあれば、ライブラリが該当する場合もあり、該当するCVEが皆無のものはほとんどないと思った方がよいでしょう。実際、最も有名なコンテナレジストリである Docker Hubに公開された上位1000の人気コンテナイメージのうち、五分の一がクリティカルレベルの脆弱性を内在しているとの調査報告もあります。

またパブリックに公開されたコンテナイメージに仮想通貨マイニングなどのマルウェアが仕込まれており、それをデプロイしたコンテナがバックドアとなる事例も多数あります。DevOpsを保護するためには、まずデプロイ前のコンテナイメージがクリーンであることを保証し、その後も継続的に脆弱性やマルウェアの有無をスキャニングした上で、開発・運用のパイプラインをヘルシーに保つ仕組みが必要です。

• レジストリ/リポジトリの保護

これを実現するために有効なのが、DevOpsで利用するコンテナイメージをプライベートなレジストリに保存し、適宜スキャニングする運用です。SaaS型の有償レジストリには、脆弱性スキャニング込みでサービス契約可能なものもあり、リスクを含むコンテナイメージを検出すると、自動でロックダウンするポリシーを適用するなどの機能を持ちます。コンテナイメージの保護という観点では、開発ツールなどでコンテナイメージを署名し、それを取得或いはデプロイする際に、コンテナイメージが信頼できるものであり、改ざんされていないことを検証するプロセスを加えることも効果的です。

外部レジストリとローカルレジストリのスキャン機能を持つセキュリティ製品を導入するオプションもあります。セキュリティ専用ベンダは脅威インテリジェンス情報が充実しており、脆弱性の性質（リモート実行可否、DoS、ゼロデイ、etc.,）に応じてパッケージ内の該当コンポーネントをソートできるなどの機能を持つものもあります。またコンテナの構成管理機能付きの製品であれば、コンテナイメージが稼働するノードやコンテナ名を可視化し、通信要件や監査情報と併せて確認できます。脆弱性が日々発見されているのはコンテナ環境に限った話ではありませんが、それが自社のシステムにどのような影響を与え得るか判断する材料として、脆弱性情報とコンテナの構成情報が一体化したツールがあることは助けになるでしょう。

終わりに

本コラムではコンテナの需要とセキュリティ強化の必要性に触れ、特にフォーカスすべき 3つのポイントであるインフラの保護、マイクロサービスの保護、コンテナイメージの保護について記載しました。NetOne Systemsは、これらの課題を解決し得る製品を取り扱っています。それについては別の機会に説明したいと思います。

執筆者プロフィール

松尾 咲季
ネットワンシステムズ株式会社 ビジネス開発本部 第３応用技術部 第２チーム所属
オンプレミス、クラウドのセキュリティ商材を評価、検証し、提案や導入支援を行う業務に従事
・CISSP
・AWS Speciality - Security
・Cisco CCNP Security
・Palo Alto Networks PCNSE

• 
• 

ピックアップ

ナレッジセンターを検索する