קטגוריה: לינוקס

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

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

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

רמות 1-3 (ושאר רמות) הן דרך מצוינת "לחלוב" מעסקים כספים. ככל שהרמה עולה, אתה משלם יותר. בעולם הלינוקס לדוגמא, רמות לא קיימות. כשאתה קונה לדוגמא SLES או RHEL, אז אתה מקבל תמיכה על גירסת הלינוקס שרכשת (בהמשך אכנס ליתרונות ולחסרונות). אם התמיכה בחבילה שרכשת אינה מספקת לסיטואציה שלך, אז אתה יכול לרכוש שרותי Incident או Consulting (כל חברה והמושגים שלה) שבה אתה תשלם כמה מאות דולרים לשעה, ויצרן ההפצה יקדיש לך מישהו שישב על המערכת שלה למצוא מה התקלה ואיך לפתור אותה. היכן יש רמות בעולם הלינוקס? ברמת הדחיפות. אם ניקח לדוגמא את רמות התמיכה של Red Hat, נוכל לראות שיש רמות ב-SLA. רוצה שרות טלפוני? שלם 800$ פר עותק הפצה. רוצה שרות מהיר? המחיר קופץ ל-1500$ פר עותק (שוב, המחירים אינם כוללים מצבים שבהם מהנדס מוצמד לעסק שלך לפתור את הבעיה, שם התשלום ליצרן ההפצה הוא בנפרד ממה ששילמת על ההפצה).

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

כשזה מגיע לעסקים וחברות שמריצים עשרות/מאות/אלפי מכונות לינוקס לעומת זאת, אין יתרון ברכישת מנוי שנתי לתמיכה של יצרן ההפצה. בעסקים וחברות, ברוב המקרים התוכנות שמריצים על הלינוקס – הן יותר חדשות ממה שמגיעים עם ההפצה. לדוגמא, גירסת PHP שמגיעה בהפצת RHEL 7.4 היא גירסה 5.4.16 כאשר הגירסה היציבה היום לפי אתר PHP היא 7.1.10. אם תתקין את 7.1.10 על ה-RHEL ויהיו לך בעיות שה-PHP לא מצליח לרוץ, רד-האט לא תתן לך שרות הואיל והם נותנים אך ורק שרות לחבילות שהגיעו עם ההפצה עצמה, לא מ-REPO נוספים. דוגמא נוספת: רוצה להשתמש ב-NodeJS? הגירסה שקיימת היום ב-EPEL REPO היא אכן גירסת ה-LTS האחרונה, אבל שוב – מכיוון שזה REPO חיצוני, אין תמיכה רשמית מצד רד-האט.

לכן אני ממליץ לחברות לחשוב על כמה נקודות:

  • אם יש בחברתכם IT שנותן תמיכת לינוקס, ואתם חושבים במהלך השנה להכניס טכנולוגיה/פלטפורמה חדשה – קחו יעוץ חיצוני (גם אם זה לשעות בודדות) שמכיר את הטכנולוגיה החדשה. חבל שתשרפו עשרות שעות על תקלות שהיועץ החיצוני כבר מכיר.
  • אם בחברתכם יש חובה להשתמש בהפצה מקורית (RHEL או SLES) ואתם רוצים עדכונים, אז מומלץ לחשוב על רשיונות SuSE Linux Enterprise עם Expanded Support – זה יתן לכם עדכונים גם ל-RHEL וגם ל-SUSE וזה גם יותר זול מ-RHEL מבחינת רישוי שנתי.
  • כיום כמעט בכל פרויקט לינוקס, החבילות מגיעות מבחוץ (Github או REPO חיצוניים) אינן נתמכות ע"י יצרן ההפצה ולכן אם אין לכם צוות לינוקס בחברה שיכול לבצע אינטגרציה במסגרת הזמן שאתם רוצים – קחו יעוץ חיצוני (כדאי לסכם שיכתבו עבורכם תיעוד).
  • אם אתם משתמשים (או חושבים לעבור) לאובונטו, עדיף לרכוש בנק שעות חודשי ליעוץ מומחה.

קונים/מטמיעים שרתים? כדאי שתקראו

ברוב החברות, עד שהם רוכשים שרתים אפשר לפתוח בקבוק שמפניה. רוב החברות רוכשות שרתים אחת לכמה שנים ועם כניסת טכנולוגיות הוירטואליזציה השונות, כמות השרתים הנרכשת – קטנה. אחרי הכל, הרבה יותר קל וזול לדחוף עוד כמה עשרות ג'יגהבייט זכרון לשרת ואולי להוסיף/לשדרג מעבדים מאשר לרכוש ברזל חדש (האמת שיש לי בנושא ויכוח עם כמה אנשי IT. אחרי הכל, שרתים בסיסיים שכוללים 2 מעבדים 4 או 8 ליבות ו-16 ג'יגה זכרון + 2 דיסקים SATA – לעיתים יותר זולים משדרוג שרת קיים, תלוי בגודל השדרוג) – בתחום הזה כל חברה מחליטה לעצמה איך ולאן מתקדמים.

תחום השרתים עצמו די מתפתח. היו לנו שרתי Blade (זוכרים?) וכיום יש מחברות כמו SuperMicro שרתים שהם Twin שהם 2 או 4 שרתים במארז 2U או 4U (בהתאמה) וחברות אחרות גם העתיקו את הטכנולוגיה. היום גם ניתן להכניס דיסקים SSD PCI שעברו דיאטה רצחנית והם בעובי 7 מ"מ וניתן להכניס בין 10-15 דיסקים כאלו במארז 1U (תלוי ביצרן). מבחינה פנימית – כל יצרן בנה לעצמו פתרונות (שחלקם הגדול די קנייני) על מנת לבדל את מוצריו מהמתחרים. חלק מהפתרונות לדעתי תמוהים, חלק מעניינים – אבל ברוב המקרים הטכנולוגיה סגורה. קחו לדוגמא את HP – תכניסו דיסקים שאינם של HP (שבעצמם כלל לא מייצרים דיסקים) ותקבלו הודעה מעצבנת שהדיסקים אמנם יעבדו אבל אם תהיה תקלה – לא תקבלו LED אדום על אותו דיסק. בשבילי כאחד שעוקב כמעט מדי יום לגבי טכנולוגיות חדשות כמעט בכל סוג חומרה – זה מעצבן, כי תמיד יש פתרונות חדשים במחירים מעניינים. בשביל חברות – זה כלל אינו ISSUE, הם פשוט יקנו את הדיסקים מיצרן השרת וישלמו עוד כמה אלפי דולרים. בגלל זה אני מעדיף שרתים "לבנים" מיצרנים כמו TYAN, SuperMicro, ASRockRack, Gigabyte ו-ASUS (האחרונים יותר מייצרים לוחות אם מאשר שרתים מוכנים ללקוח).

