IKT lahendusel põhineva teenuse käitamine

Sissejuhatus

IKT teenuse käitamise eesmärk on pakkuda võimalikult palju etteantud turvalisuse tasemega teenust.

Väited

• käesolev tekst tegeleb IKT teenuse käitamisega seotud probleemidega; ei tegele teenuse sisulise ettevalmistamisega või arendamisega
• käesolev tekst püüab anda IKT teenuse käitamisest mõtlemisele ja tegevustele raamistiku
• mitte-loomingulised asjad tuleb teha rutiiniks; ja asjad mida on raske formaliseerida lahendatakse improviseerides

Mõisted

• teenus - kliendile antud võimalus kasutada üle andmeside võrgu mingit teenuse pakkuja poolt ettevalmistatud funktsionaalsust; reeglina klient eeldab põhjendatult, et teenus töötab nö kogu aeg (kuigi sla (service level agreement) võib seda täpsustada)
• rakendus - tarkvara/programm, mida teenuse pakkumisel kasutatakse (võib olla rakenduskihi tarkvara või ka nt esitluskihi või andmekihi)
• teenuskomponent - kliendile pakutavat abstraktsemat teenust moodustav komponent (võrk, operatsioonisüsteem, rakendus või toetav teenus)
• teenuskomponendi töökorrasus - teenuskomponent võib iseenesest olla töötamise võime osas kahes olekus, korras või katki; töökorrasuse väärtus määratleb milline variant parasjagu aset leiab
• rakenduskomponent - rakendust moodustavad komponendid (nt http staatilist osa serveeriv veebiserver, http dünaamilist osa serveeriv veebiserver, andmebaas)
• rakenduskomponendi töökorrasus
• rünne - teenuskomponendi töötamise tahtlik häirimine
• avastatus - kas midagu on avastatud või mitte (nt mingi oleku väärtus või oleku väärtuse muutus)

Teenuse töötamine ja võimalus teenust kasutada sõltub üldiselt kuuest komponendist (teenuskomponendist; st nende töökorras olekust ehk töökorrasusest)

• teenusega seotud rakendus töötab (rakendus võib omakorda jaguneda rakenduskihis töötavaks rakenduseks ja andmbaasi kihis töötavaks rakenduseks jne, neid nimetatakse rakenduskomponentideks)
• teenusega seotud operatsioonisüsteemi keskkond töötab
• teenusega seotud võrk töötab
• teenusega seotud toetavad süsteemid töötavad
• teenuse pakkuja vastu teostatud rünne on kontrolli all (st ründe tingimustes suudab teenuse pakkuja oma teenust internetis esitleda)
• teenust kasutav klient vastab nõuetele (ta kasutab sobivat riist-ja tarkvara, sobiva võrguühenduse küljes, omab vajalikke arvutikasutamise oskusi ja teenuse kaustamiseks vajalikke privileege)

Väited

• käeolevas tekstis mõnel juhul eelistatakse mõistet 'töökorrasus' kuna see on neutraalsem kui nt 'töötamine'; st töökorrasuse kontrolli tulem võib olla loomulikumal viisil positiivne ja negatiivne
• käesolev tekst jääb üldiselt sellisele abstraktsioonitasemele, kus kõneldakse teenuskomponentidest; aga rakenduskomponente üldiselt ei käsitleta

Tööpõhimõte

Teenuse kasutamise seisukohast saab eristada kahte teenuse olekut

• teenuse töötamine (nt see sisaldab nii rakenduse korrektset töötamist kui ka ebaõnnestunud rünnet, st rünne taustal toimub aga vääratakse edukalt)
• teenuse mitte-töötamine (nt see sisaldab nii rakenduse mitte-korrektset töötamist kui ka õnnestunud rünnet, st rünne toimub aga ei väärata edukalt)

Teenuse pakkumise seisukohast sobib lisaks teenuse olekut täpsustada kolme mõõtmega

