Auditoria de declarações N1QL do Couchbase

Servidor Couchbase 5.5 inclui a capacidade de manter um registro de todas as ações N1QL realizadas pelos usuários. Isso faz parte do recurso mais geral do Couchbase, o auditoria introduzida na versão 5.0. A auditoria só está disponível na edição Enterprise.

A auditoria permite que os administradores do sistema rastreiem quem está acessando quais dados no sistema. Isso é importante quando os dados armazenados são sensíveis de alguma forma, como informações sobre usuários. O Couchbase Server 5.5 oferece suporte à auditoria de instruções N1QL e permite que o administrador especifique quais tipos de instruções (SELECTs? INSERTs?) devem ser realmente auditadas.

É importante entender o que o Couchbase Server 5.5 não faz. Em particular, ele não permite a auditoria em nível de registro. Se uma instrução UPDATE for executada e modificar cinco registros, o registro de auditoria incluirá toda a instrução executada, inclusive todos os parâmetros passados, e dirá que cinco registros foram atualizados. Ele não dirá quais registros específicos foram atualizados ou quais eram seus valores antes ou depois da operação. Fundamentalmente, a auditoria N1QL audita instruções, não registros.

Para configurar a auditoria, faça login no console de administração do Couchbase. Navegue até a guia Security (Segurança) (na lateral) e até a guia Audit (Auditoria) (na parte superior da tela). Agora você deve ver uma tela como esta:

Essa guia permite que você configure a auditoria em geral. A caixa de seleção na parte superior indica se a auditoria deve ser feita. "Target Log Directory" mostra onde colocar os registros do log de auditoria. Os registros aparecem em um arquivo chamado "audit.log" no diretório de log de destino. O próximo conjunto de caixas de texto controla a rotação do log por tamanho e intervalo de tempo.

Em seguida, há três menus suspensos para vários tipos de eventos, o que lhe dá um controle preciso sobre os tipos de atividades que devem ser registradas. De modo geral, audite apenas o que for necessário. O custo real da taxa de transferência da auditoria depende de quanto é auditado e do tipo de declarações que estão sendo auditadas. Dez por cento de perda de rendimento devido à auditoria é uma estimativa razoável, mas você deve testar o efeito real antes de implantar um novo sistema.

Por fim, você pode colocar usuários na lista de permissões na caixa "Ignorar eventos desses usuários". Esses usuários são confiáveis a ponto de suas ações não precisarem ser registradas. Por exemplo, você pode ter um script automatizado que insere novos dados. Você confia totalmente nesse script. Criar um usuário na lista de permissões e fazer com que o script use as credenciais desse usuário pode ser útil para evitar a geração de muitos registros de auditoria.

Alterne o menu suspenso "N1QL Events" (Eventos N1QL) para ver os tipos de eventos disponíveis para o N1QL.

Há dois tipos gerais. O primeiro são os eventos correspondentes aos tipos de instruções N1QL. Por exemplo, você pode optar por auditar todos os eventos INSERT ou todos os eventos DELETE. Por exemplo, pode ser razoável auditar todos os eventos que modificam dados (INSERT/DELETE/UPDATE/UPSERT), mas ignorar as instruções que apenas recuperam dados (SELECT).

O segundo são os eventos correspondentes às APIs expostas pelo mecanismo de consulta. O mecanismo de consulta N1QL disponibiliza várias APIs, geralmente para monitorar o sistema. Cada um desses endpoints de API é um tipo de evento separado. Por exemplo, há um para o ponto de extremidade /admin/stats e outro para o ponto de extremidade /admin/ping. Você tem controle separado para auditar ou não os acessos a essas APIs.

Consulta simples

Começaremos com a auditoria de um simples comando SELECT.

Vá para a página "Buckets" do console de administração e crie um bucket chamado "test" (sem aspas). A cota de memória de 100 MB é suficiente para nossos propósitos. Em seguida, vá para Query (Consulta) e crie um índice primário no novo bucket, para que possamos executar consultas N1QL nele.

criar índice primário em teste

Em seguida, volte para a tela de configuração de auditoria e selecione "Audit events & write them to a log" na parte superior e a opção "SELECT statement" em "N1QL Events". Em seguida, pressione "Save" (Salvar) na parte inferior da tela.

Em seguida, execute uma consulta como esta.

curl http://localhost:8093/query/service -d "statement=select * from test" -u Administrator:password

E vamos dar uma olhada no registro de auditoria. O campo "Target Log Directory" da tela de configuração de auditoria contém o diretório em que o log de auditoria está armazenado. Usaremos o comando "tail" para mostrar os últimos registros do log de auditoria nesse diretório. Nos sistemas Mac, esse comando funciona:

tail ~/Library/Application\ Support/Couchbase/var/lib/couchbase/logs/audit.log

