攻撃事例で考える「コンテナセキュリティ」のリスクと対策：特集：クラウドネイティブのセキュリティ対策とDevSecOpsの勘所（2）

コンテナ基盤にセキュリティリスクがあることは認識している。セキュリティのガイドラインなどもチェックしている。だが、いまひとつ攻撃やリスクのイメージが湧かない。そんな開発者に向けて、NTTデータのクラウドエンジニア、望月敬太氏が具体的な攻撃デモを通して、意識すべきリスクや対策について分かりやすく解説する。2021年11月4〜5日にオンラインで開催された「CloudNative Days Tokyo 2021」から「乗っ取れコンテナ！！〜開発者から見たコンテナセキュリティの考え方〜」で紹介された内容だ。

[谷崎朋子，＠IT]

ガイドラインだけでは実感しにくいコンテナセキュリティのリスク

　マイクロサービスやエッジコンピューティングを実現する技術の一つとして活用が進むコンテナ。その一方で、コンテナやアプリケーション、オーケストレーターの設定不備や運用ミス、脆弱（ぜいじゃく）性などによるセキュリティリスクが数多く指摘されてきた。

　こうした事態を受けて、NIST（米国国立標準技術研究所）はセキュリティプラクティスとして「NIST SP800-190 アプリケーションコンテナセキュリティガイド」を公開。情報処理推進機構（IPA）が日本語訳版を出すなど、安全な活用が呼び掛けられている。

　ただ、ガイドラインは汎用（はんよう）性を重視するため、「雰囲気は分かるものの、リスクを具体的にイメージしにくい」と、NTTデータのクラウドエンジニア、望月敬太氏は難点を示す。何事においても、どう危険なのかを明確に思い浮かべられないと、対策がおざなりになりがちだ。また、実際に問題が発生したとき、どの対策を優先すべきなのか分からずに、うまく行動できない可能性もある。

　そこで望月氏はコンテナを設定、デプロイする開発者に焦点を絞り、コンテナやコンテナホストへの乗っ取り攻撃のデモを実演した。その上で、どのような対策が必要なのかを具体的に解説した。

デプロイする開発者の責任範囲（望月氏の講演資料から引用）

　なお、今回は実際にコンテナに対する攻撃デモを実演しているものの、決してサイバー攻撃を肯定するものではない旨を望月氏は強調している。

攻撃者の乗っ取る様子を見ながらリスクを実感

　攻撃デモは次のようなシナリオに沿っている。Kubernetesをコンテナ基盤に利用し、さまざまなサービスをコンテナやPod（コンテナイメージのDockerファイル）としてデプロイする、とあるチームの開発者が主人公だ。あるとき、コンテナ技術について学べるWebサービスをKubernetes上にPodとしてデプロイし、ネット越しにユーザーが利用できるようにした。しかし、デプロイしたコンテナイメージと「Kubernetes Manifest」（コンテナ起動設定）にセキュリティリスクが含まれていたため、攻撃者に乗っ取られてユーザーを悪意あるWebサイトへと誘導されてしまったという内容だ。

コンテナへの攻撃デモの概要（望月氏の講演資料から引用）

　攻撃デモでは、コンテナとコンテナホスト（ワーカーノード）をそれぞれ乗っ取る手順を紹介した。

　まず、コンテナを乗っ取る手順だ。攻撃者は初めに攻撃端末1で待ち受けポート（5050）を設定し、攻撃端末2からある脆弱性を悪用するためのHTTPリクエストを発行した。不正なコマンドが実行されて、コンテナ内に侵入する。その後、シェルでコマンドを実行できることを確認してから、Webページのリンク先を攻撃者の用意したWebページに書き換える。これでユーザーは、正規のリンクをクリックしたつもりで、悪意あるWebサイトに飛ばされてしまう。

コンテナの乗っ取りデモ（望月氏の講演資料から引用）

