Windows munkaállomás házirendje
Ebben a leírásban felvázolunk egy elvi házirendet, amely irodai munkaállomások, illetve döntően munkára is használt hordozható számítógépek biztonságos üzemeltetését célozza Microsoft Windows 7, 8.x és 10 operációs rendszerek alatt. A leírás csak irányelveket tartalmaz, a konkrét telepítési javaslatokat lásd ezeken az oldalakon:
Work in progress - még ne vedd komolyan!
Tartalomjegyzék
Azonosítás és személyiségvédelem
Számítógépes tevékenységünk kapcsán erőforrásokat veszünk igénybe (esetleg ilyeneket biztosítunk), ennek során valamilyen (logikai) személyként vagy valamilyen (logikai) szerepben jelenünk meg. Az azonosítás során a konkrét felhasználói tevékenységet végző entitás (természetes személy, esetleg program) ideiglenesen kötődik egy-egy létező (logikai) személyhez vagy szerephez. Az elérhető, felvehető (logikai) személyek, szerepek egyfajta összessége ad egy (elektronikus) személyiséget, amelyhez a számítógépes világban (kibertérben) lehetőségek és kötelezettségek kapcsolódnak; ezeket a reális világban általában egy természetes vagy jogi személy élvezi, illetve tartozik értük helytállni. Ennek következtében az elektronikus személyiség valós értéket képvisel, amellyel reális haszon reményében vissza lehet élni, és amelyet emiatt védelmezni szükséges.
Az elektronikus személyiség komponensei között lehet összefüggés. Biztonsági szempontból ez kevéssé kívánatos, mert így egy támadó egyetlen azonosítással esetleg több komponenshez is hozzáférhet, illetve azzal visszaélve olyan ismereteket szerezhet, amelyek más komponensek, végső soron az egész elektronikus személyiség megszerzéséhez vezethetnek. Kényelmi szempontból ellenben az lenne kívánatos, ha az egész személyiséghez egyetlen, lehetőleg automatikus azonosítással lehetne hozzáférni (azaz a gépek automatikusan és megbízhatóan felismernének bennünket). Mivel ennek technikai feltételei általában még nem adottak, a házirend kialakítása során itt könnyen elhibázható kompromisszumra kényszerülünk.
Általános megfontolások
- Kerüljük a megosztott titkokat. Hacsak lehetséges, mindig (logikai) személyeket authentikáljunk és (logikai) csoportoknak adjunk hozzáféréseket.
- A felhasználókat megfelelően tájékoztatni kell a biztonsági házirendről - nemcsak a követelményekről, hanem lehetőség szerint a háttérben lévő megfontolásokról is. A biztonság és a kényelem egymás ellen hatnak, és hasznosnak gondolom, ha a felhasználók megértik az esetleges kényelmetlenségek okait is.
- TODO!
Személyiségvédelmi szintek
Figyelem: az alábbi táblázat egy saját kísérlet a különböző biztonsági megfontolások integrálására; egyelőre kritikával olvasandó és alkalmazandó!
Az elektronikus személyiség komponensei közül
fokozottan érdemes védeni azokat, amelyek:
|
fokozott védelemre alkalmasak pl. az alábbi eszközök:
Egy fokozott védelemre alkalmas eszköz több szolgáltatást is védhet (akár az összeset is). |
átlagosan érdemes védeni azokat, amelyek nem igényelnek fokozott védelmet, de:
|
átlagos védelemre alkalmasak pl. az alábbi eszközök:
Egy átlagos védelemre alkalmas eszköz közvetve sem védhet több szolgáltatást. |
gyengén (esetleg sehogy sem) érdemes védeni azokat, amelyek a fentiekbe nem tartoznak és:
|
gyenge védelemre használhatóak pl. az alábbi eszközök:
|
Windows felhasználók kezelése
Ebben a leírásban nem foglalkozunk az Active Directory alapú (Azure AD vagy Windows domain) felhasználókezeléssel (TODO!).
Rendszergazda szerepkör
A rendszerüzemeltetés (jellemzően a gép erőforrásainak kezelése - telepítések, frissítések, beállítások) lényegesen eltér a mindennapi felhasználói tevékenységtől, amelyre inkább a fenti erőforrások igénybe vétele a jellemző. Ezt a két szerepkört logikailag mindenképpen érdemes elkülöníteni; a technikai elkülönítés során elsősorban a következő kérdések merülnek fel:
- Szükséges-e (hasznos-e) a rendszergazda szerep számára (nem személyes jellegű) dedikált felhasználói fiókot felvenni? Ha igen, milyen legyen ez a fiók?
- A gép mindennapi felhasználóinak legyen-e üzemeltetői feladata illetve hozzáférése? Mire jogosítson ez a hozzáférés?
Szükséges-e dedikált rendszergazda fiók?
A tárgyalt Windowsokban minden felhasználói tevékenység (a rendszergazda felhasználóként és a korlátozott felhasználóként elindítottak egyaránt) korlátozott privilégiumokkal fut, és az emelt jogosultságot igénylő folyamatok bármilyen (nem rendszer) felhasználó általi elindítását a UAC egy rendszergazda jogosultságú felhasználó tényleges, a grafikus felületen valós időben kiadott, nem scriptelhető jóváhagyásához köti (ezután a folyamat a jóváhagyó nevében indul el). Emiatt (szemben a korábbi NT Windowsokkal) a rendszergazda fiók elkülönítése nem abszolút biztonsági követelmény.
- Amennyiben a gép személyes tulajdon, és azon lényegében egyetlen felhasználó dolgozik, akihez a gép erősen kötődik (okostelefon, saját notebook, stb.), és aki (legalább minimális szakértelem birtokában) teljes joggal és felelősséggel üzemelteti a gépet, valószínűleg nem érdemes rendszergazda fiókot dedikálni (azaz emiatt egy külön profilt karbantartani). A dedikált rendszergazda fióknak ugyanakkor megvan az a pszichológiai előnye, hogy ilyenkor a UAC kérésére a rendszergazda szerep jelszavát (vagy PIN-jét, stb.) kell megadni, ami sokkal határozottabban figyelmezteti a felhasználót arra, hogy üzemeltetési feladatot fog ellátni, mintha (elkülönítés nélkül) egyetlen kattintással engedélyezni lehetne a kérést.
- Minden más esetben szükségesnek tűnik az elkülönített rendszergazda fiók.
A rendszergazda fiókot (célszerűen ez a telepítéskor létrejövő első - amúgy is rendszergazda jogosultságú - felhasználó fiókja legyen) szerep hozzáférésként alakítsuk ki:
- Egyetlen fiókot használjunk akkor is, ha a géphez több rendszerüzemeltetésre jogosult személy tartozik.
- A rendszergazda fiókot védjük erős azonosítással (tudomásul vesszük, hogy ez lehet megosztott titok).
- Ebben a fiókban ne tartsunk személyes adatot, a fiókot ideiglenesen se használjuk mindennapi munkára!
A rendszergazda fiók kialakítható hagyományos, helyi fiókként vagy (a rendszergazda szerepet megtestesítő) Microsoft fiókként. Technikailag a Microsoft fiókhoz kötött Windows felhasználó is egy helyi felhasználó (pl. a Vezérlőpult, Felhasználói fiókok, Felhasználói profilok... listája Helyi típusúnak mutatja). Egy helyi fiók utólag is hozzáköthető egy Microsoft fiókhoz, illetve ez a hozzárendelés bármikor megszüntethető.
A Microsoft fiók(kal összekötött helyi rendszergazda fiók) nagy előnye, hogy így több, különböző gépen (pl. egy kisvállalat összes Windows munkaállomásán) megjelenhet ugyanaz a felhasználó entitás (a domain administrator szereppel analóg módon), amely lényegesen könnyebben karbantartható (pl. bejelentkezési jelszava, egyes beállításai az összes gépen egyszerre változtathatóak), mintha minden gépen különálló rendszergazda fiókot kellene kezelnünk. A Microsoft fiók hátránya, hogy a hozzá kötött gépeken, az ezzel a bejelentkezéssel végzett felhasználói műveletekről a Microsoft nagyon valószínűen (és legálisan) adatokat gyűjt, ezeket valószínűleg feldolgozza és hasznosítja, illetve pl. hatóságoknak valószínűleg a tudtunk nélkül is kiadja.
- Ha egy rendszergazda szerep több gép karbantartásáért is felelős (vállalti környezet), általában érdemes ezeken a gépeken rendszergazda Microsoft fiókot használni.
- A csak egy gépen megjelenő (és nem személyes használatú) rendszergazda fiókot általában nem érdemes Microsoft fiókhoz kötni.
Kinek legyen rendszergazda hozzáférése?
Ha a mindennapi felhasználók egyáltalán nem jogosultak üzemeltetési feladatok ellátására - pl. vállalati környezetben nincs engedélyük a gépre bármit is telepíteni, vagy szakértelem illetve affinitás híján erről lemondanak, stb. -, akkor a rendszergazda hozzáférést előttük titokban kell tartani. Ez esetben célszerű felkészülni arra, hogy bármikor(!) szükségük lehet informatikai (táv)segítségre, mert a hordozható eszközök elterjedésével a munkavégzés vállalati környezetben sem korlátozódik az iroda területére és a munkaidőre.
Vállalati környezetben a fenti megoldás előnyösnek tűnik, elsősorban a tiszta felelősségi viszonyok miatt.
Ha az üzemeltetési feladat megoszlik (pl. az egyszerűbb problémákat a mindennapi felhasználók önállóan elhárítják, minden más esetben elérhető a gép üzemeltetéséért felelős rendszergazda személy, aki egyébként ennek a gépnek nem mindennapi felhasználója), akkor a mindennapi felhasználóknak is szükségük van rendszergazda jogosultságra. Ezt többféleképpen biztosíthatjuk számukra:
- Fiókjukat csak a szükséges jogosultságokkal rendelkező, helyi Windows csoporthoz adjuk hozzá (ez a régebbi power user koncepció - TODO!). A megoldás előnye, hogy nem szükséges megosztott titok, és a jogosultság pontosan szabályozott.
- Megosztjuk velük a rendszergazda szerepfiók (helyi) hozzáférését. A megoldás hátránya az osztott titok (vállalati környezetben talán egy minden gépen egyedi, helyi PIN kód megadása a legkevésbé kártékony), valamint hogy a felhasználók "bármit" megtehetnek. A megoldás előnye, hogy a UAC kérések jóváhagyásakor a bonyolultabb authentikáció miatt jobban tudatosul a szerepváltás.
- Korlátozott felhasználói fiók helyett rendszergazda felhasználói fiókot készítünk számukra (fiókjukat felvesszük az Administrators csoportba). A megoldás előnye, hogy nem szükséges megosztott titok. A megoldás hátránya, hogy a felhasználók "bármit" megtehetnek, valamint az UAC kérdések egyetlen kattintással jóváhagyhatóak (vagyis kevéssé tudatosul a felhasználóban az, hogy ennek során a mindennapi használatnál lényegesen nagyobb körültekintést igénylő üzemeltetői feladatot lát el).
A megosztott üzemeltetést vállalati környezetben inkább igyekezzünk elkerülni.
Szponzor szerepkör
Ez a szerepkör - amelyet kötelezően egy Microsoft fiók testesít meg - a Microsoft Áruház bevezetésével vált megkerülhetetlenné. A Microsoft Áruházból csak Microsoft fiókkal történő bejelentkezés után lehet alkalmazást letölteni (hasonlóan a más bejelentkezést igénylő Google Play vagy az Apple App Store áruházakhoz). A Microsoft fiókot ilyenkor nem Windows felhasználóként (adattárolási-szinkronizációs, levelezési, stb. célra) használjuk, hanem szoftver vásárlóként, aki akár pénzköltésre is jogosult.
A Microsoft elhallgatja a Microsoft fiók fenti két felhasználása közti, lényegi eltérést, így ez a felhasználókban valószínűleg nem is tudatosul.
- Egyfelhasználós, saját tulajdonú gép esetén célszerű, ha a tulajdonos és felhasználó személy rendelkezik saját Microsoft fiókkal, és ezt használja szponzorként. Amennyiben Windows felhasználóként is Microsoft fiókot használ, a rendszergazda, szponzor és mindennapi felhasználó szerepet egyaránt megtestesítheti egyetlen, személyes Microsoft fiókja (a Microsoft ezt a módot preferálja). Ha Windows felhasználója lokális, akkor szponzor fiókjával csak az Áruház alkalmazásba kell bejelentkezzen (így tud letölteni és vásárolni, de nem használja az adattárolási- és szinkronizációs lehetőségeket).
- Vállalati környezetben a gép és a szoftverek tulajdonosa általában a vállalat, és az ezzel kapcsolatos pénzköltésre pl. az IT részleg jogosult, így a szponzor Microsoft fióknak (amely nem személyes, hanem szerepfiók) ezt kell reprezentálnia. A konkrét vásárlások (letöltések) során az IT erre jogosult munkatársának kell ezzel a fiókkal az Áruház alkalmazásba bejelentkeznie, majd vásárlás (letöltés) után onnan kijelentkeznie(!), függetlenül az aktuálisan bejelentkezett Windows felhasználó kilététől.
A rendszergazda és szponzor szerepkörök összekötése
- Egyfelhasználós, saját tulajdonú gépeken (a Microsoft szándékának megfelelően) a rendszergazda, szponzor és Windows felhasználó tevékenységek mindegyikéhez a felhasználó általában a saját, személyes Microsoft fiókját társítja, így ezeket a szerepeket automatikusan összeköti.
- Vállalati környezetben a rendszergazda és szponzor szerepkörök összekötése (azonos Microsoft fiókhoz társítása) elsősorban kényelmi szempontból jön szóba (általában mindkettőért az IT felel, és így az IT munkatársaknak csak egy hozzáférést kell ismerniük, megjegyezniük). Ügyelni kell arra, hogy ily módon a rendszergazdai fiókba bejelentkezve egyben (külön kérdés nélkül) megvalósul az Áruház alkalmazásba bejelentkezés is, vagyis aki a helyi gépen (akár a Microsoft fiók jelszavának ismerete nélkül, pl. ideiglenes PIN kóddal) rendszergazda bejelentkezésre képes, egyben vásárolhat, pénzt is költhet.
Amennyiben ez a két szerepkör össze van kötve, fokozottan kell figyelni arra, ki és hogyan szerezhet helyi rendszergazda hozzáférést.
Általános felhasználók
TODO!
Vendég felhasználó
TODO!
Titkosítás
Titkosításra általában aszimmetrikus kódoláson alapuló technikákat alkalmaznak (a privát kulccsal elkódolt adat csak a publikus kulccsal dekódolható - ez egyben tanúsítja, hogy az adat a privát kulcs birtokosától származik, azaz elektronikus aláírást jelent; a publikus kulccsal elkódolt adat csak a privát kulccsal dekódolható - ez biztosítja, hogy az adatot csak a privát kulcs birtokosa tudja megfejteni, azaz titkosítást jelent).
A titkosító eszközöknek biztosítaniuk kell, hogy megfelelő kulcs ismerete nélkül a titkosítás feltörése aránytalanul sok időbe teljen. Ennek érdekében:
- kellően erős titkosítást alkalmazzunk;
- lehetőleg nyílt forrású, és megbízhatóan lefordított eszközöket alkalmazzunk;
- csak mainstream eszközöket alkalmazzunk;
- privát kulcsainkat erősen védjük.
A titkosításhoz az operációs rendszer technikai támogatást ad (a tárgyalt Windowsok tartalmaznak központi tanúsítványtárat, illetve rendelkeznek a szükséges kriptográfiai kódkönyvtár komponensekkel) - ezekben általában kénytelenek vagyunk megbízni (TODO!).
A fájlrendszer védelme
A titkosítás célja, hogy a fájlrendszerben tárolt érzékeny adatokat a támadó akkor se ismerje meg, ha lehetősége van a fájlrendszerhez rendszergazda jogosultsággal, vagy a jogosultságkezelés megkerülésével (pl. az operációs rendszer futtatása nélkül) is hozzáférni. Utóbbi helyzet áll elő, ha a gépet elveszítjük vagy azt ellopják, illetve ha egy őrizetlenül hagyott gépen a behatolónak lehetősége van saját operációs rendszert futtatni (pl. Live CD-ről bootolni).
A fájlrendszer titkosítása az erre külön fel nem készített, szokvány Windows alkalmazások számára transzparens (észrevehetetlen) kell legyen - erről a gyakorlatban valamilyen háttérben futó szolgáltatás gondoskodik, amely a felhasználói munkamenet során általában mindvégig működik. A munkamenet során a titkosított fájlok a felhasználó számára (így az ő nevében futtatott malware-ek, legális vagy illegális távoli hozzáférés-kezelők, stb. számára is) szabadon hozzáférhetőek, vagyis ökölszabályként ez a fajta védelem csak a munkameneten kívül - kikapcsolt gép, illetve kijelentkezett felhasználó esetén - hatásos.
A fájlrendszer védelme (védett helyen lévő, nem hordozható munkaállomások kivételével) minden, személyes vagy érzékeny adatokat is kezelő gépen erősen ajánlott!
Titkosított felhasználói profilok
A legkedvezőbb technikai megoldásnak a gépen megtalálható felhasználói profilok (C:\Users\[profile name]) külön-külön történő titkosítása tűnik, amelyet célszerűen a bejelentkezési jelszó(val megegyező jelszó) megadásával lehet feloldani. Így a be nem jelentkezett felhasználók összes adata (levelezés, dokumentumok, böngészési előzmények, mentett jelszavak, stb.) a háttértáron csak titkosítva szerepel, azaz egy rendszergazda bejelentkezéssel sem lehet azokhoz hozzáférni. Ugyanakkor az operációs rendszer (egyébként nyilvános) állományai nincsenek titkosítva, annak teljesítményét, karbantartását, esetleges javíthatóságát, stb. a titkosítás kevéssé befolyásolja.
Sajnos, jelenleg nem tudok olyan megoldást, amely a felhasználói profilok ilyen jellegű titkosítását biztosítja (TODO!).
Kiválasztott felhasználói adatok titkosítása
Ennél a megoldásnál minden felhasználó számára létrehozunk egy-egy titkosított fájlterületet, amelyre profiljából az érzékenynek gondolt adatokat (pl. NTFS junction-ökkel, transzparens módon) átirányítjuk. A megoldás közel egyenértékű lehetne a teljes profil titkosításával, azonban az adatok kiválasztása és átirányítása konfigurálást igényel, korlátok lehetnek (pl. nem lehet elrejteni olyan állományt, ami a bejelentkezéshez és a titkosító eszköz futásához közvetlenül vagy közvetve kell), és a felhasználói felületen nem különülnek el világosan a védett és nem védett adatok.
Sajnos, jelenleg nem ismerek olyan eszközt, amely a titkosítás feloldását a bejelentkezéssel integrálná, illetve a bejelentkezés folyamatát a feloldásig késleltetné. Emiatt pl. a Desktop vagy a teljes AppData felvétele a titkosított adatok közé nehézkesnek tűnik (TODO!).
A teljes háttértár titkosítása
Számos hardver- és szoftver gyártó által alkalmazott megoldás, amely megakadályozza a háttértár másik gépben történő elolvasását, vagy másik operációs rendszer használatával a jogosultságkezelés megkerülését (pl. úgy, hogy a feloldáshoz a háttértáron kívül az alaplapra integrált TPM és az operációs rendszer által tárolt kulcs vagy adat is szükséges).
A megoldás előnye, hogy (mérlegelés és konfigurálás nélkül) "mindent" titkosít; hátránya, hogy a titkosítás feloldását a gép valamennyi felhasználójának ismernie kell (osztott titok), és a titkosítás nem szelektív: annak feloldása után valamennyi felhasználó adata megismerhető, nemcsak az aktuálisan bejelentkezett felhasználóé. Egyfelhasználós készüléken (pl. okostelefonon) ezek a hátrányok nem jelentősek, de több felhasználó esetén a teljes háttértár titkosítása - bár a semminél nyilvánvalóan sokkal jobb! - nem tűnik teljes értékű megoldásnak.
Az adatforgalom védelme és hitelesítése
Ebben a szakaszban a gépek közötti, tipikusan hálózaton keresztül lebonyolított adatforgalommal foglalkozunk; a saját gépen belüli adatforgalmat ez a leírás nem érinti.
Az adatátviteli csatorna titkosítása
Napjainkban általánosan elterjedt a titkosított hálózati protokollok (pl. HTTPs, IMAPs, SMTPs) használata, és sokan gondolják úgy, hogy pusztán ezek használatával az adatátvitelek lehallgatástól és meghamisítástól védetté tehetőek. Ez a megállapítás részben igaz is: pl. ha egy webáruház honlapjához és vásárlás esetén a kapcsolódó banki szolgáltatóhoz is egyaránt HTTPs csatornán, közvetlenül kapcsolódunk, a csatorna titkosítása elegendőnek tűnik.
A csatorna titkosítása azonban csak a point-to-point jellegű adatátvitelt biztosítja kielégítően. Amennyiben az adatkapcsolat (közbenső) szervereken és szolgáltatásokon keresztül valósul meg, a titkosításban nem közvetlenül a küldő és a címzett vesznek részt, hanem a mindenki a saját szolgáltatójának partnere, így mindkét szolgáltatónak módja van az adat megismerésére vagy meghamisítására, valamint a titkosítás nem terjed ki a szolgáltatók közötti kapcsolatra sem. Pl. hiába csatlakozunk levélküldő szolgáltatónkhoz SMTPs-sel, ha annak szervere azután titkosítatlan SMTP kapcsolatot használ a címzett levélfogadójának elérésére, ahonnan a címzett ismét titkosítva - pl. IMAPs útján - viszi el a levelet. A titkosítatlan szakaszban a levelet bárki (a két szolgáltató, valamint bármelyik esetleges közbenső állomás) egyszerűen lemásolhatja vagy meghamisíthatja. Mivel mindkét levelezőpartner a saját szolgáltatójához titkosítva kapcsolódik, tévesen azt gondolhatják, hogy mindvégig védett és titkosított kapcsolatot használtak.
A fentiek figyelembe vételével azt mondhatjuk, hogy a titkosított adatcsatornák használata alapvető védelmi intézkedés, amely minden gépen erősen ajánlott, de nem feltétlenül elegendő.
Az adattartalom titkosítása
Az adatátvitelhez többlet biztonságot ad hozzá, illetve az átvitt tartalom hitelesítésének lehetőségét biztosítja, ha a csővezeték titkosításán kívül magukat az átvitt adatokat is titkosítjuk, illetve elektronikusan aláírjuk. Az adattartalom titkosításának módjában a küldő és címzett partnereknek meg kell egyezniük; pl. ha partnerünk nem személy, hanem szolgáltatás (weboldal, fájlszerver, stb.), amely ezt a titkosítási réteget nem támogatja, akkor az adattartalom titkosításáról kénytelenek vagyunk lemondani.
A titkosított tartalomkezelés a felhasználók számára akkor kényelmes, ha azt a tartalomkezelő alkalmazások (pl. az email kliensprogram, szövegszerkesztő, stb.) technikai oldalról támogatják; a külön lépésben és eszközzel történő aláírás-kezelés több felhasználói figyelmet igényel. Szükséges minden tartalomkibocsátó és -fogadó (gyakorlatilag minden felhasználó személy illetve szerepkör) számára egy személyes tanúsítvány (elektronikus "személyi igazolvány"), amelyet generálhatunk magunk (mely esetben nem lesz automatikusan megbízható), vagy (akár ingyenesen, akár díj ellenében) beszerezhetünk valamely elismert tanúsítványszolgáltatótól.
Az elektronikus aláíráshoz a személyes tanúsítvány publikus kulcsát az aláírónak közzé kell tennie (egy webhelyen, felhőbeli megosztásként, emailben terjesztve, stb.), és gondoskodnia kell arról, hogy partnerei ebben megbízzanak (elismert tanúsítványszolgáltató által kiállított igazolvány esetén ez automatikus). Az elektronikus aláíráshoz a partner közreműködése nem szükséges, azt figyelmen kívül hagyva is teljes értékű számára az adatátvitel (pl. olvasható az elküldött email). A titkosított adatküldéshez a címzett partner személyes tanúsítványának publikus kulcsát kell az adatküldőnek beszereznie, és abban megbíznia. A visszafejtéshez a partnernek alkalmaznia kell a szükséges kriptográfiát, ennek hiányában az átvitt adathoz nem jut hozzá (pl. előfordulhat, hogy az így küldött email csak a megfelelően beállított asztali levelezőprogramban olvasható, webfelületen vagy okostelefonon nem).
Legalább az email forgalom tartalmi titkosítása és hitelesítése vállalati környezetben erősen ajánlott, opcionálisan minden gépen hasznosnak tűnik. Vállalati környezetben a fájlszervereken lévő, közös dokumentumtár hitelesítését is érdemesnek tűnik kidolgozni.
Adatbiztonság
TODO:
- Távoli fájlrendszerek használata
- Adatszinkronizálás
- Mentés
- Archiválás
Szoftverforrások és frissítések
Napjainkban a (mindennapi felhasználásra szánt, nem katonai célú, stb.) szoftver termékek fejlesztési és kiadási ciklusa lerövidült; talán az is kijelenthető, hogy a gyártók számára a funkcionalitás fejlesztésén alapuló versenyelőny fontosabbnak tűnik a stabilitásnál és a hibamentességnél. Emiatt(?) a működési hibák és biztonsági problémák nem jelentéktelen részét már a kiadás után fedezik fel, és ezek javításáról kiadások közötti frissítésekkel (patchekkel) igyekeznek gondoskodni. Ezek telepítése, a szoftver napra készen tartása a felhasználó (és az üzemeltető) elemi érdeke.
A frissítések követésére nagyjából az alábbi technikai lehetőségek állnak rendelkezésre:
- A frissítések követését az operációs rendszer beépített szolgáltatása (a Windows Update) végzi úgy, hogy mind a frissítések megjelenésének figyelése, mind azok telepítése automatikusan, felhasználói beavatkozás nélkül is megtörténhet (a Windows komponenseken kívül pl. a Skype esetében);
- A frissítések követését egyéb, emelt jogosultsággal, háttérben futó szolgáltatás végzi, ugyancsak teljesen automatizálható módon (pl. Windows Áruház, az onnan beszerzett alkalmazások esetében; a Mozilla Maintenance Service a Mozilla Firefox és Mozilla Thunderbird alkalmazások esetében; illetve pl. a Secunia PSI amely kifejezetten erre a feladatra szakosodva, számos, 3rd party alkalmazás frissítéskövetését igyekszik ellátni);
- A frissítések követése automatizált ugyan, de a telepítés rendszergazda jogosultságú felhasználó jóváhagyásához (UAC) kötött - emiatt a korlátozott felhasználó önállóan nem képes gondoskodni az alkalmazás napra készen tartásáról (igen gyakori megoldás, ilyenek pl. az Adobe, Oracle Java frissítőprogramjai, stb.);
- A frissítések követése félig-meddig automatizált (pl. az alkalmazás minden elindításakor keres frissítést), de a frissítés telepítése nincs különösebben támogatva - arra jogosult felhasználóként az első telepítéshez hasonló (emelt jogosultságú) lépéseket kell elvégezni minden frissítés esetén (szintén gyakori megoldás, ilyen pl. a LibreOffice frissítője, stb.);
- Léteznek ugyan frissítések, de ezeknek sem a figyelése, sem a telepítése különösebben nem támogatott; a felhasználó pl. hírlevélből vagy a gyártó weblapjának periodikus ellenőrzésével értesülhet a frissítésekről, és ezeket az az első telepítéshez hasonló (emelt jogosultságot igénylő) módon kell telepítenie (ilyen pl. a PuTTY SSH-kliensprogram);
- Nincsenek könnyedén követhető frissítések.
A fenti eljárások közül csak az első két pontban foglaltak tekinthetők megnyugtatónak - tapasztalat szerint, ahol (bármilyen csekély) felhasználói beavatkozásra szükség van, ott a frissítések el fognak maradni. Ebből következően, ha lehetőségünk van nagyjából azonos funkciókat biztosító szoftverek közötti választásra, preferáljuk az automatikus frissítéssel rendelkező (vagy legalább az előbbi listában minél feljebb szereplő) megoldást.
Mivel a Windows (ellentétben pl. a Linux terjesztésekkel) jelenleg csak szerényen disztribúció jellegű (azaz kevés olyan alkalmazás van, amelynek frissítése az operációs rendszerrel azonos forrásból történik, és csak ilyen alkalmazások használatával a szükséges funkcionalitás jelenleg nem tűnik biztosíthatónak), az alkalmazások napra készen tartását más úton kell biztosítanunk:
- Vállalati környezetben elkészíthetünk és karbantarthatunk egy saját Windows alkalmazás repository-t, amelybe felvesszük a vállalati házirend szerint támogatott alkalmazásokat, ezek frissítéseit követjük, és a munkaállomásokra olyan frissítő szoftvert telepíthetünk, amely ebből a repository-ból dolgozik (TODO!);
- TODO!
- Tudomásul vehetjük, hogy a frissítéskezelés teljesen nem automatizálható - ez esetben gondoskodnunk kell a Windows munkaállomások periodikus rendszergazdai revíziójáról.
Magángépek esetén, illetve kisvállalati körülmények között a Windows munkaállomásokon az alkalmazások frissítésének állapotát időről időre, rendszergazdai bejelentkezéssel ellenőrizni kell. Ezt a feladatot tényegesen be kell ütemezni és erre erőforrást kell allokálni.
Egyéb konvenciók
A helyi fájlrendszer használata
Bár megfelelő fájlrendszerbeli jogosultságok esetén tulajdonképpen mindegy, hogy mi hol van, érdemes törekedni áttekinthető mappaszerkezet fenntartására.
TODO!
A felhasználói felület beállításai
TODO!
Személyes felelősség
TODO!
