情シス部隊必見！クラウドネイティブに乗り遅れないためのコンテナセキュリティ対策

　ビジネスの拡大やスピードの加速といった観点からクラウドネイティブ技術への注目が高まっています。

　ただし、クラウドネイティブの推進に向けてセキュリティ部分の強化を検討しているが、コンテナ領域は従来情シス部隊でも触れてきていないため、コンテナについての知見がない、コンテナセキュリティはなにをやってよいかわからないという企業のご担当者も多くいます。

　今回は、クラウドネイティブにおけるセキュリティ課題について、特にコンテナに着目し必要なセキュリティ対策や対応方法について紹介します。

▼ 目次
１．DXにおいて注目されるクラウドネイティブ
２．クラウドネイティブにおけるセキュリティ課題
３．コンテナセキュリティに必要な検討要素
４. 各要素に対するセキュリティソリューションカバー範囲

１．DXにおいて注目されるクラウドネイティブ

　昨今、ビジネスの拡大やスピードの加速といった観点からクラウドネイティブ技術への注目が高まっています。

　クラウドネイティブ技術は「パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらすもの(CNCF Cloud Native Definition v1.0)」という定義がされており、具体的なアプローチ方法にAWSなどのIaaS/PaaS、コンテナ技術などがあげられます。

　これらの技術を活用していくことはビジネス変革の推進につながる一方で、セキュリティの観点では従来の考え方やソリューションでは十分な対応ができないことが多く課題となっています。

2. クラウドネイティブにおけるセキュリティ課題

　企業がクラウドネイティブに移行するにあたって、考慮すべきセキュリティ上のポイントとして「新たな攻撃対象領域」や「従来の境界防御では守れない領域」があり、具体的には下記の領域があげられます。

クラウドサービスへのアクセス経路
クラウド上で行われるアクティビティ
クラウドの設定
コンテナやサーバレス関数

　各領域での具体的な脅威については、下記のドキュメントにまとまっています。
以下をクリックすると各ページがご覧いただけます。

一般的に知られている脅威についての情報

クラウドネイティブを狙った攻撃手法
- ATT&CK for Enterprise Cloud Matrix
- Threat Matrix for Kubernetes

　また、クラウドの設定ミスによる情報漏洩対策に関する対応策については、ビジネスonIT「CSPMとは｜クラウドの設定ミスによるセキュリティリスクを抑制、管理を徹底する」に詳細を記載しておりますのであわせてご参照ください。

　上記のようなクラウドネイティブのセキュリティ課題の中でも、後手になりがちなのがコンテナへのセキュリティ対策ではないでしょうか。

　CaaSやKaaSによって企業でのコンテナ導入のハードルは下がっている一方で、情報システム部門の担当者を主な対象として実施した弊社独自のアンケートでは、「自社でのシステムでKubernetesを活用したシステムの検討・利用状況」について、88%が「担当ではないためわからない」と回答しており、多くの場合コンテナ推進は情報システム部の主導ではないことが考えられます。

　セキュリティ対策についても、従来は情報システム部のセキュリティ担当者が中心となり進めていましたが、コンテナのセキュリティ対策は追いついていないと考えています。

　昨今ではコンテナ特有のセキュリティ対策ができていなかったことにより、攻撃や情報漏洩が起きたという例もよく聞かれる様になっています。

　特に最近はとあるthreat actor(サイバー攻撃集団)がDockerやKubernetesを狙ったマルウェアを攻撃キャンペーンに利用するなど、より高度な攻撃の対象になるケースも増えており、組織としてコンテナセキュリティを考える重要性が深まっています。

3. コンテナセキュリティに必要な検討要素

　一口にコンテナセキュリティといっても、コンテナを構成するモジュールごとにセキュリティの考え方は異なります。今回は特にコンテナセキュリティ特有の課題になりがちな「コンテナイメージの保護」と「コンテナ実行時の保護」の2点に絞り、それぞれのセキュリティ課題と必要な検討要素について解説します。

コンテナイメージの保護について

