Бұл мақала «Желілік инфрақұрылымды қалай басқаруға болады» мақалалар сериясының үшінші мақаласы. Сериядағы барлық мақалалардың мазмұнын және сілтемелерді табуға болады осында.

Қауіпсіздік тәуекелдерін толығымен жою туралы айтудың қажеті жоқ. Негізінде біз оларды нөлге дейін азайта алмаймыз. Сондай-ақ, біз желіні барған сайын қауіпсіз етуге ұмтылған сайын, шешімдеріміздің қымбаттап бара жатқанын түсінуіміз керек. Желіңіз үшін мағынасы бар құны, күрделілігі және қауіпсіздік арасындағы келіссөзді табу керек.

Әрине, қауіпсіздік дизайны жалпы архитектураға органикалық түрде біріктірілген және қолданылатын қауіпсіздік шешімдері желілік инфрақұрылымның ауқымдылығына, сенімділігіне, басқарылуына, ... әсер етеді, бұл да ескерілуі керек.

Бірақ қазір біз желі құру туралы айтпайтынымызды еске сала кетейін. Біздің пікіріміз бойынша бастапқы шарттар біз дизайнды таңдадық, жабдықты таңдадық және инфрақұрылымды жасадық және бұл кезеңде, мүмкіндігінше, бұрын таңдалған тәсіл контекстінде «өмір сүру» және шешімдерді табу керек.

Біздің ендігі міндетіміз – желі деңгейінде қауіпсіздікке байланысты тәуекелдерді анықтау және оларды ақылға қонымды деңгейге дейін төмендету.

Желілік қауіпсіздік аудиті

Егер сіздің ұйымыңыз ISO 27k процестерін енгізген болса, қауіпсіздік аудиттері мен желідегі өзгерістер осы тәсілдегі жалпы процестерге біркелкі сәйкес келуі керек. Бірақ бұл стандарттар әлі де нақты шешімдер туралы емес, конфигурация туралы емес, дизайн туралы емес... Сіздің желіңіздің қандай болуы керектігін егжей-тегжейлі көрсететін нақты кеңестер, стандарттар жоқ, бұл тапсырманың күрделілігі мен әдемілігі.

Мен бірнеше ықтимал желілік қауіпсіздік аудиттерін атап өткім келеді:

• жабдық конфигурациясының аудиті (қатайту)
• қауіпсіздік дизайны аудиті
• қолжетімділік аудиті
• процесс аудиті

Жабдық конфигурациясының аудиті (қатайту)

Көп жағдайда бұл сіздің желіңіздің қауіпсіздігін тексеру және жақсарту үшін ең жақсы бастапқы нүкте сияқты. IMHO, бұл Парето заңының жақсы демонстрациясы (20% күш нәтиженің 80% береді, ал қалған 80% күш нәтиженің тек 20% береді).

Қорытындылайтын болсақ, бізде жабдықты конфигурациялау кезінде қауіпсіздікті қамтамасыз ету бойынша «үздік тәжірибелерге» қатысты жеткізушілердің ұсыныстары болады. Бұл «қатайту» деп аталады.

Сондай-ақ, осы ұсыныстарға негізделген сауалнаманы жиі таба аласыз (немесе өзіңіз жасаңыз), ол сіздің жабдық конфигурациясының осы «үздік тәжірибелерге» қаншалықты сәйкес келетінін анықтауға және нәтижеге сәйкес желіге өзгертулер енгізуге көмектеседі. . Бұл қауіпсіздік тәуекелдерін айтарлықтай оңай, іс жүзінде ешқандай шығынсыз азайтуға мүмкіндік береді.

Кейбір Cisco операциялық жүйелеріне бірнеше мысалдар.

Cisco IOS конфигурациясын қатайту
Cisco IOS-XR конфигурациясының шыңдалуы
Cisco NX-OS конфигурациясының шыңдалуы
Cisco Baseline Қауіпсіздікті тексеру тізімі

Осы құжаттардың негізінде жабдықтың әрбір түріне арналған конфигурация талаптарының тізімін жасауға болады. Мысалы, Cisco N7K VDC үшін бұл талаптар ұқсас болуы мүмкін солай.

Осылайша, желілік инфрақұрылымдағы белсенді жабдықтың әртүрлі түрлері үшін конфигурация файлдарын жасауға болады. Әрі қарай, қолмен немесе автоматтандыруды пайдаланып, осы конфигурация файлдарын «жүктеп салуға» болады. Бұл процесті қалай автоматтандыру керектігі оркестрлеу және автоматтандыру туралы мақалалардың басқа сериясында егжей-тегжейлі талқыланады.

