3 moduri în care dezvoltatorii fără cod se pot împușca singuri în picior

A fost o perioadă în care organizațiile care au aversión la riscuri puteau limita sever capacitatea utilizatorilor lor de afaceri de a face greșeli costisitoare. Cu cunoștințe tehnice limitate, permisiuni stricte și lipsă de vânt din spate, cel mai rău lucru pe care un utilizator de afaceri îl putea face a fost să descarce malware sau să se îndrăgostească de o campanie de phishing. Acele zile au trecut acum.

In prezent, fiecare platformă majoră de software-as-a-service (SaaS) vine la pachet cu capabilități de automatizare și creare de aplicații care sunt proiectate și comercializate direct utilizatorilor de afaceri. Platformele SaaS precum Microsoft 365, Salesforce și ServiceNow sunt încorporate platforme fără cod/low-code în ofertele lor existente, punându-le direct în mâinile utilizatorilor de afaceri fără a cere aprobarea corporativă. Capabilitățile care erau cândva disponibile doar pentru echipele IT și de dezvoltare sunt acum disponibile în întreaga organizație.

Power Platform, platforma low-code a Microsoft, este integrată în Office 365 și este un exemplu excelent datorită poziției puternice a Microsoft în întreprindere și a ratei în care este adoptată de utilizatorii de afaceri. Poate fără să-și dea seama, întreprinderile pun puterea la nivel de dezvoltator în mâinile mai multor oameni decât oricând, cu mult mai puțină securitate sau cunoștințe tehnice. Ce ar putea merge prost?

Destul de multe, de fapt. Să examinăm câteva exemple din lumea reală din experiența mea. Informațiile au fost anonimizate, iar procesele specifice afacerii au fost omise.

Situația 1: Furnizor nou? Doar fă-o

Echipa de asistență clienți a unei companii multinaționale de retail a dorit să-și îmbogățească datele clienților cu informații despre consumatori. În special, ei sperau să găsească mai multe informații despre clienții noi, astfel încât să îi poată servi mai bine, chiar și în timpul achiziției inițiale. Echipa de asistență pentru clienți a decis asupra unui furnizor cu care ar dori să lucreze. Vânzătorul a cerut ca datele să le fie trimise pentru îmbogățire, care urmau să fie apoi retrase de serviciile lor.

În mod normal, aici intervine IT-ul. IT-ul ar trebui să creeze un fel de integrare pentru a obține date către și de la furnizor. În mod evident, echipa de securitate IT ar trebui să fie implicată și pentru a se asigura că acest furnizor poate avea încredere cu datele clienților și să aprobe achiziția. Achizițiile și juridicul ar fi avut, de asemenea, un rol esențial. În acest caz, însă, lucrurile au mers într-o altă direcție.

Această echipă specială de asistență pentru clienți era experți Microsoft Power Platform. În loc să aștepte resurse sau aprobare, au continuat și au construit ei înșiși integrarea: colectarea datelor clienților de pe serverele SQL aflate în producție, redirecționarea tuturor către un server FTP furnizat de furnizor și preluarea datelor îmbogățite înapoi de pe serverul FTP către baza de date de producție. Întregul proces a fost executat automat de fiecare dată când un client nou a fost adăugat la baza de date. Toate acestea au fost realizate prin interfețe drag-and-drop, găzduite pe Office 365 și folosind conturile lor personale. Licența a fost plătită din buzunar, ceea ce a ținut achizițiile în afara circuitului.

Imaginați-vă surpriza CISO când au găsit o grămadă de automatizări de afaceri care mută datele clienților la o adresă IP codificată pe AWS. Fiind un client exclusiv Azure, acest lucru a ridicat un steag roșu uriaș. În plus, datele erau trimise și primite cu o conexiune FTP nesigură, creând un risc de securitate și de conformitate. Când echipa de securitate a descoperit acest lucru printr-un instrument de securitate dedicat, datele au fost mutate în și din organizație de aproape un an.

Situația 2: Ohh, este greșit să colectezi carduri de credit?

Echipa de resurse umane a unui mare furnizor IT se pregătea pentru o campanie „Give Away” o dată pe an, în care angajații sunt încurajați să doneze organizației lor de caritate preferate, compania participând prin egalarea fiecărui dolar donat de angajați. Campania de anul precedent a fost un succes masiv, așa că așteptările au fost pe acoperiș. Pentru a alimenta campania și a atenua procesele manuale, un angajat creativ de resurse umane a folosit Power Platform a Microsoft pentru a crea o aplicație care a facilitat întregul proces. Pentru a se înregistra, un angajat ar trebui să se conecteze la aplicație cu contul său corporativ, să trimită suma donației, să selecteze o organizație de caritate și să furnizeze detaliile cardului de credit pentru plată.

Campania a fost un succes uriaș, cu o participare record a angajaților și puțină muncă manuală necesară angajaților din HR. Din anumite motive, însă, echipa de securitate nu a fost mulțumită de felul în care au decurs lucrurile. În timp ce se înregistra în campanie, un angajat din echipa de securitate și-a dat seama că cardurile de credit erau colectate într-o aplicație care nu părea că ar trebui să facă acest lucru. În urma investigațiilor, ei au descoperit că acele detalii ale cardului de credit au fost într-adevăr gestionate necorespunzător. Detaliile cardului de credit au fost stocate în mediul implicit Power Platform, ceea ce înseamnă că erau disponibile pentru întregul chiriaș Azure AD, inclusiv pentru toți angajații, furnizorii și contractanții. În plus, acestea au fost stocate ca simple câmpuri de șir de text simplu.

Din fericire, încălcarea procesării datelor a fost descoperită de echipa de securitate înainte ca actorii rău intenționați – sau auditorii de conformitate – să o descopere. Baza de date a fost curățată, iar aplicația a fost corectată pentru a gestiona corect informațiile financiare conform reglementărilor.

Situația 3: De ce nu pot folosi Gmail?

În calitate de utilizator, nimănui nu-i plac controalele de prevenire a pierderii datelor de companie. Chiar și atunci când este necesar, ele introduc frecări enervante în operațiunile de zi cu zi. Drept urmare, utilizatorii au încercat întotdeauna să le ocolească. O luptă perenă între utilizatorii de afaceri creativi și echipa de securitate este e-mailul corporativ. Sincronizarea e-mailului corporativ cu un cont de e-mail personal sau cu un calendar corporativ cu un calendar personal: echipele de securitate au o soluție pentru asta. Și anume, au implementat soluții de securitate a e-mailului și DLP pentru a bloca redirecționarea e-mailurilor și pentru a asigura guvernanța datelor. Asta rezolvă problema, nu?

Ei bine, nu. O constatare repetată în cadrul întreprinderilor mari și al întreprinderilor mici, constată că utilizatorii creează automatizări care ocolesc controalele e-mailului pentru a redirecționa e-mailul corporativ și calendarul către conturile lor personale. În loc să redirecționeze e-mailurile, acestea copiază și lipesc date de la un serviciu la altul. Conectându-se la fiecare serviciu cu o identitate separată și automatizând procesul de copiere și inserare fără cod, utilizatorii de afaceri ocolesc controalele de securitate cu ușurință – și fără o modalitate ușoară pentru echipele de securitate de a afla.

S-a dezvoltat chiar și comunitatea Power Platform şabloane pe care orice utilizator Office 365 îl poate prelua și utiliza.

Cu o mare putere vine o mare responsabilitate

Împuternicirea utilizatorilor de afaceri este grozavă. Liniile de afaceri nu ar trebui să aștepte IT sau să lupte pentru resurse de dezvoltare. Cu toate acestea, nu putem doar să oferim utilizatorilor de afaceri putere la nivel de dezvoltator fără îndrumări sau balustrade și să ne așteptăm ca totul să fie în regulă.

Echipele de securitate trebuie să educe utilizatorii de afaceri și să-i facă conștienți de noile lor responsabilități ca dezvoltatori de aplicații, chiar dacă acele aplicații au fost create folosind „fără cod”. Echipele de securitate ar trebui, de asemenea, să pună în aplicare balustrade și monitorizare pentru a se asigura că atunci când utilizatorii de afaceri fac o greșeală, așa cum facem cu toții, aceasta nu se va transforma în scurgeri de date sau incidente de audit de conformitate.