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 funcionalidades 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 para mantener los proyectos seguros y seguros.

Este artículo es para los administradores de la organización y profesionales de TI que administran sus recursos de proyecto diariamente. Es más útil para los usuarios que ya están familiarizados con Azure DevOps y quieren 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. Al almacenar los proyectos en Azure DevOps, 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 se encuentran en 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 dentro de cada categoría y se explica lo que Hace Azure DevOps para abordarlas. El artículo comienza por describir cómo se almacenan los datos y cómo Azure DevOps administra el acceso a los datos.

La protección de datos requiere la participación activa de los administradores y usuarios que saben qué pasos se deben seguir para proteger los recursos frente a la divulgación y manipulación no autorizadas. Sea explícito cuando conceda permisos a los puntos de acceso de usuario, por lo que solo las personas adecuadas acceden a los datos dentro de Azure DevOps.

Debe considerar que todos los datos pueden estar en riesgo, independientemente de dónde se usen o cómo se usen. Esta instrucción es verdadera para los datos almacenados en la nube y los datos almacenados en un centro de datos privado. Es importante clasificar los datos, su sensibilidad y riesgo, y el daño que podría hacer si se pone en peligro. Además, clasifique los datos en relación con una directiva general para administrar la seguridad de la información.

Basado en Azure

Hospedamos Azure DevOps completamente 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 para la protección de datos, estos son algunos antecedentes 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 la mayoría de 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 la organización, incluidos los metadatos del proyecto, el historial de control de código fuente con versiones y los detalles de los elementos de trabajo. El almacenamiento de base 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 del identificador de Microsoft Entra y 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 emite una cookie de autenticación al usuario. 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 acceder, la validación de permisos se basa en los permisos explícitos del usuario y en los permisos que heredó el usuario 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, los proyectos de equipo y los datos y la funcionalidad con ámbito de equipo. Los administradores también pueden usar controles de acceso para recursos específicos, como carpetas para el control de versiones y las rutas de acceso de área para los elementos de trabajo.

Disponibilidad de datos

Azure DevOps usa muchas características de Azure Storage para ayudar a garantizar la disponibilidad de los datos si se produce un error de hardware, una interrupción del servicio o un desastre regional. Además, el equipo de Azure DevOps sigue los procedimientos para ayudar a proteger los datos frente a la eliminación accidental o malintencionada.

Redundancia de datos

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

Para 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.

Tener varias copias le permite conmutar por error a una región independiente si hay una interrupción o un desastre importantes, mientras que también tiene 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 opta por evitar la conmutación por error para que los datos del cliente no se pierdan.
• 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 se pierde ese Acuerdo de Nivel de Servicio en un mes específico.
• Dado que solo hay una región en Brasil, los datos del cliente en Brasil se replican 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 emplea copias de seguridad a un momento dado para los blobs almacenados en Azure Blob Storage y las bases de datos dentro de Azure SQL Database. Cada cuenta de almacenamiento mantiene una copia independiente de todos los blobs, con los cambios que se anexan a los datos existentes. Estas copias de seguridad son inmutables, lo que elimina la necesidad de volver a escribir cualquier almacenamiento existente durante los procedimientos de copia de seguridad.

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

Puede recuperar organizaciones o proyectos eliminados en el período de 28 días después de la eliminación. Pero, una vez transcurrido este período de tiempo, estas entidades se eliminan permanentemente y no se pueden restaurar. Aunque estas copias de seguridad sirven como componente fundamental para la recuperación ante desastres, es esencial que los clientes practiquen las estrategias de copia de seguridad y administración de datos adecuadas para garantizar una protección completa de sus datos.

La práctica es crítica

Tener varias copias de seguridad de los datos es buena, pero sin práctica, la restauración puede ser impredecible. La gente dice que "las copias de seguridad nunca fallan; lo hacen las restauraciones". Aunque la declaración es técnicamente incorrecta, la opinión es correcta.

