Active Directory Federation Services da Microsoft

Hoje vamos falar um pouco sobre o ADFS, Active Directory Federation Services da Microsoft.

O AD FS é um serviço baseado em padrões, que permite o compartilhamento seguro de informações de identidade entre parceiros de negócios confiáveis (conhecidos como Federação) em uma extranet. Quando um usuário precisa acessar um aplicativo Web de um de seus parceiros de Federação, a própria organização do usuário é responsável por autenticá-lo e fornecer informações de identidade na forma de “Claims”, para o parceiro que hospeda o aplicativo Web. O parceiro de hospedagem usa sua diretiva de confiança para mapear as declarações de entrada para declarações que são compreendidas pelo seu aplicativo da Web, que usa as declarações para tomar decisões de autorização.

Resumindo, já pensou ter vários serviços como Office 365, Azure, AWS e Google GSuite todos utilizando o mesmo login, isso mesmo, o mesmo login da sua rede Active Directory. Tudo isso e ainda contar com duplo fator de autenticação usando Google Autenticator ou Microsoft Autenticator?

A proposta do ADFS é justamente essa, trazer cada vez mais integração ao Active Diretory com ferramentas externas e tornar o SSO (Login Único) o mais seguro possível.

O ADFS portal, é basicamente um portal para autenticação dos usuários em ferramentas de terceiros, cada aplicação tem sua forma de autenticação, se formos falar de AWS, após criar as roles necessárias, os usuários acessarão o portal ADFS e serão redirecionados para a AWS após autenticação, se formos falar de O365 e Gsuite, o usuário faz o login no portal O365/Gsuite e é redirecionado automaticamente para autenticação no ADFS Portal.

A Darede já possui a bagagem técnica necessária para implantação, customização e administração do seu ambiente ADFS, a infraestrutura inicial para até 1000 usuários é de certa forma simples. Você precisará de alguns itens básicos de infraestrutura que são eles:

• Ambiente rodando Microsoft Active Directory com pelos menos 2 domain controllers;
• Servidor dedicado com ip válido com poucos recursos executando o ADFS Proxy;
• Servidor dedicado ou domain controller executando ADFS Server;
• Certificado Wildcard Válido,

Existem alguns fatores importantes frente a segurança nesse cenário, recomenda-se subir a infraestrutura em um ambiente em nuvem (AWS/Azure), com isso garante-se disponibilidade do portal de autenticação em casos de falha na estrutura On-Premise. Outra dica valiosa, é manter o ADFS Proxy isolado ao Active Directory, ou seja, o servidor deve permanecer em WorkGroup evitando assim em uma hipótese de invasão, seu ambiente AD está seguro.

Por fim, aplicar uma solução WAF (Web Application Firewall) que garante tranquilidade e segurança para os administradores.

Agora que já falamos bastante sobre a federação, vamos a um exemplo prático de como ela acontece, no exemplo abaixo vamos realizar o login no portal AWS:

Para isso, bastará acessar o portal ADFS da sua organização:

Após escolher a aplicação AWS – Amazon Web Services, o usuário é redirecionado a tela de login, onde deve-se inserir as credenciais de domínio AD:

Como sempre usamos o MFA para esse tipo de acesso, o usuário será redirecionado para a tela de inserção de código de acesso que já foi previamente cadastrada:

Automaticamente após inserir o código MFA corretamente o usuário é direcionado ao console AWS:

Viram, o processo de autenticação ADFS é fácil e seguro. Venham executar seu projeto de Federação Conosco!

Afinal, o que é Cloud?

O termo tem uma conotação muito abrangente e nos últimos anos um apelo de Marketing muito maior que uma definição técnica, tudo hoje é relacionado com Cloud/Nuvem com o intuito de agregar valor comercial ao produto ofertado.
Qualquer definição dada ao termo pode ser contestada, uma vez que não existe um órgão, instituição ou comitê que especifique termos de tecnologia, até projetos como o Techterms e Wikipédia, são a opinião de pessoas a respeito do uso do termo e não uma unanimidade. Assim o conteúdo desse artigo é nossa opinião sobre o uso do termo Cloud e mais importante nossa definição do que ”Cloud Computing” (que para nós são coisas diferentes).


O início

Desde o primeiro diagrama de tecnologia que vi, o desenho da nuvem representa a Internet ou uma conexão WAN (externa à rede Interna):


Diagrama/Topologia de Rede de Exemplo

