मेघ सुरक्षा देखरेख

डेटा आणि ऍप्लिकेशन्स क्लाउडवर हलवणे कॉर्पोरेट SOC साठी एक नवीन आव्हान प्रस्तुत करते, जे नेहमी इतर लोकांच्या पायाभूत सुविधांवर लक्ष ठेवण्यासाठी तयार नसतात. नेटोस्कोपच्या मते, सरासरी एंटरप्राइझ (वरवर पाहता यूएस मध्ये) 1246 भिन्न क्लाउड सेवा वापरते, जे एका वर्षापूर्वी 22% जास्त आहे. 1246 क्लाउड सेवा!!! त्यापैकी 175 एचआर सेवेशी संबंधित आहेत, 170 मार्केटिंगशी संबंधित आहेत, 110 दळणवळण क्षेत्रात आहेत आणि 76 वित्त आणि CRM क्षेत्रातील आहेत. Cisco "केवळ" 700 बाह्य क्लाउड सेवा वापरते. त्यामुळे या आकड्यांमुळे मी थोडा गोंधळलो आहे. परंतु कोणत्याही परिस्थितीत, समस्या त्यांच्याबरोबर नाही, परंतु या वस्तुस्थितीसह की क्लाउडचा वापर वाढत्या संख्येने कंपन्यांद्वारे सक्रियपणे केला जाऊ लागला आहे ज्यांना त्यांच्या स्वत: च्या नेटवर्कप्रमाणेच क्लाउड इन्फ्रास्ट्रक्चरचे निरीक्षण करण्यासाठी समान क्षमता हवी आहे. आणि हा कल वाढत आहे - त्यानुसार अमेरिकन चेंबर ऑफ अकाउंट्सनुसार 2023 पर्यंत, युनायटेड स्टेट्समध्ये 1200 डेटा केंद्रे बंद होणार आहेत (6250 आधीच बंद झाली आहेत). परंतु क्लाउडमध्ये संक्रमण फक्त "चला आमच्या सर्व्हरला बाह्य प्रदात्याकडे हलवू" असे नाही. नवीन IT आर्किटेक्चर, नवीन सॉफ्टवेअर, नवीन प्रक्रिया, नवीन निर्बंध... हे सर्व केवळ IT च्या कामातच नाही तर माहितीच्या सुरक्षिततेतही लक्षणीय बदल घडवून आणते. आणि जर प्रदाते कसे तरी क्लाउडची सुरक्षितता सुनिश्चित करण्यास शिकले असतील (सुदैवाने तेथे बर्‍याच शिफारसी आहेत), तर क्लाउड माहिती सुरक्षा मॉनिटरिंगसह, विशेषत: सास प्लॅटफॉर्मवर, लक्षणीय अडचणी आहेत, ज्याबद्दल आम्ही बोलू.

समजा तुमच्या कंपनीने त्याच्या पायाभूत सुविधांचा काही भाग क्लाउडवर हलवला आहे... थांबा. या मार्गाने नाही. जर इन्फ्रास्ट्रक्चर हस्तांतरित केले गेले असेल आणि तुम्ही आताच त्याचे निरीक्षण कसे कराल याचा विचार करत असाल तर तुम्ही आधीच गमावले आहे. जोपर्यंत ते Amazon, Google किंवा Microsoft (आणि नंतर आरक्षणासह) नाही तोपर्यंत, तुमच्याकडे कदाचित तुमचा डेटा आणि ऍप्लिकेशन्सचे निरीक्षण करण्याची जास्त क्षमता नसेल. जर तुम्हाला लॉगसह काम करण्याची संधी दिली गेली तर ते चांगले आहे. कधीकधी सुरक्षा इव्हेंट डेटा उपलब्ध असेल, परंतु तुम्हाला त्यात प्रवेश नसेल. उदाहरणार्थ, ऑफिस 365. जर तुमच्याकडे सर्वात स्वस्त E1 परवाना असेल, तर सुरक्षा कार्यक्रम तुमच्यासाठी अजिबात उपलब्ध नाहीत. तुमच्याकडे E3 परवाना असल्यास, तुमचा डेटा फक्त 90 दिवसांसाठी साठवला जातो आणि तुमच्याकडे E5 परवाना असेल तरच, लॉगचा कालावधी एका वर्षासाठी उपलब्ध असतो (तथापि, स्वतंत्रपणे करण्याची आवश्यकता संबंधित त्याच्या स्वतःच्या बारकावे देखील आहेत. मायक्रोसॉफ्ट सपोर्टकडून लॉगसह कार्य करण्यासाठी अनेक फंक्शन्सची विनंती करा). तसे, कॉर्पोरेट एक्सचेंजपेक्षा मॉनिटरिंग फंक्शन्सच्या बाबतीत E3 परवाना खूपच कमकुवत आहे. समान पातळी गाठण्यासाठी, तुम्हाला E5 परवाना किंवा अतिरिक्त प्रगत अनुपालन परवाना आवश्यक आहे, ज्यासाठी क्लाउड इन्फ्रास्ट्रक्चरवर जाण्यासाठी तुमच्या आर्थिक मॉडेलमध्ये घटक नसलेल्या अतिरिक्त पैशांची आवश्यकता असू शकते. आणि क्लाउड माहिती सुरक्षा निरीक्षणाशी संबंधित समस्यांना कमी लेखण्याचे हे फक्त एक उदाहरण आहे. या लेखात, पूर्ण झाल्याची बतावणी न करता, मी सुरक्षिततेच्या दृष्टिकोनातून क्लाउड प्रदाता निवडताना विचारात घेतलेल्या काही बारीकसारीक गोष्टींकडे लक्ष वेधू इच्छितो. आणि लेखाच्या शेवटी, एक चेकलिस्ट दिली जाईल जी क्लाउड माहिती सुरक्षिततेच्या देखरेखीची समस्या सोडवली गेली आहे हे लक्षात घेण्यापूर्वी पूर्ण करणे योग्य आहे.

क्लाउड वातावरणात घटनांना कारणीभूत असलेल्या अनेक सामान्य समस्या आहेत, ज्यांना माहिती सुरक्षा सेवांना प्रतिसाद देण्यासाठी वेळ नाही किंवा ते अजिबात दिसत नाहीत:

• सुरक्षा नोंदी अस्तित्वात नाहीत. ही एक सामान्य परिस्थिती आहे, विशेषत: क्लाउड सोल्यूशन मार्केटमधील नवशिक्या खेळाडूंमध्ये. परंतु आपण त्यांना लगेच सोडू नये. लहान खेळाडू, विशेषत: देशांतर्गत, ग्राहकांच्या आवश्यकतांबद्दल अधिक संवेदनशील असतात आणि त्यांच्या उत्पादनांसाठी मंजूर रोडमॅप बदलून काही आवश्यक कार्ये त्वरित अंमलात आणू शकतात. होय, हे Amazon मधील GuardDuty चे analogue किंवा Bitrix मधील “प्रोएक्टिव्ह प्रोटेक्शन” मॉड्यूल नसून किमान काहीतरी असेल.
• माहिती सुरक्षेला हे माहीत नसते की लॉग कुठे साठवले जातात किंवा त्यामध्ये प्रवेश नाही. येथे क्लाउड सेवा प्रदात्याशी वाटाघाटी करणे आवश्यक आहे - जर त्याने क्लायंटला त्याच्यासाठी महत्त्वपूर्ण मानले तर कदाचित तो अशी माहिती प्रदान करेल. परंतु सर्वसाधारणपणे, जेव्हा लॉगमध्ये प्रवेश "विशेष निर्णयाद्वारे" प्रदान केला जातो तेव्हा ते फार चांगले नसते.
• असेही घडते की क्लाउड प्रदात्याकडे लॉग आहेत, परंतु ते मर्यादित निरीक्षण आणि इव्हेंट रेकॉर्डिंग प्रदान करतात, जे सर्व घटना शोधण्यासाठी पुरेसे नाहीत. उदाहरणार्थ, तुम्हाला फक्त वेबसाइटवरील बदलांचे लॉग किंवा वापरकर्ता प्रमाणीकरण प्रयत्नांचे लॉग प्राप्त होऊ शकतात, परंतु इतर इव्हेंट नाहीत, जसे की नेटवर्क ट्रॅफिक, जे तुमच्यापासून तुमच्या क्लाउड इन्फ्रास्ट्रक्चरला हॅक करण्याच्या प्रयत्नांचे वैशिष्ट्य असलेल्या इव्हेंटचा संपूर्ण स्तर लपवेल.
• नोंदी आहेत, परंतु त्यांच्यापर्यंत प्रवेश स्वयंचलित करणे कठीण आहे, ज्यामुळे त्यांचे सतत निरीक्षण केले जाऊ शकत नाही, परंतु वेळापत्रकानुसार. आणि जर तुम्ही लॉग आपोआप डाउनलोड करू शकत नसाल, तर लॉग डाउनलोड करणे, उदाहरणार्थ, एक्सेल फॉरमॅटमध्ये (जसे की अनेक घरगुती क्लाउड सोल्यूशन प्रदात्यांप्रमाणे), कॉर्पोरेट माहिती सुरक्षा सेवेला त्यांच्याशी टिंकर करण्याची अनिच्छा देखील होऊ शकते.
• लॉग मॉनिटरिंग नाही. क्लाउड वातावरणात माहिती सुरक्षा घटना घडण्याचे हे कदाचित सर्वात अस्पष्ट कारण आहे. असे दिसते की तेथे लॉग आहेत आणि त्यांना स्वयंचलितपणे प्रवेश करणे शक्य आहे, परंतु कोणीही हे करत नाही. का?

सामायिक क्लाउड सुरक्षा संकल्पना

क्लाउडमध्ये संक्रमण हे नेहमीच पायाभूत सुविधांवर नियंत्रण राखण्याची इच्छा आणि ते राखण्यात माहिर असलेल्या क्लाउड प्रदात्याच्या अधिक व्यावसायिक हातात हस्तांतरित करण्याच्या इच्छेमध्ये संतुलन शोधणे असते. आणि क्लाउड सुरक्षेच्या क्षेत्रात, हे संतुलन देखील शोधले पाहिजे. शिवाय, वापरलेल्या क्लाउड सर्व्हिस डिलिव्हरी मॉडेलवर (IaaS, PaaS, SaaS) अवलंबून, ही शिल्लक नेहमीच वेगळी असेल. कोणत्याही परिस्थितीत, आम्ही हे लक्षात ठेवले पाहिजे की आज सर्व क्लाउड प्रदाते तथाकथित सामायिक जबाबदारी आणि सामायिक माहिती सुरक्षा मॉडेलचे अनुसरण करतात. क्लाउड काही गोष्टींसाठी जबाबदार आहे आणि इतरांसाठी क्लायंट जबाबदार आहे, त्याचा डेटा, त्याचे ऍप्लिकेशन, त्याची व्हर्च्युअल मशीन आणि इतर संसाधने क्लाउडमध्ये ठेवतात. क्लाउडवर जाऊन आम्ही सर्व जबाबदारी प्रदात्यावर टाकू अशी अपेक्षा करणे बेपर्वा ठरेल. परंतु क्लाउडवर जाताना सर्व सुरक्षा स्वतः तयार करणे देखील मूर्खपणाचे आहे. शिल्लक आवश्यक आहे, जे अनेक घटकांवर अवलंबून असेल: - जोखीम व्यवस्थापन धोरण, धोक्याचे मॉडेल, क्लाउड प्रदात्यासाठी उपलब्ध सुरक्षा यंत्रणा, कायदे इ.

