¿Qué política de control de acceso necesitas?

Por qué los desarrolladores necesitan políticas de control de acceso reales (no solo teoría)

Si estás enviando código, manteniendo pipelinePara gestionar registros de artefactos, se necesita más que teoría. Las políticas de control de acceso débiles o indefinidas invitan a la manipulación del repositorio. CI/CD abuso, y fugas de credencialesDevSecOps exige una aplicación real, no solo configuraciones de permisos ocultas.

Para administrar eficazmente las políticas de control de acceso en los repositorios de código, pipelines de CI / CDy registros de artefactos, muchos equipos confían en herramientas de cumplimiento automatizado como Xygeni. Mediante la monitorización continua de roles, permisos y cumplimiento de políticas, Xygeni ayuda a prevenir la desviación de permisos, el acceso no autorizado y las anulaciones manuales, convirtiendo la teoría del control de acceso obligatorio en práctica.

El control de acceso bloquea directamente su código fuente, asegura sus compilaciones y protege su producción. pipelineSi los desarrolladores ignoran los controles o las cuentas de servicio tienen permisos amplios, se abre la puerta a brechas de seguridad. Por eso es fundamental comprender el control de acceso obligatorio, el control de acceso MAC y otros modelos.

Tipos de políticas de control de acceso que los desarrolladores deben conocer

Las políticas de control de acceso se dividen en tres categorías principales, cada una de las cuales se adapta de manera diferente. CI/CD Flujos de trabajo. A continuación, un breve análisis comparativo para mayor claridad:

Modelo	¿Quién controla el acceso?	Uso típico en CI/CD	Nivel de riesgo
DAC (Control de acceso discrecional)	Propietario del recurso (desarrollador, administrador)	Uso compartido manual del acceso al repositorio o registro	Alto (error humano)
RBAC (Control de acceso basado en roles)	El sistema asigna permisos por rol	Protección de ramas de GitHub, acceso a trabajos de CI basado en roles de usuario	Medio (roles mal configurados)
MAC (Control de acceso obligatorio)	Aplicado por la política del sistema	Establece quién puede publicar artefactos o implementar código	Bajo (la política anula la intención del usuario)

Aclarando MAC vs. RBAC en CI/CD Contexto

Es fácil confundir el control de acceso basado en roles (RBAC) con control de acceso obligatorio (control de acceso mac), especialmente en CI/CD Ambientes. Mientras CI/CD Plataformas como GitHub y GitLab usan RBAC para administrar roles y permisos (por ejemplo, quién puede fusionar o implementar), esto sigue estando fundamentalmente basado en roles, no en un verdadero control de acceso MAC.

RBAC permite asignar permisos según roles (desarrollador, mantenedor, etc.), pero estos permisos siguen estando controlados por el usuario y son modificables. Las configuraciones incorrectas o la manipulación de permisos son riesgos comunes.

El control de acceso obligatorio (control de acceso MAC), en cambio, se aplica a nivel de sistema o infraestructura. Los usuarios, incluidos los administradores, no pueden anularlo. Considere el control de acceso MAC como políticas integradas en la plataforma: políticas de IAM en proveedores de nube (p. ej., AWS IAM, GCP IAM) o herramientas de aplicación a nivel de sistema operativo como SELinux o AppArmor. En estos casos, el acceso solo se concede cuando se cumplen reglas predefinidas que no se pueden eludir.

In CI/CDMuchas herramientas simulan el comportamiento del control de acceso MAC mediante roles de IAM con un alcance limitado o permisos específicos de recursos, pero esto no constituye un control de acceso obligatorio completo. La verdadera implementación del control de acceso obligatorio requiere controles por debajo de la capa de aplicación, a nivel del sistema operativo, la red o la infraestructura en la nube, donde el acceso se rige por políticas de control de acceso inmutables, no por la configuración humana.

Control de acceso basado en roles (RBAC)

RBAC asigna permisos a roles definidos como "desarrollador", "mantenedor" o "administrador de versiones". Simplifica la administración en herramientas como GitHub y GitLabEn lugar de configurar usuario por usuario, asígneles un rol y deje que el sistema aplique las reglas.

