12 min de lectura

Objetivos de aprendizaje

Al final de este módulo, podrás:

  • Distinguir los tres tipos de cuentas y separar los derechos de capacidad (lo que un grupo puede hacer) de las concesiones de recursos (qué recursos puede tocar).
  • Aplicar el privilegio mínimo en una plataforma cuyo modelo de acceso es de lectura implícita y no tiene regla de denegación, donde el privilegio mínimo significa simplemente no conceder.
  • Explicar por qué la federación es solo autenticación, sin aprovisionamiento justo a tiempo y sin asignación de grupo a proveedor de identidad, y diseñar el manual de unión/salida/movimiento que esto fuerza.
  • Crear un grupo, definir el alcance de una concesión de recursos, y agregar un miembro en el Data Center Designer, y emitir y definir el alcance de un token API que mantiene las credenciales personales fuera de la automatización.

Unidad 2.2: Identidad, RBAC, y Federación

Introducción

El control de acceso en IONOS no se parece al lenguaje de política IAM de los hiperscalers de EE. UU. No hay documento de política JSON, no hay denegación explícita y no hay condiciones per-action detalladas. El acceso es basado en grupos, con derechos de capacidad asignados a un grupo y recursos concedidos al mismo grupo, y el acceso de lectura es implícito en el momento en que se concede un recurso. Este modelo es más simple, pero obliga a una disciplina particular: el privilegio mínimo se logra no concediendo, no escribiendo una regla restrictiva. Esta unidad establece esa disciplina, describe dónde genuinamente termina la federación y termina creando un grupo con alcance y un token API con alcance en el Data Center Designer para FinCorp.

1. Tipos de cuenta, derechos de capacidad y concesiones de recursos

Existen tres tipos de cuentas dentro de un contrato. El propietario del contrato se crea automáticamente para quien se registró primero, tiene acceso total a todos los recursos, puede crear y eliminar usuarios y asignar el rol de Administrador, y es la única cuenta que puede cambiar el método de pago del contrato; solo hay uno y no se puede revocar. Un Administrador (ilimitado por contrato) tiene el mismo alcance que el propietario, excepto para el método de pago, puede asignar el rol de Administrador a otros, y accede a todos los recursos contratados sin pertenecer a ningún grupo. Un Usuario es el tipo de cuenta básico: no tiene acceso en absoluto, excepto a través de la pertenencia a un grupo y los privilegios asignados a esos grupos, y se puede actualizar a Administrador.

Para los Usuarios, el acceso se construye a partir de dos capas independientes, y mantenerlas distintas es el núcleo del modelo:

  • Los derechos de capacidad son habilidades a nivel de contrato asignadas a un grupo, que gobiernan qué tipo de acción pueden realizar sus miembros. Los derechos de grupo asignables incluyen Crear Centro de Datos, Crear Instantáneas, Reservar bloques IP, Crear Acceso a Internet, Utilizar Object Storage, Crear Unidades de Copia de Seguridad, Crear clusters Kubernetes y Acceder al Registro de Actividades.
  • Las concesiones de recursos determinan qué recursos específicos puede acceder un grupo, extraídos de los tipos de recursos controlables: Centros de Datos Virtuales, Instantáneas, Imágenes, bloques IP, Unidades de Copia de Seguridad y clusters Kubernetes. Cada concesión lleva un nivel de autorización: Lectura (implícito en el momento en que se asigna un recurso a un grupo), Edición y Compartir.

Un grupo con el derecho de Crear Centro de Datos pero sin Centro de Datos Virtual concedido no puede ver ni acceder a centros de datos existentes; un grupo al que se le ha concedido un Centro de Datos Virtual específico a nivel de Edición pero que carece del derecho de Crear Centro de Datos puede modificar ese Centro de Datos Virtual pero no puede crear nuevos. La capacidad y la concesión son ortogonales, y un usuario obtiene la intersección de ambas en todos los grupos a los que pertenece. Los Administradores se sitúan fuera de esto por completo: porque acceden a todos los recursos directamente, no necesitan pertenecer a un grupo, lo que hace que el rol de Administrador sea una asignación deliberadamente escasa en lugar de una comodidad.

2. Lectura implícita, no denegación y mínimo privilegio al no conceder

La plataforma no tiene regla de denegación. No puede escribir una política que reste acceso; solo puede agregar derechos de capacidad y concesiones de recursos. Combinado con la lectura implícita (asignar un recurso a un grupo concede lectura automáticamente), esto significa que el mínimo privilegio es una función de restricción en el momento de la concesión, no de una regla correctiva posterior. La postura de mínimo privilegio es, por lo tanto: crear grupos con un alcance estrecho, conceder a cada uno solo los recursos que realmente necesita al nivel más bajo que funcione (preferir Leer sobre Editar, y reservar Compartir deliberadamente), y nunca apoyarse en el rol de Administrador como atajo.

