בלוג

פריצת המידע בחברת שירביט
16/03/2021

פריצת המידע בחברת שירביט

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

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

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

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

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

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

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

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

כיצד נמענים מתקיפת סייבר?

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

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

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

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

מה האלטרנטיבה?

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

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

שי גינדי, סמנכ"ל פיתוח עסקי ומכירות בקבוצת Y-tech

מודל האבטחה בענן - אחריות משותפת
01/02/2021

מודל האבטחה בענן - אחריות משותפת

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

IaaS – תשתית כשירות (Infrastructure aa Service), לדוגמא: שרתים, רשת, ואחסון בענן

PaaS – פלטפורמה כשירות (Platform aa Service), לדוגמא: שירות SQL ללא שרת

SaaS – תוכנה כשירות (Software aa Service), לדוגמא: שירות Salesforce

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

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

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

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

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

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

מודלי אבטחה IaaS, PaaS ו- SaaS

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

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

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

במודל SaaS, ללקוח אין כלל שליטה על רובד התוכנה והוא למעשה מעביר את כלל האחריות לספק. ספק SaaS אחראי על כלל רבדי האבטחה בפתרון אותו הוא מספק, מרמת התשתית ועד לרמת התוכנה. צוותי IT צריכים לדאוג רק לניהול הרשאות, בהתאם לכלים שמעמיד לרשותם הספק. יש לזכור שבמרבית המקרים, ספקי SaaS נשענים על תשתיות של ספקי IaaS אחרים, ולמעשה נוצרת שכבה נוספת של אחריות על האבטחה של הפתרון שמתחלקת בין מספר ספקים. יש לזכור שספק "תוכנה כשירות", קרי SaaS, בסופו של יום מספק שירות תוכנה ועליה הוא אחראי באופן בלעדי מקצה לקצה, במקרה בו הוא מארח את התוכנה על שירות תשתית IaaS של ספק אחר, ספק ה-IaaS מחזיק בתפקיד ברור באחריות על אבטחת התשתית ויתכן כי מחזיק בתקנים מתאימים, אך אינו שותף לאבטחת התוכנה, קרי המוצר אותו הלקוח צורך מספק ה-SaaS. עמידה בתקנים של ספק התשתית בשירות ה-IaaS אינה זוקפת את זכות התקינה גם לספק ה-SaaS שאחראי באופן בלעדי לתוכנה, במקרה זה עליו להציג תקינה הולמת בלעדית למוצר אותו הוא מספק, ללא קשר לתשתית עליה מתארח המוצר, שכן ספק התשתית אינו לוקח חלק באבטחת המוצר/תוכנה והתקינה אינה רלוונטית לרובד זה.

אכיפת המודל

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

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

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

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

 111

תומר שוייצר הינו מנכ"ל קבוצת Y-tech ונציג ישראל בוועדת התקינה העולמית למחשוב ענן בארגון ISO/IEC JTC1.

RTO/RPO - המשכיות עסקית
05/12/2021

RTO/RPO - המשכיות עסקית

רציפות עסקית / Business Continuity Program הינה תוכנית רחבה שמטרתה לאפשר לארגון לעבוד בצורה רציפה ככל הניתן וזאת בהתאם ליעדים שנקבעו מבעוד מועד. תכנית התאוששות מאסון (Disaster Recovery Plan) היא חלק מתוך התהליך הגדול יותר של בניית רציפות עסקית. עולם המחשוב כיום הינו חלק בלתי נפרד מכל פעילות עסקית באשר היא, ישנם עסקים שנעזרים במערכות מחשוב אך יכולים גם להתקיים בלעדיהם לפרק זמן כזה או אחר וישנם עסקים אשר כל הליבה העסקית מושתתת על מערכות המחשוב והפסקת פעילות של דקות ספורות ולעיתים שניות עשויה להיות בעלת משמעות עסקית גדולה.

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

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

RTO :  Recovery Time Objective:

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

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

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

RPO Recovery Point Objective:

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

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

RPO-RTO

