formexposed
Começar

Medidas Técnicas e Organizativas

Este documento é publicado em várias línguas. Em caso de divergência entre as versões linguísticas, prevalece a versão polaca.

Versão 1.1 · Última atualização: 22 de outubro de 2026

Medidas nos termos do Art. 32 do RGPD com as quais LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Poland, protege o serviço formexposed. Esta página faz parte integrante do Acordo de Tratamento de Dados como Anexo 2.

1. Âmbito e princípio

As medidas aplicam-se a todos os dados tratados pelo serviço: aos dados que tratamos por conta dos nossos Clientes (descritos no Acordo de Tratamento de Dados) e aos dados relativamente aos quais somos nós próprios o responsável pelo tratamento, como as contas de cliente e os registos. Não existem níveis de proteção distintos para uns e outros; o que protege a conta protege também os dados tratados enquanto subcontratante.

Estrutura nos termos do Art. 32(1) do RGPD. A pseudonimização e a cifragem (alínea a)) são tratadas na secção 4; a confidencialidade, integridade, disponibilidade e resiliência permanentes dos sistemas (alínea b)) nas secções 3, 5, 6 e 7; a capacidade de restabelecer a disponibilidade de forma atempada após um incidente (alínea c)) na secção 7.1; o processo para testar, apreciar e avaliar regularmente a eficácia (alínea d)) na secção 9. Selecionámos as medidas com base nos riscos descritos na nossa Avaliação de Impacto sobre a Proteção de Dados, tendo em conta as técnicas mais avançadas e os custos de aplicação.

Princípio: medido em vez de pretendido. Só é aqui indicado o que foi efetivamente implementado no código ou no funcionamento. O que está planeado mas ainda não implementado é expressamente enumerado como “planeado” na secção 10. Uma medida que aqui não conste não está tacitamente em vigor.

Os nomes de máquinas, endereços internos, portas, nomes de utilizador e versões de software não são deliberadamente indicados. Não ajudam ninguém a avaliar as medidas, mas ajudam quem as pretenda contornar. Quem deles necessitar para uma auditoria nos termos do Acordo de Tratamento de Dados recebê-los-á no âmbito dessa auditoria, sob confidencialidade, na medida em que sejam necessários para a auditoria.

2. Estrutura do serviço

O serviço funciona em dois servidores próprios do prestador na Polónia, situados na mesma rede interna:

  • Servidor web com base de dados. Disponibiliza a aplicação, contém a base de dados, envia notificações e efetua cópias de segurança dos dados. Só ele está configurado para aceitar pedidos provenientes da internet.
  • Servidor de análise. Realiza as verificações de sítios web de terceiros e próprios num navegador e executa o modelo de linguagem que classifica formulários individuais e acrescenta código no “Fix it for me”. Não está configurado para aceitar pedidos provenientes da internet, mas vai buscar ele próprio as suas tarefas ao servidor web e devolve-lhe os resultados.

Não intervém no funcionamento qualquer fornecedor de alojamento, de centro de dados ou de serviços de nuvem, e nada é enviado para um serviço externo de IA. Os terceiros que recebem dados constam da página Subcontratantes Ulteriores.

3. Confidencialidade

3.1 Controlo do acesso físico

Os servidores estão localizados em instalações do prestador na Polónia que não estão abertas ao público. Só o proprietário tem acesso (segundo declaração do operador). O endereço exato da localização não é deliberadamente aqui indicado.

