Compartir a través de

Información general sobre la protección de datos

Azure DevOps Services

Azure DevOps Services es una aplicación hospedada en la nube para los proyectos de desarrollo, desde la planeación hasta la implementación. En función de las prestaciones locales, con más servicios en la nube, administramos el código fuente, los elementos de trabajo, las compilaciones y las pruebas. Azure DevOps usa la infraestructura de plataforma como servicio (PaaS) y muchos servicios de Azure, incluidos Azure SQL, para ofrecer un servicio confiable y disponible globalmente para los proyectos de desarrollo.

En este artículo se describen los pasos que Microsoft realiza para ayudar a mantener los proyectos seguros, disponibles, seguros y privados. Describe el rol que desempeña el cliente para mantener los proyectos seguros y protegidos.

Este artículo está destinado a los administradores de organizaciones y a los profesionales de TI que administran sus recursos de proyecto a diario. Resulta más útil a los usuarios que ya conocen Azure DevOps y desean obtener más información sobre cómo Microsoft protege los recursos almacenados en Azure DevOps.

Nuestro Compromiso

Microsoft ayuda a garantizar que los proyectos permanezcan seguros y seguros, sin excepción. Cuando se almacenan proyectos en Azure DevOps, estos se benefician de varias capas de tecnologías de seguridad y gobernanza, prácticas operativas y directivas de cumplimiento. Aplicamos la privacidad y la integridad de los datos tanto en reposo como en tránsito.

Las amenazas a las que se enfrenta pertenecen a cuatro categorías básicas: disponibilidad de datos, disponibilidad del servicio, seguridad del servicio y privacidad de los datos. En este artículo se exploran amenazas específicas pertenecientes a cada categoría y se explica qué hace Azure DevOps para abordarlas. El artículo comienza con una descripción de cómo se almacenan los datos y de cómo administra Azure DevOps el acceso a ellos.

Para proteger los datos, se requiere la participación activa de administradores y usuarios que sepan qué pasos se deben seguir para proteger los recursos frente a la divulgación y la manipulación no autorizadas. Cuando conceda permisos a los puntos de acceso de usuarios, hágalo de manera explícita, de tal forma que únicamente las personas adecuadas puedan obtener acceso a los datos contenidos en Azure DevOps.

Debe considerar que todos los datos pueden estar en riesgo, independientemente de dónde se encuentren o cómo se usen. Esto se aplica a los datos almacenados tanto en la nube como en centros de datos privados. Es importante clasificar los datos, su nivel de confidencialidad y de riesgo, y el daño que podría derivarse en caso de que se viesen comprometidos. Además, hay que clasificar los datos de conformidad con una directiva general de administración de la seguridad de la información.

Basado en Azure

Diagrama de la arquitectura general de Azure DevOps.

Hospedamos Azure DevOps íntegramente en centros de datos de Azure. Azure DevOps usa muchos servicios principales de Azure, como proceso, almacenamiento, redes, Azure SQL, administración de identidades y acceso, y Azure Service Bus.

Azure DevOps usa Azure Storage como repositorio principal para los metadatos del servicio y los datos del cliente. Según el tipo de datos y los requisitos de almacenamiento y recuperación, Azure DevOps usa Azure Blob Storage y Azure SQL Database Storage.

Para ayudarle a comprender el enfoque de Azure DevOps Services respecto a la protección de datos, aquí presentamos información de referencia sobre los servicios de almacenamiento:

  • Azure Blob Storage almacena grandes fragmentos de datos no estructurados. Todos los proyectos usan este servicio. Los datos incluyen información potencialmente confidencial o privada, como el contenido de archivos de origen y datos adjuntos para elementos de trabajo. Para casi todos los proyectos, la mayoría del almacenamiento en uso es este tipo de almacenamiento de blobs no estructurado.

  • Azure SQL Database almacena los aspectos estructurados y transaccionales de su organización, incluidos los metadatos de los proyectos, el historial de control de código fuente con versiones y los detalles de los elementos de trabajo. El almacenamiento de bases de datos proporciona acceso rápido a los elementos importantes del proyecto. Proporciona índices en Blob Storage para buscar archivos y datos adjuntos.

Los administradores pueden administrar el acceso a los recursos concediéndole o restringiendo permisos en las identidades o grupos de usuarios. Azure DevOps usa la autenticación federada de identidades de usuario a través de Microsoft Entra ID y de las cuentas de Microsoft.

