Cuidado com a representação do usuário em aplicativos de código baixo/sem código

No mês passado eu escrevi um artigo sobre como as plataformas low-code/no-code estão oferecendo compartilhamento de credenciais como um serviço, por que estão fazendo isso e como isso se parece perspectiva de um atacante. Neste artigo, vou me concentrar nas implicações desse compromisso e como ele afeta as empresas hoje.

Veja por que compartilhar suas credenciais corporativas com outra pessoa é uma prática ruim. Digamos que eu queira passar minhas credenciais para um colega para consultar os logs de produção para uma análise única do comportamento do usuário. Em uma empresa típica, conceder permissões a alguém para consultar uma nova fonte de dados pode significar um longo processo de revisão de acesso, especialmente quando se trata de produção ou dados confidenciais. Meu colega poderia facilmente ficar frustrado. “Tudo o que eu queria era fazer essa pequena consulta única, e já estou esperando há um mês!” eles poderiam dizer. Eu poderia simplesmente executar a consulta para eles, mas estou sobrecarregado com minhas próprias tarefas do dia-a-dia, e consultas pontuais tendem a ficar complicadas.

Resta-me uma solução rápida: eu poderia simplesmente compartilhar meu nome de usuário/senha com meu colega. Se eles receberem um desafio de MFA, aprovarei com prazer. Não preciso perder tempo executando a consulta e meu colega é desbloqueado. Todos ganham! Certo?

Bem, você estaria certo em sua análise, mas está perdendo o quadro maior. Embora seja importante para a empresa que seu colega faça a análise do comportamento do usuário, é igualmente, se não mais, importante que sua empresa permaneça em conformidade com toda uma série de padrões de privacidade e segurança e mantenha a confiança do cliente ao manter o compromisso da empresa com a segurança .

Se as metas corporativas de alto nível não o convencerem, considere as equipes de gerenciamento central em TI ou segurança. Essas equipes baseiam suas operações e estratégias de segurança no fato de que cada usuário tem sua própria identidade. As equipes de TI estão configurando políticas de rede e acesso que pressupõem que cada usuário estaria conectado a partir de um IP corporativo ou laptop corporativo de uma só vez; as equipes de segurança estão correlacionando eventos com base no ID do usuário; as equipes de finanças podem agregar relatórios de custos por usuário e seu ambiente de nuvem pessoal. O compartilhamento de credenciais mina todas essas suposições, entre outras. Ele retira o significado básico de uma identidade online.

Um exemplo do mundo real

Vamos nos voltar para o mundo do low-code/no-code e examinar um cenário do mundo real. Em uma grande empresa, Jane, uma funcionária inspirada da equipe de atendimento ao cliente, percebeu que, quando os funcionários de toda a organização participam de um caso de cliente, geralmente perdem informações importantes sobre o cliente, como histórico de casos de suporte e compras mais recentes. Isso degrada a experiência do cliente, pois ele precisa explicar seu problema repetidamente enquanto o caso é encaminhado para o funcionário certo que pode resolver o problema.

Para melhorar isso, Jane criou um aplicativo que permite que os funcionários da empresa visualizem essas informações importantes sobre os clientes quando esses funcionários fazem parte da equipe responsável por tratar do caso de suporte do cliente. Primeiro, vamos reconhecer o poder do low-code/no-code, que permite a Jane identificar uma necessidade e resolvê-la por conta própria, sem pedir um orçamento ou esperar por alocações de recursos de TI.

Ao criar o aplicativo, Jane teve que contornar vários problemas, sendo o maior deles as permissões. Os funcionários de toda a organização não têm acesso direto para consultar o banco de dados do cliente para obter as informações de que precisam. Se o fizessem, Jane não precisaria criar esse aplicativo. Para superar esse problema, Jane efetuou login no banco de dados e incorporou sua sessão autenticada diretamente no aplicativo. Quando o aplicativo recebe uma solicitação de um usuário, ele usará a identidade de Jane para executar essa consulta e retornar os resultados ao usuário. Esse recurso de incorporação de credenciais, como exploramos no mês passado, é um recurso-chave das plataformas low-code/no-code. Jane certificou-se de configurar o controle de acesso baseado em função (RBAC) no aplicativo de modo que cada usuário possa acessar apenas os casos de cliente aos quais foi atribuído.

O aplicativo resolveu um importante problema de negócios e, portanto, ganhou rapidamente a adoção dos usuários em toda a empresa. As pessoas ficaram felizes por poderem fornecer um serviço melhor aos seus clientes tendo o contexto certo para a conversa. Os clientes também ficaram satisfeitos. Um mês depois que Jane criou o aplicativo, ele já era usado por centenas de usuários em toda a organização, com taxas de satisfação do cliente aumentando.