3.2 Controlo de acesso: início de sessão no serviço

  • As palavras-passe são armazenadas apenas como hash, utilizando o método padrão do PHP (bcrypt). Se o método padrão mudar, o hash é renovado no início de sessão seguinte. Numa tentativa de início de sessão com um endereço desconhecido, o servidor calcula igualmente um hash, para que o tempo de resposta não revele se existe uma conta. Do mesmo modo, a resposta a um pedido de reposição da palavra-passe não revela, nem pela sua redação nem pela sua duração, se a conta existe; os e-mails de reposição são enviados para o mesmo endereço no máximo três vezes por hora. As novas palavras-passe têm de ter, pelo menos, dez caracteres e não podem exceder 72 bytes (UTF-8), porque o bcrypt não tem em conta mais bytes. A alteração da palavra-passe termina a sessão em todos os outros dispositivos; a reposição através da ligação termina a sessão em todos os dispositivos, e a ligação só é válida uma vez.
  • Bloqueio após tentativas falhadas. Os inícios de sessão falhados são contados por endereço IP; após demasiados num curto espaço de tempo (atualmente oito em 15 minutos), o início de sessão a partir desse endereço é temporariamente bloqueado. Um início de sessão bem-sucedido repõe este contador. As tentativas são apagadas após sete dias. Além disso, antes de cada verificação da palavra-passe, é contada uma tentativa por conta (para um endereço desconhecido, por endereço introduzido) e por endereço IP, incluindo as tentativas bem-sucedidas: atualmente, no máximo oito por conta a partir do mesmo endereço IP e 80 por endereço IP em 15 minutos; aplica-se um limite consideravelmente mais elevado por conta para todos os endereços em conjunto, contra tentativas de adivinhação distribuídas. Assim, as tentativas falhadas a partir de outro endereço já não bloqueiam o titular de uma conta. Estes contadores contêm apenas uma chave HMAC, nenhum endereço de e-mail ou IP em texto simples, e expiram com a respetiva janela temporal. Se o armazenamento dos contadores não estiver disponível, o início de sessão é recusado, e não permitido. O mesmo tipo de limite aplica-se à confirmação da palavra-passe antes de uma alteração da palavra-passe ou do endereço, à ativação ou desativação do segundo fator, à transferência de um espaço de trabalho, à exportação de dados e à eliminação da conta (cinco tentativas por conta em 15 minutos), aos registos (dez por endereço IP por hora) e às palavras-passe dos portais de clientes (dez tentativas por portal e endereço IP, 50 por portal em 15 minutos).
  • Segundo fator. Qualquer conta pode ativar o início de sessão com um código de utilização única nos termos da RFC 6238 (TOTP). O segredo correspondente é armazenado cifrado na base de dados; a chave não é armazenada na base de dados, pelo que uma extração da base de dados, por si só, não basta. Um código aceite não é válido uma segunda vez. Dez códigos de recuperação são armazenados apenas como hash. Os códigos de utilização única e de recuperação estão limitados a dez tentativas por conta em 15 minutos, inclusive durante a configuração.
  • Área de administração apenas com segundo fator. A área de administração do operador só se abre a contas com o segundo fator ativado. A lista de verificação da configuração assinala todas as contas de administrador sem segundo fator.
  • Sessões. O cookie de sessão não pode ser lido por scripts (HttpOnly), só é enviado através de HTTPS (Secure) e não é enviado com pedidos de sítios de terceiros que possam alterar algo (SameSite=Lax). No início de sessão, é criado um novo ID de sessão, para que um ID previamente introduzido deixe de ser válido; o servidor não aceita um ID de sessão que não tenha sido ele próprio a emitir. Cada conta vê os seus dispositivos com sessão iniciada e pode terminar a sessão em cada um deles individualmente.
  • “Manter sessão iniciada” é facultativo e válido durante 30 dias, mas não para contas com direitos de administração; estas iniciam sempre sessão com palavra-passe e segundo fator. O token é composto por duas partes; a parte de verificação é armazenada na base de dados apenas como hash. Cada utilização substitui-o por um novo e, mesmo com pedidos simultâneos, cada token só é válido uma vez, para que um token roubado seja detetado, o mais tardar, na visita legítima seguinte.
  • Ligações em e-mails. As ligações para confirmar o endereço e repor a palavra-passe são armazenadas na base de dados apenas como hash. A ligação de reposição é válida durante uma hora, a ligação para confirmar um registo durante 72 horas e a ligação para confirmar um endereço alterado durante 24 horas. Se o endereço de e-mail for alterado, uma ligação de reposição em aberto deixa de ser válida.
  • Interfaces. As chaves de API, os códigos de ligação das extensões e os códigos de implementação são armazenados apenas como hash. As chaves de API só podem ser utilizadas um número limitado de vezes por minuto; os códigos de ligação das extensões são válidos durante 15 minutos e apenas uma vez.
  • Proteção contra bots nos formulários públicos (registo, início de sessão, palavra-passe, verificação, ferramenta de cabeçalhos, opt-out, apoio e contacto): Google reCAPTCHA, que só é carregado no momento da submissão. Só é aceite uma resposta válida da Google com uma pontuação suficiente para a ação exata do formulário; se a Google não responder no prazo de três segundos, a submissão é recusada. Os pormenores constam da Política de Privacidade.

