DOE 23/04/2024 - Diário Oficial do Estado do Ceará

45
DIÁRIO OFICIAL DO ESTADO | SÉRIE 3 | ANO XVI Nº075 | FORTALEZA, 23 DE ABRIL DE 2024
3.4.Deve-se usar criptografia para qualquer transmissão de dados, independentemente da classificação da informação trafegada.
3.4.1.Não se deve utilizar protocolos criptográficos inseguros ou obsoletos. Exemplos: SSL e versão do TLS anterior a 1.2.
3.4.2.Protocolos de texto claro como HTTP, SMTP e FTP só devem ser usados se protegidos com algum protocolo criptográfico.
3.5.Deve-se usar chaves criptográficas com tamanho considerado seguro. Por exemplo, para a cifra AES, o tamanho mínimo considerado seguro é
de 128 bits, e para curvas elípticas (ECC), 256 bits.
3.6.Deve-se utilizar criptografia de curva elíptica (ECC) como solução de criptografia assimétrica, por ser considerado mais eficiente e seguro do
que outras soluções mais antigas (como o RSA).
3.7.Deve-se utilizar o modo de cifra de bloco Galois/Counter Mode (GCM) em criptografia simétrica, por ser considerado mais eficiente e seguro.
3.8.Não se deve implementar esquemas criptográficos próprios. Deve-se usar algoritmos amplamente testados, com implementações disponíveis
em sistemas operacionais, frameworks e bibliotecas.
4.BANCO DE DADOS
4.1.Deve-se armazenar os dados persistentes em uma camada separada da aplicação/serviço que os utiliza ou manipula.
4.2.A aplicação/serviço deve usar uma conta de acesso ao banco de dados com o mínimo de privilégios necessários ao seu propósito.
4.3.A aplicação não deve ter autorização de executar comandos de definição de estruturas de dados (DDL) em bancos de dados nos ambientes de
homologação e de produção.
4.3.1.Exclui-se deste dispositivo os sistemas/serviços de gestão de banco de dados e de integração contínua CI/CD, os quais poderão ter permissão
de execução de DDL, mediante autorização e configuração pela CEITI.
4.3.2.Nos ambientes de desenvolvimento, as credenciais de acesso a banco de dados podem ter permissões mais amplas (criação e alteração de
tabelas, colunas, views, tablespace, sequences, tablespace, gerência de sessão, criação e execução de procedures e triggers, etc) para manipulação
de estrutura de esquemas/bancos.
4.3.3.Comandos SQL devem ser implementadas nos códigos das aplicações usando técnicas para evitar vulnerabilidades, usando boas práticas como:
uso de consultas parametrizadas (prepared statements); uso de funções de procedimentos nos bancos de dados (stored procedures); validação de
entrada de dados de usuários feita pela aplicação.
5.DESENVOLVIMENTO WEB
5.1.Quaisquer dados/comandos recebidos do cliente/consumidor devem ser saneados e validados no backend, independentemente de haver alguma
pré-validação no frontend.
5.2.Deve-se controlar o upload de arquivos, estabelecendo limites de tamanho e restringindo extensões.
5.2.1.Deve-se verificar o tipo de arquivo, pois a extensão e o cabeçalho Content-Type podem ser manipulados pelo usuário. Muitas vezes, os primeiros
bytes do payload podem indicar o tipo de arquivo.
5.2.2.Deve-se testar o arquivo através de um antivírus ou em um sandbox para validar que ele não contenha dados maliciosos.
5.3.Deve-se tratar as mensagens de erro geradas pelos sistemas para que não mostrem dados sensíveis nem detalhes técnicos. É preferível gerar um
identificador da falha para o usuário, que possa ser usado posteriormente pela equipe de suporte para investigar a causa.
5.4.Deve-se exigir que todo JSON web token (JWT) contenha uma assinatura e ela deve ser sempre validada.
5.5.Cookies de autenticação ou de identificação de sessão devem ter os atributos “Samesite” “Secure” e “HttpOnly” e serem prefixados com
“_Secure” ou “_Host”.
5.6.Deve-se usar o cabeçalho HTTP X-Frame-Options para evitar ataques de clickjacking.
5.7.Não se deve usar a função eval() da linguagem JavaScript.
5.8.Deve-se utilizar o cabeçalho HSTS (HTTP Strict-Transport-Security) nas respostas HTTP.
5.9.Deve-se usar o cabeçalho Content-Security-Policy para prevenir ataques de Cross-Site Scripting (XSS).
5.10.Quando for necessário carregar recursos a partir de uma origem diferente da origem que os fornece, deve-se usar cabeçalhos Cross-Origin
Resource Sharing (CORS).
5.11.Deve-se proteger requisições que alterem o estado da aplicação (como formulários) de ataques Cross-Site Request Forgery (CSRF), por
exemplo, através do uso de tokens CSRF.
6.REGISTRO DE EVENTOS
6.1.A aplicação ou o sistema deve registrar em log de segurança os eventos relevantes à segurança da informação. Exemplos: autenticação, falha de
autorização, alteração de perfil de usuário, detecção de dados de entrada manipulados ou maliciosos, detecção de atividade incomum.
6.2.Os registros de eventos de segurança devem ser guardados separadamente dos demais tipos de logs gerados pela aplicação/sistema, e seu acesso
deverá ser mais restrito.
6.2.1.Deve-se encaminhar uma cópia dos registros para um serviço de log central.
6.3.Os registros de eventos de segurança não podem ser eliminados antes do período de 1 ano.
6.4.Cada registro no log de segurança deve conter, pelo menos:
6.4.1.Tipo de evento.
6.4.2.Data e hora do evento.
6.4.3.Ação e dados de entrada (ou a ausência destes).
6.4.4.Origem da ação (usuário, endereço IP, etc.)
6.4.5.Identificação da instância da aplicação/serviço e da máquina ou contêiner que percebeu o evento.
6.5.Não se deve registrar no log de segurança dados sensíveis, como senhas.
7.CICLO DE VIDA DE SOFTWARE
7.1.Na etapa de especificação dos requisitos:
7.1.1.Deve-se identificar e classificar todos os dados tratados pelo sistema, o que inclui criação, processamento, transmissão, armazenamento e exclusão.
7.2.Na etapa de desenho/projeto:
7.2.1.Deve-se criar um modelo de ameaças, que ajudará a identificar ameaças e vulnerabilidades antes do início da implementação da aplicação/sistema.
7.2.2.Deve-se avaliar a existência de impedimentos legais para armazenamento, processamento ou transmissão de dados fora das fronteiras nacionais.
7.3.Na implantação em produção da aplicação/sistema:
7.3.1.Deve-se submeter a aplicação/serviço a um teste de segurança automatizado em ambiente segregado. O relatório do teste não deverá apresentar
qualquer vulnerabilidade categorizada como crítica.
8.EXCEÇÕES
8.1.Os casos omissos, excepcionais e eventuais dúvidas quanto à aplicação da PSI serão resolvidos pelo CSIPD.
9.PENALIDADES
9.1.O não cumprimento da Norma de Desenvolvimento Seguro por parte dos colaboradores estará sujeito às penalidades previstas nas esferas
administrativa, civil e penal.
10.ELUCIDÁRIO
10.1.Cifra de bloco: algoritmo de criptografia simétrica que opera em blocos fixos de dados de entrada, transformando cada bloco separadamente
antes de passar para o próximo bloco.
10.2.Criptografia de curva elíptica (ECC): forma de criptografía assimétrica que utiliza propriedades matemáticas de curvas elípticas sobre corpos
finitos. Oferece níveis de segurança equivalentes aos algoritmos tradicionais, porém, com chaves significativamente menores.
10.3.CSPRNG: gerador de números pseudo-aleatórios criptograficamente seguros.
10.4.JSON web token (JWT): formato compacto e autossuficiente para representar informações entre duas partes de uma forma que pode ser
verificada e confiável. Essa informação pode ser verificada e confiável porque é assinada digitalmente. JWTs são frequentemente usados para
autenticação e autorização em aplicativos web e serviços.
10.5.Salt: sequência aleatória de dados que é usada como entrada adicional em funções de hash ou algoritmos de geração de chaves. O objetivo
principal do salt é prevenir ataques de força bruta e de tabelas de hash pré-computadas (rainbow tables).
10.6.Sessão stateful: modelo de comunicação entre cliente e servidor, em que o servidor mantém informações sobre o estado da sessão durante
requisições consecutivas do mesmo cliente.
*** *** ***