Segurança no TYO Reach
A segurança é fundamental para o que o Reach faz — você está roteando seu tráfego através da nossa infraestrutura, então você tem todo o direito de saber exatamente como ele é tratado.
Como seu tráfego se move através do Reach
Entender o caminho dos dados ajuda você a avaliar o que podemos e não podemos ver — e por que o design é como é.
Quando o Reach está ativo, o tráfego selecionado do seu dispositivo viaja para o gateway do TYO Reach através de uma conexão HTTPS criptografada. O gateway — executado no Google Cloud Run em Sydney — encaminha a solicitação para o servidor de destino em seu nome. O destino vê o endereço IP do gateway, não o seu. O TLS é aplicado em cada salto: do seu dispositivo para o gateway, e do gateway para o destino.
O TYO Reach usa o mitmproxy como seu mecanismo de proxy subjacente. "Man-in-the-middle" é uma descrição técnica de como o proxy intercepta a conexão, não uma descrição de intenção. Essa interceptação é necessária para dois propósitos específicos:
- Autenticação. O Reach adiciona um cabeçalho
Proxy-Authorisationpara que o gateway possa identificar a qual conta a solicitação pertence e aplicar sua franquia de dados. - Aplicação de política. Regras de roteamento — quais domínios saem através de qual gateway — são aplicadas nesta camada.
O proxy encerra sua sessão TLS, inspeciona os metadados HTTP (nome do host e método), aplica a política e re-criptografa a solicitação antes de encaminhá-la. Os certificados TLS de destino são validados normalmente pelo gateway. Este é o mesmo modelo usado por gateways de segurança web corporativos.
O que registramos — e o que deliberadamente não registramos
O Reach mede quanto dado você usa. Por padrão, ele não registra o que você faz com ele — um registro de conexão opcional, desativado a menos que você ou sua organização o habilite, é a única exceção.
O que registramos por padrão
Registramos o volume total de dados (bytes) transferidos através da sua conta por período de faturamento. Esta é a única informação necessária para aplicar sua franquia mensal de dados, e é a única coisa que registramos a menos que você ative o registro de conexão opcional.
O que não registramos
Não registramos caminhos de URL, strings de consulta, termos de pesquisa ou conteúdo de página — nunca. Não registramos um histórico dos domínios que você visita, a menos que você (ou sua organização) ative o registro de conexão opcional, e mesmo então apenas o nome do host e o horário da conexão são armazenados, nunca caminhos ou conteúdo. Não criamos perfis de navegação nem compartilhamos dados de tráfego com anunciantes ou provedores de análise.
Registro de conexão opcional e retenção
Os dados de medição de contagem de bytes são retidos pelo seu período de faturamento atual mais um curto período para resolução de disputas. O registro de conexão (acesso) opcional fica desativado por padrão; quando você ou sua organização o habilita, os metadados de nível de conexão (host, hora, duração) são retidos por no máximo 30 dias e depois excluídos. Todos os logs são armazenados no Google Cloud na região de Sydney.
Identidade apoiada pelo TYO ID
A autenticação para o TYO Reach é tratada pelo id.tyo.com.au — o próprio serviço de identidade da TYO — não por uma plataforma de terceiros que não controlamos.
Identidade hospedada na Austrália
O TYO ID é executado no Google Cloud na Austrália. As credenciais da sua conta nunca transitam por uma plataforma de identidade dos EUA ou da UE. Os fluxos de login usam OAuth 2.0 com tokens de sessão de curta duração — credenciais de longa duração nunca são armazenadas no aplicativo cliente.
MFA e TOTP
A autenticação multifator está disponível via TOTP (senhas únicas baseadas em tempo — compatíveis com qualquer aplicativo autenticador RFC 6238). Administradores de equipe podem exigir MFA para todos os membros do grupo; os usuários não podem optar por sair de uma política de MFA aplicada pelo grupo.
Login com Google e Microsoft
As equipes podem fazer login com Google ou Microsoft. A federação de diretório Azure AD / OIDC empresarial está disponível mediante solicitação para organizações que precisam dela.
Como o gateway é construído e operado
O gateway é executado em infraestrutura serverless gerenciada — sem máquinas virtuais persistentes, sem acesso SSH, sem segredos de longa duração no ambiente.
Google Cloud Run
O gateway de proxy Reach é executado no Cloud Run — a plataforma de contêiner serverless gerenciada do Google. O Cloud Run escala automaticamente, aplica a segurança de infraestrutura subjacente do Google e significa que não há VMs persistentes para corrigirmos ou para um invasor persistir entre as implantações.
Sem acesso SSH à produção
Não há acesso SSH ou shell ao gateway em execução. Todas as implantações passam pelo pipeline de implantação do Google Cloud. Os rollbacks são realizados via reimplantação, não via acesso ao console.
GCP Secret Manager
Credenciais sensíveis — chaves de API, tokens de serviço, strings de conexão de banco de dados — são armazenadas no GCP Secret Manager, não em arquivos de variáveis de ambiente ou código. O gateway recupera segredos na inicialização através de uma API interna autenticada.
Correção automática da plataforma
O Cloud Run lida com a correção do SO e do runtime automaticamente. Mantemos a camada de aplicação; o Google mantém a plataforma. Não há superfície de VM não corrigida.
Encontrou uma vulnerabilidade de segurança?
Se você encontrou um problema no TYO Reach, queremos saber sobre ele antes que seja divulgado publicamente.
Envie uma descrição do problema para [email protected]. Por favor, inclua:
- Uma descrição clara da vulnerabilidade e seu impacto potencial.
- Etapas para reproduzir (uma prova de conceito nos ajuda a triar mais rápido).
- Capturas de tela, logs ou qualquer evidência de suporte.
Nosso objetivo é reconhecer todos os relatórios de segurança dentro de um dia útil e fornecer um cronograma de resolução dentro de três dias úteis após a confirmação do problema. Por favor, dê-nos um tempo razoável para corrigir o problema antes de qualquer divulgação pública.
Pedimos que você:
- Não acesse ou modifique dados pertencentes a outros usuários.
- Não realize testes de negação de serviço contra sistemas de produção.
- Aja de boa fé.
Atualmente, não executamos um programa de recompensa por bugs pago, mas reconheceremos os pesquisadores nas notas de lançamento com sua permissão.
O Reach vê minhas senhas?
Se você estiver fazendo login em um site via HTTPS — que praticamente todas as páginas de login usam — o conteúdo do formulário de login, incluindo sua senha, é criptografado de ponta a ponta entre seu navegador e o site de destino. O gateway Reach vê o nome do host da conexão, mas não pode ler o conteúdo da solicitação, incluindo campos de senha. Como regra geral: evite enviar credenciais via HTTP não criptografado em qualquer rede.
O Reach pode ler meu conteúdo de navegação HTTPS?
Para conexões HTTPS, o gateway vê o nome do host (por exemplo, example.com), mas não o caminho da URL, a string de consulta ou o conteúdo da página. Por padrão, não registramos nomes de host de forma alguma; eles só são registrados se você ou sua organização ativar o registro de conexão opcional (apenas nome do host e horário da conexão, mantidos por 30 dias). Para a pequena minoria de tráfego HTTP não criptografado que ainda existe na internet, o gateway é tecnicamente capaz de ler a solicitação, mas não inspecionamos nem armazenamos seu conteúdo.
Onde meus dados são armazenados?
Dados da conta, registros de medição e quaisquer logs são armazenados no Google Cloud na região de Sydney. Não replicamos dados pessoais para jurisdições fora da Austrália, exceto conforme exigido pelas operações de infraestrutura padrão do Google. Consulte nossa Política de Privacidade para obter detalhes completos.
Como denuncio uma vulnerabilidade?
Envie um e-mail para [email protected] com uma descrição do problema, etapas para reproduzir e qualquer material de suporte. Nosso objetivo é reconhecer todos os relatórios dentro de um dia útil. Por favor, dê-nos tempo para resolver o problema antes da divulgação pública.