Control de Acceso en ISO 27001: Requisitos, Controles e Implementación para SaaS

El control de acceso es la práctica de garantizar que solo las personas autorizadas puedan acceder a información, sistemas y recursos específicos, y solo en la medida que su rol lo requiera. En ISO 27001, el control de acceso abarca múltiples controles del Annex A y afecta prácticamente a todas las áreas de las operaciones de una empresa SaaS, desde la incorporación de empleados hasta la administración de bases de datos en producción o la autenticación de APIs orientadas al cliente.

Para las empresas SaaS, el control de acceso es simultáneamente el dominio más importante y más complejo de implementar correctamente. Tu producto funciona sobre infraestructura en la nube gestionada por equipos distribuidos. Los ingenieros necesitan acceso a los sistemas de producción. Los equipos de éxito del cliente necesitan acceso a los datos de los clientes para brindar soporte. Las integraciones con terceros necesitan credenciales de API. Los pipelines de CI/CD necesitan claves de despliegue. Cada una de estas rutas de acceso debe ser gobernada, monitoreada y revisada.

Esta guía cubre todos los requisitos de control de acceso de ISO 27001, los controles específicos del Annex A que aplican y orientación práctica de implementación para empresas SaaS que operan en plataformas modernas en la nube.

Controles Relevantes del Annex A

ISO 27001:2022 reorganizó sus controles en cuatro temas: Organizacionales, Personas, Físicos y Tecnológicos. El control de acceso abarca los temas Organizacional y Tecnológico. Comprender qué controles aplican — y qué exige cada uno — es la base de tu política de control de acceso.

Controles Organizacionales

A.5.15 — Control de acceso El control general. Requiere que se establezcan e implementen reglas que regulen el acceso a la información y otros activos asociados, basándose en requisitos de negocio y de seguridad de la información. Esta es tu política de control de acceso — el documento que define los principios (privilegio mínimo, necesidad de conocer, RBAC) que todos los demás controles de acceso implementan.

A.5.16 — Gestión de identidades Debe gestionarse el ciclo de vida completo de las identidades de usuario. Esto cubre la creación, mantenimiento y eliminación de identidades digitales. Para las empresas SaaS, esto significa gestionar identidades a través de tu proveedor de identidad (Okta, Azure AD, Google Workspace), plataformas en la nube, herramientas SaaS y aplicaciones internas.

A.5.17 — Información de autenticación Gestión de la información de autenticación (contraseñas, tokens, certificados, claves) a lo largo de todo su ciclo de vida. Esto incluye la asignación inicial, almacenamiento seguro, rotación y revocación. El control exige que la información de autenticación no se comparta entre individuos y que las credenciales predeterminadas se cambien inmediatamente tras el aprovisionamiento.

A.5.18 — Derechos de acceso Los derechos de acceso deben ser aprovisionados, revisados, modificados y eliminados de acuerdo con la política de control de acceso. Este es el control operativo que implementa tu modelo RBAC. Requiere un proceso definido para otorgar acceso, un mecanismo para ajustar el acceso cuando cambian los roles y un proceso definido para revocar el acceso cuando ya no es necesario.

Controles Tecnológicos

A.8.2 — Derechos de acceso privilegiado El acceso privilegiado (cuentas de administrador, acceso root, superusuario de base de datos) debe ser restringido y controlado. Este control requiere autorización explícita para el acceso privilegiado, separación de cuentas privilegiadas y regulares de usuario, registro de acciones privilegiadas y revisión periódica de los derechos de acceso privilegiado.

A.8.3 — Restricción de acceso a la información El acceso a la información debe ser restringido de acuerdo con la política de control de acceso. Esto se traduce en aplicación técnica: controles de acceso a bases de datos, reglas de autorización de aplicaciones, permisos del sistema de archivos, segmentación de red que impida rutas de acceso no autorizadas.

A.8.4 — Acceso al código fuente El acceso de lectura y escritura al código fuente, herramientas de desarrollo y configuraciones de software debe ser controlado. Para las empresas SaaS, esto significa gestión de acceso a repositorios, reglas de protección de ramas y requisitos de revisión de código.

A.8.5 — Autenticación segura Los mecanismos de autenticación deben ser apropiados para la sensibilidad de los sistemas y datos a los que se accede. Aquí es donde entran en juego los requisitos de autenticación multifactor (MFA), inicio de sesión único (SSO), autenticación sin contraseña y gestión de sesiones.

Construyendo tu Política de Control de Acceso

Tu política de control de acceso es el documento base que define principios, asigna responsabilidades y establece los requisitos que todos los procedimientos y controles técnicos posteriores implementan. Debe ser concisa, específica para tu organización y verificable. Para orientación sobre estructura y redacción de políticas, consulta nuestra guía de Políticas ISO 27001.

Principios Fundamentales

Toda política de control de acceso debe establecer estos principios:

Principio de privilegio mínimo. A los usuarios se les otorgan los derechos de acceso mínimos necesarios para realizar sus funciones laborales. El acceso no se concede por defecto — debe ser solicitado, justificado y aprobado explícitamente.

