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 de Visual Studio Team Foundation Server, con servicios en la nube adicionales, Azure DevOps el código fuente, los elementos de trabajo, las compilaciones y las pruebas. Usa la infraestructura de plataforma como servicio (PaaS) y muchos servicios de Azure, incluido Azure SQL, para ofrecer un servicio confiable y disponible globalmente para los proyectos de desarrollo.

En este artículo se de abordan los pasos que Microsoft realiza 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á destinado a administradores de la organización y profesionales de TI que administran sus recursos de proyecto a diario. Será más útil para los usuarios que ya están familiarizados con 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 sigan siendo 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. Microsoft exige privacidad e integridad de los datos tanto en reposo como 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 Azure DevOps hace para abordarlas. En primer lugar, en el artículo se describe cómo se almacenan los datos y Azure DevOps administrar el acceso a los datos.

Dado que la protección de datos adecuada también requiere la participación activa de administradores y usuarios, debe conocer los pasos que debe seguir para proteger los recursos del proyecto frente a la divulgación y manipulación no autorizadas. Debe ser explícito sobre la concesión de permisos a los puntos de acceso de usuario para tener la confianza de que solo las personas correctas acceden a los datos dentro de Azure DevOps.

Sea cual sea su enfoque, debe considerar todos los datos potencialmente "en riesgo", independientemente de dónde se utilicen o de cómo se utilicen. Esto es así tanto para los datos en la nube como para los almacenados en un centro de datos privado. Por lo tanto, es importante clasificar los datos, su confidencialidad y riesgo, y el daño que podría causar si se pone en peligro. Además, clasifice 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.

Azure DevOps Services se hospeda completamente en centros de datos de Azure y usa muchos de los servicios principales de Azure, incluidos proceso, almacenamiento, redes, Azure SQL, administración de identidades y acceso y Azure Service Bus.

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

  • Azure Blob Storage grandes fragmentos de datos no estructurados. Todos los proyectos usan el servicio azure blob Storage. Estos datos incluyen información potencialmente confidencial o privada, como el contenido de los archivos de origen y los datos adjuntos de los 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 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 control de 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 y proporciona índices en el almacenamiento de blobs para buscar archivos y datos adjuntos. Para obtener más información, vea Azure SQL Database.

Los administradores pueden administrar el acceso a los recursos mediante la concesión o restricción de permisos en identidades de usuario o grupos. Azure DevOps autenticación federada de identidades de usuario a través de Azure Active Directory (Azure AD) y cuentas Microsoft.

Durante la autenticación, el usuario se enruta al proveedor de autenticación, donde proporciona sus credenciales. Después de 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 que el usuario permanezca autenticado en Azure DevOps.

De esta manera, la información de credenciales del usuario nunca se comparte directamente con Azure DevOps. Para cada Azure DevOps recurso al que el usuario intenta acceder, los permisos se validan en función de los permisos explícitos del usuario, así como de 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,las colecciones de proyectos, los proyectos de equipo y la funcionalidad y los datos 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 de área de elementos de trabajo.

Disponibilidad de los datos

Azure DevOps Services usa muchas de las características Azure Storage para garantizar la disponibilidad de los datos en caso de error de hardware, interrupción del servicio o desastre en la región. Además, el equipo de Azure DevOps sigue los procedimientos para proteger los datos contra la eliminación accidental o malintencionada.

Redundancia de datos

Para proteger los datos en caso de errores de hardware o servicio, Azure Storage replica geográficamente los datos de los clientes entre dos regiones de la misma geografía. Por ejemplo, Azure puede replicar geográficamente los 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 se produce una interrupción o un desastre importantes, al 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 se produce 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 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 la unidad de escalado afectada. Excepto en circunstancias extremas, Microsoft opta por no conmutar por error para que los datos de los clientes no se pierdan.
  • Azure DevOps ofrece una garantía del Acuerdo de Nivel de Servicio de tiempo de actividad del 99,9 % y devuelve una parte de los cargos mensuales si ese Acuerdo de Nivel de Servicio se pierde en un mes específico.
  • Dado que solo hay una región en Brasil, los datos de los clientes de Brasil se replican en la Centro-sur de EE. UU. con fines de recuperación ante desastres.

Se cometen errores