ישנה נקודה חשובה שלצערי אינה ידועה רבות כשרוכשים שרתים חדשים: לא מומלץ להכניס אותם ל-DMZ שלכם. מדוע? אסביר.

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

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

כדי לראות את הבעיה בזמן אמת, אתם מוזמנים לבצע את התרגיל הבא מול חוות השרתים שלכם: בחרו לכם מספר שרתים מיצרנים שונים, בדקו גירסאות BIOS/UEFI והשוו את מספר הגירסה למספר הגירסה שמופיעה באתר היצרן. מהיכרות שלי: בסביבות ה-50-70% מהמקרים, השרת אינו מעודכן לקושחות ול-UEFI/BIOS האחרונים (הסיבה שאני שומע הכי הרבה: "זה רץ, אז למה לנסות להתקין דברים חדשים?". התשובה שלי: אבטחה).

ישנם לעיתים חורי אבטחה ממש גדולים. קחו לדוגמא את ה-Management Engine של אינטל שנמצא בכל שרת ובכל תחנת עבודה (שכוללים את הדרייברים של אינטל). משנת 2010 ישנו חור אבטחה רציני שתוקף יכול להגיע אל ה-Management Engine (שנמצא כחומרה בתוך המכונה), להשתלט עליו ולעקוב אחרי מה שקורה במכונה במקרה הקל או להזיק לדברים שרצים במכונה במקרה היותר גרוע. שום פירמוט או החלפת דיסקים לא יעזרו. תצטרכו להשתלט על ה-Management Engine מחדש על מנת לפתור את הבעיה. לאינטל לקח 7 שנים עד שבחודש מאי הם שחררו עדכון. החור קיים ב- Intel's Active Management Technology (AMT), Standard Manageability (ISM) ,Small Business Technology (SBT) מגירסאות 6 עד 11.6. האם עדכנתם אצלכם את השרתים לחסום את הפירצה הזו? (אפשר לקרוא עוד על כך כאן)

לכן, ההמלצה שלי בנושא DMZ לדוגמא, היא הכנסת שרתים ישנים יותר (נניח דור אחד אחורה או יותר) מאשר הכנסת שרתים שיצאו זה עתה לשוק. שרתים אלו נבחנו ע"י גופים רבים, עדכונים רבים יצאו וסביר להניח שהם יהיו יותר מוגנים מבחינת קושחות ו-UEFI/BIOS (לא לשכוח לעדכן את ה-UEFI/BIOS לגירסה האחרונה לפני שמכניסים את השרתים ל-DMZ).

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

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

נקודות חשובות בשדרוג ל-CentOS 7.4

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

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

כמו תמיד, בגרסאות עדכון Minor ישנם שינויים רבים בהפצה, אך שינויים אלו עדיין שומרים על תאימות בינארית, תאימות קבצי הגדרות וכו'. יחד עם זאת, בחלק מהמקרים מעדיפים ברד-האט (ונגזר מזה גם ב-CentOS) לשדרג חבילות מסויימות לגרסאות Major מתקדמות יותר ובלבד שתשאר התאימות. הסיבה לכך היא שהפצת לינוקס (בניגוד לגירסת Windows) כוללת אלפי חבילות (וזאת לפני הפעלת מאגר תוכנות מומלץ כמו EPEL) ואין לרד-האט את המשאבים לעקוב אחרי כל החבילות וליישם Backporting של עדכוני אבטחה. ברד-האט בודקים אם ישנן פריצות ידועות ואם הפריצות נחסמו בגירסה יציבה מתקדמת יותר, גירסת העדכון הבאה תכלול את הגירסה המתקדמת יותר (מה שנקרא בשפה המקצועית "Rebase").

ב-רד-האט שחררו מסמך ארוך לגבי השינויים ברד-האט 7.4 (וכמובן כל הדברים נמצאים ב-CentOS 7.4) שנמצא כאן ומאוד מומלץ לקריאה לפני שדרוג שרתים. ישנם שינויים כמעט בכל תחום, Kernel עם עדכוני מודולים, תמיכה בדרייברים חדשים, חבילות בגירסאות חדשות (ה-Rebase שהזכרתי לעיל). בלינק לעיל תוכלו למצוא את ה-General Updates שמדבר בכלליות על השינויים ומתחתיו פירוט לגבי השינויים.

