![Fechar [x]](http://dw1.s81c.com/i/c.gif){kind=small}
O administrador de segurança tem o requisito de permitir que um usuário final se conecte ao banco de dados somente a partir de um conjunto específico de endereços IP. Este artigo mostra como as funções do banco de dados e os contextos confiáveis podem ser usados para lidar com isso. Para fins de ilustração, suporemos que o administrador de segurança deseja assegurar que o usuário Einstein só possa se conectar ao banco de dados a partir do endereço IP 9.26.120.62.
Uma função é um objeto de banco de dados que agrupa um privilégio ou mais e pode ser designado a usuários, grupos, o grupo especial PUBLIC, outras funções ou um contexto confiável. As funções simplificam a administração e o gerenciamento dos privilégios ao permitir que o administrador de segurança agrupe autoridades e privilégios em uma função e conceda essa função aos usuários que precisam dessas autoridades e privilégios para realizar suas tarefas. Além disso, já que as funções residem no sistema de banco de dados do DB2, elas não estão sujeitas às mesmas restrições que os grupos.
Todos os privilégios e autoridades do DB2 que podem ser concedidos em um banco de dados podem ser concedidos a uma função. Por exemplo, pode-se conceder a uma função a autoridade CONNECT e o privilégio SELECT em alguma tabela.
Um contexto confiável é um objeto de banco de dados que define um relacionamento confiável para uma conexão entre o banco de dados e uma entidade externa, como um servidor de aplicativos.
O relacionamento confiável se baseia no seguinte conjunto de atributos:
- ID de autorização do sistema — Representa o usuário que estabelece uma conexão com o banco de dados
- Endereço IP (ou nome de domínio) — Representa o host a partir do qual a conexão com o banco de dados é estabelecida
- Criptografia do fluxo de dados — Representa a configuração de criptografia (se houver) para a comunicação de dados entre o servidor e o cliente de banco de dados
Quando um usuário estabelece uma conexão com o banco de dados, o sistema de banco de dados DB2 verifica se a conexão corresponde à definição de objeto de contexto confiável no banco de dados. Quando ocorre uma correspondência, a conexão com o banco de dados é considerada confiável.
Um dos recursos que os contextos confiáveis fornecem é a capacidade que o usuário do contexto confiável tem de herdar uma função do banco de dados. Por exemplo, o administrador de segurança pode optar por dar o privilégio SELECT na tabela de folha de pagamento para uma função e disponibilizar essa função somente por meio de um contexto confiável. Isso significa que os usuários não poderão se aproveitar da função (e, consequentemente, do privilégio de SELECT na tabela de folha de pagamento) quando estiverem operando fora do escopo do contexto confiável.
Antes do FixPak 3 do DB2 9.7, as funções herdadas por meio de contextos confiáveis não eram levadas em conta ao verificar a autoridade de CONNECT no momento da conexão com o banco de dados. Esta restrição está sendo removida no FP3 do DB2 9.7. A capacidade de restringir o local a partir do qual um usuário final pode se conectar ao banco de dados é uma aplicação imediata desse aprimoramento.
Temos o usuário regular, Einstein, e queremos permitir que ele se conecte ao banco de dados T1 em 9.26.120.64 (hotel48) somente a partir do IP 9.26.120.62 (hotel46).
Etapa 1: crie o banco de dados T1 em 9.26.120.64 (hotel48)
db2start db2 create database T1 |
Verifique se o banco de dados foi criado: db2 list db
directory.
Figura 1. diretório de banco de dados do sistema
Etapa 2: configure o protocolo de comunicação TCPIP
No lado do servidor 9.26.120.64 hotel48, execute o seguinte:
Lista 1. Configurando a comunicação e configuração para TCPIP
db2set DB2COMM=TCPIP db2 update dbm cfg using SVCENAME xziskind db2stop db2start |
No lado do cliente 9.26.120.62 hotel46, execute:
Lista 2. Catalogando o nó TCPIP e o banco de dados
db2 catalog tcpip node NT1 remote hotel48 server xziskind db2 terminate db2 catalog database T1 at node NT1 db2 terminate |
Certifique-se de que o usuário Einstein possa se conectar ao banco de dados T1.
Figura 2. A partir de 9.26.120.64 hotel48
Figura 3. A partir de 9.26.120.62 hotel46
O usuário Einstein pode se conectar ao banco de dados T1 a partir dos dois endereços IP.
Vamos verificar as autoridades de Einstein. Para esse fim, vamos usar a função de tabela AUTH_LIST_AUTHORITIES_FOR_AUTHID . Essa ação retorna todas as autoridades de um identificador de autorização, que se encontram no arquivo de configuração do banco de dados ou foram dadas a um identificador de autorização direta ou indiretamente por meio de um grupo ou função.
Lista 3. Autoridades de Einstein
db2 SELECT AUTHORITY, D_USER, D_GROUP, D_PUBLIC,
ROLE_USER, ROLE_GROUP, ROLE_PUBLIC, D_ROLE
FROM TABLE (SYSPROC.AUTH_LIST_AUTHORITIES_FOR_AUTHID ('EINSTEIN', 'U') ) AS T
ORDER BY AUTHORITY
AUTHORITY D_USER D_GROUP D_PUBLIC ROLE_USER ROLE_GROUP ROLE_PUBLIC D_ROLE
------------------------- ------ ------- -------- --------- ---------- ----------- ------
ACCESSCTRL N N N N N N *
BINDADD N N Y N N N *
CONNECT N N Y N N N *
CREATETAB N N Y N N N *
CREATE_EXTERNAL_ROUTINE N N N N N N *
CREATE_NOT_FENCED_ROUTINE N N N N N N *
DATAACCESS N N N N N N *
DBADM N N N N N N *
EXPLAIN N N N N N N *
IMPLICIT_SCHEMA N N Y N N N *
LOAD N N N N N N *
QUIESCE_CONNECT N N N N N N *
SECADM N N N N N N *
SQLADM N N N N N N *
SYSADM * N * * * * *
SYSCTRL * N * * * * *
SYSMAINT * N * * * * *
SYSMON * N * * * * *
WLMADM N N N N N N *
19 record(s) selected. |
O usuário Einstein tem autoridade de CONNECT por meio do grupo especial PUBLIC.
Etapa 3: revogar a autoridade de CONNECT a partir de PUBLIC
db2 revoke connect on database from public |
Verifique novamente as autoridades de Einstein:
Lista 4. Autoridades de Einstein depois da revogação de CONNECT a partir de PUBLIC
db2 SELECT AUTHORITY, D_USER, D_GROUP, D_PUBLIC,
ROLE_USER, ROLE_GROUP, ROLE_PUBLIC, D_ROLE
FROM TABLE (SYSPROC.AUTH_LIST_AUTHORITIES_FOR_AUTHID ('EINSTEIN', 'U') ) AS T
ORDER BY AUTHORITY
AUTHORITY D_USER D_GROUP D_PUBLIC ROLE_USER ROLE_GROUP ROLE_PUBLIC D_ROLE
------------------------- ------ ------- -------- --------- ---------- ----------- ------
ACCESSCTRL N N N N N N *
BINDADD N N Y N N N *
CONNECT N N N N N N *
CREATETAB N N Y N N N *
CREATE_EXTERNAL_ROUTINE N N N N N N *
CREATE_NOT_FENCED_ROUTINE N N N N N N *
DATAACCESS N N N N N N *
DBADM N N N N N N *
EXPLAIN N N N N N N *
IMPLICIT_SCHEMA N N Y N N N *
LOAD N N N N N N *
QUIESCE_CONNECT N N N N N N *
SECADM N N N N N N *
SQLADM N N N N N N *
SYSADM * N * * * * *
SYSCTRL * N * * * * *
SYSMAINT * N * * * * *
SYSMON * N * * * * *
WLMADM N N N N N N *
19 record(s) selected. |
O usuário Einstein não tem mais autoridade de CONNECT a partir de nenhuma origem.
Agora, tente se conectar novamente.
Figura 4. A partir de 9.26.120.64 hotel48
Figura 5. A partir de 9.26.120.62 hotel46
O usuário Einstein não pode mais se conectar a partir de nenhum endereço IP.
Etapa 4: crie a função e o contexto confiável
Os comandos a seguir são executados como um usuário com autoridade de SECADM:
- Crie a função:
db2 create role connect_role - Dê a autoridade de CONNECT à função:
db2 grant CONNECT on database to role connect_role - Crie o contexto confiável:
db2 create trusted context connect_tc based upon connection using system authid einstein attributes(address '9.26.120.62') default role connect_role enable
Figura 6. Criando a função, conectando e criando o contexto confiável
Certifique-se de que o usuário Einstein possa se conectar a partir de IP 9.26.120.62 (hotel46), mas não a partir de IP 9.26.120.64 (hotel48).
Figura 7. A partir de 9.26.120.62 hotel46
Figura 8. A partir de 9.26.120.64 hotel48
Combinando os recursos de contextos confiáveis, funções e a autoridade de CONNECT, podemos controlar o local a partir do qual um usuário regular se conecta ao banco de dados. Observe que essa solução não se aplica aos superusuários SYSADM, SYSCTRL, SYSMAINT, SYSMON, DBADM e SECADM. Esses usuários têm autoridade de CONNECT implícita.
Aprender
- Saiba mais sobre funções de banco de dados no DB2 para Linux, UNIX e Windows.
- Obtenha mais informações sobre Contextos confiáveis e conexões confiáveis no DB2.
- Obtenha os detalhes sobre a função de tabela AUTH_LIST_AUTHORITIES_FOR_AUTHID.
- Obtenha uma visão geral das autoridades do DB2 para Linux, UNIX e Windows.
- Saiba mais sobre Information Management na zona do
Information Management no developerWorks. Encontre documentação técnica, artigos com instruções, educação, downloads, informações sobre produtos e mais.
- Fique por dentro doseventos técnicos e webcasts do developerWorks
.
- Siga o DeveloperWorks no Twitter.
Obter produtos e tecnologias
- Agora é possível usar o DB2 gratuitamente. Faça o download do
DB2 Express-C, uma versão gratuita do DB2 Express Edition para a comunidade que oferece os mesmos recursos de dados centrais que o DB2 Express Edition e fornece uma base sólida para desenvolver e implementar aplicativos.
- Crie seu próximo projeto de desenvolvimento com o Versão de teste do software IBM,
disponível para download diretamente no developerWorks.
- Agora é possível usar o DB2 gratuitamente. Faça o download do
DB2 Express-C, uma versão gratuita do DB2 Express Edition para a comunidade que oferece os mesmos recursos de dados centrais que o DB2 Express Edition e fornece uma base sólida para desenvolver e implementar aplicativos.
Discutir
- Participar do fórum de discussão.
- Confira os blogs do developerWorks
e participe da
comunidade do developerWorks.
Mihai Iacob trabalha há cinco anos como desenvolvedor de software no laboratório da IBM Toronto como integrante da equipe de desenvolvimento de segurança do DB2 para Linux, UNIX e Windows.
Igal Ziskind trabalha há sete anos como desenvolvedor de software no laboratório da IBM Toronto. É integrante da equipe de desenvolvimento de segurança do DB2 para Linux, UNIX e Windows. Antes de ocupar o cargo atual, era integrante da equipe de desenvolvimento do DB2 Up and Running.
Walid Rjaibi é Senior Technical Staff Member do Security Architecture Board Steering da IBM. É o Chief Security Architect do DB2 para Linux, UNIX e Windows (LUW) e supervisiona diretamente os aspectos técnicos e gerenciais da certificação de arquitetura, design, desenvolvimento e critérios comuns de todos os recursos de segurança do DB2 LUW. Isso inclui a identificação e autenticação, autorização, controle de acesso, mascaramento de dados, auditoria e criptografia.
Antes da função atual, Walid foi membro da equipe de pesquisa no Laboratório de Pesquisa da IBM em Zurique, na Suíça, onde estabeleceu e liderou um novo programa de pesquisa voltado para a segurança e privacidade de bancos de dados. Os resultados da pesquisa de Walid estabeleceram a base para aprimoramentos importantes na segurança do DB2 LUW. Ele liderou os esforços de desenvolvimento propriamente ditos ao voltar para o desenvolvimento do DB2 LUW em Toronto.
As principais realizações de Walid relacionadas à segurança de bancos de dados incluem a liderança da pesquisa e do desenvolvimento do controle de acesso baseado em rótulo, controle de acesso baseado na função, contextos confiáveis, separação de obrigações e controle de acesso com baixa granularidade. Seu trabalho teve como resultado vinte patentes e várias publicações em atas de conferências científicas importantes, como a International Conference on Very Large Databases (VLDB), a International Conference on Data Engineering (ICDE) e a International Conference on Security and Cryptography (SECRYPT).
