12. fejezet, avagy az utcsó biztonságos chapter

Chapter XII. User And Data Security (Adat és felhasználó védelem)

 

Ez a fejezet ismét egy olyan fejezet, amelyben leírtak szinte teljesen eltérnek Winforms-nál illetve Webforms-nál. Én most az utóbbival fogok foglalkozni.
Az első lecke végre valahára úgy kezdődik, hogy a dolgok mögötti fogalmakat megmagyarázza. Ez azért tetszik most ennyire, mert az előtte illetve utána lévő néhány fejezetben sajnos ez nem annyira sikerült. Így mindenkinek világos, mi az autentikáció (felhasználó azonosítás) és mi az autórizáció (jogosultság kezelés).
Az előbbi két fogalomra épül az RBS (Role Based Security, szerepalapú biztonság). Webalkalmazásnál kicsit másképp is történhet a felhasználó azonosítás, mint winforms alatt. Hiszen lehetőségünk van windows, űrlap alapú(forms) és passport felhasználó hitelesítésre vagy akár Anonymous autentikációra is. Ezért webalkalmazásoknál inkább a Roles, MemberShip illetve FormsAuthentication osztályokat használjuk.
Egy hasznos tulajdonsága a FormsAuthentication osztálynak a RequireSSL, amelyet, ha true állítunk, akkor a sütik, melyek tartalmazzák az authentication ticket –et SSL-en (Secure Sockets Layer) keresztül jutnak el a klienstől a szerverig, illetve vissza. Ezt akár a web.config-ban is beállíthatjuk:
<authentication mode="Forms">
  <forms loginUrl=" login.aspx"
    cookieless="UseCookies"
    requireSSL="true"
    slidingExpiration="false"
    …
</authentication>

AuthenticationTicket készítésére akkor van szükségünk, ha egyedi azonosítást szeretnénk, íme egy nagyon egyszerű példa:
if (FormsAuthentication.Authenticate(UserName.Value, UserPassword.Value))
{
    FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(UserName.Value, false, 5000);          
    FormsAuthentication.RedirectFromLoginPage(UserName.Value, Persist.Checked);
}
És ha esetleg lejárna a süti érvényességének (életének) ideje, akkor a RenewTicketIfOld() metódus segítségével tudjuk megújítani, bár célszerűbb a csúszó időt beállítani (lsd. fentebb config fájl /slidingepiration/).

 

A MemberShip-nél én most csak a MemberShipUser osztályt emelném ki. Ezen keresztül egy-két infót eltudunk érni a felhasználókról. De sokszor szükségünk van sok egyéb adatra is, nem csak az e-mail címre. Ilyenkor használhatjuk a Profile-t, vagy felüldefiniálhatjuk a MemberShipUser osztályt. Erre íme egy tanulságos tutorial:
http://msdn2.microsoft.com/en-us/library/ms366730(vs.90).aspx

 

A Role Managment osztályok közül számunkra igazándiból a fontosabbak: a Roles, a RolePrincipal illetve a RoleManagerModule. A Roles-ról már volt régebben szó, így most őt nem vesézném ki. A RolePrincipal az az osztály mely tartalmazza az adott userhez tartozó szerepköröket. Ezt veheti adatbázisból vagy akár sütiből is. A RoleManagerModule osztály kezeli a RolePrincipal objektumokat.

 

ASP.NET esetén kétfajta jogosultság kezelésről beszélhetünk: Fájl illetve Url alapú. Ezek alapján beszélhetünk FileAuthorizationModule -ról illetve UrlAuthorizationModule –ról. Az első esetén az aspx illetve asmx fájlokhoz tartozó ACL jogosultságot ellenőrzi le. Ha nem windows autentikációt használunk, akkor annak a windows user-nek ellenőrzi a jogosultságait, akinek a nevében futnak az ASP.NET process.
Az UrlAuthorizationModule pedig a web.config-ból már jól ismert allow illetve deny segítségével van megvalósítva.

Végül még a titkosításos részhez lenne két hozzáfűzni valóm. Régebben halottam még egy nagyon jó szemléltetést a hashelésre. A hashelést magyarul néha sózásnak is hívják. Ebből következően, ha van egy masszánk, amit megsózunk, akkor kapunk egy „másik” masszát. Ebből már nem tudjuk kiszedni a sót (tehát a hashelt alakot nem tudjuk vissza fejteni). De újra elő tudjuk állítani a sózott masszát, amelyet össze tudunk hasonlítani egy régebbi sózott masszával (tehát determinisztikus, így reprodukálható).
Ha a beépített ASP.NET felhasználó kezelést/hitelesítést használjuk, akkor a userek jelszavainak az ASPNETDB adatbázisban egy-egy MD5-ös hashelt alakja lesz eltárolva!

 

A szimmetrikus illletve asszimmetrikus titkosítással kapcsolatban pedig az alábbi két cikket ajánlom a figyelmetekbe:
http://www.biztostu.hu/mod/resource/view.php?id=463
http://www.biztostu.hu/mod/resource/view.php?id=464

 

Végül pedig egy idézet:
Aki azt hiszi, hogy feltörhetetlen titkosítási módszert talált ki, az vagy hihetetlenül ritka zseni vagy naiv és tapasztalatlan
Phil Zimmermann

 

Math.Sqrt(121) + “.” + translate(“head”, “hungarian”) + ” ezet”;

Chapter XI. Application Security (Alkalmazás biztonság)

Alapjában véve háromfajta biztonsági szintet vagy módszert különbözettünk meg egymástól jogosultság kezelés szempontjából:
– Code Access Permissions
– Identity Permissons
– Role-Based Security Permissions

Még mielőtt megnéznénk mi mire is jó, fontos hogy megértsük, mi is az a jogosoltság kezelés egyáltalán.
3féle jogosultság kezelést különböztetünk meg (kicsit pongyolán megfogalmazva):
– Amikor a kódnak vagy erőforrásnak van szüksége jogosultságokra.
– Amikor magához az alkalmazás vagy szerelvény futattásához kellenek a szükséges jogosultságok
– Illetve amikor bizonyos kódok lefutását jogosultságokhoz szeretnénk kötni.
A különböző jogosultság kezeléseket mind-mind a CLR (Common Language Runtime) végzi. Ezek között természetesen sokszor van átfedés, ugyanígy a három biztonsági módszer között sem tudjuk meghúzni az éles határokat, de körülbelül az alábbiakat jelentik:
– CAP: erőforrások hozzáférés kezelése, védett műveletek végrehajtása
– IP: szerelvények (assemblies) azonosítása /könyvben emlékezzünk vissza az evidence témakörre/
– RBS: felhasználó azonosító vagy csoport alapján történik a jogosultság kezelés

Az Identity Permissions alá a követlező jogosultság objektumok tartoznak:
PublisherIdentityPermission, SiteIdentityPermission, StrongNameIdentityPermission, URLIdentityPermission, ZoneIdentityPermission
 
Az RBS-ről fog szólni a 12. fejezet, szal ezt egyenlőre kicsit még mellőzöm.

A CAP vagy ennek bővebb témaköre a CAS (kóderedet-alapú biztonság), ami minket most inkább érdekel. Itt igazándiból kétféle dologról van szó, amik között szintén van némi áthallás:
– erőforrás védelem
– művelet védelem (deklaratívan, imperatívan )
Általában akkor van szükségünk a művelet védelemre, ha valamilyen erőforrással dolgozunk, tehát akár azt is mondhatnánk, hogy erőforrás védelem indirektbe. A védelem szavak alatt itt a jogosultság kezelést értsük, ne azt, hogy pl.: egyszerre csak egy felhasználó férhet hozzá az erőforráshoz, stb.
Ezeket a funkciókat az alábbi módokon érhetjük el:
– Jogosultság, jogosultság csomagok deklarálásával rendszer erőforrásokhoz
– Rendszergazdáknak lehetőség van code group-ok létrehozására a jogosultság csomagokból
– Lekérdezhető az erőforrás különböző használatihoz szükséges jogosultságok
– Szerelvények betöltéséhez szükséges jogosultságok
– Ellenőrizhető, hogy a kódot hívó rendelkezik-e speciális jogosultságokkal
– Ellenőrizhetó, hogy a hívó ki csoda (digitális aláírással, hogy egy adott oldalhoz vagy csoporthoz tartozik-e)
– Szigorítható a hívó feltétel, különböző +jogosultságok igénylésével.

Egy kicsit régi (2003-as) cikket ajánlanék a figyelmetekbe, ami szerintem valamivel érhetőben magyarázza el a Code Group >> Permission Set >> Permission lényegét, mint ahogy a könyvben van:
http://www.ondotnet.com/pub/a/dotnet/2003/02/18/permissions.html

 

A jogosultság garantálásra kétféle módszer van:
– mi találjuk ki, hogy mi kell neki 
– ő megmondja mit kér, mi megadjuk.
Kicsit pongyalára sikeredett, de legalább érthető! Ez természetesen az application domain-re is és az assembly-re is érvényes!

Akit bővebben érdekel a Code Access Security, ajánlom figyelmébe az MSDN eléggé részletes és eléggé elméleti jellegű témáját:
http://msdn2.microsoft.com/en-us/library/930b76w0.aspx

Remélem ezzel, hogy most nem plussz új objektumokat, illetve példakódokat mutogattam nem okoztam senkinek csalódást. Én úgy éreztem a fejezet olvasása során, hogy sok fontos dolog nem lett kimondva, de a lényegtelenről viszont volt rizsa. Ezért gondoltam úgy, hogy megpróbálom valahogy az egészet formába önteni, remélem sikerült!

Surface vs. Magyarok?

Nem régiben, júniusban, egy magyarországi kft-nek is sikerült előállítani működő multitouch technológiát. A cég a Mobilia-Artica, amely egy belsőépítészeti tervező- és kivetelező cég. (sajnos képet, illetve leírást még nem találtam róla az oldalukon)…
A 80-as évek elején már elkezdtek foglalkozni a multitouch megvalósításával, de igazi áttörés a Surface volt. Előtte még csak egy-egy pontot tudtak értelmezni az érintő képernyők. A magyar cégnek FTIR (Frustrated Total Internal Reflection) elven sikerült a több pont figyelését megvalósítani.
A magyar termék siker lehetősége a koncepciójukban rejlik. Ők úgyis a Microsoft-tal ellentétben nem egy dohányzó asztalba bezárva kínálják, hanem bármilyen felületbe beépíthetően. Pl.: egy étteremben a bárpultba, vagy asztalba beépítve az étlap megtekintéséhez, illetve a rendelés leadásához.
Őszintén szólva én kiváncsi vagyok, melyik hotel/étterem/könyvtár/oktatási intézmény, stb… lesz az első Magyarországon, mely először fogja valamelyik technológiai megvalósítást alkalmazni, használni!

Windows Xp telepítési trükkök…

Sajnos az elöző vizsgám nem sikerült, így július 4-ig hosszabítást kaptam a vizsgaidőszakra. Ezért ma csak egy rövidebb, de hasznos dologról fogok írni.
Pont a mi nap telepítettem újra a windows xp-met és közben eszembe jutott, hogy van egy-két nem teljesen triviális módon elérhető hasznos funkció.
Az egyik ilyen az, hogy a telepítési folyamatokat is van lehetőségünk nyomon követni! Vagyis nem csak azt láthatjuk, hogy még 34 perc van hátra (15 perce is ugyan ennyit írt ki), és a jól megírt marketing szöveget olvashatjuk (hétről-hétre újra-telepítésenként), hogy milyen jó is az új windows xp. 
A windows-os alkalmazás telepítéseknél megszokott ablakban láthatjuk egy progressbar-on a telepítés "készenlétségének" százalékos arányát, és azt hogy éppen mi települ. Ezt a funkciót a Shift + F11 billentyű kombinációval tudjuk előcsalni.
A másik, ami kicsit hasznos dolog lehet az az, hogy telepítés közben hívhatunk command promtot (parancssort). Ezt a Shift + F10 kombinációval tehetjük meg. Ez típikusan azért jó, mert már telepítés közben is játszanunk, akár flipper-t, vagy a kedvenc kártyás játékunkat. A flippert így érhetjük el: "C:\Program Files\Windows NT\Flipper\PINBALL.EXE", míg mondjuk a passzinánszt "sol.exe"!
Fontos azt megjegyezni, hogy ilyen a promt System nevében fut, tehát System jogosultsággal rendelkezünk, ezért csak óvatosan!!!

 

Két portálra szeretném felhívni a figyelmeteket, amelyek a Windows Xp-vel illetve a Windows Vista újdonságaival foglalkoznak:

http://www.msw.hu/

http://winportal.net/

A winportal-on is található erről egy leírás: http://winportal.net/?id=933 – Paszinánsz Windows telepítés közben

És a bejegyzés végére egy kis ajándék. Azok akik, még nem "gyakoroltál" elégszer azt, hogy hogyan is kell Windowst telepíteni, nekik íme egy Windows Xp telepítés szimulátor. (~1,23mb)

Ja és sajnos Vista telepítésnél nem elérhetőek ezek a funkciók!