Compartilhar via

Componentes e limites do sistema de informações do Azure

Este artigo fornece uma descrição geral da arquitetura e do gerenciamento do Azure. O ambiente do sistema do Azure é composto pelas seguintes redes:

  • Rede de produção do Microsoft Azure (rede do Azure)
  • Rede corporativa da Microsoft (corpnet)

Equipes de TI separadas são responsáveis por operações e manutenção dessas redes.

Arquitetura do Azure

O Azure é uma plataforma de computação em nuvem e infraestrutura para criar, implantar e gerenciar aplicativos e serviços por meio de uma rede de datacenters. A Microsoft gerencia esses datacenters. Com base no número de recursos especificados, o Azure cria VMs (máquinas virtuais) com base na necessidade de recursos. Essas VMs são executadas em um hipervisor do Azure, que foi projetado para uso na nuvem e não é acessível ao público.

Em cada nó do servidor físico do Azure, há um hipervisor que é executado diretamente pelo hardware. O hipervisor divide um nó em um número variável de VMs convidadas. Cada nó também tem uma VM raiz, que executa o sistema operacional host. O Firewall do Windows está habilitado em cada VM. Você define quais portas podem ser endereçáveis configurando o arquivo de definição de serviço. Essas portas são as únicas abertas e endereçáveis, interna ou externamente. Todo o tráfego e o acesso ao disco e à rede são mediados pelo hipervisor e pelo sistema operacional raiz.

Na camada de host, as VMs do Azure executam uma versão personalizada e protegida do Windows Server mais recente. O Azure usa uma versão do Windows Server que inclui apenas os componentes necessários para hospedar VMs. Isso melhora o desempenho e reduz a superfície de ataque. Os limites do computador são impostos pelo hipervisor, que não depende da segurança do sistema operacional.

Gerenciamento do Azure por controladores de malha

No Azure, VMs em execução em servidores físicos (nós/folhas) são agrupadas em clusters de aproximadamente 1.000. As VMs são gerenciadas de forma independente por um componente de software de plataforma escalonado e redundante chamado FC (controlador de malha).

Cada FC gerencia o ciclo de vida de aplicativos em execução em seu cluster, provisiona e monitora a integridade do hardware sob seu controle. Ele executa operações autônomas, como reencarnar instâncias de VM em servidores íntegros quando determina que um servidor falhou. O FC também executa operações de gerenciamento de aplicativos, como implantação, atualização e dimensionamento de aplicativos.

O datacenter é dividido em clusters. Os clusters isolam falhas no nível fc e impedem que determinadas classes de erros afetem servidores além do cluster no qual ocorrem. Os FCs que atendem a um cluster específico do Azure são agrupados em um cluster FC.

Inventário de hardware

O FC prepara um inventário de dispositivos de rede e hardware do Azure durante o processo de configuração de inicialização. Todos os novos componentes de hardware e rede que inserem o ambiente de produção do Azure devem seguir o processo de configuração de inicialização. O FC é responsável por gerenciar todo o inventário listado no arquivo de configuração datacenter.xml.

Imagens do sistema operacional gerenciado por FC

A equipe do sistema operacional fornece imagens, na forma de Discos Rígidos Virtuais, implantadas em todas as VMs de host e convidados no ambiente de produção do Azure. A equipe constrói essas imagens base por meio de um processo de build offline automatizado. A imagem base é uma versão do sistema operacional na qual o kernel e outros componentes principais foram modificados e otimizados para dar suporte ao ambiente do Azure.

Há três tipos de imagens do sistema operacional gerenciado por malha:

  • Host: um sistema operacional personalizado que é executado nas VMs do host.
  • Nativo: um sistema operacional nativo executado em locatários (por exemplo, o Armazenamento do Microsoft Azure). Esse sistema operacional não tem nenhum hipervisor.
  • Convidado: um sistema operacional convidado que é executado em VMs convidadas.

