Pemantauan Keselamatan Awan

Memindahkan data dan aplikasi ke awan memberikan cabaran baharu untuk SOC korporat, yang tidak sentiasa bersedia untuk memantau infrastruktur orang lain. Menurut Netoskope, perusahaan purata (nampaknya di AS) menggunakan 1246 perkhidmatan awan yang berbeza, iaitu 22% lebih daripada setahun yang lalu. 1246 perkhidmatan awan!!! 175 daripadanya berkaitan dengan perkhidmatan HR, 170 berkaitan pemasaran, 110 dalam bidang komunikasi dan 76 dalam bidang kewangan dan CRM. Cisco menggunakan "hanya" 700 perkhidmatan awan luaran. Jadi saya agak keliru dengan nombor ini. Tetapi dalam apa jua keadaan, masalahnya bukan pada mereka, tetapi dengan fakta bahawa awan mula digunakan dengan agak aktif oleh semakin banyak syarikat yang ingin mempunyai keupayaan yang sama untuk memantau infrastruktur awan seperti dalam rangkaian mereka sendiri. Dan trend ini berkembang - mengikut menurut Dewan Akaun Amerika Menjelang 2023, 1200 pusat data akan ditutup di Amerika Syarikat (6250 telah ditutup). Tetapi peralihan kepada awan bukan sekadar "mari alihkan pelayan kami ke pembekal luaran." Seni bina IT baharu, perisian baharu, proses baharu, sekatan baharu... Semua ini membawa perubahan ketara kepada kerja bukan sahaja IT, tetapi juga keselamatan maklumat. Dan jika pembekal telah belajar untuk entah bagaimana mengatasi memastikan keselamatan awan itu sendiri (nasib baik terdapat banyak cadangan), maka dengan pemantauan keselamatan maklumat awan, terutamanya pada platform SaaS, terdapat kesukaran yang ketara, yang akan kita bincangkan.

Katakan syarikat anda telah memindahkan sebahagian daripada infrastrukturnya ke awan... Berhenti. Bukan dengan cara ini. Jika infrastruktur telah dipindahkan, dan anda hanya memikirkan bagaimana anda akan memantaunya, maka anda telah pun kalah. Melainkan Amazon, Google atau Microsoft (dan kemudian dengan tempahan), anda mungkin tidak mempunyai banyak keupayaan untuk memantau data dan aplikasi anda. Adalah baik jika anda diberi peluang untuk bekerja dengan log. Kadangkala data acara keselamatan akan tersedia, tetapi anda tidak akan mempunyai akses kepadanya. Contohnya, Office 365. Jika anda mempunyai lesen E1 termurah, maka acara keselamatan tidak tersedia untuk anda sama sekali. Jika anda mempunyai lesen E3, data anda disimpan selama 90 hari sahaja, dan hanya jika anda mempunyai lesen E5, tempoh log tersedia selama setahun (namun, ini juga mempunyai nuansa tersendiri yang berkaitan dengan keperluan untuk secara berasingan meminta beberapa fungsi untuk bekerja dengan log daripada sokongan Microsoft). Ngomong-ngomong, lesen E3 jauh lebih lemah dari segi fungsi pemantauan daripada Bursa korporat. Untuk mencapai tahap yang sama, anda memerlukan lesen E5 atau lesen Pematuhan Lanjutan tambahan, yang mungkin memerlukan wang tambahan yang tidak diambil kira dalam model kewangan anda untuk beralih ke infrastruktur awan. Dan ini hanyalah satu contoh meremehkan isu yang berkaitan dengan pemantauan keselamatan maklumat awan. Dalam artikel ini, tanpa berpura-pura lengkap, saya ingin menarik perhatian kepada beberapa nuansa yang harus diambil kira apabila memilih penyedia awan dari sudut pandangan keselamatan. Dan pada akhir artikel, senarai semak akan diberikan yang patut dilengkapkan sebelum mempertimbangkan isu pemantauan keselamatan maklumat awan telah diselesaikan.

Terdapat beberapa masalah biasa yang membawa kepada insiden dalam persekitaran awan, yang perkhidmatan keselamatan maklumat tidak mempunyai masa untuk bertindak balas atau tidak melihatnya sama sekali:

• Log keselamatan tidak wujud. Ini adalah situasi yang agak biasa, terutamanya dalam kalangan pemain baru dalam pasaran penyelesaian awan. Tetapi anda tidak sepatutnya berputus asa dengan mereka dengan serta-merta. Pemain kecil, terutamanya yang domestik, lebih sensitif terhadap keperluan pelanggan dan boleh melaksanakan beberapa fungsi yang diperlukan dengan cepat dengan menukar peta jalan yang diluluskan untuk produk mereka. Ya, ini tidak akan menjadi analog GuardDuty dari Amazon atau modul "Perlindungan Proaktif" dari Bitrix, tetapi sekurang-kurangnya sesuatu.
• Keselamatan maklumat tidak tahu di mana log disimpan atau tiada akses kepadanya. Di sini adalah perlu untuk mengadakan rundingan dengan penyedia perkhidmatan awan - mungkin dia akan memberikan maklumat sedemikian jika dia menganggap pelanggan penting kepadanya. Tetapi secara umum, ia tidak begitu baik apabila akses kepada log disediakan "oleh keputusan khas."
• Ia juga berlaku bahawa pembekal awan mempunyai log, tetapi mereka menyediakan pemantauan dan rakaman acara terhad, yang tidak mencukupi untuk mengesan semua kejadian. Sebagai contoh, anda hanya boleh menerima log perubahan pada tapak web atau log percubaan pengesahan pengguna, tetapi bukan peristiwa lain, seperti trafik rangkaian, yang akan menyembunyikan daripada anda seluruh lapisan peristiwa yang mencirikan percubaan untuk menggodam infrastruktur awan anda.
• Terdapat log, tetapi akses kepada mereka adalah sukar untuk mengautomasikan, yang memaksa mereka untuk dipantau bukan secara berterusan, tetapi mengikut jadual. Dan jika anda tidak boleh memuat turun log secara automatik, kemudian memuat turun log, contohnya, dalam format Excel (seperti dengan beberapa penyedia penyelesaian awan domestik), malah boleh menyebabkan keengganan di pihak perkhidmatan keselamatan maklumat korporat untuk bermain-main dengan mereka.
• Tiada pemantauan log. Ini mungkin sebab yang paling tidak jelas untuk berlakunya insiden keselamatan maklumat dalam persekitaran awan. Nampaknya terdapat log, dan adalah mungkin untuk mengautomasikan akses kepada mereka, tetapi tiada siapa yang melakukan ini. kenapa?

Konsep keselamatan awan yang dikongsi

Peralihan kepada awan sentiasa mencari keseimbangan antara keinginan untuk mengekalkan kawalan ke atas infrastruktur dan memindahkannya ke tangan pembekal awan yang lebih profesional yang pakar dalam mengekalkannya. Dan dalam bidang keselamatan awan, keseimbangan ini juga mesti dicari. Selain itu, bergantung pada model penyampaian perkhidmatan awan yang digunakan (IaaS, PaaS, SaaS), baki ini akan berbeza sepanjang masa. Walau apa pun, kita mesti ingat bahawa semua penyedia awan hari ini mengikut apa yang dipanggil tanggungjawab bersama dan model keselamatan maklumat yang dikongsi. Awan bertanggungjawab untuk beberapa perkara, dan untuk yang lain, pelanggan bertanggungjawab, meletakkan datanya, aplikasinya, mesin mayanya dan sumber lain dalam awan. Adalah melulu untuk menjangkakan bahawa dengan pergi ke awan, kami akan mengalihkan semua tanggungjawab kepada pembekal. Tetapi adalah tidak bijak untuk membina sendiri semua keselamatan apabila berpindah ke awan. Keseimbangan diperlukan, yang bergantung pada banyak faktor: - strategi pengurusan risiko, model ancaman, mekanisme keselamatan yang tersedia untuk penyedia awan, perundangan, dsb.

