Descrição geral da proteção de dados
Serviços de DevOps do Azure
Os Serviços de DevOps do Azure são 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 na nuvem, gerenciamos seu código-fonte, itens de trabalho, compilações e testes. O Azure DevOps usa a infraestrutura de plataforma como serviço (PaaS) e muitos serviços do Azure, incluindo o Azure SQL, para fornecer um serviço confiável e disponível globalmente para seus projetos de desenvolvimento.
Este artigo descreve as etapas que a Microsoft executa para ajudar a manter seus projetos seguros, disponíveis, protegidos 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 ativos armazenados no Azure DevOps.
O nosso compromisso
A Microsoft ajuda a garantir que seus projetos permaneçam seguros e protegidos, 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. Asseguramos a privacidade e a integridade dos dados tanto em repouso como 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 todos os dados como potencialmente em risco, não importa onde estejam ou como estejam sendo usados. Esta afirmação é válida tanto para os dados armazenados na nuvem quanto para os 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 da segurança das informações.
Criado no Azure
Hospedamos o Azure DevOps inteiramente em 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 utiliza o Armazenamento do Azure como o repositório principal para metadados do 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 à proteção de dados, aqui estão alguns antecedentes sobre os serviços de armazenamento:
O Armazenamento de Blobs do Azure armazena grandes blocos de dados não estruturados. Todos os projetos utilizam este serviço. Os dados incluem informações potencialmente confidenciais ou privadas, como os conteúdos dos ficheiros de origem e os 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 aspetos estruturados e transacionais da 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 a autenticação federada de identidades de usuário por meio do Microsoft Entra ID e das 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. Este cookie permite que o utilizador permaneça autenticado no Azure DevOps.
Dessa forma, as informações de credenciais 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 de 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 dos dados
O Azure DevOps usa muitos recursos do Armazenamento do Azure para ajudar a garantir a disponibilidade dos dados se houver uma falha de hardware, interrupção do 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 os 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 geograficamente dados 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. Como tal, o Azure mantém sempre o equivalente a seis cópias dos 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 em uma região. Para o armazenamento do Banco de Dados SQL do Azure, os backups diários são mantidos externamente se houver um desastre regional.
Em relação à redundância e failover de dados:
- 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, porque 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 dos clientes no Brasil são replicados para a região Centro-Sul dos EUA para fins de recuperação de desastres.
Erros acontecem
Para se 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 acrescentadas 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 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 eliminação acidental aqui refere-se a cenários que surgem como resultado de um incidente nos 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 suportamos a restauração de ativos que os clientes excluem acidentalmente. Esses backups destinam-se apenas à continuidade dos negócios e para ajudar na recuperação de cenários de interrupção ou desastre.
- Em casos raros, nosso processo de exclusão pode levar até 70 dias devido a novas tentativas de back-end e à necessidade de excluir dados de várias fontes.
A prática é fundamental
Ter vários backups de seus dados é bom, mas sem prática, a restauração pode ser imprevisível. As pessoas dizem que "os backups nunca falham; as restaurações fazem." 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 do Azure. Há muitas combinações de cenários de desastre e corrupção de dados. Continuamos a planear e a executar novos testes para estes cenários regularmente.
Disponibilidade do serviço
O Azure DevOps oferece proteções distribuídas de negação de serviço (DDoS) e resposta de site ao vivo para ajudar a garantir que você tenha acesso à sua organização e aos ativos associados.
Proteções contra DDoS
Em alguns casos, um ataque DDoS mal-intencionado pode afetar a disponibilidade do serviço. O Azure tem um sistema de defesa contra DDoS que ajuda a prevenir ataques contra o nosso serviço. Ele usa técnicas padrão de deteçã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 do exterior, 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ções no nível do aplicativo e da organização. Essa prática ajuda a evitar qualquer uso excessivo de recursos de serviço essenciais durante um ataque ou uso indevido acidental de recursos.
Resposta do site ao vivo
Em circunstâncias raras, você pode precisar de uma resposta do site ao vivo 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 envolver 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 deteçã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 sites ao vivo se concentram em sua experiência e na integridade do serviço. Esses processos minimizam o tempo para detetar, responder e mitigar problemas. Todas as disciplinas de engenharia estão envolvidas e são 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 de site ao vivo. Veja o que essas faixas implicam:
A equipe de operações também monitora as métricas de disponibilidade para organizações individuais. Essas métricas fornecem informações 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 diretamente com você 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 deteção de violações. Se houver uma violação, a Microsoft usa planos de resposta de segurança para minimizar o vazamento, a perda ou a corrupção de dados. Para obter mais informações, consulte Sobre segurança, autenticação e autorização.
Segurança desde a conceçã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 na 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 seguintes metodologias especificam os requisitos de formação:
- Modelagem de ameaças durante o projeto de serviço
- Seguindo as práticas recomendadas para design e código
- Verificando a segurança com ferramentas e testes padrão
- Limitar o acesso aos dados operacionais e dos clientes
- Limitação da implementação de novas funcionalidades através de um processo de aprovação rígido
Um serviço de nuvem é tão seguro quanto a plataforma 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 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 no Windows Update. O mesmo rigor de atualização se aplica a máquinas locais, incluindo aquelas usadas para implantação, monitoramento e emissão de relatórios.
A equipe de DevOps do Azure realiza testes de penetração regulares e focados em segurança do Azure DevOps. O teste de penetração tenta explorar os serviços de produção ao vivo e a infraestrutura do Azure DevOps usando as mesmas técnicas e mecanismos que os 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 equipa analisa os resultados destes testes para identificar outras áreas de melhoria e aumentar a qualidade dos sistemas preventivos e da formação. Você pode revisar os resultados dos testes de penetração recentes do Azure DevOps no Portal de Confiança de Serviços da Microsoft.
Segurança de credenciais
A Microsoft está empenhada em garantir que os seus projetos permaneçam seguros e protegidos, sem exceção. No Azure DevOps, seus projetos se beneficiam de várias camadas de tecnologias de segurança e governança, práticas operacionais e políticas de conformidade. Asseguramos a privacidade e a integridade dos dados tanto em repouso como em trânsito. Além disso, aderimos às seguintes práticas com relação às credenciais ou segredos que o Azure DevOps armazena. Para saber mais sobre como escolher o mecanismo de autenticação correto, consulte Orientações para autenticação.
Importante
O Azure DevOps não dá suporte à autenticação de Credenciais Alternativas. Se você ainda estiver usando Credenciais Alternativas, recomendamos que mude para um método de autenticação mais seguro.
Tokens de acesso pessoal (PATs)
- Armazenamos um hash do PAT.
- Os PATs brutos geram na memória no lado do servidor. 32 bytes gerados aleatoriamente através do RNGCryptoServiceProvider e são compartilhados com o chamador como uma cadeia de caracteres codificada em base 32. Este valor NÃO é armazenado.
- O hash PAT gera na memória no lado do servidor como um HMACSHA256Hash da PAT bruta usando uma chave de assinatura simétrica de 64 bytes armazenada em nosso cofre de chaves.
- O hash é armazenado em nosso banco de dados.
Chaves de shell seguro (SSH)
- Armazenamos um hash do ID da organização anexa e da chave pública SSH.
- As chaves públicas brutas são fornecidas diretamente pelo chamador através de SSL.
- O hash SSH gera na memória no lado do servidor como um HMACSHA256Hash do ID da organização e da chave pública bruta usando uma chave de assinatura simétrica de 64 bytes armazenada em nosso cofre de chaves.
- O hash é armazenado em nosso banco de dados.
Credenciais OAuth (JWTs)
- As credenciais OAuth são emitidas como tokens da web JSON (JWTs) totalmente autodescritivos e não são armazenadas em nosso serviço.
- As reclamações em JWTs emitidas e apresentadas ao nosso serviço são validadas usando um certificado armazenado em nosso cofre de chaves.
Comunicar falhas de segurança
Se acredita que o seu teste de penetração revelou uma potencial falha de segurança relacionada com o serviço Azure DevOps, comunique-a à Microsoft no prazo de 24 horas. Para obter mais informações, consulte a página da Microsoft para relatar uma vulnerabilidade de segurança do computador.
Importante
Embora não seja necessário notificar a Microsoft sobre as atividades de teste de penetração, você deve estar em conformidade com as Regras de Contrato de 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 comunicam problemas e incentiva mais pessoas a ajudar a manter o Azure DevOps seguro. Para obter mais informações, consulte Microsoft Azure DevOps Bounty Program.
Limitar o acesso
A Microsoft mantém um controlo rigoroso sobre quem obtém acesso ao nosso ambiente de produção e aos dados dos clientes. Concedemos acesso ao nível de menor privilégio exigido e somente após 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 está correlacionado com essas aprovações. Se detetarmos acesso não aprovado, alertamos a equipe de operações para investigar.
Usamos autenticação de dois fatores para todo o acesso remoto ao 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 registrada com segurança. Todos os segredos são alternados 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 reforçadas para gerenciar o serviço. Essas máquinas executam um número mínimo de aplicativos e operam em um ambiente logicamente segmentado.
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. Todos os acessos são monitorizados e registados de forma segura. Para isolar o serviço de adulterações externas, 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 a intrusões
Criptografamos dados via HTTPS e SSL para ajudar a garantir que eles não sejam intercetados 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 maliciosas 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 criptografia do lado do serviço.
A equipe do Azure DevOps usa a infraestrutura do Azure para registrar e monitorar os principais aspetos do serviço. O registro e o monitoramento ajudam a garantir que as atividades dentro do serviço sejam legítimas e ajudam a detetar 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 intrusã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 remediar a situação.
Para ajudar a combater ameaças emergentes, o Azure DevOps emprega uma estratégia de violação assumida. Uma equipe altamente especializada de especialistas em segurança dentro da Microsoft assume o papel de adversários sofisticados. Esta equipa testa a deteção e resposta a violações, para medir com precisão a prontidão e os impactos de ataques do mundo real. Essa estratégia fortalece a deteçã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, detetar 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.
Data privacy (Privacidade dos dados)
Deve ter a certeza de que estamos a tratar os seus dados de forma adequada e para utilizações legítimas. Parte dessa garantia envolve restringir cuidadosamente o uso.
Regulamento Geral sobre a Proteção de Dados
O Regulamento Geral sobre a Proteção de Dados (RGPD) é a maior alteração nas leis de proteção de dados na Europa desde a introdução, em 1995, da Diretiva de Proteção de Dados 95/46/CE da União Europeia (UE). Para obter mais informações sobre o GDPR, consulte a página de visão geral na Central de Confiabilidade da Microsoft.
Residência e soberania dos dados
O Azure DevOps está disponível nos seguintes oito locais geográficos 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 mudar de ideias mais tarde, pode migrar a organização para uma localização diferente com a ajuda do suporte da Microsoft.
O Azure DevOps não move nem replica dados de clientes 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.
Nota
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 obter mais informações, consulte Locais de dados para o Azure DevOps.
Acesso das autoridades policiais
Em alguns casos, terceiros, como entidades policiais, 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 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 à Microsoft
De tempos em tempos, os funcionários da Microsoft precisam obter acesso aos dados do cliente armazenados no Azure DevOps. Como precaução, todos os funcionários que têm (ou podem ter) acesso aos dados do cliente devem passar por uma verificação de antecedentes que inclui empregos anteriores e condenações criminais. Permitimos o acesso aos sistemas de produção apenas quando há um incidente no local ativo ou outra atividade de manutenção aprovada, que é registrada e monitorada.
Como nem todos os dados dentro do nosso sistema são tratados da mesma forma, 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 através da operação do serviço.
Com base na classificação, controlamos cenários de uso, requisitos de geolocalização, 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 querem ser contatados sobre essas ofertas, você pode optar por receber e não receber comunicações por e-mail de marketing.
A Microsoft nunca usa dados de clientes para direcionar ofertas específicas para usuários ou organizações específicas. Em vez disso, usamos dados da organização e estatísticas de uso agregadas no nível da organização para determinar os grupos que devem receber ofertas específicas.
Reforçar a 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
As equipes da Microsoft estão adotando o Azure DevOps internamente. A equipe de DevOps do Azure se mudou 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 de DevOps existentes. Para equipes que se movem rapidamente, estabelecemos uma abordagem de classificação de projetos. Ele avalia a tolerância ao risco, 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.
Mais 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 confidenciais também exigem autenticação de dois fatores.
Certificações de conformidade
Poderá estar interessado em compreender a avaliação por terceiros dos nossos procedimentos de segurança de dados. O Azure DevOps obteve as seguintes certificações:
- ISO 27001:2013
- Certificação ISO 27018:2019
- Certificação ISO 26262:2023
- HIPAA (Health Insurance Portability and Accountability Act).
- Acordo de Associado Comercial (BAA)
- Cláusulas do Modelo da UE
- Controles de Sistema e Organização (SOC) 1 Tipo 2
- SOC 2 Tipo 2
- Alemanha C5
- Australia IRAP
- ENS-Espanha
A auditoria SOC para Azure DevOps abrange controles de segurança de dados, disponibilidade, integridade de processamento e confidencialidade. Os relatórios SOC para o Azure DevOps estão disponíveis por meio do Portal de Confiança de Serviços da Microsoft.
O Consensus Assessment Initiative Questionnaire (CAIQ) ajuda as organizações a avaliar as práticas e capacidades de segurança dos fornecedores de serviços na nuvem. Em alinhamento com nosso compromisso com a segurança e a transparência, concluímos recentemente a avaliação CAIQ para o Azure DevOps. Convidamo-lo a rever o relatório completo no Portal de Confiança de Serviços da Microsoft.
Passos que pode dar
Uma proteção de dados adequada requer o 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. Combine o nível de rigor e granularidade de permissão para essas organizações com o nível de sensibilidade do seu projeto.
Classificar os dados
O primeiro passo é classificar os 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 são movidos 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 seus usuários.
O Microsoft Entra ID permite que seu 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 saem de sua organização. Por meio da federação do Ative Directory, você pode vincular diretamente o Microsoft Entra ID 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:
| Property | Conta da Microsoft | Microsoft Entra ID |
|---|---|---|
| Criador de identidade | User | Organization |
| Nome de usuário e senha únicos para todos os ativos de trabalho | Não | Sim |
| Controle de tempo de vida e complexidade da senha | User | Organization |
| Limites de associação do Azure DevOps | Qualquer conta Microsoft | Diretório da organização |
| Identidade rastreável | Não | Sim |
| Organização e propriedade de IP | Obscuro | Organization |
| Inscrição de autenticação de dois fatores | User | Organization |
| Acesso condicional baseado nos dispositivos | Não | Organization |
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 autenticação por 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 ou computador desktop Windows. O BitLocker encripta toda a unidade em que o Windows e os seus dados residem. Quando o BitLocker está habilitado, ele criptografa automaticamente qualquer arquivo salvo nessa unidade. Se o seu computador cair nas mãos erradas, o BitLocker impede o acesso não autorizado de cópias locais de dados dos 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 as 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 alternativa 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 conexão de aplicativo & políticas de segurança para sua organização.
Acesso seguro à sua organização
Os administradores podem usar o Microsoft Entra ID 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 que você definiu 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 certos tipos de políticas de acesso condicional (por exemplo, vedação de IP) para mecanismos de autenticação personalizados do Azure DevOps. Esses mecanismos incluem tokens de acesso pessoal, autenticação alternativa, OAuth e chaves 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.