Dado que no hay denegación, una concesión demasiado amplia no puede ser parcheada con una excepción; debe ser eliminada y redefinida. La disciplina operativa que sigue es modelar grupos en torno a roles (un grupo de operaciones de base de datos, un grupo de red, un grupo de auditoría de solo lectura) y mantener el conjunto de recursos concedidos a cada uno tan ajustado como lo permita el rol. Para FinCorp bajo escrutinio de BSI, un grupo de auditoría se le concede el derecho de registro de actividad de acceso y concesiones de nivel de lectura en los VDC relevantes y nada más, para que el auditor pueda revisar sin tener la capacidad de cambiar la infraestructura.

3. La Federación Es Solo Autenticación

FinCorp ya ejecuta un proveedor de identidad corporativa, por lo que el instinto es federar y dejar que el IdP controle todo. La plataforma admite la federación con SAML 2.0 y proveedores de identidad OpenID Connect (OIDC), pero su alcance hoy en día es solo autenticación. Esta frase conlleva tres consecuencias difíciles que deben diseñarse alrededor de ellas:

  • No hay aprovisionamiento justo a tiempo. Un inicio de sesión federado no crea una cuenta de IONOS de inmediato. El usuario debe existir ya como usuario de IONOS Cloud antes de que pueda autenticarse a través del IdP; la vinculación de la cuenta requiere un usuario existente.
  • No hay asignación de grupo desde el proveedor de identidad. El IdP no controla la membresía en los grupos de IONOS. La federación autentica a la persona; no asigna sus derechos de capacidad ni concesiones de recursos. El mapeo de acceso desde las reclamaciones del IdP a los grupos de IONOS está en la hoja de ruta, pero no está disponible hoy en día.
  • Autenticación, no autorización. La federación responde a "¿es esta la persona correcta?"; el modelo de grupo y concesión aún responde a "¿qué pueden hacer?", y ese modelo se administra dentro de IONOS, independientemente del IdP.

El patrón que esto fuerza es un libro de ejecución de unión/movimiento/salida explícito y manual. Cuando alguien se une, un administrador crea el usuario de IONOS y asigna los grupos correctos antes de que el inicio de sesión federado sea útil. Cuando alguien cambia de rol (cambio), un administrador ajusta su membresía en el grupo manualmente. Cuando alguien se va (salida), deshabilitarlos en el IdP detiene los nuevos inicios de sesión, pero el usuario de IONOS y sus concesiones deben eliminarse por separado, porque el IdP nunca poseyó el acceso del lado de IONOS. Tratar la federación como si aprovisionara y desaprovisionara cuentas es la lectura errónea peligrosa; no hace ninguna de las dos cosas. El patrón nativo es mantener un libro de ejecución documentado y auditar la lista de usuarios de IONOS contra el sistema de RRHH en un calendario, ya que nada los reconcilia automáticamente.

DCD Implementación paso a paso

Usted creará un grupo FinCorp con alcance, concederá un solo recurso, agregará un miembro y luego emitirá un token API con un alcance limitado. Solo los propietarios y administradores del contrato pueden gestionar usuarios. El objetivo arquitectónico es un grupo con privilegios mínimos cuyo acceso sea exactamente los recursos concedidos, más una credencial de automatización que no sea el inicio de sesión personal de nadie.

Objetivo de construcción: Crear un grupo, conceder un recurso con alcance, agregar un miembro; emitir y conceder un token API.

Pasos (en el Data Center Designer):

  1. Abra el Administrador de usuarios (Usuarios y grupos). En la pestaña Grupos, seleccione Crear, ingrese un nombre de grupo (por ejemplo fincorp-db-ops) y seleccione Crear para confirmar. El grupo ahora aparece en la lista de grupos sin derechos y sin recursos aún.
  2. Con el grupo seleccionado, asigne los derechos de capacidad habilitando solo los privilegios que el rol necesita (por ejemplo, Crear clusters Kubernetes, o Acceder a registros de actividad para un grupo de auditoría). Deje todos los demás derechos desactivados; desactivado es el denegar.
  3. Abra la pestaña Recursos del grupo, haga clic en Conceder acceso y seleccione el recurso específico (por ejemplo, el VDC fincorp-prod-de) desde el menú desplegable. Conceder un recurso habilita Lectura implícitamente; aumente a Editar solo si el rol requiere cambios.
  4. Abra la pestaña Miembros y agregue el usuario desde el menú desplegable Agregar usuario. El usuario ahora hereda exactamente los derechos y concesiones de este grupo, y nada más. (No agregue administradores a grupos; ya tienen acceso a todo.)
  5. Para la automatización, vaya a Menú > Administración > Token Manager y genere un token de autenticación. Seleccione un TTL desde los valores permitidos (1 hora, 4 horas, 1 día, 7 días, 30 días, 60 días, 90 días, 180 días, 365 días), eligiendo el más corto que se adapte al trabajo. Los permisos del token son los permisos del usuario bajo el que se genera, así que genere bajo un usuario de servicio creado a propósito que pertenezca solo al grupo con alcance limitado, nunca bajo una cuenta de administrador personal.
  6. Copie el valor del token inmediatamente. Se muestra exactamente una vez en la generación y no se puede recuperar después; almacénelo en su administrador de secretos antes de salir de la pantalla.

