Mesures tècniques i organitzatives

Aquest document es publica en diverses llengües. En cas de discrepància entre les versions lingüístiques, la versió polonesa és la vinculant.

Versió 1.1 · Última actualització: 22 d'octubre de 2026

Mesures en virtut de l'art. 32 RGPD amb què LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Poland, protegeix el servei formexposed. Aquesta pàgina forma part de l'Acord d'encàrrec del tractament com a annex 2.

1. Àmbit d'aplicació i principi

Les mesures s'apliquen a totes les dades tractades pel servei: a les dades que tractem per compte dels nostres Clients (descrites a l'Acord d'encàrrec del tractament) i a les dades de les quals nosaltres mateixos som el responsable del tractament, com ara comptes de client i registres. No hi ha nivells de protecció separats per als dos grups; el que protegeix el compte també protegeix les dades tractades com a encarregat.

Estructura segons l'art. 32(1) RGPD. La pseudonimització i el xifrat (lletra (a)) es cobreixen a la secció 4; la confidencialitat, la integritat, la disponibilitat i la resiliència permanents dels sistemes (lletra (b)), a les seccions 3, 5, 6 i 7; la capacitat de restaurar la disponibilitat de manera oportuna després d'un incident (lletra (c)), a la secció 7.1; i el procés de verificació, avaluació i valoració regular de l'eficàcia (lletra (d)), a la secció 9. Hem seleccionat les mesures sobre la base dels riscos descrits a la nostra Avaluació d'impacte relativa a la protecció de dades, tenint en compte l'estat de la tècnica i els costos d'implementació.

Principi: allò mesurat, no allò previst. Aquí només s'indica el que s'ha implementat realment al codi o en el funcionament. El que està previst però encara no s'ha implementat s'enumera expressament com a «previst» a la secció 10. Una mesura que no apareix aquí no s'ha de donar tàcitament per implementada.

Deliberadament no s'indiquen noms de màquines, adreces internes, ports, noms d'usuari ni versions de programari. No ajuden a avaluar les mesures, però sí que ajuden qui vol eludir-les. Qui els necessiti per a una auditoria segons l'Acord d'encàrrec del tractament els rebrà durant aquesta auditoria sota confidencialitat, en la mesura que siguin necessaris per a l'auditoria.

2. Estructura del servei

El servei s'executa en dos servidors propis del prestador a Polònia, situats a la mateixa xarxa interna:

Servidor web amb base de dades. Serveix l'aplicació, conserva la base de dades, envia notificacions i fa còpies de seguretat de les dades. Només aquest servidor està configurat per acceptar sol·licituds d'internet.
Servidor d'escaneig. Fa les comprovacions de llocs web de tercers i propis en un navegador i executa el model de llenguatge que classifica formularis individuals, resumeix els resultats dels escaneigs en plans d'acció prioritzats per a comptes de pagament i afegeix codi a «Fix it for me». No està configurat per acceptar sol·licituds d'internet, sinó que recupera pel seu compte les tasques del servidor web i hi retorna els resultats.

No hi intervé cap proveïdor d'allotjament, centre de dades o núvol en el funcionament, i no s'envia res a cap servei extern d'IA. La pàgina Subencarregats del tractament indica quins tercers reben dades.

3. Confidencialitat

3.1 Control de l'accés físic

