Măsuri tehnice și organizatorice

Acest document este publicat în mai multe limbi. În cazul oricărei neconcordanțe între versiunile lingvistice, versiunea în limba polonă este cea obligatorie.

Versiunea 1.1 · Ultima actualizare: 22 octombrie 2026

Măsuri conform art. 32 RGPD prin care LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polonia, protejează serviciul formexposed. Această pagină face parte din Acordul de prelucrare a datelor ca Anexa 2.

1. Domeniu de aplicare și principiu

Măsurile se aplică tuturor datelor prelucrate de serviciu: datelor pe care le prelucrăm în numele Clienților noștri (descrise în Acordul de prelucrare a datelor) și datelor pentru care noi înșine suntem operator, cum ar fi conturile de client și jurnalele. Nu există niveluri de protecție separate pentru cele două; ceea ce protejează contul protejează și datele prelucrate în calitate de persoană împuternicită.

Structura conform art. 32(1) RGPD. Pseudonimizarea și criptarea (litera (a)) sunt tratate în secțiunea 4; asigurarea continuă a confidențialității, integrității, disponibilității și rezilienței sistemelor (litera (b)) în secțiunile 3, 5, 6 și 7; capacitatea de a restabili în timp util disponibilitatea după un incident (litera (c)) în secțiunea 7.1; procesul de testare, evaluare și apreciere periodică a eficacității (litera (d)) în secțiunea 9. Am selectat măsurile pe baza riscurilor descrise în Evaluarea impactului asupra protecției datelor, ținând seama de stadiul actual al tehnologiei și de costurile implementării.

Principiu: măsurat, nu intenționat. Aici este menționat doar ceea ce a fost efectiv implementat în cod sau în operare. Ceea ce este planificat, dar încă neimplementat, este enumerat expres ca „planificat” în secțiunea 10. O măsură care lipsește aici nu există în mod tacit.

Numele mașinilor, adresele interne, porturile, numele de utilizator și versiunile software nu sunt indicate în mod intenționat. Ele nu ajută pe nimeni să evalueze măsurile, dar îl ajută pe cel care dorește să le ocolească. Cine are nevoie de ele pentru un audit conform Acordului de prelucrare a datelor le primește în cursul acelui audit, sub obligația de confidențialitate, în măsura în care sunt necesare pentru audit.

2. Structura serviciului

Serviciul rulează pe două servere proprii ale furnizorului în Polonia, aflate în aceeași rețea internă:

Server web cu bază de date. Livrează aplicația, găzduiește baza de date, trimite notificările și face copii de rezervă ale datelor. Numai el este configurat să accepte cereri din internet.
Server de scanare. Efectuează verificările site-urilor terților și ale site-urilor proprii într-un browser și rulează modelul lingvistic care clasifică anumite formulare și adaugă cod în „Fix it for me”. Nu este configurat să accepte cereri din internet, ci își preia singur sarcinile de la serverul web și returnează rezultatele acolo.

În operare nu este implicat niciun furnizor de găzduire, centru de date sau cloud și nimic nu ajunge la un serviciu extern de IA. Ce terți primesc date este descris pe pagina Persoane împuternicite secundare.

3. Confidențialitate

3.1 Controlul accesului fizic

Serverele se află în spații ale furnizorului din Polonia care nu sunt deschise publicului. Doar proprietarul are acces (conform declarației operatorului). Adresa exactă a locației nu este indicată aici în mod intenționat.

3.2 Controlul accesului: autentificarea în serviciu

