El archivo de políticas que los usuarios no pueden anular

Módulo 6 · Seguridad y gobernanza · Lección 1 de 6

Al terminar esta lección podrás configurar managed-settings.json para el despliegue de un nuevo cliente y saber qué controles establecer antes de que alguien inicie sesión.

Tu cliente: FinCo Financial Services

FinCo es una firma de servicios financieros de 1.800 desarrolladores que moderniza su infraestructura de banca central. Es nativa de AWS y ejecuta todas sus cargas de trabajo en us-east-1 y us-west-2. Usa Okta para la gestión de identidades y SSO, y Jamf para la gestión de dispositivos macOS. Su equipo de seguridad tiene tres requisitos innegociables antes de que cualquier herramienta nueva entre en producción: todo el procesamiento de datos debe permanecer dentro de las regiones de AWS aprobadas, cada cuenta de desarrollador debe poder rastrearse hasta Okta, y cualquier herramienta nueva de IA debe superar una revisión de seguridad por escrito. Este es el contexto de cliente para el cuestionario de seguridad que construirás a lo largo del Módulo 6.

La capa de gobernanza

managed-settings.json está por encima de todo. Ninguna configuración de usuario o de proyecto puede anularla.

1. Managed settings. Aplicadas por IT mediante MDM o push desde el servidor. Ninguna otra capa puede sobrescribirlas. Aquí vive la política no negociable de la organización.
2. Argumentos de línea de comandos. Sobrescrituras a nivel de sesión, aplicadas al invocar la CLI. Útiles para scripts de automatización, pero temporales.
3. Configuración local del proyecto. .claude/settings.local.json: a nivel de desarrollador, normalmente no se versiona en el control de código fuente.
4. Configuración compartida del proyecto. .claude/settings.json: se versiona y se comparte con todo el equipo.
5. Configuración de usuario. ~/.claude/settings.json: preferencias personales, la capa de menor prioridad.

flowchart TB
    M["1 · Managed settings<br/>managed-settings.json, aplicada por IT"]
    CLI["2 · Argumentos de línea de comandos<br/>solo para la sesión"]
    LP["3 · Proyecto local<br/>.claude/settings.local.json"]
    SP["4 · Proyecto compartido<br/>.claude/settings.json"]
    U["5 · Usuario<br/>~/.claude/settings.json"]
    M -->|"mayor prioridad que"| CLI
    CLI -->|"mayor prioridad que"| LP
    LP -->|"mayor prioridad que"| SP
    SP -->|"mayor prioridad que"| U

Para recordar

Todas las demás capas de configuración sirven al individuo. managed-settings.json sirve a la organización. Un desarrollador puede configurar su propio settings.json personal, pero managed-settings.json significa que no puede deshacer lo que estableció el administrador.

Mecanismos de distribución

Tres formas de distribuirla. Cuál encaja depende de la gestión de dispositivos del cliente.

1. Server-managed

Se distribuye desde la consola de administración de Claude.ai (disponible en los planes Teams y Enterprise), lo que la convierte en la opción adecuada para organizaciones sin infraestructura de MDM existente.

Encaja con un cliente que: quiere control centralizado sin montar gestión de dispositivos. Es el camino más sencillo cuando no hay Jamf ni Intune. Enterprise desbloquea el conjunto completo de funciones de managed settings; Teams ofrece acceso básico a la consola de administración.

2. MDM / políticas del sistema operativo

Preferencias gestionadas de macOS mediante Jamf; registro de Windows mediante Intune o Group Policy. Es lo mejor para organizaciones que ya tienen gestión de dispositivos.

Encaja con un cliente que: ya gestiona los endpoints de sus desarrolladores. FinCo usa Jamf para macOS, así que esta es la vía natural para su despliegue, sin infraestructura nueva.

3. Basado en archivos

Instalación manual en directorios del sistema. Apropiado para pilotos, despliegues pequeños o pruebas por etapas antes de un despliegue completo con MDM.

Encaja con un cliente que: está probando antes de comprometerse. Sirve para una cohorte piloto, pero no escala: planifica el paso a MDM o a gestión desde el servidor antes de un despliegue completo.

flowchart LR
    C["Perfil del cliente"] -->|"ya gestiona los endpoints de sus desarrolladores"| M["MDM / políticas del sistema operativo<br/>Jamf, Intune o Group Policy"]
    C -->|"quiere control centralizado sin gestión de dispositivos"| S["Server-managed<br/>consola de Claude.ai, Teams o Enterprise"]
    C -->|"está probando antes de comprometerse"| F["Basado en archivos<br/>instalación manual en directorios del sistema"]

