実はリスクが多いコンテナのセキュリティを確保する方法：コンテナはセキュリティホールまみれ？

リポジトリで公開されているコンテナの多くには多数の脆弱性が含まれており、さらに改ざんされるリスクもある。コンテナからコンテナへ、リスクが水平移動する恐れもある。これらにどう対処すればいいのか。

[Aaron Tan，Computer Weekly]

　コンテナにはさまざまなメリットがある。だが、それに伴ってアーキテクチャやプラクティスに変化が起き、新たな課題やチャンスも生まれる。

　これまでのセキュリティモデルは、複数階層のセキュリティ製品を使うことでITシステムの課題に対処してきた。これによってアジャイル開発の天敵となるストレスや低速なプロセスが生み出されていた。だが新しいアプローチは結果を重視し、テクノロジーツールやプラクティスを活用してセキュリティを確保する。

　継続的デリバリー（CD）において、セキュリティの鍵となるのが自動化だ。開発者はコンテナを使うことで、顧客のニーズに集中してコードを素早く作成できる。だが、広く使われているコンテナイメージとパブリックコンテナリポジトリがサプライチェーン攻撃を受けた場合、自動化とコンテナインフラの規模によっては被害が悪化する恐れがある。

Docker Hubのハッキング

　2019年4月、世界最大のコンテナイメージのライブラリとコミュニティーである「Docker Hub」がハッキングを受け、約19万人（Dockerの顧客ベースの5％）のユーザー名、ハッシュ化されたパスワード、GitHubとBitbucketのアクセストークンが漏えいした。

　さらに、Kenna Securityが2019年に実施した調査によって、Docker Hubのコンテナイメージトップ1000の多くに何らかの脆弱（ぜいじゃく）性が含まれていることが分かった。

　最も古いコンテナは150万回利用されており、未解決の脆弱性は431件以上に上るという。約170万回利用されたkeyvanfatehi/sinopiaコンテナには総計2000件以上の脆弱性が見つかっている。

　だが脅威検出と脆弱性へのパッチ適用は、コンテナセキュリティの側面のほんの一部にすぎない。この件に関してはRed Hatが「コンテナ・セキュリティの10大要素」として詳しく解説している。

関連記事

• Dockerを導入する前に企業が絶対に知っておくべきこと
• Dockerのバックアップ戦略――Dockerの何を保護すべきか？

特別編集ブックレット

• コンテナセキュリティにゼロトラストを適用すべき理由

コンテナの全体的なセキュリティ確保

　Red Hatのアジア太平洋部門でアプリケーションプラットフォーム製品の地域製品管理ディレクターを務めるビシャール・ガリワラ氏によると、コンテナのセキュリティを全体的に確保するには、これらの層（ホストOS、ネットワーク、ストレージ、コンテナ化アプリケーションにアクセスを付与するAPI）が必要になるという。

　Red Hatのモデル中で最も重要なのがコンテナホスト（通常はLinuxサーバ）のセキュリティだと指摘するガリワラ氏は次のように話す。「コンテナホストに脆弱性があれば、コンテナ管理プラットフォーム全体が侵害される恐れがある」

　コンテナのセキュリティを確保するには、信頼性の高いソースとレジストリを使わなければならない。この点についてはPivotalのウォルター氏も強調している。「コンテナプラットフォームは、ビルド済みのイメージを運用環境にプッシュする前にレジストリに格納する。レジストリが侵害されると、運用環境に導入されるイメージを攻撃者が変更できる。そのため、レジストリを厳しく管理統制することが不可欠だ」

　Red Hatはコンテナカタログを用意し、さまざまなミドルウェア、データベース、言語ランタイムの認証済みコンテナイメージを一覧にしている。「例えばNode.jsに重大な脆弱性があれば、Red HatのNode.jsの全コンテナが新しいセキュリティ修正プログラムによって全て自動的に再構築される」（ガリワラ氏）

