Identidad y control de acceso (IAM)

Identidad y control de acceso

¿Quién es el miembro?

Puede ser

• una persona
• un subsistema (ejem. Aplicación): esto se le conoce como service account.

Zero Trust / Confianza Cero: No confiamos en lo que está dentro de nuestro perímetro de seguridad de forma automática.

• Las comunicaciones dentro del perímetro de seguridad están cifradas y vienen con permisos.
• Establecemos que aplicaciones pueden hablar con que aplicaciones.
• Determinamos el tipo de recursos que las aplicaciones pueden generar.

¿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:

• Generar uno nuevo
• Modificarlo
• Borrarlo
• Hacerle update

¿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:[email protected]",
 		"serviceAccount:[email protected]",
 		"group:[email protected]",
 		"domain:acme.com" ]
 },
 {
 	"role": "roles/storage.objectViewer",	# rol
 	"members": ["user:[email protected]"]	# a los que les asignaremos el rol
 }
 ]
}

De esta manera entiendo las políticas.

Se admiten críticas. 📈📝

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:
.

• Principal. Definida por una cuenta existen en google, una cuenta de servicio o una identidad de Cloud bajo un dominio.
• Role. Una colección de permisos que determinar las operaciones permitidas sobre un recursos.
• Policy. Una colección vinculada de roles que puede atar desde uno o varios principals.

.
Si esta política esta vinculada a un proyecto, los principals son abstraídos sobre la jerarquía del proyecto.
.

• 
  -
  

.

Tipos de principals

• Google Account user: : Representada por un ente físico o jerárquico, quien interactúa con la Google Cloud.
• Service Account serviceAccount: : Representada por una aplicación.
• Google Group group: : Representada por una colección de Google Accounts y Service Accounts.
• Google Workspace Domain domain: : Representada bajo un dominio ( tal como example.com ) el cual define aun usuario como [email protected].
• Google Identity Domain : Similar a Google Workspace, pero sin disfrutar de la distro del Workspace.
• 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:[email protected]",
         "serviceAccount:[email protected]",
         "group:[email protected]",
         "domain:google.com"
       ]
    },
    {
      "role": "roles/storage.objectViewer",
      "members": [
        "user:[email protected]"
      ]
    }
  ]
}

.
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:

• Basic Roles. Existentes en la consola de Google Cloud como Owner, Editor y Viewer.
• Predefined roles. Roles que dan acceso privilegiado adicional a los roles básicos.
• Custom roles. Roles creados para las necesidades puntales de una organización

Identidad y control de acceso (IAM)

• Cloud identity y controles de acceso IAM
  • Quién (persona o recurso “equipo, aplicación o servicio”)
    • sujetado al modelo Zero Trust > quiere decir que no confiamos en lo que está dentro de nuestro perímetro de seguridad de forma automática
  • Puede hacer qué (que acciones tiene permitido realizar, pueden haber permisos asignados tanto a personas como a recursos)
  • en cuál recurso

Roles

• Representan un conjunto de permisos detallados
  • Rol (Instance Admin)
    • Lista de permisos (delete, get, setmachinetype, start, stop)
    • permisos para generar políticas de seguridad
    • permisos para leer los logs
  • Rol (Administradores de red)
    • generar redes
    • generar sub redes
    • generar rangos de IP
    • generar switches y otros recursos
• Los roles no se asignan a personas, se asignan a los grupos
• Asignación de políticas y herencia

Estructura de una política

{
 "bindings": [
 {
 	"role": "roles/storage.objectAdmin",
    "members": [
        "user:[email protected]",
 		"serviceAccount:[email protected]",
 		"group:[email protected]",
 		"domain:acme.com" ]
 },
 {
 	"role": "roles/storage.objectViewer",	# rol
 	"members": ["user:[email protected]"]	# a los que les asignaremos el rol
 }
 ]
}

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.

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

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.

• Quien = Humano o aplicación (service Account)
• Puede hacer que = Serie de permisos asignados a través de roles.
• En cual recursos = Políticas asignadas a cada uno de los recursos.
• Los Roles se asignan a grupos. (Dev, Pre, Pro)

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.

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)

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.

Puede ser confuso la versión del “QUIÉN”, tan solo es comprender que son dos identidades:
a) El usuario como ser humano.
b) La aplicación como identidad de funcionalidad.

Muy interesante de como generar las políticas de seguridad y la creación de buckets.

En la clase anterior se mencionaba como seguir modelos arquitectonicos y jerarquicos para seguir procesos y definir tareas dentro de la organizacion y la importancia de aplicarlos a las soluciones de software en la nube.