Sebagai contoh, klasifikasi data yang dihoskan dalam awan sentiasa menjadi tanggungjawab pelanggan. Pembekal awan atau pembekal perkhidmatan luaran hanya boleh membantunya dengan alatan yang akan membantu menandai data dalam awan, mengenal pasti pelanggaran, memadamkan data yang melanggar undang-undang atau menyembunyikannya menggunakan satu kaedah atau kaedah yang lain. Sebaliknya, keselamatan fizikal sentiasa menjadi tanggungjawab penyedia awan, yang tidak boleh dikongsi dengan pelanggan. Tetapi segala-galanya yang ada di antara data dan infrastruktur fizikal adalah subjek perbincangan dalam artikel ini. Sebagai contoh, ketersediaan awan adalah tanggungjawab pembekal, dan menyediakan peraturan tembok api atau mendayakan penyulitan adalah tanggungjawab pelanggan. Dalam artikel ini, kami akan cuba melihat mekanisme pemantauan keselamatan maklumat yang disediakan hari ini oleh pelbagai penyedia awan popular di Rusia, apakah ciri penggunaannya, dan bilakah ia patut melihat ke arah penyelesaian tindanan luaran (contohnya, Cisco E- mail Security) yang mengembangkan keupayaan awan anda dari segi keselamatan siber. Dalam sesetengah kes, terutamanya jika anda mengikuti strategi berbilang awan, anda tidak akan mempunyai pilihan selain menggunakan penyelesaian pemantauan keselamatan maklumat luaran dalam beberapa persekitaran awan sekaligus (contohnya, Cisco CloudLock atau Cisco Stealthwatch Cloud). Nah, dalam beberapa kes anda akan menyedari bahawa pembekal awan yang anda pilih (atau dikenakan ke atas anda) tidak menawarkan sebarang keupayaan pemantauan keselamatan maklumat sama sekali. Ini tidak menyenangkan, tetapi juga tidak sedikit, kerana ia membolehkan anda menilai tahap risiko yang berkaitan dengan bekerja dengan awan ini dengan secukupnya.

Kitaran Hayat Pemantauan Keselamatan Awan

Untuk memantau keselamatan awan yang anda gunakan, anda hanya mempunyai tiga pilihan:

• bergantung pada alatan yang disediakan oleh pembekal awan anda,
• gunakan penyelesaian daripada pihak ketiga yang akan memantau platform IaaS, PaaS atau SaaS yang anda gunakan,
• bina infrastruktur pemantauan persekitaran awan anda sendiri (hanya untuk platform IaaS/PaaS).

Mari lihat ciri-ciri yang ada pada setiap pilihan ini. Tetapi pertama, kita perlu memahami rangka kerja umum yang akan digunakan apabila memantau platform awan. Saya akan menyerlahkan 6 komponen utama proses pemantauan keselamatan maklumat dalam awan:

• Penyediaan infrastruktur. Menentukan aplikasi dan infrastruktur yang diperlukan untuk mengumpul acara penting untuk keselamatan maklumat ke dalam storan.
• Koleksi. Pada peringkat ini, peristiwa keselamatan diagregatkan daripada pelbagai sumber untuk penghantaran seterusnya untuk pemprosesan, penyimpanan dan analisis.
• Rawatan. Pada peringkat ini, data diubah dan diperkaya untuk memudahkan analisis seterusnya.
• Penyimpanan. Komponen ini bertanggungjawab untuk penyimpanan jangka pendek dan jangka panjang bagi data diproses dan mentah yang dikumpul.
• Analisis. Pada peringkat ini, anda mempunyai keupayaan untuk mengesan insiden dan membalasnya secara automatik atau manual.
• Pelaporan. Peringkat ini membantu untuk merumuskan penunjuk utama untuk pihak berkepentingan (pengurusan, juruaudit, penyedia awan, pelanggan, dsb.) yang membantu kami membuat keputusan tertentu, contohnya, menukar penyedia atau mengukuhkan keselamatan maklumat.

Memahami komponen ini akan membolehkan anda membuat keputusan dengan cepat pada masa hadapan tentang perkara yang boleh anda ambil daripada pembekal anda, dan perkara yang perlu anda lakukan sendiri atau dengan penglibatan perunding luar.

Perkhidmatan awan terbina dalam

Saya sudah menulis di atas bahawa banyak perkhidmatan awan hari ini tidak menyediakan sebarang keupayaan pemantauan keselamatan maklumat. Secara amnya, mereka tidak banyak memberi perhatian kepada topik keselamatan maklumat. Sebagai contoh, salah satu perkhidmatan Rusia yang popular untuk menghantar laporan kepada agensi kerajaan melalui Internet (saya tidak akan menyebut namanya secara khusus). Keseluruhan bahagian tentang keselamatan perkhidmatan ini berkisar pada penggunaan CIPF yang diperakui. Bahagian keselamatan maklumat perkhidmatan awan domestik lain untuk pengurusan dokumen elektronik tidak berbeza. Ia bercakap tentang sijil kunci awam, kriptografi yang diperakui, menghapuskan kelemahan web, perlindungan terhadap serangan DDoS, menggunakan tembok api, sandaran, dan juga audit keselamatan maklumat biasa. Tetapi tidak ada perkataan tentang pemantauan, mahupun tentang kemungkinan mendapat akses kepada acara keselamatan maklumat yang mungkin menarik minat pelanggan penyedia perkhidmatan ini.

Secara umum, melalui cara pembekal awan menerangkan isu keselamatan maklumat di tapak webnya dan dalam dokumentasinya, anda boleh memahami betapa seriusnya ia mengambil isu ini. Sebagai contoh, jika anda membaca manual untuk produk "Pejabat Saya", tidak ada perkataan tentang keselamatan sama sekali, tetapi dalam dokumentasi untuk produk berasingan "Pejabat Saya. KS3”, direka untuk melindungi daripada akses tanpa kebenaran, terdapat penyenaraian biasa mata bagi tertib ke-17 FSTEC, yang “Pejabat Saya.KS3” laksanakan, tetapi ia tidak diterangkan bagaimana ia melaksanakannya dan, yang paling penting, cara untuk mengintegrasikan mekanisme ini dengan keselamatan maklumat korporat. Mungkin dokumentasi sedemikian wujud, tetapi saya tidak menemuinya dalam domain awam, di tapak web "Pejabat Saya". Walaupun mungkin saya tidak mempunyai akses kepada maklumat rahsia ini?..

Bagi Bitrix, keadaannya lebih baik. Dokumentasi menerangkan format log peristiwa dan, menariknya, log pencerobohan, yang mengandungi peristiwa yang berkaitan dengan potensi ancaman kepada platform awan. Dari sana anda boleh mengeluarkan IP, nama pengguna atau tetamu, sumber acara, masa, Ejen Pengguna, jenis acara, dsb. Benar, anda boleh bekerja dengan acara ini sama ada dari panel kawalan awan itu sendiri atau memuat naik data dalam format MS Excel. Kini sukar untuk mengautomasikan kerja dengan log Bitrix dan anda perlu melakukan beberapa kerja secara manual (memuat naik laporan dan memuatkannya ke dalam SIEM anda). Tetapi jika kita ingat bahawa sehingga baru-baru ini peluang sedemikian tidak wujud, maka ini adalah kemajuan yang besar. Pada masa yang sama, saya ingin ambil perhatian bahawa banyak penyedia awan asing menawarkan fungsi serupa "untuk pemula" - sama ada melihat log dengan mata anda melalui panel kawalan, atau memuat naik data kepada diri sendiri (namun, kebanyakan memuat naik data dalam . format csv, bukan Excel).

