Este é um post inspirada no post do Insano Mundo de Jack que é um complemento do post no br-net.org que é uma tradução do post do Geeks are Sexy.

DBA’s são pessoas que trabalham entre os desenvolvedores (locais ou externos) e os adminstradores de sistema. Na minha curta experiência, os DBA’s costumam estabelecer relações mais amistosas com os Administradores de Sistema (que são poucos) e ter atritos com os desenvolvedores (que são muitos).

Então, aqui vão algumas dicas para o desenvolvedor (e em alguns casos usuários também) manterem uma relação produtiva com o seu DBA:

1. Se a sua aplicação parou de funcionar de repente, isto não significa que o banco de dados está fora do ar. A rede costuma ser o problema número um. Verifique se a rede está funcionando normalmente antes de por a culpa no banco de dados;
2. Entenda que o fato de uma aplicação ter desempenho adequado nos testes ou nos primeiros meses de produção, não significa que ela terá desempenho bom sempre. Os problemas de desempenho crescem geometricamente a partir de um certo volume de dados;
3. Por mais que você se considere um mestre em modelagem de dados, discuta o modelo com o seu DBA antes de sair implementando ele. O modelo de dados lógico nunca é igual ao modelo físico implementado pelo DBA;
4. Antes de sair desnormalizando o seu modelo de dados, tente seguir as formas normais e discuta os casos em que você acha conveniente fugir do modelo relacional com o seu DBA. Muitas veses isto não é vantajoso ou pode ser feito de forma transparente para a aplicação, ou só é vantajoso em alguns SGDBs.
5. DBAs não gostam de mudanças rápidas. Eles são resistentes a mudanças por natureza. Isto tem haver com a função deles. Linguagens de programação vem e vão e muitas vezes os bancos de dados continuam o mesmo. Veja que apesar dos modismos, a teoria relacional de bancos de dados continua firme há mais de 20 anos;
6. Nunca peça para realizar alterações no modelo de dados com pressa. Uma simples mudança de um campo em uma única tabela pode demandar semanas de planejamento cuidadoso. Se você apressar seu DBA para realizar as alterações, descobrirá que um erro cometido pelo DBA pode acarretar prejuízos incalculáveis para uma empresa.
7. Nunca, repito NUNCA solicite alteração em dados diretamente no ambiente de produção. Por favor, não insista!
8. Não peça permissões no ambiente de produção se você não está preparado para se responsabilizar pela perda daquelas informações.
9. Por mais que você seja um programador habilidoso, entenda que há operações que rodam de forma mais eficiente dentro do banco de dados. Aprenda a utilizar as linguagens procedurais do banco de dados e aprenda a utilizar subconsultas. É melhor perguntar para o seu DBA se você não souber, do que tentar resolver o problema sozinho.
10. Entenda que orientação a objetos pode ser a palavra de órdem entre as linguagens de programação, mas em materia de banco de dados suportando aplicações transacionais, isto não funciona, por mais que alguns vendedores tentem lhe convencer o contrário. Por mais que isto lhe pareça atraente, os SGDBs orientados a objeto não conseguiram provar sua robustez em ambientes de produção.
11. Não, diagramas UML não substituem as documentações clássicas utilizadas em banco de dados como o diagrama entidade relacionamento e dicionários de dados.
12. Veja seu DBA também como um desenvolvedor e não apenas como um administrador de sistemas. Ele é uma peça fundamental na homologação dos sistemas, mas se estiver presente no começo do projeto, muito tempo poderá ser economizado, a não ser que você tenha um Administrador de Dados realmente experiente na equipe.

Este é um tema bastante polêmico, já tive algumas discussões acaloradas em listas de discussão (bom, o nome já diz que é para discutir, não é? ) onde até hoje muitos defendem uma opinião contraria a minha. Mas é um tema que me incomoda e estou longe de chegar a uma resposta conclusiva, portanto todos os comentários, pedras e sugestões são bem vindos.

Eu confesso que nos meus primeiros sistemas eu fiquei tentado a fazer isso:

Para cada usuário da aplicação, criar um usuário no banco de dados com o comando CREATE USER (ou com o comando CREATE ROLE).

Assim, a aplicação ficaria muito mais simples, eu não precisaria ficar me preocupando com criptografia de senhas e toda uma estrutura adicional que seria necessária se todos os usuários da aplicação se conectassem com o mesmo usuário no banco de dados.

