Configurando permissões para incorporação
Configurando permissões para incorporação
Você pode usar uma única instância do Analytics para gerenciar permissões para todos os seus clientes. A ferramenta de permissões do Analytics que você usa depende de como você armazena os dados dos seus clientes.
- Um banco de dados para todos os clientes (configurações com dados misturados)
- Um banco de dados por cliente
- Múltiplos schemas (um schema por cliente)
Um banco de dados para todos os clientes (configurações com dados misturados)
Se todos os dados dos seus clientes estiverem no mesmo schema e nas mesmas tabelas (frequentemente chamado de “data commingling”):
| Tenant_ID | Coluna 1 | Coluna 2 |
|---|---|---|
| A | … | … |
| B | … | … |
| C | … | … |
Você pode usar:
- Data sandboxing para restringir linhas e colunas.
- Impersonação de conexão para imitar papéis configurados no seu banco de dados. A impersonação é uma boa escolha se você quiser garantir acesso via SQL nativo aos seus dados.
Restrição de linhas com base no Tenant ID
Suponha que você tenha uma tabela chamada Data que se parece com esta:
| Tenant_ID | Métricas | Insights |
|---|---|---|
| A | … | … |
| B | … | … |
| C | … | … |
Para exibir uma versão filtrada da tabela Data para diferentes tenants baseada no Tenant_ID, você pode criar um sandbox básico.
Isso significa que o Tenant A verá as linhas onde Tenant_ID = A, e o Tenant B verá as linhas onde Tenant_ID = B.
Veja como o sandbox básico funcionará:
- Crie um grupo, por exemplo “Sandboxed Tenants”, e adicione as contas do Analytics dos usuários a esse grupo.
- Adicione um atributo de usuário. Para cada conta, adicione um atributo de usuário como
Tenant_ID, com o valor do atributo definido para “A”, “B” ou “C”. - Sandbox a tabela para o grupo para aplicar a segurança a nível de linha baseada em atributos de usuário.
Restrição de colunas com base na concessão
Suponha que a coluna Insights seja um recurso premium, e que o Tenant B seja o único cliente pagando para ver esses Insights.
| Tenant ID | Métricas | Insights |
|---|---|---|
| A | … | |
| B | … | … |
| C | … |
Para impedir que os Tenants A e C visualizem a coluna Insights, você pode criar um sandbox personalizado para restringir tanto as linhas quanto as colunas que eles podem ver quando acessam a tabela.
- Crie um grupo chamado “Metrics-Only Tenants”.
- Adicione os Tenants A e C ao grupo. Observe que, ao aplicar diferentes sandboxes na tabela Data para grupos diferentes, cada conta do Analytics deve pertencer a apenas um grupo.
- Adicione um atributo de usuário como
Tenant_ID, definindo-o como “A” ou “C”. -
Em seguida, crie uma consulta SQL usando a tabela Data, como esta:
SELECT Tenant_ID, Metrics FROM data WHERE Tenant_ID = {{ tenant_user_attribute }} - Salve essa consulta SQL como “Customer Metrics”.
- Crie um sandbox personalizado usando o grupo “Metrics-Only Tenants” e a consulta SQL “Customer Metrics”.
Quando, por exemplo, o Tenant A fizer login, ele verá apenas as colunas Tenant_ID e Metrics, e apenas as linhas onde Tenant_ID = A.
Impersonação permite que você gerencie acesso com papéis do banco de dados
A impersonação permite que você mapeie atributos de usuário para papéis do banco de dados, o que possibilita aplicar segurança a nível de linha usando os privilégios de banco de dados que você conceder a cada papel.
Confira este artigo sobre impersonação.
Um banco de dados por cliente
Se cada cliente possui seu próprio banco de dados, você pode usar database routing para alternar a fonte de dados para as consultas. Com o database routing, você precisa construir o dashboard apenas uma vez, e o Analytics trocará o banco de dados consultado dependendo de quem estiver logado.
Para que o database routing funcione, porém, os schemas em cada banco devem ser idênticos.
Para controlar de forma mais precisa o que os indivíduos podem visualizar, mesmo dentro dos mesmos tenants, você pode usar também outras ferramentas que o Analytics oferece, como data sandboxing e impersonação de conexão, em conjunto com o database routing.
Múltiplos schemas (um schema por cliente)
Se os dados dos seus clientes estiverem armazenados em tabelas separadas no mesmo schema ou em schemas diferentes dentro de um banco único, como neste exemplo:
Schema do Tenant A
| Tenant A | Coluna 1 | Coluna 2 |
|---|---|---|
| Linha 1 | … | … |
| Linha 2 | … | … |
| Linha 3 | … | … |
Schema do Tenant B
| Tenant B | Coluna 1 | Coluna 2 |
|---|---|---|
| Linha 1 | … | … |
| Linha 2 | … | … |
| Linha 3 | … | … |
Você pode:
- Conceder acesso self-service ou somente visualização ao schema.
- Conceder acesso via SQL nativo ao schema.
Diferente dos dados misturados, dados com um schema por cliente são incompatíveis com data sandboxing, porque um sandbox só pode aplicar permissões a nível de linha e coluna, não a nível de schema.
Concedendo aos clientes acesso self-service ou somente visualização ao seu schema
Suponha que você tenha um único banco de dados com dez tabelas diferentes, cada uma correspondendo a um cliente (empresa). Você deseja que cada cliente acesse apenas a sua própria tabela.
-
Crie um grupo para o seu primeiro cliente nas Configurações de Admin > Pessoas. Se precisar de diferentes níveis de permissões dentro da empresa (alguns funcionários podem criar perguntas, outros podem apenas visualizar), crie múltiplos grupos, como Empresa A (Self-service) e Empresa A (Somente visualização).
-
Conceda acesso à tabela acessando Permissões > Dados > Bancos de dados e concedendo ao novo grupo acesso à tabela do cliente. Se quiser que seus clientes criem perguntas e dashboards dentro da tabela deles, defina a permissão de Criar consulta para Construtor de consultas.
Para funcionários que só devem visualizar dados e criar coleções para essas perguntas e dashboards específicos, veja permissões para coleções.
Evite conceder acesso ao editor SQL nativo — isso permite que usuários consultem tabelas que não deveriam ver.
Se você restringir as permissões de cada grupo a uma única tabela, o Analytics ocultará quaisquer novas tabelas que você adicionar ao banco de dados.
-
Convide seu primeiro usuário e adicione-o ao grupo apropriado. Se estiver usando SSO, você pode pular esta etapa.
-
Repita o processo para cada cliente, seguindo os passos 1–3.
Concedendo aos clientes acesso via SQL nativo ao seu schema
Se você precisar que os clientes façam consultas SQL nativas:
-
Crie uma conta de usuário no banco para cada cliente (no seu banco de dados, não no Analytics). Esse usuário deve ter acesso apenas às suas tabelas ou schemas específicos. Para PostgreSQL, por exemplo, você pode adicionar um usuário via psql e conceder permissões somente para suas tabelas.
-
Conecte o Analytics ao seu banco usando a conta do usuário do banco que você criou. Veja bancos de dados.
-
Crie um novo grupo no Analytics e conceda a ele acesso à conexão de banco de dados. Como o papel do usuário do banco controla o que é visível, você pode conceder ao grupo acesso Pode visualizar no banco de dados e permissões para Construtor de consultas e SQL nativo. Veja grupos.
Os membros do grupo verão todas as tabelas que o usuário do banco pode acessar. Para ocultar tabelas no futuro, será necessário alterar as permissões no próprio banco, não no Analytics.
-
Convide seu primeiro usuário e adicione-o ao grupo adequado. Se estiver usando SSO, você pode pular esta etapa.
-
Repita o processo para cada cliente, seguindo os passos 1-4. Você terá tantas conexões de banco quanto clientes.
Leia a documentação para outras versões do Analytics.