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 el planeamiento hasta la implementación. En función de las funcionalidades locales, con servicios en la nube adicionales, 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 lleva a cabo para ayudar a mantener los proyectos seguros, disponibles, seguros y privados. Además, describe el rol que desempeña para mantener los proyectos seguros y seguros.

Este artículo está pensado para administradores de la organización y profesionales de TI que administran diariamente sus recursos de proyecto. Será más útil para los usuarios que ya están familiarizados con Azure DevOps y quieren saber más 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 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 en reposo y en tránsito.

Las amenazas a las que se enfrenta se reducen 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 dentro de cada categoría y se explica qué Azure DevOps hace para abordarlas. En primer lugar, en el artículo se describe 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 deben saber 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.

Sea cual sea el enfoque, debe considerar todos los datos potencialmente "en riesgo", independientemente de dónde se use o cómo se usen. Esto es cierto para los datos de la nube y los datos almacenados en un centro de datos privado. Es importante clasificar los datos, su confidencialidad y riesgo, y el daño que podría causar si se pone en peligro. Además, clasifique los datos en relación con una directiva general de administración de seguridad de la información.

Basado en Azure

Diagram of Azure DevOps high-level architecture.

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 las necesidades de almacenamiento y recuperación, Azure DevOps usa Azure Blob Storage (para objetos binarios grandes) y Azure SQL almacenamiento de datos. Para comprender el enfoque de Azure DevOps Services para la protección de datos, es importante obtener información general sobre estos elementos.

  • Azure Blob Storage almacena grandes fragmentos de datos no estructurados. Todos los proyectos utilizan el servicio de Azure Blob Storage. 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. Para obtener más información, consulte Azure Blob Storage.

  • Azure SQL Database almacenamiento 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 del elemento de trabajo. El almacenamiento de base de datos proporciona acceso rápido a los elementos importantes de su proyecto y proporciona índices en el almacenamiento de blobs para buscar archivos y datos adjuntos. Para obtener más información, consulte Azure SQL Database.

Los administradores pueden administrar el acceso a los recursos concediéndoles 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 Azure Active Directory (Azure AD) y 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 haya comprobado las credenciales del usuario, Azure DevOps emite una cookie de autenticación al usuario, lo que permite al usuario permanecer autenticado en Azure DevOps.

De este modo, la información de credenciales del usuario nunca se comparte directamente con Azure DevOps. Para cada recurso Azure DevOps al que el usuario intenta acceder, los permisos se validan en función de los permisos explícitos del usuario, así como los permisos heredados a través de la pertenencia a grupos. Los administradores pueden usar controles de acceso para proteger el acceso a la organización, colecciones de proyectos, proyectos de equipo y datos y funcionalidades con ámbito de equipo. Los administradores también pueden proteger recursos más específicos, como carpetas de control de versiones y rutas de acceso del área de trabajo.

Disponibilidad de los datos

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

Redundancia de datos

Para proteger los datos durante errores de hardware o servicio, Azure Storage replica geográficamente los datos del cliente entre dos regiones de la misma geografía. Por ejemplo, Azure 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 y se replican de forma asincrónica en una segunda región de la misma geografía. Por lo tanto, Azure siempre mantiene el equivalente de seis copias de los datos. Esto le permite conmutar por error a una región independiente si hay una interrupción o un desastre importantes, al mismo tiempo que tiene redundancia local para errores de hardware dentro de una región. Para Azure SQL Database almacenamiento, las copias de seguridad diarias se mantienen fuera del sitio si hay un desastre regional.

Nota

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 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 la unidad de escalado afectada. Excepto en circunstancias extremas, Microsoft opta por no conmutar por error para que los datos del cliente no se pierdan.
  • Azure DevOps ofrece una garantía del Acuerdo de Nivel de Servicio de tiempo de actividad del 99,9 por ciento y 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 de clientes en Brasil se replican en la región Centro-sur de EE. UU. con fines de recuperación ante desastres.

Se producen errores

Para protegerse frente a la eliminación accidental de datos, Microsoft también toma copias de seguridad a un momento dado de los blobs de Azure Blob Storage y las bases de datos de Azure SQL Database. Hay una copia independiente de todos los blobs y los cambios se anexan a cada cuenta de almacenamiento. Dado que estos datos son inmutables, no es necesario volver a escribir ningún almacenamiento existente como parte de los procedimientos de copia de seguridad.

