הבדיקות יראו: כיצד להתכונן ליישום Cisco ISE ולהבין אילו תכונות מערכת אתה צריך

באיזו תדירות קונים משהו באופן ספונטני, נכנעים לפרסומת מגניבה, ואז הפריט הרצוי בהתחלה אוסף אבק בארון, במזווה או במוסך עד לניקוי או מעבר האביב הבא? התוצאה היא אכזבה עקב ציפיות לא מוצדקות ובזבוז כסף. זה הרבה יותר גרוע כשזה קורה לעסק. לעתים קרובות, גימיקים שיווקיים כל כך טובים עד שחברות רוכשות פתרון יקר מבלי לראות את התמונה המלאה של היישום שלו. בינתיים, בדיקת ניסיון של המערכת עוזרת להבין כיצד להכין את התשתית לאינטגרציה, איזו פונקציונליות ובאיזו מידה יש ​​ליישם. כך תוכלו להימנע ממספר עצום של בעיות עקב בחירת מוצר "באופן עיוור". בנוסף, יישום לאחר "טייס" מוכשר יביא למהנדסים הרבה פחות תאי עצב שנהרסו ושיער אפור. בואו נבין מדוע בדיקות פיילוט חשובות כל כך לפרויקט מוצלח, באמצעות הדוגמה של כלי פופולרי לשליטה בגישה לרשת ארגונית - Cisco ISE. בואו נבחן גם אפשרויות סטנדרטיות וגם לא סטנדרטיות לחלוטין לשימוש בפתרון שנתקלנו בו בפרקטיקה שלנו.

Cisco ISE - "שרת רדיוס על סטרואידים"

Cisco Identity Services Engine (ISE) היא פלטפורמה ליצירת מערכת בקרת גישה לרשת המקומית של הארגון. בקהילת המומחים, המוצר זכה לכינוי "שרת רדיוס על סטרואידים" בשל תכונותיו. למה? בעיקרו של דבר, הפתרון הוא שרת Radius, שאליו צורפו מספר עצום של שירותים ו"טריקים" נוספים, המאפשרים לך לקבל כמות גדולה של מידע הקשרי וליישם את סט הנתונים שנוצר במדיניות גישה.

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

לא ניתן לבצע פיילוט ביישום: למה אתה צריך בדיקה?

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

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

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

אז איך מתכוננים כראוי ליישום Cisco ISE? מניסיוננו ספרנו 4 נקודות עיקריות שחשוב לקחת בחשבון במהלך בדיקת הפיילוט של המערכת.

גורם טופס

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

האם ציוד הרשת שלך תואם ל-Cisco ISE?

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

האם כל המכשירים שלך סטנדרטיים?

לכל רשת יש מכשירים טיפוסיים שלא אמור להיות קשה להתחבר אליהם: תחנות עבודה, טלפונים IP, נקודות גישה ל-Wi-Fi, מצלמות וידאו וכן הלאה. אבל קורה גם שצריך לחבר מכשירים לא סטנדרטיים ל-LAN, למשל ממירי אותות RS232/Ethernet, ממשקי אל-פסק, ציוד טכנולוגי שונים וכו' חשוב לקבוע מראש את רשימת התקנים כאלה. , כך שבשלב היישום כבר יש לך הבנה כיצד טכנית הם יעבדו עם Cisco ISE.

דיאלוג בונה עם מומחי IT

לקוחות Cisco ISE הם לרוב מחלקות אבטחה, בעוד שמחלקות IT אחראיות בדרך כלל על הגדרת מתגי שכבת גישה ו-Active Directory. לכן, אינטראקציה פרודוקטיבית בין מומחי אבטחה ומומחי IT היא אחד התנאים החשובים ליישום ללא כאבים של המערכת. אם האחרונים תופסים אינטגרציה עם עוינות, כדאי להסביר להם כיצד הפתרון יועיל למחלקת ה-IT.

5 מקרי השימוש המובילים של Cisco ISE

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

גישה מאובטחת לרשת LAN דרך חוט עם EAP-TLS

כפי שמראות תוצאות המחקר של חוצנים שלנו, לעתים קרובות כדי לחדור לרשת של חברה, תוקפים משתמשים בשקעים רגילים אליהם מחוברים מדפסות, טלפונים, מצלמות IP, נקודות Wi-Fi והתקני רשת לא אישיים אחרים. לכן, גם אם הגישה לרשת מבוססת על טכנולוגיית dot1x, אך נעשה שימוש בפרוטוקולים חלופיים ללא שימוש בתעודות אימות משתמש, קיימת סבירות גבוהה להתקפה מוצלחת עם יירוט הפעלה וסיסמאות בכוח גס. במקרה של Cisco ISE, יהיה הרבה יותר קשה לגנוב תעודה - בשביל זה, האקרים יצטרכו הרבה יותר כוח מחשוב, כך שהמקרה הזה מאוד יעיל.

גישה אלחוטית כפולה SSID

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

מעקף ויצירת פרופילים של אימות MAC

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

EAP-שרשור

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

יציבה

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

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

פרויקטים לא סטנדרטיים: עוד למה אתה צריך את Cisco ISE, או 3 מקרים נדירים מהפרקטיקה שלנו

בקרת גישה לשרתים מבוססי לינוקס

