Dockerは今年で6年目を迎えました。それだけの年月が流れてなお、コンテナのための明確な戦略が欠けているセキュリティチームが数多く見受けられます。そうしたチームはしばしば、クラウドのセキュリティとコンテナのセキュリティに個別に対応しています。ですが、セキュリティチームにとって、パブリッククラウドとコンテナ間の本質的な関連性を理解することは非常に重要です。
図1：フルスタッククラウドの可視性 vs サイロ型コンテナの可視性
コンテナ + クラウド = ピーナッツバターとゼリー
コンピューティングは、過去20年間にわたって数々の進化を遂げてきました。これら進化の歴史については別のブログで書く予定ですが、さしあたっては「開発者はオペレーティングシステムとアプリケーションの依存関係を扱うことにうんざりしている」とだけいっておけば十分でしょう。コンテナはこの問題に対処してくれましたが、それはまったく新しいセキュリティ上の課題も生み出しました。そしてコンテナ市場需要の急拡大につれ、セキュリティ製品（商用からオープンソースまで）も急増しました。こうしたポイント製品は、コンテナセキュリティのかかえる課題の狭い範囲の問題であれば対応できたものの、セキュリティを全体的に捉える視点には欠けていました。コンテナ上で開発されるアプリの大半は、AWS Redshift、GCP Cloud Datastore、Azure SQLなどのPaaSサービスを組み合わせて利用しています（これは上図を参照していただければおわかりになるでしょう）。ですが、クラウドのAPIレイヤ全体を可視化して、どのクラウドネイティブサービスが使用されているかを正確に把握していないかぎり、コンテナの利用により、どのようなリスクが組織におよぶのかを正確に評価することは困難です。
ここで、「自社の一連のコンテナが最新のCVEに対して脆弱ではあるものの、AWSセキュリティグループ設定では、攻撃に必要なポートがオープンになっていない」というシナリオを考えてみましょう。フルスタックでセキュリティ知識を持っていればこの場合のリスクの評価はガラリと変わりますが、そうした視点はコンテナ用セキュリティポイント製品を採用しているだけでは得ることができません。なぜなら、そうしたポイント製品だけでは、いちばん大事なクラウドプロバイダのAPI レイヤを可視化できないことが多いからです。逆に、フルスタックに渡ってセキュリティの状況が把握できていれば、おそらく上記の脆弱性の問題への対応は待たせておいてよいと判断でき、ほかに明らかになった脆弱性があれば、そちらを優先して対応するという判断もできるでしょう。そこで私たちの抱える問題は「 ほかのクラウドアーキテクチャからコンテナのセキュリティを切り離して検討するという現在の戦略に欠けているものは何か」ということになるでしょう。
コンテナのセキュリティにも包括的に対応する
この問題に対処する最初のステップは、明確な目標を設定し、チームが何を達成しようとしているのかを把握することです。ここで立てる目標は「開発者の教育、セキュリティ基準の合意、ベストプラクティスの自動強制、クラウドプロバイダのネイティブAPIとの緊密な統合を組み合わせることにより、コンテナを安全に使用できるようにする」という簡単なものでよいでしょう。ここで重要なのは、チームが別のセキュリティツールを購入することを制限することではありません。ヒト・プロセス・テクノロジを含む全体を俯瞰したアプローチをとるようことをチームに奨励することです。
つまりそれがどういうことかと言えば、DevOpsを採用し、セキュリティにシフトレフト(前倒し)で対応する、ということです。ただし、皆さんのチームがセキュリティプロセスとツールの両方を開発ライフサイクルに統合してはじめてDevSecOpsを実現できます。ここで DevSecOps とは、DevOpsにセキュリティを開発プロセスのできるだけ早い段階で組み込み、セキュリティをシフトレフトすることを指します。そしていまコンテナやクラウドが利用されている速度を考えれば、セキュリティチームは DevSecOps をとるほかに成功するすべがないのです。明確な目標を設定したら、チームはコンテナのライフサイクルにおける3つの重要なフェーズ、つまり構築フェーズ、デプロイフェーズ、ランタイムフェーズに全力を注ぎたくなることでしょう。というのも、これらそれぞれのフェーズが、独自の課題をかかえ、セキュリティチームの注意深い対応を求めるものだからです。
まとめ
2019年に予測されている コンテナの採用が企業の90％に達していることを踏まえれば、チームはこれら3つのフェーズのセキュリティをクラウドセキュリティの全般的な戦略に含めることが重要です。コンテナも統合すべき一要素とみなしたうえでクラウドセキュリティ戦略を開発・実装しているチームメンバーがいないかぎり、セキュリティチームはコンテナの利用によって組織にもたらされるリスクを正しく評価できない可能性があります。たしかにさらに別のポイントセキュリティ製品を買い込んで後づけで対応するという考えは簡単だし魅力的ではありますが、より成熟した組織であれば、クラウドとコンテナを同一のものと見なして対応することでしょう。コンテナセキュリティとクラウドセキュリティに別々に対処してしまえば、統合的戦略で対処していれば対応できるリスクを可視化できないままになってしまうのです。
そのためにどうすればよいのかについては、続編『コンテナ：DevSecOpsへの移行を促進する』をお読みください。