Segurança
Segurança que sabe receber.
Um fornecedor de identidade vale o que valem as paredes entre os seus inquilinos e o cuidado que tem com os segredos. Eis como o Usher Identity é construído. Descrevemos o que o software faz; não alegamos ter qualquer 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 registáveis diferentes. As bases de dados estão numa rede que não consegue chegar à internet, e a única saída é um proxy que verifica para onde 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 responde por todos os ambientes, distinguidos pelo host; nada é guardado em cache para um host e servido a outro.
- Cada serviço liga-se ao Valkey com o seu próprio utilizador, limitado às suas próprias chaves. Não existe utilizador predefinido.
- As instruções SQL que contêm tokens e códigos nunca são escritas no registo da base de dados com os respetivos valores.
A internet
Pessoas, as suas apps, os seus servidores
A periferia
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 saída
Postgres
Um esquema por ambiente
Valkey
Cada serviço limitado às suas próprias chaves
A única saída
Proxy de saída
Para todos os URLs indicados pelos clientes
Descoberta, JWKS, fim de sessão
Apenas endereços públicos
Isolamento
Nada de importante é partilhado.
Cada ambiente de um projeto tem o seu próprio esquema Postgres, as suas próprias chaves de assinatura e os seus próprios segredos, selados com a sua própria chave de dados. O seu emissor é um host no domínio dos inquilinos, e os seus cookies são restritos ao host, por isso um navegador nunca envia o cookie de um ambiente a outro.
usheridentity.com
O site, a Usher Identity Console, as contas Usher Identity
*.usherid.com
Um emissor por ambiente, num domínio separado
Os utilizadores, as sessões e os tokens ficam num esquema criado para este ambiente. As consultas correm nesse esquema, nunca numa tabela partilhada com uma coluna de inquilino.
Copie o segredo de cliente Google selado de Acme em produção para Northwind em produção.
Cifragem em repouso
Cifragem de envelope, presa ao seu lugar.
Os segredos que confia ao Usher Identity são selados com AES-256-GCM sob uma chave de dados que pertence a um só ambiente. As próprias chaves de dados são encapsuladas por uma chave-mestra com versões, guardada fora da base de dados.
- Chaves de dados por ambiente
- Comprometer a chave de dados de um ambiente não revela nada sobre a de outro.
- Associação por AAD
- O ambiente e a finalidade ficam associados a cada texto cifrado, por isso um valor não pode ser movido entre linhas nem entre inquilinos.
- Chaves com versões
- Cada valor selado regista a versão da chave com que foi criado, para que as chaves possam ser rodadas e os valores antigos voltem a ser encapsulados.
- Autenticada
- A etiqueta do GCM faz com que um valor adulterado não abra, em vez de ser decifrado como outra coisa qualquer.
Chave-mestra
Guardada fora da base de dados, com versões
Chave de dados, uma por ambiente
Encapsulada 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 pormenores, tratados com cuidado.
Palavras-passe, se as usar
Com hash Argon2id ao custo recomendado pela OWASP (19 MiB, duas passagens), e com um limite de quantos cálculos correm em simultâneo, para que uma avalanche de inícios de sessão não deite o serviço abaixo. As novas palavras-passe são comparadas com fugas de dados conhecidas através da API de intervalos do Have I Been Pwned, que só vê um prefixo curto do hash da palavra-passe. O comprimento mínimo predefinido é de 12 caracteres.
Nada guardado que possa ser reutilizado
Os segredos de cliente, os tokens, os tokens das ligações mágicas e os códigos por e-mail são guardados com hash. Os códigos de recuperação são cifrados. Um código de autorização dura cinco minutos; um código por e-mail permite três tentativas.
Limites de pedidos em todas as portas
O início de sessão, o registo, os códigos por e-mail, as ligações mágicas, as reposições de palavra-passe e as verificações do segundo fator têm cada um o seu limite: dez inícios de sessão com palavra-passe 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 à volta dele: só correm os scripts desta origem que tragam o nonce, os formulários só são submetidos para a mesma origem, e outros sites não podem incorporar a página.
Um registo de auditoria em que pode confiar
As alterações a espaços de trabalho, projetos e ambientes são escritas num registo só de acréscimo, com cada entrada encadeada por hash à anterior, para que uma entrada editada ou em falta se note.
Um proxy de saída para os URLs dos clientes
Cada pedido que o Usher Identity faz a um endereço indicado por um cliente (descoberta OIDC, JWKS, fim de sessão por back-channel) sai por um único proxy. Este resolve o nome uma vez, recusa endereços privados, de loopback, link-local e de metadados da nuvem, e liga-se ao endereço que verificou, para que um ataque de DNS rebinding não transforme o URL de um cliente num endereço interno.
Identificadores que nunca são atribuídos duas vezes
O identificador de um ambiente de produção é o primeiro rótulo do seu emissor. A Console só está aberta por convite, um Lobby denunciado por phishing é suspenso, e um identificador já usado nunca volta a ser atribuído, porque apps antigas podem ainda confiar nos seus tokens.
Sessões que terminam quando quer
O Usher Identity verifica as suas próprias sessões em cada pedido, em vez de confiar numa cópia em cache, por isso uma sessão que termine acaba de imediato. Os tokens de acesso têm vida curta (dez minutos, por predefinição), e a sua API pode fazer a introspeção deles.
Divulgação responsável
Encontrou alguma coisa? Diga-nos primeiro.
Se acha que encontrou um problema de segurança no Usher Identity, gostaríamos de saber, e vamos trabalhar consigo para o resolver.
- O que encontrou, onde, e como o reproduzir.
- O que alguém poderia fazer com isso, tanto quanto percebe.
- Como podemos entrar em contacto consigo, e se quer que o seu nome seja referido.
Teste apenas em ambientes que sejam seus, não aceda a dados de outras pessoas e dê-nos um prazo razoável para resolvermos o problema antes de o divulgar. Para denunciar uma página que se faz passar por um início de sessão do Usher Identity, consulte Denunciar abuso.