Visão geral da proteção de dados
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 em nuvem, gerenciamos seu código-fonte, itens de trabalho, builds 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 é destinado a administradores de organização 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 desejam 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 sabem 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 do usuário, para que apenas as pessoas certas acessem os dados no Azure DevOps.
Você deve considerar todos os dados como potencialmente em risco, não importa onde estejam ou como estejam sendo usados. Essa instrução é verdadeira para dados armazenados na nuvem e 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 para gerenciar a segurança da informação.
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 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 do Azure DevOps Services para proteção de dados, aqui estão algumas informações sobre os serviços de armazenamento:
Armazenamento de Blobs do Azure armazena grandes partes de dados não estruturados. Todos os projetos usam 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 maior parte do armazenamento em uso é esse tipo de armazenamento de blobs não estruturado.
O Banco de Dados SQL do Azure armazena os aspectos estruturados e transacionais da sua organização, incluindo metadados do projeto, o histórico de controle do código-fonte com controle de versão 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 blobs para pesquisar 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 do Azure DevOps 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 de 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 no escopo da 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 do Armazenamento do Azure para ajudar a garantir a disponibilidade dos dados se houver uma falha de hardware, interrupção de serviço ou desastre regional. Além disso, a equipe do Azure DevOps 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 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 em 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 SLA (contrato de nível de serviço) de 99,9% de tempo de atividade. O Azure DevOps reembolsará uma parte dos encargos mensais se perder esse SLA em um mês específico.
- Como há apenas uma região no Brasil, os dados do cliente no Brasil são replicados para a região Centro-Sul dos EUA para fins de recuperação de desastre.
Erros acontecem
Para se proteger contra perda acidental de dados, a Microsoft emprega backups pontuais 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 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, depois que esse período de tempo decorrido, 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 dos 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 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 é 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 "os 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 do backup. Testamos regularmente o armazenamento com redundância geográfica do Azure. Existem 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 do aplicativo que podem penetrar nos sistemas de defesa do Azure, o Azure DevOps estabelece cotas e limitação no nível do aplicativo e da organização. Essa prática ajuda a evitar o 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 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 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 do Azure DevOps para gerenciamento de sites dinâmicos 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 estão envolvidas e responsáveis, portanto, 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:
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 esse contrato todos os meses. Para obter mais informações, consulte SLA para Azure DevOps.
Às vezes, 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 por design
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 do Azure DevOps tem requisitos de treinamento anual 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 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
- Implementação de novos recursos por meio de um processo de aprovação rígido
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 IaaS (infraestrutura como serviço), como para um serviço de build 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 computadores locais, incluindo os computadores usados 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 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 equipe analisa os resultados desses testes para identificar outras áreas de melhoria e aumentar a qualidade dos sistemas preventivos e do treinamento. Você pode examinar os resultados dos testes de penetração recentes do Azure DevOps no Portal de Confiança do Serviço da Microsoft.
Segurança de credenciais
A Microsoft está comprometida em garantir que 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. Aplicamos privacidade e integridade de dados em repouso e em trânsito. Além disso, aderimos às práticas a seguir em relação às credenciais ou segredos que o Azure DevOps armazena. Para saber mais sobre como escolher o mecanismo de autenticação correto, consulte Diretrizes 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 você mude para um método de autenticação mais seguro.
Tokens de acesso pessoal (PATs)
- Armazenamos um hash do PAT.
- Os PATs brutos são gerados na memória no lado do servidor. 32 bytes são gerados aleatoriamente por meio do RNGCryptoServiceProvider e são compartilhados com o chamador como uma cadeia de caracteres codificada em base 32. Esse valor NÃO é armazenado.
- O hash PAT é gerado na memória no lado do servidor como um HMACSHA256Hash do PAT bruto 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 por SSL.
- O hash SSH é gerado na memória no lado do servidor como um HMACSHA256Hash da 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 declarações em JWTs emitidas e apresentadas ao nosso serviço são validadas usando um certificado armazenado em nosso cofre de chaves.
Relatando falhas de segurança
Se você acredita que seu teste de penetração revelou uma possível falha de segurança relacionada ao serviço Azure DevOps, relate-o à 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 você não precise notificar a Microsoft sobre as atividades de teste de penetração, você deve estar em conformidade com as Regras de Compromisso do Teste de Penetração da Microsoft.
Programa de recompensas
O Azure DevOps participa do programa Microsoft Bug Bounty. Esse programa recompensa os pesquisadores de segurança que relatam problemas para nós e incentiva mais pessoas a ajudar a manter o Azure DevOps seguro. Para obter mais informações, consulte Programa de recompensas do Microsoft Azure DevOps.
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 menor privilégio 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 e aprovações de acesso 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. Todos esses segredos são 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 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ções externas, não permitimos aplicativos como o Outlook e o Office, pois 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 enquanto estiverem em 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 em 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 criptografia do lado do serviço.
A equipe do Azure DevOps usa a infraestrutura do Azure para registrar e monitorar os principais aspectos do serviço. O registro em log 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ções.
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 malicioso ou não autorizado gera alertas em tempo real.
Quando a equipe do Azure DevOps identifica uma possível intrusão ou vulnerabilidade de segurança de alta prioridade, ela tem um plano de resposta claro. Esse plano descreve as partes responsáveis, as etapas necessárias para proteger os dados do cliente e as 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 assumida. Uma equipe altamente especializada de especialistas em segurança 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 certeza de que estamos lidando com seus dados de forma adequada 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 nem replica dados do cliente fora do local escolhido. Em vez disso, seus dados são replicados geograficamente para uma segunda região no 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 desastre.
Observação
Para builds e versões executados em agentes macOS fornecidos pela Microsoft, seus dados são transferidos para um datacenter GitHub nos Estados Unidos.
Para obter mais informações, consulte Locais de dados para Azure DevOps.
Acesso à aplicação da lei
Em alguns casos, terceiros, como entidades de aplicação da lei, podem abordar 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 do cliente 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 teste 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. 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 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 ao se inscrever ou administrar 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
A Microsoft ocasionalmente 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 ter confiança em outros esforços que a Microsoft faz em nome do Azure DevOps. Esses esforços incluem políticas de adoção interna na Microsoft, o nível de transparência do estado de nosso serviço e o progresso para receber a 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 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.
Equipes grandes se movem mais gradualmente do que as menores, devido aos investimentos em sistemas DevOps existentes. Para 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.
Mais requisitos para projetos internos incluem associar a organização à ID do Microsoft Entra para garantir o ciclo de vida de identidade do usuário adequado e a complexidade da senha. Projetos mais confidenciais 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
- ISO 26262:2023
- Lei HIPAA (Health Insurance Portability and Accountability Act) dos EUA
- Acordo de Parceiro 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 Consensus Assessment Initiative Questionnaire (CAIQ) ajuda as organizações a avaliar as práticas e recursos de segurança dos provedores de serviços em 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. Convidamos você a examinar o relatório completo no Portal de Confiança do Serviço da Microsoft.
Etapas que você pode seguir
A 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. 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 ser reutilizados quando os projetos são movidos para o Azure DevOps. Para obter mais informações, você pode baixar Classificação de dados para preparação para a nuvem da Microsoft Trustworthy Computing.
Adote a ID do Microsoft Entra
Use a ID do Microsoft Entra para gerenciar o acesso da sua organização ao Azure DevOps. A ID do Microsoft Entra fornece outra maneira de melhorar a segurança das credenciais dos usuários.
A ID do Microsoft Entra 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 da 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 do Azure DevOps:
| Propriedade | Conta da 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 |
| Tempo de vida da senha e controle de complexidade | 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 IP | 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 a ID do Microsoft Entra. 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 a 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 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 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 avaliando se precisa de mais políticas para atender aos requisitos de segurança de seus projetos.
Você pode desabilitar as 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 políticas de conexão e segurança de aplicativos 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, a ID do Microsoft Entra verifica as condições específicas que você define para um usuário acessar um aplicativo. Depois que o usuário atende aos requisitos de acesso, o usuário é 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, OAuth e chaves SSH (Secure Shell). Se os usuários acessarem o Azure DevOps por meio de um cliente de terceiros, somente as políticas baseadas em IPv4 serão respeitadas.