שיטות מומלצות לאבטחה של ניתוח נתונים מוטמע

עם ניתוח נתונים מוטמע של Looker, אתם יכולים לאפשר למשתמשים וללקוחות שלכם לחקור נתונים שמוטמעים ב-iframe בכל דף אינטרנט, פורטל או אפליקציה בפורמט HTML. ה-iframe מריץ את כל אפליקציית Looker, ומבקש רק את הנתונים שדרושים להצגת השאילתה. כברירת מחדל, ל-iframe אין הרשאה לקרוא או לכתוב נתונים מהאתר או מהאפליקציה החיצוניים שלכם.

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

• אם אתם מטמיעים תוכן מ-Looker אצל לקוחות, כדאי להגדיר את תוכן הלקוחות במופע נפרד של Looker מהמופע שבו אתם משתמשים לניתוח נתונים פנימי.
• אפשר לקשר נתונים רק למופע המוטמע של Looker שמשתמשים בהטמעה צריכים לגשת אליו, וזה יכול להיות כל אחד.
• צריך להגן על הטוקנים האקראיים בכתובות URL ציבוריות להטמעה כאילו היו פרטי כניסה של משתמשים, ולהשבית כתובות URL ציבוריות אם לא נעשה בהן שימוש.
• ערך external_user_id שמוקצה חייב להיות ייחודי לכל קבוצה נתונה של הרשאות, מאפייני משתמשים ומודלים. חשוב לוודא שאתם לא משתמשים באותו external_user_id בכמה סשנים שונים של הטמעה למשתמשים אינטראקטיביים שונים, וגם לא משתמשים באותו external_user_id למשתמש יחיד שיש לו הרשאות שונות, ערכי מאפייני משתמש שונים או גישה למודל שונה.
• הפעלת מערכת סגורה.
• חשוב להגן על הסוד של ההטמעה החתומה כאילו מדובר בהרשאות אדמין במופע Looker המוטמע, ולהשאיר את ההטמעה החתומה מושבתת אם לא משתמשים בה.
• מומלץ להשתמש באימות חזק עבור מופעי Looker שמוטמעים באתרים אחרים (הטמעה עם חתימה, SAML, Google OAuth, אימות דו-שלבי).
• אם אתם משתמשים בהטמעה ללא קובצי Cookie, עליכם להגן על אסימון ההפניה של הסשן כדי שניתן יהיה לגשת אליו רק בשרת המארח של אפליקציית ההטמעה. אסימון ההפניה של הסשן לא אמור להיחשף בדפדפן.
• אם אתם משתמשים בהטמעה ללא קובצי Cookie ומגדירים את הדומיין המוטמע המותר כשאתם מקבלים את הסשן ללא קובצי Cookie, אל תסמכו אף פעם על המקור מהדפדפן של המשתמש שהטמיע את הסרטון. חשוב לשמור תמיד מיפוי של המשתמש בהטמעה למקור המהימן של המשתמש בהטמעה בשרת האפליקציה להטמעה.

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

הטמעה ציבורית

אם האפשרות גישה ציבורית של Look מופעלת,אפשר להטמיע תרשים או טבלת נתונים באתר חיצוני באמצעות תג iframe ב-HTML. אפשר גם לשתף את כתובת ה-URL של טבלת Look באופן ציבורי או לייבא נתונים לגיליונות אלקטרוניים ב-Google או ב-Excel.

כתובת ה-URL וכתובת ה-URL להטמעה בתג iframe מכילות טוקן אקראי, ואי אפשר לנחש אותו. עם זאת, כל מי שיש לו את כתובת ה-URL להטמעה יכול לגשת לנתונים, ולא מוחלים סינון או הגבלות נוספים. מומלץ לשקול את ההשלכות על האבטחה של יצירה ושיתוף של כתובת URL ציבורית ל-Look מסוים לפני שמפעילים את האפשרות כתובות URL ציבוריות.

כתובות URL ציבוריות וכתובות URL ציבוריות להטמעה אף פעם לא פוקעות, ואי אפשר לבטל אותן. כשמשתפים כתובת URL ציבורית, משתפים את השאילתה ולא את הנתונים עצמם.

הטמעה פרטית

אם אתם לא רוצים לאפשר גישה ציבורית ל-Look, אתם יכולים גם להטמיע Look – או ניתוח ב-Explore או לוח בקרה – באופן פרטי ב-iframe, כך שתידרש התחברות ל-Looker כדי לצפות בתוכן.

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

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

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

הטמעה חתומה

כדי לעדכן את הרישיון שלכם לתכונה הזו, אתם צריכים לפנות למומחה מכירות של Google Cloud.

הטמעה עם חתימה היא שלב נוסף מעבר להטמעה פרטית. בהטמעה עם חתימה, המשתמשים לא צריכים לעבור אימות באמצעות חשבון משתמש ב-Looker. במקום זאת, אפשר לאמת אותם דרך האפליקציה שלכם באמצעות כתובת ה-URL ב-iframe. האימות יוצר סשן חדש בדפדפן ומנפיק קובץ Cookie לדפדפן.

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

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

פרמטרים מוטמעים חתומים

הפרמטרים שכלולים בכתובת ה-URL של ה-iframe גלויים למשתמשים שמשבצים את ה-iframe, אבל הם לא ניתנים לעריכה. למשל:

• ‫user_attributes: משמשים לסינון נוסף של הנתונים. ‫user_attributes הן תכונות עוצמתיות, ולכן כדאי לחשוב איך אפשר להשתמש בהן במופע Looker שלכם.
• session_length: כדאי להגדיר את הזמן הזה למינימום הנדרש.

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

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

ניהול הגישה להטמעה חתומה

כשיוצרים את כתובת ה-URL של התוכן המוטמע:

• משתמשים ברמת הרשאות הנמוכה ביותר שנדרשת.
• מקצים גישה רק למודלים ספציפיים שהמשתמש צריך לקבל אליהם גישה.
• משתמשים ב-group_ids כדי להקצות משתמש לקבוצה ולאפשר למשתמש שמוטמע לשלוט בגישה לתיקייה שלו ב-Looker.

Looker API

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

ניהול הגישה להטמעה באמצעות ה-API

כשמפעילים גישה לתוכן מוטמע באמצעות Looker API, מומלץ:

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

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

אירועים של JavaScript מוטמע

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

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

אם משתמשים בפונקציית JavaScript‏ eval, צריך לוודא שערך המחרוזת בארגומנט eval מגיע ממקור מהימן, כמו שרת Looker או CDN, ושהוא מועבר באמצעות HTTPS.

נתוני לקוחות אף פעם לא עוברים דרך רשתות ה-CDN של Looker. נכסים סטטיים של אפליקציית האינטרנט של Looker – קוד JavaScript, דפי HTML, סגנונות CSS – מוצגים רק מ-CDN.

פריסות באירוח בצד הלקוח

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

פריסות באירוח בצד הלקוח מתאימות במיוחד במקרים הבאים:

• המשתמשים לא צריכים לגשת ל-Looker דרך האינטרנט.
• אתם משתמשים ב-Looker כחלק ממערכת אחרת וניגשים לתוכן מוטמע באמצעות ה-API.