Controle de acesso granular para streams de alteração

Esta página explica como o controle de acesso detalhado funciona com fluxos de mudanças do Spanner para bancos de dados com dialeto GoogleSQL e PostgreSQL.

Para usuários com controle de acesso detalhado, você permite o acesso de leitura para alterar os dados de streams usando as permissões a seguir. As duas concessões são obrigatórias.

  • Conceda SELECT no fluxo de alterações.

    GoogleSQL 

    GRANT SELECT ON CHANGE STREAM CHANGE_STREAM_NAME TO ROLE ROLE_NAME;

    PostgreSQL 

    GRANT SELECT ON CHANGE STREAM CHANGE_STREAM_NAME TO ROLE_NAME;

  • Conceda EXECUTE na função de leitura que é criada automaticamente para o fluxo de alterações. Use a função de leitura para ler registros de fluxo de mudança.

    GoogleSQL 

    GRANT EXECUTE ON TABLE FUNCTION READ_FUNCTION_NAME TO ROLE ROLE_NAME;

    PostgreSQL 

    GRANT EXECUTE ON FUNCTION READ_FUNCTION_NAME TO ROLE_NAME;

    Para informações sobre convenções de nomenclatura para funções de leitura de fluxo de alterações e formatação das informações retornadas, consulte estes tópicos:

Visualizações INFORMATION_SCHEMA para fluxos de alterações

As visualizações a seguir mostram informações sobre funções e privilégios do banco de dados para fluxos de mudanças:

As linhas nessas visualizações são filtradas com base nos privilégios de função do banco de dados atual em fluxos de mudanças. Isso garante que os participantes possam acessar apenas as funções, os privilégios e as mudanças de fluxo a que têm acesso.

A filtragem de linhas também se aplica às seguintes visualizações relacionadas a fluxos de mudanças:

GoogleSQL

A função do sistema spanner_info_reader e os membros dela sempre veem um INFORMATION_SCHEMA não filtrado.

PostgreSQL

A função do sistema spanner_info_reader e os membros dela têm acesso a uma information_schema não filtrada.

A filtragem de linha também se aplica às seguintes visualizações de metadados para funções de leitura de fluxo de mudanças:

GoogleSQL

PostgreSQL

Advertências

  • Os fluxos de alterações usam um banco de dados de metadados para manter o estado interno. O banco de dados de metadados pode ser igual ou diferente do banco de dados do aplicativo. Recomendamos que você use um banco de dados diferente. No entanto, para usuários de controle de acesso detalhado, o banco de dados de metadados não pode ser o mesmo que o banco de dados do aplicativo. Isso ocorre porque o principal do IAM que executa o job do Dataflow precisa de acesso de leitura ou gravação no nível do banco de dados para o banco de dados de metadados. Isso substituiria os privilégios de controle de acesso detalhados que foram configurados para o banco de dados do aplicativo.

    Para mais informações, consulte Considerar um banco de dados de metadados separado.

  • Como um fluxo de alterações contém uma cópia separada dos dados das tabelas e colunas rastreadas, tenha cuidado ao conceder aos usuários acesso ao fluxo de alterações. Os leitores do fluxo de mudanças podem conferir as alterações de dados das tabelas e colunas rastreadas, mesmo quando não têm privilégios SELECT nas tabelas e colunas. Embora seja mais flexível configurar controles separados em fluxos de mudanças e nas tabelas e colunas rastreadas, há um possível risco. Portanto, estruture os papéis e privilégios do banco de dados de acordo. Por exemplo, ao revogar o privilégio SELECT em uma tabela de uma função, considere revogar também SELECT no fluxo de mudanças e revogar EXECUTE na função de leitura associada.

  • Se você conceder SELECT em um fluxo de mudanças que rastreia todas as tabelas, o beneficiário poderá conferir as mudanças de dados de todas as tabelas adicionadas no futuro.

A seguir