De janeiro a dezembro de 2023 - AWS Control Tower
Transição para o novo tipo de produto External do AWS Service Catalog (fase 3)Versão 3.3 da zona de pouso do AWS Control TowerTransição para o novo tipo de produto External do AWS Service Catalog (fase 2)AWS Control Tower anuncia controles para auxiliar a soberania digitalAWS Control Tower é compatível com APIs da zona de pousoAWS Control Tower permite a marcação de controles habilitadosAWS Control Tower disponível na região Ásia-Pacífico (Melbourne)Transição para o novo tipo de produto External do AWS Service Catalog (fase 1)Nova API de controle disponívelAWS Control Tower adiciona outros controlesNovo tipo de desvio relatado: acesso confiável desabilitadoQuatro Regiões da AWS adicionaisAWS Control Tower disponível na região Tel AvivAWS Control Tower lança 28 novos controles proativosAWS Control Tower desativa dois controlesVersão 3.2 da zona de pouso do AWS Control TowerAWS Control Tower gerencia contas com base em IDControles de detecção adicionais do Security Hub disponíveis na biblioteca de controles do AWS Control TowerAWS Control Tower publica tabelas de metadados de controleSuporte do Terraform para o Account Factory CustomizationAutogerenciamento do Centro de Identidade do AWS IAM disponível para zona de pousoAWS Control Tower aborda a governança mista para UOsControles proativos adicionais disponíveisAtualização de controles proativos do Amazon EC2Sete Regiões da AWS adicionais disponíveis Rastreamento de solicitações de personalização de conta do Account Factory for Terraform (AFT) Versão 3.1 da zona de pouso do AWS Control TowerControles proativos disponíveis ao público

De janeiro a dezembro de 2023

Em 2023, o AWS Control Tower lançou as seguintes atualizações:

Transição para o novo tipo de produto External do AWS Service Catalog (fase 3)

14 de dezembro de 2023

(Não é necessário atualizar a zona de pouso do AWS Control Tower.)

O AWS Control Tower não é mais compatível com o Terraform Open Source como um tipo de produto (esquema) ao criar Contas da AWS. Consulte mais informações e instruções sobre como atualizar os esquemas da conta em Transition to the AWS Service Catalog External product type.

Se não atualizar os esquemas da conta para usar o tipo de produto External, você só poderá atualizar ou encerrar contas que provisionou usando esquemas do Terraform Open Source.

Versão 3.3 da zona de pouso do AWS Control Tower

14 de dezembro de 2023

(É necessário atualizar a zona de pouso do AWS Control Tower para a versão 3.3. Consulte informações em Atualizar a zona de pouso).

Atualizações na política de bucket do S3 na conta de auditoria do AWS Control Tower

Modificamos a política de bucket de auditoria do Amazon S3 que o AWS Control Tower implanta nas contas, de modo que uma condição aws:SourceOrgID deve ser atendida para qualquer permissão de gravação. Com esse lançamento, os serviços da AWS têm acesso aos seus recursos somente quando a solicitação é originada da sua organização ou unidade organizacional (UO).

É possível usar a chave de condição aws:SourceOrgID e definir o valor do ID da organização no elemento de condição da política de bucket do S3. Essa condição garante que o CloudTrail só possa gravar logs em nome de contas dentro da organização no bucket do S3; ela impede que os logs do CloudTrail fora da organização gravem no bucket do S3 do AWS Control Tower.

Fizemos essa alteração para corrigir uma possível vulnerabilidade de segurança, sem afetar a funcionalidade das workloads existentes. Consulte a política atualizada em Política de bucket do Amazon S3 na conta de auditoria.

Consulte mais informações sobre a nova chave de condição na documentação do IAM e na publicação do blog do IAM intitulada “Use scalable controls for AWS services accessing your resources”.

Atualizações da política no tópico do SNS do AWS Config

Adicionamos a nova chave de condição aws:SourceOrgID à política do tópico do SNS do AWS Config. Consulte a política atualizada, em The AWS Config SNS topic policy.

Atualizações no controle de negação de região da zona de pouso

  • discovery-marketplace: removido. Essa ação é coberta pela isenção aws-marketplace:*.

  • quicksight:DescribeAccountSubscription adicionado

Atualizar um modelo do AWS CloudFormation

Atualizamos o modelo do AWS CloudFormation da pilha chamada BASELINE-CLOUDTRAIL-MASTER para que ela não mostre desvio quando a criptografia do AWS KMS não for usada.

Transição para o novo tipo de produto External do AWS Service Catalog (fase 2)

7 de dezembro de 2023

(Não é necessário atualizar a zona de pouso do AWS Control Tower.)

HashiCorp atualizou o licenciamento do Terraform. Como resultado, o AWS Service Catalog alterou o suporte para produtos do Terraform Open Source e provisionou produtos para um novo tipo de produto, chamado External.

Para evitar interrupções nas workloads e nos recursos da AWS existentes em suas contas, siga as etapas de transição do AWS Control Tower em Transition to the AWS Service Catalog External product type até 14 de dezembro de 2023.

AWS Control Tower anuncia controles para auxiliar a soberania digital

27 de novembro de 2023

(Não é necessário atualizar a zona de pouso do AWS Control Tower.)

O AWS Control Tower anuncia 65 novos controles gerenciados pela AWS para ajudar a atender aos seus requisitos de soberania digital. Com esse lançamento, é possível descobrir esses controles sob um novo grupo de soberania digital no console do AWS Control Tower. É possível usar esses controles para ajudar a evitar ações e detectar alterações de recursos em relação à residência de dados, restrição de acesso granular, criptografia e recursos de resiliência. Esses controles foram projetados para simplificar o atendimento dos requisitos em grande escala. Consulte mais informações sobre controles de soberania digital em Controls that enhance digital sovereignty protection.

Por exemplo, você pode optar por habilitar controles que ajudem a aplicar suas estratégias de criptografia e resiliência, como Exigir um cache da API do AWS AppSync para ter a criptografia em trânsito habilitada ou Exigir que um AWS Network Firewall seja implantado em várias zonas de disponibilidade. Você também pode personalizar o controle de negação de região do AWS Control Tower para aplicar restrições regionais que melhor atendam às suas necessidades comerciais exclusivas.

Esse lançamento traz recursos bem aprimorados de negação de região do AWS Control Tower. É possível aplicar um novo controle de negação de região parametrizado no nível da UO, para aumentar a granularidade da governança e, ao mesmo tempo, manter a governança adicional da região no nível da zona de pouso. Esse controle de negação de região personalizável ajuda você a aplicar restrições regionais que melhor atendam às suas necessidades comerciais exclusivas. Consulte mais informações sobre o novo controle de negação de região configurável em Region deny control applied to the OU.

Como uma nova ferramenta para o novo aprimoramento de negação de região, esse lançamento inclui uma nova API UpdateEnabledControl, que permite redefinir os controles habilitados para as configurações padrão. Essa API é especialmente útil em casos de uso em que você precisa resolver o desvio rapidamente ou para garantir de forma programática que um controle não esteja em um estado de desvio. Consulte mais informações sobre a nova API na Referência de API do AWS Control Tower.

