Identidad y control de acceso (IAM)

18/23
Recursos

Aportes 11

Preguntas 1

Ordenar por:

¬ŅQuieres ver m√°s aportes, preguntas y respuestas de la comunidad? Crea una cuenta 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.
.

‚ĚĒ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
 }
 ]
}

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

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)

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

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.

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

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.

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.