Kako izgraditi robusne sigurnosne mjere za zaštitu svojih poslužitelja

Uvod

Kada radite na oblačnoj infrastrukturi, vaša primarna briga je osigurati da su vaše aplikacije u potpunosti operativne. Jedna važna stavka vašeg procesa postavljanja i implementacije je ugradnja učinkovitih, temeljitih i robusnih sigurnosnih mjera u vaše aplikacije ili sustave prije nego što se ponude javnosti. Umjesto retroaktivnog provođenja sigurnosnih mjera nakon implementacije, važno je osigurati da u vašu infrastrukturu bude ugrađena sigurna osnovna konfiguracija.

Ovaj vodič će vam pomoći u tom pogledu. Istaknut će određene praktične sigurnosne mjere koje se mogu primijeniti dok se infrastruktura vašeg poslužitelja postavlja i konfigurira. Iako ovo nije iscrpan popis sigurnosnih protokola poslužitelja, korisna je polazna točka. Kako budete radili i bolje razumjeli specifične potrebe svog okruženja i aplikacija, možete razviti dodatne sigurnosne mjere koje će vam pomoći u nadogradnji vaše baze.

SSH (Secure Shell) ključevi

Dok radite sa svojim poslužiteljem, veliku većinu vremena provest ćete radeći u SSH vezi s vašim poslužiteljem u terminalskoj sesiji. Sigurnosni ključevi ljuske (SSH) pružaju sigurniju metodu prijave na poslužitelj od prijava koje se oslanjaju na lozinke. Za potrebe autentifikacije, uz korištenje SSH ključeva, pripremaju se dva pristupna ključa. Prvi je tajni (privatni) ključ, dok je drugi javni ključ koji se može dijeliti.

Autentifikacija SSH ključem mora se najprije konfigurirati. To se postiže postavljanjem javnog SSH ključa u odgovarajući direktorij na poslužitelju. Kada se vaš klijent inicijalno poveže s poslužiteljem, od vas će se tražiti dokaz o posjedovanju privatnog ključa. To se radi generiranjem nasumične vrijednosti koja se zatim šalje vašem SSH klijentu. SSH klijent će zauzvrat koristiti privatni ključ za šifriranje odgovora. Taj će odgovor biti poslan poslužitelju. Zatim će poslužitelj dešifrirati poruku od klijenta pomoću vašeg javnog ključa. Ako poslužitelj dešifrira nasumičnu vrijednost, to znači da klijent ima privatni ključ. U tom slučaju autentifikacija je potvrđena i može se uspostaviti veza s poslužiteljem bez lozinke.

Poboljšanje sigurnosti pomoću SSH ključeva

Iako je autorizacija lozinkom ili bilo koja autentifikacija putem SSH-a potpuno šifrirana, zlonamjerni korisnici mogu pokušati pristupiti poslužitelju. Pogotovo ako su došli u posjed javne IP adrese poslužitelja. Isprobavanjem svake moguće kombinacije tipki, moderno računalstvo dopušta prijave temeljene na lozinki, što zlonamjerni korisnici često pokušavaju. Ako bi se ti pokušaji pristupa automatizirali, sustavnim isprobavanjem različitih kombinacija moguće je konačno doći do točne lozinke.

Korištenjem SSH šifrirane autentifikacije, nema potrebe za omogućavanjem lozinki za prijavu. SSH ključevi obično sadrže ogroman broj mogućih kombinacija koje bi napadač morao isprobati. Povećani broj bitova višestruko povećava potencijal za različite kombinacije potrebne za probijanje šifriranja. Prolazak kroz sve moguće kombinacije algoritma SSH ključa stoga bi oduzeo iznimno puno vremena. Zbog toga to postaje pothvat koji nije vrijedan vremena zlonamjernog napadača. Zato se SSH šifriranje obično smatra 'neprobojnim'.

Implementacija SSH ključeva

Za prijavu na bilo koji udaljeni Linux poslužitelj trebali bi se koristiti SSH ključevi. Na lokalnom računalu može se generirati par ključeva, a javni ključ se prenosi na poslužitelj u roku od nekoliko minuta. Uz ovaj vodič dobit ćete osnovnu predodžbu o tome kako koristiti SSH za povezivanje s udaljenim poslužiteljem u Ubuntuu. Također možete pratiti naš detaljni vodič o tome kako konfigurirati svoj Linux poslužitelj za korištenje autentifikacije temeljene na SSH ključu.

