Tehniskie un organizatoriskie pasākumi

Šis dokuments ir publicēts vairākās valodās. Ja starp valodu versijām ir kādas neatbilstības, saistoša ir poļu valodas versija.

Versija 1.1 · Pēdējoreiz atjaunināts: 2026. gada 22. oktobrī

Pasākumi saskaņā ar VDAR 32. pantu, ar kuriem LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polija, aizsargā pakalpojumu formexposed. Šī lapa ir Datu apstrādes līguma daļa kā 2. pielikums.

1. Darbības joma un princips

Pasākumi attiecas uz visiem pakalpojuma apstrādātajiem datiem: uz datiem, ko mēs apstrādājam savu Klientu uzdevumā (aprakstīti Datu apstrādes līgumā), un uz datiem, kuriem pārzinis esam mēs paši, piemēram, klientu kontiem un žurnāliem. Abiem nav atsevišķu aizsardzības līmeņu; tas, kas aizsargā kontu, aizsargā arī apstrādātāja datus.

Struktūra atbilstoši VDAR 32. panta 1. punktam. Pseidonimizācija un šifrēšana (a) apakšpunkts) ir aplūkota 4. sadaļā; sistēmu pastāvīga konfidencialitāte, integritāte, pieejamība un noturība (b) apakšpunkts) – 3., 5., 6. un 7. sadaļā; spēja savlaicīgi atjaunot pieejamību pēc incidenta (c) apakšpunkts) – 7.1. sadaļā; process efektivitātes regulārai testēšanai, izvērtēšanai un novērtēšanai (d) apakšpunkts) – 9. sadaļā. Pasākumus mēs izvēlējāmies, pamatojoties uz riskiem, kas aprakstīti mūsu Novērtējumā par ietekmi uz datu aizsardzību, ņemot vērā jaunākos tehnoloģiju sasniegumus un īstenošanas izmaksas.

Princips: izmērīts, nevis iecerēts. Šeit ir norādīts tikai tas, kas faktiski ir īstenots kodā vai darbībā. Tas, kas ir plānots, bet vēl nav īstenots, 10. sadaļā ir skaidri uzskaitīts kā „plānots”. Pasākums, kura šeit nav, nav klusībā ieviests.

Iekārtu nosaukumi, iekšējās adreses, porti, lietotājvārdi un programmatūras versijas apzināti netiek norādīti. Tie nevienam nepalīdz novērtēt pasākumus, bet palīdz tam, kurš vēlas tos apiet. Ikviens, kam tie nepieciešami revīzijai saskaņā ar Datu apstrādes līgumu, tos saņems šīs revīzijas gaitā ar konfidencialitātes nosacījumu, ciktāl tie revīzijai ir nepieciešami.

2. Pakalpojuma uzbūve

Pakalpojums darbojas divos pakalpojuma sniedzēja paša serveros Polijā, kas atrodas vienā iekšējā tīklā:

Tīmekļa serveris ar datubāzi. Tas nodrošina lietotni, glabā datubāzi, sūta paziņojumus un veido datu rezerves kopijas. Tikai tas ir iestatīts pieņemt pieprasījumus no interneta.
Skenēšanas serveris. Tas pārlūkprogrammā veic trešo personu un pašu vietņu pārbaudes un darbina valodas modeli, kas klasificē atsevišķas formas un pievieno kodu funkcijā „Fix it for me”. Tas nav iestatīts pieņemt pieprasījumus no interneta, bet pats izgūst savus uzdevumus no tīmekļa servera un atgriež tur rezultātus.

Darbībā nav iesaistīts neviens mitināšanas, datu centra vai mākoņpakalpojumu sniedzējs, un nekas netiek nodots ārējam MI pakalpojumam. Kuras trešās personas saņem datus, ir izklāstīts lapā Apakšapstrādātāji.

3. Konfidencialitāte

3.1 Fiziskās piekļuves kontrole

Serveri atrodas pakalpojuma sniedzēja telpās Polijā, kas nav atvērtas sabiedrībai. Piekļuve ir tikai īpašniekam (saskaņā ar operatora sniegto informāciju). Atrašanās vietas precīza adrese šeit apzināti netiek norādīta.

3.2 Piekļuves kontrole: pieteikšanās pakalpojumā

