ეს სტატია მესამეა სტატიების სერიიდან „როგორ აიღოთ კონტროლი თქვენი ქსელის ინფრასტრუქტურაზე“. სერიის ყველა სტატიის შინაარსი და ბმულები შეგიძლიათ იხილოთ აქ.

უსაფრთხოების რისკების სრულად აღმოფხვრაზე ლაპარაკს აზრი არ აქვს. პრინციპში მათ ნულამდე ვერ დავამცირებთ. ჩვენ ასევე უნდა გვესმოდეს, რომ როდესაც ჩვენ ვცდილობთ გავხადოთ ქსელი უფრო და უფრო უსაფრთხო, ჩვენი გადაწყვეტილებები უფრო და უფრო ძვირი ხდება. თქვენ უნდა იპოვოთ კომპრომისი ღირებულებას, სირთულესა და უსაფრთხოებას შორის, რაც აზრი აქვს თქვენს ქსელს.

რა თქმა უნდა, უსაფრთხოების დიზაინი ორგანულად არის ინტეგრირებული მთლიან არქიტექტურაში და გამოყენებული უსაფრთხოების გადაწყვეტილებები გავლენას ახდენს ქსელის ინფრასტრუქტურის მასშტაბურობაზე, საიმედოობაზე, მართვადობაზე, ..., რაც ასევე უნდა იქნას გათვალისწინებული.

მაგრამ შეგახსენებთ, რომ ახლა ჩვენ არ ვსაუბრობთ ქსელის შექმნაზე. ჩვენის მიხედვით საწყისი პირობები ჩვენ უკვე ავირჩიეთ დიზაინი, შევარჩიეთ აღჭურვილობა და შევქმენით ინფრასტრუქტურა და ამ ეტაპზე, თუ შესაძლებელია, უნდა „ვიცხოვროთ“ და ვიპოვოთ გადაწყვეტილებები ადრე არჩეული მიდგომის კონტექსტში.

ახლა ჩვენი ამოცანაა ქსელის დონეზე უსაფრთხოებასთან დაკავშირებული რისკების იდენტიფიცირება და მათი გონივრულ დონეზე შემცირება.

ქსელის უსაფრთხოების აუდიტი

თუ თქვენს ორგანიზაციას აქვს დანერგილი ISO 27k პროცესები, მაშინ უსაფრთხოების აუდიტი და ქსელის ცვლილებები შეუფერხებლად უნდა მოერგოს ამ მიდგომის საერთო პროცესებს. მაგრამ ეს სტანდარტები ჯერ კიდევ არ ეხება კონკრეტულ გადაწყვეტილებებს, არც კონფიგურაციას, არც დიზაინს... არ არსებობს მკაფიო რჩევა, არ არსებობს სტანდარტები, რომლებიც დეტალურად კარნახობს როგორი უნდა იყოს თქვენი ქსელი, ეს არის ამ ამოცანის სირთულე და სილამაზე.

მე გამოვყოფდი ქსელის უსაფრთხოების რამდენიმე შესაძლო აუდიტს:

• აღჭურვილობის კონფიგურაციის აუდიტი (გამკვრივება)
• უსაფრთხოების დიზაინის აუდიტი
• წვდომის აუდიტი
• პროცესის აუდიტი

აღჭურვილობის კონფიგურაციის აუდიტი (გამკვრივება)

როგორც ჩანს, უმეტეს შემთხვევაში ეს არის საუკეთესო საწყისი წერტილი თქვენი ქსელის აუდიტისა და უსაფრთხოების გასაუმჯობესებლად. IMHO, ეს არის პარეტოს კანონის კარგი დემონსტრირება (ძალისხმევის 20% იძლევა შედეგის 80%-ს, ხოლო დანარჩენი 80% შრომის მხოლოდ 20%-ს იძლევა).

დასკვნა ის არის, რომ ჩვენ ჩვეულებრივ გვაქვს რეკომენდაციები გამყიდველებისგან აღჭურვილობის კონფიგურაციისას უსაფრთხოების „საუკეთესო პრაქტიკის“ შესახებ. ამას ეწოდება "გამკვრივება".

