CAPÍTULO 7 · La identidad sale del equipo
Nombrar los recursos para que cuenten a qué pertenecen
Dentro del código, config y el prefijo de las apps nos ayudaron a ubicarnos. Al salir hacia la infraestructura aparece el mismo problema con otros objetos: registros de aplicación, grupos de recursos, servidores y entornos. Un nombre que solo entiende quien lo creó dificulta tanto una publicación como una investigación posterior.
Extendemos el acuerdo de nombres para reconocer aplicación, entorno y función. No buscamos nombres largos por sí mismos, sino pistas suficientes para distinguir lo que estamos tocando. También asociamos cada recurso con su responsable y su ciclo de vida: una prueba que terminó no debería permanecer indefinidamente solo porque nadie sabe si todavía se utiliza.
Ya podemos organizar las piezas externas con mayor claridad. Pero identificarlas no define qué confianza debemos depositar en ellas. Al integrar cuentas, aplicaciones y recursos necesitamos un criterio que nos impida considerar seguro todo lo que simplemente esté dentro de una misma organización.
Leer esta parte dentro del relato completo →DEL RELATO A LA PRÁCTICA
Vamos a desarrollar esta decisión con su mapa, explicación, código y ejercicio.
MIRA · CONECTA · COMPRENDE
Un nombre legible, un ID estable
Las flechas resumen el recorrido conceptual. Los controles y dependencias se detallan debajo.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- Convención. Tipo, entorno y servicio
- Identificador. Vincula el objeto real
- Propietario. Responde por el ciclo de vida
- Revisión. Renueva, verifica o retira
01 / EL PROBLEMA
¿Para qué sirve?
Cuando crecen los entornos, nombres ambiguos hacen fácil conceder acceso a la aplicación equivocada o eliminar un registro todavía usado.
02 / COMPRENDER
El concepto, explicado
Una convención puede indicar tipo, entorno y servicio: appe_prod_sensorhub. El prefijo es una decisión de tu equipo, no un estándar obligatorio de Entra.
El display name sirve a las personas y puede cambiar. Las integraciones deben usar identificadores estables; dos objetos pueden tener nombres parecidos y permisos diferentes.
El ciclo de vida incluye alta, asignación de dueño, revisión de acceso, renovación de credenciales y retiro. Un registro sin propietario o sin fecha de revisión queda fuera del gobierno operativo.
Separar local, pruebas y producción tiene sentido cuando tienen riesgo o configuración diferentes. Decide si local usa DEV o un registro independiente y explica el motivo en una decisión de arquitectura.
03 / CONSTRUIR
Implementación paso a paso
- Acuerda vocabulario y entornos permitidos.
- Asigna un nombre por función y entorno; distingue web y API si tienen registros separados.
- Registra IDs, dueño, criticidad y fecha de revisión en un inventario.
- Automatiza la validación de nombres en tus scripts internos.
- Antes del retiro identifica consumidores, revoca acceso y elimina credenciales después de la transición.
04 / APLICAR
Ejemplo en SensorHub
# Función pura para el inventario del equipo.
import re
def identity_name(environment, service):
if environment not in {"local", "dev", "prod"}:
raise ValueError("Entorno no reconocido")
if not re.fullmatch(r"[a-z][a-z0-9-]{1,39}", service):
raise ValueError("Servicio inválido")
return f"appe_{environment}_{service}"
assert identity_name("prod", "sensorhub") == "appe_prod_sensorhub"Cómo leer el ejemplo
- La función pertenece a UTIL_LIB si distintos scripts comparten la regla.
- Validar nombres no valida permisos ni demuestra aislamiento.
- Un inventario guarda el object ID y Client ID además del nombre visible.
Error habitual
Usar el nombre visible como clave de autorización o asumir que renombrar una app cambia su identidad.
05 / PRACTICAR
Tu turno
Agrega una aplicación API y especifica cómo retirar un antiguo registro local.
Ver solución orientativa
Usa servicios sensorhub-web y sensorhub-api. Revisa callbacks y consumidores del registro local, migra configuración, verifica funcionamiento y finalmente revoca sus credenciales.
06 / VERIFICAR
Cómo sabes que funciona
- Se rechazan entornos desconocidos.
- Cada objeto tiene un responsable.
- Una búsqueda por nombre se confirma mediante sus IDs.
Para profundizar
Documentación oficial para comprobar configuración, permisos y condiciones vigentes. Revisión del tema: 2026-10-11.
CONTINUAR LA EXPERIENCIA
El siguiente paso del recorrido:
Zero Trust: identidad, acceso y autorización →Continuar en modo relato