Shadow IT: transformar a descoberta em responsabilidade atribuída

Uma equipa adota uma ferramenta porque esta resolve um problema real. A questão de segurança começa quando o inventário, os contratos e os processos de acesso da organização não refletem essa utilização. Uma aplicação pode tornar-se essencial para um processo de negócio antes de alguém ter decidido quem a administra, que dados pode conter ou como será desativada.

A shadow IT inclui serviços, aplicações e dispositivos utilizados fora dos processos de aprovação ou de gestão estabelecidos. A descoberta deve conduzir a uma decisão proporcionada e a um responsável designado, e não simplesmente a uma lista mais longa de domínios suspeitos.

Para um CTO, o objetivo é operacional: compreender a dependência, conter a exposição inaceitável e dar ao negócio um caminho viável para tecnologia gerida.

Definir a fronteira antes de recolher sinais

A shadow IT é uma condição de gestão, e não uma categoria de produtos intrinsecamente inseguros. Um serviço de colaboração reputado pode ficar sem gestão quando os trabalhadores criam espaços de trabalho pessoais. Um portátil pessoal pode ser legítimo ao abrigo de um regime controlado de utilização de dispositivos próprios. Inversamente, um serviço adquirido pode continuar fora de uma gestão efetiva se ninguém controlar os seus administradores ou o processo de saída.

Olhe para além dos nomes de software desconhecidos. Exemplos relevantes incluem:

• Armazenamento na nuvem, contas de mensagens e gestores de palavras-passe pessoais utilizados para informação da empresa.
• Extensões de browser, assistentes de reuniões com IA e serviços de transcrição com acesso a conteúdos da empresa.
• Aplicações de terceiros ligadas ao e-mail, aos calendários, aos repositórios ou ao armazenamento de ficheiros através de OAuth.
• Portáteis não geridos, suportes de armazenamento amovíveis, dispositivos de rede e utilitários de acesso remoto.
• Contas na nuvem detidas por equipas, aplicações low-code e scripts de automatização que suportam fluxos de trabalho de produção.

As aplicações aprovadas também podem desenvolver utilizações não geridas. Uma nova integração, uma definição de partilha pública ou uma funcionalidade de IA podem alterar a avaliação de riscos original sem alterar o nome do produto.

Comece por um processo de negócio ou um departamento. Defina que contas, dispositivos, redes, fornecedores e fluxos de dados pertencem à primeira revisão. Isso torna as constatações acionáveis e expõe as lacunas do método antes de se iniciar a recolha em toda a organização.

Construir uma imagem a partir de várias fontes

Nenhuma fonte de descoberta, por si só, mostra todas as ferramentas. Os registos de identidade não captam contas locais; os registos de despesa não captam serviços gratuitos; os registos de rede podem mostrar um destino sem explicar que informação foi para lá.

Utilize fontes complementares e conserve a proveniência de cada constatação.

Explique por que razão a descoberta está a ser feita, o que será recolhido, quem o pode consultar e durante quanto tempo será conservado. Cumpra as regras de privacidade e de direito do trabalho aplicáveis. Prefira metadados suficientes para identificar o serviço e o respetivo acesso, em vez de recolher o conteúdo de mensagens, gravações ou navegação pessoal. Restrinja também o acesso aos próprios registos de descoberta.

Faça perguntas práticas às equipas: onde partilham ficheiros grandes, gravam reuniões, traduzem documentos, recolhem feedback de clientes ou automatizam tarefas repetitivas? Pergunte que ferramentas interromperiam o trabalho se fossem removidas amanhã. Estas perguntas revelam dependências que uma lista de domínios não consegue mostrar.

Normalize as constatações antes de as contar. Um fornecedor pode ter vários domínios, produtos, espaços de trabalho e entidades de faturação. Separe a identidade do produto da identidade do tenant e distinga as evidências de instalação, de autorização, de início de sessão e de utilização confirmada para o negócio. Registe as constatações incertas como candidatas, em vez de declarar que cada destino observado é uma aplicação não autorizada.

Transformar cada constatação num registo de responsabilidade

Um registo útil descreve a utilização, e não apenas o fornecedor. Duas equipas que utilizam o mesmo produto podem ter dados, acessos, contratos e consequências diferentes.

Para cada utilização confirmada, registe:

• O produto, o fornecedor, o identificador do tenant ou espaço de trabalho e a fonte de descoberta.
• A finalidade de negócio, o processo dependente, a população de utilizadores e a criticidade.
• As categorias de dados, as origens e os destinos dos dados, as definições de partilha e a conservação.
• Os tipos de contas, os administradores, a autenticação, as integrações e as permissões concedidas.
• O titular do contrato, o plano de subscrição, os dados de renovação e as disposições relevantes sobre o tratamento.
• O responsável de negócio, o custodiante técnico, o revisor, o tratamento proposto e a data de revisão.

O responsável de negócio justifica a necessidade e coordena a utilização aceitável. O custodiante técnico gere a configuração, os acessos, as integrações e a desativação. A segurança avalia o risco; os especialistas de compras e de privacidade analisam as matérias da sua competência. Numa organização pequena, estas responsabilidades podem recair sobre a mesma pessoa, mas devem continuar explícitas.

Se ninguém assumir a responsabilidade por um serviço, não o classifique como aprovado só porque os utilizadores gostam dele. Atribua um patrocinador temporário responsável e um prazo para a decisão. Registe o que continua desconhecido e quem o vai esclarecer.

Siga os dados, e não apenas a aplicação. Uma ferramenta pode receber carregamentos, sincronizar pastas inteiras, criar transcrições ou enviar conteúdos para outro prestador. O nosso guia de descoberta de dados explica como rastrear essas relações.

Analisar os acessos OAuth separadamente da utilização da aplicação

O OAuth permite que uma aplicação obtenha um acesso autorizado sem receber a palavra-passe do utilizador. Isso é útil, mas a autorização pode ser mais ampla ou mais duradoura do que a tarefa exige. Iniciar sessão numa aplicação e conceder-lhe acesso a recursos da empresa são eventos diferentes.

Para cada aplicação ligada, analise, quando disponíveis, a identidade do editor ou do cliente, o utilizador que concedeu o acesso, o recurso, os âmbitos (scopes), o tipo de consentimento e a data da concessão. Distinga o acesso delegado, exercido em nome de um utilizador, das permissões de aplicação que podem funcionar sem um utilizador interativo. Analise o comportamento dos refresh tokens e se a autorização pode continuar depois de o utilizador deixar de utilizar ativamente a ferramenta.

Dê prioridade às concessões que permitem ler caixas de correio, modificar ficheiros, aceder ao diretório, alterar repositórios ou aceder de forma ampla a vários utilizadores. Verifique se os âmbitos pedidos correspondem à finalidade declarada. Um utilitário de agendamento que pede acesso ao calendário levanta uma questão diferente de um que pede o conteúdo da caixa de correio e acesso irrestrito a ficheiros.

Como controlo prático, restrinja os consentimentos de elevado impacto aos administradores ou a um fluxo de revisão, quando a plataforma o suportar. Reveja as novas permissões concedidas e as alterações a aplicações existentes, e não apenas os registos de novas aplicações.

Remover uma extensão de browser ou desligar uma integração visível para o utilizador pode não remover todas as concessões, tokens ou cópias externas de dados. Verifique a revogação na plataforma do recurso e na conta junto do fornecedor. O transporte cifrado não prova que uma integração é segura, nem torna impossível qualquer inspeção; a visibilidade depende dos controlos e da telemetria disponíveis.

Priorizar pela exposição e pela dependência do negócio

Utilize a triagem para decidir o que precisa de atenção primeiro. Evite tratar todas as ferramentas não aprovadas como igualmente urgentes.

Avalie a sensibilidade e o volume da informação envolvida, a amplitude dos acessos, a partilha externa, o estado de segurança dos dispositivos, o controlo administrativo e as evidências de comprometimento. Considere também a disponibilidade: uma automatização não documentada pode ser a única via para enviar encomendas a um fornecedor.

Uma ferramenta pública de referência de design utilizada sem carregamentos pode precisar apenas de um registo simples. Um assistente de reuniões com IA, com acesso ao calendário, gravações e conversas com clientes, precisa de uma revisão mais aprofundada das permissões, do armazenamento, da conservação e do tratamento a jusante. Um serviço de acesso remoto não gerido num sistema de produção justifica uma contenção e uma investigação rápidas.

