ความท้าทายด้านการธนาคารเพิ่มขึ้น: PSD2 หมายถึงกฎการแชร์ข้อมูลใหม่
เผยแพร่แล้ว: 2018-04-13หลายคนคงเคยได้ยินคำสั่ง European Banking Authority (หรือ EBA) ของสหภาพยุโรปที่เรียกว่า PSD2 (ย่อมาจาก Payment Services Directive) แนวทางเหล่านี้ได้รับการเผยแพร่ครั้งแรกเมื่อปลายปี 2015 ภายในเดือนมกราคม 2018 ประเทศสมาชิกทั้งหมดต้องปฏิบัติตามกฎระเบียบ
อุตสาหกรรมการธนาคารกำลังเผชิญกับความท้าทายมากมายหากพวกเขาไม่ได้คิดถึงอนาคตดิจิทัล
ทำความเข้าใจการรับรองความถูกต้องของลูกค้าสำหรับ PSD2 ของสหภาพยุโรป
วัตถุประสงค์หลักของ PSD2 ได้แก่:
- เปิดโอกาสทางการตลาดใหม่ๆ ให้กับผู้เล่นที่หลากหลาย เช่น ผู้ค้าออนไลน์ พร้อมยกระดับสนามแข่งขันสำหรับผู้มีส่วนได้ส่วนเสียหลักทั้งหมด
- ให้ความโปร่งใสของผู้บริโภคและทางเลือกของผู้บริโภค
- ขอแนะนำแนวทางปฏิบัติด้านความปลอดภัยแบบใหม่ที่มีประสิทธิภาพมากขึ้นสำหรับ การชำระเงิน ออนไลน์
โดยทั่วไปมีหลักเกณฑ์หลายประการสำหรับ PSD2; อย่างไรก็ตาม สามารถดาวน์โหลดแนวทาง PSD2 ที่ดีกว่าข้อใดข้อหนึ่งได้จาก MEF (ฟอรัมระบบนิเวศมือถือ)
การตรวจสอบลูกค้าที่แข็งแกร่ง
องค์ประกอบหลักประการหนึ่งของข้อบังคับ PSD2 คือแนวคิดของ Strong Customer Authentication (หรือ SCA) บันทึก EBA: “ต้องขอบคุณ PSD2 ที่ผู้บริโภคจะได้รับการคุ้มครองที่ดีขึ้นเมื่อพวกเขาทำการชำระเงินทางอิเล็กทรอนิกส์หรือการทำธุรกรรม (เช่นการใช้ธนาคารออนไลน์หรือการซื้อออนไลน์)
มาตรฐานทางเทคนิคด้านกฎระเบียบ (RTS) ทำให้การรับรองความถูกต้องของลูกค้า (SCA) เป็นพื้นฐานสำหรับการเข้าถึงบัญชีการชำระเงินของตน เช่นเดียวกับการชำระเงินออนไลน์” ในระยะสั้น SCA เรียกร้องให้มีการตรวจสอบสิทธิ์แบบสองปัจจัย (2FA) อย่างน้อย
การรับรองความถูกต้องด้วยสองปัจจัยหมายความว่าผู้ใช้จะต้อง "พิสูจน์" ตัวตนของพวกเขาด้วยสององค์ประกอบที่แยกจากกันในสาม:
- สิ่งที่พวกเขารู้ (รหัส PIN หรือรหัสผ่าน)
- สิ่งที่พวกเขามี (อุปกรณ์พกพา การ์ด)
- บางอย่างที่เป็น (ลายนิ้วมือ การสแกนใบหน้า เช่น ไบโอเมตริกซ์)
EBA ตั้งข้อสังเกตว่า SCA มักใช้ทั่วทั้งสหภาพยุโรป อย่างไรก็ตาม กรณีนี้ไม่เสมอไปสำหรับธุรกรรมการชำระเงินออนไลน์ เช่น การชำระเงินด้วยบัตรเครดิตหรือการโอนเงินผ่านธนาคารโดยตรง SCA มีผลบังคับใช้ในประเทศในสหภาพยุโรปของเบลเยียม เนเธอร์แลนด์ และสวีเดน) อย่างไรก็ตาม ในประเทศอื่น ๆ ในสหภาพยุโรป SCA มีผลบังคับใช้โดยสมัครใจเท่านั้น ตามข่าวประชาสัมพันธ์ที่ยอดเยี่ยมจากคณะกรรมาธิการยุโรป
ในขณะที่ประเทศสมาชิกสหภาพยุโรปจะต้องดำเนินการ PSD2 ในเดือนมกราคม 2018 SCA จะมีผลบังคับใช้ 18 เดือนต่อมาหลังจากมาตรฐานทางเทคนิคด้านกฎระเบียบของ EBA (RTS) หลังจากวันที่มีผลบังคับใช้ของ RTS (ซึ่งคาดว่าจะเป็นปลายปีนี้) . โดยพื้นฐานแล้ว เรากำลังดูช่วงกลางถึงปลายปี 2019 (กันยายน 2019 เป็นวันดังกล่าวที่เอกสารบางส่วนได้ยกมา) ซึ่งจะช่วยให้ผู้มีส่วนได้ส่วนเสียทั้งหมดมีเวลาเพียงพอในการรวม SCA และข้อกำหนดด้านความปลอดภัยอื่นๆ เข้ากับระบบและเวิร์กโฟลว์ของตน
ธนาคารเพื่อรายย่อย: ไลออนส์ นายธนาคาร และฟินเทค โอ้!
Fintechs คุกคามสถานะที่เป็นอยู่ ต่างจากธนาคารตรงที่พวกเขาไม่มีภาระผูกพันกับมรดก กฎระเบียบ และในกรณีส่วนใหญ่ แม้กระทั่งความจำเป็นในการทำเงิน นายธนาคารรายย่อยจำเป็นต้องปรับตัวและให้ความสำคัญกับความสัมพันธ์กับลูกค้าเพื่อแข่งขัน
2FA สำหรับ SCA
เมื่อพิจารณาจากไทม์ไลน์ของ SCA แล้ว ปี 2018 จึงเป็นช่วงเวลาที่เหมาะสำหรับธุรกิจต่างๆ ในการเริ่มใช้โซลูชัน 2FA เพื่อพิจารณาความปลอดภัยที่เพิ่มขึ้นตามที่จำเป็น
บริษัทกฎหมายระหว่างประเทศ Taylor Wessing ในเอกสารของพวกเขา: การรับรองความถูกต้องของลูกค้าที่เข้มงวดภายใต้ PSD2 ระบุว่า "EBA เห็นด้วยกับผู้ตอบแบบสอบถามส่วนใหญ่ในเอกสารให้คำปรึกษาเพื่อให้แน่ใจว่าเทคโนโลยีเป็นกลางและอนุญาตให้มีการพัฒนาที่เป็นมิตรต่อผู้ใช้ วิธีการชำระเงินที่เข้าถึงได้และเป็นนวัตกรรมใหม่ ไม่ควรกำหนดองค์ประกอบการรับรองความถูกต้องเพิ่มเติม” ซึ่งหมายความว่า EBA ไม่ได้ระบุลักษณะที่อาจนำ 2FA ไปใช้ มีรูปแบบต่างๆ มากมาย รวมถึงการส่งโทเค็นผ่านช่องทางมือถือ เช่น SMS หรือการแจ้งเตือนแบบพุช หรือช่องทางอีเมลแบบเดิม ตลอดจนโซลูชั่น TOTP soft token และอื่นๆ
จากทั้งหมดที่กล่าวมานี้ เราควรชี้ให้เห็นว่า เช่นเดียวกับแผนการปรับใช้ 2FA ที่ดีใดๆ ก็ตาม มีข้อจำกัดบางประการและข้อบังคับเฉพาะ และสิ่งเหล่านี้จำเป็นต้องได้รับการพิจารณาอย่างรอบคอบ
รหัสยืนยันตัวตน
RTS ตั้งข้อสังเกตว่าการสร้างรหัสรับรองความถูกต้องเป็นไปตามเงื่อนไขต่อไปนี้:
- ข้อมูลเกี่ยวกับความรู้ การครอบครอง และมรดกไม่สามารถได้มาจากการเปิดเผยรหัสรับรองความถูกต้อง
- ไม่สามารถสร้างรหัสการตรวจสอบสิทธิ์ใหม่ตามความรู้ของรหัสการตรวจสอบสิทธิ์อื่น ๆ ที่สร้างขึ้นก่อนหน้านี้
- รหัสยืนยันตัวตนไม่สามารถปลอมแปลงได้
นอกจากนี้ RTS ระบุว่าควรพยายามตรวจสอบความถูกต้องที่ล้มเหลวไม่เกิน 5 ครั้งภายในระยะเวลาที่ใช้งานได้ของรหัส และเวลาสูงสุดที่ไม่มีกิจกรรมโดยผู้ชำระเงินหรือผู้ใช้หลังจากตรวจสอบสิทธิ์ในการเข้าถึงบัญชีการชำระเงินออนไลน์แล้วจะต้องไม่เกิน 5 นาที .

การเชื่อมโยงแบบไดนามิกของธุรกรรม
RTS ระบุว่าธุรกรรมทางอิเล็กทรอนิกส์ทางไกล - โดยพื้นฐานแล้วการชำระเงินผ่านอินเทอร์เน็ต (ไม่ว่าจะบนอุปกรณ์เดสก์ท็อป เช่น แล็ปท็อปหรืออุปกรณ์มือถือ) จะต้องมีองค์ประกอบที่ "เชื่อมโยงธุรกรรมแบบไดนามิกกับจำนวนเฉพาะและผู้รับเงินเฉพาะ" RTS ถือว่านี่เป็นรูปแบบเพิ่มเติมของ SCA
สำหรับข้อกำหนด SCA นี้ จำนวนเงินของธุรกรรมการชำระเงินรวมถึงผู้ที่ได้รับเงิน (หรือผู้ค้า) ควรส่งคืนให้กับผู้ใช้ในเวลาที่ทำธุรกรรม 2FA หากมีการเปลี่ยนแปลงจำนวนเงินหรือผู้รับเงิน ควรสร้างรหัสยืนยันอื่น (เช่น “เชื่อมโยงแบบไดนามิก” รหัสนั้นกับผู้รับเงินรายใหม่และ/หรือจำนวนเงินที่ชำระ) ข้อความ SMS ที่มีข้อมูลที่จำเป็นทั้งหมดอาจดูเหมือนภาพทางด้านขวา: รหัสความปลอดภัย 10 นาที ชื่อผู้ขาย (หรือผู้รับเงิน) และจำนวนเงินที่ทำธุรกรรม
ที่น่าสนใจคือ รหัสรับรองความถูกต้องที่สร้างโดยแอปที่สอดคล้องกับ TOTP ของบุคคลที่สาม เช่น Google Authenticator นั้นถูกสร้างขึ้นโดยแยกจากข้อมูลการชำระเงิน / ผู้ขายโดยสิ้นเชิง ดังนั้นจึงไม่สามารถเชื่อมโยงแบบไดนามิกได้
ความเป็นอิสระของช่อง
ข้อกำหนดนี้ค่อนข้างยุ่งยาก RTS ระบุว่า “ผู้ให้บริการชำระเงินจะต้องนำมาตรการความปลอดภัยมาใช้ โดยองค์ประกอบใด ๆ ของการรับรองความถูกต้องของลูกค้าที่แข็งแกร่งหรือรหัสการตรวจสอบความถูกต้องนั้นถูกใช้ผ่านอุปกรณ์อเนกประสงค์ เพื่อลดความเสี่ยงที่จะเป็นผลมาจากอุปกรณ์อเนกประสงค์นั้น ถูกประนีประนอม” อุปกรณ์อเนกประสงค์อาจเป็นอุปกรณ์พกพา แท็บเล็ต หรือแม้แต่แล็ปท็อป
หากผู้ใช้ใช้แล็ปท็อปและได้รับการร้องขอให้ชำระเงิน ร้านค้านั้นอาจส่ง SMS ไปยังอุปกรณ์มือถือของผู้ใช้พร้อมกับผู้รับเงิน (เช่น ผู้ค้า) ตลอดจนจำนวนเงินที่จะต้องจ่ายพร้อมกับการรับรองความถูกต้อง รหัสในเนื้อหาของ SMS
ในอีกตัวอย่างหนึ่ง หากผู้ใช้ใช้อุปกรณ์มือถือเพื่อโต้ตอบกับผู้ขายและเริ่มชำระเงิน ความเป็นอิสระของช่องทางนี้ไม่ ได้ ห้ามการใช้ SMS หรือช่องทางการจัดส่งเฉพาะมือถือโดยเฉพาะ ที่นี่มันเป็นเส้นบางๆ ในหลายกรณี อุปกรณ์เดียวที่ผู้ใช้มีคืออุปกรณ์อเนกประสงค์ เช่น โทรศัพท์มือถือ แต่ความเป็นอิสระของช่องก็แค่นั้น – ช่อง อิสระ ในอุปกรณ์เดียวกัน – SMS ที่มีรหัสการตรวจสอบสิทธิ์เป็นช่องทางอื่น (อันที่จริงมันเป็น ช่องสัญญาณนอกแบนด์ เข้าถึงผ่านหมายเลขโทรศัพท์มือถือ) มากกว่ามือถือ แอพหรือเว็บเบราว์เซอร์ที่ผู้ใช้มีส่วนร่วมกับผู้ขาย ความเป็นอิสระของช่องทางเดียวกันจะนำไปใช้กับการใช้แอพมือถือเพื่อสร้างรหัสที่สอดคล้องกับ TOTP (เช่น Google Authenticator) แต่ดังที่ระบุไว้ก่อนหน้านี้ รหัสการร้องเรียน TOTP ล้มเหลวในการเชื่อมโยงแบบไดนามิกของธุรกรรม
ในทางกลับกัน หากผู้ใช้ใช้แอปบนอุปกรณ์เคลื่อนที่เพื่อเข้าถึงผู้ขาย การแจ้งเตือนแบบพุชไปยังแอปเดียวกันนั้น (ด้วยรหัสการตรวจสอบสิทธิ์) จะไม่สามารถทำได้ เนื่องจากเป็นช่องทางเดียวกัน
มีคนบอกว่า 2FA ทาง SMS นั้นไม่ปลอดภัยอย่างมากและในบางกรณีก็อาจเป็นจริงได้ ใช่ มีบางกรณีที่ผู้โจมตีสามารถเข้าถึงข้อความ SMS 2FA ผ่าน SS7 ในโอเปอเรเตอร์เดียว อย่างไรก็ตาม ช่องโหว่เหล่านี้จำนวนมากได้ถูกปิดไปแล้ว นอกจากนี้ มันสำคัญมากที่วิธีการสร้างและมอบรหัสรับรองความถูกต้องให้กับผู้ใช้ และวิธีที่ผู้ให้บริการส่งข้อความส่งรหัสดังกล่าว
ในสถานการณ์ที่อุปกรณ์อเนกประสงค์แพร่หลาย (และในปัจจุบัน อุปกรณ์เหล่านี้เป็นและจะยังคงเป็นอุปกรณ์ที่แพร่หลายมากที่สุด) ผู้ให้บริการโทรศัพท์มือถือที่จัดเตรียมช่องทางการรับส่งข้อความควรเป็นช่องทางนอกแบนด์ที่ทำงานได้สำหรับโทเค็น 2FA
สำหรับการวิเคราะห์ที่ละเอียดยิ่งขึ้น ฉันพบบล็อกโพสต์ที่ให้ข้อมูลโดย Frederik Mennes ซึ่งให้รายละเอียดเพิ่มเติมเกี่ยวกับสถานการณ์ประเภทใด โดยเฉพาะสำหรับอุปกรณ์อเนกประสงค์ ควรเป็นไปตาม PSD2 SCA
PSD2 SCA ไม่ควรมองข้าม แต่โซลูชัน 2FA ที่ใช้งานแล้วจำนวนมากควรใช้งานได้ อย่างไรก็ตาม เราทราบด้วยว่าผู้ค้าออนไลน์จำนวนมากยังไม่ได้ให้บริการโซลูชั่นที่สอดคล้องกับ PSD2 SCA ในการเขียนนี้ ยังมีเวลาเหลือเฟือที่จะรวม SCA เข้ากับเวิร์กโฟลว์การชำระเงิน
SAP Authentication 365 เป็นโซลูชันที่ให้โซลูชันระบบคลาวด์ที่ใช้ API เพื่อให้ธุรกิจสามารถใช้ SCA ที่สอดคล้องกับ PSD2 ได้ บริการมือถือ SAP Authentication 365 เป็นบริการแบบ end-to-end ที่ช่วยให้คุณสามารถใช้บริการการตรวจสอบสิทธิ์แบบสองปัจจัย (2FA) แบบหลายช่องสัญญาณได้อย่างรวดเร็วและปลอดภัย ด้วยการรับรองความถูกต้องที่ปรับให้เหมาะกับธุรกิจดิจิทัลของคุณ
ช่วยปกป้องข้อมูลประจำตัวและข้อมูลของลูกค้าองค์กรของคุณโดยเปิดใช้งานการรับรองความถูกต้องผ่าน SMS, อีเมล, การแจ้งเตือนแบบพุชหรือซอฟต์โทเค็น TOTP REST API จาก SAP ช่วยลดความยุ่งยากในการสร้างและรับรองความถูกต้องของรหัสตรวจสอบความถูกต้องหรือรหัสการพิสูจน์ตัวตน และให้ความยืดหยุ่นและความสามารถในการเปิดใช้งานการนำกลยุทธ์ SCA ที่สอดคล้องกับ PSD2 ไปใช้
