Cara menggabungkan dengan aman segmen jaringan dari tiga bank besar: trik berbagi

Beberapa waktu lalu, di bawah merek VTB, tiga bank besar bergabung: VTB, ex-VTB24, dan mantan Bank Moskow. Untuk pengamat eksternal, bank VTB gabungan sekarang bekerja secara keseluruhan, tetapi dari dalam, semuanya terlihat jauh lebih rumit. Dalam posting ini, kita akan berbicara tentang rencana untuk membuat jaringan terpadu bank VTB terintegrasi, berbagi peretasan kehidupan dalam mengatur interaksi firewall, menghubungkan dan menggabungkan segmen jaringan tanpa mengganggu layanan.

Kesulitan dalam interaksi infrastruktur yang berbeda

Operasi VTB saat ini didukung oleh tiga infrastruktur warisan: ex-Bank of Moscow, ex-VTB24 dan VTB sendiri. Infrastruktur masing-masing memiliki perimeter jaringan mereka sendiri, di perbatasan yang ada peralatan pelindung. Salah satu syarat untuk mengintegrasikan infrastruktur di tingkat jaringan adalah keberadaan struktur pengalamatan IP yang konsisten.

Segera setelah penggabungan, kami mulai menyelaraskan ruang alamat, dan sekarang hampir selesai. Tetapi prosesnya memakan waktu dan cepat, dan tenggat waktu untuk mengatur lintas-akses antar infrastruktur sangat ketat. Oleh karena itu, pada tahap pertama, kami menghubungkan infrastruktur bank yang berbeda satu sama lain dalam bentuk sebagaimana adanya - melalui cara firewall untuk sejumlah zona keamanan utama. Menurut skema ini, untuk mengatur akses dari satu perimeter jaringan ke yang lain, perlu untuk mengarahkan lalu lintas melalui banyak firewall dan cara perlindungan lainnya, disiarkan di alamat sambungan sumber daya dan pengguna yang menggunakan teknologi NAT dan PAT. Selain itu, semua firewall di persimpangan dicadangkan baik secara lokal maupun geografis, dan ini harus selalu diperhitungkan ketika mengatur interaksi dan membangun rantai layanan.

Skema semacam itu cukup fungsional, tetapi Anda tentu tidak bisa menyebutnya optimal. Ada masalah teknis dan organisasi. Penting untuk mengoordinasikan dan mendokumentasikan interaksi banyak sistem yang komponen-komponennya tersebar di berbagai infrastruktur dan zona keamanan. Pada saat yang sama, dalam proses transformasi infrastruktur, perlu untuk segera memperbarui dokumentasi ini untuk setiap sistem. Melakukan proses ini sangat memuat sumber daya kami yang paling berharga - spesialis yang sangat berkualitas.

Masalah teknis diekspresikan dalam penggandaan lalu lintas pada tautan, beban alat keamanan yang tinggi, kompleksitas mengatur interaksi jaringan, ketidakmampuan untuk membuat beberapa interaksi tanpa terjemahan alamat.

Masalah multiplikasi lalu lintas muncul terutama karena banyak zona keamanan berinteraksi satu sama lain melalui firewall di situs yang berbeda. Terlepas dari lokasi geografis server itu sendiri, jika lalu lintas melampaui batas zona keamanan, itu akan melalui serangkaian fitur keamanan yang mungkin ada di lokasi lain. Sebagai contoh, kami memiliki dua server di satu pusat data, tetapi satu di perimeter VTB, dan yang lain di perimeter jaringan ex-VTB24. Lalu lintas di antara mereka tidak langsung, tetapi melewati 3-4 firewall yang dapat aktif di pusat data lainnya, dan lalu lintas akan dikirim ke firewall dan kembali beberapa kali melalui jaringan trunk.

Untuk memastikan keandalan yang tinggi, kami membutuhkan setiap firewall dalam 3-4 salinan - dua di satu situs dalam bentuk cluster HA dan satu atau dua firewall di situs lain, yang lalu lintasnya akan beralih jika cluster firewall utama atau situs secara keseluruhan terganggu.

Kami meringkas. Tiga jaringan independen adalah sejumlah besar masalah : kompleksitas yang berlebihan, kebutuhan untuk peralatan tambahan yang mahal, kemacetan, kesulitan redundansi dan, sebagai akibatnya, biaya tinggi untuk mengoperasikan infrastruktur.

Pendekatan integrasi umum

Karena kami memutuskan untuk melakukan transformasi arsitektur jaringan, kami akan mulai dengan hal-hal dasar. Mari kita beralih dari atas ke bawah, kita akan mulai dengan menganalisis persyaratan bisnis, pelamar, insinyur sistem, dan personel keamanan.

• Berdasarkan kebutuhan mereka, kami merancang struktur target zona keamanan dan prinsip-prinsip interkoneksi antara zona-zona ini.
  
• Kami memaksakan struktur zona ini pada geografi konsumen utama kami - pusat data dan kantor besar.
  
• Selanjutnya, kami membentuk jaringan transportasi MPLS.
  
• Di bawahnya, kami telah membawa jaringan utama yang menyediakan layanan ke lapisan fisik.
  
• Kami memilih lokasi untuk penempatan modul tepi dan modul firewall.
  
• Setelah gambar target diklarifikasi, kami bekerja dan menyetujui metodologi migrasi dari infrastruktur yang ada ke infrastruktur target sehingga prosesnya transparan untuk sistem kerja.
  

Konsep jaringan target

Kami akan memiliki jaringan backbone utama - ini adalah infrastruktur transportasi telekomunikasi yang didasarkan pada jalur komunikasi serat optik (FOCL), peralatan pembentukan saluran pasif dan aktif. Itu juga dapat menggunakan subsistem densifikasi saluran optik xWDM dan, mungkin, jaringan SDH.

Berdasarkan jaringan primer, kami sedang membangun apa yang disebut jaringan inti . Ini akan memiliki rencana alamat tunggal dan satu set protokol routing. Jaringan inti meliputi:

• MPLS - jaringan multiservice;
  
• DCI - tautan antara pusat data;
  
• Modul EDGE - berbagai modul koneksi: firewall, organisasi mitra, saluran internet, pusat data, LAN, jaringan regional.
  

Kami membuat jaringan multiservice sesuai dengan prinsip hierarkis dengan alokasi node transit (P) dan end (PE) . Selama analisis awal dari peralatan yang tersedia di pasaran saat ini, menjadi jelas bahwa akan lebih layak secara ekonomis untuk mentransfer level P-node ke peralatan yang terpisah daripada menggabungkan fungsi P / PE dalam satu perangkat.

Jaringan multiservice akan memiliki ketersediaan tinggi, toleransi kesalahan, waktu konvergensi minimum, skalabilitas, kinerja tinggi dan fungsionalitas, khususnya IPv6 dan dukungan multicast.

Selama pembangunan jaringan backbone, kami bermaksud untuk meninggalkan teknologi berpemilik (jika mungkin tanpa mengurangi kualitas), karena kami berusaha untuk membuat solusi fleksibel dan tidak terikat pada vendor tertentu. Tetapi pada saat yang sama kami tidak ingin membuat "vinaigrette" dari peralatan berbagai vendor. Prinsip desain dasar kami adalah untuk menyediakan jumlah layanan maksimum saat menggunakan peralatan yang minimal memadai untuk jumlah vendor ini. Ini akan memungkinkan, antara lain, untuk mengatur pemeliharaan infrastruktur jaringan, menggunakan jumlah personel yang terbatas. Penting juga bahwa peralatan baru tersebut kompatibel dengan peralatan yang ada untuk memastikan proses migrasi yang lancar.

Struktur zona keamanan jaringan VTB, ex-VTB24 dan ex-Bank Moskow dalam kerangka proyek ini direncanakan akan sepenuhnya dirancang ulang dengan tujuan menggabungkan segmen duplikat fungsional. Struktur terpadu zona keamanan dengan aturan perutean umum dan konsep terpadu akses internetwork direncanakan. Kami berencana untuk melakukan firewall di antara zona keamanan menggunakan firewall perangkat keras terpisah, yang ditempatkan di dua lokasi utama. Kami juga berencana untuk menerapkan semua modul tepi secara independen di dua situs yang berbeda dengan redundansi otomatis di antara mereka berdasarkan protokol routing dinamis standar.