Base de necesidad de conocer. El acceso a la información se restringe a las personas que lo requieren para su rol específico. Tener una habilitación de seguridad o antigüedad no confiere automáticamente acceso a toda la información de ese nivel.

Segregación de funciones. Las funciones críticas se dividen entre múltiples individuos para evitar que una sola persona tenga control de extremo a extremo sobre un proceso sensible. En términos SaaS: la persona que escribe el código no debería ser la única aprobadora de sus propios despliegues a producción.

Denegación por defecto. El acceso se deniega por defecto y se otorga explícitamente según sea necesario. Esto aplica a reglas de red, permisos de aplicaciones, políticas de IAM en la nube y acceso a repositorios.

Alcance de la Política

Define exactamente qué cubre la política de control de acceso:

• Todos los sistemas y entornos de producción
• Toda la infraestructura en la nube (cuentas y recursos de AWS, Azure, GCP)
• Todas las aplicaciones corporativas (correo electrónico, herramientas de colaboración, sistemas de RRHH)
• Todos los repositorios de código fuente
• Todas las bases de datos que contengan datos de clientes u organizacionales
• Todas las herramientas SaaS de terceros dentro del alcance del ISMS
• Todas las cuentas de servicio, claves API e identidades de máquina
• Todas las cuentas de empleados, contratistas y usuarios de terceros

Sé explícito sobre lo que queda fuera del alcance. Si tienes entornos sandbox de desarrollo que están intencionalmente excluidos del ISMS, establécelo claramente.

Aprovisionamiento y Desaprovisionamiento de Usuarios

El ciclo de vida del acceso — desde otorgar el acceso inicial hasta revocarlo cuando ya no es necesario — es donde el control de acceso funciona o falla. Los auditores prueban esto rigurosamente porque los errores de aprovisionamiento y desaprovisionamiento son la fuente más común de derechos de acceso excesivos.

Proceso de Aprovisionamiento

Un proceso de aprovisionamiento bien definido incluye:

1. Solicitud de acceso. Todo acceso debe ser solicitado formalmente. La solicitud debe especificar qué acceso se necesita, por qué y por cuánto tiempo. Para las empresas SaaS, esto típicamente significa un ticket en tu herramienta de gestión de proyectos (Jira, Linear, Asana) o una solicitud a través de tu plataforma de gestión de identidades.

2. Autorización. La solicitud debe ser aprobada por alguien con la autoridad para otorgar ese acceso — típicamente el gerente del empleado y/o el propietario del sistema. La aprobación debe estar documentada (no un “claro, adelante” verbal).

3. Implementación. El acceso se aprovisiona de acuerdo con la solicitud aprobada, utilizando roles predefinidos siempre que sea posible en lugar de permisos personalizados. La persona que implementa el acceso debe verificar que lo aprovisionado coincida con lo que fue aprobado.

4. Verificación. Después del aprovisionamiento, verifica que el usuario tenga el acceso correcto — ni más ni menos de lo que fue aprobado.

5. Documentación. El registro completo — solicitud, aprobación, implementación y verificación — debe conservarse para fines de auditoría.

Implementación SaaS: Utiliza tu proveedor de identidad (Okta, Azure AD, Google Workspace) como centro de acceso centralizado. Define políticas de acceso basadas en grupos donde añadir un usuario a un grupo aprovisione automáticamente el acceso correcto en las aplicaciones conectadas. La incorporación de un nuevo empleado activa un flujo de trabajo automatizado: RRHH crea el registro del empleado, el proveedor de identidad crea la cuenta y las membresías de grupo aprovisionan el acceso según el departamento y rol.

Control de Acceso Basado en Roles (RBAC)

RBAC es el modelo de gestión de acceso más práctico para empresas SaaS. En lugar de gestionar permisos usuario por usuario, defines roles que se corresponden con funciones laborales y asignas usuarios a roles.

Define roles basados en funciones laborales:

• Ingeniería — Desarrollador: Acceso de lectura/escritura a repositorios asignados, acceso de lectura a entornos de staging, sin acceso a producción
• Ingeniería — Desarrollador Senior: Igual que Desarrollador más acceso de lectura a logs y métricas de producción
• Ingeniería — DevOps/SRE: Igual que Desarrollador Senior más acceso de escritura a repositorios de infraestructura como código y capacidades de despliegue a producción
• Éxito del Cliente: Acceso de lectura a datos del cliente en el portal de soporte, sin acceso directo a base de datos
• Finanzas: Acceso a sistemas de facturación, sin acceso a sistemas de ingeniería
• Ejecutivos: Acceso a paneles e informes, sin acceso directo a sistemas

Principios de RBAC para SaaS:

• Mantén los roles lo suficientemente granulares para aplicar el privilegio mínimo pero no tan granulares que tengas un rol único por persona
• Documenta los derechos de acceso de cada rol y revísalos cuando las funciones laborales evolucionen
• Utiliza acceso basado en grupos en tu proveedor de identidad para implementar RBAC técnicamente
• Cuando alguien cambia de rol, revoca el acceso del rol anterior y aprovisiona el acceso del nuevo rol — no acumules permisos

Proceso de Desaprovisionamiento