Parolele sunt stocate doar ca hash, folosind metoda standard a PHP (bcrypt). Dacă metoda standard se schimbă, hash-ul este reînnoit la următoarea autentificare. La o încercare de autentificare cu o adresă necunoscută, serverul calculează totuși un hash, astfel încât timpul de răspuns să nu dezvăluie dacă un cont există. De asemenea, răspunsul la o cerere de resetare a parolei nu dezvăluie nici prin formulare, nici prin durată dacă contul există; e-mailurile de resetare sunt trimise la aceeași adresă de cel mult trei ori pe oră. Parolele noi trebuie să aibă cel puțin zece caractere și nu pot depăși 72 de octeți (UTF-8), deoarece bcrypt nu ia în considerare mai mulți octeți. Schimbarea parolei deconectează toate celelalte dispozitive; resetarea ei prin link deconectează toate dispozitivele, iar linkul este valabil o singură dată.
Blocare după încercări eșuate. Autentificările eșuate sunt numărate per adresă IP; după prea multe într-un timp scurt (în prezent opt în 15 minute), autentificarea de la acea adresă este blocată temporar. O autentificare reușită resetează acest contor. Încercările sunt șterse după șapte zile. În plus, înaintea fiecărei verificări a parolei se numără o încercare per cont (pentru o adresă necunoscută, per adresa introdusă) și per adresă IP, inclusiv încercările reușite: în prezent cel mult opt per cont de la aceeași adresă IP și 80 per adresă IP în 15 minute; per cont, pentru toate adresele la un loc, se aplică o limită considerabil mai mare, împotriva ghicirii distribuite. Astfel, încercările eșuate de la o altă adresă nu mai blochează proprietarul în afara contului său. Aceste contoare conțin doar o cheie HMAC, nicio adresă de e-mail sau IP în clar, și expiră odată cu fereastra lor de timp. Dacă stocarea contoarelor nu este disponibilă, autentificarea este refuzată, nu permisă. Același tip de limită se aplică la confirmarea parolei înainte de schimbarea parolei sau a adresei, activarea sau dezactivarea celui de-al doilea factor, transferul unui spațiu de lucru, exportul de date și ștergerea contului (cinci încercări per cont în 15 minute), la înregistrări (zece per adresă IP pe oră) și la parolele portalurilor pentru clienți (zece încercări per portal și adresă IP, 50 per portal în 15 minute).
Al doilea factor. Fiecare cont poate activa autentificarea cu un cod unic conform RFC 6238 (TOTP). Secretul pentru acesta este stocat criptat în baza de date; cheia nu este stocată în baza de date, astfel încât un extras din baza de date nu este suficient în sine. Un cod acceptat nu este valabil a doua oară. Zece coduri de recuperare sunt stocate doar ca hash. Codurile unice și de recuperare sunt limitate la zece încercări per cont în 15 minute, inclusiv în timpul configurării.
Zona de administrare doar cu al doilea factor. Zona de administrare a operatorului se deschide doar pentru conturile cu al doilea factor activat. Lista de verificare a configurării raportează fiecare cont de administrator fără al doilea factor.
Sesiuni. Cookie-ul de sesiune nu poate fi citit de scripturi (HttpOnly), este trimis doar prin HTTPS (Secure) și nu este trimis odată cu cererile de pe site-uri terțe care ar putea modifica ceva (SameSite=Lax). La autentificare se creează un nou ID de sesiune, astfel încât un ID plantat în prealabil să nu mai fie valabil; serverul nu acceptă un ID de sesiune pe care nu l-a emis el însuși. Fiecare cont își vede dispozitivele conectate și le poate deconecta individual.
„Păstrează-mă conectat” este opțional și valabil 30 de zile, dar nu și pentru conturile cu drepturi de administrare; acestea se autentifică întotdeauna cu parolă și al doilea factor. Tokenul este format din două părți; partea de verificare este stocată în baza de date doar ca hash. Fiecare utilizare îl înlocuiește cu unul nou și, chiar și în cazul cererilor simultane, fiecare token este valabil o singură dată, astfel încât un token furat este observat cel târziu la următoarea vizită autentică.
Linkuri în e-mailuri. Linkurile pentru confirmarea adresei și resetarea parolei sunt stocate în baza de date doar ca hash. Linkul de resetare este valabil o oră, linkul de confirmare a unei înregistrări 72 de ore, linkul de confirmare a unei adrese modificate 24 de ore. Dacă adresa de e-mail este modificată, un link de resetare deschis devine invalid.
Interfețe. Cheile API, codurile de conectare ale extensiilor și codurile de implementare sunt stocate doar ca hash. Cheile API pot fi folosite doar de un număr limitat de ori pe minut; codurile de conectare ale extensiilor sunt valabile 15 minute și o singură dată.
Protecția împotriva boților pe formularele publice (înregistrare, autentificare, parolă, verificare, instrumentul pentru antete, opt-out, asistență și contact): Google reCAPTCHA, care este încărcat doar la trimitere. Este acceptat doar un răspuns valid de la Google cu un scor suficient pentru exact acțiunea formularului; dacă Google nu răspunde în trei secunde, trimiterea este refuzată. Detalii găsiți în Politica de confidențialitate.

