Governação de extensões do navegador para NIS2, DORA e GDPR da UE

Maria, Diretora de Segurança da Informação de uma fintech em rápido crescimento, considerava que a pré-avaliação DORA estava a correr bem. A sua equipa tinha preparado o registo de terceiros de TIC, os contratos SaaS críticos, os registos de diligência devida de fornecedores, as decisões de aceitação do risco e o pacote de reporte ao órgão de administração.

Depois, o auditor fez uma pergunta que ninguém tinha previsto.

“Podem mostrar-nos o vosso processo de governação para extensões do navegador?”

A pergunta surgiu durante uma revisão de endpoint com uma analista financeira. Durante uma partilha de ecrã, o auditor reparou numa extensão de produtividade de terceiros no navegador da analista. Parecia inofensiva, mas uma pesquisa rápida mostrou que o programador tinha sofrido um comprometimento da cadeia de fornecimento três meses antes. A extensão comprometida tinha sido utilizada para desviar tokens de sessão de grandes plataformas SaaS.

A fintech tinha políticas robustas contra software não autorizado. Tinha EDR, MFA, CASB, registos SaaS e um SGSI alinhado com a ISO/IEC 27001. Mas ninguém tinha tratado o navegador como uma plataforma de software gerida. Ninguém tinha inventariado as extensões. Ninguém tinha aprovado as respetivas permissões. Ninguém tinha verificado se os programadores das extensões eram fornecedores. Ninguém tinha mapeado a atividade das extensões para evidência DORA, NIS2 ou GDPR da UE.

Um único complemento do navegador transformou um endpoint aparentemente conforme numa possível porta de entrada para sistemas financeiros, dados de clientes e fluxos de trabalho regulados.

Esse é o problema da governação de extensões do navegador em 2026. O navegador já não é apenas uma janela para a Internet. É onde os colaboradores se autenticam, aprovam pagamentos, acedem a registos de CRM, tratam dados pessoais, gerem infraestrutura cloud e interagem com plataformas SaaS críticas. As extensões já não são complementos meramente visuais. São código de terceiros a executar na camada mais sensível do trabalho moderno.

Para Diretores de Segurança da Informação, gestores de conformidade, Encarregados da Proteção de Dados e responsáveis pelo risco associado às TIC, as extensões não geridas situam-se na interseção entre segurança de endpoints, TI sombra, risco de fornecedor, gestão de alterações, gestão de vulnerabilidades e responsabilização em matéria de privacidade. A ISO/IEC 27001:2022 dá às organizações a estrutura para governar este risco. A NIS2, a DORA e o GDPR da UE criam a pressão regulamentar para o demonstrar.

As extensões do navegador são software, fornecedores e subcontratantes responsáveis pelo tratamento de dados

A maioria das organizações já aprendeu a gerir computadores portáteis, dispositivos móveis, servidores, aplicações SaaS, infraestrutura cloud e contas privilegiadas. As extensões do navegador ficam muitas vezes entre esses programas.

As equipas de segurança veem-nas como uma definição do navegador. A área de compras não as vê porque não é assinado qualquer contrato. O departamento jurídico não as vê porque não é aberto qualquer pedido de integração de fornecedores. As equipas de privacidade não as veem porque a extensão é instalada por um utilizador, não implementada como aplicação oficial. Ainda assim, a extensão pode solicitar permissão para ler e alterar dados em todos os websites, aceder ao conteúdo da área de transferência, capturar metadados de páginas, gerir transferências, injetar scripts ou comunicar com um backend externo.

Isto significa que uma extensão do navegador pode ser, simultaneamente, tudo o que se segue:

O [ZB] Zenith Blueprint: An Auditor’s 30-Step Roadmap capta a questão central na sua orientação ISO/IEC 27002:2022 para o controlo 8.19. Avisa que “mesmo trabalhadores bem-intencionados podem instalar ferramentas para ‘fazer o trabalho mais depressa’, uma extensão de navegador, uma biblioteca de código, uma aplicação de transferência de ficheiros, sem perceber que acabaram de introduzir uma backdoor, uma dependência sem patches ou um vetor de exfiltração de dados.”

Essa frase deve ser tratada como uma declaração de risco ao nível do conselho de administração. Os colaboradores que instalam extensões de risco normalmente não estão a tentar contornar a segurança. Estão a tentar melhorar a produtividade. A falha de governação ocorre quando a organização não disponibiliza um processo seguro de pedido, aprovação, implementação e monitorização.