Você deverá ver várias linhas longas de texto JSON. Cada linha é um registro de auditoria. A última é o registro da declaração que enviamos. Reformatada, ela tem a seguinte aparência:

Vamos examiná-los campo a campo:

• "timestamp" mostra a hora do nó de consulta.
• "real_userid" mostra qual credencial de usuário foi fornecida com a solicitação. Nesse caso, é o usuário incorporado, "Administrator".
• "requestId" é o UUID que o mecanismo de consulta gera para cada solicitação. Esses IDs são exclusivos com probabilidade muito alta.
• "statement" é a declaração real que executamos.
• "isAdHoc" é verdadeiro nesse caso, mostrando que enviamos um comando real para execução, em vez de executar um comando preparado.
• "userAgent" é a cadeia de caracteres User-Agent da solicitação original. Isso é útil para distinguir se a solicitação veio de um SDK, do shell do CBQ ou do Query WorkBench.
• "node" é o endereço IP do qual a solicitação foi recebida.
• "status" mostra o que aconteceu com a solicitação. Nesse caso, ela foi bem-sucedida.
• "metrics" é um conjunto de estatísticas sobre o resultado. Isso corresponde às métricas que foram enviadas com o resultado da solicitação original.
• "id" é o ID do tipo de evento. Os registros de auditoria de todas as consultas SELECT têm o mesmo id, 28672.
• "name" é o nome abreviado do tipo de evento. Ele será o mesmo para todas as consultas SELECT.
• "description" é o nome longo do tipo de evento. Isso também é o mesmo para todas as consultas SELECT.

Observe que o registro de auditoria fornece apenas um usuário, embora o mecanismo de consulta permita várias credenciais por solicitação. Isso foi projetado. O N1QL permitia várias credenciais para consultas na época em que nossas credenciais eram por banco e, portanto, eram necessárias várias credenciais para junções de vários bancos. Mas a partir da versão 5.0, com o RBAC, várias credenciais não são mais necessárias. Nós as suportamos para fins de compatibilidade com versões anteriores, mas a maneira correta de lidar com esses casos é criar usuários com credenciais para vários buckets e usar um desses usuários para cada consulta. Se você insistir em usar várias credenciais para uma consulta auditada, a consulta será auditada, mas haverá um registro de auditoria separado para cada credencial fornecida. Isso é um pouco estranho, por isso sugerimos fortemente que você atualize o modelo de permissões para usar permissões RBAC nesses casos.

Preparar declaração

Agora vamos considerar um caso mais sofisticado, com um comando preparado. Primeiro, volte à tela de configuração de auditoria e ative a auditoria dos comandos SELECT e PREPARE. Lembre-se de clicar em "Save" (Salvar) na parte inferior da tela.

Agora, primeiro vamos preparar um comando. Aqui estamos preparando um comando SELECT, com o nome "example". Observe que o comando tem um parâmetro sem nome.

curl http://localhost:8093/query/service -d "statement=prepare example as select * from test where one=?" -u Administrador:senha

Em seguida, executaremos a instrução, fornecendo um argumento para a instrução. Nesse caso, a instrução será executada, mas não retornará nenhum resultado.

curl http://localhost:8093/query/service -d 'prepared="example"&args=["bar"]'

Agora vamos dar uma olhada no registro de auditoria novamente.

tail ~/Library/Application\ Support/Couchbase/var/lib/couchbase/logs/audit.log

O registro mostrará dois eventos, um para o PREPARE e outro para o SELECT executado a partir do comando preparado:

Os campos dos registros de auditoria são semelhantes aos da execução anterior de um comando SELECT, mas há dois campos que merecem atenção:

• "positionalArgs" contém o argumento fornecido com a consulta.
• "isAdHoc" é, nesse caso, falso, porque o SELECT foi executado a partir de um comando preparado enviado anteriormente.

Solicitação de API

Em seguida, vamos tentar auditar uma das APIs do mecanismo de consulta. Vá para a página de configuração de auditoria e ative o tipo de evento "/admin/ping API request". Não se esqueça de salvar a configuração na parte inferior da página.

Agora envie um ping:

curl -v http://localhost:8093/admin/ping

Não espere muito, o "{}" na parte inferior é o resultado completo:

Em seguida, vamos dar uma olhada no registro de auditoria (novamente, usando o local nos Macs):

tail ~/Library/Application\ Support/Couchbase/var/lib/couchbase/logs/audit.log

A mensagem de registro de auditoria resultante, formatada, tem a seguinte aparência:

Aqui, os campos "timestamp" e "real_userid" funcionam como antes, no exemplo SELECT. "httpMethod" é o tipo de solicitação HTTP. "httpResultCode" e "errorMessage" indicam o que aconteceu com a solicitação. "Id", "name" e "description" são específicos para o evento de auditoria; esses campos serão idênticos para todos os registros de auditoria criados para eventos /admin/ping.

