Tan Zuñiga
Roger Hassan Moreno Serrano
Víctor Macías Pincay
¿Qué es la gestión de identidad y acceso?
La gestión de identidad y acceso (IAM, por sus siglas en inglés) es un componente esencial de la seguridad en entornos de computación en la nube. Nos permite definir, asignar y gestionar qué usuarios o aplicaciones (identidades) pueden realizar determinadas acciones (permisos) sobre un recurso específico. En el contexto del cloud, el concepto de "Zero Trust" juega un papel importante, ya que incluso dentro del perímetro de seguridad, no se confía automáticamente en las comunicaciones sin asegurar permisos y accesos cifrados.
¿Quiénes son los miembros en IAM?
En el contexto de IAM, el quién puede referirse tanto a un usuario humano como a una aplicación. Las aplicaciones, conocidas como "service accounts", también pueden tener identidades y permisos para interactuar con otros recursos en la nube. En contraste, los humanos tienen una identidad más tradicional, y el sistema debe gestionar ambas formas para mantener los niveles adecuados de seguridad.
¿Cómo se determinan los permisos?
Los permisos determinan qué acciones pueden realizar los miembros en IAM. Estos permisos no se asignan individualmente, sino que se agrupan en roles, como el de administrador de seguridad o administrador de red. Por ejemplo:
Un punto fundamental es que los roles no se asignan a individuos sino a grupos, facilitando la gestión del acceso a medida que los colaboradores se unen o dejan la empresa.
¿Qué es una política en IAM?
Las políticas son documentos que asignan roles a ciertos miembros respecto a determinados recursos. Estos se expresan usualmente en formato JSON y puedo contener varias combinaciones de roles y miembros. Las políticas pueden aplicarse a diferentes niveles:
Entender cómo se asignan y aplican las políticas es esencial para una adecuada gestión de accesos en la infraestructura de Google Cloud. Por ejemplo, una política podría establecer que un grupo de administradores puede generar bucket en todos los proyectos de una organización.
Consejos para una efectiva gestión de IAM
La gestión adecuada de identidades y accesos no solo mejora la seguridad, sino que optimiza la operatividad de tu entorno en la nube. Explora cómo se implementan estas ideas en otros proveedores de nube y compara las diferencias con Google Cloud para seguir aprendiendo y adquiriendo experiencia en esta área crítica de la tecnología.
Tan Zuñiga
Roger Hassan Moreno Serrano
Víctor Macías Pincay
Andrés Castellanos
Roger Hassan Moreno Serrano
Emmanuel Rodríguez
Víctor Macías Pincay
Moises Bueso
Ernesto Jose Gabriel Lopez Bravo
Isaac Álvaro Cisneros Zaragoza
Lina Marcela Cabarique Niño
Carolina de la Barrera Bautista
Oscar Giovanni Bocanegra Hurtado
Jhon Freddy Tavera Blandon
Pablo Mora
Company_adminChristian Felipe Santa Osorio
Aurelio ML
Jonathan Ernesto Hernández Guardado
Jonathan Ernesto Hernández Guardado
Alejandro Suarez del Moral
MARLON CHUQUINO CAPA
Kevin Fiorentino
Anthony Ismael Manotoa Moreno
Yosuad David Castillo Valdes
Jorge Emilio Granados Guzmán
Horacio Arias Hernández
Horacio Arias Hernández
Identidad y control de acceso
¿Quién es el miembro?
Puede ser
Zero Trust / Confianza Cero: No confiamos en lo que está dentro de nuestro perímetro de seguridad de forma automática.
¿Qué puede hacer?
Existe una taxonomía muy grande de recursos relacionados con que puede hacer.
Los recursos tienen ciertos permisos asignados. Además los permisos permiten realizar acciones sobre un recurso:
¿En cuál recurso?
Las políticas de seguridad se asignan a cada uno de los recursos. En una política podemos establecer el rol de los miembros.
Quién puede hacer qué en cuál recurso.
El quién es persona o aplicación. El qué son permisos y se asignan a través de roles.
Roles
Los roles son una colección de permisos detallados que asignamos a grupos.
Podemos generar nuestros propios roles, pero ya hay varios existentes.
Asignación de politicas y herencia
Se puede asignar a varios niveles: podemos asignar políticas a nivel org. folder, proyecto y recurso. Además de que heredan la política de los nodos superiores.
Estructura de una política
{ "bindings": [ { "role": "roles/storage.objectAdmin", "members": [ "user:alice@acme.com", "serviceAccount:my-other-app@appspot.gserviceaccount.com", "group:admins@acme.com", "domain:acme.com" ] }, { "role": "roles/storage.objectViewer", # rol "members": ["user:bob@acme.com"] # a los que les asignaremos el rol } ] }
Gracias amiguis, tus aportes siempre me ayudan a entenderlo mejor :D
Muchas gracias por cada aporte.
De esta manera entiendo las políticas.
Se admiten críticas. 📈📝
Esta bueno amigo, podrías hacer otro a ver qué cambia :D
IAM ( Identity and Access Management )
Definición
IAM nos permite otorgar acceso a específicos recursos de Google Cloud, así como limitar el acceso a otros. Con esto, IAM nos permite adoptar el principio de seguridad basada en privilegios donde todos, recursos y accesos, poseen permisos según sus necesidades. .
💡Con IAM, podemos administrar el acceso al definir who ( identidad ) tiene access ( role ) para con algún resource.
. En IAM, los permisos no sob abstraídos para un usuario final. En su lugar, los permisos son agrupados en roles, los cuales son otorgados a abstracciones llamadas principals.
Por último, una IAM policy define y aplica que roles a ciertos principals para con qué recursos. .
❔Si pudiéramos diagramar un IAM policy, tendríamos el siguiente ejemplo
. Para los diagramas siguientes, podemos denotar lo sigueinte: .
. Si esta política esta vinculada a un proyecto, los principals son abstraídos sobre la jerarquía del proyecto. .
.
Tipos de principals
user: : Representada por un ente físico o jerárquico, quien interactúa con la Google Cloud.serviceAccount: : Representada por una aplicación.group: : Representada por una colección de Google Accounts y Service Accounts.domain: : Representada bajo un dominio ( tal como example.com ) el cual define aun usuario como username@example.com.allAuthenticateUsers: : Representa a los usuarios autenticados con Google Account pero sin considerase dentro de la organización. También representa a cuentas personales de Gmail.allUsers: : Especifica a todos los usuarios del internet..
Acceso Administrado
Cada política es representada por un objeto llamado Policy , el cual consiste de una lista de roles bindings:
.
{ "bindings": [ { "role": "roles/storage.objectAdmin", "members": [ "user:ali@example.com", "serviceAccount:my-other-app@appspot.gserviceaccount.com", "group:admins@example.com", "domain:google.com" ] }, { "role": "roles/storage.objectViewer", "members": [ "user:maria@example.com" ] } ] }
. Donde:
role . Especificado como role/service.roleName que define las acciones abstraídas sobre un determinado rol.members . Una lista de principals donde cada uno es precedido por su correspondiente prefijo..
💡Los roles pueden ser categorizados en:
Muy detallada esta información. Muchas gracias.
Identidad y control de acceso (IAM)
Roles
Estructura de una política
{ "bindings": [ { "role": "roles/storage.objectAdmin", "members": [ "user:alice@acme.com", "serviceAccount:my-other-app@appspot.gserviceaccount.com", "group:admins@acme.com", "domain:acme.com" ] }, { "role": "roles/storage.objectViewer", # rol "members": ["user:bob@acme.com"] # a los que les asignaremos el rol } ] }
En Oracle Cloud debes crear primero el grupo o grupo dinámico, y luego utilizar el grupo dentro de la politica.
Lo que varia con relación a GCP es la politicas, en OCI son como frases tipo
Allow group Admins to manage all-resources in tenancy
Básicamente, esto te da permiso de administrador sobre el tenancy de OCI
Excelente aporte compañero, muchas gracias.
Es curioso como funciona el control de acceso porque en comparación con AWS el concepto de role se mapea en gcp con el concepto de service account (los roles en aws son una identidad que se asocia a una aplicación), por lo demás es muy parecido. En cuanto al tema de las organizaciones en AWS no es necesario tener una definida ni un profile de facturación, ni un billing account para una cuenta personal (hasta donde he entendido de gcp), aunque si soporta un esquema similar mediante AWS organizations para ya una organización de cuentas y control de accessos.
IAM
IAM es quien puede hacer qué en qué recursos
QUIÉN? puede referirse a un humano o persona real pero el quién también puede referirse a un subsistema (en terminos de cloud).
Service Account es un servicio que válida al subsistema, mientras que la identidad común es para un usuario humano.
zero trust es una de las capas de seguridad más importantes, que habla de todo lo que esta dentro del perimetro de seguridad y todo lo de fuera no es de confianza.
quién puede hacer qué? = permisos
todos los permisos te permiten hacer update, crear nuevos permisos, etc.
Un Rol es un conjunto de permisos detallados.
Los Roles no se asignan a personas sino a grupos (normalmente).
Estructura de una política
Una vez que ya generaste una política tienes que asignar esa política al folder o proyecto.
¿Qué es IAM?
El control de identidad y acceso IAM es un servicio fundamental en Google Cloud Platform GCP que te permite administrar quién puede acceder a tus recursos en la nube y qué acciones pueden realizar. IAM te proporciona las herramientas para
Beneficios de usar IAM
Si tienes experiencia en administración de dominios windows se te hace mas fácil entender, pues prácticamente es la misma esencia. Es mi humilde opinión.
Lo que entiendo con los Boquetes es que se pueden arrastrar herramientas allí para que entren a un proyecto a ejecutar ese trabajo asignándoselas a un colaborador con esas funciones.
Llegue a un nuevo proyecto, literal tenían las claves de producción públicas (en el chat) y con eso tenía acceso a todo xD (ps: No sigan esas prácticas pls)
Asignar permisos a usuarios individuales es como darle una llave maestra a cada empleado de un edificio; si alguien renuncia o cambia de departamento, tienes que rastrear y cambiar su cerradura específica. Al usar grupos, creas "llaveros" virtuales por departamento (por ejemplo, dev-team o data-scientists). Cuando un nuevo desarrollador entra a la empresa, simplemente lo agregas al grupo y automáticamente hereda todos los accesos necesarios para su trabajo, como leer bases de datos o encender servidores. Si esa persona se va, la eliminas del grupo y su acceso se revoca al instante en todos los sistemas. Esto reduce drásticamente los errores humanos, evita que queden cuentas fantasma con permisos activos y hace que las auditorías de seguridad sean mucho más rápidas y limpias.
Debes recurrir a roles personalizados únicamente cuando los roles predefinidos no se ajusten al principio de menor privilegio que requiere tu empresa. La plataforma ya ofrece cientos de roles predefinidos (como Network Viewer o Compute Admin) que agrupan lógicamente los permisos más comunes y se actualizan automáticamente si se lanzan nuevas funcionalidades. Sin embargo, si por cumplimiento normativo necesitas que un auditor externo solo pueda ver los logs de red y reiniciar una máquina virtual específica, pero sin acceso a nada más, un rol predefinido podría darle demasiado poder. En ese escenario exacto, creas un rol personalizado seleccionando con pinzas esos dos permisos exactos. Mantén esta práctica como una excepción, ya que los roles personalizados requieren mantenimiento manual por parte de tu equipo.
la aplicacion web que yo haga va a tener su etcetera@appspot.gservcie acocutn.com?
Alejandro, exactamente. Cuando despliegas una aplicación en Google Cloud (por ejemplo, en App Engine), el sistema crea automáticamente una cuenta de servicio predeterminada con ese formato.
Esta cuenta actúa como la "identidad" de tu aplicación. Si tu código necesita leer un archivo de un bucket de almacenamiento o escribir en una base de datos, lo hará usando los permisos que tú le hayas asignado a esa cuenta específica.
Es una forma de automatizar la seguridad: en lugar de que tú tengas que gestionar credenciales manualmente, la plataforma le otorga a tu aplicación su propia "identidad digital" desde el momento en que nace.
Para ver cómo gestionar estos permisos de forma práctica, te sugiero revisar: Gestión de Roles y Permisos en Google Cloud Platform.
y dónde podría conseguir trabajo con Google cloud
En cualquier empresa que lo utilice. Tienes que orientar tu perfil profesional como DevOps. Especializarte en servicios cloud como Google Cloud, Azure, AWS, entre otros. Podrás aplicar a los empleos que utilicen Google Cloud en el futuro.
Hola :D
Como ejercicio, busca "Google Cloud" en LinkedIn y encontrarás una gran cantidad de empleos
Los "buckets" en Google Cloud Platform (GCP) son contenedores de almacenamiento dentro del servicio Cloud Storage. Permiten almacenar y organizar archivos de manera eficiente. Cada bucket tiene un nombre único y se puede configurar con permisos de acceso, lo que te permite controlar quién puede ver o modificar los archivos que contiene. Además, los buckets pueden ubicarse en diferentes regiones para optimizar la latencia y el costo de almacenamiento.
kjkhjh
Es bueno ver todo los que se puede utilizar, pero sobre todo el ver que la IA es una herramienta que está bajo la supervisión de los humanos, que la oferta laboral es muy grande, y que bueno que las empresas comprendan que lo más importante es el capital humano el cual hace que las mismas crezcan día con día.
Puede hacer qué: Se ve la taxonomía en que es lo que puede hacer y en qué momento, es el hecho de poder dar permisos a los usuarios y por otro lado a las aplicaciones; así mismo en cuales recursos. Esto aplicando las políticas con las cuales en la organización se hayan planteado, para el uso de los recursos.