Tämä artikkeli on kolmas artikkelisarjassa "Kuinka ottaa verkkoinfrastruktuurisi hallintaan". Sarjan kaikkien artikkeleiden sisältö ja linkit löytyvät täällä.

Turvallisuusriskien täydellisestä poistamisesta on turha puhua. Periaatteessa emme voi vähentää niitä nollaan. Meidän on myös ymmärrettävä, että kun pyrimme tekemään verkosta entistä turvallisempaa, ratkaisumme ovat yhä kalliimpia. Sinun on löydettävä verkkollesi järkevä kompromissi kustannusten, monimutkaisuuden ja turvallisuuden välillä.

Tietysti tietoturvasuunnittelu on orgaanisesti integroitu kokonaisarkkitehtuuriin ja käytetyt tietoturvaratkaisut vaikuttavat verkkoinfrastruktuurin skaalautumiseen, luotettavuuteen, hallittavuuteen, ..., mikä on myös otettava huomioon.

Mutta haluan muistuttaa, että nyt emme puhu verkon luomisesta. Meidän mukaan alkuolosuhteet olemme jo valinneet suunnittelun, valinneet laitteet ja luoneet infrastruktuurin, ja tässä vaiheessa meidän tulisi mahdollisuuksien mukaan "elätä" ja etsiä ratkaisuja aiemmin valitun lähestymistavan puitteissa.

Tehtävämme on nyt tunnistaa tietoturvaan liittyvät riskit verkkotasolla ja vähentää ne kohtuulliselle tasolle.

Verkon turvatarkastus

Jos organisaatiosi on ottanut käyttöön ISO 27k -prosessit, tietoturva-auditointien ja verkkomuutosten tulisi sopia saumattomasti tämän lähestymistavan kokonaisprosesseihin. Mutta nämä standardit eivät edelleenkään koske erityisiä ratkaisuja, eivät konfigurointia, eivät suunnittelua... Ei ole olemassa selkeitä neuvoja, ei standardeja, jotka sanelevat yksityiskohtaisesti, millainen verkkosi tulisi olla. Tämä on tämän tehtävän monimutkaisuus ja kauneus.

Haluaisin korostaa useita mahdollisia verkon tietoturvatarkastuksia:

• laitekokoonpanon auditointi (karkaisu)
• turvasuunnittelun tarkastus
• pääsyn tarkastus
• prosessin tarkastus

Laitteiden kokoonpanon tarkastus (karkaisu)

Näyttää siltä, ​​että useimmissa tapauksissa tämä on paras lähtökohta verkkosi tarkastukselle ja turvallisuuden parantamiselle. IMHO, tämä on hyvä osoitus Pareton laista (20 % ponnistelusta tuottaa 80 % tuloksesta ja loput 80 % ponnisteluista vain 20 % tuloksesta).

Tärkeintä on, että meillä on yleensä toimittajilta suosituksia turvallisuuden "parhaista käytännöistä" laitteita määritettäessä. Tätä kutsutaan "kovettumiseksi".

Voit myös usein löytää näiden suositusten pohjalta kyselylomakkeen (tai luoda sellaisen itse), jonka avulla voit määrittää, kuinka hyvin laitteesi kokoonpano vastaa näitä "parhaita käytäntöjä" ja tuloksen mukaisesti tehdä muutoksia verkkoosi. . Tämän avulla voit vähentää tietoturvariskejä merkittävästi melko helposti, käytännössä ilman kustannuksia.

Useita esimerkkejä joistakin Cisco-käyttöjärjestelmistä.

Cisco IOS Configuration Hardening
Cisco IOS-XR Configuration Hardening
Cisco NX-OS Configuration Hardening
Cisco Baseline -suojauksen tarkistuslista

Näiden asiakirjojen perusteella voidaan luoda luettelo kokoonpanovaatimuksista jokaiselle laitetyypille. Esimerkiksi Cisco N7K VDC:lle nämä vaatimukset saattavat näyttää tältä niin.