Para protegerse contra la eliminación accidental de datos, Microsoft también realiza 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 Azure SQL Database y Azure DevOps Services hace uso de esto. 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 organizaciones enteras durante un máximo de 28 días después de la eliminación. Esto se debe a que Microsoft realiza una "eliminación automática" para las operaciones de eliminación de la organización.

La práctica es fundamental

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

Microsoft realiza periódicamente 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, Microsoft restaura a partir de copias de seguridad para recuperarse de errores humanos, como cuando un cliente ha eliminado accidentalmente un proyecto en Azure DevOps. Hay muchas permutaciones de escenarios de desastres y daños en los datos, y Microsoft sigue planeando y ejecutando nuevas pruebas periódicamente.

Disponibilidad del servicio

Azure DevOps Services ofrece protección contra denegación de servicio distribuido (DDoS) y respuesta a sitios activos para ayudar a garantizar que tiene acceso a su organización y a los recursos asociados.

Protección contra DDoS

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

En el caso de ataques específicos de la aplicación que pueden penetrar los sistemas de defensa de Azure, Azure DevOps establece cuotas de nivel de aplicación y organización y limitació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 en directo

En raras circunstancias, es posible que necesite una respuesta de sitio en directo a un problema con la disponibilidad del servicio. Microsoft tiene un equipo de operaciones disponible las 24 horas del día, los 7 días de la hora, para identificar rápidamente el problema e interactuar con los recursos necesarios del equipo de desarrollo. A continuación, esos recursos abordan 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 afecta al servicio. Una vez que el equipo ha solucionado un problema, identifica la causa principal del problema y realiza 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 para detectar, responder y mitigar problemas. Todas las materias de ingeniería están implicadas y son responsables, por lo que hay mejoras continuas que evolucionan a partir de la experiencia directa. Esto significa que los procesos de supervisión, diagnóstico, resistencia y control de calidad se mejoran con el tiempo.

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

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 podrían afectar solo a algunos de nuestros clientes. Las investigaciones en estos datos a menudo pueden dar lugar a mejoras específicas 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 contrato de nivel de servicio (SLA) y proporciona una garantía financiera para garantizar que se cumple este contrato cada mes. Para obtener más información, vea Sla for 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 una supervisión constante, desde técnicas de diseño y codificación adecuadas hasta factores operativos. Microsoft invierte activamente en la prevención de brechas de seguridad y en la detección de infracciones. Si hay 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, vea Acerca de la seguridad, la autenticación y la autorización.

Proteger por diseño

Azure DevOps Services está diseñado para ser seguro. Hace uso de la Ciclo de vida de desarrollo de seguridad de Microsoft en el núcleo de su proceso de desarrollo, y el programa Microsoft Operational Security Assurance guía sus procedimientos de operación en la nube. Estas metodologías especifican los siguientes requisitos:

  • Modelado de amenazas durante el diseño del servicio.
  • Seguir los procedimientos recomendados de diseño y código.
  • Comprobación de la seguridad con herramientas y pruebas estándar.
  • Limitación del acceso a los datos operativos y de cliente.
  • Acceso al lanzamiento de nuevas características a través de un proceso de aprobación rígido.

El Azure DevOps Services cuenta con requisitos de entrenamiento anuales para todos los ingenieros y personal de operaciones, y patrocinadora reuniones informales de "bolsa negra" hospedadas por ingenieros de Microsoft. Después de resolver un problema que se ha producido en una reunión de bolsa morena, 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 la 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. La misma actualización se aplica a las máquinas locales, incluidas las que se usan para la implementación, supervisión e informes.

El Azure DevOps Services 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 directo y la infraestructura de Azure DevOps. El objetivo es identificar vulnerabilidades reales, 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 el entrenamiento.

Seguridad de credenciales

Las credenciales de Azure DevOps se almacenan mediante los procedimientos recomendados del sector. Obtenga 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, informe 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, todavía debe cumplir las reglas de compromiso de pruebas de penetración unificadas de Microsoft Cloud.

Programa de recompensas

Azure DevOps participa en microsoft online services Programa de recompensas. Este programa recompensa a los investigadores de seguridad que nos informan de problemas y anima a más personas a ayudar a Azure DevOps seguridad. Para obtener más información, vea el Azure DevOps Programa de recompensas.

Restricción del acceso