Las copias de seguridad son una parte estándar de Azure SQL Database y Azure DevOps hace uso de esto. Mantenemos un valor de 28 días de sus datos. En ambos casos, estas copias de seguridad también se replican en una región emparejada, lo que ayuda a garantizar que se recupera de una interrupción regional.

Una protección adicional es que Microsoft puede recuperar todas las organizaciones durante un máximo de 28 días después de la eliminación. Esto se debe a que realizamos una "eliminación temporal" para las operaciones de eliminación de la organización.

La práctica es crítica

Tener varias copias de seguridad redundantes de los datos es buena, pero sin práctica, la restauración puede ser impredecible. Se ha dicho que "las copias de seguridad nunca fallan, las restauraciones sí". Aunque técnicamente incorrecto, la opinión es correcta.

Microsoft practica regularmente la restauración de varios conjuntos de datos a partir de la copia de seguridad. El almacenamiento con redundancia geográfica de Azure se prueba periódicamente. Además, de vez en cuando, restauramos desde copias de seguridad para recuperarse de un error humano, como cuando un cliente ha eliminado accidentalmente un proyecto en Azure DevOps. Hay muchas combinaciones de escenarios de desastres y daños en los datos, que seguimos planeando y ejecutando nuevas pruebas 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 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.

Para ataques específicos de la aplicación que pueden penetrar en los sistemas de defensa de Azure, Azure DevOps establece cuotas y límites de nivel de aplicación y organización. Esto 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 disponible 24x7 para identificar rápidamente el problema y para interactuar con los recursos necesarios del equipo de desarrollo. A continuación, esos recursos solucionan el problema. También tienen como objetivo actualizar la página de estado del servicio en cuestión de minutos después de detectar un problema que afecte al servicio. Una vez que el equipo ha solucionado un problema, identifican la causa principal del problema y realizan un seguimiento de los cambios necesarios para evitar problemas similares en el futuro.

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

La administración de sitios en directo en Azure DevOps tiene tres pistas distintas: telemetría, administración de incidentes y revisión del sitio activo. Estas son las pistas que conllevan:

Image of the Azure DevOps Services live site management process.

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 pueden afectar solo a algunos de nuestros clientes. Las investigaciones en 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 (SLA) 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 más información, consulte Acerca de la seguridad, la autenticación y la autorización.

Protección 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 sus procedimientos de operación en la nube. Las metodologías siguientes especifican los siguientes requisitos:

  • Modelado de amenazas durante el diseño del servicio.
  • Siga los procedimientos recomendados de diseño y código.
  • Comprobación de la seguridad con herramientas y pruebas estándar.
  • Limitar el acceso a datos operativos y de clientes.
  • Gating rollout of new features through a rigid approval process.

El equipo de Azure DevOps tiene requisitos de formación anuales para todos los ingenieros y el personal de operaciones, y patrocina reuniones informales de "bolsa marrón" hospedadas por ingenieros de Microsoft. Después de resolver un problema generado en una reunión de bolsa marrón, comparten lo que han aprendido con el resto del equipo.

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 para 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 usadas 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. Con las mismas técnicas y mecanismos que los atacantes malintencionados, las pruebas de penetración intentan aprovechar los servicios de producción en vivo y la infraestructura de Azure DevOps. El objetivo es identificar vulnerabilidades, configuraciones, errores u otras brechas de seguridad en un proceso controlado. El equipo revisa los resultados 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 Azure DevOps en el Portal de confianza de servicios.

Seguridad de credenciales

Las credenciales de Azure DevOps se almacenan mediante procedimientos recomendados del sector. Más información sobre el almacenamiento de credenciales.

Informes de problemas de seguridad

Si durante las pruebas de penetración cree que ha detectado 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, vea Notificar una vulnerabilidad de seguridad del equipo.

Importante

Aunque ya no es necesario notificar a Microsoft las actividades de pruebas de penetración, debe cumplir con las reglas de compromiso de las pruebas de penetración unificadas de Microsoft Cloud.

Programa de recompensas

Azure DevOps participa en el Programa de Recompensas de Microsoft Online Services. 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 obtener más información, consulte el Azure DevOps Programa de recompensas.

Restricción del acceso

