Arquitetura da Plataforma

Como as quatro camadas da browserMate se dividem responsabilidades, como a execução de um processo atravessa cada uma delas, e como autenticação e persistência funcionam por trás da simplicidade de uso, sem entrar em detalhes internos de implementação.

Camadas da Arquitetura

A plataforma browserMate é dividida em quatro serviços independentes, cada um com uma responsabilidade única e uma superfície de confiança diferente. Essa separação existe para que nenhum componente precise confiar mais do que o estritamente necessário em nenhum outro, inclusive nos componentes que rodam fora do perímetro da browserMate, dentro do ambiente do próprio cliente.

É o mesmo princípio de least privilege que rege bancos, provedores de nuvem e qualquer arquitetura pensada para operar credenciais reais de sistemas de terceiros em escala. Não só automatizar cliques.

As quatro camadas da plataforma

Cada camada tem um papel e um limite claro do que nunca faz:

O caminho de uma execução

O mesmo desenho de caixas acima descreve, na prática, o que acontece do clique em "Executar" até o resultado aparecer na tela:

1. Autoria. O processo é desenhado no Agent Builder e fica salvo isolado por tenant. Nenhum outro cliente enxerga essa estrutura.
2. Disparo. Uma execução começa manualmente, por agendamento ou por uma chamada da API Externa.
3. Captura do job. O Runtime do ambiente designado pega a execução da fila e se autentica com um token de curta duração, emitido especificamente para aquele job.
4. Autorização. Antes de tocar qualquer dado, o Runtime pede ao Router a confirmação de que pode operar sobre aquele processo. A decisão de "quem pode o quê" nunca é tomada pelo próprio Runtime.
5. Segredos sob demanda. Sempre que uma etapa precisa de uma senha do Cofre ou da credencial de um conector, o Runtime pede ao Router, que decifra via KMS e devolve só o valor necessário, nunca a chave.
6. Evidências e logs. Screenshots e PDFs de evidência sobem por um upload administrado pelo Router; cada etapa gera um log estruturado que alimenta a Trilha de Auditoria e os Dashboards analíticos.
7. Acompanhamento. Status, pausas e o resultado final chegam em tempo real ao Control Room, por um canal protegido por regra de acesso por tenant.

Topologia de Comunicação

O desenho das camadas mostra responsabilidade: quem pode fazer o quê. Este mostra fiação: protocolo, porta e quem autentica cada salto, exatamente o que o time de TI do cliente costuma pedir antes de liberar firewall/proxy para colocar um Ambiente Runtime em produção atrás de uma rede restritiva.

O Router e os serviços do Google Cloud

O Router é a cintura da plataforma: o único componente que efetivamente mantém as credenciais mais privilegiadas de acesso à infraestrutura Google Cloud. Nem a UI nem o Runtime precisam, ou conseguem, tocar diretamente nessas credenciais para realizar uma operação sensível.

• Autorização multi-tenant. Antes de qualquer operação sobre um processo, o Router resolve sozinho se quem está pedindo é o dono, tem compartilhamento válido, ou não tem acesso nenhum, o mesmo modelo descrito em Integrações.
• Cofre de segredos. Toda leitura de senha do Cofre ou de credencial de conector passa pelo Router, que decifra via Cloud KMS e entrega só o valor em texto puro necessário para aquela chamada. A chave-mestra nunca sai do Router.
• Observabilidade. Logs de execução e métricas de produção são encaminhados pelo Router para Cloud Logging e BigQuery, alimentando análises históricas sem sobrecarregar o banco operacional.
• Evidências. Uploads e exclusões de arquivos de evidência no Cloud Storage também passam pelo Router, nunca diretamente do Runtime.

Autenticação e identidade

O login de usuários é inteiramente resolvido pelo Firebase Authentication. Google, Microsoft ou e-mail/senha, sempre do navegador direto para o provedor, sem que a senha passe pelo backend da browserMate. O que a plataforma faz é reconhecer, depois disso, a mesma identidade em todas as camadas:

• Após o login, a UI estabelece uma sessão de servidor (cookie httpOnly) para todas as operações autenticadas. Ver detalhes em Sessões e cookies.
• Ao ativar um Ambiente Runtime, ele recebe do Router um token de execução de curta duração, atrelado ao mesmo tenant do usuário. Não uma credencial mestra que precisaria ser protegida indefinidamente numa máquina fora do controle da browserMate (detalhes em Isolamento do Runtime).
• Um identificador de tenant único, emitido no login e reconhecido em toda a plataforma, garante que UI, Runtime e Router enxerguem o mesmo dono de dados sem depender de nenhuma credencial administrativa circulando pela rede.
• Chamadas da API Externa seguem um caminho totalmente separado, com duas credenciais próprias, nunca reaproveitam sessão de navegador nem token de Runtime.

Persistência: onde cada dado mora