3.3 Controlo de acesso: administração dos servidores

  • O servidor acessível a partir da internet utiliza um filtro de pacotes para permitir apenas os serviços que oferece e bloqueia automaticamente endereços após repetidas tentativas falhadas de início de sessão na administração do servidor.
  • Os processos automatizados entre os servidores utilizam chaves próprias com direitos estritamente limitados. A chave com a qual o servidor web disponibiliza novas versões do scanner só pode executar uma lista fixa de comandos no servidor de análise e só pode copiar, em modo apenas de escrita, para o diretório do scanner; não é possível iniciar uma sessão interativa com ela, e cada comando rejeitado é registado. Do mesmo modo, o servidor de análise só pode escrever capturas de ecrã num diretório específico do servidor web.
  • O processo que serve o sítio web não tem acesso de escrita à instalação de produção nem uma chave para o servidor de análise. Uma implementação desencadeada na área de administração apenas regista uma tarefa, que é executada por um processo separado.
  • Os segredos, como as credenciais da base de dados e as chaves, são guardados em ficheiros de configuração fora do diretório servido e não são copiados durante a implementação. A configuração do servidor web não é distribuída através da interface web.

3.4 Controlo de autorizações: direitos dentro do serviço

  • Funções. Cada espaço de trabalho tem as funções de proprietário, administrador e leitor. A alteração, a eliminação, o envio de convites e o armazenamento de credenciais estão reservados a proprietários e administradores; só o proprietário pode alterar funções e remover membros. Um convite só é válido enquanto a pessoa que o enviou continuar a ser proprietário ou administrador. Os leitores veem os endereços de webhooks e canais de chat apenas abreviados ao anfitrião, porque o endereço, por si só, permite publicar no canal. A verificação é efetuada no servidor e não apenas na interface.
  • Associação ao espaço de trabalho. Os domínios e as definições só são acessíveis aos membros do espaço de trabalho. Para cada verificação, o Serviço cria um relatório com uma ligação aleatória que não pode ser adivinhada; os resultados e as capturas de ecrã de uma verificação podem ser consultados através desta ligação sem início de sessão, sendo as capturas de ecrã acessíveis apenas juntamente com a ligação do respetivo relatório. A ligação aparece na conta e nos alertas; quem a partilhar partilha o relatório.
  • Os pedidos que alteram o estado exigem um token de segurança por sessão (proteção CSRF), que é comparado em tempo constante.
  • “Ver como cliente”. Para efeitos de apoio, o operador pode ver a aplicação tal como um Cliente a vê. A vista termina ao fim de uma hora, bloqueia alterações à palavra-passe, ao endereço, ao segundo fator, aos dispositivos, à subscrição, à exportação e à eliminação, fecha entretanto a área de administração e é registada. Ao terminá-la, a sessão do operador é completamente terminada; o operador só pode regressar à área de administração iniciando novamente sessão com palavra-passe e segundo fator. O Cliente pode vê-la na sua exportação de dados.
  • Administração. Só algumas contas expressamente autorizadas têm direitos de administração; cada reposição de um segundo fator pela administração é registada.

