Ez a cikk az első egy cikksorozatban, amely a "Hogyan vegyük kontrollunk alá a hálózati infrastruktúrát" címet viseli. A cikksorozat összes cikkének tartalmát és linkjeit itt találja .
Teljesen el tudom képzelni, hogy sok olyan cég létezik, ahol egy egyszerű hálózat esetén az egy óra vagy akár egy nap sem számít kritikusnak. Sajnálatos módon nem volt alkalmam olyan helyeken dolgozni. De természetesen a hálózatok különbözőek, az igények széles spektrumot ölelnek fel, és a megközelítések is eltérőek, ennek ellenére az alábbi lista sok esetben gyakorlatilag "muszáj" lesz.
Tehát, az alapfeltételek.
Új munkahelyen van, vagy előléptették, vagy egyszerűen új megvilágításba helyezte a feladatait. A vállalat hálózata az Ön felelőssége. Számos szempontból ez kihívás, ami némileg indokolja ennek a cikknek a mentoráló jellegét :). De remélem, hogy ez a cikk bármely hálózati mérnök számára hasznos lehet.
Az első stratégiai célja, hogy megtanuljon szembenézni az entrópiával és fenntartani a nyújtott szolgáltatás szintjét.
A lentebb leírt feladatok közül sok különböző eszközökkel megoldható. Szándékosan nem említem a technikai megvalósítást, mert alapvetően gyakran nem számít, hogyan oldott meg egy adott feladatot, hanem az, hogy milyen hasznosan alkalmazza azt, és egyáltalán használja-e. Például alig van értelme a professzionálisan kidolgozott megfigyelő rendszerének, ha nem nézi, és nem reagál az értesítésekre.
Hardver
Először is meg kell értenie, hogy hol vannak a legnagyobb kockázatok.
Ismét eltérő lehet. El tudom képzelni, hogy valahol például a biztonsági kérdések, máshol a szolgáltatás folytonosságával kapcsolatos problémák, vagy talán valami más. Miért ne?
Tegyük fel, hogy a szolgáltatás folytonossága az a terület, amelyre fókuszálunk (ez így volt minden cégnél, ahol dolgoztam).
Így a felszerelésekkel kell kezdenünk. Íme egy lista azokról a témákról, amelyekre figyelni kell:
- az eszközök kritikus szint szerinti osztályozása
- kritikus eszközök tartalékossá tétele
- támogatás, licencek
Fontos, hogy átgondoljátok a lehetséges meghibásodásokat, különösen a kritikus fontosságú berendezések esetében. Gyakran figyelmen kívül hagyják a dupla meghibásodások valószínűségét, máskülönben a megoldás és a támogatás feleslegesen drága lehet. De a valóban kritikus hálózati elemek, amelyek meghibásodása jelentős hatással lehet a vállalkozásra, esetében ezt is figyelembe kell venni.
támadásra
Tegyük fel, hogy a központi kapcsolóról beszélünk az adatközpontban.
Mivel arra állapodtunk meg, hogy a szolgáltatás folyamatossága a legfontosabb szempont, ésszerű biztosítani ennek az berendezésnek a „forró” redundanciáját. De ez még nem minden. Azt is meg kell határoznotok, hogy mennyi ideig, ha az első kapcsoló meghibásodik, tudtok elfogadni, hogy csak egy kapcsolóval működtettek, hiszen van kockázat, hogy az is elromlik.
Fontos! Ezt a kérdést nem ti dönthetitek el. A kockázatokat, lehetséges megoldásokat és költségeket a vezetőségnek vagy a cég vezetésének kell ismertetni. A döntéseket nekik kell meghozniuk.
Tehát, ha úgy döntenek, hogy a dupla meghibásodás kis valószínűsége mellett a négy órás üzemelés egy kapcsolóval elfogadható, akkor egyszerűen szerződhettek a megfelelő támogatásra (amelynek keretében a berendezést négy órán belül kicserélik).
De mi van, ha nem érkezik meg? Sajnos egyszer már voltunk ilyen helyzetben. Négy óra helyett egy hétig tartott a berendezés szállítása!!!
Ezért ezt a kockázatot is meg kell beszélni, és talán érdemes lenne még egy kapcsolót (harmadik) vásárolni és azt tartalékban (hideg redundancia) tartani, vagy laboratóriumi célokra használni.
Fontos! Készítsetek egy táblázatot az összes támogatásról, amivel rendelkeztek, a lejárati dátumokkal, és adjátok hozzá a naptárhoz, hogy legalább egy hónappal a lejárat előtt értesítést kapjatok arról, hogy a támogatás meghosszabbításával foglalkozni kell.
Nem fogják megbocsátani, ha elfelejted megújítani a támogatást, és másnap, amikor lejár, elromlik a berendezésed.
Vészhelyzeti munkák
Bármi is történjen a hálózatodban, ideális esetben meg kell őrizned a hozzáférést a hálózati berendezéseidhez.
Fontos! Hozzáféréssel kell rendelkeznie az összes berendezéshez, és ennek a hozzáférésnek nem szabad függenie az adathálózat működőképességétől.
Ezen kívül előre kell gondolkodnia a lehetséges negatív forgatókönyveken, és dokumentálnia kell a szükséges intézkedéseket. E dokumentum elérhetősége szintén kritikus, ezért nemcsak a részleg közös erőforrásában kell közzétennie, hanem lokálisan is el kell mentenie a mérnökök számítógépeire.
Kötelező, hogy ott legyen
- információ, amely szükséges a szállító vagy integrátor támogatására történő kérelem benyújtásához
- információ arról, hogyan lehet hozzáférni bármely berendezéshez (konzol, menedzsment)
Továbbá természetesen bármilyen egyéb hasznos információt is tartalmazhat, például különböző berendezések frissítési eljárásának leírását és hasznos diagnosztikai parancsokat.
Partnerek
Most értékelnie kell a partnerekkel kapcsolatos kockázatokat. Általában ez
- internetszolgáltatók és a forgalomcsere pontjai (IX)
- kommunikációs csatorna szolgáltatók
Milyen kérdéseket kell feltennie magának? A berendezésekhez hasonlóan különböző vészhelyzeti forgatókönyveket kell számításba venni. Például internetszolgáltatók esetén ez ilyesmit jelenthet:
- mi történik, ha az X internetszolgáltató valamilyen okból kifolyólag megszünteti a szolgáltatást?
- elégséges lesz-e a többi szolgáltató sávszélessége?
- mennyire marad meg a kapcsolat Stabilitása?
- mennyire függetlenek az internetszolgáltatói, és okozhat-e egy komoly baleset az egyiküknek problémát a többieknél?
- hány optikai bejöveteled van az adatközpontodba?
- mi történik, ha az egyik bejövő teljesen megsemmisül?
A bejövőkkel kapcsolatban, a két különböző cégnél szerzett tapasztalatom alapján, az egyik adatközpontokban helyezkednek el, ásó tönkretette a kutakat, és csak csodával határos módon maradtak épen az optikai kábeleink. Ez nem is olyan ritka eset.
Nos, természetesen nemcsak ezeket a kérdéseket kell feltennie, hanem újra, a vezetőség támogatásával, biztosítania kell a megfelelő megoldást bármilyen helyzetben.
Biztonsági mentés
A következő prioritás lehet a berendezések konfigurációinak biztonsági mentése. Ez minden esetben nagyon fontos szempont. Nem sorolnám fel azokat az eseteket, amikor elveszítheti a konfigurációt, inkább rendszeresen végezzen biztonsági mentést, és ne gondoljon erre. Ezen kívül a rendszeres biztonsági mentés nagyon hasznos lehet a változások ellenőrzésében.
Fontos! Készítsen napi biztonsági másolatot. Ez nem olyan nagy adatmennyiség, hogy spóroljon rajta. Reggel a felelős mérnöknek (vagy Önnek) meg kell kapnia a rendszertől egy jelentést, amely egyértelműen jelzi, hogy a biztonsági másolat sikeres volt-e vagy sem, és ha nem volt sikeres a biztonsági másolat, akkor a problémát meg kell oldani, vagy jegyet kell létrehozni (lásd a hálózati osztály folyamatait).
Szoftververziók
A kérdés, hogy érdemes-e frissíteni a szoftveresen a hardvert, nem egyértelmű. Egyrészt a régi verziók ismert hibákat és sebezhetőségeket tartalmaznak, másrészt az új szoftver mindig nem fájdalommentes frissítési folyamatot jelent, és másrészt új hibák és sebezhetőségek is előfordulhatnak.
Itt meg kell találni az optimális megoldást. Néhány nyilvánvaló ajánlás:
- csak stabil verziókat telepítsen
- mégsem érdemes teljesen régi szoftververziókon élni
- készítsen táblázatot az információkkal, hogy melyik szoftver hol található
- időnként olvassa el a sebezhetőségi és hiba-nyilvántartási jelentéseket a szoftver verzióiról, és ha kritikus problémák merülnek fel, érdemes elgondolkodnia a frissítésen
Ezen a lépésen, konzolos hozzáféréssel a hardverhez, a támogatási információval és a frissítési eljárás leírásával alapvetően készen áll a lépésre. Ideális az a helyzet, amikor laboratóriumi hardver áll rendelkezésre, ahol tesztelheti az egész eljárást, de sajnos ez nem gyakran fordul elő.
Kritikus hardver esetén keresheti a gyártó támogatását, hogy segítsenek a frissítés végrehajtásában.
Jegykezelő rendszer
Most körülnézhet. Rendelkeznie kell azzal a folyamattal, amely lehetővé teszi a más részlegekkel való együttműködést és a részlegen belüli kapcsolatokat.
Ez lehet, hogy nem kötelező (például, ha a cége kicsi), de nagyon ajánlom, hogy úgy szervezze meg a munkát, hogy minden külső és belső feladat a jegyrendszeren keresztül menjen.
A jegyrendszer tulajdonképpen az Ön interfésze a belső és külső kommunikációhoz, és kellő részletességgel kell leírnia ezt az interfészt.
Nézzük meg például egy fontos és gyakran előforduló feladatot az hozzáférés megnyitásáról. Leírom az algoritmust, amely jól működött az egyik cégnél.
támadásra
Kezdjük azzal, hogy gyakran a hozzáférési kéréseket olyan nyelven fogalmazzák meg a megrendelők, amelyet a hálózati mérnökök nem értenek, nevezetesen az alkalmazás nyelvén, például: "nyissák meg nekem a hozzáférést a 1C-hez."
Ezért soha nem fogadtuk el közvetlenül az ilyen felhasználóktól érkező kéréseket.
Ez volt az első követelmény.
- A hozzáférési kérelmeknek a technikai osztályoktól kell érkezniük (a mi esetünkben ez a unix, windows, helpdesk mérnök volt).
A második követelmény az, hogy
- a hozzáférést jegyzőkönyvezni kell (azt a technikai osztálytól, ahonnan a kérést kaptuk), és mint kérést, egy hivatkozást kell kapjunk erre a jegyzőkönyvezett hozzáférésre.
A kérés formájának érthetőnek kell lennie számunkra, azaz
- a kérésnek tartalmaznia kell információt arról, hogy melyik és melyik alhálózatba kell megnyitni a hozzáférést, valamint a protokollt és (tcp/udp esetén) a portokat.
Ezenkívül meg kell adni
- a hozzáférés célját,
- ideiglenes vagy állandó (ha ideiglenes, akkor meddig).
És egy nagyon fontos pont az engedélyek,
- a hozzáférést kezdeményező osztály vezetőjétől (például a könyveléstől).
- a technikai osztály vezetőjétől, ahonnan a kérelem a hálózati osztályhoz érkezett (például a helpdesktől).
Eközben ennek a hozzáférésnek a "tulajdonosa" a hozzáférést kezdeményező osztály vezetője, és ő felelős azért, hogy annak az osztálynak a jegyzőkönyvezett hozzáférések oldala naprakész maradjon.
Naplózás
Ez az a dolog, amibe bele lehet merülni. De ha proaktív megközelítést szeretne bevezetni, meg kell tanulnia kezelni ezt az adatáradatot.
Íme néhány gyakorlati ajánlás:
- a naplókat naponta kell átnézni.
- Tervezett átnézés esetén (nem vészhelyzetben) elég, ha a kritikus szintekre (severity) 0, 1, 2 korlátozódik, és ha szükséges, hozzáadhat kiválasztott mintákat más szintekből.
- Írjon egy szkriptet, amely elemzi a naplókat és figyelmen kívül hagyja azokat a naplókat, azok mintáit, amelyeket hozzáadott az ignoráló listához.
Ez a megközelítés lehetővé teszi, hogy idővel összeállítson egy ignoráló listát a nem érdekes naplókról, és csak azokat hagyja meg, amelyek valóban fontosak az Ön számára.
Nálunk ez remekül működött.
Monitorozás
Nem ritka, hogy a vállalatnál hiányzik a megfigyelési rendszer. Például számíthat a naplókra, de a berendezés egyszerűen "meghalhat", anélkül hogy bármit "mondana", vagy az UDP csomag, amely a syslog protokollt használja, elveszhet és nem érkezik meg. Összességében a proaktív megfigyelés fontos és szükséges.
Két a legkeresettebb példa a gyakorlatomban:
- a hálózati kapcsolatok, kritikus linkek (például a szolgáltatókhoz való csatlakozás) terhelésének figyelése. Ez lehetővé teszi a potenciális szolgáltatásromlási problémák proaktív észlelését a forgalom elvesztése miatt, ezáltal megelőzhető azok megjelenése.
- grafikonok, amelyek a NetFlow alapján készülnek. Ezek könnyen lehetővé teszik a forgalmi anomáliák megtalálását, és nagyon hasznosak egyes egyszerű, de lényeges hacker támadások felfedezésére.
Fontos! Állítsa be az sms értesítést a legkritikusabb eseményekhez. Ez vonatkozik mind a megfigyelésre, mind a naplózásra. Ha nincs ügyelet, akkor az sms-eknek az üzletidőn kívül is meg kell érkezniük.
Gondolja át a folyamatot úgy, hogy ne ébressze fel az összes mérnököt. Nálunk volt rá ügyeletes mérnök.
Változások nyomon követése
Véleményem szerint nem szükséges az összes változást ellenőrizni. De mindenképpen lehetősége legyen arra, hogy szükség esetén könnyen megtalálja, ki és miért hajtott végre változásokat a hálózaton.
Néhány tanács:
- használjon jegykezelő rendszert a részletes leírás érdekében arról, hogy mi történt e jegy keretein belül, például a végrehajtott konfiguráció másolásával a jegybe
- használja a hálózati berendezéseken elérhető megjegyzési lehetőségeket (például commit comment a Juniper esetében). Feljegyezheti a jegy számát
- használja a konfigurációs biztonsági másolatok diff-fájljait
Ez folyamatként is megvalósítható, naponta áttekintve az összes jegyet a változások ügyében.
Folyamatok
Formálisan rögzítenie és le kell írnia a csapatában lévő folyamatokat. Ha eljutott ehhez a ponthoz, már léteznie kell legalább a következő folyamatoknak a csapatában:
Napi folyamatok:
- jegyek kezelése
- naplók kezelése
- változások ellenőrzése
- napi ellenőrző lista
Éves folyamatok:
- garanciák, licencek megújítása
Aszinkron folyamatok:
- válasz különböző vészhelyzetekre
Az első rész következtetése
Megfigyelted, hogy mindez még nem a hálózat konfigurálásáról, a tervezésről, a hálózati protokollokról, az útválasztásról vagy a biztonságról szól… Ez valami körülötte. De ezek a, bár unalmasnak tűnhetnek, természetesen nagyon fontos elemei a hálózati osztály munkájának.
Jelenleg, ahogy látod, még semmit sem javítottál a hálózatodban. Ha voltak biztonsági részek, akkor azok megmaradtak, ha volt rossz tervezés, az is megmaradt. Még nem alkalmaztad a hálózati mérnöki tudásod és készséged, amire valószínűleg sok időt, energiát és néha pénzt költöttél. De először meg kell alapozni ( vagy megerősíteni) az alapokat, és csak azután foglalkozhatsz az építkezéssel.
Arról, hogyan lehet keresni és elhárítani a hibákat, majd javítani az infrastruktúrádat – erről szólnak a következő részek.
Természetesen nem szükséges mindent sorrendben csinálni. Az idő kritikus lehet. Parallelikusan dolgozhatsz, ha engedélyezik az erőforrások.
És egy fontos kiegészítés. Kommunikálj, kérdezd meg, konzultálj a csapatoddal. Végül is, ők támogatják és végzik mindezt.
Forrás: habr.com