Registe um cenário de risco concreto, e não «risco de shadow IT». Por exemplo: «Um antigo trabalhador mantém a administração do espaço de trabalho e pode exportar propostas a clientes.» Esta afirmação aponta para um responsável, uma alteração de controlo e um teste.

A descoberta não é automaticamente uma prova de violação. Se as constatações indicarem divulgação não autorizada ou comprometimento, passe para o processo de incidentes, preservando os registos relevantes. Quando estão envolvidos dados pessoais, a avaliação da notificação depende das circunstâncias e do papel da organização nos termos dos artigos 33.º e 34.º do RGPD, e não simplesmente de a ferramenta ter sido aprovada ou não.

Escolher um tratamento que preserve a necessidade do negócio

Cada decisão precisa de um responsável, de uma fundamentação, de critérios de conclusão e de seguimento. Na prática, há quatro tratamentos úteis.

Aprovar e colocar sob gestão

A aprovação deve descrever a utilização permitida, e não conceder uma autorização irrestrita para o produto. Estabeleça uma administração controlada pela empresa, autenticação adequada, acesso com o menor privilégio, tratamento de entradas, mudanças e saídas e uma configuração suportada. Verifique o registo de eventos, as restrições de partilha, as opções de recuperação ou exportação e a conservação face ao caso de utilização.

Reveja o fornecedor e o contrato, quando aplicável. Se o fornecedor tratar dados pessoais por conta da organização, avalie as disposições exigidas para subcontratantes nos termos do artigo 28.º do RGPD. As disposições sobre transferências internacionais exigem uma avaliação separada; a escolha de uma região de alojamento não resolve todas as questões. As medidas de segurança do artigo 32.º baseiam-se no risco, e não numa lista de verificação universal cumprida com uma única definição.

Conserve as evidências da aprovação: exportações de configuração, atribuições de administradores, testes de acesso, revisão contratual e o risco residual aceite.

Substituir por uma alternativa adequada

A substituição só funciona se a alternativa satisfizer a necessidade real. Teste os limites de ficheiros, a colaboração externa, a acessibilidade, a automatização e as integrações necessárias antes de impor a migração.

Defina a sequência de migração, reconcilie os registos e confirme que os utilizadores conseguem concluir o fluxo de trabalho. Preserve os registos exigidos e os metadados relevantes. Verifique as ligações partilhadas e as integrações após a transição e encerre depois o tenant antigo, em vez de apenas deixar de pagar.

Remover a utilização injustificada

Para uma ferramenta sem uma finalidade defensável ou com exposição inaceitável, impeça novas utilizações e planeie a remoção. Revogue concessões e tokens, remova extensões ou software, desative contas, feche ligações de partilha e trate os dados já exportados. Faça a rotação das credenciais expostas quando as constatações o justificarem.

Eliminar uma conta não é prova de que toda a informação detida pelo fornecedor desapareceu. Obtenha as evidências de eliminação disponíveis e documente a conservação contratual, as cópias de segurança ou outras limitações. Preserve a informação sujeita a conservação obrigatória ou a retenção para fins judiciais.

Permitir uma exceção controlada e temporária

Uma ferramenta crítica para o negócio pode precisar de um período de transição. Especifique os utilizadores e os dados permitidos, os controlos compensatórios, quem aceita o risco, a data de expiração e as condições de saída. Restrinja, quando possível, a expansão da utilização. Uma exceção «temporária» permanente e sem revisão é uma lacuna de gestão por resolver.

Exemplo prático: um assistente de reuniões com IA

Considere, a título ilustrativo, uma organização que está a rever o seu processo comercial. Suponha que oito trabalhadores utilizam um assistente de reuniões gratuito através de contas individuais. As entrevistas confirmam que grava chamadas com clientes; uma exportação de identidades mostra concessões de acesso ao calendário. Não existe qualquer registo de compra, e um gestor comercial depende das transcrições para as passagens de testemunho.

A primeira decisão é suspender novas gravações e novos utilizadores enquanto se apura o que foi captado. A segurança regista as concessões e as identidades das contas. O gestor identifica as reuniões afetadas e a necessidade operacional. As áreas de privacidade e de compras analisam as disposições sobre o tratamento, a informação aos participantes, os termos do fornecedor, a conservação e quaisquer disposições relevantes sobre transferências. A equipa verifica também se as gravações ou as transcrições estão publicamente acessíveis e se o serviço utiliza os conteúdos para outras finalidades.

