ສະຫຼຸບ OWASP API Top 10 ແລະ 6 API Security Best Practices ຈາກ F5

ແອັບ​ພລິ​ເຄ​ຊັນ​ໃນ​ປັດຈຸບັນ​ຖືກ​ພັດທະນາ​ໃຫ້​ມີ​ຄວາມ​ຊັບ​ຊ້ອນ​ແລະ​ທັນ​ສະໄໝ​ຫຼາຍ​ຍິ່ງ​ຂຶ້ນ ທັງຍັງ​ສາມາດ​ເຊື່ອມ​ຕໍ່​ກັບ​ລະບົບ​ຕ່າງ​ໆ ເພື່ອ​ປະ​ສານ​ການ​ເຮັດ​ວຽກງານ​ໄດ້​ຢ່າງ​ສະ​ດວກ​ແລະ​ວ່ອງໄວ ສົ່ງ​ຜົນ​ໃຫ້ API ຖືກ​ໃຊ້​ງານ​ເປັນ​ຈຳນວນ​ຫລາຍ ບົດ​ຄວາມ​ນີ້ F5 ໄດ້​ອອກ​ມາ​ເປີດ​ເຜີຍ​ເຖິງ​ຄວາມ​ສ່ຽງ​ດ້ານ​ຄວາມຫມັ້ນຄົງ​ປອດໄ​ພ​ຂອງ API ຕາມ OWAP API Top 10 ແລະ​ແນວ​ທາງ​ປະຕິບັດ​ທີ່​ດີ​ທີ່ສຸດ​ໃນ​ການ​ປ້ອງ​ກັນ API ຈາກໄ​ພ​ຄຸກ​ຄາມ​ໄຊ​ເບີ

API ເຕີບໂຕ​ຢ່າງ​ກ້າວ​ກະ​ໂດດ ສ່ຽງ​ຖືກ​ແຮັກ​ເກ​ີ​ໂຈມ​ຕີ​ຫລາຍ​ຂຶ້ນ

ປະຕິເສດ​ບໍ່​ໄດ້​ວ່າ​ເກືອບ​ທຸກ​ອົງກອນ​ໃນ​ປັດຈຸບັນ​ຕ່າງ​ມຸ້ງ​ໜ້າ​ເຮັດ Digital Transformation ກັນ​ທັງ​ສິ້ນ ແອັບ​ພຣິ​ເຄ​ຊັນ​ຖືກ​ພັດທະນາ​ໃຫ້​ມີ​ຄວາມ​ທັນ​ສະໄໝ​ດ້ວຍ​ສ​ະຖາ​ປັດຕະຍະ​ກຳ​ແບບ Microservices ເຊິ່ງ​ແບ່ງ​ຟັງ​ຊັນ​ການ​ເຮັດ​ວຽກ​ອອກ​ເປັນ​ຫຼາຍ​ໆ ສ່ວນ ໃນ​ຂະນະ​ທີ່ Developer ກໍ​ແບ່ງ​ອອກ​ເປັນ​ຫຼາຍ​ທີມ​ຫລາຍ​ຂຶ້ນ ເພື່ອ​ໃຫ້​ອອກ​ຟີ​ເຈີແລະ​ຟັງ​ຊັນ​ການ​ໃຊ້​ງານ​ໃໝ່​ໆ ສູ່ຕະຫ​ລາດ​ໄດ້​ຢ່າງ​ວ່ອງໄວ ລວມ​ເຖິງ​ການ​ປັບ​ໄປ​ໃຊ້ Hybrid ແລະ Multi-cloud ຂອງ​ອົງກອນເຫຼົ່າ​ນີ້ ລ້ວນ​ເຊື່ອມ​ຕໍ່​ແລະ​ປະ​ສານ​ການ​ເຮັດ​ວຽກ​ຜ່ານ​ທາງ API ສົ່ງ​ຜົນ​ໃຫ້​ລະບົບ API ເຕີບໂຕ​ຢ່າງ​ກ້າວ​ກະ​ໂດດ

