Controles estándar en AMS Advanced - Guía de usuario avanzada de AMS

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Controles estándar en AMS Advanced

Los siguientes son los controles estándar del AMS:

El siguiente es el control estándar para 001: Configuración de etiquetado.

  1. Todos los AWS recursos requeridos por el equipo de AMS para fines operativos y de administración deben tener el siguiente par clave-valor.

    • AppId= AMSInfrastructure

    • Entorno = AMSInfrastructure

    • AppName = AMSInfrastructure

    • AMSResource=Verdadero

  2. Todas las etiquetas requeridas por el equipo de AMS, distintas de las enumeradas anteriormente, deben tener prefijos tal como se menciona en la lista de prefijos de AMS (consulte la nota).

  3. Los valores de etiqueta requeridos por el equipo de AMS (AppIdentorno y AppName) se pueden cambiar en cualquiera de los recursos que haya creado en función de sus solicitudes de cambio.

  4. No debes eliminar ninguna etiqueta de las pilas que AMS requiera en función de tus solicitudes de cambio.

  5. No puede utilizar la convención de nomenclatura de etiquetas AMS para su infraestructura, como se menciona en el punto 2.

  6. Puede hacer que se creen etiquetas personalizadas en los recursos que necesite AMS (normalmente para casos de uso de facturación e informes de costes). Las etiquetas personalizadas se conservan si los recursos se actualizan mediante la actualización de la pila y no mediante la actualización de la plantilla.

nota

Lista de prefijos AMS

  1. ams-*

  2. AWSManagedServicios*

  3. /ams/ *

  4. Ams*

  5. AMS*

  6. Ams*

  7. mc*

  8. MC*

  9. Mc*

  10. centinella*

  11. Centinela*

  12. Servicios_gestionados*

  13. Nuevo AMS*

  14. AWS_*

  15. aws*

  16. VPC_*

  17. CloudTrail*

  18. Cloudtrail*

  19. /aws_reservado/

  20. INGERIR*

  21. EPSDB*

  22. MMS*

  23. TemplateId*

  24. StackSet-ams*

  25. StackSet-Zona de aterrizaje de AWS

  26. IAMPolicy*

  27. cliente-mc-*

  28. Raíz*

  29. LandingZone*

  30. StateMachine*

  31. codedeploy_service_role

  32. host de administración

  33. sentinel.int.

  34. eps

  35. UnhealthyInServiceBastion

  36. ms-

