ბაზის განახლება შუამავლებით იწყება: PgBouncer-ისა და Hyperdrive-ის გაკვეთილები

წარმატებული SQL მოთხოვნა ბაზის განახლების საკმარისი შემოწმება არ არის. ის ვერ გვიჩვენებს, სწორი მომხმარებელი მივიდა თუ არა ბაზამდე, დარჩა თუ არა წინა სესიის მდგომარეობა და სწორია თუ არა ქეშირებული პასუხი. ოქტომბრის ოთხი პუბლიკაცია ამ საზღვრებს სხვადასხვა მხრიდან წარმოაჩენს.

პრაქტიკული არჩევანი ასეთია: გამოშვების მიღებისას უნდა შემოწმდეს მთელი გზა მომხმარებლიდან შენახულ ჩანაწერამდე. შეიძლება ბაზა, კავშირების პული და ცვლილებების მიწოდების სისტემა ცალ-ცალკე გამართულად მუშაობდეს, საერთო შედეგი კი მაინც მცდარი იყოს.

ოთხი წყარო, სხვადასხვა რისკი

PgBouncer-ის 14 ოქტომბრის განახლება ავთენტიფიკაციისა და მომსახურების შეფერხების მოწყვლადობებს ასწორებს. GitLab-ის 12 ოქტომბრის განცხადების მიმდინარე ვერსიებია 19.4.2, 19.3.5 და 19.2.8.

Cloudflare-ის 14 ოქტომბრის ანალიზი კავშირის მდგომარეობასა და ქეშირების შეცდომებს ეხება. PlanetScale-ის 12 ოქტომბრის მასალა დიდი მნიშვნელობების შენახვას განიხილავს. ეს სხვადასხვა პროდუქტია. მათი შედარება გვაძლევს შემოწმების მეთოდს და არა კონკრეტული ვერსიების თავსებადობის მტკიცებულებას.

რას ტოვებს ჩვეულებრივი ტესტი შეუმოწმებელს

საწყისი შემოწმება ხშირად ერთ როლს, ახალ კავშირსა და პატარა ჩანაწერს იყენებს. სამუშაო სისტემაში კავშირი ხელახლა გამოიყენება, მომხმარებლებს განსხვავებული უფლებები აქვთ, დოკუმენტები კი ზომითა და სტრუქტურით განსხვავდება.

ავთენტიფიკაციას აკრძალული მოქმედების ტესტი სჭირდება. პულს სესიების იზოლაცია უნდა შევუმოწმოთ. ქეშის პასუხი შესაბამისი მომხმარებლის უფლებებით მიღებულ პასუხს უნდა შევადაროთ. შენახვის ცვლილებისას საჭიროა რეალური მოხმარების მსგავსი მონაცემები. ერთი საშუალო დრო ამ კითხვებს ვერ პასუხობს.

უკან დაბრუნებაც კომპონენტების მიხედვით იგეგმება. აპლიკაციის ძველი კოდი პულის კონფიგურაციას არ აღადგენს. ქეშის გამორთვამ შეიძლება ბაზის დატვირთვა გაზარდოს. ბიბლიოთეკის დაბრუნება უკვე გარდაქმნილ მონაცემს ვერ გააუქმებს.

პირობითი მაგალითი: დოკუმენტების პორტალი

წარმოვიდგინოთ კონტრაქტორების პორტალი, სადაც სია მოკლე აღწერას აჩვენებს, ბარათი კი სრულ ხარჯთაღრიცხვას ხსნის. ეს პროექტირების მაგალითია და არა შესრულებული პროექტის აღწერა.

ვამზადებთ ორი ორგანიზაციის ჩანაწერებს, განსხვავებულ უფლებებსა და რამდენიმე ზომის დოკუმენტს. ჯერ ცნობილ საწყის გარემოში ვაფიქსირებთ სწორ პასუხებს, შემდეგ იმავე მოთხოვნებს შუამავლის გავლით ვიმეორებთ. ორგანიზაცია A კითხულობს დოკუმენტს, გამოდის სისტემიდან და ორგანიზაცია B იმავე იდენტიფიკატორს ითხოვს. B-ს უცხო ჩანაწერი არ უნდა გაეხსნას, თუნდაც პასუხი ქეშში იყოს.

შემდეგ ვამოწმებთ გამოყენებულ კავშირსა და შეცდომის შემდეგ მოთხოვნას. სიის მოთხოვნამ ყველა სრული დანართი შემთხვევით არ უნდა ამოიღოს. დიდი დოკუმენტი აქ რესურსის მოხმარებასა და წვდომის ფორმას ამოწმებს.

მოულოდნელი ცარიელი პასუხი ავტომატურად წაშლის ბრძანებად არ უნდა იქცეს. ჯერ ინახება მოთხოვნის იდენტიფიკატორი და მოწმდება შეუსაბამობა. ამ მიდგომას აქვს ფასი: დროებითი გაურკვევლობა და ოპერატორის სამუშაო. დამტკიცების პროცესში ეს ხშირად უფრო მისაღებია, ვიდრე შეუქცევადი მცდარი მოქმედება.

განახლების გადაწყვეტილება

დაზარალებული უსაფრთხოების კომპონენტის პატჩს მოკლე, მომზადებული მიღების პროცედურა სჭირდება. შენახვის ოპტიმიზაცია და ახალი ქეში შეიძლება ცალკე გამოვუშვათ. მათი ერთ გამოშვებაში გაერთიანება მიზეზის პოვნას ართულებს.

ჯერ ვამოწმებთ უფლებების შეზღუდვას, პასუხის შინაარსსა და შეფერხების შემდეგ აღდგენას. სიჩქარეს შემდეგ ვაფასებთ წარმომადგენლობით მონაცემებზე. წყაროებიდან უნივერსალური აჩქარების პროცენტი არ გამომდინარეობს.

დამატებითი საფუძველია სერვერი როგორც სისტემის ბირთვი. საკუთარი API-ის პროექტი მონაცემების, უფლებებისა და კონტრაქტების კონტექსტს იძლევა. ინტეგრაციების დაგეგმვა მოთხოვნის გზისა და სწორი შედეგის განსაზღვრით შეიძლება დავიწყოთ.