Artikel ini adalah yang ketiga dari serangkaian artikel yang berjudul “Bagaimana Mengambil Infrastruktur Jaringan Di Bawah Kontrol Anda”. Isi semua artikel dalam seri dan tautan dapat ditemukan di sini .



Tidak masuk akal untuk berbicara tentang penghapusan risiko keamanan sepenuhnya. Pada prinsipnya, kita tidak bisa menguranginya menjadi nol. Anda juga perlu memahami bahwa ketika kami berusaha untuk membuat jaringan lebih dan lebih aman, solusi kami menjadi lebih dan lebih mahal. Anda perlu menemukan kompromi yang masuk akal untuk jaringan Anda antara harga, kompleksitas dan keamanan.

Tentu saja, desain keamanan terintegrasi secara organik ke dalam arsitektur keseluruhan dan solusi keamanan yang digunakan memengaruhi skalabilitas, keandalan, pengelolaan, ... infrastruktur jaringan, yang juga harus diperhitungkan.

Tapi, saya mengingatkan Anda bahwa sekarang kita tidak berbicara tentang membuat jaringan. Sesuai dengan kondisi awal kami, kami telah memilih desain, peralatan yang dipilih, dan menciptakan infrastruktur, dan pada tahap ini kita harus, jika mungkin, "hidup" dan menemukan solusi dalam konteks pendekatan yang dipilih sebelumnya.

Tugas kami sekarang adalah untuk mengidentifikasi risiko yang terkait dengan keamanan di tingkat jaringan dan menguranginya ke nilai yang wajar.

Audit Keamanan Jaringan

Jika organisasi Anda telah menerapkan proses ISO 27k, maka audit keamanan dan perubahan jaringan harus diintegrasikan secara organik ke dalam keseluruhan proses sebagai bagian dari pendekatan ini. Tetapi standar-standar ini masih bukan tentang solusi spesifik, bukan tentang konfigurasi, bukan tentang desain ... Tidak ada kiat yang pasti, tidak ada standar yang menentukan secara terperinci apa yang seharusnya menjadi jaringan Anda, ini adalah kompleksitas dan keindahan tugas ini.

Saya akan menyoroti beberapa kemungkinan audit keamanan jaringan:

• audit konfigurasi peralatan (pengerasan)
• desain audit keamanan
• audit akses
• proses audit

Audit konfigurasi perangkat keras (pengerasan)

Dalam kebanyakan kasus, ini tampaknya menjadi titik awal terbaik untuk mengaudit dan meningkatkan keamanan jaringan Anda. IMHO, ini adalah demonstrasi yang baik dari hukum Pareto (20% dari upaya memberikan 80% dari hasilnya, dan 80% sisanya dari upaya hanya 20% dari hasilnya).

Intinya adalah bahwa biasanya kami memiliki rekomendasi dari vendor mengenai "praktik terbaik" tentang keselamatan saat mengkonfigurasi peralatan. Ini disebut pengerasan.

Anda juga dapat sering menemukan kuesioner (atau menulis sendiri) berdasarkan rekomendasi ini, yang akan membantu Anda menentukan bagaimana konfigurasi perangkat keras Anda cocok dengan "praktik terbaik" ini dan membuat perubahan pada jaringan Anda sesuai dengan hasilnya. Ini akan memungkinkan Anda untuk dengan mudah, hampir tanpa biaya, secara signifikan mengurangi risiko keamanan.

Beberapa contoh untuk beberapa sistem operasi Cisco.

Pengerasan Konfigurasi Cisco IOS
Pengerasan Konfigurasi Cisco IOS-XR
Pengerasan Konfigurasi Cisco NX-OS
Daftar Periksa Keamanan Cisco Baseline

Berdasarkan dokumen-dokumen ini, daftar persyaratan konfigurasi untuk setiap jenis peralatan dapat dibuat. Misalnya, untuk Cisco N7K VDC, persyaratan ini mungkin terlihat seperti ini .

Dengan demikian, file konfigurasi untuk berbagai jenis peralatan aktif dari infrastruktur jaringan Anda dapat dibuat. Selanjutnya, secara manual atau menggunakan otomatisasi, Anda dapat "mengunggah" file-file konfigurasi ini. Cara mengotomatiskan proses ini akan dibahas secara rinci dalam seri artikel lain tentang orkestrasi dan otomatisasi.

Desain audit keamanan

Biasanya, jaringan perusahaan dalam satu atau lain bentuk berisi segmen berikut:

• DC (Layanan publik DMZ dan pusat data Intranet)
• Akses internet
• VPN akses jarak jauh
• Wan edge
• Cabang
• Kampus (kantor)
• Inti