Porque é que NIS2, DORA e GDPR da UE tornam urgente este ponto cego

O risco associado a extensões do navegador existe há anos, mas o contexto regulamentar mudou. Em 2026, espera-se que as organizações demonstrem não apenas que os controlos existem, mas que são baseados no risco, integrados, monitorizados e suportados por evidência.

A NIS2 eleva as expectativas relativas à higiene de cibersegurança e à segurança da cadeia de fornecimento. A DORA exige que as entidades financeiras giram o risco associado às TIC em dependências internas e de terceiros. O GDPR da UE exige que responsáveis pelo tratamento e subcontratantes demonstrem segurança do tratamento, responsabilização e privacidade desde a conceção. Extensões não geridas podem comprometer os três regimes.

A lição é simples. Uma extensão do navegador não é demasiado pequena para importar. Se puder tocar em dados regulados, sessões autenticadas, fluxos de trabalho financeiros ou serviços SaaS críticos, tem de ser governada.

Utilizar a ISO/IEC 27001:2022 como modelo operacional

A ISO/IEC 27001:2022 é eficaz para a governação de extensões do navegador porque não exige um silo de conformidade separado. Permite às organizações estender os processos existentes do SGSI à camada do navegador.

O modelo prático de controlos assenta em oito controlos do Anexo A da ISO/IEC 27001:2022:

O [ZC] Zenith Controls: The Cross-Compliance Guide é especialmente útil porque explica como os controlos ISO/IEC 27001 são auditados e como suportam evidência entre referenciais. Para o controlo 8.19, Zenith Controls: The Cross-Compliance Guide explica que os auditores irão “seguir o fluxo de trabalho: do pedido ao teste, à aprovação e à implementação”. É exatamente assim que a governação de extensões deve ser desenhada.

Se um auditor encontrar uma extensão que não consta da lista aprovada, não está documentada em registos de alteração e não foi sujeita a avaliação de risco, o problema já não é apenas uma definição do navegador. Torna-se evidência de controlo fraco sobre a instalação de software, governação fraca de endpoints e possível falha de risco de fornecedor.

Passo 1, descobrir o parque de extensões

A primeira falha de controlo na fintech de Maria foi a visibilidade. A sua equipa não sabia que extensões estavam instaladas, quem as tinha instalado, que permissões solicitavam ou se se ligavam a serviços externos.

A descoberta deve cobrir todos os navegadores geridos, perfis, utilizadores, dispositivos e sistemas operativos. Deve identificar o nome da extensão, identificador único, versão, editor, origem da instalação, conjunto de permissões, data de instalação, estado de atualização, número de utilizadores, proprietário de negócio e se a extensão é instalada obrigatoriamente, instalada pelo utilizador, carregada lateralmente ou bloqueada.

O controlo 8.1, Dispositivos endpoint de utilizador, é a âncora. A orientação do Zenith Blueprint: An Auditor’s 30-Step Roadmap para o controlo 8.1 estabelece que os dispositivos endpoint de utilizador “devem ser reforçados, monitorizados e controlados”. Esse requisito inclui naturalmente o navegador, porque o navegador é agora a principal interface de endpoint de utilizador para trabalho SaaS e cloud.

O controlo 5.23 também se aplica quando as extensões se ligam a serviços na nuvem. O Zenith Blueprint: An Auditor’s 30-Step Roadmap enquadra este controlo como resposta à TI sombra, em que os utilizadores adotam serviços não sancionados sem governação. Uma extensão do navegador que envia conteúdo para um backend alojado desconhecido constitui um evento de adoção de serviço na nuvem, mesmo que ninguém na área de compras o tenha aprovado.

Um resultado de descoberta maduro deve classificar cada extensão num de cinco estados:

A descoberta não deve ser um projeto pontual. As extensões são atualizadas frequentemente, os editores mudam de proprietário, as permissões expandem-se e as lojas removem pacotes maliciosos depois de os utilizadores já os terem instalado. O inventário deve tornar-se contínuo ou, pelo menos, suficientemente recorrente para suportar a gestão de vulnerabilidades e a evidência de auditoria.

Passo 2, tornar explícita a utilização aceitável

