Declaração de Segurança

Esta Declaração de Segurança descreve as medidas técnicas e organizacionais que a Kapsule Group Limited ("KapsuleHost") implementa para proteger os dados alojados na nossa plataforma. É referenciada pelo Acordo de Processamento de Dados e é atualizada periodicamente para refletir melhorias na nossa postura de segurança.

O nosso princípio fundamental é defesa em profundidade: implementamos múltiplos controlos independentes em camadas para que nenhuma falha isolada exponha os dados dos clientes.

Mantemos políticas documentadas de segurança da informação e privacidade, revistas pelo menos anualmente e atualizadas quando alterações significativas à plataforma ou ao cenário de ameaças o exigem.

Um Responsável de Privacidade designado é responsável pela conformidade com a proteção de dados. As responsabilidades de segurança são atribuídas a indivíduos nomeados na equipa de infraestrutura.

Todo o pessoal recebe formação em privacidade e segurança na admissão e anualmente thereafter. O pessoal com acesso aos sistemas de produção está sujeito a verificações de antecedentes quando permitido pela lei.

Os incidentes de segurança e quase-acidentes são registados, revistos e utilizados para melhorar os controlos de forma contínua.

O acesso aos sistemas de produção e dados dos clientes é regido por controles de acesso rigorosos baseados em funções, construídos segundo princípios de privilégio mínimo: o pessoal recebe apenas o acesso necessário para desempenhar sua função específica.

A autenticação obrigatória de dois fatores (2FA) é aplicada para todo o pessoal com acesso à infraestrutura de produção, ao painel de controle de hospedagem, ao código-fonte e às consolas do fornecedor de nuvem.

Os direitos de acesso são revistos periodicamente e revogados imediatamente em caso de mudança de função ou saída. Os eventos de acesso e escalações de privilégio são registados.

Os ambientes de produção e não-produção são rigorosamente separados. Os ambientes dos clientes são logicamente isolados uns dos outros dentro da plataforma de hospedagem.

Todo o acesso administrativo aos servidores de produção é autenticado através de pares de chaves SSH; a autenticação SSH baseada em password está desativada.

Todos os dados em trânsito entre clientes e a nossa plataforma são encriptados utilizando TLS 1.2 ou superior. Os certificados TLS são emitidos automaticamente e renovados antes do vencimento.

As cópias de segurança fora do local são encriptadas utilizando restic com AES-256. As chaves de encriptação são armazenadas separadamente dos dados de cópia de segurança e são copiadas offline. A perda da chave torna os dados de cópia de segurança irrecuperáveis, razão pela qual as chaves são mantidas em múltiplos locais seguros offline.

As cópias de segurança encriptadas são armazenadas num fornecedor independente de armazenamento de objetos, região Oceania, proporcionando separação geográfica da nossa infraestrutura de alojamento primária.

Os segredos de aplicação, as chaves API e as credenciais são armazenados em ficheiros com permissões restritas nos servidores que os utilizam, acessíveis apenas à conta de serviço que deles necessita, e nunca são incorporados no código fonte nem confirmados no controlo de versão. Os segredos de infraestrutura e de cópias de segurança são adicionalmente protegidos através do SOPS com cifragem age.

Todas as superfícies de produção, incluindo o nosso site de marketing, o painel de controlo do cliente, a nossa API e os sites de clientes alojados por nós, são protegidas por uma firewall de aplicação web (ModSecurity com o OWASP Core Rule Set) executada na nossa própria infraestrutura. O nosso site de marketing conta ainda com a proteção de uma firewall de aplicação web na periferia da nossa CDN, a funcionar em modo de bloqueio. A proteção ao nível da periferia abrange os sites de clientes alojados por nós que são servidos através da nossa CDN. Não se estende ao painel de controlo do cliente nem à nossa API.

Os sites dos clientes são isolados uns dos outros e dos serviços de plataforma partilhados ao nível da rede, não apenas através de contas de sistema de ficheiros e processos separados. Regras de firewall ao nível do kernel (nftables), associadas à própria conta de sistema de cada processo e não à lógica da aplicação, bloqueiam qualquer processo não administrativo, incluindo o próprio código de aplicação de cada site do cliente, de aceder à porta da base de dados partilhada ou à porta do servidor de aplicações própria de qualquer outro site. Isto foi verificado através da realização de tentativas de ligação reais a partir do contexto de execução real de um site, em ambas as direções: bloqueado para um processo de site normal, permitido para a administração do sistema. O mesmo mecanismo também bloqueia o acesso não administrativo a pontos finais internos de serviços de infraestrutura cloud aos quais um processo de site nunca deveria conseguir aceder. Ainda não se estende a todos os serviços partilhados: o serviço de cache partilhado da plataforma está protegido por credenciais próprias de cada site, limitadas aos dados desse site, mas ainda não é adicionalmente bloqueado ao nível da rede da mesma forma que as portas da base de dados e do servidor de aplicações; alargar a mesma proteção de firewall a este serviço é uma melhoria planeada do nosso programa de segurança.

