Latest / M365.FM – Podcast de Microsoft 365, Copilot e IA en español / Azure Policy vs. RBAC: quién puede hacer qué y qué configuraciones están permitidas – guía clara de gobernanza en Azure (Doblaje IA)

Transcript

Azure Policy vs. RBAC: quién puede hacer qué y qué configuraciones están permitidas – guía clara de gobernanza en Azure (Doblaje IA) · M365.FM – Podcast de Microsoft 365, Copilot e IA en español

0:03
Speaker 2: Hoy hablaremos de una función de Azure de la que
0:05
Speaker 2: probablemente hayas oído hablar, pero que quizá no entiendas del todo.
0:07
Speaker 2: Azure Policy es una de las herramientas de gobernanza más
0:10
Speaker 2: potentes de toda la plataforma, pero la mayoría de las
0:12
Speaker 2: personas la ignoran o creen que es solo para administradores
0:14
Speaker 2: de TI. Al final de este episodio, sabrás qué es
0:17
Speaker 2: Azure Policy en realidad, cómo funciona como un libro de
0:20
Speaker 2: reglas invisible y por qué es esencial para mantener tu
0:22
Speaker 2: entorno de Azure seguro y bajo control. Lo desglosaremos en
0:26
Speaker 2: bloques de construcción claros, empezando por el problema que resuelve.
0:28
Speaker 2: Toma tu café y vamos a sumérginos en él. El problema.
0:32
Speaker 2: Porque la nube necesita barandillas. Piensa en la antigua forma
0:34
Speaker 2: de hacer las cosas. En las instalaciones, cuando necesitabas un servidor,
0:38
Speaker 2: enviabas una solicitud al equipo de operación. Ellos realizaban las reglas,
0:42
Speaker 2: las directivas de la empresa, los estándares de seguridad, tal
0:44
Speaker 2: vez algunos requisitos normativos, y a continuación te aprovisionaban el servidor.
0:47
Speaker 2: Un guardián humano se interponía entre tú y la infraestructura.
0:50
Speaker 2: Esa persona conocía las reglas y se aseguraba de que
0:52
Speaker 2: no se escaparan. La nube cambió eso por completo. Ahora
0:54
Speaker 2: el dueño de la app tiene acceso directo sin nadie
0:57
Speaker 2: de por medio. Haz clic en crear en Azure Portal
0:59
Speaker 2: y se realizará al instante. También puedes usar la línea
1:02
Speaker 2: de comandos, una API o herramientas de infraestructura como código
1:05
Speaker 2: como Terraform. El problema es que nadie comprueba tu trabajo
1:08
Speaker 2: antes de que se quede el recurso. Y ahí es
1:09
Speaker 2: donde empieza el problema. Muchos dueños de apps desconocentes arreglan.
1:12
Speaker 2: Quizás no se dan cuenta de que la política de
1:14
Speaker 2: la empresa exige que todos los datos sigan en Europa.
1:16
Speaker 2: O que las cuentas de almacenamiento deben bloquear el acceso público.
1:18
Speaker 2: O que determinados tamaños de máquina virtual son cars on
1:21
Speaker 2: cars en producción sin que sigan adelante y crean recursos
1:23
Speaker 2: y a veces se producen errores. Una máquina virtual se
1:26
Speaker 2: implementa con una IP pública y puertos abiertos a Internet.
1:29
Speaker 2: Una cuenta de almacenamiento se crea con acceso público a blobs,
1:31
Speaker 2: lo que expone datos confidenciales. Alguien pone en marcha una
1:34
Speaker 2: costosa instancia de GPU para una prueba rápida y se
1:36
Speaker 2: olvida de eliminarla. Estas cosas pasan todo el tiempo. Lo
1:39
Speaker 2: que necesitamos es un sistema de cumplimiento automático que funcione siempre,
1:42
Speaker 2: sin importar quién crea el recurso o cómo lo haga.
1:45
Speaker 2: Ya sea el portal, la CLI, una llamada a la
1:47
Speaker 2: API o una implementación de Terraform en las reglas, deben
1:49
Speaker 2: comprobarse automáticamente. Y eso es exactamente para lo que se
1:52
Speaker 2: creó Azure Policy.¿ Qué es Azure Policy? El libro de
1:55
Speaker 2: reglas invisible. Entonces,¿ qué es Azure Policy? Esa es la
1:58
Speaker 2: definición más simple. Azure Policy es un servicio que te
2:00
Speaker 2: permite definir reglas para tus recursos de Azure y las
2:03
Speaker 2: aplica automáticamente. Piensa en ello como el libro de reglas
2:05
Speaker 2: de un juego de mesa. El juego tiene muchos movimientos posibles,
2:08
Speaker 2: pero el libro de reglas dice cuáles están realmente permitidos.
2:10
Speaker 2: No puedes mover tu pieza donde quieras. Las reglas te
2:13
Speaker 2: dicen qué es legal y qué no. Ahora bien, aquí
2:15
Speaker 2: hay una distinción fundamental. Azure Policy no es lo mismo
2:17
Speaker 2: que un control de acceso a zanroles o RBACs. RBACs
2:20
Speaker 2: controla quién puede hacer algo. Responde a la pregunta de
2:22
Speaker 2: quién tiene permiso para crear recursos en esta suscripción. Azure
2:25
Speaker 2: Policy controla lo que se puede hacer o, más precisamente,
2:28
Speaker 2: qué configuraciones están permitidas. Responde a la pregunta de qué
2:30
Speaker 2: tipo de recursos se pueden crear y cómo se deben configurar.
2:34
Speaker 2: CKR base indica que Mirko puede crear cuentas de almacenamiento
2:37
Speaker 2: y Azure Policy exige que éstas tengan HTTPS habilitado. Dos
2:40
Speaker 2: cosas diferentes y necesitas algo. Esta es la clave. Azure
2:43
Speaker 2: Policy siempre está activa y siempre se aplica. Cada solicitud
2:46
Speaker 2: para crear, actualizar o eliminar un recurso pasa por Azure
2:49
Speaker 2: Policy y no hay forma de evitarla. Se encuentra entre
2:52
Speaker 2: usted y Azure Resource Manager, el plano de control de Azure.
2:55
Speaker 2: Imagínese que es un filtro automático. Cada solicitud pasa por
2:58
Speaker 2: este filtro, y si no coincide con las reglas, la
3:00
Speaker 2: solicitud se bloquea o marca, y no funciona solo con
3:02
Speaker 2: recursos nuevos. Azure Policy también evalúa los recursos existentes, por
3:06
Speaker 2: lo que detecta desviaciones de la configuración con el tiempo.
3:09
Speaker 2: Si alguien cambia una configuración en un recurso que ya
3:11
Speaker 2: ha implementado y ese cambio infringe una directiva, Azure Policy
3:14
Speaker 2: lo marcará. Entonces,¿ cómo se escriben realmente estas reglas? Ahí
3:17
Speaker 2: intervienen las definiciones de directivas. Definiciones de directivas, redactar las reglas. Entonces,¿
3:22
Speaker 2: cómo se escriben realmente estas reglas? Ahí es donde entran
3:24
Speaker 2: en juego las definiciones de directivas. Una definición de directiva
3:26
Speaker 2: es la regla en sí misma y se escribe como
3:28
Speaker 2: un documento JSON. JSON puede sonar técnico, pero la estructura
3:31
Speaker 2: es bastante simple. Sigue un patrón básico. Si esta condición
3:34
Speaker 2: es verdadera, entonces se aplica este efecto. Permítame darle un
3:37
Speaker 2: ejemplo breve. Hay una política integrada que dice que si
3:39
Speaker 2: una cuenta de almacenamiento no tiene HTTPS habilitado, denigue el A.
3:43
Speaker 2: Eso es todo. Cuando la condición es verdadera, el efecto
3:45
Speaker 2: entra en acción y bloquea la implementación. Cada definición de
3:47
Speaker 2: política tiene tres partes claras. Primero, las condiciones. Esa es
3:50
Speaker 2: la parte if. Está comprobando. El tipo de recurso, la ubicación,
3:54
Speaker 2: una configuración específica. Segundo, los efectos. Esa es la parte
3:57
Speaker 2: de dan. Eso sucede cuando se cumple la condición. Bloqueas
3:59
Speaker 2: la implementación no solo en la marca. Tercero, los parámetros.
4:02
Speaker 2: Estos son los espacios en blanco que hacen que la
4:04
Speaker 2: política sea reutilizada. Los parámetros son donde entra en juego
4:07
Speaker 2: el verdadero poder. Imagina que quieres escribir una política que
4:10
Speaker 2: solo permita recursos en ciertas regiones. No quieres escribir una
4:13
Speaker 2: política diferente para cada combinación posible de regiones. Su lugar
4:16
Speaker 2: escribes una definición llamada ubicaciones permitidas, que agregas un parámetro
4:20
Speaker 2: para las regiones permitidas. Cuando asignas la política, rellenas el
4:22
Speaker 2: espacio en blanco. Quizás dices Europa Occidental y Europa del
4:25
Speaker 2: Norte para una suscripción y este de E-E-U y oeste
4:27
Speaker 2: de U para otra. Misma definición, parámetros diferentes. Así es
4:30
Speaker 2: como se mantienen las cosas en la línea. No tienes
4:33
Speaker 2: que escribir todo esto desde cero. Microsoft proporciona cientos de
4:36
Speaker 2: definiciones de directivas integradas que puedes empezar a usar de inmediato.
4:39
Speaker 2: Abarcan categorías como proceso, almacenamiento, redes, centro de seguridad, etiquetado,
4:42
Speaker 2: administración de costos y más. Puedes encontrarlas en Azure Portal,
4:45
Speaker 2: buscar lo que necesitas y asignarlas de inmediato. No se
4:48
Speaker 2: requiere JSON si no quieres escribirlo. Pero una definición en
4:51
Speaker 2: un archivo no hace nada. tienes que asignarla para que funcione.
4:54
Speaker 2: Asignaciones de directivas, poner reglas en función. Una asignación de
4:58
Speaker 2: directivas es cuando tomas tu definición y la diriges a
5:00
Speaker 2: un ámbito específico. Un ámbito es solo el límite donde
5:02
Speaker 2: se aplica esa regla. Tienes tres opciones, de la más
5:04
Speaker 2: amplia a la más estricta. Asignarla en el nivel del
5:07
Speaker 2: grupo de administración y cubrirá todo un conjunto de suscripciones.
5:10
Speaker 2: Suéltala en el nivel de suscripción y cubrirá todo lo
5:12
Speaker 2: que hay dentro de esa suscripción. O asignarla en el
5:14
Speaker 2: nivel del grupo de recursos y solo cubrirá los recursos
5:16
Speaker 2: dentro de ese grupo. Ahora, hablemos de la herencia. Este
5:19
Speaker 2: es un concepto clave. Cuando asignas una política en el
5:21
Speaker 2: nivel del grupo de administración, ésta se transmite automáticamente a
5:24
Speaker 2: cada suscripción y grupo de recursos subyacente. No necesitas asignarla
5:27
Speaker 2: una y otra vez. Es como publicar una regla en
5:29
Speaker 2: el tablón de anuncios principal de la entrada de un
5:31
Speaker 2: edificio de oficina. Todos los que pasan por allí deben seguirla.¿
5:34
Speaker 2: No publicarías la misma regla en todas las plantas? Eso
5:37
Speaker 2: sería una fuerza de experiencia. La regla es simplemente semanal.¿
5:39
Speaker 2: Pero qué ocurre cuando necesitas una excepción? Puede que tu
5:41
Speaker 2: empresa diga que todos los datos deben permanecer en Europa,
5:43
Speaker 2: pero un proyecto tiene una razón legítima para usar un
5:45
Speaker 2: centro de datos en Asia. No quieres eliminar toda la
5:47
Speaker 2: política porque eso dejaría todo expuesto. Por lo tanto, creas
5:50
Speaker 2: una exención. Las exenciones te permiten hacer excepciones para recursos
5:53
Speaker 2: o grupos de recursos específicos sin anular la política en
5:56
Speaker 2: el resto. Es una forma sencilla de gestionar casos externos.
5:58
Speaker 2: Aquí tienes una guía práctica. Asigne tus políticas fundamentales generales
6:03
Speaker 2: en el nivel del grupo de administración. Cosas como ubicaciones
6:05
Speaker 2: permitidas o etiquetas obligatorias deberían aplicarse a todo. Luego, asigna
6:09
Speaker 2: políticas más específicas en el de suscripción o grupo de recursos.
6:12
Speaker 2: Puede que tu suscripción de desarrollo tenga reglas más flexibles
6:14
Speaker 2: que tu suscripción de producción. Eso está perfectamente bien. Las
6:17
Speaker 2: políticas específicas se suman a las generales. Ahora, hablemos de
6:19
Speaker 2: lo que realmente ocurre cuando alguien incumple una regla. Ahí
6:22
Speaker 2: es donde entra en juego el segundo. Efectos.¿ Qué ocurre
6:24
Speaker 2: cuando se incumple una regla? Por lo tanto, escrito una regla,
6:27
Speaker 2: él asigna.¿ Qué ocurre cuando alguien la incumple? Ahí es
6:29
Speaker 2: donde entra en juego el segundo. Los efectos son la
6:31
Speaker 2: parte de la política. Deciden qué ocurre cuando un recurso
6:35
Speaker 2: no coincide con la regla. Hay cuatro principales que verán.
6:38
Speaker 2: En primer lugar, denegar es el efecto más común para
6:40
Speaker 2: las reglas críticas. Cuando se activa una política de denegación,
6:44
Speaker 2: la implementación se bloquea por completo. El usuario recibe un
6:46
Speaker 2: mensaje de error claro que indica que la validación ha
6:48
Speaker 2: fallado y explica que política lo detuvo. No se crea
6:51
Speaker 2: ningún recurso, no hay daño. Utilice esto para reglas que
6:54
Speaker 2: nunca se deben incumplir. Como el acceso público a blobs
6:57
Speaker 2: en cuentas de almacenamiento o despliegues fuera de regiones aprobadas.
7:01
Speaker 2: Segundo lugar, la auditoría. Esta funciona de forma diferente. La
7:04
Speaker 2: implementación se realiza, pero el recurso se marca como no
7:06
Speaker 2: conforme en el panel de cumplimiento. La auditoría es increíblemente
7:09
Speaker 2: útil cuando no estás seguro de cómo afectará una nueva
7:11
Speaker 2: regla a tu entorno. Puedes ver lo que está pasando
7:13
Speaker 2: sin romper nada cómo tomar una medida antes de aplicar
7:16
Speaker 2: un cambio. Tercero, modifica y anexa. Estos efectos corrigen el
7:20
Speaker 2: problema automáticamente en lugar de bloquearlo. Modifica la configuración existente
7:24
Speaker 2: durante el implemento. Anexa añade algo a un campo existente.
7:27
Speaker 2: Por ejemplo, busque una política que añada automáticamente una etiqueta
7:29
Speaker 2: obligatoria con un valor predeterminado. Si alguien olvida añadir una
7:33
Speaker 2: etiqueta de centro de coste, la política la añade por ellos,
7:35
Speaker 2: la implementación se realiza y el recurso es compatible sin
7:38
Speaker 2: trabajo adicional. Cuarto, implementa si no existe. Esta gestiona situaciones
7:42
Speaker 2: en las que falta un recurso de apoyo. Supongamos que
7:45
Speaker 2: quieres habilitar el registro diagnóstico en cada cuenta de almacenamiento.
7:47
Speaker 2: Si alguien crea una cuenta de almacenamiento sin configuración de diagnóstico,
7:50
Speaker 2: implementa si no existe y automáticamente implementa la configuración que falta.
7:54
Speaker 2: Es como tener un ayudante que la impide atrás de ti.
7:56
Speaker 2: Esta es la mejor práctica. Empieza con el auditorio. Primero,
7:58
Speaker 2: observa lo que realmente está pasando en tu entorno. Descubre
8:01
Speaker 2: cuántos recursos se verían afectados por una nueva regla. Luego,
8:03
Speaker 2: pasa de negar una vez que estés seguro de que
8:05
Speaker 2: la regla es correcta y no interrumpirá las implementaciones legítimas.
8:08
Speaker 2: Administrar una política es sencillo.¿ Pero qué pasa si necesitas 50,
8:11
Speaker 2: todas relacionadas con la seguridad o cumplimiento? Ahí es donde
8:13
Speaker 2: entra en juego la ciencia. iniciativas que agrupan reglas. Entonces,¿
8:17
Speaker 2: qué es una iniciativa? Piensa en ella como una colección
8:19
Speaker 2: de políticas agrupadas en torno a un objetivo común. En
8:22
Speaker 2: lugar de asignar 50 políticas individuales una por una, asignas
8:25
Speaker 2: una única iniciativa que las contiene todas. Es como un
8:28
Speaker 2: kit de herramientas pero empaquetado para un trabajo especial. No
8:31
Speaker 2: coges un martillo, un destornillador y una llave inglesa por separado.
8:33
Speaker 2: Simplemente coges todo el kit de herramientas. Todo lo que
8:35
Speaker 2: necesitas está en un solo lugar. La ventaja aquí es
8:37
Speaker 2: la generación de informes de cumplimiento. Cuando asignas una iniciativa,
8:39
Speaker 2: obtienes una única vista de cumplimiento para todo el grupo.
8:42
Speaker 2: Puedes ver de un vistazo si tu entorno cumple con
8:44
Speaker 2: el estándar general Si algo no cumple, puedes profundizar directamente
8:47
Speaker 2: en la política específica que está fallando. Es mucho más
8:50
Speaker 2: limpio que seguir 50 políticas por separado. Microsoft proporciona iniciativas
8:54
Speaker 2: integradas que cubren los principales marcos de cumplimiento. Cosas como
8:57
Speaker 2: Azure Security Benchmark, CS, NIST, PCI, DSS, IPA, ISO, 2701
9:01
Speaker 2: y más. Estas ya están creadas y listas para asignar.
9:06
Speaker 2: No tiene que averiguar qué directivas se asignan a qué
9:08
Speaker 2: requisito de cumplimiento. Microsoft de trabajo por usted. Algunas de
9:11
Speaker 2: estas iniciativas contienen cientos de directivas individuales. Imagina intentar asignarlas
9:15
Speaker 2: todas una por una. 9. Utilizar iniciativa. También puede crear
9:18
Speaker 2: iniciativas personalizadas para sus propios estándares. Quizás tenga una línea
9:21
Speaker 2: base de producción que incluya directivas para cifrado, registro y
9:24
Speaker 2: seguridad de red. O una iniciativa de estándares de control
9:27
Speaker 2: de costes que limite los tamaños de las máquinas virtuales
9:29
Speaker 2: y requiere etiquetas de centro de coste. Dame idea. Agrupe
9:32
Speaker 2: las directivas, asigna el paquete y controle su cumplimiento como
9:34
Speaker 2: una sola unidad. Hagamos que esto sea concreto con ejemplos
9:36
Speaker 2: del mundo real de cómo las personas usan Azure Policy.
9:39
Speaker 2: Ejemplos del mundo real. Directiva en acción. Hagámoslo realidad. Aquí
9:44
Speaker 2: hay cinco escenarios comunes en los que Azure Policy resuelve
9:46
Speaker 2: problemas reales. Primero, restricciones regionales para cumplimiento de datos. Imagina
9:50
Speaker 2: que tu empresa tiene la política de que los datos
9:52
Speaker 2: de los clientes permanezcan en Europa. Puedes asignar la política
9:55
Speaker 2: integrada de ubicaciones permitidas en el nivel del grupo de
9:58
Speaker 2: administración RAIS y permitir solo regiones de la OE como
10:00
Speaker 2: Europa Occidental y Europa del Norte. Ahora, cuando alguien crea
10:02
Speaker 2: una nueva suscripción, esta hereda automáticamente se arregla. No puede
10:05
Speaker 2: implementar recursos en U o Asia, aunque lo intente. La
10:09
Speaker 2: política lo bloquea. Sin comprobaciones manuales ni solicitudes de premio.
10:12
Speaker 2: La regla simplemente se aplica. Segundo, la aplicación de etiquetas
10:14
Speaker 2: para coste. Tu equipo de finanzas necesita realizar un seguimiento
10:17
Speaker 2: del gasto por departamento. pero no pueden hacerlo si los
10:20
Speaker 2: recursos no tienen las etiquetas adecuadas. Por lo tanto, creas
10:22
Speaker 2: una política que requiere una etiqueta de centro de costes
10:24
Speaker 2: y una etiqueta de entorno en cada recurso. Pero aquí
10:27
Speaker 2: está la parte inteligente. Utiliza el efecto de modificación. Si
10:30
Speaker 2: alguien olvida agregar la etiqueta, la política la agrega automáticamente
10:32
Speaker 2: con un valor predeterminado. La implementación se realiza y el
10:35
Speaker 2: recurso cumple con él. Binance recibe datos de costes precisos
10:38
Speaker 2: y los desarrolladores no se bloquean por una etiqueta ausente. Tercero,
10:40
Speaker 2: el control de costes en desarrollo. A los equipos de
10:42
Speaker 2: desarrollo les encanta experimentar, pero los experimentos pueden salir caros.
10:45
Speaker 2: Alguien podría poner en marcha una instancia de GPU con
10:47
Speaker 2: 24 núcleos solo para probar una excepción. Si crea una
10:49
Speaker 2: política que restrinja el tamaño de las máquinas virtuales en
10:52
Speaker 2: suscripciones de DB, es cosminor. Cosas como la serie B
10:54
Speaker 2: o la serie D con núcleos limitados. Si alguien intenta
10:57
Speaker 2: implementar una GPU costosa o una máquina virtual con mucha memoria,
11:00
Speaker 2: el efecto de negación se activa y la bloquea. Los
11:02
Speaker 2: desarrolladores aún pueden experimentar, pero no pueden exceder el presupuesto. Cuarto,
11:05
Speaker 2: la línea base de seguridad de almacenamiento. Las cuentas de
11:07
Speaker 2: almacenamiento son uno de los lugares más comunes donde se
11:09
Speaker 2: producen errores de seguridad. Alguien crea una cuenta de almacenamiento
11:12
Speaker 2: con acceso público a Blobs y de repente los datos
11:14
Speaker 2: confidenciales quedan expuestos a Internet. Por lo tanto, crea una
11:17
Speaker 2: política que requiere tráfico HTTPS únicamente y bloquea el acceso
11:20
Speaker 2: público a Blobs. Y utiliza Deploy If Not Exist para
11:23
Speaker 2: habilitar automáticamente el registro de diagnóstico en cada cuenta de
11:25
Speaker 2: almacenamiento que no lo tenga. La política soluciona el problema
11:28
Speaker 2: antes de que éste ocurra. Quinto lugar, convenciones de Nomenclat.
11:32
Speaker 2: Su equipo quiere que todos los recursos comiencen con Prod
11:34
Speaker 2: o Dev para que puedan saber fácilmente a qué entorno
11:36
Speaker 2: pertenece algo. Creas una directiva que coteja el nombre del
11:40
Speaker 2: recurso con el patrón, pero en lugar de bloquear la implementación,
11:42
Speaker 2: usas el efecto de auditoría, usas el efecto de auditoría.
11:45
Speaker 2: El recurso se crea, pero se marca como no conforme.
11:48
Speaker 2: Luego ejecutas un informe de cumplimiento mensual y pides al
11:50
Speaker 2: equipo que corrija el mensual. Es una forma suave de
11:51
Speaker 2: aplicar estándares sin interrumpir los flujos de trabajo. Cada uno
11:54
Speaker 2: de estos ejemplos sigue el mismo patrón. Identifique el problema.
11:58
Speaker 2: Elige o crea la directiva. Decide el efecto, asigna el
12:01
Speaker 2: ámbito correcto y supervisa el cumplimiento. Ese es el manual.
12:04
Speaker 2: Ahora alejémonos y veamos cómo encajan todas estas piezas en
12:06
Speaker 2: el panorama general de la gobernanza de ASUM. el panorama general,
12:10
Speaker 2: cómo se conecta todo.¿ Dónde encaja Azure Policy en el
12:12
Speaker 2: panorama general? Hacémoslo de esta manera. Azure Policy funciona en
12:17
Speaker 2: el nivel del plano de control justo encima de Azure
12:19
Speaker 2: Resource Manager y evalúa cada solicitud que llega. Cada vez
12:23
Speaker 2: que alguien crea, actualiza o elimina un recurso Azure Policy
12:26
Speaker 2: y comprueba las reglas, es el guardián de la puerta principal.
12:30
Speaker 2: No es la única herramienta en la caja de gobernanza.
12:32
Speaker 2: Azure Policy es solo una parte de un sistema más grande.
12:34
Speaker 2: Los grupos de administración proporcionan la jerarquía para organizar tus
12:37
Speaker 2: suscripciones y aplicar reglas a escala. El control de acceso
12:40
Speaker 2: basado en errores decide quién tiene acceso a qué, mientras
12:42
Speaker 2: que Azure Policy controla qué configuraciones están permitidas. Juntos forman
12:46
Speaker 2: la base de la gobernanza de la nube. Ahora bien,
12:48
Speaker 2: aquí está la cuestión. Azure Policy también es el motor
12:50
Speaker 2: detrás de otros servicios que quizás ya uses. Microsoft Defender
12:53
Speaker 2: para la nube usa Azure Policy para generar sus recomendaciones
12:56
Speaker 2: de cumplimiento. Cuando Defender te indica que una cuenta de
12:58
Speaker 2: almacenamiento no cumple, está ejecutando una evaluación de directivas. Azure
13:02
Speaker 2: Advisor extrae muchas de sus recomendaciones de costo y confiabilidad
13:05
Speaker 2: de las mismas evaluaciones de directivas. y el panel de
13:08
Speaker 2: cumplimiento en Azure Portal todo creado a partir de datos
13:10
Speaker 2: de directivas. Por lo tanto, incluso si nunca has creado
13:12
Speaker 2: una directiva tú mismo, es probable que las hayas estado
13:14
Speaker 2: usando sin saberlo. Existe otra práctica denominada directiva como código.
13:18
Speaker 2: En lugar de crear directivas, a través del portal las
13:20
Speaker 2: almacenas como archivos JSON en un repositorio de Git y
13:22
Speaker 2: las implementas a través de canalizaciones de C y CGE
13:24
Speaker 2: como si fuera código de aplicación. Eso te proporciona control
13:27
Speaker 2: de versiones, revisiones de código y pruebas automatizadas para tu
13:30
Speaker 2: regla de governance. Es una forma más escalable de administrar
13:32
Speaker 2: directivas en grandes organizaciones. Esto es lo más importante que
13:35
Speaker 2: hay que recordar. Al configurar Azure Policy correctamente, se ejecuta
13:38
Speaker 2: de forma silenciosa de fondo. Es la barrera de protección
13:41
Speaker 2: automática que evita los problemas antes de que ocurran. Puede
13:44
Speaker 2: que los usuarios nunca sepan que está ahí, pero se
13:45
Speaker 2: benefician de ella cada vez que implementan un recurso. Obtienes
13:48
Speaker 2: una aplicación coherente en todo momento, sin comprobaciones manuales, tickets
13:51
Speaker 2: de aprobación ni errores humanos. Así es Azure Policy en
13:54
Speaker 2: un lenguaje sencillo. Es un libro de reglas invisible que
13:58
Speaker 2: aplica los estándares de tu organización en cada recurso en
14:00
Speaker 2: todo momento. Si quieres una sola acción de este episodio,
14:03
Speaker 2: aquí la tienes. Ve a el Azure Portal, busca la
14:06
Speaker 2: directiva y asigna la directiva de ubicaciones permitidas e integrada
14:09
Speaker 2: a una suscripción de prueba. Empiece con la auditoría y
14:11
Speaker 2: observa que ocurre. Es la forma más rápida de entender
14:14
Speaker 2: cómo funciona. Suscríbete para obtener más conocimientos básicos de Microsoft
14:17
Speaker 2: y compártelos con alguien que esté empezando su recorrido con él.
14:19
Speaker 2: Deja un comentario con lo que te gustaría explicar a continuación.