ברוב המקרים, הרצת yum update תשדרג מערכת מכל גירסה קודמת (7.0, 7.1 וכו') לגירסה האחרונה בלי הרבה בעיות, אולם ישנם מקרים בהם השדרוג יכשל או יותר חמור – המכונה/VM לא תצליח לעשות Boot או לא תצליח להפעיל תקשורת דרך כניסות התקשורת הרגילות/וירטואליות.

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

  • אם אתם משתמשים ב-iptables וב-ip6tables (הראשון מיועד ל-IPV4 והשני ל-IPV6, הן מותקנות כברירת מחדל בהתקנה רגילה). אם אתם מפעילים את שתיהם, יכולות להיווצר בעיות של תקשורת. הבאג מתוקן ב-CentOS 7.4 בחבילה iptables-1.4.21-18.0.1.el7 אך הוא עדיין לא מתוקן ברד-האט 7.4. הפתרון המומלץ כרגע – להפעיל רק אחד מהם ולבטל את השני (בעזרת פקודת systemctl disable).
  • אם אתם משתמשים ב-Xen, מכונת VM של CentOS 7.4 עם דרייברים Paravirtualized – ה-VM לא יצליח לבצע BOOT וכרגע הפתרון הוא HVM (או PV-on-HVM). תיקון לכך יצא בקרוב.
  • במקרים מסויימים הרצת yum update תתקין חבילות i686 ולא X86-64. הבעיה מתרחשת עקב התקנת RDMA. אם אתם משתמשים ב-RDMA, מומלץ להריץ yum install rdma-core && yum update. אם אתם עדיין רואים בעיה, מומלץ להריץ yum install rdma-core ibacm. 
  • אם אתם רוצים להתקין VirtualBox על תחנת עבודה שתריץ כ-host את CentOS 7.4, תצטרכו להתקין את גירסת VirtualBox 5.1.28 מהאתר. גירסה 5.1.26 לא תעבוד.
  • משתמשים ב-VMware ורוצים להקים VM מבוסס CentOS 7.4? עקב שינויים שרד-האט ביצעו בקרנל, התקשורת הוירטואלית לא תעבוד. יש צורך בהתקנת Patch ל-VMware tools. לפרטים – כנסו ובצעו את ההוראות בקישור הזה.
  • חבילת ה-initramFS הרבה יותר גדולה מבעבר, ולכן אם מחיצת ה-boot/ שלכם קטנה מ-1 ג'יגהבייט, תצטרכו להרחיב אותה לפני השדרוג ל-7.4 לפחות לגודל 1 ג'יגהבייט (אני ממליץ להרחיב לגודל 5 ג'יגהבייט אם הנכם מתקינים מספר גרסאות קרנל).
  • יכול להיות ששרות SAMBA יפול עם השגיאה symbol krb5_get_init_creds_opt_set_pac_request, not defined. במקרים כאלו יש להתקין את חבילת  krb5-libs-1.15.1-8.el7 ולהפעיל את שרות SAMBA מחדש.
  • ועוד בעניין SAMBA – אם אתם עובדים עם אותנטיקציית SSSD ומאפשרים SHARE, זה לא יעבוד. כרגע האפשרות היחידה היא לשנמך לגירסה שקיימת בסנטוס 7.3. כרגע רד-האט עובדים על הבאג הזה.
  • נדיר, אבל ראיתי מקרים שזה קורה: אתם מפעילים את ה-CentOS ואין תקשורת עד שאתם מבצעים Login או שהתקשורת לא מופעלת בזמן Boot. במקרים כאלו, עקבו אחר ההוראות כאן.
  • החל מגירסה 7.4, מינימום זכרון שנדרש עבור המערכת הוא 1 ג'יגהבייט. במקרים שאתם רוצים להריץ את ה-ISO כ-LIVE, יש צורך בלפחות 1.5 ג'יגהבייט זכרון.
  • עוד בענייני VMWare: אם אתם מגדירים ידנית VM לשימוש עם CentOS 7.4, אל תנסו לבחור דרייברים SCSI אלא אך ורק את ה-Paravirtualized. דרייברים ל-SCSI ש-VMWare השתמשו כבר לא קיימים בקרנל הזה.
  • אוהבים את פקודת ifconfig ו-netstat? תתכוננו לשכוח מהם. הם מסומנים כ-Deprecated והם אינם מותקנים כברירת מחדל עם CentOS 7.4, ולכן אם הרשת שלך לא עלתה, השתמשו בפקודת nmcli כדי להפעיל את כרטיס הרשת ואז תוכלו להתקין את החבילה (ותתכוננו לשנות סקריפטים שמשתמשים בפקודות הנ"ל).
  • בסנטוס 7.4 מותקנת גירסה חדשה של sudo שמשתמשת ב-var/db/sudo/lectured/ ולפיכך ההתראה הראשונה שמשתמשים ב-sudo (עם האזהרות וכו') תופיע מחדש לכל המשתמשים ב-sudo לאחר שדרוג לסנטוס 7.4.
  • אם אתם משתמשים ב-CentOS 7.4 עם GNOME, יכול להיות שמנהל הקבצים (Nautilus) יראה את האייקונים מאוד גדולים. הפתרון הוא להריץ את הפקודה: gsettings set org.gnome.nautilus.icon-view default-zoom-level 'small' ולבצע lougout ולאחר מכן login.
  • אם אתם משתמשים ב-CentOS 7.3 (או גרסאות 7 קודמות) ואתם מריצים על זה OpenLDAP ואתם מתכוונים לשדרג, יש לבצע את ההוראות בלינקים כאן וכאן או שתהיה לכם בעיה רצינית עם ה-OpenLDAP. בכל מקרה אם מדובר ב-VM, בצעו snapshot לפני כן.

בכל מקרה, תמיד מומלץ להסתכל בדף ה-Errata של רד-האט ולוודא שאין עדכונים שלא התקנתם או שלא שמתם לב אליהם.

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

הפריצה ב-Equifax והבעיות ב-Enterprise

כל מי שנמצא בעולם אבטחת המידע שמע בוודאי על אירוע הסייבר הכי גדול שהיה בארה"ב עד היום: פריצה לחברת בדיקת קרדיט עם גניבת פרטים של 143 מיליון איש (ועוד 400,000 בבריטניה, ועוד מגה-פדיחות לגבי הסניף שלהם באוסטרליה מבחינת אבטחת מידע).

מקור הפריצה גם ידוע: בחברה השתמשו בפלטפורמת פיתוח Apache Struts המאפשרת פיתוח אפליקציות WEB ב-JAVA בקלות. חור האבטחה התגלה וטלאי תיקון שוחרר במרץ, אבל ב-Equifax לא ממש טרחו להטמיע את הטלאי, מה שנוצל בחודש מאי כדי לפרוץ ולגנוב את הררי המידע.

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

וכאן בדיוק מתחילה הבעיה..

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

אבל ישנם 2 בעיות בסיסיות ששום טכנולוגיה כמו FW/IPS/WAF וכו' לא ממש יכולות לפתור.

נתחיל בבעיה היותר קלה לפתרון שרובם כלל לא מיישמים. אני קורא לה "סימוכין עיוור" – שורת שרתי אפליקציה פנימיים מתחברים ל-SQL כלשהו ושולפים מידע. בד"כ אתר מבוסס Web או אפליקצייה וובית או אפליקציית מובייל – יעבירו בקשות מהאפליקציה או מהשרתי Front End לשרתי Back End, שרתי ה-Back End יתשאלו את ה-SQL, יבצעו סינון/סידור פלט ויעבירו את הנתונים בחזרה לשרתי Front End או אפליקציה. עד פה הכל טוב ויפה, וכאן יש לנו "סימוכין עיוור" – מכיוון שכל השרתי Back End ושרת ה-SQL נמצאים בכתובות פנימיות, אין שום מגבלה לכמות השאילתות (ובמקרים מסויימים גם אין סינון שאילתות) ששרתי ה-Back End יכולים לשלוח אל ה-SQL ולהעביר הלאה את המידע. שאילתה אחת או מיליון – זה אותו דבר. ה-IPS או ה-WAF יכולים להגן נגד שאילתות רחבות (ה-*), וכך בדיוק נגנב המידע מ-Equifax (מבלי להיכנס לכל הפרטים הטכניים של הפריצה).

הבה נדגים זאת: חברת תקשורת סלולרית מפעילה מוקד שרות לקוחות. מחשבי פקידי השרות לקוחות מריצים אפליקציות ווביות שמתשאלים ה-SQL נון סטופ לגבי פרטים על הלקוחות והפקידים גם מבצעים שינויים בפרטים (שינוי חבילה, חסימת מספר, שינוי פרטי לקוח ועוד ועוד). האם יש איזו מגבלה של כמות שאילתות פר PC? סביר מאוד להניח שלא וסביר להניח שגם לא נמצא מגבלה כזו גם באפליקציה הסלולרית או באתר החברה, וכך יוצא מצב שאם מאן דהוא פורץ ואני מוצא פריצה בספריה שהחברה משתמשת כדי לבנות את האפליקציית Web – אני יכול להקים מספר מכונות VM אצל ספקי ענן שונים (או יותר גרוע – כמה עשרות קונטיינרים פר VM) – הפורץ יכול לתשאל דרך החור שהוא מוצא את ה-SQL שאלות ובעזרת סקריפט שהוא יכול לבנות – הוא יכול לשאוב את המידע מה-SQL, ועד שהחברה תעלה על כך – הפורץ כבר יעלם לו (אחרי הכל, כשפתוחים חשבון אצל ספקי ענן, ספק הענן אינו מחטט בציציות הלקוח – כל עוד יש ללקוח כרטיס אשראי כלשהו [גם אם מדובר בכרטיס חד פעמי או אפילו קרדיט שהתקבל מביקור בכנס]), אף אחד לא יעצור את אותו פורץ לעשות כרצונו, ואם הוא רוצה – הוא יכול לעשות את הכל דרך VPN או הקמת VPN על ספק הוסטינג נידח כלשהו. בהצלחה במציאת הפורץ.

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

כיום רוב העולם כבר למד לעבוד עם תוכנות/ספריות/פלטפורמות חיצוניות שמדיניות עדכוני האבטחה שלהם לא תמיד ברורה והם אינם כלולים באיזה Repository של הפצת לינוקס. יש כיום את Github שבמקרים רבים יכול להציל מפתחים ואנשי IT עם פרויקטים שאנשים כתבו והעלו ורבים משתמשים בכך כדי לפתור בעיות וכדי לממש דברים שונים, אולם כלי ה-IPS לדוגמא לא ממש מגלים חורי אבטחה וכלי סריקה לא ימצאו את החורים כי לפעמים אין CVE לחור אבטחה לכלי שמישהו פיתח, העלה ל-github ושכח בכלל מהפרויקט לאחר זמן מה. יותר מכך – במקרים רבים ההטמעה עצמה מוטמעת עם הרשאות שגויות (ברמת Administrator או root), עם הרשאות קבצים שגויות, או שפתחו יוזר ב-SQL ברמת "הכל כלול" (רוצים דוגמא? לכו תבדקו בחברה אלו הרשאות ה-Jenkins מותקן ורץ. הוא לא אמור לרוץ כ-root).

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

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

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

החלוקה

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

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

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

התשובה: אני מעריך בין 1 ל-2. להלן הסיבות מדוע המספר נמוך:

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

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

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

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

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

אז מה ניתן לעשות בנידון? איך ניתן להשיג עוד עבודות? להלן מספר נקודות חשובות:

  • פרסם עבודות שאינן מתאימות לך. אתה מומחה בפייתון ומישהו מחפש מתכנת ++C? קח את פרטיו ופרסם את פרטי ההצעה (אתה יכול לפרסם כאן וכאן).
  • עדיין לא הומצאה מכונה לקריאת מחשבות ואיש אינו יודע אם אתה במצב של 0 עבודות או שאתה מחפש עבודות, מחפש עבודה קבועה לחצי משרה, מחפש משרה מלאה לטווח ארוך וכו'. אל תתבייש, תפרסם זאת! (הח"מ מחפש לחצי משרה 🙂 ), זו הדרך הכי מהירה שחברים ישתפו זאת וסיכוייך לקבל משרה כך אינם נמוכים.
  • פרסם תכנים משלך על התחומים שאתה נותן בהם שרות(ים) ומדי פעם תבצע קצת SEO כך שגוגל יעלה את דירוג הבלוג/אתר שלך.. להלן דוגמא על קונטיינרים:

  • הדגם את יכולותיך. קל לדבר ולכתוב על דברים אבל אם יש משהו שמושך אנשים להתעניין בשרותיך – הם הדגמות של הדברים. התקנה של דברים מאפס, הגדרות שונות, הסברים איך מפעילים דברים וכו'. כל מה שאתה צריך זה חשבון בגוגל, מיקרופון ותוסף Nimbus לכרום (ניתן להתקנה מכאן). להלן דוגמא:
  • כרטיסי ביקור – נפגשת עם מישהו? אתה ב-Meetup ומשוחח עם אנשים? חלק כרטיסים, אולי יחזרו אליך. אל תשאיר אנשים עם תהיה "הבחור שפגשתי רציני, חבל שאין לי את הפרטים שלו".
  • הסעיף הבא נתון למחלוקת ביני לבין חבריי אך אני עדיין עומד על שלי: אם אתה טוב בתחומך, שקף זאת במחיר שאתה גובה. הנה כמה דוגמאות למחירים שמהם לא כדאי לרדת (תחום סיסטם/Devops/אינטגרציה/יעוץ). תזכרו שכעצמאים המדינה עושקת אותנו בכל מצב:
    • עבודה חד פעמית חרום לתיקון תקלה (מעכשיו לעכשיו) – לא פחות מ-300 שקל
    • חצי משרה קבועה – לא פחות מ-150 שקל
    • משרה מלאה קבועה (תשלום כנגד חשבונית, לא תלוש משכורת) – לא פחות מ-120 לשעה
    • יעוץ מומחה – פר שעות (בד"כ לוקחים מינימום שעה או שעתיים) – לא פחות מ-200 לשעה
  • "לחפור" קצת. הגעת ללקוח שרוצה ממך עבודה X. בדוק אם יש עוד דברים שאתה יכול לעשות עבורו ובכך להרחיב את העבודה או כמות שעות העבודה.
  • חשוב: דרוש מקדמה כאשר מדובר בעבודה גדולה. שיטות תשלום של ש+60 או ש+30 הן נחמדות אבל אם אין לך כרגע עבודות שאתה עושה בנוסף, אתה יכול להיתקע למצוקת מזומנים. אין כללים לסכום אולם אני לדוגמא נוהג לבקש בין שליש למחצית הסכום כמקדמה (בהתאם לכמות השעות או מחיר הפרויקט) וחשוב לוודא שהמקדמה תשולם לפני שאתה מתחיל לעבוד.

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

התהליך המומלץ בעת ביצוע פרויקט ע"י יועץ

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

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

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

לעניות דעתי, דברים צריכים להתבצע בדיוק ההיפך.

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

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

משם עוברים לשאר החלקים – אחסון (Storage), רשת (Network) ומחשוב (Compute). היכן מומלץ לחשוב על פתרון NFS והיכן מומלץ על פתרון בלוק כמו iSCSI? האם ללקוח יש תשתית תקשורת מתקדמת (10/25/50 ג'יגהביט) או שצריך לעבוד ב-Teaming? האם חיבור הסטורג' "יחנק" עקב עבודה מאומצת של הפתרון שהלקוח רוצה שירימו לו? האם הלקוח צריך לעבוד ב-HA או DR או שאם נופל הפתרון ויש השבתה זמנית זה לא יהיה קריטי בשבילו? ועוד לא דיברנו על שילוב אוטומציה, Workflow ועוד דברים אחרים.

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

Solaris / SPARC – הסוף

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

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

בהתחלה זה עבד לא רע. בכל זאת, ל-Sun היו שרתים כלל לא רעים, פתרונות סטורג' מבוססי ZFS, פתרונות משולבים כמו Exadata ועוד מוצרים שחברות גדולות רכשו, אך הבעיה הגדולה ביותר היתה – סטגנציה. מערכת ההפעלה Solaris לא קיבלה עדכונים רציניים, מערכת ה-ZFS גם לא קיבלה תכונות חדשות ורציניות מאז סולאריס 10, וגם מעבדי ה-SPARC החדשים לא ממש היוו איום רציני לאינטל (שבסופו של דבר כבשה את שוק השרתים בכל מובן). אינטל פתחה מרכזי לינוקס בתוך החוברה ובסבלנות ועבודה עם יצרני הפצות לינוקס כמו רד-האט ו-SuSE כדי לשפר עוד ועוד את ליבת הלינוקס (ואת המעבדים עצמם) על מנת לתת תוצאות לא-פחות-טובות מהשילוב של סולאריס ו-SPARC וכיום מבחינה טכנית, אין שום הצדקה טכנולוגית להטמיע Solaris. אם אתה מחפש פתרון מבוסס יוניקס, פשוט תתקין לינוקס ותגמור עם זה, שלא לדבר על כך שדברים שנכנסו חזק לטרנד כמו Machine Learning או IOT – אתה צריך לינוקס וסולאריס לא יתן לך פתרון (בהצלחה להפעיל כרטיסי Tesla עם סולאריס. מנסיון – זה לא כיף, גם כשיש דרייברים של nVidia).

כשחברה מפתחת מערכת הפעלה, בין אם מדובר במערכת שהבסיס שלה הוא קוד סגור (מיקרוסופט) או קוד פתוח (יוניקס) או משולב (zOS) – החברה צריכה להיות כמה שיותר "שקופה" ולסייע לכל מי שרוצה בכך, בין אם מדובר בחברות המפתחות תוכנה (ISV) או חומרה (IHV) או אינטגרטורים עצמאיים ולמעט עניין רשיונות למערכת הפעלה – הדבר האחרון שהחברה צריכה לעשות זה לשלוח מכתבי איום לאינטגרטורים שמנסים לתת פתרונות ללקוחות שמשתמשים במערכת ההפעלה של החברה. דבר נוסף הוא פתיחת טכנולוגיות – גם IBM, גם מיקרוסופט ובוודאי רד-האט, סוזה, אובונטו, VMWARE ואחרים – כשהם מפתחים דברים חדשים ורוצים לשתף את זה בציבור, אתה תמצא תוך זמן קצר את הקוד ב-GitHub ומפתחי החברה ישמחו לסייע בבעיות או בקבלת רעיונות ושיפורים לדברים החדשים שהם שחררו. ככה זה היום – חברות פיתוח מערכות הפעלה כבר הפסיקו לפחד מקוד פתוח והן דווקא מאמצות את המהלכים בחום. אתם יכולים להיכנס ל-GitHub ולראות לדוגמא פרויקטים של מיקרוסופט, IBM, VMWARE וגם Oracle (אם כי מה שאורקל מעלה זה סקריפטים וכלי עזר שהמהנדסים פיתחו, לא פרויקטים עצמאיים) כך שאם נמדוד ונדרג חברות מבחינת תרומת קוד ופרויקטים – נקבל את אורקל במקום די עגום שם למטה.

אורקל מנסה גם ללכת בשיטת ה-Me too. פתרון הוירטואליזציה שלהם? העתק של Xen. פתרון הלינוקס שלהם? העתקה ישירה מ-RHEL (של רד-האט) ואפילו הכלים המיוחדים שאורקל העבירו מסולאריס – כיום ב-2017 יש להם חלופות שהן בקוד פתוח לגמרי וכמובן רצות על כל הפצת לינוקס. גם בתחום הענן אורקל התעוררה מאוחר מדי ואם תסתכלו מבחינת דוחות Market Share, תוכלו לראות שאורקל נמצאת בד"כ בגרפים בתוך קטגוריית ה-Others. איך אורקל ישיגו לקוחות לענן שלהם? בכך שהם יעשו כל מאמץ לדחוף את הלקוחות שלהם שמשתמשים ב-Middleware וב-DB של אורקל – לענן תוך מתן הנחות (אני מנחש: זמניות) ולמי שמתעקש לעבוד On Premise – חכו לחשבוניות החידוש רשיון.

האם אורקל מחר הולכת "למות"? אני בספק, אבל מצד שני בינתיים לא רואים שום מנועי צמיחה רציניים שם. אם מחר חברתכם תחליט לעבור לענן, סביר להניח שהיא תבחר באמזון או מיקרוסופט ואולי גם יחשבו על פתרון הענן של גוגל, אבל אני מאוד בספק אם חברות יעברו לענן הציבורי של אורקל. גם בתחום ה-On Premise מחכה לאורקל תחרות לא קלה עם ההצעה החדשה של מיקרוסופט לחברות שמתעקשות להריץ את ה-DB שלהם באורקל תחת לינוקס: מיקרוסופט מוכנה לתת רשיון מלא ל-SQL Server החדש שרץ תחת לינוקס בחינם לכל לקוח שעובר מאורקל (ואגב, ה-SQL של מיקרוסופט יכול לרוץ גם כקונטיינר Docker בלינוקס) כך שכשחברות יצטרכו לחדש רשיון, יהיה להן קשה מאוד לסרב להצעה של מיקרוסופט, במיוחד שהן לא צריכות לשנות מערכת הפעלה..

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

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

עדכונים לגבי ESXI

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

נתחיל בהווה: אם יש לכם גרסאות 4, 5, 5.1, 5.5 אז אולי הגיע הזמן יהיה לחשוב על שדרוג. לפי המסמך הזה של VMWare, גרסאות 4, 5.0, 5.1 כבר סיימו את חייהם מבחינת תמיכה ואם אתם מריצים גירסה 5.5 – היא תסיים את חייה ב-19/9/2018 כך שכדאי בתכנון התקציבי להכניס הוצאת שדרוג.

אם אתם משתמשים בגירסה 6.0 של ESXI אז מאוד מומלץ לשדרג לגירסה 6.5U1. השינויים בין 6.0 ל-6.5 הם רבים וכוללים שינויים ועדכונים ל-vSAN, עדכוני דרייברים רבים, מעבר ל-VSCA (ב-VMware ממש רוצים שתעבור ל-VCSA והם נותנים "הטבות" ב-VCSA כמו כלי מיגרציה, High Availability "טבעי", וגיבוי ושחזור "טבעיים" (של ה-Appliance, לגיבוי מכונות VM תמשיכו להשתמש ב-Veeam). ההתקנה של VCSA הרבה יותר קלה ואתם יכולים לקרוא על מגוון התכונות החדשות במסמך הארוך והרשמי כאן או בגירסה המקוצרת כאן. השדרוג מ-6.0 ל-6.5U1 עולה לכם … 0 שקלים מבחינת רישוי.

אם יש לכם גירסה 6.5, מאוד מומלץ לשדרג ל-6.5U1 בגלל כמה סיבות, להלן חלק מהן:

  • גירסת VSAN שודרגה ל-6.6 (והיא מצריכה ESXI 6.5 כולל VCSA 6.5 או אם אתם עדיין בגירסת Windows – אז vCenter Server 6.5 – מומלץ בחום לעבור ל-VCSA, הוא יעביר לכם את הנתונים אוטומטית) ואם אתם עובדים All Flash תקבלו הפתעה נחמדה – שיפור של 50% בביצועים. בנוסף תכנון גדילה עובר עתה תהליך Pre-check כך שהדברים יהיו יותר בטוחים ולא יפלו עקב חישוב שגוי מצד מנהל המערכת. בנוסף מקבלים את vRealize Operation Management, תהליך ה-Deploy יותר קל, תהליך בדיקת התקינות שופר מאוד, אין יותר צורך ב-Multicast (אני יכול לדמיין אנחת רווחה מאנשי התקשורת), שיפורים ב-Cross Site Protection (לאלו שמשתמשים בזה, לא מכיר כאלו) ועוד. אפשר לקרוא מה חדש כאן.
  • אם אתם חושבים לרכוש ברזלים חדשים כמו שרתים מבוססי מעבדי EPYC (שאפו!) או שרתים מבוססי דור 5 של Xeon – תצטרכו את ה-Update 1 של גירסה 6.5, אחרת תקבלו מסך סגול והמון עצבים. לאלו שרוצים להריץ בביתם כ-LAB את גירסה 6.5 על מעבדי Ryzen או Threadripper או Skylake-X – גם אתם תצטרכו את גירסת 6.5U1. (לא מומלץ לנסות על Kabylake-X – ניסיתי, זה נופל לאחר זמן מה מבחינת ביצועים ו-VMware אפילו לא מוכנים להתייחס לכך).
  • עדכוני דרייברים – ישנם עדכונים לכל כרטיסי הרשתות, החל מכרטיסים בסיסיים כמו כרטיסים מבוססי אינטל של 1 ג'יגהביט ועד לכרטיסים של 40/50 ג'יגהביט (למיטב ידיעתי כרטיסים של 100 ג'יגה תצטרכו דרייבר יצרן עדיין).
  • ה-vCenter יכול להיות ב-High Availability באופן טבעי ללא צורך בקפיצת ראש לבריכה בעומק חצי מטר. מגדירים Active, Passive ו-Witness ויאללה – יש HA. פונקציה זו אינה קיימת בגירסת Windows. כמו שאמרתי – VMWare מאוד רוצים שתעופו מגירסת ה-Windows לטובת גירסת ה-Appliance.
  • שדרוג מכונות ESXI הרבה יותר קל וברוב המקרים אוטומטי לגירסה אחרונה עם VCSA. שימו לב: קודם משדרגים Appliance ורק אז את ה-Hosts.
  • גם VUM עבר שדרוגים בכל הקשור לעדכונים ומעתה הוא יכול גם לשדרג אוטומטית (אם תרצו) מכונות VM לגירסה אחרונה (או גירסה שתקבעו) של תאימות VM.
  • בכל הקשור ל-Auto Deploy, מי שמנהל את ה-vSphere בחברה אולי ישמח לדעת שהוא פחות יצטרך להשתמש ב-PowerCLI ועכשיו יש ניהול גרפי מלא של הדברים וגם בניית Image חדש של ESXI Boot תוך כדי הוספה והעפה של דרייברים.
  • ויש עוד ערימות של תכונות חדשות…

אחד הדברים החשובים לגבי תשתית vSphere מהגירסאות הקיימות לגירסה 7 העתידית – זה שגירסה 7 העתידית תהיה שונה מאוד ממה שהיה עד כה. זה לא סוד ש-VMWare עובדים לאט (רק בגירסה 6.5 הם התחילו לתמוך ב-VMWare tools חתומים והתקנה של מערכות הפעלה עם Secure Boot), אבל בגירסה 7 הם רוצים לסגור פערים. העולם עובר לקונטיינרים וכרגע ל-VMware אין תשובה ב-vSphere באופן רשמי, כנ"ל לגבי פתרון תחרותי ל-OpenStack או Azure Stack של מיקרוסופט (אם כי יש להם כלי להקים OpenStack בתוך vSphere – ראו למטה), כך שגירסה 7 תהיה שונה לחלוטין מכל הגרסאות הקודמות. אי אפשר למסור עליה פרטים (אין לי הסכם NDA עם VMware אבל מצד שני אין לי חשק מחר לקום בבוקר ולקבל טלפון וצעקות מאנשים שם) אך מה שכן אפשר לאמר – שהיא בהחלט תקל על חברות גדולות שרוצות לעבור להשתמש בקונטיינרים (ויש לה כבר פרויקטים בקוד פתוח בנושא, אפשר לראות אותם כאן – ויש המון). משהו אחד שאני יכול להמר (אין לי בסיס משמועות לכך) זה ש-VMWare גם תבצע אינטגרציה של VMWare Integrated Openstack לתוך vSphere בעזרת מוצרים משלימים שיש כבר ל-VMware ובעזרת חלקים בקוד פתוח (שהיא תשחרר שינויים תחת אותם רשיונות). אגב, למי שלא מכיר את התוכנה – מוזמן לעקוב אחר המצגת הנחמדה כאן.

לסיכום: ישנם לא מעט חברות גדולות שרוצות להישאר רק על VM, לא ענן מבוסס OpenStack, לא קונטיינרים (אולי בעתיד) וחברות רבות הן גם מאוד שמרניות, לכן אני חושב שנראה כאן מעין "קו" וירטואלי בין מוצרים והטמעות שחברות יבחרו. עד גירסה 6.5U1 ה-vSphere סובב כולו סביב VM והתשתיות לספק את הדרישות ל-VM (רשתות, סטורג' וכו'). מגירסה 7 המוצר יהיה הרבה יותר גדול ומורכב בהרבה מהיום ולא בטוח שחברות ירצו לקפוץ אליו  ויש מצב שיותר ויותר חברות יחליטו להישאר עם 6.5U1 ואת השאר להעביר לעננים ציבוריים במקום לשדרג לגירסה 7 (ודרך אגב, אני מאמין שגירסה מוקדמת שלה אנו נראה ב-VMWorld שתתרחש עוד 18 יום ולאחר מכן ב-VMWare Europe. אגב, בכנס הזה נראה את התשובה של VMWare לאינטגרציה עם עננים ציבוריים, לא רק של אמזון).

הולך להיות מעניין…

קצת על רד-האט, BTRFS, פוליטיקה ומוכנות ל-Enterprise

אם נסתכל כיום על תשתיות של כל Enterprise או כל חברה גדולה, נראה שכיום רוב מכונות הלינוקס וה-Windows רצות כרגע על VM, בין אם זה רץ על ESXI, על Hyper-V, על OpenStack או בעננים ציבוריים או פרטיים. גם לינוקס וגם Windows רצים בלי בעיה כ-VM ולכל מערכת הפעלה יש תמיכה טובה בקישוריות בין ה-VM ל-Hypervisor שמריץ אותו.

הבעיות מתחילות כשצריכים להריץ הפצות לינוקס כמו רד-האט או סנטוס על "ברזל" פיזי או Appliance פיזי. אין שום בעיה להתקין לינוקס וברוב המקרים גם לא נצטרך דרייברים, וה-File system יעבוד כמו שצריך, אולם יש דברים בלינוקס שהם אינם קלים או מובנים למשתמשים רבים שאינם אנשי לינוקס ותיקים. יצירת RAID מבוסס תוכנה (Software RAID או Fake RAID) הם לא בדיוק דבר הכי קליל, במיוחד אם רוצים לשלב Volume Management בתוך אותו RAID תוכנה (אם כי כמובן יש אתרים שמסבירים כיצד לעשות זאת). את המשוכה הזו ניתן לדלג עליה די בקלות אולם אם אנחנו רוצים לבצע Snapshots או להוסיף SSD כ-Cache לאותו RAID, זה כבר נהיה יותר מורכב. רוצה גם לבצע Compression ו-DeDup בזמן אמת? כאן כבר תצטרך איש לינוקס טוב וזה לא תמיד אפשרי, תלוי במה קיים ובאפשרות לשנות דברים.

האם ניתן לעשות את הדברים בלינוקס? התשובה היא שבהחלט כן. אני כותב את הפוסט הזה בביתי ואחד משרתי ה-NAS שלי עושה בדיוק את הדברים הללו: ה-RAID הוא תוכנה, המערכת מייצאת iSCSI, CIFS, NFS החוצה למערכות אחרות (כל עריכת הוידאו שלי שאתם רואים בערוץ הוידאו של העסק מבוצעת על CIFS/SAMBA, לא על דיסק מקומי), יש DeDuplication  ויש דחיסה והכל רץ על "מפלצת" עם … מעבד i5 ועם 16 ג'יגהבייט זכרון, 5 דיסקים מכניים ו-2 דיסקים SSD ישנים שישבו אצלי במגירות. המערכת עצמה רצה על ZFS עם הפצת CentOS 7 ועם כל העומס שאני זורק עליה (ויש עומס) – היא עושה את עבודתה יציב כבר 4 שנים בלי תקלה אחת הקשורה ל-ZFS.

אז אם יש את זה, מדוע אינך רואה בהפצת לינוקס מבוססת רד-האט או סוזה אפשרות להקים מכונה עם ZFS? הרי ל-ZFS יש כבר ותק של בערך 12 שנה ב-Sun עם סולאריס (המערכת פותחה שם במשך 5 שנים לפני שהיא שולבה בסולאריס).

הסיבה הרשמית היא "בעיה ברשיון", הסיבה המציאותית יותר היא … פוליטית.

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

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

ב-2008 החלה לקום מערכת ניהול קבצים ודיסקים חדשה בשם BTRFS. בעקרון, BTRFS אמור להיות התשובה ל-ZFS רק בקוד GPL והוא משולב בתוך הליבת לינוקס. אנחנו ב-2017 וכיום כל הפצת לינוקס תומכת ב-BTRFS אולם הבעיה הגדולה ביותר של BTRFS היא ביציבות. ה-BTRFS יציב מבחינת file-system אך יש לא מעט בעיות במימוש ה-RAID שלו ובחלקים אחרים. בזמנו הקוד נבנה תחת קורת הגג של אורקל, אולם מאז שאורקל החליטה לברוח מקוד פתוח כאילו מדובר במחלה מדבקת – התפזרו המפתחים לכל עבר ואין עבודה יציבה על BTRFS, מה שגרם לרד-האט להודיע שהיא "יורדת" מ-BTRFS בגירסאות הבאות של הפצת הלינוקס שלה (בינתיים שאר ההפצות ממשיכות לתמוך ב-BTRFS, וזו מערכת עיקרית בהפצות כמו SuSE).

נשמע כמו צעד די דרסטי – לא? אכן, רק שבימים האחרונים הסתבר מדוע רד-האט עשתה זאת. רד-האט רכשה חברה קטנה בשם Permabit ש.. מציעה בדיוק את השרותים שה-Enterprise צריך: דחיסה, Dedupe, thin provisioning וכו'. האם רד-האט תציע זאת בחינם לקהל הרחב? כן, אבל יקח זמן. במילים אחרות, במקום לחכות ש-BTRFS יבשיל, רד-האט העדיפה לקנות חברה וטכנולוגיה. במקביל הודיעה רד-האט שהם החלו פרויקט חדש שנקרא Stratis שיאפשר לבצע חלק מהדברים בצורה קלה ופשוטה. אל תחזיקו את נשימתכם, לפרויקט יקח כמה שנים עד שיהיו פירות וניתן יהיה להשתמש בו בצורה בטוחה.

לסיכום: כיום ב-8 מתוך 10 מקרים, כשמקימים מכונת לינוקס, מקימים אותה כ-VM. לא צריך RAID ב-VM (אבל כן צריך LVM אם תרצו להגדיל דיסק או להוסיף דיסק ל-VM) ו-snapshots ניתן לעשות ברמת VM – ועדיין, עקב כל מיני החלטות שאני קורא להן "פוליטיות" הפצות רשמיות עדיין לא כוללות (גם בגרסאות המסחריות) דברים ש-Enterprise צריכים כשמקימים מערכת עם דיסקים מקומיים. הרכישה ש-רד האט ביצעה מסייעת במשהו, אבל אם רד-האט היתה עושה צעדים לפני מס' שנים כדי לסגור עיסקה עם אורקל, אז היינו כיום עם מערכת כמו ZFS שנותנת את הדברים שאותם לקוחות חשובים צריכים, במיוחד במקומות שמעוניינים להרים Software defined storage בשיטה של Scale Up.

על הקשחות תחנות עבודה/דסקטופ ושרתים

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

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

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

  • אנשים מסתכלים על המאמרים של מיקרוסופט וחושבים שעניין האבטחה זה כמו שמיקרוסופט מפרסמת – 3-5 עמודים בלינקים שונים ואפשר לסמן ✔ על הנושא. זהו, שזה לא. אבטחת מידע רצינית בין אם זה על דסקטופ או שרת היא הרבה יותר מורכבת ואתם מוזמנים להעיף מבט על ה-CIS Benchmark שנחשב ה-דבר בהקשחה. על Windows 10 בלבד מדובר על 942 עמודים. Windows Server 2012 R2? זה 732 עמודים. (ועם CIS זה הולך לפי ניקוד לגבי השינויים שעושים, כל דבר מקבל ניקוד שונה)
  • אין "הקשחה אחידה". איש אבטחת המידע רוצה את מקסימום האבטחה, איש ה-IT רוצה פחות כדי שהוא אשכרה יוכל לעבוד בצורה נוחה, ולכן זה יקח לא מעט זמן לעבור על הנקודות ולבצע את הדברים.
  • "חיתוך פינות" – הנה משהו שאני שומע שוב ושוב מלקוחות פוטנציאליים: "כבר עשית את רוב העבודה ללקוחות קודמים, תביא את זה, נעשה תיאומים ונגמור עניין". הבעיה – עדיין לא פגשתי לקוח שמוכן שקוד או סקריפטים שכתבתי עבורו – יעברו הלאה ללקוחות אחרים, גם אם מדובר בדברים שכתבתי בביתי עם ה-LAB שלי. לקוחות רוצים משהו פשוט: שילמנו? זה נשאר אצלנו וזה לא עובר לאף לקוח, אז צריך לכתוב מחדש דברים שוב ושוב.
  • אוטומציה – האם אפשר לעשות את הדברים בצורה אוטומטית פחות או יותר? (להריץ אוטומציה בלי הגדרות פר שרת ששונים מאחד לשני יוביל להשבתה של המערכות שלכם. ראיתי כבר מישהו שניסה זאת פעם) – בהחלט, אבל זה דורש עבודה של 2-3 חודשים של כתיבה ומימוש כל הסעיפים והגדרת קובץ שבו יהיה אפשר לבחור מה יהיה enabled ומה יהיה Disabled, וכן, אני מדבר על אוטומציה ל-Windows עם דברים כמו Ansible.זו עבודה שאינה קלה שמצריכה המון snapshots הואיל וכל מימוש סעיף ובחינתו מצריך snapshot ו-rollback לאחר הבדיקה.
  • תחנות עבודה / דסקטופ – אפשר גם לעשות שם אוטומציה בנוגע להקשחה אולם עדיף לעשות Image מאסטר ולשכפל בין התחנות, תוך יצירת שינויים בהתאם לתפקיד התחנה/דסקטופ.
  • רגולציה / Conformance tests – יש הבדל ענק בין חברה לייבוא שימורים לבין חברת ביטוח או בנק שרוצים הקשחות. במקרים של הגופים הגדולים, חוץ ממחלקת אבטחת מידע צריך לערב את המחלקה שאחרית על מימוש רגולציות ו-Conformance tests (ראיתי מקרה שעבודה ענקית של הקשחה בוטלה ברגע האחרון לפני מימוש רק כי לא עירבו את המחלקה הזו. עבודה עבורי של חצי שנה נעלמה במחי מייל אחד מאותה מחלקה).
  • שילוב הקשחה של Windows ו-Linux. רעיון נחמד, לא ניתן לביצוע מכיוון שמדובר במערכות לגמרי שונות שמצריכות סקריפטים שונים לחלוטין.

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