19 جولاءِ 2019 تي، ڪيپيٽل ون کي پيغام مليو ته هر جديد ڪمپنيءَ کي خوف آهي- ڊيٽا جي ڀڃڪڙي ٿي. اهو 106 ملين کان وڌيڪ ماڻهن کي متاثر ڪيو. 140 يو ايس سوشل سيڪيورٽي نمبر، هڪ ملين ڪينيڊا سوشل سيڪيورٽي نمبر. 000 بئنڪ اڪائونٽس. ناپسنديده، توهان متفق نه آهيو؟
بدقسمتي سان، هيڪ 19 جولاء تي نه ٿيو. جيئن ته اهو نڪتو، Paige Thompson، a.k.a. اڻaticاڻ، ان کي 22 مارچ ۽ 23 مارچ 2019 جي وچ ۾ انجام ڏنو. اهو آهي لڳ ڀڳ چار مهينا اڳ. حقيقت ۾، اهو صرف ٻاهرين صلاحڪارن جي مدد سان هو ته ڪيپيٽل ون دريافت ڪرڻ جي قابل هئي ته ڪجهه ٿيو هو.
هڪ اڳوڻي Amazon ملازم کي گرفتار ڪيو ويو ۽ $ 250 ڏنڊ ۽ پنج سال جيل ۾ منهن ڏيڻو پيو ... پر اڃا به ڪافي منفيات باقي آهي. ڇو؟ ڇاڪاڻ ته ڪيتريون ئي ڪمپنيون جيڪي هيڪس کان متاثر ٿيا آهن انهن جي انفراسٽرڪچر ۽ ايپليڪيشنن کي مضبوط ڪرڻ جي ذميواري کي ڇڪڻ جي ڪوشش ڪري رهيا آهن سائبر ڪرائم ۾ اضافو جي وچ ۾.
بهرحال، توهان آساني سان هن ڪهاڻي کي گوگل ڪري سگهو ٿا. اسان ڊرامي ۾ نه وينداسين، پر ڳالهائينداسين ٽيڪنيڪل معاملي جي پاسي.
سڀ کان پهرين، ڇا ٿيو؟
ڪيپيٽل ون وٽ لڳ ڀڳ 700 S3 بڪيٽ ھلندڙ ھئا، جن کي Paige Thompson نقل ڪيو ۽ بند ڪري ڇڏيو.
ٻيو، ڇا هي هڪ ٻيو ڪيس غلط ترتيب ڏنل S3 بالٽ پاليسي جو آهي؟
نه، هن ڀيري نه. هتي هوء غلط ترتيب واري فائر وال سان سرور تائين پهچ حاصل ڪئي ۽ اتان کان سڄو آپريشن ڪيو.
انتظار ڪريو، اهو ڪيئن ممڪن آهي؟
خير، اچو ته شروع ڪريون سرور ۾ لاگ ان ٿيڻ سان، جيتوڻيڪ اسان وٽ ڪيترائي تفصيل نه آهن. اسان کي صرف ٻڌايو ويو ته اهو "غلط ترتيب واري فائر وال" ذريعي ٿيو. تنهن ڪري، ڪجهه سادو جيئن غلط سيڪيورٽي گروپ سيٽنگون يا ويب ايپليڪيشن فائر وال جي ترتيب (Imperva)، يا نيٽورڪ فائر وال (iptables، ufw، shorewall، وغيره). ڪيپيٽل ون صرف پنهنجو ڏوهه قبول ڪيو ۽ چيو ته اهو سوراخ بند ڪري چڪو آهي.
پٿر چيو ته ڪيپيٽل ون شروعاتي طور تي فائر وال جي ڪمزوري کي نوٽيس نه ڪيو پر جلدي ڪم ڪيو جڏهن ان جي خبر پئجي وئي. اهو يقيني طور تي مدد ڪئي وئي ته هيڪر مبينا طور تي عوامي ڊومين ۾ اهم سڃاڻپ واري معلومات ڇڏي، پٿر چيو.
جيڪڏھن توھان حيران ٿي رھيا آھيو ته اسان ھن حصي ۾ ڇو نه ٿا وڃون، مھرباني ڪري سمجھو ته محدود معلومات جي ڪري اسان صرف اندازو لڳائي سگھون ٿا. اهو ڪو به احساس نه ٿو ڏئي ته هيڪ ڪئپٽيٽ ون طرفان ڇڏيل هڪ سوراخ تي منحصر آهي. ۽ جيستائين اهي اسان کي وڌيڪ نه ٻڌائيندا، اسان صرف انهن سڀني ممڪن طريقن جي فهرست ڪنداسين جيڪي ڪيپيٽل ون پنهنجي سرور کي کليل ڇڏي سڀني ممڪن طريقن سان گڏ انهن مختلف اختيارن مان هڪ کي استعمال ڪري سگهي ٿو. اهي خاميون ۽ ٽيڪنالاجيون حد تائين ٿي سگهن ٿيون جهنگلي بيوقوف نگراني کان وٺي ناقابل يقين حد تائين پيچيده نمونن تائين. امڪانن جي حد کي ڏنو ويو، اهو هڪ ڊگهو ساگا بڻجي ويندو جنهن سان ڪوبه حقيقي نتيجو ناهي. تنهن ڪري، اچو ته ان حصي جو تجزيو ڪرڻ تي ڌيان ڏيو جتي اسان وٽ حقيقتون آهن.
تنهن ڪري پهريون رستو آهي: ڄاڻو ته توهان جي فائر والز ڪهڙي اجازت ڏين ٿا.
هڪ پاليسي يا مناسب عمل قائم ڪريو انهي کي يقيني بڻائڻ لاءِ ته صرف ان کي کولڻ جي ضرورت آهي. جيڪڏهن توهان AWS وسيلا استعمال ڪري رهيا آهيو جهڙوڪ سيڪيورٽي گروپس يا نيٽ ورڪ ACLs، ظاهر آهي آڊٽ لاءِ چيڪ لسٽ ڊگھي ٿي سگهي ٿي... پر جيئن ته ڪيترائي وسيلا پاڻمرادو ٺاهيا ويندا آهن (يعني CloudFormation)، اهو پڻ ممڪن آهي ته انهن جي آڊيٽنگ کي خودڪار ڪرڻ. ڇا اهو هڪ گهريلو اسڪرپٽ آهي جيڪو خامين لاءِ نئين شين کي اسڪين ڪري ٿو، يا CI/CD پروسيس ۾ سيڪيورٽي آڊٽ وانگر ڪجهه... ان کان بچڻ لاءِ ڪيترائي آسان آپشن آهن.
ڪهاڻي جو ”مذاق“ حصو اهو آهي ته جيڪڏهن ڪيپيٽل ون پهرين جاءِ تي سوراخ ڪري ڇڏي ها... ڪجهه به نه ٿئي ها. ۽ ائين، صاف طور تي، اهو هميشه حيران ڪندڙ آهي اهو ڏسڻ لاء ته ڪيئن ڪجهه واقعي تمام سادو هڪ ڪمپني جي هيڪ ٿيڻ جو واحد سبب بڻجي ٿو. خاص طور تي هڪ جيترو وڏو سرمائيدار هڪ.
پوء، هيڪر اندر - اڳتي ڇا ٿيو؟
خير، هڪ EC2 مثال ۾ ٽوڙڻ کان پوء ... تمام گهڻو غلط ٿي سگهي ٿو. توھان عملي طور تي چاقو جي ڪنڊ تي ھلندا آھيو جيڪڏھن توھان ڪنھن کي پري وڃڻ ڏيو. پر اهو ڪيئن S3 بالٽ ۾ داخل ٿيو؟ ھن کي سمجھڻ لاء، اچو ته بحث ڪريون IAM ڪردار.
تنهن ڪري، AWS خدمتن تائين رسائي حاصل ڪرڻ جو هڪ طريقو صارف هجڻ آهي. چڱو، هي هڪ تمام واضح آهي. پر ڇا جيڪڏھن توھان چاھيو ٿا ٻيون AWS خدمتون، جھڙوڪ توھان جي ايپليڪيشن سرور، توھان جي S3 بڪيٽ تائين رسائي؟ اھو اھو آھي جيڪو IAM ڪردار لاءِ آھن. اهي ٻن حصن تي مشتمل آهن:
- اعتماد جي پاليسي - ڪهڙيون خدمتون يا ماڻهو هن ڪردار کي استعمال ڪري سگهن ٿا؟
- اجازتن جي پاليسي - هي ڪردار ڇا جي اجازت ڏئي ٿو؟
مثال طور، توهان هڪ IAM ڪردار ٺاهڻ چاهيو ٿا جيڪو EC2 مثالن کي S3 بالٽ تائين رسائي جي اجازت ڏيندو: پهريون، ڪردار کي هڪ اعتماد واري پاليسي مقرر ڪئي وئي آهي جيڪا EC2 (سڄي خدمت) يا مخصوص مثالن کي "اختيار" ڪري سگهي ٿو. هڪ ڪردار کي قبول ڪرڻ جو مطلب آهي ته اهي ڪم ڪرڻ لاء ڪردار جي اجازتن کي استعمال ڪري سگهن ٿا. ٻيو، اجازتن واري پاليسي سروس/شخص/ وسيلن کي اجازت ڏئي ٿي جنهن S3 تي ڪجهه به ڪرڻ لاءِ ”ڪردار ورتو آهي“، چاهي اها هڪ مخصوص بالٽ تائين رسائي هجي... يا 700 کان مٿي، جيئن ڪيپيٽل ون جي صورت ۾.
هڪ دفعو توهان IAM ڪردار سان EC2 مثال ۾ آهيو، توهان ڪيترن ئي طريقن سان سندون حاصل ڪري سگهو ٿا:
- توھان درخواست ڪري سگھو ٿا مثال ميٽا ڊيٽا تي
http://169.254.169.254/latest/meta-dataٻين شين جي وچ ۾، توهان ڳولي سگهو ٿا IAM ڪردار ڪنهن به رسائي جي چاٻين سان هن ايڊريس تي. يقينا، صرف جيڪڏهن توهان هڪ مثال ۾ آهيو.
- AWS CLI استعمال ڪريو...
جيڪڏهن AWS CLI انسٽال ٿيل آهي، اهو IAM ڪردارن جي سندن سان ڀريل آهي، جيڪڏهن موجود هجي. اهو سڀ ڪجهه باقي آهي مثال جي ذريعي ڪم ڪرڻ. يقينن، جيڪڏهن انهن جي اعتماد واري پاليسي کليل هئي، Paige سڀ ڪجهه سڌو ڪري سگهي ٿو.
تنهن ڪري IAM ڪردارن جو خلاصو اهو آهي ته اهي ڪجهه وسيلن کي توهان جي طرفان ٻين وسيلن تي عمل ڪرڻ جي اجازت ڏين ٿا.
هاڻي ته توهان IAM جي ڪردار کي سمجهي رهيا آهيو، اسان انهي بابت ڳالهائي سگهون ٿا ته Paige Thompson ڇا ڪيو:
- هوء فائر وال ۾ سوراخ ذريعي سرور (EC2 مثال) تائين رسائي حاصل ڪئي
ڇا اهو سيڪيورٽي گروپن/ACLs يا انهن جي پنهنجي ويب ايپليڪيشن فائر والز هئي، سوراخ شايد پلگ ڪرڻ بلڪل آسان هو، جيئن سرڪاري رڪارڊ ۾ بيان ڪيو ويو آهي.
- هڪ دفعو سرور تي، هوء ڪم ڪرڻ جي قابل هئي "جيئن" هوء خود سرور هئي
- جيئن ته IAM سرور ڪردار S3 تائين انهن 700+ بالڪن تائين رسائي جي اجازت ڏني، اهو انهن تائين رسائي ڪرڻ جي قابل هو
ان وقت کان وٺي، هن کي صرف حڪم هلائڻو هو List Buckets۽ پوء حڪم Sync AWS CLI کان...
. اهڙي نقصان کي روڪڻ ڇو ته ڪمپنيون ڪلائوڊ انفراسٽرڪچر جي تحفظ، DevOps، ۽ سيڪيورٽي ماهرن ۾ تمام گهڻي سيڙپڪاري ڪن ٿيون. ۽ ڪئين قيمتي ۽ قيمتي اثرائتي بادل ڏانهن منتقل ٿي رهيو آهي؟ ايتري قدر جو اڃا به وڌيڪ ۽ وڌيڪ سائبر سيڪيورٽي چئلينج جي منهن ۾ !
ڪهاڻي جو اخلاقي: توهان جي حفاظت چيڪ ڪريو؛ باقاعده آڊٽ ڪرڻ؛ سيڪيورٽي پاليسين لاءِ گهٽ ۾ گهٽ استحقاق جي اصول جو احترام ڪريو.
( توهان مڪمل قانوني رپورٽ ڏسي سگهو ٿا).
جو ذريعو: www.habr.com