Artikel ini adalah yang ketiga dalam siri artikel "Cara Mengambil Kawalan Infrastruktur Rangkaian Anda." Kandungan semua artikel dalam siri dan pautan boleh didapati di sini.

Tidak ada gunanya bercakap tentang menghapuskan sepenuhnya risiko keselamatan. Pada dasarnya, kita tidak boleh mengurangkannya kepada sifar. Kami juga perlu memahami bahawa semasa kami berusaha untuk menjadikan rangkaian lebih selamat, penyelesaian kami menjadi semakin mahal. Anda perlu mencari pertukaran antara kos, kerumitan dan keselamatan yang masuk akal untuk rangkaian anda.

Sudah tentu, reka bentuk keselamatan disepadukan secara organik ke dalam seni bina keseluruhan dan penyelesaian keselamatan yang digunakan mempengaruhi kebolehskalaan, kebolehpercayaan, kebolehurusan, ... infrastruktur rangkaian, yang juga mesti diambil kira.

Tetapi izinkan saya mengingatkan anda bahawa sekarang kita tidak bercakap tentang mewujudkan rangkaian. Menurut kami keadaan awal kami telah memilih reka bentuk, memilih peralatan, dan mencipta infrastruktur, dan pada peringkat ini, jika boleh, kami harus "hidup" dan mencari penyelesaian dalam konteks pendekatan yang dipilih sebelum ini.

Tugas kami sekarang adalah untuk mengenal pasti risiko yang berkaitan dengan keselamatan di peringkat rangkaian dan mengurangkannya ke tahap yang munasabah.

Audit keselamatan rangkaian

Jika organisasi anda telah melaksanakan proses ISO 27k, maka audit keselamatan dan perubahan rangkaian harus sesuai dengan lancar ke dalam keseluruhan proses dalam pendekatan ini. Tetapi piawaian ini masih bukan mengenai penyelesaian khusus, bukan mengenai konfigurasi, bukan mengenai reka bentuk... Tiada nasihat yang jelas, tiada piawaian yang menentukan secara terperinci bagaimana rangkaian anda sepatutnya, ini adalah kerumitan dan keindahan tugas ini.

Saya akan menyerlahkan beberapa kemungkinan audit keselamatan rangkaian:

• audit konfigurasi peralatan (pengerasan)
• audit reka bentuk keselamatan
• audit akses
• audit proses

Audit konfigurasi peralatan (pengerasan)

Nampaknya dalam kebanyakan kes ini adalah titik permulaan terbaik untuk mengaudit dan meningkatkan keselamatan rangkaian anda. IMHO, ini adalah demonstrasi undang-undang Pareto yang baik (20% daripada usaha menghasilkan 80% daripada hasil, dan baki 80% daripada usaha menghasilkan hanya 20% daripada hasil).

Intinya ialah kami biasanya mempunyai cadangan daripada vendor mengenai "amalan terbaik" untuk keselamatan semasa mengkonfigurasi peralatan. Ini dipanggil "pengerasan".

Anda juga sering boleh mencari soal selidik (atau buat sendiri) berdasarkan pengesyoran ini, yang akan membantu anda menentukan sejauh mana konfigurasi peralatan anda mematuhi "amalan terbaik" ini dan, selaras dengan hasilnya, membuat perubahan dalam rangkaian anda . Ini akan membolehkan anda mengurangkan risiko keselamatan dengan ketara dengan mudah, hampir tanpa kos.

Beberapa contoh untuk beberapa sistem pengendalian Cisco.

Pengerasan Konfigurasi Cisco IOS
Pengerasan Konfigurasi Cisco IOS-XR
Pengerasan Konfigurasi Cisco NX-OS
Senarai Semakan Keselamatan Garis Dasar Cisco

Berdasarkan dokumen ini, senarai keperluan konfigurasi untuk setiap jenis peralatan boleh dibuat. Sebagai contoh, untuk Cisco N7K VDC keperluan ini mungkin kelihatan seperti jadi.

