Recursos de segurança do Banco de Dados SQL do Azure

  • Artigo

O Banco de Dados SQL do Azure fornece um serviço de banco de dados relacional no Azure. Para proteger os dados do cliente e fornecer recursos de segurança fortes que eles esperam de um serviço de banco de dados relacional, o Banco de Dados SQL tem seus próprios conjuntos de recursos de segurança. Esses recursos se baseiam nos controles que são herdados do Azure.

Funcionalidades de segurança

Uso do protocolo TDS

O Banco de Dados SQL do Azure oferece suporte apenas ao protocolo de fluxo de dados tabulares (TDS), que exige que o banco de dados seja acessível somente pela porta padrão do TCP/1433.

Firewall do Banco de Dados SQL do Azure

Para ajudar a proteger os dados do cliente, o Banco de Dados SQL do Azure inclui uma funcionalidade de firewall que, por padrão, impede todo o acesso ao Banco de Dados SQL.

Firewall do Banco de Dados SQL do Azure

O firewall do gateway pode limitar endereços, o que permite que o controle granular dos clientes especifique intervalos de endereços IP aceitáveis. O firewall concede acesso com base no endereço IP de origem de cada solicitação.

Os clientes podem obter a configuração de firewall usando um portal de gerenciamento ou programaticamente usando a API REST do Banco de Dados SQL do Azure Management. O Banco de Dados SQL do Azure tem um firewall de gateway que, por padrão, impede todo o acesso do TDS do cliente a ele. Os clientes devem configurar o acesso usando listas de controle de acesso (ACLs) para permitir conexões do banco de dados SQL do Azure por endereços de Internet, protocolos e números de porta de origem e de destino.

DoSGuard

O DosGuard, um serviço de gateway de Banco de Dados SQL, reduz ataques de DoS (negação de serviço). O DoSGuard controla ativamente os logons com falha de endereços IP. Se houver vários logons com falha de um endereço IP dentro de um período, o endereço IP é impedido de acessar todos os recursos no serviço por um período predefinido.

Além disso, o gateway do Banco de Dados SQL do Azure executa:

  • Negociações de capacidade de canal seguro para implementar conexões criptografadas validadas pelo TDS FIPS 140-2 quando ele se conecta aos servidores de banco de dados.
  • Inspeção de pacote TDS com estado enquanto aceita conexões de clientes. O gateway valida as informações de conexão. O gateway passa os pacotes TDS para o servidor físico apropriado com base no nome do banco de dados especificado na cadeia de conexão.

O principal princípio para a segurança de rede da oferta do Banco de Dados SQL do Azure é permitir apenas a conexão e a comunicação necessárias para permitir que o serviço funcione. Todas as outras portas, protocolos e conexões são bloqueados por padrão. Redes locais virtuais (VLANs) e ACLs são usadas para restringir as comunicações de rede por redes de origem e destino, protocolos e números de porta.

Mecanismos aprovados para implementar ACLs baseadas em rede incluem ACLs em roteadores e balanceadores de carga. Esses mecanismos são gerenciados pelo sistema de rede do Azure, pelo firewall de convidado da VM e pelas regras de firewall do gateway do Banco de Dados SQL do Azure, que são configuradas pelo cliente.

Segregação de dados e isolamento do cliente

A rede de produção do Azure é estruturada de forma que os componentes do sistema acessíveis publicamente sejam segregados dos recursos internos. Existem limites físicos e lógicos entre os servidores da Web que fornecem acesso ao portal do Azure voltado ao público e à infraestrutura virtual subjacente do Azure, onde residem as instâncias do aplicativo do cliente e os dados do cliente.

Todas as informações acessíveis publicamente são gerenciadas na rede de produção do Azure. A rede de produção é:

  • Sujeita a mecanismos de proteção de limites e autenticação de dois fatores
  • Usa o conjunto de recursos de segurança e firewall descrito na seção anterior
  • Usa as funções de isolamento de dados indicadas nas próximas seções

Sistemas não autorizados e isolamento do FC

