Ամպային անվտանգության մոնիտորինգ

Տվյալների և հավելվածների ամպ տեղափոխումը նոր մարտահրավեր է կորպորատիվ SOC-ների համար, որոնք միշտ չէ, որ պատրաստ են վերահսկել այլ մարդկանց ենթակառուցվածքը: Ըստ Netoskope-ի՝ միջին ձեռնարկությունը (ըստ երևույթին ԱՄՆ-ում) օգտագործում է 1246 տարբեր ամպային ծառայություններ, ինչը 22%-ով ավելի է, քան մեկ տարի առաջ։ 1246 ամպային ծառայություններ!!! Դրանցից 175-ը վերաբերում է HR ծառայություններին, 170-ը՝ մարքեթինգին, 110-ը՝ կապի, 76-ը՝ ֆինանսներին և CRM-ին։ Cisco-ն օգտագործում է «միայն» 700 արտաքին ամպային ծառայություններ: Այսպիսով, ես մի փոքր շփոթված եմ այս թվերով: Բայց ամեն դեպքում, խնդիրը նրանց մեջ չէ, այլ այն, որ ամպը սկսում է բավականին ակտիվորեն օգտագործել աճող թվով ընկերություններ, որոնք կցանկանային ունենալ ամպային ենթակառուցվածքի մոնիտորինգի նույն հնարավորությունները, ինչ իրենց սեփական ցանցում: Եվ այս միտումը աճում է - ըստ ըստ Ամերիկյան հաշվիչ պալատի Մինչեւ 2023 թվականը ԱՄՆ-ում պատրաստվում է փակել 1200 տվյալների կենտրոն (6250-ն արդեն փակվել է)։ Բայց ամպին անցումը պարզապես «եկեք տեղափոխենք մեր սերվերները արտաքին մատակարար» չէ: ՏՏ նոր ճարտարապետություն, նոր ծրագրային ապահովում, նոր գործընթացներ, նոր սահմանափակումներ... Այս ամենը էական փոփոխություններ է բերում ոչ միայն ՏՏ, այլ նաև տեղեկատվական անվտանգության ոլորտում։ Եվ եթե պրովայդերները սովորել են ինչ-որ կերպ հաղթահարել ամպի անվտանգության ապահովումը (բարեբախտաբար, շատ առաջարկություններ կան), ապա ամպային տեղեկատվության անվտանգության մոնիտորինգի դեպքում, հատկապես SaaS հարթակներում, կան զգալի դժվարություններ, որոնց մասին մենք կխոսենք:

Ենթադրենք, ձեր ընկերությունը իր ենթակառուցվածքի մի մասը տեղափոխել է ամպ... Դադարեցրեք: Ոչ այս կերպ: Եթե ​​ենթակառուցվածքը փոխանցվել է, և դուք միայն հիմա եք մտածում, թե ինչպես եք վերահսկելու այն, ուրեմն դուք արդեն պարտվել եք։ Եթե ​​դա Amazon-ը, Google-ը կամ Microsoft-ը չեն (և այնուհետև վերապահումներով), դուք, հավանաբար, ձեր տվյալները և հավելվածները վերահսկելու մեծ հնարավորություն չեք ունենա: Լավ է, եթե ձեզ հնարավորություն տրվի աշխատել գերանների հետ: Երբեմն անվտանգության միջոցառումների տվյալները հասանելի կլինեն, բայց դուք մուտք չեք ունենա դրանք: Օրինակ՝ Office 365. Եթե դուք ունեք ամենաէժան E1 լիցենզիան, ապա անվտանգության միջոցառումներն ընդհանրապես հասանելի չեն ձեզ համար: Եթե ​​դուք ունեք E3 լիցենզիա, ձեր տվյալները պահվում են ընդամենը 90 օր, և միայն այն դեպքում, եթե ունեք E5 լիցենզիա, տեղեկամատյանների տևողությունը հասանելի է մեկ տարի (սակայն, սա նաև ունի իր նրբությունները՝ կապված առանձին անելու անհրաժեշտության հետ. Microsoft-ի աջակցությամբ տեղեկամատյանների հետ աշխատելու համար մի շարք գործառույթներ պահանջեք): Ի դեպ, E3 լիցենզիան մոնիտորինգի գործառույթների առումով շատ ավելի թույլ է, քան կորպորատիվ Exchange-ը։ Նույն մակարդակին հասնելու համար ձեզ անհրաժեշտ է E5 լիցենզիա կամ լրացուցիչ Ընդլայնված Համապատասխանության լիցենզիա, որը կարող է պահանջել լրացուցիչ գումար, որը չի ներառվել ձեր ֆինանսական մոդելում ամպային ենթակառուցվածք տեղափոխվելու համար: Եվ սա ամպային տեղեկատվական անվտանգության մոնիտորինգի հետ կապված խնդիրների թերագնահատման ընդամենը մեկ օրինակ է։ Այս հոդվածում, առանց ամբողջական ձևանալու, ես ուզում եմ ուշադրություն հրավիրել որոշ նրբերանգների վրա, որոնք պետք է հաշվի առնել անվտանգության տեսանկյունից ամպային մատակարար ընտրելիս: Իսկ հոդվածի վերջում կտրվի ստուգաթերթ, որն արժե լրացնել՝ նախքան ամպային տեղեկատվական անվտանգության մոնիտորինգի հարցը լուծված համարելը։

Կան մի քանի բնորոշ խնդիրներ, որոնք հանգեցնում են միջադեպերի ամպային միջավայրում, որոնց տեղեկատվական անվտանգության ծառայությունները ժամանակ չունեն արձագանքելու կամ ընդհանրապես չեն տեսնում դրանք.

• Անվտանգության մատյանները գոյություն չունեն: Սա բավականին տարածված իրավիճակ է, հատկապես ամպային լուծումների շուկայում սկսնակ խաղացողների շրջանում: Բայց դուք չպետք է անմիջապես հրաժարվեք դրանցից: Փոքր խաղացողները, հատկապես ներքին, ավելի զգայուն են հաճախորդների պահանջների նկատմամբ և կարող են արագ իրականացնել որոշ պահանջվող գործառույթներ՝ փոխելով իրենց արտադրանքի հաստատված ճանապարհային քարտեզը: Այո, սա չի լինի Amazon-ի GuardDuty-ի կամ Bitrix-ի «Proactive Protection» մոդուլի անալոգը, բայց գոնե ինչ-որ բան:
• Տեղեկատվական անվտանգությունը չգիտի, թե որտեղ են պահվում տեղեկամատյանները կամ դրանց հասանելիություն չկա: Այստեղ անհրաժեշտ է բանակցությունների մեջ մտնել ամպային ծառայություններ մատուցողի հետ, միգուցե նա նման տեղեկատվություն տրամադրի, եթե հաճախորդը համարի իր համար կարևոր: Բայց, ընդհանուր առմամբ, այնքան էլ լավ չէ, երբ տեղեկամատյանների մուտքն ապահովվում է «հատուկ որոշմամբ»։
• Պատահում է նաև, որ ամպային մատակարարն ունի տեղեկամատյաններ, բայց դրանք ապահովում են սահմանափակ մոնիտորինգ և իրադարձությունների գրանցում, որոնք բավարար չեն բոլոր միջադեպերը հայտնաբերելու համար: Օրինակ, դուք կարող եք ստանալ միայն վեբկայքի փոփոխությունների մատյաններ կամ օգտատերերի նույնականացման փորձերի գրանցամատյաններ, բայց ոչ այլ իրադարձություններ, ինչպիսիք են ցանցային տրաֆիկը, որը ձեզնից կթաքցնի իրադարձությունների մի ամբողջ շերտ, որը բնութագրում է ձեր ամպային ենթակառուցվածքը կոտրելու փորձերը:
• Կան տեղեկամատյաններ, բայց դրանց մուտքը դժվար է ավտոմատացնել, ինչը ստիպում է նրանց վերահսկել ոչ թե անընդհատ, այլ ժամանակացույցով։ Եվ եթե դուք չեք կարող ինքնաբերաբար ներբեռնել տեղեկամատյանները, ապա տեղեկամատյանների ներբեռնումը, օրինակ, Excel ձևաչափով (ինչպես տեղական ամպային լուծումների մի շարք մատակարարների դեպքում), կարող է նույնիսկ հանգեցնել կորպորատիվ տեղեկատվական անվտանգության ծառայության կողմից դրանց հետ չհամագործակցելու դժկամությանը:
• Մատյանների մոնիտորինգ չկա: Սա, թերեւս, ամենաանհասկանալի պատճառն է ամպային միջավայրում տեղեկատվական անվտանգության միջադեպերի առաջացման համար: Թվում է, թե կան տեղեկամատյաններ, և հնարավոր է ավտոմատացնել դրանց մուտքը, բայց ոչ ոք դա չի անում: Ինչո՞ւ։

Համօգտագործվող ամպային անվտանգության հայեցակարգ

Ամպային անցումը միշտ հավասարակշռության որոնում է ենթակառուցվածքի նկատմամբ վերահսկողությունը պահպանելու ցանկության և այն փոխանցելու ամպային մատակարարի ավելի պրոֆեսիոնալ ձեռքերին, որը մասնագիտացած է դրա պահպանման մեջ: Իսկ ամպային անվտանգության ոլորտում նույնպես պետք է փնտրել այս հավասարակշռությունը։ Ավելին, կախված օգտագործվող ամպային ծառայությունների մատուցման մոդելից (IaaS, PaaS, SaaS), այս հաշվեկշիռը միշտ տարբեր կլինի: Ամեն դեպքում, մենք պետք է հիշենք, որ այսօր բոլոր ամպային պրովայդերները հետևում են, այսպես կոչված, ընդհանուր պատասխանատվության և ընդհանուր տեղեկատվական անվտանգության մոդելին: Ամպը պատասխանատու է որոշ բաների համար, իսկ մյուսների համար պատասխանատու է հաճախորդը՝ տեղադրելով իր տվյալները, իր հավելվածները, իր վիրտուալ մեքենաները և այլ ռեսուրսներ ամպի մեջ: Անխոհեմ կլիներ ակնկալել, որ գնալով ամպի վրա՝ մենք ողջ պատասխանատվությունը կփոխանցենք մատակարարի վրա: Բայց նաև խելամիտ չէ ամբողջ անվտանգությունը ինքներդ ստեղծել, երբ տեղափոխվում եք ամպ: Պահանջվում է հավասարակշռություն, որը կախված կլինի բազմաթիվ գործոններից. - ռիսկերի կառավարման ռազմավարություն, սպառնալիքի մոդել, ամպային մատակարարին հասանելի անվտանգության մեխանիզմներ, օրենսդրություն և այլն:

Օրինակ, ամպում տեղակայված տվյալների դասակարգումը միշտ էլ հաճախորդի պարտականությունն է: Ամպային մատակարարը կամ արտաքին ծառայությունների մատակարարը կարող է օգնել նրան միայն այնպիսի գործիքներով, որոնք կօգնեն նշել տվյալները ամպում, բացահայտել խախտումները, ջնջել տվյալներ, որոնք խախտում են օրենքը կամ քողարկել դրանք այս կամ այն ​​եղանակով: Մյուս կողմից, ֆիզիկական անվտանգությունը միշտ ամպային մատակարարի պարտականությունն է, որը նա չի կարող կիսել հաճախորդների հետ: Բայց այն ամենը, ինչ գտնվում է տվյալների և ֆիզիկական ենթակառուցվածքի միջև, հենց այս հոդվածում քննարկման առարկա է: Օրինակ, ամպի առկայությունը մատակարարի պատասխանատվությունն է, իսկ firewall-ի կանոնների կարգավորումը կամ գաղտնագրման հնարավորությունը հաճախորդի պարտականությունն է: Այս հոդվածում մենք կփորձենք տեսնել, թե ինչ տեղեկատվական անվտանգության մոնիտորինգի մեխանիզմներ են այսօր տրամադրվում Ռուսաստանում տարբեր հանրաճանաչ ամպային մատակարարների կողմից, որոնք են դրանց օգտագործման առանձնահատկությունները և երբ արժե նայել արտաքին ծածկույթի լուծումներին (օրինակ՝ Cisco E- փոստի անվտանգություն), որոնք ընդլայնում են ձեր ամպի հնարավորությունները կիբերանվտանգության առումով: Որոշ դեպքերում, հատկապես, եթե հետևում եք բազմաբնույթ ամպային ռազմավարությանը, դուք այլ ելք չեք ունենա, քան օգտագործել արտաքին տեղեկատվական անվտանգության մոնիտորինգի լուծումները միանգամից մի քանի ամպային միջավայրերում (օրինակ՝ Cisco CloudLock կամ Cisco Stealthwatch Cloud): Դե, որոշ դեպքերում դուք կհասկանաք, որ ձեր ընտրած (կամ ձեզ պարտադրված) ամպային մատակարարը ընդհանրապես չի առաջարկում տեղեկատվական անվտանգության մոնիտորինգի որևէ հնարավորություն։ Սա տհաճ է, բայց նաև ոչ քիչ, քանի որ թույլ է տալիս համարժեք գնահատել այս ամպի հետ աշխատելու հետ կապված ռիսկի մակարդակը:

Ամպային անվտանգության մոնիտորինգի կյանքի ցիկլը

Ձեր օգտագործած ամպերի անվտանգությունը վերահսկելու համար դուք ունեք ընդամենը երեք տարբերակ.

• ապավինեք ձեր ամպային մատակարարի տրամադրած գործիքներին,
• օգտագործել երրորդ կողմերի լուծումները, որոնք կվերահսկեն ձեր օգտագործած IaaS, PaaS կամ SaaS հարթակները,
• ստեղծեք ձեր սեփական ամպային մոնիտորինգի ենթակառուցվածքը (միայն IaaS/PaaS հարթակների համար):

Տեսնենք, թե ինչ առանձնահատկություններ ունի այս տարբերակներից յուրաքանչյուրը: Բայց նախ, մենք պետք է հասկանանք ընդհանուր շրջանակը, որը կօգտագործվի ամպային հարթակների մոնիտորինգի ժամանակ: Ես կառանձնացնեի ամպում տեղեկատվական անվտանգության մոնիտորինգի գործընթացի 6 հիմնական բաղադրիչ.

• Ենթակառուցվածքների պատրաստում. Պահեստում տեղեկատվական անվտանգության համար կարևոր իրադարձությունների հավաքագրման համար անհրաժեշտ հավելվածների և ենթակառուցվածքների որոշում:
• Հավաքածու. Այս փուլում անվտանգության միջոցառումները համախմբվում են տարբեր աղբյուրներից՝ հետագա փոխանցման համար՝ մշակման, պահպանման և վերլուծության համար:
• Բուժում. Այս փուլում տվյալները փոխակերպվում և հարստացվում են հետագա վերլուծությունը հեշտացնելու համար:
• Պահպանում. Այս բաղադրիչը պատասխանատու է հավաքագրված մշակված և չմշակված տվյալների կարճաժամկետ և երկարաժամկետ պահպանման համար:
• Վերլուծություն. Այս փուլում դուք հնարավորություն ունեք հայտնաբերել միջադեպերը և արձագանքել դրանց ավտոմատ կամ ձեռքով:
• Հաշվետվություն. Այս փուլն օգնում է շահագրգիռ կողմերի (կառավարում, աուդիտորներ, ամպի մատակարար, հաճախորդներ և այլն) համար ձևակերպել հիմնական ցուցիչներ, որոնք օգնում են մեզ որոշակի որոշումներ կայացնել, օրինակ՝ փոխել մատակարարին կամ ամրապնդել տեղեկատվական անվտանգությունը:

Այս բաղադրիչները հասկանալը թույլ կտա ձեզ արագ որոշել ապագայում, թե ինչ կարող եք վերցնել ձեր մատակարարից և ինչ պետք է անեք ինքներդ կամ արտաքին խորհրդատուների ներգրավմամբ:

Ներկառուցված ամպային ծառայություններ

Ես արդեն գրել եմ վերևում, որ այսօր շատ ամպային ծառայություններ չեն ապահովում տեղեկատվական անվտանգության մոնիտորինգի որևէ հնարավորություն: Ընդհանուր առմամբ, տեղեկատվական անվտանգության թեմային առանձնապես ուշադրություն չեն դարձնում։ Օրինակ՝ ռուսական հանրահայտ ծառայություններից մեկը՝ ինտերնետի միջոցով պետական ​​կառույցներին հաշվետվություններ ուղարկելու համար (կոնկրետ անունը չեմ նշի)։ Այս ծառայության անվտանգության մասին ամբողջ բաժինը պտտվում է հավաստագրված CIPF-ի օգտագործման շուրջ: Էլեկտրոնային փաստաթղթերի կառավարման մեկ այլ ներքին ամպային ծառայության տեղեկատվական անվտանգության բաժինը չի տարբերվում: Այն խոսում է հանրային բանալիների վկայագրերի, վավերացված ծածկագրության, վեբ խոցելիության վերացման, DDoS հարձակումներից պաշտպանության, firewalls-ի, կրկնօրինակների և նույնիսկ տեղեկատվական անվտանգության կանոնավոր ստուգումների մասին: Բայց խոսք չկա մոնիտորինգի մասին, ոչ էլ տեղեկատվական անվտանգության միջոցառումներին հասանելիություն ստանալու հնարավորության մասին, որոնք կարող են հետաքրքրել այս ծառայություն մատուցողի հաճախորդներին:

Ընդհանրապես, ի դեպ, ամպի մատակարարը նկարագրում է տեղեկատվական անվտանգության խնդիրները իր կայքում և իր փաստաթղթերում, դուք կարող եք հասկանալ, թե որքան լուրջ է նա վերաբերվում այս հարցին: Օրինակ, եթե դուք կարդում եք «My Office» արտադրանքի ձեռնարկները, ապա ընդհանրապես խոսք չկա անվտանգության մասին, այլ առանձին արտադրանքի փաստաթղթերում «My Office. KS3», որը նախատեսված է չարտոնված մուտքից պաշտպանվելու համար, կա FSTEC-ի 17-րդ կարգի կետերի սովորական ցուցակ, որը իրականացնում է «My Office.KS3»-ը, բայց նկարագրված չէ, թե ինչպես է այն իրականացնում և, ամենակարևորը, ինչպես ինտեգրել այս մեխանիզմները կորպորատիվ տեղեկատվական անվտանգության հետ: Թերևս այդպիսի փաստաթղթեր կան, բայց ես այն չգտա հանրային սեփականությունում՝ «Իմ գրասենյակ» կայքում։ Թեև միգուցե ես պարզապես մուտք չունեմ այս գաղտնի տեղեկատվությանը:

Bitrix-ի համար իրավիճակը շատ ավելի լավ է։ Փաստաթղթերը նկարագրում են իրադարձությունների մատյանների ձևաչափերը և, հետաքրքիր է, ներխուժման գրանցամատյանը, որը պարունակում է իրադարձություններ՝ կապված ամպային հարթակի հնարավոր սպառնալիքների հետ: Այնտեղից կարող եք դուրս բերել IP-ն, օգտատիրոջ կամ հյուրի անունը, միջոցառման աղբյուրը, ժամը, Օգտատիրոջ գործակալը, միջոցառման տեսակը և այլն: Ճիշտ է, դուք կարող եք աշխատել այս իրադարձությունների հետ կամ հենց ամպի կառավարման վահանակից, կամ վերբեռնել տվյալները MS Excel ձևաչափով: Այժմ դժվար է ավտոմատացնել աշխատանքը Bitrix տեղեկամատյանների հետ, և դուք ստիպված կլինեք որոշ աշխատանքներ կատարել ձեռքով (վերբեռնել զեկույցը և բեռնել այն ձեր SIEM-ում): Բայց եթե հիշենք, որ մինչև համեմատաբար վերջերս նման հնարավորություն չկար, ապա սա մեծ առաջընթաց է։ Միևնույն ժամանակ, ես կցանկանայի նշել, որ շատ օտարերկրյա ամպային պրովայդերներ առաջարկում են նմանատիպ ֆունկցիոնալություն «սկսնակների համար». csv ձևաչափ, ոչ թե Excel):