3.3 Controlul accesului: administrarea serverelor

Serverul accesibil din internet folosește un filtru de pachete pentru a permite doar serviciile pe care le oferă și blochează automat adresele după autentificări eșuate repetate în administrarea serverului.
Procesele automate dintre servere folosesc chei proprii cu drepturi strict limitate. Cheia cu care serverul web livrează versiuni noi ale scanerului poate executa pe serverul de scanare doar o listă fixă de comenzi și poate doar copia, exclusiv în scriere, în directorul scanerului; cu ea nu este posibilă o autentificare interactivă, iar fiecare comandă respinsă este înregistrată în jurnal. De asemenea, serverul de scanare poate scrie capturi de ecran doar într-un anumit director de pe serverul web.
Procesul care servește site-ul web nu are nici acces de scriere la instalarea de producție, nici o cheie pentru serverul de scanare. O implementare declanșată în zona de administrare doar înregistrează o sarcină, pe care o execută o rulare separată.
Secretele, cum ar fi datele de acces la baza de date și cheile, sunt păstrate în fișiere de configurare din afara directorului servit și nu sunt copiate la implementare. Configurația serverului web nu este distribuită prin interfața web.

3.4 Controlul autorizării: drepturi în cadrul serviciului

Roluri. Fiecare spațiu de lucru are rolurile de proprietar, administrator și cititor. Modificarea, ștergerea, invitarea și salvarea datelor de autentificare sunt rezervate proprietarilor și administratorilor; doar proprietarul poate schimba rolurile și elimina membri. O invitație este valabilă doar atât timp cât persoana care a trimis-o este încă proprietar sau administrator. Cititorii văd adresele webhookurilor și ale canalelor de chat doar scurtate la host, deoarece adresa singură permite postarea în canal. Verificarea are loc pe server, nu doar în interfață.
Legarea de spațiul de lucru. Domeniile și setările sunt accesibile doar membrilor spațiului de lucru. Pentru fiecare verificare, Serviciul creează un raport sub un link aleatoriu care nu poate fi ghicit; rezultatele și capturile de ecran ale unei verificări pot fi accesate prin acest link fără autentificare, capturile de ecran doar împreună cu linkul raportului lor. Linkul apare în cont și în alerte; cine îl transmite mai departe transmite raportul.
Cererile care modifică starea necesită un token de securitate per sesiune (protecție CSRF), care este comparat în timp constant.
„Vizualizare ca client”. Pentru asistență, operatorul poate vedea aplicația așa cum o vede un Client. Vizualizarea se încheie după o oră, blochează modificările parolei, adresei, celui de-al doilea factor, dispozitivelor, abonamentului, exportului și ștergerii, închide între timp zona de administrare și este înregistrată în jurnal. Încheierea ei deconectează complet operatorul; acesta poate reveni în zona de administrare doar autentificându-se din nou cu parolă și al doilea factor. Clientul o poate vedea în exportul său de date.
Administrare. Doar câteva conturi autorizate în mod expres au drepturi administrative; fiecare resetare a unui al doilea factor de către administrare este înregistrată în jurnal.

3.5 Controlul separării

Datele clienților sunt separate logic per spațiu de lucru. Fiecare cale de citire și scriere din zona autentificată poartă cu sine această legătură; rapoartele sunt accesibile suplimentar prin linkul lor (secțiunea 3.4).
Dezvoltarea și operarea rulează în instalări separate, cu baze de date separate și utilizatori de baze de date separați. Utilizatorul de dezvoltare nu are acces la baza de date de producție. Datele reale ale clienților nu sunt copiate în dezvoltare; acolo lucrăm cu date de exemplu generate.
Pentru fiecare mediu, scanerul are propriile date de acces, cu drepturi doar asupra datelor de care are nevoie pentru sarcinile sale. Nu poate citi conturi, facturare sau jurnale.
Pe serverul web rulează și alte servicii ale aceluiași furnizor. Acestea au propriile baze de date și propriii utilizatori de baze de date, fără acces la datele acestui serviciu.

