Trumpai: kas privalo ar nori informuoti klientus po duomenų pažeidimo, pirmiausia kartu su duomenų apsaugos pareigūnu ir advokatu nusprendžia, ar yra pareiga pagal BDAR 34 str., ir išsiaiškina, ar verslo klientai patys yra duomenų valdytojai. Tada seka klientų grupės, saugūs kanalai, paruoštas klientų aptarnavimas ir baigiamasis pranešimas. Pranešimuose nėra prisijungimo nuorodų, kad jie netaptų fišingo pavyzdžiu. Šis puslapis yra bendro pobūdžio informacija ir nėra teisinė konsultacija.
Laiškas, kurio visi bijo
Serveris išvalytas, spraga uždaryta, teismo ekspertizė turi pirmų rezultatų. Dabar ant stalo guli klausimas, kurio daugelis vadovų mieliau išvengtų: ar turime tai pasakyti savo klientams? O jei taip, tai kaip, nepadarant daugiau žalos nei pats incidentas?
Padėtis aplink PHP2Shell šį klausimą daugeliui įmonių iškėlė iš naujo, net be įsilaužimo. Svetainės atsargumo sumetimais buvo atjungtos, klientai teiravosi, o sukčiai tokias situacijas, kaip rodo patirtis, išnaudoja suklastotiems pranešimams. Kaip apskritai sudaroma krizių komunikacija, kokia eilės tvarka ir su kokiu turiniu, aprašyta skyriuje Krizių komunikacija po atakos. Šis straipsnis gilinasi dar vienu žingsniu: sprendimas, klientų grupės ir praktinis įgyvendinimas.
Klientų informavimas po duomenų pažeidimo: pareiga ar sprendimas?
BDAR 34 str. reikalauja nedelsiant pranešti duomenų subjektams, kai asmens duomenų saugumo pažeidimas greičiausiai kelia didelį pavojų jų teisėms ir laisvėms. Pranešime aiškia ir paprasta kalba aprašomas pažeidimo pobūdis ir nurodomas bent vienas kontaktinis asmuo, tikėtinos pasekmės ir imtos ar planuojamos priemonės.
BDAR 34 str. 3 d. nurodo išimtis: kai duomenys, pavyzdžiui, dėl šifravimo, neprieinami neįgaliotiems asmenims, kai vėlesnės priemonės greičiausiai pašalina didelį pavojų arba kai pranešimas pareikalautų neproporcingų pastangų; tuomet jį pakeičia viešas paskelbimas. Ar viena iš šių išimčių taikoma, yra teisinis vertinimas kiekvienu atveju. Jis priklauso duomenų apsaugos pareigūnui ir advokatui, kaip ir pranešimas priežiūros institucijai, žr. BDAR pranešimo pareiga: 72 valandos po incidento.
Net be pareigos informavimas gali būti prasmingas. Klientai, apie incidentą sužinoję iš kito šaltinio, praranda pasitikėjimą greičiau nei tie, kurie apie jį išgirsta iš jūsų.
Lieka laiko klausimas. Kas informuoja per anksti, galbūt turės taisyti pareiškimus. Kas laukia per ilgai, rizikuoja, kad klientai tuo metu patirs žalą, pavyzdžiui, dėl fišingo naudojant nutekėjusius adresus. Pasiteisinęs vidurys: anksti pranešti, kas nustatyta ir ką klientai gali daryti patys, ir aiškiai pažadėti, kad sekos daugiau informacijos. „Nedelsiant“ pagal 34 str. nereiškia laukti tyrimo pabaigos.
Kuriuos klientus ir kaip pasiekti
Ne visiems klientams reikia to paties pranešimo. Skirkite bent tris grupes:
| Klientų grupė | Jūsų vaidmuo | Ką tai reiškia informavimui |
|---|---|---|
| Privatūs klientai su paskyra ar užsakymu | dažniausiai valdytojas | įvertinti pranešimą pagal 34 str., suprantama kalba, konkrečios rekomendacijos |
| Verslo klientai, kurių duomenis naudojate savo tikslams | dažniausiai valdytojas | dalykiška informacija įvardytiems kontaktiniams asmenims, kontekstas jų pačių pareigoms |
| Verslo klientai, kurių vardu tvarkote duomenis | duomenų tvarkytojas | nedelsiamas informavimas pagal 33 str. 2 d., pagalba jų pranešimams |
Trečioji grupė dažnai nepastebima. Jei eksploatuojate, pavyzdžiui, parduotuves ar portalus klientams, jie paprastai patys yra valdytojai ir turi vykdyti savo pranešimo pareigas. Tam jiems greitai ir išsamiai reikia jūsų informacijos.
Kanalai be fišingo skatinimo
Saugiausias kanalas yra tas, kurį klientai jau pažįsta. Pasiteisino:
- El. laiškas iš įprasto siuntėjo adreso, be prisijungimo nuorodų ir be priedų, su nurodymu pačiam atidaryti svetainę.
- Pranešimas po prisijungimo kliento paskyroje, kai tik sistema vėl veikia saugiai.
- Pranešimas svetainėje kaip viešas papildymas arba, kur tai numato 34 str. 3 d., kaip viešas paskelbimas.
- Laiškas paštu klientams be aktualaus el. pašto adreso arba esant ypač jautriems duomenims.
- Telefonas ir klientų aptarnavimas kaip kontaktinis punktas klausimams, su numeriu, kurį klientai jau pažįsta iš jūsų svetainės ar sąskaitos.
Kiekviename pranešime aiškiai nurodykite, kad niekada neprašote el. paštu ar telefonu slaptažodžių, kodų ar mokėjimo duomenų. Po žinomų incidentų sukčiai mielai siunčia pranešimus, kurie atrodo kaip jūsų.
Nuo sprendimo iki baigiamojo pranešimo
Taip eiga gali atrodyti praktikoje:
- Užfiksuoti faktus: kas įrodyta, kas tikėtina, kas nežinoma. Į išorę eina tik įrodyta.
- Gauti teisinį vertinimą: pareiga pagal 34 str., vaidmuo verslo klientų atžvilgiu, derinimas su pranešimu institucijai.
- Nustatyti klientų grupes ir kanalus, adresatų sąrašą imti iš savo sistemos, ne iš galbūt manipuliuotos kopijos.
- Paruošti klientų aptarnavimą: vidiniai klausimai ir atsakymai, aiški kalbos taisyklė, sudėtingų atvejų nukreipimas nurodytai tarnybai.
- Suformuluoti rekomendacijas klientams: pavyzdžiui, pakeisti slaptažodį, jei gali būti paveikti prisijungimo duomenys, ir atkreipti dėmesį į įtartinus pranešimus.
- Išsiųsti ir dokumentuoti: kas, kada ir kokiu kanalu buvo informuotas.
- Papildyti: pranešti naujus radinius ir išsiųsti baigiamąjį pranešimą, kai tyrimas baigtas.
Kas kontaktų kelius įmonėje nustatė iš anksto, sutaupo daug laiko, žr. Avariniai kontaktai: ką ir kada reikia informuoti?. Techninius žingsnius, kurie turėtų būti prieš informavimą, apibendrina kontrolinis sąrašas po įsilaužimo.
Kaip PHP SOS padeda konkrečiai?
- Pateikiame techninius incidento faktus taip parengtus, kad duomenų apsaugos pareigūnas ir advokatas galėtų įvertinti pareigas.
- Patikriname jūsų klientų pranešimus dėl techninio tikslumo ir dėl to, kad jie neduotų užpuolikams užuominų.
- Užtikriname, kad adresatų sąrašai ir klientų paskyros prieš siunčiant būtų paimti iš išvalytos sistemos.
- Per Incident Response pateikiame žinias tolesniems ir baigiamiesiems pranešimams sutartu ritmu.
Išvada: gera klientų informacija yra teisiškai patikrinta, suskirstyta pagal grupes, išsiųsta saugiais kanalais ir užbaigta. Šis puslapis yra bendro pobūdžio informacija ir nėra teisinė konsultacija; sprendimą kiekvienu atveju priimate kartu su duomenų apsaugos pareigūnu ir advokatu.
Dažni klausimai
Kada po duomenų pažeidimo privalau informuoti klientus?
Pagal BDAR 34 str., kai pažeidimas greičiausiai kelia didelį pavojų duomenų subjektų teisėms ir laisvėms. Yra išimčių, pavyzdžiui, kai duomenys veiksmingai užšifruoti. Vertinimą atliekate kartu su duomenų apsaugos pareigūnu ir advokatu; šis puslapis nėra teisinė konsultacija.
Kas galioja, jei duomenis tvarkau savo verslo klientų vardu?
Tuomet jūsų klientai dažniausiai patys yra duomenų valdytojai. Pagal BDAR 33 str. 2 d. duomenų tvarkytojas apie duomenų pažeidimą nedelsdamas praneša valdytojui, kai tik apie jį sužino. Pranešimas institucijai ir duomenų subjektams lieka jūsų kliento reikalas.
Ar galiu informuoti klientus, nors pareigos nėra?
Taip. Savanoriškas informavimas gali būti prasmingas, pavyzdžiui, jei dėl PHP2Shell svetainė atsargumo sumetimais buvo išjungta arba klientai kelia klausimų. Svarbu nurodyti tik užtikrintus faktus ir neskubėti raminti.
Kaip užkirsti kelią sukčiams imituoti mano pranešimą?
Pranešime nenaudokite prisijungimo nuorodų ir priedų, nukreipkite į savo žinomą svetainę ir aiškiai nurodykite, kokiais būdais niekada neprašote slaptažodžių ar mokėjimo duomenų.