Dengan cara ini, fail konfigurasi boleh dibuat untuk pelbagai jenis peralatan aktif dalam infrastruktur rangkaian anda. Seterusnya, secara manual atau menggunakan automasi, anda boleh "memuat naik" fail konfigurasi ini. Cara mengautomasikan proses ini akan dibincangkan secara terperinci dalam siri artikel lain mengenai orkestrasi dan automasi.

Audit reka bentuk keselamatan

Biasanya, rangkaian perusahaan mengandungi segmen berikut dalam satu bentuk atau yang lain:

• DC (DMZ perkhidmatan awam dan pusat data Intranet)
• Akses Internet
• VPN akses jauh
• tepi WAN
• Cawangan
• Kampus (Pejabat)
• Teras

Tajuk diambil daripada Cisco SELAMAT model, tetapi ia tidak perlu, sudah tentu, dilampirkan dengan tepat pada nama-nama ini dan pada model ini. Namun, saya ingin bercakap tentang intipati dan tidak terperangkap dalam formaliti.

Bagi setiap segmen ini, keperluan keselamatan, risiko dan, sewajarnya, penyelesaian akan berbeza.

Mari lihat setiap satu daripada mereka secara berasingan untuk masalah yang mungkin anda hadapi dari sudut reka bentuk keselamatan. Sudah tentu, saya ulangi sekali lagi bahawa artikel ini tidak berpura-pura lengkap, yang tidak mudah (jika tidak mustahil) dicapai dalam topik yang benar-benar mendalam dan pelbagai aspek ini, tetapi ia mencerminkan pengalaman peribadi saya.

Tiada penyelesaian yang sempurna (sekurang-kurangnya belum lagi). Ia sentiasa kompromi. Tetapi adalah penting bahawa keputusan untuk menggunakan satu pendekatan atau yang lain dibuat secara sedar, dengan pemahaman tentang kebaikan dan keburukannya.

Pusat data

Segmen paling kritikal dari sudut keselamatan.
Dan, seperti biasa, tiada penyelesaian universal di sini sama ada. Semuanya sangat bergantung pada keperluan rangkaian.

Adakah firewall perlu atau tidak?

Nampaknya jawapannya jelas, tetapi semuanya tidak begitu jelas seperti yang disangka. Dan pilihan anda boleh dipengaruhi bukan sahaja harga.

Contoh 1. Kelewatan.

Jika kependaman rendah merupakan keperluan penting antara beberapa segmen rangkaian, yang, sebagai contoh, benar dalam kes pertukaran, maka kami tidak akan dapat menggunakan tembok api antara segmen ini. Sukar untuk mencari kajian tentang kependaman dalam tembok api, tetapi beberapa model suis boleh memberikan kependaman kurang daripada atau mengikut urutan 1 mksec, jadi saya fikir jika mikrosaat penting kepada anda, maka tembok api bukan untuk anda.

Contoh 2. Prestasi.

Daya tampung suis L3 teratas biasanya merupakan susunan magnitud yang lebih tinggi daripada daya tampung tembok api yang paling berkuasa. Oleh itu, dalam kes trafik intensiti tinggi, kemungkinan besar anda juga perlu membenarkan trafik ini memintas tembok api.

Contoh 3. Kebolehpercayaan

Firewall, terutamanya NGFW moden (Next-Generation FW) ialah peranti yang kompleks. Mereka jauh lebih kompleks daripada suis L3/L2. Mereka menyediakan sejumlah besar perkhidmatan dan pilihan konfigurasi, jadi tidak menghairankan bahawa kebolehpercayaan mereka jauh lebih rendah. Jika kesinambungan perkhidmatan adalah penting kepada rangkaian, maka anda mungkin perlu memilih apa yang akan membawa kepada ketersediaan yang lebih baik - keselamatan dengan tembok api atau kesederhanaan rangkaian yang dibina pada suis (atau pelbagai jenis fabrik) menggunakan ACL biasa.

Dalam kes contoh di atas, kemungkinan besar anda (seperti biasa) perlu mencari kompromi. Lihat ke arah penyelesaian berikut:

• jika anda memutuskan untuk tidak menggunakan tembok api di dalam pusat data, maka anda perlu memikirkan cara untuk mengehadkan akses di sekeliling perimeter sebanyak mungkin. Sebagai contoh, anda boleh membuka hanya port yang diperlukan dari Internet (untuk trafik pelanggan) dan akses pentadbiran ke pusat data hanya dari hos lompat. Pada hos lompat, lakukan semua pemeriksaan yang diperlukan (pengesahan/keizinan, antivirus, pengelogan, ...)
• anda boleh menggunakan partition logik rangkaian pusat data ke dalam segmen, serupa dengan skema yang diterangkan dalam PSEFABRIC contoh p002. Dalam kes ini, penghalaan mesti dikonfigurasikan sedemikian rupa sehingga trafik sensitif kelewatan atau intensiti tinggi pergi "dalam" satu segmen (dalam kes p002, VRF) dan tidak melalui tembok api. Trafik antara segmen berbeza akan terus melalui tembok api. Anda juga boleh menggunakan laluan bocor antara VRF untuk mengelak mengalihkan trafik melalui tembok api
• Anda juga boleh menggunakan tembok api dalam mod telus dan hanya untuk VLAN yang faktor-faktor ini (latensi/prestasi) tidak penting. Tetapi anda perlu mengkaji dengan teliti sekatan yang berkaitan dengan penggunaan mod ini untuk setiap vendor
• anda mungkin ingin mempertimbangkan untuk menggunakan seni bina rantaian perkhidmatan. Ini akan membenarkan hanya trafik yang diperlukan untuk melalui tembok api. Nampak bagus dalam teori, tetapi saya tidak pernah melihat penyelesaian ini dalam pengeluaran. Kami telah menguji rantaian perkhidmatan untuk Cisco ACI/Juniper SRX/F5 LTM kira-kira 3 tahun yang lalu, tetapi pada masa itu penyelesaian ini kelihatan "kasar" kepada kami.

Tahap perlindungan

Sekarang anda perlu menjawab soalan apakah alat yang anda ingin gunakan untuk menapis trafik. Berikut adalah beberapa ciri yang biasanya terdapat dalam NGFW (contohnya, di sini):

• tembok api stateful (lalai)
• firewall aplikasi
• pencegahan ancaman (antivirus, anti-perisian pengintip dan kerentanan)
• Penapisan URL
• penapisan data (penapisan kandungan)
• menyekat fail (menyekat jenis fail)
• perlindungan dos

Dan tidak semuanya jelas sama ada. Nampaknya semakin tinggi tahap perlindungan, lebih baik. Tetapi anda juga perlu mempertimbangkannya

• Lebih banyak fungsi firewall di atas yang anda gunakan, lebih mahal secara semula jadi (lesen, modul tambahan)
• penggunaan beberapa algoritma boleh mengurangkan daya pemprosesan firewall dengan ketara dan juga meningkatkan kelewatan, lihat sebagai contoh di sini
• seperti mana-mana penyelesaian yang kompleks, penggunaan kaedah perlindungan yang kompleks boleh mengurangkan kebolehpercayaan penyelesaian anda, sebagai contoh, apabila menggunakan firewall aplikasi, saya menghadapi penyekatan beberapa aplikasi yang berfungsi agak standard (dns, smb)

Seperti biasa, anda perlu mencari penyelesaian terbaik untuk rangkaian anda.

Adalah mustahil untuk menjawab soalan secara pasti tentang fungsi perlindungan yang mungkin diperlukan. Pertama, kerana ia sudah tentu bergantung pada data yang anda hantar atau simpan dan cuba untuk melindungi. Kedua, pada hakikatnya, selalunya pilihan alat keselamatan adalah soal kepercayaan dan kepercayaan kepada vendor. Anda tidak tahu algoritma, anda tidak tahu sejauh mana keberkesanannya, dan anda tidak boleh mengujinya sepenuhnya.

Oleh itu, dalam segmen kritikal, penyelesaian yang baik mungkin menggunakan tawaran daripada syarikat yang berbeza. Contohnya, anda boleh mendayakan antivirus pada tembok api, tetapi juga menggunakan perlindungan antivirus (dari pengilang lain) secara setempat pada hos.

Segmentasi

