Política de acesso a recursos de TI

Quando eu ainda cursava tecnologia de redes, meu bom professor Gisler ministrava a disciplina de administração de sistemas.
O pulo do gato na elaboração de uma política de uso de recursos, dizia ele, era identificar os usuários, identificar os recursos, separar os usuários em grupos e decidir quem teria que tipo de acesso aos recursos (identificar acessos). Uma vez feita a matriz, era só administrá-la.
Lembro-me de que fiquei fascinado com essas palavras, proferidas às 22:20 ao fundo sonoro de tiros esparsos e contumazes no Rio Comprido (rs rs...). Sim, era óbvio, mas não era tão simples, segundo ele demonstrou.

Identificar usuários implica em saber quem são as pessoas, onde estão. Não é tão fácil, se você considerar que as pessoas se movem tanto fisicamente quanto temporal e administrativamente.
Um técnico judiciário pode tornar-se um juiz através de concurso. O que você fará ? Criará uma sigla e senha nova de rede para ele ? Apagará seus registros antigos ? Seus logs de rede ficariam inconsistentes ! Criará uma nova sigla e senha ? Como a sigla antiga ficará relacionada com a pessoa atual ? São decisões interessantes e variam segundo a instituição. De qualquer modo, a atividade de definir usuários depende de ferramentas de diretório (Open LDAP, AD, Oracle OID) e a dica é: cada identidade deve ser única. Você ainda terá que decidir se os acessos serão validados por senha, biometria, certificação digital etc. Melhor pensar nisso logo...

Identificar recursos tem a ver com sistemas de inventário e listas de controle de acesso (ACLs). Os recursos podem ser hardware (micros, impressoras...), software (licenças de Office...), serviços (acesso a correio eletrônico, logon de rede...), documentos em geral. É uma boa idéia a sua instituição ter um plano de classificação de documentos. Melhor ainda se tiver um plano de classificação de informações.
As políticas externas também influem aqui. Nos Estados Unidos, o HIPAA determina regras para o manuseio e guarda de informações de saúde, bem como políticas e comunicação. Isso quer dizer, por exemplo, que os e-mails devem ser guardados em servidores (e não nos desktops) e devem sofrer backup. Além disso, os usuários não podem removê-los, apenas podem acrescentar mensagens.

Identificar acessos é a parte mais desafiadora. Quem pode fazer o que com quais recursos ? O usuário “A” pode escrever em qualquer impressora, mesmo naquelas às quais ele não tem acesso físico ? Isso quer dizer que qualquer um pode mandar dados para a impressora do diretor ? Isso implica que código pernicioso pode ser guardado ali também, afinal, é uma máquina com 2GB de memória...
E os grupos, estão bem definidos ? Alguns sistemas operacionais aceitam sempre o acesso mais restritivo (e.g. Windows 2003), enquanto outros o menos restritivo (como os velhos Windows NT ainda em uso por aí). O Unix, por exemplo, permite uma gama de ACLs (access control lists).

De qualquer modo, você terá que fazer a sua matriz, com ou sem ajuda de ferramentas. Liste os recursos, os usuários, defina as políticas de acesso físico e lógico e defina os grupos. Você terá de analisar riscos também ! Não se esqueça de que, nas aplicações corporativas, cada módulo deve ter uma política de acesso para cada função. É algo semelhante a definir, na moderna visão da UML, quem pode ter que acesso a quais atributos, métodos ou classes.

Saudades do coronel Gisler. Vida longa, saúde e prosperidade !