თქვენ ასევე შეგიძლიათ ხშირად იპოვოთ კითხვარი (ან თავად შექმნათ) ამ რეკომენდაციებზე დაყრდნობით, რომელიც დაგეხმარებათ განსაზღვროთ რამდენად შეესაბამება თქვენი აღჭურვილობის კონფიგურაცია ამ „საუკეთესო პრაქტიკას“ და, შედეგის შესაბამისად, შეიტანოთ ცვლილებები თქვენს ქსელში. . ეს საშუალებას მოგცემთ მნიშვნელოვნად შეამციროთ უსაფრთხოების რისკები საკმაოდ მარტივად, პრაქტიკულად ყოველგვარი ხარჯების გარეშე.

რამდენიმე მაგალითი Cisco-ს ზოგიერთი ოპერაციული სისტემისთვის.

Cisco IOS კონფიგურაციის გამკვრივება
Cisco IOS-XR კონფიგურაციის გამკვრივება
Cisco NX-OS კონფიგურაციის გამკვრივება
Cisco Baseline უსაფრთხოების შემოწმების სია

ამ დოკუმენტებზე დაყრდნობით, შეიძლება შეიქმნას კონფიგურაციის მოთხოვნების სია თითოეული ტიპის აღჭურვილობისთვის. მაგალითად, Cisco N7K VDC-სთვის ეს მოთხოვნები შეიძლება გამოიყურებოდეს ასე.

ამ გზით, კონფიგურაციის ფაილები შეიძლება შეიქმნას თქვენი ქსელის ინფრასტრუქტურის სხვადასხვა ტიპის აქტიური აღჭურვილობისთვის. შემდეგი, ხელით ან ავტომატიზაციის გამოყენებით, შეგიძლიათ "ატვირთოთ" ეს კონფიგურაციის ფაილები. როგორ მოხდეს ამ პროცესის ავტომატიზაცია, დეტალურად იქნება განხილული სტატიების სხვა სერიაში ორკესტრირებისა და ავტომატიზაციის შესახებ.

უსაფრთხოების დიზაინის აუდიტი

როგორც წესი, საწარმოს ქსელი შეიცავს შემდეგ სეგმენტებს ამა თუ იმ ფორმით:

• DC (საჯარო სერვისების DMZ ​​და ინტრანეტის მონაცემთა ცენტრი)
• ინტერნეტის ხელმისაწვდომობა
• დისტანციური წვდომა VPN
• WAN ზღვარი
• ფილიალი
• კამპუსი (ოფისი)
• Core

სათაურები აღებულია Cisco SAFE მოდელი, მაგრამ არ არის აუცილებელი, რა თქმა უნდა, ზუსტად დაერთოს ამ სახელებს და ამ მოდელს. მაინც მინდა არსზე ვისაუბრო და ფორმალობაში არ ჩავიძირო.

თითოეული ამ სეგმენტისთვის უსაფრთხოების მოთხოვნები, რისკები და, შესაბამისად, გადაწყვეტილებები განსხვავებული იქნება.

მოდით შევხედოთ თითოეულ მათგანს ცალკე იმ პრობლემებისთვის, რომლებიც შეიძლება შეგხვდეთ უსაფრთხოების დიზაინის თვალსაზრისით. რასაკვირველია, კიდევ ერთხელ ვიმეორებ, რომ ეს სტატია არავითარ შემთხვევაში არ წარმოადგენს სრულყოფილ პრეტენზიას, რომლის მიღწევა არც ისე ადვილია (თუ შეუძლებელი) ამ მართლაც ღრმა და მრავალმხრივ თემაში, მაგრამ ის ასახავს ჩემს პირად გამოცდილებას.

სრულყოფილი გამოსავალი არ არსებობს (ყოველ შემთხვევაში, ჯერ არა). ეს ყოველთვის კომპრომისია. მაგრამ მნიშვნელოვანია, რომ ამა თუ იმ მიდგომის გამოყენების გადაწყვეტილება მიღებული იყოს შეგნებულად, მისი დადებითი და უარყოფითი მხარეების გაგებით.

მონაცემთა ცენტრი

