کلاؤڈ سیکیورٹی مانیٹرنگ

ڈیٹا اور ایپلیکیشنز کو کلاؤڈ پر منتقل کرنا کارپوریٹ SOCs کے لیے ایک نیا چیلنج پیش کرتا ہے، جو ہمیشہ دوسرے لوگوں کے انفراسٹرکچر کی نگرانی کے لیے تیار نہیں ہوتے ہیں۔ نیٹوسکوپ کے مطابق، اوسط انٹرپرائز (بظاہر امریکہ میں) 1246 مختلف کلاؤڈ سروسز استعمال کرتا ہے، جو ایک سال پہلے کے مقابلے میں 22 فیصد زیادہ ہے۔ 1246 کلاؤڈ سروسز!!! ان میں سے 175 کا تعلق HR سروسز سے، 170 کا تعلق مارکیٹنگ سے، 110 کا کمیونیکیشن کے شعبے سے اور 76 کا تعلق فنانس اور CRM سے ہے۔ Cisco "صرف" 700 بیرونی کلاؤڈ سروسز استعمال کرتا ہے۔ تو میں ان نمبروں سے تھوڑا سا الجھا ہوا ہوں۔ لیکن کسی بھی صورت میں، مسئلہ ان کے ساتھ نہیں ہے، لیکن اس حقیقت کے ساتھ کہ کلاؤڈ کو کمپنیوں کی بڑھتی ہوئی تعداد کے ذریعہ کافی فعال طور پر استعمال کرنا شروع کر دیا گیا ہے جو اپنے نیٹ ورک کی طرح کلاؤڈ انفراسٹرکچر کی نگرانی کے لئے وہی صلاحیتیں رکھنا چاہیں گی۔ اور یہ رجحان بڑھ رہا ہے - کے مطابق امریکی چیمبر آف اکاؤنٹس کے مطابق 2023 تک، ریاستہائے متحدہ میں 1200 ڈیٹا سینٹرز بند ہونے جا رہے ہیں (6250 پہلے ہی بند ہو چکے ہیں)۔ لیکن کلاؤڈ میں منتقلی صرف یہ نہیں ہے کہ "آئیے اپنے سرورز کو کسی بیرونی فراہم کنندہ کے پاس منتقل کریں۔" نیا IT فن تعمیر، نیا سافٹ ویئر، نئے عمل، نئی پابندیاں... یہ سب نہ صرف IT بلکہ معلومات کی حفاظت کے کام میں بھی اہم تبدیلیاں لاتے ہیں۔ اور اگر فراہم کنندگان نے کسی نہ کسی طرح کلاؤڈ کی حفاظت کو یقینی بنانا سیکھ لیا ہے (خوش قسمتی سے بہت ساری سفارشات ہیں)، تو کلاؤڈ انفارمیشن سیکیورٹی مانیٹرنگ کے ساتھ، خاص طور پر SaaS پلیٹ فارمز پر، اہم مشکلات ہیں، جن کے بارے میں ہم بات کریں گے۔

مان لیں کہ آپ کی کمپنی نے اپنے بنیادی ڈھانچے کا کچھ حصہ کلاؤڈ پر منتقل کر دیا ہے... رکو۔ اس طرح نہیں۔ اگر انفراسٹرکچر کو منتقل کر دیا گیا ہے، اور آپ صرف اس بارے میں سوچ رہے ہیں کہ آپ اس کی نگرانی کیسے کریں گے، تو آپ پہلے ہی کھو چکے ہیں۔ جب تک کہ یہ ایمیزون، گوگل، یا مائیکروسافٹ (اور پھر تحفظات کے ساتھ) نہ ہو، آپ کے پاس اپنے ڈیٹا اور ایپلیکیشنز کی نگرانی کرنے کی زیادہ صلاحیت نہیں ہوگی۔ اگر آپ کو لاگز کے ساتھ کام کرنے کا موقع دیا جائے تو یہ اچھا ہے۔ بعض اوقات سیکیورٹی ایونٹ کا ڈیٹا دستیاب ہوگا، لیکن آپ کو اس تک رسائی حاصل نہیں ہوگی۔ مثال کے طور پر، Office 365۔ اگر آپ کے پاس سب سے سستا E1 لائسنس ہے، تو سیکیورٹی ایونٹس آپ کے لیے بالکل بھی دستیاب نہیں ہیں۔ اگر آپ کے پاس E3 لائسنس ہے، تو آپ کا ڈیٹا صرف 90 دنوں کے لیے محفوظ کیا جاتا ہے، اور صرف اس صورت میں جب آپ کے پاس E5 لائسنس ہے، لاگز کی مدت ایک سال کے لیے دستیاب ہے (تاہم، اس کی اپنی باریکیاں بھی ہیں جو علیحدہ علیحدہ کرنے کی ضرورت سے متعلق ہیں۔ مائیکروسافٹ سپورٹ سے لاگز کے ساتھ کام کرنے کے لیے متعدد فنکشنز کی درخواست کریں)۔ ویسے، کارپوریٹ ایکسچینج کے مقابلے E3 لائسنس مانیٹرنگ کے افعال کے لحاظ سے بہت کمزور ہے۔ اسی سطح کو حاصل کرنے کے لیے، آپ کو E5 لائسنس یا ایک اضافی ایڈوانسڈ کمپلائنس لائسنس کی ضرورت ہے، جس کے لیے اضافی رقم درکار ہو سکتی ہے جو کلاؤڈ انفراسٹرکچر پر جانے کے لیے آپ کے مالیاتی ماڈل میں شامل نہیں کی گئی تھی۔ اور یہ کلاؤڈ انفارمیشن سیکیورٹی مانیٹرنگ سے متعلق مسائل کو کم کرنے کی صرف ایک مثال ہے۔ اس مضمون میں، مکمل ہونے کا بہانہ کیے بغیر، میں کچھ باریکیوں کی طرف توجہ مبذول کرانا چاہتا ہوں جنہیں حفاظتی نقطہ نظر سے کلاؤڈ فراہم کنندہ کا انتخاب کرتے وقت دھیان میں رکھنا چاہیے۔ اور مضمون کے آخر میں، ایک چیک لسٹ دی جائے گی جو اس بات پر غور کرنے سے پہلے کہ کلاؤڈ انفارمیشن سیکیورٹی کی نگرانی کا مسئلہ حل ہو گیا ہے، مکمل کرنا ضروری ہے۔

کئی عام مسائل ہیں جو بادل کے ماحول میں واقعات کا باعث بنتے ہیں، جن کا جواب دینے کے لیے انفارمیشن سیکیورٹی سروسز کے پاس وقت نہیں ہوتا یا انہیں بالکل نظر نہیں آتا:

• سیکیورٹی لاگز موجود نہیں ہیں۔ یہ کافی عام صورت حال ہے، خاص طور پر کلاؤڈ سلوشنز مارکیٹ میں نئے کھلاڑیوں کے درمیان۔ لیکن آپ کو فوری طور پر ان سے دستبردار نہیں ہونا چاہئے۔ چھوٹے کھلاڑی، خاص طور پر گھریلو، گاہک کی ضروریات کے لیے زیادہ حساس ہوتے ہیں اور اپنی مصنوعات کے لیے منظور شدہ روڈ میپ کو تبدیل کر کے کچھ ضروری کاموں کو تیزی سے نافذ کر سکتے ہیں۔ ہاں، یہ Amazon سے GuardDuty یا Bitrix سے "Proactive Protection" ماڈیول کا analogue نہیں ہوگا، لیکن کم از کم کچھ۔
• انفارمیشن سیکیورٹی کو نہیں معلوم کہ لاگز کہاں محفوظ ہیں یا ان تک رسائی نہیں ہے۔ یہاں کلاؤڈ سروس فراہم کرنے والے کے ساتھ بات چیت میں داخل ہونا ضروری ہے - شاید وہ ایسی معلومات فراہم کرے گا اگر وہ کلائنٹ کو اپنے لئے اہم سمجھتا ہے۔ لیکن عام طور پر، یہ بہت اچھا نہیں ہوتا جب لاگز تک رسائی "خصوصی فیصلے کے ذریعے" فراہم کی جاتی ہے۔
• ایسا بھی ہوتا ہے کہ کلاؤڈ فراہم کرنے والے کے پاس لاگ ہیں، لیکن وہ محدود نگرانی اور ایونٹ کی ریکارڈنگ فراہم کرتے ہیں، جو تمام واقعات کا پتہ لگانے کے لیے کافی نہیں ہیں۔ مثال کے طور پر، آپ کو صرف ویب سائٹ پر تبدیلیوں کے لاگز یا صارف کی توثیق کی کوششوں کے لاگز موصول ہو سکتے ہیں، لیکن دوسرے واقعات نہیں، جیسے کہ نیٹ ورک ٹریفک، جو آپ سے ایسے واقعات کی ایک پوری پرت چھپائے گی جو آپ کے کلاؤڈ انفراسٹرکچر کو ہیک کرنے کی کوششوں کو نمایاں کرتی ہیں۔
• نوشتہ جات موجود ہیں، لیکن ان تک رسائی خودکار کرنا مشکل ہے، جس کی وجہ سے ان کی نگرانی مسلسل نہیں، بلکہ شیڈول کے مطابق کی جاتی ہے۔ اور اگر آپ لاگز کو خود بخود ڈاؤن لوڈ نہیں کر سکتے ہیں، تو لاگ ڈاؤن لوڈ کرنا، مثال کے طور پر، ایکسل فارمیٹ میں (جیسا کہ متعدد گھریلو کلاؤڈ حل فراہم کرنے والوں کے ساتھ)، کارپوریٹ انفارمیشن سیکیورٹی سروس کی جانب سے ان کے ساتھ ٹنکر کرنے میں ہچکچاہٹ کا باعث بھی بن سکتا ہے۔
• کوئی لاگ مانیٹرنگ نہیں ہے۔ بادل کے ماحول میں انفارمیشن سیکیورٹی کے واقعات کے رونما ہونے کی یہ شاید سب سے غیر واضح وجہ ہے۔ ایسا لگتا ہے کہ وہاں لاگز موجود ہیں، اور ان تک خودکار رسائی ممکن ہے، لیکن کوئی بھی ایسا نہیں کرتا ہے۔ کیوں؟

مشترکہ کلاؤڈ سیکیورٹی کا تصور

کلاؤڈ میں منتقلی ہمیشہ بنیادی ڈھانچے پر کنٹرول برقرار رکھنے اور اسے کلاؤڈ فراہم کرنے والے کے زیادہ پیشہ ورانہ ہاتھوں میں منتقل کرنے کی خواہش کے درمیان توازن کی تلاش ہوتی ہے جو اسے برقرار رکھنے میں مہارت رکھتا ہے۔ اور کلاؤڈ سیکیورٹی کے شعبے میں بھی اس توازن کو تلاش کرنا ہوگا۔ مزید برآں، استعمال کیے گئے کلاؤڈ سروس ڈیلیوری ماڈل (IaaS, PaaS, SaaS) پر منحصر ہے، یہ بیلنس ہر وقت مختلف رہے گا۔ کسی بھی صورت میں، ہمیں یاد رکھنا چاہیے کہ آج کل کلاؤڈ فراہم کرنے والے تمام نام نہاد مشترکہ ذمہ داری اور مشترکہ معلوماتی حفاظتی ماڈل کی پیروی کرتے ہیں۔ کلاؤڈ کچھ چیزوں کے لیے ذمہ دار ہے، اور دوسروں کے لیے کلائنٹ ذمہ دار ہے، اس کا ڈیٹا، اس کی ایپلی کیشنز، اس کی ورچوئل مشینیں اور دیگر وسائل کو کلاؤڈ میں رکھنا۔ یہ توقع کرنا لاپرواہی ہوگی کہ بادل پر جا کر، ہم تمام ذمہ داری فراہم کنندہ پر ڈال دیں گے۔ لیکن کلاؤڈ پر جاتے وقت تمام سیکیورٹی خود تیار کرنا بھی غیر دانشمندانہ ہے۔ ایک توازن کی ضرورت ہے، جس کا انحصار بہت سے عوامل پر ہوگا: - خطرے کے انتظام کی حکمت عملی، خطرے کا ماڈل، کلاؤڈ فراہم کرنے والے کے لیے دستیاب سیکیورٹی میکانزم، قانون سازی وغیرہ۔

مثال کے طور پر، کلاؤڈ میں ہوسٹ کردہ ڈیٹا کی درجہ بندی ہمیشہ گاہک کی ذمہ داری ہوتی ہے۔ ایک کلاؤڈ فراہم کنندہ یا ایک بیرونی سروس فراہم کنندہ صرف ان ٹولز کے ساتھ اس کی مدد کرسکتا ہے جو کلاؤڈ میں ڈیٹا کو نشان زد کرنے، خلاف ورزیوں کی نشاندہی کرنے، قانون کی خلاف ورزی کرنے والے ڈیٹا کو حذف کرنے، یا کسی نہ کسی طریقے کو استعمال کرتے ہوئے اسے ماسک کرنے میں مدد کرے گا۔ دوسری طرف، فزیکل سیکیورٹی ہمیشہ کلاؤڈ فراہم کنندہ کی ذمہ داری ہوتی ہے، جسے وہ کلائنٹس کے ساتھ شیئر نہیں کر سکتا۔ لیکن ہر وہ چیز جو ڈیٹا اور فزیکل انفراسٹرکچر کے درمیان ہے اس مضمون میں بحث کا موضوع ہے۔ مثال کے طور پر، کلاؤڈ کی دستیابی فراہم کنندہ کی ذمہ داری ہے، اور فائر وال کے قوانین کو ترتیب دینا یا انکرپشن کو فعال کرنا کلائنٹ کی ذمہ داری ہے۔ اس مضمون میں ہم یہ دیکھنے کی کوشش کریں گے کہ آج کل روس میں مختلف مقبول کلاؤڈ فراہم کنندگان کی جانب سے انفارمیشن سیکیورٹی مانیٹرنگ میکانزم فراہم کیے جاتے ہیں، ان کے استعمال کی خصوصیات کیا ہیں، اور یہ کب بیرونی اوورلے حل کی طرف دیکھنے کے قابل ہے (مثال کے طور پر، سسکو ای- میل سیکیورٹی) جو سائبر سیکیورٹی کے لحاظ سے آپ کے کلاؤڈ کی صلاحیتوں کو بڑھاتا ہے۔ کچھ معاملات میں، خاص طور پر اگر آپ ملٹی کلاؤڈ حکمت عملی کی پیروی کر رہے ہیں، تو آپ کے پاس ایک ساتھ کئی کلاؤڈ ماحول میں بیرونی معلومات کی حفاظت کی نگرانی کے حل استعمال کرنے کے علاوہ کوئی چارہ نہیں ہوگا (مثال کے طور پر، Cisco CloudLock یا Cisco Stealthwatch Cloud)۔ ٹھیک ہے، کچھ معاملات میں آپ کو یہ احساس ہوگا کہ آپ نے جو کلاؤڈ فراہم کنندہ منتخب کیا ہے (یا آپ پر مسلط کیا گیا ہے) وہ معلومات کی حفاظت کی نگرانی کی صلاحیتیں بالکل بھی پیش نہیں کرتا ہے۔ یہ ناخوشگوار ہے، لیکن تھوڑا بھی نہیں، کیونکہ یہ آپ کو اس کلاؤڈ کے ساتھ کام کرنے سے وابستہ خطرے کی سطح کا مناسب اندازہ لگانے کی اجازت دیتا ہے۔

کلاؤڈ سیکیورٹی مانیٹرنگ لائف سائیکل

آپ جو بادل استعمال کرتے ہیں ان کی حفاظت کی نگرانی کرنے کے لیے، آپ کے پاس صرف تین اختیارات ہیں:

• اپنے کلاؤڈ فراہم کنندہ کے ذریعہ فراہم کردہ ٹولز پر انحصار کریں،
• فریق ثالث کے ایسے حل استعمال کریں جو آپ کے استعمال کردہ IaaS، PaaS یا SaaS پلیٹ فارمز کی نگرانی کریں گے،
• اپنا کلاؤڈ مانیٹرنگ انفراسٹرکچر بنائیں (صرف IaaS/PaaS پلیٹ فارمز کے لیے)۔

آئیے دیکھتے ہیں کہ ان میں سے ہر ایک میں کیا خصوصیات ہیں۔ لیکن پہلے، ہمیں عام فریم ورک کو سمجھنے کی ضرورت ہے جو کلاؤڈ پلیٹ فارم کی نگرانی کے دوران استعمال کیا جائے گا۔ میں کلاؤڈ میں معلومات کی حفاظت کی نگرانی کے عمل کے 6 اہم اجزاء کو اجاگر کروں گا:

• انفراسٹرکچر کی تیاری۔ سٹوریج میں معلومات کی حفاظت کے لیے اہم واقعات کو جمع کرنے کے لیے ضروری ایپلی کیشنز اور انفراسٹرکچر کا تعین کرنا۔
• مجموعہ. اس مرحلے پر، پروسیسنگ، اسٹوریج اور تجزیہ کے لیے بعد میں ٹرانسمیشن کے لیے مختلف ذرائع سے سیکیورٹی کے واقعات کو جمع کیا جاتا ہے۔
• علاج. اس مرحلے پر، ڈیٹا کو تبدیل کیا جاتا ہے اور بعد کے تجزیے کی سہولت کے لیے افزودہ کیا جاتا ہے۔
• ذخیرہ یہ جزو جمع شدہ پروسیس شدہ اور خام ڈیٹا کے قلیل مدتی اور طویل مدتی ذخیرہ کے لیے ذمہ دار ہے۔
• تجزیہ۔ اس مرحلے پر، آپ کے پاس واقعات کا پتہ لگانے اور خود بخود یا دستی طور پر ان کا جواب دینے کی صلاحیت ہے۔
• رپورٹنگ۔ یہ مرحلہ اسٹیک ہولڈرز (انتظام، آڈیٹرز، کلاؤڈ فراہم کنندہ، کلائنٹس، وغیرہ) کے لیے کلیدی اشارے تیار کرنے میں مدد کرتا ہے جو ہمیں کچھ فیصلے کرنے میں مدد کرتا ہے، مثال کے طور پر، فراہم کنندہ کو تبدیل کرنا یا معلومات کی حفاظت کو مضبوط کرنا۔

ان اجزاء کو سمجھنا آپ کو مستقبل میں جلد فیصلہ کرنے کی اجازت دے گا کہ آپ اپنے فراہم کنندہ سے کیا لے سکتے ہیں، اور آپ کو خود یا بیرونی کنسلٹنٹس کی شمولیت سے کیا کرنا پڑے گا۔

بلٹ ان کلاؤڈ سروسز

میں نے پہلے ہی اوپر لکھا ہے کہ آج کل بہت سی کلاؤڈ سروسز انفارمیشن سیکیورٹی مانیٹرنگ کی صلاحیتیں فراہم نہیں کرتی ہیں۔ عام طور پر، وہ معلومات کی حفاظت کے موضوع پر زیادہ توجہ نہیں دیتے ہیں۔ مثال کے طور پر، انٹرنیٹ کے ذریعے سرکاری اداروں کو رپورٹیں بھیجنے کے لیے مقبول روسی خدمات میں سے ایک (میں خاص طور پر اس کا نام نہیں بتاؤں گا)۔ اس سروس کی سیکورٹی کے بارے میں پورا حصہ تصدیق شدہ CIPF کے استعمال کے گرد گھومتا ہے۔ الیکٹرانک دستاویز کے انتظام کے لیے ایک اور گھریلو کلاؤڈ سروس کا انفارمیشن سیکیورٹی سیکشن مختلف نہیں ہے۔ یہ عوامی کلیدی سرٹیفکیٹس، مصدقہ کرپٹوگرافی، ویب کی کمزوریوں کو ختم کرنے، DDoS حملوں سے تحفظ، فائر والز، بیک اپس، اور یہاں تک کہ باقاعدہ انفارمیشن سیکیورٹی آڈٹ کے بارے میں بات کرتا ہے۔ لیکن نگرانی کے بارے میں کوئی لفظ نہیں ہے، اور نہ ہی انفارمیشن سیکیورٹی ایونٹس تک رسائی حاصل کرنے کے امکان کے بارے میں جو اس سروس فراہم کنندہ کے کلائنٹس کے لیے دلچسپی کا باعث ہوسکتے ہیں۔

عام طور پر، جس طرح سے کلاؤڈ فراہم کنندہ اپنی ویب سائٹ پر اور اپنی دستاویزات میں معلومات کے تحفظ کے مسائل کو بیان کرتا ہے، آپ سمجھ سکتے ہیں کہ وہ اس مسئلے کو کتنی سنجیدگی سے لیتا ہے۔ مثال کے طور پر، اگر آپ "My Office" پروڈکٹس کے لیے کتابچے پڑھتے ہیں، تو وہاں سیکورٹی کے بارے میں کوئی لفظ نہیں ہے، لیکن علیحدہ پروڈکٹ "My Office" کے لیے دستاویزات میں ہے۔ KS3"، غیر مجاز رسائی سے تحفظ کے لیے ڈیزائن کیا گیا ہے، FSTEC کے 17ویں آرڈر کے پوائنٹس کی ایک عام فہرست ہے، جسے "My Office.KS3" لاگو کرتا ہے، لیکن یہ بیان نہیں کیا گیا ہے کہ یہ اسے کیسے نافذ کرتا ہے اور سب سے اہم بات یہ ہے کہ کیسے ان میکانزم کو کارپوریٹ انفارمیشن سیکیورٹی کے ساتھ مربوط کریں۔ شاید ایسی دستاویزات موجود ہوں، لیکن مجھے یہ عوامی ڈومین میں، "My Office" ویب سائٹ پر نہیں ملی۔ حالانکہ شاید مجھے اس خفیہ معلومات تک رسائی حاصل نہیں ہے؟

Bitrix کے لئے، صورت حال بہت بہتر ہے. دستاویزات میں ایونٹ لاگ کے فارمیٹس اور دلچسپ بات یہ ہے کہ انٹروژن لاگ، جس میں کلاؤڈ پلیٹ فارم کو ممکنہ خطرات سے متعلق واقعات شامل ہیں۔ وہاں سے آپ IP، صارف یا مہمان کا نام، ایونٹ کا ذریعہ، وقت، صارف ایجنٹ، ایونٹ کی قسم وغیرہ نکال سکتے ہیں۔ سچ ہے، آپ ان واقعات کے ساتھ یا تو خود کلاؤڈ کے کنٹرول پینل سے کام کر سکتے ہیں، یا MS Excel فارمیٹ میں ڈیٹا اپ لوڈ کر سکتے ہیں۔ اب Bitrix لاگز کے ساتھ کام کو خودکار کرنا مشکل ہے اور آپ کو کچھ کام دستی طور پر کرنا ہوں گے (رپورٹ اپ لوڈ کرنا اور اسے اپنے SIEM میں لوڈ کرنا)۔ لیکن اگر ہم یاد رکھیں کہ نسبتاً حال ہی میں ایسا موقع موجود نہیں تھا، تو یہ بہت بڑی پیش رفت ہے۔ ایک ہی وقت میں، میں یہ نوٹ کرنا چاہوں گا کہ بہت سے غیر ملکی کلاؤڈ فراہم کرنے والے "ابتدائی لوگوں کے لیے" اسی طرح کی فعالیت پیش کرتے ہیں - یا تو کنٹرول پینل کے ذریعے لاگز کو اپنی آنکھوں سے دیکھیں، یا ڈیٹا کو اپنے پاس اپ لوڈ کریں (تاہم، زیادہ تر ڈیٹا اپ لوڈ کرتے ہیں۔ csv فارمیٹ، ایکسل نہیں)۔