Els servidors es troben en dependències del prestador a Polònia que no estan obertes al públic. Només el propietari hi té accés (segons la declaració de l'operador). Deliberadament no es dona aquí l'adreça exacta de la ubicació.

3.2 Control d'accés: inici de sessió al servei

Les contrasenyes només s'emmagatzemen en forma de hash amb el mètode estàndard de PHP (bcrypt). Si el mètode estàndard canvia, el hash es renova en el pròxim inici de sessió. En un intent d'inici de sessió amb una adreça desconeguda, el servidor calcula igualment un hash perquè el temps de resposta no reveli si existeix un compte. De la mateixa manera, la resposta a una sol·licitud de restabliment de contrasenya no revela ni per la redacció ni per la durada si el compte existeix; s'envien correus de restabliment a la mateixa adreça com a màxim tres vegades per hora. Les contrasenyes noves han de tenir com a mínim deu caràcters i no poden superar els 72 bytes (UTF-8), perquè bcrypt no té en compte més bytes. Canviar la contrasenya tanca la sessió a tots els altres dispositius; restablir-la mitjançant l'enllaç tanca la sessió a tots els dispositius, i l'enllaç només és vàlid una vegada.
Bloqueig després d'intents fallits. Els inicis de sessió fallits es compten per adreça IP; després de massa intents en poc temps (actualment vuit en 15 minuts), es bloqueja temporalment l'inici de sessió des d'aquesta adreça. Un inici de sessió correcte restableix aquest comptador. Els intents se suprimeixen al cap de set dies. A més, abans de cada comprovació de contrasenya es compta un intent per compte (per a una adreça desconeguda, per adreça introduïda) i per adreça IP, inclosos els intents correctes: actualment, com a màxim vuit per compte des de la mateixa adreça IP i 80 per adreça IP en 15 minuts; s'aplica un límit considerablement més alt per compte sumant totes les adreces, per evitar els intents distribuïts d'endevinar contrasenyes. Per tant, els intents fallits des d'una altra adreça ja no impedeixen al propietari accedir a un compte. Aquests comptadors només contenen una clau HMAC, sense adreces de correu electrònic ni adreces IP en text clar, i caduquen amb la seva finestra temporal. Si l'emmagatzematge dels comptadors no està disponible, es rebutja l'inici de sessió, no es deixa passar. S'aplica el mateix tipus de límit a la confirmació de la contrasenya abans de canviar la contrasenya o l'adreça, activar o desactivar el segon factor, transferir un espai de treball, exportar les dades i suprimir el compte (cinc intents per compte en 15 minuts), als registres (deu per adreça IP per hora) i a les contrasenyes dels portals de clients (deu intents per portal i adreça IP, 50 per portal en 15 minuts).
Segon factor. Qualsevol compte pot activar l'inici de sessió amb un codi d'un sol ús segons RFC 6238 (TOTP). El secret corresponent s'emmagatzema xifrat a la base de dades; la clau no s'emmagatzema a la base de dades, de manera que un extracte de la base de dades per si sol no és suficient. Un codi acceptat no és vàlid per segona vegada. Els deu codis de recuperació només s'emmagatzemen en forma de hash. Els codis d'un sol ús i de recuperació estan limitats a deu intents per compte en 15 minuts, també durant la configuració.
Àrea d'administració només amb segon factor. L'àrea d'administració de l'operador només s'obre als comptes amb el segon factor activat. La llista de comprovació de la configuració indica tots els comptes d'administrador sense segon factor.
Sessions. Els scripts no poden llegir la galeta de sessió (HttpOnly), que només s'envia mitjançant HTTPS (Secure) i no s'envia amb sol·licituds de llocs de tercers que podrien modificar alguna cosa (SameSite=Lax). En iniciar sessió, es crea un identificador de sessió nou, de manera que un identificador introduït prèviament ja no és vàlid; el servidor no accepta cap identificador de sessió que no hagi emès ell mateix. Cada compte veu els seus dispositius amb sessió iniciada i pot tancar-ne les sessions individualment.
«Mantenir la sessió iniciada» és opcional i és vàlid durant 30 dies, però no per als comptes amb drets d'administració; aquests sempre inicien sessió amb contrasenya i segon factor. El testimoni consta de dues parts; la part de verificació només s'emmagatzema a la base de dades en forma de hash. Cada ús el substitueix per un de nou i, fins i tot amb sol·licituds simultànies, cada testimoni només és vàlid una vegada, de manera que un testimoni robat es detecta com a màxim en la pròxima visita autèntica.
Enllaços als correus electrònics. Els enllaços per confirmar l'adreça i restablir la contrasenya només s'emmagatzemen a la base de dades en forma de hash. L'enllaç de restabliment és vàlid durant una hora; el de confirmació d'un registre, durant 72 hores; i el de confirmació d'una adreça modificada, durant 24 hores. Si es canvia l'adreça de correu electrònic, un enllaç de restabliment pendent deixa de ser vàlid.
Interfícies. Les claus d'API, els codis de connexió de les extensions i els codis de connexió de desplegament només s'emmagatzemen en forma de hash. Les claus d'API només es poden utilitzar un nombre limitat de vegades per minut; els codis de connexió de les extensions són vàlids durant 15 minuts i només una vegada.
Protecció contra bots als formularis públics (registre, inici de sessió, contrasenya, comprovació, eina de capçaleres, exclusió voluntària, suport i contacte): Google reCAPTCHA, que només es carrega en enviar el formulari. Només s'accepta una resposta vàlida de Google amb una puntuació suficient per a l'acció exacta del formulari; si Google no respon dins de tres segons, es rebutja l'enviament. La Política de privacitat en proporciona els detalls.

3.3 Control d'accés: administració del servidor

El servidor accessible des d'internet utilitza un filtre de paquets per permetre només els serveis que ofereix i bloqueja automàticament les adreces després d'intents fallits repetits d'inici de sessió a l'administració del servidor.
Els processos automatitzats entre els servidors utilitzen les seves pròpies claus amb permisos estrictament limitats. La clau amb què el servidor web lliura versions noves de l'escàner només pot executar una llista fixa d'ordres al servidor d'escaneig i només pot copiar, amb accés només d'escriptura, al directori de l'escàner; no és possible iniciar-hi una sessió interactiva, i totes les ordres rebutjades es registren. Igualment, el servidor d'escaneig només pot escriure captures de pantalla en un directori específic del servidor web.
El procés que serveix el lloc web no té accés d'escriptura a la instal·lació de producció ni cap clau del servidor d'escaneig. Un desplegament iniciat a l'àrea d'administració només registra una tasca, que executa un procés separat.
Els secrets, com ara les credencials de la base de dades i les claus, es conserven en fitxers de configuració fora del directori servit i no es copien durant el desplegament. La configuració del servidor web no es distribueix a través de la interfície web.

3.4 Control d'autorització: permisos dins del servei

Rols. Cada espai de treball té els rols de propietari, administrador i lector. La modificació, la supressió, les invitacions i l'emmagatzematge de credencials es reserven als propietaris i administradors; només el propietari pot canviar els rols i eliminar membres. Una invitació només és vàlida mentre qui l'ha enviada continua sent propietari o administrador. Els lectors només veuen les adreces dels webhooks i dels canals de xat reduïdes a l'amfitrió, perquè l'adreça per si sola permet publicar al canal. La comprovació es fa al servidor, no només a la interfície.
Vinculació a l'espai de treball. Només els membres de l'espai de treball poden accedir als dominis i a la configuració. Per a cada comprovació, el Servei crea un informe amb un enllaç aleatori que no es pot endevinar; els resultats i les captures de pantalla d'una comprovació són accessibles mitjançant aquest enllaç sense iniciar sessió, i les captures de pantalla només juntament amb l'enllaç del seu informe. L'enllaç apareix al compte i als avisos; qui el transmet transmet l'informe.
Les sol·licituds que modifiquen l'estat requereixen un testimoni de seguretat per sessió (protecció CSRF), que es compara en temps constant.
«Veure com a client». Per al suport, l'operador pot veure l'aplicació tal com la veu un Client. La visualització finalitza al cap d'una hora, bloqueja els canvis de contrasenya, adreça, segon factor, dispositius, subscripció, exportació i supressió, tanca l'àrea d'administració mentrestant i queda registrada. Quan finalitza, es tanca completament la sessió de l'operador; aquest només pot tornar a l'àrea d'administració iniciant sessió de nou amb contrasenya i segon factor. El Client ho pot veure a la seva exportació de dades.
Administració. Només uns quants comptes expressament autoritzats tenen drets d'administració; tots els restabliments d'un segon factor fets per l'administració queden registrats.

3.5 Control de separació

Les dades dels clients estan separades lògicament per espai de treball. Totes les vies de lectura i escriptura a l'àrea amb sessió iniciada incorporen aquesta vinculació; els informes també són accessibles mitjançant el seu enllaç (secció 3.4).
El desenvolupament i el funcionament es fan en instal·lacions separades amb bases de dades separades i usuaris de base de dades separats. L'usuari de desenvolupament no té accés a la base de dades de producció. No es copien dades reals de clients a desenvolupament; allà treballem amb dades d'exemple generades.
Per a cada entorn, l'escàner té les seves pròpies credencials amb permisos únicament sobre les dades que necessita per a les seves tasques. No pot llegir comptes, facturació ni registres.
Altres serveis del mateix prestador també s'executen al servidor web. Tenen les seves pròpies bases de dades i els seus propis usuaris de base de dades sense accés a les dades d'aquest servei.

4. Xifrat, pseudonimització i minimització de dades

4.1 Credencials per a l'escaneig que requereix iniciar sessió

Per a aquesta funció, el Client emmagatzema el nom d'usuari i la contrasenya d'un compte de prova. Són les dades més sensibles del servei i, per tant, es protegeixen de manera diferent de totes les altres:

En emmagatzemar-les, el servidor web les xifra amb la clau pública del servidor d'escaneig (ECIES: X25519 amb una clau d'un sol ús per registre, HKDF-SHA256, AES-256-GCM). La clau privada només existeix al servidor d'escaneig. El servidor web, la base de dades i les còpies de seguretat només contenen text xifrat; nosaltres tampoc no el podem llegir allà.
Cada registre està vinculat criptogràficament al seu domini. Si es trasllada a un altre domini, el desxifrat falla.
Per a un escaneig, el text xifrat s'adjunta a la tasca. El servidor d'escaneig el desxifra i passa les credencials al contenidor de comprovació només mitjançant l'entrada estàndard, mai com a argument de línia d'ordres que seria visible a les llistes de processos. Tan bon punt el servidor d'escaneig l'ha llegit, el text xifrat se suprimeix de la tasca; un procés elimina qualsevol resta com a màxim al cap d'una hora.
Les credencials no es mostren mai, no es registren mai als registres tècnics, no es proporcionen mai mitjançant l'API ni s'exporten. La interfície només mostra el primer caràcter i la longitud del nom d'usuari. Eliminar-les sobreescriu el text xifrat.
A l'àrea que requereix iniciar sessió, l'escàner només llegeix: no hi ha enviaments, proves actives, captures de pantalla ni pàgines per tancar la sessió, eliminar o cancel·lar.

