Control de seguridad: Administración de identidades

  • Artículo

Administración de identidades cubre controles que establecen una identidad segura y controles de acceso mediante sistemas de administración de identidad y acceso, incluido el uso del inicio de sesión único, la autenticación segura, las identidades administradas (y las entidades de servicio) para las aplicaciones, el acceso condicional y la supervisión de anomalías en las cuentas.

IM-1: Uso de una identidad centralizada y un sistema de autenticación

Id. de CIS Controls v8 Identificadores de NIST SP 800-53 r4 Id. de PCI-DSS v3.2.1
6.7, 12.5 AC-2, AC-3, IA-2, IA-8 7.2, 8.3

Principio de seguridad: use un sistema centralizado de identidades y autenticación para controlar las identidades y autenticaciones de la organización para los recursos en la nube y que no son de nube.

Guía de Azure: Azure Active Directory (Azure AD) es el servicio de administración de identidades y autenticación de Azure. Debe normalizar el uso de Azure AD para controlar las identidades y autenticación de la organización en:

  • Recursos en la nube de Microsoft, como Azure Storage, Azure Virtual Machines (Linux y Windows), azure Key Vault, PaaS y aplicaciones SaaS.
  • Los recursos de la organización, como aplicaciones en Azure, aplicaciones de terceros que se ejecutan en los recursos de la red corporativa y aplicaciones SaaS de terceros.
  • Las identidades empresariales de Active Directory mediante sincronización con Azure AD para garantizar una estrategia de identidad coherente y administrada de forma centralizada.

Para los servicios de Azure que se aplican, evite el uso de métodos de autenticación local y, en su lugar, use Azure Active Directory para centralizar las autenticaciones de servicio.

Nota: Tan pronto como sea técnicamente posible, debe migrar las aplicaciones basadas en Active Directory local a Azure AD. Podría ser un directorio de empresa de Azure AD, una configuración de negocio a negocio, o una configuración de negocio a consumidor.

Implementación de Azure y contexto adicional:

Guía de AWS: AWS IAM (Administración de identidades y acceso) es el servicio de administración de identidades y autenticación predeterminado de AWS. Use AWS IAM para controlar la administración de identidades y acceso de AWS. Como alternativa, a través de AWS y Azure Single Sign-On (SSO), también puede usar Azure AD para administrar la identidad y el control de acceso de AWS para evitar la administración de cuentas duplicadas por separado en dos plataformas en la nube.

AWS admite single Sign-On que le permite enlazar las identidades de terceros de su empresa (como Windows Active Directory u otros almacenes de identidades) con las identidades de AWS para evitar crear cuentas duplicadas para acceder a los recursos de AWS.

Implementación de AWS y contexto adicional:

Guía de GCP: el sistema de administración de identidades y acceso (IAM) de Google Cloud es el servicio de administración de identidades y autenticación predeterminado de Google Cloud que se usa para las cuentas de Google Cloud Identity. Use Google Cloud IAM para controlar la administración de identidades y acceso de GCP. Como alternativa, a través de Google Cloud Identity y Azure Sigle Sign-On (SSO), también puede usar Azure AD para administrar la identidad y el control de acceso de GCP para evitar la administración de cuentas duplicadas por separado en un entorno en la nube demutli.

Google Cloud Identity es el proveedor de identidades para todos los servicios de Google. Admite single Sign-On que le permite enlazar las identidades de terceros de su empresa (como Windows Active Directory u otros almacenes de identidades) con identidades de Google Cloud para evitar crear cuentas duplicadas para acceder a los recursos de GCP.

Nota: Uso de Google Cloud Directory Sync. Google proporciona una herramienta de conector que se integra con la mayoría de los sistemas de administración LDAP empresariales y sincroniza las identidades según una programación. Mediante la configuración de una cuenta de Cloud Identity y la sincronización de Google Cloud Directory Sync, puede configurar cuáles de las cuentas de usuario (incluidos los usuarios, grupos y perfiles de usuario, alias y mucho más) se sincronizarán según una programación entre el sistema de administración de identidades local y el sistema GCP.

