מאת: צליל שילה יועץ מתודולוגי בחברת Comm-IT
‍

Software as a Service ובקיצור SaaS, הינה טכנולוגיה המאפשרת לספק תוכנות או שירותים בממשק Web שלא באופן מקומי אלא באמצעות אירוח מקוון בענן. יותר ויותר תוכנות מתבססות כיום על SaaS. ההנגשה הנוחה של השירות ללקוח, המאפשרת לו להשתמש בתוכנה ללא התקנה ועדכון שלה, מושכת עוד ועוד לקוחות מסקטורים שונים.

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

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

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

• Cognito – שירות לניהול אימות לקוחות ומתן הרשאות לאפליקציה ב-Web או בנייד, תוף שימוש בשני רכיבים: בריכת משתמשים – האחראית על הרשמה והתחברות של משתמשים לאפליקציה, ובריכת זהויות – המאפשרת גישה למשתמש בהתממשקות עם רכיבי AWS אחרים.
• Cloud Front – רכיב המשמש ממשק חזית (Frontend) אליו גולשים הלקוחות ומאפשר גישה לתכנים בענן מהשרת הקרוב ביותר גיאוגרפית, במטרה לספק ביצועים איכותיים ככל הניתן.
• Web Application Firewall (WAF) – אפליקציה המהווה חומת אש חכמה אשר בודקת את הבקשה בצורה כירורגית ויורדת לפרטי תוכן הבקשה על מנת לזהות בקשות זדוניות, או בקשות החורגות מהפורמט המקובל
• Application Load Balancer (ALB) – רכיב אשר מתקשר עם כל השרתים, ויודע לנווט בקשה שהגיעה לשרת מסוים במטרה לחלק עומסים בין השרתים ולפי הזעירות (Micro-service) הרלוונטי אליו הבקשה צריכה להישלח.

בין כלל הרכיבים קיים קשר המאפשר ללקוח להזדהות ולעבור בין שכבות הארכיטקטורה עד למידע הרלוונטי אליו. הרכיב אשר מאפשר את המעבר הרוחבי בין השכבות הינו Identity and Access Management  (או בקיצור: IAM), אליו מופנות כל הבקשות של הלקוח.
הרכיבים השונים שהוזכרו לעיל מהווים את התשתית עבור אפליקציית ה-SaaS, אולם קיים טווח של מודלים ארכיטקטוניים שניתן ליישם תוך שימוש ברכיבים הנ"ל. שני המודלים המייצגים את קצוות הטווח הם מודל Pool ומודל Silo, שבהם נדון להלן.

מודל Pool. במודל זה מספר דיירים חולקים תשתית אחת, כאשר כלל המידע של הלקוחות השונים מאוחסן  בבסיס נתונים או ב-Bucket אחד. מחד, היתרון המרכזי של מודל זה הוא יחס עלות-תועלת גבוה מכיוון שהספק מנהל רק תשתית אחת מרכזית להרבה לקוחות, ומנצל את המקום לאחסון בצורה טובה ונכונה יותר. מאידך, החסרונות במודל זה הם האתגרים שהוצגו. אבטחת המידע, טובה ככל שתהיה, אינה הרמטית ודורשת פתרונות בכדי להתמודד עם האיומים על פרטיות המידע של כל לקוח. המודל מתמודד עם האתגר על ידי שילוב של מספר פתרונות. הפתרון הראשון הוא אימות איכותי של המשתמש על בסיס מספר גורמים (Multi-factor Authentication), ולאחר מכן הגדרת Token לכל משתמש שמתחבר, המורכב מזיהוי משתמש (User ID), מזהה דייר (Tenant ID) ותפקיד הדייר (Tenant Role) אשר חוצה את השכבות בארכיטקטורה ומלווה את הבקשה על מנת להתקדם עד לגישה למידע. הפתרון השני לאתגר אבטחת המידע במודל זה הוא חלוקה (Partitioning) של בסיס הנתונים לפי לקוח כך שלכל לקוח יש גישה רק לחלק שאליו הוא מורשה. עם האתגר השני, המאופיין בהשפעה של לקוח שמעמיס על השרת ובכך פוגע בביצועים של לקוחות אחרים על אותו שרת, יודע המודל להתמודד באמצעות גמישות בגודל וכמות השרתים וכתוצאה מכך מזעור הפגיעה. השימוש ב-Auto Scaling של AWS מאפשר להגדיל או להקטין את מספר השרתים ובכך לחלק אל העומס בין כלל השרתים.

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

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

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

‍

‍