Pienākšana, pārcelšana un aiziešana: piekļuvei jābūt pārskatatbildīgai

Piekļuves izmaiņas ir ne tikai tehniska, bet arī koordinācijas problēma. Identitāšu platforma nevar noņemt līgumdarbinieka kontu, ja neviens nepaziņo īpašniekam, ka līgums ir beidzies. Tāpat savlaicīgs personāla nodaļas paziņojums nepierāda, ka katra lietotne ir pārstājusi pieņemt personas akreditācijas datus.

Darbinieku pienākšanai, pārcelšanai un aiziešanai nepieciešams process, kas sasaista biznesa notikumu ar apstiprinātu piekļuves stāvokli, izpilda nepieciešamās izmaiņas un pārbauda rezultātu. No tehniskās vadības skatpunkta svarīgais jautājums nav, vai pastāv darba attiecību izbeigšanas kontrolsaraksts. Svarīgi ir tas, vai process aptver sistēmas, ko cilvēki faktiski izmanto, apstrādā kļūmes un atstāj pierādījumus par to, kas un kad mainījās.

Definējiet dzīves ciklu un tā nodošanas punktus

Uztveriet katru dzīves cikla notikumu kā izmaiņu personas atļautajā piekļuvē, nevis vienkārši kā pieteikumu konta izveidei vai atspējošanai. Notikuma ierakstā jānorāda persona, darba vai sadarbības statuss, vadītājs vai sponsors, spēkā stāšanās datums un laiks un ietekmētā loma. Izmantojiet stabilu identifikatoru, nevis paļaujieties tikai uz vārdiem vai e-pasta adresēm.

Darbinieku notikumus bieži iniciē personāla nodaļa. Līgumdarbinieku notikumus var iniciēt iepirkumu atbildīgais, projekta vadītājs vai iekšējais sponsors. Katrai personu grupai izvēlieties autoritatīvu avotu un definējiet, kā labojumi, atcelti darba sākumi, līgumu pagarinājumi un steidzamas aiziešanas nonāk līdz IT.

Nošķiriet četrus pienākumus pat tad, ja nelielā komandā vairākus no tiem uztic vienai personai:

Nosauciet aizvietotājus un eskalācijas ceļu. Plānota aiziešana nedrīkst būt atkarīga no viena administratora pieejamības. Sensitīvām izmaiņām neatkarīgs pārskatītājs nodrošina noderīgu pārbaudi; ja personāla trūkums to neļauj, dokumentējiet kārtību un izmantojiet vēlāku pārskatīšanu.

Katram notikumam definējiet pabeigšanas kritērijus. Jauns darbinieks ir gatavs, kad apstiprinātā piekļuve un nepieciešamās ierīču kontroles ir pārbaudītas. Pārcelšana ir pabeigta, kad pārbaudīti gan papildinājumi, gan atsaukumi. Aiziešana ir pabeigta, kad piekļuves ceļi ir atsaukti un neatrisinātiem aktīvu, datu vai akreditācijas datu jautājumiem ir skaidri īpašnieki.

Šie ir praktiski kontroļu izstrādes ieteikumi, nevis universāli likumā noteikti termiņi. ISO 27001 ISMS ietvaros piekļuves kontrolēm jāatspoguļo organizācijas tvērums un riska apstrāde. Plašāku kontroļu kontekstu skatiet rakstā ISO 27001 A pielikums praksē.

Nosakiet pārklājumu, pirms automatizējat izmaiņas

Sāciet ar lietotņu sarakstu. Katrai sistēmai reģistrējiet tās īpašnieku, identitātes avotu, piekļuves piešķiršanas metodi, autentifikācijas metodi, atbalstītās atsaukšanas darbības un pārbaudes metodi. Iekļaujiet centralizēti pārvaldītas lietotnes un lietotnes ar lokāliem kontiem.

Vienotā pieteikšanās nenozīmē obligāti pilnu dzīves cikla pārvaldību. Lietotne var autentificēt caur identitātes nodrošinātāju, vienlaikus uzturot lokālus administratorus, API atslēgas, aktīvas sesijas vai atkopšanas iespējas. Piekļuves piešķiršanas savienotājs var atspējot lietotāju, nenoņemot visas tiesības. Dokumentējiet, ko katrs mehānisms faktiski dara.

Iekļaujiet šos mazāk redzamos piekļuves ceļus:

• Priviliģētos kontus, kas ir atsevišķi no personas ikdienas konta.
• VPN piekļuvi, sertifikātus, SSH atslēgas un attālinātā atbalsta rīkus.
• Personiskās piekļuves pilnvaras, API akreditācijas datus un lietotņu paroles.
• Koplietojamus akreditācijas datus, ko persona zināja vai varēja iegūt.
• Viesu kontus, ārējās sadarbības vietas un klientu pārvaldītas vides.
• Pakalpojumu identitātes, kuru īpašnieks vai akreditācijas datu turētājs mainās.

Neatspējojiet automātiski katru pakalpojuma identitāti, kas saistīta ar aizejošu darbinieku: tā var darbināt ražošanas slodzi. Tā vietā nododiet īpašumtiesības, pārskatiet atļaujas un attiecīgā gadījumā nomainiet atklātos akreditācijas datus. Mērķis ir noņemt personas piekļuvi, neradot novēršamu pārtraukumu.

Periodiski saskaņojiet sarakstu ar identitāšu eksportiem, ierīču ierakstiem, iepirkumu ierakstiem un komandu deklarācijām. Neviens atsevišķs avots ne vienmēr atklās katru lietotni. Nepārvaldītiem atradumiem jānonāk dzīves cikla procesā, nevis jāpaliek neformāliem izņēmumiem.

Jauni darbinieki: piešķiriet kontrolētu sākuma stāvokli

Veidojiet lomu bāzes līnijas ar ierobežotiem izņēmumiem

Definējiet piekļuves paketes ap pienākumiem, nevis tikai amatu nosaukumiem. Atbalsta analītiķim var būt nepieciešama piekļuve klientu pieteikumiem, bet ne norēķinu eksportiem. Programmatūras inženierim var būt nepieciešami pirmkoda repozitoriji un izstrādes vides, pēc noklusējuma nesaņemot ražošanas administrēšanu.

Katrai bāzes līnijai jābūt īpašniekam, versijai, iekļautajām grupām vai tiesībām un pārskatīšanas datumam. Reģistrējiet, kura versija tika piemērota jaunajam darbiniekam. Pretējā gadījumā vēlāka lomas atjaunināšana apgrūtina vēsturisko piekļuves lēmumu rekonstruēšanu.

Pieprasiet papildu piekļuvi atsevišķi. Pieprasījumā jānorāda biznesa mērķis, apstiprinošais sistēmas vai datu īpašnieks, atļaujas līmenis un attiecīgā gadījumā derīguma termiņš. Izvairieties no esoša darbinieka pilna atļauju kopuma kopēšanas: tas var atkārtot uzkrātos izņēmumus un privilēģijas no iepriekšējām lomām.

Ja tas ir noderīgi, sagatavojiet kontus pirms darba sākuma datuma, bet kontrolējiet aktivizēšanu. Atcelta pieņemšana darbā izraisa sagatavoto kontu, nosūtīto ierīču un ielūgumu sakopšanu. Līgumdarbiniekiem jābūt iekšējam sponsoram un beigu vai pārskatīšanas datumam; pagarinājumiem jāprasa apstiprinošs lēmums, nevis jāļauj piekļuvei klusi kļūt pastāvīgai.

Nosakiet ierīces un autentifikācijas bāzes līniju

Reģistrējiet ierīces identifikatoru, piešķirto personu, nodošanas datumu un reģistrāciju pārvaldībā. Pirms sensitīvas piekļuves piešķiršanas pārbaudiet attiecīgo bāzes līniju: atbalstītu operētājsistēmu, ielāpu statusu, diska šifrēšanu, ekrāna bloķēšanu, galiekārtas aizsardzību un apstiprinātu autentifikācijas iestatījumu.