Općenito, onemogućavanje izravne prijave root korisnika putem SSH-a uobičajena je najbolja praksa, dok se prijava vrši kao nepovlašteni korisnik uz korištenje alata kao što je sudo za povećanje privilegija prema potrebi. To je poznato kao načelo najmanjih privilegija: metoda ograničavanja prava pristupa. Nakon što se prijava s nepovlaštenim računom verificira putem SSH-a, prijave root korisnika mogu se onemogućiti postavljanjem direktive PermitRootLogin no u /etc/ssh/sshd_config na vašem poslužitelju. Zatim se poslužitelj može ponovno pokrenuti naredbom SSH procesa sudo systemctl restart sshd.

Vatrozidi

Softver (ili hardverski uređaj) koji regulira izloženost usluga mreži poznat je kao vatrozid. Optimalno konfiguriran vatrozid osigurava da su samo dopuštene usluge javno dostupne te dopuštene za ulaz i izlaz iz određenog poslužitelja.

Nekoliko usluga može se prema zadanim postavkama izvoditi na poslužitelju i one se mogu kategorizirati u sljedeće skupine:

• Interne usluge: Njima bi se trebalo pristupati samo interno sa samog poslužitelja. To sprječava izlaganje usluga javno dostupnom internetu (npr. baza podataka dostupna samo putem lokalnih veza).
• Javne usluge: Usluge kojima svatko može pristupiti, često anonimno, na internetu. To uključuje web poslužitelje koji posjetiteljima omogućuju pristup vašoj web stranici.
• Privatne usluge: Samo ovlašteni računi s ekskluzivnog skupa lokacija mogu pristupiti ovim uslugama (npr. upravljačka ploča baze podataka phpMyAdmin).

Dok javne usluge mogu ostati dostupne za pristup s interneta, privatne usluge mogu se ograničiti na temelju parametara pristupa (kao što su vrste veza), a internim uslugama u potpunosti se onemogućuje bilo kakav pristup putem interneta. Pristup tim uslugama, zajedno s detaljnošću s kojom je dopušten, u potpunosti kontrolira vatrozid. Neiskorišteni priključci obično su konfigurirani tako da u potpunosti blokiraju pristup njima.

Poboljšanje sigurnosti upotrebom vatrozida

Vatrozid je osnova za zaštitu poslužitelja. Služi za ograničavanje veze prema uslugama i od njih prije nego što aplikacija obradi promet. Naravno, možete implementirati dodatne sigurnosne značajke za svoje usluge i ograničiti ih na željena sučelja.

Pravilno konfiguriran vatrozid neće ograničiti samo one usluge za koje odlučite da ostanu otvorene. To ograničava elemente osjetljive na iskorištavanje jer su dostupni dijelovi softvera znatno ograničeniji, pa je stoga manja vjerojatnost da će doživjeti napad.

Implementacija vatrozida

Mnogi vatrozidi dostupni su za Linux sustave. Neki od njih prilično su složeni. Međutim, tipično postavljanje vatrozida trebalo bi se obaviti samo u vrijeme početnog postavljanja poslužitelja kada se implementiraju promjene na uslugama s poslužitelja. To bi vam trebalo oduzeti samo nekoliko minuta vremena. Slijede neke opcije koje treba razmotriti za postavljanje i aktivaciju vatrozida:

• Za CentOS možete pratiti naš vodič za postavljanje vatrozida s FirewallD-om na CentOS-u 7.
• Naš vodič za Iptables može vas provesti kroz izlistavanje i brisanje pravila vatrozida Iptables.

Što je najvažnije, bez obzira na vodič, morate osigurati da odabrani vatrozid blokira nepoznati promet s vaših poslužitelja kako biste spriječili da se bilo koje novodostupne usluge nenamjerno izlože internetu. Zbog potrebe za izričitim odobravanjem pristupa, od vas će se tražiti da u potpunosti procijenite kako se usluzi pristupa, kako se izvodi i tko joj smije pristupiti.