3.5 Controlo da separação

  • Os dados dos clientes estão logicamente separados por espaço de trabalho. Cada caminho de leitura e escrita na área com sessão iniciada transporta esta associação; os relatórios são adicionalmente acessíveis através da respetiva ligação (secção 3.4).
  • O desenvolvimento e o funcionamento decorrem em instalações separadas, com bases de dados separadas e utilizadores de base de dados separados. O utilizador de desenvolvimento não tem acesso à base de dados de produção. Os dados reais dos clientes não são copiados para o desenvolvimento; aí trabalhamos com dados de exemplo gerados.
  • Para cada ambiente, o scanner tem credenciais próprias com direitos apenas sobre os dados de que necessita para as suas tarefas. Não pode ler contas, faturação nem registos.
  • No servidor web funcionam também outros serviços do mesmo prestador. Têm bases de dados próprias e utilizadores de base de dados próprios, sem acesso aos dados deste serviço.

4. Cifragem, pseudonimização e minimização dos dados

4.1 Credenciais para a análise por detrás do início de sessão

Para esta função, o Cliente armazena o nome de utilizador e a palavra-passe de uma conta de teste. São os dados mais sensíveis do serviço e, por isso, são protegidos de forma diferente de tudo o resto:

  • Ao armazená-los, o servidor web cifra-os com a chave pública do servidor de análise (ECIES: X25519 com uma chave de utilização única por registo, HKDF-SHA256, AES-256-GCM). A chave privada existe apenas no servidor de análise. O servidor web, a base de dados e as cópias de segurança contêm apenas texto cifrado; também nós não o conseguimos ler aí.
  • Cada registo está criptograficamente associado ao seu domínio. Se for transferido para outro domínio, a decifragem falha.
  • Para uma análise, o texto cifrado é anexado à tarefa. O servidor de análise decifra-o e transmite as credenciais ao contentor de verificação apenas através da entrada padrão, nunca como argumento da linha de comandos, que seria visível nas listas de processos. Logo que o servidor de análise o tenha lido, o texto cifrado é apagado da tarefa; um processo limpa eventuais restos o mais tardar após uma hora.
  • As credenciais nunca são apresentadas, nunca são registadas, nunca são devolvidas através da API e não são exportadas. A interface mostra apenas o primeiro carácter e o comprimento do nome de utilizador. A sua remoção sobrescreve o texto cifrado.
  • Por detrás do início de sessão, o scanner apenas lê: sem submissões, sem testes ativos, sem capturas de ecrã, sem páginas para terminar sessão, eliminar ou cancelar.

4.2 Outras cifragens e hashes

  • As palavras-passe, os códigos de recuperação, as palavras-passe dos portais de clientes, as chaves de API, os códigos de ligação e de implementação, os tokens de “Manter sessão iniciada”, os IDs de sessão na lista de dispositivos e as ligações de confirmação e de reposição são armazenados apenas como hash.
  • Os segredos do segundo fator são armazenados cifrados (secção 3.2).
  • Não afirmamos que toda a base de dados esteja cifrada em repouso. Os valores sensíveis são protegidos individualmente, conforme descrito acima.

