As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Compliance
A conformidade é uma responsabilidade compartilhada entre a AWS e os consumidores de seus serviços. De um modo geral, a AWS é responsável pela “segurança da nuvem”, enquanto seus usuários são responsáveis pela “segurança na nuvem”. A linha que define o que a AWS e seus usuários são responsáveis variará de acordo com o serviço. Por exemplo, com o Fargate, a AWS é responsável por gerenciar a segurança física de seus datacenters, do hardware, da infraestrutura virtual (Amazon EC2) e do tempo de execução do contêiner (Docker). Os usuários do Fargate são responsáveis por proteger a imagem do contêiner e seu aplicativo. Saber quem é responsável pelo quê é uma consideração importante ao executar cargas de trabalho que devem seguir os padrões de conformidade.
A tabela a seguir mostra os programas de conformidade com os quais os diferentes serviços de contêiner estão em conformidade.
| Programa de conformidade | Orquestrador Amazon ECS | Orquestrador Amazon EKS | ECS Fargate | Amazon ECR |
|---|---|---|---|---|
|
PCI DSS nível 1 |
1 |
1 |
1 |
1 |
|
Elegível para HIPAA |
1 |
1 |
1 |
1 |
|
SOC É |
1 |
1 |
1 |
1 |
|
SOC II |
1 |
1 |
1 |
1 |
|
SOC III |
1 |
1 |
1 |
1 |
|
ISO 27001:2013 |
1 |
1 |
1 |
1 |
|
ISO 9001:2015 |
1 |
1 |
1 |
1 |
|
ISO 27017:2015 |
1 |
1 |
1 |
1 |
|
ISO 27018:2019 |
1 |
1 |
1 |
1 |
|
IRAP |
1 |
1 |
1 |
1 |
|
FedRAMP Moderado (Leste/Oeste) |
1 |
1 |
0 |
1 |
|
FedRAMP High () GovCloud |
1 |
1 |
0 |
1 |
|
DOD CC SRG |
1 |
Avaliação da DISA (1) IL5 |
0 |
1 |
|
HIPAA BAA |
1 |
1 |
1 |
1 |
|
MTCS |
1 |
1 |
0 |
1 |
|
C5 |
1 |
1 |
0 |
1 |
|
K-ISMS |
1 |
1 |
0 |
1 |
|
ENS High |
1 |
1 |
0 |
1 |
|
OSPAR |
1 |
1 |
0 |
1 |
|
HITRUST CSF |
1 |
1 |
1 |
1 |
O status de conformidade muda com o tempo. Para obter o status mais recente, sempre consulte https://aws.amazon.com/compliance/services-in-scope/
Para obter mais informações sobre modelos de credenciamento de nuvem e melhores práticas, consulte o whitepaper da AWS, Modelos de credenciamento
Deslocando para a esquerda
O conceito de mudar para a esquerda envolve detectar violações e erros de políticas no início do ciclo de vida do desenvolvimento de software. Do ponto de vista da segurança, isso pode ser muito benéfico. Um desenvolvedor, por exemplo, pode corrigir problemas com sua configuração antes que o aplicativo seja implantado no cluster. Detectar erros como esse mais cedo ajudará a impedir que configurações que violem suas políticas sejam implantadas.
Política como código
A política pode ser considerada como um conjunto de regras para governar comportamentos, ou seja, comportamentos permitidos ou proibidos. Por exemplo, você pode ter uma política que diz que todos os Dockerfiles devem incluir uma diretiva USER que faça com que o contêiner seja executado como um usuário não root. Como documento, uma política como essa pode ser difícil de descobrir e aplicar. Também pode ficar desatualizado à medida que seus requisitos mudam. Com as soluções Policy as Code (PaC), você pode automatizar os controles de segurança, conformidade e privacidade que detectam, previnem, reduzem e neutralizam ameaças conhecidas e persistentes. Além disso, eles fornecem um mecanismo para codificar suas políticas e gerenciá-las da mesma forma que você faz com outros artefatos de código. A vantagem dessa abordagem é que você pode reutilizar suas GitOps estratégias DevOps e estratégias para gerenciar e aplicar políticas de forma consistente em frotas de clusters Kubernetes. Consulte o Pod Security
Use policy-as-code ferramentas em pipelines para detectar violações antes da implantação
-
O OPA é um
mecanismo de políticas de código aberto que faz parte do CNCF. Ele é usado para tomar decisões políticas e pode ser executado de várias maneiras diferentes, por exemplo, como uma biblioteca de idiomas ou um serviço. As políticas de OPA são escritas em uma linguagem específica de domínio (DSL) chamada Rego. Embora geralmente seja executado como parte de um Kubernetes Dynamic Admission Controller como o projeto Gatekeeper , o OPA também pode ser incorporado ao seu pipeline de CI/CD. Isso permite que os desenvolvedores obtenham feedback sobre sua configuração no início do ciclo de lançamento, o que pode posteriormente ajudá-los a resolver problemas antes de começarem a produção. Uma coleção de políticas comuns de OPA pode ser encontrada no GitHub repositório deste projeto. -
O Conftest
é construído com base no OPA e fornece uma experiência focada no desenvolvedor para testar a configuração do Kubernetes. -
O Kyverno
é um mecanismo de políticas projetado para o Kubernetes. Com o Kyverno, as políticas são gerenciadas como recursos do Kubernetes e nenhuma nova linguagem é necessária para criar políticas. Isso permite usar ferramentas conhecidas, como kubectl, git e kustomize, para gerenciar políticas. As políticas da Kyverno podem validar, alterar e gerar recursos do Kubernetes, além de garantir a segurança da cadeia de suprimentos de imagens da OCI. A CLI do Kyverno pode ser usada para testar políticas e validar recursos como parte de um pipeline de CI/CD. Todas as políticas da comunidade Kyverno podem ser encontradas no site da Kyverno e, para exemplos de como usar a CLI do Kyverno para escrever testes em pipelines, consulte o repositório de políticas.
Ferramentas e recursos
-
Workshop de imersão em segurança do Amazon EKS — Conformidade regulatória
-
Análise de segurança do Kubernetes Uma avaliação de segurança
terceirizada do Kubernetes 1.13.4 (2019) -
NeuVector da SUSE
, plataforma de segurança de contêineres de código aberto e de confiança zero, fornece relatórios de conformidade e verificações de conformidade personalizadas
