スッキリ、繋げて、コンテナセキュリティを得意分野に！ #1 コンテナセキュリティで重要な観点

コンテナセキュリティで重要な3つの観点

本シリーズを通して、『点』での理解を繋いで全体感を掴んでいくために、まず、コンテナセキュリティの重要なポイントを3つお伝えします。
米国国立標準技術研究所（NIST）が発行している『NIST SP800-190』（アプリケーションコンテナセキュリティガイド）などの情報を参考にしていますが、以下3つは本シリーズ用に私のほうで整理したものです。

＜ コンテナセキュリティの重要な観点 ＞
観点①：既存のアプローチの見直しが必要　（NIST SP800-190にも記載）
観点②：多層防御が従来よりも重要　（NIST SP800-190にも記載）
観点③：ナレッジ不足が大きな落とし穴となりうる　（このシリーズでのテーマともなる部分）

次の章からは、それぞれの観点を詳しく見ていきます。

観点①：既存のアプローチの見直しが必要、を詳しく

ここでは、コンテナセキュリティで重要な観点①アプローチの見直しが必要について、次の要因を例に詳しく見ていきます。
要因１：コンテナの特性
要因２：DXやセキュリティバイデザインの風潮

要因１：コンテナの特性
一つ目の要因、コンテナの特性が及ぼす既存のアプローチへの影響です。
技術自体が従来のものと異なるため、既存の対策方法やプロセスも見直しする必要がある、というものです。
まず、おさらいとして、コンテナの定義とその特性を改めて確認します。
コンテナは、ホスト上の隔離された空間でアプリケーションを実行させる仮想化技術です。
下図のように、よく仮想マシン（VM）とコンテナの仮想化技術は比較されます。

VMでは、仮想的にハードウェアを含めてマシンを再現しようとしてきました。
一方でコンテナは、完全なマシンの再現をせず、アプリに必要なものだけを内包して隔離環境を作り出します。
コンテナの特長として次のようなものが挙げられます。
・（依存ライブラリも同梱のため）別の環境でも同様に動作可能
・（必要なものだけ⇒軽量のため）移送がしやすい、起動が早い、自動化に組み込みやすい
・（隔離環境で動作のため）疎結合を保てる
上記のような特長により、コンテナの特性には次のようなものがあります。
・コンテナはライフサイクルが短い
　起動が早くて疎結合⇒壊れたらすぐ新しいものに取り換える使い方が可能なため、
　物理サーバや仮想サーバのようにひとつのモノを丁寧に育てるのでなく、気軽に使い捨てられる存在。（ひどい）
・稼働中のコンテナ自体は不変性を保つことを良しとする
　気軽に置き換えできるように、コンテナ自体は変更せず、コンテナの元となるコンテナイメージを変更することが慣例。

こうしたコンテナの特性は例えばセキュリティパッチの更新方法やプロセスの見直しに繋がります。
従来の『本番環境へのパッチ適用』が『コンテナイメージ更新⇒本番環境にデプロイ』※に置き換わります。
※コンテナイメージをパッチ適用済のものに更新、稼働中のコンテナ自体に変更を加えないという方法・プロセス

要因２：DXやセキュリティバイデザインの風潮
二つ目の要因、DXやセキュリティバイデザインの風潮によるアプローチ見直しを見ていきます。
DX（デジタルトランスフォーメーション）では迅速かつ柔軟な価値提供が求められます。
一方で、セキュリティバイデザインは、設計時点からセキュリティを組み込むというものです。
あらかじめセキュリティを組み込むことは、セキュリティを後乗せに比べて、手戻りのリスクが少なくなります。
迅速かつ柔軟な価値提供が求められるDXにとって、セキュリティバイデザインは必要な選択と言えます。

（実際、コンテナの場合、事前にコンテナイメージを作り込み、デプロイ後はコンテナとして不変性を保ちつつ稼働させるため、セキュリティバイデザインの考え方と非常にマッチしています。）
DXやセキュリティバイデザインの風潮によって、セキュリティを作り込む工程が変化します。
すなわち、セキュリティを実装するメンバや部門も、方法やプロセスと共に変わってくることになります。
つまり、DXやセキュリティバイデザインの風潮によって組織におけるセキュリティの責任所在の見直しが必要と言えます。

上記の通り、二つの要因を例に、コンテナセキュリティの重要な観点①既存のアプローチの見直しが必要を見ていただきました。

観点②：多層防御が従来よりも重要、を詳しく

次に、コンテナセキュリティで重要な観点②多層防御が従来よりも重要を詳しく見ていきます。
ここでは、主に次の二つの要因を例に説明していきます。
要因１：コンテナ技術に起因すること
要因２：コンテナを取り巻く要素が多岐に渡り、その全てが自身の管理下にないケースがあること

要因１：コンテナ技術に起因すること
コンテナで実現している仮想化メカニズムでは、従来の仮想マシンの仮想化よりも分離レベルが低いことが挙げられます。
観点①の中でも記述したように、コンテナは、仮想化に際してハードウェアを含めた完全なマシンの再現をしていません。
コンテナは、アプリ実行に必要なものをまとめて梱包し、他と干渉しない隔離環境で動作できるようにしていますが、実際には下図のようにOSカーネルはホストのものを利用しており、他コンテナとも共有して使用しています。

