Melhores práticas para proteger seu ambiente Microsoft Azure

5 maio 2015

Como você deve saber, migrar suas cargas de trabalho para a nuvem não significa que você deixa de ser responsável pela segurança de seus sistemas operacionais, aplicações e dados. Trabalhando na segurança da infraestrutura Azure, essa responsabilidade de segurança compartilhada começa garantindo que seu ambiente Azure seja seguro. Como o primeiro de uma série de postagens sobre as melhores práticas Azure, iremos falar passo a passo sobre o que você precisa fazer para proteger o acesso nas camadas administrativas, de aplicações e de rede.

Em uma postagem posterior, falaremos sobre os próximos passos para garantir a segurança de suas cargas de trabalho. Não deixe de compartilhar suas próprias dicas para o gerenciamento do Azure na seção de comentários abaixo!

Agora vamos às melhores práticas…

Planeje antes de sua Adoção da Nuvem

Quero falar sobre esse princípio geral antes de começar a falar sobre as dicas de segurança porque é um ponto essencial e geralmente negligenciado. Infelizmente, esse é um erro comum dos responsáveis pelas aplicações ignorar as equipes de TI e de segurança e se inscreverem em serviços de nuvem sem planejamento ou reflexão. Tal adoção de serviços de nuvem geralmente leva a correções complicadas e dispendiosas posteriormente, quando suas equipes de TI e de segurança são envolvidas. Por exemplo, se você não separa claramente suas assinaturas, você pode sem querer dar acesso a serviços de produção para funcionários que não precisam dele. Pensar e planejar é um bom investimento, apesar de levar tempo. Investir tempo planejando sua estratégia de adoção da nuvem permite estabelecer uma fundação sólida sobre a qual você pode construir e crescer, sem medo de mudanças dispendiosas mais tarde.

Agora, vamos falar do fluxo geral da inscrição no Serviço de Nuvem da Microsoft (Azure) e apresentar a você alguns conceitos fundamentais associados ao Microsoft Azure. Isso vai ajudá-lo a entender melhor as relações entre esses componentes, quais são os princípios de segurança para cada etapa e quais opções estão à sua disposição.

Criando Sua Conta Azure

Para fazer qualquer coisa no Azure, você precisa de uma conta. Quando você cria uma conta no Azure usando o Azure Account Center, existem duas opções para se inscrever: a) uma conta Microsoft, tais como <usuário>@outlook.com, <usuário>@hotmail.com ou <usuário>@live.com; ou b) conta de trabalho ou da sua empresa – essas são originadas no Azure Active Directory.

As assinaturas do Microsoft Azure usam o Azure Active Directory para inscrever os usuários no portal de gerenciamento e para proteger o acesso à API de gestão Azure. É recomendável usar as contas de trabalho/empresa que são criadas dentro do Azure Active Directory e que fornecem mais opções de gerenciamento. Mais importante, as contas de trabalho/de empresa podem ser suplementadas com autenticação de dois fatores, o que é sempre recomendado para usuários privilegiados, tais como “administrados da conta/administrador global”.

Considere criar uma conta de email de “serviço” na sua empresa, por exemplo, uma lista de distribuição (DL) com um endereço SMTP externo associado a ele que possa ser usado para se inscrever no Azure. Esse email DL deve manter alguns acionistas importantes do projeto como membros, de modo que sua conta Azure não seja afetada pela troca de funcionários. Por exemplo, “Comp_Azure_Srv@yourdomain.com” pode ser a identidade do usuário para o processo de inscrição na conta Azure. Essa conta se tornará sua “Conta de Administrador ou Administrador Global”. Basta colocar este usuário em sua conta “root”. O administrador da conta é a única pessoa autorizada a acessar o centro de contas para criar inscrições, cancelar assinaturas, mudar a cobrança da assinatura, mudar o administrador do serviço, entre outras coisas. Existe uma relação individual entre a conta Azure e o administrador da conta.

Configurando Sua Assinatura