Tanpa mengambil kira pilihan tiada log, pembekal awan biasanya menawarkan anda tiga pilihan untuk memantau acara keselamatan - papan pemuka, muat naik data dan akses API. Yang pertama nampaknya menyelesaikan banyak masalah untuk anda, tetapi ini tidak sepenuhnya benar - jika anda mempunyai beberapa majalah, anda perlu bertukar antara skrin yang memaparkannya, kehilangan gambaran keseluruhan. Di samping itu, pembekal awan tidak mungkin memberikan anda keupayaan untuk mengaitkan peristiwa keselamatan dan secara amnya menganalisisnya dari sudut pandangan keselamatan (biasanya anda berurusan dengan data mentah, yang anda perlu fahami sendiri). Terdapat pengecualian dan kami akan membincangkannya dengan lebih lanjut. Akhir sekali, patut ditanya apakah peristiwa yang direkodkan oleh pembekal awan anda, dalam format apa, dan bagaimana ia sepadan dengan proses pemantauan keselamatan maklumat anda? Contohnya, pengenalan dan pengesahan pengguna dan tetamu. Bitrix yang sama membolehkan anda, berdasarkan peristiwa ini, merekodkan tarikh dan masa acara, nama pengguna atau tetamu (jika anda mempunyai modul "Analitis Web"), objek yang diakses dan elemen lain yang biasa untuk tapak web . Tetapi perkhidmatan keselamatan maklumat korporat mungkin memerlukan maklumat tentang sama ada pengguna mengakses awan daripada peranti yang dipercayai (contohnya, dalam rangkaian korporat, tugas ini dilaksanakan oleh Cisco ISE). Bagaimana pula dengan tugas mudah seperti fungsi geo-IP, yang akan membantu menentukan sama ada akaun pengguna perkhidmatan awan telah dicuri? Dan walaupun pembekal awan menyediakannya kepada anda, ini tidak mencukupi. Cisco CloudLock yang sama bukan sahaja menganalisis geolokasi, tetapi menggunakan pembelajaran mesin untuk ini dan menganalisis data sejarah untuk setiap pengguna dan memantau pelbagai anomali dalam percubaan pengenalan dan pengesahan. Hanya MS Azure yang mempunyai fungsi yang serupa (jika anda mempunyai langganan yang sesuai).

Terdapat satu lagi kesukaran - kerana bagi kebanyakan pembekal awan, pemantauan keselamatan maklumat merupakan topik baharu yang baru mereka mulakan, mereka sentiasa mengubah sesuatu dalam penyelesaian mereka. Hari ini mereka mempunyai satu versi API, esok yang lain, lusa yang ketiga. Anda juga perlu bersedia untuk ini. Perkara yang sama berlaku dengan fungsi, yang mungkin berubah, yang mesti diambil kira dalam sistem pemantauan keselamatan maklumat anda. Sebagai contoh, Amazon pada mulanya mempunyai perkhidmatan pemantauan acara awan yang berasingan—AWS CloudTrail dan AWS CloudWatch. Kemudian perkhidmatan berasingan untuk memantau peristiwa keselamatan maklumat muncul - AWS GuardDuty. Selepas beberapa lama, Amazon melancarkan sistem pengurusan baharu, Amazon Security Hub, yang merangkumi analisis data yang diterima daripada GuardDuty, Amazon Inspector, Amazon Macie dan beberapa yang lain. Contoh lain ialah alat penyepaduan log Azure dengan SIEM - AzLog. Ia digunakan secara aktif oleh banyak vendor SIEM, sehingga pada tahun 2018 Microsoft mengumumkan pemberhentian pembangunan dan sokongannya, yang berhadapan dengan ramai pelanggan yang menggunakan alat ini dengan masalah (kita akan bercakap tentang cara ia diselesaikan kemudian).

Oleh itu, pantau dengan teliti semua ciri pemantauan yang ditawarkan oleh pembekal awan anda. Atau bergantung pada penyedia penyelesaian luaran yang akan bertindak sebagai perantara antara SOC anda dan awan yang anda ingin pantau. Ya, ia akan menjadi lebih mahal (walaupun tidak selalu), tetapi anda akan mengalihkan semua tanggungjawab ke bahu orang lain. Atau tidak semuanya?.. Mari kita ingat konsep keselamatan yang dikongsi dan fahami bahawa kita tidak boleh mengalihkan apa-apa - kita perlu memahami secara bebas cara penyedia awan yang berbeza menyediakan pemantauan keselamatan maklumat data, aplikasi, mesin maya dan sumber lain anda dihoskan dalam awan. Dan kita akan mulakan dengan apa yang ditawarkan oleh Amazon dalam bahagian ini.

Contoh: Pemantauan keselamatan maklumat dalam IaaS berdasarkan AWS

Ya, ya, saya faham bahawa Amazon bukanlah contoh terbaik kerana fakta bahawa ini adalah perkhidmatan Amerika dan ia boleh disekat sebagai sebahagian daripada perjuangan menentang ekstremisme dan penyebaran maklumat yang dilarang di Rusia. Tetapi dalam penerbitan ini saya hanya ingin menunjukkan bagaimana platform awan yang berbeza berbeza dalam keupayaan pemantauan keselamatan maklumat mereka dan perkara yang perlu anda perhatikan apabila memindahkan proses utama anda ke awan dari sudut pandangan keselamatan. Nah, jika beberapa pembangun penyelesaian awan Rusia mempelajari sesuatu yang berguna untuk diri mereka sendiri, maka itu akan menjadi hebat.

Perkara pertama yang perlu dikatakan ialah Amazon bukanlah kubu yang tidak dapat ditembusi. Pelbagai insiden kerap berlaku kepada pelanggannya. Contohnya, nama, alamat, tarikh lahir dan nombor telefon 198 juta pengundi telah dicuri daripada Deep Root Analytics. Syarikat Israel Nice Systems mencuri 14 juta rekod pelanggan Verizon. Walau bagaimanapun, keupayaan terbina dalam AWS membolehkan anda mengesan pelbagai kejadian. Sebagai contoh:

• kesan ke atas infrastruktur (DDoS)
• kompromi nod (suntikan arahan)
• kompromi akaun dan akses tanpa kebenaran
• konfigurasi dan kelemahan yang salah
• antara muka dan API yang tidak selamat.

Percanggahan ini disebabkan oleh fakta bahawa, seperti yang kami ketahui di atas, pelanggan itu sendiri bertanggungjawab untuk keselamatan data pelanggan. Dan jika dia tidak peduli untuk menghidupkan mekanisme perlindungan dan tidak menghidupkan alat pemantauan, maka dia hanya akan belajar tentang kejadian itu dari media atau dari pelanggannya.

Untuk mengenal pasti insiden, anda boleh menggunakan pelbagai perkhidmatan pemantauan berbeza yang dibangunkan oleh Amazon (walaupun ini sering dilengkapkan dengan alat luaran seperti osquery). Jadi, dalam AWS, semua tindakan pengguna dipantau, tanpa mengira cara ia dijalankan - melalui konsol pengurusan, baris arahan, SDK atau perkhidmatan AWS yang lain. Semua rekod setiap aktiviti akaun AWS (termasuk nama pengguna, tindakan, perkhidmatan, parameter aktiviti dan hasil) dan penggunaan API tersedia melalui AWS CloudTrail. Anda boleh melihat acara ini (seperti log masuk konsol AWS IAM) daripada konsol CloudTrail, menganalisisnya menggunakan Amazon Athena atau "menyumber luar"nya kepada penyelesaian luaran seperti Splunk, AlienVault, dsb. Log AWS CloudTrail sendiri diletakkan dalam baldi AWS S3 anda.

Dua perkhidmatan AWS lain menyediakan beberapa keupayaan pemantauan penting lain. Pertama, Amazon CloudWatch ialah perkhidmatan pemantauan untuk sumber dan aplikasi AWS yang, antara lain, membolehkan anda mengenal pasti pelbagai anomali dalam awan anda. Semua perkhidmatan AWS terbina dalam, seperti Amazon Elastic Compute Cloud (pelayan), Perkhidmatan Pangkalan Data Amazon Relational (pangkalan data), Amazon Elastic MapReduce (analisis data) dan 30 perkhidmatan Amazon yang lain, menggunakan Amazon CloudWatch untuk menyimpan log mereka. Pembangun boleh menggunakan API terbuka daripada Amazon CloudWatch untuk menambahkan fungsi pemantauan log pada aplikasi dan perkhidmatan tersuai, membolehkan mereka mengembangkan skop analisis peristiwa dalam konteks keselamatan.

