דילוג לתוכן

אבטחה

אבטחה שמרגישה כמו הכנסת אורחים.

ספק זהויות טוב רק כמו הקירות שבין הדיירים שלו והזהירות שבה הוא מטפל בסודות. כך Usher Identity בנוי. אנחנו מתארים מה התוכנה עושה, ולא טוענים לשום הסמכה.

ארכיטקטורה

דומיינים נפרדים, רשתות נפרדות.

הדפים של Usher Identity עצמו והמנפיק של כל לקוח נמצאים בדומיינים רשומים שונים. מסדי הנתונים יושבים ברשת שאין לה גישה לאינטרנט, והדרך היחידה החוצה היא פרוקסי שבודק לאן הוא הולך.

  • Caddy מסיים את ה-TLS לכל מארח, ומסיר כותרות שרק השירותים של Usher Identity עצמו רשאים להגדיר.
  • שכבת האימות עונה לכל הסביבות, ומבחינה ביניהן לפי המארח; שום דבר לא נשמר במטמון עבור מארח אחד ומוגש לאחר.
  • כל שירות מדבר עם Valkey כמשתמש משלו, ומוגבל למפתחות שלו. אין משתמש ברירת מחדל.
  • פקודות שמכילות אסימונים וקודים אף פעם לא נכתבות ליומן של מסד הנתונים יחד עם הערכים שלהן.

האינטרנט

אנשים, האפליקציות שלך, השרתים שלך

הקצה

Caddy: TLS ו-HSTS, הסרת כותרות פנימיות

usheridentity.com

האתר ו-Console

usheridentity.com, console.usheridentity.com

API

api.usheridentity.com

*.usherid.com

שכבת האימות

המנפיק וה-Lobby של כל סביבה

רשת הנתונים · אין נתיב החוצה

Postgres

סכמה לכל סביבה

Valkey

כל שירות מוגבל למפתחות שלו

הדרך היחידה החוצה

פרוקסי יציאה

לכל כתובת URL שלקוח סיפק

גילוי, JWKS, התנתקות

כתובות ציבוריות בלבד

השכבות של Usher Identity. דומיין הדיירים הוא דומיין רשום שונה מזה של הפלטפורמה, כך שהדפים של דייר אף פעם לא נמצאים באותו אתר (same-site) כמו Console.

בידוד

שום דבר משמעותי לא משותף.

כל סביבת פרויקט מקבלת סכמת Postgres משלה, מפתחות חתימה משלה וסודות משלה, מוצפנים במפתח הנתונים שלה. המנפיק שלה הוא מארח בדומיין הדיירים, וקובצי ה-Cookie שלה הם של מארח בלבד, כך שדפדפן אף פעם לא שולח קובץ Cookie של סביבה אחת לסביבה אחרת.

usheridentity.com

האתר, Usher Identity Console, חשבונות Usher Identity

*.usherid.com

מנפיק אחד לכל סביבה, בדומיין נפרד

סביבה

משתמשים, סשנים ואסימונים נמצאים בסכמה שנוצרה עבור הסביבה הזו. השאילתות רצות מול הסכמה הזו, ואף פעם לא מול טבלה משותפת עם עמודת דייר.

להעתיק את סוד הלקוח המוצפן של Google מסביבת הייצור של Acme אל סביבת הייצור של Northwind.

הצפנה במנוחה

הצפנת מעטפה, קשורה למקומה.

סודות שנותנים ל-Usher Identity מוצפנים ב-AES-256-GCM תחת מפתח נתונים ששייך לסביבה אחת. מפתחות הנתונים עצמם עטופים במפתח ראשי עם גרסאות, שמוחזק מחוץ למסד הנתונים.

מפתחות נתונים לכל סביבה
פריצה למפתח הנתונים של סביבה אחת לא חושפת שום דבר על סביבה אחרת.
קשירת AAD
הסביבה והייעוד קשורים לכל טקסט מוצפן, כך שאי אפשר להעביר ערך בין שורות או בין דיירים.
מפתחות עם גרסאות
כל ערך מוצפן שומר את גרסת המפתח שבה נוצר, כך שאפשר להחליף מפתחות ולעטוף מחדש ערכים ישנים.
מאומת
התג של GCM מבטיח שערך ששונה לא ייפתח, במקום להיפענח למשהו אחר.
  1. מפתח ראשי

    מוחזק מחוץ למסד הנתונים, עם גרסאות

  2. מפתח נתונים, אחד לכל סביבה

    עטוף במפתח הראשי

  3. הסוד

    מוצפן ב-AES-256-GCM תחת מפתח הנתונים

