SEGURANÇA

Um dos aspectos fundamentais do serviço de diretórios LDAP é segurança das informações armazenadas no servidor LDAP. De acordo com o modelo de segurança, são definidos, quais os procedimentos que devem ser tomados para evitar o acesso não autorizado às informações dos diretórios, como protocolos de autenticação e encriptação (PAPOTTI et. al., 2006).

Na atual versão do LDAP (LDAPv3), que trata a autenticação baseada nos modos de como os servidores são acessados. Com isso, utilizam-se frameworks SASL, bem como, múltiplos mecanismos de autenticação (SUNGAILA, 2007).

3.2.1 Métodos de Autenticação

A terceira e última versão do LDAP (LDAPv3), possuí métodos de autenticação que foram definidos na RFC 2829 (Authentication Methods for LDAP) (SUNGAILA, 2007). Nessa RFC, os servidores LDAP foram classificados em três grupos:

1) Públicos para somente-leitura, na qual permitem “login” anônimos, ou seja, sem que o usuário informe a senha.

2) Com autenticação usando senhas e mecanismo SASL DIGEST-MD5 (RFC 2831 – Using Digest Authentication as a SASL Mechanism).

3) Autenticação e criptografia de dados, utilizando StartTLS (RFC 2830 LDAPv3: Extension for Transport Layer Security) para camada de transporte segura e certificados com chaves públicas para autenticação de ambos os lados.

As interfaces de gerenciamento, em padrão UNIX (inclui Linux também) e Samba (para autenticar estações Windows), por exemplo, das contas de usuários são realizadas nos arquivos passwd e shadow. O processo de autenticação é realizado com o usuário digitando o login e a senha de acesso, ao passo que o sistema efetua a checagem da senha fornecida corresponde à oficial criptografada que é armazenada no arquivo-texto (/etc/passwd). Esse processo baseia-se no conceito de que o usuário é realmente o solicitado, e a senha de acesso está correta. Para que esse processo funcione adequadamente, foram desenvolvidas aplicações, levando em consideração estes procedimentos (login, ftpd etc) (SUNGAILA, 2007).

Desde então, vários métodos de autenticação têm sido criados, desenvolvidos, testados e colocados em produção, incluindo mecanismos complicados de substituição do passwd, dispositivos de hardware como o Smart Cards e outros. O problema gerado com isto é que, a cada novo esquema de autenticação apresentado, todos os aplicativos envolvidos em autenticação de usuários, devem ser reescritos para suportá-los (SUNGAILA, 2007).

A partir desse contexto, pode-se utilizar o PAM (Pluggable Authentication Modules) que equivale a dizer que é um método flexível de checagem de itens de segurança quando um usuário efetua logon.

O PAM foi criado pela Sun Microsystems para oferecer um método de desenvolver aplicações que sejam independentes do mecanismo de autenticação em uso. Estas aplicações passam a solicitar ao PAM que o usuário seja autenticado. Este, por sua vez, utiliza o módulo de autenticação definido pelo administrador local, durante a fase de configuração do equipamento, e é totalmente transparente para as aplicações (o login é uma destas) (CERQUEIRA, 2005). Todas as aplicações do PAM foram publicadas pela Sun no formato de RFC, na qual o Linux baseia-se para a utilização.

Os módulos de autenticação PAM foram divididos em quatro categorias distintas (SUNGAILA, 2007), definindo os tipos disponíveis:

• auth – faz a validação do usuário, verificando a identidade por várias maneiras: checando usuário e senha, método mais simples e mais usual, utilizando a verificação biométrica como impressão digital, timbre voz ou imagem da retina. Pode ainda limitar o número de usuários ou restringir o acesso do root em algum serviço.

• account - verifica se o usuário pode utilizar o serviço na qual está tentando autenticação, checando o horário da conexão, o grupo do usuário, o dia da semana, o IP (Internet Protocol) de origem ou ainda o número de logins simultâneos.

• passwd – entra em funcionamento durante o processo de troca de senhas dos usuários. Módulos deste tipo incluem a cracklib que checa se a senha do usuário é fraca ou se pertence a algum dicionário conhecido, melhorando a segurança das senhas.