Kami mengatur pengelolaan peralatan jaringan inti melalui jaringan fisik yang terpisah (out-of-band). Akses administratif ke semua peralatan jaringan akan diberikan melalui satu layanan otentikasi, otorisasi, dan akuntansi (AAA).

Untuk dengan cepat menemukan masalah dalam jaringan, sangat penting untuk dapat menyalin lalu lintas dari titik mana pun dalam jaringan untuk dianalisis dan mengirimkannya ke penganalisa melalui saluran komunikasi independen. Untuk melakukan ini, kami akan membuat jaringan terisolasi untuk lalu lintas SPAN, dengan bantuan yang akan kami kumpulkan, saring, dan kirimkan arus lalu lintas ke server analytics.

Untuk membakukan layanan yang disediakan oleh jaringan dan kemungkinan mengalokasikan biaya, kami akan memperkenalkan katalog tunggal dengan indikator SLA. Kami beralih ke model layanan, di mana kami mempertimbangkan interkoneksi infrastruktur jaringan dengan tugas yang diterapkan, interkoneksi elemen aplikasi kontrol, dan dampaknya terhadap layanan. Dan model layanan ini didukung oleh sistem pemantauan jaringan sehingga kami dapat mengalokasikan biaya TI dengan benar.

Dari teori ke praktik

Sekarang kami akan turun satu tingkat dan memberi tahu Anda tentang solusi paling menarik di infrastruktur baru kami yang mungkin berguna bagi Anda.

Hutan Sumberdaya: Detail

Kami sudah berkenalan dengan penduduk Khabrovsk dengan hutan sumber daya VTB. Sekarang coba berikan deskripsi teknis yang lebih rinci.



Misalkan kita memiliki dua (untuk kesederhanaan) infrastruktur jaringan organisasi yang berbeda yang perlu digabungkan. Dalam setiap infrastruktur, sebagai aturan, di antara sekumpulan segmen jaringan fungsional (zona keamanan), orang dapat membedakan segmen jaringan produktif utama, di mana sistem industri utama berada. Kami menghubungkan zona produktif ini ke struktur segmen kunci tertentu, yang kami sebut “hutan sumber daya” . Segmen gateway ini menerbitkan sumber daya bersama yang tersedia dari dua infrastruktur.

Konsep hutan sumber daya, dari sudut pandang jaringan, adalah untuk menciptakan zona keamanan gateway yang terdiri dari dua IP VPN (untuk kasus dua bank). IP VPN ini disalurkan secara bebas di antara mereka sendiri dan terhubung melalui firewall ke segmen produktif. Pengalamatan IP untuk segmen ini dipilih dari berbagai alamat IP yang terpisah. Dengan demikian, rute menuju hutan sumber daya menjadi mungkin dari jaringan kedua organisasi.

Tetapi dengan perutean dari hutan sumber daya ke segmen industri, situasinya agak lebih buruk, karena pengalamatan di dalamnya sering bersinggungan dan tidak mungkin untuk membentuk satu tabel tunggal. Untuk mengatasi masalah ini, kita hanya perlu dua segmen di hutan sumber daya. Di setiap segmen hutan sumber daya, rute default ditulis menuju jaringan industri organisasi "mereka". Artinya, pengguna dapat mengakses tanpa menerjemahkan alamat ke segmen “milik sendiri” dari hutan sumber daya dan ke segmen lain melalui PAT.

Dengan demikian, dua segmen hutan sumber daya mewakili zona keamanan gateway tunggal, jika Anda menggambar perbatasan di sepanjang firewall. Masing-masing dari mereka memiliki perutean sendiri: gateway default melihat ke arah bank "nya". Jika kita menempatkan sumber daya di beberapa segmen hutan sumber daya, maka pengguna bank terkait dapat berinteraksi dengannya tanpa NAT.

Interaksi tanpa NAT sangat penting untuk banyak sistem dan, pertama-tama, untuk interaksi domain Microsoft - setelah semua, di hutan sumber daya kami memiliki server Direktori Aktif untuk domain bersama yang baru, kepercayaan yang dibuat oleh kedua organisasi. Juga, tanpa interaksi NAT, sistem seperti Skype for Business, ABS "MBANK" dan banyak aplikasi lainnya diperlukan, di mana server kembali ke alamat klien. Dan jika klien berada di belakang PAT, koneksi balik tidak lagi dibuat.