ID Norma técnica
1.0 Duración del tiempo de espera
1.1 El tiempo de espera predeterminado de un usuario federado es de una hora y puede aumentarse hasta cuatro horas.
1.2 El tiempo de acceso predeterminado a la pila es de 12 horas.
2.0 AWS Uso de la cuenta raíz
2.1 Si se utiliza una cuenta raíz por cualquier motivo, Amazon GuardDuty debe estar configurado para generar los resultados pertinentes.
2.2 En el caso de las cuentas de una sola cuenta en la zona de aterrizaje (SALZ) y en las cuentas de administración de varias cuentas de la zona de aterrizaje (MALZ) (anteriormente denominada Master/Billing cuenta), la cuenta del usuario raíz debe tener habilitada la MFA virtual y el token virtual de MFA se descarta durante la incorporación de la cuenta, de modo que ni AMS ni los clientes puedan iniciar sesión como root. Debe seguir el proceso estándar de pérdida de la contraseña AWS raíz junto con su gestor de prestación de servicios en la nube (CSDM) de AMS. Esta configuración debe permanecer durante el ciclo de vida de las cuentas gestionadas por AMS.
2.3 No debe crear claves de acceso para la cuenta raíz.
3.0 Creación y modificación de usuarios
3.1 Se pueden crear IAM users/roles con acceso programático y permisos de solo lectura sin ninguna política de tiempo limitado. Sin embargo, no se permite el permiso para permitir la lectura de objetos (por ejemplo, S3:GetObject) en todos los depósitos de Amazon Simple Storage Service de la cuenta.
3.1.1 Se pueden crear usuarios humanos de IAM para el acceso a la consola y con permisos de solo lectura con la política de límite de tiempo (hasta 180 días), mientras que la política removal/renewal/extension de límite de tiempo limitado generará la notificación de riesgo. Sin embargo, no se permite el permiso para leer objetos (por ejemplo, S3:GetObject) en todos los depósitos de S3 de la cuenta.
3.2 No se deben crear usuarios y roles de IAM para el acceso programático y de consola con permisos que modifiquen la infraestructura (escritura y administración de permisos) en la cuenta del cliente sin una aceptación arriesgada. Existen excepciones para los permisos de escritura a nivel de objeto de S3, que se permiten sin riesgo de aceptación siempre que los segmentos específicos estén dentro del ámbito de aplicación y las operaciones de etiquetado en etiquetas no relacionadas con AMS.
3.3 Los usuarios de IAM con acceso programático, nombrados customer_servicenow_user y customer_servicenow_logging_user necesarios para la ServiceNow integración en la cuenta de aplicación SALZ o MALZ y las *cuentas principales* se pueden crear sin ninguna política de tiempo limitado.
3.4 Los usuarios de IAM con acceso programático, que utilizan customer_cloud_endure_policy y customer_cloud_endure_deny_policy (con acceso de solo lectura) que se requieren para la CloudEndure integración en SALZ pueden crearse cuentas de MALZ, pero necesitan una política de tiempo limitado durante el período de migración planificado. El límite de tiempo puede ser de un período máximo de 180 días sin ningún tipo de RA. El SCP también está autorizado a cambiar las cuentas de MALZ para permitir que estas políticas funcionen durante el período requerido. Usted define los períodos de migración adecuados a sus necesidades y los ajusta según sea necesario.
4.0 Políticas, acciones y APIs
4.1 Todos los usuarios y funciones de IAM en las cuentas de SALZ deben tener incorporada la Política de rechazo de clientes (CDP) predeterminada para proteger la infraestructura de AMS de daños accidentales o intencionados.
4.2 El AMS SCPs debe estar activado en todas las cuentas gestionadas por AMS en MALZ.
4.3 Las identidades capaces de realizar acciones administrativas en las claves de KMS, por ejemplo PutKeyPolicyScheduleKeyDeletion, deben estar restringidas únicamente a los operadores de AMS y a los responsables de automatización.
4.4 Una política no debe proporcionar acceso al administrador con una declaración equivalente a «Efecto»: «Permitir» con «Acción»: «*» en lugar de «Recurso»: «*» sin riesgo de aceptación.
4.5 La política de IAM no debe incluir ninguna acción que incluya la acción Permitir S3: *** en cualquier segmento sin riesgo de aceptación.
4.6 No se deben permitir las llamadas a la API contra las políticas clave de KMS para las claves de infraestructura de AMS en las políticas de IAM del cliente.
4.7 No se deben permitir acciones que eludan el proceso de administración de cambios (RFC), como iniciar o detener la instancia, crear un bucket de S3 o una instancia de RDS, etc.
4.8 No se deben permitir acciones que realicen cambios en los registros DNS de la infraestructura de AMS en Amazon Route 53.
4.9 Los usuarios humanos de IAM con acceso a la consola creados después de seguir el debido proceso no deben tener ninguna política asociada directamente, excepto la política de confianza, el rol y la política de tiempo limitado.
4.10 Se pueden EC2 crear perfiles de instancias de Amazon con acceso de lectura a un secreto o espacio de nombres específico AWS Secrets Manager dentro de la misma cuenta.
4.11 Los permisos de AWS Managed Services Change Management (AMSCM) o AWS Managed Services Service Knowledge Management System (AMSSKMS) se pueden añadir a cualquier función (capacidad de apertura). SR/Incident/RFC
4.12 La política de IAM no debe incluir ninguna acción que incluya la acción Permitir registros (DeleteLogGroup y registros) DeleteLogStream en cualquier grupo de CloudWatch registros de AMS Amazon.
4.13 No se deben permitir los permisos para crear claves multirregionales.
4.14 Para proporcionar acceso a un bucket de S3 ARNs que aún no esté creado en sus cuentas, utilice la clave de condición de S3 específica del servicio s3:ResourceAccount para especificar el número de cuenta.
4.15 Puedes tener acceso a ver, crear, enumerar y eliminar tu panel personalizado, pero solo puedes ver y enumerar en los CloudWatch paneles de Amazon.
4.15.1 Puede ver, crear, enumerar y eliminar el acceso a su panel de control personalizado de S3 Storage Lens.
4.16 Se pueden conceder todos los permisos relacionados con SQL Workbench roles/users para trabajar en las bases de datos de Amazon Redshift.
4.17 Se puede conceder cualquier AWS CloudShell permiso a los roles de los clientes como alternativa a la CLI.
4.18 Una función de IAM Servicio de AWS como director de confianza también debe cumplir con las normas técnicas de la IAM.
4.19 Los roles vinculados a servicios (SLRs) no están sujetos a los estándares técnicos de AMS IAM, ya que los crea y mantiene el equipo de servicio de IAM.
4.20 Las políticas de IAM no deben permitir el acceso de lectura sin restricciones a los objetos del bucket de Amazon S3 (por ejemplo, Amazon S3:GetObject) en todos los buckets de una cuenta:

  • En las cuentas en modo desarrollador: las infracciones dan lugar a una notificación de riesgo

  • En las cuentas que no están en modo desarrollador: las infracciones requieren la aceptación del riesgo