　コンテナイメージは、コンテナ環境で実行するアプリケーションや実行に必要なコンポーネント、メタデータを含んだテンプレートです。従来のサーバシステムとは異なり、コンテナの世界では、これらのイメージに実装したいアプリケーションのコードや、必要なコンポーネントを入れてDockerなどのコンテナ基盤で実行することで、各々のコンテナイメージが一つのアプリケーションを実行するコンテナとなります。作成したコンテナイメージはレポジトリと呼ばれる保存領域に格納することで、他プロジェクトや第三者との共有が可能です。

　コンテナを使ったアプリケーション開発では、都度、ゼロベースからイメージを作成するのではなく、公開レポジトリからコンテナイメージをダウンロードしてくることで、アプリケーション開発の速度や移植性でメリットを享受できます。

　攻撃者は、上記のコンテナ開発の特徴を理解し、コンテナへ攻撃をするためにコンテナイメージにマルウェアを事前に仕込んでおくといった手段をとることが知られています。

　従来のサーバシステムでは、サーバなどのエンドポイントにアンチマルウェア製品をインストールしマルウェアの対策を行いますが、コンテナでは従来のエンドポイント型ソリューションがサポートされておらず、そもそもインストールできないことが多いため、開発段階でのセキュリティ対策が重要となります。

　また、悪意がないユーザであってもコンテナイメージの管理を間違えることで重大なセキュリティリスクが発生する可能性があります。具体的には下記があげられます。

イメージ内に機密情報を平文で埋め込み、パブリックなレジストリに配置する
脆弱性が残っている古いコンポーネントを利用する

　このようなセキュリティリスクにおいては、コンテナイメージを作成するアプリケーション開発者側のセキュリティ意識によるところも大きいですが、組織としてどのレベルの脆弱性を許容するかなどのルール作りも必要です。

コンテナ実行時の保護について

　コンテナイメージからコンテナを作成し、起動することでコンテナが実行されます。実行中のコンテナは、例えばhttpdが実行されていればwebサーバとして動作し、mysqlが実行されていればDBサーバとして動作しますが、コンテナの基本的な使い方として1つのコンテナには1つのアプリケーションのみを実行させることが一般的です。

　実行中のコンテナを攻撃する際も、基本的には従来のサーバシステムと同様に公開されているポートなどに対してネットワークレベルでアクセスし、脆弱性を狙った攻撃や、不正なプログラムを送りこんで実行させるなどして、コンテナ内に侵入します。

　ネットワークレベルでの攻撃のためIPS/IDSやWAFなどで攻撃をブロックすることはできますが、前述した通りコンテナ自体に従来のサーバ保護製品などをインストールすることができず、エンドポイント側での防御や侵入の検知が難しいという課題があります。

　また、攻撃者はコンテナへの侵入を達成すると、他コンテナやコンテナが実行されているホスト自身に対して横展開や侵入を試みます。コンテナ間のトラフィックは厳密に制御されていないことも多く、重要サーバへ簡単にアクセスを許してしまうケースや、ホストの脆弱性やコンテナ実行権限の設定不備などを突かれて簡単にホストへの侵入を許すといったケースもあるため、コンテナ間のネットワークやコンテナを実行するホストに対しても同じレベルのセキュリティ対策が必要になります。

4. 各要素に対するセキュリティソリューションカバー範囲

　ここまでコンテナのセキュリティ課題に対して説明しました。対策のアプローチは様々ですが、今回はコンテナに特化したセキュリティソリューションとしてCWPPの活用をご紹介します。

　CWPP(Cloud Workload Protection Platform)はガートナーが2018年に定義した新しいソリューション形態です。クラウドネイティブ環境での統合ワークロード保護製品としてコンテナに特化した機能を有しています。様々な機能を持っている製品が多いですが、コンテナセキュリティでは主に下記のような機能を活用します。

イメージスキャン
ランタイム監視

イメージスキャン

　ベースイメージの取得時や新規作成、修正時にマルウェアや脆弱性などが埋め込まれていないかをスキャンし、イメージごとにリスク分析・評価を行います。

　例えばイメージ内のコンポーネントに脆弱性があった場合、脆弱性の個数や重大度(CVSS値やベンダー独自視点の指標など)に応じて、そのイメージを利用させなくすることで環境内に重大な脆弱性を持ったシステムがリリースされることを防ぐことができます。マルウェアを検知した場合も同様に、コンテナイメージが実行される前に検知することが可能となります。