Tällä tavalla voidaan luoda konfiguraatiotiedostoja verkkoinfrastruktuurisi erityyppisille aktiivisille laitteille. Seuraavaksi voit "ladata" nämä konfigurointitiedostot manuaalisesti tai automaation avulla. Tämän prosessin automatisointia käsitellään yksityiskohtaisesti toisessa orkestrointia ja automaatiota käsittelevässä artikkelisarjassa.

Turvasuunnittelun auditointi

Tyypillisesti yritysverkosto sisältää seuraavat segmentit muodossa tai toisessa:

• DC (julkiset palvelut DMZ ja intranet-palvelinkeskus)
• Internet-yhteys
• Etäkäyttö VPN
• WAN reuna
• Sivuliike
• Kampus (toimisto)
• Ydin

Otsikot otettu kohteesta Cisco SAFE mallia, mutta ei tietenkään ole välttämätöntä liittyä juuri näihin nimiin ja tähän malliin. Silti haluan puhua olemuksesta enkä juuttua muodollisuuksiin.

Jokaiselle näistä segmenteistä turvallisuusvaatimukset, riskit ja vastaavasti ratkaisut ovat erilaisia.

Katsotaanpa jokaista niistä erikseen niiden ongelmien varalta, joita saatat kohdata tietoturvasuunnittelun näkökulmasta. Tietenkin toistan uudelleen, että tämä artikkeli ei millään tavalla teeskentele olevan täydellinen, mikä ei ole helppoa (ellei mahdotonta) saavuttaa tässä todella syvässä ja monitahoisessa aiheessa, mutta se heijastaa henkilökohtaista kokemustani.

Täydellistä ratkaisua ei ole (ainakaan vielä). Se on aina kompromissi. Mutta on tärkeää, että päätös yhden tai toisen lähestymistavan käytöstä tehdään tietoisesti ja ymmärtää sen hyvät ja huonot puolet.

Data Center

Turvallisuuden kannalta kriittisin segmentti.
Ja kuten tavallista, tässäkään ei ole universaalia ratkaisua. Kaikki riippuu suuresti verkkovaatimuksista.

Onko palomuuri välttämätön vai ei?

Vaikuttaa siltä, ​​​​että vastaus on ilmeinen, mutta kaikki ei ole aivan niin selvää kuin miltä saattaa näyttää. Eikä valintaan voi vaikuttaa vain hinta.

Esimerkki 1. Viiveet.

Jos alhainen latenssi on olennainen vaatimus joidenkin verkkosegmenttien välillä, mikä on totta esimerkiksi vaihdon tapauksessa, emme voi käyttää palomuureja näiden segmenttien välillä. On vaikea löytää tutkimuksia palomuurien latenssista, mutta harvat kytkinmallit voivat tarjota viivettä, joka on pienempi tai luokkaa 1 mksek, joten uskon, että jos mikrosekunnit ovat sinulle tärkeitä, palomuurit eivät ole sinua varten.

Esimerkki 2. Suorituskykyä.

Parhaiden L3-kytkimien suorituskyky on yleensä suuruusluokkaa suurempi kuin tehokkaimpien palomuurien suorituskyky. Siksi suuren intensiteetin liikenteessä sinun on myös todennäköisesti sallittava tämän liikenteen ohittaa palomuurit.

Esimerkki 3. Luotettavuutta.

Palomuurit, erityisesti nykyaikainen NGFW (Next-Generation FW) ovat monimutkaisia ​​laitteita. Ne ovat paljon monimutkaisempia kuin L3/L2-kytkimet. Ne tarjoavat suuren määrän palveluita ja konfigurointivaihtoehtoja, joten ei ole yllättävää, että niiden luotettavuus on paljon alhaisempi. Jos palvelun jatkuvuus on kriittinen verkon kannalta, saatat joutua valitsemaan, mikä johtaa parempaan käytettävyyteen - palomuuriturvallisuus vai kytkimiin (tai erilaisiin kudoksiin) rakennetun verkon yksinkertaisuus käyttämällä tavallisia ACL-luetteloita.

Yllä olevien esimerkkien tapauksessa sinun on todennäköisesti (tavalliseen tapaan) löydettävä kompromissi. Katsokaa seuraavia ratkaisuja:

• jos päätät olla käyttämättä palomuureja datakeskuksen sisällä, sinun on mietittävä, kuinka rajoittaa pääsyä kehän ympärille niin paljon kuin mahdollista. Voit esimerkiksi avata vain tarvittavat portit Internetistä (asiakasliikennettä varten) ja järjestelmänvalvojan pääsyn datakeskukseen vain hyppyisänniltä. Suorita hyppyisännillä kaikki tarvittavat tarkistukset (todennus/valtuutus, virustorjunta, lokikirjaus jne.)
• voit käyttää palvelinkeskusverkon loogista osiota segmenteiksi, kuten PSEFABRICissa kuvattu kaava esimerkki p002. Tässä tapauksessa reititys on konfiguroitava siten, että viiveherkkä tai korkean intensiteetin liikenne kulkee yhden segmentin "sisällä" (p002:n tapauksessa VRF) eikä kulje palomuurin läpi. Liikenne eri segmenttien välillä kulkee edelleen palomuurin läpi. Voit myös käyttää VRF:ien välistä reittivuotoa välttääksesi liikenteen uudelleenohjauksen palomuurin läpi
• Voit myös käyttää palomuuria läpinäkyvässä tilassa ja vain niissä VLAN-verkoissa, joissa nämä tekijät (latenssi/suorituskyky) eivät ole merkittäviä. Mutta sinun on tutkittava huolellisesti tämän modin käyttöön liittyvät rajoitukset jokaiselle myyjälle
• kannattaa harkita palveluketjun arkkitehtuurin käyttöä. Tämä sallii vain tarpeellisen liikenteen kulkevan palomuurin läpi. Teoriassa näyttää hyvältä, mutta en ole koskaan nähnyt tätä ratkaisua tuotannossa. Testasimme Cisco ACI/Juniper SRX/F5 LTM:n palveluketjua noin 3 vuotta sitten, mutta tuolloin tämä ratkaisu vaikutti meistä "karkealta".

Suojaustaso

Nyt sinun on vastattava kysymykseen, mitä työkaluja haluat käyttää liikenteen suodattamiseen. Tässä on joitain ominaisuuksia, jotka yleensä ovat NGFW:ssä (esim. täällä):

• tilallinen palomuuri (oletus)
• sovellusten palomuuri
• uhkien esto (virustorjunta, vakoiluohjelmien torjunta ja haavoittuvuus)
• URL-suodatus
• tietojen suodatus (sisällön suodatus)
• tiedostojen esto (tiedostotyyppien esto)
• dos suojaus

Eikä kaikki ole myöskään selvää. Vaikuttaa siltä, ​​että mitä korkeampi suojan taso, sitä parempi. Mutta sinun on myös harkittava sitä

• Mitä enemmän yllämainituista palomuuritoiminnoista käytät, sitä kalliimpaa se luonnollisesti on (lisenssit, lisämoduulit)
• joidenkin algoritmien käyttö voi vähentää merkittävästi palomuurin suorituskykyä ja myös lisätä viiveitä, katso esimerkiksi täällä
• kuten mikä tahansa monimutkainen ratkaisu, monimutkaisten suojausmenetelmien käyttö voi heikentää ratkaisusi luotettavuutta, esimerkiksi sovellusten palomuuria käytettäessä törmäsin joidenkin melko tavallisten toimivien sovellusten (dns, smb) tukkoon

Kuten aina, sinun on löydettävä verkkollesi paras ratkaisu.

On mahdotonta vastata lopullisesti kysymykseen siitä, mitä suojaustoimintoja voidaan tarvita. Ensinnäkin, koska se tietysti riippuu tiedoista, joita siirrät tai tallennat ja yrität suojata. Toiseksi, todellisuudessa turvallisuustyökalujen valinta on usein kysymys uskosta ja luottamuksesta myyjään. Et tunne algoritmeja, et tiedä kuinka tehokkaita ne ovat, etkä voi testata niitä täysin.

Siksi kriittisillä segmenteillä hyvä ratkaisu voi olla eri yritysten tarjousten hyödyntäminen. Voit esimerkiksi ottaa virustorjunnan käyttöön palomuurissa, mutta myös käyttää virustorjuntaa (toiselta valmistajalta) paikallisesti isännissä.

Segmentointi

