Lección 5 · Transporte, registros y operación del servidor

Examina cómo se conecta el cliente y qué información puede quedar en el recorrido técnico.

Formas de conexión

El arranque admite stdio, streamable-http y sse, este último identificado como heredado. El valor por defecto es stdio. La elección cambia cómo se comunica el cliente con el servidor y qué exposición tiene el proceso. Una configuración local por procesos y un servicio accesible por red no tienen la misma frontera de acceso.

La creación del servidor MCP examinada configura nombre, versión y ciclo de vida, sin incorporar explícitamente un proveedor de autenticación de clientes en esa llamada. Esto delimita lo que muestra el código. No permite afirmar que cualquier despliegue sea accesible sin control: la protección efectiva puede depender del SDK, de opciones y de componentes del entorno que aquí no se han ejecutado.

Dos autenticaciones diferentes

La credencial Microsoft responde a cómo el servidor se autentica ante Microsoft. La autenticación del cliente MCP responde a quién puede solicitar operaciones al servidor. Una credencial Microsoft correctamente configurada no resuelve por sí sola el segundo problema. El gobierno del sistema completo necesita identificar ambos lados del puente.

Además, disponer de autenticación no resuelve toda la autorización. La pregunta «quién puede conectarse» se distingue de «qué herramientas puede solicitar y en qué condiciones». Las prácticas oficiales de seguridad MCP amplían la separación de estas fronteras.

Registros con contenido

Las funciones start_thread y update_thread emiten llamadas de depuración que incluyen título o contenido, junto con identificadores pertinentes. La configuración de logging y la del entorno determinan qué se registra y dónde termina. La presencia de esas llamadas no demuestra que todos los despliegues conserven ese contenido ni que nunca lo hagan.

Los registros pueden ayudar a reconstruir una operación, pero también contener conversaciones internas o datos de identidad. La utilidad de una traza y su protección deben considerarse conjuntamente. El hecho de disponer de un identificador de mensaje tampoco equivale a disponer de un registro de aprobación humana.

ElementoInformación observada en el códigoLímite de lo que se sabe
TransportesTres opciones de arranqueNo se ha comprobado la exposición de un despliegue real
CredencialesVariables de aplicación y destino requeridasNo se han examinado secretos ni permisos de un tenant
DepuraciónLlamadas con contenido e identificadoresEl almacenamiento efectivo depende de la configuración
Errores de operaciónRegistro y propagación en funciones del clienteNo equivalen a un proceso empresarial de incidentes completo

Trazabilidad del uso

El servidor devuelve identificadores que pueden vincular una respuesta a un hilo. El proceso de gobierno puede necesitar además petición original, solicitante, revisión y decisión. La implementación no demuestra por sí sola esa cadena completa. Se distingue información técnica disponible de evidencia organizativa conservada.

No se han iniciado procesos del servidor ni realizado llamadas externas en este monográfico. La relación con seguimiento y seguridad procede de la lectura de contratos y del código. Esa base permite explicar con precisión qué habría que conocer de una instalación sin atribuirle controles o resultados que no se han observado.

MCP Teams Server · Transporte, registros y operación del servidor

Amplía este punto en el curso

Módulo 7 · Datos y seguridad. Amplía el acceso al servicio y la protección de registros con información sensible.

Módulo 10 · Seguimiento e incidentes. Explica qué contexto necesita una traza para apoyar una investigación o conclusión.

Fuentes de esta lección

M1 · Presentación oficial

M2 · Código: herramientas y arranque MCP

M3 · Código: operaciones de Teams

M4 · Configuración Microsoft y permisos

M4 · Código: configuración del servidor

E2 · MCP: prácticas de seguridad

Registro unificado: qué demuestra y qué debe evitar

La capa de integración puede asignar un correlation_id a la propuesta y utilizarlo en aprobación, ejecución y verificación. El servidor analizado no genera por sí solo este expediente completo. El esquema del curso es un modelo organizativo; sus campos no se presentan como la salida nativa del SDK ni como un formato impuesto por una norma.

Grupo del registroContenido mínimo del ejemploPrecaución de diseño
ContextoIdentificador de solicitud, versión del cliente, commit del servidor y entornoNo incluir secretos, tokens ni variables de entorno completas
AcciónHerramienta, equipo, canal, hilo y referencia de propuestaEl destino forma parte de lo aprobado
AprobaciónReferencia, aprobador, fecha, expiración y huella de la propuestaComprobar atribuciones y correspondencia antes de ejecutar
ResultadoEstado confirmado, fallido o incierto y referencias retornadasNo inventar un HTTP 200 ni interpretar una pérdida de respuesta como éxito
ConservaciónPolítica de acceso y retención aplicableNo fijar un plazo universal ni almacenar todo el chat por defecto

El ejemplo descargable de la entrega usa identificadores sintéticos. La propuesta original se conserva, si es necesaria, en un repositorio de acceso restringido; el registro general guarda su referencia. Una huella no anonimiza automáticamente datos personales y tampoco permite reconstruir el texto sin ese repositorio.

Si se añade CerbIA en una arquitectura futura, se registran la versión de la política, el resultado real y la actuación del anfitrión. No se utiliza un supuesto campo cerbia_verdict: PASSED como prueba de integración nativa. Una evaluación técnica favorable no sustituye la aprobación exigida por este caso.

Comprobación de la cadena de suministro

Identificar un commit es el inicio del inventario, no un resultado de conformidad. Deben relacionarse artefacto desplegado, dependencias resueltas, licencias, resultados del análisis de vulnerabilidades y decisiones de tratamiento. La fecha y el alcance de la comprobación importan: un análisis de otro entorno o de una versión anterior no prueba el estado actual. Las dependencias Microsoft y del SDK MCP forman parte de esta revisión.

Descargar el monográfico en PDF
José Manuel Hernández AgudoFundamentos del SGIA e ISO/IEC 42001
Monográfico 6 · MCP Teams Server · Lección 5 de 6