Durante la autenticación, el usuario se enruta al proveedor de autenticación, donde proporciona sus credenciales. Una vez que el proveedor de autenticación comprueba las credenciales del usuario, Azure DevOps envía a este último una cookie de autenticación. Esta cookie permite al usuario permanecer autenticado en Azure DevOps.

De esta manera, la información de credenciales del usuario nunca se comparte directamente con Azure DevOps. Para cada recurso de Azure DevOps al que el usuario intenta obtener acceso, la validación se basa en los permisos explícitos del usuario y en los permisos que este heredó a través de la pertenencia a grupos.

Los administradores pueden usar controles de acceso para ayudar a proteger el acceso a la organización, las colecciones de proyectos y los proyectos de equipo, así como los datos y la funcionalidad de ámbito de equipo. Los administradores también pueden usar controles de acceso para recursos específicos, como carpetas para el control de versiones y rutas de área para los elementos de trabajo.

Disponibilidad de datos

Azure DevOps usa numerosas características de Azure Storage para ayudar a garantizar la disponibilidad de los datos en caso de producirse un error de hardware, una interrupción del servicio o un desastre regional. Además, el equipo de Azure DevOps sigue los procedimientos destinados a ayudar a proteger los datos contra la eliminación accidental o malintencionada.

Redundancia de datos

Con el fin de ayudar a proteger los datos en caso de errores de hardware o de servicio, Azure Storage replica geográficamente los datos del cliente entre dos regiones de la misma ubicación geográfica. Por ejemplo, Azure Storage puede replicar geográficamente los datos entre el norte y el oeste de Europa o entre norte y el sur de los Estados Unidos.

En el caso de Azure Blob Storage, los datos del cliente se replican tres veces dentro de una sola región. Los datos del cliente se replican de forma asincrónica en una segunda región de la misma ubicación geográfica. Por lo tanto, Azure siempre mantiene el equivalente de seis copias de los datos.

Contar con varias copias le permite conmutar por error a una región independiente si se produce una interrupción o un desastre de gran calado, además de ofrecer redundancia local para errores de hardware dentro de una región. Para Azure SQL almacenamiento de base de datos, las copias de seguridad diarias se mantienen fuera del sitio si se produce un desastre regional.

Con respecto a la redundancia de datos y la conmutación por error:

  • Hay una diferencia inherente, medida en minutos, cuando Microsoft replica los datos entre la región primaria y la secundaria.
  • La conmutación por error a la región secundaria es una decisión que Microsoft debe tomar de forma centralizada, ya que afecta a todos los clientes de una unidad de escalado determinada. Excepto en circunstancias extremas, Microsoft prefiere evitar realizar una conmutación por error para que no se pierdan los datos del cliente.
  • Azure DevOps ofrece un acuerdo de nivel de servicio (SLA) del tiempo de actividad del 99,9 %. Azure DevOps devuelve una parte de los cargos mensuales si el SLA se incumple en un mes determinado.
  • Dado que solo hay una región en Brasil, los datos de los clientes de esta nación se pueden replicar en la región Centro-sur de EE. UU. con fines de recuperación ante desastres.

Se producen errores

Para proteger contra la pérdida accidental de datos, Microsoft utiliza las copias de seguridad de un momento dado para los blobs almacenados en Azure Blob Storage y las bases de datos contenidas en Azure SQL Database. En cada cuenta de almacenamiento, se mantiene una copia independiente de todos los blobs, cuyos cambios se anexan a los datos existentes. Estas copias de seguridad son inmutables, lo que elimina la necesidad de reescribir los almacenamientos existentes durante los procedimientos de copia de seguridad.

Azure SQL Database incluye características de copia de seguridad estándar que se utilizan en Azure DevOps. Los datos se conservan durante 28 días y estas copias de seguridad también se replican en una región emparejada para facilitar la recuperación en caso de interrupción regional.

Puede recuperar organizaciones o proyectos eliminados dentro del período de 28 días posterior a la eliminación. Sin embargo, una vez transcurrido este período, estas entidades se eliminan de forma permanente y ya no se pueden restaurar. Aunque las copias de seguridad sirven como componente fundamental en la recuperación ante desastres, es esencial que los clientes apliquen las estrategias adecuadas de copia de seguridad y administración de datos para garantizar una protección íntegra de sus datos.

Importante

  • Por eliminación accidental se entienden los escenarios derivados de un incidente en nuestros servicios. No incluye la eliminación accidental de recursos por parte de los clientes (por ejemplo, repositorios, elementos de trabajo, datos adjuntos o artefactos).
  • No admitimos la restauración de recursos que los clientes hayan eliminado accidentalmente. Estas copias de seguridad están pensadas únicamente para ofrecer continuidad empresarial y para facilitar la recuperación en escenarios de interrupción o de desastre.
  • En raras ocasiones, el proceso de eliminación puede tardar hasta 70 días debido a reintentos de back-end y la necesidad de eliminar datos de varios orígenes.