Novos controles proativos

  • CT.APIGATEWAY.PR.6: exija um domínio REST do Amazon API Gateway para usar uma política de segurança que especifique uma versão mínima do protocolo TLS do TLSv1.2

  • CT.APPSYNC.PR.2: exija que uma API do AWS AppSync GraphQL seja configurada com visibilidade privada.

  • CT.APPSYNC.PR.3: exija que uma API do AWS AppSync GraphQL não seja autenticada com chaves de API.

  • CT.APPSYNC.PR.4: exija um cache da API do AWS AppSync GraphQL para ter a criptografia em trânsito ativada.

  • CT.APPSYNC.PR.5: exija um cache da API do AWS AppSync GraphQL para ter a criptografia em trânsito habilitada.

  • CT.AUTOSCALING.PR.9: exija um volume do Amazon EBS configurado por meio de uma configuração de lançamento do Amazon EC2 Auto Scaling para criptografar dados em repouso.

  • CT.AUTOSCALING.PR.10: exija que um grupo do Amazon EC2 Auto Scaling use somente tipos de instância AWS Nitro ao substituir um modelo de execução.

  • CT.AUTOSCALING.PR.11: exija que somente os tipos de instância AWS Nitro que permitem criptografia de tráfego de rede entre instâncias sejam adicionados a um grupo do Amazon EC2 Auto Scaling, ao substituir um modelo de execução.

  • CT.DAX.PR.3: exija um cluster do DynamoDB Accelerator para criptografar dados em trânsito com o Transport Layer Security (TLS).

  • CT.DMS.PR.2: exija um endpoint do AWS Database Migration Service (DMS) para criptografar conexões para endpoints de origem e destino.

  • CT.EC2.PR.15: exija que uma instância do Amazon EC2 use um tipo de instância do AWS Nitro ao criar do tipo de recurso AWS::EC2::LaunchTemplate.

  • CT.EC2.PR.16: exija que uma instância do Amazon EC2 use um tipo de instância do AWS Nitro quando criada usando o tipo de recurso AWS::EC2::Instance.

  • CT.EC2.PR.17: exija um host dedicado do Amazon EC2 para usar um tipo de instância do AWS Nitro.

  • CT.EC2.PR.18: exija que uma frota do Amazon EC2 substitua somente os modelos de execução com os tipos de instância do AWS Nitro.

  • CT.EC2.PR.19: exija que uma instância do Amazon EC2 use um tipo de instância do Nitro que seja compatível com a criptografia em trânsito entre instâncias quando criada usando o tipo de recurso AWS::EC2::Instance.

  • CT.EC2.PR.20: exija que uma frota do Amazon EC2 substitua somente os modelos de execução por tipos de instância do AWS Nitro que sejam compatíveis com a criptografia em trânsito entre instâncias.

  • CT.ELASTICACHE.PR.8: exija que um grupo de replicação do Amazon ElastiCache de versões posteriores do Redis tenha a autenticação RBAC ativada.

  • CT.MQ.PR.1: exija que um agente do Amazon MQ ActiveMQ use o modo de implantação ativo/em espera para alta disponibilidade.

  • CT.MQ.PR.2: exija que um agente do Amazon MQ Rabbit MQ use o modo de cluster multi-AZ para alta disponibilidade.

  • CT.MSK.PR.1: exija um cluster do Amazon Managed Streaming for Apache Kafka (MSK) para aplicar a criptografia em trânsito entre os nós do agente de cluster.

  • CT.MSK.PR.2: exija que um cluster do Amazon Managed Streaming for Apache Kafka (MSK) seja configurado com PublicAccess desabilitado.

  • CT.NETWORK-FIREWALL.PR.5: exija que um firewall do AWS Network Firewall seja implantado em várias zonas de disponibilidade.

  • CT.RDS.PR.26: exija um proxy de banco de dados do Amazon RDS para requerer conexões de Transport Layer Security (TLS).

  • CT.RDS.PR.27: exija um grupo de parâmetros de cluster de banco de dados do Amazon RDS para requerer conexões de Transport Layer Security (TLS) para tipos de mecanismos compatíveis.

  • CT.RDS.PR.28: exija um grupo de parâmetros de banco de dados do Amazon RDS para requerer conexões de Transport Layer Security (TLS) para tipos de mecanismos compatíveis.

  • CT.RDS.PR.29: exija que um cluster do Amazon RDS não esteja configurado para ser acessível publicamente por meio da propriedade “PubliclyAccessible”

  • CT.RDS.PR.30: exija que uma instância de banco de dados do Amazon RDS tenha a criptografia em repouso configurada para usar uma chave do KMS que você especifique para os tipos de mecanismos compatíveis.

  • CT.S3.PR.12: exija que um ponto de acesso Amazon S3 tenha uma configuração de Bloqueio de Acesso Público (BPA) com todas as opções definidas como verdadeiras.

Novos controles preventivos

  • CT.APPSYNC.PV.1: exija que uma API do AWS AppSync GraphQL seja configurada com visibilidade privada.

  • CT.EC2.PV.1: exija que um snapshot do Amazon EBS seja criado com base em um volume do EC2 criptografado.

  • CT.EC2.PV.2: exija que um volume anexado do Amazon EBS esteja configurado para criptografar dados em repouso.

  • CT.EC2.PV.3: exija que um snapshot do Amazon EBS não possa ser restaurado publicamente.

  • CT.EC2.PV.4: exija que APIs diretas do Amazon EBS não sejam chamadas.

  • CT.EC2.PV.5: proíba o uso da importação e exportação de VMs do Amazon EC2.

  • CT.EC2.PV.6: proíba o uso das ações de API RequestSpotFleet e RequestSpotInstances obsoletas do Amazon EC2

  • CT.KMS.PV.1: exija que uma política de chave do AWS KMS tenha uma instrução que limite a criação de concessões AWS KMS a serviços da AWS.

  • CT.KMS.PV.2: exija que uma chave assimétrica do AWS KMS com material de chave RSA usado para criptografia não tenha um comprimento de chave de 2.048 bits.

  • CT.KMS.PV.3: exija que uma chave do AWS KMS seja configurada com a verificação de segurança de bloqueio de política de desvio habilitada.

  • CT.KMS.PV.4: exija que uma chave gerenciada pelo cliente (CMK) do AWS KMS seja configurada com material de chave proveniente do AWS CloudHSM.

  • CT.KMS.PV.5: exija que uma chave gerenciada pelo cliente (CMK) do AWS KMS seja configurada com material de chave importado.

  • CT.KMS.PV.6: exija que uma chave gerenciada pelo cliente (CMK) do AWS KMS seja configurada com material de chave proveniente de um repositório de chaves externo (XKS).

  • CT.LAMBDA.PV.1: exija um URL da função do AWS Lambda para usar a autenticação baseada no AWS IAM.

  • CT.LAMBDA.PV.2: exija que um URL da função do AWS Lambda seja configurado para acesso somente por entidades principais em sua Conta da AWS.

  • CT.MULTISERVICE.PV.1: negue acesso à AWS com base na Região da AWSsolicitada para uma unidade organizacional.

Os novos controles de detecção que aprimoram seu procedimento de governança de soberania digital fazem parte do AWS Control Tower do padrão gerenciado por serviços do AWS Security Hub.

Novos controles de detecção

  • SH.ACM.2: os certificados RSA gerenciados pelo ACM devem usar um comprimento de chave de pelo menos 2.048 bits

  • SH.AppSync.5: as APIs do AWS AppSync GraphQL não devem ser autenticadas com chaves de API.

  • SH.CloudTrail.6: assegure que o bucket do S3 usado para armazenar logs do CloudTrail não seja acessível publicamente.

  • SH.DMS.9: os endpoints do DMS devem usar SSL.

  • SH.DocumentDB.3: os snapshots manuais do cluster do Amazon DocumentDB não devem ser públicos.

  • SH.DynamoDB.3: os clusters do DynamoDB Accelerator (DAX) devem ser criptografados em repouso.

  • SH.EC2.23: os EC2 Transit Gateways não devem aceitar automaticamente solicitações de anexos de VPC.

  • SH.EKS.1: os endpoints do cluster do EKS não devem ser acessíveis ao público.

  • SH.ElastiCache.3: os grupos de replicação do ElastiCache devem ter o failover automático habilitado.

  • SH.ElastiCache.4: os grupos de replicação do ElastiCache devem ter a criptografia em repouso habilitada.

  • SH.ElastiCache.5: os grupos de replicação do ElastiCache devem ter a criptografia em trânsito habilitada.

  • SH.ElastiCache.6: os grupos de replicação do ElastiCache de versões anteriores do Redis devem ter o Redis AUTH habilitado.

  • SH.EventBridge.3: os barramentos de eventos personalizados do EventBridge devem ter uma política baseada em recursos anexada.

  • SH.KMS.4: a alternância de chaves do AWS KMS deve ser habilitada.

  • SH.Lambda.3: as funções do Lambda devem estar em uma VPC.

  • SH.MQ.5: os agentes do ActiveMQ devem usar o modo de implantação ativo/em espera.

  • SH.MQ.6: os agentes do RabbitMQ devem usar o modo de implantação de cluster.

  • SH.MSK.1: os clusters do MSK devem ser criptografados em trânsito entre os nós do agente.

  • SH.RDS.12: a autenticação do IAM deve ser configurada para clusters do RDS.

  • SH.RDS.15: os clusters de banco de dados do RDS devem ser configurados com várias zonas de disponibilidade.

  • SH.S3.17: os buckets do S3 devem ser criptografados em repouso com chaves do AWS KMS.

