เปิดธนาคาร API ธนาคารแบบเปิดกำลังกลายเป็นปรากฏการณ์ระดับโลกอย่างรวดเร็ว ด้วยกฎหมายของ PSD2 ของสหภาพยุโรป บริษัทต่างๆ ในยุโรปและภูมิภาคอื่นๆ ได้เริ่มยอมรับแนวทางปฏิบัติเกี่ยวกับธนาคารแบบเปิดไม่ว่าจะได้รับแรงหนุนจากกฎระเบียบของรัฐบาลหรือแรงกดดันของตลาด
ธนาคารต่างๆ กำลังเปิด API สำหรับ FinTechs เพื่อผสานรวมกับข้อมูลลูกค้า ทำให้เกิดเศรษฐกิจรูปแบบใหม่ทั้งหมดของบริการทางการเงินที่ปรับเปลี่ยนได้ ซึ่งช่วยปรับปรุงประสบการณ์ของลูกค้าปลายทาง อย่างไรก็ตาม ข้อมูลธนาคารเป็นจุดสัมผัสที่ละเอียดอ่อน การเปิดโครงสร้างพื้นฐานของธนาคารทำให้เกิดความเสี่ยงอย่างมาก และจำเป็นต้องมีมาตรการรักษาความปลอดภัยที่ได้รับการปรับปรุงเพื่อให้เป็นไปตามข้อกำหนดและข้อบังคับด้านข้อมูล แล้วเราจะรักษาความปลอดภัยให้กับธนาคารแบบเปิดได้อย่างไร?
ด้านล่างนี้ เราจะหารือเกี่ยวกับวิธีการเปิดธนาคารโดยไม่ทำให้พวกเขาเสี่ยง เราจะแนะนำว่าธนาคารเปิดคืออะไรและครอบคลุมมาตรฐานความปลอดภัยระดับธนาคารที่ล้ำสมัยเพื่อให้แน่ใจว่า API การธนาคารและความเป็นส่วนตัวของข้อมูลเป็นไปตามกฎระเบียบและการปฏิบัติตามข้อกำหนดล่าสุดเมื่อเร็วๆ นี้เราได้นำ Chris Wood ผู้เชี่ยวชาญด้านการธนาคารแบบเปิดและผู้เชี่ยวชาญ API เข้ามาสำหรับการ
รักษาความปลอดภัย Open Banking LiveCast ของเรา ดูการบันทึกแบบเต็มด้านล่าง:
Open Banking Security คืออะไร?
เป็นเวลากว่าสิบปีแล้วที่โครงการ Open Bank เสนอรูปแบบการธนาคารแบบเปิด และเป็นเวลากว่าห้าปีแล้วที่กฎหมาย PSD2 ถูกนำมาใช้ในสหภาพยุโรป ความคิดริเริ่มเหล่านี้เสนอให้ธนาคารใช้อินเทอร์เฟซแบบเปิดสำหรับผู้ให้บริการบุคคลที่สาม (TPP) เพื่อรวมเข้าด้วยกัน API การธนาคารเหล่านี้ช่วยให้ TPP ที่มีการควบคุมอย่างเข้มงวดในการเข้าถึงบัญชีของลูกค้า เรียกข้อมูล เริ่มการชำระเงิน และดำเนินการอื่นๆ เพื่อปรับปรุงประสบการณ์ของลูกค้าที่เกี่ยวข้องกับการเงินแบบเปิด
ทว่าการขัดขวางเส้นทางการธนาคารออนไลน์ด้วยการแนะนำบุคคลที่สามเข้ามารวมกันทำให้เกิดความเสี่ยงโดยธรรมชาติ ไม่ต้องพูดถึงภัยคุกคามทางไซเบอร์ที่เพิ่มขึ้นและการละเมิดที่เกี่ยวข้องกับข้อมูลดิจิทัลที่ละเอียดอ่อน ดังนั้น มาตรฐานความปลอดภัยธนาคารแบบเปิดจึงเกิดขึ้นเพื่อปกป้องข้อมูลส่วนบุคคลที่ระบุตัวบุคคลได้ (PII) ที่ละเอียดอ่อน ตรวจสอบสิทธิ์ TPP และเสนอวิธีการแบ่งปันการอนุญาตระหว่างเครือข่ายบริการทางการเงินใหม่ ทั้งหมดนี้ทำได้โดยไม่สูญเสียประสบการณ์ของผู้ใช้ปลายทาง เพื่อให้การธนาคารแบบเปิดประสบความสำเร็จ เรา “จำเป็นต้องทำให้แน่ใจว่า API นั้นปลอดภัย” Chris Wood กล่าว ข้อมูลลูกค้าจะต้องปลอดภัยและเข้าถึงได้โดย TPP ที่ได้รับอนุญาตเท่านั้น
ห้ามาตรฐานความปลอดภัยธนาคารแบบเปิด
แล้วเราจะรักษาความปลอดภัยกระบวนทัศน์ใหม่นี้ได้อย่างไร? ตามที่ Wood อธิบาย มาตรฐาน API ต่างๆ มากมายกำลังถูกสร้างขึ้นในส่วนต่างๆ ของโลก เพื่อให้แน่ใจว่าการธนาคารแบบเปิดสามารถพัฒนาและคงไว้ซึ่งความปลอดภัย Wood เสนอให้ใช้มาตรฐานเหล่านี้เพื่อควบคุมการขนส่ง การรับรองความถูกต้อง การอนุญาต และการมอบหมายข้อมูลประจำตัว มาตรฐานชั้นนำ ได้แก่ HTTPS, mTLS, OAuth 2.0, OpenID Connect, FAPI และอื่นๆ ด้านล่างนี้ เราจะให้ภาพรวมระดับสูงของมาตรฐานเหล่านี้ และดูว่ามาตรฐานเหล่านี้เหมาะสมอย่างไรภายในปริศนาความปลอดภัยแบบเปิดของธนาคาร
1. mTLS
ก่อนอื่น Wood เน้นย้ำถึงความสำคัญของMutual Authentication over Transport Layer Security (mTLS) ซึ่งทั้งไคลเอนต์และเซิร์ฟเวอร์แสดงและตรวจสอบใบรับรอง การตรวจสอบความถูกต้องของใบรับรองเซิร์ฟเวอร์ด้วยการตรวจสอบสิทธิ์แบบสองทางนั้นถูกทดลองและเป็นจริง และค่อนข้างแพร่หลาย หมายความว่าพร้อมสำหรับตลาดที่จะนำไปใช้ ซึ่งจะช่วยหลีกเลี่ยงการโจมตีแบบคนกลาง เล่นซ้ำ และการปลอมแปลง
2. eIDAS
แต่มันไม่ได้หยุดเพียงแค่นั้น มีเลเยอร์เพิ่มเติมเหนือ mTLS ให้พิจารณา eIDAS (บริการระบุตัวตน รับรองความถูกต้อง และเชื่อถือทางอิเล็กทรอนิกส์) เป็นมาตรฐานของสหภาพยุโรปสำหรับการระบุตัวตนทางอิเล็กทรอนิกส์ ซึ่งPSD2 กำหนดให้ผู้ให้บริการความน่าเชื่อถือคุณภาพ (QTSP) นำมาใช้ สิ่งนี้ระบุโดยใช้ ASN.1 ซึ่งเป็นรูปแบบข้อมูลเพื่อดำเนินการแอตทริบิวต์เพิ่มเติม
3. OAuth 2.0
OAuth 2.0 ค่อนข้างแพร่หลายและเป็นที่รู้จักกันดีในดินแดนของ API ผู้พิสูจน์ส่วนใหญ่ใช้ในรูปแบบใดรูปแบบหนึ่ง OAuth มอบอำนาจการรักษาความปลอดภัย ที่ไม่เหมือน ใคร ตัวอย่างเช่น ด้วย OAuth แอปที่ใช้ Twitter API ไม่จำเป็นต้องเห็นรหัสผ่านของผู้ใช้ OAuth ได้รับการสนับสนุนในโครงการธนาคาร แบบเปิด เช่น Berlin Group และ STET
สถาบันธนาคารเปิดอื่น ๆ ยังไม่ได้ใช้ OAuth Wood กล่าวว่ามี “วิธีปรับปรุง OAuth ได้อย่างแน่นอน… การอัปเกรด OAuth เพื่อเพิ่มความปลอดภัยเป็นพิเศษและฟีเจอร์ต่างๆ ถือว่ามีความสำคัญ” เขาสนับสนุนการใช้ OAuth 2.0 และ mTLS ร่วมกัน นี่คือที่มาของ OpenID Connect
4. OpenID Connect
OpenID Connect อยู่บน OAuth เพื่อให้หลักฐานการรับรองความถูกต้องเพิ่มเติมด้วยโทเค็น ID ข้อมูลจำเพาะอธิบายว่าเป็น “เลเยอร์ข้อมูลประจำตัวอย่างง่ายที่ด้านบนของโปรโตคอล OAuth 2.0” ในรูปแบบของ JSON Web Token (JWT) โทเค็นนี้ระบุว่าผู้ใช้ได้ตรวจสอบสิทธิ์และนำเสนอคุณสมบัติเพิ่มเติมมากมายเพื่อขยายความสามารถ
5. FAPI
API ระดับการเงิน (FAPI) คือโปรไฟล์ OpenID Foundation ที่อยู่บน OpenID Connect ซึ่งให้ความปลอดภัยเป็นพิเศษสำหรับองค์กรทางการเงิน มาตรฐานนี้มีคุณลักษณะด้านความปลอดภัยเพิ่มเติมที่เซิร์ฟเวอร์การอนุญาต ซึ่งทำให้พฤติกรรมรัดกุมยิ่งขึ้นโดยแบ่งกลุ่มการอนุญาต TPP FAPI ถูกจัดเป็นสี่ร่าง: โปรไฟล์ความปลอดภัย API แบบอ่านอย่างเดียว, โปรไฟล์ความปลอดภัย API แบบอ่านและเขียน, โหมดตอบกลับการอนุญาตที่ปลอดภัยของ JWT สำหรับ OAuth 2.0 (JARM) และการตรวจสอบสิทธิ์ Backchannel ที่เริ่มต้นโดยไคลเอนต์ (CIBA) ซึ่งให้วิธีการใหม่ ของการขอการรับรองความถูกต้องของผู้ใช้ Wood มองว่า FAPI เป็น “โครงสร้างที่สำคัญสำหรับการเติบโตในอนาคตของการธนาคารแบบเปิด”
การดำเนินการรักษาความปลอดภัยแบบเปิดของธนาคาร
ตอนนี้เรามีการแนะนำอย่างกว้างๆ เกี่ยวกับมาตรฐานความปลอดภัยแบบเปิดแล้ว การใช้งานธนาคารแบบเปิดที่ปลอดภัยมีหน้าตาเป็นอย่างไร? ปรากฎว่า เทคนิคเดียวกันสำหรับการรักษาความปลอดภัย API ส่วนใหญ่นำไปใช้กับการรักษาความปลอดภัยสถาปัตยกรรมธนาคารแบบเปิด Daniel Lindau สถาปนิกโซลูชันของ Curity กล่าว ลินเดาเดินผ่านขั้นตอนการใช้งานตัวอย่างเพื่อให้เกิดความปลอดภัยและการปฏิบัติตามข้อกำหนด ทางการเงิน
ขั้นตอนการดำเนินการ
Lindau อธิบายผู้เล่นหลักสี่รายภายในการตั้งค่าความปลอดภัยแบบเปิดของธนาคาร: บุคคลที่สาม บริการโทเค็นของธนาคาร API ของ Open Banking และที่สำคัญคือ เกตเวย์ API ในการสร้างคีย์หรือใบรับรองสำหรับบุคคลที่สามเพื่อเรียกใช้ API ลินเดาได้ดำเนินการตามขั้นตอนตัวอย่าง:
- เราจะถือว่าบุคคลที่สามได้ลงทะเบียนแล้ว ในการเริ่มต้น พวกเขาต้องร้องขอการเข้าถึงบัญชีผู้ใช้ ซึ่งน่าจะผ่าน OAuth Code Flow
- จากนั้นบริการโทเค็นจะตรวจสอบสิทธิ์ผู้ใช้ เป็นส่วนหนึ่งของมาตรฐานธนาคารแบบเปิด บริการโทเค็นต้องรองรับการตรวจสอบสิทธิ์แบบหลายปัจจัย
- ตอนนี้บริการโทเค็นจะถามผู้ใช้ว่าพวกเขาอนุญาตให้บุคคลที่สามเข้าถึงข้อมูลของพวกเขาหรือไม่ ซึ่งอาจเกี่ยวข้องกับป๊อปอัป UI ของหน้าเว็บ หรือแอปรับรองความถูกต้อง ไม่ว่า PSD2 จะต้องได้รับความยินยอมที่ลงนามด้วยการเข้ารหัส
- ถัดไป บริการโทเค็นจะออกโทเค็นให้กับบุคคลที่สามเพื่อพิสูจน์ว่าได้รับความยินยอม Lindau แนะนำให้เปลี่ยนสิ่งนี้เป็น Sender-Constrained Token ดังนั้นเฉพาะผู้ที่ถือโทเค็นเท่านั้นที่สามารถใช้ได้ ดังนั้นจึงช่วยเพิ่มความปลอดภัย
- ถัดไป บุคคลที่สามส่งโทเค็นไปยัง API Gateway เนื่องจากเป็นโทเค็นที่จำกัดผู้ส่ง จึงต้องใช้ mTLS
- จากนั้น API Gateway จะตรวจสอบความถูกต้องของโทเค็น พิจารณาด้วยบริการโทเค็นของธนาคาร และรับโทเค็นมูลค่า ซึ่งเป็น JWT ซึ่งช่วยให้ API Gateway บังคับใช้ผู้ส่งและจัดเตรียมขอบเขตการควบคุมการเข้าถึงแบบหยาบสำหรับนโยบายเฉพาะ
- JWT นี้ถูกส่งไปยัง APIs ซึ่งมีข้อมูลและอ้างว่าจำเป็นต้องให้สิทธิ์คำขอ จากนั้นการอนุญาต API จะใช้การตัดสินใจเข้าถึงอย่างละเอียดเพื่อยอมรับคำขอ
จากข้อมูลของ Lindau โฟลว์ข้างต้นแสดงให้เห็นถึงกระบวนการที่ปลอดภัยเพื่อป้องกันไม่ให้ข้อมูลที่ละเอียดอ่อนเข้าถึงโลกภายนอก กุญแจสำคัญในที่นี้คือการใช้โปรโตคอลแบบเปิดเพื่อบังคับใช้การเข้าถึงที่จำกัดของผู้ส่ง ซึ่งได้รับการยืนยันภายใน JWT ตลอดกระบวนการทั้งหมด สิ่งนี้ทำให้มั่นใจได้ถึงการยืนยันโดยตรงจากผู้ใช้ตั้งแต่ต้นทางถึงปลายทาง
ในการเปิดใช้งานการตั้งค่าบริษัท Lindau เน้นย้ำในด้านอื่นๆ อีกสองสามอย่าง: การลงทะเบียน TPP เช่นเดียวกับการลงทะเบียนลูกค้าแบบไดนามิก (RFC 7591) และการจัดการการลงทะเบียนลูกค้าแบบไดนามิก (RFC 7592) รวมถึงการตรวจสอบลูกค้าที่แข็งแกร่ง นอกจากนี้ เขายังเน้นย้ำถึงประโยชน์ของการใช้Hypermedia API สำหรับการตรวจสอบสิทธิ์ซึ่งเป็นแนวคิดที่ Curity กำลังผลักดันให้เป็นมาตรฐาน การใช้ API การตรวจสอบสิทธิ์ไฮเปอร์มีเดียจะทำให้เซิร์ฟเวอร์สามารถขับเคลื่อนโฟลว์การตรวจสอบสิทธิ์ทั้งหมดและรับลิงก์ไฮเปอร์มีเดียที่เน้นความสามารถเพิ่มเติม
มาตรฐานความปลอดภัยธนาคารแบบเปิด: มาตรฐานในปัจจุบันและอนาคต
การธนาคารแบบเปิดมีความสำคัญเพิ่มขึ้นในสหภาพยุโรปและแพร่กระจายไปยังตลาดโลกอื่นๆ การเปิดการเข้าถึง API ของธนาคารแก่บุคคลที่สามสามารถช่วยให้เกิดนวัตกรรมที่ช่วยประหยัดเวลาได้หลายอย่าง เช่น การขอสินเชื่อที่ง่ายขึ้น การเริ่มต้นการชำระเงินจากภายนอก หรือการรวมบัญชีที่ราบรื่นยิ่งขึ้น
ในการสร้างการดำเนินการธนาคารแบบเปิดที่ปลอดภัย Lindau ได้กล่าวถึงข้อกังวลที่สำคัญบางประการ:
- ใช้การลงทะเบียนไคลเอ็นต์แบบไดนามิกสำหรับ TPPS ซึ่งจะช่วยรวบรวมการตั้งค่าไคลเอ็นต์
- ใช้โทเค็นที่จำกัดผู้ส่งเสมอ — ไม่จำเป็นต้องใช้โทเค็นสำหรับผู้ถือ เมื่อคุณมีคีย์ที่เชื่อถือได้กับลูกค้าของคุณ
- รวมศูนย์รับรองความถูกต้องและใช้วิธีการหลายปัจจัย
- ใช้การตัดสินใจในการควบคุมการเข้าถึงแบบหลายชั้น โดยมีความละเอียดในเกตเวย์แบบหยาบและแบบละเอียดสำหรับ API
- สุดท้ายนี้ แดเนียล แนะนำให้ปรึกษามาตรฐาน !
ในประเด็นสุดท้ายนั้น มาตรฐานจะต้องพัฒนาขึ้น ในแง่ของการนำมาตรฐานไปใช้ในอนาคต Wood เล็งเห็นถึงการใช้การโต้ตอบ CIBA หรือ “สไตล์ CIBA” ที่เพิ่มขึ้น และเพิ่มการใช้มาตรฐานไบโอเมตริกซ์ เช่น FIDO2 นอกจากนี้ เขายังคาดว่าการจัดการการเข้าถึงในระดับนโยบายจะกลายเป็นเรื่องปกติมากขึ้น ควบคู่ไปกับการปรับปรุงประสบการณ์การธนาคารบนมือถือแบบเนทีฟ
ทั้งนี้บริษัทเคแอนด์โอ จึงได้มุ่งเน้นการจัดการแก้ไขปัญหา จัดการเอกสาร ด้านเอกสารขององค์กรมาอย่างยาวนาน และ ให้ความสำคัญกับด้านงานเอกสาร ต่อลูกค้าเป็นอย่างดี จนถึงปัจจุบันก็ได้ความยอมรับจากองค์กร ขนาดใหญ่ ขนาดกลาง และขนาดเล็กมากมาย จึงใคร่ขออาสาดูและปัญหาด้านเอกสารให้กับองค์กรของท่านอย่างสุดความสามารถ เพราะเราเป็นหนึ่งในธุรกิจ ระบบจัดเก็บเอกสาร ที่ท่านไว้ใจได้
สอบถามได้สบายใจทั้ง เรื่องค่าบริการ ราคา และ งบประมาณ เพราะเป็นราคาที่สุด คุ้มที่สุด
เรามีแอดมินคอยคอบคำถาม 24 ชั้วโมงที่ Line OA ให้คำปรึกษาด้านวางระบบจัดการเอกสารอิเล็กทรอนิกส์ EDMS โดยทีมงานผู้เชี่ยวชาญจาก K&O
ที่มีประสบการณ์มากว่า 15 ปี รวมถึงซอฟต์แวร์ระดับโลก ติดต่อ 0 2 – 8 6 0 – 6 6 5 9 หรือ E m a i l : c s @ k o . i n . t h
หากท่านมีความสนใจ บทความ หรือ Technology สามารถติดต่อได้ตามเบอร์ที่ให้ไว้ด้านล่างนี้
Tel.086-594-5494
Tel.095-919-6699
