Eelmisel kuul kirjutasin artikkel selle kohta, kuidas madala koodiga/koodita platvormid pakuvad mandaadi jagamist teenusena, miks nad seda teevad ja kuidas see välja näeb ründaja vaatenurk. Selles artiklis keskendun selle kompromissi tagajärgedele ja sellele, kuidas see praegu ettevõtteid mõjutab.
Siin on põhjus, miks oma ettevõtte mandaatide jagamine kellegi teisega on halb tava. Oletame, et tahan edastada oma mandaadid kolleegile, et teha päring tootmislogidest ühekordse kasutaja käitumise analüüsi jaoks. Tavalises ettevõttes võib kellelegi uue andmeallika päringu tegemiseks loa andmine tähendada pikka juurdepääsu ülevaatusprotsessi, eriti kui tegemist on tootmis- või tundlike andmetega. Mu kolleeg võib kergesti pettuda. "Ma tahtsin ainult seda pisikest ühekordset päringut teha ja olen juba kuu aega oodanud!" nad võiksid öelda. Võiksin lihtsalt nende jaoks päringu käivitada, kuid olen oma igapäevaste ülesannetega uppunud ja ühekordsed päringud kipuvad muutuma keeruliseks.
Mul on jäänud üks kiire lahendus: võin lihtsalt oma kasutajanime/parooli kolleegiga jagada. Kui nad saavad MFA väljakutse, kiidan selle hea meelega heaks. Ma ei pea kulutama aega päringu käitamiseks ja mu kolleeg blokeeritakse. Kõik võidavad! eks?
Noh, teil oleks oma analüüsis õigus, kuid teil jääb suurem pilt puudu. Kuigi ettevõtte jaoks on oluline, et teie kolleeg saaks oma kasutajakäitumise analüüsi tehtud, on sama, kui mitte veelgi olulisem, et teie ettevõte järgiks paljusid privaatsus- ja turvastandardeid ning säilitaks klientide usalduse, säilitades ettevõtte turvalisuse tagamise kohustuse. .
Kui ettevõtte kõrgetasemelised eesmärgid teid ei veena, kaaluge IT- või turbevaldkonna keskjuhtimismeeskondi. Need meeskonnad põhinevad oma tegevuses ja turvastrateegiates asjaolul, et igal kasutajal on oma ainulaadne identiteet. IT-meeskonnad seadistavad võrgu- ja juurdepääsupoliitikaid, mis eeldavad, et iga kasutaja logitakse korraga sisse ühest ettevõtte IP-st või ettevõtte sülearvutist; turvameeskonnad korreleerivad sündmusi kasutajatunnuse alusel; finantsmeeskonnad võiksid koondada kuluaruandeid kasutaja ja isikliku pilvekeskkonna kohta. Mandaatide jagamine õõnestab muu hulgas kõiki neid eeldusi. See eemaldab veebiidentiteedi põhitähenduse.
Näide reaalsest maailmast
Pöördume madala koodi/koodita maailma poole ja uurime reaalset stsenaariumi. Ühes suurettevõttes mõistis klienditeenindusmeeskonna inspireeritud töötaja Jane, et kui töötajad kogu organisatsioonis osalevad kliendijuhtumis, on neil tavaliselt puudu põhiteave kliendi kohta, nagu nende tugijuhtumite ajalugu ja viimased ostud. See halvendab kliendi kogemust, kuna ta peab oma probleemi ikka ja jälle selgitama, samal ajal kui juhtum suunatakse õigele töötajale, kes saab probleemiga tegeleda.
Selle parandamiseks lõi Jane rakenduse, mis võimaldab ettevõtte töötajatel vaadata seda olulist klientide kohta käivat teavet, kui need töötajad on osa meeskonnast, kes vastutab kliendi tugijuhtumi lahendamise eest. Esiteks, võtame hetke, et tunnistada madala koodi/koodita võimsust, mis võimaldab Jane'il vajaduse tuvastada ja sellega iseseisvalt tegeleda, ilma eelarvet küsimata või IT-ressursside eraldamist ootamata.
Rakenduse loomise ajal pidi Jane lahendama mitmeid probleeme, millest suurim oli load. Kogu organisatsiooni töötajatel ei ole otsest juurdepääsu kliendiandmebaasi päringute tegemiseks, et saada vajalikku teavet. Kui nad seda teeksid, ei peaks Jane seda rakendust looma. Selle probleemi lahendamiseks logis Jane sisse andmebaasi ja manustas oma autentitud seansi otse rakendusse. Kui rakendus saab ühelt kasutajalt päringu, kasutab see päringu täitmiseks Jane'i identiteeti ja tagastab seejärel tulemused kasutajale. See mandaadi manustamise funktsioon, nagu me eelmisel kuul uurisime, on madala koodi/koodita platvormide põhifunktsioon. Jane seadistas rakenduses kindlasti rollipõhise juurdepääsukontrolli (RBAC), nii et igal kasutajal on juurdepääs ainult neile määratud kliendijuhtumitele.
Rakendus lahendas olulise äriprobleemi ja leidis seetõttu kiiresti kasutajate omaksvõtu kogu ettevõttes. Inimesed olid õnnelikud, et saavad oma kliente paremini teenindada, kui neil on vestluse jaoks õige kontekst. Ka kliendid olid rahul. Kuu aega pärast Jane'i rakenduse loomist kasutasid seda juba sajad kasutajad kogu organisatsioonis ning klientide rahulolu määr kasvas.
Samal ajal käivitati SOC-s kõrgetasemeline hoiatus, mis näitas ebatavalist tegevust tootmisklientide andmebaasis ja määrati kogenud turbeanalüütikule Amyle. Amy esialgne uurimine näitas, et sisekasutaja üritas kogu andmebaasi kraapida, küsides teavet mitme kliendi kohta organisatsiooni mitmelt IP-aadressilt. Päringu muster oli väga keeruline; lihtsa loendusmustri asemel, mida võiksite näha andmebaasi kraapimisel, küsiti sama kliendi andmeid mitu korda, mõnikord erinevate IP-aadresside kaudu ja erinevatel kuupäevadel. Kas see võib olla ründaja, kes üritab turvaseiresüsteeme segadusse ajada?
Pärast kiiret uurimist avastas Amy üliolulise teabe: kõik need päringud kõigil IP-aadressidel ja kuupäevadel kasutasid ühte kasutajaidentiteeti, keegi nimega Jane klienditeeninduse meeskonnast.
Amy pöördus Jane poole, et küsida, mis toimub. Alguses Jane ei teadnud. Kas tema volikirjad varastati? Kas ta klõpsas valel lingil või usaldas valet sissetulevat meili? Kuid kui Jane rääkis Amyle hiljuti loodud rakendusest, mõistsid nad mõlemad, et seos võib olla. SOC-i analüütik Amy polnud madala koodi/koodita koodiga kursis, mistõttu nad pöördusid AppSeci meeskonna poole. Jane'i abiga sai meeskond aru, et Jane'i rakenduses olid Jane'i volikirjad. Andmebaasi vaatenurgast ei olnud ühtegi rakendust – oli vaid Jane, kes täitis palju päringuid.
Jane, Amy ja AppSeci meeskond otsustasid rakenduse kuni lahenduse leidmiseni sulgeda. Rakenduste kasutajad kogu organisatsioonis olid pettunud, kuna nad hakkasid sellele lootma, ja ka kliendid tundsid seda.
Kuigi Amy lõpetas probleemi ja dokumenteeris oma leiud, ei olnud klienditeeninduse asepresident rahul, nähes klientide rahulolu langust, mistõttu nad palusid Jane'il otsida püsivat lahendust. Jane eemaldas platvormi dokumentatsiooni ja organisatsiooni tippkeskuse meeskonna abiga rakendusest oma manustatud identiteedi, muutis rakendust nii, et see kasutaks andmebaasi päringute tegemiseks iga kasutaja identiteeti ja tagas, et kasutajad saavad õigused ainult nendele klientide juhtumitele, millega nad on seotud. . Uues ja täiustatud versioonis kasutas rakendus klientide andmebaasi päringute tegemiseks iga kasutaja identiteeti. Jane ja rakenduse kasutajad olid õnnelikud, et rakendus on taas võrgus, Amy ja AppSeci meeskond olid õnnelikud, et Jane'i identiteeti enam ei jagata, ning ettevõte nägi, et klientide rahulolu hakkas taas tõusma. Kõik oli hästi.
Kaks nädalat hiljem sai SOC uue hoiatuse ebatavalise juurdepääsu kohta tootmisklientide andmebaasile. See nägi kahtlaselt sarnane sama andmebaasi eelmise hoiatusega. Jällegi kasutasid kogu organisatsiooni IP-aadressid andmebaasi päringute tegemiseks ühe kasutaja identiteeti. Jällegi oli see kasutaja Jane. Kuid seekord teadsid turvameeskond ja Jane, et rakendus kasutab oma kasutaja identiteeti. Mis toimub?
Uurimine näitas, et algsel rakendusel oli kaudselt jagatud Jane'i autentitud andmebaasi seanss rakenduse kasutajatega. Rakendust kasutajaga jagades sai see kasutaja otsese juurdepääsu rakendusele ühendus, ümbris autentitud andmebaasi seansi ümber, mida pakub madala koodi/koodita platvorm. Seda ühendust kasutades said kasutajad autentitud seanssi otse kasutada – nad ei pidanud enam rakendust läbima. Selgub, et mitmed kasutajad olid selle avastanud ja arvasid, et see oli kavandatud käitumine, kasutasid päringute käitamiseks Jane'i autentitud andmebaasi seanssi. Neile meeldis see lahendus, kuna ühenduse otsene kasutamine andis neile täieliku juurdepääsu andmebaasile, mitte ainult neile määratud kliendijuhtumitele.
Ühendus kustutati ja juhtum lõppes. SOC-i analüütik võttis ühendust kasutajatega, kes olid kasutanud Jane'i ühendust, et veenduda, et nad kustutavad kõik salvestatud kliendiandmed.
Madala koodi/koodita turvaprobleemi lahendamine
Ülaltoodud lugu on reaalne stsenaarium rahvusvaheliselt B2C ettevõttelt. Mõned üksikasjad jäeti privaatsuse kaitsmiseks välja või kohandati. Oleme näinud, kuidas heatahtlik töötaja võib tahtmatult oma identiteeti teiste kasutajatega jagada, põhjustades IT-, turva- ja ärivaldkonnas terve rea probleeme. Nagu eelmisel kuul uurisime, on mandaatide jagamine madala koodi/koodita funktsioonide põhifunktsioon. See on norm, mitte erand.
As low-code/no-code õitseb ettevõttes edasi, teadlikult või mitte, on turvalisuse ja IT-meeskondade jaoks äriarengu vestlusega ühinemine ülioluline. Madala koodi/koodita rakendustega on kaasas a ainulaadsed turvaprobleemid, ja nende viljakas olemus tähendab, et need väljakutsed muutuvad teravaks kiiremini kui kunagi varem.