Como o controlador de malha (FC) é o orquestrador central da malha do Azure, controles significativos estão em vigor para mitigar as ameaças, especialmente de FAs potencialmente comprometidos em aplicativos de clientes. O FC não reconhece nenhum hardware cujas informações do dispositivo (por exemplo, endereço MAC) não estejam pré-carregadas no FC. Os servidores DHCP no FC configuraram listas de endereços MAC dos nós que devem ser reinicializados. Mesmo se sistemas não autorizados estiverem conectados, eles não são incorporados ao inventário de malha e, portanto, não estão conectados ou autorizados a se comunicar com qualquer sistema dentro desse inventário. Isso reduz o risco de comunicação não autorizada de sistemas com o FC e acesso à VLAN e ao Azure.

Isolamento de VLAN

A rede de produção do Azure é separada logicamente em três VLANs primárias:

  • A principal VLAN: Interconecta nós de clientes não confiáveis.
  • O FC VLAN: Contém FCs confiáveis e sistemas de suporte.
  • A VLAN do dispositivo: contém rede confiável e outros dispositivos de infraestrutura.

Filtragem de pacotes

O IPFilter e os firewalls de software que são implementados no sistema operacional raiz e sistema operacional convidado de nós impõem restrições de conectividade e impedir que o tráfego não autorizado entre as VMs.

Hiper visor, sistema operacional raiz e VMs convidadas

O hipervisor e a raiz do sistema operacional gerenciam o isolamento da raiz do sistema operacional das VMs convidadas e as VMs convidadas umas das outras.

Tipos de regras de firewalls

Uma regra é definida como:

{IP do SRC, Porta do SRC, IP de destino, Porta de destino, Protocolo de destino, Entrada/Saída, Com estado/sem estado, Tempo limite de fluxo com estado}.

Os pacotes de caracteres ociosos síncronos (SYN) só são permitidos dentro ou fora se qualquer uma das regras permitir. Para TCP, o Azure usa regras sem estado em que o princípio é que ele permite que apenas todos os pacotes não-SYN entrem ou saiam da VM. A premissa de segurança é que qualquer pilha de host seja resiliente de ignorar um não SYN se ela não tiver visto um pacote SYN anteriormente. O protocolo TCP em si é stateful e, em combinação com a regra baseada em SYN sem estado, atinge um comportamento geral de uma implementação com estado.

Para User Datagram Protocol (UDP), o Azure usa uma regra stateful. Sempre que um pacote UDP corresponde a uma regra, um fluxo inverso é criado na outra direção. Esse fluxo tem um tempo limite interno.

Os clientes são responsáveis por configurar seus próprios firewalls além do que o Azure fornece. Aqui, os clientes são capazes de definir as regras de tráfego de entrada e saída.

Gerenciamento de configuração de produção

As configurações seguras padrão são mantidas pelas equipes de operações respectivas no Banco de Dados SQL do Azure e do Azure. Todas as alterações de configuração em sistemas de produção são documentadas e controladas por meio de um sistema de controle central. Alterações de software e hardware são controladas por meio do sistema central de rastreamento. As alterações de rede relacionadas à ACL são rastreadas usando um serviço de gerenciamento de ACL.

Todas as alterações de configuração no Azure são desenvolvidas e testadas no ambiente de preparo e, em seguida, são implantadas no ambiente de produção. Builds de software são examinados como parte dos testes. Verificações de segurança e privacidade são analisadas como parte dos critérios de lista de verificação de entrada. As alterações são implantadas em intervalos programados pela respectiva equipe de implantação. As versões são analisadas e aprovadas pela respectiva equipe de implantação antes de serem implantadas em produção.

As alterações são monitoradas para o sucesso. Em um cenário de falha, a alteração é revertida para seu estado anterior ou um hotfix é implantado para resolver a falha com a aprovação do pessoal designado. O Source Depot, o Git, o TFS, o MDS (Master Data Services), os corredores, o monitoramento de segurança do Azure, o FC e a plataforma WinFabric são usados para gerenciar, aplicar e verificar as configurações no ambiente virtual do Azure.

Da mesma forma, as alterações de hardware e de rede têm estabelecido etapas de validação para avaliar sua aderência aos requisitos de build. As liberações são revisadas e autorizadas por meio de um painel consultivo de mudança coordenada (CAB) dos respectivos grupos em toda a pilha.

Próximas etapas

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