Depois da conta Azure ter sido criada, o próximo passo é configurar as assinaturas (ou subscriptions, em inglês). Todos os serviços de nuvem pertencem a uma assinatura; as assinaturas ajudam você a organizar o acesso aos recursos do serviço de nuvem. O administrador da conta (a pessoa que criou a conta Azure) é a única pessoa que pode criar assinaturas e é designado como o “administrador do serviço” default para a assinatura. Existe uma relação individual entre a conta Azure e o administrador da conta. O acesso ao Portal de Gerenciamento Azure é concedido a esse administrador. Você também pode criar até 10 coadministradores por assinatura, e pode criar múltiplas assinaturas baseadas em seus requisitos. Por exemplo, você pode criar assinaturas individuais baseadas no tipo de ambiente, tais como “desenvolvimento”, “montagem” e “produção”. É aconselhável separar suas cargas de trabalho em assinaturas específicas para evitar mudanças acidentais, possibilitando que você veja o uso do serviço e controle o acesso a cada um, de maneira granular.

Figura 1 – Conta Azure para Assinaturas e Administradores de Acesso

Configuração de Controles Baseados em Funções (RBAC)

Agora que as assinaturas foram criadas, você pode começar a controlar quais recursos da nuvem seus funcionários podem acessar e quais ações podem realizar com esses recursos. No novo Portal de Pré Visualização do Microsoft Azure (Microsoft Azure Preview Portal), a Microsoft anunciou o pré lançamento do Controle de Acesso Baseado em Função (em inglês, Role-Based Access Control ou RBAC). Usando o RBAC, você pode limitar o acesso de usuários e grupos designando funções a eles nos recursos do Azure. O controle de acesso baseado em função do Azure vem com diferentes funções incorporadas: “proprietário”, “leitor” e colaborador” que podem ser atribuídas a usuários, grupos e serviços.

É mais fácil criar e atribuir o acesso para o “nível de assinatura” em primeiro lugar, e depois fazer os ajustes nos níveis de recursos. Por exemplo, John Smith (seu DBA) pode receber a função de “leitor” no nível de assinatura e, com base na sua função (DBA) e na estrutura de aplicação (aplicação de três níveis: web, app e DB), depois você pode designar a ele a função de “colaborador” no nível de máquinas virtuais (VM) que estão sendo executadas na base de dados de sua aplicação.

Figura 2 – Acesso de Leitor no nível de Assinatura

Figura 3. – Acesso de Colaborador no nível de VM

Controle Seus Pontos de Acesso aos Recursos do Azure

Em seguida, você precisa decidir como seus usuários irão acessar os recursos da nuvem ao qual obtiveram acesso. O Microsoft Azure permite múltiplos métodos de acesso e recursos de gerenciamento, portanto, é importante restringir o acesso remoto para sua VM a partir de uma estação de trabalho fortificada e dedicada executando apenas os serviços e aplicações necessários, podendo ter um acesso restrito à rede apenas para o que é necessário para realizar tarefas de forma prática. Essas estações de trabalho não são usadas por seus usuários para as atividades cotidianas. Você pode bloquear mais o acesso aos recursos do Azure com um Gateway de Desktop Remoto (Remote Desktop Gateway ou RDGW), instalado no local e conectado ao ambiente Azure. Esse RDGW, junto com a Proteção de Acesso à rede do Servidor Windows (NAP), ajuda a garantir que apenas os clientes que atendam critérios de segurança específicos estabelecidos por seus AD GPOs podem se conectar.

Nesse tipo de configuração, a instância local do Windows Firewall (ou um cliente de Firewall não Microsoft) é configurada para bloquear conexões de entrada, tais como a RDP. O administrador pode se logar na estação de trabalho local fortificada e começar uma sessão RDP que se conecta à máquina virtual Azure, mas não pode se logar em um PC corporativo e usar o RDP para se conectar à estação de trabalho em si. Essa prática tem o objetivo de restringir e reduzir sua superfície de ataque. A seguinte visualização lógica mostra como o acesso à Azure VM só é permitido a partir da estação de trabalho fortificada local via RDGW.

Figura 4. – Tirado De: http://go.microsoft.com/fwlink/?linkid=518999&clcid=0x409

