קודם מזהים איזה מפתח קיבלתם ומה הוא מאפשר
פתחו את תיעוד הספק ובדקו אם מדובר במזהה ציבורי, מפתח לפרסום, token סודי או אישור בעל הרשאות ניהול. מפתח שמאפשר לקרוא פניות, לשלוח דואר או לשנות רשומות דורש טיפול שונה ממזהה תצוגה. אין לשלוח את הערך עצמו כדי שמישהו יזהה את הסוג; שם המוצר, סוג האישור וההרשאות בדרך כלל מספיקים לתכנון הראשוני.
ערכו רשימת חיבורים לפי משימה: אתר אל CRM, טופס אל מערכת דואר, או שרת אל גיבוי. לכל חיבור רשמו בעלים עסקי, אחראי טכני, סביבת שימוש ופעולה נחוצה. כך אפשר לבקש אישור מצומצם ולא להעתיק מפתח מנהל ראשי לכל תוסף. GitHub מתעד בחירת שיטת אימות והרשאות מתאימה למשימה; האפשרויות המדויקות משתנות בין ספקים.
מפת אחסון: לא כל משתנה סביבה נשאר בשרת
שם כמו ENV אינו מבטיח סודיות. כלי בנייה ומסגרות יכולים לשלב ערכים בפלט ציבורי אם משתמשים במנגנון שמיועד לדפדפן. על האחראי לבדוק את הפלט שנמסר למשתמש, את הגדרות הפריסה ואת גישת התהליך לסוד, בלי להדפיס את הערך ללוג או לדוח.
הטבלה היא כלי תכנון מקורי לאתר עסקי, ולא הגדרת התקנה לכל מערכת. קובץ שמחוץ לתיקייה הציבורית עדיין מצריך הרשאות, הגנת גיבויים ותהליך מסירה. מנהל סודות מתאים כשאפשר לשלבו ולתחזק הרשאות אליו באופן אמין.
| מיקום או שימוש | בדיקה נדרשת | החלטה מעשית |
|---|---|---|
| JavaScript שנשלח לדפדפן | האם הספק מגדיר את הערך כציבורי | לא לשלב סוד שרת בפלט |
| הגדרת שרת או מנהל סודות | מי קורא ומי משנה אותה | לאפשר רק לתהליך ולאחראים הנחוצים |
| תהליך בנייה ופריסה | האם הערך נשמר בקבצים או בלוגים | לבדוק פלט והרשאות מסירה |
| גיבוי או ייצוא הגדרות | מי מורשה לשחזר ולצפות | לכלול את העותק במפת החשיפה |
הפרידו אתר חי, בדיקות וספקים
לכל סביבה צריכים להיות אישורים המתאימים לה ולהיקף הפעולה, ככל שהספק מאפשר. תוסף שנבדק בסביבה נפרדת לא אמור לקבל אוטומטית הרשאת מחיקה במערכת לקוחות אמיתית. גם מפתח לקריאה בלבד יכול לחשוף מידע, ולכן יש לבדוק את סוג הנתונים ולא רק את האפשרות לשנות אותם.
לפני מסירה לספק הגדירו מי מנפיק, היכן מוזן הערך ומתי מסירים גישה. העדיפו חיבור נתמך עם הרשאות מוגדרות על פני שיתוף חשבון של עובד. מגבלות כתובת, API ותקציב תלויות במוצר; ב-Google Cloud יש הנחיות להגבלת מפתחות ולמניעת הכללתם בפרמטר URL. אין להניח שאותה אפשרות קיימת אצל כל ספק.
איך מתכננים החלפה בלי לנתק את העסק
החלפה שגרתית צריכה לכלול זיהוי כל הצרכנים, הנפקת אישור מתאים, עדכון מבוקר ובדיקת פעולה מול הספק. אם הספק מאפשר חפיפה, מתכננים חלון מעבר קצר ומבטלים את הישן לאחר אימות. אם אינו מאפשר חפיפה, מגדירים זמן שינוי, אחראי וסימן ברור לכישלון. אין להבטיח מעבר רציף בלי להבין את המגבלה.
בחשד לחשיפה, רמת הסיכון יכולה לחייב ביטול מיידי גם במחיר הפרעה לשירות. משמרים תיעוד רלוונטי ובוחנים שימוש לא מוכר בהתאם להרשאות המפתח. מחיקה מהקובץ האחרון אינה מוכיחה שהסוד נעלם מהיסטוריה, גיבויים או עותקים. לא מחזירים מפתח שנחשף רק מפני שהמפתח החדש אינו עובד.
דוגמה: טופס חדש משתמש במפתח של מערכת הלקוחות
בתרחיש להמחשה בלבד, ספק מבקש מפתח מלא כדי להעביר פניות מהאתר. בעל העסק מברר אילו שדות נדרשים ואיזו פעולה אמורה להתבצע, ומבקש אישור מצומצם ככל שהמוצר תומך. הבדיקה נעשית עם נתוני ניסיון וללא הודעות ללקוחות אמיתיים. הצלחת שליחת פנייה אחת אינה מאשרת גישה לכל מסד הלקוחות.
אחרי הבדיקה משווים את הרשומה הצפויה לתוצאה בפועל, מאמתים שאין כתיבה כפולה ומסירים את אישור הניסיון לפי התוכנית. אם נדרש מפתח רחב בגלל מגבלת מוצר, מתעדים זאת כהחלטת סיכון לבחינה, ולא מציגים אותה כהרשאה מצומצמת. יש לבדוק גם מי יוכל לתחזק את החיבור לאחר עזיבת הספק.
מה לבקש במסירה ומתי להזמין בדיקה
מסמך המסירה צריך לתאר את סוג האישור, בעליו, תפקידו, הרשאותיו, הסביבה ותהליך החלפה וביטול. מציינים מיקום מנוהל ללא ערך סודי, ואת הראיה לכך שהחיבור עובד. אפשר לצרף מזהה רשומת ניסיון מושחר, זמן בדיקה ותוצאה צפויה, במקום צילום מלא של מסך המפתחות.
אם מפתח סודי הופיע בקוד ציבורי, נשלח לנמען לא מתאים או מאפשר פעולות שלא הוגדרו, צריך בירור חשיפה וטיפול באישור עצמו. תכנון ניהול סודות אינו מחליף בירור אירוע שכבר התרחש. בפנייה ל-CyberFixCrew תארו את הספק ואת החיבור; אל תצרפו מפתחות, סיסמאות או ייצוא לקוחות.