Enquanto isso, no SOC, um alerta de alta gravidade mostrando atividade anormal no banco de dados do cliente de produção foi acionado e atribuído a Amy, uma analista de segurança experiente. A investigação inicial de Amy mostrou que um usuário interno estava tentando raspar todo o banco de dados, consultando informações sobre vários clientes de vários endereços IP em toda a organização. O padrão de consulta era muito complexo; em vez de um padrão de enumeração simples que você esperaria ver quando um banco de dados está sendo raspado, os dados do mesmo cliente foram consultados várias vezes, às vezes por meio de endereços IP diferentes e em datas diferentes. Poderia ser um invasor tentando confundir os sistemas de monitoramento de segurança?

Após uma rápida investigação, Amy descobriu uma informação crucial: todas essas consultas em todos os endereços IP e datas estavam usando uma única identidade de usuário, alguém chamado Jane da equipe de atendimento ao cliente.

Amy estendeu a mão para Jane para perguntar o que está acontecendo. A princípio, Jane não sabia. Suas credenciais foram roubadas? Ela clicou no link errado ou confiou no e-mail errado? Mas quando Jane contou a Amy sobre o aplicativo que ela criou recentemente, ambos perceberam que poderia haver uma conexão. Amy, a analista de SOC, não estava familiarizada com low-code/no-code, então eles entraram em contato com a equipe AppSec. Com a ajuda de Jane, a equipe descobriu que o aplicativo de Jane tinha as credenciais de Jane incorporadas nele. Do ponto de vista do banco de dados, não havia aplicativo — havia apenas Jane, executando muitas consultas.

Jane, Amy e a equipe do AppSec decidiram encerrar o aplicativo até que uma solução fosse encontrada. Os usuários de aplicativos em toda a organização ficaram frustrados, pois passaram a confiar nele, e os clientes também estavam sentindo isso.

Enquanto Amy encerrava o problema e documentava suas descobertas, o vice-presidente de atendimento ao cliente não estava feliz com a queda da taxa de satisfação do cliente, então eles pediram a Jane que procurasse uma solução permanente. Com a ajuda da documentação da plataforma e da equipe do Centro de Excelência da organização, Jane removeu sua identidade incorporada do aplicativo, alterou o aplicativo para usar a identidade de cada usuário para consultar o banco de dados e garantiu que os usuários obtivessem permissões apenas para casos de clientes aos quais estão associados . Em sua nova e aprimorada versão, o aplicativo utilizava a identidade de cada usuário para consultar o banco de dados de clientes. Jane e os usuários do aplicativo ficaram felizes por o aplicativo estar online novamente, Amy e a equipe da AppSec ficaram felizes porque a identidade de Jane não é mais compartilhada e a empresa viu a taxa de satisfação do cliente começar a subir novamente. Tudo foi bem.

Duas semanas depois, o SOC recebeu outro alerta sobre acesso anormal ao banco de dados do cliente de produção. Parecia suspeitosamente semelhante ao alerta anterior no mesmo banco de dados. Novamente, os endereços IP de toda a organização estavam usando a identidade de um único usuário para consultar o banco de dados. Novamente, esse usuário era Jane. Mas desta vez, a equipe de segurança e Jane sabiam que o aplicativo usa as identidades de seus usuários. O que está acontecendo?

A investigação revelou que o aplicativo original tinha compartilhado implicitamente A sessão de banco de dados autenticada de Jane com os usuários do aplicativo. Ao compartilhar o aplicativo com um usuário, esse usuário obteve acesso direto ao da conexão, um wrapper em torno de uma sessão de banco de dados autenticada fornecida pela plataforma low-code/no-code. Usando essa conexão, os usuários podem aproveitar a sessão autenticada diretamente – eles não precisam mais passar pelo aplicativo. Acontece que vários usuários descobriram isso e, pensando que esse era o comportamento pretendido, estavam usando a sessão de banco de dados autenticada de Jane para executar suas consultas. Eles adoraram essa solução, pois o uso da conexão direta lhes dava acesso total ao banco de dados, não apenas para casos de clientes aos quais são atribuídos.

A conexão foi excluída e o incidente acabou. O analista de SOC entrou em contato com usuários que usaram a conexão de Jane para garantir que eles descartassem todos os dados de clientes armazenados.

Enfrentando o desafio de segurança Low-Code/No-Code

A história acima é um cenário da vida real de uma empresa multinacional B2C. Alguns detalhes foram omitidos ou ajustados para proteger a privacidade. Vimos como um funcionário bem-intencionado pode compartilhar involuntariamente sua identidade com outros usuários, causando uma série de problemas na TI, na segurança e nos negócios. Como exploramos no mês passado, o compartilhamento de credenciais é um recurso importante do low-code/no-code. É a norma, não a exceção.

As low-code/no-code continua a florescer na empresa, conscientemente ou não, é crucial que as equipes de segurança e TI participem da conversa de desenvolvimento de negócios. Os aplicativos de código baixo/sem código vêm com um conjunto único de desafios de segurança, e sua natureza prolífica significa que esses desafios se tornam agudos mais rápido do que nunca.