ຈາກ​ການ​ສຳຫຼວດ​ພົ​ບວ່າ​ຫລາຍກວ່າ 90% ຂອງ​ທຣາ​ຟ​ຟິກ​ເທິງ​ອິນ​ເຕີ​ເນັດ ຖືກ​ຈຳ​ແນກ​ເປັນ​ການ​ຮັບ​ສົ່ງ​ຂໍ້​ມູນ API (JSON/SML) ຈຶ່ງ​ເປັນ​ສາ​ເຫດ​ທີ່​ເຮັດໃຫ້​ອາດຊະຍາກອນ​ໄຊ​ເບີ​ເລີ່ມ​ຫາ​ຊ່ອງ​ໂຫວ່​ແລະ​ໂຈມ​ຕີ​ລະບົບ API ຫລາຍ​ຂຶ້ນ ການ​ຂາດ​ຄວາມ​ຕ​ະ​ໜັກ​ຮູ້​ແລະ​ການ​ປ້ອງ​ກັນ API ອາດ​ກໍ່​ໃຫ້​ເກີດ​ເຫດ Data Breach ຫລື​ຂໍ້​ມູນຮົ່ວ​ໄຫຼ​ສູ່​ສາທາລະນະ​ໄດ້ ໂດຍ​ສາ​ເຫດ​ອັນ​ດັບ​ໜຶ່ງ​ຂອງ​ການ​ເຈາະ​ລະບົບ API ຄື No Authentication ຕາມ​ມາ​ດ້ວຍ Bad Authentication ແລະ Bad Authorization

ສະຫລຸບ​ຄວາມ​ສ່ຽງ​ຂອງ API ຈາກ OWASP API Top 10

ໃນ​ປີ 2019 OWASP ໄດ້​ທຳການ​ວິໄ​ຈ​ແລະ​ສຳຫຼວດ​ຄວາມ​ສ່ຽງ​ດ້ານ​ຄວາມຫມັ້ນຄົງ​ປອດໄພ​ຂອງ API ຈຳ​ແນກ​ອອກ​ເປັນ 10 ອັນ​ດັບ ດັ່ງ​ນີ້:

API1: Broken Object Level Authorization (BOLA)

ການ​ເຜີ​ເປີດ​ໃຫ້​ເຂົ້າ​ເຖິງ​ຂໍ້​ມູນ​ໂດຍ​ໃຊ້ Object ID ເຊິ່ງ​ສ່ຽງ​ຖືກ​ແຮັກ​ເກີ​ເຂົ້າ​ເຖິງ​ຂໍ້​ມູນ​ອື່ນ​ໆ ຜ່ານ​ທາງ Object ID ທີ່​ບໍ່​ແມ່ນ​ຂອງ​ຕົນເອງ​ໄດ້ ດັ່ງ​ພາບ​ຕົວ​ຢ່າງ​ດ້ານ​ລຸມ​ທີ່ James Lee ສັງເກດ​ພົ​ບວ່າ​ມີ​ການ​ໃຊ້ User ID ເພື່ອ​ເຂົ້າ​ເຖິງ​ຂໍ້​ມູນ​ສ່ວນ​ບຸກ​ຄົນ ແທນ​ທີ່​ຈະ​ໃຊ້​ໝາຍ​ເລກ 23 ເພື່ອ​ເຂົ້າ​ເຖິງ​ຂໍ້​ມູນ​ຂອງ​ຕົນ ກັບ​ໃຊ້​ໝາຍ​ເລກ 24 ເພື່ອ​ເຂົ້າ​ເຖິງ​ຂໍ້​ມູນ​ຂອງ​ບຸກ​ຄົນ​ອື່ນ​ແທນ (ໃນ​ທີ່​ນີ້​ຄື​ຂໍ້​ມູນ​ຂອງ Claire Lee) ແນະ​ນຳ​ວ່າ​ຄວນ​ມີ​ການເຮັດ Authorization Policy ໃນ​ລະ​ດັບ Object ທັງ​ເທິງ​ໂຄ້​ດ​ແລະ​ເທິງ API Gateway ລວມ​ເຖິງ​ການ​ກວດ​ຈັບ​ພຶດຕິກຳ​ເພື່ອ​ຮັບ​ມື​ກັບ​ຄວາມ​ສ່ຽງ​ດັ່ງ​ກ່າວ

API2: Broken User Authentication

