Duomenų saugumo atitiktis: apsaugokite visą informacijos gyvavimo ciklą

Duomenų saugumą lengviau įvertinti, kai komanda gali atsekti informaciją nuo surinkimo iki ištrynimo. Tinkamos kontrolės priemonės priklauso nuo jautrumo, paskirties, naudotojų ir praradimo ar netinkamo naudojimo pasekmių. Gamybinė duomenų bazė gali būti gerai apsaugota, o tie patys įrašai lieka atviri eksportuotose skaičiuoklėse, pagalbos užklausų prieduose, analitikos srautuose ar atsarginėse kopijose.

Todėl CTO duomenų saugumo atitiktis yra inžinerijos ir įrodymų problema: nustatyti, kurie reikalavimai taikomi, paversti juos kontrolės priemonėmis kiekviename duomenų sraute ir įrodyti, kad šios kontrolės priemonės veikia. Politikos aprašo numatomą elgseną. Konfigūracijos, testai, žurnalai ir peržiūrėtos išimtys parodo, ar sistema iš tikrųjų taip elgiasi.

Atskirkite saugumo reikalavimus nuo platesnių duomenų prievolių

Duomenų saugumo atitiktis susijusi su apsauga nuo neteisėtos prieigos, atskleidimo, pakeitimo, sunaikinimo ir prieinamumo praradimo. Ji apima asmens informaciją, bet taip pat šaltinio kodą, finansinius įrašus, intelektinę nuosavybę, prisijungimo duomenis ir kitą jautrią verslo informaciją.

Platesnė duomenų atitiktis apima klausimus, į kuriuos vien saugumo kontrolės priemonės atsakyti negali: ar duomenų rinkimas teisėtas, kokie tikslai leidžiami, kokių pranešimų ar sutarčių reikia, kaip asmenys įgyvendina savo teises ir kiek laiko informacija gali būti saugoma. Šifravimas nepaverčia nepagrįsto duomenų rinkimo teisėtu. Teisėtas duomenų tvarkymo tikslas nepaverčia nesaugaus įgyvendinimo priimtinu.

Laikykite atskirus tris reikalavimų šaltinius:

• Įstatymai ir kiti teisės aktai: prievolės, nulemtos jurisdikcijos, duomenų tvarkymo veiklos, organizacijos vaidmens ir sektoriaus.
• Standartai ir patikinimo sistemos: struktūrizuoti saugumo valdymo ar nepriklausomo vertinimo požiūriai.
• Sutartys ir vidiniai įsipareigojimai: klientų sąlygos, sutartys su tiekėjais, tvarkymo politikos ir paslaugų pažadai.

Kiekvienam reikalavimui užfiksuokite šaltinį, apimtį, atsakingą asmenį ir interpretaciją. Tuomet inžinerija gali įgyvendinti bendras apsaugos priemones, klaidingai nelaikydama kiekvienos sistemos teisiškai lygiaverte.

Prieš rinkdamiesi kontrolės priemones nustatykite taikymą

Naudingas taikymo registras paaiškina, kodėl reikalavimas taikomas, o ne tik tai, kad kažkas jį įtraukė į kontrolinį sąrašą.

Tai pradiniai klausimai, o ne išsamūs teisiniai testai. Pavyzdžiui, su sveikata susijusiai programinei įrangai HIPAA automatiškai netaikomas vien todėl, kad ji tvarko sveikatos informaciją. Mokėjimų apdorojimo perdavimas išorės teikėjui gali sumažinti PCI DSS apimtį, tačiau automatiškai nepanaikina prekybininko atsakomybių.

BDAR 32 straipsnis reikalauja rizikai tinkamo saugumo, atsižvelgiant į tokius veiksnius kaip duomenų tvarkymo pobūdis, įgyvendinimo sąnaudos ir naujausia technikos pažanga. Jame nurodomos tokios priemonės kaip šifravimas, atsparumas, atkūrimas ir reguliarus vertinimas; jis nenustato visuotinio privalomo šifravimo visur.

ISO 27001 taikomas apibrėžtos apimties informacijos saugumo valdymo sistemai. Jo reikalavimai apima rizikos valdymą, vidaus auditą ir vadovybinę peržiūrą. A priedo kontrolės priemonės svarstomos taikant rizika grindžiamą taikomumą, o sprendimai dokumentuojami taikomumo pareiškime. Sertifikavimą atlieka nepriklausoma sertifikavimo įstaiga.

