Microsoft Azure

Windows Azure – TCC – Secure Azure Cloud Services | VM’s [#Cloud #Security]

Share-it!
Share on Facebook0Tweet about this on TwitterShare on LinkedIn1Share on Google+0Email this to someone

Ola pessoall, voltando aos posts sobre meu TCC, vou falar um pouco hoje sobre seguranca em VM, no ambiente Windows Azure, espero que gostem.

Comunicação entre VM’s:

As VM’s que estão contidas dentro de uma rede de distribuição, podem se comunicar internamente com outras VM’s utilizando endereços IP privados. Porém, a segurança na comunicação entra as VM’s pode e deve ser melhorada utilizando a implementação de uma rede virtual, como uma VLAN.

Se um aplicativo recebe ou envia dados sensíveis através de uma rede privada interna, tais como uma VPN, os dados podem ser criptografados utilizando IPSec, SSL/TLS ou outro método de criptografia à nível de aplicativo.

Porém, os clientes com maior confidencialidade ou preocupações com privacidade dos dados (especialmente os clientes que possuem regulamentações da indústria), devem garantir por meio de configuração que todas as comunicações privadas entre as VM’s dentro de uma região, sejam codificadas.

Os administradores podem decidir quais as portas de uma VM e endereços IP’s podem ser acessados. Além disso é possível implementar uma série de alterações de configuração para ajudar em um acesso remoto seguro seguro à rede, como:

* Definição de parâmetros de entrada na camada de acesso à nuvem, para abrir as portas somente quando necessário. É possível especificar listas ACL’s na entrada dos endpoints para controlar os IP’s de origem à partir dos quais a VM irá permitir o tráfego. Ou seja: Só trafega o que é expressamente permitido.

* Usar Firewall e Proxy de terceiros (como por exemplo Barracuda Web Application, Firewall Vx ou GN Firewall), é possível adicionar VM’s a uma rede virtual e em seguida, definir uma entrada endpoint para uma porta no firewall/proxy.

* Definição de portas abertas no firewall dentro do S.O. O Administrador deverá seguir o mesmo padrão do modelo de segurança como se a VM estivesse aberta na intenet.

Comunicação através das Assinaturas:

Um cliente pode ter várias assinaturas, e pode haver uma necessidade de comunicação entre as VM’s em diferentes assinaturas. Nesses casos, as VM’s podem ser configuradas para se comunicar através de endereços IP virtuais publicos. Além disso, uma ACL precisa ser configurada em terminais de entrada para permitir que as VM’s faça comunicação apenas uns com os outros.
É muito importante o uso dos endereços de IP reservados, para que as ACL’s de endereços IP não mudem.

Comunicação para ambiente on premises:

Quando é requerido comunicação segura entre o Azure e o ambiente local do cliente, a melhor prática a ser adotada é proteger o canal utilizando um Gateway de rede virtual.

Existem 2 cenários para implantação:
* Interno (Aplicações multi-tier): Esse cenário funciona como um sistema de processamento de registros webbased, onde o aplicativo não precisa de qualquer de qualquer conexão de entrada com Internet e não precisa de conectividade com os servidores e aplicações no ambiente on-premises do cliente.
* Public-Facing Multi-Tier Application: Quando um aplicativo multi-tier Azure é implantado e a camada de front end requer conectividade de entrada com a internet (através da porta 443 – SSL). Os níveis de backend não precisam de conectividade de entrada, mas, necessitam de conectividade com o ambiente interno do cliente.

Neste caso, o administrador deve:
* Criar uma rede virtual comas VM’s apropriadas.
* Definir parâmetross de entrada para o tráfego da internet para as VM’s na camada de front-end
* Retirar os terminais de entrada de gestão remota para todas as VM’s e bloqueá-los
* Configurar o gateway virtual de rede para que o trpafego destinado à rede corporativa flua através de uma VPN.
O gateway virtual de rede estabelece um túnel IPSec para rotear o tráfego entre a rede virtual e a VPN do cliente.
Este pode ser um hardware VPN ou um software de VPN, como o Windows Server 2012 Routing and Remote Access Services.
A criação de uma rede privada virtual dentro do Azure fornece uma capacidade melhor, no que diz respeito à segurança. Essa conexão pode ser uma VPN Site to Site ou Client to Site.
Se a VPN dentro de uma região está ligada à uma rede empresarial através da internet, um gateway de rede virtual deverá ser configurado, e através dele a conexão é criptografada por um padrão como AES-256,
Se a rede privada virtual dentro de uma região utiliza a tecnologia Azure Express Route o tráfego é considerado muito mais seguro, pois ele atravessa o ISP e uma MPLS.
Os clientes que possuem preocupações com segurança, devem criptografar as comunicaçõe susando IPSec, TLS ou outra forma de criptografia, atém mesmo em disco com o Bitlocker.
Protegendo Gerenciamento Remoto de VM’s
Os administradores podem criar uma VM utilizando o Portal de Gerenciamento do Azure ou Windows Power Shell.
Quando um administrador usa o Portal, o Remote Desktop Protocol (RDP) e Windows PowerShell remote, estão liberados e com suas portas abertas.
O Portal atribui RDP e Power shell Remoto com o número das portas aleatórias, para reduzir a chance de um ataque do tipo dicíonário.(Ataque conhecido por utilizar uma tabela de exaustivas tentativas e erros)
O Administrador pode optar por manter o RDPe Power Shell Remote aberto para a internet, mas no mínimo, ele deverá proteger as contas de permissão com senhas fortes.

Protegendo de ataques DDoS:

Para a proteção dos serviços Azure contra os ataques DDoS, a Microsoft fornece uma defesa distribuída, que faz parte do monitoramento contínuo do processo no Azure.
Essa defesa é contínuamente melhorada através de testes de penetração e ataques DDoS orquestrados pela equipe de engenharia da própria Microsoft.
O Sistema de defesa contra DDoS do Azure é projetado não só para resistir aos ataques de fora, mas também contra ataques de outros clientes da plataforma Azure.
* Ataques na camada de rede de alto volume: Esses ataques costumam congestionar os túneis e sobrecarregar a capacidade de processamento, por inundar a rede com muitos pacotes ao mesmo tempo.
A tecnologia de defesa DDoS do Azure oferece uma detecção e mitigação técnicas como SYN cookies, limitação de taxa e limitação de conexão, para ajudar e assegurar que tais ataques não tenham impacto no ambiente contratado pelo cliente.
* Ataques na camada de aplicação: Esses ataques podem ser feitos contra uma VM de um cliente.
O Azure não fornece mitigação ou bloqueio evetino no tráfego de rede de um cliente individual, porque a infra estrutura não consegue interpretar esse comportamento esperado das aplicações do cliente.
Sendo assim, semelhante à implantações locais, as mitigações incluem:
– Executar várias instâncias de VM, através de um balanceamento de carga, usando IP Público.
– Uso de dispositivos de proxy ou firewamm de aplicação, tais como Web (WAF’s), que encerram e encaminham o tráfego para os endpoints que estão rodando a VM.
Algumas soluções vitualizadas, como a Baracuda Networks, estão disponíveis para a execução ajudando na prevenção de intrusões e detecções.
– ACL’s de rede podem impedir que os pacotes a partir de um determinado endereço IP atinja a VM.

Protegendo VMs com DNS interno:

Lidando com VM’s dentro de um serviço de nuvem, temos a opção de referenciá-las por um nome. Logo, o Azure oferece um DNS interno para ajudar nessa identificação e comunicação.
Os nomes das VM’s são resolvidos para endereços IP privados, mantendo a privacidade através dos serviços. Os endereços de IP privados atribuídos à ambos, VM’s e Serviços, podem mudar durante a reparação da infraestrutura de nuvem.
Logo, há possibilidade das comunicações entre entre entre os serviços dentro do Azure serem resolvidos pelo nome DNS, e não pelo endereço IP.
A unica exceção à essa regra é quando as redes virtuais estão sendo utilizadas com endereço customizado.
Nesses casos, o endereço IP é estático, além disso, o DNS pode mudas o TTL das respostas.
Isolando Vms com uma Rede Virtual para defesa em profundidade
O administrador pode segmentar o tráfego da internet na camada de rede, com uma rede Virtual usando grupo de segurança de rede.
Esses grupos podem ser aplicados a uma sub rede de uma rede virtual.
Figura 4 Using Network Security Groups in a multi-tier application VNET
Além de segmentar o tráfego de intranet, os grupos de segurança de rede (NSG’s) podem também controla o tráfego de entrada e saída da internet.
Eses grupos podem ser aplicados a uma VM ou a uma sub-rede, e em alguns casos para ambos.

Alguns aspectos são importantes:
* As regras possuem, o que a Microsoft chama de, 5-tuple (Ip de Origem, Porta de Origem, IP de Destino, Porta de Destino e Protocolo) conforme mostra a figura 5. (Figura 5)
* As regras do NSG são stateful, ou seja, se houver uma regra de entrada que permita o tráfego através de uma porta, não necessitará uma regra de saída para que os pacotes trafeguem na mesma porta.
* Cada NSG contém regras padrão, que permitem a conectividade dentro da Rede Virtual e acesso de saída para a internet.
* Os processos NSG são regras baseadas em prioridades. Regras com o valor menos significam de maior prioridade, e são processadas antes das outras regras com valor maior.
* o Azure fornece tags padrão como INTERNET e VIRTUAL_NETWORK, que se referem ao espaço de endereços IP públicos fora da rede virtual. Essas podem ser usadas como parte de uma regra para controle de acesso.
Protegendo a comunicação de VM’s para SQL
O Azure também fornece um firewall embutido para filtrar as entradas de tráfegos, com destino às instâncias SQL do cliente.
Inicialmente, todas as comunicações com o banco de dados estão bloqueadas. Para ativá-las, o administrador deverá definir regras de firewall no serviço SQL Azure Database, permitindo que um determinado IP possa se comunicar com a instância.
Além disso, o mesmo deverá sempre atualizar o IP nas ACL’s, sempre que o IP público mudar.
O Azure usam firewall hypervisor (filtro de pacotes), que é implementado no hypervisor e configurado por um agente controlador de acesso. Isso ajuda a proteger os clientes de um acesso não autorizado.

Existem duas categorias de regras:

Configuração de Máquinas ou Infraestrutura: Por padrão, toda a comunicação é bloqueada. Há algumas exceções para permitir que uma VM envie e recebe tráfego de DHCP e DNS. VM’s também podem enviar tráfego para internet e para outras VM’s. Alista de destinos permitidos de saída não inclui sub-redes do roteador no Azure e outras propriedades da Microsoft.

Arquivo de Configuração: Esse arquivo define as ACL’s de entrada com base no modelo de serviço do cliente. Por exemplo, se um cliente possui um front-end da Web na porta 80 em uma VM, então o Azure abre a porta TCP 80 para todos os IP’s se o cliente configurar um endpoint no portal do Azure.

Network Security Groups (NSG): são utilizados para controlar o tráfego de uma ou mais máquinas virtuais em sua rede virtual. Um NSG contém regras de controle de acesso que permitem ou negam tráfego com base na direão do mesmo, protocolo, endereço de origem, porta, endereço de destino e porta de destino.

User Defined Routing: o cliente poderá controlar o roteamento de pacotes através de um appliance virtual, criando rotas definidas que especificam qual o próximo salto para que os pacotes fluam.

IP Forwarding: Um appliance virtual de segurança de rede é capaz de receber o tráfego de entrada que não é dirigido para si. É possível permitir que uma VM receba esse tráfego e dirija à outros destinos.

Forced Tunneling: Permite o redirecionamento forçado. Ou seja, Força todo o tráfego de internet gerado por suas VM’s de volta para sua empresa (on premises) através de um tunel site-to-site, para obter inspeção e auditoria.

Endpoint ACL’s: É possível controlar quais máquinas possuem permissão de conexão à internet.

Um Forte Abraço, e até a próxima! #enjoy #rock

Gustavo Magella

Leave a Reply

Your email address will not be published. Required fields are marked *

Responda o enigma: * Time limit is exhausted. Please reload CAPTCHA.