En este tema, se muestra cómo configurar los permisos de administración de identidades y accesos (IAM) para situaciones de herramientas de redes. Se proporciona orientación sobre las funciones de IAM que se deben otorgar a las funciones prácticas relacionadas con las herramientas de redes de tu empresa para esas situaciones. Este contenido está dirigido, sobre todo, a los administradores de red y los empleados que administran las tareas de herramientas de redes de una organización. En todas las situaciones que se describen a continuación, se supone que se configuró una organización de Google Cloud.
Este documento no explica en detalle las funciones y los permisos de red. Para obtener una descripción detallada de las funciones y los permisos asociados con las API de procesamiento y de herramientas de redes, lee Funciones predefinidas de IAM de Compute Engine.
Un solo equipo administra la seguridad y la red de la organización
En esta situación, una organización grande tiene un equipo central que administra la seguridad y los controles de red para toda la organización. Los desarrolladores no tienen permisos para realizar cambios en ninguna configuración de red o seguridad definida por el equipo de seguridad y redes, pero se les otorga permiso para crear recursos como máquinas virtuales en subredes compartidas.
Para facilitar esto, la organización hace uso de una VPC compartida (nube privada virtual). Una VPC compartida permite la creación de una red de VPC de espacios IP RFC 1918 que los proyectos asociados (proyectos de servicio) pueden usar. Los desarrolladores que usan los proyectos asociados pueden crear instancias de VM en los espacios de red de VPC compartida. Los administradores de redes y seguridad de la organización pueden crear subredes, VPN y reglas de firewall que todos los proyectos de la red de VPC pueden usar.
En las siguientes tablas, se explican las funciones de IAM que se deben otorgar al equipo de seguridad y administración y al de desarrollo, además del nivel de recursos en el que se otorgarán las funciones.
| Recurso: | Organización | |
|---|---|---|
| Funciones: | Administrador de VPC compartida Administrador de red Administrador de seguridad |
|
| Principal: | Equipo de administración de seguridad y red. |
| Recurso: | Proyecto host | Esta función otorga permiso para usar subredes que la VPC compartida ha compartido. |
|---|---|---|
| Función: | Usuario de red | |
| Principal: | Desarrolladores |
| Recurso: | Proyecto de servicio | Ten en cuenta que esta función habilita el permiso para utilizar direcciones IP externas. Consulta la nota a continuación como una guía sobre cómo prevenir esta acción. |
|---|---|---|
| Función: | compute.instanceAdmin | |
| Principal: | Desarrolladores |
En esta situación, necesitarás tres políticas de permisos diferentes: una para la organización, una para el proyecto host y otra para los proyectos de servicio.
La primera política de permisos, que se debe vincular a nivel de organización, otorga al equipo de redes y seguridad los roles que necesita para administrar proyectos host de la VPC compartida. Esto incluye la capacidad de asociar proyectos de servicio con el proyecto host. También otorga al equipo de redes y seguridad la capacidad de administrar todos los recursos de red y de seguridad en todos los proyectos de la organización.
{
"bindings": [
{
"role": "roles/compute.xpnAdmin",
"members": [
"group:sec-net@example.com"
]
},
{
"role":"roles/compute.networkAdmin",
"members": [
"group:sec-net@example.com"
]
},
{
"role": "roles/compute.securityAdmin",
"members": [
"group:sec-net@example.com"
]
}
]
}
La segunda política de permisos debe estar asociada con el proyecto host y les otorga a los desarrolladores de la organización la capacidad de usar las redes compartidas en el proyecto host de VPC compartida.
{
"bindings": [
{
"role": "roles/compute.networkUser",
"members": [
"group:developers@example.com"
]
}
]
}
La tercera política de permisos debe estar asociada con cada proyecto de servicio. Esto permite a los desarrolladores que usan el proyecto administrar las instancias en el proyecto de servicio y la capacidad de usar las subredes compartidas en el proyecto host.
Puedes colocar todos los proyectos de servicio en una carpeta y configurar esta política de permisos en particular en ese nivel de la jerarquía. Esto permitiría que todos los proyectos creados en esa carpeta hereden los permisos configurados en la carpeta dentro de la cual se crea el proyecto de servicio.
También debes otorgar a los desarrolladores la función de usuario de red en el proyecto de servicio.
{
"bindings": [
{
"role": "roles/compute.networkUser",
"members": [
"group:developers@example.com"
]
},
{
"role": "roles/compute.instanceAdmin",
"members": [
"group:developers@example.com"
]
}
]
}
La práctica recomendada es usar grupos para administrar principales. En el ejemplo anterior, agregarías el ID de usuario de los usuarios que administran los controles de seguridad y red al grupo sec-net, y los desarrolladores al grupo developers.
Cuando necesitas modificar quién es capaz de llevar a cabo la función, tan solo debes ajustar la membresía del grupo, sin necesidad de actualizar la política de permisos.
Equipos separados de red y seguridad
En esta situación, una organización grande tiene dos equipos centrales, uno que administra los controles de seguridad y otro que administra los recursos de red para toda la organización. Los desarrolladores no tienen permisos para realizar cambios en ninguna configuración de red o seguridad definida por el equipo de seguridad y redes, pero se les otorga permiso para crear recursos como máquinas virtuales en subredes compartidas.
Al igual que en la primera situación, se usará una VPC compartida y los permisos adecuados configurados para la red, la seguridad y los desarrolladores de los tres grupos.
En las siguientes tablas, se explican las funciones de IAM que se deben otorgar al equipo de seguridad y administración y al de desarrollo, además del nivel de recursos en el que se otorgarán las funciones.
| Recurso: | Organización | |
|---|---|---|
| Funciones: | Administrador de VPC compartida Administrador de red |
|
| Principal: | Equipo administrador de red |
| Recurso: | Organización | |
|---|---|---|
| Funciones: | Administrador de seguridad Administrador de la organización |
|
| Principal: | Equipo de seguridad |
| Recurso: | Proyecto host | Esta función otorga permiso para usar subredes que la VPC compartida ha compartido. |
|---|---|---|
| Función: | Usuario de red | |
| Principal: | Desarrolladores |
| Recurso: | Proyecto de servicio | Ten en cuenta que esta función habilita el permiso para utilizar direcciones IP externas. Consulta la nota a continuación como una guía sobre cómo prevenir esta acción. |
|---|---|---|
| Función: | compute.instanceAdmin | |
| Principal: | Desarrolladores |
En esta situación, necesitarás tres políticas de permisos diferentes: una para la organización, una para el proyecto host y otra para los proyectos de servicio.
La primera política de permisos, que se debe vincular a nivel de organización, otorga al equipo de redes los roles que necesita para administrar los proyectos host de la VPC compartida y todos los recursos de red. Esto incluye la capacidad de asociar proyectos de servicio con el proyecto host. El rol de administrador de redes también otorga al equipo de redes la capacidad de ver las reglas de firewall, pero no de modificarlas. También otorga al equipo de seguridad la capacidad de establecer políticas de permisos y administrar reglas de firewall y certificados SSL en todos los proyectos de la organización.
{
"bindings": [
{
"role": "roles/compute.xpnAdmin",
"members": [
"group:networks@example.com"
]
},
{
"role": "roles/compute.networkAdmin",
"members": [
"group:networks@example.com"
]
},
{
"role": "roles/compute.securityAdmin",
"members": [
"group:security@example.com"
]
},
{
"role": "roles/resourcemanager.organizationAdmin",
"members": [
"group:security@example.com"
]
}
]
}
La segunda política de permisos debe estar asociada con el proyecto host. Esta política de permisos permite que los desarrolladores de la organización usen las redes compartidas en el proyecto host de la VPC compartida.
{
"bindings": [
{
"role": "roles/compute.networkUser",
"members": [
"group:developers@example.com"
]
}
]
}
La tercera política de permisos debe estar asociada con cada proyecto de servicio. Esto permite a los desarrolladores que usan el proyecto administrar las instancias en el proyecto de servicio y la capacidad de usar las subredes compartidas en el proyecto host.
Puedes colocar todos los proyectos de servicio en una carpeta y configurar esta política de permisos en particular en ese nivel de la jerarquía. Esto permitiría que todos los proyectos creados en esa carpeta hereden los permisos configurados en la carpeta dentro de la cual se crea el proyecto de servicio.
{
"bindings": [
{
"role": "roles/compute.networkUser",
"members": [
"group:developers@example.com"
]
},
{
"role": "roles/compute.instanceAdmin",
"members": [
"group:developers@example.com"
]
}
]
}
Cada equipo puede administrar su propia red
Un nativo digital quiere dar a sus equipos de desarrollo la capacidad de trabajar de manera autónoma. No tienen equipos centrales de administración de TI y confían en sus equipos para administrar todos los aspectos de sus proyectos.
A pesar de esto, también quieren poder implementar algunos controles sueltos que les permitan adoptar una configuración más formal a medida que crecen y su producto se lanza al mercado.
Para implementar esta situación, se le asigna a cada equipo de desarrolladores su propia carpeta. Mediante esta estructura, se garantiza que los proyectos individuales creados en la carpeta hereden los permisos adecuados y, a la vez, se permite que cada equipo trabaje de forma independiente. Cada equipo debe respetar el principio de privilegio mínimo cuando establece políticas de permisos en sus propios recursos.
A pesar de que, en un principio, serán los mismos miembros del equipo quienes administrarán los recursos de red y los recursos de los proyectos, se recomienda crear distintos grupos para las tareas lógicas.
Este enfoque facilita la limitación del acceso a aquellos recursos que el personal temporal necesita o quizás el personal nuevo que necesita capacitación antes de poder modificar los recursos de red. También permite cambiar quién tiene acceso a qué recursos sin tener que modificar la política de permisos cada vez que se produce un cambio de personal.
| Recurso: | Carpeta | Se puede utilizar una cuenta de servicio para crear y poseer proyectos. |
|---|---|---|
| Funciones: | Creador del proyecto Administrador de carpetas |
|
| Principal: | Líderes de equipo de desarrollo Cuenta de servicio |
| Recurso: | Carpeta | |
|---|---|---|
| Funciones: | Administrador de la red Administrador de seguridad |
|
| Principal: | Equipo de seguridad y red |
| Recurso: | Carpeta | Estas funciones permiten a los desarrolladores administrar todos los aspectos de BigQuery y de Compute Engine. |
|---|---|---|
| Funciones: | Administrador de instancias Administrador de BigQuery |
|
| Principal: | Desarrolladores |
Esto requiere una política de permisos vinculada a la carpeta asignada de cada equipo.
{
"bindings": [
{
"role": "roles/resourcemanager.foldersAdmin",
"members": [
"group:devteamleads01@example.com",
"serviceAccount:dev01-project-creator@shared-resources-proj.iam.gserviceaccount.com"
]
},
{
"role":"roles/resourcemanager.projectCreator",
"members": [
"group:devteamleads01@example.com",
"serviceAccount:dev01-project-creator@shared-resources-proj.iam.gserviceaccount.com"
]
},
{
"role": "roles/compute.securityAdmin",
"members": [
"group:net-sec-dev01@example.com"
]
},
{
"role": "roles/compute.networkAdmin",
"members": [
"group:net-sec-dev01@example.com"
]
},
{
"role": "roles/compute.instanceAdmin",
"members": [
"group:dev01@example.com"
]
},
{
"role": "roles/bigquery.admin",
"members": [
"group:dev01@example.com"
]
}
]
}