
Prieigos pakeitimai yra ne tik techninė, bet ir koordinavimo problema. Tapatybių platforma negali pašalinti rangovo paskyros, jei niekas nepraneša atsakingam asmeniui, kad sutartis baigėsi. Lygiai taip pat laiku gautas personalo skyriaus pranešimas neįrodo, kad visos programos nustojo priimti asmens prisijungimo duomenis.
Ateinantiems, perkeliamiems ir išeinantiems darbuotojams reikia proceso, kuris verslo įvykį susieja su patvirtinta prieigos būsena, atlieka būtinus pakeitimus ir patikrina rezultatą. Technologijų vadovybės požiūriu svarbus klausimas yra ne tai, ar yra išėjimo kontrolinis sąrašas. Svarbu, ar procesas apima sistemas, kurias žmonės iš tikrųjų naudoja, ar jis susitvarko su nesėkmėmis ir ar palieka įrodymus, kas ir kada pasikeitė.
Kiekvieną gyvavimo ciklo įvykį traktuokite kaip asmens leidžiamos prieigos pakeitimą, o ne vien kaip užklausą sukurti ar išjungti paskyrą. Įvykio įraše turėtų būti nurodytas asmuo, darbo ar sutarties santykių būsena, vadovas ar globėjas, įsigaliojimo data ir laikas bei paveiktas vaidmuo. Naudokite stabilų identifikatorių, o ne remkitės vien vardais ar el. pašto adresais.
Darbuotojų įvykius dažnai inicijuos personalo skyrius. Rangovų įvykius gali inicijuoti pirkimų atsakingas asmuo, projekto vadovas ar vidinis globėjas. Kiekvienai populiacijai pasirinkite autoritetingą šaltinį ir apibrėžkite, kaip pataisymai, atšaukti darbo pradžios atvejai, sutarčių pratęsimai ir skubūs išėjimai pasiekia IT.
Atskirkite keturias atsakomybes, net jei maža komanda kelias iš jų priskiria tam pačiam asmeniui:
| Atsakomybė | Atskaitingas veiksmas | Tikėtinas įrašas |
|---|---|---|
| Inicijavimas | Pateikti tikslų įvykį ir įsigaliojimo laiką | Įvykio įrašas ir šaltinis |
| Patvirtinimas | Patvirtinti numatytą prieigą ir išimtis | Įvardytas patvirtinimas ir pagrindimas |
| Vykdymas | Atlikti pakeitimus visose paveiktose sistemose | Kiekvienos sistemos rezultatai ir laiko žymos |
| Patikrinimas | Patikrinti gautą būseną ir išspręsti neatitikimus | Peržiūros rezultatas ir atviros išimtys |
Paskirkite pavaduotojus ir eskalavimo kelią. Suplanuotas išėjimas neturi priklausyti nuo vieno administratoriaus buvimo. Jautriems pakeitimams naudingą patikrą suteikia nepriklausomas tikrintojas; kai personalo trūkumas to neleidžia, dokumentuokite tvarką ir atlikite vėlesnę peržiūrą.
Kiekvienam įvykiui apibrėžkite užbaigimo kriterijus. Ateinantis darbuotojas pasiruošęs, kai patikrinta patvirtinta prieiga ir būtinos įrenginių kontrolės. Perkėlimas užbaigtas, kai patikrinti ir papildymai, ir pašalinimai. Išėjimas užbaigtas, kai prieigos keliai atšaukti, o neišspręsti turto, duomenų ar prisijungimo duomenų klausimai turi aiškius atsakingus asmenis.
Tai praktinės kontrolių projektavimo rekomendacijos, o ne visuotiniai įstatyminiai terminai. ISO 27001 ISMS aplinkoje prieigos kontrolės turėtų atspindėti organizacijos taikymo sritį ir rizikos valdymą. Platesnį kontrolių kontekstą rasite straipsnyje ISO 27001 A priedas praktikoje.
Pradėkite nuo programų inventoriaus. Kiekvienai sistemai užfiksuokite jos atsakingą asmenį, tapatybės šaltinį, paskyrų kūrimo metodą, autentifikavimo metodą, palaikomus atšaukimo veiksmus ir patikrinimo metodą. Įtraukite centralizuotai valdomas programas ir programas su vietinėmis paskyromis.
Vienkartinis prisijungimas (SSO) nebūtinai reiškia viso gyvavimo ciklo valdymą. Programa gali autentifikuoti per tapatybių teikėją, kartu išlaikydama vietinius administratorius, API raktus, aktyvias sesijas ar atkūrimo galimybes. Paskyrų kūrimo jungtis gali išjungti naudotoją, nepašalindama kiekvienos teisės. Dokumentuokite, ką kiekvienas mechanizmas iš tikrųjų daro.
Įtraukite šiuos mažiau matomus prieigos kelius:
Automatiškai neišjunkite kiekvienos su išeinančiu darbuotoju susijusios paslaugos tapatybės: ji gali vykdyti gamybinį darbo krūvį. Vietoj to perduokite atsakomybę, peržiūrėkite leidimus ir, kai tinkama, pakeiskite atskleistus prisijungimo duomenis. Tikslas yra pašalinti asmens prieigą nesukeliant sutrikimo, kurio galima išvengti.
Periodiškai suderinkite inventorių su tapatybių eksportais, įrenginių įrašais, pirkimų įrašais ir komandų deklaracijomis. Nė vienas šaltinis nebūtinai atskleis kiekvieną programą. Nevaldomi atradimai turėtų patekti į gyvavimo ciklo procesą, o ne likti neformaliomis išimtimis.
Prieigos paketus apibrėžkite pagal atsakomybes, o ne vien pagal pareigybių pavadinimus. Pagalbos analitikui gali reikėti prieigos prie klientų užklausų, bet ne prie atsiskaitymų eksporto. Programinės įrangos inžinieriui gali reikėti kodo saugyklų ir kūrimo aplinkų, pagal numatytuosius nustatymus negaunant gamybinės aplinkos administravimo teisių.
Kiekviena bazinė konfigūracija turėtų turėti atsakingą asmenį, versiją, įtrauktas grupes ar teises ir peržiūros datą. Užfiksuokite, kuri versija buvo pritaikyta ateinančiam darbuotojui. Kitaip vėlesnis vaidmens atnaujinimas apsunkina istorinių prieigos sprendimų atkūrimą.
Papildomos prieigos prašykite atskirai. Prašyme turėtų būti nurodytas verslo tikslas, tvirtinantis sistemos ar duomenų atsakingas asmuo, leidimų lygis ir, kai tinkama, galiojimo pabaiga. Venkite kopijuoti viso esamo darbuotojo leidimų rinkinio: taip gali būti atkartotos sukauptos išimtys ir ankstesnių vaidmenų privilegijos.
Kai naudinga, paskyras paruoškite iš anksto prieš darbo pradžios datą, bet kontroliuokite jų aktyvavimą. Atšauktas įdarbinimas turėtų inicijuoti iš anksto paruoštų paskyrų, išsiųstų įrenginių ir kvietimų sutvarkymą. Rangovai turėtų turėti vidinį globėją ir pabaigos ar peržiūros datą; pratęsimams turėtų reikėti teigiamo sprendimo, o ne tyliai virsti nuolatine prieiga.
Užfiksuokite įrenginio identifikatorių, priskirtą asmenį, perdavimo datą ir įtraukimą į valdymą. Prieš suteikdami jautrią prieigą, patikrinkite atitinkamą bazinę konfigūraciją: palaikomą operacinę sistemą, pataisų būklę, disko šifravimą, ekrano užraktą, galinių įrenginių apsaugą ir patvirtintą autentifikavimo sąranką.
Tai rizika grindžiami įgyvendinimo pasirinkimai, o ne teiginys, kad kiekviena organizacija turi naudoti identiškus nustatymus. Asmeniniams įrenginiams aiškiai apibrėžkite leidžiamą prieigą ir duomenų tvarkymą, o ne laikykite juos lygiaverčiais valdomiems nešiojamiesiems kompiuteriams.
Kai įmanoma, naudokite datuotus įrenginių valdymo sistemų stebėjimus. Rankinis inventorius vis tiek gali būti naudingas, jei jis suderintas ir pagrįstas įrodymais; gyvą inventorių taip pat reikia kritiškai vertinti, kai įrenginys nustojo teikti ataskaitas. Išsaugokite stebėjimų laiką, kad sena gera būsena nebūtų palaikyta dabartiniu užtikrinimu.
Patikrinkite autentifikavimo registraciją ir pradinių prisijungimo duomenų pateikimą. Kai jūsų politika reikalauja daugiaveiksnio autentifikavimo, patvirtinkite, kad jis aktyvus prieš prasidedant prieigai, o ne fiksuokite tik tai, kad buvo išsiųstas kvietimas užsiregistruoti. Prisijungimo duomenų ir atkūrimo kodų nelaikykite gyvavimo ciklo užklausose.
Perkėlimai dažnai yra sunkiausi gyvavimo ciklo įvykiai, nes asmuo lieka dirbti, o jo esama paskyra toliau veikia. Naujai prieigai skiriamas dėmesys, nes trūkstami leidimai trukdo dirbti. Sena prieiga gali išlikti be jokių matomų požymių.
Perkėlimą traktuokite kaip trijų būsenų palyginimą: dabartinės prieigos, patvirtintos naujos bazinės konfigūracijos ir patvirtintų išliekančių išimčių. Nustatykite, kurias teises reikia pridėti, išlaikyti, sumažinti ar pašalinti. Tikrinkite tiesioginius priskyrimus, taip pat grupes, įdėtines narystes, administravimo vaidmenis ir vietinius programų leidimus.
Ankstesnis vadovas turėtų padėti nustatyti pasibaigusias atsakomybes. Priimantis vadovas patvirtina naujas pareigas, o sistemų ar duomenų atsakingi asmenys tvirtina jautrią prieigą. Taip naujas vadovas negali netiesiogiai leisti išlaikyti prieigos prie kito skyriaus informacijos.
Pereinamasis laikotarpis gali būti teisėtas. Iš finansų skyriaus išeinančiam asmeniui gali reikėti ribotos prieigos, kad užbaigtų perdavimą. Užfiksuokite konkretų leidimą, pagrindimą, tvirtinantį atsakingą asmenį ir galiojimo pabaigą. Kai įmanoma, plačią rašymo prieigą pakeiskite siauresne arba tik skaitymo prieiga. Galiojimo pabaigą įtraukite į vykdomą užduotį ar sistemos nustatymą, o ne tik į komentarą.
Pakeitimai taip pat gali paveikti įrenginius, bendras pašto dėžutes, duomenų atsakomybę ir privilegijuotas pareigas. Perėjimas į administravimo vaidmenį neturėtų automatiškai paversti kasdienės paskyros privilegijuota tapatybe.
Po vykdymo palyginkite faktinį prieigos rinkinį su numatytu rezultatu. Perkeliant į kitą skyrių, suteikti naują vaidmenį gali būti lengva. Svarbus patikrinimas yra tai, ar lieka sena finansų, klientų ar administravimo prieiga. Perkėlimų imtis, kurioje tikrinamas tik naujų teisių suteikimas, šios rizikos nepastebi.
Užfiksuokite įsigaliojantį atšaukimo laiką, įskaitant laiko juostą. „Paskutinė diena“ yra per daug neaiški paskirstytoms komandoms ir suplanuotam automatizavimui. Atskirkite suplanuotą išėjimą nuo skubaus atleidimo, įtariamo kompromitavimo ar netikėto nebuvimo, dėl kurio reikia laikinai sustabdyti prieigą.
Laiką suderinkite su personalo skyriumi ir atitinkamais vadovais. Jautrią informaciją apie atleidimą ribokite tik tiems, kam jos reikia, kartu užtikrindami, kad vykdytojai gautų pakankamai informacijos veikti. Didelės rizikos išėjimams gali prireikti koordinuotų neatidėliotinų veiksmų; įprasti išėjimai gali leisti suplanuotą perdavimą prieš pasibaigiant prieigai.
Neleiskite, kad duomenų perdavimas ar įrenginių siuntimas atidėtų atšaukimą. Šios veiklos gali turėti atskiras užbaigimo datas ir atsakingus asmenis. Jei paskata ateina pavėluotai, užfiksuokite numatytą nutraukimo laiką, faktinį vykdymą ir pažeidžiamumo intervalą, o ne keiskite dokumentus, kad įvykis atrodytų laiku atliktas.
Išjunkite pagrindinę tapatybę ir atlikite programoms specifinius veiksmus pagal inventorių. Pagal poreikį spręskite aktyvių sesijų, atnaujinimo žetonų, vietinių paskyrų, privilegijuotų paskyrų, nuotolinės prieigos, sertifikatų ir asmeninių prisijungimo duomenų klausimus. Centrinės paskyros išjungimas neįrodo, kad kiekviena esama sesija ar savarankiškai išduoti prisijungimo duomenys tapo netinkami naudoti.
Bendras paslaptis, kurias asmuo galėjo pasiekti, keiskite pagal riziką ir patikrinkite, ar pakeitimas nesutrikdys priklausomų sistemų. Pašalinkite atkūrimo metodus ar deleguotus leidimus, kurie galėtų atkurti prieigą. Kai susijusios klientų ar tiekėjų aplinkos, paprašykite jų atsakingo asmens atšaukti prieigą ir išsaugokite patvirtinimą.
Užfiksuokite atskirus rezultatus. Jungties skirtojo laiko pabaiga nėra sėkmingas uždarymas vien todėl, kad bendra užduotis baigėsi. Nesėkmes nukreipkite įvardytam atsakingam asmeniui, naudokite patvirtintą atsarginį sprendimą ir patikrinkite galutinę būseną. Skubi neišspręsta prieiga turėtų patekti į saugumo eskalavimo procesą.
Kiekvieną priskirtą turtą sekite per grąžinimą, apžiūrą ir patvirtintą atstatymą ar utilizavimą. Nuotoliniams darbuotojams užfiksuokite siuntimo tvarką ir neišspręstą turto saugojimą. Pašalinkite fizinę prieigą ir, kai aktualu, susigrąžinkite žetonus ar raktus.
Jei grąžinimas vėluoja, pagal politiką ir riziką naudokite turimas užrakinimo ar ištrynimo kontroles. Atskirkite komandos išsiuntimą nuo to, kad įrenginys ją patvirtino ir įvykdė. Neprisijungęs nešiojamasis kompiuteris gali komandos negauti. Likutinį pažeidžiamumą vertinkite pagal šifravimo būseną, vietinius prisijungimo duomenis, talpykloje esančius duomenis ir turimus tinklo apribojimus, o ne laikykite „ištrynimas eilėje“ ištrynimo įrodymu.
Verslo dokumentams, saugykloms, bendriems darbo procesams ir paslaugų atsakomybei paskirkite perėmėją. Naudokite įgaliotus administracinius perdavimo mechanizmus, o ne prašykite ko nors apsimesti buvusiu darbuotoju. Ribokite prieigą prie pašto dėžutės ar failų, užfiksuokite tikslą ir apribokite ją gaunančių asmenų ratą.
Atskirkite prieigos atšaukimą, licencijų susigrąžinimą, saugojimą ir ištrynimą. Licencijos pašalinimas skirtingose programose gali skirtingai paveikti duomenų prieinamumą. Prieš negrįžtamą tvarkymą patikrinkite saugojimo reikalavimus ir bet kokį teisinį duomenų išsaugojimo įpareigojimą.
Asmens duomenims BDAR 5 straipsnis nustato saugojimo trukmės apribojimą; jis nesukuria vieno universalaus darbuotojų paskyrų ištrynimo termino. Apibrėžkite pagrįstus saugojimo laikotarpius ir tvarkymo atsakomybes. 32 straipsnis reikalauja rizikai tinkamų saugumo priemonių, todėl dokumentuokite išėjimo kontrolių motyvus, o ne laikykite kontrolinio sąrašo savaime teisine atitiktimi.
Naudingas įrašas susieja leistą sprendimą su stebėtu rezultatu. Išsaugokite įvykį, patvirtinimą, paveiktas sistemas, vykdymo laiką, patikrinimo rezultatus ir išimčių valdymą. Įtraukite numatytą įsigaliojimo laiką, kad tikrintojai galėtų įvertinti, ar veikta laiku.
Praktiniame įrodymų pakete yra:
Politika parodo ketinimą. Užklausa parodo koordinavimą. Programos rezultatas ar prieigos eksportas padeda parodyti įgyvendinimą. Nė vienas iš jų neturėtų pakeisti kitų. Ekrano kopijos gali būti naudingos, kai stipresnių eksportų nėra, tačiau jose turi būti pakankamai konteksto sistemai, subjektui ir stebėjimo laikui nustatyti.
Apsaugokite šiuos įrašus: juose yra informacijos apie darbo santykius ir saugumo požiūriu jautrių detalių. Taikykite prieigos apribojimus ir saugojimo grafiką, venkite kaip įrodymus rinkti slaptažodžius, nereikalingus atleidimo aprašymus ar ištisas pašto dėžutes. Istoriniai įrašai turėtų likti suprantami net ir ištrynus veikiančias paskyras.
Panagrinėkime iliustracinę įmonę su centriniu tapatybių teikėju, valdomais nešiojamaisiais kompiuteriais ir finansų programa su vietiniais leidimais. Tarkime, darbuotojas birželio 1 d. pereina iš finansų operacijų į klientų sėkmės komandą, jam reikia penkių darbo dienų perdavimo laikotarpio, o vėliau, rugsėjo 30 d., jis išeina. Šios datos ir susitarimai yra pavyzdžio prielaidos, o ne nustatyti terminai.
Perkėlimui IT užfiksuoja dabartines teises. Klientų sėkmės prieiga patvirtinama, finansų rašymo prieiga pašalinama įsigaliojimo metu, o ribota finansų skaitymo prieiga išlaikoma iki perdavimo laikotarpio pabaigos. Finansų atsakingas asmuo patvirtina šią išimtį. Kadangi finansų programa tvarko vietinius leidimus, jos administratorius pakeitimą atlieka ir patikrina atskirai nuo tapatybių teikėjo grupės atnaujinimo.
Pasibaigus laikotarpiui, patikrinimas nustato, kad liko vietinis eksporto leidimas. Perkėlimo įrašas lieka atviras, administratorius leidimą pašalina, o tikrintojas užfiksuoja galutinę būseną. Pamoka konkreti: vaidmens pakeitimas centriniu lygmeniu pavyko, tačiau programos leidimų modeliui reikėjo papildomo veiksmo.
Vėlesniam išėjimui procesas nustato tikslų nutraukimo laiką, perduoda verslo failus patvirtintam perėmėjui, išjungia tapatybes, atšaukia taikomas sesijas ir žetonus bei tiesiogiai patikrina finansų paskyrą. Nešiojamasis kompiuteris per kurjerį dar nepristatytas. Jo grąžinimas lieka turto išimtimi, o suvaldymo veiksmai ir įrenginio stebėjimai fiksuojami atskirai nuo paskyros atšaukimo.
Gauti įrodymai rodo ir sėkmingus pakeitimus, ir pradinę pašalinimo nesėkmę. Paslėpus nesėkmę būtų prarasta informacija, reikalinga darbo procesui tobulinti.
Realių gyvavimo ciklo įvykių imtį tikrinkite pagal programų inventorių. Įtraukite rangovus, privilegijuotus naudotojus, nuotolinius darbuotojus, perkeliamus darbuotojus su laikinu persidengimu ir programas už tapatybių teikėjo ribų. Prieigos peržiūrose taip pat turėtų būti nagrinėjama, ar dabartiniai leidimai vis dar atitinka kiekvieno asmens atsakomybes; jos papildo įvykių inicijuojamus pakeitimus, o ne juos pakeičia.
Testuokite ne tik įprastą vykdymą, bet ir nesėkmių kelius: praleistą personalo skyriaus įvykį, nepavykusią jungtį, nepasiekiamą administratorių, vėluojantį įrenginio grąžinimą ar atšauktą darbo pradžią. Patikrinkite, ar įspėjimai pasiekia atsakingą asmenį ir ar pakartojimai ar rankiniai veiksmai duoda patikrinamus rezultatus.
Naudingi rodikliai yra atšaukimo vėlavimas, palyginti su suderintu nutraukimo laiku, nepavykę veiksmai, laukiantys sprendimo, pasibaigusio galiojimo laikina prieiga ir įvykiai, uždaryti be patikrinimo. Apibrėžkite, ką skaičiuoja kiekvienas rodiklis. Geras vidurkis gali paslėpti vieną ilgai išliekančią privilegijuotą išimtį. Išvadas naudokite vaidmenų bazinėms konfigūracijoms, jungčių elgsenai, atsakomybei ir eskalavimo taisyklėms atnaujinti.
„Secani“ gali palaikyti peržiūrimą kontrolės įrašą, susiedama reikalavimus su sistemomis, atsakingais asmenimis, įrodymais ir sprendimais. Paskyrų pakeitimus atlikite veiklos tapatybių ir įrenginių sistemose; atitikties darbo erdvę naudokite taikymo sričiai, įkeltiems rezultatams, išimtims ir peržiūros sprendimams išsaugoti. Prieš remdamiesi bet kokiomis DI padedamomis įrodymų išvadomis, jas turėtų patvirtinti žmonės tikrintojai.
Pradėkite nuo vienos reprezentatyvios komandos ir neseniai atėjusio, perkelto bei išėjusio darbuotojo atvejų. Atsekite kiekvieną įvykį nuo pranešimo iki faktinės sistemos būsenos. Ištaisykite pirmą aptiktą perdavimo tašką ar prieigos kelią, priskirkite jam atsakingą asmenį ir prieš plėsdami procesą jį pakartotinai patikrinkite.
Secani sujungia aprėptis, įrodymus, užduotis ir DI agentus vienoje bendroje darbo erdvėje.
Susiekite kritines paslaugas su atkūrimo tikslais, priklausomybėmis, pratybomis ir taisomaisiais veiksmais, kad tęstinumo planai atspindėtų faktinius gebėjimus.
Peržiūrėkite debesijos tapatybes, pažeidžiamumą, šifravimą, atkūrimą ir žurnalų registravimą remdamiesi įrodymais, susietais su faktinėmis paskyromis, paslaugomis ir duomenimis.
Derinkite pasikartojančias technines patikras ir periodinį vertinimą, aiškiai apibrėždami aprėptį, duomenų rinkimo būklę, ribines vertes ir atsakomybę už tolesnius veiksmus.