שרתים וירטואליים ב-AWS: הגדרה מאובטחת של EC2

הגדרת AWS EC2: היכן נשברת האבטחה

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

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

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

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

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

מה נותנת תצורה נכונה של אינסטנסים: אפקט במספרים

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

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

ארכיטקטורת EC2: דרכי פריסה ומצבי גישה

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

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

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

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

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

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

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

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

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

הרכב המסירה מקובע בצ'ק־ליסט, ולפיו גם מתקבלת העבודה:

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

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

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

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

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

מה שינו

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

תוצאות היישום

זמן השיקום הצטמצם מ-40-60 דקות ל-6-8. מספר הפעולות הידניות בשחרור ירד ל-4 במקום 27, חלון הלילה וההשבתה יצאו מהתהליך. במהלך רבעון ליווי — אף כשל בעדכון במקום שבו קודם תועדו בעקביות 2-3 באותה תקופה; את הפרויקט הוביל מהנדס ה-DevOps שלנו.

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

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

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

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

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

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

שאלות טכניות נפוצות ומגבלות אופייניות

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

איך נשמרים מפתחות גישה?

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

האם אפשר לעדכן בלי השבתה?

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

איך השרתים עוברים שיא עומס?

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

למי יש גישה לשרתים ומה נכנס ללוגים?

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

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

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

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