Visão geral da proteção de dados

Artigo
04/19/2024

Azure DevOps Services

Azure DevOps Services é um aplicativo hospedado na nuvem para seus projetos de desenvolvimento, desde o planejamento até a implantação. Com base nos recursos locais, com mais serviços de nuvem, gerenciamos seu código-fonte, itens de trabalho, compilações e testes. O Azure DevOps usa a infraestrutura de PaaS (plataforma como serviço) e muitos serviços do Azure, incluindo SQL do Azure, para fornecer um serviço confiável e disponível globalmente para seus projetos de desenvolvimento.

Este artigo discute as etapas que a Microsoft executa para ajudar a manter seus projetos seguros, disponíveis, seguros e privados. Ele descreve o papel que você desempenha em manter seus projetos seguros e protegidos.

Este artigo destina-se a administradores de organizações e profissionais de TI que gerenciam seus ativos de projeto diariamente. É mais útil para indivíduos que já estão familiarizados com o Azure DevOps e querem saber mais sobre como a Microsoft protege os ativos armazenados no Azure DevOps.

Nosso compromisso

A Microsoft ajuda a garantir que seus projetos permaneçam seguros e seguros, sem exceção. Quando você armazena seus projetos no Azure DevOps, eles se beneficiam de várias camadas de tecnologias de segurança e governança, práticas operacionais e políticas de conformidade. Aplicamos privacidade e integridade de dados em repouso e em trânsito.

As ameaças que você enfrenta estão em quatro categorias básicas: disponibilidade de dados, disponibilidade de serviço, segurança de serviço e privacidade de dados. Este artigo explora ameaças específicas dentro de cada categoria e explica o que o Azure DevOps faz para resolvê-las. O artigo começa descrevendo como os dados são armazenados e como o Azure DevOps gerencia o acesso aos seus dados.

A proteção de dados requer o envolvimento ativo de administradores e usuários que saibam quais medidas tomar para proteger seus ativos contra divulgação e adulteração não autorizadas. Seja explícito ao conceder permissões a pontos de acesso de usuário, para que apenas as pessoas certas acessem dados no Azure DevOps.

Você deve considerar que todos os dados estão potencialmente em risco, não importa onde estejam ou como estejam sendo usados. Essa instrução é verdadeira tanto para dados armazenados na nuvem quanto para dados armazenados em um datacenter privado. É importante classificar seus dados, sua sensibilidade e risco, e os danos que eles podem causar se forem comprometidos. Além disso, categorize seus dados em relação a uma política geral de gerenciamento de segurança das informações.

Criado no Azure

Diagrama da arquitetura de alto nível do Azure DevOps.

Hospedamos o Azure DevOps inteiramente nos datacenters do Azure. O Azure DevOps usa muitos serviços principais do Azure, incluindo computação, armazenamento, rede, SQL do Azure, gerenciamento de identidade e acesso e Barramento de Serviço do Azure.

O Azure DevOps usa o Armazenamento do Microsoft Azure como o repositório primário para metadados de serviço e dados do cliente. Dependendo do tipo de dados e dos requisitos de armazenamento e recuperação, o Azure DevOps usa o Armazenamento de Blobs do Azure e o armazenamento do Banco de Dados SQL do Azure.

Para ajudá-lo a entender a abordagem dos Serviços de DevOps do Azure para a proteção de dados, aqui estão alguns detalhes sobre os serviços de armazenamento:

Armazenamento de Blobs do Azure armazena grandes partes de dados não estruturados. Todos os projetos utilizam este serviço. Os dados incluem informações potencialmente confidenciais ou privadas, como o conteúdo de arquivos de origem e anexos de itens de trabalho. Para a maioria dos projetos, a maioria do armazenamento em uso é esse tipo de armazenamento de blob não estruturado.
O Banco de Dados SQL do Azure armazena os aspectos estruturados e transacionais de sua organização, incluindo metadados do projeto, o histórico de controle de origem versionado e detalhes de itens de trabalho. O armazenamento de banco de dados oferece acesso rápido aos elementos importantes do seu projeto. Ele fornece índices no armazenamento de blob para procurar arquivos e anexos.

