Seguridad Registros Aplicaciones Azure

Los Registros de Aplicaciones Azure son uno de los lugares donde el privilegio del tenant se vuelve invisible con más facilidad. Un registro de aplicación puede parecer un detalle de integración, pero su service principal puede tener permisos de aplicación de Microsoft Graph, credenciales activas y rutas de acceso a nivel de tenant que no dependen de un usuario con sesión iniciada.

¿Qué son los riesgos de los Registros de Aplicaciones de Azure?

Los Registros de Aplicaciones Azure son los objetos de identidad detrás de aplicaciones personalizadas, automatizaciones, integraciones y muchas conexiones SaaS de terceros en Microsoft Entra ID. Pueden autenticarse frente a Microsoft Graph, recursos de Azure y otras APIs protegidas.

El riesgo aparece cuando esas aplicaciones conservan más permisos de los que necesitan, mantienen credenciales más tiempo del debido, o permanecen en el tenant mucho después de que el propietario original dejó de prestarles atención. En ese estado, la aplicación se comporta como una identidad privilegiada permanente, con mucha menos visibilidad humana cotidiana que una cuenta de usuario administrador.

Una buena revisión no consiste solo en encontrar un permiso peligroso. Consiste en demostrar qué aplicaciones están activas, cuáles tienen acceso de aplicación de alto privilegio, quién es su propietario y cómo se gobiernan sus credenciales.

Cómo funciona

Los registros de aplicaciones suelen autenticarse con uno de dos tipos de credenciales:

client secrets
certificados

La aplicación actúa entonces según los permisos otorgados a su service principal correspondiente.

Importan dos modelos amplios de permisos:

permisos delegados, donde la app actúa en el contexto de un usuario con sesión iniciada
permisos de aplicación, donde la app actúa como sí misma, sin ningún usuario presente

La documentación de Microsoft Graph es explícita sobre la diferencia: los permisos de aplicación son permisos exclusivos de la app, usados sin un usuario con sesión iniciada. Una app daemon o un servicio backend puede usarlos para llamar a las APIs como sí misma. Si la app tiene un permiso de aplicación amplio, el radio de impacto lo determina ese permiso y el recurso, no la sesión actual de un usuario interactivo.

Los casos de mayor riesgo suelen ser permisos de aplicación que otorgan acceso amplio a datos de todo el tenant o capacidad de modificación del directorio. Si un atacante obtiene la credencial de la app, hereda todo el poder de API que la app ya posee.

Registros de Aplicaciones Azure: qué las hace de alto riesgo

El patrón peligroso suele ser una combinación, no una única casilla:

permisos de aplicación amplios, como acceso a buzones, archivos o directorio a nivel de todo el tenant
credenciales de larga duración, con rotación débil, o copiadas en varios lugares
ningún propietario claro para la app o su service principal
ninguna actividad de inicio de sesión reciente, lo que sugiere que la app puede estar abandonada pero sigue siendo de confianza
consentimiento de administrador otorgado hace mucho tiempo, sin revisión recurrente

Por eso una revisión de permisos sin revisión de propiedad está incompleta. Una app con permisos moderados y sin propietario puede convertirse igualmente en un incidente serio cuando se filtra el secret y nadie nota los inicios de sesión.

Existe también una segunda distinción práctica importante: algunas apps son riesgosas porque pueden escribir o administrar, mientras que otras lo son porque pueden leer silenciosamente grandes volúmenes de datos del tenant. Ambos casos merecen revisión, incluso cuando el portal los etiqueta como conjuntos de permisos diferentes.

Datos sobre permisos que cambian el riesgo

No trate cada permiso de Graph como intercambiable. Microsoft documenta que los permisos de aplicación pueden operar sin un usuario con sesión iniciada, y que algunos permisos permiten acceso a nivel de organización a los datos asociados. Por ejemplo, un permiso amplio de archivos, correo, directorio o gestión de aplicaciones puede ser más dañino que un permiso delegado que solo funciona dentro de una sesión de usuario restringida.

