კომპანიის ვებ აპლიკაციის VPN-ის მიღმა გადატანა: გადასვლის სახელმძღვანელო
თვალყური ადევნეთ ცვლილებას მომხმარებლის სანიშნიდან ძველ საჯარო მსმენელამდე. გეგმაში შეინახეთ HTTPS, აპლიკაციის ანგარიშები და ყოველი არა-თანამშრომელი გამომძახებელი.
წარმოიდგინეთ ცვლილება მომხმარებლის მხრიდან. ვიღაც სანიშნეს აჭერს, ელოდება ნაცნობ შესვლის გვერდს და სამაგიეროდ იღებს კავშირის შეცდომას, რადგან ჰოსტის სახელი ახლა მხოლოდ გვირაბის შიგნით პასუხობს. ეს ერთი მომენტი შეიცავს ყველაფერს, რაც მიგრაციის გეგმამ სწორად უნდა გააკეთოს: სახელი, გზა, სერტიფიკატი, ანგარიში და მის უკან არსებული ოპერაცია. გაიარეთ ქვემოთ მოცემული ნაბიჯები ამ თანმიმდევრობით და გადასვლა შეწყვეტს ნახტომობას.
ნაბიჯი 1: ჩაწერეთ, რას აკეთებენ მომხმარებლები დღეს
დაიწყეთ მისამართის ზოლში არსებული ჰოსტის სახელით, პორტით, ადამიანების მიერ შესრულებული ოპერაციებით და მათ მიერ გამოყენებული ანგარიშებით. თუ სამ ძირითად ოპერაციას ვერ დაასახელებთ, არ ხართ მზად საჯარო შესასვლელის დახურვისთვის, რადგან მიღების დროს ვერ ამოიცნობთ გატეხილს.
შემდეგ გადაწყვიტეთ, ვინ არის კერძო აუდიტორია. კორპორატიულ VPN-ზე მყოფი თანამშრომლები დასაწყისია და არა პასუხი. კონტრაქტორებს, მხარდაჭერის პერსონალს და ფინანსურ გუნდს შესაძლოა ყველას სჭირდებოდეს აპლიკაცია და შესაძლოა ყველა ერთი კარიბჭის უკან არ იჯდეს.
ნაბიჯი 2: გამოყავით გვირაბი შესვლისგან
როცა მომხმარებელი VPN-ის გავლით აღწევს აპლიკაციას, ბრაუზერი კვლავ ხსნის TLS კავშირს თავად აპლიკაციის ბოლო წერტილთან. სერტიფიკატი უნდა შეესაბამებოდეს ამ სახელს და აპლიკაცია კვლავ ამოწმებს ანგარიშს. გვირაბში არაფერი ცვლის არც ერთს.
აი, სადაც მიგრაციები ჩუმად ცდება. ვიღაც წყვეტს, რომ კერძო მისამართს აღარ სჭირდება სწორი სერტიფიკატი, მომხმარებლები სწავლობენ გაფრთხილების გავლით გადასვლას და ორგანიზაციამ საჯარო გამოვლენა გაცვალა უსაფრთხოების გაფრთხილებების იგნორირების ტრენინგით. თუ აპლიკაციას ნამდვილად სჭირდება შიდა სერტიფიკატი, გამოსცადეთ ერთი შიდა ორგანოსგან და სწორად გაანაწილეთ ნდობა. ეს კონტროლირებადი ცვლილებაა; გაფრთხილების გვერდი არა.
დატოვეთ ავტორიზაცია იქ, სადაც უკვე არის. NIST-ის ნულოვანი ნდობის არქიტექტურის შეჯამება პირდაპირ ამბობს: ქსელური მდებარეობა არ არის მგრძნობიარე ოპერაციის მინიჭების საფუძველი. გვირაბის შიგნით ყოფნა არ უნდა აქცევდეს მხოლოდ-კითხვის ანგარიშს ადმინისტრატორად.
ნაბიჯი 3: იპოვეთ გამომძახებლები, რომლებიც თანამშრომლები არ არიან
გახსენით აპლიკაციის კონფიგურაცია და ჩამოთვალეთ ყველაფერი, რაც მას ესაუბრება: იდენტობის მომწოდებლის უკუგამოძახების URL, გადახდის მომწოდებლის ვებჰუკი, დაგეგმილი იმპორტი, მონიტორინგის ზონდი, პარტნიორის API კლიენტი. თითოეული დამოკიდებულებაა მფლობელით და თითოეული სხვადასხვა მომენტში გატყდება.
გადაწყვიტეთ მხარდაჭერილი გზა თითოეულისთვის, რომელიც უნდა დარჩეს. ვებჰუკის მომწოდებელი ვერ შეუერთდება თქვენს თანამშრომელთა VPN-ს, ამიტომ ან გამოაჩინეთ ვიწროდ შემოსაზღვრული ინტეგრაციის ბოლო წერტილი საკუთარი ავთენტიფიკაციით, ან შეცვალეთ ინტეგრაციის მოდელი. მთელი აპლიკაციის საჯაროდ დატოვება ერთი უკუგამოძახების გამო არჩევანია და ჩვეულებრივ არასწორი.
ჩაწერეთ ყოველი გამონაკლისი დანიშნულებით, დაშვებული ოპერაციით, ავთენტიფიკაციით და მფლობელით. ინტეგრაციისთვის მიცემული ზოგადი VPN ანგარიში არის ის გზა, რომლითაც გამონაკლისი მუდმივი ხდება. გადახედეთ სიას შემდეგ წვდომის მიმოხილვაზე, რადგან ინტეგრაციები უფრო დიდხანს ცოცხლობენ, ვიდრე პროექტები, რომლებმაც ისინი დაამატეს. ვადის გარეშე გამონაკლისი მუდმივი დიზაინის გადაწყვეტილებაა, რომელიც არავის მიუღია.
ნაბიჯი 4: გააუქმეთ საჯარო მარშრუტი და არა მხოლოდ DNS ჩანაწერი
გაიარეთ გამოქვეყნების ჯაჭვი: DNS, დატვირთვის ბალანსირების მსმენელები, საპირისპირო პროქსის წესები, ჰოსტის ფაირვოლი და ნებისმიერი ალტერნატიული სახელი, რომელიც ჯერ კიდევ ძველ მისამართზე მიუთითებს. შეამოწმეთ მისამართების ორივე ოჯახი. ძირითადი A ჩანაწერის შეცვლა თითქმის არაფერს ამტკიცებს, თუ უფრო ძველი CNAME ან IPv6 მსმენელი კვლავ ემსახურება აპლიკაციას.
პარალელურად დაადასტურეთ, რომ კერძო სახელი გვირაბის შიგნით წყდება და სერტიფიკატი ფარავს იმ სახელს, რომელსაც მომხმარებლები აკრეფენ. მომხმარებელმა, რომელსაც რიცხვითი მისამართის ჩასმა უწევს, სიმპტომი იპოვა და არა გადაწყვეტა.
შემოსაზღვრეთ VPN აუდიტორია აპლიკაციის გზით. ოფისის ქსელზე ფართო წვდომა ერთ გამოვლენის გადაწყვეტილებას ცვლის უფრო დიდით და ადმინისტრაციულ ინტერფეისებს სჭირდებათ საკუთარი დაშვებული წყაროები და არა მომხმარებლის წესის მემკვიდრეობა.
ნაბიჯი 5: თავად გაიარეთ მიღება
დაუკავშირდით დამტკიცებულ მომხმარებლად, გახსენით სანიშნე, შეამოწმეთ სერტიფიკატი, შედით და შეასრულეთ ერთი რეალური ოპერაცია. შემდეგ სცადეთ ანგარიში, რომელსაც ეს ოპერაცია არ უნდა ჰქონდეს, და დაადასტურეთ, რომ უარს ეუბნებიან. შემდეგ სცადეთ VPN-ის გარეთ მოწყობილობიდან და დაადასტურეთ, რომ აპლიკაცია მიუწვდომელია.
გაიმეორეთ ყოველი შენახული ინტეგრაციისთვის და წაიკითხეთ მომწოდებლის მიწოდების ჟურნალი იმის ნაცვლად, რომ ჩათვალოთ თქვენი საკუთარი სატესტო ხელსაწყოს 200 იგივე. წარმატებული VPN შესვლა არც ერთი ამ შედეგის მტკიცებულება არ არის.
ნაბიჯი 6: ივარჯიშეთ ცუდი დღე
გადაწყვიტეთ, რა ხდება გვირაბის შეფერხების დროს: სამუშაო ჩერდება, თუ სხვა დამტკიცებული წვდომის მეთოდი იღებს სადავეებს. რაც არ უნდა აირჩიოთ, ჩაწერეთ და ერთხელ გამოსცადეთ, რადგან საგანგებო საჯარო ხელახლა გახსნას, როგორც არადოკუმენტირებულ აღდგენის მექანიზმს, საბოლოოდ ზეწოლის ქვეშ მყოფი ვინმე შეასრულებს.
შეინახეთ აღდგენის წვდომა კარიბჭისა და აპლიკაციის შემნარჩუნებელი ადმინისტრატორებისთვის, მფლობელით და წაშლის თარიღით. ჩაწერეთ ცვლილება და მისი უკუქცევის პირობები იმავე ადგილას, რათა წარუმატებელმა მიგრაციამ არ ჩაკეტოს ის ადამიანები, ვინც მას გამოასწორებდა.
გადასვლის შემდეგ პაჩინგი, ანგარიშების სასიცოცხლო ციკლი, აპლიკაციის ავტორიზაცია და აუდიტი კვლავ თქვენია. გვირაბმა შესასვლელი შევიწროა; მან არც ერთი ამ ამოცანა არ აიღო.