Microsoft mantiene un control estricto sobre quién obtiene acceso a nuestros datos de cliente y entorno de producción. El acceso se concede en el nivel de privilegios mínimos necesarios y solo después de que se proporcionen y comprueben las justificaciones adecuadas. 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.

Las solicitudes de acceso y las aprobaciones se realizan un seguimiento y se supervisan en un sistema independiente. Todo el acceso al sistema se correlaciona con estas aprobaciones y, si detectamos acceso no aprobado, el equipo de operaciones recibe una alerta para investigar.

Usamos la autenticación en dos fases para todo el acceso remoto al sistema. Por lo tanto, si se ha robado el nombre de usuario y la contraseña de uno de nuestros desarrolladores o personal de operaciones, los datos permanecen protegidos. Esto significa que se deben realizar comprobaciones de autenticación adicionales a través de una tarjeta inteligente o una llamada telefónica a un número aprobado previamente antes de permitir cualquier acceso remoto al servicio.

Además, Microsoft usa secretos para administrar y mantener el servicio, como contraseñas RDP, certificados SSL y claves de cifrado. Todos ellos se administran, almacenan y transmiten de forma segura a través de la 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 se pueden rotar 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 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 asegurarnos de que no se interceptan ni modifican mientras están en tránsito entre usted y Azure DevOps.

Además, los datos que almacenamos en su nombre en Azure DevOps se cifran de la siguiente manera:

  • Los datos almacenados en las bases de datos de Azure SQL se cifran mediante Cifrado de datos transparente (TDE). TDE protege contra la amenaza de 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 proteger los datos en tránsito. Para proteger los datos en reposo almacenados en Azure Blob Storage, Azure DevOps usa Azure Storage Service Encryption (SSE).

La infraestructura de Azure ayuda al equipo de Azure DevOps a registrar y supervisar aspectos clave del servicio. Esto ayuda a garantizar que las actividades dentro del servicio sean legítimas y detecte infracciones o intentos de vulneración. Además, todas las actividades de implementación y administrador se registran de forma segura, al igual que el acceso del operador al almacenamiento de producción. Las alertas en tiempo real se generan porque la información del registro se analiza automáticamente para descubrir comportamientos potencialmente malintencionados o no autorizados.

Cuando se identifique una posible vulnerabilidad de seguridad de alta prioridad o intrusión, el equipo tiene un plan de respuesta claro. En este plan se describen las partes responsables, los pasos necesarios para proteger los datos de los clientes y cómo interactuar con expertos en seguridad en Microsoft. El equipo también notifica a los propietarios de la organización si los datos fueron divulgados o dañados, para que puedan tomar los pasos adecuados para solucionar la situación.

Por último, para ayudar a combatir las amenazas emergentes, Azure DevOps emplea una estrategia de "Asumir vulneración". Un grupo altamente especializado de expertos en seguridad en Microsoft, conocido como equipo rojo, 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, respuesta y defensa de amenazas del servicio. También permite al equipo validar y mejorar la eficacia de todo el programa de seguridad.

Privacidad de datos

Debe tener confianza en que los datos se administran correctamente y para usos legítimos. Parte de esa garantía implica restringir adecuadamente el uso para que los datos solo se usen por motivos legítimos.

Reglamento General de Protección de Datos (RGPD)

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 la regulación del RGPD, consulte la página de información general del Centro de confianza de Microsoft.

Residencia y soberanía 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 geografía más cercana, pero tiene la opción de elegir una geografía diferente. Si cambia de opinión más adelante, es posible migrar la organización a una geografía diferente, con la ayuda del soporte técnico de Microsoft.

Azure DevOps no mueve ni replica los datos del cliente fuera de la geografía elegida. En su lugar, los datos se replican geográficamente en una segunda región dentro de la misma geografía. La única excepción es Brasil, que replica datos en la geografía 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 de macOS proporcionados por Microsoft, los datos se transferirán a un centro de datos de GitHub en EE. UU.

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

Acceso a la aplicación de la ley