La práctica es crítica

Contar con varias copias de seguridad de los datos es positivo, pero si no se tiene práctica, la restauración puede resultar impredecible. Se suele decir que "lo que falla no son las copias de seguridad, sino las restauraciones". Aunque la afirmación es técnicamente incorrecta, la opinión sí es acertada.

En Microsoft, practicamos con regularidad la restauración de conjuntos de datos a partir de copias de seguridad. Sometemos a pruebas periódicas el almacenamiento con redundancia geográfica de Azure. Hay muchas combinaciones de escenarios de desastres y de daños en los datos. Continuamos planeando y llevando a cabo nuevas pruebas para estos escenarios con frecuencia.

Disponibilidad del servicio

Azure DevOps ofrece protecciones de denegación de servicio distribuidas (DDoS) y respuesta al sitio activo para ayudar a garantizar que tiene acceso a la organización y a los recursos asociados.

Protecciones de DDoS

En algunos casos, un ataque DDoS malintencionado puede afectar a la disponibilidad del servicio. Azure tiene un sistema de defensa DDoS que ayuda a evitar ataques contra nuestro servicio. Usa técnicas de detección y mitigación estándar, como cookies SYN, limitación de velocidad y límites de conexión. El sistema está diseñado para resistir ataques no solo desde el exterior, sino también desde Dentro de Azure.

En el caso de los ataques específicos de aplicaciones que pueden penetrar en los sistemas de defensa de Azure, Azure DevOps establece cuotas de nivel de aplicación y de nivel de organización, así como limitaciones. Esta práctica ayuda a evitar el uso excesivo de los recursos de servicios esenciales durante un ataque o un uso incorrecto accidental de los recursos.

Respuesta del sitio activo

En raras circunstancias, es posible que necesite una respuesta del sitio activo a un problema con la disponibilidad del servicio. Nuestro equipo de operaciones está disponible en todo momento para identificar enseguida el problema e interactuar con el personal necesario del equipo de desarrollo.

A continuación, el equipo de desarrollo soluciona el problema. También trata de actualizar la página de estado del servicio en los minutos siguientes desde que se detecta un problema que afecta al servicio. Una vez que el equipo de desarrollo ha solucionado un problema, identifica la causa principal y realiza un seguimiento de los cambios necesarios para evitar que se reproduzcan otros similares en el futuro.

Los procesos de Azure DevOps de administración de sitios activos se centran en la experiencia del cliente y en el estado del servicio. Estos procesos minimizan el tiempo para detectar, responder y mitigar los problemas. Todas las disciplinas de ingeniería están implicadas y asumen su responsabilidad, por lo que la evolución de las mejoras continuas se basa en la experiencia directa. Así, se mejoran con el tiempo los procesos de supervisión, diagnóstico, resiliencia y control de calidad.

La administración de sitios activos en Azure DevOps tiene tres pistas distintas: telemetría, administración de incidentes y revisión del sitio activo. Esto es lo que conllevan estas pistas:

Imagen del proceso de Azure DevOps Services para la administración de sitios activos.

El equipo de operaciones también supervisa las métricas de disponibilidad de las organizaciones individuales. Estas métricas proporcionan información sobre condiciones específicas que podrían afectar solo a algunos de nuestros clientes. Las investigaciones sobre estos datos a menudo pueden dar lugar a mejoras dirigidas para solucionar problemas específicos del cliente. En algunos casos, Microsoft puede incluso ponerse en contacto con usted directamente para comprender su experiencia y trabajar con usted para mejorar el servicio.

Microsoft publica un SLA y proporciona una garantía financiera a fin de velar por que cumplamos este acuerdo cada mes. Para más información, consulte Acuerdo de Nivel de Servicio para Azure DevOps.

A veces, los equipos asociados o las dependencias tienen incidentes que afectan a Azure DevOps. Todos los equipos asociados siguen enfoques similares para identificar, resolver y aprender de estas interrupciones del servicio.

Seguridad del servicio

La seguridad del servicio requiere vigilancia constante, desde técnicas de diseño y codificación adecuadas a factores operativos. Microsoft invierte activamente en la prevención de agujeros de seguridad y en la detección de infracciones. Si se produce una infracción, Microsoft usa planes de respuesta de seguridad para minimizar la pérdida de datos, la pérdida o los daños. Para obtener más información, consulte Acerca de la seguridad, la autenticación y la autorización.

