คู่มือนี้อธิบายข้อกำหนดด้านความปลอดภัยที่พบบ่อยสำหรับผู้ใช้ 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 กำหนดให้ผู้ใช้ทุกคนต้องใช้ 2SV โดยทำตามเวิร์กโฟลว์ การตรวจสอบสิทธิ์ผู้ใช้เพื่อสร้างโทเค็นการรีเฟรช OAuth 2.0 ใหม่ ผู้ใช้จะต้องผ่านการตรวจสอบสิทธิ์ด้วยปัจจัยที่ 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