4.3 Minimização dos dados desde a conceção

  • Verificação de entrega: são lidos apenas os cabeçalhos e no máximo os primeiros 8 KB do texto. Só a hora, a associação, se for caso disso o ID da submissão de teste, e o resultado da verificação de autenticidade (SPF, DKIM, DMARC) chegam à base de dados, nunca o conteúdo nem um endereço de remetente completo. O resultado de autenticidade do e-mail mais recente é conservado junto do domínio e é sobrescrito pelo seguinte; contém o endereço IP do servidor de correio que efetuou a entrega e o domínio de e-mail do remetente. O e-mail é eliminado da caixa de correio após o processamento bem-sucedido; se a obtenção ou a eliminação falhar, isso acontece na execução bem-sucedida seguinte.
  • Verificações: a estrutura dos formulários é armazenada com nomes de campos, tipos e etiquetas, atributos de obrigatoriedade e de visibilidade, sem valores; o scanner lê os inícios de campos ocultos pré-preenchidos (até 24 caracteres) e de atributos data (até 60 caracteres) apenas durante a verificação e não os armazena. As capturas de ecrã da verificação completa não são ocultadas; só as verificações no navegador tapam os campos de introdução. Os endereços de destinatário dos formulários são armazenados apenas como domínio. As submissões de teste ativas contêm apenas textos de teste identificados, sem dados pessoais.
  • As extensões para WordPress e TYPO3 transmitem apenas números diários e características como o inventário de plugins e, no caso de um plugin para WordPress ligado, também os domínios das ligações contidas em mensagens bloqueadas para a proteção coletiva (ativada por predefinição); nenhum outro conteúdo, nenhuns nomes, endereços ou endereços IP de visitantes. As contagens facultativas de erros de formulários e de campos estão desativadas por predefinição.
  • “Fix it for me”: o código colado é tratado apenas durante o pedido e não é armazenado.
  • Selo: a imagem do selo nos sítios web dos clientes não define qualquer cookie nem inicia qualquer sessão.
  • As notificações operacionais para o telemóvel do operador são textos fixos sem variáveis, ou seja, sem nomes, endereços ou conteúdos. As notificações de erro por e-mail para o operador contêm o texto bruto da mensagem de erro, não depurado e truncado a 400 caracteres; em casos pontuais, pode conter endereços ou ligações.
  • Proteção coletiva: entre as extensões dos Clientes, só são partilhados domínios de ligações contidas em spam bloqueado; a troca de redes IP está desativada.
  • Localização: o país de um endereço IP é determinado a partir de um ficheiro de base de dados local; nenhum endereço é enviado para um serviço de geolocalização.

5. Proteção contra a utilização abusiva do scanner

O scanner carrega páginas de terceiros com um navegador real. Sem proteção, seria uma ferramenta com a qual alguém do exterior poderia alcançar a nossa rede interna ou outros alvos não públicos (server-side request forgery). Existem, por isso, duas camadas independentes e o isolamento de cada execução individual.

5.1 Execução isolada

  • Cada verificação é executada no seu próprio contentor, que é removido posteriormente. É executada sem direitos de administrador, sem capacidades adicionais do sistema operativo e sem possibilidade de escalar privilégios. O seu sistema de ficheiros é apenas de leitura, à exceção de pequenas áreas voláteis.
  • A memória, o número de processos e o tempo de execução são limitados; uma execução que exceda o tempo é terminada.

5.2 Rede: duas camadas

  • Primeira camada, no scanner: antes da análise e, depois, em cada pedido individual do navegador, incluindo redirecionamentos e conteúdos incorporados, é verificado para onde o endereço é resolvido. São rejeitadas redes privadas, locais, reservadas e de documentação (IPv4 e IPv6), bem como portas diferentes das habituais na web. O navegador não permite service workers, e as ligações WebSocket são fechadas, porque ambos poderiam contornar esta verificação.
  • Segunda camada, na rede: os contentores funcionam numa rede própria. As regras da firewall só permitem ligações daí para a internet em portas web; as ligações para redes privadas, incluindo a nossa rede interna com o servidor web e a base de dados, são bloqueadas. As exceções que a própria execução da verificação exige estão limitadas ao necessário e descritas na nossa documentação interna. Esta camada produz também efeito se um nome só for resolvido de forma diferente após a primeira verificação.

5.3 Pedidos efetuados pelo servidor web

Quando o próprio servidor web solicita endereços de terceiros – para a prova de controlo do domínio, para a ferramenta de cabeçalhos, para a procura de ficheiros expostos, para os pedidos de pulso, para consultas RDAP e para a verificação de certificados, para webhooks e alertas de chat e para o segundo ponto de controlo facultativo –, aplicam-se as mesmas regras: apenas protocolos web, nas portas web habituais (webhooks e alertas de chat apenas através de HTTPS na porta padrão), apenas endereços públicos, ligação apenas exatamente ao endereço previamente verificado, para que um nome não possa ser posteriormente redirecionado para um alvo interno, redirecionamentos não seguidos de todo ou seguidos apenas manualmente e verificados de novo de cada vez, limites de tempo curtos; para a prova de controlo do domínio, para os pedidos de pulso e para o segundo ponto de controlo nas verificações no navegador, também um tamanho de resposta limitado.

