Šifravimas ir raktų valdymas: patikrinkite apsaugos grandinę

Šifravimas apsaugo informaciją esant tam tikroms prielaidoms. Naudingas įgyvendinimas paaiškina, kurie duomenys apsaugoti, nuo kokios prieigos ir kaip raktai lieka kontroliuojami per visą jų gyvavimo ciklą. Nustatymas „šifravimas įjungtas“ atsako tik į nedidelę šio klausimo dalį.

Technologijų vadovui inžinerinis uždavinys yra patikrinti apsaugos grandinę: kur atsiranda atviras tekstas, kur jis keliauja, kur saugomas šifruotas tekstas, kas gali prašyti iššifravimo ir kas nutinka gedimo ar atkūrimo metu. Ši grandinė apima programas, tapatybes, debesijos paslaugas, administratorius, atsargines kopijas ir veiklos procedūras.

Toliau pateiktos praktinės rekomendacijos siūlo būdą šiai grandinei suprojektuoti ir peržiūrėti. Pradėkite nuo vienos jautrių duomenų saugyklos, tada tą patį metodą pritaikykite nuo jos priklausančioms sistemoms ir antrinėms kopijoms.

Prieš rinkdamiesi technologiją, apibrėžkite apsaugos tikslą

Pradėkite nuo grėsmės aprašymo, o ne nuo algoritmo. „Apsaugoti klientų įrašus“ yra per plati formuluotė, kad galėtų vadovauti įgyvendinimui. „Neleisti asmeniui, turinčiam pavogtą atsarginę kopiją, perskaityti klientų įrašų be atskirai kontroliuojamų raktų“ nurodo turtą, užpuoliko galimybes ir apsaugos ribą.

Skirtingoms grėsmėms reikia skirtingų kontrolės priemonių. Disko šifravimas gali apsaugoti išjungtą pavogtą nešiojamąjį kompiuterį, tačiau autentifikuotas naudotojas ar kenkėjiškas procesas vis tiek gali skaityti failus, kol diskas atrakintas. Duomenų bazės šifravimas gali apsaugoti laikmenas, kartu leisdamas duomenų bazės užklausoms grąžinti atvirą tekstą. Programos lygmens šifravimas gali apriboti tai, ką mato duomenų bazių administratoriai, tačiau gali neapsaugoti nuo kompromituotos programos, turinčios leidimą iššifruoti.

Naudokite trumpą duomenų srautų inventorių, kad šie skirtumai būtų aiškūs. Įtraukite gamybinius įrašus, įkeltus dokumentus, podėlius, eiles, analitikos ištraukas, žurnalus, laikinuosius failus, momentines kopijas ir atsargines kopijas. Duomenų aptikimas turėtų nustatyti kopijas, kurios išeina už pagrindinės saugojimo architektūros ribų, o ne tik architektūros diagramoje pavaizduotas sistemas.

Kiekvienam svarbiam srautui užfiksuokite:

• Duomenų kategoriją ir jos konfidencialumo poreikius.
• Šaltinį, paskirties vietą, tarpines paslaugas ir atviro teksto ribas.
• Užpuoliką ar neįgaliotą vaidmenį, kurį šifravimas turi suvaržyti.
• Tapatybę, kuriai leidžiama iššifruoti, ir priežastį, kodėl jai reikia šio leidimo.
• Prieinamumo, saugojimo ir atkūrimo reikalavimus.
• Už įgyvendinimą atsakingą asmenį ir už įrodymus atsakingą peržiūrėtoją.

Grėsmių modeliavimo metodas padeda patikrinti, ar pasirinkta riba atitinka grėsmę. Jei užpuolikas gali perimti programos tapatybę, vien skaidrus saugyklos šifravimas neužkirs kelio prieigai per tą programą.

Rezultatas yra apsaugos žemėlapis: duomenų srautų diagrama su aiškiomis prielaidomis ir išimtimis. Jis tampa atskaitos tašku konfigūracijos patikroms, autorizacijos testams ir atkūrimo pratyboms.

Supraskite, ką iš tikrųjų suteikia kriptografiniai komponentai

Šifravimas paverčia atvirą tekstą šifruotu tekstu naudojant kriptografinį algoritmą ir raktą. Jo konfidencialumas priklauso nuo konstrukcijos, įgyvendinimo, rakto slaptumo ir veikimo aplinkos. Stiprus algoritmas negali kompensuoti rakto, įkelto į išeitinio kodo saugyklą, ar programos galinio taško, grąžinančio kito kliento įrašus.

