האם הכספת שלך ב-Vaultwarden צריכה להיות נגישה רק דרך VPN? שלושה תנאים

ההתחברות הראשונה בטלפון חלופי היא הרגע שבו כספת שנגישה רק דרך 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 בלבד מפחיתה חשיפה; היא אינה הופכת מימוש פגיע לבלתי מזיק ואינה מגנה על נקודת קצה שנפרצה. שלושת התנאים קובעים את מודל הגישה, והתחזוקה קובעת אם המודל הזה ישרוד את השנה.