उदाहरणार्थ, क्लाउडमध्ये होस्ट केलेल्या डेटाचे वर्गीकरण नेहमीच ग्राहकाची जबाबदारी असते. क्लाउड प्रदाता किंवा बाह्य सेवा प्रदाता त्याला केवळ अशा साधनांसह मदत करू शकतात जे क्लाउडमध्ये डेटा चिन्हांकित करण्यात, उल्लंघने ओळखण्यास, कायद्याचे उल्लंघन करणारा डेटा हटविण्यात किंवा एक किंवा दुसरी पद्धत वापरून मास्क करण्यात मदत करतील. दुसरीकडे, भौतिक सुरक्षा ही नेहमी क्लाउड प्रदात्याची जबाबदारी असते, जी तो क्लायंटसह शेअर करू शकत नाही. परंतु डेटा आणि भौतिक पायाभूत सुविधांमधील प्रत्येक गोष्ट या लेखातील चर्चेचा विषय आहे. उदाहरणार्थ, क्लाउडची उपलब्धता ही प्रदात्याची जबाबदारी आहे आणि फायरवॉल नियम सेट करणे किंवा एन्क्रिप्शन सक्षम करणे ही क्लायंटची जबाबदारी आहे. या लेखात आम्ही रशियामधील विविध लोकप्रिय क्लाउड प्रदात्यांद्वारे आज कोणती माहिती सुरक्षा देखरेख यंत्रणा प्रदान केली जाते, त्यांच्या वापराची वैशिष्ट्ये काय आहेत आणि बाह्य आच्छादन उपायांकडे लक्ष देणे केव्हा योग्य आहे हे पाहण्याचा प्रयत्न करू (उदाहरणार्थ, सिस्को ई- मेल सिक्युरिटी) जी सायबर सिक्युरिटीच्या दृष्टीने तुमच्या क्लाउडची क्षमता वाढवते. काही प्रकरणांमध्ये, विशेषतः जर तुम्ही मल्टी-क्लाउड स्ट्रॅटेजी फॉलो करत असाल, तर तुमच्याकडे एकाच वेळी अनेक क्लाउड वातावरणात (उदाहरणार्थ, Cisco CloudLock किंवा Cisco Stealthwatch Cloud) बाह्य माहिती सुरक्षा मॉनिटरिंग सोल्यूशन्स वापरण्याशिवाय पर्याय नसेल. बरं, काही प्रकरणांमध्ये तुमच्या लक्षात येईल की तुम्ही निवडलेला (किंवा तुमच्यावर लादलेला) क्लाउड प्रदाता कोणतीही माहिती सुरक्षा देखरेख क्षमता देत नाही. हे अप्रिय आहे, परंतु थोडेसे देखील नाही, कारण ते आपल्याला या क्लाउडसह कार्य करण्याशी संबंधित जोखमीच्या पातळीचे पुरेसे मूल्यांकन करण्यास अनुमती देते.

क्लाउड सिक्युरिटी मॉनिटरिंग लाइफसायकल

तुम्ही वापरत असलेल्या ढगांच्या सुरक्षिततेचे निरीक्षण करण्यासाठी, तुमच्याकडे फक्त तीन पर्याय आहेत:

• तुमच्या क्लाउड प्रदात्याने प्रदान केलेल्या साधनांवर अवलंबून रहा,
• तृतीय पक्षांकडील उपाय वापरा जे तुम्ही वापरत असलेल्या IaaS, PaaS किंवा SaaS प्लॅटफॉर्मवर लक्ष ठेवतील,
• तुमची स्वतःची क्लाउड मॉनिटरिंग इन्फ्रास्ट्रक्चर तयार करा (केवळ IaaS/PaaS प्लॅटफॉर्मसाठी).

या प्रत्येक पर्यायामध्ये कोणती वैशिष्ट्ये आहेत ते पाहू या. परंतु प्रथम, आम्हाला क्लाउड प्लॅटफॉर्मचे निरीक्षण करताना वापरले जाणारे सामान्य फ्रेमवर्क समजून घेणे आवश्यक आहे. मी क्लाउडमधील माहिती सुरक्षा निरीक्षण प्रक्रियेचे 6 मुख्य घटक हायलाइट करेन:

• पायाभूत सुविधांची तयारी. स्टोरेजमध्ये माहितीच्या सुरक्षिततेसाठी महत्त्वाच्या घटना गोळा करण्यासाठी आवश्यक अनुप्रयोग आणि पायाभूत सुविधा निश्चित करणे.
• संकलन. या टप्प्यावर, प्रक्रिया, स्टोरेज आणि विश्लेषणासाठी त्यानंतरच्या प्रसारणासाठी विविध स्त्रोतांकडून सुरक्षा कार्यक्रम एकत्रित केले जातात.
• उपचार. या टप्प्यावर, त्यानंतरच्या विश्लेषणासाठी डेटाचे रूपांतर आणि समृद्ध केले जाते.
• स्टोरेज. हा घटक संकलित प्रक्रिया केलेल्या आणि कच्च्या डेटाच्या अल्पकालीन आणि दीर्घकालीन स्टोरेजसाठी जबाबदार आहे.
• विश्लेषण. या टप्प्यावर, तुमच्याकडे घटना शोधण्याची आणि त्यांना स्वयंचलितपणे किंवा व्यक्तिचलितपणे प्रतिसाद देण्याची क्षमता आहे.
• अहवाल देत आहे. हा टप्पा भागधारकांसाठी (व्यवस्थापन, लेखा परीक्षक, क्लाउड प्रदाता, क्लायंट इ.) प्रमुख निर्देशक तयार करण्यात मदत करतो जे आम्हाला काही निर्णय घेण्यास मदत करतात, उदाहरणार्थ, प्रदाता बदलणे किंवा माहिती सुरक्षा मजबूत करणे.

हे घटक समजून घेतल्याने भविष्यात तुम्ही तुमच्या प्रदात्याकडून काय घेऊ शकता आणि तुम्हाला स्वतःला किंवा बाह्य सल्लागारांच्या सहभागाने काय करावे लागेल हे त्वरीत ठरवता येईल.

अंगभूत क्लाउड सेवा

मी आधीच वर लिहिले आहे की अनेक क्लाउड सेवा आज कोणतीही माहिती सुरक्षा देखरेख क्षमता प्रदान करत नाहीत. सर्वसाधारणपणे, ते माहिती सुरक्षिततेच्या विषयावर फारसे लक्ष देत नाहीत. उदाहरणार्थ, इंटरनेटद्वारे सरकारी एजन्सींना अहवाल पाठवण्यासाठी लोकप्रिय रशियन सेवांपैकी एक (मी विशेषतः त्याचे नाव सांगणार नाही). या सेवेच्या सुरक्षिततेबद्दलचा संपूर्ण विभाग प्रमाणित CIPF च्या वापराभोवती फिरतो. इलेक्ट्रॉनिक दस्तऐवज व्यवस्थापनासाठी दुसर्या घरगुती क्लाउड सेवेचा माहिती सुरक्षा विभाग वेगळा नाही. हे सार्वजनिक की प्रमाणपत्रे, प्रमाणित क्रिप्टोग्राफी, वेब असुरक्षा दूर करणे, DDoS हल्ल्यांपासून संरक्षण, फायरवॉल वापरणे, बॅकअप आणि अगदी नियमित माहिती सुरक्षा ऑडिट बद्दल बोलतो. परंतु या सेवा प्रदात्याच्या क्लायंटला स्वारस्य असलेल्या माहिती सुरक्षा इव्हेंट्समध्ये प्रवेश मिळवण्याच्या शक्यतेबद्दल किंवा देखरेख करण्याबद्दल एक शब्दही नाही.

सर्वसाधारणपणे, क्लाउड प्रदाता त्याच्या वेबसाइटवर आणि त्याच्या दस्तऐवजीकरणामध्ये माहिती सुरक्षिततेच्या समस्यांचे वर्णन करत असताना, ही समस्या किती गांभीर्याने घेते हे तुम्ही समजू शकता. उदाहरणार्थ, जर तुम्ही “माय ऑफिस” उत्पादनांसाठी मॅन्युअल वाचले, तर सुरक्षिततेबद्दल अजिबात शब्द नाही, परंतु “माय ऑफिस” या स्वतंत्र उत्पादनाच्या दस्तऐवजीकरणात. KS3", अनधिकृत प्रवेशापासून संरक्षण करण्यासाठी डिझाइन केलेले, FSTEC च्या 17 व्या ऑर्डरच्या बिंदूंची एक नेहमीची सूची असते, जी "My Office.KS3" लागू करते, परंतु ते ते कसे लागू करते आणि सर्वात महत्त्वाचे म्हणजे, कसे करावे याचे वर्णन केलेले नाही. कॉर्पोरेट माहिती सुरक्षिततेसह या यंत्रणा एकत्रित करा. कदाचित असे दस्तऐवजीकरण अस्तित्वात आहे, परंतु मला ते सार्वजनिक डोमेनमध्ये, “माय ऑफिस” वेबसाइटवर सापडले नाही. जरी कदाचित मला या गुप्त माहितीमध्ये प्रवेश नाही?..

बिट्रिक्ससाठी, परिस्थिती खूपच चांगली आहे. दस्तऐवजीकरण इव्हेंट लॉगचे स्वरूप आणि मनोरंजकपणे, घुसखोरी लॉगचे वर्णन करते, ज्यामध्ये क्लाउड प्लॅटफॉर्मवरील संभाव्य धोक्यांशी संबंधित इव्हेंट असतात. तेथून तुम्ही आयपी, वापरकर्ता किंवा अतिथी नाव, इव्हेंट स्त्रोत, वेळ, वापरकर्ता एजंट, इव्हेंट प्रकार इत्यादी काढू शकता. खरे आहे, तुम्ही क्लाउडच्या कंट्रोल पॅनलमधून या इव्हेंटसह कार्य करू शकता किंवा एमएस एक्सेल फॉरमॅटमध्ये डेटा अपलोड करू शकता. आता Bitrix लॉगसह कार्य स्वयंचलित करणे अवघड आहे आणि तुम्हाला काही काम स्वतः करावे लागेल (अहवाल अपलोड करणे आणि ते तुमच्या SIEM मध्ये लोड करणे). परंतु जर आपल्याला आठवत असेल की तुलनेने अलीकडे अशी संधी अस्तित्वात नव्हती, तर ही मोठी प्रगती आहे. त्याच वेळी, मी हे लक्षात घेऊ इच्छितो की अनेक परदेशी क्लाउड प्रदाते "नवशिक्यांसाठी" समान कार्यक्षमता ऑफर करतात - एकतर नियंत्रण पॅनेलद्वारे आपल्या डोळ्यांनी लॉग पहा किंवा डेटा स्वतः अपलोड करा (तथापि, बहुतेक डेटा . csv फॉरमॅट, एक्सेल नाही).

