Hogyan építsen ki robusztus biztonsági intézkedéseket szerverei védelmére

Bevezetés

Amikor felhőalapú infrastruktúrán dolgozik, a legfőbb szempont az, hogy alkalmazásai teljes mértékben működőképesek legyenek. A telepítési és bevezetési folyamat egyik fontos eleme, hogy hatékony, alapos és robusztus biztonsági intézkedéseket építsen be alkalmazásaiba vagy rendszereibe, mielőtt azokat a nyilvánosság számára elérhetővé tenné. Ahelyett, hogy a biztonsági intézkedéseket a telepítés után, visszamenőlegesen vezetné be, fontos biztosítani, hogy az infrastruktúrába egy biztonságos alapkonfiguráció legyen beépítve.

Ez az útmutató ebben nyújt segítséget. Kiemel bizonyos gyakorlati biztonsági intézkedéseket, amelyek a szerver infrastruktúrájának beállítása és konfigurálása során valósíthatók meg. Bár ez nem a szerverbiztonsági protokollok kimerítő listája, hasznos kiindulópontként szolgál. Ahogy dolgozik a környezetével és alkalmazásaival, és jobban megérti azok specifikus igényeit, további biztonsági intézkedéseket fejleszthet ki az alapok megerősítésére.

SSH (Secure Shell) kulcsok

Miközben a szerverével dolgozik, az ideje nagy részét egy terminálmunkamenetben, a szerverével való SSH-kapcsolatban fogja tölteni. A biztonsági héj (SSH) kulcsok biztonságosabb bejelentkezési módot nyújtanak a szerverre, mint a jelszavakon alapuló bejelentkezések. Hitelesítés céljából, az SSH-kulcsok használatával két hozzáférési kulcs készül. Az első egy titkos (privát) kulcs, míg a másik egy megosztható, nyilvános kulcs.

Az SSH-kulcsos hitelesítést először konfigurálni kell. Ez úgy történik, hogy az SSH nyilvános kulcsot a szerver megfelelő könyvtárába helyezzük. Amikor az ügyfél (kliens) először csatlakozik a szerverhez, igazolnia kell a privát kulcs birtoklását. Ez egy véletlenszerű érték generálásával történik, amelyet a rendszer elküld az SSH-kliensnek. Az SSH-kliens ezután a privát kulcsot használja a válasz titkosításához. Ezt a választ elküldi a szervernek. Ezután a szerver a nyilvános kulcs segítségével visszafejti a klienstől érkező üzenetet. Ha a szerver sikeresen visszafejti a véletlenszerű értéket, az azt jelzi, hogy a kliens rendelkezik a privát kulccsal. Ebben az esetben a hitelesítés megerősítést nyer, és létrejöhet a jelszó nélküli kapcsolat a szerverrel.

A biztonság fokozása SSH-kulcsokkal

Bár a jelszavas engedélyezés vagy bármilyen SSH-val történő hitelesítés teljesen titkosított, rosszindulatú felhasználók megkísérelhetik a szerverhez való hozzáférést. Különösen akkor, ha birtokukba jutott a szerver nyilvános IP-címe. Az összes lehetséges kulcskombináció kipróbálásával a modern számítástechnika lehetővé teszi a jelszóalapú bejelentkezések feltörését, és ezt a rosszindulatú felhasználók gyakran meg is kísérlik. Ha valaki automatizálná ezeket a hozzáférési kísérleteket, a különböző kombinációk szisztematikus kipróbálásával végül elérhetné a helyes jelszót.

Az SSH titkosított hitelesítés kihasználásával nincs szükség a jelszavas bejelentkezés engedélyezésére. Az SSH-kulcsok általában olyan hatalmas számú kombinációs lehetőséget tartalmaznak, amelyet egy támadónak végig kellene próbálnia. A megnövelt bitek száma megsokszorozza a titkosítás feltöréséhez szükséges különböző kombinációk lehetőségét. Az SSH-kulcs algoritmus összes lehetséges kombinációjának végigfuttatása ezért rendkívül időigényes lenne. Így ez egy olyan vállalkozássá válik, amely nem éri meg a rosszindulatú támadó idejét. Ezért tekintik az SSH-titkosítást általában „feltörhetetlennek”.

