הגדרה מקיפה של הצפנת נתונים לפרויקט קריפטו – פתרון מלא

היכן נשברת הצפנת הנתונים של פרויקט קריפטו בפועל

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

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

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

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

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

בהמשך נפרט כיצד זה נסגר.

מה נותנת הצפנה מנוהלת: זמן, השבתה, מחלקות כשל

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

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

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

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

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

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

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

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

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

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

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

שלבי ההגדרה: מביקורת הסכימה ועד מסירת הנהלים

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

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

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

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

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

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

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

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

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

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

מה השתנה לאחר ההטמעה

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

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

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

מה לעשות אם בפרויקט כבר פרוס ניהול מפתחות משלו?

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

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

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

ספקות טכניים: עומס, רוטציה, ביקורת גישה

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

האם אפשר להטמיע בלי לעצור את המוצר?

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

מי בצוות יש לו גישה למפתחות?

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

מה לעשות עם נתונים שכבר מונחים בגלוי?

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

כיצד לוודא שההצפנה באמת עובדת?

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

נדון במשימה: נראה סכימה ונחזור עם הערכה

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

להתחלה נדרשים נתוני פתיחה על הפרויקט — בדרך כלל די ברשימה כזו:

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

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