MCS क्लाउड प्लॅटफॉर्म सुरक्षा ऑडिट

स्कायशिप संध्याकाळ सीरलाइट द्वारे

कोणतीही सेवा तयार करताना सुरक्षिततेवर सतत काम करणे आवश्यक असते. सुरक्षा ही एक सतत प्रक्रिया आहे ज्यामध्ये उत्पादनाच्या सुरक्षिततेचे सतत विश्लेषण आणि सुधारणा, असुरक्षिततेबद्दल बातम्यांचे निरीक्षण करणे आणि बरेच काही समाविष्ट असते. ऑडिटसह. ऑडिट इन-हाउस आणि बाह्य तज्ञांद्वारे केले जातात, जे सुरक्षिततेसाठी मूलभूतपणे मदत करू शकतात कारण ते प्रकल्पात बुडलेले नाहीत आणि त्यांचे मन मोकळे आहे.

लेख बाह्य तज्ञांच्या या सर्वात सरळ दृष्टिकोनाबद्दल आहे ज्यांनी Mail.ru क्लाउड सोल्युशन्स (MCS) टीमला क्लाउड सेवेची चाचणी घेण्यात मदत केली आणि त्यांना काय आढळले याबद्दल आहे. "बाह्य शक्ती" म्हणून MCS ने डिजिटल सिक्युरिटी कंपनीची निवड केली, जी माहिती सुरक्षा वर्तुळातील उच्च कौशल्यासाठी ओळखली जाते. आणि या लेखात आम्ही बाह्य ऑडिटचा भाग म्हणून आढळलेल्या काही मनोरंजक भेद्यतेचे विश्लेषण करू - जेणेकरुन तुम्ही तुमची स्वतःची क्लाउड सेवा तयार करता तेव्हा समान रेक टाळता.

ही उत्क्रांती उतारे

Mail.ru क्लाउड सोल्यूशन्स (MCS) क्लाउडमध्ये आभासी पायाभूत सुविधा निर्माण करण्यासाठी एक व्यासपीठ आहे. यामध्ये IaaS, PaaS आणि डेव्हलपरसाठी रेडीमेड अॅप्लिकेशन इमेजचे मार्केटप्लेस समाविष्ट आहे. MCS आर्किटेक्चर लक्षात घेऊन, खालील भागात उत्पादनाची सुरक्षितता तपासणे आवश्यक होते:

• व्हर्च्युअलायझेशन वातावरणाच्या पायाभूत सुविधांचे संरक्षण करणे: हायपरवाइजर, राउटिंग, फायरवॉल;
• ग्राहकांच्या आभासी पायाभूत सुविधांचे संरक्षण: SDN मधील नेटवर्क, खाजगी नेटवर्कसह एकमेकांपासून अलगाव;
• ओपनस्टॅक आणि त्याचे खुले घटक;
• आमच्या स्वत: च्या डिझाइनचे S3;
• IAM: रोल मॉडेलसह बहु-भाडेकरू प्रकल्प;
• दृष्टी (संगणक दृष्टी): प्रतिमांसह कार्य करताना API आणि भेद्यता;
• वेब इंटरफेस आणि क्लासिक वेब हल्ले;
• PaaS घटकांची भेद्यता;
• सर्व घटकांचे API.

कदाचित पुढील इतिहासासाठी हेच आवश्यक आहे.

कोणत्या प्रकारचे काम केले गेले आणि त्याची आवश्यकता का होती?

सुरक्षा ऑडिटचा उद्देश भेद्यता आणि कॉन्फिगरेशन त्रुटी ओळखणे आहे ज्यामुळे वैयक्तिक डेटा लीक होऊ शकतो, संवेदनशील माहितीमध्ये बदल होऊ शकतो किंवा सेवा उपलब्धतेमध्ये व्यत्यय येऊ शकतो.

कामाच्या दरम्यान, जे सरासरी 1-2 महिने टिकते, ऑडिटर संभाव्य हल्लेखोरांच्या कृतींची पुनरावृत्ती करतात आणि निवडलेल्या सेवेच्या क्लायंट आणि सर्व्हर भागांमध्ये भेद्यता शोधतात. MCS क्लाउड प्लॅटफॉर्मच्या ऑडिटच्या संदर्भात, खालील उद्दिष्टे ओळखली गेली:

