Recomendações de segurança
Este manual apresenta algumas recomendações de segurança para o uso do sistema.
Uso de HTTPS
Sempre que possível deve-se utilizar HTTPS tanto na comunicação entre os usuários e o Engine quanto na comunicação entre os Engines.
No acesso a servidores públicos
Recomenda-se que todos os Engines expostos publicamente para acesso via internet utilizem HTTPS. Essa prática garante que a comunicação entre os usuários e o Engine esteja protegida de leitura por terceiros caso seja interceptada.
O procedimento de configuração do HTTPS no Engine é descrito em detalhes no manual Configuração do HTTPS no Engine.
Na comunicação entre Engines
Um Engine pode se comunicar com outro Engine utilizando o protocolo IAP sobre HTTP. Por esse motivo recomenda-se também que a comunicação entre Engines seja feita utilizando HTTPS. Para isso é necessário que o Engine servidor de aplicativo tenha o HTTPS configurado e que o Engine servidor de borda referencie o servidor de aplicativo utilizando o endereço configurado com HTTPS.
Uso de criptografia
A utilização de criptografia para proteger os dados de acessos indevidos é uma prática comum no mercado. A comunicação utilizando HTTPS é um exemplo de uso mas a criptografia também pode ser utilizada em outros contextos.
Banco de dados criptografado
É recomendado que os dados contidos no banco de dados sejam protegidos por meio de alguma solução de criptografia de dados em repouso, impedindo que os dados do sistema possam ser lidos por usuários que eventualmente tenham acesso físico aos discos contendo os arquivos da base de dados.
Essa criptografia pode ser realizada diretamente pelo sistema controlador do disco, funcionalidade por padrão habilitada nos principais provedores de infraestrutura em nuvem, como Google GCP, Amazon AWS e Microsoft Azure, ou pelo próprio banco de dados, por meio da criptografia de dados transparente ( TDE). Para saber mais sobre a utilização de TDE nos SGBDs, consulte a documentação específica de cada banco de dados:
- Microsoft SQL Server.
- Oracle.
- PostgreSQL não oferece suporte a TDE nativamente mas existe uma versão proprietária que oferece esse suporte.
É importante que a solução de criptografia adotada seja transparente para todas as aplicações que se conectam ao SGBD, permitindo que possam ser utilizadas soluções de terceiros, como ferramentas de BI, na base de dados do sistema.
Conexões criptografadas com o banco de dados
Como regra geral de segurança é recomendado que o administrador habilite o uso de criptografia SSL na conexão entre o Engine e o banco de dados. O procedimento para habilitar a criptografia é específico para cada banco de dados e não requer alterações na instalação ou configuração do Engine.
Durante a configuração em ambientes de produção é recomendada a utilização de certificados digitais válidos emitidos por uma Autoridade Certificadora. Consulte o manual de banco de dados para mais informações sobre a ativação da criptografia na conexão entre o Engine e os bancos de dados.
Política de senhas
Recomenda-se que o administrador implemente uma política de utilização de senhas fortes na sua organização. Senhas fortes ajudam a manter a segurança do sistema ao combater ataques de força bruta do tipo ataque de dicionário.
Para cadastrar, consultar ou implantar uma regra de senha consulte o manual do processo Regras de formação e uso de senhas.
Atualizações de versão
Uma prática bastante recomendada para segurança de sistemas em geral é manter uma rotina de atualização de versão de todas as ferramentas de software utilizadas. Manter os softwares sempre atualizados permite que correções para falhas de segurança conhecidas sejam sempre aplicadas, reduzindo as chances de que essas falhas de segurança sejam exploradas para conseguir acesso indevido ao sistema.
É importante acompanhar os informes de liberação de versão e planejar o melhor momento para aplicação da atualização. Também é importante que a atualização seja aplicada antes em um ambiente separado da produção para validar que nenhum tipo de regressão ocorrerá com a nova versão.
Contas de usuário
As contas de usuário devem ser gerenciadas apenas por usuários administradores e preferencialmente seguindo um processo bem definido como solicitação por email com todos os dados da pessoa por exemplo. Deve-se selecionar os grupos aos quais o usuário pertence de modo que ele tenha apenas o mínimo de permissão necessária para realizar o seu trabalho.
Desativação de contas inativas
Por questão de segurança os usuários devem ter suas contas desativadas depois de um determinado período de inatividade. A reativação de uma conta também deve ser feita seguindo um processo bem definido.
Para consultar e auxiliar na desativação de contas inativas, utilize o relatório “Admin > Segurança > Grupos, papéis e usuários > Usuários inativos no período”.
Autorizadores externos
Quando um usuário é desligado da organização é tarefa do administrador garantir que o acesso do usuário seja revogado em todos os sistemas aos quais ele tinha acesso. Centralizar a gestão das contas de usuário facilita essa atividade em cenários com vários sistemas.
O Engine suporta a integração com serviços de provedores de identidade para autenticação externa de usuários utilizando o protocolo “OpenID Connect”.
Grupos e papéis
O administrador deve classificar os usuários do sistema em grupos e papéis, e deve realizar a parametrização das permissões em relação a esses grupos. Permissões não devem ser atribuídas diretamente a usuários específicos do sistema, esse é um cenário de exceção que deve ser evitado.
Para maiores detalhes consulte o manual sobre grupos e papeis.
Segregação de responsabilidades
Recomenda-se que seja implantada na organização a segregação clara de responsabilidades. Isso significa que nenhum usuário deve ser responsável por todas as etapas de um processo. Essa prática melhora a segurança diminuindo a possibilidade que o sistema seja utilizado de forma fraudulenta.
A segregação de responsabilidades pode ser implementada por meio da criação de grupos e papéis e da configuração cuidadosa das permissões desses grupos.