Segurança

Controles de Segurança

Projetos criados pelo Nx Plugin for AWS incluem uma série de controles de segurança prontos para uso. Esta página fornece uma visão geral desses controles e links para os guias relevantes para mais detalhes.

Verificação de Infraestrutura

Projetos de infraestrutura são configurados com Checkov como parte do target build, de modo que configurações de infraestrutura inseguras falham a build:

Projetos CDK sintetizam templates CloudFormation que são verificados pelo Checkov. Consulte Security Testing para detalhes.
Projetos Terraform executam o Checkov diretamente no seu código Terraform. Consulte Terraform Projects.

Quando a infraestrutura fornecida suprime uma regra do Checkov, a supressão é limitada ao recurso específico e anotada com uma justificativa. O helper compartilhado suppressRules requer uma razão para cada supressão, e recomendamos seguir a mesma prática no seu próprio código. Consulte Suppressing Checkov Checks.

Verificação de Imagens de Contêiner

Projetos que constroem imagens de contêiner (por exemplo, agents, servidores MCP e imagens de migração de banco de dados) incluem um target trivy que verifica imagens em busca de vulnerabilidades HIGH e CRITICAL antes de serem implantadas, falhando a build em caso de descobertas. Consulte Docker Bundling para detalhes, incluindo como suprimir descobertas com um arquivo .trivyignore.

Verificação de Credenciais

Workspaces incluem hooks de pré-commit do git-secrets que verificam arquivos preparados em busca de padrões de credenciais AWS, prevenindo commits acidentais de chaves de acesso e outros valores sensíveis. Consulte a seção Git Secrets do guia de workspace.

Autenticação

APIs, agents e servidores MCP usam autenticação AWS IAM (SigV4) por padrão:

APIs tRPC, FastAPI e Smithy usam autenticação IAM por padrão, com Cognito e autorizadores personalizados disponíveis como opções. O stub de autorizador personalizado fornecido nega requisições por padrão.
Agents e servidores MCP implantados no Amazon Bedrock AgentCore Runtime usam autenticação IAM (SigV4) por padrão, com autenticação Cognito baseada em JWT como opção.
O gerador de autenticação de website fornece um user pool do Amazon Cognito com autenticação multifator (MFA) obrigatória, uma política de senha forte e proteção contra exclusão habilitada.

Criptografia

A infraestrutura fornecida criptografa dados em trânsito e em repouso:

Websites são servidos via CloudFront com HTTP redirecionado para HTTPS, e uma política de cabeçalhos de resposta incluindo HTTP Strict Transport Security (HSTS), uma Content Security Policy e outros cabeçalhos de segurança. Um WAF com regras gerenciadas pela AWS está associado à distribuição.
Buckets S3 bloqueiam todo acesso público, impõem acesso somente SSL via políticas de bucket, são criptografados (KMS com rotação de chaves para conteúdo de website) e entregam logs de acesso ao servidor para grupos de log do CloudWatch criptografados com chaves KMS gerenciadas pelo cliente, onde podem ser consultados com Logs Insights e monitorados com alarmes.
Logs de acesso de API são gravados em grupos de log do CloudWatch criptografados com chaves KMS gerenciadas pelo cliente com rotação habilitada.
Bancos de dados Aurora habilitam criptografia de armazenamento com uma chave KMS gerenciada pelo cliente, geram credenciais no AWS Secrets Manager (nunca codificadas) e suportam rotação automática de credenciais.

Privilégio Mínimo

Constructs CDK e módulos Terraform fornecidos seguem o princípio do privilégio mínimo:

Constructs expõem métodos grant* (por exemplo, grantInvokeAccess em APIs e agents, grantConnect em bancos de dados) para que os consumidores concedam apenas o acesso necessário.
Políticas IAM na infraestrutura fornecida são limitadas a recursos e ações específicas. Quando um recurso curinga é exigido pelo serviço AWS (por exemplo, ecr:GetAuthorizationToken), ele é limitado a essas ações e restringido com condições quando suportado.

Licenciamento de Dependências

O gerador de licença configura gerenciamento automatizado de cabeçalhos de licença e verificação de licenças de dependências contra uma lista de permissões de licenças aprovadas, ajudando você a detectar dependências transitivas problemáticas antes de serem enviadas.

Responsabilidade

Segurança e conformidade é uma responsabilidade compartilhada. A AWS descreve isso através do Modelo de Responsabilidade Compartilhada, que distingue entre segurança da nuvem (responsabilidade da AWS) e segurança na nuvem (sua responsabilidade como cliente).

O Nx Plugin for AWS ajuda você a abordar partes do seu lado desse modelo. Seus geradores fornecem fundações seguras e codificam as melhores práticas da AWS dentro do escopo do código que produzem — os controles descritos acima. Isso reduz o esforço necessário para construir com segurança, mas não transfere a propriedade da segurança para o plugin.

Você é proprietário do código que é gerado em seu workspace e permanece responsável por sua segurança. Uma vez fornecido, o código gerado é seu para modificar, estender e operar, e deve ser tratado da mesma forma que qualquer outro código que você escreve.

Em particular:

O escopo do plugin é limitado aos seus geradores. O plugin não tem conhecimento da lógica de negócios da sua aplicação, classificação de dados, modelo de ameaças ou obrigações regulatórias, e não pode tomar decisões que dependam deles.
A autenticação está configurada, mas a autorização não. As APIs são protegidas com autenticação por padrão (por exemplo, IAM/SigV4), mas o plugin não pode determinar quais principais autenticados devem ter permissão para executar quais operações em quais recursos. A autorização refinada depende da sua lógica de negócios e deve ser projetada, implementada e testada por você.
O código gerado é um ponto de partida, não um produto acabado. À medida que você adiciona funcionalidades, você introduz considerações de segurança que o plugin não pode antecipar — validação de entrada, manipulação de dados, gerenciamento de segredos, escolhas de dependências e integrações com outros sistemas.

Consequentemente, você deve revisar o código gerado e as aplicações que você constrói sobre ele de acordo com as políticas de segurança, padrões e processos de revisão da sua própria organização, e submetê-los à mesma modelagem de ameaças, testes de segurança e portões de aprovação que você aplica a qualquer carga de trabalho de produção. Os controles fornecidos pelo plugin são destinados a complementar esses processos, não a substituí-los.