Controles padrão no AMS Advanced - Guia do usuário avançado do AMS

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 Advanced

A seguir estão os controles padrão no AMS:

A seguir está o controle padrão para 001 - Configuração de marcação.

  1. Todos os AWS recursos exigidos pela equipe do AMS para fins operacionais e de gerenciamento devem ter o seguinte par de valores-chave.

    • AppId= AMSInfrastructure

    • Meio ambiente = AMSInfrastructure

    • AppName = AMSInfrastructure

    • AMSResource=Verdadeiro

  2. Todas as tags exigidas pela equipe do AMS, exceto as listadas anteriormente, devem ter prefixos conforme mencionado na lista de prefixos do AMS (consulte a Nota).

  3. Os valores de tag exigidos pela equipe do AMS (AppId, Ambiente e AppName) podem ser alterados em qualquer um dos recursos criados por você com base em suas solicitações de alteração.

  4. Qualquer tag nas pilhas exigida pelo AMS não deve ser excluída com base em suas solicitações de alteração.

  5. Você não pode usar a convenção de nomenclatura de tags do AMS para sua infraestrutura, conforme mencionado no ponto 2.

  6. Você pode criar etiquetas personalizadas nos recursos exigidos pelo AMS (normalmente para casos de uso de faturamento e relatórios de custos). As tags personalizadas são mantidas se os recursos forem atualizados pela atualização da pilha e não pela atualização do modelo.

nota

Lista de prefixos AMS

  1. ams-*

  2. AWSManagedServiços*

  3. /ams/ *

  4. mão*

  5. MÃO*

  6. Amigos*

  7. mc*

  8. MC*

  9. Mc*

  10. sentinela*

  11. Sentinela*

  12. Serviços_gerenciados*

  13. Novo AMS*

  14. AWS_*

  15. era*

  16. VPC_*

  17. CloudTrail*

  18. Cloudtrail*

  19. /aws_reserved/

  20. INGERIR*

  21. EPSDB*

  22. MÃES*

  23. TemplateId*

  24. StackSet-mão*

  25. StackSet-Zona de aterrissagem da AWS

  26. IAMPolicy*

  27. cliente-mc-*

  28. Raiz*

  29. LandingZone*

  30. StateMachine*

  31. codedeploy_service_role

  32. host de gerenciamento

  33. sentinel.int.

  34. eps

  35. UnhealthyInServiceBastion

  36. ms-

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 padrão de acesso à pilha é de 12 horas.
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 Para contas de zona de destino de conta única (SALZ) e conta de gerenciamento de zona de destino com várias contas (MALZ) (anteriormente conhecida como Master/Billing conta), a conta de usuário raiz deve ter o MFA virtual ativado e o soft token do MFA é descartado durante a integração da conta, para que nem o AMS nem os clientes possam fazer login como root. O processo padrão de perda da senha AWS raiz deve ser seguido em conjunto com o AMS Cloud Service Delivery Manager (CSDM). Essa configuração deve permanecer durante o ciclo de vida das contas gerenciadas pelo AMS.
2.3 Você não deve criar chaves de acesso para a conta raiz.
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 Usuários do IAM com acesso programático, nomeados customer_servicenow_user e customer_servicenow_logging_user necessários para ServiceNow integração na conta do aplicativo SALZ ou MALZ e nas contas*principais*, podem ser criados sem nenhuma política de tempo limitado.
3.4 Os usuários do IAM com acesso programático, uso customer_cloud_endure_policy e customer_cloud_endure_deny_policy (com acesso somente leitura) necessários para CloudEndure integração nas contas SALZ e MALZ podem ser criados, mas precisam de uma política de tempo limitado para o período da migração planejada. O limite de tempo pode ser de um período máximo de 180 dias sem qualquer RA. O SCP também está autorizado a alterar as contas MALZ para permitir que essas políticas funcionem pelo período exigido. Você define janelas de migração apropriadas para suas necessidades e ajusta conforme necessário.
4,0 Políticas, ações e APIs
4.1 Todos os seus usuários e funções do IAM nas contas do SALZ devem ter a Política de Negação do Cliente (CDP) padrão anexada para proteger a infraestrutura do AMS contra danos acidentais ou intencionais.
4.2 O AMS SCPs deve estar habilitado em todas as contas gerenciadas pelo AMS no MALZ.
4.3 Identidades capazes de realizar ações administrativas em chaves KMS, como, e PutKeyPolicyScheduleKeyDeletion, devem ser restritas somente aos operadores e diretores de automação do AMS.
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.5 A política do IAM não deve incluir nenhuma ação que inclua a ação Permitir S3: *** em nenhum bucket 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.7 Ações que ignoram o processo de gerenciamento de alterações (RFC) não devem ser permitidas, como iniciar ou interromper a instância, criar um bucket do S3 ou instância do RDS e assim por diante.
4.8 Ações que fazem alterações nos 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.11 As permissões do AWS Managed Services Change Management (AMSCM) ou do AWS Managed Services Service Knowledge Management System (AMSSKMS) podem ser adicionadas a qualquer função (capacidade de abertura). SR/Incident/RFC
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 Para fornecer acesso ao bucket do S3 ARNs que ainda não foi criado em suas contas, use a chave de condição do S3 específica do serviço s3:ResourceAccount para especificar o número da conta.
4.15 Você pode ter acesso de visualização, criação, lista e exclusão ao seu painel personalizado, mas somente acessar e listar nos CloudWatch painéis da Amazon.
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 um AWS service (Serviço da AWS) diretor confiável também deve estar em conformidade 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 As políticas do IAM não devem permitir acesso de leitura irrestrito aos objetos de bucket do Amazon S3 (por exemplo, Amazon S3GetObject:) em todos os buckets de uma conta:

  • Nas contas do modo Desenvolvedor: as violações resultam em uma notificação de risco

  • Em contas do modo não desenvolvedor: violações exigem aceitação de risco

