Deployment Architecture — Resumen de estudio

Path: Architect · 5 lecciones interactivas con simulaciones

Recomendar, configurar y defender la vía de despliegue de Claude Code de un cliente: vía → brechas → proxy → gateway → cuestionario de seguridad. Entregable del curso: el Deployment Decision Doc.

1. Marco de decisión

• La vía define quién factura, cómo se autentican los usuarios, dónde quedan los datos de uso y qué funciones existen. Afecta tres frentes: procurement (factura), seguridad (autenticación) y finanzas (chargeback). Revertirla obliga a rehacer los tres, así que es una puerta de un solo sentido: se decide en el pre-kickoff (Día −14 a Día 0) de una activación de 30 días.
• Regla: los compromisos de nube y la postura de compliance del cliente eligen la vía. Tu trabajo es sacarlos a la luz antes de que el cliente elija por inercia.

4 preguntas, en este orden:

1. Compromisos de nube (EDP de AWS, CUD de GCP, MACC de Azure): es el factor más fuerte. Pregúntale a procurement, no solo a IT.
2. Cómo prefiere comprar procurement: suscripción con un proveedor nuevo (meses) o marketplace con un proveedor que ya tiene (días).
3. Compliance: si exige ZDR, solo Enterprise directo; si exige que el tráfico quede en su propio tenant y región, Bedrock o Vertex.
4. Quién administra usuarios y presupuestos: Enterprise lo trae resuelto; en la nube se arma con IAM + herramientas de costo o con un LLM gateway.

El tradeoff que hay que decir en voz alta:

• Nube: el perímetro y las herramientas del cliente. Pierde la web de Claude, pierde ZDR y tiene algunas brechas. El cliente se encarga de fijar versiones de modelo y de construir el dashboard de uso.
• Enterprise directo: el producto completo, pero un proveedor nuevo, precio por asiento y tráfico hacia Anthropic.

Checklist del Día −14 según la vía:

• Enterprise: la identidad es lo más lento (SSO/domain capture, asientos y roles, managed settings, solicitud de ZDR por organización).
• Bedrock: formulario por cuenta (acceso inmediato), IAM, habilitar regiones, fijar IDs de modelo.
• Vertex: solicita el acceso el Día 1 (24–48 h), cuota por región, fijar IDs.
• Foundry: crear el recurso y los deployments con versión fija (no auto-update), roles de Entra, fijar nombres.

Simulación Meridian Capital (800 devs, servicios financieros):

1. B: primero, compromisos de nube y forma de compra.
2. A: Bedrock, condicionado a la revisión de seguridad (hay un EDP de 3 años y el CFO quiere consumirlo).
3. B: "No hay ZDR en Bedrock: la retención la rige AWS".
4. C: nombrar las brechas de paridad y ofrecer un memo de una página.

2. Brechas de paridad: avísalas antes del contrato

• Todas las brechas se descubren; la única pregunta es quién y cuándo. Avisada en el contrato es consultoría; descubierta en la semana 3 es un defecto con tu nombre.
• Las 6 brechas del memo:
  • Bedrock: no funciona WebSearch → define en el pre-kickoff una alternativa MCP aprobada.
  • Ninguna vía de nube incluye Claude en la web.
  • No aplica el ZDR de Anthropic (es otro control, no ausencia de control).
  • Las versiones de modelo son responsabilidad del cliente: un alias puede ir atrasado o apuntar a un modelo no habilitado; las tareas de fondo usan el modelo principal en vez de uno tipo Haiku. Fija versiones.
  • La telemetría viene apagada por defecto (métricas, error reporting, /feedback genera un bundle local) → OTel o gateway para las métricas del CoE.
  • Vertex: 24–48 h de Model Garden; activa explícitamente MCP tool search (viene apagado); prompt caching según la región (también en Bedrock).
• Formato del memo (una página): nombra la brecha → di cuándo y a quién le pegaría → empieza por la mitigación.

Simulación Northgate Logistics:

1. A: mantener todas las líneas, cada una como mitigación.
2. B: responder con la línea del memo y la alternativa MCP.
3. A: explicar el default de telemetría y proponer OTel, Cost Explorer o gateway.

3. Proxy corporativo

• El primer ticket de cualquier activación es de red.
• Proxy: saca el tráfico del edificio (perímetro, TLS inspection; lo gestionan redes y seguridad). Gateway: gobierna el tráfico al modelo. Se pueden combinar.
• Variables: HTTPS_PROXY, HTTP_PROXY, NO_PROXY (separadas por coma o espacio; credenciales user:pass@ sacadas de un secrets manager).
  • Son variables del sistema operativo: no se ponen en los settings de Claude Code → despliégalas por MDM (Jamf/Kandji en macOS, registro en Windows).
  • SOCKS no está soportado. NTLM/Kerberos → usa un gateway.
• TLS inspection (Zscaler, Netskope): "self-signed certificate in chain" significa que el proxy está haciendo su trabajo.
  • Claude Code confía en el almacén de certificados del sistema.
  • Si falla: NODE_EXTRA_CA_CERTS=/ruta/corp-root-ca.pem (también CLAUDE_CODE_CERT_STORE; para mTLS, CLAUDE_CODE_CLIENT_CERT y _KEY).
  • Nunca desactives la verificación TLS.
