Datu drošības atbilstība: aizsargājiet visu informācijas dzīves ciklu

Datu drošību ir vieglāk novērtēt, ja komanda var izsekot informācijai no vākšanas līdz dzēšanai. Attiecīgās kontroles ir atkarīgas no sensitivitātes, mērķa, lietotājiem un datu zaudēšanas vai ļaunprātīgas izmantošanas sekām. Ražošanas datubāze var būt labi aizsargāta, kamēr tie paši ieraksti paliek atklāti eksportētās izklājlapās, atbalsta pielikumos, analītikas plūsmās vai rezerves kopijās.

Tāpēc CTO datu drošības atbilstība ir inženierijas un pierādījumu problēma: noteikt, kuras prasības ir piemērojamas, pārvērst tās kontrolēs katrā datu plūsmā un pierādīt, ka šīs kontroles darbojas. Politikas apraksta paredzēto rīcību. Konfigurācijas, testi, žurnāli un pārskatīti izņēmumi parāda, vai sistēma patiešām tā rīkojas.

Nošķiriet drošības prasības no plašākiem datu pienākumiem

Datu drošības atbilstība attiecas uz aizsardzību pret nesankcionētu piekļuvi, izpaušanu, izmainīšanu, iznīcināšanu un pieejamības zudumu. Tā aptver personas informāciju, bet arī pirmkodu, finanšu ierakstus, intelektuālo īpašumu, piekļuves datus un citu sensitīvu biznesa informāciju.

Plašāka datu atbilstība ietver jautājumus, uz kuriem drošības kontroles vienas pašas nevar atbildēt: vai vākšana ir likumīga, kādi mērķi ir atļauti, kādi paziņojumi vai līgumi ir nepieciešami, kā personas īsteno savas tiesības un cik ilgi informāciju drīkst glabāt. Šifrēšana nepadara nepamatotu vākšanu likumīgu. Derīgs apstrādes mērķis nepadara nedrošu ieviešanu pieņemamu.

Turiet trīs prasību avotus atsevišķi:

• Tiesību akti un regulējums: pienākumi, ko nosaka jurisdikcija, apstrādes darbības, organizācijas loma un nozare.
• Standarti un garantijas ietvari: strukturētas pieejas drošības pārvaldībai vai neatkarīgam novērtējumam.
• Līgumi un iekšējās saistības: klientu noteikumi, piegādātāju līgumi, apstrādes politikas un pakalpojumu solījumi.

Dokumentējiet katras prasības avotu, tvērumu, atbildīgo īpašnieku un interpretāciju. Tad inženieri var ieviest kopīgus aizsardzības pasākumus, kļūdaini neuzskatot katru ietvaru par juridiski līdzvērtīgu.

Nosakiet piemērojamību pirms kontroļu izvēles

Noderīgs piemērojamības reģistrs izskaidro, kāpēc prasība ir piemērojama, nevis tikai to, ka kāds to pievienojis kontrolsarakstam.

Tie ir sākotnējie jautājumi, nevis pilnīgi juridiski testi. Piemēram, ar veselību saistīta programmatūra automātiski nav pakļauta HIPAA tikai tāpēc, ka tā apstrādā veselības informāciju. Maksājumu apstrādes nodošana ārpakalpojumā var samazināt PCI DSS tvērumu, taču tā automātiski nenovērš tirgotāja pienākumus.

VDAR 32. pants prasa riskam atbilstošu drošību, ņemot vērā tādus faktorus kā apstrādes raksturs, ieviešanas izmaksas un jaunākās tehnoloģijas. Tas min tādus pasākumus kā šifrēšana, noturība, atjaunošana un regulāra izvērtēšana; tas neuzliek universālu vispārēju šifrēšanas pienākumu.

ISO 27001 attiecas uz informācijas drošības pārvaldības sistēmu noteiktā tvērumā. Tā prasības ietver riska apstrādi, iekšējo auditu un vadības pārskatu. A pielikuma kontroles tiek izskatītas, balstoties uz riskā pamatotu piemērojamību, un lēmumi tiek dokumentēti Piemērojamības paziņojumā. Sertifikāciju veic neatkarīga sertifikācijas institūcija.