Puhumme konesaliverkon loogisesta segmentoinnista. Esimerkiksi osiointi VLAN-verkkoihin ja aliverkkoihin on myös loogista segmentointia, mutta emme ota sitä huomioon sen ilmeisyyden vuoksi. Mielenkiintoinen segmentointi, jossa otetaan huomioon sellaiset kokonaisuudet kuin FW-turvavyöhykkeet, VRF:t (ja niiden analogit suhteessa eri toimittajiin), loogiset laitteet (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...

Tässä on esimerkki tällaisesta loogisesta segmentoinnista ja tällä hetkellä kysytystä datakeskussuunnittelusta PSEFABRIC-projektin p002.

Kun olet määritellyt verkkosi loogiset osat, voit kuvata kuinka liikenne liikkuu eri segmenttien välillä, missä laitteissa suodatus suoritetaan ja millä keinoin.

Jos verkossasi ei ole selkeää loogista osiota ja eri tietovirtojen suojauskäytäntöjen soveltamissääntöjä ei ole virallistettu, tämä tarkoittaa, että kun avaat tämän tai toisen pääsyn, sinun on ratkaistava tämä ongelma, ja suurella todennäköisyydellä ratkaisee sen joka kerta eri tavalla.

Usein segmentointi perustuu vain FW-turvavyöhykkeisiin. Sitten sinun on vastattava seuraaviin kysymyksiin:

• mitä turvavyöhykkeitä tarvitset
• mitä suojaustasoa haluat soveltaa kullekin näistä vyöhykkeistä
• sallitaanko alueen sisäinen liikenne oletuksena?
• jos ei, mitä liikenteen suodatuskäytäntöjä sovelletaan kullakin vyöhykkeellä
• mitä liikenteen suodatuskäytäntöjä sovelletaan kullekin vyöhykeparille (lähde/kohde)

TCAM

Yleinen ongelma on riittämätön TCAM (Ternary Content Addressable Memory) sekä reitityksessä että pääsyssä. IMHO, tämä on yksi tärkeimmistä kysymyksistä valittaessa laitteita, joten sinun on käsiteltävä tätä asiaa asianmukaisesti.

Esimerkki 1. Välitystaulukko TCAM.

Katsotaanpa katsomaan Palo Alto 7k palomuuri
Näemme, että IPv4-lähetystaulukon koko* = 32 kt
Lisäksi tämä reittien määrä on yhteinen kaikille VSYS:ille.

Oletetaan, että suunnittelusi mukaan päätät käyttää 4 VSYS:ää.
Jokainen näistä VSYS:istä on yhdistetty BGP:n kautta kahteen pilven MPLS PE:ään, joita käytät BB:nä. Näin ollen 4 VSYS:ää vaihtavat kaikki tietyt reitit keskenään ja niillä on edelleenlähetystaulukko, jossa on suunnilleen samat reittijoukot (mutta eri NH:t). Koska jokaisessa VSYS:ssä on 2 BGP-istuntoa (samoilla asetuksilla), sitten jokaisella MPLS:n kautta vastaanotetulla reitillä on 2 NH- ja vastaavasti 2 FIB-merkintää edelleenlähetystaulukossa. Jos oletamme, että tämä on palvelinkeskuksen ainoa palomuuri ja sen on tiedettävä kaikki reitit, tämä tarkoittaa, että palvelinkeskuksemme reittien kokonaismäärä ei voi olla suurempi kuin 32K/(4 * 2) = 4K.

Jos nyt oletetaan, että meillä on 2 datakeskusta (samalla rakenteella) ja haluamme käyttää VLAN-verkkoja "venytettyinä" datakeskusten välillä (esimerkiksi vMotionille), niin reititysongelman ratkaisemiseksi meidän on käytettävä isäntäreittejä . Mutta tämä tarkoittaa, että kahdelle palvelinkeskukselle meillä on enintään 2 mahdollista isäntäkonetta, ja tämä ei tietenkään välttämättä riitä.

Esimerkki 2. ACL TCAM.

Jos aiot suodattaa liikennettä L3-kytkimillä (tai muilla L3-kytkimiä käyttävillä ratkaisuilla, esim. Cisco ACI), laitteita valittaessa kannattaa kiinnittää huomiota TCAM ACL:ään.

Oletetaan, että haluat hallita pääsyä Cisco Catalyst 4500:n SVI-liitäntöihin. Sitten, kuten näkyy tässä artikkelissa, voit hallita lähtevää (sekä saapuvaa) liikennettä liitännöissä käyttämällä vain 4096 TCAM-linjaa. Mikä TCAM3:a käytettäessä antaa sinulle noin 4000 tuhatta ACE:tä (ACL-riviä).

Jos kohtaat riittämättömän TCAM:n ongelman, sinun on ensinnäkin tietysti harkittava optimointimahdollisuutta. Joten jos edelleenlähetystaulukon kokoon liittyy ongelmia, sinun on harkittava mahdollisuutta yhdistää reitit. Jos pääsyn TCAM-koossa ilmenee ongelmia, tarkasta pääsyt, poista vanhentuneet ja päällekkäiset tietueet ja mahdollisesti tarkista käyttöoikeuksien avaamismenettely (käsitellään yksityiskohtaisesti pääsyn valvontaa käsittelevässä luvussa).

High Availability

Kysymys kuuluu: pitäisikö minun käyttää HA:ta palomuurien vai asentaa kaksi erillistä laatikkoa "rinnakkain" ja jos toinen epäonnistuu, reitittää liikenne toisen kautta?

Vaikuttaa siltä, ​​​​että vastaus on ilmeinen - käytä HA:ta. Syy siihen, miksi tämä kysymys herää edelleen, on se, että valitettavasti saavutettavuuden teoreettinen ja mainonta 99 ja useat desimaaliset prosenttiosuudet käytännössä eivät ole läheskään niin ruusuisia. HA on loogisesti melko monimutkainen asia, ja eri laitteilla ja eri valmistajilla (ei ollut poikkeuksia) havaitsimme ongelmia ja bugeja ja palvelukatkoja.

Jos käytät HA:ta, sinulla on mahdollisuus sammuttaa yksittäiset solmut, vaihtaa niiden välillä palvelua pysäyttämättä, mikä on tärkeää esimerkiksi päivityksiä tehtäessä, mutta samalla sinulla on kaukana nollasta todennäköisyys, että molemmat solmut katkeaa samaan aikaan, ja myös, että seuraavassa päivitys ei suju niin sujuvasti kuin myyjä lupaa (tämä ongelma voidaan välttää, jos sinulla on mahdollisuus testata päivitystä laboratoriolaitteilla).

Jos et käytä HA:ta, kaksinkertaisen epäonnistumisen kannalta riskisi ovat paljon pienemmät (koska sinulla on 2 itsenäistä palomuuria), mutta koska... istuntoja ei synkronoida, menetät liikennettä aina kun vaihdat näiden palomuurien välillä. Tietysti voit käyttää tilatonta palomuuria, mutta silloin palomuurin käyttö on suurelta osin menetetty.

Siksi, jos olet tarkastuksen tuloksena löytänyt yksinäisiä palomuurit ja harkitset verkkosi luotettavuuden lisäämistä, HA on tietysti yksi suositeltavista ratkaisuista, mutta sinun tulee ottaa huomioon myös niihin liittyvät haitat. tällä lähestymistavalla ja kenties erityisesti verkkoasi varten toinen ratkaisu olisi sopivampi.

Hallittavuus

Periaatteessa HA on myös hallittavuutta. Sen sijaan, että määrität 2 laatikkoa erikseen ja käsittelet kokoonpanojen synkronoinnin ongelmaa, hallitset niitä aivan kuin sinulla olisi yksi laite.

Mutta ehkä sinulla on monia datakeskuksia ja monia palomuuria, niin tämä kysymys herää uudelle tasolle. Ja kysymys ei ole vain kokoonpanosta, vaan myös siitä

• varmuuskopioasetukset
• päivitykset
• päivitykset
• seurantaa
• puunkorjuu

Ja kaikki tämä voidaan ratkaista keskitetyillä hallintajärjestelmillä.

Joten esimerkiksi jos käytät Palo Alto -palomuuria, niin Katsella on sellainen ratkaisu.

Jatkettava.

Lähde: will.com