Seguridad por diseño

Azure DevOps está diseñado para ser seguro. Azure DevOps usa el ciclo de vida de desarrollo de seguridad de Microsoft en el núcleo de su proceso de desarrollo. El programa Microsoft Operational Security Assurance sirve para orientar los procedimientos de operación en la nube en Azure DevOps.

El equipo de Azure DevOps presenta requisitos de formación anual para todos los ingenieros y personal de operaciones. El equipo también patrocina reuniones informales moderadas por ingenieros de Microsoft. Una vez que el equipo ha resuelto un problema presentado durante una reunión, comparte las conclusiones extraídas con los demás equipos.

En las metodologías siguientes, se especifican los requisitos de formación:

  • Modelar las amenazas durante el diseño del servicio
  • Aplicar procedimientos recomendados para el diseño y la codificación
  • Comprobar la seguridad con herramientas y pruebas estándar
  • Limitar el acceso a los datos operativos y de los clientes
  • Controlar la implementación de nuevas funciones a través de un rígido proceso de aprobación

Un servicio en la nube solo es tan seguro como la plataforma host. Azure DevOps usa PaaS para gran parte de su infraestructura. PaaS proporciona automáticamente actualizaciones periódicas de vulnerabilidades de seguridad conocidas.

Las máquinas virtuales hospedadas en Azure usan la infraestructura como servicio (IaaS), por ejemplo, para un servicio de compilación hospedado. Estas imágenes reciben actualizaciones periódicas para incluir las revisiones de seguridad más recientes disponibles en Windows Update. El mismo rigor de actualización se aplica a las máquinas locales, incluidas aquellas que se usan con fines de implementación, supervisión y generación de informes.

El equipo de Azure DevOps realiza pruebas de penetración periódicas centradas en la seguridad de Azure DevOps. Las pruebas de penetración tratan de aprovechar los servicios de producción activos y la infraestructura de Azure DevOps aplicando las mismas técnicas y mecanismos que usan los atacantes malintencionados. El objetivo es identificar vulnerabilidades del mundo real, configuraciones, errores u otras brechas de seguridad en un proceso controlado.

El equipo revisa los resultados de estas pruebas para identificar otras áreas de mejora y aumentar la calidad de los sistemas preventivos, así como la formación. Puede revisar los resultados de las pruebas de penetración recientes de Azure DevOps en el Portal de confianza del servicio de Microsoft.

Seguridad de credenciales

Microsoft se compromete a garantizar que todos sus proyectos permanezcan seguros y protegidos, sin excepción. En Azure DevOps, los proyectos se benefician de varias capas de tecnologías de seguridad y gobernanza, prácticas operativas y directivas de cumplimiento. Aplicamos la privacidad y la integridad de los datos tanto en reposo como en tránsito. Además, cumplimos los procedimientos siguientes con respecto a las credenciales o secretos que se almacenan en Azure DevOps. Para obtener más información sobre cómo elegir el mecanismo de autenticación adecuado, consulte nuestra guía sobre autenticación.

Importante

Azure DevOps no admite la autenticación de credenciales alternativas. Si sigue utilizando Credenciales alternativas, Le recomendamos encarecidamente que cambie a un método de autenticación más seguro.

Tokens de acceso personal (PAT)

  • Almacenamos un hash del PAT.
  • Los PAT sin procesar se generan en memoria del lado del servidor. Se generan 32 bytes aleatoriamente a través de RNGCryptoServiceProvider y se comparten con el autor de la llamada como una cadena codificada en base 32. Este valor NO se almacena.
  • El hash PAT se genera en memoria en el lado del servidor como un HMACSHA256Hash del PAT sin procesar mediante una clave de firma simétrica de 64 bytes almacenada en nuestra bóveda de claves.
  • El hash se almacena en nuestra base de datos.

Claves de Secure Shell (SSH)

  • Almacenamos un hash del identificador de la organización contenedora y la clave pública SSH.
  • El autor de la llamada proporciona las claves públicas sin procesar, directamente a través de SSL.
  • La hash SSH se genera en la memoria del lado del servidor como un HMACSHA256Hash del identificador de la organización y la clave pública en bruto, utilizando una clave de firma simétrica de 64 bytes almacenada en nuestro almacén de claves.
  • El hash se almacena en nuestra base de datos.