نو-لاگز آپشن پر غور کیے بغیر، کلاؤڈ فراہم کرنے والے عام طور پر آپ کو سیکورٹی ایونٹس کی نگرانی کے لیے تین اختیارات پیش کرتے ہیں - ڈیش بورڈز، ڈیٹا اپ لوڈ اور API تک رسائی۔ ایسا لگتا ہے کہ پہلا آپ کے لیے بہت سے مسائل کو حل کرتا ہے، لیکن یہ مکمل طور پر درست نہیں ہے - اگر آپ کے پاس کئی میگزین ہیں، تو آپ کو مجموعی تصویر کو کھوتے ہوئے انہیں ڈسپلے کرنے والی اسکرینوں کے درمیان سوئچ کرنا ہوگا۔ اس کے علاوہ، کلاؤڈ فراہم کنندہ آپ کو حفاظتی واقعات کو آپس میں جوڑنے اور عام طور پر حفاظتی نقطہ نظر سے ان کا تجزیہ کرنے کی صلاحیت فراہم کرنے کا امکان نہیں رکھتا ہے (عام طور پر آپ خام ڈیٹا کے ساتھ کام کر رہے ہوتے ہیں، جسے آپ کو خود سمجھنے کی ضرورت ہوتی ہے)۔ مستثنیات ہیں اور ہم ان کے بارے میں مزید بات کریں گے۔ آخر میں، یہ پوچھنے کے قابل ہے کہ آپ کے کلاؤڈ فراہم کنندہ کے ذریعہ کون سے واقعات ریکارڈ کیے جاتے ہیں، کس شکل میں، اور وہ آپ کی معلومات کی حفاظت کی نگرانی کے عمل سے کیسے مطابقت رکھتے ہیں؟ مثال کے طور پر، صارفین اور مہمانوں کی شناخت اور تصدیق۔ وہی Bitrix آپ کو، ان واقعات کی بنیاد پر، ایونٹ کی تاریخ اور وقت، صارف یا مہمان کا نام (اگر آپ کے پاس "ویب تجزیات" ماڈیول ہے)، رسائی شدہ آبجیکٹ اور ویب سائٹ کے لیے مخصوص دیگر عناصر کو ریکارڈ کرنے کی اجازت دیتا ہے۔ . لیکن کارپوریٹ انفارمیشن سیکیورٹی سروسز کو اس بارے میں معلومات کی ضرورت ہو سکتی ہے کہ آیا صارف نے کسی قابل اعتماد ڈیوائس سے کلاؤڈ تک رسائی حاصل کی ہے (مثال کے طور پر، کارپوریٹ نیٹ ورک میں یہ کام Cisco ISE کے ذریعے نافذ کیا جاتا ہے)۔ جیو-آئی پی فنکشن جیسے آسان کام کا کیا ہوگا، جو اس بات کا تعین کرنے میں مدد کرے گا کہ آیا کلاؤڈ سروس صارف کا اکاؤنٹ چوری ہوگیا ہے؟ اور یہاں تک کہ اگر کلاؤڈ فراہم کنندہ آپ کو فراہم کرتا ہے، تو یہ کافی نہیں ہے۔ یہی Cisco CloudLock صرف جغرافیائی محل وقوع کا تجزیہ نہیں کرتا بلکہ اس کے لیے مشین لرننگ کا استعمال کرتا ہے اور ہر صارف کے لیے تاریخی ڈیٹا کا تجزیہ کرتا ہے اور شناخت اور تصدیق کی کوششوں میں مختلف بے ضابطگیوں پر نظر رکھتا ہے۔ صرف MS Azure میں اسی طرح کی فعالیت ہے (اگر آپ کے پاس مناسب سبسکرپشن ہے)۔

ایک اور مشکل ہے - چونکہ بہت سے کلاؤڈ فراہم کرنے والوں کے لیے معلومات کی حفاظت کی نگرانی ایک نیا موضوع ہے جس سے وہ ابھی نمٹنا شروع کر رہے ہیں، وہ اپنے حل میں مسلسل کچھ تبدیل کر رہے ہیں۔ آج ان کے پاس API کا ایک ورژن ہے، کل دوسرا، پرسوں ایک تیسرا۔ اس کے لیے آپ کو بھی تیار رہنا ہوگا۔ فعالیت کے ساتھ بھی ایسا ہی ہے، جو بدل سکتا ہے، جسے آپ کے انفارمیشن سیکیورٹی مانیٹرنگ سسٹم میں مدنظر رکھا جانا چاہیے۔ مثال کے طور پر، ایمیزون کے پاس ابتدائی طور پر الگ الگ کلاؤڈ ایونٹ مانیٹرنگ سروسز—AWS CloudTrail اور AWS CloudWatch تھیں۔ پھر انفارمیشن سیکیورٹی ایونٹس کی نگرانی کے لیے ایک علیحدہ سروس ظاہر ہوئی - AWS GuardDuty۔ کچھ عرصے کے بعد، ایمیزون نے ایک نیا مینجمنٹ سسٹم، Amazon Security Hub شروع کیا، جس میں GuardDuty، Amazon Inspector، Amazon Macie اور کئی دیگر افراد سے موصول ہونے والے ڈیٹا کا تجزیہ شامل ہے۔ ایک اور مثال SIEM - AzLog کے ساتھ Azure لاگ انٹیگریشن ٹول ہے۔ یہ بہت سے SIEM دکانداروں کے ذریعہ فعال طور پر استعمال کیا گیا تھا، یہاں تک کہ 2018 میں مائیکروسافٹ نے اس کی ترقی اور مدد کو روکنے کا اعلان کیا، جس نے بہت سے کلائنٹس کا سامنا کیا جنہوں نے اس ٹول کو کسی مسئلے کے ساتھ استعمال کیا (ہم اس کے بارے میں بعد میں بات کریں گے کہ اسے کیسے حل کیا گیا)۔

اس لیے، آپ کے کلاؤڈ فراہم کنندہ آپ کو پیش کردہ تمام مانیٹرنگ خصوصیات کی احتیاط سے نگرانی کریں۔ یا بیرونی حل فراہم کرنے والوں پر بھروسہ کریں جو آپ کے SOC اور اس کلاؤڈ کے درمیان ثالث کے طور پر کام کریں گے جس کی آپ نگرانی کرنا چاہتے ہیں۔ ہاں، یہ زیادہ مہنگا ہوگا (اگرچہ ہمیشہ نہیں)، لیکن آپ تمام ذمہ داری کسی اور کے کندھوں پر ڈال دیں گے۔ یا یہ سب کچھ نہیں؟... آئیے مشترکہ سیکیورٹی کے تصور کو یاد رکھیں اور سمجھیں کہ ہم کچھ بھی نہیں بدل سکتے - ہمیں آزادانہ طور پر یہ سمجھنا پڑے گا کہ مختلف کلاؤڈ فراہم کرنے والے آپ کے ڈیٹا، ایپلی کیشنز، ورچوئل مشینوں اور دیگر وسائل کی معلومات کی حفاظت کی نگرانی کیسے کرتے ہیں۔ بادل میں میزبانی کی. اور ہم اس کے ساتھ شروع کریں گے جو ایمیزون اس حصے میں پیش کرتا ہے۔

مثال: AWS کی بنیاد پر IaaS میں معلومات کی حفاظت کی نگرانی

ہاں، ہاں، میں سمجھتا ہوں کہ ایمیزون بہترین مثال نہیں ہے اس حقیقت کی وجہ سے کہ یہ ایک امریکی سروس ہے اور اسے انتہا پسندی کے خلاف جنگ اور روس میں ممنوع معلومات کی ترسیل کے حصے کے طور پر بلاک کیا جا سکتا ہے۔ لیکن اس اشاعت میں میں صرف یہ بتانا چاہوں گا کہ مختلف کلاؤڈ پلیٹ فارم اپنی معلومات کی حفاظت کی نگرانی کی صلاحیتوں میں کس طرح مختلف ہیں اور حفاظتی نقطہ نظر سے اپنے کلیدی عمل کو بادلوں میں منتقل کرتے وقت آپ کو کن چیزوں پر توجہ دینی چاہیے۔ ٹھیک ہے، اگر کلاؤڈ سلوشنز کے کچھ روسی ڈویلپرز اپنے لیے کوئی مفید چیز سیکھ لیں، تو یہ بہت اچھا ہوگا۔

پہلی بات یہ ہے کہ ایمیزون ایک ناقابل تسخیر قلعہ نہیں ہے۔ اس کے گاہکوں کے ساتھ مختلف واقعات باقاعدگی سے ہوتے رہتے ہیں۔ مثال کے طور پر، ڈیپ روٹ اینالیٹکس سے 198 ملین ووٹرز کے نام، پتے، تاریخ پیدائش اور ٹیلی فون نمبر چرائے گئے۔ اسرائیلی کمپنی Nice Systems نے Verizon کے صارفین کے 14 ملین ریکارڈ چرا لیے۔ تاہم، AWS کی بلٹ ان صلاحیتیں آپ کو واقعات کی ایک وسیع رینج کا پتہ لگانے کی اجازت دیتی ہیں۔ مثال کے طور پر:

• انفراسٹرکچر پر اثر (DDoS)
• نوڈ کمپرومائز (کمانڈ انجیکشن)
• اکاؤنٹ میں سمجھوتہ اور غیر مجاز رسائی
• غلط ترتیب اور کمزوریاں
• غیر محفوظ انٹرفیس اور APIs۔

یہ تفاوت اس حقیقت کی وجہ سے ہے کہ جیسا کہ ہم نے اوپر پایا، صارف خود کسٹمر ڈیٹا کی حفاظت کا ذمہ دار ہے۔ اور اگر اس نے حفاظتی میکانزم کو آن کرنے کی زحمت نہیں کی اور مانیٹرنگ ٹولز کو آن نہیں کیا، تو وہ صرف میڈیا یا اپنے مؤکلوں سے اس واقعے کے بارے میں جان سکے گا۔

واقعات کی نشاندہی کرنے کے لیے، آپ Amazon کی تیار کردہ مختلف مانیٹرنگ سروسز کی ایک وسیع رینج کا استعمال کر سکتے ہیں (حالانکہ یہ اکثر بیرونی ٹولز جیسے کہ osquery سے مکمل ہوتے ہیں)۔ لہذا، AWS میں، صارف کے تمام اعمال کی نگرانی کی جاتی ہے، قطع نظر اس کے کہ وہ کیسے انجام دیے جاتے ہیں - مینجمنٹ کنسول، کمانڈ لائن، SDK یا دیگر AWS سروسز کے ذریعے۔ ہر AWS اکاؤنٹ کی سرگرمی کے تمام ریکارڈ (بشمول صارف نام، کارروائی، سروس، سرگرمی کے پیرامیٹرز، اور نتیجہ) اور API کے استعمال AWS CloudTrail کے ذریعے دستیاب ہیں۔ آپ کلاؤڈ ٹریل کنسول سے ان واقعات (جیسے AWS IAM کنسول لاگ ان) کو دیکھ سکتے ہیں، Amazon Athena کا استعمال کرتے ہوئے ان کا تجزیہ کر سکتے ہیں، یا Splunk، AlienVault، وغیرہ جیسے بیرونی حلوں پر انہیں "آؤٹ سورس" کر سکتے ہیں۔ AWS CloudTrail لاگز خود آپ کی AWS S3 بالٹی میں رکھے گئے ہیں۔