Consulte mais informações sobre controles adicionados ao AWS Control Tower do padrão gerenciado por serviço do AWS Security Hub em Controls that apply to Service-Managed Standard: AWS Control Tower na documentação do AWS Security Hub.

Consulte uma lista de Regiões da AWS que não são compatíveis com determinados controles que fazem parte do AWS Control Tower do padrão gerenciado por serviços do AWS Security Hub em Unsupported Regions.

Novo controle configurável de negação de região no nível da UO

CT.MULTISERVICE.PV.1: esse controle aceita parâmetros para especificar regiões isentas, entidades principais do IAM e ações que são permitidas, no nível da UO, em vez de para toda a zona de pouso do AWS Control Tower. É um controle preventivo, implementado pela política de controle de serviços (SCP).

Consulte mais informações em Region deny control applied to the OU.

A API do UpdateEnabledControl

Esse lançamento do AWS Control Tower adiciona o seguinte suporte de API para controles:

  • A API EnableControl atualizada pode configurar controles que são configuráveis.

  • A API GetEnabledControl atualizada mostra os parâmetros configurados em um controle habilitado.

  • A nova API UpdateEnabledControl pode alterar os parâmetros em um controle habilitado.

Consulte mais informações na Referência de API do AWS Control Tower.

AWS Control Tower é compatível com APIs da zona de pouso

26 de novembro de 2023

(Não é necessário atualizar a zona de pouso do AWS Control Tower.)

O AWS Control Tower agora permite a configuração e a execução da zona de pouso usando APIs. É possível criar, atualizar, obter, listar, redefinir e excluir zonas de pouso usando APIs.

As APIs a seguir permitem que você configure e gerencie a zona de pouso programaticamente usando o AWS CloudFormation ou a AWS CLI.

AWS Control Tower é compatível com as seguintes APIs da zona de pouso:

  • CreateLandingZone: essa chamada de API cria uma zona de pouso usando uma versão da zona de pouso e um arquivo de manifesto.

  • GetLandingZoneOperation: essa chamada de API retorna o status de uma operação de zona de pouso especificada.

  • GetLandingZone: essa chamada de API retorna detalhes sobre a zona de pouso especificada, incluindo a versão, o arquivo de manifesto e o status.

  • UpdateLandingZone: essa chamada de API atualiza a versão da zona de pouso ou o arquivo de manifesto.

  • ListLandingZone: essa chamada de API retorna um identificador da zona de pouso (ARN) para uma configuração da zona de pouso na conta de gerenciamento.

  • ResetLandingZone: essa chamada de API redefine a zona de pouso para os parâmetros especificados na atualização mais recente, o que pode reparar o desvio. Se a zona de pouso não tiver sido atualizada, essa chamada a redefinirá para os parâmetros especificados na criação.

  • DeleteLandingZone: essa chamada de API desativa a zona de pouso.

Para começar a usar as APIs da zona de pouso, consulte Começar a usar o AWS Control Tower com APIs.

AWS Control Tower permite a marcação de controles habilitados

10 de novembro de 2023

(Não é necessário atualizar a zona de pouso do AWS Control Tower.)

O AWS Control Tower agora permite a marcação de recursos para controles habilitados, pelo console do AWS Control Tower ou por meio de APIs. É possível adicionar, remover ou listar tags para controles habilitados.

Com o lançamento das APIs a seguir, é possível configurar tags para os controles que você habilita no AWS Control Tower. As tags ajudam a gerenciar, identificar, organizar, pesquisar e filtrar recursos. Você pode criar tags para categorizar recursos por finalidade, proprietário, ambiente ou outros critérios.

O AWS Control Tower é compatível com as seguintes APIs para o controle de marcação com tags:

  • TagResource: essa chamada de API adiciona tags aos controles habilitados no AWS Control Tower.

  • UntagResource: essa chamada de API remove as tags dos controles habilitados no AWS Control Tower.

  • ListTagsForResource: essa chamada de API retorna tags para controles habilitados no AWS Control Tower.

As APIs de controle do AWS Control Tower estão disponíveis em Regiões da AWS onde o AWS Control Tower está disponível. Consulte uma lista completa de Regiões da AWS em que o AWS Control Tower está disponível na Tabela de regiões da AWS. Consulte uma lista completa das APIs do AWS Control Tower na Referência de API.

AWS Control Tower disponível na região Ásia-Pacífico (Melbourne)

3 de novembro de 2023

(Não é necessário atualizar a zona de pouso do AWS Control Tower.)

O AWS Control Tower está disponível na região Ásia-Pacífico (Melbourne).

Se você já usa o AWS Control Tower e deseja estender seus recursos de governança para essa região em suas contas, acesse a página Configurações no painel do AWS Control Tower, selecione a região e atualize a zona de pouso. Depois de atualizar a zona de pouso, você deve atualizar todas as contas que são administradas pelo AWS Control Tower para colocar suas contas e UOs sob governança na nova região. Consulte mais informações em About Updates.

Consulte uma lista de regiões nas quais o AWS Control Tower está disponível na Tabela de Região da AWS.

Transição para o novo tipo de produto External do AWS Service Catalog (fase 1)

31 de outubro de 2023

(Não é necessário atualizar a zona de pouso do AWS Control Tower.)

HashiCorp atualizou o licenciamento do Terraform. Como resultado, o AWS Service Catalog atualizou o suporte para produtos do Terraform Open Source e provisionou produtos para um novo tipo de produto, chamado External.

O AWS Control Tower não permite personalizações do Account Factory que dependem do tipo de produto External do AWS Service Catalog. Para evitar interromper as workloads e os recursos da AWS existentes em sua conta, siga as etapas de transição do AWS Control Tower na ordem sugerida até 14 de dezembro de 2023.

  1. Atualize o Terraform Reference Engine existente para que o AWS Service Catalog inclua suporte aos tipos de produto External e Terraform Open Source. Consulte instruções sobre como atualizar o Terraform Reference Engine em AWS Service Catalog GitHub Repository.

  2. Acesse o AWS Service Catalog e duplique os esquemas existentes do Terraform Open Source para usar o novo tipo de produto External. Não encerre os esquemas existentes do Terraform Open Source.

  3. Continue usando os esquemas existentes do Terraform Open Source para criar ou atualizar contas no AWS Control Tower.

Nova API de controle disponível

14 de outubro de 2023

(Não é necessário atualizar a zona de pouso do AWS Control Tower.)

O AWS Control Tower agora é compatível com uma API adicional que você pode usar para implantar e gerenciar controles do AWS Control Tower em grande escala. Consulte mais informações sobre as APIs de controle do AWS Control Tower na Referência de API.

O AWS Control Tower adicionou uma nova API de controle.

  • GetEnabledControl: a chamada de API fornece detalhes sobre um controle habilitado.

Também atualizamos esta API:

ListEnabledControls: essa chamada de API lista os controles habilitados pelo AWS Control Tower na unidade organizacional especificada e as contas que ela contém. Agora, ela retorna informações adicionais em um objeto EnabledControlSummary.

Com essas APIs, é possível realizar várias operações comuns de forma programática. Por exemplo:

  • Consulte uma lista de todos os controles que você habilitou na biblioteca de controles do AWS Control Tower.

  • Para qualquer controle habilitado, é possível ter informações sobre as regiões compatíveis com o controle, além do identificador (ARN), do status de desvio e do resumo do status do controle.