4.2 Altres xifrats i hashes

Les contrasenyes, els codis de recuperació, les contrasenyes dels portals de clients, les claus d'API, els codis de connexió i els de connexió de desplegament, els testimonis de «Mantenir la sessió iniciada», els identificadors de sessió de la llista de dispositius i els enllaços de confirmació i de restabliment només s'emmagatzemen en forma de hash.
Els secrets del segon factor s'emmagatzemen xifrats (secció 3.2).
No afirmem que tota la base de dades estigui xifrada en repòs. Els valors sensibles es protegeixen individualment, tal com es descriu més amunt.

4.3 Minimització de dades des del disseny

Comprovació del lliurament: Només es llegeixen les capçaleres i com a màxim els primers 8 KB del text. A la base de dades només hi arriben el moment, l'assignació, si escau l'identificador de l'enviament de prova i el resultat de la comprovació d'autenticitat (SPF, DKIM, DMARC), mai el contingut ni una adreça completa del remitent. El resultat d'autenticitat del correu electrònic més recent es conserva amb el domini i el següent el sobreescriu; conté l'adreça IP del servidor de correu que fa el lliurament i el domini del correu electrònic del remitent. El correu electrònic se suprimeix de la bústia després d'un tractament correcte; si la recuperació o la supressió falla, es fa en la pròxima execució correcta.
Comprovacions: L'estructura dels formularis s'emmagatzema amb els noms dels camps, els tipus i les etiquetes, els atributs d'obligatorietat i visibilitat, sense valors; l'escàner només llegeix el començament dels camps ocults preemplenats (fins a 24 caràcters) i dels atributs de dades (fins a 60 caràcters) durant la comprovació, i no els emmagatzema. Les captures de pantalla de la comprovació completa no estan censurades; només les comprovacions al navegador tapen els camps d'entrada. Les adreces dels destinataris dels formularis només s'emmagatzemen en forma de domini. Els enviaments de prova actius només contenen textos de prova identificats com a tals, sense dades personals.
Les extensions de WordPress i TYPO3 només transmeten xifres diàries i característiques com ara l'inventari de connectors i, per a un connector de WordPress connectat, també els dominis dels enllaços de missatges bloquejats per a la protecció col·lectiva (activada per defecte); cap altre contingut, ni noms, adreces o adreces IP dels visitants. Els recomptes opcionals dels formularis i dels errors dels camps estan desactivats per defecte.
«Fix it for me»: El codi enganxat només es tracta durant la sol·licitud i no s'emmagatzema.
Distintiu: La imatge del distintiu als llocs web dels clients no estableix cap galeta ni inicia cap sessió.
Les notificacions operatives al telèfon de l'operador són textos fixos sense variables, és a dir, sense noms, adreces ni contingut. Les notificacions d'error per correu electrònic a l'operador contenen el text sense tractar del missatge d'error, sense sanejar i truncat a 400 caràcters; en casos individuals pot contenir adreces o enllaços.
Protecció col·lectiva: Entre les extensions dels Clients només es comparteixen dominis dels enllaços dels missatges brossa bloquejats; l'intercanvi de xarxes IP està desactivat.
Ubicació: El país d'una adreça IP es determina a partir d'un fitxer de base de dades local; no s'envia cap adreça a cap servei de geolocalització.

