במסמך הזה מפורטות תשובות לשאלות נפוצות בנושא אבטחת נתונים ב-RCS לעסקים ובנושאים קשורים.
RBM היא פלטפורמת הודעות שעסקים משתמשים בה כדי לשלוח סיסמאות חד-פעמיות (OTP) ולנהל שיחות עם לקוחות בנושאים כמו עסקאות, שירות לקוחות, מבצעים ועוד. Google מספקת RBM API לשליחת הודעות בין עסקים לבין משתמשי קצה דרך השרתים של Google.
בדרך כלל, עסקים עובדים עם שותפים לשליחת הודעות (כולל צוברים, ספקי פלטפורמות תקשורת כשירות (CPaaS), ספקי סלולר וספקי פתרונות אחרים של RCS) שמתחברים ל-API של Google כדי ליצור ולתחזק סוכני RBM בשם העסק. שותפים שרוצים להשתמש ב-RBM דרך ה-API או דרך Business Communications Developer Console צריכים להסכים לתנאים ולהגבלות של RBM ולמדיניות השימוש המקובל של Google. מכיוון ש-Google פועלת כמעבדת מידע, השותפים כפופים גם לנספח לעיבוד נתונים של Google.
אישורים ותאימות
האם RBM מאושר על ידי צדדים שלישיים?
תשתית ה-RCS של Google ו-RBM עוברות ביקורת באופן עצמאי מדי שנה כדי לוודא שהן עומדות בתקנים מוכרים של איכות ואבטחת נתונים. השירותים שלנו עומדים בתקנים ISO 27001, SOC 2 ו-SOC 3. כדי לקבל עותקים של האישורים, אפשר לפנות למנהל החשבון.
האם RBM עומד בדרישות של התקנה הכללית להגנה על מידע (GDPR) של האיחוד האירופי?
העיבוד של נתונים על ידי Google כמעבד מידע תואם ל-GDPR, אבל האחריות לתאימות ל-GDPR מוטלת על העסק שמשתמש בפלטפורמה. כמו ברוב ערוצי השיווק, העסקים אחראים לתהליכים שלהם שקשורים לאיסוף נתונים, לשימוש בנתונים ולאחסון נתונים.
האם RBM תואם ל-EU Payment Services Directive 2 (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 Business Messaging? אילו אלמנטים מוצפנים?
ההודעות שנשלחות בין עסקים לבין משתמשי קצה מוצפנות בין המכשיר של משתמש הקצה לבין השרתים של 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 בנושא אירועי אבטחת מידע בDPA.
יכולות רשת שלא נתמכות
אילו יכולות רשת לא נתמכות ב-RBM?
- כותרות בהתאמה אישית כדי לאפשר מעבר דרך חומות אש
- טווחים של בלוקים של Classless inter-domain routing (CIDR) משירותי Google