Credenciales de OAuth (JWT)

  • Las credenciales de OAuth emitidas son tokens web JSON (JWT) autodescriptivos que no se guardan en nuestro servicio.
  • Las notificaciones de JWT emitidas y presentadas a nuestro servicio se validan mediante un certificado almacenado en nuestro almacén de claves.

Informes de errores de seguridad

Si considera que las pruebas de penetración han revelado un posible fallo de seguridad relacionado con el servicio Azure DevOps, comuníqueselo a Microsoft en el plazo de 24 horas. Para obtener más información, consulte la página web de Microsoft para notificar vulnerabilidades de seguridad informática.

Importante

Aunque no es preciso notificar a Microsoft las actividades de pruebas de penetración, debe cumplir las reglas de realización de las pruebas de penetración de Microsoft.

Programa de recompensas

Azure DevOps participa en el Programa de recompensas de Microsoft por la detección de errores. Este programa recompensa a los investigadores de seguridad que nos comunican problemas y anima a que otras personas contribuyan a mantener la seguridad de Azure DevOps. Para obtener más información, consulte el programa de recompensas de Microsoft Azure DevOps.

Restricción del acceso

Microsoft mantiene un control estricto sobre quién obtiene acceso a nuestros datos de cliente y entorno de producción. Concedemos acceso en el nivel de mínimos privilegios requeridos y solo tras haber comprobado que están justificados para el usuario. Si un miembro del equipo necesita acceso para resolver un problema urgente o implementar un cambio de configuración, debe solicitar acceso cuando es necesario. El acceso se revoca en cuanto se resuelve la situación.

Las solicitudes y aprobaciones de acceso se someten a seguimiento y se supervisan en un sistema independiente. Todo el acceso al sistema está correlacionado con estas aprobaciones. Si detectamos un acceso no aprobado, alertamos al equipo de operaciones para que lo investigue.

Usamos la autenticación en dos fases para todo el acceso remoto al sistema. Si se roba el nombre de usuario y la contraseña de uno de nuestros desarrolladores o miembro del personal de operaciones, los datos permanecen protegidos. Es preciso efectuar más comprobaciones de autenticación mediante una tarjeta inteligente o una llamada telefónica a un número previamente aprobado antes de que permitamos el acceso remoto al servicio.

Para administrar y mantener el servicio, Microsoft usa secretos como contraseñas RDP, certificados SSL y claves de cifrado. Estos secretos se administran, almacenan y transmiten de forma segura a través de Azure Portal. Para tener acceso a cualquiera de estos secretos, se requiere un permiso específico que se graba y registra de forma segura. Todos los secretos se rotan con una cadencia regular y podemos rotarlos a petición si hay un evento de seguridad.

El equipo de operaciones de Azure DevOps usa estaciones de trabajo de administrador protegidas para administrar el servicio. Estas máquinas ejecutan un número mínimo de aplicaciones y funcionan en un entorno segmentado lógicamente.

Los miembros del equipo de operaciones deben proporcionar credenciales específicas con autenticación en dos fases para acceder a las estaciones de trabajo. Todo el acceso se supervisa y se registra de forma segura. Para aislar el servicio contra manipulaciones externas, no permitimos aplicaciones como Outlook y Office, ya que a menudo son blanco de ataques, como los de phishing de objetivo definido, entre otros.

Protección y respuesta de intrusiones

Ciframos los datos mediante HTTPS y SSL para contribuir a garantizar que no se intercepten ni modifiquen mientras están en tránsito entre usted y Azure DevOps. Los datos que almacenamos en su nombre en Azure DevOps se cifran de la siguiente manera:

  • Los datos almacenados en bases de datos de Azure SQL se cifran mediante el cifrado de datos transparente. Esta característica ayuda a proteger contra actividades maliciosas mediante el cifrado en tiempo real de la base de datos, las copias de seguridad asociadas y los archivos de registro de transacciones en reposo.

  • Las conexiones de Azure Blob Storage se cifran para ayudar a proteger los datos en tránsito. Para los datos en reposo almacenados en Azure Blob Storage, Azure DevOps usa el cifrado en el lado del servicio.

El equipo de Azure DevOps usa la infraestructura de Azure para registrar y supervisar los aspectos esenciales del servicio. El registro y la supervisión ayudan a garantizar que las actividades que se realizan en el seno del servicio sean legítimas y a detectar infracciones o intentos de infracciones.

Todas las actividades de implementación y administración se registran de forma segura, al igual que los accesos de los operadores al almacenamiento de producción. La información de registro se analiza automáticamente y se generan alertas en tiempo real en caso de cualquier comportamiento potencialmente malintencionado o no autorizado.

