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 Accelerate
Los siguientes son los controles estándar de AMS:
| 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 espera de la sesión RDP para Microsoft Windows Server está establecido en 15 minutos y se puede extender según el caso de uso. |
| 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 | No se deben 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 determinado 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 | En los servidores Microsoft Windows, solo se debe crear una cuenta de servicio gestionada por grupos de Microsoft (gMSA). |
| 4.0 | Políticas, acciones y APIs |
| 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.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.8 | No se deben permitir acciones que cambien 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.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 | El acceso a los ARN de los buckets de S3 que aún no se han creado en las cuentas de los clientes se puede proporcionar restringiendo el acceso a los buckets a las cuentas de los clientes especificando el número de cuenta mediante la clave de condición S3 específica del servicio s3:. ResourceAccount |
| 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 con el AWS servicio como principio de confianza también debe estar en línea con los estándares técnicos 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 | La política de IAM no debería permitir la lectura de objetos (por ejemplo, S3:GetObject) en todos los depósitos de S3 de la cuenta. |
| 4.21 | Todos los permisos de IAM para el tipo de recurso «savingsplan» se pueden conceder a los clientes. |
| 4.22 | El ingeniero de AMS no puede copiar ni mover los datos de los clientes (archivos, objetos S3, bases de datos, etc.) 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. |
| 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.4 | 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 | Los recursos del cliente deben configurarse con políticas basadas en los recursos con privilegios mínimos, a menos que el cliente especifique explícitamente una política diferente. |
El siguiente es el control estándar para el X003: Seguridad de red:
| ID | Norma técnica |
|---|---|
| Redes | |
| 1.0 | Reservado para el control futuro |
| 2.0 | Se permite la IP elástica en EC2 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+. |
| 5.0 | Un grupo de seguridad no debe tener una fuente como 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 un puerto público que no esté enrutado 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, como 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 asumir riesgos. |
| 12.0 | AMS Security hará referencia a los estándares cada vez que se solicite la incorporación de un grupo de seguridad a una instancia. |
| 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 | La solicitud ICMP entrante a Amazon por EC2 parte del cliente infra requerirá una notificación del riesgo. |
| 24,0 | 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. |
| 25.0 | 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. |
| 26,0 | Se permiten solicitudes ICMP salientes desde Amazon EC2 a cualquier destino. |
| 27.0 | Uso compartido de grupos de seguridad |
| 27.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. |
| 27.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 X004: Pruebas de penetración
AMS no admite la infraestructura de pentest. Es responsabilidad del cliente. Por ejemplo, Kali no es una distribución de Linux compatible con AMS.
Los clientes deben cumplir con las pruebas de penetración
. 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.
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.
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 el X005 - GuardDuty
GuardDuty debe estar activado en todas las cuentas de los clientes en todo momento.
GuardDuty las alertas deben almacenarse en la misma cuenta o en cualquier otra cuenta gestionada por la misma organización.
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.
El siguiente es el control estándar para el X007: 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.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.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 del contacto de seguridad autorizado por el cliente. |
| 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. Eso significa configurar la «validación del archivo de registro» 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 puede reenviarse de AMS a una cuenta ajena a una cuenta ajena a AMS únicamente si la cuenta no es propiedad del mismo cliente de AMS (confirmando que tiene la misma AWS Organizations cuenta o haciendo coincidir el dominio del correo electrónico con el nombre de la empresa del cliente y la cuenta vinculada al PAGADOR) mediante herramientas internas. |