Microsoft practica regularmente la restauración de conjuntos de datos a partir de la copia de seguridad. Probamos periódicamente el almacenamiento con redundancia geográfica de Azure. Hay muchas combinaciones de escenarios de desastres y daños en los datos. Seguimos planeando y ejecutando nuevas pruebas para estos escenarios con regularidad.

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 la aplicación 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 y limitación. Esta práctica ayuda a evitar el uso excesivo de los recursos de servicio clave 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. Tenemos un equipo de operaciones que está disponible constantemente para identificar rápidamente el problema y para interactuar con los recursos necesarios del equipo de desarrollo.

A continuación, los recursos del equipo de desarrollo solucionan el problema. También pretenden actualizar la página de estado del servicio en cuestión de minutos después de detectar un problema que afecte al servicio. Después de que los recursos del equipo de desarrollo solucionen un problema, identifican la causa principal y realizan un seguimiento de los cambios necesarios para evitar problemas similares en el futuro.

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

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:

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 Acuerdo de Nivel de Servicio y proporciona una garantía financiera para garantizar que cumplamos este contrato 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 guía los procedimientos de operación en la nube en Azure DevOps.

El equipo de Azure DevOps tiene requisitos de aprendizaje anual para todos los ingenieros y personal de operaciones. El equipo también patrocina reuniones informales hospedadas por ingenieros de Microsoft. Después de que el equipo resuelva un problema que aparece en una reunión, comparte las lecciones aprendidas con otros equipos.

Las metodologías siguientes especifican los requisitos de entrenamiento:

• Modelado de amenazas durante el diseño del servicio
• Procedimientos recomendados para el diseño y el código
• Comprobación de la seguridad con herramientas y pruebas estándar
• Limitación del acceso a datos operativos y de clientes
• Implementación de nuevas características mediante un proceso de aprobación rígido

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 infraestructura como servicio (IaaS), como 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 las que se usan para la implementación, la supervisión y los 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 intentan aprovechar los servicios de producción en vivo y la infraestructura de Azure DevOps mediante 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 y la formación. Puede revisar los resultados de las pruebas de penetración recientes de Azure DevOps en el Portal de confianza de servicios de Microsoft.

Seguridad de credenciales

Microsoft se compromete a garantizar que los proyectos permanezcan seguros y seguros, 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, se adhieren a los procedimientos siguientes con respecto a las credenciales o secretos que almacena Azure DevOps. Para obtener más información sobre cómo elegir el mecanismo de autenticación adecuado, consulte Guía para la autenticación.

Tokens de acceso personal (PAT)

• Almacenamos un hash del PAT.
• Los PAT sin procesar generan en memoria en el lado servidor. 32 bytes generan aleatoriamente a través del 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 genera en memoria en el servidor como HMACSHA256Hash del PAT sin procesar mediante 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.

Claves de Secure Shell (SSH)

• Almacenamos un hash del identificador de la organización envolvente y la clave pública SSH.
• Las claves públicas sin procesar se proporcionan directamente por el autor de la llamada a través de SSL.
• El hash SSH genera una clave de firma simétrica de 64 bytes en el servidor como HMACSHA256Hash del identificador de la organización y una clave pública sin procesar mediante 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)

• Problema de credenciales de OAuth como tokens web JSON (JWT) totalmente descritos y no se almacenan 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 cree que las pruebas de penetración mostraron un posible error de seguridad relacionado con el servicio Azure DevOps, notifique a Microsoft en un plazo de 24 horas. Para obtener más información, consulte la página web de Microsoft para notificar una vulnerabilidad de seguridad del equipo.

Programa de recompensas

Azure DevOps participa en el programa de recompensas de errores de Microsoft. Este programa recompensa a los investigadores de seguridad que nos informan de problemas y anima a más personas a ayudar a mantener Azure DevOps seguro. Para más información, consulte 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. Se concede acceso en el nivel de privilegio mínimo requerido y solo después de la comprobación de las justificaciones de un usuario. Si un miembro del equipo necesita acceso para resolver un problema urgente o implementar un cambio de configuración, debe solicitar acceso Just-In-Time al servicio de producción. El acceso se revoca en cuanto se resuelve la situación.

