Šešėlinis IT: aptiktus įrankius paverskite atsakinga nuosavybe

Komanda pradeda naudoti įrankį, nes jis išsprendžia tikrą problemą. Saugumo problema prasideda tada, kai organizacijos inventorius, sutartys ir prieigos procesai šio naudojimo neatspindi. Programa gali tapti esmine verslo proceso dalimi anksčiau, nei kas nors nusprendžia, kas ją administruoja, kokius duomenis joje galima laikyti ar kaip jos atsisakyti.

Šešėlinis IT apima paslaugas, programas ir įrenginius, naudojamus apeinant nustatytus patvirtinimo ar valdymo procesus. Aptikimas turėtų lemti proporcingą sprendimą ir įvardytą atsakingą asmenį, o ne vien ilgesnį įtartinų domenų sąrašą.

Technologijų vadovui tikslas yra praktinis: suprasti priklausomybę, suvaldyti nepriimtiną riziką ir suteikti verslui įgyvendinamą kelią į valdomas technologijas.

Prieš rinkdami signalus apibrėžkite ribas

Šešėlinis IT yra valdymo būklė, o ne iš prigimties nesaugių produktų kategorija. Patikima bendradarbiavimo paslauga gali tapti nevaldoma, kai darbuotojai susikuria asmenines darbo erdves. Asmeninis nešiojamasis kompiuteris gali būti teisėtai naudojamas pagal kontroliuojamą „atsinešk savo įrenginį“ tvarką. Ir atvirkščiai, nupirkta paslauga vis tiek gali būti nevaldoma, jei niekas nekontroliuoja jos administratorių ar prieigos panaikinimo darbuotojams išeinant.

Žiūrėkite toliau nei nežinomų programų pavadinimai. Aktualūs pavyzdžiai:

• Asmeninė debesijos saugykla, susirašinėjimo paskyros ir slaptažodžių tvarkyklės, naudojamos įmonės informacijai.
• Naršyklės plėtiniai, DI susitikimų asistentai ir transkribavimo paslaugos, turinčios prieigą prie įmonės turinio.
• Trečiųjų šalių programos, per OAuth prijungtos prie el. pašto, kalendorių, saugyklų ar failų saugojimo.
• Nevaldomi nešiojamieji kompiuteriai, išimamosios laikmenos, tinklo įrenginiai ir nuotolinės prieigos priemonės.
• Komandoms priklausančios debesijos paskyros, mažo kodo programos ir automatizavimo scenarijai, palaikantys gamybines darbo eigas.

Patvirtintos programos taip pat gali įgyti nevaldomų naudojimo būdų. Nauja integracija, viešo bendrinimo nustatymas ar DI funkcija gali pakeisti pradinį rizikos vertinimą, nepakeitusi produkto pavadinimo.

Pradėkite nuo vieno verslo proceso ar padalinio. Apibrėžkite, kurios paskyros, galiniai įrenginiai, tinklai, tiekėjai ir duomenų srautai patenka į pirmąją peržiūrą. Taip išvados tampa įgyvendinamos, o metodo spragos išryškėja dar prieš pradedant rinkti duomenis visoje organizacijoje.

Susidarykite vaizdą iš kelių šaltinių

Nė vienas aptikimo šaltinis neparodo visų įrankių. Tapatybių įrašuose nėra vietinių paskyrų; išlaidų įrašuose nėra nemokamų paslaugų; tinklo žurnalai gali parodyti paskirties vietą, bet nepaaiškinti, kokia informacija ten pateko.

Naudokite vienas kitą papildančius šaltinius ir išsaugokite kiekvienos išvados kilmę.

Paaiškinkite, kodėl atliekamas aptikimas, kas bus renkama, kas galės tai peržiūrėti ir kiek laiko tai bus saugoma. Laikykitės taikomų privatumo ir darbo teisės taisyklių. Pirmenybę teikite metaduomenims, kurių pakanka paslaugai ir jos prieigai nustatyti, o ne pranešimų turinio, įrašų ar asmeninio naršymo turinio rinkimui. Apribokite prieigą ir prie pačių aptikimo įrašų.