El desaprovisionamiento es el área de mayor riesgo del control de acceso. Un exempleado o contratista con credenciales activas es un riesgo de seguridad grave y un hallazgo de auditoría garantizado.

Disparadores inmediatos para el desaprovisionamiento:

• Terminación del empleado (voluntaria o involuntaria)
• Finalización del contrato de un contratista
• Terminación de la relación con un tercero
• Transferencia del empleado a un rol que no requiere el acceso actual

Plazo requerido para el desaprovisionamiento: Tu política debe especificar un tiempo máximo entre el evento disparador y la eliminación del acceso. Para las empresas SaaS, la expectativa estándar es:

• Terminación involuntaria: Acceso revocado antes o en el momento en que se notifica al empleado, dentro del mismo día laboral
• Terminación voluntaria: Acceso revocado al final del último día laboral del empleado
• Cambios de rol: Acceso del rol anterior revocado dentro de 5 días hábiles desde la fecha efectiva del cambio de rol
• Finalización de contratista: Acceso revocado en el último día del contrato

Implementación SaaS: Integra tu sistema de RRHH con tu proveedor de identidad. Cuando RRHH procesa una terminación, el proveedor de identidad desactiva automáticamente la cuenta y revoca todo el acceso a aplicaciones conectadas. Para sistemas no conectados al proveedor de identidad (herramientas legacy, entornos específicos de clientes), mantén una lista de verificación de desaprovisionamiento y verifica la finalización.

Paso crítico frecuentemente omitido: Cuentas de servicio, credenciales compartidas y claves SSH asociadas con el individuo que se va. Si un exingeniero tenía acceso a claves SSH de producción, esas claves deben ser rotadas. Si contribuyó a credenciales de cuentas de servicio compartidas, esas credenciales deben ser cambiadas. Documenta esto en tu procedimiento de desaprovisionamiento.

Acceso al Cambiar de Rol

Los cambios de rol son una fuente significativa de acumulación de acceso — la acumulación gradual de permisos cuando los empleados se mueven entre equipos sin que se revoquen los permisos anteriores. Con el tiempo, una persona que comenzó en soporte de ingeniería y pasó por QA hasta gestión de producto podría retener acceso de los tres roles.

Prevén la acumulación de acceso mediante:

• Tratar las transferencias internas como un evento de desaprovisionamiento/reaprovisionamiento
• Comparar el acceso actual del usuario con los derechos de acceso definidos del rol objetivo
• Eliminar el acceso que no es necesario para el nuevo rol
• Documentar el cambio de acceso con el mismo rigor que el aprovisionamiento inicial

Gestión de Acceso Privilegiado

El acceso privilegiado — cuentas administrativas con permisos elevados — es la categoría de acceso más sensible y recibe el mayor escrutinio durante las auditorías de ISO 27001. El control A.8.2 se dirige específicamente al acceso privilegiado.

Qué Constituye Acceso Privilegiado en SaaS

• Administradores de plataforma en la nube: Cuenta root de AWS, administradores de IAM, Administradores Globales de Azure, Administradores de Organización de GCP
• Administradores de bases de datos: Superusuarios de bases de datos de producción, usuarios con capacidades de exportación de datos
• Gestión de infraestructura: Administradores de clústeres Kubernetes, administradores de red
• Administradores del proveedor de identidad: Super administradores de Okta, Administradores Globales de Azure AD
• Administradores de aplicaciones: Roles de administrador en herramientas SaaS que pueden ver todos los datos o modificar configuraciones de seguridad
• Acceso a pipelines de CI/CD: Cuentas que pueden desplegar a producción, modificar configuraciones de pipeline o acceder a secretos de despliegue

Controles de Acceso Privilegiado

Separar cuentas privilegiadas y regulares. Los administradores deben tener una cuenta estándar para el trabajo diario (correo, Slack, documentos) y una cuenta privilegiada separada para tareas administrativas. Esto reduce el radio de impacto si la cuenta de uso diario se ve comprometida.

Requerir autenticación más fuerte para el acceso privilegiado. Si se requiere MFA para el acceso estándar, el acceso privilegiado debería requerir llaves de seguridad de hardware (FIDO2/WebAuthn) en lugar de SMS o TOTP. Considera requerir reautenticación para operaciones sensibles incluso dentro de una sesión autenticada.

Implementar acceso justo a tiempo (JIT). En lugar de acceso privilegiado persistente, otorga permisos elevados temporales cuando se necesiten para una tarea específica, con revocación automática después de un período definido.

Implementación SaaS: Utiliza herramientas como AWS IAM Identity Center (anteriormente SSO) con límites de duración de sesión, HashiCorp Vault para secretos dinámicos o soluciones PAM dedicadas. Cuando un ingeniero necesita acceso a la base de datos de producción para una sesión de depuración, solicita acceso JIT a través de un flujo de trabajo que otorga credenciales temporales por 2-4 horas y registra toda la actividad durante esa ventana.

Registrar todas las acciones privilegiadas. Cada acción realizada con credenciales privilegiadas debe ser registrada, y esos registros deben estar protegidos contra modificación por parte de los propios usuarios privilegiados. Envía los registros a un SIEM centralizado o sistema de gestión de logs donde puedan ser revisados.

