Excel პარტნიორის SQL Server-ზე დომენური ნდობის გარეშე

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

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

სამი გადაწყვეტილება, რომელსაც კითხვა მალავს

იდენტობა არის ის, ვინც ხართ მონაცემთა ბაზის აზრით: Windows-ის ანგარიში სანდო დომენიდან, SQL შესვლა საკუთარი პაროლით, ან სერტიფიკატზე დაფუძნებული იდენტობა. ტრანსპორტი არის ის, დაშიფრულია თუ არა სესია და ამოწმებს თუ არა კლიენტი სერვერის სერტიფიკატების ჯაჭვს. გზა არის ის, როგორ აღწევენ პაკეტები მსმენელამდე, რომელიც შეიძლება იყოს VPN, კერძო კავშირი ან საჯარო ბოლო წერტილი firewall-ის წესებით. თითოეული სხვა ადგილას ცხოვრობს და თითოეული დამოუკიდებლად შეიძლება ჩავარდეს.

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

იდენტობა ტყის ნდობის გარეშე

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

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

დაშიფვრა კი, მაგრამ სერტიფიკატის ნდობა?

ODBC Driver 18-ით Encrypt=Yes;TrustServerCertificate=No ითხოვს დაშიფრულ სესიას, რომლის სერტიფიკატიც ნამდვილად მოწმდება. მაშინ კავშირის სტრიქონმა უნდა დაასახელოს სერვერი, რომელსაც სერტიფიკატი ფარავს, და კლიენტმა უნდა ენდოს მის ჯაჭვს. Driver 18 ნაგულისხმევადაც შიფრავს, წინა ვერსიებისგან განსხვავებით, ამიტომ ძველმა კავშირის სტრიქონმა შეიძლება ახლა TLS-ზე მოილაპარაკოს ამის თქმის გარეშე. ცხადი პარამეტრები განზრახ პოლიტიკას ყველა მანქანაზე ხილვადს ხდის, რაც მნიშვნელოვანია, როცა რამდენიმე ადამიანი ერთსა და იმავე წიგნს ინახავს.

TrustServerCertificate=Yes შიფრავს და გამოტოვებს შემოწმებას, რაც არ არის ეკვივალენტური შეკეთება სახელის შეუსაბამობის ან არასანდო ჯაჭვისთვის. ის აცილებს სიგნალს, რომელიც გეტყოდათ, რომ კლიენტი არასწორ ბოლო წერტილს მიაღწია, ამიტომ შეასწორეთ სერტიფიკატი ან სახელი.

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

ქსელური გზა დაცვა არ არის

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

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

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