4.21 Todos los permisos de IAM para el tipo de recurso «savingsplan» se pueden conceder a los clientes.
4.22 Los ingenieros de AMS no pueden copiar ni mover los datos de los clientes (archivos, objetos S3, bases de datos) manualmente en ninguno de los servicios de almacenamiento de datos, como Amazon S3, Amazon Relational Database Service, Amazon DynamoDB, etc., ni en el sistema de archivos del sistema operativo.
4.23 La política de SCP no debe modificarse para permitir ningún acceso adicional a ninguna de las cuentas gestionadas por AMS.
4.24 No se debe permitir ningún cambio en la política de SCP que pueda infringir la infraestructura o las capacidades de administración de AMS. (Nota: los recursos de AMS tienen la etiqueta AppId= AMSInfrastructure y siguen el espacio de nombres protegido de AMS).
4.25 La función de aprovisionamiento automatizado de IAM de AMS debe estar habilitada en sus cuentas como una función opcional.
4.26 Los roles o usuarios de AMS asumidos por humanos no deben tener acceso al contenido del cliente en S3, RDS, DynamoDB, Redshift, Elasticache, EFS y. FSx Además, en las funciones de operador se debe denegar explícitamente el acceso a una publicación conocida o nueva APIs publicada por otra persona Servicios de AWS que permita el acceso al contenido de los clientes.
5.0 Federación
5.1 La autenticación debe configurarse mediante la federación en la cuenta gestionada por AMS.
5.2 Solo debe haber una confianza de salida unidireccional entre AMS AD y su Active Directory (AMS AD confía en el AD local).
5.3 Los almacenes de identidades utilizados para autenticarse en AMS no deben existir en las cuentas de aplicaciones gestionadas por AMS.
6.0 Políticas de cuentas cruzadas
6.1 Se pueden configurar las funciones de IAM y las políticas de confianza entre las cuentas de AMS que pertenecen al mismo cliente según los registros de los clientes.
6.2 Las políticas de confianza de los roles de IAM entre las cuentas AMS y las que no son de AMS solo se deben configurar si la cuenta que no es de AMS pertenece al mismo cliente de AMS (confirmando que están bajo la misma AWS Organizations cuenta o haciendo coincidir el dominio de correo electrónico con el nombre de la empresa del cliente).
6.3 Las políticas de confianza de las funciones de IAM entre las cuentas de AMS y las cuentas de terceros no deben configurarse sin correr el riesgo de aceptarlas.
6.4 Se pueden configurar políticas multicuentas para acceder a cualquier cuenta de AMS CMKs del mismo cliente gestionada por un cliente.
6.5 Se pueden configurar políticas multicuenta para acceder a cualquier clave de KMS de una cuenta que no sea de AMS mediante una cuenta de AMS.
6.6 No se deben permitir las políticas multicuenta para acceder a cualquier clave de KMS de una cuenta de AMS por parte de una cuenta de terceros sin una aceptación arriesgada.
6.6.1 Las políticas multicuentas para acceder a cualquier clave de KMS de una cuenta de AMS desde una cuenta que no sea de AMS solo se pueden configurar si la cuenta que no es de AMS es propiedad del mismo cliente de AMS.
6.7 Se pueden configurar políticas multicuenta para acceder a cualquier dato o recurso del bucket de S3 donde se puedan almacenar datos (como Amazon RDS, Amazon DynamoDB o Amazon Redshift) entre cuentas de AMS del mismo cliente.
6.8 Se pueden configurar políticas multicuenta para acceder a cualquier dato o recurso del bucket de S3 donde se puedan almacenar datos (como Amazon RDS, Amazon DynamoDB o Amazon Redshift) en una cuenta que no sea de AMS desde una cuenta de AMS con acceso de solo lectura.
6.9 Las políticas multicuenta para acceder a cualquier dato o recurso del bucket de S3 donde se puedan almacenar datos (como Amazon RDS, Amazon DynamoDB o Amazon Redshift) con permisos de escritura de AMS a una cuenta que no sea de AMS (o de una cuenta que no sea de AMS a AMS) solo deben configurarse si la cuenta que no es de AMS es propiedad del mismo cliente de AMS (confirmando que está en la misma cuenta o haciendo coincidir el dominio de correo electrónico con AWS Organizations el nombre de la empresa del cliente).
6,10 Se pueden configurar políticas multicuenta para acceder a cualquier dato o recurso del bucket de S3 donde se puedan almacenar datos (como Amazon RDS, Amazon DynamoDB o Amazon Redshift) en una cuenta de terceros desde una cuenta de AMS con acceso de solo lectura.
6.11 No se deben configurar políticas multicuenta para acceder a cualquier dato o recurso del bucket de S3 donde se puedan almacenar datos (como Amazon RDS, Amazon DynamoDB o Amazon Redshift) en una cuenta de terceros desde una cuenta de AMS con acceso de escritura.
6.12 Las políticas multicuentas de cuentas de terceros para acceder a un bucket de S3 de un cliente de AMS o a los recursos en los que se puedan almacenar datos (como Amazon RDS, Amazon DynamoDB o Amazon Redshift) no deben configurarse sin una aceptación arriesgada.
7.0 User Groups (Grupos de usuarios)
7.1 Se permiten los grupos de IAM con permisos de solo lectura y no mutativos.
8.0 Políticas basadas en recursos
8.1 Los recursos de la infraestructura de AMS deben protegerse de la administración por parte de identidades no autorizadas mediante la incorporación de políticas basadas en los recursos.
8.2 Sus recursos deben configurarse con políticas basadas en recursos con privilegios mínimos, a menos que especifique explícitamente una política diferente.
9.0 Servicios aprovisionados de autoservicio (SSPS)
9.1 El rol o la política de IAM predeterminados de AMS (incluidos el perfil de la instancia, el SSPS y el patrón) no deben modificarse con o sin ningún riesgo. Se permiten excepciones (sin riesgo de aceptación) a las políticas de confianza. En las funciones predeterminadas del SSP también se permite etiquetar los cambios de rol, política o usuario.
9.3 La política de SSPS para el rol de consola de Systems Manager Automation no se puede adjuntar a ningún rol personalizado aparte del rol predeterminado. Las demás políticas de SSPS solo se deben adjuntar a las funciones de IAM personalizadas después de garantizar que la vinculación de la política a una función personalizada no proporciona permisos adicionales fuera del diseño previsto para el servicio SSPS predeterminado.