SOC 2 yra atestacijos ataskaita, o ne sertifikatas. Jos kriterijai susiję su saugumu ir, jei įtraukta į apimtį, prieinamumu, apdorojimo vientisumu, konfidencialumu ir privatumu. Nei SOC 2 ataskaita, nei ISO sertifikatas neįrodo atitikties BDAR.

Konkretiems sektoriams būdingas prievoles reikia vertinti atskirai. SOX susijęs su atitinkamų įmonių finansine atskaitomybe ir su ja susijusiomis vidaus kontrolės priemonėmis; CMMC – su apibrėžtais gynybos sutarčių reikalavimais ir informacinėmis aplinkomis. Europoje NIS2 direktyva reikalauja išanalizuoti sektorių, dydį, paslaugą ir įtraukimo taisykles pagal nacionalinį įgyvendinimą. Skaitmeninės veiklos atsparumo aktas (DORA) pirmiausia taikomas nurodytiems finansų subjektams, nustatant sutartines prievoles IRT paslaugų teikėjams ir priežiūros režimą paskirtiems kritiniams teikėjams. Nemanykite, kad kiekvienas finansinių technologijų ar technologijų tiekėjas turi tas pačias tiesiogines pareigas.

Sudarykite gyvavimo ciklo žemėlapį, apimantį antrines kopijas

Pradėkite nuo vieno svarbaus verslo proceso, pavyzdžiui, pacientų registracijos, darbo užmokesčio, klientų aptarnavimo ar mokėjimų suderinimo. Nustatykite jo duomenų savininką ir techninį savininką, tada atsekite informaciją per surinkimą, naudojimą, dalijimąsi, saugojimą, atkūrimą ir sunaikinimą.

Kiekvienam duomenų rinkiniui užfiksuokite:

• Jo paskirtį, jautrumą ir taikomus tvarkymo reikalavimus.
• Šaltinių sistemas, saugojimo vietas, sąsajas ir gavėjus.
• Žmones naudotojus, tarnybines paskyras, tiekėjus ir privilegijuotos prieigos kelius.
• Išvestinius duomenų rinkinius, eksportus, podėlius, testines kopijas, žurnalus ir atsargines kopijas.
• Saugojimo sukėlėjus, ištrynimo būdus ir išimtis.

Klasifikavimas turėtų vesti prie sprendimų. Žyma, pavyzdžiui, „riboto naudojimo sveikatos duomenys“, naudinga tik tada, kai ji nulemia leidžiamas paskirties vietas, prieigos taisykles, registravimą žurnaluose, šifravimą ir sunaikinimą. Derinkite konfidencialumą su vientisumu ir prieinamumu: pakeistas receptas ar neprieinamas klinikinis įrašas gali pakenkti net be atskleidimo.

Žemėlapį patikrinkite pagal architektūros diagramas, duomenų bazių schemas, integracijų nustatymus, saugyklų inventorius ir pokalbius su pagalbos ir veiklos darbuotojais. Aptikimo įrankiai gali nustatyti kandidatus, tačiau savininkas turi patvirtinti paskirtį ir tvarkymą. Jei komanda dar negali paaiškinti, kur yra jautri informacija, tęskite duomenų aptikimu.

Įgyvendinkite apsaugą kiekviename gyvavimo ciklo etape

Surinkimas: sumažinkite duomenų kiekį ir apribokite priėmimą

Rinkite tai, ko reikia patvirtintam tikslui. Pašalinkite nereikalingus formos laukus ir nepriimkite neribotų priedų, kai pakanka struktūrizuotos įvesties. Tikrinkite turinio dydį, tipą ir turinį; apsaugokite priėmimo galinius taškus nuo neleistinų pateikimų ir piktnaudžiavimo.

Asmens duomenų atveju susiekite rinkimo sąsają su dokumentuotu duomenų tvarkymo tikslu ir taikomu teisiniu pagrindu. Pagal BDAR sutikimas yra vienas iš galimų 6 straipsnio pagrindų, o ne visuotinė būtina sąlyga. Kai naudojamas sutikimas, taikomoji programa turi palaikyti atitinkamą sutikimo gyvavimo ciklą, o ne tik rodyti žymimąjį langelį.

