Um fornecedor SaaS da área de saúde tinha doze analistas de dados responsáveis por criar painéis de análise para clientes e relatórios internos de inteligência de negócios. A equipe de análise havia recebido acesso de leitura ao banco de dados de produção quando a função de análise foi criada, uma decisão pragmática que permitia à equipe consultar quaisquer dados de que precisasse para os relatórios que lhe eram solicitados. Ao longo de quatro anos, a equipe cresceu de três para doze analistas, o banco de dados de produção passou a conter registros de mais de duzentos clientes empresariais e a concessão de acesso nunca foi revista. Cada analista podia consultar prontuários de pacientes, dados clínicos ou informações administrativas de qualquer cliente, sem restrição, registro em log ou revisão. O acesso era tecnicamente somente leitura: sem gravações, sem exclusões. Também era totalmente irrestrito: qualquer um dos doze analistas podia consultar qualquer registro de qualquer cliente a qualquer momento, sem aprovação, sem justificativa e sem revisão de auditoria. Uma investigação de violação de dados, iniciada quando um blogueiro da área de saúde publicou informações que pareciam vir de dentro do sistema, acabou rastreando a origem até um analista que vinha consultando registros fora do seu escopo de trabalho havia mais de um ano. Os controles de acesso sempre haviam permitido isso. Ninguém estava observando.
O que é, de fato, o problema do risco de acesso para análise de dados de fornecedores?
O risco de acesso para análise de dados surge quando o acesso a dados concedido às equipes de análise (as pessoas responsáveis por criar painéis, relatórios e modelos analíticos) é significativamente mais amplo do que qualquer tarefa analítica específica exige e é mantido sem os controles de acesso, o registro em log e a periodicidade de revisão aplicados a outras formas de acesso privilegiado a dados. O acesso para análise costuma ser implementado de forma ampla na criação da função ('dar à equipe de análise acesso de leitura ao banco de dados') e raramente é revisto à medida que a equipe cresce, os dados acessados se tornam mais sensíveis e evolui o escopo do que cada analista realmente precisa para sua função específica.
A falha no privilégio mínimo é a principal lacuna de governança. Na maioria das organizações, o acesso privilegiado (contas administrativas, acesso de gravação a sistemas de produção, acesso ao processamento de pagamentos) está sujeito a definição cuidadosa de escopo, fluxos de aprovação e revisão periódica. O acesso para análise de dados é frequentemente tratado como uma categoria à parte, que não exigiria governança equivalente por ser somente leitura e aparentemente de menor risco. A caracterização como somente leitura é correta: os analistas normalmente não podem modificar nem excluir dados. A caracterização como de menor risco exige ressalvas: o acesso de leitura a conjuntos de dados abrangentes que contêm informações pessoais sensíveis, registros financeiros ou dados de saúde é de menor risco do que o acesso de gravação aos mesmos dados, mas não é de baixo risco em nenhum sentido absoluto. O analista que leu prontuários de pacientes para divulgação não autorizada não precisou de acesso de gravação. Precisou do acesso de leitura que todos haviam tratado como irrelevante.
O problema do escopo agrava o problema do acesso. As equipes de análise em ambientes SaaS multilocatário frequentemente têm acesso a dados de toda a base de clientes, e não limitado a clientes específicos, porque criar painéis e relatórios é mais fácil quando o analista pode consultar o conjunto de dados completo. Um fornecedor SaaS da área de saúde cuja equipe de análise precisa criar um painel de desfechos clínicos para o Cliente A tecnicamente não precisa de acesso aos dados do Cliente B para fazer esse trabalho; mas, se a concessão de acesso prevê leitura de todo o banco de dados, a consulta destinada a atender o Cliente A pode ler os registros do Cliente B com a mesma facilidade. A função analítica exigia acesso com escopo definido. A concessão de acesso forneceu acesso sem escopo. O escopo nunca importou até que o analista decidiu ultrapassá-lo.
Os riscos de acesso para análise se concentram em cinco padrões de falha específicos nos ambientes de fornecedores:
- Acesso amplo de leitura ao banco de dados para funções de análise: equipes de análise recebem acesso de leitura a bancos de dados de produção completos, em vez de acesso limitado aos conjuntos de dados específicos necessários para suas tarefas analíticas específicas
- Acesso para análise entre clientes em ambientes multilocatário: equipes de análise com acesso a dados de toda a base de clientes quando as tarefas analíticas exigem acesso apenas aos dados de clientes específicos
- Acesso para análise excluído da revisão de acesso: o acesso somente leitura para análise não é incluído nas revisões periódicas de acesso porque é percebido como inerentemente de menor risco do que o acesso de gravação
- Nenhum registro em log no nível de consulta para o acesso de análise: as consultas de análise não são registradas no nível de registro, o que impossibilita detectar acessos não autorizados a dados dentro do escopo de leitura autorizado
- Acesso para análise que persiste além da função: analistas que mudam de função ou deixam a organização mantêm o acesso ao banco de dados de análise porque os processos de desligamento se concentram no acesso aos sistemas e ignoram as credenciais das plataformas de análise
Por que isso importa
O risco de acesso para análise de dados é importante para TPRM porque o cenário de ameaça interna com maior probabilidade de produzir uma violação de dados significativa envolvendo clientes de um fornecedor SaaS multilocatário não é um ataque externo sofisticado: é um usuário de análise autorizado que tem acesso de leitura irrestrito a todo o conjunto de dados de clientes e decide usar esse acesso fora do escopo pretendido. Os controles concebidos para proteger o aplicativo principal (autenticação, acesso baseado em funções, registro de auditoria) se aplicam a usuários autorizados que acessam dados pela interface do aplicativo. Eles não impedem que um usuário de análise autorizado consulte qualquer registro do banco de dados usando as credenciais de leitura que recebeu para trabalho legítimo.
A dimensão multilocatário amplia significativamente o risco. Um fornecedor SaaS da área de saúde cuja equipe de análise pode consultar qualquer prontuário de paciente de qualquer um de seus duzentos clientes empresariais concentrou o risco de acesso a dados dos duzentos clientes em uma equipe de doze pessoas cujo acesso nunca foi revisado. Cada um desses duzentos clientes avaliou a postura de segurança de dados do fornecedor e concluiu que os dados de seus pacientes estavam adequadamente protegidos. Nenhum deles avaliou se a equipe de análise do fornecedor podia consultar os prontuários de seus pacientes sem nenhuma restrição.
Para profissionais de TPRM, isso cria uma obrigação de avaliação específica que vai além da confirmação do controle de acesso. A questão não é apenas se o fornecedor tem controles de acesso baseados em funções, mas se esses controles se aplicam à função de análise com o mesmo rigor aplicado a outras funções de acesso a dados, incluindo definição de escopo, periodicidade de revisão e registro em log no nível de consulta que permita detectar padrões de acesso não autorizados dentro de uma concessão de acesso autorizada.
Onde a maioria das equipes erra
A falha mais recorrente é aceitar o acesso somente leitura como equivalente a um acesso de baixo risco e, por isso, não aplicar ao acesso para análise o mesmo escrutínio de governança aplicado ao acesso com privilégio de gravação. O acesso somente leitura a conjuntos de dados sensíveis abrangentes é uma concessão significativa de acesso a dados: a capacidade de ler todos os registros de clientes, todas as transações e todos os campos sensíveis é a mesma capacidade necessária para exfiltrar esses dados, ainda que a gravação e a exclusão estejam desativadas. A restrição de gravação reduz o raio de impacto se o acesso for mal utilizado, mas não reduz a exposição se os dados forem lidos e divulgados.
A segunda falha é não perguntar sobre o registro em log no nível de consulta para o acesso de análise. Os logs de acesso no nível da infraestrutura confirmam que um analista se autenticou no banco de dados. Os logs no nível de consulta confirmam quais registros ele efetivamente recuperou durante a sessão. A diferença entre esses dois níveis de log é a diferença entre saber que alguém esteve na sala e saber o que leu enquanto estava lá. Para um acesso de análise que abrange um conjunto de dados multilocatário de clientes, o registro em log no nível de consulta é o único mecanismo capaz de detectar acessos não autorizados entre clientes dentro de uma concessão de acesso autorizada.
- Tratar o acesso somente leitura como inerentemente de menor risco: o acesso de leitura a dados sensíveis abrangentes é suficiente para permitir a exfiltração
- Acesso para análise excluído do privilégio mínimo: acesso amplo ao banco de dados concedido por conveniência funcional, e não limitado aos requisitos de tarefas específicas
- Nenhum registro em log no nível de consulta para sessões de análise: os logs de infraestrutura confirmam a autenticação, mas não o acesso no nível de registro durante a sessão
- Acesso para análise não revisado na periodicidade de revisão de acesso: o acesso somente leitura é tratado como uma categoria à parte, de menor prioridade
- Acesso entre clientes sem escopo definido: o acesso para análise em ambientes multilocatário não é restrito ao subconjunto de clientes relevante para o trabalho de cada analista
Como é uma boa prática
Uma governança madura do acesso para análise aplica o privilégio mínimo às funções de análise com o mesmo rigor do acesso com privilégio de gravação: limita o acesso aos dados necessários para tarefas analíticas específicas, revisa esse escopo periodicamente à medida que as tarefas mudam e implementa registro em log no nível de consulta que permita detectar padrões de acesso incompatíveis com o escopo de trabalho autorizado.
- Privilégio mínimo aplicado ao acesso para análise: acesso limitado aos conjuntos de dados, subconjuntos de clientes ou categorias de dados necessários para a função específica do analista, e não leitura de todo o banco de dados
- Registro de auditoria no nível de consulta: toda consulta de análise registrada com a identidade do usuário, data e hora, tabelas acessadas e quantidade de registros, e revisada em busca de padrões anômalos
- Acesso para análise com a mesma periodicidade de revisão do acesso de gravação: revisões periódicas que confirmam que o escopo do acesso para análise continua proporcional à função atual
- Restrição de acesso entre clientes em ambientes multilocatário: acesso para análise restrito a subconjuntos específicos de clientes para os quais o analista tenha uma justificativa de negócio para acessar os dados de cada cliente
- Desligamento do acesso às plataformas de análise: credenciais do banco de dados de análise incluídas explicitamente nas listas de verificação de desligamento, junto com o acesso aos sistemas principais
Ferramentas
Governar o acesso para análise exige tanto ferramentas de controle de acesso granular para a infraestrutura de análise quanto ferramentas de monitoramento que capturem a atividade no nível de consulta.
Controle de acesso a plataformas de análise: Databricks Unity Catalog, AWS Lake Formation, dbt
As plataformas modernas de análise oferecem controle de acesso granular que permite limitar o acesso para análise no nível de tabela, coluna e linha, restringindo cada analista às categorias de dados específicas que seu trabalho exige. O AWS Lake Formation oferece segurança no nível de coluna e de linha para ambientes de análise baseados em S3. O Databricks Unity Catalog oferece governança de acesso unificada para tabelas Delta Lake, com controle de acesso baseado em atributos. Para profissionais de TPRM, perguntar se a plataforma de análise do fornecedor usa controle de acesso granular, em vez de acesso de leitura a todo o banco de dados, revela a arquitetura de governança do seu modelo de acesso para análise.
Monitoramento de atividade de banco de dados: Imperva, IBM Guardium
As plataformas de DAM capturam a atividade no nível de consulta em bancos de dados, incluindo consultas de análise, fornecendo a trilha de auditoria no nível de registro que os logs de infraestrutura não oferecem. O Imperva oferece especificamente análise de comportamento de usuários aplicada a padrões de consulta a bancos de dados, detectando volumes de acesso anômalos e padrões incomuns de consulta entre clientes. Para profissionais de TPRM, perguntar se as consultas de análise são registradas no nível de registro e se a detecção de anomalias é aplicada aos padrões de acesso para análise revela a profundidade do monitoramento por trás desse acesso.
Governança de identidades: SailPoint, Saviynt
As plataformas de IGA incluem as credenciais das plataformas de análise em seus fluxos de revisão de acesso, garantindo que o acesso para análise seja revisado com a mesma periodicidade de outras funções de acesso a dados, em vez de ficar fora do escopo de revisão como uma categoria 'somente leitura'. Para profissionais de TPRM, perguntar se o acesso às plataformas de análise está incluído no programa de governança de identidades e revisão de acesso do fornecedor é uma pergunta específica sobre a abrangência da governança.
Desafios de governança
O desafio de governança do acesso para análise é a tensão com a produtividade. As equipes de análise precisam de acesso rápido e flexível aos dados para realizar trabalho exploratório de forma eficaz; restrições de consulta e fluxos de aprovação para cada nova análise reduzem a agilidade que torna a função de análise valiosa. A resposta de governança não é eliminar a flexibilidade do acesso para análise, mas definir adequadamente o escopo dessa flexibilidade: fornecer acesso às categorias de dados e aos subconjuntos de clientes que a função do analista exige e restringir o acesso a dados fora desse escopo. As restrições não eliminam a capacidade analítica. Eliminam o acesso a dados que o analista não tem motivo de negócio para consultar.
Para programas de TPRM, a abordagem prática de governança é incluir o acesso para análise na avaliação de controle de acesso do fornecedor como uma categoria de acesso distinta, sem presumir que esteja coberto pela confirmação geral de controle de acesso, e perguntar especificamente sobre escopo, periodicidade de revisão e registro em log no nível de consulta. A concessão ampla de acesso para análise que nunca foi revista é o risco de acesso escondido dentro de um programa de controle de acesso bem governado.
- Incluir o acesso para análise na avaliação de controle de acesso do fornecedor, sem presumir que ele esteja coberto pela confirmação geral de acesso baseado em funções
- Perguntar sobre o escopo do acesso para análise: se é leitura de todo o banco de dados ou se é limitado a tabelas, colunas ou subconjuntos de clientes específicos
- Exigir registro em log no nível de consulta para o acesso de análise: trilha de auditoria no nível de registro, e não apenas logs de autenticação
- Perguntar sobre a periodicidade de revisão do acesso para análise: se está incluído nas revisões periódicas de acesso ou é tratado como uma categoria à parte, de menor prioridade
- Confirmar o desligamento na análise de dados: credenciais da plataforma de análise incluídas no processo de desligamento
Se você faz parte de uma equipe pequena
Acrescente à sua avaliação de controle de acesso de fornecedores uma pergunta que trate especificamente da função de análise: quantas pessoas da sua equipe de análise têm acesso a dados de clientes em produção, qual é o escopo desse acesso e quando ele foi revisado pela última vez? No caso de fornecedores multilocatário, pergunte em seguida se os analistas podem consultar dados de clientes além daqueles a que seu trabalho se refere. Essas duas perguntas revelam a amplitude do acesso para análise que as avaliações padrão de controle de acesso nunca alcançam.
- Perguntar quantos analistas têm acesso ao banco de dados de produção e qual é o escopo desse acesso
- Perguntar se o acesso para análise é revisado com a mesma periodicidade do acesso com privilégio de gravação
- Perguntar se existe registro em log no nível de consulta para sessões de análise
- No caso de fornecedores multilocatário, perguntar se o acesso para análise é restrito a subconjuntos específicos de clientes
O que exigir
Pergunte diretamente:
"Quantas pessoas da sua equipe de análise têm acesso de leitura a bancos de dados de produção que contêm dados de clientes? E esse acesso é de leitura de todo o banco de dados ou limitado a tabelas, categorias de dados ou subconjuntos de clientes específicos?"
"As consultas de análise são registradas em log no nível de registro? Especificamente, vocês conseguem identificar qual analista consultou quais registros de clientes em uma determinada sessão, e esse log é revisado em busca de padrões anômalos?"
"O acesso ao banco de dados de análise está incluído nas suas revisões periódicas de acesso? E quando o acesso da equipe de análise foi revisado pela última vez quanto à proporcionalidade do escopo?"
O que esperar como evidência
- Documentação do escopo do acesso para análise: número de analistas, amplitude do acesso, restrição do escopo por cliente
- Confirmação do registro em log no nível de consulta para sessões de análise
- Histórico de revisões do acesso para análise: incluído nas revisões periódicas, com a data da última revisão
- Confirmação da restrição de acesso entre clientes em ambientes multilocatário
Um fornecedor que responde à pergunta sobre o escopo do acesso para análise com 'nossa equipe de análise só tem acesso de leitura' confirmou o tipo de acesso. Pergunte especificamente se esse acesso de leitura abrange todo o banco de dados de produção ou se é limitado a categorias de dados específicas. Somente leitura e escopo limitado são escolhas de governança diferentes. Ambos são somente leitura. Apenas um aplica o privilégio mínimo.
Como comprovar
A governança do acesso para análise é tratada implicitamente nos princípios de minimização de dados e limitação da finalidade do GDPR, nos requisitos de privilégio mínimo do PCI-DSS e nos padrões de acesso mínimo necessário do HIPAA. Demonstrar diligência devida exige evidências de que o acesso para análise foi avaliado como uma categoria de acesso distinta, com escopo e governança de revisão próprios.
- Registros de avaliação de fornecedores que documentam as perguntas sobre escopo, registro em log e periodicidade de revisão do acesso para análise
- Confirmação do registro em log no nível de consulta para sessões de análise
- Evidências de restrição de acesso entre clientes para fornecedores multilocatário
- Inclusão das revisões do acesso para análise no programa de IGA ou de revisão de acesso
Principal conclusão
Acesso de leitura a tudo continua sendo acesso a tudo. O analista que leu prontuários de pacientes fora do seu escopo de trabalho não precisou de acesso de gravação para isso. Precisou do acesso de leitura que doze pessoas tinham e que ninguém revisava havia quatro anos. O acesso para análise é a concessão de acesso ampla, normalizada e nunca questionada que existe porque era mais fácil dizer 'dê à equipe de análise acesso de leitura ao banco de dados' do que definir o que cada analista realmente precisa. O privilégio mínimo se aplica ao acesso de leitura tanto quanto ao de gravação quando os dados lidos são sensíveis. O registro em log no nível de consulta se aplica às sessões de análise tanto quanto às sessões administrativas quando os registros lidos pertencem a clientes que confiam no fornecedor para controlar quem os consulta.