企業でのコンテナの急速な採用は、セキュリティをシフトレフト(前倒し)するための、またとない機会と言えます。セキュリティのリーダーとして、皆さんはこのチャンスをうまく使っているでしょうか。以前の投稿では、コンテナとパブリッククラウドの間の本質的な関連について説明しました。この記事では、コンテナが開発チームとセキュリティチームの間の隔たりを埋める最も重要な機会の1つである理由を説明します。さて、コンテナを利用して皆さんの組織は一歩DevSecOpsに近づけるのでしょうか。この疑問を探求する前に、私たちがどのようにして現時点のコンピューティング環境に至ったかを理解すべく、簡単にこれまでの現代のコンピューティング進化の歴史をおさらいしてみましょう。

図1：現代コンピューティングの進化

「歴史は繰り返さない。しかし韻を踏む」 - マーク・トウェイン

簡単な歴史のおさらい

私はコンピューティングを進化の繰り返しと考えるのが好きです。最初の進化の波は、単一OSと通常1つのアプリケーションを備えたベアメタルで実行されているクライアントサーバーでした。2番目の波は、VMwareが2001年にサーバー市場に参入したときに発生しました。これにより私たちは仮想化コンピューティングの時代を迎えました。3番目の波が、私たちをコンテナと共に現在に連れて来てくれます。コンテナの採用を推進するのは、DevOpsのスピードと、アプリケーションを移植可能にしたいという願望です。および安全でないコそして現在の最先端で、まださほど多くの企業で広く採用されるにいたっていないフェーズにあるのが、第4の進化、つまりサーバーレスまたはサービスとしての機能（FaaS）です。これは、利用する側がハードウェアやOSにとらわれない、計算の完全な抽象化を表しています。FaaSにおける最も有名な実装はGoogleの Cloud FunctionsとAWSのLambdaでしょう。では、こうした背後にある歴史を踏まえたうえで、コンテナセキュリティのピラミッド図（図2参照）と、それがセキュリティチームをどのようにしてDevSecOpsに移行させることができるのかを掘り下げてみましょう。

図2：コンテナセキュリティのピラミッド図

セキュリティを構築する

「セキュリティをコンテナ構築フェーズに組み込む」とは、皆さんがシフトレフトを実践し、後追い的な対応はしない、ということを意味しています。これを物理的な建築にたとえて考えて見ましょう。家を建てる前に最初にすべきことは、目的の最終状態がどのように見えるかを把握することですね。コンテナのセキュリティでもこの点で違いはありません。構築フェーズのセキュリティは、脆弱性、マルウェア、安全でないコードを削除することに重点を置く必要があります。コンテナはライブラリ、バイナリ、アプリケーションコードで構成されているため、組織内に公式のコンテナレジストリを確立することが重要です。もちろん、皆さんの組織にもそうしたレジストリがひとつふたつすでに存在していることでしょう。そこで、セキュリティチームがなすべき仕事は、こうしたレジストリを見つけてアクセス権を取得したりセキュリティ標準を設定したりといった作業を自主的にすばやく引き受けるように動くことです。標準コンテナレジストリを識別して作成することの主な目的は、信頼できるイメージを作成することにあります。信頼されていないレジストリからコンテナがデプロイされないようにプロセスを合意し、自動的に強制する必要があります。200万以上のDockerizedアプリケーションでは、 Docker Hubがおそらく最も有名なコンテナレジストリでしょう。このことはすなわち、皆さんの組織の開発者と会話を始めるのにこうしたコンテナレジストリが最適な場所でもあることも意味しています。

セキュリティをデプロイする

デプロイ(家であれば、実際の建て付け)フェーズでのフォーカスは、住宅に使用される建材に問題がないことを確認することから、チームがそうした建材を正しく組み上げることを確認することに移ります。脆弱性を含まないイメージを作成できても、安全に構成されていない Kubernetes ポッド上にデプロイされれば、コンテナのリスク管理は十分でないことになるからです。その好例といえそうなのが、弊社脅威インテリジェンスリサーチチーム Unit 42の調査結果にあらわれています。この調査によれば、実に組織の46％があらゆる接続元からKubernetesポッドへのトラフィックを受け入れているのです。オンプレミスの世界にたとえるなら、これはサーバーをデプロイしてインターネットに対し「any」から「any」への接続を開いたままにすることと同じです。さすがにオンプレミスでこれは行わないはずですね。であれば過半数の組織がパブリッククラウドでそれを行うのも問題だといえます。安全な構成でのデプロイは、オーケストレーションと選択したコンテナエンジンの両方にセキュリティ標準を採用することで達成できます。そのさいは、自動化と監視を可能にするために必要なプロセスとツール（すなわち、ガードレール）を配備することを忘れないでください。Docker、Kubernetesの両方について、インターネットセキュリティセンター（CIS）がすばらしいセキュリティベンチマークを作成していますのでこれらを手始めに利用するとよいでしょう。セキュリティを正しくデプロイできれば、ランタイムには「よい」ものだけが入り込むことができるはずです。

ランタイムセキュリティ

家は建てられ、目的とする機能を果たしていますが、システムというものはいずれエントロピー増大に向かうものです（熱力学第二法則によれば）。ランタイムセキュリティとは、実行中のコンテナにある新しい脆弱性を識別し、通常稼働状態がどのようなものであるかを把握することです。またこれにはゼロデイ攻撃を示す可能性がある疑わしい/異常な活動の調査も含まれます。皆さんのセキュリティチームが最初（つまり構築フェーズ）から関わっていたのであれば、ランタイムセキュリティを正しいものにすることはそうでない場合にくらべてはるかに容易です。ですがなんらかの理由から最初から関わることができず、ランタイムのフェーズに入ってから後追い的に対応しているのであれば、その時点から前にさかのぼって対応することになってしまうでしょう。このとき、現在の最終状態が安全であることを確認することはもちろん重要なのですが、ランタイムだけにフォーカスしてしまうと、セキュリティチームが最初のフェーズから関与しないという同じ問題が繰り返し発生してしまいかねません。IBMシステム科学研究所の研究結果によれば、メンテナンスフェーズ（すなわち私たちの例ではランタイムフェーズ）にバグを修正するのにかかるコストは、設計フェーズ(私たちの例では構築フェーズ)に見つかった場合の100倍高いと報告しているのですから、ぜひ最初のフェーズから関わりをもつことを覚えておくべきでしょう。

「セキュリティはプロセスであって製品ではない」 - ブルースシュナイアー

いまを絶好の機会ととらえよう

企業でのコンテナの急速な採用は、セキュリティをシフトレフトしてくれる、これまでない絶好の機会と言えます。セキュリティが最初から開発サイクルに組み込まれていれば、セキュリティチーム、開発チームの両チームとも、プロジェクトに対し、自身の所有意識の高まりを感じることでしょう。セキュリティをランタイムにかわされるやりとりだけに紐づけせず、両チームのコラボレーションが最初からずっと継続し、組織がセキュリティの取り組みを構築・デプロイ・ランタイムというコンテナセキュリティのピラミッドに集中させることでこうした効果を得ることができます。包括的なクラウドセキュリティ戦略の一環としてこの「最初から最後までの関与」を実践するセキュリティチームであれば、コンテナはDevSecOpsに一歩近づくための福音となりえることでしょう。