Realizamos un seguimiento y supervisamos las solicitudes y aprobaciones de acceso en un sistema independiente. Todo el acceso al sistema se correlaciona con estas aprobaciones. Si detectamos acceso no aprobado, alertamos al equipo de operaciones para investigar.

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 personal de operaciones, los datos permanecen protegidos. Se deben realizar más comprobaciones de autenticación a través de una tarjeta inteligente o una llamada telefónica a un número previamente aprobado antes de permitir 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. Cualquier acceso a estos secretos requiere un permiso específico, que se registra y se 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 de alteraciones externas, no permitimos aplicaciones como Outlook y Office, ya que a menudo son objetivos de suplantación de identidad de lanza y otros tipos de ataques.

Protección y respuesta de intrusiones

Ciframos los datos a través de HTTPS y SSL para ayudar a garantizar que no se intercepta ni modifica mientras está 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 a través del cifrado de datos transparente. Esta característica ayuda a protegerse contra actividades malintencionadas 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 del lado del servicio.

El equipo de Azure DevOps usa la infraestructura de Azure para registrar y supervisar aspectos clave del servicio. El registro y la supervisión ayudan a garantizar que las actividades dentro del servicio son legítimas y ayudan a detectar infracciones o intentos de infracciones.

Todas las actividades de implementación y administrador se registran de forma segura, ya que es el acceso del operador al almacenamiento de producción. La información del registro se analiza automáticamente y cualquier comportamiento potencialmente malintencionado o no autorizado genera alertas en tiempo real.

Cuando el equipo de Azure DevOps identifica una posible vulnerabilidad de seguridad de alta prioridad o intrusiones, tiene un plan de respuesta claro. En este plan se describen las partes responsables, los pasos necesarios para proteger los datos de los clientes e instrucciones sobre cómo interactuar con expertos en seguridad en 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 amenazas emergentes, Azure DevOps emplea una estrategia de vulneración de seguridad . Un equipo altamente especializado de expertos en seguridad dentro de Microsoft asume el papel 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 ransomware

Azure DevOps usa controles de Azure para ayudar a evitar, detectar y responder a un ataque de ransomware. Para más información sobre cómo Azure ayuda a proteger a los clientes frente a ataques de ransomware, consulte Protección contra ransomware en Azure.

Privacidad de datos

Debe tener confianza en que estamos manejando sus datos de forma adecuada y para usos legítimos. Parte de esa garantía implica restringir cuidadosamente el 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, la organización se asigna a la ubicación más cercana. Sin embargo, puede elegir otra ubicación al crear la organización. Si cambia de opinión más adelante, 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 su lugar, los datos se replican geográficamente en una segunda región dentro de la misma ubicación. La única excepción es Brasil, que replica datos en la región Centro-sur de EE. UU. con fines de recuperación ante desastres.

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

Acceso al cumplimiento de la ley

En algunos casos, terceros, como las entidades de aplicación de la ley, podrían abordar Microsoft para obtener acceso a los datos de los clientes almacenados en Azure DevOps. Intentamos redirigir las solicitudes al propietario de la organización para la resolución. Cuando una orden judicial obliga a Microsoft a revelar datos de clientes a terceros, Microsoft realiza un esfuerzo razonable para notificar al propietario de la organización por adelantado, a menos que esté prohibido legalmente hacerlo.

Algunos clientes requieren su almacenamiento de datos en una ubicación geográfica determinada para garantizar una jurisdicción legal específica para cualquier actividad de aplicación de la ley. Todos los datos del cliente, como el código fuente, los elementos de trabajo, los resultados de las pruebas y los reflejos con redundancia geográfica y las copias de seguridad fuera del sitio, se mantienen dentro de una de las ubicaciones mencionadas anteriormente.

Microsoft Access

De vez en cuando, los empleados de Microsoft necesitan obtener acceso a los datos de los clientes almacenados en Azure DevOps. Como medida de precaución, todos los empleados que tienen (o pueden tener) acceso a los datos de los clientes deben pasar una comprobación de antecedentes que incluya antecedentes laborales anteriores y condenas penales. Permitimos el acceso a los sistemas de producción solo cuando hay un incidente de 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, clasificamos los datos en estos tipos:

• Datos del cliente: lo que se carga en Azure DevOps.
• Datos de la organización: información que envía al registrarse o administrar su organización.
• Datos de Microsoft: información necesaria para o recopilada a través del funcionamiento del servicio.

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 quiere ponerse en contacto con los clientes para informarles sobre más características y servicios que podrían ser ú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.