5. Protecció contra l'ús indegut de l'escàner

L'escàner carrega pàgines de tercers amb un navegador real. Sense protecció, seria una eina amb què algú de fora podria arribar a la nostra xarxa interna o a altres destinacions no públiques (falsificació de sol·licituds del costat del servidor). Per això hi ha dues capes independents i l'aïllament de cada execució individual.

5.1 Execució aïllada

Cada comprovació s'executa en el seu propi contenidor, que s'elimina després. S'executa sense drets d'administrador, sense capacitats addicionals del sistema operatiu i sense possibilitat d'elevar els privilegis. El seu sistema de fitxers és només de lectura, excepte petites àrees volàtils.
La memòria, el nombre de processos i el temps d'execució estan limitats; una execució que supera el temps es finalitza.

5.2 Xarxa: dues capes

Primera capa, a l'escàner: Abans de l'escaneig i després per a cada sol·licitud individual del navegador, incloses les redireccions i el contingut incrustat, es comprova a quina destinació es resol l'adreça. Es rebutgen les xarxes privades, locals, reservades i de documentació (IPv4 i IPv6), així com els ports diferents dels habituals per al web. El navegador no permet service workers i es tanquen les connexions WebSocket, perquè tots dos podrien eludir aquesta comprovació.
Segona capa, a la xarxa: Els contenidors s'executen en la seva pròpia xarxa. Les regles del tallafoc només permeten connexions des d'allà a internet pels ports web; es bloquegen les connexions cap a xarxes privades, inclosa la nostra xarxa interna amb el servidor web i la base de dades. Les excepcions que requereix la mateixa execució de comprovació es limiten al que és necessari i es descriuen a la nostra documentació interna. Aquesta capa també actua si un nom es resol de manera diferent només després de la primera comprovació.

