Felkészülés egy Auditra


Tagek: Egyéb,
Írta: toshy
Publikálva: 2010-06-16 15:16:10



avagy

mikor a farok csóválja....



Egy rendszergazdát, szerverfarmot általában szívesen auditálnak , különböző okokból. Vagy azért mert a cég szeretne elérni egy bizonyos minősítést, vagy azért mert egy cégnek erre a típusú melóra külön csapatott tart fent, és ezeknek az embereknek pedig ez a munkája.
Aztán az is elképzelhető még, hogy a médiában (Internet, Magazinok, TV.... stb) az hallani , hogy X,Y cég rendszerét támadás érte.... stb.
Erre természetesen úgy reagálnak , hogy nálunk minden rendben, vagy ha nem akkor az emberi mulasztás, mert valaki nem tartotta be a szabályokat.
Ezzel a cikkel 2 alapvető célt szeretnék elérni.
Az egyik hogy valamilyen szinten segítsek felkészülni egy auditra.
A másik hogy bemutassam, mennyire igaz az a kifejezés, hogy a "farok csóválja".


Szóval IT AUDIT.



3 dologra tud épülni egy ilyen audit.

Az első és ez mindennek az alapja a "Process" vagyis a munkafolyamat leírása.
Ahol jól érthetően le van írva minden felelőségi kör, "eszkalációs útvonal", a dokumentáció mikéntjét ...stb.
Azért kell ez mert erre támaszkodva lehet védekezni egy audit folyamán, de a támadások is csak innen indulhatnak.
Nem szép dolog ezt egy harchoz hasonlítani, de ez illik rá a legjobban.
Szóval ha megvan a munkafolyamat leírása akkor már nincs más dolgunk csak betartani azt. Nyilván adódhatnak olyan nem várt, vagy nem tervezet helyzetek, amire nem illeszkedik a doksi egyetlen eleme sem. Ezekre is kell hagyni egy kiskaput a dokumentációban.
Ha megvan a munkafolyamat leírás, és mindenben arra támaszkodunk akkor már csak 2 másik dologra kell nagyon figyelni.


A második az "Approve" azzaz jóváhagyás.
Mindig mindent jóvá kell hagyatni, azt hogy milyen témában, vagy kivel az ugye a munkafolyamat leírásban kell szerepeljen.
Tehát ha mondjuk egy bármilyen kis változtatást is megfelelően körülményesen le kell írni. Minek a változtatás , ha esetleg valaki kért valamit , mondjuk egy ügyfél, és ahhoz kell akkor az illető ügyfél levelét a kérdéses változásról csatolni.
Leírni mit érint ez a változás, mi történhet a legrosszabb esetben mekkora szolgáltatás kiesést jelenthet ez. Ha vissza kell állni valamilyen nem várt, vagy előre nem látott okokból, akkor annak mi a menete ez esetben mennyi idő a vissza állás.
A munka tervezett idő pontját, az változtatás végző személy nevét, a munka elvégzéséhez szükséges ajánlott illetve minimális eszközöket, vagy szolgáltatásokat.
Pl. áram, vagy hálózat, vagy internet, vagy világítás, de lehet eső mentes napsütéses napot is megemlíteni egy színpadi hangosítás esetén, vagy bármilyen hasonló munkák esetén.
Ha megvannak a szükséges jóváhagyások, akkor jöhet a harmadik dolog.