Depois de as extensões estarem visíveis, as expectativas dos utilizadores devem ser claras. Muitas organizações já têm linguagem de políticas que pode suportar a governação de extensões, mas esta tem de ser aplicada explicitamente ao navegador.

[P-EPM] Política de proteção de endpoints contra malware - PME estabelece que os utilizadores “não devem instalar software ou plugins não autorizados que possam introduzir risco”. Essa frase dá às equipas de segurança uma base de política sólida para tratar extensões do navegador como software controlado.

[P03-AUP] P03 Política de Utilização Aceitável, também referida como a Política de Utilização Aceitável empresarial, proíbe “Ferramentas não aprovadas: instalar ou utilizar software, hardware, serviços na nuvem ou dispositivos não autorizados”. Esta é a base orientada para o utilizador. Converte a governação de extensões do navegador de uma preferência técnica num requisito comportamental e de conformidade aplicável.

Uma política robusta de extensões do navegador deve responder a seis perguntas práticas:

Isto não significa proibir todas as extensões úteis. Significa passar de confiança implícita para aprovação explícita. Algumas extensões podem ser seguras, necessárias e melhorar a produtividade. Outras podem ser desnecessárias, excessivamente privilegiadas, abandonadas ou hostis. O programa de governação deve distinguir entre elas.

Passo 3, aplicar negação por defeito com lista de permissões por exceção

O controlo 8.19, Instalação de software em sistemas operacionais, é o controlo que transforma a política em operação. As extensões do navegador não devem ser tratadas de forma diferente de outro software apenas porque os utilizadores as instalam através de uma loja do navegador.

O Zenith Blueprint: An Auditor’s 30-Step Roadmap é direto neste ponto: “nenhum software é instalado sem estar justificado, autorizado e protegido”. Para extensões do navegador, isto significa utilizar gestão empresarial de navegadores, gestão de endpoints ou ferramentas de configuração de dispositivos para aplicar regras de instalação.

O modelo mais defensável é a negação por defeito com lista de permissões por exceção:

1. Bloquear todas as extensões por defeito em navegadores geridos.
2. Instalar obrigatoriamente apenas extensões corporativas essenciais e aprovadas.
3. Manter uma lista de permissões para extensões aprovadas por grupo de utilizadores, departamento ou função.
4. Bloquear extensões carregadas lateralmente e origens de instalação não fiáveis.
5. Impedir que os utilizadores contornem políticas mudando de perfil ou utilizando navegadores não geridos.
6. Remover extensões já instaladas que não estejam aprovadas.
7. Rever permissões das extensões e risco do editor antes da aprovação.
8. Registar extensões permitidas, bloqueadas, removidas e alteradas.

Algumas organizações começam com um modelo mais gradual devido à complexidade operacional. Podem inventariar primeiro, bloquear extensões sabidamente maliciosas e depois introduzir listas de permissões por fases para grupos de alto risco, como finanças, engenharia, administradores privilegiados, jurídico, Recursos Humanos e apoio ao cliente. Isto é aceitável se existir um roteiro documentado. O que não é defensável é a tolerância permanente de risco desconhecido de extensões.

Passo 4, avaliar o risco das extensões como fornecedores e software

Uma revisão de risco de extensões do navegador deve ser suficientemente leve para ser adotada pelo negócio, mas suficientemente robusta para resistir a auditoria. A revisão deve combinar risco de software, risco de fornecedor, risco cloud, proteção de dados e gestão de vulnerabilidades.

[P-TP] Política de segurança de terceiros e fornecedores determina que “todos os novos fornecedores devem ser submetidos a uma avaliação de segurança documentada antes da celebração do contrato”. Nem todos os programadores de extensões exigirão um processo completo de integração de fornecedores empresarial, mas o princípio de risco de fornecedor continua a aplicar-se. Se um programador consegue enviar atualizações de código para navegadores de colaboradores ou tratar dados da organização através de um serviço backend, a organização tem uma dependência de terceiros.

[P-ASR] Política de Requisitos de Segurança das Aplicações - PME reforça o mesmo requisito a partir da perspetiva de software: “qualquer ferramenta de terceiros, plugin ou biblioteca de código externa utilizada numa aplicação deve ser registada e revista anualmente quanto ao impacto na segurança e ao estado de patch”.

Utilize o seguinte modelo de risco para normalizar decisões:

Uma extensão de alto risco não deve ser aprovada salvo se existir uma necessidade crítica de negócio, controlos compensatórios documentados e aceitação do risco pela gestão de topo. Exemplos de controlos compensatórios incluem limitar a utilização a um perfil de navegador reforçado, restringir a URLs específicos, bloquear a introdução de dados em aplicações sensíveis enquanto a extensão está ativa, utilizar monitorização DLP ou exigir um contrato com o fornecedor e adenda de privacidade.

Passo 5, integrar a revisão de privacidade e GDPR da UE

A governação de extensões do navegador falha frequentemente porque a revisão de privacidade está desligada das ferramentas de endpoint. No entanto, muitas extensões conseguem visualizar dados pessoais apresentados em aplicações SaaS, sistemas de Recursos Humanos, tickets de suporte, registos de CRM, correio eletrónico, plataformas de análise e ferramentas de colaboração.

Nos termos do artigo 5(2) do GDPR, a organização deve demonstrar responsabilização. Nos termos do artigo 25, deve implementar proteção de dados desde a conceção e por defeito. Nos termos do artigo 32, deve aplicar medidas técnicas e organizativas adequadas para a segurança do tratamento. Se uma extensão exfiltrar dados pessoais, o evento pode tornar-se uma violação de dados pessoais nos termos do artigo 4(12), desencadeando avaliação e possivelmente obrigações de notificação ao abrigo do artigo 33.

Uma revisão de extensões sensível à privacidade deve perguntar:

Nem todas as extensões exigem uma AIPD completa. Contudo, extensões com amplo acesso a páginas, processamento por IA, captura de ecrã, acesso a correio eletrónico, acesso a CRM, acesso a dados de Recursos Humanos, dados de apoio ao cliente ou dados financeiros regulados devem acionar uma avaliação de privacidade estruturada.

Passo 6, registar eventos e monitorizar para auditoria e resposta a incidentes

Um programa de governação de extensões sem registos de eventos não é auditável. Também enfraquece a resposta a incidentes, porque a organização não consegue determinar quando uma extensão foi instalada, quem a utilizou, que versão estava presente, quando as permissões foram alteradas ou se ocorreu uma tentativa de instalação bloqueada.

[P-LM] Política de registo de eventos e monitorização - PME identifica registos para “instalações de software” como um requisito essencial de governação. A instalação de extensões do navegador é um evento de instalação de software e deve ser capturada em conformidade.

No mínimo, os registos devem incluir:

Estes registos devem alimentar processos de monitorização ao abrigo dos controlos 8.15 e 8.16. Dependendo do risco, também podem ser encaminhados para um SIEM, uma plataforma de endpoint ou um repositório de evidência de conformidade. Devem ser configurados alertas para extensões de alto risco bloqueadas, picos súbitos em pedidos de extensões, alterações às permissões de extensões aprovadas, tentativas de instalação a partir de fontes não oficiais e tentativas de instalação por utilizadores privilegiados.

A monitorização também é uma vantagem para NIS2 e DORA. A comunicação de incidentes ao abrigo do artigo 23 da NIS2 depende de deteção precoce e avaliação de impacto. A DORA exige tratamento robusto de incidentes de TIC e evidência de resiliência. A avaliação de violação ao abrigo do GDPR da UE depende de saber o que aconteceu, quando aconteceu e que dados podem ter sido afetados.

O que o auditor quer ver

Um auditor raramente fica satisfeito com uma afirmação como “bloqueamos extensões de risco”. Quer evidência de governação. A evidência deve ligar política, avaliação de riscos, aplicação técnica, monitorização e responsabilização da gestão.

É aqui que o Zenith Controls: The Cross-Compliance Guide se torna valioso. Ajuda as organizações a mostrar como uma atividade de controlo suporta múltiplas expectativas de conformidade. Um único fluxo de aprovação de extensões do navegador pode suportar o controlo 8.19 da ISO/IEC 27001, a higiene de cibersegurança da NIS2, a gestão do risco associado às TIC da DORA e a responsabilização do GDPR da UE, se a evidência for retida e claramente mapeada.

Mapeamento cruzado, ISO/IEC 27001:2022 para NIS2, DORA e GDPR da UE

Um mapeamento cruzado prático ajuda os Diretores de Segurança da Informação a explicar porque a governação de extensões do navegador não é um controlo técnico de nicho. É um controlo de conformidade com amplo valor regulamentar.