Creación de confianza

Puede confiar en otros esfuerzos que Microsoft realiza en nombre de Azure DevOps. Estos esfuerzos incluyen directivas de adopción internas en Microsoft, el nivel de transparencia en el estado de nuestro servicio y el progreso hacia la recepción de la certificación de nuestros sistemas para administrar la seguridad de la información.

Adopción interna

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

Los equipos grandes se mueven más gradualmente que los más pequeños, debido a sus inversiones en sistemas de DevOps existentes. Para los equipos que se mueven rápidamente, 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 más necesarios para los proyectos internos se incluye la asociación de la organización con el identificador de Entra de Microsoft para garantizar la complejidad adecuada del ciclo de vida de la identidad del usuario y la contraseña. Los proyectos que son más sensibles también requieren autenticación en dos fases.

Certificaciones de cumplimiento

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

• ISO 27001:2013
• 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-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 de iniciativa de evaluación del consenso (CAIQ) ayuda a las organizaciones a evaluar y evaluar las prácticas y funcionalidades de seguridad de los proveedores de servicios en la nube. En consonancia con nuestro compromiso con la seguridad y la transparencia, hemos completado recientemente la evaluación de CAIQ para Azure DevOps. Le invitamos a revisar el informe completo en el Portal de confianza de servicios de Microsoft.

Pasos que puede realizar

La protección de datos adecuada requiere una interacción activa de usted, sus administradores y sus usuarios. Los datos del proyecto almacenados en Azure DevOps solo son tan seguros como los puntos de acceso de usuario. 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 la sensibilidad y el horizonte de riesgo, junto con los daños que pueden producirse si se ponen en peligro. Muchas empresas tienen métodos de clasificación existentes que pueden reutilizar cuando los proyectos se mueven a Azure DevOps. Para obtener más información, puede descargar clasificación de datos para la preparación para la nube de Microsoft Trustworthy Computing.

Adopción del identificador de Entra de Microsoft

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 su directiva de acceso de usuario, complejidad de contraseñas, actualizaciones de contraseña y expiración cuando los usuarios abandonan su organización. A través de la federación de Active Directory, puede vincular directamente el identificador de Entra de Microsoft al directorio central de la organización, por lo que solo tiene una ubicación para administrar estos detalles para su empresa.

En la tabla siguiente se comparan las características de Microsoft Account y Microsoft Entra en relación con el acceso a Azure DevOps:

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 requerir varios factores mediante el identificador de Entra de Microsoft. 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 entra en manos incorrectas, BitLocker impide el acceso no autorizado de copias locales de datos de los proyectos.

Limitar el uso de credenciales de autenticación alternativas

El mecanismo de autenticación predeterminado para las herramientas relacionadas con Git es la autenticación alternativa (a veces denominada autenticación básica). Este mecanismo permite a un usuario configurar un nombre de usuario y una contraseña alternativos para su uso durante las operaciones de línea de comandos de Git. El usuario puede usar esta combinación de nombre de usuario y contraseña para acceder 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 hay 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 no cumple los requisitos de seguridad de su organización. Para obtener más información, consulte Cambio de las directivas de seguridad y conexión de aplicaciones para su organización.

Protección del acceso a su organización

Los administradores pueden usar el identificador de Entra de Microsoft para controlar el acceso a los recursos y aplicaciones de Azure, como Azure DevOps. Con el control de acceso condicional implementado, Microsoft Entra ID comprueba las condiciones específicas que estableció para que un usuario acceda a una aplicación. Una vez que el usuario cumple los requisitos de acceso, el usuario se autentica y puede acceder 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 acceden a Azure DevOps a través de un cliente de terceros, solo se respetan las directivas basadas en IPv4.

Más recursos

• Página principal de Azure DevOps
• Ubicaciones de datos para Azure DevOps
• Declaración de privacidad de Microsoft
• Compatibilidad con Azure DevOps
• Características y servicios incluidos en Azure DevOps
• Centro de confianza de Azure
• Ciclo de vida de desarrollo de seguridad de Microsoft