Այս հոդվածը երրորդն է «Ինչպես վերահսկել ձեր ցանցային ենթակառուցվածքը» հոդվածների շարքում: Շարքի բոլոր հոդվածների բովանդակությունը և հղումները կարելի է գտնել .
Անվտանգության ռիսկերն ամբողջությամբ վերացնելու մասին խոսելն անիմաստ է։ Սկզբունքորեն մենք չենք կարող դրանք զրոյացնել։ Մենք նաև պետք է հասկանանք, որ քանի որ մենք ձգտում ենք ցանցն ավելի ու ավելի անվտանգ դարձնել, մեր լուծումներն ավելի ու ավելի թանկ են դառնում: Դուք պետք է փոխզիջում գտնեք արժեքի, բարդության և անվտանգության միջև, որն իմաստ ունի ձեր ցանցի համար:
Իհարկե, անվտանգության դիզայնը օրգանապես ինտեգրված է ընդհանուր ճարտարապետության մեջ, և օգտագործվող անվտանգության լուծումները ազդում են ցանցային ենթակառուցվածքի մասշտաբայնության, հուսալիության, կառավարելիության և ... վրա, ինչը նույնպես պետք է հաշվի առնել:
Բայց հիշեցնեմ, որ հիմա մենք չենք խոսում ցանց ստեղծելու մասին։ Ըստ մեր մենք արդեն ընտրել ենք դիզայնը, ընտրել տեխնիկան, ստեղծել ենք ենթակառուցվածքը, և այս փուլում, հնարավորության դեպքում, պետք է «ապրենք» և լուծումներ գտնենք նախկինում ընտրված մոտեցման համատեքստում։
Այժմ մեր խնդիրն է բացահայտել ցանցի մակարդակով անվտանգության հետ կապված ռիսկերը և դրանք հասցնել ողջամիտ մակարդակի:
Ցանցի անվտանգության աուդիտ
Եթե ձեր կազմակերպությունն իրականացրել է ISO 27k գործընթացներ, ապա անվտանգության աուդիտները և ցանցի փոփոխությունները պետք է անխափան տեղավորվեն այս մոտեցման ընդհանուր գործընթացների մեջ: Բայց այս ստանդարտները դեռևս կոնկրետ լուծումների, ոչ կոնֆիգուրացիայի, ոչ դիզայնի մասին են... Չկան հստակ խորհուրդներ, չկան ստանդարտներ, որոնք մանրամասն թելադրում են, թե ինչպիսին պետք է լինի ձեր ցանցը, սա է այս առաջադրանքի բարդությունն ու գեղեցկությունը:
Ես կնշեի ցանցի անվտանգության մի քանի հնարավոր աուդիտ.
- սարքավորումների կոնֆիգուրացիայի աուդիտ (կարծրացում)
- անվտանգության դիզայնի աուդիտ
- մուտքի աուդիտ
- գործընթացի աուդիտ
Սարքավորումների կոնֆիգուրացիայի աուդիտ (կարծրացում)
Թվում է, որ շատ դեպքերում սա լավագույն մեկնարկային կետն է աուդիտի և ձեր ցանցի անվտանգության բարելավման համար: IMHO, սա Պարետոյի օրենքի լավ ցուցադրումն է (20% ջանքերը տալիս են արդյունքի 80% -ը, իսկ մնացած 80% ջանքերը տալիս են արդյունքի միայն 20% -ը):
Ներքևի տողն այն է, որ մենք սովորաբար առաջարկում ենք մատակարարներից՝ կապված սարքավորումների կազմաձևման ժամանակ անվտանգության «լավագույն փորձի» հետ: Սա կոչվում է «կարծրացում»:
Այս առաջարկությունների հիման վրա դուք կարող եք նաև հաճախ գտնել հարցաթերթ (կամ ինքներդ ստեղծել), որը կօգնի ձեզ որոշել, թե որքանով է ձեր սարքավորման կոնֆիգուրացիան համապատասխանում այս «լավագույն փորձին» և արդյունքին համապատասխան՝ փոփոխություններ կատարել ձեր ցանցում։ . Սա թույլ կտա զգալիորեն նվազեցնել անվտանգության ռիսկերը բավականին հեշտությամբ՝ գրեթե առանց ծախսերի:
Մի քանի օրինակ Cisco-ի որոշ օպերացիոն համակարգերի համար:
Այս փաստաթղթերի հիման վրա կարող է ստեղծվել յուրաքանչյուր տեսակի սարքավորման համար կազմաձևման պահանջների ցանկ: Օրինակ, Cisco N7K VDC-ի համար այս պահանջները կարող են նման լինել .
Այս կերպ կոնֆիգուրացիայի ֆայլերը կարող են ստեղծվել ձեր ցանցային ենթակառուցվածքի տարբեր տեսակի ակտիվ սարքավորումների համար: Հաջորդը, ձեռքով կամ օգտագործելով ավտոմատացում, կարող եք «վերբեռնել» այս կազմաձևման ֆայլերը: Ինչպես ավտոմատացնել այս գործընթացը, մանրամասն կքննարկվի նվագախմբի և ավտոմատացման վերաբերյալ հոդվածների մեկ այլ շարքում:
Անվտանգության դիզայնի աուդիտ
Սովորաբար, ձեռնարկության ցանցը այս կամ այն ձևով պարունակում է հետևյալ հատվածները.
- DC (Հանրային ծառայությունների DMZ և Ինտրանետ տվյալների կենտրոն)
- Մուտք ինտերնետ
- Հեռակա մուտք VPN
- WAN եզր
- Մասնաճյուղ
- Համալսարան (գրասենյակ)
- Core
Վերնագրերը վերցված են մոդելը, բայց պետք չէ, իհարկե, կցել հենց այս անուններին և այս մոդելին։ Այդուհանդերձ, ուզում եմ խոսել էության մասին և չխրվել ձևականությունների մեջ։
Այս հատվածներից յուրաքանչյուրի համար անվտանգության պահանջները, ռիսկերը և, համապատասխանաբար, լուծումները տարբեր կլինեն։
Եկեք նայենք դրանցից յուրաքանչյուրին առանձին՝ այն խնդիրների համար, որոնց կարող եք հանդիպել անվտանգության նախագծման տեսանկյունից: Իհարկե, նորից եմ կրկնում, որ այս հոդվածը ոչ մի կերպ չի հավակնում ամբողջական լինելուն, ինչին հասնելը հեշտ չէ (եթե ոչ անհնար) այս իսկապես խորը և բազմակողմ թեմայում, բայց այն արտացոլում է իմ անձնական փորձը։
Կատարյալ լուծում չկա (համենայն դեպս՝ դեռ): Դա միշտ փոխզիջում է: Բայց կարևոր է, որ այս կամ այն մոտեցումն օգտագործելու որոշումը գիտակցված լինի՝ հասկանալով դրա դրական և բացասական կողմերը:
data Center
Անվտանգության տեսանկյունից ամենակարևոր հատվածը:
Եվ, ինչպես միշտ, այստեղ էլ համընդհանուր լուծում չկա։ Ամեն ինչ մեծապես կախված է ցանցի պահանջներից:
Firewall-ը անհրաժեշտ է, թե ոչ:
Թվում է, թե պատասխանն ակնհայտ է, բայց ամեն ինչ այնքան էլ պարզ չէ, որքան կարող է թվալ։ Եվ ձեր ընտրության վրա կարող են ազդել ոչ միայն գին.
Օրինակ 1: Ուշացումներ.
Եթե ցածր հետաձգումը էական պահանջ է ցանցի որոշ սեգմենտների միջև, ինչը, օրինակ, ճիշտ է փոխանակման դեպքում, ապա մենք չենք կարողանա օգտագործել firewalls այս հատվածների միջև: Դժվար է գտնել ուշացման վերաբերյալ ուսումնասիրություններ firewall-ներում, բայց մի քանի անջատիչ մոդելներ կարող են ապահովել 1 mksec-ից պակաս կամ կարգի ուշացում, այնպես որ, կարծում եմ, եթե միկրովայրկյանները կարևոր են ձեզ համար, ապա firewalls-ը ձեզ համար չէ:
Օրինակ 2: Կատարում:
Վերին L3 անջատիչների թողունակությունը սովորաբար մեծության կարգով ավելի մեծ է, քան ամենահզոր firewalls-ի թողունակությունը: Հետևաբար, բարձր ինտենսիվության երթևեկության դեպքում, ամենայն հավանականությամբ, դուք նույնպես ստիպված կլինեք թույլ տալ, որ այս տրաֆիկը շրջանցի firewalls-ը:
Օրինակ 3: Վստահելիություն:
Firewall-երը, հատկապես ժամանակակից NGFW-ն (Հաջորդ սերնդի FW) բարդ սարքեր են: Նրանք շատ ավելի բարդ են, քան L3/L2 անջատիչները: Նրանք ապահովում են մեծ թվով ծառայություններ և կազմաձևման տարբերակներ, ուստի զարմանալի չէ, որ դրանց հուսալիությունը շատ ավելի ցածր է: Եթե ծառայության շարունակականությունը կարևոր է ցանցի համար, ապա դուք կարող եք ընտրել այն, ինչը կհանգեցնի ավելի լավ հասանելիության՝ անվտանգությունը firewall-ով կամ ցանցի պարզությունը, որը կառուցված է անջատիչների (կամ տարբեր տեսակի գործվածքների) վրա՝ օգտագործելով սովորական ACL-ներ:
Վերոնշյալ օրինակների դեպքում, ամենայն հավանականությամբ, (ինչպես միշտ) ստիպված կլինեք փոխզիջում գտնել: Նայեք հետևյալ լուծումներին.
- եթե որոշեք չօգտագործել firewalls տվյալների կենտրոնի ներսում, ապա դուք պետք է մտածեք, թե ինչպես հնարավորինս սահմանափակել մուտքը պարագծի շուրջ: Օրինակ, դուք կարող եք բացել միայն անհրաժեշտ նավահանգիստները ինտերնետից (հաճախորդի տրաֆիկի համար) և ադմինիստրատիվ մուտք դեպի տվյալների կենտրոն միայն jump host-ներից: Jump hosts-ում կատարեք բոլոր անհրաժեշտ ստուգումները (նույնականացում/լիազորում, հակավիրուսային, գրանցում, ...)
- Դուք կարող եք օգտագործել տվյալների կենտրոնի ցանցի տրամաբանական բաժանումը հատվածների՝ PSEFABRIC-ում նկարագրված սխեմայի նման . Այս դեպքում երթուղավորումը պետք է կազմաձևվի այնպես, որ ուշացման կամ բարձր ինտենսիվության երթևեկությունը գնա մեկ հատվածի «ներսում» (p002, VRF-ի դեպքում) և չանցնի firewall-ով: Տարբեր հատվածների միջև երթևեկությունը կշարունակվի անցնել firewall-ով: Դուք կարող եք նաև օգտագործել երթուղու արտահոսք VRF-ների միջև՝ երթևեկությունը firewall-ի միջոցով վերահղումից խուսափելու համար
- Դուք կարող եք նաև օգտագործել firewall թափանցիկ ռեժիմով և միայն այն VLAN-ների համար, որտեղ այդ գործոնները (latency/performance) էական չեն: Բայց դուք պետք է ուշադիր ուսումնասիրեք այս ռեժիմի օգտագործման հետ կապված սահմանափակումները յուրաքանչյուր վաճառողի համար
- դուք կարող եք մտածել ծառայության շղթայի ճարտարապետության օգտագործման մասին: Սա թույլ կտա միայն անհրաժեշտ տրաֆիկին անցնել firewall-ով: Տեսականորեն գեղեցիկ տեսք ունի, բայց ես երբեք չեմ տեսել այս լուծումը արտադրության մեջ: Մենք փորձարկեցինք Cisco ACI/Juniper SRX/F5 LTM սպասարկման շղթան մոտ 3 տարի առաջ, բայց այն ժամանակ այս լուծումը մեզ «կոպիտ» էր թվում:
Պաշտպանության մակարդակ
Այժմ դուք պետք է պատասխանեք այն հարցին, թե ինչ գործիքներ եք ցանկանում օգտագործել թրաֆիկը զտելու համար: Ահա որոշ առանձնահատկություններ, որոնք սովորաբար առկա են NGFW-ում (օրինակ. ):
- պետական firewalling (կանխադրված)
- հավելվածի firewalling
- սպառնալիքների կանխարգելում (հակավիրուսներ, հակալրտեսող ծրագրեր և խոցելիություն)
- URL զտիչ
- տվյալների զտում (բովանդակության զտում)
- ֆայլերի արգելափակում (ֆայլերի տեսակների արգելափակում)
- dos պաշտպանություն
Եվ ամեն ինչ նույնպես պարզ չէ։ Թվում է, թե որքան բարձր է պաշտպանության մակարդակը, այնքան լավ: Բայց դուք նույնպես պետք է հաշվի առնեք դա
- Որքան շատ վերը նշված firewall գործառույթներն օգտագործեք, այնքան ավելի թանկ կլինի այն բնականաբար (լիցենզիաներ, լրացուցիչ մոդուլներ)
- որոշ ալգորիթմների օգտագործումը կարող է զգալիորեն նվազեցնել firewall թողունակությունը և նաև մեծացնել ձգձգումները, տե՛ս օրինակ.
- ինչպես ցանկացած բարդ լուծում, պաշտպանության բարդ մեթոդների օգտագործումը կարող է նվազեցնել ձեր լուծման հուսալիությունը, օրինակ՝ հավելվածի firewalling-ի օգտագործման ժամանակ ես հանդիպեցի մի քանի բավականին ստանդարտ աշխատանքային հավելվածների արգելափակման (dns, smb)
Ինչպես միշտ, դուք պետք է գտնեք լավագույն լուծումը ձեր ցանցի համար:
Անհնար է միանշանակ պատասխանել այն հարցին, թե ինչ պաշտպանական գործառույթներ կարող են պահանջվել: Նախ, քանի որ դա, իհարկե, կախված է այն տվյալներից, որոնք դուք փոխանցում կամ պահպանում եք և փորձում եք պաշտպանել: Երկրորդ, իրականում հաճախ անվտանգության գործիքների ընտրությունը հավատքի և վաճառողի նկատմամբ վստահության խնդիր է: Դուք չգիտեք ալգորիթմները, չգիտեք, թե որքան արդյունավետ են դրանք և չեք կարող դրանք ամբողջությամբ փորձարկել:
Հետևաբար, կարևոր հատվածներում լավ լուծում կարող է լինել տարբեր ընկերությունների առաջարկներից օգտվելը: Օրինակ, դուք կարող եք միացնել հակավիրուսը firewall-ում, բայց նաև օգտագործել հակավիրուսային պաշտպանություն (այլ արտադրողի կողմից) տեղական հոսթների վրա:
Սեգմենտացիան
Խոսքը տվյալների կենտրոնի ցանցի տրամաբանական սեգմենտավորման մասին է։ Օրինակ, VLAN-ների և ենթացանցերի բաժանումը նույնպես տրամաբանական սեգմենտավորում է, բայց մենք դա չենք դիտարկի իր ակնհայտության պատճառով: Հետաքրքիր հատվածավորում՝ հաշվի առնելով այնպիսի սուբյեկտներ, ինչպիսիք են FW անվտանգության գոտիները, VRF-ները (և դրանց անալոգները տարբեր վաճառողների հետ կապված), տրամաբանական սարքերը (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...
Տրված է նման տրամաբանական սեգմենտավորման և ներկայումս պահանջարկ ունեցող տվյալների կենտրոնի նախագծման օրինակ .
Սահմանելով ձեր ցանցի տրամաբանական մասերը՝ կարող եք այնուհետև նկարագրել, թե ինչպես է երթևեկությունը շարժվում տարբեր հատվածների միջև, որ սարքերի վրա և ինչ միջոցներով կկատարվի զտիչ:
Եթե ձեր ցանցը չունի հստակ տրամաբանական բաժանում, և տվյալների տարբեր հոսքերի համար անվտանգության քաղաքականության կիրառման կանոնները ձևակերպված չեն, դա նշանակում է, որ երբ բացում եք այս կամ այն մուտքը, ստիպված եք լուծել այս խնդիրը, և մեծ հավանականությամբ ամեն անգամ այլ կերպ կլուծի:
Հաճախ հատվածավորումը հիմնված է միայն FW անվտանգության գոտիների վրա: Ապա դուք պետք է պատասխանեք հետևյալ հարցերին.
- ինչ անվտանգության գոտիներ են ձեզ անհրաժեշտ
- ինչ մակարդակի պաշտպանության եք ցանկանում կիրառել այս գոտիներից յուրաքանչյուրի համար
- Արդյո՞ք ներգոտի երթևեկությունը թույլատրվելու է լռելյայն:
- եթե ոչ, երթևեկության զտման ինչպիսի քաղաքականություն կկիրառվի յուրաքանչյուր գոտում
- երթևեկության զտման ինչ քաղաքականություններ կկիրառվեն յուրաքանչյուր զույգ գոտիների համար (աղբյուր/նպատակակետ)
TCAM- ը
Ընդհանուր խնդիր է անբավարար TCAM-ը (Ternary Content Addressable Memory) ինչպես երթուղիների, այնպես էլ մուտքերի համար: IMHO, սա սարքավորումների ընտրության ամենակարեւոր խնդիրներից մեկն է, այնպես որ դուք պետք է համապատասխան խնամքով վերաբերվեք այս հարցին:
Օրինակ 1. Փոխանցման աղյուսակ TCAM:
Եկեք նայենք firewall
Մենք տեսնում ենք, որ IPv4 վերահասցեավորման աղյուսակի չափը* = 32K
Ավելին, երթուղիների այս թիվը ընդհանուր է բոլոր VSYS-ների համար:Ենթադրենք, որ ըստ ձեր դիզայնի դուք որոշում եք օգտագործել 4 VSYS:
Այս VSYS-ներից յուրաքանչյուրը BGP-ի միջոցով միացված է ամպի երկու MPLS PE-ներին, որոնք դուք օգտագործում եք որպես BB: Այսպիսով, 4 VSYS փոխանակում են բոլոր հատուկ երթուղիները միմյանց հետ և ունեն վերահասցեավորման աղյուսակ՝ մոտավորապես նույն երթուղիներով (բայց տարբեր NH-ներով): Որովհետեւ յուրաքանչյուր VSYS ունի 2 BGP նիստ (նույն կարգավորումներով), այնուհետև MPLS-ի միջոցով ստացված յուրաքանչյուր երթուղի ունի 2 NH և, համապատասխանաբար, 2 FIB գրառում Փոխանցման աղյուսակում: Եթե ենթադրենք, որ սա տվյալների կենտրոնի միակ firewall-ն է, և այն պետք է իմանա բոլոր երթուղիների մասին, ապա դա կնշանակի, որ մեր տվյալների կենտրոնում երթուղիների ընդհանուր թիվը չի կարող լինել ավելի քան 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-ն firewall-ների համար, թե՞ տեղադրեմ երկու անկախ տուփեր «զուգահեռաբար», և եթե դրանցից մեկը ձախողվի, երթևեկությունը անցնի երկրորդի միջով:
Թվում է, թե պատասխանն ակնհայտ է՝ օգտագործել HA: Այս հարցի առաջացման պատճառն այն է, որ, ցավոք, գործնականում հասանելիության տեսական և գովազդային 99 և մի քանի տասնորդական տոկոսները հեռու են այդքան վարդագույն լինելուց: HA-ն տրամաբանորեն բավականին բարդ բան է, և տարբեր սարքավորումների վրա և տարբեր վաճառողների հետ (բացառություններ չկային), մենք հայտնաբերեցինք խնդիրներ և սխալներ և սպասարկման կանգառներ:
Եթե դուք օգտագործում եք HA, դուք հնարավորություն կունենաք անջատել առանձին հանգույցները, անցնել նրանց միջև՝ առանց ծառայությունը դադարեցնելու, ինչը կարևոր է, օրինակ, թարմացումներ կատարելիս, բայց միևնույն ժամանակ դուք ունեք զրոյականից հեռու հավանականություն, որ երկու հանգույցներն էլ. միևնույն ժամանակ կխախտվի, և նաև, որ հաջորդ արդիականացումը չի ընթանա այնքան հարթ, որքան խոստանում է վաճառողը (այս խնդիրը կարելի է խուսափել, եթե հնարավորություն ունեք փորձարկել արդիականացումը լաբորատոր սարքավորումների վրա):
Եթե դուք չեք օգտագործում HA, ապա կրկնակի ձախողման տեսանկյունից ձեր ռիսկերը շատ ավելի ցածր են (քանի որ դուք ունեք 2 անկախ firewalls), բայց քանի որ... նիստերը համաժամանակացված չեն, այնուհետև ամեն անգամ, երբ անցնեք այս firewalls-ի միջև, դուք կկորցնեք երթևեկությունը: Դուք, իհարկե, կարող եք օգտագործել քաղաքացիություն չունեցող firewall-ը, բայց հետո firewall-ի օգտագործման իմաստը հիմնականում կորցնում է:
Հետևաբար, եթե աուդիտի արդյունքում դուք հայտնաբերել եք միայնակ firewalls և մտածում եք ձեր ցանցի հուսալիությունը բարձրացնելու մասին, ապա HA-ն, իհարկե, առաջարկվող լուծումներից է, բայց պետք է նաև հաշվի առնել դրա հետ կապված թերությունները. այս մոտեցմամբ և, հավանաբար, հատուկ ձեր ցանցի համար ավելի հարմար կլինի մեկ այլ լուծում:
Կառավարելիություն
Սկզբունքորեն ՀԱ-ն նաև վերահսկելիության մասին է։ Փոխանակ 2 տուփ առանձին կազմաձևելու և կոնֆիգուրացիաները համաժամեցված պահելու խնդրին առնչվելու փոխարեն, դուք կառավարում եք դրանք այնպես, կարծես մեկ սարք ունեք:
Բայց միգուցե դուք ունեք բազմաթիվ տվյալների կենտրոններ և շատ firewalls, ապա այս հարցը ծագում է նոր մակարդակում: Եվ հարցը միայն կոնֆիգուրացիայի մասին չէ, այլ նաև
- պահուստային կոնֆիգուրացիաներ
- թարմացումներ
- բարելավումներ
- մոնիտորինգ
- ծառահատումներ
Եվ այս ամենը կարելի է լուծել կենտրոնացված կառավարման համակարգերով։
Այսպիսով, օրինակ, եթե դուք օգտագործում եք Palo Alto firewalls, ապա այդպիսի լուծում է.
Շարունակելի
Source: www.habr.com