دو دیگر AWS خدمات متعدد دیگر اہم نگرانی کی صلاحیتیں فراہم کرتی ہیں۔ سب سے پہلے، Amazon CloudWatch AWS وسائل اور ایپلیکیشنز کے لیے ایک مانیٹرنگ سروس ہے جو دوسری چیزوں کے علاوہ، آپ کو اپنے کلاؤڈ میں مختلف بے ضابطگیوں کی شناخت کرنے کی اجازت دیتی ہے۔ تمام بلٹ ان AWS سروسز، جیسے Amazon Elastic Compute Cloud (سرورز)، Amazon Relational Database Service (databases)، Amazon Elastic MapReduce (ڈیٹا تجزیہ)، اور 30 ​​دیگر Amazon سروسز، Amazon CloudWatch اپنے لاگز کو ذخیرہ کرنے کے لیے استعمال کرتی ہیں۔ ڈویلپرز اپنی مرضی کی ایپلی کیشنز اور خدمات میں لاگ مانیٹرنگ کی فعالیت کو شامل کرنے کے لیے Amazon CloudWatch سے اوپن API کا استعمال کر سکتے ہیں، جس سے وہ سیکیورٹی کے تناظر میں ایونٹ کے تجزیہ کے دائرہ کار کو بڑھا سکتے ہیں۔

دوم، VPC فلو لاگز سروس آپ کو اپنے AWS سرورز (بیرونی یا اندرونی طور پر) کے ساتھ ساتھ مائیکرو سروسز کے درمیان بھیجے یا موصول ہونے والے نیٹ ورک ٹریفک کا تجزیہ کرنے کی اجازت دیتی ہے۔ جب آپ کے AWS VPC وسائل میں سے کوئی بھی نیٹ ورک کے ساتھ تعامل کرتا ہے، VPC Flow Logs نیٹ ورک ٹریفک کے بارے میں تفصیلات ریکارڈ کرتا ہے، بشمول سورس اور ڈیسٹینیشن نیٹ ورک انٹرفیس، نیز IP ایڈریس، پورٹس، پروٹوکول، بائٹس کی تعداد، اور پیکٹوں کی تعداد جو آپ کرتے ہیں۔ دیکھا. مقامی نیٹ ورک سیکیورٹی کا تجربہ رکھنے والے اسے تھریڈز کے مشابہ کے طور پر پہچانیں گے۔ نیٹ فلو، جو سوئچز، راؤٹرز اور انٹرپرائز گریڈ فائر والز کے ذریعے بنایا جا سکتا ہے۔ یہ لاگز انفارمیشن سیکیورٹی کی نگرانی کے مقاصد کے لیے اہم ہیں کیونکہ، صارفین اور ایپلیکیشنز کے اعمال سے متعلق واقعات کے برعکس، یہ آپ کو AWS ورچوئل پرائیویٹ کلاؤڈ ماحول میں نیٹ ورک کے تعاملات سے محروم ہونے کی بھی اجازت دیتے ہیں۔

خلاصہ یہ کہ یہ تینوں AWS سروسز—AWS CloudTrail، Amazon CloudWatch، اور VPC فلو لاگز—ایک ساتھ آپ کے اکاؤنٹ کے استعمال، صارف کے رویے، انفراسٹرکچر مینجمنٹ، ایپلیکیشن اور سروس کی سرگرمی، اور نیٹ ورک کی سرگرمی کے بارے میں کافی طاقتور بصیرت فراہم کرتی ہیں۔ مثال کے طور پر، ان کا استعمال درج ذیل بے ضابطگیوں کا پتہ لگانے کے لیے کیا جا سکتا ہے۔

• سائٹ کو اسکین کرنے کی کوششیں، پچھلے دروازوں کی تلاش، "404 غلطیوں" کے پھٹ کے ذریعے کمزوریوں کی تلاش۔
• انجکشن حملے (مثال کے طور پر، ایس کیو ایل انجیکشن) "500 غلطیوں" کے پھٹنے کے ذریعے۔
• حملے کے معروف اوزار sqlmap، nikto، w3af، nmap، وغیرہ ہیں۔ صارف ایجنٹ فیلڈ کے تجزیہ کے ذریعے۔

Amazon Web Services نے سائبر سیکیورٹی کے مقاصد کے لیے دیگر خدمات بھی تیار کی ہیں جو آپ کو بہت سے دیگر مسائل کو حل کرنے کی اجازت دیتی ہیں۔ مثال کے طور پر، AWS کے پاس آڈیٹنگ پالیسیوں اور کنفیگریشنز کے لیے ایک بلٹ ان سروس ہے - AWS Config۔ یہ سروس آپ کے AWS وسائل اور ان کی تشکیلات کا مسلسل آڈٹ فراہم کرتی ہے۔ آئیے ایک سادہ سی مثال لیتے ہیں: فرض کریں کہ آپ یہ یقینی بنانا چاہتے ہیں کہ آپ کے تمام سرورز پر صارف کے پاس ورڈز غیر فعال ہیں اور یہ رسائی صرف سرٹیفکیٹس کی بنیاد پر ہی ممکن ہے۔ AWS Config آپ کے تمام سرورز کے لیے اسے چیک کرنا آسان بناتا ہے۔ ایسی دوسری پالیسیاں ہیں جو آپ کے کلاؤڈ سرورز پر لاگو کی جا سکتی ہیں: "کوئی سرور پورٹ 22 استعمال نہیں کر سکتا"، "صرف منتظمین فائر وال کے قوانین کو تبدیل کر سکتے ہیں" یا "صرف صارف Ivashko نئے صارف اکاؤنٹس بنا سکتا ہے، اور وہ ایسا کر سکتا ہے یہ صرف منگل کو ہے۔ " 2016 کے موسم گرما میں، AWS Config سروس کو ترقی یافتہ پالیسیوں کی خلاف ورزیوں کا پتہ لگانے کے لیے خود کار طریقے سے بڑھایا گیا تھا۔ AWS کنفیگریشن رولز بنیادی طور پر آپ کے استعمال کردہ Amazon سروسز کے لیے کنفیگریشن کی مسلسل درخواستیں ہیں، جو متعلقہ پالیسیوں کی خلاف ورزی کی صورت میں ایونٹس تخلیق کرتی ہیں۔ مثال کے طور پر، اس بات کی تصدیق کے لیے وقتاً فوقتاً AWS Config استفسارات چلانے کی بجائے کہ ورچوئل سرور پر موجود تمام ڈسکیں انکرپٹڈ ہیں، AWS کنفیگ رولز کو سرور ڈسکوں کو مسلسل چیک کرنے کے لیے استعمال کیا جا سکتا ہے تاکہ یہ یقینی بنایا جا سکے کہ یہ شرط پوری ہوئی ہے۔ اور، سب سے اہم بات، اس اشاعت کے تناظر میں، کوئی بھی خلاف ورزی ایسے واقعات کو جنم دیتی ہے جن کا تجزیہ آپ کی انفارمیشن سیکیورٹی سروس کے ذریعے کیا جا سکتا ہے۔

AWS کے پاس روایتی کارپوریٹ انفارمیشن سیکیورٹی سلوشنز کے برابر بھی ہے، جو سیکیورٹی کے ایسے واقعات بھی پیدا کرتے ہیں جن کا آپ تجزیہ کر سکتے ہیں اور کرنا چاہیے:

• دخل اندازی کا پتہ لگانا - AWS GuardDuty
• انفارمیشن لیک کنٹرول - AWS Macie
• EDR (حالانکہ یہ کلاؤڈ میں اینڈ پوائنٹس کے بارے میں قدرے عجیب بات کرتا ہے) - AWS Cloudwatch + اوپن سورس osquery یا GRR حل
• نیٹ فلو تجزیہ - AWS Cloudwatch + AWS VPC فلو
• DNS تجزیہ - AWS Cloudwatch + AWS Route53
• AD - AWS ڈائریکٹری سروس
• اکاؤنٹ مینجمنٹ - AWS IAM
• SSO - AWS SSO
• سیکورٹی تجزیہ - AWS انسپکٹر
• کنفیگریشن مینجمنٹ - AWS Config
• WAF - AWS WAF.

میں ان تمام Amazon سروسز کی تفصیل سے وضاحت نہیں کروں گا جو معلومات کی حفاظت کے تناظر میں مفید ہو سکتی ہیں۔ اہم بات یہ سمجھنا ہے کہ یہ سبھی ایسے واقعات پیدا کر سکتے ہیں جن کا ہم معلومات کی حفاظت کے تناظر میں تجزیہ کر سکتے ہیں اور کرنا چاہیے، اس مقصد کے لیے ایمیزون کی خود ساختہ صلاحیتوں اور بیرونی حل دونوں کو استعمال کرتے ہوئے، مثال کے طور پر، SIEM، جو سیکیورٹی ایونٹس کو اپنے مانیٹرنگ سینٹر میں لے جائیں اور وہاں دیگر کلاؤڈ سروسز یا اندرونی انفراسٹرکچر، پیری میٹر یا موبائل ڈیوائسز کے ایونٹس کے ساتھ ان کا تجزیہ کریں۔

کسی بھی صورت میں، یہ سب ڈیٹا کے ذرائع سے شروع ہوتا ہے جو آپ کو معلومات کی حفاظت کے واقعات فراہم کرتے ہیں۔ ان ذرائع میں شامل ہیں، لیکن ان تک محدود نہیں ہیں:

• CloudTrail - API کا استعمال اور صارف کے اعمال
• قابل اعتماد مشیر - بہترین طریقوں کے خلاف سیکیورٹی چیک
• کنفیگ - انوینٹری اور اکاؤنٹس اور سروس کی ترتیبات کی ترتیب
• VPC فلو لاگز - ورچوئل انٹرفیس سے کنکشن
• IAM - شناخت اور تصدیق کی خدمت
• ELB رسائی لاگز - لوڈ بیلنسر
• انسپکٹر - درخواست کی کمزوریاں
• S3 - فائل اسٹوریج
• CloudWatch - ایپلیکیشن کی سرگرمی
• SNS ایک اطلاع کی خدمت ہے۔

Amazon، اپنی نسل کے لیے ایونٹ کے ذرائع اور ٹولز کی اس طرح کی ایک رینج پیش کرتے ہوئے، معلومات کی حفاظت کے تناظر میں جمع کیے گئے ڈیٹا کا تجزیہ کرنے کی صلاحیت میں بہت محدود ہے۔ آپ کو دستیاب لاگز کا آزادانہ طور پر مطالعہ کرنا پڑے گا، ان میں سمجھوتہ کے متعلقہ اشارے تلاش کرنا ہوں گے۔ AWS Security Hub، جسے Amazon نے حال ہی میں شروع کیا ہے، اس کا مقصد AWS کے لیے کلاؤڈ SIEM بن کر اس مسئلے کو حل کرنا ہے۔ لیکن اب تک یہ صرف اپنے سفر کے آغاز میں ہے اور یہ ان ذرائع کی تعداد کے لحاظ سے محدود ہے جن کے ساتھ یہ کام کرتا ہے اور خود ایمیزون کے فن تعمیر اور سبسکرپشنز کے ذریعہ قائم کردہ دیگر پابندیوں سے۔

