Projeto Cloud – Algumas opções de Backup com Azure – Parte IV

October 29th, 2014 No comments

Uma das principais responsabilidades de qualquer Sysadmin é garantir a continuidade do ambiente em caso de algum tipo problema. De fato um dos pilares da tríade de segurança é a disponibilidade (Availability) do acesso ao dado a quem de direito e uma das formas de garantir esse requisito é com uma solução de recuperação de catástrofe eficaz.

 

Há várias formas de implementar uma solução de Backup, não há regras nem receitas prontas e qualquer solução deve examinar não só as caraterísticas do ambiente (tipo de serviços, servidores, sistemas e etc) mas também as políticas de segurança definidas para o ambiente e negócio da empresa.

 

Em nosso projeto implantamos uma solução mista, envolvendo serviços nativos do Windows, sistema de backup atual (System Center 2012 R2 – Data Protection Manager) e também as opções oferecidas pelo Azure (Azure Backup). Dividimos a solução de duas formas:

 

1 – Estender nossa solução de backup atual para armazenar dados sensíveis também na nuvem;

Já temos uma solução de Backup robusta utilizando o System Center 2012 R2 – Data Protection Manager com unidades de storage e carrossel de fitas LTO internamente. Para alguns dados mais sensíveis (algumas bases de dados por exemplo) além de armazenamento local e em fita também guardaremos em um “cofre” (vault) na nuvem.

 

2 – Utilizar o próprio Azure para fazer backup do que está rodando na nuvem;

Utilizando o Azure Backup decidimos fazer backup na nuvem de pastas e arquivos de backup de alguns servidores em execução.

 

O primeiro passo é criar um cofre de backup. Optamos por criar um para cada solução dessa forma conseguimos nos organizar melhor.

1 – Selecionar a opção de criação de um novo cofre de backup

 

Infelizmente ainda não está disponível no datacenter do Brasil essa opção, mas acredito que essa limitação é apenas temporária.

 

2- Após a criação do cofre de backup temos acesso às opções aos programas para configuração dos agentes, bem como as credenciais de acesso ao cofre.

 

 

3 – Para integração com o System Center 2012 R2 DPM devemos a opção do agente e, após a instalação no servidor, teremos acesso as configurações de conexão do DPM ao cofre da nuvem

 

4 – Só conseguimos conectar o servidor local ao cofre da nuvem se apresentarmos o certificado de segurança, com isso garantimos que o acesso é feito de forma restrita e segura. Para fazer o download o certificado (Credenciais do Cofre) basta selecionar a opção indicada no Painel do cofre recém criada. O arquivo gerado contém várias informações dentre elas a chave de criptografia utilizada para segurança da conexão:

 

Obs. Podemos utilizar certificados próprios para esse recurso, para tanto é necessário fazer o “upload” do certificado interno (da sua empresa) para o Azure. Assunto para outro artigo ! J

5 – No DPM o primeiro passo para registro do servidor ao cofre da nuvem é a importação do certificado :

6 – Em seguida é necessário informar as informações de proxy, caso exista essa configuração em seu ambiente;

 

7 – A próxima etapa é definir o consumo de banda de acordo com o perfil de acesso (trabalho) no seu ambiente.

8 – O quarto passo é definir a área temporária, em disco, que será utilizada para recuperação de um arquivo. Esse espaço é requerido para recuperações feitas no Azure.

 

9 – O Certificado que utilizamos para é importante para garantir a segurança da conexão entre o nosso ambiente o cofre da nuvem, mas como protegemos o dado que está armazenado? Nessa etapa colocamos a “chave” – Passphrase que será utilizada para criptografar, e de-criptografar, o conteúdo do Backup.

OBS: Lembre-se de guardar essa chave criada em segurança !

 

 

Após a conexão e registro feitos entre o DPM e o cofre do Azure precisamos criar o “Job de backup” ou Protection Group como é chamado no DPM. A criação do Job é mesma, a única diferença fica na etapa de configuração do método de proteção onde estará disponível a seleção da salvaguarda online.

 

Para a segunda solução, backup na nuvem dos servidores rodando no Azure decidimos utilizar o próprio agente que está disponível ao criar o cofre de backup.

 Após a instalação do agente a etapa de registro, assim como na solução integrada com o DPM, também é requerida. Selecionamos a mesma credencial que obtemos na solução anterior e está disponível no painel do cofre de backup.

 

Também é necessário criar a chave, passphrase, para proteger o dado.

 

Após a instalação o recurso de Azure Backup estará disponível para uso

 

A configuração de uma rotina, JOB, de backup também é muito intuitiva. Para tanto basta selecionarmos a opção de criação de um novo agendamento de Backup.

Seleciona as pastas que farão parte do Backup;

 

A próxima etapa é definir:

- Retenção, número de dias que o backup ficará guardado no cofre;

- Frequência, se será diária ou semanal e quais dias ocorrerão;

- Horário, horário que será executado

 

 Finish ! sua política, job, de Azure Backup está pronta !

 

Passados alguns ciclos de execução você verá nas opções de recuperação (recovery) os dias disponíveis com a versão para uma possível recuperação de dados.

 

Além das soluções acima gosto também de usar alguns recursos nativos do Windows e do SQL Server (no caso de banco de dados) para compor nossas opções de recuperação de dados.

 

No Windows a que mais gosto, e recomendo fortemente, é a opção de “Shadow Copies”. Esse recurso está disponível no Windows e com apenas um clique habilitamos a opção de recuperação de versões anteriores de arquivos um volume específico.

Resumindo, temos uma solução de recuperação de dados (backup) nativo no Windows e com opção do próprio usuário ter acesso!  Isso acelera em muito a recuperação de um determinado dado em cenário mais simples.

