Энэ нийтлэл нь "Сүлжээний дэд бүтцээ хэрхэн хянах вэ" цуврал нийтлэлийн гурав дахь нь юм. Цуврал дахь бүх нийтлэлийн агуулга, холбоосыг олж болно энд.

Аюулгүй байдлын эрсдэлийг бүрмөсөн арилгана гэж ярих нь утгагүй. Зарчмын хувьд бид тэдгээрийг тэг болгож чадахгүй. Сүлжээг улам бүр аюулгүй болгохыг хичээх тусам бидний шийдэл улам бүр үнэтэй болж байгааг бид ойлгох хэрэгтэй. Та сүлжээндээ утга учиртай зардал, нарийн төвөгтэй байдал, аюулгүй байдлын хоорондох солилцоог олох хэрэгтэй.

Мэдээжийн хэрэг, хамгаалалтын дизайн нь ерөнхий архитектурт органик байдлаар нэгдсэн бөгөөд ашигласан хамгаалалтын шийдлүүд нь сүлжээний дэд бүтцийн өргөтгөх чадвар, найдвартай байдал, удирдах чадвар, ... зэрэгт нөлөөлдөг бөгөөд үүнийг бас анхаарч үзэх хэрэгтэй.

Гэхдээ одоо сүлжээ бий болгох тухай яриагүй гэдгийг сануулъя. Бидний хэлснээр анхны нөхцөл Бид дизайныг аль хэдийн сонгож, тоног төхөөрөмжөө сонгож, дэд бүтцийг бий болгосон бөгөөд энэ үе шатанд боломжтой бол өмнө нь сонгосон арга барилын хүрээнд "амьдарч", шийдлийг олох хэрэгтэй.

Одоо бидний хийх ажил бол сүлжээний түвшинд аюулгүй байдалтай холбоотой эрсдлийг тодорхойлж, боломжийн хэмжээнд хүртэл бууруулах явдал юм.

Сүлжээний аюулгүй байдлын аудит

Хэрэв танай байгууллага ISO 27k процессыг хэрэгжүүлсэн бол аюулгүй байдлын аудит болон сүлжээний өөрчлөлтүүд нь энэ аргын хүрээнд ерөнхий процесст бүрэн нийцэх ёстой. Гэхдээ эдгээр стандартууд нь тодорхой шийдлүүдийн тухай биш, тохиргооны тухай биш, дизайны тухай биш хэвээр байна ... Таны сүлжээ ямар байх ёстойг нарийвчлан зааж өгсөн тодорхой зөвлөмж, стандарт байхгүй, энэ бол энэ ажлын нарийн төвөгтэй байдал, гоо үзэсгэлэн юм.

Би хэд хэдэн боломжит сүлжээний аюулгүй байдлын аудитыг онцлон тэмдэглэх болно:

• тоног төхөөрөмжийн тохиргооны аудит (хатууруулах)
• аюулгүй байдлын дизайны аудит
• хандалтын аудит
• үйл явцын аудит

Тоног төхөөрөмжийн тохиргооны аудит (хатууруулах)

Ихэнх тохиолдолд энэ нь таны сүлжээний аюулгүй байдлыг шалгах, сайжруулах хамгийн сайн эхлэл юм. IMHO, энэ бол Паретогийн хуулийн сайн нотолгоо юм (хүч чармайлтын 20% нь үр дүнгийн 80%, үлдсэн 80% нь үр дүнгийн 20% -ийг л гаргадаг).

Хамгийн гол нь бид ихэвчлэн тоног төхөөрөмжийг тохируулахдаа аюулгүй байдлын талаар "шилдэг туршлагууд"-ын талаар үйлдвэрлэгчдээс зөвлөмж өгдөг. Үүнийг "хатуурах" гэж нэрлэдэг.

Та мөн эдгээр зөвлөмжид үндэслэн санал асуулгын хуудсыг олох боломжтой (эсвэл өөрөө үүсгэх) бөгөөд энэ нь таны төхөөрөмжийн тохиргоо эдгээр "шилдэг туршлага" -тай хэр нийцэж байгааг тодорхойлоход туслах бөгөөд үр дүнд нь тохируулан сүлжээндээ өөрчлөлт оруулахад тусална. . Энэ нь аюулгүй байдлын эрсдлийг маш амархан, бараг ямар ч зардалгүйгээр бууруулах боломжийг танд олгоно.