Kita bercakap tentang pembahagian logik rangkaian pusat data. Sebagai contoh, pembahagian ke dalam VLAN dan subnet juga merupakan pembahagian logik, tetapi kami tidak akan menganggapnya kerana kejelasannya. Segmentasi yang menarik dengan mengambil kira entiti seperti zon keselamatan FW, VRF (dan analognya berhubung dengan pelbagai vendor), peranti logik (PA VSYS, Cisco N7K VDC, Penyewa Cisco ACI, ...), ...

Contoh pembahagian logik sedemikian dan reka bentuk pusat data yang sedang dalam permintaan diberikan dalam p002 projek PSEFABRIC.

Setelah mentakrifkan bahagian logik rangkaian anda, anda kemudian boleh menerangkan cara trafik bergerak antara segmen yang berbeza, penapisan peranti yang akan dilakukan dan dengan cara apa.

Jika rangkaian anda tidak mempunyai partition logik yang jelas dan peraturan untuk menggunakan dasar keselamatan untuk aliran data yang berbeza tidak diformalkan, ini bermakna apabila anda membuka akses ini atau itu, anda terpaksa menyelesaikan masalah ini, dan dengan kebarangkalian tinggi anda akan menyelesaikannya setiap kali secara berbeza.

Selalunya pembahagian hanya berdasarkan zon keselamatan FW. Kemudian anda perlu menjawab soalan berikut:

• apakah zon keselamatan yang anda perlukan
• apakah tahap perlindungan yang anda ingin gunakan untuk setiap zon ini
• adakah trafik dalam zon dibenarkan secara lalai?
• jika tidak, dasar penapisan trafik yang akan digunakan dalam setiap zon
• dasar penapisan trafik yang akan digunakan untuk setiap pasangan zon (sumber/destinasi)

TCAM

Masalah biasa ialah TCAM (Ternary Content Addressable Memory) yang tidak mencukupi, baik untuk penghalaan dan untuk akses. IMHO, ini adalah salah satu isu yang paling penting apabila memilih peralatan, jadi anda perlu menangani masalah ini dengan tahap penjagaan yang sesuai.

Contoh 1. Jadual Pemajuan TCAM.

Mari kita pertimbangkan Palo Alto 7k tembok api
Kami melihat bahawa saiz jadual pemajuan IPv4* = 32K
Selain itu, bilangan laluan ini adalah perkara biasa untuk semua VSYS.

Mari kita anggap bahawa mengikut reka bentuk anda, anda memutuskan untuk menggunakan 4 VSYS.
Setiap VSYS ini disambungkan melalui BGP ke dua MPLS PE awan yang anda gunakan sebagai BB. Oleh itu, 4 VSYS menukar semua laluan tertentu antara satu sama lain dan mempunyai jadual pemajuan dengan lebih kurang set laluan yang sama (tetapi NH berbeza). Kerana setiap VSYS mempunyai 2 sesi BGP (dengan tetapan yang sama), maka setiap laluan yang diterima melalui MPLS mempunyai 2 NH dan, oleh itu, 2 entri FIB dalam Jadual Pemajuan. Jika kami menganggap bahawa ini adalah satu-satunya tembok api dalam pusat data dan ia mesti mengetahui tentang semua laluan, maka ini bermakna jumlah laluan dalam pusat data kami tidak boleh melebihi 32K/(4 * 2) = 4K.

Sekarang, jika kita mengandaikan bahawa kita mempunyai 2 pusat data (dengan reka bentuk yang sama), dan kita mahu menggunakan VLAN "diregangkan" antara pusat data (contohnya, untuk vMotion), maka untuk menyelesaikan masalah penghalaan, kita mesti menggunakan laluan hos . Tetapi ini bermakna bahawa untuk 2 pusat data kami akan mempunyai tidak lebih daripada 4096 hos yang mungkin dan, sudah tentu, ini mungkin tidak mencukupi.

Contoh 2. ACL TCAM.

Jika anda bercadang untuk menapis trafik pada suis L3 (atau penyelesaian lain yang menggunakan suis L3, contohnya, Cisco ACI), maka apabila memilih peralatan anda harus memberi perhatian kepada TCAM ACL.