Ejemplo: Archivo CODEOWNERS de GitHub

# CODEOWNERS
/docs/ @doc-team
/scripts/ @devops-team
/main.py @maintainers

Esto garantiza que solo los roles asignados puedan aprobar cambios en directorios críticos.

Configuración de roles de GitLab: configure el acceso al proyecto en Configuración > Miembros:

Desarrollador: Puede empujar hacia ramas destacadas.
Mantenedor: Puede fusionarse en ramas protegidas.
Invitada: Acceso de sólo lectura.

Ejemplo de RBAC del flujo de trabajo de acciones de GitHub:

yaml
# .github/workflows/deploy.yml
name: Deploy to Production
on:
  push:
    branches:
      - main
jobs:
  deploy:
    if: github.actor == 'release-manager'
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Deploy
        run: ./scripts/deploy.sh

Control de Acceso Obligatorio (MAC)

El control de acceso obligatorio (control de acceso MAC) aplica reglas estrictas a nivel de sistema que los usuarios y administradores no pueden anular. Utilice el control de acceso MAC. para controlar estrictamente quién puede leer, escribir o ejecutar recursos críticos.

Ejemplo: Política de registro de artefactos de Google (YAML simplificado)

yaml
bindings:
  - role: roles/artifactregistry.writer
    members:
      - serviceAccount:ci-deployer@project.iam.gserviceaccount.com

Esta política otorga permiso de escritura solo a la cuenta de servicio ci-deployer, lo que garantiza que solo los trabajos de CI con esta identidad puedan enviar artefactos.

Ejemplo: Política de Amazon ECR (YAML simplificado)

yaml
Version: "2008-10-17"
Statement:
  - Effect: Deny
    Principal: "*"
    Action: ecr:PutImage
    Resource: arn:aws:ecr:region:account-id:repository/my-app
    Condition:
      StringNotEquals:
        aws:userid: ci-service-account

Esta política deniega cualquier acción "PutImage" en el repositorio ECR, a menos que la realice la cuenta de servicio ci. Restringe la carga de imágenes estrictamente a esta cuenta de servicio.

Riesgos de la anulación manual y cómo MAC los previene

Uno de los mayores riesgos con RBAC y Modelos DAC Existe la posibilidad de anulaciones manuales, intencionales o accidentales. Por ejemplo, un administrador o desarrollador podría cargar artefactos directamente a un registro protegido u otorgar permisos excesivos fuera de las políticas de control de acceso definidas. Estas acciones pueden generar vulnerabilidades o causar brechas de cumplimiento.

El control de acceso obligatorio (control de acceso MAC) evita dichas anulaciones al aplicar políticas a nivel de sistema que ningún usuario, ni siquiera los administradores, puede eludir. Acceso decisLas iones se rigen por reglas inmutables integradas en la infraestructura (como políticas de IAM en la nube o módulos de seguridad a nivel de sistema operativo). Esto significa:

Un administrador no puede cargar manualmente artefactos a un registro si la política de control de acceso de Mac los niega.
Los usuarios no pueden escalar privilegios ni alterar permisos fuera de las políticas de control de acceso definidas.
Automático CI/CD pipelineLos programas se ejecutan estrictamente dentro de sus permisos asignados, lo que evita la expansión del alcance.

Al eliminar las anulaciones manuales, el control de acceso obligatorio garantiza una postura de seguridad más sólida y confiable que RBAC o DAC por sí solos.

2.4 Control de acceso discrecional (DAC)

DAC permite a los propietarios de recursos asignar permisos manualmente. Es flexible, pero arriesgado. Un intercambio incorrecto puede comprometer un repositorio. DAC funciona así: "Eres el dueño, tú decides quién entra".

Ejemplo: El desarrollador invita a un colaborador externo y le otorga acceso de escritura al repositorio. El colaborador envía código inseguro directamente al dev .

In CI/CD, DAC podría parecer un desarrollador que otorga manualmente acceso de implementación de producción a un miembro temporal del equipo a través de la consola, fuera de cualquier política de control de acceso definida.

Cómo elegir una política de control de acceso que funcione en la vida real Pipelines