Simetrinė ir asimetrinė kriptografija atlieka skirtingas užduotis

Simetrinis šifravimas šifravimui ir iššifravimui naudoja bendrą slaptą raktą. Dėl efektyvumo jis dažnai naudojamas dideliems duomenų kiekiams. AES palaiko 128, 192 ir 256 bitų raktus, tačiau vien rakto dydžio etiketė neapibūdina saugaus įgyvendinimo: svarbūs ir režimas, nonce tvarkymas, autentifikavimas bei bibliotekos elgsena.

Asimetrinė kriptografija naudoja susijusius viešąjį ir privatųjį raktus. Priklausomai nuo algoritmo ir protokolo, ji palaiko šifravimą, parašus ar raktų suderinimą. RSA ir elipsinių kreivių konstrukcijos turi skirtingas galimybes ir parametrus; tai nėra tarpusavyje keičiamos etiketės. Asimetrinė kriptografija savaime nėra „saugesnė“ už simetrinį šifravimą.

Šiuolaikinės sistemos dažnai jas derina. Saugus perdavimo protokolas gali autentifikuoti kitą šalį ir nustatyti bendras paslaptis, o tada srautui apsaugoti naudoti simetrinį šifravimą. Dideli failai paprastai šifruojami simetriniais duomenų raktais, o ne visas failas tiesiogiai apdorojamas asimetriniu algoritmu.

Konfidencialumas nėra tas pats, kas vientisumas ar autentiškumas

Autentifikuotas šifravimas, pavyzdžiui, teisingai naudojamas AES-GCM, apsaugo konfidencialumą ir aptinka neleistinus apsaugoto šifruoto teksto bei susijusių duomenų pakeitimus. Pakartotinai naudojant tą patį nonce su tuo pačiu raktu, ši apsauga gali būti susilpninta. Pirmenybę teikite prižiūrimoms bibliotekoms ir gerai palaikomiems formatams, kurie saugiai įgyvendina šiuos reikalavimus; nekurkite savo šifro, režimo ar raktų apsikeitimo protokolo.

Maišos funkcija sukuria santrauką, o ne atkuriamą šifruotą tekstą. Įprasta maišos reikšmė neįrodo, kas sukūrė pranešimą. Slaptažodžiams saugoti reikia specialiai tam skirto slaptažodžių maišos algoritmo, o ne grįžtamojo šifravimo ar vien greitos bendrosios paskirties santraukos.

Pranešimo autentiškumo kodas naudoja paslaptį vientisumui ir autentiškumui patikrinti tarp šalių, kurios dalijasi ta paslaptimi. Skaitmeniniai parašai naudoja privatųjį pasirašymo raktą ir viešąjį patikros raktą; jie nepadaro pasirašyto turinio konfidencialaus.

Šie skirtumai svarbūs peržiūros metu. Klauskite, kokia savybė reikalinga ir koks mechanizmas ją suteikia, o ne priimkite „kriptografiją“ kaip vieną neišskaidytą kontrolės priemonę.

Patikrinkite kiekvieną saugojimo lygmenį ir kiekvieną antrinę kopiją

Šifravimas saugojimo metu apima saugomą informaciją, įskaitant duomenis, kuriuos aktyviai naudoja veikianti paslauga. Ši sąvoka nereiškia vien archyvuotų ar neaktyvių duomenų.

Skirtingi lygmenys apsaugo nuo skirtingų prieigos kelių:

Patikrinkite faktinę išteklių konfigūraciją, o ne vien paskyros numatytąjį nustatymą. Numatytasis nustatymas gali būti taikomas tik naujai sukurtoms saugykloms. Esami objektai, importuoti tomai, replikos ar istorinės momentinės kopijos gali turėti kitokius nustatymus.

Duomenų bazėse patikrinkite operacijų žurnalus, laikinąją saugyklą, replikas, eksportus ir administracines iškeltinių kopijų procedūras. Objektų saugyklose patikrinkite įkėlimus, kopijas, replikavimo paskirties vietas, versijuotus objektus ir atsisiuntimo kelius. Galiniuose įrenginiuose patikrinkite atkūrimo raktų tvarkymą ir tai, ar apimamos keičiamosios laikmenos.

Programos lygmens šifravimui reikia atskiro projektavimo sprendimo. Jis gali sumažinti poveikį duomenų bazių operatoriams arba susiaurinti, kurie darbo krūviai gali iššifruoti pasirinktus laukus. Jis taip pat gali apsunkinti indeksavimą, paiešką, analitiką ir palaikymo darbo eigas. Dokumentuokite, kur iššifruotos reikšmės patenka į atmintį, žurnalus, klaidų ataskaitas ar eksportus.

Nelaikykite šifravimo autorizacijos pakaitalu. Programa gali teisingai iššifruoti įrašą ir vis tiek jį atskleisti netinkamam nuomininkui. Nuomininkų izoliaciją, prieigos patikras ir privilegijuotos prieigos kontrolės priemones įtraukite į tą pačią peržiūrą.

Patikrinkite perdavimą nuo pirmojo siuntėjo iki galutinio gavėjo

Perdavimo šifravimas apsaugo duomenis, judančius tarp galinių taškų. Naudingas klausimas yra ne „Ar naudojame HTTPS?“, o „Kurie ryšiai apsaugoti ir kurios tapatybės autentifikuojamos?“

Aprašykite ryšius tarp naršyklės ir kraštinio mazgo, kraštinio mazgo ir programos, tarp paslaugų, tarp programos ir duomenų bazės, replikavimo, atsarginių kopijų perdavimo, administracinės prieigos ir eksporto trečiosioms šalims. TLS nutraukimas apkrovos balansavimo įrenginyje sukuria ribą: kitam etapui reikia atskiro apsaugos sprendimo. Privatus tinklas automatiškai nepašalina perėmimo ar šoninio judėjimo rizikų.

Kaip praktinį pagrindą rinkitės palaikomas šiuolaikines TLS konfigūracijas ir prižiūrimas klientų bibliotekas. TLS 1.3 yra stiprus numatytasis pasirinkimas, kur jis palaikomas; tinkamai sukonfigūruoto TLS 1.2 gali tekti išlaikyti dėl suderinamumo. Pasenęs SSL nėra tinkamas šiuolaikinis saugumo pasirinkimas.

Sertifikatų patikra yra apsaugos dalis. Patikrinkite serverio vardo patikrą, patikimų sertifikatų saugyklas, galiojimo pabaigos stebėseną, sertifikatų atnaujinimą ir tai, ar gamybinėje aplinkoje nėra nustatymų, išjungiančių patikrą. Šifravimas į neautentifikuotą galinį tašką gali apsaugoti srautą nuo pasyvaus stebėjimo, bet vis tiek siųsti jį netinkamai šaliai.

Abipusis TLS gali autentifikuoti abu ryšio galus, tačiau jis nepakeičia programos autorizacijos. Sertifikatų išdavimas, darbo krūvių tapatybės, atnaujinimas ir atšaukimas tampa veiklos priklausomybėmis, kurioms reikia atsakingų asmenų ir testų.

Atskirkite perdavimo šifravimą nuo ištisinio šifravimo. Paslauga, kuri nutraukia TLS ir apdoroja atvirą tekstą, neužtikrina konfidencialumo nuo savęs pačios. Ištisinio šifravimo sprendimai iššifravimą palieka tik paskirtiems galiniams taškams; jie kelia atskirų klausimų dėl įrenginių registravimo, gavėjų patikros, prieigos iš kelių įrenginių ir atkūrimo.

Įrodymai turėtų apimti konfigūraciją ir ryšių testus. Testuokite, ar atmetami netinkami sertifikatai ir draudžiamos protokolo versijos, o ne tik vieną sėkmingą šifruotą ryšį.

Valdykite raktus kaip turtą su gyvavimo ciklu

Raktus reikia sukurti, saugoti, leisti naudoti, keisti, atšaukti, saugoti ir sunaikinti. Kiekvienam etapui turėtų būti atsakingas asmuo ir apibrėžta procedūra.

Raktus kurkite ir registruokite apgalvotai

Raktus kurkite naudodami prižiūrimas kriptografines priemones su tinkamu atsitiktinumu. Gamybinių šifravimo raktų neišveskite iš įsimintinų slaptažodžių, identifikatorių, laiko žymų ar įprastų programų atsitiktinių skaičių funkcijų.

Tvarkykite raktų inventorių, kuriame būtų nurodyta paskirtis, atsakingas asmuo, aplinka, apsaugotos sistemos, algoritmas, rakto identifikatorius, sukūrimo data, būsena ir atkūrimo priklausomybės. Fiksuokite metaduomenis, o ne slaptą rakto medžiagą. Atskirkite šifravimo raktus, pasirašymo raktus, TLS privačiuosius raktus ir API prisijungimo duomenis, nes jų atskleidimo ir pakeitimo procedūros skiriasi.

Atskirkite gamybinę aplinką nuo kūrimo ir testavimo. Bendro rakto naudojimas keliose aplinkose padidina mažesnio patikimumo aplinkos poveikį ir apsunkina naudojimo žurnalų interpretavimą.

Atskirkite raktų kontrolę nuo prieigos prie duomenų

Raktų valdymo paslauga (KMS) paprastai teikia valdomas raktų operacijas, prieigos politikas, versijų valdymą ir naudojimo įrašus. Aparatinis saugumo modulis (HSM) suteikia aparatine įranga pagrįstą ribą kriptografinėms operacijoms ir raktų apsaugai. Paslaugos gali derinti šias funkcijas, tačiau produktų pavadinimai nenustato tikslios saugumo ribos.

Nustatykite, ar raktus galima eksportuoti, kurios operacijos vyksta ribos viduje, kas administruoja politikas ir kaip veikia atkūrimas. Valdomas raktų paslaugas ar aparatinę apsaugą rinkitės pagal riziką ir veiklos reikalavimus, o ne laikykite specialią aparatinę įrangą visuotinai būtina. HSM pirmiausia apsaugo raktus ir kriptografines operacijas; jie nėra bendrosios paskirties saugyklos visiems šifruotiems verslo duomenims.

Vokinis šifravimas yra dažnas modelis. Duomenų šifravimo raktas šifruoja turinį, o raktų šifravimo raktas apsaugo tą duomenų raktą. Užšifruotas duomenų raktas gali būti saugomas kartu su šifruotu tekstu. Jo saugumas priklauso nuo to, ar galimybė jį išvynioti kontroliuojama atskirai, o ne nuo to, ar kiekvienas užšifruotas raktas paslėptas kitoje vietoje.

Iššifravimą ribokite darbo krūviais, kuriems jo reikia. Kur įmanoma, atskirkite raktų administravimą nuo raktų naudojimo ir saugyklų administravimo. Patikrinkite, ar administratorius, kuris šiuo metu negali iššifruoti, gali pats sau suteikti tokį leidimą. Avarinė prieiga turėtų turėti aiškų patvirtinimą, ribotą trukmę ir peržiūros seką.

Raktų keitimą laikykite pakeitimų procesu, o ne varnele

Kriptografinius laikotarpius nustatykite pagal duomenų jautrumą, poveikį, algoritmo apribojimus, naudojimo apimtį ir taikomus reikalavimus. Raktų keitimas taip pat tinkamas po įtariamo kompromitavimo ar reikšmingo pasitikėjimo pokyčio.

Išsiaiškinkite, ką „raktų keitimas“ reiškia pasirinktoje paslaugoje. Naujos rakto versijos sukūrimas būsimam šifravimui gali palikti istorinius duomenis priklausomus nuo senesnių versijų. Duomenų raktų pervyniojimas nauju raktų šifravimo raktu skiriasi nuo pagrindinių duomenų iššifravimo ir pakartotinio šifravimo. Nė vienos iš šių operacijų nereikėtų numanyti vien iš automatinio raktų keitimo nustatymo.

Raktų keitimo plane turėtų būti nurodytos paveiktos programos, saugomi raktų identifikatoriai, istorinės versijos, laipsniškas diegimas, gedimų stebėsena, atšaukimo sąlygos ir galutinis išėmimas iš naudojimo. Prieš panaikindami senąją prieigą, testuokite skirtingų versijų skaitymą ir ilgai trunkančius darbus.

Atskirkite atšaukimą nuo sunaikinimo

Atšaukimas panaikina leidimą arba išjungia būsimą rakto naudojimą. Jis neištrina jau gauto atviro teksto, nepanaikina kiekvieno podėlyje esančio duomenų rakto ir nepašalina eksportuotos paslapties.

Sunaikinimas gali padaryti saugomą šifruotą tekstą neatkuriamą, bet tik tada, kai išsprendžiamos visos tinkamos naudoti kopijos ir atkūrimo keliai. Atsižvelkite į replikas, deponavimą, eksportuotą medžiagą, atsargines kopijas ir bendrų raktų priklausomybes. Jei nesusiję įrašai naudoja tą patį raktą, jo sunaikinimas gali sunaikinti ir prieigą prie duomenų, kurie turi likti prieinami.

Saugojimo ir ištrynimo projektavimą laikykite susietą. Neribotas raktų saugojimas gali pakenkti ištrynimo tikslui; per ankstyvas sunaikinimas gali sukelti prieinamumo incidentą.

Debesijos raktų modelius vertinkite pagal faktinę kontrolės ribą

Debesijos šifravimas gali sumažinti įgyvendinimo darbą, tačiau paslaugų teikėjo numatytieji nustatymai nenulemia jūsų grėsmių modelio. Vertinkite paslaugą, raktų politiką, administracinę prieigą, regioną, atkūrimo modelį ir pagrindžiančius įrodymus kartu.

Paslaugų teikėjo valdomi raktai kai kurioms rizikoms gali tikti, sukeldami palyginti mažą veiklos naštą. Kliento valdomi raktai gali suteikti aiškesnę politikos kontrolę, nuosavybę ir gyvavimo ciklo sprendimus. Išorėje laikomi raktai gali sukurti kitokią pasitikėjimo ribą, kartu įvesdami priklausomybę nuo išorinio prieinamumo ir ryšio.

Tokios sąvokos kaip „bring your own key“, „bring your own encryption“ ir „encryption as a service“ nėra lygiavertės architektūrinės garantijos. Rakto importavimas į paslaugų teikėjo paslaugą nebūtinai reiškia, kad paslaugų teikėjas niekada negali iššifruoti. Kliento pusės šifravimo diegimas pakeičia atviro teksto ribą, tačiau gali apsunkinti programos funkcijas ir atkūrimą.

Paklauskite galimo paslaugų teikėjo:

• Ar galime nustatyti raktą, naudojamą kiekvienam atitinkamam saugojimo ištekliui ir atsarginei kopijai?
• Kas gali keisti raktų politikas ir kaip šie pakeitimai registruojami?
• Kas nutinka, kai raktas išjungiamas ar raktų paslauga nepasiekiama?
• Kaip eksportas, replikavimas, migracija ir paskyros uždarymas veikia apsaugą?
• Kokie naudojimo įvykiai prieinami ir kokia veikla lieka už jų matomumo ribų?

Našumą vertinkite naudodami reprezentatyvius darbo krūvius: pralaidumą, delsą, raktų paslaugos kvotas, podėlio elgseną ir gedimų būdus. Paslauga, veikianti nedidelėje demonstracijoje, gali neveikti masinio atkūrimo metu. Duomenų vieta ir kliento raktų nuosavybė yra naudingi projektavimo duomenys, o ne suverenumo ar atitikties reguliavimo reikalavimams įrodymas.

Sprendimą rinkitės per veiklos bandymą

Kandidatus lyginkite pagal apsaugos žemėlapį, o ne pagal algoritmų pavadinimų sąrašą. Įtraukite bibliotekų priežiūrą, palaikomas platformas, administracinį atskyrimą, įrodymų prieinamumą, migracijos galimybes ir komandos gebėjimą valdyti paslaugą. Jei sutartis reikalauja patvirtinto kriptografinio modulio, nustatykite atitinkamą modulį, versiją, veikimo aplinką ir patvirtinimo apimtį; vien AES etiketė šio reikalavimo neįrodo.

Praktinio bandymo metu reikėtų užšifruoti reprezentatyvius duomenis, atlikti įprastus skaitymus, pakeisti raktą, atkurti senesnę kopiją ir imituoti nepasiekiamą raktų paslaugą. Įtraukite masinius importus ir eksportus, nes jų elgsena gali skirtis nuo įprastų programos užklausų. Matuokite poveikį pačios programos delsai ir atkūrimo tikslams, o ne priimkite bendrą teiginį apie našumą.

Užfiksuokite aiškų priėmimo sprendimą: kurios grėsmės sprendžiamos, kokios priklausomybės įvedamos, kas lieka už apimties ribų ir kas atsakingas už tas liekamąsias rizikas. Taip pat testuokite perkeliamumą. Eksportuotas šifruotas tekstas turi mažai veiklos vertės, jei pasibaigus santykiams su paslaugų teikėju neįmanoma interpretuoti jo formato, įvyniotų raktų ar reikalingų metaduomenų.

Atkūrimą projektuokite kartu su konfidencialumu

Atsarginei kopijai nustatykite tris dalykus: duomenys užšifruoti, įgalioti atkūrimo darbuotojai gali atlikti reikiamas raktų operacijas ir atkūrimas pavyksta.

Nedėkite vienintelio atkūrimo kelio į tą pačią gedimo ribą kaip gamybinė aplinka. Paskyros užblokavimas, regioninis sutrikimas ar administracinė klaida gali paveikti ir atsarginę kopiją, ir jos raktus. Atskira atkūrimo tvarka turėtų likti griežtai kontroliuojama; jos nepriklausomumas neturi padaryti jos plačiai prieinamos.

Dokumentuokite kiekvienai atsarginių kopijų kartai reikalingas raktų versijas, reikiamas tapatybes, patvirtinimo žingsnius, paslaugų teikėjo priklausomybes ir atkurtų duomenų apribojimus. Atkūrimas į testinę aplinką neturėtų tyliai atskleisti gamybinės informacijos kūrėjams.

Atkūrimą išbandykite izoliuotoje aplinkoje. Užfiksuokite, ar pavyko rasti atsarginę kopiją, ar vientisumo patikros buvo sėkmingos, ar reikiami raktai liko tinkami naudoti, ar programos duomenis buvo galima perskaityti ir ar pasiektas atkūrimo laikas atitiko organizacijos tikslą. Bet kokie laiko duomenys priklauso faktinėms pratyboms, o ne numanomai šifravimo naudai.

Į atsparumo testavimą įtraukite raktų paslaugos gedimą. Nuspręskite, ar darbo krūvis turėtų sustoti saugiai, bandyti pakartotinai ar naudoti patvirtintą podėlyje esantį raktą. Podėlis gali pagerinti prieinamumą, tačiau pailgina laikotarpį, per kurį procesas gali iššifruoti po to, kai centrinė prieiga panaikinama. Šį kompromisą dokumentuokite aiškiai.

Pasirenkite įtariamam rakto kompromitavimui

Reagavimas priklauso nuo to, kas buvo atskleista. Nutekėję programos prisijungimo duomenys su leidimu kreiptis į KMS skiriasi nuo eksportuoto šifravimo rakto: pašalinus prisijungimo duomenis gali būti sustabdyta būsima prieiga prie paslaugos, o užpuolikas, turintis raktą ir šifruotą tekstą, gali iššifruoti savarankiškai. Kompromituotas pasirašymo raktas sukuria kitokią problemą, susijusią su pasitikėjimu parašais, o ne vien konfidencialumu.

Parenkite vadovą, kuriame nurodytas sprendimą priimantis asmuo, paveiktų raktų identifikatoriai, priklausomos sistemos, izoliavimo galimybės ir išsaugotini įrodymai. Ištirkite politikų pakeitimus, neįprastas raktų operacijas, duomenų atsisiuntimus, prieigą prie programų ir galimą poveikio laikotarpį. Trūkstami žurnalų įvykiai nėra įrodymas, kad iššifravimas nevyko, ypač kai raktus galima eksportuoti ar laikyti podėlyje.

Izoliavimas gali apimti tapatybės išjungimą, politikos susiaurinimą, darbo krūvio izoliavimą ar rakto išjungimą. Prieš atlikdami negrįžtamą veiksmą, įvertinkite prieinamumo pasekmes. Nesunaikinkite vienintelio atkūrimo rakto kaip improvizuoto izoliavimo žingsnio.

Po izoliavimo nustatykite, kuriuos duomenis reikia perkelti į nekompromituotus raktus. Vyniojimo rakto pakeitimo nepakanka, jei užpuolikas gavo pagrindinius duomenų raktus. Saugomų duomenų pakartotinis šifravimas gali apsaugoti būsimas kopijas, tačiau negali atšaukti kartu pavogto šifruoto teksto ir raktų. Panašiai, pakeitus kompromituotą programos tapatybę, bet neištaisius jos autorizacijos trūkumo, pradinis atskleidimo kelias lieka atviras.

Išsaugokite incidento laiko juostą, paveiktų duomenų vertinimą, pakeitimo ir patvirtinimo įrašus bei likusius neapibrėžtumus. Kai susiję asmens duomenys, pranešimo pareigas vertinkite atskirai; teiginys „duomenų bazė buvo užšifruota“ neatsako, ar užpuolikas galėjo gauti atvirą tekstą ar tinkamus naudoti raktus.