• session – cria o ambiente do usuário, habilitando dispositivos de hardware aos quais o usuário tenha direito de acesso, como cdrom, placas de áudio e outros, mapeia sistemas de arquivos remotos, efetua registros em log, além de criar recursos como o diretório pessoal do usuário caso este não exista. Porém, determina o que será necessário para que o usuário se conecte.

De forma ampla, o PAM é um conjunto de bibliotecas fornecido com a maioria das distribuições Linux moderno e é instalado por padrão no RedHat Linux. As bibliotecas do PAM fornecem uma interface consistente a um protocolo de autenticação. Uma aplicação pode usar essas bibliotecas para permitir o uso de

qualquer protocolo de autenticação dentro da aplicação. Assim, se o administrador de sistema mudar, por exemplo, a autenticação de /etc/passwd para o LDAP, a aplicação não precisa ser reescrita ou recompilada (CERQUEIRA, 2005). Exige-se um módulo para cada sistema de autenticação.

O PAM somente fornece parte da informação necessária para controlar os usuários em um sistema Linux. Além de permitir checagem se um usuário entrou com a senha correta, um sistema Linux precisa de outras informações, como o ID numérico do usuário, o diretório, o shell padrão e etc. Esta informação, normalmente é armazenada no arquivo /etc/passwd, pode ser determinada através de uma interface de sistema conhecida como NSS (Name Service Switch) (CERQUEIRA, 2005).

3.2.2 Métodos de Criptografia

Uma forma de manter a confidencialidade dos dados é através da criptografia. Ela fornece técnicas que permitem a codificação e decodificação dos dados, onde os mesmos podem ser transmitidos e armazenados sem que haja alterações ou a exposição à entidade não autorizada. O objetivo da criptografia é prover uma comunicação segura, garantindo aos serviços a confidencialidade, autenticidade e integridade.

A criptografia de chave pública e implementações dentro de um servidor LDAP baseado num sistema de segurança, tem sido possível devido às redes e protocolos de aplicações serem padronizados. Os protocolos mais importantes são SSL e TLS. O SSL/ TLS (última versão do SSL) é um sistema aberto, protocolo não proprietário desenvolvido pela Netscape para prover segurança durante as comunicações sensíveis. Este é aceito pelo padrão WEB para a comunicação entre cliente-servidor criptografada e autenticada, podendo rodar em baixo dos protocolos de aplicação HTTP, SNMP, FTP, LDAP e Telnet [Baltimore] (COUTINHO; MSILVA, 2006). Este é seguro, rápido e facilmente adaptado a outros protocolos WEB (Figura 17).

Figura 17. LDAP usando SASL com SSL/TLS, retirado do (BRANCO, 2004) O TLS é um padrão do IETF, proposto pela Microsoft, que é definido como um protocolo que fornece privacidade de comunicação e segurança entre duas aplicações que comunicam-se através de uma rede. O TLS fornece um canal seguro através da encriptação da comunicação e permite aos clientes autenticarem-se nos servidores ou, opcionalmente, que os servidores autentiquem os clientes (KANIES, 2001).

Os clientes que usam TLS na comunicação, as mensagens não serão decifradas caso sejam capturadas e nem alteradas (homem do meio), bem como, podem autenticar o servidor e verificar a autenticidade de servidores nos quais ele já está conectado, usando certificados com chaves públicas (KANIES, 2001).

Conforme foi citado anteriormente, o NSS é uma interface de sistema, que pode guardar as informações do usuário, na qual, delimita um conjunto de bibliotecas designadas para o suporte de desenvolvimento de uma plataforma de segurança – aplicações de servidores e clientes habilitados. A construção de aplicações com NSS podem suportar certificados de SSL v2 e v3, TLS e outros padrões de segurança (SUNGAILA, 2007).

3.2.3 Modelo de Controle de Acesso

O modelo define os direitos de acesso as informações do diretório para cada usuário ou grupo, como por exemplo, somente leitura de nomes para usuário administrador, alteração de descrição para todos os usuários e leitura de informações básicas do diretório para usuário anônimo (SUNGAILA, 2007).

Porém, esse controle de acesso não foi padronizado pela IETF (PAPOTTI et. al., 2006), por que ainda está sendo definido um padrão. Cada fabricante tem um padrão distinto, com muito trabalho de migração, visto que às vezes é necessária a mudança de fabricante.