Mindent dokumentálni.
A munkafolyamatot, a jóváhagyásokat, a felszanálói neveket azoknak az újra validálását (erről többet kicsit később)
Dokumentálni a dokumentációt is kell :-)
Itt egy rövid kis példa hátha ezzel jobban tudom szemléltetni ezt a mindent dokumentálni kell dolgot.
Meg kell megjegyeznem, hogy a példa egy megtörtént IT AUDIT alkalmával történt, de ugyanakkor nem egyezik meg pontosan a problémával, hiszen erről nem beszélhetek, de érzékeltetni tudom vele a lényeget.
Szóval adott a hálózati eszközökre egy autentikációs szerver ami legyen egy freeradius-os Linux szerver, természetesen clusterben a redundancia miatt. Annak természetesen van egy adatbázisa amiben a felhasználói nevek nyilván vannak tartva, és megfelelően loggolja is mikor kért hozzá férést, mihez , ezt mikor kapta meg, ki hagyta jóvá neki, esetleg ugyan ebben az adatbázisban nyilván lehet még tartani, hogy mikor lépet be , és hova ezzel az ID-val.
Na most általában a process doksikban le van írva hogy egy felhasználói fiókhoz a jelszó bonyolultsága milyen kell legyen, milyen időközönként kell azt megváltoztatni, milyen időközönként kell újra validálni.


Erre a "Validálásra" térjünk most ki egy kicsit.
Az nem elég ha valakinek létrehozunk egy felhasználói fiókot, mert mi van ha az illető már nincs a cégnél, vagy elment szülési szabadságra, vagy nincs már szüksége az adott hozzáférésre.
Ezért általában két dolgot szoktak csinálni az egyik egy folyamatos, mondjuk heti , vagy havi ACL lista re validációt ami mondjuk annyiból áll, hogy megnézi a nyilvántartó adatbázisban, hogy az ott szereplő felhasználói fiók, és le adminisztrált jogosultság egyezik-e a meglévő hozzáféréssel.
A másik, hogy bizonyos időközönként újra kérdezzük az illetőt, hogy szüksége van-e az adott hozzáférésre.
Ha nem jön semmi válasz akkor mondjuk egy következő levélben valami "biztos nincs ?" című levélben értesíteni, hogy ok, akkor vissza vonjuk a hozzá férését. Ezzel a két dologgal valamilyen szinten minimalizálni lehet a használaton kívüli felhasználói fiókokkal való visszaélést. Természetesen mindezeknek a re validálásoknak nyoma kell legyen log-ban, levelezésben, vagy ott ahol meg van határozva a munkafolyamat leírásban.


Akkor térjünk vissza a példához.
Szóval mondjuk ez egy kis cég és van egy ember aki hálózati adminisztrátor.
Ez az ember be kell tudjon lépni a hálózati eszközökre, hogy adminisztrálhassa őket.
Ehhez jogosultságot kell kérnie, a "nyilvántartó" adatbázisban.
Mivel Ő az adminisztrátor ezért le is adminisztrálja ezt magának.
Ugye ti is érzitek, hogy ez bár így szabályos, mekkora egy marhaság, tehát kérek magamtól magamnak egy ID-t amit eleve nem is tudnék le adminisztrálni, ha nem lenne már eleve egy felhasználói fiókom, így le adminisztrálom magamnak :)))))
De komoly audit finding lehet egy ISO auditon ha ez nincs így le adminisztrálva.


És most jöjjön a "amikor a farok csóválja" dolog.
Képzeljük el, hogy adott egy közepes méretű cég, mondjuk ~10 szerves szerver parkkal, ~150 hálózati végponttal, és kb ~100 alkalmazottal.
Erre mondjuk felvesznek két rendszergazdát de úgy, hogy az egyik a hálózatokkal is foglalkozik a másik meg mondjuk Level 1-es support-ot is ad a felhasználóknak, tehát HelpDesk-ezik.
Na most ha folyamatosan megy a fent említett ACL-es illetve re validációs process, akkor kizárt, hogy ezt a munka kört el tudja látni 2 ember, sőt talán három sem.
Általában ez a szomorú Magyar valóság.
Hiszen mindig mindenki igyekszik ott húzni a azt a nadrág szíjat ahol csak lehet.
Általában ilyenkor megint a nem megfelelő emberek a megfelelő tudás hiányában hoznak meg olyan döntéseket aminek aztán nem értik a következményét. Például otthagyják a rendszergazdák a melót, hiszen munka idejének 70%-ban csak adminisztrál.

Szólj hozzá

Hozzászólások(3)