A parte de auditoria também seria uma maravilha! Eu posso olhar qual usuário está conectado no Banco de Dados e guardar isso numa tabela de forma simples e confiável. Sempre saberei quem se conectou no banco de dados!

Logo percebi que meus dotes de desenvolvedor não são tão bons assim e passei a trabalhar mais de perto com bancos de dados. E aí fui percebendo os problemas deste tipo de sistema de autenticação de aplicações em bancos de dados. Não posso dizer que me tornei um conhecedor do assunto, mas sofri com diversas aplicações.

Me parece que as aplicações Cliente/Servidor tem um hábito grande de utilizar este tipo de esquema, embora eu já tenha visto isso em aplicações Web também. Já vi esquemas mais elaborados que tentam de uma forma ou outra contornar os problemas que eu vou citar a seguir, mas de qualquer forma, me parece que a decisão tomada no começo do desenvolvimento da aplicação sobre este assunto torna tudo mais complicado depois, embora eu já tenha (depois de muita briga) feito com que um fornecedor tenha alterado completamente o seu esquema de autenticação da aplicação.

As desvantagens

1) Segurança contra conexão através de clientes diferentes da aplicação.

Imagine que o seu usuário utilize uma conexão através de ODBC ou JDBC a partir de uma suite de escritório que já deve estar instalada na máquina dele. Isto não leva mais do que 2 minutos e o banco de dados vira um livro aberto para o usuário!!!

É claro que você pode (e deve) restringir com GRANTs e REVOKEs o acesso a cada usuário e utilizar ROLEs para cada perfil. No entanto, veja, se você tem um GRANT como DELETE numa tabela, o usuário poderá apagar todos registros da tabela. Com um GRANT UPDATE o usuário pode alterar todos os dados. Seria melhor que o usuário só se conectasse pela aplicação, onde o desenvolvedor controla mais rigorosamente o acesso aos dados.

2) Quem cria os usuários e altera as suas senhas?

Com uma dúzia des usuários tudo corre bem. Com centenas de usuários, o trabalho do DBA começa a ficar sobrecarregado. Um agravante peculiar é o momento de colocar a senha do usuário. O DBA deverá estar presente ao lado do usuário, o que pode ser incômodo para eles. O usuário pode estar longe ou trabalhar em outro horário. Se isto acontecer, começaram a transmitir senhas por e-mail ou telefone, ou ainda pior… utilizar senhas padronizadas. Alguns podem achar isso um absurdo, mas eu já vi acontecer isso várias veses.

Você pode delegar o poder de criar usuários a aplicação, mas não conheço muitos DBAs que gostem da idéia de uma aplicação que pode criar usuários no banco por aí. Não é seguro e geralmente isso é feito concedendo superpoderes no banco de dados para a aplicação. Isto significa que o DBA perde totalmente o controle sobre o banco de dados. Veja bem, se existem funções distintas para o desenvolvedor e o DBA, é porque ambos devem ter atribuições distintas. Criar usuários no banco de dados ou alterar suas senhas, não deve ser nunca uma atribuição do desenvolvedor, pelo menos na base de produção. É só pensar no que vai acontecer no dia em que for descoberto um problema grave no banco de dados… de quem será a responsabilidade?

3) Quem apaga ou inativa os usuários?

Apesar de muito semelhante ao ítem anterior, há uma pequena diferença sobre quando isto ocorre. Usuários entram em férias, saem da empresa e quem é que lembra de avisar para desativar ou apagar o seu usuário? Quantas vezes não ligam para o DBA desesperados para trocar a senha de um usuário importante que saiu de férias e só ele tinha a senha para resolver um problema urgente? E os usuários que são demitidos, costumam não ficar muito felizes nesta época. Eles podem deixar a sua senha para um colega ou coisa pior. Veja que momento oportuno para boa fraude no sistema.

4) Administrar um banco de dados com muitos usuário é bem mais trabalhoso

Pode parecer uma besteira, mas lidar com um banco de dados com centenas de usuários criados, pode ser um verdadeiro pesadelo. Além de ter de criar os usuários e ficar alterando suas senhas com frequência, muita confusão pode acontecer quando você realiza rotinas mais delicadas com migração de dados. Se você acha que isto nunca ocorre, imagine algumas situações:

• Migração para um novo servidor;
• Migração de versão SGDB;
• Migração da base de produção para a base de teste ou homologação.

Estas operações são sempre demoradas e propensas a erros. Quando muitos usuários existem criados no banco de dados, os erros se multiplicam. Erros em GRANTs, senhas que mudam, importação e exportação de objetos para cada usuário. É uma boa prática exportar e importar objetos por usuário e não todos num único arquivo, e com muitos usuários criados no banco isto pode se tornar bastante trabalhoso, ainda mais se a aplicação criar novos objetos para cada usuário (não estranhem não, eu também já vi isso e em larga escala)

5) Redundância de informação

Não demora muito para perceber que somente com GRANTs e REVOKEs não é possível controlar bem o acesso na aplicação. Você vai querer :

• Controlar o acesso a telas específicas do sistema que envolvem várias tabelas diferentes.
• Que o usuário tenha acesso a funções específicas na sua tela que não se enquadram nas especificadas pelos GRANTs e REVOKEs.
• Que os usuários tenham acesso a apenas uma faixa de valores de uma tabela ou mais tabelas.

Todas estas situações exigem que você crie uma estrutura de tabelas para administrar estas permissões. Se você pensava em ter menos trabalho autenticando usuários direto no banco de dados, logo você vai perceber que é bem capaz de você ter mais trabalho ainda.

Alternativas

Tabelas de usuários, senhas e permissões por aplicação

Uma alternativa comum é criar logo algumas tabelas com os nomes de usuários e colunas para senha e telas e operações das quais o usuário poderá ter acesso. A estrutura poderá ser um pouco mais complexa, com o uso de grupos, tempo de validade de sessão, data de desativação automática de senha e outras funcionalidades interessantes que você pode e deve criar.

A aplicação se conectará ao banco de dados com um único usuário que terá todas as permissões necessárias para realizar as operações normais da aplicação. Isto significa que o usuário da aplicação não deve ser o OWNER dos objetos da aplicação e não deve ter GRANTs como DROP, CREATE, ALTER e TRUNCATE e situações normais.

Outro detalhe é que o usuário não deve ter acesso a senha da aplicação em momento algum, ao mesmo tempo que deva ser possível de trocar a senha periodicamente a partir de algum procedimento especial. No caso de aplicações que utiliza um servidor de aplicação, isto não apresenta nenhum problema. Já as aplicações cliente/servidor tradicionais terão que realizar operações um pouco mais criativas para lidar com isso, pois a senha deverá estar compilada junto com o código da aplicação.

Para contornar o problema da auditabilidade, você vai ter que utilizar um pouco mais de criatividade (muito menos do que você precisaria para resolver os problemas de segurança já citados). Você pode criar uma função no banco de dados e passar como parâmetro o nome do funcionário. Em alguns SGDBs a sua vida pode ser até mais simples, o ORACLE, por exemplo permitir a criação de TRRIGERs de sistema que são disparados quando um usuário se conecta. Além disso, você pode utilizar tabelas de histórico, logs do SGDB e outros recursos que variam um pouco conforme o fornecedor.

Autenticação externa via serviço de diretório

A maioria dos SGDBs possuem autenticação direta através de algum serviço de diretório como o AD ou LDAP. Isto permite uma autenticação centralizada para todas as suas aplicações com a mesma senha para todos os usuários. É sem dúvida uma solução ótima em termos de senhas, mas não elimina a necessidade de se criar os usuários no banco de dados.

É possível, com um pouco de trabalho adicional, implementar a sincronização a criação de usuários no diretório com a criação de usuários no banco de dados, mas pode ser algo um pouco menos trivial. De qualquer forma, todos os usuários nomeados da aplicação deverão existir no serviço de diretório. Isto significa também que o seu administrador de sistema será responsável por todas as senhas dos usuários.

Os usuários ficarão muito felizes em utilizar a mesma senha para várias operações diferentes. Algumas pessoas podem considerar isto um tanto estranho. Mas imagine que se você tiver um bom administrador de sistemas e um bom serviço de diretórios, você poderá ter muito mais controle sobre as senhas do que em outras situações.