Зарим Cisco үйлдлийн системүүдийн хэд хэдэн жишээ.

Cisco IOS тохиргооны хатуужилт
Cisco IOS-XR тохиргооны хатуужилт
Cisco NX-OS тохиргооны хатуужилт
Cisco үндсэн аюулгүй байдлын шалгалтын жагсаалт

Эдгээр баримт бичигт үндэслэн тоног төхөөрөмжийн төрөл бүрийн тохиргоонд тавигдах шаардлагуудын жагсаалтыг гаргаж болно. Жишээлбэл, Cisco N7K VDC-ийн хувьд эдгээр шаардлага нь иймэрхүү харагдаж болно тэгээд.

Ийм байдлаар сүлжээний дэд бүтцэд байгаа янз бүрийн төрлийн идэвхтэй төхөөрөмжид тохируулгын файлуудыг үүсгэж болно. Дараа нь гараар эсвэл автоматжуулалтыг ашиглан эдгээр тохиргооны файлуудыг "байршуулж" болно. Энэ үйл явцыг хэрхэн автоматжуулах талаар зохион байгуулалт, автоматжуулалтын талаархи өөр цуврал нийтлэлд дэлгэрэнгүй авч үзэх болно.

Аюулгүй байдлын дизайны аудит

Ихэвчлэн аж ахуйн нэгжийн сүлжээ нь нэг хэлбэрээр дараах сегментүүдийг агуулдаг:

• DC (Төрийн үйлчилгээний DMZ ба дотоод сүлжээ мэдээллийн төв)
• Интернэт хандалт
• Алсын хандалтын VPN
• WAN ирмэг
• салбар
• Кампус (Оффис)
• Core

Гарчигнаас авсан Cisco АЮУЛГҮЙ загвар, гэхдээ мэдээжийн хэрэг, эдгээр нэрс болон энэ загварт яг таг хавсаргах шаардлагагүй. Гэсэн хэдий ч би мөн чанарын талаар ярихыг хүсч, албан ёсны асуудалд гацахгүй байхыг хүсч байна.

Эдгээр сегмент бүрийн хувьд аюулгүй байдлын шаардлага, эрсдэл, үүний дагуу шийдлүүд өөр байх болно.

Аюулгүй байдлын дизайны үүднээс танд тулгарч болох асуудлуудыг тус тусад нь авч үзье. Мэдээжийн хэрэг, энэ нийтлэл нь бүрэн дүүрэн мэт дүр эсгэдэггүй бөгөөд энэ нь үнэхээр гүн гүнзгий, олон талт сэдвээр хүрэхэд хялбар биш (хэрэв боломжгүй бол) боловч энэ нь миний хувийн туршлагыг тусгасан гэдгийг би дахин давтан хэлье.

Төгс шийдэл байхгүй (ядаж л хараахан болоогүй). Энэ нь үргэлж буулт хийдэг. Гэхдээ аль нэг хандлагыг ашиглах шийдвэрийг ухамсартайгаар гаргаж, түүний давуу болон сул талуудыг ойлгох нь чухал юм.

Мэдээллийн төв

Аюулгүй байдлын үүднээс авч үзвэл хамгийн чухал сегмент.
Мөн ердийнх шиг энд бас бүх нийтийн шийдэл байдаггүй. Энэ бүхэн сүлжээний шаардлагаас ихээхэн хамаарна.

Галт хана шаардлагатай юу, үгүй ​​юу?

Хариулт нь тодорхой юм шиг санагдаж байгаа ч бүх зүйл тийм ч тодорхой биш байна. Мөн таны сонголт зөвхөн нөлөөлж чадахгүй үнэ.

Жишээ 1. Саатал.

Хэрэв бага хоцрогдол нь сүлжээний зарим сегментүүдийн хоорондох чухал шаардлага юм бол жишээлбэл солилцооны хувьд үнэн бол бид эдгээр сегментүүдийн хооронд галт ханыг ашиглах боломжгүй болно. Галт хананы хоцрогдлын талаарх судалгааг олоход хэцүү байдаг ч цөөн хэдэн шилжүүлэгч загвар нь 1 мкссек-ээс бага буюу түүнээс бага хоцролтыг хангаж чаддаг тул хэрэв микросекунд танд чухал бол галт хана танд тохирохгүй гэж би бодож байна.

Жишээ 2. Гүйцэтгэл.

Дээд талын L3 унтраалгауудын дамжуулах чадвар нь ихэвчлэн хамгийн хүчирхэг галт хананы нэвтрүүлэх чадвараас өндөр байдаг. Тиймээс, өндөр эрчимтэй замын хөдөлгөөний хувьд та энэ урсгалыг галт ханыг тойрч гарахыг зөвшөөрөх хэрэгтэй болно.

Жишээ 3. Найдвартай байдал.

Галт хана, ялангуяа орчин үеийн NGFW (Next-Generation FW) нь нарийн төвөгтэй төхөөрөмж юм. Эдгээр нь L3/L2 шилжүүлэгчээс хамаагүй илүү төвөгтэй байдаг. Тэд олон тооны үйлчилгээ, тохиргооны сонголтыг санал болгодог тул найдвартай байдал нь хамаагүй бага байдаг нь гайхах зүйл биш юм. Хэрэв үйлчилгээний тасралтгүй байдал нь сүлжээнд чухал ач холбогдолтой бол та галт хана бүхий аюулгүй байдал эсвэл ердийн ACL ашиглан унтраалга (эсвэл янз бүрийн төрлийн даавуу) дээр суурилуулсан сүлжээний энгийн байдлыг илүү сайн байлгахад юу хүргэхийг сонгох хэрэгтэй.

Дээрх жишээнүүдийн хувьд та (ердийнх шиг) буулт хийх хэрэгтэй болно. Дараах шийдлүүдийг анхаарч үзээрэй.

• Хэрэв та мэдээллийн төв дотор галт ханыг ашиглахгүй байхаар шийдсэн бол периметрийн эргэн тойронд нэвтрэх эрхийг аль болох хязгаарлах талаар бодох хэрэгтэй. Жишээлбэл, та зөвхөн интернетээс шаардлагатай портуудыг (үйлчлүүлэгчийн урсгалд зориулж) нээж, мэдээллийн төв рүү зөвхөн jump host-оос захиргааны хандалт хийх боломжтой. Jurass hosts дээр шаардлагатай бүх шалгалтыг (гэрчлэлт/зөвшөөрөл, вирусны эсрэг, бүртгэл хөтлөх, ...) гүйцэтгэнэ.
• та PSEFABRIC-д тайлбарласан схемтэй төстэй сегментүүдэд өгөгдлийн төвийн сүлжээний логик хуваалтыг ашиглаж болно. жишээ p002. Энэ тохиолдолд чиглүүлэлт нь саатал мэдрэмтгий эсвэл өндөр эрчимтэй урсгал нь нэг сегмент дотор (p002, VRF тохиолдолд) "дотор" орж, галт ханаар дамжихгүй байхаар тохируулагдсан байх ёстой. Янз бүрийн сегментүүдийн хоорондох урсгал галт ханаар дамжин өнгөрөх болно. Та мөн галт ханаар дамжуулан траффикийг дахин чиглүүлэхээс зайлсхийхийн тулд VRF-ийн хооронд алдагдах замыг ашиглаж болно
• Та мөн галт ханыг ил тод горимд, зөвхөн эдгээр хүчин зүйлс (хоцролт/гүйцэтгэл) ач холбогдолгүй VLAN-д ашиглаж болно. Гэхдээ та үйлдвэрлэгч бүрийн хувьд энэ горимыг ашиглахтай холбоотой хязгаарлалтыг сайтар судлах хэрэгтэй
• Та үйлчилгээний сүлжээний архитектурыг ашиглах талаар бодож магадгүй. Энэ нь зөвхөн шаардлагатай урсгалыг галт ханаар дамжин өнгөрөх боломжийг олгоно. Онолын хувьд сайхан харагдаж байна, гэхдээ би ийм шийдлийг үйлдвэрлэлд хэзээ ч харж байгаагүй. Бид 5 жилийн өмнө Cisco ACI/Juniper SRX/F3 LTM-ийн үйлчилгээний сүлжээг туршиж үзсэн боловч тухайн үед энэ шийдэл нь бидэнд "бүдүүлэг" мэт санагдаж байсан.

