Políticas de la organización y restricciones

Una restricción se aplica en una organización, una carpeta o un proyecto, y sus descendientes la heredan por defecto. Hay restricciones booleanas, que se aplican o no (por ejemplo, impedir crear llaves de cuentas de servicio), y restricciones de lista, que permiten o deniegan valores (por ejemplo, las ubicaciones donde se pueden crear recursos). Una política definida en un nodo hijo puede reemplazar a la del padre, y eso requiere un permiso propio, el de administrador de políticas de la organización.

Por eso un revisor no se queda en lo que dice la organización: baja por cada nodo y mira si alguno la anula.

Abre el laboratorio. El archivo politicas-por-nodo.json es la exportación de lo que cada nodo define. Lo normal es que cada restricción aparezca una vez, en el nivel donde se quiere aplicar; lo que debe llamar la atención es una política en un nodo bajo que lleve la misma restricción con enforce: false.

Aplicar una restricción de golpe puede romper cosas que funcionaban. Para eso existe el modo de simulación (dry-run): la política se evalúa, las violaciones se registran en el registro de auditoría y la acción no se deniega. Se deja una temporada, se lee qué se habría bloqueado, se corrige a los equipos y entonces se aplica. En la exportación se ve porque la política lleva dryRunSpec y no spec.

En el laboratorio, el archivo registro-de-simulacion.jsonl guarda lo que dos restricciones en simulación habrían bloqueado desde el 1 de noviembre. Cada línea indica la restricción violada, quién lo pidió y qué recurso.

Una de las dos restricciones simuladas es constraints/gcp.restrictNonCmekServices: con la lista de servicios denegados storage.googleapis.com, bloquearía crear buckets que no usen llaves del cliente (Cloud KMS, la sala anterior). La otra, constraints/gcp.resourceLocations, limita las ubicaciones. Las violaciones de cada una están mezcladas en el mismo registro.

Las restricciones no son retroactivas: si un recurso ya existía en un estado que la restricción prohíbe, la política lo considera en violación, pero el servicio no cambia lo que ya hacía. Aplicar la restricción de acceso uniforme en la organización asegura que los buckets nuevos nazcan bien, no que los viejos se corrijan solos. Por eso, después de aplicar, hay que volver a inventariar.

En buckets-y-fechas.txt está la fecha en que se aplicó la restricción de acceso uniforme y, por bucket, su fecha de creación y si lo tiene activado.

En AWS las barandillas equivalentes son las políticas de control de servicios de AWS Organizations, que fijan lo máximo que se puede permitir en una cuenta; en Azure, Azure Policy sobre grupos de administración y suscripciones, con efectos que auditan o deniegan. La idea es la misma en los tres: la regla vive en la jerarquía y no depende de la memoria de cada equipo.