• teenuskomponentide töökorrasus - kas rakendus, operatsioonisüsteem, võrk ja toetavad süsteemid ise töötavad korrektselt või mitte (nt ei ole nö iseenesest katki kuna on valesti seadistatud)
• rünne - kas toimub mingi kihi vastu ebaõnnestunud või õnnestunud rünne
• avastatus - kas käesolev teenuse olek, teenuskomponendi töökorrasus või rünne on avastatud või mõtte (nt toimib edukas rünne, mis ei ole avastatud)

Igal ajahetkel saab teenuse oleku määratleda ja seda olekut täpsustada. Kui teenuse olek muutub või muutuvad olekut täpsustavad väärsused, käivitatakse vastavad tegevused (nt algab rünne, sellele vastuseks käivituvad rünnet neutraliseerivad meetmed ning teenuse pakkumine seejuures ei kannata).

IKT teenuse ettavalmistamisel tuleb kõigi teenuskomponentidega tegelemisel pöörata tähelepanu

• kuidas töökorrasus tekitada
• kuidas töökorrasust säilitada
• kuidas töökorrasus ja muutus töökorrasuse olekus on avastatav (jälgitav)
• kuidas rünne on avastatav
• kuidas ründe iseloomu ja mõju täpsustada
• töökorrasuse riknemise põhjuse tuvastamine
• ründe edu põhjuse tuvastamine
• kuidas rünne väärata
• ründega seotud kahju hindamine
• kuidas ründega seotud asitõendeid koguda
• kuidas töökorrasus taastada
• kuidas ründe allikas neutraliseerida

Edasine tekst saaks tegeleda detailsema käsitlusega kahes vaates, valitud on esimene variant

• tegeldakse iga teenuskomponendi kaupa ründe, töökorrasusega, avastatavusega jne
• tegeldakse ründe, töökorrasuse, avastatavuse jne kaupa kõigi teenuskomponentidega

Väited

• avastatus iseenesest ei mõju kuidagi teenuse olekule
• avastatus on eelduseks teenuse olekut muutvate tegevuste käivitamiseks
• teenus töötab kui ühelt poolt on teenuskomponentide töökorrasus piisavalt hea ja teiselt poolt rünne piisavalt hästi ära hallatud
• olematu ründe haldamiseks ei ole vaja teha pingutusi
• üldiselt avastatakse rünne mitte otseselt vaid kaudselt, st ründe mõju järgi
• rünne toimub teenuskomponendi suhtes
• rünne ei pruugi toimida ainult ühe konkreetse teenuskomponendi suhtes vaid mitme (nt võrk + operatsioonisüsteem)
• töökorrasusest kõneldakse seoses ühe või teise teenuskomponendiga
• teenuse pakkumise seisukohast on otstarbekas eristada nt rakenduse korrektset töötamist ja ebaõnnestunud rünnet seepärast, et nende juhtumite puhul käivituvad erinevad teenuse pakkuja poolsed protseduurid; kuigi kasutajale välja paistev tulemus on sama
• lisaks ründele võib teenuskomponent minna katki ka nö iseenda raskuse all (nt kui kasutaja teadmatusest esitab rakendusele ebakorrektse sisendi, rakendus ei valideeri sisendit ja selle tõttu rakendus krahhib; valiti ebamõistlik arhitektuur, seadistati valesti võrguseadmeid)
• ikt teenuse edukale käitamisele aitab kaasa arusaamine süsteemi ressursikasutusest ja rakendust moodutavate komponentide omavahelistest seostest; ja siseste ja süsteemi väliste komponentide vahelisest suhtlemisest
• rakenduse korrektse töötamise avastamisele vastab logikirje rakenduse logifailis ja korrektse töötamise mitte-avastamisel selline logikirje puudub
• rakenduse korrektse töötamise mitte-avastamine ei ole eriti hull; ünnestunud rünne on halb, aga seda leevendab kui rünne avastati; õnnestunud ja mitte-avastatud rünne on väga halb

