コンテナと Kubernetes のコンプライアンスに関する考慮事項

コンテナを実行しているのなら、潜在的なセキュリティリスクについて考えたことがあるはずです。ワークフローに DevOps 手法を導入しているだけの組織もあれば、CI/CD パイプラインは確立したが機密データの保護が必要だと考えている組織もあるでしょう。

ロールベースのアクセス制御 (RBAC) により、Kubernetes API エンドポイントの認可を標準的な方法で管理できます。Kubernetes クラスタの RBAC 構成は、どの名前空間内のどのリソースタイプで、どのサブジェクトがどのアクションを実行できるかを制御しますが、RBAC はロールの構成方法を規定するものではありません。そこで登場するのがコンプライアンス・フレームワークです。

多くの業界にとって、コンプライアンス要件を満たすことがビジネスを行う上で不可欠です。コンプライアンスの問題は、コンテナ化されたクラウドネイティブ・アプリケーションを構築および実行する上で最初の難題になるかもしれませんが、クラウドネイティブ環境での包括的なコンプライアンスを可能にするフレームワークとテクノロジーは急速に進化しています。コンテナ化されたアプリケーションに関連する主なコンプライアンス・フレームワークは次のとおりです。

• CIS ベンチマーク (Kubernetes および Docker 向け)
• NIST SP 800-190
• PCI
• HIPAA

コンプライアンスが最終的に目指すのは、アプリケーションの安全性を保証することです。しかし、組織はアプリケーションが継続的に安全であることを第三者に対して証明できる必要もあるため、コンプライアンス要件を満たすのは、単にアプリケーションを保護するよりも難しい場合があります。また、継続的なコンプライアンスを証明する記録を追跡し、保持することも必要です。

コンプライアンスは困難な課題にもなり得ますが、コンプライアンス基準を満たさない場合にははるかに多額のコストがかかる可能性があります。コンプライアンス違反に関連する罰金の平均コストは、コンプライアンス要件を満たすために要する平均コストのほぼ 3 倍です。

コンプライアンス基準は、組織のセキュリティ・ガバナンス・ポリシーの設定における重要な要素でもあります。特定のフレームワークのガイドラインを満たす必要がない場合でも、組織独自の内部ポリシーの設定を始めるにあたって、ガイドラインをゼロから作成する代わりにコンプライアンス・フレームワークを使用できます。

フレームワーク

CIS ベンチマーク：Center for Internet Security が開発した CIS ベンチマークは、コンテナ、特に Docker ランタイムや Kubernetes を使用するコンテナのベストプラクティスを提供しますが、どの業界に対しても強制力はありません。

NIST 800-190：コンテナセキュリティに関する米国国立標準技術研究所のフレームワークで、同研究所が公開する多くのサイバーセキュリティ・コンプライアンス・フレームワークの 1 つです。すべての米国連邦政府機関および政府請負業者は、NIST 800-190 の要件を満たす必要があります。

PCI：主要なクレジットカード会社 5 社によるパートナーシップを通じて開発された PCI (ペイメントカード業界) フレームワークは、支払い情報の保存、処理、または伝送を行う組織を対象としています。

HIPAA：HIPAA 法の技術的な保護措置は、個人を特定できる電子的保護対象医療情報を収集、処理、または伝送する組織に対処します。

米国国立標準技術研究所の特別刊行物 800-190 (NIST 800-190) は、コンテナ化されたアプリケーションのセキュリティ保護に関連する特定の課題と、アプリケーションのセキュリティプロファイルを向上するために組織がやるべきことを理解するためのフレームワークを提供します。

NIST ガイドラインは、米国政府機関および政府請負業者を対象としていますが、総合的なセキュリティの向上のために、そして、PCI や HIPAA などの他のコンプライアンス・フレームワークへの準拠を容易にするという理由から、あらゆる企業が NIST 800-190 ガイドラインに従うべきでしょう。

リスク

NIST 800-190 は、コンテナ化されたアプリケーションのセキュリティ脆弱性の一般的な原因を挙げています。それには次のようなものがあります。

• 危殆化したイメージ
• コンテナイメージの構成ミス
• 信頼できないコンテナイメージ
• 秘密の管理が不十分
• アクセス制御の構成ミス
• OS の脆弱性
• 過度に大きな攻撃対象領域

同様に重要なこととして、NIST 800-190 は、組織が従来のアプリケーションとは異なる方法でコンテナ化されたアプリケーションのセキュリティに取り組む必要性を強調しています。コンテナ化されたアプリケーションには仮想マシンとは異なるリスク要因があり、一連の異なるセキュリティ対策が必要です。

NIST 800-190 は、組織に次のことを求めています。