O mapeamento DORA merece atenção especial. Alguns auditores e avaliadores utilizarão linguagem ao estilo COBIT ao rever a governação de alterações de TIC. COBIT BAI06 é geralmente entendido como Managed IT Changes. Se as extensões do navegador são software e a sua instalação altera o ambiente de computação do utilizador, então a instalação de extensões pertence à mesma lógica governada de alterações. O Zenith Controls: The Cross-Compliance Guide suporta esta lente de auditoria ao mostrar como a evidência de controlos ISO/IEC 27001 pode ser reutilizada entre expectativas de conformidade.

Um plano de implementação de 90 dias para a governação de extensões do navegador

As organizações não precisam de resolver tudo numa única semana. Um programa prático pode ser construído por fases, especialmente se a disrupção do negócio tiver de ser gerida com cuidado.

Para organizações de alto risco, especialmente entidades financeiras ao abrigo da DORA ou entidades essenciais e importantes ao abrigo da NIS2, a primeira fase de aplicação deve priorizar utilizadores com acesso a sistemas críticos, dados regulados, consolas administrativas privilegiadas, plataformas financeiras, ferramentas de apoio ao cliente e ambientes de desenvolvimento.

A mensagem ao nível do conselho de administração

A governação de extensões do navegador não deve ser apresentada aos executivos como um projeto de endurecimento do navegador. Deve ser apresentada como um controlo sobre código de terceiros não validado em fluxos de trabalho regulados.

O conselho de administração e o órgão de administração têm de compreender quatro pontos:

1. O navegador é agora uma plataforma core do negócio.
2. As extensões podem aceder a dados SaaS sensíveis e sessões autenticadas.
3. Extensões não geridas criam risco de fornecedor, privacidade, incidentes e resiliência.
4. A ISO/IEC 27001:2022 fornece um modelo de controlo defensável que suporta evidência NIS2, DORA e GDPR da UE.

Este enquadramento afasta a discussão da preferência técnica e aproxima-a da resiliência operacional. Também suporta financiamento para gestão empresarial de navegadores, integração com endpoints, monitorização, revisão de privacidade, triagem de fornecedores e automatização de evidência de auditoria.

De ponto cego a controlo estratégico

O problema de auditoria de Maria não foi causado por uma analista ter instalado uma ferramenta de produtividade. Foi causado por uma classe de risco não gerida. A organização tinha construído um programa de conformidade robusto em torno de ativos visíveis, fornecedores visíveis, plataformas SaaS visíveis e endpoints visíveis, mas a camada de extensões do navegador permanecia invisível.

Essa lacuna é agora demasiado importante para ser ignorada.

A correção não é complicada, mas tem de ser deliberada. Trate o navegador como parte do endpoint. Trate as extensões como software. Trate os programadores de extensões e os backends como fornecedores quando relevante. Trate permissões como acesso a dados. Trate instalação como alteração. Trate registos como evidência de conformidade.

Um programa defensável começa com quatro ações:

1. Descobrir todas as extensões em navegadores e endpoints geridos.
2. Definir regras de utilização aceitável e negação por defeito utilizando a Política de proteção de endpoints contra malware - PME, a P03 Política de Utilização Aceitável e a Política de Utilização Aceitável empresarial.
3. Avaliar pedidos de extensões utilizando critérios de fornecedor, cloud, vulnerabilidade e privacidade da Política de segurança de terceiros e fornecedores e da Política de Requisitos de Segurança das Aplicações - PME.
4. Aplicar e monitorizar a atividade de instalação utilizando gestão de navegadores, registo de eventos e práticas de evidência alinhadas com a Política de registo de eventos e monitorização - PME.

Para Diretores de Segurança da Informação que se preparam para auditorias NIS2, DORA, GDPR da UE ou ISO/IEC 27001:2022, a governação de extensões do navegador é uma melhoria de controlo de elevado valor porque fecha um vetor real de ataque e, ao mesmo tempo, produz evidência reutilizável entre referenciais.

Para acelerar o trabalho, descarregue o Zenith Blueprint: An Auditor’s 30-Step Roadmap e mapeie a sua evidência com o Zenith Controls: The Cross-Compliance Guide. Se quiser transformar o caos das extensões do navegador num programa de governação preparado para auditoria, agende uma avaliação ou demonstração da Clarysec e comece com um inventário prático, um mapa de riscos e um plano de controlo de 90 dias.