Como o Transglot é protegido.
escopo definido.
Como o Transglot é protegido.
Criptografia, controle de acesso, isolamento de locatário e trilha de auditoria, cada um nomeando o mecanismo que o impõe. As coisas que ainda não construímos estão listadas aqui como lacunas.
- TLS 1.2 ou superior em trânsito
- webhooks assinados com HMAC
- linhas de auditoria somente para acréscimo
- quatro funções, cinco capacidades de token
Criptografia, acesso, isolamento e auditoria.
Criptografado antes de sair do host
Os backups do banco de dados são criptografados na saída. O repositório de backup de arquivos é criptografado com senha e se recusa a funcionar sem sua chave. Credenciais de aplicativos conectados e segredos de webhook são armazenados como colunas criptografadas. Tokens de implantação são armazenados como hash SHA-256 e exibidos uma vez, na criação. Os discos ativos não são criptografados no nível de volume, porque ainda não implementamos isso, e você deve saber disso aqui, em vez de descobrir durante a due diligence.
Assinado na saída
Webhooks de saída são assinados com HMAC-SHA256 sobre o carimbo de data/hora e o corpo. O carimbo de data/hora também é enviado, para que você possa aplicar sua própria janela de replay.
Identidade e acesso
Quatro funções de workspace em todos os planos, inclusive no gratuito: administrador, desenvolvedor, revisor e tradutor, além de proprietários da conta e membros de cobrança. Permissões por projeto e por idioma são adicionadas a isso, permitindo que um freelancer receba acesso a apenas um idioma e não veja mais nada. O login com SAML 2.0 com provisionamento just-in-time e o provisionamento SCIM 2.0 estão disponíveis no plano Enterprise, e o login por senha pode ser desativado para todo o workspace.
Isolamento de locatário
Cada consulta é restrita à sua organização e projeto. Um ID pertencente a outra pessoa retorna 404 em vez de 403, para que a existência de outro workspace nunca seja revelada. O pool de memória compartilhado de correspondência exata é a única exceção deliberada, e qualquer projeto pode sair dele com um interruptor.
A trilha de auditoria
Alterações de função, criação de tokens, alterações de faturamento, configuração de SSO e logins via SSO são registrados, e as linhas não podem ser editadas ou excluídas: o modelo gera erro em ambos os casos. Logins por senha não estão no registro atualmente. Proprietários e administradores no plano Enterprise exportam todo o registro como CSV. Não há cadeia de hash nem assinatura criptográfica, portanto, nada aqui indica proteção contra adulteração.
Tempo de atividade e créditos
Não publicamos percentuais aqui, pois qualquer número que informássemos seria apenas nossa palavra sobre nossa própria disponibilidade. Os planos Business e Enterprise possuem uma meta contratual mensal de tempo de atividade com um cronograma de créditos de serviço, e esse cronograma constitui o SLA.
Onde a conformidade realmente se encontra
As mesmas quatro linhas que a página de confiança e o centro de confiança leem, a partir da mesma configuração. Um selo só pode dizer "obtido" quando um booleano afirma isso, e hoje nenhum deles o faz.
- SOC 2 Type II: auditoria em andamento
- ISO/IEC 42001 (AI management): em busca
- GDPR: alinhado, não certificado
- CCPA / CPRA: alinhado, não certificado
O que um revisor pergunta, respondido primeiro.
As perguntas com as quais uma revisão de segurança começa, e as respostas, na ordem em que geralmente chegam. Cada linha é um controle no código-base, e não uma afirmação sobre ele. A última linha é uma lacuna, e permanecerá aqui até deixar de ser verdadeira.
- nenhuma descoberta citada, pois ainda não há relatório de terceiros
- nenhuma certificação implícita: a tabela de conformidade em /trust lê dados da configuração
- pesquisas de boa-fé nunca são recebidas com advogados
Perguntas frequentes
A lista que geralmente acompanha uma revisão de segurança.
