Cara konsolidasi arsip bekerja di DeviceLock DLP

Belum lama ini, kami merilis versi minor baru 8.3.75005 dari paket perangkat lunak pencegahan kebocoran data DeviceLock DLP dan, di antara perbaikan lainnya, termasuk fungsi konsolidasi data dari server penyimpanan yang cukup berguna untuk perusahaan besar.



Saya ingin berbicara tentang konsolidasi sedikit lagi ...


Pertama, sedikit tentang bagaimana pengumpulan dan penyimpanan data yang dicegat diatur dalam DeviceLock DLP. Menjadi solusi agen untuk mencegah kebocoran informasi, DeviceLock DLP mencegat, menganalisis dan mengaktifkan / menonaktifkan transfer data langsung ke komputer pengguna menggunakan agen. Selain mencegat, menganalisis, dan memutuskan apakah akan mengizinkan / menolak transfer, agen juga dapat (jika ditentukan oleh kebijakan) mengakumulasi data audit dan bayangan (salinan informasi yang dikirimkan oleh pengguna).


Server penyimpanan DeviceLock Enterprise Server (DLES) digunakan untuk penyimpanan terpusat dan selanjutnya analisis data yang diakumulasikan oleh agen (misalnya, pelaporan, pencarian arsip, dll.). Sejumlah besar server semacam itu dapat diinstal di organisasi (kami tidak membatasi jumlah mereka pada lisensi), yang memungkinkan Anda untuk mendistribusikan beban secara merata pada segmen jaringan individual dan meminimalkan waktu pengumpulan data dari agen. Untuk agen, beberapa server DLES dapat ditentukan dan aturan untuk memilih server saat mentransfer data yang terakumulasi ke arsip ditentukan. Setiap DeviceLock Enterprise Server terhubung ke server SQL dan menyimpan datanya dalam database terpisah. Selain itu, beberapa server penyimpanan dapat dihubungkan ke satu server SQL.



Jika suatu organisasi memiliki beberapa cabang, skema yang paling sering digunakan adalah ketika setiap cabang memiliki server sendiri (atau beberapa server) untuk penyimpanan, dan akumulasi data mengalir ke kantor pusat sesuai dengan jadwal yang ditentukan (sekali sehari, seminggu, dll.).


Sebelum rilis pembaruan ini, replikasi data dapat dilakukan dengan menggunakan server SQL, yang tidak terlalu baik dari sudut pandang kenyamanan umum pengaturan kompleks. Ketidakpastian replikasi terutama terbukti dalam situasi ketika beberapa server penyimpanan terhubung ke server SQL yang sama.


Sekarang kami mengusulkan untuk menggunakan fungsi konsolidasi, yang jauh lebih mudah untuk dikonfigurasi dan digunakan, di mana replikasi data terjadwal dilakukan secara eksklusif oleh alat DeviceLock Enterprise Server bawaan.


Saya akan menunjukkan contoh "langsung" konfigurasi dasar konsolidasi data akumulasi dari empat server penyimpanan ke server utama.



Diagram di atas menunjukkan bahwa dua server (Test28-w10x64 dan PC-55OSI) terhubung ke satu SQL server (SQL2), sedangkan dua server lainnya (VSamsonov-PC dan mamaev-pc) masing-masing terhubung ke server SQL mereka sendiri (SQL1) dan SQL3, masing-masing). Replikasi data akan dilakukan pada server master DLSRV yang terhubung ke SQL-master.


Untuk mengatur jadwal dan menunjukkan server master di mana data harus direplikasi, parameter konsolidasi harus ditetapkan pada masing-masing Test28-w10x64, PC-55OSI, VSamsonov-PC dan server mamaev-pc.



Di antara hal-hal lain, Anda juga dapat menunjukkan apa yang sebenarnya perlu direplikasi (log mana), apakah akan menyalin data atau mentransfernya, untuk membentuk saluran jaringan atau memberikannya untuk konsolidasi secara keseluruhan.


Setelah berhasil membangun koneksi antara "hilir" dan server utama, statistik konsolidasi akan muncul di antarmuka yang terakhir.



Anda dapat melihat data yang dikumpulkan, seperti biasa, di penampil standar log terkait. Misalnya, untuk salinan salinan bayangan, akan terlihat seperti ini:



Server asli yang mengumpulkan data dari agen ditampilkan di kolom Server di sini.


Secara terpisah, saya ingin mencatat bahwa "tingkat sarang" konsolidasi tidak terbatas. Jika akan diperlukan untuk mereplikasi data dari DLSRV di tempat lain "naik", maka cukup dalam pengaturan konsolidasi untuk DLSRV Anda perlu mendaftarkan "server upstream". Dan hampir ad infinitum;)

Source: https://habr.com/ru/post/id439010/


All Articles