Múlt hónapban írtam egy cikket arról, hogy az alacsony kódú/kód nélküli platformok hogyan kínálják a hitelesítő adatok megosztását szolgáltatásként, miért teszik ezt, és hogyan néz ki ez a támadó perspektívája. Ebben a cikkben ennek a kompromisszumnak a következményeire és a mai vállalkozásokra gyakorolt hatásra fogok összpontosítani.
Ezért rossz gyakorlat a vállalati hitelesítő adatok megosztása másokkal. Tegyük fel, hogy át akarom adni a hitelesítő adataimat egy kollégámnak, hogy lekérdezzem a termelési naplókat egy egyszeri felhasználói viselkedés elemzéshez. Egy tipikus vállalkozásban egy új adatforrás lekérdezésére vonatkozó engedélyek megadása hosszú hozzáférés-ellenőrzési folyamatot jelenthet, különösen, ha termelési vagy érzékeny adatokról van szó. A kollégám könnyen elkeseredhet. „Csak ezt az apró, egyszeri lekérdezést akartam elvégezni, és már egy hónapja várok rá!” mondhatnák. Egyszerűen lefuttathatnám nekik a lekérdezést, de el vagyok zsúfolva a saját napi feladataimmal, és az egyszeri lekérdezések általában bonyolulttá válnak.
Egyetlen gyors megoldás maradt: megoszthatnám a felhasználónevem/jelszavamat a kollégámmal. Ha MFA-kihívást kapnak, szívesen elfogadom. Nem kell időt töltenem a lekérdezés futtatásával, és a kollégám feloldódik. Mindenki nyer! Jobb?
Nos, igazad lenne az elemzésben, de hiányzik a nagyobb kép. Bár a vállalat számára fontos, hogy kollégája elvégezze a felhasználói viselkedés elemzését, ugyanilyen fontos, ha nem fontosabb, hogy az Ön vállalata továbbra is megfeleljen számos adatvédelmi és biztonsági szabványnak, és fenntartsa az ügyfelek bizalmát azáltal, hogy fenntartja a vállalat biztonság iránti elkötelezettségét. .
Ha a magas szintű vállalati célok nem győzik meg Önt, vegye fontolóra az informatikai vagy biztonsági központi irányítási csapatokat. Ezek a csapatok működésüket és biztonsági stratégiájukat arra a tényre alapozzák, hogy minden felhasználónak megvan a saját egyedi identitása. Az informatikai csapatok hálózati és hozzáférési szabályzatokat állítanak fel, amelyek feltételezik, hogy minden felhasználó egyszerre egy vállalati IP-címről vagy vállalati laptopról jelentkezik be; a biztonsági csapatok felhasználói azonosító alapján korrelálják az eseményeket; A pénzügyi csapatok a költségjelentéseket felhasználónként és személyes felhőkörnyezetükönként összesíthetik. A hitelesítő adatok megosztása aláássa többek között ezeket a feltételezéseket. Megfosztja az online identitás alapvető jelentését.
Egy valós példa
Forduljunk az alacsony kód/kód nélküli világ felé, és vizsgáljunk meg egy valós forgatókönyvet. Egy nagyvállalatnál Jane, az ügyfélszolgálati csapat ihletett alkalmazottja rájött, hogy amikor a szervezet alkalmazottai részt vesznek egy ügyfélügyben, általában hiányoznak az ügyfélről szóló kulcsfontosságú információk, például a támogatási esetek előzményei és a legutóbbi vásárlások. Ez rontja az ügyfél élményét, mivel újra és újra meg kell magyaráznia a problémát, miközben az ügy a megfelelő alkalmazotthoz kerül, aki meg tudja oldani a problémát.
Ennek javítása érdekében Jane létrehozott egy alkalmazást, amely lehetővé teszi a vállalati alkalmazottak számára, hogy megtekintsék ezeket a kulcsfontosságú információkat az ügyfelekről, amikor az alkalmazottak az ügyfél támogatási ügyének kezeléséért felelős csapat tagjai. Először is, szánjunk egy percet annak elismerésére, hogy az alacsony kód/kód nélküli technológia hatalma, amely lehetővé teszi, hogy Jane önállóan azonosítsa az igényt, és megoldja azt anélkül, hogy költségvetést kérne vagy IT-erőforrás-allokációra várna.
Az alkalmazás felépítése közben Jane-nek több problémát kellett megkerülnie, a legnagyobb az engedélyekkel kapcsolatos probléma. A szervezeten belüli alkalmazottaknak nincs közvetlen hozzáférésük az ügyféladatbázis lekérdezéséhez, hogy megszerezzék a szükséges információkat. Ha megtennék, akkor Jane-nek nem kellene megépítenie ezt az alkalmazást. A probléma megoldása érdekében Jane bejelentkezett az adatbázisba, és közvetlenül az alkalmazásba ágyazta be hitelesített munkamenetét. Amikor az alkalmazás kérést kap egy felhasználótól, Jane identitását használja a lekérdezés végrehajtásához, majd az eredményeket visszaküldi a felhasználónak. Ez a hitelesítő adatok beágyazási funkciója, ahogy a múlt hónapban felfedeztük, az alacsony kódú/kód nélküli platformok kulcsfontosságú jellemzője. Jane gondoskodott arról, hogy szerepalapú hozzáférés-vezérlést (RBAC) állítson be az alkalmazásban úgy, hogy minden felhasználó csak azokhoz az ügyfelekhez férhessen hozzá, amelyekhez hozzá van rendelve.
Az alkalmazás megoldott egy fontos üzleti problémát, így gyorsan elterjedt a vállalaton belül. Az emberek örültek, hogy jobb szolgáltatást tudtak nyújtani ügyfeleiknek, ha megfelelő kontextust biztosítanak a beszélgetéshez. A vásárlók is elégedettek voltak. Egy hónappal azután, hogy Jane létrehozta az alkalmazást, már több száz felhasználó használta a szervezetben, és az ügyfelek elégedettségi aránya emelkedett.
Eközben a SOC-nál egy rendkívül súlyos riasztást adtak ki, amely rendellenes tevékenységet mutatott az éles ügyfél-adatbázis körül, és Amyhez, egy tapasztalt biztonsági elemzőhöz rendelték. Amy kezdeti vizsgálata kimutatta, hogy egy belső felhasználó megpróbálta lekaparni a teljes adatbázist, és több ügyfélről kérdezett le információkat a szervezet több IP-címéről. A lekérdezési minta nagyon összetett volt; egy egyszerű felsorolási minta helyett, amelyet az adatbázis lemásolásakor láthat, ugyanazon ügyfél adatait többször is lekérdezték, néha különböző IP-címeken és különböző dátumokon. Lehet, hogy ez egy támadó, aki megpróbálja összezavarni a biztonsági megfigyelőrendszereket?
Egy gyors vizsgálat után Amy egy döntő fontosságú információt tárt fel: az összes IP-címre és dátumra vonatkozó lekérdezések egyetlen felhasználói identitást használtak, valakit, akit Jane-nek hívtak az ügyfélszolgálati csapattól.
Amy megkereste Jane-t, hogy megkérdezze, mi folyik itt. Eleinte Jane nem tudta. Ellopták a hitelesítő adatait? Rossz linkre kattintott, vagy rossz bejövő e-mailben bízott? De amikor Jane mesélt Amynek a nemrégiben készített alkalmazásról, mindketten rájöttek, hogy lehet, hogy van kapcsolat. Amy, az SOC elemzője nem ismerte a low-code/no-code technikát, ezért felvették az AppSec csapatát. Jane segítségével a csapat rájött, hogy Jane alkalmazásában Jane hitelesítő adatai vannak beágyazva. Az adatbázis szemszögéből nézve nem volt alkalmazás – csak Jane volt, aki rengeteg lekérdezést hajtott végre.
Jane, Amy és az AppSec csapata úgy döntött, hogy leállítják az alkalmazást, amíg meg nem találják a megoldást. Az alkalmazás felhasználói a szervezetben csalódottak voltak, mivel támaszkodtak rá, és az ügyfelek is érezték ezt.
Míg Amy lezárta a kérdést, és dokumentálta a megállapításaikat, az ügyfélszolgálat alelnöke nem örült az ügyfél-elégedettségi ráta csökkenésének, ezért megkérték Jane-t, hogy keressen állandó megoldást. A platform dokumentációjának és a szervezet kiválósági központjának csapata segítségével Jane eltávolította beágyazott identitását az alkalmazásból, megváltoztatta az alkalmazást úgy, hogy az egyes felhasználók identitását használja az adatbázis lekérdezéséhez, és biztosította, hogy a felhasználók csak azokhoz az ügyfelekhez kapjanak engedélyeket, amelyekhez kapcsolódnak. . Az új és továbbfejlesztett verziójában az alkalmazás az egyes felhasználók identitását használta az ügyféladatbázis lekérdezéséhez. Jane és az alkalmazás felhasználói örültek, hogy az alkalmazás újra elérhető, Amy és az AppSec csapata örült annak, hogy Jane személyazonosságát már nem osztják meg, és a vállalat azt tapasztalta, hogy az ügyfelek elégedettsége ismét emelkedni kezdett. Minden jó volt.
Két héttel később az SOC újabb figyelmeztetést kapott a gyártási ügyfelek adatbázisához való rendellenes hozzáférésről. Gyanúsan hasonlított az ugyanabban az adatbázisban szereplő előző riasztáshoz. A szervezet IP-címei ismét egyetlen felhasználó identitását használták az adatbázis lekérdezéséhez. Ez a felhasználó ismét Jane volt. De ezúttal a biztonsági csapat és Jane tudta, hogy az alkalmazás a felhasználói identitását használja. Mi történik?
A vizsgálat során kiderült, hogy az eredeti alkalmazásban volt hallgatólagosan megosztott Jane hitelesített adatbázis-munkamenete az alkalmazás felhasználóival. Az alkalmazás egy felhasználóval való megosztásával a felhasználó közvetlen hozzáférést kapott a kapcsolat, az alacsony kódú/kód nélküli platform által biztosított hitelesített adatbázis-munkamenet körüli burkoló. Ezzel a kapcsolattal a felhasználók közvetlenül kihasználhatják a hitelesített munkamenetet – többé nem kellett átmenniük az alkalmazáson. Kiderült, hogy több felhasználó rájött erre, és azt gondolva, hogy ez volt a szándékolt viselkedés, Jane hitelesített adatbázis-munkamenetét használták a lekérdezések futtatásához. Szerették ezt a megoldást, hiszen a kapcsolat közvetlen használatával teljes hozzáférést kaptak az adatbázishoz, nem csak azokhoz az ügyfelekhez, amelyekhez hozzá vannak rendelve.
A kapcsolat megszakadt, és az incidens véget ért. Az SOC elemzője megkereste azokat a felhasználókat, akik használták Jane kapcsolatát, hogy megbizonyosodjanak arról, hogy eldobják az általuk tárolt ügyféladatokat.
Az alacsony kódszámú/kód nélküli biztonsági kihívás kezelése
A fenti történet valós forgatókönyv egy multinacionális B2C cégtől. Néhány részletet kihagytunk vagy módosítottunk a magánélet védelme érdekében. Láttuk, hogy egy jó szándékú alkalmazott akaratlanul is megoszthatja személyazonosságát más felhasználókkal, ami számos problémát okoz az IT, a biztonság és az üzleti életben. Ahogyan azt a múlt hónapban felfedeztük, a hitelesítő adatok megosztása az alacsony kódú/kód nélküli rendszerek kulcsfontosságú jellemzője. Ez a norma, nem a kivétel.
As a low-code/no-code továbbra is virágzik a vállalkozásban, akár tudatosan, akár nem, kulcsfontosságú, hogy biztonsági és informatikai csapatok csatlakozzanak az üzletfejlesztési beszélgetéshez. Az alacsony kódú/kód nélküli alkalmazásokhoz a egyedi biztonsági kihívások, és termékeny természetük azt jelenti, hogy ezek a kihívások minden eddiginél gyorsabban súlyosbodnak.