• 専用のツールを使用して、ビルド、デプロイ、ランタイムへとイメージのライフサイクル全体を通じてイメージの脆弱性を管理する
• イメージが構成のベストプラクティスに準拠するようにする
• 秘密を保護するために、秘密をイメージの外部に保存し、Kubernetes を使用して管理し、秘密を必要とするコンテナのみにアクセスを制限し、保存中および転送中は暗号化する
• レジストリからプッシュまたはプルする場合は、安全な接続を使用する
• コンテナが常に最新のイメージバージョンを使用するようにする
• ネットワークトラフィックをセグメント化し、少なくとも、機密性の高いネットワークと機密性の低いネットワークを分離する
• Kubernetes を使用してノードを安全に導入し、ノードとその接続状態のインベントリーを維持する
• コンテナからの発信トラフィックを制御する
• CIS ベンチマークなど、コンテナランタイムの構成基準に継続的に準拠するようにする
• セキュリティ制御を使用して、コンテナレベルおよびインフラストラクチャ・レベルで脅威と潜在的な侵入を検出する
• 攻撃対象領域が可能な限り小さい、コンテナ向けに強化されたオペレーティングシステムを使用する
• コンテナが設計どおりに機能するための権限をできるだけ少なくすることで、ホストファイルシステムの改ざんを防ぐ

NIST 800-190 の要件に準拠する必要がない組織であっても、NIST 800-190 は組織のセキュリティ体制を向上するために役立つフレームワークだと捉えるべきでしょう。これにより、組織はビルド、デプロイ、ランタイムの各フェーズを通じてセキュリティについて検討し、各段階に固有のセキュリティ要件に対応できます。

ペイメントカード業界データセキュリティ基準 (PCI DSS) は、セキュリティとデータ保護の業界標準を設定するために、Visa、MasterCard、American Express、Discover、および JCB が 2004 年に策定しました。この基準は、テクノロジーの変化への対応を目的として最初にリリースされて以来、何度も更新されてきました。これはカード会員データ環境内のあらゆるもの、つまり、カード会員データの保存、処理、または伝送を行う人、プロセス、テクノロジーに対して適用されます。テクノロジーに関しては、ハードウェアとソフトウェアの両方を対象としています。

PCI の要件への準拠は容易ではなく、そのために企業が支出する年間コストの平均額は 550 万ドルです。しかし、コンプライアンス違反のコストははるかに高額で、ペナルティによる年間コストの平均額は 1,480 万ドルです。適切なプロセスとツールが整っていれば、PCI コンプライアンスは大きな課題にはなりません。

PCI DSS には 6 つの目標が定められており、対応する 12 の要件があります。それは次のようなものです。

安全なネットワークシステムの構築と保守

1. カード会員データを保護するために、ファイアウォール構成のインストールと保守を行う
2. システムパスワードおよびその他のセキュリティパラメーターに、ベンダー提供のデフォルト値を使用しない

カード会員データの保護

1. 保存されるカード会員データを保護する
2. オープンなパブリックネットワーク経由でのカード会員データの伝送を暗号化する

脆弱性管理プログラムの整備

1. マルウェアやエクスプロイトからすべてのシステムを保護し、ウイルス対策ソフトウェアを定期的に更新する
2. 安全性の高いシステムとアプリケーションを開発し、保守する
3. 強力なアクセス制御手法の導入

カード会員データへのアクセスを業務上必要な範囲内に制限する

1. システムコンポーネントへのアクセスを識別および認証する
2. カード会員データへの物理アクセスを制限する

ネットワークの定期的な監視およびテスト

1. ネットワークリソースおよびカード会員データへのすべてのアクセスを追跡および監視する
2. セキュリティシステムおよびプロセスを定期的にテストする

情報セキュリティポリシーの整備

1. すべての担当者の情報セキュリティに対応するポリシーを整備する

コンテナ化されたアプリケーション向けの PCI コンプライアンス

PCI が略述する上記 6 つの目標それぞれに付随する要件のうちの一部は、コンテナ環境と Kubernetes 環境に直接関連しています。コンテナと Kubernetes のセキュリティツールを評価して、以下の要件に対応できることを確認しましょう。

1.12 ワイヤレスネットワークなど、カード会員データ環境 (CDE) とその他のネットワーク間のすべての接続を示す最新ネットワーク図。

1.1.4 各インターネット接続、および非武装地帯 (DMZ) と内部ネットワークゾーンの間のファイアウォール要件。

1.2 信頼できないネットワークとカード会員データ環境内のすべてのシステムコンポーネントの接続を制限する、ファイアウォールおよびルーター構成を構築する。

1.2.1 着信および発信トラフィックをカード会員データ環境に必要なトラフィックに制限し、それ以外のすべてのトラフィックを明示的にに拒否する。

1.3.2 着信インターネット・トラフィックを DMZ 内の IP アドレスに制限する。

1.3.4 カード会員データ環境からインターネットへの未承認の発信トラフィックを禁止する。

1.3.5 ネットワーク内への「確立された」接続のみを許可する。

2.1 システムをネットワークに導入する前に、必ずベンダー提供のデフォルト値を変更し、不要なデフォルトアカウントを無効にする。

2.2 すべてのシステムコンポーネントについて構成基準を作成する。この基準は、すべての既知のセキュリティ脆弱性に対処し、業界で認知されたシステム強化基準と一致している必要がある。

2.2.1 同じサーバーに異なったセキュリティレベルを必要とする機能が共存しないように、1 つのサーバーには主要機能を 1 つだけ実装する。(たとえば、Web サーバー、データベースサーバー、DNS は別々のサーバーに実装する必要がある。)