مثال: Azure کی بنیاد پر IaaS میں انفارمیشن سیکیورٹی مانیٹرنگ

میں اس بارے میں ایک طویل بحث میں نہیں پڑنا چاہتا کہ کلاؤڈ فراہم کرنے والے تینوں (ایمیزون، مائیکروسافٹ یا گوگل) میں سے کون بہتر ہے (خاص طور پر چونکہ ان میں سے ہر ایک کی اب بھی اپنی مخصوص خصوصیات ہیں اور وہ اپنے مسائل کو حل کرنے کے لیے موزوں ہے)؛ آئیے انفارمیشن سیکیورٹی مانیٹرنگ کی صلاحیتوں پر توجہ مرکوز کریں جو یہ کھلاڑی فراہم کرتے ہیں۔ یہ تسلیم کرنا ضروری ہے کہ Amazon AWS اس سیگمنٹ میں سب سے پہلے میں سے ایک تھا اور اس وجہ سے اس نے اپنے معلوماتی حفاظتی افعال کے لحاظ سے سب سے آگے ترقی کی ہے (حالانکہ بہت سے لوگ تسلیم کرتے ہیں کہ ان کا استعمال کرنا مشکل ہے)۔ لیکن اس کا مطلب یہ نہیں ہے کہ ہم ان مواقع کو نظر انداز کر دیں گے جو مائیکروسافٹ اور گوگل ہمیں فراہم کرتے ہیں۔

مائیکروسافٹ کی مصنوعات کو ہمیشہ ان کے "کھلے پن" سے ممتاز کیا گیا ہے اور Azure میں بھی صورتحال ایسی ہی ہے۔ مثال کے طور پر، اگر AWS اور GCP ہمیشہ "جس چیز کی اجازت نہیں ہے وہ ممنوع ہے" کے تصور سے آگے بڑھتے ہیں، تو Azure کا نقطہ نظر بالکل برعکس ہے۔ مثال کے طور پر، کلاؤڈ میں ورچوئل نیٹ ورک اور اس میں ایک ورچوئل مشین بناتے وقت، تمام پورٹس اور پروٹوکول کھلے ہوتے ہیں اور بطور ڈیفالٹ اجازت دی جاتی ہے۔ لہذا، آپ کو مائیکروسافٹ سے کلاؤڈ میں رسائی کنٹرول سسٹم کے ابتدائی سیٹ اپ پر تھوڑی زیادہ محنت کرنا پڑے گی۔ اور یہ Azure کلاؤڈ میں سرگرمی کی نگرانی کے معاملے میں آپ پر مزید سخت تقاضے بھی عائد کرتا ہے۔

AWS کی ایک خاصیت اس حقیقت سے جڑی ہوئی ہے کہ جب آپ اپنے ورچوئل وسائل کی نگرانی کرتے ہیں، اگر وہ مختلف خطوں میں واقع ہیں، تو آپ کو تمام واقعات اور ان کے متفقہ تجزیے کو یکجا کرنے میں مشکلات پیش آتی ہیں، جن کو ختم کرنے کے لیے آپ کو مختلف چالوں کا سہارا لینا پڑتا ہے، جیسے AWS Lambda کے لیے اپنا کوڈ بنائیں جو واقعات کو خطوں کے درمیان منتقل کرے گا۔ Azure کو یہ مسئلہ نہیں ہے - اس کا ایکٹیویٹی لاگ میکانزم بغیر کسی پابندی کے پوری تنظیم میں تمام سرگرمیوں کو ٹریک کرتا ہے۔ یہی بات AWS سیکیورٹی ہب پر بھی لاگو ہوتی ہے، جسے حال ہی میں Amazon نے ایک ہی سیکیورٹی سینٹر کے اندر بہت سے سیکیورٹی افعال کو مستحکم کرنے کے لیے تیار کیا تھا، لیکن صرف اس کے علاقے کے اندر، جو، تاہم، روس کے لیے متعلقہ نہیں ہے۔ Azure کا اپنا سیکیورٹی سینٹر ہے، جو علاقائی پابندیوں کا پابند نہیں ہے، جو کلاؤڈ پلیٹ فارم کی تمام حفاظتی خصوصیات تک رسائی فراہم کرتا ہے۔ مزید یہ کہ، مختلف مقامی ٹیموں کے لیے یہ اپنی حفاظتی صلاحیتوں کا اپنا سیٹ فراہم کر سکتا ہے، بشمول ان کے زیر انتظام سیکیورٹی ایونٹس۔ AWS Security Hub ابھی بھی Azure Security Center جیسا بننے کے راستے پر ہے۔ لیکن یہ مرہم میں ایک مکھی شامل کرنے کے قابل ہے - آپ Azure سے بہت کچھ نچوڑ سکتے ہیں جو پہلے AWS میں بیان کیا گیا تھا، لیکن یہ سب سے زیادہ آسانی سے صرف Azure AD، Azure Monitor اور Azure Security Center کے لیے کیا جاتا ہے۔ دیگر تمام Azure سیکیورٹی میکانزم، بشمول سیکیورٹی ایونٹ کے تجزیہ، ابھی تک سب سے آسان طریقے سے منظم نہیں ہوئے ہیں۔ اس مسئلے کو جزوی طور پر API کے ذریعے حل کیا گیا ہے، جو کہ تمام Microsoft Azure سروسز پر محیط ہے، لیکن اس کے لیے آپ کی طرف سے اپنے کلاؤڈ کو اپنے SOC کے ساتھ مربوط کرنے اور اہل ماہرین کی موجودگی کی ضرورت ہوگی (درحقیقت، بالکل اسی طرح جیسے کسی دوسرے SIEM کے ساتھ کام کرتا ہے۔ کلاؤڈ APIs)۔ کچھ SIEMs، جن پر بعد میں بات کی جائے گی، پہلے سے ہی Azure کو سپورٹ کرتے ہیں اور اس کی نگرانی کے کام کو خودکار کر سکتے ہیں، لیکن اس کی اپنی مشکلات بھی ہیں - وہ سبھی وہ تمام لاگز جمع نہیں کر سکتے جو Azure کے پاس ہیں۔

Azure میں ایونٹ کلیکشن اور مانیٹرنگ Azure Monitor سروس کا استعمال کرتے ہوئے فراہم کی جاتی ہے، جو Microsoft کلاؤڈ اور اس کے وسائل - Git repositories، کنٹینرز، ورچوئل مشینیں، ایپلی کیشنز وغیرہ میں ڈیٹا اکٹھا کرنے، ذخیرہ کرنے اور تجزیہ کرنے کا ایک اہم ٹول ہے۔ Azure Monitor کے ذریعے جمع کیے گئے تمام ڈیٹا کو دو زمروں میں تقسیم کیا گیا ہے - میٹرکس، جو حقیقی وقت میں جمع کیے گئے ہیں اور Azure کلاؤڈ کے کلیدی کارکردگی کے اشارے، اور لاگز کو بیان کرتے ہیں، جس میں Azure وسائل اور خدمات کی سرگرمی کے کچھ پہلوؤں کو نمایاں کرنے والے ریکارڈز میں منظم ڈیٹا پر مشتمل ہے۔ اس کے علاوہ، ڈیٹا کلیکٹر API کا استعمال کرتے ہوئے، Azure مانیٹر سروس اپنے نگرانی کے منظرنامے بنانے کے لیے کسی بھی REST ذریعہ سے ڈیٹا اکٹھا کر سکتی ہے۔

یہاں کچھ سیکیورٹی ایونٹ کے ذرائع ہیں جو Azure آپ کو پیش کرتا ہے اور آپ Azure Portal، CLI، PowerShell، یا REST API (اور کچھ صرف Azure Monitor/Insight API کے ذریعے) تک رسائی حاصل کر سکتے ہیں:

• ایکٹیویٹی لاگز - یہ لاگ کلاؤڈ ریسورسز پر کسی تحریری آپریشن (PUT، POST، DELETE) سے متعلق "کون،" "کیا" اور "کب" کے کلاسک سوالات کا جواب دیتا ہے۔ پڑھنے تک رسائی (GET) سے متعلق واقعات اس لاگ میں شامل نہیں ہیں، جیسے کہ بہت سے دوسرے۔
• تشخیصی لاگز - آپ کے سبسکرپشن میں شامل کسی خاص وسائل کے ساتھ آپریشنز کے ڈیٹا پر مشتمل ہے۔
• Azure AD رپورٹنگ - گروپ اور صارف کے انتظام سے متعلق صارف کی سرگرمی اور سسٹم کی سرگرمی دونوں پر مشتمل ہے۔
• Windows Event Log اور Linux Syslog - کلاؤڈ میں میزبانی کی گئی ورچوئل مشینوں کے ایونٹس پر مشتمل ہے۔
• میٹرکس - آپ کی کلاؤڈ سروسز اور وسائل کی کارکردگی اور صحت کی صورتحال کے بارے میں ٹیلی میٹری پر مشتمل ہے۔ ہر منٹ کی پیمائش اور ذخیرہ. 30 دنوں کے اندر.
• نیٹ ورک سیکیورٹی گروپ فلو لاگز - نیٹ ورک واچر سروس اور نیٹ ورک کی سطح پر وسائل کی نگرانی کا استعمال کرتے ہوئے جمع کردہ نیٹ ورک سیکیورٹی ایونٹس پر ڈیٹا پر مشتمل ہے۔
• اسٹوریج لاگز - اسٹوریج کی سہولیات تک رسائی سے متعلق واقعات پر مشتمل ہے۔

نگرانی کے لیے، آپ بیرونی SIEMs یا بلٹ ان Azure Monitor اور اس کی ایکسٹینشن استعمال کر سکتے ہیں۔ ہم انفارمیشن سیکیورٹی ایونٹ مینجمنٹ سسٹمز کے بارے میں بعد میں بات کریں گے، لیکن ابھی کے لیے دیکھتے ہیں کہ Azure خود ہمیں سیکیورٹی کے تناظر میں ڈیٹا کے تجزیہ کے لیے کیا پیش کرتا ہے۔ Azure Monitor میں سیکیورٹی سے متعلق ہر چیز کے لیے مرکزی اسکرین لاگ اینالیٹکس سیکیورٹی اور آڈٹ ڈیش بورڈ ہے (مفت ورژن صرف ایک ہفتے کے لیے ایونٹ اسٹوریج کی محدود مقدار کو سپورٹ کرتا ہے)۔ اس ڈیش بورڈ کو 5 اہم شعبوں میں تقسیم کیا گیا ہے جو آپ کے استعمال کردہ کلاؤڈ ماحول میں کیا ہو رہا ہے اس کے خلاصے کے اعدادوشمار کا تصور کرتے ہیں:

• سیکیورٹی ڈومینز - معلومات کی حفاظت سے متعلق اہم مقداری اشارے - واقعات کی تعداد، سمجھوتہ شدہ نوڈس کی تعداد، غیر پیچ شدہ نوڈس، نیٹ ورک سیکیورٹی ایونٹس وغیرہ۔
• قابل ذکر مسائل - فعال معلومات کے تحفظ کے مسائل کی تعداد اور اہمیت کو ظاہر کرتا ہے۔
• پتہ لگانے - آپ کے خلاف استعمال ہونے والے حملوں کے نمونے دکھاتا ہے۔
• تھریٹ انٹیلی جنس - بیرونی نوڈس پر جغرافیائی معلومات دکھاتا ہے جو آپ پر حملہ کر رہے ہیں۔
• عام سیکیورٹی سوالات - عام سوالات جو آپ کو اپنی معلومات کی حفاظت کی بہتر نگرانی کرنے میں مدد کریں گے۔

