Segurança

A decisão de segurança mais importante do Kanbanly é onde se verificam as permissões. Não se verificam no ecrã, nem no código que consulta a base de dados: verificam-se na própria base de dados, com políticas de segurança ao nível da linha.

A diferença é enorme e vale a pena compreendê-la. Se as permissões forem verificadas nas consultas, é preciso lembrar-se em cada uma delas: nas mais de cem que esta aplicação faz, esquecer-se numa é uma questão de tempo, e a que se esquecer não dará qualquer erro — mostrará dados que não devia, e será descoberta quando alguém se queixar. Com políticas na base, a verificação aplica-se a todas as leituras por definição, sem que nenhuma consulta se tenha de lembrar. Uma consulta mal escrita devolve menos do que esperava, não mais.

Sobre essa base estão construídos os papéis de quadro — administrar, editar, comentar, observar —, a visibilidade dos espaços de trabalho, o acesso dos convidados a um quadro isolado e que campos do seu perfil vê cada um.

As palavras-passe são custodiadas pelo sistema de autenticação da Supabase, cifradas com funções de derivação pensadas para isso. O Kanbanly não guarda palavras-passe na sua própria base de dados, e nem o código da aplicação nem quem a administra podem ler a sua. Quando a esquece não lha podemos dizer: só lhe podemos dar uma via para definir outra.

Também pode entrar com a Google, caso em que a palavra-passe nem sequer existe do nosso lado: quem o identifica é a Google e nós recebemos a confirmação.

A recuperação de palavra-passe é feita por uma ligação enviada para o seu e-mail, com validade limitada. Enquanto uma recuperação está a meio, a aplicação leva-o de volta a terminá-la em vez de o deixar a meio caminho com uma sessão num estado estranho.

O número do seu cartão, a sua data de validade e o seu código de segurança nunca chegam ao Kanbanly. Introduz-os no formulário da Wompi, que é quem os processa e quem está sujeito às normas da indústria de meios de pagamento.

De volta guardamos apenas o necessário para lhe podermos mostrar o que foi cobrado e com quê: o identificador da transação, o montante, a moeda, o estado, a marca do cartão e os seus quatro últimos dígitos. Com isso não se pode cobrar nada.

Cada cobrança leva uma referência única gerada por nós, e é essa unicidade que impede cobrar duas vezes o mesmo período. Os avisos que a plataforma nos envia quando uma cobrança muda de estado vêm assinados, e a assinatura é verificada antes de lhes dar atenção: sem essa verificação, qualquer pessoa que conhecesse o endereço do aviso poderia declarar aprovada uma cobrança que nunca existiu.

Todo o tráfego entre o seu navegador e o Kanbanly vai cifrado com HTTPS, sem exceção e sem possibilidade de ligar de outra forma. O mesmo vale para o tráfego entre a aplicação e a base de dados, e entre a aplicação e os fornecedores de e-mail e de pagamentos.

Os dados guardados estão cifrados em repouso pela infraestrutura da base de dados e do armazenamento de ficheiros.

Os ficheiros anexos dos cartões são guardados num armazenamento separado da base de dados, e a lista de anexos de um cartão está protegida pelas mesmas políticas de acesso que o cartão: quem não pode abrir o cartão não vê os seus anexos.

Há um limite de tamanho por ficheiro, e ainda um teto por plano: um ficheiro que exceda o teto do seu plano é rejeitado e eliminado do armazenamento em vez de ficar ali a ocupar espaço sem que ninguém volte a olhar para ele.

Esta secção não é habitual numa página de segurança, e está aqui de propósito: acreditamos que dizer que falhas encontrámos e como as fechámos diz mais sobre a segurança de um produto do que uma lista de adjetivos.

As funções que podem gerar e-mail a partir de uma conta com sessão têm tetos por pessoa e por janela de tempo, verificados na base de dados e não só no ecrã. Sem eles, um formulário que envia e-mail é uma torneira aberta: alguém de má-fé enche a caixa do apoio e, já agora, queima a quota do fornecedor para tudo o resto que o Kanbanly envia.

As janelas são móveis e não são cortadas à meia-noite, precisamente para que não se possam gastar duas quotas completas com dois minutos de diferença.

Cada alteração à base de dados é uma migração numerada, com a sua explicação escrita de por que é feita e que falha concreta corrige, e com testes que correm contra um PostgreSQL a sério: verifica-se que quem não deve ver algo não o vê, e não apenas que quem deve vê-lo o vê. Verificar só a metade boa é o que deixa passar metade da falha.

O código tem testes automáticos que correm antes de se publicar seja o que for. Vários deles são guardiões: não verificam que algo funciona, mas que uma regra não foi quebrada sem que ninguém desse conta. Cada guardião é quebrado de propósito ao ser escrito, para confirmar que dispara.

As chaves de acesso aos fornecedores vivem em variáveis de ambiente do servidor e não viajam para o navegador. As que têm mesmo de ser públicas são públicas por desenho, e por trás delas estão as políticas da base que impedem fazer algo indevido com elas.

Conte-nos. Não precisa de a saber explicar em termos técnicos nem de provar nada: se algo o deixou ver o que não devia, ou lhe pareceu estranho, queremos saber.

Escreva-nos pelo canal de assistência da aplicação e descreva-a com o detalhe que puder: o que fez, o que esperava e o que aconteceu em vez disso. Se puder juntar uma captura de ecrã, melhor.

Pedimos-lhe duas coisas em troca: que nos dê uma margem razoável para a corrigir antes de a contar em público, e que não aceda a dados de outras pessoas para além do mínimo para confirmar que a falha existe. A quem avisa de boa-fé não vamos atrás.

Ser honestos sobre os limites faz parte disto. O Kanbanly ainda não oferece autenticação em dois passos, nem início de sessão único empresarial, nem certificações de conformidade auditadas por terceiros. Não há um programa de recompensas por falhas.

Se algo disso for imprescindível para a sua organização, diga-nos pela Ajuda: saber quem precisa e para quê é o que decide por que ordem as coisas são feitas.