Utilize o mysqldump para realizar backup de seus bancos. [Leia mais]

Apesar de o SQL Server não possuir objetos do tipo seqüência, os programas Progress 4GL / ABL conseguem utilizá-las. Na prática, o DataServer as está emulando. Veja como isto funciona. [Leia mais]

Veja como é possível utilizar as stored-procedures do Oracle em programas desenvolvidos em Progress 4GL [Leia mais]

Como o after-image pode ajudar na continuidade do ambiente. [Leia mais]

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. 

No post anterior criamos os usuários, definimos os administradores, restringimos o acesso anônimo e concedemos algumas permissões para tabelas e campos. Hoje veremos que apenas esse trabalho não é suficiente para evitar que usuários desempenhem atividades não autorizadas no banco.  Quando um programa Progress é compilado, ou seja, sua sintaxe é validada e um código intermediário (r-code) é gerado para posterior execução, apenas é validada a permissão do usuário que está compilando este programa. Se este usuário possuir as permissões de acesso às tabelas necessárias por este programa, o respectivo r-code (arquivo .r) é gerado. Isto é conhecido como validação de permissões em tempo de compilação. Depois de gerado, este r-code poderá ser executado por qualquer usuário, independente deste possuir ou não as permissões necessárias nas tabelas que o programa acessa. Se isso não for levado em consideração, de nada adianta proteger seu banco. Até a versão 9 do Progress, cabia apenas às aplicações o controle de qual usuário pode executar determinado programa. Já apartir da versão 10.1A existe uma forma de forçar o banco a validar esta permissão também em tempo de execução, utilizando para isso o usuário que está conectado naquele momento ao banco de dados. Para habilitar tal opção, acesse a ferramenta Data Administrator, menu Admin, Database Options, conforme a figura a seguir: Sem essa opção habilitada, nosso trabalho de restringir o acesso é válido apenas para execução de programas fontes ou consulta direta realizada via editor do Progress.  Outra boa prática de segurança é impedir que r-codes não autorizados sejam executados no banco de dados. Isto é possível através de uma assinatura que é atribuída ao banco de dados. Toda vez que um programa compilado for executado, este r-code deverá possuir também esta assinatura. Caso não possua, ocorrerá um erro de CRC, impedindo que este programa seja executado. Isso impede que qualquer usuário compile um programa em uma base semelhante a nossa, porém aberta, e consiga executar este programa em nossa base fechada, sobrepondo assim toda a definição de segurança que tenhamos configurado. Essa opção é bastante útil em ambientes aonde não é possível habilitar validação em tempo de execução (versões de Progress anteriores a 10.1A) ou sistemas nos quais seja difícil mapear quais são as permissões necessárias para cada usuário no sistema. Entretanto, ela não substitui a validação em tempo de execução, considerando que um usuário poderá a qualquer momento acessar uma estação que possua licença que permita consulta direta via editor do Progress (sem r-codes). Para atribuir uma assinatura ao banco de dados, utilize o comando proutil <nomeDoBanco> -C dbauthkey + <assinatura>.Para atribuir essa mesma assinatura para o programa compilado, utilize o comando proutil <nomeDoBanco> -C rcodekey + <assinatura> <nomeDoPrograma.r>. Por exemplo: proutil ems2cad -C dbauthkey + cristoRedentorproutil ems2cad -C rcodekey + cristoRedentor mostraCustomer.r Programas que são compilados conectados em bases com assinatura definida já receberão a assinatura do banco. Apenas será necessário atribuir assinatura utilizando o proutil... rcodekey... em r-codes compilados em outras bases.  Mais detalhes sobre a utilização destes comandos, consultar a documentação do Progress, disponível no endereço http://www.progress.com/. Cuidar para não utilizar uma chave muito fácil de ser descoberta. A assinatura que utilizei acima não é um bom exemplo, serve apenas para ilustrar.Tomar o cuidado também de não deixar esta assinatura dentro de algum script e principalmente, cuidar para não esquecer esta chave, já que não há uma forma de recuperar esta informação do banco. A Datasul desenvolveu uma ferramenta que automatiza as tarefas de aplicar assinatura em bancos e programas, bem como atribuir algumas permissões em tabelas de bancos de dados Progress, chamada DASPPE. Esta ferramenta é gratuíta e pode ser baixada do portal de clientes Datasul, através do endereço www.datasul.com.br/portal, opções central de downloads, arquivos de apoio, idioma, produto, versão, ferramentas, dasppe.zip. Esta ferramenta não possui suporte e é atendida apenas via consultoria telefônica, disponível pelo telefone (47) 2101-7444, opção 2, tecnologia. No próximo post desta série veremos alguns detalhes sobre permissões de acesso a banco Progress através de conexões ODBC/JDBC, utilizando a conexão do tipo SQL, que vimos no primeiro post.