Não confunda isso com a autenticação via sistema operacional (IDENT) que checa apenas se o nome do usuário do SO remoto é igual ao nome do usuário criado no banco de dados. A autenticação via IDENT é muito insegura pois permique que qualquer pessoa que consiga conectar um computador na rede (mesmo sem se autenticar no serviço de diretório) com um usuário no seu SO igual ao nome de um usuário da aplicação se autentique. Imagine por exemplo que você crie no seu computador um usuário com o nome ‘ADMIN’ e este seja o nome do usuário que administra a aplicação.

Conclusão

Eu realmente tenho uma solução milagrosa para todos os problemas citados. Sei que sempre existirão usuários especiais que poderão consultar dados diretamente no banco de dados. Para estes poucos casos (se não forem poucos, então deve haver algumas funcionalidades faltando na aplicação) basta criar algumas VIEWS e dar acesso limitado apenas a estes objetos para as suas contas criadas no banco de dados. Nada além disso.

Já vi esquemas mirabolantes para contornar os problemas citados nos itens 1, 2 e 3, mas nunca vi alguém contornar o ítem 4. Muito pelo contrário, quanto mais tentam contornar o problema da segurança, mais complicam a vida do DBA.

Acredito que a criação de alguns frameworks para autenticação possam ser soluções robustas, mas será difícil convencer diferentes fornecedores a adotarem uma mesma solução a curto prazo. É nestes momentos em que ficar refém de fonecedores de pacotes nos lembram da beleza do Software Livre!

Podem existir formas completamente diferentes de autenticação que não incorram em tantos problemas de segurança e administração. Como eu disse no começo, não sou um expert no assunto. Quero conhecer novas soluções. Mas até agora, a maioria delas parece se basear nos 3 tipos citados:

1) Criação de usuários normais direto no banco de dados.
2) Criação de usuário único da aplicação
3) Autenticação de usuários utilizando um serviço de diretório

Se você conhecer outras soluções ou discorda dos meus argumentos, por favor, me conte para eu melhorar este artigo e sugerir novas soluções para os desenvolvedores da aplicações que “sobrevivem” nos bancos de dados que eu administro!

Continuing my serie of interviews with PostgreSQL Developers, i have the pleasure to talk with Mr. Bruce Monjiam (in the FAQ of his blog, he tell us that the English pronunciation of Momjian is is MOM-jin). In the past, I talk with Josh Berkus and Euler Taveira (in portuguese, only).

Bruce Momjian is a co-founder of the PostgreSQL Global Development Group, and has worked on PostgreSQL since 1996. He is the author of PostgreSQL: Introduction and Concepts, published by Addison-Wesley. Bruce is employed by EnterpriseDB. Previously, he was employed by SRA Japan and Great Bridge LLC, both PostgreSQL support companies. He has spoken at many international open-source conferences. Prior to his involvement with PostgreSQL, Bruce worked as a consultant, developing custom database applications for some of the world’s largest law firms. Prior to this, he was a high school computer science teacher and holds a Masters in Education.

2 - When did You become a PostgreSQL developer?

Conheço muita gente que está acostumada a usar controle de versões, bug tracking e outras ferramentas importantes no desenvolviemnto de aplicações. Mas quando o assunto é banco de dados, poucos estão dispostos a investir em vários servidores de bancos de dados distintos. A situação ideal é ter

• Um servidor em produção
• Um servidor de homologação
• Um servodor de testes

Mas a questão é… para que investir num servidor de banco de dados de homologação?

Bom… a realidade é que o processo de desenvolvimento só adquire um estatus suficiente para entrar em produção, após a homologação, e este não pode ser feito no ambiente de testes. Vejamos as diferenças:

No servidor de testes, você pode iniciar o desenvolvimento de uma aplicação, a partir do zero, com dados completamente fictícios e pequenos volumes. Em geral, o servidor de testes costuma ter menor capacidade de armazenamento e processamento. O DBA costuma dar um pouco mais de liberdade para o desenvolvedor neste servidor. A principal preocupação aqui é com o modelo de dados. O trabalho do AD aqui é fundamental, sendo modelo lógico o principal alvo de alterações. É na base de testes que os testes de componente ocorrem.