5.4 O que o scanner não faz em sítios de terceiros

  • As submissões de teste ativas (no máximo cinco por verificação) existem para os Clientes apenas relativamente a domínios para os quais foi apresentada prova de controlo (DNS, meta tag, ficheiro ou extensão); a única exceção são as verificações internas dos nossos próprios domínios de teste e demonstração. O nome de anfitrião de um domínio com prova de controlo não pode ser alterado, para que a prova não passe para outro anfitrião. Tudo o resto é passivo: leitura de páginas como um visitante.
  • As verificações no navegador vão até ao momento anterior à submissão e não desencadeiam qualquer encomenda, pagamento ou submissão.
  • Os domínios da lista de opt-out não são verificados; a monitorização em curso termina com a próxima verificação agendada.

6. Integridade: transmissão e introdução

6.1 Transporte

  • A aplicação só é acessível a partir da internet através de HTTPS; o navegador é instruído a utilizar apenas HTTPS durante um ano (HSTS). Os certificados são renovados automaticamente.
  • Outros cabeçalhos restringem a incorporação da aplicação em páginas de terceiros, a adivinhação de tipos de ficheiro e a submissão de formulários para destinos de terceiros. Uma política de segurança de conteúdos só permite executar na aplicação os scripts que o servidor liberta com a respetiva resposta; os navegadores atuais não executam scripts injetados nem processadores de eventos no HTML.
  • A caixa de correio da verificação de entrega é consultada através de uma ligação cifrada com verificação de certificado.
  • Os webhooks podem ser assinados com um segredo do Cliente (HMAC-SHA256 com carimbo temporal), para que o destinatário possa verificar a origem e a integridade. Os pedidos ao segundo ponto de controlo facultativo são assinados e, nas verificações no navegador, também as respetivas respostas.
  • Dito abertamente: as ligações dentro da nossa rede interna não são integralmente cifradas. As credenciais para a análise por detrás do início de sessão permanecem cifradas em todo o percurso (secção 4.1).

6.2 Controlo da introdução e registos

  • As ações importantes em contas e espaços de trabalho (como início de sessão, alterações a domínios, destinos de alerta e direitos, eliminações, acessos de apoio) são registadas no registo de atividade com a conta, a hora, o endereço IP e o país, e apagadas após 365 dias.
  • Os registos de acesso a páginas mantidos para efeitos de segurança e prevenção de abusos são apagados após 60 dias, os registos de erros após 90 dias e os conteúdos dos e-mails enviados após 30 dias. Os tokens de acesso em endereços solicitados e referenciadores, como os das ligações de relatórios ou de portais, só aparecem nos registos de acesso a páginas de forma mascarada.
  • A aceitação dos documentos contratuais é armazenada com a versão apresentada, a respetiva soma de verificação, a hora, o endereço IP e a identificação do navegador.
  • Os registos de prova podem ser dotados de um carimbo temporal de uma entidade externa de carimbos temporais; só lhe é enviada uma soma de verificação do conteúdo, e não o próprio conteúdo.

7. Disponibilidade e resiliência

7.1 Cópia de segurança

  • É efetuada uma cópia de segurança da base de dados todas as noites. Uma cópia de segurança só recebe o seu nome definitivo depois de o seu conteúdo ter sido verificado: conclusão bem-sucedida do programa de cópia de segurança, pelo menos um registo, tantas tabelas quantas as que a base de dados tem e a linha final de uma execução completa. As cópias de segurança mais antigas só são removidas após uma nova cópia bem-sucedida.
  • Cada cópia de segurança é eliminada após 14 dias. O local de armazenamento situa-se fora de qualquer diretório servido; um local dentro do projeto é rejeitado.
  • Teste de restauro: uma vez por semana, a cópia de segurança mais recente é carregada numa base de dados descartável, comparada tabela a tabela com a produção e novamente eliminada. O resultado é armazenado.
  • Se uma cópia de segurança ou um teste falhar, é enviada uma notificação por e-mail e para o telemóvel do operador.
  • Recuperação após um incidente: se a base de dados falhar ou os dados forem corrompidos, restauramos a cópia de segurança testada mais recente. As alterações efetuadas desde essa cópia, em regra no máximo as de um dia, podem perder-se neste processo; se uma cópia de segurança tiver falhado, correspondentemente mais. Voltamos então a executar os pedidos de apagamento posteriores conhecidos (secção 8). Não nos comprometemos com qualquer tempo de recuperação determinado.
  • Limite, dito abertamente: atualmente, as cópias de segurança estão armazenadas no mesmo local que a base de dados e não são cifradas separadamente. Protegem contra erros de operação, alterações defeituosas e dados corrompidos, mas não contra a perda do próprio servidor. Está planeada uma cópia cifrada num segundo local (secção 10).
  • As credenciais para a análise por detrás do início de sessão estão contidas nas cópias de segurança apenas como texto cifrado; o segredo do segundo fator apenas sob forma cifrada, com uma chave fora da base de dados.