ການ​ໂຈມ​ຕີ​ເພື່ອ​ບາຍ​ພາດ​ການ​ພິສູດ​ຕົວ​ຕົນ ເຊິ່ງ​ອາດ​ເກີດ​ຈາກ​ການ​ທີ່​ບໍ່​ມີ​ລະບົບ​ການ​ພິສູດ​ຕົວ​ຕົນ ລະບົບ​ບໍ່​ແຂງ​ແກ່ງ​ພຽງ​ພໍ (Weak JWT) ຫລື​ການ​ໂຈມ​ຕີ​ອື່ນ​ໆ ເຊັ່ນ Credential Stuffing, ການ​ລັກ API Key ໄປ​ໃຊ້​ສວມ​ສິດ ເປັນ​ຕົ້ນ ຄວາມ​ສ່ຽງ​ນີ້​ປ້ອງ​ກັນ​ໄດ້​ໂດຍ​ການ​ໃຊ້​ລະບົບ​ພິສູດ​ຕົວ​ຕົນ​ທີ່​ແຂງ​ແກ່ງ ເຊັ່ນ OAuth/OIDC

API3: Excessive Data Exposure

ການ​ເຜີ​ເປີດ​ເຜີຍ​ຂໍ້​ມູນ​ຫລາຍ​ເກີນ​ໄປ​ເມື່ອ​ຖືກ​ຮ້ອງ​ຂໍ​ຜ່ານ API ເຊິ່ງ​ສ່ຽງ​ຕໍ່​ການ​ທີ່​ຂໍ້​ມູນ​ຄວາມ​ລັບ​ບາງຢ່າງ ເຊັ່ນ ໝາຍ​ເລກ​ບັດ​​ເຄຣ​ດິດ ອາດ​ຮົ່ວ​ໄຫຼ​ອອກ​ໄປ​ດ້ວຍ​ໄດ້ ສາມາດ​ຫຼຸດ​ຄວາມ​ສ່ຽງ​ນີ້​ໄດ້​ດ້ວຍ​ການ​ອອກ​ແບບ​ໃຫ້​ລະບົບ API ຕອບ​ກັບ​ສະເພາະ​ຂໍ້​ມູນ​ທີ່​ຈຳ​ເປັນ ຫລື​ຫາ​ໂຊ​ລູ​ຊັນ​ມາ​ກວດ​ຈັບ​ແລະ​ທຳການ Mask ຂໍ້​ມູນ​ສຳຄັນ​ທີ່​ຖືກ​ສົ່ງ​ອອກ​ໄປ

API4: Lack of Resource & Rate Limiting

ການ​ໂຈມ​ຕີ​ເກີດ​ຂຶ້ນ​ໄດ້​ເມື່ອ​ບໍ່​ມີ​ການ​ຈຳ​ກັດ​ຈຳນວນ ເນື້ອ​ຫາ ແລະ​ປະ​ເພດ​ຂອງ​ຄຳ​ຮ້ອງ​ຂໍ API ຈາກ​ຜູ້​ໃຊ້ ເຊິ່ງ​ຖ້າ​ມີ​ຄຳ​ຮ້ອງ​ຂໍ​ຫລາຍ​ເກີນ​ໄປ Payload ໃຫຍ່​ເກີນ​ໄປ ຫລື​ມີ​ການ​ດາວ​ໂຫຼດ/ອັບ​ໂຫຼດ​ໄຟ​ຂະໜາດ​ໃຫຍ່ ອາດ​ສ່ຽງ​ເກີດ​ເງື່ອນ​ໄຂ DoS ໄດ້ ແນະ​ນຳ​ໃຫ້​ເຮັດ Rate Limits ເທິງ API Gateway ເພື່ອ​ໃຫ້​ໝັ່ນໃຈ​ວ່າ​ລະບົບ API ຈະ​ພ້ອມ​ໃຊ້​ງານ​ຕະຫລອດ​ເວລາ

API5: Broken Function Level Authorization