Controles del día 0

Bloquea la autenticación y el acceso a MCP antes de que alguien toque un teclado.

Autenticación: forceLoginMethod

Impone la autenticación claudeai o console. Bloquea el login con clave de API, que se salta el SSO y los controles de auditoría.

Para FinCo: configúralo en claudeai para que cada inicio de sesión pase por el SSO de Okta. Una clave de API eludiría su requisito de que cada cuenta debe poder rastrearse hasta Okta.

Autenticación: forceLoginOrgUUID

El login falla salvo que la cuenta pertenezca a la organización con el UUID especificado. Evita el acceso desde cuentas personales en el dominio corporativo.

Para FinCo: fija los inicios de sesión a la organización corporativa, de modo que un desarrollador no pueda entrar en silencio con una cuenta personal de Claude que use su correo de trabajo.

MCP: allowedMcpServers

Lista de permitidos con los nombres de los servidores MCP aprobados. Un arreglo vacío impone un bloqueo total: ninguna conexión MCP de ningún tipo.

Para FinCo: empieza con una lista restringida. Una lista explícita (o un arreglo vacío durante la revisión) significa que ningún servidor MCP se ejecuta hasta que el equipo de seguridad lo apruebe.

MCP: allowManagedMcpServersOnly

Solo pueden estar activos los servidores MCP definidos por el administrador. Los servidores que añaden los usuarios se bloquean, sin importar el estado de la lista de permitidos.

Para FinCo: es el control a nivel de categoría. Cierra toda la clase de riesgo de «el desarrollador añadió su propio servidor», no solo uno a la vez. Es la respuesta al escenario de esta lección.

Más allá del día 0

Hooks, permisos, fijación de versiones e instrucciones de la organización completan la política.

Hooks: allowManagedHooksOnly y disableAllHooks

Controlan qué scripts previos y posteriores a una tarea están permitidos para ejecutarse.

Por qué importa: los hooks ejecutan scripts arbitrarios alrededor de las tareas. allowManagedHooksOnly permite a la organización distribuir automatizaciones aprobadas y bloquea cualquier cosa que un desarrollador conecte por su cuenta.

Permisos: allowManagedPermissionRulesOnly y disableAutoMode

Evitan que los usuarios anulen las reglas de aprobación de herramientas o activen de forma global el auto-aceptado.

Por qué importa: disableAutoMode impide que un desarrollador desactive los avisos de aprobación, manteniendo a una persona en el proceso de aprobación de las llamadas a herramientas en un entorno regulado.

Fijación de versiones: requiredMinimumVersion y requiredMaximumVersion

Fijan el rango de versiones de la CLI y hacen que Claude Code salga al iniciar si la versión instalada queda fuera de ese rango.

Por qué importa: para clientes con reglas de cumplimiento de versiones probadas, esto es una aplicación forzosa, no documentación. Claude Code se niega a arrancar fuera del rango aprobado.

CLAUDE.md de la organización: la clave claudeMd

Inyecta instrucciones para toda la organización en cada sesión como memoria gestionada, aplicadas antes que cualquier CLAUDE.md de proyecto o de usuario.

Por qué importa: como se carga primero y no puede anularse, es el lugar para las instrucciones innegociables, no para preferencias que un desarrollador pueda ignorar en silencio.

Instrucciones de la organización: qué escribir

El CLAUDE.md gestionado define la política. Cuatro principios para escribirlo bien.

1. Política, no preferencias

Los requisitos de seguridad, las reglas de cumplimiento y las restricciones de manejo de propiedad intelectual van aquí. Las preferencias de estilo de código y de formato de salida van en el CLAUDE.md del proyecto.

La prueba: ¿incumplir esto generaría un problema de cumplimiento o legal? Si la respuesta es sí, es una instrucción de la organización. Si no, pertenece a la capa de proyecto o de usuario, donde los desarrolladores pueden ajustarla.

2. Usa Claude para redactarlo

Comparte con Claude la política de uso aceptable o las pautas de manejo de datos del cliente y pídele un borrador de CLAUDE.md gestionado. Después revísalo y ajústalo.

Por qué funciona: Claude produce instrucciones calibradas al lenguaje y a la estructura de políticas del propio cliente. El trabajo del consultor pasa a ser editar y aprobar, en lugar de redactar desde cero.

3. Evita la sobrerrestricción

