הגדרת AWS CloudTrail לביקורת ואבטחה מקצה לקצה

הגדרת CloudTrail: מה נשבר בלי ביקורת פעולות בחשבון

CloudTrail מופעל כברירת מחדל כמעט בכל חשבון, ובדיוק משום כך ביקורת פעולות בחשבון נחשבת לעתים קרובות למשימה פתורה. בפועל «יומן האירועים» בקונסולה שומר רק אירועי ניהול מ־90 הימים האחרונים ורק באזור הנוכחי.

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

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

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

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

יש לקשר את רשומות CloudTrail ליומני רשת וליומני מאזן העומס, אחרת תמונת התקרית מתפרקת לקטעים לא קשורים.

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

מה נותנת ביקורת בנויה היטב: זמן הניתוח, זמן ההשבתה, סוגי הכשלים

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

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

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

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

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

מצבי איסוף אירועים: יומן אחיד, ריבוי חשבונות, אזורים

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

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

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

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

סדר ההטמעה: מניתוח היומנים הקיימים ועד מסירת הנהלים

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

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

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

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

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

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

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

בסיום — יומן שלם וצוות שיודע לעבוד איתו.

הגדרת CloudTrail: ארטיפקטים ומדיניות גישה בסיום

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

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

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

מקרה בוחן: ביקורת חשבון עם תפקידים וגישות בלתי ניתנים למעקב

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

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

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

מה עשינו

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

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

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

מדדים לפני ואחרי

שלמות האירועים בפעולות הניהול עלתה מ-58% ל-100%. זמן ניתוח התקרית התקצר משני-שלושה ימים ל-40 דקות: השרשרת בכל החשבונות נאספת בשאילתה אחת. ביקורת התפקידים הניבה 470 רשומות, מהן 70 שאינן בשימוש ו-34 עם הרשאות עודפות — את העודפות ביטלנו. גם סוג הכשלים השתנה: במקום «לוגים לא נמצאו» הניתוח נתקל באירוע מסוים ובהקשרו.

מה עושים אם חלק מהפעולות כבר נכתבות ליומן הישן?

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

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

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

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

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

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

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

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

מה יקרה לנפח האחסון כעבור שנה?

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

כמה מהר האירועים מתאימים לניתוח?

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

מה אם הקולט אינו זמין?

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

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

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

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

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