אבטחת נתונים ב-RCS Business Messaging (RBM)

במסמך הזה תמצאו תשובות לשאלות נפוצות לגבי אבטחת הנתונים של RCS Business Messaging (RBM) והנושאים הקשורים.

RBM היא פלטפורמה להעברת הודעות שמותגים משתמשים בה כדי לשלוח סיסמאות חד-פעמיות (OTP) וליצור מעורבות עם הלקוחות בדו-שיח עם הלקוחות לגבי עסקאות, שירות לקוחות, מבצעים ועוד. RBM מסופק באמצעות Google API ומועבר למשתמשי הקצה דרך השרתים של Google.

בדרך כלל, מותגים עובדים עם שותפים (למשל ספקים, אתרי אגרגטור שאוספים הודעות SMS, פלטפורמות לניהול קשרי לקוחות (CRM) וכלים ליצירת בוטים) שמתחברים ל-Google API כדי ליצור ולתחזק סוכני RBM בשם המותגים. שותפים שרוצים להשתמש ב-RBM דרך ה-API או דרך Business Communications Developer Console חייבים להסכים לתנאים ולהגבלות ולמדיניות השימוש המקובל של Google. מכיוון ש-Google פועלת כמעבד מידע, השותפים כפופים גם לנספח לעיבוד נתונים של Google.

Google לא עורכת הסכמים מותאמים אישית או משלימים לגבי RBM.

אישור ותאימות

האם RBM קיבל אישור מצד שלישי כלשהו?

התשתית של RBM ותשתית ה-RCS של Google נבדקות מדי שנה באופן עצמאי, כדי להבטיח תאימות לסטנדרטים המוכרים ביותר של איכות ואבטחת מידע. השירותים שלנו כוללים אישורי ISO 27001, SOC 2 ו-SOC 3. אפשר לפנות למנהל החשבון אם ברצונך לקבל עותקים של האישורים.

האם RBM פועל בהתאם ל-EU Payment Services Directive 2 (PSD2)?

כן, RBM תואם לתקני PSD2, שמחייב אימות חזק ללקוח (SCA). מאחר ש-RBM משויך למספר הטלפון ולכרטיס ה-SIM המאומתים של משתמש הקצה, סיסמה חד-פעמית (OTP) שנשלחת באמצעות RBM נחשבת ל'רכיב בעלות' תואם ב-SCA, כפי שמתואר על ידי European Banking Authority.

עיבוד נתונים

מה המשמעות של היותו מעבד מידע של Google?

ב-RBM, Google משמשת כמעבד מידע, והמותג או השותף משמשים כנאמני מידע. בנספח לעיבוד נתונים (DPA) מוסבר ש-Google היא מעבד מידע, והיא קובעת את התנאים לעיבוד נתונים בשם מותגים ושותפים.

האם הרשות להגנה על מידע חלה על כל משתמשי הקצה שמנהלים אינטראקציה עם נציג של RBM?

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

אחסון הודעות והצפנה

אילו נתונים מאוחסנים במכשיר של משתמש הקצה?

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

האזור שהשותף מציין במהלך הגדרת הסוכן אומר ל-RBM איפה הסוכן נמצא. Google משתמשת במידע הזה כדי לקבוע איפה לשמור את נתוני ההודעות וכדי לשפר את ניתוב התנועה של ההודעות לנציג.

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

מהם הארכיטקטורה והתהליך של העברת ההודעות ב-RBM? אילו רכיבים מוצפנים?

ההודעות שנשלחות בין מותגים ומשתמשי קצה מוצפנות בין המכשיר של משתמש הקצה לשרתים של Google ובין השרתים של Google לשותף להעברת הודעות, באמצעות ה-API של RCS Business Messaging (RBM) של Google.

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

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

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

האם ההודעות השמורות מוצפנות?

אחסון בשרתי Google

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

הגישה להודעות שמורות זמינה רק במזהה Google של משתמש הקצה. שימו לב לשני היוצאים מן הכלל:

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

נפח אחסון במכשירים ניידים

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

למשך כמה זמן ההודעות נשמרות?