Paroles tiek glabātas tikai kā jaucējvērtība, izmantojot PHP standarta metodi (bcrypt). Ja standarta metode mainās, jaucējvērtība tiek atjaunota nākamajā pieteikšanās reizē. Pieteikšanās mēģinājumam ar nezināmu adresi serveris tik un tā aprēķina jaucējvērtību, lai atbildes laiks neatklātu, vai konts pastāv. Tāpat atbilde uz paroles atiestatīšanas pieprasījumu ne ar formulējumu, ne ar ilgumu neatklāj, vai konts pastāv; atiestatīšanas e-pasta ziņojumi uz vienu un to pašu adresi tiek sūtīti ne vairāk kā trīs reizes stundā. Jaunajām parolēm jābūt vismaz desmit rakstzīmes garām, un tās nedrīkst pārsniegt 72 baitus (UTF-8), jo bcrypt vairāk baitu neņem vērā. Paroles maiņa izraksta visas pārējās ierīces; tās atiestatīšana ar saiti izraksta visas ierīces, un saite ir derīga tikai vienu reizi.
Bloķēšana pēc neveiksmīgiem mēģinājumiem. Neveiksmīgas pieteikšanās tiek skaitītas katrai IP adresei; pēc pārāk daudziem mēģinājumiem īsā laikā (pašlaik astoņi 15 minūtēs) pieteikšanās no šīs adreses tiek uz laiku bloķēta. Veiksmīga pieteikšanās šo skaitītāju atiestata. Mēģinājumi tiek dzēsti pēc septiņām dienām. Turklāt pirms katras paroles pārbaudes tiek ieskaitīts viens mēģinājums katram kontam (nezināmai adresei – katrai ievadītajai adresei) un katrai IP adresei, ieskaitot veiksmīgos mēģinājumus: pašlaik ne vairāk kā astoņi katram kontam no vienas IP adreses un 80 katrai IP adresei 15 minūtēs; katram kontam no visām adresēm kopā piemēro ievērojami augstāku ierobežojumu pret izkliedētu minēšanu. Tādējādi neveiksmīgi mēģinājumi no citas adreses vairs nebloķē īpašnieka piekļuvi kontam. Šie skaitītāji satur tikai HMAC atslēgu, nevis e-pasta vai IP adresi atklātā tekstā, un beidzas līdz ar savu laika logu. Ja skaitītāju krātuve nav pieejama, pieteikšanās tiek atteikta, nevis atļauta. Tāda paša veida ierobežojums attiecas uz paroles apstiprināšanu pirms paroles vai adreses maiņas, otrā faktora ieslēgšanu vai izslēgšanu, darbvietas nodošanu, datu eksportu un konta dzēšanu (pieci mēģinājumi katram kontam 15 minūtēs), uz reģistrācijām (desmit katrai IP adresei stundā) un uz klientu portālu parolēm (desmit mēģinājumi katram portālam un IP adresei, 50 katram portālam 15 minūtēs).
Otrais faktors. Katrā kontā var iespējot pieteikšanos ar vienreizēju kodu saskaņā ar RFC 6238 (TOTP). Šim nolūkam paredzētais noslēpums tiek glabāts datubāzē šifrētā veidā; atslēga datubāzē netiek glabāta, tāpēc ar datubāzes izrakstu vien nepietiek. Pieņemts kods otrreiz nav derīgs. Desmit atkopšanas kodi tiek glabāti tikai kā jaucējvērtība. Vienreizējiem un atkopšanas kodiem ir ierobežojums – desmit mēģinājumi katram kontam 15 minūtēs, arī iestatīšanas laikā.
Administrēšanas sadaļa tikai ar otro faktoru. Operatora administrēšanas sadaļa atveras tikai kontiem ar iespējotu otro faktoru. Iestatīšanas kontrolsaraksts ziņo par katru administratora kontu bez otrā faktora.
Sesijas. Sesijas sīkdatni nevar nolasīt skripti (HttpOnly), tā tiek sūtīta tikai pa HTTPS (Secure) un netiek sūtīta ar pieprasījumiem no trešo personu vietnēm, kas varētu kaut ko mainīt (SameSite=Lax). Piesakoties tiek izveidots jauns sesijas ID, lai iepriekš iestādīts ID vairs nebūtu derīgs; serveris nepieņem sesijas ID, ko tas nav izsniedzis pats. Katrs konts redz savas pieteiktās ierīces un var tās atsevišķi izrakstīt.
„Atcerēties mani” nav obligāts un ir derīgs 30 dienas, taču ne kontiem ar administrēšanas tiesībām; tie vienmēr piesakās ar paroli un otro faktoru. Marķieris sastāv no divām daļām; pārbaudošā daļa datubāzē tiek glabāta tikai kā jaucējvērtība. Katra izmantošana to aizstāj ar jaunu, un pat vienlaicīgu pieprasījumu gadījumā katrs marķieris ir derīgs tikai vienu reizi, tāpēc nozagts marķieris tiek pamanīts ne vēlāk kā nākamajā īstajā apmeklējumā.
Saites e-pasta ziņojumos. Saites adreses apstiprināšanai un paroles atiestatīšanai datubāzē tiek glabātas tikai kā jaucējvērtība. Atiestatīšanas saite ir derīga vienu stundu, reģistrācijas apstiprināšanas saite – 72 stundas, mainītas adreses apstiprināšanas saite – 24 stundas. Ja e-pasta adrese tiek mainīta, atklāta atiestatīšanas saite kļūst nederīga.
Saskarnes. API atslēgas, paplašinājumu savienojuma kodi un ieviešanas kodi tiek glabāti tikai kā jaucējvērtība. API atslēgas var izmantot tikai ierobežotu reižu skaitu minūtē; paplašinājumu savienojuma kodi ir derīgi 15 minūtes un tikai vienu reizi.
Aizsardzība pret botiem publiskajās formās (reģistrācija, pieteikšanās, parole, pārbaude, galveņu rīks, atteikšanās, atbalsts un saziņa): Google reCAPTCHA, kas tiek ielādēta tikai iesniegšanas brīdī. Tiek pieņemta tikai derīga Google atbilde ar pietiekamu vērtējumu tieši formas darbībai; ja Google neatbild trīs sekunžu laikā, iesniegums tiek atteikts. Sīkāka informācija ir Privātuma politikā.

