Autorizações granulares ao nível do schema no Db2 11.5.5

Em versões anteriores ao Db2 11.5.5, conceder a um utilizador acesso abrangente a todos os objetos de um schema era difícil de fazer de forma cirúrgica. A alternativa prática era atribuir DBADM ou SECADM, autoridades que conferem acessos num âmbito muito maior do que o necessário. O Db2 11.5.5 resolve este problema com um conjunto de autoridades e privilégios específicos ao nível do schema, pensados de forma a implementar o Princípio do Menor Privilégio de forma direta.

Este artigo é deliberadamente prático. Cada passo abaixo mostra os comandos exatos a executar e as verificações a fazer. O lab foi pensado para ser reproduzido numa instância Db2 11.5.5 ou posterior.

O problema com o modelo anterior

O controlo de acesso no Db2 assenta em dois conceitos distintos: autoridades, que operam ao nível da instância ou da base de dados, e privilégios, que operam ao nível do objeto individual.

O problema clássico surgia quando uma equipa precisava de gerir ou aceder a todos os objetos de um schema específico. As opções disponíveis eram:

• Atribuir DBADM, que dá controlo sobre toda a base de dados
• Atribuir SECADM, que dá controlo sobre toda a política de segurança
• Conceder privilégios objeto a objeto, o que é operacionalmente pesado e difícil de manter quando o schema cresce

Nenhuma destas opções é boa. As primeiras duas violam o Princípio do Menor Privilégio. A terceira é correta em teoria mas impraticável quando um schema tem dezenas ou centenas de objetos.

O que este lab constrói

No fim do lab terá:

• uma base de dados de teste com um schema populado
• quatro utilizadores com perfis de acesso distintos
• a demonstração prática de cada nova autoridade de schema
• a demonstração dos novos privilégios de schema com um único GRANT
• testes de verificação que confirmam o que cada utilizador pode e não pode fazer
• uma consulta de auditoria sobre SYSCAT.SCHEMAAUTH

Pré-requisitos

Use uma instância Db2 em versão 11.5.5 ou posterior.

Também necessita de:

• Acesso shell com permissões de DBADM ou SECADM para criar utilizadores e conceder autoridades
• O CLP do Db2

Os utilizadores de sistema operativo referidos no lab devem existir no sistema antes de executar os GRANT. Execute os seguintes comandos como root para os criar:

useradd -m alice   && echo "alice:passw0rd"   | chpasswd
useradd -m thomas  && echo "thomas:passw0rd"  | chpasswd
useradd -m etl     && echo "etl:passw0rd"     | chpasswd
useradd -m secmgr  && echo "secmgr:passw0rd"  | chpasswd

1. Criar a base de dados e o schema de teste

Os passos seguintes devem ser executados pelo proprietário da instância Db2. Se SCHLAB já existir de uma execução anterior, elimine-a primeiro para garantir um estado limpo:

Crie a base de dados de teste e conecte-se à mesma:

db2 create database SCHLAB
db2 connect to SCHLAB

A definição do procedimento exige um terminador multi-instrução. Guarde o DDL num ficheiro e execute-o com db2 -td@:

cat > /tmp/schlab_ddl.sql <<'SQLEOF'
CREATE SCHEMA sales@

CREATE TABLE sales.customers (
  id        INTEGER NOT NULL,
  name      VARCHAR(100),
  email     VARCHAR(100),
  PRIMARY KEY (id)
)@

CREATE TABLE sales.orders (
  id          INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY,
  customer_id INTEGER,
  amount      DECIMAL(10,2),
  PRIMARY KEY (id)
)@

CREATE PROCEDURE sales.register_order (IN p_customer INTEGER, IN p_amount DECIMAL(10,2))
LANGUAGE SQL
BEGIN
  INSERT INTO sales.orders (customer_id, amount)
  VALUES (p_customer, p_amount);
END@
SQLEOF
db2 -td@ -f /tmp/schlab_ddl.sql

Insira alguns dados de teste:

db2 "INSERT INTO sales.customers VALUES (1, 'Alice Martin', '[email protected]')"
db2 "INSERT INTO sales.customers VALUES (2, 'Thomas Chen', '[email protected]')"
db2 "INSERT INTO sales.orders (customer_id, amount) VALUES (1, 150.00)"
db2 "INSERT INTO sales.orders (customer_id, amount) VALUES (2, 320.50)"
db2 commit

2. Criar os perfis de utilizador

Vamos trabalhar com quatro utilizadores que representam perfis reais:

Conceda CONNECT à base de dados a todos:

db2 "GRANT CONNECT ON DATABASE TO USER alice"
db2 "GRANT CONNECT ON DATABASE TO USER etl"
db2 "GRANT CONNECT ON DATABASE TO USER thomas"
db2 "GRANT CONNECT ON DATABASE TO USER secmgr"

3. SELECTIN: acesso de leitura ao schema completo

Antes desta funcionalidade, conceder leitura a todos os objetos do schema exigia um GRANT SELECT por cada tabela e View. Agora:

db2 "GRANT SELECTIN ON SCHEMA sales TO USER alice"

Verifique como alice:

db2 connect to SCHLAB user alice using passw0rd
db2 "SELECT * FROM sales.customers"
db2 "SELECT * FROM sales.orders"

Ambas as consultas devem funcionar. Confirme que alice não pode inserir dados:

db2 "INSERT INTO sales.customers VALUES (3, 'Test User', '[email protected]')"

Este comando deve falhar com SQL0551N: alice não tem INSERTIN nem INSERT direto sobre a tabela.

Termine a sessão:

db2 connect reset

4. INSERTIN e EXECUTEIN: pipeline ETL

O utilizador etl precisa de inserir dados e chamar o Stored Procedure, mas não deve conseguir ler dados existentes:

db2 connect to SCHLAB
db2 "GRANT INSERTIN ON SCHEMA sales TO USER etl"
db2 "GRANT EXECUTEIN ON SCHEMA sales TO USER etl"

Verifique como etl:

db2 connect to SCHLAB user etl using passw0rd
db2 "INSERT INTO sales.customers VALUES (3, 'New Customer', '[email protected]')"
db2 "CALL sales.register_order(3, 99.90)"
db2 commit

Ambos devem funcionar. Confirme que etl não pode ler os dados:

db2 "SELECT * FROM sales.customers"

Este comando deve falhar com SQL0551N.

Termine a sessão:

db2 connect reset

5. SCHEMAADM: controlo total sobre o schema

SCHEMAADM é a autoridade mais abrangente. Concede controlo total sobre o schema sem dar acesso ao resto da base de dados:

db2 connect to SCHLAB
db2 "GRANT SCHEMAADM ON SCHEMA sales TO USER thomas"
db2 "GRANT USE OF TABLESPACE USERSPACE1 TO USER thomas"

SCHEMAADM confere autoridade sobre os objetos do schema mas não inclui acesso a table spaces. O GRANT USE OF TABLESPACE é necessário para que thomas possa criar novas tabelas. Sem ele, o CREATE TABLE falha com SQL0286N.

Verifique como thomas:

db2 connect to SCHLAB user thomas using passw0rd
db2 "CREATE TABLE sales.campaigns (id INTEGER NOT NULL, name VARCHAR(100), PRIMARY KEY (id))"
db2 "GRANT SELECT ON TABLE sales.campaigns TO USER alice"
db2 "RUNSTATS ON TABLE sales.customers"

Todas estas operações devem funcionar. Confirme que thomas não tem acessos fora do schema:

db2 "CREATE TABLE public.test (id INTEGER)"

Este comando deve falhar porque thomas não tem autoridade sobre outros schemas.

Termine a sessão:

db2 connect reset

6. ACCESSCTRL - gestão de permissões sem acesso a dados

ACCESSCTRL ao nível do schema permite conceder e revogar permissões sobre objetos do schema sem dar acesso direto aos dados:

db2 connect to SCHLAB
db2 "GRANT ACCESSCTRL ON SCHEMA sales TO USER secmgr"

Verifique como secmgr:

db2 connect to SCHLAB user secmgr using passw0rd
db2 "GRANT SELECT ON TABLE sales.orders TO USER alice"
db2 "REVOKE SELECT ON TABLE sales.orders FROM USER alice"

Ambas as operações devem funcionar. Confirme que secmgr não consegue ler os dados:

db2 "SELECT * FROM sales.customers"

Este comando deve falhar com SQL0551N.

Termine a sessão:

db2 connect reset

7. Auditar as autorizações de schema

As concessões ao nível do schema são visíveis na View SYSCAT.SCHEMAAUTH. Consulte o estado atual:

db2 connect to SCHLAB
cat > /tmp/schauth.sql <<'SQLEOF'
SELECT
  GRANTEE,
  GRANTEETYPE,
  SCHEMANAME,
  SELECTINAUTH,
  INSERTINAUTH,
  UPDATEINAUTH,
  DELETEINAUTH,
  EXECUTEINAUTH,
  ALTERINAUTH,
  SCHEMAADMAUTH,
  ACCESSCTRLAUTH,
  DATAACCESSAUTH,
  LOADAUTH
FROM SYSCAT.SCHEMAAUTH
WHERE SCHEMANAME = 'SALES'
ORDER BY GRANTEE
;
SQLEOF
db2 -tvf /tmp/schauth.sql

Cada coluna mostra Y (concessão direta), G (concessão com capacidade de propagar) ou em branco (sem concessão). Esta consulta é o ponto de partida natural para uma auditoria de acessos ao schema.

8. Revogar autorizações

Todas as concessões são reversíveis com REVOKE:

db2 "REVOKE SELECTIN ON SCHEMA sales FROM USER alice"
db2 "REVOKE INSERTIN ON SCHEMA sales FROM USER etl"
db2 "REVOKE EXECUTEIN ON SCHEMA sales FROM USER etl"
db2 "REVOKE SCHEMAADM ON SCHEMA sales FROM USER thomas"
db2 "REVOKE USE OF TABLESPACE USERSPACE1 FROM USER thomas"
db2 "REVOKE ACCESSCTRL ON SCHEMA sales FROM USER secmgr"

9. Limpeza

Elimine a base de dados de teste e remova os utilizadores de sistema criados nos pré-requisitos:

db2 connect reset
db2 drop database SCHLAB

Remova os utilizadores de sistema como root:

userdel -r alice
userdel -r thomas
userdel -r etl
userdel -r secmgr

Principais conclusões

• O Db2 11.5.5 introduz autoridades de schema (SCHEMAADM, ACCESSCTRL, DATAACCESS, LOAD) que permitem delegar controlo total ou parcial sobre um schema sem atribuir DBADM ou SECADM.
• Os novos privilégios de schema (SELECTIN, INSERTIN, UPDATEIN, DELETEIN, EXECUTEIN) eliminam a necessidade de conceder permissões objeto a objeto.
• O modelo permite implementar o Princípio do Menor Privilégio de forma prática e auditável.
• A visibilidade das autorizações sobre o schema está disponível em SYSCAT.SCHEMAAUTH e as autorizações podem ser removidas através de REVOKE.

Documentação IBM útil

Para aprofundar, as referências IBM mais úteis para este tema são:

• Visão geral de autoridades
• Privilégios e autoridades de schema
• Uso do catálogo do sistema para informação de segurança
• REVOKE para privilégios e autoridades de schema