Os sistemas operativos, software de plataforma e dependências de aplicação são atualizados regularmente. As atualizações de segurança são aplicadas automaticamente através do unattended-upgrades, normalmente no prazo de um dia após o lançamento. Para correções de segurança críticas, incluindo as que exigem intervenção manual, como um reinício, ou que ainda não estão disponíveis através de atualizações automáticas, o nosso prazo máximo assumido é de 7 dias a partir do lançamento. A infraestrutura exposta à Internet é verificada regularmente quanto a vulnerabilidades conhecidas.

As regras de firewall restringem o acesso de entrada ao mínimo de portas e serviços necessários. Os serviços desnecessários são desativados por predefinição.

Testes de penetração periódicos são realizados por testadores qualificados independentes. As conclusões materiais são remediadas e retestadas.

As tentativas de autenticação, as alterações de conta e de configuração, e as ações realizadas pelo nosso próprio pessoal nas contas de clientes são registadas numa trilha de auditoria centralizada e inalterável em base de dados, conservada por um período mínimo de 90 dias. Os registos de infraestrutura e de sistema (registos do servidor web, da firewall e do sistema operativo) são conservados localmente em cada servidor de produção, acessíveis apenas ao pessoal autorizado, e são ainda enviados de hora a hora para um armazenamento externo independente de escrita única, com um bloqueio de retenção de 90 dias: uma vez escrito, um arquivo de registos não pode ser eliminado nem substituído por ninguém, incluindo nós, durante esse período, pelo que um servidor comprometido não consegue apagar as provas do que nele ocorreu.

A saúde da plataforma e os sinais de segurança são monitorizados 24x7. Os alertas são encaminhados para pessoal de plantão para investigação imediata.

Mantemos um plano de resposta a incidentes documentado com níveis de gravidade definidos, percursos de escalação e procedimentos de comunicação. O plano é revisto e testado pelo menos anualmente.

Na eventualidade de uma Violação de Privacidade Notificável confirmada que afete Informações Pessoais do Cliente, notificaremos os clientes afetados dentro de 72 horas após tomarmos conhecimento, conforme exigido pela Privacy Act 2020 e pelo Data Processing Agreement.

Sentry é utilizado para rastreamento de erros em tempo real e monitorização do desempenho das aplicações em toda a stack da plataforma.

Os ficheiros do site do cliente, bases de dados e dados de correio eletrónico são copiados diariamente para armazenamento de objetos externo (região Oceânia) utilizando restic. As cópias de segurança são encriptadas em repouso com AES-256.

A retenção de cópias de segurança é um mínimo de 30 dias em todos os planos pagos. Os planos superiores mantêm as cópias de segurança durante mais tempo: 90 dias, 1 ano ou 7 anos, consoante o nível contratado. Consulte o Acordo de Nível de Serviço para detalhes de retenção específicos do plano.

Os procedimentos de restauro estão documentados nos nossos runbooks internos e são testados periodicamente. A equipa de plataforma realiza exercícios de restauro para validar a integridade das cópias de segurança.

A base de código da plataforma KapsuleHost (incluindo scripts de configuração e provisionamento) é copiada diariamente para repositórios GitHub privados na organização kapsulenz, fornecendo um caminho de recuperação independente para a própria plataforma.

Os procedimentos de recuperação após desastres para cada componente de infraestrutura estão documentados com um tempo de recuperação alvo específico para esse componente: até 8 horas para o servidor de alojamento, em função do volume de dados do cliente a restaurar; de 2 a 4 horas para a plataforma de correio; e 4 horas para o portal do cliente.

Todo o pessoal com acesso a dados de clientes está vinculado por obrigações de confidencialidade, seja por contrato ou por lei.

Mantemos acordos escritos de processamento de dados com todos os sub-processadores. Estes acordos exigem que os sub-processadores implementem proteções não menos protetoras do que as contidas no nosso Acordo de Processamento de Dados, incluindo obrigações de confidencialidade, segurança e processamento limitado ao fim específico.

A nossa lista de sub-processadores é revista pelo menos anualmente quanto à sua adequação contínua. Os sub-processadores são avaliados em relação aos nossos requisitos mínimos de segurança antes do seu envolvimento.

A lista atual de sub-processadores é publicada em kapsulehost.com/legal/sub-processors.

Os servidores de produção são operados em centros de dados de terceiros. Não somos proprietários nem operamos qualquer centro de dados, pelo que a segurança física, os controlos ambientais, a redundância de energia e a supressão de incêndios são responsabilidade do operador da instalação, e os nossos acordos com subprocessadores de infraestrutura exigem proteções não menos protetoras do que as previstas no nosso Data Processing Agreement. Não publicamos o país de cada servidor de produção individual: a nossa capacidade desloca-se à medida que acrescentamos regiões, e uma localização publicada uma vez torna-se incorreta no dia em que muda, sem que ninguém a tenha editado. Os subprocessadores que contratamos estão listados em kapsulehost.com/legal/sub-processors.