Los permisos de gestión de aplicaciones merecen atención especial. La referencia de permisos de Microsoft Graph advierte que los permisos capaces de gestionar credenciales pueden permitir que una aplicación actúe como otras entidades y use los privilegios que se les han otorgado. Esa es una clase de riesgo distinta a la de una app que solo lee su propio perfil.

El consentimiento de administrador también forma parte del límite de control. Los permisos de aplicación solo pueden ser consentidos por un administrador, nunca por un usuario final. Específicamente para los permisos de aplicación de Microsoft Graph, Microsoft documenta que solo Privileged Role Administrator y Global Administrator pueden dar consentimiento; Application Administrator y Cloud Application Administrator pueden consentir permisos de aplicación excluyendo Microsoft Graph. Si el tenant no cuenta con una revisión recurrente de las aplicaciones con consentimiento de administrador, el modelo de acceso efectivo puede desviarse durante años después de que el proyecto original haya terminado.

La cadena de ataque

Paso 1 - Enumerar los registros de aplicaciones y sus permisos

Connect-MgGraph -Scopes 'Application.Read.All'

Get-MgApplication -All | ForEach-Object {
  $app = $_
  $sp = Get-MgServicePrincipal -Filter "appId eq '$($app.AppId)'"
  $appRoles = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id

  [PSCustomObject]@{
    AppName      = $app.DisplayName
    AppId        = $app.AppId
    Created      = $app.CreatedDateTime
    SecretExpiry = ($app.PasswordCredentials | Sort-Object EndDateTime | Select-Object -Last 1).EndDateTime
    Permissions  = ($appRoles | ForEach-Object { "$($_.ResourceDisplayName):$($_.AppRoleId)" }) -join ', '
  }
} | Where-Object { $_.Permissions -ne '' }

Paso 2 - Priorizar las combinaciones más sensibles

Concéntrese primero en las aplicaciones que combinan permisos amplios de tenant con credenciales obsoletas o propiedad poco clara. Los service principals que ostentan directamente roles de administrador de Entra son un caso aparte y a menudo peor, tratado en Rol de Administrador de Service Principal en Entra Sobreprivilegiado: Detección y Corrección.

Un orden de triaje útil:

aplicaciones con permisos de aplicación hacia Microsoft Graph o cargas de trabajo de Exchange
aplicaciones con permisos de gestión de apps o de gestión del directorio
service principals con credenciales activas pero sin evidencia de inicio de sesión reciente
apps con múltiples secrets o certificados activos que ningún propietario puede explicar
apps con consentimiento de administrador pero sin propietario de negocio actual

Paso 3 - Obtener la credencial

Los client secrets suelen quedar expuestos en repositorios de código, pipelines de despliegue, archivos de configuración locales o notas operativas copiadas. El problema no es que los secrets puedan filtrarse en teoría. El problema es que muchos tenants siguen dependiendo de secrets de larga duración para apps de alto valor.

Paso 4 - Autenticarse como la aplicación y usar el scope otorgado

import msal

app = msal.ConfidentialClientApplication(
    client_id='APP_CLIENT_ID',
    client_credential='STOLEN_SECRET',
    authority='https://login.microsoftonline.com/TENANT_ID'
)
result = app.acquire_token_for_client(scopes=['https://graph.microsoft.com/.default'])
token = result['access_token']

En ese punto, la ruta de ataque queda determinada por los permisos ya otorgados a la app, no por ningún exploit administrativo nuevo.

Detección

Señales de auditoría e inicio de sesión de Entra

Señal	Qué buscar
Add application	Nuevos registros de aplicaciones fuera de las ventanas de cambio esperadas
Add service principal credentials	Nuevo client secret o certificado añadido a un service principal
Update application - Certificates and secrets management	Nueva credencial añadida directamente en el objeto de la aplicación
Add app role assignment to service principal	Nuevo permiso de aplicación otorgado a una app
Consent to application	Nuevo consentimiento delegado o de administrador sobre permisos sensibles
Service principal sign-in	Autenticación de la app desde IPs, ubicaciones u horarios inusuales