3.3 Piekļuves kontrole: serveru administrēšana

No interneta sasniedzamais serveris ar pakešu filtru atļauj tikai tos pakalpojumus, ko tas piedāvā, un automātiski bloķē adreses pēc atkārtotām neveiksmīgām pieteikšanās reizēm serveru administrēšanā.
Automatizētie procesi starp serveriem izmanto atsevišķas atslēgas ar šauri ierobežotām tiesībām. Atslēga, ar kuru tīmekļa serveris piegādā jaunas skenera versijas, skenēšanas serverī drīkst izpildīt tikai fiksētu komandu sarakstu un drīkst tikai kopēt, tikai rakstīšanas režīmā, skenera direktorijā; interaktīva pieteikšanās ar to nav iespējama, un katra noraidītā komanda tiek reģistrēta žurnālā. Tāpat skenēšanas serveris drīkst rakstīt ekrānuzņēmumus tikai noteiktā direktorijā tīmekļa serverī.
Procesam, kas apkalpo vietni, nav ne rakstīšanas piekļuves darba instalācijai, ne atslēgas skenēšanas serverim. Administrēšanas sadaļā ierosināta izvietošana tikai reģistrē uzdevumu, ko izpilda atsevišķs process.
Noslēpumi, piemēram, datubāzes pieteikšanās dati un atslēgas, tiek glabāti konfigurācijas failos ārpus apkalpotās direktorijas un izvietošanas laikā netiek kopēti līdzi. Tīmekļa servera konfigurācija netiek izplatīta caur tīmekļa saskarni.

3.4 Autorizācijas kontrole: tiesības pakalpojumā

Lomas. Katrā darbvietā ir lomas „īpašnieks”, „administrators” un „lasītājs”. Mainīšana, dzēšana, uzaicināšana un pieteikšanās datu saglabāšana ir paredzēta īpašniekiem un administratoriem; tikai īpašnieks drīkst mainīt lomas un noņemt dalībniekus. Uzaicinājums ir derīgs tikai tik ilgi, kamēr persona, kas to nosūtīja, joprojām ir īpašnieks vai administrators. Lasītāji redz tīmekļa āķu un tērzēšanas kanālu adreses tikai saīsinātas līdz resursdatoram, jo jau ar adresi vien var publicēt kanālā. Pārbaude notiek serverī, ne tikai saskarnē.
Piesaiste darbvietai. Domēni un iestatījumi ir pieejami tikai darbvietas dalībniekiem. Par katru pārbaudi Pakalpojums izveido ziņojumu ar nejaušu saiti, ko nevar uzminēt; pārbaudes rezultātiem un ekrānuzņēmumiem caur šo saiti var piekļūt bez pieteikšanās, ekrānuzņēmumiem – tikai kopā ar to ziņojuma saiti. Saite parādās kontā un brīdinājumos; ikviens, kas to nodod tālāk, nodod tālāk ziņojumu.
Stāvokli mainošiem pieprasījumiem nepieciešams drošības marķieris katrai sesijai (CSRF aizsardzība), kas tiek salīdzināts nemainīgā laikā.
„Skatīt kā klients”. Atbalsta nolūkos operators var redzēt lietotni tā, kā to redz Klients. Skats beidzas pēc vienas stundas, bloķē paroles, adreses, otrā faktora, ierīču, abonementa, eksporta un dzēšanas izmaiņas, šajā laikā aizver administrēšanas sadaļu un tiek reģistrēts žurnālā. Tā beigšana pilnībā izraksta operatoru; operators var atgriezties administrēšanas sadaļā, tikai atkārtoti piesakoties ar paroli un otro faktoru. Klients to var redzēt savā datu eksportā.
Administrēšana. Administratīvās tiesības ir tikai dažiem skaidri pilnvarotiem kontiem; katra otrā faktora atiestatīšana, ko veic administrācija, tiek reģistrēta žurnālā.

3.5 Nošķiršanas kontrole