Revisar el acceso privilegiado trimestralmente. El acceso privilegiado debe revisarse con mayor frecuencia que el acceso estándar. Las revisiones trimestrales son la expectativa mínima. Durante cada revisión, verifica que cada cuenta privilegiada sigue siendo necesaria, que el nivel de acceso sigue siendo apropiado y que el propietario de la cuenta sigue empleado y en un rol que requiere acceso privilegiado.

El Problema de la Cuenta Root de AWS

Cada cuenta de AWS tiene un usuario root con acceso sin restricciones. Esta es una preocupación común en auditorías.

Mejores prácticas:

• Habilitar MFA en la cuenta root usando una llave de seguridad de hardware
• No utilizar la cuenta root para operaciones del día a día
• Almacenar las credenciales de la cuenta root en una ubicación física segura (caja fuerte o bóveda segura)
• Registrar y alertar sobre cualquier uso de la cuenta root a través de CloudTrail
• Documentar las circunstancias bajo las cuales se permite el acceso a la cuenta root (típicamente limitado a acciones a nivel de cuenta que solo root puede realizar)

Autenticación Multifactor e Inicio de Sesión Único

Requisitos de MFA

El control A.8.5 requiere autenticación segura apropiada para la sensibilidad del sistema al que se accede. Para las empresas SaaS, esto se traduce en requisitos de MFA en todo el entorno.

Dónde debe aplicarse MFA:

• Todo acceso al proveedor de identidad (no negociable)
• Todo acceso a la consola de plataformas en la nube (AWS, Azure, GCP)
• Todo acceso a entornos de producción
• Todas las conexiones VPN
• Todo acceso a repositorios de código
• Todo acceso a cuentas privilegiadas
• Todo acceso administrativo a herramientas SaaS

Jerarquía de fortaleza de MFA:

1. Llaves de seguridad de hardware (FIDO2/WebAuthn): Más resistentes al phishing. Requeridas para acceso privilegiado.
2. Aplicaciones de autenticación (TOTP): Aceptables para acceso estándar. Ejemplos: Google Authenticator, Authy, 1Password.
3. Notificaciones push: Aceptables pero vulnerables a ataques de fatiga MFA. Usa coincidencia de números si está disponible.
4. Códigos SMS: Forma más débil. Vulnerable al intercambio de SIM. Evitar para acceso a sistemas de producción.

Recomendación de política: Requerir MFA con aplicación de autenticación como mínimo para todo acceso. Requerir llaves de seguridad de hardware para acceso privilegiado y acceso a sistemas que contengan datos de clientes.

Inicio de Sesión Único (SSO)

SSO centraliza la autenticación a través de tu proveedor de identidad y es la forma más efectiva de aplicar políticas consistentes de control de acceso en tu ecosistema de herramientas SaaS.

Beneficios para el cumplimiento de ISO 27001:

• Registros de autenticación centralizados para todas las aplicaciones conectadas
• Aplicación consistente de MFA en todos los sistemas
• Desaprovisionamiento simplificado — desactiva la cuenta del IdP y se revoca todo el acceso conectado
• Reducción de la fatiga de contraseñas y los riesgos de seguridad que conlleva

Prioridades de implementación de SSO para empresas SaaS:

1. Primero: Acceso a plataformas en la nube (AWS IAM Identity Center, Azure AD, GCP Cloud Identity)
2. Segundo: Repositorios de código (GitHub, GitLab, Bitbucket)
3. Tercero: Herramientas de CI/CD (Jenkins, CircleCI, GitHub Actions)
4. Cuarto: Herramientas de comunicación (Slack, Microsoft Teams)
5. Quinto: Todas las herramientas SaaS restantes que soporten SSO

La realidad del “impuesto SSO”: Muchos proveedores SaaS cobran precios premium por la integración SSO. Presupuesta esto durante la planificación de implementación de ISO 27001. El costo del SSO se justifica por los beneficios de cumplimiento y la eficiencia operativa de la gestión centralizada de acceso.

Aplicaciones que no soportan SSO: Mantén un inventario documentado de aplicaciones que no pueden conectarse a SSO. Estas requieren gestión de cuentas individual, aplicación separada de MFA y deben ser priorizadas en las listas de verificación de desaprovisionamiento ya que no serán revocadas automáticamente cuando se desactive la cuenta del IdP.

Revisiones de Acceso

El control A.5.18 requiere que los derechos de acceso se revisen a intervalos definidos. Las revisiones de acceso son un punto de verificación esencial en auditorías — los auditores solicitarán evidencia de que las revisiones se completaron según lo programado y que los hallazgos fueron remediados.

Frecuencia de Revisión

Trimestral: Acceso privilegiado, acceso a entornos de producción y acceso a sistemas que contengan datos sensibles de clientes. Esta es la cadencia mínima que esperan los auditores para acceso de alto riesgo.

Semestral: Acceso estándar a aplicaciones, acceso a repositorios de código y acceso a herramientas corporativas.

Anual: Acceso de bajo riesgo, sistemas informativos y plataformas de documentación interna.