コンテナ仮想化技術の欠陥によって隔離環境を超えて、ホストやホスト上の他コンテナへ影響するリスクも考えられます。
そのため、コンテナは次のように利用することが望ましいとされています。
「コンテナは、同じ目的や機微性、脅威に対する態勢を持つもの同士をグルーピングして利用する」
これにより、コンテナの侵害の影響度を最小限に抑えるといった多層防御の観点に繋がります。

要因２：コンテナを取り巻く要素が多岐に渡り、その全てが自身の管理下にないケースがあること
コンテナを取り巻く要素（コンポーネント）は、多岐に渡っています。
要素には、CI/CDを含むビルド環境や、コンテナイメージの格納先となるレジストリ、コンテナ実行環境となるサーバ、複数のコンテナを管理するオーケストレータ（下図ではKuburnetesを例として記述）などがあります。

また、上記のいずれかで何らかのクラウドサービスを利用するケースがあると予想されます。
構成する要素が多く、それら全てが自身の部門や組織の管理下にないケースでは、可能な限り自身の管理下でセキュリティを作り込むのが良いでしょう。
自身の見えない部分で対策を取っているであろうから大丈夫なはず、という思い込みが危険です。
対策に抜け漏れがあった場合や、対策を突破された場合に、他でカバーできるように多層防御が大切となります。

上記の二つの例は多層防御すべき要因として記載しましたが。
一方で、コンテナでは多層防御ができるとも言え、本シリーズを通して、コンテナでは随所で多層防御の観点が登場します。

どこかで突破されたり、対策できなかったりしても、他でカバーして被害を最小限に留める多層防御が、コンテナでは求められており、実施可能となります。
以上、コンテナセキュリティで重要な観点②多層防御が従来よりも重要を見ていただきました。

観点③：ナレッジ不足が大きな落とし穴となりうる、を詳しく

続いて、コンテナセキュリティで重要な観点③ナレッジ不足が大きな落とし穴となりうる点を詳しく見ていきます。
要因１：コンテナセキュリティの全体像を捉えることが難解
要因２：コンテナではユーザによるセキュリティの作り込みが特に重要

要因１：コンテナセキュリティの全体像を捉えることが難解
この点がまさに本ブログシリーズのテーマに通じるものになりますが、コンテナを取り巻く技術要素は多く、コンテナセキュリティの全体像を捉えるのが難しいように思います。
コンテナ周辺技術には、コンテナ仮想化を実現する様々なLinux技術や、コンテナ間通信を可能とするネットワーク技術、コンテナを管理するオーケストレータの便利機能や、実行環境として用いるクラウドサービスの理解など様々です。

実際、ガイドラインやベストプラクティスを参考にすることが、コンテナセキュリティの全体像を捉えるの近道です。
しかし、こうした参考情報を読み解くのも、ひとつのハードルかと思います。
多岐に渡る技術要素の理解が足りずに、参考にする情報の本質を捉えきれないことも考えられます。
ナレッジ不足によって本質を捉えられずに穴があることに気が付けない、考慮漏れに繋がる恐れがあります。

要因２：コンテナではユーザによるセキュリティの作り込みが特に重要
コンテナを取り扱うにあたって一連のユーザ体験は観点①で触れたように従来と異なります。
セキュリティバイデザインの風潮に伴い、セキュリティ製品の在り方やカバー範囲も変わってきています。
コンテナにおいてセキュリティ製品では、次のようなものがあります。
・ユーザによるセキュリティの作り込みのチェック機能
・ユーザで対策できない部分を補完する保護機能
・ユーザによるセキュリティの作り込みを突破されたことを考慮した保護機能（多層防御）
例えば、コンテナイメージの脆弱性をスキャンするセキュリティ製品などは、一つ目のチェックする機能にあたります。
このように根本原因をつぶすにはユーザによるセキュリティの作り込みが重要となるケースがあります。
また、対策の中には、ユーザによる作り込みでしか防げないものもあります。（同一用途のコンテナのグルーピング等）コンテナでは対策製品を頼るだけでは立ち行かず、セキュアにする方法をご自身で理解している必要性が高いです。

以上、コンテナセキュリティで重要な観点③ナレッジ不足が大きな落とし穴となりうる点を見ていただきました。

対策の考え方について

最後に、ここまでを踏まえて、対策の考え方についてまとめてみました。

コンテナセキュリティの全体感を捉えるには、何かしらのフレームワークを参考にすると良いです。
下図では、NIST SP8000-190を参考にしています。
マトリクスなどを用意して、ユーザ、クラウドベンダ、3rdパーティ製品のそれぞれで対応をマッピングします。

本ブログシリーズでは、コンテナセキュリティについて、捉えづらい部分をスッキリ、理解の点と点を繋げて、全体像を捉えられるようにすることをテーマとしています。
皆さんがコンテナ分野を『苦手』から『面白い≒得意』にできるようなコンテンツをお届けしていきます！
※本ブログの内容はエンジニア個人の見解であり、弊社全体としての見解ではない点をご了承ください。