As APIs de controle do AWS Control Tower estão disponíveis em Regiões da AWS onde o AWS Control Tower está disponível. Consulte uma lista completa de Regiões da AWS em que o AWS Control Tower está disponível na Tabela de regiões da AWS. Consulte uma lista completa das APIs do AWS Control Tower na Referência de API.

AWS Control Tower adiciona outros controles

5 de outubro de 2023

(Não é necessário atualizar a zona de pouso do AWS Control Tower.)

O AWS Control Tower anuncia novos controles proativos e de detecção.

Os controles proativos no AWS Control Tower são implementados por meio de hooks do AWS CloudFormation, que identificam e bloqueiam recursos não compatíveis antes que o AWS CloudFormation os provisione. Os controles proativos complementam os recursos existentes de controle preventivo e de detecção no AWS Control Tower.

Novos controles proativos

  • [CT.ATHENA.PR.1]: exija que um grupo de trabalho do Amazon Athena criptografe os resultados da consulta do Athena em repouso.

  • [CT.ATHENA.PR.2]: exija que um grupo de trabalho do Amazon Athena criptografe os resultados da consulta do Athena com uma chave do AWS Key Management Service (KMS).

  • [CT.CLOUDTRAIL.PR.4]: exija um armazenamento de dados de eventos do AWS CloudTrail Lake para habilitar a criptografia em repouso com uma chave do AWS KMS.

  • [CT.DAX.PR.2]: exija um cluster Amazon DAX para implantar nós em pelo menos três zonas de disponibilidade.

  • [CT.EC2.PR.14]: exija um volume do Amazon EBS configurado por meio de um modelo de execução do Amazon EC2 para criptografar dados em repouso.

  • [CT.EKS.PR.2]: exija que um cluster Amazon EKS seja configurado com criptografia secreta usando chaves do AWS Key Management Service (KMS).

  • [CT.ELASTICLOADBALANCING.PR.14]: exija que um Network Load Balancer tenha o balanceamento de carga entre zonas ativado.

  • [CT.ELASTICLOADBALANCING.PR.15]: exija que um grupo de destino do Elastic Load Balancing v2 não desabilite explicitamente o balanceamento de carga entre zonas.

  • [CT.EMR.PR.1]: exija que uma configuração de segurança do Amazon EMR (EMR) esteja configurada para criptografar dados em repouso no Amazon S3.

  • [CT.EMR.PR.2]: exija que uma configuração de segurança do Amazon EMR (EMR) esteja configurada para criptografar dados em repouso no Amazon S3 com uma chave do AWS KMS.

  • [CT.EMR.PR.3]: exija que uma configuração de segurança do Amazon EMR (EMR) seja configurada com a criptografia de disco local de volume do EBS usando uma chave do AWS KMS.

  • [CT.EMR.PR.4]: exija que uma configuração de segurança do Amazon EMR (EMR) esteja configurada para criptografar dados em trânsito.

  • [CT.GLUE.PR.1]: exija que um trabalho do AWS Glue tenha uma configuração de segurança associada.

  • [CT.GLUE.PR.2]: exija uma configuração de segurança do AWS Glue para criptografar dados em destinos do Amazon S3 usando chaves do AWS KMS.

  • [CT.KMS.PR.2]: exija que uma chave assimétrica do AWS KMS com material de chave RSA usado para criptografia tenha um comprimento de chave maior que 2.048 bits.

  • [CT.KMS.PR.3]: exija que uma política de chave do AWS KMS tenha uma instrução que limite a criação de concessões AWS KMS a serviços da AWS.

  • [CT.LAMBDA.PR.4]: exija uma permissão de camada do AWS Lambda para conceder acesso a uma organização da AWS ou a uma conta da AWS específica.

  • [CT.LAMBDA.PR.5]: exija um URL da função do AWS Lambda para usar a autenticação baseada no AWS IAM.

  • [CT.LAMBDA.PR.6]: exija uma política de CORS do URL da função do AWS Lambda função para restringir o acesso a origens específicas.

  • [CT.NEPTUNE.PR.4]: exija um cluster de banco de dados do Amazon Neptune para permitir a exportação de logs do Amazon CloudWatch para logs de auditoria.

  • [CT.NEPTUNE.PR.5]: exija um cluster de banco de dados do Amazon Neptune para definir um período de retenção de backup maior ou igual a sete dias.

  • [CT.REDSHIFT.PR.9]: exija que um grupo de parâmetros de cluster do Amazon Redshift esteja configurado para usar o Secure Sockets Layer (SSL) para criptografia de dados em trânsito.

Esses novos controles proativos estão disponíveis em Regiões da AWS comerciais onde o AWS Control Tower está disponível. Consulte mais detalhes sobre esses controles em Proactive controls. Consulte mais detalhes sobre onde os controles estão disponíveis em Control limitations.

Novos controles de detecção

Novos controles foram adicionados ao padrão gerenciado por serviços do Security Hub: AWS Control Tower. Esses controles ajudam a aprimorar o procedimento de governança. Eles agem como parte do padrão gerenciado por serviços do Security Hub: AWS Control Tower, depois que você os habilita em qualquer UO específica.

  • [SH.Athena.1]: os grupos de trabalho do Athena devem ser criptografados em repouso.

  • [SH.Neptune.1]: os clusters de banco de dados Neptune devem ser criptografados em repouso.

  • [SH.Neptune.2]: os clusters do banco de dados do Neptune devem publicar logs de auditoria no CloudWatch Logs.

  • [SH.Neptune.3]: os snapshots do cluster de banco de dados do Neptune não devem ser públicos.

  • [SH.Neptune.4]: o cluster de banco de dados do Neptune deve ter a proteção contra exclusão habilitada.

  • [SH.Neptune.5]: os clusters de banco de dados do Neptune devem ter backups automatizados habilitados.

  • [SH.Neptune.6]: os snapshots do cluster de banco de dados do Neptune devem ser criptografados em repouso.

  • [SH.Neptune.7]: os clusters de banco de dados do Neptune devem ter a autenticação de banco de dados do IAM habilitada.

  • [SH.Neptune.8]: os clusters de banco de dados do Neptune devem ser configurados para copiar tags para snapshots.

  • [SH.RDS.27]: os clusters de banco de dados do RDS devem ser criptografados em repouso.

Os novos controles de detecção do AWS Security Hub estão disponíveis na maioria das Regiões da AWS onde o AWS Control Tower está disponível. Consulte mais detalhes sobre esses controles em Controls that apply to Service-Managed Standard: AWS Control Tower. Consulte mais detalhes sobre onde os controles estão disponíveis em Limitações de controle.

Novo tipo de desvio relatado: acesso confiável desabilitado

21 de setembro de 2023

(Não é necessário atualizar a zona de pouso do AWS Control Tower.)

Depois de configurar a zona de pouso do AWS Control Tower, é possível desabilitar o acesso confiável ao AWS Control Tower no AWS Organizations. No entanto, isso causa um desvio.

Com o tipo de desvio de acesso confiável desabilitado, o AWS Control Tower notifica você quando esse tipo de desvio ocorre, para que seja possível reparar a zona de pouso do AWS Control Tower. Consulte mais informações em Types of governance drift.

Quatro Regiões da AWS adicionais

13 de setembro de 2023

(Não é necessário atualizar a zona de pouso do AWS Control Tower.)

O AWS Control Tower já está disponível nas regiões Ásia-Pacífico (Hyderabad), Europa (Espanha e Zurique) e Oriente Médio (EAU).

Se você já usa o AWS Control Tower e deseja estender seus recursos de governança para essa região em suas contas, acesse a página Configurações no painel do AWS Control Tower, selecione a região e atualize a zona de pouso. Depois de atualizar a zona de pouso, você deve atualizar todas as contas que são administradas pelo AWS Control Tower para colocar suas contas e UOs sob governança na nova região. Consulte mais informações em About Updates.