नो-लॉग्स पर्यायाचा विचार न करता, क्लाउड प्रदाते सहसा तुम्हाला सुरक्षा इव्हेंट्सचे निरीक्षण करण्यासाठी तीन पर्याय देतात - डॅशबोर्ड, डेटा अपलोड आणि API प्रवेश. प्रथम तुमच्यासाठी अनेक समस्यांचे निराकरण करते असे दिसते, परंतु हे पूर्णपणे सत्य नाही - जर तुमच्याकडे अनेक मासिके असतील, तर तुम्हाला ते प्रदर्शित करणार्‍या स्क्रीन्समध्ये स्विच करावे लागेल, एकूण चित्र गमावून बसावे लागेल. याव्यतिरिक्त, क्लाउड प्रदाता तुम्हाला सुरक्षितता इव्हेंट्सशी परस्परसंबंधित करण्याची आणि सामान्यत: सुरक्षिततेच्या दृष्टिकोनातून त्यांचे विश्लेषण करण्याची क्षमता प्रदान करण्याची शक्यता नाही (सामान्यत: तुम्ही कच्च्या डेटासह व्यवहार करत आहात, जो तुम्हाला स्वतःला समजून घेणे आवश्यक आहे). अपवाद आहेत आणि आम्ही त्यांच्याबद्दल पुढे बोलू. शेवटी, तुमच्या क्लाउड प्रदात्याद्वारे कोणते इव्हेंट रेकॉर्ड केले जातात हे विचारणे योग्य आहे, कोणत्या स्वरूपात आणि ते तुमच्या माहिती सुरक्षा निरीक्षण प्रक्रियेशी कसे संबंधित आहेत? उदाहरणार्थ, वापरकर्ते आणि अतिथींची ओळख आणि प्रमाणीकरण. तेच Bitrix तुम्हाला, या इव्हेंटच्या आधारावर, इव्हेंटची तारीख आणि वेळ, वापरकर्त्याचे किंवा अतिथीचे नाव (जर तुमच्याकडे “वेब अॅनालिटिक्स” मॉड्यूल असल्यास), प्रवेश केलेला ऑब्जेक्ट आणि वेबसाइटसाठी वैशिष्ट्यपूर्ण इतर घटक रेकॉर्ड करण्याची परवानगी देते. . परंतु कॉर्पोरेट माहिती सुरक्षा सेवांना वापरकर्त्याने विश्वसनीय डिव्हाइसवरून क्लाउडमध्ये प्रवेश केला की नाही याबद्दल माहितीची आवश्यकता असू शकते (उदाहरणार्थ, कॉर्पोरेट नेटवर्कमध्ये हे कार्य Cisco ISE द्वारे लागू केले जाते). जिओ-आयपी फंक्शनसारख्या सोप्या कार्याचे काय, जे क्लाउड सेवा वापरकर्ता खाते चोरीला गेले आहे की नाही हे निर्धारित करण्यात मदत करेल? आणि जरी क्लाउड प्रदाता तुम्हाला ते प्रदान करत असले तरीही हे पुरेसे नाही. समान Cisco CloudLock केवळ भौगोलिक स्थानाचे विश्लेषण करत नाही, परंतु यासाठी मशीन लर्निंग वापरते आणि प्रत्येक वापरकर्त्यासाठी ऐतिहासिक डेटाचे विश्लेषण करते आणि ओळख आणि प्रमाणीकरणाच्या प्रयत्नांमधील विविध विसंगतींचे परीक्षण करते. फक्त MS Azure कडे समान कार्यक्षमता आहे (जर तुमच्याकडे योग्य सदस्यत्व असेल).

आणखी एक अडचण आहे - कारण अनेक क्लाउड प्रदात्यांसाठी माहिती सुरक्षा देखरेख हा एक नवीन विषय आहे ज्याला ते नुकतेच सामोरे जात आहेत, ते त्यांच्या उपायांमध्ये सतत काहीतरी बदलत आहेत. आज त्यांच्याकडे API ची एक आवृत्ती आहे, उद्या दुसरी, परवा तिसरी. यासाठी तुम्हालाही तयार राहावे लागेल. कार्यक्षमतेबाबतही हेच खरे आहे, जे बदलू शकते, जे तुमच्या माहिती सुरक्षा निरीक्षण प्रणालीमध्ये विचारात घेतले पाहिजे. उदाहरणार्थ, Amazon कडे सुरुवातीला वेगळ्या क्लाउड इव्हेंट मॉनिटरिंग सेवा होत्या—AWS CloudTrail आणि AWS CloudWatch. नंतर माहिती सुरक्षा इव्हेंट्सचे निरीक्षण करण्यासाठी एक वेगळी सेवा दिसू लागली - AWS GuardDuty. काही काळानंतर, Amazon ने एक नवीन व्यवस्थापन प्रणाली, Amazon Security Hub लाँच केली, ज्यामध्ये GuardDuty, Amazon Inspector, Amazon Macie आणि इतर अनेकांकडून मिळालेल्या डेटाचे विश्लेषण समाविष्ट आहे. दुसरे उदाहरण म्हणजे SIEM - AzLog सह Azure लॉग इंटिग्रेशन टूल. हे अनेक SIEM विक्रेत्यांकडून सक्रियपणे वापरले जात होते, जोपर्यंत 2018 मध्ये मायक्रोसॉफ्टने त्याचा विकास आणि समर्थन बंद करण्याची घोषणा केली होती, ज्याने या साधनाचा वापर करणाऱ्या अनेक क्लायंटला समस्येचा सामना करावा लागला (आम्ही त्याचे निराकरण कसे केले याबद्दल नंतर बोलू).

म्हणून, तुमचा क्लाउड प्रदाता तुम्हाला ऑफर करत असलेल्या सर्व मॉनिटरिंग वैशिष्ट्यांचे काळजीपूर्वक निरीक्षण करा. किंवा बाह्य समाधान प्रदात्यांवर विसंबून राहा जे तुमची SOC आणि तुम्ही देखरेख करू इच्छित असलेल्या क्लाउडमध्ये मध्यस्थ म्हणून काम करतील. होय, ते अधिक महाग असेल (जरी नेहमीच नाही), परंतु तुम्ही सर्व जबाबदारी दुसऱ्याच्या खांद्यावर टाकाल. किंवा हे सर्व नाही?.. सामायिक सुरक्षिततेची संकल्पना लक्षात ठेवू आणि आपण काहीही बदलू शकत नाही हे समजून घेऊ - भिन्न क्लाउड प्रदाते आपला डेटा, ऍप्लिकेशन्स, व्हर्च्युअल मशीन आणि इतर संसाधनांच्या माहिती सुरक्षिततेचे निरीक्षण कसे करतात हे आपल्याला स्वतंत्रपणे समजून घ्यावे लागेल. मेघ मध्ये होस्ट केले. आणि आम्ही या भागात ऍमेझॉन काय ऑफर करतो त्यापासून सुरुवात करू.

उदाहरण: AWS वर आधारित IaaS मध्ये माहिती सुरक्षा निरीक्षण

होय, होय, मला समजले आहे की Amazon ही एक अमेरिकन सेवा आहे या वस्तुस्थितीमुळे सर्वोत्तम उदाहरण नाही आणि अतिवाद आणि रशियामध्ये प्रतिबंधित माहितीच्या प्रसाराचा भाग म्हणून ते अवरोधित केले जाऊ शकते. परंतु या प्रकाशनात मी हे दर्शवू इच्छितो की भिन्न क्लाउड प्लॅटफॉर्म त्यांच्या माहिती सुरक्षा देखरेख क्षमतेमध्ये कसे भिन्न आहेत आणि सुरक्षिततेच्या दृष्टिकोनातून आपल्या मुख्य प्रक्रिया क्लाउडमध्ये हस्तांतरित करताना आपण कशाकडे लक्ष दिले पाहिजे. ठीक आहे, जर क्लाउड सोल्यूशन्सच्या काही रशियन विकसकांनी स्वतःसाठी काहीतरी उपयुक्त शिकले तर ते खूप चांगले होईल.

पहिली गोष्ट म्हणजे Amazon हा अभेद्य किल्ला नाही. त्याच्या ग्राहकांसोबत विविध घटना नियमितपणे घडत असतात. उदाहरणार्थ, डीप रूट अॅनालिटिक्समधून १९८ दशलक्ष मतदारांची नावे, पत्ते, जन्मतारीख आणि दूरध्वनी क्रमांक चोरले गेले. इस्त्रायली कंपनी नाइस सिस्टम्सने व्हेरिझॉन सदस्यांच्या 198 दशलक्ष रेकॉर्ड चोरल्या. तथापि, AWS च्या अंगभूत क्षमता तुम्हाला घटनांची विस्तृत श्रेणी शोधण्याची परवानगी देतात. उदाहरणार्थ:

• पायाभूत सुविधांवर परिणाम (DDoS)
• नोड तडजोड (कमांड इंजेक्शन)
• खाते तडजोड आणि अनधिकृत प्रवेश
• चुकीचे कॉन्फिगरेशन आणि भेद्यता
• असुरक्षित इंटरफेस आणि API.

ही विसंगती या वस्तुस्थितीमुळे आहे की, आम्ही वर शोधल्याप्रमाणे, ग्राहक स्वतः ग्राहक डेटाच्या सुरक्षिततेसाठी जबाबदार आहे. आणि जर त्याने संरक्षक यंत्रणा चालू करण्याची तसदी घेतली नाही आणि देखरेखीची साधने चालू केली नाहीत, तर तो केवळ मीडिया किंवा त्याच्या क्लायंटकडून या घटनेबद्दल शिकेल.

घटना ओळखण्यासाठी, तुम्ही Amazon द्वारे विकसित केलेल्या विविध देखरेख सेवांच्या विस्तृत श्रेणीचा वापर करू शकता (जरी या अनेकदा बाह्य साधनांनी पूरक असतात जसे की osquery). म्हणून, AWS मध्ये, सर्व वापरकर्त्यांच्या क्रियांचे निरीक्षण केले जाते, त्या कशा केल्या जातात याची पर्वा न करता - व्यवस्थापन कन्सोल, कमांड लाइन, SDK किंवा इतर AWS सेवांद्वारे. प्रत्येक AWS खात्याच्या क्रियाकलापाचे सर्व रेकॉर्ड (वापरकर्तानाव, क्रिया, सेवा, क्रियाकलाप पॅरामीटर्स आणि परिणामांसह) आणि API वापर AWS CloudTrail द्वारे उपलब्ध आहेत. तुम्ही क्लाउडट्रेल कन्सोलवरून हे इव्हेंट (जसे की AWS IAM कन्सोल लॉगिन) पाहू शकता, Amazon Athena वापरून त्यांचे विश्लेषण करू शकता किंवा Splunk, AlienVault इ. सारख्या बाह्य उपायांसाठी "आउटसोर्स" करू शकता. AWS CloudTrail लॉग स्वतः तुमच्या AWS S3 बकेटमध्ये ठेवलेले असतात.

दोन इतर AWS सेवा इतर अनेक महत्त्वाच्या देखरेख क्षमता प्रदान करतात. प्रथम, Amazon CloudWatch ही AWS संसाधने आणि अनुप्रयोगांसाठी एक देखरेख सेवा आहे जी इतर गोष्टींबरोबरच, तुम्हाला तुमच्या क्लाउडमधील विविध विसंगती ओळखण्याची परवानगी देते. Amazon Elastic Compute Cloud (सर्व्हर्स), Amazon Relational Database Service (database), Amazon Elastic MapReduce (डेटा विश्लेषण), आणि इतर 30 Amazon सेवा यासारख्या सर्व अंगभूत AWS सेवा, त्यांचे लॉग संग्रहित करण्यासाठी Amazon CloudWatch वापरतात. डेव्हलपर सानुकूल अॅप्लिकेशन्स आणि सेवांमध्ये लॉग मॉनिटरिंग कार्यक्षमता जोडण्यासाठी Amazon CloudWatch मधील ओपन API वापरू शकतात, ज्यामुळे त्यांना सुरक्षा संदर्भात इव्हेंट विश्लेषणाची व्याप्ती वाढवता येते.

