DPI (SSL ստուգում) հակասում է կրիպտոգրաֆիայի հատիկին, բայց ընկերությունները դա իրականացնում են

Վստահության շղթա. CC BY-SA 4.0 Յանպաս

SSL երթևեկության ստուգումը (SSL/TLS ապակոդավորում, SSL վերլուծություն կամ DPI) դառնում է ավելի ու ավելի թեժ քննարկման թեմա ձեռնարկության ոլորտում: Երթևեկության վերծանման գաղափարը, կարծես, հակասում է ծածկագրության գաղափարին: Այնուամենայնիվ, փաստը մնում է փաստ, որ ավելի ու ավելի շատ ընկերություններ օգտագործում են DPI տեխնոլոգիաներ՝ դա բացատրելով բովանդակությունը չարամիտ ծրագրերի, տվյալների արտահոսքի և այլնի համար ստուգելու անհրաժեշտությամբ։

Դե, եթե որպես փաստ ընդունենք, որ նման տեխնոլոգիան պետք է ներդրվի, ապա գոնե պետք է դիտարկենք այն ամենաանվտանգ և կառավարելի ձևով անելու ուղիները։ Համենայնդեպս մի վստահեք այդ վկայագրերին, օրինակ, որոնք ձեզ տալիս է DPI համակարգի մատակարարը։

Իրականացման մեկ ասպեկտ կա, որի մասին ոչ բոլորը գիտեն։ Իրականում շատերն իսկապես զարմանում են, երբ լսում են այդ մասին։ Սա մասնավոր սերտիֆիկացման մարմին է (CA): Այն առաջացնում է տրաֆիկի վերծանման և վերակոդավորման վկայագրեր:

Ինքնաստորագրված վկայագրերի կամ DPI սարքերի վկայագրերի վրա հույս դնելու փոխարեն, դուք կարող եք օգտագործել հատուկ CA երրորդ կողմի CA-ից, ինչպիսին է GlobalSign-ը: Բայց նախ, եկեք արագ նայենք բուն խնդրին:

Ի՞նչ է SSL ստուգումը և ինչու է այն օգտագործվում:

Ավելի ու ավելի շատ հանրային կայքեր են անցնում HTTPS-ի: Օրինակ՝ ըստ Chrome-ի վիճակագրություն2019 թվականի սեպտեմբերի սկզբին Ռուսաստանում կոդավորված տրաֆիկի բաժինը հասել է 83%-ի։

Ցավոք սրտի, երթևեկության գաղտնագրումն ավելի ու ավելի է օգտագործվում հարձակվողների կողմից, հատկապես, որ Let's Encrypt-ը բաժանում է հազարավոր անվճար SSL վկայագրեր ավտոմատացված ռեժիմով: Այսպիսով, HTTPS-ն օգտագործվում է ամենուր, և բրաուզերի հասցեագոտում կողպեքը դադարել է ծառայել որպես անվտանգության հուսալի ցուցիչ:

Հենց այս դիրքից է, որ DPI լուծումների արտադրողները գովազդում են իրենց արտադրանքը: Նրանք տեղադրվում են վերջնական օգտատերերի (այսինքն՝ ձեր աշխատակիցները, ովքեր զննում են համացանցը) և ինտերնետի միջև՝ զտելով վնասակար տրաֆիկը: Այսօր շուկայում կան մի շարք նման ապրանքներ, սակայն գործընթացներն ըստ էության նույնն են։ HTTPS տրաֆիկը անցնում է ստուգիչով, որտեղ այն վերծանվում է և ստուգվում է չարամիտ ծրագրերի համար:

Հաստատումն ավարտվելուց հետո սարքը վերջնական հաճախորդի հետ ստեղծում է նոր SSL նիստ՝ բովանդակությունը վերծանելու և վերակոդավորելու համար:

Ինչպե՞ս է աշխատում վերծանման/վերագրանցման գործընթացը:

Որպեսզի SSL տեսչական սարքը գաղտնազերծի և վերաբոդավորի փաթեթները, նախքան դրանք վերջնական օգտագործողներին ուղարկելը, այն պետք է կարողանա անմիջապես թողարկել SSL վկայագրեր: Սա նշանակում է, որ դրա վրա պետք է տեղադրված լինի CA վկայական:

Ընկերության համար (կամ միջինում գտնվող այլ մարդ) կարևոր է, որ այս SSL վկայագրերը վստահեն բրաուզերները (այսինքն՝ չհրապարակել սարսափելի նախազգուշական հաղորդագրություններ, ինչպիսին է ստորև): Հետևաբար, CA շղթան (կամ հիերարխիան) պետք է լինի դիտարկիչի վստահության խանութում: Քանի որ այս վկայագրերը չեն տրվել հանրության կողմից վստահված CA-ներից, դուք պետք է ձեռքով բաշխեք CA-ի հիերարխիան բոլոր վերջնական հաճախորդներին:

Նախազգուշական հաղորդագրություն Chrome-ում ինքնաստորագրված վկայագրի համար: Աղբյուր. BadSSL.com

На компьютерах с Windows можно задействовать Active Directory и групповые политики, но для мобильных устройств процедура сложнее.

Իրավիճակն ավելի է բարդանում, եթե Ձեզ անհրաժեշտ է աջակցել կորպորատիվ միջավայրում այլ արմատական ​​վկայագրերի, ինչպիսիք են Microsoft-ի կամ OpenSSL-ի վրա հիմնվածները: Գաղտնի բանալիների պաշտպանություն և կառավարում, որպեսզի ստեղներից ոչ մեկի անսպասելի ժամկետը չլրանա:

Լավագույն տարբերակ. մասնավոր, նվիրված արմատական ​​վկայագիր երրորդ կողմի CA-ից

Եթե ​​մի քանի արմատների կամ ինքնուրույն ստորագրված վկայագրերի կառավարումը ձեզ չի գրավում, կա մեկ այլ տարբերակ. կարող եք ապավինել երրորդ կողմի CA-ին: Այս դեպքում վկայականները տրվում են մասնավոր սերտիֆիկացման մարմին, որը վստահության շղթայում կապված է հատուկ, ընկերության համար ստեղծված հատուկ արմատական ​​սերտիֆիկացման մարմնի հետ:

Պարզեցված ճարտարապետություն՝ նվիրված հաճախորդների արմատական ​​վկայագրերի համար

Այս կարգավորումը լուծում է նախկինում նշված որոշ խնդիրներ՝ գոնե նվազեցնելով կառավարվող արմատների թիվը: Այստեղ միայն մեկ մասնավոր արմատային CA-ն կարող է օգտագործվել բոլոր ներքին PKI կարիքների համար ցանկացած միջանկյալ CA-ների հետ: Օրինակ, վերը նշված դիագրամը ցույց է տալիս բազմամակարդակ հիերարխիա, որտեղ մեկ միջանկյալ CA օգտագործվում է SSL-ի ստուգման/գաղտնազերծման համար, իսկ մյուսը՝ ներքին համակարգիչների համար (նոութբուքեր, սերվերներ, աշխատասեղաններ և այլն):

Այս սխեմայով բոլոր հաճախորդների վրա CA հյուրընկալելու կարիք չկա, քանի որ վերին մակարդակի CA-ն հյուրընկալվում է GlobalSign-ի կողմից, որը լուծում է մասնավոր բանալիների պաշտպանության և ժամկետանցության խնդիրները:

Այս մոտեցման մեկ այլ առավելություն է SSL ստուգման CA-ն ցանկացած պատճառով չեղյալ հայտարարելու հնարավորությունը: Փոխարենը, այն պարզապես ստեղծում է նորը, որը կապված է ձեր սկզբնական մասնավոր արմատին, և դուք կարող եք անմիջապես օգտագործել այն:

Չնայած բոլոր հակասություններին, ձեռնարկություններն ավելի ու ավելի են իրականացնում SSL երթևեկության ստուգում, որպես իրենց ներքին կամ մասնավոր PKI ենթակառուցվածքի մաս: Անձնական PKI-ի այլ կիրառություններ ներառում են սարքի կամ օգտագործողի նույնականացման վկայագրերի տրամադրումը, ներքին սերվերների համար SSL և տարբեր կոնֆիգուրացիաներ, որոնք թույլատրված չեն հանրային վստահելի վկայագրերում, ինչպես պահանջվում է CA/Browser Forum-ի կողմից:

Բրաուզերները հակադարձում են

Հարկ է նշել, որ բրաուզերի մշակողները փորձում են դիմակայել այս միտումին և պաշտպանել վերջնական օգտագործողներին MiTM-ից: Օրինակ՝ մի քանի օր առաջ Mozilla-ն որոշում կայացրեց Լռելյայն միացրեք DoH (DNS-over-HTTPS) արձանագրությունը Firefox-ի հետևյալ դիտարկիչի տարբերակներից մեկում: DoH արձանագրությունը թաքցնում է DNS հարցումները DPI համակարգից՝ ավելի դժվարացնելով SSL-ի ստուգումը:

Նմանատիպ ծրագրերով 10 թվականի սեպտեմբերի 2019-ը հայտարարվեց Google Chrome բրաուզերի համար:

Հարցմանը կարող են մասնակցել միայն գրանցված օգտվողները։ Մուտք գործել, խնդրում եմ:

Ի՞նչ եք կարծում, ընկերությունն իրավունք ունի՞ ստուգել իր աշխատակիցների SSL տրաֆիկը:

• Այո, նրանց համաձայնությամբ։

• Ոչ, նման համաձայնություն խնդրելն անօրինական է և/կամ էթիկայից դուրս:

Քվեարկել է 122 օգտատեր։ 15 օգտատեր ձեռնպահ է մնացել։

Source: www.habr.com