VMWare על AWS – האם שווה להשכיר?

(אני רוצה להתחיל בהערה קטנה. אחרי שכתבתי את הפוסט על PKS קיבלתי מאנשים הערות שאני "אנטי VMware". אני לא. למען האמת, אני בשלבים של מעבר כל המכונות שלי ל-vSphere 6.7 ואני חושב שפתרון הוירטואליזציה של VMWare הוא מהטובים בשוק. יחד עם זאת, יש לי השגות לגבי חלק ממוצרי החברה ואת אותן השגות אני משתף, לא יותר מזה). נקודה נוספת: בעבר כתבתי על VMWare on AWS אבל הכל היה מבוסס על שמועות. הפעם ביקשתי מחבר שבעבודתו משתמשים במוצר להקדיש לי שעתיים ולהראות לי את התכונות ובדקתי גם את ההדגמות והקליפים הרשמיים טרם כתיבת פוסט זה.

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

לתוך הנישה הזו VMWare מוציאה "מוצר חדש" שנקרא VMWare on AWS ופתרון זה יוצר מעין "המשכיות בענן", אתה יכול להשתמש ב-SDDC Manager לנהל את הפתרון של VMware בענן יחד עם הפתרון שרץ אצלך מקומית (On Prem). אתה לא צריך לשנות מכונות וירטואליות לעבר הפתרון שלהם שרץ בענן של ה-סע"צ שבחרת, אתה פשוט מבצע Migrate של אותן מכונות וירטואליות לאותו DC מרוחק, ל-Cluster המרוחק ול-Datastore המרוחק, בוחר את הסוויצ', מאשר, וזהו – המכונות הוירטואליות בדרך לענן הציבורי. נשמע קל ופשוט, בלי הרבה כאבי ראש.. לא?

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

  • הפתרון VMWare on AWS הוא בעצם פתרון vSAN המוכר. אתם לא משלמים פר VM, אתם משלמים פר שרת פיזי ויש צורך במינימום 3 שרתים.
  • התמחור יכול להיות דינמי (פר שעה) או פר שנה או פר 3 שנים והמחיר עצמו טיפ טיפה גבוה .. אם לדוגמא אתם רוצים להקים זאת בארה"ב, בוירג'יניה, שם המחיר יהיה הכי "זול". כמה? ובכן, על 3 מכונות בסיס (נקראת i3) תשלמו 155,961 דולר לשנה. רוצים להריץ את זה בפרנקפורט, גרמניה? המחיר מטפס ל-185,952 דולר לשנה. המחיר כולל את הרשיונות ל-vSphere ו-vSAN אך אינו כולל VMWare Site recovery, ובשביל לכלול זאת יש לשלם $22,600 פלוס 347$ פר VM.
  • ישנן שתי סוגי מכונות: i3 metal, r5 metal. ה-i3 כוללת דיסקים NVME מקומיים (אחסון כולל Cache בסביבות ה-16 טרה), ואילו מכונת ה-i5 משתמשת באחסון של AWS (ה-EBS) כ-"דיסקים מקומיים", אחסון EBS אינו נכלל בסכומים שציינתי לעיל והתשלום הוא חודשי. פונקציה נוספת – Elastic vSAN (מאפשר להשתמש באחסון שבשרת גם אם אותו שרת הוא במצב תחזוקה) עולה $2.28 לשעה פר מכונה. אלו מחירים ל-3 שרתים בשרת ה"נמוך" (18 ליבות, i3-metal). אם אתם רוצים להשתמש באחסון של אמזון (EBS) ולקחת שרתים יותר רציניים (r5 metal, עם 48 ליבות) אז בוירג'יניה תצטרכו לשלם 174,411 דולר לשנה, ובפרנקפורט המחיר מטפס ל-210,396 דולר לשנה.
  • רוצים הנחות על המחיר? בשמחה, רק אם אתם משלמים מראש. אם אתם שוכרים את הברזלים ל-3 שנים מראש, יש לכם 50% הנחה. אם לשנה – 30% הנחה (לפי המסמך הזה).

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

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

אם נרכוש שלושה שרתים, בכל אחד מהם מעבד אחד AMD EPYC עם 32 ליבות (כך נחסוך במחצית את העלויות של vSphere ו-vSAN וכל מוצר אחר שמחושב Per Socket), עם חצי טרהבייט זכרון, עם 6 דיסקים NVME SSD ו-2 דיסקים NVME SSD Mixed Intense, עם כרטיס רשת של 10 ג'יגהביט, כל הרשיונות (ל-3 שנים) שצריך ולקינוח גם סוויצ' נחמד. צריכים את המערכת בגרמניה, או ארה"ב או אפילו מחוץ למשרדכם פה בארץ? חפשו ספק שמוכר שרותי COLO (כלומר Co Location) לאחסן 4U או 7U (שזה 3 שרתים, תלוי בגודלם הפיזי – פלוס סוויצ') עם רוחב פס נאה, ואתם תשלמו לו בערך 2000-4000$ לחודש.

ניקח את כל הערימה הזו ונחשב אותה – ותראו שלא תגיעו ל-$160,000 שתצטרכו לשלם בממוצע לשנה על VMWare on AWS, ובנוסף – הציוד והרשיונות הם שלכם, וזה כולל SLA לברזלים ולציוד עצמו.

אחד הדברים שחשוב להבין לגבי VMWare on AWS היא למרות שהשיווק יזכיר בכל שניה וחצי את המילה "ענן" – חוץ מהעובדה שזה יושב ב-DC של ספק ענן ציבורי, אין לפתרון הנ"ל כמעט כלום עם מה ש-סע"צ בעצם מייצג. (ה"כמעט" קשור למכונה r5 metal שמשתמשת באחסון של ספק הענן אבל זה בעצם לא ממש משנה כלום. EBS מאפשר גדילה דינמית, אבל vSAN לא יודע "לאכול" דיסק "פיזי" שגודלו השתנה). כל השירותי ענן שתשתמש בהם מתוך ה-VMware on AWS יהיו בדיוק כמו שתיקח את השרותים מבחוץ או ממכונות וירטואליות שה-סע"צ משכיר מהשרותים שלו.

