Varo käyttäjän toisena henkilönä esiintymistä vähäkoodiisissa/ei-koodisovelluksissa

Viime kuussa kirjoitin artikkeli siitä, miten alhaisen koodin/koodittomat alustat tarjoavat tunnistetietojen jakamisen palveluna, miksi ne tekevät sen ja miltä se näyttää hyökkääjän näkökulmasta. Tässä artikkelissa keskityn tämän kompromissin vaikutuksiin ja siihen, miten se vaikuttaa yrityksiin nykyään.

Tästä syystä yritystietojesi jakaminen jonkun muun kanssa on huono käytäntö. Sano, että haluan välittää valtuustietoni kollegalle, jotta voin tehdä kyselyn tuotantolokeista kertaluonteista käyttäjien käyttäytymisanalyysiä varten. Tyypillisessä yrityksessä luvan myöntäminen uudelle tietolähteelle voi tarkoittaa pitkää käyttöoikeuksien tarkistusprosessia, etenkin kun on kyse tuotanto- tai arkaluonteisista tiedoista. Kollegani voi helposti turhautua. "Halusin vain tehdä tämän pienen kertaluonteisen kyselyn, ja olen odottanut jo kuukauden!" he voisivat sanoa. Voisin vain suorittaa kyselyn heille, mutta olen täynnä päivittäisiä tehtäviäni, ja yksittäiset kyselyt ovat yleensä monimutkaisia.

Minulle jää yksi nopea ratkaisu: voisin vain jakaa käyttäjätunnukseni/salasanani kollegalleni. Jos he saavat MFA-haasteen, hyväksyn sen mielelläni. Minun ei tarvitse käyttää aikaa kyselyn suorittamiseen, ja kollegani vapautetaan. Kaikki voittaa! Eikö?

No, olet oikeassa analyysissäsi, mutta sinulta puuttuu isompi kuva. Vaikka yritykselle on tärkeää, että kollegasi saa käyttäjäkäyttäytymisanalyysinsä valmiiksi, on yhtä, ellei tärkeämpää, että yrityksesi noudattaa monia tietosuoja- ja turvallisuusstandardeja ja säilyttää asiakkaiden luottamuksen ylläpitämällä yrityksen sitoutumista tietoturvaan. .

Jos korkean tason yritystavoitteet eivät vakuuta sinua, harkitse IT- tai turvallisuusalan keskusjohtoryhmiä. Nämä tiimit perustavat toimintansa ja tietoturvastrategiansa siihen, että jokaisella käyttäjällä on oma ainutlaatuinen identiteettinsä. IT-tiimit määrittävät verkko- ja käyttökäytäntöjä, joissa oletetaan, että jokainen käyttäjä kirjautuu sisään yhdestä yrityksen IP-osoitteesta tai kannettavasta tietokoneesta kerralla. turvallisuustiimit korreloivat tapahtumia käyttäjätunnuksen perusteella; rahoitustiimit voisivat koota kustannusraportteja käyttäjää ja henkilökohtaista pilviympäristöään kohti. Tunnusten jakaminen horjuttaa muun muassa kaikkia näitä oletuksia. Se poistaa verkkoidentiteetin perusmerkityksen.

Tosimaailman esimerkki

Käännytään matalan koodin/ei koodin maailmaan ja tarkastellaan todellista skenaariota. Suuressa yrityksessä Jane, asiakaspalvelutiimin inspiroitunut työntekijä, tajusi, että kun työntekijät eri puolilla organisaatiota osallistuvat asiakastapaukseen, heiltä yleensä puuttuu tärkeitä tietoja asiakkaasta, kuten tukitapaushistoria ja viimeisimmät ostot. Tämä heikentää asiakkaan kokemusta, koska hänen on selitettävä ongelmansa yhä uudelleen ja uudelleen, kun tapaus ohjataan oikealle työntekijälle, joka voi käsitellä ongelman.

Tämän parantamiseksi Jane loi sovelluksen, jonka avulla yrityksen työntekijät voivat tarkastella näitä keskeisiä asiakkaita koskevia tietoja, kun kyseiset työntekijät ovat osa tiimiä, joka vastaa asiakkaan tukitapauksen käsittelystä. Ensinnäkin tunnustetaan vähän koodin/no-coden teho, jonka avulla Jane voi tunnistaa tarpeen ja ratkaista sen itse ilman, että kysyy budjettia tai odota IT-resurssien allokointia.

Rakentaessaan sovellusta Janen täytyi kiertää useita ongelmia, joista suurin oli käyttöoikeudet. Työntekijöillä ympäri organisaatiota ei ole suoraa pääsyä asiakastietokannan kyselyihin saadakseen tarvitsemansa tiedot. Jos he tekisivät, Janen ei tarvitsisi rakentaa tätä sovellusta. Tämän ongelman ratkaisemiseksi Jane kirjautui tietokantaan ja upotti todennettu istuntonsa suoraan sovellukseen. Kun sovellus vastaanottaa pyynnön yhdeltä käyttäjältä, se käyttää Janen identiteettiä kyselyn suorittamiseen ja palauttaa sitten tulokset käyttäjälle. Tämä tunnistetietojen upotusominaisuus, kuten tutkimme viime kuussa, on alhaisen koodin/koodittomien alustojen avainominaisuus. Jane on määrittänyt sovellukseen roolipohjaisen pääsynhallinnan (RBAC) siten, että jokainen käyttäjä voi käyttää vain asiakastapauksia, joihin hän on määrätty.

Sovellus ratkaisi tärkeän liiketoimintaongelman, joten se sai nopeasti käyttäjien käyttöön koko yrityksen. Ihmiset olivat iloisia, että he pystyivät palvelemaan asiakkaitaan paremmin, kun heillä oli oikea konteksti keskustelulle. Asiakkaatkin olivat tyytyväisiä. Kuukausi sen jälkeen, kun Jane loi sovelluksen, sadat käyttäjät ympäri organisaatiota käyttivät sitä jo asiakastyytyväisyysasteen noustessa.

Samaan aikaan SOC:ssa käynnistettiin vakava hälytys, joka osoitti epänormaalia toimintaa tuotantoasiakastietokannassa, ja se määrättiin Amylle, kokeneelle tietoturva-analyytikolle. Amyn alustava tutkimus osoitti, että sisäinen käyttäjä yritti raaputtaa koko tietokannan ja kyseli tietoja useista asiakkaista useista organisaation IP-osoitteista. Kyselymalli oli hyvin monimutkainen; yksinkertaisen luettelointimallin sijaan, jonka voit odottaa näkevän tietokannan kaapimisen, saman asiakkaan tietoja kysyttiin useita kertoja, joskus eri IP-osoitteiden kautta ja eri päivinä. Voisiko tämä olla hyökkääjä, joka yrittää sekoittaa turvavalvontajärjestelmät?

Nopean tutkimuksen jälkeen Amy paljasti ratkaisevan tiedon: kaikki nämä kyselyt kaikista IP-osoitteista ja päivämääristä käyttivät yhtä käyttäjäidentiteettiä, jotakuta Jane-nimistä asiakaspalvelutiimistä.

Amy otti yhteyttä Janeen kysyäkseen, mitä tapahtuu. Aluksi Jane ei tiennyt. Varastettiinko hänen valtakirjansa? Klikkaiko hän väärää linkkiä vai luottiko hän väärään saapuvaan sähköpostiin? Mutta kun Jane kertoi Amylle äskettäin rakentamastaan ​​sovelluksesta, he molemmat ymmärsivät, että yhteys saattaa olla olemassa. Amy, SOC:n analyytikko, ei tuntenut matalakoodia/ei-koodia, joten he ottivat yhteyttä AppSec-tiimiin. Janen avulla tiimi päätti, että Janen sovelluksessa oli Janen tunnistetiedot. Tietokannan näkökulmasta sovelluksia ei ollut – siellä oli vain Jane, joka suoritti paljon kyselyjä.

Jane, Amy ja AppSec-tiimi päättivät sulkea sovelluksen, kunnes ratkaisu löydettiin. Sovellusten käyttäjät ympäri organisaatiota olivat turhautuneita, koska he olivat alkaneet luottaa siihen, ja myös asiakkaat tunsivat sen.

Vaikka Amy sulki ongelman ja dokumentoi havainnot, asiakaspalvelun johtaja ei ollut tyytyväinen asiakastyytyväisyysasteen laskuun, joten he pyysivät Janea etsimään pysyvää ratkaisua. Alustan dokumentaation ja organisaation huippuyksikkötiimin avulla Jane poisti upotetun identiteettinsä sovelluksesta, muutti sovelluksen käyttämään jokaisen käyttäjän identiteettiä tietokannan kyselyihin ja varmisti, että käyttäjät saavat käyttöoikeudet vain niihin asiakastapauksiin, joihin he liittyvät. . Uudessa ja parannetussa versiossaan sovellus käytti kunkin käyttäjän identiteettiä kyselyjen tekemiseen asiakastietokannasta. Jane ja sovelluksen käyttäjät olivat iloisia siitä, että sovellus on jälleen verkossa, Amy ja AppSec-tiimi olivat iloisia siitä, että Janen identiteettiä ei enää jaeta, ja yritys näki asiakastyytyväisyysasteen alkavan taas nousta. Kaikki oli hyvin.

Kaksi viikkoa myöhemmin SOC sai toisen hälytyksen epänormaalista pääsystä tuotantoasiakastietokantaan. Se näytti epäilyttävän samanlaiselta kuin edellinen hälytys samassa tietokannassa. Jälleen IP-osoitteet eri puolilta organisaatiota käyttivät yhden käyttäjän identiteettiä tietokannan kyselyihin. Jälleen tämä käyttäjä oli Jane. Mutta tällä kertaa turvallisuustiimi ja Jane tiesivät, että sovellus käyttää käyttäjän identiteettiä. Mitä tapahtuu?

Tutkimus paljasti, että alkuperäisessä sovelluksessa oli implisiittisesti jaettu Janen todennettu tietokantaistunto sovelluksen käyttäjien kanssa. Jakamalla sovelluksen käyttäjän kanssa, tämä käyttäjä sai suoran pääsyn sovellukseen liitäntä, kääre todennetun tietokantaistunnon ympärillä, jonka tarjoaa matalan koodin/ei-koodin alusta. Tätä yhteyttä käyttämällä käyttäjät voivat hyödyntää todennettua istuntoa suoraan – heidän ei enää tarvinnut käydä sovelluksen läpi. Kävi ilmi, että useat käyttäjät olivat havainneet tämän ja ajattelivat, että tämä oli tarkoitus käyttäytyä, ja he käyttivät Janen todennettua tietokantaistuntoa kyselyiden suorittamiseen. He rakastivat tätä ratkaisua, koska yhteyden suora käyttö antoi heille täyden pääsyn tietokantaan, ei vain niihin asiakastapauksiin, joihin heidät on määrätty.

Yhteys katkesi ja tapaus oli ohi. SOC-analyytikko otti yhteyttä käyttäjiin, jotka olivat käyttäneet Janen yhteyttä varmistaakseen, että he hävittävät kaikki tallentamansa asiakastiedot.

Low-Code/No-Code-turvallisuushaasteen käsitteleminen

Yllä oleva tarina on tosielämän skenaario monikansalliselta B2C-yritykseltä. Jotkut yksityiskohdat jätettiin pois tai niitä muutettiin yksityisyyden suojaamiseksi. Olemme nähneet, kuinka hyvää tarkoittava työntekijä voi tietämättään jakaa identiteettinsä muiden käyttäjien kanssa, mikä aiheuttaa monia ongelmia IT-, tietoturva- ja liiketoiminnassa. Kuten viime kuussa tutkimme, tunnistetietojen jakaminen on matalan koodin/ei-koodin keskeinen ominaisuus. Se on normi, ei poikkeus.

As low-code/no-code jatkaa kukoistamista yrityksessä, tietoisesti tai ei, on erittäin tärkeää, että tietoturva- ja IT-tiimit osallistuvat liiketoiminnan kehittämiskeskusteluun. Matalakoodin/koodittomien sovellusten mukana tulee a ainutlaatuisia turvallisuushaasteita, ja niiden tuottelias luonne tarkoittaa, että nämä haasteet kärjistyvät nopeammin kuin koskaan ennen.