Užduokite komandoms praktinius klausimus: kur dalijatės dideliais failais, įrašote susitikimus, verčiate dokumentus, renkate klientų atsiliepimus ar automatizuojate pasikartojančias užduotis? Paklauskite, kurie įrankiai sutrikdytų darbą, jei rytoj būtų pašalinti. Šie klausimai atskleidžia priklausomybes, kurių domenų sąrašas neparodo.

Prieš skaičiuodami išvadas, jas suvienodinkite. Tiekėjas gali turėti kelis domenus, produktus, darbo erdves ir atsiskaitymo subjektus. Atskirkite produkto tapatybę nuo nuomininko tapatybės ir atskirkite įdiegimo, įgaliojimo, prisijungimo ir patvirtinto verslo naudojimo įrodymus. Neaiškias išvadas fiksuokite kaip kandidatus, užuot skelbę kiekvieną pastebėtą paskirties vietą neleistina programa.

Kiekvieną išvadą paverskite atsakomybės įrašu

Naudingas registras aprašo naudojimą, ne vien tiekėją. Dvi tą patį produktą naudojančios komandos gali turėti skirtingus duomenis, prieigą, sutartis ir pasekmes.

Kiekvienam patvirtintam naudojimui užfiksuokite:

• Produktą, tiekėją, nuomininko ar darbo erdvės identifikatorių ir aptikimo šaltinį.
• Verslo paskirtį, priklausomą procesą, naudotojų grupę ir kritiškumą.
• Duomenų kategorijas, duomenų šaltinius, paskirties vietas, bendrinimo nustatymus ir saugojimą.
• Paskyrų tipus, administratorius, autentifikavimą, integracijas ir suteiktas teises.
• Sutarties turėtoją, prenumeratos planą, atnaujinimo informaciją ir susijusius duomenų tvarkymo susitarimus.
• Verslo savininką, techninį prižiūrėtoją, peržiūrėtoją, siūlomą rizikos tvarkymo būdą ir peržiūros datą.

Verslo savininkas pagrindžia poreikį ir koordinuoja priimtiną naudojimą. Techninis prižiūrėtojas valdo konfigūraciją, prieigą, integracijas ir naudojimo nutraukimą. Saugumo komanda vertina riziką; pirkimų ir privatumo specialistai peržiūri jų kompetencijai priklausančius klausimus. Mažoje organizacijoje šios atsakomybės gali tekti tam pačiam asmeniui, tačiau jos turėtų likti aiškiai įvardytos.

Jei niekas nesiims atsakomybės už paslaugą, nelaikykite jos patvirtinta vien todėl, kad ji patinka naudotojams. Paskirkite laikiną atsakingą rėmėją ir sprendimo terminą. Užfiksuokite, kas lieka nežinoma ir kas tai išsiaiškins.

Sekite ne tik programą, bet ir duomenis. Įrankis gali gauti įkeltus failus, sinchronizuoti ištisus aplankus, kurti transkriptus ar siųsti turinį kitam paslaugų teikėjui. Mūsų duomenų aptikimo vadove paaiškinama, kaip atsekti šiuos ryšius.

OAuth prieigą tikrinkite atskirai nuo programos naudojimo

OAuth leidžia programai gauti įgaliotą prieigą negaunant naudotojo slaptažodžio. Tai naudinga, tačiau įgaliojimas gali būti platesnis ar ilgalaikiškesnis, nei reikia užduočiai. Prisijungimas prie programos ir prieigos prie įmonės išteklių suteikimas jai yra skirtingi įvykiai.

Kiekvienai prijungtai programai, kai įmanoma, patikrinkite leidėjo ar kliento tapatybę, prieigą suteikusį naudotoją, išteklių, aprėptis, sutikimo tipą ir suteikimo datą. Atskirkite deleguotą prieigą, naudojamą naudotojo vardu, nuo programos teisių, kurios gali veikti be interaktyvaus naudotojo. Išnagrinėkite atnaujinimo prieigos raktų elgseną ir tai, ar įgaliojimas gali galioti ir naudotojui nustojus aktyviai naudoti įrankį.

Pirmenybę teikite įgaliojimams, leidžiantiems skaityti pašto dėžutes, keisti failus, pasiekti katalogą, keisti saugyklas ar turėti plačią prieigą prie kelių naudotojų duomenų. Patikrinkite, ar prašomos aprėptys atitinka nurodytą paskirtį. Planavimo įrankis, prašantis prieigos prie kalendoriaus, kelia kitokį klausimą nei įrankis, prašantis pašto dėžutės turinio ir neribotos prieigos prie failų.

Kaip praktinę kontrolės priemonę, kai platforma tai palaiko, didelio poveikio sutikimų suteikimą apribokite administratoriams arba peržiūros darbo eigai. Peržiūrėkite naujai suteiktas teises ir esamų programų pakeitimus, ne tik naujų programų registracijas.

Pašalinus naršyklės plėtinį ar atjungus naudotojui matomą integraciją, gali būti pašalinti ne visi įgaliojimai, prieigos raktai ar išorinės duomenų kopijos. Patikrinkite atšaukimą išteklių platformoje ir tiekėjo paskyroje. Šifruotas perdavimas neįrodo, kad integracija saugi, ir nepadaro bet kokio tikrinimo neįmanomo; matomumas priklauso nuo turimų kontrolės priemonių ir telemetrijos.

Prioritetus nustatykite pagal riziką ir verslo priklausomybę

Rūšiavimą naudokite nuspręsti, kam pirmiausia reikia dėmesio. Nelaikykite kiekvieno nepatvirtinto įrankio vienodai skubiu.

Įvertinkite susijusios informacijos jautrumą ir apimtį, prieigos plotį, išorinį bendrinimą, įrenginių būklę, administracinę kontrolę ir kompromitavimo įrodymus. Taip pat atsižvelkite į prieinamumą: nedokumentuotas automatizavimas gali būti vienintelis būdas siųsti užsakymus tiekėjui.

Viešam dizaino pavyzdžių įrankiui, naudojamam be failų įkėlimo, gali pakakti paprastos registracijos. DI susitikimų asistentui su prieiga prie kalendoriaus, įrašų ir pokalbių su klientais reikia nuodugnesnės teisių, saugojimo, saugojimo terminų ir tolesnio duomenų tvarkymo peržiūros. Nevaldoma nuotolinės prieigos paslauga gamybinėje sistemoje pateisina skubų suvaldymą ir tyrimą.

Užfiksuokite konkretų rizikos scenarijų, o ne „šešėlinio IT riziką“. Pavyzdžiui: „Buvęs darbuotojas išlaiko darbo erdvės administravimo teises ir gali eksportuoti pasiūlymus klientams.“ Toks teiginys nurodo atsakingą asmenį, kontrolės priemonės pakeitimą ir bandymą.

Aptikimas savaime nėra pažeidimo įrodymas. Jei išvados rodo neteisėtą atskleidimą ar kompromitavimą, pereikite prie incidentų proceso, išsaugodami susijusius žurnalus. Kai susiję asmens duomenys, pranešimo vertinimas priklauso nuo aplinkybių ir organizacinio vaidmens pagal BDAR 33 ir 34 straipsnius, o ne vien nuo to, ar įrankis buvo patvirtintas.

Pasirinkite verslo poreikį išsaugantį rizikos tvarkymo būdą

Kiekvienam sprendimui reikia atsakingo asmens, pagrindimo, užbaigimo kriterijų ir tolesnių veiksmų. Praktikoje naudingi keturi rizikos tvarkymo būdai.

Patvirtinti ir įtraukti į valdymą

Patvirtinimas turėtų aprašyti leidžiamą naudojimą, o ne suteikti neribotą leidimą naudoti produktą. Užtikrinkite įmonės kontroliuojamą administravimą, tinkamą autentifikavimą, mažiausių privilegijų prieigą, darbuotojų atėjimo, perkėlimo ir išėjimo tvarkymą bei palaikomą konfigūraciją. Registravimą žurnaluose, bendrinimo apribojimus, atkūrimo ar eksporto galimybes ir saugojimą patikrinkite pagal naudojimo atvejį.

Kai taikoma, peržiūrėkite tiekėją ir sutartį. Jei tiekėjas organizacijos vardu tvarko asmens duomenis, įvertinkite reikalingus duomenų tvarkytojo susitarimus pagal BDAR 28 straipsnį. Tarptautinio perdavimo tvarkai reikia atskiro vertinimo; pasirinktas talpinimo regionas neišsprendžia visų klausimų. 32 straipsnio saugumo priemonės grindžiamos rizika, o ne yra visuotinis kontrolinis sąrašas, įvykdomas vienu nustatymu.

Išsaugokite patvirtinimo įrodymus: konfigūracijos eksportus, administratorių paskyrimus, prieigos bandymus, sutarties peržiūrą ir prisiimtą liekamąją riziką.

Pakeisti tinkama alternatyva

Pakeitimas veikia tik tada, kai alternatyva atitinka faktinį poreikį. Prieš įpareigodami pereiti, išbandykite failų dydžio ribas, išorinį bendradarbiavimą, prieinamumą, automatizavimą ir reikiamas integracijas.

Apibrėžkite perkėlimo seką, suderinkite įrašus ir patvirtinkite, kad naudotojai gali užbaigti darbo eigą. Išsaugokite privalomus įrašus ir susijusius metaduomenis. Po perjungimo patikrinkite bendrinimo nuorodas ir integracijas, o tada uždarykite seną nuomininką, o ne tik nustokite mokėti.

Pašalinti nepagrįstą naudojimą

Įrankiui be pagrįstos paskirties arba su nepriimtina rizika sustabdykite naują naudojimą ir suplanuokite pašalinimą. Atšaukite įgaliojimus ir prieigos raktus, pašalinkite plėtinius ar programinę įrangą, išjunkite paskyras, uždarykite bendrinimo nuorodas ir pasirūpinkite jau eksportuotais duomenimis. Kai tai pateisina išvados, pakeiskite atskleistus prisijungimo duomenis.

Paskyros ištrynimas neįrodo, kad visa tiekėjo turima informacija išnyko. Gaukite turimus ištrynimo įrodymus ir dokumentuokite sutartinį saugojimą, atsargines kopijas ar kitus apribojimus. Išsaugokite informaciją, kuriai taikomas privalomas saugojimas ar teisinis sulaikymas.

Leisti kontroliuojamą laikiną išimtį

Verslui kritiniam įrankiui gali reikėti pereinamojo laikotarpio. Nurodykite leidžiamus naudotojus ir duomenis, kompensacines kontrolės priemones, atsakingą rizikos prisiėmėją, galiojimo pabaigą ir pasitraukimo sąlygas. Kai įmanoma, apribokite tolesnį plėtimą. Nuolatinė „laikina“ išimtis be peržiūros yra neišspręsta valdymo spraga.

Pavyzdys: DI susitikimų asistentas

Panagrinėkime iliustracinę organizaciją, peržiūrinčią savo pardavimų procesą. Tarkime, kad aštuoni darbuotojai per asmenines paskyras naudoja nemokamą susitikimų asistentą. Pokalbiai patvirtina, kad jis įrašo skambučius su klientais; tapatybių eksportas rodo kalendoriaus įgaliojimus. Pirkimo įrašo nėra, o pardavimų vadovas remiasi transkriptais perduodant klientus.

Pirmasis sprendimas – sustabdyti papildomus įrašus ir naujų naudotojų prisijungimą, kol nustatoma, kas buvo užfiksuota. Saugumo komanda užfiksuoja įgaliojimus ir paskyrų tapatybes. Vadovas nustato paveiktus susitikimus ir veiklos poreikį. Privatumo ir pirkimų specialistai peržiūri duomenų tvarkymo susitarimus, informaciją dalyviams, tiekėjo sąlygas, saugojimą ir bet kokią susijusią perdavimo tvarką. Komanda taip pat patikrina, ar įrašai ar transkriptai yra viešai prieinami ir ar paslauga naudoja turinį kitais tikslais.

Tarkime, kad peržiūra parodo, jog nemokamas planas negali užtikrinti įmonės kontroliuojamo administravimo ar reikiamų saugojimo nustatymų. Sprendimas yra pakeitimas, o ne klientų perdavimo proceso atsisakymas. Pardavimų komanda išbando patvirtintą alternatyvą su tinkamomis prieigos ir įrašymo kontrolės priemonėmis, o techninis prižiūrėtojas atšaukia senus kalendoriaus įgaliojimus ir perkelia leidžiamus įrašus.