Klientu dati ir loģiski nošķirti pēc darbvietas. Katrs lasīšanas un rakstīšanas ceļš pieteiktajā sadaļā ietver šo piesaisti; ziņojumi papildus ir pieejami caur savu saiti (3.4. sadaļa).
Izstrāde un darbība notiek atsevišķās instalācijās ar atsevišķām datubāzēm un atsevišķiem datubāzes lietotājiem. Izstrādes lietotājam nav piekļuves darba datubāzei. Īsti klientu dati netiek kopēti uz izstrādes vidi; tur mēs strādājam ar ģenerētiem paraugdatiem.
Katrā vidē skenerim ir savi pieteikšanās dati ar tiesībām tikai uz tiem datiem, kas tam nepieciešami tā uzdevumiem. Tas nevar nolasīt kontus, norēķinus vai žurnālus.
Tīmekļa serverī darbojas arī citi tā paša pakalpojuma sniedzēja pakalpojumi. Tiem ir savas datubāzes un savi datubāzes lietotāji bez piekļuves šā pakalpojuma datiem.

4. Šifrēšana, pseidonimizācija un datu minimizēšana

4.1 Pieteikšanās dati skenēšanai aiz pieteikšanās

Šai funkcijai Klients saglabā testa konta lietotājvārdu un paroli. Tie ir sensitīvākie dati pakalpojumā, un tāpēc tie tiek aizsargāti citādi nekā viss pārējais:

Saglabājot tos, tīmekļa serveris tos šifrē ar skenēšanas servera publisko atslēgu (ECIES: X25519 ar vienreizēju atslēgu katram ierakstam, HKDF-SHA256, AES-256-GCM). Privātā atslēga pastāv tikai skenēšanas serverī. Tīmekļa serverī, datubāzē un rezerves kopijās ir tikai šifrteksts; arī mēs to tur nevaram nolasīt.
Katrs ieraksts ir kriptogrāfiski piesaistīts savam domēnam. Ja to pārvieto uz citu domēnu, atšifrēšana neizdodas.
Skenēšanai šifrteksts tiek pievienots uzdevumam. Skenēšanas serveris to atšifrē un nodod pieteikšanās datus pārbaudes konteineram tikai caur standarta ievadi, nekad kā komandrindas argumentu, kas būtu redzams procesu sarakstos. Tiklīdz skenēšanas serveris to ir nolasījis, šifrteksts tiek dzēsts no uzdevuma; atsevišķs process notīra jebkādas atliekas ne vēlāk kā pēc vienas stundas.
Pieteikšanās dati nekad netiek parādīti, nekad netiek reģistrēti žurnālos, nekad netiek izvadīti caur API un netiek eksportēti. Saskarne parāda tikai lietotājvārda pirmo rakstzīmi un garumu. To noņemšana pārraksta šifrtekstu.
Aiz pieteikšanās skeneris tikai lasa: nekādas iesniegšanas, neviena aktīva testa, nekādu ekrānuzņēmumu, nekādu izrakstīšanās, dzēšanas vai anulēšanas lapu.

4.2 Cita šifrēšana un jaucējvērtības

Paroles, atkopšanas kodi, klientu portālu paroles, API atslēgas, savienojuma un ieviešanas kodi, „Atcerēties mani” marķieri, sesiju ID ierīču sarakstā un apstiprināšanas un atiestatīšanas saites tiek glabāti tikai kā jaucējvērtība.
Otrā faktora noslēpumi tiek glabāti šifrētā veidā (3.2. sadaļa).
Mēs neapgalvojam, ka visa datubāze miera stāvoklī ir šifrēta. Sensitīvās vērtības tiek aizsargātas atsevišķi, kā aprakstīts iepriekš.

4.3 Datu minimizēšana jau izstrādē

Piegādes pārbaude: tiek nolasītas tikai galvenes un ne vairāk kā pirmie 8 KB teksta. Datubāzē nonāk tikai laiks, piesaiste, attiecīgā gadījumā testa iesnieguma ID un autentiskuma pārbaudes (SPF, DKIM, DMARC) rezultāts, nekad saturs vai pilna sūtītāja adrese. Jaunākā e-pasta ziņojuma autentiskuma rezultāts tiek glabāts pie domēna, un nākamais to pārraksta; tas satur piegādājošā pasta servera IP adresi un sūtītāja e-pasta domēnu. Pēc veiksmīgas apstrādes e-pasta ziņojums tiek dzēsts no pastkastes; ja izgūšana vai dzēšana neizdodas, tas notiek nākamajā veiksmīgajā izpildē.
Pārbaudes: formu struktūra tiek saglabāta ar lauku nosaukumiem, tipiem un etiķetēm, obligātuma un redzamības atribūtiem, bez vērtībām; iepriekš aizpildītu slēpto lauku sākumu (līdz 24 rakstzīmēm) un datu atribūtu sākumu (līdz 60 rakstzīmēm) skeneris nolasa tikai pārbaudes laikā un nesaglabā. Pilnās pārbaudes ekrānuzņēmumi netiek aizklāti; ievades laukus aizklāj tikai pārlūkprogrammas pārbaudes. Formu adresātu adreses tiek glabātas tikai kā domēns. Aktīvie testa iesniegumi satur tikai marķētus testa tekstus bez personas datiem.
WordPress un TYPO3 paplašinājumi pārsūta tikai dienas skaitļus un raksturlielumus, piemēram, spraudņu sarakstu, un pievienotam WordPress spraudnim arī saišu domēnus no bloķētiem ziņojumiem kolektīvajai aizsardzībai (pēc noklusējuma ieslēgta); nekādu citu saturu, nekādus apmeklētāju vārdus, adreses vai IP adreses. Neobligātie formu un lauku kļūdu skaitītāji pēc noklusējuma ir izslēgti.
„Fix it for me”: ielīmētais kods tiek apstrādāts tikai pieprasījuma izpildes laikā un netiek saglabāts.
Emblēma: emblēmas attēls klientu vietnēs neiestata sīkdatnes un nesāk sesiju.
Darbības paziņojumi uz operatora tālruni ir fiksēti teksti bez mainīgajiem, t. i., bez vārdiem, adresēm vai satura. Kļūdu paziņojumi pa e-pastu operatoram satur kļūdas ziņojuma neapstrādātu tekstu, kas nav attīrīts un ir saīsināts līdz 400 rakstzīmēm; atsevišķos gadījumos tajā var būt adreses vai saites.
Kolektīvā aizsardzība: starp Klientu paplašinājumiem tiek kopīgoti tikai domēni no saitēm bloķētā surogātpastā; IP tīklu apmaiņa ir izslēgta.
Atrašanās vieta: IP adreses valsts tiek noteikta no vietējā datubāzes faila; neviena adrese netiek nosūtīta ģeolokācijas pakalpojumam.