Қауіпсіздік дизайны аудиті

Әдетте, кәсіпорын желісі сол немесе басқа пішінде келесі сегменттерді қамтиды:

• DC (Қоғамдық қызметтер DMZ және Intranet деректер орталығы)
• Интернетке қосылу
• Қашықтан қол жеткізу VPN
• WAN шеті
• филиал
• Кампус (кеңсе)
• өзек

Тақырыптар қайдан алынды Cisco ҚАУІПСІЗ үлгі, бірақ, әрине, дәл осы атауларға және осы үлгіге қосылудың қажеті жоқ. Сонда да мен формальдылыққа батып кетпей, мәні туралы айтқым келеді.

Осы сегменттердің әрқайсысы үшін қауіпсіздік талаптары, тәуекелдер және сәйкесінше шешімдер әртүрлі болады.

Қауіпсіздік дизайны тұрғысынан тап болуы мүмкін мәселелер үшін олардың әрқайсысын бөлек қарастырайық. Әрине, тағы да қайталаймын, бұл мақала толық деп көрсетпейді, бұл шын мәнінде терең және көп қырлы тақырыпта қол жеткізу оңай емес (мүмкін емес болса), бірақ бұл менің жеке тәжірибемді көрсетеді.

Мінсіз шешім жоқ (кем дегенде әлі жоқ). Бұл әрқашан ымыраға келу. Бірақ бір немесе басқа тәсілді қолдану туралы шешім оның жақсы және жағымсыз жақтарын түсіне отырып, саналы түрде қабылдануы маңызды.

Деректер орталығы

Қауіпсіздік тұрғысынан ең маңызды сегмент.
Және, әдеттегідей, мұнда да әмбебап шешім жоқ. Мұның бәрі желі талаптарына байланысты.

Брандмауэр қажет пе, жоқ па?

Жауап анық көрінетін сияқты, бірақ бәрі көрінгендей анық емес. Сіздің таңдауыңыз тек әсер ете алмайды баға.

Мысал 1. Кешігулер.

Егер кейбір желі сегменттері арасындағы төмен кідіріс маңызды талап болса, мысалы, алмасу жағдайында дұрыс болса, онда біз осы сегменттер арасында желіаралық қалқандарды пайдалана алмаймыз. Брандмауэрлерде кідіріс туралы зерттеулерді табу қиын, бірақ бірнеше коммутатор үлгілері 1 мксек-тен аз немесе кідіріспен қамтамасыз ете алады, сондықтан микросекундтар сіз үшін маңызды болса, брандмауэрлер сізге арналмаған деп ойлаймын.

Мысал 2. Өнімділік.

Жоғарғы L3 қосқыштарының өткізу қабілеті әдетте ең қуатты брандмауэрлердің өткізу қабілетінен жоғары. Сондықтан, жоғары қарқынды трафик жағдайында, сіз бұл трафикке брандмауэрді айналып өтуге рұқсат беруіңіз мүмкін.

Мысал 3. Сенімділік.

Брандмауэрлер, әсіресе қазіргі заманғы NGFW (Next-Generation FW) күрделі құрылғылар болып табылады. Олар L3/L2 қосқыштарына қарағанда әлдеқайда күрделі. Олар көптеген қызметтер мен конфигурация опцияларын ұсынады, сондықтан олардың сенімділігі әлдеқайда төмен болуы таңқаларлық емес. Егер қызмет көрсетудің үздіксіздігі желі үшін маңызды болса, онда сізге қолжетімділікке не әкелетінін таңдау қажет болуы мүмкін - брандмауэр арқылы қауіпсіздік немесе кәдімгі ACL қолданатын коммутаторларға (немесе әртүрлі маталар түрлеріне) салынған желінің қарапайымдылығы.

Жоғарыда келтірілген мысалдар жағдайында сіз (әдеттегідей) ымыраға келуге тура келеді. Келесі шешімдерді іздеңіз:

• деректер орталығының ішінде брандмауэрлерді пайдаланбауды шешсеңіз, периметр бойынша қол жеткізуді мүмкіндігінше шектеу туралы ойлануыңыз керек. Мысалы, Интернеттен тек қажетті порттарды ашуға болады (клиент трафигі үшін) және деректер орталығына тек өту хосттарынан әкімшілік қатынасу. Секіру хосттарында барлық қажетті тексерулерді орындаңыз (аутентификация/авторизация, антивирус, журнал жүргізу, ...)
• деректер орталығы желісінің логикалық бөлімін PSEFABRIC-те сипатталған схемаға ұқсас сегменттерге пайдалануға болады. мысал p002. Бұл жағдайда маршруттау кідіріске сезімтал немесе жоғары қарқынды трафик бір сегменттің «ішінде» өтетіндей (p002, VRF жағдайында) және брандмауэр арқылы өтпейтіндей конфигурациялануы керек. Әртүрлі сегменттер арасындағы трафик брандмауэр арқылы өтуді жалғастырады. Сондай-ақ брандмауэр арқылы трафикті қайта бағыттамау үшін VRF арасында ағып кету жолын пайдалануға болады
• Сондай-ақ брандмауэрді мөлдір режимде және осы факторлар (кідіріс/өнімділік) маңызды емес VLAN желілері үшін ғана пайдалануға болады. Бірақ әрбір жеткізуші үшін осы режимді пайдалануға байланысты шектеулерді мұқият зерделеу керек
• қызмет тізбегі архитектурасын пайдалануды қарастырғыңыз келуі мүмкін. Бұл брандмауэр арқылы тек қажетті трафикті өткізуге мүмкіндік береді. Теорияда жақсы көрінеді, бірақ мен бұл шешімді өндірісте ешқашан көрген емеспін. Біз Cisco ACI/Juniper SRX/F5 LTM үшін қызмет көрсету тізбегін шамамен 3 жыл бұрын сынадық, бірақ сол кезде бұл шешім бізге «шикі» болып көрінді.

Қорғаныс деңгейі

Енді трафикті сүзу үшін қандай құралдарды пайдаланғыңыз келеді деген сұраққа жауап беруіңіз керек. Мұнда әдетте NGFW-де болатын кейбір мүмкіндіктер берілген (мысалы, осында):

• күйді брандмауэр (әдепкі)
• қолданбалы желіаралық қалқан
• қауіптердің алдын алу (антивирус, шпиондық бағдарламаға қарсы және осалдық)
• URL сүзгісі
• деректерді сүзу (мазмұнды сүзу)
• файлды блоктау (файл түрлерін блоктау)
• қорғау

Және бәрі де анық емес. Қорғаныс деңгейі неғұрлым жоғары болса, соғұрлым жақсы болатын сияқты. Бірақ мұны да ескеру керек

• Жоғарыда көрсетілген брандмауэр функцияларын неғұрлым көп пайдалансаңыз, соғұрлым ол қымбатырақ болады (лицензиялар, қосымша модульдер)
• кейбір алгоритмдерді пайдалану брандмауэрдің өткізу қабілетін айтарлықтай азайтады, сонымен қатар кідірістерді арттырады, мысалы, қараңыз. осында
• Кез келген күрделі шешім сияқты, күрделі қорғау әдістерін пайдалану шешіміңіздің сенімділігін төмендетуі мүмкін, мысалы, қолданбалы желіаралық қалқанды пайдалану кезінде мен кейбір стандартты жұмыс қосымшаларының (dns, smb) бұғатталуына тап болдым.

Әдеттегідей, желі үшін ең жақсы шешімді табу керек.

Қандай қорғаныс функциялары қажет болуы мүмкін деген сұраққа нақты жауап беру мүмкін емес. Біріншіден, бұл, әрине, сіз жіберетін немесе сақтайтын және қорғауға тырысатын деректерге байланысты. Екіншіден, шын мәнінде, қауіпсіздік құралдарын таңдау көбінесе жеткізушіге сенім мен сенім мәселесі болып табылады. Сіз алгоритмдерді білмейсіз, олардың қаншалықты тиімді екенін білмейсіз және оларды толық тексере алмайсыз.

Сондықтан, маңызды сегменттерде әртүрлі компаниялардың ұсыныстарын пайдалану жақсы шешім болуы мүмкін. Мысалы, брандмауэрде антивирусты қосуға болады, сонымен қатар хосттарда жергілікті антивирустық қорғауды (басқа өндірушіден) пайдалануға болады.

Сегменттеу