Microsoft documenta los registros de inicio de sesión de service principal de forma separada de los inicios de sesión interactivos y no interactivos de usuario. Esos registros son importantes porque la autenticación exclusiva de app no involucra a un usuario humano. Microsoft también documenta que estos eventos se agregan: los inicios de sesión se agrupan en una sola fila cuando coinciden el nombre o ID del service principal, el estado, la dirección IP y el nombre o ID del recurso, así que expanda una fila antes de concluir que una app inició sesión una sola vez. Los inicios de sesión de managed identity no aparecen en este registro; tienen el suyo propio. Para los patrones de detección que funcionan específicamente sobre este registro, consulte Entra Service Principal: Detección de Anomalías de Inicio de Sesión, Puntos Ciegos de la Identidad de Carga de Trabajo.

Preguntas prácticas de revisión

qué apps tienen permisos de aplicación con alcance a todo el tenant
qué apps tienen múltiples secrets activos o secrets antiguos que nunca se eliminaron
qué apps no tienen inicio de sesión reciente pero conservan acceso privilegiado
qué apps no tienen propietario activo ni patrocinador de negocio
qué apps pueden gestionar aplicaciones, service principals, credenciales, grants o asignaciones de roles

Consulta de detección SIEM (Elastic KQL)

data_stream.dataset: "azure.auditlogs"
    and azure.auditlogs.operation_name: "Add service principal credentials"
    and event.outcome: "success"

Use el nombre de la actividad exactamente como lo publica Microsoft en la referencia de actividades de auditoría. Una credencial añadida en el objeto application se registra bajo una actividad distinta, Update application - Certificates and secrets management, así que una regla que solo vigile la actividad del service principal se pierde la mitad de los casos. Ese evento se vuelve mucho más útil al enriquecerlo con el propietario de la app, el inventario previo de credenciales y el nivel de permisos del service principal afectado.

Lógica de detección que reduce falsos positivos

Un secret nuevo en una app de prueba de bajo privilegio no es lo mismo que un secret nuevo en una app con permisos de aplicación de Graph y sin propietario. Priorice cruzando la actividad de auditoría con el inventario de apps:

permisos actuales de la app y estado de consentimiento
si la app usa permisos de aplicación o permisos delegados
cantidad de credenciales y fechas de expiración
momento del último inicio de sesión del service principal
número de propietarios y si siguen siendo empleados activos
si la IP de origen o la carga de trabajo cambió respecto a la línea base histórica

Remediación

Ganancia rápida: inventaríe cada aplicación con permisos de aplicación amplios y haga que el propietario certifique que el permiso y la credencial siguen siendo necesarios.

1. Eliminar o deshabilitar aplicaciones no utilizadas

Empiece por la antigüedad, pero no confunda antigüedad con desuso. La siguiente consulta lista aplicaciones registradas hace más de 90 días, que en un tenant maduro son la mayoría. Produce una lista de candidatos a revisión, no una lista de aplicaciones sin uso.

$cutoff = (Get-Date).AddDays(-90)
Get-MgApplication -All | Where-Object { $_.CreatedDateTime -lt $cutoff } |
  Select-Object DisplayName, AppId, CreatedDateTime

La señal de desuso es la autenticación, no la fecha de creación: revise los registros de inicio de sesión del service principal para la app, o el informe Service principal sign-in activity usage and insights, que sigue en preview al momento de escribir esto. Use en conjunto la revisión de actividad, propiedad y dependencias. Si nadie puede explicar por qué la app sigue existiendo, no debería conservar acceso permanente.

2. Rotar y reducir credenciales

Get-MgApplication -All | ForEach-Object {
  $app = $_
  $app.PasswordCredentials |
    Where-Object { $_.EndDateTime -lt (Get-Date).AddDays(30) } |
    Select-Object @{n='AppName';e={$app.DisplayName}}, DisplayName, EndDateTime
}

Rote los secrets antiguos, elimine los secrets sustituidos y evite dejar activas varias credenciales válidas sin motivo. Si una credencial se copió en código, pipelines o documentación, trate la rotación como un solo paso. La ubicación de almacenamiento anterior también necesita limpieza.

3. Preferir una gestión de credenciales más robusta