1. सेवेतील प्रमाणीकरणाचे विश्लेषण. या घटकातील भेद्यता इतर लोकांच्या खात्यांमध्ये त्वरित प्रवेश करण्यास मदत करेल.
2. वेगवेगळ्या खात्यांमधील रोल मॉडेल आणि ऍक्सेस कंट्रोलचा अभ्यास करणे. आक्रमणकर्त्यासाठी, दुसर्‍याच्या व्हर्च्युअल मशीनमध्ये प्रवेश मिळवण्याची क्षमता हे एक इष्ट ध्येय आहे.
3. क्लायंट साइड भेद्यता. XSS/CSRF/CRLF/इ. दुर्भावनायुक्त लिंक्सद्वारे इतर वापरकर्त्यांवर हल्ला करणे शक्य आहे का?
4. सर्व्हर साइड भेद्यता: RCE आणि सर्व प्रकारचे इंजेक्शन (SQL/XXE/SSRF आणि असेच). सर्व्हर असुरक्षा शोधणे सामान्यतः अधिक कठीण असते, परंतु ते एकाच वेळी अनेक वापरकर्त्यांना तडजोड करतात.
5. नेटवर्क स्तरावर वापरकर्ता विभाग अलगावचे विश्लेषण. आक्रमणकर्त्यासाठी, अलगावची कमतरता इतर वापरकर्त्यांविरूद्ध आक्रमण पृष्ठभाग मोठ्या प्रमाणात वाढवते.
6. व्यवसाय तर्कशास्त्र विश्लेषण. व्यवसायांना फसवणे आणि व्हर्च्युअल मशीन विनामूल्य तयार करणे शक्य आहे का?

या प्रकल्पात, "ग्रे-बॉक्स" मॉडेलनुसार कार्य केले गेले: ऑडिटर्सने सामान्य वापरकर्त्यांच्या विशेषाधिकारांसह सेवेशी संवाद साधला, परंतु त्यांच्याकडे API चा स्त्रोत कोड अंशतः होता आणि विकासकांसोबत तपशील स्पष्ट करण्याची संधी होती. हे सहसा सर्वात सोयीस्कर असते आणि त्याच वेळी कामाचे अगदी वास्तववादी मॉडेल: अंतर्गत माहिती अद्याप आक्रमणकर्त्याद्वारे संकलित केली जाऊ शकते, ही फक्त वेळेची बाब आहे.

असुरक्षा आढळल्या

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

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

IDOR

आयडीओआर (असुरक्षित डायरेक्ट ऑब्जेक्ट रेफरन्स) भेद्यता ही व्यवसाय तर्कशास्त्रातील सर्वात सामान्य असुरक्षा आहे, जी एक किंवा दुसर्‍याला अशा वस्तूंमध्ये प्रवेश मिळवू देते ज्यांना प्रत्यक्षात प्रवेश करण्याची परवानगी नाही. आयडीओआर असुरक्षा वेगवेगळ्या प्रमाणात गंभीरतेच्या वापरकर्त्याबद्दल माहिती मिळवण्याची शक्यता निर्माण करतात.

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

MCS च्या बाबतीत, ऑडिटर्सना नुकतीच असुरक्षित अभिज्ञापकांशी संबंधित IDOR भेद्यता आढळली. वापरकर्त्याच्या वैयक्तिक खात्यामध्ये, UUID अभिज्ञापक कोणत्याही वस्तूंमध्ये प्रवेश करण्यासाठी वापरले गेले, जे सुरक्षा तज्ञांच्या म्हणण्याप्रमाणे, प्रभावीपणे असुरक्षित (म्हणजे, क्रूर फोर्स हल्ल्यांपासून संरक्षित) वाटले. परंतु काही विशिष्ट घटकांसाठी, असे आढळून आले की ऍप्लिकेशनच्या वापरकर्त्यांबद्दल माहिती मिळविण्यासाठी नियमित अंदाज लावता येण्याजोग्या क्रमांकांचा वापर केला जातो. मला वाटते की तुम्ही असा अंदाज लावू शकता की वापरकर्ता आयडी एकाने बदलणे, पुन्हा विनंती पाठवणे आणि अशा प्रकारे ACL (प्रवेश नियंत्रण सूची, प्रक्रिया आणि वापरकर्त्यांसाठी डेटा प्रवेश नियम) बायपास करून माहिती मिळवणे शक्य आहे.