4.21 Todas as permissões do IAM para o tipo de recurso “savingsplan” podem ser concedidas aos clientes.
4.22 Os engenheiros do AMS não têm permissão para copiar ou mover dados do cliente (arquivos, objetos do S3, bancos de dados) 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.
4.23 A política de SCP não deve ser modificada para permitir qualquer acesso adicional em qualquer conta gerenciada do AMS.
4,24 Quaisquer alterações na política do SCP que possam prejudicar a infraestrutura ou os recursos de gerenciamento do AMS não devem ser permitidas. (Observação: os recursos do AMS têm a tag AppId= AMSInfrastructure e seguem o AMS Protected Namespace).
4,25 O recurso AMS Automated IAM Provisioning deve ser ativado em suas contas como um recurso opcional.
4.26 As funções ou os usuários assumidos por humanos do AMS não devem ter acesso ao conteúdo do cliente no S3, RDS, DynamoDB, Redshift, Elasticache, EFS e. FSx Além disso, qualquer acesso a um novo e conhecido APIs lançado por terceiros Serviços da AWS que conceda acesso ao conteúdo do cliente deve ser explicitamente negado nas funções de operador.
5.0 Federação
5.1 A autenticação deve ser configurada usando a federação na conta gerenciada do AMS.
5.2 Só deve haver confiança de saída unidirecional do AMS AD para seu Active Directory (o AMS AD confia no AD local).
5.3 Seus repositórios de identidade usados para se autenticar no AMS não devem existir nas contas de aplicativos gerenciados pelo AMS.
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 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 com 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.1 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 Seus recursos devem ser configurados com políticas baseadas em recursos com privilégios mínimos, a menos que você especifique explicitamente uma política diferente.
9.0 Serviços provisionados de autoatendimento (SSPS)
9.1 A função ou política padrão do IAM do AMS (incluindo perfil de instância, SSPS, padrão) não deve ser modificada com ou sem qualquer aceitação de risco. Exceções são permitidas (sem aceitação de risco) para políticas de confiança. A marcação da função, política ou alterações do usuário também é permitida nas funções SSP padrão.
9.3 A política SSPS para a função de console do Systems Manager Automation não pode ser anexada a nenhuma função personalizada além da função padrão. Outras políticas de SSPS só devem ser anexadas a funções personalizadas do IAM depois de garantir que a vinculação da política a uma função personalizada não forneça permissões adicionais fora do design pretendido para o serviço SSPS padrão.

