Saltar para o conteúdo principal
A MKA1 gerencia todas as chaves criptográficas por meio do AWS KMS, que é sustentado por módulos de segurança de hardware validados pelo FIPS 140-2 Nível 3. O TLS 1.3 é imposto em todos os endpoints públicos e nas conexões internas do banco de dados, com tamanhos de chave verificados que atendem aos requisitos de conformidade.

​
O que está ativo

​
Gerenciamento de chaves com HSM

Os controles abaixo foram verificados no ambiente de produção ao vivo:
  • A criptografia de envelope dos segredos do EKS utiliza uma chave AWS KMS gerenciada pelo cliente (arn:aws:kms:us-west-2:REDACTED:key/...).
  • A chave KMS é sustentada por HSMs validados pelo FIPS 140-2 Nível 3, operados pela AWS.
  • Os segredos criptografados com SOPS em repouso no repositório também utilizam o AWS KMS para criptografia de envelope.
  • Os volumes EBS conectados ao cluster de produção utilizam encrypted: "true" com a storage class gp3, com chaves de criptografia gerenciadas pelo KMS.

​
Imposição de TLS 1.3

Os controles abaixo foram verificados no ambiente de produção ao vivo:
  • apigw.mka1.com:443 negociou TLSv1.3 com a cipher suite TLS_AES_128_GCM_SHA256.
  • livekit.mka1.com:443 negociou TLSv1.3 com a cipher suite TLS_AES_128_GCM_SHA256.
  • Ambos os endpoints utilizam troca de chaves X25519 (253 bits) e chaves públicas RSA de 2048 bits emitidas pelo AWS Certificate Manager.
  • A política SSL do ALB ELBSecurityPolicy-TLS13-1-2-2021-06 está configurada nos ingresses do Kong e do LiveKit, garantindo apenas TLS 1.3 e cifras fortes de TLS 1.2.
  • O cluster CNPG/PostgreSQL de produção impõe ssl_min_protocol_version: TLSv1.3 e ssl_max_protocol_version: TLSv1.3.
  • Os certificados TLS do banco de dados são gerenciados pelo cert-manager com secrets dedicados: clientCASecret, serverCASecret, serverTLSSecret e replicationTLSSecret.

​
Como validamos isso

Validamos o uso de chaves com HSM e a imposição de TLS 1.3 com inspeção direta do cluster e testes nos endpoints. O uso da chave KMS e o suporte por HSM são confirmados pela descrição do cluster EKS: 
aws eks describe-cluster --name mk1-eks-production --region us-west-2 \
  --query 'cluster.encryptionConfig'
O handshake TLS 1.3 e os tamanhos de chave são verificados com openssl s_client: 
openssl s_client -connect apigw.mka1.com:443 -servername apigw.mka1.com -tls1_3 -brief
openssl s_client -connect livekit.mka1.com:443 -servername livekit.mka1.com -tls1_3 -brief
A configuração de TLS do banco de dados é verificada diretamente no cluster ao vivo: 
kubectl -n cnpg get cluster -o yaml | grep -A2 ssl

​
Evidências

Os trechos sanitizados abaixo foram extraídos de verificações contra a nossa implantação de produção ao vivo.

​
Provedor KMS no cluster EKS

{
  "cluster": {
    "name": "mk1-eks-production",
    "encryptionConfig": [
      {
        "resources": ["secrets"],
        "provider": {
          "keyArn": "arn:aws:kms:us-west-2:[redacted-account]:key/[redacted-key-id]"
        }
      }
    ]
  }
}

​
Handshake TLS 1.3 com tamanhos de chave — apigw.mka1.com

CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_128_GCM_SHA256
Peer Temp Key: X25519, 253 bits
Verification: OK
...
Server public key is 2048 bit
Verify return code: 0 (ok)

​
Handshake TLS 1.3 com tamanhos de chave — livekit.mka1.com

CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_128_GCM_SHA256
Peer Temp Key: X25519, 253 bits
Verification: OK
...
Server public key is 2048 bit
Verify return code: 0 (ok)

​
Política SSL do ALB e configuração TLS do banco de dados

Kong public ingress:
- alb.ingress.kubernetes.io/ssl-policy: ELBSecurityPolicy-TLS13-1-2-2021-06

CNPG/PostgreSQL:
- ssl_min_protocol_version: TLSv1.3
- ssl_max_protocol_version: TLSv1.3
- clientCASecret: mk1-db-[redacted]
- serverCASecret: mk1-db-[redacted]
- serverTLSSecret: mk1-db-[redacted]
- replicationTLSSecret: mk1-db-[redacted]