Teenuskomponentide ründed vastavad erinevatele kihtidele

• võrk - ründe eesmärgiks on segada teenuse pakkumist, nt sellega, et täidetakse teenusega seotud võrgukanali maht (nt random src syn-flood, udp-flood vms pakettidega)
• operatsioonisüsteem - ründe eesmärgiks on kulutada selle operatsioonisüsteemi ressurssi või saada ligipääs os ressursi kasutamiseks (nt kasutada tls haavatavusi)
• rakendus - ründe eesmärgiks on volitama ligipääs andmete sisestamiseks; ründe eesmärgiks on rakendust krahhida andes rakendusele eksitavat sisendit

Seejuures ühte või teist liiki sündmuste esinemine ei ole ainult teenuse pakkuja kontrollida, see sõltub ka kasutaja käitumisest (nt mis sisendit ta teenusele esitab). Õnnestunud mitte-avastatud ründe absoluutne vältimine ei ole otseselt võimalik (juba sellepärast, et kui miski pole avastatav, siis on juba keeruline temast kõneleda), aga selle tõenäosuse vähendamine toimub kõigi muude variantide esinemise tõenäosuse suurendamise teel. (Kusjuures samas, õnnestunud mitte-avastatud ründe tõenäosuse suurendamine on kergesti võimalik, jätta ssh port lahti, root kasutajana saab sisse, logitakse /dev/null seadmesse; sel juhul ainult ei tohi ründaja ise midagi väga nähtavat ise teha, nt arvutit reinstallida.)

Erinevate sündmuste toimumise tõenäosusele mõjuvad erinevad meetmed, nt

• rakenduse korrektne töötamine, mis on avastatud - sobiv operatsioonisüsteemi keskkond, sobival määral kasutada arvutusressurssi, kvaliteetne rakendustarkvara, sobiv võrk
• ebaõnnestunud rünne, mis on avastatud - sama mis eelmine, kuid ründe toimumise tingimustes toimisid oodatult os keskkonda ja võrku täiendanud ründe vääramise ja tuvastamise vahendid
• õnnestunud rünne, mis on avastatud - sama mis eelmine, kuid vääramise osa oli ebapiisav

Lisaks saab avaldab teenuse töötamisele mõju selle teenuse pakkumist abistavate komponentide töötamine - nt teenuse domeeninime teenindavate pädevate nimeserverite töö (sarnaselt ntp ja ocsp).

Teenuse käitamisega tegeledes peaks suutma eristada

• nö interneti müra - google vms indekseerijad teevad http päringuid
• juhusliku valitud target'i ründamine - bot'id püüavad avastada ligipääsetavaid ressursse
• sihitud rünne - tegeldakse konkreetse teenusega

Üldiselt peaks arvestama kahte põhimõtet

• süsteeme ei maksa disainida ülemäära keeruliseks (et nad kukuvad kokku ise enda raskuse all)
• turvalisus töötab kihiliselt (ebaõnnestumine rünnet takistada võrgu kihis võib õnnestuda rakenduse kihis)

Rakendus

Väited

• ründe eesmärgiks on volitama ligipääsuta andmete kopeerimine/muutmine/kustutamine/sisestamine
• ründe eesmärgiks on rakendust krahhida andes rakendusele eksitavat sisendit
• ründega ei kaasne märkimisväärse mahuga võrguliiklust
• rakendus ise saab kõige paremini aru kui toimub rakenduse taseme rünne

Töökorrasuse tekitamine

• rakendus on iseenesest kvaliteetne
• rakenduse töökorrasuse tekitamise vastutab süsteemiadministraator
• rakendus on korrektselt seadistatud (nt kasutama os ressursse, kasutajaprivileegid, mälu jne)
• rakenduse seadistustega saab kitsendada klientide teenindamist (nt samalt ip aadressilt teenindatakse mingit arvu samaaegseid teenuse kasutuskorraga seotud sessioone)
• rakenduse kõrgkäideldavus on seadistatud korrektselt (koostöös operatsioonisüsteemi ja võrguga)