ຄວາມ​ສ່ຽງ​ຄ້າຍ API1 ແຕ່​ເກີດ​ຈາກ​ການ​ເຜີ​ເປີດ​ໃຫ້​ແຮັກ​ເກີ​ສາມາດ​ໃຊ້​ຟັງ​ຊັນ​ຕ່າງ​ໆ ໄດ້​ໂດຍ​ບໍ່​ມີ​ສິດ ດັ່ງ​ພາບ​ຕົວ​ຢ່າງ​ດ້ານ​ລຸມ ກຸ່ມ Admin ມີ​ສິດ​ໃຊ້​ຟັງ​ຊັນ GET, POST, DELETE ໃນ​ຂະນະ​ທີ່​ກຸ່ມ Users ສາມາດ​ໃຊ້​ໄດ້​ແຄ່​ຟັງ​ຊັນ GET ເພື່ອ​ເບິ່ງ​ຂໍ້​ມູນ​ໄດ້​ຢ່າງ​ດຽວ ແຕ່​ກັບ​ໃຊ້​ຟັງ​ຊັນ​ອື່ນ​ໆ ເພື່ອ​ອັບ​ເດດ​ຫລື​ລົບ​ຂໍ້​ມູນ​ໄດ້​ດ້ວຍ ເປັນ​ຕົ້ນ ວິທີ​ການ​ປ້ອງ​ກັນ​ກໍ​ຄ້າຍ API1 ຄື ຈັດ​ເຮັດ Access Control Policy ທັງ​ເທິງ​ໂຄ້​ດ​ແລະ​ເທິງ API Gateway

API6: Mass Assignment

ໂດຍ​ທົ່ວ​ໄປ​ແລ້ວ ຈະ​ມີ​ການ​ຈຳ​ກັດ​ພາ​ຣາ​ມິ​ເຕີ​ທີ່​ໃຊ້​ສົ່ງ​ຄຳ​ຮ້ອງ​ຂໍ API ວ່າ​ຕ້ອງ​ເປັນ​ຊຸດ​ພາ​ຣາ​ມິ​ເຕ​ີ​ນີ້​ເທົ່າ​ນັ້ນ ແຕ່​ຖ້າ​ເປີດ​ໃຊ້​ຟັງ​ຊັນ Allow Bypass of Mapping Restriction ຈະ​ເຮັດໃຫ້​ສາມາດ​ເພີ່ມ​ພາ​ຣາ​ມິ​ເຕີ​ອື່ນ​ເຂົ້າໄປ​ໃນ​ການ​ສົ່ງ​ຄຳ​ຮ້ອງ​ຂໍ​ໄດ້ ເຖິງວ່າ​ການເຮັດ​ເຊັ່ນ​ນີ້​ຈະ​ຊ່ວຍ​ເພີ່ມ​ຄວາມສະດວກ​ສະບາຍ​ໃຫ້​ແກ່ Developer ແຕ່​ກໍ​ສ້າງ​ຊ່ອງ​ໂຫວ່​ໃຫ້​ແຮັກ​ເກີ​ສາມາດ​ສົ່ງ​ພາ​ຣາ​ມິ​ເຕີ​ເຂົ້າ​ມາ​ແກ້​ໄຂ​ຫລື​ປ່ຽນ​ແປງ​ຂໍ້​ມູນ​ພາຍ​ໃນ​ໄດ້​ເຊັ່ນ​ກັນ ແນະ​ນຳ​ໃຫ້​ສ້າງ OpenAPI Specification (OAS) ຕາມ Business Logic ເທິງ API Endpoints ແລ້ວ​ອິມ​ພອດ​ເຂົ້າ WAAP ຫລື API Gateway ເພື່ອ​ກວດ​ສອບ​ຄຳ​ຮ້ອງ​ຂໍ API ທີ່​ສົ່ງ​ເຂົ້າ​ມາ​ວ່າ​ເປັນ​ໄປ​ຕາມ​ທີ່​ກຳນົດ​ໄວ້​ຫລື​ບໍ່

API7: Security Misconfiguration