SOC 2 ir apliecinājuma ziņojums, nevis sertifikācija. Tā kritēriji attiecas uz drošību un, ja iekļauts tvērumā, pieejamību, apstrādes integritāti, konfidencialitāti un privātumu. Ne SOC 2 ziņojums, ne ISO sertifikāts neapliecina atbilstību VDAR.

Nozarei specifiskiem pienākumiem nepieciešams atsevišķs novērtējums. SOX attiecas uz finanšu pārskatiem un ar tiem saistītajām iekšējām kontrolēm attiecīgos uzņēmumos; CMMC attiecas uz noteiktām aizsardzības līgumu prasībām un informācijas vidēm. Eiropā NIS2 prasa analizēt nozari, lielumu, pakalpojumu un iekļaušanas noteikumus saskaņā ar nacionālo transpozīciju. DORA galvenokārt aptver noteiktas finanšu vienības, ar līgumiskiem pienākumiem IKT piegādātājiem un uzraudzības režīmu noteiktiem kritiskiem pakalpojumu sniedzējiem. Nepieņemiet, ka katram finanšu tehnoloģiju vai tehnoloģiju piegādātājam ir vienādi tiešie pienākumi.

Izveidojiet dzīves cikla karti, kas ietver sekundārās kopijas

Sāciet ar vienu svarīgu biznesa procesu, piemēram, pacientu reģistrāciju, algu aprēķinu, klientu atbalstu vai maksājumu saskaņošanu. Identificējiet tā datu īpašnieku un tehnisko īpašnieku, pēc tam izsekojiet informācijai cauri vākšanai, izmantošanai, kopīgošanai, glabāšanai, atjaunošanai un iznīcināšanai.

Katrai datu kopai dokumentējiet:

• Tās mērķi, sensitivitāti un piemērojamās apstrādes prasības.
• Avota sistēmas, glabāšanas vietas, saskarnes un saņēmējus.
• Cilvēkus lietotājus, servisa kontus, piegādātājus un priviliģētas piekļuves ceļus.
• Atvasinātās datu kopas, eksportus, kešatmiņas, testa kopijas, žurnālus un rezerves kopijas.
• Glabāšanas termiņu ierosinātājus, dzēšanas metodes un izņēmumus.

Klasifikācijai jānoved pie lēmumiem. Apzīmējums, piemēram, „ierobežotas pieejamības veselības dati”, ir noderīgs tikai tad, ja tas nosaka atļautos galamērķus, piekļuves noteikumus, žurnalēšanu, šifrēšanu un iznīcināšanu. Apvienojiet konfidencialitāti ar integritāti un pieejamību: izmainīta recepte vai nepieejams klīniskais ieraksts var radīt kaitējumu arī bez izpaušanas.

Validējiet karti, salīdzinot to ar arhitektūras diagrammām, datubāzu shēmām, integrāciju iestatījumiem, krātuvju inventāriem un intervijām ar atbalsta un darbības personālu. Atklāšanas rīki var identificēt kandidātus, taču īpašniekam jāapstiprina mērķis un apstrāde. Turpiniet ar datu atklāšanu, ja komanda vēl nevar paskaidrot, kur atrodas sensitīvā informācija.

Ieviesiet aizsardzību katrā dzīves cikla posmā

Vākšana: samaziniet datus un ierobežojiet ievadi

Vāciet to, ko prasa apstiprinātais mērķis. Noņemiet nevajadzīgus veidlapas laukus un nepieņemiet neierobežotus pielikumus, ja pietiek ar strukturētu ievadi. Validējiet datu apjomu, tipu un saturu; aizsargājiet ievades galapunktus pret nesankcionētiem iesniegumiem un ļaunprātīgu izmantošanu.

Personas datiem sasaistiet vākšanas saskarni ar dokumentēto apstrādes mērķi un piemērojamo tiesisko pamatu. Saskaņā ar VDAR piekrišana ir viens no iespējamiem 6. panta pamatiem, nevis universāls priekšnoteikums. Ja tiek izmantota piekrišana, lietotnei jāatbalsta attiecīgais piekrišanas dzīves cikls, nevis tikai jāattēlo izvēles rūtiņa.