Nama-nama tersebut diambil dari model Cisco SAFE , tetapi tentu saja tidak perlu untuk mengikat nama-nama ini dan ke model ini. Tetap saja, saya ingin berbicara tentang esensi dan tidak terjebak dalam formalitas.

Untuk masing-masing segmen ini, persyaratan untuk tingkat keamanan, risiko dan, karenanya, keputusan akan berbeda.

Kami akan mempertimbangkan masing-masing secara terpisah untuk masalah yang mungkin Anda temui dalam hal desain keamanan. Tentu saja, saya ulangi lagi bahwa artikel ini sama sekali tidak mengklaim lengkap, yang dalam topik yang benar-benar mendalam dan beragam ini tidak mudah untuk dicapai (jika memungkinkan), tetapi mencerminkan pengalaman pribadi saya.

Tidak ada solusi yang sempurna (setidaknya untuk saat ini). Itu selalu kompromi. Tetapi penting bahwa keputusan untuk menerapkan pendekatan ini atau itu dibuat secara sadar, dengan pemahaman baik pro maupun kontra.

Pusat data

Segmen keamanan paling kritis.
Dan, seperti biasa, juga tidak ada solusi universal. Itu semua tergantung pada persyaratan jaringan.

Apakah firewall diperlukan atau tidak?

Tampaknya jawabannya jelas, tetapi semuanya tidak sejelas kelihatannya. Dan pilihan Anda mungkin terpengaruh tidak hanya oleh harga .

Contoh 1. Penundaan.

Jika antara beberapa segmen jaringan latensi rendah merupakan persyaratan penting, yang, misalnya, benar dalam kasus pertukaran, maka di antara segmen ini kami tidak akan dapat menggunakan firewall. Sulit untuk menemukan studi tentang keterlambatan firewall, tetapi hanya beberapa model sakelar yang dapat memberikan penundaan kurang dari atau sekitar 1 mksec, jadi saya pikir jika mikrodetik penting bagi Anda, maka firewall bukan untuk Anda.

Contoh 2. Kinerja.

Bandwidth dari switch L3 atas biasanya urutan besarnya lebih tinggi dari bandwidth firewall paling produktif. Oleh karena itu, dalam hal lalu lintas intensitas tinggi, kemungkinan besar Anda juga harus mengizinkan lalu lintas ini untuk mem-bypass firewall.

Contoh 3. Keandalan.

Firewall, terutama NGFW modern (Next-Generation FW) adalah perangkat yang kompleks. Mereka secara signifikan lebih kompleks daripada switch L3 / L2. Mereka menyediakan sejumlah besar opsi layanan dan konfigurasi, sehingga tidak mengherankan bahwa keandalannya jauh lebih rendah. Jika kelangsungan layanan sangat penting untuk jaringan, maka Anda mungkin harus memilih apa yang akan mengarah pada ketersediaan yang lebih baik - keamanan firewall atau kesederhanaan jaringan yang dibangun di atas sakelar (atau berbagai jenis pabrik) menggunakan ACL biasa.

Dalam kasus contoh di atas, Anda kemungkinan besar (seperti biasa) harus menemukan kompromi. Lihatlah ke solusi berikut:

• jika Anda memutuskan untuk tidak menggunakan firewall di dalam pusat data, maka Anda perlu mempertimbangkan cara membatasi akses ke perimeter 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 melompat. Pada host lompat, lakukan semua pemeriksaan yang diperlukan (otentikasi / otorisasi, antivirus, logging, ...)
• Anda dapat menggunakan partisi logis dari jaringan pusat data ke dalam segmen, mirip dengan skema yang dijelaskan dalam contoh PSEFABRIC p002 . Dalam hal ini, perutean harus dikonfigurasikan agar lalu lintas yang sensitif terhadap keterlambatan atau lalu lintas intensitas tinggi masuk "ke dalam" satu segmen (dalam kasus p002, VRF-a) dan tidak melewati firewall. Lalu lintas antara segmen yang berbeda masih akan melewati firewall. Anda juga dapat menggunakan rute bocor di antara VRF untuk menghindari mengarahkan lalu lintas melalui firewall.
• Anda juga dapat menggunakan firewall dalam mode transparan dan hanya untuk VLAN yang faktor-faktor ini (penundaan / kinerja) tidak signifikan. Tetapi Anda perlu mempelajari dengan cermat batasan yang terkait dengan penggunaan mod ini untuk setiap vendor
• Anda mungkin mempertimbangkan untuk menerapkan arsitektur rantai layanan. Ini akan memungkinkan Anda untuk mengarahkan hanya lalu lintas yang diperlukan melalui firewall. Secara teoritis terlihat indah, 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, tetapi pada saat itu solusi ini bagi kami “mentah”

