Visão geral da proteção de dados

Serviços do Azure DevOps

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 a função que você desempenha para 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. Ele é mais útil para pessoas já familiarizadas 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ços, segurança de serviços e privacidade de dados. Este artigo explora ameaças específicas em 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 devem ser tomadas para proteger seus ativos contra divulgação não autorizada e adulteração. Seja explícito ao conceder permissões aos pontos de acesso do usuário, para que somente as pessoas certas acessem os dados no Azure DevOps.

Você deve considerar que todos os dados estão potencialmente em risco, não importa onde estejam localizados ou como estão sendo usados. Essa afirmação é verdadeira tanto para dados armazenados na nuvem quanto para dados armazenados em um datacenter privado. É importante classificar seus dados, sua confidencialidade 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 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 do Azure DevOps em relação à 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 esse 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 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 de versão da fonte e detalhes de itens de trabalho. O armazenamento em banco de dados oferece acesso rápido aos elementos importantes do seu projeto. Ele fornece índices no armazenamento de blobs 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 do Microsoft Entra ID e de 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 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 os controles de acesso para proteger o acesso à organização, às coleções de projetos, aos projetos de equipe e aos 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 do Armazenamento do Azure para ajudar a garantir a disponibilidade dos dados em caso de falha de hardware, interrupção de serviço ou desastre regional. Além disso, a equipe do Azure DevOps segue os procedimentos para proteger os dados contra exclusão acidental ou mal-intencionada.

Redundância de dados

Para proteger os dados durante falhas de hardware ou de 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 os 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. 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 o 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 de forma centralizada, pois afeta todos os clientes em uma unidade de escala específica. Exceto em circunstâncias extremas, a Microsoft opta por evitar falhas para que os dados dos clientes 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 não cumprir 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 a perda acidental de dados, a Microsoft emprega backups pontuais para os blobs armazenados no Armazenamento de Blobs do Azure e para os 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 utilizados pelo Azure DevOps. Seus dados são retidos por 28 dias, sendo que esses backups também são 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 no período de 28 dias após a exclusão. Porém, quando esse prazo passa, essas entidades são permanentemente excluídas e não podem ser restauradas. Embora esses backups sejam um componente crucial para a recuperação de desastres, é essencial que os clientes pratiquem estratégias adequadas de gerenciamento de dados e backup para garantir a proteção completa de seus dados.

A prática é crítica

É bom ter vários backups de seus dados, 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 é correto.

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 desastres 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 a aplicativos 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ços essenciais durante um ataque ou o 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.

Em seguida, os recursos da equipe de desenvolvimento resolvem o problema. Eles também pretendem atualizar a página de status do serviço em minutos após a detecção de um problema que afete 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 o gerenciamento de sites ativos concentram-se 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 são responsáveis, de modo que os aprimoramentos constantes 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 assegurar que cumpriremos esse contrato todos os meses. Para obter mais informações, consulte SLA para Azure DevOps.

Às vezes, equipes de parceiros ou dependências 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 de Garantia de segurança operacional da Microsoft orienta os procedimentos de operação em 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 metodologias a seguir especificam os requisitos de treinamento:

• Modelagem de ameaças durante o design do serviço
• Seguir as práticas recomendadas de design e código
• Verificando a segurança com ferramentas e testes padrão
• Limitando o acesso aos dados operacionais e do cliente
• Distribuiçã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 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 aos computadores locais, incluindo os computadores usados para implementação, monitoramento e geração de relatórios.

A equipe do Azure DevOps realiza testes regulares de penetração focados em segurança do Azure DevOps. Os testes de penetração tentam explorar os serviços e a infraestrutura de produção em tempo real 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 analisar os resultados dos testes de penetração recentes do Azure DevOps na página do Portal de confiança do serviço Microsoft.

Segurança de credenciais

A Microsoft tem o compromisso de 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 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 Diretrizes para autenticação.

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 gerados aleatoriamente por meio do RNGCryptoServiceProvider e compartilhados com o solicitante como uma string 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 a chave pública SSH.
• As chaves públicas brutas são fornecidas diretamente pelo chamador por SSL.
• O hash SSH é gerado na memória do 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 nos JWTs emitidos e apresentados ao nosso serviço são validadas usando um certificado armazenado em nosso cofre de chaves.

Informar 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, informe 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 no computador.

Programa de recompensas

O Azure DevOps participa do programa de Recompensas por Bugs da Microsoft. 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 o 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 do 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 as solicitações de acesso e as aprovações em um sistema separado. Todo o acesso ao sistema está correlacionado 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 da 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 gravada de forma segura. Todos os segredos são rotacionados em intervalos regulares, e podemos rotacioná-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 costumam ser alvos de spear phishing e outros tipos de ataques.

