คู่มือนี้จะอธิบายข้อกำหนดด้านความปลอดภัยที่พบบ่อยสำหรับผู้ใช้ Google Ads และ Google Ads API
การยืนยันแบบ 2 ขั้นตอนคืออะไร
การยืนยันแบบ 2 ขั้นตอนหรือ 2SV หรือที่เรียกว่าการตรวจสอบสิทธิ์แบบ 2 ปัจจัย (2FA) เป็นการตรวจสอบสิทธิ์แบบ หลายปัจจัย (MFA) รูปแบบหนึ่งที่เพิ่ม ปัจจัยที่ 2 ในการครอบครอง ("สิ่งที่คุณมี") นอกเหนือจากชื่อผู้ใช้และ รหัสผ่าน
2SV ปลอดภัยกว่าระบบการตรวจสอบสิทธิ์แบบปัจจัยเดียว ซึ่งการตรวจสอบสิทธิ์จะใช้เพียงชื่อผู้ใช้และปัจจัยด้านความรู้เดียว ("สิ่งที่คุณรู้") ซึ่งโดยปกติคือรหัสผ่าน การกำหนดให้ใช้ปัจจัยที่ 2 จะทำให้ผู้ใช้ที่ไม่ได้รับอนุญาตละเมิดบัญชีของคุณได้ยากขึ้น รหัสผ่านอาจถูกละเมิดได้ แต่การใช้ 2SV หมายความว่ารหัสผ่านที่ถูกละเมิดเพียงอย่างเดียวไม่เพียงพอต่อการเข้าถึง
สิ่งที่ต้องมีหรือทำสำหรับการยืนยันแบบ 2 ขั้นตอน
ส่วนต่อไปนี้จะแสดงรายละเอียดสิ่งที่ต้องมีหรือทำสำหรับการยืนยันแบบ 2 ขั้นตอนเพื่อใช้ Google Ads และ Google Ads API
ข้อกำหนดของ Google Ads
Google Ads รองรับข้อบังคับด้านความปลอดภัยของบัญชีดูแลจัดการ ซึ่งช่วยให้ ผู้ดูแลระบบของบัญชีดูแลจัดการบังคับใช้การตั้งค่าความปลอดภัยขั้นต่ำกับบัญชีย่อยปัจจุบัน และในอนาคตทั้งหมดที่บัญชีดูแลจัดการเป็นเจ้าของที่มีสิทธิ์ระดับผู้ดูแลระบบ นโยบายหนึ่งดังกล่าวอนุญาตให้ผู้ดูแลระบบของบัญชีดูแลจัดการกำหนดให้ผู้ใช้ที่เป็นเจ้าของบัญชีย่อยเปิดใช้การยืนยันแบบ 2 ขั้นตอนในบัญชีเพื่อลงชื่อเข้าใช้
โทเค็นการรีเฟรช OAuth ที่มีอยู่จะไม่ได้รับผลกระทบจากนโยบายนี้ ยกเว้นการเรียกใช้ Google Ads API โทเค็นเหล่านี้จะยังคงทำงานได้ตามปกติ และระบบจะไม่แจ้งให้ผู้ใช้ให้สิทธิ์อีกครั้งเมื่อได้รับโทเค็นเพื่อการเข้าถึง OAuth อย่างไรก็ตาม
การเรียกใช้ Google Ads API จะล้มเหลวโดยมีข้อผิดพลาด TWO_STEP_VERIFICATION_NOT_ENROLLED
จนกว่าผู้ใช้จะเปิดใช้การยืนยันแบบ 2 ขั้นตอนในบัญชี Google
ข้อกำหนดของ Google Ads API
Google Ads API กำหนดให้ผู้ใช้ทั้งหมดที่ทำตามเวิร์กโฟลว์ การตรวจสอบสิทธิ์ผู้ใช้เพื่อสร้างโทเค็นการรีเฟรช OAuth 2.0 ใหม่ต้องใช้ 2SV ผู้ใช้จะได้รับแจ้งให้ตรวจสอบสิทธิ์ด้วยปัจจัยที่ 2 เสมอ นอกเหนือจากชื่อผู้ใช้และรหัสผ่าน
หากผู้ใช้ไม่ได้เปิดใช้การยืนยันแบบ 2 ขั้นตอน ระบบจะแจ้งให้เพิ่มวิธีการยืนยันแบบ 2 ขั้นตอน
โทเค็นการรีเฟรช OAuth ที่มีอยู่จะไม่ได้รับผลกระทบจากนโยบายนี้ โทเค็นเหล่านี้จะยังคงทำงานได้ตามปกติ และระบบจะไม่แจ้งให้ผู้ใช้ให้สิทธิ์อีกครั้งเมื่อได้รับโทเค็นเพื่อการเข้าถึง OAuth
พาสคีย์คืออะไร
พาสคีย์เป็นการตรวจสอบสิทธิ์แบบหลายปัจจัยรูปแบบหนึ่งที่ผสานรวมวิทยาการเข้ารหัสคีย์สาธารณะกับการรักษาความปลอดภัยที่มีอยู่ของอุปกรณ์ (เช่น ลายนิ้วมือ การสแกนใบหน้า หรือ PIN ล็อกหน้าจอ) เพื่อยืนยันตัวตนของเจ้าของบัญชี พาสคีย์ผสานรวมการครอบครองอุปกรณ์ ("สิ่งที่คุณมี" เช่น อุปกรณ์เคลื่อนที่หรือคีย์ FIDO2) กับความรู้เกี่ยวกับวิธีปลดล็อกอุปกรณ์ ("สิ่งที่คุณรู้") ซึ่งเป็นทางเลือกแทนรหัสผ่านที่สะดวก
พาสคีย์ถือว่าปลอดภัยกว่า 2FA ด้วยเหตุผลต่อไปนี้
- ผูกกับโดเมน: พาสคีย์ผูกกับโดเมนที่เฉพาะเจาะจง (เช่น
google.com) และจะใช้ไม่ได้กับเว็บไซต์หลอกลวงที่แอบอ้างเป็นเว็บไซต์เดิม (เช่นgoogle-fake.com) - ผูกกับอุปกรณ์: พาสคีย์จะล็อกอยู่เบื้องหลังการตรวจสอบสิทธิ์ในเครื่องของอุปกรณ์ และต้องให้ผู้ใช้แสดงตัวตนเพื่อปลดล็อก
- ไม่มีข้อมูลลับให้ขโมย: พาสคีย์ใช้วิธีการท้าทาย-ตอบสนองด้วยวิทยาการเข้ารหัสคีย์สาธารณะระหว่างอุปกรณ์กับเซิร์ฟเวอร์ และไม่ใช้รหัสผ่านแบบใช้งานครั้งเดียวหรือรหัสผ่านที่อาจถูกดักจับ
วิธีตั้งค่าพาสคีย์
วิธีตั้งค่าพาสคีย์
- ไปที่ g.co/passkeys
- คลิกสร้างพาสคีย์ เพื่อลงชื่อเข้าใช้เครื่องมือจัดการคีย์ความปลอดภัย
- สร้างพาสคีย์โดยทำตามข้อความแจ้งที่อุปกรณ์แสดง
สิ่งที่ต้องมีหรือทำสำหรับพาสคีย์
ส่วนต่อไปนี้จะแสดงรายละเอียดสิ่งที่ต้องมีหรือทำสำหรับพาสคีย์เพื่อใช้ Google Ads และ Google Ads API
ข้อกำหนดของ Google Ads
Google Ads รองรับการใช้พาสคีย์เพื่อลงชื่อเข้าใช้ บัญชี ผู้ลงโฆษณาบางรายอาจต้องใช้พาสคีย์ เพื่อให้สิทธิ์การดำเนินการที่มีความละเอียดอ่อนภายในบัญชี Google Ads
ข้อกำหนดของ Google Ads API
Google Ads API อาจกำหนดให้ผู้ใช้บางรายต้องตรวจสอบสิทธิ์ด้วยพาสคีย์ ผู้ใช้ที่บังคับใช้ จะต้องตรวจสอบสิทธิ์โดยใช้พาสคีย์เมื่อทำตามเวิร์กโฟลว์การตรวจสอบสิทธิ์ ผู้ใช้เพื่อสร้างโทเค็นการรีเฟรช OAuth 2.0 ใหม่สำหรับ Google Ads API หากคุณยังไม่ได้สร้างพาสคีย์ ระบบจะแจ้งให้สร้างและใช้พาสคีย์เพื่อทำเวิร์กโฟลว์การตรวจสอบสิทธิ์ให้เสร็จสมบูรณ์ การตรวจสอบสิทธิ์รูปแบบอื่นๆ ที่ใช้รหัสผ่านเพียงอย่างเดียว หรือกลไกการตรวจสอบสิทธิ์แบบ 2 ปัจจัย (2FA) เช่น รหัสผ่านแบบใช้ครั้งเดียวที่อิงตามเวลา (TOTP) หรือรหัสที่อิงตาม SMS จะไม่ได้รับอนุญาตสำหรับบัญชีที่บังคับใช้
โทเค็นการรีเฟรช OAuth ที่มีอยู่จะไม่ได้รับผลกระทบจากนโยบายนี้ โทเค็นเหล่านี้จะยังคงทำงานได้ตามปกติ และระบบจะไม่แจ้งให้ผู้ใช้ให้สิทธิ์อีกครั้งเมื่อได้รับโทเค็นเพื่อการเข้าถึง OAuth