Suponha que a revisão conclui que o plano gratuito não permite uma administração controlada pela empresa nem as definições de conservação exigidas. A decisão é substituir, e não abandonar o processo de passagem de testemunho. A área comercial testa uma alternativa aprovada com controlos de acesso e de gravação adequados, enquanto o custodiante técnico revoga as antigas concessões de acesso ao calendário e migra os registos permitidos.

As evidências de encerramento incluem a lista de contas afetadas, a configuração da substituta, os resultados da revogação das concessões, as verificações das antigas ligações de partilha e as confirmações de eliminação disponíveis. Qualquer limitação por resolver relativa à conservação em cópias de segurança permanece registada. O gestor comercial é responsável pela utilização aceitável; as TI são responsáveis pela configuração e pelas saídas. A revisão termina com um processo gerido, e não apenas com uma aplicação bloqueada.

Evitar o próximo ponto cego com um processo de pedido utilizável

As equipas adotam muitas vezes ferramentas para contornar aprovações lentas, funcionalidades em falta ou atritos nos sistemas existentes. A descoberta deve identificar essas causas. Caso contrário, a remoção limita-se a deslocar a mesma atividade para um sítio menos visível.

Torne os pedidos fáceis de submeter. Peça a finalidade, os utilizadores, as categorias de dados, as integrações, a urgência e um responsável de negócio. Publique os critérios que desencadeiam uma revisão mais aprofundada e disponibilize um caminho prático para testes de baixo risco. Dê aos requerentes um estado e um momento previsto para a decisão; não deixe os pedidos numa fila sem explicação.

Ensine comportamentos concretos: perguntar antes de ligar um serviço ao e-mail da empresa, evitar carregar informação de clientes para uma ferramenta não revista e comunicar a existência de um espaço de trabalho antes de o renovar. Dê às equipas um canal de comunicação focado em corrigir lacunas, e não em punir quem comunica de boa-fé.

Continue a monitorizar as alterações após a aprovação. Reveja as novas concessões OAuth, as alterações administrativas, a partilha externa, as funcionalidades de IA recém-ativadas e a expansão para dados mais sensíveis. Como recomendação prática, combine verificações desencadeadas por eventos com uma confirmação periódica pelos responsáveis. A frequência de revisão deve refletir a exposição e a criticidade para o negócio, e não um intervalo universal.

Tornar as evidências úteis para o SGSI

A ISO/IEC 27001 diz respeito a um sistema de gestão da segurança da informação com âmbito delimitado. As constatações de shadow IT podem alimentar a gestão de ativos, a avaliação de fornecedores, os controlos de acesso, a avaliação de riscos e o tratamento. A seleção de controlos continua a basear-se no risco; uma lista de aplicações não é um SGSI nem prova de que os controlos funcionam.

Mantenha distintos o âmbito da descoberta, a avaliação, a decisão de tratamento, as evidências de implementação e a verificação da eficácia. Um ticket fechado com a indicação «removido» é uma evidência mais fraca do que um acesso revogado acompanhado de um resultado testado. A aceitação de riscos deve identificar quem tinha autoridade para a aceitar e quando tem de ser revista. A certificação não demonstra, por si só, a conformidade com o RGPD.

O Secani disponibiliza um espaço de trabalho ligado para modelar sistemas e serviços, relacionar as evidências com requisitos e decisões e atribuir responsáveis e tarefas de revisão. Mantenha a descoberta e a aplicação de regras nos sistemas operacionais adequados e traga depois as exportações, as revisões e as aprovações relevantes para esse contexto de conformidade. Trate as sugestões assistidas por IA como rascunhos que exigem revisão humana, preservando a rastreabilidade das fontes.

Para a próxima revisão, escolha um processo de negócio e reconcilie as constatações de identidades, despesas, dispositivos e entrevistas. Conclua cada constatação confirmada com um responsável designado, um tratamento, um prazo e um teste de encerramento. As medidas úteis incluem a cobertura de responsáveis, as decisões em atraso, as exceções prestes a expirar e as verificações de remoção de acessos concluídas, e não apenas o número de ferramentas descobertas.