Las instrucciones de la organización demasiado prescriptivas degradan la calidad del resultado y generan fricción para los desarrolladores. Restringe solo lo que debe restringirse y deja a Claude margen para operar dentro de esos límites.

En la práctica: un equipo de seguridad que añade 30 líneas de reglas de estilo junto a 3 requisitos de cumplimiento entierra la señal. Claude intentará satisfacer todas las instrucciones por igual, diluyendo las que realmente importan.

4. Incluye el porqué

Añade un breve contexto junto a cada restricción, como «por requisitos regulatorios» o «según nuestra política de propiedad intelectual». Los desarrolladores que entienden una limitación tienen menos probabilidades de sortearla.

Beneficio secundario: las razones hacen que las instrucciones de la organización sean más fáciles de auditar y actualizar cuando cambian las políticas. Una restricción sin contexto es más difícil de evaluar cuando alguien pregunta si todavía aplica.

Comprueba tu comprensión

Dos controles que se sostienen

requiredMinimumVersion es un mecanismo de aplicación forzosa, no documentación: Claude Code sale al iniciar si la versión queda fuera del rango configurado. El CLAUDE.md gestionado se carga antes que cualquier CLAUDE.md personal o de proyecto, y las capas de menor prioridad no pueden anularlo.

Actividad: ¿quién gana?

Cada capa quiere establecer el mismo valor. El ajuste de la actividad es autoUpdates. Activa una capa para «establecerla» y observa cuál tiene efecto. El administrador establece primero la capa gestionada. Las capas son:

• Managed settings: managed-settings.json, aplicada por IT.
• Argumentos de línea de comandos: --setting, solo para la sesión.
• Proyecto local: .claude/settings.local.json.
• Proyecto compartido: .claude/settings.json.
• Usuario: ~/.claude/settings.json, personal.

Ver respuesta

Respuesta correcta: managed settings (capa 1). Ninguna configuración de usuario o de proyecto puede anularla.

Debrief cuando gana la capa gestionada: «Managed settings gana. No importa cuántas capas inferiores establezcan este valor: el managed-settings.json del administrador surte efecto y el resto queda anulado. Para eso existe el archivo.»

Debrief cuando se elige una capa inferior: «La capa elegida gana, por ahora. En cuanto el administrador establezca la capa gestionada, esta tendrá prioridad y esta elección quedará anulada.»

Escenario: ¿qué ajuste cierra el riesgo de servidores MCP no aprobados?

Un equipo de seguridad de un cliente detecta que algunos desarrolladores han conectado un servidor MCP personal de GitHub que accede a repositorios fuera de la lista aprobada. Necesitas añadir un solo ajuste a managed-settings.json para cerrar esta categoría de riesgo. ¿Cuál es?

• A · disableAllHooks: true. Impide que se ejecute cualquier script de hook durante las tareas.
• B · allowManagedMcpServersOnly: true. Solo los servidores MCP definidos por el administrador pueden estar activos, sin importar lo que añadan los usuarios.
• C · Añadir el nombre del servidor a deniedMcpServers. Bloquea ese servidor concreto por nombre.
• D · forceLoginMethod: "claudeai". Impone el método de autenticación SSO.

Ver respuesta

Respuesta correcta: B. allowManagedMcpServersOnly aborda la categoría, no solo el síntoma. Denegar un servidor por nombre deja abierta la puerta a cualquier otro servidor no aprobado que un desarrollador añada después. Este ajuste garantiza que solo puede estar activo lo que el administrador aprueba explícitamente, cerrando la clase de riesgo en lugar de parchear instancias individuales.

Ideas clave

• La jerarquía de configuración coloca managed-settings.json (la organización) por encima de todas las demás capas: ningún ajuste personal o de proyecto puede anularla.
• Hay tres mecanismos de distribución: server-managed (Teams o Enterprise), MDM o políticas del sistema operativo, y basado en archivos. La elección depende de la gestión de dispositivos del cliente.
• Los controles del día 0 se establecen antes de que alguien use la herramienta: forceLoginMethod y forceLoginOrgUUID para la autenticación; allowedMcpServers y allowManagedMcpServersOnly para MCP.
• Más allá del día 0, los hooks, las reglas de permisos, el rango de versiones y el CLAUDE.md de la organización completan la política.
• El CLAUDE.md gestionado debe contener política (requisitos de seguridad y de cumplimiento), con su porqué, y no sobrerrestringir: las preferencias de estilo van en el CLAUDE.md del proyecto.

Siguiente: Sistema de permisos y control de operaciones