O host e os sistemas operacionais nativos gerenciados por FC foram projetados para uso na nuvem e não são acessíveis publicamente.

Host e sistemas operacionais nativos

Host e nativo são imagens do sistema operacional reforçadas que hospedam os agentes de malha e são executados em um nó de computação (executados como a primeira VM no nó) e nós de armazenamento. O benefício de usar imagens base otimizadas de host e nativo é que ele reduz a área de superfície exposta por APIs ou componentes não utilizados. Elas podem apresentar altos riscos de segurança e aumentar o impacto do sistema operacional. Os sistemas operacionais de volume reduzido incluem apenas os componentes necessários para o Azure.

Sistema operacional convidado

Os componentes internos do Azure em execução em VMs do sistema operacional convidado não têm oportunidade de executar o Protocolo de Área de Trabalho Remota. Todas as alterações nas configurações de linha de base devem passar pelo processo de gerenciamento de alterações e lançamentos.

Datacenters do Azure

A equipe de MCIO (Infraestrutura e Operações de Nuvem) da Microsoft gerencia a infraestrutura física e as instalações do datacenter para todos os serviços online da Microsoft. O MCIO é o principal responsável por gerenciar os controles físicos e ambientais dentro dos datacenters, bem como gerenciar e dar suporte a dispositivos de rede de perímetro externo (como roteadores de borda e roteadores de datacenter). O MCIO também é responsável por configurar o hardware mínimo do servidor em racks no datacenter. Os clientes não têm interação direta com o Azure.

Equipes de serviços e gerenciamento de serviços

Vários grupos de engenharia, conhecidos como equipes de serviço, gerenciam o suporte do serviço do Azure. Cada equipe de serviço é responsável por uma área de suporte para o Azure. Cada equipe de serviço deve disponibilizar um engenheiro 24 vezes por dia, 7 dias por semana para investigar e resolver falhas no serviço. As equipes de serviço não têm, por padrão, acesso físico ao hardware que está operando no Azure.

As equipes de serviço são:

  • Plataformas de aplicativos
  • Microsoft Entra ID
  • Computação do Azure
  • Rede do Azure
  • Serviços de Engenharia de Nuvem
  • ISSD: Segurança
  • Autenticação multifator
  • Banco de Dados SQL
  • Armazenamento

Tipos de usuários

Os funcionários (ou contratados) da Microsoft são considerados usuários internos. Todos os outros usuários são considerados usuários externos. Todos os usuários internos do Azure têm seu status de funcionário categorizado com um nível de confidencialidade que define seu acesso aos dados do cliente (acesso ou sem acesso). Os privilégios de usuário para o Azure (permissão de autorização após a autenticação) são descritos na tabela a seguir:

Função Interno ou externo Nível de sensibilidade Privilégios e funções autorizados executados Tipo de acesso
Engenheiro de datacenter do Azure Interno Sem acesso aos dados do cliente Gerencie a segurança física do local. Realize patrulhas dentro e fora do datacenter e monitore todos os pontos de entrada. Escolte para dentro e para fora do datacenter certos funcionários sem autorização que fornecem serviços gerais (como refeições ou limpeza) ou trabalho de TI dentro do datacenter. Realize o monitoramento de rotina e a manutenção do hardware de rede. Gerencie incidentes e execute trabalho de correção de falhas usando várias ferramentas. Realize o monitoramento de rotina e a manutenção do hardware físico nos datacenters. Acesso ao ambiente sob demanda de proprietários de propriedade. Capaz de executar investigações forenses, registrar relatórios de incidentes e exigir requisitos obrigatórios de treinamento e política de segurança. Propriedade operacional e manutenção de ferramentas de segurança críticas, como scanners e coleta de logs. Acesso persistente ao ambiente.
Triagem de incidentes do Azure (engenheiros de resposta rápida) Interno Acesso aos dados do cliente Gerenciar comunicações entre mcio, suporte e equipes de engenharia. Incidentes de plataforma de triagem, problemas de implantação e solicitações de serviço. Acesso just-in-time ao ambiente – com acesso persistente limitado para sistemas não clientes.
Engenheiros de implantação do Azure Interno Acesso aos dados do cliente Implantar e atualizar componentes da plataforma, software e alterações de configuração agendadas em suporte ao Azure. Acesso just-in-time ao ambiente – com acesso persistente limitado para sistemas não clientes.
Suporte de interrupção de cliente do Azure (locatário) Interno Acesso aos dados do cliente Depurar e diagnosticar falhas e interrupções de plataforma para locatários de computação individuais e contas do Azure. Analisar as falhas. Implemente correções críticas na plataforma ou para o cliente, e promova melhorias técnicas em todas as áreas de suporte. Acesso just-in-time ao ambiente – com acesso persistente limitado para sistemas não clientes.
Incidente e engenheiros de sites ativos do Azure (engenheiros de monitoramento) Interno Acesso aos dados do cliente Diagnosticar e mitigar problemas de saúde da plataforma usando ferramentas de diagnóstico. Conduzir correções para os drivers de volume da unidade, reparar itens resultantes de interrupções e ajudar em ações de restauração de interrupção. Acesso just-in-time ao ambiente – com acesso persistente limitado para sistemas não clientes.
Clientes do Azure Externo Não aplicável Não aplicável Não aplicável

O Azure usa identificadores exclusivos para autenticar usuários e clientes organizacionais (ou processos que atuam em nome de usuários organizacionais). Isso se aplica a todos os ativos e dispositivos que fazem parte do ambiente do Azure.

Autenticação interna do Azure

As comunicações entre componentes internos do Azure são protegidas com criptografia TLS. Na maioria dos casos, os certificados X.509 são autoassinados. Certificados com conexões que podem ser acessadas de fora da rede do Azure são uma exceção, assim como certificados para os FCs. FCs têm certificados emitidos por um Microsoft Certificate da autoridade (CA) que é apoiada por uma autoridade de certificação de raiz confiável. Isso permite que as chaves públicas de FC ser revertidas facilmente. Além disso, as ferramentas de desenvolvedor da Microsoft usam chaves públicas fc. Quando os desenvolvedores enviam novas imagens de aplicativo, as imagens são criptografadas com uma chave pública FC para proteger os segredos inseridos.

Autenticação de dispositivo de hardware do Azure

O FC mantém um conjunto de credenciais (chaves e/ou senhas) usadas para se autenticar em vários dispositivos de hardware sob seu controle. A Microsoft usa um sistema para impedir o acesso a essas credenciais. Especificamente, o transporte, a persistência e o uso dessas credenciais são projetados para impedir que desenvolvedores, administradores, serviços de backup do Azure e pessoal acessem informações sensíveis, confidenciais ou privadas.

A Microsoft usa criptografia com base na chave pública de identidade mestra do FC. Isso ocorre nos tempos de configuração do FC e de reconfiguração do FC, para transferir as credenciais usadas para acessar dispositivos de hardware de rede. Quando o FC precisa das credenciais, o FC as recupera e descriptografa.

Dispositivos de rede

A equipe de rede do Azure configura contas de serviço de rede para permitir que um cliente do Azure se autentique em dispositivos de rede (roteadores, comutadores e balanceadores de carga).

Administração segura do serviço

A equipe de operações do Azure é obrigada a usar SAWs (estações de trabalho de administrador seguro). Os clientes podem implementar controles semelhantes usando estações de trabalho de acesso privilegiado. Com SAWs, a equipe administrativa usa uma conta administrativa atribuída individualmente separada da conta de usuário padrão do usuário. O SAW baseia-se nessa prática de separação de conta fornecendo uma estação de trabalho confiável para essas contas confidenciais.

Próximas etapas

Para saber mais sobre o que a Microsoft faz para ajudar a proteger a infraestrutura do Azure, consulte: