Techninių ir organizacinių priemonių priedas turi paaiškinti, kokios apsaugos veikia konkrečioje paslaugoje ir kaip jų veikimą galima patikrinti. Bendras sąrašas „šifravimas, atsarginės kopijos, mokymai“ neatskleidžia nei taikymo apimties, nei atsakomybės. Kita vertus, sutarties priede nereikia skelbti privačių raktų, prieigos duomenų ar visos vidinės konfigūracijos.
Šis modelis padeda parengti aiškų saugos priedą prie duomenų tvarkymo sutarties arba vidaus paslaugos aprašo. Kiekvieną priemonę susiesite su saugoma operacija, įgyvendinimo būsena, savininku ir įrodymu. Pateikti tekstai yra hipotetiniai pavyzdžiai, kuriuos galima naudoti tik tada, kai jie atitinka faktinę sistemą.
Apibrėžkite priedo taikymo ribas
Pirmoje dalyje nurodykite paslaugą, duomenų tvarkymo operacijas, aplinkas ir susijusius dalyvius. Bendrovė gali turėti vieną saugos politiką, bet kelias labai skirtingas paslaugas. Sertifikatas ar procedūra, apimanti vieną duomenų centrą, neįrodo kitos programos ar išorinės pagalbos proceso apsaugos.
Pavyzdinis apimties tekstas: „Priedas taikomas klientų dokumentų portalo gamybinei aplinkai, jos administravimui ir atsarginėms kopijoms. Kliento pačio valdomi galiniai įrenginiai aprašomi atskirame atsakomybės skyriuje.“ Prieš naudodami tokį fragmentą patikrinkite, ar bandymo aplinkoje nėra tikrų duomenų ir ar jos nepagrįstai nepaliekate už apimties ribų.
Informacinių sistemų žemėlapis padeda susieti priedą su tikru duomenų keliu. Nurodykite, kuri dalis vykdoma jūsų, kuri tiekėjo ir kuri kliento. Tai turi būti atsakomybės paaiškinimas, o ne būdas palikti reikšmingą riziką be savininko.
Priemones pasirinkite pagal riziką ir taikomas pareigas
BDAR 32 straipsnis numato riziką atitinkančią apsaugą, atsižvelgiant į techninių galimybių išsivystymo lygį, įgyvendinimo sąnaudas, tvarkymo pobūdį, aprėptį, kontekstą, tikslus ir riziką žmonių teisėms bei laisvėms. Jo priemonių pavyzdžiai nėra vienodas visoms sistemoms privalomas katalogas.
Priedo rengimo byloje įvardykite pagrindinius scenarijus: neteisėta prieiga, neteisingas pakeitimas, duomenų praradimas, paslaugos nepasiekiamumas ir neteisingas atskleidimas. Kiekvienam pasirinkite priemones ir parodykite, kokią rizikos dalį jos mažina. PDAV pavyzdys padeda tada, kai reikia platesnio poveikio vertinimo, tačiau ne kiekvienas saugos priedas savaime yra PDAV.
Jei priemonė dar tik planuojama, jos nerašykite kaip įgyvendintos. Galima aiškiai atskirti esamą būseną, patvirtintą pakeitimą ir jo priėmimo sąlygą. Sutartinis pažadas turi būti suderintas su realiu diegimo planu ir tuo, ar paslaugą galima pradėti iki priemonės įgyvendinimo.
Naudokite vienodą priemonės įrašo struktūrą
Kiekvienai priemonei aprašykite apsaugos paskirtį, apimtį, faktinį mechanizmą, savininką ir patikrinimo įrodymą. Ta pati struktūra palengvina palyginimą su tiekėjo dokumentais, tačiau turinys turi likti konkretus. Skirtingų sistemų priemonės neturi būti nukopijuotos vien dėl to, kad abi priklauso tai pačiai organizacijai.
| Priemonė | Hipotetinis konkretus aprašas | Įrodymas |
|---|---|---|
| Administravimo prieiga | Individualios paskyros, MFA, paskirtų vaidmenų patvirtinimas | Paskyrų ir leidimų peržiūros rezultatas |
| Dokumentų prieiga | Kliento darbuotojas mato tik jam suteiktą klientų aplinką | Atskyrimo bandymo protokolas |
| Ryšio apsauga | Patvirtintas TLS profilis kiekvienai nustatytai atkarpai | Galinių taškų ir sertifikatų patikra |
| Atkūrimas | Atsarginės kopijos ir tikslui pritaikytas atkūrimo procesas | Faktinio atkūrimo bandymo įrašas |
| Pašalinimas | Nustatytų duomenų šalinimas pagal sutartą pabaigos eigą | Šalinimo ir likusių kopijų patikra |
Šios eilutės nėra užpildytas konkretaus tiekėjo patvirtinimas. Rengėjas turi papildyti tikrą apimtį ir tai, kas buvo patikrinta. Jei turimas tik savideklaracijos atsakymas, įrodymo skiltyje taip ir nurodykite; nevadinkite jo atliktu auditu ar nepriklausomu sertifikavimu.
Konfidencialumą aprašykite nuo paskyros iki dokumento
Prieigos dalyje parodykite, kaip teisės suteikiamos, keičiamos ir panaikinamos. Nurodykite, kas patvirtina administravimo prieigą ir kaip tvarkomos laikinos techninės pagalbos teisės. Autentifikavimo politika padeda suderinti paskyrų, MFA ir atkūrimo reikalavimus. Bendras teiginys „prieiga tik įgaliotiems asmenims“ neatskleidžia suteikimo kontrolės.
Dokumentų lygmeniu paaiškinkite atskyrimą pagal organizaciją, projektą ar funkciją, kai tai aktualu. Patikrinkite ne tik pagrindinį ekraną, bet ir paiešką, eksportą, nuorodas bei fonines užduotis. Jei klientų aplinkos atskirtos, bandymas turi parodyti, kad vienos aplinkos paskyra negali pasiekti kitos aplinkos įrašo alternatyviu keliu.
Fizinę apsaugą aprašykite pagal tikrą modelį. Organizacijai, naudojančiai debesijos paslaugą, nereikia apsimesti pačiai valdančia duomenų centro apsaugos postą. Galima nurodyti tiekėjo atsakomybę ir peržiūrėtą įrodymą. Savo darbo vietų, popierinių dokumentų ir įrenginių apsaugos tuo pačiu nepamirškite.
Šifravimui nurodykite duomenų ir raktų apimtį
Šifravimo planas padeda atskirti perdavimo, saugojimo ir raktų valdymo priemones. Priedo tekstas turėtų parodyti, kokie duomenys šifruojami, kas valdo raktus ir kokias ribas priemonė turi. Duomenų laikmenos šifravimas neapsaugo nuo visų veiksmų, kuriuos leidžia jau prisijungusi privilegijuota paskyra.
Ryšiui remkitės TLS patikros lapu, įskaitant atkarpas po tarpinio serverio. Neskelbkite vieno protokolo pavadinimo taip, tarsi jis patvirtintų visą perdavimo grandinę. Jei raktus valdo paslaugos teikėjas, priede aiškiai atskirkite tokį modelį nuo sprendimo, kuriame tik klientas turi iššifravimo galimybę.
Vientisumui numatykite pakeitimų kontrolę
Vientisumas apima apsaugą nuo neteisingo ar neleistino pakeitimo. Aprašykite, kas gali keisti gamybinę konfigūraciją, kaip patvirtinami reikšmingi pakeitimai ir kaip aptinkamas netikėtas rezultatas. Vien failo kontrolinė suma neapima visų programos ar administratoriaus veiksmų, todėl priemonės turi atitikti konkretų duomenų kelią.
Saugumo žurnalų politika padeda nustatyti, kurie veiksmai registruojami ir kas peržiūri įvykius. Priedo aprašas turi atskirti registravimą nuo aktyvios stebėsenos. Jei įvykiai saugomi, bet niekas negauna įspėjimo, negalima pažadėti nuolatinio neatidėliotino reagavimo vien dėl turimo žurnalo.
Pakeitimų pavyzdyje programuotojas parengia naują versiją, paskirtas asmuo patvirtina diegimą, o komanda patikrina pagrindinius duomenų prieigos ir vientisumo scenarijus. Sutarties priede nebūtina pateikti visų komandų, tačiau turi būti suprantamas atsakomybės ir patikros mechanizmas.
Prieinamumą ir atkūrimą pagrįskite bandymu
Atsarginė kopija nėra tas pats, kas sėkmingas paslaugos atkūrimas. Aprašykite, kokia informacija kopijuojama, kaip kopijos apsaugotos nuo tos pačios gedimo priežasties ir kokie atkūrimo tikslai suderinti su procesu. Konkrečius RTO ir RPO dydžius nurodykite tik tada, kai jie iš tiesų nustatyti ir jų taikymo ribos aiškios.
Veiklos tęstinumo planas padeda suderinti techninį atkūrimą su paslaugos darbu, o atkūrimo pratybos pateikia įrodymo eigą. Jei bandyme atkurta tik duomenų bazė, bet ne autentifikavimas ar reikalingi raktai, rezultatą aprašykite tiksliai. Dalinė patikra neturi virsti pažadu, kad visa paslauga atkurta per nurodytą laiką.
Užpildytas fragmentas galėtų būti toks: „Atkūrimo procesą tikriname pagal patvirtintą pratybų planą; bandymo įraše fiksuojame atstatytą apimtį, trukmę, duomenų nuoseklumą ir nepašalintas problemas.“ Toks tekstas dar turi būti papildytas organizacijos tikru planu. BDAR 32 straipsnis nenustato visoms organizacijoms vienodo pusmetinio ar metinio bandymo dažnio.
Įtraukite žmones, incidentus ir tiekėjus
Organizacinės priemonės apima pareigų paskirstymą, instrukcijas, reikalingus mokymus ir konfidencialumo sąlygas. Mokymą susiekite su tikromis užduotimis: neteisingas gavėjas, techninės pagalbos prieiga ar jautrus užduoties priedas. Vien visų darbuotojų parašas neįrodo, kad komanda moka sustabdyti konkretų incidentą.
Incidento dalyje aprašykite kontaktą, eskalavimą ir pagalbos teikimą. Kai veikiama kaip tvarkytojas, 33 straipsnio 2 dalis reikalauja pranešti valdytojui nepagrįstai nedelsiant sužinojus apie asmens duomenų saugumo pažeidimą. Valdytojo pranešimo priežiūros institucijai režimas yra atskiras. Nesupainiokite jo 72 valandų ribos su leidimu tvarkytojui tiek laukti.
Valdytojo ir tvarkytojo vaidmenų lentelė padeda nustatyti, kas vykdo kiekvieną pareigą. Kai naudojami subtvarkytojai, priedo apimtis turi derėti su sutartinėmis sąlygomis ir realiai perduotomis operacijomis. Bendras tiekėjo saugos aprašas nepadengia savaime visų naujai prijungtų paslaugų.
Tikrinkite įrodymų tinkamumą ir pokyčius
Audito įrodymų užduotyje nurodykite, kokį konkretų teiginį turi pagrįsti dokumentas. Sertifikato atveju patikrinkite subjektą, apimtį, laikotarpį ir susijusią paslaugą. Ataskaitos atveju nustatykite, kokios kontrolės vertintos ir ar yra išimčių. Logotipas ar bendras teiginys „atitinkame standartus“ nėra visas patikros rezultatas.
Ne kiekvienai paslaugai automatiškai reikia identiško nepriklausomo audito ar sertifikato. Tikrinimo gylį pagrįskite rizika ir reikalingomis garantijomis. Kartu pernelyg trumpas savideklaracijos atsakymas neturi būti laikomas pakankamu vien todėl, kad tiekėjas populiarus. Neatsakytus klausimus palikite matomus, su atsakingu asmeniu ir sprendimo sąlyga.
Priedą užbaikite aiškia versija ir atsakomybės ribomis
Nurodykite versiją, patvirtinimo datą ir tvarką, kaip valdomi reikšmingi priemonių pakeitimai. Atskirai aprašykite kliento veiksmus, nuo kurių priklauso paslaugos apsauga: paskyrų suteikimą, MFA įjungimą ar galinių įrenginių valdymą, kai tai tikrai jo atsakomybė. Nebūtina kiekvieno vidinio pakeitimo pateikti kaip naujos sutarties, tačiau pažadėtas apsaugos lygis turi likti kontroliuojamas.
Prieš pasirašymą palyginkite priedą su faktine konfigūracija ir peržiūrėtais įrodymais. Pašalinkite pasenusius pažadus, paaiškinkite išimtis ir įsitikinkite, kad atsakingi žmonės sutinka su jiems priskirtomis užduotimis. Galutinis dokumentas turi leisti abiem šalims suprasti, kas saugoma, kokiu būdu ir kaip galima patikrinti, kad pasirinktos priemonės veikia.