Microsoft mantiene un control estricto sobre quién obtiene acceso a nuestro entorno de producción y a los datos de los clientes. El acceso solo se concede en el nivel de privilegio mínimo necesario y solo después de proporcionar y comprobar 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.

Se realiza un seguimiento de las solicitudes de acceso y las aprobaciones y se supervisan en un sistema independiente. Todo el acceso al sistema se correlaciona con estas aprobaciones y, si se detecta acceso no aprobado, se genera una alerta para que el equipo de operaciones investigue.

Si se robaron el nombre de usuario y la contraseña de uno de nuestros desarrolladores o del personal de operaciones, los datos siguen estando protegidos porque usamos la autenticación en dos fases para todo el acceso remoto al sistema. Esto significa que deben realizarse 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 del Azure Portal. Cualquier acceso a estos secretos requiere un permiso específico, que se registra y registra de forma segura. Todos los secretos se giran a cadencia regular y se pueden rotar a petición si hay un evento de seguridad.

El Azure DevOps de operaciones usa estaciones de trabajo de administrador con seguridad 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 la manipulación externa, en este entorno no se permiten aplicaciones como Outlook y Office, que a menudo son destinos de suplantación de identidad (phishing) y otros tipos de ataques.

Protección y respuesta de intrusiones

Para asegurarse de que los datos no se interceptan ni modifican mientras están en tránsito entre usted y Azure DevOps, los ciframos a través de HTTPS y SSL.

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

  • Para los datos almacenados en bases de SQL azure, Azure DevOps usa Cifrado de datos transparente (TDE). Esto protege contra la amenaza de actividad malintencionada 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 Storage blobs de Azure 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 Azure DevOps Services a registrar y supervisar aspectos clave del servicio. Esto ayuda a garantizar que las actividades dentro del servicio son legítimas y detecta infracciones o intentos de infracció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 inician porque la información del registro se analiza automáticamente para descubrir comportamientos potencialmente malintencionados o no autorizados.

Cuando se ha detectado una posible intrusión o se ha identificado una vulnerabilidad de seguridad de alta prioridad, el equipo tiene un plan claro de respuesta a incidentes de seguridad. 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 de Microsoft. El equipo también notifica a los propietarios de la organización si los datos están potencialmente divulgados o dañados, para que puedan tomar las medidas adecuadas para solucionar la situación.

Por último, para ayudar a combatir las amenazas emergentes, Azure DevOps Services emplea una estrategia de "Asumir brecha". Un grupo altamente especializado de expertos en seguridad de Microsoft, conocido como equipo rojo, asume el rol de adversarios sofisticados. Este equipo prueba la detección de infracciones y la respuesta para medir con precisión la preparación y los impactos de los ataques del mundo real. 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.

Privacidad de datos

Debe tener la confianza de 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 utilicen por motivos legítimos.

Reglamento General de Protección de Datos (RGPD)

El Reglamento general de protección de datos (RGPD) es el cambio más importante en las leyes de protección de datos en Europa desde la introducción en 1995 de la Directiva de protección de datos de la Unión Europea (UE) 95/46/EC. Para más información sobre el reglamento 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 regiones 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 geográfica 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 su organización a otra ubicación geográfica, con la ayuda del soporte técnico de Microsoft.

Azure DevOps no mueve ni replica los datos de los clientes 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 los datos en la Centro-sur de EE. UU. geográfica con fines de recuperación ante desastres.

Nota

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

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

Acceso de aplicación de la ley

En algunos casos, terceros, como las entidades de cumplimiento de la ley, podrían acercarse a Microsoft para obtener acceso a los datos de los clientes almacenados Azure DevOps. Microsoft intenta redirigir las solicitudes al propietario de la organización para su resolución. Cuando se ve obligado por orden de la corte a revelar datos de clientes a un tercero, Microsoft hace un esfuerzo razonable para notificar al propietario de la organización de antemano, a menos que se nos prohíba 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 las actividades 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 en la sección anterior.

Acceso de Microsoft

De vez en cuando, los empleados de Microsoft necesitan obtener acceso a los datos de los clientes almacenados 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 el empleo anterior y los antecedentes delictivos. Además, solo se permite el acceso a los sistemas de producción cuando hay un incidente de sitio en directo u otra actividad de mantenimiento aprobada, que se registra y supervisa.