4. Criptare, pseudonimizare și reducerea la minimum a datelor

4.1 Datele de autentificare pentru scanarea în spatele autentificării

Pentru această funcție, Clientul stochează numele de utilizator și parola unui cont de test. Acestea sunt cele mai sensibile date din serviciu și sunt, prin urmare, protejate diferit față de orice altceva:

La stocare, serverul web le criptează cu cheia publică a serverului de scanare (ECIES: X25519 cu o cheie unică per înregistrare, HKDF-SHA256, AES-256-GCM). Cheia privată există doar pe serverul de scanare. Serverul web, baza de date și copiile de rezervă conțin doar text criptat; nici noi nu îl putem citi acolo.
Fiecare înregistrare este legată criptografic de domeniul său. Dacă este mutată la un alt domeniu, decriptarea eșuează.
Pentru o scanare, textul criptat este atașat sarcinii. Serverul de scanare îl decriptează și transmite datele de autentificare containerului de verificare doar prin intrarea standard, niciodată ca argument în linia de comandă care ar fi vizibil în listele de procese. De îndată ce serverul de scanare l-a citit, textul criptat este șters din sarcină; o rulare elimină eventualele resturi cel târziu după o oră.
Datele de autentificare nu sunt niciodată afișate, niciodată înregistrate în jurnal, niciodată furnizate prin API și nu sunt exportate. Interfața afișează doar primul caracter și lungimea numelui de utilizator. Eliminarea lor suprascrie textul criptat.
În spatele autentificării, scanerul doar citește: fără trimiteri, fără test activ, fără capturi de ecran, fără pagini de deconectare, ștergere sau reziliere.

4.2 Alte criptări și hash-uri

Parolele, codurile de recuperare, parolele portalurilor pentru clienți, cheile API, codurile de conectare și de implementare, tokenurile „Păstrează-mă conectat”, ID-urile de sesiune din lista de dispozitive și linkurile de confirmare și resetare sunt stocate doar ca hash.
Secretele pentru al doilea factor sunt stocate criptat (secțiunea 3.2).
Nu pretindem criptarea întregii baze de date în repaus. Valorile sensibile sunt protejate individual, așa cum este descris mai sus.

4.3 Reducerea la minimum a datelor prin design

Verificarea livrării: Sunt citite doar antetele și cel mult primii 8 KB din text. În baza de date ajung doar momentul, atribuirea, după caz ID-ul trimiterii de test și rezultatul verificării autenticității (SPF, DKIM, DMARC), niciodată conținutul sau o adresă completă a expeditorului. Rezultatul autenticității celui mai recent e-mail este păstrat la domeniu și este suprascris de următorul; acesta conține adresa IP a serverului de e-mail care a livrat mesajul și domeniul de e-mail al expeditorului. E-mailul este șters din căsuța poștală după prelucrarea reușită; dacă preluarea sau ștergerea eșuează, acest lucru are loc la următoarea rulare reușită.
Verificări: Structura formularelor este stocată cu numele câmpurilor, tipurile și etichetele, atributele de obligativitate și vizibilitate, fără valori; scanerul citește începuturile câmpurilor ascunse precompletate (până la 24 de caractere) și ale atributelor data (până la 60 de caractere) doar în timpul verificării și nu le stochează. Capturile de ecran ale verificării complete nu sunt anonimizate; doar verificările în browser acoperă câmpurile de introducere. Adresele destinatarilor formularelor sunt stocate doar ca domeniu. Trimiterile de test active conțin doar texte de test marcate, fără date cu caracter personal.
Extensiile pentru WordPress și TYPO3 transmit doar cifre zilnice și caracteristici, cum ar fi inventarul pluginurilor, iar pentru un plugin WordPress conectat și domeniile linkurilor din mesajele blocate pentru protecția colectivă (activată implicit); niciun alt conținut, niciun nume, nicio adresă sau adresă IP a vizitatorilor. Contoarele opționale ale erorilor formularelor și câmpurilor sunt dezactivate implicit.
„Fix it for me”: Codul introdus este prelucrat doar pe durata cererii și nu este stocat.
Insigna: Imaginea insignei de pe site-urile clienților nu setează niciun cookie și nu pornește nicio sesiune.
Notificările operaționale către telefonul operatorului sunt texte fixe fără variabile, adică fără nume, adrese sau conținut. Notificările de eroare prin e-mail către operator conțin textul brut al mesajului de eroare, necurățat și trunchiat la 400 de caractere; în cazuri izolate, acesta poate conține adrese sau linkuri.
Protecția colectivă: Între extensiile Clienților se partajează doar domeniile din linkurile din spamul blocat; schimbul de rețele IP este dezactivat.
Localizare: Țara unei adrese IP este determinată dintr-un fișier local de bază de date; nicio adresă nu ajunge la un serviciu de geolocalizare.