Kedua, perkhidmatan VPC Flow Logs membolehkan anda menganalisis trafik rangkaian yang dihantar atau diterima oleh pelayan AWS anda (secara luaran atau dalaman), serta antara perkhidmatan mikro. Apabila mana-mana sumber VPC AWS anda berinteraksi dengan rangkaian, Log Aliran VPC merekodkan butiran tentang trafik rangkaian, termasuk antara muka rangkaian sumber dan destinasi, serta alamat IP, port, protokol, bilangan bait dan bilangan paket yang anda melihat. Mereka yang berpengalaman dengan keselamatan rangkaian tempatan akan mengenali ini sebagai analog dengan benang Aliran Bersih, yang boleh dibuat oleh suis, penghala dan tembok api gred perusahaan. Log ini penting untuk tujuan pemantauan keselamatan maklumat kerana, tidak seperti peristiwa tentang tindakan pengguna dan aplikasi, log ini juga membolehkan anda tidak terlepas interaksi rangkaian dalam persekitaran awan peribadi maya AWS.

Ringkasnya, ketiga-tiga perkhidmatan AWS ini—AWS CloudTrail, Amazon CloudWatch dan VPC Flow Logs—bersama-sama memberikan cerapan yang agak berkuasa tentang penggunaan akaun anda, tingkah laku pengguna, pengurusan infrastruktur, aktiviti aplikasi dan perkhidmatan serta aktiviti rangkaian. Sebagai contoh, ia boleh digunakan untuk mengesan anomali berikut:

• Percubaan untuk mengimbas tapak, mencari pintu belakang, mencari kelemahan melalui cetusan "404 ralat".
• Serangan suntikan (contohnya, suntikan SQL) melalui letupan "500 ralat".
• Alat serangan yang terkenal ialah sqlmap, nikto, w3af, nmap, dll. melalui analisis medan Ejen Pengguna.

Perkhidmatan Web Amazon juga telah membangunkan perkhidmatan lain untuk tujuan keselamatan siber yang membolehkan anda menyelesaikan banyak masalah lain. Sebagai contoh, AWS mempunyai perkhidmatan terbina dalam untuk dasar dan konfigurasi pengauditan - AWS Config. Perkhidmatan ini menyediakan pengauditan berterusan sumber AWS anda dan konfigurasinya. Mari kita ambil contoh mudah: Katakan anda ingin memastikan bahawa kata laluan pengguna dilumpuhkan pada semua pelayan anda dan akses itu hanya boleh dilakukan berdasarkan sijil. AWS Config memudahkan untuk menyemak ini untuk semua pelayan anda. Terdapat dasar lain yang boleh digunakan pada pelayan awan anda: "Tiada pelayan boleh menggunakan port 22", "Hanya pentadbir boleh menukar peraturan tembok api" atau "Hanya pengguna Ivashko boleh membuat akaun pengguna baharu dan dia boleh melakukannya hanya pada hari Selasa. " Pada musim panas 2016, perkhidmatan AWS Config telah dikembangkan untuk mengautomasikan pengesanan pelanggaran dasar yang dibangunkan. Peraturan Konfigurasi AWS pada asasnya ialah permintaan konfigurasi berterusan untuk perkhidmatan Amazon yang anda gunakan, yang menjana peristiwa jika dasar yang sepadan dilanggar. Sebagai contoh, daripada menjalankan pertanyaan AWS Config secara berkala untuk mengesahkan bahawa semua cakera pada pelayan maya disulitkan, Peraturan AWS Config boleh digunakan untuk menyemak cakera pelayan secara berterusan untuk memastikan syarat ini dipenuhi. Dan, yang paling penting, dalam konteks penerbitan ini, sebarang pelanggaran menjana peristiwa yang boleh dianalisis oleh perkhidmatan keselamatan maklumat anda.

AWS juga mempunyai persamaan dengan penyelesaian keselamatan maklumat korporat tradisional, yang juga menjana peristiwa keselamatan yang anda boleh dan patut analisis:

• Pengesanan Pencerobohan - AWS GuardDuty
• Kawalan Kebocoran Maklumat - AWS Macie
• EDR (walaupun ia bercakap tentang titik akhir dalam awan sedikit pelik) - AWS Cloudwatch + penyelesaian osquery sumber terbuka atau GRR
• Analisis aliran bersih - AWS Cloudwatch + AWS VPC Flow
• Analisis DNS - AWS Cloudwatch + AWS Route53
• AD - Perkhidmatan Direktori AWS
• Pengurusan Akaun - AWS IAM
• SSO - AWS SSO
• analisis keselamatan - Inspektor AWS
• pengurusan konfigurasi - AWS Config
• WAF - AWS WAF.

Saya tidak akan menerangkan secara terperinci semua perkhidmatan Amazon yang mungkin berguna dalam konteks keselamatan maklumat. Perkara utama adalah untuk memahami bahawa kesemuanya boleh menjana peristiwa yang boleh dan patut kita analisis dalam konteks keselamatan maklumat, menggunakan untuk tujuan ini kedua-dua keupayaan terbina dalam Amazon itu sendiri dan penyelesaian luaran, contohnya, SIEM, yang boleh bawa acara keselamatan ke pusat pemantauan anda dan analisanya di sana bersama-sama dengan acara daripada perkhidmatan awan lain atau daripada infrastruktur dalaman, perimeter atau peranti mudah alih.

Walau apa pun, semuanya bermula dengan sumber data yang memberikan anda peristiwa keselamatan maklumat. Sumber-sumber ini termasuk, tetapi tidak terhad kepada:

• CloudTrail - Penggunaan API dan Tindakan Pengguna
• Penasihat Dipercayai - semakan keselamatan terhadap amalan terbaik
• Config - inventori dan konfigurasi akaun dan tetapan perkhidmatan
• Log Aliran VPC - sambungan ke antara muka maya
• IAM - perkhidmatan pengenalan dan pengesahan
• Log Akses ELB - Pengimbang Beban
• Inspektor - kelemahan aplikasi
• S3 - storan fail
• CloudWatch - Aktiviti Aplikasi
• SNS ialah perkhidmatan pemberitahuan.

Amazon, sambil menawarkan rangkaian sumber dan alatan acara sedemikian untuk penjanaan mereka, sangat terhad dalam keupayaannya untuk menganalisis data yang dikumpul dalam konteks keselamatan maklumat. Anda perlu mengkaji secara bebas log yang tersedia, mencari petunjuk kompromi yang berkaitan di dalamnya. Hab Keselamatan AWS, yang dilancarkan Amazon baru-baru ini, bertujuan untuk menyelesaikan masalah ini dengan menjadi SIEM awan untuk AWS. Tetapi setakat ini ia hanya pada permulaan perjalanannya dan dihadkan oleh bilangan sumber yang ia berfungsi dan oleh sekatan lain yang ditetapkan oleh seni bina dan langganan Amazon itu sendiri.

Contoh: Pemantauan keselamatan maklumat dalam IaaS berdasarkan Azure

Saya tidak mahu masuk ke dalam perdebatan panjang tentang yang mana antara tiga penyedia awan (Amazon, Microsoft atau Google) lebih baik (terutamanya kerana setiap daripada mereka masih mempunyai spesifik khusus sendiri dan sesuai untuk menyelesaikan masalahnya sendiri); Mari fokus pada keupayaan pemantauan keselamatan maklumat yang disediakan oleh pemain ini. Harus diakui bahawa Amazon AWS adalah salah satu yang pertama dalam segmen ini dan oleh itu telah maju paling jauh dari segi fungsi keselamatan maklumatnya (walaupun ramai yang mengakui bahawa ia sukar untuk digunakan). Tetapi ini tidak bermakna kami akan mengabaikan peluang yang diberikan oleh Microsoft dan Google kepada kami.

Produk Microsoft sentiasa dibezakan dengan "keterbukaan" mereka dan dalam Azure keadaannya adalah serupa. Sebagai contoh, jika AWS dan GCP sentiasa meneruskan konsep "apa yang tidak dibenarkan adalah dilarang", maka Azure mempunyai pendekatan yang bertentangan. Contohnya, apabila mencipta rangkaian maya dalam awan dan mesin maya di dalamnya, semua port dan protokol dibuka dan dibenarkan secara lalai. Oleh itu, anda perlu menghabiskan lebih sedikit usaha pada persediaan awal sistem kawalan akses dalam awan daripada Microsoft. Dan ini juga mengenakan keperluan yang lebih ketat kepada anda dari segi aktiviti pemantauan dalam awan Azure.