Cuando el equipo de Azure DevOps identifica una posible vulnerabilidad de seguridad de alta prioridad o intrusiones, cuenta con un plan de respuesta claro. En este plan, se describe quiénes son los responsables, qué pasos deben darse para proteger los datos de los clientes y cuáles son las instrucciones sobre cómo interactuar con los expertos en seguridad de Microsoft. El equipo también notifica a los propietarios de la organización si los datos se han divulgado o dañado, para que puedan tomar los pasos adecuados para solucionar la situación.

Para ayudar a combatir las amenazas emergentes, Azure DevOps emplea una estrategia de suposición de infracciones. Un equipo altamente especializado de expertos en seguridad de Microsoft asume el rol de adversarios sofisticados. Este equipo prueba la detección y respuesta de infracciones para medir con precisión la preparación y los impactos de los ataques reales. Esta estrategia refuerza la detección de amenazas, la respuesta y la defensa del servicio. También permite al equipo validar y mejorar la eficacia de todo el programa de seguridad.

Protección contra ataques por ransomware

Azure DevOps usa controles de Azure para ayudar a prevenir ataques por ransomware, detectarlos y responder ante ellos. Para obtener más información sobre cómo ayuda Azure a proteger a los clientes frente a ataques por ransomware, consulte Protección contra ransomware en Azure.

Privacidad de datos

Debe confiar en que controlamos sus datos de la forma adecuada y para usos legítimos. Una parte de esa garantía consiste en restringir cuidadosamente su uso.

Reglamento general de protección de datos

El Reglamento general de protección de datos (RGPD) es el mayor cambio en las leyes de protección de datos en Europa desde la introducción de la Directiva de protección de datos de la Unión Europea (UE) 95/46/CE. Para obtener más información sobre el RGPD, consulte la página de información general del Centro de confianza de Microsoft.

Soberanía y residencia de datos

Azure DevOps está disponible en las ocho ubicaciones geográficas siguientes en todo el mundo: Estados Unidos, Canadá, Europa, Reino Unido, India, Australia, Asia Pacífico y Brasil. De forma predeterminada, se asigna a cada organización la ubicación más próxima. Sin embargo, puede elegir otra ubicación al crear la organización. Si más adelante cambia de opinión, puede migrar la organización a otra ubicación con la ayuda del soporte técnico de Microsoft.

Azure DevOps no mueve ni replica los datos del cliente fuera de la ubicación elegida. En lugar de eso, los datos se replican geográficamente en una segunda región que pertenece a la misma ubicación. La única excepción es Brasil, cuyos datos se replican en la región Centro-sur de EE. UU. con fines de recuperación ante desastres.

Nota

En el caso de compilaciones y versiones que se ejecutan en agentes macOS proporcionados por Microsoft, los datos se transfieren a un centro de datos de GitHub en los Estados Unidos.

Para obtener más información, consulte Ubicaciones de datos para Azure DevOps.

Acceso al cumplimiento de la ley

En algunos casos, puede que terceros, por ejemplo, entidades encargadas de la aplicación de la ley, soliciten a Microsoft que les facilite acceso a datos de clientes almacenados en Azure DevOps. Intentamos redirigir las solicitudes al propietario de la organización para su resolución. Cuando una orden judicial obliga a Microsoft a revelar datos de clientes a terceros, Microsoft se esfuerza dentro de lo razonable para notificárselo al propietario de la organización por adelantado, a menos que la ley prohíba hacerlo.

Algunos clientes requieren que su almacenamiento de datos se encuentre en una ubicación geográfica determinada para pertenecer a una jurisdicción legal concreta en términos de actividades de aplicación de la ley. Todos los datos de clientes, como el código fuente, los elementos de trabajo, los resultados de las pruebas, así como los reflejos con redundancia geográfica y las copias de seguridad fuera del sitio, se conservan dentro de una de las ubicaciones mencionadas anteriormente.

Microsoft Access

En ocasiones, los empleados de Microsoft necesitan obtener acceso a los datos de clientes almacenados en Azure DevOps. Como medida de precaución, todos los empleados que tienen (o pueden tener) acceso a datos de clientes deben superar una verificación de antecedentes tanto profesionales como penales. Permitimos el acceso a los sistemas de producción únicamente cuando se produce un incidente en un sitio activo u otra actividad de mantenimiento aprobada, que se registra y supervisa.

