コンテナ環境でDevSecOpsに立ちはだかる３つの壁

はじめに

サービスを集約することでシステムの効率化を図るコンテナ環境において、開発や運用の自動化にあわせて自動化されたセキュリティを組み込むDevSecOps。その実現に向けては、いくつかの課題が顕在化しています。本記事では、実際の開発現場においては課題となりやすい3つの壁と、解決に向けたつ具体的なアプローチについて考えていきます。

3行でわかる本記事のポイント

• コンテナセキュリティの課題を解決するにはコンテナ環境を保護するフレームワークに準拠した製品を選ぶことが大切
• 大量の脆弱性の課題を解決するには本当にその脆弱性に対処すべきかを判断することが大切
• ソフトウェアサプライチェーンセキュリティに対処していくためには、開発環境やステージング環境での動作を可視化したうえでレビューを実施していくことが重要

目次

• コンテナ／コンテナオーケストレーターのメリット
• コンテナ環境でDevSecOpsに立ちはだかる「３つの壁」と「乗り越え方」
• ①コンテナセキュリティの壁
• ②大量の脆弱性の壁
• ③ソフトウェアサプライチェーンセキュリティの壁
• まとめ

※本記事の内容は、デモを含めた動画でご覧いただけます

コンテナ／コンテナオーケストレーターのメリット

仮想化技術においてゲストOSを起動させずにアプリケーションの実行高環境が構築できるコンテナ化は、依存関係を1つにパッケージング化するため、軽量かつポータブル性に優れており、オンプレミスであってもクラウドであっても同様に動作させることができることはご存じの方も多いことでしょう。また Kubernetesのようなコンテナを動かすためのオーケストレーターを使うことで、デプロイメントの高度化による運用の自動化にも大きく貢献します。障害が発生したときのオートヒーリングによる自動復旧やリソースひっ迫時のスケールアウト・スケールインの自動化も実現してくれることが大きなメリットです。

コンテナの利用によって、DevOpsを実現するモダンな環境での開発から運用のサイクルをよりスムーズに回していくことができます。実際にDevOpsを実現しようとしても、手元では動作したものがCIツール上で動かない、CIツール上で動いたものがデプロイしてもユーザー側の端末で動かないといった依存関係の問題は非常によく起こり得ます。そんな課題を解決するための手段としてコンテナ化が活用される場面も増えているのです。その意味で、DevOpsとコンテナは非常に相性がいいと言えます。

一方で、DevOpsのなかにセキュアな環境づくりを組み込もうとすると、単純にセキュリティ要件を加えただけでは逆にボトルネックになってしまうこともあります。そこで、セキュリティも自動化された形で検知から対処までのプロセスを組み込むDevSecOpsの実現が重要です。ただし、DevSecOpsを実現する際には、大きく3つの壁が立ちふさがるケースが多く見られます。

コンテナ環境でDevSecOpsに立ちはだかる「３つの壁」と「乗り越え方」　

具体的には、「コンテナセキュリティ」「大量の脆弱性」「ソフトウェアサプライチェーンセキュリティ」の3つが存在します。それでは１つずつ、具体的な解決策とともに解説していきましょう。

①コンテナセキュリティの壁

従来のセキュリティソリューションでは、コンテナやコンテナオーケストレーターの構造や特性上、適切なセキュリティを適用することが困難です。また、セキュリティの自動化という観点での適用ができるようにはなっていません。たとえば脆弱性を検知する際には、Dockerfileをベースにビルドしていくことになりますが、実際には12桁のショートIDに紐づいて格納していきます。こういったIDから人の目でイメージとの紐付けを判断することが難しいため、コンテナのランタイムやオーケストレーターとうまく連携し、どのイメージにどの脆弱性があるのかを正しく検知できるような製品が求められます。特にオーケストレーター上にデプロイされたコンテナは、動的なIPアドレスを利用し、リソースひっ迫などにあわせて動的にクラスタ内で生成と削減を繰り返すため、きちんとオーケストレーターと連携しながらコンテナの状態をリアルタイムに判断し、適切なポリシーを適用していけるようなツールが必要です。

コンテナのライフサイクルにおいても同様の考え方が必要で、通常の仮想マシンで問題が検知された場合は、その仮想マシンにログインしてパッチを適用するといった処理が可能です。ただし、コンテナは環境内で動的に作成・削除が繰り返されるため、一つ一つにログインしてパッチを当てるような修正は行わず、イメージから修正し、古いものと入れ替えるというアプローチになります。このようなライフサイクルにおいては、デプロイ前にイメージがセキュアに作成できていることをチェックでき、デプロイ後にはコンテナが意図したとおりに動作しているかをランタイム上から監視するアプローチが必要です。

＜解決策＞

この課題に対処するには、コンテナ環境を保護するNIST-SP.800-190などのフレームワークに準拠した製品を選ぶことです。また、DevOpsを止めずにセキュリティを適用するためには、シフトレフトの考え方でリリース前にできる限り対処し、リリース後も閾値を明確にしたうえでアクションが自動化できるようシフトライトのアプローチを心掛ける必要があります。

②大量の脆弱性の壁

