ACS (Advanced Cluster Security) 旧 StackRox 資料

過去のセミナー資料を公開企画

Transcript

1. 1 Advanced Cluster Security for Kuberentes 製品概要 2021/06/14 Solution Architect Yuhki Hanada
2. StackRox 導入企業様事例 Customers | StackRox より StackRoxの顧客は、SaaS、フィンテック、政府機 関を含め、様々な地域や業界にわたっています。 今日、クラウドネイティブ企業、フォーチュン500 企業、政府機関のDevOpsチームやセキュリティ・ チームは、StackRoxに基づいて、コンテナのライフ サイクル全体にわたってセキュリティやコンプライ アンス・ポリシーを実装しています。 StackRoxのソフトウェアは、Kubernetesネイティ ブなコンテナ・セキュリティ・プラットフォームと してIron Bankアーティファクト・リポジトリに含 まれ、米国国防総省（DoD:Departiment of Defence）のエンタープライズDevSecOpsコンテナ 強化ガイドへの準拠が認定されるとともに、自動テ ストおよびコンテナ・セキュリティを実現するため にDoDによる使用が認可されています
3. US Air Force、アメリカ国防総省 (Department of Defense) 事例 StackRox delivers container and Kubernetes security to US Air Force | HG Insights 「継続的に革新的なソフトウェアを 提供し、アプリケーションとデータ の安全性を確保することは、我々の 準備態勢にとって不可欠です。我々 は、コンテナとKubernetesをベー スにした迅速な革新のための Hardening された環境として、 Platform Oneソフトウェア・ファク トリーを構築しました。 StackRoxがKubernetesネイティブ なアーキテクチャを活用してその環 境を保護してくれることで、ビルド からデプロイ、ランタイムまで、ア プリケーションのライフサイクル全 体でセキュリティを提供することが できます」（米空軍のロブ・スロー ター少佐）
4. 4 Enterprise Kubernetes from Red Hat Kubernetes cluster services Automated Ops ⠇Over-the-air updates ⠇Monitoring ⠇Logging ⠇Registry ⠇Networking ⠇Router ⠇Virtualization ⠇OLM ⠇Helm Linux (container host OS) Kubernetes (orchestration) マルチクラスター管理 Observability | Discovery ⠇Policy ⠇Compliance ⠇Configuration ⠇Workloads 高度なセキュリティ機能 Declarative security ⠇ Vulnerability management ⠇ Network segmentation ⠇ Threat detection & response OpenShift Kubernetes Engine OpenShift Container Platform Red Hat Advanced Cluster Management for Kubernetes (ACM) Red Hat Advanced Cluster Security for Kubernetes (ACS) OpenShift ファミリー OpenShift Plus Global registry Image management | Security scanning | Geo- replication Mirroring | Image builds Cluster services monitoring, registry, logging Application services middleware, functions, ISV Service mesh Developer services dev tools, automated builds, CI/CD, IDE 運用のためのサービス アプリケーションに必要な ミドルウェア アプリケーション開発 Distribute Storage Bock / File / Object アクセ スをサポートする分散スト レージソフトウェア OpenShit Data Foundation
5. コンテナとセキュリティ
6. セキュリティのガイドラインについて NIST SP 800-190 「アプリケーション・コンテナのセキュリティガイド」 NIST (Nastional Institute of Standard and Technology:米国標準技術研究所)は、商務省の配下の組織 NIST SP 800-204 「マイクロサービスをベースとしたアプリケーションのセキュリティ戦略」 NIST SP 800-53 「連邦政府情報システムおよび連邦組織のためのセキュリティ管理策とプライバシー管理策」 米国連邦政府で使用するシステムのセキュリティとプライバシー管理の基準。日本も政府で導入するクラウドシステムの管理基準 の一つとして採用する予定。 CIS Benchmarks[1] for Docker / Kubernetes CIS (Center for Internet Security) が発行。ベンダー製品・サービスを対象に25以上のベンダー向けの100 以上のベストプラク ティスがある。 HIPAA (Health Insurance Portability and Accountability Act) 医療情報のプライバシーとセキュリティに関する法律。それを満たすためのデータのプライバシーとセキュリティ要件。 PCI DSS (Payment Card Industry Data Security Standard) クレジットカードの情報を保護する事を目的に作られた、クレカ向けシステムの基準。 審査機関が存在し、認証が取得できる。定期的な検査も求められる。
7. セキュリティのガイドラインについて NIST SP 800-190 「アプリケーション・コンテナのセキュリティガイド」 NIST (Nastional Institute of Standard and Technology:米国標準技術研究所)は、商務省の配下の組織 NIST SP 800-204 「マイクロサービスをベースとしたアプリケーションのセキュリティ戦略」 NIST SP 800-53 「連邦政府情報システムおよび連邦組織のためのセキュリティ管理策とプライバシー管理策」 米国連邦政府で使用するシステムのセキュリティとプライバシー管理の基準。日本も政府で導入するクラウドシステムの管理基準 の一つとして採用する予定。 CIS Benchmarks[1] for Docker / Kubernetes CIS (Center for Internet Security) が発行。ベンダー製品・サービスを対象に25以上のベンダー向けの100 以上のベストプラク ティスがある。 HIPAA (Health Insurance Portability and Accountability Act) 医療情報のプライバシーとセキュリティに関する法律。それを満たすためのデータのプライバシーとセキュリティ要件。 PCI DSS (Payment Card Industry Data Security Standard) クレジットカードの情報を保護する事を目的に作られた、クレカ向けシステムの基準。 審査機関が存在し、認証が取得できる。定期的な検査も求められる。 コンテナ/コンテナに近い部分 具体的な製品・設定についての指定は無いレベル (抽象的) 具体的な製品毎の設定についてのガイド
8. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-190.pdf 参考:NIST SP 800-190 https://www.ipa.go.jp/files/000085279.pdf IPA による翻訳版もあります SP=Special Publication. コンテナを使用する上でのセキュリティの考慮ポイント (一般的なリスク・ポイントと対策の概念について言及したもので、具体的な手法、ツールなどについてガイド しているわけではない)
9. 参考：NIST SP 800-190 (1) 3.1. イメージのリスク 3.1.1 イメージの脆弱性 使用されたイメージは時間の経過と伴に古くなり脆弱性がでてくる。 3.1.2 イメージ設定の不備 必要以上に大きな権限で実行できるようになっている。SSHデーモンが含まれおり、アタックサーフェス が大きなコンテナが存在する(設定の問題)。 3.1.3 埋め込まれたマルウェア 不適切なサードパーティーや出所が不明なイメージをベースレイヤーとして使用する事で、マルウェアが 埋め込まれている可能性がある。 3.1.4 踏め混まれた平文の秘密情報 SSH秘密鍵、X.509秘密鍵が埋め込まれたコンテナがあるとセキュリティリスクになる。 3.1.5 信頼できないイメージの使用 組織外から配布されている脆弱性やマルウェアが仕込まれたイメージを使用する。「3.1.3 埋め込まれた マルウェア」に近い内容。 3.2. レジストリのリスク 3.2.1 レジストリへのセキュアでない接続 暗号化されてないやりとりをする事により、認証情報を盗み出したり、中間者攻撃により、問題のあるイ メージをオーケストレーターに提供する。 3.2.2 レジストリ内の古いイメージ レジストリに保管されているイメージが古くなり、脆弱性を含んだ状態になる。「3.1.1イメージの脆弱 性」の内容に近い。 3.2.3 認証・認可の不十分な制限 レジストリへの不正アクセスによる知的財産の損失 3.3. オーケストレーターのリスク 3.3.1 制限のない管理者アクセス 悪意のあるもしくは不注意のユーザーが他のネームスペースに影響を与える可能性がある。 3.3.2 不正アクセス 独自でUser Directory を持っているオーケストレーターのアカウント管理 (厳密に管理されにくい) オーケストレーターが保管しているデータボリュームの暗号化の考慮 3.3.3 コンテナ間ネットワークトラフィックの不十分な分離 ・暗号化されたオーバーレイ・ネットワークは安全だが、モニタリングできないためセキュリティ上の 「盲点」となる可能性がある。 ・セキュリティレベル(機微性)が異なるアプリが同一ネットワークにあると、一つのアプリが攻撃された時 に共有されたネットワークを介して別のアプリを攻撃できてしまうことへの考慮。 3.3.4 ワークロードの機微性レベルの混合 ・同じノード上に重要度が異なる、コンテナが配置される事がある。片方のセキュリティが破られた場合 、もう一方が脆弱性にさらされる可能性がある。 3.3.5 オーケストレーターノードの信頼 ・不正なノードがクラスタに参加しコンテナを実行 ・一つのノードの侵害がクラスタ全体のセキュリティリスクになる可能性がある(同じ鍵ペアが使われてい る) ・オーケストレーターと、管理者、開発者、ノード間の通信が暗号化されてない。認証がない。
10. 参考：NIST SP 800-190 (2) 3.4. コンテナのリスク 3.4.1 コンテナ・ランタイムの脆弱性 ・コンテナ・ランタイムソフトウェアの脆弱性を使用した他のコンテナやホストOS自体への攻撃。 3.4.2 コンテナからの無制限ネットワークアクセス ・「3.3.3コンテナ間ネットワークトラフィックの不十分な分離」と似ているが、コンテナ間通信ではなく 、コンテナと外向けネットワークのアクセスについて。 ・外部のネットワークアドレスは、内部では使われておらず、トラフィックの可視性がないため、管理が 難しい。 3.4.3 セキュアでないコンテナランタイムの設定 ・コンテナランタイムを不適切に設定するとホストOSのリスクを増大させる。 ・特権モードで動作するコンテナは、ホストの全てのデバイスにアクセスできる。 3.4.4 アプリの脆弱性 ・アプリの作りによる脆弱性。XSSやSQL injection 等 3.4.5 未承認コンテナ ・開発やデバッグ用などで用いられる、本来環境には存在するべきではない“未承認”コンテナの存在。気 づかれずに環境に存在している場合、セキュリティリスクになる。 3.5. ホストOSのリスク 3.5.1 大きなアタックサーフェス ・ホストOSはアタック・サーフェスが大きい 3.5.2 共有カーネル ・コンテナ専用OSでも、共有カーネルを使用しているため、ハイパーバイザーよりは分離レベルが低く、 アタックサーフェスは大きい。 3.5.3 ホストOSコンポーネントの脆弱性 ・ホストOSの脆弱性。コンテナ専用OSでも最低限の機能しか持っていないとは言え、最低限の機能の中 に脆弱性が存在する可能性はある。 3.5.4 不適切なユーザーアクセス権 ・ユーザーが管理目的でOSに直接できるようになっている場合、全てのユーザーに影響する広範囲の変更 が可能になる。 3.5.5 ホストOSファイルシステムの改竄 ･コンテナがホストOS上のディレクトリーをマウントできるようになっている場合、他のコンテナに影響 を与えるファイル改竄のリスクになる可能性がある。
11. 全体構成・ダッシュボード
12. Host Host ACS のカバレッジ コンテナのベース・ イメージ(外部) ユーザーが作成し た独自のイメージ 新しいコンテナの作成 マニフェスト(YAML) RHEL8のイメージ Ubuntuのイメージ テスト Kubernetes Host RHEL8 ユーザー コンテナ ユーザー コンテナ RHEL8 ユーザー コンテナ プログ ラム 実行 環境 + + = 使用するイメージ レプリカ数 PVのサイズ etc GitHub Quay Red Hat Eco System Catalog オーケストレーター管理者の設定 root 権限での実行 不十分なコンテナ間分離 Host にアクセス アプリの脆弱性 コンテナランタイムの設定 Docker Hub Docker Registry 適当なストレージ イメージの「ビルド」 マニフェストの作成 ③コンテナのリスク ⑤ホストOSのリスク ②レジストリのリスク ①イメージのリスク 知的財産の損失 秘密鍵の埋め込まれたコンテナ 出所不明のイメージ 脆弱性(意図的な埋込) 脆弱性(古いイメージ) レジストリへのアクセス権限 脆弱性(古いイメージ) OSへの侵入 脆弱性の放置 ④オーケストレー ターのリスク ※ 文言は、NIST SP800-190 をそのまま書き写しているわけではなく、抜粋アレンジしています。 コンテナオーケストレーター セキュアなアクセス Kubernetes の世界では、ユーザーが k8sに直接 アプリをインストールする事はなく、k8sが「マ ニフェスト」に書かれたイメージをレジストリー から引っ張ってくる。 レジストリ レジストリ レジストリ Kubernetes の世界では、 アプリケーションの不具合、 脆弱性の「パッチ適用」は、 ここで行われる。
13. Host Host ACS のカバレッジ コンテナのベース・ イメージ(外部) ユーザーが作成し た独自のイメージ 新しいコンテナの作成 マニフェスト(YAML) RHEL8のイメージ Ubuntuのイメージ テスト Kubernetes Host RHEL8 ユーザー コンテナ ユーザー コンテナ RHEL8 ユーザー コンテナ プログ ラム 実行 環境 + + = 使用するイメージ レプリカ数 PVのサイズ etc GitHub Quay Red Hat Eco System Catalog オーケストレーター管理者の設定 root 権限での実行 不十分なコンテナ間分離 Host にアクセス アプリの脆弱性 コンテナランタイムの設定 Docker Hub Docker Registry 適当なストレージ イメージの「ビルド」 マニフェストの作成 ③コンテナのリスク ⑤ホストOSのリスク ②レジストリのリスク ①イメージのリスク 知的財産の損失 秘密鍵の埋め込まれたコンテナ 出所不明のイメージ 脆弱性(意図的な埋込) 脆弱性(古いイメージ) レジストリへのアクセス権限 脆弱性(古いイメージ) OSへの侵入 脆弱性の放置 ④オーケストレー ターのリスク ※ 文言は、NIST SP800-190 をそのまま書き写しているわけではなく、抜粋アレンジしています。 コンテナオーケストレーター セキュアなアクセス Kubernetes の世界では、ユーザーが k8sに直接 アプリをインストールする事はなく、k8sが「マ ニフェスト」に書かれたイメージをレジストリー から引っ張ってくる。 レジストリ レジストリ レジストリ Kubernetes の世界では、 アプリケーションの不具合、 脆弱性の「パッチ適用」は、 ここで行われる。 ACSのおおよそのカバー範囲 ※Registry, CI/CD ツー ル / Kuberentes そのも のは含まない ※この部分は Kuberentes に格納された後 に見られ ている
14. ACSアーキテクチャー Architecture
15. 包括的な可視性を提供 全てのイメージ、コンテナ・レジスト リ、 Kuberentes Deployment の構成、 コンテナの実行時の振る舞い検知 可視化 脆弱性管理 ポリシーを使った構成の検査 アプリケーション(Deployment)間で 使用されている Secret の検知 既知の脆弱性の検知。CI/CDパイプラインや、 デプロイされたイメージのスキャン。 CVE / CVSS による可視化。 アプリケーションの安全ではない構成や、課 題な権限の要求のスキャンによる検知。 構成管理 ACS (Advanced Cluster Security) for Kuberentes主要機能 セキュリティ項目を、影響度や、セ キュリティー侵害の可能性に会わせて、 ヒューリスティックに判断し、対応の Priorityを提示 リスク・プロファイリング
16. CIS ベンチマーク, NIST, PCI, HIPAA等の 300以上のコントロールを使った、継続的 ないコンプライアンスの評価 自動化されたコンプライアンスとAudit ベースラインの振る舞い情報を作成し、 シェル実行などの異常な振る舞い時にアラー トを生成。 ランタイム検知 Pod 間のネットワークのフロー情報を 検知し表示。 Kuberentes の NetworkPolicyを自動 的に生成。 ネットワーク・セグメンテーショ ン ACS (Advanced Cluster Security) for Kuberentes主要機能 ビルド時、デプロイ時のセキュリ ティ・ポリシーの適用。 脆弱性や、構成の分析を CI/CD プロ セスへ統合 ポリシー / DevSecOps
17. 可視化 / リスク・プロファイリング
18. ACS ダッシュボード 一覧 詳細 コンプライアンス遵守状況 Policy 違反状況 • ACSが把握している状況を一 覧で把握するためのメインの ダッシュボード • デフォルトの Policy、ユー ザー定義の Policy の違反状 況 • コンプライアンスのベンチ マークの遵守状況 (CIS / HIPAA / NIST SP 800-190 / NIST SP 800-53 / PCI DSS) 詳細 Dashboard 一覧
19. リスク・プロファイリング 対応すべき優先度を提案 実運用環境で発生する問題に全て同じ Priority では対応で きない。 Policy違反、疑わしい Activity、Image の脆弱性、危険な 構成、危険なツールのインストール状況、Image の新しさ 等の複数の要素を元に対応すべき Priority を提案 判断の元になった Policy違反など リスクのあるアプリケーション (Deployment) 名
20. ランタイム検知 実行が検知された疑わ しいプロセス 検知時刻 リスクのあるDeployment
21. 脆弱性管理
22. 脆弱性管理 • 管理環境内の脆弱性の種類を、CVSS スコアや数、Fixが存在しているか等、 複数のカットで情報を提供 • 一番時間のかかる「この脆弱性はど のような脆弱性なのか」「Fixは存在 しているのか」を調査する時間を大 幅に削減 Deployment内の脆弱性情報のサマリー Deployment に含まれてい る Image のCVE の一覧 イメージのどのレイヤーに 脆弱性が含まれているか CVE 情報の詳細 修正モジュールのバー ジョン等 環境内の脆弱性の高い Deployment
23. Deployment に含まれる脆弱性 CVSS (Common Vulerbility Scoring System)スコア 修正があるか CVE番号
24. Networkセグメンテーション
25. Network セグメンテーション • Deployment間、外部とのネット ワーク通信を通信方向、プロトコル、 ポートで監視 • Networkのアクティビティを観察 しbaselineを作成 • basline から外れた通信を自動で検 知、アラート化 baseline には無いアクティビ ティを監視 通常時のネットワークの 動きを観測 baseline flow を作成 baseline を元に、Kubernetes の Network Policy を自動生成 anomalous flow baseline flow deployment 毎 の Ingress / Egress フローの 詳細をトラッキン グ
26. Network セグメンテーション Network Policy Emulator Kuberentes の NetworkPolicy をトラフィックをベースに自動生成 自分で作成した Network Poliyをアップロード するエリア
27. ポリシー / DevSecOps
28. ポリシー GUI による Policy 作成画面 Policy の評価をどのタイミングで行うか Buildのタイミングでの Policy評価 Deployのタイミングでの Policy評価 コンテナ実行中の Policy評価 「apk」というコンポーネントの 全てのバージョン。が入って居る場合… 条件 (Criteria) を追加して Policy を作成 Wizard 形式で、プリセットの Policy 以外にもユーザーが追加でポリシーを作成 Wizard 形式で入力
29. DevSecOps とシフトレフト Image scanning Registries CI/CD tools DevOps notification SIEM Build Secure supply chain Deploy Secure infrastructure Run Secure workloads Policy engine API AWS Security Hub Run anywhere OpenShift Amazon EKS Google GKE Azure AKS 3rd Party ツール群 ビルド時に、危険な構成や、 脆弱性を見つけて開発者に エラーを返す コンテナが Kuberentes に Deploy される前にイ メージに問題が無いか チェック コンテナ内から必要 の無いプログラムが 起動していないか等 セキュリティの対策は、できるだけ開発の初期から行う（シフト・レフト)
30. CI/CD との統合 # Image の Security Policy 違反チェック ./roxctl imache check --image=<image-name> # Image の scan ./roxctl image scan --image=<image-name> # Deployment の Security Policy 違反チェック ./roxctl –e “$OX_CENTRAL_ADDRESS” deployment check --file=<yaml-filename> ✗ Image gcr.io/rox-se/sample-image:getting-started failed policy 'Docker CIS 4.1: Ensure That a User for the Container Has Been Created' - Description: ↳ Containers should run as a non-root user - Rationale: ↳ It is good practice to run the container as a non-root user, where possible. This can be done via the USER directive in the Dockerfile. - Remediation: ↳ Ensure that the Dockerfile for each container switches from the root user - Violations: - Image has user 'root’ <省略> - Violations: - Fixable CVE-2021-20205 (CVSS 6.5) found in component 'libjpeg-turbo' (version 2.0.6-r0), resolved by version 2.1.0-r0 - Fixable CVE-2021-22876 (CVSS 5.3) found in component 'curl' (version 7.74.0-r0), resolved by version 7.76.0-r0 - Fixable CVE-2021-22890 (CVSS 3.7) found in component 'curl' (version 7.74.0-r0), resolved by version 7.76.0-r0 - Fixable CVE-2021-28831 (CVSS 7.5) found in component 'busybox' (version 1.32.1-r3), resolved by version 1.32.1-r4 - Fixable CVE-2021-30139 (CVSS 7.5) found in component 'apk-tools' (version 2.12.1-r0), resolved by version 2.12.5-r0 • CI/CDツールに統合可能な CLI ツール • Image や Deployment の Security Policy 違反や Image Scan を行う。 • 開発者に対するわかりやすく 違反 (Violation) 内容と、その対策 (Remediation) を提示 結果サンプル
31. Red Hat が提供するコンテナの脆弱性情報 1年以上前のイメージ 4ヶ月前のイメージ 最新のイメージ old new 古いイメージをそのまま使い続ける事は、脆弱性を放置する事につながります。 以下は、Red Hat が OpenSfhit 用に提供している ElasticSearch コンテナのバージョンによる脆弱性の違いです。 Red Hat が提供するコンテナイメージにつついては、常に最新の脆弱性の情報が提供されます。 F D A Health Health Health https://catalog.redhat.com/ https://catalog.redhat.com/software/containers/rhceph-beta/rhceph-4-dashboard-rhel8/5e965720d70cc54b02d1f413?container-tabs=security
32. コンテナのビルドプロセス 開発用の端末 / OpenShift 上のコンテナ開発環境 Kubernetes Repository user コンテナ Build Secure supply chain Deploy Secure infrastructure Run Secure workloads base コンテナ User コンテナ User コンテナ ミドルウェア ユーザー・プログラム CI/CDプロセス Build Deploy Run Private Registry Repository • 脆弱性が発覚した場合、コンテナを再ビルドする必要が ある。 • CI/CDプロセスを自動化して整備しておく事で脆弱性対 応時の運用負荷を軽減可能 実際にはさらに開発・検証・本 番プロセスを考慮する必要があ る Base Image Public Repository Middleware Public Repository Source Code Repository
33. コンテナのビルドプロセス 開発用の端末 / OpenShift 上のコンテナ開発環境 Kubernetes Repository user コンテナ Build Secure supply chain Deploy Secure infrastructure Run Secure workloads base コンテナ User コンテナ User コンテナ ミドルウェア ユーザー・プログラム CI/CDプロセス Build Deploy Run Private Registry Repository • 脆弱性が発覚した場合、コンテナを再ビルドする必要が ある。 • CI/CDプロセスを自動化して整備しておく事で脆弱性対 応時の運用負荷を軽減可能 実際にはさらに開発・検証・本 番プロセスを考慮する必要があ る Base Image Public Repository Middleware Public Repository Source Code Repository OpenShift Pipeline OpenShift GitOps OpenShift Builds
34. 自動化されたコンプラ イアンス管理とAudit
35. コンプライアンス管理 遵守状況 – CIS Docker – CIS K8s – HIPPA – NIST SP 800-190 – NIST SP 800-53 – PCI • Namespace 毎に要求されるコンプライアンスが異 なる → Kuberentese Namespace 毎のコンプライアン ス適合状況を表示 • レポートの生成が必要 → PDF / CSV形式のレポート出力 対応している規格
36. コンプライアンス・レポーティング レポーティングの format は、pdf 形式と csv の両 方に対応
37. 外部連携
38. 外部連携 (Integration) API リファレンス 3rd Party ツールとの連携のための標準的なインターフェイスと、 プログラムからアクセスするための APIリファレンスを提供
39. サポート対象プラットフォーム
40. サポート対象プラットフォーム Red Hat Advanced Cluster Security for Kubernetes Support Policy - Red Hat Customer Portal Central = Server コンポーネント ( スキャナー、Persitent Storage、User Interface)
41. リソース • マニュアル (StackRox) https://help.stackrox.com/ • デモビデオ (440) OCB: StackRox Overview and Demo - YouTube
42. Red Hat is the world’s leading provider of enterprise open source software solutions. Award-winning support, training, and consulting services make Red Hat a trusted adviser to the Fortune 500. Thank you