בשנים האחרונות , ובעידן של ריכוז פעילות אצל ספקיות שירותים כדרך הגיונית ופשרת מחירים ותמיכה לשירותים מנוהלים - ישנה מגמה בולטת בהחלט לספקיות שירותים , ובעיקר ספקיות האינטרנט וחברות שר מסוגלות להעמיד מערך אירוח שרתים ומתן תמיכה במודל מיידי - להקים שירותים במודל ASP - ( Application Service Povider ) ובכך בעצם לאפשר מתן של שירותים ללקוחות רבים על גבי פלטפורמה אחת.
בין השירותים שעוברים לאט לאט לעולם הASP אנו יכולים לראות את מודל הHosted UTM FW אשר מפשט עלויות על ידי כך שבקצה הלקוח מונח נתב בלבד, אשר מקשר לתוך VRF אצל הספקית ונגמר בFW שיתופי פרטי , ואז המודל ללקוח הוא בעצם שירות חודשי במקום השקעה בציוד וכח אדם מתחזק. זה נכון גם לגבי MAIL RELAY , שירות SSL VPN ומאוד נפוץ בתחום אירוח האתרים ואפילו החל לתפוס תאוצ בעולם הVOIP. כמובן שאת השירות הוותיק מכולם - תיבת דואר אלקטרוני אצל הספקית , אנו רואים כיום כבר כמובן מאליו ... שירותים רבים מתווספים כיום ואפשר אפילו לראו שירותי EXCHANGE או VMWARE מנוהלים ומשותפים מרחוק.
אחת הבעיות היותר מורכבות בהקמת מערכות ASP הקשורות לאבטחת מידע או בכלל לשירותים מנוהלים ( ואני לא מכניס לכאן את אלמנט הCTO\CSO המבוהל שלוקחים לו את השליטה ומעבירים לספקית ואזהוא מרגיש את הצורך להתגונן כפליים ) הוא הצורך לייצר קונסולידציה בין מערכות לצורכי הגדרה מנוהלים.
הכוונה בעצם היא לכך שכאשר חברה נרשמת לשירות מסויים , בד"כ קליטת ההזמנה מבצעת דרך מערכות CRM למיניהן , שמטייבות עסקאות מול מערכת ERP , ולאחר מכן מעבירות לביצוע חלק ניכר מהפעולות במערכות אוטומטיות . על ידי כך בעצם ירד העומס והדרישות לכח אדם במערכות הBACKOFFICE של הספקיות.
דוגמא מעניינת תהיה למשל ללקוח אשר מעוניין לקבל שירות אנטיספאם עבור דומיין שלו . אז הדרך הנכונה תהיה להעביר את הדומיין לשליטת הספקית והקמת DNS ZONE על גבי מערכות הDNS ( התממשקות ראשונה ) ואז להקים את הדומיין והמדיניות במערכות האנטיספאם ( התממשקות שניה ) ואז להגדיר בחוקי המערכות אפשרות RELAY לדומיין דרך מערכות הספקית ( התממשקות שלישית ) ואז לדבר עם מערכת הIDM של הלקוח בשביל לאפשר למשתמשים שליטה ( התממשקות רביעית ) וכאשר יש לך 5000 - 10000 וכן הלאה לקוחות , המשימה הופכת לעיל בלתי הגיוני . ולכן האוטומציה.
אחת הדרכים שאני אוהב להשתמש בהן היא להקים בעצם מערכת LINUX אשר יודעת לקבל שאילתות ממערכות הERP\CRM ובעצ לתקשר עם המערכות השונות ואז לבצע את הקמת החוקים באופן אוטומטי.
ולאור העובדה שרוב המערכות לASP תומכות SSH ( וזו בד"כ דרישת RFP בעולם הזה ) נהוג לעבוד עם mod_ssh על גבי PERL. אך אני אישית לא אוהב את השיטה הזו - ואני מקווה שאני מכיר לכם משהו חדש פה : Expect Interpeter.
בעצם מערכת EXPECT ( אשר ניתנת להרצה גם על שכבה של WINDOWS ) מאפשרת לנו לעבוד באופן אמיתי כמשתמש וירטואלי על גבי מערכות מרוחקות ולשלוח להן פקודות ומשתנים משלנו. למשל בואו ניקח את שיטת הוספת הניתוב לנתב CISCO ... איך בעצם נוסיף ניתוב ? נבצע את הקוד הבא :
Username: USERNAME
Password: PASSWORD
Router> enable
Router# conf t
Router(conf)# router 1.1.1.1 255.255.255.255 2.2.2.2
Router(conf)# exit
Router# wr mem
Router# exit
למעשה מדובר על רצף פקודות הגיוני , אשר מתחיל בTELNET\SSH לכתובת IP , והמשתנים בו יהיו תמיד שם משתמש , ססמה , כתובת יעד וכתובת מקור. ולכן ניתן ליצור לכך אוטומציה . מה שיבצע SCRIPT של EXPECT יהיה בעצם לצפות לערכים שונים מהפלט של פקודת הSSH או הTELNET ובעצם לזרוק את המשתנה או הפלט הנכון לטרמינל בתגובה - בניגוד לדרך של עבודה עם PROCESS , כאן מדובר על שימוש טבעי בסביבת הTELNET , דוגמא לביצוע מקביל של הפעולה שרצינו בסקריפט של EXPECT ( בלי בדיקת קלט או נכונות וכל מיני פולשטיקים ... ) :
#!/usr/bin/expect -f
#usage : ./script RO_IP RO_USER RO_PASS SRC_IP SRC_MSK DST_IP
set router_ip [lindex $argv 0]
set router_user [lindex $argv 1]
set router_pass [lindex $argv 2]
set data_srcip [lindex $argv 3]
set data_srcmsk[lindex $argv 4]
set data_dstip [lindex $argv 5]
set timeout -1
spawn telnet $router_ip
match_max 1000000
expect "Username:"
send -- "$router_user\r"
expect "Password:"
send -- "$router_pass\r"
expect "> "
send -- "enable\r"
expect "# "
send -- "conf t\r"
send -- "route $data_srcip $data_srcmsk $data_dstip\r"
send -- "exit\r"
send -- "wr mem\r"
send -- "exit\r"
expect eof
ולמה בזבזתי זמן יקר לכתוב כאן את הסקריפט הפשוט הזה ? פשוט בכדי להראות עד כמה פשוט לבצע אוטומציה לתהליכים מול מערכות באמצעות EXPECT ולהוריד משמעותית את הOVERHEAD , שימו לב לקוד - אני בעצם משתמש בידע שלי בהגדר נתב ושולח פקודות טבעיות למול SESSION של TELNET במקרה זה ופשוט בכל פ מצפה לפלט מהקונסול ושולח ערכים משלי. באמצעות שימוש בסקריפטולוגיה מסוג זה , בעצם ניתן להביא למימוש - אוטומציה של תהליכים. מתכנת הסקריפט בסהכ צריך לשבת עם פלט של הגדרה , או עם איש תפעו מערכת ולעקוב אחרי השורות . אגב קיים גם פורט שנקרא AutoExpect שבעצם מקלט סשן חי ואז הופך אותו לסקריפט.
בואו נחשוב על זה , אם יש לנו מערכות כמו FORTIGATE שאנו רוצים להגדיר VDOM עם הגדרות בסיסיות בצורה אוטומטית ולתת לאיש התפעול מסך פשוט וללא טעויות - דרך קלה לביצוע . אותו דבר לגבי הקמה של שירות דואר RELAY לחברה , אותו דבר לגבי בניית רשתות MPLS קטנות ( כי מי ייתן למערכת אוטומטית להגדיר BGP ... ) ורבים אחרים. ניתן לראות הטמעות רבות בארגונים גדולים אשר עצם הקמת משתמש חדש ברשת דורש מעבר על 15 מערכות שונות ( וחלק מכך הוא גם הגדרות בNAC למשל ) אשר ניתן לפשט על ידי קישור פשוט של LOGINSCRIPT ראשוני אשר יגדיר את המשתמש בשאר המערכות השונות בארגון.
אז נכון , יש להיזהר רבות , וCODE REVIEW במבחינת אבטחת מידע הוא קריטי, כמו גם דרך העברת CREDENTIALS לסקריפט ( שאגב נהוג לא לשמור במערכות אלו , אלא לקחת אותו בכל הרצה כקלט ולתשאל עבורו ) אבל בהחלט מדובר על דרך הגיונית ולגיטימית לבנות מערכות LARGE-SCALE תוך שמירה על מינימום מגע אנושי בתהליך , ומקסימום יעילות.
Labels: managment, provider, script, service