פעם פתרנו מקרה די לא טריוויאלי עבור אחד הלקוחות שכבר הטמיעו את מערכת Cisco ISE: היינו צריכים למצוא דרך לשלוט בפעולות המשתמש (בעיקר מנהלים) בשרתים עם לינוקס מותקנת. בחיפוש אחר תשובה, הגענו לרעיון להשתמש בתוכנת PAM Radius Module החינמית, המאפשרת לך להיכנס לשרתים המריצים לינוקס עם אימות בשרת רדיוס חיצוני. הכל בהקשר זה יהיה טוב, אלמלא "אבל" אחד: שרת הרדיוס, ששולח תגובה לבקשת האימות, נותן רק את שם החשבון ואת התוצאה - הערכה מקובלת או הערכה נדחתה. בינתיים, להרשאה בלינוקס, אתה צריך להקצות לפחות פרמטר אחד נוסף - ספריית הבית, כך שהמשתמש לפחות יגיע לאנשהו. לא מצאנו דרך לתת את זה כתכונת רדיוס, אז כתבנו סקריפט מיוחד ליצירת חשבונות מרחוק במארחים במצב חצי אוטומטי. משימה זו הייתה די ריאלית, מכיוון שעסקנו בחשבונות מנהלים, שמספרם לא היה כל כך גדול. לאחר מכן, משתמשים התחברו למכשיר הנדרש, ולאחר מכן הוקצתה להם הגישה הדרושה. נשאלת שאלה סבירה: האם יש צורך להשתמש ב-Cisco ISE במקרים כאלה? למעשה, לא - כל שרת רדיוס יתאים, אבל מכיוון שללקוח כבר הייתה מערכת זו, פשוט הוספנו לה פיצ'ר חדש.

מלאי חומרה ותוכנה ברשת ה-LAN

פעם עבדנו על פרויקט לאספקת Cisco ISE ללקוח אחד ללא "פיילוט" מקדים. לא היו דרישות ברורות לפתרון, בנוסף עסקינן ברשת שטוחה ולא מפולחת, מה שסיבך את המשימה שלנו. במהלך הפרויקט, הגדרנו את כל שיטות הפרופיל האפשריות בהן תמכה הרשת: NetFlow, DHCP, SNMP, אינטגרציה של AD וכו'. כתוצאה מכך, גישת MAR הוגדרה עם היכולת להיכנס לרשת אם האימות נכשל. כלומר, גם אם האימות לא היה מוצלח, המערכת עדיין תאפשר למשתמש להיכנס לרשת, אוספת מידע אודותיו ותקליט אותו במסד הנתונים של ISE. ניטור רשת זה במשך מספר שבועות עזר לנו לזהות מערכות מחוברות והתקנים לא אישיים ולפתח גישה לפלח אותם. לאחר מכן, הגדרנו בנוסף את הפרסום להתקנת הסוכן בתחנות עבודה על מנת לאסוף מידע על התוכנה המותקנת עליהן. מה התוצאה? הצלחנו לפלח את הרשת ולקבוע את רשימת התוכנות שיש להסיר מתחנות העבודה. לא אסתיר שמשימות נוספות של הפצת משתמשים לקבוצות תחום ותיחום זכויות גישה לקחו לנו די הרבה זמן, אבל בדרך זו קיבלנו תמונה מלאה של איזו חומרה יש ללקוח ברשת. אגב, זה לא היה קשה בגלל העבודה הטובה של פרופילים מחוץ לקופסה. ובכן, היכן שהפרופיל לא עזר, בדקנו את עצמנו, והדגשנו את יציאת המתג שאליה היה מחובר הציוד.

התקנה מרחוק של תוכנות בתחנות עבודה

המקרה הזה הוא אחד המוזרים ביותר בפרקטיקה שלי. יום אחד, לקוח הגיע אלינו עם זעקה לעזרה - משהו השתבש בעת הטמעת Cisco ISE, הכל נשבר, ואף אחד אחר לא יכול היה לגשת לרשת. התחלנו לבדוק את זה וגילינו את הדברים הבאים. לחברה היו 2000 מחשבים, שבהיעדר בקר תחום, נוהלו תחת חשבון מנהל. לצורך הצצה, הארגון הטמיע את Cisco ISE. היה צורך להבין איכשהו האם מותקן אנטי וירוס במחשבים קיימים, האם סביבת התוכנה עודכנה וכו'. ומכיוון שמנהלי IT התקינו ציוד רשת במערכת, הגיוני שהייתה להם גישה אליו. לאחר שראו איך זה עובד ופיתחו את המחשבים האישיים שלהם, המנהלים העלו את הרעיון להתקין את התוכנה על תחנות עבודה של עובדים מרחוק ללא ביקורים אישיים. רק תארו לעצמכם כמה צעדים תוכלו לחסוך ביום בדרך זו! המנהלים ביצעו מספר בדיקות של תחנת העבודה לקיומו של קובץ ספציפי בספריית C:Program Files, ואם היה נעדר, הושק תיקון אוטומטי באמצעות קישור המוביל לאחסון הקבצים לקובץ .exe של ההתקנה. זה אפשר למשתמשים רגילים לעבור לשיתוף קבצים ולהוריד משם את התוכנה הדרושה. למרבה הצער, המנהל לא הכיר היטב את מערכת ה-ISE ופגע במנגנוני הפרסום - הוא כתב את הפוליסה בצורה לא נכונה, מה שהוביל לבעיה שהיינו מעורבים בפתרון. באופן אישי, אני מאוד מופתע מגישה יצירתית כזו, כי זה יהיה הרבה יותר זול ופחות כרוך בעבודה ליצור בקר תחום. אבל כהוכחה לקונספט זה עבד.

קרא עוד על הניואנסים הטכניים המתעוררים בעת יישום Cisco ISE במאמר של עמיתי "תרגול יישום Cisco ISE. השקפה של מהנדס".

ארטם בובריקוב, מהנדס עיצוב של מרכז אבטחת מידע ב-Jet Infosystems

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

מקור: www.habr.com