Falhas comuns de aplicações
web e métodos de ataques
Vejamos alguns métodos comuns de explorar as vulnerabilidades de uma aplicação ou site hospedado em um servidor web.
Misconfiguration
É muito fácil para o administrador inexperiente, mas bem-intencionado, configurar mal ou simplesmente se perder em uma configuração, que pode ser a opção que permite um ataque.
Para evitar que a configuração incorreta se torne um problema, certifique-se de que a função do servidor está corretamente definida. Planeje e avalie a configuração para garantir que ela irá fornecer a proteção necessária. Certifique-se também de rever as melhores práticas que fornecedores como a
Microsoft oferecem sobre as etapas a serem tomadas para proteger um sistema.
Outra opção é usar scanners de vulnerabilidade para verificar possíveis problemas em um site ou aplicação da Web. Os
scanners de vulnerabilidade podem fornecer orientação valiosa sobre onde os esforços devem ser concentrados.
Validação de Entrada
Validação de entrada é um mecanismo usado para verificar as informações de como elas são inseridas em uma aplicação. Normalmente, um usuário inserindo dados em um formulário ou site terá poucas ou nenhuma restrição colocadas sobre eles. Quando os dados são aceitos sem restrições, erros tanto intencionais como não intencionais podem ser inseridos no sistema e podem levar a problemas mais tarde. No entanto, com um mecanismo para validar entrada, é possível frustrar esses problemas, que incluem:
Manipulação de banco de dados Corrupção de banco de dados Buffer overflows
Dados inconsistentes
A falta de validação de entrada pode permitir ataques avançados como SQL Injection. Também é possível que outros ataques, como o XSS armazenado, possam ser possíveis pela falta de validação de entrada.
Um bom exemplo da falta de validação de entrada é uma caixa em um formulário onde um código postal deve ser inserido, mas na realidade ele aceitará qualquer dado. Em outros casos, aceitar os dados errados significará simplesmente que a informação pode ser inutilizável para o proprietário do site, mas pode causar falha no site ou manipular de forma errada a informação para revelar outras informações na tela.
Felizmente, este problema é relativamente fácil de corrigir uma vez que o desenvolvedor só precisa colocar restrições sobre os tipos de entrada que podem ser aceitos pela aplicação. Por exemplo, o desenvolvedor pode ter certeza de que apenas dados numéricos e certas frases são permitidas.
Cross-Site Scripting
Outro tipo de ataque contra um servidor web é o ataque cross-site scripting (XSS). Ele depende de uma variação do ataque de validação de entrada, mas o alvo é diferente porque o objetivo é ir atrás de um usuário em vez do aplicativo ou dados. Um exemplo de XSS usa métodos de script para executar um cavalo de Tróia com o navegador de um alvo. Isso seria feito possível através do uso de linguagens de script como JavaScript ou VBScript. Através de uma análise cuidadosa, um invasor pode procurar maneiras de injetar código malicioso em páginas da web, a fim de obter informações que vão desde informações de sessão no navegador, acesso privilegiado ao conteúdo no navegador.
Vejamos etapas do XSS em ação:
O atacante descobre que um site sofre de um defeito de script XSS.
Um atacante envia um e-mail informando que a vítima acaba de receber um prêmio e deve coletá-lo clicando em u m l i n k n o e - m a i l . O l i n k n o e - m a i l v a i p a r a : http://www.badsite.com/default.asp?name=<script>badgoal( )</ script>
Quando o link é clicado, o site exibe a mensagem “Bem-vindo de volta!” Com um prompt para o usuário digitar seu nome.
O site lê o nome de seu navegador através do link no e-mail. Quando o usuário clica no link no e-mail, o site é informado que seu nome é <script>evilScript</script>
O servidor web relata o nome e o retorna ao navegador da vítima.
O navegador interpreta corretamente isso como um script e executa o script.
Este script instrui o navegador a enviar um cookie contendo algumas informações para o sistema do invasor, o que ele faz.
XSS é um ataque antigo e vários navegadores modernos incluem proteção contra isso. No entanto, a proteção não é infalível, e os ataques podem ser induzidos por má configuração, gambiarras ou mesmo add-ons de terceiros. Isso nem mesmo inclui ataques de script XSS que se originam do próprio servidor.
Redirecionamentos e encaminhamentos
não validados
Para que esse tipo de ataque ocorra, a aplicação ou página da Web deve ter validação de entrada fraca ou inexistente.
um módulo redirect.php que leva uma URL através de um parâmetro GET. A manipulação deste parâmetro pode criar uma URL no sitealvo.com que redireciona o navegador para sitedohackermaldoso.com. Quando o usuário vê o link, eles vão ver favorito.com/blahblahblah , que o usuário acha que é confiável e seguro clicar. Na realidade, o link irá enviá-los para uma página diferente, que neste caso pode fazer o download de software ou algum outro material malicioso no sistema de uma vítima.
Sistemas de logon inseguros
Muitos aplicativos da Web exigem algum tipo de autenticação ou processo de login antes usar. Devido à importância do processo de logon, é essencial que ele seja manuseado com segurança. Você deve tomar cuidado para que a entrada incorreta ou imprópria de informações não revele dados que um invasor pode usar para obter informações adicionais sobre um sistema.
Os aplicativos podem rastrear informações relacionadas a logons incorretos ou logins de usuários, se assim estiverem ativados. Normalmente, esta informação vem em forma de log, com lista de itens como estes:
Entrada de um ID de usuário inválido com uma senha válida;
Entrada de um ID de usuário válido com uma senha inválida;
Entrada de um ID de usuário e senha inválidos;
Os aplicativos devem ser projetados para retornar informações genéricas que não revelem informações como nomes de usuários corretos. Os aplicativos da Web que retornam uma mensagem como “nome de usuário inválido” ou “senha inválida” podem dar a um invasor um alvo para se concentrar – como uma senha correta.
Erros de script
Aplicativos da Web, programas e código, como Common Gateway Interface (CGI), ASP.NET e JavaServer Pages (JSP) são comumente usados ??em aplicativos da Web e apresentam seus próprios problemas. Vulnerabilidades como a falta de scripts de validação de entrada podem ser um problema. Um atacante experiente pode usar uma série de métodos para causar tristeza ao administrador de um aplicativo da Web, incluindo o seguinte:
Upload Bombing – Carrega massas de arquivos para um servidor com o objetivo de encher o disco rígido no servidor. Uma vez preenchido o disco rígido do servidor, a aplicação deixará de funcionar e vai falhar.
Ataque Poison Null Byte – Este ataque passa caracteres especiais que o scripts não foram projetados para manipular corretamente. Quando isso é feito, o script pode conceder acesso onde não deveria ser dado.
Scripts padrão – Os scripts padrão são frequentemente carregados em servidores por web designers que não sabem o que eles fazem em detalhes. Nesses casos, um intruso pode analisar ou explorar problemas de configuração com os scripts e obter acesso não autorizado a um sistema. Scripts de exemplo – Os aplicativos da Web podem incluir conteúdo de exemplo e scripts que estão regularmente em servidores. Em tais situações, esses scripts podem ser usados ??por um atacante.
Scripts mal escritos ou questionáveis – Alguns scripts apareceram que incluem Informações como nomes de usuários e senhas, permitindo que um invasor visualize o conteúdo do script e leia essas credenciais.
sessão
Uma sessão representa a conexão que um cliente tem com o aplicativo do servidor. A informação da sessão que é mantida entre o cliente e o servidor é importante e pode dar a um invasor acesso a informações confidenciais, caso seja comprometida.
De forma ideal, uma sessão terá um identificador exclusivo, criptografia e outros parâmetros atribuídos sempre que uma nova conexão entre um cliente e um servidor for criada. Depois que a sessão for encerrada, fechada ou não for necessária, a informação será descartada e não será usada novamente (ou pelo menos não será usada por um período prolongado), mas isso nem sempre é o caso. Algumas vulnerabilidades desse tipo incluem o seguinte:
Sessões de longa duração – As sessões entre um cliente e um servidor devem permanecer válidas apenas pelo tempo que eles são necessários e depois descartados. Sessões que permanecem válidas por períodos mais longos do que são necessárias permitem que intrusos usem ataques como XSS recuperem identificadores de sessão e reutilizem uma sessão.
Recursos de Logout – Os aplicativos devem fornecer um recurso de logout que permite que um visitante faça logout e feche uma sessão sem fechar o navegador.
Identificadores de sessão inseguros ou IDs de sessão facilmente previsíveis ou previsíveis – Algumas falhas em aplicativos da Web podem levar à reutilização de IDs de sessão. A exploração de IDs de sessão também pode cair na categoria de sequestro de sessão (session hijacking).
Concedendo IDs de Sessão a Usuários Não Autorizados – Às vezes, os aplicativos concedem IDs de sessão para usuários não autenticados e redirecionam para uma página de logout. Isso pode dar ao invasor a capacidade de
solicitar URLs válidos.
Pobre ou Nenhum Controle de Mudança de Senha – Uma implementação inadequada ou insegura no sistema de alteração de senha, em que a senha antiga não é necessária, permite que um hacker altere senhas de outros usuários.
Inclusão de informações desprotegidas nos cookies – Os cookies podem conter informações desprotegidas como o endereço IP interno de um servidor que pode ser usado por um hacker para saber mais sobre a natureza da aplicação web.
Protegendo Cookies
Como os cookies são parte integrante de aplicativos da Web, é importante compreender os métodos que podem ser usados ??para protegê-los adequadamente. Enquanto o desenvolvedor de um aplicativo é, em última instância, a única pessoa que pode fazer alterações para proteger os cookies na maioria dos casos, é importante entender o que eles podem fazer.
Já discutimos o que são os cookies e falamos um pouco sobre o que eles são usados ??e como eles podem ser comprometidos. Agora vamos falar sobre a definição de atributos que podem proteger os cookies e torná-los mais seguros.
A seguir está uma lista dos atributos que podem ser definidos em uma base por cookie, o que os torna mais seguros para usar:
Secure – Quando esse atributo é definido em um cookie, informa ao navegador que os cookies só poderão ser enviados através de métodos seguros, como HTTPS. No entanto, no caso de uma aplicação web que utiliza HTTP e HTTPS, o cookie pode inadvertidamente ser passado em texto claro.
XSS porque o cookie só pode ser acessado via HTTP e não via scripts, como o JavaScript do lado do cliente. Pode não ser suportado em todos os navegadores.
Domain – Quando esse atributo é usado, ele verifica se o domínio que o cookie está sendo usado é dele mesmo. Então um segundo atributo conhecido como o atributo path será verificado.
Path – Quando o atributo de domínio é definido, o caminho pode então especificar se o local ou cookie é realmente válido. É importante ao usar esse atributo que você use o caminho mais restritivo possível para evitar ataques lançados de aplicativos co-localizados.
Expires – Este atributo oferece uma forte proteção contra o mau uso de cookies porque ele realmente exclui o cookie quando a data de validade é excedida. No entanto, até que a data seja excedida, o cookie continuará a ser acessível e utilizado pela sessão do browser atual e todas as sessões seguintes. Se o atributo não estiver definido especificamente, o cookie será excluído assim que a sessão atual do navegador seja fechada.
Fraquezas na criptografia
Em aplicações web, criptografia desempenha um papel vital porque informações confidenciais são frequentemente trocadas entre o cliente e servidor na forma de logons ou outros tipos de informações.
Ao proteger aplicativos da Web, você deve considerar a segurança da informação em duas etapas: quando ela é armazenada e quando é transmitida. Ambas as etapas são áreas potenciais para o ataque. Ao considerar a criptografia e seu impacto na aplicação, concentre-se nesses áreas:
Cifras fracas – Cifras fracas ou algoritmos de codificação são aqueles que usam chaves curtas ou são
mal concebidas e implementadas. O uso de cifras fracas pode permitir que um invasor descriptografe dados facilmente e obtenha acesso não autorizado às informações. É importante que você nunca subestime o valor dos dados sendo armazenados, processados ??ou transmitidos pela sua aplicação web. Considere os dados que você armazena para seus clientes e como protegê-los. Informações confidenciais, como dados de cartão de crédito, nunca devem ser transmitidas. Se este tipo de informação precisa ser armazenado, use sempre a criptografia mais forte possível ou exigida, como AES 256 ou RSA 2048. Se ele não precisa ser armazenado, não armazene. Se você precisar processar pagamentos que envolverão esses dados, use um processador de pagamento que seja compatível com PCI para que você não precise assumir essa tarefa.
Software Vulnerável – Algumas implementações de software que criptografam a transmissão dos dados, como Secure Sockets Layer (SSL), podem sofrer de programação deficiente e, portanto, tornar-se vulnerável a ataques como buffer overflow.
Algumas ferramentas e recursos estão disponíveis para ajudar na avaliação da segurança de aplicativos da Web e suas estratégias de criptografia associadas:
OpenSSL, um toolkit de código aberto usado para i m p l e m e n t a r o s p r o t o c o l o s S S L v 3 e T L S v 1 : www.openssl.org
O guia OWASP para falhas criptográficas comuns: www.owasp.org
Nessus Vulnerability Scanner, que pode listar as cifras em uso por um servidor web: www.nessus.org
WinSSLMiM, que pode ser usado para executar um ataque m a n - i n - t h e - m i d d l e H T T P S : www.securiteinfo.com/outils/WinSSLMiM.shtml
protocolos não-SSL-aware: www.stunnel.org
Ataque Directory Traversal
Este ataque também é conhecido como Path Traversal, ou traduzido ao pé da letra como ataque de passagem de diretório. Ele permite que um invasor se mova para fora do diretório do servidor web e para outras partes do host. Uma vez fora deste diretório, o invasor pode então ser capaz de ignorar permissões e outros controles de segurança e executar comandos no sistema.
Para executar este ataque, um intruso tira proveito de erros ou fraquezas em uma das duas áreas:
As listas de controle de acesso (ACLs), que são usadas para indicar quais usuários e grupos têm permissão para acessar arquivos e diretórios em um servidor, bem como o nível de interação permitido;
Diretório raiz, que é o diretório no servidor para o qual os usuários são especificamente restritos. Normalmente, esta é a pasta de nível mais alto que se pode chegar. O diretório raiz atua como o diretório superior do site e impede que os usuários obtenham acesso a arquivos confidenciais no servidor.
Para realizar um ataque de passagem de diretório, é surpreendentemente necessário pouco conhecimento e um navegador da Web. Com essas ferramentas e paciência, é possível encontrar cegamente arquivos e diretórios padrões em um sistema.
O sucesso do ataque depende em grande parte da configuração do site e do servidor, mas existem alguns tópicos comuns. Normalmente, os atacantes dependem de assumir ou falsificar-se como usuários e obter acesso a tudo o que os usuários têm acesso.
Nos aplicativos da Web com páginas dinâmicas (como PHP, ASP ou ASP.NET), a entrada é normalmente recebida dos navegadores por meio dos métodos de solicitação GET ou POST. Aqui está um exemplo de um URL de solicitação GET HTTP:
http://subdominio.nomedositealvo.com/pagina.asp?ver=conteudo.h tml
Com essa URL, o navegador solicita a página dinâmica pagina.asp do servidor e com ela também envia a exibição de parâmetros com o valor conteudo.html. Quando esta solicitação é executada no servidor web, pagina.asp recupera o arquivo conteudo.html do sistema de arquivos do servidor e o devolve ao solicitante. Através de algumas análises, um invasor pode assumir que a página pagina.asp pode recuperar arquivos do sistema de arquivos e criar um URL personalizada:
http://subdominio.nomedositealvo.com/pagina.asp?ver=../../../. ./../Windows/system.ini
Isso fará com que a página dinâmica recupere o arquivo system.ini do sistema de arquivos e exibe-o para o usuário. A expressão ../ instrui o sistema a ir um diretório para cima, que é comumente usado como uma diretiva de sistema operacional. O atacante tem que adivinhar quantos diretórios tem que ir até encontrar a pasta do Windows no sistema, mas isso é feito facilmente por tentativa e erro.
A estrutura do diretório real variará dependendo do próprio servidor, portanto este processo pode exigir uma quantidade considerável de tentativa e erro. Entretanto, considere o fato de que não é incomum que o software seja instalado em pastas e estruturas padrões.
Você não precisa usar o código para atacar o servidor. Você pode usar apenas o navegador sozinho. Um servidor web pode estar completamente aberto a um ataque de diretório de passagem e apenas à espera de um invasor ambicioso para rastrear e usar arquivos de exemplo e scripts contra ele.
Por exemplo, uma solicitação de URL que faz uso do diretório de scripts do IIS para percorrer diretórios e executar um comando pode ter esta aparência:
http://servidoralvoparaserinvadido.com/scripts/..%5c../Windows /System32/cmd.exe?/C+dir+c:\
A solicitação retorna uma lista de todos os arquivos no diretório C:\, executando o arquivo de shell do comando cmd.exe e executando o comando dir c:\ no shell. A expressão %5c que está na solicitação de URL é um código de escape do servidor web usado para representar caractere normal. Nesse caso, %5c representa o caractere \. Em alguns textos e whitepapers, o uso de um sinal % em um URL é conhecido como codificação percentual.
A maioria dos servidores web modernos verifica a presença de códigos e bloqueiam de serem usados. No entanto, com um número tão grande de servidores web de todos os tipos, é mais do que possível que o servidor que você escolher para atacar não irá filtrar esses códigos.
Protegendo-se de ataques Directory
Traversal
Alguns métodos pode ser usado para impedir ataques deste tipo, como:
Excutar software de servidor web modernos ou garantindo que patches atualizados estejam instalados;
Ativando filtragem de entrada do usuário para o servidor web. É comum que servidores web modernos incluam a capacidade de filtrar solicitações ou códigos não padronizados.
Testando Aplicações Web
Como as aplicações web são complexas, pode ser necessário o uso de software especializado para analisar ou testar um aplicativo. Alguns destes pacotes de software estão aqui.
Burp Suite
O Burp Suite é um aplicativo baseado em Java usado para testar e atacar aplicativos da web. Em uma inspeção mais próxima o software é realmente uma coleção das ferramentas usadas para verificar diversas peças e características de uma aplicação. O Burp Suite oferece uma combinação robusta de ferramentas que podem ser usadas tanto manual quanto automaticamente para verificar a aplicação. As ferramentas podem enumerar, analisar, verificar, atacar e explorar furos na aplicação web. O Burp Suite inclui ferramentas que podem executar o seguinte: Proxy – A função proxy permite ao usuário encaminhar o tráfego entre o navegador e configurando o navegador da Web para usar o Burp Suite como um proxy. Quando em uso, o software permite a interceptação, visualização e alteração do tráfego entre o navegador e o servidor. Spider – Esta ferramenta pode mapear uma aplicação web, gerando um inventário da estrutura da aplicação.
Scanner – Quando colocado em uso, o scanner pode descobrir vulnerabilidades em um aplicativo da Web. Em muitos casos, não é tão robusto como um scanner de vulnerabilidades dedicado, mas ainda é eficaz.
Intruder – Esta é uma ferramenta de ataque automatizada e totalmente personalizável para aplicações web.
Repeater – Esta é uma ferramenta para modificar e reeditar manualmente solicitações HTTP individuais e analisar a resposta de cada um.
Sequencer – Este recurso específico é muito útil para testar aplicações web para susceptibilidade ao sequestro
de sessão, inspecionando tokens para aleatoriedade.
Vega Web Application Scanner
Incluído com o Kali Linux 2.0 é um scanner projetado para avaliar uma aplicação web. O Vega é capaz de detectar problemas de injeção de SQL, XSS, divulgação de informações confidenciais e muito mais. Enquanto ele está presente e instalado no Kali Linux, ele está disponível no Windows e OS X também porque é baseado em Java.
Sugestões de livros:
RADIUS
O RADIUS, Remote Authentication Dial In User Service, é um protocolo amplamente utilizado para gerenciar o acesso dos mais diversos serviços de rede. Este protocolo define um padrão para troca de informações entre um Servidor de acesso à rede (NAS, Network Access Server) e um servidor AAA para realizar a autenticação, a autorização e as operações de gerenciamento de contas. Um servidor RADIUS AAA pode gerenciar de forma eficiente diferentes perfis de usuários para a autenticação dos mesmos, além de fornecer informações de configurações que especificam o tipo de serviço a ser entregue e as políticas de cada tipo de serviço, para garantir o uso apropriado de cada recurso disponível. Dentre os serviços que utilizam o RADIUS, podemos citar as autenticações em redes sem-fio, conexões DSL e VPNs. Existem soluções pagas que implementam o RADIUS, mas também existem soluções de código aberto de qualidade como o Free Radius, que conta com uma crescente base de usuários.
Porque utilizar o RADIUS
O RADIUS apresenta uma série de funcionalidades que o qualifica como um eficiente sistema de autenticação adaptável as mais diversas condições de rede. Serão descritas a seguir as principais vantagens:
Modelo Cliente/Servidor: O RADIUS utiliza o modelo cliente/servidor. O NAS funciona como um cliente para o servidor RADIUS. O cliente é responsável por enviar as informações dos usuários que desejam acessar o serviço do NAS para o servidor RADIUS, que se encarregará de verificar a autenticidade do usuário e informar a sua validade para o NAS, que poderá retornar então a resposta adequada para o usuário. Desta forma, o NAS repassa a tarefa de autenticação para o servidor RADIUS, que retorna para o NAS informações fundamentais para controlar o uso de um determinado recurso por parte do usuário, como por exemplo, quais são os limites de acesso do usuário e qual é o tempo máximo de conexão antes de a mesma expirar.
Segurança: As transferências de dados realizadas entre o cliente e o servidor RADIUS são autenticadas através do uso de um segredo compartilhado (shared secret), que nunca é enviado pela rede. Este segredo é de prévio conhecimento tanto do cliente quanto do servidor e é utilizado para garantir a autenticidade do usuário de um determinado serviço requisitado. As senhas de usuário são criptografadas para tentar garantir que nenhum usuário malicioso que esteja ouvindo a rede possa descobrir a senha do usuário. Além disso, outros métodos de autenticação podem ser implementados, dependendo do grau de segurança requisitado pelo sistema. Flexibilidade e Adaptabilidade: Os dispositivos de rede como roteadores, servidores, e switches, muitas vezes não conseguem arcar com um grande número de usuários com informações de autenticação distintas. Através do RADIUS, estes dispositivos
podem romper esta barreira e permitir a autenticação destes usuários através do uso de servidores RADIUS embarcados atuando como proxys para servidores RADIUS de maior capacidade de processamento.
Protocolo extensível: Ao utilizar um campo de atributos de tamanho variável em seus pacotes, o protocolo RADIUS permite que novos atributos sejam adicionados sem atrapalhar implementações prévias do protocolo. Através do campo atributos, também é possível estabelecer novos parâmetros e novos mecanismos de autenticação, sem necessariamente ter que alterar o formato do pacote.
Compatibilidade: Os servidores RADIUS podem verificar as credenciais de seus usuários em bancos de dados de fontes externas, como bancos de dados SQL, Kerberos e LDAP. Desta forma, a implementação de um servidor RADIUS pode ser realizada de forma a reaproveitar um banco de usuários já existente. Outro ponto interessante é que o RADIUS é amplamente utilizado, e praticamente todos os fabricantes de hardware produzem produtos compatíveis com o serviço.
Aplicações
O RADIUS é utilizado atualmente em uma ampla gama de serviços. Ele é adotado como um protocolo de autenticação utilizado pelo IEEE 802.1X, (freqüentemente usado em redes sem-fio), melhorando a criptografia padrão do Wired Equivalency
Privacy (WEP) e utilizando outros métodos de autenticação como
o EAP e algumas de suas variantes. Devido a sua grande f l e x i b i l i d a d e , o u s o d e s e r v i d o r e s R A D I U S a t u a n d o como proxys em dispositivos de rede como roteadores sem-fio permite que estes autentiquem e gerenciem o acesso de um grande número de usuários destes serviços, tarefa quase impossível se levarmos em conta que a quantidade de memória destes sistemas embarcados não permitiria a autenticação de um grande número de usuários com diferentes métodos de
autenticação e diferentes atributos. Além disso, o RADIUS é utilizado amplamente em Provedores de Serviço VoIP, que o empregam para transmitir as credenciais dos usuários e também para realizar o monitoramento das chamadas efetuadas, para a posterior cobrança pelos serviços.
AAA
–
Authentication,
Authorization, Accounting
O servidor RADIUS é um servidor AAA. Para poder ser considerado como tal, ele precisa ser capaz de autenticar usuários, lidar efetivamente com as requisições de autorização e prover a coleta de informações dos usuários (auditoria).
A autenticação se refere ao processo de se apresentar uma identidade digital de uma entidade para outra. Normalmente, esta autenticação ocorre entre um cliente e um servidor. De uma forma mais geral, a autenticação é efetuada através da a p r e s e n t a ç ã o d e u m a i d e n t i d a d e e s u a s c r e d e n c i a i s correspondentes, como a senha associada, tickets, tokens e certificados digitais.
A autorização se refere à associação de certos tipos de privilégios para uma entidade, baseados na própria autenticação da entidade e de quais serviços estão sendo requisitados. Dentre as políticas de autorização, podemos utilizar restrições em determinados horários, restrições de acordo com o grupo ao qual pertence o usuário e proteção contra múltiplas conexões simultâneas efetuadas pelo mesmo usuário. Como exemplo de aplicações que utilizam estas políticas de autorização, podemos citar as políticas de Qualidade de Serviço, que podem fornecer mais banda de acordo com o serviço requisitado, o controle de certos tipos de pacotes, como ocorre no traffic shapping, dentre outros.
Accounting (auditoria) se refere ao monitoramento do comportamento dos usuários e de que forma estes consomem os
recursos da rede. Estas informações podem ser muito úteis para melhor gerenciar os recursos de rede, para a cobrança de serviços e para o planejamento de quais setores da rede precisam ser melhorados.
Topologia e Funcionamento
O protocolo RADIUS segue a arquitetura servidor/cliente. O usuário que deseja utilizar um determinado serviço de rede envia as suas informações para o NAS solicitado (o NAS atua como um cliente para o servidor RADIUS), que pode solicitar a autenticação deste usuário a um servidor RADIUS AAA, na forma de uma mensagem de requisição de acesso (Access- Request
message). De acordo com a resposta fornecida pelo servidor
AAA, o cliente (NAS) pode então fornecer os serviços requisitados pelo usuário de acordo com as políticas e informações estabelecidas pelo servidor RADIUS AAA. Após receber uma requisição do cliente, o servidor RADIUS tenta promover a autenticação do usuário, e retorna as informações de configuração e as políticas a serem aplicadas para o mesmo. Devido a grande flexibilidade do protocolo e devido as diferentes tecnologias agregadas ao RADIUS, o servidor pode ser configurado para autenticar os usuários localmente ou como um cliente proxy que redireciona os pedidos de acesso para outro servidor AAA remoto. Quando utilizamos o servidor RADIUS desta forma, o servidor AAA que atua como proxy passa a ser o responsável pela intermediação das mensagens trocadas entre o cliente e o servidor remoto. Um servidor RADIUS pode ser configurado para efetuar determinadas requisições localmente e atuar comoproxy para outros servidores remotos. Um exemplo muito prático e útil desta flexibilidade do RADIUS é a utilização do mesmo para a autenticação em serviços que executam em sistemas embarcados. Como os sistemas embarcados geralmente possuem limitações de gasto de energia e de espaço de armazenamento e memória, a utilização de um servidor AAA embarcado atuando somente como proxy pode garantir a
autenticação segura de usuários de um serviço, como o acesso de uma rede sem-fio em um ponto de acesso.
Exemplo de uma configuração que utiliza o RADIUS. Nesta figura, suponha que os serviços do NAS1 são autenticados pelo servidor RADIUS 1, enquanto os serviços do NAS 2 são autenticados pelo servidor RADIUS 2.
Podemos observar um exemplo típico de um sistema utilizando RADIUS. O Usuário A, por exemplo, deseja utilizar um serviço fornecido pelo NAS1. Após o usuário A enviar um pedido para o NAS1, o NAS1 que atua como um cliente RADIUS, envia para o Servidor RADIUS 1 a requisição de acesso, indicando que o usuário A deseja utilizar o serviço fornecido pelo NAS 1. Neste exemplo, o servidor RADIUS 1 conseguiu autenticar o Usuário A com sucesso. O servidor RADIUS então informa ao NAS1 da autenticidade do usuário A, que pode agora utilizar o serviço por ele requisitado. Ainda na figura 3.1A, o usuário C deseja utilizar um serviço fornecido pelo NAS 2. Para este caso, o servidor RADIUS 1 funciona apenas como um proxy para o servidor RADIUS 2, de forma que a intermediação do processo de autenticação entre o servidor RADIUS 2 e o NAS 2 será feita pelo servidor RADIUS 1. Neste exemplo, podemos verificar o
grande grau de flexibilidade do Servidor RADIUS, que pode autenticar determinados serviços localmente e ao mesmo tempo intermediar a autenticação de outros serviços de autenticação remotos.
Pacotes de dados RADIUS
O Pacote de dados RADIUS segue o seguinte formato: Código:
O campo código tem o tamanho fixo de um octeto e serve para identificar qual tipo de pacote RADIUS está sendo enviado. Caso o campo código esteja preenchido de forma incorreta, ele é descartado silenciosamente, sem que ocorra um processamento posterior deste pacote. Dentre os possíveis tipos de pacote podemos citar:
Requisição de acesso (Access-Request) Acesso aceito (Access-Accept)
Acesso negado (Access-Reject)
Desafio de acesso (Access-Challenge) Identificador:
O campo de identificação possui o tamanho fixo de um octeto, e o seu principal objetivo é identificar as requisições e as respostas trocadas. O servidor RADIUS AAA pode detectar uma requisição duplicada através da análise do IP de origem e da porta UDP de origem. Nestes casos, o pacote é descartado silenciosamente.
Comprimento:
O campo Comprimento possui o tamanho fixo de 2 octetos e serve para informar o tamanho do pacote. Também estão inclusos no cálculo do tamanho do pacote os campos Código, Identificador, Comprimento, Autenticador e Atributos. Se o tamanho especificado no campo Comprimento for menor que o tamanho do pacote, os octetos fora do alcance especificado são ignorados. Caso o tamanho do pacote seja menor do que o tamanho e s p e c i f i c a d o n o c a m p o C o m p r i m e n t o , e s t e p a c o t e é
silenciosamente descartado. Os pacotes RADIUS devem possuir um tamanho mínimo de 20 octetos e um tamanho máximo de 4096 octetos.
Autenticador:
O campo de Autenticação possui o tamanho de dezesseis octetos. Os valores incluídos neste campo do pacote são utilizados para autenticar as respostas do servidor RADIUS e também são utilizados no algoritmo de ocultação de senhas.
Requisição de Autenticação: Nos pacotes de requisição de acesso, o valor do campo de Autenticação é um número aleatório chamado de Autenticador de Requisições. É fundamental que este valor numérico não seja previsível, e que seja único durante o período em que está sendo utilizado. Se estas condições não forem atendidas, a repetição de um mesmo valor numérico de autenticação poderia permitir que um atacante respondesse no lugar do usuário legitimo, utilizando uma resposta anteriormente interceptada. Em outro caso, um atacante poderia responder uma predição de uma requisição futura, e usar esta previsibilidade para enganar os usuários e atuar como um servidor falso. Dentro do pacote de Requisição de acesso, é utilizado o algoritmo de ocultação de senhas. Este algoritmo gera um hash do segredo compartilhado concatenado com o Autenticador de requisições. Em seguida, é feito um XOR com a senha do usuário, e este valor é colocado no campo de senha do usuário do pacote. Desta forma, o segredo compartilhado e a senha do usuário não são enviados diretamente pela rede. Assim, somente quem possuir o segredo compartilhado e a senha do usuário poderá realizar a mesma operação e verificar se o resultado é compatível. Neste caso, somente o servidor RADIUS possui estas informações. Resposta de Autenticação: O valor inserido no campo de Autenticação nos pacotes do tipo Acesso Aceito, Acesso Negado, e Desafio de acesso são chamados de Resposta de Autenticação. Eles contêm um hash MD5 que é calculado
a t r a v é s d o p a c o t e R A D I U S , o c a m p o d e c ó d i g o , o identificador, o comprimento, o campo de Autenticação do pacote de requisição de acesso, e os atributos de resposta, seguidos do segredo compartilhado entre o Servidor RADIUS e o NAS. Desta forma, o campo com a Resposta de Autenticação é formado por: MD5(Código+Identificador+Comprimento+Campo de Autenticação do pacote de requisição de acesso+Atributos de Resposta + Segredo Compartilhado), onde o sinal “+” representa a concatenação.
Atributos:
O campo de Atributos é responsável por carregar informações específicas de autenticação e de autorização, como os detalhes específicos de uma dada requisição ou de uma dada resposta. Dentre os tipos de informações contidas, podemos citar o nome do usuário a ser autenticado, o endereço IP do NAS, a porta que será utilizada na conexão, dentre outras.
Estabelecimento de uma sessão
RADIUS
O estabelecimento de uma sessão RADIUS ocorre com uma série de trocas de mensagens que objetivam fornecer um determinado serviço de rede para um usuário. Quando um NAS (cliente) é configurado para utilizar o RADIUS, quaisquer usuários que desejem acessar um serviço deste NAS precisam apresentar suas credenciais de autenticação para o NAS, por exemplo, através de uma tela de inicio de sessão, onde o usuário pode inserir o seu nome e a sua senha. Após receber estas informações do usuário, o NAS pode autenticá-lo usando o RADIUS. Para realizar esta autenticação, o NAS, que atua como cliente do servidor RADIUS, envia um pacote do tipo Requisição de Acesso, que contém atributos como o nome do usuário, a sua senha, o seu numero de identificação, dentre outros. As senhas de usuários são ocultadas através da utilização de um método baseado no algoritmo “RSAMessage Digest 5” (MD5).
Possibilidades da requisição de acesso a um serviço
A mensagem de Requisição de acesso é enviada pela rede. Se não houver resposta em um limite de tempo pré- estabelecido, a Requisição de acesso é re- enviada. O cliente ainda pode enviar a Requisição para outros servidores alternativos, no caso de falha na conexão com o servidor primário. Os algoritmos que permitem a troca de servidores são baseados no numero de tentativas de acesso ou em um esquema baseado em round-robin.
Após o recebimento da mensagem de Requisição, o servidor RADIUS tenta validar o cliente. O servidor RADIUS descarta silenciosamente os clientes para os quais ele não possui um segredo compartilhado. Após a autenticação do cliente, o RADIUS consulta um banco de dados de usuários para verificar se o usuário que esta solicitando acesso ao NAS possui as permissões necessárias para ter o acesso garantido.
No caso onde o servidor RADIUS está atuando como um Proxy, ele repassa a Requisição de acesso para o outro servidor RADIUS. Se alguma das condições não for satisfeita pelo usuário, o RADIUS emite um pacote de Acesso negado, que indica que a requisição feita pelo usuário é invalida. O NAS recebe esta mensagem, e desconecta o usuário, podendo ou não enviar alguma mensagem de aviso. Se o usuário satisfizer a todas as condições, o servidor RADIUS pode, de forma a garantir uma segurança adicional, enviar um pacote do tipo Desafio de acesso. Este desafio pode vir na forma de uma pergunta que somente o usuário sabe, ou vir na forma de um código que somente os usuários com determinados dispositivos como smartcards ou softwares específicos conseguirão responder corretamente, garantindo a identidade do mesmo. A resposta ao Desafio de aceso é outra mensagem do tipo Requisição de acesso, onde o campo com a senha do usuário é preenchida com a resposta do desafio criptografada e uma marcação para indicar que a requisição é uma resposta ao Desafio de Acesso.
Por fim, se todas as condições forem satisfeitas, e se o usuário responder corretamente ao desfio de acesso, o servidor RADIUS envia um pacote do tipo Acesso aceito, que contém informações a respeito do serviço a ser oferecido. Dentre estas informações, podemos citar o tipo de serviço, o IP atribuído ao usuário, parâmetros de configuração, tempo de acesso máximo, o protocolo que vai ser utilizado, etc.
Considerações a respeito da
Segurança
A utilização do RADIUS como servidor AAA não é totalmente segura. Esta seção é dedicada a expor alguns dos problemas de segurança encontrados assim como as possíveis maneiras de contorná-los.
Ao utilizarmos o RADIUS, necessariamente precisamos consultar a uma base de dados responsável por associar as identidades dos usuários e suas respectivas informações de autenticação. Uma recomendação a ser seguida na utilização do RADIUS é garantir que cada nome de usuário deve estar associado somente a uma forma de autenticação. Caso sejam necessárias outras formas, diferentes nomes serão associados a cada forma de autenticação. Desta maneira são evitadas formas de ataque que exploram as formas mais fracas de autenticação. De nada adiantaria um usuário estar fortemente protegido de ataques por um método de autenticação, se este mesmo usuário também pudesse ser autenticado, por exemplo, através do Protocolo de Autenticação por Senha, que é pouco seguro.
Além disso, é fundamental que as senhas dos usuários e os segredos compartilhados (shared secrets) estejam armazenados de forma segura, onde o acesso a estas informações seja o mais restrito possível. Idealmente, os segredos compartilhados e as senhas só devem ser acessados pelos processos de autenticação. Como o RADIUS suporta o uso de uma chave de segredo estática entre o servidor AAA e o usuário, seja através da engenharia reversa, ou seja, através do monitoramento do tráfego, o atacante pode descobrir o segredo compartilhado, oferecendo riscos de segurança sérios ao sistema de autenticação. No caso do monitoramento de tráfico, podemos descobrir o segredo compartilhado a partir da resposta de autenticação, que é um h a s h M D 5 c a l c u l a d o n a f o r m a MD5(Código+Identificador+Comprimento+Campo de Autenticação do pacote de requisição de acesso+Atributos de Resposta + Segredo
Compartilhado), onde o “+” significa concatenação. Desta forma, se um atacante observar uma requisição de acesso e o pacote contendo o pedido de acesso aceito referente a esta requisição, ele pode iniciar um ataque de força bruta para descobrir o segredo compartilhado. A capacidade do atacante de poder prever algumas parcelas da mensagem que gerou o hash permite que este reduza significativamente o custo computacional para descobrir este segredo compartilhado.
Como segurança adicional, é possível se utilizar de túneis IPSEC criptografados para proteger os pacotes RADIUS, ou outros tipos de túneis para proteger os conteúdos sensíveis ou privados.
Conclusão
O RADIUS se apresenta como uma solução eficiente capaz de prover uma forma segura de se autenticar usuários e auditorar o acesso dos recursos providos a estes usuários. Ele pode utilizar diferentes mecanismos de autenticação, e é altamente adaptável. Apesar de todas as suas vantagens, o protocolo é um tanto quanto velho. O aumento constante do número de atributos incluídos em seus pacotes, visando estender o uso do RADIUS aos serviços e tecnologias mais recentes, acaba promovendo um cenário onde a dificuldade de se manter o mesmo protocolo se torna cada vez maior. Neste momento, começa a surgir a necessidade de se utilizar um novo protocolo, o DIAMETER, que é uma evolução do RADIUS. O Seu objetivo é sanar os problemas enfrentados pelo RADIUS, e promover um serviço AAA ainda mais seguro e eficiente.
Arquitetura de Aplicações em
2, 3, 4 ou N camadas
Fiz uma compilação de partes de textos e iremos aqui discutir cada um dos conceitos, mostrando as vantagens e desvantagens de aplicações em cada quantidade de camadas existentes, ou seja, toda sua evolução.
Modelo Cliente/Servidor
C l i e n t e - s e r v i d o r é u m m o d e l o c o m p u t a c i o n a l q u e separa clientes e servidores, sendo interligados entre si geralmente utilizando-se uma rede de computadores. Cada instância de um cliente pode enviar requisições de dado para algum dos servidores conectados e esperar pela resposta. Por sua vez, algum dos servidores disponíveis pode aceitar tais requisições, processá-las e retornar o resultado para o cliente. Apesar do conceito ser aplicado em diversos usos e aplicações, a arquitetura é praticamente a mesma.
O modelo Cliente/Servidor, foi criado tendo como base a descentralização dos dados e recursos de processamento, em oposição ao modelo Centralizado utilizado na época em que o Mainframe dominava absoluto. No modelo Cliente/Servidor, conforme indicado pela figura abaixo, em uma rede de computadores, existem uma ou mais máquinas que atuam como Servidores, disponibilizando recursos para as demais máquinas, as quais atuam como Clientes.
A máquina servidor é um host que está executando um ou mais programas de servidor que partilham os seus recursos com os clientes.
Um cliente não compartilha de seus recursos, mas solicita o conteúdo de um servidor ou função de serviço. Os clientes,
portanto, iniciam sessões de comunicação com os servidores que esperam as solicitações de entrada.
Modelo Cliente-Servidor
Conforme pode ser visto na figura, temos Servidores para Arquivos, Banco de dados e outras funções, tais como: Servidores de impressão, Servidores Web, etc. Estas redes, tipicamente, são formadas por Servidores, os quais são equipamentos com um maior poder de processamento e armazenamento do que os clientes, os quais, na maioria dos casos, são Microcomputadores ligados em rede.
Aplicações em 2 Camadas
No início da utilização do modelo Cliente/Servidor, as aplicações foram desenvolvidas utilizando-se um modelo de desenvolvimento em duas camadas. Neste modelo, um programa, normalmente desenvolvido em um ambiente de desenvolvimento, como o Visual Basic, Delphi ou Power Builder, é instalado em cada Cliente. Este programa acessa dados em um servidor de Banco de dados, conforme ilustrado na figura abaixo:
2 Camadas
No modelo de duas camadas, temos um programa que é instalado no Cliente, programa esse que faz acesso a um Banco de dados que fica residente no Servidor de Banco de dados. Na maioria dos casos, a máquina do Cliente é um PC rodando Windows, e a aplicação Cliente é desenvolvida utilizando-se um dos ambientes conhecidos, conforme citado anteriormente. Sendo a aplicação Cliente, um programa para Windows (na grande maioria dos casos), esta deve ser instalada em cada um dos computadores da rede, que farão uso da aplicação. É o processo de instalação normal, para qualquer aplicação Windows. No modelo de 2 camadas, a aplicação Cliente é responsável pelas seguintes funções:
Apresentação: O Código que gera a Interface visível do programa, que é utilizada pelo usuário para acessar a aplicação, faz parte da aplicação Cliente. Todos os formulários, menus e demais elementos visuais, estão contidos no código da aplicação Cliente. Caso sejam necessárias alterações na interface do programa, faz-se necessária a geração de uma nova versão do programa, e todos os computadores que possuem a versão anterior, devem receber a nova versão, para que o usuário possa ter acesso as alterações da interface. Aí que começam a surgir os problemas no modelo de 2 camadas: Uma simples alteração de interface, é suficiente para gerar a necessidade de atualizar a aplicação, em centenas ou
milhares de computadores. O gerenciamento desta tarefa, é algo extremamente complexo e de custo elevado.
Lógica do Negócio: Aqui estão as regras que definem a maneira como os dados serão acessados e processados, as quais são conhecidas como “Lógica do Negócio”. Fazem parte das Regras do Negócio, desde funções simples de validação da entrada de dados, como o cálculo do digito verificador de um CPF, até funções mais complexas, como descontos escalonados para os maiores clientes, de acordo com o volume da compra. Questões relativas a legislação fiscal e escrita contábil, também fazem parte da Lógica do Negócio. Por exemplo, um programa para gerência de Recursos Humanos, desenvolvido para a legislação dos EUA, não pode ser utilizado, sem modificações, por uma empresa brasileira.. Alterações nas regras do negócio são bastante freqüentes, ainda mais com as repetidas mudanças na legislação do nosso país. Com isso, faz-se necessária a geração de uma nova versão do programa, cada vez que uma determinada regra muda, ou quando regras forem acrescentadas ou retiradas. Desta forma, todos os computadores que possuem a versão anterior, devem receber a nova versão, para que o usuário possa ter acesso as alterações . Mais problemas com o modelo de 2 camadas: Qualquer alteração nas regras do negócio, é suficiente para gerar a necessidade de atualizar a aplicação, em centenas ou milhares de computadores. O gerenciamento desta tarefa, é algo extremamente complexo e de custo elevado.
A outra camada, vem a ser o Banco de dados, o qual fica armazenado em Servidor da rede. Uma aplicação desenvolvida em Visual Basic, a qual acessa um Banco de dados em um servidor Microsoft SQL Server, é um típico exemplo de uma aplicação em 2 camadas.
Com a evolução do mercado e as alterações da legislação, mudanças nas regras do negócio são bastante freqüentes. Com isso o modelo de duas camadas, demonstrou-se de difícil
manutenção e gerenciamento, além de apresentar um custo de propriedade muito elevado.
Isto sem contar com o problema conhecido como “DLL Hell” (Inferno das DLLs), onde diferentes aplicativos, instalam diferentes versões da mesma DLL e um conflito é gerado. É o caso típico onde a instalação de um programa, faz com que um ou mais programas, instalados anteriormente, deixem de funcionar. Em resumo, como diria um famoso comediante: “Uma verdadeira visão do Inferno”. Inferno para o usuário, que não tem os programas funcionando como deveriam; inferno para a equipe de desenvolvimento que não tem o seu trabalho reconhecido e, normalmente, tem que trabalhar apenas “apagando incêndios”; e inferno para a Administração/Gerência da rede que não consegue gerar os resultados esperados pela Administração da empresa, apesar dos elevados valores já investidos.
Resumindo:
Sistemas em camadas surgiram para:
Melhor aproveitar os PCs da empresa
Oferecer sistemas com interfaces gráficas amigáveis
Integrar o desktop e os dados corporativos Em outras palavras, permitiram aumentar a escalabilidade de uso de Sistemas de Informação Os primeiros sistemas cliente-servidor eram de duas camadas
Camada cliente trata da lógica de negócio e da UI
Camada servidor trata dos dados (usando um SGBD)
Pode parecer difícil de acreditar, mas um grande número de empresas ainda tem a maioria dos seus aplicativos baseados no
modelo Cliente/Servidor de 2 camadas. Em busca de soluções para os problemas do modelo de duas camadas, é que surge a proposta do modelo de 3 camadas.
Aplicações em 3 Camadas
Modelo em três camadas, derivado do modelo ‘n’ camadas, recebe esta denominação quando um sistema cliente-servidor é desenvolvido retirando-se a camada de negócio do lado docliente. O desenvolvimento é mais demorado no início comparando-se com o modelo em duas camadas pois é necessário dar suporte a uma maior quantidade de plataformas e ambientes diferentes. Em contrapartida, o retorno vem em forma de respostas mais rápidas nas requisições, excelente performance tanto em sistemas que rodam na Internet ou em intranet e mais controle no crescimento do sistema.
Como uma evolução do modelo de 2 camadas, surge, com o crescimento da Internet, o modelo de três camadas. A idéia básica do modelo de 3 camadas, é “retirar” as Regras do Negócio do cliente e centralizá-las em um determinado ponto, o qual é chamado de Servidor de Aplicações. O acesso ao Banco de dados é feito através das regras contidas no Servidor de Aplicações. Ao centralizar as Regras do Negócio em um único ponto, fica muito mais fácil a atualização destas regras. A figura, nos dá uma idéia geral do modelo em 3 camadas:
3 Camadas
Todo o acesso do cliente ao Banco de dados, é feito de acordo com as regras contidas no Servidor de aplicações. O cliente não tem acesso direto ao Banco de dados, sem antes passar pelo servidor de aplicações. Com isso as três camadas são as seguintes:
Apresentação: Continua no programa instalado no cliente. Alterações na Interface do programa, geram a necessidade de atualizar a aplicação em todos os computadores, onde esta está sendo utilizada. Porém cabe ressaltar, que alterações na interface, são menos freqüentes do que alterações nas regras do negócio.
Lógica: São as regras do negócio, as quais determinam de que maneira os dados serão utilizados. Esta camada foi deslocada para o Servidor de aplicações. Desta maneira, quando uma regra do negócio for alterada, basta atualizá-la no Servidor de aplicações. Após a atualização, todos os usuários passarão a ter acesso a nova versão, sem que seja necessário reinstalar o programa em cada um dos computadores da rede. Vejam que ao centralizar as regras do negócio em um Servidor de aplicações, estamos facilitando a tarefa de manter a aplicação atualizada.
Dados: Nesta camada temos o servidor de Banco de dados, no qual reside toda a informação necessária para o funcionamento da aplicação. Cabe ressaltar, novamente, que os dados somente são acessados através do Servidor de aplicação, e não diretamente pela aplicação Cliente. Resumindo:
A arquitetura cliente/servidor em 2 camadas sofria de vários problemas:
Falta de escalabilidade (conexões a bancos de dados)
lógica de aplicação forçava instalações)
Dificuldade de acessar fontes heterogêneas (legado CICS, 3270, …)
Inventou-se a arquitetura em 3 camadas Camada de apresentação (UI)
Camada de aplicação (business logic) Camada de dados
Problemas de manutenção foram reduzidos, pois mudanças às camadas de aplicação e de dados não necessitam de novas instalações no desktop
Observe que as camadas são lógicas:
Fisicamente, várias camadas podem executar na mesma máquina
Quase sempre, há separação física de máquinas
Com a introdução da camada de Lógica, resolvemos o problema de termos que atualizar a aplicação, em centenas ou milhares de computadores, cada vez que uma regra do negócio for alterada. Porém continuamos com o problema de atualização da aplicação, cada vez que forem necessárias mudanças na Interface. Por isso que surgiram os modelos de n-camadas. Agora vamos falar um pouco sobre o modelo de 4 camadas.
Aplicações em 4 Camadas (Web
Based)
Como uma evolução do modelo de três camadas, surge o modelo de quatro camadas. A idéia básica do modelo de 4 camadas, é retirar a apresentação do cliente e centralizá-las em um determinado ponto, o qual na maioria dos casos é um servidor Web. Com isso o próprio Cliente deixa de existir como um programa que precisa ser instalado em cada computador da rede. O acesso a aplicação, é feito através de um Navegador, como o Internet Explorer ou o Netscape Navigator. A figura nos dá uma idéia geral do modelo em quatro camadas:
4 Camadas
Para acessar a aplicação, o cliente acessa o endereço da aplicação, utilizando o seu navegador. Por exemplo http://www.empresa-abc.com/sistemas/cadastro.asp . Todo o acesso do cliente ao Banco de dados, é feito de acordo com as regras contidas no Servidor de aplicações. O cliente não tem acesso direto ao Banco de dados, sem antes passar pelo servidor de aplicações. Com isso as quatro camadas são as seguintes:
Cliente: Nesta caso o Cliente é o Navegador utilizado pelo usuário, quer seja o Internet Explorer, quer seja o Netscape Navigator, ou outro Navegador qualquer.
Apresentação: Passa para o Servidor Web. A interface pode ser composta de páginas HTML, ASP, ou qualquer outra tecnologia capaz de gerar conteúdo para o Navegador. Com isso alterações na interface da aplicação, são feitas diretamente no servidor Web, sendo que estas alterações estarão, automaticamente, disponíveis para todos os Clientes. Com isso não existe a necessidade de reinstalar a aplicação em todos os computadores da rede cada vez que uma alteração for feita na camada de apresentação. Fica muito mais fácil garantir que todos estão acessando a versão mais atualizada da aplicação. A única coisa que o cliente precisa ter instalado na sua máquina, é o Navegador. O
acesso ao Banco de dados, é feito através do Servidor de aplicações.
Lógica: São as regras do negócio, as quais determinam de que maneira os dados serão utilizados. Esta camada está no Servidor de aplicações. Desta maneira, quando uma regra do negócio for alterada, basta atualizá-la no Servidor de aplicações. Após a atualização, todos os usuários passarão a ter acesso a nova versão, sem que seja necessário reinstalar o programa em cada um dos computadores da rede. Vejam que ao centralizar as regras do negócio em um Servidor de aplicações, estamos facilitando a tarefa de manter a aplicação atualizada. Dados: Nesta camada temos o servidor de Banco de dados, no qual reside toda a informação necessária para o funcionamento da aplicação.
Com o deslocamento da camada de apresentação para um Servidor Web, resolvemos o problema de termos que atualizar a aplicação, em centenas ou milhares de computadores, cada vez que a interface for alterada. Neste ponto a atualização das aplicações é uma tarefa mais gerenciável, muito diferente do que acontecia no caso do modelo em duas camadas.
Os servidores de Aplicação, servidor Web e servidor de Banco de dados, não precisam, necessariamente, ser servidores separados, isto é, uma máquina para fazer o papel de cada um dos servidores. O conceito de servidor de Aplicação, Web ou Banco de dados, é um conceito relacionado com a função que o servidor desempenha. Podemos ter, em um mesmo equipamento, um Servidor de aplicações, um servidor Web e um servidor de Banco de dados. Claro que questões de desempenho devem ser levadas em consideração.
Resumindo:
A arquitetura em 3 camadas original sofre de problemas: A instalação inicial dos programas no desktop é cara
O problema de manutenção ainda persiste quando há mudanças à camada de apresentação
Não se pode instalar software facilmente num d e s k t o p q u e n ã o e s t á s o b s e u c o n t r o l e administrativo
Em máquinas de parceiros Em máquinas de fornecedores Em máquinas de grandes clientes Em máquinas na Internet
Então, usamos o Browser como Cliente Universal Conceito de Intranet
A camada de aplicação se quebra em duas: Web e Aplicação
Evitamos instalar qualquer software no desktop e portanto, problemas de manutenção
Evitar instalação em computadores de clientes, parceiros, fornecedores, etc.
Às vezes, continua-se a chamar isso de 3 camadas porque as camadas Web e Aplicação freqüentemente rodam na mesma máquina (para pequenos volumes)
Arquitetura em N Camadas
Os problemas remanescentes:
Não há suporte a Thin Clients (PDA, celulares, smart cards, quiosques, …) pois preciso usar um browser (pesado) no cliente
Dificuldade de criar software reutilizável: cadê a componentização?
Fazer aplicações distribuídas multicamadas é difícil. Tem que:
Implementar persistência (impedance
mismatch entre o mundo OO e o mundo dos BDs
relacionais)
Implementar tolerância a falhas com fail-over
I m p l e m e n t a r g e r ê n c i a d e t r a n s a ç õ e s distribuídas
Implementar balanceamento de carga Implementar resource pooling
etc.
As empresas não querem contratar PhDs para implementar sistemas de informação!
O truque é introduzir middleware num servidor de aplicação que ofereça esses serviços automaticamente
Além do mais, as soluções oferecidas (J2EE, .Net) são baseadas em componentes
As camadas podem ter vários nomes: Apresentação, interface, cliente Web
Aplicação, Business
Dados, Enterprise Information System (EIS)
N Camadas Fontes:
http://www.juliobattisti.com.br/artigos/ti/ncamadas.asp http://jacques.dsc.ufcg.edu.br/cursos/j2ee/html/intro/intro.ht m http://pt.wikipedia.org/wiki/Modelo_em_três_camadas http://pt.wikipedia.org/wiki/Cliente-servidor http://pt.wikipedia.org/wiki/N_camadas