Paslapčių ir jautraus turinio nedėkite į URL, klaidų pranešimus ir taikomosios programos telemetriją. Išbandykite klaidų kelius: atmestas pateikimas neturėtų palikti visos kopijos derinimo paslaugoje.

Naudojimas ir prieiga: autorizaciją užtikrinkite arti duomenų

Autentifikavimas nustato tapatybę; autorizacija nustato, prie kurių įrašų ir operacijų ta tapatybė gali turėti prieigą. Įgyvendinkite abu. Prisijungęs naudotojas neturėtų gauti prieigos prie kito kliento įrašų pakeitęs identifikatorių.

Taikykite mažiausių privilegijų principą, kai tinka, atskirkite administracines pareigas ir reikalaukite stipresnio autentifikavimo jautriai ar privilegijuotai prieigai. Tarnybinėms paskyroms suteikite siaurai apibrėžtas teises, o ne pakartotinai naudokite žmonių prisijungimo duomenis. Užtikrinkite, kad prisijungimo, perkėlimo ir išėjimo procesai apimtų taikomųjų programų vaidmenis, debesijos teises, API raktus ir tiekėjų prieigą.

Pagalbos tarnybos prieigai apibrėžkite patvirtinimo sąlygas, laiko ribas, leidžiamus veiksmus ir audito sekas. Prieigą peržiūrėkite pagal dabartinį verslo poreikį, o ne tik pagal tai, ar paskyra tebėra aktyvi. Įrodymai turėtų apimti autorizacijos testus, prieigos peržiūros sprendimus ir panaikintų teisių pavyzdžius.

Gamybiniai duomenys neturėtų tapti numatytaisiais testavimo duomenimis. Pirmenybę teikite sintetiniams duomenims. Jei realių duomenų išimtis pagrįsta, patvirtinkite jos apimtį, apribokite prieigą ir nustatykite galiojimo pabaigą. Pseudonimizavimas gali sumažinti atvirumą, tačiau pseudonimizuoti asmens duomenys lieka BDAR taikymo srityje, jei asmenų tapatybę galima vėl nustatyti naudojant papildomą informaciją.

Saugojimas ir perdavimas: apsaugokite duomenis ir jų raktus

Atskirkite saugomų duomenų šifravimą nuo perduodamų duomenų šifravimo. Saugyklų šifravimas apsaugo nuo tam tikrų praradimo ar prieigos scenarijų; perdavimo šifravimas apsaugo ryšio kanalus. Nė vienas neužkerta kelio autorizuotai taikomajai programai grąžinti įrašų netinkamam naudotojui.

Naudokite nusistovėjusias, prižiūrimas kriptografines realizacijas ir modernų autentifikuotą šifravimą. Sukonfigūruokite palaikomus perdavimo protokolus, tikrinkite sertifikatus ir pašalinkite pasenusias konfigūracijas. Nekurkite savo kriptografijos.

Raktų valdymas yra kontrolės priemonės dalis, o ne įgyvendinimo išnaša. Dokumentuokite, kas gali naudoti, administruoti, keisti, atšaukti ir atkurti raktus. KMS palaiko valdomas raktų operacijas; HSM gali suteikti aparatine įranga paremtą kriptografinės medžiagos apsaugą. Būdą pasirinkite pagal grėsmių modelį ir veiklos reikalavimus.

Kai įmanoma, atskirkite raktų administravimą nuo įprastos prieigos prie duomenų. Išbandykite, ar atšaukta prieiga iš tikrųjų neleidžia iššifruoti ir ar po teisėto infrastruktūros gedimo atkūrimas lieka įmanomas. Praradus vienintelį tinkamą naudoti raktą, nepažeistos atsarginės kopijos gali virsti neprieinamais duomenimis. Veiklos skirtumai aprašyti straipsnyje apie šifravimą ir raktų valdymą.

Perdavimams taip pat reikia gavėjų kontrolės. Kai tinka, naudokite patvirtintas paskirties vietas, apribotus API prisijungimo duomenis ir laiko atžvilgiu ribotą atsisiuntimo prieigą. Eksportus sekite kaip kopijas su atsakingais asmenimis ir galiojimo pabaigos taisyklėmis, o ne kaip įvykius, kuriais atsakomybė baigiasi.

