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é hace Azure DevOps 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
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 Almacenamiento de base de datos 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 ha 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 de 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 hay 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 almacenamiento de base de datos, 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 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 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 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 recupere de una interrupción regional.
Una protección adicional es que los clientes pueden recuperar sus organizaciones o proyectos eliminados durante un máximo de 28 días después de la eliminación. Las organizaciones y proyectos eliminados se encuentran en una fase de "eliminación temporal" durante 28 días, lo que permite a los clientes recuperarse según sea necesario. Después de 28 días se eliminan permanentemente y no se pueden restaurar.
Importante
La eliminación accidental aquí hace referencia a escenarios que surgen como resultado de un incidente en nuestros servicios y no incluye la eliminación accidental de recursos (por ejemplo, repositorios, elementos de trabajo, datos adjuntos, artefactos) por parte de los clientes. No se admite la restauración de recursos eliminados accidentalmente por los clientes, ya que estas copias de seguridad están pensadas para la continuidad empresarial y solo ayuda a la recuperación de escenarios de interrupción o desastre.
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. 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 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.
Los procesos de administración de sitios activos de Azure DevOps se centran en la experiencia y el estado del servicio. Estos procesos minimizan el tiempo de detección, respuesta y mitigación de problemas. Todas las disciplinas de ingeniería están implicadas y son responsables, por lo que hay mejoras continuas que evolucionan 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 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 (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 obtener 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.
- Siguiendo los procedimientos recomendados de diseño y código.
- Comprobación de la seguridad con herramientas y pruebas estándar.
- Limitar el acceso a los datos operativos y de los clientes.
- Gating rollout of new features through a rigid approval process.
El equipo de Azure DevOps tiene requisitos de entrenamiento anuales para todos los ingenieros y 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 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 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 del mundo real, 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 de Azure DevOps en el Portal de confianza de servicios.
Seguridad de credenciales
Las credenciales de Azure DevOps se almacenan mediante procedimientos recomendados del sector. Obtenga más información sobre el almacenamiento de credenciales.
Informe 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, notifiquelo 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 proteger Azure DevOps. Para más información, consulte el Programa de recompensas de 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. El acceso se concede en el nivel de privilegio mínimo necesario 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 el 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 el nombre de usuario y la contraseña de uno de nuestros desarrolladores o personal de operaciones se robaron, 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 que se permita el 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 se registra de forma segura. Para aislar el servicio de alteraciones externas, no se permiten aplicaciones como Outlook y Office, ya que a menudo son objetivos de suplantación de identidad (phishing) 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 durante el 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 detecten 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. Se generan alertas en tiempo real 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 intrusiones o de alta prioridad, 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 se han divulgado o dañado, 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 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.
Introducción a la protección contra ataques de ransomware
Azure DevOps se basa en Azure y usa los controles de la mejor clase de Azure para ayudar a evitar, detectar y responder a un ataque de ransomware. Para más información sobre cómo Azure protege a los clientes frente a ataques de ransomware, consulte Defensas de Azure para ataques de ransomware.
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 correctamente 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 zonas 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 su organización a otra ubicación geográfica, con la ayuda del soporte técnico de Microsoft.
Azure DevOps no mueve ni replica datos de 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 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 macOS proporcionados por Microsoft, los datos se transferirán a un centro de datos de GitHub en estados Unidos.
Para más información, consulte Ubicación de datos de Azure DevOps.
Acceso al cumplimiento 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 la resolución. Cuando se ve obligado por orden judicial a revelar datos de clientes a un tercero, 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 de los clientes, 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.
Acceso a Microsoft
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. Solo se permite el acceso a los sistemas de producción 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 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 clientes para dirigirse a ofertas específicas para usuarios u 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 estar seguro en otros esfuerzos que Microsoft realiza en nombre de Azure DevOps. Estos esfuerzos incluyen directivas de adopción interna 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
Los equipos de Microsoft están adoptando Azure DevOps internamente. El equipo de 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 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 planificación.
Entre los requisitos adicionales para los proyectos internos se incluye la asociación de la organización con Azure AD para garantizar la complejidad adecuada del ciclo de vida de la identidad de usuario y la complejidad de las contraseñas. 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
- 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 usuarios. Los datos del proyecto almacenados en Azure DevOps solo son tan seguros como los puntos de acceso del usuario final. Coincide con el nivel de estricto 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 los daños que pueden producirse si se ponen 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 su organización a Azure DevOps. Azure AD proporciona otra manera de mejorar la seguridad de las credenciales de los usuarios. Azure AD permite al departamento de TI administrar su directiva de acceso de usuario final, complejidad de contraseñas, actualizaciones de contraseñas y expiración si el usuario deja 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 con respecto al acceso a Azure DevOps:
| Propiedades | Cuenta Microsoft | Azure AD |
|---|---|---|
| Creador de identidades | Usuario | Organización |
| Nombre de usuario único/contraseña para todos los recursos de trabajo | No | Sí |
| Control de complejidad de la duración de & la contraseña | Usuario | Organización |
| Límites de pertenencia a Azure DevOps | Cualquier cuenta de Microsoft (MSA) | Directorio de la organización |
| Identidad rastreable | No | Sí |
| 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.
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 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, barreras IP) para mecanismos de autenticación personalizados de Azure DevOps. 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).