Consulte uma lista de regiões nas quais o AWS Control Tower está disponível na Tabela de Região da AWS.

AWS Control Tower disponível na região Tel Aviv

28 de agosto de 2023

(Não é necessário atualizar a zona de pouso do AWS Control Tower.)

O AWS Control Tower anuncia disponibilidade na região Israel (Tel Aviv).

Se você já usa o AWS Control Tower e deseja estender seus recursos de governança para essa região em suas contas, acesse a página Configurações no painel do AWS Control Tower, selecione a região e atualize a zona de pouso. Depois de atualizar a zona de pouso, você deve atualizar todas as contas que são administradas pelo AWS Control Tower para colocar suas contas e UOs sob governança na nova região. Consulte mais informações em About Updates.

Consulte uma lista de regiões nas quais o AWS Control Tower está disponível na Tabela de Região da AWS.

AWS Control Tower lança 28 novos controles proativos

24 de julho de 2023

(Não é necessário atualizar a zona de pouso do AWS Control Tower.)

O AWS Control Tower está adicionando 28 novos controles proativos para ajudar a gerenciar o ambiente da AWS.

Os controles proativos aprimoram os recursos de governança do AWS Control Tower nos ambientes de várias contas da AWS, bloqueando recursos não compatíveis antes de serem provisionados. Esses controles ajudam a gerenciar serviços da AWS como Amazon CloudWatch, Amazon Neptune, Amazon ElastiCache, AWS Step Functions e Amazon DocumentDB. Os novos controles ajudam você a atingir objetivos de controle, como estabelecer registros e monitoramento, criptografar dados em repouso ou melhorar a resiliência.

Aqui está uma lista completa dos novos controles:

  • [CT.APPSYNC.PR.1]: exija que uma API do AWS AppSync GraphQL tenha o registro em log habilitado.

  • [CT.CLOUDWATCH.PR.1]: exija que um alarme do Amazon CloudWatch tenha uma ação configurada para o estado do alarme.

  • [CT.CLOUDWATCH.PR.2]: exija que um grupo de logs do Amazon CloudWatch seja retido por pelo menos um ano.

  • [CT.CLOUDWATCH.PR.3]: exija que um grupo de logs do Amazon CloudWatch seja criptografado em repouso com uma chave do AWS KMS.

  • [CT.CLOUDWATCH.PR.4]: exija que uma ação de alarme do Amazon CloudWatch seja ativada.

  • [CT.DOCUMENTDB.PR.1]: exija que um cluster Amazon DocumentDB seja criptografado em repouso.

  • [CT.DOCUMENTDB.PR.2]: exija que um cluster do Amazon DocumentDB tenha backups automáticos habilitados.

  • [CT.DYNAMODB.PR.2]: exija que uma tabela do Amazon DynamoDB seja criptografada em repouso usando chaves do AWS KMS.

  • [CT.EC2.PR.13]: exija que uma instância do Amazon EC2 tenha o monitoramento detalhado habilitado.

  • [CT.EKS.PR.1]: exija que um cluster do Amazon EKS seja configurado com o acesso público desabilitado ao endpoint do servidor da API do Kubernetes do cluster.

  • [CT.ELASTICACHE.PR.1]: exija que um cluster do Amazon ElastiCache para Redis tenha backups automáticos ativados.

  • [CT.ELASTICACHE.PR.2]: exija que um cluster do Amazon ElastiCache para Redis tenha as atualizações automáticas de versões secundárias ativadas.

  • [CT.ELASTICACHE.PR.3]: exija que um grupo de replicação do Amazon ElastiCache para Redis tenha o failover automático ativado.

  • [CT.ELASTICACHE.PR.4]: exija que um grupo de replicação do Amazon ElastiCache tenha a criptografia em repouso ativada.

  • [CT.ELASTICACHE.PR.5]: exija que um grupo de replicação do Amazon ElastiCache para Redis tenha a criptografia em trânsito ativada.

  • [CT.ELASTICACHE.PR.6]: exija um cluster de cache do Amazon ElastiCache para usar um grupo de sub-rede personalizado.

  • [CT.ELASTICACHE.PR.7]: exija que um grupo de replicação do Amazon ElastiCache de versões anteriores do Redis tenha a autenticação AUTH do Redis.

  • [CT.ELASTICBEANSTALK.PR.3]: exija que um ambiente do AWS Elastic Beanstalk tenha uma configuração de registro em log.

  • [CT.LAMBDA.PR.3]: exija que uma função do AWS Lambda esteja em uma Amazon Virtual Private Cloud (VPC) gerenciada pelo cliente.

  • [CT.NEPTUNE.PR.1]: exija que um cluster de banco de dados do Amazon Neptune tenha a autenticação de banco de dados do AWS Identity and Access Management (IAM).

  • [CT.NEPTUNE.PR.2]: exija que um cluster de banco de dados do Amazon Neptune tenha a proteção contra exclusão habilitada.

  • [CT.NEPTUNE.PR.3]: exija que um cluster de banco de dados do Amazon Neptune tenha a criptografia de armazenamento habilitada.

  • [CT.REDSHIFT.PR.8]: exija que um cluster do Amazon Redshift seja criptografado.

  • [CT.S3.PR.9]: exija que um bucket do Amazon S3 tenha o Bloqueio de Objetos do S3 ativado.

  • [CT.S3.PR.10]: exija que um bucket do Amazon S3 tenha a criptografia do lado do servidor configurada usando chaves do AWS KMS.

  • [CT.S3.PR.11]: exija que um bucket do Amazon S3 tenha o versionamento habilitado.

  • [CT.STEPFUNCTIONS.PR.1]: exija que uma máquina de estado do AWS Step Functions tenha o registro em log ativado.

  • [CT.STEPFUNCTIONS.PR.2]: exija que uma máquina de estado do AWS Step Functions tenha o rastreamento AWS X-Ray ativado.

Os controles proativos no AWS Control Tower são implementados por meio de hooks do AWS CloudFormation, que identificam e bloqueiam recursos não compatíveis antes que o AWS CloudFormation os provisione. Os controles proativos complementam os recursos existentes de controle preventivo e de detecção no AWS Control Tower.

Esses novos controles proativos estão disponíveis em todas as Regiões da AWS onde o AWS Control Tower está disponível. Consulte mais detalhes sobre esses controles em Proactive controls.

AWS Control Tower desativa dois controles

18 de julho de 2023

(Não é necessário atualizar a zona de pouso do AWS Control Tower.)

O AWS Control Tower conduz análises regulares de seus controles de segurança para garantir que eles estejam atualizados e continuem sendo considerados como práticas recomendadas. Os dois controles a seguir foram desativados, a partir de 18 de julho de 2023, e serão removidos da biblioteca de controles a partir de 18 de agosto de 2023. Não é mais possível habilitar esses controles em nenhuma unidade organizacional. Você pode optar por desativar esses controles antes da data de remoção.

  • [SH.S3.4]: os buckets do S3 devem ter a criptografia no lado do servidor habilitada.

  • [CT.S3.PR.7]: exija que um bucket do Amazon S3 tenha a criptografia do lado do servidor configurada.

Motivo da desativação

Desde janeiro de 2023, o Amazon S3 configurou a criptografia padrão em todos os buckets não criptografados novos e existentes para aplicar a criptografia do lado do servidor com chaves gerenciadas do S3 (SSE-S3) como o nível básico de criptografia para novos objetos carregados nesses buckets. Nenhuma alteração foi feita na configuração de criptografia padrão para um bucket existente que já tenha a criptografia SSE-S3 ou do lado do servidor com chaves do AWS Key Management Service (AWS KMS) (SSE-KMS) configuradas.

Versão 3.2 da zona de pouso do AWS Control Tower

16 de junho de 2023

(É necessário atualizar a zona de pouso do AWS Control Tower para a versão 3.2. Consulte informações em Atualizar a zona de pouso).

A versão 3.2 da zona de pouso do AWS Control Tower traz os controles que fazem parte do padrão gerenciado por serviços do AWS Security Hub: AWS Control Tower para disponibilidade geral. Ele introduz a capacidade de visualizar o status de desvio dos controles que fazem parte desse padrão no console do AWS Control Tower.