5. Aizsardzība pret skenera ļaunprātīgu izmantošanu

Skeneris ielādē trešo personu lapas ar īstu pārlūkprogrammu. Bez aizsardzības tas būtu rīks, ar kuru kāds no ārpuses varētu sasniegt mūsu iekšējo tīklu vai citus nepubliskus mērķus (servera puses pieprasījumu viltošana, SSRF). Tāpēc ir divi neatkarīgi slāņi un katras atsevišķās izpildes izolācija.

5.1 Izolēta izpilde

Katra pārbaude darbojas savā konteinerā, kas pēc tam tiek noņemts. Tas darbojas bez administratora tiesībām, bez papildu operētājsistēmas spējām un bez iespējas paaugstināt privilēģijas. Tā failu sistēma ir tikai lasāma, izņemot nelielas īslaicīgas zonas.
Atmiņa, procesu skaits un izpildes laiks ir ierobežoti; izpilde, kas pārsniedz laiku, tiek pārtraukta.

5.2 Tīkls: divi slāņi

Pirmais slānis, skenerī: pirms skenēšanas un pēc tam katram atsevišķam pārlūkprogrammas pieprasījumam, ieskaitot pāradresācijas un iegulto saturu, tiek pārbaudīts, uz kurieni adrese tiek atrisināta. Privātie, lokālie, rezervētie un dokumentācijas tīkli (IPv4 un IPv6) tiek noraidīti, tāpat kā porti, kas nav tīmeklim ierastie. Pārlūkprogramma neatļauj service worker, un WebSocket savienojumi tiek aizvērti, jo abi varētu apiet šo pārbaudi.
Otrais slānis, tīklā: konteineri darbojas savā tīklā. Ugunsmūra noteikumi atļauj savienojumus no turienes uz internetu tikai tīmekļa portos; savienojumi ar privātajiem tīkliem, ieskaitot mūsu iekšējo tīklu ar tīmekļa serveri un datubāzi, ir bloķēti. Izņēmumi, kas nepieciešami pašai pārbaudes izpildei, ir ierobežoti līdz nepieciešamajam un aprakstīti mūsu iekšējā dokumentācijā. Šis slānis darbojas arī tad, ja nosaukums tiek atrisināts citādi tikai pēc pirmās pārbaudes.

5.3 Tīmekļa servera veiktie pieprasījumi

Ja tīmekļa serveris pats pieprasa trešo personu adreses – domēna kontroles pierādījumam, galveņu rīkam, atklātu failu meklēšanai, pulsa pieprasījumiem, RDAP vaicājumiem un sertifikātu pārbaudei, tīmekļa āķiem un tērzēšanas brīdinājumiem un neobligātajam otrajam kontrolpunktam –, piemēro tos pašus noteikumus: tikai tīmekļa protokoli ierastajos tīmekļa portos (tīmekļa āķi un tērzēšanas brīdinājumi tikai pa HTTPS standarta portā), tikai publiskas adreses, savienojums tikai tieši ar iepriekš pārbaudīto adresi, lai nosaukumu nevarētu vēlāk pāradresēt uz iekšēju mērķi, pāradresācijām vai nu vispār neseko, vai seko tikai manuāli un katru reizi tās pārbauda no jauna, īsi laika ierobežojumi; domēna kontroles pierādījumam, pulsa pieprasījumiem un otrajam kontrolpunktam pārlūkprogrammas pārbaudēs – arī ierobežots atbildes lielums.

5.4 Ko skeneris nedara trešo personu vietnēs