Az SSH-kulcsok bevezetése

Bármely távoli Linux szerverre való bejelentkezéshez SSH-kulcsokat kell használni. A helyi gépen legenerálható a kulcspár, és a nyilvános kulcs percek alatt átvihető a szerverre. Ebből az útmutatóból alapvető képet kaphat arról, hogy hogyan használható az SSH a távoli szerverhez való csatlakozáshoz Ubuntu alatt. Emellett követheti a részletes útmutatónkat arról, hogyan konfigurálhatja Linux szerverét az SSH-kulcs alapú hitelesítés használatára.

Összességében a root felhasználó közvetlen SSH-n keresztüli bejelentkezésének megtiltása egy általánosan alkalmazott bevált gyakorlat, míg a bejelentkezés nem privilegizált felhasználóként történik, és szükség esetén egy olyan eszköz használatával, mint a sudo, a jogosultságok kiterjesztésére. Ez a legkisebb jogosultság elveként ismert: a hozzáférési jogosultságok korlátozásának egy módszere. Miután a nem privilegizált fiókkal való bejelentkezést ellenőriztük SSH-val, a root bejelentkezések letilthatók a PermitRootLogin no direktíva beállításával a szerver /etc/ssh/sshd_config fájljában. Ezután a szerver újraindítható a sudo systemctl restart sshd SSH folyamat paranccsal.

Tűzfalak

Azt a szoftvert (vagy hardvereszközt), amely szabályozza a szolgáltatások hálózati kitettségét, tűzfalnak nevezzük. Egy optimálisan konfigurált tűzfal biztosítja, hogy csak az engedélyezett szolgáltatások legyenek nyilvánosan elérhetők, és engedélyezettek az adott szerverre be- és onnan kimenő irányban.

Alapértelmezés szerint több szolgáltatás is futhat egy szerveren, és ezek a következő csoportokba sorolhatók:

• Belső szolgáltatások: Ezeket csak belsőleg, magáról a szerverről szabad elérni. Ez megakadályozza a szolgáltatások kitettségét a nyilvánosan elérhető internetes hozzáférésnek (pl. egy csak helyi kapcsolatokon keresztül elérhető adatbázis).
• Nyilvános szolgáltatások: Olyan szolgáltatások, amelyeket bárki elérhet, gyakran névtelenül, az interneten. Ide tartoznak a webszerverek, amelyek lehetővé teszik, hogy a látogatók elérjék az Ön webhelyét.
• Privát szolgáltatások: Csak a helyszínek egy kizárólagos csoportjából származó felhatalmazott fiókok érhetik el ezeket a szolgáltatásokat (pl. phpMyAdmin adatbázis-kezelő panel).

Míg a nyilvános szolgáltatások elérhetők maradhatnak az internetről, a privát szolgáltatások korlátozhatók a hozzáférési paraméterek (például a kapcsolattípusok) alapján, a belső szolgáltatások pedig teljesen el vannak zárva minden internetes hozzáféréstől. Ezen szolgáltatások elérését, valamint az engedélyezés részletességét mind a tűzfal szabályozza. A használaton kívüli portokat általában úgy konfigurálják, hogy teljesen blokkolják a hozzájuk való hozzáférést.

Biztonság fokozása tűzfal használatával

A tűzfal a szervervédelem alapköve. Arra szolgál, hogy korlátozza a szolgáltatásokhoz való és onnan induló kapcsolatokat, mielőtt az alkalmazás kezelné a forgalmat. Természetesen további biztonsági funkciókat is bevezethet a szolgáltatásaihoz, és korlátozhatja azokat a kívánt interfészekre.

Csak azokat a szolgáltatásokat nem fogja korlátozni egy megfelelően konfigurált tűzfal, amelyeket Ön nyitva kíván hagyni. Ez korlátozza a sebezhető elemeket, mivel a rendelkezésre álló szoftverek köre sokkal korlátozottabb, és ezért kisebb a valószínűsége egy támadásnak.

