ความปลอดภัยของข้อมูลสำหรับ RCS for Business

เอกสารนี้จะตอบคำถามที่พบบ่อยเกี่ยวกับความปลอดภัยข้อมูล RCS for Business และหัวข้อที่เกี่ยวข้อง

RBM เป็นแพลตฟอร์มการรับส่งข้อความที่ธุรกิจใช้เพื่อส่งรหัสผ่านแบบใช้ครั้งเดียว (OTP) และดึงดูดลูกค้าให้มีส่วนร่วมในการสนทนาเกี่ยวกับการทำธุรกรรม การบริการลูกค้า โปรโมชัน และอื่นๆ Google มี RBM API เพื่อส่งข้อความระหว่างธุรกิจกับผู้ใช้ปลายทางผ่านเซิร์ฟเวอร์ของ Google

โดยปกติแล้ว ธุรกิจจะทำงานร่วมกับพาร์ทเนอร์ด้านการรับส่งข้อความ (รวมถึงผู้รวบรวมข้อมูล ผู้ให้บริการแพลตฟอร์มการสื่อสารเป็นบริการ (CPaaS) ผู้ให้บริการเครือข่าย และผู้ให้บริการโซลูชัน RCS อื่นๆ) ซึ่งเชื่อมต่อกับ Google API เพื่อสร้างและดูแลตัวแทน RBM ในนามของธุรกิจ พาร์ทเนอร์ที่ต้องการใช้ RBM ผ่าน API หรือ RCS for Business Developer Console ต้องยอมรับ ข้อกำหนดในการให้บริการ RBM และ นโยบายการใช้งานที่ยอมรับได้ของ Google เนื่องจาก Google ทำหน้าที่เป็น ผู้ประมวลผลข้อมูล, พาร์ทเนอร์จึงอยู่ภายใต้บังคับของ เอกสารแนบท้ายการประมวลผลข้อมูลของ Google ด้วย

การรับรองและการปฏิบัติตามข้อกำหนด

RBM ได้รับการรับรองจากบุคคลที่สามไหม

RBM และโครงสร้างพื้นฐาน RCS ของ Google ได้รับการตรวจสอบโดยอิสระทุกปีเพื่อให้เป็นไปตามมาตรฐานด้านคุณภาพและความปลอดภัยข้อมูลที่ได้รับการยอมรับอย่างกว้างขวาง บริการของเราได้รับการรับรองISO 27001, SOC 2 และ SOC 3 โปรดติดต่อผู้จัดการฝ่ายดูแลลูกค้าหากต้องการสำเนาใบรับรอง

RBM เป็นไปตามกฎระเบียบให้ความคุ้มครองข้อมูลส่วนบุคคลของผู้บริโภค (GDPR) ของสหภาพยุโรปไหม

แม้ว่าการประมวลผลข้อมูลของ Google ในฐานะผู้ประมวลผลข้อมูลจะเป็นไปตาม GDPR แต่การปฏิบัติตาม GDPR เป็นความรับผิดชอบของธุรกิจ แต่ละรายที่ใช้แพลตฟอร์ม เช่นเดียวกับช่องทางการตลาดส่วนใหญ่ ธุรกิจมีหน้าที่รับผิดชอบกระบวนการของตนเองเกี่ยวกับการเก็บรวบรวมข้อมูล การใช้ข้อมูล และการจัดเก็บข้อมูล

RBM เป็นไปตามกฎระเบียบด้านบริการชำระเงินฉบับที่ 2 (PSD2) ของสหภาพยุโรปไหม

ใช่ RBM เป็นไปตาม PSD2 ซึ่งกำหนดให้ต้องมีการยืนยันตัวตนลูกค้าแบบขั้นสูง (SCA) เนื่องจาก RBM เชื่อมโยงกับหมายเลขโทรศัพท์ที่ยืนยันแล้วของผู้ใช้ปลายทางและซิมการ์ด รหัสผ่านที่สามารถใช้งานได้เพียงครั้งเดียว (OTP) ที่ส่งโดยใช้ RBM จึงถือเป็น "องค์ประกอบการครอบครอง" SCA ที่เป็นไปตามข้อกำหนดตามที่อธิบายไว้โดย European Banking Authority

RBM เป็นไปตามข้อกำหนดของ HIPAA ไหม