Server yang kami pasang di segmen hutan sumber daya dibagi menjadi dua kategori: infrastruktur (misalnya, server MS AD) dan menyediakan akses ke beberapa sistem informasi. Jenis server terakhir yang kami sebut Data Mart. Etalase biasanya merupakan server web, yang bagian belakangnya sudah ada di belakang firewall di jaringan produksi organisasi yang membuat etalase ini di hutan sumber daya.

Dan bagaimana cara pengguna disahkan saat mengakses sumber daya yang dipublikasikan? Jika kami hanya menyediakan akses ke beberapa aplikasi untuk satu atau dua pengguna di domain lain, maka kami dapat membuat akun terpisah untuk otentikasi di domain kami untuk mereka. Tetapi ketika kita berbicara tentang penggabungan besar-besaran infrastruktur - katakanlah, 50 ribu pengguna - sama sekali tidak realistis untuk memulai dan memelihara cross-account terpisah untuk mereka. Menciptakan kepercayaan langsung antara hutan berbagai organisasi juga tidak selalu memungkinkan, baik untuk alasan keamanan maupun karena kebutuhan untuk membuat pengguna PAT dalam kondisi ruang alamat yang bersinggungan. Oleh karena itu, untuk menyelesaikan masalah otentikasi pengguna terpadu, hutan MS AD baru yang terdiri dari satu domain dibuat di perimeter hutan sumber daya. Di domain baru ini, pengguna mengautentikasi saat mengakses layanan. Untuk memungkinkan ini, kepercayaan tingkat hutan bilateral dibentuk antara hutan baru dan hutan domain dari masing-masing organisasi. Dengan demikian, pengguna dari salah satu organisasi dapat mengautentikasi pada sumber daya apa pun yang dipublikasikan.

Mendapatkan Integrasi Jaringan

Setelah kami membangun interaksi sistem melalui infrastruktur hutan sumber daya dan dengan demikian menghilangkan gejala akut, sudah waktunya untuk mengambil integrasi langsung dari jaringan.

Untuk melakukan ini, pada tahap pertama, kami menghubungkan segmen produk dari tiga bank ke firewall kuat tunggal (secara logis bersatu, tetapi secara fisik berkali-kali dicadangkan di situs yang berbeda). Firewall menyediakan interaksi langsung antara sistem bank yang berbeda.

Dengan ex-VTB24, sebelum mengatur interaksi langsung antara sistem, kami sudah berhasil menyelaraskan ruang alamat. Setelah membentuk tabel routing pada firewall dan membuka akses yang sesuai, kami dapat memastikan interaksi antara sistem dalam dua infrastruktur yang berbeda.

Dengan mantan Bank Moskow, ruang alamat pada saat organisasi interaksi terapan tidak selaras, dan kami harus menggunakan NAT timbal balik untuk mengatur interaksi sistem. Menggunakan NAT menciptakan sejumlah masalah resolusi DNS yang diselesaikan dengan pemeliharaan zona DNS duplikat. Selain itu, karena NAT, ada kesulitan dengan pengoperasian sejumlah sistem aplikasi. Sekarang kita hampir menghilangkan persimpangan ruang alamat, tetapi kita dihadapkan pada kenyataan bahwa banyak sistem VTB dan ex-Bank of Moscow terikat erat untuk berinteraksi pada alamat yang diterjemahkan. Sekarang kita perlu memigrasikan interaksi ini ke alamat IP nyata dengan tetap menjaga kelangsungan bisnis.

Penghapusan NAT

Di sini tujuan kami adalah untuk memastikan pengoperasian sistem dalam ruang alamat tunggal untuk integrasi lebih lanjut dari kedua layanan infrastruktur (MS AD, DNS) dan aplikasi (Skype for Business, MBANK). Sayangnya, karena beberapa sistem aplikasi sudah terikat satu sama lain di alamat yang diterjemahkan, pekerjaan individu dengan masing-masing sistem aplikasi diperlukan untuk menghilangkan NAT untuk interaksi spesifik.