दुसरे म्हणजे, व्हीपीसी फ्लो लॉग सेवा तुम्हाला तुमच्या AWS सर्व्हरद्वारे (बाहेरून किंवा अंतर्गत) पाठवलेल्या किंवा प्राप्त झालेल्या नेटवर्क ट्रॅफिकचे विश्लेषण करण्याची परवानगी देते तसेच मायक्रो सर्व्हिसेसमध्ये. जेव्हा तुमची कोणतीही AWS VPC संसाधने नेटवर्कशी संवाद साधतात, तेव्हा VPC फ्लो लॉग नेटवर्क रहदारीबद्दल तपशील रेकॉर्ड करतात, ज्यामध्ये स्त्रोत आणि गंतव्य नेटवर्क इंटरफेस, तसेच IP पत्ते, पोर्ट, प्रोटोकॉल, बाइट्सची संख्या आणि तुम्ही पॅकेटची संख्या समाविष्ट केली आहे. पाहिले. ज्यांना स्थानिक नेटवर्क सुरक्षिततेचा अनुभव आहे ते हे थ्रेड्सचे समान म्हणून ओळखतील नेटफ्लो, जे स्विच, राउटर आणि एंटरप्राइझ-ग्रेड फायरवॉलद्वारे तयार केले जाऊ शकते. हे लॉग माहिती सुरक्षा निरीक्षणाच्या उद्देशांसाठी महत्त्वाचे आहेत कारण, वापरकर्ते आणि ऍप्लिकेशन्सच्या कृतींबद्दलच्या घटनांपेक्षा वेगळे, ते तुम्हाला AWS आभासी खाजगी क्लाउड वातावरणात नेटवर्क परस्परसंवाद गमावू देऊ नका.

सारांश, या तीन AWS सेवा—AWS CloudTrail, Amazon CloudWatch, आणि VPC फ्लो लॉग—एकत्रितपणे तुमच्या खात्याचा वापर, वापरकर्ता वर्तन, पायाभूत सुविधा व्यवस्थापन, अनुप्रयोग आणि सेवा क्रियाकलाप आणि नेटवर्क क्रियाकलाप याबद्दल बऱ्यापैकी शक्तिशाली अंतर्दृष्टी प्रदान करतात. उदाहरणार्थ, ते खालील विसंगती शोधण्यासाठी वापरले जाऊ शकतात:

• साइट स्कॅन करण्याचा प्रयत्न, मागील दरवाजा शोधणे, "404 त्रुटी" च्या स्फोटांद्वारे भेद्यता शोधणे.
• इंजेक्शन हल्ले (उदाहरणार्थ, एसक्यूएल इंजेक्शन) “500 त्रुटी” च्या स्फोटांद्वारे.
• ज्ञात हल्ला साधने sqlmap, nikto, w3af, nmap, इ. वापरकर्ता एजंट फील्डच्या विश्लेषणाद्वारे.

Amazon Web Services ने सायबरसुरक्षा उद्देशांसाठी इतर सेवा देखील विकसित केल्या आहेत ज्या तुम्हाला इतर अनेक समस्यांचे निराकरण करण्यास अनुमती देतात. उदाहरणार्थ, AWS मध्ये ऑडिटिंग पॉलिसी आणि कॉन्फिगरेशनसाठी अंगभूत सेवा आहे - AWS कॉन्फिगरेशन. ही सेवा तुमच्या AWS संसाधनांचे आणि त्यांच्या कॉन्फिगरेशनचे सतत ऑडिट करते. चला एक साधे उदाहरण घेऊ: समजा तुम्ही तुमच्या सर्व सर्व्हरवर वापरकर्ता संकेतशब्द अक्षम केले आहेत आणि प्रवेश केवळ प्रमाणपत्रांच्या आधारे शक्य आहे याची खात्री करावयाची आहे. AWS कॉन्फिग आपल्या सर्व सर्व्हरसाठी हे तपासणे सोपे करते. तुमच्या क्लाउड सर्व्हरवर लागू करता येणारी इतर धोरणे आहेत: “कोणताही सर्व्हर पोर्ट 22 वापरू शकत नाही”, “केवळ प्रशासक फायरवॉल नियम बदलू शकतात” किंवा “केवळ वापरकर्ता इवाश्को नवीन वापरकर्ता खाती तयार करू शकतो आणि तो फक्त मंगळवारीच करू शकतो. " 2016 च्या उन्हाळ्यात, AWS कॉन्फिग सेवेचा विस्तार विकसित धोरणांच्या उल्लंघनाचा शोध स्वयंचलित करण्यासाठी केला गेला. AWS कॉन्फिगरेशन नियम हे मूलत: तुम्ही वापरत असलेल्या Amazon सेवांसाठी सतत कॉन्फिगरेशन विनंत्या आहेत, जे संबंधित धोरणांचे उल्लंघन केल्यास इव्हेंट तयार करतात. उदाहरणार्थ, व्हर्च्युअल सर्व्हरवरील सर्व डिस्क्स एनक्रिप्टेड आहेत याची पडताळणी करण्यासाठी वेळोवेळी AWS कॉन्फिग क्वेरी चालवण्याऐवजी, ही अट पूर्ण झाली आहे याची खात्री करण्यासाठी AWS कॉन्फिग नियम सतत सर्व्हर डिस्क तपासण्यासाठी वापरले जाऊ शकतात. आणि, सर्वात महत्त्वाचे म्हणजे, या प्रकाशनाच्या संदर्भात, कोणतेही उल्लंघन अशा घटना निर्माण करतात ज्यांचे विश्लेषण आपल्या माहिती सुरक्षा सेवेद्वारे केले जाऊ शकते.

AWS कडे पारंपारिक कॉर्पोरेट माहिती सुरक्षा सोल्यूशन्सच्या समतुल्य आहे, जे सुरक्षा इव्हेंट देखील तयार करतात ज्यांचे तुम्ही विश्लेषण करू शकता आणि करू शकता:

• घुसखोरी शोध - AWS GuardDuty
• माहिती गळती नियंत्रण - AWS Macie
• EDR (जरी ते क्लाउडमधील एंडपॉइंट्सबद्दल थोडे विचित्रपणे बोलत असले तरी) - AWS क्लाउडवॉच + ओपन सोर्स ऑस्क्वेरी किंवा GRR उपाय
• नेटफ्लो विश्लेषण - AWS क्लाउडवॉच + AWS VPC प्रवाह
• DNS विश्लेषण - AWS क्लाउडवॉच + AWS मार्ग53
• AD - AWS निर्देशिका सेवा
• खाते व्यवस्थापन - AWS IAM
• SSO - AWS SSO
• सुरक्षा विश्लेषण - AWS निरीक्षक
• कॉन्फिगरेशन व्यवस्थापन - AWS कॉन्फिगरेशन
• WAF - AWS WAF.

माहिती सुरक्षिततेच्या संदर्भात उपयुक्त ठरणाऱ्या सर्व Amazon सेवांचे मी तपशीलवार वर्णन करणार नाही. मुख्य गोष्ट म्हणजे हे समजून घेणे आवश्यक आहे की ते सर्व इव्हेंट्स व्युत्पन्न करू शकतात ज्यांचे आपण माहिती सुरक्षिततेच्या संदर्भात विश्लेषण करू शकतो आणि करू शकतो, या उद्देशासाठी ऍमेझॉनच्या स्वतःच्या अंगभूत क्षमता आणि बाह्य उपाय या दोन्हींचा वापर करून, उदाहरणार्थ, SIEM, जे करू शकते. सुरक्षा इव्हेंट्स तुमच्या मॉनिटरिंग सेंटरमध्ये घेऊन जा आणि इतर क्लाउड सेवा किंवा अंतर्गत इन्फ्रास्ट्रक्चर, परिमिती किंवा मोबाइल डिव्हाइसवरील इव्हेंटसह त्यांचे विश्लेषण करा.

कोणत्याही परिस्थितीत, हे सर्व डेटा स्त्रोतांपासून सुरू होते जे आपल्याला माहिती सुरक्षा इव्हेंट प्रदान करतात. या स्त्रोतांमध्ये हे समाविष्ट आहे, परंतु इतकेच मर्यादित नाही:

• CloudTrail - API वापर आणि वापरकर्ता क्रिया
• विश्वसनीय सल्लागार - सर्वोत्तम पद्धतींविरूद्ध सुरक्षा तपासणी
• कॉन्फिग - इन्व्हेंटरी आणि खाती आणि सेवा सेटिंग्जची कॉन्फिगरेशन
• व्हीपीसी फ्लो लॉग - व्हर्च्युअल इंटरफेसशी कनेक्शन
• IAM - ओळख आणि प्रमाणीकरण सेवा
• ELB प्रवेश लॉग - लोड बॅलन्सर
• निरीक्षक - अनुप्रयोग भेद्यता
• S3 - फाइल स्टोरेज
• CloudWatch - अनुप्रयोग क्रियाकलाप
• SNS ही एक सूचना सेवा आहे.

Amazon, त्यांच्या पिढीसाठी इव्हेंट स्रोत आणि साधनांची श्रेणी ऑफर करत असताना, माहिती सुरक्षिततेच्या संदर्भात गोळा केलेल्या डेटाचे विश्लेषण करण्याची क्षमता खूपच मर्यादित आहे. तुम्हाला उपलब्ध नोंदींचा स्वतंत्रपणे अभ्यास करावा लागेल, त्यातील तडजोडीचे संबंधित संकेतक शोधावे लागतील. AWS सिक्युरिटी हब, जे Amazon ने अलीकडेच लाँच केले आहे, AWS साठी क्लाउड SIEM बनून या समस्येचे निराकरण करण्याचे उद्दिष्ट आहे. परंतु आतापर्यंत ते केवळ त्याच्या प्रवासाच्या सुरुवातीस आहे आणि ते ज्या स्त्रोतांसह कार्य करते त्या स्त्रोतांच्या संख्येनुसार आणि आर्किटेक्चर आणि अॅमेझॉनच्या सदस्यत्वांद्वारे स्थापित केलेल्या इतर निर्बंधांद्वारे मर्यादित आहे.

उदाहरण: Azure वर आधारित IaaS मध्ये माहिती सुरक्षा निरीक्षण

तीन क्लाउड प्रदाते (अमेझॉन, मायक्रोसॉफ्ट किंवा गुगल) पैकी कोणते चांगले आहे याबद्दल मला दीर्घ वादविवादात पडायचे नाही (विशेषत: त्यांच्यापैकी प्रत्येकाची अजूनही स्वतःची विशिष्ट वैशिष्ट्ये आहेत आणि ते स्वतःच्या समस्या सोडवण्यासाठी योग्य आहेत); हे खेळाडू प्रदान करत असलेल्या माहिती सुरक्षा निरीक्षण क्षमतांवर लक्ष केंद्रित करूया. हे मान्य केलेच पाहिजे की Amazon AWS या विभागातील पहिल्यांपैकी एक होता आणि म्हणूनच माहिती सुरक्षा कार्यांच्या बाबतीत ते सर्वात पुढे प्रगत झाले आहे (जरी ते वापरणे कठीण आहे हे अनेकांनी मान्य केले आहे). परंतु याचा अर्थ असा नाही की आम्ही Microsoft आणि Google द्वारे प्रदान केलेल्या संधींकडे दुर्लक्ष करू.

मायक्रोसॉफ्ट उत्पादने नेहमीच त्यांच्या "मोकळेपणा" द्वारे ओळखली जातात आणि अझूरमध्ये परिस्थिती समान आहे. उदाहरणार्थ, जर AWS आणि GCP नेहमी "ज्याला परवानगी नाही ते प्रतिबंधित आहे" या संकल्पनेतून पुढे जात असेल तर Azure कडे अगदी विरुद्ध दृष्टीकोन आहे. उदाहरणार्थ, क्लाउडमध्ये व्हर्च्युअल नेटवर्क आणि त्यात व्हर्च्युअल मशीन तयार करताना, सर्व पोर्ट आणि प्रोटोकॉल उघडलेले असतात आणि डीफॉल्टनुसार परवानगी दिली जाते. त्यामुळे, मायक्रोसॉफ्टकडून क्लाउडमधील ऍक्सेस कंट्रोल सिस्टमच्या सुरुवातीच्या सेटअपवर तुम्हाला थोडे अधिक प्रयत्न करावे लागतील. आणि हे Azure क्लाउडमधील क्रियाकलापांच्या देखरेखीच्या दृष्टीने तुमच्यावर अधिक कठोर आवश्यकता लादते.

