Qual abordagem relacionada à disponibilidade envolve o uso de permissões de arquivo?

Avançar para o conteúdo principal

Não há mais suporte para esse navegador.

Atualize o Microsoft Edge para aproveitar os recursos, o suporte técnico e as atualizações de segurança mais recentes.

Visão geral da proteção de dados

• Artigo
• 10/04/2022
• 25 minutos para o fim da leitura

Neste artigo

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 serviços de nuvem adicionais, 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 globalmente disponível 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. Além disso, ele descreve o papel que você desempenha para manter seus projetos seguros e seguros.

Este artigo destina-se a administradores da organização e profissionais de TI que gerenciam seus ativos de projeto diariamente. Ele será 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.

Nosso compromisso

A Microsoft ajuda a garantir que seus projetos permaneçam seguros e seguros, sem exceção. Quando armazenados 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 a privacidade e a integridade dos dados em repouso e em trânsito.

As ameaças que você enfrenta se resumem a quatro categorias básicas: disponibilidade de dados, disponibilidade do serviço, segurança do serviço 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. Primeiro, o artigo descreve 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 devem saber quais etapas devem ser tomadas para proteger seus ativos contra divulgação e violação não autorizadas. Seja explícito ao conceder permissões aos pontos de acesso do usuário, portanto, somente as pessoas certas estão acessando dados no Azure DevOps.

Seja qual for a sua abordagem, você deve considerar todos os dados potencialmente "em risco", independentemente de onde estão ou como estão sendo usados. Isso é verdadeiro para dados na nuvem e dados armazenados em um data center privado. É importante classificar seus dados, sua confidencialidade e risco e o dano que ele poderá causar se forem comprometidos. Além disso, categorize seus dados em relação a uma política geral de gerenciamento de segurança da informação.

Criado no Azure

Hospedamos o Azure DevOps inteiramente nos data centers 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 das necessidades de armazenamento e recuperação, o Azure DevOps usa o Armazenamento de Blobs do Azure (para objetos binários grandes) e o armazenamento de dados do SQL do Azure. Para entender a abordagem do Azure DevOps Services para proteção de dados, é importante saber o histórico desses elementos.

• Armazenamento de Blobs do Azure armazena grandes partes de dados não estruturados. Todos os projetos usam o serviço de Armazenamento de Blobs do Azure. 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. Para obter mais informações, consulte Armazenamento de Blobs do Azure.

• SQL do Azure Armazenamento de banco de dados armazena os aspectos estruturados e transacionais de sua organização, incluindo metadados do projeto, o histórico de controle do código-fonte com versão e detalhes do item de trabalho. O armazenamento de banco de dados fornece acesso rápido aos elementos importantes do projeto e índices no armazenamento de blobs para pesquisar arquivos e anexos. Para saber mais, confira Banco de Dados SQL do Azure.

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 de contas do Azure Active Directory (Azure AD) e 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 verificar as credenciais do usuário, o Azure DevOps emitirá um cookie de autenticação para o usuário, o que 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, as permissões são validadas com base nas permissões explícitas do usuário, bem como nas permissões herdadas por meio da associação de grupo. Os administradores podem usar controles de acesso para proteger o acesso à organização, coleções de projetos, projetos de equipe e funcionalidades com escopo de equipe. Os administradores também podem proteger ativos mais específicos, como pastas de controle de versão e caminhos de área de item de trabalho.

Disponibilidade de dados

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

Redundância de dados

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

Para Armazenamento de Blobs do Azure, os dados do cliente são replicados três vezes em uma única região e são replicados de forma assíncrona para uma segunda região na mesma geografia. Assim, o Azure sempre mantém o equivalente a seis cópias de seus dados. Isso 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.

Observação