Mais informações no link : http://technet.microsoft.com/en-us/library/cc771305.aspx

 

Já no SQL gosto da opção ter disponível em disco, não só em fitas, diversas versões de backup das bases de dados. A alguns anos escrevi um artigo sobre isso – http://rodrigoi.org.br/backup-banco-de-dados-sql-server/ – utilizo até hoje a pratica.

Abraços,

 

 

Projeto Cloud – Balanceamento de Maquinas Virtuais, Auto escala e Sincronia de Pastas – Parte III

October 17th, 2014 No comments

Para quem hospedas sites ou sistemas na WEB uma das maiores necessidades é ter a possibilidade de balancear os acessos entre mais de um servidor (Load Balance – LB).

 

No Azure além da possibilidade dividir os acessos entre vários servidores podemos também atribuir configurações para ligar ou desligar servidores (auto escala) com base nas necessidades do ambiente. Esse recurso é muito importante para manter os custos do projeto controlados e, principalmente, para garantir que só estamos pagando o que estamos utilizando.

 

Completando a configuração precisamos manter os arquivos entre os servidores sincronizados, portanto nosso ambiente está apoiado em 3 recursos (dois ou mais servidores em balanceamento (LB) + Auto Escala + replicação de pastas)

 

I – Criação dos Servidores em LB

Para tanto o primeiro passo é configurar/criar um novo “cloud servisse”, esse recurso é um dos passos para criar um ambiente de alta disponibilidade (LB) criando um nome público pelo qual os servidores indicados responderão, é o equivalente a um Endereço virtual.

 

 

 

Em seguida partimos para a criação dos servidores (Máquinas Virtuais – VM). Onde a primeira etapa do assistente basta definir a configuração da máquina, nome e dados de acesso

A diferença está na segunda etapa, quando precisamos associar o servidor ao serviço de nuvem que criamos previamente (CLUSTER-WEB). É importante também associar o servidor a região que criamos no início do projeto (http://rodrigoi.org.br/projeto-cloud-configurando-maquinas-virtuais-no-azure-e-permissoes-de-acesso-parte-ii/) isso garantirá que esse novo recurso estará na mesma rede virtual que criamos.

Há também uma opção chamada “Conjunto de Disponibilidade” (Availability Set), a configuração dessa opção é opcional todavia é recomendada já que é esse recurso garante que no caso de uma falha de Rack seu serviço não fique indisponível uma vez que suas máquinas virtuais não estarão no mesmo Rack. Mais detalhes em : http://azure.microsoft.com/en-us/documentation/articles/virtual-machines-manage-availability/

 

 

Ao final é possível identificar que a VM está criada e foi atribuída a ela a URL que será usada no LB e que foi definida na criação do serviço de nuvem.

 

A criação do nosso segundo servidor, segundo nó da nossa solução de balanceamento, é similar a anterior.

 

Ao final identificamos que os dois servidores estão associados corretamente à nossa URL do balanceamento (LB)

 

Em seguida é necessário configurar um ponto de extremidade (porta de acesso) para permitir o acesso via LB. A configuração começa selecionando uma das máquinas virtuais e criando um novo ponto de extremidade

Em nosso exemplo criaremos o acesso ao protocolo HTTP (porta 80) para disponibilizar nosso site/sistema via WEB. A atenção nessa etapa fica na marcação da opção de criação de um conjunto de balanceamento de carga

Ao selecionar essa opção o assistente abre uma nova opção onde será configurado o nome para esse item do LB, em nosso exemplo repetimos o nome HTTP, bem como as configurações de Probe (configuração para monitorar o recursos e identificar se este está disponível ou não)

 

No segundo servidor repetimos as configurações mas iniciando a seleção com o ponto de extremidade que acabamos de criar.

 

Ao final, se avaliarmos o serviço de nuvem criado para o LB poderemos identificar que as duas maquinas virtuais estão atribuídas corretamente a esse recurso.

 

 

Qualquer acesso à url http://cluster-web.cloudapp.net/ será respondida por um dos servidores (nós) do nosso LB.

 

II – Configuração de Auto Escala

 

Em seguida precisamos configurar o recurso de Auto Escala. É com esse recurso que criaremos regras para garantir que não estaremos utilizando, e pagando, mais recursos que o necessário.

 

A configuração é feita através do serviço de nuvem que criamos inicialmente.

 

Temos duas opções de criação de escala:

 

- Escala por Agendamento: Podemos determinar em quais dias e horários uma ou mais instancias (Maquinas virtuais) estarão em execução.

A configuração é simples e intuitiva, bastando apenas definir a política que melhor atende às suas necessidades. Por exemplo, se você precisa que durante o horário comercial (definido por você) as duas instancias estejam trabalhando para melhorar o desempenho do seu site mas a noite e nos finais de semana uma instância seja desligada a configuração é feita conforme imagens abaixo:

1-     Definição de escalas, horários de expediente e fuso horário

 

2-     Atribuição das duas instancias durante o dia :

 

3 – Atribuição de uma única instancia durante a noite e finais de semana:

 

 

- Escala por Métrica: Podemos também definir a política de utilização dos recursos com base em consumo da CPU ou Fila de execução.

Por exemplo: podemos definir que somente uma instancia fique ligada e a segunda só entre em operação caso o processador da primeira esteja com carga de mais de 80%, imagem abaixo.

 

 

Se confirmarmos a regra acima e salvarmos sua configuração é possível identificar que logo após sua criação uma das instancias é parada, reduzindo portanto o gasto, e consumo, desnecessário dos nossos recursos contratados

 

 

III – Replicação de Pasta

 

Já temos nosso ambiente de alta disponibilidade configurada no Azure, com Load Balance. Também configuramos a escala automática para manter ligado somente as instancias necessárias baseadas em horário e/ou consumo de CPU, garantindo o uso racional da rede e também dos custos do projeto. Mas como vamos manter a sincronia do Site (arquivos do site) considerando que durante o dia ocorrerão mudanças e uma das instancias pode estar desligada?

 

Há muitas formas de manter dois ou mais servidores sincronizados, particularmente gosto de usar o serviço de DFS replication, que é nativo Windows. Com esse serviço consigo garantir a sincronia das pastas que atendem aos meus sites.

É importante reforçar que para utilização desse serviço é necessário que os servidores estejam em um mesmo domínio.

OBS. No nosso projeto há uma base de dados SQL responsável pelo conteúdo dinâmico do site, esse ambiente é atendido por um servidor de SQL exclusivo, assunto para um próximo artigo …

 

A criação da replicação entre pastas de dois, ou mais, servidores é feita seguindo os seguintes passos:

1 – Criação de um grupo de replicação;

 

2 – Atribuição do nome do grupo de replicação;

 

3 – Seleção dos computadores que replicação as pastas

 

 

4 – Definição do sentido da replicação.

 

5 – Configuração do consumo de banda da replicação

 

6 – Definição do computador “primário” para replicação (essa opção só é necessária para o início da replicação).

 

7 – Definição da pasta, ou pastas, no primeiro nó que serão objetos da replicação

 

8 – Definição da pasta, ou pastas, no segundo nó que serão objetos da replicação

 

 

 

8 – Confirmação das configurações

 

Replicação configurada !

Dica: se o volume de alteração for alto você terá melhoria do desempenha da replicação alterando o tamanho da cota de staging

 

 

Agora que já temos nossos servidores WEB configurado em Load Balance (LB) com políticas de Auto Escala e sincronia das pastas dos sites precisamos apenas copiar o conteúdo do site/sistema para a pasta indicada em apenas um dos servidores, configurar o IIS e apontar o seu endereço de DNS para o CNAME cluster-web.cloudapp.net, com isso já teremos o site funcionando em alta disponibilidade.

 

Agora que o primeiro ambiente está criado, precisamos ajustar a salvaguarda dos dados (Backup) !!!  Próximo artigo ;)

 