Aktīvie testa iesniegumi (ne vairāk kā pieci katrā pārbaudē) Klientiem ir pieejami tikai domēniem, kuriem ir iesniegts kontroles pierādījums (DNS, meta tags, fails vai paplašinājums); vienīgais izņēmums ir mūsu pašu testa un demonstrācijas domēnu iekšējās pārbaudes. Domēna ar kontroles pierādījumu resursdatora nosaukumu nevar mainīt, lai pierādījums nepārietu uz citu resursdatoru. Viss pārējais ir pasīvs: lapu lasīšana kā apmeklētājam.
Pārlūkprogrammas pārbaudes notiek līdz brīdim pirms iesniegšanas un neizraisa nekādu pasūtījumu, maksājumu vai iesniegšanu.
Domēni, kas ir atteikšanās sarakstā, netiek pārbaudīti; pastāvīgā uzraudzība beidzas ar nākamo plānoto pārbaudi.

6. Integritāte: pārsūtīšana un ievade

6.1 Transportēšana

Lietotne no interneta ir sasniedzama tikai pa HTTPS; pārlūkprogrammai tiek norādīts vienu gadu izmantot tikai HTTPS (HSTS). Sertifikāti tiek atjaunoti automātiski.
Citas galvenes ierobežo lietotnes iegulšanu trešo personu lapās, failu tipu minēšanu un formu iesniegšanu trešo personu mērķiem. Satura drošības politika ļauj lietotnē darboties tikai tiem skriptiem, kurus serveris atļauj ar attiecīgo atbildi; mūsdienu pārlūkprogrammas neizpilda HTML ievietotus skriptus vai notikumu apstrādātājus.
Piegādes pārbaudes pastkaste tiek nolasīta, izmantojot šifrētu savienojumu ar sertifikāta pārbaudi.
Tīmekļa āķus var parakstīt ar Klienta noslēpumu (HMAC-SHA256 ar laikspiedolu), lai saņēmējs varētu pārbaudīt izcelsmi un integritāti. Pieprasījumi neobligātajam otrajam kontrolpunktam ir parakstīti, un pārlūkprogrammas pārbaudēm – arī to atbildes.
Atklāti norādīts: savienojumi mūsu iekšējā tīklā nav šifrēti visur. Pieteikšanās dati skenēšanai aiz pieteikšanās paliek šifrēti visu laiku (4.1. sadaļa).

6.2 Ievades kontrole un žurnāli

Svarīgas darbības kontos un darbvietās (piemēram, pieteikšanās, domēnu, brīdinājumu galamērķu un tiesību izmaiņas, dzēšana, atbalsta piekļuve) tiek reģistrētas darbību žurnālā ar kontu, laiku, IP adresi un valsti un tiek dzēstas pēc 365 dienām.
Lapu piekļuves ieraksti, kas tiek glabāti drošības un ļaunprātīgas izmantošanas novēršanas nolūkos, tiek dzēsti pēc 60 dienām, kļūdu žurnāli – pēc 90 dienām, nosūtīto e-pasta ziņojumu saturs – pēc 30 dienām. Piekļuves marķieri pieprasītajās adresēs un atsaucēs (referrer), piemēram, ziņojumu vai portālu saitēs, lapu piekļuves ierakstos parādās tikai maskētā veidā.
Līguma dokumentu pieņemšana tiek saglabāta ar parādīto versiju, tās kontrolsummu, laiku, IP adresi un pārlūkprogrammas identifikatoru.
Pierādījumu žurnāliem var pievienot laikspiedolu no ārējas laikspiedolu iestādes; tai tiek nosūtīta tikai satura kontrolsumma, nevis pats saturs.

7. Pieejamība un noturība

7.1 Rezerves kopēšana

Datubāzes rezerves kopija tiek veidota katru nakti. Rezerves kopija saņem galīgo nosaukumu tikai pēc tam, kad ir pārbaudīts tās saturs: rezerves kopēšanas programmas veiksmīga pabeigšana, vismaz viens ieraksts, tikpat tabulu, cik ir datubāzē, un pilnīgas izpildes noslēguma rinda. Vecākās rezerves kopijas tiek noņemtas tikai pēc veiksmīgas jaunas kopijas izveides.
Katra rezerves kopija tiek dzēsta pēc 14 dienām. Glabāšanas vieta atrodas ārpus jebkuras apkalpotās direktorijas; vieta projekta iekšienē tiek noraidīta.
Atjaunošanas tests: reizi nedēļā jaunākā rezerves kopija tiek ielādēta vienreizlietojamā datubāzē, salīdzināta pa tabulām ar darba datubāzi un atkal dzēsta. Rezultāts tiek saglabāts.
Ja rezerves kopēšana vai tests neizdodas, tiek nosūtīts paziņojums pa e-pastu un uz operatora tālruni.
Atjaunošana pēc incidenta: ja datubāze sabojājas vai dati tiek bojāti, mēs atjaunojam jaunāko pārbaudīto rezerves kopiju. Izmaiņas, kas veiktas kopš šīs rezerves kopijas, parasti ne vairāk kā vienas dienas izmaiņas, šajā procesā var tikt zaudētas; ja kāda rezerves kopēšana nav izdevusies, attiecīgi vairāk. Pēc tam mēs atkārtoti izpildām zināmos vēlākos dzēšanas pieprasījumus (8. sadaļa). Mēs neapņemamies ievērot noteiktu atjaunošanas laiku.
Ierobežojums, atklāti norādīts: rezerves kopijas pašlaik tiek glabātas tajā pašā vietā, kur datubāze, un nav atsevišķi šifrētas. Tās aizsargā pret darbības kļūdām, kļūdainām izmaiņām un bojātiem datiem, nevis pret paša servera zudumu. Ir plānota šifrēta kopija otrā atrašanās vietā (10. sadaļa).
Pieteikšanās dati skenēšanai aiz pieteikšanās rezerves kopijās ir tikai kā šifrteksts; otrā faktora noslēpums – tikai šifrētā veidā, ar atslēgu ārpus datubāzes.