Fica claro então, que Cloud está relacionado a rede pública, ou o que está externo ao ambiente de rede interna.
Muito antes do termo Cloud ser usado, serviços já eram oferecidos na Internet, como hospedagem de sites, email, streaming de vídeo, etc. Tudo mudou com o conceito de ”Cloud Computing”, que foi largamente difundido com o lançamento dos primeiros produtos da AWS (Amazon Web Services).

Com o sucesso dos produtos da AWS e da popularização do termo, outros serviços passaram a ser associado a Cloud, inclusive serviços de Internet que já existiam se associaram ao termo Cloud como apelo de Marketing e como símbolo de inovação.

Como diversos produtos são associados ao termo Cloud, organizamos eles em grupos, ou tipos de produtos Cloud. Uma abordagem mais utilizada (inclusive pela Microsoft) organiza os produtos Cloud em:

• OnPremise: Ao que está desassociado da nuvem, fora da Cloud;
• Infrastucture As A Service (IaaS): Quando os equipamentos, ou Infraestrutura, são oferecidos como serviço, e o Sistema Operacional (Windows, Linux, etc) é responsabilidade nossa (quem contrata);
• Plataform As A Service (PaaS): Aqui o Sistema Operacional não é responsabilidade do cliente, não temos acesso ao Windows/Linux, usamos por exemplo, apenas o Banco de Dados, Servidor Web, etc.
• Software As A Service (SaaS): Aplicação completa oferecida como serviço, o cliente apenas consome o App, exemplo são ERP, Serviço de Email, Spotfy, Netflix, etc.


Fonte: https://azure.microsoft.com/pt-br/overview/what-is-paas/

Porém para nós da Darede, a visão acima não é o melhor agrupamento, uma vez que não agrupa serviços que devem/podem ser comparados entre si, e a linha entre eles é muito tênue e pode causar confusões. Entendemos que o melhor agrupamento dos serviços de Cloud são:

• Cloud Computing: Aqui é o que a maior parte dos profissionais de TI entendem por Cloud, funciona como uma terceirização de hardware. Porém diferente de colocation, VPS e Servidor dedicado, que já existiam antes do conceito de ”Cloud Computing”, aqui falamos em:
o AWS,
o Azure,
o e Google Cloud Platform.

• Licenciamento como Serviço (LaaS): É muito comum ver software sendo vendidos ‘em Cloud’. A ideia aqui é pagar pelo tempo que usa e não um valor pela aquisição de licença como o antigo modelo praticado desde a década de 80. A receita tem sido boa tanto para quem vende, como para quem compra. Exemplos de LaaS:
o Adobe,
o Pacote Office,
o AutoCAD

• Software como Serviço (SaaS): Aqui incluímos sistemas que são contratados como serviço e hospedados na Internet. O fornecedor usa sua grande infraestrutura de equipamentos e vende em pequenas fatias, por exemplo $1 por usuário por mês. Aqui alguns produtos em SaaS:
o Google G Suite,
o Office 365,
o Pipedrive,
o SalesForce
o Dropbox,
o Spotfy,
o Netflix

Agora fica mais fácil entender qual ‘Set’ de produtos você irá utilizar em cada um dos Modelos de Cloud, ou usar onPremise se fizer sentido.

Aqui algumas perguntas que pode lhe ajudar a montar esse ‘Set’ de fornecedores de serviços em cloud:
1. Utilizar email corporativo próprio ou SaaS?
2. Adquirir uma licença de 10 mil reais ou pagar 200 reais por mês para usa-la?
3. Qual fornecedor de “Cloud Computing” usar?
4. Hospedar uma aplicação onPremise ou em “Cloud Computing”?
5. Vou armazenar meus arquivos onPremise, em “Cloud Computing” ou usando algum SaaS?

Cloud Computing
Agora vamos nos aprofundar um pouco em ”Cloud Computing”, que é a maior área de atuação Darede, pois está diretamente associada ao uso de poder computacional para nossas aplicações.

É muito comum ver fornecedores de serviços de Infraestrutura na Internet que se intitula “Cloud Computing”, quando está na verdade oferecendo produtos anteriores a “Cloud Computing” abaixo exemplo de produtos que NÃO SÃO “Cloud Computing”:

• Colocation: Espaço com energia, ar-condicionado e acesso à Internet para instalarmos nosso computador;
• Servidor Dedicado: Quando o servidor é instalado na estrutura do provedor de serviço e nós temos acesso ao Sistema Operacional;
• VPS: Sigla para Virtual Private Server, que é simplesmente um servidor virtual contratado como serviço;
Mas afinal, qual o limite entre Cloud Computing e Infraestrutura com Serviço na Internet? Entendemos que para ser considerado “Cloud Computing”, o produto precisa ter, no mínimo:
• Política do “Pague somente pelo que use”;
• Capacidade Ilimitada* de crescimento imediato;
• Estrutura “scriptável” onde é possível interagir com 100% através de APIs, ou outro método.