Implementación de GCP y contexto adicional:

Partes interesadas de la seguridad del cliente (más información):

IM-2: Protección del sistema de identidad y autenticación

Id. de CIS Controls v8 Identificadores de NIST SP 800-53 r4 Id. de PCI-DSS v3.2.1
5.4, 6.5 AC-2, AC-3, IA-2, IA-8, SI-4 8.2, 8.3

Principio de seguridad: proteja su identidad y el sistema de autenticación como prioridad alta en la práctica de seguridad en la nube de la organización. Controles de seguridad comunes incluyen:

  • Restricción de roles y cuentas con privilegios
  • Exigencia de autenticación sólida para todo el acceso con privilegios
  • Supervisión y auditoría de actividades de alto riesgo

Guía de Azure: use la línea de base de seguridad de Azure AD y la puntuación de seguridad de Identidad de Azure AD para evaluar la posición de seguridad de la identidad de Azure AD y corregir las brechas de seguridad y configuración. La puntuación segura de identidad de Azure AD evalúa Azure AD para las siguientes configuraciones:

  • Uso de roles administrativos limitados
  • Activar la directiva de riesgo de usuario
  • Designar más de un administrador global
  • Habilitar la directiva para bloquear la autenticación heredada
  • Garantizar que todos los usuarios pueden completar la autenticación multifactor para el acceso seguro
  • Requerir MFA para roles administrativos
  • Habilitar el autoservicio de restablecimiento de contraseña
  • No expirar las contraseñas
  • Activar la directiva de riesgo de inicio de sesión
  • No permitir que los usuarios concedan acceso a aplicaciones no administradas

Use Azure AD Identity Protection para detectar, investigar y corregir los riesgos basados en identidades. Para proteger de forma similar el dominio de Active Directory local, use Defender for Identity.

Nota: Siga los procedimientos recomendados publicados para todos los demás componentes de identidad, incluidos los Active Directory local y las funcionalidades de terceros, y las infraestructuras (como sistemas operativos, redes, bases de datos) que las hospedan.

Implementación de Azure y contexto adicional:

Guía de AWS: Use los siguientes procedimientos recomendados de seguridad para proteger su IAM de AWS:

  • Configure las claves de acceso de usuario raíz de la cuenta de AWS para el acceso de emergencia, tal y como se describe en PA-5 (Configuración del acceso de emergencia)
  • Siga los principios de privilegios mínimos para las asignaciones de acceso.
  • Aproveche los grupos de IAM para aplicar directivas en lugar de usuarios individuales.
  • Siga las instrucciones de autenticación sólida en IM-6 (Usar controles de autenticación seguros) para todos los usuarios.
  • Uso de SCP de AWS Organizations (directiva de control de servicios) y límites de permisos
  • Uso del Asesor de acceso de IAM para auditar el acceso al servicio
  • Uso del informe de credenciales de IAM para realizar un seguimiento de las cuentas de usuario y el estado de las credenciales

Nota: Siga los procedimientos recomendados publicados si tiene otros sistemas de identidad y autenticación, por ejemplo, siga la línea de base de seguridad de Azure AD si usa Azure AD para administrar la identidad y el acceso de AWS.

Implementación de AWS y contexto adicional:

Guía de GCP: use los siguientes procedimientos recomendados de seguridad para proteger los servicios de Google Cloud IAM e Cloud Identity para sus organizaciones:

  • Configure una cuenta de superadministrador para el acceso de emergencia siguiendo las recomendaciones de PA-5 ("Configurar el acceso de emergencia").
  • Cree una dirección de correo electrónico de superadministrador (como la cuenta de superadministrador de Google Workspace o Cloud Identity) y esta cuenta no debe ser específica de un usuario determinado en caso de que se necesite una recuperación de emergencia.
  • Seguir los principios de privilegios mínimos y separación de obligaciones
  • Evitar el uso de la cuenta de superadministrador para las actividades diarias
  • Aproveche los grupos de Google Cloud Identity para aplicar directivas en lugar de aplicar directivas a usuarios individuales.
  • Siga las instrucciones de autenticación sólida como se describe en IM-6 ("Usar controles de autenticación seguros") para todos los usuarios que tienen privilegios elevados.
  • Uso de directivas de IAM para restringir el acceso a los recursos
  • Usar el servicio de directivas de organización para controlar y configurar restricciones en los recursos
  • Uso del registro de auditoría de IAM en los registros de auditoría en la nube para revisar las actividades con privilegios