Vientisumas ir prieinamumas: išbandykite veiklos teiginius

Vientisumą apsaugokite įvesties tikrinimu, duomenų bazių apribojimais, kontroliuojamais pakeitimais, suderinimu ir duomenims tinkamomis audito sekomis. Kontrolinė suma gali aptikti kai kuriuos pakeitimus; ji nenustato, kas turėjo teisę juos atlikti.

Atkūrimo tikslus apibrėžkite pagal verslo pasekmes. Atitinkamai pasirinkite atsarginių kopijų darymo dažnumą ir atkūrimo sprendimą. Apsaugokite atsargines kopijas nuo atsitiktinio ištrynimo ir kompromituotų administratorių, o prieigą prie jų, kai įmanoma, ribokite nepriklausomai nuo įprastos prieigos prie taikomosios programos.

Teiginys apie atkūrimą turėtų būti susietas su testu, o ne tik su atsarginių kopijų konfigūracija. Atkurkite į izoliuotą aplinką, patikrinkite įrašų išsamumą ir nuoseklumą, patikrinkite taikomosios programos priklausomybes ir išmatuokite faktinį atkūrimo našumą. Užfiksuokite nesėkmes ir taisomuosius darbus. Sėkmingo duomenų bazės atkūrimo nepakanka, jei trūksta reikalingų raktų, failų ar tapatybės paslaugų.

Saugojimas ir sunaikinimas: ištrynimą padarykite įvykdomą

Saugojimo terminus apibrėžkite pagal duomenų kategoriją ir tikslą su aiškiu sukėlėju: paskyros uždarymu, sutarties įvykdymu, įrašo įvykiu ar kita pagrįsta sąlyga. Susiekite politiką su įgyvendintomis taisyklėmis duomenų bazėse, objektų saugyklose, paieškos indeksuose, analitikos sistemose ir tiekėjų paslaugose.

Ištrynimui reikia pakartotinių bandymų tvarkymo ir suderinimo. Užduotis, pranešanti apie sėkmę, bet ignoruojanti nepavykusią užklausą tolesnei sistemai, neįrodo sunaikinimo. Palaikykite peržiūrėtas išimtis teisinio sulaikymo ar kito pagrįsto saugojimo atvejams, įskaitant atsakingą asmenį ir pabaigos sąlygą.

Atsarginėms kopijoms reikia dokumentuoto modelio. Paaiškinkite galiojimo laikotarpius, įprasto naudojimo apribojimus ir tai, kaip tvarkomi anksčiau ištrinti įrašai, jei atsarginė kopija atkuriama. Nežadėkite neatidėliotino ištrynimo visur, jei architektūra to negali užtikrinti. Saugus sunaikinimas taip pat apima eksportuotus failus, nebenaudojamus įrenginius ir bendradarbiavimo su tiekėju užbaigimą.

Debesijos patikinimą vertinkite kaip apibrėžtos apimties įrodymą

Debesijos paslaugos perskirsto atsakomybes; jos jų nepanaikina. Nustatykite, ką valdo teikėjas ir ką konfigūruoja jūsų komanda, įskaitant tapatybes, tinklo atvirumą, šifravimo nustatymus, taikomosios programos autorizaciją, registravimą žurnaluose, saugojimą ir atkūrimą.

Tiekėjo patikinimą vertinkite faktinei paslaugai. Patikrinkite ataskaitos apimtį, vertinimo laikotarpį, išimtis, kliento atsakomybes ir neišspręstas išvadas. Teikėjo sertifikatas neįrodo, kad jūsų saugyklos talpykla, taikomoji programa ar administratorių teisės sukonfigūruotos teisingai.

Vieta yra dar vienas apimties klausimas. Sudarykite pagrindinės saugyklos, replikų, avarinio atkūrimo, pagalbos tarnybos prieigos, subtvarkytojų ir telemetrijos paskirties vietų žemėlapį. Vien prieglobos pasirinktame regione nepakanka duomenų suverenumui ar atitikčiai BDAR įrodyti. Tarptautinių perdavimų vertinimai yra atskiri nuo BDAR 28 straipsnyje numatytų reikalavimų sutartims su duomenų tvarkytojais.