Microsoft publica un orden de preferencia explícito, y no comienza con los certificados. Use una managed identity siempre que la carga de trabajo se ejecute en Azure: Microsoft la califica como la opción más segura y la recomienda con firmeza. Si la carga de trabajo se ejecuta en otro lugar, en una plataforma que ofrezca gestión automatizada de credenciales, use en su lugar workload identity federation. Solo cuando ninguna de las dos sea posible debería recurrir a credenciales de certificado, almacenadas en un key vault y emitidas por una CA de confianza en lugar de autofirmadas.

La guía de Microsoft sobre secrets es directa: «Don't use password credentials, also known as secrets». Los secrets son cómodos, y precisamente por eso terminan copiados en herramientas de desarrollo y operaciones. Las políticas de gestión de aplicaciones también pueden limitar la vida útil de los secrets o bloquear su uso por completo.

4. Reducir el alcance de permisos

Revise si la app realmente necesita permisos de aplicación. Cuando sea posible:

sustituya permisos de escritura amplios por permisos de lectura o con alcance más estrecho
prefiera permisos delegados cuando exista un contexto de usuario real
elimine el consentimiento de administrador que ya no esté justificado por la carga de trabajo
evite otorgar permisos de gestión de apps salvo que la carga de trabajo realmente gestione aplicaciones
documente por qué cada permiso de aplicación restante es necesario

5. Restringir quién puede crear aplicaciones y otorgar consentimiento

Microsoft ofrece configuraciones de tenant y roles delegados para controlar quién puede registrar aplicaciones y quién puede otorgar consentimiento a aplicaciones. Deshabilite el registro amplio de apps por usuarios y el consentimiento de usuario donde el negocio no lo necesite, y asigne después roles explícitos a los equipos que sí lo necesitan.

Esto no es solo gobernanza. Evita que el tenant reintroduzca el mismo problema tras la limpieza. Si cualquiera puede crear apps y solicitar permisos amplios sin una vía de revisión, la proliferación de apps privilegiadas volverá.

Validar antes de cerrar el hallazgo

Una revisión de registros de aplicaciones no está completa cuando el portal simplemente se ve más limpio. Valide el resultado frente al comportamiento real del tenant.

exporte las apps de alto riesgo restantes, sus propietarios, sus credenciales activas y sus permisos efectivos
confirme que los secrets antiguos se eliminaron, no solo se sustituyeron mientras la credencial anterior seguía activa
verifique que la app sigue funcionando tras reducir permisos o rotar credenciales
confirme que las aplicaciones abandonadas se deshabilitaron o eliminaron realmente, en lugar de quedar como excepciones no documentadas
revise los registros de inicio de sesión del service principal después del cambio para confirmar que no quedan IPs de origen o recursos inesperados
vuelva a revisar los permisos con consentimiento de administrador y confirme que la lista coincide con el inventario de aplicaciones

Revise también la vía de gobernanza que lo rodea: quién puede crear apps, quién puede otorgar consentimiento de administrador, y quién debe aprobar el acceso de aplicación privilegiado. Sin ese control, el mismo patrón regresará en el siguiente ciclo de proyectos.

Cómo lo detecta EtcSec

EtcSec hace útiles los hallazgos de registros de aplicaciones combinando privilegio, antigüedad de credenciales, brechas de propiedad y señales de actividad. Un tenant normalmente no falla porque tenga muchas aplicaciones. Falla porque un número reducido de aplicaciones tiene permisos amplios, higiene de credenciales débil y ninguna vía de revisión clara.

El modelo de detección está basado en exposición: permisos de aplicación amplios, credenciales que siguen siendo válidas, propiedad poco clara y actividad de service principal que no coincide con el caso de uso documentado. Cada uno de esos elementos se corresponde con una verificación dedicada: permisos peligrosos de correo, archivos, directorio y roles otorgados a una app; aplicaciones con múltiples secrets activos o sin rotación de credenciales; aplicaciones y service principals sin propietario; concesiones de consentimiento a nivel de todo el tenant; y service principals que aún conservan credenciales obsoletas. El valor está en el cruce de datos, no en una sola señal aislada.

Registros de Aplicaciones Azure: Apps Sobreprivilegiadas