　2つ目の攻撃シナリオは、コンテナホストの乗っ取りだ。ここで攻撃者が使うのは、「Container Breakout」という手法だ。本来、コンテナホストは隔離されているので、コンテナからは干渉できないはずだが、その思い込みの裏を突いた攻撃だ。

　Container Breakoutを起こす準備は、2つある。1つは、乗っ取ったコンテナでsudoコマンドを使い、ルート権限に昇格した後、ホストで実行したいプログラム（デモではcmdファイル）をコンテナ内に作成する。実はこの作成したcmdファイル、コンテナ内にのみ保存されていると思いきや、コンテナホスト上の特定のディレクトリ内にも現れる。このようになる理由は、コンテナのrootfsがコンテナホスト上の「OverlayFS」をマウントしたものだからだ。OverlayFSは複数のディレクトリを1つのファイルシステムに見せる技術で、マウント先のディレクトリで新規ファイルなどが作成されると、その内容がOverlayFSを構成するディレクトリ中の「Upperdir」と呼ばれるディレクトリにも反映される。つまり、cmdファイルの実態はコンテナホストに存在する。

　もう1つの準備は、コンテナ内のcgroupと呼ばれる特殊なファイルシステム下に「x」という名前のディレクトリを作成することだ。実はこのcgroup、コンテナとコンテナホストで共通のものを使っている。つまり、コンテナ内にのみディレクトリを作成したつもりが、コンテナからコンテナホストのcgroupへ直接アクセスできる状態になっている。コンテナとコンテナホストでファイルシステムを隔離するのが一般的だが、cgroupについてはcgroup namespaceが共通なため、共有状態になるのだと望月氏は説明する。

コンテナホストの乗っ取るには（1）（望月氏の講演資料から引用）

　こうした事前の準備とその他の標準的な機能を組み合わせることで、コンテナからホスト上のcmdファイルをパス指定で実行可能になる。後は、ホストにバックドアを仕掛けてリモートからいつでも任意のプログラムを実行できるように持っていくだけだ。

　バックドアに必要なホストのIPアドレスは、デバイスの設定を一覧表示するコマンド（ip a）をcmdファイルに書き込んで実行し、テキスト出力させるだけだ。続いて、攻撃端末2の8023ポートを待ち受けに設定し、cmdファイルに8023ポートと接続確立するコマンドと、コンテナホストの9023ポートを待ち受けに設定するコマンドを書き込んで保存する。その後、攻撃端末3からコンテナホストのIPアドレスに対して9023ポートにコネクションを張る。以上で、攻撃端末3で発行したコマンドをコンテナホストで実行できる環境が整った。乗っ取り成功だ。

コンテナホストを乗っ取るには（2）（望月氏の講演資料から引用）

コンテナイメージのセキュリティ対策は「余分なものを含めない」こと

　こうした攻撃が成功するのは、何もコンテナやKubernetesにバグがあるからではない。開発者がコンテナイメージやコンテナレイヤーに対して、意識せず作り込んでしまったセキュリティリスクを攻撃者が悪用しただけだと、望月氏は言う。

　では、どう対策すればよいのか。望月氏はコンテナイメージ（Dockerファイルなど）とコンテナ（Kubernetes Manifestなど）のそれぞれについて、リスクと対策の考え方を解説した。

　コンテナイメージのセキュリティ対策について、基本原則は「イメージに余分なものを含めない」ことだと望月氏は断言する。

　「例えば、ライブラリやパッケージ、バイナリ、設定値として必要最小限のものしかパッケージされていないイメージAと、必要以上の要素を含むイメージBがあるとする。ライブラリやパッケージの中には、脆弱性が存在するものもある。そう考えたとき、必要以上にこれらの要素を含むイメージBには、それだけセキュリティリスクが多く存在することになる」（望月氏）