Хамгаалалтын түвшин

Одоо та замын хөдөлгөөний шүүлтүүрийг ямар хэрэгсэл ашиглахыг хүсч байна вэ гэсэн асуултанд хариулах хэрэгтэй. NGFW-д ихэвчлэн байдаг зарим шинж чанарууд энд байна (жишээлбэл, энд):

• төлөвтэй галт хана (өгөгдмөл)
• програмын галт хана
• аюулаас урьдчилан сэргийлэх (вирусны эсрэг, тагнуулын эсрэг програм, эмзэг байдал)
• URL шүүлтүүр
• өгөгдөл шүүх (агуулгын шүүлтүүр)
• файлыг хориглох (файлын төрлийг хориглох)
• хамгаалах

Мөн бүх зүйл тодорхой биш байна. Хамгаалалтын түвшин өндөр байх тусмаа сайн юм шиг санагддаг. Гэхдээ та үүнийг бас анхаарч үзэх хэрэгтэй

• Дээрх галт ханын функцийг ашиглах тусам илүү үнэтэй байх болно (лиценз, нэмэлт модулиуд)
• Зарим алгоритмыг ашиглах нь галт ханын дамжуулалтыг мэдэгдэхүйц бууруулж, саатлыг нэмэгдүүлэх боломжтой. энд
• Аливаа нарийн төвөгтэй шийдлийн нэгэн адил хамгаалалтын нарийн төвөгтэй аргуудыг ашиглах нь таны шийдлийн найдвартай байдлыг бууруулж болно, жишээлбэл, програмын галт ханыг ашиглах үед би нэлээд стандарт ажилладаг зарим програмуудыг (dns, smb) хаахтай тулгарсан.

Ердийнх шигээ та сүлжээндээ хамгийн сайн шийдлийг олох хэрэгтэй.

Ямар хамгаалалтын функц шаардлагатай байж болох вэ гэсэн асуултад тодорхой хариулт өгөх боломжгүй юм. Нэгдүгээрт, энэ нь мэдээж таны дамжуулж, хадгалж, хамгаалахыг оролдож буй өгөгдлөөс хамаарна. Хоёрдугаарт, бодит байдал дээр ихэнхдээ хамгаалалтын хэрэгслийг сонгох нь худалдагчид итгэх итгэл, итгэлийн асуудал юм. Та алгоритмыг мэдэхгүй, хэр үр дүнтэй болохыг мэдэхгүй, тэдгээрийг бүрэн шалгаж чадахгүй.

Тиймээс чухал сегментүүдэд өөр өөр компаниудын саналыг ашиглах нь сайн шийдэл байж болох юм. Жишээлбэл, та галт хананд вирусны эсрэг програмыг идэвхжүүлж болохоос гадна хостууд дээр вирусны эсрэг хамгаалалтыг (өөр үйлдвэрлэгчээс) ашиглаж болно.

Сегментчлэл