En algunos casos, terceros, como las entidades de cumplimiento de la ley, podrían aproximarse a 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 su resolución. Cuando la orden judicial obliga a divulgar datos de clientes a terceros, Microsoft hace un esfuerzo razonable para notificar al propietario de la organización por adelantado, a menos que esté legalmente prohibido 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 zonas geográficas 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 tengan o puedan tener acceso a los datos de los clientes deben pasar una comprobación de antecedentes, que comprueba las condenas penales y de empleo anteriores. 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 igual, clasificamos los datos para distinguir entre los siguientes tipos de datos:

  • Datos del cliente: lo que carga en Azure DevOps.
  • Datos de la organización: información que se usa 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 características y servicios adicionales 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 Realiza Microsoft en nombre de Azure DevOps. Estos esfuerzos incluyen directivas de adopción internas en Microsoft, el nivel de transparencia proporcionado en el estado de nuestro servicio y el progreso hacia la certificación de nuestros sistemas de administración de seguridad de la información.

Adopción interna

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

Obviamente, los equipos grandes se mueven más gradualmente que los más pequeños, dadas sus inversiones en sistemas de DevOps existentes. Para que los equipos puedan moverse rápidamente, hemos establecido un enfoque de clasificación de proyectos. Evalúa la tolerancia al riesgo, 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 para los proyectos internos se incluyen la asociación de la organización con Azure AD para garantizar la complejidad adecuada del ciclo de vida de la identidad del usuario y la contraseña. Para proyectos más confidenciales, también se requiere la autenticación en dos fases.

Certificaciones de cumplimiento

Algunos de ustedes quieren comprender la evaluación de terceros de nuestros procedimientos de seguridad de datos. Azure DevOps ha logrado las siguientes certificaciones:

  • ISO 27001:2013
  • ISO 27018:2019
  • HIPAA (Ley de portabilidad y responsabilidad de seguros de salud)
  • BAA (Contrato de socio comercial)
  • Cláusulas modelo de la UE
  • SOC 1 tipo 2
  • SOC 2 tipo 2
  • C5 de Alemania

La auditoría de SOC para Azure DevOps cubre 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.

Pasos que puede realizar

La protección de datos adecuada requiere la participación activa, así como la de los administradores y los usuarios. Los datos del proyecto almacenados en Azure DevOps solo son tan seguros como los puntos de acceso del usuario final. 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, y el daño que puede producirse si se pone en peligro. Muchas empresas tienen métodos de clasificación existentes que se pueden reutilizar cuando los proyectos se mueven a Azure DevOps. Para obtener más información, puede descargar el documento "Clasificación de datos para la preparación para la nube" de Microsoft Trustworthy Computing.

Adopción de Azure Active Directory

Use Azure Active Directory (Azure AD) para administrar el acceso de la organización a Azure DevOps. Azure AD proporciona otra manera de mejorar la seguridad de las credenciales de los usuarios. Azure AD permite que el departamento de TI administre su directiva de acceso del usuario final, la complejidad de la contraseña, las actualizaciones de contraseñas y la expiración si el usuario abandona la organización. A través de la federación de Active Directory, puede vincular directamente Azure AD 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 la cuenta Microsoft y Azure AD relativas al acceso Azure DevOps:

Propiedades Cuenta Microsoft Azure AD
Creador de identidades Usuario Organización
Nombre de usuario único o contraseña para todos los recursos de trabajo No
Control de complejidad de la duración & de la contraseña Usuario Organización
límites de pertenencia Azure DevOps Cualquier cuenta microsoft (MSA) Directorio de la organización
Identidad rastreable No
Propiedad de ip de la organización & 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 requerir varios factores con Azure AD. 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.

Uso de BitLocker

Para proyectos confidenciales, puede usar BitLocker en el equipo portátil o de escritorio de 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 portátil o de escritorio 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 al usuario final configurar un nombre de usuario y una contraseña alternativos para su uso durante las operaciones de línea de comandos de Git. Esta combinación de nombre de usuario y contraseña también se puede usar 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ña. La organización debe seguir evaluando si se requieren directivas adicionales para cumplir los requisitos de seguridad del proyecto. Puede deshabilitar por completo las credenciales de autenticación alternativas si decide que 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

Azure AD permite a los administradores controlar el acceso a los recursos y aplicaciones de Azure, como Azure DevOps. Con el control de acceso condicional instaurado, Azure AD comprueba si se dan las condiciones específicas que establezca para que un usuario acceda a una aplicación. Una vez que estos requisitos se cumplen, se autentica al usuario, quien puede acceder a la aplicación.

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

Recursos adicionales