Em relação à redundância de dados e 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 na unidade de escala afetada. Exceto em circunstâncias extremas, a Microsoft opta por não fazer failover para que os dados do cliente não sejam perdidos.
• O Azure DevOps oferece uma garantia de SLA de tempo de atividade de 99,9% e reembolsa uma parte dos encargos mensais se esse SLA for perdido 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 proteger contra a exclusão acidental de dados, a Microsoft também faz backups pontuais dos blobs no Armazenamento de Blobs do Azure e dos bancos de dados no Banco de Dados SQL do Azure. Há uma cópia separada de todos os blobs e as alterações são acrescentadas a cada conta de armazenamento. Como esses dados são imutáveis, você não precisa reescrever nenhum armazenamento existente como parte dos procedimentos de backup.

Os backups são uma parte padrão do Banco de Dados SQL do Azure e o Azure DevOps faz uso disso. Mantemos 28 dias de seus dados. Em ambos os casos, esses backups também são replicados em uma região emparelhada, ajudando a garantir que nos recuperemos de uma interrupção regional.

Outra proteção é que os clientes podem recuperar suas organizações ou projetos excluídos por até 28 dias após a exclusão. Organizações e projetos excluídos estão em um estágio "excluído suavemente" por 28 dias, permitindo que os clientes se recuperem conforme necessário. Após 28 dias, eles são excluídos permanentemente e não podem ser restaurados.

Importante

A exclusão acidental aqui refere-se a cenários que surgem como resultado de um incidente em nossos serviços e não inclui a exclusão acidental de ativos (por exemplo, repositórios, itens de trabalho, anexos, artefatos) pelos clientes. Não oferecemos suporte à restauração de ativos que são excluídos acidentalmente pelos clientes, pois esses backups servem apenas para continuidade dos negócios e ajuda na recuperação de cenários de interrupção ou desastre.

A prática é crítica

Ter vários backups redundantes de seus dados é bom, mas sem prática, a restauração pode ser imprevisível. Foi dito que "os backups nunca falham, as restaurações falham". Embora tecnicamente incorreto, o sentimento está certo.

A Microsoft pratica regularmente a restauração de vários conjuntos de dados do backup. O armazenamento com redundância geográfica do Azure é testado regularmente. Além disso, de tempos em tempos, restauramos de backups para recuperar de erros humanos, como quando um cliente excluiu inadvertidamente um projeto no Azure DevOps. Há muitas combinações de cenários de desastre e corrupção de dados, que continuamos planejando e executando novos testes regularmente.

Disponibilidade do serviço

O Azure DevOps oferece proteções de DDoS (negação de serviço) distribuídas e resposta dinâmica 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 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. Isso ajuda a evitar qualquer uso excessivo dos principais recursos de serviço durante um ataque ou uso indevido acidental de recursos.

Resposta ao vivo do site

Em circunstâncias raras, você pode exigir uma resposta dinâmica do site a um problema com a disponibilidade do serviço. Temos uma equipe de operações disponível 24 vezes por dia, 7 dias por semana, para identificar rapidamente o problema e envolver os recursos necessários da equipe de desenvolvimento. Esses recursos resolvem o problema. Eles também visam atualizar a página de status do serviço em minutos após a detecção de um problema que afeta o serviço. Depois que a equipe tiver resolvido um problema, ela identificará a causa raiz do problema e acompanhará as alterações necessárias para evitar problemas semelhantes no futuro.

Os processos de gerenciamento de site ao vivo do Azure DevOps se concentram em sua experiência e na integridade do serviço. Esses processos minimizam o tempo para detectar, responder e atenuar problemas. Todas as disciplinas de engenharia são envolvidas e responsáveis, portanto, há melhorias contínuas evoluindo fora da experiência direta. Isso significa que os processos de monitoramento, diagnóstico, resiliência e garantia de qualidade melhoram ao longo do 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 envolvem:

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. 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 (contrato de nível de serviço) e fornece uma garantia financeira para garantir que cumpramos 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 de design e codificação adequadas 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 o vazamento de dados, a perda ou a corrupção. Para obter mais informações, consulte Sobre segurança, autenticação e autorização.

