02/04/12 Segurança Total em um Banco de Dados PostgreSQL
1/15www.ibm.com/developerworks/br/opensource/library/os-postgresecurity/
Conecte-se (ou Registrar)Português (Brasil)
Itens Técnicos Downloads e Trials Comunidade
Segurança Total em um Banco de Dados PostgreSQLDisponibilidade para o primeiro ataque
Robert Bernier, PostgreSQL Business Intelligence Analyst, Medio Systems
Resumo: A segurança de banco de dados é a maior preocupação com os aplicativos baseados na Web de hoje. Sem controle, você arrisca expor informações sensíveis
sobre sua empresa ou, pior ainda, sobre seus valiosos clientes. Neste artigo, aprenda sobre medidas de segurança que você pode tomar para proteger seu banco de dados
PostgreSQL.
Data: 16/Dez/2009
Nível: Intermediário Atividade: 6933 visualizações
Comentários: 0 (Visualizar | Incluir comentário - Conectar)
Média de classificação (8 votos)
Classificar este artigo
Introdução
Existem muitas histórias na imprensa sobre crackers acessando bancos de dados corporativos. Foram-se os dias quando adolescentes eram os autores da maioria dos ataquesa dados. Hoje, a colheita de dados é um grande negócio e é realizado por especialistas dedicados que trabalham dentro de uma infraestrutura corporativa. Não é uma questão
de como você pode evitar a tentativa de acesso não-autorizada — você não pode — mas, em vez disso, como você pode reduzir o efeito quando ele ocorrer.
Definições
Hacker — Um hacker explora, investiga e descobre por meio do entendimento da tecnologia em um nível raramente duplicado em circunstâncias normais. Ser chamado de
hacker por seus colegas é uma medalha de honra não porque você faz alguma coisa ruim, mas porque seu conhecimento não tem paralelo.
Cracker — Um hacker com má intenção, como vandalismo, fraude em cartão de crédito, roubo de identidade, pirataria ou outros tipos de atividade ilegal.
Este artigo explora os desafios de proteger seu servidor de banco de dados PostgreSQL (também conhecido como Postgres). O PostgreSQL é um poderoso sistema de banco
de dados relacional de objeto de software livre. Ele tem uma arquitetura comprovada com reputação para confiabilidade, integridade de dados e correção. Ele executa emtodos os principais sistemas operacionais, incluindo Linux®, UNIX®, e Windows®. Ele é completamente compatível com o ACID, e tem suporte completo para chaves
estrangeiras, junções, visualizações, acionadores e procedimentos armazenados (em vários idiomas).
Certifique-se de fazer o download das listas de código de amostra usadas neste artigo.
O administrador ideal
Na grande tradição do UNIX, o PostgreSQL foi projetado desde a base para complementar o S.O. no qual se sustenta. Otimizar o PostgreSQL para seu potencial máximorequer conhecimento além da demanda tipicamente esperada do administrador de banco de dados médio (DBA - average database administrator).
Resumidamente, o DBA de PostgreSQL ideal tem o seguinte conhecimento:
Conhecedor da teoria relacional e familiarizado com o SQL 92, 99 e 2003, respectivamente.
Conhece como ler código de origem, preferencialmente C, e pode compilar código de origem no Linux.
Pode administrar sistema e se sente confortável com o system-V UNIX ou Linux.
Pode manter, se necessário, os vários itens de hardware tipicamente encontrados em uma loja de TI. Entende a camada TCP OS, pode criar uma subrede em uma rede,
ajustar firewalls, etc.
Muitos DBAs possuem somente as habilidades para administrar, monitorar e ajustar o próprio banco de dados. Porém, o PostgreSQL é integrado para também contar com os
utilitários do S.O. É raro um DBA que domine todas essas disciplinas, mas ter esse conhecimento possibilita ao DBA do PostgreSQL realizar mais em menos tempo do que
seria possível de outra forma.
Revisão dos privilégios de acesso
Conhecer o que uma função de banco de dados faz é fundamental se você irá apreciar possíveis vetores de ataque. Primeiro, você precisa controlar o acesso aos dados
concedendo e revogando permissões.
Funções, e concessão de direitos e privilégios
O quão segura é uma função comum com direitos e privilégios padrão? A conta do usuário pode ser criada com um dos seguintes comandos:
A instrução SQL CREATE USER
A instrução SQL CREATE ROLE
O utilitário de linha de comandos Postgres createuser
Esses três métodos de criação de contas de usuário se comportam de maneira diferente, e resultam em direitos e privilégios padrão drasticamente diferentes.
Para uma função comum, o usuário típico pode:
02/04/12 Segurança Total em um Banco de Dados PostgreSQL
2/15www.ibm.com/developerworks/br/opensource/library/os-postgresecurity/
Acessar qualquer banco de dados se o cluster de dados usar a política de autenticação padrão conforme descrito em pg_hba.conf.
Criar objetos no esquema PUBLIC de qualquer banco de dados que o usuário puder acessar.
Criar objetos de sessão (temporários) em sessões temporárias, como schema pg_temp_?Alterar parâmetros de tempo de execução.
Criar funções definidas pelo usuário.
Executar funções definidas pelo usuário criadas por outros usuários no esquema PUBLIC (desde que eles interajam somente com objetos aos quais o usuário obteve
privilégios concedidos para acessar).
É importante saber o que o usuário tem permissão para fazer, mas é igualmente importante entender as atividades que o usuário comum não pode fazer por padrão. Usuários
comuns não podem:
Criar um banco de dados ou um esquema.
Criar outros usuários.
Acessar objetos criados por outros usuários.Efetuar login (aplica-se somente à instrução CREATE ROLE).
Direitos e privilégios de superusuários
Apesar de um usuário comum não poder executar os direitos e privilégios definidos como recursos de superusuário, o usuário comum ainda pode causar um pouco desofrimento com direitos e privilégios padrão.
Esta seção discute os vetores de ataque que o usuário comum pode manipular.
Acessando objetos
Uma prática extremamente comum e insegura ocorre quando o PostgreSQL é usado como o back end para um servidor da Web. O desenvolvedor cria o usuário comumdesejando somente realizar aqueles comandos que manipulam os dados usando os comandos INSERT, UPDATE, e DELETE. Porém, ações não autorizadas são possíveis porque
o esquema PUBLIC é aberto a todos. O usuário pode, por exemplo, fazer mineração de dados nessas tabelas. É até mesmo possível modificá-los incluindo regras eacionadores, salvando dados em tabelas localizadas no esquema PUBLIC, que podem então ser colhidos.
Lembre-se, uma conta de usuário comprometida pode fazer qualquer coisa que deseje aos objetos que possui.
Contornar esta ameaça é fácil: não deixe que a conta de usuário comum possua ou crie nada. A Lista 1 mostra como assegurar uma tabela.
Lista 1. Assegurando uma tabela
postgres=# SET SESSION AUTHORIZATION postgres;SETpostgres=# CREATE ROLE user1 WITH LOGIN UNENCRYPTED PASSWORD '123';CREATE ROLEpostgres=# CREATE SCHEMA user1 CREATE TABLE t1(i int);CREATE SCHEMApostgres=# INSERT INTO user1.t1 VALUES(1);INSERT 0 1postgres=# GRANT USAGE ON SCHEMA user1 TO user1;GRANTpostgres=# SELECT I FROM user1.t1; i--- 2(1 row)
postgres=# SET SESSION AUTHORIZATION user1;SETpostgres=> SELECT I FROM user1.t1;ERROR: permission denied for relation t1postgres=> SET SESSION AUTHORIZATION postgres;SETpostgres=# GRANT SELECT ON user1.t1 TO user1;GRANTpostgres=# SET SESSION AUTHORIZATION user1;SETpostgres=> SELECT I FROM user1.t1; i--- 2(1 row)
A Lista 2 demonstra interdição de acesso ao esquema PUBLIC.
Lista 2. Evitando que o user1 da função crie quaisquer entidades
postgres=> SET SESSION AUTHORIZATION postgres;SETpostgres=# REVOKE ALL PRIVILEGES ON SCHEMA PUBLIC FROM user1;REVOKEpostgres=# SET SESSION AUTHORIZATION user1;SET
A mensagem de erro "ERRO: permissão negada para user1 do esquema" significa que esta medida defensiva funciona:
02/04/12 Segurança Total em um Banco de Dados PostgreSQL
3/15www.ibm.com/developerworks/br/opensource/library/os-postgresecurity/
postgres=> CREATE TABLE X();ERROR: permission denied for schema user1
Acessando objetos sob o controle de outros usuários
Este vetor de ataque, mostrado na Lista 3 abaixo, assume que o usuário tem acesso ao esquema PUBLIC; por exemplo, GRANT USAGE ON SCHEMA PUBLIC TO user1. Elefunciona sob as seguintes suposições:
Todos os usuários tem, por padrão, permissão para se conectar a qualquer banco de dados no cluster.Clusters de postura permitem aos usuários a capacidade de criar e manipular todas as entidades no esquema PUBLIC.
Uma conta de usuário comum tem o direito de acessar catálogos do sistema. Caso contrário, a conta do usuário não pode funcionar adequadamente (intrínseco aocomportamento do servidor PostgreSQL).
Lista 3. Reunindo informações sobre uma tabela
postgres=> SELECT * FROM user1.t2;ERRO: permissão negada para relação t2postgres=> inserir nos valores de user1.t2 (10);ERRO: permissão negada para relação t2postgres=>postgres=> \d Lista de relações Esquema | Nome | Tipo | Proprietário--------+------+-------+---------- user1 | t1 | tabela | postgres user1 | t2 | tabela | postgres(2 linhas)
postgres=> \d t? Tabela "user1.t1" Coluna | Tipo | Modificadores--------+---------+----------- i | número inteiro |
Tabela "user1.t2" Coluna | Tipo | Modificadores--------+---------+----------- i | número inteiro |
Apesar de não ser possível acessar a tabela, o usuário ainda pode reunir informações sobre ela.
A Lista 4 mostra a conta de usuário user1 obtendo uma lista de contas de usuário e suas respectivas propriedades, também. O usuário comum não pode acessar as própriassenhas.
Lista 4. Obtendo propriedades de contas de usuário
postgres=> select * from pg_user; usename | usesysid | usecreatedb | usesuper | usecatupd | passwd | valuntil | useconfig----------+----------+-------------+----------+-----------+----------+----------postgres | 10 | t | t | t | ******** | | user1 | 18770 | f | f | f | ******** | |(2 rows)
Todos os usuários possuem a habilidade padrão de aprender as definições e o esquema do cluster.
A Lista 5 mostra um script que reúne informações sobre o esquema de definição inteiro do cluster por meio de consulta dos catálogos. Os catálogos do sistema podem ser
modificados, ou "raqueados", pelo superusuário, mitigando assim esta ameaça.
Lista 5. Extraindo definições globais do cluster
#!/bin/bashpsql mydatabase << _eof_set search_path=public,information_schema,pg_catalog,pg_toast;\t\o list.txtSELECT n.nspname||'.'||c.relname as "Table Name"FROM pg_catalog.pg_class c JOIN pg_catalog.pg_roles r ON r.oid = c.relowner LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespaceWHERE c.relkind IN ('r','')ORDER BY 1;\q_eof_
for i in $( cat list.txt ); do psql -c "\d $i"done
02/04/12 Segurança Total em um Banco de Dados PostgreSQL
4/15www.ibm.com/developerworks/br/opensource/library/os-postgresecurity/
Criando e acessando funções definidas pelo usuário
Funções são confiáveis ou não-confiáveis. Linguagens processuais confiáveis executam instruções dentro do contexto do banco de dados, como criação de tabelas, índices,
inclusão ou remoção de dados, etc. Linguagens procedurais não confiáveis além dos recursos confiáveis, são capazes de afetar o mundo real também, como a lista de
conteúdo de um diretório, criação, ou exclusão de arquivos, chamada de processos do sistema e mesmo criação de conexões de soquete para outros hosts.
Lista 6. Incluindo linguagens procedurais em um banco de dados e restaurando acesso ao user1
postgres=# create language plpgsql;CREATE LANGUAGEpostgres=# create language plperlu;CREATE LANGUAGEpostgres=# create language plperl;CREATE LANGUAGEpostgres=> SET SESSION AUTHORIZATION postgres;SETpostgres=# GRANT USAGE ON SCHEMA PUBLIC TO user1;GRANT
Lista 7. Linguagens procedurais confiáveis versus não confiáveis
postgres=# select lanname as language, lanpltrusted as trusted from pg_language; language | trusted----------+--------- internal | f c | f sql | t plperlu | f plperl | t(5 rows)
Diferentemente das tabelas, a conta de usuário não necessita de permissões especiais ao chamar a função de alguma outra pessoa, mesmo se elas foram criadas pelo
superusuário.
Lista 8. Chamando uma função de superusuário
postgres=# SET SESSION AUTHORIZATION postgres;SETpostgres=# CREATE OR REPLACE FUNCTION public.f1 (postgres(# OUT x textpostgres(# ) ASpostgres-# $body$postgres$# select 'hello from f1()'::text;postgres$# $body$postgres-# LANGUAGE SQL;CREATE FUNCTIONpostgres=# SET SESSION AUTHORIZATION user1;SETpostgres=>postgres=> SELECT * FROM f1(); x----------------- hello from f1()(1 row)
A função na Lista 9 abaixo foi criada pelo superusuário usando plperlu. Ela retorna o conteúdo do diretório; user1 pode chamar esta função. Um usuário comum pode
chamar ambas as funções, confiáveis e não confiáveis. O melhor método para mitigar esta ameaça é negar o acesso à função revogando o privilégio.
Lista 9. Explorando funções por um usuário autorizado
postgres=> SET SESSION AUTHORIZATION postgres;SETpostgres=# CREATE OR REPLACE FUNCTION public.f2 (postgres(# OUT x textpostgres(# ) ASpostgres-# $body$postgres$# # emite conteúdo do diretório-raiz em saída padrãopostgres$# # observe o uso das aspas simplespostgres$# $a = ̀ls -l / 2>/dev/null̀;postgres$# $message = "\nAqui está a lista de diretórios\n".$a; postgres$# return $message;postgres$# $body$postgres-# LANGUAGE PLPERLU;CREATE FUNCTIONpostgres=# SET SESSION AUTHORIZATION user1;SETpostgres=> SELECT * FROM f2(); x----------------------------------------------------------------------------
02/04/12 Segurança Total em um Banco de Dados PostgreSQL
5/15www.ibm.com/developerworks/br/opensource/library/os-postgresecurity/
Aqui está a lista de diretórios total 120 drwxr-xr-x 2 root root 4096 Aug 29 07:03 bin drwxr-xr-x 3 root root 4096 Oct 11 05:17 boot drwxr-xr-x 3 root root 4096 Nov 26 2006 build lrwxrwxrwx 1 root root 11 Aug 22 2006 cdrom -> media/cdrom drwxr-xr-x 15 root root 14960 Oct 12 07:35 dev drwxr-xr-x 118 root root 8192 Oct 12 07:36 etc(1 row)
Lista 10. Assegurando o user1 e o grupo PUBLIC
postgres=# SET SESSION AUTHORIZATION postgres;SETpostgres=# REVOKE ALL ON FUNCTION f2() FROM user1, GROUP PUBLIC;REVOKEpostgres=# SET SESSION AUTHORIZATION user1;SETpostgres=> SELECT * FROM f2();ERROR: permission denied for function f2postgres=>
A Lista 11 envolve reunião de inteligência.
Lista 11. Obtendo o código de origem da função
postgres=> SET SESSION AUTHORIZATION user1;SETpostgres=> select prosrc as "function f3()" from pg_proc where proname='f3';
function f3()---------------# emite o conteúdo do diretório-raiz na saída padrão # observe o uso das aspas simples $a = ̀ls -l / 2>/dev/null̀; $message = "\nAqui está a lista de diretórios\n".$a; return $message;(1 row)
Para ocultar o código de origem:
Escreva a sua função como um módulo em seu ambiente de linguagem nativa (C, Perl, Python, etc.) e armazene-a no disco rígido do host. Depois crie uma função
definida pelo usuário abstrata em PostgreSQL que chame o módulo.
Considere gravar o código de origem em uma tabela e dinamicamente criar sua função conforme for necessário.Grave sua função definida pelo usuário em outro banco de dados no cluster, que é então chamada por uma conta de usuário autorizada usando o módulo dblink .
Usando o security definer
O security definer executa a função com os privilégios do usuário que a criou. Assim, um usuário pode acessar uma tabela que, sob circunstâncias normais, está indisponível.
Por exemplo, como mostrado na Lista 12, uma tabela com duas colunas é criada no esquema Postgres pelo postgres do superusuário. O usuário comum, user1, invocará umafunção usando o parâmetro security definer e obterá um valor com base em um valor de entrada.
Lista 12. Criando uma tabela e uma função
postgres=# SET SESSION AUTHORIZATION postgres;SETpostgres=# CREATE TABLE postgres.t4(x serial,y numeric);NOTICE: CREATE TABLE will create implicit sequence "t4_x_seq" for serial column "t4.x"CREATE TABLEpostgres=# INSERT INTO postgres.t4(y) VALUES (random()::numeric(4,3));INSERT 0 1postgres=# INSERT INTO postgres.t4(y) VALUES (random()::numeric(4,3));INSERT 0 1postgres=# INSERT INTO postgres.t4(y) VALUES (random()::numeric(4,3));INSERT 0 1postgres=# INSERT INTO postgres.t4(y) VALUES (random()::numeric(4,3));INSERT 0 1postgres=# INSERT INTO postgres.t4(y) VALUES (random()::numeric(4,3));INSERT 0 1postgres=# CREATE OR REPLACE FUNCTION public.f4 (postgres(# IN a int,postgres(# OUT b numericpostgres(# ) RETURNS SETOF numeric ASpostgres-# $body$postgres$# select y from postgres.t4 where x=$1 limit 1;postgres$# $body$postgres-# LANGUAGE SQL SECURITY DEFINER;CREATE FUNCTION
02/04/12 Segurança Total em um Banco de Dados PostgreSQL
6/15www.ibm.com/developerworks/br/opensource/library/os-postgresecurity/
A Lista 13 mostra que a conta de usuário user1 agora pode acessar as informações desejadas.
Lista 13. Função não-privilegiada acessando uma tabela com uma chamada de função
postgres=# SET SESSION AUTHORIZATION user1;SETpostgres=> SELECT b as "my first record" FROM f4(1); my first record----------------- 0.379(1 row)
postgres=> SELECT b as "my second record" FROM f4(2); my second record------------------ 0.200(1 row)
Invadindo a senha do PostgreSQL
A administração de senha efetiva é fundamental para a segurança em um DBMS. É função do DBA impor uma política de senha aprovada. Uma senha deve consistir em
caracteres alfanuméricos escolhidos aleatoriamente que não tenham um padrão discernível. A prática comum dita que as senhas possuem pelo menos seis caracteres e são
mudadas frequentemente.
Contas e senhas de usuário do PostgreSQL
A política de segurança da conta de usuário do PostgreSQL é centrada nos comandos SQL que criam e administram a conta do usuário:
CREATE ROLE
ALTER ROLE
DROP ROLE
As seguintes instruções SQL pertencem ao antigo estilo de administração de conta de usuário (apesar de válido, você deve usar a técnica mais nova de gerenciamento de
usuários como funções):
CREATE GROUP
ALTER GROUP
DROP GROUP
CREATE USER
ALTER USER
DROP USER
As senhas são armazenadas como descriptografadas e criptografadas. Senha descriptografadas são armazenadas abertamente e podem ser lidas pelo superusuário. A senha
criptografada envolve a geração e armazenamento de seu hash MD5, que não pode ser lido. Alguém valida a senha no momento do login ao executar hash e compará-la com
o que já foi armazenado no cluster de dados.
Abaixo estão algumas chamadas de exemplo que criam e administram a senha:
Uma conta é criada sem uma senha:
CREATE ROLE user1 WITH LOGIN;
Uma conta é criada com uma senha descriptografada:
CREATE ROLE roger WITH LOGIN UNENCRYPTED PASSWORD '123'
Uma conta é alterada e uma senha criptografada é designada a ela:
ALTER ROLE user1 WITH ENCRYPTED PASSWORD '123'
A execução de uma consulta SQL pelo superusuário em relação à tabela de catálogos pg_shadow retorna o nome da conta do usuário e sua senha. A Lista 14 mostra o
código.
Lista 14. Obtendo a senha de um usuário do catálogo
postgres=# select usename as useraccount,passwd as "password" from pg_shadow wherelength(passwd)>1 order by usename;
useraccount | password-------------+------------------------------------- user1 | md5173ca5050c91b538b6bf1f685b262b35 roger | 123(2 rows)
A Lista 15 mostra como é possível gerar o hash MD5 para user1 com a senha 123.
02/04/12 Segurança Total em um Banco de Dados PostgreSQL
7/15www.ibm.com/developerworks/br/opensource/library/os-postgresecurity/
Lista 15. Gerando uma senha MD5
postgres=# select 'md5'||md5('123user1') as "my own generated hash", passwd as "stored hash for user1" from pg_shadow where usename='user1';
my own generated hash | stored hash for user1-------------------------------------+------------------------------------- md5173ca5050c91b538b6bf1f685b262b35 | md5173ca5050c91b538b6bf1f685b262b35(1 row)
Pronto para outro susto? Existem alguns poucos mecanismos dentro do PostgreSQL que podem impor uma política de senha blindada.
As possíveis limitações de segurança incluem:
O superusuário não pode impor um número mínimo de caracteres a ser usado para a senha.
Apesar de haver um parâmetro padrão nas definições da configuração para como a senha deva ser armazenada (descriptografada ou criptografada com um hash MD5),
o usuário não pode ser forçado usar um métodos de armazenamento particular pelo superusuário.
Não existe nenhum mecanismo que imponha um tempo de vida à conta do usuário.O mecanismo que controla o tempo de vida efetivo da senha da conta do usuário se torna irrelevante quando o método de conexão não é PASSWORD ou MD5 no
arquivo de configuração de autenticação de cliente do cluster, pg_hba.conf.
Os parâmetros de tempo de execução do usuário que são alterados pela instrução ALTER ROLE e que foram configurados pelo superusuário ou pelas definições de
configuração estabelecidas por padrão no arquivo postgresql.conf, podem ser alterados pelo proprietário da conta do usuário à vontade.
Renomear uma conta de usuário limpa sua senha se ela foi criptografada.
Não é possível controlar quem fez as mudanças nas contas de usuário ou quando essas mudanças ocorreram.
Uma arquitetura agressiva com edição cuidadosa dos catálogos do sistema podem recompensar o DBA vigilante.
Devido ao fascinante potencial para danos, as limitações de segurança das contas e senhas de usuário valem outro artigo separado.
Invadindo a senha
Impor uma senha forte é uma meta digna, mas simplesmente não há como julgar sua força até que alguém a invada. A invasão de utilitários se baseia em duas abordagens, como
a seguir.
Força bruta
O teste metódico do hash. Ele começa com algumas letras, aumentando em comprimento à medida que o ataque continua. Este método é recomendado para testar
senhas curtas.
Ataques de dicionário
Usa uma abordagem de engenharia social. Um dicionário de palavras, usado pelo utilitário de invasão, é o ponto inicial. Depois disso, combinações dessas palavras são
geradas e testadas em relação ao hash capturado. Este ataque tira vantagem da crença errônea de que uma cadeia de caracteres longa que consista em uma combinação
mnemônica de cadeias e caracteres é mais segura do que um comprimento um pouco mais curto de cadeias e caracteres escolhidos aleatoriamente.
Dependendo da força da senha e do hardware usado, a invasão pode ocorrer em alguns poucos segundos até vários meses.
Os DBAs estão interessados em identificar senhas com menos de seis caracteres de comprimento.
O utilitário da linha de comandos MDCrack usa a força bruta para testar a senha. Este binário Windows funciona bem em Linux sob Wine.
Inserir wine MDCrack-sse.exe --help retorna os comutadores de configuração. Alguns são mostrados abaixo:
Usage: MDCrack [options...] --test-hash|hash MDCrack [options...] --bench[=PASS] MDCrack [options...] --resume[=FILENAME]|--delete[=FILENAME] MDCrack [options...] --help|--about
A chamada de linha de comandos mais simples é wine MDCrack-sse.exe --algorithm=MD5 --append=$USERNAME $MD5_HASH, em que $USERNAME é o nome do
usuário e $MD5_HASH é o hash MD5 na tabela de catálogos pg_shadow.
MDCrack pode executar em modo de sessão, como a seguir, assim é possível parar uma operação de invasão e continuar posteriormente.
Lista 16. MDCrack executando em modo de sessão
# iniciar sessãowine MDCrack-sse.exe --algorithm=MD5 --append=$USERNAME $MD5_HASH\ --session=mysessionfile.txt
# continuar o uso do último modo de sessãowine MDCrack-sse.exe --algorithm=MD5 --append=$USERNAME $MD5_HASH\ --resume=mysessionfile.txt
O conjunto de caracteres padrão é abcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ. Você poderia terminar com um processo imenso se
a senha candidata incluísse um caractere que não fizesse parte do conjunto de caracteres definido como padrão. É possível mudá-lo para qualquer combinação de caracteres
alfanuméricos que desejar. Por exemplo, você pode desejar incluir caracteres de controle e pontuação.
02/04/12 Segurança Total em um Banco de Dados PostgreSQL
8/15www.ibm.com/developerworks/br/opensource/library/os-postgresecurity/
O ajuste do conjunto de caracteres é feito na linha de comandos. A variável $CHARSET representa o conjunto real de caracteres que será usado:
wine MDCrack-sse.exe --algorithm=MD5 --append=$USERNAME $MD5_HASH --charset=$CHARSET
O exemplo abaixo é uma chamada para violar uma senha do Postgres de 123. Ignorar os três primeiros caracteres fornece a você o valor hash MD5
md5173ca5050c91b538b6bf1f685b262b35. É possível determinar a senha com a seguinte chamada (dica: grep para a cadeia de caracteres Collision found). Esta invasãoleva aproximadamente 0,32 segundos:
wine MDCrack-sse.exe --algorithm=MD5 --append=user1 173ca5050c91b538b6bf1f685b262b35\| grep "Collision found"
A Lista 17 demonstra a invasão da senha no sistema catalog pg_shadow.
Lista 17. Invadindo a senha
wine MDCrack-sse.exe --algorithm=MD5 --append=user1 \p̀sql -t -c "select substring(passwd,4) from pg_shadow where usename='user1';"̀ \| grep "Collision found"
Modelos de autenticação
Agora que você viu o que pode dar errado, é hora de explorar o que você pode fazer para fazer as coisas certas. A autenticação é um assunto vasto, sendo assim, somente o
básico será abordado aqui.
Sob o guarda-chuva "autenticação", existem muitos significados de controle de acesso para o cluster Postgres:
Soquetes de domínio UNIXAutenticação de servidor Ident
Autenticação de servidor LDAP
PAM
Kerberos
SSL
Soquetes de domínio UNIX
Um soquete de domínio UNIX é um canal de comunicação bidirecional que remonta um arquivo de muitos aspectos. O servidor cria o soquete de domínio que está
aguardando por clientes para abrir o arquivo com o sistema de arquivos. Um soquete de domínio PostgreSQL típico é mostrado abaixo.
Lista 18. Soquete de domínio típico
robert@wolf:~$ ls -la /tmp|grep PGSQLsrwxrwxrwx 1 robert robert 0 2007-10-15 12:47 .s.PGSQL.5432-rw------- 1 robert robert 33 2007-10-15 12:47 .s.PGSQL.5432.lock
Observe que o número da porta está anexado ao nome do arquivo. Reconfigurar o servidor para uma porta TCP/IP diferente também altera o nome do soquete do domínio.
Três parâmetros no arquivo de configuração postgresql.conf controlam as permissões para um soquete de domínio:
unix_socket_directory (o arquivo PATH)unix_socket_group (o grupo de usuários)
unix_socket_permissions (assume como padrão 0777)
O local do do soquete de domínio varia de acordo com a distribuição Linux:
O código de origem PostgreSQL instala e coloca o soquete no diretório /tmp.
O BSD localiza o soquete no diretório /tmp.
Os derivativos RedHat localizam o soquete no diretório /tmp.
Os derivativos Debian localizam o soquete em /var/run/postgresql com permissões somente para o postgresqlaccount.
Existem algumas coisas estranhas sobre soquetes de domínio. Considere as implicações do seguinte exemplo.
Sudosudo é um comando poderoso com muitas possíveis configurações que permitem aos usuários executar programas com os privilégios de segurança de outro usuário(normalmente o superusuário ou raiz). Similar ao comando do Windows runas.
Um cluster é criado no diretório inicial de robert (superusuário) com uma autenticação de confiável. Na inicialização do servidor, porém, as permissões de soquete de domínio
permitem login, exceto robert. O usuário robert efetua login com TCP, mas é recusado no soquete de domínio. Porém, robert pode efetuar login através de um soquete de
domínio após efetuar sudopara nobody.
Este exemplo mostra a versatilidade das permissões de arquivos, mitigando os danos causados por um cracker que se torne superusuário.
02/04/12 Segurança Total em um Banco de Dados PostgreSQL
9/15www.ibm.com/developerworks/br/opensource/library/os-postgresecurity/
Lista 19. Permissões
robert@wolf:~$ initdb -A trust -U postgres ~/data
robert@wolf:~$ pg_ctl -D ~/data/ -l ~/logfile.txt \-o "-c unix_socket_permissions=007 -c unix_socket_directory=/tmp" startserver starting
robert@wolf:~$ psql -h localhost -U postgres -c "select 'superuser:this works' as msg" msg---------------------- superuser:this works(1 row)
robert@wolf:~$ psql -h /tmp -U postgres -c "select 'superuser:this fails' as msg"psql: não foi possível conectar-se ao servidor: Permissão negada O servidor está executando localmente e aceitando conexões no soquete de domínio Unix "/tmp/.s.PGSQL.5432"?robert@wolf:~$ sudo su nobody[sudo] password for robert:
$ psql -h localhost -U postgres -c "select 'nobody:this works' as msg" msg------------------- nobody:this works(1 row)
$ psql -h /tmp -U postgres -c "select 'nobody:this still works' as msg" msg------------------------- nobody:this still works(1 row)
Ident
O servidor Ident responde a uma simples pergunta: Qual usuário iniciou a conexão que sai da sua porta X e se conecta à minha Y? No contexto de um servidor PostgreSQL, é
informado o DBMS da Identidade da conta do usuário que está fazendo uma tentativa de login. O PostgreSQL então obtém essa resposta e permite ou nega permissão para
login seguindo um conjunto de regras configurado pelo DBA nos arquivos de configuração apropriados.
O mecanismo de autenticação do servidor Ident do PostgreSQL funciona mapeando as contas de usuário do PostgreSQL para as contas de usuário do UNIX usando o
servidor Ident do próprio host.
Os exemplos a seguir assumem que todas as conta de usuário do UNIX foram mapeadas no PostgreSQL para poder efetuar login em qualquer banco de dados, desde que
eles usem o mesmo nome de conta no PostgreSQL. O login falha se o nome de usuário do UNIX não existir como uma conta de usuário no servidor PostgreSQL, ou se uma
tentativa for feita para efetuar login usando outro nome de conta de usuário do PostgreSQL.
~Suponha que você tenha se conectado por meio de SSH no host: ssh -l robert wolf.
Lista 20. Um login falho e um bem-sucedido
robert@wolf:~$ psql -U robert robertBem-vindo ao psql 8.2.4, o terminal interativo do PostgreSQL.
Digite: \copyright para termos de distribuição \h para ajuda com comandos SQL \? para ajuda com comandos psql \g ou terminar com ponto e vírgula para executar consulta \q para encerrar
robert@wolf:~$ psql -U postgres robertpsql: FATAL: Autenticação Ident falhou para usuário "postgres"
-- Isto funciona, su para se tornar o postgres da conta do usuário UNIX
O PostgreSQL usa dois arquivos para administrar e controlar todas as sessões de login para usuários que foram autenticados pelo servidor Ident:
pg_hba.conf
Controla o acesso através de registros que são definidos em uma única linha.
pg_Ident.conf
Entra em ação quando o serviço Ident é usado como o autenticador da conta do usuário. Por exemplo, o METHOD é identificado como Ident no arquivo pg_hba.conf.
Lista 21. Exemplos de configuração simples
Exemplo 1: Uma conexão LOCALHOST impõe que a conta unix robert acesse o banco de dados robertexclusivamente. Não existe autenticação nos soquetes de domínio UNIX.(pg_hba.conf)# TYPE DATABASE USER CIDR-ADDRESS METHOD OPTION host all all 127.0.0.1/32 Ident mymap local all all trust
02/04/12 Segurança Total em um Banco de Dados PostgreSQL
10/15www.ibm.com/developerworks/br/opensource/library/os-postgresecurity/
(pg_Ident.conf)# MAPNAME Ident-USERNAME PG-USERNAME mymap robert robert
Exemplo 2: Uma conexão do soquete de domínio impõe que a conta unix robert acesse qualquer bancode dados como conta pg robert; postgres de conta unix podem acessar qualquer banco de dados como usuário robert.(pg_hba.conf)# TYPE DATABASE USER CIDR-ADDRESS METHOD OPTION local all all Ident mymap host all all 127.0.0.1/32 trust
(pg_Ident.conf)# MAPNAME Ident-USERNAME PG-USERNAME mymap robert robert mymap postgres robert
Exemplo 3: Uma conexão do soquete de domínio impõe que a conta unix pode se conectar a qualquerbanco de dados com seu homônimo de banco de dados postgres usando a palavra-chave "sameuser". pg_Ident.conf não é necessariamente aqui. Conexões do host local através de TCP-IP são rejeitadas.
(pg_hba.conf)# TYPE DATABASE USER CIDR-ADDRESS METHOD OPTION local template0,template1 all Ident sameuser host all all 127.0.0.1/32 reject
Ex4: (todos os usuários podem se conectar com seus próprios nomes de usuário somente aos bancos de dados postgres e robert)
(pg_hba.conf)# TYPE DATABASE USER CIDR-ADDRESS METHOD OPTION local template0,template1 all Ident sameuser
Lembre-se das seguintes advertências:
As mudanças de configuração tomam efeito assim que você recarrega os arquivos, como pg_ctl -D mycluster reload.
Várias definições de configuração podem causar comportamento temperamental. Procure por mensagens de configuração falhas no log.Ident foi projetado e implementado quando as próprias máquinas foram consideradas seguras. Qualquer servidor remoto que procure autenticação deve ser considerado
suspeito.
O servidor Ident é usado somente para autenticar conexões de host local.
Criptografia de dados
Existem muitas maneiras pelas quais você pode se expor inadvertidamente a um cracker dentro de uma intranet.
Vamos dar uma sondada. Suponha que você execute o seguinte comando no seu host local, 192.168.2.64: tcpdump -i eth0 -X -s 3000 host 192.168.2.100 and
port 5432.
Em um host remoto, 192.168.2.100, você se conecta ao PostgreSQL do host local, que já está atendendo na porta 5432: psql -h 192.168.2.64 -p 5432 -U postgrespostgres. Agora altere a senha da sua conta de superusuário, postgres: ALTER USER postgres WITH ENCRYPTED PASSWORD 'my_new_password';.
Lista 22. Discernindo a senha em um dump de dados sondado
16:39:17.323806 IP wolf.56336 > laptop.postgresql: P 598:666(68) ack 470 win 3068<nop,nop,timestamp 9740679 9589666> 0x0000: 4500 0078 4703 4000 4006 6d88 c0a8 0264 E..xG.@[email protected] 0x0010: c0a8 0240 dc10 1538 6a4f 7ada 6a71 e77c [email protected].| 0x0020: 8018 0bfc 1a9d 0000 0101 080a 0094 a187 ................ 0x0030: 0092 53a2 5100 0000 4341 4c54 4552 2055 ..S.Q...CALTER.U 0x0040: 5345 5220 706f 7374 6772 6573 2057 4954 SER.postgres.WIT 0x0050: 4820 454e 4352 5950 5445 4420 5041 5353 H.ENCRYPTED.PASS 0x0060: 574f 5244 2027 6d79 5f6e 6577 5f70 6173 WORD.'my_new_pas 0x0070: 7377 6f72 6427 3b00 sword';.
Túneis SSH usando redirecionamento de porta
O redirecionamento de IP é uma tecnologia de tunelamento que redireciona pacotes da Internet de um host para outro. Ele permite que seus clientes PostgreSQL, como psql,
pgadmin, e mesmo openoffice, se conectem ao servidor Postgres remoto com uma conexão SSH.
Considere as seguintes questões:
O que acontece se não existir nenhum cliente psql no servidor PostgreSQL remoto?
O que acontece se você precisar fazer upload ou download de dados entre sua estação de trabalho e o host remoto?O que você faz quando precisa usar os clientes do banco de dados porque eles podem executar certas tarefas que o cliente psql também não pode fazer, ou que não
pode fazer de jeito algum?
Como fazer o tunelamento de sua rede para que a sua equipe possa se conectar remotamente a um banco de dados protegido por um firewall?
02/04/12 Segurança Total em um Banco de Dados PostgreSQL
11/15www.ibm.com/developerworks/br/opensource/library/os-postgresecurity/
Este exemplo conecta um cliente (host local) a um host remoto (192.168.2.100). Uma conexão com proxy na porta da estação de trabalho de 10000 é criada. O cliente, na
conexão com a porta 10000, é redirecionado para o servidor PostgreSQL do host remoto, que está atendendo na porta 5432: ssh -L 10000:localhost:5432192.168.2.100.
Incluir o comutador -g permite que outros hosts obtenham vantagem da sua conexão redirecionada, o que a torna uma rede privada virtual (VPN) instantânea para conexões
Postgres: ssh -g -L 10000:localhost:5432 192.168.2.100.
Algumas advertências sobre tunelamento:
O cliente e o servidor do banco de dados têm a impressão de que estão se comunicando com seu próprio host local.
Lembre-se de configurar o arquivo pg_hba.conf para definir a autenticação correta para as conexões do host local usando TCP/IP.
Portas abaixo de 1024 são exclusivamente controladas pelo raiz.
Sessões de SSH necessitam de uma conta de usuário existente no servidor PostgreSQL/SSH.
Sessões criptografadas por SSL
Sessões criptografadas com PostgreSQL necessitam que o servidor seja compilado com o comutador --with-openssl . Os binários distro do Linux possuem essa função.Clientes como psql e pgadmin também possuem os recursos do requisito.
É possível especificar o servidor usando o utilitário de linha de comandos pg_config , como a seguir.
pg_config --configure
Para preparar o servidor PostgreSQL para sessões criptografadas:
1. Crie uma chave de servidor auto-assinada (server.key) e um certificado (server.crt) usando a ferramenta de linha de comandos OpenSSL openssl.
1. Crie a chave do servidor: openssl genrsa -des3 -out server.key 1024.
2. Remova a passphrase openssl rsa -in server.key -out server.key.
3. Crie um certificado auto-assinado para o servidor: openssl req -new -key server.key -x509 -out server.crt.
2. Instale os dois arquivos, server.key e server.crt, no diretório do cluster de dados.
3. Edite o arquivo postgresql.conf e configure o par nomeado: ssl = on.4. Reinicie o servidor.
Lista 23. Conexão de sessão criptografada com SSL bem-sucedida
robert@wolf:~$ psql -h 192.168.2.100 -U robertBem-vindo ao psql 8.2.4, o terminal interativo do PostgreSQL.
Digite: \copyright para termos de distribuição \h para ajuda com comandos SQL \? para ajuda com comandos psql \g ou terminar com ponto e vírgula para executar consulta \q para encerrar
Conexão SSL (código: DHE-RSA-AES256-SHA, bits: 256)
robert=#
O servidor sempre testa a conexão primeiro para os pedidos de sessão criptografados. Porém, é possível controlar o comportamento do servidor editando o arquivo deautenticação pg_hba.conf. No lado do cliente, é possível controlar o comportamento padrão do cliente (psql) para o uso de uma sessão criptografada ou não por meio da
definição da variável de ambiente PGSSLMODE.
Existem seis modos (dois novos modos são específicos da V8.4).
Modo Descriçãodisable Tentará somente conexões SSL descriptografadas.
allow Primeiro tenta uma conexão descriptografada e, se não obtiver êxito, uma tentativa de conexão SSL é feita.prefer O oposto de allow; a primeira tentativa de conexão é SSL e a segunda é descriptografada.
require O cliente tenta somente uma conexão SSL criptografada.verify-ca Uma conexão SSL, e certificado de cliente válido assinado por um CA confiável.
Verify-fullUma conexão SSL, certificado de cliente válido assinado por um CA confiável, e o nome do host do servidor correspondente ao nome do host do certificado.
Por exemplo: export PGSSLMODE=prefer.
Certificados SSL
Autenticação SSL é quando o cliente e o servidor trocam certificados que foram assinados por um terceiro que tem credenciais inquestionáveis. Esse terceiro é conhecidocomo uma autoridade de certificação (CA). A conexão é recusada pelo servidor ou pelo cliente quando não recebe um certificado legítimo do outro.
Apesar de haver muitos detalhes, a configuração de uma autenticação no PostgreSQL usando certificados SSL é direta:
1. Edite postgresql.conf, ssl=on.
A autenticação do lado do servidor precisa que os seguintes arquivos estejam em seu cluster de dados:
server.keyserver.crt (que deve ser assinado por um CA)
root.crt (verifica a autenticação do cliente)root.crl (lista de revogação de certificado, opcional)
02/04/12 Segurança Total em um Banco de Dados PostgreSQL
12/15www.ibm.com/developerworks/br/opensource/library/os-postgresecurity/
O arquivo root.crt contém uma lista de certificados CA aprovados. Deve haver um coleta inteira de certificados disponíveis para a sua distribuição particular, que vocêpode incluir.
A arquivo root.crl é similar ao root.crt quanto ao fato de que contém uma lista de certificados assinados pelo CA. Porém, esses certificados são de clientes que tiveram odireito de conexão revogado. Um root.crl vazio não interferirá com o processo de autenticação.
A autenticação do lado do cliente precisa que os seguintes arquivos estejam no diretório inicial do cliente, ~/.postgresql:
postgresql.key
postgresql.crtroot.crt (verifica a autenticação do servidor)
root.crl (lista de revogação de certificado, opcional)
Assim como com o root.crt do servidor, arquivo do cliente, root.crt, contém uma lista de certificados que foram assinados por um terceiro CA respeitado. O últimoarquivo, root.crl, é opcional e é usado para revogar certificados do servidor.
A obtenção de certificados requer que ambos, cliente e servidor, tenham enviado pedidos de certificado, client.csr e server.csr, ao CA. Os certificados somente podem
ser criados após terem gerado suas próprias chaves privadas, como a seguir.
openssl req -new -newkey rsa:1024 -nodes -keyout client.key -out client.csropenssl req -new -newkey rsa:1024 -nodes -keyout server.key -out server.csr
Existe mais de uma maneira de executar o utilitário openssl para obter o que você precisa. Por exemplo, é possível colocar um tempo de vida neles, ou é possível gerá-los com certificados auto-assinados e eliminar a necessidade de um CA.
2. Agora você tem três opções para gerar seus certificados de cliente e servidor. Você pode:
Obter client.csr e server.csr assinados por um CA respeitado.Se tornar um CA usando o utilitário openssl perl CA.pl.
Criar certificados auto-assinados e inclui-los nos arquivos root.crt do servidor e do cliente, respectivamente.3. Abaixo está um conjunto de comandos abreviados para usar com o CA.pl. Consulte as man pages CA.pl para obter mais informações sobre pedidos de certificado.
CA.pl -newca (criar a nova CA)
CA.pl -newreq (criar um pedido de certificado com uma chave privada)CA.pl -signreq (assinar o pedido de certificado pelo CA que você criou)
Para os puristas do software livre, sempre há o http://www.cacert.org para certificados 'grátis'.
Lista 24. Um certificado de exemplo
-----BEGIN CERTIFICATE-----MIIC9TCCAl6gAwIBAgIJAMuhpY+o4QR+MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpTb21lLVN0YXRlMSEwHwYDVQQKExhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQxFDASBgNVBAMTC0NvbW1vbiBOYW1lMB4XDTA3MDIxMjEyMjExNVoXDTA3MDMxNDEyMjExNVowWzELMAkGA1UEBhMCQVUxEzARBgNVBAgTClNvbWUtU3RhdGUxITAfBgNVBAoTGEludGVybmV0IFdpZGdpdHMgUHR5IEx0ZDEUMBIGA1UEAxMLQ29tbW9uIE5hbWUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKA4nX/eBKsPJI1DmtH2wdJE9uZf+IRMUWYrAEDL4F6NEuo2+BsIoOBKS/rrV77Itet9kduJCQ6k/z2ouAVb4muXpJALDjJpYBXt9wqZf+2p1n9dqDw1rCWBjXIdhOcA3DDvu0Ig1FUfm8GS97evxM5IJBECRnK/5JZroXCRSHcpAgMBAAGjgcAwgb0wHQYDVR0OBBYEFElEWNUCV+61itXp86czrDe35vjrMIGNBgNVHSMEgYUwgYKAFElEWNUCV+61itXp86czrDe35vjroV+kXTBbMQswCQYDVQQGEwJBVTETMBEGA1UECBMKU29tZS1TdGF0ZTEhMB8GA1UEChMYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMRQwEgYDVQQDEwtDb21tb24gTmFtZYIJAMuhpY+o4QR+MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEAaFzbUmXcWVzqaVeEpZkNwF/eVh110qIUUxXGdeKZGNXIyK67GCUYSG/IFkZ/hrGLeqElLrdmU0mHd2Enq2IuvhxnsOVTTickjKospJvlHPYSumkXx0Xpzey9PhjLh1chpxNGTATKb8ET8YZvBRrDHl/EMPIjLd62iSR/ugFe8go=-----END CERTIFICATE-----
4. Supondo que você gerou certificados auto-assinados, copie-os no local correto e edite root.crt.
O certificado do cliente é salvo no root.crt do servidor e o certificado do servidor é alvo no root.crt do cliente.
5. Monitore as mensagens de log na reinicialização do servidor para confirmar que tudo está configurado corretamente.
O comportamento padrão do servidor ainda usa criptografia. Isso pode ser desativado editando-se o par de nomes ssl_ciphers='NULL' em postgresql.conf e reiniciando oservidor. Considere sua decisão com cuidado; configurar ssl_ciphers para NULL efetivamente desativa a criptografia.
Conclusão
Neste artigo, você aprendeu alguns fundamentos sobre a proteção do servidor do seu banco de dados PostgresSQL. Existe muito mais material sobre este assunto, mas não é
possível abordar muitos tópicos em um só artigo. Não há o suficiente sendo escrito sobre o PostgreSQL atualmente. Talvez, com um pouco da sua ajuda, possamos aprendermais sobre a segurança do PostgreSQL.
Download
Descrição Nome Tamanho Método de downloadSample code os-postgresecurity-listings_src_code.zip 10KB HTTP
02/04/12 Segurança Total em um Banco de Dados PostgreSQL
13/15www.ibm.com/developerworks/br/opensource/library/os-postgresecurity/
Informações sobre métodos de download
Recursos
Aprender
Confira o tutorial "Segurança Total em um Banco de Dados PostgreSQL," que se baseia em uma série de artigos do autor.
Leia a Documentação do PostgreSQL V8.3.8.
Consulte http://c3rb3r.openwall.net/mdcrack/.
No Wikipedia, saiba mais sobre soquetes de domínio UNIX; protocolo Ident, um protocolo da Internet que ajuda a identificar o usuário de uma conexão TCP particular;
e autoridade de certificação.
Obtenha toda as as notícias, FAQ, documentos, origem e mais para o Projeto OpenSSL.
Obtenha várias correções para os programas tcpdump e libpcap.
Saiba mais sobre redirecionamento de porta, ou tunelamento, para redirecionar tráfego TCP sem segurança através do SSH Secure Shell.
Para ouvir entrevistas e discussões interessantes para desenvolvedores de software, confira os podcasts do developerWorks.
Mantenha-se atualizado com os eventos e webcasts técnicos do developerWorks.
Siga o developerWorks no Twitter.
Confira as próximas conferências, trade shows, webcasts e outros Eventos futuros no mundo todo que são de interesse dos desenvolvedores de software livre da IBM.
Visite a zona de software livre do developerWorks para obter informações extensivas sobre instruções, ferramentas e atualizações de projeto para ajudá nodesenvolvimento de tecnologias de software livre e em seu uso com produtos da IBM, assim como nossos artigos e tutoriais mais conhecidos.
O My developerWorks é um exemplo de uma comunidade geral bem-sucedida que abrange uma ampla variedade de tópicos.
Assista e aprenda sobre a IBM e tecnologias de software livre e funções de produto com as demos gratuitas do developerWorks On demand.
Obter produtos e tecnologias
Inove seu próximo projeto de desenvolvimento de software livre com o software de avaliação IBM, disponível para download ou em DVD.
Faça o download de versões de avaliação de produto IBM ou experimente as versões de avaliações disponíveis on-line no IBM SOA Sandbox e coloque suas mãos em
ferramentas de desenvolvimento de aplicativos e produtos de middleware do DB2®, Lotus®, Rational®, Tivoli® e WebSphere®.
Discutir
Participe dos blogs do developerWorks e envolva-se na comunidade do developerWorks.
Sobre o autor
Robert Bernier é analista de PostgreSQL Business Intelligence na Medio Systems, que é líder na tecnologia emergente de pesquisa de mídia. Ele foi um consultor dePostgreSQL para muitos líderes em suas respectivas indústrias, incluindo telefones celulares, Wall Street, centros de pesquisa científica, contratados da defesa dos EUA, edepartamentos de TI das universidades e faculdades Ivy League. Ele é um defensor do PostgreSQL e escreveu para Sys-Admin, Hakin9, PHP Solutions, e muitos sites on-line
incluindo Linux.com, PHPbuilder.com, PHP Magazine, Linux Weekly News e o portal da Web O'Reilly. Ele contribuiu nos livros BSD Hacks e Multimedia Hacks. Eletambém mantém o pg-live, http://pg-live.info, que é usado no mundo todo em conferências, trade shows e sessões de treinamento para fazer o perfil dos incríveis recursos do
PostgreSQL.
Fechar [x]
developerWorks: Registre-se
IBM ID:
Precisa de um ID IBM?
Esqueceu seu ID IBM?
Senha:
Esqueceu sua senha?Alterar sua senha
Mantenha-me conectado.
02/04/12 Segurança Total em um Banco de Dados PostgreSQL
14/15www.ibm.com/developerworks/br/opensource/library/os-postgresecurity/
Imprimir esta página Compartilhe esta página Siga o developerWorks
Sobre
Ajuda
Entre em contato conosco
Feeds Relatar abuso
Termos de uso
Privacidade
IBM Academic Initiative
IBM PartnerWorld
Industry Network
Ao clicar em Enviar, você concorda com os termos de uso do developerWorks.
Enviar Cancelar
Na primeira vez que você efetua sign in no developerWorks, um perfil é criado para você. Informações selecionadas do seu perfil developerWorks são exibidas aopúblico, mas você pode editá-las a qualquer momento. Seu primeiro nome, sobrenome (a menos que escolha ocultá-los), e seu nome de exibição acompanharão oconteúdo que postar.
Todas as informações enviadas são seguras.
Fechar [x]
Selecione seu nome de exibiçãoAo se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o
conteúdo que você postar no developerWorks.
Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de emailpor motivo de privacidade.
Nome de exibição: (Deve possuir de 3 a 31 caracteres.)
Ao clicar em Enviar, você concorda com os termos de uso do developerWorks.
Enviar Cancelar
Todas as informações enviadas são seguras.
Média de classificação (8 votos)
1 estrela
1 estrela
2 estrelas
2 estrelas
3 estrelas
3 estrelas
4 estrelas
4 estrelas
5 estrelas
5 estrelas
Enviar
Incluir comentário:
Conectar or registre-se para deixar um comentário.
Observação: elementos HTML não são suportados nos comentários.
Notificar-me quando um comentário for adicionado1000 caracteres restantes
Postar
Nenhum comentário postado para esse artigo
02/04/12 Segurança Total em um Banco de Dados PostgreSQL
15/15www.ibm.com/developerworks/br/opensource/library/os-postgresecurity/
Acessibilidade (Inglês)