Recursos de segurança incorporados do ADDF - AWS Orientação prescritiva

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á.

Recursos de segurança incorporados do ADDF

O Autonomous Driving Data Framework (ADDF) tem vários recursos de segurança incorporados. Por padrão, esses recursos são projetados para ajudar você a configurar uma estrutura segura e ajudar sua organização a atender aos requisitos de segurança corporativa comuns.

A seguir estão os recursos de segurança incorporados:

Privilégio mínimo para o código do módulo ADDF

Privilégio mínimo é a prática recomendada de segurança para conceder as permissões mínimas necessárias para executar uma tarefa. Para obter mais informações, consulte Aplicar permissões de privilégios mínimos. Os módulos fornecidos pelo ADDF seguem rigorosamente o princípio de privilégios mínimos em seus códigos e recursos implantados, da seguinte forma:

  • Todas as políticas do AWS Identity and Access Management (IAM) geradas para um módulo ADDF têm as permissões mínimas necessárias para o caso de uso. 

  • Os Serviços da AWS são configurados e implantados de acordo com o princípio de privilégios mínimos. Os módulos fornecidos pelo ADDF usam somente os serviços e os recursos de serviço necessários para o caso de uso específico.

Infraestrutura como código

O ADDF, como estrutura, foi projetado para implantar módulos ADDF como infraestrutura como código (IaC). O IaC elimina os processos de implantação manual e ajuda a evitar erros e configurações incorretas, que podem resultar de processos manuais. 

O ADDF foi projetado para orquestrar e implantar módulos usando qualquer estrutura comum de IaC. Isso inclui, mas não está limitado a: 

Você pode usar diferentes estruturas de IaC para escrever módulos diferentes e, em seguida, usar o ADDF para implantá-los.

A estrutura IaC padrão usada pelos módulos ADDF é o AWS CDK. O AWS CDK é uma abstração orientada a objetos de alto nível que você pode usar para definir recursos da AWS imperativamente. O AWS CDK já impõe as práticas recomendadas de segurança por padrão para vários serviços e cenários. Ao usar o AWS CDK, o risco de configurações incorretas de segurança é reduzido.

Verificações de segurança automatizadas para IaC

O utilitário cdk-nag (GitHub) de código aberto está integrado ao ADDF. Este utilitário verifica automaticamente os módulos ADDF baseados noAWS CDK para aderir às práticas recomendadas gerais e de segurança. O utilitário cdk-nag usa regras e pacotes de regras para detectar e denunciar códigos que violam as práticas recomendadas. Para obter mais informações sobre as regras e uma lista abrangente, consulte regras cdk-nag (GitHub).

Política personalizada de privilégios mínimos para o perfil de implantação do AWS CDK.

O ADDF faz uso extensivo do AWS CDK v2. É necessário que você faça bootstrap de todas as Contas da AWS para o AWS CDK. Para obter mais informações, consulte Fazer bootstrapping (documentação do AWS CDK).

Por padrão, o AWS CDK atribui a política gerenciada permissiva da AWS AdministratorAccess ao perfil de implantação do AWS CDK criado em contas com bootstrap. O nome completo desse perfil é cdk-[CDK_QUALIFIER]-cfn-exec-role-[AWS_ACCOUNT_ID]-[REGION]. O AWS CDK usa esse perfil para implantar recursos na Conta da AWS com bootstrap como parte do processo de implantação do AWS CDK.

Dependendo dos requisitos de segurança da sua organização, a política AdministratorAccess pode ser muito permissiva. Como parte do processo de bootstrap do AWS CDK, você pode personalizar a política e as permissões de acordo com suas necessidades. Você pode alterar a política ao refazer bootstrap da conta com uma política recém-definida usando o parâmetro --cloudformation-execution-policies. Para obter mais informações, consulte Personalizar bootstrap (documentação do AWS CDK).

nota

Embora esse recurso de segurança não seja específico do ADDF, ele está listado nesta seção porque pode aumentar a segurança geral da sua implantação do ADDF.

Política de privilégios mínimos para o arquivo deployspec do módulo