Tűzfalak bevezetése

Számos tűzfal áll rendelkezésre Linux rendszerekhez. Ezek közül néhány meglehetősen összetett. A tűzfal tipikus beállítását azonban általában csak a szerver kezdeti beállításakor kell elvégezni, amikor a szerver szolgáltatásaiban változtatások történnek. Ez mindössze néhány percet vesz igénybe. Az alábbiakban bemutatunk néhány lehetőséget, amelyeket érdemes megfontolni a tűzfal beállításához és aktiválásához:

• CentOS esetén követheti a Tűzfal beállítása FirewallD segítségével CentOS 7 rendszeren útmutatónkat.
• Az Iptables útmutatónk végigvezeti Önt az Iptables tűzfalszabályok listázásán és törlésén.

A legfontosabb, hogy az útmutatótól függetlenül biztosítania kell, hogy a választott tűzfal blokkolja az ismeretlen forgalmat a szervereiről, megakadályozva ezzel, hogy az újonnan elérhető szolgáltatások véletlenül ki legyenek téve az internetnek. A hozzáférés kifejezett engedélyezésének szükségessége arra készteti Önt, hogy teljes mértékben értékelje a szolgáltatások elérésének és futtatásának módját, valamint azt, hogy ki férhet hozzájuk.

Virtuális magánfelhő (VPC) hálózatok

Az Ön infrastruktúrájának’ erőforrásainak egy olyan privát hálózaton belül kell működniük, amelyet VPC-ként ismernek. Ezek a hálózatok biztonságosabbak, mivel megakadályozzák a hozzáférést más felhőalapú VPC-hálózatokból. Így a hálózat interfészeit elérhetetlenné teszik a nyilvános internetről.

A biztonság fokozása VPC-hálózatokkal

A belső kommunikációhoz a magánhálózatok előnyösebbek, mint a nyilvános hálózati megfelelők. A VPC lehetővé teszi az erőforráscsoportok elkülönítését meghatározott magánhálózatokba. Mivel a VPC-hálózatok csak magánkapcsolatokon keresztül érintkeznek egymással, a hálózat forgalma védve van a nyilvános internetnek való kitettségtől, ahol ezek az információk sebezhetőek lennének a lehallgatással vagy a kiszivárgással szemben. A VPC-hálózatok a végrehajtási környezetek, valamint a bérlők elkülönítésére is használhatók. Az internetes átjárók egyetlen hozzáférési pontként is beállíthatók a nyilvános internet és a VPC-hálózaton lévő erőforrások között.

Emellett a biztonság nagy része a rendszereink elemzését és az összes összetevő képességeink szerinti legjobb biztosítását foglalja magában. A szolgáltatásaudit lehetővé teszi számunkra, hogy megismerjük a rendszerek elfogadható protokolljait, a futó szolgáltatásokat és azt, hogy mely portokat használják a kommunikációhoz. Ezen információk ismerete segíthet a legjobb döntések meghozatalában a konfigurációt illetően. Ilyen döntések lehetnek a tűzfalbeállítások, a rendszerfelügyelet és a riasztások, valamint az, hogy mely szolgáltatásoknak kell nyilvánosan elérhetőnek lenniük.

Az auditálás kihasználása a biztonság növelése érdekében

Mindegyik szolgáltatás használható külső ügyfelek kiszolgálására vagy belső célokra. A szándéktól függetlenül ezek a szolgáltatások mind sebezhetőségi pontot jelentenek a rosszindulatú felhasználók számára. Ahogy a futó szolgáltatások száma növekszik, úgy nő a sebezhetőségek kihasználásának lehetősége is.

Miután pontosan tisztában van azzal, hogy egy gép milyen szolgáltatásokat futtat, elkezdheti a szolgáltatások elemzését. A szolgáltatásaudit futtatásakor a következő kérdéseket érdemes feltenni:

• Aktívan kell futnia az adott szolgáltatásnak?
• A megfelelő hálózati interfészeken fut?
• A szolgáltatás nyilvános vagy magánhálózati interfészhez illik a legjobban?
• Helyesen vannak beállítva a tűzfalszabályok, hogy engedélyezzék a jogos forgalmat ehhez a szolgáltatáshoz?
• Blokkolva van a jogosulatlan forgalom a tűzfalszabályaimmal?
• Be van kapcsolva a biztonsági sebezhetőségekre figyelmeztető riasztási rendszer?

Amikor új szervert ad hozzá az infrastruktúrához, a fentieknek alapvető gyakorlatnak kell lenniük a konfigurációs folyamat során. A szolgáltatásauditok további előnye, hogy lehetővé teszik a nem szándékosan megváltozott konfigurációk azonosítását.

Szolgáltatásauditok végrehajtása

A futó szolgáltatások auditálásához használja az ss parancsot, hogy kilistázza az összes UDP- és TCP-portot, amelyet aktívan használnak egy szerveren. Íme egy példa az ss parancs használatára egy PID programnévvel, amely a hallgatózó TCP- és UDP-portokat ellenőrzi:

A következőhöz hasonló eredményt fog kapni:

Elsősorban a Netid, a Local Address:Port és a Process oszlopokra kell összpontosítania:

• Ha a Local Address:Port értéke 0.0.0.0, az azt jelenti, hogy a szolgáltatás aktívan fogad minden kapcsolatot az összes IPv4 hálózati interfészen. Ha a cím [::], akkor az összes IPv6-kapcsolat fogadja a forgalmat.
• A fenti példában mind az Nginx, mind az SSH az összes nyilvános interfészen hallgatózik mindkét hálózati protokollcsaládon (IPv4 és IPv6).

A fenti példa alapján eldöntheti, hogy engedélyezni szeretné-e az SSH és az Nginx számára a mindkét interfészen való hallgatózást, vagy csak az egyikükön. Általában érdemes letiltani minden használaton kívüli szolgáltatást, hogy megakadályozza a futásukat. Ha például a webhelyének csak IPv4-en keresztül kell elérhetőnek lennie, a kitettség korlátozása érdekében érdemes kikapcsolni az IPv6-interfészeket.

Naprakészen tartás felügyelet nélküli frissítésekkel

A felügyelet nélküli frissítések csökkentik a szerverek biztonságának megőrzéséhez szükséges erőfeszítéseket, és segítenek lerövidíteni azt az időt, amíg a szerverek ki vannak téve az ismert hibáknak. Minél tovább tart a frissítések futtatása a szerveren, annál tovább marad kitéve az ismert sebezhetőségeknek. A felügyelet nélküli frissítések biztosítják, hogy amint a javítócsomagok elérhetővé válnak, azok automatikusan települjenek a szerverre, korlátozva a sebezhetőség időtartamát.

A szerverauditálás mellett a felügyelet nélküli frissítések jelentősen csökkenthetik a támadásoknak való kitettséget. Emellett nagymértékben csökkentik a szerverkarbantartásra fordított időt is.

Hogyan aktiválhatók a felügyelet nélküli frissítések

A felügyelet nélküli frissítések ma már opcionális funkcióként érhetők el a legtöbb szerverdisztribúción. Ubuntun például a rendszergazda a következő parancsot futtathatja:

A felügyelet nélküli frissítések bevezetésével kapcsolatos további információkért tekintse meg az Automatikus frissítések részt itt. A Fedora esetében az útmutató itt található. Kérjük, vegye figyelembe, hogy az automatikus frissítések csak azokat a szoftvereket telepítik, amelyeket eredetileg a rendszer csomagkezelő rendszerén keresztül telepítettek. Minden kiegészítő alkalmazást, például a webes alapúakat, külön kell manuálisan ellenőrizni a frissítések szempontjából, vagy egyedileg kell beállítani az automatikus frissítésekhez.

Könyvtárindexek