AWS चे एक वैशिष्ठ्य या वस्तुस्थितीशी निगडीत आहे की जेव्हा तुम्ही तुमच्या व्हर्च्युअल संसाधनांचे निरीक्षण करता, जर ते वेगवेगळ्या प्रदेशात असतील, तर तुम्हाला सर्व इव्हेंट्स आणि त्यांचे एकत्रित विश्लेषण एकत्र करण्यात अडचणी येतात, ज्या दूर करण्यासाठी तुम्हाला विविध युक्त्यांचा अवलंब करावा लागतो, जसे की AWS Lambda साठी तुमचा स्वतःचा कोड तयार करा जो प्रदेशांमधील इव्हेंटची वाहतूक करेल. Azure ला ही समस्या नाही - त्याची अ‍ॅक्टिव्हिटी लॉग यंत्रणा निर्बंधांशिवाय संपूर्ण संस्थेतील सर्व क्रियाकलापांचा मागोवा घेते. हेच AWS सिक्युरिटी हबला लागू होते, जे अलीकडे Amazon द्वारे एकाच सुरक्षा केंद्रामध्ये अनेक सुरक्षा कार्ये एकत्रित करण्यासाठी विकसित केले गेले होते, परंतु केवळ त्याच्या प्रदेशात, जे तथापि, रशियासाठी संबंधित नाही. Azure चे स्वतःचे सुरक्षा केंद्र आहे, जे प्रादेशिक निर्बंधांनी बांधलेले नाही, क्लाउड प्लॅटफॉर्मच्या सर्व सुरक्षा वैशिष्ट्यांमध्ये प्रवेश प्रदान करते. शिवाय, वेगवेगळ्या स्थानिक संघांसाठी ते त्यांच्याद्वारे व्यवस्थापित केलेल्या सुरक्षा कार्यक्रमांसह स्वतःच्या संरक्षणात्मक क्षमतांचा संच प्रदान करू शकतात. AWS सिक्युरिटी हब अजूनही Azure सिक्युरिटी सेंटरसारखे बनण्याच्या मार्गावर आहे. परंतु मलममध्ये एक माशी जोडणे फायदेशीर आहे - तुम्ही Azure मधून पूर्वी AWS मध्ये वर्णन केलेले बरेच काही पिळून काढू शकता, परंतु हे फक्त Azure AD, Azure Monitor आणि Azure सुरक्षा केंद्रासाठी सर्वात सोयीस्करपणे केले जाते. इतर सर्व Azure सुरक्षा यंत्रणा, सुरक्षा कार्यक्रम विश्लेषणासह, अद्याप सर्वात सोयीस्कर पद्धतीने व्यवस्थापित केलेले नाहीत. समस्या अंशतः API द्वारे सोडवली जाते, जी सर्व Microsoft Azure सेवांमध्ये व्यापते, परंतु यासाठी तुमच्या क्लाउडला तुमच्या SOC आणि पात्र तज्ञांची उपस्थिती (खरेतर, इतर कोणत्याही SIEM प्रमाणेच) सोबत काम करणार्‍या सोबत जोडण्यासाठी तुमच्याकडून अतिरिक्त प्रयत्न करावे लागतील. क्लाउड API). काही SIEM, ज्यांची नंतर चर्चा केली जाईल, ते आधीच Azure ला समर्थन देतात आणि त्याचे निरीक्षण करण्याचे कार्य स्वयंचलित करू शकतात, परंतु त्याच्या स्वतःच्या अडचणी देखील आहेत - ते सर्व Azure कडे असलेले सर्व लॉग गोळा करू शकत नाहीत.

Azure मध्‍ये इव्‍हेंट कलेक्‍शन आणि मॉनिटरिंग हे Azure मॉनिटर सेवेचा वापर करून पुरविले जाते, जे Microsoft क्लाउडमध्‍ये डेटा संकलित, संग्रहित आणि विश्‍लेषित करण्‍याचे मुख्‍य साधन आहे - Git रिपॉझिटरीज, कंटेनर, व्हर्च्युअल मशीन, अॅप्लिकेशन इ. Azure मॉनिटरद्वारे संकलित केलेला सर्व डेटा दोन श्रेणींमध्ये विभागला गेला आहे - मेट्रिक्स, रीअल टाइममध्ये गोळा केलेले आणि Azure क्लाउडचे मुख्य कार्यप्रदर्शन निर्देशकांचे वर्णन करणारे आणि लॉग, ज्यामध्ये Azure संसाधने आणि सेवांच्या क्रियाकलापांच्या विशिष्ट पैलूंचे वैशिष्ट्य असलेल्या रेकॉर्डमध्ये आयोजित केलेला डेटा आहे. याव्यतिरिक्त, डेटा कलेक्टर API वापरून, Azure मॉनिटर सेवा स्वतःचे निरीक्षण परिस्थिती तयार करण्यासाठी कोणत्याही REST स्त्रोताकडून डेटा संकलित करू शकते.

येथे काही सुरक्षा इव्हेंट स्रोत आहेत जे Azure तुम्हाला ऑफर करते आणि तुम्ही Azure पोर्टल, CLI, PowerShell किंवा REST API (आणि काही फक्त Azure Monitor/Insight API द्वारे) प्रवेश करू शकता:

• अ‍ॅक्टिव्हिटी लॉग - हा लॉग क्लाउड संसाधनांवर कोणत्याही लेखन ऑपरेशन (पुट, पोस्ट, हटवा) संबंधित "कोण," "काय," आणि "केव्हा" च्या उत्कृष्ट प्रश्नांची उत्तरे देतो. रीड ऍक्सेस (GET) शी संबंधित इव्हेंट इतर अनेकांप्रमाणे या लॉगमध्ये समाविष्ट केलेले नाहीत.
• डायग्नोस्टिक लॉग - तुमच्या सबस्क्रिप्शनमध्ये समाविष्ट असलेल्या विशिष्ट संसाधनासह ऑपरेशन्सचा डेटा समाविष्ट आहे.
• Azure AD रिपोर्टिंग - गट आणि वापरकर्ता व्यवस्थापनाशी संबंधित वापरकर्ता क्रियाकलाप आणि सिस्टम क्रियाकलाप दोन्ही समाविष्टीत आहे.
• विंडोज इव्हेंट लॉग आणि लिनक्स सिस्लॉग - क्लाउडमध्ये होस्ट केलेल्या व्हर्च्युअल मशीनमधील इव्हेंट समाविष्ट करतात.
• मेट्रिक्स - तुमच्या क्लाउड सेवा आणि संसाधनांच्या कार्यप्रदर्शन आणि आरोग्य स्थितीबद्दल टेलीमेट्री असते. दर मिनिटाला मोजले आणि साठवले. 30 दिवसांच्या आत.
• नेटवर्क सिक्युरिटी ग्रुप फ्लो लॉग्स - नेटवर्क वॉचर सेवा वापरून संकलित केलेल्या नेटवर्क सिक्युरिटी इव्हेंट्सवरील डेटा आणि नेटवर्क स्तरावर संसाधन निरीक्षण समाविष्ट करते.
• स्टोरेज लॉग - स्टोरेज सुविधांशी संबंधित इव्हेंट समाविष्ट करतात.

देखरेखीसाठी, तुम्ही बाह्य SIEMs किंवा अंगभूत Azure Monitor आणि त्याचे विस्तार वापरू शकता. आम्ही माहिती सुरक्षा इव्हेंट मॅनेजमेंट सिस्टमबद्दल नंतर बोलू, परंतु आत्तासाठी सुरक्षिततेच्या संदर्भात डेटा विश्लेषणासाठी Azure स्वतः काय ऑफर करते ते पाहू. Azure मॉनिटरमधील सुरक्षितता-संबंधित प्रत्येक गोष्टीसाठी मुख्य स्क्रीन म्हणजे लॉग अॅनालिटिक्स सिक्युरिटी आणि ऑडिट डॅशबोर्ड (विनामूल्य आवृत्ती केवळ एका आठवड्यासाठी मर्यादित प्रमाणात इव्हेंट स्टोरेजला सपोर्ट करते). हा डॅशबोर्ड 5 मुख्य भागात विभागलेला आहे जो तुम्ही वापरत असलेल्या क्लाउड वातावरणात काय घडत आहे याची सारांश आकडेवारी पाहतो:

• सुरक्षा डोमेन - माहिती सुरक्षिततेशी संबंधित मुख्य परिमाणात्मक निर्देशक - घटनांची संख्या, तडजोड नोड्सची संख्या, अनपॅच नोड्स, नेटवर्क सुरक्षा इव्हेंट इ.
• उल्लेखनीय समस्या - सक्रिय माहिती सुरक्षा समस्यांची संख्या आणि महत्त्व प्रदर्शित करते
• डिटेक्शन्स - तुमच्या विरुद्ध वापरलेल्या हल्ल्यांचे नमुने दाखवते
• थ्रेट इंटेलिजन्स - तुमच्यावर हल्ला करणाऱ्या बाह्य नोड्सवर भौगोलिक माहिती प्रदर्शित करते
• सामान्य सुरक्षा प्रश्न - ठराविक क्वेरी ज्या तुम्हाला तुमच्या माहितीच्या सुरक्षिततेचे चांगल्या प्रकारे निरीक्षण करण्यात मदत करतील.

Azure मॉनिटर विस्तारांमध्ये Azure Key Vault (क्लाउडमधील क्रिप्टोग्राफिक कीजचे संरक्षण), मालवेअर असेसमेंट (व्हर्च्युअल मशीनवरील दुर्भावनापूर्ण कोडपासून संरक्षणाचे विश्लेषण), Azure ऍप्लिकेशन गेटवे अॅनालिसिस (इतर गोष्टींसह, क्लाउड फायरवॉल लॉगचे विश्लेषण) इ. . इव्हेंट्सवर प्रक्रिया करण्यासाठी विशिष्ट नियमांसह समृद्ध केलेली ही साधने तुम्हाला सुरक्षिततेसह क्लाउड सेवांच्या क्रियाकलापांच्या विविध पैलूंची कल्पना करण्यास आणि ऑपरेशनमधील काही विचलन ओळखण्याची परवानगी देतात. परंतु, जसे अनेकदा घडते, कोणत्याही अतिरिक्त कार्यक्षमतेसाठी संबंधित सशुल्क सदस्यता आवश्यक असते, ज्यासाठी तुमच्याकडून संबंधित आर्थिक गुंतवणूक आवश्यक असते, ज्याची तुम्हाला आगाऊ योजना करणे आवश्यक असते.

Azure मध्ये अनेक अंगभूत धोक्याची देखरेख क्षमता आहे जी Azure AD, Azure Monitor आणि Azure सुरक्षा केंद्रामध्ये एकत्रित केली आहे. त्यापैकी, उदाहरणार्थ, ज्ञात दुर्भावनायुक्त आयपीसह आभासी मशीनच्या परस्परसंवादाचा शोध (मायक्रोसॉफ्टच्या थ्रेट इंटेलिजेंस सेवांसह एकत्रीकरणाच्या उपस्थितीमुळे), क्लाउडमध्ये होस्ट केलेल्या व्हर्च्युअल मशीनमधून अलार्म प्राप्त करून क्लाउड इन्फ्रास्ट्रक्चरमध्ये मालवेअर शोधणे, पासवर्ड व्हर्च्युअल मशीनवर अंदाज लावणे ”, वापरकर्ता ओळख प्रणालीच्या कॉन्फिगरेशनमधील असुरक्षा, अनामिक किंवा संक्रमित नोड्समधून सिस्टममध्ये लॉग इन करणे, खाते लीक होणे, असामान्य स्थानांवरून सिस्टममध्ये लॉग इन करणे इ. Azure आज काही क्लाउड प्रदात्यांपैकी एक आहे जे तुम्हाला संकलित माहिती सुरक्षा इव्हेंट्स समृद्ध करण्यासाठी अंगभूत थ्रेट इंटेलिजन्स क्षमता देते.

