Imagen destacada del artículo: Amazon Route 53 e ISO 27001: cómo convertir el DNS en un control de seguridad auditable

Amazon Route 53 e ISO 27001: cómo convertir el DNS en un control de seguridad auditable

Fecha de publicación:

El DNS: ese gran olvidado en las auditorías ISO 27001

Cuando hablamos de ISO 27001, lo primero que viene a la mente son políticas, documentación interminable y procedimientos. Después entran en escena los firewalls, el cifrado, IAM… y el DNS se queda en un segundo plano. Gran error.

Te lo digo por experiencia: en una arquitectura cloud, el DNS no es solo un servicio técnico más. Es un punto de control de seguridad crítico que, bien gestionado con Route 53, puede mapearse directamente a controles reales del Anexo A.

Este artículo no va de “cumplir por cumplir” ni de crear documentación que nadie lee. Va de usar Amazon Route 53 como parte activa de tu SGSI (Sistema de Gestión de Seguridad de la Información), de forma técnica, justificable y, lo más importante, auditable ante una certificación ISO 27001.

El DNS también forma parte del perímetro de seguridad

ISO 27001 no te dice qué tecnologías usar (no es una guía técnica), pero sí establece requisitos claros sobre control de accesos, segregación, disponibilidad, integridad y trazabilidad. Y adivina qué: el DNS toca todas esas áreas.

La pregunta del millón en auditorías

Imagina esta situación típica de auditor:

“¿Cómo controlan y protegen los puntos de entrada a sus sistemas?”

Si tu respuesta es únicamente “tenemos firewalls y load balancers”, estás dejando fuera el primer punto por el que pasa cualquier conexión: la resolución DNS.

Route 53 vive fuera de tu VPC, es global y altamente disponible. Esto lo convierte en un control previo al propio cloud, ideal para reforzar principios clave del SGSI incluso antes de que el tráfico llegue a tu infraestructura.

Route 53 dentro del contexto ISO 27001: enfoque basado en riesgos

ISO 27001 se basa en la gestión de riesgos. Y el DNS, aunque a veces pase desapercibido, introduce riesgos muy reales:

  • Redirección de tráfico no autorizada: Un cambio malicioso puede enviar usuarios a servidores controlados por atacantes
  • Cambios no controlados en registros críticos: Sin trazabilidad ni aprobación formal
  • Caídas de servicio por errores de configuración: Un cambio manual mal hecho puede tumbar todo el servicio
  • Falta de trazabilidad en cambios: ¿Quién modificó qué y cuándo?

Lo bueno es que Route 53 permite mitigar estos riesgos de forma técnica, no solo documental. Y eso es música para los oídos de cualquier auditor.

Mapeo práctico con controles del Anexo A

Vamos a lo concreto. Así es como Route 53 se alinea con controles específicos del Anexo A de ISO 27001.

A.9 - Control de acceso y segregación de funciones

Uno de los puntos más sensibles en cualquier auditoría es quién puede tocar qué. Con Route 53 puedes implementar:

Políticas IAM granulares:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["route53:GetHostedZone", "route53:ListResourceRecordSets"],
    "Resource": "*"
  }, {
    "Effect": "Allow",
    "Action": "route53:ChangeResourceRecordSets",
    "Resource": "arn:aws:route53:::hostedzone/Z1234567890ABC",
    "Condition": {
      "StringEquals": {
        "aws:RequestedRegion": "eu-west-1"
      }
    }
  }]
}

Controles que implementas:

  • Limitar quién puede modificar zonas DNS específicas
  • Separar cuentas (producción, staging, desarrollo)
  • Delegar subzonas sin compartir control total
  • Aplicar MFA para cambios críticos

Esto encaja perfectamente con el principio de mínimo privilegio y la separación de responsabilidades. No todo el mundo debería poder cambiar el DNS de producción. Y Route 53 te permite demostrarlo con políticas claras, no con buenas intenciones.

A.12.1 - Gestión del cambio y trazabilidad

ISO 27001 exige que los cambios relevantes estén controlados y sean trazables. No es negociable.

Aquí Route 53 juega muy bien con el ecosistema AWS:

CloudTrail para auditoría completa: Cada modificación en Route 53 queda registrada con:

  • Quién hizo el cambio (identidad IAM)
  • Cuándo se realizó (timestamp preciso)
  • Qué se modificó (cambios específicos en registros)
  • Desde dónde (IP de origen, región)