Ha egy könyvtárból hiányzik az indexfájl, a legtöbb szerver alapértelmezés szerint úgy van beállítva, hogy megjelenítse a könyvtárindexeket. Más szóval, ha a webszerverén létrejött egy „downloads” nevű könyvtár, akkor bárki, aki ezt a könyvtárat böngészi, láthatja a benne lévő összes fájlt. Bár ez nem mindig jelent biztonsági kockázatot, a bizalmas információkat láthatóvá teszi az illetéktelenek számára. Példaként gondoljon arra, hogy a webszerverén lehet egy fájl, amely a webhely kezdőlapjának hozzáférési adatait tartalmazza, és egy fájl a webhely adatbázisának háttérrendszeréhez tartozó összes konfigurációval. Ha a könyvtárindexek nincsenek letiltva, ezeket a fájlokat bárki láthatja, aki az adott könyvtárat böngészi.

A biztonság növelése a könyvtárindexek letiltásával

Bár a könyvtárindexek hasznosak, akaratlanul is kiszolgáltatottá tehetik a fájlokat. Az ilyen akaratlan kitettség és a kapcsolódó kockázatok mérséklése érdekében a szerveren lévő könyvtárindexeket alapértelmezés szerint le kell tiltani. Bár a látogatók továbbra is elérhetik a fájlokat, a nem szándékos adatmegtekintés lehetősége jelentősen korlátozott.

Könyvtárindexek letiltása

A legtöbb esetben a webszerver konfigurációjának egyetlen sorral történő kiegészítése elegendő a könyvtárindexek letiltásához.

• Kövesse ezeket a lépéseket a könyvtárlisták letiltásához az Apache Wikin. Győződjön meg arról, hogy az Options -Indexes szerepel az Apache Directory konfigurációs blokkjaiban.
• Az Nginx esetében az indexek alapértelmezés szerint le vannak tiltva, így ezzel kapcsolatban nincs szükség további lépésekre.

Gyakori biztonsági mentések

Bár a biztonsági mentések nem jelentenek közvetlen biztonsági intézkedést, elengedhetetlenek az adatok és a teljes rendszerek védelméhez a rendszer kompromittálódása esetén. Segít annak elemzésében is, hogyan kerülhetett sor a rendszer elleni támadásra. Gondoljon egy olyan sajnálatos forgatókönyvre, amikor a rendszert zsarolóvírus (ransomware – egy olyan vírus vagy rosszindulatú program, amely titkosítja a rendszeren lévő fájlokat, és csak akkor oldja fel a titkosítást, ha pénzt fizet a hackernek) támadja meg. Ha nincsenek biztonsági mentések az adatokról, az egyetlen választása az, hogy kifizeti a pénzt, hogy visszakapja a hozzáférést az adataihoz. Ha az adatokról biztonságos mentés áll rendelkezésre, továbbra is hozzáférhet azokhoz, és helyreállíthatja az adatokat anélkül, hogy hozzá kellene férnie a kompromittált rendszerhez.

Biztonság növelése gyakori biztonsági mentésekkel

A gyakori biztonsági mentések segítenek visszaszerezni az információkat támadás, sérülés vagy akár akaratlan adatvesztés (törlés) esetén. Függetlenül attól, hogy milyen típusú negatív esemény vezet az adatvesztéshez, a kockázatot csökkenti a szerveradatok másolatainak megőrzése.

A zsarolóvírus-támadásokon kívül a gyakori biztonsági mentések segíthetnek a hosszú távú rendszertámadások mérhető kivizsgálásában is. Ha nem tárolja biztonságosan az adatait mentett formában, a támadás forrásának és a kompromittált adatok körének meghatározása nehéz vagy akár lehetetlen is lehet.

Gyakori biztonsági mentések megvalósítása

Rendszerei biztonsági mentésekor kiemelten fontos, hogy a helyreállítási erőfeszítések céljaként a sérült, kompromittált vagy törölt adatok ellenőrizhető helyreállítását tekintse. A legjobb megközelítés érdekében gondolja át, milyen lépések igényelnének a legkevesebb munkát ahhoz, hogy újra működőképes legyen, ha a szervere holnap eltűnne.

Íme néhány további szempont, amelyet érdemes figyelembe venni a katasztrófa utáni helyreállítási terv kidolgozásakor:

• Ha dinamikusan változó adatokkal dolgozik, a biztonsági mentéseknek valószínűleg gyakoribbaknak kell lenniük. Adatvesztés esetén, ha a legutóbbi mentés túl régen történt, előfordulhat, hogy kénytelen lesz visszatérni az elavult adatokhoz.
• Gondoljon a tényleges biztonsági mentés-helyreállítási folyamatra. Új szervert kell hozzáadni ehhez, vagy a meglévő is helyreállítható?
• Mi a leghosszabb időtartam, ameddig a szerver nem működhet?
• Szükséges megoldás a telephelyen kívüli (offsite) biztonsági mentés?

Ha többet szeretne megtudni a CloudSigma katasztrófa utáni helyreállítási (Disaster Recovery) megoldásairól, olvassa el blogbejegyzésünket, amely részletesen bemutatja, miért a mi katasztrófa utáni helyreállítás mint szolgáltatásunk (Disaster-Recovery-as-a-Service) a tökéletes társ a felhőhöz. Itt pedig többet tudhat meg a CloudSigma biztonsági & üzletmenet-folytonossági funkcióiról. Van egy részletes útmutatónk is arról, hogyan állítható be egyszerűen a CloudSigma biztonsági mentési funkciója.

Magánhálózatok és VPN-ek

A magánhálózat olyan hálózat, amelyhez csak bizonyos felhasználók vagy szerverek férhetnek hozzá és használhatják azt. A távoli eszközök közötti biztonságos kapcsolat, amely lehetővé teszi, hogy a kapcsolat úgy működjön, mintha magánhálózatban lenne, egy VPN (virtuális magánhálózat). Lehetővé teszi a kapcsolatok biztosítását egy magánhálózatban, valamint a távoli szerverek összekapcsolását.

Hogyan növelik a biztonságot a magánhálózatok?

Ha belső kommunikációra nyilvános vagy magánhálózat használata között lehet választani, az utóbbi mindig a preferált opció. Tartsa szem előtt azonban, hogy az adatközponton belüli többi felhasználó továbbra is hozzáférhet ugyanahhoz a hálózathoz. Ez azt jelenti, hogy további biztonsági intézkedéseket kell alkalmazni a szerverek közötti biztonságos kommunikáció garantálása érdekében.

Lényegében a VPN használata egy módszer arra, hogy korlátozza, mit láthatnak a szervezet munkatársai. A levelezés teljesen biztonságos és privát lesz. Az alkalmazáskonfigurációk lehetővé tennék a virtuális interfész forgalmának átirányítását a VPN-en keresztül. Ezáltal csak azokat a szolgáltatásokat tesszük elérhetővé a nyilvános hálózaton, amelyeket az interneten keresztüli ügyfél-interakcióra szántak.

Mennyire nehéz a VPN bevezetése?

A magánhálózatok kihasználása az adatközpontban ugyanolyan egyszerű, mint az alkalmazások és a tűzfal beállítása a magánhálózat használatára, valamint a VPN engedélyezése a szerver létrehozása során. Fontos észben tartani, hogy más szerverek is osztoznak ugyanazon a hálózati téren, mint az adatközpont-szintű magánhálózatok.

A VPN kezdeti beállítása valamivel bonyolultabb. Az általa nyújtott plusz biztonság azonban a legtöbb felhasználási esetnél megéri a fáradságot. A konfigurációs adatokat és a megosztott biztonsági beállításokat a hálózat minden egyes szerverén telepíteni és konfigurálni kell. További részletes információkért arról, hogyan működik a VPN, valamint az OpenVPN Ubuntu-n történő beállításának áttekintéséért kövesse ezt az útmutatót. Követheti ezt az oktatóanyagot is, amely végigvezeti Önt a VPN-hálózat CloudSigma infrastruktúrájához való csatlakoztatásának lépésein.

SSL/TLS titkosítás és nyilvános kulcsú infrastruktúra (PKI)