Tās ir uz risku balstītas ieviešanas izvēles, nevis apgalvojums, ka katrai organizācijai jāizmanto identiski iestatījumi. Personiskajām ierīcēm skaidri definējiet atļauto piekļuvi un datu apstrādi, nevis uzskatiet tās par līdzvērtīgām pārvaldītiem klēpjdatoriem.

Ja iespējams, izmantojiet datētus novērojumus no ierīču pārvaldības sistēmām. Manuāls saraksts joprojām var būt noderīgs, ja tas ir saskaņots un pamatots ar pierādījumiem; arī reāllaika sarakstam nepieciešama rūpīga pārbaude, ja ierīce ir pārstājusi ziņot. Saglabājiet novērojumu laikus, lai vecs veselīgs statuss netiktu sajaukts ar pašreizēju apliecinājumu.

Pārbaudiet autentifikācijas reģistrāciju un sākotnējo akreditācijas datu nodošanu. Ja jūsu politika prasa daudzfaktoru autentifikāciju, pārliecinieties, ka tā ir aktīva pirms piekļuves sākuma, nevis reģistrējiet tikai to, ka nosūtīts reģistrācijas ielūgums. Neglabājiet akreditācijas datus un atkopšanas kodus dzīves cikla pieteikumos.

Pārcelšana: noņemiet veco lomu, nevis tikai pievienojiet jauno

Pārcelšana bieži ir vissarežģītākais dzīves cikla notikums, jo persona joprojām ir nodarbināta un tās esošais konts turpina darboties. Jaunajai piekļuvei tiek pievērsta uzmanība, jo trūkstošas atļaujas traucē darbu. Vecā piekļuve var saglabāties bez jebkādiem redzamiem simptomiem.

Uztveriet pārcelšanu kā trīs stāvokļu salīdzinājumu: pašreizējā piekļuve, apstiprinātā jaunā bāzes līnija un apstiprinātie turpināmie izņēmumi. Nosakiet, kuras tiesības jāpievieno, jāsaglabā, jāsamazina vai jānoņem. Pārbaudiet tiešos piešķīrumus, kā arī grupas, ligzdotas dalības, administratīvās lomas un lokālās lietotņu atļaujas.

Iepriekšējam vadītājam jāpalīdz identificēt pienākumi, kas ir beigušies. Jaunais vadītājs apstiprina jaunos pienākumus, bet sistēmu vai datu īpašnieki apstiprina sensitīvu piekļuvi. Tas novērš, ka jauns vadītājs netieši atļauj saglabāt piekļuvi citas nodaļas informācijai.

Pārejas periods var būt leģitīms. Kādam, kurš pāriet no finanšu nodaļas, var būt nepieciešama ierobežota piekļuve, lai pabeigtu darbu nodošanu. Reģistrējiet konkrēto atļauju, pamatojumu, apstiprinošo īpašnieku un derīguma termiņu. Ja iespējams, aizstājiet plašu rakstīšanas piekļuvi ar šaurāku vai tikai lasīšanas piekļuvi. Derīguma termiņu iestrādājiet izpildāmā uzdevumā vai sistēmas iestatījumā, nevis tikai komentārā.

Izmaiņas var ietekmēt arī ierīces, koplietojamas pastkastes, datu īpašumtiesības un priviliģētus pienākumus. Pāreja uz administratīvu lomu nedrīkst automātiski pārvērst ikdienas kontu par priviliģētu identitāti.

Pēc izpildes salīdziniet faktisko piekļuves kopumu ar paredzēto rezultātu. Pārcelšanas gadījumā uz citu nodaļu jaunās lomas piešķiršana var būt viegla. Svarīgā pārbaude ir, vai saglabājusies vecā finanšu, klientu vai administratīvā piekļuve. Pārcelšanas izlase, kas pārbauda tikai jauno piešķiršanu, palaiž garām šo risku.

Aiziešana: koordinējiet atsaukšanu, aktīvus un darbības nepārtrauktību

Nosakiet laiku atbilstoši riskam un apstākļiem

Reģistrējiet atsaukšanas spēkā stāšanās laiku, ieskaitot laika joslu. „Pēdējā diena” ir pārāk neskaidri izkliedētām komandām un ieplānotai automatizācijai. Nošķiriet plānotu aiziešanu no steidzamas atlaišanas, aizdomām par apdraudējumu vai negaidītas prombūtnes, kas prasa pagaidu apturēšanu.

Saskaņojiet laiku ar personāla nodaļu un attiecīgo vadību. Ierobežojiet sensitīvu informāciju par darba attiecību izbeigšanu tikai tiem, kam tā nepieciešama, vienlaikus nodrošinot, ka izpildītāji saņem pietiekami daudz informācijas, lai rīkotos. Augsta riska aiziešanas gadījumā var būt nepieciešama koordinēta tūlītēja rīcība; ikdienišķas aiziešanas var pieļaut plānotu darbu nodošanu pirms piekļuves beigām.

Neļaujiet datu nodošanai vai ierīču nosūtīšanai aizkavēt atsaukšanu. Šīm darbībām var būt atsevišķi pabeigšanas datumi un īpašnieki. Ja ierosinātājs pienāk novēloti, reģistrējiet paredzēto beigu brīdi, faktisko izpildi un atklātības intervālu, nevis mainiet dokumentus, lai notikums izskatītos savlaicīgs.

Slēdziet visus attiecīgos piekļuves ceļus

Atspējojiet primāro identitāti un izpildiet lietotnēm specifiskās darbības no saraksta. Attiecīgi risiniet aktīvās sesijas, atsvaidzināšanas pilnvaras, lokālos kontus, priviliģētos kontus, attālināto piekļuvi, sertifikātus un personiskos akreditācijas datus. Centrālā konta atspējošana nepierāda, ka katra esošā sesija vai neatkarīgi izsniegts akreditācijas dats ir kļuvis nelietojams.

Atbilstoši riskam nomainiet koplietojamos noslēpumus, kuriem persona varēja piekļūt, un pārbaudiet, vai nomaiņa netraucēs atkarīgās sistēmas. Noņemiet atkopšanas metodes vai deleģētās atļaujas, kas varētu atjaunot piekļuvi. Ja ir iesaistītas klientu vai piegādātāju vides, pieprasiet atsaukšanu no to īpašnieka un saglabājiet apstiprinājumu.

Fiksējiet atsevišķus rezultātus. Savienotāja noildze nav veiksmīga slēgšana tikai tāpēc, ka kopējais uzdevums ir pabeigts. Novirziet kļūmes nosauktam reaģētājam, izmantojiet apstiprinātu rezerves risinājumu un pārbaudiet galīgo stāvokli. Steidzamai neatrisinātai piekļuvei jānonāk drošības eskalācijas procesā.

Atgūstiet ierīces, nepieņemot, ka attālinātās komandas izdevās

Izsekojiet katru piešķirto aktīvu līdz atgriešanai, pārbaudei un apstiprinātai atiestatīšanai vai utilizācijai. Attālināti strādājošajiem reģistrējiet nosūtīšanas kārtību un neatrisinātos glabāšanas jautājumus. Noņemiet fizisko piekļuvi un attiecīgā gadījumā atgūstiet žetonus vai atslēgas.

Ja atgriešana aizkavējas, izmantojiet pieejamās bloķēšanas vai dzēšanas kontroles atbilstoši politikai un riskam. Nošķiriet komandas izsniegšanu no tā, ka ierīce to apstiprina un izpilda. Bezsaistē esošs klēpjdators var komandu nesaņemt. Novērtējiet atlikušo atklātību, izmantojot šifrēšanas statusu, lokālos akreditācijas datus, kešatmiņā saglabātos datus un pieejamos tīkla ierobežojumus, nevis uzskatiet „dzēšana ierindota” par dzēšanas pierādījumu.

Saglabājiet nepieciešamos datus un atgūstiet licences

Piešķiriet pēcteci biznesa dokumentiem, repozitorijiem, koplietojamām darba plūsmām un pakalpojumu īpašumtiesībām. Izmantojiet atļautus administratīvās nodošanas mehānismus, nevis lūdziet kādam uzdoties par bijušo darbinieku. Ierobežojiet piekļuvi pastkastei vai failiem, reģistrējiet mērķi un ierobežojiet personu loku, kas to saņem.

Nošķiriet piekļuves atsaukšanu, licenču atgūšanu, glabāšanu un dzēšanu. Licences noņemšana dažādās lietotnēs var atšķirīgi ietekmēt datu pieejamību. Pirms neatgriezeniskas sakopšanas pārbaudiet glabāšanas prasības un jebkādu juridisku saglabāšanas pienākumu.

Attiecībā uz personas datiem VDAR 5. pants nosaka glabāšanas ierobežojumu; tas nerada vienu universālu darbinieku kontu dzēšanas termiņu. Definējiet pamatotus glabāšanas periodus un sakopšanas pienākumus. 32. pants prasa riskam atbilstošus drošības pasākumus, tāpēc dokumentējiet darba attiecību izbeigšanas kontroļu pamatojumu, nevis uzskatiet kontrolsarakstu pašu par sevi par juridisku atbilstību.

Saglabājiet pierādījumus par faktiskajām izmaiņām

Noderīgais ieraksts sasaista atļauto lēmumu ar novēroto rezultātu. Saglabājiet notikumu, apstiprinājumu, ietekmētās sistēmas, izpildes laikus, pārbaudes rezultātus un izņēmumu apstrādi. Iekļaujiet paredzēto spēkā stāšanās laiku, lai pārskatītāji varētu novērtēt savlaicīgumu.

Praktiska pierādījumu pakete ietver:

• Stabilu personas un notikuma identifikatoru ar iniciējošo avotu.
• Apstiprināto bāzes līniju un jebkuras saglabātās vai papildu atļaujas.
• Darbības katrā sistēmā, rezultātus, laika zīmogus un attiecīgās atsauces uz žurnāliem.
• Pārbaudi, kas parāda iegūto piekļuves stāvokli.
• Aktīvu, datu nodošanas un licenču rezultātus, ja attiecas.
• Neizdevušās darbības un izņēmumus ar īpašnieku, termiņu un slēgšanas pierādījumiem.

Politika pierāda nodomu. Pieteikums pierāda koordināciju. Lietotnes rezultāts vai piekļuves eksports palīdz pierādīt ieviešanu. Nevienu no tiem nedrīkst aizstāt ar citu. Ekrānuzņēmumi var būt noderīgi, ja spēcīgāki eksporti nav pieejami, taču tajos jābūt pietiekamam kontekstam, lai identificētu sistēmu, subjektu un novērošanas laiku.

Aizsargājiet šos ierakstus: tie satur informāciju par darba attiecībām un drošības ziņā sensitīvas detaļas. Piemērojiet piekļuves ierobežojumus un glabāšanas grafiku un izvairieties vākt kā pierādījumus paroles, nevajadzīgus darba attiecību izbeigšanas aprakstus vai veselas pastkastes. Vēsturiskajiem ierakstiem jāpaliek saprotamiem arī pēc darbības kontu dzēšanas.

Praktisks piemērs: pārcelšana, kam seko aiziešana

Aplūkosim ilustratīvu uzņēmumu ar centrālu identitātes nodrošinātāju, pārvaldītiem klēpjdatoriem un finanšu lietotni ar lokālām atļaujām. Pieņemsim, ka darbinieks 1. jūnijā pāriet no finanšu operācijām uz klientu panākumu komandu, viņam nepieciešama piecu darba dienu darbu nodošana un vēlāk, 30. septembrī, viņš aiziet. Šie datumi un kārtība ir piemēra pieņēmumi, nevis noteikti termiņi.

Pārcelšanas gadījumā IT fiksē pašreizējās tiesības. Klientu panākumu komandas piekļuve tiek apstiprināta, finanšu rakstīšanas piekļuve tiek noņemta spēkā stāšanās brīdī, un ierobežota finanšu lasīšanas piekļuve tiek saglabāta līdz darbu nodošanas termiņa beigām. Finanšu īpašnieks apstiprina šo izņēmumu. Tā kā finanšu lietotne uztur lokālas atļaujas, tās administrators izpilda un pārbauda izmaiņas atsevišķi no identitātes nodrošinātāja grupas atjauninājuma.