Nota: Siga los procedimientos recomendados publicados si tiene otros sistemas de identidad y autenticación, por ejemplo, siga la línea de base de seguridad de Azure AD si usa Azure AD para administrar la identidad y el acceso de GCP.

Implementación de GCP y contexto adicional:

Partes interesadas de la seguridad del cliente (más información):

IM-3: Administración de identidades de aplicaciones de forma segura y automática

Id. de CIS Controls v8 Identificadores de NIST SP 800-53 r4 Id. de PCI-DSS v3.2.1
N/D AC-2, AC-3, IA-4, IA-5, IA-9 N/D

Principio de seguridad: use identidades de aplicación administradas en lugar de crear cuentas humanas para que las aplicaciones accedan a los recursos y ejecuten código. Las identidades de aplicación administradas proporcionan ventajas, como la reducción de la exposición de las credenciales. Automatice la rotación de credenciales para garantizar la seguridad de las identidades.

Guía de Azure: use identidades administradas de Azure, que se pueden autenticar en servicios y recursos de Azure que admiten la autenticación de Azure AD. La plataforma administra totalmente, rota y protege las credenciales de identidad administrada, lo que evita las credenciales codificadas de forma rígida en el código fuente o en los archivos de configuración.

En el caso de los servicios que no admiten identidades administradas, use Azure AD para crear entidades de servicio con permisos restringidos a nivel de recurso. Se recomienda configurar entidades de servicio con credenciales de certificado y revertir a secretos de cliente para la autenticación.

Implementación de Azure y contexto adicional:

Guía de AWS: use roles de IAM de AWS en lugar de crear cuentas de usuario para recursos que admitan esta característica. Los roles de IAM se administran mediante la plataforma en el back-end y las credenciales son temporales y se rotan automáticamente. Esto evita la creación de claves de acceso a largo plazo o un nombre de usuario o contraseña para aplicaciones y credenciales codificadas de forma rígida en el código fuente o los archivos de configuración.

Puede usar roles vinculados a servicios que están asociados a directivas de permisos predefinidas para el acceso entre servicios de AWS en lugar de personalizar sus propios permisos de rol para los roles de IAM.

Nota: Para los servicios que no admiten roles de IAM, use claves de acceso, pero siga el procedimiento recomendado de seguridad, como IM-8 Restringir la exposición de credenciales y secretos para proteger las claves.

Implementación de AWS y contexto adicional:

Guía de GCP: use cuentas de servicio administradas por Google en lugar de crear cuentas administradas por el usuario para los recursos que admiten esta característica. Las cuentas de servicio administradas por Google se administran mediante la plataforma en el back-end y las claves de la cuenta de servicio son temporales y se rotan automáticamente. Esto evita la creación de claves de acceso a largo plazo o un nombre de usuario o contraseña para aplicaciones y credenciales codificadas de forma rígida en archivos de configuración o código fuente.

Use la inteligencia de directivas para comprender y reconocer actividades sospechosas para las cuentas de servicio.

Implementación de GCP y contexto adicional:

Partes interesadas de la seguridad del cliente (más información):

IM-4: Autenticación de servidores y servicios

Id. de CIS Controls v8 Identificadores de NIST SP 800-53 r4 Id. de PCI-DSS v3.2.1
N/A IA-9 N/D

Principio de seguridad: autentique los servicios y servidores remotos del lado cliente para asegurarse de que se está conectando a servicios y servidores de confianza. El protocolo de autenticación de servidores más común es Seguridad de la capa de transporte (TLS), donde el lado cliente (a menudo un explorador o dispositivo cliente) comprueba el servidor mediante la verificación de que el certificado del servidor ha sido emitido por una entidad de certificación de confianza.

