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á.
Controles padrão no AMS Accelerate
A seguir estão os controles padrão no AMS:
| ID | Padrão técnico |
|---|---|
| 1.0 | Duração do tempo limite |
| 1.1 | O tempo limite padrão de uma sessão de usuário federado é de uma hora e pode ser aumentado para até quatro horas. |
| 1.2 | O tempo limite da sessão RDP para o Microsoft Windows Server está definido para 15 minutos e pode ser estendido com base no caso de uso. |
| 2.0 | AWS Uso da conta raiz |
| 2.1 | Se houver uso da conta raiz por qualquer motivo, a Amazon GuardDuty deverá ser configurada para gerar descobertas relevantes. |
| 2.2 | As chaves de acesso para a conta raiz não devem ser criadas. |
| 3.0 | Criação e modificação de usuários |
| 3.1 | O IAM users/roles com acesso programático e com permissões somente de leitura pode ser criado sem nenhuma política de tempo limitado. No entanto, a permissão para permitir a leitura de objetos (por exemplo, S3:GetObject) em todos os buckets do Amazon Simple Storage Service na conta não é permitida. |
| 3.1.1 | Usuários humanos do IAM para acesso ao console e com permissões somente de leitura podem ser criados com a política de limite de tempo (até 180 dias), enquanto a política com limite removal/renewal/extension de tempo resultará na notificação de risco. No entanto, a permissão para permitir a leitura de objetos (por exemplo, S3:GetObject) em todos os buckets do S3 na conta não é permitida. |
| 3.2 | Os usuários e funções do IAM para acesso programático e de console com quaisquer permissões que alterem a infraestrutura (gravação e gerenciamento de permissões) na conta do cliente não devem ser criados sem a aceitação do risco. Existem exceções para permissões de gravação em nível de objeto do S3, que são permitidas sem aceitação de riscos, desde que os buckets específicos estejam no escopo e nas operações de marcação em tags não relacionadas ao AMS. |
| 3.3 | Nos servidores Microsoft Windows, somente a Conta de Serviço Gerenciada do Grupo Microsoft (gMSA) deve ser criada. |
| 4,0 | Políticas, ações e APIs |
| 4.4 | Uma política não deve fornecer acesso ao administrador com uma declaração equivalente a “Efeito”: “Permitir” com “Ação”: “*” sobre “Recurso”: “*” sem aceitação de risco. |
| 4.6 | As chamadas de API contra políticas de chaves do KMS para chaves de infraestrutura do AMS nas políticas de IAM do cliente não devem ser permitidas. |
| 4.8 | Ações que alterem os registros DNS da infraestrutura do AMS no Amazon Route 53 não devem ser permitidas. |
| 4,9 | Usuários humanos do IAM com acesso ao console criado após seguirem o devido processo legal não devem ter nenhuma política anexada diretamente, exceto a política de confiança, a política de assumir funções e a política de limite de tempo. |
| 4.10 | Perfis de EC2 instância da Amazon com acesso de leitura a um segredo ou namespace específico AWS Secrets Manager na mesma conta podem ser criados. |
| 4.12 | A política do IAM não deve incluir nenhuma ação que inclua a ação Permitir registros: DeleteLogGroup e registros: DeleteLogStream em qualquer grupo de CloudWatch registros do AMS Amazon. |
| 4.13 | As permissões para criar chaves multirregionais não devem ser permitidas. |
| 4.14 | O acesso ao ARN do bucket do S3 que ainda não foi criado nas contas do cliente pode ser fornecido restringindo o acesso aos compartimentos às contas do cliente por meio da especificação do número da conta usando a chave de condição S3 específica do serviço s3:. ResourceAccount |
| 4.15.1 | Você pode visualizar, criar, listar e excluir o acesso ao painel personalizado da lente de armazenamento do S3. |
| 4.16 | Permissões completas relacionadas ao SQL Workbench podem ser concedidas roles/users para trabalhar nos bancos de dados do Amazon Redshift. |
| 4.17 | Qualquer AWS CloudShell permissão pode ser concedida às funções do cliente como alternativa à CLI. |
| 4.18 | Uma função do IAM com o AWS serviço como principal confiável também precisa estar alinhada com os padrões técnicos do IAM. |
| 4.19 | As funções vinculadas ao serviço (SLRs) não estão sujeitas aos padrões técnicos do AMS IAM, pois são criadas e mantidas pela equipe de serviço do IAM. |
| 4.20 | A política do IAM não deve permitir a leitura de objetos (por exemplo, S3:GetObject) em todos os buckets do S3 na conta. |
| 4.21 | Todas as permissões do IAM para o tipo de recurso “savingsplan” podem ser concedidas aos clientes. |
| 4.22 | O engenheiro do AMS não tem permissão para copiar ou mover dados do cliente (arquivos, objetos do S3, bancos de dados etc.) manualmente em nenhum dos serviços de armazenamento de dados, como Amazon S3, Amazon Relational Database Service, Amazon DynamoDB, etc., nem no sistema de arquivos do sistema operacional. |
| 6.0 | Políticas de contas cruzadas |
| 6.1 | As funções do IAM, as políticas de confiança entre contas do AMS que pertencem ao mesmo cliente, de acordo com os registros do cliente, podem ser configuradas. |
| 6.2 | As políticas de confiança das funções do IAM entre contas AMS e não AMS devem ser configuradas somente se a conta não AMS pertencer ao mesmo cliente do AMS (confirmando que elas estão na mesma AWS Organizations conta ou combinando o domínio de e-mail com o nome da empresa do cliente). |
| 6.3 | As políticas de confiança das funções do IAM entre contas do AMS e contas de terceiros não devem ser configuradas sem a aceitação do risco. |
| 6.4 | Políticas entre contas para acessar qualquer cliente gerenciado CMKs entre contas AMS do mesmo cliente podem ser configuradas. |
| 6.5 | Políticas entre contas para acessar qualquer chave KMS em uma conta não AMS por meio de uma conta AMS podem ser configuradas. |
| 6.6 | As políticas entre contas para acessar qualquer chave KMS em uma conta AMS por uma conta de terceiros não devem ser permitidas sem a aceitação do risco. |
| 6.6.1 | As políticas entre contas para acessar qualquer chave KMS em uma conta AMS por uma conta não AMS só podem ser configuradas se a conta não AMS pertencer ao mesmo cliente do AMS. |
| 6.7 | Políticas entre contas para acessar quaisquer dados ou recursos do bucket do S3 em que os dados possam ser armazenados (como Amazon RDS, Amazon DynamoDB ou Amazon Redshift) entre contas AMS do mesmo cliente podem ser configuradas. |
| 6.8 | Políticas entre contas para acessar quaisquer dados ou recursos do bucket do S3 em que os dados possam ser armazenados (como Amazon RDS, Amazon DynamoDB ou Amazon Redshift) em uma conta não AMS a partir de uma conta AMS com acesso somente leitura podem ser configuradas. |
| 6.9 | Políticas entre contas para acessar quaisquer dados ou recursos de bucket do S3 em que os dados possam ser armazenados (como Amazon RDS, Amazon DynamoDB ou Amazon Redshift) com permissões de gravação do AMS para uma conta que não seja do AMS (ou de uma conta que não seja do AMS para o AMS) devem ser configuradas somente se a conta não AMS pertencer ao mesmo cliente do AMS (confirmando que eles estão na mesma conta ou combinando o domínio de e-mail). com AWS Organizations o nome da empresa do cliente). |
| 6.10 | Políticas entre contas para acessar quaisquer dados ou recursos do bucket do S3 em que os dados possam ser armazenados (como Amazon RDS, Amazon DynamoDB ou Amazon Redshift) em uma conta de terceiros a partir de uma conta AMS com acesso somente leitura podem ser configuradas. |
| 6.11 | Políticas entre contas para acessar quaisquer dados ou recursos do bucket do S3 em que os dados possam ser armazenados (como Amazon RDS, Amazon DynamoDB ou Amazon Redshift) em uma conta de terceiros a partir de uma conta AMS com acesso de gravação não devem ser configuradas. |
| 6.12 | Políticas entre contas de contas de terceiros para acessar um bucket S3 de um cliente do AMS ou recursos nos quais os dados podem ser armazenados (como Amazon RDS, Amazon DynamoDB ou Amazon Redshift) não devem ser configuradas sem a aceitação do risco. |
| 7.0 | User Groups (Grupos de usuários) |
| 7.1 | Grupos do IAM com permissões somente de leitura e não mutativas são permitidos. |
| 8.0 | Políticas baseadas em recurso |
| 8.4 | Os recursos de infraestrutura do AMS devem ser protegidos do gerenciamento por identidades não autorizadas por meio da anexação de políticas baseadas em recursos. |
| 8.2 | Os recursos do cliente devem ser configurados com políticas baseadas em recursos com privilégios mínimos, a menos que o cliente especifique explicitamente uma política diferente. |
A seguir está o controle padrão para X003 - Network Security:
| ID | Padrão técnico |
|---|---|
| Redes | |
| 1,0 | Reservado para controle futuro |
| 2,0 | O IP elástico em EC2 instâncias é permitido |
| 3.0 | O plano de controle AMS e, por extensão, no plano de dados TLS 1.2+ devem ser usados. |
| 5,0 | Um grupo de segurança não deve ter origem como 0.0.0.0/0 na regra de entrada se não estiver conectado a um balanceador de carga conforme 9.0 |
| 6.0 | O bucket ou os objetos do S3 não devem ser tornados públicos sem a aceitação do risco. |
| 7.0 | O acesso ao gerenciamento de servidores nas portas SSH/22 ou SSH/2222 (não SFTP/2222), TELNET/23, RDP/3389, WinRM/5985-5986, VNC/ 5900-5901 TS/CITRIX/1494 ou 1604, LDAP/389 ou 636 e RPC/135, NETBIOS/137-139 não deve ser permitido de fora da VM VPC por meio de grupos de segurança. |
| 8.0 | O acesso ao gerenciamento de banco de dados em portas (MySQL/3306, PostgreSQL/5432, Oracle/1521, MSSQL/1433) ou em portas personalizadas não deve ser permitido do público, não roteado para VPC sobre DX, VPC-peer ou VPN via grupo de segurança. IPs |
| 8.1 | Qualquer recurso em que os dados do cliente possam ser armazenados não deve ser exposto diretamente à Internet pública. |
| 9.0 | O acesso direto a aplicativos pela porta HTTP/80, HTTPS/8443 e HTTPS/443 da Internet é permitido somente para balanceadores de carga, mas não para nenhum recurso de computação diretamente, por exemplo, instâncias, contêineres etc. EC2 ECS/EKS/Fargate |
| 10.0 | O acesso de aplicativos pelas portas HTTP/80 e HTTPS/443 a partir do intervalo de IP privado do cliente pode ser permitido. |
| 11.0 | Quaisquer alterações nos grupos de segurança que controlam o acesso à infraestrutura do AMS não devem ser permitidas sem a aceitação do risco. |
| 12.0 | O AMS Security consultará os padrões sempre que for solicitado que um grupo de segurança seja anexado a uma instância. |
| 14.0 | A associação entre contas de zonas hospedadas privadas com contas VPCs de AMS para contas não AMS (ou não AMS para AMS) deve ser configurada somente se a conta não AMS pertencer ao mesmo cliente AMS (confirmando que elas estão na mesma conta da AWS Organization ou combinando o domínio de e-mail com o nome da empresa do cliente) usando ferramentas internas. |
| 15.0 | Conexões de emparelhamento de VPC entre contas que pertencem ao mesmo cliente podem ser permitidas. |
| 16,0 | A base do AMS AMIs pode ser compartilhada com contas que não sejam da AMS, desde que ambas sejam de propriedade do mesmo cliente (confirmando que estão na mesma AWS Organizations conta ou combinando o domínio do e-mail com o nome da empresa do cliente) usando ferramentas internas. |
| 17.0 | A porta FTP 21 não deve ser configurada em nenhum grupo de segurança sem a aceitação do risco. |
| 18,0 | A conectividade de rede entre contas via gateway de trânsito é permitida, desde que todas as contas sejam de propriedade do cliente. |
| 19,0 | Não é permitido transformar uma sub-rede privada em pública |
| 20.0 | Conexões de emparelhamento de VPC com contas de terceiros (não pertencentes ao cliente) não devem ser permitidas. |
| 21,0 | A vinculação do Transit Gateway a uma conta de terceiros (não pertencente ao cliente) não deve ser permitida. |
| 22,0 | Qualquer tráfego de rede necessário para que o AMS forneça os serviços aos clientes não deve ser bloqueado no ponto de saída da rede do cliente. |
| 23,0 | A solicitação de ICMP recebida da infraestrutura EC2 do cliente para a Amazon exigirá uma notificação de risco. |
| 24,0 | Solicitações de entrada do público IPs roteadas para a Amazon VPC via DX, VPC-peer ou VPN via grupo de segurança são permitidas. |
| 25.0 | Solicitações de entrada de um público IPs não roteado para a Amazon VPC via DX, VPC-peer ou VPN via grupo de segurança exigiriam uma aceitação de risco. |
| 26,0 | A solicitação ICMP de saída da Amazon EC2 para qualquer destino é permitida. |
| 27,0 | Compartilhamento de grupos de segurança |
| 27.1 | Se um grupo de segurança atender a esse padrão de segurança, ele poderá ser compartilhado VPCs na mesma conta e entre contas na mesma organização. |
| 27.2 | Se um grupo de segurança não atender a esse padrão e uma aceitação de risco tiver sido exigida anteriormente para esse grupo de segurança, o uso do recurso de compartilhamento de grupos de segurança entre VPCs a mesma conta ou entre contas na mesma organização não será permitido sem a aceitação do risco para essa nova VPC ou conta. |
O seguinte é o controle padrão para X004 - Teste de penetração
O AMS não oferece suporte à infraestrutura de pentest. É responsabilidade do cliente. Por exemplo, o Kali não é uma distribuição Linux compatível com AMS.
Os clientes precisam aderir aos testes de penetração
. O AMS deve ser pré-notificado com 24 horas de antecedência, caso o cliente deseje realizar testes de penetração de infraestrutura nas contas.
A AMS provisionará a infraestrutura de pentesting do cliente de acordo com os requisitos do cliente explicitamente declarados na solicitação de mudança ou solicitação de serviço do cliente.
O gerenciamento de identidade da infraestrutura de testes do cliente é de responsabilidade do cliente.
A seguir está o controle padrão para o X005 - GuardDuty
GuardDuty deve estar habilitado em todas as contas de clientes em todos os momentos.
GuardDuty os alertas devem ser armazenados na mesma conta ou em qualquer outra conta gerenciada da mesma organização.
O recurso de lista de IP confiável do não GuardDuty deve ser usado. Em vez disso, o arquivamento automático pode ser usado como alternativa, o que é útil para fins de auditoria.
A seguir está o controle padrão para X007 - Logging
| ID | Padrão técnico |
|---|---|
| 1.0 | Tipos de registro |
| 1.1 | Registros do sistema operacional: todos os hosts devem registrar eventos mínimos de autenticação do host, eventos de acesso para todos os usos de privilégios elevados e eventos de acesso para todas as alterações no acesso e na configuração de privilégios, incluindo sucesso e falha. |
| 1.2 | AWS CloudTrail: o registro CloudTrail de eventos de gerenciamento deve ser ativado e configurado para entregar os registros a um bucket do S3. |
| 1.3 | Registros de fluxo de VPC: todos os registros de tráfego de rede devem ser registrados por meio de registros de fluxo de VPC. |
| 1.4 | Registro de acesso ao servidor Amazon S3: os buckets S3 obrigatórios do AMS que armazenam registros devem ter o registro de acesso ao servidor ativado. |
| 1.5 | AWS Config Snapshots: AWS Config devem registrar as alterações de configuração de todos os recursos suportados em todas as regiões e entregar os arquivos de instantâneos de configuração aos buckets do S3 pelo menos uma vez por dia. |
| 1,7 | Registros de aplicativos: os clientes têm o poder de ativar o login em seus aplicativos e armazená-los no grupo de registros de CloudWatch registros ou em um bucket do S3. |
| 1.8 | Registro em nível de objeto do S3: os clientes têm o poder de ativar o registro em nível de objeto em seus buckets do S3. |
| 1.9 | Registro de serviços: os clientes têm o poder de habilitar e encaminhar registros para serviços SSPS como qualquer serviço principal. |
| 1.10 | Registros do Elastic Load Balancing (Classic/Application Load Balancer/NetworkLoad Balancer): as entradas de registro de acesso e erro devem ser armazenadas nos buckets S3 gerenciados pelo AMS 2.0. |
| 2.0 | Controle de acesso |
| 2.3 | Os buckets S3 exigidos pela AMS que armazenam registros não devem permitir usuários de contas de terceiros como princípios nas políticas do bucket. |
| 2.4 | Os registros dos grupos de CloudWatch registros do Logs não devem ser excluídos sem a aprovação explícita do contato de segurança autorizado do cliente. |
| 3.0 | Retenção de registros |
| 3.1 | Os grupos de registros de CloudWatch registros exigidos pela AMS devem ter um período mínimo de retenção de 90 dias nos registros. |
| 3.2 | Os buckets S3 exigidos pela AMS que armazenam os registros devem ter um período mínimo de retenção de 18 meses nos registros. |
| 3.3 | AWS Backup os instantâneos devem estar disponíveis com retenção mínima de 31 dias nos recursos suportados. |
| 4,0 | Criptografia |
| 4.1 | A criptografia deve estar habilitada em todos os buckets do S3 exigidos pelas equipes do AMS que armazenam registros. |
| 4.2 | Qualquer encaminhamento de registros de contas de clientes para qualquer outra conta deve ser criptografado. |
| 5.0 | Integridade |
| 5.1 | O mecanismo de integridade do arquivo de log deve estar ativado. Isso significa configurar a “validação do arquivo de log” nas AWS CloudTrail trilhas exigidas pelas equipes do AMS. |
| 6.0 | Encaminhamento de registros |
| 6.1 | Qualquer registro pode ser encaminhado de uma conta AMS para outra conta AMS do mesmo cliente. |
| 6.2 | Qualquer registro pode ser encaminhado do AMS para uma conta não AMS somente se a conta não pertencer ao mesmo cliente do AMS (confirmando que eles estão na mesma AWS Organizations conta ou combinando o domínio do e-mail com o nome da empresa do cliente e a conta vinculada ao PAYER) usando ferramentas internas. |
