ברודקום רכשה את VMWare – ההמשך

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

להלן תקציר:

למי שלא מכיר את חברת ברודקום, החברה רוכשת חברות שונות, ולאחר הרכישה היא מוכרת חלקים שונים של החברה הנרכשת, מקצצת בהשקעות בצורה משמעותית בחברה הנרכשת, כך שבמקרים רבים, החברה הנרכשת אינה יותר מ"שלד" ממה שהיתה בעבר חברה גדולה. דוגמאות לא חסר: CA, symantec ויש עוד כמה. גם רכישת VMWare אינה הרכישה האחרונה, החברה רכשה מאז את ConnectAll.

בחודשים האחרונים התקיימו מספר ישיבות עם הנהלת ברודקום, VMware, שותפים ואחרים, בהם התגלו הדברים הבאים:

  • החברה מחסלת את תוכנית השותפים המקורית של VMware וברדקום מעתה היא המחליטה מי יהיו השותפים והתנאים החדשים.
  • החברה משנה לחלוטין את פורטפוליו המוצרים של VMWare ומעתה יהיו שני מוצרי "אב", ורוב המוצרים האחרים של החברה לא יהיו זמינים יותר לרכישה עצמאית, אלא כ"תוספים" לאותם "מוצרי אב" – ארחיב בנושא בהמשך הפוסט
  • ברודקום החליטה ש-VMWare תצא מכל מה שקשור לוירטואליזציית קצה (VDI), ניהול מערכות קצה, וכל מה שקשור ל-End User Computing והיא מציעה את החטיבה למכירה עד סוף השנה הקלנדרית הנוכחית בסכום של 5 מיליארד דולר.