AWS mempunyai keanehan yang dikaitkan dengan fakta bahawa apabila anda memantau sumber maya anda, jika ia terletak di wilayah yang berbeza, maka anda menghadapi kesukaran untuk menggabungkan semua acara dan analisis bersatu mereka, untuk menghapuskan yang anda perlukan untuk menggunakan pelbagai helah, seperti Cipta kod anda sendiri untuk AWS Lambda yang akan mengangkut acara antara wilayah. Azure tidak mempunyai masalah ini - mekanisme Log Aktivitinya menjejaki semua aktiviti di seluruh organisasi tanpa sekatan. Perkara yang sama berlaku untuk Hab Keselamatan AWS, yang baru-baru ini dibangunkan oleh Amazon untuk menyatukan banyak fungsi keselamatan dalam satu pusat keselamatan, tetapi hanya dalam wilayahnya, yang bagaimanapun, tidak relevan untuk Rusia. Azure mempunyai Pusat Keselamatannya sendiri, yang tidak terikat dengan sekatan serantau, menyediakan akses kepada semua ciri keselamatan platform awan. Selain itu, untuk pasukan tempatan yang berbeza ia boleh menyediakan set keupayaan perlindungannya sendiri, termasuk acara keselamatan yang diuruskan oleh mereka. Hab Keselamatan AWS masih dalam perjalanan untuk menjadi serupa dengan Pusat Keselamatan Azure. Tetapi ia berbaloi untuk menambah lalat dalam salap - anda boleh memerah daripada Azure banyak perkara yang diterangkan sebelum ini dalam AWS, tetapi ini paling mudah dilakukan hanya untuk Azure AD, Azure Monitor dan Pusat Keselamatan Azure. Semua mekanisme keselamatan Azure yang lain, termasuk analisis peristiwa keselamatan, belum lagi diurus dengan cara yang paling mudah. Masalah ini sebahagiannya diselesaikan oleh API, yang meresap dalam semua perkhidmatan Microsoft Azure, tetapi ini memerlukan usaha tambahan daripada anda untuk mengintegrasikan awan anda dengan SOC anda dan kehadiran pakar yang berkelayakan (sebenarnya, seperti mana-mana SIEM lain yang berfungsi dengan awan API). Sesetengah SIEM, yang akan dibincangkan kemudian, sudah menyokong Azure dan boleh mengautomasikan tugas memantaunya, tetapi ia juga mempunyai kesukaran tersendiri - tidak semuanya boleh mengumpul semua log yang dimiliki oleh Azure.

Pengumpulan dan pemantauan acara dalam Azure disediakan menggunakan perkhidmatan Azure Monitor, yang merupakan alat utama untuk mengumpul, menyimpan dan menganalisis data dalam awan Microsoft dan sumbernya - repositori Git, bekas, mesin maya, aplikasi, dsb. Semua data yang dikumpul oleh Azure Monitor dibahagikan kepada dua kategori - metrik, dikumpul dalam masa nyata dan menerangkan penunjuk prestasi utama awan Azure, dan log, yang mengandungi data yang disusun ke dalam rekod yang mencirikan aspek tertentu aktiviti sumber dan perkhidmatan Azure. Selain itu, menggunakan API Pengumpul Data, perkhidmatan Azure Monitor boleh mengumpul data daripada mana-mana sumber REST untuk membina senario pemantauannya sendiri.

Berikut ialah beberapa sumber acara keselamatan yang Azure tawarkan kepada anda dan anda boleh akses melalui Azure Portal, CLI, PowerShell atau REST API (dan sesetengahnya hanya melalui Azure Monitor/Insight API):

• Log Aktiviti - log ini menjawab soalan klasik "siapa," "apa" dan "bila" mengenai sebarang operasi tulis (PUT, POST, DELETE) pada sumber awan. Acara yang berkaitan dengan akses baca (GET) tidak disertakan dalam log ini, seperti beberapa yang lain.
• Log Diagnostik - mengandungi data tentang operasi dengan sumber tertentu yang disertakan dalam langganan anda.
• Pelaporan Azure AD - mengandungi kedua-dua aktiviti pengguna dan aktiviti sistem yang berkaitan dengan pengurusan kumpulan dan pengguna.
• Log Peristiwa Windows dan Linux Syslog - mengandungi acara daripada mesin maya yang dihoskan dalam awan.
• Metrik - mengandungi telemetri mengenai prestasi dan status kesihatan perkhidmatan dan sumber awan anda. Diukur setiap minit dan disimpan. dalam masa 30 hari.
• Log Aliran Kumpulan Keselamatan Rangkaian - mengandungi data tentang peristiwa keselamatan rangkaian yang dikumpul menggunakan perkhidmatan Pemerhati Rangkaian dan pemantauan sumber di peringkat rangkaian.
• Log Storan - mengandungi peristiwa yang berkaitan dengan akses kepada kemudahan storan.

Untuk pemantauan, anda boleh menggunakan SIEM luaran atau Azure Monitor terbina dalam dan sambungannya. Kami akan bercakap tentang sistem pengurusan acara keselamatan maklumat kemudian, tetapi buat masa ini mari lihat apa yang Azure sendiri tawarkan kepada kami untuk analisis data dalam konteks keselamatan. Skrin utama untuk semua yang berkaitan dengan keselamatan dalam Azure Monitor ialah Log Analytics Security dan Audit Dashboard (versi percuma menyokong jumlah storan acara yang terhad untuk hanya satu minggu). Papan pemuka ini dibahagikan kepada 5 kawasan utama yang menggambarkan statistik ringkasan tentang perkara yang berlaku dalam persekitaran awan yang anda gunakan:

• Domain Keselamatan - penunjuk kuantitatif utama yang berkaitan dengan keselamatan maklumat - bilangan insiden, bilangan nod yang terjejas, nod tidak ditambal, peristiwa keselamatan rangkaian, dsb.
• Isu Penting - memaparkan bilangan dan kepentingan isu keselamatan maklumat aktif
• Pengesanan - memaparkan corak serangan yang digunakan terhadap anda
• Perisikan Ancaman - memaparkan maklumat geografi pada nod luaran yang menyerang anda
• Pertanyaan keselamatan biasa - pertanyaan biasa yang akan membantu anda memantau keselamatan maklumat anda dengan lebih baik.

Sambungan Azure Monitor termasuk Azure Key Vault (perlindungan kunci kriptografi dalam awan), Penilaian Hasad (analisis perlindungan terhadap kod hasad pada mesin maya), Azure Application Gateway Analytics (analisis, antara lain, log firewall awan), dsb. . Alat ini, diperkaya dengan peraturan tertentu untuk memproses acara, membolehkan anda memvisualisasikan pelbagai aspek aktiviti perkhidmatan awan, termasuk keselamatan, dan mengenal pasti sisihan tertentu daripada operasi. Tetapi, seperti yang sering berlaku, sebarang fungsi tambahan memerlukan langganan berbayar yang sepadan, yang memerlukan pelaburan kewangan yang sepadan daripada anda, yang perlu anda rancang terlebih dahulu.

Azure mempunyai beberapa keupayaan pemantauan ancaman terbina dalam yang disepadukan ke dalam Azure AD, Azure Monitor dan Pusat Keselamatan Azure. Antaranya, sebagai contoh, pengesanan interaksi mesin maya dengan IP berniat jahat yang diketahui (disebabkan kehadiran integrasi dengan perkhidmatan Perisikan Ancaman daripada Microsoft), pengesanan perisian hasad dalam infrastruktur awan dengan menerima penggera daripada mesin maya yang dihoskan dalam awan, kata laluan meneka serangan ” pada mesin maya, kelemahan dalam konfigurasi sistem pengenalan pengguna, log masuk ke dalam sistem daripada anonymizer atau nod yang dijangkiti, kebocoran akaun, log masuk ke sistem dari lokasi luar biasa, dsb. Azure hari ini ialah salah satu daripada beberapa pembekal awan yang menawarkan anda keupayaan Perisikan Ancaman terbina dalam untuk memperkayakan peristiwa keselamatan maklumat yang dikumpul.