*Capacidade Ilimitada pode ser muito abrangente, afinal sempre há um ou alguns limites, mas o que quero dizer, é ter uma capacidade disponível de centenas ou milhares de vezes maior que a capacidade mínima contratada.
Com isso, muitos de vocês que estão lendo devem ter percebido (e esse é o intuito principal desse artigo), que Cloud Computing é muito mais que Infraestrutura Como Serviço na Internet e talvez até descoberto coisas que não sabia! =)

Aqui uma lista de coisa que você pode fazer com “Cloud Computing” e talvez não soubesse:

• Pagar por servidor por segundo ligado (sim se um servidor fica liga 90 segundos, você pagará apenas por esses segundos, caso desligue, para de pagar);
• Aumentar sua capacidade computacional em 10, 100, 1000 vezes por apenas algumas horas e pagar somente por isso;
• Possuir um site de contingência pagando R$0, e pagar por ele apenas pelos dias utilizados (e se forem utilizados);
• Hospedar sua aplicação em Datacenters distintos sem pagar nada por isso;
• Criar um script para subir uma estrutura em poucos segundos, seja ela de 1 serviço/servidor ou de centenas de milhares;
• Ter a mesma capacidade computacional de empresas referência em tecnologia e inovação (como Amazon, americanas.com.br, MercadoLivre, R7) pagando proporcionalmente ao tamanho do seu negócio;
• Fazer seu backup pagando U$0,004 (sim, menos de meio centavo);
• Ter velocidade de Internet ILIMITADA!


Flávio Rescia
Gerente de Operações
flavio.rescia@darede.com.br

Sócio Fundador Darede, graduado em Redes de Computador e Sistemas de Informação, ministra aulas de Redes de Computador no SENAI e possuí vasta experiência com provedores de Internet, tecnologia para mercado financeiro e Cloud Computing.

Parte 2: O que você precisa, Office 365 ou Exchange Server?

Levantamos os custos de cada um dos itens envolvidos em uma solução de Exchange Server e montamos uma planilha que pode ser baixada sem custo aqui. Dessa forma conseguimos uma estimativa do custo inicial (lembrando que o ideal é trabalhar com depreciação total em 36 meses) de ambas as soluções conforme imagem abaixo:

Assim conseguimos comparar os planos para pequenas e médias empresas (Business) onde chegamos ao comparativo abaixo, como esses planos são limitados a 300 contas, limitamos dessa forma:

Para fazer o comparativo acima, dividimos o investimento inicial por 36 (número de meses até a necessidade de troca dos equipamentos e licenças).

Agora para planos Enterprise (E1,E3 e E5) não há limite de contas, caso você não precise do pacote Office Offline, temos o ponto de encontro próximo há 300 contas. Coincidência, não?

Agora se você precisa do pacote Office Offline temos duas opções:
• Exchange Server + Pacote Office (em nosso exemplo usamos o standard)
• Office 365 Business ou >E3

Assim fizemos uma comparativo para essas opções, com o valor do Office Standard mentalizado (valor dividido por 36 meses) lembrando que o Business Essentials permite apenas 300 contas:

Considerações
Não consideramos custo com backup para solução com Exchange Server por entender que uma possível contingência e o de recursos do próprio Exchange Server (como archive e journaling) se equiparam a funcionalidades do Office 365.
O valor com Microsoft Windows foi considerado no valor do servidor.

Conclusão
Dessa forma, conseguimos chegar às seguinte conclusões:
• Do ponto de vista de funcionalidades, ambas as soluções possuem suas vantagens e desvantagens;
• Os custos iniciais com Exchange Server são sempre muito elevados;
• Para empresas com poucos usuários, o uso de Exchange não possuí um bom custo vs benefício;
• Os planos Business do Office 365 se mostram sempre com melhor custo que as soluções com Exchange Server.


Flávio Rescia
Gerente de Operações
flavio.rescia@darede.com.br

Sócio Fundador Darede, graduado em Redes de Computador e Sistemas de Informação, ministra aulas de Redes de Computador no SENAI e possuí vasta experiência com provedores de Internet, tecnologia para mercado financeiro e Cloud Computing.

PARTE 2: DNS, dúvidas quando precisa hospedar uma aplicação?

DNS, você sabe o que é, mas sempre tem dúvidas quando precisa hospedar uma aplicação?

Até então falamos apenas de solução de nomes para IP, porém não existe apenas esse tipo de resposta, essa é a principal função do DNS, porém não é a única.
Agora vamos entender as entradas DNS que podem ser utilizadas e quando utilizamos:

Entrada Tipo A

É a que falamos até agora, serve para resolver um nome como www.xpto.com.br para um IP como 200.200.200.1

Entrada do Tipo CNAME

Para facilitar a configuração são usadas entradas CNAME (do inglês Canonical Name, Apelido), que são entradas que apontam nomes DNS como www.xpto.com.br para outro nome como www.darede.com.br.

(Ferrou, agora babei!)

A sacada aqui é evitar a necessidade de mudar o DNS de www.xpto.com.br sempre que o IP mudar.
Imagina que o site www.xpto.com.br esteja no mesmo servidor que o www.darede.com.br que aponta para 200.1.1.1, caso tenhamos que mudar nosso provedor e trocar o IP 200.1.1.1 para outro IP, como 202.1.1.1, precisaremos trocar apenas a entrada www.darede.com.br e não o www.xpto.com.br, uma vez que www.xpto.com.br continuará apontando para www.darede.com.br. Parece bobagem? Imagina que você tenha 1000 sites apontando para www.darede.com.br e mude a operadora 😱!
diagrama

A desvantagem no uso de CNAME é que será necessário o cliente resolver duas vezes:
• www.xpto.com.br > www.darede.com.br
• www.darede.com.br > 200.1.1.1
Entradas CNAME hoje são muito utilizadas por serviços gerenciados (como AWS CloudFront, AWS ELB), uma vez que o serviço lhe oferece um nome e você cria um CNAME de seu domínio (como www.darede.com.br) e aponta para o nome oferecido pelo provedor do serviço. Caso os IPs da AWS mudem, nós não precisamos nos preocupar.
diagrama

DICA:

De acordo com a RFC não é possível criar entradas do tipo CNAME para ‘naked domain’ (exemplo darede.com.br), nesse caso temos que configurar uma entrada ‘A’ direto para o IP. Quando precisamos apontar o ‘naked domain’ para um serviço gerenciado (que não há IP fixo), temos duas opções:

1. Apontar para um servidor (esse sim com um IP fixo), e fazer um redirecionamento HTTP 301 para ele;

2. Para AWS, podemos usar uma entrada A com Alias. Alias é um recurso da AWS para criar entradas ‘A’ para serviços gerenciados AWS (como Elastic LoadBalancer, S3, CloudFront, API Gateway, etc). O AWS Route53 garante que a entrada sempre aponte para os IPs atuais do serviço gerenciado.

Entrada Tipo MX

Um e-mail é enviado para voce@seudominio.com.br certo? Qual o nome DNS do seu servidor de RECEBIMENTO de e-mails?
seudominio.com.br? NÃO. Geralmente seudominio.com.br aponta para seu site e não para seu servidor de recebimento de e-mail.
E agora? Para isso existe a entrada do tipo MX, que vem de Mail eXchange (também acho bizarro devia ser ME, kk!), o MX aponta para nossos servidores de recebimento de e-mails (SMTP/S).
Esse tipo de entrada pode apontar tanto para IP quanto para nomes, e possui uma particularidade, cada entrada possui dois valores:
• Nome ou IP do servidor de recebimento de e-mail;
• Prioridade, que é usada para redundância de servidores;
dos1

Entradas do tipo TXT

Para muitos serviços que surgiram anos após a primeira versão do protocolo HYPERLINK “https://www.ietf.org/rfc/rfc1034.txt”DNSs era preciso validar se um domínio é mesmo de propriedade de determinada pessoa/empresa. Como fazer isso?
Simples, lhe faço um desafio ao mantenedor do domínio. Crio um código de teste (como 123codigo) e peço para o mantenedor configurar uma entrada 123codigo.dominio.com.br, se essa entrada for criada, significa que realmente ele tem acesso ao SOA, logo posso confiar que ele é responsável por esse domínio.
Mas criar uma entrada ‘perdida’ para isso, parece uma gambiarra né? Como tudo em tecnologia que parece gambiara vira padrão. As entradas do tipo TXT surgiram para isso, é possível atribuir um texto qualquer (não apenas um nome ou IP) a essa entrada, que funciona como uma variável para qualquer finalidade.
O SPF que surgiu anos depois, é um exemplo de utilização de entrada TXT. Como o serviço de e-mail, que foi criado HYPERLINK “https://tools.ietf.org/html/rfc821” à HYPERLINK “https://tools.ietf.org/html/rfc821” HYPERLINK “https://tools.ietf.org/html/rfc821″décadas atrás, não possuía uma validação da origem do e-mail, qualquer um podia (e ainda pode) enviar e-mails em nome qualquer domínio. O SPF surgiu como um padrão para garantir o dono do domínio de origem possa informar ao servidor de recebimento (destino) os IPs que podem enviar e-mail em nome de @dominiodeorigem.com.br. Para isso era/é usada uma entrada TXT. Em 2014 foi criado um outro tipo de entrada DNS dedicada a SPF.
Um uso típico de entradas TXT é a validação de serviços cloud, como Google, AWS e Azure se você pode mesmo usar seu domínio.