Azure مانیٹر ایکسٹینشنز میں Azure Key Vault (کلاؤڈ میں کرپٹوگرافک کیز کا تحفظ)، مالویئر اسسمنٹ (ورچوئل مشینوں پر نقصان دہ کوڈ کے خلاف تحفظ کا تجزیہ)، Azure ایپلیکیشن گیٹ وے تجزیات (دیگر چیزوں کے علاوہ، کلاؤڈ فائر وال لاگز کا تجزیہ)، وغیرہ شامل ہیں۔ . یہ ٹولز، واقعات کی پروسیسنگ کے لیے کچھ اصولوں کے ساتھ افزودہ، آپ کو کلاؤڈ سروسز کی سرگرمی کے مختلف پہلوؤں کو دیکھنے کی اجازت دیتے ہیں، بشمول سیکیورٹی، اور آپریشن سے کچھ انحرافات کی نشاندہی کرتے ہیں۔ لیکن، جیسا کہ اکثر ہوتا ہے، کسی بھی اضافی فعالیت کے لیے متعلقہ ادا شدہ سبسکرپشن کی ضرورت ہوتی ہے، جس کے لیے آپ سے متعلقہ مالی سرمایہ کاری کی ضرورت ہوتی ہے، جس کی آپ کو پہلے سے منصوبہ بندی کرنے کی ضرورت ہوتی ہے۔

Azure میں خطرے کی نگرانی کی بہت سی بلٹ ان صلاحیتیں ہیں جو Azure AD، Azure Monitor، اور Azure Security Center میں ضم ہیں۔ ان میں، مثال کے طور پر، معلوم بدنیتی پر مبنی آئی پی کے ساتھ ورچوئل مشینوں کے تعامل کا پتہ لگانا (مائیکروسافٹ کی جانب سے تھریٹ انٹیلی جنس سروسز کے ساتھ انضمام کی موجودگی کی وجہ سے)، کلاؤڈ میں میزبانی کی گئی ورچوئل مشینوں سے الارم وصول کرکے کلاؤڈ انفراسٹرکچر میں میلویئر کا پتہ لگانا، پاس ورڈ۔ ورچوئل مشینوں پر حملے کا اندازہ لگانا، صارف کی شناخت کے نظام کی ترتیب میں کمزوریاں، گمنام یا متاثرہ نوڈس سے سسٹم میں لاگ ان ہونا، اکاؤنٹ کا لیک ہونا، غیر معمولی جگہوں سے سسٹم میں لاگ ان ہونا وغیرہ۔ Azure آج ان چند کلاؤڈ فراہم کنندگان میں سے ایک ہے جو جمع کردہ معلومات کے حفاظتی واقعات کو تقویت دینے کے لیے آپ کو بلٹ ان تھریٹ انٹیلی جنس صلاحیتیں فراہم کرتا ہے۔

جیسا کہ اوپر ذکر کیا گیا ہے، سیکیورٹی کی فعالیت اور، اس کے نتیجے میں، اس کے ذریعے پیدا ہونے والے سیکیورٹی ایونٹس تمام صارفین کے لیے یکساں طور پر دستیاب نہیں ہیں، لیکن اس کے لیے ایک مخصوص سبسکرپشن کی ضرورت ہوتی ہے جس میں آپ کی ضرورت کی فعالیت شامل ہوتی ہے، جو انفارمیشن سیکیورٹی مانیٹرنگ کے لیے مناسب ایونٹس تیار کرتی ہے۔ مثال کے طور پر، اکاؤنٹس میں بے ضابطگیوں کی نگرانی کے لیے پچھلے پیراگراف میں بیان کیے گئے کچھ فنکشنز صرف Azure AD سروس کے P2 پریمیم لائسنس میں دستیاب ہیں۔ اس کے بغیر، آپ کو، جیسا کہ AWS کے معاملے میں، جمع کیے گئے سیکیورٹی ایونٹس کا "دستی طور پر" تجزیہ کرنا پڑے گا۔ اور، یہ بھی، Azure AD لائسنس کی قسم پر منحصر ہے، تمام واقعات تجزیہ کے لیے دستیاب نہیں ہوں گے۔

Azure پورٹل پر، آپ اپنی دلچسپی کے نوشتہ جات کے لیے تلاش کے دونوں استفسارات کا نظم کر سکتے ہیں اور اہم معلوماتی حفاظتی اشاریوں کو دیکھنے کے لیے ڈیش بورڈ سیٹ کر سکتے ہیں۔ اس کے علاوہ، وہاں آپ Azure مانیٹر ایکسٹینشنز کو منتخب کر سکتے ہیں، جو آپ کو Azure مانیٹر لاگز کی فعالیت کو بڑھانے اور سیکیورٹی کے نقطہ نظر سے واقعات کا گہرا تجزیہ حاصل کرنے کی اجازت دیتے ہیں۔

اگر آپ کو نہ صرف لاگز کے ساتھ کام کرنے کی صلاحیت بلکہ اپنے Azure کلاؤڈ پلیٹ فارم کے لیے ایک جامع سیکیورٹی سینٹر کی ضرورت ہے، جس میں انفارمیشن سیکیورٹی پالیسی مینجمنٹ بھی شامل ہے، تو آپ Azure سیکیورٹی سینٹر کے ساتھ کام کرنے کی ضرورت کے بارے میں بات کر سکتے ہیں، جن میں سے زیادہ تر مفید افعال ہیں۔ کچھ رقم کے لیے دستیاب ہیں، مثال کے طور پر خطرے کا پتہ لگانا، Azure سے باہر نگرانی، تعمیل کی تشخیص وغیرہ۔ (مفت ورژن میں، آپ کو صرف حفاظتی تشخیص اور شناخت شدہ مسائل کو ختم کرنے کے لیے سفارشات تک رسائی حاصل ہے)۔ یہ تمام حفاظتی امور کو ایک جگہ پر اکٹھا کرتا ہے۔ درحقیقت، ہم Azure Monitor سے آپ کو فراہم کردہ معلومات کے تحفظ کے اعلیٰ درجے کے بارے میں بات کر سکتے ہیں، کیونکہ اس صورت میں آپ کی کلاؤڈ فیکٹری میں جمع کردہ ڈیٹا کو بہت سے ذرائع، جیسے Azure، Office 365، Microsoft CRM آن لائن، Microsoft Dynamics AX کا استعمال کرتے ہوئے افزودہ کیا جاتا ہے۔ , outlook .com، MSN.com، Microsoft Digital Crimes Unit (DCU) اور Microsoft Security Response Center (MSRC)، جس پر مختلف جدید ترین مشین لرننگ اور طرز عمل کے تجزیات کے الگورتھم لگائے گئے ہیں، جو بالآخر خطرات کا پتہ لگانے اور ان کا جواب دینے کی کارکردگی کو بہتر بنائیں گے۔ .

Azure کا اپنا SIEM بھی ہے - یہ 2019 کے آغاز میں نمودار ہوا۔ یہ Azure Sentinel ہے، جو Azure Monitor کے ڈیٹا پر انحصار کرتا ہے اور اس کے ساتھ ضم بھی ہو سکتا ہے۔ بیرونی حفاظتی حل (مثال کے طور پر، NGFW یا WAF)، جن کی فہرست مسلسل بڑھ رہی ہے۔ اس کے علاوہ، مائیکروسافٹ گراف سیکیورٹی API کے انضمام کے ذریعے، آپ اپنے Threat Intelligence فیڈ کو Sentinel سے منسلک کرنے کی صلاحیت رکھتے ہیں، جو آپ کے Azure کلاؤڈ میں واقعات کا تجزیہ کرنے کی صلاحیتوں کو مزید تقویت دیتا ہے۔ یہ دلیل دی جا سکتی ہے کہ Azure Sentinel پہلا "آبائی" SIEM ہے جو کلاؤڈ فراہم کرنے والوں سے ظاہر ہوا (وہی Splunk یا ELK، جو کلاؤڈ میں ہوسٹ کیا جا سکتا ہے، مثال کے طور پر، AWS، اب بھی روایتی کلاؤڈ سروس فراہم کرنے والوں کے ذریعے تیار نہیں کیا گیا ہے)۔ Azure Sentinel اور Security Center کو Azure کلاؤڈ کے لیے SOC کہا جا سکتا ہے اور اگر آپ کے پاس اب کوئی انفراسٹرکچر نہیں ہے اور آپ نے اپنے تمام کمپیوٹنگ وسائل کو کلاؤڈ پر منتقل کر دیا ہے اور یہ Microsoft کلاؤڈ Azure ہو گا تو یہ ان تک محدود ہو سکتے ہیں (کچھ تحفظات کے ساتھ)۔

لیکن چونکہ Azure کی بلٹ ان صلاحیتیں (چاہے آپ کے پاس سینٹینیل کی رکنیت ہو) اکثر معلومات کی حفاظت کی نگرانی اور اس عمل کو سیکیورٹی کے دیگر ذرائع (کلاؤڈ اور اندرونی دونوں) کے ساتھ مربوط کرنے کے مقاصد کے لیے کافی نہیں ہوتی ہیں، اس لیے ایک جمع کردہ ڈیٹا کو بیرونی سسٹمز میں ایکسپورٹ کرنے کی ضرورت ہے، جس میں SIEM شامل ہو سکتا ہے۔ یہ API کا استعمال کرتے ہوئے اور خصوصی ایکسٹینشنز کا استعمال کرتے ہوئے کیا جاتا ہے، جو فی الحال سرکاری طور پر صرف درج ذیل SIEMs کے لیے دستیاب ہیں - Splunk (Azure Monitor Add-on for Splunk)، IBM QRadar (Microsoft Azure DSM)، SumoLogic، ArcSight اور ELK۔ کچھ عرصہ پہلے تک، اس طرح کے اور بھی SIEMs موجود تھے، لیکن 1 جون، 2019 سے، Microsoft نے Azure Log Integration Tool (AzLog) کی حمایت کرنا بند کر دیا، جو Azure کے وجود کے آغاز میں اور لاگز (Azure) کے ساتھ کام کرنے کے معمول کے معیار کی عدم موجودگی میں مانیٹر ابھی تک موجود نہیں تھا) نے مائیکروسافٹ کلاؤڈ کے ساتھ بیرونی SIEM کو ضم کرنا آسان بنا دیا۔ اب صورتحال بدل گئی ہے اور مائیکروسافٹ نے Azure Event Hub پلیٹ فارم کو دوسرے SIEMs کے لیے اہم انٹیگریشن ٹول کے طور پر تجویز کیا ہے۔ بہت سے لوگ پہلے ہی اس طرح کے انضمام کو لاگو کر چکے ہیں، لیکن ہوشیار رہیں - وہ تمام Azure لاگز نہیں پکڑ سکتے ہیں، لیکن صرف کچھ (اپنے SIEM کے لئے دستاویزات دیکھیں)۔