• Allowlist con el motivo de cada dominio:
  • api.anthropic.com: la API en la vía directa y el chequeo de seguridad de WebFetch en todas las vías. Si lo bloqueas en Bedrock, WebFetch falla salvo que desactives el preflight.
  • claude.ai / platform.claude.com: autenticación (sobre todo en la vía directa).
  • downloads.claude.ai: instalador, auto-update, plugins.
  • Vías de nube: los endpoints del proveedor. Verifica con /status.
• Managed settings (managed-settings.json): en la cima de la jerarquía; no se pueden sobrescribir. Fijan permisos, MCP permitidos, login SSO obligatorio y versión mínima.
  • 3 formas de entrega: server-managed desde la consola de admin (solo Enterprise), MDM (plist o registro) o archivo en el directorio del sistema. Todas requieren permisos de admin.

Simulación Halvern Bank (40 terminales colgadas):

1. A: llamar al equipo de red (¿hay proxy? ¿TLS inspection?).
2. B: desplegar HTTPS_PROXY y NO_PROXY por MDM.
3. B: NODE_EXTRA_CA_CERTS (nunca NODE_TLS_REJECT_UNAUTHORIZED=0).
4. A: allowlist con el motivo de cada dominio (sin wildcards).

4. Patrón LLM gateway

• "Un proxy pasa tráfico; un gateway lo entiende."
• 5 capacidades:
  • Auth centralizada (tokens de corta vida; se rota una vez).
  • Costo por equipo.
  • Límites de presupuesto aplicados antes de la llamada.
  • Enrutamiento de modelos detrás de una URL estable (Bedrock y Vertex juntos).
  • Auditoría en el stack del cliente (en la nube, de ahí sale la observabilidad).

export ANTHROPIC_BASE_URL=https://llm-gateway.client.com ; export ANTHROPIC_AUTH_TOKEN=team-token
export CLAUDE_CODE_USE_BEDROCK=1 ; export ANTHROPIC_BEDROCK_BASE_URL=.../bedrock ; export CLAUDE_CODE_SKIP_BEDROCK_AUTH=1
export CLAUDE_CODE_USE_VERTEX=1  ; export ANTHROPIC_VERTEX_BASE_URL=.../vertex   ; export CLAUDE_CODE_SKIP_VERTEX_AUTH=1

• Skip-auth: el gateway inyecta las credenciales. apiKeyHelper permite tokens rotativos desde un vault.
• ⚠️ Criterio de aceptación: el gateway debe reenviar intactos anthropic-beta y anthropic-version. Si los quita, las funciones se degradan y parece un bug.
• Headers de atribución (los envía Claude Code solo): X-Claude-Code-Session-Id, X-Claude-Code-Agent-Id (subagents) y X-Claude-Code-Parent-Agent-Id → chargeback por equipo.
• LiteLLM es la implementación de referencia (formato Anthropic y OpenAI). ⚠️ Las versiones 1.82.7 y 1.82.8 de PyPI estaban comprometidas con malware: verifica la versión segura.
• Recomienda un gateway antes de que pregunten (más de un equipo, chargeback o multi-nube).

5. Datos, compliance y ZDR

• ¿Entrenan con nuestros datos? "No bajo términos comerciales, salvo que hagan opt-in explícito" (p. ej. el Development Partner Program, que no existe en Bedrock ni Vertex). No digas "nunca".
• Retención: la rige el contrato (confirma el plazo con el account team). Ojo: Claude Code guarda transcripciones en local, en texto plano, en el home del usuario (configurable) → es tema de gestión de dispositivos.
• Cifrado:
  • Directo: AES-256 + ZDR.
  • Bedrock: cuenta AWS, KMS opcional.
  • Vertex: CMEK opcional.
  • Foundry: confirma la ruta de los datos.
• ZDR, con precisión:
  • Solo Claude Code en Enterprise, habilitado por organización tras una revisión de elegibilidad (no viene incluido por defecto) y no disponible en las vías de nube.
  • Cubre la inferencia de Claude Code; los costos, analytics y audit logs siguen funcionando.
  • No cubre el chat de claude.ai, Cowork, la metadata de admin ni lo que procesan los MCP de terceros.
  • Desactiva Claude Code en la web, las sesiones remotas desde desktop y /feedback.
  • Las sesiones marcadas por abuso se pueden retener hasta 2 años.
  • Con ZDR, analytics muestra uso pero no métricas de contribución.
  • Cada organización nueva necesita su propia habilitación.
• Residencia: el control regional está en las vías de nube (regiones de Bedrock; endpoints de Vertex). En la vía directa, las garantías por región se hablan con el account team: no improvises.
• Certificaciones en trust.anthropic.com (autoservicio): SOC 2 Type 2, ISO 27001:2022, 27017/27018, ISO 42001, CSA STAR L2, HIPAA (BAA), GDPR, NIST 800-171, FedRAMP High vía Claude for Government y resúmenes anuales de pentest.
• Regla: responde con lo que puedes citar, nombra lo único que vas a verificar y nunca inventes una garantía.

Simulación Corvane Health (CISO):

1. A: "no bajo términos comerciales, salvo opt-in".
2. B: retención en servidor + transcripciones locales en cada laptop.
3. B: ZDR y Claude Code en la web chocan: hay que elegir.
4. C: "No: Foundry enruta a infraestructura de Anthropic; para residencia estricta, usa Bedrock o Vertex".
5. A: "los tienes hoy desde el Trust Center".