Entrada Tipo PTR

É o contrário de entradas do Tipo ‘A’, usada para apontar um IP (200.1.1.1) para um nome (www.xpto.com.br).
Essa entrada causa muita confusão, uma vez que ela só pode ser usada pelo mantenedor do IP e não do domínio.
Em geral o mantenedor do IP é o provedor de seu Link de Internet ou serviço na nuvem. Assim somente o provedor poderá configurar o reverso de seu IP, caso precise, a única forma é abrir um chamado com eles.
Os usos práticos desse tipo de entrada são poucos, mas importantes:
• Identificação em caso de testes como traceroute por exemplo:

dos2
Note que alguns saltos não possuem Reverso (PTR) configurado

• Velocidade de algumas aplicações, como SSH e traceroute, uma vez que essas aplicações, de forma nativa, resolve o Reverso do IP, o que causa lentidão quando a entrada não existe por ficar tentando resolver;
• Controle SPAM, novamente o e-mail kkk! Como o SMTP foi inventado antes da invenção do SPAM, ele não previu seu uso, uma das técnicas para evitar SPAM é garantir que haja um vínculo entre o mantenedor do IP e seu utilizador, a técnica é simples. Se você está em uma LAN House, não vai conseguir pedir para configurar o reverso nele, então o servidor SMTP de recebimento espera que o IP aponte para um nome, e que esse nome aponte para o próprio IP. Caso isso não aconteça, o e-mail é considerado SPAM.
diagrama

Trocando SOAs – Futuro
Tempo de replicação – Futuro


Flávio Rescia
Gerente de Operações
flavio.rescia@darede.com.br

Sócio Fundador Darede, graduado em Redes de Computador e Sistemas de Informação, ministra aulas de Redes de Computador no SENAI e possuí vasta experiência com provedores de Internet, tecnologia para mercado financeiro e Cloud Computing.

Modificando Parâmetro “Copy Tags to Snapshot” Aurora Postgres

Poucos sabem, mas todos os recursos da AWS são disponíveis via API, esse é um dos segredos do sucesso da AWS e de outras soluções de Cloud, pois dessa forma você pode automatizar qualquer operação da infraestrutura.

Porém alguns recursos não são disponíveis na Console (interface web), em geral a AWS lança novas funcionalidades primeiro apenas em API e posteriormente disponibiliza esse recurso na Console WEB.

Esse é um exemplo, em bancos de dados RDS Aurora Postgres não conseguimos alterar o valor “Copy tags to snapshots” (que é usado para colocar a mesma TAG que estão no RDS nos snaphots criados à partir dele), via Console WEB. Provavelmente essa funcionalidade deve ser implementada em breve, enquanto isso pode fazer via API, como via aws cli por exemplo:

—————————————————————
Opção desabilitada e pode ser vista em RDS > Instances > rds_name

—————————————————————

Ao tentar modificar essa opção não existe:

—————————————————————
Alteração não disponível em: RDS > Instances > instance_name > Modify

—————————————————————

Primeiro listamos os bancos que não estão com essa opção habilitada:

$ aws rds describe-db-instances --output table --region us-east-1 --query 'DBInstances[*].[DBInstanceIdentifier,CopyTagsToSnapshot]' | grep False
| db1-123445566123123 | False |
| db2-123445566123123 | False |
| db3-123445566123123 | False |
| db5-123445566123123 | False |
| db7-123445566123123 | False |
| db8-123445566123123 | False |
| db0-123445566123123 | False |

Agora podemos habilitar essa opção com o comando abaixo

$ aws rds modify-db-instance --db-instance-identifier db1-123445566123123 --copy-tags-to-snapshot --apply-immediately

O comando deverá retornar um json, com as informações atuais do banco (já com a modificação), que pode ser constatada inclusive via Console WEB:

—————————————————————
Parâmetro alterado pode ser visto pela Console WEB

—————————————————————


Flávio Rescia
Gerente de Operações
flavio.rescia@darede.com.br

Sócio Fundador Darede, graduado em Redes de Computador e Sistemas de Informação, ministra aulas de Redes de Computador no SENAI e possuí vasta experiência com provedores de Internet, tecnologia para mercado financeiro e Cloud Computing.