Proteção e resposta contra intrusões

Criptografamos os dados via HTTPS e SSL para 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 forma:

• Os dados armazenados nos bancos de dados SQL do Azure são criptografados por meio de criptografia de dados transparente. Esse recurso protege contra atividades mal-intencionadas por meio da criptografia em tempo real do banco de dados, dos backups associados e dos arquivos de registro de transações em repouso.

• As conexões do Armazenamento de Blobs do Azure são criptografadas para 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 .

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

Todas as atividades de implantação e de administrador são registradas com segurança, assim como o acesso do operador ao armazenamento de produção. As informações de registro 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 dos clientes e instruções sobre como se envolver 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 as ameaças emergentes, o Azure DevOps emprega uma estratégia de violação presumida. 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 os controles do Azure para prevenir, detectar e responder a um ataque de ransomware. Para obter mais informações sobre como o Azure protege os clientes contra ataques de ransomware, consulte Proteção contra ransomware no Azure.

Privacidade dos dados

Você deve ter certeza de que estamos tratando seus dados de forma apropriada e para usos legítimos. Parte dessa garantia envolve a restrição cuidadosa do 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 no Microsoft Trust Center.

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 mudar de ideia posteriormente, você poderá migrar a organização para um local diferente com a ajuda do suporte da Microsoft.

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

Para obter mais informações, confira Locais de dados do 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 um terceiro, a Microsoft faz um esforço razoável para notificar o proprietário da organização com antecedência, a menos que sejamos legalmente proibidos de fazê-lo.

Alguns clientes exigem o armazenamento de seus dados em uma determinada localização geográ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, espelhos geo-redundantes 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 a dados de clientes devem passar por uma verificação de antecedentes que inclua empregos anteriores e condenações criminais. Permitimos o acesso aos sistemas de produção somente quando há um incidente no local ou outra atividade de manutenção aprovada, que é registrada e monitorada.

Como nem todos os dados em nosso sistema são tratados da mesma forma, classificamos os dados nesses 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

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.

Gerenciamento de políticas de privacidade para administradores controlarem a coleta de comentários do usuário

O recurso de alternância de comentários permite que os proprietários da organização do Azure DevOps controlem se os usuários são solicitados a fornecer comentários e enviá-los. Esse recurso é essencial para garantir que as práticas de comentários se alinhem às políticas de privacidade e governança da sua organização.

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 no estado de nosso serviço e o progresso no sentido de receber a certificação de nossos sistemas para gerenciar a segurança das informações.

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.

As equipes grandes se movem mais gradualmente do que as menores, devido aos seus investimentos em sistemas de 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 a associação da organização ao Microsoft Entra ID para garantir o ciclo de vida adequado da identidade do usuário e a complexidade da senha. Os projetos mais confidenciais também exigem autenticação de dois fatores.

Certificações de conformidade

Talvez você tenha interesse em entender a avaliação de terceiros sobre nossos procedimentos de segurança de dados. O Azure DevOps obteve as seguintes certificações:

• ISO 27001:2022
• ISO 27018:2019
• ISO 26262:2023
• Lei HIPAA (Health Insurance Portability and Accountability Act) dos EUA
• Contrato de Associação 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 CAIQ (Questionário de Iniciativa de Avaliação de Consenso) ajuda as organizações a avaliar as práticas e os recursos de segurança dos provedores de serviço 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 ler o relatório completo no Portal de confiança do serviço Microsoft.

Etapas que você pode seguir

A proteção adequada dos dados exige o seu envolvimento ativo, dos administradores e dos usuários. Os dados do seu 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 confidencialidade e no horizonte de risco, juntamente com os danos que podem ocorrer se forem 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 da Classificação de dados para prontidão na nuvem da Microsoft Trustworthy Computing..

Adote o Microsoft Entra ID

Use o Microsoft Entra ID para gerenciar o acesso de sua organização no Azure DevOps. O Microsoft Entra ID oferece outra maneira de aumentar a segurança das credenciais dos usuários.

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

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

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 seu 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 uma 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 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 desativar 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 segurança de conexão & de aplicativo para sua organização.

Proteger o acesso à sua organização

Os administradores podem usar o Microsoft Entra ID para controlar o acesso aos recursos e aplicativos do Azure, como o Azure DevOps. Com o controle de acesso condicional em vigor, o Microsoft Entra ID verifica condições específica que você define 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, 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 honradas.

Mais recursos

• Home page do Azure DevOps
• Locais de dados do Azure DevOps
• Política de privacidade da Microsoft
• Suporte do Azure DevOps
• Recursos e serviços incluídos no Azure DevOps
• Central de Confiabilidade do Azure
• Ciclo de vida de desenvolvimento de segurança da Microsoft