O RGPD está aí e o Governo considera fundamental definir orientações técnicas para a Administração Pública, recomendando-as ao setor empresarial do Estado, em matéria de arquitetura de segurança das redes e sistemas de informação e procedimentos a adotar de modo a cumprir as normas do regulamento.
Assim, através da Resolução do n.º 41/2018 publicada no Diário da Republica em 28 de março, o Conselho de Ministros definiu uma série de requisitos técnicos mínimos das redes e sistemas de informação. Os requisitos são apresentados em forma de tabela compostos por requisitos gerais e respetivos requisitos específicos para sistemas Front-End, camada Aplicacional e base de Dados e a sua respetiva classificação quanto à obrigatoriedade de os implementar. A mesma resolução determina que os requisitos devem ser implementados num prazo máximo de 18 meses após a entrada em vigor da presente resolução, ou seja, dia 29 de Março de 2018.
Esta resolução tem uma relevância considerável, pois é crítico que exista uma postura formal em relação ao que as entidades têm de facto de implementar para estarem em conformidade com as normas do RGPD. Por esta razão, considero que todas as entidades mesmo as privadas deverão aproveitar esta tabela como um fio condutor seguro no rumo à conformidade.
Naturalmente, a tabela apresentada, é um pouco genérica e cabe aos especialistas de TI interpretá-la no enquadramento da sua Organização e encontrar soluções ou produtos que respondam às recomendações e obrigações. O detalhe dos requisitos pode ser consultado no documento original aqui: https://dre.pt/application/conteudo/114937034.
Partimos então para a análise dos diversos requisitos e possíveis soluções ou produtos para mitigar as mesmas
1. As aplicações cliente (exemplo, Android, IOS, WEB) devem ser desenvolvidas adotando práticas de desenvolvimento seguro.
Esta recomendação dirige-se às aplicações que a organização utiliza e que contenham dados pessoais. Se todas as aplicações que utiliza são comerciais, então deverá indagar o fornecedor acerca dos requisitos específicos para cada camada e de preferência exigir por escrito que os requisitos obrigatórios estão cumpridos.
Se, por outro lado a aplicação é desenvolvida à medida, então deverá preocupar-se em auditar os requisitos e corrigir as falhas. Para este requisito o importante é garantir que são seguidas as boas práticas de desenvolvimento e que todo o tráfego entre camadas é encriptado com um protocolo seguro e com certificados digitais válidos. Por exemplo, se a aplicação em questão for uma aplicação Web based, o tráfego entre o utilizador e o servidor web deverá estar encriptado em HTTPS com um certificado TLS e a comunicação entre o web server e a Base de Dados deverá de igual modo ser encriptada com um certificado digital válido por um período inferior a 2 anos.
2. Capacidade para autenticar e autorizar todos os utilizadores e dispositivos, incluindo o controlo do acesso a sistemas e aplicações.
O tema para o segundo requisito é autenticação. Um requisito crítico, pois de nada nos vale toda as outras medidas de segurança se o sistema que valida os utilizadores e respetivos acessos for fraco ou inexistente. Os requisitos específicos são de facto dois: Que todo o processo seja mantido em sessão segura (encriptado) e que a palavra-passe respeite uma composição complexa.
Em relação à segurança da sessão e a respetiva encriptação, caso a aplicação em causa utilize “Single Sign On” e a infraestrutura assente numa Active Directory, apenas terá de garantir que os protocolos obsoletos, tais como o RC4 e DES estão desativados e que não utilizam sistemas inferiores a Windows 2008 / Vista. Caso a aplicação utilize o seu próprio mecanismo de autenticação, então os requisitos específicos terão de ser passados ao fornecedor da aplicação ou no caso de uma aplicação desenvolvida à medida implementados internamente, dando a devida atenção à encriptação em transito (com TLS por exemplo) e que as credenciais sejam transmitidas através do seu hash. Está também proibida a passagem de dados pessoais em variáveis visíveis ao utilizador como por exemplo no URL.
A palavra-passe deve ter no mínimo 9 caracteres (13 caracteres para utilizadores com acesso privilegiado) e ser complexa. A sua composição deverá exigir a inclusão de 3 dos 4 seguintes conjuntos de caracteres: letras minúsculas (a…z), letras maiúsculas (A…Z), números (0…9) e caracteres especiais (~ ! @ # $ % ^ & * ( ) _ + | ` - = \ { } [ ] : “ ; ‘ < > ? , . /). Poderá, em alternativa, ser constituída por frases ou excertos de texto longo conhecidos pelo utilizador, sem caracter de «espaço». Para os administradores, no acesso à camada aplicacional deverá ser usado um sistema de dois fatores, por exemplo Password + Token.
Em relação à complexidade da palavra-passe sou forçado a discordar e a abrir uns parênteses importante:
Toda a industria, incluindo o NIST, já concluiu que a complexidade da palavra-passe não acarreta mais segurança. A escolha de uma palavra-passe complexa, como por exemplo P@$$wrd1! que respeita em completo o requisito em causa, não é segura.
Os hackers mal-intencionados sabem como um utilizador normal cria palavras-passe porque:
- Conhecem bem as substituições comuns de caracteres, tais como “$” por “s”. "P @ $$ w0rd" não representa qualquer desafio.
- Sabem também que, se houver regras de complexidade, a maioria das pessoas aplicará as regras da mesma maneira: iniciando uma palavra com letra maiúscula e terminando com um dígito ou pontuação. (Por isso, recomendo a eliminação das regras de complexidade e as recomendações mais recentes do NIST concordam.)
- Sabem que exigir que os utilizadores alterem as suas palavras-passe periodicamente leva a outros padrões previsíveis. Por exemplo, se precisarem alterar sua palavra-passe a cada trimestre, frequentemente escolherão senhas com base em clubes desportivos, meses ou estações combinadas com o ano atual.
A solução, passa por exigir um sistema de dois fatores (que a resolução recomenda e bem) e por aplicar um sistema que consiga impedir a criação de passwords inseguras no sistema. Por exemplo Azure AD MFA e Azure AD Password Protection.
3. Atribuição de direitos de acesso e privilégio de forma restrita e controlada.
Dois requisitos específicos:
1. Criação de perfis com privilégios mínimos, onde cada tipo de perfil é definido em função do Tipo de Dado Pessoal a que acede e Ação que pode efetuar sobre o Dado Pessoal (Create, Read, Update, Delete — CRUD), de acordo com o princípio da necessidade de conhecer.
2. Criação de registo de acesso, alteração e remoção (logs), com informação sobre quem acedeu, de onde acedeu (IP e Porto), quando acedeu, a que dados acedeu, que ação foi efetuada sobre os mesmos (CRUD).
O primeiro tem a ver com a máxima do menor privilégio possível. Cada utilizador apenas pode ter permissão para o que necessita de aceder. O que implica a revisão ou criação de perfis e a sua implementação no controlo de acessos de cada aplicação ou sistema.
O segundo tem a ver com registos e neste campo é obrigatório que as aplicações e sistemas suportem este registo e essencial a implementação de uma gestão centralizada de logs, com respetiva analítica e sistema de alertas como por exemplo o Azure Log Analytics e o Azure Alerts
4. Atribuição das credenciais de acesso de forma controlada através de um processo formal de gestão do respetivo ciclo de vida
O processo de atribuição de credenciais deve em primeira análise ter em conta o requisito 3. Deve também ser ao mais automatizado possível, auditado e sem permitir outro acesso que não o do destinatário da informação.
Quer isto dizer que a clássica entrega das credenciais verbalmente deixa de ser possível. O ideal será implementar um automatismo para a entrega das credenciais ao utilizador. Mais uma vez, a tarefa estará simplificada se as aplicações suportarem Single Sign On, recorrendo-se da Active Directory como repositório único de gestão de identidades.
Uma simples solução com Microsoft Forms, Powershell a Azure SSPR poderá resolver a questão.
5. Revisão de direitos de acesso de utilizadores em intervalos regulares.
As contas devem ser revalidadas periodicamente sob os mesmos critérios utilizados na criação, devendo ter em conta a segregação das funções existentes e os privilégios de acesso que devem estar associados a essas funções, em cada momento (privilégios mínimos, onde cada tipo de conta é definido em função do Tipo de Dado Pessoal a que acede e Ação que pode efetuar sobre o Dado Pessoal (CRUD).
Este requisito obriga a definição de um processo formal e recomenda a automatização do mesmo. A automatização é complexa e dificilmente será um automatismo único transversal a todas as aplicações. Será por isso importante, mais uma vez, o SSO e a orquestração com os fornecedores das aplicações.
É também recomendado implementar uma alarmística que informe quando um utilizador está sem atividade há mais de 90 dias e desative a conta. Este processo, para as contas da Active Directory pode ser resolvido recorrendo a um script Powershell.
6.Capacidade para garantir que os utilizadores fazem uma utilização correta dos dados.
Os requisitos para este tema são idênticos aos do ponto 5, acrescidos da obrigatoriedade de registo da sua atividade. É assim obrigatório que as aplicações e sistemas suportem este registo e essencial uma gestão centralizada de logs, com respetiva analítica e sistema de alertas como por exemplo Azure Log Analytics e Azure Alerts
7. Restrição de acesso à informação baseado no princípio necessidade de conhecer (criação de perfil).
Mapeados os perfis de acesso será necessário configurar as fontes de dados de forma que o acesso aos mesmos esteja restringido em função da sua classificação. Ou seja, no caso de um documento classificado como “Confidencial RH”. Apenas as contas com perfis associados a funções RH, deverão conseguir aceder ao mesmo. Será também necessário registar com alarmística as tentativas de acesso a dados excluídos dos privilégios associados ao perfil. O Azure Information Protection em conjunto com o Azure log Analytics e Azure Alerts podem dar uma valiosa ajuda a preencher este requisito.
8. Automatização dos processos de concessão, revisão, análise e revogação de acesso.
Aplicam-se as mesmas disposições que no ponto “6. Capacidade para garantir que os utilizadores fazem uma utilização correta dos dados” e no ponto “5. Revisão de direitos de acesso de utilizadores em intervalos regulares”.
9. Procedimentos seguros de início de sessão
Aplicam -se as mesmas disposições referidas em “2. Capacidade para autenticar e autorizar todos os utilizadores e dispositivos, incluindo o acesso controlado por um procedimento seguro de início de sessão”.
Da análise destes 9 pontos, concluímos a importância e peso que a gestão de identidades e controlo de acessos tem para o RGPD. E também fácil perceber que a consolidação dos diretórios de utilizadores para um repositório central único como a Active Directory é essencial para conseguir responder aos requisitos da forma mais simples, rápida e com inferior custo. Realço ainda que apesar de alguns dos produtos que foram referidos serem da família Microsoft Azure, a cloud da Microsoft, os mesmos implementam controlos nos sistemas instalados localmente e não obrigam uma passagem dos dados para a nuvem da Microsoft.
Na segunda parte deste artigo serão decifrados os restantes 8 requisitos da tabela apresentada na resolução do conselho de ministros. Não percam a próxima edição!