वर नमूद केल्याप्रमाणे, सुरक्षा कार्यक्षमता आणि परिणामी, त्याद्वारे व्युत्पन्न केलेले सुरक्षा इव्हेंट सर्व वापरकर्त्यांसाठी समान रीतीने उपलब्ध नसतात, परंतु आपल्याला आवश्यक असलेल्या कार्यक्षमतेचा समावेश असलेली विशिष्ट सदस्यता आवश्यक असते, जी माहिती सुरक्षा निरीक्षणासाठी योग्य इव्हेंट्स व्युत्पन्न करते. उदाहरणार्थ, खात्यांमधील विसंगतींचे निरीक्षण करण्यासाठी मागील परिच्छेदामध्ये वर्णन केलेली काही कार्ये केवळ Azure AD सेवेसाठी P2 प्रीमियम परवान्यामध्ये उपलब्ध आहेत. त्याशिवाय, तुम्हाला, AWS च्या बाबतीत, गोळा केलेल्या सुरक्षा घटनांचे "स्वतः" विश्लेषण करावे लागेल. आणि, तसेच, Azure AD परवान्याच्या प्रकारावर अवलंबून, सर्व इव्हेंट विश्लेषणासाठी उपलब्ध नसतील.

Azure पोर्टलवर, तुम्ही तुमच्या आवडीच्या नोंदींसाठी दोन्ही शोध क्वेरी व्यवस्थापित करू शकता आणि मुख्य माहिती सुरक्षा निर्देशकांची कल्पना करण्यासाठी डॅशबोर्ड सेट करू शकता. याव्यतिरिक्त, तेथे तुम्ही Azure Monitor विस्तार निवडू शकता, जे तुम्हाला Azure Monitor logs च्या कार्यक्षमतेचा विस्तार करण्यास आणि सुरक्षिततेच्या दृष्टिकोनातून इव्हेंटचे सखोल विश्लेषण मिळविण्यास अनुमती देतात.

जर तुम्हाला फक्त लॉगसह काम करण्याची क्षमताच नाही तर तुमच्या Azure क्लाउड प्लॅटफॉर्मसाठी माहिती सुरक्षा धोरण व्यवस्थापनासह सर्वसमावेशक सुरक्षा केंद्राची गरज असेल, तर तुम्ही Azure सुरक्षा केंद्रासोबत काम करण्याच्या गरजेबद्दल बोलू शकता, त्यातील बहुतांश उपयुक्त कार्ये काही पैशांसाठी उपलब्ध आहेत, उदाहरणार्थ, धोका शोधणे, Azure च्या बाहेर निरीक्षण करणे, अनुपालन मूल्यांकन इ. (विनामूल्य आवृत्तीमध्ये, तुम्हाला फक्त सुरक्षितता मूल्यांकन आणि ओळखल्या गेलेल्या समस्या दूर करण्यासाठी शिफारसींमध्ये प्रवेश आहे). हे सर्व सुरक्षा समस्या एकाच ठिकाणी एकत्रित करते. खरं तर, Azure मॉनिटर तुम्हाला पुरवित असलेल्या माहितीच्या सुरक्षिततेच्या उच्च पातळीबद्दल आम्ही बोलू शकतो, कारण या प्रकरणात तुमच्या क्लाउड फॅक्टरीमध्ये गोळा केलेला डेटा Azure, Office 365, Microsoft CRM ऑनलाइन, Microsoft Dynamics AX यासारख्या अनेक स्त्रोतांचा वापर करून समृद्ध केला जातो. , outlook .com, MSN.com, Microsoft Digital Crimes Unit (DCU) आणि मायक्रोसॉफ्ट सिक्युरिटी रिस्पॉन्स सेंटर (MSRC), ज्यावर विविध अत्याधुनिक मशीन लर्निंग आणि वर्तणुकीशी संबंधित विश्लेषणे अल्गोरिदम लागू केले आहेत, ज्याने शेवटी धमक्या शोधण्याची आणि त्यांना प्रतिसाद देण्याची कार्यक्षमता सुधारली पाहिजे. .

Azure चे स्वतःचे SIEM देखील आहे - ते 2019 च्या सुरूवातीस दिसू लागले. हे Azure Sentinel आहे, जे Azure Monitor कडील डेटावर अवलंबून आहे आणि ते समाकलित देखील करू शकते. बाह्य सुरक्षा उपाय (उदाहरणार्थ, NGFW किंवा WAF), ज्याची यादी सतत वाढत आहे. याव्यतिरिक्त, मायक्रोसॉफ्ट ग्राफ सिक्युरिटी एपीआयच्या एकत्रीकरणाद्वारे, तुमच्याकडे तुमच्या स्वतःच्या थ्रेट इंटेलिजन्स फीडला सेंटिनेलशी कनेक्ट करण्याची क्षमता आहे, जी तुमच्या Azure क्लाउडमधील घटनांचे विश्लेषण करण्याची क्षमता समृद्ध करते. असा युक्तिवाद केला जाऊ शकतो की Azure Sentinel हा क्लाउड प्रदात्यांकडून दिसलेला पहिला "नेटिव्ह" SIEM आहे (समान स्प्लंक किंवा ELK, जे क्लाउडमध्ये होस्ट केले जाऊ शकतात, उदाहरणार्थ, AWS, अजूनही पारंपारिक क्लाउड सेवा प्रदात्यांनी विकसित केलेले नाहीत). Azure सेंटिनेल आणि सिक्युरिटी सेंटरला Azure क्लाउडसाठी SOC म्हटले जाऊ शकते आणि जर तुमच्याकडे यापुढे कोणतीही पायाभूत सुविधा नसेल आणि तुम्ही तुमची सर्व संगणकीय संसाधने क्लाउडमध्ये हस्तांतरित केली असतील आणि ते मायक्रोसॉफ्ट क्लाउड Azure असेल तर त्यांच्यापुरते मर्यादित असू शकते (विशिष्ट आरक्षणांसह).

परंतु Azure ची अंगभूत क्षमता (जरी तुमच्याकडे सेंटिनेलची सदस्यता असली तरीही) माहिती सुरक्षिततेचे निरीक्षण करण्यासाठी आणि ही प्रक्रिया इतर सुरक्षा कार्यक्रमांच्या (क्लाउड आणि अंतर्गत दोन्ही) स्त्रोतांसह एकत्रित करण्याच्या हेतूंसाठी पुरेशी नसते. गोळा केलेला डेटा बाह्य प्रणालींवर निर्यात करणे आवश्यक आहे, ज्यामध्ये SIEM समाविष्ट असू शकते. हे API वापरून आणि विशेष विस्तार वापरून केले जाते, जे सध्या अधिकृतपणे खालील SIEMs साठी उपलब्ध आहेत - Splunk (Azure Monitor Add-on for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight आणि ELK. अलीकडे पर्यंत, असे आणखी SIEM होते, परंतु 1 जून, 2019 पासून, मायक्रोसॉफ्टने Azure लॉग इंटिग्रेशन टूल (AzLog) ला समर्थन देणे बंद केले, जे Azure च्या अस्तित्वाच्या प्रारंभी आणि लॉगसह कार्य करण्याचे सामान्य मानकीकरण नसतानाही (Azure) मॉनिटरने अद्याप अस्तित्वात नव्हते) मायक्रोसॉफ्ट क्लाउडसह बाह्य SIEM समाकलित करणे सोपे केले. आता परिस्थिती बदलली आहे आणि मायक्रोसॉफ्ट इतर SIEM साठी मुख्य एकत्रीकरण साधन म्हणून Azure इव्हेंट हब प्लॅटफॉर्मची शिफारस करते. अनेकांनी आधीच असे एकत्रीकरण लागू केले आहे, परंतु सावधगिरी बाळगा - ते सर्व Azure लॉग कॅप्चर करू शकत नाहीत, परंतु फक्त काही (तुमच्या SIEM साठी दस्तऐवजीकरण पहा).

Azure मध्ये एक संक्षिप्त सहल संपवताना, मी या क्लाउड सेवेबद्दल एक सामान्य शिफारस देऊ इच्छितो - तुम्ही Azure मधील माहिती सुरक्षा निरीक्षण कार्यांबद्दल काहीही बोलण्यापूर्वी, तुम्ही ते अतिशय काळजीपूर्वक कॉन्फिगर केले पाहिजे आणि ते कागदपत्रांमध्ये लिहिलेल्याप्रमाणे कार्य करतात याची चाचणी घ्यावी आणि जसे सल्लागारांनी तुम्हाला Microsoft सांगितले (आणि Azure फंक्शन्सच्या कार्यक्षमतेबद्दल त्यांची मते भिन्न असू शकतात). तुमच्याकडे आर्थिक संसाधने असल्यास, तुम्ही माहिती सुरक्षा निरीक्षणाच्या दृष्टीने Azure कडून बरीच उपयुक्त माहिती पिळून काढू शकता. जर तुमची संसाधने मर्यादित असतील, तर, AWS च्या बाबतीत, तुम्हाला फक्त तुमच्या स्वतःच्या ताकदीवर आणि Azure Monitor ने तुम्हाला पुरवलेल्या कच्च्या डेटावर अवलंबून राहावे लागेल. आणि लक्षात ठेवा की बर्‍याच मॉनिटरिंग फंक्शन्ससाठी पैसे खर्च होतात आणि किंमत धोरणाशी आधीच परिचित होणे चांगले. उदाहरणार्थ, तुम्ही प्रति ग्राहक कमाल 31 GB पर्यंत 5 दिवसांचा डेटा विनामूल्य संचयित करू शकता - ही मूल्ये ओलांडल्यास तुम्हाला अतिरिक्त पैसे (ग्राहकाकडून प्रत्येक अतिरिक्त GB संचयित करण्यासाठी अंदाजे $2+ आणि त्यासाठी $0,1) द्यावे लागतील प्रत्येक अतिरिक्त महिन्याला 1 GB संचयित करणे). अॅप्लिकेशन टेलीमेट्री आणि मेट्रिक्ससह कार्य करण्यासाठी अतिरिक्त निधीची आवश्यकता असू शकते, तसेच अलर्ट आणि सूचनांसह कार्य करणे (एक विशिष्ट मर्यादा विनामूल्य उपलब्ध आहे, जी कदाचित आपल्या गरजांसाठी पुरेशी नसेल).

उदाहरण: Google क्लाउड प्लॅटफॉर्मवर आधारित IaaS मध्ये माहिती सुरक्षा निरीक्षण