El siguiente es el control estándar para 003 - Network Security:

ID Norma técnica
Redes
1.0 Se debe acceder a todas las EC2 instancias mediante SSH o RDP únicamente a través de hosts Bastion, rango CIDR de VPC del host bastión o desde el rango CIDR de VPC de la misma instancia.
2.0 EC2 Se permite la IP elástica en las instancias
3.0 Se debe utilizar el plano de control AMS y, por extensión, en el plano de datos, el TLS 1.2+.
4.0 Todo el tráfico de salida debe pasar por la cuenta IGW o TGW.
5.0 Un grupo de seguridad no debe tener el origen 0.0.0.0/0 en la regla de entrada si no está conectado a un balanceador de cargas según la versión 9.0
6.0 El depósito o los objetos de S3 no deben hacerse públicos sin riesgo de ser aceptados.
7.0 No se debe permitir el acceso a la administración de servidores en los puertos SSH/22 o SSH/2222 (no SFTP/2222), TELNET/23, RDP/3389, WinRM/5985-5986, VNC/ 5900-5901 TS/CITRIX/1494 o 1604, LDAP/389 o 636 y RPC/135, NETBIOS/137-139 desde fuera de la VPC a través de grupos de seguridad.
8.0 No se debe permitir el acceso a la administración de bases de datos en los puertos (MySQL/3306, PostgreSQL/5432, Oracle/1521, MSSQL/1433) o en un puerto personalizado desde el público ni se debe enrutar a una VPC a través de DX, VPC-Peer o una VPN a través de un grupo de seguridad. IPs
8.1 Cualquier recurso en el que se puedan almacenar los datos de los clientes no debe exponerse directamente a la Internet pública.
9.0 El acceso directo a las aplicaciones a través de los puertos HTTP/80, HTTPS/8443 y HTTPS/443 desde Internet solo está permitido a los balanceadores de carga, pero no a ningún recurso de cómputo directamente, por ejemplo, instancias, contenedores, etc. EC2 ECS/EKS/Fargate
10.0 Se puede permitir el acceso de las aplicaciones a través de los puertos HTTP/80 y HTTPS/443 desde el rango de IP privadas del cliente.
11.0 No se debe permitir ningún cambio en los grupos de seguridad que controlan el acceso a la infraestructura de AMS sin que ello suponga un riesgo.
12.0 AMS Security hace referencia a los estándares cada vez que se solicita que un grupo de seguridad se adjunte a una instancia.
13.0 El acceso al bastión del cliente en los puertos 3389 y 22 solo debe permitirse desde los rangos de IP privadas que se enruten a la VPC a través de DX, VPC-peer o VPN.
14.0 La asociación entre cuentas de zonas alojadas privadas VPCs desde una cuenta de AMS a una cuenta que no es de AMS (o que no es de AMS a una cuenta de AMS) solo debe configurarse si la cuenta que no es de AMS es propiedad del mismo cliente de AMS (confirmando que están bajo la misma cuenta de la organización de AWS o haciendo coincidir el dominio de correo electrónico con el nombre de la empresa del cliente) mediante herramientas internas.
15.0 Se pueden permitir las conexiones de emparejamiento de VPC entre cuentas que pertenecen al mismo cliente.
16.0 La base de AMS se AMIs puede compartir con cuentas ajenas a AMS siempre que ambas cuentas sean propiedad del mismo cliente (confirmando que están bajo la misma AWS Organizations cuenta o haciendo coincidir el dominio de correo electrónico con el nombre de la empresa del cliente) mediante herramientas internas.
17.0 El puerto FTP 21 no debe configurarse en ninguno de los grupos de seguridad sin una aceptación del riesgo.
18.0 Se permite la conectividad de red entre cuentas a través de Transit Gateway siempre que todas las cuentas sean propiedad del cliente.
19.0 No está permitido convertir una subred privada en pública
20.0 No se deben permitir las conexiones de emparejamiento de VPC con cuentas de terceros (que no sean propiedad del cliente).
21.0 No se debe permitir la conexión de Transit Gateway a una cuenta de terceros (que no sea propiedad del cliente).
22.0 El tráfico de red necesario para que AMS preste los servicios a los clientes no debe bloquearse en el punto de salida de la red del cliente.
23.0 Se permite compartir las reglas de resolución con aquellas que Cuenta de AWS sean propiedad del mismo cliente mediante una notificación de riesgo
19.0 ICMP
19,1 La solicitud ICMP entrante a Amazon por EC2 parte del cliente infra requerirá una notificación del riesgo.
19.2 Se permiten las solicitudes entrantes del público IPs enrutadas a Amazon VPC a través de DX, VPC-peer o VPN a través de un grupo de seguridad.
19.3 Las solicitudes entrantes del público que IPs no se enruten a Amazon VPC a través de DX, VPC-peer o VPN a través de un grupo de seguridad requerirían una aceptación de riesgo.
19.4 Se permiten solicitudes ICMP salientes desde Amazon EC2 a cualquier destino.
20.0 Uso compartido de grupos de seguridad
20.1