5.3 Sol·licituds fetes pel servidor web

Quan el mateix servidor web sol·licita adreces de tercers —per acreditar el control del domini, per a l'eina de capçaleres, per cercar fitxers exposats, per a les sol·licituds de comprovació periòdica, per a les consultes RDAP i la comprovació de certificats, per als webhooks i els avisos de xat i per al segon punt de comprovació opcional— s'apliquen les mateixes regles: només protocols web, als ports web habituals (webhooks i avisos de xat només mitjançant HTTPS al port estàndard), només adreces públiques, connexió únicament a l'adreça exacta comprovada prèviament perquè un nom no es pugui redirigir després a una destinació interna, redireccions que no se segueixen en absolut o que només se segueixen manualment i es tornen a comprovar cada vegada, i límits de temps curts; per a l'acreditació del control del domini, les sol·licituds de comprovació periòdica i el segon punt de comprovació de les comprovacions al navegador, també s'aplica una mida de resposta limitada.

5.4 Què no fa l'escàner als llocs de tercers

Els enviaments de prova actius (com a màxim cinc per comprovació) només es fan per als Clients en dominis dels quals s'ha facilitat l'acreditació del control (DNS, metaetiqueta, fitxer o extensió); l'única excepció són les comprovacions internes dels nostres propis dominis de prova i de demostració. El nom d'amfitrió d'un domini amb acreditació del control no es pot modificar, de manera que l'acreditació no passa a un altre amfitrió. Tota la resta és passiva: llegir pàgines com un visitant.
Les comprovacions al navegador arriben fins al punt anterior a l'enviament i no inicien cap comanda, pagament ni enviament.
Els dominis de la llista d'exclusió voluntària no es comproven; la supervisió en curs finalitza amb la pròxima comprovació programada.

