תעדו נקודת התחלה וגבול אחריות
רשמו הפצה וגרסה, תפקידים, ספק, זהויות ניהול ותהליכים עסקיים. שרת שמפעיל אתר, מסד, דואר וחיבורים דורש הבנת תלות לפני שינוי. בדקו מי מוסמך לעדכן כל שכבה והאם השירות מנוהל במלואו או רק חלקית. המילה VPS מתארת סוג תשתית, ולא את כל עבודות התחזוקה שנכללות בהסכם.
הכינו גישה חלופית מתאימה ודרך חזרה לשינוי, בהיקף מורשה. גיבוי הגדרות יכול לסייע אך אינו הוכחה שהיישום והנתונים ניתנים לשחזור. אם יש חשד לפגיעה פעילה, לא מתחילים בניקוי תצורה שמוחק ראיות; מגדירים גם מסלול בירור אירוע.
קו בסיס קושר כל בקרה לצורך ולבדיקת קבלה
הטבלה היא מסגרת עבודה מקורית, לא רשימת פקודות לכל הפצת Linux. לכל סעיף מתאימים בדיקה וסמכות. אם אין מידע, מציינים פער ואחראי במקום לקבוע שהגדרת ברירת מחדל מספיקה או להחמיר הכול בו זמנית. קו הבסיס צריך להיות ניתן לתחזוקה.
| תחום | מה צריך לדעת | ראיית קבלה אפשרית |
|---|---|---|
| גרסה ורכיבים | מה נתמך ומאיזה מקור מתעדכן | גרסה ומקור שנבדקו |
| גישה ניהולית | מי מתחבר ואילו סמכויות נדרשות | כניסה מורשית וגבול תפקיד |
| שירותים ורשת | מה חשוף ולמי יש צורך בו | מסלולי גישה תואמים למדיניות |
| סודות וקבצים | מי קורא ומשנה מידע רגיש | הרשאות ותפקוד לאחר שינוי |
| לוגים ותפעול | איזה אירוע נרשם ומי בוחן כשל | מידע תפעולי נגיש למורשים |
| גיבוי והתאוששות | מה מוגן ואיך בודקים שחזור | בדיקת קבלה בסביבה מתאימה |
עדכונים דורשים מדיניות ולא רק מתג אוטומטי
Ubuntu מתעדת מנגנון לעדכונים אוטומטיים ואת מקורות החבילות שבהיקפו. הוספת מאגר אינה בהכרח מוסיפה אותו אוטומטית למנגנון, ועדכון עשוי לדרוש טיפול בהפעלה מחדש. לכן בודקים את התצורה בפועל ואת הרכיבים שאינם מכוסים. הדוגמה היא ל-Ubuntu, ולא קביעה על כל הפצה.
גישה ושירותים נבדקים לאורך המסלול
בדקו גם כלל ספק, חומת אש בשרת, שירות שמאזין ויישום שמקבל פעולה. סגירת גישה בשכבה אחת אינה הוכחה שכל נתיב חלופי נבדק. אם Docker מפרסם שירות, צריך להבין את כללי הרשת שהוא מוסיף ולא להניח שרשימת כללים אחת מתארת את החשיפה כולה.
מדריכי Docker מתארים אינטראקציה בין פרסום שירותים לכללי רשת. גם תהליך ריצה שנראה מבודד יכול להחזיק גישה רחבה לקבצים או למנוע. הקשחת השרת והקשחת הקונטיינר הן משימות קשורות עם היקפים שונים; אין להסיק מהשלמת אחת שהשנייה כבר נעשתה.
דוגמה: עדכון הצליח והחיבור העסקי הפסיק לעבוד
התרחיש להמחשה בלבד. לאחר שינוי שרת האתר עולה, אך תהליך העברת פניות נכשל בגלל תלות שלא מופתה. בדיקת קבלה שכוללת רק דף בית תחמיץ את הבעיה. הצוות בודק את התהליך, מאתר את השינוי ומחליט על תיקון או חזרה מתואמת בלי לבטל את כל ההגנות.
אחרי התיקון בודקים גם שגישה שלא נדרשת נשארה מוגבלת. התוצאה אינה רק זמין או חסום, אלא פעולה עסקית מותרת שעובדת בתוך גבולות שהוגדרו. משתמשים בנתוני ניסיון ובנמענים מאושרים כדי לא ליצור פניות, חיובים או הודעות אמת במהלך הניסוי.
מסרו רשימת שינויים, חריגות ובעלות להמשך
מסירת הקשחה צריכה לציין נכסים, גרסאות, שינויים וראיות בדיקה. לכל חריגה יש נימוק, אחראי ומועד בחינה. עדכנו את המסמך בהוספת שירות או שינוי ספק, כדי שלא יהפוך לתמונה של יום ההקמה בלבד. ציון כלי או מספר אפשרויות שכובו אינם תחליף לכך.
ב-CyberFixCrew אפשר להגדיר סקירת Linux/VPS ושינויים לפי היקף מוסכם. אין הבטחה שהקשחה מסירה כל חולשה או מחליפה תפעול, גיבוי ותגובה. בפנייה ראשונית תארו תפקיד וגרסה אם ידועים, בלי לשלוח מפתחות SSH, סיסמאות או קבצי תצורה עם סודות.