Nota: La autenticación mutua se puede usar cuando el servidor y el cliente se autentican entre sí.

Guía de Azure: muchos servicios de Azure admiten la autenticación TLS de forma predeterminada. En el caso de los servicios que no admiten la autenticación TLS de forma predeterminada o que admiten la deshabilitación de TLS, asegúrese de que siempre está habilitado para admitir la autenticación de servidor o cliente. La aplicación cliente también debe diseñarse para comprobar la identidad del servidor o cliente (comprobando el certificado del servidor emitido por una entidad de certificación de confianza) en la fase de protocolo de enlace.

Nota: Los servicios como API Management y LA puerta de enlace de API admiten la autenticación mutua tls.

Implementación de Azure y contexto adicional:

Guía de AWS: muchos servicios de AWS admiten la autenticación TLS de forma predeterminada. En el caso de los servicios que no admiten la autenticación TLS de forma predeterminada o que admiten la deshabilitación de TLS, asegúrese de que siempre está habilitado para admitir la autenticación de servidor o cliente. La aplicación cliente también debe diseñarse para comprobar la identidad del servidor o cliente (comprobando el certificado del servidor emitido por una entidad de certificación de confianza) en la fase de protocolo de enlace.

Nota: Los servicios como API Gateway admiten la autenticación mutua tls.

Implementación de AWS y contexto adicional:

Guía de GCP: muchos servicios de GCP admiten la autenticación TLS de forma predeterminada. En el caso de los servicios que no admiten esto de forma predeterminada o que admiten la deshabilitación de TLS, asegúrese de que siempre está habilitado para admitir la autenticación de servidor o cliente. La aplicación cliente también debe diseñarse para comprobar la identidad del servidor o cliente (comprobando el certificado del servidor emitido por una entidad de certificación de confianza) en la fase de protocolo de enlace.

Nota: Los servicios como El equilibrio de carga en la nube admiten la autenticación mutua tls.

Implementación de GCP y contexto adicional:

Partes interesadas de la seguridad del cliente (más información):

IM-5: Uso del inicio de sesión único (SSO) para acceder a las aplicaciones

Id. de CIS Controls v8 Identificadores de NIST SP 800-53 r4 Id. de PCI-DSS v3.2.1
12.5 IA-4, IA-2, IA-8 N/D

Principio de seguridad: use el inicio de sesión único (SSO) para simplificar la experiencia del usuario para autenticarse en recursos, incluidas las aplicaciones y los datos de los servicios en la nube y los entornos locales.

Guía de Azure: use Azure AD para el acceso a aplicaciones de carga de trabajo (orientado al cliente) a través del inicio de sesión único (SSO) de Azure AD, lo que reduce la necesidad de cuentas duplicadas. Azure AD proporciona administración de identidades y acceso a los recursos de Azure (en el plano de administración, incluida la CLI, PowerShell, el portal), las aplicaciones en la nube y las aplicaciones locales.

Azure AD también admite el inicio de sesión único para identidades empresariales, como identidades de usuario corporativos, así como identidades de usuario externos de usuarios públicos y de terceros de confianza.

Implementación de Azure y contexto adicional:

Guía de AWS: Use AWS Cognito para administrar las cargas de trabajo de las aplicaciones orientadas al cliente a través del inicio de sesión único (SSO) para permitir a los clientes puenter sus identidades de terceros de diferentes proveedores de identidades.

Para el acceso de inicio de sesión único a los recursos nativos de AWS (incluido el acceso de la consola de AWS o el acceso de nivel de plano de datos o la administración de servicios y el acceso al plano de datos), use AWS Sigle Sign-On para reducir la necesidad de cuentas duplicadas.

AWS SSO también le permite enlazar identidades corporativas (como identidades de Azure Active Directory) con identidades de AWS, así como identidades de usuario externos de usuarios públicos y de terceros de confianza.

Implementación de AWS y contexto adicional:

Guía de GCP: use Google Cloud Identity para administrar el acceso a la aplicación de carga de trabajo orientada al cliente a través del inicio de sesión único de Google Cloud Identity, lo que reduce la necesidad de cuentas duplicadas. Google Cloud Identity proporciona administración de identidades y acceso a GCP (en el plano de administración, incluida la CLI de Google Cloud, el acceso a la consola), las aplicaciones en la nube y las aplicaciones locales.

Google Cloud Identity también admite el inicio de sesión único para identidades empresariales, como identidades de usuario corporativos de Azure AD o Active Directory, así como identidades de usuario externos de usuarios públicos y de terceros de confianza. Implementación de GCP y contexto adicional:

Partes interesadas de la seguridad del cliente (más información):

IM-6: Uso de controles de autenticación sólida

Id. de CIS Controls v8 Identificadores de NIST SP 800-53 r4 Id. de PCI-DSS v3.2.1
6.3, 6.4 AC-2, AC-3, IA-2, IA-5, IA-8 7.2, 8.2, 8.3, 8.4

Principio de seguridad: aplique controles de autenticación seguros (autenticación segura sin contraseña o autenticación multifactor) con el sistema centralizado de administración de identidades y autenticación para todo el acceso a los recursos. La autenticación basada solo en credenciales con contraseña se considera heredada, ya que no es segura y no soporta métodos de ataque populares.

Al implementar la autenticación sólida, configure primero los administradores y usuarios con privilegios para garantizar el mayor nivel del método de autenticación sólida, seguido rápidamente de la implementación de la directiva de autenticación sólida adecuada para todos los usuarios.

Nota: Si se requiere la autenticación heredada basada en contraseñas para aplicaciones y escenarios heredados, asegúrese de que se sigan los procedimientos recomendados de seguridad con contraseña, como los requisitos de complejidad.

Guía de Azure: Azure AD admite controles de autenticación seguros a través de métodos sin contraseña y autenticación multifactor (MFA).

  • Autenticación sin contraseña: Use la autenticación sin contraseña como método de autenticación predeterminado. Hay tres opciones disponibles en la autenticación sin contraseña: Windows Hello para empresas, inicio de sesión telefónico de la aplicación Microsoft Authenticator y claves de seguridad FIDO2. Además, los clientes pueden usar métodos de autenticación locales, como tarjetas inteligentes.
  • Autenticación multifactor: Azure MFA se puede exigir a todos los usuarios, a usuarios concretos o por usuario en función de los factores de riesgo y las condiciones de inicio de sesión. Habilite Azure MFA y siga Microsoft Defender recomendaciones de administración de identidades y acceso en la nube para la configuración de MFA.

Si la autenticación heredada basada en contraseña todavía se usa para la autenticación de Azure AD, recuerde que las cuentas solo en la nube (cuentas de usuario creadas directamente en Azure) tienen una directiva de contraseñas de base de referencia predeterminada. Además, las cuentas híbridas (cuentas de usuario que proceden de Active Directory local) siguen las directivas de contraseñas locales.

En el caso de las aplicaciones y servicios de terceros que pueden tener identificadores y contraseñas predeterminados, debe deshabilitarlos o cambiarlos durante la configuración inicial del servicio.

Implementación de Azure y contexto adicional:

Guía de AWS: AWS IAM admite controles de autenticación seguros a través de la autenticación multifactor (MFA). MFA se puede aplicar a todos los usuarios, seleccionar usuarios o en el nivel por usuario en función de las condiciones definidas.

Si usa cuentas corporativas de un directorio de terceros (como Windows Active Directory) con identidades de AWS, siga las instrucciones de seguridad correspondientes para aplicar una autenticación segura. Consulte la Guía de Azure para este control si usa Azure AD para administrar el acceso a AWS.

Nota: En el caso de aplicaciones de terceros y servicios de AWS que pueden tener identificadores y contraseñas predeterminados, debe deshabilitarlos o cambiarlos durante la configuración inicial del servicio.

Implementación de AWS y contexto adicional:

Guía de GCP: Google Cloud Identity admite controles de autenticación seguros a través de la autenticación multifactor (MFA). MFA se puede aplicar a todos los usuarios, seleccionar usuarios o en el nivel por usuario en función de las condiciones definidas. Para proteger las cuentas de superadministrador de Identidad en la nube (y área de trabajo), considere la posibilidad de usar claves de seguridad y el Programa de protección avanzada de Google para obtener la máxima seguridad.

Si usa cuentas corporativas de un directorio de terceros (como Windows Active Directory) con identidades de Google Cloud, siga las instrucciones de seguridad correspondientes para aplicar la autenticación segura. Consulte la Guía de Azure para este control si usa Azure AD para administrar el acceso a Google Cloud.

Use Identity-Aware Proxy para establecer una capa de autorización central para las aplicaciones a las que accede HTTPS, por lo que puede usar un modelo de control de acceso de nivel de aplicación en lugar de basarse en firewalls de nivel de red.

Nota: En el caso de aplicaciones de terceros y servicios GCP que pueden tener identificadores y contraseñas predeterminados, debe deshabilitarlos o cambiarlos durante la configuración inicial del servicio.

Implementación de GCP y contexto adicional:

Partes interesadas de la seguridad del cliente (más información):

IM-7: Restricción del acceso a los recursos en función de las condiciones

Id. de CIS Controls v8 Identificadores de NIST SP 800-53 r4 Id. de PCI-DSS v3.2.1
3.3, 6.4, 13.5 AC-2, AC-3, AC-6 7.2

Principio de seguridad: valide explícitamente las señales de confianza para permitir o denegar el acceso de los usuarios a los recursos, como parte de un modelo de acceso de confianza cero. Las señales que se van a validar deben incluir la autenticación sólida de la cuenta de usuario, el análisis del comportamiento de la cuenta de usuario, la confiabilidad del dispositivo, la pertenencia a grupos o usuarios, las ubicaciones, etc.

Guía de Azure: use el acceso condicional de Azure AD para controles de acceso más granulares en función de las condiciones definidas por el usuario, como requerir inicios de sesión de usuario desde determinados intervalos IP (o dispositivos) para usar MFA. El acceso condicional de Azure AD permite exigir controles de acceso en las aplicaciones de la organización, en función de ciertas condiciones.

Defina las condiciones y los criterios aplicables para el acceso condicional de Azure AD en la carga de trabajo. Considere los siguientes casos de uso comunes:

  • Requerir la autenticación multifactor a los usuarios con roles administrativos
  • Requerir la autenticación multifactor para las tareas de administración de Azure
  • Bloquear los inicios de sesión a los usuarios que intenten usar protocolos de autenticación heredados
  • Requerir ubicaciones de confianza para el registro de Azure AD Multi-Factor Authentication
  • Bloquear o conceder el acceso desde ubicaciones concretas
  • Bloquear de comportamientos de inicio de sesión peligrosos
  • Requerir dispositivos administrados por la organización para aplicaciones concretas

Nota: Los controles de administración de sesiones de autenticación granulares también se pueden implementar a través de la directiva de acceso condicional de Azure AD, como la frecuencia de inicio de sesión y la sesión del explorador persistente.

Implementación de Azure y contexto adicional:

Guía de AWS: cree una directiva de IAM y defina condiciones para controles de acceso más pormenorizados en función de las condiciones definidas por el usuario, como requerir inicios de sesión de usuario desde determinados intervalos IP (o dispositivos) para usar la autenticación multifactor. La configuración de condición puede incluir una o varias condiciones, así como lógicas.

Las directivas se pueden definir desde seis dimensiones diferentes: directivas basadas en identidades, directivas basadas en recursos, límites de permisos, directiva de control de servicios (SCP) de AWS Organizations, Access Control Listas (ACL) y directivas de sesión.

Implementación de AWS y contexto adicional:

Guía de GCP: cree y defina condiciones de IAM para controles de acceso basados en atributos más granulares en función de las condiciones definidas por el usuario, como requerir inicios de sesión de usuario desde determinados intervalos IP (o dispositivos) para usar la autenticación multifactor. La configuración de condición puede incluir una o varias condiciones, así como lógica.