सर्व्हर साइड रिक्वेस्ट फोर्जरी (SSRF)

ओपनसोर्स उत्पादनांबद्दल चांगली गोष्ट म्हणजे त्यांच्याकडे उद्भवलेल्या समस्यांचे तपशीलवार तांत्रिक वर्णन असलेले मंच मोठ्या संख्येने आहेत आणि जर तुम्ही भाग्यवान असाल, तर समाधानाचे वर्णन. परंतु या नाण्याला एक फ्लिप साइड आहे: ज्ञात असुरक्षा देखील तपशीलवार वर्णन केल्या आहेत. उदाहरणार्थ, OpenStack फोरमवर भेद्यतेचे अप्रतिम वर्णन आहेत [XSS] и [SSRF], जे काही कारणास्तव कोणीही दुरुस्त करण्याची घाई करत नाही.

ऍप्लिकेशन्सची सामान्य कार्यक्षमता म्हणजे सर्व्हरला लिंक पाठवण्याची वापरकर्त्याची क्षमता, ज्यावर सर्व्हर क्लिक करतो (उदाहरणार्थ, निर्दिष्ट स्त्रोतावरून प्रतिमा डाउनलोड करण्यासाठी). जर सुरक्षा साधने स्वतः दुवे फिल्टर करत नाहीत किंवा सर्व्हरवरून वापरकर्त्यांना दिलेले प्रतिसाद, अशी कार्यक्षमता हल्लेखोरांद्वारे सहजपणे वापरली जाऊ शकतात.

SSRF असुरक्षा आक्रमणाच्या विकासास मोठ्या प्रमाणात वाढवू शकतात. आक्रमणकर्त्याला मिळू शकते:

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

ओपनस्टॅकमध्ये एक SSRF भेद्यता फार पूर्वीपासून ज्ञात आहे, जी निसर्गात “अंध” आहे: जेव्हा तुम्ही सर्व्हरशी संपर्क साधता तेव्हा तुम्हाला त्याकडून प्रतिसाद मिळत नाही, परंतु विनंतीच्या परिणामानुसार तुम्हाला वेगवेगळ्या प्रकारच्या त्रुटी/विलंब मिळतात. . या आधारावर, तुम्ही अंतर्गत नेटवर्कवरील होस्टवर पोर्ट स्कॅन करू शकता, पुढील सर्व परिणामांसह ज्यांना कमी लेखले जाऊ नये. उदाहरणार्थ, उत्पादनामध्ये बॅक-ऑफिस API असू शकते जे केवळ कॉर्पोरेट नेटवर्कवरून प्रवेश करण्यायोग्य आहे. दस्तऐवजीकरणासह (आतल्या लोकांबद्दल विसरू नका), आक्रमणकर्ता अंतर्गत पद्धतींमध्ये प्रवेश करण्यासाठी SSRF वापरू शकतो. उदाहरणार्थ, जर तुम्हाला उपयुक्त URL ची अंदाजे यादी मिळू शकली असेल, तर SSRF वापरून तुम्ही त्यामधून जाऊ शकता आणि विनंती कार्यान्वित करू शकता - तुलनेने बोलायचे तर, खात्यातून खात्यात पैसे हस्तांतरित करा किंवा मर्यादा बदलू शकता.

OpenStack मध्ये SSRF असुरक्षा शोधण्याची ही पहिलीच वेळ नाही. पूर्वी, थेट दुव्यावरून व्हीएम आयएसओ प्रतिमा डाउनलोड करणे शक्य होते, ज्यामुळे समान परिणाम देखील झाले. हे वैशिष्ट्य आता OpenStack वरून काढून टाकण्यात आले आहे. वरवर पाहता, समुदायाने हा समस्येचा सर्वात सोपा आणि विश्वासार्ह उपाय मानला.