ყველაზე კრიტიკული სეგმენტი უსაფრთხოების თვალსაზრისით.
და, როგორც ყოველთვის, აქაც არ არის უნივერსალური გადაწყვეტა. ეს ყველაფერი დიდწილად დამოკიდებულია ქსელის მოთხოვნებზე.

Firewall აუცილებელია თუ არა?

როგორც ჩანს, პასუხი აშკარაა, მაგრამ ყველაფერი არც ისე ნათელია, როგორც შეიძლება ჩანდეს. და თქვენს არჩევანზე შეიძლება გავლენა იქონიოს არა მხოლოდ ფასი.

მაგალითი 1. დაგვიანებები.

თუ დაბალი შეყოვნება არის არსებითი მოთხოვნა ქსელის ზოგიერთ სეგმენტს შორის, რაც, მაგალითად, მართალია გაცვლის შემთხვევაში, მაშინ ჩვენ ვერ შევძლებთ ამ სეგმენტებს შორის ფაირვოლების გამოყენებას. ძნელია იპოვოთ კვლევები შეყოვნების შესახებ ფაირვოლებში, მაგრამ რამდენიმე გადართვის მოდელს შეუძლია უზრუნველყოს შეყოვნება 1 მკსკზე ნაკლები ან მისი რიგითობით, ასე რომ, ვფიქრობ, თუ მიკროწამები თქვენთვის მნიშვნელოვანია, მაშინ ფაირვოლები თქვენთვის არ არის.

მაგალითი 2. შესრულება.

ზედა L3 გადამრთველების გამტარუნარიანობა, როგორც წესი, უფრო მაღალია, ვიდრე ყველაზე მძლავრი ბუხარის გამტარუნარიანობა. ამიტომ, მაღალი ინტენსივობის ტრაფიკის შემთხვევაში, თქვენ ასევე მოგიწევთ ამ ტრაფიკის გვერდის ავლით ნება დართოთ firewall-ებს.

მაგალითი 3. საიმედოობის.

Firewalls, განსაკუთრებით თანამედროვე NGFW (შემდეგი თაობის FW) რთული მოწყობილობებია. ისინი ბევრად უფრო რთულია ვიდრე L3/L2 კონცენტრატორები. ისინი უზრუნველყოფენ უამრავ მომსახურებას და კონფიგურაციის ვარიანტებს, ამიტომ გასაკვირი არ არის, რომ მათი საიმედოობა გაცილებით დაბალია. თუ სერვისის უწყვეტობა გადამწყვეტია ქსელისთვის, მაშინ შეიძლება მოგიწიოთ არჩევანის გაკეთება, რაც გამოიწვევს უკეთეს ხელმისაწვდომობას - უსაფრთხოება firewall-ით ან ქსელის სიმარტივე, რომელიც აგებულია გადამრთველებზე (ან სხვადასხვა სახის ქსოვილებზე) რეგულარული ACL-ების გამოყენებით.

ზემოთ მოყვანილი მაგალითების შემთხვევაში, დიდი ალბათობით (როგორც ყოველთვის) მოგიწევთ კომპრომისის პოვნა. გადახედეთ შემდეგ გადაწყვეტილებებს:

• თუ გადაწყვეტთ არ გამოიყენოთ ბუხარი მონაცემთა ცენტრის შიგნით, მაშინ უნდა იფიქროთ იმაზე, თუ როგორ შეზღუდოთ წვდომა პერიმეტრის გარშემო მაქსიმალურად. მაგალითად, თქვენ შეგიძლიათ გახსნათ მხოლოდ საჭირო პორტები ინტერნეტიდან (კლიენტის ტრაფიკისთვის) და ადმინისტრაციული წვდომა მონაცემთა ცენტრში მხოლოდ ნახტომი ჰოსტებისგან. გადახტომის ჰოსტებზე, შეასრულეთ ყველა საჭირო შემოწმება (ავთენტიფიკაცია/ავტორიზაცია, ანტივირუსი, შესვლა, ...)
• შეგიძლიათ გამოიყენოთ მონაცემთა ცენტრის ქსელის ლოგიკური დანაყოფი სეგმენტებად, PSEFABRIC-ში აღწერილი სქემის მსგავსი მაგალითი p002. ამ შემთხვევაში, მარშრუტიზაცია უნდა იყოს კონფიგურირებული ისე, რომ შეფერხებისადმი მგრძნობიარე ან მაღალი ინტენსივობის ტრაფიკი გადავიდეს ერთ სეგმენტში (p002, VRF-ის შემთხვევაში) და არ გაიაროს firewall-ში. ტრაფიკი სხვადასხვა სეგმენტებს შორის გაგრძელდება Firewall-ით. თქვენ ასევე შეგიძლიათ გამოიყენოთ მარშრუტის გაჟონვა VRF-ებს შორის, რათა თავიდან აიცილოთ ტრაფიკის გადამისამართება Firewall-ში
• თქვენ ასევე შეგიძლიათ გამოიყენოთ firewall გამჭვირვალე რეჟიმში და მხოლოდ იმ VLAN-ებისთვის, სადაც ეს ფაქტორები (დაყოვნება/შესრულება) არ არის მნიშვნელოვანი. მაგრამ თქვენ უნდა ყურადღებით შეისწავლოთ შეზღუდვები, რომლებიც დაკავშირებულია ამ რეჟიმის გამოყენებასთან თითოეული გამყიდველისთვის
• შეგიძლიათ განიხილოთ მომსახურების ჯაჭვის არქიტექტურის გამოყენება. ეს საშუალებას მისცემს მხოლოდ საჭირო ტრაფიკს გაიაროს firewall-ში. თეორიულად კარგად გამოიყურება, მაგრამ მე არასოდეს მინახავს ეს გამოსავალი წარმოებაში. ჩვენ გამოვცადეთ სერვისის ჯაჭვი Cisco ACI/Juniper SRX/F5 LTM-სთვის დაახლოებით 3 წლის წინ, მაგრამ იმ დროს ეს გამოსავალი ჩვენთვის „უხეში“ ჩანდა.

დაცვის დონე

ახლა თქვენ უნდა უპასუხოთ კითხვას, თუ რა ინსტრუმენტების გამოყენება გსურთ ტრაფიკის გასაფილტრად. აქ არის რამოდენიმე მახასიათებელი, რომელიც ჩვეულებრივ გვხვდება NGFW-ში (მაგალითად, აქ):

• stateful firewalling (ნაგულისხმევი)
• განაცხადის firewalling
• საფრთხის პრევენცია (ანტივირუსი, ანტი-სპივერი და დაუცველობა)
• URL გაფილტვრა
• მონაცემთა ფილტრაცია (შინაარსის ფილტრაცია)
• ფაილის დაბლოკვა (ფაილის ტიპების დაბლოკვა)
• dos დაცვა

და არც ყველაფერი ნათელია. როგორც ჩანს, რაც უფრო მაღალია დაცვის დონე, მით უკეთესი. მაგრამ თქვენ ასევე უნდა გაითვალისწინოთ ეს

• რაც უფრო მეტს იყენებთ ზემოაღნიშნული firewall ფუნქციას, მით უფრო ძვირი იქნება ის ბუნებრივია (ლიცენზიები, დამატებითი მოდულები)
• ზოგიერთი ალგორითმის გამოყენებამ შეიძლება მნიშვნელოვნად შეამციროს firewall გამტარუნარიანობა და ასევე გაზარდოს შეფერხებები, იხილეთ მაგალითად აქ
• ნებისმიერი რთული გადაწყვეტის მსგავსად, კომპლექსური დაცვის მეთოდების გამოყენებამ შეიძლება შეამციროს თქვენი გადაწყვეტის სანდოობა, მაგალითად, აპლიკაციის firewalling-ის გამოყენებისას, მე შევხვდი რამდენიმე საკმაოდ სტანდარტული სამუშაო აპლიკაციის დაბლოკვას (dns, smb)

როგორც ყოველთვის, თქვენ უნდა იპოვოთ საუკეთესო გამოსავალი თქვენი ქსელისთვის.