Tu política de control de acceso debe especificar la frecuencia de revisión para cada categoría. No establezcas una frecuencia que no puedas mantener — un ciclo de revisión incumplido es un hallazgo de auditoría.

Cómo Realizar Revisiones de Acceso

Paso 1: Generar informes de acceso. Exporta las listas de usuarios actuales y sus permisos de cada sistema bajo revisión. La mayoría de los proveedores de identidad pueden generar informes consolidados de las aplicaciones conectadas.

Paso 2: Distribuir a los revisores. Cada sistema o aplicación debe tener un propietario designado que revise el acceso para ese sistema. En la práctica, esto generalmente significa:

• Los líderes de ingeniería revisan el acceso a la infraestructura de producción
• Los líderes de equipo revisan el acceso de su equipo a las aplicaciones
• El equipo de seguridad revisa el acceso privilegiado en todos los sistemas

Paso 3: Revisar cada entrada. Para cada combinación usuario-acceso, el revisor determina:

• ¿Esta persona sigue empleada? (Verificar contra los registros de RRHH)
• ¿Su rol actual requiere este acceso?
• ¿El nivel de acceso es apropiado (no excesivo)?
• ¿La cuenta está activa (se ha usado recientemente)?

Paso 4: Remediar hallazgos. Elimina el acceso que ya no es necesario. Reduce los permisos excesivos. Desactiva las cuentas inactivas. Documenta cada acción de remediación.

Paso 5: Documentar la revisión. Conserva el informe de acceso, los comentarios del revisor, las acciones de remediación y la fecha de finalización. Esta es la evidencia que los auditores solicitarán.

Implementación SaaS: Construye un flujo de trabajo automatizado de revisión de acceso. Exporta listas de usuarios de tu proveedor de identidad y sistemas conectados vía API. Preséntalos en un formato estructurado (hoja de cálculo, plataforma GRC o herramienta personalizada) donde los revisores puedan aprobar, marcar o revocar cada entrada de acceso. Rastrea el porcentaje de finalización y envía recordatorios a los revisores que no hayan completado sus revisiones antes de la fecha límite.

Hallazgos Comunes en Revisiones de Acceso

• Cuentas huérfanas: Cuentas pertenecientes a exempleados o contratistas que no fueron desaprovisionados correctamente
• Permisos excesivos: Usuarios con acceso más allá de lo que su rol requiere, frecuentemente por cambios de rol sin limpieza de acceso
• Cuentas inactivas: Cuentas activas que no se han utilizado en más de 60-90 días, sugiriendo que el acceso es innecesario
• Cuentas compartidas: Múltiples individuos usando las mismas credenciales, violando los requisitos de responsabilidad y pista de auditoría
• Falta de MFA: Cuentas que deberían tener MFA aplicado pero no lo tienen

Consideraciones de Control de Acceso Específicas para SaaS

Las empresas SaaS enfrentan desafíos de control de acceso que no existen en los entornos de TI tradicionales. Tus políticas y procedimientos deben abordarlos explícitamente.

Multi-Tenencia

Si tu producto es multi-tenant, el control de acceso debe garantizar un aislamiento estricto entre inquilinos. Esto es tanto un requisito de seguridad como un tema de confianza del cliente.

Controles a implementar:

• Aislamiento de inquilinos en las capas de aplicación, base de datos y red
• Acceso a datos del cliente restringido por contexto de inquilino (un ingeniero depurando el problema de un cliente no debería poder acceder a los datos de otro cliente)
• Registro de auditoría de todo acceso entre inquilinos
• Pruebas regulares de los límites de aislamiento de inquilinos (incluir en el alcance de pruebas de penetración)

Claves API y Autenticación Servicio a Servicio

Los productos SaaS típicamente exponen APIs contra las cuales los clientes y socios se autentican. Gestionar estas credenciales es una responsabilidad del control de acceso.

Gestión de claves API:

• Generar claves API únicas por cliente o integración, no claves compartidas
• Soportar rotación de claves sin interrupción del servicio
• Implementar políticas de expiración de claves
• Registrar todo uso de claves API y monitorear patrones anómalos
• Proporcionar a los clientes la capacidad de revocar y regenerar sus propias claves
• Nunca incrustar claves API en código fuente o aplicaciones del lado del cliente

Autenticación servicio a servicio:

• Usar tokens de corta duración (OAuth 2.0, JWT) en lugar de credenciales de larga duración donde sea posible
• Implementar TLS mutuo (mTLS) para comunicación interna entre servicios en contextos de alta seguridad
• Rotar credenciales de servicio en un calendario definido
• Almacenar credenciales de servicio en un gestor de secretos (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault), no en variables de entorno o archivos de configuración

Acceso a Pipelines de CI/CD

Tu pipeline de despliegue tiene acceso a producción por diseño — despliega código, ejecuta migraciones y gestiona infraestructura. Esto lo convierte en un objetivo de alto valor y un dominio crítico de control de acceso.

Controles de acceso de CI/CD:

• Restringir quién puede modificar las configuraciones del pipeline (tratar pipeline-como-código con los mismos controles que el código de aplicación)
• Usar credenciales de corta duración y alcance limitado para el despliegue (federación OIDC con AWS, tokens temporales en lugar de secretos de larga duración)
• Requerir puertas de aprobación para despliegues a producción (como mínimo, revisión de código; idealmente, una aprobación explícita de despliegue)
• Registrar todas las ejecuciones del pipeline con pistas de auditoría completas
• Implementar reglas de protección de ramas para que solo la rama principal pueda activar despliegues a producción
• Separar las credenciales del pipeline por entorno (el pipeline de staging no debería tener credenciales de producción)

Acceso a Datos del Cliente para Soporte

Los ingenieros de soporte y los equipos de éxito del cliente pueden necesitar acceder a datos del cliente para resolver problemas. Este acceso debe ser controlado, justificado y registrado.

Modelo de acceso de emergencia (break-glass):

• Definir criterios claros para cuándo se permite el acceso a datos del cliente (por ejemplo, ticket de soporte activo del cliente)
• Requerir aprobación explícita para cada evento de acceso (de un líder de equipo o a través de un flujo de trabajo automatizado)
• Otorgar acceso con tiempo limitado (revocado automáticamente después de la sesión de soporte)
• Registrar todo acceso a datos durante la sesión
• Anonimizar o pseudonimizar datos en entornos de no producción para que el soporte pueda solucionar problemas sin ver datos reales del cliente

Implementación de IAM en la Nube

Para las empresas SaaS que ejecutan en las principales plataformas en la nube, IAM en la nube es el mecanismo principal para implementar el control de acceso a nivel de infraestructura.

AWS IAM

Estructura de cuentas: Utiliza AWS Organizations con cuentas separadas para producción, staging, desarrollo y seguridad/auditoría. Esto proporciona límites duros a nivel de cuenta que previenen el acceso accidental entre entornos.

Mejores prácticas de IAM para ISO 27001:

• Nunca uses la cuenta root para operaciones. Habilita MFA y restringe su uso.
• Usa IAM Identity Center (anteriormente SSO) para federar acceso desde tu proveedor de identidad
• Define políticas de IAM siguiendo el privilegio mínimo — comienza sin permisos y añade solo lo necesario
• Usa roles de IAM para aplicaciones y servicios, no usuarios de IAM con claves de acceso de larga duración
• Habilita CloudTrail en todas las regiones para un registro de auditoría completo
• Usa Políticas de Control de Servicio (SCPs) para aplicar barreras a nivel de toda la organización
• Implementa límites de permisos para restringir los permisos máximos que una entidad IAM puede tener

Hallazgos comunes de auditoría en AWS:

• Usuarios de IAM con políticas en línea en lugar de políticas gestionadas adjuntas
• Claves de acceso que no se han rotado en más de 90 días
• Usuarios de IAM con acceso a consola pero sin MFA
• Políticas excesivamente permisivas usando comodines (por ejemplo, "Action": "*", "Resource": "*")
• CloudTrail no habilitado en todas las regiones

Azure IAM

Estructura de tenant y suscripción: Usa grupos de gestión y suscripciones de Azure para separar entornos. Azure AD (ahora Entra ID) sirve como proveedor de identidad.

Controles clave:

• Usa Azure AD Privileged Identity Management (PIM) para acceso privilegiado JIT
• Implementa políticas de Acceso Condicional para autenticación basada en riesgo
• Habilita Azure AD Identity Protection para detección automatizada de riesgos
• Usa identidades gestionadas para recursos de Azure (elimina la gestión de credenciales para acceso servicio a servicio)
• Configura ajustes de diagnóstico para transmitir registros de Azure AD a tu SIEM

GCP IAM

Jerarquía de recursos: Usa organizaciones, carpetas y proyectos de GCP para separar entornos. Cloud Identity o Google Workspace sirve como proveedor de identidad.

Controles clave:

• Usa Workload Identity Federation para evitar claves de cuentas de servicio para cargas de trabajo externas
• Implementa Políticas de Organización para aplicar restricciones en todos los proyectos
• Usa Condiciones de IAM para decisiones de acceso conscientes del contexto
• Habilita registros de auditoría de Actividad de Administrador (siempre activos) y registros de auditoría de Acceso a Datos para recursos sensibles
• Revisa las sugerencias del recomendador de IAM para reducir permisos excesivos

Registro y Monitoreo de Eventos de Acceso

El control de acceso está incompleto sin visibilidad. Los controles A.8.15 (Registro) y A.8.16 (Actividades de monitoreo) requieren que los eventos de acceso se registren y monitoreen para detectar anomalías.

Qué Registrar

Eventos de autenticación:

• Intentos de inicio de sesión exitosos y fallidos
• Desafíos de MFA y resultados
• Cambios y restablecimientos de contraseñas
• Bloqueos de cuentas
• Emisión y renovación de tokens SSO

Eventos de autorización:

• Otorgamientos y revocaciones de acceso
• Cambios de permisos
• Asignaciones y eliminaciones de roles
• Eventos de escalamiento de privilegios

Eventos administrativos:

• Cambios en políticas de IAM
• Modificaciones de grupos de seguridad
• Cambios en ACL de red
• Creación o modificación de cuentas de servicio

Eventos de acceso a datos:

• Consultas a bases de datos en tablas sensibles
• Acceso a archivos en ubicaciones de almacenamiento sensibles
• Llamadas API que devuelven datos de clientes
• Exportaciones o descargas masivas de datos

Monitoreo y Alertas

El registro es necesario pero no suficiente. Debes monitorear activamente los registros en busca de patrones sospechosos y responder a las alertas.

Eventos que ameritan alerta:

• Múltiples intentos fallidos de inicio de sesión desde la misma cuenta o IP
• Inicio de sesión exitoso desde una ubicación geográfica inusual
• Uso de cuenta privilegiada fuera del horario laboral
• Acceso a datos sensibles por cuentas que típicamente no los acceden
• Creación de nuevas cuentas privilegiadas
• Desactivación de MFA en cualquier cuenta
• Acceso desde direcciones IP que no están en tus rangos corporativos o de VPN

Implementación SaaS: Reenvía todos los registros de acceso a un SIEM centralizado (Datadog, Splunk, Elastic o una solución nativa de la nube como AWS Security Hub, Azure Sentinel o GCP Chronicle). Define reglas de alerta para los eventos anteriores. Establece un proceso para triaje e investigación de alertas, con escalamiento a tu proceso de respuesta a incidentes para actividad sospechosa confirmada.

Protección de Registros

Los registros de acceso deben estar protegidos contra manipulación. Si una cuenta privilegiada comprometida puede modificar sus propios registros de acceso, los registros pierden su valor probatorio.

Medidas de protección:

• Almacenar registros en una cuenta o sistema separado de los sistemas que se están monitoreando
• Aplicar políticas de escritura única, lectura múltiple (WORM) o solo adición al almacenamiento de registros
• Restringir la eliminación y modificación de registros a un número muy pequeño de cuentas (o prevenirlo por completo)
• Monitorear la manipulación o eliminación de registros como una alerta de alta prioridad

Hallazgos Comunes de Auditoría en Control de Acceso

Comprender lo que los auditores típicamente encuentran te ayuda a abordar las brechas de manera proactiva. Estos son los hallazgos de control de acceso más frecuentes durante las auditorías de certificación ISO 27001.

Hallazgo 1: Desaprovisionamiento Incompleto

Lo que los auditores prueban: Solicitan tu lista de empleados terminados durante el período de auditoría y la cruzan con las cuentas de usuario en los sistemas críticos.

Lo que encuentran: Exempleados con cuentas activas en sistemas no conectados al proveedor de identidad — frecuentemente aplicaciones legacy, herramientas de desarrollador o cuentas de plataformas en la nube con credenciales locales.

Cómo prevenirlo: Mantén una lista de verificación de desaprovisionamiento completa que cubra todos los sistemas en el alcance. Automatiza donde sea posible. Para sistemas que no pueden ser automatizados, verifica la finalización del desaprovisionamiento manualmente y documenta la verificación.

Hallazgo 2: Acceso Privilegiado Excesivo

Lo que los auditores prueban: Revisan la lista de usuarios con acceso privilegiado y la comparan con el organigrama y las definiciones de roles.

Lo que encuentran: Ingenieros a quienes se les otorgó acceso de administrador para un proyecto específico hace meses y aún lo tienen. Fundadores que tienen acceso root a todo a pesar de haber pasado a roles no técnicos. Cuentas de servicio con privilegios de administrador porque era “más fácil” de configurar.

Cómo prevenirlo: Implementa revisiones trimestrales de acceso privilegiado con remediación documentada. Usa acceso JIT para operaciones privilegiadas para que el acceso de administrador persistente sea la excepción, no la norma.

Hallazgo 3: Revisiones de Acceso Faltantes o Incompletas

Lo que los auditores prueban: Solicitan evidencia de revisiones de acceso completadas durante el período de auditoría, que coincidan con la frecuencia establecida en tu política de control de acceso.

Lo que encuentran: Revisiones que debían ocurrir trimestralmente pero solo ocurrieron dos veces. Revisiones que se realizaron pero carecían de documentación de hallazgos y remediación. Revisiones que cubrieron algunos sistemas pero no todos los sistemas en el alcance.

Cómo prevenirlo: Automatiza la programación de revisiones de acceso. Establece recordatorios de calendario con suficiente anticipación para completar la revisión antes de la fecha límite. Usa una plantilla de revisión estructurada que capture la fecha, el revisor, los sistemas revisados, los hallazgos y las acciones de remediación. Consulta nuestra lista de verificación de certificación ISO 27001 para un cronograma completo de actividades recurrentes.

Hallazgo 4: Cuentas Compartidas

Lo que los auditores prueban: Buscan cuentas utilizadas por múltiples individuos, lo cual viola los requisitos de responsabilidad y pista de auditoría.

Lo que encuentran: Cuentas “admin” compartidas para herramientas SaaS que no soportan SSO. Credenciales compartidas para sistemas legacy. Cuentas genéricas de “deploy” usadas por múltiples ingenieros.

Cómo prevenirlo: Elimina las cuentas compartidas siempre que sea posible. Donde las cuentas compartidas son técnicamente inevitables (algunos sistemas legacy), implementa controles compensatorios: procedimientos de registro de entrada/salida, grabación de sesiones y registro de uso que identifique quién usó la cuenta compartida en cada momento.

