Data

6 mar, 2014

Administração do DB2 em Ambiente UNIX – Parte 07

Publicidade

Encerrado o período de férias, estamos voltando à nossa série de artigos. Nesta aula eu falo sobre os tipos de privilégios no DB2 e como atribuir ou retirar tais privilégios.

Recomendo ao leitor interessado em acompanhar o curso que acesse o portal do DB2 para abaixar uma cópia do DB2 Express-C, edição gratuita do produto, ou então para obter instruções de como acessar e configurar uma instalação do DB2 rodando na nuvem. Para mais detalhes, clique aqui.

AULA 7 – Autorizações, privilégios e papéis

Depois que autentica o usuário que está se conectando ao banco de dados, o DB2 passa a verificar as autorizações que este indivíduo recebeu. Isso define o que este usuário é capaz de fazer dentro do banco de dados e/ou da instância do DB2.

A estrutura de autorizações do DB2 envolve três tipos de entidades:

  • Os administradores da segurança, que atribuem autorizações;
  • Os agentes, ou seja, os usuários e/ou grupos de usuários que recebem autorizações;
  • Os “segurados”, que englobam os objetos do banco de dados e da instância sobre os quais se dá ou retira autorizações (exemplo: tabelas, esquemas, visões, etc.).

Existem vários níveis e interações entre os tipos de autorizações que se pode dar ou revogar, mas sempre teremos estas três entidades envolvidas no processo.

Tipos de autorização

Existem quatro tipos de autorizações no DB2:

  1. Permissões primárias: quando o administrador garante a autorização diretamente para um ID de usuário sobre os “segurados”. (Agente=indivíduo);
  2. Permissões secundárias: quando se dá autorização para grupos de usuários e/ou papéis aos quais o usuário está associado. (Agente=grupo);
  3. Permissões públicas: aquelas autorizações que dão acesso para todo e qualquer usuário que tenha acesso ao banco de dados. (Agente=qualquer um que se conecte ao banco);
  4. 4.      Permissões sensíveis ao contexto: permissões atribuídas a uma conexão ou contexto confiável, como por exemplo, as permissões dadas a um servidor de aplicação externo.  (Agente=usuário e/ou serviço que se conecta através de uma conexão confiável).

 Autoridades versus privilégios

Quando falamos de autorizações, estamos pensando no conjunto de “direitos” ou “permissões” dadas a um usuário e/ou grupo de usuários.

Estas autorizações podem ser atribuídas de duas maneiras:

  • Atribuindo privilégios sobre cada objeto individual, usando os comandos GRANT e REVOKE. Costumamos chamar estas autorizações de granulares, porque dão ao administrador controle sobre cada objeto da base. A seguir veremos detalhes de como administrar estes privilégios;
  • Através de acesso a conjuntos específicos de ações que são reunidas dentro de “pacotes” chamados autoridades (que serão tratadas em detalhe no próximo artigo desta série). As autoridades mais conhecidas do DB2 são o SYSADM, que atua como o administrador de toda instância, e DBADM, que é o “proprietário” de um banco de dados.

 Tipos de privilégios

DB2 reconhece vários tipos de privilégios, como privilégios sobre tabelas, visões, tablespaces, esquemas, pacotes, índices, sequência, rotinas, etc.

Para o DBA iniciante, é importante reconhecer ao menos os privilégios mais básicos, listados a seguir:

Privilégios de esquema: permite que o usuário execute ações dentro de um dado esquema do banco. Este tipo engloba apenas três privilégios.

  1. 1.1.  CREATEIN   – permite que se crie objetos dentro do esquema
  2. 1.2.  ALTERIN      – permite que se altere objetos do esquema
  3. 1.3.  DROPIN       – permite que se exclua objetos do esquema

Privilégios de tablespace: permite ações ao nível de tablespace. Aqui temos apenas o privilégio USE, que libera a criação de tabelas usando o tablespace especificado no privilégio.

Privilégios de tabela e visão: aqui temos uma série de privilégios que possibilitam ações específicas com tabelas e/ou visões. São eles:

  1. 3.1.  DELETE – privilégio de excluir registros de uma tabela ou visão
  2. 3.2.  INSERT – privilégio de inserir registros numa tabela ou visão
  3. 3.3.  SELECT – privilégio de selecionar registros de uma tabela ou visão
  4. 3.4.  UPDATE – privilégio de alterar registros de uma tabela ou visão
  5. 3.5.  ALTER – privilégio de alterar a definição de uma tabela
  6. 3.6.  INDEX – privilégio de criar índices sobre uma tabela
  7. 3.7.  REFERENCES – privilégio de criar ou excluir chaves estrangeiras (em outras tabelas) definindo a tabela referenciada como tabela pai
  8. 3.8.  CONTROL – libera todos os privilégios possíveis sobre uma tabela ou visão (listados anteriormente); isso considera também o privilégio de excluir o objeto e atribuir a terceiros privilégios sobre o objeto em questão (ou mesmo revogar tais privilégios).

Concedendo e revogando privilégios

Apesar de parecer extremamente simples, nem sempre é tão óbvio identificar a forma como um privilégio foi concedido ou revogado.

Os privilégios são evidentes quando atribuídos ou revogados diretamente. Isso é chamado de privilégios explícitos. Exemplo: garantir direito de leitura e excluir direito de INSERT sobre a tabela “meuesquema.tabelaXPTO” para todos os usuários do grupo “OsCaras”

wc

Mas existem também os privilégios implícitos. São privilégios herdados automaticamente no momento em que executamos certas ações.

Exemplo: o usuário WCRIVELINI tem privilégio de criar tabelas no esquema “esquema1” e assim que ele cria a tabela “esquema1.minhatabela”, automaticamente está recebendo o privilégio de ter controle completo sobre esta tabela  (INSERT, DELETE, UPDATE, SELECT, INDEX, etc).

wc1

Finalmente existem os privilégios indiretos, ou seja, quando recebemos privilégios para executar uma ação que implica na execução de outras ações. Isso acontece com muita frequência e é muito fácil de entender. Exemplo: usuário WCRIVELINI recebe direito de execução do procedimento armazenado “esquema1.spInsereDados” e este procedimento insere dados nas tabelas ta1,tab2 e tab3. Portanto indiretamente WCRIVELINI recebe direito de inserção nestas tabelas também.

wc2

Por hoje é só. Em breve teremos a AULA 8 desta série tratando das autoridades do DB2. Até lá.

Referências

O leitor interessado encontrará informações mais detalhadas nas seguintes referências.

“A primeira qualidade de um bom DBA é ser um bom pesquisador”.