Neļaujiet noslēpumiem un sensitīviem datiem nonākt URL, kļūdu ziņojumos un lietotnes telemetrijā. Pārbaudiet kļūmju ceļus: noraidītam iesniegumam nevajadzētu atstāt pilnu kopiju atkļūdošanas pakalpojumā.

Izmantošana un piekļuve: īstenojiet autorizāciju tuvu datiem

Autentifikācija nosaka identitāti; autorizācija nosaka, kuriem ierakstiem un darbībām šī identitāte drīkst piekļūt. Ieviesiet abas. Pieteicies lietotājs nedrīkst iegūt piekļuvi cita klienta ierakstiem, mainot identifikatoru.

Izmantojiet mazāko privilēģiju principu, ja nepieciešams, nodaliet administratīvos pienākumus un pieprasiet stiprāku autentifikāciju sensitīvai vai priviliģētai piekļuvei. Piešķiriet servisa kontiem šauri ierobežotas atļaujas, nevis atkārtoti izmantojiet cilvēku piekļuves datus. Nodrošiniet, ka jaunpienācēju, pārcelto un aizgājēju procesi aptver lietotņu lomas, mākoņa atļaujas, API pilnvaras un piegādātāju piekļuvi.

Atbalsta piekļuvei nosakiet apstiprināšanas nosacījumus, laika ierobežojumus, atļautās darbības un audita takas. Pārskatiet piekļuvi atbilstoši pašreizējai biznesa vajadzībai, nevis tikai pēc tā, vai konts joprojām ir aktīvs. Pierādījumiem jāietver autorizācijas testi, piekļuves pārskatīšanas lēmumi un atsaukto atļauju piemēri.

Ražošanas datiem nevajadzētu kļūt par noklusējuma testa datiem. Dodiet priekšroku sintētiskiem datiem. Ja izņēmums ar reāliem datiem ir pamatots, apstipriniet tā tvērumu, ierobežojiet piekļuvi un nosakiet derīguma termiņu. Pseidonimizācija var samazināt risku, taču pseidonimizēti personas dati paliek VDAR darbības jomā, ja personas var atkārtoti identificēt, izmantojot papildu informāciju.

Glabāšana un pārsūtīšana: aizsargājiet datus un to atslēgas

Nošķiriet šifrēšanu glabāšanā no šifrēšanas pārsūtīšanas laikā. Glabāšanas šifrēšana aizsargā noteiktos zaudēšanas vai piekļuves scenārijos; transporta šifrēšana aizsargā sakaru kanālus. Neviena no tām neliedz autorizētai lietotnei atgriezt ierakstus nepareizam lietotājam.

Izmantojiet pārbaudītas, uzturētas kriptogrāfijas implementācijas un mūsdienīgu autentificētu šifrēšanu. Konfigurējiet atbalstītos transporta protokolus, validējiet sertifikātus un noņemiet novecojušas konfigurācijas. Neizstrādājiet pašu kriptogrāfiju.

Atslēgu pārvaldība ir kontroles daļa, nevis ieviešanas zemsvītras piezīme. Dokumentējiet, kas drīkst atslēgas izmantot, administrēt, rotēt, atsaukt un atjaunot. KMS atbalsta pārvaldītas atslēgu darbības; HSM var nodrošināt aparatūrā balstītu kriptogrāfiskā materiāla aizsardzību. Izvēlieties pieeju atbilstoši draudu modelim un darbības prasībām.

Kur iespējams, nodaliet atslēgu administrēšanu no ikdienas piekļuves datiem. Pārbaudiet, vai atsaukta piekļuve patiešām novērš atšifrēšanu un vai atjaunošana joprojām ir iespējama pēc leģitīmas infrastruktūras kļūmes. Vienīgās izmantojamās atslēgas zaudēšana var pārvērst neskartas rezerves kopijas nepieejamos datos. Darbības atšķirības skatiet rakstā par šifrēšanu un atslēgu pārvaldību.

Pārsūtīšanai nepieciešamas arī saņēmēju kontroles. Izmantojiet apstiprinātus galamērķus, ierobežotus API piekļuves datus un, ja piemēroti, laikā ierobežotu lejupielādes piekļuvi. Sekojiet eksportiem kā kopijām ar īpašniekiem un derīguma termiņa noteikumiem, nevis kā notikumiem, kas izbeidz atbildību.