Prieš pradėdami bendradarbiavimą nustatykite sutartinius lūkesčius dėl incidentų, prieigos, subtvarkytojų, duomenų susigrąžinimo, ištrynimo ir paslaugos nutraukimo. Išbandykite, ar eksportuoti duomenys tinkami naudoti ir ar galima gauti tiekėjo ištrynimo įrodymų. Tiekėjas, negalintis palaikyti jums reikalingo gyvavimo ciklo, sukuria architektūrinį sprendimą, o ne vien pirkimų pastabą.

Taikykite sveikatos technologijų kontekstą nesuliedami atskirų prievolių

Sveikatos technologijos iliustruoja, kodėl duomenų kontekstas svarbus. Pagal BDAR 9 straipsnį sveikatos duomenys priskiriami specialiųjų kategorijų duomenims, be to, reikia ir 6 straipsnyje numatyto teisinio pagrindo. Dokumentuokite atitinkamą 9 straipsnio sąlygą, o ne manykite, kad kiekviena operacija su sveikatos duomenimis gali remtis tuo pačiu pagrindimu.

Įvertinkite, ar duomenų tvarkymas gali sukelti didelį pavojų ir todėl pagal 35 straipsnį reikalauja poveikio duomenų apsaugai vertinimo. Saugumo įrodymai turėtų atspindėti tikėtiną žalą: neteisingi įrašai, netinkama darbuotojų prieiga, atskleidimas per pranešimus ir neprieinamos paslaugos – visa tai gali būti svarbu.

Medicinos priemonių prievolės priklauso nuo produkto ir numatytosios paskirties. MDR ar IVDR vertinimas yra atskira kryptis nuo privatumo ir informacijos saugumo. Elektroninių sveikatos įrašų produktus ir antrinio naudojimo veiklą taip pat reikėtų įvertinti pagal taikomas Europos sveikatos duomenų erdvės nuostatas ir etapais įsigaliojančius reikalavimus. Nacionalinės sveikatos priežiūros ir išlaidų kompensavimo taisyklės gali nustatyti papildomų apribojimų.

Pardavimas ligoninei automatiškai nenustato kiekvieno tiekėjo tiesioginio statuso pagal NIS2. Teisinį taikymą dokumentuokite atskirai nuo ligoninės sutartinių saugumo reikalavimų. Klientų prašymai pateikti ISO sertifikatą, SOC 2 ar kitą patikinimą gali būti komerciškai svarbūs, nebūdami visuotiniais teisiniais reikalavimais.

Įrodymus kurkite aplink teiginius, tada stebėkite nukrypimus

Kiekvienai esminei kontrolės priemonei apibrėžkite teiginį, už įgyvendinimą atsakingą asmenį, apimtį, įrodymų šaltinį, testą, peržiūrėtoją ir peržiūros sukėlėją. Politikos, konfigūracijos ir veiksmingumo įrodymus laikykite atskirus.

Pakartotinai naudokite įrodymus, kai jie pagrindžia kelis reikalavimus, tačiau išsaugokite kiekvieno reikalavimo interpretaciją. Kontrolės priemonių susiejimas yra „daug su daug“; bendra prieigos peržiūra neįrodo kiekvienos teisinės pareigos vykdymo.

Stebėkite pokyčius, galinčius paneigti modelį: naujas integracijas, teisių pakeitimus, išjungtą audito registravimą, nepavykusias atsargines kopijas, ištrynimo klaidas ir naujas paskirties vietas. Įspėjimus nukreipkite atsakingiems asmenims su eskalavimo keliu. Periodiniai auditai turėtų atrinktinai tikrinti, ar šios patikros veikė, o ne tik tai, ar egzistuoja valdymo skydelis. Įsiskverbimo testavimas gali būti tinkamas atsižvelgiant į riziką ar sutarčių reikalavimus, tačiau nėra visuotinis privalomas testas pagal ISO 27001 ar SOC 2.