Filtragem de encaminhamento

(Este é um tópico avançado. Não é necessário conhecer o material desta seção para usar a auditoria do N1QL de forma eficaz. Mas uma olhada nos bastidores pode ser do interesse de usuários avançados).

A auditoria é controlada em cada servidor por um executável chamado audit demon. O demônio de auditoria cria todos os registros no log de auditoria. Na versão 5.0, o demônio de auditoria era responsável por toda a filtragem de eventos; os clientes enviavam registros de todos os eventos auditáveis e o demônio de auditoria criava ou não registros de auditoria no log, dependendo da configuração de filtragem. Infelizmente, isso seria muito ineficiente quando a auditoria é altamente filtrada e os clientes estão fazendo muito trabalho potencialmente auditável. Um cliente, como o mecanismo de consulta, poderia gerar milhões de registros para que fossem descartados pelo demônio da auditoria quando chegassem.

Para aliviar esse problema, na versão 5.5 o Couchbase oferece suporte à filtragem direta. O mecanismo de consulta está ciente da configuração de auditoria atual e envia apenas os registros atualmente auditados para o demônio de auditoria. Ele também envia um registro de auditoria especial para indicar que recebeu a nova configuração e está ciente dela.

Essa filtragem dupla é a razão pela qual você pode ver dois tipos de registros de configuração no log de auditoria. Um registro como esse indica que o demônio de auditoria recebeu uma nova configuração:

E um registro como esse indica que o mecanismo de consulta recebeu uma nova configuração:

Observe o UUID que identifica a configuração. Você pode obter esse UUID na configuração, da seguinte forma:

curl http://localhost:8091/pools/default -u Administrator:password

Procure o campo "auditUid".

Você pode obter a configuração completa de auditoria da seguinte forma:

curl http://localhost:8091/settings/audit -u Administrator:password

Carregando o registro de auditoria

Atualmente, o Couchbase Server suporta apenas um destino para os registros de auditoria: um arquivo no servidor. Mas, às vezes, seria útil obter os registros de auditoria no próprio banco de dados. Isso não é difícil, pois os registros de auditoria são JSON. Mas o carregamento do registro requer o uso de um utilitário, o cbimport.

Supondo que o log de auditoria tenha sido criado no local padrão em um Mac e que você tenha criado o compartimento "teste", esse encantamento carrega o arquivo audit.log no compartimento "teste":

/Applications/Couchbase\ Server.app/Contents/Resources/couchbase-core/bin/cbimport json -c http://localhost:8091 -u Administrator -p password -b test -g "#UUID#" -d file:///Users/johanlarson/Library/Application\ Support/Couchbase/var/lib/couchbase/logs/audit.log -f lines

Isso é bastante complicado, e você precisaria de variações ligeiramente diferentes em outros sistemas, portanto, vamos analisar isso passo a passo.

• /Applications/Couchbase\ Server.app/Contents/Resources/couchbase-core/bin/cbimport é o caminho completo para o comando cbimport em um Mac. Para outros sistemas, os utilitários estão localizados em outro lugar. Veja este documento.
• -c http://localhost:8091 é o URL do servidor em que o Couchbase está sendo executado
• -u Administrador -p senha é o nome de usuário e a senha do usuário com o qual estamos fazendo o upload dos dados (neste caso, o administrador padrão).
• teste -b é o nome do bucket para o qual estamos carregando os dados.
• -g "#UUID#" é o tipo de chave a ser gerada para cada documento inserido no bucket. Neste caso, estamos usando um UUID, mas há muitas outras opções. Verifique o cbimport para obter mais informações.
• -d file:///Users/johanlarson/Library/Application\ Support/Couchbase/var/lib/couchbase/logs/audit.log é um URL de arquivo que aponta para o local do registro de auditoria. Observe as três barras inclinadas e a barra invertida para permitir um espaço no caminho do URL. Os logs, inclusive o log de auditoria, são colocados em diretórios padrão que variam de sistema para sistema. Veja este documento para obter mais informações.

Quando os registros de auditoria estiverem no sistema, você poderá consultá-los como qualquer outro dado.

Essa consulta mostra quantos registros de auditoria você tem:

select count(*) as num from test

E essa consulta divide a contagem por tipo de registro de auditoria:

select name, count(*) as num from test group by name

Resumo

• As solicitações ao mecanismo de consulta são auditáveis a partir de Servidor Couchbase 5.5 EE.
• A auditoria em geral oferece suporte à filtragem por tipo de evento e à lista de permissões de usuários.
• As solicitações são marcadas como eventos por tipo de consulta e ponto de extremidade da API.
• Há documentação adicional disponível sobre a auditoria de instruções N1QL aqui.
• Faça o download do Couchbase Server 5.5 aqui.