Azure میں ایک مختصر سیر کا اختتام کرتے ہوئے، میں اس کلاؤڈ سروس کے بارے میں ایک عمومی سفارش دینا چاہوں گا - Azure میں انفارمیشن سیکیورٹی مانیٹرنگ کے افعال کے بارے میں کچھ کہنے سے پہلے، آپ کو ان کو بہت احتیاط سے ترتیب دینا چاہیے اور جانچنا چاہیے کہ وہ دستاویزات میں لکھے ہوئے کے مطابق کام کرتے ہیں اور جیسا کہ کنسلٹنٹس نے آپ کو مائیکروسافٹ بتایا تھا (اور Azure فنکشنز کی فعالیت پر ان کے خیالات مختلف ہو سکتے ہیں)۔ اگر آپ کے پاس مالی وسائل ہیں، تو آپ Azure سے معلومات کی حفاظت کی نگرانی کے سلسلے میں بہت سی مفید معلومات کو نچوڑ سکتے ہیں۔ اگر آپ کے وسائل محدود ہیں، تو، AWS کے معاملے کی طرح، آپ کو صرف اپنی طاقت اور اس خام ڈیٹا پر انحصار کرنا پڑے گا جو Azure Monitor آپ کو فراہم کرتا ہے۔ اور یاد رکھیں کہ بہت سے مانیٹرنگ فنکشنز پر پیسہ خرچ ہوتا ہے اور یہ بہتر ہے کہ آپ قیمتوں کی پالیسی سے پہلے ہی واقف ہو جائیں۔ مثال کے طور پر، آپ مفت میں 31 دن کا ڈیٹا زیادہ سے زیادہ 5 GB فی گاہک تک ذخیرہ کر سکتے ہیں - ان قدروں سے تجاوز کرنے پر آپ کو اضافی رقم نکالنے کی ضرورت ہوگی (صارفین سے ہر اضافی GB ذخیرہ کرنے کے لیے تقریباً $2+ اور اس کے لیے $0,1 ہر اضافی مہینے میں 1 GB ذخیرہ کرنا)۔ ایپلی کیشن ٹیلی میٹری اور میٹرکس کے ساتھ کام کرنے کے لیے اضافی فنڈز کی بھی ضرورت پڑ سکتی ہے، نیز الرٹس اور اطلاعات کے ساتھ کام کرنا (ایک مخصوص حد مفت میں دستیاب ہے، جو آپ کی ضروریات کے لیے کافی نہیں ہو سکتی ہے)۔

مثال: گوگل کلاؤڈ پلیٹ فارم پر مبنی IaaS میں انفارمیشن سیکیورٹی مانیٹرنگ

گوگل کلاؤڈ پلیٹ فارم AWS اور Azure کے مقابلے میں ایک نوجوان کی طرح لگتا ہے، لیکن یہ جزوی طور پر اچھا ہے۔ AWS کے برعکس، جس نے اپنی صلاحیتوں کو بڑھایا، بشمول سیکورٹی والے، آہستہ آہستہ، مرکزیت کے ساتھ مسائل کا سامنا کرنا پڑتا ہے۔ GCP، Azure کی طرح، مرکزی طور پر بہت بہتر انتظام کیا جاتا ہے، جو پورے انٹرپرائز میں غلطیوں اور نفاذ کے وقت کو کم کرتا ہے۔ سیکورٹی کے نقطہ نظر سے، GCP، عجیب طور پر کافی، AWS اور Azure کے درمیان ہے۔ اس کے پاس پوری تنظیم کے لیے ایک ہی ایونٹ کی رجسٹریشن بھی ہے، لیکن یہ نامکمل ہے۔ کچھ فنکشنز اب بھی بیٹا موڈ میں ہیں، لیکن آہستہ آہستہ اس کمی کو ختم کیا جانا چاہیے اور GCP معلومات کی حفاظت کی نگرانی کے لحاظ سے ایک زیادہ پختہ پلیٹ فارم بن جائے گا۔

GCP میں ایونٹس کو لاگ کرنے کا اہم ٹول Stackdriver Logging (Azure Monitor کی طرح) ہے، جو آپ کو اپنے پورے کلاؤڈ انفراسٹرکچر (نیز 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"
}

ان لاگز تک رسائی کئی طریقوں سے ممکن ہے (جس طرح پہلے Azure اور AWS پر بات کی گئی تھی) - Log Viewer انٹرفیس کے ذریعے، API کے ذریعے، Google Cloud SDK کے ذریعے، یا اپنے پروجیکٹ کے سرگرمی صفحہ کے ذریعے جس کے لیے آپ واقعات میں دلچسپی رکھتے ہیں۔ اسی طرح، انہیں اضافی تجزیہ کے لیے بیرونی حلوں میں برآمد کیا جا سکتا ہے۔ مؤخر الذکر لاگز کو BigQuery یا Cloud Pub/Sub سٹوریج میں برآمد کر کے کیا جاتا ہے۔

Stackdriver لاگنگ کے علاوہ، GCP پلیٹ فارم Stackdriver مانیٹرنگ کی فعالیت بھی پیش کرتا ہے، جو آپ کو کلاؤڈ سروسز اور ایپلیکیشنز کے کلیدی میٹرکس (کارکردگی، MTBF، مجموعی صحت، وغیرہ) کی نگرانی کرنے کی اجازت دیتا ہے۔ پروسیس شدہ اور بصری ڈیٹا آپ کے کلاؤڈ انفراسٹرکچر میں مسائل کو تلاش کرنا آسان بنا سکتا ہے، بشمول سیکیورٹی کے تناظر میں۔ لیکن یہ واضح رہے کہ معلومات کی حفاظت کے تناظر میں یہ فعالیت زیادہ بھرپور نہیں ہوگی، کیوں کہ آج GCP کے پاس AWS GuardDuty کا ینالاگ نہیں ہے اور وہ تمام رجسٹرڈ ایونٹس میں سے برے کی شناخت نہیں کر سکتا (گوگل نے ایونٹ تھریٹ ڈیٹیکشن تیار کیا ہے، لیکن یہ ابھی بھی بیٹا میں ترقی کے مراحل میں ہے اور اس کی افادیت کے بارے میں بات کرنا بہت جلد ہے)۔ Stackdriver مانیٹرنگ کو بے ضابطگیوں کا پتہ لگانے کے لیے ایک نظام کے طور پر استعمال کیا جا سکتا ہے، جس کے بعد ان کی موجودگی کی وجوہات تلاش کرنے کے لیے چھان بین کی جائے گی۔ لیکن مارکیٹ میں جی سی پی انفارمیشن سیکیورٹی کے شعبے میں اہل افراد کی کمی کے پیش نظر، فی الحال یہ کام مشکل نظر آتا ہے۔

کچھ معلوماتی حفاظتی ماڈیولز کی فہرست دینا بھی قابل قدر ہے جو آپ کے GCP کلاؤڈ میں استعمال کیے جاسکتے ہیں، اور جو AWS کی پیشکش سے ملتے جلتے ہیں:

• کلاؤڈ سیکیورٹی کمانڈ سینٹر AWS سیکیورٹی ہب اور Azure سیکیورٹی سینٹر کا ایک اینالاگ ہے۔
• Cloud DLP - 90 سے زیادہ پہلے سے طے شدہ درجہ بندی کی پالیسیوں کا استعمال کرتے ہوئے کلاؤڈ میں ہوسٹ کردہ ڈیٹا کی خودکار دریافت اور ترمیم (جیسے ماسکنگ)۔
• Cloud Scanner App Engine، Compute Engine اور Google Kubernetes میں معلوم کمزوریوں (XSS، Flash Injection، unpatched libraries، وغیرہ) کے لیے ایک سکینر ہے۔
• کلاؤڈ IAM - تمام GCP وسائل تک رسائی کو کنٹرول کریں۔
• Cloud Identity - ایک کنسول سے GCP صارف، ڈیوائس اور ایپلیکیشن اکاؤنٹس کا نظم کریں۔
• کلاؤڈ HSM - کرپٹوگرافک کیز کا تحفظ۔
• کلاؤڈ کی مینجمنٹ سروس - جی سی پی میں کرپٹوگرافک کیز کا انتظام۔
• VPC سروس کنٹرول - اپنے GCP وسائل کو لیک ہونے سے بچانے کے لیے ایک محفوظ دائرہ بنائیں۔
• ٹائٹن سیکیورٹی کلید - فشنگ سے تحفظ۔

ان میں سے بہت سے ماڈیولز سیکیورٹی ایونٹس تیار کرتے ہیں جنہیں تجزیہ کے لیے BigQuery اسٹوریج میں بھیجا جا سکتا ہے یا SIEM سمیت دیگر سسٹمز کو ایکسپورٹ کیا جا سکتا ہے۔ جیسا کہ اوپر ذکر کیا گیا ہے، GCP ایک فعال طور پر ترقی پذیر پلیٹ فارم ہے اور گوگل اب اپنے پلیٹ فارم کے لیے متعدد نئے انفارمیشن سیکیورٹی ماڈیولز تیار کر رہا ہے۔ ان میں ایونٹ تھریٹ ڈیٹیکشن (اب بیٹا میں دستیاب ہے) ہیں، جو غیر مجاز سرگرمی کے نشانات کی تلاش میں Stackdriver لاگز کو اسکین کرتا ہے (AWS میں GuardDuty کے مشابہ)، یا پالیسی انٹیلی جنس (الفا میں دستیاب)، جو آپ کو ذہین پالیسیاں تیار کرنے کی اجازت دے گی۔ GCP وسائل تک رسائی۔

میں نے مقبول کلاؤڈ پلیٹ فارمز میں بلٹ ان نگرانی کی صلاحیتوں کا ایک مختصر جائزہ لیا۔ لیکن کیا آپ کے پاس ایسے ماہرین ہیں جو "را" IaaS فراہم کنندہ لاگز کے ساتھ کام کرنے کے قابل ہیں (ہر کوئی AWS یا Azure یا Google کی جدید صلاحیتوں کو خریدنے کے لیے تیار نہیں ہے)؟ اس کے علاوہ، بہت سے لوگ اس کہاوت سے واقف ہیں "ٹرسٹ، لیکن تصدیق کریں" جو کہ سیکورٹی کے میدان میں پہلے سے کہیں زیادہ سچ ہے۔ آپ کو کلاؤڈ فراہم کنندہ کی بلٹ ان صلاحیتوں پر کتنا بھروسہ ہے جو آپ کو انفارمیشن سیکیورٹی ایونٹس بھیجتی ہیں؟ وہ معلومات کی حفاظت پر کس حد تک توجہ دیتے ہیں؟

بعض اوقات یہ اوورلے کلاؤڈ انفراسٹرکچر مانیٹرنگ سلوشنز کو دیکھنے کے قابل ہوتا ہے جو بلٹ ان کلاؤڈ سیکیورٹی کی تکمیل کر سکتے ہیں، اور بعض اوقات ایسے حل ہی آپ کے ڈیٹا اور کلاؤڈ میں ہوسٹ کردہ ایپلیکیشنز کی سیکیورٹی کے بارے میں بصیرت حاصل کرنے کا واحد آپشن ہوتے ہیں۔ اس کے علاوہ، وہ زیادہ آسان ہیں، کیونکہ وہ مختلف کلاؤڈ فراہم کنندگان سے مختلف کلاؤڈ سروسز کے ذریعے تیار کردہ ضروری لاگز کا تجزیہ کرنے کے تمام کام انجام دیتے ہیں۔ اس طرح کے اوورلے حل کی ایک مثال Cisco Stealthwatch Cloud ہے، جو ایک ہی کام پر مرکوز ہے - بادل کے ماحول میں معلومات کی حفاظت کی بے ضابطگیوں کی نگرانی، بشمول Amazon AWS، Microsoft Azure اور Google Cloud Platform، بلکہ نجی کلاؤڈز بھی۔

مثال: اسٹیلتھ واچ کلاؤڈ کا استعمال کرتے ہوئے انفارمیشن سیکیورٹی مانیٹرنگ

