על שרתים וירטואליים (VPS) ו-DNS

לקוחות רבים שוכרים שרתים וירטואליים (VPS) ומאחסנים עליהם את האתרים שלהם. יש כאלו המאחסנים מספר קטן של אתרים ויש כאלו המאחסנים מאות אתרים.

מטבע הדברים, לכל אתר מגיעים עם שם הדומיין. היכן מוגדר שם הדומיין כדי שיוכר בעולם? ב-DNS כמובן, ומטבע הדברים, אלו שמשכירים שרתים וירטואליים ברוב המקרים מגדירים את השרת גם להיות שרת ה-DNS, ומכיון שבשביל DNS יש צורך ב-2 שרתים, כמעט כולם מגדירים את שרת ה-DNS שישמש כ"אדון" (Master) ו-Slave ("עבד").

כאן מתחילה הבעיה (והיא לא קשורה לספק כלשהו אלא בכלל).

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

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

כלומר הפתרון של לאחסן את רישומי ושרות ה-DNS בתוך שרת ה-VPS שלך אינו רעיון טוב.

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

  • אם יש לך מספר קטן של דומיינים (נניח כמה עשרות דומיינים) מספיקה חבילת אחסון משותף (נקראת גם "אחסון אתרים" או "אכסון אתרים") בתצורת "ריסלר" (ישנם ספקים שקוראים לזה שמות אחרים, אתה צריך לבקש חבילה שאתה יכול לרשום בה דומיינים דרך הפאנל). חשוב לוודא שלאותו ספק שרתי ה-DNS שלו מופרדים (מומלץ שיהיו מופרדים ברמה הפיזית כך שכל שרת DNS ישב בשרת פיזי אחר). עם חבילה זו תוכל לרשום את הדומיינים שלך אצל אותו ספק ולהפנות את ה- A record לכתובת ה-IP של שרת ה-VPS שלך (אפשר גם רישומים אחרים כמו MX, CNAME ועוד, ועל כך מומלץ להתייעץ עם הספק או עם מישהו מקצועי שמבין ב-DNS ובהתאם לצרכים). ודא עם הספק שהרישומים שיצרת מסונכרנים אוטומטית עם שרת ה-DNS השני שלו. במקביל, כשרשמת בחבילה את הדומיינים, הספק יתן לך 2 רישומים (או יותר) של Name Servers שאלו בד"כ שמות שרתי ה-DNS שלו. את הרישומים האלו אתה צריך להכניס אצל רשם הדומיינים, היכן שרכשת את הדומיינים.
  • אם יש לך כמות גדולה של דומיינים (מאות ומעלה), מומלץ לשכור מספק אחר שרת VPS מאוד קטן (256 מגהבייט זכרון, דיסק קשיח וירטואלי קטן, עוצמת השרת אינה חשובה), ולהרים עליו שרת DNS. אם הינך משתמש בשרת ה-VPS העיקרי שלך עם cPanel, אז הנה חדשות טובות: אתה יכול להוריד ולהתקין ללא תשלום בשרת ה-VPS הקטן את cPanel DNS Only ולעקוב אחר ההוראות שם. תוכל להגדיר דומיינים בשרת ה-VPS העיקרי שלך והוא יסנכרן את הרישומים אוטומטית עם שרת ה-VPS הקטן שלך. (אגב, הסיבה לספק אחר נעוצה בעניין שאם יש תקלה כלשהי אצל הספק העיקרי שלך, שרותי DNS עדיין יוכלו לזהות את הדומיינים שלך בעולם).
  • אפשרות שלישית (והכי זולה, אם כי לא תמיד אפשרית): להשאיר את ניהול ה-DNS אצל רשם הדומיינים שלך. רובם מציעים פאנל כלשהו לשינוי ה-A record וכו' בקלות, וכך גם אם השרת הוירטואלי שלך נופל, שרתי ה-DNS בעולם עדיין ידעו לגבי הדומיינים שלך. החסרון בשיטה זו: אצל רוב הרשמי דומיינים הישראליים, העדכון עצמו מתרחש רק לאחר 24 שעות ועד אז לוקח עוד 24 שעות עד שזה מתעדכן בארץ (בהשוואה לחו"ל שזה עניין של שניות). לצערי, בנושאי DNS, "תודות" לספקי האינטרנט הגדולים ולאיגוד האינטרנט (ולכל תהליך רישומי דומיינים מקומיים), אנחנו עדיין "תקועים" בשנות ה-90.

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

על שרתים וירטואליים (VPS) והתקפות

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

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

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

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