A tanúsítványok generálását, kezelését és érvényesítését a személyek azonosítására és a kommunikáció titkosítására nyilvános kulcsú infrastruktúrának (PKI) nevezzük. A különböző entitások hitelesíthetik egymást SSL vagy TLS tanúsítványok használatával. Ezt követően titkosított kommunikáció kialakítására is használhatók.

Hogyan növelik a biztonságot a tanúsítványok?

A forgalom titkosításához és a tagok azonosságának ellenőrzéséhez a szerveren elengedhetetlen egy tanúsítványkiadó (CA) létrehozása, valamint a hálózat összes tanúsítványának átláthatósága. Ez segíthet megelőzni a „közbeékelődéses” (man-in-the-middle) támadásokat, amelyek során egy hacker utánozza a szervert, és a forgalmat máshová irányítja át.

Az egyes szerverek konfigurációja beállítható úgy, hogy bízzon egy központosított CA-ban. Így minden későbbi tanúsítvány-aláírásban implicit módon megbízhat. Ha a szerver által használt protokollok és alkalmazások támogatják az SSL/TLS titkosítást, akkor a rendszert a VPN-alagút többletterhelése nélkül is biztonságossá teheti. További információért kövesse a LetsEncrypt SSL tanúsítványok megújításának automatizálásáról szóló útmutatónkat Nginx-hez.

A megvalósítás nehézsége

Egy tanúsítványkiadó konfigurálása, majd a többi PKI beállítása kezdetben sok erőfeszítést igényelhet. Ezenkívül, amikor új tanúsítványokat kell létrehozni, visszavonni vagy aláírni, további adminisztrációs erőfeszítésekre lesz szükség.

Mivel a legtöbb infrastruktúrának növekednie kell, egy teljes értékű PKO bevezetése a legésszerűbb megközelítés. Amíg el nem ér egy olyan pontot, ahol a PKI megéri a többlet adminisztrációs költségeket, a rendszer összetevőinek biztosítására szolgáló VPN használata megfelelő átmeneti megoldásként szolgálhat.

Rendszerbehatolás észlelése és fájlellenőrzés alkalmazása

A fájlellenőrzés (file auditing) egy olyan folyamat, amellyel a rendszer teljesen biztonságos, jó állapotban lévő fájljait és azok attribútumait hasonlítják össze a rendszer jelenlegi állapotával. Ez egy jó módszer a jogosulatlan rendszermódosítások megtalálására és elszigetelésére.

Az IDS, behatolásjelző rendszer, olyan megfigyelő szoftverre utal, amely nyomon követi a rendszeren belüli minden jogosulatlan tevékenységet. Általában fájlellenőrzési módszereket használ a váratlan rendszermódosítások felkutatására.

A biztonság fokozása IDS/fájlellenőrzés segítségével

A szolgáltatásszintű ellenőrzésen túl a fájlszintű ellenőrzések elvégzése is elengedhetetlen a rendszer biztonságának szavatolásához. Ezt megteheti egy automatizált IDS-folyamat, vagy időszakosan elvégezheti a rendszergazda is.

A fájlellenőrzések és az IDS az egyetlen valódi folyamatok annak biztosítására, hogy a rendszerben ne történjenek váratlan változtatások. A legtöbb behatoló hosszabb ideig szeretné kihasználni az általa megszállt szervereket, és ehhez meg kell őriznie a képességét arra, hogy tevékenysége rejtve maradjon. Kicserélhetik a bináris fájlokat sebezhető vagy kompromittált verziókra. A rendszerben módosított fájlokat a fájlrendszer-ellenőrzés észleli. Ez megadja azt a megnyugvást, hogy nagyon gyorsan megtudhatja, ha a rendszer integritása sérült.

Megvalósítási nehézségi szint

Az IDS és a fájlellenőrzés bevezetése igen intenzív folyamat lehet. Kezdetben a rendszert úgy kell konfigurálni, hogy meghatározzuk a kizárandó útvonalakat, és rögzítsük a rendszeren végrehajtott nem szabványos módosításokat, hogy létrehozzuk a rendszer alapállapotát.