Kurkite įrodymus, kurie patikrina grandinę

Politika apibūdina numatytą elgseną. Įrodymai turėtų parodyti, kad įgyvendinimas jos laikosi ir kad svarbūs gedimų keliai elgiasi taip, kaip tikimasi.

Kartu naudokite konfigūracijos eksportus, politikų peržiūras, prieigos testus, raktų naudojimo žurnalus, diegimo patikras ir atkūrimo įrašus. Ekrano nuotraukos gali padėti peržiūrai, tačiau vien jos retai paaiškina apimtį, istorinę elgseną ar nuokrypius.

Žurnalų aprėptį interpretuokite atsargiai. Taikant vokinį šifravimą ir podėlyje laikomus duomenų raktus, viena raktų paslaugos operacija gali leisti kelis vėlesnius vietinius iššifravimus. Todėl KMS žurnalas nebūtinai yra išsamus kiekvienos prieigos prie atviro teksto įrašas. Kur tinka, derinkite jį su programos autorizacijos ir prieigos prie duomenų įrašais.

Iš įrodymų paketų pašalinkite paslaptis. Niekada neįkelkite neapdorotų raktų, atkūrimo frazių, galiojančių prisijungimo duomenų ar nereikalingų atviro teksto įrašų. Išsaugokite išteklių identifikatorių, laiko žymą, apimtį, peržiūrėtoją, testo rezultatą ir atitinkamą konfigūraciją, nesukurdami naujo atskleidimo.

Išimtyse turėtų būti nurodyta paveikta sistema, priežastis, kompensuojamosios kontrolės priemonės, atsakingas asmuo, galiojimo pabaiga ir šalinimo užduotis. Laikinai pasenusio perdavimo išimčiai reikia sprendimo ir pasitraukimo plano, o ne nuolatinės pastabos skaičiuoklėje.

Praktiškai rekomenduojama tikslines patikras kartoti po saugyklų, darbo krūvių tapatybių, raktų politikų, sertifikatų ar atsarginių kopijų paskirties vietų pakeitimų. Suplanuotos peržiūros išlieka naudingos, tačiau diegimas gali pakeisti apsaugos ribą dar iki kitos kalendorinės peržiūros. Automatinės patikros turėtų pateikti įgyvendinamus radinius su išteklių kontekstu ir atsakingu asmeniu, o žmonės peržiūrėtojai vertina išimtis ir grėsmių modelio pokyčius.

Pavyzdys: klientų dokumentų paslaugos atsekimas

Tarkime, iliustracinė SaaS paslauga saugo konfidencialius klientų dokumentus objektų saugykloje. Jos programa pateikia dokumentus autentifikuotiems naudotojams, o kasdienės atsarginės kopijos padeda pasiekti verslo nustatytą atkūrimo tikslą. Peržiūrimos grėsmės yra pavogtos saugyklos kopijos, neteisėta administracinė prieiga ir duomenų atskleidimas tarp nuomininkų.

Komanda aprašo TLS tarp naršyklės ir kraštinio mazgo, TLS tarp kraštinio mazgo ir programos, ryšius tarp programos ir saugyklos, gamybinę saugyklą ir atskirą atsarginių kopijų paskirties vietą. Ji nustato, kad trikčių šalinimo eksporto darbas įrašo iššifruotus failus į palaikymo aplanką. Šis aplankas tampa neatidėliotinu apimties klausimu; gamybinės saugyklos šifravimo nustatymas jo neapima.

Pradiniame sprendime gamybinius objektus apsaugo saugyklos šifravimas su kliento valdomu raktu. Programos tapatybė gali gauti autorizuotus objektus ir iškviesti reikiamas raktų operacijas. Diegimo vaidmuo gali kurti išteklius, tačiau neturi įprasto iššifravimo leidimo. Raktų politikų administravimas vyksta pagal atskirą patvirtinimo kelią.

Komanda pripažįsta likusią ribą: kompromituota programa vis tiek galėtų gauti atvirą tekstą. Ji svarsto programos lygmens šifravimą ypač jautriai dokumentų kategorijai, tada įvertina paieškos reikalavimus, palaikymo prieigą ir atkūrimo sudėtingumą, prieš nuspręsdama, ar papildoma riba pagrįsta.

Patikra duoda konkrečius rezultatus:

