Oct 2, 2026
Kā pārbaudīt trauksmes celšanas programmatūras drošību: tehniskā audita kontrolsaraksts darba devējiem

Pirms uzticat sava uzņēmuma trauksmes cēlēju vārdus kādam piegādātājam, jāpārliecinās par trim lietām: vai serveris tiešām neko nezina, vai dati nepamet Eiropu un vai žurnslogs ir auditoram derīgs. Šajā rakstā aplūkojam, kā pārbaudīt trauksmes celšanas programmatūras drošību — no IP adrešu un sīkfailu verifikācijas līdz ISO 27001 sertifikātu nolasīšanai — un kāpēc šī pārbaude pieder pie atbilstības speciālista, ne tikai IT nodaļas pienākumiem. Konkrēti, kā pārbaudīt trauksmes celšanas programmatūras drošību praksē — ar pārlūka rīkiem, dokumentāciju un neatkarīgu auditu palīdzību.
Saturs
- Galvenās atziņas
- Kāpēc drošības pārbaude nav IT departamenta, bet gan atbilstības speciālista atbildība
- Vai IP adrese, sīkfaili un pirkstu nospiedumi tiešām netiek vākti – kā to pārbaudīt
- Šifrēšana no gala līdz galam: ko nozīmē AES-256-GCM un nulles piekļuve
- Kur dati tiek glabāti un kāpēc ES vai Šveice maina risku profilu
- Audita gatavs darbību žurnslogs: kādi ieraksti izdzīvos ES regulas pārbaudē
- Sertifikāti, kas tiešām skaita – ISO 27001, SOC 2 un to robežas
- Praktisks kontrolsaraksts: 10 jautājumi, ko uzdot pārdevējam
- Biežāk uzdotie jautājumi
- Avoti
Galvenās atziņas
- Trauksmes celšanas programmatūras drošības novērtējums ir atbilstības pienākums: tas nosaka, vai organizācija spēj izpildīt ES Trauksmes celšanas direktīvas (2019/1937) 7 dienu apstiprinājuma un 3 mēnešu izskatīšanas termiņus, kuru nokavēša var tikt uzskatīta par atbilstības pārkāpumu.
- Īstu anonimitāti apliecina trīs tehniski pārbaudāmi apgalvojumi: IP adrešu nevākšana, sīkfailu neizmantošana un pārlūkprogrammas pirkstu nospiedumu neveidošana — katru no tiem var pārbaudīt ar pārlūkā pieejamajiem izstrādātāja rīkiem, piemēram, pārlūka izstrādātāja rīku cilnēm "Network" un "Application".
- Šifrēšana no gala līdz galam ar AES-256-GCM un nulles piekļuves arhitektūra nozīmē, ka pat pakalpojuma sniedzējs nevar izlasīt ziņojumu saturu — un to var pierādīt tikai ar kriptogrāfisko atslēgu pārvaldības dokumentāciju, nevis ar mārketinga materiāliem.
- Datu glabāšanas vieta maina risku profilu: ES vai Šveicē mitināti dati gandrīz vienmēr ir drošāki par ASV mitinātu alternatīvu, ņemot vērā trešo pušu piekļuves riskus un jurisdikciju, piemēram, CLOUD Act piemērošanu ASV uzņēmumiem.
- Audita gatavs darbību žurnslogs ietver laika zīmogu, neizdzēšamus ierakstus un standarta eksporta formātus (CSV, PDF, JSON) — bez šiem elementiem auditors nevarēs pārliecināties par notikumu hronoloģiju un hronoloģisku integritāti.
Kāpēc drošības pārbaude nav IT departamenta, bet gan atbilstības speciālista atbildība
Atbilstības speciālists ir atbildīgs par programmatūras drošības novērtējumu, jo tieši viņš uzrauga ES Trauksmes celšanas direktīvas (2019/1937) prasību izpildi un uzņemas risku, ja ziņotāja identitāte noplūst. IT nodaļa var pārbaudīt tehniskos parametrus, bet tikai atbilstības speciālists spēj novērtēt, vai konkrētais tehniskais lēmums atbilst regulējuma prasībām par ziņotāju aizsardzību un datu minimizēšanu.
Šo atbildības sadalījumu nosaka trīs faktori. Pirmkārt, atbilstības speciālisti ir tie, kas pārzina 7 dienu apstiprinājuma termiņu un 3 mēnešu izskatīšanas termiņu — IT speciālists parasti nezina, kā šie termiņi ir formulēti direktīvā un kādi pierādījumi auditoram ir jāuzrāda. Otrkārt, gadījumos, kad ziņotājs vēlas palikt anonīms, atbilstības speciālistam ir jāsaprot, kādas tehniskās metodes patiešām nodrošina anonimitāti un kuras ir tikai mārketinga saukļi. Treškārt, ja auditors vai regulators pieprasa pierādījumus, atbildību par dokumentāciju nes personas, kas tieši strādā ar atbilstības programmu, nevis infrastruktūras administratori.
Praksē tas nozīmē, ka pirms līguma parakstīšanas atbilstības speciālistam pašam jāpārskata pārdevēja drošības dokumentācija, jāuzdod konkrēti jautājumi un jāpieprasa neatkarīgi audita ziņojumi. IT nodaļas loma ir sniegt tehnisko atbalstu — piemēram, pārbaudīt, vai pārlūkprogrammas tīkla pieprasījumi tiešām nesatur identificējošu informāciju, piemēram, IP adreses HTTP galvenēs.
Vai IP adrese, sīkfaili un pirkstu nospiedumi tiešām netiek vākti – kā to pārbaudīt
Anonīmas ziņošanas drošība sākas ar trīs tehniskiem jautājumiem: vai platforma vāc IP adreses, vai tā izmanto sīkfailus un vai tā veido pārlūkprogrammas pirkstu nospiedumus. Atbilde uz katru no tiem ir jāpārbauda ar konkrētiem rīkiem, nevis jāuzticas pārdevēja apgalvojumiem.
IP adrešu pārbaude notiek šādi: atveriet ziņošanas lapu, atveriet pārlūkprogrammas izstrādātāja rīkus (F12), dodieties uz cilni "Network" un iesniedziet testa ziņojumu. Pēc tam pārbaudiet katru tīkla pieprasījumu — ja redzat HTTP galveni "X-Forwarded-For" vai "Client-IP", kas satur Jūsu IP adresi, platforma to vāc. Servera puses žurnālos šī informācija var tikt saglabāta pat tad, ja tā netiek sūtīta uz priekšgalu. Pēc anonīmas ziņošanas programmatūras kritērijiem īsta anonimitāte nozīmē, ka servera puse vispār nepieraksta savienojuma metadatus, piemēram, IP adreses vai laika zīmogus.
Sīkfailu pārbaude ir vienkāršāka: atveriet ziņošanas lapu, pēc tam pārlūkprogrammas izstrādātāja rīkos atveriet cilni "Application" un pārbaudiet sadaļu "Cookies". Ja redzat jebkādus sīkfailus, kas nav nepieciešami tehniskai sesijas uzturēšanai (piemēram, trešo pušu izsekošanas sīkfaili), platforma neatbilst anonimitātes prasībām. Sīkfaili var tikt izmantoti, lai saistītu vairākus ziņojumus ar vienu lietotāju vai lai izveidotu noturīgu identifikatoru pat pēc IP adreses maiņas.
Kā pārbaudīt pārlūkprogrammas pirkstu nospiedumu veidošanu?
Pārlūkprogrammas pirkstu nospiedumu veidošana notiek, kad platforma vāc informāciju par Jūsu ekrāna izšķirtspēju, fontu sarakstu, laika joslu, valodu un citiem parametriem, lai izveidotu unikālu identifikatoru. Pārbaudiet to, atverot vietni ar pārlūka konsole un izpildot komandu navigator.userAgent, screen.width, screen.height — ja šie dati tiek sūtīti uz serveri, platforma veido pirkstu nospiedumu. Šāda veida pirkstu nospiedumu veidošana ir sīki aprakstīta OWASP resursos, un tā var tikt izmantota, lai atšķirtu vienu lietotāju no cita bez IP adreses.
Šifrēšana no gala līdz galam: ko nozīmē AES-256-GCM un nulles piekļuve
Šifrēšana no gala līdz galam nozīmē, ka ziņojuma saturs tiek šifrēts ziņotāja pārlūkprogrammā un atšifrēts tikai saņēmēja ierīcē — serveris glabā tikai šifrtekstu un nevar izlasīt ziņojumu saturu. AES-256-GCM ir simetriskās šifrēšanas algoritms ar 256 bitu atslēgu, kas tiek uzskatīts par drošu pret mūsdienu uzbrukuma metodēm, savukārt nulētās piekļuves arhitektūra nozīmē, ka pat pakalpojuma sniedzēja darbinieki tehniski nevar piekļūt atšifrētajiem datiem, jo privātās atslēgas nekad nepamet lietotāja ierīci.
Tehniskais pamatojums ir šāds. Kad ziņotājs iesniedz ziņojumu, pārlūkprogramma ģenerē unikālu AES-256-GCM atslēgu konkrētajam ziņojumam. Šī atslēga tiek šifrēta ar katra saņēmēja publisko atslēgu, izmantojot P-256 ECDH atslēgu apmaiņas protokolu. Serveris saņem tikai šifrēto ziņojumu un šifrēto atslēgu — bez privātās atslēgas tas nevar atšifrēt saturu. Privātās atslēgas tiek glabātas tikai ziņotāja un saņēmēja ierīcēs, aizsargātas ar Argon2id atvasinātu paroles atslēgu.
Pārdevējam tas ir jāpierāda ar dokumentāciju, nevis tikai ar mārketinga materiāliem. Pieprasiet kriptogrāfisko arhitektūras shēmenos atslēgu pārvaldības procedūru aprakstu un neatkarīga kriptogrāfa vai drošības auditora ziņojumu. Ja pārdevējs nevar uzrādīt šos dokumentus vai atsakās atbildēt uz konkrētiem tehniskiem jautājumiem, tā ir sarkanā karoga zīme.
Kur dati tiek glabāti un kāpēc ES vai Šveice maina risku profilu
Datu glabāšanas vieta nosaka, kuriem likumiem dati pakļaujas un kuras valsts iestādes var pieprasīt piekļuvi. ES vai Šveicē mitināti dati parasti nozīmē stingrāku datu aizsardzības režīmu, mazāku trešo pušu piekļuves risku un skaidrāku juridisko ceļu, ja tomēr notiek datu noplūde.
Datu aizsardzība trauksmes celšanā kļūst īpaši svarīga, ņemot vērā, ka ziņojumi bieži satur sensitīvu informāciju par darbiniekiem, vadību vai organizācijas praksi. Ja dati tiek glabāti ārpus ES, piemēram, ASV, uz tiem var attiekties CLOUD Act un citi ASV normatīvie akti, kas piešķir ASV iestādēm plašas pilnvaras pieprasīt datus no amerikāņu uzņēmumiem. Pat ja serveri fiziski atrodas Eiropā, ja pakalpojuma sniedzējs ir ASV uzņēmums, risks nodod binātu strūsu.
Šveicē mitināti dati piedāvā papildu aizsardzības slāni, jo Šveices datu aizsardzības likumi ir saderīgi ar GDPR un tiek uzskatīti par papildu aizsardzības slāni salīdzinājumā ar daudzām citām jurisdikcijām. Turklāt Šveices datu centri bieži ir ISO 27001 sertificēti, kas nozīmē neatkarīgu informācijas drošības vadības sistēmas auditu un regulāru atjaunināšanu.
Praktiski tas nozīmē, ka līgumā ar pārdevēju ir jābūt skaidri norādītai datu glabāšanas vietai un jābūt garantijai, ka dati netiks pārvietoti ārpus sākotnēji norādītās jurisdikcijas bez iepriekšēja brīdinājuma. Šāda līguma garantija ir viens no dokumentējamiem pierādījumiem, ko auditors var pieprasīt atbilstības novērtēšanai.
Audita gatavs darbību žurnslogs: kādi ieraksti izdzīvos ES regulas pārbaudē
Audita gatavs darbību žurnslogs ietver laika zīmogotus, neizdzēšamus ierakstus par katru darbību ar ziņojumu, sākot no iesniegšanas brīža līdz izskatīšanas beigām. Šie ieraksti ir pierādījums regulatoram vai auditoram, ka organizācija ir ievērojusi noteiktos termiņus un procedūras.
Pēc ISO 37002:2021 vadlīnijām un ES Trauksmes celšanas direktīvas (2019/1937) prasībām darbību žurnslam ir jāsatur šādi elementi: ziņojuma saņemšanas laiks (ar laika zīmogu), 7 dienu apstiprinājuma paziņojuma nosūtīšanas laiks, visas darbības ar ziņojumu (piekļuve, labošana, komentāri), izskatīšanas sākuma un beigu laiks, un gala lēmums. Katram ierakstam jābūt nesaraujami saistītam ar iepriekšējiem ierakstiem, lai novērstu vēlāku manipulāciju un nodrošinātu hronoloģisku integritāti.
Svarīgi, lai žurnslogs būtu pieejams standarta formātos (CSV, PDF, JSON) un lai eksporta process pats par sevi tiktu reģistrēts žurnslogā. Ja auditors pieprasa pierādījumus un Jūs nevarat uzrādīt pilnīgu, nemainītu hronoloģiju, tas var tikt uzskatīts par atbilstības pārkāpumu un radīt administratīvu risku.
Sertifikāti, kas tiešām skaita – ISO 27001, SOC 2 un to robežas
ISO 27001 un SOC 2 ir divi biežāk sastopamie drošības sertifikāti, bet tiem ir dažādas jomas un ierobežojumi. ISO 27001 apliecina, ka organizācijai ir ieviesta informācijas drošības vadības sistēma (ISMS), savukārt SOC 2 apliecina, ka pakalpojuma sniedzējs ievēro noteiktus drošības, pieejamības un konfidencialitātes principus.
ISO 27001 whistleblowing kontekstā ir īpaši svarīgs, jo tas aptver visu organizācijas drošības vadību — no risku novērtēšanas līdz incidentu pārvaldībai. Sertifikāts nozīmē, ka neatkarīgs auditors ir pārbaudījis ISMS un apstiprinājis, ka tā atbilst starptautiskajam standartam. Tomēr ISO 27001 negarantē, ka konkrētais produkts ir drošs — tas apliecina tikai organizācijas spēju pārvaldīt drošību un uzturēt ISMS.
SOC 2 ziņojums (īpaši Type II) ir detalizētāks un aptver konkrētus drošības kontroles, kas darbojas noteiktā laika periodā. Tas ir vērtīgāks, ja vēlaties redzēt, kā pārdevējs faktiski pārvalda savu infrastruktūru. Tomēr SOC 2 ziņojumi parasti ir konfidenciāli, un pārdevējs var izsniegt tikai kopsavilkumu vai izvilkumu.
Abu sertifikātu robežas ir tādas, ka tie apliecina procesu un kontroles esamību, bet negarantē, ka katrs incidents vai konfigurācijas kļūda tiks novērsta. Tāpēc sertifikāti ir nepieciešams, bet ne pietiekams nosacījums. Papildus pieprasiet neatkarīgus ievainojamības skenēšanas rezultātus, ielaušanās testu ziņojumus un incidentu reaģēšanas procedūru aprakstu, lai iegūtu pilnīgāku priekšstatu.
Praktisks kontrolsaraksts: 10 jautājumi, ko uzdot pārdevējam
Šis kontrolsaraksts apkopo 10 jautājumus, kas jāuzdod katram trauksmes celšanas programmatūras piegādātājam pirms līguma parakstīšanas. Katrs jautājums ir formulēts tā, lai iegūtu pārbaudāmu atbildi, nevis vispārīgu mārketinga frāzi.
- Kā Jūs pierādāt, ka serverī netiek glabātas IP adreses un sīkfaili? — Pieprasiet neatkarīga auditora ziņojumu vai publisku drošības audita rezultātu.
- Kāda šifrēšanas shēma tiek izmantota ziņojumu aizsardzībai? — Atbildei jāietver konkrēts algoritms atalgoritms un atslēgu pārvaldības procedūra.
- Kur fiziski atrodas serveri un kāda ir datu glabāšanas jurisdikcija? — Atbildei jābūt skaidrai un jāatspoguļojas līgumā.
- Vai Jums ir ISO 27001 sertifikāts un kad tas tika atjaunots? — Pieprasiet sertifikāta kopiju un derīguma termiņu.
- Kā darbību žurnslogs tiek aizsargāts pret manipulācijām? — Atbildei jāietver tehniskie mehānismi atlaika hronoloģisku integritāti.
- Kādi ir standarta eksporta formāti audita vajadzībām? — Atbildei jābūt konkrētai: CSV, PDF, JSON vai cits formāts, ko Jūsu auditors var izmantot.
- Kā Jūs nodrošināt, ka ziņotāja identitāte paliek anonīma pat tad, ja pats ziņotājs to vēlāk atklāj? — Šis jautājums atklāj, vai sistēma ir patiesi anonīma vai tikai konfidenciāla.
- Kāda ir Jūsu incidentu reaģēšanas procedūra datu noplūdes gadījumā? — Atbildei jāietver konkrēts laika limits paziņošanai atpazīmēriekšķējiem).
- Vai Jūs veicat regulārus ielaušanās testus un vai rezultāti ir pieejami klientiem? — Pieprasiet vismaz kopsavilkumu.
- Kā tiks nodrošināta atbilstība ISO 37002 vadlīnijām un GDPR prasībām mūsu līguma ietvaros? — Atbildei jāietver konkrēti pienākumi un atbildības sadalījums.
Šo kontrolsarakstu var izmantot kā līguma pielikumu vai kā neatkarīgu novērtējuma dokumentu. Atbildes uz šiem jautājumiem veido pamatu trauksmes celšanas programmatūras audits, ko varēsiet uzrādīt gan iekšējiem auditoriem, gan ārējiem regulatoriem.
Biežāk uzdotie jautājumi
Kāpēc IP adrešu vākšana ir problēma anonīmai ziņošanai?
IP adrese var tikt izmantota, lai identificētu ziņotāju pat tad, ja vārds nav norādīts, jo IP adrese bieži ir piesaistīta konkrētam interneta pakalpojuma abonentam vai organizācijai. Ja servera žurnāli tiek pieprasīti vai noplūst, ziņotāja identitāte var tikt atklāta, pārkāpjot anonimitātes solījumu un pakļaujot ziņotāju atriebības riskam.
Kā atšķiras konfidenciāla un anonīma ziņošana?
Konfidenciālā ziņošanā organizācija zina ziņotāja identitāti un apņemas to neizpaust, savukārt anonīmā ziņošanā organizācija tehniski nevar uzzināt ziņotāja identitāti, jo dati tiek šifrēti pirms to nonākšanas serverī. Anonīma ziņošana nodrošina augstāku aizsardzības līmeni, bet ierobežo iespējas uzdot precizējošus jautājumus.
Vai Šveices datu centri tiešām ir drošāki par ES datu centriem?
Šveices datu centri piedāvā papildu aizsardzības slāni, jo Šveices likumi ierobežo ārvalstu iestāžu piekļuvi datiem un pieprasa Šveices tiesas orderi datu izsniegšanai. ES datu centriem ir spēkā GDPR aizsardzība, bet ES dalībvalstu iestāžu sadarbības mehānismi var būt ātrāki. Abu gadījumu riski ir zemāki nekā ASV vai citu jurisdikciju gadījumā, bet Šveice parasti tiek uzskatīta par visdrošāko.
Kādas ir ISO 37002:2021 prasības attiecībā uz darbību žurnslogu?
ISO 37002:2021 prasa, lai organizācija dokumentētu visus ar ziņojumu saistītos lēmumus un darbības, nodrošinātu to izsekojamību un aizsargātu žurnslogu pret nesankcionētu piekļuvi. Žurnslogam jābūt pieejamam auditam un jāsaglabājas noteiktu laika periodu pēc ziņojuma izskatīšanas beigām.
Kādas ir 7 dienu apstiprinājuma un 3 mēnešu izskatīšanas termiņu sekas?
Šie termiņi ir noteikti ES Trauksmes celšanas direktīvā (2019/1937) un Latvijas Trauksmes likumā. To neievērošana var novest pie administratīvām sankcijām, kā arī uzskatāma par atbilstības pārkāpumu, kas var tikt izmantots tiesvedībā pret organizāciju.