מצב ממש לא נעים.

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

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

  • אתם רואים שהשרת שלכם בקושי מגיב וכל החיבורים של שרת ה-Web שלכם תפוסים (אפשר לראות זאת בלינוקס דרך SSH עם הפקודה: server httpd status או service httpd fullstatus – ב-CentOS/RHEL/Fedora. להפצות אחרות יש שינוי קטן מבחינת פקודות). הדבר הראשון שניתן לעשות הוא לגבות את קובץ httpd.conf (אם יש לכם cPanel לדוגמא, הוא נמצא ב- usr/local/apache/conf/httpd.conf ואם זה הגירסה שמגיעה עם CentOS/RHEL/Fedora אז המקום הוא etc/httpd/conf.d/httpd.conf/) ולשנות אותו בהתאם להוראות שמופיעות כאן. שימו לב: מומלץ לאחר ההתקפה להחזיר את המצב לקדמותו. מומלץ לאחר ביצוע השינויים להתחיל את השרת עם פקודת restart ולא עם reload.
  • אם יש לך חומת אש פנימית בשרת מבוסס Linux, מומלץ להתקין חומת אש חינמית כמו CSF ואז ניתן להשתמש בהגדרות כמו שמופיעות כאן כדי להפחית ולחסום התקפות אם הן קטנות עד בינוניות (תלוי בכמות המתקיפים, גודל שרת VPS, כמות זכרון, רוחב פס וכו')
  • התקנת מודול ב-Apache שנקרא Mod_Evasive. מודול זה יודע להבין בצורה לא רעה שהשרת Apache מותקף והוא יודע לנהוג בהתאם. מומלץ לקרוא את ההוראות איתו (למשתמשי cPanel החיים קלים, פשוט תעקבו אחרי ההוראות כאן).
  • ניתן באמצעות פקודה כמו הפקודה בשורה הבאה כדי לקבל מעין טבלה עם 2 קבוצות מספרים. מצד שמאל יהיה בסדר עולה כמות הבקשות ומצד ימין כתובת ה-IP ששולחת את הבקשות לשרת שלכם. כל מה שצריך לעשות זה לכתוב חוק דינמי (עם CSF זה csf -d ip כאשר ip זו הכתובת שרוצים לחסום) לחסום את הכתובות עם הכי הרבה בקשות, רק שימו לב שלא לחסום את עצמכם בטעות אם רצות אפליקציות שלכם פנימית בשרת:
netstat -anp |grep 'tcp|udp' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n

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

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

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

אפשרות נוספת (וקצת יותר יקרה): לקחת שרת וירטואלי (VPS) אחר לא מאותו ספק (אי אפשר לדעת אף פעם אם התקפה היא רק מול IP אחד או מול טווח ענק של כתובות של אותו ספק) ועליו להקים אתר בסיסי של השרות שלך, לבנות רפליקציה של ה-DB בין האתרים. ב"יום הדין" בשרת העיקרי תצטרך לעשות את הדברים הבאים:

  • קובץ robots.txt שיודיע לגוגל לא לסרוק בכלל את האתר שלך ( /  :Disallow ). הדבר האחרון שאתה רוצה שגוגל יאנדקס את הדף בסעיף הבא. (מקדמי אתרים אינם ממליצים זאת).
  • שינוי קובץ httpd.conf בשרת ה-Apache לפי ההוראות מעלה
  • קובץ index.html (לא PHP ולא בשום שפה אחרת שמכריחה את השרת Apache/NGINX לפנות למודולים שונים כדי ליצור את הקובץ) ובו יהיה הסבר קצרצר על כך שיש התקפה נגדך, ולינק ל-VPS השני שלך (בלי redirect, בלי קוד 301, בלי הפניה אוטומטית, אתה לא רוצה לקחת את ההתקפה איתך ל-VPS השני). כך הלקוח עדיין יוכל לקבל ממך שרות.

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

ישנם גם פתרונות אחרים נגד התקפות DDoS ו-DoS הכוללים קופסאות שבעצם יודעות לנטר את הרשת ולהבחין בנקל בהתקפה ו"להרוג" חלק לא קטן ממנה, אבל כל קופסא כזו עולה בסביבות ה-10,000 דולר ומעלה (כמו של IntruGuard). יש גם פתרונות מבוססי מכונות וירטואליות כמו של Sophos אבל במקרים רבים הם פתרונות ברמה של ספק קטן או ללקוח שיש לו כמה שרתים. בכל מקרה, כיום גם עם מכונת Linux רגילה ניתן למנוע התקפות שונות.

על אבטחת מידע ללקוחות – מצד הספקים

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

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

תקיפת שרת

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

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

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

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

פריצה לשרת

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

שיטה זו עדיין בשימוש היום על ידי סקריפטים שפורצים רבים מריצים. הסקריפט לוקח טווח כתובות מסויים ומנסה למצוא בפורטים מסויימים אפשרות לפרוץ, כך לדוגמא אחד הפורטים הפופולריים הוא פורט 22 שמשמש בשרתי יוניקס/לינוקס כחיבור לשרת (SSH). סקריפט כזה שמוצא את הפורט הזה, ינסה לעשות login דרך משתמשים כמו root, admin וכו' ועל כל משתמש הוא ינסה להריץ סידרה של סיסמאות ידועות כמו מספרים, מספרים ואותיות רציפות על מקלדת (1q2w3e4r) ועוד כל מיני סיסמאות. אם השרת נמצא עם סיסמא כזו, הסקריפט יצור יוזר נוסף עם הרשאות root וידווח בחזרה למפעיל הסקריפט שיש לו עוד שרת פתוח לשימושו. אותו דבר קורה עם פורטים כמו 25 (SMTP), ועוד פורטים.

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

אבל רוב הפריצות אינן פריצות פורטים, אלא פריצת אפליקציות.

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

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

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

  1. הטמעת חומת אש רצינית עם חוקים קשיחים: סיסקו, צ'ק-פוינט, פורטינט, ג'וניפר – כולם מייצרים קופסאות חומות אש מספיק רציניות כדי להגן על משתמשים. ספק רציני יודע לקחת קופסא כזו ולהגדיר מי יכול להיכנס ברזולוציה של כתובת IP, איזה פורטים לפתוח עבור הלקוח ואיזה פורטים לסגור. ספק רציני גם יתקין ללקוח חומת אש פנימית עם חסימת פורטים פנימה והחוצה לפי הצורך.
  2. לא לאפשר לעובדים שלו להיכנס למערכות של הספק עם סיסמאות אלא עם מפתחות הצפנה בלבד וכל כניסה נרשמת ומתועדת.
  3. ספק טוב מפריד לחלוטין בין רשת השרתים של הלקוחות לרשת שלו עצמו. כך לדוגמא כל עניין ניהול הלקוחות, פרטי הלקוחות, סיסמאות וכו' צריכים לשבת ברשת נפרדת, עם גישה מאוד מפוקחת לסקריפט ששולף נתונים ועדיף שהנתונים יועברו בהצפנה. (אצלנו לדוגמא כל רישום הלקוחות נמצא בכלל בעיר אחרת אצל ספק אחר).
  4. אם מדובר בספק שסולק כרטיסי אשראי, אז הספק צריך להקים רשת פיזית אחרת (לא להסתפק במכונה וירטואלית וחיבור VLAN נפרד) ולהציג אישור שעבר PCI (שימו לב: ישנו סולק שלא אציין את שמו שמציג לוגו של PCI באתר שלו אך הוא לא עבר PCI ולכן חשוב לבקש לראות הוכחה שהספק עבר תקן PCI ושהתעודה מראה את השנה הקלנדרית הנוכחית (בדיקת תקינות ל-PCI צריך לעבור כל שנה).
  5. ספק טוב שומר בשרתי אחסון שיתופי שלו לפחות חודש רישומים של כניסות לשרת הן דרך WEB וגם SSH, רישומים אלו אמורים להישמר בגיבוי.
  6. עדכונים – כל השרתים (למעט VPS שאינם מנוהלים על ידי הספק) צריכים להיות אחת לשבוע מעודכנים בכל הטלאים האחרונים שיצאו לאותה הפצה.
  7. פאנלים – חובה שיהיו מעודכנים לגירסה האחרונה.

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

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

ועוד משהו אחד: בחשבון משותף עם גישת SSH אפשר לבדוק את חלק מהדברים. לדוגמא אם תקישו את הפקודה uname -a תוכלו לראות שגירסת הליבה (אם זו מערכת CentOS מעודכנת) היא 2.6.18-274 (לקוחות שלנו יראו 374, הוספנו כמה דברים לליבה). אם המספר פחות מ-274, זה אומר שהשרת אינו מעודכן, ובמקרים כאלו אתם חשופים לחורי אבטחה.

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

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

על אבטחת מידע ללקוחות בעלי אתרים

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

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

אז נתחיל לעשות סדר בבלאגן.

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

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

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

עוד מספר נקודות:

  1. ספק האחסון אינו יכול לעשות קסמים ולהפוך את כל הנתונים למוצפנים, זו אחריותו של המתכנת להצפין את הנתונים לפני ההכנסה/עריכת נתונים קיימים בין אם דרך שפת התכנות, ספריית תכנות או שימוש בפונקציות ששרת ה-SQL נותן (לדוגמא: encrypt ב-MySQL וכאן אפשר למצוא יותר מידע). האחריות של הספק היא לחסום כניסה לא מורשת ל-MySQL (לדוגמא) ברמה של כניסה מבחוץ ומניעת אפשרות למשתמש לראות את כל בסיסי הנתונים בתוך ה-DB עצמו (למעט מה ששייך לאותו חשבון). כמו כן הספק צריך לאסור באחסון משותף (לדוגמא) אפשרות להתחבר ל-SQL מבחוץ (גם כשבונה האתר מאוד אוהב כלי GUI חיצוניים ורוצה להתחבר ישירות לשרת איתם).
    ככלל, ספק צריך לברר עם הלקוח מה הוא מאחסן ולעדכן את החוזה בין הספק ללקוח לגבי אחריות על המידע, עניינים משפטיים וכו' (ואני ממליץ לקחת את שרותיו של עו"ד קלינגר לעניינים אלו, הוא מומחה בזה).
  2. בוני האתרים: מאחריותכם להסביר ללקוחות לגבי עניין האבטחת מידע ולבקש ממנו שימצא איש אבטחת מידע שישב איתכם ויבדוק את האתר וימליץ לכם מה לעשות מבחינת קוד, פרוצדורות וכו'. אם לקוח רוצה לחסוך או לשחק אותה "ראש קטן", אתם תהיו המטרה של רמו"ט על עבירת אי רישום מאגר מידע (ואני די בטוח שהם ימצאו עוד סעיפים להאשים אתכם), ואם מחר חס ושלום יפרצו לאותו אתר ויפיצו את המידע, הנפגעים יכולים לתבוע אותו תביעה אזרחית ותנחשו את מי הוא יגרור אל התביעה הזו..
    לכן אם לקוח מתעקש לא לקחת איש אבטחת מידע, ואתם לוקחים את הפרוייקט, תצטרכו להחתים את הלקוח על מסמך שהוא זה שמבקש אתר ללא אבטחת מידע כפי שנדרש בחוק והוא לוקח את כל האחריות עליו ופוטר אתכם מאחריות (לא יודע כמה מסמך כזה הוא לגטימי, עדיף להתייעץ עם עו"ד).
  3. לקוחות שיש להם אתרי חנויות או כל אתר שאוסף מידע מגולשים: בלי אבטחת מידע גם הרמו"ט יכולה לתבוע אתכם ואם נפרץ האתר שלכם – אלו שזלג המידע שלהם החוצה יכולים לתבוע אתכם תביעה אזרחית על אי-הגנה על מאגר מידע ושלל סעיפים נוספים, לכן מומלץ להשקיע את הסכומים הנוספים ברישום ובאבטחה על מנת להימנע מהכאב ראש הזה.

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

איזו וירטואליזציה מומלצת?

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

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

להלן רשימת ה"חשודים העיקריים", ברשותכם:

  • Virtuozzo (או OpenVZ בגירסת הקוד הפתוח): אחת התוכנות הותיקות ביותר בשוק שבעצם די קיבעה בשוק מושג כמו Over-selling (שהספק מבטיח לך 1 ג'יגה זכרון, יש לו 20 לקוחות ויש במכונה 8 ג'יגהבייט זכרון) ואת המושג VPS בעצם (למרות שהוא לא ממש נתן לך באמת Private Server בהשוואה למצב כיום).
    יתרונות: במצב "טבעי" (הווה אומר: לא הרבה לקוחות על שרת פיזי אחד) המכונה נותנת ביצועים שהם כמעט כמו לרוץ על שרת פיזי. הטריק הוא כמובן שהמכונה לא ממש מריצה וירטואליזציה, אלא עושה הפרדה ע"י chroot (שזה root "כלוא"), כך שהאפליקציות שלך רצות במצב רגיל על השרת בלי תוכנה שצריך להמיר פקודות או לעבור מצבים שונים מבחינת מעבד, מערכת הפעלה וכו'.
    חסרונות: לא חסר! ספקים רבים "דוחפים" כמה שיותר לקוחות לשרת פיזי, מגדירים יותר זכרון ממה שיש במכונה, כך שהמכונה צריכה לעשות סימולציית זכרון נוסף ע"י שימוש בדיסק הקשיח, מה שמבטיח שהביצועים ירדו, נוסיף לכך שאין בוירטואליזציה הזו הפרדה ממשית בין הלקוחות, וכך לקוח שיש לו תהליך שתופס 100% מהמעבד יאיט את המכונה לכולם (אם כי יש כלים "להרוג" את זה, אבל אז יש לנו תהליך מת ולקוח עצבני).
    בנוסף, לא ניתן להתקין מערכות הפעלה שונות – יש CentOS 5.3 על השרת? זה מה יש ואי אפשר להתקין שום גירסת לינוקס אחרת (המצב שונה עם OpenVZ אך עדיין רוב הספקים לא מוכנים לתת מערכות לינוקס שונות על OpenVZ עקב עלויות תמיכה פנימיות) וכמובן לא Windows או כל מערכת הפעלה אחרת.
    והנקודה הכי בעייתית: המכונה משתמשת בקרנל (Kernel, ליבה) שמגיע עם ה"וירטואליזציה" וניתן רק להחליף לקרנל חדש יותר עם תמיכה באותה וירטואליזציה. הצרה היא שלשם כך יש צורך בלעשות Reboot והרבה ספקים חוששים לעשות Reboot פיזי לשרת כי הלקוחות יצעקו, וכך נוצר מצב עצוב שיש חורי אבטחה ואם מישהו עולה על חור אבטחה כזה, הוא יכול לגשת לכל החשבונות של הלקוחות ולעשות בהם כרצונו.
    המלצה: אם אפשר, לא לקחת חבילת VPS עם וירטואליזציה כזו. ישנם פתרונות אחרים טובים בהרבה.
  • Xen – וירטואליזציית קוד פתוח שב-5-9 שנים האחרונות תופסת מקום של כבוד בשוק ספקי שרת VPS. היא נכתבה ע"י סטודנטים וכיום היא בבעלות של חברת Citrix שגם משחררת מוצר עסקי (XenServer) וגם משחררת גירסת קוד פתוח של Xen.
    יתרונות: יש אפשרות להריץ גירסאות לינוקס אשר מקומפלות עם תמיכה ל-Xen ואז לקבל ביצועים כמו עם Virtuozzo, וגם אפשר להריץ מערכות הפעלה זרות (Windows, Linux, FreeBSD, Solaris ועוד). ל-Xen יש דרייברים מיוחדים (PV – Paravirtualized) אשר יודעים לשוחח ישירות עם החומרה הפיזית ובכך להאיץ ביצועים של דיסק, רשת ועוד.
    חסרונות: מבחינת ביצועים, המערכת נותנת ביצועים ממש לא רעים, אך לא בהשוואה למתחרה אחר בקוד פתוח (KVM) וגם לא מול המתחרה (VMWare). חסרון נוסף שלה הוא עניין התזמון (Scheduling) של מערכות הוירטואליות שרצות עליה (מי שמשתמש ב-Linode אולי מכיר את זה שלפעמים צריך לחכות כמה שניות עד שהמכונה מתחילה "לזוז" כמו שצריך ברגע שעושים אליה SSH). הבעיה מוכרת למפתחי Xen והם עובדים עליה בגירסה 4.3.
    לסיכום: Xen היא אפשרות לא רעה בשרת VPS, רק מומלץ לבדוק את הביצועים של המכונה לפני שסוגרים חוזה.
  • Hyper-V של מיקרוסופט: כמו תמיד, מיקרוסופט נכנסה לשוק באיחור רב, ומכיוון שלא היה להם טכנולוגיית וירטואליזציה, אז הם קנו חברה (Connectix) שהמוצר שלהם ממש לא היווה תחרות, וכיום המצב עדיין כך. Hyper-V הוא פתרון הוירטואליזציה של מיקרוסופט, הוא מגיע עם כל שרת Windows 2008 (יש גם גירסת Stand Alone) והוא תומך במספר מצומצם של מערכות הפעלה אורחות. הוא נמצא בשימוש רב אצל חברות וארגונים שמתעקשים אך ורק להשתמש בטכנולוגיות של מיקרוסופט ובשל מחירו ה"חינמי" כביכול.
    יתרונות: זהו מוצר הוירטואליזציה היחיד שמיקרוסופט תומכת בו רשמית מ-א' ועד ת', בין אם אתה מריץ עליו שרתי Windows אחרים כ"אורחים" או גרסאות לינוקס שונות. המוצר קל (יחסית) לשימוש ומהווה פיתוי לא קטן לחברות להשתמש בו במקום להשתמש במוצר המוביל או מוצרים מבוססים קוד פתוח – כי הוא "חינמי". כיום כבר יש לו ביצועים לא רעים.
    חסרונות: תמיכה במערכות הפעלה – מאוד סלקטיבית. רק לאחרונה נוספה תמיכה רשמית ל-CentOS, הוא תומך כבר זמן רב ב-Red Hat וב-SuSE. הוא עדיין לא תומך רשמית בהפצעות חופשיות אחרות כמו Debian ו-Ubuntu אם כי יש אפשרות לעבוד איתן תחת Hyper-V. מבחינת ביצועים הוא עדיין מפגר הרבה אחרי VMWare ואחרי KVM של RedHat.
    למעט אצל ספקים מסויימים (כמדומני בארץ אצל LiveDNS) רוב הספקיות שרתי VPS אינן משתמשות במוצר זה.
  • KVM – הפתרון של RedHat. זהו מוצר וירטואליזציה די צעיר (מ-2006 אם אינני טועה) שפותח ע"י חברת Qumranet הישראלית ונרכש ע"י רד-האט. אחד הדברים היפים ב-KVM זה שהוא בעצם לקח מה ש-Virtuozzo עשו ועשה את זה בצורה נכונה (עם טכנולוגיית VT של אינטל ו-AMD): כל מערכת הפעלה היא Process עצמאי, שאפשר להפעיל עליו כלים שונים כמו nice כדי להאיט/להאיץ/לתעדף ביצועים של מערכת הפעלה אורחת. KVM שואב הרבה מ-Xen ופרויקט קוד פתוח אחר (שלעבדכם הנאמן היה הכבוד ללוות): QEMU. כיום המוצר נמכר ע"י RedHat תחת השם RHEV (שאגב, גירסה 3.0 שלו יצאה היום) והוא גם קיים בכל הפצת לינוקס עם כלי ניהול חדש (שיצא רשמית ב-31/1 השנה) בשם Ovirt.
    יתרונות: ביצועים ביצועים ביצועים – KVM יודע לתת פייט מאוד רציני למוביל (VMWare) בכל הקשור לביצועי וירטואליזציה ואם חברות חושבות לעזוב את המוביל לטובת פתרון קוד פתוח, אז מומלץ לנסות את KVM. בנוסף KVM יודע לתמוך בכל מערכות ההפעלה, הוא חלק מליבת הלינוקס, וקל להתחיל להשתמש בו (בהתקנה של Fedora לדוגמא, כל מה שצריך להפעיל פקודת virt-manager וכבר יופיע ממשק גרפי להגדרות וכו').
    חסרונות: המערכת בגירסת הקוד הפתוח עד היום לא היתה קלה לניהול. לא שהיו חסרים כלים לניהול (ישנם ספריות, מערכת ניהול דרך command line בשם virsh שיודעת גם להתממשק למערכות וירטואליזציה אחרות), אבל היה צריך להושיב מפתח כדי להרים מערכת נורמלית להקמה והטמעה של KVM. כיום יש כבר את Ovirt שאפשר להוריד ולהתקין, והוא מאפשר חיים יותר קלים בניהול.
    חסרון נוסף הוא שמכיון שהמערכת צעירה ומשתנה מאוד (עד לפני שנה היה צריך שרת Windows כדי לנהל את המערכת), עדיין חסר לה ספרות ודוקומנטציה מלאה לכל הדברים. בנוסף, עדיין יש פה ושם בעיות (כמו: התקנת Windows 2008 בפעם הראשונה לוקחת יותר מחצי שעה, פי 5 מכל פתרון אחר!).
    KVM נמצאת בשימוש אצל ספקים מסויימים (עם Proxmox), אך מערכות אלו עדיין לא מספיק חזקות ויציבות (גירסה 2.0 של Proxmox תתמוך בגרסאות האחרונות של KVM והספריות הנלוות). במהלך החודשים הקרובים יכנס Ovirt לשימוש וכלים אחרים, ולספקים יהיה יותר נוח להטמיע פתרון מלא מבוסס KVM. (אצלנו ב"חץ ביז" התחלנו להשתמש ב-KVM למערכות לא חיוניות ואנחנו לאט לאט מפתחים פאנל חדש ולקוחות שירצו יוכלו במהלך השנה לבחור את הוירטואליזציה שירצו)
  • VMWare – המובילים, ה"מלכים" בכל תחום הוירטואליזציה. אין הרבה מה לאמר עליהם חוץ מהעובדה שזה התחום שהם מובילים בו בכל העולם (70% משוק הוירטואליזציה נשלט על ידם לפני גרטנר).
    יתרונות: אין סוף. יציבות, מהירות, תמיכה בציודים שונים, מתפתחים די מהר ובקיצור – אם יש לך פתרון מבוסס vSphere של VMWare, אין לך מה להסתכל אצל אחרים.
    חסרונות: מגירסה 5 המחירים טיפסו בטירוף מעלה, מה שגרם לחברות רבות להישאר בגירסה 4.1 האחרונה. יש תוספות מאוד נחמדות ל-vSphere-5 (כמו האפשרות לאחד מספר שרתים וליצור Storage מכובד ועוד דברים), אבל המחיר אוי המחיר שהם מבקשים..
    מבחינת ספקי שרתי VPS – בארץ לא מעט ספקים משתמשים בגירסת ה-ESXI החינמית, בחו"ל יש ספקים שמאפשרים וירטואליזציה עם VMWare תמורת מחיר של 50$ חודשי עבור הרשיון (פר מכונה וירטואלית).

לסיכום: לכל וירטואליזציה יש יתרונות וחסרונות. יש וירטואליזציות מהירות אך שהאבטחה בהן גרועה מאוד (Virtuozzo). יש וירטואליזציה מעולה אך שתצטרך להוסיף תשלום עליה (VMWare), ויש טכנולוגיות וירטואליזציות שונות בשימוש נרחב (Xen אצל Amazon, Linode) אך הן אינן נותנות את מיטב הביצועי וירטואליזציה.

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

בהצלחה

כשבוחרים ספק לשרות VPS

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

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

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

אני יכול לתת דוגמא מהעסק שלנו: אנחנו מתמקדים בשרתי VPS המיועדים לתחום ה-Prosumer  כלומר לשוק שמורכב גם ממקצוענים שמכירים היטב ולעומק מה זה VPS, מה זה שרת וירטואלי, מה ניתן ומה לא ניתן לעשות איתו, איך להגדיר אותו, איך לשנות אותו מכל צד אפשרי, לעשות לו אופטימיזציה ועוד, וגם לאנשים עצמם שמתכנתים, אנשי סיסטם (שיש להם בעבודה שרתים וירטואליים והם מנהלים אותם או שהם מנהלים של המחלקות הללו), אינטגרטורים, בוני אתרים מקצועיים, אנשי QA ועוד. גם האחסון המשותף שלנו שונה מאוד מאחסון אתרים שאחרים נותנים, כי אצלנו שמים דגש יותר על תמיכה של שפות נוספות, כלים (כמו GIT,SVN וכו') לניהול קוד, בקרה, והגבלת המשתמש כדי שלא יוכל "לחנוק" משתמש אחר (כן, גם באחסון משותף). אם מישהו שלא מבין כלל בתחום מגיע אלינו והוא רוצה לאחסן אתר, אנחנו נבקש לסגור את הפרטים הטכניים מול בונה האתרים שלו ולא איתו. אם אין לו בונה אתרים והוא לא מבין כלום בנושא ורוצה להרים בלוג משלו, נשמח להפנות אותו למתחרים, כי זה לא התחום שלנו. אנחנו לא נותנים שרות ל-End Users אבל רוב הספקים הישראלים שנותנים שרותי אחסון אתרים (אחסון משותף) נותנים בשמחה למשתמשי קצה, אז שירוויחו, בשמחה.

זה הפוקוס אצלנו.

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

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

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

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

בהצלחה

אחסון משותף וחשיבות תחזוקה שוטפת

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

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

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

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

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

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

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

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

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

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

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

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

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

מיתוס: מחשוב ענן בישראל

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

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

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

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

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

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

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

היכן לאחסן ומה לבדוק

שנים רבות אני שומע את השאלה הבאה בגרסאות שונות "אני בונה אתר ואני רוצה לאחסן אותו. מכיר מישהו מומלץ?" או "יש לי אתר באחסון XYZ אבל אני לא מרוצה מהשרות. מכיר חברה אחרת מומלצת?"

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

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

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

  • אתר קטן או מספר אתרים קטנים: אם יש לך אתר קטן או מספר אתרים קטנים ואין חשיבות לזמן הטעינה שלהם, כמו בלוגים אישיים עם מספר מבקרים קטן, אתרים אישיים קטנים עם מספר נמוך של מבקרים ואתרים קטנים נוספים אשר אינם מקודמים (SEO) – אז אפשר לאחסן את האתר בארץ, בארה"ב או אירופה באחסון משותף.
  • בלוגים או אתרים קטנים עם מספר גולשים של מאות ביום או בלוגים מקודמים (SEO) עם קהל יעד ישראלי : בקידום אתרים יש חשיבות גדולה האם האתר נטען מהר או לא (לא רק ה-HTML של הדף הראשי אלא גם תמונות וכו') , ואתר קטן/בלוג עם כמות קוראים רבים צריך שהמידע יגיע כמה שיותר מהר לגולש – אתרים כאלו מומלץ לאחסן בארץ, ואם הפתרונות בארץ יקרים מדי לפונה, אחסון משותף באירופה יכול לתת תוצאות לא רעות (אם כי המהירות מאירופה וחו"ל אל ישראל יכולה להשתנות עקב האטת תקשורת מכוונת מצד ספקי התקשורת הישראליים).
  • אתרים בינוניים המיועדים לקהל הישראלי (מושכים כמות של אלפי גולשים ליום) – חד וחלק, חפשו אחסון משותף או שרת VPS (שרת וירטואלי) כאן בישראל. יכול להיות שהמחיר יהיה טיפה יותר יקר (על הבדלי המחירים אכתוב כאן בפוסט אחר), אך מצד שני הגולשים שלכם יקבלו את המידע בצורה מהירה וזורמת (תלוי כמובן בספק, רוחב הפס שלו, שרת VPS שלו וכו' – ואלו עניינים לפוסט אחר).
  • אתרים גדולים (עשרות אלפי גולשים, אלפי גולשים שמעלים תוכן ביום) המיועדים לקהל ישראלי – מומלץ לרכוש שרתים יעודיים מיבואני שרתים (DELL, HP, IBM וכו') ולארח אותם בחווה שהספק מארח. המחיר יצא זול בהרבה מאשר לקחת שרת וירטואלי מפלצתי שלא בטוח שיעמוד בעומסים ויהיה יקר בצורה משמעותית מאירוח שרת פיזי בחווה.
  • אתרים/שרותים בינוניים וגדלים המיועדים לקהל עולמי: כאן לצערי פתרון בישראל לא יסייע לך ("תודות" לספקי התקשורת הישראליים) אולם פתרון מקובל אחר שרבים משתמשים בו (השכרת שרתים/VPS בארה"ב) גם אינו הפתרון הכי יעיל. אם אתה מייעד את הפתרון שלך ככלל עולמי, עדיף לקחת פתרון באירופה (ישירות או דרך ספק ישראלי שיש לו שרתים באירופה). מדוע? כי רוחב הפס בין אירופה לשאר המקומות בעולם גדול משמעותית ממה שיש בין ארה"ב לשאר העולם.
  • פתרונות מורכבים (מספר שרתים וירטואליים ו/או יעודיים עם Load Balancer וכו') – רבים מעדיפים לקחת פתרונות כאלו מ-Amazon (כשמדובר בשרתים וירטואליים, אמזון אינה משכירה שרתים יעודיים ואינה נותנת שרותי Colo), אולם מומלץ לחשוב גם על פתרונות מספקים אחרים ולשקול אותם בגלל סיבה פשוטה: הפתרון של Amazon (ו-Amazon היא רק דוגמא אחת) הוא פתרון "נעול", כלומר אם מחר בבוקר לא תהיה מרוצה מהשרות שלהם/שרתים שלהם, אינך יכול לקום ולעבור ספק תוך יום יומיים, תצטרך לשנות מהקצה אל הקצה את כל התשתית שלך, דבר שיעלה לך לא מעט, ולכן לפעמים דווקא כדאי לקחת פתרונות סטנדרטיים (לדוגמא: מספר שרתים וירטואליים ו-Load Balancer בחומרה או תוכנה) כשהאיש הטכני שלך מגדיר אותם, ואם תרצה לעבור, כל מה שיהיה צריך לעשות זה לשכור חבילות זהות, וכל מה שנותר לאיש הטכני שלך יהיה להעתיק את התוכן מהשרתים הישנים לחדשים, לשנות כתובות, ולהגדיר את ה-LB מחדש, וזה לוקח רק חלקיק מהזמן שלוקח לעבור מ-Amazon.
  • לא להיות "יד רביעית": ישנם ספקים גדולים בעולם (המקרה הכי ידוע: חברת OVH) שמעדיפים לא לעבוד עם מדינות שונות (ובכללן ישראל) מסיבותיהן הפרטיות. מה קורה אז? מישהו באותה מדינה שוכר שרת/ים, משכיר אותם למישהו אחר (נניח בישראל) ואותו ישראלי משכיר לך את השרת, כלומר אתה בעצם "יד רביעית" (הספק עצמו, האזרח הזר, המשכיר הישראלי, ואתה) וכולם מרוויחים עליך לא רע. במקרה ויש לך תקלה או בקשת שדרוג והמשכיר הישראלי לא יודע או לא יכול  לפתור אותה, התקלה צריכה "להשתרשר למעלה" בכל המסלול, לכן מומלץ מאוד לשכור דרך נציג ישראלי שיש לו שרתים משלו (או שהוא שוכר שרתים) אצל הספק עצמו ולא דרך צד שלישי. זכור כי במידה והספק מצא לדוגמא שאתה ישראלי והוא אינו מעוניין לעשות עסקים עם ישראליים, הוא יכול פשוט לקום ולנתק את השרת, ולך תריב עם המוכר הישראלי או הבחור במדינה זרה שמכר לישראלי.
  • לא לשכור שרת VPS על סמך אתר בלבד: באתרים של ספקים הכל כתוב בצורה יפה ומושכת. המפרט הטכני מדבר על מעבדים חזקים, רוחב פס נדיב וכו'. אם אתה מעוניין בחבילה, בקש אותה ליום יומיים נסיון ותנסה "להתיש" את השרת VPS (לדוגמא) בסימולציות של מבקרים רבים, (בכמות שאתה מתכנן) ותוודא כי השרת עומד ביעדים שהגדרת. רק לאחר מכן כדאי שתסגור את העיסקה ותוודא שהשרת שקיבלת לניסוי – הוא זה שתקבל ולא אחר (טריק שיווקי ידוע).
  • חשוב לוודא שהספק נותן לך דברים מסויימים שאותם תצטרך בהמשך הדרך:
    • רוחב פס המוקצה לשרת שלך בכל הזמן (לא "מתפרץ"). מומלץ שתבדוק מדי פעם אם יש ברשותך את הרוחב הפס הנ"ל.
    • גישה לקונסולה ו/או KVM באופן מיידי (במקרה ואינך מצליח לגשת לשרת מרחוק אם בטעות נעלת את עצמך מרחוק). ספקים מסויימים לא נותנים זאת ובמקום זה מבקשים ממך סיסמת root על מנת לבצע מה שאתה רוצה – אל תיתן סיסמת root. אינך יודע מי הולך לטפל בשרת, מה הידע שלו ומה באמת הוא עושה.
    • הצמד שרות ניטור משלך לשרת הוירטואלי/יעודי שלך, לא תמיד תקבל התראה אם השרת שלך נפל.
    • ודא כי אם מדובר בשרת VPS, שהוירטואליזציה היא מלאה ואתה יכול לשדרג כל חלק במערכת עצמה ולא רק חלקים מסויימים, וכדאי שתבדוק באיזו וירטואליזציה מדובר.
    • החלף סיסמת root לאחר שקיבלת את המכונה וודא כי איש אינו נמצא במכונה זולתך.
    • ודא כי ישנה אפשרות התקנת כל העדכונים במערכת וודא כי האיש הטכני שלך מריץ עדכונים לפחות אחת לשבוע.

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

בהצלחה

נקודות למחשבה לסטארטאפיסט

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

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

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

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

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

אז מכיוון שבהתחלה (הווה אומר: חודשים ראשונים) מי שמשלם על התשתית זה אתה ו/או שותף שלך ואין לך דוד/מכר מיליונר עם סיגר עבה בפה / קרנות כלשהן שמוכנות לשפוך עליך כספים רבים שתשיג אנשי מכירות, פרסום מאסיבי ועוד, תצטרך להתחיל במשהו קטן ורק לאחר שתהיה המאסה תוכל לתכנן מחדש ממש בגדול. במילים אחרות: את התכנון של 3 שרתי אפאצ'י בפרונט, 3 שרתי אפליקציה, 2 שרתי SQL, ו-Load Balancer עם ראוטר וחומת אש עצבנית – כדאי להשאיר לזמן שתהיה לך מאסה גדולה וקבועה.

לכן, כשמתחילים צריך לקחת שרת וירטואלי (עדיין לא יעודי, המחיר של יעודי יקפיץ בעוד כמה מאות דולרים לחודש) טוב עם ליבה אחת (מומלץ 2 אם אפשרי מבחינת תקציב) וזכרון של לפחות 1-2 ג'יגה (אם מדובר בשרת Linux) או 2-3 ג'יגה (אם מדובר בשרת Windows. מה לעשות, Windows שותה זכרון עם צינור). מבחינת רוחב פס, ודא כי הספק נותן לך לפחות 5-10 מגהביט סימטרי (לא "מתפרץ", שזה בעצם טריק שיווקי למכור שליש מוצר במחיר של מוצר) ומתחייב על כך בחוזה. מבחינת דיסק, כדאי שיהיו כמה עשרות ג'יגהבייט בתור התחלה. ודא שיש לך אפשרות לקבל קונסולה אם במקרה נעלת את עצמך בטעות (כמו במקרה של טעות בהגדרות SSH או חוק שגוי בחומת האש הפנימית) מבלי להתחנן לתמיכה שיפתחו לך.

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

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

  • Cache חובה: לא חשוב כמה האתרים שלכם דינמי, חלקים רבים בתוכו הם סטטיים – תמונות, סקריפטים, תכנים, דף פתיחה ועוד, וכל החלקים האלו אפשר ליצור להם קבצים סטטיים שיוגשו לגולש ואפליקציית Cache תייצר אותן תוך מעקב מה בתוקף ומה לא. אם אתם משתמשים באפליקציות CMS, אז ברוב המקרים זה רק עניין של התקנת תוסף פשוט שיתן לכם את זה. שימוש חכם ב-Cache יכול לחסוך את רוב העבודה שהשרת צריך לעשות כדי לתת תכנים מותאמים לגולש.
  • אופטימיזציית SQL – זה משהו אחד שיש לך 2 שרתי SQL מאסיביים שרצים עם סינכרון/רפליקציות עם תקציב שנתי רצינית, וזה משהו אחר שאתה סטארט אפ ויש לך תקציב ששווה לתקציב הקופה-הקטנה של גוגל. שרת ה-SQL שלך צריך לעבוד בצורה אופטימלית וחזקה. אם אתה משתמש לדוגמא ב-MySQL, אז יש כאן לדוגמא מדריך איך לעשות זאת, וכל שרת SQL מכובד כולל אתר שלם איך לעשות אופטימיזציות, החל בבחירת מנוע נכון (InnoDB, MyISAM וכו'), הגדרת כמות חיבורים בהתאם לכמות הזכרון והצורך, ועד ל-Queries בלתי אופטימליים (דבר שגורם "מריבות" בין מפתחים שונים, גם את זה ראיתי).
  • שרת WEB טוב: הנה עובדה – שרת Apache על VPS כמו שפירטתי מקודם שמוגדר טוב (עם כל ה-MPM, מודולים וכו') יכול לשרת כמה אלפי אנשים סימולטנית מבלי לחנוק את הליבה של ה-VPS ומבלי לגרום ל-Load היסטרי. גם שרת NGINX יכול לבצע את העבודה הזו מבלי לחנוק משאבים, כל מה שצריך זה תכנון ובדיקה (לא חסרים כלים להעמיס שרתים). אם פעם אחת יושבים ומגדירים את זה בצורה טובה, אז יהיו לכם לילות ללא יקיצה בגלל שרת קורס. חשוב להגדיר בשרת Cache לדברים שלא הולכים להשתנות כל דקה (לדוגמא: קבצי Header ו-Footer).
  • אבטחה: יודעים מי ינסה לבדוק כמה האתר שלכם מאובטח? המתחרים שלכם, ובמקרים רבים המתחרים שלכם מכאן בארץ. חושבים שלא ינסו לבדוק SQL Injection וכל חור אפשרי? הם בהחלט ינסו, כי זו השיטה הכי טובה לגלות סודות מסחריים שלכם (במיוחד דפים וקבצים נסתרים שמיועדים ללקוחות Beta סגור). לכן כדאי לבדוק את כל הרכיבים כולל אלו שלא תהיה להם גישה מבחוץ. נסו לסרוק את השרת שלכם עם nmap, או SNORT (לא, הוא עוד לא מת) וכלים אחרים, חפשו כלים אחרים, בדקו XSS, נסו לבצע SQL Injection ותקנו את כל החורים.
  • עבדו עם גירסאות יציבות של מערכות הפעלה. ב-Windows זה Non issue, משתמשים ב-2008 R2, בלינוקס לעומת זאת מומלץ שלא להשתמש בגרסאות שמשתנות כל הזמן כמו Ubuntu הרגיל (קח את Ubuntu LTS) או Fedora (קחו CentOS 6 או Scientific Linux 6.1) והקפידו להריץ עדכון לפחות אחת לשבוע.
  • צרו גיבוי מרוחק – כל ספק יכול להבטיח שהגיבוי שלו סוף הדרך, שזה נחמד, אבל עדיף שיהיה לכם לפחות אחת לחודש גיבוי של האתר וה-DB אצלכם בידיים או בשרת מרוחק אחר (זה לא מסובך: mysqldump לבסיס הנתונים, rsync לשאר, להריץ הכל ב-cron ונגמר העניין).

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

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

רק הצלחה!