KeyMeld: מפתח משותף ל-iPhone ו-Android ומבנה Zero Vault לפרויקט

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

על iPhone, היישום יכול להגן על המפתח המקומי באמצעות Apple Keychain. ב-Android, נעשה שימוש ב-Android Keystore. הטכנולוגיות האלו מיועדות לשמור מפתחות רגישים בסביבת המכשיר המוגנת, אך הן לא תחליף הן להן.

משתמש רגיל לא מבחין בהבדל: הוא פשוט רוצה לפתוח את היישום ב-iPhone, להניח אותו על Android ולהמשיך לעבוד עם אותם נתונים מוגנים.

עבור המפתחן עולה שאלה ארכיטקטונית: כיצד לאפשר גישה משותפת בשני הפלטפורמות, מבלי להעביר את המפתחות המקומיים של המכשירים או לשמור עותקים שלהם במסד הנתונים של ה-backend עצמו?

כשבדקתי את KeyMeld, ראיתי שהשירות מציע מפתח אוניברסלי נפרד לשם כך, מבלי להתערב בהגנת הפנימית של iOS ו-Android.

מפתח משותף לפלטפורמות שונות

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

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

השירות לא לוקח את המפתח מ-iPhone, לא מעביר אותו ל-Android ולא מנסה להפוך שני מפתחות שונים לאחד. ההגנה של הפלטפורמה נשארת עצמאית, והיישום מקבל רמת גישה משותפת לפרויקט שלו.

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

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

Zero Vault שייך לפרויקט

חשוב להבהיר: Zero Vault לא הוא שם של KeyMeld עצמו. זו מודל ארכיטקטוני שניתן לבנות מתוך השירות החיצוני.

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

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

זהו תוצאת מודל Zero Vault בארכיטקטורה של הפרויקט: שרת ה-backend לא מחזיק מפתח משותף ממרחב מוגן של הלקוח.

Zero Vault אינו אומר ש-Backend של המוצר לא שומר דבר. חשבונות, הגדרות, נתוני עסקיים וכל מה שנדרש להפעלת היישום נשארים על השרת. אך המפתח האוניברסלי אינו קיים לצדם.

פריצה לשרת של המוצר לא תחשוף מפתח אוניברסלי כזה בעצמו: הוא לא נשמר ביחד עם החשבונות או נתונים אחרים בשרת. מודל זה לא מבטיח שכל תקלה תעבור ללא נזק. הוא משרת מטרה ספציפית — להוציא את המפתח האוניברסלי ממאגר היישום של הלקוח.

תרחיש חי: חשבון אחד ב-iPhone ו-Android

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

ב-iPhone, היישום מגן על המפתח המקומי באמצעות כלים של iOS. ב-Android, נעשה שימוש במנגנון ההגנה של Android. המפתחות הפנימיים של המכשירים שונים, וזה נורמלי.

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

אפשר גם היה לבנות תבניות נפרדות ל-iOS ו-Android, לנסות להעביר מפתחות מקומיים ידנית או לשמור עותקים שלהם בשרת.

KeyMeld מאפשר לוותר על העברת המפתחות המקומיים ושמירת עותקים של מפתחות בשרת, תוך הוספת מפתח אוניברסלי משותף.

לקוחות ב-iPhone וב-Android מקבלים גישה לאותו מפתח אוניברסלי במסגרת פרויקט וחשבון מאושרים. כל מכשיר ממשיך להשתמש במנגנונים האישיים שלו להגן על הנתונים.

זה נראה למשתמש כמו חשבון אחד על כל המכשירים. הוא לא חייב לדעת באיזה מנגנון מדובר בתוך ה-iPhone או ה-Android.

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

השרת משתתף באישור הבקשה, אך המפתח האוניברסלי מיועד למשתמש מאושר ואינו נשמר בשרת ה-backend של המוצר.

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

שלושה סוגי מפתחות וסודות נפרדים

כדי לא לבלבל בין חלקי הארכיטקטורה, מספיק להבחין בשלושה מושגים:

• מפתח מקומי של המכשיר שייך למכשיר ספציפי ומנוהל באמצעות הכלים של iOS או Android.

• מפתח אוניברסלי משמש את הלקוחות המאושרים של אותו פרויקט וחשבונות, ומקשר בין הפלטפורמות ברמת המוצר.

• סוד שירותי נחוץ ל-backend לתקשורת מאובטחת עם KeyMeld. הוא לא מועבר ליישום המובייל או לדפדפן.

הסוד השירות ומפתח האוניברסלי משימות שונות. במודל Zero Vault, המפתח האוניברסלי לא נשמר במסד הנתונים של המוצר יחד עם נתוני ה-backend.

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

הגישה למפתח נשארת ניהולית

השגת המפתח האוניברסלי איננה זכות בלתי מוגבלת לכל לקוח.

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

חשוב לא להסיק מסקנות מיידיות וגורפות. זה אינו אומר השמדת עותק מקומי קיים של המפתח. מדובר על שליטה בפסיקת הגישה למפתח והוספת לקוחות חדשים.

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

המפתחת — שאין צורך לבנות את הלוגיקה הזו בנפרד עבור iOS ו-Android. גם המודל הסופי של Zero Vault תלויית באם הפרויקט שומר את המפתח האוניברסלי אצלו ובין ההגנות על התשתית שלו ובסביבת ה-SaaS החיצוני של KeyMeld.

מה KeyMeld לא עושה

KeyMeld איננו מנהל סיסמאות ואינו שומר רשומות TOTP של המשתמש. הוא אינו הופך לבסיס נתונים ענני ליישום ואינו מחליף סנכרון תוכן.

זה לא תחליף ל-Apple Keychain או ל-Android Keystore. השירות משאיר את המנגנונים המקומיים של הפלטפורמה במקומם ומוסיף שכבת עבודה משותפת למוצר.

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

ולבסוף, KeyMeld אינו מחולל Zero Vault אוטומטי. הוא מספק רק פרופיל חיצוני של מפתח אוניברסלי. כדי לשמר את המבנה הזה, על המפתחים לא לשים את המפתח האוניברסלי במסד השרת שלהם. גם אזורים אמינים נפרדים צריכים להישאר מופרדים.

מי עשוי להזדקק לכך

הגישה הזאת מתאימה ליישומים שפועלים על כמה פלטפורמות ומנצלים נתונים מקומיים מוגנים.

ישויות כאלה יכולות להיות אוטנטיקטור, יישומים ארגוניים, מוצרים SaaS, שירותים עם מכשירים מרובים וכל פרויקט שצריך לעבודה אחידה על iPhone ו-Android.

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

לאחר שעיינתי בפרויקט, הייתי מגדיר את KeyMeld ככלי לבניית מודל Zero Vault עבור המוצר שלך, ולא כ-Zero Vault מוכן מראש.

iOS ו-Android משמרות את מנגנוני ההגנה הפנימיים שלהן. הלקוחות מקבלים מפתח אחיד. וה-backend, שאינו שומר את המפתח לעצמו ואינו מחבר בין התשתית הפנימית ל-KeyMeld, לא הופך לתיבת אוצר עם מפתח מונפק לנתוני הלקוח.

זה מושך משתמשים לכניסה אחידה בפלטפורמות שונות. הוא מאפשר למפתח להוציא את המפתח האוניברסלי מחוץ ל-backend שלו. ולפרויקט כולו — את מבנה Zero Vault, שבו השרת אינו מחזיק את המפתח לנתוני הלקוח המוגנים.

למידע נוסף על הפרויקט: KeyMeld