Office-vs-Exchange

Office 365 ou Exchange Server?

Essa é uma pergunta que temos ouvido muito nos últimos anos. Uma empresa pretende migrar sua solução de e-mail e, frente às inúmeras soluções de e-mail existentes (OnPremises ou SaaS) para nessas duas finalistas: e agora?

Adotar Microsoft Exchange ou Microsoft Office 365?

Se você chegou até aqui, já deve saber bem o que é Microsoft Exchange Server e Microsoft Office 365. Caso tenha dúvidas, veja os links abaixo:

Como quase tudo em infraestrutura de TI, a resposta é: Depende!

Fizemos um estudo onde colocamos todas as VARIÁVEIS possíveis e em nossa análise apresentamos alguns cenários possíveis onde podemos ver que para cada ambiente, há uma melhor solução. Abaixo, descrevemos cada uma dessas VARIÁVEIS, assim você conseguirá elencar as que fazem parte de sua realidade.

1) Quantidade de usuário

Esse fator é muito importante, a primeira conclusão que devemos chegar é que o Custo Inicial de uma solução OnPremises, como é o Microsoft Exchange Server, é maior que o de uma solução SaaS, como o Office 365. Então, até aqui, nos parece que se você tem apenas um usuário, faz mais sentido utilizar o Office 365, as dúvidas agora seriam: a) Qual versão de Office365 usar e, b) A partir de quantos usuários/colaboradores valerá a pena usar o Microsoft Exchange Server (se é que valerá).

2) Investimento inicial

Você possui recurso para um investimento inicial (CAPEX)? Se em seu orçamento tem sobrado recurso para investimento recorrente (OPEX), o uso de soluções SaaS pode lhe cair como uma luva. Já quando o contrário acontece, você tem uma grana sobrando para um projeto pontual, o uso de Exchange passa a ser possível. Mas não se esqueça de colocar em sua conta que sempre haverá um custo inicial, como para fazer a migração para o Office365. E mesmo usando o Exchange, haverá um custo recorrente para manter a solução, seja com profissionais internos ou contratando uma consultoria para administrar seu ambiente, além de energia, depreciação dos equipamentos, renovação de licenças e etc.

3) Uso do pacote Microsoft Office

Essa é uma VARIÁVEL que tem feito a diferença em alguns cenários. O Office365 oferece, em todas suas versões, o direito dos usuários usarem o Pacote Office. Nos pacotes mais simples, apenas o Office Online (que, acreditem, tem atendido muitíssimos casos) e, a partir do pacote Bussiness dá o direito a usar o Pacote Offline, o mesmo já utilizado por nós enquanto tiver que pagar pelo serviço.

4) Estado atual e desejado de seu parque de licença

Uma das sacadas da Microsoft é que com o uso do Office365, além de mudar a solução de e-mail de sua empresa, você pode utilizar o Pacote Office licenciado pagando por seu uso de forma mensal. Muitas empresas têm usado esse produto para substituir sua licença atual em versões antigas ou para regularização de seu parque. O Office365 traz junto a atualização permanente do Office, enquanto você manter o pacote mensal. Em outras palavras, você pode resolver um problema de softwares não regularizados e manter-se sempre na versão mais nova do Office.

5) Perfil de e-mails

É muito importante considerar o perfil de e-mails da empresa. Por exemplo, se sua empresa tem um fluxo de e-mails grande entre os colaboradores, pode ser uma boa ideia usar o Exchange, pois os e-mails trafegariam somente na sua rede interna e não consomem o link de Internet. Elencamos aqui alguns perfis de empresa que podem exigir cenários específicos

  1. Fluxo de e-mails grandes: Se seu(s) link(s) de Internet são pequenos, certamente o uso de serviço externo pode ser um problema. Por exemplo, se você tem um link de 1,5,10Mbps certamente sua rede interna trafega em 100 ou 1000Mbps. Se seu servidor de e-mail estiver instalado dentro de seu escritório a experiência dos usuários com e-mail e com a Internet certamente será melhor.
  2. Legislações e Regras: Em alguns casos, como empresas do mercado financeiro ou instituições públicas, há regras específicas quanto o local e acesso a dados. Já tivemos casos onde não conseguíamos atender regras de retenção, ou o simples fato de a Microsoft ter acesso aos dados (mesmo que a política de uso do Office365 afirme o contrário), pois esses órgãos reguladores ou política de segurança interna não permitem o uso de solução em nuvem.
  3. Muitas Caixas de E-mail: A política de licenciamento do Office 365 é baseada em usuários, dessa forma cada caixa de e-mail requer uma licença. Algumas companhias utilizam diversas caixas de e-mail como: atendimento, compras, vendas (mesmo sabendo que isso poderia ser apenas um grupo ou poderíamos usar diretórios públicos). Nesse caso, o custo com Office 365 fica alto, enquanto no Exchange Server podemos criar quantas caixas de e-mail acharmos necessário sem custo inicial maior.
  4. Caixas de E-mail grandes: Os planos de Office 365, como seus concorrentes (Gmail, AWS WorkMail), possuem caixas de e-mail grande 50/100GB, o que costuma ser muito mais que o necessário e em ambiente OnPremises limitamos mais.

