Vis daugiau organizacijų eksperimentuoja su „Claude Code“, „Cursor“, „Lovable“, „Bolt“ ir kitais įrankiais. Dažnai tai padeda greitai pamatyti idėjos potencialą ir geriau suprasti, kokio sprendimo iš tikrųjų reikia.
Tačiau tarp veikiančio prototipo ir patikimos verslo sistemos yra nemažas skirtumas.
Sistema gali turėti prisijungimą, duomenų bazę, dokumentų įkėlimą ir tvarkingą vartotojo sąsają, bet tuo pačiu turėti rizikų, kurių be techninės patirties lengva nepastebėti.
Pavyzdžiui:
netinkamai valdomas prieigas
viešai pasiekiamus dokumentus
nepatikimas atsargines kopijas
klaidingus finansinius skaičiavimus
neaiškią duomenų saugojimo vietą
priklausomybę nuo vieno darbuotojo ar vienos paskyros
Šio straipsnio tikslas – ne stabdyti tokias iniciatyvas, o padėti organizacijoms laiku atpažinti momentą, kada prototipą jau verta profesionaliai įvertinti prieš pradedant naudoti su tikrais duomenimis, darbuotojais ar klientais.
Toliau – 12 svarbiausių dalykų, kuriuos verta patikrinti.
1. Patikrinkite, ar įkelti failai nėra viešai pasiekiami
Tai viena pavojingiausių ir lengviausiai nepastebimų klaidų.
Sistema gali reikalauti prisijungti, kad naudotojas pamatytų dokumentų sąrašą, tačiau pats failas gali būti saugomas viešame kataloge. Tokiu atveju sutartį, sąskaitą ar kitą dokumentą gali atidaryti kiekvienas, turintis tiesioginę nuorodą.
Kaip tai patikrinti
Atidarykite dokumentą, nukopijuokite jo nuorodą ir pabandykite ją atverti:
atsijungę nuo sistemos
privačiame naršyklės lange
kitame įrenginyje
Jeigu dokumentas atsidaro be prisijungimo, jis greičiausiai nėra tinkamai apsaugotas.
Taip pat būtina patikrinti, ar vienas prisijungęs klientas negali pakeisti dokumento numerio nuorodoje ir atidaryti kitam klientui priklausančio failo.
2. Prisijungimo langas dar nereiškia, kad prieigos valdomos teisingai
Prisijungimas nustato, kas yra naudotojas. Tačiau sistema dar turi nuspręsti, kokius konkrečius duomenis jis gali matyti ir kokius veiksmus atlikti.
Pavyzdžiui:
darbuotojas turi matyti tik savo padalinio duomenis
klientas – tik savo įmonės užsakymus
vadybininkas neturi keisti administracinių nustatymų
buvęs darbuotojas nebegali prisijungti
Vien paslėpti mygtuką nepakanka. Sistema turi tikrinti teises kiekvieną kartą atidarant, keičiant, atsisiunčiant ar ištrinant duomenis.
Testuoti reikia ne tik tai, ką naudotojas turėtų galėti padaryti, bet ir tai, ko jis neturėtų galėti padaryti.
3. Eksperimentuodami nenaudokite tikrų jautrių duomenų
Norint greitai patikrinti sistemą, kyla pagunda įkelti kelias tikras sutartis, sąskaitas ar klientų duomenis.
Tačiau eksperimentinė sistema gali neturėti tinkamos apsaugos, o įkelta informacija gali patekti į:
išorinius DI modelius
sistemos žurnalus
klaidų stebėjimo įrankius
neaiškiai valdomas duomenų saugyklas
kitų paslaugų tiekėjų sistemas
Testavimui naudokite išgalvotus arba anonimizuotus duomenis. Tikrus duomenis galima kelti tik aiškiai žinant, kur jie saugomi, kam perduodami ir kas gali juos pasiekti.
4. Nelaikykite slaptažodžių ir API raktų programiniame kode
Integracijoms su DI, el. paštu, mokėjimais, apskaita ar kitomis sistemomis naudojami slapti API raktai.
Kuriant su DI labai paprasta įrašyti tokį raktą tiesiai į kodą, kad integracija „tiesiog pradėtų veikti“. Tačiau jis gali patekti į viešą programinio kodo saugyklą, sistemos žurnalus ar būti matomas naršyklėje.
Nutekėjęs raktas gali leisti:
naudotis jūsų mokamomis paslaugomis
siųsti laiškus įmonės vardu
pasiekti klientų duomenis
atlikti veiksmus kitose sistemose
sukelti dideles išlaidas
Slapti duomenys turi būti laikomi tam skirtose saugiose konfigūracijose. Jeigu raktas jau buvo paviešintas, vien ištrinti jį iš kodo neužtenka – raktą reikia panaikinti ir pakeisti nauju.
5. Turėkite atsargines kopijas ir realiai išbandykite atkūrimą
Sistema gali veikti be problemų mėnesius, kol vienas neteisingas pakeitimas ištrina klientų duomenis, dokumentus ar užsakymų istoriją.
Neužtenka žinoti, kad atsarginės kopijos „turėtų būti daromos“.
Reikia aiškiai atsakyti:
kaip dažnai jos daromos
kur jos saugomos
ar kopijuojama ir duomenų bazė, ir failai
kiek laiko kopijos saugomos
kas atsakingas už atkūrimą
ar atkūrimas kada nors buvo išbandytas
Atsarginė kopija, kurios niekas nebandė atkurti, dar nėra patikimas apsaugos planas.
6. Atskirkite testavimo sistemą nuo realios
Naujo funkcionalumo nereikėtų bandyti sistemoje, kurioje jau dirbama su tikrais duomenimis.
Vienas eksperimentas gali:
išsiųsti tikrą laišką klientui
sukurti sąskaitą
pakeisti užsakymo būseną
perduoti neteisingus duomenis į apskaitą
ištrinti dokumentus
sustabdyti sistemos veikimą
Testavimo aplinkoje turėtų būti naudojami bandomieji duomenys, o mokėjimai, el. laiškai ir kitos integracijos turi veikti testavimo režimu.
7. Patikrinkite verslo logiką, o ne tik tai, ar mygtukas veikia
Sistema gali techniškai veikti nepriekaištingai, tačiau skaičiuoti neteisingai.
Pavyzdžiui, ji gali:
neteisingai apskaičiuoti PVM
pritaikyti ne tą nuolaidą
sumaišyti kainas su PVM ir be PVM
neįvertinti minimalaus užsakymo kiekio
leisti viršyti kliento kredito limitą
apeiti privalomą patvirtinimą
Tokios klaidos dažnai nesukelia jokio techninio pranešimo. Sistema tiesiog pateikia neteisingą rezultatą.
Svarbiausi skaičiavimai ir taisyklės turi būti patikrinti pagal iš anksto paruoštus realius scenarijus, įskaitant nestandartines ir ribines situacijas.
8. Įsitikinkite, kad sistema registruoja svarbius veiksmus
Kai sistemoje kažkas pasikeičia, turi būti įmanoma nustatyti:
kas atliko veiksmą
kada jis buvo atliktas
kas buvo pakeista
kokia reikšmė buvo anksčiau
ar veiksmą atliko žmogus, DI, ar kita sistema
Be veiksmų istorijos gali būti neįmanoma išsiaiškinti, kas pakeitė kainą, ištrynė dokumentą ar suteikė administratoriaus teises.
Tačiau žurnaluose negalima saugoti slaptažodžių, API raktų ar kitos perteklinės jautrios informacijos.
9. Numatykite, kaip bus panaikinamos išėjusių darbuotojų prieigos
Savarankiškai kuriamose sistemose paskyros dažnai sukuriamos greitai, tačiau pamirštama jas vėliau peržiūrėti.
Taip sistemoje lieka:
buvusių darbuotojų paskyros
seni administratoriai
išorinių partnerių prieigos
bendri komandos slaptažodžiai
nebeaiškios paskirties API raktai
Dar prieš paleidimą turi būti aišku, kas kuria paskyras, kas suteikia administratoriaus teises ir kas nedelsiant panaikina prieigas darbuotojui išėjus.
Administratoriams turėtų būti naudojamas kelių veiksnių autentifikavimas, o kiekvienas žmogus – turėti individualią paskyrą.
10. Įvertinkite ne tik tai, kaip sistema veikia dabar
Sprendimas gali veikti puikiai su trimis naudotojais ir keliasdešimt įrašų, tačiau pradėti strigti sukaupus daugiau duomenų.
Augant sistemai gali paaiškėti, kad:
paieška tampa labai lėta
ataskaita užblokuoja visą sistemą
failai užpildo saugyklą
vienas vartotojas sugeneruoja tūkstančius DI užklausų
išorinių paslaugų išlaidos tampa nekontroliuojamos
vienu metu atliekami veiksmai sugadina duomenis
Reikia iš anksto numatyti vartotojų, duomenų ir failų kiekius, naudojimo apribojimus bei išlaidų perspėjimus.
11. Įsitikinkite, kad sistema priklauso organizacijai
Sistema neturėtų likti vieno ją sukūrusio darbuotojo asmeninėje paskyroje.
Organizacija turi žinoti:
kur saugomas programinis kodas
kas valdo domeną
kas turi prieigą prie serverio ir duomenų bazės
kieno vardu sukurtos išorinių paslaugų paskyros
ar galima eksportuoti duomenis
ar kita komanda galėtų perimti sistemos priežiūrą
Asmeninė paskyra, asmeninė mokėjimo kortelė ar vienintelis informaciją turintis darbuotojas sukuria didelę priklausomybę.
12. Atpažinkite momentą, kai prototipas tampa verslo sistema
Didžiausia klaida – vertinti sprendimą kaip nedidelį eksperimentą vien todėl, kad jis buvo greitai sukurtas.
Profesionalus techninis įvertinimas tampa būtinas, kai sistema:
saugo klientų ar darbuotojų duomenis
leidžia kelti vidinius dokumentus
naudojama išorinių klientų
turi skirtingus prieigos lygius
integruojama su apskaita ar kitomis svarbiomis sistemomis
vykdo mokėjimus ar generuoja sąskaitas
atlieka svarbius finansinius skaičiavimus
tampa kasdienio darbo dalimi
turi veikti patikimai ir be pertrūkių
Nuo šio momento tai jau nebe vien prototipas. Tai verslo sistema, už kurios saugumą, duomenis ir veikimo pasekmes atsako organizacija.
15 klausimų, kuriuos turėtumėte užduoti prieš sistemos paleidimą
Ar atsijungęs žmogus gali pasiekti įkeltus dokumentus?
Ar vienas klientas gali pamatyti kito kliento duomenis?
Kur saugomi duomenys ir dokumentai?
Ar testavimui naudojami tikri duomenys?
Kam šie duomenys perduodami?
Kas nutiktų netyčia ištrynus svarbią informaciją?
Ar atkūrimas iš atsarginės kopijos buvo išbandytas?
Kas turi administratoriaus teises?
Kaip panaikinamos išėjusių darbuotojų prieigos?
Ar slaptažodžiai ir API raktai nėra programiniame kode?
Ar testavimo sistema gali atlikti realius veiksmus?
Ar registruojama svarbių pakeitimų istorija?
Ar galima eksportuoti visus savo duomenis?
Kas pastebės, jeigu sistema nustos veikti?
Kokią didžiausią žalą galėtų padaryti viena jos klaida?
Jeigu į šiuos klausimus nėra aiškių atsakymų, sistemos dar nereikėtų naudoti svarbiems verslo procesams.
Apibendrinimas
DI įrankiais šiandien galima labai greitai sukurti įtikinamai atrodantį ir iš pirmo žvilgsnio veikiantį sprendimą. Tačiau būtent tai gali sukurti klaidingą saugumo jausmą.
Didžioji dalis pavojingiausių problemų vartotojo sąsajoje nėra matomos. Sistema gali rodyti teisingus mygtukus, bet netinkamai riboti prieigas. Gali turėti prisijungimą, bet viešai saugoti dokumentus. Gali tiksliai vykdyti aprašytą formulę, nors pati formulė verslo požiūriu yra neteisinga.
Todėl savarankiškai sukurtas prototipas neturėtų būti automatiškai laikomas paruošta verslo sistema.
Jeigu sprendimas pradeda naudoti tikrus duomenis, jungiamas su kitomis sistemomis, tampa svarbus darbuotojams ar atveriamas klientams, prieš paleidimą jį turėtų įvertinti patyrę technologijų specialistai.
Toks įvertinimas nėra bandymas sustabdyti idėją. Jo tikslas – padėti išsaugoti tai, kas prototipe vertinga, ir pašalinti rizikas, kurios vėliau gali kainuoti gerokai daugiau nei profesionali peržiūra pačioje pradžioje.