Os administradores podem gerenciar o acesso aos recursos concedendo ou restringindo permissões em identidades ou grupos de usuários. O Azure DevOps usa autenticação federada de identidades de usuário por meio da ID do Microsoft Entra e contas da Microsoft.

Durante a autenticação, o usuário é roteado para o provedor de autenticação, onde fornece suas credenciais. Depois que o provedor de autenticação verifica as credenciais do usuário, o Azure DevOps emite um cookie de autenticação para o usuário. Esse cookie permite que o usuário permaneça autenticado no Azure DevOps.

Dessa forma, as informações de credencial do usuário nunca são compartilhadas diretamente com o Azure DevOps. Para cada recurso de DevOps do Azure que o usuário tenta acessar, a validação das permissões é baseada nas permissões explícitas do usuário e nas permissões que o usuário herdou por meio da associação ao grupo.

Os administradores podem usar controles de acesso para ajudar a proteger o acesso à organização, coleções de projetos, projetos de equipe e dados e funcionalidades com escopo de equipe. Os administradores também podem usar controles de acesso para ativos específicos, como pastas para controle de versão e caminhos de área para itens de trabalho.

Disponibilidade de dados

O Azure DevOps usa muitos recursos de Armazenamento do Azure para ajudar a garantir a disponibilidade de dados se houver uma falha de hardware, interrupção de serviço ou desastre regional. Além disso, a equipe de DevOps do Azure segue procedimentos para ajudar a proteger os dados contra exclusão acidental ou mal-intencionada.

Redundância de dados

Para ajudar a proteger dados durante falhas de hardware ou serviço, o Armazenamento do Azure replica geograficamente os dados do cliente entre duas regiões na mesma localização geográfica. Por exemplo, o Armazenamento do Azure pode replicar dados geograficamente entre o Norte e o Oeste da Europa ou entre o Norte e o Sul dos Estados Unidos.

Para o Armazenamento de Blobs do Azure, os dados do cliente são replicados três vezes em uma única região. Os dados do cliente são replicados de forma assíncrona para uma segunda região na mesma localização geográfica. Dessa forma, o Azure sempre mantém o equivalente a seis cópias de seus dados.

Ter várias cópias permite que você faça failover para uma região separada se houver uma grande interrupção ou desastre, além de ter redundância local para falhas de hardware dentro de uma região. Para SQL do Azure armazenamento de banco de dados, os backups diários serão mantidos fora do local se houver um desastre regional.

Em relação à redundância de dados e ao failover:

Há um delta inerente, medido em minutos, quando a Microsoft replica seus dados entre a região primária e secundária.
O failover para a região secundária é uma decisão que a Microsoft deve tomar centralmente, pois afeta todos os clientes em uma unidade de escala específica. Exceto em circunstâncias extremas, a Microsoft opta por evitar o failover para que os dados do cliente não sejam perdidos.
O Azure DevOps oferece um contrato de nível de serviço (SLA) de 99,9% de tempo de atividade. O Azure DevOps reembolsa uma parte das cobranças mensais se perder esse SLA em um mês específico.
Como há apenas uma região no Brasil, os dados de clientes no Brasil são replicados para a região Centro-Sul dos EUA para fins de recuperação de desastres.

Erros acontecem

Para proteger contra perda acidental de dados, a Microsoft emprega backups point-in-time para blobs armazenados no Armazenamento de Blobs do Azure e bancos de dados no Banco de Dados SQL do Azure. Cada conta de armazenamento mantém uma cópia separada de todos os blobs, com as alterações sendo anexadas aos dados existentes. Esses backups são imutáveis, eliminando a necessidade de reescrever qualquer armazenamento existente durante os procedimentos de backup.

O Banco de Dados SQL do Azure inclui recursos de backup padrão, que são utilizados pelo Azure DevOps. Seus dados são retidos por 28 dias, com esses backups também sendo replicados em uma região emparelhada para facilitar a recuperação durante uma interrupção regional.