Control de acceso en Git

Utilice RBAC para gestionar los roles de colaborador, mantenedor y de lanzamiento. Bloquee los derechos de fusión en ramas protegidas. Requerir firma. commits y limitar quién puede eludir las protecciones.

Ejemplo: Reglas de protección de ramas de GitHub

Exigir pull request revisiones antes de fusionarse.
Descartar lo obsoleto pull request Aprobaciones cuando son nuevas commitLos s son empujados.
Requerir firma commits.
Omite el DAC para repositorios críticos para la producción. No otorgues acceso de escritura a la ligera.

Pipeline Cumplimiento

Establecer un control de acceso obligatorio para pipelines. Un modelo sólido de control de acceso de Mac limita los trabajos de CI únicamente a los permisos que necesitan.

Separa los secretos por entorno.
Utilice tokens únicos por entorno.
Evite que las ejecuciones manuales afecten la producción.

Ejemplo: Un trabajo de CI reutiliza un token de implementación entre las etapas de prueba y producción, enviando accidentalmente el código de prueba a producción.

Agregue reglas de control de acceso de Mac para controlar el alcance del token:

yaml
env:
  DEPLOY_TOKEN: ${{ Secretos.DEPLOY_TOKEN_PROD }}
if: github.ref == 'refs/heads/main' && github.actor == 'release-manager'

Ejemplo de alcance de Secretos: uso de tokens específicos del entorno

Delimitando adecuadamente los Secretos por entorno es fundamental Prevenir el acceso accidental o malicioso entre entornos. Por ejemplo, un token de implementación para el entorno de desarrollo nunca debería poder usarse para implementar en producción.

Así es como los controles basados en políticas de control de acceso aíslan el uso de Secreto en GitHub Actions:

yaml
env:
  DEPLOY_TOKEN_DEV: ${{ Secretos.DEPLOY_TOKEN_DEV }}
  DEPLOY_TOKEN_PROD: ${{ Secretos.DEPLOY_TOKEN_PROD }}

jobs:
  deploy-dev:
    if: github.ref == 'refs/heads/dev' && github.actor == 'developer'
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to Dev
        run: ./deploy.sh
        env:
          TOKEN: ${{ env.DEPLOY_TOKEN_DEV }}

  deploy-prod:
    if: github.ref == 'refs/heads/main' && github.actor == 'release-manager'
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to Prod
        run: ./deploy.sh
        env:
          TOKEN: ${{ env.DEPLOY_TOKEN_PROD }}

Esto garantiza que:

Solo el developer El rol puede activar implementaciones usando el token de desarrollo en el dev .
Solo el administrador de versiones El rol se puede implementar en producción usando el token de producción en el principal .

Este uso limitado de Secreto reduce el riesgo de que las fugas de tokens se intensifiquen en distintos entornos y hace cumplir el mínimo privilegio en CI/CD pipelines siguiendo fuertes políticas de control de acceso.

Controles de acceso a artefactos

Bloquear registros de artefactos mediante control de acceso obligatorio. CI/CD Los sistemas deberían gestionar las publicaciones, no los desarrolladores individuales.

Use RBAC para definir qué equipos extraen datos de registros específicos. Es posible que los desarrolladores solo necesiten acceso de lectura a los paquetes de producción.

json
{
  "rules": [
    {
      "action": "read",
      "resource": "npm-package:internal/*",
      "allowed_roles": ["developer", "qa"]
    },
    {
      "action": "write",
      "resource": "npm-package:internal/*",
      "allowed_principals": ["ci-pipeline"]
    }
  ]
}

Fallos comunes de control de acceso en flujos de trabajo de desarrollo

Acceso a repositorios excesivamente permisivo

Problema: Conceder a demasiados usuarios acceso de escritura/administración a los repositorios.
Cómo sucede: Los miembros del equipo ascienden o se incorporan sin que se revisen sus permisos. Los roles se sobrecargan.
Explotación del atacante: Los atacantes atacan estas cuentas mediante credenciales robadas o ingeniería social. Una vez dentro, pueden inyectar código malicioso, puertas traseras o eliminar el historial para ocultar rastros.