आणि मध्ये हे HackerOne सेवा (h1) कडून सार्वजनिकरित्या उपलब्ध अहवाल, इंस्टन्स मेटाडेटा वाचण्याच्या क्षमतेसह यापुढे अंध नसलेल्या SSRF चे शोषण संपूर्ण Shopify इन्फ्रास्ट्रक्चरमध्ये रूट ऍक्सेसकडे नेईल.

MCS मध्ये, SSRF असुरक्षा दोन ठिकाणी समान कार्यक्षमतेसह शोधण्यात आल्या, परंतु फायरवॉल आणि इतर संरक्षणांमुळे त्यांचे शोषण करणे जवळजवळ अशक्य होते. एक ना एक मार्ग, MCS टीमने समुदायाची वाट न पाहता या समस्येचे निराकरण केले.

शेल लोड करण्याऐवजी XSS

शेकडो अभ्यास लिहिले असूनही, वर्षानुवर्षे XSS (क्रॉस-साइट स्क्रिप्टिंग) हल्ला अजूनही सर्वात जास्त आहे वारंवार भेटले वेब भेद्यता (किंवा हल्ला?).

कोणत्याही सुरक्षा संशोधकासाठी फाइल अपलोड हे आवडते ठिकाण आहे. हे बर्‍याचदा निष्पन्न होते की आपण एक अनियंत्रित स्क्रिप्ट (एएसपी/जेएसपी/पीएचपी) लोड करू शकता आणि पेंटेस्टर्सच्या परिभाषेत ओएस कमांड कार्यान्वित करू शकता - “लोड शेल”. परंतु अशा असुरक्षिततेची लोकप्रियता दोन्ही दिशेने कार्य करते: ते लक्षात ठेवले जातात आणि त्यांच्याविरूद्ध उपाय विकसित केले जातात, जेणेकरून अलीकडे "शेल लोड करणे" ची संभाव्यता शून्य होते.

हल्ला करणारा संघ (डिजिटल सिक्युरिटी द्वारे प्रस्तुत) भाग्यवान होता. ठीक आहे, MCS मध्ये सर्व्हरच्या बाजूला डाऊनलोड केलेल्या फायलींची सामग्री तपासली होती, फक्त प्रतिमांना परवानगी होती. पण SVG देखील एक चित्र आहे. SVG प्रतिमा धोकादायक कशा असू शकतात? कारण तुम्ही त्यात JavaScript स्निपेट्स एम्बेड करू शकता!

हे निष्पन्न झाले की डाउनलोड केलेल्या फायली एमसीएस सेवेच्या सर्व वापरकर्त्यांसाठी उपलब्ध आहेत, याचा अर्थ इतर क्लाउड वापरकर्त्यांवर, म्हणजे प्रशासकांवर हल्ला करणे शक्य आहे.

फिशिंग लॉगिन फॉर्मवर XSS हल्ल्याचे उदाहरण

XSS हल्ला शोषणाची उदाहरणे:

• जर लोड केलेली स्क्रिप्ट संसाधन API मध्ये त्वरित प्रवेश करू शकत असेल तर सत्र चोरण्याचा प्रयत्न का करायचा (विशेषतः आता HTTP-केवळ कुकीज सर्वत्र आहेत, जेएस स्क्रिप्ट वापरून चोरीपासून संरक्षित आहेत)? या प्रकरणात, पेलोड सर्व्हर कॉन्फिगरेशन बदलण्यासाठी XHR विनंत्या वापरू शकतो, उदाहरणार्थ, आक्रमणकर्त्याची सार्वजनिक SSH की जोडा आणि सर्व्हरवर SSH प्रवेश मिळवा.
• जर CSP धोरण (सामग्री संरक्षण धोरण) JavaScript ला इंजेक्ट करण्यापासून प्रतिबंधित करते, तर आक्रमणकर्ता त्याशिवाय जाऊ शकतो. शुद्ध HTML वापरून, साइटसाठी बनावट लॉगिन फॉर्म तयार करा आणि या प्रगत फिशिंगद्वारे प्रशासकाचा पासवर्ड चोरा: वापरकर्त्यासाठी फिशिंग पृष्ठ समान URL वर संपते आणि वापरकर्त्यासाठी ते शोधणे अधिक कठीण आहे.
• शेवटी, आक्रमणकर्ता व्यवस्था करू शकतो क्लायंट DoS — ४ KB पेक्षा मोठ्या कुकीज सेट करा. वापरकर्त्याने फक्त एकदाच लिंक उघडणे आवश्यक आहे आणि जोपर्यंत वापरकर्ता ब्राउझर साफ करण्याचा विचार करत नाही तोपर्यंत संपूर्ण साइट प्रवेश करण्यायोग्य बनते: बहुतेक प्रकरणांमध्ये, वेब सर्व्हर अशा क्लायंटला स्वीकारण्यास नकार देईल.

या वेळी अधिक हुशार शोषणासह, आणखी एका शोधलेल्या XSS चे उदाहरण पाहूया. MCS सेवा तुम्हाला फायरवॉल सेटिंग्ज गटांमध्ये एकत्र करण्याची परवानगी देते. गटाचे नाव जिथे XSS आढळले होते. त्याचे वैशिष्ठ्य असे होते की व्हेक्टर ताबडतोब ट्रिगर झाला नाही, नियमांची सूची पाहताना नाही तर गट हटवताना:

म्हणजेच, परिस्थिती खालीलप्रमाणे होती: आक्रमणकर्ता नावात "लोड" सह फायरवॉल नियम तयार करतो, प्रशासकाला थोड्या वेळाने ते लक्षात येते आणि हटविण्याची प्रक्रिया सुरू होते. आणि इथेच दुर्भावनापूर्ण JS कार्य करते.

MCS विकसकांसाठी, डाउनलोड केलेल्या SVG प्रतिमांमधील XSS विरूद्ध संरक्षण करण्यासाठी (त्या सोडल्या जाऊ शकत नसल्यास), डिजिटल सुरक्षा टीमने शिफारस केली:

• वापरकर्त्यांनी अपलोड केलेल्या फायली वेगळ्या डोमेनवर ठेवा ज्याचा “कुकीज” शी काहीही संबंध नाही. स्क्रिप्ट वेगळ्या डोमेनच्या संदर्भात अंमलात आणली जाईल आणि MCS ला धोका निर्माण करणार नाही.
• सर्व्हरच्या HTTP प्रतिसादात, “सामग्री-स्वभाव: संलग्नक” शीर्षलेख पाठवा. नंतर फाइल्स ब्राउझरद्वारे डाउनलोड केल्या जातील आणि अंमलात आणल्या जाणार नाहीत.

याव्यतिरिक्त, आता XSS शोषणाचे धोके कमी करण्यासाठी विकसकांना अनेक मार्ग उपलब्ध आहेत:

• “केवळ HTTP” ध्वज वापरून, तुम्ही सत्र “कुकीज” हेडर दुर्भावनापूर्ण JavaScript ला अगम्य बनवू शकता;
• CSP धोरणाची योग्य अंमलबजावणी केली आक्रमणकर्त्यासाठी XSS चे शोषण करणे अधिक कठीण होईल;
• आधुनिक टेम्प्लेट इंजिन जसे की अँगुलर किंवा रिएक्ट वापरकर्त्याच्या ब्राउझरवर आउटपुट करण्यापूर्वी वापरकर्ता डेटा स्वयंचलितपणे निर्जंतुक करतात.

द्वि-घटक प्रमाणीकरण भेद्यता

खाते सुरक्षा सुधारण्यासाठी, वापरकर्त्यांना नेहमी 2FA (टू-फॅक्टर ऑथेंटिकेशन) सक्षम करण्याचा सल्ला दिला जातो. खरंच, जर वापरकर्त्याच्या क्रेडेन्शियल्सशी तडजोड केली गेली असेल तर आक्रमणकर्त्याला सेवेमध्ये प्रवेश मिळवण्यापासून रोखण्याचा हा एक प्रभावी मार्ग आहे.