Essa atualização inclui um novo perfil vinculado ao serviço (SLR), chamado AWSServiceRoleForAWSControlTower. Esse perfil auxilia o AWS Control Tower criando uma regra gerenciada do EventBridge, chamada AWSControlTowerManagedRule em cada conta-membro. Essa regra gerenciada coleta eventos de Descoberta do AWS Security Hub, com os quais o AWS Control Tower pode determinar o desvio do controle.

Essa regra é a primeira regra gerenciada a ser criada pelo AWS Control Tower. A regra não é implantada por uma pilha; ela é implantada diretamente pelas APIs do EventBridge. É possível visualizar a regra no console do EventBridge ou por meio das APIs do EventBridge. Se o campo managed-by for preenchido, ele mostrará a entidade principal do serviço AWS Control Tower.

Anteriormente, o AWS Control Tower assumiu o perfil AWSControlTowerExecution para realizar operações nas contas-membros. Esse novo perfil e regra estão melhor alinhados com o princípio das práticas recomendadas de permitir o privilégio mínimo ao realizar operações em um ambiente de várias contas da AWS. O novo perfil fornece permissões de escopo reduzido que permitem especificamente: criar a regra gerenciada nas contas-membros, manter a regra gerenciada, publicar notificações de segurança por meio do SNS e verificar o desvio. Consulte mais informações em AWSServiceRoleForAWSControlTower.

A atualização da zona de pouso 3.2 também inclui um novo recurso de StackSet na conta de gerenciamento, BP_BASELINE_SERVICE_LINKED_ROLE, que inicialmente implanta o perfil vinculado ao serviço.

Ao relatar o desvio do controle do Security Hub (na zona de pouso 3.2 e posterior), o AWS Control Tower recebe uma atualização de status diária do Security Hub. Embora os controles estejam ativos em todas as regiões administradas, o AWS Control Tower envia os eventos de Descoberta do AWS Security Hub somente para a região de origem do AWS Control Tower. Consulte mais informações em Security Hub control drift reporting.

Atualização do controle de negação de região

Essa versão da zona de pouso também inclui uma atualização para o controle de negação de região.

Serviços globais e APIs adicionados

  • AWS Billing and Cost Management (billing:*)

  • AWS CloudTrail (cloudtrail:LookupEvents) para permitir a visibilidade de eventos globais nas contas-membros.

  • Faturamento Consolidado da AWS (consolidatedbilling:*)

  • Aplicativo Móvel do Console de Gerenciamento da AWS (consoleapp:*)

  • Nível gratuito da AWS (freetier:*)

  • Faturamento da AWS (invoicing:*)

  • AWS IQ (iq:*)

  • Notificações de Usuários da AWS (notifications:*)

  • Contatos de Notificações de Usuários da AWS (notifications-contacts:*)

  • Pagamentos da Amazon (payments:*)

  • Configurações fiscais da AWS (tax:*)

Serviços globais e APIs removidos

  • Remoção de s3:GetAccountPublic porque não é uma ação válida.

  • Remoção de s3:PutAccountPublic porque não é uma ação válida.

AWS Control Tower gerencia contas com base em ID

14 de junho de 2023

(Não é necessário atualizar a zona de pouso do AWS Control Tower.)

O AWS Control Tower agora cria e gerencia contas que você cria no Account Factory rastreando o ID da conta da AWS, em vez do endereço de e-mail da conta.

Ao provisionar uma conta, o solicitante da conta sempre deve ter as permissões CreateAccount e DescribeCreateAccountStatus. Esse conjunto de permissões faz parte do perfil de Administrador e é concedido automaticamente quando um solicitante assume esse perfil. Se você delegar permissão para provisionar contas, talvez seja necessário adicionar essas permissões diretamente aos solicitantes da conta.

Controles de detecção adicionais do Security Hub disponíveis na biblioteca de controles do AWS Control Tower

12 de junho de 2023

(Não é necessário atualizar a zona de pouso do AWS Control Tower.)

O AWS Control Tower adicionou dez novos controles de detecção do AWS Security Hub à biblioteca de controles do AWS Control Tower. Esses novos controles têm como destino serviços como API Gateway, AWS CodeBuild, Amazon Elastic Compute Cloud (EC2), Amazon Elastic Load Balancer, Amazon Redshift, Amazon SageMaker e AWS WAF. Esses novos controles ajudam a aprimorar seu procedimento de governança atendendo aos objetivos de controle, como Estabelecer registro em log e monitoramento, Limitar o acesso à rede e Criptografar dados em repouso.

Esses controles agem como parte do Padrão gerenciado por serviços do Security Hub: AWS Control Tower, depois que você os habilita em qualquer UO específica.

  • [SH.Account.1]: as informações de contato de segurança devem ser fornecidas para uma Conta da AWS.

  • [SH.APIGateway.8]: as rotas do API de Gateway devem especificar um tipo de autorização.

  • [SH.APIGateway.9]: o registro em log de acesso deve ser configurado para os estágios V2 do API Gateway.

  • [SH.CodeBuild.3]: os logs do CodeBuild S3 devem ser criptografados.

  • [SH.EC2.25]: os modelos de execução do EC2 não devem atribuir IPs públicos às interfaces de rede.

  • [SH.ELB.1]: o Application Load Balancer deve ser configurado para redirecionar todas as solicitações HTTP para HTTPS.

  • [SH.Redshift.10]: os clusters do Redshift devem ser criptografados em repouso.

  • [SH.SageMaker.2]: as instâncias de caderno do SageMaker devem ser iniciadas em uma VPC personalizada.

  • [SH.SageMaker.3]: os usuários não devem ter acesso raiz às instâncias de caderno do SageMaker.

  • [SH.WAF.10]: a ACL da Web do WAFV2 devem ter pelo menos uma regra ou um grupo de regras.

Os novos controles de detecção do AWS Security Hub estão disponíveis em todas as Regiões da AWS onde o AWS Control Tower está disponível. Consulte mais detalhes sobre esses controles em Controls that apply to Service-Managed Standard: AWS Control Tower.

AWS Control Tower publica tabelas de metadados de controle

7 de junho de 2023

(Não é necessário atualizar a zona de pouso do AWS Control Tower.)

O AWS Control Tower agora fornece tabelas completas de metadados de controle como parte da documentação publicada. Ao trabalhar com as APIs de controle, é possível consultar o Identificador de controle da API de cada controle, que é um ARN exclusivo associado a cada Região da AWS. As tabelas incluem os frameworks e os objetivos de controle que cada controle abrange. Anteriormente, essas informações estavam disponíveis somente no console.

As tabelas também incluem os metadados dos controles do Security Hub que fazem parte do Padrão gerenciado por serviço do AWS Security Hub: AWS Control Tower. Consulte detalhes completos em Tables of control metadata.

Consulte uma lista abreviada de identificadores de controle e alguns exemplos de uso em Resource identifiers for APIs and controls.

Suporte do Terraform para o Account Factory Customization

6 de junho de 2023

(Não é necessário atualizar a zona de pouso do AWS Control Tower.)

O AWS Control Tower oferece suporte em uma única região para o Terraform por meio do Account Factory Customization (AFC). A partir desse lançamento, é possível usar o AWS Control Tower e o Service Catalog juntos para definir esquemas de contas do AFC no Terraform Open Source. É possível personalizar Contas da AWS novas e existentes antes de provisionar recursos no AWS Control Tower. Por padrão, esse recurso permite implantar e atualizar contas, com o Terraform, na sua região de origem do AWS Control Tower.

Um esquema de conta descreve recursos e configurações específicos que são necessários quando uma Conta da AWS é provisionada. É possível usar o esquema como modelo para criar várias Contas da AWS em grande escala.