Integritāte un pieejamība: pārbaudiet darbības apgalvojumus

Aizsargājiet integritāti ar ievades validāciju, datubāzes ierobežojumiem, kontrolētām izmaiņām, saskaņošanu un datiem atbilstošām audita takām. Kontrolsumma var atklāt dažas izmaiņas; tā nenosaka, kurš bija pilnvarots tās veikt.

Nosakiet atjaunošanas mērķus, balstoties uz biznesa sekām. Atbilstoši izvēlieties rezerves kopēšanas biežumu un atjaunošanas dizainu. Aizsargājiet rezerves kopijas pret nejaušu dzēšanu un kompromitētiem administratoriem un, kur iespējams, ierobežojiet piekļuvi neatkarīgi no parastās lietotnes piekļuves.

Atjaunošanas apgalvojumam jābūt saistītam ar testu, nevis tikai ar rezerves kopēšanas konfigurāciju. Atjaunojiet izolētā vidē, pārbaudiet ierakstu pilnīgumu un konsekvenci, pārbaudiet lietotnes atkarības un izmēriet faktisko atjaunošanas veiktspēju. Dokumentējiet kļūmes un korektīvo darbu. Veiksmīga datubāzes atjaunošana nav pietiekama, ja trūkst nepieciešamo atslēgu, failu vai identitātes pakalpojumu.

Glabāšana un iznīcināšana: padariet dzēšanu izpildāmu

Nosakiet glabāšanas termiņus pēc datu kategorijas un mērķa ar skaidru ierosinātāju: konta slēgšanu, līguma izpildi, ieraksta notikumu vai citu pamatotu nosacījumu. Sasaistiet politiku ar ieviestiem noteikumiem datubāzēs, objektu krātuvēs, meklēšanas indeksos, analītikas sistēmās un piegādātāju pakalpojumos.

Dzēšanai nepieciešama atkārtošanas apstrāde un saskaņošana. Uzdevums, kas ziņo par panākumiem, ignorējot neizdevušos pakārtotu pieprasījumu, nepierāda iznīcināšanu. Uzturiet pārskatītus izņēmumus juridiskai aizturēšanai vai citai pamatotai glabāšanai, ieskaitot īpašumtiesības un beigu nosacījumu.

Rezerves kopijām nepieciešams dokumentēts modelis. Paskaidrojiet derīguma termiņus, parastās izmantošanas ierobežojumus un to, kā tiek apstrādāti iepriekš dzēsti ieraksti, ja rezerves kopija tiek atjaunota. Nesoliet tūlītēju dzēšanu visur, ja arhitektūra to nespēj nodrošināt. Droša iznīcināšana ietver arī eksportētus failus, ekspluatācijā vairs neizmantotas ierīces un piegādātāju atslēgšanu.

Uztveriet mākoņa garantiju kā tvērumā ierobežotus pierādījumus

Mākoņpakalpojumi pārdala pienākumus; tie tos nenovērš. Identificējiet, ko darbina pakalpojumu sniedzējs un ko konfigurē jūsu komanda, ieskaitot identitāti, tīkla pieejamību, šifrēšanas iestatījumus, lietotnes autorizāciju, žurnalēšanu, glabāšanu un atjaunošanu.

Izvērtējiet piegādātāja garantiju faktiskajam pakalpojumam. Pārbaudiet ziņojuma tvērumu, novērtējuma periodu, izņēmumus, klienta pienākumus un neatrisinātus konstatējumus. Pakalpojumu sniedzēja sertifikāts nepierāda, ka jūsu krātuves konteiners, lietotne vai administratoru atļaujas ir konfigurētas pareizi.

Atrašanās vieta ir vēl viens tvēruma jautājums. Kartējiet primāro glabāšanu, replikas, avārijas atjaunošanu, atbalsta piekļuvi, apakšapstrādātājus un telemetrijas galamērķus. Mitināšana izvēlētā reģionā vien neapliecina datu suverenitāti vai atbilstību VDAR. Starptautiskās datu nosūtīšanas novērtējumi ir nošķirti no apstrādātāja līguma prasībām VDAR 28. pantā.

