במסמך הזה מפורטות תשובות לשאלות נפוצות בנושא אבטחת מידע ב-RCS for Business ובנושאים קשורים.
RBM היא פלטפורמה לשליחת הודעות שעסקים משתמשים בה כדי לשלוח סיסמאות חד-פעמיות (OTP) ולנהל שיחות עם לקוחות בנושאים כמו עסקאות, שירות לקוחות, מבצעים ועוד. Google מספקת RBM API לשליחת הודעות בין עסקים לבין משתמשי קצה דרך השרתים של Google.
בדרך כלל, עסקים עובדים עם שותפים לשליחת הודעות (כולל צוברים, ספקי פלטפורמות תקשורת כשירות (CPaaS), ספקי סלולר וספקי פתרונות אחרים של RCS) שמתחברים ל-API של Google כדי ליצור ולתחזק סוכני RBM בשם העסק. שותפים שרוצים להשתמש ב-RBM דרך ה-API או דרך Google Developers Console של RCS לעסקים צריכים להסכים לתנאים ולהגבלות של RBM ולמדיניות השימוש המקובל של Google. מכיוון ש-Google פועלת כמעבדת מידע, השותפים כפופים גם לנספח של Google לעיבוד נתונים.
אישורים ותאימות
האם RBM מאושר על ידי צדדים שלישיים?
תשתית ה-RCS של Google ו-RBM עוברות ביקורת באופן עצמאי מדי שנה כדי לוודא שהן עומדות בתקנים מוכרים של איכות ואבטחת נתונים. השירותים שלנו עומדים בתקנים ISO 27001, SOC 2 ו-SOC 3. כדי לקבל עותקים של האישורים, אפשר לפנות למנהל החשבון.
האם RBM עומד בדרישות General Data Protection Regulation (התקנות הכלליות להגנה על מידע, GDPR) של האיחוד האירופי?
העיבוד של נתונים על ידי Google כמעבד מידע תואם ל-GDPR, אבל האחריות לתאימות ל-GDPR מוטלת על העסק שמשתמש בפלטפורמה. כמו ברוב ערוצי השיווק, העסקים אחראים לתהליכים שלהם שקשורים לאיסוף נתונים, לשימוש בנתונים ולאחסון נתונים.
האם RBM תואם לדירקטיבה האירופית בנושא שירותי תשלום (PSD2)?
כן, RBM תואם ל-PSD2, שדורש אימות חזק ללקוח (SCA). מכיוון ש-RBM משויך למספר הטלפון המאומת של משתמש הקצה ולכרטיס ה-SIM שלו, סיסמה חד-פעמית (OTP) שנשלחת באמצעות RBM נחשבת ל"רכיב בעלות" תואם של SCA, כפי שמתואר על ידי הרשות האירופית לבנקאות.
האם RBM עומד בדרישות HIPAA?
לא, RBM לא עומד בדרישות של HIPAA.
תוכן מוגבל ותרחישי שימוש
אילו סוגים של תרחישי שימוש בתחום הבריאות נתמכים ב-RBM?
פלטפורמת RBM תומכת בתרחישי שימוש שקשורים לבריאות, בתנאי שמידע רפואי מוגן (PHI) לא נכלל בהודעות האלה. לדוגמה, אפשר לשלוח תזכורת לפגישה או התראה עם קישור להתחברות לפורטל מאובטח למטופלים. אסור לשלוח הודעות שמכילות מידע בריאותי פרטי או שמקדמות מוצרי בריאות מוגבלים. רשימת המוצרים המוגבלים שקשורים לבריאות והשירותים המוגבלים מופיעה במדיניות השימוש המקובל.
עיבוד נתונים
מה המשמעות של העובדה ש-Google היא מעבד מידע?
ב-RBM, Google משמשת כמעבד מידע והעסק או השותף משמשים כנאמני מידע. הנספח לעיבוד נתונים (DPA) מסביר ש-Google היא מעבדת מידע, והוא קובע את התנאים לטיפול בנתונים בשם עסקים ושותפים.
האם הסכם ה-DPA חל על כל משתמשי הקצה שמנהלים אינטראקציה עם נציג ב-RBM?
כן, הסכם ה-DPA חל על כל משתמשי הקצה והנתונים שלהם. Google יצרה את פלטפורמת RBM בהתאם לחוק הגנת הנתונים, כדי להבטיח שכל משתמשי הקצה יקבלו את אותה רמה גבוהה של אבטחת מידע.
אחסון והצפנה של הודעות
אילו נתונים מאוחסנים במכשיר של משתמש הקצה?
מטא-נתונים על נציגים ב-RBM ועל ההודעות שהוחלפו איתם מאוחסנים במכשיר של משתמש הקצה. יכול להיות שההודעות האלה יכללו מידע אישי ששותף עם סוכן RBM.
מה הקשר בין ה'אזור' של הנציג לבין אחסון ההודעות?
האזור שהשותף מציין במהלך הגדרת הסוכן מציין ל-RBM את המיקום של הסוכן (צפון אמריקה, אירופה או אסיה והאוקיינוס השקט). Google משתמשת במידע הזה כדי לקבוע איפה צריך לאחסן את נתוני ההודעות וכדי לבצע אופטימיזציה של ניתוב תנועת ההודעות לסוכן.
באזור שצוין, הנתונים עשויים לעבור בין כמה מרכזי נתונים של Google לצורך גמישות, יכולת הרחבה וכנדרש למוצר גלובלי להעברת הודעות. מטעמי אבטחה ופרטיות, Google לא חושפת את המיקומים הספציפיים של מרכזי הנתונים האלה. (מידע נוסף על אבטחה במרכז הנתונים ובאבטחת הרשת זמין בDPA).
במקרה חריג של הפסקה זמנית בשירות באזור מסוים, Google עשויה לעבד באופן זמני את תעבורת ההודעות באזור אחר כדי לשמור על זמינות השירות. המעבר הזה הוא אמצעי זמני שנועד למנוע שיבוש מלא בשירות ולהבטיח את מסירת ההודעות.
מהי ארכיטקטורת ההודעות והזרימה של RCS for Business? אילו אלמנטים מוצפנים?
ההודעות שנשלחות בין עסקים לבין משתמשי קצה מוצפנות בין המכשיר של משתמש הקצה לבין השרתים של Google, ובין השרתים של Google לבין שותף המסרים, באמצעות ה-API של Google ל-RCS Business Messaging.
ההודעות מוצפנות ברשת של Google באמצעות מפתחות שרק רכיבים ספציפיים של השירות יכולים לגשת אליהם. מפתחות ההצפנה מאפשרים למערכות של Google לבדוק את התאימות למדיניות.
במאמר איך זה עובד מוסבר על תהליך העברת ההודעות מקצה לקצה ועל התפקידים של כל הצדדים המעורבים.
האם ההודעות המאוחסנות מוצפנות?
אחסון בשרתי Google
הודעות מסוכן לאדם (A2P) נשמרות בשרתים של Google אם הנמען לא מחובר לאינטרנט. יכול להיות שהמפתח יבחר לבטל את ההודעות האלה ולשלוח אותן בערוץ אחר. הודעות מאדם לאפליקציה (P2A) נשמרות בשרתים של Google אם הסוכן לא יכול לקבל אותן. Google מחזיקה את ההודעות האלה למשך שבעה ימים לפני שהיא מפסיקה את הטיפול בהן.
ההודעות שמאוחסנות בשרתים של Google מוצפנות במצב מנוחה.
הגישה של Google להודעות מאוחסנות אפשרית רק במקרים הבאים:
- יכול להיות ש-Google תעבד זמנית את תוכן ההודעות שנשלחות מעסקים כדי לזהות ולמנוע ספאם וניצול לרעה, ותשתמש באותות האלה כדי לאמן מודלים של AI לשיפור היכולות של זיהוי ומניעת ספאם. מידע נוסף על טיפול בנתונים בדוחות ספאם זמין במאמר האם Google קוראת הודעות בין עסקים לבין משתמשי קצה?
- יכול להיות שנשתף הודעות מאוחסנות עם סוכנויות אכיפת חוק חיצוניות בהתאם לתנאי החובות של Google לעמוד בדרישות החוק הרלוונטי. מידע נוסף זמין בדוח השקיפות של Google.
כמה זמן ההודעות נשמרות?
אחסון בשרתי Google
- נכסי נציג RBM (לוגו, שם, תיאור וכו'): מאוחסנים באופן קבוע באחסון הגלובלי של Google.
- הודעות מאדם לנציג (P2A): נשמרות בשיטת אחסון והעברה למשך עד שבעה ימים. ההודעה נמחקת ברגע שהנציג ב-RBM מקבל אותה ומאשר את קבלתה.
- הודעות מסוכן לאדם (A2P): נשמרות עד למסירה, למשך 30 ימים לכל היותר. לפני שמגיעים למגבלת 30 הימים, סוכנים יכולים לבטל הודעות שלא נמסרו. ההודעות האלה יוסרו מתור ההמתנה למסירה ויימחקו מהשרתים של Google. אם הודעה שנמסרה מכילה קובצי מדיה, הקבצים האלה מאוחסנים למשך 60 יום. יכול להיות שהודעות A2P יישמרו בשרתים של Google למשך 14 ימים אחרי המסירה, כדי לזהות ולמנוע ספאם והתנהלות פוגעת.
אחסון במכשירים ניידים
ההודעות במכשיר של משתמש הקצה מאוחסנות שם עד שמשתמש הקצה מוחק אותן או משנה את מנגנון האחסון.
האם RBM מוצפן מקצה לקצה?
לא, RBM לא מציע הצפנה מקצה לקצה. לכן לא תראו סמל נעילה בממשק המשתמש של Messages בשיחות RBM. עם זאת, RBM משתמש בהצפנה מקצה לקצה כדי להגן על ההודעות כשהן עוברות בין המכשירים של המשתמשים לבין השרתים של Google, וגם בין השרתים של Google לבין שותפי העברת ההודעות.
איזה סוג הצפנה משמש ב-RBM, והאם עסק יכול לשלוט במפתחות המשויכים?
ב-RBM נעשה שימוש בהצפנה מקצה לקצה כדי להגן על ההודעות בזמן שהן עוברות בין המכשירים לבין שרתי Google. לעסקים אין שליטה במפתחות ההצפנה. Google מנהלת את המפתחות האלה למטרות אבטחה, כולל סריקה של תוכן זדוני כמו כתובות URL של פישינג ותוכנות זדוניות, כדי להגן על המשתמשים מפני ספאם. פרטים נוספים על גישה להודעות ועל בדיקה שלהן זמינים במאמר האם Google קוראת הודעות בין עסקים לבין משתמשי קצה?
אילו גורמים יכולים לגשת להודעות ב-RBM? מהי האחריות של שותפים לשליחת הודעות, עסקים וספקי סלולר להבטחת אבטחת מידע?
RBM היא טכנולוגיה לתחבורה ציבורית שמבוססת על Google. פלטפורמת RBM מעבירה הודעות בין משתמשי קצה לבין נציגים שמייצגים עסקים. הנציגים האלה נוצרים ומופעלים על ידי שותפים לשירותי העברת הודעות, עסקים ובמקרים מסוימים ספקי סלולר. לגורמים שמפעילים סוכני RBM, ובמקרים מסוימים גם לספקי הסלולר, יש גישה לתוכן ההודעות ב-RBM לצורך מסירתן ולמטרות אחרות. ל-Google יש גם גישה לתוכן של ההודעות ב-RBM כדי להגן מפני ספאם וניצול לרעה.
כל אחד מהשותפים, העסקים והספקים של שירותי התקשורת אחראי בנפרד לעמוד בכל הדרישות הרלוונטיות בנושא אבטחת מידע, פרטיות ותקנות מקומיות.
אבטחת RBM API
האם Google יכולה לקבל את טוקני הגישה שנשלחים על ידי ספק OAuth?
לא, Google אף פעם לא מקבלת את טוקני הגישה שנשלחים על ידי ספק OAuth במהלך אימות המשתמש. ב-OAuth 2.0 נעשה שימוש במפתח הוכחה להחלפת קוד (PKCE) כדי לאבטח את תהליך האימות.
איך הנתונים מוצפנים בין מפתח RBM לבין Google?
מפתחים ניגשים ל-RBM API באמצעות HTTPS, התקן הגלובלי לעסקאות מאובטחות באינטרנט. RBM API תומך ב-TLS 1.3 עם הצפנות AES 256 ו-SHA384.
מריצים את הפקודה הבאה כדי לבדוק את שרשרת האישורים, את גרסת ה-TLS ואת האלגוריתמים להצפנה שנתמכים:
openssl s_client -connect rcsbusinessmessaging.googleapis.com:443
אימות מספר טלפון
כדי לשמור על האבטחה של אפליקציית ההודעות של Google, איך Google מאמתת שמספר טלפון עדיין שייך למשתמש המקורי?
אימות ראשוני של מספר הטלפון: Google משתמשת במגוון טכניקות כדי לזהות את מספר הטלפון של משתמש הקצה (כלומר, מספר MSISDN או מספר בינלאומי של תחנה ניידת בספריית מנויים). הטכניקות האלה כוללות שילוב ישיר של API עם ספקי סלולר, שליחת SMS ממכשיר נייד ובקשה ממשתמש הקצה להזין את מספר הטלפון שלו. אחרי שמספר הטלפון מזוהה, יכול להיות ש-Google תשלח הודעת SMS עם סיסמה חד-פעמית (OTP) בלתי נראית כדי לאמת אותו.
שמירה על אבטחה אחרי האימות הראשוני: אם לספק יש שילוב API ישיר, הוא יכול לשלוח ל-Google פיד של השבתת כרטיסי SIM או מספרי MSISDN באופן תקופתי כדי להשבית את RCS ובכך להשבית את RBM למספרי טלפון שכבר לא פעילים. Google עשויה גם לעקוב אחרי שינויים בבעלות על מספר הטלפון באמצעות אותות מהמכשיר, כמו הסרת כרטיס SIM ופעילות בכרטיס ה-SIM, וגם באמצעות אימות מחדש של מספר הטלפון מדי פעם.
פרטיות ואבטחה
אילו דוחות Google מפיקה לגבי סוכני RBM?
ל-Google יש דוחות פנימיים על המספר הכולל של משתמשי קצה, הודעות ותגובות לכל סוכן, על סמך נתונים מ-28 הימים האחרונים. Google משתמשת בנתונים האלה לצורך אבחון, שיפורים במערכת ויצירת דוחות חיוב לספקי סלולר. תוכן ההודעות לא נשמר לצורכי דיווח. אחרי 28 ימים, Google מאחסנת רק נתוני דיווח מצטברים, ואין הגבלת זמן על האחסון הזה. לכל הנתונים הנצברים שמשותפים עם גורמים חיצוניים יש אורך חיים (TTL) של 63 ימים.
דוחות החיוב ויומני הפעילות שספקי הסלולר מקבלים מאוחסנים למשך 63 ימים בשרתים של Google. שותפים של ספקי סלולר יכולים לבחור להוריד את הקבצים האלה ולשמור אותם למשך הזמן שהם רואים לנכון.
האם Google משתמשת בנתוני משתמשי קצה מחוץ ל-RBM?
Google משתמשת בנתוני משתמשי הקצה רק כדי לספק את שירות ה-RBM ולשפר אותו, כמו שצוין בסעיף 5.2 של הסכם עיבוד הנתונים.
לדוגמה, Google עשויה לבצע את הפעולות הבאות עם נתוני משתמשי קצה:
- לזהות ולמנוע ספאם והונאה.
- שיתוף דוחות חיוב ויומני פעילות לא מצטברים עם שותפים של ספקי סלולר.
- מדידה ושיפור של ביצועי RBM עבור משתמשי קצה ועסקים.
במסגרת המאמץ הזה, Google משתפת נתונים מצטברים עם שותפים כדי שהם יוכלו לשפר את חוויית השימוש בהודעות. פרטים נוספים מופיעים במאמר בנושא אילו דוחות Google מפיקה לגבי סוכני RBM?
אבל Google לא תעשה את הפעולות הבאות עם נתוני משתמשי הקצה:
- ביצוע טירגוט מודעות על סמך תוכן ההודעות.
- לשתף את תוכן ההודעות עם מתחרים או עם צדדים שלישיים, למעט עם רשויות אכיפת החוק כפי שנדרש על פי החוק החל.
האם Google קוראת אי פעם הודעות בין עסקים לבין משתמשי קצה?
יכול להיות שהמערכת של Google לזיהוי ולמניעת ספאם תסרוק את תוכן ההודעות שנשלחו מהעסקים כדי לזהות הפרות של מדיניות השימוש המקובל. ל-Google אין גישה לתוכן של ההודעות שהמשתמשים שולחים לעסקים. עם זאת, אם משתמש הקצה מדווח על שיחה כספאם:
- פרטי השולח/ת וההודעות האחרונות שנשלחו מהעסק יועברו ל-Google ואולי גם לספק הסלולר של המשתמש.
- יכול להיות שהמערכת של Google לזיהוי ולמניעת ספאם תעבד זמנית את תוכן ההודעות שנשלחו מהעסקים, ותשתמש באותות האלה כדי לאמן מודלים של AI לשיפור היכולות של זיהוי ומניעת ספאם.
- יכול להיות שעובדים וקבלנים של Google יבדקו את פרטי הדיווח על ספאם כדי לעזור ל-Google לשפר את היכולת לזהות ספאם ולהגן מפני ניצול לרעה. לבודקים אנושיים תהיה גישה מוגבלת למידע הזה ל-30 יום לצורך הבדיקה. מספר הטלפון של משתמש הקצה יצונזרו לצורך בדיקת הספאם.
איזה מידע על משתמשי קצה Google מספקת לעסק?
כדי להפעיל שיחה ב-RBM, Google משתפת עם העסק את מספר הטלפון של משתמש הקצה כדי לזהות את משתמש הקצה בשיחה. לא נשתף עם העסק פרטים אישיים אחרים.
האם בסעיף 'פרטיות ואבטחה' של מדיניות השימוש המקובל יש הגבלות על היכולת של עסק לאסוף מידע על הלקוחות שלו ולהשתמש בו?
Google לא מתכוונת להגביל את היכולת של העסק לשרת את הלקוחות שלו. עסק יכול לאחסן שיחה בין משתמש קצה לבין העסק שנוצרה באמצעות RBM API, בהתאם לתנאים של מדיניות הפרטיות שלו.
מה המשמעות של המונחים הבאים בתנאים ובהגבלות של RBM? "עליך להשיג את כל ההסכמות הנדרשות ולדאוג לשמר אותן לאורך זמן כדי לאפשר את עיבוד המידע האישי בכפוף לתנאים האלה של RBM".
Google מצפה מכל העסקים שמשתמשים ב-RBM לפעול בהתאם לתקנות הרלוונטיות בנושא נתונים ואבטחה (כמו GDPR) ולספק מדיניות פרטיות שמסבירה איך הם משתמשים בנתוני משתמשי הקצה ו/או משתפים אותם. מפתחים צריכים לספק את מדיניות הפרטיות שלהם כדי שהסוכן שלהם ייבדק לפני הפעלה.
איך RBM מגן על משתמשי קצה מפני כתובות URL זדוניות?
כדי להגן על משתמשי הקצה, ב-RBM נעשה שימוש בגלישה בטוחה של Google לסריקת קישורים בהודעות ולחסימה אוטומטית של הודעות שמכילות תוכנות זדוניות או קישורי פישינג. אם הגלישה הבטוחה לא חוסמת הודעה שמכילה קישור, יכול להיות שאפליקציית ההודעות תיצור תצוגה מקדימה של תמונה ממוזערת כדי להראות לאן הקישור מוביל.
שיתוף הפעולה של Google כשעסק עובר ביקורת
העסק שלנו כפוף לתקנות ועשוי לעבור ביקורת. האם Google תפעל בהתאם?
באחריות העסק לוודא שהחברה שלו עומדת בתקנות הרלוונטיות. Google תגיב רק לפניות של רשויות אכיפת החוק ושל רשויות רגולטוריות בהתאם לדין החל.
תגובה לאירוע
איך Google מטפלת בפרצות אבטחה?
אפשר לעיין בסעיף 7.2 בנושא אירועי אבטחת מידע בהסכם עיבוד הנתונים.
יכולות רשת שלא נתמכות
אילו יכולות רשת לא נתמכות ב-RBM?
- כותרות בהתאמה אישית כדי לאפשר מעבר דרך חומות אש
- טווחים של בלוקים בפורמט Classless inter-domain routing (CIDR) משירותי Google