Dado que no todos los datos de nuestro sistema se tratan igual, los datos se clasifican para distinguir entre los datos del cliente (lo que se carga en Azure DevOps), los datos de la organización (información que se usa al registrarse o administrar su organización) y los datos de Microsoft (información necesaria para o recopilada a través del funcionamiento del servicio). En función de la clasificación, Microsoft controla los escenarios de uso, los requisitos de ubicación geográfica, las restricciones de acceso y los requisitos de retención.

Uso promocional de Microsoft

En ocasiones, Microsoft quiere ponerse en contacto con los clientes para que sepan sobre características y servicios adicionales que pueden ser útiles. Dado que no todos los clientes quieren ponerse en contacto con ellos sobre estas ofertas, puede participar y no participar en las comunicaciones de correo electrónico de marketing.

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

Generar confianza

Además de estas protecciones, puede confiar en otros esfuerzos que Microsoft realiza en nombre de Azure DevOps. Entre ellas se incluyen las directivas de adopción internas de Microsoft, el nivel de transparencia proporcionado en el estado de nuestro servicio y el progreso hacia la recepción de la certificación de nuestros sistemas de administración de seguridad de la información.

Adopción interna

Teams de Microsoft están adoptando Azure DevOps internamente. El Azure DevOps se trasladó a una organización en 2014 y la usa ampliamente. Más ampliamente, 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 DevOps existentes. Para los equipos que pueden 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. Para los equipos más grandes, la adopción suele producirse en fases, con más planeamiento.

Entre los requisitos adicionales de los proyectos internos se incluyen la asociación de la organización con Microsoft.com Azure Active Directory para garantizar el ciclo de vida de la identidad de usuario y la complejidad de la contraseña adecuados. Para proyectos más confidenciales, también se requiere la autenticación en dos fases.

Certificaciones de cumplimiento

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

  • ISO 27001:2013
  • HIPAA (Ley de responsabilidad y portabilidad de seguros de salud)
  • BAA (Contrato de asociación empresarial)
  • Cláusulas modelo de la UE
  • SOC 1 tipo 2
  • SOC 2 tipo 2

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

Pasos que puede seguir

La protección adecuada de los datos requiere su participación activa, así como la de los administradores y usuarios. Los datos del proyecto almacenados Azure DevOps solo son tan seguros como los puntos de acceso del usuario final. Es importante hacer coincidir el nivel de integridad y granularidad de los permisos para esas organizaciones con el nivel de confidencialidad del proyecto.

Clasificación de los datos

El primer paso consiste en clasificar los datos en función de su sensibilidad y su horizonte de riesgo, y los daños que pueden producirse si están 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.

Adoptar Azure Active Directory

Otra manera de mejorar la seguridad de las credenciales de los usuarios finales es usar Azure Active Directory (Azure AD) para administrar el acceso de la organización a Azure DevOps. Azure AD permite que el departamento de TI administre su directiva de acceso de usuario final, incluida 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 Active Directory federación, puede vincular directamente Azure AD al directorio central de su 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 Azure AD Microsoft con respecto al Azure DevOps acceso:

Propiedades Cuenta Microsoft Azure AD
Creador de identidades User (Usuario) Organización
Nombre de usuario y contraseña únicos para todos los recursos de trabajo No
Control de complejidad de & la duración de la contraseña User (Usuario) Organización
Azure DevOps límites de pertenencia Cualquier 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 2 fases User (Usuario) Organización
Acceso condicional basado en dispositivos No Organización

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

Requerir la autenticación en dos fases.

En algunos casos, 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 Windows portátil o de escritorio. BitLocker cifra toda la unidad en la que 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 se encuentra en manos equivocadas, BitLocker impide el acceso no autorizado de copias locales de datos desde 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 la 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. Por ejemplo, todas las comunicaciones se envían a través de HTTPS y hay requisitos de complejidad de la contraseña. No obstante, su organización debe evaluar si se requieren directivas adicionales para cumplir los requisitos de seguridad del proyecto. Puede deshabilitar las credenciales de autenticación alternativas por completo si decide que no cumple los requisitos de seguridad de su organización. Para más información, consulte Cambio de las directivas de seguridad de conexión de aplicaciones para su organización.

Proteger el acceso a su organización

Azure AD permite a los administradores controlar el acceso a 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, la protección 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