Você pode recuperar organizações ou projetos excluídos dentro da janela de 28 dias após a exclusão. Mas, uma vez decorrido esse período de tempo, essas entidades são excluídas permanentemente e não podem ser restauradas. Embora esses backups sirvam como um componente crucial para a recuperação de desastres, é essencial que os clientes pratiquem estratégias apropriadas de gerenciamento e backup de dados para garantir a proteção abrangente de seus dados.

Importante

A exclusão acidental aqui se refere a cenários que surgem como resultado de um incidente em nossos serviços. Ele não inclui a exclusão acidental de ativos pelos clientes (por exemplo, repositórios, itens de trabalho, anexos ou artefatos).

Não oferecemos suporte à restauração de ativos que os clientes excluem acidentalmente. Esses backups destinam-se apenas à continuidade de negócios e para ajudar na recuperação de cenários de interrupção ou desastre.

A prática é crítica

Ter vários backups de seus dados é bom, mas sem prática, a restauração pode ser imprevisível. As pessoas dizem que "backups nunca falham; as restaurações sim." Embora a afirmação seja tecnicamente incorreta, o sentimento está certo.

A Microsoft pratica regularmente a restauração de conjuntos de dados a partir do backup. Testamos regularmente o armazenamento com redundância geográfica a partir do Azure. Há muitas combinações de cenários de desastre e corrupção de dados. Continuamos a planejar e executar novos testes para esses cenários regularmente.

Disponibilidade do serviço

O Azure DevOps oferece proteções de DDoS (negação de serviço) distribuídas e resposta ao vivo do site para ajudar a garantir que você tenha acesso à sua organização e ativos associados.

Proteções contra DDoS

Em alguns casos, um ataque de DDoS mal-intencionado pode afetar a disponibilidade do serviço. O Azure tem um sistema de defesa DDoS que ajuda a evitar ataques contra nosso serviço. Ele usa técnicas padrão de detecção e mitigação, como cookies SYN, limitação de taxa e limites de conexão. O sistema foi projetado para resistir a ataques não apenas de fora, mas também de dentro do Azure.

Para ataques específicos de aplicativos que podem penetrar nos sistemas de defesa do Azure, o Azure DevOps estabelece cotas e limitação em nível de aplicativo e de organização. Essa prática ajuda a evitar qualquer uso excessivo de recursos de serviço chave durante um ataque ou uso indevido acidental de recursos.

Resposta ao vivo do site

Em circunstâncias raras, você pode exigir uma resposta ao vivo do site para um problema com a disponibilidade do serviço. Temos uma equipe de operações que está constantemente disponível para identificar rapidamente o problema e engajar os recursos necessários da equipe de desenvolvimento.

Os recursos da equipe de desenvolvimento resolvem o problema. Eles também visam atualizar a página de status do serviço em poucos minutos após a detecção de um problema que afeta o serviço. Depois que os recursos da equipe de desenvolvimento resolvem um problema, eles identificam a causa raiz e rastreiam as alterações necessárias para evitar problemas semelhantes no futuro.

Os processos de DevOps do Azure para gerenciamento de site ao vivo se concentram em sua experiência e na integridade do serviço. Esses processos minimizam o tempo para detectar, responder e atenuar problemas. Todas as disciplinas de engenharia são envolvidas e responsáveis, de modo que as melhorias contínuas evoluem a partir da experiência direta. Os processos de monitoramento, diagnóstico, resiliência e garantia de qualidade melhoram com o tempo.

O gerenciamento de site ao vivo no Azure DevOps tem três faixas distintas: telemetria, gerenciamento de incidentes e revisão dinâmica do site. Aqui está o que essas faixas implicam:

Imagem do processo dos Serviços de DevOps do Azure para gerenciamento de site ao vivo.

A equipe de operações também monitora as métricas de disponibilidade para organizações individuais. Essas métricas fornecem insights sobre condições específicas que podem afetar apenas alguns de nossos clientes. As investigações sobre esses dados geralmente podem resultar em melhorias direcionadas para resolver problemas específicos do cliente. Em alguns casos, a Microsoft pode até entrar em contato com você diretamente para entender sua experiência e trabalhar com você para melhorar o serviço.