הבה נסתכל על ההצעות של ה-סע"צ. רבים נוטים להתעצל ולבחור נניח מהעשיריה הראשונה של ההצעות ל-VM כדי לא להסתבך, אבל המציאות היא שכל סע"צ מציע מספר "דורות" של מכונות וירטואליות, חלק לא קטן מההצעות די זולות ויכולות להתאים למשימות שונות (הנה לדוגמא ההצעות של AWS. מיקרוסופט, לפחות ממה שבדקתי, לא מציעה טבלה כזו אז חברת Nakivo מציעה טבלה כזו עם הסברים, ובגוגל יש דף פשוט שמסביר את הסוגים. אז אם לדוגמא אתם צריכים להריץ אפליקציה שדורשת המון זכרון אך כמעט ולא עושה כלום עם המעבד, אתם יכולים לשכור Instance מדור ישן יותר ובכך לחסוך. צריכים מכונות VM שאליהן מחוברים דיסקים SSD פיזיים לוקאלית? יש. ב-VMWare on AWS אין חיה כזו – יש סוג אחד של מעבד (ישן, מלפני שלוש דורות – Xeon V4) ואין לך אפשרות לחבר SSD פיזי לוקאלית ל-VM (על VMware on AWS – כי זה מנוהל על ידי VMware).

בסופו של דבר, צריך להחליט לכאן או לכאן, האם לקחת את ההצעה של VMWare on AWS שלא ממש נותנת יתרון כלשהו לכך שהמערכת רצה בחוות שרתים של סע"צ – לבין הפתרונות ש-סע"צ מציע. נכון, אם רוצים להשתמש בפתרונות של סע"צ, ולא רוצים לבנות מכונות VM מחדש, צריך להמיר (יש לכך כלים שונים, סקריפטים ואפשר לבצע לכך אוטומציה, אגב), אבל מצד שני, ל-סע"צ יש מגוון הצעות שלא קיימות כלל ב-VMware on AWS. לעומת זאת, יש חברות שיתעקשו על "המשכיות" והמחיר לא ממש מזיז להן – אז להן VMWare on AWS יכול כנראה להתאים.

קונטיינרים ו-Windows – מאמר עדכון (2020)

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

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

וזה חתיכת כאב ראש..

באותו זמן מיקרוסופט החלה להציע דרכים להכין ולהריץ קונטיינרים, אבל רק ב-Windows Server 2019 (ובגרסאות Windows 10 היותר מתקדמות) הם הציעו באופן רשמי דרכים להריץ קונטיינרים ל-Windows (הכוונה שהקונטיינר מכיל IMAGE עם קבצים בינאריים ל-Windows). בהתחלה עם Hyper-V בצורה מבודדת (דרך מצויינת לבזבז זכרון) ואחר כך כ-Process מבודד.

העניין הוא שחברות רוצות לא רק קונטיינרים, אלא את כל ה"מסביב", אורקסטרציה, תמיכת Plugins שונים, HA ועוד ועוד – כל מה ש-Kuberentes נותן. את זה לא היה באותו זמן, ו-K8S החל להיתמך באופן רשמי ויחסית יציב – בגירסה 1.14 (אם כי יש תיקוני באגים בכל הקשור לתמיכת Windows ולכן כדאי להסתכל על גירסה 1.17 האחרונה).

בחודשים האחרונים החלו יצרני "הפצות" K8S כמו PKS של VMWare להציע גירסת בטא לתמיכת Windows Containers וגירסת Openshift הבאה תציע זאת גם. אם אתם מתכוננים להיפגש עם נציג של VMWare לגבי PKS, הוא בוודאי יציג לכם מצגת עם שקופית שמזכירה לכם ש-Windows 2008/2008R2 מסיים לקבל תמיכה רשמית השנה ולכן כדאי לנצל את העניין לעבור לקונטיינרים (אכן התמיכה מסתיימת אבל יש שמירה לאחור די רצינית בכל הקשור לתאימות בינארית, כך שאפשר להריץ את אותן אפליקציות ב-Windows 2012/2016/2019, המקסימום – תצטרכו לקמפל מול ספריות סטנדרטיות, כך שהטענה שגירסת OS הסתיימה ולכן עכשיו עכשיו חשוב לעבור לקונטיינרים – לא ממש "מחזיקה מים").

אז מה המצב כיום?

טכנית, אין בעיה להריץ K8S תחת Windows, אך כרגע Windows נתמך כ-Workers Node באופן רשמי ולכן עדיין תצטרכו מכונת לינוקס שתשמש כ-Master. אם אתם רוצים להריץ K8S מהקוד הקיים הפתוח, אתם צריכים לעבור תהליך התקנה די ארוך ומורכב שאפשר לקרוא עליו כאן (יש עוד 2 חלקים בצד שמאל, אל תדלגו עליהם). אם אתם חושבים להשתמש ב-Rancher, גירסה 2.3 תומכת ב-Windows Containers, לגבי השאר – ציינתי לעיל.

אם אתם מתכננים לממש ולהריץ קונטיינרים ל-WIndows בעננים ציבוריים, אז כל הספקים המספקים שרות הרצת קונטיינרים מנוהל כבר תומכים בכך.

הדברים החשובים לזכור ולבדוק (אם אתם מריצים K8S ב-On prem):

  • לא לשדרג את ה-Windows אוטומטית. אם מיקרוסופט מוציאה מחר Service Pack או עדכון שמעלה את גירסת ה-Windows (דוגמא: 1709 ל-1903) יכול לשבור דברים בקלות, ויכול להיות מצב שלא תוכלו להריץ קונטיינרים.
  • תמיכת Plugins – ל-K8S יש מאות Plugins שונים בתחומים שונים. ב-Windows רק חלק קטן נתמך ורץ (הם מופיעים בקישור שנתתי בפיסקת תהליך ההתקנה לעיל). כך לדוגמא, חלק מיצרני הסטורג'ים שחררו Plugins ל-K8S בכל הקשור ל-Volumes, צרו איתם קשר לראות אם הם שחררו את ה-Plugins שלהם ל-Windows. כמו כן, תמיכת CSI (כלומר: Containers Storage Interface) היא עדיין ברמת אלפא/בטא.
  • יכול להיות שה-IPS/IDS שלכם לא יאהבו את K8S ל-Windows, הואיל ובחלק מהמקרים נעשים שינויים לפאקטות. כמו כן התמיכה ב-NAT היא קצת בעייתית (תסתכלו בחלק של ה-Networking באותו קישור) – קחו את זה בחשבון לטיפול.
  • קונטיינרים ברמת privileged (אלו בדרך כלל קונטיינרים שמשפיעים על כל ה-K8S) לא יכולים כרגע לרוץ תחת Windows.
  • ניהול זכרון: בלינוקס יש תהליך (שנוא אבל הכרחי) שנקרא OOMKiller שהורג תהליכים בעת מצבים שמסתיים הזכרון. ב-Windows זה אחרת, וברגע שמסתיים הזכרון, המערכת משתמשת ב-pagefile כך שאין משהו שיהרוג תהליכים אם הזכרון מסתיים ולכן יכול להיות מצב שה-Node "יזחל" רק בגלל שאין זכרון. התיעוד מציע מספר אפשרויות, אבל כדאי לעקוב היטב במערכת הניטור לגבי זכרון במכונות Windows המריצות PKS.
  • אם אתם משתמשים ב-Flannel פלאגין לרשת K8S, כדאי לזכור שאין אפשרות לתקשורת בין Node ל-POD.
  • אבטחה – בכל מה שקשור ל-Secrets – דברים נכתבים כ-clear text ב-Node Volume. יש שתי המלצות בתיעוד – או ACL או Bitlocker, שתי פתרונות שלדעתי די עקומים אבל זה מה שיש. בנוסף – האבטחה ל-POD שהפצות K8S שונות מאפשרות תחת לינוקס (SELinux, AppArmor וכו') – לא נתמכות ב-Windows בכלל ויכול להיות שבעתיד יפותח משהו.

כל הנקודות לעיל נלקחו מהמסמך בקישור לעיל והם רלוונטיים לגירסה האחרונה (שברוב המקרים לא כלולה בהפצות K8S השונות), ולכן אני עדיין טוען: התמיכה ב-Windows היא עדיין Work In progress, זה יכול להספיק להריץ דברים פנימית שאינם פתוחים/חשופים לאינטרנט, בסביבות Testing, Staging ואפילו PROD מצומצם, אבל מומלץ לעבור עם מחלקת אבטחת מידע על כל המגבלות במסמך המקורי ולהחליט אלו קונטיינרים ל-Windows להקים ולהריץ ב-K8S, מה ממירים להרצה על לינוקס (כדאי לזכור: בתוך POD אי אפשר להריץ קונטיינרים גם מ-Windows וגם מלינוקס), ועל מה כרגע מדלגים.

לסיכום: K8S ל-Windows, למרות יצרני הפצות K8S שונות, הוא עדיין Work In Progress. יש את כל החלקים הבסיסיים, אבל חסרים לא מעט דברים חיצוניים ויש לא מעט אורות אדומים בכל מה שקשור לאבטחת מידע, ניהול זכרון, Plugins וכו' וכו'. אין שום בעיה ואפילו מומלץ – להקים מערכת K8S ולצוות אליה מכונות Windows לשרת Linux שישמש כ-Master ולהתחיל תהליכי המרה, טסטים והרצות שונות, אבל כשזה מגיע לפרודקשן, ממליץ "לעשות חושבים", גם אם מדובר בהרצת קונטיינרים לפרודקשן במערכות קונטיינרים מנוהלות ע"י ספקי ענן ציבורי.

אבטחת מידע: קצת על Cloud Hopper

בעשור האחרון בעולם חל גידול מאסיבי בשימוש בעננים. יש כמובן את שלושת האמיגוס (אמזון,גוגל,מיקרוסופט) אבל ישנן חברות רבות, כולל יצרני שרתים, ספקי Hosting שונים ברחבי העולם שהציעו שרותים שונים, החל מ-Hybrid Cloud, תשתית "רק בענן" או שימוש בשרותים שונים כ-SAAS. האמת היא שברוב החברות בארץ ובעולם, יש לפחות שימוש בשרות SAAS אחד או יותר (זוכרים שפעם שרת המייל היה יושב בארגון, לדוגמא?)

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

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

אחד הדברים המייחדים את הסינים בכל הקשור לריגול, גניבות, פריצות וכו' – זה הסדר שהם עובדים. אין "קפריזות". יש צוותים (שמוזכרים בקצרה בפוסט של Fox Business) וכל צוות אחראי על משהו אחר: צוות שאחראי על בדיקת הפריצות, על שמות משתמשים וסיסמאות שלא שונו, צוות שאחראי על מיפוי חוזר ונשנה של תשתיות החברות הנפרצות, צוות (גדול) שאחראי על התמודדויות מול אנטי-וירוסים, IPS/IDS, צוות שאחראי על כתיבת סקריפטים וכלים שונים כמו C&C, צוות שבודק פריצות חדשות שלא ידועות ציבורית, צוות שאחראי על קבלת Payload, רישומי דומיינים – ויש בוודאי עוד כמה צוותים.

הסינים לא באים לפרוץ ולגנוב. הם יריצו כלים שונים כדי למצוא פריצה, ולאחר שמצאו – הם יעבירו את הממצאים לצוות אחר. הם רוצים לפרוץ ולא מצליחים? הם לא יתקיפו ב-DDoS, הם יפנו את המטרה לצוות אחרת שיפתח ב-ריגול למצוא דרך מי הם כן יכולים לפרוץ: קבלני משנה שנותנים לאותה חברה שרותים, חברות שנותנות שרותים לאותה מטרה, חברות שנותנות שרותי Cloud לאותה מטרה וכו'. התהליך שלהם אולי איטי אבל יסודי.

פרויקט Cloud Hopper הוא פרויקט של הפורצים שמימן המשרד לבטחון הפנים הסיני. הקבוצה העיקרית שהיתה אחראית על הפרויקט נקראת APT10 וזו קבוצה סופר מתוחכמת שלא רק מכירה למי הם פורצים, הם בדרך כלל מכירים גם את רמת הידע של חברות שמנסות להגן על הלקוחות נגד פריצות וה-APT10 לא ממש ביישנים: הם יודעים מי מנסה "לצוד" אותם והם משאירים strings בכלים המותקנים על המכונות הפרוצות עם כל מיני הקנטות, כולל רמזים ללמוד איך עובד אנטי וירוס והמעקפים בכך שהם הפנו את ה-C&C לדומיין: gostudyantivirus.com ועוד (הטריק הזה אקסלוסיבי לא רק לסינים כמובן, גם החבר'ה ב-8200 ואחרים משתמשים בו)

קבוצת APT10 במסגרת Cloud Hopper החליטה למצוא לה אי שם ב-2014 מטרה חדשה: ספקי Cloud (או CSP כפי שזה מוכר יותר בשוק), לחדור אל תשתיות ה-CSP, להשיג הרשאות לתשתיות הוירטואליות של הלקוחות ופשוט להיכנס, לגנוב מידע, ולקפוץ (Hopping) מלקוח ללקוח באותה תשתית, כאשר לא מדובר בגניבה חד פעמית אלא מתמשכת.

ומי היו ה-CSP? אולי שמעתם את השמות, הכי מפורסמים הם HPE ו-IBM והיו עוד כמה עשרות CSP יותר קטנים. מי הלקוחות שנפרצו? גם כאן, אולי שמעתם עליהם: חברת Ericsson (כן, חברת התקשורת), פיליפס, חברת TATA ההודית, פוג'יטסו, ועוד רבים אחרים. המצב ב-HPE היה כל כך גרוע, שהפורצים פשוט "דרסו" כל נסיון חסימה מצד מנהלי אבטחת המידע של HPE והם נכנסו שוב ושוב לתשתית. אגב, ללקוחות ה-CSP לא הודיעו מאומה מחשש לתביעות (ואולי מחשש שהלקוח ינסה תוך שעות ספורות לעבור מיידית לספק אחר).

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

על ה-Cloud Hopper תוכלו לקרוא באתרים שונים, אבל אם יש משהו אחד שלא תמצאו שם – זה פריצה לשלושת האמיגוס. אין ספק שתוכלו למצוא מאמרים על פריצות לכל מיני מאגרים שהיו שמורים בתוך S3 Buckets שטיפשים לא הגדירו להם אבטחה מספקת, לתשתיות וירטואליות של לקוחות שהגדרות האבטחה בהן היו בדיחה – אבל לא תמצאו מאמרים על פריצות לתשתיות הפיזיות של AWS, GCP או Azure או לחלקים המאפשרים כניסה לתשתיות וירטואליות של לקוחות, מכיוון שאותה שלישיה בונה את הדברים בצורה שונה לחלוטין, משקיעה הרבה יותר מכל CSP שהחליט שזה אחלה רעיון לקרוא לעצמו "ענן", כולל השקעה בצוותים שאשכרה מנסים לפרוץ בכל דרך מבחוץ פנימה נון סטופ ומיישמים מיידית את הלקחים, במקום לסמוך על כל מיני חומות אש, IPS/IDS ו-MFA (להלן החדשות: רוב שיטות ה-MFA כבר נפרצו עוד לפני שנתיים!).

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

  • Firewall, IPS/IDS, Antivirus, Malware protection, עדכוני אבטחה – כל הדברים הללו נחמדים, אבל פורצים מקצועיים יודעים לעקוף את אותם כלים. אף אחד לא ינסה להיכנס ל-Firewall שלך ולשנות פורטים כי אין צורך בכך, וכל כלי שפורצים כותבים עובר בדיקה מול כל אנטיוירוס מסחרי אם הכלי מתגלה או לא (ואם כן אז משנים את הקוד), ולגבי IPS/IDS – ארמוז בעדינות שיש מספר דרכים לנצל חולשות שלו בתוך ה-LAN, ומדובר על רוב המוצרים המסחריים המצויים בשוק. לא קשה כל כך לזייף ב-Stream פיסות Headers.
  • כמו שמחליפים גירסת לינוקס או Windows, כדאי אחת לתקופה להחליף חלקים גדולים ממערך האבטחה – כלים, מתודות וכו'. תתחילו בשני דברים פשוטים: Zero Trust (זה מה שהשלישיה משתמשים), ו-U2F.
  • אתם מרימים תשתית וירטואלית בענן מקומי? (גם אם זה DR) – אל תתנו לאף אחד גישה ועדיף שזה יהיה על ברזלים ותשתית נפרדת שלכם, ואם צריך קו יעודי לכך שלא מחובר לתשתית של הספק בתוך ה-DC. לחשוב ש-VLAN מגן על משהו – זו בדיחה במקרה הטוב, לא מסובך לפורץ מקצועי להיכנס למתג. רק קחו בחשבון שספקים מקומיים ינתקו לכם את התקשורת אם אתם מותקפים ב-DDoS.
  • אם אתם מקימים תשתית וירטואלית אצל אחד משלישיית האמיגוס, תשתמשו בכלי אבטחה שלהם ולא בכלים צד ג'. הכלים של אותם ספקי ענן ציבורי הרבה יותר רציניים, מעודכנים תדיר (לא רק כשמגלים חור אבטחה וסוגרים אותו כמה ימים אחרי זה כמו אצל רוב הכלים המסחריים!), יכולים לבצע Scaling רציני ומנוסים שוב ושוב על ידי מאות אלפי לקוחות. להגדיר Security Groups ולחשוב שאתם מאובטחים – אתם ממש לא.
  • "התקמצנות" במפתחות פרטים/ציבוריים. רוצים לבצע Passwordless SSH? תשאירו את זה בצורה סופר מצומצמת לצרכי אוטומציה. בשאר המקרים – תקנו Yubikey ותשתמשו בו או מפתח Titan מ-גוגל. אפשר גם 2FA אבל תיזהרו לא ליפול לטריקים כאלו. זיכרו: העצלנות היא הגורם מספר אחד לפריצות קלות.
  • בעננים ציבוריים במיוחד – אף ספק ענן ציבורי לא נותן לך אבטחה כברירת מחדל ולכן תצטרך להשתמש בשרותים שלהם לצרכים אלו, ב-AWS יש רשימה שלמה, תעברו עליה, תבחרו ותגדירו את מה שאתם צריכים (הנה גם ל-Azure, אל תאכלו לי את הראש)
  • אני ממליץ לחשוב מחדש (לכיוון ויתור) על שירותי ניהול מרוחקים. אתם יכולים להגן על התשתית שלכם כמה שתרצו אבל אם עובד משרותי הניהול הוא סופר אהבל ופורצים למחשב הנייד/נייח שלו – ההגנות שלכם לא שוות כלום ומכיוון שיש לו הרשאות admin ברוב המקרים (כי הם מנהלים את התשתית) – יהיו לפורץ את אותן ההרשאות.
  • בדיקות Pen testing זה נחמד, אבל זה עובד מול שורת פריצות ופרמטרים ידועים מראש בתוך הכלי. רוצים להיות יותר בטוחים שאתם מוגנים? תשכרו מישהו שאשכרה ינסה לפרוץ בצורות קצת יותר .. מקוריות.

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

על AWS וחסכון: Lightsail

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

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

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

מצד שני, אם יש לי בלוג גדול שבו אני מציג תכנים רבים ואני צריך שרידות גבוהה, אז אני יכול לבנות את המערכת כך (נניח ומדובר על שלושה שרתים):

  • 3 שרתי לינוקס שמריצים WordPress עם מפרט נמוך 2-4 ליבות, 2-4 ג'י'גהבייט זכרון.
  • ה-DB לא ירוץ באותן מכונות, הוא ירוץ משרות ה-DB המנוהל ש-AWS מציעים – אפשר לבחור עם או בלי שרידות, כך שכל מה שאצטרך לעשות זה להגדיר את ה-DB בוורדפרס.
  • התכנים ישבו ב-DB והתמונות ישבו ב-S3 (שימוש ב-S3 מחייב תשלום נפרד על האחסון ועל התעבורה)
  • שרות Load Balancing מנוהל שמוצע במסגרת ה-Lightsail (עלות: $18 בחודש)
  • את הסינכרון בין השרתים אני יכול לבצע דרך GIT עם פקודות אוטומציה להוריד ולסנכרן מול הדיסק המקומי של המכונה. עלות: 0.
  • פעם בשבוע או בחודש אני יכול להוריד מכונה אחת, ליצור Snapshot כגיבוי ואם צריך – לבנות מה-snapshot מכונה חדשה.

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

עם Lightsail לא תוכל (ברמה העקרונית) להשתמש ברוב השרותים ש-AWS מציע אלא אם תריץ חיבור VPC Peering בין המכונות שנמצאות ב-Lightsail לבין ה-VPC שמוגדר לך בחשבון או שאתה בנית.

אסכם כך הדברים: Lightsail בעקרון מגיע כפתרון תחרותי מול ספקי ה-Hosting השונים ובמחירים מאוד מפתים. הפתרון הזה מתאים לדוגמא לי, כי אני מחפש "נראות חיצונית" לעסק שלי ולבלוגים שלי, והמחיר שאני משלם בחודש ($20) הוא ידוע וקבוע. הפתרון יכול להתאים גם לאחרים, כל עוד הם מחפשים מכונות לא חזקות, עם מפרט קבוע ומחיר קבוע – עבור לקוחותיהם לדוגמא, אך Lightsail אינו מתאים משאבי עיבוד גבוהים בצורה קבועה, ולמי שמחפש להקים מכונות וירטואליות זמניות (מה לעשות, עם Lightsail, הרמת מכונה רק ל-5 דקות, אתה חייב לשלם על כל החודש). אם אתם מחפשים להשתמש בכלים המתקדמים של AWS, חברו את המכונות הוירטואליות ב-Lightsail אל ה-VPC שלכם שבניתם או שבכלל תשתמשו ב-Instances של EC2.

תשתית מקומית וענן: חסכון – צו השעה

כמעט בכל חברה מגיע מצב שאחת הסיטואציות הבאות מתרחשות:

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

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

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

אז איך בעצם ניתן לחסוך?

בכל הקשור לתשתית מקומית, ההמלצה שלי במקרים רבים היא לפני שאצים רצים לרכוש שרתים חדשים לדוגמא, לשדרג את הקיימים. תחליפו מעבדים לכאלו עם יותר ליבות, תוסיפו זכרון, אם אתם עובדים עם דיסקים מקומיים – תחליפו אותם ל-SSD טובים וכו'. אם לדוגמא רכשתם (בחוכמה) שרתים כמו של חברת SuperMicro, אז אתם בכלל יכולים לעבור קדימה דור של מעבדים (לדוגמא: V3 ל-V4 או Xeon SP דור ראשון לדור שני) – כלומר בלא מעט מקרים ניתן לשדרג תשתית קיימת של שרתים ולהרוויח ביצועים יותר גבוהים, וזאת במחיר קטן בהרבה מרכישת שרת חדש (מה גם שהשדרוג נתמך לחלוטין על ידי היצרן והמפיץ)

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

על מנת לחסוך בענן הציבורי, כדאי לבצע מספר דברים:

  • להפסיק לחשוב על הענן הציבורי כ-DC פרטי שלנו. ב-VMware, כשמקימים מכונה מקומית וכשאתה מגדיר VM עם 16 ליבות או חצי טרה אחסון (ב-Thin Provisioning) – אז המערכת תהיה מספיק חכמה לתת לך משאבים, אבל לא לחסום את המשאבים הללו משימוש מכונות VM אחרות. בענן ציבורי – אתה משלם על כך, גם אם השתמש באחסון ב-2% ובמעבד ב-4%, אתה תשלם כאילו ניצלת את הכל, אז במקרים כאלו, כדאי לשנות Instance או לבנות אותה מחדש עם משאבים יותר מצומצמים.
  • לנטר ולצמצם – כלים כמו Terraform יודעים היטב לתמוך בכל ספקי הענן הציבורי. נכון, זה לא בדיוק "קליק קליק קליק" אבל בהחלט שווה להשקיע וללמוד ואז להתחיל להריץ את זה על החשבון שלכם ולמצוא מה המשאבים שאינם מנוצלים, דברים שהוגדרו בפראות אבל לא ממש משומשים וכו' – ומשם להחליט מה לעשות עם זה. החסכון בשיטה הזו – גדול מאוד.
  • להפסיק להתעצל! אתה צריך SQL שכל מה שמתחבר אליו זה client ורבע? תקים קונטיינר או Instance כזה בעצמך במקום להשתמש בשרות מנוהל. זה יותר זול. נכון, צריך להשקיע קצת יותר בהקמה והגדרה, אבל זה חוסך בטווח הארוך.
  • לעבור לקונטיינרים במקום מכונות וירטואליות – קונטיינר תופס פחות משאבים, ניתן לרפלק, ויש לו Scaling מעולה. אה, ובחישוב סופי, זה יוצא יותר זול.
  • לבחור תוכנות אחרות שהן יותר "Native" לענן – תוכנות שיודעות לאחסן ב-Object Storage לדוגמא, שהוא הרבה יותר זול מאחסון שמחובר ל-Instance, וזו רק דוגמא אחת.
  • לכבות מכונות – מכונה כבויה עולה הרבה פחות ממכונה פעילה (אתה עדיין צריך לשלם על האחסון שהיא תופסת), אז אולי הגיע הזמן לאיזה סקריפט קטן שרץ על כל המכונות ומכבה כאלו שלא עושות כלום, ואגב, עדיף להגדיר עם Terraform שמכונות מסויימות יכובו אוטומטית (או ימחקו) לאחר זמן מה, כמו מכונות טסטים שהוקמו זמנית ושכחו מהן.

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

עננים ציבוריים מקומיים מול עננים ציבוריים אמיתיים

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

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

נדמיין עתה מצב תיאורתי שבו החלטתי להתחרות בכולם. אני משיג VC נחמדים ומשכנע אותם להשקיע בעסק שלי סכום נחמד של 8 ספרות (בדולרים). אני רוכש כמה עשרות ארונות, מפזר אותם בין ספקי האינטרנט השונים בארץ, "מפוצץ" את כולם בשרתים חדשים ואני מקים בדרך SDN ו-Software defined storage מפלצתי. על כל התשתית הזו אני מקים מערכת שתתן ללקוחות דרך ממשק WEB ודרך API את השרותים הבאים:

וירטואליזציה, קונטיינרים (עצמאית, ללא צורך בהקמת מכונות וירטואליות), Serverless, הקמת "ברזלים" יעודיים ללקוח, שרותי Object Storage ו-Block Storage, שרותי NFS/CIFS יעודיים לרשת שלך בלבד, שרות רשת פרטית משלך (כמו VPC), שרותי Load Balancer, שרותי DNS, שרותי identity, שרותי Imaging למכונות VM שלך, שרותי אורקסטרציה, שרותי Messaging, שרותי התראות, שמירת משאבים וחלוקתם על ידי הלקוח, אורקסטרציית קונטיינרים, ביג דאטה, שירותי גיבוי, שחזור ו-DR, תאימות ל-EC2 (כפרוקסי), מטריקות, ניטור מלא של הכל, שרותי Event (כמו Cloud trail), שרותי Governance ושרות יחודי של Benchmarks, וכמובן – שרותי Billing ו-Chargeback – וכל זה זמין ביום הראשון. תירשם, תכניס פרטי כרטיס אשראי וצא לדרך.

אתם מוזמנים לחפש ספק, כל ספק בארץ, שיכול להציע לכם את השרותים הללו באופן מיידי. הם ישמחו להציע לכם את זה – כפרויקט, שמישהו ירים, תשלמו על הקמה והגדרות וכו' וכו'. פה אני מדבר על משהו שיהיה זמין דרך ה-WEB ודרך API. אני משער שהחברים ב-8200 צוחקים כי הם מבינים על איזו מערכת אני מתבסס (Openstack).

ספקי ענן מקומיים, בניגוד לספקי ענן ציבוריים גדולים – יכולים להציע כמות מוגבלת מאוד של שרותים, ובנוסף – לא יהיה לכם מושג מה תקבלו מבחינת ביצועים (לא מאמינים? קחו את החוזה מול הספק שלכם, חפשו את המילים CPU Pinning או התחייבות לגבי ביצועי Compute, סטורג' וכו'. אני מאמין שלא תמצאו את זה מוזכר במסמכים). טכנית, אם ניקח לדוגמא שרת עם 16 ליבות, אין שום מגבלה שיכולה למנוע הרצה של מכונה וירטואלית עם 32 ליבות. אתה כלקוח יכול לבדוק אם זה מה שאתה מקבל אם תריץ אפליקציית Benchmark כלשהי שוב ושוב במשך כמה ימים ותוציא את הפלט לקובץ ואז תוכל להשוות .. ולהתעצבן.

אצל ספקי ענן ציבוריים אין את המשחקים הללו. סע"צ קובע מה יהיו משאבים של VCPU (כלומר CPU וירטואלי) ואותם תקבל כל הזמן, בדיוק את אותם משאבים שירוצו באותה מהירות. אותו דבר לגבי סטורג' – אתה בוחר סוג עם התחייבות למסגרת IOPS (כלומר שנעה בין X ל-Y אך לא מעבר לכך) או ל-IOPS קבוע (דיסקים מגנטיים לדוגמא). בארץ, כלקוח, לא תמצא התחייבות כזו.

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

לסיכום, אני ממליץ לחשוב על 2 דברים חשובים:

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

כמה מילים על קונטיינרים "מבחוץ"

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

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

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

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

הפצות לינוקס כמו רד-האט, CentOS, SuSE, אורקל לינוקס, דביאן, אובונטו וכו' – נבנית בכל פעם מאפס על ידי הידור קוד של חבילות שונות עד שנבנית הפצה בסיסית לחלוטין. להפצה הזו המערכת תעשה Boot, ומשם היא תמשיך להדר את הקוד של כל החבילות שונות (ב-רד-האט, או כל הפצה מבוססת RPM יש חבילות מיוחדות שנקראות SRPM שמכילות קוד מקור + טלאים וסקריפטים כדי לקמפל אותה). ההפצה כוללת חבילות שונות מבחוץ שעברו בתוך יצרן ההפצה בדיקת קוד וברוב המקרים גם שינויים על מנת לרוץ על אותה הפצת לינוקס ספציפית.

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

בחברות גדולות (כמו בנקים וכו') בדרך כלל לא פותחים את חומת האש להורדת חבילות מיצרן ההפצה באופן ישיר ומשתמשים בתוכנת-אמצע (Middleware) כמו Red Hat Satellite כדי להתקין את ההפצות ועדכונים על שרתים ומחשבים נוספים. ברוב המקומות האחרים שאינם עובדים ישירות מול רד-האט או עובדים עם הפצות אחרות, יש כלי אחר חינמי ובקוד פתוח כמו SpaceWalk שמאפשר להפיץ פנימית בשרתי החברה (ובחשבון הפרטי בענן הציבורי של החברה) עדכוני תוכנה בצורה מאובטחת ומוצפנת (אפשר לשלב בתוך הכלי גם את ה-CA של החברה).

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

איך? די פשוט. כמעט בכל קונטיינר שמופיע ב-Repository ציבורי (כמו Docker Hub) אנחנו נמצא קישור ל-Github שמכיל את קוד ה-Dockerfile. נוריד את קבצי ה-Dockerfile ואחרים מה-git (פקודת git checkout) ואז פשוט נבנה את הקונטיינר מחדש. היתרון הגדול בבניית הקונטיינר מחדש הוא בכך שחבילות רבות מקבלות עדכוני אבטחה וקונטיינרים הזמינים ב-repo ציבורי לא תמיד מעודכנים, וכך נוכל לבנות אותם עם הגרסאות המעודכנות עם תיקוני אבטחה ומה שיותר חשוב – החבילות מגיעות ממקום ידוע (אם משתמשים ב-spacewalk – אז הם מגיעים משרת פנימי בחברה שהוריד את החבילות ממקור בטוח), ואפשר כמובן לאחסן את אותם קונטיינרים ב-Registry פרטי פנימי (הנה הוראות איך להקים אחד באובונטו).

במקרים מסויימים ה-Dockerfile כולל פקודת COPY וקבצי המקור אינם נמצאים ב-repo באותו git. התייחסו במשנה זהירות לקונטיינרים מסוג זה, ובמקרים כאלו אם אתם ממש צריכים את הקונטיינר הספציפי, אולי כדאי להריץ עליו סריקה עם אחד הכלים שהזכרתי לעיל.

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

הבעיות של היום ומחר – עם פתרונות של אתמול ושלשום

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

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

לאחר קריאת החוברת או ההמלצות – אני מחזיר תשובה לפונה, בדרך כלל התשובה תהיה אחת משלושת האופציות הבאות:

  • ההמלצות טובות ונכונות (אם יהיו לי הערות או נקודות מסויימות – אציין אותן)
  • הרעיון העקרוני בהמלצות נכון, אבל מומלץ לשלב פלטפורמות X,Y וטכנולוגיות A,B.
  • אתם שילמתם על היעוץ הזה? ברצינות? אתם נמצאים בשנות ה-90 או ה-2000 או מה?

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

להלן שתי דוגמאות, מהחודשים האחרונים:

  • חברה מסויימת רצתה להריץ פלטפורמה מסויימת על לינוקס מספר רב של פעמים. המערכת אמורה להיות פתוחה לרשת וההפניות יועברו דרך Load Balancer (אני לא יכול לפרט עקב הסכמי סודיות). היעוץ שהם קיבלו: לרכוש 18 שרתים עם מפרט די "כבד", רכישה של Load Balancer חומרתי, סטורג' מפלצתי, לכל הברזלים רשיון VMWare Enterprise.
    ההצעה שלי (שהתקבלה): במקום 18 שרתים עם מפרט כבד, 2 שרתים עם מפרט נמוך, 4 שרתים עם מפרט כבד (יחסית, הרבה זכרון), מערכת OpenShift, ושרת נוסף קטן שיריץ ESXI כדי להריץ 2 מכונות VM שמריצות Windows. סטורג' – או בניה או לרכוש משהו קטן מכיוון שאין צורך ב-IOPS רציני או כמות אחסון גדולה. הפלטפורמה תרוץ כולה על קונטיינרים, ובהתבסס על הסטטיסטיקה שנמסרה לי, אני מתקשה להאמין שתהיה צריכת משאבים של יותר מ-40% בכל השרתים.
  • חברת מדיה מסויימת רצתה לאחסן תכנים רבים ולהערכתם הם יגדלו בכל שנה בסביבות ה-100-150 טרהבייט. הדרישה – אפשרות גדילה ללא SPOF (כלומר: Single Point of Failure) ומבלי לרדת בכמות רוחב הפס הפנימי, אדרבא – אם אפשר שתהיה גדולה יותר ויותר – הם ישמחו. כאן לא היתה חברה מסויימת שנתנה יעוץ, אלא החברה ביקשה מכל מפיצי הסטורג'ים הגדולים והמוכרים בארץ, ואני התבקשתי להמליץ על אחת מההצעות.
    הבעיה: אף הצעה לא כללה פתרון אחסון Scale Out. כל ההצעות היו פחות או יותר "תוסיף מדף" ובקשר לשרידות – קנה שתי ראשים. לפיכך המלצתי הפשוטה (שהתקבלה) היתה: זרקו את ההצעות ובקשו או פתרון Scale Out או לבנות פתרון Scale Out מבוסס קוד פתוח או תוכנה סגורה שמציעות יצרני שרתים וחברות אחרות, ורשת עם Backbone של 40 ג'יגהביט שיגדלו בהמשך לכיוון ה-100 ג'יגהביט.

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

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

קצת על Scale Out עם פלטפורמות יעודיות

בשנים האחרונות אנחנו עדים ליותר ויותר פלטפורמות שעובדות בשיטות של Scale Out. הפלטפורמה הכי ידועה לדברים כאלו היא כמובן Kubernetes, אך כמובן שישנן פלטפורמות אחרות שקשורות יותר לעיבוד נתונים – Kafka או Cassandra לדוגמא, כל אחת מהן פלטפורמה לצרכים שונים, אבל מבחינת צרכי חומרה, הצרכים הם פחות או יותר זהים: מעבדים בינוניים (לא צריך כמות מפוצצת של ליבות, יספיקו 8-16), ולא צריך דיסקים (קשיחים או SSD) יקרים.

כלומר – אם אתה צריך להריץ פלטפורמה שעובדת ב-Scale Out מקומית בתשתית שלך, אל תנסה לחפש את היוקרתי עם כל מילות הבאז האחרונות, אלא ההיפך – מי הספק שיכול לתת לך את ההצעה הכי זולה שתעמוד במפרט שנקבע מראש, SLA שאתה צריך וכו'. ב-Scale Out אין את מושגי השרידות מעולם ה-Scale Up. אין Heart beat, אין Active/Passive, Active/Active וכו'. עם Scale Out בדרך כלל הפלטפורמה תהיה בנויה כך שאם שרת למטה/אינו זמין/אינו פעיל, המערכת תאזן את עצמה אוטומטית (למי שמשתמש ב-Kubernetes ורוצה לראות זאת – תורידו Node ותראו איך זה עובד).

מכיוון שפתרונות Scale Out תופסים יותר ויותר תאוצה, פתרונות Scale Up כמו סטורג'ים קנייניים, מנסים "לתפוס טרמפ" על הטרנד (כמה שאפשר לקרוא לזה כך). מריץ Kubernetes? הפתרון שלנו יודע לתמוך בווליומים, ובאחסון כזה וכזה, ובוודאי שהיא מתאימה לאחסון עבור פתרונות Scale Out!

וזהו – שההצהרה לעיל נכונה רק בחלק מהמקרים. אם אתה מריץ יותר מ-5-10 שרתי Cassandra או Kafka כפרודקשן ואתה מכניס דרך ה"מפיקים" (Producers) המון מידע שמגיע ממאות/אלפי חיישנים או מקורות שונים, הסטורג' הקנייני יהפך די מהר לצוואר הבקבוק.

אחת השגיאות שאפשר לראות בפורומים שונים, זה שאנשים שעובדים עם פתרונות Scale Out מחפשים איך לאחסן את כמות הנתונים שהולכת וגודלת והם עדיין לא מכירים/מבינים את עניין ההוספה המתמדת של ברזלים ודיסקים מקומיים – והם תמיד יקבלו את הצעות הפתרונות שמתאימים ל-Scale Up: לתכנן את הגדילה למשך שנה וכו' וכו' ואז לבחור סטורג'. זו טעות, כי בעולם המדידות/דגימות ושימוש בפלטפורמות Scale Out אתה מחפש לקבל כמה שיותר מידע, לא כמה שפחות, ויכול להיות שהחודש הקרוב אתה תוסיף עוד 4 טרה מידע לחודש אבל בעוד 3 חודשים זה יקפוץ ל-15 טרה לחודש. בגדלים כאלו, שום פתרון סטורג' קנייני אינו מתאים, אלא אם רוצים "לשרוף" את תקציב החברה, ולכן יש צורך ללכת לפי הפתרון של הפלטפורמה, לא לפי שם/דגם של סטורג'.

ולכן:

  • אם הולכים להשתמש בפלטפורמה שהיא בראש ובראשונה Scale Out לצרכי עיבוד נתונים/קליטת נתונים – נצטרך דיסקים ושרת מהקצה הנמוך-בינוני, מבלי להשקיע יותר מדי כספים פר ברזל (קחו דיסקים בסיסיים, בפוסט קרוב אסביר לגבי הגדרות אחסון מקומי למערכות כמו Kafka ו-Cassandra), (אגב, אם אתם רוצים להריץ Kafka בענן, אמזון לדוגמא שמחה להציע לכם את MSK).
  • אם אנחנו רוצים לשמור כמות גדולה מאוד של מידע לאחר עיבוד או ארכיבאי כשהכמות גודלת כל הזמן, או שאנחנו צריכים Object Storage – פתרון אחסון Scale Out (כמו Gluster) יתאים יותר לשימושים הללו מכיוון שעלות הגדילה היא זולה, והביצועים גודלים ככל שמוסיפים ברזלים לאותו אחסון.

לסיכום: בעולם ה-Enterprise, הסטורג' הקנייני היה ה-דבר הכי חשוב וקריטי. אין סטורג', שום דבר לא פועל. מאז הגיעו ספקי הענן הציבורי הגדולים שהכריזו שאצלם אין ולא יהיה שום סטורג' מרכזי, ובמקביל התפתחו יותר ויותר פלטפורמות שמחזירות את השימוש בדיסקים מקומיים ומאפשרות לבנות אחסון מדיסקים זולים וממשאבים צנועים, וזהו בדיוק החלק שבמחלקות ה-IT או ה-CIO/CTO צריכים להבין: אל תנסו לכפות פתרון Scale Up על פתרון Scale Out.

קצת לפני שמכריזים על זוכה במכרז

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

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

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

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

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

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

  • לא לרכוש את השרות כ-SAAS (שימו לב: אני לא מדבר על מחיר). כשספק ענן ציבורי מציע שרות כ-SAAS, אתם יודעים שאותו ספק יהיה קיים ב-3-5 השנים הקרובות ולכן שרותי ענן שונים בתצורת SAAS אין בעיה לשכור אותם, אולם כשחברה בונה לך פתרון ומנגישה לך אותו כ-SAAS, אותה משרד/חברה מכניסה את עצמה למצב של "בת ערובה" אם בהמשך אין הסכמה על מחירים, או אם המשרד/גוף לא מרוצים מהביצועים, לדוגמא.
    אני רוצה לסייג: אם אתם צריכים לרכוש Firewall או כל אפליקציה שכוללת OS לינוקסאי דרך ה-Market של ספק הענן זה בסדר, אבל אם זה משהו שמפותח עבורכם – בקשו שיתקינו את הדברים על התשתית הוירטואלית שלכם, מקומית או בחשבון ענן שלכם.
  • על מה זה רץ? ברוב המקרים כיום הפיתוח של פתרון עבורכם יבוצע תוך שימוש בפלטרפורמה כזו או אחרת. חשוב מאוד לבדוק איזו פלטפורמה ואיזו גירסה, האם יש בה שימוש כיום, האם יש קליפים או עדויות לגבי אותה פלטפורמה? מתי עדכנו אותה לאחרונה? הדבר האחרון שאתם רוצים זה שספק מציע ישתמש במשהו ישן שכבר כמעט מת – בשביל לבנות עבורכם את מה שהנכם מבקשים.
  • חישובי ענן ציבורי. אם השרות שאתם רוצים צריך לרוץ על ספק ענן ציבורי, עדיף שהחברה/גוף המבקש הצעות יבקש הקמה על התשתית בחשבון הענן שלו ועדיף לבדוק היטב מה יש בסעיפי התמיכה. כך לדוגמא, רבים כשעוברים לענן מחפשים לקחת את שרותי התמיכה היקרים ביותר (24/7 פלטינום או כל שם אחר) מבלי להבין שבמקרה ויש תקלה והיא קיימת לא רק בחשבון החברה אלא גם אצל אחרים – לא תקבלו שרות יותר מהיר ותצטרכו לחכות לפתרון התקלה כמו כולם.
  • אם כבר מדברים על חישובי ענן ציבורי: שרותים. ספקי ענן ציבורי מציעים שרותים שונים שהם אבולוציוניים, כלומר – בהתחלה הוצעה שרות בשם X, לאחר זמן מה הוצע שרות Y שהוא בעצם "אבולוציה" של שרות X וכו'. במקרים רבים יש גם הפרשי מחיר ניכרים בין השרותים וגם הבדלי ביצועים רציניים, אך הבעיה היא שמציעים גדולים לא ממש טורחים (לא ממש באשמתם כש-AWS מציעים כמעט כל יום שרותים חדשים) להכיר את השרותים השונים ולכן כדאי לראות מה יש בהצעה ולהחליף בשרותים מודרניים יותר או במקרים מסוימים אם יש את הידע – להקים את הדברים עצמאית בתשתית הענן.
  • גישה לקוד מקור ותיעודו: כיום כשמפתחים לענן ציבורי ומשתמשים בפלטפורמות/ספריות שונות, ברוב המקרים הקוד עצמו פתוח וזמין וכדאי להחיל זאת גם לדברים שמפותחים עבור משרדים/גופים/חברות – המציע הולך לפתח עבורך משהו? דרוש את קוד המקור ותיעוד API ודברים שונים ששונו.
  • אבטחה: תמיד חשוב לזכור – ענן ציבורי נותן אפס אבטחה. אפשר לשכור שרותים שונים ולבצע הגדרות שונות כדי לקבל אבטחה ברמה טובה, אבל זה לא מגיע כברירת מחדל ולא בחינם. כדאי שגוף חיצוני (לא מטעם המציע) יבדוק את המערכת, ואם יש תקציב – לבצע Code Auditing.

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