Harmony Browse

WiliRGasparetto — Tue, 24 Mar 2026 01:08:49 GMT

Arquitetura, fluxo de enforcement e pontos de atenção em produção

Este post consolida uma visão **engineering-first** do **Harmony Browse**, com foco em **como o enforcement realmente acontece no browser**, como reduzir risco sem aumentar fricção operacional, e quais são os “gotchas” típicos em rollout corporativo.

> Nota de licenciamento/capacidade (importante): alguns recursos podem depender do **pacote Advanced** (ex.: DLP avançado e controles de GenAI). Além disso, a integração com **Microsoft Purview Sensitivity Labels** e maior granularidade de DLP/GenAI está disponível nas **versões mais recentes** do produto — valide o que está habilitado no seu tenant e a versão/feature set do Browse antes de desenhar a política final.
> Referências no final (SKs oficiais).

## 1) O que é o Harmony Browse (visão prática)

Harmony Browse é uma solução de **Browser Security** baseada em **extensão**, criada para aplicar controles diretamente no **canal principal de risco do usuário moderno**: navegação web/SaaS, uploads/downloads e interação com aplicações (incluindo GenAI). A proposta é manter enforcement consistente **independente de rede/localização**, reduzindo dependência de “estar no perímetro”.

---

## 2) Componentes e fluxo de funcionamento (Control plane vs Data plane)

### 2.1 Control plane (gestão/política)

* Políticas são definidas e versionadas no portal (Infinity/Harmony), segmentadas por **grupos**, escopo e regras (URL filtering, anti-phishing, download control, DLP, GenAI, exceções).

### 2.2 Data plane (enforcement no browser)

Fluxo típico (em produção):

1. **Distribuição da extensão**

* Deploy via mecanismo corporativo (MDM/gerenciamento de browser, GPO etc.).
* Alguns navegadores exigem consent/permissões específicas (ex.: Firefox) — isso precisa ser tratado no processo de onboarding.

2. **Aplicação e atualização de policy**

* Ao iniciar, o browser carrega a extensão e sincroniza as políticas aplicáveis ao usuário/dispositivo/grupo.

3. **Inspeção em tempo real**

* **URL / Navegação:** decisões por reputação/categoria/policy (incluindo categoria “AI” quando aplicável).
* **Downloads:** inspeção inline e acionamento de análise avançada quando configurado.
* **DLP/GenAI:** enforcement conforme política (onde habilitado/licenciado).

4. **Ações automáticas**

* Bloqueio/allow, notificações (ajustáveis), geração de evento e evidência no dashboard.

5. **Reporting e auditoria**

* Dashboards e relatórios agendados para SOC/IT/Compliance, com logs para investigação.

---

## 3) Capacidades técnicas (o que você realmente controla)

### 3.1 Zero-Phishing / proteção de navegação

* Bloqueio de phishing em tempo real.
* **Exclusões (allow/trust list)** podem ser usadas para reduzir latência e ruído, mas precisam de governança (owner, justificativa, expiração).

**Gotcha TAC:** exclusão “global e eterna” vira bypass permanente — e phishing moderno explora domínios legítimos comprometidos.

---

### 3.2 URL Filtering (incluindo categoria GenAI/AI)

* Controle por reputação e categoria, com enforcement consistente fora do perímetro.
* Boa prática: aplicar políticas por **perfil de risco** (Finance/Eng/Third-party) em vez de uma política única para toda a empresa.

---

### 3.3 Proteção de downloads + Threat Emulation (sandbox)

* Inspeção de download e envio para sandbox quando aplicável.
* Política precisa definir o comportamento em caso de **falha de emulação** (ex.: arquivo criptografado/indecifrável):

* **Block** (mais seguro)
* **Allow + Alert** (mais flexível, exige SOC/monitoramento)
* **Allow by exception** (somente para grupos controlados)

**Gotcha TAC:** “Allow on emulation failure” sem logging e sem escopo vira o caminho favorito para payloads evasivos.

---

### 3.4 Data Loss Prevention (DLP) no browser

* DLP direcionado a fluxos web (upload, forms, etc.) conforme política.
* **DLP avançado** pode exigir o pacote **Advanced**.
* Integração com **Microsoft Purview Sensitivity Labels** e maior granularidade está disponível nas **versões mais recentes** — valide o feature set no tenant.

**Boa prática:** iniciar com escopo controlado (grupos de risco e destinos críticos) e evoluir a partir de evidência de eventos reais.

---

### 3.5 GenAI Security (controle de risco em IA generativa)

* Controles voltados a reduzir risco de:

* vazamento de dados em prompts
* upload de documentos sensíveis em ferramentas de IA
* uso de plataformas não aprovadas (shadow AI)
* Pode exigir **Advanced** (dependendo do tenant/feature set).
* Granularidade mais rica tende a aparecer nas **versões mais recentes**.

**Ponto TAC:** trate GenAI como canal de exfiltração; alinhe GenAI Security com DLP e classificação (Purview) para reduzir falso positivo.

---

### 3.6 IOC Management (Infinity IOC)

* Capacidade de bloquear automaticamente **URLs/arquivos** via integração com Infinity IOC.

**Boa prática:** workflow SOC → validação → publicação de IOC com prazo de expiração (evita lista infinita).

---

### 3.7 Controle de modo incógnito

* Possibilidade de bloquear Incognito/Private Mode em navegadores suportados (Chrome/Edge/Firefox/Brave).

**Nota operacional:** alinhar com privacidade/compliance e comunicar adequadamente ao usuário (governança > surpresa).

---

### 3.8 Observabilidade e UX

* Dashboard com filtros e relatórios programáveis.
* Extensão pode ser “pinável” para visibilidade (dependendo de política e navegador).
* Ajuste de notificações para reduzir interrupção do usuário final.

---

## 4) Estratégia de rollout (do jeito que evita incidentes)

**Modelo recomendado (rings):**

1. **Pilot-IT/Sec** (alta tolerância a mudanças)
2. **Pilot-Business** (usuários reais)
3. **Wave 1 (20–30%)**
4. **Wave 2 (50–70%)**
5. **Full**

**Métricas mínimas por wave**

* taxa de bloqueio por categoria
* falsos positivos por app crítico
* incidentes por 100 usuários
* volume de eventos por usuário/dia
* top destinos bloqueados (para tuning)

---

## 5) “Gotchas” clássicos em produção (e como evitar)

* **Manifest V3 / mudanças de plataforma:** acompanhe versão e comportamento por browser.
* **Certificate pinning / apps sensíveis:** podem exigir bypass/ajuste (evite liberar domínio inteiro sem escopo).
* **Falha de emulação:** defina política explícita; não deixe comportamento “implícito”.
* **Exceções sem governança:** owner + justificativa + expiração obrigatórios.
* **GenAI/DLP sem segmentação:** aplicar “igual para todos” tende a gerar ruído e bypass.

---

## Referências (SKs oficiais)

* **sk179610 — Harmony Browse – What’s New?**
* **sk179690 — Harmony Browse Client Connectivity Requirements**

Se você quiser, eu monto um **template TAC** para CheckMates com:

* matriz de decisão “emulation failed” (block/allow/exception)
* checklist de rollout por navegador
* modelo de governança de exceções (owner/expiry/justificativa)
* e um mini-runbook de troubleshooting de conectividade (baseado em sk179690).

topic Harmony Browse in SaaS Security

Harmony Browse