A Microsoft publica um SLA e fornece uma garantia financeira para garantir que cumprimos este contrato todos os meses. Para obter mais informações, consulte SLA para Azure DevOps.

Às vezes, as equipes ou dependências de parceiros têm incidentes que afetam o Azure DevOps. Todas as equipes de parceiros seguem abordagens semelhantes para identificar, resolver e aprender com essas interrupções de serviço.

Segurança do serviço

A segurança do serviço requer vigilância constante, desde técnicas adequadas de design e codificação até fatores operacionais. A Microsoft investe ativamente na prevenção de falhas de segurança e na detecção de violações. Se houver uma violação, a Microsoft usará planos de resposta de segurança para minimizar vazamento, perda ou corrupção de dados. Para obter mais informações, consulte Sobre segurança, autenticação e autorização.

Segurança desde a concepção

O Azure DevOps foi projetado para ser seguro. O Azure DevOps usa o Ciclo de Vida de Desenvolvimento de Segurança da Microsoft no centro de seu processo de desenvolvimento. O programa Microsoft Operational Security Assurance orienta os procedimentos de operação de nuvem no Azure DevOps.

A equipe de DevOps do Azure tem requisitos de treinamento anuais para todos os engenheiros e pessoal de operações. A equipe também patrocina reuniões informais organizadas por engenheiros da Microsoft. Depois que a equipe resolve um problema que surge em uma reunião, ela compartilha as lições aprendidas com outras equipes.

As metodologias a seguir especificam os requisitos de treinamento:

Modelagem de ameaças durante o design do serviço
Seguindo as práticas recomendadas para design e código
Verificando a segurança com ferramentas e testes padrão
Limitando o acesso a dados operacionais e de clientes
Lançamento de novos recursos por meio de um rígido processo de aprovação

Um serviço de nuvem é tão seguro quanto a plataforma de host. O Azure DevOps usa PaaS para grande parte de sua infraestrutura. O PaaS fornece automaticamente atualizações regulares para vulnerabilidades de segurança conhecidas.

As máquinas virtuais hospedadas no Azure usam a infraestrutura como serviço (IaaS), como para um serviço de compilação hospedado. Essas imagens recebem atualizações regulares para incluir os patches de segurança mais recentes disponíveis de Windows Update. O mesmo rigor de atualização se aplica a máquinas locais, incluindo aquelas usadas para implantação, monitoramento e relatórios.

A equipe do Azure DevOps realiza testes regulares de penetração focados em segurança do Azure DevOps. O teste de penetração tenta explorar os serviços de produção em tempo real e a infraestrutura do Azure DevOps usando as mesmas técnicas e mecanismos que invasores mal-intencionados usam. O objetivo é identificar vulnerabilidades, configurações, erros ou outras lacunas de segurança do mundo real em um processo controlado.

A equipe revisa os resultados desses testes para identificar outras áreas de melhoria e aumentar a qualidade dos sistemas preventivos e do treinamento. Você pode revisar os resultados dos recentes testes de penetração do Azure DevOps no Portal de Confiança de Serviço da Microsoft.

Segurança de credenciais

Usamos as práticas recomendadas do setor para armazenar suas credenciais no Azure DevOps. Saiba mais sobre o armazenamento de credenciais.

Relatando falhas de segurança

Se você acredita que seu teste de penetração revelou uma falha de segurança potencial relacionada ao serviço Azure DevOps, denuncie-a à Microsoft dentro de 24 horas. Para obter mais informações, consulte a página da Web da Microsoft para relatar uma vulnerabilidade de segurança do computador.

Importante

Embora não seja necessário notificar a Microsoft sobre atividades de teste de penetração, você deve estar em conformidade com as Regras de Engajamento do Teste de Penetração da Microsoft.

Programa de recompensas

O Azure DevOps participa do programa Microsoft Bug Bounty. Este programa recompensa os investigadores de segurança que nos reportam problemas e incentiva mais pessoas a ajudar a manter o Azure DevOps seguro. Para obter mais informações, consulte Programa de recompensa de DevOps do Microsoft Azure.