7.2 Monitorização

  • Um processo de estado verifica os componentes do serviço a cada cinco minutos, incluindo a base de dados, a fila e o sinal de vida do scanner, que o scanner escreve regularmente mesmo quando inativo. Se um componente falhar, é enviada uma notificação; se recuperar, um aviso de normalização.
  • Vigilância cruzada: um processo de estado não pode comunicar a falha da máquina em que é executado. Por isso, o servidor de análise verifica a cada minuto se a aplicação responde e, após várias falhas consecutivas, envia um texto fixo para o telemóvel do operador. Inversamente, o servidor web monitoriza o sinal de vida do scanner; a lista de verificação da configuração mostra se a vigilância cruzada está em funcionamento.
  • Alerta de erros: um tipo de erro que nunca tenha ocorrido antes é comunicado uma vez de imediato; uma acumulação de erros desencadeia apenas um único sinal para o telemóvel do operador; uma vez por dia é enviada uma visão geral. Assim, não tomamos conhecimento de um erro primeiro através de um Cliente.
  • Limite, dito abertamente: ambos os servidores estão no mesmo local. Uma falha de todo o local, por exemplo de energia ou de ligação à internet, não é comunicada por nenhum mecanismo de alerta, mas detetada por uma pessoa.

7.3 Alterações e implementação

  • As novas versões são primeiro construídas e testadas no ambiente de desenvolvimento separado. A implementação verifica todos os pré-requisitos antes de o primeiro ficheiro ser escrito, efetua as alterações ao esquema da base de dados e deixa as verificações em curso terminar de forma ordenada antes de o scanner ser reiniciado.
  • Para o percurso de um novo Cliente, existe um teste de fumo sobre HTTP real, que é executado após as transições. Não afirmamos que exista um conjunto de testes automatizados antes de cada implementação.

8. Apagamento e prazos de conservação

  • Um processo de apagamento executado todas as noites aplica os prazos indicados na Política de Privacidade e no Acordo de Tratamento de Dados. Lê as mesmas definições de onde são retirados os números dos textos; relativamente a estes prazos, o texto e o comportamento não divergem, portanto.
  • Os resultados das verificações, incluindo capturas de ecrã, são apagados após 13 meses (mantém-se o mais recente por domínio), os números das extensões após 13 meses, os registos de entrega de alertas após 90 dias e os pedidos de apoio após 24 meses.
  • A remoção de um domínio apaga os dados do domínio, incluindo verificações, formulários, resultados, capturas de ecrã, relatórios, tarefas, destinos e registos de alertas, incidentes, dados de entrega, credenciais para a análise por detrás do início de sessão e provas.
  • A eliminação de uma conta é imediata; os espaços de trabalho sem outros membros são eliminados com os respetivos dados, os espaços de trabalho com outros membros passam para outro membro, em primeiro lugar para os administradores e, entre estes, para o mais antigo. Até à expiração dos respetivos prazos, mantêm-se: os registos cujas entradas conservam o antigo número de conta, que já não remete para qualquer conta existente, incluindo a entrada de eliminação, bem como os e-mails enviados, a prova da celebração do contrato, os pedidos de apoio, os relatórios das verificações de potenciais clientes (até 90 dias) e os dados de faturação na Stripe; os pormenores constam da Política de Privacidade.
  • Os dados apagados permanecem nas cópias de segurança até à sua expiração, após 14 dias. Não há apagamento seletivo dentro de uma cópia de segurança; se uma cópia de segurança for restaurada, os pedidos de apagamento posteriores conhecidos são novamente executados manualmente.