6. Integritat: transferència i entrada de dades

6.1 Transport

L'aplicació només és accessible des d'internet mitjançant HTTPS; s'indica al navegador que utilitzi únicament HTTPS durant un any (HSTS). Els certificats es renoven automàticament.
Altres capçaleres restringeixen la incrustació de l'aplicació en pàgines de tercers, la inferència dels tipus de fitxer i l'enviament de formularis a destinacions de tercers. Una política de seguretat del contingut només deixa executar a l'aplicació els scripts que el servidor autoritza amb la resposta corresponent; els navegadors actuals no executen scripts injectats ni gestors d'esdeveniments a l'HTML.
La bústia de la comprovació del lliurament es consulta mitjançant una connexió xifrada amb verificació del certificat.
Els webhooks es poden signar amb un secret del Client (HMAC-SHA256 amb marca de temps) perquè el destinatari pugui verificar l'origen i la integritat. Les sol·licituds al segon punt de comprovació opcional estan signades i, per a les comprovacions al navegador, també les seves respostes.
Ho indiquem obertament: Les connexions dins de la nostra xarxa interna no estan xifrades en tot el seu recorregut. Les credencials per a l'escaneig que requereix iniciar sessió es mantenen xifrades en tot moment (secció 4.1).

6.2 Control d'entrada i registres

Les accions importants als comptes i als espais de treball (com ara l'inici de sessió, els canvis de dominis, de destinacions d'avís i de permisos, les supressions i l'accés del servei d'assistència) es registren al registre d'activitat amb el compte, el moment, l'adreça IP i el país, i se suprimeixen al cap de 365 dies.
Els registres d'accés a pàgines conservats per a seguretat i prevenció d'abusos se suprimeixen al cap de 60 dies; els registres d'errors, al cap de 90 dies; i els continguts dels correus electrònics enviats, al cap de 30 dies. Els testimonis d'accés a les adreces sol·licitades i als referrers, com ara els dels enllaços d'informes o de portals, només apareixen als registres d'accés a pàgines en forma emmascarada.
L'acceptació dels documents contractuals s'emmagatzema amb la versió mostrada, la seva suma de verificació, el moment, l'adreça IP i l'identificador del navegador.
Els registres de proves es poden dotar d'un segell de temps d'una autoritat externa de segellament de temps; només se li envia una suma de verificació del contingut, no el contingut mateix.

7. Disponibilitat i resiliència

7.1 Còpia de seguretat

Es fa una còpia de seguretat de la base de dades cada nit. Una còpia de seguretat només rep el seu nom definitiu després de comprovar-ne el contingut: finalització correcta del programa de còpia de seguretat, com a mínim un registre, tantes taules com té la base de dades i la línia final d'una execució completa. Les còpies de seguretat anteriors només s'eliminen després d'una còpia nova correcta.
Cada còpia de seguretat se suprimeix al cap de 14 dies. La ubicació d'emmagatzematge és fora de qualsevol directori servit; es rebutja una ubicació dins del projecte.
Prova de restauració: Una vegada a la setmana, es carrega l'última còpia de seguretat en una base de dades d'un sol ús, es compara taula per taula amb producció i es torna a suprimir. El resultat s'emmagatzema.
Si una còpia de seguretat o una prova falla, s'envia una notificació per correu electrònic i al telèfon de l'operador.
Recuperació després d'un incident: Si la base de dades falla o les dades es corrompen, restaurem l'última còpia de seguretat provada. Durant aquest procés es poden perdre els canvis fets des d'aquella còpia, per regla general com a màxim els d'un dia; si una còpia de seguretat ha fallat, se'n poden perdre proporcionalment més. Després tornem a executar les sol·licituds de supressió posteriors conegudes (secció 8). No ens comprometem a cap temps de recuperació concret.
Limitació, indicada obertament: Actualment, les còpies de seguretat s'emmagatzemen a la mateixa ubicació que la base de dades i no es xifren per separat. Protegeixen contra errors d'operació, canvis defectuosos i dades corruptes, no contra la pèrdua del servidor mateix. Està prevista una còpia xifrada en una segona ubicació (secció 10).
Les còpies de seguretat només contenen les credencials per a l'escaneig que requereix iniciar sessió en forma de text xifrat; el secret del segon factor també hi és només en format xifrat, amb una clau fora de la base de dades.