Dado que no todos los datos de nuestro sistema se tratan de la misma manera, los clasificamos en estos tipos:

  • Datos del cliente: los que carga en Azure DevOps.
  • Datos de la organización: información que envía cuando se registra o administra su organización.
  • Datos de Microsoft: información necesaria para el funcionamiento del servicio o recopilada a través de este.

En función de la clasificación, controlamos escenarios de uso, requisitos de ubicación geográfica, restricciones de acceso y requisitos de retención.

Uso promocional de Microsoft

En ocasiones, Microsoft desea ponerse en contacto con los clientes para informarles sobre más características y servicios que podrían resultarles útiles. Dado que no todos los clientes quieren ponerse en contacto con estas ofertas, puede optar por no recibir comunicaciones por correo electrónico de marketing.

Microsoft nunca usa datos de cliente para dirigirse a ofertas específicas para usuarios o organizaciones específicos. En su lugar, usamos datos de la organización y agregamos estadísticas de uso en el nivel de organización para determinar los grupos que deben recibir ofertas específicas.

Administración de directivas de privacidad para que los administradores controle la recopilación de comentarios de los usuarios

La función de conmutador de comentarios permite a los propietarios de la organización de Azure DevOps controlar si se pide a los usuarios que proporcionen comentarios y los envíen. Esta característica es esencial para garantizar que las prácticas de comentarios se alineen con las directivas de privacidad y gobernanza de su organización.

Creación de confianza

Puede confiar en los demás esfuerzos que Microsoft realiza en nombre de Azure DevOps. Estos esfuerzos incluyen directivas de adopción internas de Microsoft, el nivel de transparencia del estado de nuestro servicio y los avances para recibir la certificación de nuestros sistemas destinados a administrar la seguridad de la información.

Adopción interna

Los equipos de Microsoft están adoptando internamente Azure DevOps. El equipo de Azure DevOps se trasladó a una organización en 2014 y lo usa ampliamente. Hemos establecido directrices a fin de habilitar los planes de adopción para otros equipos.

Los equipos grandes avanzan de manera más gradual que los pequeños, a causa de sus inversiones en sistemas de DevOps existentes. Para los equipos que avanzan con rapidez, hemos establecido un enfoque de clasificación de proyectos. Evalúa la tolerancia a riesgos, en función de las características del proyecto, para determinar si el proyecto es adecuado para Azure DevOps. En el caso de los equipos más grandes, la adopción suele producirse en fases, con más planeamiento.

Entre los requisitos adicionales que se requieren en los proyectos internos, se incluye la asociación de la organización con Microsoft Entra ID para garantizar el ciclo de vida de la identidad de los usuarios y la complejidad adecuada de las contraseñas. Los proyectos con mayor nivel de confidencialidad requieren además la autenticación en dos fases.

Certificaciones de cumplimiento

Es posible que le interese comprender cómo terceros realizan la evaluación de nuestros procedimientos para la seguridad de los datos. Azure DevOps ha obtenido las certificaciones siguientes:

  • ISO 27001:2022
  • ISO 27018:2019
  • ISO 26262:2023
  • Ley de transferencia y responsabilidad de seguros de salud (HIPAA)
  • Contrato de socio comercial (BAA)
  • Cláusulas modelo de la UE
  • Controles de sistema y organización (SOC) 1, tipo 2
  • SOC 2 tipo 2
  • C5 de Alemania
  • IRAP en Australia
  • ENS de España

La auditoría de SOC para Azure DevOps abarca los controles de seguridad de datos, disponibilidad, integridad de procesamiento y confidencialidad. Los informes de SOC para Azure DevOps están disponibles a través del Portal de confianza de servicios de Microsoft.

El cuestionario Consensus Assessment Initiative Questionnaire (CAIQ) ayuda a las organizaciones a determinar y evaluar las prácticas y las prestaciones de seguridad de los proveedores de servicios en la nube. En consonancia con nuestro compromiso con la seguridad y la transparencia, recientemente hemos llevado a cabo la evaluación del CAIQ para Azure DevOps. Le invitamos a consultar el informe completo en el Portal de confianza de servicios de Microsoft.

Pasos que puede realizar

Para proteger correctamente los datos, es preciso que se impliquen tanto usted como sus administradores y usuarios. Sus datos de proyectos almacenados en Azure DevOps estarán protegidos en tanto en cuanto los puntos de acceso de usuario sean seguros. Coincida con el nivel de estrictoidad y granularidad de los permisos para esas organizaciones con el nivel de confidencialidad del proyecto.

Clasificación de los datos