Біз деректер орталығы желісін логикалық сегментациялау туралы айтып отырмыз. Мысалы, VLAN және ішкі желілерге бөлу де логикалық сегменттеу болып табылады, бірақ біз оны анықтығына байланысты қарастырмаймыз. FW қауіпсіздік аймақтары, VRF (және олардың әртүрлі жеткізушілерге қатысты аналогтары), логикалық құрылғылар (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...) сияқты нысандарды ескере отырып қызықты сегменттеу.

Осындай логикалық сегментацияның мысалы және қазіргі уақытта сұранысқа ие деректер орталығының дизайны келтірілген PSEFABRIC жобасының p002.

Желінің логикалық бөліктерін анықтай отырып, сіз трафиктің әртүрлі сегменттер арасында қалай қозғалатынын, қай құрылғыларда сүзгілеу орындалатынын және қандай құралдармен орындалатынын сипаттай аласыз.

Если в вашей сети отсутствует ясное логическое разбиение и не формализованы правила применения security политик для разных потоков данных (flow), то это значит, что при открытии того или иного доступа вы вынуждены решать эту задачу, и с большой вероятностью каждый раз вы будете решать ее әр қалай.

Көбінесе сегменттеу тек FW қауіпсіздік аймақтарына негізделген. Содан кейін келесі сұрақтарға жауап беру керек:

• сізге қандай қауіпсіздік аймақтары қажет
• осы аймақтардың әрқайсысына қандай қорғаныс деңгейін қолданғыңыз келеді
• әдепкі бойынша аймақішілік трафик рұқсат етіледі ме?
• олай болмаса, әр аймақта қандай трафикті сүзу саясаты қолданылады
• аймақтардың әрбір жұбы үшін қандай трафикті сүзу саясаты қолданылады (көзі/межелі орын)

TCAM

Жалпы мәселе маршруттау үшін де, кірулер үшін де жеткіліксіз TCAM (Үштік мазмұнды мекенжайлық жад). IMHO, бұл жабдықты таңдаудағы ең маңызды мәселелердің бірі, сондықтан сіз бұл мәселені тиісті дәрежеде мұқият қарауыңыз керек.

Мысал 1. TCAM жіберу кестесі.

Қарап көрейік Пало Альто 7к брандмауэр
Біз IPv4 қайта жіберу кестесінің өлшемі* = 32К екенін көреміз
Сонымен қатар, маршруттардың бұл саны барлық VSYS үшін ортақ.

Дизайныңызға сәйкес сіз 4 VSYS пайдалануды шештіңіз делік.
Осы VSYS-тердің әрқайсысы BGP арқылы сіз BB ретінде пайдаланатын бұлттың екі MPLS PE-ге қосылған. Осылайша, 4 VSYS барлық нақты маршруттарды бір-бірімен алмастырады және шамамен бірдей маршруттар жиыны (бірақ әртүрлі NHs) бар бағыттау кестесіне ие. Өйткені әрбір VSYS-де 2 BGP сеансы бар (бірдей параметрлермен), содан кейін MPLS арқылы алынған әрбір маршрутта 2 NH және сәйкесінше, қайта жіберу кестесінде 2 FIB жазбасы болады. Егер бұл деректер орталығындағы жалғыз брандмауэр және ол барлық бағыттар туралы білуі керек деп есептесек, бұл біздің деректер орталығындағы маршруттардың жалпы саны 32K/(4 * 2) = 4K-ден аспауы керек дегенді білдіреді.

Енді бізде 2 деректер орталығы (бірдей дизайнмен) бар деп болжасақ және біз деректер орталықтары арасында «созылған» VLAN-ды қолданғымыз келсе (мысалы, vMotion үшін), онда маршруттау мәселесін шешу үшін біз хост маршруттарын пайдалануымыз керек. . Бірақ бұл 2 деректер орталығы үшін бізде 4096 ықтимал хосттан аспайтынын білдіреді және, әрине, бұл жеткіліксіз болуы мүмкін.

Мысал 2. ACL TCAM.

Егер сіз L3 қосқыштарында (немесе L3 қосқыштарын пайдаланатын басқа шешімдерде, мысалы, Cisco ACI) трафикті сүзуді жоспарласаңыз, онда жабдықты таңдағанда TCAM ACL-ге назар аудару керек.