Seperti yang dinyatakan di atas, fungsi keselamatan dan, akibatnya, peristiwa keselamatan yang dijana olehnya tidak tersedia untuk semua pengguna secara sama rata, tetapi memerlukan langganan tertentu yang merangkumi fungsi yang anda perlukan, yang menjana peristiwa yang sesuai untuk pemantauan keselamatan maklumat. Contohnya, beberapa fungsi yang diterangkan dalam perenggan sebelumnya untuk memantau anomali dalam akaun hanya tersedia dalam lesen premium P2 untuk perkhidmatan Azure AD. Tanpa itu, anda, seperti dalam kes AWS, perlu menganalisis peristiwa keselamatan yang dikumpul "secara manual". Dan, juga, bergantung pada jenis lesen Azure AD, tidak semua acara akan tersedia untuk analisis.

Pada portal Azure, anda boleh mengurus kedua-dua pertanyaan carian untuk log yang menarik minat anda dan menyediakan papan pemuka untuk menggambarkan penunjuk keselamatan maklumat utama. Di samping itu, di sana anda boleh memilih sambungan Azure Monitor, yang membolehkan anda mengembangkan kefungsian log Azure Monitor dan mendapatkan analisis peristiwa yang lebih mendalam dari sudut keselamatan.

Jika anda bukan sahaja memerlukan keupayaan untuk bekerja dengan log, tetapi pusat keselamatan yang komprehensif untuk platform awan Azure anda, termasuk pengurusan dasar keselamatan maklumat, maka anda boleh bercakap tentang keperluan untuk bekerja dengan Pusat Keselamatan Azure, yang kebanyakannya fungsi berguna. tersedia untuk wang, contohnya, pengesanan ancaman, pemantauan di luar Azure, penilaian pematuhan, dsb. (dalam versi percuma, anda hanya mempunyai akses kepada penilaian keselamatan dan cadangan untuk menghapuskan masalah yang dikenal pasti). Ia menyatukan semua isu keselamatan di satu tempat. Malah, kita boleh bercakap tentang tahap keselamatan maklumat yang lebih tinggi daripada yang disediakan oleh Azure Monitor, kerana dalam kes ini, data yang dikumpul di seluruh kilang awan anda diperkaya menggunakan banyak sumber, seperti Azure, Office 365, Microsoft CRM dalam talian, Microsoft Dynamics AX , outlook .com, MSN.com, Unit Jenayah Digital Microsoft (DCU) dan Pusat Tindak Balas Keselamatan Microsoft (MSRC), di mana pelbagai pembelajaran mesin yang canggih dan algoritma analitik tingkah laku diletakkan, yang akhirnya akan meningkatkan kecekapan mengesan dan bertindak balas terhadap ancaman. .

Azure juga mempunyai SIEM sendiri - ia muncul pada awal 2019. Ini ialah Azure Sentinel, yang bergantung pada data daripada Azure Monitor dan juga boleh disepadukan dengan. penyelesaian keselamatan luaran (contohnya, NGFW atau WAF), senarai yang sentiasa berkembang. Selain itu, melalui penyepaduan Microsoft Graph Security API, anda mempunyai keupayaan untuk menyambungkan suapan Perisikan Ancaman anda sendiri kepada Sentinel, yang memperkayakan keupayaan untuk menganalisis insiden dalam awan Azure anda. Boleh dikatakan bahawa Azure Sentinel ialah SIEM "asli" pertama yang muncul daripada penyedia awan (Splunk atau ELK yang sama, yang boleh dihoskan dalam awan, contohnya, AWS, masih tidak dibangunkan oleh penyedia perkhidmatan awan tradisional). Azure Sentinel dan Pusat Keselamatan boleh dipanggil SOC untuk awan Azure dan boleh terhad kepada mereka (dengan tempahan tertentu) jika anda tidak lagi mempunyai sebarang infrastruktur dan anda memindahkan semua sumber pengkomputeran anda ke awan dan ia akan menjadi Microsoft cloud Azure.

Tetapi oleh kerana keupayaan terbina dalam Azure (walaupun anda mempunyai langganan Sentinel) selalunya tidak mencukupi untuk tujuan memantau keselamatan maklumat dan menyepadukan proses ini dengan sumber peristiwa keselamatan lain (kedua-dua awan dan dalaman), terdapat perlu mengeksport data yang dikumpul ke sistem luaran, yang mungkin termasuk SIEM. Ini dilakukan menggunakan API dan menggunakan sambungan khas, yang kini tersedia secara rasmi hanya untuk SIEM berikut - Splunk (Azure Monitor Add-On untuk Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight dan ELK. Sehingga baru-baru ini, terdapat lebih banyak SIEM seperti itu, tetapi mulai 1 Jun 2019, Microsoft berhenti menyokong Alat Integrasi Log Azure (AzLog), yang pada awal kewujudan Azure dan tanpa adanya penyeragaman biasa untuk bekerja dengan log (Azure Monitor belum wujud lagi) menjadikannya mudah mengintegrasikan SIEM luaran dengan awan Microsoft. Kini keadaan telah berubah dan Microsoft mengesyorkan platform Azure Event Hub sebagai alat penyepaduan utama untuk SIEM lain. Ramai yang telah melaksanakan integrasi sedemikian, tetapi berhati-hati - mereka mungkin tidak menangkap semua log Azure, tetapi hanya beberapa (lihat dalam dokumentasi untuk SIEM anda).

Mengakhiri lawatan ringkas ke Azure, saya ingin memberikan cadangan umum tentang perkhidmatan awan ini - sebelum anda mengatakan apa-apa tentang fungsi pemantauan keselamatan maklumat dalam Azure, anda harus mengkonfigurasinya dengan berhati-hati dan menguji bahawa ia berfungsi seperti yang tertulis dalam dokumentasi dan seperti yang diberitahu oleh perunding kepada anda Microsoft (dan mereka mungkin mempunyai pandangan yang berbeza tentang kefungsian fungsi Azure). Jika anda mempunyai sumber kewangan, anda boleh memerah banyak maklumat berguna daripada Azure dari segi pemantauan keselamatan maklumat. Jika sumber anda terhad, maka, seperti dalam kes AWS, anda hanya perlu bergantung pada kekuatan anda sendiri dan data mentah yang disediakan oleh Azure Monitor kepada anda. Dan ingat bahawa banyak fungsi pemantauan memerlukan wang dan adalah lebih baik untuk membiasakan diri dengan dasar penetapan harga terlebih dahulu. Sebagai contoh, secara percuma anda boleh menyimpan 31 hari data sehingga maksimum 5 GB setiap pelanggan - melebihi nilai ini memerlukan anda mengeluarkan wang tambahan (kira-kira $2+ untuk menyimpan setiap GB tambahan daripada pelanggan dan $0,1 untuk menyimpan 1 GB setiap bulan tambahan). Bekerja dengan telemetri dan metrik aplikasi juga mungkin memerlukan dana tambahan, serta bekerja dengan makluman dan pemberitahuan (had tertentu tersedia secara percuma, yang mungkin tidak mencukupi untuk keperluan anda).

Contoh: Pemantauan keselamatan maklumat dalam IaaS berdasarkan Google Cloud Platform

Google Cloud Platform kelihatan seperti anak muda berbanding AWS dan Azure, tetapi ini sebahagiannya bagus. Tidak seperti AWS, yang meningkatkan keupayaannya, termasuk yang keselamatan, secara beransur-ansur, mengalami masalah dengan pemusatan; GCP, seperti Azure, diuruskan dengan lebih baik secara berpusat, yang mengurangkan ralat dan masa pelaksanaan merentas perusahaan. Dari sudut keselamatan, GCP adalah, anehnya, antara AWS dan Azure. Dia juga mempunyai pendaftaran acara tunggal untuk keseluruhan organisasi, tetapi ia tidak lengkap. Sesetengah fungsi masih dalam mod beta, tetapi secara beransur-ansur kekurangan ini harus dihapuskan dan GCP akan menjadi platform yang lebih matang dari segi pemantauan keselamatan maklumat.

Alat utama untuk mengelog peristiwa dalam GCP ialah Stackdriver Logging (serupa dengan Azure Monitor), yang membolehkan anda mengumpul acara merentas keseluruhan infrastruktur awan anda (serta dari AWS). Dari perspektif keselamatan dalam GCP, setiap organisasi, projek atau folder mempunyai empat log:

• Aktiviti Pentadbiran - mengandungi semua acara yang berkaitan dengan akses pentadbiran, contohnya, mencipta mesin maya, menukar hak akses, dsb. Log ini sentiasa ditulis, tanpa mengira keinginan anda, dan menyimpan datanya selama 400 hari.
• Akses Data - mengandungi semua peristiwa yang berkaitan dengan bekerja dengan data oleh pengguna awan (penciptaan, pengubahsuaian, pembacaan, dsb.). Secara lalai, log ini tidak ditulis, kerana volumnya mengembang dengan sangat cepat. Atas sebab ini, jangka hayatnya hanya 30 hari. Di samping itu, tidak semuanya ditulis dalam majalah ini. Contohnya, acara yang berkaitan dengan sumber yang boleh diakses secara terbuka kepada semua pengguna atau yang boleh diakses tanpa log masuk ke GCP tidak ditulis kepadanya.
• Peristiwa Sistem - mengandungi peristiwa sistem yang tidak berkaitan dengan pengguna, atau tindakan pentadbir yang mengubah konfigurasi sumber awan. Ia sentiasa ditulis dan disimpan selama 400 hari.
• Ketelusan Akses ialah contoh unik log yang menangkap semua tindakan pekerja Google (tetapi belum lagi untuk semua perkhidmatan GCP) yang mengakses infrastruktur anda sebagai sebahagian daripada tugas kerja mereka. Log ini disimpan selama 400 hari dan tidak tersedia untuk setiap pelanggan GCP, tetapi hanya jika beberapa syarat dipenuhi (sama ada sokongan peringkat Emas atau Platinum atau kehadiran 4 peranan jenis tertentu sebagai sebahagian daripada sokongan korporat). Fungsi serupa juga tersedia, contohnya, dalam Office 365 - Kotak Kunci.

Contoh log: Ketelusan Akses

{
 insertId:  "abcdefg12345"
 jsonPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.TransparencyLog"
  location: {
   principalOfficeCountry:  "US"
   principalEmployingEntity:  "Google LLC"
   principalPhysicalLocationCountry:  "CA"
  }
  product: [
   0:  "Cloud Storage"
  ]
  reason: [
    detail:  "Case number: bar123"
    type:  "CUSTOMER_INITIATED_SUPPORT"
  ]
  accesses: [
   0: {
    methodName: "GoogleInternal.Read"
    resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"
    }
  ]
 }
 logName:  "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.com%2Faccess_transparency"
 operation: {
  id:  "12345xyz"
 }
 receiveTimestamp:  "2017-12-18T16:06:37.400577736Z"
 resource: {
  labels: {
   project_id:  "1234567890"
  }
  type:  "project"
 }
 severity:  "NOTICE"
 timestamp:  "2017-12-18T16:06:24.660001Z"
}