Las condiciones se especifican en los enlaces de rol de la directiva de permiso de un recurso. Los atributos de condición se basan en el recurso solicitado (por ejemplo, su tipo o nombre) o en detalles sobre la solicitud, por ejemplo, su marca de tiempo o su dirección IP de destino.

Implementación de GCP y contexto adicional:

Partes interesadas de la seguridad del cliente (más información):

IM-8: Restringir la exposición de credenciales y secretos

Id. de CIS Controls v8 Identificadores de NIST SP 800-53 r4 Id. de PCI-DSS v3.2.1
16.9, 16.12 IA-5 3.5, 6.3, 8.2

Principio de seguridad: asegúrese de que los desarrolladores de aplicaciones controle de forma segura las credenciales y los secretos:

  • Evite insertar las credenciales y secretos en los archivos de código y configuración.
  • Use un almacén de claves o un servicio seguro de almacén de claves para almacenar las credenciales y secretos.
  • Busque credenciales en el código fuente.

Nota: Esto se suele regir y aplicar a través de un ciclo de vida de desarrollo de software seguro (SDLC) y un proceso de seguridad de DevOps.

Guía de Azure: al usar una identidad administrada no es una opción, asegúrese de que los secretos y las credenciales se almacenan en ubicaciones seguras, como Azure Key Vault, en lugar de insertarlos en los archivos de código y configuración.

Si usa Azure DevOps y GitHub para la plataforma de administración de código:

  • Implemente Azure DevOps Credential Scanner para identificar las credenciales en el código.
  • En GitHub, use la característica nativa de análisis de secretos para identificar credenciales u otro tipo de secretos en el código.

Los clientes, como los servicios Azure Functions, Azure Apps y las VM, pueden usar identidades administradas para acceder a Azure Key Vault de manera segura. Consulte los controles de protección de datos relacionados con el uso de Azure Key Vault para la administración de secretos.

Nota: Azure Key Vault proporciona rotación automática para los servicios admitidos. En el caso de los secretos que no se pueden rotar automáticamente, asegúrese de que se rotan manualmente periódicamente y se purgan cuando ya no están en uso.

Implementación de Azure y contexto adicional:

Guía de AWS: al usar un rol de IAM para el acceso a aplicaciones no es una opción, asegúrese de que los secretos y las credenciales se almacenan en ubicaciones seguras, como AWS Secret Manager o Systems Manager Parameter Store, en lugar de insertarlos en los archivos de código y configuración.

Use CodeGuru Reviewer para el análisis de código estático que puede detectar los secretos codificados de forma rígida en el código fuente.

Si usa Azure DevOps y GitHub para la plataforma de administración de código:

  • Implemente Azure DevOps Credential Scanner para identificar las credenciales en el código.
  • En GitHub, use la característica nativa de análisis de secretos para identificar credenciales u otro tipo de secretos en el código.

Nota: Secrets Manager proporciona rotación automática de secretos para los servicios admitidos. En el caso de los secretos que no se pueden rotar automáticamente, asegúrese de que se rotan manualmente periódicamente y se purgan cuando ya no están en uso.

Implementación de AWS y contexto adicional:

Guía de GCP: al usar una cuenta de servicio administrada por Google para el acceso a aplicaciones no es una opción, asegúrese de que los secretos y las credenciales se almacenan en ubicaciones seguras, como secret Manager de Google Cloud en lugar de insertarlas en los archivos de código y configuración.

Use la extensión Google Cloud Code en el IDE (entorno de desarrollo integrado), como Visual Studio Code para integrar secretos administrados por Secret Manager en el código.

Si usa Azure DevOps o GitHub para la plataforma de administración de código:

  • Implemente Azure DevOps Credential Scanner para identificar las credenciales en el código.
  • En GitHub, use la característica nativa de análisis de secretos para identificar credenciales u otro tipo de secretos en el código.

Nota: Configure programaciones de rotación para secretos almacenados en Secret Manager como procedimiento recomendado.