Integración con logs centralizados: Puedes enviar estos logs a S3, CloudWatch Logs o incluso a tu SIEM corporativo para análisis centralizado.

Respuesta auditable: Cuando el auditor te pregunta:

“¿Cómo saben que nadie ha modificado el DNS sin autorización?”

No respondes con un “confiamos en nuestro equipo”. Respondes mostrando los logs de CloudTrail filtrados por `ChangeResourceRecordSets`, con cada cambio documentado y atribuible.

A.17 - Disponibilidad y continuidad del servicio

La disponibilidad es uno de los pilares de ISO 27001. Y el DNS, créeme, no es opcional en tu plan de continuidad.

Con Route 53 puedes implementar:

Políticas de routing inteligente:

  • Failover automático: Si tu servidor primario cae, el tráfico se redirige automáticamente a un secundario
  • Geoproximity routing: Dirige usuarios al endpoint más cercano y saludable
  • Health checks activos: Monitorización continua de la salud de tus endpoints

Multi-región por diseño:

www.ejemplo.com → Health Check EU-West-1 (Primary)
                ↓ (si falla)
                → Health Check US-East-1 (Failover)

Desde el punto de vista del SGSI, esto se traduce en:

  • ✅ Reducción del impacto de interrupciones (objetivo de tiempo de recuperación menor)
  • ✅ Medidas técnicas de continuidad del negocio
  • ✅ Evidencias claras de diseño resiliente

No es teoría ni PowerPoints bonitos. Es arquitectura real alineada con tu análisis de riesgos.

A.12.6 - Protección frente a errores humanos

Aquí va una verdad incómoda: muchos incidentes de seguridad no son ataques sofisticados, son errores humanos. Cambios mal hechos, prisas, falta de revisión o simplemente un viernes por la tarde.

Buenas prácticas con Route 53 alineadas con ISO 27001:

1. Infraestructura como código (IaC): Gestiona tu DNS con Terraform, CloudFormation o CDK:

resource "aws_route53_record" "www" {
  zone_id = aws_route53_zone.primary.zone_id
  name    = "www.ejemplo.com"
  type    = "A"
  ttl     = "300"
  records = [aws_eip.lb.public_ip]
}

2. Proceso de revisión (peer review): Los cambios en DNS pasan por pull requests, como cualquier otro código crítico.

3. Evitar cambios manuales en producción: Si alguien necesita modificar algo urgente, hay un proceso documentado y con aprobación.

4. Testing en staging primero: Pruebas los cambios DNS en entornos no productivos antes de aplicarlos.

Esto reduce el riesgo operacional y demuestra madurez en la gestión técnica. Los auditores valoran mucho más esta aproximación que una política bonita colgada en SharePoint que nadie lee.

A.8 - DNS como activo dentro del inventario de información

ISO 27001 exige identificar, clasificar y proteger activos. El DNS es definitivamente un activo crítico, aunque a veces no se documente como tal en el inventario.

Route 53 facilita la gestión de activos:

Centralización de dominios: Todos tus dominios en un único lugar, con visibilidad completa de:

  • Qué zonas DNS existen
  • Qué registros contienen
  • Quién es el responsable técnico
  • Nivel de criticidad para el negocio

Etiquetado (tagging) para clasificación:

Dominio: www.ejemplo.com
Tags:
  - Environment: Production
  - Criticality: High
  - Owner: equipo-plataforma
  - DataClassification: Public

Documentación auditable: Esto encaja perfectamente con la gestión de activos del SGSI: sabes qué dominios existen, para qué sirven, quién los gestiona y cómo protegerlos según su criticidad.

Route 53 y evidencias para auditoría: de la teoría a la práctica

Uno de los mayores dolores de cabeza en una certificación ISO 27001 es demostrar que lo que dices en los procedimientos es verdad. No basta con escribir “tenemos controles de seguridad robustos”.

Route 53 te permite aportar evidencias técnicas concretas:

Evidencias que suman puntos en auditoría

Control declaradoEvidencia técnica con Route 53
Control de accesosPolíticas IAM exportadas, roles con MFA obligatorio
Gestión de cambiosLogs de CloudTrail con historial completo de modificaciones
Segregación de entornosZonas DNS separadas (prod.ejemplo.com, staging.ejemplo.com)
Alta disponibilidadHealth checks configurados, políticas de failover activas
TrazabilidadDashboard de CloudWatch con métricas y alarmas

Todo esto es infinitamente más sólido que una declaración genérica tipo “nuestros sistemas están protegidos” o un procedimiento de Word que nadie sigue.