Mreže virtualnog privatnog oblaka (VPC)

Resursi vaše infrastrukture’ moraju raditi unutar privatne mreže poznate kao VPC. Ove su mreže sigurnije jer sprječavaju pristup iz drugih VPC mreža u oblaku. Na taj način čine mrežna sučelja nedostupnima s javnog interneta.

Poboljšanje sigurnosti pomoću VPC mreža

Privatne mreže imaju prednost pred javnim mrežnim pandanima za internu komunikaciju. VPC omogućuje izolaciju grupa resursa u određene privatne mreže. Budući da se VPC mreže povezuju samo putem privatnih veza, promet mreže zaštićen je od izlaganja javnom internetu, gdje bi te informacije mogle biti podložne presretanju ili otkrivanju. VPC mreže također se mogu koristiti za izolaciju izvršnih okruženja, kao i zakupaca. Internetski prolazi također se mogu postaviti kao jedinstvena točka pristupa između javnog interneta i resursa na vašoj VPC mreži.

Osim toga, veliki dio sigurnosti obuhvaća analizu naših sustava i osiguravanje svih komponenti najbolje što možemo. Revizija usluga omogućuje nam da saznamo prihvatljive protokole sustava, usluge koje se izvode i koji se portovi koriste za komunikaciju. Poznavanje ovih informacija može pomoći u donošenju najboljih odluka u vezi s konfiguracijom. Takve odluke mogu biti postavke vatrozida, nadzor sustava i upozorenja te koje bi usluge trebale biti javno dostupne.

Iskorištavanje revizije za poboljšanje sigurnosti

Svaka se usluga može koristiti za rad s vanjskim klijentima ili za interne svrhe. Bez obzira na namjeru, sve su te usluge točke ranjivosti za zlonamjerne korisnike. Kako se broj pokrenutih usluga povećava, tako raste i potencijal za iskorištavanje ranjivosti.

Možete započeti s analizom usluga nakon što dobro shvatite koje usluge računalo izvodi. Prilikom provođenja revizije usluga, korisno je postaviti sljedeća pitanja:

• Treba li određena usluga biti aktivno pokrenuta?
• Izvodi li se na optimalnim mrežnim sučeljima?
• Je li usluga najprikladnija za javno ili privatno mrežno sučelje?
• Jesu li pravila vatrozida ispravno konfigurirana kako bi se dopustio legitiman promet prema ovoj usluzi?
• Je li nelegitiman promet blokiran mojim pravilima vatrozida?
• Je li omogućen sustav upozorenja o sigurnosnim ranjivostima?

Prilikom dodavanja novog poslužitelja u infrastrukturu, gore navedeno bi trebale biti standardne prakse u njegovom konfiguracijskom procesu. Dodatna prednost revizije usluga je ta što će omogućiti prepoznavanje svih konfiguracija koje su se nenamjerno promijenile.

Provođenje revizije usluga

Kako biste revidirali pokrenute usluge, upotrijebite naredbu ss za popis svih UDP i TCP portova koji se aktivno koriste na poslužitelju. Evo primjera korištenja naredbe ss s nazivom programa PID, provjeravajući TCP i UDP portove koji slušaju:

Bit će vraćeno nešto slično sljedećem:

Vaš glavni fokus trebao bi biti na stupcima Netid, Local Address:Port i Process:

• Ako je vrijednost Local Address:Port 0.0.0.0, to znači da usluga aktivno prihvaća sve veze na svim IPv4 mrežnim sučeljima. Ako je adresa [::], tada sve IPv6 veze prihvaćaju promet.
• U gornjem primjeru, i Nginx i SSH slušaju na svim javnim sučeljima na oba mrežna stoga (IPv4 i IPv6).

Uz gornji primjer, možete odabrati trebate li dopustiti SSH-u i Nginxu da slušaju na oba sučelja ili samo na jednom od njih. Općenito, željeli biste onemogućiti sve usluge koje se ne koriste kako biste spriječili njihovo pokretanje. Na primjer, ako bi vaša web-lokacija trebala biti dostupna samo putem IPv4, pomoglo bi isključiti IPv6 sučelja kako bi se ograničila izloženost.