ไม่ RBM ไม่เป็นไปตามข้อกำหนดของ HIPAA

เนื้อหาและกรณีการใช้งานที่ถูกจำกัด

RBM รองรับกรณีการใช้งานด้านการดูแลสุขภาพประเภทใดบ้าง

RBM รองรับกรณีการใช้งานที่เกี่ยวข้องกับการดูแลสุขภาพ โดยไม่รวมข้อมูลสุขภาพที่ได้รับการคุ้มครอง (PHI) จากข้อความดังกล่าว เช่น ระบบรองรับการส่งการแจ้งเตือนการนัดหมายหรือการแจ้งเตือนพร้อมลิงก์เพื่อเข้าสู่ระบบพอร์ทัลผู้ป่วยที่ปลอดภัย แต่ไม่อนุญาตให้ส่งข้อความที่มี PHI หรือโปรโมตผลิตภัณฑ์ด้านการดูแลสุขภาพที่ถูกจำกัด ดูรายการผลิตภัณฑ์และบริการที่เกี่ยวข้องกับการดูแลสุขภาพที่ถูกจำกัดได้ใน นโยบายการใช้งานที่ยอมรับได้

การประมวลผลข้อมูล

การที่ Google เป็นผู้ประมวลผลข้อมูลหมายความว่าอย่างไร

RBM จะให้ Google ทำหน้าที่เป็นผู้ประมวลผลข้อมูล และธุรกิจหรือพาร์ทเนอร์ทำหน้าที่เป็นผู้ควบคุมข้อมูล เอกสารแนบท้ายการประมวลผลข้อมูล (DPA) อธิบายว่า Google เป็นผู้ประมวลผลข้อมูล และควบคุมข้อกำหนดในการจัดการข้อมูลในนามของธุรกิจและพาร์ทเนอร์

DPA มีผลกับผู้ใช้ปลายทางทุกคนที่โต้ตอบกับตัวแทน RBM ไหม

ใช่ DPA มีผลกับผู้ใช้ปลายทางและข้อมูลของผู้ใช้ปลายทางทุกคน Google สร้างแพลตฟอร์ม RBM ให้เป็นไปตาม DPA และตรวจสอบว่าผู้ใช้ปลายทางทุกคนได้รับการรักษาความปลอดภัยข้อมูลในระดับสูงเท่ากัน

การจัดเก็บและการเข้ารหัสข้อความ

ระบบจัดเก็บข้อมูลใดไว้ในอุปกรณ์ของผู้ใช้ปลายทาง

ระบบจะจัดเก็บข้อมูลเมตาเกี่ยวกับตัวแทน RBM และข้อความที่แลกเปลี่ยนกับตัวแทนไว้ในอุปกรณ์ของผู้ใช้ปลายทาง ข้อความเหล่านี้อาจรวมถึงข้อมูลส่วนบุคคลที่แชร์กับตัวแทน RBM

ภูมิภาคที่พาร์ทเนอร์ระบุระหว่างการตั้งค่าตัวแทนจะบอก RBM ว่าตัวแทนอยู่ที่ใด (อเมริกาเหนือ ยุโรป หรือเอเชียแปซิฟิก) Google ใช้ข้อมูลนี้เพื่อกำหนดตำแหน่งที่ควรจัดเก็บข้อมูลข้อความ และเพื่อเพิ่มประสิทธิภาพการกำหนดเส้นทางการรับส่งข้อมูลข้อความไปยังตัวแทน

ภายในภูมิภาคที่ระบุ ข้อมูลอาจย้ายไปมาระหว่างศูนย์ข้อมูลหลายแห่งของ Google เพื่อความยืดหยุ่น ความสามารถในการปรับขนาด และตามที่จำเป็นสำหรับผลิตภัณฑ์การรับส่งข้อความระดับโลก Google ไม่เปิดเผยตำแหน่งที่ตั้งที่เฉพาะเจาะจงของศูนย์ข้อมูลเหล่านี้เนื่องด้วยเหตุผลด้านความปลอดภัยและความเป็นส่วนตัว (ดูข้อมูลเพิ่มเติมเกี่ยวกับความปลอดภัยของศูนย์ข้อมูลและเครือข่ายได้ใน DPA )

ในกรณีที่เกิดการหยุดทำงานของภูมิภาคโดยสมบูรณ์ Google อาจประมวลผลการรับส่งข้อมูลข้อความในภูมิภาคอื่นชั่วคราวเพื่อรักษาความพร้อมใช้งานของบริการ การเฟลโอเวอร์นี้เป็นมาตรการชั่วคราวที่ออกแบบมาเพื่อป้องกันการหยุดชะงักของบริการโดยรวมและตรวจสอบว่ามีการส่งข้อความ

สถาปัตยกรรมและการไหลของการรับส่งข้อความสำหรับ RCS for Business เป็นอย่างไร องค์ประกอบใดบ้างที่ได้รับการเข้ารหัส

ข้อความที่ส่งระหว่างธุรกิจกับผู้ใช้ปลายทางจะได้รับการเข้ารหัสระหว่างอุปกรณ์ของผู้ใช้ปลายทางกับเซิร์ฟเวอร์ของ Google และระหว่างเซิร์ฟเวอร์ของ Google กับพาร์ทเนอร์ด้านการรับส่งข้อความทางธุรกิจ RCS ผ่าน RCS Business Messaging API ของ Google

ขั้นตอนการรับส่งข้อความ RBM ที่แสดงการเข้ารหัสข้อความระหว่างตัวแทนกับ RBM และระหว่าง RBM กับผู้ใช้ปลายทาง เมื่อข้อความไปถึงแพลตฟอร์ม RBM ระบบจะ ตรวจสอบหามัลแวร์และสแปม

ข้อความจะได้รับการเข้ารหัสทั่วทั้งเครือข่ายของ Google โดยใช้คีย์ที่เฉพาะคอมโพเนนต์ของบริการบางอย่างเท่านั้นที่จะเข้าถึงได้ คีย์การเข้ารหัสช่วยให้ระบบของ Google ตรวจสอบการปฏิบัติตามนโยบายได้

ดูภาพรวมของการไหลของการรับส่งข้อความจากต้นทางถึงปลายทางและบทบาทของทุกฝ่าย ที่เกี่ยวข้องได้ที่หัวข้อวิธีการทำงาน

ข้อความที่จัดเก็บได้รับการเข้ารหัสไหม

การจัดเก็บในเซิร์ฟเวอร์ของ Google

ระบบจะเก็บข้อความจากตัวแทนถึงบุคคล (A2P) ไว้ในเซิร์ฟเวอร์ของ Google หากผู้รับออฟไลน์ นักพัฒนาแอปอาจเลือกเพิกถอนข้อความเหล่านี้และส่งผ่านช่องทางอื่น ระบบจะเก็บข้อความจากบุคคลถึงแอปพลิเคชัน (P2A) ไว้ในเซิร์ฟเวอร์ของ Google หากตัวแทนรับข้อความไม่ได้ Google จะเก็บข้อความเหล่านี้ไว้ 7 วันก่อนที่จะลบออก

ข้อความที่จัดเก็บไว้ในเซิร์ฟเวอร์ของ Google จะได้รับการเข้ารหัสเมื่อไม่มีการเคลื่อนไหว

Google จะเข้าถึงข้อความที่จัดเก็บไว้ได้ในกรณีต่อไปนี้เท่านั้น

  • Google อาจประมวลผลเนื้อหาของข้อความที่ธุรกิจส่งเป็นการชั่วคราวเพื่อตรวจจับและป้องกันสแปมและการละเมิด และอาจใช้สัญญาณเหล่านั้นในการฝึกโมเดล AI เพื่อปรับปรุงการป้องกันและการตรวจจับสแปม ดูข้อมูลเพิ่มเติมเกี่ยวกับการจัดการข้อมูล สำหรับการรายงานสแปมได้ที่ Google อ่านข้อความระหว่างธุรกิจกับผู้ใช้ปลายทางไหม
  • ระบบอาจแชร์ข้อความที่จัดเก็บไว้กับหน่วยงานบังคับใช้กฎหมายภายนอกภายใต้ข้อกำหนดของภาระหน้าที่ของ Google ในการปฏิบัติตามกฎหมายที่เกี่ยวข้อง ดูข้อมูลเพิ่มเติมได้ที่ รายงานเพื่อความโปร่งใส ของ Google

ระบบจะจัดเก็บข้อความไว้นานเท่าใด

การจัดเก็บในเซิร์ฟเวอร์ของ Google

  • เนื้อหาของตัวแทน RBM (โลโก้ ชื่อ คำอธิบาย ฯลฯ): จัดเก็บอย่างถาวรในพื้นที่เก็บข้อมูลส่วนกลางของ Google
  • ข้อความจากบุคคลถึงตัวแทน (ข้อความ P2A): จัดเก็บและส่งต่อโดยมีระยะเวลาไม่เกิน 7 วัน ระบบจะลบข้อความทันทีที่ตัวแทน RBM ได้รับและรับทราบข้อความ
  • ข้อความจากตัวแทนถึงบุคคล (ข้อความ A2P): จัดเก็บไว้จนกว่าจะส่งถึงผู้รับ โดยมีระยะเวลาไม่เกิน 30 วัน ก่อนถึงขีดจำกัด 30 วัน ตัวแทนสามารถ เพิกถอน ข้อความที่ยังไม่ได้ส่ง ซึ่งระบบจะนำออกจากคิวการส่งและลบ ออกจากเซิร์ฟเวอร์ของ Google หากข้อความที่ส่งแล้วมีไฟล์สื่อ ระบบจะจัดเก็บไฟล์เหล่านี้ไว้ 60 วัน ระบบอาจเก็บข้อความ A2P ไว้ในเซิร์ฟเวอร์ของ Google เป็นเวลา 14 วันหลังจากส่งเพื่อตรวจจับและป้องกันสแปมและการละเมิด

การจัดเก็บในอุปกรณ์เคลื่อนที่

ระบบจะจัดเก็บข้อความไว้ในอุปกรณ์ของผู้ใช้ปลายทางจนกว่าผู้ใช้ปลายทางจะลบข้อความหรือเปลี่ยนกลไกการจัดเก็บ

RBM มีการเข้ารหัสจากต้นทางถึงปลายทางไหม

ไม่ RBM ไม่มีการเข้ารหัสจากต้นทางถึงปลายทาง ด้วยเหตุนี้ คุณจึงไม่เห็นไอคอนแม่กุญแจแสดงใน UI ของ 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 ใช้ Proof Key for 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

การยืนยันหมายเลขโทรศัพท์

Google จะยืนยันได้อย่างไรว่าหมายเลขโทรศัพท์ยังคงเป็นของผู้ใช้เดิมเพื่อรักษาความปลอดภัยของแอป Messages ของ Google

  • การยืนยันหมายเลขโทรศัพท์ครั้งแรก: Google ใช้เทคนิคต่างๆ เพื่อระบุหมายเลขโทรศัพท์ของผู้ใช้ปลายทาง (เช่น MSISDN หรือหมายเลขโทรศัพท์มือถือของผู้ใช้บริการโทรคมนาคมระหว่างประเทศ) เทคนิคเหล่านี้รวมถึงการผสานรวม API โดยตรงกับผู้ให้บริการเครือข่าย, SMS ที่ส่งจากอุปกรณ์เคลื่อนที่ และการขอให้ผู้ใช้ปลายทางป้อนหมายเลขโทรศัพท์ เมื่อระบุหมายเลขโทรศัพท์ได้แล้ว Google อาจส่ง SMS รหัสผ่านที่สามารถใช้งานได้เพียงครั้งเดียว (OTP) ที่มองไม่เห็นเพื่อยืนยันหมายเลขโทรศัพท์

  • การรักษาความปลอดภัยหลังจากการยืนยันครั้งแรก: เมื่อผู้ให้บริการเครือข่ายมีการผสานรวม API โดยตรง ผู้ให้บริการเครือข่ายจะส่งฟีดการยกเลิกการใช้งานซิม/MSISDN ไปยัง Google เป็นระยะๆ เพื่อปิดใช้ RCS และปิดใช้ RBM สำหรับหมายเลขโทรศัพท์ที่ไม่ได้ใช้งานอีกต่อไป นอกจากนี้ Google ยังอาจตรวจสอบการเปลี่ยนแปลงความเป็นเจ้าของหมายเลขโทรศัพท์ผ่านสัญญาณของอุปกรณ์ เช่น การนำซิมออกและกิจกรรมของซิม รวมถึงการยืนยันหมายเลขโทรศัพท์ซ้ำเป็นระยะๆ

ความเป็นส่วนตัวและความปลอดภัย

Google ทำการรายงานเกี่ยวกับตัวแทน RBM อย่างไร

Google มีการรายงานภายในเกี่ยวกับจำนวนรวมของผู้ใช้ปลายทาง ข้อความ และการตอบกลับสำหรับตัวแทนแต่ละรายโดยอิงตามข้อมูลในช่วง 28 วันที่ผ่านมา Google ใช้ข้อมูลนี้เพื่อการวินิจฉัย การปรับปรุงระบบ และเพื่อสร้างรายงานการเรียกเก็บเงินสำหรับผู้ให้บริการเครือข่าย ระบบจะไม่จัดเก็บเนื้อหาข้อความเพื่อวัตถุประสงค์ในการรายงาน หลังจากผ่านไป 28 วัน Google จะจัดเก็บเฉพาะข้อมูลการรายงานแบบรวม และไม่มีการจำกัดเวลาในการจัดเก็บนี้ ข้อมูลแบบรวมที่แชร์ภายนอกจะมีอายุการใช้งาน (TTL) 63 วัน

ระบบจะจัดเก็บรายงานการเรียกเก็บเงิน และบันทึกกิจกรรม ที่ผู้ให้บริการเครือข่ายได้รับไว้ในเซิร์ฟเวอร์ของ Google เป็นเวลา 63 วัน พาร์ทเนอร์ผู้ให้บริการเครือข่ายอาจเลือกดาวน์โหลดไฟล์เหล่านี้และเก็บไว้ได้นานเท่าที่เห็นสมควร

Google ใช้ข้อมูลผู้ใช้ปลายทางภายนอก RBM ไหม

Google ใช้ข้อมูลผู้ใช้ปลายทางเพื่อให้บริการและปรับปรุงบริการ RBM เท่านั้น ตามที่ระบุไว้ ในส่วนที่ 5.2 ของ DPA

ตัวอย่างเช่น Google อาจ ดำเนินการต่อไปนี้กับข้อมูลผู้ใช้ปลายทาง

แต่ Google จะไม่ ดำเนินการต่อไปนี้กับข้อมูลผู้ใช้ปลายทาง

  • กำหนดเป้าหมายโฆษณาตามเนื้อหาข้อความ
  • แชร์เนื้อหาข้อความกับคู่แข่งหรือบุคคลที่สาม ยกเว้นหน่วยงานบังคับใช้กฎหมายตามที่กฎหมายที่เกี่ยวข้องกำหนด

Google อ่านข้อความระหว่างธุรกิจกับผู้ใช้ปลายทางไหม

การตรวจจับและป้องกันสแปมของ Google อาจสแกนเนื้อหาของข้อความที่ส่งโดยธุรกิจเพื่อดูการละเมิดนโยบายการใช้งานที่ยอมรับได้ Google ไม่มีสิทธิ์เข้าถึงเนื้อหาของข้อความใดๆ ที่ผู้ใช้ส่งไปยังธุรกิจ อย่างไรก็ตาม เมื่อผู้ใช้ปลายทางรายงาน การสนทนาว่าเป็นสแปม ระบบจะดำเนินการดังนี้

  • ข้อมูลของผู้ส่งและข้อความล่าสุดที่ส่งมาจากธุรกิจดังกล่าวจะถูกส่งให้กับ Google และอาจส่งให้กับผู้ให้บริการเครือข่ายของผู้ใช้
  • การตรวจจับและป้องกันสแปมของ Google อาจประมวลผลเนื้อหาของข้อความที่ธุรกิจส่งเป็นการชั่วคราว และใช้สัญญาณเหล่านั้นในการฝึกโมเดล AI เพื่อปรับปรุงการตรวจจับและป้องกันสแปม
  • พนักงานและผู้รับเหมาของ Google อาจตรวจสอบข้อมูลสแปมเพื่อช่วยปรับปรุงการป้องกันของ Google จากสแปมและการละเมิด เจ้าหน้าที่ตรวจสอบจะเข้าถึงข้อมูลนี้ได้ในระดับจำกัดและในระดับตรวจสอบเป็นเวลา 30 วัน ระบบจะปกปิดหมายเลขโทรศัพท์ของผู้ใช้ปลายทางเพื่อวัตถุประสงค์ในการตรวจสอบสแปม

