Segurança e arquitetura

• O sensor corre no seu alojamento, a partir do agendador, fora da pasta pública. Não tem regras próprias. Recolhe impressões digitais e envia-as.
• O servidor central guarda as regras, compara cada relatório com o último estado limpo e decide. A lista de ficheiros a vigiar é definida aqui, não pelo sensor.
• As cópias limpas dos seus ficheiros críticos ficam na nossa infraestrutura, não no seu alojamento. Quem entrar na sua conta de alojamento não as consegue substituir.

• Corre com o seu próprio utilizador de alojamento. Não precisa de acesso root e não instala nada no servidor.
• Lê ficheiros de código e, da base de dados, apenas os registos de administradores, as definições de pagamento e algumas definições da plataforma, como o endereço do site e a lista de extensões.
• Escreve num único caso: quando o servidor central ordena a reposição de um ficheiro de pagamento.
• Nunca apaga um ficheiro. Antes de substituir um, guarda a versão substituída numa pasta privada.

• São enviados: impressões digitais de ficheiros, o conteúdo dos ficheiros de código críticos que mudaram, os nomes de utilizador dos administradores e as impressões digitais (não os valores) dos e-mails e palavras-passe dos administradores e das definições de pagamento.
• Nunca são enviados: encomendas, clientes, números de cartão, nem qualquer página que os seus visitantes vejam.
• Cada mensagem é assinada nos dois sentidos e leva uma marca temporal e um número de utilização única, pelo que não pode ser alterada nem repetida.

A decisão é tomada por regras fixas, não por IA. Assim, os mesmos factos dão sempre a mesma decisão e cada uma pode ser explicada. Têm de se verificar todas as condições seguintes:

• o ficheiro é um ficheiro de pagamento ou de checkout,
• a alteração acrescenta um destino de pagamento que não reconhecemos,
• não está em curso uma atualização da plataforma nem dessa extensão,
• existe uma cópia limpa verificada.

Qualquer outra alteração é comunicada e aguarda a sua aprovação. Não é desfeita.

Antes de escrever, o sensor verifica que o ficheiro em disco continua a ser exatamente o que foi analisado, que não é uma ligação para outro local e que está dentro do seu site. A escrita é feita num só passo, para que não possa ficar um ficheiro meio escrito. Depois, o sensor confirma o resultado ao servidor central.

A versão alterada é guardada como prova. Se a alteração era sua, repõe-na a partir do seu painel com um botão. Cada reposição automática é acompanhada por um registo da decisão: a regra, o ficheiro, o destino, se havia uma atualização em curso e as impressões digitais antes e depois.

Testes controlados em lojas de teste, versão 1.12:

• Tempo entre a adulteração e a reposição, com verificação a cada minuto. Alterámos o endereço de pagamento num ficheiro de pagamento 8 vezes, em momentos aleatórios dentro do minuto. Nas 8 vezes a alteração foi encontrada e o ficheiro limpo reposto na verificação imediatamente seguinte: entre 8 e 57 segundos depois da adulteração, 33 em média. Depois de a verificação começar, a deteção e a reposição demoram menos de um segundo, pelo que a espera é definida pelo intervalo do seu plano.
• 100 alterações controladas de seis tipos, em lojas de teste OpenCart e WooCommerce. As 100 foram encontradas e o ficheiro limpo foi reposto. Na mesma série fizemos 100 alterações normais de programador: nenhuma foi desfeita e nenhuma fez soar um alarme.
• O ficheiro volta a mudar entre a análise e a reposição. A reposição não foi aplicada, a versão mais recente ficou no lugar e foi verificada na passagem seguinte.
• O ficheiro é trocado por uma ligação (symlink) antes da reposição. O sensor recusou escrever e foi enviado um alerta crítico.
• A mesma mensagem é enviada duas vezes, ou alterada pelo caminho. A segunda foi rejeitada como repetição, a alterada por assinatura inválida.
• O servidor central está indisponível. O sensor não alterou nada no site. Quando o servidor voltou, a alteração feita entretanto foi encontrada e o ficheiro reposto. Enquanto o servidor não responde, não há verificações.
• Uma palavra-passe do painel roubada. Foi possível iniciar sessão, mas não aprovar uma alteração: é preciso o código enviado para o e-mail do proprietário. Seis códigos ao acaso falharam e o proprietário foi avisado.
• Anulação de uma reposição a partir do painel. Com o código recebido por e-mail, a alteração voltou a ser colocada na verificação seguinte.
• O ficheiro do próprio sensor é modificado, ou o sensor passa de repente a comunicar muito menos ficheiros. Alerta crítico na verificação seguinte.
• Na página pública aparecem um script de um domínio parecido com um verdadeiro e um formulário que envia dados para outro lado. A verificação externa gerou um alerta crítico.
• São os nossos próprios testes controlados em lojas de teste, na mesma máquina do servidor central. Não são uma auditoria independente, e uma instalação real acrescenta o atraso da rede.

• Os relatórios e as aprovações só estão disponíveis depois de iniciar sessão. Não existem ligações de relatório abertas.
• As palavras-passe são guardadas em hash. Após cinco tentativas erradas, a conta fica bloqueada durante quinze minutos.
• Aprovar uma alteração ou desfazer uma reposição exige também um código enviado nesse momento para o seu e-mail. Uma palavra-passe do painel roubada não chega.
• Cada aprovação e cada anulação fica registada com o utilizador e o endereço de onde veio, e é enviada por e-mail ao proprietário e à nossa equipa.

De seis em seis horas o nosso servidor abre também as suas páginas públicas como um visitante faria e compara os domínios externos que carregam com a vez anterior. Um script novo de um domínio parecido com um verdadeiro ou de um serviço aberto de alojamento de código, ou um formulário que começa a enviar dados para outro lado, gera um alerta. Esta verificação não depende do sensor.

• O histórico de eventos é guardado durante 90 dias.
• As cópias limpas são guardadas enquanto a subscrição estiver ativa e eliminadas quando termina.

• O HachiGuard não substitui uma firewall, um antivírus nem uma verificação PCI. É a camada que repara numa alteração e a desfaz depois de alguém ter entrado.
• Um script que o seu checkout carrega a partir do servidor de um terceiro pode ser alterado nesse servidor sem que nenhum ficheiro seu mude. Reparamos num domínio externo novo, mas não numa alteração dentro de um script que já lá estava.
• Se toda a sua conta de alojamento for tomada, um sensor que corre dentro dela já não pode ser considerado totalmente fiável. Por isso as cópias limpas, as regras e as decisões ficam fora dela, e por isso um sensor calado ou alterado faz soar o alarme.
• Os ficheiros codificados não podem ser lidos. Seguimo-los pela impressão digital e comunicamos cada alteração, mas não os repomos automaticamente.
• A primeira verificação assume o estado atual como limpo. Reveja os administradores e os endereços de pagamento antes de ela correr.
• A deteção acontece com o intervalo do seu plano. Uma alteração feita logo a seguir a uma verificação é vista na seguinte.