Pirms sadarbības uzsākšanas nosakiet līgumiskās gaidas attiecībā uz incidentiem, piekļuvi, apakšapstrādātājiem, datu izgūšanu, dzēšanu un pakalpojuma izbeigšanu. Pārbaudiet, vai eksportētie dati ir izmantojami un vai ir iespējams iegūt piegādātāja dzēšanas pierādījumus. Piegādātājs, kas nespēj atbalstīt jums nepieciešamo dzīves ciklu, rada arhitektūras lēmumu, nevis tikai iepirkuma piezīmi.

Piemērojiet veselības tehnoloģiju kontekstu, nesapludinot atsevišķus pienākumus

Veselības tehnoloģijas ilustrē, kāpēc datu konteksts ir svarīgs. Veselības datiem saskaņā ar VDAR 9. pantu tiek piemērots īpašo kategoriju režīms, līdztekus nepieciešamībai pēc 6. panta tiesiskā pamata. Dokumentējiet attiecīgo 9. panta nosacījumu, nevis pieņemiet, ka katra darbība ar veselības datiem var balstīties uz vienu un to pašu pamatojumu.

Novērtējiet, vai apstrāde varētu radīt augstu risku un tādēļ prasīt novērtējumu par ietekmi uz datu aizsardzību saskaņā ar 35. pantu. Drošības pierādījumiem jāatspoguļo iespējamais kaitējums: nepareizi ieraksti, nepiemērota personāla piekļuve, izpaušana ar paziņojumu starpniecību un nepieejami pakalpojumi var būt būtiski.

Medicīnisko ierīču pienākumi ir atkarīgi no produkta un paredzētā nolūka. MDR vai IVDR novērtējums ir atsevišķs virziens, kas nošķirts no privātuma un informācijas drošības. Elektronisko veselības karšu produktiem un sekundārās izmantošanas darbībām arī nepieciešams novērtējums attiecībā pret piemērojamajiem Eiropas veselības datu telpas noteikumiem un pakāpeniski ieviešamām prasībām. Nacionālie veselības aprūpes un kompensāciju noteikumi var radīt papildu ierobežojumus.

Pārdošana slimnīcai automātiski nenosaka katra piegādātāja tiešo NIS2 statusu. Dokumentējiet juridisko piemērojamību atsevišķi no slimnīcas līgumiskajām drošības prasībām. Klientu pieprasījumi pēc ISO sertifikācijas, SOC 2 vai citas garantijas var būt komerciāli svarīgi, lai gan tie nav universālas juridiskas prasības.

Veidojiet pierādījumus ap apgalvojumiem, pēc tam uzraugiet novirzes

Katrai būtiskai kontrolei definējiet apgalvojumu, ieviešanas īpašnieku, tvērumu, pierādījumu avotu, testu, pārskatītāju un pārskatīšanas ierosinātāju. Turiet politikas, konfigurācijas un efektivitātes pierādījumus atsevišķi.

Izmantojiet pierādījumus atkārtoti, ja tie atbalsta vairākas prasības, taču saglabājiet katras prasības interpretāciju. Kontroļu sasaiste ir daudzi-pret-daudziem; kopīga piekļuves pārskatīšana neapliecina katru juridisko pienākumu.

Uzraugiet izmaiņas, kas var padarīt modeli nederīgu: jaunas integrācijas, atļauju izmaiņas, atspējotu audita žurnalēšanu, neizdevušās rezerves kopijas, dzēšanas kļūdas un jaunus galamērķus. Novirziet brīdinājumus īpašniekiem ar eskalācijas ceļu. Periodiskajos auditos jāpārbauda izlase par to, vai šīs pārbaudes darbojās, nevis tikai tas, vai pastāv informācijas panelis. Ielaušanās testēšana var būt piemērota atbilstoši riskam vai līguma prasībām, taču tā nav universāls obligāts tests saskaņā ar ISO 27001 vai SOC 2.