შეუძლებელია საბოლოო პასუხის გაცემა კითხვაზე, თუ რა დამცავი ფუნქციები შეიძლება იყოს საჭირო. პირველ რიგში, იმიტომ, რომ ეს, რა თქმა უნდა, დამოკიდებულია იმ მონაცემებზე, რომლებსაც გადასცემთ ან ინახავთ და ცდილობთ მის დაცვას. მეორეც, სინამდვილეში, ხშირად უსაფრთხოების ინსტრუმენტების არჩევანი გამყიდველისადმი რწმენისა და ნდობის საკითხია. თქვენ არ იცით ალგორითმები, არ იცით რამდენად ეფექტურია ისინი და არ შეგიძლიათ სრულად შეამოწმოთ ისინი.

ამიტომ, კრიტიკულ სეგმენტებში კარგი გამოსავალი შეიძლება იყოს სხვადასხვა კომპანიის შეთავაზებების გამოყენება. მაგალითად, შეგიძლიათ ჩართოთ ანტივირუსი firewall-ზე, მაგრამ ასევე გამოიყენოთ ანტივირუსული დაცვა (სხვა მწარმოებლისგან) ლოკალურად ჰოსტებზე.

სეგმენტაცია

საუბარია მონაცემთა ცენტრის ქსელის ლოგიკურ სეგმენტაციაზე. მაგალითად, VLAN და ქვექსელებად დაყოფა ასევე ლოგიკური სეგმენტაციაა, მაგრამ ჩვენ არ განვიხილავთ მას აშკარად. საინტერესო სეგმენტაცია ისეთი ერთეულების გათვალისწინებით, როგორიცაა FW უსაფრთხოების ზონები, VRF (და მათი ანალოგები სხვადასხვა გამყიდველებთან მიმართებაში), ლოგიკური მოწყობილობები (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...

მოცემულია ასეთი ლოგიკური სეგმენტაციის მაგალითი და ამჟამად მოთხოვნადი მონაცემთა ცენტრის დიზაინი PSEFABRIC პროექტის p002.

თქვენი ქსელის ლოგიკური ნაწილების განსაზღვრის შემდეგ, შეგიძლიათ აღწეროთ როგორ მოძრაობს ტრაფიკი სხვადასხვა სეგმენტებს შორის, რომელ მოწყობილობებზე განხორციელდება ფილტრაცია და რა საშუალებებით.

თუ თქვენს ქსელს არ აქვს მკაფიო ლოგიკური დანაყოფი და მონაცემთა სხვადასხვა ნაკადისთვის უსაფრთხოების პოლიტიკის გამოყენების წესები არ არის ფორმალიზებული, ეს ნიშნავს, რომ როდესაც გახსნით ამა თუ იმ წვდომას, იძულებული ხართ მოაგვაროთ ეს პრობლემა და დიდი ალბათობით თქვენ ყოველ ჯერზე სხვანაირად გადაჭრის.

ხშირად სეგმენტაცია ეფუძნება მხოლოდ FW უსაფრთხოების ზონებს. შემდეგ თქვენ უნდა უპასუხოთ შემდეგ კითხვებს:

• რა უსაფრთხოების ზონები გჭირდებათ
• რა დონის დაცვა გსურთ გამოიყენოთ თითოეულ ამ ზონაზე
• დაიშვება თუ არა შიდა ზონაში მოძრაობა ნაგულისხმევად?
• თუ არა, რა ტრაფიკის ფილტრაციის პოლიტიკა იქნება გამოყენებული თითოეულ ზონაში
• რა ტრაფიკის ფილტრაციის პოლიტიკა იქნება გამოყენებული თითოეული წყვილი ზონისთვის (წყარო/დანიშნულება)

TCAM

საერთო პრობლემაა არასაკმარისი TCAM (Ternary Content Addressable Memory), როგორც მარშრუტიზაციისთვის, ასევე წვდომისთვის. IMHO, ეს არის ერთ-ერთი ყველაზე მნიშვნელოვანი საკითხი აღჭურვილობის არჩევისას, ამიტომ ამ საკითხს სათანადო ზრუნვით უნდა მოეპყროთ.

მაგალითი 1. გადამისამართების ცხრილი TCAM.

განვიხილოთ პალო ალტო 7კ 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 ფაიერვოლებისთვის თუ დავაყენო ორი დამოუკიდებელი ყუთი „პარალელურად“ და, თუ ერთ-ერთი მათგანი ვერ მოხერხდა, ტრაფიკი მეორეში გავატარო?

როგორც ჩანს, პასუხი აშკარაა - გამოიყენეთ HA. მიზეზი, რის გამოც ეს კითხვა ჯერ კიდევ ჩნდება, არის ის, რომ, სამწუხაროდ, თეორიული და სარეკლამო 99 და რამდენიმე ათობითი პროცენტი პრაქტიკაში შორს არის ასეთი ვარდისფერი. HA ლოგიკურად საკმაოდ რთული რამ არის და სხვადასხვა აღჭურვილობაზე და სხვადასხვა გამყიდველთან ერთად (არ იყო გამონაკლისი), ჩვენ დავიჭირეთ პრობლემები და შეცდომები და სერვისის გაჩერება.

თუ იყენებთ HA-ს, გექნებათ შესაძლებლობა გამორთოთ ცალკეული კვანძები, გადახვიდეთ მათ შორის სერვისის შეწყვეტის გარეშე, რაც მნიშვნელოვანია, მაგალითად, განახლებების შესრულებისას, მაგრამ ამავე დროს თქვენ გაქვთ ნულოვანი ალბათობა, რომ ორივე კვანძი გაფუჭდება ამავე დროს, და ასევე, რომ შემდეგი განახლება არ განხორციელდება ისე შეუფერხებლად, როგორც გამყიდველი გვპირდება (ამ პრობლემის თავიდან აცილება შესაძლებელია, თუ გექნებათ შესაძლებლობა შეამოწმოთ განახლება ლაბორატორიულ აღჭურვილობაზე).

თუ არ იყენებთ HA-ს, მაშინ ორმაგი წარუმატებლობის თვალსაზრისით თქვენი რისკები გაცილებით დაბალია (რადგან თქვენ გაქვთ 2 დამოუკიდებელი ფირვოლი), მაგრამ ვინაიდან... სესიები არ არის სინქრონიზებული, მაშინ ყოველ ჯერზე, როდესაც გადართავთ ამ ფეიერვოლებს შორის, თქვენ დაკარგავთ ტრაფიკს. თქვენ, რა თქმა უნდა, შეგიძლიათ გამოიყენოთ მოქალაქეობის არმქონე ფაიერვოლინგი, მაგრამ შემდეგ ფაირვოლ-ის გამოყენების აზრი დიდწილად დაიკარგება.

ამიტომ, თუ აუდიტის შედეგად აღმოაჩინეთ მარტოხელა ფარები და ფიქრობთ თქვენი ქსელის საიმედოობის გაზრდაზე, მაშინ HA, რა თქმა უნდა, ერთ-ერთი რეკომენდებული გამოსავალია, მაგრამ ასევე უნდა გაითვალისწინოთ დაკავშირებული უარყოფითი მხარეები. ამ მიდგომით და, შესაძლოა, კონკრეტულად თქვენი ქსელისთვის, სხვა გამოსავალი უფრო შესაფერისი იქნება.

მართვადობა

პრინციპში, HA ასევე ეხება კონტროლირებადობას. იმის ნაცვლად, რომ ცალ-ცალკე დააკონფიგურიროთ 2 ყუთი და გაუმკლავდეთ კონფიგურაციების სინქრონიზაციის პრობლემას, თქვენ მათ ისე მართავთ, თითქოს ერთი მოწყობილობა გქონდეთ.

მაგრამ, შესაძლოა, თქვენ გაქვთ მრავალი მონაცემთა ცენტრი და ბევრი ბუხარი, მაშინ ეს კითხვა ჩნდება ახალ დონეზე. და კითხვა ეხება არა მხოლოდ კონფიგურაციას, არამედ

• სარეზერვო კონფიგურაციები
• განახლებები
• განახლებები
• მონიტორინგი
• ჭრის

და ეს ყველაფერი შეიძლება გადაწყდეს ცენტრალიზებული მართვის სისტემებით.

ასე რომ, მაგალითად, თუ იყენებთ Palo Alto firewalls-ს, მაშინ ნახვა არის ასეთი გამოსავალი.

გაგრძელდება.

წყარო: www.habr.com