Atenție la uzurparea identității utilizatorilor în aplicațiile Low-Code/Fără cod

Luna trecuta am scris un articol despre modul în care platformele low-code/fără cod oferă partajarea acreditărilor ca serviciu, de ce o fac și cum arată acest lucru de la perspectiva unui atacator. În acest articol, mă voi concentra asupra implicațiilor acestui compromis și asupra modului în care acesta afectează întreprinderile de astăzi.

Iată de ce împărtășirea acreditărilor dvs. de companie cu altcineva este o practică proastă. Să presupunem că vreau să-mi transmit acreditările unui coleg pentru a interoga jurnalele de producție pentru o analiză unică a comportamentului utilizatorului. Într-o întreprindere tipică, acordarea cuiva permisiuni de a interoga o nouă sursă de date ar putea însemna un proces lung de revizuire a accesului, mai ales când vine vorba de date de producție sau sensibile. Colegul meu s-ar putea frustra cu ușurință. „Tot ce îmi doream este să fac această mică interogare unică și deja aștept de o lună!” ar putea spune. Aș putea doar să rulez interogarea pentru ei, dar sunt acoperit cu propriile sarcini de zi cu zi, iar interogările unice tind să devină complicate.

Am rămas cu o soluție rapidă: aș putea doar să-mi partajez numele de utilizator/parola cu colegul meu. Dacă primesc o provocare MAE, voi aproba cu plăcere. Nu trebuie să petrec timpul rulând interogarea, iar colegul meu este deblocat. Toată lumea câștigă! Dreapta?

Ei bine, ai avea dreptate în analiza ta, dar îți lipsește imaginea de ansamblu. Deși este important pentru întreprindere ca colegul dvs. să-și facă analiza comportamentului utilizatorilor, este la fel de important, dacă nu mai mult, ca întreprinderea dvs. să rămână în conformitate cu o serie întreagă de standarde de confidențialitate și securitate și să mențină încrederea clienților, menținând angajamentul companiei față de securitate. .

Dacă obiectivele de nivel înalt ale întreprinderii nu vă convin, luați în considerare echipele centrale de management din IT sau securitate. Aceste echipe își bazează operațiunile și strategiile de securitate pe faptul că fiecare utilizator are propria sa identitate unică. Echipele IT stabilesc politici de rețea și acces care presupun că fiecare utilizator va fi conectat de la un IP corporativ sau laptop corporativ simultan; echipele de securitate corelează evenimente pe baza ID-ului utilizatorului; echipele financiare ar putea agrega rapoarte de cost per utilizator și mediul lor personal de cloud. Partajarea acreditărilor subminează toate aceste ipoteze, printre altele. Îndepărtează sensul de bază al unei identități online.

Un exemplu din lumea reală

Să ne întoarcem la lumea low-code/no-code și să examinăm un scenariu din lumea reală. Într-o întreprindere mare, Jane, un angajat inspirat din echipa de asistență pentru clienți, și-a dat seama că atunci când angajații din întreaga organizație iau parte la un caz de client, de obicei le lipsesc informații cheie despre client, cum ar fi istoricul cazurilor de asistență și ultimele achiziții. Acest lucru degradează experiența clientului, deoarece trebuie să-și explice problema din nou și din nou, în timp ce cazul este direcționat către angajatul potrivit care poate rezolva problema.

Pentru a îmbunătăți acest lucru, Jane a creat o aplicație care le permite angajaților companiei să vadă aceste informații cheie despre clienți atunci când acești angajați fac parte din echipa responsabilă cu soluționarea cazului de asistență al clientului. Mai întâi, să luăm un moment pentru a recunoaște puterea low-code/no-code, care îi permite lui Jane să identifice o nevoie și să o răspundă singură, fără a cere un buget sau a aștepta alocările de resurse IT.

În timpul construirii aplicației, Jane a trebuit să rezolve mai multe probleme, cea mai mare fiind permisiunile. Angajații din întreaga organizație nu au acces direct pentru a interoga baza de date a clienților pentru a obține informațiile de care au nevoie. Dacă ar fi făcut-o, atunci Jane nu ar trebui să creeze această aplicație. Pentru a depăși această problemă, Jane s-a conectat la baza de date și și-a încorporat sesiunea autentificată direct în aplicație. Când aplicația primește o solicitare de la un utilizator, va folosi identitatea lui Jane pentru a executa acea interogare și apoi va returna rezultatele utilizatorului. Această caracteristică de încorporare a acreditărilor, așa cum am explorat luna trecută, este o caracteristică cheie a platformelor low-code/no-code. Jane s-a asigurat că a configurat controlul accesului bazat pe roluri (RBAC) în aplicație, astfel încât fiecare utilizator să poată accesa doar cazurile clienților cărora le este atribuit.

Aplicația a rezolvat o problemă importantă de afaceri și, astfel, a câștigat rapid adoptarea de către utilizatori în întreaga întreprindere. Oamenii au fost fericiți că ar putea oferi un serviciu mai bun clienților lor, având contextul potrivit pentru conversație. Clienții au fost și ei fericiți. La o lună după ce Jane a creat aplicația, aceasta a fost deja folosită de sute de utilizatori din întreaga organizație, ratele de satisfacție ale clienților crescând.

Între timp, la SOC, a fost declanșată o alertă de mare severitate care arată o activitate anormală în baza de date a clienților de producție și i-a fost atribuită lui Amy, un analist de securitate cu experiență. Investigația inițială a lui Amy a arătat că un utilizator intern încerca să curețe întreaga bază de date, interogând informații despre mai mulți clienți de la mai multe adrese IP din întreaga organizație. Modelul de interogare a fost foarte complex; în loc de un model de enumerare simplu pe care v-ați aștepta să vedeți când o bază de date este în curs de răzuire, datele aceluiași client au fost interogate de mai multe ori, uneori prin adrese IP diferite și la date diferite. Ar putea fi acesta un atacator care încearcă să încurce sistemele de monitorizare a securității?

După o investigație rapidă, Amy a descoperit o informație crucială: toate acele interogări la toate adresele IP și datele foloseau o singură identitate de utilizator, cineva pe nume Jane din echipa de asistență pentru clienți.

Amy a ajuns la Jane să o întrebe ce se întâmplă. La început, Jane nu știa. I-au fost furate acreditările? A făcut clic pe linkul greșit sau a avut încredere în e-mailul primit greșit? Dar când Jane i-a spus lui Amy despre aplicația pe care a construit-o recent, amândoi și-au dat seama că ar putea exista o conexiune. Amy, analistul SOC, nu era familiarizată cu low-code/no-code, așa că au contactat echipa AppSec. Cu ajutorul lui Jane, echipa și-a dat seama că aplicația lui Jane avea acreditările lui Jane încorporate în ea. Din perspectiva bazei de date, nu exista nicio aplicație - era doar Jane, care executa o mulțime de interogări.

Jane, Amy și echipa AppSec au decis să închidă aplicația până când a fost găsită o soluție. Utilizatorii aplicațiilor din întreaga organizație au fost frustrați, deoarece ajunseseră să se bazeze pe ea, iar clienții o simțeau și ei.

În timp ce Amy a închis problema și și-a documentat constatările, VP-ul pentru asistența clienților nu a fost mulțumit că rata de satisfacție a clienților scădea, așa că i-au cerut lui Jane să caute o soluție permanentă. Cu ajutorul documentației platformei și al echipei Centrului de excelență a organizației, Jane și-a eliminat identitatea încorporată din aplicație, a schimbat aplicația pentru a utiliza identitatea fiecărui utilizator pentru a interoga baza de date și s-a asigurat că utilizatorii obțin permisiuni numai pentru cazurile clienților cu care sunt asociați. . În versiunea sa nouă și îmbunătățită, aplicația a folosit identitatea fiecărui utilizator pentru a interoga baza de date a clienților. Jane și utilizatorii aplicației au fost fericiți că aplicația este din nou online, Amy și echipa AppSec s-au bucurat că identitatea lui Jane nu mai este partajată, iar întreprinderea a văzut că rata de satisfacție a clienților a început să crească din nou. Totul a fost bine.

Două săptămâni mai târziu, SOC a primit o altă alertă privind accesul anormal la baza de date a clienților de producție. Arăta suspect de similar cu alerta anterioară din aceeași bază de date. Din nou, adresele IP din întreaga organizație foloseau identitatea unui singur utilizator pentru a interoga baza de date. Din nou, acel utilizator a fost Jane. Dar de data aceasta, echipa de securitate și Jane știau că aplicația folosește identitățile utilizatorului său. Ce se întâmplă?

Ancheta a arătat că aplicația originală avea împărtășită implicit Sesiunea de bază de date autentificată a lui Jane cu utilizatorii aplicației. Prin partajarea aplicației cu un utilizator, acel utilizator a primit acces direct la conexiune, un înveliș în jurul unei sesiuni de bază de date autentificate furnizată de platforma low-code/no-code. Folosind acea conexiune, utilizatorii puteau folosi direct sesiunea autentificată - nu mai trebuiau să treacă prin aplicație. Se pare că mai mulți utilizatori aflaseră acest lucru și, crezând că acesta era comportamentul intenționat, foloseau sesiunea de bază de date autentificată a lui Jane pentru a-și rula interogările. Le-a plăcut această soluție, deoarece utilizarea conexiunii le-a oferit direct acces deplin la baza de date, nu doar pentru cazurile clienților cărora le sunt alocați.

Conexiunea a fost ștearsă, iar incidentul s-a încheiat. Analistul SOC a contactat utilizatorii care au folosit conexiunea lui Jane pentru a se asigura că au renunțat la orice date despre clienți pe care le-au stocat.

Abordarea provocării securității Low-Code/No-Code

Povestea de mai sus este un scenariu real de la o companie multinațională B2C. Unele detalii au fost omise sau ajustate pentru a proteja confidențialitatea. Am văzut cum un angajat bine intenționat și-ar putea împărtăși fără să vrea identitatea altor utilizatori, provocând o serie întreagă de probleme în IT, securitate și afacere. După cum am explorat luna trecută, partajarea acreditărilor este o caracteristică cheie a low-code/no-code. Este norma, nu excepția.

As low-code/no-code continuă să înflorească în întreprindere, conștient sau nu, este crucial ca echipele de securitate și IT să se alăture conversației despre dezvoltarea afacerii. Aplicațiile low-code/fără cod vin cu un un set unic de provocări de securitate, iar natura lor prolifică înseamnă că acele provocări devin mai acute mai repede decât oricând.