5. Protecția împotriva utilizării abuzive a scanerului

Scanerul încarcă pagini ale terților cu un browser real. Fără protecție, ar fi un instrument cu care cineva din exterior ar putea ajunge în rețeaua noastră internă sau la alte ținte nepublice (falsificarea cererilor din partea serverului – SSRF). De aceea există două straturi independente și izolarea fiecărei rulări în parte.

5.1 Rulare izolată

Fiecare verificare rulează în propriul container, care este eliminat ulterior. Rulează fără drepturi de administrator, fără capabilități suplimentare ale sistemului de operare și fără posibilitatea de a escalada privilegiile. Sistemul său de fișiere este doar în citire, cu excepția unor zone volatile mici.
Memoria, numărul de procese și durata de rulare sunt limitate; o rulare care depășește timpul este oprită.

5.2 Rețea: două straturi

Primul strat, în scaner: Înainte de scanare și apoi pentru fiecare cerere a browserului, inclusiv redirecționările și conținutul încorporat, se verifică unde se rezolvă adresa. Rețelele private, locale, rezervate și de documentare (IPv4 și IPv6) sunt respinse, la fel ca porturile diferite de cele uzuale pentru web. Browserul nu permite service workers, iar conexiunile WebSocket sunt închise, deoarece ambele ar putea ocoli această verificare.
Al doilea strat, în rețea: Containerele rulează în propria rețea. Regulile firewallului permit de acolo conexiuni către internet doar pe porturile web; conexiunile către rețele private, inclusiv rețeaua noastră internă cu serverul web și baza de date, sunt blocate. Excepțiile de care are nevoie rularea verificării însăși sunt limitate la strictul necesar și descrise în documentația noastră internă. Acest strat acționează și dacă un nume se rezolvă diferit abia după prima verificare.

5.3 Cereri efectuate de serverul web

Atunci când serverul web însuși solicită adrese ale terților – pentru dovada controlului asupra domeniului, pentru instrumentul pentru antete, pentru căutarea fișierelor expuse, pentru cererile de puls, pentru interogările RDAP și verificarea certificatelor, pentru webhookuri și alertele prin chat și pentru al doilea punct de verificare opțional – se aplică aceleași reguli: doar protocoale web, pe porturile web uzuale (webhookurile și alertele prin chat doar prin HTTPS pe portul standard), doar adrese publice, conexiune doar la exact adresa verificată în prealabil, astfel încât un nume să nu poată fi redirecționat ulterior către o țintă internă, redirecționări fie neurmate deloc, fie urmate doar manual și reverificate de fiecare dată, limite scurte de timp; pentru dovada controlului asupra domeniului, pentru cererile de puls și pentru al doilea punct de verificare în verificările în browser, și o dimensiune limitată a răspunsului.

5.4 Ce nu face scanerul pe site-urile terților

