כמה מילים בעניין חוק המחשבים

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

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

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

כשזה מגיע לאבטחת מידע, רוב החברות שבטוחות שהן מוגנות ב-95%+ הן טועות, מכיוון שברוב החברות רוכשים כל מיני פתרון כמו חומות אש, WAF, IPS/IDS וכו' ולפיכך הן סוברות שהן מוגנות. ההגנה שהציודים הללו נותנים היא חלקית בלבד. פורץ מתוחכם לא יחפש איך לתחמן את חומת האש או ה-WAF שלך, אלא יכנס לקוד שהדפדפן מוריד למחשב המקומי ולפרמטרים בשורת ה-URL. בחלקים הללו הוא ינסה למצוא את הכשלים והחורים. אחד הטיעונים המגוחכים ששמעתי ש"אין למשתמש שמריץ את ה-web service אפשרות shell". מדוע מגוכך? כי אפשר ליצור shell בכל שפה דרך הדפדפן. להלן דוגמא של shell ב-PHP שכל מה שהפורץ צריך לעשות זה למצוא מקום שההרשאות יותר מדי פתוחות כדי להעלות את הקובץ ומשם לחגוג (אם בשרת יש תמיכת PHP).

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

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

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

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

בשביל לדווח על פריצה, יש צורך ב-3 דברים:

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

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

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

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

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

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

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

אשמח לשמוע את דעתכם.

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

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

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

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

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

בדרך כלל, לפני פריצה כזו, הם יבצעו תחקיר בסיוע כל דבר אפשרי (ריגול דרך האינטרנט ברשתות חברתיות, ריגול "קלאסי" תוך שימוש בסוכנים שנמצאים בארץ) כדי למצוא מי האנשים שאותם הם הולכים לתקוף במובן הסייבר. הם יחפשו אנשי IT ואם אפשר – אנשים שיש להם כמה שפחות ידע/נסיון בתחום ה-IT אך שיש להם גישה פנימית למערכות, אחד כזה שלמחשב שלו בעבודה יש חיבור לאינטרנט ול-LAN הפנימי, והוא לא ממש שם לב לשינוי בין URL כמו secure.iec.co.il ל-secure.iec.co.il.info (דוגמא פיקטיבית, אין לי מושג ירוק בתשתית של חברת חשמל). נניח שהראשון מפנה ל-ADFS או משהו חשוב אחר. ה-URL השני שנתתי הוא מזויף והפורצים הקימו אותו (כולל העתקה של גרפיקה עד לביט האחרון) כך שאותו איש IT לא יחוש בסכנה ויכניס את פרטיו האמיתיים להיכנס למערכת. (אגב, טריק ששמעתי שמשתמשים בו אחרי הכנסת שם משתמש וסיסמא הוא להציג הודעה של שם משתמש/סיסמא שגויים כדי "לשאוב" שמות משתמש וסיסמאות נוספות מאותו איש IT).

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

מהרגע שאותו קובץ פועל, לפורצים יש בעצם גישה. סביר להניח שהם יפתחו איזו מערכת C&C (ר"ת Command & Control) כדי לראות איך לגשת אל המערכת, ומכיוון שמשתמשי IT רבים משתמשים בתוכנות כמו SecureCRT ותוכנות אחרות המאפשרות גישה במקביל לשרתים, יש עכשיו לפורצים דרך להיכנס למערכות האחרות עם ההרשאות של אותו איש IT ומהמחשב שלו, כך שסביר להניח ששום מערכת מניעה לא ממש תזהה פעילות חריגה. תזכרו – בשלבים הראשונים, הפורצים לא משנים קבצים וקונפיגורציות, הם לומדים.

אז … מה ניתן לעשות כדי להקשות?

יהיו כאלו שיציעו להשתמש ב-Smart Card. רעיון לא טוב, מכיוון שבד"כ ה-Smart Card נמצא בתוך המחשב ולא מוציאים אותו ואת ה-PIN אפשר לתפוס עם key logger. אז הפתרון הזה עף החוצה.

פתרונות אחרים שיכולים לעזור, הם פתרונות שבעצם מבוססים על אימות כפול, תוך שימוש בטביעת אצבע עם ציוד בחיבור USB או באמצעות TOTP (ר"ת Time Based One Time Password) שמותקן על הטלפון הסלולרי. אפליקציה פופולרית לכך (שנמצאת ב-Repo של כל הפצת אינטרנט) היא Google Authenticator (האפליקציה לא מצריכה חיבור אינטרנט).

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

  • מערכות לינוקס רחוקות עם כניסת SSH: אם נחליט על TOTP עם שימוש באפליקציה כמו ה-Google Authenticator (יש אפליקציות אחרות ויש גם את המפתחות RSA המפורסמים, כולם עושים את אותה עבודה), נוכל לעקוב אחר ההוראות כאן כדי להתקין זאת. משהו שצריך לקחת בחשבון – תצטרכו להעיף מפתחות SSH מקובץ ה-authorized_keys על מנת שה-TOTP יפעל. כך שתנסו להיכנס לאפליקציה, המערכת תבקש ממכם קוד וידוא שיופיע לכם באפליקציה בטלפון (או במפתח RSA הפיזי).
  • מערכות לינוקס/Windows מרוחקות עם כרטיס Yubikey (גוגל בקרוב מוציאה מוצר מתחרה שנקרא Google Titan, גם הוא פתרון מבוסס FIDO2) – בדרך זו יש לחבר ל-USB מפתח ובכל פעם להעביר את האצבע כשיש צורך לבצע אותנטיקציה. השיטה הזו יותר מאובטחת משיטות שימוש בקורא טביעות אצבע שמובנה במחשב). גם כאן, תצטרכו לבצע תהליך התקנה, רק שכאן יש גם שימוש ב-OpenPGP. כל הפרטים נמצאים כאן.
  • מערכות Windows (תוך שימוש ב-RDP): פתרון חינמי אין למיטב ידיעתי, יש פתרון מסחרי שתומך גם ב-TOTP וגם ב-FIDO2, יש פתרון של חברת ROHOS כאן.

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

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

מדינת ישראל, למי שעדיין לא יודע, היא מדינה עם כמות סטארט-אפים ענקית יחסית לגודלה. אנחנו למען האמת שניים רק לעמק הסיליקון בארה"ב, ושם בהחלט מכירים את ישראל וחברות ענק שרוצות לרכוש טכנולוגיה, יודעים היטב שהם יצטרכו לבדוק פה באזור חיוג 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 ונגמר העניין).

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

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

רק הצלחה!