โดยสรุป
ทีมฟินเทคต้องเผชิญกับข้อกำหนดด้านเครื่องมือ API ที่บริษัทซอฟต์แวร์ส่วนใหญ่ไม่มี: ข้อพิจารณาขอบเขตของ PCI DSS, กฎการจัดเก็บข้อมูลในประเทศ, บันทึกการตรวจสอบสำหรับหน่วยงานกำกับดูแลทางการเงิน, และปัญหาของข้อมูลประจำตัว API สำหรับระบบการชำระเงินที่จัดเก็บอยู่ในเครื่องมือที่โฮสต์บนคลาวด์ คู่มือนี้จะประเมินเครื่องมือทดสอบ API โดยพิจารณาจากมุมมองการปฏิบัติตามข้อกำหนดของฟินเทค โดยให้ความสำคัญเป็นพิเศษกับวิธีที่แต่ละเครื่องมือจัดการกับข้อมูลที่ละเอียดอ่อน
บทนำ
การสร้าง API สำหรับการชำระเงิน, การผสานรวมระบบธนาคารแบบเปิด (open banking), หรือบริการข้อมูลทางการเงิน หมายความว่าขั้นตอนการทดสอบ API ของคุณเกี่ยวข้องกับโครงสร้างพื้นฐานที่ละเอียดอ่อน ข้อมูลประจำตัวที่นักพัฒนาของคุณใช้ทดสอบกับสภาพแวดล้อมจำลองอาจเข้าถึงระบบการเงินจริงได้ รายละเอียด API ของคุณอาจมีข้อมูลเกี่ยวกับสถาปัตยกรรมความปลอดภัยของคุณที่คู่แข่งหรือผู้โจมตีอาจพบว่ามีคุณค่า
เครื่องมือทดสอบ API ส่วนใหญ่ได้รับการออกแบบมาสำหรับการพัฒนาซอฟต์แวร์ทั่วไป โดยมีการโฮสต์บนคลาวด์, ซิงค์ข้อมูลประจำตัวไปยังเซิร์ฟเวอร์โดยค่าเริ่มต้น และไม่แยกความแตกต่างระหว่างนักพัฒนาที่ทดสอบ API ของแอปทำอาหารกับนักพัฒนาที่ทดสอบ API ประมวลผลการชำระเงิน
ทีมฟินเทคจำเป็นต้องตั้งคำถามที่ยากขึ้น ข้อมูลประจำตัว API ของฉันจัดเก็บอยู่ที่ใดเมื่ออยู่ในเครื่องมือนี้? จะเกิดอะไรขึ้นหากผู้ให้บริการถูกละเมิดข้อมูล? ฉันสามารถปฏิบัติตามข้อกำหนดขอบเขต PCI DSS ของฉันได้หรือไม่? ฉันสามารถสร้างบันทึกการตรวจสอบเพื่อการตรวจสอบจากหน่วยงานกำกับดูแลได้หรือไม่?
บทความนี้จะตอบคำถามเหล่านั้นสำหรับเครื่องมือทดสอบ API ที่ได้รับการประเมินบ่อยที่สุด
ข้อกำหนดการปฏิบัติตามข้อกำหนดที่มีผลต่อการเลือกใช้เครื่องมือ API
PCI DSS และการจัดการข้อมูลประจำตัว
PCI DSS (Payment Card Industry Data Security Standard) มีผลบังคับใช้หาก API ของคุณเกี่ยวข้องกับข้อมูลผู้ถือบัตร และข้อกำหนดของมันมีผลต่อการเลือกใช้เครื่องมือของคุณ โดยเฉพาะ:
- ข้อกำหนด 7 (การควบคุมการเข้าถึง): ระบบที่สามารถเข้าถึงสภาพแวดล้อมข้อมูลผู้ถือบัตรจะต้องมีการควบคุมการเข้าถึง หากเครื่องมือทดสอบ API ของคุณจัดเก็บข้อมูลประจำตัวที่สามารถเข้าถึงระบบการชำระเงินได้ อาจอยู่ในขอบเขตของ PCI
- ข้อกำหนด 10 (การบันทึกและการตรวจสอบ): การเข้าถึงทรัพยากรเครือข่ายและข้อมูลผู้ถือบัตรทั้งหมดจะต้องถูกบันทึกและสามารถตรวจสอบได้
- ข้อกำหนด 12.5 (ผู้ให้บริการภายนอก): คุณต้องจัดทำรายการผู้ให้บริการภายนอกและข้อมูลผู้ถือบัตรที่พวกเขาจัดเก็บ, ประมวลผล หรือส่งผ่าน
เครื่องมือ API ที่โฮสต์บนคลาวด์ที่ซิงค์ตัวแปรสภาพแวดล้อม (รวมถึงคีย์ API และโทเค็นการตรวจสอบสิทธิ์) ไปยังเซิร์ฟเวอร์ของตน อาจถือเป็นผู้ให้บริการภายนอกที่อยู่ในขอบเขตของ PCI ซึ่งจะกระตุ้นให้เกิดข้อกำหนดในการประเมิน, ข้อตกลงที่เป็นลายลักษณ์อักษร และการตรวจสอบวิเคราะห์สถานะอย่างต่อเนื่อง
วิธีแก้ปัญหาที่สะอาด: ใช้เครื่องมือ API ที่จัดเก็บข้อมูลประจำตัวภายในเครื่องและไม่ซิงค์ค่าที่ละเอียดอ่อนไปยังคลาวด์ คุณสมบัติ local environment variable ของ Apidog ทำเช่นนี้ – ตัวแปรที่ละเอียดอ่อนจะถูกทำเครื่องหมายและจัดเก็บเฉพาะบนอุปกรณ์ภายในเครื่องเท่านั้น
การจัดเก็บข้อมูลในประเทศและข้อจำกัดทางภูมิศาสตร์
บริษัทฟินเทคที่ดำเนินงานใน EU, UK หรือเขตอำนาจศาลที่มีการควบคุมอื่น ๆ อาจมีข้อกำหนดการจัดเก็บข้อมูลในประเทศที่จำกัดว่าข้อมูลสามารถจัดเก็บได้ที่ใด สำหรับฟินเทคที่มีฐานในสหรัฐฯ ซึ่งมีการดำเนินงานใน EU รายละเอียด API และข้อมูลทดสอบของคุณอาจต้องอยู่ใน EU
เครื่องมือ Cloud SaaS โดยทั่วไปไม่เสนอการจัดเก็บข้อมูลในภูมิภาคสำหรับแผนมาตรฐาน แผน Enterprise บางครั้งก็มี การปรับใช้แบบ On-premises หรือ VPC ช่วยขจัดปัญหานี้ได้อย่างสมบูรณ์ – ข้อมูลจะยังคงอยู่ ณ จุดที่คุณปรับใช้
บันทึกการตรวจสอบสำหรับหน่วยงานกำกับดูแลทางการเงิน
หน่วยงานกำกับดูแลบริการทางการเงิน – SEC, FCA, FINRA, OCC ขึ้นอยู่กับเขตอำนาจศาลและประเภทผลิตภัณฑ์ของคุณ – คาดหวังให้องค์กรสามารถแสดงได้ว่าใครเข้าถึงระบบใดและเมื่อใด ในบริบทของเครื่องมือ API นั่นหมายถึง:
- ใครเข้าถึงสภาพแวดล้อมการทดสอบสำหรับ API ที่สำคัญ
- ใครแก้ไขรายละเอียด API หรือการกำหนดค่าการทดสอบ
- เมื่อการทดสอบอัตโนมัติทำงานกับสภาพแวดล้อมที่เฉพาะเจาะจง
- ไม่ว่าการทดสอบจะให้ผลลัพธ์ที่สอดคล้องกับพฤติกรรมที่คาดไว้หรือไม่
เครื่องมือ API ที่มีการบันทึกการตรวจสอบสามารถให้หลักฐานนี้ได้ หากไม่มี คุณจะต้องรวบรวมหลักฐานจากบันทึกที่กระจัดกระจายอยู่ในหลายระบบ
ความเข้ากันได้กับการทดสอบการเจาะระบบ (Penetration Testing)
บริษัทฟินเทคโดยทั่วไปจะมีการทดสอบการเจาะระบบเป็นประจำทุกปีหรือกึ่งประจำปี ซึ่งมักถูกกำหนดโดย PCI DSS, SOC 2 หรือข้อตกลงความปลอดภัยของลูกค้า เครื่องมือ API ของคุณจำเป็นต้องรองรับผู้ทดสอบการเจาะระบบที่ต้องการรันสถานการณ์การทดสอบกับ API ของคุณ
หากเครื่องมือทดสอบ API ของคุณต้องการการตรวจสอบสิทธิ์บนคลาวด์ และผู้ทดสอบการเจาะระบบไม่สามารถเข้าถึงอินสแตนซ์คลาวด์ของคุณได้ นั่นคือปัญหาขั้นตอนการทำงาน เครื่องมือที่โฮสต์เอง (self-hosted) หรือติดตั้งภายในเครื่อง (locally installable) สามารถหลีกเลี่ยงปัญหานี้ได้
การประเมินเครื่องมือ: Apidog, Postman และ Insomnia
Apidog
Apidog ได้รับการออกแบบด้วยปรัชญา local-first พฤติกรรมเริ่มต้นคือการจัดเก็บข้อมูลภายในเครื่อง การซิงค์ไปยังคลาวด์ของ Apidog เป็นแบบเลือกทำ สำหรับตัวแปรสภาพแวดล้อมโดยเฉพาะ คุณสามารถทำเครื่องหมายตัวแปรแต่ละรายการว่าเป็น “local” – ซึ่งจะมีอยู่เฉพาะในเครื่องของนักพัฒนานั้นๆ และจะไม่มีการส่งไปยังเซิร์ฟเวอร์ของ Apidog เลย แม้ว่าพื้นที่ทำงานจะถูกซิงค์ก็ตาม
นี่คือค่าเริ่มต้นที่ถูกต้องสำหรับฟินเทค คีย์ API ของ Stripe ของคุณ, รหัสลับลูกค้าของ Plaid, โทเค็นการตรวจสอบสิทธิ์ของผู้ประมวลผลการชำระเงินของคุณ – จะไม่มีสิ่งใดออกจากเครื่องของนักพัฒนาเลยหากคุณใช้ตัวแปรแบบ local
สำหรับทีมที่ต้องการการควบคุมข้อมูลอย่างสมบูรณ์ Apidog Enterprise มีการปรับใช้แบบ self-hosted คุณสามารถเรียกใช้ Apidog บนโครงสร้างพื้นฐานของคุณเอง ไม่มีการเชื่อมต่อกับคลาวด์ของ Apidog รายละเอียด, การทดสอบ, ข้อมูลประจำตัว (แม้แต่ข้อมูลที่ไม่ใช่ local) และบันทึกการตรวจสอบทั้งหมดจะยังคงอยู่ภายในขอบเขตของคุณ
การบันทึกการตรวจสอบมีให้ในแผน Enterprise ซึ่งครอบคลุมการเปลี่ยนแปลงรายละเอียด API, ประวัติการทดสอบ, เหตุการณ์การเข้าถึงของผู้ใช้ และการแก้ไขพื้นที่ทำงาน
Apidog ไม่มีการรับรอง PCI DSS โดยเฉพาะ แต่สถาปัตยกรรมของมัน – การจัดเก็บข้อมูลประจำตัวภายในเครื่อง, ตัวเลือก self-hosted, การบันทึกการตรวจสอบ – สอดคล้องกับข้อกำหนดของ PCI ในลักษณะที่เครื่องมือคลาวด์ทั่วไปไม่มี
Postman
Postman เป็นที่นิยมใช้กันอย่างแพร่หลายในฟินเทค แต่สถาปัตยกรรมเริ่มต้นของมันทำให้เกิดปัญหาด้านการปฏิบัติตามข้อกำหนด โดยค่าเริ่มต้น Postman จะซิงค์ทุกอย่าง – คอลเลกชัน, สภาพแวดล้อม และค่าตัวแปรสภาพแวดล้อม – ไปยังคลาวด์ของ Postman ซึ่งรวมถึงข้อมูลประจำตัวที่ละเอียดอ่อนด้วย เว้นแต่คุณจะระมัดระวัง
Postman มีวิธีทำเครื่องหมายตัวแปรสภาพแวดล้อมเป็นประเภท “secret” ซึ่งจะซ่อนไม่ให้มองเห็นใน UI แต่ยังคงซิงค์ไปยังเซิร์ฟเวอร์ของ Postman ในรูปแบบที่เข้ารหัส สำหรับการตีความ PCI ที่เข้มงวด การที่ข้อมูลประจำตัวอยู่บนเซิร์ฟเวอร์ของบุคคลที่สาม – แม้ว่าจะเข้ารหัสแล้ว – อาจเป็นปัญหาได้
Postman ได้รับการรับรอง SOC 2 Type II ซึ่งช่วยแก้ไขข้อกังวลบางประการด้านการปฏิบัติตามข้อกำหนด พวกเขายังเสนอแผน Enterprise ที่มีตัวเลือกการจัดเก็บข้อมูลในประเทศ อย่างไรก็ตาม สิ่งเหล่านี้ต้องใช้สัญญาในระดับองค์กรและไม่สามารถใช้งานได้สำหรับทีมที่ใช้แผนมาตรฐานหรือแผนโปร
ตัวเลือก on-prem ของ Postman (Postman Enterprise On-Premises) มีอยู่จริง แต่ในอดีตมักได้รับการอัปเดตคุณสมบัติช้ากว่าเวอร์ชันคลาวด์ หากการโฮสต์เองเป็นข้อกำหนดที่เข้มงวด โปรดตรวจสอบว่าเวอร์ชัน on-prem ตรงตามความต้องการคุณสมบัติของคุณก่อนที่จะตัดสินใจ
Insomnia
Insomnia (ที่ Kong เข้าซื้อกิจการ) เป็น REST client แบบ local-first โดยค่าเริ่มต้นจะจัดเก็บทุกอย่างในเครื่อง ซึ่งทำให้เป็นที่น่าสนใจสำหรับทีมที่คำนึงถึงการปฏิบัติตามข้อกำหนด Insomnia Sync (คุณสมบัติการซิงค์บนคลาวด์) เป็นแบบเลือกทำ
ข้อจำกัดของ Insomnia คือเป็นเครื่องมือสำหรับการทดสอบและดีบักเป็นหลัก ไม่มีการรองรับที่แข็งแกร่งสำหรับการออกแบบ API, ชุดการทดสอบอัตโนมัติ, การรวม CI/CD หรือเอกสาร API สำหรับทีมฟินเทคที่ต้องการมากกว่าการทดสอบด้วยตนเอง Insomnia มักจะเป็นเพียงเครื่องมือหนึ่งในชุดเครื่องมือที่ใหญ่กว่า แทนที่จะเป็นโซลูชันที่สมบูรณ์
Insomnia ไม่มีคุณสมบัติการทำงานร่วมกันเป็นทีม, RBAC หรือการบันทึกการตรวจสอบที่ทีมฟินเทคระดับองค์กรต้องการ เป็นเครื่องมือที่ดีสำหรับนักพัฒนาแต่ละคนแต่ไม่เหมาะสำหรับข้อกำหนดการกำกับดูแลของทีม
การเปรียบเทียบสำหรับทีมฟินเทค
| เกณฑ์ | Apidog | Postman | Insomnia |
|---|---|---|---|
| การจัดเก็บข้อมูลประจำตัวภายในเครื่อง | มี (เลือกทำต่อตัวแปร) | ซิงค์แบบเข้ารหัสไปยังคลาวด์ | มี (ค่าเริ่มต้น) |
| ตัวเลือกโฮสต์เอง / on-prem | มี (Enterprise) | มี (Enterprise, มีข้อจำกัด) | ไม่มี |
| บันทึกการตรวจสอบ | มี (Enterprise) | มี (Enterprise) | ไม่มี |
| การรับรอง SOC 2 | ตรวจสอบกับผู้ให้บริการ | มี (Type II) | ตรวจสอบกับผู้ให้บริการ |
| วงจรชีวิตสมบูรณ์ (ออกแบบ+ทดสอบ+จำลอง+เอกสาร) | มี | บางส่วน | ไม่มี |
| การผสานรวม CI/CD | มี | มี | มีข้อจำกัด |
| ตัวเลือกการจัดเก็บข้อมูลในประเทศ | On-prem แก้ปัญหาได้ | เฉพาะ Enterprise | ไม่มี |
Apidog จัดการกับการปฏิบัติตามข้อกำหนดของฟินเทคโดยเฉพาะได้อย่างไร
ตัวแปรสภาพแวดล้อมภายในเครื่องในทางปฏิบัติ
เมื่อนักพัฒนาสร้างสภาพแวดล้อมการทดสอบใน Apidog สำหรับ API การชำระเงิน พวกเขาสามารถทำเครื่องหมายคีย์ API และโทเค็นการตรวจสอบสิทธิ์ของพวกเขาเป็นตัวแปร local ได้ ตัวแปรเหล่านี้จะมองเห็นได้เฉพาะบนเครื่องของนักพัฒนารายนั้นเท่านั้น สมาชิกทีมคนอื่นๆ ที่เชื่อมต่อกับพื้นที่ทำงานเดียวกันจะเห็นช่องว่างสำหรับตัวแปร – ซึ่งพวกเขาจะต้องป้อนค่าของตนเอง
รูปแบบนี้สะท้อนถึงวิธีที่ทีมรักษาความปลอดภัยฟินเทคต้องการให้จัดการข้อมูลประจำตัว: นักพัฒนาแต่ละคนรับผิดชอบข้อมูลประจำตัวของตนเอง ซึ่งไม่ได้จัดเก็บแบบรวมศูนย์ในลักษณะที่อาจเปิดเผยได้ในการละเมิดข้อมูลครั้งเดียว
การปรับใช้แบบโฮสต์เองเพื่อการควบคุมที่สมบูรณ์
สำหรับทีมฟินเทคที่มีข้อกำหนดการจัดเก็บข้อมูลในประเทศอย่างเข้มงวด การปรับใช้แบบ self-hosted ของ Apidog Enterprise หมายความว่าแพลตฟอร์มทั้งหมด – รายละเอียด API, การกำหนดค่าการทดสอบ, ผลการทดสอบ และบันทึกการเข้าถึงของผู้ใช้ – จะอยู่บนโครงสร้างพื้นฐานของคุณ หากคุณกำลังปรับใช้ภายในสภาพแวดล้อม AWS ที่เป็นไปตาม PCI ข้อมูลของ Apidog จะรับช่วงการควบคุมที่คุณได้กำหนดไว้แล้ว
การปรับใช้เป็นแบบคอนเทนเนอร์ (Docker/Kubernetes) ซึ่งเข้ากับขั้นตอน DevSecOps มาตรฐาน ทีมรักษาความปลอดภัยของคุณสามารถสแกนคอนเทนเนอร์, ใช้กำหนดนโยบายเครือข่าย และตรวจสอบการส่งข้อมูลออกได้เช่นเดียวกับบริการภายในอื่นๆ
การบันทึกการตรวจสอบสำหรับหลักฐานทางกฎระเบียบ
Apidog Enterprise เก็บบันทึกการตรวจสอบสำหรับเหตุการณ์ในพื้นที่ทำงาน: ใครสร้างหรือแก้ไขรายละเอียด API, เมื่อชุดการทดสอบทำงาน, ใครเปลี่ยนสิทธิ์การเข้าถึง บันทึกเหล่านี้สามารถส่งออกและนำเข้าสู่ SIEM ของคุณเพื่อการตรวจสอบความปลอดภัยแบบรวมศูนย์
สำหรับการสอบสวนจากหน่วยงานกำกับดูแล หรือการประเมินโดย PCI QSA คุณสามารถจัดเตรียมหลักฐานเฉพาะว่าใครเข้าถึงการกำหนดค่าการทดสอบสำหรับ API การชำระเงิน และเมื่อใดที่มีการแก้ไขการกำหนดค่าเหล่านั้น
รายการตรวจสอบเชิงปฏิบัติสำหรับการเลือกใช้เครื่องมือ API สำหรับฟินเทค
ก่อนตัดสินใจเลือกขั้นสุดท้าย:
- [ ] ตัวแปรสภาพแวดล้อม (คีย์ API, โทเค็น) อยู่ที่ใดจริง ๆ – บนเครื่องของนักพัฒนาหรือเซิร์ฟเวอร์ของผู้ให้บริการ?
- [ ] คุณสามารถขอคำอธิบายเป็นลายลักษณ์อักษรเกี่ยวกับแนวปฏิบัติในการจัดการข้อมูลของผู้ให้บริการที่เหมาะสมสำหรับการประเมินความเสี่ยงของผู้ให้บริการได้หรือไม่?
- [ ] เครื่องมือนี้มีตัวเลือกการปรับใช้แบบโฮสต์เองหรือไม่ หากข้อกำหนดการจัดเก็บข้อมูลในประเทศของคุณมีการเปลี่ยนแปลง?
- [ ] มีรูปแบบบันทึกการตรวจสอบใดบ้าง และสามารถส่งออกไปยัง SIEM ของคุณได้หรือไม่?
- [ ] ผู้ให้บริการได้ดำเนินการตรวจสอบ SOC 2 Type II เสร็จสิ้นแล้วหรือไม่? พวกเขาสามารถให้รายงานภายใต้ NDA ได้หรือไม่?
- [ ] ทีมทดสอบการเจาะระบบของคุณจำเป็นต้องทำงานกับเครื่องมือนี้หรือไม่ และพวกเขาสามารถเข้าถึงได้จากภายนอกเครือข่ายของคุณหรือไม่?
- [ ] จะเกิดอะไรขึ้นกับข้อมูลของคุณหากคุณยกเลิกการสมัครสมาชิก?
คำถามที่พบบ่อย
การใช้ Apidog ทำให้ผู้ให้บริการตกอยู่ในขอบเขต PCI DSS หรือไม่?คุณสมบัติ local variable ของ Apidog ได้รับการออกแบบมาโดยเฉพาะเพื่อให้ข้อมูลประจำตัวที่ละเอียดอ่อนไม่หลุดออกจากเครื่องของนักพัฒนา หากคุณใช้ตัวแปร local สำหรับข้อมูลประจำตัวที่เกี่ยวข้องกับการชำระเงินทั้งหมด โครงสร้างพื้นฐานคลาวด์ของ Apidog จะไม่ได้รับข้อมูลประจำตัวเหล่านั้น ซึ่งช่วยลดคำถามเรื่องขอบเขต สำหรับคำตอบที่ชัดเจน โปรดปรึกษากับ PCI QSA ที่สามารถประเมินการกำหนดค่าเฉพาะของคุณได้
Apidog สามารถปรับใช้ในสภาพแวดล้อม AWS ที่เป็นไปตาม PCI ได้หรือไม่?ได้ การปรับใช้แบบ self-hosted ของ Apidog Enterprise ใช้ Docker และ Kubernetes ซึ่งสามารถปรับใช้ภายใน AWS VPC โดยมีการใช้การควบคุมที่เป็นไปตาม PCI ในระดับโครงสร้างพื้นฐาน การควบคุม PCI ที่มีอยู่ของคุณ (การแบ่งส่วนเครือข่าย, การบันทึกการเข้าถึง, การเข้ารหัส) จะมีผลกับการปรับใช้ Apidog
ความเสี่ยงของการใช้เครื่องมือ API ที่โฮสต์บนคลาวด์สำหรับการพัฒนาฟินเทคคืออะไร?ความเสี่ยงหลักคือ: การเปิดเผยข้อมูลประจำตัวหากผู้ให้บริการถูกละเมิด, การขยายขอบเขต PCI ที่อาจเกิดขึ้นซึ่งต้องมีการประเมินผู้ให้บริการ และการไม่ปฏิบัติตามข้อกำหนดการจัดเก็บข้อมูลในประเทศ ความรุนแรงขึ้นอยู่กับว่าการทดสอบของคุณเกี่ยวข้องกับข้อมูลทางการเงินจริง หรือใช้ข้อมูลทดสอบที่ผ่านการทำความสะอาดและข้อมูลประจำตัวสำหรับ sandbox
Apidog มี Business Associate Agreement (BAA) ให้บริการหรือไม่? BAA มีความเกี่ยวข้องหลักๆ กับ HIPAA มากกว่ากรอบการทำงานด้านการปฏิบัติตามข้อกำหนดของฟินเทค สำหรับฟินเทค ข้อตกลงที่เกี่ยวข้องโดยทั่วไปคือ Data Processing Agreement (DPA) โปรดติดต่อทีม Apidog Enterprise สำหรับตัวเลือกข้อตกลงปัจจุบัน
ทีมฟินเทคควรจัดการข้อมูลทดสอบที่คล้ายกับข้อมูลทางการเงินจริงอย่างไร?ตามหลักการแล้ว ควรใช้เฉพาะข้อมูลทดสอบสังเคราะห์และข้อมูลประจำตัว sandbox ในเครื่องมือทดสอบ API ของคุณ โดยไม่คำนึงถึงเครื่องมือที่คุณเลือก หากไม่สามารถทำได้ ให้เลือกเครื่องมือที่มีการปรับใช้แบบ self-hosted เพื่อให้ข้อมูลยังคงอยู่ในสภาพแวดล้อมที่คุณควบคุม
Apidog สามารถรวมเข้ากับเครื่องมือสแกนความปลอดภัยที่ใช้ใน CI/CD pipelines ของฟินเทคได้หรือไม่? Apidog CLI runner สามารถรวมเข้ากับ CI pipelines ที่มีขั้นตอนการสแกนความปลอดภัยได้ ผลการทดสอบ API เป็นอิสระจากผลการสแกนความปลอดภัย สำหรับการทดสอบความปลอดภัย API แบบบูรณาการ ReadyAPI หรือเครื่องมือ DAST ที่สร้างขึ้นโดยเฉพาะอาจเป็นส่วนเสริมที่เหมาะสมกว่าสำหรับ Apidog ในการทดสอบฟังก์ชันการทำงาน
เครื่องมือ API ของฟินเทคเป็นการตัดสินใจด้านการปฏิบัติตามข้อกำหนดพอๆ กับการตัดสินใจด้านประสิทธิภาพของนักพัฒนา เครื่องมือที่เหมาะสมสำหรับสตาร์ทอัพแอปพลิเคชันสำหรับผู้บริโภคอาจไม่จำเป็นต้องเหมาะสมสำหรับบริษัทผู้ให้บริการชำระเงิน ประเมินโดยพิจารณาจากตำแหน่งที่ข้อมูลของคุณไปถึงจริง – ไม่ใช่แค่ที่ผู้ให้บริการบอกว่าไปถึง แต่คือที่ที่ข้อมูลไปถึงโดยค่าเริ่มต้น โดยการออกแบบ และในกรณีที่เลวร้ายที่สุด