Trimiterile de test active (cel mult cinci per verificare) există pentru Clienți doar pentru domeniile pentru care a fost furnizată dovada controlului (DNS, metaetichetă, fișier sau extensie); singura excepție sunt verificările interne ale propriilor noastre domenii de test și demonstrație. Numele de host al unui domeniu cu dovada controlului nu poate fi modificat, astfel încât dovada să nu treacă la un alt host. Tot restul este pasiv: citirea paginilor ca un vizitator.
Verificările în browser merg până la momentul dinaintea trimiterii și nu declanșează nicio comandă, plată sau trimitere.
Domeniile de pe lista de opt-out nu sunt verificate; monitorizarea în curs se încheie la următoarea verificare programată.

6. Integritate: transfer și introducere

6.1 Transport

Aplicația poate fi accesată din internet doar prin HTTPS; browserul este instruit să folosească doar HTTPS timp de un an (HSTS). Certificatele sunt reînnoite automat.
Alte antete restricționează încorporarea aplicației în pagini ale terților, ghicirea tipurilor de fișiere și trimiterea formularelor către ținte ale terților. O politică de securitate a conținutului permite rularea în aplicație doar a scripturilor pe care serverul le autorizează cu răspunsul respectiv; browserele actuale nu execută scripturi injectate sau handlere de evenimente în HTML.
Căsuța poștală a verificării livrării este preluată printr-o conexiune criptată, cu verificarea certificatului.
Webhookurile pot fi semnate cu un secret al Clientului (HMAC-SHA256 cu marcaj de timp), astfel încât destinatarul să poată verifica originea și integritatea. Cererile către al doilea punct de verificare opțional sunt semnate, iar pentru verificările în browser și răspunsurile acestora.
Spus deschis: Conexiunile din rețeaua noastră internă nu sunt criptate în totalitate. Datele de autentificare pentru scanarea în spatele autentificării rămân criptate pe tot parcursul (secțiunea 4.1).

6.2 Controlul introducerii și jurnale

Acțiunile importante din conturi și spații de lucru (cum ar fi autentificarea, modificările domeniilor, ale destinațiilor alertelor și ale drepturilor, ștergerile, accesul pentru asistență) sunt înregistrate în jurnalul de activitate cu contul, momentul, adresa IP și țara și sunt șterse după 365 zile.
Înregistrările accesărilor paginilor, păstrate pentru securitate și prevenirea abuzurilor, sunt șterse după 60 zile, jurnalele de erori după 90 zile, conținutul e-mailurilor trimise după 30 zile. Tokenurile de acces din adresele solicitate și din referreri, cum ar fi cele ale linkurilor de raport sau de portal, apar în înregistrările accesărilor paginilor doar în formă mascată.
Acceptarea documentelor contractuale este stocată cu versiunea afișată, suma ei de control, momentul, adresa IP și identificatorul browserului.
Jurnalele probatorii pot fi prevăzute cu un marcaj de timp de la o autoritate externă de marcare temporală; la aceasta ajunge doar o sumă de control a conținutului, nu conținutul însuși.

7. Disponibilitate și reziliență

7.1 Copii de rezervă

Baza de date este salvată în fiecare noapte. O copie de rezervă primește numele final doar după ce conținutul ei a fost verificat: finalizarea cu succes a programului de backup, cel puțin o înregistrare, tot atâtea tabele câte are baza de date și linia de încheiere a unei rulări complete. Copiile de rezervă mai vechi sunt eliminate doar după una nouă reușită.
Fiecare copie de rezervă este ștearsă după 14 zile. Locul de stocare se află în afara oricărui director servit; un loc din interiorul proiectului este respins.
Testul de restaurare: O dată pe săptămână, cea mai recentă copie de rezervă este încărcată într-o bază de date temporară, comparată tabel cu tabel cu producția și ștearsă din nou. Rezultatul este stocat.
Dacă o copie de rezervă sau un test eșuează, se trimite o notificare prin e-mail și pe telefonul operatorului.
Recuperarea după un incident: Dacă baza de date cade sau datele sunt corupte, restaurăm cea mai recentă copie de rezervă testată. Modificările făcute de la acea copie, de regulă cel mult cele dintr-o zi, se pot pierde în acest proces; dacă o copie de rezervă a eșuat, corespunzător mai multe. Reexecutăm apoi cererile de ștergere ulterioare cunoscute (secțiunea 8). Nu ne angajăm la un anumit timp de recuperare.
Limită, spusă deschis: Copiile de rezervă sunt stocate în prezent în aceeași locație ca baza de date și nu sunt criptate separat. Ele protejează împotriva erorilor de operare, a modificărilor greșite și a datelor corupte, nu și împotriva pierderii serverului însuși. O copie criptată într-o a doua locație este planificată (secțiunea 10).
Datele de autentificare pentru scanarea în spatele autentificării sunt conținute în copiile de rezervă doar ca text criptat; secretul celui de-al doilea factor doar în formă criptată, cu o cheie din afara bazei de date.