AWS ایک لچکدار کمپیوٹنگ پلیٹ فارم مہیا کرتا ہے، لیکن یہ لچک کمپنیوں کے لیے ایسی غلطیاں کرنا آسان بناتی ہے جو سیکیورٹی کے مسائل کا باعث بنتی ہیں۔ اور مشترکہ انفارمیشن سیکیورٹی ماڈل صرف اس میں حصہ ڈالتا ہے۔ نامعلوم کمزوریوں کے ساتھ کلاؤڈ میں سافٹ ویئر چلانا (معلوم افراد کا مقابلہ کیا جا سکتا ہے، مثال کے طور پر، AWS انسپکٹر یا GCP کلاؤڈ سکینر)، کمزور پاس ورڈ، غلط کنفیگریشن، اندرونی، وغیرہ۔ اور یہ سب کلاؤڈ ریسورسز کے رویے سے ظاہر ہوتا ہے، جس کی نگرانی سسکو سٹیلتھ واچ کلاؤڈ کے ذریعے کی جا سکتی ہے، جو کہ انفارمیشن سیکیورٹی مانیٹرنگ اور اٹیک ڈیٹیکشن سسٹم ہے۔ عوامی اور نجی بادل۔

سسکو سٹیلتھ واچ کلاؤڈ کی ایک اہم خصوصیت اداروں کو ماڈل بنانے کی صلاحیت ہے۔ اس کے ساتھ، آپ اپنے کلاؤڈ وسائل میں سے ہر ایک کا سافٹ ویئر ماڈل (یعنی قریب قریب ریئل ٹائم سمولیشن) بنا سکتے ہیں (اس سے کوئی فرق نہیں پڑتا کہ یہ AWS، Azure، GCP، یا کچھ اور ہے)۔ ان میں سرورز اور صارفین شامل ہو سکتے ہیں، نیز آپ کے کلاؤڈ ماحول کے لیے مخصوص وسائل کی اقسام، جیسے سیکیورٹی گروپس اور آٹو اسکیل گروپس۔ یہ ماڈل کلاؤڈ سروسز کے ذریعہ فراہم کردہ ساختی ڈیٹا اسٹریمز کو بطور ان پٹ استعمال کرتے ہیں۔ مثال کے طور پر، AWS کے لیے یہ ہوں گے VPC Flow Logs، AWS CloudTrail، AWS CloudWatch، AWS Config، AWS Inspector، AWS Lambda، اور AWS IAM۔ ہستی ماڈلنگ آپ کے کسی بھی وسائل کے کردار اور رویے کو خود بخود دریافت کرتی ہے (آپ کلاؤڈ کی تمام سرگرمیوں کی پروفائلنگ کے بارے میں بات کر سکتے ہیں)۔ ان کرداروں میں Android یا Apple موبائل ڈیوائس، Citrix PVS سرور، RDP سرور، میل گیٹ وے، VoIP کلائنٹ، ٹرمینل سرور، ڈومین کنٹرولر وغیرہ شامل ہیں۔ اس کے بعد یہ ان کے رویے کی مسلسل نگرانی کرتا ہے تاکہ اس بات کا تعین کیا جا سکے کہ کب پرخطر یا حفاظت کے لیے خطرناک رویہ پیش آتا ہے۔ آپ پاس ورڈ کا اندازہ لگانا، DDoS حملے، ڈیٹا لیک، غیر قانونی ریموٹ رسائی، بدنیتی پر مبنی کوڈ کی سرگرمی، کمزوری اسکیننگ اور دیگر خطرات کی شناخت کر سکتے ہیں۔ مثال کے طور پر، ایس ایس ایچ کے ذریعے آپ کی تنظیم (جنوبی کوریا) کے لیے ایک غیر معمولی ملک سے Kubernetes کلسٹر تک ریموٹ رسائی کی کوشش کا پتہ لگانا ایسا لگتا ہے:

اور پوسٹگریس ڈیٹا بیس سے کسی ایسے ملک میں معلومات کا مبینہ لیک ہونا جس کے ساتھ ہمیں پہلے کسی بات چیت کا سامنا نہیں کرنا پڑا اس طرح لگتا ہے:

آخر میں، یہ وہی ہے جو چین اور انڈونیشیا کی طرف سے بیرونی ریموٹ ڈیوائس سے بہت سی ناکام SSH کوششیں اس طرح نظر آتی ہیں:

یا، فرض کریں کہ VPC میں سرور کی مثال، پالیسی کے مطابق، کبھی بھی دور دراز لاگ ان کی منزل نہیں بنتی ہے۔ آئیے مزید مان لیں کہ اس کمپیوٹر کو فائر وال رولز کی پالیسی میں غلط تبدیلی کی وجہ سے ریموٹ لاگ ان کا تجربہ ہوا ہے۔ ہستی ماڈلنگ کی خصوصیت اس سرگرمی ("غیر معمولی ریموٹ رسائی") کا قریب قریب حقیقی وقت میں پتہ لگائے گی اور اس کی اطلاع دے گی اور مخصوص AWS CloudTrail، Azure Monitor، یا GCP Stackdriver Logging API کال (بشمول صارف نام، تاریخ اور وقت، دیگر تفصیلات کے ساتھ) کی طرف اشارہ کرے گی۔ جس نے ITU اصول میں تبدیلی کا اشارہ کیا۔ اور پھر اس معلومات کو تجزیہ کے لیے SIEM کو بھیجا جا سکتا ہے۔

اسی طرح کی صلاحیتیں Cisco Stealthwatch Cloud کے تعاون سے کسی بھی کلاؤڈ ماحول کے لیے لاگو کی جاتی ہیں:

ہستی ماڈلنگ سیکورٹی آٹومیشن کی ایک منفرد شکل ہے جو آپ کے لوگوں، عمل یا ٹیکنالوجی کے ساتھ پہلے سے نامعلوم مسئلہ کو ننگا کر سکتی ہے۔ مثال کے طور پر، یہ آپ کو دیگر چیزوں کے علاوہ، حفاظتی مسائل کا پتہ لگانے کی اجازت دیتا ہے جیسے:

• کیا کسی نے ہمارے استعمال کردہ سافٹ ویئر میں بیک ڈور دریافت کیا ہے؟
• کیا ہمارے کلاؤڈ میں کوئی تھرڈ پارٹی سافٹ ویئر یا ڈیوائس ہے؟
• کیا مجاز صارف مراعات کا غلط استعمال کر رہا ہے؟
• کیا کوئی ترتیب کی خرابی تھی جس نے ریموٹ رسائی یا وسائل کے دوسرے غیر ارادی استعمال کی اجازت دی؟
• کیا ہمارے سرورز سے ڈیٹا لیک ہوا ہے؟
• کیا کوئی غیر معمولی جغرافیائی مقام سے ہم سے رابطہ قائم کرنے کی کوشش کر رہا تھا؟
• کیا ہمارا کلاؤڈ نقصان دہ کوڈ سے متاثر ہے؟

انفارمیشن سیکیورٹی ایونٹ کا پتہ چلا اس سے متعلقہ ٹکٹ کی شکل میں Slack، Cisco Spark، PagerDuty واقعہ کے انتظام کے نظام کو بھیجا جا سکتا ہے، اور Splunk یا ELK سمیت مختلف SIEMs کو بھی بھیجا جا سکتا ہے۔ خلاصہ کرنے کے لیے، ہم یہ کہہ سکتے ہیں کہ اگر آپ کی کمپنی ملٹی کلاؤڈ حکمت عملی استعمال کرتی ہے اور کسی ایک کلاؤڈ فراہم کنندہ تک محدود نہیں ہے، اوپر بیان کردہ معلومات کی حفاظت کی نگرانی کی صلاحیتیں، تو سسکو اسٹیلتھ واچ کلاؤڈ کا استعمال مانیٹرنگ کا متحد سیٹ حاصل کرنے کے لیے ایک اچھا آپشن ہے۔ سرکردہ کلاؤڈ پلیئرز کے لیے صلاحیتیں - ایمیزون، مائیکروسافٹ اور گوگل۔ سب سے دلچسپ بات یہ ہے کہ اگر آپ اسٹیلتھ واچ کلاؤڈ کی قیمتوں کا موازنہ AWS، Azure یا GCP میں انفارمیشن سیکیورٹی مانیٹرنگ کے لیے جدید لائسنس کے ساتھ کریں، تو یہ معلوم ہو سکتا ہے کہ Cisco سلوشن ایمیزون، مائیکروسافٹ کی بلٹ ان صلاحیتوں سے بھی سستا ہو گا۔ اور گوگل کے حل۔ یہ متضاد ہے، لیکن یہ سچ ہے۔ اور آپ جتنے زیادہ بادل اور ان کی صلاحیتوں کا استعمال کریں گے، ایک مضبوط حل کا فائدہ اتنا ہی واضح ہوگا۔

اس کے علاوہ، اسٹیلتھ واچ کلاؤڈ آپ کی تنظیم میں تعینات نجی بادلوں کی نگرانی کر سکتا ہے، مثال کے طور پر، Kubernetes کنٹینرز کی بنیاد پر یا نیٹ فلو کے بہاؤ یا نیٹ ورک کے سامان میں عکس بندی کے ذریعے موصول ہونے والے نیٹ ورک ٹریفک کی نگرانی کر کے (یہاں تک کہ مقامی طور پر تیار کردہ)، AD ڈیٹا یا DNS سرورز وغیرہ۔ یہ تمام ڈیٹا سائبرسیکیوریٹی تھریٹ ریسرچرز کے دنیا کے سب سے بڑے غیر سرکاری گروپ سسکو ٹالوس کے ذریعہ جمع کردہ تھریٹ انٹیلی جنس معلومات سے افزودہ کیا جائے گا۔

یہ آپ کو عوامی اور ہائبرڈ دونوں بادلوں کے لیے ایک متحد نگرانی کا نظام نافذ کرنے کی اجازت دیتا ہے جسے آپ کی کمپنی استعمال کر سکتی ہے۔ اس کے بعد جمع کی گئی معلومات کا اسٹیلتھ واچ کلاؤڈ کی بلٹ ان صلاحیتوں کا استعمال کرتے ہوئے تجزیہ کیا جا سکتا ہے یا آپ کے SIEM کو بھیجا جا سکتا ہے (Splunk، ELK، SumoLogic اور کئی دیگر کو بطور ڈیفالٹ سپورٹ کیا جاتا ہے)۔

اس کے ساتھ، ہم مضمون کا پہلا حصہ مکمل کریں گے، جس میں میں نے IaaS/PaaS پلیٹ فارمز کی انفارمیشن سیکیورٹی کی نگرانی کے لیے بلٹ ان اور ایکسٹرنل ٹولز کا جائزہ لیا، جو ہمیں بادل کے ماحول میں پیش آنے والے واقعات کا فوری پتہ لگانے اور ان کا جواب دینے کی اجازت دیتے ہیں۔ ہمارے انٹرپرائز نے منتخب کیا ہے. دوسرے حصے میں، ہم موضوع کو جاری رکھیں گے اور Salesforce اور Dropbox کی مثال کا استعمال کرتے ہوئے SaaS پلیٹ فارمز کی نگرانی کے لیے آپشنز کو دیکھیں گے، اور ہم مختلف کلاؤڈ فراہم کنندگان کے لیے ایک متحد انفارمیشن سیکیورٹی مانیٹرنگ سسٹم بنا کر ہر چیز کا خلاصہ اور یکجا کرنے کی کوشش کریں گے۔

ماخذ: www.habr.com