Serviços

Consultoria no âmbito do RGPD

O Regulamento (UE) 2016/679, do Parlamento Europeu e do Conselho, de 27 de abril de 2016, doravante designado RGPD, veio introduzir um novo regime em matéria de proteção de dados pessoais, tendo revogado a Diretiva n.º 95/46/CE.

Para além do reforço da proteção jurídica dos direitos dos titulares dos dados, o RGPD exige novas regras e procedimentos do ponto de vista tecnológico.

A relação entre a tecnologia e o Direito está espelhada, de modo especial, na proteção de dados desde a conceção e por defeito (artigo 25.º do RGPD), nas medidas adequadas para garantir a segurança do tratamento (artigo 32.º do RGPD), na notificação de violações de dados pessoais às autoridades de controlo (artigo 33.º do RGPD), na comunicação de violação de dados pessoais aos titulares dos dados (artigo 34.º do RGPD) e na avaliação de impacto sobre a proteção de dados (artigo 35.º do RGPD). O direito ao apagamento dos dados pessoais e o direito à portabilidade destes, consagrados respetivamente nos artigos 17.º e 20.º do RGPD, exigem igualmente a implementação de tecnologias de informação que utilizem formatos interoperáveis, sem imposição ou discriminação em favor da utilização de um determinado tipo de tecnologia, e que permitam que estes direitos possam ser efetivamente exercidos.

Neste sentido, e conforme a Resolução do Conselho de Ministros 41 de 2018 (extrato na seguinte tabela), a Hardsecure implementa os controlos necessários para garantir compliance com o regulamento e estabelece um conjunto de ações que permite à organização garantir a sua continuidade, face a novas formas de riscos de segurança. Estes requisitos técnicos são complementados com os requisitos procedimentais e processuais estabelecidos na norma ISO27001:2013, ISO27002:2013 e ISO27005.

 

Arquitetura de Segurança das Redes e Sistemas de Informação - Requisitos Técnicos

As aplicações cliente (exemplo: Android, IOS, web) devem ser desenvolvidas adotando práticas de desenvolvimento seguro:

FE

  • Seguir as boas práticas de desenvolvimento.  Obrigatório
    • Exemplo: Open Web Application Security Project no que respeita ao desenvolvimento de código seguro e de submissão desse código a testes de segurança. 
  • Utilização de sessões seguras com protocolo de segurança.  Obrigatório
  • Utilização de Transport Layer Security (TLS), na sua versão mais recente. Recomendado
  • Não guardar informação pessoal no browser, memória ou disco, para além do tempo da sessão e apenas na medida do necessário.  Obrigatório

APP

  • Utilização de sessões seguras com protocolo de segurança.  Obrigatório
  • Recomenda-se o uso de TLS, na sua versão mais recente, na comunicação com as camadas adjacentes.  Recomendado
  • Se possível usar certificados através de Application Programming Interface (API), não sendo desta forma necessário o uso de palavras-passe.  Recomendado
  • Não é permitida a utilização de credenciais em plain text, quer no código quer em ficheiros de configuração.   Recomendado
  • Deve ser evitado palavras-passe embebidas no código.  Recomendado
  • As credenciais que necessitem de ser armazenadas em ficheiros de configuração devem estar codificadas (HASH - mínimo SHA 256).  Recomendado

BD

  • Comunicação com camada aplicacional através de autenticação por certificado válido por período não superior a 2 anos, no caso de as camadas serem física ou logicamente distintas.  Obrigatório
    • Exemplo: padrão X.509, da ITU-T para Infraestruturas de Chaves Públicas (ICP)
  • Prever cifra de informação pessoal (recomenda-se mínimo 2048 bit) apenas se a aplicação cliente tiver camada de BD física e logicamente distinta, usando preferencialmente tecnologia que permita interoperabilidade entre sistemas.  Obrigatório

 Capacidade para autenticar e autorizar todos os utilizadores e dispositivos, incluindo o controlo do acesso a sistemas e aplicações.

FE

  • O processo de autenticação deve ser sempre iniciado e mantido em sessão segura.  Obrigatório
  • Recomenda-se: 1) o uso de TLS, na sua versão mais recente; ou 2) o uso de palavra-passe, preferencialmente em combinação com outro fator (Double Factor Authentication-2FA).  Recomendado

  Como por exemplo:

  • Palavra-passe + SMS Token
  • Palavra-passe + Smartcard
  • Palavra-passe + Biometria
  • Palavra-passe + Padrão Gráfico
  • Palavra-passe + Cartão de coordenadas
  • Palavra-passe + Código Aleatório Temporário (menos de 5 minutos de validade) enviado na forma de QR-Code
  • Dados pessoais de sessão excluídos das variáveis Uniform Resource Locator (URL) ou de outras variáveis visíveis ao utilizador.  Obrigatório
  • Credenciais de início de sessão transmitidos através do seu HASH, mínimo Secure Hash Algorithm-256 (SHA-256), ou utilização de cifra ou codificação para a transmissão de dados pessoais (nome do utilizador e palavra-passe em HASH e restantes dados cifrados).  Obrigatório
  • Sempre que aplicável, 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».

Recomenda-se que para novos sistemas seja sempre usado como padrão de autenticação o 2FA.

APP 

  • A palavra-passe dos administradores deve ter no mínimo 13 caracteres e ser complexa. Neste caso, 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».  Obrigatório
  • Para todos os administradores deve-se utilizar Padrão de autenticação 2FA.  Obrigatório
    • Palavra-passe + Smartcard
    • Palavra-passe + Biometria
    • Palavra-passe + certificado (por exemplo X.509, da ITU-T para ICP, válido por período não superior a 2 anos).
  • Como mecanismo de proteção e segurança da informação recomenda-se o uso de Token.  Recomendado
  • Comunicação com camadas FE ou BD através de sessão segura, com prévia autenticação se as camadas forem físicas ou logicamente distintas.  Recomendado
  • Deve ser evitado palavras-passe embebidas no código. Quando tal não for possível, devem estar codificadas (HASH, mínimo SHA-256).  Recomendado
  • Se possível, usar certificados através de API, não sendo desta forma necessário o uso de palavras-passe.  Recomendado
  • Autenticação de elementos comunicantes garantida por validação de informação estática ao nível da rede.  Obrigatório
    • Exemplos: 1) utilização de IP fixo + hostname + MacAddress + fatores de autenticação, ou 2) Utilização de certificados.

BD

  • A palavra-passe deve ter no mínimo 13 caracteres e ser complexa. Neste caso, 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».  Obrigatório
  • Dados pessoais de autenticação, transmitidos através do seu HASH (mínimo SHA-256), ou recorrendo à cifra ou codificação para efetuar essa transmissão. Recomendado