7.2 Monitorizare

O rulare de stare verifică la fiecare cinci minute componentele serviciului, inclusiv baza de date, coada și semnalul de viață (heartbeat) al scanerului, pe care scanerul îl scrie periodic chiar și atunci când este inactiv. Dacă o componentă cade, se trimite o notificare; dacă își revine, o notificare de revenire la normal.
Supraveghere încrucișată: O rulare de stare nu poate raporta căderea mașinii pe care rulează. De aceea, serverul de scanare verifică în fiecare minut dacă aplicația răspunde și, după mai multe eșecuri consecutive, trimite un text fix pe telefonul operatorului. Invers, serverul web monitorizează semnalul de viață al scanerului; lista de verificare a configurării arată dacă supravegherea încrucișată funcționează.
Alertă de eroare: Un tip de eroare care nu a mai apărut niciodată este raportat o dată, imediat; o acumulare de erori declanșează doar un singur semnal pe telefonul operatorului; o dată pe zi se trimite o prezentare generală. Astfel, nu aflăm de o eroare abia de la un Client.
Limită, spusă deschis: Ambele servere se află în aceeași locație. O cădere a întregii locații, de exemplu a alimentării cu energie sau a conexiunii la internet, nu este raportată de niciun mecanism de alertare, ci observată de un om.

7.3 Modificări și implementare

Versiunile noi sunt mai întâi construite și testate în mediul de dezvoltare separat. Implementarea verifică toate condițiile prealabile înainte de scrierea primului fișier, efectuează modificările schemei bazei de date și lasă verificările în curs să se încheie în mod ordonat înainte de repornirea scanerului.
Pentru parcursul unui Client nou există un test de fum (smoke test) prin HTTP real, care este rulat după schimbări. Nu pretindem o suită de teste automate înaintea fiecărei implementări.

8. Ștergere și perioade de stocare

O rulare de ștergere în fiecare noapte aplică perioadele indicate în Politica de confidențialitate și în Acordul de prelucrare a datelor. Aceasta citește aceleași setări din care sunt preluate cifrele din texte; pentru aceste perioade, textul și comportamentul nu diferă deci.
Rezultatele verificărilor, inclusiv capturile de ecran, sunt șterse după 13 luni (cel mai recent per domeniu rămâne), cifrele extensiilor după 13 luni, jurnalele de livrare a alertelor după 90 zile, solicitările de asistență după 24 luni.
Eliminarea unui domeniu șterge datele domeniului, inclusiv verificările, formularele, constatările, capturile de ecran, rapoartele, sarcinile, destinațiile și jurnalele alertelor, incidentele, datele de livrare, datele de autentificare pentru scanarea în spatele autentificării și dovezile.
Ștergerea unui cont are loc imediat; spațiile de lucru fără alți membri sunt șterse împreună cu datele lor, spațiile de lucru cu alți membri trec la un alt membru, mai întâi la administratori, iar dintre aceștia la cel mai vechi. Până la expirarea propriilor perioade rămân: jurnalele ale căror intrări păstrează vechiul număr de cont, care nu mai face trimitere la niciun cont existent, inclusiv intrarea privind ștergerea, precum și e-mailurile trimise, dovada încheierii contractului, solicitările de asistență, rapoartele verificărilor clienților potențiali (până la 90 de zile) și datele de facturare la Stripe; detalii găsiți în Politica de confidențialitate.
Datele șterse rămân în copiile de rezervă până la expirarea acestora după 14 zile. Nu are loc o ștergere țintită în cadrul unei copii de rezervă; dacă o copie de rezervă este restaurată, cererile de ștergere ulterioare cunoscute sunt executate din nou manual.