No servidor de homologação, os desenvolvedores perdem os seus direitos e entra em ação o trabalho do DBA. Os dados da base de produção devem ser carregados na sua totalidade (se a aplicação já estiver em produção). A conversão do modelo de dados deve ser testada. Quando a aplicação for completamente nova… um bom gerador de dados é importante. Deve-se realizar uma carga com volume compatível com o esperado após alguns anos de operação. O servidor de homologação, precisa ter uma capacidade de armazenamento semelhante a do servidor de produção, além da capacidade de processamento. Mais que isso, é importante que a arquitetura física e lógica seja o mais semelhante possível ao do servidor de produção.

É no servidor de homologação que os testes da aplicação ocorrem. Os testes de desempenho vão permitir que um bom DBA faça ajustes na estrutura física de armazenamento e sugerir ajustes no SQL da aplicação. Muitas pessoas desprezam estes testes e depois de um par de anos.. descobre que a aplicação foi mal projetada e começa apresentar graves problemas. Consertar isso depois de dois anos é realmente muito difícil. A chance de você perder o cliente ou gastar muito dinheiro para resolver o problema é grande.

Uma boa opção para chamar os amigos para um almoço Geek em casa. Um prato apimentado que não sai caro e vai muito bem com cerveja. Sucesso garantido!

O “chili con carne” é um prato tipicamente mexicano, muito apreciado nos Estados Unidos. É barato de se fazer e era inicialmente apreciada por vaqueiros.

Ingredientes:
(para 4 geeks ou 6 pessoas normais)

• 250 gramas de feijão. Você pode escolher o feijão comum ou o preto, fica a seu critério, eu fiz com o comum;

• 600 gramas de carne. Pode ser coxão mole ou filet mignon em cubos bem pequenos ou com carne moída. Recomendo fazer em cubos com filet mignon, mas já comi com carne moída e não fica nada mal;
• 4 colheres de sopa de azeite de oliva;
• 1/2 colher de chá de cominho em pó;
• 1/2 colher de chá de páprica em pó. Não confunda com páprica doce;
• 1 colher de chá de tomilho;
• 3 dentes de alho;
• 1 cebola picada;
• 4 colheres de extrato de tomate ou 1 lata de molho de tomate pronto;
• Sal, orégano e/ou pimenta do reino a gosto;
• Pimenta!!!

Como pimenta, você pode misturar várias coisas como no “chili powder“. Pimentas comuns vão bem, como malagueta, dedo de moça e pimentão. De preferência misture um pouco de cada!!! Eu achei no supermercado uma bandeja de “pimentas ardidas” a R$ 2,00. Usei uma de cada, junto com uma malagueta! O ideal é usar pimentas frescas bem picadas, mas vi receitas utilizando pimenta em pó também. A quantidade deve variar um pouco com a sua valentia. Mas você verá que existem formas de contornar “um pouco” a situação no final.

Modo de preparo:
Deixe o feijão lavado por 12 horas de molho em água fria e depois cozinhe eles por uns 40 minutos. Se estiver com pressa, coloque logo numa panela de pressão (neste caso não precisa deixar o feijão de molho). O importante é tirar o feijão do fogo um pouco antes do ponto para ele cozinhar mais uns minutos junto com o chili.

Enquanto o feijão cozinha, refogue com azeite o cominho, tomilho, as pimentas e depois o alho e a cebola. Depois que a cebola dourar, coloque a carne e deixe ela cozinhar bem no meio do refogado. Junte o feijão, o molho de tomate e ponha sal a gosto.

Depois de mexer por uns minutos, experimente e veja como está. Se estiver muito forte, coloque cerveja pilsen para suavizar o gosto - e dar um sabor no chili também, claro! Eu coloquei uma lata de cerveja. Se você usar extrato de tomate, poderá variar entre água ou cerveja para diluir o extrato de tomate, quanto mais cerveja, menos ardido fica ou seu chili. Você terá de fazer isso a olho e aos poucos ir experimentando para ver como está.

Ao servir:
Sirva com arroz cerveja bem gelada e deixe bebidas por perto. A bebida não deixará a sua boca menos apimentada, dizem que ela apenas espalha a pimenta na boca. Se achar que poderá ter problemas, deixe miolo de pão por perto, que dizem que funciona melhor. Em todo caso… depois de secar a panela do chili, um sorvete de sobremesa tem um efeito que neutralizará totalmente o chili, mas em compensação… vai estragar o paladar para quem estiver tomando cerveja!

Bom, experimentem e depois me contem (não sobre os efeitos colaterais posteriores)