7.2 Supervisió

Un procés d'estat comprova els components del servei cada cinc minuts, inclosos la base de dades, la cua i el senyal de vida de l'escàner, que aquest escriu periòdicament fins i tot quan està inactiu. Si un component falla, s'envia una notificació; si es recupera, s'avisa que torna a funcionar.
Supervisió creuada: Un procés d'estat no pot informar de la fallada de la màquina on s'executa. Per això, el servidor d'escaneig comprova cada minut si l'aplicació respon i, després de diverses fallades consecutives, envia un text fix al telèfon de l'operador. Al seu torn, el servidor web supervisa el senyal de vida de l'escàner; la llista de comprovació de la configuració mostra si la supervisió creuada està en funcionament.
Alerta d'error: Un tipus d'error que no s'ha produït mai abans es notifica una vegada immediatament; una acumulació d'errors només desencadena un sol senyal al telèfon de l'operador; una vegada al dia s'envia un resum. Això significa que no ens assabentem per primera vegada d'un error a través d'un Client.
Limitació, indicada obertament: Tots dos servidors són a la mateixa ubicació. La fallada de tota la ubicació, per exemple del subministrament elèctric o de la connexió a internet, no la notifica cap mecanisme d'alerta, sinó que la detecta una persona.

7.3 Canvis i desplegament

Les versions noves es construeixen i es proven primer a l'entorn de desenvolupament separat. El desplegament comprova tots els requisits previs abans d'escriure el primer fitxer, fa els canvis a l'esquema de la base de dades i deixa que les comprovacions en curs finalitzin ordenadament abans que es reiniciï l'escàner.
Per al recorregut d'un Client nou hi ha una prova bàsica de funcionament sobre HTTP real, que s'executa després dels canvis d'entorn. No afirmem que hi hagi una bateria de proves automatitzada abans de cada desplegament individual.

8. Supressió i terminis de conservació