Termiņa beigās pārbaudē konstatē, ka saglabājusies lokāla eksporta atļauja. Pārcelšanas ieraksts paliek atvērts, administrators to noņem, un pārskatītājs reģistrē galīgo stāvokli. Mācība ir konkrēta: lomas maiņa centralizēti izdevās, taču lietotnes atļauju modelis prasīja papildu darbību.

Vēlākajai aiziešanai process nosaka precīzu beigu brīdi, nodod biznesa failus apstiprinātam pēctecim, atspējo identitātes, atsauc attiecīgās sesijas un pilnvaras un tieši pārbauda finanšu kontu. Klēpjdators ar kurjeru vēl nav pienācis. Tā atgriešana paliek aktīvu izņēmums, un ierobežošanas darbības un ierīces novērojumi tiek reģistrēti atsevišķi no konta atsaukšanas.

Iegūtie pierādījumi parāda gan veiksmīgās izmaiņas, gan sākotnējo atsaukšanas kļūmi. Kļūmes slēpšana nozīmētu zaudēt informāciju, kas nepieciešama darba plūsmas uzlabošanai.

Testējiet pārklājumu un padariet nākamo uzlabojumu konkrētu

Pārbaudiet reālu dzīves cikla notikumu izlasi pret lietotņu sarakstu. Iekļaujiet līgumdarbiniekus, priviliģētos lietotājus, attālināti strādājošos, pārceltos darbiniekus ar pagaidu pārklāšanos un lietotnes ārpus identitātes nodrošinātāja. Piekļuves pārskatīšanā jāizvērtē arī tas, vai pašreizējās atļaujas joprojām atbilst katras personas pienākumiem; tā papildina notikumu ierosinātās izmaiņas, nevis tās aizstāj.

Testējiet kļūmju ceļus, ne tikai parasto izpildi: nokavētu personāla nodaļas notikumu, neizdevušos savienotāju, nepieejamu administratoru, aizkavētu ierīces atgriešanu vai atceltu darba sākumu. Pārbaudiet, vai brīdinājumi sasniedz reaģētāju un vai atkārtoti mēģinājumi vai manuālas darbības rada pārbaudāmus rezultātus.

Noderīgi rādītāji ir atsaukšanas kavējums attiecībā pret saskaņoto beigu brīdi, neizdevušās darbības, kas gaida atrisināšanu, nokavēta pagaidu piekļuve un notikumi, kas slēgti bez pārbaudes. Definējiet, ko katrs rādītājs uzskaita. Labs vidējais rādītājs var noslēpt vienu ilgstošu priviliģētu izņēmumu. Izmantojiet konstatējumus, lai atjauninātu lomu bāzes līnijas, savienotāju darbību, īpašumtiesības un eskalācijas noteikumus.

Secani var atbalstīt pārskatāmo kontroļu ierakstu, savienojot prasības ar sistēmām, īpašniekiem, pierādījumiem un lēmumiem. Kontu izmaiņas veiciet operatīvajās identitāšu un ierīču sistēmās; atbilstības darbvietu izmantojiet, lai saglabātu tvērumu, augšupielādētos rezultātus, izņēmumus un pārskatīšanas lēmumus. Cilvēkiem pārskatītājiem jāvalidē visi MI atbalstītie secinājumi par pierādījumiem, pirms uz tiem paļauties.

Sāciet ar vienu reprezentatīvu komandu un nesenu pienākšanas, pārcelšanas un aiziešanas gadījumu. Izsekojiet katru notikumu no paziņojuma līdz faktiskajam sistēmas stāvoklim. Novērsiet pirmo atklāto nodošanas punktu vai piekļuves ceļu, piešķiriet tam īpašnieku un testējiet to atkārtoti, pirms paplašināt procesu.