Segurança
Segurança com cara de hospitalidade.
Um provedor de identidade só é tão bom quanto as paredes entre os seus locatários e o cuidado que tem com os segredos. Veja como o Usher Identity é construído. Descrevemos o que o software faz; não alegamos ter nenhuma certificação.
Arquitetura
Domínios separados, redes separadas.
As páginas do próprio Usher Identity e o emissor de cada cliente ficam em domínios registráveis diferentes. Os bancos de dados ficam em uma rede que não alcança a internet, e a única saída é um proxy que verifica para onde cada conexão vai.
- O Caddy faz a terminação TLS de todos os hosts e remove os cabeçalhos que só os serviços do próprio Usher Identity podem definir.
- A camada de autenticação atende todos os ambientes, diferenciados pelo host; nada é armazenado em cache para um host e servido para outro.
- Cada serviço se conecta ao Valkey com o próprio usuário, limitado às próprias chaves. Não existe usuário padrão.
- As instruções SQL que carregam tokens e códigos nunca são gravadas com os seus valores no log do banco de dados.
A internet
Pessoas, os seus apps, os seus servidores
A borda
Caddy: TLS, HSTS, remove cabeçalhos internos
usheridentity.com
Site e Console
usheridentity.com, console.usheridentity.com
API
api.usheridentity.com
*.usherid.com
Camada de autenticação
O emissor e o Lobby de cada ambiente
Rede de dados · sem rota de saída
Postgres
Um schema por ambiente
Valkey
Cada serviço limitado às próprias chaves
A única saída
Proxy de saída
Para cada URL fornecida por um cliente
Descoberta, JWKS, logout
Somente endereços públicos
Isolamento
Nada que importe é compartilhado.
Cada ambiente de projeto tem o próprio schema Postgres, as próprias chaves de assinatura e os próprios segredos, selados com a sua própria chave de dados. O emissor dele é um host no domínio dos locatários, e os cookies são restritos ao host, então um navegador nunca envia o cookie de um ambiente para outro.
usheridentity.com
O site, o Usher Identity Console e as contas Usher Identity
*.usherid.com
Um emissor por ambiente, em um domínio separado
Usuários, sessões e tokens ficam em um schema feito para este ambiente. As consultas são executadas nesse schema, nunca em uma tabela compartilhada com uma coluna de locatário.
Copiar o segredo de cliente do Google selado de Acme em produção para Northwind em produção.
Criptografia em repouso
Criptografia de envelope, presa ao seu lugar.
Os segredos que você entrega ao Usher Identity são selados com AES-256-GCM sob uma chave de dados que pertence a um único ambiente. As próprias chaves de dados são envolvidas por uma chave mestra com versões, mantida fora do banco de dados.
- Chaves de dados por ambiente
- Comprometer a chave de dados de um ambiente não revela nada sobre a de outro.
- Vinculação por AAD
- O ambiente e a finalidade ficam vinculados a cada texto cifrado, então um valor não pode ser movido entre linhas ou locatários.
- Chaves com versões
- Cada valor selado registra a versão da chave com que foi criado, então as chaves podem passar por rotação e os valores antigos podem ser envolvidos de novo.
- Autenticada
- A tag do GCM faz com que um valor adulterado não abra, em vez de ser decifrado como outra coisa.
Chave mestra
Mantida fora do banco de dados, com versões
Chave de dados, uma por ambiente
Envolvida pela chave mestra
O segredo
Selado com AES-256-GCM sob a chave de dados
u1.<key version>.<iv>.<ciphertext + tag>
aad = u1 | version | environment | purpose
Práticas
Os detalhes, feitos com cuidado.
Senhas, se você usar
Com hash Argon2id no custo recomendado pela OWASP (19 MiB, duas passagens) e um limite de quantos hashes rodam ao mesmo tempo, para que uma enxurrada de inícios de sessão não derrube o serviço. As senhas novas são comparadas com vazamentos conhecidos pela API de intervalos do Have I Been Pwned, que vê apenas um prefixo curto do hash da senha. Por padrão, o comprimento mínimo é de 12 caracteres.
Nada guardado que possa ser reutilizado
Segredos de cliente, tokens, tokens de links mágicos e códigos por e-mail são armazenados como hash. Os códigos de backup são criptografados. Um código de autorização dura cinco minutos; um código por e-mail permite três tentativas.
Limites de tentativas em todas as portas
Início de sessão, cadastro, códigos por e-mail, links mágicos, redefinições de senha e verificações de segundo fator têm, cada um, o seu próprio limite: dez inícios de sessão com senha por minuto, por exemplo, e cinco códigos por e-mail a cada dez minutos.
Uma Content-Security-Policy rigorosa
Cada página do Lobby recebe um nonce novo e uma política construída em torno dele: só rodam os scripts desta origem que carregam o nonce, os formulários só enviam para a mesma origem e outros sites não podem incorporar a página em frames.
Um log de auditoria confiável
As alterações em espaços de trabalho, projetos e ambientes são gravadas em um log que só aceita acréscimos, com cada entrada encadeada por hash à anterior, então uma entrada editada ou ausente fica evidente.
Um proxy de saída para as URLs dos clientes
Toda requisição que o Usher Identity faz a um endereço fornecido por um cliente (descoberta OIDC, JWKS, logout por back-channel) sai por um único proxy. Ele resolve o nome uma vez, recusa endereços privados, de loopback, link-local e de metadados de nuvem, e se conecta ao endereço que verificou, então um DNS rebinding não consegue transformar a URL de um cliente em uma URL interna.
Handles que nunca são entregues duas vezes
O handle de um ambiente de produção é o primeiro rótulo do seu emissor. O Console é aberto só por convite, um Lobby denunciado por phishing é suspenso, e um handle já usado nunca é entregue de novo, porque apps antigos ainda podem confiar nos tokens dele.
Sessões que terminam quando você quiser
O Usher Identity verifica as próprias sessões a cada requisição, em vez de confiar em uma cópia em cache, então uma sessão encerrada por você termina na hora. Os tokens de acesso têm vida curta (dez minutos, por padrão), e a sua API pode fazer a introspecção deles.
Divulgação responsável
Encontrou algo? Conte para nós primeiro.
Se você acha que encontrou um problema de segurança no Usher Identity, queremos saber, e vamos trabalhar com você para corrigi-lo.
- O que você encontrou, onde e como reproduzir.
- O que alguém poderia fazer com isso, até onde você entende.
- Como podemos falar com você e se você gostaria de receber os créditos.
Teste apenas em ambientes que sejam seus, não acesse dados de outras pessoas e nos dê um prazo razoável para corrigir o problema antes de divulgá-lo. Para denunciar uma página que se passa por uma página de início de sessão do Usher Identity, veja Denunciar abuso.