הגדרת Keychain לאחסון מאובטח של נתונים ב-iOS

iOS Keychain: היכן האפליקציה מאבדת נתונים והרשאות

הכשל הנפוץ ביותר — טוקנים וסיסמאות מאוחסנים ב-UserDefaults או ב-plist בתוך ה-sandbox של האפליקציה.

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

הכשל הטיפוסי השני — מחלקת נגישות שגויה של רשומה ב-iOS Keychain. כברירת מחדל הפריט נקרא לאחר הפתיחה הראשונה ונשאר נגיש כל עוד המכשיר דלוק — זה מספיק כדי שתהליכי רקע והרחבות יוציאו את הטוקן.

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

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

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

מה נותנת הגדרה נכונה של אחסון מאובטח

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

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

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

זה מסיר סוג שלם של כשלים — "נתונים אינם נקראים לאחר התקנה מחדש", כאשר האפליקציה פועלת формально, אך מאבדת את כל מה שהיה אמור לשרוד התקנה מחדש.

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

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

מצבי גישה לאחסון: השוואת אפשרויות

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

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

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

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

שלבי הטמעת אחסון מאובטח

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

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

1. ביקורת אחסון. אוספים מפה מלאה של הנתונים: אילו ערכים נכתבים, היכן, מי קורא אותם ומה קורה בעת יציאה מהחשבון. התוצר — רשימת רשומות עם סימון "מועבר לאחסון / נמחק / נשאר כפי שהוא".
2. סכמת מפתחות. מתכננים את מבנה הרשומות: מפתח נפרד לכל סוג נתונים, קידומת אחידה לרשומות שירות, מאפייני זמינות מפורשים — מתי רשומה צריכה להיקרא רק במכשיר לא נעול, ומתי לשרוד אתחול.
3. הגדרת קבוצות גישה. אם באקוסיסטם יש כמה אפליקציות או הרחבות, מקשרים אותן לקבוצה משותפת, כך שהחלפת אסימונים תתבצע ללא כפילות וללא יציאה מגבולות ה-sandbox.
4. העברת נתונים קיימים. מעבירים ערכים שנצברו מהאחסון הישן לחדש בכתיבה חד-פעמית בהפעלה הראשונה, עם בדיקת שלמות וחזרה לאחור אם הכתיבה לא אושרה.
5. בדיקת תרחישים. מריצים את ההתנהגות בעת נעילת מסך, עדכון האפליקציה, שחזור מגיבוי והחלפת סיסמת המכשיר — דווקא כאן צצות שגיאות גישה.
6. טיפול בשגיאות ובכשלים. מגדירים מה עושה האפליקציה אם הרשומה אינה זמינה: לא קורסת, אלא מבקשת התחברות מחדש באופן תקין.
7. מסירת תיעוד. מוסרים את סכמת המפתחות, כללי הרוטציה והנחיות להוספת רשומות חדשות — כדי שהצוות לא יחזור לנתח הכול מחדש.

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

מה הלקוח מקבל לידיו לאחר העבודה

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

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

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

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

הלקוח — שירות משלוחים עם אפליקציה ב-iOS, קהל פעיל, גרסאות כל שבועיים. לאחר עדכון שגרתי החלו תלונות: חלק מהמשתמשים איבדו את ההרשאה בעת הפתיחה, חלק — את הסל והכתובות. תוך שבוע הגיעו 340 פניות לתמיכה, ושיעור כשלי קריאת הנתונים השמורים בגרסאות החדשות עמד על כ-6% מהבסיס הפעיל.

מה היה

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

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

מה שינו

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

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

מה התוצאה

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

במה שונה Keychain מקובץ מקומי וסנכרון ענן?

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

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

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

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

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

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

שורה תחתונה: קובץ מקומי הוא נתונים שקל לאבד בהתקנה מחדש וקל להוציא יחד עם עותק; הענן הוא סנכרון נוח, אך עם מעגל אמון חיצוני; Keychain הוא מאגר מבוקר, שבו הגישה, ההעברה והשחזור מוגדרים באמצעות מדיניות ברמת כל רשומה.

ספקות טכניים לפני תחילת העבודה

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

מה יקרה לנתונים שכבר נשמרו?

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

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

האם זה עובד באופן זהה בגרסאות שונות של המערכת?

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

האם ניתן לחזור אחורה אם משהו ישתבש?

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

אילו סיכונים אתם רואים כבר בהתחלה?

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

נדון במשימה שלך להגנת נתונים

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

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

מה לשלוח להערכה מהירה: תיאור הסכימה הנוכחית של האחסון, רשימת תרחישי העבודה עם הנתונים ודרישות האבטחה. תאר את המשימה — נחזור עם הערכה ותוכנית.