No Couchbase 4.5, os dados eram protegidos bucket por bucket. Cada bucket tinha uma senha e, para acessar um bucket por meio de uma consulta N1QL, o usuário precisava incluir a senha do bucket na consulta. Os buckets sem senha eram possíveis, mas não eram recomendados para uso em produção.
Esse esquema oferecia proteção básica, mas era muito grosseiro: um usuário podia fazer tudo com um compartimento ou nada. Além disso, as consultas que acessavam muitos compartimentos exigiam a inserção de uma senha para cada compartimento, o que era inconveniente, principalmente se as senhas fossem alteradas.
Para permitir que nossos usuários evitem esses problemas, introduzimos o controle de acesso baseado em função (RBAC) no Couchbase Server 5.0. O acesso aos dados agora é controlado por meio de funções refinadas em buckets, e cada usuário pode receber funções que se ajustam ao que ele realmente deve fazer no banco de dados.
Neste artigo, apresentarei a você as principais funcionalidades oferecidas pelo RBAC no Couchbase Server 5.0. Exercícios práticos permitirão que você experimente os novos recursos por conta própria.
Configuração
Para os exercícios práticos, você precisará instalar o Couchbase Server 5.0, Enterprise Edition. Durante a instalação, configure-o para ter um administrador chamado "Administrator" com a senha "password". Obviamente, essa não é uma prática recomendada em um ambiente de produção.
Faça login no console de administração (em http://localhost:8091) e vá para a tela Buckets. Crie dois buckets, "testbucket1" e "testbucket2", cada um com uma cota de memória de 100 MB para evitar o esgotamento da memória.
Em seguida, vá para a tela Query (Consulta) e crie índices primários nos dois buckets que acabou de criar. Os índices primários permitem que você execute consultas nos buckets.
|
1 2 |
CRIAR PRIMÁRIO ÍNDICE ON balde de teste1 CRIAR PRIMÁRIO ÍNDICE ON testbucket2 |
Você pode acessar a tela Índices para verificar se os índices foram realmente criados. Ambos terão o nome "#primary".
Principais funções
Há quatro funções principais que controlam quem pode executar quais consultas N1QL. As funções query_select, query_insert, query_update e query_delete permitem que você execute consultas N1QL do tipo correspondente. Há também três funções mais especializadas (query_manage_index, query_system_catalog e query_external_access) que serão abordadas na próxima seção, Funções adicionais importantes.
Mas há mais do que isso. Essas funções são parametrizadas pelo bucket ao qual se aplicam. Um usuário não pode ter apenas a função query_select; precisamos saber em qual bucket a função está, como query_select[testbucket1], que permite que o usuário execute uma consulta SELECT no testbucket1. Também é possível ter essa função em todos os buckets, indicado por query_select[*].
Para tentar fazer isso, acesse o console do Couchbase e, na tela Segurança, crie um novo usuário user1 com a senha "password" e a função query_select[testbucket1].
A função pode ser encontrada em "Query Roles" (Funções de consulta) no menu de criação de usuários.
Em seguida, faça o mesmo para "user2", mas dê a esse usuário query_select[testbucket2].
Agora vamos tentar executar uma consulta nesses buckets usando as funções. Usarei a ferramenta de shell CBQ que vem com o Couchbase.
|
1 |
cbq -e http://localhost:8093/ -s "select * from testbucket1" |
Isso nos leva a essa resposta:
|
1 2 3 4 5 6 7 8 9 |
{ "requestID": "d838da35-24a3-415e-b9e1-69ac02a9820b", "assinatura": {"*":"*"}, "resultados": [ ], "erros": [{"código":13014,"msg":"O usuário não tem credenciais para executar consultas SELECT no bucket testbucket1. Adicione a função query_select em testbucket1 para permitir que a consulta seja executada."}], "status": "parado", "métricas": {"elapsedTime" (tempo decorrido): "4.214692ms","executionTime": "4.190101ms","resultCount": 0,"resultSize": 0,"errorCount": 1} } |
Observe que o erro nos diz claramente qual é a função que está faltando. Vamos tentar novamente com o usuário1, que tem a função correta:
|
1 |
cbq -e http://localhost:8093/ -s "select * from testbucket1" -u user1 -p password |
Isso funcionou:
|
1 2 3 4 5 6 7 8 |
{ "requestID": "caeba7de-d9eb-4e2f-8f67-d6e795fb1dbd", "assinatura": {"*":"*"}, "resultados": [ ], "status": "sucesso", "métricas": {"elapsedTime" (tempo decorrido): "11.501861ms","executionTime": "11.471201ms","resultCount": 0,"resultSize": 0} } |
Tente você mesmo fazer a consulta com o usuário2, que tem a função correta, mas no bucket errado. A solicitação falhará.
Agora, vamos tentar uma consulta mais complexa que toque em dois compartimentos. Comece executando esta consulta:
|
1 2 3 |
cbq -e http://localhost:8093/ -s "INSERT INTO testbucket2 (KEY source.c_id, VALUE source.customer) SELECT * FROM testbucket1 source WHERE source.new = true" |
O sistema nos informa que precisa da função query_insert[testbucket2]:
|
1 2 |
"erros": [{"código":13014,"msg":"O usuário não tem credenciais para executar consultas INSERT no bucket testbucket2. Adicione a função query_insert no testbucket2 para permitir que a consulta seja executada."}], |
Crie um novo usuário "user3" com a função necessária e tente novamente:
|
1 2 |
"erros": [{"código":13014,"msg":"O usuário não tem credenciais para executar consultas SELECT no bucket testbucket1. Adicione a função query_select no testbucket1 para permitir que a consulta seja executada."}], |
Ainda estamos recebendo um erro, mas é um erro diferente do anterior. A consulta que estamos tentando executar tem duas partes: ela seleciona no testbucket1 e insere no testbucket2. Fornecemos credenciais suficientes para a inserção, mas não para a seleção. Vá para o console, adicione query_select[testbucket2] ao user3 e tente novamente. Dessa vez, a consulta funciona.
|
1 2 3 4 5 6 7 8 |
{ "requestID": "3c313c29-8b67-4e63-92b0-763586345f59", "assinatura": nulo, "resultados": [ ], "status": "sucesso", "métricas": {"elapsedTime" (tempo decorrido): "11.451689ms","executionTime": "11.415157ms","resultCount": 0,"resultSize": 0} } |
Vamos tentar mais uma vez. Adicione uma cláusula RETURNING à consulta e tente executá-la:
|
1 2 3 |
cbq -e http://localhost:8093/ -s "INSERT INTO testbucket2 (KEY source.c_id, VALUE source.customer) SELECT * DE balde de teste1 fonte ONDE fonte.novo = verdadeiro RETORNO meta().id id" -u usuário3 -p senha |
Isso falha:
|
1 2 |
"erros": [{"código":13014,"msg":"O usuário não tem credenciais para executar consultas SELECT no bucket testbucket2. Adicione a função query_select no testbucket2 para permitir que a consulta seja executada."}], |
O que está acontecendo aqui é que a cláusula RETURNING está sendo tratada como um SELECT no bucket em que inserimos (testbucket2), ocorrendo logo após a inserção. O usuário não tem a função query_select[testbucket2] e, portanto, está sendo recusado.
Adicione a função query_select[testbucket2] ao user3 e execute novamente a consulta. Agora ela funcionará.
Funções adicionais importantes
Há mais três funções que você deve conhecer ao trabalhar com o N1QL.
gerenciar índice de consulta
Primeiro, vamos tentar criar um índice:
|
1 |
cbq -e http://localhost:8093/ -s "CREATE INDEX test_idx ON testbucket1(price)" |
Isso gera um erro:
|
1 2 3 |
"erros": [{"código":13014,"msg":"O usuário não tem credenciais para executar operações de índice. Adicione a função query_manage_index em testbucket1 para permitir que a consulta seja executada."}], "status": "parado", |
A função Query Manage Index (Gerenciar índice de consulta) em um bucket é necessária para criar, excluir ou construir índices nesse bucket.
Crie um novo usuário "user4" com a função query_manage_index[testbucket1]. Experimente o criação de índices novamente. A consulta agora funcionará.
|
1 2 |
cbq -e http://localhost:8093/ -s "CREATE INDEX test_idx ON testbucket1(price)" -u usuário4 -p senha |
catálogo_do_sistema de consulta
Nas versões anteriores do Couchbase, as tabelas do sistema eram totalmente acessíveis a qualquer pessoa. Agora, elas são mais restritas de várias maneiras que serão descritas posteriormente neste documento, mas há uma função útil, query_system_catalog, que permite o acesso às tabelas do sistema. Isso é particularmente útil para a equipe que precisa depurar problemas com consultas ou com o sistema, mas não deve receber privilégios totais de administrador.
Se consultarmos system:keyspaces como administrador, veremos os dois compartimentos que criamos no sistema:
|
1 |
cbq -e http://localhost:8093/ -s "SELECT * FROM system:keyspaces" -u Administrator -p password |
|
1 2 3 4 5 6 7 8 9 10 |
{ "requestID": "46ee066e-25f6-4bef-a70a-553f4c224c39", "assinatura": {"*":"*"}, "resultados": [ {"espaços-chave":{"datastore_id":"http://127.0.0.1:8091","id":"testbucket2","name" (nome):"testbucket2","namespace_id":"default"}}, {"espaços-chave":{"datastore_id":"http://127.0.0.1:8091","id":"testbucket1","name" (nome):"testbucket1","namespace_id":"default"}} ], "status": "sucesso", "métricas": {"elapsedTime" (tempo decorrido): "16.562026ms","executionTime": "16.52656ms","resultCount": 2,"resultSize": 238} } |
Mas se executarmos a mesma consulta sem credenciais, os resultados serão filtrados:
|
1 2 3 4 5 6 7 8 9 |
{ "requestID": "932e6b73-3058-4877-8da1-1715b16e53f5", "assinatura": {"*":"*"}, "resultados": [ ], "avisos": [{"código":11011,"msg":"Um ou mais documentos foram excluídos do compartimento system:keyspaces devido a permissões de usuário insuficientes."}], "status": "sucesso", "métricas": {"elapsedTime" (tempo decorrido): "20.563024ms","executionTime": "20.532213ms","resultCount": 0,"resultSize": 0,"warningCount": 1} } |
Crie um novo usuário "user5" com a função query_system_catalog e execute novamente a consulta. Você verá os mesmos resultados de quando executamos a consulta como Administrador.
Acesso externo à consulta
A nova função CURL() possibilita a consulta de serviços REST a partir do N1QL. Para usar a função, precisamos fazer algumas configurações e executar a consulta usando a nova função query_external_access.
Vamos tentar a consulta primeiro:
|
1 2 3 |
cbq -e http://localhost:8093/query/service -s 'SELECT CURL("https://maps.googleapis.com/maps/api/geocode/json", {"data": "address=Half+Moon+Bay", "get":true}) GEO' |
A consulta é recusada porque as permissões apropriadas não foram fornecidas:
|
1 2 |
"erros": [{"código":13014,"msg":"O usuário não tem credenciais para executar consultas usando a função CURL(). Adicione a função query_external_access para permitir que a consulta seja executada."}] |
Crie um usuário "user6" com a função query_external_access e execute novamente a consulta usando esse usuário. Desta vez, a consulta se recusa a ser executada porque não ativamos o CURL(); por motivos de segurança, ele é desativado por padrão.
Crie um arquivo "curl_whitelist.json" com o seguinte conteúdo:
|
1 |
{"all_access":verdadeiro} |
Coloque-o no diretório do couchbase. Em um Mac, o local exato é "/Applications/Couchbase Server.app/Contents/Resources/couchbase-core/var/lib/couchbase/n1qlcerts/curl_whitelist.json". Em outros sistemas, o local é ligeiramente diferente. Tente a consulta novamente, que deve ser executada corretamente, baixando dados como este:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
"address_components" (componentes de endereço) : [ { "long_name" : "Half Moon Bay", "short_name" : "Half Moon Bay", "tipos" : [ "localidade", "política" ] }, { "long_name" : "Condado de San Mateo", "short_name" : "Condado de San Mateo", "tipos" : [ "administrative_area_level_2", "política" ] }, { "long_name" : "Califórnia", "short_name" : "CA", "tipos" : [ "administrative_area_level_1", "política" ] }, { "long_name" : "Estados Unidos", "short_name" : "EUA", "tipos" : [ "país", "política" ] } |
A lista completa das funções N1QL é a seguinte:
| Função | Permissões | Sintaxe GRANT |
| Seleção de consulta | Declarações SELECT | GRANT select ON testbucket TO myuser |
| Inserção de consulta | Declarações INSERT | GRANT insert ON testbucket TO myuser |
| Atualização da consulta | Declarações de atualização | GRANT update ON testbucket TO myuser |
| Consulta Excluir | Declarações DELETE | GRANT delete ON testbucket to myuser |
| Consultar o catálogo do sistema | Acesso aos espaços de chave do sistema | GRANT query_system_catalog TO myuser |
| Consulta Gerenciar índice | Operações de índice | GRANT query_manage_index ON testbucket TO myuser |
| Consulta de acesso externo | Função CURL() | GRANT query_external_access TO myuser |
EXPLICAR e PREPARAR
É claro que podemos fazer outras coisas com as consultas além de apenas executá-las. Podemos usar o EXPLAIN para entender como o mecanismo de consulta calcula uma consulta. E podemos usar o PREPARE para configurar uma consulta para execução repetida.
No Couchbase 5.0, as permissões para EXPLAIN e PREPARE são simples. Elas são as mesmas que as permissões necessárias para a declaração subjacente. Isso é tudo o que há para fazer.
Para testar isso, vamos tentar EXPLORAR uma instrução SELECT simples, a mesma que usamos na seção anterior "Funções primárias":
|
1 |
cbq -e http://localhost:8093/ -s "explain select * from testbucket1" |
Em resposta, recebemos uma mensagem de erro solicitando uma função específica:
|
1 2 |
"erros": [{"código":13014,"msg":"O usuário não tem credenciais para executar consultas SELECT no bucket testbucket1. Adicione a função query_select no testbucket1 para permitir que a consulta seja executada."}], |
Vamos fornecer um usuário com essa função:
|
1 |
cbq -e http://localhost:8093/ -s "explain select * from testbucket1" -u user1 -p password |
Sucesso, assim como vimos para a própria declaração em "Funções primárias".
Agora vamos tentar PREPARAR a segunda declaração de "Primary Roles":
|
1 2 3 |
cbq -e http://localhost:8093/ -s "PREPARE INSERT INTO testbucket2 (KEY source.c_id, VALUE source.customer) SELECT * FROM testbucket1 source WHERE source.new = true" |
Recebemos a mesma mensagem de erro que recebemos originalmente para a declaração em si:
|
1 2 |
"erros": [{"código":13014,"msg":"O usuário não tem credenciais para executar consultas INSERT no balde testbucket2. Adicione a função query_insert no testbucket2 para permitir que a consulta seja executada."}], |
E se adicionarmos um usuário com credenciais para SELECT e INSERT, o PREPARE será bem-sucedido:
|
1 2 3 4 5 |
cbq -e http://localhost:8093/ -s "PREPARE INSERT INTO testbucket2 (KEY source.c_id, VALUE source.customer) SELECT * FROM testbucket1 source WHERE source.new = true" -u usuário3 -p senha |
CONCESSÃO e REVOGAÇÃO
Na versão 5.0, o N1QL inclui comandos para conceder funções aos usuários (GRANT) e para retirá-las (REVOKE). Esses comandos exigem permissão de administrador para serem executados.
Antes de experimentar essas declarações, vamos analisar quais usuários estão configurados e quais funções eles têm. Veja o que você deve ver na tela Security (Segurança) do console do Couchbase.
Podemos conceder uma nova função cluster_admin ao usuário1 da seguinte forma:
|
1 |
cbq -e http://localhost:8093/ -s "grant cluster_admin to user1" -u Administrator -p password |
Isso será bem-sucedido e, logo em seguida, o console do Couchbase será atualizado para refletir a nova atribuição de função.
Também podemos atribuir funções parametrizadas, como esta:
|
1 2 3 4 |
cbq -e http://localhost:8093/ -s "grant query_insert on testbucket2 to user2" -u Administrador -p senha |
Podemos desfazer a concessão inicial por meio de um REVOKE:
|
1 |
cbq -e http://localhost:8093/ -s "revoke cluster_admin from user1" -u Administrator -p password |
Todos esses parâmetros podem receber listas de argumentos:
|
1 2 3 4 |
cbq -e http://localhost:8093/ -s "grant query_insert, query_delete on testbucket1, testbucket2 to user5, user6" -u Administrador -p senha |
E, por fim, o prefixo query_ é opcional para query_insert, query_update, query_delete e query_select, tornando parte da sintaxe mais familiar:
|
1 2 |
cbq -e http://localhost:8093/ -s "grant insert,delete on testbucket1 to user4" -u Administrador -p senha |
Comparação com a Oracle
O controle de acesso baseado em função no Couchbase 5.0 foi projetado para ser familiar aos profissionais que já usaram o controle de acesso em outros sistemas de banco de dados atuais. A esta altura, você já deve ter reconhecido conceitos familiares, como as permissões de inserção/seleção/atualização/exclusão aplicáveis a buckets, que são como tabelas. Além disso, a noção de usuários administradores com permissões amplas deve ser familiar. O controle de acesso baseado em função no Couchbase 5.0 foi projetado para ser familiar aos profissionais que usaram o controle de acesso em outros sistemas de banco de dados atuais. A esta altura, você já deve ter reconhecido conceitos familiares, como as permissões de inserção/seleção/atualização/exclusão aplicáveis aos buckets, que são como tabelas. Além disso, a noção de usuários administradores com permissões amplas deve ser familiar.
Por exemplo, essa consulta GRANT funcionará tanto no Couchbase quanto no Oracle:
|
1 |
CONCESSÃO selecionar, inserir ON padrão PARA jlarson, pedestres |
Uma diferença conceitual entre o Couchbase e outros sistemas, como o Oracle, é que temos um modelo binário de privilégio: usuários e funções. Eles normalmente têm um modelo trinário, com usuários, funções e privilégios. Dessa forma, conceder permissões aos usuários no Oracle é conceder privilégios em objetos aos usuários. No Couchbase, trata-se de conceder funções parametrizadas aos usuários.
As funções são estáticas na versão 5.0. Não há declarações equivalentes a CREATE/DROP/ALTER ROLE.
As permissões do Couchbase estão no sistema como um todo ou nos buckets. Não temos noção de permissões em tabelas, colunas ou coleções.
No Couchbase, GRANT e REVOKE só são possíveis para usuários administradores. Não existe uma OPÇÃO DE ADMIN ou uma OPÇÃO DE GRANT. Para alterar as permissões, você precisa ser um administrador.
Por fim, não temos equivalente a SET ROLE. SET ROLE é um comando em nível de sessão, o que não faz sentido no Couchbase porque não temos sessões, apenas solicitações RESTful individuais.
Novos espaços-chave do sistema
O Couchbase 5.0 apresenta três novos espaços de chave do sistema relacionados aos usuários. O primeiro deles é system:user_info. Esse espaço de chave lista os usuários configurados no sistema, incluindo suas funções. Vamos tentar uma consulta:
|
1 |
cbq -e http://localhost:8093/ -s "select * from system:user_info" -u Administrator -p password |
Isso nos dá sete entradas como esta, uma para cada usuário que configuramos, mais o Administrador configurado:
|
1 2 3 |
{"user_info":{"domínio":"local","id":"user4","name" (nome):"Usuário4","funções":[{"bucket_name":"testbucket1","função":"query_manage_index"},{"bucket_name":"testbucket1","função":"inserir"},{"bucket_name":"testbucket1","função":"delete"}]}}, {"user_info":{"domínio":"local","id":"user2","name" (nome):"Usuário 2","funções":[{"bucket_name":"testbucket2","função":"selecionar"},{"bucket_name":"testbucket2","função":"inserir"}]}}, {"user_info":{"domínio":"local","id":"user5","name" (nome):"Usuário5","funções":[{"bucket_name":"testbucket2","função":"inserir"},{"bucket_name":"testbucket1","função":"inserir"},{"bucket_name":"testbucket2","função":"delete"},{"bucket_name":"testbucket1","função":"delete"},{"função":"query_system_catalog"}]}}, |
O espaço-chave system:applicable_roles é semelhante, mas divide cada função de usuário em uma entrada separada, produzindo uma visão mais relacional dos dados:
|
1 2 3 4 |
cbq -e http://localhost:8093/ -s "select * from system:applicable_roles where grantee = 'user3'" -u Administrador -p senha |
|
1 2 3 4 5 |
"resultados": [ {"applicable_roles":{"bucket_name":"testbucket2","donatário":"user3","função":"selecionar"}}, {"applicable_roles":{"bucket_name":"testbucket1","donatário":"user3","função":"selecionar"}}, {"applicable_roles":{"bucket_name":"testbucket2","donatário":"user3","função":"inserir"}} ], |
Por fim, o espaço-chave system:my_user_info mostra a parte do system:my_user_info correspondente ao usuário cujas credenciais são passadas com a consulta.
|
1 |
cbq -e http://localhost:8093/ -s "select * from system:my_user_info" -u user3 -p password |
|
1 2 3 4 |
"resultados": [ {"my_user_info":{"domínio":"local","id":"user3","name" (nome):"Usuário 3", "funções":[{"bucket_name":"testbucket2","função":"selecionar"},{"bucket_name":"testbucket1","função":"selecionar"},{"bucket_name":"testbucket2","função":"inserir"}]}} ], |
Acesso aos espaços-chave do sistema
De acordo com uma filosofia geral de operação segura, os espaços de chave do sistema (buckets) são protegidos na versão 5.0. O grau de restrição varia de acordo com os dados presentes em cada espaço de chave.
Três espaços de chaves não têm nada que possa ser valioso para um invasor:
- sistema:armazenamentos de dados
- sistema:namespaces
- sistema: duplo
Dessa forma, esses espaços de chaves não são protegidos. Não são necessárias credenciais para acessá-los.
|
1 |
cbq -e http://localhost:8093/query/service -s "select * from system:datastores" |
|
1 2 3 |
"resultados": [ {"datastores":{"id":"http://127.0.0.1:8091","url":"http://127.0.0.1:8091"}} ], |
No outro extremo da segurança estão system:user_info e system:applicable_roles, que contêm a lista de usuários e suas funções. Elas podem ser acessadas apenas por usuários Admin e Read Only Admin. A tabela system:my_user_info é semelhante, mas mostra apenas as informações relevantes para o usuário cujas credenciais são apresentadas com a consulta. Já exploramos essas tabelas acima.
Os próximos quatro espaços de chave do sistema contêm uma variedade de informações de tempo de execução e configuração.
- Sistema: preparações
- Sistema:completed_requests
- Sistema:active_requests
- Sistema: nós
Como as informações nelas contidas não são tão confidenciais quanto as informações do usuário, elas podem ser visualizadas mais amplamente. Eles podem ser acessados pela maioria dos administradores, mesmo os menores: Admin, Read Only Admin, Cluster Admin, Query System Catalog, Replication Admin, Bucket Admin (qualquer bucket) ou Views Admin (qualquer bucket).
Vamos tentar olhar para system:prepareds como user5, o usuário que criamos com a permissão Query System Catalog, acima.
|
1 |
cbq -e http://localhost:8093/ -s "select * from system:prepareds" -u user5 -p password |
Isso nos mostra uma declaração preparada que criamos anteriormente.
O espaço de chave system:keyspaces mostra a lista de buckets configurados no sistema. Essas informações são um tanto sensíveis, pois fornecem ao invasor informações sobre a finalidade do uso do sistema. Dessa forma, os usuários com funções de alto nível (Admin, Read Only Admin, Cluster Admin) veem tudo o que está nesse espaço de chave. Os usuários com a função Query System Catalog também veem tudo, pois essa função é destinada à depuração de problemas de consulta. Para outros usuários, a visualização é filtrada; o usuário vê apenas os espaços-chave para os quais tem permissão query_select.
Por exemplo, uma consulta a system:keyspaces sem credenciais será bem-sucedida, mas não mostrará nenhuma entrada:
|
1 |
cbq -e http://localhost:8093/ -s "select * from system:keyspaces" |
|
1 2 3 |
"resultados": [ ], |
Adicione credenciais para o usuário5, que tem a função Query System Catalog, e todas as entradas são mostradas:
|
1 |
cbq -e http://localhost:8093/ -s "select * from system:keyspaces" -u user5 -p password |
|
1 2 3 4 |
"resultados": [ {"espaços-chave":{"datastore_id":"http://127.0.0.1:8091","id":"testbucket1","name" (nome):"testbucket1","namespace_id":"default"}}, {"espaços-chave":{"datastore_id":"http://127.0.0.1:8091","id":"testbucket2","name" (nome):"testbucket2","namespace_id":"default"}} ], |
Use as credenciais para user1, que tem apenas query_select[testbucket1], e você verá apenas a entrada para testbucket1.
|
1 |
cbq -e http://localhost:8093/ -s "select * from system:keyspaces" -u user1 -p password |
|
1 2 3 |
"resultados": [ {"espaços-chave":{"datastore_id":"http://127.0.0.1:8091","id":"testbucket1","name" (nome):"testbucket1","namespace_id":"default"}} ], |
O espaço de chave system:indexes é tratado de forma muito semelhante a system:keyspaces: as funções de alto nível permitem acesso completo, enquanto a função query_select permite acesso filtrado. A diferença real é que a função query_manage_index permite acesso filtrado, como query_select.
Proteção para APIs de administração
O mecanismo de consulta N1QL tem APIs RESTful correspondentes a três dos espaços-chave do sistema: system:prepareds, system:completed_requests e system:active_requests. Elas costumavam ser abertas no Couchbase 4.6, mas agora estão protegidas. Eles exigem as mesmas credenciais que os espaços de chave.
|
1 |
enrolar http://localhost:8093/admin/prepareds |
|
1 2 3 4 |
{"chamador":"auth:268", "código":13014,"chave":"datastore.couchbase.insufficient_credentiasl", "mensagem":"O usuário não tem credenciais para executar consultas que acessam as tabelas do sistema. Adicione a função query_system_catalog para permitir a execução da consulta."} |
Se tentarmos novamente com o usuário 5, que tem a função necessária, isso funcionará.
|
1 |
enrolar http://localhost:8093/admin/prepareds -u user5:password |
Acesso a buckets migrados sem senha
Ao migrar da versão 4.6 para a 5.0, é útil preservar os padrões de permissões existentes, para permitir que os aplicativos legados continuem funcionando como antes. Isso é um pouco complicado nesse caso, porque na versão 4.6 o acesso era controlado por meio de senhas nos próprios buckets, enquanto na versão 5.0 o controle de acesso é baseado em usuários com várias funções.
Para preservar os padrões de acesso legados, durante o processo de atualização, criamos usuários com nomes e senhas correspondentes ao bucket original. Isso permite que os aplicativos existentes continuem fazendo o que estavam fazendo, mesmo no caso de acesso sem nenhuma senha.
Para ver isso em ação, será necessário algum trabalho. Fique confortável.
Comece instalando o Couchbase 4.6. Em seguida, crie dois buckets, "openbucket" sem senha e "closedbucket" com a senha "password".
Vá para a guia Query (Consulta) e adicione índices primários para ambos os buckets para permitir a execução de consultas N1QL.
|
1 2 |
criar primário índice em openbucket criar primário índice em balde fechado |
Verifique se o openbucket pode ser consultado sem uma senha:
|
1 |
cbq -e http://localhost:8093/ -s "select * from openbucket" |
Mas a consulta ao closedbucket sem uma senha falha:
|
1 |
cbq -e http://localhost:8093/ -s "select * from closedbucket" |
Mas o closedbucket pode ser consultado com uma senha:
|
1 |
cbq -e http://localhost:8093/ -s "select * from closedbucket" -u closedbucket -p password |
Esse é o padrão de acesso que queremos preservar quando atualizarmos para a versão 5.0. Agora, desligue o Couchbase e faça a atualização para a versão 5.0, preservando os dados subjacentes que acabamos de criar. Em seguida, vá para a tela Segurança do console do Couchbase. Lá, você verá dois novos usuários criados pelo processo de atualização.
O usuário "closedbucket" tem o mesmo nome que o bucket "closedbucket" e a senha que foi atribuída ao bucket na versão 4.6. Ele nos permite preservar o acesso legado ao closedbucket. O usuário "openbucket" faz o mesmo, mas para o openbucket.
Vamos verificar se o padrão de acesso anterior ainda funciona.
|
1 |
cbq -e http://localhost:8093/ -s "select * from openbucket" |
O Openbucket ainda pode ser acessado sem uma senha.
|
1 |
cbq -e http://localhost:8093/ -s "select * from closedbucket" |
O acesso ao Closedbucket falha sem uma senha.
|
1 |
cbq -e http://localhost:8093/ -s "select * from closedbucket" -u closedbucket -p password |
Mas o acesso ao closedbucket é bem-sucedido com uma senha.
Viva! As coisas funcionam como antes. Vá preparar uma guloseima para você.
Resumo
- O controle de acesso no Couchbase 4.6 usava senhas para os buckets. No 5.0, ele usa funções atribuídas aos usuários.
- As principais funções usadas para controlar o acesso de um usuário ao N1QL são query_select/query_insert/query_update/query_delete. Todas elas são parametrizadas por bucket.
- Funções importantes mais especializadas incluem query_manage_index, query_system_catalog e query_external_access.
- Explicar ou preparar uma consulta requer as mesmas funções que a execução da mesma.
Há novos comandos que permitem que você CONCEDA e REVOGUE funções. - O sistema de funções deve ser familiar aos usuários familiarizados com outros grandes bancos de dados. A principal diferença é que o Couchbase não tem noção de permissões fora das funções.
- Há novos espaços-chave do sistema para consultar os usuários e as funções atribuídas a eles.
Os espaços de chave do sistema são controlados para fins de segurança. O comportamento varia de espaço de chave para espaço de chave, dependendo da sensibilidade dos dados contidos nele. - Os padrões de acesso existentes, mesmo para buckets sem senha, ainda devem funcionar após a migração da versão 4.6 para a 5.0.
