19-yil 2019-iyul kuni Capital One har bir zamonaviy kompaniya qo‘rqadigan xabarni oldi – ma’lumotlar buzilishi sodir bo‘ldi. Bu 106 milliondan ortiq odamga ta'sir qildi. 140 000 AQSh ijtimoiy xavfsizlik raqamlari, bir million Kanada ijtimoiy xavfsizlik raqamlari. 80 000 bank hisoblari. Noxush, rozi emasmisiz?
Afsuski, buzg'unchilik 19 iyul kuni sodir bo'lmadi. Ma'lum bo'lishicha, Peyj Tompson, a.k.a. Tartibsiz, buni 22-yil 23-martdan 2019-martgacha qilgan. Ya'ni deyarli to'rt oy oldin. Darhaqiqat, faqat tashqi maslahatchilar yordamida Capital One nimadir sodir bo'lganligini aniqlashga muvaffaq bo'ldi.
Amazonning sobiq xodimi hibsga olindi va unga 250 XNUMX dollar jarima va besh yil qamoq jazosi tayinlanishi mumkin... lekin hali ham ko'p salbiy narsalar qolgan. Nega? Chunki buzg'unchiliklardan jabr ko'rgan ko'plab kompaniyalar kiberjinoyatlarning ko'payishi fonida o'z infratuzilmasi va ilovalarini mustahkamlash mas'uliyatidan voz kechishga harakat qilmoqda.
Qanday bo'lmasin, siz ushbu hikoyani osongina google qilishingiz mumkin. Biz dramaga kirmaymiz, lekin bu haqda gaplashamiz texnik masalaning tomoni.
Birinchidan, nima bo'ldi?
Capital One-da 700 ga yaqin S3 chelaklari ishlayotgan bo'lib, Peyj Tompson ularni ko'chirib olib, o'chirib tashladi.
Ikkinchidan, bu noto'g'ri sozlangan S3 chelak siyosatining yana bir holatimi?
Yo'q, bu safar emas. Bu erda u noto'g'ri sozlangan xavfsizlik devori bo'lgan serverga kirish huquqiga ega bo'ldi va u erdan butun operatsiyani amalga oshirdi.
Kuting, bu qanday mumkin?
Keling, serverga kirishdan boshlaylik, garchi bizda unchalik ko'p ma'lumotlar yo'q. Bizga faqat "noto'g'ri sozlangan xavfsizlik devori" orqali sodir bo'lganligini aytishdi. Shunday qilib, noto'g'ri xavfsizlik guruhi sozlamalari yoki veb-ilovaning xavfsizlik devori (Imperva) yoki tarmoq xavfsizlik devori (iptables, ufw, shorewall va boshqalar) konfiguratsiyasi kabi oddiy narsa. Capital One faqat o'z aybini tan oldi va teshikni yopganini aytdi.
Stounning so‘zlariga ko‘ra, Capital One dastlab xavfsizlik devori zaifligini sezmagan, biroq u xabardor bo‘lgach, tezda harakat qilgan. Bunga, shubhasiz, xakerning asosiy identifikatsiya ma'lumotlarini jamoat mulkida qoldirgani yordam berdi, dedi Stoun.
Nima uchun biz bu qismga chuqurroq kirmayotganimizga qiziqsangiz, maʼlumotlarning cheklanganligi sababli biz faqat taxmin qilishimiz mumkinligini tushunib oling. Hack Capital One tomonidan qoldirilgan teshikka bog'liqligini hisobga olsak, bu hech qanday ma'noga ega emas. Va agar ular bizga ko'proq ma'lumot bermasalar, biz Capital One o'z serverini ochiq qoldirgan barcha mumkin bo'lgan usullarni sanab o'tamiz, shu bilan birga kimdir ushbu turli xil variantlardan birini ishlatishi mumkin bo'lgan barcha usullar bilan birgalikda. Ushbu kamchiliklar va usullar juda ahmoqona nazoratdan tortib, nihoyatda murakkab naqshlargacha bo'lishi mumkin. Imkoniyatlar ko'lamini hisobga olsak, bu haqiqiy xulosasiz uzoq dostonga aylanadi. Shuning uchun, keling, bizda faktlar mavjud bo'lgan qismni tahlil qilishga e'tibor qarataylik.
Shunday qilib, birinchi olib tashlash: xavfsizlik devoringiz nimaga ruxsat berishini bilib oling.
FAQAT ochilishi kerak bo'lgan narsa ochilishini ta'minlash uchun siyosat yoki tegishli jarayonni belgilang. Xavfsizlik guruhlari yoki tarmoq ACLlari kabi AWS resurslaridan foydalanayotgan bo'lsangiz, tekshirish uchun tekshirish ro'yxati uzoq bo'lishi mumkin... lekin xuddi ko'p resurslar avtomatik tarzda yaratilgani kabi (masalan, CloudFormation), ularning auditini avtomatlashtirish ham mumkin. Yangi ob'ektlarni kamchiliklarni skanerlaydigan uy qurilishi skripti bo'ladimi yoki CI/CD jarayonida xavfsizlik auditi kabi narsa bo'ladimi ... buni oldini olish uchun juda ko'p oson variantlar mavjud.
Hikoyaning "kulgili" tomoni shundaki, agar Capital One birinchi navbatda teshikni yopib qo'yganida ... hech narsa bo'lmagan bo'lardi. Va shuning uchun, ochig'ini aytganda, bir narsaning qandayligini ko'rish har doim hayratda qoldiradi juda oddiy kompaniyaning buzib kirishi uchun yagona sabab bo'ladi. Ayniqsa, Capital One kabi katta.
Xo'sh, ichkarida xaker - keyin nima bo'ldi?
Xo'sh, EC2 namunasini buzgandan so'ng ... ko'p narsa noto'g'ri ketishi mumkin. Agar kimnidir shu qadar uzoqqa qo'yib yuborsangiz, siz deyarli pichoq chetida yurasiz. Lekin u S3 chelaklariga qanday kirdi? Buni tushunish uchun IAM rollarini muhokama qilaylik.
Shunday qilib, AWS xizmatlariga kirishning bir usuli bu foydalanuvchi bo'lishdir. OK, bu juda aniq. Agar siz ilova serverlari kabi boshqa AWS xizmatlariga S3 chelaklariga kirish huquqini berishni istasangiz-chi? IAM rollari aynan shu maqsadda. Ular ikkita komponentdan iborat:
- Ishonch siyosati - bu roldan qanday xizmatlar yoki odamlar foydalanishi mumkin?
- Ruxsatlar siyosati - bu rol nimaga imkon beradi?
Masalan, siz EC2 nusxalariga S3 paqiriga kirishga ruxsat beruvchi IAM rolini yaratmoqchisiz: Birinchidan, rol EC2 (butun xizmat) yoki muayyan misollar rolni “o‘z zimmasiga olishi” mumkin bo‘lgan Ishonch siyosatiga ega bo‘lishi uchun o‘rnatiladi. Rolni qabul qilish, ular harakatlarni bajarish uchun rol ruxsatlaridan foydalanishi mumkinligini anglatadi. Ikkinchidan, Ruxsatlar siyosati "rolni o'z zimmasiga olgan" xizmatga/shaxsga/resursga S3-da istalgan narsani bajarishga imkon beradi, xoh u bitta chelakga kirishi mumkinmi... yoki Capital One misolida bo'lgani kabi 700 dan ortiq.
IAM roli bilan EC2 misolida bo'lganingizdan so'ng, hisob ma'lumotlarini bir necha usul bilan olishingiz mumkin:
- Siz misol metamaʼlumotlarini soʻrashingiz mumkin
http://169.254.169.254/latest/meta-dataBoshqa narsalar qatorida, siz ushbu manzildagi istalgan kirish tugmalari bilan IAM rolini topishingiz mumkin. Albatta, agar siz bir misolda bo'lsangiz.
- AWS CLI dan foydalaning...
Agar AWS CLI o'rnatilgan bo'lsa, u mavjud bo'lsa, IAM rollarining hisob ma'lumotlari bilan yuklanadi. Qolgan narsa - bu misol orqali ishlash. Albatta, agar ularning Ishonch siyosati ochiq bo'lsa, Peyj hamma narsani bevosita qila olardi.
Shunday qilib, IAM rollarining mohiyati shundaki, ular ba'zi manbalarga BOSHQA RESURSLARDA SIZNING NOMONDAN HARAKAT qilishiga imkon beradi.
Endi siz IAM rollarini tushunganingizdan so'ng, Peyj Tompson nima qilgani haqida gapirishimiz mumkin:
- U xavfsizlik devoridagi teshik orqali serverga (EC2 nusxasi) kirish huquqiga ega bo'ldi
Xavfsizlik guruhlari/ACLlari yoki o'zlarining veb-ilovalarining xavfsizlik devorlari bo'ladimi, rasmiy yozuvlarda aytilganidek, teshikni ulash juda oson edi.
- Serverga kirgandan so'ng, u o'zini serverdek "xuddi" qila oldi
- IAM server roli S3-ga ushbu 700+ chelaklarga kirishga ruxsat berganligi sababli, u ularga kirishga muvaffaq bo'ldi
Shu paytdan boshlab u faqat buyruqni bajarishi kerak edi List Bucketsva keyin buyruq Sync AWS CLI dan...
. Bunday zararning oldini olish uchun kompaniyalar bulutli infratuzilmani himoya qilish, DevOps va xavfsizlik bo'yicha mutaxassislarga shunchalik ko'p sarmoya kiritadi. Va bulutga o'tish qanchalik qimmatli va tejamkor? Shu qadar ko'pki, hatto kiberxavfsizlik bo'yicha tobora ko'proq muammolarga duch kelganda ham !
Hikoyaning axloqi: xavfsizligingizni tekshiring; Muntazam auditlarni o'tkazish; Xavfsizlik siyosati uchun eng kam imtiyozlar tamoyilini hurmat qiling.
( To'liq huquqiy hisobotni ko'rishingiz mumkin).
Manba: www.habr.com