Proteger 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 do Microsoft Operational Security Assurance orienta seus procedimentos de operação na nuvem. As seguintes metodologias especificam os seguintes requisitos:

• Modelagem de ameaças durante o design do serviço.
• Seguindo 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 rígido processo de aprovação.

A equipe do Azure DevOps tem requisitos de treinamento anuais para todos os engenheiros e funcionários de operações e patrocina reuniões informais de "bolsa marrom" organizadas por engenheiros da Microsoft. Depois que eles resolveram um problema levantado em uma reunião de bolsa marrom, eles compartilham o que aprenderam com o resto da equipe.

Um serviço de nuvem é tão seguro quanto a plataforma de host. O Azure DevOps usa o PaaS para grande parte de sua infraestrutura. O PaaS fornece automaticamente atualizações regulares para vulnerabilidades de segurança conhecidas. As VMs hospedadas no Azure usam a 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 aqueles usados para implantação, monitoramento e relatórios.

A equipe do Azure DevOps realiza testes regulares de penetração com foco na segurança do Azure DevOps. Usando as mesmas técnicas e mecanismos que invasores mal-intencionados, o teste de penetração tenta explorar os serviços de produção ao vivo e a infraestrutura do Azure DevOps. O objetivo é identificar vulnerabilidades do mundo real, configurações, erros ou outras lacunas de segurança em um processo controlado. A equipe examina os resultados para identificar outras áreas de melhoria e aumentar a qualidade dos sistemas e treinamentos preventivos. Você pode examinar os resultados de testes recentes de penetração do Azure DevOps no Portal de Confiança do Serviço.

Segurança de credenciais

Suas credenciais no Azure DevOps são armazenadas usando as melhores práticas do setor. Saiba mais sobre o armazenamento de credenciais.

Relatar problemas de segurança

Se durante o teste de penetração você acredita ter descoberto uma possível falha de segurança relacionada ao serviço do Azure DevOps, denuncie-a à Microsoft dentro de 24 horas. Para obter mais informações, consulte Relatar uma vulnerabilidade de segurança do computador.

Programa de recompensas

O Azure DevOps participa do Microsoft Online Services Bounty Program. Este 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 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. O acesso é concedido no nível de privilégio mínimo necessário e somente após as justificativas adequadas serem fornecidas e verificadas. 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.

Solicitações e aprovações de acesso são controladas e monitoradas em um sistema separado. Todo o acesso ao sistema se correlaciona com essas aprovações e, se detectarmos o acesso não aprovado, a equipe de operações será alertada para investigar.

Usamos a autenticação de dois fatores para todo o acesso remoto ao sistema. Portanto, se o nome de usuário e a senha de um de nossos desenvolvedores ou equipe de operação tiverem sido roubados, os dados permanecerão protegidos. Isso significa que verificações de autenticação adicionais por meio de cartão inteligente ou uma chamada telefônica para um número pré-aprovado deve ocorrer antes que qualquer acesso remoto ao serviço seja permitido.

Além disso, a Microsoft usa segredos para gerenciar e manter o serviço, como senhas RDP, certificados SSL e chaves de criptografia. Todos eles 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 de maneira segura. Todos os segredos são girados em uma cadência regular e podem ser girados 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 violações externas, não permitimos aplicativos como Outlook e Office, pois eles geralmente são alvos de spear-phishing e outros tipos de ataques.

Proteção e resposta contra intrusões

Criptografamos dados por meio de HTTPS e SSL para garantir que eles não sejam interceptados ou modificados durante o trânsito entre você e o Azure DevOps.

Além disso, 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 criptografadas usando TDE (Transparent Data Encryption). A TDE protege contra ameaça de atividade mal-intencionada ao realizar a criptografia em tempo real do banco de dados, dos backups associados e dos arquivos de log 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 proteger dados inativos armazenados no Armazenamento de Blobs do Azure, o Azure DevOps usa a SSE (Criptografia do Serviço de Armazenamento) do Azure.