Errores comunes:

  • Conceder un recurso con edición cuando es suficiente la lectura. No hay regla de denegación para revertirlo; una concesión demasiado amplia debe ser eliminada y redefinida.
  • Emitir tokens API bajo una cuenta personal o de administrador. El token hereda el alcance completo de la cuenta; emítalo bajo un usuario de servicio dedicado y con alcance limitado en su lugar.
  • Suponer que un token se puede pausar. Desactivar un token significa eliminarlo; la eliminación es inmediata y permanente, y el valor no se puede recuperar, así que planifique la rotación como eliminar y volver a emitir.
  • Esperar que la federación cree o elimine cuentas. Solo autentica; el ciclo de vida de unir/mover/dejar es un libro de ejecución manual en el lado de IONOS.
  • Tratar la visualización de token de una sola vez como recuperable. Capture en la generación; no hay segunda oportunidad para leerlo.

Una breve ilustración del límite de credenciales: la programación contra el API utiliza el token como credencial de portador, nunca un nombre de usuario y contraseña, que es exactamente por qué el token debe llevar solo el alcance mínimo del usuario de servicio.

curl --location \
  --request GET 'https://api.ionos.com/cloudapi/v6/datacenters' \
  --header 'Authorization: Bearer <SERVICE_USER_TOKEN>'

El punto arquitectónico está en el encabezado: el token es la identidad. Todo lo que el usuario del servicio puede hacer, el script también puede hacer, por lo que limitar al usuario, no al script, es el control.

Resumen

El control de acceso de IONOS es basado en grupos con derechos de capacidad y concesiones de recursos mantenidos por separado, lectura implícita y sin regla de denegación, por lo que se logra el privilegio mínimo al otorgar de manera estrecha en lugar de escribir una política restrictiva. La federación con SAML o OIDC es solo autenticación, sin aprovisionamiento justo a tiempo y sin asignación de IdP a grupo, lo que fuerza a un libro de ejecución manual de unir/mover/dejar. Los tokens de API heredan los permisos del usuario emisor y se muestran una vez, por lo que pertenecen a usuarios de servicio con ámbito y se rotan mediante eliminación y reemisión.

Puntos clave:

  • Tres tipos de cuentas: un propietario de contrato no revocable, administradores ilimitados (alcance completo menos método de pago, sin grupo necesario) y usuarios que obtienen acceso solo a través de grupos.
  • Los derechos de capacidad (qué puede hacer un grupo) y las concesiones de recursos (qué recursos, en niveles de Lectura/Edición/Compartir) son ortogonales; un usuario obtiene la intersección a través de sus grupos.
  • No hay regla de denegación y la lectura es implícita, por lo que el privilegio mínimo significa no otorgar; una concesión demasiado amplia se elimina y se vuelve a definir, no se parchea.
  • La federación es solo autenticación: el usuario debe existir previamente (no JIT), el IdP no asigna grupos y unir/mover/dejar es un libro de ejecución manual.
  • Los tokens de API heredan los permisos del usuario emisor, permiten hasta 100 por usuario, se muestran una vez y no son recuperables, y se eliminan (no se deshabilitan) para revocar; emítalos bajo usuarios de servicio con ámbito.

Terminología importante:

  • Derecho de capacidad: Un privilegio de grupo a nivel de contrato que rige qué tipo de acción pueden realizar los miembros (por ejemplo, crear clusters de Kubernetes).
  • Concesión de recursos: Una asignación de un recurso específico a un grupo en nivel de Lectura, Edición o Compartir; la concesión habilita la lectura implícitamente.
  • Federación: Confianza de autenticación SAML 2.0 / OIDC; verifica la identidad solo y no aprovisiona cuentas ni asigna grupos.
  • Token de API: Un credencial portador que hereda los permisos del usuario emisor, se muestra una vez en la generación y se revoca mediante eliminación.