9. Organizare și revizuire

Persoane: Serviciul este operat în prezent chiar de proprietar. Alte persoane primesc acces doar după un angajament de confidențialitate și doar în măsura necesară și prelucrează date numai pe baza instrucțiunilor noastre (art. 29 și art. 32(4) RGPD).
Persoane împuternicite secundare: Le recrutăm doar după verificarea garanțiilor lor și pe baza unui contract conform art. 28(4) RGPD și le enumerăm pe pagina Persoane împuternicite secundare; detaliile sunt reglementate de Acordul de prelucrare a datelor.
Încălcări ale securității datelor cu caracter personal: Dacă o încălcare a securității datelor cu caracter personal afectează datele prelucrate în calitate de persoană împuternicită, notificăm Clientul fără întârzieri nejustificate, dacă este posibil în termen de 48 de ore; detaliile sunt reglementate de Acordul de prelucrare a datelor.
Raportarea vulnerabilităților: Acceptăm rapoarte la Securitate și prin fișierul /.well-known/security.txt.
Lista de verificare pentru configurare și lansare: În zona de administrare, o listă de verificare măsoară starea setărilor relevante pentru securitate, cum ar fi copiile de rezervă, administratorii fără al doilea factor, configurarea e-mailului și semnalul de viață, și afișează abaterile.
Revizuirea acestor măsuri (art. 32(1)(d) RGPD): la fiecare modificare semnificativă a serviciului, după fiecare incident de securitate și în rest cel puțin o dată pe an. Cu această ocazie evaluăm dacă măsurile sunt eficace și încă corespund riscurilor și înregistrăm rezultatul într-o nouă versiune a acestei pagini sau, dacă nu se schimbă nimic, cu data revizuirii în secțiunea 11. În mod continuu, lista de verificare pentru configurare și lansare măsoară starea setărilor pe care le acoperă.
Audituri externe: În prezent nu sunt comandate teste de penetrare externe și nu există certificări de securitate. Acest lucru este menționat aici pentru ca nimeni să nu presupună că ar exista.

10. Planificat, încă neimplementat

Aceste puncte nu sunt măsuri asumate până când nu sunt enumerate aici ca implementate într-o nouă versiune:

Copie de rezervă într-o a doua locație: o copie criptată a copiei de rezervă nocturne în afara serverului, astfel încât nici pierderea totală a serverului să nu ducă la pierderea datelor.
Al doilea punct de verificare: Confirmarea independentă a verificărilor în browser dintr-o a doua locație este pregătită în serviciu, dar nu este configurată. Fără ea nu există confirmare dintr-o a doua locație.
Consolidarea securității administrării serverelor: Aceasta continuă. Din motivele indicate în secțiunea 1, nu publicăm detalii.

11. Stare și versiune

Versiunea 1.1 · Ultima actualizare: 22 octombrie 2026 · în caz de neconcordanțe între versiunile lingvistice, prevalează versiunea în limba poloneză în locul celei în limba germană; nicio altă modificare.
Versiunea 1.0 · Ultima actualizare: 11 octombrie 2026 · prima versiune ca pagină separată; anterior Anexa 2 la Acordul de prelucrare a datelor. Corectat față de anexa anterioară: testul de restaurare rulează săptămânal, copiile de rezervă se află pe același server, nu rulează o suită de teste automate înaintea fiecărei implementări, conexiunile din rețeaua internă nu sunt criptate în totalitate. Descrise nou: criptarea datelor de autentificare pentru scanarea în spatele autentificării, izolarea scanerului, supravegherea încrucișată și alerta de eroare.
Modificările sunt publicate cu un nou număr de versiune aici și în prezentarea generală Modificări ale documentelor contractuale; pentru orice slăbire a măsurilor se aplică termenul de preaviz din Acordul de prelucrare a datelor.
În caz de neconcordanțe între versiunile lingvistice, prevalează versiunea în limba poloneză.

Cum vă putem ajuta?