A infraestrutura do Azure ajuda a equipe do Azure DevOps a registrar e monitorar os principais aspectos do serviço. Isso ajuda a garantir que as atividades dentro do serviço sejam legítimas e detecte violações ou tentativas de violações. Além disso, 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. Alertas em tempo real são gerados porque as informações de log são analisadas automaticamente para descobrir comportamentos potencialmente mal-intencionados ou não autorizados.

Quando uma possível intrusão ou vulnerabilidade de segurança de alta prioridade é identificada, a equipe tem um plano de resposta claro. Este plano descreve as partes responsáveis, as etapas necessárias para proteger os dados do cliente e como se envolver com especialistas em segurança na 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 solucionar a situação.

Por fim, para ajudar a combater ameaças emergentes, o Azure DevOps emprega uma estratégia "Assumir Violação". Um grupo altamente especializado de especialistas em segurança na Microsoft, conhecido como Equipe Vermelha, 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 prontidão e os impactos dos ataques do mundo real. Essa estratégia fortalece a detecção de ameaças, a resposta e a defesa do serviço. Ele também permite que a equipe valide e melhore a eficácia de todo o programa de segurança.

Privacidade dos dados

Você deve ter confiança de que seus dados estão sendo tratados adequadamente e para usos legítimos. Parte dessa garantia envolve restringir adequadamente o uso para que seus dados sejam usados apenas por motivos legítimos.

Regulamento Geral sobre a Proteção de Dados (RGPD)

