Oh no! Where's the JavaScript?
Your Web browser does not have JavaScript enabled or does not support JavaScript. Please enable JavaScript on your Web browser to properly view this Web site, or upgrade to a Web browser that does support JavaScript.

ລາວເຊີດລາວເຊີດລາວເຊີດ

ບົດຄວາມ

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

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

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

ປະຕິເສດ​ບໍ່​ໄດ້​ວ່າ​ເກືອບ​ທຸກ​ອົງ​ກອນໃນ​ປັດຈຸບັນ​ຕ່າງ​ພາກັນ​ເຮັດ​ Digital Transformation,​ ແອັບ​ພິ​ເຄ​ຊັ່ນຖືກ​ພັດທະນາ​ໃຫ້​ມີ​ຄວາມ​ທັນ​ສະໄໝ​ດ້ວຍ​ສ​ະຖາ​ປັດ​ຕະຍາກຳ​ແບບ​ Microservices ຊຶ່ງ​ແບ່ງ​​ Function ການ​ເຮັດ​ວຽກ​ອອກ​ເປັນ​ຫຼາຍ​ໆ​ສ່ວນ​ ໃນ​ຂະນະ​ທີ່​ Developer ກໍ່​ແບ່ງ​ອອກ​ເປັນ​ຫຼາຍ​ທີມ​ຫຼາຍ​ຂຶ້ນ​ ເພື່ອ​ໃຫ້​ອອກຄຸນສົມບັດ ​ແລະ ​Function ​ການ​ໃຊ້​ງານ​ໃໝ່​ໆ​ ສູ່ຕະຫຼາດ​ໄດ້​ຢ່າງ​ວ່ອງໄວ​ ລວມເຖິງ​ການ​ປັບ​ໄປ​ໃຊ້​ 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 ທັງ​ເທິງ​ໂຄ້ດ (Code) ​ແລະ ​ເທິງ​ API Gateway ລວມ​ເຖິງ​ການ​ກວດ​ຈັບ​ພຶດຕິກຳ​ເພື່ອ​ຮັບ​ມື​ກັບ​ຄວາມ​ສ່ຽງ​ດັ່ງ​ກ່າວ​.


API2: Broken User Authentication

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

API3: Excessive Data Exposure

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

API4: Lack of Resource & Rate Limiting

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

API5: Broken Function Level Authorization

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


API6: Mass Assignment

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

API7: Security Misconfiguration

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

API8: Injection

ຄວາມ​ສ່ຽງ​ນີ້​ຄ້າຍ​ຄືກັບ​ການ​ໂຈມ​ຕີ​ Web Apps ທີ່​ແຮັກ​ເກີ​​ສາມາດ​ສົ່ງ​ script ​ບາງຢ່າງ​ເຂົ້າ​ມາປະ​ມວນ​ຜົນ​ໃນ​ລະບົບ​ຫຼັງ​ບ້ານ​ໄດ້​ ເຊັ່ນ:​ 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 ໄດ້ແດ່, ​ວິທີ​ທີ່​ໃຊ້​ງານ​ຄື​ຫຍັງ​, ພາ​ຣາ​ມິ​ເຕີ​​ທີ່​ໃຊ້​ປະກອບ​ດ້ວຍ​ຫຍັງ​ແດ່​ ເປັນ​ຕົ້ນ​.

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.


ເອກະສານອ້າງອີງ: https://www.techtalkthai.com/owasp-api-top-10-and-6-api-security-best-practices-by-f5/

Meesaisak 25 April 2023 703 reads Print