Resposta :
Resposta:
Na situação proposta, a área de banco de dados teria que criar dois perfis distintos e divulgá-los, respectivamente, para dois públicos distintos. No caso:
CREATE USER ‘jose'@'localhost' IDENTIFIED BY ‘senha123';
GRANT ALL ON db_operacoes.* TO ‘jose'@'localhost';
Essa instrução seria para a criação dos usuários "jose" dentro do servidor do banco de dados para acesso local, ou seja, somente dentro da Polícia Federal. Esse usuário terá todos os privilégios do banco "db_operacoes".
Após isso, basta monitorar todos os perfis que logaram por esse usuário, até encontrar o que causou o vazamento de informações das operações.
A mesma lógica será utilizada para os demais servidores da Polícia Federal:
CREATE USER ‘servidorPF'@'localhost' IDENTIFIED BY ‘senha321';
GRANT ALL ON db_operacoes.* TO ‘servidorPF'@'localhost';
Para os demais servidores, será enviado o usuário "servidorPF" e a senha "senha321". Esses outros não seriam monitorados.
Explicação:
Resposta:
Padrão de resposta esperado
Na situação proposta, a área de banco de dados teria que criar dois perfis distintos e divulgá-los, respectivamente, para dois públicos distintos. No caso:
CREATE USER ‘jose'@'localhost' IDENTIFIED BY ‘senha123';
GRANT ALL ON db_operacoes.* TO ‘jose'@'localhost';
Essa instrução seria para a criação dos usuários "jose" dentro do servidor do banco de dados para acesso local, ou seja, somente dentro da Polícia Federal. Esse usuário terá todos os privilégios do banco "db_operacoes".
Após isso, basta monitorar todos os perfis que logaram por esse usuário, até encontrar o que causou o vazamento de informações das operações.
A mesma lógica será utilizada para os demais servidores da Polícia Federal:
CREATE USER ‘servidorPF'@'localhost' IDENTIFIED BY ‘senha321';
GRANT ALL ON db_operacoes.* TO ‘servidorPF'@'localhost';
Para os demais servidores, será enviado o usuário "servidorPF" e a senha "senha321". Esses outros não seriam monitorados.
Explicação: