Kellele läbistustestimine sobib?
Pentest on mõistlik ettevõttele, kelle veebirakendus või API käsitleb kliendiandmeid, tellimusi, makseid või erinevate õigustega kasutajaid. Näiteks e-pood, kliendiportaal ja partneritele avatud API vajavad enamat kui avalehe tehniliste päiste kontrolli. Ettevõtte suurusest olulisemad on andmete väärtus ja süsteemi kaudu tehtavad toimingud.
Test tasub läbi mõelda enne olulist väljalaset ning pärast sisselogimise, rollide, maksevoo või integratsiooni muutmist. Kui põhilised uuendused ja ligipääsud on korrastamata, võib esmalt olla kasulikum küberaudit ja parandusplaan. Kaardistuses valime, kas vaja on aktiivset testi või laiemat turvaseisu ülevaadet.
Millise otsuse aitab läbistustest teha?
- Enne avalikustamist: millised kinnitatud nõrkused tuleb enne kliendiportaali või uue API avamist parandada?
- Pärast muudatust: kas uued rollid, sisselogimine või kasutajavoog võivad avada ligipääsu andmetele või toimingutele, mida kasutaja ei tohiks saada?
- Arendustööde planeerimisel: milline leid on tegelikult ärile oluline ning milline automaatne hoiatus vajab esmalt kontrollimist?
- Paranduste järel: kas konkreetne tõendatud nõrkus on kokkulepitud kordustestis kõrvaldatud?
Raport aitab põhjendada paranduste järjekorda ja dokumenteerida testitud ulatust. See ei anna automaatselt vastavust NIS2-le või mõnele standardile ega tõenda, et kõik süsteemid on turvalised. Kohustuste ülevaate leiad NIS2 juhendist.
Mida saab pentestis kokku leppida?
Ulatuse (scope) keskmes on täpselt nimetatud veebirakendus või API: veebiaadress, API baas-URL, valitud funktsioonid ja testkontod. Loetleme domeenid ja keskkonnad, mida tohib kontrollida, ning välistame kõik, mis pole loas nimetatud.
- Veebirakenduse pentest: sisselogimine, rollide ja kasutajate õigused, seansihaldus, sisendite käsitlemine ning kasutajavoogude äriloogika. Veebilehe ja e-poe turvatestimise juhend aitab olulised vood välja valida.
- API pentest: autentimine, objektide ja funktsioonide juurdepääsukontroll, andmete nähtavus ning päringupiirangud. API turvatestimise juhend näitab rollide ja klientide õiguste maatriksit ning vajalikke sisendeid.
- AI-funktsiooniga rakendus: kokkulepitud päringute ja andmevoogude kontroll, näiteks rakenduse juhiste või ühendatud allika sisu mõju vastusele ja andmete avaldamisele. See ei ole kõigi mudeli- ja taristuriskide tervikhindamine.
Black-box, grey-box või white-box pentest?
Black-box ehk musta kasti test algab vähese taustainfoga. Grey-box ehk halli kasti test kasutab valitud testkontosid või arhitektuuriinfot. White-box ehk valge kasti test saab kokkulepitud dokumentatsiooni või kooditeavet. Need on lähteinfo valikud, mitte automaatselt pakutavad paketid: sobiv lähenemine ja teostatavus kinnitatakse pakkumises.
Kirjalik luba ja reeglid enne testimist
Enne aktiivset testimist kinnitame kirjalikult, et tellijal on õigus nimetatud süsteemi testimiseks luba anda. Samas dokumendis või kokkuleppes määratleme sihtmärgid, testimisakna, kontaktisiku ja lubatud tegevused. Kolmandale osapoolele kuuluvaid süsteeme ei testita tellija üldise loa põhjal, kui puudub vajalik omaniku luba.
Et test ei häiriks tavakasutajaid ega kahjustaks andmeid, lepime läbi testkontod ja nende rollid, võimalusel staging-keskkonna ehk tootmisele sarnase testkeskkonna, koormuspiirangud, keelatud tegevused ning peatamise tingimused. Näiteks võivad keelatud olla teenusetõkestuse katsed, päris kasutajate andmete muutmine, masspäringud või kolmanda osapoole makseteenuse kontroll. Kui märkame ettenägematut mõju, peatame vastava tegevuse ja võtame kokkulepitud kontaktiga ühendust. Töö algab alles siis, kui ulatus, hind ja ajastus on kokku lepitud.
Kuidas läbistustestimine käib?
Eesmärk ja sihtmärgid
Kaardistame süsteemi, olulised kasutajateed ja küsimuse, millele test peab vastama. Väljund: kokkulepitud sihtmärgid, eesmärk ja esialgne ulatus.
Luba ja ettevalmistus
Kinnitame testkontod, lubatud tegevused, ajavahemiku, kontaktid ja peatamise tingimused. Väljund: kirjalik testimisluba ja piirid, mille järgi töö toimub.
Test ja leidude kinnitamine
Tööriistad ja agendid aitavad nõrkusi otsida; olulised tulemused kontrollib inimene. Väljund: kinnitatud leiud koos nende tõendite ja mõjuga, mitte pelk skannerihoiatus.
Raport ja järgmised sammud
Seome leiu soovitatud parandusega ja paneme tööd tähtsuse järjekorda. Väljund: raport ning pakkumises kokku lepitud paranduste kordustest.
Miks valida Tehisabiline?
Meie töö keskmes on kokkulepitud piirid, oluliste leidude inimese ülevaatus ja parandamiseks kasutatav väljund. Tehnilised tööriistad ja agendid aitavad kontrollidega; lõppjäreldus ei põhine üksnes skannerihoiatusel. Raport seob leiu tõendi, mõju ja parandussoovitusega.
Enne tellimist näed siin näidisleiu välju, pakkumiseks vajalikke sisendeid ja testimise reegleid. Ettevõtte ning vastutaja info on Meist-lehel. Hinna, testimisakna ja kordustesti tingimused kinnitame enne töö algust, et oleks selge, mis teenuses sisaldub.
Mida raport sisaldab?
Raportis on testitud süsteemide ja piiride kokkuvõte, kasutatud eeldused ja olulised piirangud, kinnitatud leidude kirjeldused ning parandamise soovitused. Iga leiu juures selgitame, kus see paikneb, millised tõendid seda toetavad, millist mõju see võib võimaldada ja mida teha riski vähendamiseks. Leiud järjestame mõju ja parandamise kiireloomulisuse järgi; hinnang ei ole lubadus, et kõigis süsteemi osades otsiti kõike.
- Viide
- WEB-EXAMPLE-01
- Leid
- Testkontoga pääseb teise testkonto näidisobjektile.
- Tõend
- Kokkulepitud testkeskkonnas tehtud päringute võrdlus; päris kasutajaandmeid ei kasutatud.
- Mõju ja parandus
- Kontrolli objekti omandiõigust serveris iga päringu puhul ning lisa regressioonitest.
Järeltest (retest) tähendab kokkulepitud leiu paranduse uuesti kontrollimist, mitte kogu algse testi kordamist. Pakkumises lepime kokku, kas ja milliste leidude parandusi üle vaatame, mis ulatuses ning millise ajavahemiku sees. Uued funktsioonid või ulatusevälised süsteemid vajavad eraldi kokkulepet.
Pentestimise hind: millest pakkumine sõltub?
Hind sõltub sihtsüsteemidest, kasutajarollidest ja -voogudest, API otspunktide ulatusest, testimise sügavusest ning raporti ja kordustesti mahust. Testkontod ja dokumentatsioon aitavad töö täpsemalt piiritleda. Avalikku standardhinda meil ei ole; tasu ja ajakava kinnitame konkreetse ulatuse järgi.
Mida esimeses päringus kirjeldada?
- Süsteem: veebirakendus või API, avalik aadress ja äriline kasutus.
- Eesmärk: näiteks sisselogimine, kliendiandmete eraldatus või maksevoo õigused.
- Ettevalmistus: testkeskkond, testkontod ja nende rollid; API kirjeldus, kui see on olemas.
- Aeg ja järelkontroll: sobiv ajavahemik ning kas vajad paranduste kordustesti.
- Luba: kes saab kinnitada omaniku nõusoleku ja testimise piirid?
Esimesse e-kirja ära lisa paroole, API-võtmeid ega kliendiandmeid. Vajalikud ligipääsud jagatakse hiljem kokkulepitud viisil. Saada pakkumise päring.
Küberaudit, pentest või skanner?
| Lähenemine | Põhiküsimus | Tüüpiline väljund |
|---|---|---|
| Pentest | Kas kokkulepitud sihtmärgis saab nõrkust piiride sees ära kasutada? | Tõendatud leiud, mõju ja parandused |
| Küberaudit | Milline on laiem turvaseis kokkulepitud protsesside ja seadistuste lõikes? | Laiem ülevaade ja prioriteetne parandusplaan |
| Skanner | Kas tuntud tehnilised mustrid või versioonid vajavad tähelepanu? | Automaatne kontrolltulemus, mis vajab konteksti ja kinnitamist |
Valik sõltub küsimusest: skanner sobib korduvaks tehniliseks kontrolliks, pentest uurib kokkulepitud sihti aktiivselt ning audit vaatab tavaliselt laiemat pilti. Need võivad teineteist täiendada, kuid pole samatähenduslikud.
Mida pentest ei tõesta?
Testi tulemus kirjeldab kindla ajahetke, antud ligipääsude ja kokkulepitud piiride sees tehtud tööd. Test võib jätta leidmata harva käivituva vea, testimata funktsiooni või muutuva sõltuvuse probleemi. Hea tulemus ei tõesta, et süsteem on ründekindel, et haavatavusi pole või et tulevikus intsidenti ei juhtu. Samuti ei ole pentest sertifikaat ega vastavuse garantii.
Ulatuse ja meetodite valikul lähtume sobivuse korral avalikest metoodikatest nagu OWASP Web Security Testing Guide ning NIST SP 800-115. Need annavad kasuliku raamistiku, kuid viide ei tähenda automaatselt kogu standardi katmist ega sertifitseeritud vastavushindamist.
Küsimused pentestimise kohta
Kas läbistustestimine ja pentesting tähendavad sama?
Jah. Läbistustestimine, pentestimine, läbitungimistest ja ingliskeelsed penetration testing ning pentesting kirjeldavad sama põhieesmärki: hinnata kokkulepitud sihtmärkides nõrkuste ärakasutatavust. Täpne ulatus ja lubatud tegevused kinnitatakse siiski eraldi; nimetus ei tähenda kõigi süsteemide täielikku kontrolli.
Kas testite tootmiskeskkonda?
Ainult siis, kui omaniku kirjalik luba hõlmab tootmiskeskkonda ning riskid, tegevused ja testimisaken on kokku lepitud. Sobiva testkeskkonna olemasolul hindame selle kasutamist enne.
Kas test hõlmab kogu ettevõtte võrku või mobiilirakendust?
See teenus kirjeldab veebirakenduse ja API kokkulepitud testimist. Võrk ja mobiilirakendus ei kuulu automaatselt ulatusse; kirjelda vajadust ning kinnitame enne, kas seda saame testida.
Kui kaua pentest kestab?
Ajastus sõltub ulatusest, ligipääsudest, keskkonna valmisolekust ja sügavusest. Kinnitame ajakava pakkumises, mitte üldise tähtajana.
Kas parandate leitud vead?
Raport selgitab soovitatud parandusi. Rakenduse muutmine ei kuulu testimise hulka, kui seda pole eraldi kokku lepitud. Ka paranduste kordustesti ulatus kinnitatakse pakkumises.
Kuidas alustada?
Kirjuta [email protected]. Kirjelda rakendust või API-t, eesmärki, testkeskkonna ja testkontode võimalust ning sobivat ajavahemikku. Ära saada esimeses kirjas paroole ega tundlikke andmeid.