מדוע הגדרת HSM נתקעת באינטגרציה
מפתחות חתימה בפרויקטי בלוקצ'יין כמעט תמיד מתחילים באותו אופן: יוצרים אותם בסקריפט, שמים בקובץ לצד האפליקציה ומוסרים לשירות שמנפיק עסקאות. כל עוד שירות אחד חותם, התצורה נראית עובדת.
ברגע שארנקים, נודה, גשר ותשלומים פנימיים מתחילים לחתום, לכל אחד יש עותק משלו של המפתח, קובץ סיסמה משלו וגרסה משלו של הסביבה ה"נכונה".
אחר כך נשברת האבטחה. אחסון מפתחות במערכת קבצים פירושו שגישה למפתח הפרטי שווה לגישה לשרת: כל מי שקורא את תיקיית הבנייה או נכנס לקונטיינר נושא עמו את היכולת לחתום. מהנדס התחלף, קבלן עזב, גיבוי דלף — יש לבצע רוטציה של המפתח יחד עם הגירת כתובות ועסקאות תקועות.
לא פחות סובל מכך הייצור. פעולות ידניות עם מפתחות — הרצת סקריפט, הקלדת ביטוי סיסמה, אישור ידני — תולות את השחרור באדם: פריסת לילה ממתינה לתורן, וחתימה על אצוות עסקאות הופכת לנוהל מתואם נפרד.
HSM הופך את התמונה: המפתח נוצר בתוך המודול ופיזית אינו עוזב אותו, האפליקציה שולחת לחתימה רק נתונים, החוצה מוחזרת התוצאה, וההגנה על תשתית המפתחות מפסיקה להישען על המשמעת של הצוות ומאושרת ביומן פניות.
בדיוק במעבר למודל הזה הגדרת HSM נתקעת: יש להפריד את קוד החתימה מחומר המפתח, לפצל תפקידים, לשכתב קריאות ולהסכים על נוהל רוטציה. אנחנו מפרקים כיצד זה נסגר.
אפקט ההטמעה: עמידות לתקלות ושליטה במפתחות
כל עוד מפתחות פרטיים מונחים בקבצים במארח או במשתני סביבה לצד השירות החותם, יש לנו סוג כשל אחד במחיר מקסימלי: גישה לשרת משמעה עותק של המפתח, חתימה על עסקאות בשם השירות והחלפה מלאה של תשתית המפתחות.
הסוג השני — תפעולי: רוטציה, שחרור נעילה לאחר הפעלה מחדש, בדיקת גיבויים נעשים ביד, וכל פעולה כזו פותחת חלון לטעות.
מודול אבטחה חומרתי מסיר את שניהם. המפתח נוצר בתוך ההתקן ואינו מיוצא לא דרך ממשק ניהולי ולא דרך ממשק קריפטוגרפי: השירות שולח נתונים ומקבל חתימה, ורק רשומת יומן נכנסת פנימה. תאימות ל-FIPS 140 משמעה שחומר המפתח נמחק בניסיון לפתוח את המארז.
עמידות החתימה לתקלות נשענת על יתירות מודולים: ההתקנים מאוחדים לקבוצה, המפתח נשמר בכל אחד מהם בשליטת קוורום, וכשל של אחד מהם אינו עוצר את זרימת העסקאות. השחזור — החלפת התקן והרכבה מחדש של עותק המפתח לפי שיטת שיתוף סוד בין מחזיקים. זמן ההשבתה מצטמצם משעות של תיאומים למחזור אחד של עבודות נוהל.
ביקורת פעולות עם מפתחות מפסיקה להיות איסוף לוגים ממערכות שונות: המודול מנהל יומן בלתי ניתן לשינוי של יצירות, רוטציות והחלפות מדיניות. חשיפת מפתחות עוברת מתרחיש "מנפיקים מחדש הכול" לנוהל מבוקר עם גבול זמן מדויק.
דרכי חיבור HSM: התאמה לצרכים שלכם
הבחירה בתצורת מיקום המודול אינה עניין של טעם: היא קובעת מי מחזיק פיזית בחומר המפתח, איזו השהיה נוצרת בדרך החתימה ומה יקרה בכשל של אתר. מודול מקומי, מתאר שכור אצל ספק ותצורה היברידית מכסים פרופילי סיכון שונים ועוברים ביקורת בדרכים שונות.
השוואת הגישות מצטמצמת לשלוש שאלות: היכן נמצא מפתח השורש, למי יש גישה פיזית לאזור האבטחה, וכיצד משחזרים גישה לאחר אובדן אתר. התשובות לכך מרוכזות בטבלה.
תצורת מיקום המודול
| תצורה | מתי מתאימה | מגבלות |
|---|---|---|
| מודול מקומי במתאר שלכם | נדרשת שליטה מלאה במפתחות; החתימה מתבצעת באתר אחד, חשובה השהיה | נדרשים חדרים עם גישה מוגבלת, תכנית הפרדת תפקידים, תכנית החלפה בכשל ונוהל עדכון |
| מודול בענן אצל ספק | אין אתר משלכם, פעולות חתימה נדירות, נדרש התחלה מהירה | המפתחות אצל צד שלישי, תלות בערוץ תקשורת, חלק מדרישות הביקורת לא ניתן לסגור |
| תצורה היברידית | שורש האמון נשאר מקומית, מפתחות תפעוליים — במתאר שכור; נדרש גיבוי למקרה אובדן אתר | שתי מודלים של גישה בנוהל אחד, רוטציה מסונכרנת של מפתחות, בקרה נפרדת של הפרדת תפקידים |
מעבר בין תצורות אינו מחייב הנפקה מחדש של מפתחות, אם המודול תומך בממשק תקני לגישה אליהם. לכן אפשר להתחיל מתצורה של מתאר שכור ובהמשך להעביר את שורש האמון למקום מקומי — בלי לעצור את חתימת העסקאות.
שלבי הטמעת המודול: מביקורת עד מסירה
סדר העבודות נקבע לפני ההתחלה: שינוי סדר השלבים לאחר הפריסה משמעו טקס מפתחות חוזר וחלקים חדשים אצל האחראים. כל שלב נסגר בתוצר שהלקוח מקבל.
סדר העבודות
- ביקורת תשתית המפתחות. עורכים ספירת מלאי של מפתחות וחותמים: היכן הם נשמרים כעת, למי יש גישה, אילו פעולות קריטיות, מה דורש המבקר.
- תכנון תצורת החיבור. מספר המודולים והאתרים, מדיניות גישה בקוורום, תפקידי מפעילים, בידוד רשת והחלפה מתוכננת של חלקים.
- טקס מפתחות. המפתחות נוצרים בתוך המודול ומתפצלים לחלקים; החלק הפרטי אינו עוזב את ההיקף המוגן.
- פריסה ואינטגרציה. מחברים שירותי חתימה וצמתי רשת דרך ספק קריפטוגרפי תקני, מתארים התנהגות בעת אי-זמינות המודול.
- בדיקת שחזור. מרימים תצורה מגיבויים במתקן נפרד, מדמים כשל ומודדים זמן חזרה לפעולה.
- בדיקת עמידות לתקלות. מעבירים עומס למודול הגיבוי, בודקים תיעוד יומן של פעולות והפעלת התראות למשמרת התורנית.
- מסירה לתפעול. מוסרים תצורה, מדיניות גישה, נוהל טקס והנחיות למשמרת התורנית, ומבצעים הדרכה.
סט תיעוד ותרשימי תשתית המפתחות
עם סיום העבודות נשאר אצל הלקוח לא רק מודול עובד, אלא סט מלא של תוצרים שלפיו הצוות שלו יוכל לנהל מפתחות בלי לפנות אלינו. כל מסמך מתאר את מצבו בפועל של המתקן — פרמטרים מעודכנים של מדיניות, תפקידים אמיתיים ונהלים מאומתים, ולא תבנית גנרית.
- תיעוד מפתחות: מרשם עם מזהים, ייעוד, שיוך לכתובות בלוקצ'יין ורמת ההגנה של כל מפתח, כולל מפת התאמה "מפתח — שירות — אחראי".
- מדיניות גישה: מטריצת תפקידים עם קוורום חתימות לפעולות קריטיות, הפרדת תפקידים בין מנהל למפעיל, כללי גישת חירום עם רישום חובה ביומן הביקורת.
- נוהל רוטציה: תדירות ההחלפה המתוכננת ותנאים להחלפה לא מתוכננת, סדר הוצאת חומר מפתח ישן משימוש, בדיקת חתימה חובה במתאר בדיקה לפני מעבר לייצור.
- תרשים גיבוי: טופולוגיית המודול הראשי והגיבוי, מקומות אחסון העותקים, סדר השחזור לאחר כשל ונקודות ביקורת שבהן מאומתת השלמות.
- הנחיות תפעול: אותות אופייניים לתקלות, קריטריונים לירידת ביצועים, סדר פעולות למהנדס התורן וגבולות שמעבר להם התערבות מחייבת תיאום.
- העברת ידע לצוות: ניתוח התצורה במתקן חי, תרגול תרחישי רוטציה ושחזור במתאר הדרכה, ומפגש נפרד למצבים לא שגרתיים.
המסמכים נשמרים במערכת בקרת גרסאות לצד התצורה: בעת שינוי מדיניות או חיבור שירות חדש, העריכות נכנסות לאותו סט, ולכן הנהלים אינם סוטים מהמצב בפועל של התשתית.
מקרה בוחן: כיצד הסרנו פעולות ידניות עם מפתחות חתימה
לפני: החתימה נשענה על מהנדס תורן
הלקוח — ספק שירותי תשלום עם זרימת עסקאות מסביב לשעון. מפתחות החתימה נשמרו במארח מבודד, וכל אצווה נחתמה בידי מהנדס תורן: הוציא אמצעי אחסון, אישר את הפעולה לפי הנוהל, והחזיר אותו. חתימה אחת ארכה 30–40 דקות, ותור העסקאות המתין כל אותו הזמן.
פעולה ידנית יצרה שני סוגי כשל. אנושי — משמרת שנשכחה, אמצעי אחסון שהוחלף בטעות, תקלה בסדר הפעולות: החתימה לא עברה, והשירות נפל ל-2–4 שעות. פרוצדורלי — בזמן שהמפתח הוצא, הוא התקיים מחוץ למתאר המוגן. ברבעון הצטברו 3–4 אירועים עם השבתה ובירור.
אחרי: המפתחות נשארים במודול, החתימה — קריאה לממשק
פרסנו מודול אבטחה חומרתי והעברנו את החתימה לקריאה תוכנתית. המפתח נוצר בתוך המודול ואינו עוזב אותו — החוצה יוצאת רק תוצאת החתימה. הגישה מחולקת לפי תפקידים ותצורת k-of-n: מפעיל אחד מפעיל, השני מאשר; הרוטציה מתבצעת לפי לוח זמנים, בלי לעצור את השירות, וכל קריאה נרשמת ביומן עם היוזם.
מדדים: חתימת אצווה — שניות במקום עשרות דקות, פעולות ידניות — אפס, התורים לחתימה נעלמו. בתקופת התצפית לא נרשמה אף השבתה עקב חתימה; סוגי "משמרת שנשכחה" ו"אמצעי אחסון לא נכון" נשללו ארכיטקטונית, ולא באמצעות נוהל. חזרה למפתח הקודם נבדקה במתקן — דקות.
במה שונה ארנק תוכנה ממודול חומרה?
ארנק תוכנה הוא מכיל מוצפן עם מפתח פרטי בדיסק השרת או במאגר סודות. המפתח מפוענח לזיכרון התהליך, וברגע החתימה יכול לקרוא אותו כל מי שיש לו גישה לתהליך הזה, לדאמפ זיכרון או לגיבוי. ההבדל בין הגישות בדיוק כאן: היכן פיזית נמצא המפתח והאם הוא עוזב את המאגר שלו אפילו לרגע.
מודול חומרה (HSM) בנוי הפוך: המפתח נוצר בתוך מתאר מוגן ולעולם אינו עוזב אותו. החוצה מוחזרת רק חתימה מוכנה או תוצאה של פעולה קריפטוגרפית. אפילו גישה מלאה לשרת — עם הרשאות סופר-משתמש, עם עותק דיסק, עם קריאת כל הזיכרון — אינה מאפשרת לחלץ את המפתח הפרטי.
רמות ההגנה נבדלות לא באורך המפתח, אלא במודל האמון. בפתרון תוכנה אלה בידוד תהליכים, הפרדת הרשאות וביקורת חיצונית של פעולות.
במודול — הגנה פיזית על המארז, מחיקת מפתחות בניסיון פריצה, הפרדת תפקידי מפעילים וקוורום: החתימה מורכבת רק לאחר אישור מכמה אחראים, וכל פנייה נכנסת ליומן בלתי ניתן לשינוי.
מתי נדרש מודול: המפתח מנהל הנפקה ותנועת נכסי לקוחות, פעולות אוצר, צומת רשת או ארנק עם כמה חותמים, וכן אם ביקורת ודרישות הרגולטור מחייבות הוכחה שהמפתח לא עזב סביבה מוגנת.
עבור מתארי בדיקה, שירותים פנימיים ומשימות עם מפעיל אחד, בדרך כלל די בבידוד תהליך ובהצפנה — המעבר מוצדק כאשר הסיכון לחשיפת המפתח עולה על מורכבות התפעול.
ספקות טכניים שכדאי להסיר לפני תחילת העבודה
הספקות כאן נוגעים לא למודול עצמו, אלא לחיבור שלו עם מתאר שכבר פועל: מה לעשות עם מפתחות פעילים, האם נדרש מתקן בדיקה נפרד, כיצד לא להישאר עם אדם יחיד בעל גישה מלאה. התאימות לשירותים הקיימים נפתרת בלי לשכתב את הלוגיקה — המודול משתלב בתהליכי החתימה והאימות הקיימים.
מה לעשות עם מפתחות שכבר הונפקו?
אין מנפיקים אותם מחדש באופן עיוור: ההעברה נעשית בצורה מוגנת — במעטפה מוצפנת או דרך שיתוף סוד בין כמה מחזיקים, כל אחד מזין את חלקו בנפרד.
אם ההעברה אינה אפשרית לפי מדיניות, המפתח נשאר פעיל עם תחום שימוש מצומצם, ולצידו מונפק מפתח חדש — עם פרק זמן שבו מערכות חיצוניות מספיקות לעבור בלי להחליף כתובות ומזהים.
האם נדרש מתאר בדיקה נפרד?
כן, והוא נפרס לפני סביבת הייצור, על היררכיית מפתחות משלו וללא גישה למפתחות העבודה. במתקן מריצים טקסים, נוהל שחזור והתנהגות המערכת בכשל של מודול אחד — כולל תרחיש שבו הוא לא עולה כלל. תרגולים ששוברים את המתקן אינם יוצרים סיכון במתאר העבודה.
כיצד להפריד גישות?
התפקידים מתחלקים לפחות לשלושה: מנהל מגדיר את המודול, אך אינו חותם; מפעיל חותם, אך אינו משנה מדיניות; מבקר רק קורא את יומן הפעולות. פעולות קריטיות — החלפת מדיניות, חילוץ מפתח, שינוי קוורום — דורשות אישור בו-זמני מכמה מחזיקים ואינן מבוצעות בידי אדם אחד לבדו.
מה אם המודול יכשל?
מודול גיבוי עם מדיניות זהה ועותקי מפתחות הנשמרים בנפרד מסירים נקודת כשל יחידה. סדר הזנת חלקי הסוד ובדיקת השלמות מתורגלים מראש, ולכן שחזור הגישה מתבצע לפי נוהל, ולא במצב של בירורים.
נדון במשימה ונחזור עם הערכה ותוכנית
כדי לחזור עם הערכה ותוכנית, ולא עם שאלות הבהרה, די במידע ראשוני קצר: כיצד נשמרים המפתחות כעת, אילו שירותים חותמים על עסקאות ולמי יש גישה אליהם.
מה לשלוח לניתוח:
- תרשים פריסה: היכן צמתי הרשת, היכן המודול, כיצד מופרדים הסגמנטים ומי יוזם את החיבור;
- רשימת השירותים החותמים: צמתים, שירות אחסון נכסים, פריסת חוזים, חתימות לא מקוונות;
- מודל תפקידים: מי יוזם, מי מאשר, האם נדרשת תצורה עם כמה מנהלים;
- דרישות ביקורת: מה נכנס ליומן, מי ומאיזו סיבה משחזר מפתח;
- מצב עמידות לתקלות: מודול אחד או קבוצה, זמן השבתה מותר לחתימה;
- נוהל רוטציה, מגבלות עומס ומשך חיים של מפתחות.
לאחר מכן שלושה שלבים. תחילה ניתוח: משווים את הארכיטקטורה לדרישות ומראים היכן התצורה תסתר מהמציאות. אחר כך הערכת היקף העבודה — הרכב השלבים, מספר האיטרציות, ההחלטות הנדרשות מכם, והסיכונים עם הדרך להסירם.
לאחר מכן — תוכנית הטמעה עם סדר עבודה, נקודות קבלה ונוהל חזרה לאחור, כדי שהשינויים ייכנסו בהדרגה ובלי לעצור את החתימה.
מכם יידרשו גישה למתאר בדיקה, אחראי קריפטוגרפיה וחלון עבודה. דרישות מהקבלן מנוסחות כך: תצורה ניתנת לשחזור, מדיניות מפתחות מתועדת, תרחיש שחזור מאומת והעברת ידע לצוות שלכם.
תארו את המשימה — נחזור עם הערכה ותוכנית הטמעה.