Užbaigimo įrodymai apima paveiktų paskyrų sąrašą, pakaitalo konfigūraciją, įgaliojimų atšaukimo rezultatus, senų bendrinimo nuorodų patikras ir turimus ištrynimo patvirtinimus. Bet koks neišspręstas atsarginių kopijų saugojimo apribojimas lieka užfiksuotas. Pardavimų vadovas atsako už priimtiną naudojimą; IT atsako už konfigūraciją ir prieigos panaikinimą. Peržiūra baigiasi valdomu procesu, o ne vien užblokuota programa.

Užkirskite kelią kitai aklajai zonai patogiu priėmimo procesu

Komandos dažnai pradeda naudoti įrankius, kad apeitų lėtus patvirtinimus, trūkstamas funkcijas ar nepatogumus esamose sistemose. Aptikimas turėtų nustatyti šias priežastis. Kitaip pašalinimas tiesiog perkels tą pačią veiklą į dar mažiau matomą vietą.

Padarykite prašymų pateikimą paprastą. Prašykite nurodyti paskirtį, naudotojus, duomenų kategorijas, integracijas, skubumą ir verslo savininką. Paskelbkite kriterijus, inicijuojančius nuodugnesnę peržiūrą, ir numatykite praktinį kelią mažos rizikos bandymams. Suteikite prašymų teikėjams būseną ir numatomą sprendimo laiką; nepalikite prašymų nepaaiškinamoje eilėje.

Mokykite konkretaus elgesio: paklauskite prieš prijungdami paslaugą prie įmonės el. pašto, neįkelkite klientų informacijos į neperžiūrėtą įrankį ir praneškite apie esamą darbo erdvę prieš ją atnaujindami. Suteikite komandoms atskleidimo kelią, orientuotą į spragų taisymą, o ne į sąžiningo pranešimo baudimą.

Toliau stebėkite pokyčius ir po patvirtinimo. Peržiūrėkite naujus OAuth įgaliojimus, administravimo pakeitimus, išorinį bendrinimą, naujai įjungtas DI funkcijas ir plėtimą į jautresnius duomenis. Praktiškai rekomenduojama įvykių inicijuojamas patikras derinti su periodiniu atsakingo asmens patvirtinimu. Peržiūrų dažnumas turėtų atspindėti riziką ir verslo kritiškumą, o ne visuotinį intervalą.

Padarykite įrodymus naudingus ISMS

ISO/IEC 27001 susijęs su apibrėžtos taikymo srities informacijos saugumo valdymo sistema. Šešėlinio IT išvados gali papildyti turto valdymą, tiekėjų peržiūrą, prieigos kontrolės priemones, rizikos vertinimą ir rizikos tvarkymą. Kontrolės priemonės ir toliau parenkamos remiantis rizika; programų sąrašas nėra nei ISMS, nei įrodymas, kad kontrolės priemonės veikia.

Atskirkite aptikimo apimtį, vertinimą, sprendimą dėl rizikos tvarkymo, įgyvendinimo įrodymus ir veiksmingumo patikrą. Uždaryta užduotis su įrašu „pašalinta“ yra silpnesnis įrodymas nei atšaukta prieiga kartu su išbandytu rezultatu. Rizikos prisiėmime turėtų būti nurodyta, kas turėjo įgaliojimus ją prisiimti ir kada ją reikia persvarstyti. Sertifikavimas savaime neįrodo atitikties BDAR.

Secani suteikia susietą darbo erdvę sistemoms ir paslaugoms modeliuoti, įrodymams susieti su reikalavimais ir sprendimais bei atsakingiems asmenims ir peržiūros užduotims paskirti. Aptikimą ir vykdymo užtikrinimą palikite tinkamose veiklos sistemose, o susijusius eksportus, peržiūras ir patvirtinimus perkelkite į šį atitikties kontekstą. DI padedamus pasiūlymus laikykite juodraščiais, kuriuos turi peržiūrėti žmonės, išsaugodami šaltinių atsekamumą.

Kitai peržiūrai pasirinkite vieną verslo procesą ir suderinkite jo tapatybių, išlaidų, galinių įrenginių ir pokalbių išvadas. Kiekvieną patvirtintą išvadą užbaikite įvardytu atsakingu asmeniu, rizikos tvarkymo būdu, terminu ir užbaigimo patikra. Naudingi rodikliai apima atsakingų asmenų aprėptį, vėluojančius sprendimus, besibaigiančias išimtis ir užbaigtas prieigos panaikinimo patikras, o ne vien aptiktų įrankių skaičių.