Hola a todos y bienvenidos de nuevo.
Ahora, en el vídeo de hoy, vamos a hablar de estrategias para utilizar las políticas de control de servicios.
Ahora, en una visión general de alto nivel, hay dos estrategias principales que puede utilizar para configurar
los pasos dentro de su cuenta.
Una es la estrategia basada en la lista de denegaciones y la otra es la estrategia basada en la lista de permitidos.
Así que en el vídeo de hoy vamos a hablar de ambos con todo detalle.
Ahora, el primer enfoque primario es la lista de denegación, y en la lista de denegación, las acciones están permitidas por
defecto a nivel de IP.
Y luego especifica cuáles son los servicios y acciones que quiere denegar.
Ahora, cuando hablamos de organizaciones y políticas de control de servicios, por defecto,
hacen uso de esta estrategia basada en listas de denegación, y esto se consigue utilizando la política CB de acceso total que se adjunta
a la raíz.
Ahora, si echamos un vistazo rápido a cómo es esta política de acceso completo, esta es la declaración de política
donde todo está permitido por defecto.
Ahora, tenga en cuenta que esto puede ser un poco confuso porque la estrategia de negación es en realidad ha permitido.
Así que esto es un poco confuso para empezar.
Ahora, veamos también esto rápidamente.
Ahora, actualmente estoy en la organización que no tiene el IPS habilitado.
Así que si usted mira en una de las cuentas de aquí, si usted mira en las políticas, no hay políticas
que se asocian ahora en esta etapa.
Cada vez que habilitamos las políticas de control de servicios, en esta etapa vemos que hay una política
primaria que se crea que es la de acceso total.
Se trata de una póliza gestionada.
Y si nos fijamos en esto, los objetivos de las políticas, se asocia con la raíz y todas las cuentas que forman
parte ahora en este enfoque de base.
Si te fijas en la declaración política general, lo permite todo.
Así que, por defecto, todo estará permitido a nivel de SP y luego usted denegará explícitamente cualquier servicio que quiera
prohibir.
Por ejemplo, si no quiere que nadie se conecte con el servicio, añada una declaración deny explícitamente.
Ahora tenga en cuenta que como se trata de una política gestionada, hay ciertas restricciones, por lo que puede seguir adelante y crear
un nuevo conjunto de políticas.
No podrás realizar diversas operaciones.
Por ejemplo, si quieres borrarlo, vamos a probarlo como acceso total.
Y si ves en la descripción pone que no se puede modificar y gestionar la política.
Sólo se leen genial.
Una vez entendido esto, veamos algunas de las ventajas que aporta este tipo de estrategia.
Como ya sabemos, utilizando la estrategia de denegación, el administrador de la cuenta puede delegar todos los servicios
y acciones hasta que cree un PPC adjunto que deniegue un servicio específico.
Así que por defecto todo estará permitido.
Y luego añades la política de denegación explícita para denegar un servicio o acción específicos.
Así que aquí hay que señalar que las declaraciones deny requieren menos mantenimiento porque no es necesario
actualizar la política cuando añade nuevos servicios.
Así que un tiene cientos de servicios ahora desde que ha permitido explícitamente todos los servicios en el nivel ACP, usted realmente
no necesita preocuparse porque incluso si se lanza un nuevo servicio, los usuarios tendrán el acceso a él.
Teniendo en cuenta que tienen los permisos adecuados.
Aparte de eso, otra de las ventajas es que las sentencias deny suelen ocupar menos espacio, por lo que es más fácil
no sobrepasar el tamaño máximo de las políticas de control de servicios.
Ahora, si nos fijamos en el ejemplo de política basada en la lista de denegación, podría ser algo como esto, donde
usted tiene una declaración fuerte y luego tiene una declaración de denegación explícita en la acción y el servicio.
Así que aquí la acción es Dynamo DB estrella con este básico, también vamos a ver en la estrategia número dos,
que es permitir lista.
Ahora para hacer uso de allow list, lo que puedes hacer, es reemplazar el ACP a managed full access por un
nuevo ACP que permita explícitamente sólo aquellos servicios y acciones que quieras permitir.
Ahora tienes que recordar que al eliminar el ACP de acceso total por defecto, todas las acciones para todos los servicios
están ahora implícitamente denegadas.
Es muy importante recordar esta parte.
Y luego, dado que todas las acciones y servicios están denegados implícitamente, añades un ACP personalizado que anula esta denegación
implícita con el permiso explícito sólo para las acciones que quieres permitir.
Así que si miras este ejemplo de política basada en listas de permitidos, este es el aspecto que tiene.
Por lo tanto, aquí se supone que este ACP de acceso total no está asociado a las cuentas.
Y luego añades esta política específica que permite ciertos servicios como EC two star cloud watch star.
Por tanto, aparte de este conjunto de servicios, los usuarios no podrán realizar operaciones en ninguno de ellos.
Ahora, antes de seguir adelante, también vamos a tener una demostración rápida asociada a esto.
Ahora, permítanme también mostrarles rápidamente una demostración.
Ahora, en esta fase, ten en cuenta que sólo lo estamos analizando desde la perspectiva de la demostración para asegurarnos de que nuestros
conceptos se entienden mejor.
Así que para la demostración de hoy tengo una política más de la lista de permisos de la universidad.
Así que si miras en la política de la lista de permitidos, está asociada con la raíz y también está asociada con
una cuenta sandbox.
Ahora, para que esta política de lista de permitidos entre en vigor, tienes que asegurarte de que tu acceso
total no está asociado a las cuentas.
Así que si nos fijamos en los objetivos, sólo se asocia con la cuenta de gestión aquí.
No está asociada a ninguna otra cuenta.
Así que si tengo que mostrarte.
Así que en root tenemos la cuenta de gestión y la cuenta sandbox.
Así que esta política específica que tenemos, la política de lista de permitidos, esta asociada si miras en la cuenta
sandbox y no hay una política de acceso completo aquí.
Así que vamos a probarlo rápidamente.
Así que si nos fijamos en el contenido, que está permitiendo a la CE de dos estrellas y la nube de reloj estrella ahora para probar las cosas.
Estoy conectado como usuario root a una de las cuentas miembro.
Ahora dentro ya que sabemos sólo CE dos y cloud watcher permitido, vamos a tratar de explorar otros
servicios como SES inmediatamente.
Verás, tenemos un error que indica que hay una denegación en el ACP.
Probemos también un servicio más.
Voy a decir API gateway de nuevo, estamos recibiendo un error.
Del mismo modo, vamos a probar e c a esta vez y ec dos funciona perfectamente bien.
Podrá lanzar instancias, etc.
De acuerdo.
Así que espero que con esto hayas entendido lo básico de la lista de permitidos y la lista de denegados.
Ahora de nuevo, una cosa que quería mostrar, vamos a ver rápidamente aquí.
Si usted mira en esta caja de arena políticas de la cuenta que es sólo permitir la política de la lista.
Aquí no existe una política de acceso total.
Y esta es la razón por la que las cosas están surtiendo efecto.
Antes de concluir, debemos tener en cuenta algunos puntos importantes.
La primera es que cada root o tu y cuenta debe tener al menos una política de control de servicios adjunta.
Y esta es la razón por la que, si quieres reemplazar la política de acceso total por defecto por una ACP que limite el permiso,
entonces debes adjuntar la ACP de reemplazo antes de eliminar la por defecto.
Así, por ejemplo, en esta etapa verás que la cuenta sandbox tiene una política de lista de permitidos.
Por lo tanto, en el momento oportuno, debe adjuntarse una póliza.
Así que si quieres cambiar de una lista a una lista de denegación, entonces lo que tienes que hacer, tienes que asociar una política
de lista de denegación y luego puedes eliminar la lista de permiso.
Estupendo.
Este es el resumen de las estrategias que puedes utilizar.
De nuevo, por lo que he visto en las organizaciones, la mayoría de ellas, utilizan su estrategia por defecto basada en listas de
denegación.
No optan por permitir lista en caso de que si usted está utilizando una lista de baja, aunque esto se ve bien, pero también
requiere una gran cantidad de esfuerzos.
Y en la mayoría de las organizaciones, el equipo de seguridad o el equipo que está gestionando todos los ssps, son
bastante pequeños y no tienen la cantidad necesaria de tiempo y recursos para gestionar la política de listas permitidas,
aparte de otras configuraciones relacionadas con la seguridad en las que tienen que trabajar como parte de la infraestructura
general.
Con esto concluiremos el vídeo de hoy.