HOME デベロッパー向け OpenShift Security Red Hat CoreOS
OpenShift Security インデックス
- OpenShift Security
- Red Hat CoreOS
- Container Security
セキュリティのガイドラインについて
コンテナ/コンテナに近い部分
具体的な製品・設定についての指定は無いレベル (抽象的)
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)
医療情報のプライバシーとセキュリティに関する法律。それを満たすためのデータのプライバシーとセキュリティ要件。
HIPAA (Health Insurance Portability and Accountability Act)
医療情報のプライバシーとセキュリティに関する法律。それを満たすためのデータのプライバシーとセキュリティ要件。
PCI DSS (Payment Card Industry Data Security Standard)
クレジットカードの情報を保護する事を目的に作られた、クレカ向けシステムの基準。
審査機関が存在し、認証が取得できる。定期的な検査も求められる。
参考:NIST SP 800-190
SP=Special Publication. コンテナを使用する上でのセキュリティの考慮ポイント
(一般的なリスク・ポイントと対策の概念について言及したもので、具体的な手法、ツールなどについてガイドしているわけではありません)
- IPA による翻訳版もあります
https://www.ipa.go.jp/files/000085279.pdf
3.1. イメージのリスク
| 3.1.1 | イメージの脆弱性 |
|
| 3.1.2 | イメージ設定の不備 |
|
| 3.1.3 | 埋め込まれたマルウェア |
|
| 3.1.4 | 踏め混まれた平文の秘密情報 |
|
| 3.1.5 | 信頼できないイメージの使用 |
|
3.2. レジストリのリスク
| 3.2.1 | レジストリへのセキュアでない接続 |
|
| 3.2.2 | レジストリ内の古いイメージ |
|
| 3.2.3 | 認証・認可の不十分な制限 |
|
3.3. オーケストレーターのリスク
| 3.3.1 | 制限のない管理者アクセス |
|
| 3.3.2 | 不正アクセス |
|
| 3.3.3 | コンテナ間ネットワークトラフィックの不十分な分離 |
|
| 3.3.4 | ワークロードの機微性レベルの混合 |
|
| 3.3.5 | オーケストレーターノードの信頼 |
|
3.4. コンテナのリスク
| 3.4.1 | コンテナ・ランタイムの脆弱性 |
|
| 3.4.2 | コンテナからの無制限ネットワークアクセス |
|
| 3.4.3 | セキュアでないコンテナランタイムの設定 |
|
| 3.4.4 | アプリの脆弱性 |
|
| 3.4.5 | 未承認コンテナ |
|
3.5. ホストOSのリスク
| 3.5.1 | 大きなアタックサーフェス |
|
| 3.5.2 | 共有カーネル |
|
| 3.5.3 | ホストOSコンポーネントの脆弱性 |
|
| 3.5.4 | 不適切なユーザーアクセス権 |
|
| 3.5.5 | ホストOSファイルシステムの改竄 |
|
セキュリティのガイドラインについて
セキュリティのガイドラインの多くは、一つ一つの項目を全てをカバーしなければいけないというものではなく、あくまで気づきを与えてくれるものです。
- 具体的な対策方法を教えてくれるものではありません。
例：ホストOSはアタックサーフェスが大きい。 - 一つ一つの項目は相互に関わっている場合もあります。
- ガイドラインの想定はあくまで、一般的なものなので、実際のシステムには当てはまらない事もあります。注意すべき視点を与えてくれるものとなります。
- どのレベルでどの項目をカバーするか。セキュリティレベルを上げる事は、運用負荷とシステム負荷を上げる事になり、限度も無くコストとの兼ね合いになる。動かすアプリによっても適切なレベルがあります。
例：インターネット上の公開掲示板システムに PCIを適用する必要は通常ありません。
暗号化されているため監視できない。と言って全てのポイントで暗号化/復号化すると、システムに過大な負荷をかけます。
全ての兆候を捉えるために SIEM を導入する場合は、大量のログを管理・分析するためのリソースが必要になります。 - ある機能に対応しているセキュリティ製品があっても「できる」というのと「どのレベルで」「できる」のかは違います。
- 適切な箇所に、適切なレベルのセキュリティ設計を行います（判断するには、それなりの時間と、理解できるエンジニアが必要です）。
- 補足
- コンテナ関連のセキュリティ・スタンダートでは、NIST SP 800-204 「Security Strategies for Microservices-based Application Systems」というのもあります。
https://csrc.nist.gov/pubs/sp/800/204/final
コンテナ環境におけるセキュリティ (NIST SP 800-190視点)
- ※
- 文言は、NIST SP800-190 をそのまま書き写しているわけではなく、抜粋アレンジしています。
コンテナ / コンテナ環境のリスク (NIST SP 800-190視点)
OpenShift も標準で、セキュリティを考えた設計 / 実装 がされています。
①イメージのリスク
イメージの脆弱性、秘密情報の埋め込まれたコンテナ、出所不明なイメージ Quay、CSO(Container Security Operator) 、Red Hat Ecosystem Catalog のベースイメージの使用
②レジストリのリスク
認証・認可、知的財産の喪失 Docker Registry の project ベースのアクセス制御、Quay によるアクセス制御、Geo Replication / Mirroring
③オーケストレーターのリスク
カーネルの共有、ホストＯＳの設定、コンテナ間のアクセス分離 File Compliance Operator、SELinux、SCC(Security Context Constrain)、OTAによる簡単な最新へのアップデート
④コンテナのリスク
ランタイム、ネットワークアクセス CRI-O / NetworkPolicy / namespace (Project)
- ※
-
NetworkPolicy, namespace は K8S標準のもの
- NetworkPolicy は、使用されるCNIプラグインによっては使用できないが、OpenShift SDNは対応している
- OpenShift の project (namespace ) では、template という概念があり、ユーザーが project を作成した時にデフォルトの “template” を適用でき、そこでデフォルトの NetworkPolicy を適用する事ができる。
⑤ホストＯＳのリスク
広いアタックサーフェス CoreOS、Machine Config Operator、Compliance Operator、OTA(Over The Air Update)