Održavanje ažurnosti pomoću automatskih ažuriranja bez nadzora

Automatska ažuriranja bez nadzora smanjuju razinu truda potrebnog za održavanje sigurnosti vaših poslužitelja i pomažu skratiti vrijeme tijekom kojeg ostaju izloženi poznatim pogreškama. Što vam više vremena treba da pokrenete ažuriranja na svom poslužitelju, to on duže ostaje izložen poznatim ranjivostima. Automatska ažuriranja bez nadzora osigurat će da se, čim paketi s ispravcima postanu dostupni, oni automatski instaliraju na poslužitelj kako bi se ograničilo vrijeme ranjivosti.

Uz reviziju poslužitelja, automatska ažuriranja bez nadzora mogu uvelike smanjiti izloženost napadima. Također će uvelike smanjiti vrijeme provedeno na održavanju poslužitelja.

Kako se aktiviraju nenadzirana ažuriranja

Nenadzirana ažuriranja sada su neobavezna značajka na većini distribucija poslužitelja. Na Ubuntuu, na primjer, administrator može pokrenuti sljedeću naredbu:

Za dodatne informacije o implementaciji nenadziranih ažuriranja, pogledajte odjeljak Automatska ažuriranja ovdje. Za Fedoru, upute se mogu pronaći ovdje. Imajte na umu da će automatska ažuriranja instalirati samo softver koji je izvorno instaliran putem vašeg sustava za upravljanje paketima. Sve dodatne aplikacije, poput onih temeljenih na webu, morat će se zasebno ručno provjeravati radi ažuriranja ili pojedinačno konfigurirati za automatska ažuriranja.

Indeksi direktorija

Kada direktoriju nedostaje indeksna datoteka, većina poslužitelja konfigurirana je tako da prema zadanim postavkama prikazuje indekse direktorija. Drugim riječima, ako je na vašem web poslužitelju stvoren direktorij pod nazivom 'downloads', svatko tko pregledava taj direktorij moći će vidjeti sve datoteke u njemu. Iako to nije uvijek sigurnosni rizik, povjerljive informacije čini vidljivima onima koji u njih ne bi trebali imati uvid. Kao primjer, uzmite u obzir da vaš web poslužitelj može imati datoteku koja sadrži vjerodajnice za pristup početnoj stranici vaše web stranice i datoteku sa svim konfiguracijama za pozadinski dio baze podataka web stranice. Ako indeksi direktorija nisu onemogućeni, te će datoteke vidjeti svatko tko pregledava taj direktorij.

Povećanje sigurnosti onemogućavanjem indeksa direktorija

Iako su indeksi direktorija korisni, mogu nenamjerno izložiti datoteke. Kako bi se ublažilo takvo nenamjerno izlaganje i svi povezani rizici, indeksi direktorija na poslužitelju trebali bi biti onemogućeni prema zadanim postavkama. Iako posjetitelji i dalje mogu doći do datoteka, izloženost nenamjernom pregledavanju podataka značajno je ograničena.

Onemogućavanje indeksa direktorija

U većini slučajeva, dodavanje samo još jednog retka u konfiguraciju vašeg web poslužitelja dovoljno je za onemogućavanje indeksa direktorija.

• Slijedite ove korake za onemogućavanje ovih popisa direktorija na Apache Wikiju. Provjerite je li Options -Indexes navedeno u konfiguracijskim blokovima Apache Directory.
• Indeksi su prema zadanim postavkama onemogućeni na Nginxu, pa u tom pogledu nisu potrebne daljnje radnje.

Česte sigurnosne kopije

Iako sigurnosne kopije nisu sigurnosna mjera, one su imperativ za zaštitu podataka i cijelih sustava u slučaju kompromitacije sustava. Također pomažu u analizi kako je sustav mogao biti napadnut. Zamislite nesretan scenarij u kojem je vaš sustav napadnut ucjenjivačkim softverom (ransomware - virus ili zlonamjerni softver koji šifrira datoteke na vašem sustavu, a dešifrira ih samo ako hakeru platite novac). Ako nema sigurnosnih kopija podataka, vaš jedini izbor je platiti novac kako biste ponovno dobili pristup svojim podacima. Ako su podaci sigurno sigurnosno kopirani, i dalje ćete im imati pristup i moći ćete ih oporaviti bez potrebe za pristupom kompromitiranom sustavu.

Poboljšanje sigurnosti putem čestih sigurnosnih kopija

Česte sigurnosne kopije pomažu u povratu informacija u slučaju napada, oštećenja ili čak nenamjernog gubitka (brisanja). Bez obzira na to koja vrsta negativnih događaja dovodi do gubitka podataka, rizik se smanjuje zadržavanjem kopija podataka poslužitelja.

Osim napada ucjenjivačkim softverom, česte sigurnosne kopije mogu pomoći u mjerljivoj istrazi dugotrajnih napada na sustav. Ako svoje podatke ne pohranjujete sigurno u obliku sigurnosne kopije, utvrđivanje izvora napada i koji su podaci kompromitirani može biti izazovno ili čak nemoguće.

Implementacija čestih sigurnosnih kopija

Ključno je da provjerljivi oporavak oštećenih, kompromitiranih ili obrisanih podataka smatrate ciljem svojih napora za oporavak prilikom izrade sigurnosnih kopija sustava. Da to najbolje predočimo, razmislite koje bi radnje zahtijevale najmanje truda da se ponovno pokrenete i nastavite s radom ako vaš poslužitelj sutra nestane.

Evo još nekih točaka koje treba uzeti u obzir kada razmišljate o planu oporavka od katastrofe:

• Ako radite s dinamički promjenjivim podacima, vaše će sigurnosne kopije vjerojatno morati biti češće. U slučaju gubitka podataka, ako je vaša posljednja sigurnosna kopija bila predavno, mogli biste biti prisiljeni vratiti se na zastarjele podatke.
• Razmislite o samom procesu obnove sigurnosne kopije. Hoće li za to trebati dodati novi poslužitelj ili se može obnoviti postojeći?
• Koje je najduže razdoblje u kojem poslužitelj može biti neaktivan?
• Je li sigurnosna kopija izvan lokacije nužno rješenje?

Kako biste saznali više o CloudSigma rješenjima za oporavak od katastrofe (Disaster Recovery), pogledajte naš blog post koji detaljno opisuje zašto je naš Disaster-Recovery-as-a-Service savršen suputnik za oblak. A ovdje možete saznati više o CloudSigma sigurnosnim značajkama & značajkama kontinuiteta poslovanja. Također imamo detaljan vodič o tome kako jednostavno postaviti CloudSigma funkcionalnost sigurnosnog kopiranja.

Privatno umrežavanje i VPN-ovi

Privatna mreža je ona koja je dostupna za pristup i korištenje samo određenim korisnicima ili poslužiteljima. Sigurna veza između udaljenih uređaja koja omogućuje da veza funkcionira kao da je u privatnoj mreži je VPN (virtualna privatna mreža). Pruža vam mogućnost osiguravanja veza u privatnoj mreži i povezivanja udaljenih poslužitelja.

Kako privatne mreže poboljšavaju sigurnost?

Kada postoji izbor između korištenja javnih i privatnih mreža za internu komunikaciju, potonja je uvijek bolja opcija. Imajte na umu, međutim, da drugi korisnici unutar podatkovnog centra i dalje mogu pristupiti istoj mreži. To znači da se i dalje moraju primijeniti dodatne sigurnosne mjere kako bi se osiguralo da je komunikacija između poslužitelja sigurna.

U biti, korištenje VPN-a je pristup za definiranje onoga što zaposlenici vaše organizacije mogu vidjeti. Korespondencija će biti potpuno sigurna i privatna. Konfiguracije aplikacija omogućile bi prolaz prometa virtualnog sučelja kroz VPN. Na taj način, samo onim uslugama koje su namijenjene interakciji s klijentima putem interneta bit će dopušteno izlaganje javnoj mreži.

Koliko je teško implementirati VPN?

Iskorištavanje privatnih mreža jednostavno je za vaš podatkovni centar kao što je konfiguriranje vaših aplikacija i vatrozida za korištenje privatne mreže te omogućavanje VPN-a tijekom stvaranja vašeg poslužitelja. Važno je zapamtiti da drugi poslužitelji dijele isti mrežni prostor kao i privatne mreže na razini cijelog centra.

Početno postavljanje VPN-a je malo složenije. Međutim, dodatna sigurnost koju ovo donosi isplati se za većinu slučajeva korištenja. Konfiguracijske podatke i zajedničku sigurnost potrebno je instalirati i konfigurirati na svakom poslužitelju u mreži. Za detaljnije informacije o tome kako VPN radi i pregledu postavljanja OpenVPN-a na Ubuntuu pratite ovaj vodič. Također možete pratiti ovaj vodič koji vas vodi kroz korake za povezivanje VPN mreže s CloudSigma infrastrukturom.

SSL/TLS enkripcija i infrastruktura javnog ključa

Generiranje, upravljanje i provjera valjanosti certifikata za identifikaciju pojedinaca i enkripciju komunikacije nazivaju se infrastruktura javnog ključa (PKI). Različiti entiteti mogu se međusobno autentificirati pomoću SSL ili TLS certifikata. Nakon toga se također mogu koristiti za uspostavljanje šifrirane komunikacije.

Kako certifikati poboljšavaju sigurnost

Kako bi se šifrirao promet i potvrdio identitet članova na poslužitelju, ključno je uspostaviti autoritet za izdavanje certifikata (CA) i imati uvid u sve certifikate vaše mreže. To može pomoći u sprječavanju napada 'čovjek u sredini' (man-in-the-middle), u kojima haker oponaša poslužitelj, a promet se preusmjerava.

Konfiguracija svakog poslužitelja može se postaviti tako da vjeruje centraliziranom CA-u. Svim naknadnim potpisima certifikata tada se može implicitno vjerovati. Ako protokoli i aplikacije koje vaš poslužitelj koristi podržavaju SSL/TLS enkripciju, možete osigurati svoj sustav bez opterećenja VPN tunela. Za dodatne informacije pratite naš vodič o tome kako automatizirati obnovu LetsEncrypt SSL certifikata za Nginx.

Težina implementacije

Konfiguriranje certifikacijskog tijela, a zatim i postavljanje preostalog PKI-ja može zahtijevati mnogo početnog truda. Također, kada je potrebno izraditi, opozvati ili potpisati nove certifikate, bit će potreban dodatni administrativni napor.

Budući da većina infrastruktura mora rasti, implementacija potpunog PKO-a najrazumniji je pristup. Dok ne dođete do točke u kojoj je PKI vrijedan dodatnih troškova administracije, korištenje VPN-a za osiguranje komponenti sustava može poslužiti kao odgovarajuća privremena mjera.

Otkrivanje upada u sustav i korištenje revizije datoteka

Revizija datoteka je proces koji se koristi za usporedbu datoteka i njihovih atributa vašeg sustava u potpuno sigurnom, ispravnom stanju s onima u vašem trenutnom sustavu. Ovo je dobra metoda za pronalaženje i izolaciju neovlaštenih promjena sustava.

IDS, odnosno sustav za otkrivanje upada, odnosi se na softver za praćenje koji prati sve neovlaštene aktivnosti na sustavu. Općenito, koristi metode revizije datoteka kako bi potražio neočekivane promjene u sustavu.

Poboljšanje sigurnosti pomoću IDS-a/revizije datoteka

Osim same revizije na razini usluga, provođenje revizija na razini datoteka ključno je za osiguravanje sigurnosti vašeg sustava. To može učiniti automatizirani IDS proces ili periodički administrator sustava.

Revizije datoteka i IDS jedini su stvarni procesi koji osiguravaju da sustav nije pretrpio neočekivane promjene. Većina uljeza želi iskorištavati poslužitelje koje napadnu tijekom duljeg vremenskog razdoblja, a kako bi to učinili, moraju zadržati mogućnost da njihovo djelovanje ostane prikriveno. Mogli bi zamijeniti binarne datoteke ranjivim ili kompromitiranim verzijama. Sve datoteke koje su izmijenjene u sustavu bit će otkrivene revizijom datotečnog sustava. To vam pruža sigurnost da vrlo brzo saznate je li integritet sustava ugrožen.

