No post anterior verificamos a necessidade de controlar quais r-codes podem ser executados em um banco de dados Progress, uma vez que um programa Progress compilado pode ignorar a configuração de segurança que fizemos.
Precisamos também controlar o acesso SQL à este banco, realizado através de conexões ODBC ou JDBC. A abordagem de acesso SQL ao banco difere um pouco do acesso 4GL que vimos até agora. Para conexões SQL o banco não permite acesso anônimo. São dois usuários que por definição já possuem acesso SQL com permissões administrativas ao banco, são eles o usuário do sistema operacional que criou o banco e o usuário SYSPROGRESS.
Controlar a senha do usuário que criou o banco não é difícil, sendo que este usuário geralmente é o administrador do servidor que, por sua vez, já deverá possuir uma senha que poucos usuários tenham acesso. Já o usuário SYSPROGRESS deverá ser criado e deverá ter sua senha confiada à poucas pessoas. Não criar o usuário SYSPROGRESS permitirá que algum usuário não autorizado o crie a qualquer momento, recebendo assim os direitos administrativos neste banco.
Com o usuário SYSPROGRESS criado, é uma boa prática não divulgar esta senha para todos os usuários do banco, mas sim conceder permissões de acesso SQL necessárias à eles. Isso é possível através dos comandos GRANT e REVOKE, que permitem conceder e retirar permissões de usuários, respectivamente. Em nosso banco de dados de exemplo, utilizaremos os seguintes comandos para conceder permissões de leitura na tabela customer para o usuário "maria" e poder de criação, alteração, consulta e exclusão para o usuário "joao":
grant select on PUB.customer to maria;
grant select, insert, update, delete on PUB.customer to joao;
Mais detalhes sobre os comandos GRANT/REVOKE bem como particularidades do acesso SQL em bancos Progress podem ser obtidos na documentação do produto e em outros posts que serão publicados neste blog.
É importante saber que as permissões concedidas para o acesso 4GL não são válidas para o acesso SQL e vice-versa. Desta forma as permissões can-read, can-write, can-create e can-delete não tem validade para este tipo de conexões.
Para finalizar esta série de posts sobre segurança em bases de dados Progress, vale lembrar que de nada adianta proteger o banco com chaves de acesso, permissões 4GL e SQL se o acesso ao servidor não estiver protegido. Ali um usuário mal intencionado poderá roubar as informações deste banco através de um dump/load binário ou ainda destruí-lo.
Assinar feeds (RSS)