Isolamento imposto pela base de dados, não pelo código da aplicação.
Todos os pedidos que alteram algo são autorizados três vezes, em três lugares que falham de forma independente. Por trás deles estão 868 políticas de segurança ao nível da linha, pelo que um erro num handler é um bug e não uma fuga de dados. Esta página está escrita para quem tem de nos aprovar.
Como a Lurno protege os dados de uma organização dos de outra
A Lurno autoriza todos os pedidos de alteração em três lugares independentes. A interface verifica uma permissão antes de mostrar um controlo. O servidor exige a mesma permissão antes de tocar nos dados e recusa se a resposta for não. A base de dados aplica uma política de segurança ao nível da linha que decide que linhas a consulta pode sequer devolver. As três têm de passar. Existem 868 políticas destas ao longo de 676 migrações, e as tabelas da aplicação vivem em 14 esquemas de domínio em vez do esquema public predefinido, pelo que as linhas de uma organização permanecem inacessíveis a partir da sessão de outra, mesmo quando o código acima delas está errado. As alterações administrativas são escritas num registo de auditoria apenas por acréscimo, cujas linhas são encadeadas com SHA-256 e podem ser verificadas com uma consulta. A Augmental Learning Inc. está alinhada com as práticas da ISO 27001; não detém qualquer certificado ISO 27001 nem relatório SOC 2, e dizemo-lo no questionário em vez de deixar que um comprador assuma o contrário.
- Autorização em três portas
- Um modelo em que um pedido é autorizado três vezes, por três mecanismos que falham de forma independente. A primeira porta é a interface: esconde um controlo para o qual a pessoa autenticada não tem permissão. A segunda porta é o servidor: o handler exige a permissão antes de tocar nos dados e lança um erro se a resposta for não. A terceira porta é a base de dados: uma política de segurança ao nível da linha na tabela restringe as linhas que a consulta pode devolver. A primeira porta é conveniência, a segunda é a fronteira principal, e a terceira é a que continua a segurar quando a segunda é contornada.
Três portas, e o que está por trás de cada uma
Um pedido, autorizado três vezes
Um controlo na interface pergunta se a pessoa autenticada detém uma permissão antes de se mostrar. O handler no servidor exige a mesma permissão antes de fazer qualquer trabalho. Depois, a base de dados aplica uma política que decide que linhas a consulta pode ver. Três mecanismos, três lugares distintos onde é preciso acertar, e basta um deles dizer não para o pedido terminar.
- A verificação na interface é conveniência, não uma fronteira. Esconde um botão; não protege uma tabela.
- Todas as verificações passam por um só catálogo de permissões e uma só função. Nenhum handler lê o nome de uma função e decide por si o que essa função significa.
- Uma função atribuída num ramo da árvore de uma organização propaga-se por esse ramo — e as políticas da base de dados leem a mesma árvore que a interface lê, pelo que as duas não podem discordar.
868 políticas ao longo de 676 migrações
O isolamento é esquema, não convenção. As tabelas são criadas com segurança ao nível da linha ativada e com políticas que delegam na mesma função de permissões que o servidor chama, e uma verificação das migrações procura tabelas a que foi concedido acesso sem uma política por trás. O número não é uma figura de marketing — é o que a base de dados devolve quando lhe perguntamos quantas políticas está a aplicar.
- As políticas não incorporam a sua própria lógica. Chamam a função de permissões, para que a resposta não possa divergir daquilo que o servidor decidiu um instante antes.
- As políticas de escrita têm uma cláusula de verificação além da cláusula de leitura, para que uma inserção não possa colocar uma linha numa organização para a qual quem escreve não tem permissão.
- Onde uma vista expõe dados pessoais, o acesso é concedido coluna a coluna. Uma concessão sobre a tabela inteira anularia silenciosamente a proteção ao nível da coluna, por isso não é usada.
Catorze esquemas de domínio, nunca o público
As tabelas da aplicação vivem em catorze esquemas nomeados — um para identidade e acessos, um para organizações, um para media, e assim por diante. Nada do que importa está no esquema public predefinido, que é o lugar onde uma concessão acidental ou uma predefinição permissiva têm mais probabilidade de expor dados. Os media privados não têm quaisquer políticas de armazenamento para browsers autenticados: cada leitura é assinada por um servidor que verificou primeiro a linha a que pertence, e cada carregamento é emitido da mesma forma.
- Os tokens de uso único — convites, reposições de palavra-passe, recuperação de conta — são guardados como hashes com sal. O token em bruto é mostrado uma vez, no email, e nunca mais.
- Só a marca é pública. O logótipo e o favicon de uma organização têm de aparecer antes de alguém iniciar sessão; os avatares e os media das lições não, por isso continuam assinados.
Provar depois o que aconteceu
Um registo de auditoria que ninguém consegue verificar é um ficheiro de log com melhor marketing. Este é apenas por acréscimo e denuncia adulterações, e verificá-lo é uma consulta.
Um registo apenas por acréscimo
As alterações administrativas são escritas como eventos com autor, ação, recurso, organização e o conteúdo antes e depois. Nada atualiza uma linha de auditoria. O caminho de escrita apenas acrescenta.
Uma cadeia de hashes SHA-256
Cada evento guarda o hash do anterior e um hash de si próprio, ambos atribuídos por um trigger da base de dados e não pelo código que registou o evento. Altere uma linha e todos os hashes seguintes deixam de coincidir.
Verificação que pode ver correr
Uma função de verificação percorre a cadeia e indica a primeira linha onde ela quebra. Corremo-la à sua frente durante uma auditoria.
Revisões de acesso
Quem detém que função, em que organização, revisto com uma periodicidade definida em vez de à hora da auditoria. Uma remoção é um evento de auditoria como qualquer outro.
Duas pessoas para as ações destrutivas
Anonimizar ou eliminar uma pessoa é um pedido e, depois, uma aprovação separada. Quem pede não pode aprovar o seu próprio pedido, e ninguém se pode visar a si próprio.
Sessões que pode terminar
Uma pessoa autenticada pode revogar as suas outras sessões, e uma sessão revogada fica bloqueada na verificação de permissões seguinte, e não quando o seu token calhar expirar.
Do consentimento ao apagamento, com um prazo em cada passo
Cada inquilino é o responsável pelo tratamento dos dados dos seus formandos e a Lurno é o subcontratante. A mecânica abaixo é o que torna essa divisão real e não apenas contratual.
- 01
Consentimento, com uma versão associada
Cada política a que uma pessoa consente tem uma versão. Altere a política e o consentimento antigo deixa de contar: a pessoa é novamente questionada, e fica registado com o que concordou e quando. O tratamento por AI é um consentimento separado — retire-o e nada é enviado a qualquer fornecedor.
- 02
Um pedido de acesso do titular, sob a forma de assistente
Um administrador percorre o pedido em vez de o improvisar: identificar o titular, reunir o que está guardado em toda a plataforma, produzir a exportação. Portabilidade significa legível por máquina — JSON e CSV, não um PDF com uma captura de ecrã.
- 03
Retenção com data de fim
Os dados pessoais têm um prazo de retenção por categoria em vez de viverem para sempre por omissão. As contas inativas, os convites expirados e as sessões obsoletas têm todos uma data a partir da qual deixam de existir.
- 04
Apagamento sob a regra de duas pessoas
Um administrador pede, um segundo aprova, e só então é executado. Quem pede nunca pode aprovar, e nenhum dos dois se pode visar a si próprio. O apagamento chega às tabelas que referenciam a pessoa, e não apenas à linha do perfil.
- 05
Um registo de violações com um relógio de 72 horas
Um incidente é uma linha com um prazo calculado em 72 horas a partir da deteção, e lembretes que continuam a disparar até ser fechado. O relógio começa na deteção, não no momento em que alguém se lembra do Artigo 33.º.
Onde os dados ficam de facto
Armazenamento de media que pode apontar para outro lado
Os ficheiros são escritos através de uma interface de armazenamento com quatro implementações: Supabase Storage, Amazon S3, Azure Blob Storage e Google Cloud Storage. É normalmente essa a resposta honesta a um requisito de localização de dados — uma instalação pode escrever ficheiros num bucket na região que é obrigado a usar, em vez de esperar que um fornecedor abra uma. Diga-nos o requisito cedo e dir-lhe-emos com clareza se está ou não cumprido hoje.
- A base de dados, a autenticação e as funções em que a API corre são alojadas pela Supabase. Essa é a única dependência que não pode configurar de outra forma, e está nomeada no DPA.
- Os domínios personalizados de cada organização são servidos através da Cloudflare, com certificados emitidos automaticamente, pelo que um formando em Beirute ou em Milão vê o seu domínio e não o nosso.
Análises de produto na UE, com os formandos de fora
As análises da plataforma passam pela PostHog na sua região da UE, atrás de uma abstração que permite substituir o fornecedor sem tocar no produto. A repetição de sessão é mascarada e nunca grava formandos — a superfície do formando não está sequer instrumentada para repetição.
- Os campos de texto e tudo o que esteja marcado como dado pessoal são mascarados no browser, antes de qualquer repetição ser enviada para algum lado.
- As análises dependem de consentimento e estão desligadas a menos que uma organização as ligue. Nada relativo a um menor é objeto de definição de perfis, em nenhuma superfície.
O que acontece ao texto antes de chegar a um fornecedor de AI
A mensagem de um formando, um PDF carregado, uma pergunta escrita no copiloto: tudo isso é conteúdo, nada disso é instrução. Essa distinção é imposta, não pedida num prompt.
Classificação de injeção
A entrada não confiável é classificada antes de a chamada real ser feita. O texto que tenta redirecionar o modelo é assinalado em vez de executado.
Uma cerca aleatória
O texto não confiável é envolvido numa etiqueta gerada por pedido, que não consegue adivinhar, e essa etiqueta é retirada do próprio conteúdo. O truncamento volta a fechar a cerca em vez de a deixar aberta.
Ocultação antes da chamada
Os nomes, emails e identificadores são substituídos antes de algo sair para um fornecedor. A classificação corre sobre uma submissão anonimizada; o mapa de volta ao formando fica no nosso servidor.
Validação do esquema de saída
Todas as respostas são validadas contra um esquema. Uma resposta malformada tem direito a uma tentativa de reparação e depois falha, em vez de ir parar a um curso.
Um rasto da proposta à alteração
Os pedidos, os rascunhos aceites e os rascunhos rejeitados são entradas separadas no mesmo registo encadeado por hash. O que o modelo sugeriu fica ao lado do que uma pessoa aplicou.
Como as pessoas iniciam sessão
Escrito como quem faz uma revisão de segurança precisa: o que existe hoje e o que não existe.
Contas por convite
As contas são criadas por um administrador ou por um convite — não existe registo self-service. As ligações de reposição e de recuperação são de uso único e guardadas em hash.
Início de sessão via parceiro (silent SSO)
Um sistema parceiro que já autenticou alguém pode entregá-lo com uma asserção assinada, para que o formando nunca veja um segundo início de sessão. É configurado por organização, com chave própria, e é revogável.
Início de sessão único SAML e OIDC
PlaneadoNão está construído. Se a sua implementação depender do Entra ID ou do Okta, diga-o na primeira chamada e dir-lhe-emos em que ponto está, em vez de dar a entender que já existe.
MFA e passkeys
PlaneadoTambém no roadmap. Hoje, o fornecedor de identidade trata da palavra-passe, as sessões podem ser revogadas pelo seu titular, e a revogação produz efeito na verificação de permissões seguinte.
Todos os que tocam nos seus dados
Cinco, e cada um está nomeado no acordo de tratamento de dados em vez de ser descoberto mais tarde.
| Capability | O que trata | Onde se aplica |
|---|---|---|
| Supabase | Base de dados, autenticação, armazenamento de ficheiros e as funções em que a API corre | O subcontratante principal. O armazenamento de media pode antes apontar para S3, Azure ou GCS. |
| Cloudflare | DNS, TLS e o domínio personalizado em que cada organização é servida | Termina o TLS dos domínios por organização; os certificados são emitidos automaticamente. |
| OpenAI | Geração por AI, tutoria e rascunhos de classificação | Chamada apenas quando um pedido o exige, depois da ocultação. A Anthropic e a Google podem ser configuradas em alternativa, e uma organização pode ligar a sua própria chave. |
| Resend | Email transacional — convites, notificações, reposições | Uma organização pode enviar a partir do seu próprio subdomínio, com a sua própria chave. |
| PostHog | Análises de produto e repetição de sessão mascarada | Região da UE. As superfícies do formando não são gravadas. |
A lista que vale é a que consta do acordo de tratamento de dados, a par do adendo FERPA de privacidade dos dados dos alunos, para escolas. Enviamos ambos antes de uma chamada, e não depois.
WCAG 2.1 AA, e o que não temos
A Lurno é construída segundo a WCAG 2.1 AA. As verificações automáticas do axe correm em integração contínua, pelo que uma falha de contraste ou uma etiqueta em falta quebram uma build em vez de chegarem a uma versão. Os percursos de teclado, o foco visível e as preferências de movimento reduzido vivem na biblioteca de componentes em vez de serem acrescentados ecrã a ecrã. O produto está disponível em inglês, francês, árabe e italiano, e o árabe é da direita para a esquerda de ponta a ponta, não um esquema da esquerda para a direita traduzido.
O que não temos é um VPAT nem uma auditoria de acessibilidade feita por terceiros, e preferimos escrevê-lo aqui a enterrá-lo na resposta à pergunta 47. Se um relatório formal de conformidade for uma condição de compra, levante a questão cedo — é uma conversa de âmbito, não uma caixa para assinalar.
Respondidas antes de ter de enviar o questionário
As páginas para que esta continua a apontar
Envie-nos o questionário.
Grande parte dele está respondida acima. Traga o resto — localização dos dados, retenção, subcontratantes, o DPA — a uma chamada, e responderemos nas mesmas palavras simples que usámos aqui.