Առանց հաշվի առնելու առանց գրանցամատյանների տարբերակը, ամպային մատակարարները սովորաբար առաջարկում են ձեզ երեք տարբերակ անվտանգության միջոցառումների մոնիտորինգի համար՝ վահանակներ, տվյալների վերբեռնում և API մուտք: Թվում է, թե առաջինը ձեզ համար շատ խնդիրներ է լուծում, բայց դա ամբողջովին ճիշտ չէ. եթե ունեք մի քանի ամսագրեր, դուք պետք է անցնեք դրանք ցուցադրող էկրանների միջև՝ կորցնելով ընդհանուր պատկերը: Բացի այդ, ամպային մատակարարը դժվար թե ձեզ ապահովի անվտանգության իրադարձությունները փոխկապակցելու և դրանք ընդհանուր առմամբ վերլուծելու անվտանգության տեսանկյունից (սովորաբար դուք գործ ունեք չմշակված տվյալների հետ, որոնք դուք ինքներդ պետք է հասկանաք): Կան բացառություններ, որոնց մասին մենք կխոսենք ավելի ուշ: Վերջապես, արժե հարցնել, թե ինչ իրադարձություններ են գրանցվում ձեր ամպային մատակարարի կողմից, ինչ ձևաչափով և ինչպես են դրանք համապատասխանում ձեր տեղեկատվական անվտանգության մոնիտորինգի գործընթացին: Օրինակ՝ օգտատերերի և հյուրերի նույնականացում և նույնականացում: Նույն Bitrix-ը թույլ է տալիս, հիմնվելով այս իրադարձությունների վրա, գրանցել իրադարձության ամսաթիվը և ժամը, օգտատիրոջ կամ հյուրի անունը (եթե ունեք «Web Analytics» մոդուլը), մուտք գործած օբյեկտը և վեբկայքի համար բնորոշ այլ տարրեր։ . Սակայն կորպորատիվ տեղեկատվական անվտանգության ծառայություններին կարող են անհրաժեշտ լինել տեղեկատվություն այն մասին, թե արդյոք օգտատերը մուտք է գործել ամպ վստահելի սարքից (օրինակ, կորպորատիվ ցանցում այս առաջադրանքն իրականացվում է Cisco ISE-ի կողմից): Ի՞նչ կասեք այնպիսի պարզ առաջադրանքի մասին, ինչպիսին է աշխարհագրական IP ֆունկցիան, որը կօգնի պարզել, թե արդյոք գողացվել է ամպային ծառայության օգտատերերի հաշիվը: Եվ նույնիսկ եթե ամպի մատակարարը տրամադրի այն ձեզ, դա բավարար չէ: Նույն Cisco CloudLock-ը ոչ միայն վերլուծում է աշխարհագրական դիրքը, այլ դրա համար օգտագործում է մեքենայական ուսուցում և վերլուծում է պատմական տվյալները յուրաքանչյուր օգտագործողի համար և վերահսկում է տարբեր անոմալիաները նույնականացման և նույնականացման փորձերում: Միայն MS Azure-ն ունի նմանատիպ գործառույթ (եթե ունեք համապատասխան բաժանորդագրություն):

Կա ևս մեկ դժվարություն. քանի որ շատ ամպային մատակարարների համար տեղեկատվական անվտանգության մոնիտորինգը նոր թեմա է, որով նրանք նոր են սկսում զբաղվել, նրանք անընդհատ ինչ-որ բան են փոխում իրենց լուծումներում: Այսօր նրանք ունեն API-ի մեկ տարբերակ, վաղը մեկ այլ տարբերակ, վաղը մյուսը՝ երրորդ: Դուք նույնպես պետք է պատրաստ լինեք դրան: Նույնը վերաբերում է ֆունկցիոնալությանը, որը կարող է փոխվել, ինչը պետք է հաշվի առնել ձեր տեղեկատվական անվտանգության մոնիտորինգի համակարգում: Օրինակ, Amazon-ը սկզբում ուներ առանձին ամպային իրադարձությունների մոնիտորինգի ծառայություններ՝ AWS CloudTrail և AWS CloudWatch: Այնուհետև հայտնվեց տեղեկատվական անվտանգության իրադարձությունների մոնիտորինգի առանձին ծառայություն՝ AWS GuardDuty: Որոշ ժամանակ անց Amazon-ը գործարկեց կառավարման նոր համակարգ՝ Amazon Security Hub, որը ներառում է GuardDuty-ից, Amazon Inspector-ից, Amazon Macie-ից և մի քանի այլ ընկերություններից ստացված տվյալների վերլուծություն: Մեկ այլ օրինակ է Azure log ինտեգրման գործիքը SIEM - AzLog-ի հետ: Այն ակտիվորեն օգտագործվում էր SIEM-ի շատ վաճառողների կողմից, մինչև 2018-ին Microsoft-ը հայտարարեց իր զարգացման և աջակցության դադարեցման մասին, ինչի պատճառով այս գործիքն օգտագործող շատ հաճախորդներ բախվեցին խնդրի հետ (մենք կխոսենք այն մասին, թե ինչպես է այն լուծվել ավելի ուշ):

Հետևաբար, ուշադիր հետևեք մոնիտորինգի բոլոր հնարավորություններին, որոնք ձեզ առաջարկում է ձեր ամպային մատակարարը: Կամ ապավինեք լուծումների արտաքին մատակարարներին, որոնք միջնորդներ կլինեն ձեր SOC-ի և ամպի միջև, որը ցանկանում եք վերահսկել: Այո, դա ավելի թանկ կլինի (թեև ոչ միշտ), բայց դուք ամբողջ պատասխանատվությունը կփոխանցեք ուրիշի ուսերին։ Թե՞ ոչ ամբողջը... Եկեք հիշենք ընդհանուր անվտանգության հայեցակարգը և հասկանանք, որ մենք ոչինչ չենք կարող փոխել. մենք պետք է ինքնուրույն հասկանանք, թե ինչպես են տարբեր ամպային մատակարարներ ապահովում ձեր տվյալների, հավելվածների, վիրտուալ մեքենաների և այլ ռեսուրսների տեղեկատվական անվտանգության մոնիտորինգը: հյուրընկալվել է ամպի մեջ: Եվ մենք կսկսենք նրանից, թե ինչ է առաջարկում Amazon-ն այս մասում:

Օրինակ. Տեղեկատվական անվտանգության մոնիտորինգ IaaS-ում՝ հիմնված AWS-ի վրա

Այո, այո, ես հասկանում եմ, որ Amazon-ը լավագույն օրինակը չէ, քանի որ սա ամերիկյան ծառայություն է և այն կարող է արգելափակվել որպես ծայրահեղականության դեմ պայքարի և Ռուսաստանում արգելված տեղեկատվության տարածման մաս։ Բայց այս հրապարակման մեջ ես պարզապես կցանկանայի ցույց տալ, թե ինչպես են տարբեր ամպային հարթակներն իրենց տեղեկատվական անվտանգության մոնիտորինգի հնարավորություններով և ինչի վրա պետք է ուշադրություն դարձնեք ձեր հիմնական գործընթացները ամպերին անվտանգության տեսանկյունից փոխանցելիս: Դե, եթե ռուսաստանյան ամպային լուծումներ մշակողներից ոմանք իրենց համար օգտակար բան սովորեն, ապա դա հիանալի կլինի:

Առաջինն այն է, որ Ամազոնը անթափանց ամրոց չէ։ Նրա հաճախորդների հետ պարբերաբար տեղի են ունենում տարբեր միջադեպեր։ Օրինակ՝ Deep Root Analytics-ից գողացել են 198 միլիոն ընտրողների անունները, հասցեները, ծննդյան տարեթիվը և հեռախոսահամարները: Իսրայելական Nice Systems ընկերությունը գողացել է Verizon-ի բաժանորդների 14 միլիոն ձայնագրություն։ Այնուամենայնիվ, AWS-ի ներկառուցված հնարավորությունները թույլ են տալիս հայտնաբերել միջադեպերի լայն շրջանակ: Օրինակ:

• ազդեցություն ենթակառուցվածքի վրա (DDoS)
• հանգույցի փոխզիջում (հրամանի ներարկում)
• հաշվի խախտում և չարտոնված մուտք
• սխալ կազմաձևեր և խոցելիություններ
• անապահով միջերեսներ և API-ներ:

Այս անհամապատասխանությունը պայմանավորված է նրանով, որ, ինչպես պարզեցինք վերևում, հաճախորդն ինքն է պատասխանատու հաճախորդների տվյալների անվտանգության համար: Իսկ եթե նա չփորձեց միացնել պաշտպանիչ մեխանիզմները և չմիացրեց մոնիտորինգի գործիքները, ապա դեպքի մասին կտեղեկանա միայն լրատվամիջոցներից կամ իր պաշտպանյալներից։

Միջադեպերը բացահայտելու համար դուք կարող եք օգտագործել Amazon-ի կողմից մշակված տարբեր մոնիտորինգի ծառայությունների լայն շրջանակ (չնայած դրանք հաճախ լրացվում են արտաքին գործիքներով, ինչպիսիք են osquery-ը): Այսպիսով, AWS-ում օգտատերերի բոլոր գործողությունները վերահսկվում են, անկախ նրանից, թե ինչպես են դրանք իրականացվում՝ կառավարման վահանակի, հրամանի տողի, SDK-ի կամ այլ AWS ծառայությունների միջոցով: AWS-ի յուրաքանչյուր հաշվի գործունեության (ներառյալ օգտանունը, գործողությունը, ծառայությունը, գործունեության պարամետրերը և արդյունքը) և API-ի օգտագործման բոլոր գրառումները հասանելի են AWS CloudTrail-ի միջոցով: Դուք կարող եք դիտել այս իրադարձությունները (օրինակ՝ AWS IAM կոնսոլի մուտքերը) CloudTrail վահանակից, վերլուծել դրանք Amazon Athena-ի միջոցով կամ «արտահանձնել» արտաքին լուծումներին, ինչպիսիք են Splunk, AlienVault և այլն: AWS CloudTrail-ի տեղեկամատյաններն իրենք տեղադրվում են ձեր AWS S3 դույլի մեջ:

Երկու այլ AWS ծառայություններ ապահովում են մի շարք այլ կարևոր մոնիտորինգի հնարավորություններ: Նախ, Amazon CloudWatch-ը AWS ռեսուրսների և հավելվածների մոնիտորինգի ծառայություն է, որը, ի թիվս այլ բաների, թույլ է տալիս բացահայտել տարբեր անոմալիաներ ձեր ամպում: Բոլոր ներկառուցված AWS ծառայությունները, ինչպիսիք են Amazon Elastic Compute Cloud (սերվերներ), Amazon Relational Database Service (տվյալների բազաներ), Amazon Elastic MapReduce (տվյալների վերլուծություն) և 30 այլ Amazon ծառայություններ, օգտագործում են Amazon CloudWatch՝ իրենց տեղեկամատյանները պահելու համար: Մշակողները կարող են օգտագործել բաց API-ն Amazon CloudWatch-ից՝ մատյանների մոնիտորինգի գործառույթն ավելացնելու մաքսային հավելվածներին և ծառայություններին՝ թույլ տալով նրանց ընդլայնել իրադարձությունների վերլուծության շրջանակը անվտանգության համատեքստում:

Երկրորդ, VPC Flow Logs ծառայությունը թույլ է տալիս վերլուծել ձեր AWS սերվերների կողմից ուղարկված կամ ստացված ցանցային տրաֆիկը (արտաքին կամ ներքին), ինչպես նաև միկրոծառայությունների միջև: Երբ ձեր AWS VPC ռեսուրսներից որևէ մեկը փոխազդում է ցանցի հետ, VPC Flow Logs-ը գրանցում է մանրամասներ ցանցի տրաֆիկի մասին, ներառյալ աղբյուրի և նպատակակետ ցանցի միջերեսը, ինչպես նաև IP հասցեները, նավահանգիստները, արձանագրությունը, բայթերի քանակը և փաթեթների քանակը: տեսավ. Նրանք, ովքեր փորձառու են տեղական ցանցի անվտանգության հետ, դա կճանաչեն որպես թելերի անալոգ NetFlow, որը կարող է ստեղծվել անջատիչների, երթուղիչների և ձեռնարկության կարգի firewalls-ի միջոցով: Այս տեղեկամատյանները կարևոր են տեղեկատվական անվտանգության մոնիտորինգի նպատակների համար, քանի որ, ի տարբերություն օգտատերերի և հավելվածների գործողությունների, դրանք նաև թույլ են տալիս բաց չթողնել ցանցային փոխազդեցությունները AWS վիրտուալ մասնավոր ամպային միջավայրում:

Ամփոփելով, այս երեք AWS ծառայությունները՝ AWS CloudTrail, Amazon CloudWatch և VPC Flow Logs, միասին բավական հզոր պատկերացում են տալիս ձեր հաշվի օգտագործման, օգտատիրոջ վարքագծի, ենթակառուցվածքի կառավարման, հավելվածների և ծառայությունների գործունեության և ցանցային գործունեության վերաբերյալ: Օրինակ, դրանք կարող են օգտագործվել հետևյալ անոմալիաները հայտնաբերելու համար.

• Կայքը սկանավորելու, հետին դռների որոնում, խոցելիության որոնում «404 սխալների» պայթյունների միջոցով:
• Ներարկման հարձակումներ (օրինակ, SQL ներարկում) «500 սխալների» պայթյունների միջոցով:
• Հարձակման հայտնի գործիքներն են sqlmap, nikto, w3af, nmap և այլն: User Agent դաշտի վերլուծության միջոցով:

Amazon Web Services-ը նաև կիբերանվտանգության նպատակով մշակել է այլ ծառայություններ, որոնք թույլ են տալիս լուծել բազմաթիվ այլ խնդիրներ: Օրինակ, AWS-ն ունի ներկառուցված ծառայություն աուդիտի քաղաքականության և կոնֆիգուրացիաների համար՝ AWS Config: Այս ծառայությունը ապահովում է ձեր AWS ռեսուրսների և դրանց կոնֆիգուրացիաների շարունակական աուդիտ: Եկեք մի պարզ օրինակ բերենք. Ենթադրենք, դուք ցանկանում եք համոզվել, որ օգտվողի գաղտնաբառերն անջատված են ձեր բոլոր սերվերներում, և որ մուտքը հնարավոր է միայն վկայագրերի հիման վրա: AWS Config-ը հեշտացնում է սա ստուգելը ձեր բոլոր սերվերների համար: Կան այլ քաղաքականություններ, որոնք կարող են կիրառվել ձեր ամպային սերվերների վրա. «Ոչ մի սերվեր չի կարող օգտագործել պորտ 22», «Միայն ադմինիստրատորները կարող են փոխել firewall-ի կանոնները» կամ «Միայն օգտվող Իվաշկոն կարող է ստեղծել նոր օգտվողների հաշիվներ, և նա կարող է դա անել միայն երեքշաբթի օրերին: « 2016 թվականի ամռանը AWS Config ծառայությունն ընդլայնվեց՝ մշակված քաղաքականության խախտումների հայտնաբերման ավտոմատացման համար: AWS Config կանոնները, ըստ էության, շարունակական կազմաձևման հարցումներ են ձեր կողմից օգտագործվող Amazon ծառայությունների համար, որոնք առաջացնում են իրադարձություններ, եթե համապատասխան քաղաքականությունը խախտվում է: Օրինակ՝ AWS Config հարցումները պարբերաբար գործարկելու փոխարեն՝ ստուգելու համար, որ վիրտուալ սերվերի բոլոր սկավառակները գաղտնագրված են, AWS Config կանոնները կարող են օգտագործվել սերվերի սկավառակները շարունակաբար ստուգելու համար՝ համոզվելու, որ այս պայմանը բավարարված է: Եվ, ամենակարևորը, այս հրապարակման համատեքստում ցանկացած խախտում առաջացնում է իրադարձություններ, որոնք կարող են վերլուծվել ձեր տեղեկատվական անվտանգության ծառայության կողմից:

AWS-ն ունի նաև իր համարժեքը ավանդական կորպորատիվ տեղեկատվական անվտանգության լուծումներին, որոնք նաև ստեղծում են անվտանգության միջոցառումներ, որոնք դուք կարող եք և պետք է վերլուծեք.

• Ներխուժման հայտնաբերում - AWS GuardDuty
• Տեղեկատվության արտահոսքի վերահսկում - AWS Macie
• EDR (թեև այն մի փոքր տարօրինակ կերպով խոսում է ամպի վերջնակետերի մասին) - AWS Cloudwatch + բաց կոդով osquery կամ GRR լուծումներ
• Netflow վերլուծություն - AWS Cloudwatch + AWS VPC Flow
• DNS վերլուծություն - AWS Cloudwatch + AWS Route53
• AD - AWS տեղեկատու ծառայություն
• Հաշվի կառավարում - AWS IAM
• SSO - AWS SSO
• անվտանգության վերլուծություն - AWS տեսուչ
• կոնֆիգուրացիայի կառավարում - AWS Config
• WAF - AWS WAF.

Ես մանրամասն չեմ նկարագրի Amazon-ի բոլոր ծառայությունները, որոնք կարող են օգտակար լինել տեղեկատվական անվտանգության համատեքստում: Հիմնական բանը հասկանալն է, որ դրանք բոլորը կարող են առաջացնել իրադարձություններ, որոնք մենք կարող ենք և պետք է վերլուծենք տեղեկատվական անվտանգության համատեքստում, այդ նպատակով օգտագործելով ինչպես Amazon-ի ներկառուցված հնարավորությունները, այնպես էլ արտաքին լուծումները, օրինակ՝ SIEM-ը, որը կարող է. Անվտանգության իրադարձությունները տեղափոխեք ձեր մոնիտորինգի կենտրոն և վերլուծեք դրանք այլ ամպային ծառայություններից կամ ներքին ենթակառուցվածքից, պարագծից կամ շարժական սարքերից ստացվող իրադարձությունների հետ միասին:

Ամեն դեպքում, ամեն ինչ սկսվում է տվյալների աղբյուրներից, որոնք ձեզ տրամադրում են տեղեկատվական անվտանգության միջոցառումներ: Այս աղբյուրները ներառում են, բայց չեն սահմանափակվում հետևյալով.

• CloudTrail - API-ի օգտագործում և օգտագործողի գործողություններ
• Վստահելի խորհրդատու՝ անվտանգության ստուգում լավագույն փորձի դեմ
• Կազմաձև - հաշիվների և ծառայության կարգավորումների գույքագրում և կազմաձևում
• VPC հոսքի տեղեկամատյաններ - միացումներ վիրտուալ ինտերֆեյսներին
• IAM - նույնականացման և նույնականացման ծառայություն
• ELB Access Logs - Load Balancer
• Տեսուչ - կիրառական խոցելիություններ
• S3 - ֆայլերի պահեստավորում
• CloudWatch - Հավելվածի գործունեություն
• SNS-ը ծանուցման ծառայություն է:

Amazon-ը, իր սերնդի համար իրադարձության աղբյուրների և գործիքների նման շարք առաջարկելով, շատ սահմանափակ է հավաքագրված տվյալները տեղեկատվական անվտանգության համատեքստում վերլուծելու իր կարողությամբ: Դուք ստիպված կլինեք ինքնուրույն ուսումնասիրել առկա տեղեկամատյանները՝ դրանցում փնտրելով փոխզիջման համապատասխան ցուցանիշներ։ AWS Security Hub-ը, որը վերջերս գործարկեց Amazon-ը, նպատակ ունի լուծել այս խնդիրը՝ դառնալով ամպային SIEM AWS-ի համար: Բայց առայժմ այն ​​միայն իր ճանապարհորդության սկզբում է և սահմանափակված է ինչպես աղբյուրների քանակով, որոնց հետ աշխատում է, այնպես էլ հենց Amazon-ի ճարտարապետությամբ և բաժանորդագրություններով սահմանված այլ սահմանափակումներով:

Օրինակ՝ տեղեկատվական անվտանգության մոնիտորինգ IaaS-ում՝ հիմնված Azure-ի վրա

Ես չեմ ուզում երկար բանավեճի մեջ մտնել այն մասին, թե ամպային երեք մատակարարներից որն է (Amazon, Microsoft կամ Google) ավելի լավը (մանավանդ, որ նրանցից յուրաքանչյուրը դեռևս ունի իր հատուկ առանձնահատկությունները և հարմար է սեփական խնդիրները լուծելու համար); Եկեք կենտրոնանանք տեղեկատվական անվտանգության մոնիտորինգի հնարավորությունների վրա, որոնք ապահովում են այս խաղացողները: Պետք է խոստովանել, որ Amazon AWS-ն առաջիններից մեկն էր այս հատվածում և, հետևաբար, առաջադիմել է ամենահեռավոր իր տեղեկատվական անվտանգության գործառույթների առումով (չնայած շատերն ընդունում են, որ դրանք դժվար է օգտագործել): Բայց դա չի նշանակում, որ մենք անտեսելու ենք այն հնարավորությունները, որոնք մեզ տալիս են Microsoft-ը և Google-ը։

Microsoft-ի արտադրանքները միշտ էլ աչքի են ընկել իրենց «բացությամբ», իսկ Azure-ում էլ իրավիճակը նման է։ Օրինակ, եթե AWS-ը և GCP-ն միշտ բխում են «այն, ինչ չի թույլատրվում, արգելվում է» հասկացությունից, ապա Azure-ն ունի ճիշտ հակառակ մոտեցումը: Օրինակ՝ ամպի մեջ վիրտուալ ցանց և դրա մեջ վիրտուալ մեքենա ստեղծելիս բոլոր նավահանգիստներն ու արձանագրությունները բաց են և թույլատրվում են լռելյայն: Հետևաբար, դուք ստիպված կլինեք մի փոքր ավելի շատ ջանք ծախսել Microsoft-ից ամպի մեջ մուտքի վերահսկման համակարգի նախնական տեղադրման վրա: Եվ սա նաև ձեզ ավելի խիստ պահանջներ է դնում Azure ամպի մեջ մշտադիտարկման գործունեության առումով:

AWS-ն ունի մի առանձնահատկություն, որը կապված է այն բանի հետ, որ երբ վերահսկում եք ձեր վիրտուալ ռեսուրսները, եթե դրանք գտնվում են տարբեր տարածաշրջաններում, ապա դուք դժվարություններ եք ունենում համատեղելու բոլոր իրադարձությունները և դրանց միասնական վերլուծությունը, ինչը վերացնելու համար անհրաժեշտ է դիմել տարբեր հնարքների, ինչպիսիք են. Ստեղծեք ձեր սեփական կոդը AWS Lambda-ի համար, որը կփոխադրի իրադարձությունները տարածաշրջանների միջև: Azure-ն այս խնդիրը չունի. նրա Activity Log մեխանիզմը հետևում է ողջ կազմակերպության գործունեությանը առանց սահմանափակումների: Նույնը վերաբերում է AWS Security Hub-ին, որը վերջերս մշակվել է Amazon-ի կողմից՝ անվտանգության բազմաթիվ գործառույթներ համախմբելու մեկ անվտանգության կենտրոնում, բայց միայն իր տարածաշրջանում, ինչը, սակայն, Ռուսաստանի համար տեղին չէ: Azure-ն ունի իր Անվտանգության կենտրոնը, որը կապված չէ տարածաշրջանային սահմանափակումներով՝ ապահովելով մուտք դեպի ամպային հարթակի անվտանգության բոլոր հնարավորությունները։ Ավելին, տարբեր տեղական թիմերի համար այն կարող է ապահովել պաշտպանական հնարավորությունների իր փաթեթը, ներառյալ նրանց կողմից կառավարվող անվտանգության միջոցառումները: AWS Security Hub-ը դեռ ճանապարհին է նմանվելու Azure Security Center-ին: Բայց արժե քսուքի մեջ մի ճանճ ավելացնել. դուք կարող եք Azure-ից շատ բան քամել այն, ինչ նախկինում նկարագրված էր AWS-ում, բայց դա ամենահարմարն է արվում միայն Azure AD-ի, Azure Monitor-ի և Azure անվտանգության կենտրոնի համար: Բոլոր մյուս Azure անվտանգության մեխանիզմները, ներառյալ անվտանգության իրադարձությունների վերլուծությունը, դեռ չեն կառավարվում ամենահարմար ձևով: Խնդիրը մասամբ լուծվում է API-ի կողմից, որը ներթափանցում է Microsoft Azure-ի բոլոր ծառայությունները, բայց դա ձեզանից լրացուցիչ ջանքեր կպահանջի՝ ձեր ամպը ձեր SOC-ի հետ ինտեգրելու և որակյալ մասնագետների ներկայությամբ (իրականում, ինչպես ցանկացած այլ SIEM, որն աշխատում է ամպի հետ: API-ներ): Որոշ SIEM-ներ, որոնք կքննարկվեն ավելի ուշ, արդեն աջակցում են Azure-ին և կարող են ավտոմատացնել դրա մոնիտորինգի խնդիրը, բայց դա նաև ունի իր դժվարությունները. ոչ բոլորն են կարող հավաքել Azure-ի բոլոր տեղեկամատյանները:

Azure-ում իրադարձությունների հավաքագրումը և մոնիտորինգը տրամադրվում է Azure Monitor ծառայության միջոցով, որը Microsoft-ի ամպի և դրա ռեսուրսների տվյալների հավաքագրման, պահպանման և վերլուծության հիմնական գործիքն է՝ Git պահոցներ, կոնտեյներներ, վիրտուալ մեքենաներ, հավելվածներ և այլն: Azure Monitor-ի կողմից հավաքագրված բոլոր տվյալները բաժանված են երկու կատեգորիայի՝ չափումներ, որոնք հավաքվում են իրական ժամանակում և նկարագրում են Azure ամպի հիմնական կատարողականի ցուցիչները, և գրանցամատյաններ, որոնք պարունակում են տվյալներ՝ կազմակերպված գրառումներում, որոնք բնութագրում են Azure-ի ռեսուրսների և ծառայությունների գործունեության որոշակի ասպեկտները: Բացի այդ, օգտագործելով Data Collector API-ն, Azure Monitor ծառայությունը կարող է տվյալներ հավաքել REST-ի ցանկացած աղբյուրից՝ սեփական մոնիտորինգի սցենարներ ստեղծելու համար:

Ահա անվտանգության միջոցառումների մի քանի աղբյուրներ, որոնք Azure-ն առաջարկում է ձեզ, և որոնց կարող եք մուտք գործել Azure Portal, CLI, PowerShell կամ REST API-ի միջոցով (և որոշները միայն Azure Monitor/Insight API-ի միջոցով).

• Գործունեության մատյաններ - այս մատյանը պատասխանում է «ով», «ինչ» և «երբ» դասական հարցերին, որոնք վերաբերում են ամպային ռեսուրսների վրա գրելու ցանկացած գործողությանը (PUT, POST, DELETE): Ընթերցանության հասանելիության (GET) հետ կապված իրադարձությունները ներառված չեն այս մատյանում, ինչպես մի շարք այլ իրադարձություններ:
• Ախտորոշիչ տեղեկամատյաններ - պարունակում է տվյալներ ձեր բաժանորդագրության մեջ ներառված որոշակի ռեսուրսի հետ կապված գործողությունների վերաբերյալ:
• Azure AD հաշվետվություն - պարունակում է ինչպես օգտագործողի գործունեությունը, այնպես էլ համակարգի գործունեությունը կապված խմբի և օգտագործողների կառավարման հետ:
• Windows Event Log և Linux Syslog - պարունակում է իրադարձություններ ամպի մեջ տեղակայված վիրտուալ մեքենաներից:
• Չափումներ - պարունակում է հեռաչափություն ձեր ամպային ծառայությունների և ռեսուրսների կատարողականի և առողջական վիճակի վերաբերյալ: Չափվում է ամեն րոպե և պահվում: 30 օրվա ընթացքում։
• Ցանցի անվտանգության խմբի հոսքերի մատյաններ - պարունակում է տվյալներ ցանցային անվտանգության իրադարձությունների վերաբերյալ, որոնք հավաքագրվել են Network Watcher ծառայության և ռեսուրսների մոնիտորինգի միջոցով ցանցի մակարդակով:
• Պահպանման տեղեկամատյաններ - պարունակում է իրադարձություններ, որոնք կապված են պահեստավորման օբյեկտներ մուտք գործելու հետ:

Մոնիտորինգի համար կարող եք օգտագործել արտաքին SIEM կամ ներկառուցված Azure Monitor-ը և դրա ընդլայնումները: Տեղեկատվական անվտանգության միջոցառումների կառավարման համակարգերի մասին մենք կխոսենք ավելի ուշ, բայց առայժմ տեսնենք, թե ինչ է առաջարկում մեզ Azure-ն ինքնին անվտանգության համատեքստում տվյալների վերլուծության համար: Azure Monitor-ում անվտանգությանն առնչվող ամեն ինչի հիմնական էկրանը Log Analytics-ի անվտանգության և աուդիտի վահանակն է (անվճար տարբերակն աջակցում է իրադարձությունների պահպանման սահմանափակ քանակությամբ ընդամենը մեկ շաբաթվա ընթացքում): Այս վահանակը բաժանված է 5 հիմնական ոլորտների, որոնք պատկերացնում են ամփոփ վիճակագրությունը, թե ինչ է կատարվում ամպային միջավայրում, որը դուք օգտագործում եք.

• Անվտանգության տիրույթներ՝ տեղեկատվական անվտանգության հետ կապված հիմնական քանակական ցուցիչներ՝ միջադեպերի, վտանգված հանգույցների, չփակված հանգույցների, ցանցի անվտանգության իրադարձությունների և այլնի քանակ:
• Նշանավոր խնդիրներ - ցուցադրում է տեղեկատվական անվտանգության ակտիվ խնդիրների քանակը և կարևորությունը
• Հայտնաբերումներ - ցուցադրում է ձեր դեմ օգտագործվող հարձակումների օրինաչափությունները
• Վտանգների հետախուզություն - ցուցադրում է աշխարհագրական տեղեկատվություն արտաքին հանգույցների վրա, որոնք հարձակվում են ձեզ վրա
• Անվտանգության ընդհանուր հարցումներ. բնորոշ հարցումներ, որոնք կօգնեն ձեզ ավելի լավ վերահսկել ձեր տեղեկատվական անվտանգությունը:

Azure Monitor-ի ընդլայնումները ներառում են Azure Key Vault (գաղտնագրային բանալիների պաշտպանություն ամպի մեջ), չարամիտ գնահատում (վիրտուալ մեքենաներում վնասակար կոդի դեմ պաշտպանության վերլուծություն), Azure Application Gateway Analytics (ի թիվս այլ բաների, ամպային firewall-ի մատյանների վերլուծություն) և այլն: . Այս գործիքները, որոնք հարստացված են իրադարձությունների մշակման որոշակի կանոններով, թույլ են տալիս պատկերացնել ամպային ծառայությունների գործունեության տարբեր ասպեկտներ, ներառյալ անվտանգությունը, և բացահայտել որոշակի շեղումներ գործառնությունից: Բայց, ինչպես հաճախ է պատահում, ցանկացած լրացուցիչ ֆունկցիոնալություն պահանջում է համապատասխան վճարովի բաժանորդագրություն, որը ձեզանից կպահանջի համապատասխան ֆինանսական ներդրումներ, որոնք դուք պետք է նախապես պլանավորեք։

Azure-ն ունի մի շարք ներկառուցված սպառնալիքների մոնիտորինգի հնարավորություններ, որոնք ինտեգրված են Azure AD-ում, Azure Monitor-ում և Azure Security Center-ում: Դրանց թվում, օրինակ, վիրտուալ մեքենաների փոխազդեցության հայտնաբերումը հայտնի վնասակար IP-ների հետ (Microsoft-ի Threat Intelligence ծառայությունների հետ ինտեգրման պատճառով), ամպային ենթակառուցվածքում չարամիտ ծրագրերի հայտնաբերում ամպում տեղակայված վիրտուալ մեքենաներից ահազանգեր ստանալու միջոցով, գաղտնաբառ: վիրտուալ մեքենաների վրա հարձակումների գուշակում, օգտատերերի նույնականացման համակարգի կազմաձևման խոցելիություն, համակարգ մուտք գործելը անանունացնողներից կամ վարակված հանգույցներից, հաշվի արտահոսք, անսովոր վայրերից համակարգ մուտք գործել և այլն: Azure-ն այսօր այն սակավաթիվ ամպային մատակարարներից մեկն է, որն առաջարկում է ձեզ ներկառուցված Threat Intelligence-ի հնարավորություններ՝ հարստացնելու հավաքագրված տեղեկատվական անվտանգության միջոցառումները:

Ինչպես նշվեց վերևում, անվտանգության գործառույթը և, որպես հետևանք, դրա կողմից ստեղծված անվտանգության իրադարձությունները հավասարապես հասանելի չեն բոլոր օգտատերերին, բայց պահանջում են որոշակի բաժանորդագրություն, որը ներառում է ձեզ անհրաժեշտ գործառույթը, որը ստեղծում է տեղեկատվական անվտանգության մոնիտորինգի համար համապատասխան իրադարձություններ: Օրինակ, նախորդ պարբերությունում նկարագրված որոշ գործառույթներ հաշիվներում անոմալիաների մոնիտորինգի համար հասանելի են միայն Azure AD ծառայության P2 պրեմիում լիցենզիայում: Առանց դրա, դուք, ինչպես AWS-ի դեպքում, ստիպված կլինեք «ձեռքով» վերլուծել հավաքագրված անվտանգության իրադարձությունները: Եվ նաև, կախված Azure AD լիցենզիայի տեսակից, ոչ բոլոր իրադարձությունները հասանելի կլինեն վերլուծության համար:

Azure պորտալում դուք կարող եք կառավարել և՛ որոնման հարցումները ձեզ հետաքրքրող տեղեկամատյանների համար, և՛ տեղադրել վահանակներ՝ պատկերացնելու տեղեկատվական անվտանգության հիմնական ցուցանիշները: Բացի այդ, այնտեղ կարող եք ընտրել Azure Monitor-ի ընդլայնումներ, որոնք թույլ են տալիս ընդլայնել Azure Monitor-ի մատյանների ֆունկցիոնալությունը և ստանալ իրադարձությունների ավելի խորը վերլուծություն անվտանգության տեսանկյունից:

Եթե ​​Ձեզ անհրաժեշտ է ոչ միայն տեղեկամատյանների հետ աշխատելու ունակություն, այլև ձեր Azure ամպային հարթակի անվտանգության համապարփակ կենտրոն, ներառյալ տեղեկատվական անվտանգության քաղաքականության կառավարումը, ապա կարող եք խոսել Azure անվտանգության կենտրոնի հետ աշխատելու անհրաժեշտության մասին, որի օգտակար գործառույթների մեծ մասը: հասանելի են որոշակի գումարով, օրինակ՝ սպառնալիքների հայտնաբերում, Azure-ից դուրս մոնիտորինգ, համապատասխանության գնահատում և այլն: (անվճար տարբերակում ձեզ հասանելի է միայն անվտանգության գնահատումը և հայտնաբերված խնդիրները վերացնելու առաջարկությունները): Այն համախմբում է անվտանգության բոլոր խնդիրները մեկ տեղում: Իրականում, մենք կարող ենք խոսել տեղեկատվական անվտանգության ավելի բարձր մակարդակի մասին, քան ձեզ տրամադրում է Azure Monitor-ը, քանի որ այս դեպքում ձեր ամպային գործարանում հավաքված տվյալները հարստացվում են բազմաթիվ աղբյուրների միջոցով, ինչպիսիք են Azure, Office 365, Microsoft CRM առցանց, Microsoft Dynamics AX: , outlook .com, MSN.com, Microsoft Digital Crimes Unit (DCU) և Microsoft Security Response Center (MSRC), որոնց վրա դրված են մեքենայական ուսուցման և վարքագծային վերլուծության տարբեր բարդ ալգորիթմներ, որոնք, ի վերջո, պետք է բարելավեն սպառնալիքների հայտնաբերման և դրանց արձագանքման արդյունավետությունը։ .

Azure-ն ունի նաև իր սեփական SIEM-ը, այն հայտնվել է 2019 թվականի սկզբին: Սա Azure Sentinel-ն է, որը հիմնված է Azure Monitor-ի տվյալների վրա և կարող է նաև ինտեգրվել: արտաքին անվտանգության լուծումներ (օրինակ՝ NGFW կամ WAF), որոնց ցանկն անընդհատ աճում է։ Բացի այդ, Microsoft Graph Security API-ի ինտեգրման միջոցով դուք հնարավորություն ունեք միացնել ձեր սեփական սպառնալիքների հետախուզական հոսքերը Sentinel-ին, ինչը հարստացնում է ձեր Azure ամպում միջադեպերը վերլուծելու հնարավորությունները: Կարելի է պնդել, որ Azure Sentinel-ը առաջին «հայրենի» SIEM-ն է, որը հայտնվել է ամպային պրովայդերներից (նույն Splunk-ը կամ ELK-ը, որոնք կարող են տեղակայվել ամպի մեջ, օրինակ՝ AWS-ը, դեռևս մշակված չեն ավանդական ամպային ծառայություններ մատուցողների կողմից): Azure Sentinel-ը և Security Center-ը կարող է կոչվել SOC Azure ամպի համար և կարող է սահմանափակվել դրանցով (որոշակի վերապահումներով), եթե այլևս չունենայիք որևէ ենթակառուցվածք և ձեր բոլոր հաշվողական ռեսուրսները փոխանցեիք ամպին, և դա կլիներ Microsoft cloud Azure-ը:

Բայց քանի որ Azure-ի ներկառուցված հնարավորությունները (նույնիսկ եթե դուք բաժանորդագրված եք Sentinel-ին) հաճախ բավարար չեն տեղեկատվական անվտանգության մոնիտորինգի և այս գործընթացը անվտանգության իրադարձությունների այլ աղբյուրների հետ ինտեգրվելու համար (ինչպես ամպային, այնպես էլ ներքին), կա. անհրաժեշտ է հավաքագրված տվյալները արտահանել արտաքին համակարգեր, որոնք կարող են ներառել SIEM-ը: Դա արվում է ինչպես API-ի, այնպես էլ հատուկ ընդլայնումների միջոցով, որոնք ներկայումս պաշտոնապես հասանելի են միայն հետևյալ SIEM-ների համար՝ Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight և ELK: Մինչև վերջերս ավելի շատ նման SIEM-ներ կային, բայց 1 թվականի հունիսի 2019-ից Microsoft-ը դադարեցրեց աջակցությունը Azure Log Integration Tool-ին (AzLog), որը Azure-ի գոյության արշալույսին և տեղեկամատյանների հետ աշխատելու նորմալ ստանդարտացման բացակայության դեպքում (Azure): Մոնիտորը դեռ գոյություն չուներ) հեշտացրեց արտաքին SIEM-ի ինտեգրումը Microsoft-ի ամպի հետ: Այժմ իրավիճակը փոխվել է, և Microsoft-ը խորհուրդ է տալիս Azure Event Hub հարթակը որպես հիմնական ինտեգրացիոն գործիք այլ SIEM-ների համար: Շատերն արդեն իրականացրել են նման ինտեգրում, բայց զգույշ եղեք. նրանք կարող են ոչ բոլոր Azure տեղեկամատյանները գրավել, այլ միայն որոշները (նայեք ձեր SIEM-ի փաստաթղթերում):

Ավարտելով կարճ էքսկուրսիա դեպի Azure, ես կցանկանայի ընդհանուր առաջարկություն տալ այս ամպային ծառայության վերաբերյալ. նախքան Azure-ում տեղեկատվական անվտանգության մոնիտորինգի գործառույթների մասին որևէ բան ասելը, դուք պետք է շատ ուշադիր կարգավորեք դրանք և ստուգեք, որ դրանք աշխատում են այնպես, ինչպես գրված է փաստաթղթերում և ինչպես խորհրդատուները ձեզ ասացին Microsoft-ին (և նրանք կարող են տարբեր տեսակետներ ունենալ Azure գործառույթների ֆունկցիոնալության վերաբերյալ): Եթե ​​ունեք ֆինանսական ռեսուրսներ, կարող եք Azure-ից շատ օգտակար տեղեկատվություն քամել տեղեկատվական անվտանգության մոնիտորինգի առումով: Եթե ​​ձեր ռեսուրսները սահմանափակ են, ապա, ինչպես AWS-ի դեպքում, դուք ստիպված կլինեք ապավինել միայն ձեր սեփական ուժերին և չմշակված տվյալներին, որոնք ձեզ տրամադրում է Azure Monitor-ը: Եվ հիշեք, որ մոնիտորինգի շատ գործառույթներ արժեն գումար, և ավելի լավ է նախապես ծանոթանալ գնային քաղաքականությանը: Օրինակ, դուք կարող եք անվճար պահել 31 օրվա տվյալներ մինչև առավելագույնը 5 ԳԲ յուրաքանչյուր հաճախորդի համար. յուրաքանչյուր լրացուցիչ ամիս 2 ԳԲ-ի պահպանում): Հավելվածի հեռաչափության և չափումների հետ աշխատելը կարող է նաև պահանջել լրացուցիչ միջոցներ, ինչպես նաև ծանուցումների և ծանուցումների հետ աշխատելը (որոշակի սահմանաչափը հասանելի է անվճար, որը կարող է բավարար չլինել ձեր կարիքների համար):

Օրինակ՝ տեղեկատվական անվտանգության մոնիտորինգ IaaS-ում՝ հիմնված Google Cloud Platform-ի վրա

Google Cloud Platform-ը AWS-ի և Azure-ի համեմատ երիտասարդ տեսք ունի, բայց դա մասամբ լավ է: Ի տարբերություն AWS-ի, որն աստիճանաբար ավելացրեց իր հնարավորությունները, այդ թվում՝ անվտանգության, կենտրոնացման հետ կապված խնդիրներ ունենալով. GCP-ն, ինչպես Azure-ը, շատ ավելի լավ է կառավարվում կենտրոնական մակարդակով, ինչը նվազեցնում է սխալներն ու իրականացման ժամանակը ամբողջ ձեռնարկությունում: Անվտանգության տեսանկյունից GCP-ն, տարօրինակ կերպով, գտնվում է AWS-ի և Azure-ի միջև: Նա նաև ունի մեկ միջոցառման գրանցում ամբողջ կազմակերպության համար, բայց այն թերի է: Որոշ գործառույթներ դեռևս գտնվում են բետա ռեժիմում, սակայն աստիճանաբար այս թերությունը պետք է վերացվի, և GCP-ն ավելի հասուն հարթակ կդառնա տեղեկատվական անվտանգության մոնիտորինգի առումով։

GCP-ում իրադարձությունների գրանցման հիմնական գործիքը Stackdriver Logging-ն է (նման է Azure Monitor-ին), որը թույլ է տալիս հավաքել իրադարձություններ ձեր ողջ ամպային ենթակառուցվածքում (ինչպես նաև AWS-ից): GCP-ում անվտանգության տեսանկյունից յուրաքանչյուր կազմակերպություն, նախագիծ կամ թղթապանակ ունի չորս մատյան.

• Ադմինիստրատորի գործունեություն - պարունակում է բոլոր իրադարձությունները՝ կապված ադմինիստրատիվ մուտքի հետ, օրինակ՝ վիրտուալ մեքենայի ստեղծում, մուտքի իրավունքի փոփոխություն և այլն։ Այս գրանցամատյանը միշտ գրված է, անկախ ձեր ցանկությունից, և պահպանում է իր տվյալները 400 օր:
• Տվյալների հասանելիություն - պարունակում է ամպային օգտագործողների տվյալների հետ աշխատելու հետ կապված բոլոր իրադարձությունները (ստեղծում, փոփոխում, ընթերցում և այլն): Լռելյայնորեն այս գրանցամատյանը գրված չէ, քանի որ դրա ծավալը շատ արագ ուռչում է: Այդ իսկ պատճառով դրա պահպանման ժամկետը ընդամենը 30 օր է։ Բացի այդ, ամեն ինչ չէ, որ գրված է այս ամսագրում։ Օրինակ, ռեսուրսների հետ կապված իրադարձությունները, որոնք հանրությանը հասանելի են բոլոր օգտատերերին, կամ որոնք հասանելի են առանց GCP մուտք գործելու, դրան չեն գրվում:
• Համակարգային իրադարձություն - պարունակում է համակարգային իրադարձություններ, որոնք կապված չեն օգտատերերի հետ, կամ ադմինիստրատորի գործողությունները, ով փոխում է ամպային ռեսուրսների կազմաձևումը: Այն միշտ գրվում և պահվում է 400 օր։
• Access Transparency-ը գրանցամատյանի եզակի օրինակ է, որն արտացոլում է Google-ի աշխատակիցների բոլոր գործողությունները (բայց դեռ ոչ բոլոր GCP ծառայությունների համար), ովքեր մուտք են գործում ձեր ենթակառուցվածքը որպես իրենց աշխատանքային պարտականությունների մաս: Այս գրանցամատյանը պահվում է 400 օր և հասանելի չէ GCP-ի յուրաքանչյուր հաճախորդին, բայց միայն այն դեպքում, եթե բավարարված են մի շարք պայմաններ (կամ ոսկի կամ պլատինե մակարդակի աջակցություն, կամ որոշակի տեսակի 4 դերերի առկայություն՝ որպես կորպորատիվ աջակցության մաս): Նմանատիպ գործառույթ հասանելի է նաև, օրինակ, Office 365 - Lockbox-ում:

Մատյան օրինակ. Մուտքի թափանցիկություն

{
 insertId:  "abcdefg12345"
 jsonPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.TransparencyLog"
  location: {
   principalOfficeCountry:  "US"
   principalEmployingEntity:  "Google LLC"
   principalPhysicalLocationCountry:  "CA"
  }
  product: [
   0:  "Cloud Storage"
  ]
  reason: [
    detail:  "Case number: bar123"
    type:  "CUSTOMER_INITIATED_SUPPORT"
  ]
  accesses: [
   0: {
    methodName: "GoogleInternal.Read"
    resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"
    }
  ]
 }
 logName:  "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.com%2Faccess_transparency"
 operation: {
  id:  "12345xyz"
 }
 receiveTimestamp:  "2017-12-18T16:06:37.400577736Z"
 resource: {
  labels: {
   project_id:  "1234567890"
  }
  type:  "project"
 }
 severity:  "NOTICE"
 timestamp:  "2017-12-18T16:06:24.660001Z"
}

Այս տեղեկամատյաններին մուտքը հնարավոր է մի քանի ձևով (նույն ձևով, ինչպես նախկինում քննարկված Azure-ը և AWS-ը)՝ Log Viewer ինտերֆեյսի, API-ի, Google Cloud SDK-ի միջոցով կամ ձեր նախագծի Գործունեության էջի միջոցով, որի համար դուք հետաքրքրված են իրադարձություններով. Նույն կերպ դրանք կարող են արտահանվել արտաքին լուծումներ՝ լրացուցիչ վերլուծության համար։ Վերջինս արվում է տեղեկամատյաններն արտահանելով BigQuery կամ Cloud Pub/Sub պահեստ:

Բացի Stackdriver Logging-ից, GCP պլատֆորմն առաջարկում է նաև Stackdriver Monitoring գործառույթը, որը թույլ է տալիս վերահսկել ամպային ծառայությունների և հավելվածների հիմնական չափումները (կատարումը, MTBF, ընդհանուր առողջությունը և այլն): Վերամշակված և վիզուալացված տվյալները կարող են հեշտացնել ձեր ամպային ենթակառուցվածքում խնդիրներ գտնելը, այդ թվում՝ անվտանգության համատեքստում: Բայց հարկ է նշել, որ այս ֆունկցիոնալությունը շատ հարուստ չի լինի տեղեկատվական անվտանգության համատեքստում, քանի որ այսօր GCP-ն չունի նույն AWS GuardDuty-ի անալոգը և չի կարող հայտնաբերել վատերը բոլոր գրանցված իրադարձությունների մեջ (Google-ը մշակել է Իրադարձությունների սպառնալիքների հայտնաբերում, բայց այն դեռ մշակման փուլում է բետա տարբերակում և դեռ վաղ է խոսել դրա օգտակարության մասին): Stackdriver Monitoring-ը կարող է օգտագործվել որպես անոմալիաների հայտնաբերման համակարգ, որն այնուհետ կհետազոտվի՝ գտնելու դրանց առաջացման պատճառները: Բայց հաշվի առնելով շուկայում GCP տեղեկատվական անվտանգության ոլորտում որակավորված կադրերի բացակայությունը, այս խնդիրը ներկայումս դժվար է թվում:

Արժե նաև տալ տեղեկատվական անվտանգության որոշ մոդուլների ցանկ, որոնք կարող են օգտագործվել ձեր GCP ամպում և որոնք նման են AWS-ի առաջարկներին.

• Cloud Security Command Center-ը AWS Security Hub-ի և Azure Security Center-ի անալոգն է:
• Cloud DLP - Ամպում տեղակայված տվյալների ավտոմատ հայտնաբերում և խմբագրում (օրինակ՝ քողարկում)՝ օգտագործելով ավելի քան 90 նախապես սահմանված դասակարգման քաղաքականություն:
• Cloud Scanner-ը App Engine-ում, Compute Engine-ում և Google Kubernetes-ում հայտնի խոցելիությունների սկաներ է (XSS, Flash Injection, չկարկատված գրադարաններ և այլն):
• Cloud IAM - Վերահսկել մուտքը GCP բոլոր ռեսուրսներին:
• Cloud Identity - Կառավարեք GCP օգտվողի, սարքի և հավելվածի հաշիվները մեկ վահանակից:
• Cloud HSM - ծածկագրային բանալիների պաշտպանություն:
• Cloud Key Management Service - գաղտնագրային բանալիների կառավարում GCP-ում:
• VPC Service Control - Ստեղծեք անվտանգ պարագիծ ձեր GCP ռեսուրսների շուրջ՝ դրանք արտահոսքից պաշտպանելու համար:
• Titan անվտանգության բանալի - պաշտպանություն ֆիշինգից:

Այս մոդուլներից շատերը ստեղծում են անվտանգության իրադարձություններ, որոնք կարող են ուղարկվել BigQuery պահեստ՝ վերլուծության կամ արտահանման այլ համակարգեր, այդ թվում՝ SIEM: Ինչպես նշվեց վերևում, GCP-ն ակտիվորեն զարգացող հարթակ է, և Google-ն այժմ մշակում է տեղեկատվական անվտանգության մի շարք նոր մոդուլներ իր հարթակի համար: Դրանց թվում են Event Threat Detection-ը (այժմ հասանելի է բետա տարբերակով), որը սկանավորում է Stackdriver-ի տեղեկամատյանները՝ փնտրելով չարտոնված գործունեության հետքեր (որոնց նման է GuardDuty-ին AWS-ում) կամ Policy Intelligence-ը (հասանելի է ալֆա տարբերակով), որը թույլ կտա ձեզ մշակել խելացի քաղաքականություն։ մուտք դեպի GCP ռեսուրսներ:

Ես կարճ ակնարկ արեցի հանրաճանաչ ամպային հարթակներում ներկառուցված մոնիտորինգի հնարավորությունների մասին: Բայց ունե՞ք մասնագետներ, ովքեր ի վիճակի են աշխատել «հում» IaaS մատակարարների տեղեկամատյանների հետ (ոչ բոլորն են պատրաստ գնել AWS-ի կամ Azure-ի կամ Google-ի առաջադեմ հնարավորությունները): Բացի այդ, շատերը ծանոթ են «վստահիր, բայց ստուգիր» ասացվածքին, որն առավել քան երբևէ ճիշտ է անվտանգության ոլորտում: Որքա՞ն եք վստահում ամպային մատակարարի ներկառուցված հնարավորություններին, որոնք ձեզ տեղեկատվական անվտանգության միջոցառումներ են ուղարկում: Որքա՞ն են նրանք ընդհանրապես կենտրոնանում տեղեկատվական անվտանգության վրա:

Երբեմն արժե դիտարկել ամպային ենթակառուցվածքի մոնիտորինգի լուծումները, որոնք կարող են լրացնել ներկառուցված ամպային անվտանգությունը, և երբեմն այդպիսի լուծումները միակ տարբերակն են՝ ձեր տվյալների և ամպում տեղակայված հավելվածների անվտանգության մասին պատկերացում կազմելու համար: Բացի այդ, դրանք պարզապես ավելի հարմար են, քանի որ նրանք իրենց վրա են վերցնում տարբեր ամպային մատակարարների տարբեր ամպային ծառայությունների կողմից ստեղծված անհրաժեշտ տեղեկամատյանների վերլուծության բոլոր խնդիրները: Նման ծածկույթի լուծման օրինակ է Cisco Stealthwatch Cloud-ը, որը կենտրոնացած է մեկ առաջադրանքի վրա՝ վերահսկել տեղեկատվական անվտանգության անոմալիաները ամպային միջավայրերում, ներառյալ ոչ միայն Amazon AWS-ը, Microsoft Azure-ը և Google Cloud Platform-ը, այլ նաև մասնավոր ամպերը:

Օրինակ՝ Տեղեկատվական անվտանգության մոնիտորինգ՝ օգտագործելով Stealthwatch Cloud

AWS-ն ապահովում է ճկուն հաշվողական հարթակ, սակայն այս ճկունությունը ընկերությունների համար հեշտացնում է սխալներ թույլ տալը, որոնք հանգեցնում են անվտանգության խնդիրների: Իսկ ընդհանուր տեղեկատվական անվտանգության մոդելը միայն նպաստում է դրան։ Անհայտ խոցելիություններով ամպի մեջ աշխատող ծրագրակազմ (հայտնիների դեմ կարելի է պայքարել, օրինակ, AWS Inspector-ի կամ GCP Cloud Scanner-ի միջոցով), թույլ գաղտնաբառեր, սխալ կազմաձևումներ, ինսայդերներ և այլն: Եվ այս ամենն արտահայտվում է ամպային ռեսուրսների վարքագծում, որը կարող է վերահսկել Cisco Stealthwatch Cloud-ը, որը տեղեկատվական անվտանգության մոնիտորինգի և հարձակումների հայտնաբերման համակարգ է։ հանրային և մասնավոր ամպեր.

Cisco Stealthwatch Cloud-ի հիմնական առանձնահատկություններից մեկը սուբյեկտների մոդելավորման հնարավորությունն է: Դրանով դուք կարող եք ստեղծել ծրագրային մոդել (այսինքն՝ գրեթե իրական ժամանակի սիմուլյացիա) ձեր ամպային ռեսուրսներից յուրաքանչյուրի համար (կարևոր չէ՝ դա AWS է, Azure, GCP, թե այլ բան): Դրանք կարող են ներառել սերվերներ և օգտվողներ, ինչպես նաև ձեր ամպային միջավայրին հատուկ ռեսուրսների տեսակներ, ինչպիսիք են անվտանգության խմբերը և ավտոմատ մասշտաբի խմբերը: Այս մոդելներն օգտագործում են կառուցվածքային տվյալների հոսքեր, որոնք տրամադրվում են ամպային ծառայությունների կողմից որպես մուտքագրում: Օրինակ, AWS-ի համար դրանք կլինեն VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda և AWS IAM: Կազմակերպության մոդելավորումը ավտոմատ կերպով բացահայտում է ձեր ցանկացած ռեսուրսների դերն ու վարքագիծը (կարող եք խոսել ամպի ամբողջ գործունեության պրոֆիլավորման մասին): Այս դերերը ներառում են Android կամ Apple շարժական սարք, Citrix PVS սերվեր, RDP սերվեր, փոստի դարպաս, VoIP հաճախորդ, տերմինալային սերվեր, տիրույթի վերահսկիչ և այլն: Այնուհետև այն շարունակաբար վերահսկում է նրանց վարքը՝ որոշելու, թե երբ է տեղի ունենում ռիսկային կամ անվտանգությանը սպառնացող վարքագիծ: Դուք կարող եք բացահայտել գաղտնաբառի գուշակությունը, DDoS հարձակումները, տվյալների արտահոսքը, ապօրինի հեռավոր մուտքը, վնասակար կոդի ակտիվությունը, խոցելիության սկանավորումը և այլ սպառնալիքներ: Օրինակ, SSH-ի միջոցով ձեր կազմակերպության համար ոչ տիպիկ երկրից (Հարավային Կորեա) դեպի Kubernetes կլաստեր հեռահար մուտքի փորձ հայտնաբերելը հետևյալն է.

Եվ ահա, թե ինչ տեսք ունի Postgress տվյալների բազայից տեղեկատվության ենթադրյալ արտահոսքը մի երկիր, որի հետ մենք նախկինում չենք հանդիպել փոխազդեցության.

Վերջապես, արտաքին հեռավոր սարքից Չինաստանից և Ինդոնեզիայից շատ անհաջող SSH փորձեր այսպիսի տեսք ունեն.

Կամ, ենթադրենք, որ սերվերի օրինակը VPC-ում, ըստ քաղաքականության, երբեք չպետք է լինի հեռավոր մուտքի նպատակակետ: Ենթադրենք, որ այս համակարգիչը հեռակա մուտք գործեց՝ firewall-ի կանոնների քաղաքականության սխալ փոփոխության պատճառով: Entity Modeling ֆունկցիան կհայտնաբերի և կհաղորդի այս գործունեությունը («Անսովոր հեռակառավարման հասանելիություն») գրեթե իրական ժամանակում և մատնացույց է անում կոնկրետ AWS CloudTrail, Azure Monitor կամ GCP Stackdriver Logging API զանգ (ներառյալ օգտվողի անունը, ամսաթիվը և ժամը, ի թիվս այլ մանրամասների: ), ինչը դրդեց փոխել ITU կանոնը: Եվ հետո այս տեղեկատվությունը կարող է ուղարկվել SIEM վերլուծության:

Նմանատիպ հնարավորություններն իրականացվում են Cisco Stealthwatch Cloud-ի կողմից աջակցվող ցանկացած ամպային միջավայրի համար.

Կազմակերպության մոդելավորումը անվտանգության ավտոմատացման եզակի ձև է, որը կարող է բացահայտել նախկինում անհայտ խնդիր ձեր մարդկանց, գործընթացների կամ տեխնոլոգիայի հետ: Օրինակ, այն թույլ է տալիս, ի թիվս այլ բաների, հայտնաբերել անվտանգության խնդիրներ, ինչպիսիք են.

• Ինչ-որ մեկը հայտնաբերե՞լ է հետնադուռ մեր օգտագործած ծրագրաշարում:
• Կա՞ որևէ երրորդ կողմի ծրագրակազմ կամ սարք մեր ամպում:
• Արդյո՞ք լիազորված օգտվողը չարաշահում է արտոնությունները:
• Կա՞ արդյոք կազմաձևման սխալ, որը թույլ է տվել հեռավոր մուտք կամ ռեսուրսների այլ չնախատեսված օգտագործում:
• Կա՞ արդյոք տվյալների արտահոսք մեր սերվերներից:
• Ինչ-որ մեկը փորձում էր մեզ կապվել ոչ տիպիկ աշխարհագրական դիրքից:
• Արդյո՞ք մեր ամպը վարակված է վնասակար կոդով:

Հայտնաբերված տեղեկատվական անվտանգության իրադարձությունը կարող է ուղարկվել համապատասխան տոմսի տեսքով Slack, Cisco Spark, PagerDuty միջադեպերի կառավարման համակարգ, ինչպես նաև ուղարկել տարբեր SIEM-ներ, այդ թվում՝ Splunk կամ ELK: Ամփոփելու համար մենք կարող ենք ասել, որ եթե ձեր ընկերությունը օգտագործում է բազմաբնույթ ամպային ռազմավարություն և չի սահմանափակվում որևէ մեկ ամպային մատակարարով, վերը նկարագրված տեղեկատվական անվտանգության մոնիտորինգի հնարավորություններով, ապա Cisco Stealthwatch Cloud-ի օգտագործումը լավ տարբերակ է մոնիտորինգի միասնական փաթեթ ստանալու համար։ ամպային առաջատար խաղացողների՝ Amazon-ի, Microsoft-ի և Google-ի հնարավորությունները: Ամենահետաքրքիրն այն է, որ եթե համեմատեք Stealthwatch Cloud-ի գները AWS-ում, Azure-ում կամ GCP-ում տեղեկատվական անվտանգության մոնիտորինգի առաջադեմ լիցենզիաների հետ, կարող է պարզվել, որ Cisco-ի լուծումը նույնիսկ ավելի էժան կլինի, քան Amazon-ի, Microsoft-ի ներկառուցված հնարավորությունները: և Google-ի լուծումները: Պարադոքսալ է, բայց այդպես է: Եվ որքան շատ ամպեր և դրանց հնարավորություններ օգտագործեք, այնքան ավելի ակնհայտ կլինի համախմբված լուծման առավելությունը:

Բացի այդ, Stealthwatch Cloud-ը կարող է վերահսկել ձեր կազմակերպությունում տեղակայված մասնավոր ամպերը, օրինակ՝ հիմնված Kubernetes կոնտեյներների վրա կամ վերահսկելով Netflow հոսքերը կամ ցանցային երթևեկությունը, որը ստացվում է ցանցային սարքավորումներում (նույնիսկ տեղական արտադրության), AD տվյալների կամ DNS սերվերների և այլնի միջոցով: Այս բոլոր տվյալները կհարստացվեն Threat Intelligence-ի տեղեկատվությամբ, որը հավաքագրել է Cisco Talos-ը՝ կիբերանվտանգության սպառնալիքների հետազոտողների աշխարհի ամենամեծ ոչ կառավարական խումբը:

Սա թույլ է տալիս ներդնել մոնիտորինգի միասնական համակարգ ինչպես հանրային, այնպես էլ հիբրիդային ամպերի համար, որոնք ձեր ընկերությունը կարող է օգտագործել: Այնուհետև հավաքագրված տեղեկատվությունը կարող է վերլուծվել՝ օգտագործելով Stealthwatch Cloud-ի ներկառուցված հնարավորությունները կամ ուղարկվել ձեր SIEM-ին (Splunk, ELK, SumoLogic և մի քանի ուրիշներ լռելյայն աջակցվում են):

Դրանով մենք կլրացնենք հոդվածի առաջին մասը, որտեղ ես վերանայեցի IaaS/PaaS պլատֆորմների տեղեկատվական անվտանգության մոնիտորինգի ներկառուցված և արտաքին գործիքները, որոնք թույլ են տալիս արագ հայտնաբերել և արձագանքել ամպային միջավայրում տեղի ունեցող միջադեպերին, որոնք. մեր ձեռնարկությունն ընտրել է. Երկրորդ մասում մենք կշարունակենք թեման և կնայենք SaaS հարթակների մոնիտորինգի տարբերակները՝ օգտագործելով Salesforce-ի և Dropbox-ի օրինակը, ինչպես նաև կփորձենք ամփոփել և միավորել ամեն ինչ՝ ստեղծելով տեղեկատվական անվտանգության մոնիտորինգի միասնական համակարգ տարբեր ամպային մատակարարների համար:

Source: www.habr.com