Text＝鮎川 徹志、山本 和美（日本アイ・ビー・エム システムズ・エンジニアリング）
近年、アプリケーションもマイクロサービス・アーキテクチャとして、コンテナで構築されることが増えている。その際、コンテナ、特にKubernetesやRed Hat OpenShiftなどのオーケストレーションツールを使用して、アプリケーションの開発からデプロイ、運用までを行うDevOpsの概念を取り入れることが一般的になりつつある。
このような構成の場合、セキュリティを考慮したDevSecOpsを考える必要があるとされる。しかし、どのようにセキュリティを担保させればよいかが難しい。実際にデリバリーするメンバー間でも、特に以下2点が悩みどころとされた。
①コンテナ・セキュリティの取っ掛かりに関する悩み
②利用に関する悩み
これらの悩みの解決法を考え、調査／実証を行った。本稿ではその内容を解説する。
セキュリティ・ガイド
まず、①のコンテナ・セキュリティの取っ掛かりに関する悩みを解決するために、コンテナのセキュリティ・ガイドラインを調査した。
コンテナ関連のセキュリティ・ガイドとしては、主に以下がある。
NIST SP 800-190 アプリケーションコンテナセキュリティガイド
NIST SP 800-204 マイクロサービスをベースとしたアプリケーションのセキュリティ戦略
NIST SP 800-53 連邦政府情報システムおよび連邦組織のためのセキュリティ管理策とプライバシー管理策
CIS Benchmarks for Docker/Kubernetes
HIPAA （Health Insurance Portability and Accountability Act）
PCI DSS １（Payment Card Industry Data Security Standards）
これらのなかで、特に「NIST SP800-190 アプリケーションコンテナセキュリティガイド」は、コンテナに特化されていること、およびIPAが翻訳した日本語版も提供されていることから、このガイドを参考にすることとした
このNIST SP800-190は7章から構成されている。なかでも、4章に主なリスクへの対策が記載されており、コンテナイメージ、オーケストレータ等への対策すべき内容が記載されている。
この内容をまとめたのが、図表1である（ただし、一部割愛している）。
図表1の内容をコンテナの作成、デプロイおよびコンテナをデプロイする流れ、およびその環境のどこであてはまるのかを表したのが、図表2である。
アプリケーションのコンテナイメージを作成するには、まずコンテナのベースイメージを取得する必要がある。このときに、そのイメージに脆弱性がないかをスキャンし、リスク対策を実施する必要がある。これが「4.1 イメージの脆弱性とその対策」、すなわちイメージのリスクに相当する。
アプリケーションを含んだイメージを作成した後、デプロイするためにイメージをレジストリに格納する。このレジストリも、アクセスやレジストリ自体のリスクを考慮する（「4.2 レジストリの脆弱性とその対策」、すなわちレジストリのリスクに相当する）。
そして、このコンテナイメージをデプロイ用のマニュフェストを利用して、コンテナ・オーケストレーション環境へデプロイする。このときにも、オーケストレーション環境に脆弱性がないか、権限の大きいユーザーを利用してないか（「4.3 オーケストレータの脆弱性とその対策」、すなわちオーケストレータのリスク）、あるいはイメージからデプロイされたコンテナが改ざんされていないか等のリスク対策（「4.4 コンテナの脆弱性とその対策」、すなわちコンテナのリスク）などを考慮することがガイドに示されている。
今回は、特にアプリケーションを含んだコンテナイメージの開発からデプロイまでのCI/CDで実行される部分を対象とし、ガイドに従って、どのようなツールを利用できるかを調査した。
CI/CDパイプラインの作成
前述では「①コンテナ・セキュリティの取っ掛かりに関する悩み」への対応として、「NIST SP800-190 アプリケーションコンテナセキュリティガイド」をもとに、アプリケーションコンテナを開発するフェーズで、どのようなセキュリティ対応が必要なのかを包括的に整理した。
以下では、「②利用に関する悩み」への対応として、JavaのサンプルアプリケーションをOpenShiftでデプロイする場合を例に、CI/CDパイプラインの作成と、前項で検討したコンテナのセキュリティ対策を組み込んだDevSecOpsパイプラインの検討と実装の流れを解説する。
手動で実施する場合
CI/CDのパイプラインがない場合は、コンテナを使う上で必要な作業を開発者や運用者が手動で実施する。
まず、開発者がアプリケーションのソースコードレポジトリにあるソースコードを修正し、手動でソースコードをビルドして、jarファイルを作成する。
次に、このjarファイルを取り込んだコンテナイメージをビルドして、コンテナ・イメージ・レジストリにpushする。
運用担当者は、コンテナ・イメージ・レジストリにpushされたコンテナイメージのイメージ名とダイジェスト値でDeploymentなどのマニフェストファイルを更新し、このマニフェストファイルからアプリケーションPodをデプロイする（図表3）。
CI/CDパイプラインを使用する場合
CI/CDパイプラインは、これまで手作業で行っていた開発作業やアプリケーションのデプロイ・プロセスを自動化する機能を提供する。
コンテナを導入する目的の1つとして、アプリケーションの開発サイクルを短縮して、素早くアプリを開発し、商用化することで、新しいビジネス価値を創出し、新たなビジネスニーズに迅速に対応することがある。
これらのコンテナの価値を享受するには、CI/CDパイプランを利用するのが必要不可欠となる。
CI/CDパイプラインを作って整備しておけば、開発者がソースを修正する際にソースコードレポジトリに対してソースコードを修正すると、これがトリガーとなり、今まで手動で実施していた作業が自動で実施され、デプロイするときもCDツールとGitをうまく使うことで、自動でアプリケーションPodをデプロイできる。
OpenShiftでは、CIはOSSのTektonベースのOpenShift Pipelines Operator、CDはOSSのArgo CDをベースとしたOpenShift GitOps Operatorが提供されており、これらのCI/CDツールをサポート付きで利用できる。
そのため、OpenShift環境で新規にCI/CDパイプラインを作成する場合は、まずはこれらのOperatorの利用を検討する（以下の参考例では、CI部分をOpenShift PipelinesのTektonのパイプラインを作成して実施し、CD部分もArgo CDを使わずにTektonのパイプラインに組み込んで実施している）。
DevSecOpsパイプラインの作成
次に作成したCI/CDパイプラインにコンテナのセキュリティ対策を組み込むことを検討する。
CI/CDパイプラインの中にセキュリティ対策ツールを組み込み、開発早期において脆弱性などを特定・修正していくプラクティスをDevSecOpsと呼ぶ。DevSecOpsを実践することで、商用環境でバグや脆弱性が見つかるリスクを低減し、対応に必要なインパクトを最小化できる。
CI/CDパイプラインにどのようなセキュリティ対策ツールを組み込むかは、前述した「①コンテナ・セキュリティの取っ掛かりに関する悩み」への対応として、「NIST SP800-190 アプリケーションコンテナセキュリティガイド」をもとに包括的に整理したアプリケーションコンテナを開発するフェーズで、必要なセキュリティ対応に沿って図表1ベースで検討する。
最初に、「何を対策するか」を検討するために、図表1からアプリケーション開発の段階でパイプラインに組み込めるセキュリティ対策の項目を検討する。
例えば、「4.1.1 イメージ作成時の脆弱性」は、CIのパイプラインに組み込める。ただし、「4.3 オーケストレータの脆弱性とその対策」は、OpenShiftの基盤のセキュリティ対策のため、CI/CDパイプラインでの対策の範囲外とする。
次に、前述のセキュリティ対策の項目に対して、「どうやって対策するか」を検討するために、どのセキュリティ対策ツールを利用するかを検討する。
どのツールを利用するかは、プロジェクトによって最適なものを選択する。検討の方針としては、実環境での利用を想定してサポートのあるツールから検討したり、ユーザーの社内セキュリティ標準で指定されたツールがある場合は、それを利用する。
OSSを利用する場合は、プロジェクトで実績と知見があるものなど、さまざまな観点からツールを検討する。
ここでは例として、IBM CloudのマネージドのOpenShiftサービスであるRedHat OpenShift Kubernetes Service （以下、ROKS）を利用して、DevSecOpsパイプラインを作成する場合の検討の流れを記載する。
図表6の青字部分が、CI/CDパイプラインに組み込むことを検討したセキュリティ対策とそのツールとなる。
「脆弱性」列と「対策」列が、CI/CDのパイプラインに組み込んだ項目となり、「実装ツール(候補)」列は、それらの対策についてどのようなセキュリティ対策ツールがあるのかを調査または検証した。
今回、実際にCI/CDパイプラインに組み込んだツールは青字の部分になる。
ツール選定の方針としては、今回はROKS環境のため、まずはIBM Cloudセキュリティ対策のサービスがある場合はそれを利用する方針とした。それ以外は、プロジェクトで知見のあるメンバーにヒアリングし、今まで使用したことがあるものや、実際に実機検証したものを選定した。
前述したように、どのツールを選択するかはユーザーの要件や環境ごとに異なると思われるが、「NIST SP800-190 アプリケーションコンテナセキュリティガイド」をベースに検討することで、どのツールになっても、もれなく包括的にセキュリティ対策を組み込める。
また、今回組み込んだのは青字部分の項目だけだが、要件に応じて「コンテナイメージへの署名」もパイプラインに組み込む、などの検討の叩き台とすることもできる。
当初のパイプラインのタスクの間に、図表6で検討したセキュリティ対策ツールのタスクを組み込んだDevSecOpsのパイプラインは、図表7となる。
初期のパイプラインに、検討したセキュリティ対策のタスク（青い四角）を追加しており、そのタスクの上に記載した項目（青字）が、そのタスクで対策するNISTの脆弱性の項目となる（例：コンテナ・イメージ・スキャンのタスクは、NISTの「4.1.1. イメージ作成時の脆弱性」に対するセキュリティ対策）。
実際にOpenShift PipelinesのTektonで作成したDevSecOpsパイプラインの実行画面は、図表9となる。
以上、本稿では「①コンテナ・セキュリティの取っ掛かりに関する悩み」に対する対応として、コンテナ・セキュリティに関するガイドラインを調査し、特に「NIST SP800-190 アプリケーションコンテナセキュリティガイド」をもとに、アプリケーションコンテナを開発するフェーズでどのようなセキュリティ対応が必要なのかを包括的に整理した。
次に、「②利用に関する悩み」に対しては、アプリケーション開発の段階でCI/CDパイプラインに組み込むセキュリティ対策の項目とツールの検討、およびDevSecOpsパイプラインを作成する流れについて整理した。
次のステップとして、DevSecOpsパイプラインに組み込んだセキュリティ対策の項目に対して、具体的にどのようなセキュリティ・ポリシーを適用し運用していくかを検討する必要がある。
そのためにも、今回のDevSecOpsパイプラインを作成する流れを開発者、運用者の双方が共通認識として持っておくことが一助となるだろう。
著者
鮎川 徹志氏
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
コンテナ・プラットフフォーム
シニアITスペシャリスト
2003年に日本アイ・ビー・エム システムズ・エンジニアリング株式会社に入社。入社以来、IAサーバーの監視製品の技術支援や、オンプレミスの基盤構築案件に従事。近年はオンプレミスのOpenShiftなどのコンテナ基盤の構築案件を担当している。
著者
山本 和美氏
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
ISE.Cloud Platform 2
シニアITスペシャリスト
入社以降、さまざまな業種のオープン系システムの構築に関わる。近年は主に、Public CloudやManagedのOpenShiftをメインとした技術支援を担当している。
［i Magazine・IS magazine］