Considerações de Segurança da Camada da Rede

A segurança da rede é uma das partes mais importantes de seu projeto geral de segurança, seja ela feita no local ou na nuvem pública. O Microsoft Azure fornece a infraestrutura necessária para conectar de maneira segura suas máquinas virtuais (VMs) umas às outras, e fazendo a ponte entre a nuvem e seu data center. As responsabilidades do gerenciamento e proteção da rede são compartilhadas entre você e a Microsoft. Por exemplo, o Microsoft Azure cuida dos ataques de spoofing, realizando verificações baseadas no hypervisor na saída da rede, isto é, um nó de computação não tem a autorização para enviar tráfego de qualquer IP diferente do seu. Do mesmo modo, como uma pessoa inscrita no Azure, você não pode entrar no data center da Microsoft e reprogramar um rack de servidor, mas tem permissão para fazer o equivalente dentro de seu ambiente de nuvem através de uma série de mecanismos virtuais diferentes, inclusive guest OS firewall, configuração de VNET Gateway e rede virtual privada (VPN).

Vamos dar uma olhada “de dentro para fora” na rede no Azure: do mesmo modo que você faz em um modelo no local, você pode planejar o projeto de sua rede com base nos requisitos de sua segurança, conectividade e aplicações. Isso deve ser feito antes de lançar suas cargas de trabalho (VMs) na Azure, porque depois que uma VM for implementada você não pode movê-la para a rede virtual sem implementá-la novamente.

Utilizando o serviço de rede virtual do Windows Azure, você pode criar redes virtuais para segregar suas aplicações de três níveis, onde você põe suas máquinas virtuais web, de aplicação e de base de dados (DB).

Figura 5 – Rede Virtual de 3 Níveis

Depois da rede virtual ser criada, você pode anexar sua máquina virtual à Rede Virtual Windows Azure. Todas as VMs anexadas à rede virtual só podem falar com outras VMs anexadas a mesma rede virtual. Se as comunicações devem ser restringidas entre as VMs dentro da mesma subrede, por exemplos, VMs no nível web não podem falar umas com as outras (leste-oeste), então ou elas usam um guest OS Firewall ou implementam uma solução de firewall baseado em um host terceirizado. Para restringir o fluxo do tráfego entre as subredes e as VMs (por exemplo, as VMs no nível web não podem falar com as do nível DB), você pode usar um guest OS firewall, implementar soluções de firewall de terceiros, como o Trend Micro Deep Security, ou pode usar o controle de acesso no nível da rede do Azure chamado Network Security Groups (NSGs), desde que sua vNet seja associada a grupos afins. Os NSGs permitirão um filtro de tráfego de dois níveis no fluxo de entrada e de saída, implementando uma política de firewall de fluxo de tráfego, mantida no nível da rede ao invés de no nível do sistema operacional.

O acesso externo às VMs a partir da Internet é definido com a criação de endpoints de entrada que permitem comunicações de entrada com a sua VM. No projeto de rede de três níveis, as VMs colocadas em um nível de aplicação ou DB normalmente não precisam de um acesso direto à Internet. Por essa razão, recomenda-se restringir o acesso direto a elas, não tendo nenhum endpoint de entrada para essas VMs e criando endpoints de entrada apenas para portas que você precisa que fiquem abertas a partir da Internet. Quando o acesso às aplicações e servidores DB a partir de fora for necessário, você também pode especificar listas de controle de acesso (access control lists ou ACLs) nos endpoints de entrada para controlar os IPs de origem a partir do qual a VM permitirá o tráfego de entrada, como mostrado abaixo:

Figura 6 – Acesso Restrito ao Servidor DB usando ACL para permitir um IP de origem de uma estação de trabalho específica

Do mesmo modo, o fluxo de comunicações de saída de sua VM deve ser restringido com base em seus requisitos de aplicações e segurança.

O diagrama lógico na Figura 7 abaixo descreve as escolhas de controle da rede de que falamos no nosso exemplo de uma pilha de aplicações de três níveis.