Google ให้ข้อมูลใดบ้างเกี่ยวกับผู้ใช้ปลายทางแก่ธุรกิจ

Google จะแชร์หมายเลขโทรศัพท์ของผู้ใช้ปลายทางกับธุรกิจเพื่อระบุตัวผู้ใช้ปลายทางในการสนทนา เพื่อให้การสนทนา RBM เป็นไปได้ แต่จะไม่มีการแชร์ข้อมูลส่วนบุคคลอื่นๆ กับธุรกิจ

ในนโยบายการใช้งานที่ยอมรับได้ ส่วนความเป็นส่วนตัวและความปลอดภัยจำกัดความสามารถของธุรกิจในการเก็บรวบรวมและใช้ข้อมูลเกี่ยวกับลูกค้าของตนเองไหม

Google ไม่ได้มีเจตนาที่จะจำกัดความสามารถของธุรกิจในการให้บริการแก่ลูกค้า ธุรกิจสามารถจัดเก็บการสนทนาระหว่างผู้ใช้ปลายทางกับธุรกิจที่สร้างขึ้นผ่าน RBM API ได้ตามข้อกำหนดของนโยบายความเป็นส่วนตัวของธุรกิจเอง

ใน ข้อกำหนดในการให้บริการ RBM ข้อความต่อไปนี้หมายความว่าอย่างไร "คุณจะได้รับและเก็บรักษาความยินยอมที่จำเป็นทั้งหมดเพื่อให้มีการประมวลผลข้อมูลส่วนบุคคลภายใต้ข้อกำหนด RBM เหล่านี้"

Google คาดหวังให้ธุรกิจทั้งหมดที่ใช้ RBM ปฏิบัติตามกฎระเบียบด้านข้อมูลและความปลอดภัยที่เกี่ยวข้อง (เช่น GDPR) และจัดทำนโยบายความเป็นส่วนตัวที่อธิบายวิธีที่ธุรกิจใช้และ/หรือแชร์ข้อมูลผู้ใช้ปลายทาง นักพัฒนาแอปต้องระบุนโยบายความเป็นส่วนตัวเพื่อให้ระบบพิจารณาตัวแทนสำหรับการตรวจสอบการเปิดตัว

RBM ปกป้องผู้ใช้ปลายทางจาก URL ที่เป็นอันตรายได้อย่างไร

RBM ใช้ Google Safe Browsing เพื่อสแกนลิงก์ใน ข้อความและบล็อกข้อความที่มีมัลแวร์หรือลิงก์ฟิชชิงโดยอัตโนมัติเพื่อปกป้องผู้ใช้ปลายทาง หาก Google Safe Browsing ไม่บล็อกข้อความที่มีลิงก์ แอปรับส่งข้อความอาจสร้างภาพขนาดย่อเพื่อแสดงปลายทางของลิงก์

ความร่วมมือของ Google เมื่อธุรกิจได้รับการตรวจสอบ

ธุรกิจของเราอยู่ภายใต้กฎระเบียบและอาจได้รับการตรวจสอบ Google จะให้ความร่วมมือไหม

ธุรกิจมีหน้าที่รับผิดชอบในการตรวจสอบว่าบริษัทของตนเป็นไปตามกฎระเบียบที่เกี่ยวข้อง Google จะตอบคำถามจากหน่วยงานบังคับใช้กฎหมายและหน่วยงานกำกับดูแลตามกฎหมายที่เกี่ยวข้องเท่านั้น

การตอบสนองต่อเหตุการณ์

Google จัดการการละเมิดข้อมูลอย่างไร

โปรดดูส่วนที่ 7.2 เหตุการณ์ที่ส่งผลต่อข้อมูลใน DPA

ความสามารถของเครือข่ายที่ไม่รองรับ

RBM ไม่รองรับความสามารถของเครือข่ายใดบ้าง

  • ส่วนหัวที่กำหนดเองเพื่ออนุญาตให้ผ่านไฟร์วอลล์
  • ช่วงบล็อก Classless Inter-Domain Routing (CIDR) จากบริการของ Google