Seguridad, privacidad y confianza cuando trabajamos en su entorno Microsoft
Accesos controlados, confidencialidad, mínimo privilegio, trazabilidad y una forma de trabajar adaptada a los requisitos de cada organización.
Los proyectos de Microsoft 365, Microsoft Azure, ciberseguridad, migración y servicios gestionados pueden requerir acceso a sistemas críticos. En MSAdvance tratamos ese acceso como una responsabilidad. Antes de comenzar definimos qué necesitamos, para qué lo necesitamos, durante cuánto tiempo, qué controles del cliente debemos respetar y cómo debe retirarse el acceso cuando deja de ser necesario.
Las respuestas que Security, IT, Legal y Procurement suelen necesitar primero
El detalle depende siempre del servicio contratado, pero estos principios resumen cómo planteamos el acceso a entornos de clientes.
Sí. Podemos firmar NDA antes de compartir información técnica sensible o iniciar el discovery.
Sí. Prestamos un servicio remoto global y adaptamos el acceso a las restricciones del cliente.
No por defecto. Solicitamos el rol adecuado a la tarea y utilizamos privilegios elevados cuando son necesarios.
Sí, cuando el tenant y el licenciamiento lo permiten. Es un modelo especialmente apropiado para acceso temporal.
Sí, cuando resulte aplicable al servicio y a la relación de partner establecida con el cliente.
Sí. Puede ser apropiado para administración delegada de suscripciones o resource groups.
No es el objetivo. Procuramos minimizar exportaciones y trabajar directamente sobre las plataformas necesarias.
Revisamos los accesos creados específicamente para el proyecto y retiramos o reducimos los que dejan de ser necesarios.
Este Trust Center describe nuestro enfoque general. Los controles, niveles de servicio, responsabilidades y obligaciones aplicables a un cliente concreto son los definidos en la documentación contractual y técnica correspondiente.
El acceso se diseña para el trabajo que debe realizarse, no para facilitar la administración
Microsoft recomienda combinar mínimo privilegio, acceso limitado en el tiempo, MFA, revisión periódica y auditoría. Esos principios encajan con la forma en la que planteamos proyectos y servicios administrados.
Confidencialidad
Podemos formalizar NDA antes de intercambiar arquitectura, dominios, inventarios, información de seguridad o datos relacionados con operaciones corporativas.
Mínimo privilegio
Solicitamos permisos acordes a las tareas previstas y evitamos ampliar privilegios únicamente porque resulte más cómodo.
Autenticación fuerte
Favorecemos MFA y controles de identidad reforzados para cuentas que operan sobre funciones administrativas.
Acceso temporal
Cuando el entorno lo permite, PIM y otros modelos JIT reducen la necesidad de privilegios permanentemente activos.
Trazabilidad
Utilizamos las capacidades de auditoría de Microsoft y documentación de proyecto para poder explicar cambios relevantes.
Minimización de datos
Si una tarea puede ejecutarse sin exportar información fuera del entorno necesario, evitamos crear copias adicionales.
Adaptación al negocio
Nos adaptamos a ventanas, aprobaciones, VPN, VDI, bastiones, restricciones territoriales y procesos internos cuando aplican.
Cierre seguro
El final del proyecto incluye revisar permisos, aplicaciones, cuentas y artefactos que ya no tienen una finalidad operativa.
Separación de funciones
Los perfiles y permisos pueden diferenciarse según responsabilidad, workload y necesidad de aprobación.
Control del cambio
Tener privilegios técnicos no equivale a realizar cambios de producción sin la coordinación necesaria.
Aplicaciones bajo control
Service principals, consentimientos y permisos Graph se tratan como identidades con impacto de seguridad.
Gobierno del cliente
El cliente conserva el gobierno de su tenant y puede revisar, modificar o retirar los accesos concedidos.
La ubicación física no debería impedir acceder al especialista adecuado
MSAdvance presta servicios de forma remota a organizaciones de diferentes países y zonas horarias. El modelo remoto facilita reunir perfiles especializados sin renunciar a controles de acceso, coordinación y trazabilidad.
Remoto no significa acceso sin restricciones
El acceso remoto puede realizarse mediante cuentas nominales protegidas con MFA, pero también podemos adaptarnos a arquitecturas más restrictivas cuando la organización las requiere.
En clientes enterprise es habitual que la administración de terceros esté condicionada por VPN corporativa, VDI, jump servers, bastiones, estaciones privilegiadas, Conditional Access, rangos IP autorizados, restricciones geográficas o ventanas horarias. Esos requisitos se estudian durante el onboarding técnico.
Servicio global no significa transferencia indiscriminada de información
La ubicación del profesional, la residencia de los datos, la infraestructura utilizada por una herramienta y la existencia de una transferencia internacional son cuestiones diferentes.
Si el cliente tiene restricciones específicas de jurisdicción, residencia, acceso territorial o proveedores, deben incorporarse al diseño del servicio antes de comenzar.
La confianza técnica empieza antes de recibir la primera cuenta administrativa
Un discovery puede revelar información sensible incluso antes de firmar un proyecto: adquisiciones, dominios, vulnerabilidades, usuarios, topología, volumen de datos, aplicaciones críticas o decisiones corporativas todavía no públicas.
Non-Disclosure Agreement
Firmamos NDA cuando el cliente o el escenario lo requieren, incluido antes de compartir información técnica detallada.
Statement of Work
Un alcance técnico claro ayuda a separar sistemas incluidos, responsabilidades, exclusiones, entregables y criterios de aceptación.
Protección de datos
Cuando el servicio implica tratamiento de datos personales por cuenta del cliente, la relación debe documentarse conforme al rol y obligaciones aplicables.
Security Addendum
Podemos revisar anexos de seguridad, políticas de proveedores y controles internos que deban incorporarse a la prestación.
Podemos trabajar sobre la documentación del cliente
En proyectos enterprise es frecuente que Procurement, Legal, Security o Data Protection dispongan de sus propias cláusulas, anexos, cuestionarios y procesos de alta de proveedores.
El objetivo es que el contrato, la arquitectura de acceso y la operación diaria sean coherentes entre sí.
Todo acceso debería responder a tres preguntas: qué, para qué y hasta cuándo
Tratamos los permisos como parte del diseño del proyecto. No como un prerrequisito genérico que se concede una vez y permanece indefinidamente.
Necesidad
Identificamos tareas y recursos que requieren acceso.
Alcance
Determinamos workload, rol y ámbito.
Aprobación
El cliente concede o aprueba el acceso.
Uso
Se utiliza para el alcance acordado.
Revisión
Evaluamos si sigue siendo necesario.
Retirada
Se reduce o elimina cuando desaparece la necesidad.
Global Administrator no es nuestro punto de partida para todos los proyectos
Hay operaciones que pueden necesitar privilegios elevados, pero muchas tareas pueden ejecutarse con roles específicos, lectura, permisos de workload o acceso temporal.
Microsoft recomienda conceder un conjunto concreto de permisos, sobre un ámbito concreto y durante un periodo concreto. Ese es el criterio que utilizamos como referencia al diseñar el acceso.
Un assessment, una migración y un managed service no deberían compartir automáticamente el mismo modelo de privilegios
La siguiente matriz es orientativa. El diseño definitivo depende de tecnología, funcionalidades, licencias y alcance.
| Escenario | Objetivo | Modelo preferente | Acceso elevado | Cierre |
|---|---|---|---|---|
| Assessment Microsoft 365 | Revisar configuración, usuarios, seguridad, licencias y riesgos. | Lectura y roles de auditoría cuando resulten suficientes. | Normalmente limitado si no se realizan cambios. | Retirar acceso temporal y entregar findings. |
| Tenant-to-Tenant | Mover identidades, correo, OneDrive, SharePoint, Teams y otros objetos. | Roles por workload, apps y permisos requeridos por las herramientas seleccionadas. | Puede ser necesario para operaciones concretas de tenant. | Revisar apps, consentimientos, cuentas y relaciones de acceso. |
| Google Workspace a Microsoft 365 | Migrar correo, calendarios, contactos y datos hacia Microsoft 365. | Permisos específicos en origen y destino según herramienta y workload. | Depende de la plataforma y del método de migración. | Revocar acceso de herramientas y credenciales temporales. |
| Microsoft Entra / Seguridad | Diseñar MFA, Conditional Access, PIM, roles y controles. | Roles específicos de identidad y seguridad. | Algunas modificaciones críticas requieren roles privilegiados. | Validar acceso, break-glass y documentación. |
| Microsoft Intune | Configurar dispositivos, compliance, aplicaciones y políticas. | Roles de Intune y scopes apropiados. | No debería implicar automáticamente Global Administrator. | Validar políticas y retirar accesos de proyecto. |
| Azure Architecture | Diseñar o implementar recursos, redes, políticas y servicios. | Azure RBAC por suscripción, resource group o recurso; Azure Lighthouse cuando aplica. | Owner o User Access Administrator únicamente cuando la tarea lo exige. | Revisar RBAC, service principals y delegaciones. |
| Managed Services | Administración recurrente y soporte. | GDAP, Azure Lighthouse, roles granulares y grupos dedicados cuando encajan. | Preferencia por elevación temporal para tareas sensibles. | Offboarding formal al finalizar el servicio. |
La cuenta que administra el entorno es parte del perímetro de seguridad
Microsoft recomienda mínimo privilegio, MFA para cuentas administrativas, PIM para acceso just-in-time y revisiones periódicas de permisos. El acceso privilegiado debe diseñarse con especial cuidado.
Autenticación fuerte para accesos administrativos
Favorecemos MFA para las identidades utilizadas en administración. Cuando el cliente dispone de Conditional Access, podemos operar dentro de las políticas establecidas.
Priorizamos identidades que permitan asociar la actividad humana a una persona o función identificable.
MFA, ubicación, dispositivo, red y otros controles pueden formar parte del acceso.
Privilegios just-in-time y limitados en el tiempo
Microsoft Entra Privileged Identity Management permite que un usuario sea elegible para un rol y lo active durante un periodo limitado. Puede incorporar MFA, aprobación, justificación y notificaciones.
Reduce el tiempo durante el que una identidad mantiene privilegios elevados activos.
Los accesos temporales pueden expirar automáticamente según la política configurada.
Las cuentas de emergencia del cliente no forman parte del acceso operativo habitual de MSAdvance
Microsoft recomienda mantener cuentas de acceso de emergencia para escenarios en los que las cuentas administrativas normales no pueden utilizarse. Su objetivo es la resiliencia del cliente, no facilitar la administración cotidiana de un proveedor.
Las cuentas break-glass deberían permanecer bajo el gobierno y procedimientos de emergencia de la organización.
Cualquier utilización extraordinaria debería responder a un escenario autorizado y trazable.
GDAP y Azure Lighthouse permiten diseñar relaciones de administración con más control
Para servicios recurrentes, el objetivo no debería ser crear una cuenta Global Administrator permanente en cada cliente si existe un modelo delegado más apropiado para el escenario.
Granular Delegated Admin Privileges
Microsoft define GDAP como un mecanismo para que los partners configuren acceso granular, de mínimo privilegio y limitado en el tiempo a workloads de clientes.
Azure Lighthouse
Permite delegar suscripciones o resource groups con roles concretos, manteniendo los recursos dentro del tenant del cliente.
Acceso revocable
El cliente conserva capacidad para revisar y retirar la delegación cuando deja de ser necesaria.
La administración delegada no elimina la responsabilidad de diseñar bien los roles
Tanto GDAP como Azure Lighthouse permiten construir un modelo más granular, pero los roles concretos siguen siendo una decisión de seguridad.
Para tareas que requieren privilegios excepcionales, preferimos tratar esa elevación como una necesidad específica y no como el estado normal de la relación.
Un service principal con permisos amplios puede ser tan sensible como una cuenta administrativa
Las migraciones, automatizaciones y herramientas de administración pueden utilizar aplicaciones empresariales, OAuth y Microsoft Graph. Esos permisos forman parte de la superficie de seguridad.
Permisos delegados
La aplicación actúa en nombre de un usuario y su acceso depende de los scopes concedidos y del acceso efectivo de esa identidad.
Permisos de aplicación
La aplicación puede operar sin un usuario conectado. Por ese motivo los permisos application requieren una revisión especialmente cuidadosa.
Least privilege en Graph
Microsoft recomienda seleccionar el nivel de permiso más bajo que permita ejecutar la operación requerida.
Consentimiento administrativo
Si una herramienta necesita admin consent, debemos saber qué permisos solicita y con qué finalidad.
Service principals
Las identidades de aplicación creadas para un proyecto deben incluirse en la revisión de seguridad y cierre.
Revocación
Consentimientos y aplicaciones que ya no cumplen una finalidad deben retirarse o reducirse.
Las contraseñas de usuarios finales no son un mecanismo normal de administración moderna
Microsoft 365, Microsoft Graph y las herramientas modernas permiten trabajar con OAuth, aplicaciones, roles y mecanismos de autorización sin conocer la contraseña de cada usuario.
Algunos sistemas heredados, integraciones o plataformas de origen pueden requerir credenciales técnicas. Cuando ocurre, acordamos con el cliente qué credencial se necesita, quién la entrega, cómo se utiliza y cuándo debe rotarse o eliminarse.
El mismo principio se aplica a client secrets, certificados, claves API y tokens. No deben tratarse como texto de uso indefinido sin ciclo de vida.
Acceder a información para ejecutar un proyecto no convierte esa información en un activo de MSAdvance
El tratamiento debe responder a una finalidad concreta, al alcance contratado y a las instrucciones aplicables cuando MSAdvance actúa por cuenta del cliente.
Minimización
Procuramos evitar exportaciones y copias innecesarias cuando el trabajo puede completarse sobre la plataforma o mediante herramientas cloud apropiadas.
Finalidad
El acceso debe relacionarse con el servicio que estamos prestando y con la necesidad técnica que justifica ese acceso.
Responsable y encargado
Cuando actuamos como encargado del tratamiento, las obligaciones y operaciones aplicables se articulan contractualmente con el responsable.
Retención
Artefactos temporales, logs o exportaciones no deberían mantenerse indefinidamente sin una necesidad técnica, contractual o legal.
Transferencias internacionales
Cuando existen implicaciones de acceso o transferencia internacional, se analizan según la arquitectura, proveedores y requisitos aplicables.
Seguridad adecuada al riesgo
El RGPD exige medidas técnicas y organizativas apropiadas teniendo en cuenta naturaleza, contexto, finalidad y riesgo del tratamiento.
El contrato y el diseño técnico deben reflejar el mismo flujo de datos
El EDPB recuerda que la relación responsable-encargado debe estar gobernada por contrato y que el encargado debe tratar los datos conforme a las instrucciones del responsable, mantener confidencialidad y aplicar seguridad apropiada.
En proyectos complejos, la arquitectura de la herramienta, los permisos, los posibles subencargados y las geografías deben entenderse antes de autorizar el tratamiento.
Elegimos la herramienta según el proyecto, y sus permisos también forman parte de la decisión
Dependiendo del escenario utilizamos capacidades nativas de Microsoft y, cuando aportan valor, herramientas especializadas. No todas las plataformas necesitan el mismo acceso ni procesan los datos de la misma manera.
Una herramienta no se introduce automáticamente porque la utilicemos en otros proyectos
Si una plataforma requiere permisos, admin consent, acceso a datos o tratamiento por un tercero, debe entenderse dentro de la arquitectura y del proceso de aprobación del proyecto.
Cuando el cliente mantiene una lista de proveedores o herramientas autorizadas, podemos revisar alternativas técnicas dentro de esas restricciones.
Un cambio correcto técnicamente puede seguir siendo un cambio incorrecto si se ejecuta sin coordinación
Los permisos responden a quién puede ejecutar una acción. El Change Management responde a cuándo debe ejecutarse, quién la aprueba y cómo validamos que el resultado es correcto.
Definir
Qué cambia y por qué.
Evaluar
Impacto, dependencias y riesgo.
Aprobar
Responsables y ventana.
Ejecutar
Cambio controlado.
Validar
Criterios de aceptación.
Documentar
Resultado y evidencias.
Rollback cuando es viable
Antes de cambios sensibles analizamos qué puede revertirse, qué no puede revertirse y qué plan alternativo existe si el resultado no es el esperado.
Backup no es migración
Una herramienta de migración no debe asumirse como sistema de backup. Si el proyecto necesita protección adicional, debe definirse expresamente.
Hypercare
Después de cutovers o cambios significativos, una fase de estabilización ayuda a resolver rápidamente incidencias que solo aparecen en producción.
Podemos integrarnos con el proceso de cambio del cliente
ServiceNow, Jira, Azure DevOps, RFC, CAB, ventanas de mantenimiento y aprobaciones internas pueden formar parte de la ejecución cuando así lo requiere la organización.
Un acceso de confianza debe dejar suficiente información para reconstruir qué ocurrió
Microsoft 365, Microsoft Entra y Azure proporcionan distintas fuentes de auditoría. Las utilizamos junto con la documentación operativa del proyecto.
Entra Audit Logs
Permiten revisar actividad sobre usuarios, grupos, aplicaciones, roles y otros objetos del directorio.
Sign-in Logs
Aportan información sobre autenticaciones de usuarios y aplicaciones.
Microsoft Purview Audit
Permite buscar actividades de usuarios y administradores registradas en múltiples servicios Microsoft.
Azure Activity Log
Proporciona visibilidad de eventos a nivel de suscripción en Azure.
Tickets y change records
Las acciones de proyecto pueden acompañarse de tickets, runbooks y evidencias de validación.
SIEM del cliente
Cuando el cliente utiliza Sentinel u otra plataforma, los registros disponibles pueden formar parte de su estrategia de supervisión.
La evidencia necesaria depende del riesgo del cambio
Un ajuste menor no necesita necesariamente el mismo nivel de documentación que un cutover de dominio, una modificación de Conditional Access o una intervención sobre privilegios.
Podemos acordar evidencias, informes y registros con el nivel de detalle adecuado al proyecto.
Si algo no se comporta como esperamos, la prioridad es limitar impacto, entenderlo y comunicarlo
Cada organización puede tener su propio proceso de respuesta. Cuando existe, nuestra actuación debe integrarse con él.
Detectar
Identificar comportamiento anómalo.
Contener
Limitar impacto cuando es necesario.
Comunicar
Escalar a los contactos acordados.
Analizar
Revisar logs, cambios y alcance.
Recuperar
Restaurar operación o estabilizar.
Revisar
Documentar causa y acciones.
Tiempos de notificación, canales, responsables, severidades, SLAs y obligaciones concretas se definen según el servicio y la documentación contractual aplicable.
Un proyecto temporal y una relación operativa continua necesitan controles diferentes
Cuando MSAdvance presta administración recurrente, el acceso deja de ser una excepción de proyecto y pasa a formar parte de un modelo operativo que debe gobernarse.
Delegación granular
Para Microsoft 365, GDAP puede proporcionar una relación más granular y limitada que modelos amplios de administración delegada.
Azure Lighthouse
En Azure, Lighthouse puede centralizar administración delegada manteniendo control de roles y ámbitos.
Revisiones periódicas
Los roles recurrentes deben seguir teniendo una justificación conforme cambia el servicio.
Responsabilidades claras
Incidencias, cambios, licencias, seguridad y aprobaciones deben tener responsables definidos.
Change Management
La operación recurrente debe respetar el modelo de aprobación acordado con el cliente.
Offboarding
Al finalizar el servicio, delegaciones, cuentas y permisos deben revisarse formalmente.
Su organización no debería rebajar sus controles para poder trabajar con nosotros
Durante el onboarding podemos revisar controles técnicos y operativos definidos por IT, Security, Legal, Compliance, Data Protection o Procurement.
El proyecto no termina cuando el cambio funciona; termina cuando el acceso deja de sobrar
Una parte importante del cierre es identificar qué elementos se crearon para el proyecto y cuáles deben mantenerse, reducirse o retirarse.
Cuentas
Revisamos identidades creadas específicamente para ejecutar el trabajo.
Roles
Los privilegios temporales o ampliados dejan de ser necesarios al cerrar el alcance.
Enterprise Applications
Aplicaciones introducidas exclusivamente para el proyecto se incluyen en la revisión.
Consentimientos
Los permisos de aplicación deben mantener una finalidad real tras el proyecto.
Artefactos temporales
Exportaciones, archivos de trabajo y logs se revisan según su utilidad y retención.
Documentación
Consolidamos información relevante para la continuidad operativa del cliente.
Los servicios gestionados son una excepción consciente, no un acceso olvidado
Si el servicio contratado requiere acceso recurrente, los permisos no se eliminan al finalizar una intervención concreta porque forman parte de una relación operativa vigente.
En ese caso, el acceso debe gobernarse como parte del managed service y retirarse formalmente en el offboarding.
Microsoft protege la plataforma; el cliente conserva responsabilidades sobre datos, identidades y configuración
El modelo cambia entre SaaS, PaaS e IaaS, pero Microsoft señala que el cliente conserva siempre responsabilidad sobre sus datos e identidades.
| Área | Microsoft | Cliente | MSAdvance |
|---|---|---|---|
| Infraestructura física | Protege y opera los datacenters y componentes físicos del servicio cloud. | Selecciona los servicios cloud que utiliza. | Diseña y configura sobre la plataforma dentro del alcance contratado. |
| Datos | Proporciona capacidades de plataforma, disponibilidad y seguridad según servicio. | Conserva gobierno, clasificación, protección y obligaciones sobre los datos. | Accede o procesa únicamente según el servicio y autorizaciones aplicables. |
| Identidades | Proporciona Microsoft Entra y mecanismos de identidad. | Es propietario de usuarios, cuentas y decisiones de acceso. | Utiliza o configura permisos dentro del alcance autorizado. |
| Configuración | Ofrece funcionalidades y controles. | Decide requisitos, políticas y riesgo aceptable. | Recomienda o implementa configuración contratada. |
| Acceso de MSAdvance | Proporciona RBAC, PIM, logs y otros mecanismos de control. | Autoriza, gobierna y puede retirar los accesos concedidos. | Utiliza el acceso para la finalidad acordada. |
Podemos ayudar a su equipo de seguridad a entender exactamente cómo se prestará el servicio
En organizaciones medianas y grandes, el proyecto puede necesitar pasar por una evaluación previa de proveedor. Preferimos resolver esas preguntas antes de comenzar y no durante un cutover.
NDA y confidencialidad
Revisión de requisitos de confidencialidad antes de recibir información sensible.
Statement of Work
Sistemas, responsabilidades, entregables y exclusiones definidos.
DPA y flujo de datos
Cuando aplica, puede documentarse tratamiento, finalidad, herramientas y partes implicadas.
Matriz de permisos
Roles, scopes, aplicaciones y elevaciones requeridas según fase y workload.
Herramientas utilizadas
Identificación de plataformas nativas o de terceros necesarias para el proyecto.
Runbook y ventanas
Operaciones críticas, orden, validación y responsabilidades.
Riesgos y mitigaciones
Dependencias, escenarios sensibles y medidas para reducir impacto.
Evidencias
Logs, tickets, resultados de validación e información de cierre.
Plan de retirada
Qué accesos, aplicaciones o artefactos deben revisarse al finalizar.
¿Su organización utiliza un Security Questionnaire propio?
Podemos revisar las preguntas relevantes para el servicio y aportar la información técnica necesaria sobre el modelo de acceso, herramientas, flujos, responsabilidades y operación.
Cuando una pregunta exige una certificación, póliza, garantía contractual o evidencia corporativa concreta, la respuesta debe basarse en documentación verificable y no en afirmaciones genéricas.
Preferimos explicar los límites antes que ganar confianza con afirmaciones absolutas
Un Trust Center debe ayudar a tomar una decisión informada, no esconder las diferencias entre servicios.
No todos los proyectos necesitan Global Admin
Algunos sí pueden necesitarlo temporalmente. Otros se resuelven con roles específicos o lectura.
Migración no equivale a backup
Copiar datos a un nuevo sistema no sustituye automáticamente una estrategia de backup y recuperación.
Remoto no equivale a acceso internacional de datos
La arquitectura, herramientas y localización efectiva deben analizarse antes de concluir qué tratamiento existe.
Una herramienta no es adecuada para todos los proyectos
Seleccionamos tecnología según origen, destino, workloads, volumen y controles del cliente.
Un log no sustituye una aprobación
Auditoría permite conocer qué ocurrió. Change Management determina si debía ocurrir.
El Trust Center no sustituye el contrato
El alcance, SLA, obligaciones y garantías concretas dependen de la documentación aplicable a cada servicio.
Principios alineados con las capacidades y recomendaciones del ecosistema Microsoft
Estas fuentes permiten al cliente verificar directamente conceptos como mínimo privilegio, PIM, GDAP, Azure Lighthouse, Microsoft Graph, auditoría y responsabilidad compartida.
Enlaces externos incluidos como referencia técnica. Los requisitos, características y licenciamiento de los productos Microsoft pueden cambiar con el tiempo y deben validarse para cada proyecto.
Conozca quiénes somos, qué credenciales tenemos y qué proyectos hemos ejecutado
Seguridad, privacidad y accesos al trabajar con MSAdvance
Respuestas directas a preguntas habituales de IT, CISO, Legal, Compliance y Procurement.
¿MSAdvance firma acuerdos de confidencialidad o NDA?
Sí. Podemos firmar NDA cuando el cliente o proyecto lo requieren, incluso antes de compartir información técnica sensible sobre usuarios, arquitectura, dominios, seguridad, adquisiciones, infraestructura o datos.
¿MSAdvance presta servicio de forma remota y global?
Sí. MSAdvance presta un servicio remoto global a organizaciones de distintas geografías. El acceso puede adaptarse a controles del cliente como MFA, VPN, VDI, bastiones, rangos IP, restricciones territoriales y ventanas de mantenimiento.
¿Es seguro dar acceso administrativo a MSAdvance?
El nivel de riesgo depende de los permisos y controles concretos. Nuestro enfoque es definir el acceso según la tarea, priorizar mínimo privilegio, autenticación fuerte, trazabilidad y retirada de permisos cuando dejan de ser necesarios.
¿Necesita MSAdvance Global Administrator para Microsoft 365?
No como regla general. Algunos escenarios pueden requerir Global Administrator para operaciones concretas, pero muchos trabajos pueden realizarse con acceso de lectura, roles específicos por workload o privilegios temporales.
¿Podemos conceder acceso mediante Microsoft Entra PIM?
Sí, cuando el licenciamiento y configuración del tenant lo permiten. PIM permite que un rol sea elegible y se active durante un periodo limitado, pudiendo incorporar MFA, aprobación, justificación y notificaciones.
¿Utilizáis MFA para cuentas administrativas?
Favorecemos MFA para identidades administrativas. Cuando trabajamos dentro de un modelo definido por el cliente, nos adaptamos a sus políticas de MFA, Conditional Access y autenticación.
¿Puede utilizarse GDAP con MSAdvance?
Sí, cuando resulta aplicable a la relación y al servicio. Microsoft define GDAP como un modelo para conceder a partners acceso granular, de mínimo privilegio y limitado en el tiempo.
¿Puede MSAdvance administrar Azure mediante Azure Lighthouse?
Sí, Azure Lighthouse puede utilizarse para delegar administración de suscripciones o grupos de recursos mediante roles y ámbitos definidos. La idoneidad depende del modelo de servicio y del alcance.
¿MSAdvance utiliza las cuentas break-glass del cliente?
No forman parte del acceso operativo habitual. Las cuentas de emergencia están diseñadas para situaciones excepcionales en las que las identidades administrativas normales no pueden utilizarse y deberían permanecer bajo control del cliente.
¿Necesitáis las contraseñas de los usuarios?
No como método normal de trabajo. Los proyectos modernos utilizan OAuth, roles, aplicaciones, APIs y mecanismos de autorización. Si una plataforma heredada requiere credenciales técnicas, se acuerda con el cliente cómo entregarlas, utilizarlas y retirarlas.
¿Qué ocurre si una herramienta necesita Microsoft Graph?
Revisamos la finalidad y permisos requeridos, diferenciando entre permisos delegados y permisos de aplicación. Los permisos de aplicación pueden operar sin un usuario conectado, por lo que requieren especial cuidado.
¿Puede el cliente revisar las aplicaciones que utiliza MSAdvance?
Sí. Si una herramienta requiere enterprise application, service principal, admin consent o permisos sobre datos, esos elementos pueden formar parte de la revisión y aprobación técnica del proyecto.
¿Copiáis datos de Microsoft 365 a equipos de MSAdvance?
Nuestro enfoque es minimizar copias innecesarias. Siempre que una tarea pueda ejecutarse directamente sobre la plataforma del cliente o mediante herramientas cloud adecuadas, evitamos generar exportaciones adicionales. Si una exportación es necesaria, debe responder a una finalidad concreta.
¿Cómo aborda MSAdvance el RGPD?
Cuando un servicio implica tratamiento de datos personales por cuenta del cliente, las responsabilidades deben documentarse según el rol aplicable. Si MSAdvance actúa como encargado, el tratamiento se realiza dentro de las instrucciones, finalidad y condiciones acordadas con el responsable.
¿Puede MSAdvance trabajar solo desde determinadas geografías?
Si el cliente establece restricciones territoriales por seguridad, protección de datos o cumplimiento, podemos analizarlas durante el diseño del servicio y adaptar la prestación cuando resulte técnicamente viable.
¿Podemos exigir VPN, VDI o bastion host?
Sí, podemos trabajar dentro de controles corporativos específicos cuando sean compatibles con las tareas del proyecto. Es habitual integrar VPN, VDI, jump servers, bastiones o estaciones privilegiadas en entornos enterprise.
¿Cómo sabemos qué cambios ha realizado MSAdvance?
Microsoft Entra, Microsoft Purview y Azure proporcionan diferentes registros de actividad y auditoría. El proyecto también puede incorporar tickets, runbooks, change records y evidencias de validación.
¿Podemos exigir que cada cambio tenga un ticket?
Sí. Podemos adaptar la ejecución al Change Management del cliente, incluyendo ServiceNow, Jira, Azure DevOps, CAB, RFC, ventanas de mantenimiento y aprobaciones.
¿Preparáis rollback antes de cambios importantes?
En cambios sensibles analizamos qué puede revertirse, qué dependencias existen y qué alternativa hay si el resultado no es el esperado. No todos los cambios son técnicamente reversibles, por lo que debe revisarse caso por caso.
¿Una herramienta de migración sirve como backup?
No debe asumirse. Migración y backup responden a objetivos diferentes. Si un proyecto requiere una capa específica de protección o recuperación, debe definirse dentro del alcance.
¿Utilizáis herramientas de terceros en las migraciones?
Dependiendo del escenario podemos utilizar capacidades nativas Microsoft o herramientas especializadas como Quest, AvePoint, ShareGate o BitTitan. La selección depende de origen, destino, workloads, volumen y requisitos.
¿Podemos restringir las herramientas permitidas?
Sí. Si la organización mantiene un catálogo de herramientas o proveedores autorizados, debe indicarse durante el discovery para revisar alternativas compatibles.
¿Qué ocurre con los accesos cuando termina un proyecto?
El cierre incluye revisar cuentas, roles, enterprise applications, service principals, consentimientos y otros accesos creados específicamente para ejecutar el proyecto.
¿Y si MSAdvance presta un servicio gestionado permanente?
En un managed service, el acceso recurrente forma parte de la prestación vigente. En ese caso debe gobernarse durante la relación y retirarse formalmente durante el offboarding.
¿Podéis completar cuestionarios de seguridad de proveedores?
Podemos revisar y responder las cuestiones técnicas relacionadas con el servicio y aportar información sobre acceso, herramientas, arquitectura, permisos, operación y tratamiento cuando corresponde.
¿Trabajáis con requisitos de ISO 27001, ENS o políticas internas?
Podemos adaptar el proyecto a requisitos técnicos y operativos derivados de ISO 27001, ENS, RGPD u otros marcos y políticas del cliente. Trabajar bajo esos requisitos no implica afirmar una certificación corporativa no expresamente acreditada.
¿Quién controla finalmente el acceso al tenant?
El tenant pertenece al cliente y el cliente mantiene el gobierno de las identidades y autorizaciones. Los permisos concedidos a MSAdvance pueden revisarse, modificarse o retirarse conforme al modelo acordado.
Podemos diseñar el proyecto alrededor de sus requisitos de seguridad, privacidad y gobierno
Si su organización necesita NDA, Security Questionnaire, PIM, VPN, VDI, GDAP, Azure Lighthouse, restricciones geográficas, herramientas aprobadas, Change Management formal o un proceso específico de onboarding de proveedores, indíquenoslo desde el principio. El modelo de trabajo debe adaptarse al riesgo y a la realidad de su negocio.