Töökorrasuse säilitamine

Muudatuste tegemisel tuleb eelnevalt veenduda, et need süsteemi olukorda paremaks teevad, või vähemalt ei tee hullemaks

• rakendusele paranduste regulaarne ja vastavalt vajadusele erakorraline rakendamine

Töökorrasuse jälgimine

• vastutab monitooringu adminstraator
• rakendus tekitab kvaliteetset kasutus ja vealogi
• kogutakse nö baseline väärtusi

Ründe avastamine

• vastutab monitooringu administraator
• rakendus tekitab kvaliteetset kasutus ja vealogi
• loetakse ajakirjandusest

Ründe iseloomu ja mõju täpsustamine

• vastutab süsteemiadministraator
• logi uurimine
• rakenduse protsesside tegevuse lähem uurimine

# ps aux
# lsof -n
# netstat -lnpa
# strace -p PID
# auditd
# tcpdump

Ründe vääramine

• vastutab süsteemiadministraator
• rakenduse seadistuse muutmisega kitsendatakse klientide teenindamist (nt samalt ip aadressilt pöördumisi)
• rakenduse parandatud versiooni juurutamine
• rakenduse logi alusel blokeeritakse rakenduse taseme rünnet võrgu kihis (nt pahalase src ip blokeerimine)
• operatsioonisüsteemi kihi abi kasutamine (nt apparmor)

Ründega seotud asitõendite kogumine

• vastutab süsteemiadministraator
• varundatud rakenduse andmed
• võrguliikluse salvestis

Kahju hindamine

• millal rünne toimus ja millise kestusega
• logi alusel
• erinevate ajahetkede varundusi kõrvutades

Operatsioonisüsteem

Väited

• operatsioonisüsteemi taseme ründe eesmärk on saada ligipääs teenust pakkuva keskkonna ressurssidele (see võimaldab korraldada platvormi kasutades uusi ründeid ning pääseda ligi rakenduse andmetele)

Töökorrasuse tekitamine

• vastutab süsteemiadministraator
• riistvara on kvaliteetne
• firmware on kvaliteetne
• operatsioonisüsteem on kvaliteetne
• operatsioonisüsteem on korrektselt seadistatud

Instrumendid

• secure boot
• apparmor
• unix kasutaja privileegid
• ulimit
• systemd

Töökorrasuse säilitamine

Muudatuste tegemisel tuleb eelnevalt veenduda, et need süsteemi olukorda paremaks teevad, või vähemalt ei tee hullemaks

• riistavarale firmware uuenduste rakendamine
• operatsioonisüsteemile paranduste regulaarne ja vastavalt vajadusele erakorraline rakendamine

Töökorrasuse jälgimine

• vastutab monitooringu adminstraator
• rakendus tekitab kvaliteetset kasutus ja vealogi lokaalselt ja üle võrgu logiserverisse

Monitooring jälgib kokkulepitud operatsioonisüsteemi parameetrite väärtusi

• cpu
• io
• võrk (võrguühendustele vastav conntrack sissekannete arv, ühenduste tekitamise ajaühikus)
• mälu
• protsesside ja threadite arv

Ründe avastamine

• vastutab monitooringu adminstraator
• op süsteem tekitab kvaliteetset kasutus ja vealogi
• op süsteem salvestab programmide ja tuuma krahhi tõmmiseid
• loetakse ajakirjandusest

Ründe iseloomu ja mõju täpsustamine

• vastutab süsteemiadministraator
• logi uurimine
• rakenduse protsesside tegevuse lähem uurimine

# ps aux
# lsof -n
# netstat -lnpa
# strace -p PID
# auditd
# tcpdump
# top -> u -> H

Kui rünne on mingil määral edenenud, siis võiks

