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 სწორი რჩება იმ ადამიანებისა და ხელსაწყოებისთვის, რომელთა დამტკიცებული სამუშაო ამას მოითხოვს. შეზღუდეთ ეს დიზაინი როლებით, ქსელური მოცვითა და ოპერაციული ზღვრებით, და დატოვეთ სხვა კლიენტებს ვიწრო ინტერფეისი. ორი ჯგუფის ერთ როლში შერევა არის ადგილი, სადაც კამათი იწყება.