גלישה מאובטחת והפרדה מהאינטרנט

אם בשנה-שנתיים האחרונות המונח התקפות סייבר הפכו לביטוי חביב ע"י עיתונאים (מבלי שהם ואנחנו בטוחים למה הכוונה), הרי שעכשיו ארגונים מתחילים להפנים את הסכנות הנובעות מהתקפות כאלה. אם בעבר היה 'מספיק' שרת AV ומערכת Firewall להגן על הרשת, כיום הארגון נדרש להגן על עצמו מפני התקפות APT. אם בעבר התקינו ביציאה מהרשת, לכיוון האינטרנט, שרת Proxy, היום מבינים שקיימים סיכונים רבים לקישור הרשת הפנימית ישירות לאינטרנט (גם עם פרוקסי).

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

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

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

תיאור קצר של הארכיטקטורה של פתרון הניתוק הלוגי (הגישה השניה) ולאחר מכן שרטוט סכמתי:

רשת טרמינלים

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

חסימת תקשורת

מגדירים ב – Firewall החוצץ בין רשת ה – LAN לבין חוות הטרמינלים חוק המאפשר למשתמשים גישה בפורט ייעודי לשרת הגלישה. מגדירים חוק נוסף (Deny) החוסם כל תקשורת אחרת (כל הפורטים) בין רשת העובדים לבין האינטרנט. הדרך היחידה החוצה לאינטרנט מתבצעת רק משרת הטרמינל.

מיילים

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

חוויית משתמש

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

 השרטוט הבא מציג גרפית את ארכיטקטורת הרשת לגלישה המאובטחה.

 

תרשים סיכונים מערכות/מנגנוני הגנה ומניעה

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

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

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

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

הערות כלליות:

1. בכל סיכון צוינו מערכות בולטות שנותנות מענה טוב לאותו סיכון.
2. לא ציינתי מערכות עבור סיכונים שמקבלים מענה הולם ללא צורך במערכות (למשל הרשאות לתיקיות בשרת הקבצים).
3. לא ציינתי גם מערכות שמספקות מענה מאוד נמוך לסיכון מסוים (למשל Firewall לא באמת ימנע באופן מיטבי גישה לא מורשית למידע בשרת פנים ארגוני בו בזמן ש – NAC לא באמת יכול למנוע זליגת נתונים למרות שהוא מונע חיבור מחשבים לא מורשים לרשת).

 הערות על מערכות:

• DB FW: ניתן להגדיר הרשאות גישה עפ"י יוזר מערכת הפעלה, יוזר בסיס נתונים, כתובת IP, שם מחשב ועוד. יכול לאפשר מניעת גישה לשדות רגישים או ניטורם. מאפשר לנטר ולחסום נסיונות Brute Force.
• DLP: יכול לחסום התקני זכרון נתיקים, למנוע או לנטר שליחה/שמירה של מידע רגיש על סמך ביטויים/תכנים או ספריות ברשת.
• הצפנת כונן קשיח משלב ה – Boot: מונעת אפשרות לאתחל את המחשב באמצעים עוקפי מערכת הפעלה של הכונן.
• AFW: מגן בפני התקפות בקלטים באפליקציה, בפלטים ובניצול חולשות על השרת, מניעת התקפות DoS.
• XML FW: מגן בפניות ל – Web Services כנגד התקפות XML המובילות ל – DoS, מניעת זליגה דרך SQL Injection.

האתגרים (שלא מודעים להם) בהטמעת מערכת מניעת זליגה DLP

דנתי כאן לא מעט על פתרונות למניעת זליגת מידע רגיש מהרשת. מניעה זו כנראה מילה שאפתנית מידי. ניטור זו מילה רלוונטית יותר. אני לא מכיר ארגון (אזרחי או צבאי) שיכול למנוע זליגת מידע לחלוטין. מדובר ביותר מפתרון אחד והם משלימים אחד את השני.

הפתרון המרכזי במניעת זליגה הוא מערכת DLP. הבעיה הגדולה, והקושי שלא מדברים עליו בשלב בחירת הפתרון והטמעתו, היא שמערכת כזו מייצרת המון התראות שווא (False Positives) והתראות רלוונטיות בכמויות מאוד גדולות.

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

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

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