Abraços,

Projeto Cloud – Configurando Maquinas Virtuais no Azure e Permissões de Acesso – Parte II

October 6th, 2014 No comments

Maquinas Virtuais no Azure e segurança de acesso.

 

Com a interconexão entre nossa rede local e o Azure (http://rodrigoi.org.br/projeto-cloud-infraestrutura-hibrida-parte-i/) estabelecida o próximo passo do nosso projeto é criar os servidores.

Inicialmente criaremos o servidor de Domain Controller (RODC) desta forma conseguiremos otimizar o uso da interconexão (VPN Site-to-Site) estabelecida entre as duas redes uma vez que várias das funções de domínio serão realizadas localmente no Azure.

A configuração do RODC não é objeto desse artigo, na internet há uma vasta documentação a respeito uma vez que esse procedimento é antigo e amplamente conhecido. (Ex. http://technet.microsoft.com/pt-br/Library/cc754629(v=ws.10).aspx). Vamos nos concentrar nas partes referentes ao Azure…

 

A criação da Máquina virtual pode ser feita de algumas formas:

- Criação Rápida – Onde você informa somente configurações básicas como Nome, Usuário, Senha e região;

- Da Galeria – Onde você informar configurações mais completas, principalmente sobre a rede onde a máquina virtual configurada.

 

Optamos pela opção “da galeria” para garantir que a máquina virtual será configurada em conformidade com as redes criamos na interconexão. Com a opção selecionada, mais uma vez, entramos no assistente que nos conduzirá na criação do Servidor.

 

1 – O primeiro passo é definir qual imagem será utilizada para criação do servidor.

 

2 – Em seguida informamos o nome do servidor, seu tamanho e dados de acesso (login e senha)

3 -  A próxima etapa também é simples entretanto é muito importante. Nessa etapa definimos a região onde o servidor será configurado. Em nosso exemplo queremos que o servidor seja colocado na rede que montamos durante o procedimento de VPN (Cloud-RedeLocal) essa marcação garantirá que além do servidor ser configurado no datacenter que você já determinou também fará com que essa máquina receba um IP da rede definida na interconexão. Ao escolher a rede virtual definida as configurações de sub-redes são automaticamente atribuídas.

É nessa etapa também que configuramos as “portas” de firewall para acesso ao servidor. Deixaremos nesse momento as configurações padrão.

 

 

4 – A quarta e última etapa é onde podemos adicionar extensões à máquina virtual. Ainda há poucas opções entretanto a lista deve crescer com o tempo.

 

Confirmando todas as etapas seu servidor é configurado (leva alguns minutos) e disponibilizado na sua rede do Azure.

 

O próximo passo é confirmar algumas informações e configurarmos as permissões de acesso. Entrando no Painel da máquina recém criada identificamos que o IP Interno está na sub-rede que configuramos durante a etapa de criação da VPN, isso é importante porque uma vez que optamos por ter um RODC dentro do Azure toda s configuração de Site do AD é feita considerando a sub-rede que definimos.

 

Na opção “Pontos de Extremidade” podemos configurar as portas que estarão acessíveis pela Internet.  É importante reforçar que essa configuração não é do Firewall interno do Windows é apenas para acesso externo, uma espécie de “firewall de borda”.

 

Considerando que, nesse projeto, todos os servidores estão conectados à nossa rede local via VPN do Azure é prudente desabilitar, ou configurar para restringir a endereços IP específicos, a conexão externa via RDP.

- Para desabilitar basta excluir a opção;

 

- Para configurar um filtro de IP precisamos selecionar a regra (porta) desejada e atribuir uma configuração de ACL. Ao acrescentar uma regra de permissão todos os demais acessso serão bloqueado.

 

Uma outra abordagem, para administrar a segurança de acesso ao servidor, é configurar o Firewall Local do Windows, via IPSEC. Essa opção é muito flexível e permite criar Políticas de Grupo facilitando a administração em todos os seus servidores no Azure.

 

Localmente no servidor configuramos o Windows Firewall (com IPSEC) da seguinte forma:

- O primeiro passo, para evitar o bloqueio do acesso ao servidor, é criar as regras de permissão. Dentro do Firewall do servidor selecione a opção Connection Security Rules para entrada no assistente de configuração

 

 

Selecione a opção Custom. No próximo passo adicione os Endpoints Any para 1 e 2

 

 

Em seguida selecione a opção Do not authenticate para permitir o acesso à essa porta

Defina o protocolo e porta onde o acesso será permitido.

 

Por fim atribua um nome para essa regra

 

Repita essas etapas para cada Protocolo e Porta que deseja ter acesso via IP externo, ao final criaremos a regra de bloqueio.

Para a regra de bloqueio selecionamos a opção Isolation

 

Em seguida a opção Request authentication for ibound and outbound connections. Essa opção fará com que qualquer conexão, for a do domínio do servidor e/ou sem o certificado digital apropriado, não seja concluída de forma bem sucedida.

 

 

Selecionamos o método de autenticação, em nosso exemplo usaremos o método padrão

 

Por fim atribuímos o nome para a regra de bloqueio

 

Ao final teremos o seguinte cenário

 

Via script as mesmas regras acima podem ser criadas da seguinte forma:

 

netsh advfirewall consec add rule name=”HTTP-IN” endpoint1=any endpoint2=any action=noauthentication port2=80 protocol=tcp

netsh advfirewall consec add rule name=”HTTPS-IN” endpoint1=any endpoint2=any action=noauthentication port2=443 protocol=tcp

netsh advfirewall consec add rule name=”RDP-IN” endpoint1=any endpoint2=any action=noauthentication port2=3389 protocol=tcp

netsh advfirewall consec add rule name=”Bloqueia Acesso” endpoint1=any endpoint2=any action=requireinrequireout

 

O mesmo procedimento de criação da máquina virtual e permissões de acesso será repetido com os demais servidores do Projeto. Salvo ajustes de capacidade do servidor e, eventualmente, portas de acesso de acordo com perfil de cada serviço.

 

No próximo artigo vamos tratar as configurações dos servidores WEB funcionando em balanceamento (alta disponibilidade) bem com os recursos de Autoscale para otimizar os custos do projeto.

 

Abraço,

Projeto Cloud – Infraestrutura Hibrida – Parte I

September 30th, 2014 Comments off

Hello Cloud !!!

 

De tempos em tempos entramos em um ciclo de renovação aqui na Universidade onde avaliamos toda nossa infraestrutura lógica e física e procuramos adequá-las às novas necessidades e tecnologias. Desta forma conseguimos manter nosso ambiente atualizado, seguro, eficiente e principalmente enxuto!

 

Uma das principais diferenças desse novo ciclo de mudanças é que não estamos somente avaliando as substituições de servidores, atualização de softwares, serviços ou discos, estamos também avaliando o que precisa continuar em nosso data center (on-primeses) e o que podemos migrar para a nuvem. A decisão é complexa, precisamos avaliar com bastante critério qual o impacto em nossa infraestrutura, os custos reais da mudança, segurança e principalmente o que será afetado na entrega de serviço aos nossos usuários.

 

De fato já estamos estudando a experimentando as soluções de nuvem a algum tempo, promovemos alguns experimentos para conhecer e entender melhor os serviços oferecidos e seus impactos ao nosso cenário e, após alguns meses de testes e analises acreditamos que para o nosso cenário o momento certo é agora ! As ofertas de nuvem já estão mais maduras, conseguimos atender a quase todas as nossas necessidades técnicas e principalmente os custos começam a se mostrar uma opção competitiva.

 

Nossa estrutura lógica atual pode ser representada, de forma simplificada, com o diagrama da figura 1. Na imagem é possível identificar que nossa primeira experiência real (ambiente de produção) foi migrar o ambiente de ensino à distância (EAD) para o Cloud da Amazon (AWS). Na ocasião, quase um ano atrás, escolhemos a Amazon por ser a melhor opção disponível e o resultado foi melhor do que o esperado. Conseguimos manter a qualidade do serviço, mesmo com milhares de acesso, sem causar nenhum impacto aos demais serviços hospedados em nossa infraestrutura local.

 

 

Figura 1- Estrutura Lógica Atual – Ambiente on-primeses

 

De lá para cá a oferta de nuvem da Microsoft, Azure, deixou de ser uma promessa e se tornou um grande competidor frente a Amazon. Nos últimos meses a evolução, e maturidade, dos serviços do Azure fez com que a concorrência com a Amazon ficasse acirrada e, na minha opinião, depois que a Microsoft abriu um data center do Azure no Brasil a balança começou a pesar a favor dela.

 

Nossa decisão de utilizar o Azure está apoiada em alguns pontos:

- Considerando nosso ambiente ser quase todo Microsoft a integração de ambiente (AD, System Center, Backup e etc) se mostrou mais eficaz;

- A curva de evolução de serviços, lançamento de serviços e funcionalidades, está muito mais acelerada no Azure;

- O acesso à informação técnica e suporte são superiores aos apresentados atualmente pela Amazon;

- Os custos, nas simulações que fizemos, se apresentaram um pouco melhores no Azure;

- Licenciamento Acadêmico, por sermos uma instituição de ensino tem alguns benefícios que favorecem a adoção da solução de nuvem da Microsoft (Ex. Office 365)

 

Com a decisão pelo Azure tomada iniciamos o nosso ciclo de evolução e o primeiro passo foi definir quais serviços serão migrados para nuvem. Nessa “primeira onda” definimos nosso escopo em:

- BACKUP – Além dos backups em disco e fita, já existentes, incluiremos nas políticas o backup de dados mais sensíveis (banco de dados e etc) no Azure;

- VPN – VPN entre Azure e Rede Local;

- AD – Instalação de um RODC no Azure para ajudar nas migrações, uma vez que temos várias políticas de segurança e restrições apoiadas no AD. Inclusive a proteção de acesso baseado em IPSEC;

- Ambiente EAD (Moodle)– Migração do ambiente atual, AWS, para o Azure;

- Sites Públicos e Portais Alunos e Professores – Nossos principais sites públicos e Portais serão executados a partir do Azure. Alguns dos sites terão sua base de dados local (on-primeses) outros terão a base de dados migradas para o Azure;

- Exchange online –Migração no nosso Exchange para o Office 365

 

O modelo lógico da solução é representado, de forma simplificada, com o diagrama da figura 2.


Figura 2- Modelo Logico do Projeto do Azure (primeira onda)

 

O projeto já está em andamento e pretendo compartilhar as principais etapas, problemas, e soluções que encontramos para atingir cada um dos objetivos propostos. Nessa série de artigos vou me concentrar apenas na migração para o Azure, as demais evoluções internas (novo cluster de Máquinas virtuais, upgrade do Banco de Dados e etc) deixarei para compartilhar com vocês em outro momento. Vamos lá …

 

Como o nosso projeto tem como um dos pilares manter as políticas de segurança atual optamos por colocar um Domain Controller (DC), mais especificamente um Read-Only Domain Controller (RODC), no Azure. Para tanto é necessário estabelecer uma conexão segura entre a nossa rede local e a nuvem, e no Azure essa opção se chama “Rede Virtual”.

No Azure é possível criar dois tipos de uma conexão VPN :

- Ponto a site – Conexão de um cliente VPN à sua estrutura no Azure. Essa é uma excelente opção para quando seu nível de segurança restringe o uso de acesso remoto, via RDP, pelo endereço público dos servidores.

- Site a Site – Conexão entre sua empresa e a sua rede no Azure. Essa é a opção que melhor se encaixa as nossas necessidades, desta forma podemos criar no Azure uma extensão da nossa rede local.

 

Como em todos os assistentes da Microsoft o processo é rápido e simples, sendo necessário apenas atenção em alguns pontos. As etapas são:

 

1 – O primeiro passo é criar o nome do objeto, no caso um objeto de rede virtual, e o local. O local é a região onde serão criados os seus recursos. No Brasil ainda não temos todos os recursos disponíveis, ex. Backup (falaremos em outro artigo), entretanto a opção de VPN já pode ser feita para a nossa região.

OBS. Para esse artigo estou utilizando minha conta pessoal do Azure, como assinante do MSDN, nesta assinatura a região do Brasil não está disponível portanto os exemplos serão feitos considerando a região Centro Sul dos Estados Unidos

2 – Nesta etapa devemos selecionar a opção do tipo de VPN, no nosso caso site a site. Também há a opção de indicar o endereço de um servidor DNS, esse endereço pode ser de um servidor da sua rede local o que facilitará a resolução de nomes internos feita pelos servidores do Azure.

No Brasil ainda não está disponível, até a data desse artigo, a opção de Rota Expressa entretanto já existe fornecedores locais trabalhando para, em breve, disponibilizar o serviço. Podemos acompanhar os valores e futuros fornecedores através do site https://azure.microsoft.com/pt-br/pricing/details/expressroute/


3 – Em seguida criaremos as informações da sua rede local e para onde a VPN do Azure deverá “discar”. Em nosso cenário incluirmos a rede dos servidores, Ex. 192.168.1.x/24.

4 – No último passo devemos criar a nossa rede no Azure, essa etapa é muito importante porque uma vez criada colocaremos todos os nossos servidores do Azure (Vms) nessa rede. Ainda em nosso exemplo criamos a rede 192.168.2.0/24 para os servidores do Azure.

 

A VPN está criada contudo é necessário mais um passo, criarmos o Gateway. É nessa etapa que um IP valido é atribuído à sua VPN, a etapa é simples entretanto pode demorar até 15 minutos.

O Azure oferece dois modelos de roteamento, Estático e Dinâmico. As diferenças são as mesmas conceituais de qualquer roteamento em rede IP:

- Roteamento Estático – As configurações de rota são manuais e não fazem uso de nenhum protocolo com roteamento dinâmico

- Roteamento Dinâmico – Rotas são criadas dinamicamente, há otimização de rotas é sensível às mudanças de rede.

 

Em nosso exemplo vamos optar pelo Roteamento Dinâmico.

 

 

Ao final do procedimento de criação do gateway seu IP válido será apresentado. Essa é uma das informações necessárias para criação da VPN do lado da rede Local

A outra informação é a chave se será compartilhada entre as pontas da VPN.

 

O Azure oferece scripts de configuração para alguns fabricantes de Firewall o que facilita muito sua adoção.

 

Nossa solução de Firewall foi, recentemente, migrada do Microsoft TMG para o Sonicwall (pretendo escrever sobre esse processo de migração do firewall em breve) e para o nosso cenário não há – ainda – script de configuração disponível todavia há uma excelente documentação sobre como configurar a VPN no Sonicwall para se conectar ao Azure, o acesso a essa documentação pode ser feita pelo link : http://www.sonicwall.org.cn/downloads/Configure_SonicOS_for_MS_Azure_Rev_A.pdf

 

Com a configuração do Sonicwall concluída a conexão é estabelecida e o canal VPN está disponível para uso !

 

 

Nossa conexão segura com ao Azure está criada agora podemos começar a criar, e configurar, os servidores e serviços definidos em projeto. Nossa primeira VM será o RODC mas isso é assunto para o próximo artigo, até lá !

 

Abraço,

 

O verdadeiro problema por trás da atualização do W7 (KB2823324)

April 11th, 2013 Comments off

A semana começou agitada para quem utiliza o Windows 7.

Na última terça feira uma atualização (KB2823324) disponibilizada pela Microsoft estaria causando indisponibilidade do sistema após a reinicialização (a temida tela azul !).

A notícia do problema, e algumas soluções de contorno, se espalharam rapidamente :

http://www.tecmundo.com.br/windows-7/38456-atualizacao-do-windows-7-pode-inutilizar-o-seu-computador.htm

http://www.baboo.com.br/2013/04/atualizacao-kb2823324-para-windows-7-causa-danos-ao-pc/

http://social.technet.microsoft.com/Forums/pt-BR/winvistapt/thread/a8a900f5-a5b2-45bb-8ac5-b1b3afb22ad7

Todos os indícios apontavam que o problema ocorria somente na versão 32bits do Windows 7 em português, fato no mínimo curioso já que desde o Windows Vista o windows é “Multilingual“.

Passado o pânico inicial é importante identificar a verdadeira causa do problema…

No Brasil vários bancos utilizam um software chamado Guardião. O objetivo desse software e trazer segurança para os clientes do banco quando acessam suas contas pela Internet. Entretanto esse software é tema de constantes discussões nas comunidades de segurança devido ao fato de ter  um comportamento similar ao de um malware e ser de uso obrigatório.

Cada Banco possui uma versão do Gardião específica. Algumas versões, menos intrusivas, requisitam que apenas uma DLL seja instalada:

Outras todavia solicitam a instalação de um executável, que fica ativo sempre que sua máquina é iniciada, mesmo que você não esteja acessando o banco.

 

O problema desta semana (KB2823324) , atribuído precipitadamente à Microsoft, não está na versão distribuída pelo Windows Update mas parece estar no software Guardião, que impede a execução correta do procedimento.

Aqui na Universidade simulamos o problema considerando os seguintes cenários :

Windows 7 (português) com Guardião – Tela Azul !

Windows 7 (português) sem Guardião – Atualizado sem problemas

Windows 7 (inglês) com Guardião – Tela Azul !

Windows 7 (inglês) sem Guardião – Atualizado sem problemas

Além do Guardião outros softwares, que possuem o mesmo comportamento, podem estar causando o problema. Segundo o site da Linha Defensiva, há relatos de outros produtos que podem estar impedindo que a atualização seja realizada,

http://www.linhadefensiva.org/2013/04/teste-mostra-incompatibilidade-de-atualizacao-com-plugin-bancario/

Este problema vai reacender a discussão em torno dos  Softwares de segurança,  novos rounds estão por vir …

Abraço,

 

 

 

 

 

 

 

 

 

Minhas Palestras no Teched Brasil 2011

October 7th, 2011 Comments off

Esse ano participei com 3 palestras e também como co-owner, junto do meu amigo Fabio Hara, das palestras de segurança.

Agradeço a todos que estiveram nas minhas palestras e, conforme combinamos, estou disponibilizando os links com os PPTs, enjoy !

- Configurando o DirectAccess em 30min (QS31)

- Como Montar um Ambiente de Alta Disponibilidade com o Hyper-v (VIR303)

- O Futuro da Plataforma de Infraestrutura da Microsoft (SRV202)
* Palestra feita com o meu amigo Airton Leal

Abraços,

Como melhorar a Segurança da Rede com algumas soluções da Microsoft

June 14th, 2011 Comments off

Garantir a segurança dos dados e sistemas de uma empresa é um dos grandes desafios dos profissionais que atuam na área de Segurança da Tecnologia da Informação (Security IT).

A preocupação em atender algumas demandas vivenciadas pelas empresas é fundamental. Saber quem são seus usuários e ativos de redes se torna um problema na realidade atual onde acesso remoto, wireless, várias filiais e sistemas distribuídos são uma realidade nas empresas. O modelo tradicional, figura abaixo, usado para “garantir” a segurança de um ambiente tinha como ponto principal isolar o acesso entre sua rede e a Internet com o uso de um Firewall.

Entretanto a realidade atual é um pouco mais complexa. O aumento das necessidades de interconexões entre redes, devices e etc, está forçando a nos preocupar na segurança mais próxima do cliente (host), vocês já devem ter ouvido falar em “Defesa em Profundidade”. Apoiado nas tecnologias da Microsoft como podemos reduzir os riscos de segurança no seu ambiente?

 

Public Key Infrastructure (PKI)

Alguns dos principais projetos de segurança envolvem o uso de Certificados Digitais. Em alguns projetos de segurança a utilização de Certificados Digitais permite uma interoperabilidade entre diversas plataformas, por exemplo: um projeto de Isolamento de Servidores e Domínio, com IPSEC, o uso de Certificados Digitais permite trabalhar tanto com máquinas Windows como Linux.

Alguns dos Projetos de Segurança mais comuns, utilizando as Tecnologias da Microsoft, que se beneficiam de uma estrutura de PKI são :

- Autenticação com 2 fatores;

- IPSEC com Certificado Digital;

- NAP com Certificado Digital;

- Right Management Service (RMS);

Projeto de PKI ( Certificação Digital)
Objetivos Requisitos
- Criar uma estrutura de Servidores com o papel de autoridades certificadores para a rede local;- Implementar e configurar certificados digitais para diversos serviços da rede como IPSEC, NAP, Wireless, SSL, RMS, DirectAccess e etc;- Implementar autenticação com mais de um fator, utilizando Smartcard ou Token. Aos servidores e/ou estações de trabalho; Windows 2008 R2

 

Sua Rede Interna está segura ?

Você consegue garantir que, agora, em sua rede somente máquinas que você conhece estão conectadas e utilizando seus recursos e servidores ? Agora imagine esse cenário em uma empresa onde existem vários prédios, milhares de pontos de rede, centenas de Access Point (AP) para acesso Wireless, dezenas de empresas parceiras trabalhando em projetos conjunto e etc. Server and Domain isolation(usando IPSEC e group policy), essa é a solução para endereçarmos problemas como esse.

Um cenário típico de aplicação dessa solução é o que encontramos na figura abaixo.

 

Nesse exemplo temos a necessidade de garantir o acesso aos servidores e dados da rede interna somente para máquina confiáveis, maquinas do nosso domínio.

O objetivo secundário é de isolar, dentro da rede já protegida criada pelo IPSEC, o acesso ao servidor de código fonte a um grupo restrito de máquinas e com o máximo de segurança, no caso com todo o tráfego criptografado.

Como o Internet Protocol Security (IPSEC) funciona na camada de rede do protocolo, abaixo da camada de aplicação, o trafego pode ser autenticado ou criptografado, de maneira centralizada com group policy no Active Directory.

 

Projeto de IPSEC ( Isolamento de Servidores e Domínio)
Objetivos Requisitos
- Aumentar a segurança da rede local permitindo o acesso aos computadores somente de máquinas cadastradas (confiáveis);- Isolamento de Servidores críticos para acesso somente de um conjunto de computadores autorizados;- Criptografar todo o tráfego de dados; Active Directory

 

Sua Rede Wireless está segura ?

Com o crescente aumento dos notebooks e dispositivos móveis nas empresas ter uma rede Wireless internamente não é mais uma opção. O gerenciamento centralizado dos computadores e/ou usuários que terão acesso ao seu ambiente Wireless é determinante garantir a segurança de todo o seu ambiente.

 

A implementação de um servidor RADIUS é necessária para que, de maneira centralizada, você possa criar políticas de acesso e segurança (incluindo a exigência de Certificados Digitais, caso você tenha uma solução de PKI implementada), no Windows 2008 R2 devemos utilizar a Role Network Policy and Access Services.

 

Wireless Segura
Objetivos Requisitos
- Configurar uma rede wireless segura;- Restringir o acesso à rede Wireless somente para computadores cadastrados;- Fazer o deploy de maneira centralizada e automática para os clientes; Windows 2008 R2

 

O computador que acessa seus dados está saudável ?

 

Nos ambientes tradicionais já existe vários níveis de proteção, Firewall de Borda, DMZ e etc, todavia a maior frequência das ocorrências de segurança estão no nível do Host (máquina do usuário). Para endereçar essa questão a Microsoft, a partir da Versão 2008 do Windows Server, lançou o Network Access Protection, com o NAP podemos definir estados de “saúde” dos computadores e com isso garantir que somente máquinas que estejam em conformidade com as políticas da rede possam ter acesso aos dados e servidores em sua rede local. Os exemplos mais comuns são de garantir que a máquina precisa estar atualizada (atualizações do Windows), anti-virus ligado e atualizado e também firewall ativo.

Trabalhando com centenas de parceiros a Microsoft permite que o NAP seja estendido á vários produtos do mercado, como anti-virus, analisadores de rede, e etc.

 

Network Access Protection (NAP)
Objetivos Requisitos
- Garantir que somente máquinas que estão em conformidade com a políticas de rede possa ter acesso à rede local;- Máquinas que não estão “saudáveis” são corrigidos automaticamente;- Melhorar a segurança para clientes remotos, como consultores e vendedores externos (Notebooks); Windows 2008 R2

 

Como oferecer ao seu usuário acesso remoto seguro ?

Oferecer os recursos para que os funcionários da sua empresa tenham sempre acesso, de forma segura, às informações necessárias para que seus trabalhos sejam realizados é determinante nos tempos atuais.

A forma mais tradicional e usada é disponibilizar o acesso via VPN (Virtual Private Network), todavia nesse tipo de acesso temos uma exposição maior devido a fragilidade das senhas de acesso, independente da política de senhas que sua empresa utiliza (senhas fortes, caracteres especiais e etc) é indiscutível que restringir o acesso a mais de um fator é a melhor forma de mitigar esse problema. Utilizando de recursos de PKI, requisito para essa solução, podemos garantir que somente usuários com o Certificado, ou token de acesso, conseguirão se autenticar remotamente na sua empresa.

 

Acesso Remoto Seguro (VPN + PKI)
Objetivos Requisitos
- Garantir acesso remoto seguro (VPN);- Acesso remoto somente para usuários autorizados e com Certificado Digital; Windows 2008 R2PKI

E os ataques de Phishing não param

June 5th, 2011 Comments off

Hoje recebi mais um email de Phishing, todavia fiquei impressionado com a “qualidade” do site, vamos analisar a anatomia do ataque. Este foi o email que recebi, tentador para os usuário do programa de milhagem da TAM;

Clicando do email somos direcionados para o suposto site da TAM;

Essa foi a parte que me impressionou, reparem que o site é muito bem feito, uma cópia quase que perfeita do site oficial da TAM, os links dos menus a esquerda está corretos e direcionando para o site oficial ;

 

Mas porque é necessário colocar a assinatura eletrônica e a senha de resgate no cadastramento de promoção ???  Infelizmente imagino que muitas pessoas não farão esse questionamento e serão vitimas desse ataque.

Abri o link nos 3 browsers que utilizo, Internet Explorer, Google Chrome e Firefox, e até o momento deste post nenhum deles identificou o link como um risco para o usuário.

 

 

 

Olhando com um pouco mais de atenção podemos verificar que a URL é estranha

 

Se procurarmos pelo domínio somos direcionados para um site de automóveis no exterior, provavelmente este site não pertence mais a eles e já está em comprometido;

Mas o que um profissional de TI pode fazer quando encontra um ataque como esse ?

1 – Cadastrei o site para análise no serviço de SMARTSCREEN da Microsoft, acredito que em pouco tempo este ataque não terá tanta eficácia para os usuários do IE;

2 – Enviei as informações, com mais detalhes, para a TAM;

3 – E principalmente informei os usuário da minha rede, domínio onde recebi o email com o Phishing;

Abraços,

Livro de Segurança (Autor Brasileiro !)

May 27th, 2011 Comments off

livroQuem trabalha e estuda a disciplina de segurança sabe o quanto é difícil bons livros de autores nacionais, todavia tive uma excelente experiência lendo o livro dos meus amigos Yuri Diógenes e Alberto Oliveira (Revisor Técnico), o livro tem uma didática muito boa, a leitura é agradável e fácil.

 

Um ponto forte são as seções “1 a 1 com o autor”, onde os autores passam dicas e experiências práticas que fortalece o entendimento do assunto.

 

Definitivamente recomendo a leitura !

 

Abraços,

Categories: Uncategorized Tags: , ,

Projeto Baboo 2.0

December 17th, 2010 Comments off

 

Em Julho de 2010 o Baboo me procurou sobre sua necessidade de fazer uma grande atualização em seu ambiente.

A proposta era uma atualização total, que seria desde as configurações dos servidores, sistema operacional até mesmo os softwares utilizados no ambiente e serviços dos sites do Baboo.

Confesso que fiquei bastante motivado com a idéia desse projeto, afinal eu sabia que o site do Baboo (www.baboo.com.br ) tem mais de 1,2 milhões de acessos/mês e o Forum (http://www.babooforum.com.br/forum/) tem mais de 4,2 milhões de internautas / mês.

*** com o novo ambiente a VM de SMTP envia mais de 540 mil mensagens em menos de 4 horas !  Rápido o suficiente para não criar nenhum fila …

A diretriz do Baboo era simples, “temos de montar um ambiente com melhor performace e segurança para suportar o crescimento e novos ambientes que vamos colocar no ar”, e com base em todo esse cenário nasceu o projeto Baboo 2.0

Finalizei o projeto, implementação e migração do ambiente antigo para o novo em meados de setembro e tudo correu como o esperado. Separei algumas informações interessantes para vocês conhecerem um pouco mais do projeto, enjoy !

Abraços ,

Infraestrutura e segurança dos servidores do Baboo 2.0

Diante da constante evolução e crescimento do ambiente de TI, torna-se imprescindível zelar pela segurança da informação e mitigar riscos provenientes desse mundo “inseguro”, tais como acesso indevido, fraudes, sabotagens, vírus, indisponibilidade, quebra de sigilo, ataques externos e consequentes prejuízos financeiros e de imagem, com essa premissa o novo projeto de infraestrutura para os sites do Baboo está apoiado sobre o tripé clássico da segurança da informação:

· Confidencialidade: controle de acesso às informações, garantindo o sigilo e o uso adequado das informações;

· Disponibilidade: garantia de que a informação esteja sempre disponível quando os usuários e/ou clientes necessitarem;

· Integridade: garantia de que as informações estarão corretas quando chegarem aos usuários ou clientes;

Abaixo segue uma ilustração do modelo lógico e físico do novo ambiente:

Segurança do Hardware

 

Hospedado em um dos melhores data centers em operação nos Estados Unidos (www.peer1.com) todo o ambiente do Baboo está coberto por todos itens de segurança física, seguindo padrões mundiais de excelência (redundância de link, data center de alta segurança, autonomia de energia, etc).

Segurança Lógica

Todo o acesso aos sites e serviços do Baboo passam por um firewall de borda, configurador e monitoramento constantemente pela equipe de segurança interna da Peer1 e também pela equipe do Baboo;

Todos os servidores, individualmente, foram configurados – procedimento de hardening – seguindo as recomendações de segurança da Microsoft.

Toda a comunicação interna entre os servidores está protegida por políticas de IPSEC.

A equipe do Baboo faz auditorias de segurança regularmente, considerando as vulnerabilidades recentes, para verificar e garantir que o ambiente esteja seguro em relação as mais novas técnicas de ataque.

Todo ambiente é monitorado pró-ativamente por profissionais altamente capacitados e detentores de certificações internacionais de segurança.

A política de backup é executada em conjunto entre a equipe do Baboo e o data center – Peer1 – para garantir que todos os dados necessários estejam verificados e armazenados em segurança, de acordo com a frequência e demanda existente.

Disponibilidade do Ambiente

 

Além do contrato de SLA firmado com o Datacenter – Peer1 – todos os servidores possuem estrutura de redundância de discos, minimizando substancialmente qualquer risco de indisponibilidade do serviço devido a problemas em discos.