ການຕັ້ງ​ຄ່າ​ການ​ຖືຮັກສາ​ຄວາມຫມັ້ນຄົງ​ປອດໄພ​ທີ່​ຜິດ​ພາດ ຫລື​ເຜີ​ໃຊ້​ຄ່າ​ເລີ່ມ​ຕົ້ນ​ຈາກ​ໂຮງ​ງານ ເຊັ່ນ ລືມ​ປິດພອດ​ເລີ່ມ​ຕົ້ນ​ຈາກ​ໂຣງ​ງານ ໃຊ້​ລະ​ຫັດ​ຜ່ານ​ທີ່​ບໍ່​ແຂງ​ແກ່ງ​ພໍ ຫລື​ເປີດ​ໃຫ້​ໃຊ້ Method ທີ່​ບໍ່​ເໝາະ​ສົມ ເປັນ​ຕົ້ນ ການ​ໝັ່ນ​ກວດ​ສອບ API Inventory ແລະ​ໃຊ້​ເຄື່ອງ​ມື​ກວດ​ສອບ​ການຕັ້ງ​ຄ່າ​ຕ່າງ​ໆ ເປັນ​ແນວ​ທາງ​ປະຕິບັດ​ທີ່​ດີ​ໃນ​ການ​ຫລຸດ​ຄວາມ​ສ່ຽງ​ນີ້

API8: Injection

ຄວາມ​ສ່ຽງ​ນີ້​ຄ້າຍ​ກັບ​ການ​ໂຈມ​ຕີ Web Apps ທີ່​ແຮັກ​ເກ​ີສາມາດ​ສົ່ງ​ສ​ະຄ​ຣິ​ບ​ບາງຢ່າງ​ເຂົ້າ​ມາ​ປະ​ມວນ​ຜົນ​ໃນ​ລະບົບ​ຫຼັງ​ບ້ານ​ໄດ້ ເຊັ່ນ GET /api/account?id=”321′ OR 1=1″ ເພື່ອ​ເຮັດ SQL Injection ລັກ​ຂໍ້​ມູນ​ຈາກ Database Server ເປັນ​ຕົ້ນ ແນະ​ນຳ​ໃຫ້​ເຮັດ SAST & DAST Analysis ເພື່ອ​ຄົ້ນ​ຫາ​ແລະ​ຈັດການ​ກັບ​ຊ່ອງ​ໂຫວ່​ເຫຼົ່າ​ນີ້​ເທິງ​ໂຄ້​ດ ຫລື​ໃຊ້​ລະບົບ​ກວດ​ຈັບ Malicious Payload ຂະນະ Runtime

API9: Improper Assets Management

ການ​ເຜີ​ລືມຍົກ​ເລີກ​ການ​ໃຊ້ API ເວີ​ຊັນ​ທົດສອບ ຫລື​ເວີ​ຊັນ​ເກົ່າ​ທີ່​ບໍ່​ໄດ້​ໃຊ້​ງານ​ແລ້ວ (ເອີ້ນວ່າ Shadow API) ເຮັດໃຫ້​ແຮັກ​ເກີ​ສາມາດ​ເຂົ້າ​ເຖິງ API ເຫຼົ່າ​ນີ້​ມີ​ການ​ຖືຮັກສາ​ຄວາມຫມັ້ນຄົງ​ປອດໄພ​ຕ່ຳ​ກວ່າ ແລະ​ເຈາະ​ຊ່ອງ​ໂຫວ່​ເຂົ້າ​ມາ​ເຮັດ​ອັນຕະລາຍ​ແອັບ​ພລິ​ເຄ​ຊັນ​ພາຍ​ໃນ​ໄດ້ ຄວາມ​ສ່ຽງ​ນີ້​ຈັດການ​ໄດ້​ໂດຍ​ການເຮັດ API Discovery ແລະ​ຕິດ​ຕາມ​ການ​ໃຊ້ API ຢ່າງ​ຕໍ່​ເນື່ອງ ເພື່ອ​ເບິ່ງ​ວ່າ​ມີ API ຫຍັງແດ່​ທີ່​ເປີດ​ໃຊ້​ງານ​ຢູ່ ທັງ​ພາຍ​ໃນ​ແລະ​ພາຍນອກ

API10: Insufficient Logging and Monitoring