7.2 Uzraudzība

Statusa process ik pēc piecām minūtēm pārbauda pakalpojuma komponentus, ieskaitot datubāzi, rindu un skenera sirdspukstu, ko skeneris regulāri raksta arī dīkstāvē. Ja kāds komponents atteic, tiek nosūtīts paziņojums; ja tas atjaunojas – trauksmes atcelšana.
Savstarpējā uzraudzība: statusa process nevar ziņot par tās iekārtas atteici, kurā tas darbojas. Tāpēc skenēšanas serveris katru minūti pārbauda, vai lietotne atbild, un pēc vairākām secīgām kļūmēm ziņo ar fiksētu tekstu uz operatora tālruni. Savukārt tīmekļa serveris uzrauga skenera sirdspukstu; iestatīšanas kontrolsaraksts parāda, vai savstarpējā uzraudzība darbojas.
Kļūdu brīdinājums: kļūdas veids, kas iepriekš nekad nav radies, tiek nekavējoties paziņots vienu reizi; kļūdu uzkrāšanās izraisa tikai vienu signālu uz operatora tālruni; reizi dienā tiek nosūtīts pārskats. Tas nozīmē, ka par kļūdu mēs neuzzinām pirmo reizi no Klienta.
Ierobežojums, atklāti norādīts: abi serveri atrodas vienā vietā. Par visas atrašanās vietas atteici, piemēram, elektroapgādes vai interneta savienojuma, neziņo neviens brīdināšanas mehānisms, to pamana cilvēks.

7.3 Izmaiņas un izvietošana

Jaunas versijas vispirms tiek izveidotas un testētas atsevišķā izstrādes vidē. Izvietošana pārbauda visus priekšnosacījumus, pirms tiek ierakstīts pirmais fails, veic datubāzes shēmas izmaiņas un ļauj notiekošajām pārbaudēm kārtīgi pabeigties, pirms skeneris tiek restartēts.
Jauna Klienta ceļam ir paredzēts dūmu tests caur īstu HTTP, kas tiek izpildīts pēc pārslēgšanas. Mēs neapgalvojam, ka pirms katras atsevišķas izvietošanas tiek izpildīts automatizēts testu komplekts.

8. Dzēšana un glabāšanas termiņi

Katru nakti dzēšanas process nodrošina Privātuma politikā un Datu apstrādes līgumā norādīto termiņu ievērošanu. Tas nolasa tos pašus iestatījumus, no kuriem ņemti skaitļi tekstos; tāpēc šiem termiņiem teksts un darbība neatšķiras.
Pārbaužu rezultāti, ieskaitot ekrānuzņēmumus, tiek dzēsti pēc 13 mēnešiem (jaunākais katram domēnam paliek), paplašinājumu skaitļi – pēc 13 mēnešiem, brīdinājumu piegādes žurnāli – pēc 90 dienām, atbalsta pieprasījumi – pēc 24 mēnešiem.
Domēna noņemšana dzēš domēna datus, ieskaitot pārbaudes, formas, konstatējumus, ekrānuzņēmumus, ziņojumus, uzdevumus, brīdinājumu galamērķus un žurnālus, incidentus, piegādes datus, pieteikšanās datus skenēšanai aiz pieteikšanās un pierādījumus.
Konta dzēšana notiek nekavējoties; darbvietas bez citiem dalībniekiem tiek dzēstas kopā ar to datiem, darbvietas ar citiem dalībniekiem pāriet citam dalībniekam, vispirms administratoriem un starp tiem – tam, kurš ir dalībnieks visilgāk. Līdz to termiņu beigām paliek: žurnāli, kuru ierakstos saglabājas vecais konta numurs, kas vairs neattiecas ne uz vienu esošu kontu, ieskaitot dzēšanas ierakstu, kā arī nosūtītie e-pasta ziņojumi, līguma noslēgšanas pierādījums, atbalsta pieprasījumi, potenciālo klientu pārbaužu ziņojumi (līdz 90 dienām) un norēķinu dati pie Stripe; sīkāka informācija ir Privātuma politikā.
Dzēstie dati paliek rezerves kopijās līdz to derīguma beigām pēc 14 dienām. Mērķtiecīga dzēšana rezerves kopijā nenotiek; ja rezerves kopija tiek atjaunota, zināmie vēlākie dzēšanas pieprasījumi tiek atkārtoti izpildīti manuāli.

