コンテナセキュリティ リスクと対策

コンテナ環境のセキュリティを考える際に重要となるのが「コンテナ特有のライフサイクル」を踏まえた対策ができるかどうかです。 コンテナ環境はサーバ、ネットワーク、ホストOS、コンテナで動作するアプリケーションだけで成立するものではなく、コンテナイメージ、レジストリ、オーケストレーションツール、コンテナランタイムなど、コンテナのライフサイクルにおいて特有の登場人物があり、これらを考慮したセキュリティ設計が求められるのです。コンテナ環境のセキュリティを考えるうえで踏まえておくべきポイントは下記の6つに分類できます。

① 安全なコンテナイメージを利用
② コンテナレジストリの保護
③ オーケストレーションツールの保護
④ アプリケーション､ネットワークの保護
⑤ コンテナホストの保護
⑥ ビルドパイプラインの保護

今回は上記の③と④についてご説明差し上げます。

図１ : コンテナのライフサイクルとセキュリティのポイント

　例えば、大規模なコンテナ環境を構築して運用する場合、何十･何百というコンテナ、あるいはこれらが稼働するたくさんのコンテナホストを「コンテナ単位」「コンテナホスト単位」で管理運用していくことになります。この時、コンテナが外部と通信するためのNATの設定や、コンテナで障害が発生した際のコンテナ再起動、コンテナホストのリソース状況の監視結果から適切な負荷分散の判断･実施などを、手動で行う必要が出てきます。小さなコンテナ環境であれば担当者のマンパワーで乗り切ることもできるでしょう。しかし、大規模環境ではそうはいきません。そこで登場するのがコンテナオーケストレーションツールです。現在ではDocker環境に対するオーケストレーションツールとしてKubernetesが有名ですね。今回の記事では、Kubernetesの詳細説明は割愛しますが、このツールはコンテナに対して広い作用を持ち、「セルフヒーリング（コンテナに障害が発生すると、自動的にコンテナを再デプロイ）」「オートスケーリング（負荷に応じたコンテナ数の自動増減）「リソースマネジメント（管理下ホストのリソース状況を監視して、コンテナを特定のホストに偏らないように最適な配置にする）」など、コンテナ環境の運用を自動化することができます。結果として、運用担当者に多くのメリットをもたらしてくれます。
　しかしこのKubernetes、できることが多くて便利な反面、攻撃者から見ると「悪用すればコンテナ環境を操れる」ような、言うなれば好都合な攻撃先とも言えます。Kubernetesを不正利用されないために、API接続する際の認証を適切に行う、過剰な権限を付与しないなどのことは当然、考慮しなければならないセキュリティと言えますが、一方でこのKubernetesに脆弱性が見つかることもあり、この点にも注意が必要です。例えば2019年にはkubecltにディレクトリトラバーサルの脆弱性（CVE-2019-11249）が見つかったり、2020年にはkube-proxyに認証関係の脆弱性（CVE-2020-8558）が見つかったりしています。
　Kubernetesに不正アクセスさせないために、認証や権限設定は確実に行ったうえで、脆弱性対策のために最新バージョンのKubernetesを利用する、そして脆弱性対策機能をホストOSで実装する、あるいはネットワーク系路上で実装するなどの対応が求められます。

　「アプリケーションとネットワークは別物なのに、なぜここでは一緒にしているのか」という疑問をお持ちの方もいらっしゃるかと思います。たしかに概念としては別物です。しかし、コンテナを用いて設計された環境は、従来の物理・仮想マシンベースのサーバシステムとは異なり、いわゆる「マイクロサービス化」されています。複数のアプリケーションを単一のホストに同居させ、サービスをモノリシックに作るのではなく、小さなサービスをAPI・ネットワークで接続して作り上げるアーキテクチャ、それがマイクロサービスです。そしてコンテナで構築されたシステムは、コンテナという単位でアプリケーションが稼働し、コンテナ間で多数の通信が常に発生する、という状況が生まれます。ただし、同一ホスト上のコンテナ間通信はコンテナエンジン・ホストを経由して発生するため、従来のネットワーク経路上でセキュリティを実装するという発想が通用しないケースが出てきます。
そこで、コンテナ環境のネットワークセキュリティを考える際には「コンテナに出入りする通信」を「アプリケーションレベルで対策する」と考えることで、漏れなく効果的にセキュリティを実施することができるのです。アプリケーション自身が安全なものであるかの確認はもちろんのこと、これが利用する通信もアプリケーションレイヤーでスキャンする方式こそが、よりコンテナの特徴にフィットしたセキュリティと言えるでしょう。
　このような保護手法として、近年注目されているのがRuntime Application Self Protection（RASP）です。RASPは、アプリケーションそのものにセキュリティ機能を組み込む方式のため、コンテナ環境やサーバレス環境（例えばAmazon ECS,EKSやAWS Lambdaなど）を守る方法として最適です。このRASPの概要についてはこちらをご覧ください。
　さて、コンテナで稼働するアプリケーションのセキュリティの実装内容についてですが、アプリケーションということでやはり、脆弱性対策がセキュリティの要になります。セキュアコーディングがしっかりとされているか、外部からアプリケーションの脆弱性を突く攻撃をいかにブロックできるか、アプリケーションに脆弱性が含まれていることをいかに早く検知して対応できるかなどが重要です。例えば、外部からSQLインジェクションが成立してしまわないか、ディレクトリトラバーサルが実行できるようになっていないかなどを確認する必要があります。また、もし万が一、不正なコンテナが攻撃者によって環境に仕組まれてしまった場合、コンテナ間通信やコンテナから外部への通信を監視することで、これをいち早く見つけられるような仕組みをとることも重要と言えるでしょう。
　コンテナ環境における「アプリケーション」「ネットワーク」のセキュリティ実装方法は、RASPなどのコンテナにフィットしたものを検討する必要こそありますが、このレイヤーにおける脅威は、従来のアプリケーションのセキュリティと大きな違いはありません。アプリケーションが直面する脅威（主には脆弱性）に対抗するということをベースに、コンテナ環境でこれをどう実装するかを練る必要があります。その際には、お使いのコンテナ環境で、ホストベースのセキュリティを実装できるか否か、ネットワーク系路上でセキュリティを実装できるか否か、などをお調べいただき、最適なセキュリティ方法をご検討ください。