ການ​ຂາດ​ການ​ບັນ​ທຶກ​ຂໍ້​ມູນ ເຝົ້າ​ລະ​ວັງ ແລະ​ລາຍ​ງານ​ເຫດການ​ດ້ານ​ຄວາມຫມັ້ນຄົງ​ປອດໄພ​ທີ່​ເໝາະ​ສົມ ຫລື​ບໍ່​ພຽງ​ພໍ ເຮັດໃຫ້​ບໍ່​ສາມາດ​ກວດ​ຈັບ​ເຫດ​ຜິດ​ປົກກະຕິ ລວມ​ເຖິງ​ບໍ່​ສາມາດ​ຕິດ​ຕາມ​ເຫດ​ໂຈມ​ຕີ​ທີ່ເກີດຂື້ນ​ໄດ້​ວ່າ ເກີດ​ທີ່​ໃດ ຢ່າງໃດ ແລະ​ເມື່ອ​ໃດ  ແນະ​ນຳ​ໃຫ້​ຈັດ​ເກັບ Log ໃນລະ​ດັບ​ແອັບ​ພລິ​ເຄ​ຊັນ ແລະ​ຂໍ້​ມູ​ນບໍລິບົດ​ທີ່​ຊ່ວຍ​ໃຫ້​ສາມາດ​ວິ​ເຄາະ​ດ້ານ​ຄວາມຫມັ້ນຄົງ​ປອດໄພ​ໄດ້​ຢ່າງ​ຄອບ​ຄຸມ

6 ແນວ​ທາງ​ປະຕິບັດ​ທີ່​ດີ​ທີ່ສຸດ​ໃນ​ການ​ຖືຮັກສາ​ຄວາມຫມັ້ນຄົງ​ປອດໄພ​ໃຫ້ API

F5 ໄດ້​ໃຫ້​ຄຳ​ແນະ​ນຳ​ໃນ​ການ​ພັດທະນາ​ກົນລະຍຸດ​ການ​ຖືຮັກສາ​ຄວາມຫມັ້ນຄົງ​ປອດໄພ​ໃຫ້ API 6 ຂໍ້ ດັ່ງ​ນີ້

1. Proactive Security

ສ້າງ​ແນວ​ທາງ​ການ​ຖືຮັກສາ​ຄວາມຫມັ້ນຄົງ​ປອດໄພ API ໃຫ້ເປັນ​ມາດຕະຖານ ເຊັ່ນ ການ​ໃຊ້ API Documentation (OAS) ເພື່ອ​ລະ​ບຸ​ວ່າ​ໃຜ​ເຂົ້າ​ເຖິງ​ບໍລິການ​ຫຍັງ​ຜ່ານ API ໄດ້​ດ້ວຍ ເມ​ທັອດ​(method) ທີ່​ໃຊ້​ງານ​ຄື​ຫຍັງ ພາ​ຣາ​ມິ​ເຕ​ີ​ທີ່​ໃຊ້​ປະກອບ​ດ້ວຍ​ຫຍັງ​ດ້ວຍ ເປັນ​ຕົ້ນ

2. Access Control

ນອກ​ຈາກ​ການ​ພິສູດ​ຕົວ​ຕົນ​ແລ້ວ ອົງ​ກອນ​ຄວນ​ກຳນົດ​ສິດ​ແລະ​ຄວບ​ຄຸມ​ການ​ເຂົ້າ​ເຖິງ API ຂອງ​ແຕ່​ລະ​ຜູ້​ໃຊ້​ງານ​ໄດ້ ເພື່ອ​ປ້ອງ​ກັນ Unauthorized Access

3. API Discovery

ຫົວ​ໃຈ​ສຳຄັນ​ໃນ​ການ​ຄົ້ນ​ຫາ Shadow API ທີ່ເກິດຂື້ນ​ໃນ​ລະບົບ ຈາກ​ທັງ​ພາຍ​ໃນ​ແລະ​ພາຍນອກ ລວມ​ເຖິງ API ທີ່​ໃຊ້​ງານ​ຢູ່​ມີ​ຄວາມຫມັ້ນຄົງ​ປອດໄພ​ພຽງ​ພໍ​ຫລື​ບໍ່

4. Data Protection

ຄວນ​ຫາ​ເຄື່ອງ​ມື​ໃນ​ການ​ປ້ອງ​ກັນ Malicious Payload ເພື່ອ​ບໍ່​ໃຫ້​ເກີດ Injection ແລະ​ປ້ອງ​ກັນ​ບໍ່​ໃຫ້​ຂໍ້​ມູນ​ສຳຄັນ​ຫຼຸດ​ສູ່​ພາຍນອກ

