Roles, responsabilidades y permisos
En una organización, varios equipos trabajan juntos para asegurarse de que la carga de trabajo y la infraestructura de apoyo sean seguras. Para evitar una confusión que pueda provocar riesgos para la seguridad, defina unas líneas claras de responsabilidad y separación de tareas.
En función de la experiencia de Microsoft con muchos proyectos de adopción de la nube, el establecimiento de roles y responsabilidades claramente definidos para funciones específicas en Azure evita confusiones que puedan dar lugar a errores humanos y de automatización con los subsecuentes riesgos de seguridad.
Líneas de responsabilidad claras
¿Tienen los equipos una visión clara de las responsabilidades y de los niveles de acceso tanto a nivel individual como de grupo?
Designación de las partes responsables de funciones específicas de Azure.
Documentar claramente y compartir los contactos responsables de cada una de estas funciones creará coherencia y facilitará la comunicación. Según nuestra experiencia con muchos proyectos de adopción de la nube, esto evitará confusión que puede conducir a errores humanos y de automatización que suponen riesgos para la seguridad.
Designe los grupos (o roles individuales) que serán responsables de estas funciones clave.
| Grupo o rol individual | Responsabilidad |
|---|---|
| Seguridad de redes | Normalmente, el equipo de seguridad de la red existente. Configuración y mantenimiento de Azure Firewall, dispositivos virtuales de red (y el enrutamiento asociado), Web Application Firewall (WAF), grupos de seguridad de red, grupos de seguridad de aplicación (ASG) y otro tráfico de la red. |
| Administración de red | Normalmente, el equipo de operaciones de red existente. Asignación de subred y red virtual en toda la empresa. |
| Seguridad de los puntos de conexión de servidor | Normalmente, el equipo de operaciones de TI, el equipo de seguridad, o ambos de forma conjunta. Supervisión y corrección de la seguridad del servidor (aplicación de revisiones, configuración, seguridad de los puntos de conexión). |
| Supervisión de incidentes y respuesta | Normalmente, el equipo de operaciones de seguridad. Supervisión y respuesta ante incidentes, con el fin de investigar y solucionar cualquier incidente en la seguridad en Administración de eventos e información de seguridad (SIEM) o en la consola de origen, como Azure Security Center o Azure AD Identity Protection. |
| Administración de directivas | Normalmente, el equipo de GRC y arquitectura. Aplique la gobernanza en función del análisis de riesgos y de los requisitos de cumplimiento. Establecimiento de la dirección de uso del control de acceso basado en roles de Azure (RBAC de Azure), Azure Security Center, la estrategia de protección del administrador y Azure Policy para controlar los recursos de Azure. |
| Seguridad y estándares de identidad | Normalmente, el equipo de seguridad y el equipo de identidad de forma conjunta. Establecimiento de la dirección de los directorios de Azure AD, el uso de PIM/PAM, la autenticación multifactor (MFA), la configuración de sincronización y contraseñas o los estándares de identidad de la aplicación. |
Nota
Los roles y las responsabilidades de las aplicaciones deberían cubrir el distinto nivel de acceso de cada función operativa. Por ejemplo, publicar la versión de producción, acceder a los datos del cliente, manipular los registros de la base de datos, etc. Los equipos de aplicaciones deben incluir las funciones centrales que se enumeran en la tabla anterior.
Asignación de permisos
Conceda a los roles los permisos adecuados que comienzan con privilegios mínimos y agregue más según sus necesidades operativas. Proporcione instrucciones claras a los equipos técnicos que implementan los permisos. Esta claridad facilita la detección y corrección de los errores humanos, como la asignación de permisos excesivos.
Asigne los permisos al grupo de administración del segmento y no a las suscripciones individuales. Esto controlará la coherencia y garantizará su aplicación a suscripciones futuras. En general, evite los permisos pormenorizados y personalizados.
Tenga en cuenta los roles integrados en Azure antes de crear roles personalizados para conceder los permisos adecuados a las máquinas virtuales y otros objetos.
La pertenencia al grupo de administradores de seguridad puede ser adecuada en el caso de equipos u organizaciones más pequeños en los que los equipos de seguridad tienen numerosas responsabilidades operativas.
Al asignar permisos para un segmento, tenga en cuenta la coherencia y la flexibilidad para acomodar varios modelos organizativos. Estos modelos pueden ir desde un único grupo de TI centralizado hasta equipos de TI y DevOps bastante independientes.
Ejemplo de modelo de referencia
En esta sección se usa este modelo de referencia para demostrar las consideraciones a tener en cuenta para asignar permisos a diferentes segmentos. Microsoft recomienda comenzar con estos modelos de referencia y adaptarlos a cada organización.
Permisos básicos de referencia de servicios
Este segmento hospeda los servicios compartidos que se usan en toda la organización. Estos servicios compartidos suelen incluir Active Directory Domain Services, DNS/DHCP y herramientas de administración del sistema hospedadas en máquinas virtuales de infraestructura como servicio (IaaS) de Azure.
Visibilidad sobre la seguridad en todos los recursos: para los equipos de seguridad, conceda acceso de solo lectura a los atributos de seguridad de todos los entornos técnicos. Este nivel de acceso es necesario para evaluar los factores de riesgo, identificar posibles mitigaciones y aconsejar a las partes interesadas de la organización que aceptan el riesgo. Para más información, consulte Visibilidad del equipo de seguridad.
Administración de directivas en algunos recursos o en todos ellos: para supervisar y aplicar el cumplimiento de normas, estándares y directivas de seguridad externos (o internos), asigne el permiso adecuado a dichos roles. Los roles y permisos que elija dependerán de la mentalidad de la organización y de las expectativas del programa de directivas. Consulte Microsoft Cloud Adoption Framework para Azure.
Antes de definir las directivas, hágase las siguientes preguntas:
- ¿Cómo se audita la seguridad de la organización y cómo se generan informes al respecto? ¿Hay informes obligatorios?
- ¿Hay prácticas de seguridad existentes vigentes?
- ¿Hay algún requisitos específicos del sector, gubernamentales o requisitos normativos?
Designe grupos (o roles individuales) para las funciones centrales que afecten a las aplicaciones y servicios compartidos.
Una vez establecidas las directivas, mejore continuamente los estándares de forma incremental. Asegúrese mediante auditorías y el cumplimiento de la supervisión de que la postura de seguridad no se degrada con el paso del tiempo. Para obtener información sobre la administración de los estándares de seguridad de una organización, consulte el artículo sobre gobernanza, riesgo y cumplimiento (GRC).
Operaciones de TI central en todos los recursos: conceda permisos al departamento de TI central (a menudo el equipo de infraestructura) para crear, modificar y eliminar recursos, como máquinas virtuales y almacenamiento. Los roles Colaborador o Propietario son adecuados para esta función.
Grupo de redes central en los recursos de red: para garantizar la coherencia y evitar los conflictos técnicos, asigne las responsabilidades de los recursos de red a una sola organización de red central. Estos recursos deben incluir redes virtuales, subredes, grupos de seguridad de red (NSG) y las máquinas virtuales que hospedan las aplicaciones de red virtual. Asigne las responsabilidades de los recursos de red a una sola organización de redes central. El rol Colaborador de red es adecuado para este grupo. Para más información, consulte Centralizar la administración de redes y la seguridad.
Permisos de roles de recursos: para la mayoría de los servicios principales, los privilegios administrativos necesarios para administrarlos se conceden mediante la propia aplicación (Active Directory, DNS, DHCP, herramientas de administración del sistema), por lo que no se requiere ningún permiso adicional de recursos de Azure. Si el modelo organizativo requiere que estos equipos administren sus propias máquinas virtuales, almacenamiento u otros recursos de Azure, puede asignar estos permisos a esos roles.
Los segmentos de carga de trabajo con equipos de DevOps autónomos administrarán los recursos asociados a cada aplicación. Los roles reales y sus permisos dependen del tamaño y de la complejidad de las aplicaciones, del tamaño y de la complejidad del equipo de aplicaciones y de la mentalidad de la organización y del equipo de aplicaciones.
Administración de servicios (cuenta de emergencia) : use el rol de administrador de servicios solo para emergencias y la configuración inicial. No use este rol para las tareas diarias. Para más información, consulte Cuentas de emergencia o de acceso de emergencia.
Permisos de referencia se segmentos
Este diseño de permisos de segmentos proporciona coherencia, a la vez que ofrece la flexibilidad para acomodar la gama de modelos de la organización que van desde un solo grupo de TI centralizado hasta los equipos de TI y de DevOps en gran medida independientes.
Visibilidad sobre la seguridad en todos los recursos: para los equipos de seguridad, conceda acceso de solo lectura a los atributos de seguridad de todos los entornos técnicos. Este nivel de acceso es necesario para evaluar los factores de riesgo, identificar posibles mitigaciones y aconsejar a las partes interesadas de la organización que aceptan el riesgo. Consulte Visibilidad del equipo de seguridad.
Administración de directivas en algunos recursos o en todos ellos: para supervisar y aplicar el cumplimiento de normas, estándares y directivas de seguridad externos (o internos), asigne el permiso adecuado a dichos roles. Los roles y permisos que elija dependerán de la mentalidad de la organización y de las expectativas del programa de directivas. Consulte Microsoft Cloud Adoption Framework para Azure.
Operaciones de TI en todos los recursos: conceda permiso para crear, modificar y eliminar recursos. El propósito del segmento (y los permisos resultantes) dependerá de la estructura de la organización.
Los segmentos con recursos administrados por una organización de TI centralizada pueden conceder al departamento de TI central (con frecuencia, el equipo de infraestructura) permiso para modificar estos recursos.
Los segmentos administrados por funciones o unidades de negocio independientes (por ejemplo, un equipo de TI de Recursos Humanos) pueden conceder a esos equipos permisos para todos los recursos del segmento.
Los segmentos con equipos de DevOps autónomos no necesitan conceder permisos en todos los recursos, ya que el rol del recurso (a continuación) concede permisos a los equipos de la aplicación. Para emergencias, use la cuenta de administrador de servicios (cuenta de emergencia).
Grupo de redes central en los recursos de red: para garantizar la coherencia y evitar los conflictos técnicos, asigne las responsabilidades de los recursos de red a una sola organización de red central. Estos recursos deben incluir redes virtuales, subredes, grupos de seguridad de red (NSG) y las máquinas virtuales que hospedan las aplicaciones de red virtual. Consulte Centralizar la administración de redes y la seguridad.
Permisos de rol de recursos: los segmentos con equipos de DevOps autónomos administrarán los recursos asociados a cada aplicación. Los roles reales y sus permisos dependen del tamaño y de la complejidad de las aplicaciones, del tamaño y de la complejidad del equipo de aplicaciones y de la mentalidad de la organización y del equipo de aplicaciones.
Administración de servicios (cuenta de emergencia) : use el rol de administrador de servicios solo para emergencias (y la configuración inicial, si es necesario). No use este rol para las tareas diarias. Para más información, consulte Cuentas de emergencia o de acceso de emergencia.
Visibilidad del equipo de seguridad
Un equipo de aplicaciones debe tener en cuenta las iniciativas de seguridad para alinear sus planes de mejora de seguridad con el resultado de esas actividades. Proporcione a los equipos de seguridad acceso de solo lectura a los aspectos de seguridad de todos los recursos técnicos de su incumbencia.
Las organizaciones de seguridad necesitan visibilidad sobre el entorno técnico para realizar sus tareas de evaluación y comunicación de los riesgos de la organización. Sin esta visibilidad, la seguridad tendrá que basarse en la información que proporcionen los grupos que trabajan en el entorno y que tengan un posible conflicto de intereses (y otras prioridades).
Tenga en cuenta que los equipos de seguridad pueden recibir otros privilegios si tienen responsabilidades operativas o el requisito de aplicar las reglas de cumplimiento en los recursos de Azure.
Por ejemplo, en Azure, asigne a los equipos de seguridad el permiso Lectores de seguridad, que proporciona acceso para medir el riesgo de seguridad (sin proporcionar acceso a los datos propiamente dichos).
En el caso de grupos de seguridad empresariales con amplias responsabilidades sobre la seguridad de Azure, puede asignar este permiso mediante:
Grupos de administración raíz: para los equipos responsables de evaluar y comunicar el riesgo sobre todos los recursos.
Grupos de administración de segmentos: para los equipos con un ámbito de responsabilidad limitado (normalmente necesario debido a los límites de la organización o a los requisitos normativos).
Importante
Dado que los equipos de seguridad tendrán un amplio acceso al entorno (y visibilidad sobre las vulnerabilidades de seguridad potenciales), tiene que considerar los grupos de seguridad como cuentas de impacto crítico y aplicar las mismas protecciones que a los administradores. En la sección Administración se detallan estos controles de Azure.
Acciones sugeridas
- Defina un proceso para alinear las actividades de comunicación, investigación y búsqueda con el equipo de la aplicación.
- Siguiendo el principio de privilegios mínimos, establezca el control de acceso en todos los recursos del entorno en la nube para los equipos de seguridad con acceso suficiente a fin de obtener la visibilidad necesaria del entorno técnico y de realizar sus tareas de evaluación e informes sobre el riesgo de la organización.
Más información
Interacción con el equipo de seguridad de la organización
Administrar inquilinos conectados
¿El equipo de seguridad tiene visibilidad sobre todas las suscripciones y entornos en la nube existentes? ¿Cómo se detectan los nuevos?
Asegúrese de que la organización de seguridad tenga en cuenta todas las inscripciones y las suscripciones asociadas conectadas a su entorno existente (a través de ExpressRoute o VPN de sitio de sitio) y la supervisión como parte de la empresa en general.
Estos recursos de Azure forman parte de su entorno empresarial y las organizaciones de seguridad necesitan visibilidad sobre ellos. Las organizaciones de seguridad necesitan este acceso para evaluar el riesgo y para determinar si se siguen las directivas de la organización y los requisitos normativos aplicables.
La infraestructura en la nube de las organizaciones debe estar bien documentada, con acceso por parte del equipo de seguridad a todos los recursos necesarios para la supervisión y la información. Se deben realizar exámenes frecuentes de los recursos conectados a la nube para asegurarse de que no se hayan agregado suscripciones o inquilinos adicionales fuera de los controles organizativos. Revise periódicamente la guía de Microsoft para asegurarse de que se consulten y sigan los procedimientos recomendados de acceso del equipo de seguridad.
Acciones sugeridas
Asegúrese de que todos los entornos de Azure que se conectan a su entorno de producción o red apliquen la directiva y los controles de gobernanza de TI de la organización en materia de seguridad.
Puede detectar los inquilinos que ya están conectados mediante una herramienta que proporciona Microsoft. Instrucciones sobre permisos
Pasos siguientes
Restrinja el acceso a los recursos de Azure a lo que se necesita saber, comenzando por el principio de seguridad con privilegios mínimos, y agregue más en función de sus necesidades operativas.
Vínculos relacionados
Para ver las consideraciones sobre el uso de grupos de administración que reflejen la estructura de la organización en un inquilino de Azure Active Directory (Azure AD), consulte el artículo sobre la organización de grupos de administración y suscripciones.
Vuelva al artículo principal: Consideraciones sobre la administración de identidades y acceso de Azure