2.2.2 システムの機能に必要なサービス、プロトコル、デーモンなどのみを有効にする。

2.2.3 安全でないと見なされているが必要なサービス、プロトコル、またはデーモンに追加のセキュリティ機能を実装する。

2.2.5 スクリプト、ドライバー、機能、サブシステム、ファイルシステム、不要な Web サーバーなど、すべての不要な機能を削除する。

2.3 強力な暗号化を使用して、すべてのコンソール以外の管理アクセスを暗号化する。

2.4 PCI DSS の適用範囲であるシステムコンポーネントのインベントリーを維持する。

3.6.2 安全な暗号化鍵の配布。

6.1 セキュリティ脆弱性情報の信頼できる社外提供元を使ってセキュリティの脆弱性を特定し、新たに発見されたセキュリティの脆弱性にリスクのランク (「高」、「中」、「低」など) を割り当てるプロセスを確立する。

6.2 ベンダー提供のセキュリティパッチをインストールして、すべてのシステムコンポーネントとソフトウェアが既知の脆弱性から保護されるようにする。重要なセキュリティパッチは、リリース後 1 カ月以内にインストールする。

6.4.1 開発/テスト環境を本番環境から分離し、アクセスツールを使用して分離を実行する。

6.4.2 開発/テスト環境と本番環境での責務の分離。

6.5.1 インジェクションの不具合 (特に SQL インジェクション)。OS コマンドインジェクション、LDAP および XPath のインジェクションの不具合、その他のインジェクションの不具合も考慮する。

6.5.3 安全でない暗号化保存。

6.5.4 安全でない通信。

6.5.6 脆弱性特定プロセス (PCI DSS 要件 6.1 で定義) で特定された、すべての「高リスク」脆弱性。

10.2.5 すべてのシステムコンポーネントに自動監査証跡を実装して、識別および認証メカニズムの使用と変更 (新しいアカウントの作成、特権の昇格など)、およびルート権限または管理者権限を持つアカウントへのすべての変更、追加、削除を再構築する。

11.2.1 四半期ごとに内部脆弱性スキャンを実施する。脆弱性に対処し、再スキャンを実施して、事業体の脆弱性ランク付け (要件 6.1 に基づく) に従ってすべての「高リスク」脆弱性が解決されたことを確認する。スキャンは有資格者が実施する必要がある。

11.5 変更検出メカニズム (ファイル整合性監視ツールなど) を導入して重要なシステムファイル、構成ファイル、または コンテンツファイルの不正な変更 (変更、追加、および削除を含む) を担当者に警告し、重要なファイルの比較を少なくとも週に一度実行するようにソフトウェアを構成する。

11.5.1 変更検出ソリューションによって生成された警告に対応するプロセスを実装する。

1996 年制定の医療情報の相互運用性と説明責任に関する法律により、あらゆる医療記録に関連する患者のプライバシーを管理するための HIPAA コンプライアンス・フレームワークが作成されました。2003 年に追加された HIPAA のセキュリティルールは、デジタル医療記録の管理に関するものです。個人を特定できる電子的保護対象医療情報 (ePHI) を扱う組織は、HIPAA の要件に準拠する必要があります。これには、医療提供者がケア、コミュニケーション、または請求のために使用するアプリケーションも含まれます。

HIPAA へのコンプライアンスを困難にしている主な要因は、セキュリティ・フレームワークが大まかなガイダンスのみを提供しており、コンテナと Kubernetes に関するガイドラインをどのように満たすべきかについては詳細が規定されていないことです。さらに、保護対象の医療情報と非対象の医療情報の違いは、多くの場合、たとえば、PCI コンプライアンスでの保護する必要があるクレジットカード情報とそうでないものの違いほど明白ではありません。

医療提供者自身に加えて、医療提供者にストレージや請求などのサービスを提供する組織のサービスに電子的個人医療情報 (ePHI) の処理が含まれる場合、そのような組織も HIPAA の要件を満たす必要があります。

HIPAA セキュリティルールの基準は、管理的、物理的、技術的な保護措置に分かれています。IT インフラストラクチャに関連する技術的な保護措置には、次のような基準があります。

• アクセス制御
• 監査制御
• データの完全性
• 認証
• データ伝送のセキュリティ

HIPAA セキュリティルールは、組織による ePHI の保護に関する詳細を規定しておらず、コンテナ化されたアプリケーションに関するものではありません。多くの場合、HIPAA コンプライアンスへの取り組みを開始するために最適なのは、コンテナセキュリティのガイドラインとベストプラクティスを提供する NIST SP 800-190 フレームワークを適用することです。HIPAA とは異なり、NIST SP 800-190 はコンテナに関するフレームワークを提供するため、コンプライアンスの実践が容易になります。しかし、HIPAA の要件を満たすには、ePHI を保護し、種類の異なるデータから分離しておくために、追加のデータ分離制御を実装する必要があります。

また、HIPAA は、アプリケーションの完全な回復と継続的なコンプライアンスの実践を可能にするために、組織がデータだけでなく構成ファイルのバックアップも保持することを求めています。