5. Continuous Security

ປັບ​ປຸງ​ການ​ພັດທະນາ​ຊັອບແວ​ໂດຍ​ການ​ນຳ​ຂະ​ບວນ​ການ​ດ້ານ​ຄວາມຫມັ້ນຄົງ​ປອດໄພ​ໃສ່​ເຂົ້າໄປ​ໃນ​ທຸກ​ເຟດ​ຂອງ API Lifecycle (CI/CD Pipeline) ແທນ​ທີ່​ຈະ​ດຳ​ເນີນ​ການ​ຫຼັງ​ຈາກ​ທີ່​ພັດທະນາ​ຊັອບແວ​ສຳເລັດ​ຮຽບຮ້ອຍ​ແລ້ວ

6. Resource Protection

ໃຊ້ Rate Limits ເພື່ອ​ປ້ອງ​ກັນ​ການ​ໂຈມ​ຕີ​ແບບ DoS/DDoS ແລະ​ເຮັດໃຫ້​ໝັ່ນໃຈ​ວ່າ API ຈະ​ພ້ອມ​ໃຊ້​ງານ​ຕະຫລອດ​ເວລາ

ຕາ​ຕະລາງ​ດ້ານ​ລຸ່ມ​ສະແດງ​ເທັກ​ໂນ​ໂລ​ຢີ​ທີ່​ໃຊ້​ໃນ​ການສ້າງ API Security ໂດຍ​ແບ່ງ​ອອກ​ເປັນ 3 ສ່ວນ ຄື Access Control, Network Security ແລະ Runtime Protection

ແນ່ນອນ​ວ່າ Defense-in-Depth ຍັງ​ຄົງ​ເປັນ​ແນວ​ທາງ​ປະຕິບັດ​ທີ່​ສຳຄັນ​ໃນ​ການ​ປົກ​ປ້ອງ API

F5 ຜູ້​ນຳ​ດ້ານ Application Delivery ແລະ Security

F5 ເປັນ​ຜູ້​ໃຫ້​ບໍລິການ​ເທກ​ໂນ​ໂລ​ຢີ​ດ້ານ Application Delivery ແລະ Security ທີ່​ຄອບ​ຄຸມ​ທັງ​ແອັບ​ພລິ​ເຄ​ຊັນ​ແບບ​ດັ້ງ​ເດີມ ແລະ​ແອັບ​ພລິ​ເຄ​ຊັນຍຸກ​ໃໝ່​ທີ່​ໃຊ້​ສະ​ຖາ​ປັດຕະຍະ​ກຳ​ແບບ Microservices ແລະ API ເທິງ Hybrid Cloud ແລະ Multi-cloud ໂດຍ​ໂຊ​ລູ​ຊັນ API Security ຂອງ F5 ປະກອບ​ດ້ວຍ

·  ການ​ປ້ອງ​ກັນ N-S Inbound Traffic ໄດ້​ແກ່ ADC, WAF, DDoS, Authentication, SSL Offload, DNS ແລະ ອື່ນ ໆ

·  Service Discovery ສຳຫລັບ​ຄົ້ນ​ຫາ Shadow API ແລະ​ກວດ​ສອບ​ວ່າ API ທີ່​ໃຊ້​ງານ​ຢູ່​ມີ​ການຕັ້ງ​ຄ່າ​ຄວາມຫມັ້ນຄົງ​ປອດໄພ​ແຂງ​ແກ່ງ​ພຽງ​ພໍ​ຫລື​ບໍ່

·  Microgateway ສຳຫລັບ​ຕິດ​ຕາມ E-W Traffic ລວມ​ເຖິງ​ກຳນົດ​ນະໂຍບາຍ​ການ​ພິສູດ​ຕົວ​ຕົນ​ແລະ​ກຳນົດ​ສິດ​ການ​ເຂົ້າ​ເຖິງ​ໃນ​ການຕິດຕໍ່​ກັນ​ຜ່ານ API ລະຫວ່າງ Containers ໄດ້

ທີ່ມາ:Article Detail (f5.com)