Como o Transglot é protegido.
delimitado.
Como o Transglot é protegido.
Encriptação, controlo de acesso, isolamento de inquilinos e registo de auditoria, cada um nomeando o mecanismo que o impõe. As coisas que não construímos estão aqui descritas como lacunas.
- tls 1.2 ou superior em trânsito
- webhooks assinados com hmac
- linhas de auditoria apenas para acrescento
- quatro funções, cinco capacidades de token
Encriptação, acesso, isolamento e auditoria.
Encriptado antes de sair do servidor
As cópias de segurança da base de dados são encriptadas durante a exportação. O repositório de cópias de segurança de ficheiros está protegido por palavra-passe e recusa funcionar sem a sua chave. As credenciais de aplicações conectadas e os segredos de webhooks são armazenados como colunas encriptadas. Os tokens de implementação são armazenados como um hash SHA-256 e apresentados apenas uma vez, na criação. Os discos ativos não estão encriptados ao nível do volume, porque ainda não desenvolvemos essa funcionalidade, e deve tomar conhecimento disso aqui em vez de durante a due diligence.
Assinado na saída
Os webhooks de saída são assinados com HMAC-SHA256 sobre a marca temporal e o corpo. A marca temporal também é enviada, para que possa impor a sua própria janela de repetição.
Identidade e acesso
Quatro funções de espaço de trabalho em todos os planos, incluindo o Gratuito: administrador, programador, revisor e tradutor, além dos proprietários da conta e membros de faturação. As concessões por projeto e por idioma sobrepõem-se, permitindo atribuir apenas um idioma a um freelancer, sem acesso a nada mais. O início de sessão SAML 2.0 com provisionamento just-in-time e o provisionamento SCIM 2.0 estão disponíveis no plano Enterprise, e o início de sessão por palavra-passe pode ser desativado para todo o espaço de trabalho.
Isolamento de inquilinos
Cada consulta está limitada à sua organização e projeto. Um ID pertencente a outra pessoa devolve 404 em vez de 403, pelo que a existência de outro espaço de trabalho nunca é revelada. O pool de memória partilhado de correspondência exata é a única exceção deliberada, e qualquer projeto pode abandoná-lo através de um interruptor.
O registo de auditoria
As alterações de funções, criação de tokens, alterações de faturação, configuração de SSO e inícios de sessão via SSO são registados, e as linhas não podem ser editadas ou eliminadas: o modelo lança uma exceção em ambos os casos. Os inícios de sessão por palavra-passe não constam atualmente do registo. Os proprietários e administradores no plano Enterprise podem exportar todo o registo como CSV. Não existe cadeia de hashes nem assinatura criptográfica, pelo que nada aqui garante deteção de adulteração.
Tempo de atividade e créditos
Não publicamos nenhuma percentagem aqui, porque qualquer valor que indicássemos seria apenas a nossa palavra sobre a nossa própria disponibilidade. Os planos Business e Enterprise incluem um objetivo contratual mensal de tempo de atividade com um calendário de créditos de serviço, sendo esse calendário o SLA.
O estado real da conformidade
As mesmas quatro linhas que a página de confiança e o centro de confiança apresentam, provenientes da mesma configuração. Um selo só pode indicar "mantido" quando um valor booleano o confirma, e hoje nenhum deles o faz.
- SOC 2 Type II: auditoria em curso
- ISO/IEC 42001 (AI management): a prosseguir
- GDPR: alinhado, não certificado
- CCPA / CPRA: alinhado, não certificado
O que um revisor pergunta, respondido primeiro.
As perguntas com que uma revisão de segurança começa, e as respetivas respostas, pela ordem habitual. Cada linha representa um controlo na base de código, e não uma afirmação isolada. A última linha é uma lacuna, e permanecerá aqui até deixar de ser verdadeira.
- nenhuma descoberta citada, porque ainda não existe relatório de terceiros
- nenhuma certificação implícita: a tabela de conformidade em /trust lê a configuração
- a investigação de boa-fé nunca é confrontada com advogados
Perguntas frequentes
A lista que geralmente acompanha uma revisão de segurança.
