د جولای په 19، 2019، Capital One پیغام ترلاسه کړ چې هر عصري شرکت ویره لري — د معلوماتو سرغړونې پیښ شوي. دا له 106 ملیون څخه ډیر خلک اغیزمن کړي. 140 د متحده ایالاتو ټولنیز امنیت شمیرې، د یو ملیون کاناډا ټولنیز امنیت شمیرې. 000 بانکي حسابونه. ناخوښه، تاسو موافق نه یاست؟
له بده مرغه، هیک د جولای په 19 مه پیښ شوی. لکه څنګه چې دا وګرځيده، Paige Thompson، a.k.a. ناڅاپي، دا د مارچ 22 او مارچ 23 ، 2019 ترمینځ ژمنه کړې. هغه دی نږدې څلور میاشتې مخکې. په حقیقت کې، دا یوازې د بهرنی مشاورینو په مرسته وه چې کیپیټل ون وکولی شو کشف کړي چې یو څه پیښ شوي.
د امازون یو پخوانی کارمند نیول شوی او د 250 ډالرو جریمې او پنځه کاله بند سره مخ دی ... مګر لاهم ډیر منفي پاتې دي. ولې؟ ځکه چې ډیری شرکتونه چې د هیکونو سره مخ شوي هڅه کوي د سایبر جرمونو د زیاتوالي په جریان کې د دوی د زیربنا او غوښتنلیکونو پیاوړي کولو مسؤلیت پریږدي.
په هرصورت، تاسو کولی شئ دا کیسه په اسانۍ سره ګوګل کړئ. موږ به ډرامې ته نه ځو، مګر په اړه خبرې کوو تخنیکي د موضوع اړخ.
لومړی، څه وشول؟
Capital One شاوخوا 700 S3 بالټونه چلول، کوم چې Paige Thompson کاپي کړي او له منځه یوړل.
دوهم، ایا دا د غلط ترتیب شوي S3 بالټ پالیسۍ بله قضیه ده؟
نه، دا ځل نه. دلته هغې د غلط ترتیب شوي فائر وال سره سرور ته لاسرسی ترلاسه کړ او له هغه ځایه یې ټول عملیات ترسره کړل.
انتظار وکړئ، دا څنګه ممکنه ده؟
ښه، راځئ چې په سرور کې د ننوتلو سره پیل وکړو، که څه هم موږ ډیری توضیحات نلرو. موږ ته یوازې ویل شوي وو چې دا د "غلط ترتیب شوي فائر وال" له لارې پیښ شوي. نو، یو څه ساده لکه د غلط امنیتي ګروپ ترتیبات یا د ویب غوښتنلیک فایر وال (Imperva)، یا د شبکې فایر وال (iptables، ufw، shorewall، او نور) ترتیب کول. کیپیټل ون یوازې خپله ګناه ومنله او ویې ویل چې سوری یې تړلی دی.
سټون وویل چې کیپیټل ون په پیل کې د اور وژنې زیان نه دی لیدلی مګر کله چې پوه شو ژر یې عمل وکړ. دا په حقیقت کې د دې حقیقت سره مرسته شوې چې هیکر په عامه ډومین کې د پیژندلو کلیدي معلومات پریښودل، سټون وویل.
که تاسو حیران یاست چې ولې موږ دې برخې ته ژور نه ځو، مهرباني وکړئ پوه شئ چې د محدودو معلوماتو له امله موږ یوازې اټکل کولی شو. دا هیڅ معنی نلري چې هیک د کیپیټل ون لخوا پاتې شوي سوري پورې اړه لري. او پرته لدې چې دوی موږ ته نور څه ووایی ، موږ به یوازې ټولې ممکنه لارې لیست کړو چې کیپیټل ون خپل سرور د ټولو ممکنه لارو په ترکیب کې خلاص پریښود چې څوک کولی شي له دې مختلف انتخابونو څخه یو وکاروي. دا نیمګړتیاوې او تخنیکونه د وحشي احمقانه نظارت څخه نیولې تر خورا پیچلي نمونو پورې اړه لري. د امکاناتو سلسله ته په پام سره، دا به یوه اوږده کیسه شي چې هیڅ ریښتینې پایله نلري. له همدې امله، راځئ چې د هغې برخې تحلیل تمرکز وکړو چیرې چې موږ حقایق لرو.
نو لومړی لاره دا ده: پوه شئ چې ستاسو فایروال څه اجازه ورکوي.
یوه پالیسي یا سمه پروسه رامینځته کړئ ترڅو ډاډ ترلاسه شي چې یوازې هغه څه چې خلاصیدو ته اړتیا لري. که تاسو د AWS سرچینې لکه امنیتي ګروپونه یا د شبکې ACLs کاروئ، په ښکاره ډول د پلټنې لپاره چک لیست اوږد کیدی شي ... مګر لکه څنګه چې ډیری سرچینې په اوتومات ډول رامینځته کیږي (د بیلګې په توګه کلاوډ فارمیشن)، دا هم ممکنه ده چې د دوی پلټنې اتومات کړئ. که دا یو کور جوړ شوی سکریپټ وي چې د نیمګړتیاوو لپاره نوي شیان سکین کوي، یا د 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 په رولونو پوهیږئ، موږ کولی شو د هغه څه په اړه وغږیږو چې پایګ تامپسن وکړ:
- هغې سرور ته لاسرسی (EC2 مثال) د اور وژنې سوري له لارې ترلاسه کړ
که دا امنیتي ګروپونه/ACLs یا د دوی خپل ویب اپلیکیشن فائر والونه وي، سوراخ شاید د پلګ کولو لپاره خورا اسانه و، لکه څنګه چې په رسمي ریکارډونو کې ویل شوي.
- یوځل په سرور کې ، هغې د دې توان درلود چې "لکه څنګه چې" هغه پخپله سرور وي
- له هغه وخته چې د IAM سرور رول S3 ته دې 700+ بالټونو ته لاسرسي اجازه ورکړه ، نو دوی ته لاسرسی درلود
له هغې شیبې څخه ، ټول هغه څه چې باید ترسره یې کړي قوماندې پرمخ وړي List Bucketsاو بیا امر Sync د AWS CLI څخه ...
. د دې ډول زیان مخنیوی له همدې امله شرکتونه د بادل زیربنا محافظت ، DevOps ، او امنیت متخصصینو کې دومره پانګونه کوي. او بادرنګ ته تلل څومره ارزښتناک او ارزانه دي؟ دومره ډیر چې حتی د ډیرو سایبر امنیت ننګونو سره مخ دي !
د کیسې اخلاق: خپل خوندیتوب وګورئ؛ منظمې پلټنې ترسره کول؛ د امنیتي پالیسیو لپاره د لږ تر لږه امتیازاتو اصولو ته درناوی وکړئ.
( تاسو کولی شئ بشپړ قانوني راپور وګورئ).
سرچینه: www.habr.com