MySQL՝ VPN-ի միջոցով. ստուգեք սերվերը, ոչ միայն գաղտնագրումը
Սխալ հոսթին գաղտնագրելը դեռ սխալ է։ Համեմատեք ssl-mode արժեքները, ապա գործարկեք մի կապ, որը նշում է նախատեսված սերվերը և դա ապացուցում։
Դուք պահում եք կապ դեպի 10.20.4.15, VPN-ը ընկնում է, և հաճախորդը դեռ միանում է։ Սա լավ լուր չէ։ Մասնավոր հասցեն դիրք է ցանկացած այն երթուղային համատեքստի ներսում, որտեղ դուք գտնվում եք, և շատ ցանցեր օգտագործում են նույն տիրույթները։ Հաճախորդը հասավ MySQL սերվերի, պարզապես գուցե ոչ ձերին։
Ուղղումը երկու կես ունի, և դրանցից միայն մեկն է ցանցի մասին։ Պահեք կապը իր նախատեսված ուղու վրա և ստիպեք հաճախորդին վավերացնել այն սերվերը, որի հետ խոսում է։ Առաջին կեսն այն է, որտեղ VPN-ն օգնում է. երկրորդ կեսը պետք է կարգավորվի։
Գաղտնագրված ինչի՞ն, ճիշտն ասած։
TLS-ը պաշտպանում է զրույցը մեջտեղում գտնվող ցանկացածից և ոչինչ չի ասում այն մասին, թե վերջնակետն ինքն իրեն ով է հայտարարում, եթե հաճախորդը չստուգի։ Վստահելի մարմնի դեմ վավերացվող վկայականը ապացուցում է, որ վկայականը եկել է այդ մարմնից։ Այն չի ապացուցում, որ վկայականը տրվել է այն հոսթի անվան համար, որին ուզում էիք հասնել, և դրանք տարբեր հարցեր են։
Սա տեսական բաց չէ։ Captive պորտալները, սխալ VRF-ի սխալները և համընկնող հասցեային պլանները բոլորը ստեղծում են սերվեր, որը լիովին պատրաստ է ձեզ հետ TLS բանակցելու։ Եթե հաճախորդը պահանջում է միայն գաղտնագրում, սեսիան մասնավոր է և ուղղված է սխալ տվյալների բազային։
Այսպիսով, համապատասխան հարցը ոչ թե այն է, թե արդյոք կապը գաղտնագրված է, այլ այն, թե արդյոք այն գաղտնագրված է այն ինքնությանը, որը նկատի ունեիք։ MySQL-ի հաճախորդում այդ տարբերությունն ամբողջությամբ ապրում է ssl-mode կարգավորման մեջ։
Հինգ ssl-mode արժեքները գործնականում
Գոյություն ունեն հինգ արժեք, և դրանցից միայն մեկն է պատասխանում այս ձեռնարկի հարցին։ Աղյուսակը թվարկում է, թե ինչ է յուրաքանչյուրն իրականում երաշխավորում, այլ ոչ թե ինչ է հուշում նրա անունը։
| Mode | What it guarantees |
|---|---|
DISABLED | No TLS at all; everything on the wire is readable |
PREFERRED | Tries TLS and falls back to plaintext when the account and server allow it, so it is not a fail-closed requirement |
REQUIRED | Refuses to connect without TLS, and does not validate the certificate |
VERIFY_CA | Validates the server certificate against the configured CA and does not check the hostname |
VERIFY_IDENTITY | Validates the CA and checks that the certificate names the host the client used |
Այս հոդվածի հարցին պատասխանում է միայն վերջին տողը։ PREFERRED արժե առանձին նշել, որովհետև հաճախորդը, որը լուռ անցնում է բաց տեքստի, ավելի վատն է, քան մերժողը. դուք կարծում եք, որ գաղտնագրում ունեք, իսկ փաթեթների գրանցումը համաձայն չէ։
Կապ, որը կարող եք գործարկել այսօր
Ստորև բերված հրամանը այն ձևն է, որ պետք է օգտագործեք, երկու տեղապահերով. հաստատված տվյալների բազայի անունը և հաստատված ալիքով ստացված CA ֆայլը։ Ոչ մեկը չպետք է վերցվի այն բանից, ինչ սերվերը առաջարկում է ձեզ առաջին շփման ժամանակ։
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password առանց արժեքի հարցնում է մուտքագրում, ինչը գաղտնիքը պահում է գործընթացների ցանկից և ձեր shell-ի պատմությունից դուրս։ Սա փոքր սովորություն է մեծ օգուտով համօգտագործվող jump հոսթերում, որտեղ հրամանի տողը տեսանելի է այլ օգտվողներին։
Երբ սա ձախողվում է, սխալի տեքստը տարբերում է դեպքերը ավելի լավ, քան ինտուիցիան։ CA-ի ձախողումը նշանակում է, որ շղթան չի վավերացվում, և դուք պետք է նայեք, թե որ CA-ն է ստորագրել սերվերի վկայականը։ Հոսթի անվան ձախողումը նշանակում է, որ շղթան կարգին է, իսկ անունը չի համընկնում, ինչը սովորաբար նշանակում է, որ դուք միացել եք ճիշտ սերվերին սխալ անվան տակ, այլ ոչ թե սխալ սերվերին։
Հուշման հայտնվելը ապացույց չէ, որ գաղտնաբառն արդեն փոխանցվել է, և ձախողված կապը չի ապացուցում, որ ոչինչ չի հեռացել հաճախորդից։ Եթե վերակառուցում եք անցյալի իրադարձություն, նշեք հաճախորդը, նրա կազմաձևը, նույնականացման պլագինը և այն փուլը, որը ձախողվել է։ Վերջնական սխալի հաղորդագրությունից ազդեցությունը գնահատելը գուշակություն է։
Երբ անունը գալիս է թունելից
Տեղական պորտի փոխանցումը կոտրում է ինքնության ստուգումը մի կերպ, որ զարմացնում է մարդկանց։ Եթե տեղական պորտը փոխանցեք տվյալների բազային և միանաք localhost հասցեին, հաճախորդը վավերացնում է վկայականը localhost-ի դեմ, և այդ անվան համար վկայական չի տրվել։ Կապը կարող է լրիվ անվտանգ լինել, և ստուգումը միևնույն է ձախողվելու է, ինչը հենց այն ստուգումն է, որն աշխատում է ինչպես նախատեսված է։
Երկու ազնիվ պատասխան կա։ Փոխանցված վերջնակետին տվեք անուն, որը լուծվում է loopback հասցեի և հայտնվում սերվերի վկայականում, կամ օգտագործեք հոսթի անունը սկզբից մինչև վերջ, որպեսզի հաճախորդը ստուգի իրական ինքնությունը։ Առաջինը հարմար է մշակողների համար և պահանջում է վկայականների աշխատանք. երկրորդն ավելի հեշտ է մտածել և հաճախ ճիշտ լռելյայն է ավտոմատացման համար։ Ստուգումն անջատելը, որպեսզի փոխանցումը աշխատի, դեն է նետում այն հատկությունը, որը փորձում էիք ավելացնել։
Ընդունումը երեք պայման է
Գրեք ընդունման թեստը որպես երեք առանձին պնդում. կապն օգտագործել է նախատեսված ուղին, գաղտնագրումը պահանջվել է, այլ ոչ թե նախընտրելի է եղել, և սերվերի ինքնությունը ստուգվել է վստահելի նյութի դեմ։ Կանաչ VPN պատկերակը դրանցից ոչ մեկը չի հաստատում։
GUI հաճախորդների և MariaDB-ի համար ստուգեք հենց վաճառողի փաստաթղթերը՝ փոխարենը ենթադրելու, որ դրոշի ուղղագրությունը փոխանցվում է։ MySQL-ի փաստաթղթերը գաղտնագրված կապերի մասին ընդգրկում են ռեժիմների տարբերությունները և CA-ի տարածման պահանջը, և սա այն հղումն է, որը պետք է ստուգել արտադրական կապի տողը փոխելուց առաջ։