מדדים אלו עשויים להשפיע על:

  • אופן בניית מערכות המחשוב ב DAY1
  • אילו מערכות גיבוי יש להתאים ללקוח לרבות פתרון DR (disaster recovery) קר או חם, אקטיבי או פאסיבי.
  • רמת השרות הנדרשת (SLA) מהמערכות התומכות, מצוות ה-IT ומהספקים הרלוונטיים.

דוגמא לתהליך מלא:

  • בשלב אפיון הפתרון ללקוח מתייחסים לנתונים הבאים:
    • מהי רמת ה Uptime הדרושה למערכת?
    • כמה זמן של כשל טוטאלי מסוגל לסבול הארגון?
    • כמה זמן איבוד מידע יכול הארגון להכיל (RPO)?
    • מהו הזמן הנדרש לארגון כדי לבצע חזרה מגיבוי (RTO)?

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

  • בהתאם לתשובות יאופיין פתרון אשר יענה על הצרכים הנ"ל, לדוגמא:
    • רמתUptime נדרשת 99.99% בשנה – יש לוודא שמערכות הספק אכן עומדות בתקן ומסוגלות לספק את הדרישה.
    • כשל טוטאלי של עד 9 שעות בשנה.
    • איבוד מידע של יום עבודה אחד.
    • חזרה מגיבוי תוך 4 שעות.

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

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

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

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

סיכום:

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

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

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

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

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

שי גינדי הוא סמנכ"ל פיתוח עסקי ומכירות בקבוצת Y-tech. בעבר מנכ"ל ומייסד Sage שנרכשה ע"י Y-tech.

אבטחת מידע בענן - איך עושים זאת נכון? (עבור שותפים)
18/10/2021

אבטחת מידע בענן - איך עושים זאת נכון? (עבור שותפים)

לקוחות מחשוב ענן בכל הגדלים ומכל המגזרים מצפים לקבל שקט נפשי מספק הענן שלהם. לשם כך, עליהם להיות בטוחים שתשתיות המחשוב והתקשורת בדטה סנטר שבו הם עושים שימוש מתפקדות היטב. ציפיה זו חשובה במיוחד במידה והלקוח הוא אינטגרטור שמעוניין להציע שירותי ענן ללקוחות הקצה שלו, בדומה למודל ה-ICT שמציעה Y-tech בתוכנית השותפים,  ICT Platform for Integrators. על האינטגרטור לדעת בוודאות גבוהה שהוא ולקוחות הקצה יזכו לרמת אבטחת המידע הגבוהה ביותר.

אבטחת מידע היקפית ופנימית

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

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

אבטחה ברמת הענן

מעבר לאבטחה שמציעה ספקית ה-ICT בענן ברמה ההיקפית, קיימת רמה נוספת של אבטחה ברמת הרשת הפנימית של כל לקוח. כל לקוח הרוכש חבילת שירותי אירוח המבוססת על Y-tech ICT Platform זוכה גם לשכבה שלישית של אבטחה. שכבה זו מגינה על התקשורת לכל שרת ושרת בשכבה 2 שהיא רמת ה-Data Link שמהווה את נקודת החיבור של השרת לרשת. הלקוח יכול לנהל את רמות האבטחה השונות באופן ישיר מתוך פורטל הניהול של Y-tech, כולל חוקי Firewall, הקצאות רוחבי פס, IDS, אנטי וירוס, לוגים ברמות שונות ומעקב אנומליה, כולל הגדרת התראות במייל על חריגות מהנורמה או ניסיונות חדירה שונים.

שרידות מובטחת

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

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

ובסופו של תהליך: הלקוח בוחר מה עוד להתקין

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

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

האינטגרטור יכול ליישם תשתית של שירותים שיתופיים ממנה יספק ללקוח שירותי Security as a Service על גבי Firewall שיתופי שלו ומוצרים נוספים. במקביל באפשרותו לבנות לכל לקוח ענן פרטי ווירטואלי משלו, שם הוא יספק לו את ה-Firewall הייעודי שלו באופן פרטי או שילוב של סביבות פרטיות עם סביבות שיתופיות מתוך הענן של האינטגרטור, כגון שירותי אבטחת דואר שיתופיים, גיבוי ועוד. חשוב לציין שהכול גמיש, בלחיצת כפתור, והכול בר שינוי לכל אורך חיי השירות.

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