Akses kepada log ini boleh dilakukan dalam beberapa cara (dengan cara yang sama seperti Azure dan AWS yang dibincangkan sebelum ini) - melalui antara muka Log Viewer, melalui API, melalui SDK Awan Google atau melalui halaman Aktiviti projek anda yang mana anda berminat dengan acara. Dengan cara yang sama, mereka boleh dieksport ke penyelesaian luaran untuk analisis tambahan. Yang terakhir dilakukan dengan mengeksport log ke BigQuery atau storan Cloud Pub/Sub.

Selain Stackdriver Logging, platform GCP juga menawarkan kefungsian Pemantauan Stackdriver, yang membolehkan anda memantau metrik utama (prestasi, MTBF, kesihatan keseluruhan, dll.) perkhidmatan dan aplikasi awan. Data yang diproses dan digambarkan boleh memudahkan anda mencari masalah dalam infrastruktur awan anda, termasuk dalam konteks keselamatan. Tetapi harus diingat bahawa fungsi ini tidak akan begitu kaya dalam konteks keselamatan maklumat, kerana hari ini GCP tidak mempunyai analog AWS GuardDuty yang sama dan tidak dapat mengenal pasti yang buruk di antara semua acara berdaftar (Google telah membangunkan Pengesanan Ancaman Peristiwa, tetapi ia masih dalam pembangunan dalam beta dan terlalu awal untuk bercakap tentang kegunaannya). Pemantauan Stackdriver boleh digunakan sebagai sistem untuk mengesan anomali, yang kemudiannya akan disiasat untuk mencari punca kejadiannya. Tetapi memandangkan kekurangan kakitangan yang berkelayakan dalam bidang keselamatan maklumat GCP di pasaran, tugas ini pada masa ini kelihatan sukar.

Ia juga bernilai memberikan senarai beberapa modul keselamatan maklumat yang boleh digunakan dalam awan GCP anda, dan yang serupa dengan apa yang ditawarkan oleh AWS:

• Pusat Arahan Keselamatan Awan ialah analog bagi Hab Keselamatan AWS dan Pusat Keselamatan Azure.
• Cloud DLP - Penemuan dan pengeditan automatik (cth. menutup) data yang dihoskan dalam awan menggunakan lebih daripada 90 dasar klasifikasi yang dipratentukan.
• Pengimbas Awan ialah pengimbas untuk kelemahan yang diketahui (XSS, Suntikan Kilat, perpustakaan yang tidak ditambal, dll.) dalam Enjin Apl, Enjin Kira dan Google Kubernetes.
• Cloud IAM - Kawal akses kepada semua sumber GCP.
• Cloud Identity - Urus akaun pengguna, peranti dan aplikasi GCP daripada satu konsol.
• Cloud HSM - perlindungan kunci kriptografi.
• Perkhidmatan Pengurusan Kunci Awan - pengurusan kunci kriptografi dalam GCP.
• Kawalan Perkhidmatan VPC - Buat perimeter selamat di sekeliling sumber GCP anda untuk melindunginya daripada kebocoran.
• Kunci Keselamatan Titan - perlindungan terhadap pancingan data.

Kebanyakan modul ini menjana peristiwa keselamatan yang boleh dihantar ke storan BigQuery untuk analisis atau eksport ke sistem lain, termasuk SIEM. Seperti yang dinyatakan di atas, GCP ialah platform yang sedang giat membangun dan Google kini sedang membangunkan beberapa modul keselamatan maklumat baharu untuk platformnya. Antaranya ialah Pengesanan Ancaman Peristiwa (kini tersedia dalam beta), yang mengimbas log Stackdriver untuk mencari kesan aktiviti yang tidak dibenarkan (bersamaan dengan GuardDuty dalam AWS), atau Perisikan Polisi (tersedia dalam alpha), yang akan membolehkan anda membangunkan dasar pintar untuk akses kepada sumber GCP.

Saya membuat gambaran ringkas tentang keupayaan pemantauan terbina dalam dalam platform awan yang popular. Tetapi adakah anda mempunyai pakar yang boleh bekerja dengan log penyedia IaaS "mentah" (bukan semua orang bersedia untuk membeli keupayaan lanjutan AWS atau Azure atau Google)? Di samping itu, ramai yang biasa dengan pepatah "percaya, tetapi sahkan," yang lebih benar berbanding sebelum ini dalam bidang keselamatan. Sejauh manakah anda mempercayai keupayaan terbina dalam pembekal awan yang menghantar acara keselamatan maklumat kepada anda? Sejauh manakah mereka memberi tumpuan kepada keselamatan maklumat sama sekali?