Katakan anda ingin mengawal akses pada antara muka SVI Cisco Catalyst 4500. Kemudian, seperti yang boleh dilihat daripada artikel ini, untuk mengawal trafik keluar (serta masuk) pada antara muka, anda boleh menggunakan hanya 4096 talian TCAM. Yang apabila menggunakan TCAM3 akan memberi anda kira-kira 4000 ribu ACE (garisan ACL).

Sekiranya anda berhadapan dengan masalah TCAM yang tidak mencukupi, maka, pertama sekali, tentu saja, anda perlu mempertimbangkan kemungkinan pengoptimuman. Jadi, sekiranya terdapat masalah dengan saiz Jadual Pemajuan, anda perlu mempertimbangkan kemungkinan mengagregatkan laluan. Sekiranya terdapat masalah dengan saiz TCAM untuk akses, akses audit, alih keluar rekod yang lapuk dan bertindih, dan mungkin menyemak semula prosedur untuk membuka akses (akan dibincangkan secara terperinci dalam bab pengauditan akses).

Ketersediaan Tinggi

Persoalannya ialah: patutkah saya menggunakan HA untuk tembok api atau memasang dua kotak bebas "selari" dan, jika salah satu daripadanya gagal, laluan lalu lintas melalui yang kedua?

Nampaknya jawapannya jelas - gunakan HA. Sebab mengapa soalan ini masih timbul ialah, malangnya, teori dan pengiklanan 99 dan beberapa peratusan perpuluhan kebolehcapaian dalam amalan ternyata jauh dari begitu cerah. HA secara logiknya adalah perkara yang agak kompleks, dan pada peralatan yang berbeza, dan dengan vendor yang berbeza (tiada pengecualian), kami menghadapi masalah dan pepijat dan perkhidmatan berhenti.

Jika anda menggunakan HA, anda akan mempunyai peluang untuk mematikan nod individu, bertukar antara mereka tanpa menghentikan perkhidmatan, yang penting, sebagai contoh, semasa membuat peningkatan, tetapi pada masa yang sama anda mempunyai kebarangkalian yang jauh dari sifar bahawa kedua-dua nod akan pecah pada masa yang sama, dan juga peningkatan seterusnya tidak akan berjalan lancar seperti yang dijanjikan vendor (masalah ini boleh dielakkan jika anda mempunyai peluang untuk menguji peningkatan pada peralatan makmal).

Jika anda tidak menggunakan HA, maka dari sudut kegagalan berganda risiko anda jauh lebih rendah (kerana anda mempunyai 2 firewall bebas), tetapi sejak... sesi tidak disegerakkan, maka setiap kali anda bertukar antara tembok api ini anda akan kehilangan trafik. Anda boleh, sudah tentu, menggunakan firewall tanpa kewarganegaraan, tetapi kemudian titik penggunaan firewall sebahagian besarnya hilang.

Oleh itu, jika hasil daripada audit anda telah menemui tembok api yang sunyi, dan anda berfikir tentang meningkatkan kebolehpercayaan rangkaian anda, maka HA, sudah tentu, adalah salah satu penyelesaian yang disyorkan, tetapi anda juga harus mengambil kira keburukan yang berkaitan dengan pendekatan ini dan, mungkin, khusus untuk rangkaian anda, penyelesaian lain akan lebih sesuai.

Kebolehurusan

Pada dasarnya, HA juga mengenai kebolehkawalan. Daripada mengkonfigurasi 2 kotak secara berasingan dan menangani masalah mengekalkan konfigurasi segerak, anda menguruskannya seolah-olah anda mempunyai satu peranti.

Tetapi mungkin anda mempunyai banyak pusat data dan banyak tembok api, maka persoalan ini timbul pada tahap yang baharu. Dan persoalannya bukan sahaja mengenai konfigurasi, tetapi juga tentang

• konfigurasi sandaran
• kemas kini
• naik taraf
• pemantauan
• pembalakan

Dan semua ini boleh diselesaikan dengan sistem pengurusan berpusat.

Jadi, sebagai contoh, jika anda menggunakan tembok api Palo Alto, maka Panorama adalah penyelesaian sedemikian.

Untuk diteruskan.

Sumber: www.habr.com