Iekļaujiet pierādījumu plānā reaģēšanu uz incidentiem. Saskaņā ar VDAR apstrādātāji bez nepamatotas kavēšanās paziņo pārziņiem. Pārziņi bez nepamatotas kavēšanās un, ja iespējams, 72 stundu laikā pēc tam, kad tiem kļuvis zināms, izvērtē paziņošanu uzraudzības iestādei, ja vien nav maz ticams, ka pārkāpums radīs risku personu tiesībām un brīvībām. Augsta riska pārkāpumi var prasīt arī paziņošanu personām, ievērojot 34. panta izņēmumus. Dokumentējiet nepaziņošanas pamatojumu un atsevišķi novērtējiet citus līgumiskos vai nozares ziņošanas pienākumus.

Piemērs: atbalsta eksporta trūkuma novēršana

Pieņemsim, ilustrācijas nolūkos, ka veselības tehnoloģiju SaaS pakalpojumu sniedzējs apstrādā klīniku vizīšu un simptomu ierakstus. Tā primārā datubāze ir šifrēta, lietotnes piekļuve ir ierobežota pa nomniekiem, un rezerves kopijas pastāv. Dzīves cikla pārskatā atklājas, ka atbalsta personāls eksportē ierakstus izklājlapās un pievieno tās pieteikumiem.

Eksports rada divas papildu krātuves: lokālās ierīces un pieteikumu sistēmas piegādātāju. Datubāzes kontroles automātiski neaizsargā nevienu no tām. Komanda vispirms noskaidro, vai atbalsta problēmas diagnosticēšanai nepieciešami pilni ieraksti, vai galamērķis ir apstiprināts un kuri līgumiskie ierobežojumi ir piemērojami.

Pēc tam tā aizstāj ikdienas eksportus ar rediģētiem diagnostikas skatiem. Izņēmuma eksportiem nepieciešams apstiprinājums, ierobežots galamērķis, ierobežoti lauki un derīguma termiņš. Tiek pārskatīti piegādātāja piekļuves un glabāšanas iestatījumi; lokālās lejupielādes tiek ierobežotas ar organizācijas apstiprinātajām galiekārtu kontrolēm.

Pierādījumu paketē ietilpst atjaunināta plūsmas karte, eksporta atļauju testi, pārskatīts izņēmums, piegādātāja konfigurācijas pierādījumi un dzēšanas rezultāti. Negatīvs tests apstiprina, ka parasta atbalsta loma nevar eksportēt citas klīnikas ierakstus. Derīguma termiņa tests pārbauda gan lietotnes kopiju, gan pieteikuma pielikumu.

Atlikušais trūkums ir skaidri norādīts: vēsturiskie pielikumi ir jāizmeklē un, ja pamatoti, jāiznīcina. Īpašnieks saņem šo uzdevumu ar izpildes kritēriju. Komanda neapgalvo dzīves cikla atbilstību tikai tāpēc, ka jaunā eksporta poga ir drošāka.

Vispirms padariet pārskatāmu vienu sensitīvu plūsmu

Sāciet ar ierobežotu plūsmu un sagatavojiet piecus rezultātus: pārbaudītu datu karti, piemērojamības lēmumus, kontroļu īpašniekus, pārbaudītus pierādījumus un prioritizētu trūkumu reģistru. Novērsiet riska iedarbības un atjaunošanas kļūmes pirms kosmētiskiem dokumentācijas uzlabojumiem. Piešķiriet izņēmumiem apstiprinātāju, pamatojumu, kompensējošus pasākumus un pārskatīšanas datumu.

Secani modelējiet lietotnes, sistēmas, pakalpojumus un ārējos pakalpojumu sniedzējus, kas atbalsta šo plūsmu. Savienojiet pierādījumus ar prasībām, kontrolēm un lēmumiem; trūkstošus pierādījumus vai neskaidras īpašumtiesības piešķiriet kā uzdevumus. Pārskatiet MI atbalstītos ieteikumus, salīdzinot tos ar avotiem, un saglabājiet cilvēku apstiprinājumus un laika zīmogus. Tas uztur aktīvus, prasības, riskus un pierādījumus kontekstā, neaizstājot tehnisko testēšanu vai juridisko analīzi ar rīku.

Praktiskais nākamais solis ir viens pilns pārskats no sākuma līdz beigām: izvēlieties sensitīvu ierakstu, izsekojiet katrai kopijai un jautājiet, kas pierāda, ka tā vākšana, piekļuve, atjaunošana, glabāšana un dzēšana ir kontrolēta.