Razina teškoće implementacije

Implementacija IDS-a i revizije datoteka može biti vrlo intenzivan proces. Na početku se sustav mora konfigurirati kako bi se definirale putanje koje treba izuzeti i utvrdile nestandardne promjene koje su napravljene na sustavu kako bi se stvorilo početno stanje sustava.

Svakodnevne operacije također postaju složenije jer će procedure morati ponovno provjeriti sustav prije pokretanja bilo kakvih ažuriranja. Početno stanje mjerenja sustava također će se morati ponovno stvoriti ili ponovno uspostaviti kako bi se obuhvatile promjene verzija softvera kao dio novog početnog stanja sustava. Izvješća o reviziji također će se morati prenijeti na drugu lokaciju. To je zato što morate spriječiti uljeza u sustav da izmijeni reviziju kako bi ostao skriven prikrivanjem svojih tragova.

Iako to svakako povećava administrativno opterećenje vašeg sustava, to je jedan od jedinih sigurnih načina da osigurate da nijedna datoteka nije izmijenjena bez vašeg znanja. Neki od najpopularnijih sustava za otkrivanje upada i reviziju datoteka su Aide i Tripwire.

Izolirana okruženja

Svaka metoda u kojoj se pojedinačne komponente izvode u vlastitom namjenskom prostoru naziva se izoliranim okruženjem za izvršavanje.

To može značiti da će određene komponente aplikacije biti smještene na vlastitim namjenskim poslužiteljima ili da vaše usluge mogu biti konfigurirane za rad u chroot okruženjima (ili spremnicima). Koliko je okruženje izolirano uglavnom ovisi o stvarnosti vaše infrastrukture i zahtjevima vaše aplikacije.

Poboljšanje sigurnosti pomoću izoliranih okruženja

Izolacijom vašeg procesa u pojedinačna okruženja, također izolirate koji bi procesi mogli biti pogođeni sigurnosnim propustima. Slično kao što odjeljci i pregrade pomažu u zadržavanju prodora vode na brodovima, kada razdvojite pojedinačne dijelove i komponente vašeg sustava, ako uljez dobije pristup jednom od njih, neće moći doći do cijelog međusobno povezanog mrežnog sustava.

Teškoća implementacije

Složenost izolacije vaših aplikacija varira ovisno o vrstama izolacije koje ste odlučili koristiti. Docker ne smatra izolaciju sigurnosnom značajkom. Međutim, kada su vaše komponente podijeljene između različitih kontejnera, izolacija se postiže mnogo lakše. Možete pratiti ovaj vodič za instalaciju Dockera na našu infrastrukturu.

Kada se postave chroot okruženja, također se pruža određeni stupanj izolacije. Međutim, ovo nije potpuno neprobojna metoda jer postoje načini za bijeg iz takvog okruženja. Namjenski strojevi za različite komponente obično su najbolji i najjednostavniji način za postizanje izolacije. Međutim, to je skuplje zbog potrebe za dodatnim strojevima.

Završne misli

Navedene strategije samo su neki od koraka koje možete poduzeti kako biste povećali sigurnost svog sustava. Vrijedi napomenuti da što duže čekate s implementacijom sigurnosnih značajki, to je njihova učinkovitost manja. Imajući to na umu, važno je osigurati da se sa sigurnošću ne čeka. Umjesto toga, trebala bi se implementirati kao jedna od prvih mjera pri izgradnji infrastrukture. Jednom kada je vaš sustav dovoljno siguran s osnovnim zaštitama, možete početi aktivirati usluge i dodavati aplikacije, znajući da se one prema zadanim postavkama izvode u sigurnom okruženju.

Sigurnost, međutim, nije statičan proces, već fluidan. Potrebno ju je održavati i ponavljati. Treba joj pristupiti s mentalitetom stalne svjesnosti i neprestane budnosti. Uvijek se zapitajte koje su sigurnosne implikacije uključene u bilo koju promjenu sustava. Pobrinite se da operativna okruženja i zadane konfiguracije uvijek optimiziraju sigurnost i rade s dovoljno defenzivnim softverom.

Ugodan rad na računalu!