Tingkat perlindungan

Sekarang Anda perlu menjawab pertanyaan tentang alat apa yang ingin Anda gunakan untuk menyaring lalu lintas. Berikut adalah beberapa fitur yang biasanya ada di NGFW (misalnya, di sini ):

• firewall stateful (default)
• firewall aplikasi
• pencegahan ancaman (antivirus, anti-spyware, dan kerentanan)
• Penyaringan URL
• pemfilteran data (pemfilteran konten)
• pemblokiran file (pemblokiran tipe file)
• perlindungan dos

Dan juga tidak semuanya jelas. Tampaknya semakin tinggi tingkat perlindungan, semakin baik. Tetapi Anda juga perlu mempertimbangkan itu

• semakin banyak fungsi firewall di atas yang Anda gunakan, secara alami akan lebih mahal (lisensi, modul tambahan)
• penggunaan algoritma tertentu dapat secara signifikan mengurangi throughput firewall, serta meningkatkan penundaan, lihat contohnya di sini
• seperti halnya solusi kompleks, penggunaan metode perlindungan yang kompleks dapat mengurangi keandalan solusi Anda, misalnya, ketika menggunakan firewall aplikasi saya menemukan pemblokiran beberapa aplikasi kerja yang cukup standar (dns, smb)

Anda, seperti biasa, perlu menemukan solusi terbaik untuk jaringan Anda.

Mustahil untuk menjawab pertanyaan tentang fungsi perlindungan apa yang mungkin diperlukan. Pertama, karena tentu saja tergantung pada data yang Anda transfer atau simpan dan coba lindungi. Kedua, pada kenyataannya, seringkali pilihan solusi adalah masalah iman dan kepercayaan pada vendor. Anda tidak tahu algoritme, Anda tidak tahu seberapa efektif mereka, dan Anda tidak dapat sepenuhnya mengujinya.

Oleh karena itu, di segmen-segmen kritis, solusi yang baik mungkin menggunakan tawaran dari berbagai perusahaan. Misalnya, Anda dapat mengaktifkan antivirus di firewall, tetapi juga menggunakan perlindungan antivirus (dari produsen lain) secara lokal di host.

Segmentasi

Ini adalah segmentasi logis dari jaringan pusat data. Misalnya, memisahkan ke dalam VLAN dan subnet juga merupakan segmentasi logis, tetapi kami tidak akan mempertimbangkannya karena kejelasannya. Segmentasi menarik dengan mempertimbangkan entitas seperti zona keamanan FW, VRF (dan analog mereka dalam kaitannya dengan berbagai vendor), perangkat logis (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...

Contoh segmentasi logis dan desain pusat data yang saat ini diperlukan diberikan pada p002 proyek PSEFABRIC .

Setelah menentukan bagian logis dari jaringan Anda, Anda dapat menggambarkan lebih lanjut bagaimana lalu lintas mengalir di antara berbagai segmen, di mana penyaringan perangkat 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, maka ini berarti bahwa ketika Anda membuka akses ini atau itu, Anda dipaksa untuk menyelesaikan masalah ini, dan dengan probabilitas tinggi Anda akan menyelesaikannya setiap kali dengan berbagai cara.

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 ini
• apakah lalu lintas intra-zona akan diizinkan secara default
• jika tidak, kebijakan penyaringan lalu lintas apa yang akan diterapkan di setiap zona
• kebijakan penyaringan lalu lintas apa yang akan diterapkan untuk setiap pasang zona (sumber / tujuan)

TCAM

Seringkali ada masalah kekurangan TCAM (Memori Alamat Addressable Ternary), baik untuk perutean maupun akses. IMHO, ini adalah salah satu masalah paling penting ketika memilih peralatan, jadi Anda harus memperlakukan masalah ini dengan tingkat akurasi yang tepat.

Contoh 1. Tabel Penerusan TCAM.

Mari kita lihat firewall Palo Alto 7k .
Kami melihat bahwa ukuran tabel penerusan IPv4 * = 32K
Pada saat yang sama, jumlah rute ini umum untuk semua VSYS.

Misalkan Anda memutuskan untuk menggunakan 4 VSYS sesuai dengan desain Anda.
Masing-masing BGPS VSYSs ini terhubung ke dua PE cloud MPLS yang Anda gunakan sebagai BB. Dengan demikian, 4 VSYS bertukar semua rute spesifik satu sama lain dan memiliki tabel penerusan dengan kira-kira set rute yang sama (tetapi NH berbeda). Karena setiap VSYS memiliki 2 sesi BGP (dengan pengaturan yang sama), maka 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 tahu tentang semua rute, maka ini berarti bahwa jumlah total rute di pusat data kami 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 "membentang" antara pusat data (misalnya, untuk vMotion), maka untuk menyelesaikan masalah perutean, kita harus menggunakan rute host, tetapi ini berarti bahwa untuk 2 pusat data kami tidak akan memiliki lebih dari 4096 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 menggunakan sakelar L3, misalnya, Cisco ACI), maka Anda harus memperhatikan TCAM ACL saat memilih peralatan.