Į įrodymų planą įtraukite reagavimą į incidentus. Pagal BDAR duomenų tvarkytojai nepagrįstai nedelsdami praneša duomenų valdytojams. Duomenų valdytojai nepagrįstai nedelsdami ir, jei įmanoma, ne vėliau kaip per 72 valandas nuo tada, kai sužinojo, įvertina pranešimą priežiūros institucijai, išskyrus atvejus, kai pažeidimas neturėtų kelti pavojaus fizinių asmenų teisėms ir laisvėms. Dėl didelį pavojų keliančių pažeidimų taip pat gali tekti pranešti asmenims, atsižvelgiant į 34 straipsnio išimtis. Užfiksuokite sprendimo nepranešti motyvus, o kitas sutartines ar sektorines pranešimo pareigas vertinkite atskirai.

Pavyzdys: pagalbos tarnybos eksporto spragos pašalinimas

Tarkime, iliustracijos dėlei, sveikatos technologijų SaaS teikėjas tvarko klinikų vizitų ir simptomų įrašus. Jo pagrindinė duomenų bazė šifruojama, prieiga prie taikomosios programos ribojama nuomininko apimtimi, o atsarginės kopijos yra. Gyvavimo ciklo peržiūra atskleidžia, kad pagalbos tarnybos darbuotojai eksportuoja įrašus į skaičiuokles ir prideda jas prie užklausų.

Eksportas sukuria dvi papildomas saugyklas: vietinius įrenginius ir užklausų sistemos tiekėją. Duomenų bazės kontrolės priemonės automatiškai neapsaugo nė vienos iš jų. Komanda pirmiausia patvirtina, ar pagalbos tarnybos problemai diagnozuoti reikia visų įrašų, ar paskirties vieta patvirtinta ir kokie sutartiniai apribojimai taikomi.

Tada įprastus eksportus ji pakeičia diagnostiniais vaizdais su užtamsinta informacija. Išimtiniams eksportams reikia patvirtinimo, ribotos prieigos paskirties vietos, riboto laukų skaičiaus ir galiojimo pabaigos. Peržiūrimi tiekėjo prieigos ir saugojimo nustatymai; vietiniai atsisiuntimai ribojami organizacijos patvirtintomis galinių įrenginių kontrolės priemonėmis.

Įrodymų paketą sudaro atnaujintas srautų žemėlapis, eksporto teisių testai, peržiūrėta išimtis, tiekėjo konfigūracijos įrodymai ir ištrynimo rezultatai. Neigiamas testas patvirtina, kad įprastas pagalbos tarnybos vaidmuo negali eksportuoti kitos klinikos įrašų. Galiojimo pabaigos testas tikrina tiek taikomosios programos kopiją, tiek užklausos priedą.

Likusi spraga nurodoma aiškiai: istorinius priedus reikia ištirti ir, kai pagrįsta, sunaikinti. Atsakingas asmuo gauna šią užduotį su užbaigimo kriterijumi. Komanda neteigia, kad pasiekė gyvavimo ciklo atitiktį vien todėl, kad naujasis eksporto mygtukas yra saugesnis.

Pirmiausia padarykite peržiūrimą vieną jautrų srautą

Pradėkite nuo apibrėžto srauto ir parenkite penkis rezultatus: patikrintą duomenų žemėlapį, taikymo sprendimus, kontrolės priemonių savininkus, patikrintus įrodymus ir prioritetizuotą spragų registrą. Atvirumo ir atkūrimo trūkumus spręskite anksčiau nei kosmetinius dokumentacijos patobulinimus. Išimtims nustatykite tvirtintoją, pagrindimą, kompensacines priemones ir peržiūros datą.

Secani sumodeliuokite šį srautą palaikančias taikomąsias programas, sistemas, paslaugas ir išorės teikėjus. Susiekite įrodymus su reikalavimais, kontrolės priemonėmis ir sprendimais; trūkstamus įrodymus ar neaiškią atsakomybę paskirkite kaip užduotis. DI pasiūlymus tikrinkite pagal jų šaltinius ir išsaugokite žmonių patvirtinimus bei laiko žymas. Taip turtas, reikalavimai, rizikos ir įrodymai išlieka kontekste, o įrankis nepakeičia techninio testavimo ar teisinės analizės.

Praktinis kitas žingsnis – viena peržiūra nuo pradžios iki galo: pasirinkite jautrų įrašą, atsekite kiekvieną kopiją ir paklauskite, kas įrodo, kad jo surinkimas, prieiga, atkūrimas, saugojimas ir ištrynimas yra kontroliuojami.