Cada tipo de dado vive no serviço mais adequado à sua natureza. Não existe um único banco fazendo tudo:

Infraestrutura: as garantias que já vêm de fábrica

A browserMate não constrói segurança sobre uma infraestrutura genérica. Constrói sobre o Google Cloud, que já chega com um conjunto de garantias independentemente auditadas. A plataforma herda essas garantias e adiciona a própria camada por cima (KMS aplicado aos segredos, autorização resolvida pelo Router, trilha de auditoria completa):

• Criptografia em repouso por padrão. Todo dado gravado na infraestrutura Google Cloud é cifrado automaticamente (AES-256), antes mesmo da camada adicional de KMS que a browserMate aplica especificamente sobre os segredos.
• Certificações auditadas por terceiros, não autodeclaradas. O Google Cloud mantém, entre outras: ISO/IEC 27001, 27017 e 27018 (segurança da informação, nuvem e proteção de dados pessoais), SOC 1, SOC 2 e SOC 3, e PCI DSS Level 1.
• Padrão criptográfico validado por norma internacional. O Cloud KMS, usado para cifrar os segredos da plataforma, segue os padrões FIPS 140-2 do NIST para geração e proteção de chaves.
• Rede privada global. O tráfego entre serviços e regiões do Google Cloud roda no backbone de fibra própria do Google, sem passar pela internet pública.
• Segurança física de data center. Controle de acesso biométrico, monitoramento 24 horas e auditoria contínua são mantidos e certificados pelo próprio Google, a mesma infraestrutura física usada por Google Search, Gmail e Google Workspace.

Segurança em profundidade

Cada camada aplica sua própria proteção. Nenhuma depende só da anterior ter feito certo:

• Cloud KMS: segredos cifrados com uma chave-mestra que nunca sai do Router, nem em caso de acesso total ao banco de dados.
• AES-256: o padrão de criptografia por trás do envelope de cada segredo armazenado.
• SSO: autenticação delegada a Google/Microsoft/Firebase, sem senha passando pelo backend da browserMate.
• Integrações: o modelo de duas credenciais e autorização sem token de dono, usado por toda a API externa.
• Cofre de Senhas: como as credenciais de sistemas de terceiros ficam disponíveis para os processos sem nunca aparecerem em texto puro nas telas.
• Dados Sensíveis: a marca que tira dado pessoal dos logs, das exportações e das imagens de tela, e o parâmetro Secreto, que espera cifrado na fila de execução.
• Isolamento do Runtime: ativação por chave, ausência de credencial mestra no executável e isolamento entre execuções via Worker threads.
• Trilha de Auditoria: todo evento sensível fica registrado e rastreável a quem o originou.

Isolamento multi-tenant em cada camada

"Multi-tenant" não é uma propriedade de um único banco de dados com uma coluna de empresa. É uma garantia que cada camada revalida por conta própria:

• A UI nunca aceita identidade vinda de parâmetro do navegador. O dono da sessão vem sempre do servidor.
• O Router resolve a autorização de cada processo do zero a cada chamada, sem cache entre requisições e sem confiar em nenhum identificador enviado pelo chamador.
• O Runtime nunca decide sozinho se pode acessar um dado de outro tenant, sempre pergunta ao Router.
• A API Externa exige duas credenciais independentes, e uma sozinha nunca é suficiente para agir em nome de uma conta (ver Duas credenciais, dois propósitos).

O resultado prático: mesmo se uma única camada tivesse uma falha de autorização, as demais ainda barrariam o acesso indevido. Não existe um ponto único cuja falha expõe todos os tenants de uma vez.

Por que essa arquitetura importa

Automação de verdade lida com credenciais reais, como logins de sistemas internos, senhas de portais e chaves de API de terceiros, e executa ações que têm consequência real no negócio do cliente. Uma plataforma que trata isso como só mais um campo de formulário não escala além do primeiro incidente.

A separação em quatro camadas independentes é o que permite à browserMate rodar a execução dentro do ambiente do próprio cliente, seja nuvem ou infraestrutura própria, sem nunca entregar a esse ambiente uma credencial capaz de ler dados de outro tenant. É o que permite trocar, escalar ou reforçar qualquer camada isoladamente, sem redesenhar as demais. E é o que transforma "segurança" de um adjetivo de marketing em uma propriedade verificável do desenho: cada camada sabe exatamente o que pode fazer, e o resto da plataforma foi construído para que ela nunca precise de mais do que isso.

Some a isso uma infraestrutura Google Cloud com certificações auditadas por terceiros e dados analíticos e de criptografia processados em território brasileiro, e o resultado é uma base técnica que aguenta a pergunta mais dura que um CIO/CTO pode fazer sobre uma plataforma de automação: "se isso vazar, o que exatamente um invasor consegue fazer com o que pegou?", e ter, camada por camada, é uma resposta específica e eficiente.