Una execució de supressió cada nit aplica els terminis indicats a la Política de privacitat i a l'Acord d'encàrrec del tractament. Llegeix la mateixa configuració de la qual s'obtenen les xifres dels textos; per tant, per a aquests terminis, el text i el comportament no divergeixen.
Els resultats de les comprovacions, incloses les captures de pantalla, se suprimeixen al cap de 13 mesos (es conserva l'últim de cada domini); les xifres de les extensions, al cap de 13 mesos; els registres de lliurament d'avisos, al cap de 90 dies; i les sol·licituds de suport, al cap de 24 mesos.
Eliminar un domini suprimeix les dades del domini, incloses les comprovacions, els formularis, els detalls de comprovació, les captures de pantalla, els informes, les tasques, les destinacions i els registres d'avís, les incidències, les dades de lliurament, les credencials per a l'escaneig que requereix iniciar sessió i les proves.
La supressió d'un compte és immediata; els espais de treball sense altres membres se suprimeixen amb les seves dades, i els que tenen altres membres passen a un altre membre, primer als administradors i, entre aquests, al que fa més temps que en forma part. Fins que finalitzen els seus propis terminis, es conserven: els registres les entrades dels quals mantenen l'antic número de compte, que ja no remet a cap compte existent, inclosa l'entrada de supressió, així com els correus electrònics enviats, la prova de formalització del contracte, les sol·licituds de suport, els informes de comprovacions de clients potencials (fins a 90 dies) i les dades de facturació a Stripe; la Política de privacitat en proporciona els detalls.
Les dades suprimides romanen a les còpies de seguretat fins que caduquen al cap de 14 dies. No es fa supressió selectiva dins d'una còpia de seguretat; si es restaura una còpia, les sol·licituds de supressió posteriors conegudes es tornen a executar manualment.

9. Organització i revisió

Persones: Actualment, el propietari fa funcionar el servei personalment. Altres persones només reben accés després d'un compromís de confidencialitat i únicament en la mesura necessària, i només tracten dades segons les nostres instruccions (art. 29 i art. 32(4) RGPD).
Subencarregats del tractament: Només els contractem després de revisar-ne les garanties i sota un contracte segons l'art. 28(4) RGPD, i els enumerem a la pàgina Subencarregats del tractament; l'Acord d'encàrrec del tractament en regula els detalls.
Violacions de la seguretat de les dades personals: Si una violació afecta dades tractades com a encarregat, ho notifiquem al Client sense dilació indeguda, si és possible dins de 48 hores; l'Acord d'encàrrec del tractament en regula els detalls.
Notificació de vulnerabilitats: Acceptem notificacions a Seguretat i mitjançant el fitxer /.well-known/security.txt.
Llista de comprovació de configuració i llançament: A l'àrea d'administració, una llista de comprovació mesura l'estat de les configuracions rellevants per a la seguretat, com ara les còpies de seguretat, els administradors sense segon factor, la configuració de correu i el senyal de vida, i mostra les desviacions.
Revisió d'aquestes mesures (art. 32(1)(d) RGPD): en cada canvi significatiu del servei, després de cada incident de seguretat i, en la resta de casos, com a mínim una vegada a l'any. En fer-ho, avaluem si les mesures són eficaces i encara s'ajusten als riscos, i registrem el resultat en una versió nova d'aquesta pàgina o, si no canvia res, amb la data de la revisió a la secció 11. De manera continuada, la llista de comprovació de configuració i llançament mesura l'estat de les configuracions que cobreix.
Auditories externes: Actualment no s'encarreguen proves de penetració externes i no hi ha certificacions de seguretat. Ho indiquem aquí perquè ningú no les doni per fetes.

10. Previst, encara no implementat

Aquests punts no són mesures compromeses fins que figurin aquí com a implementats en una versió nova:

Còpia de seguretat en una segona ubicació: una còpia xifrada de la còpia de seguretat nocturna fora del servidor, perquè fins i tot una pèrdua total del servidor no provoqui una pèrdua de dades.
Segon punt de comprovació: La confirmació independent de les comprovacions al navegador des d'una segona ubicació està preparada al servei, però no configurada. Sense aquest segon punt, no hi ha confirmació des d'una segona ubicació.
Reforç de l'administració del servidor: Aquest treball continua. Pels motius indicats a la secció 1, no en publiquem els detalls.

11. Estat i versió

Versió 1.1 · Última actualització: 22 d'octubre de 2026 · en cas de discrepàncies entre les versions lingüístiques, preval la versió polonesa en lloc de l'alemanya; cap altre canvi.
Versió 1.0 · Última actualització: 11 d'octubre de 2026 · primera versió com a pàgina separada; abans, annex 2 de l'Acord d'encàrrec del tractament. Correccions respecte de l'annex anterior: la prova de restauració s'executa setmanalment, les còpies de seguretat són al mateix servidor, no s'executa cap bateria de proves automatitzada abans de cada desplegament i les connexions de la xarxa interna no estan xifrades en tot el seu recorregut. Noves descripcions: xifrat de les credencials per a l'escaneig que requereix iniciar sessió, aïllament de l'escàner, supervisió creuada i alerta d'error.
Els canvis es publiquen amb un número de versió nou aquí i a la visió general Canvis als documents contractuals; per a qualsevol debilitament de les mesures, s'aplica el termini de preavís de l'Acord d'encàrrec del tractament.
En cas de discrepàncies entre les versions lingüístiques, preval la versió polonesa.

Com el podem ajudar?