近年脆弱性の数が増えており、特にクリティカルなセベリティの増加で対処が難しくなっています。特にシフトレフトで事前に脆弱性へ対応するには非現実的な数となってきているのが現実で、最近では年間2万件近い数の脆弱性が発見されています。HeatbleadやShellshockといった深刻な脆弱性が検知されたことで重要性が注目されてきているだけでなく、ファジングツールなどが普及したことなども脆弱性の増加に大きく影響していると見ています。

実際に開発段階で百個単位の脆弱性が出てきた場合、その脆弱性には誰が対応するのでしょうか。そもそも数が多いため、開発者が1つずつ対応していくのは難しく、もしベンダー側が出しているパッチが適用できても、開発したアプリケーションの動作に対する責任も伴います。トリアージする場合でも、CVSSのスコアベースで優先度を振り分け、クリティカルだけを対処することが最適な対応とは言えません。

　そもそも、脆弱性について正しく認識しておくことが必要です。公表されている脆弱性のなかで、統計的には攻撃に利用されているものは全体の約5％程度。これ以外の大多数の脆弱性は実際に攻撃には利用されていない・利用できないのが現実です。また、NVDで公開されていたり脆弱性スキャナーが出してきたりするCVSSのスコアについては、実はCVSSの部分的な指標だけを出したうえでクリティカルなどのセベリティを設定しています。つまり、そのスコアだけでは十分ではないのです。CVSSの基本評価基準は、脆弱性の特性だけに特化したセベリティが出ていますが、これだけでは本当のリスクとして判断するのは難しいのが実態です。

＜解決策＞

正しく判断するためには、世の中に攻撃コードがどんな状態ででていて、それらがどのレベルの完成度なのかといった現状評価基準はもちろん、実際に脆弱性を持つアプリケーションのなかに機密情報が含まれているのかといった環境評価基準も含め、さまざまな要素を加味することで本当にその脆弱性に対処すべきかを判断することです。可能であれば、そのアプリケーションが外部から接続できるかどうかやホストに対する権限やアプリ実行のユーザー権限の状態なども含めて判断していくと良いでしょう。実際に多くの脆弱性情報は「基本評価基準」に基づくスコアだけを出力しているため、本当に対処すべき脆弱性かどうか判断する際には、現状評価基準や環境評価基準など全ての評価基準を含めて評価することが必要となります。

大量に検出されるセキュリティ脆弱性を即座にトリアージしてくれるサービスを活用することもおススメです。

③ソフトウェアサプライチェーンセキュリティの壁

ソフトウェアサプライチェーンセキュリティについては、ここ数年の間に注目され始めたセキュリティリスクです。多くの機微な情報がコードリポジトリのなかに保管されるようになるなか、外部からソースコードやコンポーネントを自動的に取得するような環境が広がってきています。しかし、この自動化プロセス自体を保護するようなソリューションがほとんど世の中に存在していないのが現状です。開発工程においても、使う側は自動化を最重要目的としているため、セキュアに構成されていない環境が散見されています。そこで、このビルドプロセスが攻撃のターゲットになりつつあるのです。

　実際にビルドプロセスを狙った攻撃として、米国のアセット管理のツールにマルウェアが混入した状態で自動的に更新が配布されてしまった事例が挙げられます。もともと開発者のIDが情報漏えいし、外部から侵入してCIツールのビルドサーバーに細工することにより、同社のリリースする製品にマルウェアが混入してしまいました。製品のアップデートとともにマルウェアを多くの企業に配賦してしまった結果、実際に200社を超える規模で侵害報告があったほど。他にも、colors.jsと呼ばれる有名なライブラリの開発者自身が悪意のあるコードを挿入した例もあります。

＜解決策＞

ソフトウェアサプライチェーンセキュリティに対処していくためには、開発環境やステージング環境での動作を可視化したうえでレビューを実施していくことが重要です。プロセスや通信、ファイルシステムへのアクセスなど、意図したもの以外の挙動をしっかりと見極め、レビューしていくなかで解消していくことです。そして、プロセス監視を自動化するためにホワイトリスト化し、意図しない動作が発生した際の検知ととともに、通信のブロックやコンテナの自動復旧を前提とした削除といった対応が可能な仕組みを作り上げることが、今こそ求められています。

まとめ

これまで紹介してきた3つの壁に対する、具体的なアプローチを以下にまとめます。

これら3つの壁に対する商用ソリューションでの実装例としては、NIST-SP.800-190に準拠したPrisma Cloudが挙げられます。コンテナセキュリティへの対応はもちろん、コンテナライフサイクル全般において自動的なセキュリティを実装してくれる支援を行ってくれるソリューションです。また、脆弱性を正しく判断するためのソリューションとして、LeanSeeksがあります。基本評価と現状評価、環境評価というCVSSにおける3つの指標とともに、インターネットアクセスやルート権限の状態などもあわせて計算し、正しくトリアージできる仕組みが具現化できます。

これらのソリューションを組み合わせることで、DevSecOpsの流れを極力止めないような環境づくりが実現できるはずです。ぜひご検討いただければと思います。

＼本記事の内容を、動画でご視聴いただけます／

登録後すぐにご視聴可能

＼ソリューションに関するお問い合わせはこちら／

＼関連記事はこちら／