9. Organizācija un pārskatīšana

Personas: pakalpojumu pašlaik nodrošina pats īpašnieks. Citas personas saņem piekļuvi tikai pēc konfidencialitātes saistību uzņemšanās un tikai nepieciešamajā apjomā, un tās apstrādā datus tikai saskaņā ar mūsu norādījumiem (VDAR 29. pants un 32. panta 4. punkts).
Apakšapstrādātāji: mēs tos piesaistām tikai pēc to garantiju pārbaudes un saskaņā ar līgumu atbilstoši VDAR 28. panta 4. punktam un uzskaitām lapā Apakšapstrādātāji; sīkāk to regulē Datu apstrādes līgums.
Personas datu aizsardzības pārkāpumi: ja personas datu aizsardzības pārkāpums skar apstrādātāja datus, mēs bez nepamatotas kavēšanās, ja iespējams – 48 stundu laikā, paziņojam par to Klientam; sīkāk to regulē Datu apstrādes līgums.
Ziņošana par ievainojamībām: mēs pieņemam ziņojumus lapā Drošība un ar failu /.well-known/security.txt.
Iestatīšanas un darbības sākšanas kontrolsaraksts: administrēšanas sadaļā kontrolsaraksts mēra ar drošību saistīto iestatījumu stāvokli, piemēram, rezerves kopēšanu, administratorus bez otrā faktora, pasta iestatījumus un sirdspukstu, un parāda novirzes.
Šo pasākumu pārskatīšana (VDAR 32. panta 1. punkta d) apakšpunkts): pēc katrām būtiskām pakalpojuma izmaiņām, pēc katra drošības incidenta un pārējā laikā vismaz reizi gadā. To darot, mēs izvērtējam, vai pasākumi ir efektīvi un joprojām atbilst riskiem, un dokumentējam rezultātu jaunā šīs lapas versijā vai, ja nekas nemainās, ar pārskatīšanas datumu 11. sadaļā. Pastāvīgi iestatīšanas un darbības sākšanas kontrolsaraksts mēra to iestatījumu stāvokli, kurus tas aptver.
Ārējas revīzijas: pašlaik netiek pasūtīti ārēji ielaušanās testi, un nav drošības sertifikātu. Tas šeit ir norādīts, lai neviens nepieņemtu, ka tādi ir.

10. Plānots, vēl nav īstenots

Šie punkti nav apņemšanās pasākumi, līdz tie jaunā versijā šeit tiek uzskaitīti kā īstenoti:

Rezerves kopija otrā atrašanās vietā: nakts rezerves kopijas šifrēta kopija ārpus servera, lai pat pilnīgs servera zudums neradītu datu zudumu.
Otrais kontrolpunkts: neatkarīga pārlūkprogrammas pārbaužu apstiprināšana no otras atrašanās vietas pakalpojumā ir sagatavota, bet nav iestatīta. Bez tā nav apstiprinājuma no otras atrašanās vietas.
Serveru administrēšanas nostiprināšana: tā turpinās. 1. sadaļā minēto iemeslu dēļ mēs sīkāku informāciju nepublicējam.

11. Statuss un versija

Versija 1.1 · Pēdējoreiz atjaunināts: 2026. gada 22. oktobrī · neatbilstību gadījumā starp valodu versijām noteicošā ir poļu valodas versija, nevis vācu valodas versija; citu izmaiņu nav.
Versija 1.0 · Pēdējoreiz atjaunināts: 2026. gada 11. oktobrī · pirmā versija kā atsevišķa lapa; iepriekš Datu apstrādes līguma 2. pielikums. Salīdzinājumā ar iepriekšējo pielikumu labots: atjaunošanas tests notiek reizi nedēļā, rezerves kopijas atrodas tajā pašā serverī, pirms katras izvietošanas netiek izpildīts automatizēts testu komplekts, savienojumi iekšējā tīklā nav šifrēti visur. No jauna aprakstīts: pieteikšanās datu šifrēšana skenēšanai aiz pieteikšanās, skenera izolācija, savstarpējā uzraudzība un kļūdu brīdinājums.
Izmaiņas tiek publicētas ar jaunu versijas numuru šeit un pārskatā Līguma dokumentu grozījumi; jebkādai pasākumu vājināšanai piemēro Datu apstrādes līgumā noteikto paziņošanas termiņu.
Neatbilstību gadījumā starp valodu versijām noteicošā ir poļu valodas versija.

Kā varam palīdzēt?