Implementación de GCP y contexto adicional:

Partes interesadas de la seguridad del cliente (más información):

IM-9: Protección del acceso de los usuarios a aplicaciones existentes

Id. de CIS Controls v8 Identificadores de NIST SP 800-53 r4 Id. de PCI-DSS v3.2.1
6.7, 12.5 AC-2, AC-3, SC-11 N/D

Principio de seguridad: en un entorno híbrido, donde tiene aplicaciones locales o aplicaciones en la nube no nativas mediante la autenticación heredada, considere soluciones como el agente de seguridad de acceso a la nube (CASB), el proxy de aplicación, el inicio de sesión único (SSO) para controlar el acceso a estas aplicaciones para las siguientes ventajas:

  • Aplicación de una autenticación sólida centralizada
  • Supervisión y control de las actividades de usuarios finales de riesgo
  • Supervisión y corrección de actividades de aplicaciones heredadas de riesgo
  • Detección y prevención de la transmisión de datos confidenciales

Guía de Azure: proteja las aplicaciones en la nube locales y no nativas mediante la autenticación heredada mediante su conexión a:

  • Azure AD Application Proxy y configure la autenticación basada en encabezados para permitir el acceso de inicio de sesión único (SSO) a las aplicaciones para usuarios remotos, al tiempo que valida explícitamente la confiabilidad de los usuarios remotos y los dispositivos con acceso condicional de Azure AD. Si es necesario, use una solución Software-Defined Perimeter (SDP) de terceros que pueda ofrecer una funcionalidad similar.
  • Microsoft Defender for Cloud Apps, que sirve a un servicio de agente de seguridad de acceso a la nube (CASB) para supervisar y bloquear el acceso de los usuarios a aplicaciones SaaS de terceros no aprobadas.
  • Sus redes y controladores de entrega de aplicaciones de terceros existentes.

Nota: Las VPN se usan normalmente para acceder a las aplicaciones heredadas y, a menudo, solo tienen control de acceso básico y supervisión de sesión limitada.

Implementación de Azure y contexto adicional:

Guía de AWS: siga las instrucciones de Azure para proteger las aplicaciones en la nube locales y no nativas mediante la autenticación heredada mediante su conexión a:

  • Azure AD Application Proxy y configure la base de encabezados para permitir el acceso de inicio de sesión único (SSO) a las aplicaciones para usuarios remotos, al tiempo que valida explícitamente la confiabilidad de los usuarios remotos y los dispositivos con acceso condicional de Azure AD. Si es necesario, use una solución Software-Defined Perimeter (SDP) de terceros que pueda ofrecer una funcionalidad similar.
  • Microsoft Defender for Cloud Apps, que actúa como un servicio de agente de seguridad de acceso a la nube (CASB) para supervisar y bloquear el acceso de los usuarios a aplicaciones SaaS de terceros no aprobadas.
  • Las redes y controladores de entrega de aplicaciones existentes de terceros.

Nota: Las VPN se usan normalmente para acceder a las aplicaciones heredadas y, a menudo, solo tienen control de acceso básico y supervisión de sesión limitada.

Implementación de AWS y contexto adicional:

Guía de GCP: use Google Cloud Identity-Aware Proxy (IAP) para administrar el acceso a aplicaciones basadas en HTTP fuera de Google Cloud, incluidas las aplicaciones locales. IAP funciona con encabezados firmados o la API de usuarios dentro de un entorno estándar de App Engine. Si es necesario, use una solución de perímetro definido por software (SDP) de terceros que pueda ofrecer una funcionalidad similar.

También tiene la opción de usar Microsoft Defender for Cloud Apps que actúa como un servicio de agente de seguridad de acceso a la nube (CASB) para supervisar y bloquear el acceso de los usuarios a aplicaciones SaaS de terceros no aprobadas.

Nota: Las VPN se usan normalmente para acceder a las aplicaciones heredadas y, a menudo, solo tienen control de acceso básico y supervisión de sesión limitada.

Implementación de GCP y contexto adicional:

Partes interesadas de la seguridad del cliente (más información):