Para começar, use o Terraform Reference Engine on GitHub. O Reference Engine configura o código e a infraestrutura necessários para que o mecanismo de código aberto do Terraform funcione com o Service Catalog. Esse processo de configuração único leva alguns minutos. Depois disso, é possível definir seus requisitos de conta personalizados no Terraform e, depois, implantar suas contas com o fluxo de trabalho bem definido do Account Factory do AWS Control Tower. Os clientes que preferem trabalhar com o Terraform podem utilizar a personalização de conta do AWS Control Tower em grande escala com o AFC e ter acesso imediato a cada conta após o provisionamento.

Para saber como criar essas personalizações, consulte Creating Products e Getting started with Terraform open source na documentação do Service Catalog. Esse recurso está disponível em todas as Regiões da AWS em que o AWS Control Tower está disponível.

Autogerenciamento do Centro de Identidade do AWS IAM disponível para zona de pouso

6 de junho de 2023

(Não é necessário atualizar a zona de pouso do AWS Control Tower.)

O AWS Control Tower agora oferece uma opção de provedor de identidades para uma zona de pouso do AWS Control Tower, que você pode definir durante a configuração ou atualização. Por padrão, a zona de pouso usa o Centro de Identidade do AWS IAM, de acordo com as diretrizes das práticas recomendadas definidas em Organizing Your AWS Environment Using Multiple Accounts. Agora você tem três alternativas:

  • Você pode aceitar o padrão e permitir que o AWS Control Tower configure e gerencie o Centro de Identidade do AWS IAM para você.

  • Você pode optar por autogerenciar o Centro de Identidade do AWS IAM para refletir seus requisitos comerciais específicos.

  • Opcionalmente, você pode trazer e autogerenciar um provedor de identidades de terceiros, conectando-o por meio do Centro de Identidade do IAM, se necessário. Você deverá optar pelo provedor de identidades se o ambiente regulatório exigir o uso de um provedor específico ou se você operar em Regiões da AWS onde o Centro de Identidade do AWS IAM não esteja disponível.

Consulte mais informações em Orientações sobre o Centro de Identidade do IAM.

A seleção de provedores de identidade no nível da conta não é permitida. Esse recurso se aplica somente à zona de pouso como um todo. A opção do provedor de identidades do AWS Control Tower está disponível em todas as Regiões da AWS onde o AWS Control Tower está disponível.

AWS Control Tower aborda a governança mista para UOs

1.º de junho de 2023

(Não é necessário atualizar a zona de pouso do AWS Control Tower.)

Com esse lançamento, o AWS Control Tower impede a implantação de controles em uma unidade organizacional (UO), se essa UO estiver em um estado de governança mista. A governança mista ocorrerá em uma UO se as contas não forem atualizadas depois que o AWS Control Tower estender a governança para uma nova Região da AWS ou remover a governança. Esse lançamento ajuda você a manter as contas-membros dessa UO em conformidade uniforme. Consulte mais informações em Evitar governança mista ao configurar regiões.

Controles proativos adicionais disponíveis

19 de maio de 2023

(Não é necessário atualizar a zona de pouso do AWS Control Tower.)

O AWS Control Tower está adicionando 28 novos controles proativos para ajudar a administrar o ambiente de várias contas e a cumprir objetivos de controle específicos, como criptografia de dados em repouso ou limitar o acesso à rede. Os controles proativos são implementados com hooks do AWS CloudFormation que verificam seus recursos antes de serem provisionados. Os novos controles podem ajudar a administrar serviços da AWS como Amazon OpenSearch Service, Amazon EC2 Auto Scaling, Amazon SageMaker, Amazon API Gateway e Amazon Relational Database Service (RDS).

Os controles proativos são compatíveis com todas as Regiões da AWS comerciais onde o AWS Control Tower está disponível.

Amazon OpenSearch Service

  • [CT.OPENSEARCH.PR.1]: exija um domínio do Elasticsearch para criptografar dados em repouso.

  • [CT.OPENSEARCH.PR.2]: exija que um domínio do Elasticsearch seja criado em uma Amazon VPC especificada pelo usuário.

  • [CT.OPENSEARCH.PR.3]: exija um domínio do Elasticsearch para criptografar dados enviados entre os nós.

  • [CT.OPENSEARCH.PR.4]: exija um domínio do Elasticsearch para enviar logs de erro ao Amazon CloudWatch Logs.

  • [CT.OPENSEARCH.PR.5]: exija um domínio do Elasticsearch para enviar registros de auditoria ao Amazon CloudWatch Logs.

  • [CT.OPENSEARCH.PR.6]: exija que um domínio do Elasticsearch tenha reconhecimento de zona e pelo menos três nós de dados.

  • [CT.OPENSEARCH.PR.7]: exija que um domínio do Elasticsearch tenha pelo menos três nós principais dedicados.

  • [CT.OPENSEARCH.PR.8]: exija um domínio do Elasticsearch Service para usar o TLSv1.2.

  • [CT.OPENSEARCH.PR.9]: exija um domínio do Amazon OpenSearch Service para criptografar dados em repouso.

  • [CT.OPENSEARCH.PR.10]: exija que um domínio do Amazon OpenSearch Service seja criado em uma Amazon VPC especificada pelo usuário.

  • [CT.OPENSEARCH.PR.11]: exija um domínio do Amazon OpenSearch Service para criptografar dados enviados entre os nós.

  • [CT.OPENSEARCH.PR.12]: exija um domínio do Amazon OpenSearch Service para enviar logs de erro ao Amazon CloudWatch Logs.

  • [CT.OPENSEARCH.PR.13]: exija um domínio do Amazon OpenSearch Service para enviar registros de auditoria ao Amazon CloudWatch Logs.

  • [CT.OPENSEARCH.PR.14]: exija que um domínio do Amazon OpenSearch Service tenha reconhecimento de zonas e pelo menos três nós de dados.

  • [CT.OPENSEARCH.PR.15]: exija um domínio do Amazon OpenSearch Service para usar um controle de acesso refinado.

  • [CT.OPENSEARCH.PR.16]: exija um domínio do Amazon OpenSearch Service para usar o TLSv1.2.

Amazon EC2 Auto Scaling

  • [CT.AUTOSCALING.PR.1]: exija que um grupo do Amazon EC2 Auto Scaling tenha várias zonas de disponibilidade.

  • [CT.AUTOSCALING.PR.2]: exija uma configuração de execução de grupo do Amazon EC2 Auto Scaling para configurar instâncias do Amazon EC2 para IMDSv2.

  • [CT.AUTOSCALING.PR.3]: exija que uma configuração de execução do Amazon EC2 Auto Scaling tenha um limite de resposta de metadados de salto único.

  • [CT.AUTOSCALING.PR.4]: exija que um grupo do Amazon EC2 Auto Scaling associado a um Amazon Elastic Load Balancing (ELB) tenha as verificações de integridade do ELB ativadas.

  • [CT.AUTOSCALING.PR.5]: exija que uma configuração de execução de grupo do Amazon EC2 Auto Scaling não tenha instâncias do Amazon EC2 com endereços IP públicos.

  • [CT.AUTOSCALING.PR.6]: exija que qualquer grupo do Amazon EC2 Auto Scaling use vários tipos de instância.

  • [CT.AUTOSCALING.PR.8]: exija que um grupo do Amazon EC2 Auto Scaling tenha modelos de execução do EC2 configurados.

Amazon SageMaker

  • [CT.SAGEMAKER.PR.1]: exija uma instância de caderno do Amazon SageMaker para impedir o acesso direto à internet.

  • [CT.SAGEMAKER.PR.2]: exija que as instâncias de caderno do Amazon SageMaker sejam implantadas em uma Amazon VPC personalizada.

  • [CT.SAGEMAKER.PR.3]: exija que as instâncias de caderno do Amazon SageMaker tenham acesso raiz não permitido.

Amazon API Gateway

  • [CT.APIGATEWAY.PR.5]: exija rotas de Websocket e HTTP do Amazon API Gateway V2 para especificar um tipo de autorização.

Amazon Relational Database Service (RDS)

  • [CT.RDS.PR.25]: exija que um cluster de banco de dados do Amazon RDS tenha o registro em log configurado.

