ძველი VPN ფაილური პორტალის ჩანაცვლება: შევინარჩუნოთ კონტროლი
ნატიური ფაილური კლიენტი და პროქსი პორტალი ნებართვებს, აღდგენასა და იდენტობას სხვადასხვა ადგილას ახორციელებს. შეადარეთ ისინი ოთხ ოპერაციაზე, რომლებიც მომხმარებლებს სჭირდებათ.
ძველ პორტალს კლიენტის გარეშე ჰქონდა წაშლის ღილაკი, რჩეულის ვარსკვლავი და ელფოსტაში ჩასმული გაზიარების ბილიკი. აქედან მხოლოდ ერთია კონტროლი. პორტალის ჩანაცვლება ნიშნავს გადაწყვიტოთ, რომელი ოპერაციები სჭირდება დისტანციურ მომხმარებლებს ჯერ კიდევ და სად სრულდება თითოეული, და არა გავამრავლოთ იმ გვერდის განლაგება, რომელიც შემთხვევით მუშაობდა. ჩანაცვლების ორი ფორმა ფარავს შემთხვევების უმეტესობას, და ისინი სხვადასხვა წერტილში მარცხდება.
ღილაკი ნებართვა არ არის
დაიწყეთ ოპერაციების სიით: კითხვა, ატვირთვა, გადარქმევა, წაშლა. გადაწყვიტეთ რომელი როლები იღებს თითოეულს, შემდეგ ეს გადაწყვეტილება განახორციელეთ ფაილურ სერვისში და არა ინტერფეისში. წაშლის კონტროლის დამალვა ახალ პორტალში უცვლელად ტოვებს ბექენდის ნებართვას, და ვისაც აქვს ნატიური კლიენტი და იგივე ანგარიში, მაინც შეუძლია ფაილის მოშორება.
წაშლა ცალკე გადაწყვეტილებას იმსახურებს, რადგან ეს არის ოპერაცია, რომელზეც მომხმარებლები ნანობენ. ჰკითხეთ, საიდან შეიძლება წაშლილი ელემენტის რეალურად აღდგენა, და ნუ ჩათვლით, რომ პასუხი ლეპტოპის კალათა ან თავად პორტალის ნაგავია. ქსელური გაზიარება ჩვეულებრივ წაშლებს ლოკალური კალათის გავლით არ მიმართავს.
Windows-ზე დაფუძნებულ გაზიარებაზე Volume Shadow Copy უზრუნველყოფს სნეპშოტების მექანიზმს და იმ კოორდინაციას, რომელსაც სარეზერვო პროგრამა იყენებს, მაგრამ მისი არსებობა არაფერს ამბობს იმაზე, ინახავს თუ არა ეს გაზიარება აღდგენად ვერსიებს. ფაილური სერვისის მფლობელმა უნდა დაადასტუროს ვერსიების პოლიტიკა და აჩვენოს აღდგენა სანამ პორტალი მოქმედებიდან გავა.
ვარიანტი A: ნატიური ფაილური კლიენტი გვირაბის გავლით
დამაპირებული დისკი ან SMB კლიენტი ინარჩუნებს ოპერაციებს, რომლებიც მომხმარებლებმა უკვე იციან, და ნებართვებს ყოველ მოთხოვნაზე ფაილური სერვერი ახორციელებს. მთავარი იდენტობა ფაილური სერვისის იდენტობაა, ამიტომ წვდომა გადაურჩება VPN პროდუქტის შეცვლას, სანამ გვირაბი კვლავ ატარებს ტრაფიკს და ანგარიში ჯერ კიდევ არსებობს.
ფასი ის არის, რომ კლიენტმა სერვისამდე პირდაპირ უნდა მიაღწიოს. სახელების გარჩევა, პორტების ხელმისაწვდომობა და აუთენტიფიკაციის მეთოდი ყველა ხდება დისტანციური წვდომის დიზაინის ნაწილი, და პორტალი, რომელიც ადრე კავშირს პროქსავდა, ყველა ამ მოთხოვნას მალავდა. მართულებადი მოწყობილობების მომხმარებლები ასევე იღებენ თავიანთ ფაილების მენეჯერში ჩამონტაჟებულ გაზიარებას, რაც უფრო ფართო ზედაპირია, ვიდრე ბრაუზერის ჩანართი. დაბიუჯეტეთ ეს მხარდაჭერის დატვირთვა მიგრაციამდე, რადგან ის პირველივე დღეს მოდის და არა შეღავათიანი პერიოდის შემდეგ.
აღდგენა ამ ფორმის სასარგებლოდ ყველაზე ძლიერი არგუმენტია: წინა ვერსიები და აღდგენის ნებართვები პლატფორმის ნატიურია, და დახმარების სამსახურს შეუძლია გამოიყენოს იგივე პროცედურა, რომელსაც ადგილზე იყენებს.
ვარიანტი B: პროქსი ან აპლიკაციის კარიბჭე
პორტალი, რომელიც ფაილს იღებს და ბრაუზერში უტყდება, ფაილურ სერვისს მომხმარებლის ქსელური ბილიკიდან აშორებს. ეს სასარგებლოა, როცა მოწყობილობა გვირაბს ვერ შეუერთდება ან როცა ორგანიზაციას სურს ყოველი მოთხოვნის ერთ შევიწროების წერტილში აღრიცხვა. კომპრომისი ის არის, რომ პროქსი ყოველი ოპერაციის მონაწილე ხდება, და მან მომხმარებლის იდენტობა უნდა მიიტანოს ფაილურ სერვისამდე, ყველაფრისთვის საკუთარი მომსახურების ანგარიშის გამოყენების ნაცვლად.
წაშლისა და გადარქმევის ქცევა უნდა განხორციელდეს და არა მემკვიდრეობით მივიღოთ. თუ პროქსი წაშლის მოქმედებას ამჟღავნებს, ეს მოქმედება ბექენდს რაღაც იდენტობით იძახებს, და აუდიტის კვალი მომხმარებელს უნდა ასახელებდეს და არა კარიბჭეს. თუ პროქსი ვერ გადაარქმევს, თქვით ეს სანამ მომხმარებლები პროექტის შუაში აღმოაჩენენ.
ბმულების გადაწერა ის ადგილია, სადაც ეს ფორმა ჩუმად ცვლის მნიშვნელობას. URL, რომელსაც პორტალი პროქსავს, არ არის იგივე ობიექტი, რაც URL, რომელსაც ბრაუზერი პირდაპირ ხსნის, და ერთის მეორედ გადაქცევამ შეიძლება მოშოროს ის აუთენტიფიკაციის კონტექსტი, რომელიც მას ამუშავებდა.
სახელები, იდენტობები და მათ შორის ბმულები
დაარიგეთ დამტკიცებული სერვერი და გაზიარების ბილიკი და არა დომენის დათვალიერების სია. დათვალიერება დამოკიდებულია აღმოჩენის სერვისებზე, რომლებმაც შეიძლება გვირაბი ვერ გადალახონ, და ბილიკი, რომელიც მუშაობს იმიტომ, რომ მომხმარებლის ლეპტოპს დომენის ჩამოთვლა შეუძლია, ბილიკია, რომელიც შემდეგ მართულებად მოწყობილობაზე გატყდება.
გადახედეთ ერთჯერად შესვლას აპლიკაცია აპლიკაციით. პორტალისთვის გაცემული ტოკენი არ უნდა გადაიკრას ფაილურ სერვისზე, რომელსაც ის არასდროს გადაუმოწმებია, და იდენტიფიკატორების მატარებელი მოთხოვნის პარამეტრები არ უნდა დაკოპირდეს საჯარო ბმულში მხოლოდ იმიტომ, რომ ძველ სანიშნეში გამოჩნდნენ. მოექეცით ყოველ დამტკიცებულ აპლიკაციას, როგორც საკუთარ ნდობის საზღვარს.
| Requirement | Native client | Proxy portal |
|---|---|---|
| Permission enforcement | File service, per request | Proxy identity, then file service |
| Restore path | Platform versions and backups | Proxy trash plus backend restore |
| Device requirements | Tunnel and client | Browser only |
| Audit identity | File server logs | Proxy logs, if it forwards the user |
აირჩიეთ მოთხოვნების სიის მიხედვით
არც ერთი ფორმა არ იმარჯვებს პირდაპირ. მომუშავე გვირაბის მქონე მართული ლეპტოპების სამუშაო ძალა მეტს იღებს ნატიური კლიენტისგან, რადგან აღდგენა და ნებართვები პლატფორმიდან მოდის და არა ხელახალი იმპლემენტაციიდან. კონტრაქტორებისა და პირადი მოწყობილობების შერეული პოპულაცია შეიძლება ამართლებდეს პროქსს, თუ იდენტობის ინფრასტრუქტურა რეალურია და არა საერთო მომსახურების ანგარიში.
ჩამოწერეთ შედარება ოთხ ოპერაციასთან და აღდგენის პასუხთან, შემდეგ ძველი პორტალი გააუქმეთ მხოლოდ მას შემდეგ, რაც ახალი ბილიკით ერთი აღდგენა შესრულდა. ეს ტესტი ავარჯიშებს დიზაინის იმ ნაწილებს, რომლებსაც წარმატებული შესვლა არასდროს ეხება.