परंतु दुसरा प्रमाणीकरण घटक वापरणे नेहमीच खाते सुरक्षिततेची हमी देते का? 2FA च्या अंमलबजावणीमध्ये खालील सुरक्षा समस्या आहेत:

• ओटीपी कोडचा ब्रूट-फोर्स सर्च (वन-टाइम कोड). ऑपरेशनची साधेपणा असूनही, मोठ्या कंपन्यांद्वारे ओटीपी ब्रूट फोर्सपासून संरक्षण नसणे यासारख्या त्रुटी देखील आढळतात: स्लॅक केस, फेसबुक केस.
• कमकुवत पिढी अल्गोरिदम, उदाहरणार्थ पुढील कोडचा अंदाज लावण्याची क्षमता.
• तार्किक त्रुटी, जसे की तुमच्या फोनवर इतर कोणाच्या तरी OTP ची विनंती करण्याची क्षमता होते Shopify कडून.

MCS च्या बाबतीत, 2FA ची अंमलबजावणी Google Authenticator वर आधारित आहे आणि डुओ. प्रोटोकॉलची स्वतःच वेळ-चाचणी केली गेली आहे, परंतु अनुप्रयोगाच्या बाजूने कोड सत्यापनाची अंमलबजावणी तपासण्यासारखी आहे.

MCS 2FA अनेक ठिकाणी वापरले जाते:

• वापरकर्त्याचे प्रमाणीकरण करताना. ब्रूट फोर्सपासून संरक्षण आहे: वापरकर्त्यास एक-वेळ पासवर्ड प्रविष्ट करण्यासाठी फक्त काही प्रयत्न केले जातात, त्यानंतर इनपुट थोड्या काळासाठी अवरोधित केला जातो. हे OTP च्या ब्रूट-फोर्स निवडीची शक्यता अवरोधित करते.
• 2FA करण्यासाठी ऑफलाइन बॅकअप कोड व्युत्पन्न करताना, तसेच ते अक्षम करताना. येथे, कोणतेही ब्रूट फोर्स संरक्षण लागू केले गेले नाही, ज्यामुळे तुमच्याकडे खात्यासाठी पासवर्ड आणि सक्रिय सत्र असल्यास, बॅकअप कोड पुन्हा निर्माण करणे किंवा 2FA पूर्णपणे अक्षम करणे शक्य झाले.

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

“Burp: Intruder” टूल वापरून 2FA अक्षम करण्यासाठी OTP निवडण्याची प्रक्रिया

परिणाम

एकूणच, MCS हे उत्पादन म्हणून सुरक्षित असल्याचे दिसते. लेखापरीक्षणादरम्यान, पेन्टेस्टिंग टीमला क्लायंट VM आणि त्यांच्या डेटामध्ये प्रवेश मिळू शकला नाही आणि आढळलेल्या भेद्यता MCS टीमने त्वरीत दुरुस्त केल्या.

परंतु येथे हे लक्षात घेणे आवश्यक आहे की सुरक्षा हे सतत काम आहे. सेवा स्थिर नसतात, त्या सतत विकसित होत असतात. आणि असुरक्षिततेशिवाय उत्पादन पूर्णपणे विकसित करणे अशक्य आहे. परंतु आपण त्यांना वेळेत शोधू शकता आणि त्यांच्या पुनरावृत्तीची शक्यता कमी करू शकता.

आता MCS मध्ये नमूद केलेल्या सर्व भेद्यता आधीच निश्चित केल्या गेल्या आहेत. आणि नवीन लोकांची संख्या कमीतकमी ठेवण्यासाठी आणि त्यांचे आयुष्य कमी करण्यासाठी, प्लॅटफॉर्म टीम हे करत आहे:

• बाह्य कंपन्यांद्वारे नियमितपणे ऑडिट करा;
• समर्थन आणि सहभाग विकसित करा Mail.ru ग्रुप बग बाउंटी प्रोग्राममध्ये;
• सुरक्षिततेत गुंतणे. 🙂

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