Segurança na Lendbox

• A Lendbox corre na Amazon Web Services na região us-east-1, Estados Unidos. A aplicação, a base de dados e os documentos carregados no Amazon S3 estão todos nessa região.
• Os dados são encriptados em trânsito com TLS 1.3.
• Os dados são encriptados em repouso com AES-256. Os volumes de armazenamento da base de dados e da aplicação são encriptados com encriptação AWS EBS. Os documentos carregados e os backups são encriptados do lado do servidor no Amazon S3. As chaves de encriptação são geridas através do AWS Key Management Service.
• Os clientes podem exportar todo o seu conjunto de dados a qualquer momento a partir do produto. Não é necessário pedir-nos.

No encerramento de uma conta, os dados do cliente são conservados durante 60 dias e depois eliminados definitivamente. Durante esse período a conta pode ser reposta mediante pedido.

• A aplicação e a base de dados correm em infraestrutura AWS isolada. As bases de dados não são acessíveis publicamente e não aceitam ligações a partir da internet. A camada web é servida pela Vercel.
• Todo o tráfego de entrada passa pela Cloudflare, que fornece mitigação de DDoS e uma firewall de aplicações web.
• Os ambientes estão separados: produção, staging e desenvolvimento correm em infraestruturas distintas sem credenciais partilhadas. Desenvolvimento e staging não contêm dados de produção.

Os controlos desta secção são operados pelo cliente, não por nós. A instituição configura-os por si própria e pode verificar a qualquer momento o que cada colaborador pode fazer.

• Permissões graduadas por módulo. Cada módulo pode ser definido por colaborador num de seis níveis, apresentados abaixo.
• Atribuição de funções multibalcão. Uma única conta pode receber acesso a vários balcões e ter uma função diferente em cada um, de modo que um gerente de balcão num local é um utilizador de leitura apenas noutro.
• Separação entre quem pede e quem aprova. As ações sensíveis são divididas entre o colaborador que as solicita e o que as aprova. Os circuitos de aprovação são configuráveis por instituição, incluindo o número de etapas e que funções podem agir em cada uma.
• Autenticação multifator. Disponível em todos os inícios de sessão e ativável de forma independente por cada utilizador e colaborador.
• As sessões expiram ao fim de 5 dias e exigem nova autenticação.

• Todas as ações realizadas no produto são registadas com o utilizador que as executou, o registo afetado e uma marca temporal.
• Os registos de auditoria são apenas de acréscimo. Não podem ser editados nem eliminados a partir da aplicação, incluindo pelos administradores da instituição.
• Os períodos contabilísticos encerrados ficam bloqueados contra alterações retroativas.
• Os administradores da instituição podem exportar o histórico de auditoria a qualquer momento.

O histórico de auditoria é conservado durante toda a vida da conta, desde a data em que foi criada. Não há janela móvel nem truncagem.

• As bases de dados têm backup de hora a hora.
• Os backups são encriptados e conservados durante 6 meses.
• Objetivo de ponto de recuperação (RPO): 1 hora.

As reposições são testadas semanalmente num ambiente fora de produção. Um backup que nunca foi reposto não é um backup.

• O acesso aos dados de produção está limitado a uma única pessoa identificada, o fundador. Nenhum outro colaborador, prestador ou terceiro detém credenciais de produção. É uma decisão de conceção deliberada: é a menor superfície possível de pessoas que podem alcançar os dados dos clientes.
• O acesso à produção é nominal e protegido por autenticação multifator. Não são usadas contas nem credenciais partilhadas em nenhum ponto da organização.
• Os segredos e credenciais da aplicação são geridos no Doppler. Não são guardados no controlo de versões nem nas máquinas dos programadores.
• Continuidade: um procedimento documentado de emergência cobre o caso de a pessoa que detém as credenciais de produção estar indisponível. As credenciais de recuperação são guardadas em depósito selado junto de um segundo terceiro identificado, libertadas mediante um gatilho definido, e cada utilização é registada. O procedimento repõe o acesso dos clientes aos seus próprios dados; não concede acesso permanente a ninguém.

As vulnerabilidades de segurança são corrigidas segundo prazos baseados na gravidade, contados a partir do momento em que se confirma que a vulnerabilidade afeta a Lendbox.

• As dependências da aplicação são monitorizadas continuamente com o Renovate, que abre automaticamente pull requests de correção à medida que as versões upstream são publicadas.
• As atualizações de dependências são revistas e integradas num ciclo semanal. Os avisos com exploit conhecido saltam esse ciclo e são tratados de imediato.
• As imagens base do sistema operativo e dos contentores são reconstruídas e reimplantadas mensalmente, e de imediato caso seja divulgada uma vulnerabilidade crítica.

Os serviços aqui listados tratam dados por nossa conta, ao abrigo de contrato.

Os clientes são avisados por e-mail com pelo menos 30 dias de antecedência antes de ser acrescentado um novo subcontratante ou substituído um existente, para o contacto administrativo da conta.

Componentes auto-alojados

Os seguintes correm em infraestrutura que controlamos. São nomeados porque são visíveis a quem inspecione o produto, mas não são subcontratantes: nenhum terceiro recebe dados através deles.

• A saúde da infraestrutura e da aplicação é monitorizada continuamente com Prometheus, Alertmanager e cAdvisor, com os alertas encaminhados para um engenheiro de piquete.
• Em caso de incidente de segurança que afete dados de clientes, os clientes afetados são notificados no prazo de 72 horas após a confirmação. As notificações indicam o que aconteceu, que dados foram afetados, o que fizemos para conter a situação e que ação, se alguma, o cliente precisa de tomar.
• Os incidentes de disponibilidade são publicados na página de estado enquanto estão a ser tratados, e não depois de resolvidos.

• Escreva para [email protected]. Inclua os passos para reproduzir.
• Acusamos a receção de cada comunicação no prazo de 3 dias úteis e damos uma avaliação da gravidade e do prazo de correção previsto no prazo de 10 dias úteis.
• Não intentamos ações legais contra investigadores que comunicam de boa-fé, evitam violações de privacidade e degradação do serviço, e nos dão tempo razoável para corrigir antes da divulgação.
• Os nossos contactos legíveis por máquina são publicados em /.well-known/security.txt.