Misalkan Anda ingin mengontrol akses pada antarmuka SVI dari Cisco Catalyst 4500. Kemudian, seperti yang Anda lihat dari artikel ini , Anda hanya dapat menggunakan 4.096 baris TCAM untuk mengontrol lalu lintas keluar (dan juga masuk) pada antarmuka. Apa saat menggunakan TCAM3 akan memberi Anda sekitar 4000 ribu ACE (garis ACL).

Jika Anda dihadapkan dengan masalah TCAM tidak mencukupi, maka, pertama-tama, tentu saja, Anda perlu mempertimbangkan kemungkinan optimasi. Jadi, jika terjadi masalah dengan ukuran Tabel Penerusan, Anda perlu mempertimbangkan kemungkinan menggabungkan rute. Dalam kasus masalah dengan ukuran TCAM untuk akses - audit akses, penghapusan catatan usang dan tumpang tindih, serta, mungkin, revisi prosedur untuk membuka akses (itu akan dibahas secara rinci dalam bab tentang audit akses).

Ketersediaan tinggi

Pertanyaannya adalah apakah akan menggunakan HA untuk firewall atau untuk meletakkan dua kotak independen "paralel" dan jika salah satu dari mereka crash, rute lalu lintas melalui yang kedua?

Tampaknya jawabannya jelas - gunakan HA. Alasan mengapa pertanyaan ini tetap muncul adalah bahwa, sayangnya, teori dan periklanan 99 dan beberapa angka sembilan setelah titik desimal dari persentase aksesibilitas dalam praktik ternyata jauh lebih indah. HA adalah hal yang agak rumit secara logis, dan pada peralatan yang berbeda, dan dengan vendor yang berbeda (tidak ada pengecualian), kami menangkap masalah dan bug serta penghentian layanan.

Dalam hal menggunakan HA, Anda akan dapat mematikan masing-masing node, beralih di antara mereka tanpa menghentikan layanan, yang penting, misalnya, ketika memutakhirkan, tetapi Anda sama sekali tidak memiliki kesempatan nol bahwa kedua node akan pecah pada waktu yang sama, dan juga bahwa selanjutnya upgrade tidak akan berjalan semulus yang dijanjikan vendor (masalah ini dapat dihindari jika Anda memiliki kesempatan untuk menguji peningkatan pada peralatan laboratorium).

Jika Anda tidak menggunakan HA, maka dari sudut pandang kerusakan ganda risiko Anda jauh lebih rendah (karena Anda memiliki 2 firewall independen), tetapi karena Karena sesi tidak disinkronkan, maka setiap kali ketika beralih di antara firewall ini terjadi, Anda akan kehilangan lalu lintas. Anda bisa, tentu saja, menggunakan firewall stateless, tetapi kemudian arti menggunakan firewall sebagian besar hilang.

Oleh karena itu, jika sebagai hasil audit Anda menemukan firewall yang kesepian, dan Anda berpikir untuk meningkatkan keandalan jaringan Anda, maka HA, tentu saja, adalah salah satu solusi yang disarankan, tetapi Anda juga harus mempertimbangkan kerugian yang terkait dengan pendekatan ini dan, mungkin, hanya untuk Anda solusi lain akan lebih tepat.

Kenyamanan dalam manajemen (pengelolaan)

Pada prinsipnya, HA juga tentang pengelolaan. Alih-alih mengonfigurasi 2 kotak secara terpisah dan menyelesaikan masalah sinkronisasi pengaturan, Anda mengelolanya dengan berbagai cara seolah-olah Anda memiliki satu perangkat.

Tetapi mungkin Anda memiliki banyak pusat data dan banyak firewall, maka pertanyaan ini naik ke tingkat yang baru. Dan pertanyaannya bukan hanya tentang konfigurasi, tetapi juga tentang

• konfigurasi cadangan
• pembaruan
• upgrade
• pemantauan
• logging

Dan semua ini dapat diselesaikan dengan sistem manajemen terpusat.

Jadi, misalnya, jika Anda menggunakan firewall Palo Alto, maka Panorama adalah solusi semacam itu.

Untuk dilanjutkan.