Cisco Catalyst 4500 SVI интерфейстеріндегі қатынасты басқарғыңыз келеді делік. Содан кейін мына жерден көрініп тұрғандай. осы баптың, интерфейстердегі шығыс (сонымен қатар кіріс) трафикті басқару үшін тек 4096 TCAM желісін пайдалануға болады. Бұл TCAM3 пайдалану кезінде сізге шамамен 4000 мың ACE (ACL желілері) береді.

Егер сіз TCAM жеткіліксіздігі мәселесіне тап болсаңыз, онда, ең алдымен, әрине, оңтайландыру мүмкіндігін қарастыру керек. Сонымен, қайта жіберу кестесінің өлшеміне қатысты мәселе туындаған жағдайда, маршруттарды біріктіру мүмкіндігін қарастыру керек. Кірулерге, тексеру рұқсаттарына арналған TCAM өлшеміне қатысты мәселе туындаған жағдайда, ескірген және қайталанатын жазбаларды жойыңыз және рұқсаттарды ашу процедурасын қайта қарауыңыз мүмкін (қолжетімділіктерді тексеру тарауында егжей-тегжейлі талқыланады).

Жоғары қол жетімділік

Сұрақ: брандмауэр үшін HA пайдалануым керек пе немесе «параллель» екі тәуелсіз қорапты орнату керек пе, ал егер олардың біреуі сәтсіз болса, трафикті екіншісіне бағыттау керек пе?

Жауап анық болып көрінетін сияқты - HA қолданыңыз. Бұл сұрақтың әлі де туындайтын себебі, өкінішке орай, теориялық және жарнамалық 99 және практикада қол жетімділіктің бірнеше ондық пайызы соншалықты қызғылт емес болып шығады. HA логикалық тұрғыдан өте күрделі нәрсе, және әртүрлі жабдықта және әртүрлі жеткізушілерде (ерекшеліктер болған жоқ) біз проблемалар мен қателерді анықтадық және қызмет көрсетуді тоқтаттық.

Егер сіз HA-ны пайдалансаңыз, сізде жеке түйіндерді өшіру, қызмет көрсетуді тоқтатпай олардың арасында ауысу мүмкіндігі болады, бұл маңызды, мысалы, жаңартуларды жасау кезінде, бірақ сонымен бірге сізде екі түйіннің де нөлдік ықтималдығы бар. бір уақытта бұзылады, сонымен қатар келесі жаңарту сатушы уәде еткендей бірқалыпты жүрмейді (егер сізде зертханалық жабдықта жаңартуды тексеру мүмкіндігі болса, бұл мәселені болдырмауға болады).

Егер сіз HA қолданбасаңыз, онда екі есе ақаулық тұрғысынан сіздің тәуекелдеріңіз әлдеқайда төмен (себебі сізде 2 тәуелсіз желіаралық қалқан бар), бірақ... сеанстар синхрондалмаған болса, осы желіаралық қалқандар арасында ауысқан сайын трафик жоғалады. Сіз, әрине, азаматтығы жоқ желіаралық қалқанды пайдалана аласыз, бірақ содан кейін брандмауэрді пайдаланудың мәні айтарлықтай жоғалады.

Сондықтан, егер аудит нәтижесінде сіз жалғыз желіаралық қалқандарды тапсаңыз және желіңіздің сенімділігін арттыру туралы ойласаңыз, онда HA, әрине, ұсынылатын шешімдердің бірі болып табылады, бірақ сіз сонымен бірге байланысты кемшіліктерді де ескеруіңіз керек. осы тәсілмен және, мүмкін, сіздің желіңіз үшін, басқа шешім қолайлырақ болар еді.

Басқару қабілеті

Негізінде, HA бақылау мүмкіндігі туралы да. 2 қорапты бөлек конфигурациялаудың және конфигурацияларды синхрондауды сақтау мәселесімен айналысудың орнына, сіз оларды бір құрылғыңыз сияқты басқарасыз.

Бірақ сізде көптеген деректер орталықтары және көптеген желіаралық қалқандар бар шығар, онда бұл сұрақ жаңа деңгейде туындайды. Және мәселе конфигурация туралы ғана емес, сонымен қатар туралы

• сақтық көшірме конфигурациялары
• жаңартулар
• жаңартулар
• мониторинг
• журнал жүргізу

Ал мұның барлығын орталықтандырылған басқару жүйелері арқылы шешуге болады.

Мысалы, егер сіз Palo Alto брандмауэрін пайдалансаңыз, онда Панорама осындай шешім болып табылады.

Жалғасы бар.

Ақпарат көзі: www.habr.com