Cada módulo contém um arquivo de especificações de implantação chamado deployspec.yaml. Esse arquivo define as instruções de implantação do módulo. O CodeSeeder o usa para implantar o módulo definido na conta de destino usando o AWS CodeBuild. O CodeSeeder atribui um perfil de serviço padrão ao CodeBuild para implantar os recursos, conforme instruído no arquivo de especificações de implantação. Esse perfil de serviço foi projetado de acordo com o princípio de privilégios mínimos. Inclui todas as permissões necessárias para aplicações de implantação do AWS CDK, pois todos os módulos fornecidos pelo ADDF são criados como aplicações do AWS CDK.

No entanto, se você precisar executar qualquer comando de estágio fora do AWS CDK, será necessário criar uma política personalizada do IAM em vez de usar o perfil de serviço padrão do CodeBuild. Por exemplo, se você estiver usando uma estrutura de implantação de IaC diferente do AWS CDK, como o Terraform, será necessário criar uma política do IAM que conceda permissões suficientes para que essa estrutura específica funcione. Outro cenário que requer uma política de IAM dedicada é quando você inclui chamadas diretas do AWS Command Line Interface (AWS CLI) para outros Serviços da AWS nos comandos de estágio install, pre_build, build, ou post_build. Por exemplo, você precisará de uma política personalizada se o módulo incluir um comando do Amazon Simple Storage Service (Amazon S3) para fazer upload de arquivos em um bucket do S3. A política personalizada do IAM fornece controle refinado para qualquerAWScomando fora da implantaçao do AWS CDK. Para ver um exemplo de política personalizada do IAM, consulte ModuleStack (documentação do SeedFarmer). Ao criar uma política de IAM personalizada para seu módulo ADDF, certifique-se de aplicar permissões de privilégios mínimos.

Criptografia de dados

O ADDF armazena e processa dados possivelmente confidenciais. Para ajudar a proteger esses dados, os módulos fornecidos pelo SeedFarmer, CodeSeeder e ADDF criptografam os dados em repouso e em trânsito para todos os Serviços da AWS usados (a menos que seja explicitamente declarado o contrário para os módulos na pasta demo-only).

Armazenamento de credenciais usando Secrets Manager

O ADDF lida com vários segredos para diferentes serviços, como Docker Hub, JupyterHub e Amazon Redshift. O ADDF usa AWS Secrets Manager para armazenar quaisquer segredos relacionados ao ADDF. Isso ajuda a remover dados confidenciais do código-fonte.

Os segredos do Secrets Manager são armazenados somente nas contas de destino, conforme necessário para que a conta funcione corretamente. Por padrão, a conta da cadeia de ferramentas não contém segredos.

Revisões de segurança do SeedFarmer e do CodeSeeder

SeedFarmer e CodeSeeder (repositórios do GitHub) são usados para implantar o ADDF e seus módulos ADDF. Esses projetos de código aberto passam pelo mesmo processo de revisão de segurança interna da AWS regular como ADDF, conforme descrito em Processo de revisão de segurança do ADDF.

Suporte de limite de permissões para o perfil do AWS CodeBuild para CodeSeeder

Os limites de permissões do IAM são um mecanismo de segurança comum que define as permissões máximas que uma política baseada em identidade pode conceder a uma entidade do IAM. O SeedFarmer e o CodeSeeder oferecem suporte a um anexo de limite de permissões do IAM para cada conta de destino. O limite de permissões limita o máximo de permissões de qualquer perfil de serviço usado pelo CodeBuild quando o CodeSeeder implanta módulos. Os limites de permissões do IAM devem ser criados fora do ADDF por uma equipe de segurança. Os anexos da política de limite de permissões do IAM são aceitos como um atributo no arquivo de manifesto de implantação do ADDF, deployment.yaml. Para obter mais informações, consulte Suporte ao limite de permissões (documentação do SeedFarmer).

O fluxo de trabalho é o seguinte:

  1. Sua equipe de segurança define e cria um limite de permissões do IAM de acordo com seus requisitos de segurança. O limite de permissões do IAM deve ser criado individualmente em cada Conta da AWS do ADDF. O resultado é uma lista de Amazon Resource Name (ARN) da política de limite de permissões.

  2. A equipe de segurança compartilha a lista de ARN da política com sua equipe de desenvolvedores do ADDF.

  3. A equipe de desenvolvedores do ADDF integra a lista de ARN da política ao arquivo de manifesto. Para obter um exemplo dessa integração, consulte sample-permissionboundary.yaml (GitHub) e manifesto de implantação(documentação do SeedFarmer).

  4. Após a implantação bem-sucedida, o limite de permissões é anexado a todos os perfis de serviço que o CodeBuild usa para implantar módulos.

  5. A equipe de segurança monitora se os limites das permissões são aplicados conforme necessário.