• apparmor logis paista mingeid ebatavalisi katsetusi (nt lugeda faile, käivitada protsesse)
• secure boot logis paista pahalase tuuma mooduli laadimisi

Ründe vääramine

• vastutab süsteemiadministraator
• operatsioonisüsteemi seadistuse muutmine
• operatsioonisüsteemi parandatud versiooni juurutamine
• võrgukihi abi kasutamine (nt pahalase src ip blokeerimine tulemüüris)
• apparmor profiili täpsustamine
• rakenduse parandatud versiooni juurutamine, seadistuste muutmine (nt piiratakse php rakenduse ligipääsu failisüsteemile)

Ründega seotud asitõendite kogumine

• apport (kernel crash reports)
• logi

Kahju hindamine

• millal rünne toimus
• millistele ressurssidele (lokaalsed failisüsteemid) ründe käigus ligipääs saavutati
• kas süsteemi kasutati edasi järgmiste rünnakute tegemiseks

Võrk

Võrgu taseme ründe eesmärk on segada teenuse pakkumist

• täites füüsilist kanalit suvaliste pakettida (dst ip on teenuse ip, teenuse subnet ip, teenuse next hop ruuteri ip vms)
• kurnates teenuse ees olevate stateful tulemüüri syn pakettidega (tulemüür tekitab state'i; tulemüür võib olla eraldi seade või samas arvutis teenuse frontend komponendiga)

Töökorrasuse tekitamine

• vastutab võrguadministraator
• võrgu disain on kvaliteetne
• võrguseadmete riistvara ja nende tarkvara on kvaliteetne
• võrguseadmed on korrektselt seadistatud (nt vlanid ei kosta läbi, logi genereerimine ei sega teenuse pakkumist)
• pakkuda teenust mitmes asukohas
• kasutada rakendusserverite ees eraldi tulemüüri kihti
• lülitada tulemüüris sisse synproxy (on sellel üldse mõtet, kui backend oskab syn cookies kasutamist?)
• lülitada rakendusserverites sisse tcp syn cookies

Väited

• võrgulahenduse planeerimisel ei ole mõistlik keskenduda teenuse pakkumise sõlme juures väga võimsale ddos vms ründele vastuseismisele; rünne tuleb pigem tõrjuda oma isp'i perimeetril ja koostöös teiste isp'idega
• ei ole vaja eriliselt karta, et haldus ja teenus käivad üle sama füüsilise lingi seepärast, et kui link on rünnet täis ja kui ka saaks midagi hallata, niikuinii ei toimu teenuse pakkumist (esmalt tuleb perimeetril saada rünne kontrolli alla)

Töökorrasuse säilitamine

Muudatuste tegemisel tuleb eelnevalt veenduda, et need süsteemi olukorda paremaks teevad, või vähemalt ei tee hullemaks

• riistavarale firmware uuenduste rakendamine

Töökorrasuse jälgimine

• vastutab monitooringu adminstraator
• võrguseadmed tekitavad kasutus ja vealogi
• netflow
• moloch
• võrguseadmed genereerivad mingitele sündmustele eventisid (snmp trap, saadab meili vms)
• tehakse kindlaks baseline väärtused

Teha kindlaks tulemüüri võimekus

• olemasoleva ühenduse (tcp, udp) peal paketti sekundis ja mbit sekundis
• uute ühenduste tekitamise arv sekundis
• samaaegsete ühenduste arv

Ründe avastamine

• vastutab monitooringu administraator
• avastamiseks on oluline teada jälgitavate suuruste nn baseline väärtusi, st mis on suuruste väärtused normaalsel juhul
• kasutatakse kvaliteetset kasutus ja vealogi
• loetakse ajakirjandusest
• jälgida võrguseadmete liideste andmemahtude statistikat (ruuter, tulemüür, switch)
• jälgida tulemüüri samaaegsete ühenduste arvu ja uute ühenduste tekitamise arvu sekundis
• võrreldakse monitooringut tulemusi baseline'iga
• jälgida rakendusserveris conntrack olekut

# conntrack -L

Ründe iseloomu ja mõju täpsustamine

• vastutab võrguadministraator
• nt netflow ja moloch andmestike uurimine

Ründe vääramine

• vastutab võrguadministraator
• võrguseadme seadistuse muutmine
• võrguseadme parandatud versiooni juurutamine
• kui rünne ei ole random src, siis saab tõenäoliselt blokeerida suhteliselt hõlpsasti src ip või src subnet abil
• kui rünne on random src ja ei saa piirata src ip või subnet abil, tuleb isp perimeetril või parterite abiga kuskil kaugemal src AS vms viisil
• partner ispide abi kasutamine
• alternatiivse ruutingu juurutamine (nt läbi CDN teenuse)
• koostööpartnerie ja korrakaitse organite abil leida ja neutraliseerida allikas füüsilises maailmas

Ründega seotud asitõendite kogumine

• vastutab võrguadministraator
• võrguliikluse salvestis

Kahju hindamine

• kui kaua aega on teenusele ligipääs takistatud

Toetavad teenused

Iseenesest on toetav teenus samasugune teenus nagu seegi mida ta toetab, st toetamine on suhteline. Kuna fookus on käesoleva teenuse peal ning toetav teenus ei pruugi olla üldse sama meeskonna halduses, siis toetavat teenust jälgitakse vaid nö lõppkasutaja seisukohast. Tüüpilised toetavad teenused

• NTP
• DNS
• LDAP
• OCSP

Töökorrasuse jälgimine

• vastutab monitooringu administraator
• võimalusel saab kasutada kõnealuse toetava teenuse spetsiifilist 'IKT teenuse käitamine' teksti

Võrgutopoloogia

Valitud võrgutopoloogia peab toetama IKT teenuse käitamist. Tavaliselt on seoses võrguga sellised valikud

• kas kasutada rakendusserveri ja interneti vahel eraldi füüsilist tulemüüri
• kui teenus koosneb eraldi andme ja rakenduskihist, kas neid pidada eraldi võrkudes
• kas tulemüüri kasutamisel kasutada avalikke ruuditud aadresse või privaatsed ip aadress ja nat teisendust
• kas teenust pakutakse ainult ipv4 võrgus või ka ipv6 võrgus

Füüsilise tulemüüri kasutamine

Eeldusel, et

• kasutatakse korrektselt seadistatud Linux operatsioonisüsteem (sh lokaalne paketifilter)
• normaalset riistvara
• kvaliteetset tarkvara

suudab nö ühe protsessi server teenindada 1 Gbit/s võrguliidesega serveril ära kõik mis tema poole pöördutakse (nt nimeserver). Seega, alati ei ole tingimata füüsilise tulemüüri rakendamine põhjendatud.

Avalike aadresside vs NAT teisenduste kasutamine

Tulemüüri taha nö tavalisel viisil ruuditud avalike aadresside kasutamisel on sellised omadused

• lahendus on otsekohene seadistada, aru saada ja kasutada (sh end-to-end traceability)
• põhimõtteliselt kulutab tulemüür vähem ressurssi temast läbi minevate ühendustega tegelemisele kuna ei toimu teisendusi
• tulemüüris kogutud netflow andmestik on ip aadresside mõttes selgem (nat puhul on tegu triplettidega src, avalik dst, priv dst ip aadress)
• erijuhul töötab teenus ka väljalülitatud acl'iga tulemüüriga (tulemüür töötab ruuterina)
• kui tulemüür on väga valesti seadistatud, siis on tõenäoline, et rakendusserverid on internetist täiesti nähtavad ja vastupidi
• saab vajadusel kasutada stateless paketifiltri reegleid

NAT teisenduse omadused

• võimaldab erinevatest rakendusserveritest internetti väljuvaid ühendusi esitada samalt src aadressilt (nii on pahalasel keerulisem tuletada tulemüüri taga olevat topoloogiat)
• ipv4 numbrite vähesuse haldamine
• võimaldab teha koormusjaotust
• kui tulemüür on väga valesti seadistatud, siis on tõenäoline, et rakendusserverid ei ole internetist üldse nähtavad ja vastupidi

Misc

• kas ipv6 puhul on asjakohane kasutada nat'i?
• avalike aadresside kasutamisel on tehniliselt võimalik siiski teha nat teisendusi

Virtualiseerimine

Otsus kasutada virtualiseerimist ja kui, siis millist, peab toetama IKT teenuse käitamist. Virtualiseerimise omadused

• saab operatiivselt lülitada ümber erinevate rakendusserverite eksemplaride vahel
• tõenäoliselt on turvalisem kasutada riistvara otse ilma virtualiseerimiseta (iga täiendav nö töötav rida koodi suurendab vigade tekkimise tõenäosust)
• tõenäoliselt on suurem jõudlus kasutades riistvara otse ilma virtualiseerimiseta (iga täiendav tegevus füüsilisel riistvaral kulutab arvutusvõimsust)
• saab kasutada füüsilise riistvara ressurssi efektiivsemalt (nt iga unit rack kõrgust serveriruumis maksab ja tark on see sisustada arvutusvõimsusega; kui 1 U võimsus on seejuures liiga suur ühe teenuse jaoks, siis on mõistlik ta loogiliselt st virtualiseerimise abil tükeldada)

Kõrgkäideldavus

• kõrgkäideldavuse saavutamiseks teevad koostööd võrgu, operatsioonisüsteemi ja rakenduse kihid (võib olla ka kliendi rakendus)

Monitooring

Väited

• monitooring salvestab teenuskomponendi töötamisega seotud parameetrite väärtusi kokkulepitud ajalise intervalliga (nt kord minutis)
• tavaliselt registreeritakse cpu, mälu, storage io, võrgu io, protsesside arvu (kasutajate kaupa), threadride arv (kasutajate kaupa) jms
• monitooring säilitab kogutud andmete ajaloo
• monitooringu ettevalmistamisel sätestatakse piirväärtused, kui parameetri väärtus väljub lubatud piiridest antakse häire
• vähemalt üks teenuse kontroll peab võimalikult ehedalt esitama lõppkasutaja vaadet
• monitooring ei tohi segada teenuse töötamist
• rakenduse olukorra kohta oskab kõige paremini anda infot rakendus ise (st monitooringuga koostöö tegemine peab olema üks tema sisemisi funktsioone; nt mingite puhvrite kasutus, rakenduse sisemised vead jms)
• kui monitooringusse ei jõua etteantud arv järjestikuliste kontrollide väärtusi, antakse häire
• monitooringu teated peavad jõudma haldajale mööda mingit muud andmeside kanalit kui see, mida monitooritakse

Logimine

Väited

• üldiselt jaguneb logi kasutuslogiks ja vealogiks
• logi tekitavad protsessid (rakendusele vastavad protsessid, operatsioonisüsteemi tööd tegevad protsessid ja võrguseadmed)
• teenuskomponendi töötamise käigus tekkiv logi salvestatakse väljaspool kõnealust süsteemi (logiserveris)
• logi peab jõudma logiserverisse turvaliselt (salastatus, terviklus jne)
• logi alusel genereeritakse teenuskomponendi kasutusstatistika
• logi alusel saadakse teada teenuskomponendi töötamisel esinenud tõrgetest (sh rünnetest)
• logi kogumisest ei piisa, kogutud logi tuleb analüüsida
• tuleb kokku leppida, mis sündmuse avastamine logist on kelle vastutus
• logi peaks olema seotud monitooringuga (st logist olulise sündmuse leidmisel annab monitooring alarmi)

Testimine

TODO

Kasulikud lisamaterjad

• OpenBSD tulemüüri võrgu_koormustest
• Httperf kasutamine