უნდა იყოს თქვენი Vaultwarden-საცავი მხოლოდ VPN-ით ხელმისაწვდომი? სამი პირობა
კერძო საცავი მარშრუტიზაციისა და აღდგენის გადაწყვეტილებაა და არა მხოლოდ firewall-ის წესი. შეამოწმეთ სამი პირობა: წვდომა პირველ დღეს, მხოლოდ-კითხვის ქეში და უკან დაბრუნების გზა.
პირველი შესვლა შემცვლელ ტელეფონზე ის მომენტია, როცა მხოლოდ VPN-ით მომუშავე საცავი თავის ფასს აჩვენებს: აპლიკაციას ქეში არ აქვს, სერვერი გვირაბის უკან დგას და გვირაბის სერტიფიკატები შეიძლება იმ საცავში იყოს, რომელსაც ვერ გახსნით. ეს დიზაინის კითხვაა და არა გათიშვა, და განლაგებამდე პასუხის გაცემა უფრო იაფია, ვიდრე შემდეგ. სამი პირობა წყვეტს, პრაქტიკულია თუ არა კერძო საცავი თქვენი მომხმარებლებისთვის. თუ რომელიმე მათგანი ვერ სრულდება, სწორი პასუხი ჩვეულებრივ უფრო ვიწრო გამოქვეყნებაა და არა VPN კედელი.
პირობა 1: თქვენი მომხმარებლები სერვერს პირველ დღეს აღწევენ
ახალ მოწყობილობას არც ქეში აქვს, არც სესია და არც ნდობა. მას სჭირდება სერვერის ჰოსტის სახელის გადაწყვეტა, იქ მისასვლელი მარშრუტი და უკვე დაყენებული VPN პროფილი მანამ, სანამ მომხმარებელი შესვლას სცდის. თუ ამ სამიდან რომელიმე მხოლოდ პირველი შესვლის შემდეგ მოვა, განლაგება ყველაზე ცუდ მომენტში ჩავარდება. დათვალეთ, რამდენი ნაბიჯი უნდა გაიაროს ახალმა თანამშრომელმა სანამ საკუთარ საცავს გახსნის.
გაყოფილი გვირაბი აქ ხშირად უფრო შესაფერისია: გადაიტანეთ მხოლოდ საცავის ბოლო წერტილი და მისთვის საჭირო DNS გზა, ხოლო მომხმარებლის დარჩენილი ტრაფიკი შეხებით არ შეეხოთ. ეს მარშრუტიზაციის გადაწყვეტილებაა, რომელიც VPN-ის მფლობელთან ერთად მიიღება და არა ვარაუდი, რომ ყველა მობილური კლიენტი ერთსა და იმავე პოლიტიკას იცავს. ორივე მისამართის ოჯახი და სერვისის ჰოსტის სახელი ამ არჩევანს უნდა შეესაბამებოდეს.
თუ მომხმარებლები სერვერს ვერ აღწევენ მანამ, სანამ სამუშაო სერტიფიკატები ექნებათ, ეს პირობა ვერ სრულდება და VPN კედელს არასწორი ფორმა აქვს.
პირობა 2: ქეშირებული წვდომა მხოლოდ-კითხვისაა და ეს საკმარისია
Bitwarden-ის კლიენტებს შეუძლიათ უკვე გახსნილი საცავის ჩვენება სერვერზე მიუღწევლად, და ეს ოფლაინ ასლი მხოლოდ-კითხვისაა. ის სასარგებლოა პაროლის წასაკითხად გათიშვის დროს; ეს არ არის ახალი შესვლა და არ არის რედაქტირება. გადაწყვიტეთ, მისაღებია თუ არა მხოლოდ-კითხვა თქვენი მომხმარებლებისთვის, სანამ მის ირგვლივ დიზაინს შექმნით.
curl -sI https://vault.example.com/alive
openssl s_client -connect vault.example.com:443 -servername vault.example.com </dev/nullჩაკეტვა და გასვლა სხვადასხვა მდგომარეობაა და განსხვავებას აქ მნიშვნელობა აქვს. ჩაკეტილი კლიენტი ლოკალურ საცავს დაშიფრულად ინახავს და შეუძლია ის კვლავ გახსნას მთავარი პაროლით ან ბიომეტრიით; გასვლა შლის ამ ლოკალურ ასლს და სერვერს მოითხოვს. თუ მხარდაჭერის სკრიპტი მომხმარებლებს ეუბნება, გავიდნენ და კვლავ შევიდნენ სინქრონიზაციის პრობლემის გამოსასწორებლად, ის მათ ოფლაინ წვდომასაც ართმევს. შეამოწმეთ დროის ამოწურვის მოქმედება თითოეულ კლიენტზე ნაგულისხმევი მნიშვნელობის დაშვების ნაცვლად.
ქეშირებული ასლი სარეზერვო ასლი არ არის. ის ერთ მოწყობილობაზე ცხოვრობს, ერთი ანგარიშითაა მიბმული და გასვლის ან წაშლისას ქრება.
პირობა 3: აღდგენა თავად საცავში არ გადის
წრიული შემთხვევის შემთხვევით აგება ადვილია: VPN სერტიფიკატი საცავშია შენახული, საცავი VPN-ის უკანაა და ქეშის მქონე ერთადერთი მოწყობილობა დაკარგულია. მაშინ აღდგენა დამოკიდებულია სისტემის გარეთ არსებულ დოკუმენტზე ან ადამიანზე. ჩაწერეთ ეს გაშვების გზა და შეამოწმეთ იგი აღდგენადი ანგარიშით, სანამ ვინმეს დასჭირდება. საგანგებო პროცედურა, რომელიც არავის გამოუცდია, მხოლოდ იმედია.
შეამოწმეთ მიმდევრობა კონტროლირებულად: დაადასტურეთ, რომელი არსებული ელემენტი რჩება ოფლაინ წაკითხვადი, შემდეგ აღადგინეთ ქსელური გზა და შეამოწმეთ, რომ ახალი შესვლა და სინქრონიზაცია ორივე მუშაობს. მოერიდეთ ერთადერთი ქეშირებული ასლიდან გასვლას ექსპერიმენტის სახით, თუ უკან დაბრუნების სხვა გზა არ არსებობს. ჩაწერეთ, რაც დააკვირდით, კლიენტის ვერსიის ჩათვლით.
თუ აღდგენა საცავს მოითხოვს, ეს პირობა ვერ სრულდება. გამოსავალი დოკუმენტირებული ზოლგარეთა გზაა და არა უფრო მკაცრი გაფრთხილება გაცნობის დოკუმენტში.
რასაც ნებისმიერ შემთხვევაში ინახავთ: HTTPS, სარეზერვო ასლები და განახლებები
HTTPS თავის ადგილზე რჩება VPN-ის უკანაც. ის ვებ სერვისს აძლევს იდენტობას, რომელიც ბრაუზერს შეუძლია შეამოწმოს, და აპლიკაციის კავშირს დაცულად ინახავს იმის მიუხედავად, სად მთავრდება გვირაბი. კერძო ბოლო წერტილმა მომხმარებლებს არ უნდა ასწავლოს სერტიფიკატის გაფრთხილებების გვერდის ავლა, რადგან ეს ჩვევა მათ საჯარო საიტებზეც მიჰყვება.
სარეზერვო ასლები ხელმისაწვდომობისგან დამოუკიდებელი დისციპლინაა. Vaultwarden თავის მონაცემებს მონაცემთა ბაზაში ინახავს, და სერვისის გაჩერებულ მდგომარეობაში აღებული თანმიმდევრული ასლი, ან მონაცემთა ბაზის დონის სარეზერვო ასლი, უფრო ღირებულია, ვიდრე მუშა პროცესიდან კოპირებული ფაილი. შეინახეთ ასლი საცავის ჰოსტის გარეთ და შეამოწმეთ აღდგენა. ექსპორტირებულ საცავის მასალას იგივე დაცვა სჭირდება, რაც ორიგინალს, რადგან ექსპორტი არ არის დაშიფრული ისე, როგორც სერვერის საცავი.
sqlite3 /data/db.sqlite3 ".backup '/backup/vault-2026-11-03.sqlite3'"
docker compose psშემდეგ შეინახეთ სერვერი და კლიენტები განახლებული. მხოლოდ VPN-ით წვდომა ამცირებს გამოქვეყნებას; ის მოწყვლად იმპლემენტაციას უვნებელს არ ხდის და დაზარალებულ ბოლო წერტილს არ იცავს. სამი პირობა წყვეტს წვდომის მოდელს, ხოლო მოვლა წყვეტს, გადაიტანს თუ არა ეს მოდელი წელს.