Сегодня речь пойдет не о security, а о compliance в Kubernetes ;)

Надеюсь, все знают и понимают разницу между ними. И так в различных коммерческих решениях мне доводилось видеть следующие виды комплаенсов:
- CIS Benchmarks Docker
- CIS Benchmarks Kubernetes
- HIPPA
- NIST SP 800-190
- NIST SP 800-53
- PCI DSS
- SOC 2
- GDPR
- AWS Well-Architected Framework
- ISO27001

По сути пункты из этих документов переносятся в проверки, и система определяет сколько из них прошли успешно. Возможно 3 развития события:
1) Пункт считается закрытым, тем фактом что у вас используется само решение, которое и проводит проверку
2) Пункт может считаться закрытым, если определенные настройки в системе применены
3) Пункт остается открытым, так как решение не способно определить - обычно это какие-то не технические процессные вещи. (такое бывает до 50% от всех проверок)

Помните, что это чеклисты и они абсолютно не учитывают контекст.

k8s (in)security

Сегодня речь пойдет не о security, а о compliance в Kubernetes ;)

Надеюсь, все знают и понимают разницу между ними. И так в различных коммерческих решениях мне доводилось видеть следующие виды комплаенсов:
- CIS Benchmarks Docker
- CIS Benchmarks Kubernetes
- HIPPA
- NIST SP 800-190
- NIST SP 800-53
- PCI DSS
- SOC 2
- GDPR
- AWS Well-Architected Framework
- ISO27001

По сути пункты из этих документов переносятся в проверки, и система определяет сколько из них прошли успешно. Возможно 3 развития события:
1) Пункт считается закрытым, тем фактом что у вас используется само решение, которое и проводит проверку
2) Пункт может считаться закрытым, если определенные настройки в системе применены
3) Пункт остается открытым, так как решение не способно определить - обычно это какие-то не технические процессные вещи. (такое бывает до 50% от всех проверок)

Помните, что это чеклисты и они абсолютно не учитывают контекст.

hottg.com/k8security/188

1.24K viewsD1g1, edited  Jan 22, 2021 at 06:41