19-жылдын 2019-июлунда Capital One ар бир заманбап компания корккон билдирүүнү алды — маалымат бузулду. Андан 106 миллиондон ашык адам жабыркады. 140 АКШнын социалдык камсыздандыруу номерлери, бир миллион канадалык социалдык камсыздандыруу номерлери. 000 80 банк эсеби. Жагымсыз, макул эмессизби?
Тилекке каршы, бузукулук 19-июлда болгон жок. Маалым болгондой, Пейдж Томпсон, ака. Туура эмес, 22-жылдын 23-мартынан 2019-мартына чейин жасаган. Башкача айтканда дээрлик төрт ай мурун. Чынында, Capital One бир нерсе болгонун сырттан келген консультанттардын жардамы менен гана аныктай алган.
Амазонканын мурдагы кызматкери камакка алынып, 250 XNUMX доллар айып пул төлөп, беш жылга эркинен ажыратылышы мүмкүн... бирок дагы деле көп терс көрүнүштөр бар. Неге? Анткени хакерлерден жапа чеккен көптөгөн компаниялар киберкылмыштуулуктун өсүшүнүн шартында инфраструктурасын жана тиркемелерин чыңдоо жоопкерчилигинен баш тартууга аракет кылып жатышат.
Эмнеси болсо да, сиз бул окуяны Google'да оңой таба аласыз. Биз драмага кирбейбиз, бирок сүйлөшөбүз техникалык иштин жагы.
Биринчиден, эмне болду?
Capital Oneда 700дөй S3 чака иштеп турган, аларды Пейдж Томпсон көчүрүп алып, өчүрүп салган.
Экинчиден, бул туура эмес конфигурацияланган S3 чака саясатынын дагы бир учурубу?
Жок бул жолу эмес. Бул жерде ал туура эмес конфигурацияланган брандмауэр менен серверге кирүү мүмкүнчүлүгүн алды жана бүт операцияны ошол жерден аткарды.
Күтө туруңуз, бул кантип мүмкүн?
Келгиле, серверге кирүү менен баштайлы, бирок бизде көп маалымат жок. Бизге бул "туура эмес конфигурацияланган брандмауэр" аркылуу болгонун гана айтышты. Ошентип, коопсуздук тобунун туура эмес жөндөөлөрү же веб-тиркеме брандмауэринин (Imperva) же тармактык брандмауэрдин (iptables, ufw, shorewall ж.б.) конфигурациясы сыяктуу жөнөкөй нерсе. Capital One гана күнөөсүн мойнуна алып, тешик жапканын билдирди.
Стоундун айтымында, Capital One адегенде брандмауэрдин аялуулугун байкаган эмес, бирок аны билгенден кийин дароо иш-аракет кылган. Буга, албетте, хакердин коомдук доменде ачкычты аныктоочу маалыматты калтырып кеткени жардам берди, деди Стоун.
Эгер сиз эмне үчүн бул бөлүккө тереңирээк кирбей жатканыбызга кызыксаңыз, маалымат чектелүү болгондуктан, биз божомол гана айта аларыбызды түшүнүңүз. Хак Капитал One калтырган тешикке көз каранды экенин эске алганда, бул эч кандай мааниси жок. Жана алар бизге кененирээк маалымат бербесе, биз Capital One серверин ачык калтырган бардык мүмкүн болгон жолдорду тизмектейбиз жана кимдир бирөө ушул ар кандай варианттардын бирин колдоно ала турган бардык мүмкүн болгон жолдор менен айкалышта. Бул мүчүлүштүктөр жана ыкмалар укмуштуудай татаал схемаларга чейин өтө акылсыз көз салуулардан болушу мүмкүн. Мүмкүнчүлүктөрдүн диапазонун эске алганда, бул эч кандай реалдуу корутундусу жок узун дастанга айланат. Андыктан бизде фактылар бар бөлүгүн талдап чыгууга көңүл буралы.
Ошентип, биринчи алып кетүүчү нерсе: брандмауэрлериңиз эмнеге жол берерин билип алыңыз.
Ачылышы керек болгон нерсенин гана ачылышын камсыз кылуу үчүн саясатты же туура процессти түзүңүз. Эгер сиз Коопсуздук топтору же Тармактык ACL сыяктуу AWS ресурстарын колдонуп жатсаңыз, текшерүү үчүн текшерүү тизмеси узун болушу мүмкүн... бирок көптөгөн ресурстар автоматтык түрдө түзүлгөндөй эле (мис. CloudFormation), алардын аудитин автоматташтыруу да мүмкүн. Бул жаңы объекттерди кемчиликтерди издеген үйдө жасалган скрипт болобу, же CI/CD процессиндеги коопсуздук аудити сыяктуу... муну болтурбоо үчүн көптөгөн оңой варианттар бар.
Окуянын "күлкүлүү" жери, эгер Capital One биринчи кезекте тешикти жапса... эч нерсе болмок эмес. Ошентип, ачык айтканда, бир нерсенин чындыгында кандай болгонун көрүү дайыма таң калтырат абдан жөнөкөй компаниянын хакерликке дуушар болушунун жалгыз себеби болуп калат. Айрыкча Capital One сыяктуу чоң.
Ошентип, хакер ичиндеги - андан кийин эмне болду?
Ооба, EC2 инстанциясына киргенден кийин... көп нерсе туура эмес болуп кетиши мүмкүн. Эгер кимдир-бирөөнү ушунча алыска коё берсеңиз, сиз бычактын жээгинде басып жатасыз. Бирок ал S3 чакаларына кантип кирип калган? Муну түшүнүү үчүн, келгиле, IAM ролдорун талкуулайлы.
Ошентип, AWS кызматтарына кирүүнүн бир жолу - Колдонуучу болуу. Макул, бул абдан айкын. Бирок, эгер сиз башка AWS кызматтарын, мисалы, колдонмо серверлериңизге S3 чакаларыңызга кирүү мүмкүнчүлүгүн бергиңиз келсечи? IAM ролдору дал ушул үчүн. Алар эки компоненттен турат:
- Ишеним саясаты - бул ролду кандай кызматтар же адамдар колдоно алат?
- Уруксат саясаты - бул роль эмнеге мүмкүндүк берет?
Мисалы, сиз EC2 инстанцияларына S3 чакасына кирүү мүмкүнчүлүгүн берген IAM ролун түзгүңүз келет: Биринчиден, роль EC2 (бүт кызмат) же конкреттүү инстанциялар ролду "көзөмөлгө ала" турган Ишеним саясатына ээ болууга коюлган. Ролду кабыл алуу, алар аракеттерди аткаруу үчүн ролдун уруксаттарын колдоно алат дегенди билдирет. Экинчиден, Уруксат саясаты "ролду аткарган" кызматка/адамга/ресурска S3 боюнча кандайдыр бир нерсени жасоого мүмкүндүк берет, мейли ал белгилүү бир чакага киреби... же Capital Oneдагыдай 700дөн ашык.
IAM ролу менен EC2 инстанциясында болгондон кийин, ишеним грамоталарын бир нече жол менен ала аласыз:
- Сиз дареги боюнча инстанциянын метадайындарын сурасаңыз болот
http://169.254.169.254/latest/meta-dataБашка нерселер менен катар, сиз IAM ролун ушул даректен каалаган кирүү баскычтары менен таба аласыз. Албетте, бир гана учурда.
- AWS CLI колдонуңуз...
Эгерде AWS CLI орнотулган болсо, анда ал бар болсо, IAM ролдорунун эсептик маалыматтары менен жүктөлөт. Болгону, мисал аркылуу иштөө гана калды. Албетте, эгерде алардын Ишеним саясаты ачык болсо, Пейдж баарын түз эле жасай алмак.
Ошентип, IAM ролдорунун маңызы, алар кээ бир ресурстарга СЕНИН АТЫҢЫЗДАН БАШКА РЕСУРСТАРДА иш-аракет кылууга мүмкүндүк берет.
Эми сиз IAMдын ролун түшүнгөнүңүздөн кийин, Пейдж Томпсон эмне кылганы жөнүндө сүйлөшө алабыз:
- Ал серверге (EC2 инстанциясы) брандмауэрдеги тешик аркылуу кирүүгө мүмкүнчүлүк алды
Бул коопсуздук топтору/ACLs же өздөрүнүн веб-тиркеме брандмауэрлери болобу, расмий жазууларда айтылгандай, тешикти туташтыруу оңой болгон.
- Серверге киргенден кийин, ал сервердин өзүн "кандай" кыла алган
- IAM серверинин ролу S3 бул 700+ чакага кирүү мүмкүнчүлүгүн бергендиктен, ал аларга кире алган
Ошол учурдан тартып ал буйрукту аткаруу гана керек болчу List Bucketsанан буйрук Sync AWS CLIден...
. Мындай зыяндын алдын алуу үчүн компаниялар булут инфраструктурасын коргоого, DevOps жана коопсуздук боюнча эксперттерге көп каражат жумшайт. Жана булутка өтүү канчалык баалуу жана үнөмдүү? Ошентип, киберкоопсуздук боюнча барган сайын көп кыйынчылыктарга туш болгондо да !
Окуянын моралдык мааниси: коопсуздугуңузду текшериңиз; үзгүлтүксүз аудит жүргүзүү; Коопсуздук саясаты үчүн эң аз артыкчылык принцибин урматтаңыз.
( Сиз толук юридикалык отчетту көрө аласыз).
Source: www.habr.com