Si un grupo de seguridad cumple con este estándar de seguridad, se puede compartir entre cuentas VPCs de la misma cuenta y entre cuentas de la misma organización.

20.2

Si un grupo de seguridad no cumple con este estándar y anteriormente se requería la aceptación del riesgo para este grupo de seguridad, no se permite el uso de la función de uso compartido de grupos de seguridad entre la misma cuenta o entre cuentas de la misma organización sin la aceptación del riesgo para esa nueva VPC o cuenta. VPCs

El siguiente es el control estándar para el 004: Pruebas de penetración

  1. AMS no admite la infraestructura de pentest. Es responsabilidad del cliente. Por ejemplo, Kali no es una distribución de Linux compatible con AMS.

  2. Los clientes deben cumplir con las pruebas de penetración.

  3. En caso de que el cliente desee realizar pruebas de penetración de la infraestructura en las cuentas, se debe avisar previamente a AMS con 24 horas de antelación.

  4. AMS proporcionará al cliente una infraestructura de pentesting según los requisitos del cliente que se especifiquen explícitamente en la solicitud de cambio o servicio presentada por el cliente.

  5. La gestión de la identidad de la infraestructura de pentesting del cliente es responsabilidad del cliente.

El siguiente es el control estándar para 005 - GuardDuty

  1. GuardDuty debe estar activado en todas las cuentas de los clientes en todo momento.

  2. GuardDuty Los resultados de la cuenta de aplicaciones gestionada por el cliente (CMA) en MALZ no generarán alarmas para el equipo de operaciones.

  3. GuardDuty las alertas deben almacenarse en la misma cuenta o en cualquier otra cuenta gestionada de la misma organización.

  4. No se GuardDuty debe utilizar la función de lista de IP confiables de. En su lugar, se puede utilizar el archivado automático como alternativa, lo que resulta útil para fines de auditoría.

  5. GuardDuty La delegación de administradores no debe estar habilitada en MALZ, ya que el administrador delegado podría realizar acciones con altos privilegios, como deshabilitar las demás cuentas, sin correr el riesgo GuardDuty de aceptarlas.

  6. GuardDuty Los filtros de archivado automático deben utilizar el alcance mínimo para obtener el máximo rendimiento. Por ejemplo, si AMS ve varios bloques impredecibles IPs en distintos bloques de CIDR y hay un ASN corporativo que es adecuado utilizar, utilice el ASN. Sin embargo, si puedes limitar el alcance a rangos específicos o a /32 direcciones, entonces acércate a esos rangos.