El primer paso es clasificar los datos. Clasifique los datos en función de su confidencialidad y del horizonte de riesgo, así como de los perjuicios que sufriría en caso de que se viesen comprometidos. Muchas empresas ya poseen métodos de clasificación que reutilizan cuando migran los proyectos a Azure DevOps. Para obtener más información, puede descargar el documento sobre clasificación de datos a fin de prepararlos para la nube en Microsoft Trustworthy Computing.

Adopción de Microsoft Entra ID

Use Microsoft Entra ID para administrar el acceso de su organización a Azure DevOps. Microsoft Entra ID proporciona otra manera de mejorar la seguridad de las credenciales de los usuarios.

Microsoft Entra ID permite al departamento de TI administrar la directiva de acceso de los usuarios, la complejidad de las contraseñas, las actualizaciones de las contraseñas y la expiración cuando los usuarios abandonan la organización. A través de la federación de Active Directory, puede vincular directamente Microsoft Entra ID al directorio central de la organización, de modo que haya una sola ubicación en la que administrar estos datos para su empresa.

En la tabla siguiente, se comparan las características de Microsoft Entra y de las cuentas de Microsoft en términos de acceso a Azure DevOps:

Propiedad Cuenta Microsoft Microsoft Entra ID
Creador de identidades Usuario Organización
Nombre de usuario y contraseña únicos para todos los activos de trabajo No Sí
Control de la vigencia y de la complejidad de las contraseñas Usuario Organización
Límites de pertenencia a Azure DevOps Cualquier cuenta de Microsoft Directorio de la organización
Identidad rastreable No Sí
Quién posee la organización y la propiedad intelectual Confuso Organización
Inscripción de autenticación en dos fases Usuario Organización
Acceso condicional basado en dispositivos No Organización

Obtenga más información sobre cómo configurar esta compatibilidad con su organización.

Requerir la autenticación en dos fases.

Es posible que quiera restringir el acceso a su organización al requerir más de un factor para iniciar sesión. Puede exigir varios factores mediante Microsoft Entra ID. Por ejemplo, puede requerir autenticación telefónica, además de un nombre de usuario y una contraseña, para todas las solicitudes de autenticación.

Usar BitLocker

En el caso de proyectos confidenciales, puede usar BitLocker en su equipo portátil o de escritorio Windows. BitLocker cifra toda la unidad en la que residen Windows y los datos. Cuando BitLocker está habilitado, cifra automáticamente cualquier archivo que guarde en esa unidad. Si el equipo cae en las manos equivocadas, BitLocker impide el acceso no autorizado a copias locales de datos de los proyectos.

Limitar el uso de credenciales de autenticación alternativas

El mecanismo de autenticación predeterminado de las herramientas relacionadas con Git es la autenticación alternativa (a veces denominada autenticación básica). Este mecanismo permite que el usuario configure un nombre de usuario y una contraseña alternativos para usarlos durante las operaciones de línea de comandos con Git. El usuario puede utilizar esta combinación de nombre de usuario y contraseña para obtener acceso a cualquier otro dato para el que ese usuario tenga permisos. Por su naturaleza, las credenciales de autenticación alternativas son menos seguras que la autenticación federada predeterminada.

Todavía puede tomar decisiones para aumentar la seguridad. Toda la comunicación se envía a través de HTTPS y se aplican requisitos de complejidad de contraseñas. Su organización debe seguir evaluando si necesita más directivas para cumplir los requisitos de seguridad de los proyectos.

Puede deshabilitar las credenciales de autenticación alternativas si decide que esto no cumple los requisitos de seguridad de su organización. Para más información, consulte Cambio de directivas de seguridad de conexión & de aplicaciones para su organización.

Protección del acceso a su organización

Los administradores pueden usar Microsoft Entra ID para controlar el acceso a los recursos y aplicaciones de Azure, como Azure DevOps. Con el control de acceso condicional instaurado, Microsoft Entra ID comprueba si se dan las condiciones específicas que ha establecido para que un usuario acceda a una aplicación. Una vez que el usuario cumple los requisitos de acceso, se lo autentica y se le permite obtener acceso a la aplicación.

Azure DevOps admite la aplicación de determinados tipos de directivas de acceso condicional (por ejemplo, barreras IP) para mecanismos de autenticación personalizados de Azure DevOps. Estos mecanismos incluyen tokens de acceso personal, autenticación alternativa, OAuth y claves de Secure Shell (SSH). Si los usuarios obtienen acceso a Azure DevOps a través de un cliente externo, solo se respetan las directivas basadas en IPv4.

Más recursos