כדי לכסות טוב יותר את ערוצי זליגת המידע, כדאי לשלוח התראות בקטגוריות מסוימות ממערכת DLP למערכת SIEM. במערכת SIEM ישנה אפשרות לסנן באופן עמוק יותר אירועים ולהציף לטיפול רק כאלה שעוברים סף (Threshold) מסוים. למשל, ע"י קישור ל – LDAP, רק אירועים מעובדים שאינם חברים בקבוצה מסוימת ששלחו תוכן בקטגוריה של משאבי אנוש, יוצפו בממשק ה – SOC לטיפול. כך ניתן להקטין את כמות ההתראות המטופלות ולטפל ביותר קריטיים.

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

סוגי מתקפות Web Services ומנגנון הגנה

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

למעשה, שימוש ב – WS מתאפשר ע"י שליחת קובץ XML לשרת. השרת המקבל את הקובץ מקלף ממנו את התגיות השונות – פעולת Parsing – ועל סמך התגיות מבצע פעולות שונות בהתאם לתוכן שבין התגיות. אופן העבודה דומה מאוד לזה של HTML.

בחלוקה גסה, ניתן לחלק את הסיכונים למתקפות לפני ה – Parser ואחרי. מתקפות אחרי הפרסר הן קלות לניחוש. למשל, גניבת מידע ע"י מתקפת SQL Injection. נגד מתקפות כאלה לא מסובך מידי להתמודד. כל אותן המלצות מוכרות מעולם ה – Application Security תופסות גם כאן. קרי, בדיקות קלטים קפדניות (סוג משתנה, טווח ערכים וכדומה), אימות מבקש השירות וכדומה.

הבעיה העיקרית בשימוש ב – WS נובעת מניצול מתקפות לפני ביצוע Parsing. למעשה, בשלב הזה השרת קלט את הקבצים אך טרם יכול לבדוק אותם. מתקפות אלה מכוונות בעיקר ל – DoS. קרי, לפגוע בשירות ע"י הפלת השרת. למשל ע"י סוגי המתקפות הבאים: XML bomb, Buffer Overflow. אני לא מכיר מספרים מדויקים, אבל נהוג לחשוב כרגע שרוב המתקפות בתחום השירותים מכוונות ל – DoS. זה יכול להוביל להפלת שרת ואפילו אתר Web.

כיצד ניתן להתמודד עם מתקפות מסוג זה? הפתרון דומה לפתרונות בשכבות אחרות כגון שכבת האפליקציה או הרשת – Firewall. במקרה זה מדובר ב – XML FW שיודע להתמודד גם עם מתקפות לפני הפרסר. למשל, הגבלת מספר קריאות לשירות שניתן לפתוח מכתובת מסוימת, גודל קובץ XML מקסימלי ועוד.

בעתיד אפרט יותר לגבי יכולות XML FW.

PCI DSS – פתרון בידוד "אי"

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

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

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

אך האם כל זה נדרש? התשובה היא לא בהכרח.

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

אז הנה שלוש גישות לפתרון חלק מהדרישות של תקן ה – PCI.

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

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

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

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

מנגנוני בקרה מפצים

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

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

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

• סיסמאות לשרתים/בסיסי נתונים בברירות מחדל (למשל חשבון SA בשרת SQL).

• שינוי 'זמני' של מדיניות סיסמאות ב – AD

• חוק Any Port ב – Firewall

• קישור DB Link בין בסיס נתונים בפיתוח לבסיס נתונים בייצור 

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

הנה כמה מנגנונים מפצים ששווה לשקול ליישם בארגון:

• נהלי אבטחת מידע

• ביצוע סקרי סיכונים (הממצאים טובים רק לעת ביצוע הבדיקה)

• מערכת לניתוח חוקים ב – Firewall (אני מכיר לפחות שתי מערכות כאלה)

• מערכת לניתוח הרשאות במערכות שונות (יש כמה מערכות יפות בשוק)

