Identidad y control de acceso (IAM)

18/23
Recursos

Aportes 18

Preguntas 1

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad?

o inicia sesi贸n.

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

鉂擲i 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

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.

Identidad y control de acceso (IAM)


  • Cloud identity y controles de acceso IAM
    • Qui茅n (persona o recurso 鈥渆quipo, 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
 }
 ]
}

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

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

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.

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 鈥淨UI脡N鈥, tan solo es comprender que son dos identidades:
a) El usuario como ser humano.
b) La aplicaci贸n como identidad de funcionalidad.

En Sailpoint se gestiona distinto a gcp, se crean conectores de distintos tipos, archivos delimitados, jdbc, mainframe y tambi茅n de proveedores como Azure, gcp y aws entre otros, para dar acceso a una identidad se le debe de pedir la creaci贸n de la identidad en el recurso espec铆fico con el rol deseado, siempre y cuando sean solocitables. Me gusta como es IAM en GCP.

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.