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).