Como restringir o acesso

A Microsoft mantém um controle estrito sobre quem obtém acesso ao nosso ambiente de produção e aos dados do cliente. Concedemos acesso no nível de privilégio mínimo necessário e somente após a verificação das justificativas de um usuário. Se um membro da equipe precisar de acesso para resolver um problema urgente ou implantar uma alteração de configuração, ele deverá solicitar acesso just-in-time ao serviço de produção. O acesso é revogado assim que a situação é resolvida.

Rastreamos e monitoramos solicitações de acesso e aprovações em um sistema separado. Todo o acesso ao sistema se correlaciona com essas aprovações. Se detectarmos acesso não aprovado, alertamos a equipe de operações para investigar.

Usamos a autenticação de dois fatores para todo o acesso remoto do sistema. Se o nome de usuário e a senha de um de nossos desenvolvedores ou equipe de operações forem roubados, os dados permanecerão protegidos. Mais verificações de autenticação via cartão inteligente ou uma chamada telefônica para um número pré-aprovado devem ocorrer antes de permitirmos qualquer acesso remoto ao serviço.

Para gerenciar e manter o serviço, a Microsoft usa segredos como senhas RDP, certificados SSL e chaves de criptografia. Esses segredos são todos gerenciados, armazenados e transmitidos com segurança por meio do portal do Azure. Qualquer acesso a esses segredos requer permissão específica, que é registrada e gravada com segurança. Todos os segredos são girados em uma cadência regular, e podemos girá-los sob demanda se houver um evento de segurança.

A equipe de operações do Azure DevOps usa estações de trabalho de administrador protegidas para gerenciar o serviço. Esses computadores executam um número mínimo de aplicativos e operam em um ambiente segmentado logicamente.

Os membros da equipe de operações devem fornecer credenciais específicas com autenticação de dois fatores para acessar as estações de trabalho. Todo o acesso é monitorado e registrado com segurança. Para isolar o serviço de adulteração externa, não permitimos aplicativos como o Outlook e o Office, porque eles geralmente são alvos de spear phishing e outros tipos de ataques.

Proteção e resposta contra intrusões

Criptografamos dados via HTTPS e SSL para ajudar a garantir que eles não sejam interceptados ou modificados durante o trânsito entre você e o Azure DevOps. Os dados que armazenamos em seu nome no Azure DevOps são criptografados da seguinte maneira:

Os dados armazenados nos bancos de dados SQL do Azure são criptografados por meio de criptografia de dados transparente. Esse recurso ajuda a proteger contra atividades mal-intencionadas fazendo criptografia em tempo real do banco de dados, backups associados e arquivos de log de transações em repouso.
As conexões do Armazenamento de Blobs do Azure são criptografadas para ajudar a proteger seus dados em trânsito. Para dados em repouso armazenados no Armazenamento de Blobs do Azure, o Azure DevOps usa a criptografia do lado do serviço.

Observação

O Azure DevOps não é compatível com o FIPS (Federal Information Processing Standards) 140-2 ou 140-3.

A equipe de DevOps do Azure usa a infraestrutura do Azure para registrar e monitorar os principais aspectos do serviço. O registro e o monitoramento ajudam a garantir que as atividades dentro do serviço sejam legítimas e ajudam a detectar violações ou tentativas de violação.

Todas as atividades de implantação e administrador são registradas com segurança, assim como o acesso do operador ao armazenamento de produção. As informações de log são analisadas automaticamente e qualquer comportamento potencialmente mal-intencionado ou não autorizado gera alertas em tempo real.

Quando a equipe de DevOps do Azure identifica uma possível invasão ou vulnerabilidade de segurança de alta prioridade, ela tem um plano de resposta claro. Este plano descreve as partes responsáveis, as etapas necessárias para proteger os dados do cliente e instruções sobre como interagir com especialistas em segurança da Microsoft. A equipe também notifica os proprietários da organização se os dados foram divulgados ou corrompidos, para que eles possam tomar as medidas apropriadas para corrigir a situação.

