19 թվականի հուլիսի 2019-ին Capital One-ը ստացավ հաղորդագրություն, որ յուրաքանչյուր ժամանակակից ընկերություն վախենում է. տեղի է ունեցել տվյալների խախտում: Այն տուժել է ավելի քան 106 միլիոն մարդու վրա: 140 ԱՄՆ սոցիալական ապահովության համարներ, մեկ միլիոն կանադական սոցիալական ապահովության համարներ: 000 բանկային հաշիվ: Տհաճ, համաձայն չե՞ք։
Ցավոք, հաքերային հարձակումը տեղի չի ունեցել հուլիսի 19-ին: Ինչպես պարզվում է, Փեյջ Թոմփսոնը, a.k.a. Էրատիկ, այն կատարել է 22 թվականի մարտի 23-ից 2019-ը ընկած ժամանակահատվածում։ Այն է գրեթե չորս ամիս առաջ. Փաստորեն, միայն արտաքին խորհրդատուների օգնությամբ Capital One-ը կարողացավ բացահայտել, որ ինչ-որ բան է տեղի ունեցել:
Amazon-ի նախկին աշխատակիցը ձերբակալվել է և նրան սպառնում է 250 դոլար տուգանք և հինգ տարվա ազատազրկում... բայց դեռ շատ բացասականություն կա: Ինչո՞ւ։ Քանի որ շատ ընկերություններ, որոնք տուժել են հաքերներից, փորձում են թոթափել իրենց ենթակառուցվածքների և հավելվածների ամրապնդման պատասխանատվությունը՝ կիբերհանցագործությունների աճի պայմաններում:
Ինչևէ, այս պատմությունը հեշտությամբ կարող եք գուգլել։ Չենք խորանա դրամայի, այլ խոսենք դրա մասին տեխնիկական գործի կողմը։
Նախ՝ ի՞նչ է պատահել։
Capital One-ն ուներ մոտ 700 S3 դույլեր, որոնք Փեյջ Թոմփսոնը պատճենեց և հեռացրեց:
Երկրորդ, սա S3 դույլի քաղաքականության սխալ կազմաձևման հերթական դեպքն է:
Ոչ, այս անգամ ոչ: Այստեղ նա մուտք գործեց դեպի սխալ կազմաձևված firewall-ով սերվեր և այնտեղից իրականացրեց ամբողջ գործողությունը:
Սպասիր, ինչպե՞ս է դա հնարավոր։
Դե, եկեք սկսենք մուտք գործել սերվեր, թեև շատ մանրամասներ չունենք: Մեզ միայն ասացին, որ դա տեղի է ունեցել «սխալ կազմաձևված firewall»-ի միջոցով։ Այսպիսով, այնպիսի պարզ բան, ինչպիսին է սխալ անվտանգության խմբի կարգավորումները կամ վեբ հավելվածի firewall-ի (Imperva) կազմաձևումը կամ ցանցային firewall-ը (iptables, ufw, shorewall և այլն): Capital One-ը միայն ընդունեց իր մեղքը և ասաց, որ փակել է անցքը:
Սթոունն ասաց, որ Capital One-ը ի սկզբանե չէր նկատել firewall-ի խոցելիությունը, բայց արագ գործեց, երբ իմացավ դրա մասին: Դրան, անշուշտ, օգնել է այն փաստը, որ հաքերն իբր թողել է հիմնական նույնականացման տեղեկատվությունը հանրային տիրույթում, ասել է Սթոունը:
Եթե դուք մտածում եք, թե ինչու մենք չենք խորանում այս մասի մեջ, խնդրում ենք հասկանալ, որ սահմանափակ տեղեկատվության պատճառով մենք կարող ենք միայն ենթադրություններ անել: Սա անիմաստ է՝ հաշվի առնելով, որ հաքերային հարձակումը կախված էր Capital One-ի թողած անցքից: Եվ եթե նրանք մեզ ավելին չասեն, մենք պարզապես կթվարկենք այն բոլոր հնարավոր ուղիները, որոնցով Capital One-ը բաց թողեց իր սերվերը՝ համակցված բոլոր հնարավոր ուղիների հետ, որոնք ինչ-որ մեկը կարող էր օգտագործել այս տարբեր տարբերակներից մեկը: Այս թերություններն ու տեխնիկան կարող են տատանվել՝ սկսած ահավոր հիմար անտեսումներից մինչև անհավանական բարդ նախշեր: Հաշվի առնելով հնարավորությունների շրջանակը՝ սա երկար սագա կդառնա՝ առանց իրական եզրակացության: Ուստի կենտրոնանանք այն հատվածի վերլուծության վրա, որտեղ փաստեր ունենք։
Այսպիսով, առաջին քայլը հետևյալն է. իմացեք, թե ինչ են թույլ տալիս ձեր firewalls-ը:
Ստեղծեք քաղաքականություն կամ պատշաճ գործընթաց՝ ապահովելու համար, որ բացվի ՄԻԱՅՆ այն, ինչ պետք է բացվի: Եթե դուք օգտագործում եք AWS ռեսուրսներ, ինչպիսիք են Անվտանգության խմբերը կամ ցանցային ACL-ները, ակնհայտ է, որ աուդիտի ստուգաթերթը կարող է երկար լինել... բայց ինչպես շատ ռեսուրսներ են ստեղծվում ավտոմատ կերպով (այսինքն՝ CloudFormation), հնարավոր է նաև ավտոմատացնել դրանց աուդիտը: Անկախ նրանից, թե դա տնական սկրիպտ է, որը սկանավորում է նոր օբյեկտները թերությունների համար, թե անվտանգության աուդիտի նման մի բան CI/CD գործընթացում... կան շատ հեշտ տարբերակներ՝ խուսափելու համար:
Պատմության «զվարճալի» հատվածն այն է, որ եթե Capital One-ը ի սկզբանե փակեր անցքը... ոչինչ չէր լինի: Եվ այսպես, անկեղծ ասած, միշտ ցնցող է տեսնել, թե ինչպես է իրականում ինչ-որ բան բավականին պարզ դառնում է ընկերության հաքերային հարձակման միակ պատճառը: Հատկապես Capital One-ի չափ մեծ:
Այսպիսով, հաքեր ներսում. ի՞նչ եղավ հետո:
Դե, EC2 օրինակին ներխուժելուց հետո... շատ բան կարող է սխալվել: Դուք գործնականում քայլում եք դանակի եզրով, եթե թույլ եք տալիս մեկին այդքան հեռու գնալ: Բայց ինչպե՞ս այն մտավ S3 դույլերի մեջ: Սա հասկանալու համար եկեք քննարկենք IAM-ի դերերը:
Այսպիսով, AWS ծառայություններ մուտք գործելու եղանակներից մեկը Օգտատեր լինելն է: Լավ, սա բավականին ակնհայտ է: Բայց ի՞նչ, եթե ցանկանում եք այլ AWS ծառայություններ, ինչպիսիք են ձեր հավելվածի սերվերները, մուտք գործել ձեր S3 դույլերին: Ահա թե ինչի համար են IAM-ի դերերը: Դրանք բաղկացած են երկու բաղադրիչից.
- Վստահության քաղաքականություն. ի՞նչ ծառայություններ կամ մարդիկ կարող են օգտվել այս դերից:
- Թույլտվությունների քաղաքականություն. ի՞նչ է թույլ տալիս այս դերը:
Օրինակ, դուք ցանկանում եք ստեղծել IAM դեր, որը թույլ կտա EC2 ատյաններին մուտք գործել S3 դույլ. Նախ, դերը նախատեսված է ունենալ վստահության քաղաքականություն, որը EC2-ը (ամբողջ ծառայությունը) կամ կոնկրետ օրինակները կարող են «վերցնել» դերը: Դերը ընդունելը նշանակում է, որ նրանք կարող են օգտագործել դերի թույլտվությունները գործողություններ կատարելու համար: Երկրորդ, Թույլտվությունների քաղաքականությունը թույլ է տալիս ծառայությանը/անձին/ռեսուրսին, որը «իր վրա է վերցրել դերը» S3-ում որևէ բան անել, լինի դա մուտք գործել մեկ կոնկրետ դույլ... կամ ավելի քան 700, ինչպես Capital One-ի դեպքում:
Երբ դուք գտնվում եք EC2 օրինակում IAM-ի դերով, կարող եք հավատարմագրեր ստանալ մի քանի եղանակով.
- Դուք կարող եք պահանջել օրինակի մետատվյալներ այստեղ
http://169.254.169.254/latest/meta-dataԻ թիվս այլ բաների, դուք կարող եք գտնել IAM դերը այս հասցեի մուտքի ցանկացած ստեղներով: Իհարկե, միայն այն դեպքում, եթե դուք գտնվում եք մի օրինակում:
- Օգտագործեք AWS CLI...
Եթե AWS CLI-ն տեղադրված է, այն բեռնված է IAM-ի դերերից հավատարմագրերով, եթե առկա է: Մնում է աշխատել ատյանի ՄԻՋՈՑՈՎ։ Իհարկե, եթե նրանց վստահության քաղաքականությունը բաց լիներ, Փեյջը կարող էր ամեն ինչ անել ուղղակիորեն:
Այսպիսով, IAM-ի դերերի էությունն այն է, որ նրանք թույլ են տալիս որոշ ռեսուրսների գործել ՁԵՐ անունից ԱՅԼ ՌԵՍՈՒՐՍՆԵՐԻ վրա:
Այժմ, երբ դուք հասկանում եք IAM-ի դերերը, մենք կարող ենք խոսել այն մասին, թե ինչ արեց Փեյջ Թոմփսոնը.
- Նա մուտք է ստացել սերվեր (EC2 օրինակ) firewall-ի անցքի միջոցով
Անկախ նրանից, թե դա անվտանգության խմբեր/ACL-ներ էին, թե իրենց սեփական վեբ հավելվածի firewalls-ը, անցքը հավանաբար բավականին հեշտ էր միացնել, ինչպես նշված է պաշտոնական գրառումներում:
- Մի անգամ սերվերի վրա նա կարողացավ վարվել «կարծես» ինքը սերվերն էր
- Քանի որ IAM սերվերի դերը թույլ էր տալիս S3-ին մուտք գործել այս 700+ դույլեր, այն կարողացավ մուտք գործել դրանք
Այդ պահից նրան մնում էր միայն ղեկավարել հրամանատարությունը List Bucketsիսկ հետո հրամանը Sync AWS CLI-ից...
. Նման վնասների կանխարգելումն է պատճառը, որ ընկերությունները այդքան մեծ ներդրումներ են կատարում ամպային ենթակառուցվածքի պաշտպանության, DevOps-ի և անվտանգության փորձագետների մեջ: Իսկ որքանո՞վ է արժեքավոր և ծախսարդյունավետ տեղափոխվել դեպի ամպ: Այնքան, որ նույնիսկ կիբերանվտանգության ավելի ու ավելի շատ մարտահրավերների պայմաններում !
Պատմության բարոյականությունը. ստուգեք ձեր անվտանգությունը. Պարբերաբար ստուգումներ անցկացնել; Հարգեք անվտանգության քաղաքականության նվազագույն արտոնության սկզբունքը:
( Դուք կարող եք դիտել ամբողջական իրավական զեկույցը):
Source: www.habr.com