9. Organização e revisão

  • Pessoas: atualmente, o serviço é operado pelo próprio proprietário. Outras pessoas só recebem acesso após um compromisso de confidencialidade e apenas na medida do necessário, e só tratam dados mediante instruções nossas (Art. 29 e Art. 32(4) do RGPD).
  • Subcontratantes ulteriores: só os contratamos após a análise das suas garantias e mediante contrato nos termos do Art. 28(4) do RGPD, e enumeramo-los na página Subcontratantes Ulteriores; os pormenores regem-se pelo Acordo de Tratamento de Dados.
  • Violações de dados pessoais: se uma violação de dados pessoais afetar dados tratados enquanto subcontratante, notificamos o Cliente sem demora injustificada, se possível no prazo de 48 horas; os pormenores regem-se pelo Acordo de Tratamento de Dados.
  • Comunicação de vulnerabilidades: aceitamos comunicações em Segurança e através do ficheiro /.well-known/security.txt.
  • Lista de verificação da configuração e do lançamento: na área de administração, uma lista de verificação mede o estado das definições relevantes para a segurança, como a cópia de segurança, administradores sem segundo fator, a configuração do correio eletrónico e o sinal de vida, e apresenta os desvios.
  • Revisão destas medidas (Art. 32(1)(d) do RGPD): em cada alteração significativa do serviço, após cada incidente de segurança e, de resto, pelo menos uma vez por ano. Nessa ocasião, avaliamos se as medidas são eficazes e continuam adequadas aos riscos, e registamos o resultado numa nova versão desta página ou, se nada mudar, com a data da revisão na secção 11. De forma contínua, a lista de verificação da configuração e do lançamento mede o estado das definições que abrange.
  • Auditorias externas: atualmente, não são encomendados testes de intrusão externos e não existem certificações de segurança. Indicamo-lo aqui para que ninguém as presuma.

10. Planeado, ainda não implementado

Estes pontos não constituem medidas assumidas enquanto não forem aqui enumerados como implementados numa nova versão:

  • Cópia de segurança num segundo local: uma cópia cifrada da cópia de segurança noturna fora do servidor, para que nem mesmo a perda total do servidor conduza à perda de dados.
  • Segundo ponto de controlo: a confirmação independente das verificações no navegador a partir de um segundo local está preparada no serviço, mas não configurada. Sem ela, não há confirmação a partir de um segundo local.
  • Reforço da segurança da administração dos servidores: está em curso. Pelos motivos indicados na secção 1, não publicamos pormenores.

11. Estado e versão

  • Versão 1.1 · Última atualização: 22 de outubro de 2026 · em caso de divergências entre as versões linguísticas, prevalece a versão polaca em vez da alemã; sem outras alterações.
  • Versão 1.0 · Última atualização: 11 de outubro de 2026 · primeira versão como página separada; anteriormente Anexo 2 do Acordo de Tratamento de Dados. Corrigido em relação ao anexo anterior: o teste de restauro é semanal, as cópias de segurança estão no mesmo servidor, não é executado um conjunto de testes automatizados antes de cada implementação, as ligações na rede interna não são integralmente cifradas. Novas descrições: cifragem das credenciais para a análise por detrás do início de sessão, isolamento do scanner, vigilância cruzada e alerta de erros.
  • As alterações são publicadas com um novo número de versão aqui e na visão geral Alterações aos Documentos Contratuais; em caso de enfraquecimento de medidas, aplica-se o prazo de pré-aviso do Acordo de Tratamento de Dados.
  • Em caso de divergência entre as versões linguísticas, prevalece a versão polaca.