6) Infraestrutura Existente

Caso você possua uma estrutura que atenda outros projetos, como cluster de hypervisor, storage com espaço disponível, co-location/locação de espaço em datacenter, etc., esse custo já existente pode ser utilizado para minimizar o custo inicial, já que, como veremos ao longo desses artigos, o custo com servidor, espaço, links de Internet é muito elevado.

Abaixo, uma tabela comparativa para facilitar o entendimento das principais variáveis a serem pontuadas em sua decisão:

Exchange Server Office 365
Custo por Mailbox Não Há Licença Mensal
Custo por Usuário CAL Adquirida Pagamento Mensal
Uso do Microsoft Office Adquirir Licença Incluso*
Custo Inicial Elevado Baixo**
Multiplataforma (Windows/Android/Iphone) Sim Sim
Webmail Sim Sim
Necessário Certificado SSL Sim Não

*Office Offline apenas nos planos mais caros.
** É necessária equipe técnica para ativar e/ou migrar sua solução atual.

Agora que nós já explicamos as principais diferenças e variáveis, sabemos que ambas as soluções são muito completas, mas com características distintas. No próximo artigo, veremos como fica o custo para cada uma das soluções.


Flávio Rescia
Gerente de Operações
flavio.rescia@darede.com.br

Sócio Fundador Darede, graduado em Redes de Computador e Sistemas de Informação, ministra aulas de Redes de Computador no SENAI e possuí vasta experiência com provedores de Internet, tecnologia para mercado financeiro e Cloud Computing.

DNS e as dúvidas quando precisa hospedar uma aplicação

Se você está lendo esse nosso primeiro artigo, deve estar com aquela pulga atrás da orelha, aquele sentimento de:

“Será que agora vou saber o que estou fazendo quando crio aquela entrada TXT, ou CNAME quando sigo um procedimento?”.

Fique tranquilo, após a leitura, terá todos os conceitos práticos necessários para saber exatamente o que está fazendo quando tiver que realizar qualquer mudança no DNS.

E provavelmente você deve ter tido aula (ou apenas passou na prova) em seu curso técnico ou universitário, mas na hora de pôr a mão na massa no DNS, prefere pedir para alguém ou seguir aquela ‘receitinha’. Vamos acabar com isso hoje!

Todos que estão lendo devem saber para que serve DNS: traduzir nome para IP, para que usemos nomes e não IP em uma aplicação como browser, shell, cliente de e-mail ou qualquer outro software. Você verá que é muito mais que isso.

E muitos devem ter visto (na apresentação do professor) o desenho abaixo:

Esqueça ele, por enquanto. Provavelmente você nunca terá que se preocupar com esse conceito, para 99% dos profissionais de TI são dispensáveis, mesmo sendo o único que todo professor ensina =D!

Primeiro, é importante entender a realidade em que o DNS foi feito e quais problemas ele tenta resolver. Abaixo uma lista de verdades que explicam muita coisa:

  • DNS foi criado na década de 1980, quando os recursos computacionais eram muito mais limitados que hoje;
  • Foi criado para o controle ser centralizado;
  • E a carga maior ser descentralizada.

O segundo conceito, importante, é:

Existem dois tipos de servidores DNS:

  1. O que todos usam sempre, o DNS ‘Resolver’ e
  2. O que temos medo de mexer, o ‘SOA’.

O Servidor Resolver (do inglês “Resolvedor”) é aquele que configuramos em nossa placa de rede (ou recebemos via DHCP). Usamos para resolver/consultar nomes DNS de qualquer domínio, para que possamos navegar na Internet ou fazer uso das nossas aplicações. Subir um servidor DNS é muito simples, o roteador WIFI que temos em casa quase sempre faz essa função de servidor DNS para nós. A nossa operadora sempre nos oferece ao menos 2 servidores DNS de consulta, para nosso uso da Internet contratada.