　レジストリに関しては、Red Hatは「OpenShift」のコンテナレジストリへのアクセスを統制する厳しい制御を構築している。開発者がイメージをビルドする際は、脆弱性スキャンなどの一連のポリシーやプロセスを適用しなければ、そのイメージは使用可能とは認定されない。

　CI/CD（継続的インテグレーション／継続的デリバリー）パイプラインにまたがるビルドプロセスの管理も、セキュリティ脆弱性を調査するための鍵になるとガリワラ氏は語る。Synopsysの「Black Duck Hub」やJFrogの「Xray」などのスキャナーを使ってリアルタイムに既知の脆弱性を確認すれば、開発者はセキュリティホールを特定し、必要に応じてインフラ、ミドルウェア、アプリケーションレベルでコンテナイメージを再構築することが可能だ。

　コンテナの展開に際しては、クラスタ内に展開できるものを制御することが必要だ。「例えば、適切に記述されていないコードが原因でルートアクセスを求めるコンテナが導入されることがあるが、こうしたことを防ぐ必要がある」とガリワラ氏は言う。

不適切な分離

　コンテナオーケストレーションプラットフォームを適切に管理すれば、ホストやその他のコンテナのセキュリティリスクが軽減される。だが、名前空間とファイルシステムが不適切に分離されることが依然としてよくあるとPivotalのウォルター氏は指摘する。

　特権コンテナにも懸念がある。特権コンテナでは、コンテナの管理者がホストの実質的な権限を得ることができる。ウォルター氏は次のように語る。「同様に、共有フラットネットワークで全てのコンテナアプリケーションをホストすることにより、侵害されたアプリケーションから別のアプリケーションにリスクが水平移動するリスクが高まる」

　「セキュリティチームは、使用中のネットワーク層にトラフィックを制限して、アプリケーションが相互通信する際は宣言的なビジネスロジックが基盤になるようにする必要がある」

　また、企業がコンテナアプリケーションを展開するにつれ、API呼び出しを管理・認証するためのAPI管理が不可欠になる。トラフィックのスムーズな流れを維持するためであり、Webシングルサインオン（SSO）をサポートするためでもある。

　Red Hatのガリワラ氏によると、フェデレーション導入モデルでは、複数のパブリッククラウドとオンプレミスデータセンターでセキュリティとアクセス制御を同レベルに維持する役割を、承認機能や認証機能と共にAPI管理が担っているという。

　だが、コンテナとモノリシックアプリケーションは、近い将来まで共存し続けると予想される。現在ほとんどの企業がアプリケーションのポートフォリオをリファクタリングし、プラットフォームを切り替え、ホストを変更するためにアプリケーションの最新化戦略を立てている。

　コンテナアプリケーションとレガシーアプリケーションが点在する環境のセキュリティを管理する一般的なアプローチを「Two-Speed IT」（2速IT）という。耐用期間の長いサーバには従来のセキュリティポリシーと制御を使い、変化の少ない一時ワークロードに、より動的な方法、つまり継続的な監査と検査を使用するアプローチを指す。

　このアプローチは、各エコシステムで適切な手法を使うメリットを提供し、コンテナの動的な性質に対応するように構築されていない従来のポリシーのためにイノベーションが遅れるのを防ぐ。

　既存のモノリシックサーバを保護するのにコンテナの不変、動的、かつ一時的な性質が活用されないのはよくあることだが、それではもったいないとウォルター氏は語る。

　「ユーザーが使う重要な機能をマイクロサービスにリファクタリングすれば（しばしば侵害の原因となる）パッチ適用が難しいアプリケーションからユーザーの機器を保護することができる。このアプローチは、モノリシックなバックエンドアプリケーションを変更する必要性を減らすことで継続的な攻撃のリスクを軽減する。そして、不正アクティビティーの検出をしばしば妨害するノイズを減らす」（ウォルター氏）