自動化を駆使してコンテナアプリのDevOpsサイクルを回すとき、忘れてはならないのがビルド段階からデプロイ後までのライフサイクルを通したセキュリティ対策だ。OpenShiftを採用する場合に一緒に検討すべきポイントを整理する。
リリーススピードが重視される現代のアプリケーションやサービス開発では、DevOpsのサイクルを効率良くスピード感を持って運用する体制整備が肝要だ。DevOpsは、開発チームと運用チームが設計からデプロイ、運用までのソフトウェア開発ライフサイクル全体を通じて連携し、テストやビルド、デプロイを自動化することで柔軟かつ速度を持った開発を実現するという考え方だ。
コンテナは必要なソフトウェアを軽量なイメージにまとめてプログラマブルに扱えるため、DevOpsサイクルを高速に回すのに最適な技術だ。だが、ここで忘れてはならないのがセキュリティだ。自動化が進む中、コンテナがマルウェアに感染したり、脆弱（ぜいじゃく）性を抱えた状態でデプロイされたりしてしまうリスクをどう排除すべきだろうか。本稿ではクラウドネイティブアプリケーションならではの、DevOpsを阻害しないセキュリティ対策を見ていく。
本稿では都内で開催された「Red Hat Forum Tokyo 2019」（2019年11月）において、SB C&S ICT事業本部販売推進本部の竹石 渡氏による講演を基に、コンテナアプリケーションのセキュリティ対策のあるべき姿を整理する。
まずコンテナライフサイクルの3つのフェーズを整理しておこう。具体的にはコンテナイメージの開発や各種継続的インテグレーション（CI）ツールを使った自動化を含むビルド（Build：構築）、ビルドしたイメージをコンテナレジストリに格納するシップ（Ship：出荷）、ホストやCaaS（Container as a Service）にデプロイして運用するラン（Run：運用）だ。
コンテナアプリケーションのセキュリティは、この3つのフェーズでコンテナイメージの一貫性を保つこと＝不変性（イミュータビリティー）を維持することがカギとなる。というのも、コンテナアプリケーションの修正や新機能の追加は、実行中のアプリケーションへのパッチ適用ではなく、オリジナルのコンテナイメージに適用してから再ビルドし、再デプロイする手法を取るためだ。
では、コンテナのセキュリティ対策は何をすればよいのか。DevOpsのメリットを最大限に生かす目的で、セキュリティ対策は「シフトレフト」という概念が浸透しつつある。シフトレフトは、開発工程の「より左側」、つまり運用時よりも出荷時、出荷時よりもビルド時に、セキュリティ検証などを取り入れる考え方を指す。手戻りを防ぎ、リードタイムを短縮する効果もある。
まず、ビルドの段階は、コンテナイメージのセキュリティスキャンを実施する。マルウェアや脆弱（ぜいじゃく）性の有無を検証するのはもちろんだが、OSSを含むソフトウェアライセンスのリスクや、パスコードなどのいわゆるシークレット情報がイメージに含まれるリスクもチェックする。CIツールと連携して「マルウェア感染していたらビルドしない」といった自動化の対策も必要だ。
シップの段階では、レジストリ内のイメージのスキャンを引き続き行う。ビルド時に発見されていなかった脆弱性がレジストリ保存期間に見つかった場合のリスクをここで排除する。
ランの段階では、改ざん検知やランタイムプロテクション、コンテナファイアウォール、ホストスキャン、ユーザーのアクセス制御などを実施する。改ざん検知は、オリジナルのイメージと運用中のコンテナとの差分を検証する。不変性が維持されていなければ不正コードが挿入された可能性が疑われる。変更の形跡を見つけ次第アラートを通知するように設定しておけば、問題が発生した場合にも迅速に対応できるだろう。また、ランタイムプロテクションではコンテナの振る舞いを学習し、ランタイム時に使用するリソースやプロセスをホワイトリストに登録。そこにない機能が実行された場合にアラート通知し、機能をブロックする。
実際にコンテナがどのようなサイバー攻撃を受ける可能性があるのか、竹石氏は攻撃デモンストレーションでその内容を披露した。「Apache Struts 2」コンテナを攻撃対象として、既知の脆弱性である「CVE-2016-4438」（リモートから任意のコードを不正実行できるApache Struts 2の脆弱性）を利用してペネトレーションテストツール「Metasploit」で不正なペイロードを挿入し、コンテナを乗っ取るという内容だ。乗っ取りは簡単に成功。メインポータルに記載されたタイトルを編集し、改ざんできることを示した。
また竹石氏は参考として、NIST（米国立標準技術研究所）が公開しているアプリケーションコンテナセキュリティガイド「NIST SP 800-190」を紹介。各フェーズでセキュリティを検証することでリスク軽減が可能であることを強調した。
「特にホストOS層に関してはコンテナに特化した、コンテナが動くための必要最低限のコンポーネントしか含まれていない薄いOSを採用することでアタックサーフェスを最小化できる。コンテナ特化OS『CoreOS』を採用する『Red Hat OpenShift』は、レガシーなアプリケーション基盤よりもはるかにセキュアに設計されている」（竹石氏）
こうしたコンテナセキュリティを支援するのが、Aqua Security Softwareの「Aqua Cloud Native Security Platform」だ。
Aquaは、セキュリティチェックの自動化とイメージの監視および検知を実施するソリューション。オンプレミスだけでなく「Amazon Web Services」（AWS）や「Microsoft Azure」「Google Cloud」「IBM Cloud」など主要クラウドでも利用でき、CaaS／サーバレス環境にも導入可能だ。
Red Hatとの連携という観点ではOpenShift Containerレジストリ内でのイメージスキャンのサポート、s2i（Source-to-Image）時のイメージスキャン、またRed Hat OpenShift環境へのAquaのデプロイ方法に関するマニュアルも用意されている。まさにRed Hat OpenShiftのセキュリティ機能を補完する形で導入できるだろう。
Aquaを構成するコンポーネントは全てコンテナで提供されている。管理サーバにはログなどを保管する「Aqua Database」、UIの提供やポリシー設定を担う「Aqua Command Center」、サーバとコンテナの橋渡し的な役目を果たす「Aqua Gateway」の3つをデプロイする。クラウドおよびオンプレミスの環境には「Aqua Enforcer」をホストにデプロイ、ホストのない環境（CaaS／サーバレス環境）に関しては「Aqua Micro Enforcer」をコンテナに実装しそのコンテナを制御する。マルウェアや脆弱性の情報はAquaのインテリジェンスである「Aqua Cyber Intelligence」から配信される。
「特徴的なのはAqua Gatewayの存在だ。これがあることで数万ノードレベルでのスケールに対応できる。ノードが多岐にわたる場合もAqua Gatewayの数を増やすことで単一のコンソールでノードを管理することができる」（竹石氏）
デモで、竹石氏は問題のあるコンテナをメイン画面から簡単に深掘りできることを示した。脆弱性は色分けされて見やすく表示される他、イメージに内在する脆弱性を円グラフで表示し、どのような問題があるのかが一目で分かる。
依存関係の観点などですぐにセキュリティパッチを適用できない場合でも、コンテナイメージを変更することなく、一時的に脆弱性をふさぐ仮想パッチ機能の「vShield」で対処できる。また「CVSSが7以上である」「OSSライセンス違反がある」などの場合はイメージを認可しないといった設定ももちろん可能だ｡この他、PCI DSSなどのセキュリティ標準に準拠するためのポリシーなどもデフォルトで用意されている。
最後に竹石氏は、Aquaが攻撃を検知するかどうかをデモンストレーションした。さまざまな検知技術があるが、今回はコンテナの改ざん検知機能である「Drift Prevention」で実現する。この機能を有効にした上で、前述のデモと同様にMetasploitを使ってペイロードの挿入を試みる。すると攻撃者のコンソールに「Exploit completed, but session has not completed」（エクスプロイト完了。ただし、セッションは確立されず）と出力される。攻撃されたホストをAquaポータルで見ると、ステータスに「Block」の文字が表示される。つまり、何かファイルが実行されようとしたが、オリジナルのイメージにはないものを挿入しようとしたからブロックしたということだ。
「SB C&Sは、Aquaソリューション以外にもDevOps関連のツールを多数取り扱っている。DevOpsを実現したい、Red Hat OpenShiftでコンテナ運用しているなどであれば、ぜひ相談してほしい。セキュアなコンテナ環境を目指して一緒に取り組むことができれば幸いだ」（竹石氏）
Copyright © ITmedia, Inc. All Rights Reserved.
提供：SB C&S株式会社、レッドハット株式会社
アイティメディア営業企画／制作：TechTargetジャパン編集部
ITmediaはアイティメディア株式会社の登録商標です。
SB C&S 竹石 渡氏