Quando configuramos um Servidor Resolver?

  • No roteador da nossa casa;
  • Quando vamos compartilhar Internet em nossas impressoras (isso pode inclusive ajudar no desempenho quando fazemos cache, pois evita consulta na Internet de requisições repetidas).

Já os servidores SOA são os servidores responsáveis por responder para Internet (para os servidores de Resolver) cada nome de nosso domínio para IPs. Por exemplo, o domínio darede.com.br que temos registrado para nosso uso, precisa de servidores SOA, também ao menos dois, para que possamos apontar entradas DNS como www, mail, smtp, etc, para os IPs onde essas aplicações rodam.

Mas por que sempre ao menos dois? Nem vou responder

Nosso servidor DNS de consulta pode verificar algum outro DNS de consulta, como os do provedor, ou resolver diretamente usando o protocolo WHOIS.

Esse ai (WHOIS) foi outro que dá aquela dor no estômago quando vê né? Saaaabe o que é…. mas não sabe explicar? 😉

WHOIS é um protocolo utilizado principalmente para: “Informar aos servidores DNS Resolvers quem são os SOA de determinado domínio”. Aqui vem a sacada do DNS. Existem bilhares de entradas nos milhares de SOA, a IANA que controla a internet precisa apenas ter o controle de qual SOA reponde por cada domínio, enquanto nós ficamos responsáveis pelo SOA e suas centenas de entradas.

Muitos devem conhecer, mas usando serviços como os abaixo, conseguimos saber quem (who is) o servidor SOA do domínio xpto.com.br, além de outras informações do mantenedor do domínio:

Uma vez que o Servidor Resolver sabe quem manda no domínio (xpto.com.br), ele faz a consulta diretamente para o SOA. E agora a pergunta é: “Eu sei que você manda no domínio xpto.com.br. Quem é o www?”

Então, o fluxo de uma consulta DNS no dia a dia da Internet fica o seguinte:

  • Cliente pergunta a seu servidor DNS Resolver: “Qual IP de www.darede.com.br?”
  • Servidor DNS Resolver 1, que tem encaminhamento para outro Servidor DNS Resolver (2), pergunta: “Qual IP de www.darede.com.br?”
  • Servidor DNS Resolver 2, que não faz encaminhamento, utiliza o protocolo WHOIS para questionar: “Quem é o SOA de darede.com.br?”
  • Com os IPs do SOA, o Servidor DNS Resolver 2 pergunta à um dos SOAs: Eu sei que você é SOA de darede.com.br, qual o IP de www?”
  • Agora que o Servidor DNS Resolver 2 sabe o IP de www.darede.com.br, ele informa o cliente (ou ao Servidor DNS Resolver 1) qual é o IP e pode ou não configurar para cachear esse nome”

Registrar: O Registrar é o órgão responsável por manter a concessão dos domínios usados na Internet. É ele quem configura o WHOIS Server de modo que os servidores DNS Resolvers possam ‘descobrir’ os SOAs de cada domínio.

No Brasil, possuímos apenas um registrar, o registro.br, é nele que registramos o domínio para podermos usá-lo. Em outros países podem existir diversos Registrars, nos EUA, por exemplo, os provedores de hospedagem de sites são os próprios registrar. Já por aqui, no Brasil, os provedores de hospedagem de site fazem apenas o papel de SOA, servidor de e-mail, servidor de páginas web, etc.

Agora que entendemos o fluxo das consultas DNS na Internet, sabemos que funciona assim, como abaixo:

  • Os clientes consultam seu DNS Resolver procurando pelo IP de www.xpto.com.br;
  • O WHOIS mantém os SOAs que respondem para cada domínio;
  • O SOA mantém a tabela de nomes e IPs do domínio xpto.com.br;
  • Os Servidores DNS Resolvers consultam WHOIS (Quem é) SOA de xpto.com.br;
  • Os Servidores DNS Resolvers consultam ao SOA qual o IP de www.xpto.com.br;
  • Cliente faz a requisição (HTTP, POP, SMTP, etc) ao IP de www.xpto.com.br

Até então, falamos apenas de solução de nomes para IP, mas não existe apenas esse tipo de resposta. Essa é a principal função do DNS, porém, não é a única.

Fique ligado porque no próximo artigo vamos entender as entradas DNS que podem ser utilizadas e quando utilizamos 😉


Flávio Rescia
Gerente de Operações
flavio.rescia@darede.com.br

Sócio Fundador Darede, graduado em Redes de Computador e Sistemas de Informação, ministra aulas de Redes de Computador no SENAI e possuí vasta experiência com provedores de Internet, tecnologia para mercado financeiro e Cloud Computing.