IT sistemos auditas: 122 iš 125 lentelių buvo tuščios
Platforma, parduodama kaip 220 000 kodo eilučių ir 164 API galiniai taškai, iš esmės buvo tik sąsajos apvalkalas. Kaip tai nustatėme ir ko turėtų prašyti pirkėjas.
AFKzona Group · 5 min. skaitymo
Trumpas atsakymas
- Duomenų turėjo tik 6 iš 125 duomenų bazės lentelių – iš viso 286 įrašai, tarp jų 21 pasikartojantis dokumento numeris.
- Serverio pusės autorizacija paties projekto dokumentuose pažymėta kaip „laukiama“, o numatytasis administratoriaus slaptažodis atviru tekstu buvo įrašytas dokumentacijoje ir testų skriptuose.
- Ataskaitoje vertingos dalys įvardytos taip pat aiškiai kaip trūkumai, ir prieš pasirašymą šie faktai tapo derybų pozicija.
- Techninis patikrinimas sulygina teiginius su kodu ir duomenų baze, o tada – su veikiančia sistema. Vien dydžio rodikliai nieko neįrodo.
Pirkėjas paprašė mūsų prieš pasirašant sandorį peržiūrėti personalo valdymo platformą. Ji buvo pateikta kaip 220 000 kodo eilučių, 253 puslapiai ir 164 API galiniai taškai. Techninis patikrinimas parodė, kad tai iš esmės tik vartotojo sąsajos apvalkalas: 122 iš 125 duomenų bazės lentelių buvo tuščios, prieigos teisės tikrinamos tik naršyklėje, o didelė dalis verslo logikos, be kurios personalo platforma neįsivaizduojama, dar nebuvo parašyta. Rašytinę ataskaitą DOCX ir HTML formatais pirkėjas turėjo dar prieš priimdamas sprendimą.
Šioje atvejo analizėje paaiškiname, kaip priėjome prie šios išvados, ką reiškė skaičiai ir ko kiekvienas programinės įrangos pirkėjas turėtų paprašyti prieš mokėdamas pinigus. Pirkėjo, pardavėjo ir produkto tapatybė lieka konfidenciali.
Kas yra techninis patikrinimas?
Techninis patikrinimas (angl. technical due diligence) – tai nepriklausoma programinės įrangos peržiūra prieš ją perkant, investuojant į ją ar pasirašant didelę sutartį. Pardavėjo teiginius sulyginame su tuo, ką rodo kodas, duomenų bazė ir veikianti sistema. Rezultatas – rašytinė ataskaita, kurioje rizikos surikiuotos pagal svarbą ir nurodyta, kiek kainuotų jas pašalinti.
Tai ne kodo kokybės įvertinimas. Patikrinimas atsako į pirkėjo klausimą: ar ši programinė įranga daro tai, ką man apie ją sako, ir kiek kainuos, kad ji iš tikrųjų tai darytų? Sistemos kodas gali būti tvarkingas, o ji pati – tuščia. Ir atvirkščiai: netvarkingas kodas gali aptarnauti veikiantį verslą.
Kaip platforma buvo pateikta?
Platforma buvo pristatoma kaip dirbtiniu intelektu paremta personalo valdymo sistema, apimanti tiekėjų valdymą, kandidatų atranką ir projektų valdymą, ir lyginama su didelėmis įmonių sistemomis. Pagrindiniai skaičiai rodė apimtį: apie 220 000 kodo eilučių, 253 puslapiai ir 164 API galiniai taškai, o šalia – 334 dokumentacijos failai.
Apimties skaičius lengva sukurti ir lengva jais patikėti. Jie parodo, kiek parašyta, bet ne tai, ką sistema daro. Mūsų užduotis buvo kiekvieną teiginį paversti tokiu, kurį galima patikrinti.
Dokumentacija – irgi teiginys, o ne įrodymas. Didelė jos apimtis gali atrodyti kaip brandos ženklas, tačiau dokumentuose aprašoma tai, kas buvo suplanuota ar norėta padaryti, ir nebūtinai tai, kas iš tikrųjų sukurta. Todėl kiekvieną dokumentacijoje minimą funkciją tikrinome taip pat, kaip ir pardavimo medžiagos teiginius: ieškojome jos kode, duomenų bazėje ir testuose. Kai dokumentai vienas kitam prieštaravo, užfiksavome abi versijas, o galutinį atsakymą davė kodo saugykla.
Kaip tikrinome: teiginiai, kodas, veikianti sistema
Mūsų metodą sudaro trys sluoksniai, ir kiekvienas teiginys turi atlaikyti visus tris. Pirmiausia surašome teiginius tiksliai taip, kaip jie pateikti. Tada kiekvieną tikriname pagal kodo saugyklą ir duomenų bazę. Galiausiai – veikiančioje sistemoje, taip, kaip su ja susidurtų tikras naudotojas. Jei teiginys neatlaiko ankstesnio sluoksnio, klausimas išsprendžiamas jame.
| Sluoksnis | Ką tikriname | Į kokį klausimą atsako |
|---|---|---|
| Teiginiai | Pardavimo medžiaga, dokumentacija, būklės ataskaitos | Ką tiksliai žadama? |
| Kodas ir duomenų bazė | Išeities kodas, istorija, schema, įrašų skaičius, testai | Ar tai sukurta ir ar užtikrinama serveryje? |
| Veikianti sistema | Įprasto naudotojo paskyra veikiančioje aplinkoje | Ar visa grandinė veikia su tikrais duomenimis? |
Sąsajos apvalkalas – tai priekinė sistemos dalis, kuri įtikinamai rodo ekranus, tačiau už jų nėra nei veikiančios verslo logikos, nei tikrų duomenų. Taip nutinka, kai pirmiausia kuriami ekranai, o po jais esanti sistema atidedama vėlesniam laikui.
Šios platformos atveju atotrūkis išryškėjo jau antrajame sluoksnyje:
- Duomenų bazė. Schemoje buvo aprašytos 125 lentelės. 122 iš jų neturėjo nė vieno įrašo. Duomenų turėjo tik 6 lentelės, iš viso 286 įrašai. Tarp esamų duomenų rasta 21 pasikartojantis dokumento numeris, o 22 lentelės neturėjo pirminio rakto.
- Galiniai taškai. Visi 164 API galiniai taškai egzistavo kaip maršrutų aprašai, tačiau daugelis jų grąžino imituotus ar tiesiai į kodą įrašytus duomenis – tai pripažino ir paties projekto dokumentacija.
- Verslo taisyklės. Personalo platformos vertė – įkainiai, maržos, sąskaitos ir atitiktis. Visa aprašyta verslo logika – šešios formulės, iš jų penkios – paprasta aritmetika. Maržos skaičiavimo ir mokėjimų apdorojimo nebuvo.
- Baigtumas. Paties projekto dokumentuose to paties produkto baigtumas nurodytas nuo 71 % iki 100 % – priklausomai nuo to, kurį dokumentą skaitysi.
Ką parodė saugumo peržiūra?
Prieigos teisės buvo tikrinamos tik naršyklėje. Paties projekto dokumentuose serverio pusės autorizacija pažymėta kaip „laukiama“, taigi bet kuris naudotojas, kreipdamasis tiesiai į API, galėjo apeiti rolių patikras. Numatytasis administratoriaus slaptažodis atviru tekstu buvo įrašytas keliuose dokumentacijos failuose ir testų skriptuose, o gamybinės aplinkos saugumo kontrolinis sąrašas liko nepažymėtas.
Serverio pusės autorizacija reiškia, kad pats serveris kiekvienos užklausos metu tikrina, ar šis naudotojas turi teisę atlikti šį veiksmą. Patikras, esančias tik naršyklės kode, gali apeiti bet kas, siunčiantis užklausas tiesiogiai. OWASP netinkamą prieigos kontrolę savo „Top 10“ sąraše nurodo kaip pirmąją riziką.
Prototipui tai nėra neįprasta. Problema atsiranda tada, kai prototipas įkainojamas ir parduodamas kaip platforma.
Ką gavo pirkėjas?
Pirkėjas gavo rašytinę ataskaitą dviem formatais: DOCX failą savo patarėjams ir HTML versiją skaityti ekrane. Ataskaitoje atskirta, kas egzistuoja ir verta išsaugoti, o ko nėra; kiekvienas teiginys pateiktas šalia įrodymų, o spragos surikiuotos pagal riziką sandoriui.
Sprendimą ataskaita paliko pirkėjui ir tiksliai parodė, ką jis pirktų. Vertingos dalys įvardytos aiškiai: tikra duomenų schema, ant kurios galima statyti, veikiantys pagrindinių įrašų kūrimo, peržiūros, keitimo ir trynimo ekranai, balso agento integracija, kuri buvo viena išbaigtesnių funkcijų, ir keli pagrįsti architektūrinių sprendimų aprašai.
Peržiūros vertę lėmė jos laikas. Po pasirašymo tie patys faktai būtų virtę ginču. Prieš pasirašymą jie tapo derybų pozicija.
Ko prašyti prieš pasirašant?
Prašykite prieigos, o ne patikinimų. Savo programine įranga pasitikintis pardavėjas gali suteikti skaitymo prieigą prie kodo saugyklos, duomenų bazės schemą su įrašų skaičiumi, veikiančią aplinką ir testų rezultatus. Jei negali – tai jau išvada. Jei produktas toks, kokį jį pristato, pardavėjui šie prašymai nieko nekainuoja.
- Prieigos prie kodo saugyklos su visa istorija. Ne ZIP archyvo. Istorija parodo, kas, ką ir kada kūrė ir ar sistema prižiūrima.
- Duomenų bazės schemos su įrašų skaičiumi kiekvienoje lentelėje. Tuščios lentelės išduoda funkcijas, kurios egzistuoja tik ekrane.
- Įprasto naudotojo paskyros veikiančioje aplinkoje. Ne surežisuotos demonstracijos, o galimybės pačiam spausti ir eiti savo pasirinktais keliais.
- Testų ir paskutinių jų rezultatų. Jei testų nėra, niekas neįrodė, kad verslo taisyklės veikia.
- Informacijos, kur užtikrinama autorizacija. Paprašykite parodyti serverio pusės patikrą bent vienam jautriam veiksmui.
- Visų išorinių paslaugų ir prisijungimų sąrašo. Kas laiko raktus ir kiek kainuoja sistemos eksploatacija.
Kodo eilučių, puslapių ir galinių taškų skaičių vertinkite kaip dydžio, o ne vertės rodiklį. Klausimas visada tas pats: ką sistema daro su tikrais duomenimis ir ar daro tai saugiai.
Nepriklausoma peržiūra prieš pasirašant
Techninį patikrinimą atliekame nuo 2 500 €, kodo peržiūrą ir saugumo auditą – nuo 1 500 €. Kiekvienam darbui raštu sutariame fiksuotą kainą, o rezultatas – rašytinė ataskaita, kurioje rizikos surikiuotos pagal svarbą. Kaip atliekame peržiūras ir auditus, aprašyta skiltyje kodo peržiūros, auditai ir techninis patikrinimas. Norėdami aptarti pirkimą ar investiciją, užsisakykite nemokamą 30 min. pokalbį.
Dažni klausimai
Kas yra techninis programinės įrangos patikrinimas?
Tai nepriklausoma programinės įrangos peržiūra prieš ją perkant, investuojant į ją ar pasirašant didelę sutartį. Pardavėjo teiginiai sulyginami su kodu, duomenų baze ir veikiančia sistema, o rizikos aprašomos raštu: kas veikia, ko trūksta, kas nesaugu ir kiek kainuotų tai sutvarkyti.
Ko prašyti prieš perkant IT platformą ar investuojant į ją?
Skaitymo prieigos prie kodo saugyklos su visa jos istorija, gamybinės duomenų bazės schemos kopijos ar skaitymo prieigos prie jos su įrašų skaičiumi kiekvienoje lentelėje, prieigos prie veikiančios aplinkos su įprasto naudotojo paskyra, išorinių paslaugų ir prisijungimų sąrašo bei testų ir paskutinių jų rezultatų. Jei pardavėjas to pateikti negali, tai jau savaime yra išvada.
Kas parodo tikrąją programinės įrangos vertę?
Ar verslo taisyklės įgyvendintos ir užtikrinamos serveryje, ar per sistemą juda duomenys ir ar ji ištestuota. Kodo eilučių, puslapių ir galinių taškų skaičius parodo apimtį: šioje peržiūroje platformos, deklaruotos kaip 220 000 eilučių ir 164 galiniai taškai, 122 iš 125 duomenų bazės lentelių buvo tuščios.
Kiek kainuoja IT sistemos auditas prieš investiciją?
AFKzona Group techninis patikrinimas kainuoja nuo 2 500 €, o fiksuotą kainą raštu sutariame prieš pradėdami darbą. Rezultatas – rašytinė ataskaita, kurioje rizikos surikiuotos pagal svarbą. Fiksuotą kainą nustatome pagal kodo bazės dydį ir tai, su kiek sistemų ji susieta.
Ką apima techninio patikrinimo ataskaita?
Kiekvieną teiginį šalia įrodymų iš kodo, duomenų bazės ir veikiančios sistemos; atskirai – kas egzistuoja ir verta išsaugoti, o ko nėra; spragas, surikiuotas pagal riziką sandoriui, su jų pašalinimo kaina. Ataskaitą pateikiame DOCX failu patarėjams ir HTML versija skaityti ekrane.