A seguir está o controle padrão para 003 - Network Security:

ID Padrão técnico
Redes
1,0 Todas as EC2 instâncias devem ser acessadas por SSH ou RDP somente por meio de hosts Bastion, do intervalo VPC CIDR do Bastion Host ou do mesmo intervalo de CIDR VPC da instância.
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.
4,0 Todo o tráfego de saída deve passar usando a conta IGW ou TGW.
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 por meio de um 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 A segurança do AMS se refere aos padrões toda vez que é solicitado que um grupo de segurança seja anexado a uma instância.
13.0 O acesso ao bastião do cliente nas portas 3389 e 22 deve ser permitido somente a partir de intervalos de IP privados que são roteados para a VPC via DX, VPC-peer ou VPN.
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 O compartilhamento de regras do resolvedor com Conta da AWS pertencentes ao mesmo cliente é permitido com uma notificação de risco
19,0 ICMP
19.1 A solicitação de ICMP recebida da infraestrutura EC2 do cliente para a Amazon exigirá uma notificação de risco.
19.2 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.
19.3 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.
19,4 A solicitação ICMP de saída da Amazon EC2 para qualquer destino é permitida.
20,0 Compartilhamento de grupos de segurança
20.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.

20.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 004 - Teste de Penetração

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

  2. Os clientes precisam aderir aos testes de penetração.

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

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

  5. O gerenciamento de identidade da infraestrutura de testes do cliente é de responsabilidade do cliente.

O seguinte é o controle padrão para 005 - GuardDuty

  1. GuardDuty deve estar habilitado em todas as contas de clientes em todos os momentos.

  2. GuardDuty As descobertas da Customer Managed Application Account (CMA) no MALZ não resultarão em alarmes para a equipe de operações.

  3. GuardDuty os alertas devem ser armazenados na mesma conta ou em qualquer outra conta gerenciada da mesma organização.

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

  5. GuardDuty a delegação de administrador não deve ser habilitada no MALZ, pois o administrador delegado seria capaz de realizar ações de alto privilégio, como desativá-las GuardDuty em outras contas sem aceitar riscos.

  6. GuardDuty Os filtros de arquivamento automático devem usar o escopo mínimo para obter o máximo retorno. Por exemplo, se o AMS ver vários imprevisíveis IPs em diferentes blocos CIDR e houver um ASN corporativo apropriado para uso, use o ASN. No entanto, se você puder reduzir o escopo para intervalos específicos ou endereços /32, defina o escopo para aqueles.