Para ajudar a combater ameaças emergentes, o Azure DevOps emprega uma estratégia de violação presumida. Uma equipe altamente especializada de especialistas em segurança dentro da Microsoft assume o papel de adversários sofisticados. Essa equipe testa a detecção e a resposta de violações para medir com precisão a preparação e os impactos dos ataques do mundo real. Essa estratégia fortalece a detecção, a resposta e a defesa de ameaças do serviço. Ele também permite que a equipe valide e melhore a eficácia de todo o programa de segurança.

Proteção contra ataques de ransomware

O Azure DevOps usa controles do Azure para ajudar a prevenir, detectar e responder a um ataque de ransomware. Para obter mais informações sobre como o Azure ajuda a proteger os clientes contra ataques de ransomware, consulte Proteção contra ransomware no Azure.

Privacidade dos dados

Você deve ter confiança de que estamos lidando com seus dados adequadamente e para usos legítimos. Parte dessa garantia envolve restringir cuidadosamente o uso.

Regulamento Geral sobre a Proteção de Dados

O GdpR (Regulamento Geral sobre a Proteção de Dados) é a maior mudança nas leis de proteção de dados na Europa desde a introdução, em 1995, da Diretiva de Proteção de Dados da União Europeia (UE) 95/46/EC. Para obter mais informações sobre o GDPR, consulte a página de visão geral na Central de Confiabilidade da Microsoft.

Residência de dados e soberania

O Azure DevOps está disponível nas oito localizações geográficas a seguir em todo o mundo: Estados Unidos, Canadá, Europa, Reino Unido, Índia, Austrália, Ásia-Pacífico e Brasil. Por padrão, sua organização é atribuída ao local mais próximo. No entanto, você pode escolher um local diferente ao criar sua organização. Se você mudar de ideia mais tarde, poderá migrar a organização para um local diferente com a ajuda do suporte da Microsoft.

O Azure DevOps não move ou replica dados de clientes para fora do local escolhido. Em vez disso, seus dados são replicados geograficamente para uma segunda região dentro do mesmo local. A única exceção é o Brasil, que replica dados para a região Centro-Sul dos EUA para fins de recuperação de desastres.

Observação

Para compilações e versões executadas em agentes macOS fornecidos pela Microsoft, seus dados são transferidos para um datacenter do GitHub nos Estados Unidos.

Para saber mais, consulte Locais de dados para o Azure DevOps.

Acesso à aplicação da lei

Em alguns casos, terceiros, como entidades de aplicação da lei, podem entrar em contato com a Microsoft para obter acesso aos dados do cliente armazenados no Azure DevOps. Tentamos redirecionar as solicitações para o proprietário da organização para resolução. Quando uma ordem judicial obriga a Microsoft a divulgar dados de clientes a terceiros, a Microsoft faz um esforço razoável para notificar o proprietário da organização com antecedência, a menos que estejamos legalmente proibidos de fazê-lo.

Alguns clientes exigem o armazenamento de seus dados em uma localização geográfica específica para garantir uma jurisdição legal específica para quaisquer atividades de aplicação da lei. Todos os dados do cliente, como código-fonte, itens de trabalho, resultados de testes e espelhos com redundância geográfica e backups externos, são mantidos em um dos locais mencionados anteriormente.

Acesso da Microsoft

De tempos em tempos, os funcionários da Microsoft precisam obter acesso aos dados do cliente armazenados no Azure DevOps. Por precaução, todos os funcionários que têm (ou podem ter) acesso aos dados dos clientes devem passar por uma verificação de antecedentes que inclui condenações trabalhistas e criminais anteriores. Permitimos o acesso aos sistemas de produção somente quando há um incidente no local ativo ou outra atividade de manutenção aprovada, que é registrada e monitorada.

Como nem todos os dados em nosso sistema são tratados da mesma maneira, classificamos os dados nestes tipos:

Dados do cliente: o que você carrega no Azure DevOps.
Dados da organização: informações que você envia quando se inscreve ou administra sua organização.
Dados da Microsoft: informações necessárias ou coletadas por meio da operação do serviço.

Com base na classificação, controlamos cenários de uso, requisitos de localização geográfica, restrições de acesso e requisitos de retenção.

Uso promocional da Microsoft

Ocasionalmente, a Microsoft deseja entrar em contato com os clientes para informá-los sobre mais recursos e serviços que podem ser úteis. Como nem todos os clientes desejam ser contatados sobre essas ofertas, você pode aceitar e recusar as comunicações por email de marketing.

A Microsoft nunca usa dados do cliente para direcionar ofertas específicas para usuários ou organizações específicas. Em vez disso, usamos dados da organização e agregamos estatísticas de uso no nível da organização para determinar grupos que devem receber ofertas específicas.

Criando confiança

Você pode confiar em outros esforços que a Microsoft faz em nome do Azure DevOps. Esses esforços incluem políticas internas de adoção na Microsoft, o nível de transparência sobre o estado de nosso serviço e o progresso em direção ao recebimento da certificação de nossos sistemas para gerenciar a segurança da informação.

Adoção interna

O Teams em toda a Microsoft está adotando o Azure DevOps internamente. A equipe do Azure DevOps mudou-se para uma organização em 2014 e a usa extensivamente. Estabelecemos diretrizes para viabilizar os planos de adoção para outras equipes.

As equipes grandes se movem mais gradualmente do que as menores, por causa de seus investimentos em sistemas DevOps existentes. Para as equipes que se movem rapidamente, estabelecemos uma abordagem de classificação de projetos. Ele avalia a tolerância a riscos, com base nas características do projeto, para determinar se o projeto é apropriado para o Azure DevOps. Para equipes maiores, a adoção normalmente ocorre em fases, com mais planejamento.

Outros requisitos para projetos internos incluem associar a organização ao Microsoft Entra ID para garantir o ciclo de vida adequado da identidade do usuário e a complexidade da senha. Projetos mais sensíveis também exigem autenticação de dois fatores.

Certificações de conformidade

Você pode estar interessado em entender a avaliação de terceiros de nossos procedimentos de segurança de dados. O Azure DevOps obteve as seguintes certificações:

ISO 27001:2013
ISO 27018:2019
Certificação ISO 26262:2023
Lei HIPAA (Health Insurance Portability and Accountability Act) dos EUA
Acordo de Associado Comercial (BAA)
Cláusulas Modelo da UE
Controles de Sistema e Organização (SOC) 1 Tipo 2
SOC 2 Tipo 2
Alemanha C5
Austrália IRAP
ENS-Espanha

A auditoria do SOC para o Azure DevOps abrange controles de segurança, disponibilidade, integridade de processamento e confidencialidade de dados. Os relatórios do SOC para o Azure DevOps estão disponíveis por meio do Portal de Confiança do Serviço da Microsoft.

O Questionário da Iniciativa de Avaliação de Consenso (CAIQ) ajuda as organizações a avaliar as práticas e os recursos de segurança dos provedores de serviços de nuvem. Em alinhamento com nosso compromisso com a segurança e a transparência, concluímos recentemente a avaliação do CAIQ para o Azure DevOps. Convidamos você a revisar o relatório completo no Portal de Confiança de Serviço da Microsoft.

Etapas que você pode seguir

A proteção de dados adequada requer envolvimento ativo de você, de seus administradores e de seus usuários. Os dados do projeto armazenados no Azure DevOps são tão seguros quanto os pontos de acesso do usuário. Corresponder o nível de restrição de permissão e granularidade para essas organizações com o nível de confidencialidade do seu projeto.

Classificar os dados

A primeira etapa é classificar seus dados. Classifique os dados com base na sensibilidade e no horizonte de risco, juntamente com os danos que podem ocorrer se comprometidos. Muitas empresas têm métodos de classificação existentes que podem reutilizar quando os projetos mudam para o Azure DevOps. Para obter mais informações, você pode baixar a classificação de dados para preparação para nuvem do Microsoft Trustworthy Computing.

