TLS-ը, ցանցային մուտքը և SQL լիազորությունները տարբեր հարցերի են պատասխանում
Կապի գաղտնագրումը, աղբյուրի թույլատրումը և աղյուսակի տրամադրումը երեք որոշում են։ Անցեք դրանք հերթականությամբ, նախքան հարցնելը՝ կարո՞ղ է TLS-ը փոխարինել VPN-ին։
Ինչ-որ մեկը առաջարկում է հաճախորդին տալ PostgreSQL մուտք, որպեսզի ծախսի հայտը գաղտնագրված անցնի սկզբից մինչև վերջ։ Տվյալների բազայի ադմինիստրատորին պետք է իրական SQL սեսիա, և մեկ ուրիշը փոխարենը առաջարկում է վեբ ձև։ Երկու առաջարկներն էլ լուծում են սխալ խնդիրը, որովհետև ոչ մեկը չի սկսել այն գործողությունից, որը հաճախորդն իրականում կատարում է։ Անցեք երեք որոշումները հերթականությամբ, և TLS-ը VPN-ին փոխարինելու հարցը ինքն իրեն կպատասխանի։
Սկսեք այն գործողությունից, որն անհրաժեշտ է հաճախորդին
Գրեք, թե ինչի պետք է հասնի հաճախորդը։ Հայտ ներկայացնելը, հաշվետվության մեկ տող կարդալը և ակնթարթային հարցում կատարելը երեք տարբեր գործողություններ են՝ երեք տարբեր ռիսկի պրոֆիլներով։
Այնուհետև գրեք, թե ով է կատարում հարցումը։ Հաճախորդը, աջակցության գործակալը և ադմինիստրատորը փոխարինելի չեն նույնիսկ երբ դիպչում են նույն աղյուսակին։ Տարբերությունը որոշում է, թե հարցումների լեզվի որքան մասը հաճախորդը պետք է ընդհանրապես տեսնի։
Պատասխանների զույգը որոշում է ինտերֆեյսը։ Ամեն ինչ դրանից հետո իրականացում է, և գաղտնագրման մասին վեճերի մեծ մասը իրականում վեճեր են այն մասին, թե որ ինտերֆեյսն է ընտրվել։
Երեք վերահսկիչ, երեք որոշում
Նույնականացված TLS-ը պաշտպանում է կապը և որոշում, թե որ TLS ինքնություններն են ընդունվում։ Ցանցային մուտքը որոշում է, թե որ աղբյուրները կարող են ընդհանրապես հասնել լսողին։ Տվյալների բազայի լիազորումը որոշում է, թե դերը որ օբյեկտներ և գործողություններ կարող է օգտագործել։
Երեքից ոչ մեկը չի փոխարինում մյուսներին, ինչը աղյուսակը հստակ ցույց է տալիս։
| Control | What it decides | What it leaves open |
|---|---|---|
| Authenticated TLS | Connection protection and which TLS identities are accepted | Which tables a database user may touch |
| Restricted network entry | Which sources reach the listener | Whether an authenticated user should run a given statement |
| Database authorization | Which objects and actions a role may use | Whether the connection arrived by an approved path |
Կարդացեք այն տողը, որի վրա հենվում եք, նախքան մյուսը հեռացնելը։ Այս նախագծերի մեծ մասը ձախողվում է, որովհետև վերահսկիչը ենթադրվել է, այլ ոչ թե կարգագրվել։
Ուղիղ SQL-ը տվյալների բազայի քաղաքականությունը պահում է պատասխանատու
Հաստատված ուղիղ կապի դեպքում պահպանեք և՛ ծառայության ինքնության ստուգումը, և՛ նախատեսված մուտքի քաղաքականությունը։ TLS-ը միացնելը գաղտնագրված կապերը հասանելի է դարձնում, սակայն չի մերժում չգաղտնագրվածները, քանի դեռ մուտքի կարգավորումը hostssl գրառումներով դա չի պահանջում։
Այս տարբերությունն արժե ստուգել աշխատող կարգավորումում, ոչ թե ձևանմուշում։ TLS առաջարկող և բաց տեքստ ընդունող սերվերը այն նախագիծը չէ, որը մեծամասնությունը կարծում է, թե տեղակայել է։ Կարդացեք մուտքի կանոնները և տեսեք, թե որ գրառումներն են իրականում դա պահանջում։ Այդ մեկ ստուգումը առանձնացնում է գաղտնագրման ընդունակ սերվերը միայն գաղտնագրվածից։
Օգտագործեք դերեր միայն աշխատանքի համար անհրաժեշտ լիազորություններով, և վերանայեք սեփականությունը, ժառանգված անդամակցությունը և լայնորեն տրված թույլտվությունները։ PostgreSQL-ի լիազորությունների մոդելը տվյալների բազայի օբյեկտների իշխանության սահմանն է։
VPN-ը կարող է սահմանափակել, թե որ սարքերն են հասնում ծառայությանը՝ նախքան տվյալների բազայի նույնականացումը, և մուտքի դարպասը կարող է նման բան անել։ Երկուսից ոչ մեկը չի վերացնում բացահայտված բաղադրիչի սպասարկման, հավատարմագրերի կառավարման և ռեսուրսների օգտագործման սահմանափակման անհրաժեշտությունը։
Հաճախորդի վկայականը հավատարմագիր է, ոչ ACL
Հաճախորդի վկայականը կարող է պահանջ ավելացնել կապի պահին։ clientcert կարգավորումը կարող է պահանջել վստահելի վկայական և ավելի խիստ ռեժիմում՝ կապ վկայականի անվան և տվյալների բազայի օգտագործողի միջև։
Դա ավելի ուժեղ հավատարմագիր է։ Այն լիազորման ցանկ չէ և սերվերը անտեսանելի չի դարձնում, որովհետև կապն ընդունող բաղադրիչը դեռևս մշակում է ցանցային երթևեկություն և ձեռքսեղմում։ Վկայականին որպես մուտքի ցանկ վերաբերվելը թողնում է իրական թույլտվությունները անփոփոխ։ Այն նաև հակված է ընդլայնելու վկայականների բաշխումը, ինչը ստեղծում է հաջորդ խնդիրը։
Ավելորդ լիազորություններով դերին կցված ուժեղ վկայականը տալիս է լավ նույնականացված ադմինիստրատոր։ Ստուգեք դերը նախքան վկայականը տոնելը։
Ընտրեք ավելի նեղ ինտերֆեյսը, երբ այն համապատասխանում է
Ծախսի հայտի համար հայտն ընդունող, գործարար կանոնները պարտադրող և այդ օգտագործողի թույլատրված արդյունքը վերադարձնող հավելվածի վերջնակետը գործողությունն ավելի լավ է ներկայացնում, քան ընդհանուր SQL հաշիվը։
Այնուհետև հավելվածն օգտագործում է իր սեփական սահմանափակ տվյալների բազայի ինքնությունը, և հաճախորդը երբեք հարցումների լեզու չի ստանում որպես հատկություն։ Դա ավելի փոքր մակերևույթ է՝ սխալվելու ավելի քիչ ուղիներով։
Սա նախագծային տարբերակ է, ոչ թե պնդում, որ հավելվածի կոդը ինքնաբերաբար ավելի ապահով է։ Այդ կոդը պետք է նույնականացնի իր կանչողներին, լիազորի յուրաքանչյուր գործողություն և վավերացնի իր մուտքագրումը, և դրա սեփական թույլտվությունները տվյալների բազայում դեռևս կարևոր են։
Ուղիղ SQL-ը մնում է ճիշտ այն մարդկանց և գործիքների համար, որոնց հաստատված աշխատանքը դա պահանջում է։ Սահմանափակեք այդ նախագիծը դերերով, ցանցային ընդգրկումով և գործառնական սահմաններով, և թողեք մյուս հաճախորդները պահպանեն ավելի նեղ ինտերֆեյսը։ Երկու խմբերի միավորումը մեկ դերում այն տեղն է, որտեղից սկսվում են վեճերը։