u1.<key version>.<iv>.<ciphertext + tag>

aad = u1 | version | environment | purpose

ערך מוצפן מציין את הסביבה ואת הייעוד שלו בנתונים המאומתים. אם מעתיקים אותו לכל מקום אחר, אי אפשר לפתוח אותו.

נהלים

הפרטים, בתשומת לב.

  • סיסמאות, אם משתמשים בהן

    מגובבות עם Argon2id בעלות ש-OWASP ממליץ עליה, 19 MiB ושני מעברים, עם הגבלה על מספר הגיבובים שרצים במקביל, כך שהצפה של ניסיונות התחברות לא תוכל להפיל את השירות. סיסמאות חדשות נבדקות מול דליפות ידועות דרך ממשק הטווחים של Have I Been Pwned, שרואה רק קידומת קצרה של הגיבוב של הסיסמה. האורך המינימלי הוא 12 כברירת מחדל.

  • לא נשמר שום דבר שאפשר להשתמש בו שוב

    סודות לקוח, אסימונים, אסימוני קישורי קסם וקודים שנשלחו בדוא״ל נשמרים מגובבים. קודי הגיבוי מוצפנים. קוד הרשאה תקף לחמש דקות; קוד בדוא״ל מאפשר שלושה ניסיונות.

  • הגבלת קצב בכל דלת

    להתחברות, להרשמה, לקודים בדוא״ל, לקישורי קסם, לאיפוס סיסמאות ולבדיקות של גורם שני יש הגבלה נפרדת לכל אחד: למשל, עשר התחברויות עם סיסמה בדקה, וחמישה קודים בדוא״ל בכל עשר דקות.

  • מדיניות Content-Security-Policy מחמירה

    כל דף של ה-Lobby מקבל nonce חדש ומדיניות שבנויה סביבו: רק סקריפטים מהמקור הזה שנושאים את ה-nonce רצים, טפסים נשלחים רק לאותו מקור, ואתרים אחרים לא יכולים להציג את הדף בתוך מסגרת.

  • יומן ביקורת שאפשר לסמוך עליו

    שינויים במרחבי עבודה, בפרויקטים ובסביבות נכתבים ליומן שאפשר רק להוסיף לו, וכל רשומה קשורה לקודמתה בשרשרת גיבובים, כך שרשומה שנערכה או נמחקה בולטת מיד.

  • פרוקסי יציאה לכתובות של לקוחות

    כל בקשה ש-Usher Identity שולח לכתובת שלקוח נתן לו (גילוי OIDC, JWKS, התנתקות בערוץ אחורי) יוצאת דרך פרוקסי אחד. הוא מתרגם את השם לכתובת פעם אחת, מסרב לכתובות פרטיות, loopback, link-local וכתובות של שירותי מטא-דאטה בענן, ומתחבר לכתובת שבדק, כך ש-DNS rebinding לא יכול להפוך כתובת של לקוח לכתובת פנימית.

  • כינויים שלא ניתנים פעמיים

    הכינוי של סביבת ייצור הוא התווית הראשונה של המנפיק שלה. הגישה ל-Console היא בהזמנה בלבד, Lobby שדווח עליו כפישינג מושעה, וכינוי שכבר היה בשימוש לא ניתן שוב לעולם, כי ייתכן שאפליקציות ישנות עדיין סומכות על האסימונים שלו.

  • סשנים שמסתיימים כשמחליטים

    Usher Identity בודק את הסשנים שלו בכל בקשה במקום לסמוך על עותק שמור במטמון, כך שסשן שסיימת נגמר מיד. אסימוני גישה תקפים לזמן קצר (עשר דקות כברירת מחדל), וה-API שלך יכול לבדוק אותם (introspection).

גילוי אחראי

מצאת משהו? נשמח לשמוע ראשונים.

אם נראה לך שמצאת בעיית אבטחה ב-Usher Identity, נשמח לשמוע עליה, ונעבוד איתך כדי לתקן אותה.

security@usheridentity.com
  • מה מצאת, איפה, ואיך לשחזר את זה.
  • מה מישהו יכול לעשות עם זה, לפי ההבנה שלך.
  • איך אפשר ליצור איתך קשר, והאם לציין את שמך בתודות.

נבקש לבדוק רק מול סביבות בבעלותך, לא לגשת לנתונים של אנשים אחרים, ולתת לנו זמן סביר לתקן את הבעיה לפני שמשתפים אותה. לדיווח על דף שמתחזה להתחברות של Usher Identity, אפשר לעבור אל דיווח על שימוש לרעה.