Consejo de auditoría: Prepara capturas de pantalla de la consola AWS (o mejor, exportaciones en JSON) mostrando la configuración real. Los auditores aprecian la evidencia visual y verificable.

El DNS como control preventivo, no solo reactivo

Desde una visión SRE y de seguridad, Route 53 no es solo un servicio que reacciona a problemas. También puede prevenir incidentes antes de que ocurran.

Ejemplos de controles preventivos con Route 53

1. Bloquear tráfico a servicios no autorizados: Si desactivas un servicio legacy, eliminas sus registros DNS. Así evitas que usuarios (o scripts automáticos) sigan accediendo a él.

2. Redirigir tráfico ante comportamientos anómalos: Integrado con AWS Shield y WAF, puedes desviar tráfico sospechoso a un endpoint de análisis o directamente bloquearlo.

3. Aislar sistemas comprometidos a nivel DNS: Si detectas una brecha de seguridad en un servidor, puedes cambiar su registro DNS para:

  • Redirigir a una página de mantenimiento
  • Enviar tráfico a un honeypot
  • Eliminar temporalmente la resolución

4. Geofencing por compliance: Usando políticas de geolocalización, puedes restringir el acceso desde países donde no operas o donde el riesgo de fraude es alto:

api.ejemplo.com → Solo accesible desde EU
                → Bloqueado desde otras regiones

Estas decisiones ocurren antes de que el tráfico toque tu infraestructura. Desde el punto de vista de ISO 27001, eso es control temprano del riesgo, y eso es oro en auditoría.

Errores típicos en auditorías ISO 27001 relacionados con DNS

He he topado con estos fallos cuando preparaba la certificación:

❌ Error #1: DNS gestionado “por costumbre”

Problema: Nadie sabe realmente quién es el responsable del DNS. “Siempre lo ha gestionado Juan, pero ya no trabaja aquí”.

Solución con Route 53: Define responsables claros en el SGSI y usa IAM para asignar roles específicos (DNS Admin, DNS Reader, DNS Operator).

❌ Error #2: Cambios manuales sin registro formal

Problema: Alguien cambia un registro A desde la consola web un sábado a las 3 AM y no queda rastro documentado.

Solución con Route 53: CloudTrail + notificaciones SNS para cualquier cambio. Si alguien toca algo, salta una alerta y queda registrado.

❌ Error #3: Mezclar proveedores DNS sin criterio

Problema: Algunos dominios en GoDaddy, otros en Cloudflare, otros en Route 53… sin ningún criterio de seguridad.

Solución: Centralizar en Route 53 (o al menos documentar por qué usas múltiples proveedores en tu análisis de riesgos).

❌ Error #4: No considerar el DNS en el análisis de riesgos

Problema: El DNS no aparece como activo ni como amenaza potencial en el SGSI.

Solución: Incluir explícitamente el DNS en tu inventario de activos y en la evaluación de riesgos. Documenta amenazas como DNS spoofing, DDoS en DNS, cambios no autorizados, etc.

Route 53 no evita estos errores mágicamente, pero hace mucho más fácil corregirlos si lo integras bien en tu SGSI.

Conclusión: el DNS merece un lugar en tu SGSI

Amazon Route 53 no es solo un servicio de red más en tu stack tecnológico. En un contexto de ISO 27001, puede convertirse en un control de seguridad técnico, auditable y perfectamente alineado con la gestión de riesgos.

Tratar el DNS como parte integral del SGSI no es exagerado ni es complicar las cosas innecesariamente. Es simplemente coherente con cómo funcionan las arquitecturas cloud modernas y con las amenazas reales que enfrentan.

Puntos clave para llevarte

  1. El DNS es un activo crítico que debe estar en tu inventario y análisis de riesgos
  2. Route 53 mapea directamente a controles del Anexo A: acceso, trazabilidad, disponibilidad
  3. Las evidencias técnicas valen más que los documentos: CloudTrail > PowerPoint
  4. El control preventivo es mejor que el reactivo: actúa antes de que el tráfico llegue a tu infra
  5. La gestión como código reduce el riesgo humano: Terraform/CloudFormation para DNS

Si tu organización quiere una ISO 27001 real, no solo de papel, el DNS tiene que estar en la conversación desde el principio. Y Route 53, con su integración nativa en el ecosistema AWS, es una de las mejores herramientas para hacerlo bien desde el primer punto de entrada al sistema.