A seguir está o controle padrão para 006 - Host Security

  • Um agente antivírus deve estar sempre em execução em todas as EC2 instâncias. (por exemplo, Trend Micro DSM).

  • O módulo antimalware deve estar ativado.

  • O agente EPS deve incluir todos os diretórios e arquivos para digitalização.

  • Os arquivos colocados em quarentena pela solução antivírus podem ser compartilhados com você sob demanda.

  • Uma solução de segurança de terminais de terceiros não deve ser instalada.

  • A frequência de atualização da assinatura de antivírus deve ser definida para pelo menos uma vez por dia.

  • A frequência de varredura programada deve ser definida para pelo menos uma vez por mês.

  • A verificação em tempo real (ao acessar) deve estar sempre ativada e em execução.

  • O AMS não deve executar nenhum script personalizado que não seja de propriedade ou de autoria do AMS em suas instâncias. (Observação: você pode fazer isso usando o acesso de administrador da pilha por meio da CT de acesso de administrador da pilha ou usando a AWS Systems Manager automação (AMS SSPS).

  • A Autenticação em Nível de Rede (NLA) não deve ser desativada no host Windows.

  • O sistema operacional do host deve estar atualizado com os patches de segurança mais recentes de acordo com o ciclo de patch configurado.

  • Uma conta gerenciada do AMS não deve ter uma instância não gerenciada na conta.

  • A criação de contas de administrador local em sua instância pelo AMS não deve ser permitida.

  • O par de chaves EC2 ativado não deve ser criado.

  • Você não deve usar sistemas operacionais declarados como Fim da Vida Útil (EOL) e que não haja mais suporte de segurança fornecido pelo fornecedor ou por terceiros.

O seguinte é o controle padrão para 007 - 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.6 Registros do Endpoint Protection System (EPS): o registro da solução EPS deve estar ativado e configurado para entregar os registros a um grupo de CloudWatch registros de registros.
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.1 Você não deve ter acesso de gravação ou exclusão nos buckets do S3 exigidos pelo AMS que armazenam registros e grupos de CloudWatch registros;.
2.2 Você deve ter acesso somente para leitura a todos os registros em suas contas.
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 seu contato de segurança autorizado.
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. A “validação do arquivo de log” deve ser configurada 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 AMS for de propriedade do mesmo cliente do AMS.
6.3 Quaisquer registros de uma conta de cliente não devem ser encaminhados para uma conta de terceiros (que não seja de propriedade do cliente).

O seguinte é o controle padrão para 008 - AMS-MAD

ID Padrão técnico
1.0 Gerenciamento de acesso
1.1 Somente usuários privilegiados do AMS com logins interativos e tarefas de automação devem ter permissão para fazer login no host de gerenciamento para administrar o AD gerenciado nas contas dos clientes.
1.2 Os administradores do AD só devem ter privilégios de administrador delegado (Grupo de Administradores Delegados do AMS).
1.3 Os engenheiros que fazem login nos ambientes AD do cliente (host de gerenciamento ou instâncias) devem ter acesso com limite de tempo.
1.4 Os clientes têm acesso somente de leitura aos objetos do AD usando o Remote Server Administrator Tools em uma EC2 instância.
1.5 Os direitos administrativos para o usuário ou grupo do Active Directory não devem ser permitidos.
1.6 AWS O compartilhamento de diretórios com pessoas Conta da AWS pertencentes ao mesmo cliente é permitido com uma notificação de risco.
2.0 Contas de serviço
2.1 As contas de serviço gerenciadas em grupo (gMSA) devem ser usadas sempre que suportadas pelos aplicativos, em vez da conta de serviço padrão.
2.2 Todas as outras contas de serviço devem ser criadas após o processo de aceitação do risco.
2.3 Os grupos de segurança do AD não devem ser reutilizados, a menos que sejam explicitamente solicitados pelo cliente. Novos grupos do AD devem ser criados. Objetos de computador que solicitam acesso à conta de serviço devem ser adicionados ao novo grupo de segurança.
2.4 Qualquer conta de serviço gMSA deve ser adicionada à Unidade Organizacional (OU) “Conta de Serviço Gerenciada”.
2,5 Qualquer conta de serviço que não seja GMSA deve ser adicionada na OU “Usuários → Contas de serviço”.
3.0 Objetos de política de grupo (GPO)
3.1 Qualquer configuração no GPO “Configurações do Windows > Configurações de segurança” não deve ser modificada se reduzir a postura de segurança da conta de alguma forma em relação ao estado atual.
3.2 No MALZ, RFCs enviado de uma conta de aplicativo solicitando a criação de um GPO, o GPO deve estar vinculado à OU que corresponde à conta do aplicativo. Qualquer GPOs coisa que afete todas as contas deve ser da conta do Shared Service.
3.3 O tempo limite padrão da sessão RDP Idle deve ser definido como 15 minutos para todos os servidores no domínio do Active Directory.
4,0 Confiança do Active Direc
4.1 A confiança de saída unidirecional (diretório hospedado em AMS para diretório de clientes) é IPs permitida se os encaminhadores condicionais forem roteados para a VPC via DX, VPC-peer ou VPN.
5.0 Outros
5.1 O mecanismo de integridade do arquivo de log deve estar ativado. A “validação do arquivo de log” deve ser configurada nas AWS CloudTrail trilhas exigidas pelas equipes do AMS.
6.0 Encaminhamento de registros
6.1 Usuários, grupos, objetos de computador, UO ou outras entidades do cliente não devem usar a convenção de nomenclatura do AMS de acordo com a convenção de nomenclatura do AMS.
6.2 Tudo isso OUs deve ser gerenciado pelo AMS.

O seguinte é o controle padrão para 009 - Diversos

  • Se a criptografia estiver ativada em um recurso, objeto, banco de dados ou sistema de arquivos, ela não deverá ser desativada.