O acesso físico ao hardware do servidor é restrito ao pessoal autorizado do centro de dados. O pessoal da KapsuleHost não tem acesso físico rotineiro ao hardware de produção; todo o acesso administrativo é realizado remotamente através de canais encriptados.

Os meios de armazenamento desativados são apagados ou destruídos de forma segura de acordo com os procedimentos do operador do centro de dados antes da reutilização ou eliminação.

Os segredos de aplicação, as chaves API e os valores de configuração sensíveis são armazenados em ficheiros com permissões restritas nos servidores que os utilizam e nunca são confirmados em repositórios de código-fonte. Os segredos de infraestrutura e de cópias de segurança são geridos separadamente através do SOPS com cifragem age.

Os testes de pré-lançamento incluem execuções de testes funcionais, de regressão e focados em segurança. As alterações aos fluxos de autenticação, pagamento ou manipulação de dados recebem escrutínio adicional.

A entrada direcionada ao cliente é validada e desinfectada em todos os limites da aplicação. Aplicamos defesas padrão contra riscos do OWASP Top 10, incluindo injeção SQL, cross-site scripting e falsificação de pedido entre sites.

Autenticação de KPanel: as palavras-passe são processadas com Argon2id (resistente à memória, resistente à gravação por GPU). As novas palavras-passe são verificadas contra a base de dados Have I Been Pwned através da procura de prefixo k-anonymity antes da aceitação. O início de sessão suporta autenticação de dois fatores baseada em TOTP, códigos de uso único por SMS e chaves de hardware (WebAuthn/FIDO2). O início de sessão OAuth é suportado através do Google, GitHub, Apple Sign In e Discord. Google e Apple Sign In são verificados contra o próprio endpoint JWKS do fornecedor; GitHub e Discord não publicam um endpoint JWKS para início de sessão OAuth, pelo que esses dois são verificados em vez disso chamando diretamente a API de conta do próprio fornecedor com o token de acesso que emite. As tentativas de início de sessão são limitadas por taxa por endereço IP, e as tentativas falhadas repetidas contra uma única conta são bloqueadas por um período. Os tokens de sessão são criptograficamente aleatórios e criptograficamente assinados, e expiram após 30 dias de inatividade.

Os dados dos clientes são logicamente segregados nas camadas de alojamento, base de dados e aplicação. Os ficheiros e bases de dados de cada cliente são isolados em contas de sistema separadas, sem acesso entre clientes.

O email é isolado e protegido com medidas próprias. Cada caixa de correio é uma conta separada, isolada pelos controlos de acesso do nosso servidor de correio, e inicia sessão com as suas próprias credenciais. Os nossos servidores de correio aceitam apenas TLS 1.2 e TLS 1.3: TLS 1.0 e 1.1 são recusados em todas as portas de correio, tanto em IPv4 como em IPv6. Não disponibilizamos de todo IMAP nem POP3 sem encriptação, e nenhum método de início de sessão, de qualquer tipo, é disponibilizado antes de uma ligação estar encriptada. A porta de correio entre servidores não disponibiliza qualquer início de sessão. Cinco inícios de sessão falhados em cinco minutos bloqueiam durante uma hora o endereço IP de origem, e o servidor de correio bloqueia ainda, de forma independente, os endereços IP de onde partem ligações abusivas repetidas. Os dados das caixas de correio são armazenados em volumes encriptados (AES-256-XTS), e as cópias de segurança do correio são encriptadas. Cada domínio para o qual alojamos correio recebe as suas próprias chaves de assinatura DKIM, em RSA e em Ed25519, juntamente com um registo SPF. O nosso próprio domínio, kapsulehost.com, publica uma política DMARC de reject e uma política SPF que termina em -all, pelo que os servidores de receção que verificam DMARC recusam o correio que o falsifica. Publica também uma política MTA-STS aplicada, com relatórios TLS, que indica aos servidores de envio que nos entreguem o correio apenas através de uma ligação encriptada a um certificado verificado.

Quando um cliente termina o seu serviço, as Informações Pessoais do Cliente são disponibilizadas para exportação durante 30 dias e depois eliminadas permanentemente dos sistemas ativos. As cópias de segurança encriptadas são purgadas no próximo ciclo de rotação programado, dentro de 30 dias após a eliminação dos sistemas ativos.

Os procedimentos documentados de eliminação de dados asseguram que os dados são removidos de todos os sistemas relevantes, incluindo bases de dados ativas, caches e armazenamento de aplicação, não apenas do armazenamento de dados primário.

Os procedimentos para o tratamento de pedidos de Titulares de Dados (acesso, correção, eliminação) são documentados e testados. As ferramentas de exportação do KPanel permitem que os clientes recuperem os seus dados a qualquer momento durante o período de vigência do serviço.

Se tiver perguntas sobre as nossas práticas de segurança ou deseje comunicar uma vulnerabilidade suspeita, contacte-nos em privacy@kapsulehost.com.

Kapsule Group Limited, New Zealand.