کچھ عرصہ قبل ہم نے GOST R 57580 کی ضروریات کی تعمیل کا ایک اور جائزہ لیا تھا (اس کے بعد اسے صرف GOST کہا جاتا ہے)۔ کلائنٹ ایک کمپنی ہے جو الیکٹرانک ادائیگی کا نظام تیار کرتی ہے۔ سسٹم سنجیدہ ہے: 3 ملین سے زیادہ صارفین، روزانہ 200 ہزار سے زیادہ لین دین۔ وہ وہاں معلومات کی حفاظت کو بہت سنجیدگی سے لیتے ہیں۔
تشخیص کے عمل کے دوران، کلائنٹ نے اتفاق سے اعلان کیا کہ ڈیولپمنٹ ڈیپارٹمنٹ، ورچوئل مشینوں کے علاوہ، کنٹینرز استعمال کرنے کا ارادہ رکھتا ہے۔ لیکن اس کے ساتھ، مؤکل نے مزید کہا، ایک مسئلہ ہے: GOST میں ایک ہی Docker کے بارے میں کوئی لفظ نہیں ہے۔ میں کیا کروں؟ کنٹینرز کی سیکورٹی کا اندازہ کیسے لگایا جائے؟
یہ سچ ہے، GOST صرف ہارڈویئر ورچوئلائزیشن کے بارے میں لکھتا ہے - ورچوئل مشینوں، ہائپر وائزر اور سرور کی حفاظت کے بارے میں۔ ہم نے مرکزی بینک سے وضاحت طلب کی۔ جواب نے ہمیں پریشان کر دیا۔
GOST اور ورچوئلائزیشن
شروع کرنے کے لیے، ہمیں یاد کرنا چاہیے کہ GOST R 57580 ایک نیا معیار ہے جو "مالیاتی تنظیموں کی معلومات کی حفاظت کو یقینی بنانے کے لیے تقاضے" (FI) کی وضاحت کرتا ہے۔ ان FIs میں آپریٹرز اور ادائیگی کے نظام کے شرکاء، کریڈٹ اور نان کریڈٹ تنظیمیں، آپریشنل اور کلیئرنگ سینٹرز شامل ہیں۔
1 جنوری 2021 سے، FIs کو کرنا ضروری ہے۔ . ہم، ITGLOBAL.COM، ایک آڈٹ کمپنی ہیں جو اس طرح کے جائزے کرتی ہے۔
GOST میں ورچوئلائزڈ ماحول کے تحفظ کے لیے وقف ایک ذیلی سیکشن ہے - نمبر 7.8۔ "ورچوئلائزیشن" کی اصطلاح وہاں متعین نہیں ہے؛ ہارڈ ویئر اور کنٹینر ورچوئلائزیشن میں کوئی تقسیم نہیں ہے۔ کوئی بھی آئی ٹی ماہر کہے گا کہ تکنیکی نقطہ نظر سے یہ غلط ہے: ایک ورچوئل مشین (VM) اور ایک کنٹینر الگ الگ ماحول ہیں، جن میں الگ تھلگ کے مختلف اصول ہیں۔ میزبان کی کمزوری کے نقطہ نظر سے جس پر VM اور Docker کنٹینرز تعینات ہیں، یہ بھی ایک بڑا فرق ہے۔
یہ پتہ چلتا ہے کہ VMs اور کنٹینرز کی معلومات کی حفاظت کا اندازہ بھی مختلف ہونا چاہئے۔
مرکزی بینک سے ہمارے سوالات
ہم نے انہیں مرکزی بینک کے انفارمیشن سیکیورٹی ڈیپارٹمنٹ کو بھیج دیا (ہم سوالات کو مختصر شکل میں پیش کرتے ہیں)۔
- GOST تعمیل کا اندازہ کرتے وقت Docker قسم کے ورچوئل کنٹینرز پر کیسے غور کیا جائے؟ کیا GOST کی ذیلی دفعہ 7.8 کے مطابق ٹیکنالوجی کا جائزہ لینا درست ہے؟
- ورچوئل کنٹینر مینجمنٹ ٹولز کا اندازہ کیسے لگایا جائے؟ کیا یہ ممکن ہے کہ انہیں سرور ورچوئلائزیشن کے اجزاء سے ہم آہنگ کیا جائے اور GOST کے اسی ذیلی حصے کے مطابق ان کا جائزہ لیا جائے؟
- کیا مجھے ڈوکر کنٹینرز کے اندر معلومات کی حفاظت کا الگ سے جائزہ لینے کی ضرورت ہے؟ اگر ایسا ہے تو، تشخیصی عمل کے دوران اس کے لیے کن حفاظتی تدابیر پر غور کیا جانا چاہیے؟
- اگر کنٹینرائزیشن کو ورچوئل انفراسٹرکچر کے مساوی کیا جاتا ہے اور ذیلی دفعہ 7.8 کے مطابق اس کا اندازہ لگایا جاتا ہے، تو خصوصی معلوماتی حفاظتی ٹولز کے نفاذ کے لیے GOST کی ضروریات کو کیسے لاگو کیا جاتا ہے؟
مرکزی بینک کا جواب
ذیل میں اہم اقتباسات ہیں۔
"GOST R 57580.1-2017 مندرجہ ذیل اقدامات کے سلسلے میں تکنیکی اقدامات کے اطلاق کے ذریعے عمل درآمد کے لیے تقاضے قائم کرتا ہے GOST R 7.8-57580.1 کے ZI ذیلی سیکشن 2017، جسے، محکمے کی رائے میں، کنٹینر ورچوئلائزیشن کے استعمال کے معاملات تک بڑھایا جا سکتا ہے۔ مندرجہ ذیل کو مدنظر رکھتے ہوئے ٹیکنالوجیز:
- ورچوئل مشینوں اور ورچوئلائزیشن سرور کے اجزاء تک منطقی رسائی کو لاگو کرتے وقت شناخت، تصدیق، اجازت (رسائی کنٹرول) کو منظم کرنے کے لیے ZSV.1 - ZSV.11 کے اقدامات کا نفاذ کنٹینر ورچوئلائزیشن ٹیکنالوجی کے استعمال کے معاملات سے مختلف ہو سکتا ہے۔ اس کو مدنظر رکھتے ہوئے، متعدد اقدامات (مثال کے طور پر، ZVS.6 اور ZVS.7) کو نافذ کرنے کے لیے، ہم سمجھتے ہیں کہ یہ تجویز کرنا ممکن ہے کہ مالیاتی ادارے ایسے معاوضے کے اقدامات تیار کریں جو انہی اہداف کو حاصل کریں گے۔
- ZSV.13 - ZSV.22 کی تنظیم اور ورچوئل مشینوں کے معلوماتی تعامل کے کنٹرول کے لیے اقدامات کا نفاذ ایک مالیاتی تنظیم کے کمپیوٹر نیٹ ورک کو تقسیم کرنے کے لیے فراہم کرتا ہے تاکہ انفارمیٹائزیشن اشیاء کے درمیان فرق کیا جا سکے جو ورچوئلائزیشن ٹیکنالوجی کو نافذ کرتے ہیں اور مختلف سیکیورٹی سرکٹس سے تعلق رکھتے ہیں۔ اس کو مدنظر رکھتے ہوئے، ہمارا خیال ہے کہ کنٹینر ورچوئلائزیشن ٹیکنالوجی کا استعمال کرتے وقت مناسب سیگمنٹیشن فراہم کرنے کا مشورہ دیا جاتا ہے (دونوں قابل عمل ورچوئل کنٹینرز کے سلسلے میں اور آپریٹنگ سسٹم کی سطح پر استعمال ہونے والے ورچوئلائزیشن سسٹم کے سلسلے میں)؛
- ورچوئل مشینوں کی تصاویر کے تحفظ کو منظم کرنے کے لیے ZSV.26, ZSV.29 - ZSV.31 کے اقدامات کا نفاذ قیاس کے ذریعے بھی کیا جانا چاہیے تاکہ ورچوئل کنٹینرز کی بنیادی اور موجودہ تصاویر کی حفاظت کی جا سکے۔
- ورچوئل مشینوں اور سرور ورچوئلائزیشن اجزاء تک رسائی سے متعلق معلوماتی حفاظتی واقعات کو ریکارڈ کرنے کے لیے ZVS.32 - ZVS.43 کے اقدامات کا نفاذ ورچوئلائزیشن ماحول کے عناصر کے سلسلے میں بھی مشابہت کے ساتھ کیا جانا چاہیے جو کنٹینر ورچوئلائزیشن ٹیکنالوجی کو نافذ کرتے ہیں۔
اس کا کیا مطلب ہے
مرکزی بینک کے انفارمیشن سیکیورٹی ڈیپارٹمنٹ کے جواب سے دو اہم نتائج:
- کنٹینرز کی حفاظت کے اقدامات ورچوئل مشینوں کی حفاظت کے اقدامات سے مختلف نہیں ہیں۔
- اس سے یہ ہوتا ہے کہ، معلومات کی حفاظت کے تناظر میں، مرکزی بینک دو قسم کے ورچوئلائزیشن کو مساوی کرتا ہے - ڈوکر کنٹینرز اور VMs۔
جواب میں "معاوضہ اقدامات" کا بھی تذکرہ کیا گیا ہے جنہیں خطرات کو بے اثر کرنے کے لیے لاگو کرنے کی ضرورت ہے۔ یہ ابھی واضح نہیں ہے کہ یہ "معاوضہ کے اقدامات" کیا ہیں اور ان کی مناسبیت، مکمل اور تاثیر کی پیمائش کیسے کی جائے۔
مرکزی بینک کی پوزیشن میں کیا خرابی ہے؟
اگر آپ تشخیص (اور خود تشخیص) کے دوران مرکزی بینک کی سفارشات کا استعمال کرتے ہیں، تو آپ کو متعدد تکنیکی اور منطقی مشکلات کو حل کرنے کی ضرورت ہے۔
- ہر قابل عمل کنٹینر کو اس پر انفارمیشن پروٹیکشن سافٹ ویئر (IP) کی تنصیب کی ضرورت ہوتی ہے: اینٹی وائرس، انٹیگریٹی مانیٹرنگ، لاگز کے ساتھ کام کرنا، ڈی ایل پی سسٹم (ڈیٹا لیک کی روک تھام) وغیرہ۔ یہ سب بغیر کسی پریشانی کے VM پر انسٹال کیا جا سکتا ہے، لیکن کنٹینر کے معاملے میں، انفارمیشن سیکیورٹی کو انسٹال کرنا ایک مضحکہ خیز اقدام ہے۔ کنٹینر میں "باڈی کٹ" کی کم از کم مقدار ہوتی ہے جو سروس کے کام کرنے کے لیے درکار ہوتی ہے۔ اس میں SZI نصب کرنا اس کے معنی سے متصادم ہے۔
- کنٹینر کی تصاویر کو اسی اصول کے مطابق محفوظ کیا جانا چاہیے؛ اسے کیسے نافذ کیا جائے یہ بھی واضح نہیں ہے۔
- GOST کو سرور ورچوئلائزیشن کے اجزاء، یعنی ہائپر وائزر تک رسائی کو محدود کرنے کی ضرورت ہے۔ ڈوکر کے معاملے میں سرور کا جزو کیا سمجھا جاتا ہے؟ کیا اس کا مطلب یہ نہیں ہے کہ ہر کنٹینر کو الگ میزبان پر چلانے کی ضرورت ہے؟
- اگر روایتی ورچوئلائزیشن کے لیے حفاظتی شکلوں اور نیٹ ورک سیگمنٹس کے ذریعے VMs کو محدود کرنا ممکن ہے، تو اسی میزبان کے اندر Docker کنٹینرز کے معاملے میں، ایسا نہیں ہے۔
عملی طور پر، یہ امکان ہے کہ ہر آڈیٹر اپنے اپنے علم اور تجربے کی بنیاد پر کنٹینرز کی حفاظت کا اپنے طریقے سے جائزہ لے گا۔ ٹھیک ہے، یا اس کا بالکل بھی جائزہ نہ لیں، اگر وہاں نہ ایک ہے اور نہ ہی دوسرا۔
صرف اس صورت میں، ہم یہ شامل کریں گے کہ 1 جنوری 2021 سے، کم از کم سکور 0,7 سے کم نہیں ہونا چاہیے۔
ویسے، ہم باقاعدگی سے GOST 57580 اور مرکزی بینک کے ضوابط کے تقاضوں سے متعلق ریگولیٹرز کے جوابات اور تبصرے پوسٹ کرتے ہیں۔ .
کیا کرنا ہے
ہماری رائے میں، مالیاتی تنظیموں کے پاس مسئلے کو حل کرنے کے لیے صرف دو ہی راستے ہیں۔
1. کنٹینرز کو لاگو کرنے سے بچیں
ان لوگوں کے لئے ایک حل جو صرف ہارڈ ویئر ورچوئلائزیشن کو استعمال کرنے کے متحمل ہیں اور اسی وقت GOST کے مطابق کم درجہ بندی اور مرکزی بینک سے جرمانے سے ڈرتے ہیں۔
ایک پلس: GOST کے ذیلی دفعہ 7.8 کے تقاضوں کی تعمیل کرنا آسان ہے۔
تفریق: ہمیں کنٹینر ورچوئلائزیشن پر مبنی نئے ترقیاتی ٹولز کو ترک کرنا پڑے گا، خاص طور پر ڈوکر اور کبرنیٹس۔
2. GOST کے ذیلی سیکشن 7.8 کے تقاضوں کی تعمیل کرنے سے انکار کریں۔
لیکن ساتھ ہی، کنٹینرز کے ساتھ کام کرتے وقت معلومات کی حفاظت کو یقینی بنانے کے لیے بہترین طریقوں کا اطلاق کریں۔ یہ ان لوگوں کے لیے ایک حل ہے جو نئی ٹیکنالوجیز اور ان کے فراہم کردہ مواقع کی قدر کرتے ہیں۔ "بہترین طریقوں" سے ہمارا مطلب ہے ڈوکر کنٹینرز کی حفاظت کو یقینی بنانے کے لیے صنعت کے قبول کردہ معیارات اور معیارات:
- میزبان OS کی حفاظت، مناسب طریقے سے ترتیب شدہ لاگنگ، کنٹینرز کے درمیان ڈیٹا کے تبادلے کی ممانعت، وغیرہ۔
- تصاویر کی سالمیت کو چیک کرنے کے لیے ڈاکر ٹرسٹ فنکشن کا استعمال کرتے ہوئے اور بلٹ ان ویلنریبلٹی اسکینر کا استعمال؛
- ہمیں ریموٹ رسائی کی حفاظت اور مجموعی طور پر نیٹ ورک ماڈل کے بارے میں نہیں بھولنا چاہیے: ARP-spoofing اور MAC-flooding جیسے حملوں کو منسوخ نہیں کیا گیا ہے۔
ایک پلس: کنٹینر ورچوئلائزیشن کے استعمال پر کوئی تکنیکی پابندی نہیں۔
تفریق: اس بات کا بہت زیادہ امکان ہے کہ ریگولیٹر GOST کے تقاضوں کی عدم تعمیل پر سزا دے گا۔
حاصل يہ ہوا
ہمارے مؤکل نے کنٹینرز نہ چھوڑنے کا فیصلہ کیا۔ ایک ہی وقت میں، اسے کام کے دائرہ کار اور ڈوکر میں منتقلی کے وقت پر نمایاں طور پر دوبارہ غور کرنا پڑا (وہ چھ ماہ تک جاری رہے)۔ کلائنٹ خطرات کو اچھی طرح سمجھتا ہے۔ وہ یہ بھی سمجھتا ہے کہ GOST R 57580 کی تعمیل کے اگلے جائزے کے دوران، بہت کچھ آڈیٹر پر منحصر ہوگا۔
اس صورت حال میں آپ کیا کریں گے؟
ماخذ: www.habr.com