· · Nõrki PIN-e on võimalik ära arvata · · Unit key'd on ebaturvalised · · Terviklikkuse kehv kaitse · · Suvalise arvu generaatori kvaliteet Lisaks eelmainitule tuleb arvesse võtta ka järgnevat: · · Mobiilisetel seadmetel on suurem risk saada varastatud, kui seda on · statsionaarsetel seadmetel · · Ainuke asi, mida on vaja Bluetooth seadme kasutamiseks, on et seade · autendiks ennast, reeglina kasutaja ei pea end seadmele autentima. Kui · mobiilne juba paarunud seade läheb kaduma, siis mitteautoriseeritud · kolmandad osapooled saavad neid kasutada viivitamatult · · Sobiva varustusega saab Bluetooth seadmete aadressidega manipuleerida (nt. · flash mälu) · · Ad hoc võrkudes on arvutiviiruste ja "Trooja hobuste" leviku oht Bluetooth seadmete kasutamisega kaasnevad ohud: · 1. Bluesnarfing meetod, mille põhimõtteks on "häkkida" Bluetooth ühendust
määrata inimesed, kes liitumist tehniliselt korraldama hakkavad. Liituja peab tutvuma Infosüsteemide andmevahetuskihi rakenduse määrusega. Liituja peab nõustuma RIHAs X-tee liitumistingimustega. See on edaspidise koostöö alus. Lisaks on X-tee kaudu võimalik teha avaliku teenusena lubatud päringuid, näiteks edastada Haigekassale kindlustusandmeid. Teenuste kasutamiseks peab lõppkasutaja ennast esmalt ID- kaardi abil või internetipankade kaudu autentima. Ettevõtja esindusõigus tuvastatakse Äriregistri andmete alusel. Koostoime protokollid: •Andmete ülekanne ja kaugtööna programmide käivitamine: XML-RPC asemel/kõrval SOAP protokoll •veebiteenuste kirjeldamine: WSDL keel •teenuste kirjeldamine: UDDI standardit. X-tee süsteem: Teenuste väljaarendamiseks saab X-teega liitunu enda kasutusse järgmise funktsionaalsuse: •Autentimine (ID-kaart + 5 Interneti panka), •Autoriseerimine. •MISP (MiniInfoSüsteemPortaal).
Tavaliselt otsustatakse riski vastuvõetavuse üle riskimisega kaasnevate kulude ja tulude võrdlemise alusel. 5. Too näiteid turvanõuetest ja iseloomusta neid. Audentimisnõuded tuvastusele kuidas isikut tuvastatakse. Et vältida turvariske tarkvaras - piiratakse kasutajate juurdepääsu ning tehakse andmed-süsteemid kättesaadavaks vaid selleks volitatud isikutele. Andmetele ja kogu arvutile ligipääsuks peab kasutaja end autentima. Selleks on paroolid, kuid turvalisemad on sõrmejälje ja silma võrkkesta lugejad. Siiski ei taga see päris kindlat kaitset, sest tarkvara vigu saab ära kasutada kõrvalisi teid mööda süsteemi sissemurdmiseks (backdoor). Audentimisnõuded õigustele määratakse kindlaks, kas keegi on süsteemis admin või kasutaja Terviklikkuse nõuded - andmete mittemuutmine selle saatmise voi hoidmise protsessi ajal.
turvameetmeid. Hooldatav IT-süsteem peab hõlmama järgmiseid turbefunktsioone: - Kaughoolduse ühendus tuleks alati käivitada lokaalse IT-süsteemi kaudu. Seda on võimalik teostada hallatava IT-süsteemi kõnega kaughoolduspunkti või kasutades automaatset tagasihelistusfunktsiooni (Callback). - IT-süsteemi kasutaja peab kaugligipääsu kinnitama, näiteks vastava kinnitusega süsteemis. - Väline hoolduspersonal peab end enne hoolduse algust autentima. Kui paroolid edastatakse krüpteerimata, tuleks kasutada ühekordseid paroole (vt M 5.34 ,,Ühekordsed paroolid"). - Kaughoolduse käigus teostatu tuleb hooldataval IT-süsteemil protokollida. Lisaks võiks hooldatavale IT-süsteemile paigaldada veel lisafunktsioone: - Ajapiiri määramine vigaste ligipääsukatsete korral, - Kaughoolduse keelustamine tavakäituse ajal ning ligipääsu lubamine määratud ajavahemikuks.
See sisaldab samamoodi 24 bitist vektori initsialiseeritud kombinatsiooni, mis jätab tegeliku võtme jaoks 232 bitti, mis sisestatakse tavaliselt 58 kuueteistkümnendsüsteemi tähemärkide kombinatsioonina. Autentimine WEP kasutab autentimiseks kahte võimalust. Avatud süsteemi autentimist (Open System authentification) ja jagatud võtmega autentimist (Shared key authentication). Avatud süsteemi autentimise puhul ei pea klient ennast pöörduspunkti ühendamise käigus autentima. See tähendab, et ühenduse saab luua igaüks, aga andmete vahetamiseks on vaja WEP võtmeid. Muidu ei ole liiklus tõlgendatav. Jagatud võtmega krüpteerimine tähendab aga seda, et autentimine moodustab nelja sammulise omaette protsessi, mida kutsutakse kätluseks (handshaking). 1. Klient saadab autentimispäringu pöörduspunktile. 2. Pöörduspunkt vastab krüpteerimata sõnumiga. 3. Klient krüpteerib enda võtmega pöörduspunkti poolt saadetud sõnumi, ning
võimaldavat koodi), st. tuginetakse kompleksturbel põhinevale mehhanismile, mis tagab piisava turbe. Digiloost on samuti võimalik epikriise vaadata. Digiloost saavad epikriise vaadata ainult vastavat õigust omavad töötajad. Alates Digiloo käivitumisest (01.09.2008.a.) on nendeks töötajateks ainult perearstid või patsiendi raviarstid. Arst peab end seejuures Digilukku sisenemisel turvaliselt autentima, mis on võimalik ID-kaardi abil. Päring Digilukku teostatakse MISP portaali kaudu ID kaardi ja PIN1 koodi kasutades. Saatekirjad saadetakse Digilukku arsti poolt, kelle digiallkirjaga need tõestusväärtuse (tervikluse) tagamiseks varustatakse. Tehniliselt kasutatakse selleks MIS portaali ning nimetatud töötaja ID- kaarti ja PIN2 koodi (signeerimise võtmepaarile juurdepääsu võimaldavat koodi), st. tuginetakse kompleksturbel põhinevale mehhanismile, mis tagab piisava turbe.
Enter it again: Shall the new role be a superuser? (y/n) y Peale selle peab failis /usr/local/pgsql/data/pg_hba.conf local all md5 #local all trust #host all 127.0.0.1 255.255.255.255 trust #host all 192.168.1.1 255.255.255.255 trust antud juhul on kolm alumist rida välja kommenteeritud ja töötav rida ütleb, et lase sisse localhost'i pealt kõik kes on nõus end autentima. (st. alustama psql -u -d database) Kui kuidagi ei taha sisse lasta, siis kasautage ülevalt teist rida :) Kasutajaid näeb postgres käsurealt postgresql > # du List of roles Role name | Attributes | Member of ------------+-------------+----------- mart | | {} ants | | {} kalle | Superuser | {} : Create DB Upgrade Postgres upgrade puhul oleks soovitatav dumpida kogu baas ja hiljem restoreda pg_dumpall -U root > pgdump /etc/init
13 1.3.2.7 Hallatavus Süsteem tööd peab olema võimalik jälgida ning tõrgetest tuleb teavitada vastavalt tõrke tüübile ja konfiguratsioonile vastavaid isikuid. 1.3.2.8 Turvalisus Kasutajatele peab saama määrata rollid ning vastavalt rollidele peab olema määratud piirangud hallatavatele ning vaadatavatele andmetele. Kasutajaid peab autentima kasutajanime ja parooliga. 1.3.2.9 Paindlikkus Teenuseid peab olema võimalik lisada olemasolevat ümber tegemata. Loodud teenust peab olema võimalik muuta moodulite kaupa. 1.3.2.10 Skaleeritavus Süsteemile peab olema võimalik lisada ressursse (näiteks riistvara) võimalikult lihtsalt ka kõige suurema koormuse perioodidel. 1.3.2.11 Juurepääsetavus Kasutajatel peab olema ligipääs süsteemile üle interneti. Süsteemi töökeel on eesti keel. 1.3.2.12 Kasutatavus
● FTP server: port 21 Tavalisi FTP-ühendusi ei peeta tänapäeval turvaliseks, sest kogu info (ka paroolid) liiguvad võrgus krüpteerimata kujul. Turvalisuse huvides on soocitatav kasutada FTPS (FTP over Implicit TLS/SSL) või FTPES (FTP over Explicit TLS/SSL) laiendatud protokolle. Tüüpiline scenario näeb välja nii, et meil on kasutaja, kes tahab local hostist kuhugi kaug hosti oma faile laadida. Selleks, et oma kaugkontole ligi pääseda, peab kasutaja end autentima. Pärast seda saab kasutaja hakata laadima faile kaughosti ja vastupidi. Kasutaja (kes suhtleb läbi FTP UI) edastab kõigepealt kaughosti nime, FTP klient loob TCP ühenduse FTP serveriga. Seejärel edastab kasutaja oma nime ja passi, mis edastatakse üle TCP ühenduse. Kui autentimisega on kõik OK, saab kasutaja hakata faile üles/alla laadima. Seega, suht HTTP sarnane (mõlemad jooksevad TCP peal), aga suurim erinevus on, et FTP
annaabi.ee 