Google क्लाउड प्लॅटफॉर्म AWS आणि Azure च्या तुलनेत तरुणांसारखे दिसते, परंतु हे अंशतः चांगले आहे. AWS च्या विपरीत, ज्याने सुरक्षेसह त्याची क्षमता वाढवली, हळूहळू, केंद्रीकरणात समस्या येत आहेत; GCP, Azure प्रमाणे, मध्यवर्ती पद्धतीने अधिक चांगले व्यवस्थापित केले जाते, जे संपूर्ण एंटरप्राइझमध्ये त्रुटी आणि अंमलबजावणी वेळ कमी करते. सुरक्षिततेच्या दृष्टिकोनातून, AWS आणि Azure दरम्यान GCP, विचित्रपणे पुरेसे आहे. त्याच्याकडे संपूर्ण संस्थेसाठी एकच कार्यक्रम नोंदणी आहे, परंतु ती अपूर्ण आहे. काही फंक्शन्स अजूनही बीटा मोडमध्ये आहेत, परंतु हळूहळू ही कमतरता दूर केली पाहिजे आणि माहिती सुरक्षा निरीक्षणाच्या दृष्टीने GCP अधिक परिपक्व व्यासपीठ बनेल.

GCP मध्‍ये इव्‍हेंट लॉगिंग करण्‍याचे मुख्‍य साधन स्‍टॅकड्रायव्हर लॉगिंग आहे (अ‍ॅझ्युर मॉनिटर सारखे), जे तुम्हाला तुमच्या संपूर्ण क्लाउड इन्फ्रास्ट्रक्चरवर (तसेच AWS वरून) इव्हेंट संकलित करू देते. GCP मधील सुरक्षिततेच्या दृष्टीकोनातून, प्रत्येक संस्था, प्रकल्प किंवा फोल्डरमध्ये चार लॉग असतात:

• प्रशासकीय क्रियाकलाप - प्रशासकीय प्रवेशाशी संबंधित सर्व इव्हेंट समाविष्ट करतात, उदाहरणार्थ, आभासी मशीन तयार करणे, प्रवेश अधिकार बदलणे इ. हा लॉग नेहमी आपल्या इच्छेकडे दुर्लक्ष करून लिहिला जातो आणि त्याचा डेटा 400 दिवसांसाठी संग्रहित करतो.
• डेटा ऍक्सेस - क्लाउड वापरकर्त्यांद्वारे डेटासह कार्य करण्याशी संबंधित सर्व इव्हेंट समाविष्ट आहेत (निर्मिती, बदल, वाचन इ.). डीफॉल्टनुसार, हा लॉग लिहिला जात नाही, कारण त्याची मात्रा खूप लवकर फुगते. या कारणास्तव, त्याचे शेल्फ लाइफ फक्त 30 दिवस आहे. याव्यतिरिक्त, या मासिकात सर्वकाही लिहिलेले नाही. उदाहरणार्थ, सर्व वापरकर्त्यांसाठी सार्वजनिकरित्या प्रवेश करण्यायोग्य किंवा GCP मध्ये लॉग इन न करता प्रवेश करण्यायोग्य असलेल्या संसाधनांशी संबंधित इव्हेंट त्यावर लिहिलेले नाहीत.
• सिस्टम इव्हेंट - वापरकर्त्यांशी संबंधित नसलेले सिस्टम इव्हेंट किंवा क्लाउड संसाधनांचे कॉन्फिगरेशन बदलणार्‍या प्रशासकाच्या कृती असतात. हे नेहमी 400 दिवस लिहिले आणि संग्रहित केले जाते.
• प्रवेश पारदर्शकता हे लॉगचे एक अद्वितीय उदाहरण आहे जे Google कर्मचार्‍यांच्या सर्व क्रिया कॅप्चर करते (परंतु अद्याप सर्व GCP सेवांसाठी नाही) जे त्यांच्या नोकरीच्या कर्तव्याचा भाग म्हणून तुमच्या पायाभूत सुविधांमध्ये प्रवेश करतात. हा लॉग 400 दिवसांसाठी संग्रहित केला जातो आणि प्रत्येक GCP क्लायंटसाठी उपलब्ध नाही, परंतु केवळ अनेक अटी पूर्ण केल्या गेल्या असल्यास (एकतर गोल्ड किंवा प्लॅटिनम स्तर समर्थन, किंवा कॉर्पोरेट समर्थनाचा भाग म्हणून विशिष्ट प्रकारच्या 4 भूमिकांची उपस्थिती). एक समान कार्य देखील उपलब्ध आहे, उदाहरणार्थ, ऑफिस 365 - लॉकबॉक्समध्ये.

लॉग उदाहरण: प्रवेश पारदर्शकता

{
 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"
}

लॉग व्ह्यूअर इंटरफेसद्वारे, API द्वारे, Google क्लाउड SDK द्वारे, किंवा तुमच्या प्रकल्पाच्या क्रियाकलाप पृष्ठाद्वारे, ज्यासाठी तुम्ही कार्यक्रमांमध्ये स्वारस्य आहे. त्याच प्रकारे, ते अतिरिक्त विश्लेषणासाठी बाह्य समाधानांमध्ये निर्यात केले जाऊ शकतात. बिगक्वेरी किंवा क्लाउड पब/सब स्टोरेजमध्ये लॉग एक्सपोर्ट करून नंतरचे केले जाते.

स्टॅकड्रिव्हर लॉगिंग व्यतिरिक्त, GCP प्लॅटफॉर्म स्टॅकड्रिव्हर मॉनिटरिंग कार्यक्षमता देखील ऑफर करते, जे तुम्हाला क्लाउड सेवा आणि ऍप्लिकेशन्सच्या मुख्य मेट्रिक्स (कार्यप्रदर्शन, MTBF, एकूण आरोग्य इ.) निरीक्षण करण्यास अनुमती देते. प्रक्रिया केलेला आणि व्हिज्युअलाइज्ड डेटा तुमच्या क्लाउड इन्फ्रास्ट्रक्चरमध्ये सुरक्षिततेच्या संदर्भात समस्या शोधणे सोपे करू शकतो. परंतु हे लक्षात घेतले पाहिजे की माहिती सुरक्षिततेच्या संदर्भात ही कार्यक्षमता फारशी समृद्ध होणार नाही, कारण आज GCP कडे समान AWS GuardDuty चे एनालॉग नाही आणि सर्व नोंदणीकृत इव्हेंटमधील वाईट ओळखू शकत नाही (Google ने इव्हेंट थ्रेट डिटेक्शन विकसित केले आहे, परंतु ते अद्याप बीटामध्ये विकसित होत आहे आणि त्याच्या उपयुक्ततेबद्दल बोलणे खूप लवकर आहे). स्टॅकड्रिव्हर मॉनिटरिंगचा वापर विसंगती शोधण्यासाठी एक प्रणाली म्हणून केला जाऊ शकतो, ज्याचा नंतर त्यांच्या घटनेची कारणे शोधण्यासाठी तपास केला जाईल. परंतु बाजारपेठेतील GCP माहिती सुरक्षिततेच्या क्षेत्रात पात्र असलेल्या कर्मचा-यांची कमतरता लक्षात घेता, हे कार्य सध्या कठीण दिसते.

तुमच्या GCP क्लाउडमध्ये वापरल्या जाऊ शकणार्‍या काही माहिती सुरक्षा मॉड्यूलची यादी देणे देखील योग्य आहे आणि जे AWS ऑफर करते त्यासारखे आहे:

• क्लाउड सिक्युरिटी कमांड सेंटर हे AWS सिक्युरिटी हब आणि अझर सिक्युरिटी सेंटरचे अॅनालॉग आहे.
• क्लाउड DLP - 90 पेक्षा जास्त पूर्वनिर्धारित वर्गीकरण धोरणे वापरून क्लाउडमध्ये होस्ट केलेल्या डेटाचा स्वयंचलित शोध आणि संपादन (उदा. मास्किंग).
• क्लाउड स्कॅनर हे ऍप इंजिन, कॉम्प्युट इंजिन आणि गुगल कुबर्नेट्स मधील ज्ञात भेद्यता (XSS, फ्लॅश इंजेक्शन, अनपॅच्ड लायब्ररी इ.) साठी स्कॅनर आहे.
• क्लाउड IAM - सर्व GCP संसाधनांवर प्रवेश नियंत्रित करा.
• क्लाउड आयडेंटिटी - एकाच कन्सोलवरून GCP वापरकर्ता, डिव्हाइस आणि अॅप्लिकेशन खाती व्यवस्थापित करा.
• क्लाउड एचएसएम - क्रिप्टोग्राफिक कीचे संरक्षण.
• क्लाउड की व्यवस्थापन सेवा - GCP मधील क्रिप्टोग्राफिक की चे व्यवस्थापन.
• VPC सेवा नियंत्रण - तुमच्या GCP संसाधनांचे गळतीपासून संरक्षण करण्यासाठी त्यांच्याभोवती एक सुरक्षित परिमिती तयार करा.
• टायटन सुरक्षा की - फिशिंगपासून संरक्षण.

यापैकी बरेच मॉड्यूल सुरक्षा इव्हेंट तयार करतात जे विश्लेषणासाठी किंवा SIEM सह इतर सिस्टमवर निर्यात करण्यासाठी BigQuery स्टोरेजमध्ये पाठवले जाऊ शकतात. वर नमूद केल्याप्रमाणे, GCP हे सक्रियपणे विकसित होणारे व्यासपीठ आहे आणि Google आता त्याच्या प्लॅटफॉर्मसाठी अनेक नवीन माहिती सुरक्षा मॉड्यूल विकसित करत आहे. त्यापैकी इव्हेंट थ्रेट डिटेक्शन (आता बीटामध्ये उपलब्ध आहे), जे अनधिकृत क्रियाकलापांच्या ट्रेसच्या शोधात स्टॅक ड्रायव्हर लॉग स्कॅन करते (AWS मधील GuardDuty प्रमाणे), किंवा पॉलिसी इंटेलिजन्स (अल्फामध्ये उपलब्ध), जे तुम्हाला यासाठी बुद्धिमान धोरणे विकसित करण्यास अनुमती देईल. GCP संसाधनांमध्ये प्रवेश.

मी लोकप्रिय क्लाउड प्लॅटफॉर्ममधील अंगभूत निरीक्षण क्षमतांचे एक संक्षिप्त विहंगावलोकन केले. परंतु तुमच्याकडे असे विशेषज्ञ आहेत का जे "रॉ" IaaS प्रदाता लॉगसह कार्य करण्यास सक्षम आहेत (प्रत्येकजण AWS किंवा Azure किंवा Google च्या प्रगत क्षमता खरेदी करण्यास तयार नाही)? याव्यतिरिक्त, "विश्वास ठेवा, परंतु सत्यापित करा" या उक्तीशी अनेकजण परिचित आहेत, जे सुरक्षिततेच्या क्षेत्रात नेहमीपेक्षा सत्य आहे. तुम्हाला माहिती सुरक्षा इव्हेंट पाठवणाऱ्या क्लाउड प्रदात्याच्या अंगभूत क्षमतांवर तुमचा किती विश्वास आहे? ते माहितीच्या सुरक्षिततेवर किती लक्ष केंद्रित करतात?

काहीवेळा हे ओव्हरले क्लाउड इन्फ्रास्ट्रक्चर मॉनिटरिंग सोल्यूशन्स पाहण्यासारखे आहे जे बिल्ट-इन क्लाउड सुरक्षेला पूरक ठरू शकते आणि काहीवेळा असे उपाय क्लाउडमध्ये होस्ट केलेल्या तुमच्या डेटा आणि ऍप्लिकेशन्सच्या सुरक्षिततेबद्दल अंतर्दृष्टी मिळविण्यासाठी एकमेव पर्याय आहेत. याव्यतिरिक्त, ते अधिक सोयीस्कर आहेत, कारण ते वेगवेगळ्या क्लाउड प्रदात्यांकडून वेगवेगळ्या क्लाउड सेवांद्वारे व्युत्पन्न केलेल्या आवश्यक लॉगचे विश्लेषण करण्याची सर्व कार्ये घेतात. अशा आच्छादन समाधानाचे उदाहरण म्हणजे Cisco Stealthwatch Cloud, जे एकाच कार्यावर केंद्रित आहे - क्लाउड वातावरणातील माहिती सुरक्षा विसंगतींचे निरीक्षण करणे, ज्यामध्ये Amazon AWS, Microsoft Azure आणि Google क्लाउड प्लॅटफॉर्मच नाही तर खाजगी क्लाउड देखील समाविष्ट आहेत.