Бид мэдээллийн төвийн сүлжээг логик сегментчлэлийн тухай ярьж байна. Жишээлбэл, VLAN болон дэд сүлжээнд хуваах нь бас логик сегментчилэл боловч ойлгомжтой учраас бид үүнийг авч үзэхгүй. FW хамгаалалтын бүс, VRF (мөн тэдгээрийн төрөл бүрийн борлуулагчидтай холбоотой аналогууд), логик төхөөрөмжүүд (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ... зэрэг аж ахуйн нэгжүүдийг харгалзан үзсэн сонирхолтой сегментчилэл.

Ийм логик сегментчиллийн жишээ ба одоо эрэлт хэрэгцээтэй байгаа мэдээллийн төвийн дизайныг энд үзүүлэв PSEFABRIC төслийн p002.

Сүлжээнийхээ логик хэсгүүдийг тодорхойлсны дараа та өөр өөр сегментүүдийн хооронд траффик хэрхэн шилжих, ямар төхөөрөмж дээр шүүлтүүр хийх, ямар хэрэгслээр хийх талаар тайлбарлаж болно.

Хэрэв таны сүлжээнд тодорхой логик хуваалт байхгүй бөгөөд янз бүрийн өгөгдлийн урсгалд аюулгүй байдлын бодлогыг хэрэгжүүлэх дүрмүүд албан ёсоор тогтоогдоогүй бол та энэ эсвэл өөр хандалтыг нээх үед энэ асуудлыг шийдэхээс өөр аргагүй болж байгаа бөгөөд өндөр магадлалтайгаар та тэр болгонд өөрөөр шийдэх болно.

Ихэнхдээ сегментчилэл нь зөвхөн FW хамгаалалтын бүсэд суурилдаг. Дараа нь та дараах асуултуудад хариулах хэрэгтэй.

• танд ямар хамгаалалтын бүс хэрэгтэй вэ
• Та эдгээр бүс бүрт ямар түвшний хамгаалалт хэрэглэхийг хүсч байна
• анхдагчаар бүс доторх хөдөлгөөнийг зөвшөөрөх үү?
• Хэрэв тийм биш бол бүс бүрт замын хөдөлгөөний шүүлтүүрийн ямар бодлогыг хэрэгжүүлэх болно
• Хос бүс (эх/очих газар) бүрт хөдөлгөөний шүүлтүүрийн ямар бодлогыг хэрэгжүүлэх вэ

TCAM

Нийтлэг асуудал бол чиглүүлэлт болон хандалтын аль алинд нь TCAM (Ternary Content Addressable Memory) хангалтгүй байдаг. IMHO, энэ нь тоног төхөөрөмжийг сонгоход хамгийн чухал асуудлуудын нэг тул та энэ асуудлыг зохих ёсоор анхаарч үзэх хэрэгтэй.

Жишээ 1. Дамжуулах хүснэгт TCAM.

Харцгаая Пало Альто 7к галт хана
IPv4 дамжуулах хүснэгтийн хэмжээ* = 32К байгааг бид харж байна
Түүнчлэн, энэ тооны маршрут нь бүх VSYS-д нийтлэг байдаг.

Та дизайныхаа дагуу 4 VSYS ашиглахаар шийдсэн гэж бодъё.
Эдгээр VSYS бүр нь BGP-ээр дамжуулан таны BB болгон ашигладаг үүлний хоёр MPLS PE-тэй холбогддог. Тиймээс 4 VSYS нь бүх тодорхой маршрутуудыг өөр хоорондоо солилцдог бөгөөд ойролцоогоор ижил маршрутын багц бүхий дамжуулах хүснэгттэй байдаг (гэхдээ өөр NH). Учир нь VSYS бүр нь 2 BGP сесстэй (ижил тохиргоотой), дараа нь MPLS-ээр дамжуулан хүлээн авсан маршрут бүр 2 NH ба үүний дагуу Дамжуулах хүснэгтэд 2 FIB оруулгатай байна. Хэрэв энэ нь дата төвийн цорын ганц галт хана бөгөөд энэ нь бүх маршрутын талаар мэддэг байх ёстой гэж үзвэл манай дата төвийн нийт маршрутын тоо 32K/(4*2) = 4K-ээс их байж болохгүй гэсэн үг юм.

Одоо бид 2 дата төвтэй (ижил дизайнтай) гэж үзвэл дата төвүүдийн хооронд "сунгасан" VLAN ашиглахыг хүсч байвал (жишээлбэл, vMotion-д) чиглүүлэлтийн асуудлыг шийдэхийн тулд бид хостын маршрутуудыг ашиглах ёстой. . Гэхдээ энэ нь 2 дата төвийн хувьд бид 4096-аас илүүгүй хосттой байх болно гэсэн үг бөгөөд мэдээжийн хэрэг энэ нь хангалтгүй байж магадгүй юм.

Жишээ 2. ACL TCAM.

Хэрэв та L3 унтраалга (эсвэл Cisco ACI гэх мэт L3 шилжүүлэгч ашигладаг бусад шийдлүүд) дээр траффикийг шүүхээр төлөвлөж байгаа бол тоног төхөөрөмжийг сонгохдоо 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