3 maneiras pelas quais os desenvolvedores sem código podem dar um tiro no pé

Costumava haver um tempo em que as organizações avessas ao risco podiam limitar severamente a capacidade de seus usuários corporativos de cometer erros dispendiosos. Com conhecimento técnico limitado, permissões estritas e falta de vento favorável, a pior coisa que um usuário corporativo pode fazer é baixar malware ou cair em uma campanha de phishing. Esses dias já se foram.

Hoje em dia, todas as principais plataformas de software como serviço (SaaS) vêm integradas com recursos de automação e criação de aplicativos projetados e comercializados diretamente para usuários corporativos. Plataformas SaaS como Microsoft 365, Salesforce e ServiceNow estão incorporando plataformas no-code/low-code em suas ofertas existentes, colocando-as diretamente nas mãos dos usuários de negócios sem pedir aprovação corporativa. Os recursos que antes estavam disponíveis apenas para as equipes de TI e desenvolvimento agora estão disponíveis em toda a organização.

A Power Platform, a plataforma de baixo código da Microsoft, está incorporada ao Office 365 e é um ótimo exemplo devido à forte presença da Microsoft na empresa e à taxa em que ela é adotada por usuários corporativos. Talvez sem perceber, as empresas estão colocando o poder do desenvolvedor nas mãos de mais pessoas do que nunca, com muito menos segurança ou conhecimento técnico. O que poderia dar errado?

Bastante, na verdade. Vamos examinar alguns exemplos do mundo real de minha experiência. As informações foram anonimizadas e os processos específicos do negócio foram omitidos.

Situação 1: Novo fornecedor? Apenas faça

A equipe de atendimento ao cliente de uma empresa multinacional de varejo queria enriquecer os dados de seus clientes com percepções do consumidor. Em particular, eles esperavam encontrar mais informações sobre novos clientes para que pudessem atendê-los melhor, mesmo durante a compra inicial. A equipe de atendimento ao cliente escolheu um fornecedor com quem gostaria de trabalhar. O fornecedor exigia que os dados fossem enviados a eles para enriquecimento, que seriam então retirados por seus serviços.

Normalmente, é aqui que a TI entra em cena. A TI precisaria construir algum tipo de integração para obter dados de e para o fornecedor. A equipe de segurança de TI obviamente também precisaria estar envolvida, para garantir que esse fornecedor possa confiar nos dados do cliente e aprovar a compra. Aquisição e jurídico também teriam desempenhado um papel fundamental. Nesse caso, porém, as coisas tomaram outro rumo.

Essa equipe específica de atendimento ao cliente era especialista em Microsoft Power Platform. Em vez de esperar por recursos ou aprovação, eles simplesmente seguiram em frente e criaram a própria integração: coletando dados de clientes de servidores SQL em produção, encaminhando tudo para um servidor FTP fornecido pelo fornecedor e recuperando dados enriquecidos do servidor FTP para o banco de dados de produção. Todo o processo era executado automaticamente sempre que um novo cliente era adicionado ao banco de dados. Tudo isso foi feito por meio de interfaces de arrastar e soltar, hospedadas no Office 365 e usando suas contas pessoais. A licença foi paga do próprio bolso, o que manteve a aquisição fora do circuito.

Imagine a surpresa do CISO quando eles encontraram um monte de automações de negócios movendo dados de clientes para um endereço IP codificado na AWS. Sendo um cliente apenas do Azure, isso levantou uma bandeira vermelha gigante. Além disso, os dados eram enviados e recebidos com uma conexão FTP insegura, criando um risco de segurança e conformidade. Quando a equipe de segurança descobriu isso por meio de uma ferramenta de segurança dedicada, os dados estavam entrando e saindo da organização há quase um ano.

Situação 2: Ohh, é errado cobrar cartões de crédito?

A equipe de RH de um grande fornecedor de TI estava se preparando para uma campanha “Give Away” anual, na qual os funcionários são incentivados a doar para sua instituição de caridade favorita, com a empresa participando igualando cada dólar doado pelos funcionários. A campanha do ano anterior foi um grande sucesso, então as expectativas estavam nas alturas. Para potencializar a campanha e aliviar os processos manuais, um funcionário criativo do RH usou a Power Platform da Microsoft para criar um aplicativo que facilitou todo o processo. Para se registrar, um funcionário deve fazer login no aplicativo com sua conta corporativa, enviar o valor da doação, selecionar uma instituição de caridade e fornecer os detalhes do cartão de crédito para pagamento.

A campanha foi um grande sucesso, com recorde de participação dos colaboradores e pouco trabalho manual exigido dos colaboradores de RH. Por alguma razão, porém, a equipe de segurança não gostou do rumo que as coisas tomaram. Ao se cadastrar na campanha, um funcionário da equipe de segurança percebeu que os cartões de crédito estavam sendo recolhidos em um aplicativo que não parecia ser o correto. Após investigação, eles descobriram que os detalhes do cartão de crédito foram realmente manipulados de maneira inadequada. Os detalhes do cartão de crédito foram armazenados no ambiente padrão da Power Platform, o que significa que estavam disponíveis para todo o locatário do Azure AD, incluindo todos os funcionários, fornecedores e contratados. Além disso, eles foram armazenados como campos de string de texto sem formatação simples.

Felizmente, a violação de processamento de dados foi descoberta pela equipe de segurança antes que agentes mal-intencionados – ou auditores de conformidade – a detectassem. O banco de dados foi limpo e o aplicativo foi corrigido para lidar adequadamente com as informações financeiras de acordo com o regulamento.

Situação 3: Por que não posso simplesmente usar o Gmail?

Como usuário, ninguém gosta de controles corporativos de prevenção contra perda de dados. Mesmo quando necessário, eles introduzem atritos irritantes nas operações do dia-a-dia. Como resultado, os usuários sempre tentaram contorná-los. Um cabo de guerra perene entre usuários de negócios criativos e a equipe de segurança é o e-mail corporativo. Sincronizar e-mail corporativo com uma conta de e-mail pessoal ou calendário corporativo com um calendário pessoal: as equipes de segurança têm uma solução para isso. Ou seja, eles implementam soluções de segurança de e-mail e DLP para bloquear o encaminhamento de e-mail e garantir a governança de dados. Isso resolve o problema, certo?

Bem não. Uma descoberta repetida em grandes e pequenas empresas descobre que os usuários estão criando automações que contornam os controles de e-mail para encaminhar seus e-mails e calendários corporativos para suas contas pessoais. Em vez de encaminhar e-mails, eles copiam e colam dados de um serviço para outro. Ao fazer login em cada serviço com uma identidade separada e automatizar o processo de copiar e colar sem código, os usuários corporativos ignoram os controles de segurança com facilidade - e sem uma maneira fácil para as equipes de segurança descobrirem.

A comunidade Power Platform até desenvolveu modelos que qualquer usuário do Office 365 pode pegar e usar.

Com grandes poderes vem grandes responsabilidades

O empoderamento do usuário empresarial é ótimo. As linhas de negócios não devem esperar por TI ou lutar por recursos de desenvolvimento. No entanto, não podemos simplesmente dar aos usuários de negócios o poder de nível de desenvolvedor sem orientação ou proteção e esperar que tudo fique bem.

As equipes de segurança precisam educar os usuários de negócios e torná-los conscientes de suas novas responsabilidades como desenvolvedores de aplicativos, mesmo que esses aplicativos tenham sido criados "sem código". As equipes de segurança também devem implementar proteções e monitoramento para garantir que, quando os usuários de negócios cometerem um erro, como todos nós, isso não se transforme em vazamentos de dados completos ou incidentes de auditoria de conformidade.