DOU 03/05/2024 - Diário Oficial da União - Brasil
Baixar página em PDF · Criar alerta deste tema
O visualizador interativo precisa de JavaScript — baixe a página original em PDF.
TEXTO OFICIAL · ÍNTEGRA
Documento assinado digitalmente conforme MP nº 2.200-2 de 24/08/2001, que institui a Infraestrutura de Chaves Públicas Brasileira - ICP-Brasil. Este documento pode ser verificado no endereço eletrônico http://www.in.gov.br/autenticidade.html, pelo código 06012024050300005 5 ISSN 1677-7042 Seção 1 - Edição Extra Nº 85-B, sexta-feira, 3 de maio de 2024 Conteúdo do software 15 - O software de jogos não deve conter código malicioso ou funcionalidade considerada maliciosa. Política de Cookies 16 - Os apostadores devem ser informados do uso de cookies na instalação do software de jogos ou no acesso aos sítios eletrônicos para jogar. Quando os cookies forem necessários para os jogos on-line, estes não podem ocorrer se a política de cookies não for aceita pelo apostador. Todos os cookies utilizados não devem conter código malicioso. Acesso à informação 17 - A plataforma de jogos on-line deverá exibir diretamente da interface do usuário ou de uma página acessível ao apostador: a) as regras e conteúdo dos jogos; b) as informações de proteção ao apostador; c) os termos e condições; e d) a política de privacidade. Dos requisitos do Gerador de Números Randômicos (RNG) 18. Os tipos de RNGs permitidos são os seguintes: a) RNGs baseados em software: não utilizam dispositivos de hardware e derivam sua aleatoriedade principalmente de um algoritmo baseado em um computador ou em um software. Eles não incorporam aleatoriedade de hardware de forma significativa; b) RNGs baseados em hardware: derivam sua aleatoriedade de eventos físicos de pequena escala, como retroalimentação de circuito elétrico, ruído elétrico, desintegração radioativa e rotação do fóton; e c) RNGs mecânicos: geram resultados aleatórios de jogo mecanicamente, utilizando as leis da física por meio de rodilhos, embaralhadores e sopradores, por exemplo. Requisitos do código fonte 19 - A entidade certificadora habilitada pela Secretaria de Prêmios e Apostas do Ministério da Fazenda deverá revisar o código-fonte de todo e qualquer algoritmo de aleatoriedade principal, algoritmos de escalonamento, algoritmos de embaralhamento e outros algoritmos ou funções que desempenham um papel crítico na geração do resultado aleatório selecionado para uso por um jogo. Análise estatística 20 - A entidade certificadora habilitada pela Secretaria de Prêmios e Apostas do Ministério da Fazenda deverá utilizar testes estatísticos para avaliar os resultados gerados pelo RNG, selecionando testes adequados conforme o tipo de RNG que está sendo analisado e seu uso no jogo. 21 - Os testes estatísticos aplicados pela entidade certificadora serão avaliados em conjunto comparando a um nível de confiança de 99%, devendo incluir qualquer um ou mais dos seguintes métodos: a) distribuição total ou Chi–Quadrado; b) testes de sobreposição; c) testes de coletor de tickets; d) runs tests; e) testes de correlação de interação; f) testes de correlação serial; e g) testes de duplicação. Distribuição 22 - Cada seleção disponível de RNG deverá ter a mesma probabilidade de ser escolhida. Quando o design do jogo especificar uma distribuição não uniforme, o resultado deve estar de acordo com a distribuição desejada e observar os seguintes requisitos: a) todos os algoritmos de escalonamento, mapeamento e embaralhamento utilizados deverão ser imparciais e verificados através de uma revisão de código-fonte, sendo permitido o descarte de valores de RNG neste contexto para eliminar a parcialidade; e b) o resultado deverá ser testado contra a distribuição pretendida utilizando os testes estatísticos adequados. Independência 23 - O conhecimento dos números sorteados em um sorteio não deve fornecer informações sobre os números que possam ser sorteados em um sorteio futuro. Se o RNG selecionar vários valores dentro de um único sorteio, conhecer um ou mais valores não deverá proporcionar informações sobre os outros valores, a menos que previsto na arquitetura do jogo e previamente autorizado pela Secretaria de Prêmios e Apostas do Ministério da Fazenda, observado o seguinte: a) o RNG não deverá descartar ou modificar seleções baseadas em seleções anteriores, exceto se previsto pela arquitetura do jogo, como em funcionalidades sem troca; e b) a apresentação do resultado deverá ser testada quanto à independência entre sorteios e, se aplicável, dentro de um mesmo sorteio, usando testes estatísticos apropriados. Resultados Disponíveis 24 - O conjunto de resultados possíveis produzidos pela solução de RNG deverá ser suficientemente grande para garantir que todos os resultados estejam disponíveis em cada sorteio com a probabilidade adequada, independentemente dos resultados produzidos anteriormente, exceto quando previsto pela arquitetura do jogo e previamente autorizado pela Secretaria de Prêmios e Apostas do Ministério da Fa z e n d a . Do Monitoramento e Força do RNG Força do RNG para Determinar Resultados 25 - O RNG utilizado para gerar os resultados do jogo em uma plataforma de jogo on-line deverá ser resistente a ataques hacker utilizando recursos computacionais modernos, e que possa ter conhecimento do código fonte do RNG. Ataques Criptográficos ao RNG 26 - Um RNG criptografado não deverá ser comprometido por um hacker com conhecimento do código-fonte, sendo resistente aos seguintes tipos de ataque: a) ataque cripto-analítico direto: dada uma sequência de valores anteriores gerados pelo RNG, deverá ser computacionalmente inviável prever ou estimar os valores futuros de um RNG. Isso deverá ser garantido através do uso adequado de um algoritmo criptografado reconhecido. Um RNG baseado em hardware ou um RNG mecânico poderá ser qualificado como um algoritmo criptografado, desde que passe no teste estatístico; b) ataque de entrada conhecida: deverá ser inviável determinar computacionalmente ou estimar o estado do RNG após a propagação inicial. O RNG não deverá ser semeado apenas com base em um valor de tempo. Os fornecedores deverão garantir que os jogos não terão o mesmo seed inicial. Os métodos de propagação não devem comprometer a força criptográfica do RNG; e c) ataque de extensão de comprometimento de estado: o RNG deverá modificar periodicamente seu estado por meio do uso de entropia externa, limitando a duração efetiva de qualquer tentativa de ataque bem-sucedida por um hacker. Monitoramento de resultados dinâmicos para RNGs baseados em hardware 27 - Quando um RNG baseado em hardware for utilizado, deverá haver monitoramento dinâmico dos resultados por meio de testes estatísticos. Este processo deverá desativar o jogo quando um mau funcionamento ou alguma corrupção for detectada. Do RNG Mecânico (dispositivo físico de aleatoriedade) 28 - O software de jogo estará limitado à operação de máquinas e à leitura e gravação de dados do resultado do jogo, não desempenhando um papel determinante na sua geração. 29 - Dispositivos que criam ou exibam fiel e mecanicamente o resultado do jogo gerado por um RNG de computador não serão considerados dispositivos físicos de aleatoriedade e deverão ser testados como RNGs quando a reprodução fiel do resultado gerado do RNG tenha sido garantida. 30 - Dispositivos físicos de aleatoriedade poderão incorporar RNGs em funções secundárias, como velocidade de rotação, que não precisarão ser avaliados em relação aos requisitos de RNG descritos. Porém, o dispositivo físico de aleatoriedade deverá ser testado como um todo. 31 - Os componentes aprovados de um dispositivo físico de aleatoriedade não poderão ser substituídos por componentes não aprovados. Coleta de dados 32 - A entidade certificadora habilitada deverá coletar, pelo menos, 10.000 dados de resultados de jogos utilizando um método razoavelmente semelhante ao uso pretendido do dispositivo, quando em produção. 33 - A Secretaria de Prêmios e Apostas do Ministério da Fazenda poderá aceitar como resultados dos testes realizados pela entidade certificadora habilitada uma quantidade inferior de dados, que exigirá uma declaração sobre as limitações estatísticas causadas pelo teste reduzido no relatório de certificação. Durabilidade 34 - Todas as peças mecânicas deverão ser construídas com materiais que evitem a degradação de qualquer componente ao longo de sua vida útil estimada. 35 - A entidade certificadora habilitada poderá recomendar um cronograma de substituição mais rigoroso do que o sugerido pelo fabricante do dispositivo, e sua inspeção periódica para garantir sua integridade. Manipulação/Adulteração 36 - Os apostadores e atendentes de jogo não deverão manipular ou influenciar os dispositivos físicos de aleatoriedade fisicamente em relação à geração de dados de resultado do jogo, exceto se for projetado pela arquitetura do jogo, como no caso de um atendente de jogo pressionar um botão para parar uma roleta, ou se permitirem que um apostador faça isso. ANEXO IV DOS REQUISITOS GERAIS 1. Este anexo contém procedimentos e práticas relacionados às operações de apostas que serão verificadas pelas entidades certificadoras habilitadas pela Secretaria de Prêmios e Apostas do Ministério da Fazenda, nos termos do art. 8º desta Portaria, como parte da avaliação do sistema de apostas, da plataforma de apostas esportivas e da plataforma de jogos on-line. Da operação e segurança do sistema Procedimentos do sistema 2 - O operador será responsável por documentar, armazenar e seguir os procedimentos relevantes do sistema de apostas, da plataforma de apostas esportivas e da plataforma de jogos on-line, procedimento que deverá incluir, no mínimo, as seguintes exigências: a) procedimentos de monitoramento dos componentes críticos e da transmissão de dados de todo o sistema, incluindo comunicação, pacotes de dados, redes, bem como os componentes e transmissões de dados de quaisquer serviços de terceiros envolvidos, com o objetivo de garantir a integridade, a confiabilidade e a acessibilidade do sistema; b) procedimentos e padrões de segurança para a manutenção de todos os aspectos de segurança do sistema para garantir comunicações seguras e confiáveis, incluindo proteção contra hackers e adulteração; c) procedimentos para definir, monitorar, documentar, investigar, relatar, responder e resolver incidentes de segurança e adulterações do sistema, incluindo violações detectadas e invasões suspeitas ou reais; d) procedimento de monitoramento e ajuste do consumo de recursos, mantendo um registro do desempenho do sistema, incluindo uma função para compilar relatórios de desempenho; e e) procedimentos para investigar, documentar e resolver problemas de funcionamento, que abordem: I. determinação da causa do mau funcionamento; II. análise de registros, relatórios e registros de vigilância relevantes; III. reparo ou substituição do componente crítico; IV. verificação da integridade do componente crítico antes de restaurá-lo para operação; V. produção de relatório de incidente para a Secretaria de Prêmios e Apostas do Ministério da Fazenda, e que documente a data, hora e motivo do mau funcionamento, juntamente com a data e a hora em que o sistema foi restaurado; e VI. anulação ou cancelamento de apostas e pagamentos se uma recuperação completa não for possível. Localização física dos servidores 3 - Os servidores do sistema de apostas devem estar alojados de forma segura em um ou mais locais, atendendo minimamente às seguintes exigências: a) ter proteção suficiente contra alteração, adulteração ou acesso não autorizado; b) estar equipada com um sistema de vigilância; c) ser protegido por perímetros de segurança e por controles de entrada apropriados para garantir que o acesso seja restrito somente a pessoas autorizadas e que quaisquer acessos e tentativas de acesso físico sejam registradas em um log seguro; e d) estar equipado com controles para fornecer proteção física contra danos causados por incêndios, inundações, furacões, terremotos e outras formas de desastres naturais ou causados pelo homem. Controle de acesso lógico 4 - O sistema de apostas deve ser logicamente protegido contra acesso não autorizado por credenciais de autenticação, como senhas, autenticação multifatorial, certificados digitais, PINs, biometria e outros métodos de acesso, observando os seguintes requisitos: a) cada funcionário do operador deve ter sua própria credencial de autenticação individual, cuja concessão deve ser controlada por meio de um processo formal; b) os registros de credenciais de autenticação devem ser mantidos por sistemas que registram automaticamente as alterações de autenticação e forçam as alterações nas credenciais de autenticação; c) o armazenamento de credenciais de autenticação deve ser seguro; se alguma credencial de autenticação for codificada em um componente do sistema, ela deverá ser criptografada; d) um método de fallback para falha na autenticação, como senhas esquecidas, deve ser pelo menos tão forte quanto o método principal; e) credenciais de autenticação perdidas ou comprometidas e credenciais de autenticação de usuários cancelados devem ser imediatamente desativadas, protegidas ou destruídas; f) o sistema deve ter vários níveis de acesso de segurança para controlar e restringir diferentes classes de acesso ao servidor, incluindo a visualização, alteração ou exclusão de arquivos e diretórios críticos. Deverá haver procedimentos em vigor para atribuir, revisar, modificar e remover direitos e privilégios de acesso para cada usuário, incluindo: I. permissão para administração de contas de usuário, para adequada separação de tarefas; II. limitação dos usuários que possuam as permissões necessárias para ajustar os parâmetros críticos do sistema; e III. aplicação de parâmetros de credenciais de autenticação adequados, como duração mínima e intervalos de expiração; g) deverá haver procedimentos em vigor para identificar e sinalizar contas suspeitas onde credenciais de autenticação possam ter sido roubadas ou fraudadas; h) quaisquer tentativas de acesso lógico às aplicações do sistema ou sistemas operacionais devem ser registradas em um arquivo log seguro; i) o uso de programas utilitários que possam anular os controles do aplicativo ou do sistema operacional deve ser restrito e rigidamente controlado; e j) quando as senhas forem usadas como uma credencial de autenticação, é recomendável que sejam alteradas, pelo menos, uma vez a cada 90 dias, tenham pelo menos 8 (oito) caracteres e contenham uma combinação dos seguintes critérios: letras maiúsculas e minúsculas, caracteres numéricos e/ou especiais.