Arquitetura de várias contas da AWS

Conforme definido no pilar de segurança da AWS Well-Architected Framework, a prática recomendada é separar recursos e workloads em várias Contas da AWS, com base nos requisitos da sua organização. Isso ocorre porque uma Conta da AWS atua como um limite de isolamento. Para obter mais informações, consulte gerenciamento e separação da Conta da AWS. A implementação desse conceito é chamada de arquitetura de várias contas. Uma arquitetura de várias contas da AWS projetada corretamente fornece categorização da workload e reduz o escopo do impacto no caso de uma violação de segurança, em comparação com uma arquitetura de conta única.

O ADDF é compatível nativamente com arquiteturas de várias contas da AWS. Você pode distribuir seus módulos do ADDF em tantas Contas da AWS conforme necessário para atender aos requisitos de segurança e separação de funções da sua organização. Você pode implantar o ADDF em uma única Conta da AWS, combinando as funções da cadeia de ferramentas e da conta de destino. Como alternativa, você pode criar contas de destino individuais para módulos ADDF ou grupos de módulos.

A única restrição que você precisa considerar é que um módulo ADDF representa a menor unidade de implantação para cada Conta da AWS.

Para ambientes de produção, é recomendável usar uma arquitetura de várias contas que consista em uma conta da cadeia de ferramentas e pelo menos uma conta de destino. Para obter mais informações, consulte Arquitetura do ADDF.

Permissões com privilégios mínimos para implantações em várias contas

Se você usar uma arquitetura de várias contas, o SeedFarmer precisará acessar as contas de destino para realizar as três ações a seguir:

  1. Grave os metadados do módulo ADDF nas contas da cadeia de ferramentas e nas contas de destino.

  2. Leia os metadados do módulo ADDF atuais da conta da cadeia de ferramentas e das contas de destino.

  3. Inicie os trabalhos do AWS CodeBuild nas contas de destino, com a finalidade de implantar ou atualizar módulos.

A figura a seguir mostra os relacionamentos entre contas, incluindo operações para assumir perfis do AWS Identity and Access Management (IAM) específicos do ADDF.

Perfis do IAM em uma arquitetura multiconta da AWS que tenha uma conta de cadeia de ferramentas e contas de destino.

Essas ações entre contas são alcançadas por meio do uso de operações de assumir perfis bem definidos.

  • O perfil do IAM da cadeia de ferramentas do ADDF é implantada na conta da cadeia de ferramentas. O SeedFarmer assume esse papel. Esse perfil tem permissões para realizar uma ação iam:AssumeRole e pode assumir o perfil do IAM de implantação do ADDF em cada conta de destino. Além disso, o perfil do IAM da cadeia de ferramentas do ADDF pode executar operações do AWS Systems Manager Parameter Store localmente.

  • O perfil do IAM de implantação do ADDF é implantado em cada conta de destino. Esse perfil só pode ser assumido a partir da conta da cadeia de ferramentas usando o perfil do IAM da cadeia de ferramentas do ADDF. Esse perfil tem permissões para executar operações do AWS Systems Manager localmente e tem permissões para executar ações do AWS CodeBuild que iniciam e descrevem trabalhos do CodeBuild por meio do CodeSeeder.

Esses perfis do IAM específicos do ADDF são criados como parte do processo de bootstrapping do ADDF. Para obter mais informações, consulte Bootstrap Conta da AWS(s) no Guia de implantação do ADDF (GitHub).

Todas as permissões entre contas são configuradas de acordo com o princípio de privilégios mínimos. Se uma conta de destino for comprometida, haverá um impacto mínimo ou nenhum impacto nas outras Contas da AWS do ADDF.

No caso de uma arquitetura de conta única para ADDF, os relacionamentos de perfil permanecem os mesmos. Eles simplesmente se transformam em uma única Conta da AWS.