No post anterior iniciamos a tarefa de restringir o acesso 4GL em bases de dados Progress. Criamos alguns usuários e definimos o papel de administrador para o usuário "adm". Agora realmente iremos restringir o acesso ao banco de dados. Primeiro vamos proibir o acesso anônimo, aquele no qual qualquer usuário pode acessar as informações do banco mesmo sem informar seu usuário e senha. Para isso utilizamos a ferramenta "Data Administration" e selecionamos a opção "Disallow Blank Userid Access", conforme a figura a seguir:    Impedir que usuários anônimos conectem um banco Progress é impossível, porém desabilitando o seu acesso, estes usuários não conseguirão mais acessar as informações contidas no banco de dados. Continuarão a se conectar, porém não conseguirão fazer nada neste banco. Uma simples consulta no conteúdo de uma tabela produzirá o seguinte erro: ** Insufficient access privilege for table <table name>. (234)  Agora vamos definir o que cada usuário autenticado no banco poderá fazer. Para isso, vamos acessar a opção "Edit Data Security" via ferramenta "Data Administrator", conforme a figura a seguir: Observe as permissões concedidas para a tabela "customer". De acordo com o que especificamos nesta tela, apenas os usuários "adm" e "joao" poderão incluir, alterar e excluir registros nesta tabela. Observe que em todas as permissões aparece o símbolo de negação na primeira posição, isto porque definimos que nenhum usuário anônimo poderá acessar as informações do banco.   Concedemos também permissão de leitura na tabela "customer" para o usuário "maria". Esse usuário apenas poderá consultar dados nesta tabela, sem incluir, alterar ou excluir.   Podemos ainda definir permissões específicas para cada campo das tabelas. Isso é possível, nesta mesma tela, selecionando a opção "Permissions for Selected Field", conforme a figura a seguir:      Em nosso exemplo, definimos que apenas os usuários "adm" e "joao" conseguirão ler e alterar o conteúdo do campo "Credit-Limit" da tabela "customer". O usuário "maria" continuará conseguindo consultar os demais campos desta tabela exceto este. Caso ela tente consultar ou alterar este campo, receberá o seguinte erro:   ** Insufficient access privilege for Field Credit-Limit. (233)    Nos próximos posts conheceremos algumas situações que podem deixar uma base de dados Progress vulnerável e como evitá-las.

No post anterior conhecemos as duas formas de acesso que as bases de dados Progress suportam, que são as conexões 4GL e SQL. Vimos também algumas diferenças relacionadas a controle de acessos, comparando com bancos Oracle e SQL Server. Neste post vamos aprofundar na forma de acesso 4GL, que é utilizada pela grande maioria dos produtos Datasul atualmente em comercialização. As bases de dados Progress, quando criadas, já possibilitam acesso irrestrito ao seu conteúdo. Qualquer conexão 4GL realizada nestes bancos será capaz de criar novas tabelas, excluir tabelas já existentes, assim como realizar qualquer outra atividade neste banco, como ler, alterar e excluir registros, índices, seqüências, etc. Para começar a controlar este acesso, será necessário criar os usuários que terão direito a conectar este banco. Estes usuários poderão ser criados através da ferramenta “Data Administration”, conforme a imagem a seguir:   Após a criação dos usuários, será necessário configurar qual será o papel de cada um deles. Vamos conceder o privilégio de Administrador para o usuário “adm” neste nosso exemplo. Para isso, vamos acessar a opção “Security Administrators...” deste mesmo menu, apresentando a tela a seguir:     É possível utilizar caracteres “coringas” para atribuir permissões aos bancos Progress. Por exemplo, o caractere “*” permite que tal atribuição seja aplicada a todos os usuários. A combinação “abc*” permitirá que a atribuição seja aplicada a todos os usuários que iniciem com as letras “abc”. Isso permitirá, por exemplo, separar as permissões por áreas afins, desde que seja utilizada uma nomenclatura padrão para os nomes dos usuários. Por exemplo, para os usuários da área financeira, utilizar “fin” no início do código dos usuários. Para a área de logística, utilizar “log”, e assim por diante. Quando for aplicar as permissões, será possível utilizar a combinação “fin*” para conceder acesso a todos os usuários da área financeira. Infelizmente o Progress não possui o conceito de grupos de usuários ou regras (roles), como praticado por outros bancos de dados. Para negar o acesso deverá ser utilizado o caractere “!”. De acordo com o nosso exemplo, a combinação “!fin” evita que usuários da área financeira tenham determinada autorização. Mesmo criando os usuários e concedendo o poder de administração para apenas alguns destes, isso não garante que nosso banco esteja protegido. Conexões anônimas continuarão sendo permitidas e acesso a qualquer tabela do banco de dados. A criação de um usuário administrador e a sua atribuição a esta autoridade apenas restringe algumas ações dentro do banco de dados, como criação de novos usuários, por exemplo. No próximo post veremos como restringir o acesso anônimo ao banco, ou seja, aquele acesso sem que o usuário informe suas credenciais, bem como mostrarei como configurar permissões para as tabelas do banco.