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

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

למה התפקיד קיים בכלל

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

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

מודלינג איומים: הליבה המעשית

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

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

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

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

ארכיטקטורות ייחוס ותקנים

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

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

תכנון זהות והרשאות

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

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

העיקרון שמנחה את כל הטבלה הוא צמצום האמון המובלע: הנחה שרשת פנימית אינה בטוחה מעצם היותה פנימית. הרעיון הזה מפורט במה זה Zero Trust.

תנוחת אבטחה בענן

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

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

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

מה נדרש כדי להיכנס

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

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

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

הערכת שוק לשכר

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

רמה	הקשר טיפוסי	הערכת שוק - ₪ ברוטו לחודש
ארכיטקט/ית אבטחה בתחילת הדרך	מוצר או תחום אחד	36,000-46,000 (הערכת שוק)
ארכיטקט/ית מנוסה	ארגון בינוני	46,000-60,000 (הערכת שוק)
ארכיטקט/ית ראשי	ארגון גדול או פיננסי	58,000-78,000 (הערכת שוק)

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

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

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

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

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

מה פתוח בלוח

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

שאלות נפוצות

מה ההבדל בין ארכיטקט אבטחה למהנדס אבטחה?

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

האם צריך רקע בפיתוח?

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

כמה זה תפקיד טכני ביחס לניהולי?

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

האם התקנים הם עיקר העבודה?

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

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

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

איך נמדדת הצלחה בתפקיד?

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

האם בודק חדירות יכול לעבור לתפקיד?

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

כמה מהעבודה היא ישיבות?

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