עתה נתרכז בעניין אותם "מוצרי אב": החברה תציע בעצם שני משפחות חדשות, הראשונה תיקרא VCF (ר"ת VMware Cloud Foundation) וחבילה זו תציע את כל מה שיש ל-VMWare להציע בתחום וירטואליזציה מנוהלת, מקומית או בענן (או בצורה משולבת) , כולל חלקים רבים שהוצעו כפתרנות נפרדים ומעתה יוצעו כ-Add-ons (תוסף) למי שרוכש את VCF. להלן תרשים דוגמא למה יוצע לרוכשים (לחצו להגדלה)

קרדיט: William Lam

מוצר האב השני הוא VVF (ר"צ VMware vSphere Foundation) – שזו כמובן חבילת ה-vSphere שמיועדת לקצה הגבוה וללקוחות הגדולים. כמו ב-VCF, גם כאן, מוצרים שהיו בעבר עצמאיים וניתנים לרכישה נפרדת, ימכרו מעתה רק כ-Addons. להלן תרשים החבילה (לחצו להגדלה):

קרדיט: William Lam

כפי שניתן לראות מהתרשימים, ישנם מספר חבילות מוצרים שהחברה כורכת, בין אם הלקוח רוצה או לא. כך לדוגמא, מעתה חבילת ARIA כלולה ב-VVF. יש לך מערכת אחרת לניתוח קבצי LOG  לדוגמא? או שתיפטר מהמערכת או שתשלם עבור חלק שלא תשתמש. מצד שני, ישנם חלקים שמעתה זמינים רק אם רוכשים את VCF – כמו VMWare firewall או ATP.

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

החבילה הקטנה הנוספת היא חבילת VMware vSphere Standard (VVS) – להלן התרשים (לחצו להגדלה):

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

ההצעה האחרונה שיש לברודקום/VMWare להציע נקראת VMware vSphere Essentials Plus Kit (VVEP) והיא די זהה ל-VVS. להלן התרשים (ההגבלה ל-3 שרתים היא במקור – לחצו להגדלה):

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

בקליפ שפרסמתי בפוסט הקודם, ציינתי כי חברות גדולות לא יתרגשו מעליית המחיר הצפויה (והיא בהחלט צפויה – מפוסטים שונים ברשת רואים עליה שנעה בין 100 ל-300 אחוז, אבל תמיד כדאי לשאול את הנציגות שמולה אתם עובדים), אך הבעיה המהותית קשורה לעיקר: שום חברה לא מוכנה "לבלוע" עליית מחיר כה גבוהה כשמדובר בדיוק באותו מוצר שהיה זמין במחיר נמוך משמעותית בעבר (כבר ציינתי כי רוב מוצרי VMWare הפסיקו להיות זמינים לרכישה עצמאית ו/או רשיון Perpetual? הנה פוסט של VMware עצמה על כך לגבי רשיונות, כל המוצרים ושרותי SAAS) ולכן רבים מתחילים להתעניין בפתרונות מתחרים (ספקי הענן כבר מציעים הצעות מפתות, Nutanix גם מציעים)

מה ניתן לעשות? על מה מומלץ להסתכל ולבחון? על כך – בפוסט הבא שיפורסם בסופ"ש זה.

המעבר ל-DPU

(הערת Off topic: פוסט זה ופוסטים בעתיד יכתבו בלשון נקבה. מדוע? הפרטים נמצאים כאן)

עולם הוירטואליזציה קיים כבר יותר מ-20 שנה, והפתרונות עברו מספר "סבבים" של שינויים מהותיים בפתרונות, להלן פירוט (ברשותכם, אינני מתכוונת להיכנס לפרטים של רמת Hypervisor וכו' שגם הם השתנו, אך הדבר אינו רלוונטי לפוסט זה):

  • סיבוב ראשון – פתרונות כמו ESX/ESXI ופתרונות וירטואליזציה של מתחרים התמקדו בכך שישנם חלקים פיזיים שונים שמרכיבים את פתרון הוירטואליזציה: יש פתרון אחסון יעודי, יש מתגים ונתבים, יש חומת אש יעודית ועוד מספר "ברזלים" שנותנים שרותים משלימים – ויש את כל שרותי ה-Compute שמתקבלים מהשרתים. כל דבר – בנפרד.
  • סיבוב שני – קונסולידציה – פתרונות כמו vSAN של VMware ופתרונות מתחרים – מעבירים את השרותים המשלימים ל-Compute – אל תוך ה-Nodes עצמם. אחסון? הכנס דיסקים ונקים. רשת? יש NSX ופתרונות אחרים שייתרו פתרונות "ברזלים" יעודיים לטובת פתרון וירטואלי, כך שבסופו של יום, מערכת כזו תהיה בנויה משרתים עם דיסקים, כרטיסי רשת ומספר מתגים פשוטים ותו לא. הכל מוקם, מוגדר ומתוחזק בתוך פתרון הוירטואליזציה.

הסיבוב הנוסף הוא בעצם "חצי סיבוב". השינוי העיקרי הפעם הוא שאנחנו מוציאים החוצה מעבודת המעבד כל מה שקשור לאבטחה, תעבורת רשת, אחסון, הצפנה וכו' – ואנחנו מעבירים את הכל לדבר שנקרא SmartNIC (או כפי ש-NVIDIA ו-AMD ואחרים רוצים שתקראו לזה: DPU. אינטל רוצים שתקראו לזה: IPU).

להלן תרשים שיפשט את הדברים:

(קרדיט: The Next Platform)

כפי שאנו רואים, ה-DPU (מצד שמאל למטה בתרשים לעיל) הוא זה שיריץ את שרותי ה-ESXI וכל שרותי ה-Management (לשם כך ה-DPU מכיל מעבד ARM עם מספר ליבות וזכרון) והשרת עצמו יריץ מערכת מינימלית שמכילה Hypervisor או כל מערכת הפעלה יעודית "על הברזל" – והמערכת תתממשק  אל ה-DPU, כך שה-DPU בעצם ינהל את השרת והשרותים.

מדוע בעצם עושים זאת? הסיבה לכך די פשוטה: אין זה משנה איזה מעבד X86-64 קיים לך בשרת, בין אם מדובר ב-Xeon של אינטל או ב-EPYC של AMD, המעבדים הללו טובים בדברים מסויימים כמו Compute, אך פחות טובים בכל מה שקשור לתקשורת, הצפנות, תעבורת רשת גבוהה, אחסון ברמה ובביצועים של SAN וכו', ודברים אלו יכולים להתבצע ביעילות עם שבבים יעודיים (ASIC או FPGA, תלוי ביצרן, בפתרון וכו') ולשם גם VMWare וגם היצרניות האחרות (חוץ מ-AMD, אינטל ו-NVIDIA, גם חברות אחרות מתכוונות להציע DPU משלהן, כמו Marvell, ברודקום וכו') רוצות להיכנס, ובמילים אחרות – מה שהיה פרויקט Project Monterey בעבר, עכשיו זה חלק אינטגרלי מ-vSphere 8 שיוצא.

מאיפה בעצם הגיע הרעיון לכך? התשובה די פשוטה: ספקי ענן ציבורי, ובמיוחד AWS. רוב השרתים ב-AWS (הסתכלו לדוגמא על AWS Nitro) כוללים בעצם מערכת שמכילה KVM לינוקסי מינימלי שמריץ רק מכונות וירטואליות, וכל שאר השרותים מתקבלים דרך כרטיסי PCIe Express בעלי שבבים יעודיים (דוגמת Pensando של AMD) שנותנים שרותים יעודיים כמו אחסון, תקשורת, הצפנה ושרותים נוספים לפי הצורך, כך שבעצם המעבדים בשרת לא מריצים כמעט מאומה – זולת ה-Compute של הלקוחות וה-Hypervisor המינימלי. בשיטה זו רמת האבטחה היא הרבה יותר גבוהה, וגם אם מאן דהוא יצליח לפרוץ לשרת, אין שרות אחסון שרץ מקומית בשרת שניתן להתחבר אליו ולגנוב ממנו מידע (כל התחברות בין VM לאחסון  דרך הכרטיס היעודי מבוססת הצפנה עם מפתח יעודי פר VM ויש עוד מספר אלמנטים לאבטחה).

יש גם נקודת לינוקס בכל העניין: מכיוון ש-DPU מכיל במקרים רבים מעבדי ARM עם אחסון וזכרון עצמאיים נפרדים מהשרת, אפשר לתכנת אותם, ו-Linux Foundation, יחד עם יצרני חומרה נוספים הקימו פרויקט שנקרא Open Programmable Infrastracture Project (ובקיצור – OPI) כדי לעודד חברות תוכנה לכתוב אפליקציות ודברים נוספים עבור אותם DPU.

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

… שלא מתאים לכולם.

למען האמת – אפילו לא לרוב אלו שיש להם מספר קטן עד בינוני של שרתי ESXI.

אני חושבת שיש צורך לספר משהו אחד פשוט לגבי אותם IPU/DPU שהולכים להיות מוצעים: כל הפתרונות הללו נבנו בראש ובראשונה עבור ספקי ענן ציבורי (אז'ור, AWS, GCP, אני בספק אם אורקל משתמשת בכך), ואותן יצרניות החלו להוסיף ולשנות את הפתרונות כך שיוכלו לעבוד עם Project Monterey, כך שבסופו של יום – מדובר על פתרון שהוא מאוד חדש, ואינני בטוחה אם אפשר לקרוא לו "יציב", ובכל מקרה – מחירי כרטיסים כאלו – גבוהים מאוד, ויש צורך גם במתגים עם תמיכה במהירויות גבוהות (25 או 50 ג'יגהביט כמינימום!) – כך שגם אלו שרוצים פתרונות DPU כאלו, לא בטוח שזה יתאים להם.

לסיכום: DPU הוא פתרון מעולה, כאשר יש לארגון עשרות רבות, מאות או אלפי שרתי ESXi. לשאר הארגונים, מעבדי X86-64 כמו Xeon או EPYC – יתנו עבודה כלל לא רעה, ובמיוחד במעבדים העתידיים של שתי החברות ששואפות להכניס רכיבי האצה שונים לתוך מעבדיהן – ואת התוצאות לכך נוכל לראות בחודשים הקרובים.

רעיון קטנטן ליצרני פתרונות אחסון

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

אחד הדברים היותר מעניינים שיצא לי לראות בשנים האחרונות – זה המרחק הענק בין מה שחברות אלו מייצרות ומה שמוצריהם נותנים מבחינת שרידות, מהירות העברת נתונים וכו' – לבין מה שחברות רבות בארץ רוכשות לעצמן כשהן מחפשות סטורג'. כיום, ב-2022, יש עדיין לא מעט חברות שרוכשות אחסון המבוסס על דיסקים מכניים עם SSD שמשמש כ-Cache, ואלו היותר מתקדמים – רוכשים דיסקים SSD שמהירות הכתיבה שלהם איטית (Read Intensive) ועם עוד SSD או 2 הכוללים Flash מסוג SLC או MLC לצורך כתיבה מהירה. את אותם פתרונות אחסון מחברים לשרתים המריצים vSphere עם חיבורים של 10 ג'יגהביט חיבור נחושת או +SFP (עם DAC או סיב), או שעדיין משתמשים בחיבורים הישנים בסיבים במהירות עד 16 ג'יגהביט.

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

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

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

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

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

כשאני מדבר על "ברזל זמני", אני חושב שכל יצרן אחסון יכול בעצם לבנות שרת 2U פשוט, עם מעבד EPYC (בשביל כל ה-PCIe Lanes ל-SSD ולציוד הנוסף) וכמות קטנה יחסית של אחסון נטו (נאמר: 4 טרהבייט) עם הציוד המינימלי שצריך כדי לתת ביצועים די טובים (לא צריך להשקיע יותר מדי כמו הוספה של סוויצ', אפשר להשתמש בחיבורי JBOF חיצוניים לדוגמא). שרת כזה ניתן להשאלה לארגון מתעניין ל-30 יום כדי שיחברו ו"ישחקו" איתו – יאחסנו נתונים, יבדקו ביצועים, ויראו איך פתרון כזה יכול להשתלב בחברה.

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

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

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

מוגש כחומר למחשבה.

השוואת Proxmox למתחרים

יוצא לי מדי פעם לקבל טלפונים מקוראי הבלוג ואחרים – שמבקשים לדעת האם פתרון Proxmox יכול להיות פתרון טוב ותחליף לפתרונות יקרים יותר (vSphere) או אם הוא יכול לעמוד בתחרות מול Xen Server, או Hyper-V ואחרים, ולפיכך החלטתי לכתוב את הפוסט הזה כדי להסביר את הדברים בצורה יותר קלה ומובנת.

קצת מידע על Proxmox – מדובר מערכת ותיקה שהחלה את חייה עוד לפני שלמעבדי X86 היו יכולות וירטואליות בחומרה כמו שיש להם כיום, ולפיכך המערכת תמכה בפתרון וירטואליזציה כמו OpenVZ – הרצת מערכת לינוקס (ומערכות אחרות, אך לא Windows) בקונטיינר (אם כי פורמט הקונטיינר שונה מפורמט כמו של Docker וכו'). מאוחר יותר, כש-KVM בלינוקס צבר עם QEMU פופולריות, הוא הוטמע בפתרונות רבים (כל ספקי הענן הציבורי משתמשים ב-KVM הלינוקסי, מיקרוסופט ב-Azure משתמשת ב-KVM ב-Instances המאפשרים Nested Virtualization) וגם ב-Proxmox וכיום כשמקימים מכונה וירטואלית ב-Proxmox, היא תרוץ עם KVM.

כשזה מגיע לוירטואליזציה, Proxmox עומד בכבוד מול המתחרים ויש לו כמעט את כל מה שיש בפתרונות Hypervisor מתחרים. אין בעיה להצמיד ב-VM חומרה מסוגים וחיבורים שונים, המערכת תקבל בשמחה כל דיסק עם כל File system כ-Storage, כולל ext3, ext4,btrfs, zfs,ceph, glusterfs, והמערכת גם כוללת תמיכה שיתופית באחסון: יש לך דיסקים במכונה אחת אך לא במכונה אחרת? אין בעיה! בהגדרת ה-Storage, בחר ב-All Nodes (ראו תמונה לעיל, לחצו להגדלה) והמערכת תייצר עבורך NBD מבלי שתצטרך להרים NFS או CIFS עם כל ההגדרות. גם כשזה מגיע לשרידות, יש ל-Proxmox מה להציע (כל עוד יש לך 3 מכונות פיזיות) – הגדר את המכונות הוירטואליות שאתה מעוניין שישרדו, והמערכת תבצע להן מיגרציית Live אם אחד השרתים יורד בצורה מסודרת, או שהיא תריץ את ה-VM מחדש במכונה אחרת (כל עוד האחסון מבוסס על NFS או CIFS. קצת בעייתי לבצע שרידות שכל הדיסקים יושבים על שרת אחד שבדיוק מכבים אותו)…

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

מה קורה אם ניקח את Proxmox ונשווה אותו לפתרונות יותר גדולים כמו oVirt/RHV או vSphere של VMware? התשובה פשוטה: אין ל-Proxmox סיכוי להתחרות, הואיל ו-Proxmox לא כולל חלקים רבים. קחו לדוגמא עניין כמו איזון עומסים של מכונות VM בשרתים (ב-VMWare זה נקרא DRS, ב-oVirt/RHV זה נקרא Scheduling Policies) – זה לא קיים ב-Proxmox. עוד דוגמא קשורה לניצול כל הדיסקים הקיימים בשרתים ליצירת מערך אחסון גדול ושורד. נכון, יש GlusterFS שנתמך ב-Proxmox, אולם ל-Proxmox אין מושג ירוק מה קורה עם ה-GlusteFS – אתה יכול לבצע Mount וזהו. ב-VMware לעומת זאת, פתרון vSAN ליצירת אחסון מדיסקים – נלקח הרבה יותר ברצינות (ב-oVirt/RHV היה פתרון Hyperconverged מבוסס GlusterFS אולם הוא היה פתרון חצי אפוי והוחלט בשקט לבעוט אותו החוצה). אם נבחן לדוגמא את עניין הרשתות ושימוש ברשתות וירטואליות, הממשק ב-Proxmox מאוד אנמי (אין לך אפשר להגדיר דברים כמו VLAN, Slaves ודברים רבים דרך הממשק, אין לך אפילו אפשרות לראות אם החיבור נפל או לא, ואם אתה מתעקש להגדיר, אתה צריך לעבוד בדרכים הישנות, כמו לפני ש-NetworkManager או Netplan היו קיימים) ואילו ב-vSphere או RHV הדברים נלקחים בצורה הרבה יותר רצינית (הנה דוגמא ב-oVirt), ועוד לא דיברנו על ההתעקשות של מפתחי Proxmox לא לשלב את libvirt – ה-API הגדול והמשמעותי ביותר לכל ענייני וירטואליזציה בלינוקס ובמערכות הפעלה אחרות.

לסיכום: Proxmox הוא פתרון מעולה, למצבים מסוימים – אם רוצים להעביר משרד קטן P2V לשימוש ב-Thin clients כשהכל רץ על שרת אחד או שניים, לסטארט אפ קטן שאין לו תקציבים כרגע להשקיע בתשתית והוא לא רוצה/לא יכול להתחיל לעבוד בענן ציבורי ועוד, אך מעבר לכך – ארגונים גדולים, חברות גדולות, מוסדות ועוד – מומלץ שימשיכו להשתמש בפתרונות של VMware (או Nutanix) ומומלץ גם להכיר מה הולך לקרות ב"גל" הבא – ועל כך אפרסם פוסט נפרד.

על חוות שרתים מעל ומתחת לאדמה

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

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

התשובה עצמה – קצת מורכבת, וברשותכם – אפרט.

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

מה שתמיד מומלץ ללקוחות לעשות, זה לעבוד עם הכלים והפלטפורמות של ספקי הענן הציבורי הגדולים בכל הקשור לשרידות, ולהזניח את שיטות ה-DR הקלאסיות. שלושת ספקי הענן הגדולים, לדוגמא, מאפשרים להקים תשתית וירטואלית של שרותים ומכונות VM שפועלות במקביל במספר Availability zones (או Regions), כך שאם AZ או Region (תלוי בטרמינולוגיה של ספק הענן הציבורי) נופל או נפגע, התשתית הוירטואלית של הלקוח תמשיך לפעול מה-AZ או ה-Region האחר שנמצא גיאוגרפית במיקום שונה. לאלו שמוכנים להשקיע עוד, ניתן אפילו לבנות זאת בצורה של שימוש ב-3 Regions (או Region נוסף מחוץ לישראל ו-2 Availability zones), כך שלא חשוב מה יקרה בישראל, המערכת של הלקוח עדיין תמשיך לעבוד. אפשרות נוספת (ותמיד מומלצת) היא שימוש ב-Multi Cloud תוך שימוש בשרותים של ספקי ענן ציבורי שונים והקמה של התשתית אצל ספקי ענן ציבורי שונים, כך שאם קורה מקרה נדיר בה כל התשתית של ספק ענן ציבורי כלשהו נופלת – המערכת של הלקוח תפעל אוטומטית מהתשתית של ספק ענן ציבורי אחר.

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

פוסט תגובה ל-"לא להינעל" (המאמר של ליאור קיסוס)

קראתי את מאמרו של ידידי היקר ליאור קיסוס באתר PC, וחשבתי להגיב לגבי הדברים.

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

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

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

את הריצה המטורפת לשימוש ב-SAAS אני רואה מכל עבר, ואני חוזר ומציין תחת כל עץ רענן כי ברוב מוחלט של המקרים, שרותי ה-SAAS הם מיותרים לחלוטין אם לא מדובר בפרודקשן שחייב להיות זמין 24/7. אדרבא, ככל שמשתמשים בכמה שיותר שרותי SAAS, האפשרות למעבר לספק ענן מתחרה הופך להיות יותר ויותר קשה, במיוחד כשרוב מוחלט של ספקי הענן הציבורי כיום כלל לא מציעים שום Migration Path נורמלי מענן אחד לשני, ואף אחד כמובן לא מוכן לממן את השינויים בסקריפטים ובמקומות אחרים שצריכים לשנות כדי לעבור ענן.

יש נקודה מסויימת שאינני מסכים עם ליאור, והיא קשורה למחיר: מחירי הענן לא עולים ועולים, ואני אומר זאת באחריות: אני משתמש בשרותי ענן של אמזון כבר 6 שנים לצרכיי האישיים, וכיועץ אני מתעדכן תדיר במחירים של הספקים השונים מבחינת מחירי תשתיות ושרותים. כמעט בכל מצב, תמיד אפשר למצוא דרכים לחסוך כספים בענן, אם מוכנים קצת, טיפה, להתאמץ: במקום להשתמש ב-RDS, תפסיקו להתעצל ותקימו בעצמכם תשתית SQL (לדוגמא). במקום להשתמש ב-CDN הסופר יקר של ספק הענן, תשתמש ב-CDN של מתחרים שאינם נופלים בביצועים ובאיכות ממה שספק הענן שלכם מציע, יש "שכבות" שונות לאחסון Object Storage כמעט אצל כל ספק ענן וניתן בעזרת סקריפט פשוט להעביר קבצים (אם לא רוצים לשלם על Tiering חכם), וזה – על קצה המזלג, כך שבעזרת תכנון נכון וניטור מתמשך, לא צריך להגיע למצב של "שריפת" תקציבים אצל ספק הענן הציבורי.

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

לסיכום: יכול להיות שפתרון On Prem כ"מקדים ענן" הוא פתרון שיתאים לארגונים שונים, אך יחד עם זאת, כמעט כל גוף או ארגון שאני מכיר, כבר החל ללמוד ולהשתמש בתשתיות של ספקי ענן שונים (לא רק גוגל ו-AWS) ורבים מהם מעדיפים להשתמש בשרותי ה-SAAS של אותו ספק, בין אם להפעיל קונטיינרים או להריץ דברים אחרים, וברוב המקרים – לנסות לשכנע אותם עכשיו "לחזור ל-On Prem" יתקל בהתנגדות. אני לא חושב ש-On Prem הוא פתרון רע (ומי שיסתכל בערוץ היוטיוב העסקי שלי יוכל לראות הדגמות רבות על תשתית On Prem), אך אני כן חושב שבעזרת תכנון נכון, אפשר גם להרכיב פתרון טוב וזול – אצל ספקי ענן.

קצת פרטים לגבי DCPMM של אינטל

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

בשנים האחרונות אינטל הוציאה את מקלות ה-DCPMM (ר"ת DC Persistent Memory Module). אלו מקלות אחסון שאינם משתמשים ב-NAND כמו אחסון SSD אחר, אלא 3D Xpoint, שיטה חדשה שמאפשרת כתיבה וקריאה במהירות מאוד גבוהה ושרידות (מבחינת DWPD לדוגמא) גבוהה בהרבה, בהשוואה לפתרונות Flash אחרים שקיימים בשוק. אינטל הוציאה גם פתרונות אחסון קונבנציונאליים מבוססי 3D Xpoint (תחת השם Optane, למרות שתחת השם הזה הם הכניסו עוד סוגים שונים של אחסון, למה לא לבלבל את הלקוח הפוטנציאלי!) אך ה-DCPMM היה שונה בכך שהוא הרבה יותר מהיר והוא משובץ בתושבות הזכרון בשרת, וכתוצאה מכך, שימוש ב-DCPMM יחד עם זכרון RDIMM יכול לתת פתרון די טוב לזכרון בכמות גבוהה, במחיר יותר נמוך בהשוואה לכמות זהה של זכרון אם כולו היה מבוסס DRAM RDIMM.

בוידאו הבא אסביר קצת לגבי דברים כמו:

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

להלן הקליפ.

נקודות חשובות נוספות לגבי הנושא:

  • כאן יש מסמך חשוב מאוד מחברת לנובו המשווה את ביצועי המערכת אם משתמשים רק בזכרון, או שילוב של יותר זכרון ומעט DCPMM, וההיפך, וכמו כן הוא נותן דוגמאות לגבי יחסים RDIMM עם DCPMM מצוותים. מומלץ לקרוא.
  • הפתרון אינו קיים למערכות שאינן מבוססות אינטל (כמו AMD) הואיל ומדובר בפתרון סגור וקנייני של אינטל.
  • לא מומלץ להשתמש במצבי אחסון Block Storage כשמשתפים מקלות DCPMM משני מעבדים שונים (או יותר, במקרה ומשתמשים במעבדי ה-Cooper Lake) אלא אם יש לכם מעבדים מסידרה L או מעבדי GOLD, אחרת נוצר צוואר בקבוק שקשה לשחרר.
  • ולחבריי הגיקים שצופים בערוץ היוטיוב של ServeTheHome – אכן ראיתי את הקליפ של פטריק אתמול, וזה הזכיר לי שעל הנושא לא הוצאתי כמעט כלום, אז בגלל זה החלטתי לבצע "השלמות" 🙂

ההבדלים בין מעבדי אינטל שונים עבור שרתים (וידאו קליפ)

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

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

להתראות CentOS??

בימים האחרונים יצאה הודעה כי CentOS 8 תעבור שינויים משמעותיים ובכללם – ההפצה תחדל מלקבל עדכונים בסוף שנת 2021, ולא תהיה הפצת CentOS המקבילה ל-RHEL מבחינת גירסא וקוד. הדבר היחיד שישאר הוא CentOS Stream שזו גירסת CentOS טיפה יותר "מתקדמת" מ-RHEL (אבל מבחינת עדכוני אבטחה – ה-Stream יקבל את העדכונים רק לאחר ש-RHEL יקבל).

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

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

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

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

שלישית – ולעניין זה לא תקבלו שום אישור מגורם רשמי: התקדמות טכנולוגית שגורמת להפסד פיננסי לרד-האט. בעבר, אם הייתי צריך להרים תשתית לינוקס גדולה לפיתוח, פרודקשן, עם backend ועוד דברים רבים – הייתי צריך בארגון גדול, לרכוש מספר לא קטן של רשיונות RHEL לכל שרת פרודקשן, בין מדובר בשרת פיזי או וירטואלי. כיום, לעומת זאת, המעבר לקונטיינרים חוסך לי בצורה משמעותית את כמות רשיונות ה-RHEL שאני צריך לרכוש לפרודקשן. אם פעם, לשם הדוגמא, הייתי צריך לרכוש 20 רשיונות, היום 4 רשיונות ל-Worker Nodes יספיקו, ופה מדובר רק בדוגמא אחת. רבים כיום יעדיפו הפצת לינוקס חינמית ברוב המקומות למעט היכן שחייבים בגלל ההנהלה להשתמש בהפצות RHEL מסחריות.

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

כל איש לינוקס ותיק ירגיש בוודאי תחושת דה-ז'ה וו בנושא. כבר היינו בעבר בסרט הזה. כשחברת רד-האט החליטה להוציא רק גרסאות לינוקס מסחריות בתשלום (מה שהיה RHEL, RHES), נוצרו מספר פרויקטים שלקחו את קוד המקור של RHEL וביצעו Fork לגירסה עם שם אחר אך עם תאימות מלאה (בעקרון, לא מדובר בתהליך של קימפול הכל מחדש באופן אוטומטי. יש לא מעט כלים לפתח, יש לא מעט סקריפטים לכתוב, להסיר קבצי לוגו וסימנים מסחריים של רד-האט וכו') כשה"זוכים" בפופולריות בסופו של דבר היו CentOS, Scientific Linux וכמובן Oracle שהחליטה פשוט לבנות את הכל בעצמה ולגנוב לקוחות מ-רד-האט.

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

לפיכך, להלן המלצותיי (לפי התיעוד הרשמי):

  • אם אתם משתמשים בגירסה כלשהי של CentOS 6 – שדרגו בדחיפות. ה-EOL שלה חל בחודש שעבר.
  • אם אתם משתמשים בגירסה כלשהי של CentOS 7 – אתם בטוחים, ואתם תמשיכו לקבל עדכונים לגירסה עד תאריך 30/6/2024. אם אינכם חייבים לעבור לגירסה 8, פשוט אל תעברו, במיוחד אם המכונות הן וירטואליות.
  • אם אתם משתמשים בגירסה כלשהיא של CentOS 8 – אתם תקבלו עדכונים עד סוף שנה הבאה (31/12/2021)
  • עכשיו, כל מה שנותר לעשות, זה להמתין ולראות מי "יקפוץ". האם רד-האט תחזור בה? (קהילות הלינוקס הן לא קהילות מנומסות, בלשון המעטה!) ואם לא, מי החברות שיכריזו על Fork ל-RHEL? (אמזון? מיקרוסופט? גוגל?) במשך השנה הקרובה אנחנו נראה את ההתפתחויות ואני מאמין שכבר בחודשים הקרובים נראה חדשות בנושא עם מפות דרכים והמלצות לאן להגר.

ולבינתיים, אני ממליץ לא לקחת המלצות פזיזות, אם אפשר.

"הר" פתרונות האבטחה שאינו רלוונטי כל כך

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

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

המציאות פשוטה: גם אם תקים "הר" של Appliances לצרכי אבטחת מידע בכדי להגן על חדירה מבחוץ, הפורצים יכולים לעקוף את כל ההגנות הללו עם פעילות Phishing וכניסה למערכת עם פרטים גנובים. חשוב לזכור: הנקודה הכי חלשה ברוב הארגונים – היא המשתמשים, ולא יעזרו חידודי נהלים לא לפתוח לינקים, לא להוריד/להריץ קבצים במייל וכו' מהסיבה הפשוטה ביותר: אם משתמש קיבל מייל Phishing והוא הזין בו פרטי חיבור אמיתיים, ברוב המקרים הוא לא ירוץ למחלקת IT או אבט"מ לספר על כך. אחרי הכל, מדוע לו לחטוף על הראש? עדיף להפעיל ראש קטן ולהתעלם מכך.

הנקודה הכי חשובה בכל הסתכלות על אבטחת מידע היא Zero Trust. לא לתת שום Trust בין אם מדובר בתקשורת מבחוץ פנימה או בין שרתים או בין מכונות דסקטופ לשרתים. אחרי הכל, אם מאן דהוא הצליח להשיג פרטי גישת VPN למערכת שלכם, מהרגע שהוא מתחבר, הוא נמצא בתוך התשתית של החברה, גם אם יש לו הרשאות מוגבלות (גם עם הרשאות מוגבלות אפשר ליצור נזקים גדולים). יקח לחברה זמן להבין שהפורץ משתמש בפרטי גישת VPN שנגנבו בפעולות Phishing ממשתמש לגטימי, ומאותו רגע שהפורץ מחובר, גרימת הנזק היא פנימית, ה-Firewall וה-WAF שלך לא עוזרים במאומה באותו זמן – וכאן, כדאי לזכור, פורץ חכם לא יחפש לגרום מיידית נזק, אלא יחפש בתשתית נקודות חולשה או תשתית "צדדית" שעליה הוא יכול להתקין את ה-Payload ורק לאחר מספר ימים להפעיל זאת ולהתחיל לגרום נזק/להצפין תוכן או להעביר תכנים.

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

  • להיפטר מסיסמאות: סיסמאות היו ויהיו – מקור לאחד מכאבי הראש הגדולים, כולל כל ה-Policies ליצור אותם, החלפתם וכו'. גם במיקרוסופט ובחברות תוכנה אחרות הבינו זאת מזמן והם מציעים פתרונות שונים המבוססים על טביעת אצבע, Windows Hello, מפתחות כמו Yubikey של Yubico (או Tian של גוגל, ויש גם מפתחות המבוססים בכלל על קוד פתוח כמו Solokeys). בנוסף, שימוש במפתחות מאפשר להשתמש בהצפנות שונות (נתמכות בעיקר ב-Yubikey) ויחסית די קל להטמיע את הפתרונות בכל מערכות ההפעלה.
  • הצפנת תכנים: הסיוט הכי גדול לחברות מבחינת אבטחת מידע, הוא גניבה ו/או הצפנה באמצעות כופרה של המידע, וארגונים גדולים מאוד (חברות כמו קאנון, אוניברסיטאות, בתי חולים ועוד) חוו את הסיוט ונזק משמעותי נגרם לאותם ארגונים. אחד הפתרונות שניתן לבצע הוא הצפנה של רוב התכנים החשובים, וביצוע Decryption דרך Gateway שאליו מחוברים מספר מצומצם של משתמשים. ניתן לדוגמא לבצע זאת בעזרת הקמת LUN שיחובר למערכת לינוקס וירטואלית. מערכת הלינוקס תבצע encryption/decryption עם כלי כמו LUKS-2 או בכלים אחרים, ושיתוף (לאחר decryption) עם SAMBA. אפשר להתגונן נגד כופרה תוך שימוש ב-snapshots (במכונת הלינוקס בשימוש LVM).
  • ביצוע Snapshots – באופן עקרוני, Snapshots ברמת File systems לא אמורים לצרוך כמות משאבים גדולה ליצירה ולכן מומלץ ליצור Snapshots בפתרון האחסון ל-File systems בצורה תכופה מאוד (כל שעה לדוגמא, ובמקרים חשובים כמו הנח"ש – כל מחצית שעה). כך, אם ישנה התקפת כופרה, ניתן לשחזר מה-Snapshot במהירות במקום לשחזר מקלטות.
  • Pen testing הוא פתרון חלקי שלדעתי אינו מספק: לצערי לא מעט ארגונים וחברות שוכרים מישהו מחברה שיבצע בדיקות (Penetration testing), ורובם גם משתמשים באותם כלים וב-Kali Linux (מתי אנשים יבינו ששימוש ב-Kali Linux הוא "אות קין" שלמשתמש אין הבנה רצינית בלינוקס? כל הפצת לינוקס כוללת את כל הכלים הדרושים!) כדי לבצע את הבדיקות, ובמתודה זו הבדיקות והסריקות פשוט אינן מספקות את התשובה המלאה.
    בדיקות הקשחה וחדירה זה לא רק שימוש בכלים כמו nmap, nessus ו-1001 כלים נוספים, אלא לימוד כל המערכת ועבודה בצוות כדי לחשוב על נסיונות חדירה מכל מערכת שרצה בארגון, חולשות שקיימות לכל שרת, לכל Appliance ולכל ציוד (במיוחד ציוד ישן שאין לו עדכונים כבר מספר שנים – ציוד כזה מומלץ להחליף כמה שיותר מוקדם), מי הם האנשים בחברה שפעולות Phishing עליהם יכולות לגרום נזק מהותי, היכן ניתן לעצור או להאט דליפת מידע אם גורם כלשהו הצליח לפרוץ, האם יש עצירה אוטומטית של תעבורת Upload ל-IP שאינו white listed לאחר כמה מאות מגהבייט לדוגמא (כשהפורץ מנסה לגנוב כמה שיותר קבצים), ובקיצור – הכלים הם רק חלק קטן מהעבודה, ודרוש צוות רציני כדי לנסות לפרוץ (מבלי להגביל את הצוות, אבל עם הנחיה לגבות את הכל ולרשום כל גילוי ושינוי) ולא מישהו שהקים Kali Linux על מכונה וירטואלית ומכיר כמה כלים.
  • "קמצנות כרונית" של הרשאות: תופעה שקיימת בכל ארגון – עודף הרשאות שניתנו למשתמשים שונים, הרשאות שנפתחו "זמנית" ונשארו פתוחות או הרשאות שנפתחו ברמת worldwide (בלינוקס/יוניקס זה מוכר כ-777) בגלל שמישהו התעצל לחפש בגוגל ולקרוא איך מגדירים הרשאות בלינוקס. מאוד מומלץ לבצע אחת לחודש או לתקופה לעבור על כל ההרשאות (גם הרשאות מקומיות!) ולצמצם את ההרשאות. אם רוצים להשתמש לדוגמא ב-passwordless ssh, יש להגביל את החיבוריות להרצת פקודות מסויימות, כניסה מכתובות IP מסויימות, ועוד.
  • עדכוני תוכנה ללא תאריכון: אחת הבעיות שכתבתי לגביה שוב ושוב בבלוג זה – מנמ"ר מחליט שעדכונים יהיו אחת ל-X חודשים ותו לא. לך תסביר לאותו מנמ"ר שחולשות אבטחה מתגלות כל הזמן ויש לא מעט מקרים שיש צורך דחוף בהתקנת עדכונים, אחרת התשתית חשופה. דוגמא פשוטה: אם אתם משתמשים ב-vSphere, האם עדכנתם את הטלאי הדחוף הזה?

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