　コンテナイメージを作るとき、一般にベースイメージを「Docker Hub」などで探して活用するだろう。このとき、ベースイメージに本来含めるべきではない余分なものが多く含まれていることに気付けるかどうかだ。例えば攻撃デモのイメージには、CGI（Common Gateway Interface：Webサーバに配置されたプログラムを呼び出すインタフェース）から任意のコマンドをリモート実行できてしまうbashの脆弱性「CVE-2014-6271」、通称「ShellShock」が含まれていた。攻撃ではこれを悪用して、リモートからコマンドを実行、コンテナ内への侵入を成功させている。

　また、sudoが含まれるのもリスクだ。「そもそもコンテナでsudoコマンドは不要。これがあると、攻撃者は侵入後、簡単に特権ユーザーへ昇格できてしまう」（望月氏）

コンテナイメージには余分なものを入れないことが基本原則（望月氏の講演資料から引用）

　望月氏はこの問題の対策として次の3つを挙げた。

（1）信頼できるイメージを利用する、または一からイメージを作成する
（2）イメージをできる限り小さくする
（3）イメージを継続的にスキャンする

　1つ目は公式が提供するイメージなど、信頼できるイメージを利用するか、一からイメージを作成することだ。

　2つ目はイメージに余分なものを含めず、できる限りサイズを小さくすることだ。「公式のイメージでも、タグバージョンによってはイメージサイズが大きいものもある。小さいサイズの方がセキュリティリスクは少ないと想定できるので、なるべくサイズの小さいものを選ぶようにしたい」（望月氏）

　3つ目はイメージに対してセキュリティスキャンを実行することだ。どんなに気を付けているつもりでも、意図せず脆弱性や危険な設定を含んだイメージを作成してしまうことがある。そこで出番となるのが、Aqua Securityの「Trivy」やGOODWITHの「Dockle」といったスキャンツールだ。攻撃デモで使った脆弱なコンテナイメージをTrivyでスキャンすると、ShellShock脆弱性を検出できた。また、Dockleでコンテナイメージの設定がベストプラクティスにのっとっているかどうかを検証すると、sudoコマンドが含まれており、セキュリティリスクになり得ることを検出できた。

　「脆弱性はしばらくたった後に発見されるものも多い。スキャンしたタイミング以降に発見されるケースもあるので、継続的にスキャンを実行することが重要だ」（望月氏）

コンテナは「隔離性を維持する」ことが基本原則

　コンテナのセキュリティ対策の基本原則は、「コンテナの隔離性を維持する」ことに尽きると、望月氏は強調する。

　「コンテナはあくまでもOS上で実行されるプロセスの1つにすぎない。カーネルの持つさまざまな仕組みを用いて、ホスト上で実行されるプロセスの実行空間の隔離やrootfsの隔離、権限の制限などを行い、1つの隔離環境を作っているのがコンテナだ。これを踏まえて、コンテナは基本的に、隔離性を維持することが原則だ。これが実現できていれば、たとえ外部から侵入されたとしてもホストに影響は及ばない」（望月氏）

　Kubernetes Manifestでは、コンテナの起動設定をさまざまに定義できる。それだけに、意識していないと意図せず隔離性に穴を開けるような設定をしてしまうことがある。

コンテナの基本原則は隔離性を徹底的に維持すること（望月氏の講演資料から引用）

　攻撃デモのシナリオでは、Kubernetes Manifestでコンテナに特権を付与する設定になっていた。その結果、プロセスやコンテナ自体にコンテナホストの特権ユーザーと同等の権限を与えてしまい、cgroupに書き込みできるといったように、さまざまな操作を許してしまった。また、コンテナ内でファイルの新規作成や編集ができたが、これはホストのOverlayFSからマウントされているコンテナのrootfsに対する書き込みが許可されていたからだ。隔離性からいえば低い状態だ。

　隔離性を保つ対策は2つある。

（1）不要な設定をしない
（2）マニフェストをスキャンする

　1つ目は不要な設定をしないことだ。実はKubernetesの場合、デフォルトでコンテナプロセスについて、最低限の隔離性を保証した設定になっている。「極論すれば、デフォルトのままデプロイすればKubernetesとして定義される最低限のセキュリティレベルは確保できる」（望月氏）

