Artikel ini adalah yang ketiga dari serangkaian artikel “Cara Mengendalikan Infrastruktur Jaringan Anda.” Isi semua artikel dalam seri dan tautan dapat ditemukan .
Tidak ada gunanya membicarakan penghapusan risiko keamanan sepenuhnya. Pada prinsipnya, kita tidak bisa menguranginya menjadi nol. Kami juga perlu memahami bahwa seiring upaya kami untuk membuat jaringan menjadi lebih aman, solusi kami menjadi semakin mahal. Anda perlu menemukan trade-off antara biaya, kompleksitas, dan keamanan yang masuk akal untuk jaringan Anda.
Tentu saja, desain keamanan terintegrasi secara organik ke dalam keseluruhan arsitektur dan solusi keamanan yang digunakan memengaruhi skalabilitas, keandalan, pengelolaan, ... infrastruktur jaringan, yang juga harus diperhitungkan.
Namun izinkan saya mengingatkan Anda bahwa sekarang kita tidak berbicara tentang membuat jaringan. menurut kami kita telah memilih desain, memilih peralatan, dan membangun infrastruktur, dan pada tahap ini, jika memungkinkan, kita harus “hidup” dan mencari solusi dalam konteks pendekatan yang dipilih sebelumnya.
Tugas kita sekarang adalah mengidentifikasi risiko yang terkait dengan keamanan di tingkat jaringan dan menguranginya ke tingkat yang wajar.
Audit keamanan jaringan
Jika organisasi Anda telah menerapkan proses ISO 27k, maka audit keamanan dan perubahan jaringan harus disesuaikan dengan keseluruhan proses dalam pendekatan ini. Namun standar ini masih bukan tentang solusi spesifik, bukan tentang konfigurasi, bukan tentang desain... Tidak ada saran yang jelas, tidak ada standar yang menentukan secara rinci seperti apa jaringan Anda seharusnya, inilah kompleksitas dan keindahan tugas ini.
Saya akan menyoroti beberapa kemungkinan audit keamanan jaringan:
- audit konfigurasi peralatan (pengerasan)
- audit desain keamanan
- akses audit
- audit proses
Audit konfigurasi peralatan (pengerasan)
Tampaknya dalam banyak kasus, ini adalah titik awal terbaik untuk mengaudit dan meningkatkan keamanan jaringan Anda. IMHO, ini adalah demonstrasi yang baik dari hukum Pareto (20% upaya menghasilkan 80% hasil, dan 80% upaya sisanya hanya menghasilkan 20% hasil).
Intinya adalah kami biasanya mendapat rekomendasi dari vendor mengenai “praktik terbaik” untuk keamanan saat mengonfigurasi peralatan. Ini disebut “pengerasan”.
Anda juga sering dapat menemukan kuesioner (atau membuatnya sendiri) berdasarkan rekomendasi ini, yang akan membantu Anda menentukan seberapa baik konfigurasi peralatan Anda mematuhi “praktik terbaik” ini dan, sesuai dengan hasilnya, membuat perubahan pada jaringan Anda. . Ini akan memungkinkan Anda mengurangi risiko keamanan secara signifikan dengan cukup mudah, tanpa biaya.
Beberapa contoh untuk beberapa sistem operasi Cisco.
Berdasarkan dokumen-dokumen ini, daftar persyaratan konfigurasi untuk setiap jenis peralatan dapat dibuat. Misalnya, untuk Cisco N7K VDC, persyaratannya mungkin terlihat seperti ini .
Dengan cara ini, file konfigurasi dapat dibuat untuk berbagai jenis peralatan aktif di infrastruktur jaringan Anda. Selanjutnya, secara manual atau menggunakan otomatisasi, Anda dapat “mengunggah” file konfigurasi ini. Cara mengotomatisasi proses ini akan dibahas secara rinci dalam seri artikel lain tentang orkestrasi dan otomatisasi.
Audit desain keamanan
Biasanya, jaringan perusahaan berisi segmen berikut dalam satu atau lain bentuk:
- DC (Pusat data DMZ dan Intranet layanan publik)
- Akses Internet
- VPN akses jarak jauh
- tepi WAN
- Cabang
- Kampus (Kantor)
- Core
Judul diambil dari model, tetapi tentu saja tidak perlu melekat secara tepat pada nama-nama ini dan pada model ini. Tetap saja, saya ingin berbicara tentang esensinya dan tidak terjebak pada formalitas.
Untuk masing-masing segmen ini, persyaratan keamanan, risiko, dan solusinya akan berbeda.
Mari kita lihat masing-masing secara terpisah untuk mengetahui masalah yang mungkin Anda temui dari sudut pandang desain keamanan. Tentu saja, saya ulangi lagi bahwa artikel ini sama sekali tidak berpura-pura lengkap, yang tidak mudah (jika bukan tidak mungkin) dicapai dalam topik yang benar-benar mendalam dan beragam ini, tetapi artikel ini mencerminkan pengalaman pribadi saya.
Tidak ada solusi yang sempurna (setidaknya belum). Itu selalu merupakan kompromi. Namun keputusan untuk menggunakan pendekatan tertentu harus dibuat secara sadar, dengan pemahaman mengenai pro dan kontranya.
Data Center
Segmen paling kritis dari sudut pandang keselamatan.
Dan, seperti biasa, tidak ada solusi universal juga di sini. Itu semua sangat tergantung pada kebutuhan jaringan.
Apakah firewall diperlukan atau tidak?
Tampaknya jawabannya sudah jelas, tetapi semuanya tidak sejelas kelihatannya. Dan pilihan Anda tidak hanya dapat dipengaruhi harga.
Contoh 1. Penundaan.
Jika latensi rendah merupakan persyaratan penting antara beberapa segmen jaringan, yang misalnya berlaku dalam kasus pertukaran, maka kami tidak akan dapat menggunakan firewall di antara segmen ini. Sulit untuk menemukan studi tentang latensi di firewall, namun hanya sedikit model switch yang dapat memberikan latensi kurang dari atau sekitar 1 mksec, jadi menurut saya jika mikrodetik penting bagi Anda, maka firewall bukan untuk Anda.
Contoh 2. Performa.
Throughput dari switch L3 teratas biasanya memiliki urutan besarnya lebih tinggi daripada throughput firewall yang paling kuat. Oleh karena itu, jika lalu lintas berintensitas tinggi, kemungkinan besar Anda juga harus mengizinkan lalu lintas ini melewati firewall.
Contoh 3. Keandalan
Firewall, khususnya NGFW (Next-Generation FW) modern adalah perangkat yang kompleks. Mereka jauh lebih kompleks daripada sakelar L3/L2. Mereka menyediakan sejumlah besar layanan dan opsi konfigurasi, sehingga tidak mengherankan jika keandalannya jauh lebih rendah. Jika kontinuitas layanan sangat penting bagi jaringan, maka Anda mungkin harus memilih apa yang akan menghasilkan ketersediaan yang lebih baik - keamanan dengan firewall atau kesederhanaan jaringan yang dibangun di atas switch (atau berbagai jenis fabric) menggunakan ACL biasa.
Dalam kasus contoh di atas, kemungkinan besar Anda (seperti biasa) harus mencari kompromi. Lihatlah solusi berikut:
- jika Anda memutuskan untuk tidak menggunakan firewall di dalam pusat data, maka Anda perlu memikirkan cara membatasi akses di sekelilingnya sebanyak mungkin. Misalnya, Anda hanya dapat membuka port yang diperlukan dari Internet (untuk lalu lintas klien) dan akses administratif ke pusat data hanya dari host lompat. Pada jump host, lakukan semua pemeriksaan yang diperlukan (autentikasi/otorisasi, antivirus, logging, ...)
- Anda dapat menggunakan partisi logis dari jaringan pusat data menjadi beberapa segmen, mirip dengan skema yang dijelaskan dalam PSEFABRIC . Dalam hal ini, perutean harus dikonfigurasi sedemikian rupa sehingga lalu lintas yang sensitif terhadap penundaan atau intensitas tinggi masuk “dalam” satu segmen (dalam kasus p002, VRF) dan tidak melewati firewall. Lalu lintas antar segmen yang berbeda akan terus melewati firewall. Anda juga dapat menggunakan kebocoran rute antar VRF untuk menghindari pengalihan lalu lintas melalui firewall
- Anda juga dapat menggunakan firewall dalam mode transparan dan hanya untuk VLAN yang faktor-faktornya (latensi/kinerja) tidak signifikan. Namun Anda perlu mempelajari dengan cermat batasan terkait penggunaan mod ini untuk setiap vendor
- Anda mungkin ingin mempertimbangkan untuk menggunakan arsitektur rantai layanan. Ini hanya akan mengizinkan lalu lintas yang diperlukan untuk melewati firewall. Secara teori terlihat bagus, tetapi saya belum pernah melihat solusi ini dalam produksi. Kami menguji rantai layanan untuk Cisco ACI/Juniper SRX/F5 LTM sekitar 3 tahun yang lalu, namun pada saat itu solusi ini tampak “kasar” bagi kami.
Tingkat perlindungan
Sekarang Anda perlu menjawab pertanyaan tentang alat apa yang ingin Anda gunakan untuk memfilter lalu lintas. Berikut beberapa fitur yang biasanya ada di NGFW (misalnya, ):
- firewall berstatus (default)
- firewall aplikasi
- pencegahan ancaman (antivirus, anti-spyware, dan kerentanan)
- Pemfilteran URL
- pemfilteran data (penyaringan konten)
- pemblokiran file (pemblokiran jenis file)
- melakukan perlindungan
Dan tidak semuanya jelas juga. Tampaknya semakin tinggi tingkat perlindungannya, semakin baik. Namun Anda juga perlu mempertimbangkan hal itu
- Semakin banyak fungsi firewall di atas yang Anda gunakan, tentu akan semakin mahal harganya (lisensi, modul tambahan)
- penggunaan beberapa algoritma dapat secara signifikan mengurangi throughput firewall dan juga meningkatkan penundaan, lihat misalnya
- seperti solusi kompleks lainnya, penggunaan metode perlindungan yang kompleks dapat mengurangi keandalan solusi Anda, misalnya, saat menggunakan firewall aplikasi, saya menemukan pemblokiran beberapa aplikasi yang berfungsi cukup standar (dns, smb)
Seperti biasa, Anda perlu menemukan solusi terbaik untuk jaringan Anda.
Tidak mungkin menjawab secara pasti pertanyaan tentang fungsi perlindungan apa yang mungkin diperlukan. Pertama, karena hal ini tentu saja bergantung pada data yang Anda kirimkan atau simpan dan coba lindungi. Kedua, pada kenyataannya, sering kali pilihan alat keamanan bergantung pada keyakinan dan kepercayaan terhadap vendor. Anda tidak mengetahui algoritmenya, Anda tidak tahu seberapa efektif algoritme tersebut, dan Anda tidak dapat mengujinya sepenuhnya.
Oleh karena itu, di segmen kritis, solusi yang baik mungkin adalah dengan menggunakan penawaran dari perusahaan yang berbeda. Misalnya, Anda dapat mengaktifkan antivirus di firewall, tetapi juga menggunakan perlindungan antivirus (dari pabrikan lain) secara lokal di host.
Segmentasi
Kita berbicara tentang segmentasi logis dari jaringan pusat data. Misalnya, mempartisi menjadi VLAN dan subnet juga merupakan segmentasi logis, tetapi kami tidak akan mempertimbangkannya karena sudah jelas. Segmentasi yang menarik dengan mempertimbangkan entitas seperti zona keamanan FW, VRF (dan analognya sehubungan dengan berbagai vendor), perangkat logis (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...
Contoh segmentasi logis dan desain pusat data yang saat ini diminati diberikan dalam .
Setelah menentukan bagian logis dari jaringan Anda, Anda kemudian dapat menjelaskan bagaimana lalu lintas berpindah antar segmen yang berbeda, pada perangkat mana pemfilteran akan dilakukan dan dengan cara apa.
Jika jaringan Anda tidak memiliki partisi logis yang jelas dan aturan untuk menerapkan kebijakan keamanan untuk aliran data yang berbeda tidak diformalkan, ini berarti ketika Anda membuka akses ini atau itu, Anda terpaksa menyelesaikan masalah ini, dan dengan kemungkinan besar Anda akan menyelesaikannya setiap saat secara berbeda.
Seringkali segmentasi hanya didasarkan pada zona keamanan FW. Maka Anda perlu menjawab pertanyaan-pertanyaan berikut:
- zona keamanan apa yang Anda butuhkan
- tingkat perlindungan apa yang ingin Anda terapkan pada masing-masing zona tersebut
- apakah lalu lintas intra-zona akan diizinkan secara default?
- jika tidak, kebijakan penyaringan lalu lintas apa yang akan diterapkan dalam setiap zona
- kebijakan penyaringan lalu lintas apa yang akan diterapkan untuk setiap pasangan zona (sumber/tujuan)
TCAM
Masalah yang umum terjadi adalah TCAM (Ternary Content Addressable Memory) yang tidak mencukupi, baik untuk routing maupun untuk akses. IMHO, ini adalah salah satu masalah terpenting saat memilih peralatan, jadi Anda perlu menangani masalah ini dengan tingkat kehati-hatian yang tepat.
Contoh 1. Tabel Penerusan TCAM.
Mari kita pertimbangkan firewall
Kita melihat bahwa ukuran tabel penerusan IPv4* = 32K
Selain itu, jumlah rute ini umum untuk semua VSYS.Mari kita asumsikan bahwa menurut desain Anda, Anda memutuskan untuk menggunakan 4 VSYS.
Masing-masing VSYS ini terhubung melalui BGP ke dua MPLS PE cloud yang Anda gunakan sebagai BB. Jadi, 4 VSYS menukar semua rute tertentu satu sama lain dan memiliki tabel penerusan dengan kumpulan rute yang kira-kira sama (tetapi NH berbeda). Karena setiap VSYS memiliki 2 sesi BGP (dengan pengaturan yang sama), kemudian setiap rute yang diterima melalui MPLS memiliki 2 NH dan, karenanya, 2 entri FIB di Tabel Penerusan. Jika kita berasumsi bahwa ini adalah satu-satunya firewall di pusat data dan harus mengetahui semua rute, maka ini berarti jumlah total rute di pusat data kita tidak boleh lebih dari 32K/(4 * 2) = 4K.Sekarang, jika kita berasumsi bahwa kita memiliki 2 pusat data (dengan desain yang sama), dan kita ingin menggunakan VLAN yang “direntangkan” antar pusat data (misalnya untuk vMotion), maka untuk menyelesaikan masalah routing, kita harus menggunakan rute host . Namun ini berarti bahwa untuk 2 pusat data kita akan memiliki tidak lebih dari 4096 kemungkinan host dan, tentu saja, ini mungkin tidak cukup.
Contoh 2. ACL TCAM.
Jika Anda berencana untuk memfilter lalu lintas pada sakelar L3 (atau solusi lain yang menggunakan sakelar L3, misalnya Cisco ACI), maka saat memilih peralatan, Anda harus memperhatikan TCAM ACL.
Misalkan Anda ingin mengontrol akses pada antarmuka SVI Cisco Catalyst 4500. Kemudian, seperti dapat dilihat dari , untuk mengontrol lalu lintas keluar (serta masuk) pada antarmuka, Anda hanya dapat menggunakan 4096 jalur TCAM. Yang mana bila menggunakan TCAM3 akan memberikan sekitar 4000 ribu ACE (garis ACL).
Jika Anda dihadapkan pada masalah TCAM yang tidak mencukupi, pertama-tama, tentu saja, Anda perlu mempertimbangkan kemungkinan optimasi. Jadi, jika ada masalah dengan ukuran Tabel Penerusan, Anda perlu mempertimbangkan kemungkinan menggabungkan rute. Jika ada masalah dengan ukuran TCAM untuk akses, audit akses, hapus catatan yang ketinggalan jaman dan tumpang tindih, dan mungkin revisi prosedur pembukaan akses (akan dibahas secara rinci dalam bab tentang mengaudit akses).
Ketersediaan Tinggi
Pertanyaannya adalah: haruskah saya menggunakan HA untuk firewall atau memasang dua kotak independen “secara paralel” dan, jika salah satunya gagal, mengarahkan lalu lintas melalui kotak kedua?
Tampaknya jawabannya jelas - gunakan HA. Alasan mengapa pertanyaan ini masih muncul adalah, sayangnya, persentase aksesibilitas teoritis dan periklanan dan beberapa desimal dalam praktiknya ternyata jauh dari harapan. HA secara logis merupakan hal yang cukup kompleks, dan pada peralatan yang berbeda, dan dengan vendor yang berbeda (tidak ada pengecualian), kami menemukan masalah dan bug serta penghentian layanan.
Jika Anda menggunakan HA, Anda akan memiliki kesempatan untuk mematikan node individual, beralih di antara node tersebut tanpa menghentikan layanan, yang penting, misalnya, saat melakukan peningkatan, tetapi pada saat yang sama Anda memiliki kemungkinan jauh dari nol bahwa kedua node akan rusak pada saat yang sama, dan juga pemutakhiran berikutnya tidak akan berjalan semulus yang dijanjikan vendor (masalah ini dapat dihindari jika Anda memiliki kesempatan untuk menguji pemutakhiran pada peralatan laboratorium).
Jika Anda tidak menggunakan HA, maka dari sudut pandang kegagalan ganda, risiko Anda jauh lebih rendah (karena Anda memiliki 2 firewall independen), tetapi karena... sesi tidak disinkronkan, maka setiap kali Anda beralih di antara firewall ini, Anda akan kehilangan lalu lintas. Anda tentu saja dapat menggunakan firewall tanpa kewarganegaraan, namun tujuan penggunaan firewall sebagian besar hilang.
Oleh karena itu, jika sebagai hasil audit Anda menemukan firewall yang sepi, dan Anda berpikir untuk meningkatkan keandalan jaringan Anda, maka HA, tentu saja, adalah salah satu solusi yang disarankan, namun Anda juga harus mempertimbangkan kerugian yang terkait. dengan pendekatan ini dan, mungkin, khusus untuk jaringan Anda, solusi lain akan lebih cocok.
Pengelolaan
Pada prinsipnya, HA juga tentang pengendalian. Daripada mengonfigurasi 2 kotak secara terpisah dan mengatasi masalah menjaga konfigurasi tetap sinkron, Anda mengelolanya seolah-olah Anda memiliki satu perangkat.
Namun mungkin Anda memiliki banyak pusat data dan banyak firewall, maka pertanyaan ini muncul pada tingkat yang baru. Dan pertanyaannya bukan hanya tentang konfigurasi, tetapi juga tentang
- konfigurasi cadangan
- pembaruan
- peningkatan
- pemantauan
- pencatatan
Dan semua ini dapat diselesaikan dengan sistem manajemen terpusat.
Misalnya, jika Anda menggunakan firewall Palo Alto, maka adalah solusi seperti itu.
Untuk dilanjutkan.
Sumber: www.habr.com