Kadangkala patut melihat penyelesaian pemantauan infrastruktur awan tindanan yang boleh melengkapkan keselamatan awan terbina dalam, dan kadangkala penyelesaian sedemikian merupakan satu-satunya pilihan untuk mendapatkan cerapan tentang keselamatan data dan aplikasi anda yang dihoskan dalam awan. Di samping itu, mereka lebih mudah, kerana mereka mengambil semua tugas menganalisis log yang diperlukan yang dihasilkan oleh perkhidmatan awan yang berbeza daripada penyedia awan yang berbeza. Contoh penyelesaian tindanan sedemikian ialah Cisco Stealthwatch Cloud, yang memfokuskan pada satu tugas - memantau anomali keselamatan maklumat dalam persekitaran awan, termasuk bukan sahaja Amazon AWS, Microsoft Azure dan Google Cloud Platform, tetapi juga awan peribadi.

Contoh: Pemantauan Keselamatan Maklumat Menggunakan Awan Stealthwatch

AWS menyediakan platform pengkomputeran yang fleksibel, tetapi fleksibiliti ini memudahkan syarikat membuat kesilapan yang membawa kepada isu keselamatan. Dan model keselamatan maklumat yang dikongsi hanya menyumbang kepada ini. Menjalankan perisian dalam awan dengan kelemahan yang tidak diketahui (yang diketahui boleh diatasi, contohnya, oleh AWS Inspector atau GCP Cloud Scanner), kata laluan yang lemah, konfigurasi yang salah, orang dalam, dsb. Dan semua ini dicerminkan dalam tingkah laku sumber awan, yang boleh dipantau oleh Cisco Stealthwatch Cloud, yang merupakan pemantauan keselamatan maklumat dan sistem pengesanan serangan. awan awam dan peribadi.

Salah satu ciri utama Cisco Stealthwatch Cloud ialah keupayaan untuk memodelkan entiti. Dengan itu, anda boleh mencipta model perisian (iaitu simulasi hampir masa nyata) bagi setiap sumber awan anda (tidak kira sama ada AWS, Azure, GCP atau sesuatu yang lain). Ini boleh termasuk pelayan dan pengguna, serta jenis sumber khusus untuk persekitaran awan anda, seperti kumpulan keselamatan dan kumpulan skala automatik. Model ini menggunakan aliran data berstruktur yang disediakan oleh perkhidmatan awan sebagai input. Contohnya, untuk AWS ini ialah VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda dan AWS IAM. Pemodelan entiti secara automatik menemui peranan dan tingkah laku mana-mana sumber anda (anda boleh bercakap tentang memprofil semua aktiviti awan). Peranan ini termasuk peranti mudah alih Android atau Apple, pelayan Citrix PVS, pelayan RDP, gerbang mel, pelanggan VoIP, pelayan terminal, pengawal domain, dsb. Ia kemudiannya memantau tingkah laku mereka secara berterusan untuk menentukan bila tingkah laku berisiko atau mengancam keselamatan berlaku. Anda boleh mengenal pasti tekaan kata laluan, serangan DDoS, kebocoran data, akses jauh haram, aktiviti kod berniat jahat, pengimbasan kerentanan dan ancaman lain. Sebagai contoh, inilah rupa pengesanan percubaan akses jauh dari negara yang tidak tipikal untuk organisasi anda (Korea Selatan) kepada gugusan Kubernetes melalui SSH:

Dan inilah rupa dakwaan kebocoran maklumat daripada pangkalan data Postgress ke negara yang belum pernah kami temui interaksi sebelum ini:

Akhir sekali, inilah rupa terlalu banyak percubaan SSH yang gagal dari China dan Indonesia daripada peranti jauh luaran:

Atau, katakan bahawa tika pelayan dalam VPC, mengikut dasar, tidak sekali-kali menjadi destinasi log masuk jauh. Mari kita anggap lagi bahawa komputer ini mengalami log masuk jauh disebabkan oleh perubahan yang salah dalam dasar peraturan firewall. Ciri Pemodelan Entiti akan mengesan dan melaporkan aktiviti ini (“Akses Jauh Luar Biasa”) dalam hampir masa nyata dan menghala ke panggilan API AWS CloudTrail, Azure Monitor atau GCP Stackdriver Logging tertentu (termasuk nama pengguna, tarikh dan masa, antara butiran lain ).yang mendorong perubahan kepada peraturan ITU. Dan kemudian maklumat ini boleh dihantar ke SIEM untuk dianalisis.

Keupayaan serupa dilaksanakan untuk mana-mana persekitaran awan yang disokong oleh Cisco Stealthwatch Cloud:

Pemodelan entiti ialah bentuk unik automasi keselamatan yang boleh mendedahkan masalah yang tidak diketahui sebelum ini dengan pekerja, proses atau teknologi anda. Sebagai contoh, ia membolehkan anda mengesan, antara lain, masalah keselamatan seperti:

• Adakah seseorang menemui pintu belakang dalam perisian yang kami gunakan?
• Adakah terdapat sebarang perisian atau peranti pihak ketiga dalam awan kami?
• Adakah pengguna yang dibenarkan menyalahgunakan keistimewaan?
• Adakah terdapat ralat konfigurasi yang membenarkan akses jauh atau penggunaan sumber lain yang tidak diingini?
• Adakah terdapat kebocoran data daripada pelayan kami?
• Adakah seseorang cuba menyambung kepada kami dari lokasi geografi yang tidak tipikal?
• Adakah awan kami dijangkiti kod berniat jahat?

Acara keselamatan maklumat yang dikesan boleh dihantar dalam bentuk tiket yang sepadan ke Slack, Cisco Spark, sistem pengurusan insiden PagerDuty, dan juga dihantar ke pelbagai SIEM, termasuk Splunk atau ELK. Untuk meringkaskan, kami boleh mengatakan bahawa jika syarikat anda menggunakan strategi berbilang awan dan tidak terhad kepada mana-mana satu pembekal awan, keupayaan pemantauan keselamatan maklumat yang diterangkan di atas, maka menggunakan Cisco Stealthwatch Cloud ialah pilihan yang baik untuk mendapatkan set pemantauan bersepadu keupayaan untuk pemain awan terkemuka - Amazon, Microsoft dan Google. Perkara yang paling menarik ialah jika anda membandingkan harga untuk Stealthwatch Cloud dengan lesen lanjutan untuk pemantauan keselamatan maklumat dalam AWS, Azure atau GCP, ternyata penyelesaian Cisco akan menjadi lebih murah daripada keupayaan terbina dalam Amazon, Microsoft. dan penyelesaian Google. Ia paradoks, tetapi ia benar. Dan lebih banyak awan dan keupayaannya yang anda gunakan, lebih jelas kelebihan penyelesaian yang disatukan.

Selain itu, Stealthwatch Cloud boleh memantau awan peribadi yang digunakan dalam organisasi anda, contohnya, berdasarkan bekas Kubernetes atau dengan memantau aliran Netflow atau trafik rangkaian yang diterima melalui pencerminan dalam peralatan rangkaian (walaupun dihasilkan di dalam negara), data AD atau pelayan DNS dan sebagainya. Semua data ini akan diperkaya dengan maklumat Perisikan Ancaman yang dikumpul oleh Cisco Talos, kumpulan penyelidik ancaman keselamatan siber bukan kerajaan terbesar di dunia.

Ini membolehkan anda melaksanakan sistem pemantauan bersatu untuk awan awam dan hibrid yang mungkin digunakan oleh syarikat anda. Maklumat yang dikumpul kemudiannya boleh dianalisis menggunakan keupayaan terbina dalam Stealthwatch Cloud atau dihantar ke SIEM anda (Splunk, ELK, SumoLogic dan beberapa yang lain disokong secara lalai).

Dengan ini, kami akan melengkapkan bahagian pertama artikel, di mana saya menyemak alat terbina dalam dan luaran untuk memantau keselamatan maklumat platform IaaS/PaaS, yang membolehkan kami mengesan dan bertindak balas dengan pantas kepada insiden yang berlaku dalam persekitaran awan yang syarikat kami telah memilih. Di bahagian kedua, kami akan meneruskan topik dan melihat pilihan untuk memantau platform SaaS menggunakan contoh Salesforce dan Dropbox, dan kami juga akan cuba meringkaskan dan menyusun segala-galanya dengan mencipta sistem pemantauan keselamatan maklumat bersatu untuk pembekal awan yang berbeza.

Sumber: www.habr.com