Consulte mais informações em Proactive controls.

Atualização de controles proativos do Amazon EC2

2 de maio de 2023

(Não é necessário atualizar a zona de pouso do AWS Control Tower.)

O AWS Control Tower atualizou dois controles proativos: CT.EC2.PR.3 e CT.EC2.PR.4.

Para o controle CT.EC2.PR.3 atualizado, qualquer implantação do AWS CloudFormation que faça referência a uma lista de prefixos para um recurso do grupo de segurança é bloqueada, a menos que seja para a porta 80 ou 443.

Para o controle CT.EC2.PR.4 atualizado, qualquer implantação do AWS CloudFormation que faça referência a uma lista de prefixos para um recurso de grupo de segurança será bloqueada se a porta for 3389, 20, 23, 110, 143, 3306, 8080, 1433, 9200, 9300, 25, 445, 135, 21, 1434, 4333, 5432, 5500, 5601, 22, 3000, 5000, 8088, 8888.

Sete Regiões da AWS adicionais disponíveis

19 de abril de 2023

(Não é necessário atualizar a zona de pouso do AWS Control Tower.)

O AWS Control Tower já está disponível em mais sete Regiões da AWS: Norte da Califórnia (São Francisco), Ásia-Pacífico (Hong Kong, Jacarta e Osaka), Europa (Milão), Oriente Médio (Bahrein) e África (Cidade do Cabo). Essas regiões adicionais do AWS Control Tower, chamadas de regiões opcionais, não estão ativas por padrão, exceto a região Oeste dos EUA (N. da Califórnia), que está ativa por padrão.

Alguns controles no AWS Control Tower não operam em algumas dessas Regiões da AWS adicionais onde o AWS Control Tower está disponível, porque essas regiões não são compatíveis com a funcionalidade subjacente necessária. Consulte detalhes em Limitações de controle.

Dentre essas novas regiões, o CfCT não está disponível na região Ásia-Pacífico (Jacarta e Osaka). A disponibilidade em outras Regiões da AWS permanece inalterada.

Consulte mais informações sobre como o AWS Control Tower gerencia as limitações de regiões e controles em Considerações sobre como ativar as regiões opcionais da AWS.

Os endpoints da VPCe exigidos pelo AFT não estão disponíveis na região Oriente Médio (Bahrein). Os clientes que implantam o AFT nesta região devem implantar com o parâmetro aft_vpc_endpoints=false. Consulte mais informações no parâmetro do arquivo README.

As VPCs do AWS Control Tower têm duas zonas de disponibilidade na região Oeste dos EUA (N. da Califórnia), us-west-1, devido a uma limitação no Amazon EC2. Na região Oeste dos EUA (N. da Califórnia), seis sub-redes são divididas em duas zonas de disponibilidade. Consulte mais informações em Visão geral do AWS Control Tower e VPCs.

O AWS Control Tower adicionou novas permissões a AWSControlTowerServiceRolePolicy para autorizar o AWS Control Tower a fazer chamadas para as APIs EnableRegion, ListRegions e GetRegionOptStatus implementadas pelo serviço AWS Account Management, para disponibilizar essas Regiões da AWS adicionais para suas contas compartilhadas na zona de pouso (conta de gerenciamento, conta de arquivamento de logs, conta de auditoria) e suas contas-membros da UO. Consulte mais informações em Políticas gerenciadas para o AWS Control Tower.

Rastreamento de solicitações de personalização de conta do Account Factory for Terraform (AFT)

16 de fevereiro de 2023

O AFT permite o rastreamento de solicitações de personalização de conta. Toda vez que você envia uma solicitação de personalização de conta, o AFT gera um token de rastreamento exclusivo que passa por uma máquina de estado do AWS Step Functions de personalização do AFT, que registra em log o token como parte de sua execução. É possível usar as consultas do Amazon CloudWatch Logs Insights para pesquisar intervalos de carimbo de data/hora e recuperar o token da solicitação. Como resultado, é possível ver as cargas úteis que acompanham o token, para que você possa rastrear sua solicitação de personalização de conta em todo o fluxo de trabalho do AFT. Consulte mais informações sobre o AFT em Overview of AWS Control Tower Account Factory for Terraform. Consulte informações sobre o CloudWatch Logs e o Step Functions em:

Versão 3.1 da zona de pouso do AWS Control Tower

9 de fevereiro de 2023

(É necessário atualizar a zona de pouso do AWS Control Tower para a versão 3.1. Consulte informações em Atualizar a zona de pouso)

A versão 3.1 da zona de pouso do AWS Control Tower inclui as seguintes atualizações:

  • Com esse lançamento, o AWS Control Tower desativa o registro em log de acesso desnecessário para o bucket de registro em log de acesso, que é o bucket do Amazon S3 em que os logs de acesso são armazenados na conta de arquivamento de logs, enquanto continua habilitando o registro em log de acesso ao servidor para buckets do S3. Esse lançamento também inclui atualizações no controle de negação de região que permitem ações adicionais para serviços globais, como planos do AWS Support e AWS Artifact.

  • A desativação do registro em log de acesso ao servidor para o bucket de registro em log de acesso do AWS Control Tower faz com que o Security Hub crie uma descoberta para o bucket de registro em log de acesso da conta de arquivamento de logs, devido a uma regra do AWS Security Hub: [S3.9] O registro em log de acesso ao servidor do bucket do S3 deve ser habilitado. Em alinhamento com o Security Hub, recomendamos que você suprima essa descoberta específica, conforme declarado na descrição dessa regra no Security Hub. Consulte informações adicionais sobre descobertas suprimidas.

  • O registro em log de acesso para o bucket de registro em log (regular) na conta de arquivamento de logs permanece inalterado na versão 3.1. De acordo com as práticas recomendadas, os eventos de acesso desse bucket são registrados como entradas de log no bucket de registro em log de acesso. Consulte mais informações sobre o registro em log de acesso em Registrar em log as solicitações com registro em log de acesso ao servidor na documentação do Amazon S3.

  • Fizemos uma atualização no controle de negação de região. Essa atualização permite ações de mais serviços globais. Consulte detalhes sobre essa SCP em Deny access to AWS based on the requested Região da AWS e em Controls that enhance data residency protection.

    Serviços globais adicionados:

    • AWS Account Management (account:*)

    • AWS Activate (activate:*)

    • AWS Artifact (artifact:*)

    • AWS Billing Conductor (billingconductor:*)

    • AWS Compute Optimizer (compute-optimizer:*)

    • AWS Data Pipeline (datapipeline:GetAccountLimits)

    • AWS Device Farm(devicefarm:*)

    • AWS Marketplace (discovery-marketplace:*)

    • Amazon ECR (ecr-public:*)

    • AWS License Manager (license-manager:ListReceivedLicenses)

    • AWS Lightsail (lightsail:Get*)

    • Explorador de recursos da AWS (resource-explorer-2:*)

    • Amazon S3 (s3:CreateMultiRegionAccessPoint, s3:GetBucketPolicyStatus, s3:PutMultiRegionAccessPointPolicy)

    • AWS Savings Plans (savingsplans:*)

    • Centro de Identidade do IAM (sso:*)

    • AWS Support App (supportapp:*)

    • Planos do AWS Support (supportplans:*)

    • Sustentabilidade da AWS (sustainability:*)

    • AWS Resource Groups Tagging API (tag:GetResources)

    • AWS Marketplace Vendor Insights (vendor-insights:ListEntitledSecurityProfiles)

Controles proativos disponíveis ao público

24 de janeiro de 2023

(Não é necessário atualizar a zona de pouso do AWS Control Tower.)

Os controles proativos opcionais, anunciados anteriormente no status de prévia, já estão disponíveis ao público. Esses controles são chamados de proativos porque verificam seus recursos, antes de serem implantados, para determinar se os novos recursos estão em conformidade com os controles ativados no ambiente. Consulte mais informações em Controles abrangentes auxiliam no provisionamento e gerenciamento de recursos da AWS.