O GDPR (Regulamento Geral de 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/CE. Para obter mais informações sobre a regulamentação do RGPD, consulte a página de visão geral na Central de Confiabilidade da Microsoft.

Residência e soberania de dados

O Azure DevOps está disponível nas seguintes oito regiões geográficas 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 à sua geografia mais próxima, mas você tem a opção de escolher uma geografia diferente. Se você mudar de ideia mais tarde, é possível migrar sua organização para uma geografia diferente, com a ajuda do suporte da Microsoft.

O Azure DevOps não move nem replica dados do cliente fora da geografia escolhida. Em vez disso, seus dados são replicados geograficamente para uma segunda região dentro da mesma geografia. A única exceção é o Brasil, que replica dados para a geografia do Centro-Sul dos EUA para fins de recuperação de desastre.

Observação

Para builds e versões em execução em agentes macOS fornecidos pela Microsoft, seus dados serão transferidos para um data center do GitHub nos EUA.

Para saber mais, consulte o local de dados do Azure DevOps.

Acesso à aplicação da lei

Em alguns casos, terceiros, como entidades de aplicação da lei, podem se aproximar da Microsoft para obter acesso aos dados do cliente armazenados no Azure DevOps. Tentamos redirecionar as solicitações ao proprietário da organização para resolução. Quando obrigada por ordem judicial 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 seu armazenamento de dados em uma localização geográfica específica para garantir uma jurisdição legal específica para qualquer atividade 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 fora do local, são mantidos em uma das geografias mencionadas anteriormente.

Acesso da Microsoft

De tempos em tempos, os funcionários da Microsoft precisam obter acesso aos dados do cliente armazenados no Azure DevOps. Por precaução, todos os funcionários que têm ou podem ter acesso aos dados do cliente devem passar por uma verificação de antecedentes, que verifica o emprego anterior e condenações criminais. Permitimos o acesso aos sistemas de produção somente quando há um incidente de site 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 forma, classificamos os dados para distinguir entre os seguintes tipos de dados:

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

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

Uso promocional da Microsoft

Ocasionalmente, a Microsoft deseja entrar em contato com os clientes para informá-los sobre recursos e serviços adicionais que podem ser úteis. Como nem todos os clientes desejam ser contatados sobre essas ofertas, você pode aceitar e recusar as comunicações de 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 internas de adoção na Microsoft, o nível de transparência fornecido no estado do nosso serviço e o progresso para receber a certificação de nossos sistemas de gerenciamento de segurança de informações.

Adoção interna

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

Obviamente, grandes equipes se movem mais gradualmente do que as menores, dado seus investimentos em sistemas DevOps existentes. Para que as equipes possam se mover rapidamente, estabelecemos uma abordagem de classificação de projeto. 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.

Os requisitos adicionais para projetos internos incluem associar a organização a Azure AD para garantir a complexidade e o ciclo de vida de identidade do usuário adequados. Para projetos mais confidenciais, a autenticação de dois fatores também é necessária.

Certificações de conformidade

Alguns de vocês querem 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
• HIPAA (Lei de Portabilidade e Prestação de Contas do Seguro de Saúde)
• BAA (Business Associate Agreement)
• Cláusulas Modelo da UE
• SOC 1 Tipo 2
• SOC 2 Tipo 2
• Alemanha C5

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

Etapas que você pode executar

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

Classificar os dados

A primeira etapa é classificar seus dados. Classifique os dados com base na confidencialidade e no horizonte de risco e nos danos que podem ocorrer se eles 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 o documento "Classificação de dados para preparação de nuvem" da Computação Confiável da Microsoft.

Adotar o Azure Active Directory

Use o Azure Active Directory (Azure AD) para gerenciar o acesso da sua organização ao Azure DevOps. Azure AD fornece outra maneira de melhorar a segurança das credenciais dos usuários. Azure AD permite que seu departamento de TI gerencie sua política de acesso do usuário final, complexidade de senha, atualizações de senha e expiração se o usuário deixar sua organização. Por meio da federação do Active Directory, você pode vincular diretamente Azure AD 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 de conta da Microsoft e Azure AD em relação ao acesso do 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 com Azure AD. 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 seu laptop ou computador desktop cair em mãos erradas, o BitLocker impedirá o acesso não autorizado de cópias locais de dados de seus projetos.

Limitar o uso de credenciais de autenticação alternativas

O mecanismo de autenticação padrão para ferramentas relacionadas ao Git é a autenticação alternativa (às vezes conhecida como autenticação básica). Esse mecanismo permite que o usuário final configure um nome de usuário e senha alternativos para uso durante operações de linha de comando do Git. Essa combinação de nome de usuário e senha também pode ser usada 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 comunicação é enviada por HTTPS e há requisitos de complexidade de senha. Sua organização deve continuar avaliando se políticas adicionais são necessárias para atender aos requisitos de segurança do projeto. Você pode desabilitar completamente as credenciais de autenticação alternativas se decidir que ela não atende aos requisitos de segurança da sua organização. Para obter mais informações, consulte Alterar as políticas de segurança de conexão & do aplicativo para sua organização.

Proteger o acesso à sua organização

Azure AD fornece a capacidade dos administradores de controlar o acesso a recursos e aplicativos do Azure, como o Azure DevOps. Com o controle de acesso condicional em vigor, o Azure AD verifica condições específica que você define para um usuário acessar um aplicativo. Depois que os requisitos de acesso são atendidos, 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, cerca de IP) para mecanismos de autenticação personalizados do Azure DevOps. Esses mecanismos incluem tokens de acesso pessoal, autenticação alternativa, chaves OAuth e SSH. Se os usuários estiverem acessando o Azure DevOps por meio de um cliente de terceiros, somente as políticas baseadas em IP (somente baseadas em IPv4) serão honradas.

Recursos adicionais

• Home page do Azure DevOps
• Local de dados do Azure DevOps
• Declaração de privacidade da Microsoft
• Suporte do Azure DevOps
• Recursos e serviços incluídos no Azure DevOps
• Central de confiabilidade do Azure
• Microsoft Security Development Lifecycle

Recursos adicionais

Recursos adicionais

Neste artigo

Qual abordagem relacionada a disponibilidade envolve o uso de permissões de arquivo Select One?

Quais são os três estados de dados Cisco?

Quais são as três melhores práticas que podem ajudar a defender contra ataques de engenharia social?

Quais são os três estados de dados durante os quais os dados são vulneráveis?