　さらに隔離性を高めるには、次のような設定が推奨されるという。「攻撃デモでは、特に次の（c）と（d）が有効に働く」（望月氏）

（a）システムコールフィルター（seccomp）により、システムコールを制限する
（b）ServiceAccountをマウントしない
（c）特権昇格を禁止する
（d）rootfsへの書き込みを禁止する
（e）Capabilityの剥奪や必要最小限の付与
（f）リソース使用量を制限

　ここで望月氏は注意したいポイントが1つあると述べる。それは、コンテナイメージやKubernetes Manifestで特に何も指定せずにデプロイすると、rootユーザーでコンテナが起動する点だ。なぜなら、現在の仕様ではコンテナとコンテナホスト上の実行ユーザーはコンテナプロセスの実行ユーザーとイコールだからだ。コンテナの隔離性の観点から、コンテナ実行ユーザーを非rootユーザーとして起動するよう設定することが推奨される。

　コンテナではCapabilityなどのカーネルの仕組みによって、root実行しても権限が制限されるようになっているはずだ。これでは不十分なのだろうか。「脆弱性があれば別の話になる。カーネルの仕組みをすり抜けて不正な操作が可能になってしまうこともある。そうしたリスクを避けるためにも、基本的にコンテナは非rootで実行するように設定すべきだ」と望月氏は述べる。

　「nginxやhttpdなどWebサーバの公式イメージは、コンテナポートに特権ポート（80ポート）を使用するものがあり、そのためroot実行を前提としているものが多い。当然、これも非rootで実行可能なように設定を変更できる。これらサービスを使うときは留意したい」（望月氏）

　隔離性を保つ2つ目の対策は、Kubernetes Manifestに対してスキャンをかけることだ。設定項目をスコアリングしてリスク評価する「Kubesec」や、Kubernetes Manifestに含まれるリスクを検知して自動修正してくれる「Kubeaudit」などが役立つ。また、KubernetesのPod Security Standardに準拠したPodのみデプロイを許可する「Pod Security Admission」や、稼働中のPodが米国の国家安全保障局（NSA）と国土安全保障省サイバーセキュリティインフラセキュリティ庁（CISA）による「Kubernetes Hardening Guidance」に準拠しているかどうかを検査する「kubescape」もある。コンテナのセキュリティレベルを強化するツールが複数公開されているので、積極的に活用していきたい。

　望月氏は本講演の資料を「Speaker Deck」で公開する他、攻撃デモのPoC（概念実証）をGitHubで公開している。特に講演資料には、コンテナセキュリティを対策する上で参考となる資料の参照先がリストアップされているので、ぜひ目を通しておきたい。

　「攻撃事例を通じてコンテナにどのようなリスクがあるのか、どのような対策が必要なのかを知っていただけると思う。本講演の情報がコンテナセキュリティを意識するきっかけとなり、どこから対策に着手すべきか目安を付けることができるのであれば幸いだ」（望月氏）

特集：クラウドネイティブのセキュリティ対策とDevSecOpsの勘所

素早く価値を生み出すためにビジネスとITサービス開発、運用を直結させる取り組みが不可欠となっている。そうした中、注目されているアプローチがスピーディーにアプリケーション＝ビジネスをデプロイし、その後も高度な変化適応力を持ちながら、安定的に運用する「クラウドネイティブ」だ。近年、ビジネスの要となるが故に攻撃者はクラウドを標的とする傾向を強く示している。特に、GitHub.comやDocker Hubといった、公開されているアプリケーション資産やサービス活用におけるプロセス、設定の脆弱性を突く攻撃と漏えい事件が世間を賑（にぎ）わせているのは、周知の通りだ。ITサービスを、いかに脆弱性を減らしてリリースし、安全に運用していくのか。本特集では、そのカギとなる「DevSecOps」の取り組みを中心に、クラウドネイティブにおけるセキュリティ対策の勘所を探る。

特集：クラウドネイティブのセキュリティ対策とDevSecOpsの勘所