コンテナセキュリティを担当するべきは誰なのか……
コンテナ環境のセキュリティ対策が曖昧になりがちな要因の一つとして、組織体制的な背景も挙げられる。特にコンテナは開発者にとってメリットが大きいため、これまで多くの開発者に好まれてきた。しかしセキュリティ対策というと、一般的にインフラやシステム管理者が担当するものというイメージがある中で、近年ではDevOpsでその役割が曖昧になってきている。では、コンテナ活用するときにセキュリティを担当するべきなのは誰なのか。
竹石氏は「大前提だと、システムに携わる全員が他人ごとではなく自分ごととしてセキュリティの意識を持つ必要があります。インフラ担当、開発担当、テスト担当、誰もが自分が担当するプロセスにおいて何ができるか、何をしなくてはいけないかを念頭に置く必要があるでしょう」と話す。
それを踏まえた上で、「とは言いつつも、それは理想論で」と続ける。確かに開発やテストなど、他に専念すべきことがある人にセキュリティを任せるのは現実的ではない。どうするのかというと「自動化することでなるべく負担をかけずにセキュリティを組み込んでいけるので、極力システマチックにしていく必要があります」と強調する。
では、実際にコンテナのセキュリティ対策を始めるなら何を指針にすれば良いのだろうか。標準的なガイドラインやチェックリストとして参考になるものはないかと訊くと、『NIST SP800-190』がおすすめだという。これはアメリカ国立標準技術研究所が発行している「アプリケーションコンテナセキュリティガイド」になる。
同文書には、コンテナに関するセキュリティリスクと対策についてまとめられている。ボリュームがあるため軽く読めるものではないが、コンテナセキュリティの標準としてNIST SP800-190があることは最低限覚えておきたい。
イメージやレジストリ、オーケストレータなど様々な観点でリスクと対策が書かれており、たとえばコンテナイメージなら、先述したように脆弱性やマルウェアのリスクを有しているため、その対策としてスキャンを施すこと、信頼あるイメージのみを許可することが重要だとされている。
[画像クリックで拡大]
インフラが高度化、複雑化するというトレンドを考えると、コンテナだけではなくマルチクラウドのセキュリティも考慮する必要がある。クラウドベンダーはそれぞれが強みとなるサービスを提供しており、用途に応じて使い分けたり、冗長性の確保のため複数のクラウドを採用したりするケースもでてきている。そのため、セキュリティを施すにあたっての標準化や学習コストが新たな課題となっている。
たとえば、AWSのセキュリティに関するサービスだけを見ても多種多様にある。セキュリティチェックやアラートの一元化にはAWS Security Hub、脆弱性管理のAmazon Inspectorなど挙げたらきりがないほどだ。Microsoft AzureやGCPにおいても、セキュリティ関連のサービスが多く用意されている。一つのクラウドベンダーにおけるセキュリティサービスの全体像をつかみ取捨選択することも大変だが、それが複数になると混沌としてしまう。
竹石氏は「それぞれ個別にセキュリティに関するサービスを調査し、運用するとなると、学習コストがものすごくかかります。複雑化し、使い分けもあれば、必然的にミスも増えていきます。そのためマルチクラウドにするなら、セキュリティ対策や監視は単一のプラットフォームで横断的に使えるようなツールを使う必要があります」と指摘する。
また、近年ではガートナーが新しい製品カテゴリーとして「CNAPP（Cloud-Native Application Protection Platform）」を挙げている。各種パブリッククラウド、コンテナ、IaC（Infrastructure as Code）などクラウドネイティブなコンポーネントの監査、保護を一元的に行う。
CNAPPにおける要素の一つにCSPM（Cloud Security Posture Management）というものがある。これはマルチクラウドにわたり、セキュリティに関する設定や権限が健全かをチェックする。特に設定ミスは情報漏えいなど致命的な問題を起こしかねず、かつ人間の目が行き届かないこともあるため、ツールをうまく活用することが重要だ。今では、各セキュリティメーカーがこぞってCNAPP領域に進出してきている。
これから企業におけるコンテナ活用がさらに広がっていくことにあわせて、CNAPP分野の動向もチェックしていく必要がありそうだ。
