Permisos en Azure explicados: RBAC, PIM y todo lo que necesitas saber

Buenas, bienvenidos a otro vídeo. Sé que llevo tiempo sin subir contenido. Os pongo un poco al día. Quien quiera ir directamente al tutorial, pues le pongo por aquí arriba en qué minuto está para que vaya directamente. Pero bueno, os quería poner un poco al día en los cambios que han habido. Como podéis ver, he invertido un poquito en todo lo que es el canal. Podéis ver que, bueno, me he comprado un micro nuevo, la cámara también, bueno, estoy utilizando una cámara diferente, y también he actualizado todo lo que es miniaturas, tanto del blog como de los vídeos. He trabajado un poco en toda la infraestructura que había por detrás, las cuentas de contacto, las cuentas de la newsletter. He trabajado también en actualizar el blog a nivel de los términos de privacidad, un poquito el sobre mí, todo esto. Entonces, por eso he tardado tanto en subir vídeo. Pero bueno, lo importante es que ya hemos vuelto. Me lío ya con el tutorial y cualquier cosa pues quedo a vuestra disposición. Muy bien, pues vamos a ello. Como siempre, os recuerdo que todo esto viene de un blog. Aquí en el blog tendréis todas las guías, que tampoco tutorial, todas las guías paso por paso. Yo a veces lo prefiero si estáis haciendo un deployment de algo, tenerlo por escrito, porque así los comandos, yo qué sé, no tenéis que estar pausando el vídeo todo el rato. Entonces os recuerdo que todo esto viene de un blog. Concretamente el nuestro, AliOps. Y aquí podéis encontrar pues el post en el que está basado este vídeo, que es precisamente este de aquí, el de permisos en Azure, vale. Si no lo encontráis, aquí tenéis el buscador. También aprovecho para recordaros, he actualizado toda la parte de sobre mí y bueno, varias cosas más en la sección de contacto, etcétera. Pero bueno, no quiero aburriros más. El vídeo de hoy se basa en este post de aquí que como veis también he actualizado un índex donde os explico cómo funciona todo lo que es la gestión de permisos dentro de Azure. Para ello, primero tenemos que entender dos cosas. La primera es qué permisos tenemos y sobre qué necesitamos un permiso y ¿a quién le tenemos que dar ese permiso? Son las dos grandes preguntas: el permiso sobre qué y a quién le queremos dar ese permiso. Para ello he creado una presentación PowerPoint donde voy a explicar cómo funciona la jerarquía dentro, jerarquía por decirlo de alguna forma, los recursos dentro de Azure. Para ello Dando un segundín que os pongo esto en pantalla completa. Vale, ya lo tenéis. Tenemos que empezar con nuestro tenant, ¿no? Cada persona, cada empresa, cada entidad, vamos a llamarlo, tiene su propio tenant. Y dentro de ese tenant tendremos pues lo que vamos a ver a continuación. Como podéis ver, en nuestro caso particular, en nuestro test tenant que estamos utilizando nosotros, nuestro tenant se llama AliOps. AliOps. Aquí dentro pues lo tendremos absolutamente todo, es decir, podremos tener, pues en caso de multinacionales, las divisiones, las zonas de negocio, los equipos, absolutamente todo. Por debajo de lo que es el tenant en sí tendremos los management groups. En nuestro caso Y esto es una captura de nuestro Tenant. Yo lo tengo llamado Tenant Root Group, vale, porque solo tengo uno. Un ejemplo práctico de esto pues podrían ser zonas de la empresa, mercados, por así decir. Podríamos tener AliOps España, AliOps Suiza, como en este ejemplo. Podríamos tener EMEA, podríamos tener USA. ¿Para qué sirven los Management Groups? Sobre todo para temas de budgets, de Pues eso, la gestión en sí política, vamos a llamar de alguna forma, de la empresa, no, los costes, todo esto. Pero sobre todo quiero que os acordéis de que se suele basar en zonas más que en equipos, porque para equipos ya habrá otras cosas. Entonces, los management groups están hechos para sobre todo la gestión a nivel de management, como dice la palabra. Lo siguiente que tendremos son las suscripciones. Las suscripciones ya son un poco más específicas. Las suscripciones, en nuestro caso, tenemos la— es el problema que os he dicho que tenía antes, no, por eso tardado tanto en subir vídeo. La suscripción que yo tenía caducó por un tema de, bueno, de una licencia que tenía especial, y me he tenido que crear una suscripción nueva. Y en esa suscripción he tenido que migrar todos los recursos. Por lo tanto, la suscripción lo podríais imaginar como zonas dentro del mismo mercado. Un ejemplo claro sería la suscripción de producción, la suscripción de test, qué sé yo. En el caso, me invento, de una cadena de restaurantes, pues no sé, bueno, una cadena de restaurantes igual no es el mejor ejemplo, pero una cadena de hospitales, varios hospitales o una universidad con varios campus. Pues mira, este ejemplo me gusta. Una universidad con varios campus, pues igual tendría una suscripción para cada campus. Dentro de esa suscripción, pues hay billing accounts, hay varios recursos que te permiten gestionar más específicamente la entidad, por así decir. Luego ya por debajo de las suscripciones ya tendremos los resource groups, que en español es grupos de recursos, y es lo que su nombre indica. Al final es agrupaciones de recursos que va a tener esa entidad, esa empresa. Ahora lo veréis con un ejemplo, que pueden contener varias cosas. Nosotros, por ejemplo, tendremos un resource group de Sentinel donde guardaremos todas las cosas de Sentinel. Luego tendremos un resource group de Automation donde guardaremos todas las automatizaciones. En otra web o en otra empresa tendremos resource groups de bases de datos, de analytics, de ventas, de de lo que sea. Y dentro de esos resource groups ya tendremos las propias aplicaciones o recursos en sí, como en nuestro caso, pues por ejemplo, si es un resource group de Sentinel, pues tendremos el Log Analytics workspace, el Sentinel instance, etcétera. Como podéis ver, la jerarquía, que la jerarquía queda de la siguiente forma: tendremos arriba que es el tenant, dividido en management groups. Luego, por debajo de esos management groups, tendremos las suscripciones. Dentro de las suscripciones tendremos los resource groups, y dentro de cada resource group tendremos pues los recursos, los resources. Es muy importante entender que en Azure los recursos siempre van de arriba abajo. Es decir, cualquier permiso que tú tengas de cualquier instancia, cualquier, no sé cómo decirlo, cualquier entidad de Azure, cualquier grupo, management group, suscripción, va a hacer que heredes los permisos en sus cosas contenidas, por así decir. Es decir, que si yo tengo el permiso de, me invento, de administrador en la suscripción de producción, automáticamente heredo el permiso de administración en todo lo que esté por debajo, porque se entiende que yo soy administrador de toda la suscripción. Pero ojo, esto no va al revés. Si yo soy administrador, me invento, en Sentinel, eso no me garantiza ser administrador en producción. Por lo tanto, a esto se le llama la herencia de los privilegios. Tú heredas los permisos que tienes siempre, siempre para abajo, nunca para arriba. Esto lo veremos en el blog. Una vez entendemos qué es lo que queremos proteger mediante asignar privilegios, queda responder a la pregunta de a quién le damos esos privilegios, ¿no? Y en Azure hay 4 entidades a quien les podemos dar privilegios o permisos. La primera es el típico usuario. Ahora explicaré todos, vale. La primera es el típico usuario, luego están los grupos, luego están las Managed Identities, y luego están los Service Principals, que los trataremos aparte, si os parece. Vamos a contar las diferencias entre estas 4 identidades y luego explicaré buenas prácticas. Y luego ya pues vamos paso por paso en el blog para explicar un poco cómo funciona todo. La diferencia entre esas 4 parece muy complicado, pero es muy sencilla. El usuario es la típica persona, ¿no? Bueno, persona, pueden haber service accounts, pero ya me entendéis, es el típico usuario, persona con su correo, trabajador de la empresa, que tiene su cuenta en Entra ID y que se encarga de hacer su faena. Por usuario también entendemos service accounts. Ojo, service accounts ya sabemos que no están gestionadas por una persona, pero cuentan al final como un usuario y esas service accounts tendrán sus permisos igual que todos. Luego tenemos los grupos que, como su nombre indica, son grupos de usuarios. Por ejemplo, en nuestro caso, en nuestro tenant, Dejadme un segundo y os lo enseño. Tenemos los siguientes grupos. Hay grupos que están autogenerados por Entra ID, pero bueno, yo he creado el grupo de usuarios donde tendremos a nuestro usuario víctima. Si me carga, en miembros tendremos al usuario víctima. Y luego pues he creado otro grupo que es security admins, que está mal dicho el nombre, pero bueno. Donde tendremos a nuestra cuenta de Security Operations. ¿Por qué son interesantes los grupos? Luego lo explico, pero os tenéis que quedar con que los grupos lo que hacen es agrupar usuarios de tal forma que es muy sencillo cuando, por ejemplo, imaginaos que contratáis a una persona nueva, ¿no? Pues no tendréis que estar configurando todo desde cero para esa persona. Al incluirla en un grupo heredará las propiedades de ese grupo. Siguiente, luego tenemos las Managed Identities. Las Managed Identities son identidades que se asignan a procesos o a aplicaciones, pero no necesariamente es una identidad con su contraseña y su cuenta. Es decir, una aplicación, por ejemplo, en este caso, una Logic App. Imaginaros una automatización, una Logic App que se encarga de automatizar, me invento, el password reset a usuarios. Pues obviamente esta Logic App va a necesitar permisos para ejecutar esos password reset, claro. De tal forma que para garantizarle a esa Logic App los permisos para realizar los password reset utilizaremos la Managed Identity de la Logic App. Cada Logic App tendrá como una especie de identificador que actuará como si fuera un usuario sin ser un usuario, para nosotros poder asignarle esos permisos. No podremos hacer login a esa identidad porque es una automatización, no es como hacer login en la cuenta de un usuario, y por lo tanto es una forma más segura de gestionar permisos en automatizaciones, en aplicaciones. No necesitas linkearlas o enlazarlas con un usuario. Puedes asignarle roles y permisos sin exponer que esos roles y permisos sean utilizados de forma peligrosa. Y por último tenemos las Service Principal, que son bastante similares a las Managed Identities pero con contraseña. Imaginaros un caso de uso, sería tener una client app, una aplicación dentro de Azure con su secret, con su client secret, que sería su contraseña, y esto pues se suele utilizar para conexiones a través de APIs, aplicaciones dentro de Azure, etcétera. Esto lo iremos viendo en un futuro, no os preocupéis. Entonces, lo que os quería decir también es que hay una muy buena práctica que es que los roles y los privilegios nunca, nunca, nunca deberían asignarse a estas tres. Esto para mí es bastante importante. Los roles, los privilegios, los permisos siempre, siempre, siempre deberán estar asignados a grupos. Aunque sea, aunque sea un grupo de un usuario, pero a grupos. ¿Por qué? Porque de esta forma, cuando tú borras a un usuario o a una Managed Identity de un grupo, automáticamente le revocas todos los permisos. Y esto va a ser muy útil en un futuro. O, por ejemplo, más fácil, imagínate que no recuerdas qué permisos tienes que estar asignando, pues simplemente los asignas asignas tu identidad al grupo correspondiente, ya no tienes ni que acordarte de los grupos porque se asignan por herencia. Otra razón es simplemente por pereza. Es decir, cada vez que crees un— imagínate que cada vez que entra alguien nuevo a la empresa le tienes que asignar todos los permisos, pues igual es un palo. Mejor coger y asignarlo a un grupo, y entonces por herencia heredará todos los permisos de ese grupo. Entonces es una muy buena práctica, y de hecho yo lo tengo así. Todos los permisos del tenant de AliOps están hechos a través de grupos. Y esto es un consejo que doy a cualquier persona que esté empezando con su tenant: siempre gestionarlo a partir de grupos, muy importante. Una vez sabemos a qué le tenemos que dar permiso, cómo le tenemos que dar permiso y a quién le tenemos que dar permiso, pues toca saber qué permisos tenemos que dar. Para ello me gustará hacerlo a través del blog. Porque creo que está bien explicado y aparte así me garantizo de no dejarme cosas. Entonces no os preocupéis, las partes que ya hemos visto no me repetiré. Entonces vamos a ir parte por parte explicando un poco el blog, el post, perdón. Me salto la introducción, la jerarquía de Azure, pues sinceramente ya la acabamos de ver. De todas formas, reminder, tendréis el link abajo por si queréis entrar al post y leerlo con calma. O sea, no hace falta que saquéis capturas de pantalla ni nada, os lo doy abajo todo. Aquí tengo una explicación de los management groups, suscripciones, tal. Sobre todo la regla de oro: los permisos se heredan hacia abajo siempre, nunca hacia arriba. Y en esta parte sí que me voy a parar, es la que me interesa. Azure trabaja con RBAC. RBAC significa Role Based Access Control. ¿Y qué significa eso? Pues que el control de todos los recursos de Azure van a través de los roles que hemos dicho. Cómo se asignan. Hay 4 tipos de roles, en verdad hay más, pero los principales son estos 4. Está el de owner, está el de contributor, está el de reader y está el de administrator, más que user access administrator. Las diferencias: el owner manda, o sea, el owner es el jefe, es el patrón, puede hacer y deshacer a su antojo y puede hacerlo absolutamente lo que quiera. Por eso es owner, por eso es el dueño. Esto es, vamos, el permiso con más privilegios de todo el tema, por así decirlo. Luego tenemos los permisos de administrador, que son los que se encargan de gestionar permisos en sí, pues asignar, quitar permisos dentro del recurso. Asignar permisos a Manage Identity, todo este tipo de acciones. Luego tenemos los permisos de Contributor, que son los que se encargan de gestionar el recurso en sí, es decir, modificaciones del recurso, cambios, actualizaciones, ediciones, todo lo que sea hacer cosas. Y luego tenemos los permisos de Reader, que son los permisos que te garantizan leer el recurso o tener visibilidad sobre el recurso. Ojo, que tener permisos de contributor no te garantizan tener permisos de reader. Por lo tanto, puede ser que tú seas capaz en una instancia de Sentinel de editar parámetros de Sentinel, crear analytic rules, crear incidentes on demand, pero luego, si no tienes los permisos de reader, no ser capaz de leer los incidentes o de abrir los incidentes. Entonces es muy importante eso. Los roles asignan lo que dicen y no más. No por tener el rol de owner vas a poder ver los recursos. Podrás asignarte el poder verlos, el rol para poder verlos, pero no te garantiza el poder verlos, vale. Luego aquí ya pues tenemos más, tenemos pues no sé, en el caso de Security Operations tenemos el Security Operator. Tenemos Security Reader, tenemos Password Administrator, que te ayuda, bueno, que te permite resetear password, Privilege Authentication Administrator, bla, bla, bla. Todos estos roles entran dentro de cada aplicación y cada aplicación tendrá los suyos. Es decir, no serán los mismos roles para un administrador de bases de datos SQL que para un analista de ciberseguridad. Eso hay que entenderlo. Entonces, No voy a entrar a explicar cada rol que vamos a necesitar, eso lo iré haciendo poco a poco con todos los vídeos que vayamos haciendo, pero sí que un poco para nuestro caso, en nuestro test tenant, vamos a necesitar estos de aquí. Vamos a necesitar el Log Analytics Reader. ¿Por qué? Porque Sentinel trabaja bajo un Log Analytics Workspace. Entonces, básicamente nos garantiza esto poder leer logs. Y el Log Analytics Contributor para poder realizar KQLs, para poder crear, borrar incidentes, modificarlos, etc. Obviamente no podremos asignar permisos, como vemos en esta tabla. Aquí lo tenéis todo en detalle, no voy a entrar tan, tan a fondo porque es que ya te digo, me podría estar todo el día explicando roles. Para que veáis otro ejemplo, en el caso de reader, pues ver los recursos, ver la instancia de Sentinel. En el user access administrator puedes asignar roles a otras personas. Gestionar los accesos, los permisos, pero ojo, tampoco podemos tocar los recursos, necesitamos el owner. Vale, pues me he saltado cosas del post que no me interesaban o que ya había explicado, pero esto sí que me interesa explicarlo. PIM, Privilege Identity Management. ¿Qué es esto? Recordamos los 4 tipos de permisos que había dicho, que eran owner, reader, contributor y admin. Pues estos tipos de roles pueden ser activos o elegibles, y tenemos estos assignments. ¿Qué diferencia hay? Los active assignments son roles que siempre tenemos disponibles y por lo tanto podemos utilizar. Es decir, si yo soy reader en una instancia de Sentinel, pues yo cada vez que inicie sesión con mi cuenta voy a tener acceso a esa instancia de Sentinel. Los elegibles, en cambio, Tenemos que pedirlos a través de PIM, que es una plataforma dentro de Azure, es una herramienta más. ¿Qué tiene de bueno esto? Que son auditables. Es decir, yo para obtener el permiso tengo que solicitarlo y pedirlo y dar una business justification. Un caso de uso sería, pues por ejemplo, quiero, soy analista de seguridad de nivel 1, no tengo permiso para reiniciar la contraseña a un usuario, pero sí que lo tengo elegible. Entonces yo a través de PIM pido el permiso necesario para resetear la contraseña al usuario y doy como justificación pues el ID de la investigación o lo que tenga. Y entonces el encargado verifica eso, me da el permiso, me lo aprueba o me lo deniega. Y una vez aprobado, lo tendré aprobado por un cierto tiempo limitado, una hora, dos horas, lo necesario, lo que se estipule. Entonces yo ejecuto la acción y pasado ese tiempo pierdo el permiso. Entonces, esto está muy bien por temas de auditoría y está muy bien también por controlar las acciones de tus usuarios, los cambios dentro de tu tenant. Si tú no es que no te fíes de todos tus administradores dentro del tenant, pero si tú quieres llevar una auditoría de todo, cada administrador para pedirte el permiso necesario va a necesitar darte una business justification y quizá un ticket o lo que necesites. Entonces esto también es muy importante y se usa mucho. Aquí lo tenéis más, más en profundidad. Entonces las Managed Identities ya las he explicado. Aquí tenéis un ejemplo de cuándo usar cada tipo de identidad, y aquí tenéis un caso práctico por si lo queréis revisar. Dicho esto, bueno, aquí también tenéis, perdón, roles elegibles, entra ID, etcétera. Sigamos con un ejemplo práctico. Aquí es de cuando creé los grupos, yo los grupos que os he enseñado antes. Aquí tenéis un paso a paso de cómo crear los grupos. No lo voy a repetir porque ya los tengo creados, pero vamos, es que es súper sencillo. No voy a hacer un tutorial de esto porque Es literalmente seguir los pasos del blog. Y como podéis ver, aquí en este caso creo un resource group para asignarle permisos a este resource group. Insisto, el tema del resource group lo volveremos a hacer en un vídeo cuando cree la instancia de Sentinel, que no deberá tardar mucho. Creo que el siguiente vídeo será un tutorial de KQL. Y poca cosa más. Al final es ir creando los grupos, ir asignando los permisos, como veis aquí. Y aquí tenéis un resumen. Así que nada, esto era para hacer un poco de resumen. Hemos visto cómo funciona pues la, toda la jerarquía de permisos dentro de Azure. Recordamos, está el tenant, luego los management groups, luego las subscriptions, luego los resource groups. Y luego los resources en sí. Luego hemos visto qué tipos de permisos tenemos. Están owner, administrator, contributor, reader. Luego hemos visto también qué tipo de assignments a estos roles tenemos, que están los active assignments y los eligible assignments. Y a quién le podemos dar estos permisos, que es a usuarios, a cuentas de usuario, a grupos, que es lo recomendado, a managed identities y a service principals. Dicho esto, lo tenéis todo en el blog. Tenéis los links abajo, tenéis la caja de comentarios, en la sección de Sobre mí, si entráis aquí, aquí abajo tenéis contacto. Os recomiendo suscribiros a la newsletter, aquí os llegará todo. Tenéis el perfil de LinkedIn, lo tenéis todo. De todas formas, cualquier duda, contact@aliops.net, ahí también me podéis enviar un correo. El correo está en la sección de Sobre mí. Por preguntas que no quede. Entonces, decidme también si os gusta el nuevo formato en el que no estoy parando tanto, en el que, bueno, quizá me trabo un poco, quizá me lío un poco más, o quizá me voy un poco por las nubes, pero, pero bueno, creo que queda más natural. Y nada, nos vemos en el siguiente vídeo. Que vaya muy bien. Chao.