Արդյո՞ք iPad-ին պետք է սեփական VPN հաճախորդի վկայական։

Նոր iPad-ը միանում է թիմին, և ամենաարագ ուղին գոյություն ունեցող հաճախորդի վկայականն արտահանելն ու պլանշետում տեղադրելն է։ Դա աշխատում է այնքան ժամանակ, քանի դեռ ինչ-որ մեկը չի հեռանում, սարք չի կորցնում կամ չի պահանջում աուդիտ, որը կասի, թե որ սարքը երբ է միացել։ Որոշումը վկայականի ֆայլի մասին չէ, այլ ինքնության. թե արդյոք յուրաքանչյուր սարք կարող է ինքնուրույն լիազորվել և չեղարկվել։ Ծախսն ու կառավարման աշխատանքը որոշում են պատասխանը, և երկուսն էլ ավելի փոքր են, քան թվում են։

Ընդհանուր թողարկող, առանձին ինքնություններ

Յուրաքանչյուր սարք կարող է վստահել նույն վկայականների մարմնին և միանալ նույն դարպասին՝ ունենալով այլ հաճախորդի ինքնություն։ Թողարկողը վստահության խարիսխ է, իսկ ինքնությունը՝ բանալիների զույգ, որի սուբյեկտը սերվերը քարտեզագրում է քաղաքականության։ Հենց այս երկուսը շփոթելն է ընդհանուր վկայականը անվնաս թվացնում։ Այն անվնաս է մնում միայն այնքան ժամանակ, քանի դեռ ինչ-որ մեկին պետք չէ իմանալ, թե որ սարքն է բացել նստաշրջան։

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

Երբ երկրորդ վկայականը չափազանց թանկ է

Սարքով գրանցումը մեկ քայլ արժե՝ կառավարվող բեռնվածք, SCEP հարցում կամ ուղղորդված ներմուծում մեկանգամյա գաղտնաբառով։ Այն նաև տեղ է պահանջում սերիական համարներն ու ժամկետները հետևելու համար, այն մասը, որը տեղակայումների մեծ մասը մոռանում է մինչև առաջին վկայականի ժամկետը լրանալը։ Երկու ծախսերն էլ մեկանգամյա են, և երկուսն էլ նվազում են, երբ գրանցման հոսքը ավտոմատացնում է դրանք։

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

Գրանցեք սարքը, մի պատճենեք բանալին

Ժամանակակից հարթակները մասնավոր բանալիները պահում են պաշտպանված պահոցում, և որոշները դիզայնով նշում են դրանք որպես չարտահանվող։ Հենց այդ հատկությունն է պատճենումն ի սկզբանե անհնար դարձնում, և դա է նաև պատճառը, որ նոթբուքից արտահանված փաթեթը չի կարող պարզապես վերաներմուծվել պլանշետում որևէ աջակցվող եղանակով։ Փորձը, այնուամենայնիվ, ստեղծում է պրոֆիլ, որը մաքուր տեղադրվում է և հետո երբեք չի նույնականացնում։

Օգտագործեք գրանցման այն մեթոդը, որն արդեն աջակցում է տեղակայումը՝ կառավարվող ինքնության բեռնվածք, SCEP ծառայություն կամ հաշվի վրա հիմնված հոսք, որը սարքում նոր բանալի է թողարկում։ Վկայականների մարմնի մասնավոր բանալին բաշխելը բացակայող ինքնությունը լուծելու համար այլ սխալ է՝ շատ ավելի մեծ ազդեցության շառավղով։ Մարմինը թողարկում է վկայագրեր և երբեք չպետք է ճամփորդի վերջնակետ։

Ստուգեք չեղարկումը նախքան պատասխանելը

Նախքան ընդհանուր տարբերակն ընտրելը, նկարագրեք, թե ինչպիսի տեսք ունի չեղարկումն ամենավատ օրը։ Եթե պատասխանը մի գործողություն է, որն ազդում է մի քանի սարքի վրա, դիզայնն արդեն որոշել է ձեր դեմ։

openssl pkcs12 -in client.p12 -info -noout
openssl x509 -in client.pem -noout -subject -issuer -serial -dates
openssl verify -CAfile ca.pem client.pem

Ուսումնասիրեք այն նյութը, որն իրականում ունեք՝ կա արդյոք մասնավոր բանալի, ինչ է ասում սուբյեկտը և կարելի է արդյոք սերիական համարը չեղարկել առանձին։ Առանց իր բանալու վկայականի ֆայլը ոչինչ չի կարող նույնականացնել, և դրա համար են որոշ պատճենված ինքնություններ ձախողվում առաջին միացմանը։

Պլանշետից հավելվածը ջնջելը չեղարկում չէ, և սերվերը շարունակում է ընդունել ինքնությունը, քանի դեռ ինչ-որ մեկը չի անջատել այն։ Գրեք այդ նախադասությունը գործառնական ուղեցույցում նախքան առաջին սարքի գրանցումը։