Hallazgo 5: Cobertura Insuficiente de MFA

Lo que los auditores prueban: Verifican que MFA esté aplicado en todos los sistemas donde tu política lo requiere.

Lo que encuentran: Políticas de MFA configuradas en el proveedor de identidad pero con excepciones para ciertos usuarios o aplicaciones. Cuentas de plataformas en la nube con MFA habilitado en la consola pero no para acceso CLI. Aplicaciones que soportan MFA pero donde nunca fue habilitado.

Cómo prevenirlo: Audita la aplicación de MFA en todos los sistemas en el alcance. Cierra las brechas de excepciones. Para sistemas que no soportan MFA, documenta la limitación e implementa controles compensatorios (restricciones de IP, requisitos de VPN, registro mejorado).

Preguntas Frecuentes

¿Cuál es la diferencia entre el control de acceso en ISO 27001 y SOC 2?

Los requisitos subyacentes son casi idénticos — ambos marcos esperan privilegio mínimo, MFA, revisiones de acceso, controles de aprovisionamiento/desaprovisionamiento y gestión de acceso privilegiado. La diferencia está en la estructura del marco. ISO 27001 organiza los requisitos de control de acceso en controles específicos del Annex A. SOC 2 aborda el control de acceso a través de Criterios Comunes (principalmente CC6.1 a CC6.8). Una empresa SaaS que implementa controles de acceso para un marco satisfará la mayoría de los requisitos del otro marco con un esfuerzo adicional mínimo.

¿Con qué frecuencia deben realizarse las revisiones de acceso?

ISO 27001 no prescribe una frecuencia específica — requiere revisiones “a intervalos planificados”. Tú defines la frecuencia en tu política de control de acceso. El estándar de la industria para auditorías de certificación es revisiones trimestrales para acceso privilegiado y sensible, y revisiones semestrales o anuales para acceso estándar. Cualquier frecuencia que definas, debes demostrar ejecución consistente.

¿Necesitamos una herramienta separada de gestión de acceso privilegiado (PAM)?

No necesariamente. El requisito es controlar el acceso privilegiado — cómo implementes ese control depende de ti. Las empresas SaaS pequeñas pueden gestionar el acceso privilegiado a través de políticas de IAM, scripts de acceso JIT y procesos manuales documentados. A medida que escales, una herramienta PAM dedicada (CyberArk, BeyondTrust, HashiCorp Vault) se vuelve cada vez más valiosa para centralizar la gestión de credenciales privilegiadas, implementar grabación de sesiones y automatizar la rotación de credenciales.

¿Cómo debemos manejar el control de acceso para datos de clientes en un producto SaaS multi-tenant?

El aislamiento de inquilinos debe aplicarse a nivel técnico — lógica de aplicación, consultas de base de datos (seguridad a nivel de fila o esquema/base de datos por inquilino) y segmentación de red. El acceso interno a datos de clientes debe requerir justificación explícita (ticket de soporte activo), otorgamientos de acceso con tiempo limitado y registro completo. Considera implementar una política de acceso a datos de clientes separada de tu política general de control de acceso debido a su sensibilidad y los controles adicionales requeridos.

¿Cuál es la relación entre nuestra política de control de acceso y nuestra evaluación de riesgos?

Tu evaluación de riesgos identifica riesgos relacionados con el acceso no autorizado, privilegios excesivos y fallos en el control de acceso. La política de control de acceso define los controles que tratan esos riesgos. Los dos deben estar explícitamente vinculados — cada requisito de control de acceso en tu política debe rastrearse hasta un riesgo que aborda, y cada riesgo relacionado con el acceso en tu registro de riesgos debe rastrearse hasta el control que lo mitiga. Esta trazabilidad es algo que los auditores buscan y se documenta en tu Declaración de Aplicabilidad.

Cómo Ayuda GRCTrail

GRCTrail simplifica la implementación del control de acceso de ISO 27001 y el cumplimiento continuo para empresas SaaS:

• Revisiones de acceso automatizadas que extraen listas de usuarios de tu proveedor de identidad y sistemas conectados, las enrutan a los revisores apropiados, rastrean la finalización y retienen evidencia — eliminando el proceso de revisión basado en hojas de cálculo que causa plazos incumplidos
• Plantillas de políticas de control de acceso adaptadas para empresas SaaS, cubriendo cada control relevante del Annex A con lenguaje práctico para entornos en la nube, pipelines de CI/CD y arquitecturas multi-tenant
• Paneles de monitoreo continuo que rastrean la aplicación de MFA, cuentas inactivas y acceso privilegiado en todo tu entorno, alertándote sobre desviaciones antes de que tu auditor las encuentre

Comienza con GRCTrail

Guías Relacionadas

• ¿Qué es ISO 27001? Una Guía Práctica para Empresas SaaS
• Controles del Annex A de ISO 27001: La Guía Completa
• Políticas de ISO 27001: Qué Políticas Necesitas y Cómo Escribirlas
• Lista de Verificación de Certificación ISO 27001
• Guía de Evaluación de Riesgos ISO 27001