Adote o Microsoft Entra ID

Use a ID do Microsoft Entra para gerenciar o acesso da sua organização ao Azure DevOps. O Microsoft Entra ID fornece outra maneira de melhorar a segurança das credenciais dos usuários.

O Microsoft Entra ID permite que o departamento de TI gerencie sua política de acesso de usuário, complexidade de senha, atualizações de senha e expiração quando os usuários deixam sua organização. Por meio da federação do Active Directory, você pode vincular diretamente a ID do Microsoft Entra ao diretório central da sua organização, para que você tenha apenas um local para gerenciar esses detalhes para sua empresa.

A tabela a seguir compara as características da conta da Microsoft e do Microsoft Entra em relação ao acesso ao Azure DevOps:

Propriedade	Conta Microsoft	Microsoft Entra ID
Criador de identidade	Usuário	Organização
Nome de usuário e senha únicos para todos os ativos de trabalho	Não	Sim
Controle de tempo de vida e complexidade de senhas	Usuário	Organização
Limites de associação do Azure DevOps	Qualquer conta da Microsoft	Diretório da organização
Identidade rastreável	No	Sim
Organização e propriedade de PI	Claro	Organização
Registro de autenticação de dois fatores	Usuário	Organização
Acesso condicional com base em dispositivo	No	Organização

Saiba mais sobre como configurar esse suporte para sua organização.

Exigir a autenticação de dois fatores

Talvez você queira restringir o acesso à sua organização exigindo mais de um fator para entrar. Você pode exigir vários fatores usando o Microsoft Entra ID. Por exemplo, você pode exigir a autenticação de telefone, além de um nome de usuário e senha, para todas as solicitações de autenticação.

Usar o BitLocker

Para projetos confidenciais, você pode usar o BitLocker em seu laptop windows ou computador desktop. O BitLocker criptografa toda a unidade na qual o Windows e seus dados residem. Quando o BitLocker está habilitado, ele criptografa automaticamente qualquer arquivo que você salvar nessa unidade. Se o computador cair em mãos erradas, o BitLocker impedirá o acesso não autorizado de cópias locais de dados de seus projetos.

Limitar o uso de credenciais de autenticação alternativas

O mecanismo de autenticação padrão para ferramentas relacionadas ao Git é a autenticação alternativa (às vezes chamada de autenticação básica). Esse mecanismo permite que um usuário configure um nome de usuário e senha alternativos para uso durante operações de linha de comando do Git. O usuário pode usar essa combinação de nome de usuário/senha para acessar quaisquer outros dados para os quais esse usuário tenha permissões. Por sua natureza, as credenciais de autenticação alternativas são menos seguras do que a autenticação federada padrão.

Você ainda pode fazer escolhas para aumentar a segurança. Toda a comunicação é enviada por HTTPS e há requisitos de complexidade de senha. Sua organização deve continuar a avaliar se precisa de mais políticas para atender aos requisitos de segurança de seus projetos.

Você pode desabilitar credenciais de autenticação alternativas se decidir que elas não atendem aos requisitos de segurança da sua organização. Para obter mais informações, consulte Alterar a conexão do aplicativo e as diretivas de segurança para sua organização.

Proteger o acesso à sua organização

Os administradores podem usar a ID do Microsoft Entra para controlar o acesso a recursos e aplicativos do Azure, como o Azure DevOps. Com o controle de acesso condicional em vigor, o Microsoft Entra ID verifica as condições específicas definidas para um usuário acessar um aplicativo. Depois que o usuário atende aos requisitos de acesso, ele é autenticado e pode acessar o aplicativo.

O Azure DevOps dá suporte à imposição de determinados tipos de políticas de acesso condicional (por exemplo, isolamento ip) para mecanismos de autenticação personalizados do Azure DevOps. Esses mecanismos incluem tokens de acesso pessoal, autenticação alternativa, chaves OAuth e Secure Shell (SSH). Se seus usuários acessarem o Azure DevOps por meio de um cliente de terceiros, somente as políticas baseadas em IPv4 serão respeitadas.