A mindennapi működés is nehézkesebbé válik, mivel az eljárásoknak újra ellenőrizniük kell a rendszert a frissítések futtatása előtt. A rendszermérések alapállapotát is újra létre kell hozni vagy újra meg kell határozni, hogy a szoftververziók változásai bekerüljenek a rendszer új alapállapotába. Az ellenőrzési jelentéseket egy másik helyre is át kell vinni. Ez azért van, mert meg kell akadályoznia, hogy a rendszerbe behatoló módosítsa az ellenőrzési naplót, hogy nyomai eltakarásával rejtve maradjon.

Bár ez kétségtelenül növeli a rendszer adminisztrációs terheit, ez az egyik egyetlen biztos módszer arra, hogy megbizonyosodjon arról, hogy a fájlok egyike sem módosult az Ön tudta nélkül. A legnépszerűbb behatolásjelző és fájlellenőrző rendszerek közé tartozik az Aide és a Tripwire.

Izolált környezetek

Minden olyan módszert, ahol az egyes összetevők saját, dedikált helyükön futnak, izolált végrehajtási környezetnek nevezünk.

Ez jelentheti azt, hogy bizonyos alkalmazás-összetevők saját dedikált szervereken kapnak helyet, vagy hogy a szolgáltatások chroot környezetben (vagy konténerekben) való működésre vannak konfigurálva. A környezet izoláltságának mértéke leginkább az infrastruktúra adottságaitól és az alkalmazás követelményeitől függ.

A biztonság fokozása izolált környezetekkel

A folyamatok egyedi környezetekbe történő izolálásával azt is korlátozza, hogy a biztonsági rések mely folyamatokat érinthetik. Ahogyan a rekeszek és a vízzáró falak segítenek megfékezni a hajótest sérüléseit a hajókon, úgy a rendszer egyes részeinek és összetevőinek elkülönítésével, ha egy behatoló hozzáférést is szerez az egyikhez, nem tud bejutni a teljes összekapcsolt hálózati rendszerbe.

A megvalósítás nehézsége

Az alkalmazások izolálásának bonyolultsága a használni kívánt konténerizációs típusoktól függően változik. A Docker az izolációt nem tekinti biztonsági funkciónak. Ha azonban az összetevők különböző konténerekre vannak felosztva, az izoláció sokkal könnyebben megvalósítható. Követheti ezt a útmutatót a Docker infrastruktúránkra történő telepítéséhez.

A chroot környezetek beállításakor bizonyos fokú izoláció is biztosított. Ez azonban nem egy teljesen áthatolhatatlan módszer, mivel léteznek módszerek az ilyen környezetből való kitörésre. A különböző összetevők számára fenntartott dedikált gépek általában a legjobb és legegyszerűbb módjai az izoláció elérésének. Ez azonban költségesebb a további gépek szükségessége miatt.

Záró gondolatok

A bemutatott stratégiák csak néhány lépést jelentenek a rendszer biztonságának növelése érdekében. Érdemes megjegyezni, hogy minél tovább vár a biztonsági funkciók bevezetésével, annál kisebb lesz a hatékonyságuk. Ezt szem előtt tartva fontos biztosítani, hogy a biztonsággal ne várjunk. Ehelyett az infrastruktúra kiépítésének egyik első lépéseként kell megvalósítani. Amint a rendszer az alapvető védelmi intézkedésekkel kellően biztonságossá vált, elkezdheti a szolgáltatások aktiválását és az alkalmazások hozzáadását, tudva, hogy azok alapértelmezetten biztonságos környezetben futnak.

A biztonság azonban nem egy statikus folyamat, hanem egy folyamatosan változó. Karban kell tartani és ismételni kell. A folyamatos tudatosság és a lankadatlan éberség mentalitásával kell megközelíteni. Mindig kérdőjelezze meg, hogy milyen biztonsági következményekkel jár bármilyen rendszerváltoztatás.  Győződjön meg arról, hogy a működési környezetek és az alapértelmezett konfigurációk mindig optimalizálják a biztonságot, és kellően védelmi szoftverekkel működnek.

Kellemes számítástechnikát!