• Neįgaliota paslaugos tapatybė negali gauti ar iššifruoti dokumento.
• Autentifikuotas kito nuomininko naudotojas atmetamas programos.
• Netinkami aukštesnės grandies sertifikatai atmetami, o ne apeinami.
• Senesnė atsarginė kopija sėkmingai atkuriama naudojant reikiamą istorinę rakto versiją.
• Laipsniškas rakto pakeitimas leidžia perskaityti ir esamus dokumentus, ir naujus įkėlimus.
• Palaikymo eksporto darbas pakeičiamas taip, kad naudotų patvirtintą, prieigos kontroliuojamą šifruotą paskirties vietą su apibrėžtu saugojimu.

Peržiūrėtojas išsaugo duomenų srautų žemėlapį, konfigūracijos eksportus, tapatybių politikas, nuasmenintus neigiamų testų rezultatus, raktų keitimo įrašą ir atkūrimo ataskaitą. Rakto išjungimo pratybos negamybinėje aplinkoje patvirtina, kad paslauga grąžina kontroliuojamą klaidą, o ne atskleidžia duomenis ar tyliai atmeta įrašus.

Šis pavyzdys neįrodo apsaugos nuo kiekvienos atakos. Jis nustato, kokias grėsmes sprendimas sprendžia, kuri tapatybė lieka patikima ir kokie įrodymai pagrindžia šias išvadas.

Susiekite teisinius reikalavimus ir būsimus pokyčius su sprendimu

Šifravimo sprendimai turėtų atspindėti teisinius, sutartinius ir sistemų reikalavimus, nepaverčiant jų visuotiniais teiginiais. BDAR 32 straipsnis taiko rizika grindžiamą požiūrį ir šifravimą nurodo tarp tinkamų priemonių; jis nenustato visuotinio šifravimo įpareigojimo kiekvienai duomenų tvarkymo veiklai. Šifravimas taip pat nepanaikina pareigų, susijusių su teisėtu duomenų tvarkymu, prieiga, saugojimu ar incidentų vertinimu.

Apibrėžtos apimties ISO 27001 ISMS viduje dokumentuokite rizikos tvarkymą, taikomas kontrolės priemones, atsakomybę ir įrodymus, o ne manykite, kad viena užšifruota duomenų bazė patenkina platesnę valdymo sistemą. Kai NIS2 taikoma per nacionalinę teisę, jos 21 straipsnio priemonės apima politiką ir procedūras, susijusias su kriptografija ir, kai tikslinga, šifravimu. Taikymą ir nacionalinius reikalavimus patvirtinkite atskirai.

Kriptografinius pokyčius planuokite kaip inžinerinę priklausomybę. Inventorizuokite algoritmus, sertifikatus, bibliotekas, protokolus ir įterptus formatus, kad pasenusius mechanizmus būtų galima pakeisti. Ilgai saugomiems konfidencialiems duomenims įvertinkite būsimų kriptoanalizės ir kvantinių grėsmių aktualumą. Perėjimo prie postkvantinės kriptografijos klausimai skiriasi raktų nustatymo, parašų ir simetrinio šifravimo srityse; venkite neišbandyto visuotinio pakeitimo, pateikiamo kaip visuotinis sprendimas.

Padarykite kitą peržiūrą konkrečią

Secani gali susieti šio darbo tikslines sistemas, kontrolės reikalavimus, įgyvendinimo aprašymus, įrodymus, atsakingus asmenis ir peržiūros sprendimus. Pridėkite apsaugos žemėlapį ir nuasmenintus testų įrašus prie atitinkamų sistemų ir kontrolės priemonių, neišspręstus prieigos prie raktų ar atkūrimo klausimus paverskite užduotimis ir išsaugokite, kodėl buvo patvirtintas kiekvienas kriptografinis pasirinkimas. DI padedamus pasiūlymus peržiūrėkite pagal jų šaltinius, o žmogaus patvirtinimą išlaikykite aiškų.

Pradėkite nuo vienos jautrių duomenų saugyklos ir kartu atsekite prieigą prie duomenų, prieigą prie raktų ir atkūrimą. Pasirinkite vieną neigiamą autorizacijos testą ir vienas atkūrimo pratybas, paskirkite atsakingus asmenis ir užfiksuokite rezultatus prieš plėsdami apimtį. Mūsų debesijos saugumo vadovas pateikia platesnį konfigūracijos kontekstą.