אחסון בשרתי Google

  • נכסי סוכנים ב-RBM (לוגו, שם, תיאור וכו'): מאוחסנים באופן קבוע באחסון הגלובלי של Google.
  • הודעות ממשתמש לסוכן (הודעות P2A): מוחזקות לצורך קידום מכירות בחנות והרצה במשך 7 ימים לכל היותר. ברגע שהנציג ב-RBM מקבל את ההודעה ומאשר אותה, היא נמחקת.
  • הודעות מסוכן למשתמש (הודעות A2P): בהמתנה עד שנמסרות, למשך עד 30 ימים. נציגים יכולים לבטל הודעות שלא נמסרו לפני שהן נמסרות. אם ההודעות מכילות קובצי מדיה, כמו תמונות או סרטונים, הקבצים האלה נשמרים למשך 60 יום. כדי לזהות ספאם, יכול להיות שהודעות A2P מוצפנות יישמרו בשרתים של Google למשך 14 ימים אחרי שנמסרו.

נפח אחסון במכשירים ניידים

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

האם מותג יכול לשלוט במפתחות ההצפנה של ההודעות שמאוחסנות ב-Google?

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

איזו אחריות יש לשותפים ולמותגים כדי להבטיח אבטחת נתונים?

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

אבטחת RBM API

האם Google יכולה לקבל את אסימוני הגישה שנשלחו על ידי ספק ה-OAuth?

לא, Google אף פעם לא מקבלת את אסימוני הגישה שנשלחו על ידי ספק ה-OAuth במהלך אימות המשתמש. בפרוטוקול OAuth 2.0 נעשה שימוש במפתח הגהה ל-Code Exchange (PKCE) כדי לאבטח את תהליך האימות.

איך הנתונים מוצפנים בין מפתחי RBM ל-Google?

מפתחים ניגשים ל-RBM API באמצעות HTTPS, התקן הגלובלי לעסקאות אינטרנט מאובטחות. RBM API תומך ב-TLS 1.3 עם הצפנות AES 256 ו-SHA384.

מריצים את הפקודה הבאה כדי לבדוק את שרשרת האישורים, את גרסת ה-TLS ואת הצפנים הנתמכים:

openssl s_client -connect rcsbusinessmessaging.googleapis.com:443

אימות מספר טלפון

כדי לשמור על האבטחה של אפליקציית Messages של Google, איך Google מאמתת שמספר הטלפון עדיין שייך למשתמש המקורי?

  • אימות ראשוני של מספר הטלפון: Google משתמשת במגוון שיטות לזיהוי מספר הטלפון של משתמש הקצה (כלומר, מספר ה-MSSDN שלו או מספר ספריית המנויים הבינלאומית של התחנה לנייד). הטכניקות האלה כוללות שילוב ישיר בין ה-API עם ספקים, הודעות SMS רגילות ובקשה ממשתמשי הקצה להזין את מספר הטלפון שלהם. אחרי שמספר הטלפון מזוהה, יכול להיות ש-Google תשלח SMS בלתי נראה עם סיסמה חד-פעמית (OTP) כדי לאמת אותו.

  • שמירה על האבטחה אחרי האימות הראשוני: כשיש לספק שילוב ישיר בין ה-API, הוא יכול לשלוח ל-Google פיד השבתה של כרטיסי SIM או MSISDN כדי להשבית את השימוש ב-RCS, ולהשבית את RBM למספרי טלפון שכבר לא פעילים. Google עשויה גם לעקוב אחר שינויים בבעלות על מספר הטלפון בעזרת אותות מהמכשיר, כמו הסרה של כרטיס SIM ופעילות כרטיס ה-SIM, ובאמצעות אימות חוזר של מספר הטלפון מדי פעם.

פרטיות ואבטחה

איזה דיווח Google עושה לגבי נציגים של RBM?

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

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

האם Google משתמשת בנתונים של משתמשי קצה מחוץ ל-RBM?

Google משתמשת בנתונים של משתמשי הקצה רק כדי לספק את שירות ה-RBM ולשפר אותו, כפי שמצוין בסעיף 5.2 ב-DPA.

לדוגמה, Google עשויה לבצע את הפעולות הבאות עם נתונים של משתמשי קצה:

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

עם זאת, Google לא תבצע את הפעולות הבאות עם נתונים של משתמשי קצה:

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

האם יש מקרים שבהם Google קוראת הודעות בין מותגים לבין משתמשי קצה?

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

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

איזה מידע Google מספקת למותג על משתמשי הקצה?

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

במדיניות השימוש המקובל, האם הקטע 'פרטיות ואבטחה' מגביל את היכולת של המותג לאסוף מידע על הלקוחות שלו ולהשתמש בו?

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

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

Google מצפה מכל המותגים שמשתמשים ב-RBM לפעול בהתאם לתקנות הרלוונטיות והאבטחה (כמו GDPR) ולספק מדיניות פרטיות שמבהירה איך הם משתמשים בנתונים של משתמשי הקצה ו/או משתפים אותם. המפתח צריך לספק את מדיניות הפרטיות שלו כדי שנציג יוכל לבדוק את ההשקה.

שיתוף הפעולה של Google כאשר מותג נבדק

המותג שלנו כפוף לתקנות וייתכן שנבדוק אותו. האם Google תציית לבקשה?

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

תגובה לאירוע

איך Google מטפלת בפרצות באבטחת מידע?

יש לעיין בסעיף 7.2 אירועי אבטחת מידע ב-DPA.

יכולות רשת לא נתמכות

אילו יכולות רשת לא נתמכות על ידי RBM?

  • כותרות מותאמות אישית שיאפשרו העברה של חומת אש
  • טווחי חסימה ללא סיווג של ניתוב בין דומיינים (CIDR) משירותי Google