El siguiente es el control estándar para 006 - Host Security

  • Debe haber un agente antivirus en ejecución en todas las EC2 instancias y en todo momento. (por ejemplo, Trend Micro DSM).

  • El módulo antimalware debe estar activado.

  • El agente EPS debe incluir todos los directorios y archivos que se van a escanear.

  • Los archivos puestos en cuarentena por la solución antivirus se pueden compartir con usted cuando lo desee.

  • No se debe instalar una solución de seguridad para terminales de terceros.

  • La frecuencia de actualización de las firmas antivirus debe configurarse como mínimo una vez al día.

  • La frecuencia de escaneo programada debe configurarse como mínimo una vez al mes.

  • El escaneo en tiempo real (en tiempo real) debe estar activado y en funcionamiento en todo momento.

  • AMS no debe ejecutar ningún script personalizado que no sea propiedad de AMS ni esté creado por AMS en sus instancias. (Nota: Puede hacerlo mediante el acceso de administrador de pila a través del acceso de administrador de pila CT o mediante la AWS Systems Manager automatización (AMS SSPS).

  • La autenticación a nivel de red (NLA) no debe estar deshabilitada en el host de Windows.

  • El sistema operativo host debe estar actualizado con los últimos parches de seguridad según el ciclo de parches configurado.

  • Una cuenta gestionada por AMS no debe tener una instancia no gestionada en la cuenta.

  • No debe permitirse la creación de cuentas de administrador local en su instancia por parte de AMS.

  • No se EC2 debe crear el par de claves activado.

  • No debe utilizar sistemas operativos declarados al final de su vida útil (EOL) y el proveedor o un tercero no proporcionan ningún otro soporte de seguridad.

El siguiente es el control estándar para 007: Registro

ID Norma técnica
1.0 Tipos de registro
1.1 Registros del sistema operativo: todos los hosts deben registrar como mínimo los eventos de autenticación del host, los eventos de acceso para todos los usos de privilegios elevados y los eventos de acceso para todos los cambios en la configuración de acceso y privilegios, tanto si se realizan correctamente como si no.
1.2 AWS CloudTrail: el registro CloudTrail de eventos de administración debe estar habilitado y configurado para enviar los registros a un bucket de S3.
1.3 Registros de flujo de VPC: todos los registros de tráfico de red deben registrarse mediante registros de flujo de VPC.
1.4 Registro de acceso al servidor Amazon S3: los buckets S3 obligatorios por AMS que almacenan registros deben tener habilitado el registro de acceso al servidor.
1.5 AWS Config Instantáneas: AWS Config deben registrar los cambios de configuración de todos los recursos compatibles en todas las regiones y entregar los archivos de instantáneas de configuración a los depósitos de S3 al menos una vez al día.
1.6 Registros del Endpoint Protection System (EPS): el registro de la solución EPS debe estar habilitado y configurado para enviar los registros a un grupo de CloudWatch registros.
1.7 Registros de aplicaciones: los clientes pueden habilitar el inicio de sesión en sus aplicaciones y almacenarlos en un grupo de CloudWatch registros o en un depósito de S3.
1.8 Registro a nivel de objeto de S3: los clientes pueden habilitar el registro a nivel de objeto en sus depósitos de S3.
1.9 Registro de servicios: los clientes pueden habilitar y reenviar los registros de los servicios de SSPS como cualquier otro servicio principal.
1.10 Registros de Elastic Classic/Application Load Balancer/Network Load Balancing (Load Balancer): las entradas de los registros de acceso y errores deben almacenarse en los buckets S3 gestionados por AMS 2.0.
2.0 Control de acceso
2.1 No debe tener acceso de escritura o eliminación en los depósitos de S3 necesarios para AMS que almacenan registros y CloudWatch registros (grupos de registros).
2.2 Debe tener acceso de solo lectura a todos los registros de sus cuentas.
2.3 Los depósitos S3 exigidos por AMS que almacenan registros no deben permitir el uso de cuentas de terceros como norma en las políticas de los depósitos.
2.4 Los registros de CloudWatch los grupos de registros de Logs no se deben eliminar sin la aprobación explícita de su contacto de seguridad autorizado.
3.0 Retención de registros
3.1 Los grupos de CloudWatch registros exigidos por AMS deben tener un período de retención mínimo de 90 días en los registros.
3.2 Los depósitos S3 exigidos por AMS que almacenan los registros deben tener un período de retención mínimo de 18 meses.
3.3 AWS Backup las instantáneas deberían estar disponibles con una retención mínima de 31 días en los recursos compatibles.
4.0 Cifrado
4.1 El cifrado debe estar habilitado en todos los depósitos de S3 que necesiten los equipos de AMS que almacenen los registros.
4.2 Cualquier reenvío de registros desde las cuentas de los clientes a cualquier otra cuenta debe estar cifrado.
5.0 Integridad
5.1 El mecanismo de integridad del archivo de registro debe estar activado. La «validación del archivo de registro» debe estar configurada en las AWS CloudTrail rutas requeridas por los equipos de AMS.
6.0 Reenvío de registros
6.1 Cualquier registro se puede reenviar de una cuenta AMS a otra cuenta AMS del mismo cliente.
6.2 Cualquier registro se puede reenviar de AMS a una cuenta que no sea de AMS solo si la cuenta que no es de AMS es propiedad del mismo cliente de AMS.
6.3 Los registros de una cuenta de cliente no deben reenviarse a una cuenta de terceros (que no sea propiedad del cliente).

El siguiente es el control estándar para 008 - AMS-MAD

ID Norma técnica
1.0 Administración de accesos
1.1 Solo los usuarios con privilegios de AMS con inicios de sesión interactivos y tareas de automatización deben poder iniciar sesión en el host de administración para administrar el AD administrado en las cuentas de los clientes.
1.2 Los administradores de AD solo deben tener privilegios de administrador delegado (grupo de administradores delegados de AMS).
1.3 Los ingenieros que inicien sesión en los entornos de AD de los clientes (instancias o hosts de administración) deben tener un acceso limitado en el tiempo.
1.4 En una EC2 instancia, los clientes tienen acceso de solo lectura a los objetos de AD mediante las herramientas de administración remota del servidor.
1.5 No se deben permitir derechos administrativos al usuario o grupo de Active Directory.
1.6 AWS Se permite compartir el directorio con un Cuenta de AWS propietario del mismo cliente con una notificación de riesgo.
2.0 Cuentas de servicio
2.1 Las cuentas de servicios gestionados grupales (gMSA) se deben usar siempre que las aplicaciones las admitan en lugar de la cuenta de servicio estándar.
2.2 Todas las demás cuentas de servicio deben crearse después del proceso de aceptación del riesgo.
2.3 Los grupos de seguridad de AD no se deben reutilizar a menos que el cliente lo solicite explícitamente. Se deben crear nuevos grupos de AD. Los objetos informáticos que soliciten acceso a la cuenta de servicio deben agregarse al nuevo grupo de seguridad.
2.4 Todas las cuentas de servicio de gMSA deben añadirse a la unidad organizativa (OU) «Cuenta de servicio gestionada».
2,5 Todas las cuentas de servicio que no sean de GMSA deben agregarse a la OU «Usuarios→Cuentas de servicio».
3.0 Objetos de política de grupo (GPO)
3.1 No se debe modificar ninguna configuración del GPO «Configuración de Windows > Configuración de seguridad» si reduce la seguridad de la cuenta de alguna manera con respecto al estado actual.
3.2 En MALZ, que RFCs se envía desde una cuenta de aplicación que solicita la creación de un GPO, el GPO debe estar vinculado a la OU correspondiente a la cuenta de la aplicación. Los GPOs que afecten a todas las cuentas deben provenir de la cuenta de servicio compartido.
3.3 El tiempo de espera predeterminado de la sesión inactiva de RDP debe establecerse en 15 minutos para todos los servidores del dominio de Active Directory.
4.0 Confianza en Active Directory
4.1 Se permite la confianza saliente unidireccional (del directorio al directorio de clientes hospedado por AMS) si los reenviadores condicionales se enrutan a una VPC a través IPs de DX, VPC-peer o VPN.
5.0 Otros
5.1 El mecanismo de integridad del archivo de registro debe estar activado. La «validación del archivo de registro» debe estar configurada en las AWS CloudTrail rutas requeridas por los equipos de AMS.
6.0 Reenvío de registros
6.1 Los usuarios, grupos, objetos informáticos, unidades organizativas u otras entidades del cliente no deben utilizar la convención de nomenclatura de AMS según la convención de nomenclatura de AMS.
6.2 Todo OUs debe ser gestionado por AMS.

El siguiente es el control estándar para 009 - Miscelánea

  • Si el cifrado está activado en un recurso, objeto, base de datos o sistema de archivos, no debe deshabilitarse.