גישה של שותף ל-HSM דרך VPN: הגדירו את פעולות המפתח

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

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

נגישות, זהות ומדיניות מפתח הם שלושה שערים

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

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

שער ראשון: נתיב הרשת שניתן לשותף

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

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

שער שני: מה באמת מאמת את עצמו מול ה-HSM

זהות VPN וזהות HSM הן אובייקטים נפרדים אלא אם אינטגרציה נתמכת מחברת ביניהם במכוון. עם לקוח PKCS#11, היישום מבצע התחברות מול סלוט עם אישור המאוחסן במקום כלשהו במארח של השותף, וההתחברות הזו היא מה שה-HSM מעריך.

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

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

שער שלישי: איזה מפתח, ואיזו פעולה

חתימה, פענוח, יצירת מפתחות, עטיפת מפתחות וניהול משתמשים הם הרשאות נפרדות וחייבות להירשם בנפרד. במונחי PKCS#11, מאפיינים כמו CKA_SENSITIVE ו-CKA_EXTRACTABLE מתארים אם חומר המפתח יכול לצאת מהמודול בצורה שמישה, והם נקבעים לכל מפתח ולא לכל התקן. קראו את המדיניות בפועל על המפתח במקום להסיק אי-ייצוא מהמילה חומרה או מקיומה של מנהרה.

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

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

סירובים הם חלק ממבחן הקבלה

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

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

לחיצת יד VPN שהושלמה שייכת לאותו תיעוד. היא אינה יכולה לעמוד במקום תוצאה אחת ספציפית ל-HSM.