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 aplicativo cliente executa um pequeno proxy local (HTTP CONNECT e SOCKS5) ao qual o seu navegador se conecta. Para HTTPS, quando seu navegador abre uma conexão, o proxy local retorna "200 Connection Established" e retransmite os bytes brutos, ainda criptografados, para o gateway do TYO Reach — executado em infraestrutura de nuvem gerenciada na região selecionada — através de um túnel autenticado; o gateway retransmite esses mesmos bytes para o servidor de destino. A sessão TLS original do seu navegador é executada de ponta a ponta até o site de destino através desse túnel — o Reach é um cano, não um ponto final. Ele nunca vê texto simples, nunca gera ou apresenta um certificado substituto, e não instala nenhuma CA raiz no seu dispositivo. O destino vê o endereço IP do gateway, não o seu.
O que é autenticado é o próprio túnel, não o seu tráfego: o cliente envia um cabeçalho X-Reach-Key ao abrir o túnel com o gateway, para que este possa identificar sua conta e aplicar sua franquia de dados. A aplicação de política (quais domínios saem através de qual gateway) e a medição são feitas a partir de metadados de conexão — o host de destino que seu navegador pede ao proxy para alcançar, e a contagem de bytes — nunca pela leitura de conteúdo descriptografado.
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?
Não. Se você estiver fazendo login em um site via HTTPS — que praticamente todas as páginas de login usam — sua sessão TLS é executada de ponta a ponta entre seu navegador e o site de destino através do túnel do Reach; o Reach apenas retransmite bytes criptografados e nunca os descriptografa. Ele é estruturalmente incapaz de ver o conteúdo do formulário de login, incluindo sua 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 HTTPS — praticamente toda a navegação moderna — não. O Reach não intercepta nem descriptografa o tráfego HTTPS — ele apenas retransmite seu tráfego, já criptografado, através de um túnel, e sua sessão TLS chega de ponta a ponta ao site de destino. O gateway sabe o nome do host de destino (por exemplo, example.com) apenas porque seu navegador informa ao proxy para onde se conectar (o destino CONNECT padrão), não por analisar nada dentro do handshake criptografado — e nunca vê o caminho da URL, a string de consulta ou o conteúdo da página. Essa é uma garantia estrutural do design do túnel para HTTPS, não apenas uma política de registro. 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, essa garantia estrutural não se aplica — o proxy local é tecnicamente capaz de ler a solicitação, como qualquer proxy de encaminhamento em texto simples, 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.