उदाहरण: Stealthwatch क्लाउड वापरून माहिती सुरक्षा निरीक्षण

AWS एक लवचिक संगणन प्लॅटफॉर्म प्रदान करते, परंतु ही लवचिकता कंपन्यांना सुरक्षेच्या समस्या निर्माण करणाऱ्या चुका करणे सोपे करते. आणि सामायिक माहिती सुरक्षा मॉडेल केवळ यात योगदान देते. अज्ञात भेद्यतेसह क्लाउडमध्ये सॉफ्टवेअर चालवणे (ज्ञात असलेल्यांचा सामना केला जाऊ शकतो, उदाहरणार्थ, AWS इन्स्पेक्टर किंवा GCP क्लाउड स्कॅनर), कमकुवत पासवर्ड, चुकीची कॉन्फिगरेशन, इनसाइडर इ. आणि हे सर्व क्लाउड संसाधनांच्या वर्तनात प्रतिबिंबित होते, ज्याचे परीक्षण सिस्को स्टील्थवॉच क्लाउडद्वारे केले जाऊ शकते, जी एक माहिती सुरक्षा निरीक्षण आणि आक्रमण शोध प्रणाली आहे. सार्वजनिक आणि खाजगी ढग.

सिस्को स्टील्थवॉच क्लाउडच्या प्रमुख वैशिष्ट्यांपैकी एक म्हणजे घटक मॉडेल करण्याची क्षमता. त्यासह, तुम्ही तुमच्या प्रत्येक क्लाउड संसाधनाचे सॉफ्टवेअर मॉडेल (म्हणजेच जवळचे-रिअल-टाइम सिम्युलेशन) तयार करू शकता (ते AWS, Azure, GCP किंवा दुसरे काहीतरी आहे की नाही हे महत्त्वाचे नाही). यामध्ये सर्व्हर आणि वापरकर्ते, तसेच तुमच्या क्लाउड वातावरणाशी संबंधित संसाधन प्रकार, जसे की सुरक्षा गट आणि स्वयं-स्केल गट यांचा समावेश असू शकतो. हे मॉडेल क्लाउड सेवांद्वारे प्रदान केलेले संरचित डेटा प्रवाह इनपुट म्हणून वापरतात. उदाहरणार्थ, AWS साठी हे VPC फ्लो लॉग, AWS CloudTrail, AWS CloudWatch, AWS कॉन्फिग, AWS Inspector, AWS Lambda आणि AWS IAM असतील. एंटिटी मॉडेलिंग आपोआप आपल्या कोणत्याही संसाधनांची भूमिका आणि वर्तन शोधते (आपण सर्व क्लाउड क्रियाकलाप प्रोफाइल करण्याबद्दल बोलू शकता). या भूमिकांमध्ये Android किंवा Apple मोबाईल डिव्हाइस, Citrix PVS सर्व्हर, RDP सर्व्हर, मेल गेटवे, VoIP क्लायंट, टर्मिनल सर्व्हर, डोमेन कंट्रोलर इ. त्यानंतर धोकादायक किंवा सुरक्षिततेसाठी धोकादायक वर्तन केव्हा घडते हे निर्धारित करण्यासाठी ते त्यांच्या वर्तनाचे सतत निरीक्षण करते. तुम्ही पासवर्ड अंदाज, DDoS हल्ले, डेटा लीक, बेकायदेशीर रिमोट ऍक्सेस, दुर्भावनापूर्ण कोड क्रियाकलाप, भेद्यता स्कॅनिंग आणि इतर धोके ओळखू शकता. उदाहरणार्थ, तुमच्या संस्थेसाठी (दक्षिण कोरिया) एखाद्या देशाकडून SSH द्वारे Kubernetes क्लस्टरमध्ये रिमोट ऍक्सेस प्रयत्न शोधणे असे दिसते:

आणि पोस्टग्रेस डेटाबेसमधून ज्या देशाशी आम्ही यापूर्वी परस्परसंवादाचा सामना केला नाही अशा देशामध्ये माहितीची कथित गळती हे असे दिसते:

शेवटी, बाह्य रिमोट डिव्हाइसवरून चीन आणि इंडोनेशियामधील अनेक अयशस्वी SSH प्रयत्न असे दिसतात:

किंवा, असे समजा की VPC मधील सर्व्हर उदाहरण, धोरणानुसार, कधीही दूरस्थ लॉगिन गंतव्यस्थान नसावे. चला पुढे असे गृहीत धरू की फायरवॉल नियम धोरणातील चुकीच्या बदलामुळे या संगणकाला रिमोट लॉगऑनचा अनुभव आला. एंटिटी मॉडेलिंग वैशिष्ट्य ही क्रियाकलाप (“असामान्य रिमोट ऍक्सेस”) जवळच्या रिअल-टाइममध्ये शोधून अहवाल देईल आणि विशिष्ट AWS CloudTrail, Azure Monitor, किंवा GCP Stackdriver Logging API कॉल (वापरकर्ता नाव, तारीख आणि वेळ यासह, इतर तपशीलांसह) दर्शवेल. ) ज्याने ITU नियमात बदल करण्यास प्रवृत्त केले. आणि नंतर ही माहिती विश्लेषणासाठी SIEM कडे पाठविली जाऊ शकते.

सिस्को स्टील्थवॉच क्लाउडद्वारे समर्थित कोणत्याही क्लाउड वातावरणासाठी तत्सम क्षमता लागू केल्या जातात:

एंटिटी मॉडेलिंग हे सुरक्षितता ऑटोमेशनचा एक अनोखा प्रकार आहे जो तुमचे लोक, प्रक्रिया किंवा तंत्रज्ञानासह पूर्वी अज्ञात समस्या उघड करू शकतो. उदाहरणार्थ, ते तुम्हाला इतर गोष्टींबरोबरच, सुरक्षा समस्या शोधण्याची परवानगी देते जसे की:

• आम्ही वापरत असलेल्या सॉफ्टवेअरमध्ये कोणीतरी मागील दरवाजा शोधला आहे का?
• आमच्या क्लाउडमध्ये कोणतेही तृतीय पक्ष सॉफ्टवेअर किंवा डिव्हाइस आहे का?
• अधिकृत वापरकर्ता विशेषाधिकारांचा गैरवापर करत आहे का?
• रिमोट ऍक्सेस किंवा संसाधनांच्या इतर अनपेक्षित वापरास अनुमती देणारी कॉन्फिगरेशन त्रुटी होती का?
• आमच्या सर्व्हरमधून डेटा लीक झाला आहे का?
• कोणीतरी अ‍ॅटिपिकल भौगोलिक स्थानावरून आमच्याशी कनेक्ट होण्याचा प्रयत्न करत आहे का?
• आमच्या क्लाउडला दुर्भावनापूर्ण कोडचा संसर्ग झाला आहे का?

सापडलेली माहिती सुरक्षा इव्हेंट स्लॅक, सिस्को स्पार्क, पेजरड्युटी घटना व्यवस्थापन प्रणालीला संबंधित तिकिटाच्या स्वरूपात पाठविली जाऊ शकते आणि स्प्लंक किंवा ELK सह विविध SIEM ला देखील पाठविली जाऊ शकते. थोडक्यात, आम्ही असे म्हणू शकतो की जर तुमची कंपनी मल्टी-क्लाउड स्ट्रॅटेजी वापरत असेल आणि ती कोणत्याही एका क्लाउड प्रदात्यापुरती मर्यादित नसेल, वर वर्णन केलेल्या माहिती सुरक्षा मॉनिटरिंग क्षमता, तर सिस्को स्टील्थवॉच क्लाउड वापरणे हा एक एकत्रित मॉनिटरिंग सेट मिळविण्यासाठी चांगला पर्याय आहे. आघाडीच्या क्लाउड प्लेयर्ससाठी क्षमता - Amazon, Microsoft आणि Google. सर्वात मनोरंजक गोष्ट अशी आहे की जर तुम्ही AWS, Azure किंवा GCP मधील माहिती सुरक्षा मॉनिटरिंगसाठी प्रगत परवान्यांसह स्टील्थवॉच क्लाउडच्या किंमतींची तुलना केली तर असे दिसून येईल की सिस्को सोल्यूशन अॅमेझॉन, मायक्रोसॉफ्टच्या अंगभूत क्षमतेपेक्षा अगदी स्वस्त असेल. आणि Google उपाय. हे विरोधाभासी आहे, परंतु ते खरे आहे. आणि तुम्ही जितके अधिक ढग आणि त्यांची क्षमता वापरता तितके एकत्रित समाधानाचा फायदा अधिक स्पष्ट होईल.

याव्यतिरिक्त, स्टील्थवॉच क्लाउड तुमच्या संस्थेमध्ये तैनात केलेल्या खाजगी क्लाउडचे परीक्षण करू शकते, उदाहरणार्थ, कुबर्नेट्स कंटेनरवर आधारित किंवा नेटवर्क उपकरणांमध्ये मिररिंगद्वारे प्राप्त नेटफ्लो प्रवाह किंवा नेटवर्क ट्रॅफिकचे निरीक्षण करून (अगदी देशांतर्गत उत्पादित), AD डेटा किंवा DNS सर्व्हर इत्यादी. हा सर्व डेटा सायबरसुरक्षा धमकी संशोधकांचा जगातील सर्वात मोठा गैर-सरकारी गट सिस्को टॅलोस यांनी गोळा केलेल्या थ्रेट इंटेलिजेंस माहितीसह समृद्ध केला जाईल.

हे तुम्हाला सार्वजनिक आणि हायब्रिड दोन्ही क्लाउडसाठी युनिफाइड मॉनिटरिंग सिस्टम लागू करण्याची परवानगी देते जे तुमची कंपनी वापरू शकते. गोळा केलेल्या माहितीचे नंतर स्टील्थवॉच क्लाउडच्या अंगभूत क्षमतांचा वापर करून विश्लेषण केले जाऊ शकते किंवा आपल्या SIEM वर पाठविले जाऊ शकते (स्प्लंक, ELK, SumoLogic आणि इतर अनेक डीफॉल्टनुसार समर्थित आहेत).

यासह, आम्ही लेखाचा पहिला भाग पूर्ण करू, ज्यामध्ये मी IaaS/PaaS प्लॅटफॉर्मच्या माहिती सुरक्षिततेचे परीक्षण करण्यासाठी अंगभूत आणि बाह्य साधनांचे पुनरावलोकन केले आहे, जे आम्हाला क्लाउड वातावरणात घडणाऱ्या घटनांचा त्वरीत शोध घेण्यास आणि त्यांना प्रतिसाद देण्यास अनुमती देतात. आमच्या एंटरप्राइझने निवडले आहे. दुसऱ्या भागात, आम्ही विषय सुरू ठेवू आणि Salesforce आणि Dropbox चे उदाहरण वापरून SaaS प्लॅटफॉर्मचे निरीक्षण करण्यासाठी पर्याय पाहू, आणि आम्ही वेगवेगळ्या क्लाउड प्रदात्यांसाठी एकत्रित माहिती सुरक्षा मॉनिटरिंग सिस्टम तयार करून सर्व गोष्टींचा सारांश देण्याचा आणि एकत्र ठेवण्याचा प्रयत्न करू.

स्त्रोत: www.habr.com