• מוצר Vulnerability Assessment (מערכת הסורקת רכיבי רשת/שרתים ומאתר ליקויי אבטחת מידע ידועים, ובד"כ מפיקה דוחות ארוכים מידי שלא יודעים מה לעשות איתם)

• מערכת לניהול אירועי אבטחת מידע SIEM/SOC

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

לאבטח את המאבטח

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

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

• שרת ניהול של רכיב אבטחת מידע (למשל, שרת ניהול של Firewall) שיושב ב – LAN ולא בסגמנט אבטחת מידע מבודד. אותו שרת גם לא מנע אפשרות להריץ התקפת Brute Force ואפשר למצוא את הסיסמא למערכת ההפעלה תוך ניסיונות בודדים.

• רכיב בקרה היוצר רשומות, על ניסיונות גישה בלתי מורשים, לצרכי תיעוד (Audit Trail) ושומר את הלוגים שהוא יצר, בספריה לא מוגנת בפני מחיקה בשרת אחסון.    

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

אז מה אפשר לעשות? כמובן שאין המלצה אחת שנכונה לכל רכיב.

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

• לשנות ולשמור את הסיסמא קרוב לחזה (ולא בקובץ ברשת).

• להגדיר חוק ב – FW המונע גישה לא מורשית אליו.

• להגדיר חוק ב – DB Firewall המונע שינוי וקריאת בסיס הנתונים שלו עצמו.

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

מומחי אבטחת מידע רבים טוענים שקל לפרוץ לבסיסי נתונים (בין אם ישירות ע"י גישה ל – DB ובין אם דרך אתרים). התקפות שונות כגון SQL Injection (הזרקת קוד SQL עוין) או Cross Site Scripting (התקפה המכונה XSS בה שותלים סקריפטים עוינים באתרים) מאפשרות התקפות על אתרים ובסיסי נתונים. ובאמת, ישנם הרבה מומחים ואתרים המוכיחים כמה קל לבצע התקפות כאלה ואחרות.

אינני מנסה לטעון שזה לא נכון וגם אינני יכול לטעון שמהערכות שלנו מאובטחות ב – 100%. אבל הנה חומר למחשבה:

שני מומחים בתחום בסיסי נתונים ניסו להוכיח כמה קל לשנות הרשאות של משתמש מנמוכות לגבוהות וכמה קל לנצל פרצות ידועות בבסיס הנתונים. הם קיבלו גישה ישירה ל – DB פנימי (ברמת SQL) שאינו מאובטח באופן מושלם, והם לא היו צריכים לחדור לרשת ולגלות את בסיסי הנתונים ברשת. במשך יומיים (לא מלאים) הם ניסו התקפות שונות וניסו למצוא שירותים פגיעים. רק לאחר יומיים הם הצליחו לנצל פרצה ידועה כדי להעלות הרשאות (Privilege Escalation).

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

AFW ו – DB FW

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

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

• כהגנה בפני התקפות מהאינטרנט ש – AFW לא נותן מענה הולם.
• כאשר רוצים להגן על בסיסי הנתונים מפני גישה לא מורשית מתוך הארגון (בד"כ בארגונים גדולים בעלי מאות ואלפי משתמשים).
• כאשר המידע מאוד רגיש.
• כאשר בסיסי הנתונים אינם מוקשחים כראוי.
• בסביבה מרובת בסיסי נתונים.

CISO

הגנה בשכבות

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

התפיסה הקיימת, לרוב בארגונים קטנים, כאילו Firewall (להלן FW) מספק פתרון אבטחת מידע מלא לרשת, עלולה להיות מוטעית. נבחן את הדוגמא בשרטוט 1. נאמר שמבנה הרשת מחולק לפי השרטוט ושה – FW מוגדר לאפשר תעבורה בפורטים 80, 25 בלבד לסגמנט המסומן: 1. לכאורה, הרשת מאובטחת בצורה אידיאלית. אז היכן הבעיה?

זוכרים את השומר שסינן באופן דומה את הנכנסים לבניין (גם נותני השירות הם פורט 80)? ה – FW אומנם מאפשר תעבורת Web (פורט 80), אך אין לו מושג מה מכילה תעבורה זו. אם ניקח התקפה ידועה בשם SQL Injection, אשר מזריקה קוד SQL לשדה קלט במסך, הקוד יעבור באופן 'חוקי' לסגמנט המסומן: 2, לכיוון שרת האפליקציה (APP Srv) ומשם לבסיס הנתונים (DB). ברגע זה, הפורץ השיג את יעדו וגנב מידע מה – DB. אז מה הפתרון? הטמעת שכבות הגנה. לצורך הדוגמא, נעשה זום לכמה רכיבים מהשרטוט ונתעלם מהשאר (שרטוט 2).

לאחר שהגענו למסקנה ש – FW לא מספיק. נוכל להוסיף שרת  Firewall לשכבת האפליקציה (AFW) שיגן על שרת ה- Web מפני סוג התקפות כאלה ואחרות. נוכל להוסיף (במקום AFW או בנוסף) שרת Firewall לשכבת בסיסי הנתונים (DB FW). רכיבים נוספים אלה (השכבות הנוספות) אמורים למנוע התקפות בשכבת האפליקציה (Layer 7).

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

CISO