יוסי בר הוא מהנדס תשתיות ואבטחה בחברת Y-tech, אחראי על סביבות ה-Data Center, התקשורת ואבטחת המידע.


מחשוב ענן חכם: המפתח למהירות עבודה של אינטגרטורים ושל לקוחות קצה
01/08/2021

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

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

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

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

מהירות עבודה כתוצאה מאוטומציה

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

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

 

הלקוח/שותף מצויד מראש בהקצאה מספיקה של משאבי IT, הקצאה אותה הוא רוכש בפלטפורמה בהתאם לצרכיו ויכול להרחיבה בכל עת בכפוף למודל השירות בו הוא בחר. במודל Pay as you go הוא יכול לנהל את ההקצאות באופן עצמאי בכל עת ישירות מממשק הניהול. יתרונות אלה  תורמים להגברה משמעותית של מהירות תהליכי ה-IT של האינטגרטור ושל לקוח הקצה.

 

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

עם סיום הכנת השרתים החדשים עבור לקוח הקצה הם מתחברים באופן אוטומטי לרשת ה-Data Center, מקבלים כתובת IP באופן אוטומטי, ולמעשה כבר מחוברים לרשת האינטרנט לפי מדיניות אבטחה ורוחב פס שהלקוח/אינטגרטור בעצמו יכול לקבוע ולנהל.  גם האבטחה העוטפת את השרתים כבר נמצאת במקום והם מתחברים, שוב, באופן אוטומטי, למנגנונים כגון ניטור צריכת משאבי CPU, זיכרון, רשת ואחסון ומערך אבטחה רחב הכולל Firewall ו-IDS ברמת שרת. במקביל, קיימת הגנה מאחורי ה-Firewall הראשי של האינטגרטור שנמצא גם מאחורי שכבות האבטחה הכלליות של ה-Data Center.

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

 

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

 

מהירות שנובעת מביצועי מערכת 

מערכת ה-ICT של קבוצת Y-tech ערוכה ליכולות שציינו מבחינת כמות המשאבים ורמת התקשורת ומתרחבת באופן מתמיד במקביל לדרישה מהשטח. Y-tech מציעה מערכות פיזיות עם יכולות מחשוב, עיבוד וזיכרון ברמה הגבוהה ביותר. זאת, בנוסף למערכות אחסון מבוססות SSD שמציעות יכולות פעולות קלט/פלט לשנייה (IOPS) אדירות. החיבור מתבצע באמצעות מערכת תקשורת המבוססות על Fiber 10Gb עם תפוקה רחבה וזמן שיהוי (Latency) מינימלי.

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

 

יוסי בר הוא מהנדס מערכות בכיר בחברת Y-tech ICT, חבר בצוות האחראי על
תשתיות 
Y-tech ICT ובניית תהליכי אוטומציה.


כיצד ממשלות יכולות למקסם את הפוטנציאל של מחשוב הענן?
19/04/2021

כיצד ממשלות יכולות למקסם את הפוטנציאל של מחשוב הענן?

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

שיתוף פעולה ברמה הלאומית

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

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

עידוד ארגונים נוספים להשתמש במחשוב ענן

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

יש לתקנן מחשוב ענן

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

תומר שווייצר הוא מנכ"ל ומייסד Y-tech

למידע נוסף:

מדוע ממשלת ארה"ב עוברת למחשוב ענן:
https://www.wired.com/insights/2013/09/why-the-u-s-government-is-moving-to-cloud-computing/

"הממשלה כפלטפורמה" - פורבס:
https://www.forbes.com/sites/joemckendrick/2014/02/23/government-as-a-platform-how-cloud-computing-is-progressing-inside-the-beltway/#49e6e4e74987

 

ענן ממשלתי - מחקר שוק:
https://www.marketsandmarkets.com/PressReleases/government-cloud.asp



 

 


אבטחת שירות הענן - טיפים לספקי ענן
16/01/2021

אבטחת שירות הענן - טיפים לספקי ענן

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

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

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

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

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

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

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

תומר שוייצר הינו מנכ"ל קבוצת Y-tech ונציג ישראל בוועדת התקינה העולמית למחשוב ענן בארגון ISO/IEC JTC1.


צור קשר