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

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

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

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

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

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

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

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

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

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

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

הודעות שגיאה

 {פוסט קצרצר, לא מוצא זמן לכתוב…}

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

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

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