Permisos compartidos entre desarrollo y producción

Problema: Dejar que el desarrollo y la producción pipelines compartir permisos.
Cómo sucede: Los equipos reutilizan el mismo token de implementación o cuenta de servicio CI en todos los entornos.
Explotación del atacante: Una violación del entorno de desarrollo brinda a los atacantes acceso a producción. Control de acceso obligatorio Esto se puede evitar vinculando permisos a entornos específicos.

Carga manual de artefactos

Problema: Permitir cargas manuales de artefactos a los registros de producción.
Cómo sucede: Los desarrolladores pasan por alto pipelines para soluciones rápidas o parches urgentes.
Explotación del atacante: Las máquinas de desarrolladores comprometidas pueden cargar malware directamente al almacenamiento de artefactos, omitiendo todas las medidas de seguridad. CI/CD cheques.

Riesgo de abuso de la política de registro: La publicación manual de artefactos crea una superficie de ataque crítica en la cadena de suministro de software. Los atacantes que explotan la falta de transparencia... políticas de control de acceso Puede insertar código malicioso en paquetes confiables o imágenes de contenedores, lo que provoca una vulnerabilidad generalizada en sentido descendente. Incidentes recientes en la cadena de suministro de software han demostrado cómo la carga no regulada de artefactos puede escalar rápidamente a graves brechas de seguridad, afectando a innumerables usuarios y sistemas.

Ejemplo: aUn pasante con acceso completo al registro de npm publica una versión inestable por error. Si un atacante hubiera comprometido su equipo, podría haber publicado malware.

Pasos prácticos para implementar controles de acceso sólidos

Asigne roles a permisos exactos y descarte las configuraciones de un solo rol para todos
Automatice las comprobaciones de políticas de control de acceso en su CI/CD pipelines
Bloquear registros con control de acceso obligatorio
Registrar y supervisar continuamente el acceso a sistemas críticos
Trate las políticas de control de acceso como código. Cualquier error puede ser explotado.

El rol de Xygeni: Implementación y supervisión de políticas de acceso en flujos de trabajo de DevOps

xygeni Le ayuda a convertir el control de acceso obligatorio de la teoría a la acción al resolver desafíos reales y cotidianos de aplicación de políticas de control de acceso en DevSecOps. pipelines.

Solución al acceso a Git con permisos excesivos: Xygeni supervisa continuamente los repositorios de Git para detectar infracciones de RBAC, como asignaciones de roles sin revisar o falta de protecciones de rama. Alerta cuando las políticas de control de acceso se desvían de las reglas definidas y aplica medidas correctivas para evitar fusiones accidentales o solicitudes de acceso maliciosas.
Bloqueo CI/CD Pipelines: Los trabajos de CI a veces se ejecutan con alcances más amplios de lo previsto. Xygeni detecta cuándo CI/CD Los trabajos solicitan o operan más allá de sus roles asignados, lo que permite identificar la corrupción del alcance y el uso indebido de privilegios en tiempo real. Esto ayuda a aplicar los principios de control de acceso MAC dentro de la organización. pipelines vinculando el acceso estrictamente a la identidad y el propósito del trabajo.
Aplicación de los controles de publicación de artefactos: Si los desarrolladores siguen subiendo artefactos o imágenes manualmente, Xygeni lo detiene. Aplica un control de acceso obligatorio a nivel de registro para que solo los verificados... pipeline Las identidades pueden publicar artefactos. Se acabaron las subidas de datos a los registros de producción.
Monitoreo de acceso y señalización de anomalías: Con Xygeni, obtiene visibilidad sobre quién accedió a qué, cuándo y cómo. Monitorea continuamente el uso de Secretos, el acceso al repositorio y las interacciones del registro para detectar comportamientos inusuales, señalar configuraciones incorrectas y facilitar el análisis posterior a incidentes.

En pocas palabras: Xygeni aporta automatización y cumplimiento a la política de control de acceso para que su entorno DevOps se mantenga seguro sin ralentizarlo.

¿Qué política de control de acceso necesitas? Analicémosla

Índice

Publicaciones de lectura obligada

Últimas publicaciones de interés