Terkadang Anda dapat melakukan trik semacam itu : atur server yang sama pada saat yang sama baik di bawah alamat yang diterjemahkan maupun di bawah yang asli. Jadi, administrator aplikasi dapat menguji kerja di alamat asli sebelum migrasi, mencoba beralih ke interaksi non-NAT sendiri, dan memutar kembali jika perlu. Pada saat yang sama, kami memantau firewall menggunakan fungsi packet capture untuk melihat apakah ada yang berkomunikasi dengan server melalui alamat yang diterjemahkan. Segera setelah komunikasi tersebut berhenti, kami, dalam perjanjian dengan pemilik sumber daya, menghentikan siaran: server hanya memiliki alamat asli.

Setelah parsing NAT, sayangnya, untuk beberapa waktu akan diperlukan untuk menjaga firewall antara segmen yang identik secara fungsional, karena tidak semua zona memenuhi standar keamanan yang sama. Setelah menstandarisasi segmen, firewall antara segmen diganti dengan perutean dan zona keamanan yang identik secara fungsional bergabung bersama.

Firewall

Mari kita beralih ke masalah firewall internetwork. Pada prinsipnya, ini relevan untuk organisasi besar mana pun yang perlu memberikan toleransi kesalahan baik lokal maupun global dari peralatan pelindung.



Mari kita coba merumuskan masalah reservasi firewall secara umum. Kami memiliki dua situs: situs 1 dan situs 2. Ada beberapa (misalnya, tiga) MPLS IP VPN yang berkomunikasi satu sama lain melalui firewall stateful. Firewall ini perlu dicadangkan secara lokal dan geografis.

Kami tidak akan mempertimbangkan masalah cadangan lokal firewall, hampir semua produsen menyediakan kemampuan untuk merakit firewall menjadi cluster HA lokal. Adapun reservasi geografis firewall, praktis tidak ada vendor memiliki tugas ini di luar kotak.

Tentu saja, Anda dapat "meregangkan" kluster firewall di beberapa situs sepanjang L2, tetapi kemudian klaster ini akan mewakili satu titik kegagalan dan keandalan solusi kami tidak akan terlalu tinggi. Karena cluster terkadang membeku sepenuhnya karena kesalahan perangkat lunak, atau jatuh ke dalam keadaan otak terpecah karena putusnya hubungan L2 antar situs. Karena itu, kami segera menolak untuk meregangkan kluster firewall di atas L2.

Kami perlu membuat skema di mana jika modul firewall gagal di satu situs, transisi otomatis ke situs lain akan terjadi. Begini cara kami melakukannya.

Diputuskan untuk tetap berpegang pada model cadangan geo Active / Standby ketika cluster aktif terletak di situs yang sama. Jika tidak, kami segera mengalami masalah dengan perutean asimetris, yang sulit untuk diselesaikan dengan sejumlah besar L3 VPN.

Cluster firewall aktif harus memberi sinyal operasi yang benar. Sebagai metode pensinyalan, kami memilih pengumuman OSPF dari firewall ke jaringan rute pengujian (bendera) dengan mask / 32. Peralatan jaringan di situs 1 memonitor keberadaan rute ini dari firewall dan, jika tersedia, mengaktifkan perutean statis (misalnya, 0.0.0.0 / 0), menuju kluster firewall ini. Rute default statis ini kemudian ditempatkan (melalui redistribusi) ke dalam tabel protokol BGP MP dan didistribusikan ke seluruh jaringan backbone. , OSPF , , IP VPN.

, , , .

1 - , , 1 , 2 — . , , VPN' . , , , .

, active/standby. active-. , . , (, IP- ). . . .

L3 , . .

. , , — , , . L3-, .

, IP-. MPLS VPN. MPLS VPN «IN» VPN «OUT». VPN HUB-and-spoke VPN. Spoke HUB' VPN, .

«IN» - Spoke VPN' VPN. «OUT» Spoke VPN' .

MPLS VPN «IN». VPN . VPN HUB-VPN «IN» . . , Policy Based Routing. VPN «OUT», VPN «OUT» Spoke-VPN.



VPN, . MPLS import / export HUB VPN.

VPN , — , VLAN, ..

Kesimpulan

, , . , , , . .