Asmens duomenų šifravimo planas turi parodyti, ką šifruojate, nuo kokios grėsmės saugote ir kas gali duomenis iššifruoti. Įrašas „viskas šifruojama“ neatsako, ar administratorius gali skaityti duomenis, ar kopijos turi tą pačią apsaugą ir ar praradus raktą išliks galimybė atkurti paslaugą.
Pradėkite nuo sistemų žemėlapio. Tada atskirkite duomenis perduodant, duomenis saugykloje ir duomenis naudojant. TLS patikros lapas skirtas ryšiui, o šis planas apima platesnį šifravimo bei raktų gyvavimo ciklą.
Šifravimo sprendimo lentelė
| Objektas | Numatoma grėsmė | Priemonės apimtis | Liekanti rizika | Savininkas |
|---|---|---|---|---|
| Nešiojamojo kompiuterio diskas | Pamesto išjungto įrenginio duomenų nuskaitymas | Disko šifravimas ir kontroliuojamas atkūrimas | Prisijungęs užpuolikas gali pasiekti atvertus duomenis | Įrenginių administratorius |
| Duomenų bazė | Saugyklos laikmenos atskleidimas | Duomenų šifravimas saugykloje | Įgaliota programa vis tiek gali skaityti duomenis | Sistemos savininkas |
| Atsarginė kopija | Kopijos gavimas be leidimo | Kopijos šifravimas atskiru valdymu | Rakto praradimas sutrikdo atkūrimą | Kopijų operatorius |
| Eksportuojama byla | Neteisingas gavėjas ar nesaugus kanalas | Kontroliuojamas perdavimas ir prieigos ribojimas | Gavėjas gali atskleisti gautą turinį | Eksporto tvirtintojas |
Kiekvieną eilutę susiekite su faktine paslauga ir nustatymo įrodymu. Techninis produkto aprašas turi būti taikomas būtent naudojamai funkcijai ir planui. Vien platformos reklaminis teiginys neatskleidžia, kas valdo raktus ar kuriame etape turinys būna iššifruotas.
Raktų gyvavimo ciklas
Aprašykite rakto sukūrimą, naudojimą, saugojimą, prieigą, keitimą, atšaukimą ir sunaikinimą. Atskirai numatykite atkūrimą bei senesnių kopijų skaitymą. Jei naujas raktas pakeičia senąjį, reikia žinoti, ar dar liko duomenų, kuriems būtinas ankstesnis raktas.
Raktą ir juo apsaugotą eksportą siųsti tuo pačiu nepatikrintu kanalu dažnai reiškia bendrą atskleidimo riziką. Skirtingas katalogas tame pačiame plačiai prieinamame diske taip pat gali nesuteikti prasmingo atskyrimo. Prieigos sprendime įvertinkite, kas gali pasiekti abu elementus.
BDAR 32 straipsnis įvardija šifravimą kaip galimą riziką atitinkančią priemonę. Jis nenustato universalaus algoritmo visoms duomenų rūšims. NKSC kriptografijos inventorizacijos gairės padeda aprašyti naudojamą kriptografiją; konkretaus techninio sprendimo tinkamumą reikia tikrinti pagal aktualias specialistų rekomendacijas.
Šifravimas ir kitos priemonės
Šifravimas nepakeičia prieigos kontrolės. Programa, gavusi teisėtą prieigą prie rakto, gali atverti duomenis ir juos eksportuoti. Todėl ribokite privilegijas, registruokite jautrius veiksmus ir valdykite programines paslaptis. Autentifikavimo politika padeda kontroliuoti, kas gali pasinaudoti iššifravimo keliu.
Pseudonimizavimas yra kitoks sprendimas: tiesioginį identifikatorių pakeičia kodas, o susiejimo informacija saugoma atskirai. Duomenys dažnai išlieka asmens duomenimis. Nei pseudonimas, nei šifruotas failas savaime nesukuria anoniminio duomenų rinkinio.
Incidento vertinimas
Praradus šifruotą įrenginį nustatykite, ar apsauga buvo aktyvi, kokia buvo įrenginio būsena, ar raktas galėjo būti pasiektas ir kokie duomenys jame buvo. Šie faktai svarbūs rizikos vertinimui. Bendras teiginys „turime šifravimą“ nėra pakankamas sprendimui dėl pranešimo.
BDAR 34 straipsnio 3 dalies a punktas numato sąlygą, susijusią su priemonėmis, dėl kurių neturintiems leidimo duomenys tampa nesuprantami. Tai reikia vertinti konkrečiam pažeidimui; ši nuostata automatiškai nepanaikina visų kitų pažeidimo dokumentavimo ar institucijos informavimo pareigų. Naudokite pažeidimų procedūrą.
Atkūrimo bandymas
Iš pasirinktos kopijos saugioje aplinkoje atkurkite nedidelį leidžiamą duomenų rinkinį. Patikrinkite, ar pasiekiamas tinkamas raktas, ar teisės nesuteiktos per plačiai ir ar atkurtą rezultatą patvirtina sistemos savininkas. Bandymo metu nekurkite nekontroliuojamų produkcinių duomenų kopijų.
Protokole užrašykite rakto identifikatorių, tačiau ne patį slaptą raktą. Nurodykite bandymo rezultatą, trukmę ir priklausomybes. Šis įrodymas įtraukiamas į IT atkūrimo planą. Užbaigtame šifravimo plane turi būti matomos apsaugotos vietos, iššifravimo teisės ir atkūrimo galimybė.
Ką tiksliai reiškia šifravimas saugykloje
Duomenų saugyklos šifravimas gali apsaugoti nuo fizinės laikmenos nuskaitymo ar tam tikros neleistinos prieigos prie saugojimo infrastruktūros. Tačiau įprastai programa, turinti tinkamą prieigą, gauna iššifruotus duomenis. Todėl pasirinkdami priemonę aiškiai nurodykite, nuo kurio užpuoliko scenarijaus ji saugo ir kuriuos kelius reikia apsaugoti kitais būdais.
Pavyzdžiui, klientų sistemos administratorius gali neturėti tiesioginio priėjimo prie disko, bet turėti teisę eksportuoti visas lenteles per programą. Disko šifravimas šios rizikos nesprendžia. Reikia riboti eksporto teises, tvirtinti jautrius veiksmus ir stebėti naudojimą. Šifravimo planas turi remtis duomenų pasiekimo keliais, o ne vien pažymėtu konfigūracijos laukeliu.
Atskirai patikrinkite laikinus failus, paieškos indeksus, analizės ištraukas ir kopijas. Pagrindinė duomenų bazė gali būti apsaugota, o eksportas bendrame kataloge – likti be lygiavertės kontrolės. Į inventorių įtraukite šias vietas ir nustatykite, kas patvirtina jų apsaugą bei ištrynimą.
Kliento ir tiekėjo valdomi raktai
Debesijos paslaugos gali siūlyti skirtingus raktų valdymo modelius. Tiekėjo valdomas raktas ir kliento valdomas raktas skiriasi atsakomybių, prieigos, atkūrimo bei administravimo požiūriu. Tačiau vien etiketė „kliento raktas“ nepasako, ar tiekėjas bet kuriame paslaugos etape gali matyti iššifruotus duomenis.
Paprašykite aprašyti, kur raktas sukuriamas, kas gali suteikti teisę jį naudoti ir kaip registruojami administravimo veiksmai. Patikrinkite, kas įvyksta atšaukus raktą: ar paslauga sustoja iš karto, ar lieka talpyklos, ar dar galima skaityti senas kopijas. Šie klausimai svarbūs ir saugumui, ir paslaugos prieinamumui.
Kliento valdomas raktas gali suteikti daugiau kontrolės, tačiau kartu sukurti papildomą atsakomybę už jo prieinamumą ir teisių valdymą. Jei organizacija neturi žmonių ar procedūrų šiai atsakomybei, pasirinkimas gali didinti duomenų praradimo riziką. Sprendime palyginkite ne tik teorinę kontrolę, bet ir realią galimybę ją valdyti.
Hipotetinis šifruoto eksporto perdavimas
Organizacija turi perduoti ribotą klientų bylos dalį įgaliotam išoriniam specialistui. Pirmiausia patikrinamas gavėjas, teikimo pagrindas ir reikalinga apimtis. Tuomet pasirenkamas patvirtintas perdavimo būdas, kuris leidžia riboti prieigą ir, jei tinkama, jos trukmę. Pats šifravimas neatstoja sprendimo, ar gavėjas apskritai turi gauti duomenis.
Jei pasirenkamas šifruotas failas, nustatykite, kaip gavėjas gaus atvėrimo priemonę. Patikrinkite kontaktą per jau patikimą kanalą ir neįrašykite paslapties į tą patį laišką. Išsaugokite perdavimo faktą bei apimtį be nereikalingos papildomos turinio kopijos. Gavėjui paaiškinkite, kam skirta informacija ir kokie tolesnio naudojimo apribojimai taikomi.
Po perdavimo peržiūrėkite laikinas kopijas, darbo katalogus ir prieigos nuorodas. Jei failas lieka atvirame bendrinamame aplanke, pradinis saugus siuntimas nepašalina likusios rizikos. Perdavimo užduotis baigiama tada, kai sutvarkytas visas kelias nuo atrinkimo iki laikinos darbo medžiagos pašalinimo.
Raktų keitimas ir paslaugos tęstinumas
Rakto keitimo plane numatykite, kurie duomenys peršifruojami, kurios senos versijos išlieka ir kaip bus patikrintas skaitymas. Keitimas gali paveikti atsargines kopijas ar senesnes archyvines bylas. Prieš sunaikindami ankstesnį raktą įsitikinkite, kad nėra pagrįstai saugomų duomenų, kurie taptų negrįžtamai neprieinami.
Atskirai aprašykite kompromitavimo scenarijų. Įprastas planinis keitimas ir skubus rakto atšaukimas turi skirtingą poveikį veiklai. Reikia nustatyti paveiktą apimtį, naują apsaugos kelią ir galimą ankstesnių duomenų atskleidimą. Rakto pakeitimas nesuteikia pagrindo manyti, kad užpuolikas nebeskaito anksčiau gautų iššifruotų kopijų.
Ateities migracijų inventorius
Kriptografijos inventorius naudingas ir planuojant ilgalaikį perėjimą prie kitų techninių sprendimų. Užrašykite algoritmą, protokolą, biblioteką, duomenų jautrumo laikotarpį ir sistemos keitimo galimybes. Tai padeda nustatyti, kur migracija priklauso nuo tiekėjo, senos įrangos ar sunkiai pakeičiamo failo formato.
Neskubėkite įrašyti vienos universalios migravimo datos visiems duomenims. Vertinkite aktualias rekomendacijas, realias grėsmes ir sistemų palaikymą. Duomenys, kurie turi likti konfidencialūs daug metų, gali reikalauti kitokio planavimo negu trumpai naudojama operacinė informacija. Techninį sprendimą pagrįskite specialistų peržiūra ir išsaugokite naudoto šaltinio versiją.
Priėmimo klausimai vadovui
Prieš patvirtindamas planą vadovas turėtų gauti atsakymus, kurios duomenų vietos dar neapsaugotos, kas valdo iššifravimo prieigą ir ar bandytas atkūrimas. Aiškiai parodykite išimtis ir nepatikrintas tiekėjo prielaidas. Teiginys „šifravimas įjungtas“ neturėtų užgožti fakto, kad nežinomas rakto atkūrimo savininkas.
Užbaigtame sprendime nurodykite kitą peržiūros įvykį: naują duomenų srautą, tiekėjo pakeitimą, incidentą arba techninės rekomendacijos pasikeitimą. Kiekviena peržiūra turi patikrinti ir apsaugą nuo atskleidimo, ir galimybę teisėtai pasiekti reikalingus duomenis. Tik toks balansas leidžia šifravimą laikyti veikiančia saugumo priemone.
Neteisingai suprantami šifravimo įrodymai
Ryšio naršyklėje piktograma patvirtina tik dalį perdavimo konteksto ir neparodo, kaip gavusi duomenis juos tvarko programa. Disko šifravimo būsenos išrašas neįrodo, kad atskirai eksportuotos bylos apsaugotos tokiu pat būdu. Tiekėjo saugumo ataskaitoje nurodyta kontrolė gali apimti kitą paslaugos dalį negu ta, kuria naudojatės.
Todėl kiekvieną įrodymą susiekite su konkrečia inventoriaus eilute, grėsme ir tikrinamu teiginiu. Pažymėkite, kokią išvadą jis leidžia daryti ir kokios neleidžia. Jei dar nepatikrintas rakto atkūrimas ar administratoriaus prieiga, šie klausimai lieka atviri, net jeigu bendras šifravimo nustatymas įjungtas.
Šis įrodymų atskyrimas ypač naudingas audito metu: peržiūrėtojas gali sekti sprendimą nuo apsaugos poreikio iki faktiškai patikrinto rezultato, o organizacija aiškiai mato kitą reikalingą darbą.