ແອັບມາດຕະຖານປອດໄພ

ຂໍ້ມູນຜະລິດຕະພັນ

ຂໍ້ມູນຈໍາເພາະ

• ຊື່ຜະລິດຕະພັນ: ມາດຕະຖານແອັບປອດໄພຂອງ CSA
• ລຸ້ນ: 1.0
• ວັນທີປ່ອຍ: ມັງກອນ 10, 2024

ກ່ຽວກັບມາດຕະຖານ

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

ຈຸດປະສົງ, ຂອບເຂດ, ແລະຜູ້ຊົມທີ່ຕັ້ງໃຈ

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

ແຈ້ງການ ແລະຄໍາແນະນໍາຂອງຜູ້ພັດທະນາ

ມາດຕະຖານແອັບທີ່ປອດໄພຂອງ CSA ໃຫ້ຄຳແນະນຳແກ່ນັກພັດທະນາ
ປະຕິບັດການຄວບຄຸມຄວາມປອດໄພຂອງການກວດສອບຄວາມຖືກຕ້ອງ. ມັນເນັ້ນຫນັກໃສ່
ຄວາມສໍາຄັນຂອງການປະຕິບັດຕາມການປະຕິບັດທີ່ດີທີ່ສຸດຂອງອຸດສາຫະກໍາແລະການຮັບປະກັນ
ການປະຕິບັດຢ່າງປອດໄພຂອງກົນໄກການກວດສອບ. ນັກພັດທະນາ
ຄວນອ້າງອີງເຖິງມາດຕະຖານສໍາລັບຄໍາແນະນໍາລະອຽດກ່ຽວກັບການຈັດຕັ້ງປະຕິບັດ
ການຄວບຄຸມຄວາມປອດໄພທີ່ແນະນໍາ.

ຄໍານິຍາມເອກະສານແລະການອ້າງອີງມາດຕະຖານ

ມາດຕະຖານແອັບຯທີ່ປອດໄພຂອງ CSA ປະກອບມີຄໍານິຍາມເອກະສານ ແລະ
ການອ້າງອິງມາດຕະຖານທີ່ໃຫ້ຄວາມຊັດເຈນກ່ຽວກັບຄໍາສັບທີ່ໃຊ້
ແລະອ້າງອີງເຖິງມາດຕະຖານອຸດສາຫະກໍາທີ່ກ່ຽວຂ້ອງອື່ນໆແລະຄໍາແນະນໍາ.
ນັກພັດທະນາຄວນອ້າງອີງເຖິງຄໍານິຍາມແລະການອ້າງອີງເຫຼົ່ານີ້ສໍາລັບ a
ຄວາມ​ເຂົ້າ​ໃຈ​ທີ່​ດີກ​ວ່າ​ມາດ​ຕະ​ຖານ​.

ຄໍາແນະນໍາການນໍາໃຊ້ຜະລິດຕະພັນ

ການຢືນຢັນ

ການກວດສອບຄວາມຖືກຕ້ອງແມ່ນສ່ວນປະກອບສໍາຄັນຂອງມືຖືສ່ວນໃຫຍ່
ຄໍາຮ້ອງສະຫມັກ. ມັນຢັ້ງຢືນຕົວຕົນຂອງຜູ້ໃຊ້, ລູກຄ້າ,
ແອັບພລິເຄຊັນ, ແລະອຸປະກອນກ່ອນທີ່ຈະໃຫ້ການເຂົ້າເຖິງສະເພາະ
ຊັບພະຍາກອນຫຼືອະນຸຍາດໃຫ້ປະຕິບັດບາງຢ່າງ. ມາດຕະຖານແອັບທີ່ປອດໄພຂອງ CSA
ໃຫ້ຄໍາແນະນໍາແລະການປະຕິບັດທີ່ດີທີ່ສຸດສໍາລັບການປະຕິບັດທີ່ປອດໄພ
ການຄວບຄຸມການພິສູດຢືນຢັນ.

ການຄວບຄຸມຄວາມປອດໄພ

ມາດຕະຖານແອັບປອດໄພຂອງ CSA ປະກອບມີສິ່ງຕໍ່ໄປນີ້
ການຄວບຄຸມຄວາມປອດໄພຂອງການກວດສອບຄວາມຖືກຕ້ອງ:

ID	ການຄວບຄຸມ
AUTHN-BP01	ແອັບຯດັ່ງກ່າວໃຊ້ Multi-Factor Authentication (MFA) ເພື່ອພິສູດຢືນຢັນ ທຸລະກໍາທີ່ມີຄວາມສ່ຽງສູງ.
AUTHN-BP02	ການຄວບຄຸມຄໍາອະທິບາຍ
AUTHN-BP03	ການຄວບຄຸມຄໍາອະທິບາຍ
AUTHN-BP04	ການຄວບຄຸມຄໍາອະທິບາຍ
AUTHN-BP05	ການຄວບຄຸມຄໍາອະທິບາຍ
AUTHN-BP06	ການຄວບຄຸມຄໍາອະທິບາຍ

AUTHN-BP01 – ການພິສູດຢືນຢັນຫຼາຍປັດໃຈ (MFA)

ໃນລະບົບການກວດສອບປັດໄຈດຽວແບບດັ້ງເດີມ, ຜູ້ໃຊ້
ໂດຍປົກກະຕິພຽງແຕ່ຕ້ອງການປ້ອນບາງສິ່ງບາງຢ່າງ-ເຈົ້າ-ຮູ້ (ເຊັ່ນ: ຊື່ຜູ້ໃຊ້
ແລະລະຫັດຜ່ານ). ຢ່າງໃດກໍ່ຕາມ, MFA ເພີ່ມຂັ້ນຕອນຂອງການຢັ້ງຢືນຕົວຕົນ
ໂດຍຮຽກຮ້ອງໃຫ້ມີປັດໃຈເພີ່ມເຕີມເຊັ່ນ Something-You-Have ແລະ
Something-You-Are. ນີ້ເຮັດໃຫ້ມັນທ້າທາຍຫຼາຍສໍາລັບ malicious
ນັກສະແດງເພື່ອປະນີປະນອມບັນຊີແລະເສີມຂະຫຍາຍຄວາມປອດໄພໂດຍລວມຂອງ
ຂະບວນການຢັ້ງຢືນ.

ຄຳແນະນຳການຈັດຕັ້ງປະຕິບັດ

ນັກພັດທະນາຄວນປະຕິບັດຂັ້ນຕອນ MFA, ເຊິ່ງຮຽກຮ້ອງໃຫ້ມີ
ລະດັບການກວດສອບເພີ່ມເຕີມສໍາລັບການເຮັດທຸລະກໍາທີ່ມີຄວາມສ່ຽງສູງ. ໄດ້
ມາດຕະຖານແອັບປອດໄພຂອງ CSA ໃຫ້ຄວາມສຳຄັນຕໍ່ MFA ຕໍ່ໄປນີ້
ການປະສົມປະສານ:

1. ບາງສິ່ງບາງຢ່າງ - ເຈົ້າຮູ້
2. ບາງສິ່ງບາງຢ່າງ - ເຈົ້າມີ
3. Something-You-Are

ຄຳຖາມທີ່ຖາມເລື້ອຍໆ (FAQ)

Q: ຈຸດປະສົງຂອງມາດຕະຖານແອັບຯທີ່ປອດໄພຂອງ CSA ແມ່ນຫຍັງ?

A: ຈຸດ​ປະ​ສົງ​ຂອງ​ມາດ​ຕະ​ຖານ App ປອດ​ໄພ CSA ແມ່ນ​ເພື່ອ​ສະ​ຫນອງ​ໃຫ້
ນັກພັດທະນາທີ່ມີຄໍາແນະນໍາແລະການປະຕິບັດທີ່ດີທີ່ສຸດສໍາລັບການປະຕິບັດ
ການຄວບຄຸມການພິສູດຢືນຢັນທີ່ປອດໄພໃນແອັບພລິເຄຊັນມືຖື.

ຖາມ: ໃຜເປັນຜູ້ຊົມທີ່ມີຈຸດປະສົງສໍາລັບແອັບຯທີ່ປອດໄພຂອງ CSA
ມາດຕະຖານ?

A: ມາດຕະຖານແອັບຯທີ່ປອດໄພຂອງ CSA ແມ່ນມີຈຸດປະສົງສໍາລັບນັກພັດທະນາແລະ
ອົງການຈັດຕັ້ງມີສ່ວນຮ່ວມໃນການພັດທະນາຄໍາຮ້ອງສະຫມັກໂທລະສັບມືຖື
ທີ່ຮຽກຮ້ອງໃຫ້ມີການກວດສອບຄວາມຖືກຕ້ອງ.

ຖາມ: ແມ່ນຫຍັງຄືຜົນປະໂຫຍດຂອງການປະຕິບັດ Multi-Factor
ການຮັບຮອງຄວາມຖືກຕ້ອງ (MFA)?

A: ການປະຕິບັດ MFA ເພີ່ມຂັ້ນຕອນຂອງການຢັ້ງຢືນຕົວຕົນ, ການສ້າງ
ມັນທ້າທາຍຫຼາຍສໍາລັບນັກສະແດງທີ່ເປັນອັນຕະລາຍທີ່ຈະປະນີປະນອມບັນຊີແລະ
ເສີມຂະຫຍາຍຄວາມປອດໄພໂດຍລວມຂອງຂະບວນການກວດສອບຄວາມຖືກຕ້ອງ.

1

CSA's Safe App Standard Version 1.0 ປ່ອຍອອກມາເມື່ອວັນທີ 10 ມັງກອນ 2024
2

ໃນ​ການ​ປຶກ​ສາ​ຫາ​ລື​ກັບ​:
ສະມາຄົມຂອງທະນາຄານສິງກະໂປ, ຄະນະກໍາມະການປະຈໍາຂອງ Cyber ​​Committee Deloitte ທີ່ປຶກສາຄວາມສ່ຽງອາຊີຕາເວັນອອກສຽງໃຕ້ Ernst & Young Advisory Pte. Ltd. KPMG ໃນສິງກະໂປ Lazada Microsoft Singapore PricewaterhouseCoopers Risk Services Pte. ຈຳກັດ.
ການປະຕິເສດຄວາມຮັບຜິດຊອບ:
ອົງການຈັດຕັ້ງເຫຼົ່ານີ້ໄດ້ຮັບການປຶກສາຫາລືກ່ຽວກັບມາດຕະຖານສໍາລັບຄໍາຕິຊົມແລະຄໍາເຫັນກ່ຽວກັບການຄວບຄຸມຄວາມປອດໄພ, ລາຍລະອຽດຂອງການຄວບຄຸມຄວາມປອດໄພ, ແລະຄໍາແນະນໍາການປະຕິບັດດ້ານວິຊາການ. ໃນຂອບເຂດສູງສຸດທີ່ອະນຸຍາດພາຍໃຕ້ກົດຫມາຍ, CSA, ແລະທີ່ປຶກສາພາຍນອກຈະບໍ່ຮັບຜິດຊອບຕໍ່ຄວາມບໍ່ຖືກຕ້ອງ, ຂໍ້ຜິດພາດແລະ / ຫຼືການລະເວັ້ນໃດໆທີ່ມີຢູ່ໃນນີ້, ຫຼືການສູນເສຍຫຼືຄວາມເສຍຫາຍໃດໆ (ລວມທັງການສູນເສຍຜົນກໍາໄລ, ທຸລະກິດ, ຄວາມດີ, ຫຼືຊື່ສຽງ. , ແລະ/ຫຼືຄວາມເສຍຫາຍພິເສດ, ບັງເອີນ, ຫຼືຜົນສະທ້ອນ) ທີ່ກ່ຽວຂ້ອງກັບການນໍາໃຊ້ ຫຼືການອີງໃສ່ມາດຕະຖານນີ້. ອົງການຈັດຕັ້ງທີ່ພັດທະນາແອັບຯມືຖື, ຜູ້ໃຫ້ບໍລິການແລະຜູ້ພັດທະນາໄດ້ຖືກແນະນໍາໃຫ້ພິຈາລະນາວິທີການມາດຕະຖານທີ່ອາດຈະຖືກນໍາໃຊ້ກັບສະຖານະການສະເພາະຂອງພວກເຂົາໄດ້ຮັບຄໍາແນະນໍາທາງດ້ານກົດຫມາຍແລະ / ຫຼືດ້ານວິຊາການຂອງຕົນເອງທີ່ກ່ຽວຂ້ອງກັບເນື້ອຫາແລະ / ຫຼືການປະຕິບັດຄໍາແນະນໍາໃນອົງການຈັດຕັ້ງມາດຕະຖານການພັດທະນາມືຖື. ແອັບຯ, ຜູ້ໃຫ້ບໍລິການແລະນັກພັດທະນາຄວນໃຊ້ຄໍາຕັດສິນຂອງມືອາຊີບຖ້າແລະໃນເວລາທີ່ປະຕິບັດຄໍາແນະນໍາໃນມາດຕະຖານ, ແລະຄວນພິຈາລະນາວ່າມາດຕະການເພີ່ມເຕີມແມ່ນມີຄວາມຈໍາເປັນທີ່ກ່ຽວຂ້ອງກັບສະຖານະການສະເພາະຂອງພວກເຂົາ.
3

ເນື້ອໃນ
ໃນການປຶກສາຫາລືກັບ: ……………………………………………………………………………………………………………………… 3 ປະຕິເສດ: … ………………………………………………………………………………………………………………………………………. 3 ກ່ຽວກັບມາດຕະຖານ……………………………………………………………………………………………………………………… 6 ຈຸດປະສົງ, ຂອບເຂດ, ແລະຜູ້ຊົມທີ່ຕັ້ງໃຈ …………………………………………………………………………………………… 6 ແຈ້ງການ ແລະ ຄຳແນະນຳຜູ້ພັດທະນາ ……………………. ………………………………………………………………………………. 7 ນິຍາມເອກະສານ ແລະ ເອກະສານອ້າງອີງ ……………………………………………………………………………… 8 1. ການກວດສອບຄວາມຖືກຕ້ອງ …………………………………. ……………………………………………………………………………… 10
AUTHN-BP01 …………………………………………………………………………………………………………………………. 11 AUTHN-BP01a ………………………………………………………………………………………………………………………. 13 AUTHN-BP01b ………………………………………………………………………………………………………………………. 14 AUTHN-BP01c……………………………………………………………………………………………………………………….. 15
AUTHN-BP02 …………………………………………………………………………………………………………………………. 16 AUTHN-BP03 …………………………………………………………………………………………………………………………. 17
AUTHN-BP03a ………………………………………………………………………………………………………………………. 18 AUTHN-BP03b ………………………………………………………………………………………………………………………. 19 AUTHN-BP04 …………………………………………………………………………………………………………………………. 20 AUTHN-BP05 …………………………………………………………………………………………………………………………. 21 AUTHN-BP06 …………………………………………………………………………………………………………………………. 22 ………………………………………………………………………………………………………………………………………………… ……….. 23 2. ການອະນຸຍາດ ………………………………………………………………………………………………………………………. ….. 24 AUTHOR-BP01 ……………………………………………………………………………………………………………………… .. 25 AUTHOR-BP02 ………………………………………………………………………………………………………………………. . 26 AUTHOR-BP03 ………………………………………………………………………………………………………….. 27 AUTHOR-BP04 ……………………………………………………………………………………………………………………….. 28 ………………………………………………………………………………………………………………………………………………… …….. 29 3. ການເກັບຮັກສາຂໍ້ມູນ (Data-at-Rest) ……………………………………………………………………………………………. …. 30 STORAGE-BP01 ………………………………………………………………………………………………………………………. 31 STORAGE-BP02 ………………………………………………………………………………………………………………………. 32 STORAGE-BP02a …………………………………………………………………………………………………………………………. 33 STORAGE-BP02b …………………………………………………………………………………………………………………………. 34 STORAGE-BP03 ………………………………………………………………………………………………………………………. 35 ………………………………………………………………………………………………………………………………………………… ……….. 36 4. ຕ້ານ Tampering & Anti-Reversing ……………………………………………………………………………………………..37 RESILIENCE-BP01 ………………… …………………………………………………………………………………………………………. 38 Resilience-BP02 ………………………………………………………………………………………………………………………. 39
4

ຄວາມຢືດຢຸ່ນ-BP03 ……………………………………………………………………………………………………………………………………. 41 Resilience-BP04 ………………………………………………………………………………………………………………………. 42 Resilience-BP05 ………………………………………………………………………………………………………………………. 43 Resilience-BP06 ………………………………………………………………………………………………………………………. 44 Resilience-BP07 ………………………………………………………………………………………………………………………. 45 ເອກະສານອ້າງອີງ…………………………………………………………………………………………………………………………………… 46
5

ກ່ຽວກັບມາດຕະຖານ
ການແນະນຳມາດຕະຖານແອັບທີ່ປອດໄພແມ່ນມາດຕະຖານທີ່ແນະນຳສຳລັບແອັບພລິເຄຊັນມືຖື (ແອັບ), ພັດທະນາໂດຍອົງການຄວາມປອດໄພທາງໄຊເບີຂອງສິງກະໂປ (CSA), ໂດຍປຶກສາຫາລືກັບຄູ່ຮ່ວມອຸດສາຫະກໍາຈາກສະຖາບັນການເງິນ, ອົງການຈັດຕັ້ງເຕັກໂນໂລຢີ, ບໍລິສັດທີ່ປຶກສາ ແລະ ອົງການຂອງລັດຖະບານ. ເກີນview ຈຸດ​ປະ​ສົງ​ຂອງ​ມາດ​ຕະ​ຖານ​ແມ່ນ​ເພື່ອ​ນໍາ​ໃຊ້​ເປັນ​ພື້ນ​ຖານ​ທີ່​ແນະ​ນໍາ​ຂອງ​ການ​ຄວບ​ຄຸມ​ຄວາມ​ປອດ​ໄພ​ສໍາ​ລັບ​ຜູ້​ພັດ​ທະ​ນາ app ໂທລະ​ສັບ​ມື​ຖື​ແລະ​ຜູ້​ໃຫ້​ບໍ​ລິ​ການ​ປະ​ຕິ​ບັດ​ຕາມ​. ນີ້ຈະຮັບປະກັນວ່າແອັບຯທ້ອງຖິ່ນທັງຫມົດປະຕິບັດຕາມຊຸດການຄວບຄຸມຄວາມປອດໄພທີ່ຄ້າຍຄືກັນສໍາລັບແອັບຯມືຖື, ດັ່ງນັ້ນການເພີ່ມລະດັບຄວາມປອດໄພຂອງແອັບຯທີ່ໂຮດແລະສ້າງຢູ່ໃນສິງກະໂປ.
ຈຸດປະສົງ, ຂອບເຂດ, ແລະຜູ້ຊົມທີ່ຕັ້ງໃຈ
ເອກະສານນີ້ໄດ້ຖືກພັດທະນາຂື້ນເພື່ອສະຫນອງຄໍາແນະນໍາແລະຄໍາແນະນໍາກັບນັກພັດທະນາເພື່ອຊ່ວຍພວກເຂົາໃນການປະຕິບັດຫນ້າທີ່ຄວາມປອດໄພໃນແອັບຯຂອງພວກເຂົາ. ຄໍາແນະນໍາແລະຄໍາແນະນໍາດັ່ງກ່າວແມ່ນແນໃສ່ການຊ່ວຍເຫຼືອຜູ້ພັດທະນາໃນການຫຼຸດຜ່ອນຄວາມກວ້າງໃຫຍ່ຂອງໄພຂົ່ມຂູ່ຕໍ່ຄວາມປອດໄພທາງອິນເຕີເນັດແລະໃນການປົກປ້ອງແອັບຯຂອງພວກເຂົາຈາກການຫລອກລວງມືຖືຫຼ້າສຸດແລະການຂຸດຄົ້ນ malware ມືຖື. ເນື້ອໃນໃນທີ່ນີ້ແມ່ນບໍ່ມີຜົນຜູກພັນ, ສະໜອງໃຫ້ບົນພື້ນຖານການບໍ່ເພິ່ງພາອາໄສ ແລະ ມີຄວາມໝາຍເປັນຂໍ້ມູນຕາມທຳມະຊາດ, ແລະ ບໍ່ໄດ້ມີຈຸດປະສົງເພື່ອລະບຸໄພຂົ່ມຂູ່ດ້ານຄວາມປອດໄພທາງອິນເຕີເນັດຢ່າງຄົບຖ້ວນ ຫຼື ລະບຸຂະບວນການ ຫຼື ລະບົບຢ່າງຄົບຖ້ວນທີ່ຜູ້ພັດທະນາຄວນວາງໄວ້ເພື່ອແກ້ໄຂ ຫຼື ປ້ອງກັນສິ່ງດັ່ງກ່າວ. ໄພຂົ່ມຂູ່. ເວີຊັນ 1 ຂອງຂໍ້ແນະນຳ ແລະການຄວບຄຸມຄວາມປອດໄພຂອງ Safe App Standard ຈະເນັ້ນໃສ່ການສະໜອງຂໍ້ແນະນຳດ້ານຄວາມປອດໄພໃຫ້ກັບຜູ້ພັດທະນາແອັບທີ່ມີຄວາມສ່ຽງສູງເພື່ອຕ້ານກັບ malware ມືຖືຫຼ້າສຸດແລະການຂູດຮີດທີ່ເຫັນຢູ່ໃນສະພາບໄພຂົ່ມຂູ່ຂອງສິງກະໂປ. ແນວໃດກໍ່ຕາມ, ການຄວບຄຸມຄວາມປອດໄພເຫຼົ່ານີ້ຍັງສາມາດຮັບຜົນປະໂຫຍດ ແລະຖືກປະຕິບັດໂດຍແອັບຯອື່ນໆ. ຂໍແນະນຳໃຫ້ນັກພັດທະນາທຸກຄົນພະຍາຍາມປະຕິບັດມາດຕະການເຫຼົ່ານີ້ເພື່ອຄວາມປອດໄພຂອງແອັບຯມືຖືທີ່ປັບປຸງດີຂຶ້ນ. ເຖິງແມ່ນວ່າມາດຕະຖານນີ້ມີພື້ນທີ່ຈຸດສຸມຕົ້ນຕໍ, ການແກ້ໄຂໃນອະນາຄົດຈະຂະຫຍາຍອອກໄປເພື່ອແກ້ໄຂການປະຕິບັດທີ່ດີທີ່ສຸດດ້ານຄວາມປອດໄພແລະຂໍ້ແນະນໍາສໍາລັບ stack app ມືຖືທັງຫມົດ.
6

ແຈ້ງການ ແລະຄໍາແນະນໍາຂອງຜູ້ພັດທະນາ
ນີ້​ແມ່ນ​ເອ​ກະ​ສານ​ດໍາ​ລົງ​ຊີ​ວິດ​ທີ່​ຈະ​ໄດ້​ຮັບ​ການ review ແລະ​ການ​ປັບ​ປຸງ​ແຕ່​ລະ​ໄລ​ຍະ​. ເຊັ່ນດຽວກັນກັບມາດຕະຖານອື່ນໆທີ່ຖືກສ້າງຕັ້ງຂື້ນ, Safe App Standard ແມ່ນເອກະສານທີ່ມີຊີວິດຊີວາທີ່ຈະໄດ້ຮັບການປັບປຸງເປັນປົກກະຕິເພື່ອໃຫ້ກົງກັບພູມສັນຖານໄພຂົ່ມຂູ່ທີ່ກໍາລັງພັດທະນາແລະປະຈຸບັນແລະການໂຈມຕີໃຫມ່. ກະລຸນາອ້າງອີງເຖິງ CSA's webເວັບ​ໄຊ​ທີ່​ຈະ​ໄດ້​ຮັບ​ການ​ປັບ​ປຸງ​ສະ​ບັບ​ຫລ້າ​ສຸດ​ຂອງ Safe App ມາດ​ຕະ​ຖານ​ແລະ​ປັບ​ມາດ​ຕະ​ການ​ຄວາມ​ປອດ​ໄພ​ແລະ​ການ​ຄວບ​ຄຸມ​ຕາມ​ຄວາມ​ເຫມາະ​ສົມ​. ມາດຕະຖານນີ້ຄວນຈະຖືກອ່ານຮ່ວມກັບ ແລະບໍ່ປ່ຽນແທນ, ປ່ຽນແປງ, ຫຼືປ່ຽນແທນບັນດາພັນທະທາງກົດໝາຍ, ລະບຽບການ, ຫຼືໜ້າທີ່ອື່ນໆຂອງຜູ້ພັດທະນາແອັບ ແລະຜູ້ໃຫ້ບໍລິການ, ລວມທັງພາຍໃຕ້ກົດໝາຍວ່າດ້ວຍຄວາມປອດໄພທາງໄຊເບີ 2018, ແລະກົດໝາຍສາຂາ, ລະຫັດການປະຕິບັດ, ມາດຕະຖານການປະຕິບັດ, ຫຼືທິດທາງລາຍລັກອັກສອນທີ່ອອກໃນນັ້ນ. ການນໍາໃຊ້ເອກະສານນີ້ແລະການປະຕິບັດຄໍາແນະນໍາໃນທີ່ນີ້ບໍ່ໄດ້ຍົກເວັ້ນຫຼືເຮັດໃຫ້ຜູ້ພັດທະນາ app ແລະຜູ້ໃຫ້ບໍລິການອັດຕະໂນມັດອອກຈາກພັນທະຫຼືຫນ້າທີ່ດັ່ງກ່າວ. ເນື້ອໃນຂອງເອກະສານນີ້ບໍ່ໄດ້ມີຈຸດປະສົງເພື່ອເປັນຄໍາຖະແຫຼງທີ່ມີອໍານາດຂອງກົດຫມາຍຫຼືການທົດແທນຄໍາແນະນໍາທາງດ້ານກົດຫມາຍຫຼືຜູ້ຊ່ຽວຊານດ້ານອື່ນໆ. ຄໍາແນະນໍາຂອງຜູ້ພັດທະນາກ່ຽວກັບກອບມາດຕະຖານຄວາມປອດໄພຂອງແອັບ Safe ເພື່ອຄວາມສະດວກໃນການນຳໃຊ້, ນັກພັດທະນາຄວນຈື່ໄວ້ວ່າ ເວີຊັ່ນ 1 ຂອງມາດຕະຖານແອັບປອດໄພ ກຳນົດເປົ້າໝາຍໃນພື້ນທີ່ສຳຄັນຕໍ່ໄປນີ້, ແລະ ເອກະສານຕົວມັນເອງສາມາດແບ່ງອອກເປັນສ່ວນຍ່ອຍຕໍ່ໄປນີ້:
· Authentication · authorization · Data Storage (Data-at-Rest) · Anti-Tamper & Anti-Reversing ພື້ນທີ່ສໍາຄັນເຫຼົ່ານີ້ແມ່ນລວມເພື່ອຮັບປະກັນມາດຕະຖານຂອງຄວາມປອດໄພຂອງແອັບຯມືຖືຕໍ່ກັບ vectors ການໂຈມຕີທົ່ວໄປທີ່ສຸດທີ່ໃຊ້ໂດຍຜູ້ເປັນອັນຕະລາຍໃນລະບົບນິເວດທ້ອງຖິ່ນຂອງພວກເຮົາ. ມາດຕະຖານແອັບປອດໄພສະໜອງຊຸດການຄວບຄຸມຄວາມປອດໄພ, ຂໍ້ແນະນຳ ແລະ ການປະຕິບັດທີ່ດີທີ່ສຸດທີ່ຈະແຈ້ງ ແລະ ຫຍໍ້ທໍ້ສຳລັບການເພີ່ມຄວາມປອດໄພຂອງແອັບມືຖືທີ່ສະໜອງ ຫຼື ເປີດໃຊ້ທຸລະກຳທີ່ມີຄວາມສ່ຽງສູງ.
7

ຄໍານິຍາມເອກະສານແລະການອ້າງອີງມາດຕະຖານ
ຄໍານິຍາມຂອງເອກະສານ ຕໍ່ໄປນີ້ແມ່ນບາງຄໍານິຍາມທີ່ນັກພັດທະນາ ແລະຜູ້ອ່ານຄວນຈື່ໄວ້ເມື່ອພວກເຂົາໃຊ້ເອກະສານນີ້: ຂໍ້ມູນລະອຽດອ່ອນ ຂໍ້ມູນຜູ້ໃຊ້ເຊັ່ນ: ຂໍ້ມູນການລະບຸຕົວຕົນສ່ວນບຸກຄົນ (PII) ແລະຂໍ້ມູນການພິສູດຢືນຢັນເຊັ່ນ: ຂໍ້ມູນປະຈໍາຕົວ, ກະແຈການເຂົ້າລະຫັດ, ລະຫັດຜ່ານຄັ້ງດຽວ, ຂໍ້ມູນຊີວະມິຕິ. , ໂທເຄັນຄວາມປອດໄພ, ໃບຢັ້ງຢືນ, ແລະອື່ນໆ. ທຸລະກໍາທີ່ມີຄວາມສ່ຽງສູງແມ່ນສິ່ງທີ່ກ່ຽວຂ້ອງກັບ:
· ການ​ປ່ຽນ​ແປງ​ຫນ້າ​ທີ່​ທາງ​ດ້ານ​ການ​ເງິນ​ບາງ examples ປະກອບມີແຕ່ບໍ່ຈໍາກັດການລົງທະບຽນລາຍລະອຽດຂອງຜູ້ຮັບເງິນພາກສ່ວນທີສາມ, ການເພີ່ມຂອບເຂດການໂອນເງິນ, ແລະອື່ນໆ.
· ການລິເລີ່ມຂອງທຸລະກໍາທາງດ້ານການເງິນບາງ examples ປະກອບມີແຕ່ບໍ່ຈໍາກັດການເຮັດທຸລະກໍາກອງທຶນມູນຄ່າສູງ, ການໂອນເງິນມູນຄ່າສູງ, ການເຮັດທຸລະກໍາບັດອອນໄລນ໌, ການເຂົ້າເຖິງການຫັກເງິນໂດຍກົງ, ຫນ້າທີ່ເກັບຮັກສາເງິນ, ແລະການເຕີມເງິນ, ແລະອື່ນໆ.
· ການ​ປ່ຽນ​ແປງ​ການ​ຕັ້ງ​ຄ່າ​ຄວາມ​ປອດ​ໄພ​ຂອງ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ບາງ examples ເຫຼົ່ານີ້ປະກອບມີແຕ່ບໍ່ຈໍາກັດພຽງແຕ່ການປິດວິທີການກວດສອບຄວາມຖືກຕ້ອງ, ການປັບປຸງ tokens ດິຈິຕອນຫຼືຂໍ້ມູນປະຈໍາ, ແລະອື່ນໆ.
ການ​ຄວບ​ຄຸມ​ຄວາມ​ປອດ​ໄພ​ການ​ປະ​ຕິ​ບັດ​ຫຼື​ມາດ​ຕະ​ການ​ທາງ​ດ້ານ​ວິ​ຊາ​ການ​ແນະ​ນໍາ​ໃຫ້​ຢູ່​ໃນ​ເອ​ກະ​ສານ​ນີ້​ທີ່​ຄວນ​ຈະ​ໄດ້​ຮັບ​ການ​ປະ​ຕິ​ບັດ​ໃນ​ການ​ຄຸ້ມ​ຄອງ​, ຕິດ​ຕາມ​ກວດ​ກາ​, ແລະ​ຫຼຸດ​ຜ່ອນ​ຄວາມ​ສ່ຽງ​ດ້ານ​ຄວາມ​ປອດ​ໄພ​ຫຼື​ເຫດ​ການ​. ການຄວບຄຸມຄວາມປອດໄພເຫຼົ່ານີ້ມີ ID ຕໍ່ໄປນີ້ຕິດກັບພວກມັນ, ເຊັ່ນ: AUTHN-BP01, AUTHOR-BP01, STORAGE-BP01, RESILIENCE-BP01. Normative References ມາດຕະຖານ App Safe ອ້າງອີງມາດຕະຖານອຸດສາຫະກໍາຈາກ Open Web ໂຄງການຄວາມປອດໄພຂອງແອັບພລິເຄຊັນ (OWASP), ອົງການເຄືອຂ່າຍ ແລະຄວາມປອດໄພຂໍ້ມູນຂ່າວສານ (ENISA) ຂອງສະຫະພາບເອີຣົບ ແລະ ມາດຕະຖານຄວາມປອດໄພດ້ານຂໍ້ມູນອຸດສາຫະກໍາບັດຊໍາລະ (PCI DSS). ບັນຊີລາຍຊື່ຂອງເອກະສານອ້າງອີງແມ່ນດັ່ງຕໍ່ໄປນີ້:
· MASVS ຂອງ OWASP (ມາດຕະຖານການກວດສອບຄວາມປອດໄພຂອງແອັບພລິເຄຊັນມືຖື) · MASTG ຂອງ OWASP (ຄູ່ມືການທົດສອບຄວາມປອດໄພຂອງແອັບພລິເຄຊັນມືຖື) · ENISA's Secure Development Guidelines (SSDG) · PCI DSS's Mobile Payment Guidelines for Developers
8

9

1. ການຢືນຢັນ

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

ID

ການຄວບຄຸມ

AUTHN-BP01 AUTHN-BP01a AUTHN-BP01b AUTHN-BP01c AUTHN-BP02 AUTHN-BP03 AUTHN-BP03a AUTHN-BP03b AUTHN-BP04 AUTHN-BP05PAUTHN

ໃຊ້ Multi-Factor Authentication ເພື່ອພິສູດຢືນຢັນທຸລະກຳທີ່ມີຄວາມສ່ຽງສູງ. ປະຕິບັດການພິສູດຢືນຢັນບາງຢ່າງທີ່ທ່ານຮູ້ເປັນຫນຶ່ງໃນປັດໃຈ MFA. ປະຕິບັດບາງສິ່ງບາງຢ່າງ - ເຈົ້າ - ມີການກວດສອບຄວາມຖືກຕ້ອງເປັນຫນຶ່ງໃນປັດໃຈ MFA. ປະຕິບັດການພິສູດຢືນຢັນບາງສິ່ງບາງຢ່າງ - ເຈົ້າເປັນຫນຶ່ງໃນປັດໃຈ MFA. ໃຊ້ປັດໃຈທີ່ອີງໃສ່ບໍລິບົດເພື່ອພິສູດຢືນຢັນ. ປະຕິບັດການຮັບຮອງເຊດຊັນທີ່ປອດໄພ. ປະຕິບັດການພິສູດຢືນຢັນທີ່ປອດໄພ. ປະຕິບັດການພິສູດຢືນຢັນທີ່ບໍ່ມີລັດທີ່ປອດໄພ. ປະຕິບັດການປິດເຊດຊັນທີ່ປອດໄພໃນລະຫວ່າງການອອກຈາກລະບົບ, ບໍ່ມີການເຄື່ອນໄຫວ, ຫຼືການປິດແອັບພລິເຄຊັນ. ປະຕິບັດການປົກປ້ອງຜົນບັງຄັບໃຊ້ brute ສໍາລັບການຢັ້ງຢືນ. ປະຕິບັດກົນໄກການກວດສອບຄວາມຖືກຕ້ອງຂອງທຸລະກໍາ.

10

AUTHN-BP01
ການຄວບຄຸມ
ແອັບໃຊ້ການພິສູດຢືນຢັນຕົວຕົນຫຼາຍປັດໃຈ (MFA) ເພື່ອພິສູດຢືນຢັນທຸລະກຳທີ່ມີຄວາມສ່ຽງສູງ.
ລາຍລະອຽດ
ໃນລະບົບການພິສູດຢືນຢັນແບບປັດໃຈດຽວແບບດັ້ງເດີມ, ໂດຍທົ່ວໄປແລ້ວຜູ້ໃຊ້ພຽງແຕ່ຕ້ອງການປ້ອນ Something-YouKnow1 ເຊັ່ນຊື່ຜູ້ໃຊ້ ແລະລະຫັດຜ່ານ. ຢ່າງໃດກໍຕາມ, ຖ້າປັດໃຈດຽວນີ້ລົ້ມເຫລວຫຼືຖືກທໍາລາຍ, ຂະບວນການກວດສອບຄວາມຖືກຕ້ອງທັງຫມົດແມ່ນມີຄວາມສ່ຽງຕໍ່ການຂົ່ມຂູ່.
MFA ແມ່ນຂັ້ນຕອນການຢັ້ງຢືນຕົວຕົນທີ່ເພີ່ມຂັ້ນຕອນການຢັ້ງຢືນຕົວຕົນ, ຮຽກຮ້ອງໃຫ້ບໍ່ພຽງແຕ່ບາງສິ່ງບາງຢ່າງ-ເຈົ້າ-ຮູ້, ແຕ່ຍັງບາງສິ່ງບາງຢ່າງ-ເຈົ້າ-ມີ2 ແລະບາງສິ່ງບາງຢ່າງ-You-Are3. ການປະຕິບັດ MFA ເຮັດໃຫ້ມັນທ້າທາຍຫຼາຍສໍາລັບນັກສະແດງທີ່ເປັນອັນຕະລາຍໃນການປະນີປະນອມບັນຊີແລະເສີມຂະຫຍາຍຄວາມປອດໄພໂດຍລວມຂອງຂະບວນການກວດສອບ.
ຄຳແນະນຳການຈັດຕັ້ງປະຕິບັດ
ນັກພັດທະນາຄວນໃຊ້ Step-up MFA. ມັນເປັນປະເພດສະເພາະຂອງ MFA ທີ່ແອັບຯລວມເອົາຍຸດທະສາດການພິສູດຢືນຢັນທີ່ຕ້ອງການລະດັບການກວດສອບເພີ່ມເຕີມ, ໂດຍສະເພາະໃນເວລາທີ່ພະຍາຍາມເຮັດທຸລະກໍາທີ່ມີຄວາມສ່ຽງສູງ.
ນັກພັດທະນາຄວນຈັດລໍາດັບຄວາມສໍາຄັນຂອງການປະສົມປະສານ MFA ຕໍ່ໄປນີ້ໃນລໍາດັບ 1, 2, 3, ແລະ 4, ໂດຍມີທາງເລືອກ 1 ເປັນທາງເລືອກທີ່ປອດໄພທີ່ສຸດ.

ປັດໄຈ / ທາງເລືອກ Something-You-Know Something-You-Have
· ຊອບ​ແວ token · Hardware token · SMS OTP Something-You-Are

1

2

3

4

1 Something-You-Know ຫມາຍເຖິງຂໍ້ມູນທີ່ຜູ້ໃຊ້ຮູ້, ເຊັ່ນ PIN (ເລກປະຈໍາຕົວ), ລະຫັດຜ່ານ, ຫຼືຮູບແບບ, ແລະອື່ນໆ. 2 Something-You-Have ຫມາຍເຖິງການຄອບຄອງຂອງອຸປະກອນທາງດ້ານຮ່າງກາຍ, app, ຫຼື token ທີ່. ສ້າງຂໍ້ມູນການຮັບຮອງຄວາມຖືກຕ້ອງ, ເຊິ່ງອາດຈະລວມເອົາລະຫັດຜ່ານຄັ້ງດຽວ (OTPs). ຕົວຢ່າງamples ຂອງ tokens ດັ່ງກ່າວປະກອບມີ tokens ຊອບແວ, tokens ຮາດແວ, ແລະ SMS OTP. 3 Something-You-Are ຫມາຍເຖິງຕົວລະບຸທາງຊີວະມິຕິ, ເຊິ່ງລັກສະນະທາງກາຍະພາບທີ່ເປັນເອກະລັກຂອງຜູ້ໃຊ້ໄດ້ຖືກນໍາໃຊ້ສໍາລັບການຢັ້ງຢືນເຊັ່ນ: ລາຍນິ້ວມື, ການສະແກນ retina, ການຮັບຮູ້ໃບຫນ້າ, ຫຼືການຮັບຮູ້ສຽງ.
11

ນັກພັດທະນາໄດ້ຖືກແນະນໍາຢ່າງແຂງແຮງບໍ່ໃຫ້ອີງໃສ່ SMS ແລະອີເມລ໌ OTP ເປັນຊ່ອງທາງສໍາລັບການກວດສອບຄວາມຖືກຕ້ອງສໍາລັບທຸລະກໍາທີ່ມີຄວາມສ່ຽງສູງ. ຖ້າບໍ່ສາມາດເຮັດໄດ້, ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະປະຕິບັດປັດໄຈທາງຊີວະພາບຫຼືປັດໃຈການກວດສອບເພີ່ມເຕີມໂດຍສົມທົບກັບ SMS OTP ແລະອີເມລ໌ OTP. ສິ່ງທີ່ຄວນສັງເກດ
· ແນະນຳໃຫ້ເລືອກວິທີແກ້ໄຂນອກຊັ້ນວາງເມື່ອເປັນໄປໄດ້. · ນັກພັດທະນາຄວນຮັບປະກັນວ່າຢ່າງໜ້ອຍໜຶ່ງປັດໄຈ MFA ໄດ້ຖືກກວດສອບຢູ່ຝ່າຍລູກຄ້າ, ກັບທັງໝົດ
ຄົນອື່ນຢັ້ງຢືນຢູ່ຂ້າງເຊີບເວີ. ໃນກໍລະນີທີ່ການກວດສອບຄວາມຖືກຕ້ອງຖືກກວດສອບຢູ່ຝ່າຍລູກຄ້າ, ໂດຍສະເພາະສໍາລັບ Android, ບັງຄັບໃຊ້ລະຫັດທີ່ອີງໃສ່ສະພາບແວດລ້ອມການປະຕິບັດທີ່ເຊື່ອຖືໄດ້ (TEE). ·ການຄວບຄຸມຄວາມປອດໄພນີ້ແມ່ນອ້າງອີງຢູ່ໃນມາດຕະຖານອື່ນໆ. ກະລຸນາເບິ່ງເອກະສານທີ່ລະບຸໄວ້ໃນ:
o OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), pg. 21.
o OWASP Mobile Application Security Guide Testing Guide (MASTG) v1.7.0 (2023), pg. 51, 56. o ຄຳແນະນຳການຄຸ້ມຄອງຄວາມສ່ຽງທາງດ້ານເຕັກໂນໂລຊີ MAS (2021), ໜ້າ. 34, 50. o ENISA Smartphone Secure Development Guidelines (2016), pg. 11.
12

ການ​ຄວບ​ຄຸມ AUTHN-BP01a app ໄດ້​ປະ​ຕິ​ບັດ​ບາງ​ສິ່ງ​ບາງ​ຢ່າງ​ທີ່​ທ່ານ​ຮູ້​ການ​ກວດ​ສອບ​ເປັນ​ຫນຶ່ງ​ໃນ​ປັດ​ໄຈ MFA​. ລາຍລະອຽດ Something-You-Know ເປັນຕົວແທນຂອງຂັ້ນຕອນພື້ນຖານຂອງການຢັ້ງຢືນຕົວຕົນທີ່ກ່ຽວຂ້ອງກັບຂໍ້ມູນທີ່ຮູ້ຈັກກັບຜູ້ໃຊ້ເທົ່ານັ້ນ, ເຊັ່ນ PIN (ໝາຍເລກປະຈໍາຕົວສ່ວນບຸກຄົນ), ລະຫັດຜ່ານ, ຮູບແບບ, ແລະອື່ນໆ. ການປະຕິບັດບາງສິ່ງບາງຢ່າງທີ່ທ່ານຮູ້ເປັນຫນຶ່ງໃນປັດໃຈ MFA ຮັບປະກັນ. ລະດັບພື້ນຖານຂອງການຢັ້ງຢືນຕົວຕົນໂດຍຮຽກຮ້ອງໃຫ້ຜູ້ໃຊ້ສະຫນອງຂໍ້ມູນທີ່ເປັນເອກະລັກທີ່ກ່ຽວຂ້ອງກັບບັນຊີຂອງເຂົາເຈົ້າ. ມັນ​ເປັນ​ປັດ​ໄຈ​ທີ່​ສໍາ​ຄັນ​ໃນ​ຫຼັກ​ການ​ຂອງ "ບາງ​ສິ່ງ​ບາງ​ຢ່າງ​ທີ່​ທ່ານ​ຮູ້​, ບາງ​ສິ່ງ​ບາງ​ຢ່າງ​ທ່ານ​ມີ​, ແລະ​ບາງ​ສິ່ງ​ບາງ​ຢ່າງ​ທ່ານ​ແມ່ນ​,​" ການ​ປະ​ກອບ​ສ່ວນ​ເຂົ້າ​ໃນ​ຍຸດ​ທະ​ສາດ​ຄວາມ​ປອດ​ໄພ​ຫຼາຍ​ຊັ້ນ​ທີ່​ສົມ​ບູນ​ແບບ​ແລະ​ປະ​ສິດ​ທິ​ຜົນ​. ຂໍ້ແນະນຳການຈັດຕັ້ງປະຕິບັດ ນັກພັດທະນາຄວນຮັບຮອງເອົາຂໍ້ແນະນຳຕໍ່ໄປນີ້ໃນການສ້າງລະຫັດຜ່ານທີ່ແຂງແຮງ ແລະ ປອດໄພ:
· ຮັບປະກັນຄວາມຍາວຂອງລະຫັດຜ່ານຕໍາ່ສຸດທີ່ 12 ຕົວອັກສອນ ຫຼືຫຼາຍກວ່ານັ້ນ. ·ລວມເອົາຕົວພິມໃຫຍ່ແລະຕົວພິມນ້ອຍ, ຕົວເລກ, ແລະຕົວອັກສອນພິເສດທີ່ຈໍາກັດ
~`! @#$%^&*()_-+=:;,.? ນັກພັດທະນາຄວນຮັບຮູ້ ແລະຫຼີກລ່ຽງບັນຫາທົ່ວໄປໃນການສ້າງລະຫັດຜ່ານ:
· ຫຼີກເວັ້ນການໃຊ້ຄໍາທີ່ຄາດເດົາໄດ້, ປະໂຫຍກ, ຫຼືການປະສົມປະສານ. · ຫຼີກລ່ຽງການລວມເອົາລາຍລະອຽດສ່ວນຕົວ. · ຊີ້ບອກຕົວອັກສອນຕາມລຳດັບ (ຕົວຢ່າງ: “123456”) ຫຼືຕົວອັກສອນຊ້ຳໆ (ຕົວຢ່າງ: “aaaaa”). ສິ່ງທີ່ຄວນສັງເກດ · ນັກພັດທະນາຄວນບັງຄັບໃຊ້ການຫມຸນຂໍ້ມູນປະຈໍາຕົວຢູ່ໃນຊັບສິນຂອງອົງກອນເທົ່ານັ້ນ ຫຼືຖ້າບໍ່ມີ
ການປະຕິບັດ MFA ໃນທ້າຍຜູ້ໃຊ້, ຕົວຢ່າງ: ມີການປ່ຽນແປງປະຈໍາປີຫຼືຕາມໄລຍະເວລາທີ່ເຫມາະສົມ. ·ການຄວບຄຸມຄວາມປອດໄພນີ້ແມ່ນອ້າງອີງຢູ່ໃນມາດຕະຖານອື່ນໆ. ກະ​ລຸ​ນາ​ເບິ່ງ​ເອ​ກະ​ສານ
ສະໜອງໃຫ້ຢູ່ໃນ: o ຂໍ້ແນະນຳການຄຸ້ມຄອງຄວາມສ່ຽງດ້ານເຕັກໂນໂລຊີ MAS (2021), ໜ້າ. 34. o ENISA Smartphone Secure Development Guidelines (2016), pg. 10.
13

ການ​ຄວບ​ຄຸມ AUTHN-BP01b app ໄດ້​ປະ​ຕິ​ບັດ​ບາງ​ສິ່ງ​ບາງ​ຢ່າງ​, ທ່ານ​, ມີ​ການ​ກວດ​ສອບ​ເປັນ​ຫນຶ່ງ​ໃນ​ປັດ​ໄຈ MFA​. ລາຍ​ລະ​ອຽດ Something-You-have ຮຽກ​ຮ້ອງ​ໃຫ້​ຜູ້​ໃຊ້​ຕ້ອງ​ການ​ກວດ​ສອບ​ກັບ​ອຸ​ປະ​ກອນ​ທາງ​ດ້ານ​ຮ່າງ​ກາຍ, app, ຫຼື token ທີ່​ສ້າງ​ການ​ຢັ້ງ​ຢືນ​ການ​ຮັບ​ຮອງ, ເຊິ່ງ​ອາດ​ຈະ​ລວມ​ມີ​ລະ​ຫັດ​ຜ່ານ​ທີ່​ໃຊ້​ເວ​ລາ​ດຽວ (OTPs). ຕົວຢ່າງamples ຂອງ tokens ດັ່ງກ່າວປະກອບມີ tokens ຊອບແວ, tokens ຮາດແວ, ແລະ SMS OTP. ການປະຕິບັດບາງສິ່ງບາງຢ່າງ-ເຈົ້າ-ມີ ເປັນຫນຶ່ງໃນປັດໃຈ MFA ເພີ່ມຄວາມສັບສົນໃນຂະບວນການກວດສອບໂດຍການຮຽກຮ້ອງໃຫ້ມີການຄອບຄອງຂອງອົງປະກອບທີ່ເຫັນໄດ້ຊັດ, ຫຼຸດລົງຢ່າງຫຼວງຫຼາຍຄວາມເປັນໄປໄດ້ຂອງການເຂົ້າເຖິງທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດ. ມັນ​ເປັນ​ປັດ​ໄຈ​ທີ່​ສໍາ​ຄັນ​ໃນ​ຫຼັກ​ການ​ຂອງ “ບາງ​ສິ່ງ​ບາງ​ຢ່າງ​ທີ່​ທ່ານ​-​ຮູ້​, ບາງ​ສິ່ງ​ບາງ​ຢ່າງ​ທ່ານ​ມີ​, ແລະ​ບາງ​ສິ່ງ​ບາງ​ຢ່າງ​ທ່ານ​ແມ່ນ​,” ການ​ປະ​ກອບ​ສ່ວນ​ເຂົ້າ​ໃນ​ຍຸດ​ທະ​ສາດ​ຄວາມ​ປອດ​ໄພ​ຫຼາຍ​ຊັ້ນ​ທີ່​ສົມ​ບູນ​ແບບ​ແລະ​ປະ​ສິດ​ທິ​ຜົນ​. ຄຳແນະນຳການຈັດຕັ້ງປະຕິບັດ ນັກພັດທະນາຄວນໃຊ້ OTP ໂດຍອີງໃສ່ເວລາສຳລັບຊອບແວ tokens, hardware tokens ແລະ SMS OTP. ຄວນປະຕິບັດຕາມຄໍາແນະນໍາຕໍ່ໄປນີ້:
· OTP ຄວນໃຊ້ໄດ້ບໍ່ເກີນ 30s ເທົ່ານັ້ນ. · OTP ທີ່ຖືກປ້ອນບໍ່ຖືກຕ້ອງຫຼັງຈາກ 3 ຄວາມພະຍາຍາມຄວນຈະບໍ່ຖືກຕ້ອງ, ແລະເຊດຊັນຂອງຜູ້ໃຊ້
ຄວນຈະຖືກຖອນ ຫຼືປະຕິເສດ. ສິ່ງທີ່ຄວນສັງເກດ
·ການຄວບຄຸມຄວາມປອດໄພນີ້ແມ່ນອ້າງອີງຢູ່ໃນມາດຕະຖານອື່ນໆ. ກະລຸນາເບິ່ງເອກະສານທີ່ລະບຸໄວ້ໃນ: o OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 56-57. o ຄຳແນະນຳການຄຸ້ມຄອງຄວາມສ່ຽງດ້ານເຕັກໂນໂລຊີ MAS (2021), ໜ້າ. 50, 51. o ENISA Smartphone Secure Development Guidelines (2016), pg. 10.
14

AUTHN-BP01c
ການຄວບຄຸມແອັບຯປະຕິບັດການພິສູດຢືນຢັນບາງສິ່ງບາງຢ່າງ - ເຈົ້າເປັນອັນນຶ່ງໃນປັດໃຈ MFA.
ລາຍ​ລະ​ອຽດ Something-You-Are ຮຽກ​ຮ້ອງ​ໃຫ້​ຜູ້​ໃຊ້​ຕ້ອງ​ການ​ກວດ​ສອບ​ດ້ວຍ​ຕົວ​ລະ​ບຸ biometric ເຊັ່ນ​: ລາຍ​ນີ້ວ​ມື​, ການ​ສະ​ແກນ retina​, ຫຼື​ການ​ຈົດ​ຈໍາ​ໃບ​ຫນ້າ​. ການປະຕິບັດບາງສິ່ງບາງຢ່າງ-ເຈົ້າ-ແມ່ນເປັນໜຶ່ງໃນປັດໃຈ MFA ເພີ່ມປັດໄຈການພິສູດຄວາມຖືກຕ້ອງທີ່ເປັນແບບສ່ວນຕົວ ແລະຍາກທີ່ຈະເຮັດຊ້ຳ. ມັນສະຫນອງວິທີການທີ່ເຂັ້ມແຂງກວ່າໃນການກວດສອບຕົວຕົນຂອງຜູ້ໃຊ້ຫຼາຍກ່ວາປັດໄຈ Something-You-Know ແລະ Something-You-have, ຫຼຸດຜ່ອນຄວາມສ່ຽງຂອງການເຂົ້າເຖິງທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດ. ມັນ​ເປັນ​ປັດ​ໄຈ​ທີ່​ສໍາ​ຄັນ​ໃນ​ຫຼັກ​ການ​ຂອງ "ບາງ​ສິ່ງ​ບາງ​ຢ່າງ​ທີ່​ທ່ານ​ຮູ້​, ບາງ​ສິ່ງ​ບາງ​ຢ່າງ​ທ່ານ​ມີ​, ແລະ​ບາງ​ສິ່ງ​ບາງ​ຢ່າງ​ທີ່​ທ່ານ​ມີ​,​" ການ​ປະ​ກອບ​ສ່ວນ​ກັບ​ຍຸດ​ທະ​ສາດ​ຄວາມ​ປອດ​ໄພ​ຫຼາຍ​ຊັ້ນ​ທີ່​ສົມ​ບູນ​ແບບ​ແລະ​ປະ​ສິດ​ທິ​ຜົນ​. ຄຳແນະນຳການຈັດຕັ້ງປະຕິບັດ ນັກພັດທະນາຄວນປະຕິບັດການພິສູດຢືນຢັນທາງຊີວະມິຕິທາງຂ້າງເຊີບເວີໂດຍໃຊ້ແພລະຕະຟອມການລະບຸຕົວຕົນທາງຊີວະພາບທີ່ເຊື່ອຖືໄດ້ເຊັ່ນ Singpass. ແນວໃດກໍ່ຕາມ, ຖ້າມັນບໍ່ເປັນໄປໄດ້, ນັກພັດທະນາຄວນປະຕິບັດການພິສູດຢືນຢັນທາງຊີວະມິຕິຂອງຝ່າຍລູກຄ້າຜ່ານກົນໄກການປະຕິບັດຄວາມເຊື່ອຖື (TEEs) ຂອງອຸປະກອນເຊັ່ນ CryptoObject ແລະ Android Protected Confirmation ສໍາລັບການບໍລິການ Android ຫຼື Keychain ສໍາລັບ iOS. ສິ່ງທີ່ຄວນສັງເກດ
· ຜູ້ພັດທະນາຄວນຈຳກັດການເຮັດວຽກຂອງແອັບຯໃນອຸປະກອນທີ່ຂາດຮາດແວ Trusted Executed Environment (TEE) ຫຼື biometrics. ຕົວຢ່າງampດັ່ງນັ້ນ, ອຸປະກອນ Android ທີ່ຂາດ TEE ສາມາດກວດພົບໄດ້ໂດຍໃຊ້ “isInsideSecureHardware” Android API.
· ນັກພັດທະນາຄວນຍົກເລີກການພິສູດຢືນຢັນທາງຊີວະມິຕິ ຖ້າມີການປ່ຽນແປງໃນກົນໄກທາງຊີວະມິຕິ ເຊັ່ນ: ການລົງທະບຽນລາຍນິ້ວມືໃໝ່ໃນອຸປະກອນ. ທັງສອງແພລະຕະຟອມ iOS ແລະ Android ສະຫນັບສະຫນູນການຕັ້ງລະຫັດ crypto app ທີ່ຈະຫມົດອາຍຸໃນການຕອບສະຫນອງຕໍ່ການປ່ຽນແປງດັ່ງກ່າວ.
·ການຄວບຄຸມຄວາມປອດໄພນີ້ແມ່ນອ້າງອີງຢູ່ໃນມາດຕະຖານອື່ນໆ. ກະລຸນາເບິ່ງເອກະສານທີ່ລະບຸໄວ້ໃນ: o OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 227233, 422-426. o ຄຳແນະນຳການຄຸ້ມຄອງຄວາມສ່ຽງດ້ານເຕັກໂນໂລຊີ MAS (2021), ໜ້າ. 51. o ENISA Smartphone Secure Development Guidelines (2016), pg. ໑໑, ໒໖.
15

AUTHN-BP02
ການຄວບຄຸມແອັບໃຊ້ປັດໄຈທີ່ອີງໃສ່ບໍລິບົດເພື່ອພິສູດຢືນຢັນ. ລາຍລະອຽດຂອງປັດໃຈທີ່ອີງໃສ່ບໍລິບົດແນະນໍາອົງປະກອບແບບເຄື່ອນໄຫວເຊັ່ນ: ສະຖານທີ່ຂອງຜູ້ໃຊ້ ແລະຄຸນລັກສະນະຂອງອຸປະກອນ. ໃນຂະນະທີ່ MFA ສະຫນອງຊັ້ນຄວາມປອດໄພທີ່ເຂັ້ມແຂງໂດຍການຮຽກຮ້ອງໃຫ້ມີປັດໃຈການກວດສອບຫຼາຍ, ການລວມເອົາປັດໃຈທີ່ອີງໃສ່ບໍລິບົດສ້າງຂະບວນການກວດສອບທີ່ສົມບູນແບບແລະດັດແປງທີ່ສາມາດສະເຫນີຜົນປະໂຫຍດເພີ່ມເຕີມໃນການແກ້ໄຂຄວາມສ່ຽງຕໍ່ການພັດທະນາຂອງການເຂົ້າເຖິງທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດ. ການປະຕິບັດປັດໄຈທີ່ອີງໃສ່ບໍລິບົດຫຼຸດຜ່ອນການອີງໃສ່ຂໍ້ມູນປະຈໍາຕົວແບບຄົງທີ່, ເຮັດໃຫ້ມັນທ້າທາຍຫຼາຍສໍາລັບຜູ້ສະແດງທີ່ເປັນອັນຕະລາຍທີ່ຈະພະຍາຍາມເຂົ້າເຖິງໂດຍບໍ່ໄດ້ຮັບອະນຸຍາດ. ຄຳແນະນຳການຈັດຕັ້ງປະຕິບັດ ນັກພັດທະນາຄວນພິຈາລະນາປັດໄຈທາງບໍລິບົດຕໍ່ໄປນີ້ເພື່ອຢັ້ງຢືນຕົວຕົນຂອງຜູ້ໃຊ້:
· ສະຖານທີ່ຕັ້ງພູມສາດ: ອະນຸຍາດໃຫ້ເຂົ້າເຖິງໂດຍອີງໃສ່ສະຖານທີ່ໃນໂລກທີ່ແທ້ຈິງຂອງອຸປະກອນໂດຍໃຊ້ GPS, Wi-Fi, ຫຼືສະຖານທີ່ຕັ້ງພູມສາດທີ່ຢູ່ IP.
· ປະເພດອຸປະກອນ: ອະນຸຍາດໃຫ້ເຂົ້າເຖິງໂດຍອີງໃສ່ຄຸນລັກສະນະຂອງອຸປະກອນ. ຕົວຢ່າງ: ຂະຫນາດຫນ້າຈໍສາມາດກໍານົດວ່າອຸປະກອນເປັນໂທລະສັບສະຫຼາດຫຼືແທັບເລັດ.
ສິ່ງທີ່ຄວນສັງເກດການຄວບຄຸມຄວາມປອດໄພນີ້ແມ່ນອ້າງອີງຢູ່ໃນມາດຕະຖານອື່ນໆ. ກະລຸນາເບິ່ງເອກະສານທີ່ລະບຸໄວ້ໃນ:
· OWASP Mobile Application ຄູ່ມືການທົດສອບຄວາມປອດໄພ (MASTG) v1.7.0 (2023), ຫນ້າ. 56, 58. · ENISA Smartphone Secure Development Guidelines (2016), pg. 11.
16

AUTHN-BP03
ຄວບຄຸມແອັບປະຕິບັດການພິສູດຢືນຢັນເຊດຊັນທີ່ປອດໄພ. ລາຍ​ລະ​ອຽດ​ການ​ກວດ​ສອບ​ເຊ​ສ​ຊັນ​ທີ່​ປອດ​ໄພ​ຮັບ​ປະ​ກັນ​ການ​ຄຸ້ມ​ຄອງ​ກອງ​ປະ​ຊຸມ​ທີ່​ເຂັ້ມ​ແຂງ​ສໍາ​ລັບ​ການ​ກວດ​ສອບ​ທັງ stateful ແລະ stateless​. ເຊດຊັນທີ່ມີການຈັດການບໍ່ດີ, ໂດຍບໍ່ຄໍານຶງເຖິງວ່າແອັບຯຈະປະຕິບັດຕາມວິທີການກວດສອບ stateful4 ຫຼື stateless5, ສາມາດນໍາໄປສູ່ໄພຂົ່ມຂູ່ດ້ານຄວາມປອດໄພເຊັ່ນ: ການເຂົ້າເຖິງທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດ, ການລັກເຊດຊັນ, ຫຼືການລະເມີດຂໍ້ມູນ. ການປະຕິບັດການກວດສອບເຊດຊັນທີ່ປອດໄພສໍາລັບເຊດຊັນທີ່ມີສະຖານະໃຊ້ຕົວລະບຸເຊດຊັນທີ່ປອດໄພ, ການສື່ສານທີ່ຖືກເຂົ້າລະຫັດແລະການຫມົດເວລາທີ່ເຫມາະສົມເພື່ອປ້ອງກັນການເຂົ້າເຖິງທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດ. ສໍາລັບການພິສູດຢືນຢັນທີ່ບໍ່ມີລັດ, ມັນຮັບປະກັນວ່າ tokens ແມ່ນ tamper-resistant, ຮັກສາຄວາມຖືກຕ້ອງຂອງຄວາມຖືກຕ້ອງໂດຍບໍ່ມີການອີງໃສ່ການເກັບຮັກສາຂ້າງເຄື່ອງແມ່ຂ່າຍ. ຄຳແນະນຳການຈັດຕັ້ງປະຕິບັດ ນັກພັດທະນາຄວນປະຕິບັດການພິສູດຢືນຢັນຂອງເຊດຊັນທີ່ປອດໄພໂດຍການໃຊ້ວິທີປະຕິບັດທີ່ດີທີ່ສຸດຕໍ່ໄປນີ້ສຳລັບວິທີການກວດສອບສະຖານະ (AUTHN-BP03a) ແລະບໍ່ມີລັດ (AUTHN-BP03b) ສຳລັບເຊດຊັນ. ສິ່ງທີ່ຄວນສັງເກດການຄວບຄຸມຄວາມປອດໄພນີ້ແມ່ນອ້າງອີງຢູ່ໃນມາດຕະຖານອື່ນໆ. ກະລຸນາເບິ່ງເອກະສານທີ່ລະບຸໄວ້ໃນ:
· OWASP Mobile Application ຄູ່ມືການທົດສອບຄວາມປອດໄພ (MASTG) v1.7.0 (2023), ຫນ້າ. 51-55. · ຄູ່ມືການຄຸ້ມຄອງຄວາມສ່ຽງດ້ານເຕັກໂນໂລຊີ MAS (2021), ໜ້າ. 51. · ENISA Smartphone Secure Development Guidelines (2016), pg. 10.
4 ການກວດສອບຄວາມຖືກຕ້ອງໝາຍເຖິງການຈັດການສະຖານະຂອງເຊດຊັນຢູ່ຂ້າງເຊີບເວີ, ໂດຍປົກກະຕິຈະຕ້ອງໃຊ້ຕົວລະບຸເຊດຊັນ. 5 ການພິສູດຢືນຢັນແບບບໍ່ມີລັດໝາຍເຖິງການຈັດການເຊສຊັນໂດຍບໍ່ເກັບຂໍ້ມູນທີ່ກ່ຽວຂ້ອງກັບຜູ້ໃຊ້ຢູ່ຂ້າງເຊີບເວີ.
17

ການ​ຄວບ​ຄຸມ AUTHN-BP03a app ໄດ້​ປະ​ຕິ​ບັດ​ການ​ກວດ​ສອບ​ສະ​ຖາ​ນະ​ພາບ​ທີ່​ປອດ​ໄພ​. ລາຍ​ລະ​ອຽດ​ການ​ຮັບ​ຮອງ​ຄວາມ​ປອດ​ໄພ​ຂອງ​ລັດ​ກ່ຽວ​ຂ້ອງ​ກັບ​ການ​ປົກ​ປັກ​ຮັກ​ສາ​ແລະ​ການ​ຮັກ​ສາ​ກອງ​ປະ​ຊຸມ​ຕໍ່​ເນື່ອງ​. ໃນຂະນະທີ່ການພິສູດຢືນຢັນແບບສະຖາປະນິກໃຫ້ປະສົບການຂອງຜູ້ໃຊ້ທີ່ບໍ່ມີຮອຍຕໍ່ຜ່ານເຊດຊັນຜູ້ໃຊ້ຢ່າງຕໍ່ເນື່ອງ, ມັນສາມາດມີຄວາມສ່ຽງຕໍ່ໄພຂົ່ມຂູ່ດ້ານຄວາມປອດໄພຕ່າງໆ, ເຊັ່ນ: ຜູ້ກະທຳທີ່ເປັນອັນຕະລາຍພະຍາຍາມລັກເອົາຕົວລະບຸເຊດຊັນ. ການປະຕິບັດການກວດສອບຄວາມຖືກຕ້ອງທີ່ປອດໄພຈະປົກປ້ອງບັນຊີຜູ້ໃຊ້ຈາກການເຂົ້າເຖິງທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດແລະຊ່ອງໂຫວ່ທີ່ອາດຈະກ່ຽວຂ້ອງກັບການຈັດການເຊດຊັນໂດຍບໍ່ມີການທໍາລາຍຄວາມສົມດູນລະຫວ່າງການນໍາໃຊ້ແລະຄວາມປອດໄພ. ຄຳແນະນຳການຈັດຕັ້ງປະຕິບັດ ນັກພັດທະນາຄວນລະບຸຈຸດສິ້ນສຸດຂອງເຊີບເວີທີ່ເປີດເຜີຍຂໍ້ມູນລະອຽດອ່ອນ ຫຼື ໜ້າທີ່ສຳຄັນ. ນັກພັດທະນາຄວນຮັບຮອງເອົາການປະຕິບັດທີ່ດີທີ່ສຸດຂອງການຮັບຮອງເຊດຊັນທີ່ມີສະຖານະດັ່ງຕໍ່ໄປນີ້:
· ປະຕິເສດຄຳຮ້ອງຂໍທີ່ມີ ID ເຊດຊັນ ຫຼືໂທເຄັນທີ່ຂາດຫາຍໄປ ຫຼືບໍ່ຖືກຕ້ອງ. · ສ້າງ Session IDs ແບບສຸ່ມຢູ່ຂ້າງເຊີບເວີໂດຍບໍ່ຕ້ອງເພີ່ມພວກມັນໃສ່ URLs. · ປັບປຸງຄວາມປອດໄພ Session IDs ທີ່ມີຄວາມຍາວ ແລະ entropy ທີ່ເຫມາະສົມ, ເຮັດໃຫ້ການຄາດເດົາຍາກ. · Exchange Session IDs ພຽງແຕ່ຜ່ານການເຊື່ອມຕໍ່ HTTPS ທີ່ປອດໄພເທົ່ານັ້ນ. · ຫຼີກເວັ້ນການເກັບຮັກສາ Session ID ຢູ່ໃນບ່ອນເກັບຂໍ້ມູນຄົງທີ່. · ກວດ​ສອບ ID ເຊດ​ຊັນ​ສໍາ​ລັບ​ການ​ເຂົ້າ​ເຖິງ​ຜູ້​ໃຊ້​ກັບ​ອົງ​ປະ​ກອບ app ສິດ​ທິ​ພິ​ເສດ​. · ຢຸດເຊດຊັນຢູ່ຂ້າງເຊີບເວີ, ການລຶບຂໍ້ມູນເຊດຊັນເມື່ອໝົດເວລາ ຫຼືອອກຈາກລະບົບ. ສິ່ງທີ່ຄວນສັງເກດ ຖ້າສົງໃສ, ພິຈາລະນາໃຊ້ແພລະຕະຟອມການພິສູດຢືນຢັນທີ່ເຊື່ອຖືໄດ້ ແລະໂປໂຕຄອນ. ການຄວບຄຸມຄວາມປອດໄພນີ້ແມ່ນອ້າງອີງຢູ່ໃນມາດຕະຖານອື່ນໆ. ກະລຸນາເບິ່ງເອກະສານທີ່ລະບຸໄວ້ໃນ: · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 52.
18

ການ​ຄວບ​ຄຸມ AUTHN-BP03b app ການ​ປະ​ຕິ​ບັດ​ການ​ຮັບ​ຮອງ​ຄວາມ​ປອດ​ໄພ stateless​. ລາຍ​ລະ​ອຽດ​ການ​ກວດ​ສອບ​ຄວາມ​ປອດ​ໄພ stateless ມີ​ການ​ປະ​ຕິ​ບັດ token ທີ່​ປອດ​ໄພ​ສໍາ​ລັບ​ການ​ຮັບ​ຮອງ​ປະ​ສິດ​ທິ​ຜົນ​ແລະ​ຂະ​ຫຍາຍ​ຕົວ​ໄດ້​. ໃນຂະນະທີ່ການພິສູດຢືນຢັນແບບບໍ່ມີລັດໃຫ້ຜົນປະໂຫຍດ, ມັນສາມາດມີຄວາມສ່ຽງຫຼາຍຕໍ່ກັບໄພຂົ່ມຂູ່ດ້ານຄວາມປອດໄພເຊັ່ນ: ການປອມຕົວຂອງຜູ້ໃຊ້ຖ້າ tokens ບໍ່ໄດ້ຖືກສ້າງ, ສົ່ງແລະເກັບຮັກສາໄວ້ຢ່າງປອດໄພ. ການປະຕິບັດການພິສູດຢືນຢັນທີ່ບໍ່ມີລັດທີ່ປອດໄພຮັບປະກັນວ່າແຕ່ລະ token ການພິສູດຢືນຢັນຖືກຈັດການຢ່າງປອດໄພໃນຂະນະທີ່ເກັບກ່ຽວຜົນປະໂຫຍດຂອງປະສິດທິພາບແລະຂະຫນາດ, ຫຼຸດຜ່ອນຄວາມສ່ຽງຂອງການເຂົ້າເຖິງທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດ. ຄຳແນະນຳການຈັດຕັ້ງປະຕິບັດ ນັກພັດທະນາຄວນຮັບຮອງເອົາການປະຕິບັດທີ່ດີທີ່ສຸດຂອງການພິສູດຢືນຢັນເຊດຊັນທີ່ບໍ່ມີລັດດັ່ງລຸ່ມນີ້:
·ສ້າງ tokens ຢູ່ໃນຂ້າງເຊີຟເວີໂດຍບໍ່ມີການເພີ່ມເຕີມໃຫ້ເຂົາເຈົ້າ URLs. ·ປັບປຸງຄວາມປອດໄພຂອງ tokens ທີ່ມີຄວາມຍາວທີ່ເຫມາະສົມແລະ entropy, ເຮັດໃຫ້ການຄາດເດົາມີຄວາມຫຍຸ້ງຍາກ. ·ແລກປ່ຽນໂທເຄັນຜ່ານການເຊື່ອມຕໍ່ HTTPS ທີ່ປອດໄພເທົ່ານັ້ນ. · ກວດ​ສອບ​ວ່າ​ບໍ່​ມີ​ຂໍ້​ມູນ​ທີ່​ລະ​ອຽດ​ອ່ອນ​ເຊັ່ນ PII ຝັງ​ຢູ່​ໃນ tokens​. ·ຫຼີກເວັ້ນການເກັບຮັກສາ tokens ຢູ່ໃນການເກັບຮັກສາຄົງທີ່. · ຢັ້ງຢືນ tokens ສໍາລັບການເຂົ້າເຖິງຜູ້ໃຊ້ກັບອົງປະກອບ app ສິດທິພິເສດ. · ຢຸດໂທເຄັນຢູ່ຂ້າງເຊີບເວີ, ການລຶບຂໍ້ມູນ tokens ເມື່ອໝົດເວລາ ຫຼືອອກຈາກລະບົບ. · Cryptographically signs ໂດຍໃຊ້ algorithm ທີ່ປອດໄພ, ຫຼີກເວັ້ນການໃຊ້ null algorithms. ສິ່ງທີ່ຄວນສັງເກດ · ຖ້າສົງໄສ, ໃຫ້ພິຈາລະນາໃຊ້ແພລະຕະຟອມການພິສູດຢືນຢັນທີ່ເຊື່ອຖືໄດ້ ແລະໂປໂຕຄອນ. ·ການຄວບຄຸມຄວາມປອດໄພນີ້ແມ່ນອ້າງອີງຢູ່ໃນມາດຕະຖານອື່ນໆ. ກະ​ລຸ​ນາ​ເບິ່ງ​ເອ​ກະ​ສານ
ສະໜອງໃຫ້ໃນ: o OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 52-53.
19

AUTHN-BP04
ຄວບຄຸມແອັບປະຕິບັດການປິດເຊດຊັນທີ່ປອດໄພໃນລະຫວ່າງການອອກຈາກລະບົບ, ບໍ່ມີການເຄື່ອນໄຫວ ຫຼືການປິດແອັບ. ລາຍ​ລະ​ອຽດ​ການ​ປິດ​ກອງ​ປະ​ຊຸມ​ທີ່​ປອດ​ໄພ​ຮັບ​ປະ​ກັນ​ການ​ປິດ​ປະ​ສິດ​ທິ​ຜົນ​ຂອງ​ກອງ​ປະ​ຊຸມ​ຜູ້​ໃຊ້​. ໃນສະຖານະການເຊັ່ນການອອກຈາກລະບົບ, ການບໍ່ມີການເຄື່ອນໄຫວ, ຫຼືສະຖານະການປິດແອັບຯ, ມີທ່າແຮງສໍາລັບຜູ້ສະແດງທີ່ເປັນອັນຕະລາຍທີ່ຈະຂູດຮີດຈຸດເຂົ້າເຖິງທີ່ຍັງຄ້າງຄາຖ້າເຊດຊັນບໍ່ໄດ້ຖືກຈັດການຢ່າງເຫມາະສົມ. ການປະຕິບັດການປິດເຊດຊັນທີ່ປອດໄພໃນລະຫວ່າງການອອກຈາກລະບົບ, ຄວາມບໍ່ເຄື່ອນໄຫວ ຫຼືການປິດແອັບຯ ສາມາດຫຼຸດຜ່ອນຄວາມສ່ຽງຂອງການເຂົ້າເຖິງທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດໄດ້ຢ່າງຫຼວງຫຼາຍ ໂດຍການປິດເຊດຊັນຂອງຜູ້ໃຊ້ໂດຍອັດຕະໂນມັດ ແລະປົກປ້ອງຂໍ້ມູນຜູ້ໃຊ້ຈາກການຖືກເຂົ້າເຖິງໂດຍພາກສ່ວນທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດ. ຄຳແນະນຳການຈັດຕັ້ງປະຕິບັດ ນັກພັດທະນາຄວນພິສູດຢືນຢັນຜູ້ໃຊ້ຄືນໃໝ່ຫຼັງຈາກອອກຈາກລະບົບ, ແອັບບໍ່ເຄື່ອນໄຫວ, ບໍ່ເຄື່ອນໄຫວ, ການຢູ່ເບື້ອງຫຼັງ, ການໝົດເວລາຂອງເຊດຊັນຢ່າງແທ້ຈິງ, ຫຼືປິດຢ່າງກະທັນຫັນ/ບັງຄັບ. ນັກພັດທະນາຄວນສ້າງຕົວລະບຸເຊດຊັນໃໝ່ໃນເຊີບເວີທຸກຄັ້ງທີ່ຜູ້ໃຊ້ເລື່ອນຂຶ້ນສູ່ລະດັບການພິສູດຢືນຢັນໃໝ່ເພື່ອປ້ອງກັນການແກ້ໄຂເຊດຊັນ. ສິ່ງທີ່ຄວນສັງເກດ
· ນັກພັດທະນາຄວນຮັບປະກັນວ່າການປິດເຊດຊັນລວມມີການລຶບລ້າງ ຫຼືການຍົກເລີກ tokens ທີ່ເກັບໄວ້ໃນເຄື່ອງທັງໝົດ ຫຼືຕົວລະບຸເຊດຊັນ.
· ນັກພັດທະນາຄວນກຳນົດມູນຄ່າການໝົດເວລາທີ່ບໍ່ເຮັດວຽກໂດຍອີງໃສ່ຄວາມສ່ຽງ ແລະລັກສະນະຂອງການບໍລິການທາງດ້ານການເງິນ.
·ການຄວບຄຸມຄວາມປອດໄພນີ້ແມ່ນອ້າງອີງຢູ່ໃນມາດຕະຖານອື່ນໆ. ກະລຸນາເບິ່ງເອກະສານທີ່ລະບຸໄວ້ໃນ: o OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 55-56, 58. o ຄຳແນະນຳການຄຸ້ມຄອງຄວາມສ່ຽງທາງດ້ານເຕັກໂນໂລຊີ MAS (2021), ໜ້າ. 51. o ENISA Smartphone Secure Development Guidelines (2016), pg. 11.
20

AUTHN-BP05
ການ​ຄວບ​ຄຸມ app ການ​ປະ​ຕິ​ບັດ​ການ​ປົກ​ປັກ​ຮັກ​ສາ​ຜົນ​ບັງ​ຄັບ​ໃຊ້ brute ສໍາ​ລັບ​ການ​ກວດ​ສອບ​. ລາຍ​ລະ​ອຽດ ການ​ໂຈມ​ຕີ​ໂດຍ​ບັງ​ຄັບ​ໃຊ້ Brute ມີ​ຄວາມ​ພະ​ຍາ​ຍາມ​ອັດ​ຕະ​ໂນ​ມັດ​ແລະ​ລະ​ບົບ​ທີ່​ຈະ​ເດົາ​ຂໍ້​ມູນ​ຂອງ​ຜູ້​ໃຊ້, ສໍາ​ລັບ​ການ example, ໂດຍ ການ ພະ ຍາ ຍາມ ປະ ສົມ ຕ່າງໆ ຂອງ ຊື່ ຜູ້ ໃຊ້ ແລະ ລະ ຫັດ ຜ່ານ ເພື່ອ ໃຫ້ ໄດ້ ຮັບ ການ ເຂົ້າ ເຖິງ ທີ່ ບໍ່ ອະ ນຸ ຍາດ. ການປົກປ້ອງຜົນບັງຄັບໃຊ້ Brute ຈໍາກັດຈໍານວນຄວາມພະຍາຍາມເຂົ້າສູ່ລະບົບພາຍໃນໄລຍະເວລາທີ່ກໍານົດໄວ້. ການປະຕິບັດການປົກປ້ອງຜົນບັງຄັບໃຊ້ brute ສໍາລັບການພິສູດຢືນຢັນຢ່າງຫຼວງຫຼາຍສາມາດຫຼຸດຜ່ອນຄວາມສ່ຽງຂອງການເຂົ້າເຖິງທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດ, ປົກປ້ອງບັນຊີຜູ້ໃຊ້ແລະຮັກສາຄວາມສົມບູນຂອງຂະບວນການກວດສອບ. ຄໍາແນະນໍາການຈັດຕັ້ງປະຕິບັດ ນັກພັດທະນາຄວນປະຕິບັດກົນໄກການບັງຄັບໃຊ້ brute ໂດຍຜ່ານການປະຕິບັດທີ່ດີທີ່ສຸດດັ່ງຕໍ່ໄປນີ້:
· ປະຕິບັດການກວດສອບການຕ້ານການອັດຕະໂນມັດ. · ນຳໃຊ້ການຈຳກັດອັດຕາສຳລັບຄວາມພະຍາຍາມເຂົ້າສູ່ລະບົບ. · ລວມເອົາຄວາມລ່າຊ້າເວລາເພີ່ມຂຶ້ນ (ເຊັ່ນ: 30 ວິນາທີ, 1 ນາທີ, 2 ນາທີ, 5
ນາທີ) ສໍາລັບຄວາມພະຍາຍາມເຂົ້າສູ່ລະບົບ. · ບັງຄັບໃຫ້ປິດບັນຊີ. ສິ່ງທີ່ຄວນສັງເກດ · ນັກພັດທະນາຄວນສັງເກດວ່າກົນໄກຂອງ MFA ທັງໝົດແມ່ນມີຄວາມສ່ຽງຕໍ່ການບັງຄັບໃຊ້ຢ່າງໂຫດຮ້າຍ. · ນັກພັດທະນາຄວນບອກເຫດຜົນຂອງການປິດບັນຊີ ແລະໃຫ້ວິທີການເຂົ້າເຖິງ
ສໍາລັບຜູ້ໃຊ້ເພື່ອພິສູດຕົວຕົນແລະເອົາການລັອກອອກ. ຕົວຢ່າງamples ລວມມີການໂທຫາສາຍດ່ວນຫຼືການນໍາໃຊ້ການຢັ້ງຢືນທາງຊີວະພາບ. ·ການຄວບຄຸມຄວາມປອດໄພນີ້ແມ່ນອ້າງອີງຢູ່ໃນມາດຕະຖານອື່ນໆ. ກະລຸນາເບິ່ງເອກະສານທີ່ລະບຸໄວ້ໃນ:
o ENISA Smartphone Secure Development Guidelines (2016), pg. ໑໐, ໑໖.
21

AUTHN-BP06
ຄວບຄຸມ app ປະຕິບັດກົນໄກການຢັ້ງຢືນຄວາມຖືກຕ້ອງຂອງທຸລະກໍາ. ຄໍາອະທິບາຍໃນຂະນະທີ່ການກວດສອບຄວາມຖືກຕ້ອງຮັບປະກັນຕົວຕົນຂອງຜູ້ໃຊ້, ມັນບໍ່ໄດ້ລົບລ້າງຄວາມເປັນໄປໄດ້ຂອງກິດຈະກໍາການສໍ້ໂກງໃນລະຫວ່າງຂະບວນການເຮັດທຸລະກໍາ. ກົນໄກການກວດສອບຄວາມຖືກຕ້ອງຂອງທຸລະກໍາແມ່ນຫນ້າທີ່ຄວາມປອດໄພຊ່ວຍທີ່ໃຫ້ເວລາແລະເຄື່ອງມືຂອງຜູ້ໃຊ້ເພື່ອຕອບສະຫນອງຕໍ່ການສໍ້ໂກງທີ່ເປັນໄປໄດ້. ການປະຕິບັດກົນໄກການກວດສອບຄວາມຖືກຕ້ອງຂອງທຸລະກໍາຮັບປະກັນວ່າແຕ່ລະທຸລະກໍາຜ່ານການກວດສອບຢ່າງລະອຽດເພື່ອຢືນຢັນຄວາມຖືກຕ້ອງແລະຄວາມຖືກຕ້ອງຂອງມັນ. ຄໍາແນະນໍາການຈັດຕັ້ງປະຕິບັດ ນັກພັດທະນາສາມາດປະຕິບັດການປະຕິບັດທີ່ດີທີ່ສຸດທີ່ແນະນໍາຕໍ່ໄປນີ້:
·​ເລີ່ມ​ຕົ້ນ​ການ​ຢືນ​ຢັນ​ການ​ເຮັດ​ທຸ​ລະ​ກໍາ / ໂທ​ການ​ຢືນ​ຢັນ​. ·ໃຫ້ປະຫວັດການເຮັດທຸລະກໍາໃນເວລາທີ່ແທ້ຈິງ. · ປະຕິບັດໄລຍະເວລາ cooldown 12 ຊົ່ວໂມງຫາ 24 ຊົ່ວໂມງ. ·ປິດການເຮັດທຸລະກໍາຢູ່ຕ່າງປະເທດໂດຍຄ່າເລີ່ມຕົ້ນ; ເປີດໃຊ້ພຽງແຕ່ຜ່ານ MFA. ສິ່ງທີ່ຄວນສັງເກດການຄວບຄຸມຄວາມປອດໄພນີ້ແມ່ນອ້າງອີງຢູ່ໃນມາດຕະຖານອື່ນໆ. ກະລຸນາເບິ່ງເອກະສານທີ່ລະບຸໄວ້ໃນ: · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 57-58.
22

23

2. ການອະນຸຍາດ

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

ID

ການຄວບຄຸມ

AUTHOR-BP01 ປະຕິບັດການອະນຸຍາດດ້ານເຊີບເວີ.

AUTHOR-BP02 ປະຕິບັດການອະນຸຍາດຝ່າຍລູກຄ້າໂດຍຜ່ານການຜູກມັດອຸປະກອນ.

AUTHOR-BP03 ແຈ້ງ​ໃຫ້​ຜູ້​ໃຊ້​ຂອງ​ການ​ອະ​ນຸ​ຍາດ​ທີ່​ຕ້ອງ​ການ​ທັງ​ຫມົດ​ກ່ອນ​ທີ່​ເຂົາ​ເຈົ້າ​ຈະ​ເລີ່ມ​ຕົ້ນ​ການ​ນໍາ​ໃຊ້ app ໄດ້​.

AUTHOR-BP04

ແຈ້ງຜູ້ໃຊ້ສໍາລັບທຸລະກໍາທີ່ມີຄວາມສ່ຽງສູງທັງຫມົດທີ່ໄດ້ຮັບອະນຸຍາດແລະສໍາເລັດ.

24

AUTHOR-BP01
ຄວບຄຸມແອັບປະຕິບັດການອະນຸຍາດດ້ານເຊີບເວີ. ຄໍາອະທິບາຍການອະນຸຍາດດ້ານເຊີບເວີຫມາຍເຖິງການກວດສອບແລະການໃຫ້ສິດການເຂົ້າເຖິງຜູ້ໃຊ້ຫຼືແອັບຯໂດຍເຄື່ອງແມ່ຂ່າຍຫຼືເຄື່ອງແມ່ຂ່າຍການອະນຸຍາດ. ນີ້ຮັບປະກັນວ່າການຕັດສິນໃຈຄວບຄຸມການເຂົ້າເຖິງແລະການອະນຸຍາດຖືກຄຸ້ມຄອງແລະບັງຄັບໃຊ້ໃນດ້ານເຊີຟເວີແທນທີ່ຈະເປັນລູກຄ້າ. ໂດຍການປະຕິບັດການອະນຸຍາດດ້ານເຊີຟເວີ, ນັກພັດທະນາຫຼຸດຜ່ອນໂອກາດສໍາລັບຜູ້ໂຈມຕີທີ່ເປັນອັນຕະລາຍຕໍ່ tamper ຫຼື bypass ມາດຕະການຄວາມປອດໄພໃນ app ເພື່ອເຂົ້າເຖິງຂໍ້ມູນທີ່ລະອຽດອ່ອນໂດຍບໍ່ໄດ້ຮັບອະນຸຍາດ (ເຊັ່ນ: PIIs ແລະຂໍ້ມູນການກວດສອບ). ຄໍາແນະນໍາການຈັດຕັ້ງປະຕິບັດ ນັກພັດທະນາຄວນປະຕິບັດການອະນຸຍາດດ້ານເຊີບເວີຫຼັງຈາກການກວດສອບສົບຜົນສໍາເລັດ, ກ່ອນທີ່ຈະໃຫ້ການອະນຸຍາດເຂົ້າເຖິງ. ຜູ້​ພັດ​ທະ​ນາ​ຄວນ​ຮັບ​ປະ​ກັນ​ວ່າ​ຜູ້​ໃຊ້​ໄດ້​ຮັບ​ການ​ເຂົ້າ​ເຖິງ​ໂດຍ​ອີງ​ໃສ່​ການ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:
· ພາລະບົດບາດທີ່ຖືກມອບຫມາຍດ້ວຍການອະນຸຍາດ: ໃຫ້ແນ່ໃຈວ່າຜູ້ໃຊ້ສາມາດປະຕິບັດວຽກງານທີ່ກ່ຽວຂ້ອງກັບຄວາມຮັບຜິດຊອບຂອງເຂົາເຈົ້າເທົ່ານັ້ນ.
· ປັດໄຈທາງບໍລິບົດ: ສະຖານະການເຂົ້າເຖິງແບບເຄື່ອນໄຫວເຊັ່ນ: ເວລາຂອງການເຂົ້າເຖິງ ແລະການວິເຄາະພຶດຕິກໍາ.
ສິ່ງທີ່ຄວນສັງເກດການຄວບຄຸມຄວາມປອດໄພນີ້ແມ່ນອ້າງອີງຢູ່ໃນມາດຕະຖານອື່ນໆ. ກະລຸນາເບິ່ງເອກະສານທີ່ລະບຸໄວ້ໃນ:
· OWASP Mobile Application ຄູ່ມືການທົດສອບຄວາມປອດໄພ (MASTG) v1.7.0 (2023), ຫນ້າ. 50-55, 58. · PCI Mobile Payment Acceptance Security Guidelines v2.0.0 (2017), pg. 10. · ENISA Smartphone Secure Development Guidelines (2016), pg. 10-11.
25

AUTHOR-BP02
ການຄວບຄຸມແອັບຯປະຕິບັດການອະນຸຍາດຝ່າຍລູກຄ້າໂດຍຜ່ານການຜູກມັດອຸປະກອນ.
ລາຍລະອຽດ
ການອະນຸຍາດຝ່າຍລູກຄ້າແມ່ນຂະບວນການຈັດການສິດການເຂົ້າເຖິງພາຍໃນແອັບຯມືຖື. ອັນນີ້ມີຄວາມສ່ຽງ ເນື່ອງຈາກການເພິ່ງພາອາໄສຝ່າຍລູກຄ້າສາມາດເປີດເຜີຍແອັບຕ່າງໆໄປສູ່ຊ່ອງໂຫວ່ຕ່າງໆ ເຊັ່ນ: ການເຂົ້າເຖິງທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດ ແລະການສໍ້ໂກງທີ່ອາດເປັນໄປໄດ້.
ຖ້າການເຮັດວຽກຂອງທຸລະກິດຂອງແອັບຯ (ເຊັ່ນ: ໂທເຄັນຊອຟແວທັນທີ) ຕ້ອງການການອະນຸຍາດຈາກຝ່າຍລູກຄ້າ, ການຜູກມັດອຸປະກອນ (ການປະຕິບັດດ້ານຄວາມປອດໄພທີ່ເຊື່ອມໂຍງສິດໃນການເຂົ້າເຖິງສິດທິພິເສດໃນອຸປະກອນສະເພາະ) ແມ່ນແນະນໍາ. ໂດຍ​ການ​ປະ​ຕິ​ບັດ​ການ​ຜູກ​ມັດ​ອຸ​ປະ​ກອນ​, ແອັບ​ສາ​ມາດ​ກວດ​ສອບ​ຕົວ​ຕົນ​ຂອງ​ອຸ​ປະ​ກອນ ແລະ​ສ້າງ​ຄວາມ​ເຊື່ອ​ຖື​ໄດ້. ອັນນີ້ຊ່ວຍຫຼຸດຜ່ອນຄວາມສ່ຽງທີ່ກ່ຽວຂ້ອງກັບການເຂົ້າເຖິງທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດ ແລະຮັກສາເສັ້ນທາງທີ່ປອດໄພ ແລະເຊື່ອຖືໄດ້ລະຫວ່າງອຸປະກອນ, ແອັບ ແລະເຊີບເວີ.
ຄຳແນະນຳການຈັດຕັ້ງປະຕິບັດ
ຜູ້ພັດທະນາຄວນສ້າງການຜູກມັດລະຫວ່າງແອັບຯ ແລະອຸປະກອນ ເມື່ອຕົວຕົນຂອງຜູ້ໃຊ້ຖືກໃຊ້ເປັນຄັ້ງທຳອິດໃນອຸປະກອນມືຖືທີ່ບໍ່ໄດ້ລົງທະບຽນ.
ຜູ້ພັດທະນາຄວນກວດສອບວ່າແອັບຯດັ່ງກ່າວ:
· ກວດ​ສອບ​ການ​ປັບ​ປຸງ​ອຸ​ປະ​ກອນ​ນັບ​ຕັ້ງ​ແຕ່ runtime ສຸດ​ທ້າຍ​. · ກວດ​ສອບ​ການ​ປັບ​ປຸງ​ເຄື່ອງ​ຫມາຍ​ອຸ​ປະ​ກອນ​. · ກວດ​ເບິ່ງ​ວ່າ​ອຸ​ປະ​ກອນ​ທີ່​ໃຊ້ app ແມ່ນ​ຢູ່​ໃນ​ສະ​ຖາ​ນະ​ຄວາມ​ປອດ​ໄພ (ເຊັ່ນ​: ບໍ່​ມີ jailbreaking ຫຼື​ປົ່ງ​ຮາກ​ອອກ​ຕາມ​)​. ຂ້າງເທິງນີ້ແມ່ນພຽງແຕ່ບາງ examples ຂອງເຕັກນິກການປະຕິບັດທີ່ດີທີ່ສຸດທີ່ໃຊ້ໂດຍອຸດສາຫະກໍາ. ໃນຂະນະທີ່ລະບົບນິເວດຂອງອຸປະກອນມືຖືພັດທະນາ, ເຕັກນິກເຫຼົ່ານີ້ອາດຈະລ້າສະໄຫມ. ດັ່ງນັ້ນ, ນັກພັດທະນາຄວນຕິດຕາມການປະຕິບັດທີ່ດີທີ່ສຸດຂອງອຸດສາຫະກໍາຫຼ້າສຸດເພື່ອກວດສອບການຜູກມັດອຸປະກອນ. ສິ່ງທີ່ຄວນສັງເກດ
ເພື່ອຢັ້ງຢືນອຸປະກອນໃນອຸປະກອນ Android, ຜູ້ພັດທະນາສາມາດ:
· ໄດ້​ຮັບ​ຕົວ​ລະ​ບຸ​ທີ່​ເປັນ​ເອ​ກະ​ລັກ​ເຊັ່ນ IMEI ຫຼື Android ID​. · ດຶງຂໍ້ມູນການກໍ່ສ້າງ. · ນຳໃຊ້ຄຸນສົມບັດຂອງ OS API ເດີມ ເຊັ່ນ: SafetyNet ຂອງ Google.
ເພື່ອຢັ້ງຢືນອຸປະກອນໃນອຸປະກອນ iOS, ຜູ້ພັດທະນາສາມາດ:
· ນຳໃຊ້ບໍລິການ OS ເດີມ ເຊັ່ນ: ID ອຸປະກອນຂອງ Apple ຜ່ານ UIDevice.
ການຄວບຄຸມຄວາມປອດໄພນີ້ແມ່ນອ້າງອີງຢູ່ໃນມາດຕະຖານອື່ນໆ. ກະລຸນາເບິ່ງເອກະສານທີ່ລະບຸໄວ້ໃນ:
· OWASP Mobile Application ຄູ່ມືການທົດສອບຄວາມປອດໄພ (MASTG) v1.7.0 (2023), ຫນ້າ. 316-317, 516. · ຄູ່ມືການຄຸ້ມຄອງຄວາມສ່ຽງດ້ານເຕັກໂນໂລຊີ MAS (2021), ໜ້າ. 51, 56.
26

AUTHOR-BP03
ຄວບຄຸມແອັບຯແຈ້ງເຕືອນຜູ້ໃຊ້ຂອງການອະນຸຍາດທີ່ຈໍາເປັນທັງຫມົດກ່ອນທີ່ພວກເຂົາຈະເລີ່ມໃຊ້ແອັບຯ. ລາຍ​ລະ​ອຽດ​ການ​ອະ​ນຸ​ຍາດ​ທີ່​ຕ້ອງ​ການ​ແມ່ນ​ສິດ​ແລະ​ຄວາມ​ສາ​ມາດ​ສະ​ເພາະ​ທີ່ app ໄດ້​ຮ້ອງ​ຂໍ​ຈາກ​ອຸ​ປະ​ກອນ​ມື​ຖື​. ການອະນຸຍາດເຫຼົ່ານີ້ກໍານົດຊັບພະຍາກອນຫຼືຫນ້າທີ່ app ສາມາດເຂົ້າເຖິງໃນອຸປະກອນຂອງຜູ້ໃຊ້. ບາງຄົນ examples ປະກອບມີ, ແຕ່ບໍ່ຈໍາກັດ, ກ້ອງຖ່າຍຮູບ, ໄມໂຄຣໂຟນ, ສະຖານທີ່, ແລະອື່ນໆ. ໂດຍການປະຕິບັດການແຈ້ງເຕືອນທີ່ເຫມາະສົມທີ່ແຈ້ງໃຫ້ຜູ້ໃຊ້ຮູ້ວ່າການຮ້ອງຂໍການອະນຸຍາດໃດ, ຜູ້ພັດທະນາສາມາດປ້ອງກັນບໍ່ໃຫ້ຜູ້ໃຊ້ໂດຍບໍ່ຮູ້ຕົວວ່າໃຫ້ການອະນຸຍາດຫຼາຍເກີນໄປ, ເຊິ່ງອາດຈະເຮັດໃຫ້ຜູ້ສະແດງທີ່ເປັນອັນຕະລາຍສາມາດຂຸດຄົ້ນຊ່ອງຫວ່າງໄດ້. ແລະລັກຂໍ້ມູນລະອຽດອ່ອນ (ເຊັ່ນ: PIIs ແລະຂໍ້ມູນການພິສູດຢືນຢັນ). ການແຈ້ງເຕືອນດັ່ງກ່າວຍັງຈະເຮັດໃຫ້ຜູ້ໃຊ້ສາມາດຕັດສິນໃຈຢ່າງມີຂໍ້ມູນກ່ຽວກັບແອັບຯທີ່ເຂົາເຈົ້າຕິດຕັ້ງ. ຄຳແນະນຳການຈັດຕັ້ງປະຕິບັດ ນັກພັດທະນາຄວນໃຊ້ການແຈ້ງເຕືອນໃນແອັບ (In-App) ເພື່ອຮ້ອງຂໍການອະນຸຍາດເຂົ້າເຖິງຜູ້ໃຊ້. ຜູ້ພັດທະນາຄວນຮັບປະກັນວ່າການແຈ້ງເຕືອນ/ການແຈ້ງເຕືອນບໍ່ສະແດງຂໍ້ມູນທີ່ລະອຽດອ່ອນ. ສິ່ງທີ່ຄວນສັງເກດ, ຜູ້ພັດທະນາຄວນຮ້ອງຂໍການອະນຸຍາດທີ່ຈໍາເປັນສໍາລັບການເຮັດວຽກຂອງແອັບຯເທົ່ານັ້ນ. ການຄວບຄຸມຄວາມປອດໄພນີ້ແມ່ນອ້າງອີງຢູ່ໃນມາດຕະຖານອື່ນໆ. ກະລຸນາເບິ່ງເອກະສານທີ່ລະບຸໄວ້ໃນ:
· OWASP Mobile Application ຄູ່ມືການທົດສອບຄວາມປອດໄພ (MASTG) v1.7.0 (2023), ຫນ້າ. 56, 58. · ENISA Smartphone Secure Development Guidelines (2016), pg. 8, 18, 28. · Apple Developer Guide on Privacy, https://developer.apple.com/design/human-interface-
ຂໍ້ແນະນຳ/ຄວາມເປັນສ່ວນຕົວ (ມັງກອນ 2024). · ຄູ່ມືນັກພັດທະນາ Android ກ່ຽວກັບຄວາມເປັນສ່ວນຕົວ, https://developer.android.com/quality/privacy-and-
ຄວາມປອດໄພ (ມັງກອນ 2024).
27

AUTHOR-BP04
ຄວບຄຸມ app ແຈ້ງເຕືອນຜູ້ໃຊ້ສໍາລັບທຸລະກໍາທີ່ມີຄວາມສ່ຽງສູງທັງຫມົດທີ່ໄດ້ຮັບອະນຸຍາດແລະສໍາເລັດ.
ລາຍ​ລະ​ອຽດ ຖ້າ​ຫາກ​ວ່າ app ມີ​ຫນ້າ​ທີ່​ການ​ເຮັດ​ທຸ​ລະ​ກໍາ​ທີ່​ມີ​ຄວາມ​ສ່ຽງ​ສູງ​, ຜູ້​ໃຊ້​ຄວນ​ຈະ​ໄດ້​ຮັບ​ການ​ແຈ້ງ​ການ​ທັນ​ທີ​ທັນ​ໃດ​ເມື່ອ​ການ​ເຮັດ​ທຸ​ລະ​ກໍາ​ໄດ້​ຮັບ​ອະ​ນຸ​ຍາດ​ແລະ​ສໍາ​ເລັດ​. ໂດຍການປະຕິບັດການຄວບຄຸມນີ້, ນັກພັດທະນາສາມາດຮັບປະກັນວ່າຜູ້ໃຊ້ຈະຖືກຮັບຮູ້ທັນທີເມື່ອທຸລະກໍາທີ່ມີຄວາມສ່ຽງສູງໄດ້ຮັບການອະນຸຍາດແລະສໍາເລັດເພື່ອໃຫ້ພວກເຂົາສາມາດກໍານົດການເຮັດທຸລະກໍາທີ່ອາດຈະຖືກສໍ້ໂກງໄວເທົ່າທີ່ເປັນໄປໄດ້.
ຄຳແນະນຳການຈັດຕັ້ງປະຕິບັດ ນັກພັດທະນາຄວນໃຊ້ວິທີຕໍ່ໄປນີ້ເພື່ອແຈ້ງເຕືອນຜູ້ໃຊ້:
· ການແຈ້ງເຕືອນໃນແອັບພລິເຄຊັນ (In-App). · ແຈ້ງ​ການ​ອີ​ເມລ​໌​. · ການແຈ້ງເຕືອນບໍລິການຂໍ້ຄວາມສັ້ນ (SMS). ຜູ້ພັດທະນາຄວນຮັບປະກັນວ່າການແຈ້ງເຕືອນ/ການແຈ້ງເຕືອນບໍ່ສະແດງຂໍ້ມູນທີ່ລະອຽດອ່ອນ.
ຂ້າງເທິງນີ້ແມ່ນພຽງແຕ່ບາງ examples ຂອງເຕັກນິກການແຈ້ງການການປະຕິບັດທີ່ດີທີ່ສຸດທີ່ໃຊ້ໂດຍອຸດສາຫະກໍາ. ໃນຂະນະທີ່ລະບົບນິເວດຂອງອຸປະກອນມືຖືພັດທະນາ, ເຕັກນິກເຫຼົ່ານີ້ອາດຈະລ້າສະໄຫມ. ດັ່ງນັ້ນ, ນັກພັດທະນາຄວນຕິດຕາມການປະຕິບັດທີ່ດີທີ່ສຸດຂອງອຸດສາຫະກໍາຫຼ້າສຸດເພື່ອແຈ້ງໃຫ້ຜູ້ໃຊ້ຂອງທຸລະກໍາທີ່ມີຄວາມສ່ຽງສູງທີ່ໄດ້ຮັບອະນຸຍາດແລະສໍາເລັດ.
ສິ່ງທີ່ຄວນສັງເກດ ນັກພັດທະນາຄວນຮ້ອງຂໍພຽງແຕ່ການອະນຸຍາດທີ່ຈໍາເປັນສໍາລັບການເຮັດວຽກຂອງແອັບຯ.
ການຄວບຄຸມຄວາມປອດໄພນີ້ແມ່ນອ້າງອີງຢູ່ໃນມາດຕະຖານອື່ນໆ. ກະລຸນາເບິ່ງເອກະສານທີ່ລະບຸໄວ້ໃນ:
· ຄູ່ມືການຄຸ້ມຄອງຄວາມສ່ຽງດ້ານເຕັກໂນໂລຊີ MAS (2021), ໜ້າ. 52. · ຄຳແນະນຳຄວາມປອດໄພການຍອມຮັບການຈ່າຍເງິນຜ່ານມືຖື PCI v2.0.0 (2017), ໜ້າ. 10. · ENISA Smartphone Secure Development Guidelines (2016), pg. 8. · Apple Developer Guide on Privacy, https://developer.apple.com/design/human-interface-
ຂໍ້ແນະນຳ/ຄວາມເປັນສ່ວນຕົວ (ມັງກອນ 2024). · ຄູ່ມືນັກພັດທະນາ Android ກ່ຽວກັບຄວາມເປັນສ່ວນຕົວ, https://developer.android.com/quality/privacy-and-
ຄວາມປອດໄພ (ມັງກອນ 2024).
28

29

3. ການເກັບຮັກສາຂໍ້ມູນ (Data-at-Rest)

ແນະນຳ
ຄວາມປອດໄພການເກັບຮັກສາຂໍ້ມູນສໍາລັບຂໍ້ມູນທີ່ພັກຜ່ອນແມ່ນກ່ຽວຂ້ອງກັບການປົກປ້ອງຄວາມສົມບູນແລະຄວາມລັບຂອງຂໍ້ມູນທີ່ລະອຽດອ່ອນ (ເຊັ່ນ: PIIs ແລະຂໍ້ມູນການພິສູດຢືນຢັນ) ທີ່ເກັບໄວ້ໃນເຄື່ອງໃນອຸປະກອນຂ້າງລູກຄ້າແລະ app serverside ໃນເວລາທີ່ມັນບໍ່ໄດ້ຖືກນໍາໃຊ້ຢ່າງຈິງຈັງຫຼືສົ່ງຕໍ່. ນີ້ປະກອບມີການປະຕິບັດທີ່ດີທີ່ສຸດ, ມາດຕະການປ້ອງກັນແລະເຕັກນິກການເຂົ້າລະຫັດທີ່ຖືກຈ້າງງານເພື່ອຮັບປະກັນຂໍ້ມູນທີ່ເກັບໄວ້ໃນຖານຂໍ້ມູນ, files, cache, memory, ແລະ Trusted Execution Environment (TEE) ໃນອຸປະກອນມືຖື ແລະພື້ນທີ່ທີ່ຄ້າຍຄືກັນໃນ app servers.
ນັກພັດທະນາສາມາດຮັບປະກັນວ່າຂໍ້ມູນຜູ້ໃຊ້ຖືກຮັກສາແລະປົກປ້ອງໂດຍການປະຕິບັດການຄວບຄຸມຄວາມປອດໄພທີ່ເຂັ້ມແຂງສໍາລັບການເກັບຮັກສາຂໍ້ມູນໃນເວລາພັກຜ່ອນ. ການ​ຄວບ​ຄຸມ​ຂໍ້​ມູນ​ທີ່​ຖືກ​ຕ້ອງ​ຍັງ​ເຮັດ​ໃຫ້​ແນ່​ໃຈວ່​າ app ສາ​ມາດ​ຫຼຸດ​ຜ່ອນ​ຄວາມ​ສ່ຽງ​ຂອງ​ການ​ເຂົ້າ​ເຖິງ​ທີ່​ບໍ່​ໄດ້​ຮັບ​ອະ​ນຸ​ຍາດ​, ການ​ປະ​ນີ​ປະ​ນອມ​ອຸ​ປະ​ກອນ​, ການ​ລະ​ເມີດ​ຂໍ້​ມູນ​ທີ່​ເປັນ​ໄປ​ໄດ້​, ແລະ​ຂໍ້​ມູນ​ຮົ່ວ​ໄຫລ​ແລະ​ເສີມ​ຂະ​ຫຍາຍ​ການ​ປ້ອງ​ກັນ app ໄດ້​.
ການຄວບຄຸມຕໍ່ໄປນີ້ຈະຮັບປະກັນວ່າຂໍ້ມູນລະອຽດອ່ອນໃດໆທີ່ບັນທຶກໄວ້ໂດຍເຈດຕະນາໂດຍແອັບຯໄດ້ຖືກປົກປ້ອງຢ່າງພຽງພໍ, ໂດຍບໍ່ຄໍານຶງເຖິງສະຖານທີ່ເປົ້າຫມາຍ. ມັນຍັງກວມເອົາການຮົ່ວໄຫຼໂດຍບໍ່ໄດ້ຕັ້ງໃຈເນື່ອງຈາກການນໍາໃຊ້ APIs ຫຼືຄວາມສາມາດຂອງລະບົບທີ່ບໍ່ຖືກຕ້ອງ.
ການຄວບຄຸມຄວາມປອດໄພ

ID

ການຄວບຄຸມ

STORAGE-BP01 ເກັບຮັກສາຂໍ້ມູນທີ່ລະອຽດອ່ອນທີ່ມີຄວາມຈໍາເປັນສໍາລັບການເຮັດທຸລະກໍາເທົ່ານັ້ນ.

STORAGE-BP02 ປະຕິບັດການເກັບຮັກສາຂໍ້ມູນທີ່ລະອຽດອ່ອນຢ່າງປອດໄພ.

STORAGE-BP02a ເກັບຮັກສາຂໍ້ມູນທີ່ລະອຽດອ່ອນຢ່າງປອດໄພຢູ່ຂ້າງເຊີບເວີ.

STORAGE-BP02b

ເກັບຮັກສາຂໍ້ມູນທີ່ລະອຽດອ່ອນຢ່າງປອດໄພຢູ່ຝ່າຍລູກຄ້າໃນສະພາບແວດລ້ອມການປະຕິບັດທີ່ເຊື່ອຖືໄດ້ (TEE).

STORAGE-BP03 ລຶບຂໍ້ມູນທີ່ລະອຽດອ່ອນເມື່ອບໍ່ຈຳເປັນອີກຕໍ່ໄປ.

30

STORAGE-BP01
ການ​ຄວບ​ຄຸມ app ເກັບ​ຂໍ້​ມູນ​ທີ່​ລະ​ອຽດ​ອ່ອນ​ທີ່​ຈໍາ​ເປັນ​ພຽງ​ແຕ່​ສໍາ​ລັບ​ການ​ເຮັດ​ທຸ​ລະ​ກໍາ​. ລາຍລະອຽດຂໍ້ມູນລະອຽດອ່ອນແມ່ນຖືກກໍານົດເປັນຂໍ້ມູນຜູ້ໃຊ້ (PIIs) ແລະຂໍ້ມູນການພິສູດຢືນຢັນ (ເຊັ່ນ: ຂໍ້ມູນປະຈໍາຕົວ, ກະແຈການເຂົ້າລະຫັດ, ແລະອື່ນໆ) ນັກພັດທະນາຄວນເກັບຂໍ້ມູນທີ່ລະອຽດອ່ອນເທົ່ານັ້ນທີ່ຈໍາເປັນສໍາລັບການເຮັດວຽກຂອງທຸລະກິດ app. ການສະສົມຂໍ້ມູນທີ່ບໍ່ຈໍາເປັນຈະເພີ່ມຜົນກະທົບຂອງການລະເມີດຄວາມປອດໄພທີ່ອາດເກີດຂຶ້ນ, ເຮັດໃຫ້ແອັບຯເປັນເປົ້າຫມາຍທີ່ຫນ້າສົນໃຈສໍາລັບຜູ້ເປັນອັນຕະລາຍ. ໂດຍການປະຕິບັດການຄວບຄຸມຄວາມປອດໄພນີ້, ນັກພັດທະນາສາມາດຮັບປະກັນວ່າການເປີດເຜີຍແມ່ນຈໍາກັດຂໍ້ມູນທີ່ຈໍາເປັນສໍາລັບຫນ້າທີ່ທຸລະກິດສະເພາະ, ຫຼຸດຜ່ອນຜົນກະທົບໃນກໍລະນີທີ່ມີການເຂົ້າເຖິງໂດຍບໍ່ໄດ້ຮັບອະນຸຍາດຫຼືການລະເມີດຂໍ້ມູນ. ຄຳແນະນຳການຈັດຕັ້ງປະຕິບັດ ນັກພັດທະນາຄວນຈັດປະເພດຂໍ້ມູນທີ່ນຳໃຊ້ໂດຍແອັບໂດຍອີງໃສ່ລະດັບຄວາມອ່ອນໄຫວຂອງອົງກອນ ແລະ ອີງໃສ່ຂໍ້ກຳນົດທາງກົດໝາຍ. ຜູ້ພັດທະນາຄວນຮັບຮອງເອົາຂໍ້ແນະນຳຕໍ່ໄປນີ້ເພື່ອຮັບປະກັນຂໍ້ມູນທີ່ຖືກຈັດປະເພດເປັນຄວາມອ່ອນໄຫວ:
1. ປະຕິບັດການແກ້ໄຂການເກັບຮັກສາທີ່ປອດໄພໂດຍອີງໃສ່ຄວາມອ່ອນໄຫວຂອງມັນຢູ່ໃນຝ່າຍລູກຄ້າ / ຂ້າງເຊີຟເວີ. 2. ນຳໃຊ້ມາດຕະການປ້ອງກັນຂໍ້ມູນ (ເຊັ່ນ: tokenising, hashing with salt, encrypting) 3. ລຶບຂໍ້ມູນທີ່ລະອຽດອ່ອນເມື່ອບໍ່ຈຳເປັນອີກຕໍ່ໄປ. ສິ່ງທີ່ຄວນສັງເກດການຄວບຄຸມຄວາມປອດໄພນີ້ແມ່ນອ້າງອີງຢູ່ໃນມາດຕະຖານອື່ນໆ. ກະລຸນາເບິ່ງເອກະສານທີ່ລະບຸໄວ້ໃນ: · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 190, 398. · ຄູ່ມືການຄຸ້ມຄອງຄວາມສ່ຽງດ້ານເຕັກໂນໂລຊີ MAS (2021), ໜ້າ. 9-10, 36, 38. · ENISA Smartphone Secure Development Guidelines (2016), pg. 6.
31

STORAGE-BP02
ຄວບຄຸມແອັບປະຕິບັດການເກັບຮັກສາຂໍ້ມູນທີ່ລະອຽດອ່ອນຢ່າງປອດໄພ. ລາຍ​ລະ​ອຽດ​ການ​ເກັບ​ຮັກ​ສາ​ທີ່​ປອດ​ໄພ​ສໍາ​ລັບ​ກິດ​ມື​ຖື​ຫມາຍ​ເຖິງ​ການ​ປະ​ຕິ​ບັດ​ເຕັກ​ນິກ​ການ​ແລະ​ການ​ປະ​ຕິ​ບັດ​ເພື່ອ​ປົກ​ປັກ​ຮັກ​ສາ​ຂໍ້​ມູນ​ທີ່​ລະ​ອຽດ​ອ່ອນ​ທີ່​ເກັບ​ໄວ້​ໃນ​ອຸ​ປະ​ກອນ​ມື​ຖື​ແລະ app servers ຈາກ​ການ​ເຂົ້າ​ເຖິງ​ໂດຍ​ບໍ່​ໄດ້​ຮັບ​ອະ​ນຸ​ຍາດ​, ການ​ລັກ​ຫຼື tampກຳລັງ. ນີ້ກ່ຽວຂ້ອງກັບການປະຕິບັດທີ່ດີທີ່ສຸດເຊັ່ນ: ການເຂົ້າລະຫັດ, hashing, tokenisation, ແລະການຄວບຄຸມການເຂົ້າເຖິງທີ່ເຫມາະສົມ. ໂດຍການປະຕິບັດການເກັບຮັກສາທີ່ປອດໄພ, ຜູ້ພັດທະນາສາມາດຫຼຸດຜ່ອນການເຂົ້າເຖິງທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດ, ການປະນີປະນອມອຸປະກອນ, ການລະເມີດຂໍ້ມູນທີ່ເປັນໄປໄດ້ແລະການຮົ່ວໄຫລຂອງຂໍ້ມູນ. ຄໍາແນະນໍາການຈັດຕັ້ງປະຕິບັດ ນັກພັດທະນາຄວນປະຕິບັດການແກ້ໄຂການເກັບຮັກສາທີ່ປອດໄພທີ່ສອດຄ່ອງກັບຄວາມອ່ອນໄຫວຂອງຂໍ້ມູນ. ນັກພັດທະນາຄວນຈັດລໍາດັບຄວາມສໍາຄັນຕໍ່ໄປນີ້ສໍາລັບການແກ້ໄຂການເກັບຮັກສາທີ່ປອດໄພ (ຈາກຂໍ້ມູນທີ່ລະອຽດອ່ອນທີ່ສຸດໄປຫາຂໍ້ມູນທີ່ອ່ອນໄຫວຫນ້ອຍ):
1. ດ້ານເຊີບເວີ (ຂໍ້ມູນລະອຽດອ່ອນທັງໝົດຄວນຖືກເກັບໄວ້ໃນດ້ານເຊີບເວີ). 2. ຝ່າຍລູກຄ້າພາຍໃນສະພາບແວດລ້ອມການປະຕິບັດທີ່ເຊື່ອຖືໄດ້ (ໃນກໍລະນີທີ່ຝ່າຍເຊີຟເວີບໍ່ແມ່ນ.
ເປັນໄປໄດ້, ເກັບຂໍ້ມູນລະອຽດອ່ອນທັງໝົດຢູ່ໃນ TEE ຂ້າງລູກຄ້າ). ສິ່ງທີ່ຄວນສັງເກດການຄວບຄຸມຄວາມປອດໄພນີ້ແມ່ນອ້າງອີງຢູ່ໃນມາດຕະຖານອື່ນໆ. ກະລຸນາເບິ່ງເອກະສານທີ່ລະບຸໄວ້ໃນ:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), pg. 17-18. · OWASP Mobile Application ຄູ່ມືການທົດສອບຄວາມປອດໄພ (MASTG) v1.7.0 (2023), ຫນ້າ. 190-203, 398-
406. · ENISA Smartphone Secure Development Guidelines (2016), pg. 06-07.
32

STORAGE-BP02a
ການຄວບຄຸມ
ແອັບເກັບຂໍ້ມູນທີ່ລະອຽດອ່ອນຢ່າງປອດໄພຢູ່ຂ້າງເຊີບເວີ.
ລາຍລະອຽດ
ການເກັບຮັກສາຂໍ້ມູນທີ່ລະອຽດອ່ອນຢູ່ຂ້າງເຊີບເວີຫມາຍເຖິງການເກັບຮັກສາຂໍ້ມູນໃນເຄື່ອງແມ່ຂ່າຍຂອງແອັບຯຫ່າງໄກສອກຫຼີກຫຼືຖານຂໍ້ມູນ. ວິທີການດັ່ງກ່າວສ້າງສະພາບແວດລ້ອມທີ່ດີກວ່າເພື່ອປົກປ້ອງຂໍ້ມູນຈາກການເຂົ້າເຖິງຫຼືການລະເມີດໂດຍບໍ່ໄດ້ຮັບອະນຸຍາດ, ເຮັດໃຫ້ການຄວບຄຸມການເຂົ້າເຖິງທີ່ປອດໄພກວ່າ, ທາງເລືອກໃນການປະຕິບັດມາດຕະການຄວາມປອດໄພທີ່ດີກວ່າເຊັ່ນການເຂົ້າລະຫັດທີ່ສັບສົນຫຼາຍແລະການສະຫນອງການປັບປຸງຄວາມປອດໄພໄວຂຶ້ນ.
ໂດຍການຈັດຕັ້ງປະຕິບັດການເກັບຮັກສາຂໍ້ມູນທີ່ລະອຽດອ່ອນຂອງເຊີບເວີ, ຜູ້ພັດທະນາສາມາດຫຼຸດຜ່ອນຄວາມສ່ຽງທີ່ເກີດຈາກການເກັບຮັກສາຂໍ້ມູນດ້ານລູກຄ້າ, ຍ້ອນວ່າການເກັບຮັກສາດ້ານລູກຄ້າແມ່ນມີຄວາມອ່ອນໄຫວຕໍ່ກັບເຕັກນິກການຂຸດຄົ້ນຂໍ້ມູນທີ່ຖືກໃຊ້ທົ່ວໄປໂດຍຜູ້ເປັນອັນຕະລາຍໃນການຫລອກລວງມືຖື.
ຄຳແນະນຳການຈັດຕັ້ງປະຕິບັດ
ຜູ້ພັດທະນາຄວນນຳໃຊ້ຢ່າງໜ້ອຍ 1 ມາດຕະການປ້ອງກັນຂໍ້ມູນຕໍ່ໄປນີ້:
1. ສໍາລັບລະຫັດຜ່ານເທົ່ານັ້ນ, ນັກພັດທະນາສາມາດໃຊ້ hashing ກັບ salt6. ແທນທີ່ຈະເກັບຮັກສາລະຫັດຜ່ານຕົວຈິງ, ເກືອທີ່ເປັນເອກະລັກແມ່ນສ້າງແລະປະສົມປະສານກັບລະຫັດຜ່ານ, ສ້າງ hashes ເກືອ.
2. ນັກພັດທະນາສາມາດເຂົ້າລະຫັດຂໍ້ມູນລະອຽດອ່ອນໄດ້ 7 ຢ່າງດ້ວຍມາດຕະຖານການເຂົ້າລະຫັດເຊັ່ນ AES-128. 3. ນັກພັດທະນາສາມາດປະຕິບັດ tokenisation8 ດ້ວຍ tokenisation ການຈັດການຕົນເອງຫຼື tokenisation
ການບໍລິການ, ປ່ຽນແທນຂໍ້ມູນທີ່ລະອຽດອ່ອນດ້ວຍໂທເຄັນໃນບ່ອນທີ່ເປັນໄປໄດ້. ນອກຈາກນັ້ນ, ນັກພັດທະນາຄວນຮັບປະກັນ tokenisation ມີຄວາມຍາວພຽງພໍແລະຄວາມສັບສົນ (ສະຫນັບສະຫນູນໂດຍ cryptography ທີ່ປອດໄພ) ໂດຍອີງໃສ່ຄວາມອ່ອນໄຫວຂອງຂໍ້ມູນແລະຄວາມຕ້ອງການຂອງທຸລະກິດ.
ຂ້າງເທິງນີ້ແມ່ນພຽງແຕ່ບາງ examples ຂອງການປະຕິບັດທີ່ດີທີ່ສຸດທີ່ໃຊ້ໂດຍອຸດສາຫະກໍາ. ໃນຂະນະທີ່ລະບົບນິເວດຂອງອຸປະກອນມືຖືພັດທະນາ, ການປະຕິບັດທີ່ດີທີ່ສຸດເຫຼົ່ານີ້ອາດຈະລ້າສະໄຫມ. ດັ່ງນັ້ນ, ນັກພັດທະນາຄວນປະຕິບັດຕາມການປະຕິບັດທີ່ດີທີ່ສຸດຂອງອຸດສາຫະກໍາຫຼ້າສຸດເພື່ອເກັບຂໍ້ມູນທີ່ລະອຽດອ່ອນຢ່າງປອດໄພໃນດ້ານເຊີຟເວີ.
ສິ່ງທີ່ຄວນສັງເກດ
ການຄວບຄຸມຄວາມປອດໄພນີ້ແມ່ນອ້າງອີງຢູ່ໃນມາດຕະຖານອື່ນໆ. ກະລຸນາເບິ່ງເອກະສານທີ່ລະບຸໄວ້ໃນ:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), pg. 19-20. · OWASP Mobile Application ຄູ່ມືການທົດສອບຄວາມປອດໄພ (MASTG) v1.7.0 (2023), ຫນ້າ. 71-77, 219-227, ສ.
416-421. · ຄູ່ມືການຄຸ້ມຄອງຄວາມສ່ຽງດ້ານເຕັກໂນໂລຊີ MAS (2021), ໜ້າ. 30, 36-37, 39. · PCI Mobile Payment Acceptance Security Guidelines v2.0.0 (2017), pg. 9. · ENISA Smartphone Secure Development Guidelines (2016), pg. 6-9.
6 Hashing ກັບເກືອແມ່ນໃຊ້ເພື່ອເພີ່ມຊັ້ນຄວາມປອດໄພເພີ່ມເຕີມໂດຍການເຮັດໃຫ້ມັນມີຄວາມເຂັ້ມຂຸ້ນທາງດ້ານຄອມພິວເຕີ້ສໍາລັບຜູ້ໂຈມຕີເພື່ອຖອດລະຫັດຂໍ້ມູນທີ່ອ່ອນໄຫວຕົ້ນສະບັບ. ໃນບໍລິບົດຂອງການເກັບຮັກສາລະຫັດຜ່ານຫຼືການມາຈາກລະຫັດ, ນັກພັດທະນາຄວນໃຊ້ຟັງຊັນການສືບພັນຂອງກຸນແຈທາງດຽວຫຼືລະບົບ hash ຊ້າ, ເຊັ່ນ PBKDF2, bcrypt, ຫຼື scrypt. 7 ການເຂົ້າລະຫັດຖືກນໍາໃຊ້ເພື່ອປ່ຽນຂໍ້ມູນເຂົ້າໄປໃນຮູບແບບທີ່ບໍ່ສາມາດອ່ານໄດ້, ໃຫ້ແນ່ໃຈວ່າເຖິງແມ່ນວ່າການເຂົ້າເຖິງໂດຍບໍ່ມີການອະນຸຍາດ, ຂໍ້ມູນລະອຽດອ່ອນຍັງຄົງເປັນຄວາມລັບ. 8 Tokenisation ຖືກນໍາໃຊ້ເພື່ອທົດແທນຂໍ້ມູນທີ່ລະອຽດອ່ອນດ້ວຍ tokens ເພື່ອຫຼຸດຜ່ອນຄວາມສ່ຽງຕໍ່ການເປີດເຜີຍຂໍ້ມູນທີ່ລະອຽດອ່ອນ.
33

STORAGE-BP02b
ການຄວບຄຸມ
ແອັບເກັບຂໍ້ມູນທີ່ລະອຽດອ່ອນຢ່າງປອດໄພຢູ່ຝ່າຍລູກຄ້າໃນສະພາບແວດລ້ອມການປະຕິບັດທີ່ເຊື່ອຖືໄດ້ (TEE).
ລາຍລະອຽດ
ສະພາບແວດລ້ອມການປະຕິບັດທີ່ເຊື່ອຖືໄດ້ (TEE) ແມ່ນພື້ນທີ່ທີ່ໂດດດ່ຽວພາຍໃນອຸປະກອນມືຖືຂອງຮາດແວ ຫຼືສະຖາປັດຕະຍະກຳໂປເຊດເຊີທີ່ໃຫ້ສະພາບແວດລ້ອມທີ່ປອດໄພສູງສຳລັບການເກັບຂໍ້ມູນລະອຽດອ່ອນ ແລະປະຕິບັດການດຳເນີນການທີ່ລະອຽດອ່ອນ ຫຼືສຳຄັນ. ມັນຖືກອອກແບບມາເພື່ອປົກປ້ອງຂໍ້ມູນທີ່ລະອຽດອ່ອນ, ລະຫັດລັບ ແລະຂະບວນການສຳຄັນຈາກການເຂົ້າເຖິງທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດ ຫຼື t.ampກຳລັງ. ຖ້າໜ້າວຽກທາງທຸລະກິດຂອງແອັບຕ້ອງການເກັບຂໍ້ມູນທີ່ລະອຽດອ່ອນຢູ່ຝ່າຍລູກຄ້າ, ມັນແນະນຳໃຫ້ເກັບມັນໄວ້ໃນ TEE ຂອງອຸປະກອນ.
ໂດຍການປະຕິບັດການເກັບຮັກສາຂໍ້ມູນທີ່ລະອຽດອ່ອນທີ່ເຫມາະສົມໃນ TEE ຂ້າງລູກຄ້າ, ຜູ້ພັດທະນາສາມາດຫຼຸດຜ່ອນການຂົ່ມຂູ່ທີ່ມາຈາກພາຍໃນອຸປະກອນທີ່ຖືກທໍາລາຍແລະຈາກຜູ້ເປັນອັນຕະລາຍພາຍນອກ. ບ່ອນຈັດເກັບຂໍ້ມູນດັ່ງກ່າວຍັງສາມາດຫຼຸດຜ່ອນຕໍ່ກັບການເຂົ້າເຖິງຂໍ້ມູນທີ່ລະອຽດອ່ອນຂອງຜູ້ໃຊ້ໂດຍບໍ່ໄດ້ຮັບອະນຸຍາດໃນແອັບໃດໜຶ່ງ ແລະ ປ້ອງກັນບໍ່ໃຫ້ກະແຈການເຂົ້າລະຫັດຖືກລັກ.
ຄຳແນະນຳການຈັດຕັ້ງປະຕິບັດ
ຜູ້ພັດທະນາຄວນເກັບຮັກສາຂໍ້ມູນທີ່ລະອຽດອ່ອນຢ່າງປອດໄພຢູ່ຝ່າຍລູກຄ້າໃນສະພາບແວດລ້ອມການປະຕິບັດທີ່ເຊື່ອຖືໄດ້ (TEE) ເຊັ່ນ: ARM's TrustZone, Apple's Secure Enclave.
ນັກພັດທະນາຄວນເກັບຮັກສາລາຍຊື່ຂໍ້ມູນລະອຽດອ່ອນຕໍ່ໄປນີ້ໜ້ອຍສຸດໄວ້ໃນ TEE:
· ຕົວລະບຸທາງຊີວະມິຕິ. ·ໂທເຄັນການຢັ້ງຢືນ. · ລະຫັດການເຂົ້າລະຫັດລັບໃນລະບົບການຈັດການຫຼັກທີ່ປອດໄພເຊັ່ນ: Android Keystore, iOS
ພວງກະແຈ.
ຂ້າງເທິງນີ້ແມ່ນພຽງແຕ່ບາງ examples ຂອງສິ່ງທີ່ຜູ້ພັດທະນາຂໍ້ມູນທີ່ລະອຽດອ່ອນຄວນເກັບຮັກສາໄວ້ໃນ TEE. ໃນຂະນະທີ່ລະບົບນິເວດຂອງອຸປະກອນມືຖືພັດທະນາ, ນັກພັດທະນາຄວນໃຊ້ສິດເສລີພາບໃນການເກັບຮັກສາຂໍ້ມູນໃດໆທີ່ພວກເຂົາຄິດວ່າມີຄວາມຈໍາເປັນທີ່ຈະເກັບໄວ້ໃນ TEE.
ສິ່ງທີ່ຄວນສັງເກດ
ສໍາລັບອຸປະກອນທີ່ບໍ່ມີ TEEs ຮາດແວ, ນັກພັດທະນາອາດຈະພິຈາລະນາການນໍາໃຊ້ TEEs virtualised.
ອີກທາງເລືອກ, ນັກພັດທະນາສາມາດພິຈາລະນາປິດການໃຊ້ງານແອັບຯຫຼືປິດການທໍາງານການເຮັດທຸລະກໍາທີ່ມີຄວາມສ່ຽງສູງຂອງແອັບຯ, ເນື່ອງຈາກວ່າແອັບຯຖືກຖືວ່າບໍ່ປອດໄພສໍາລັບທຸລະກໍາທີ່ມີຄວາມສ່ຽງສູງ.
ການຄວບຄຸມຄວາມປອດໄພນີ້ແມ່ນອ້າງອີງຢູ່ໃນມາດຕະຖານອື່ນໆ. ກະລຸນາເບິ່ງເອກະສານທີ່ລະບຸໄວ້ໃນ:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), pg. 19-20. · OWASP Mobile Application ຄູ່ມືການທົດສອບຄວາມປອດໄພ (MASTG) v1.7.0 (2023), ຫນ້າ. 75, 93, 194-200. · ຄູ່ມືການຄຸ້ມຄອງຄວາມສ່ຽງດ້ານເຕັກໂນໂລຊີ MAS (2021), ໜ້າ. 51. · ຄຳແນະນຳຄວາມປອດໄພການຍອມຮັບການຈ່າຍເງິນຜ່ານມືຖື PCI v2.0.0 (2017), ໜ້າ. 07-09, 14. · ENISA Smartphone Secure Development Guidelines (2016), pg. 10.
34

STORAGE-BP03
ການຄວບຄຸມ
ແອັບຈະລຶບຂໍ້ມູນທີ່ລະອຽດອ່ອນເມື່ອບໍ່ຈຳເປັນອີກຕໍ່ໄປ.
ລາຍລະອຽດ
ການລຶບຂໍ້ມູນທີ່ລະອຽດອ່ອນໝາຍເຖິງຂັ້ນຕອນການລຶບ ຫຼືລຶບຂໍ້ມູນທີ່ເປັນຄວາມລັບ, ສ່ວນຕົວ ຫຼືຂໍ້ມູນທີ່ລະອຽດອ່ອນອອກຈາກອຸປະກອນເກັບຮັກສາ, ເຊີບເວີ ຫຼືຖານຂໍ້ມູນຢ່າງຖາວອນ. ຂະບວນການນີ້ຮັບປະກັນວ່າຂໍ້ມູນທີ່ລະອຽດອ່ອນຖືກເອົາຄືນມາໂດຍບໍ່ສາມາດກູ້ຄືນໄດ້ ແລະບໍ່ສາມາດເຂົ້າເຖິງ, ດຶງຂໍ້ມູນ, ເປີດເຜີຍໂດຍບັງເອີນ, ຫຼືສ້າງຄືນໃໝ່ໂດຍບຸກຄົນທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດ ຫຼືຜ່ານວິທີການກູ້ຄືນຂໍ້ມູນ.
ໂດຍການປະຕິບັດຂະບວນການນີ້, ຜູ້ພັດທະນາສາມາດຫຼຸດຜ່ອນປ່ອງຢ້ຽມທີ່ຜູ້ໂຈມຕີສາມາດຂຸດຄົ້ນຊ່ອງຫວ່າງເພື່ອລັກຂໍ້ມູນທີ່ລະອຽດອ່ອນ.
ຄຳແນະນຳການຈັດຕັ້ງປະຕິບັດ
ຜູ້ພັດທະນາຄວນໃຊ້ເຕັກນິກການເກັບຮັກສາຄວາມປອດໄພຢ່າງຕໍ່ເນື່ອງຕໍ່ໄປນີ້:
· ລຶບຄຸກກີ້ທີ່ເກັບໄວ້ໃນເວລາປິດແອັບ ຫຼືໃຊ້ການຈັດເກັບຄຸກກີ້ໃນໜ່ວຍຄວາມຈຳ. · ເອົາ​ຂໍ້​ມູນ​ລະ​ອຽດ​ອ່ອນ​ທັງ​ຫມົດ​ກ່ຽວ​ກັບ​ການ​ຖອນ​ການ​ຕິດ​ຕັ້ງ app​. · ເອົາຖານຂໍ້ມູນທັງໝົດອອກດ້ວຍຕົນເອງ files ທີ່ປະກອບດ້ວຍຂໍ້ມູນທີ່ລະອຽດອ່ອນ (ເຊັ່ນ: iOS WebView cache) ຈາກ
ໄດ້ file ລະບົບໃນເວລາທີ່ຫນ້າທີ່ທຸລະກິດທີ່ກ່ຽວຂ້ອງຢຸດຢູ່.
ຂ້າງເທິງນີ້ແມ່ນພຽງແຕ່ບາງ examples ຂອງການປະຕິບັດທີ່ດີທີ່ສຸດທີ່ໃຊ້ໂດຍອຸດສາຫະກໍາ. ໃນຂະນະທີ່ລະບົບນິເວດຂອງອຸປະກອນມືຖືພັດທະນາ, ເຕັກນິກເຫຼົ່ານີ້ອາດຈະລ້າສະໄຫມ. ດັ່ງນັ້ນ, ນັກພັດທະນາຄວນປະຕິບັດຕາມການປະຕິບັດທີ່ດີທີ່ສຸດຂອງອຸດສາຫະກໍາຫຼ້າສຸດເພື່ອລຶບຂໍ້ມູນທີ່ລະອຽດອ່ອນໃນເວລາທີ່ບໍ່ຈໍາເປັນ.
ສິ່ງທີ່ຄວນສັງເກດ
ນັກພັດທະນາຄວນເອົາໃຈໃສ່ໃນການປະຕິບັດຕາມມາດຕະຖານທີ່ຍອມຮັບຢ່າງກວ້າງຂວາງແລະກົດຫມາຍການເກັບຮັກສາຂໍ້ມູນທີ່ກ່ຽວຂ້ອງລວມທັງແຕ່ບໍ່ຈໍາກັດພຽງແຕ່:
· ກົດໝາຍວ່າດ້ວຍການປົກປ້ອງຂໍ້ມູນສ່ວນຕົວ (PDPA) · ກົດລະບຽບການປົກປັກຮັກສາຂໍ້ມູນທົ່ວໄປ (GDPR) · ມາດຕະຖານຄວາມປອດໄພຂໍ້ມູນອຸດສາຫະກໍາບັດຊໍາລະ (PCI DSS)
ການຄວບຄຸມຄວາມປອດໄພນີ້ແມ່ນອ້າງອີງຢູ່ໃນມາດຕະຖານອື່ນໆ. ກະລຸນາເບິ່ງເອກະສານທີ່ລະບຸໄວ້ໃນ:
· OWASP Mobile Application ຄູ່ມືການທົດສອບຄວາມປອດໄພ (MASTG) v1.7.0 (2023), ຫນ້າ. 199, 206-214, 403-414.
· ຄູ່ມືການຄຸ້ມຄອງຄວາມສ່ຽງດ້ານເຕັກໂນໂລຊີ MAS (2021), ໜ້າ. 39. · ENISA Smartphone Secure Development Guidelines (2016), pg. ວັນທີ 07, 09-10.
35

36

4. ຕ້ານ Tampering & ຕ້ານການປີ້ນກັບກັນ

ແນະນຳ
ຕ້ານ Tampການ​ຄວບ​ຄຸມ​ຄວາມ​ປອດ​ໄພ​ດ້ານ​ການ​ຕ້ານ​ການ​ຕ້ານ​ການ​ປີ້ນ​ຄືນ​ແມ່ນ​ມາດ​ຕະ​ການ​ເພີ່ມ​ເຕີມ​ທີ່​ຜູ້​ພັດ​ທະ​ນາ​ສາ​ມາດ​ປະ​ຕິ​ບັດ​ເພື່ອ​ຕ້ານ​ການ​ໂຈມ​ຕີ​ທີ່​ພະ​ຍາ​ຍາມ​ໂຈມ​ຕີ.amper ຫຼື app engineer reverse. ໂດຍການປະຕິບັດທັງສອງລັກສະນະ, ນັກພັດທະນາເພີ່ມຊັ້ນປ້ອງກັນຫຼາຍຊັ້ນໃຫ້ກັບແອັບຯ, ເຮັດໃຫ້ມັນຍາກຫຼາຍສໍາລັບຜູ້ສະແດງທີ່ເປັນອັນຕະລາຍທີ່ຈະປະສົບຜົນສໍາເລັດ.amper ຫຼື app engineer reverse, ຊຶ່ງສາມາດສົ່ງຜົນໃນ:
· ການລັກ ຫຼື ການປະນີປະນອມຂອງຊັບສິນທາງທຸລະກິດທີ່ມີຄຸນຄ່າເຊັ່ນ: ຂັ້ນຕອນການເປັນເຈົ້າຂອງ, ຄວາມລັບທາງການຄ້າ, ຫຼືຂໍ້ມູນລະອຽດອ່ອນ,
·ການສູນເສຍທາງດ້ານການເງິນຂອງຜູ້ໃຊ້ທີ່ໃຊ້ app ສໍາລັບທຸລະກໍາທີ່ມີຄວາມສ່ຽງສູງ, ·ການສູນເສຍທາງດ້ານການເງິນຂອງອົງການຈັດຕັ້ງເນື່ອງຈາກການສູນເສຍລາຍໄດ້ຫຼືການປະຕິບັດທາງດ້ານກົດຫມາຍ, ·ຄວາມເສຍຫາຍຕໍ່ຊື່ສຽງຂອງຍີ່ຫໍ້ຍ້ອນການໂຄສະນາທາງລົບຫຼືຄວາມບໍ່ພໍໃຈຂອງລູກຄ້າ.

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

ID

ການຄວບຄຸມ

RESILIENCE-BP01 ເຊັນດ້ວຍໃບຢັ້ງຢືນຈາກຮ້ານ app ຢ່າງເປັນທາງການ.

RESILIENCE-BP02 ປະຕິບັດການ jailbreak/ການກວດຫາຮາກ. RESILIENCE-BP03 ປະຕິບັດການກວດຫາຕົວຈຳລອງ.

RESILIENCE-BP04 ປະຕິບັດການກວດສອບຕ້ານ malware.

RESILIENCE-BP05 ປະຕິບັດກົນໄກການຕ້ານການ hooking.

RESILIENCE-BP06 ປະຕິບັດການວາງຊ້ອນ, ໄລຍະໄກ viewing, ແລະມາດຕະການຕອບໂຕ້ screenshot.

ຄວາມຢືດຢຸ່ນ-BP07

ປະຕິບັດການຈັບພາບຕ້ານການກົດແປ້ນພິມ ຫຼືຕ້ານການກົດແປ້ນພິມຕໍ່ກັບແປ້ນພິມສະເໝືອນຂອງພາກສ່ວນທີສາມ.

37

ຄວາມຢືດຢຸ່ນ-BP01
ການຄວບຄຸມ
ແອັບແມ່ນລະຫັດທີ່ເຊັນດ້ວຍໃບຢັ້ງຢືນຈາກຮ້ານຄ້າແອັບຢ່າງເປັນທາງການ.
ລາຍລະອຽດ
ແອັບຕ່າງໆມັກຈະຖືກຫຼອກລວງໂດຍຜູ້ກະທຳທີ່ເປັນອັນຕະລາຍ ແລະຖືກແຈກຢາຍຜ່ານຊ່ອງທາງທີ່ເຂັ້ມງວດໜ້ອຍກວ່າ. ການເຊັນຊື່ແອັບດ້ວຍໃບຮັບຮອງທີ່ສະໜອງໃຫ້ໂດຍຮ້ານຄ້າແອັບທີ່ເປັນທາງການຈະຮັບປະກັນ OS ມືຖື ແລະຜູ້ໃຊ້ວ່າແອັບມືຖືແມ່ນມາຈາກແຫຼ່ງທີ່ຢັ້ງຢືນແລ້ວ.
ການປະຕິບັດການເຊັນລະຫັດຊ່ວຍໃຫ້ລະບົບປະຕິບັດການກໍານົດວ່າຈະອະນຸຍາດໃຫ້ຊອບແວດໍາເນີນການຫຼືຕິດຕັ້ງໂດຍອີງໃສ່ລາຍເຊັນຫຼືໃບຢັ້ງຢືນທີ່ໃຊ້ເພື່ອເຊັນລະຫັດ. ນີ້ຊ່ວຍປ້ອງກັນການຕິດຕັ້ງ ແລະການປະຕິບັດແອັບຯທີ່ອາດເປັນອັນຕະລາຍ. ນອກ​ຈາກ​ນັ້ນ​, ການ​ເຊັນ​ລະ​ຫັດ​ຍັງ​ຊ່ວຍ​ໃຫ້​ມີ​ການ​ກວດ​ສອບ​ຄວາມ​ຊື່​ສັດ​, ເປັນ​ລາຍ​ເຊັນ​ຈະ​ມີ​ການ​ປ່ຽນ​ແປງ​ຖ້າ​ຫາກ​ວ່າ app ໄດ້​ຖືກ​.ampered ກັບ.
ຄຳແນະນຳການຈັດຕັ້ງປະຕິບັດ
ນັກພັດທະນາຄວນຂຽນລະຫັດໃຫ້ແອັບຯຂອງພວກເຂົາດ້ວຍໃບຢັ້ງຢືນ. ພາກນີ້ໃຫ້ຕົວຢ່າງamples of how to do this via the most popular platforms iOS and Android .
ສໍາລັບ App Store ຂອງ Apple, ມັນສາມາດເຮັດໄດ້ໂດຍການລົງທະບຽນໃນ Apple Developer Program ແລະສ້າງຄໍາຮ້ອງຂໍການເຊັນໃບຢັ້ງຢືນຢູ່ໃນປະຕູນັກພັດທະນາ. ນັກພັດທະນາສາມາດລົງທະບຽນສໍາລັບໂຄງການນັກພັດທະນາ Apple ແລະສາມາດອ້າງອີງຄູ່ມືນັກພັດທະນາຕໍ່ໄປນີ້ສໍາລັບການເຊັນລະຫັດພາຍໃຕ້ສິ່ງທີ່ຄວນສັງເກດ.
ສໍາລັບ Android, ມີ App Store ຕ່າງໆ. ສໍາລັບ Play Store ຂອງ Google, ມັນສາມາດເຮັດໄດ້ໂດຍການຕັ້ງຄ່າ Play App Signing ເຊິ່ງເປັນຄວາມຕ້ອງການສໍາລັບການແຈກຢາຍຜ່ານ Play Store ຂອງ Google. ສໍາລັບຂໍ້ມູນເພີ່ມເຕີມກ່ຽວກັບວິທີການເຮັດດັ່ງນັ້ນນັກພັດທະນາສາມາດເຂົ້າໄປເບິ່ງຄູ່ມືນັກພັດທະນາ Android ພາຍໃຕ້ສິ່ງທີ່ຄວນສັງເກດ.
ສໍາລັບຮ້ານຄ້າທີ່ເປັນທາງການອື່ນໆ, ອ້າງອີງເຖິງຄໍາແນະນໍາຂອງຜູ້ພັດທະນາຂອງເຂົາເຈົ້າກ່ຽວກັບການເຊັນລະຫັດແຫຼ່ງຂອງແອັບຯ. ສິ່ງທີ່ຄວນສັງເກດ ການຄວບຄຸມຄວາມປອດໄພນີ້ຍັງເປັນຂໍ້ກໍານົດສໍາລັບການເຜີຍແຜ່ແອັບຯໃນ App Store ຢ່າງເປັນທາງການ, ດັ່ງນັ້ນ, ການແນະນໍາແມ່ນເພື່ອໃຫ້ແອັບຯຂອງທ່ານຖືກເຊັນລະຫັດດ້ວຍໃບຢັ້ງຢືນຈາກຮ້ານຄ້າ app ຢ່າງເປັນທາງການ. ການຄວບຄຸມຄວາມປອດໄພນີ້ແມ່ນອ້າງອີງຢູ່ໃນມາດຕະຖານອື່ນໆ. ກະລຸນາເບິ່ງເອກະສານທີ່ລະບຸໄວ້ໃນ:
· ຄູ່ມືໂຄງການນັກພັດທະນາ Apple ສຳລັບການເຊັນລະຫັດ, https://developer.apple.com/support/code-signing (ມັງກອນ 2024).
· ຄູ່ມືນັກພັດທະນາ Android ກ່ຽວກັບຄວາມເປັນສ່ວນຕົວ, https://developer.android.com/quality/privacy-andsecurity (ມັງກອນ 2024).
· OWASP Mobile Application ຄູ່ມືການທົດສອບຄວາມປອດໄພ (MASTG) v1.7.0 (2023), ຫນ້າ. 325-326, 522523.
· ENISA Smartphone Secure Development Guidelines (2016), ຫນ້າ. 21.
38

ຄວາມຢືດຢຸ່ນ-BP02
ການຄວບຄຸມ
ແອັບດັ່ງກ່າວປະຕິບັດການ jailbreak ຫຼືການກວດຫາຮາກ.
ລາຍລະອຽດ
ອຸປະກອນປົ່ງຮາກອອກຕາມແລະ jailbroken ໂດຍທົ່ວໄປແລ້ວຖືວ່າບໍ່ປອດໄພ. ອຸປະກອນທີ່ປົ່ງຮາກອອກຕາມ ຫຼື jailbroken ອະນຸຍາດໃຫ້ຜູ້ໃຊ້ສາມາດໄດ້ຮັບສິດທິພິເສດສູງ, ເຮັດໃຫ້ການຫລີກລ່ຽງຄວາມປອດໄພແລະຂໍ້ຈໍາກັດ OS ໄດ້ງ່າຍຂຶ້ນ. ສິດທິພິເສດດັ່ງກ່າວອາດບໍ່ປອດໄພສຳລັບແອັບຕ່າງໆ ເນື່ອງຈາກສິດທິເຫຼົ່ານີ້ອະນຸຍາດໃຫ້ຜູ້ກະທຳທີ່ເປັນອັນຕະລາຍສາມາດສວຍໃຊ້ຊ່ອງໂຫວ່ໄດ້, ລັກເອົາຂໍ້ມູນປະຈຳຕົວ, ຄອບຄອງອຸປະກອນຂອງຜູ້ໃຊ້ ແລະ ດຳເນີນທຸລະກຳແອັບທີ່ຫຼອກລວງ.
ໂດຍການປະຕິບັດການ jailbreak ຫຼືການກວດຫາຮາກ, ນັກພັດທະນາສາມາດປ້ອງກັນການຂູດຮີດທີ່ກ່າວມາຂ້າງເທິງຈາກການເກີດຂື້ນ, ປົກປ້ອງຊັບສິນທາງປັນຍາຂອງແອັບຯ, ຮັບປະກັນຄວາມຫມັ້ນຄົງຂອງແອັບຯແລະປ້ອງກັນການຂ້າມຜ່ານຂອງລະບົບ in-app.
ຄຳແນະນຳການຈັດຕັ້ງປະຕິບັດ
ຜູ້​ພັດ​ທະ​ນາ​ຄວນ​ປະ​ຕິ​ບັດ jailbreak ຫຼື​ການ​ກວດ​ສອບ​ຮາກ​ໂດຍ​ການ​ປະ​ຕິ​ບັດ​ການ​ກວດ​ສອບ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​ໃນ app ຂອງ​ເຂົາ​ເຈົ້າ​ສໍາ​ລັບ​ອຸ​ປະ​ກອນ Android​:
1. ກວດເບິ່ງ superuser ຫຼື SU binary. 2. ກວດພົບຮາກ file ການປ່ຽນແປງລະບົບ. 3. ຊອກຫາແອັບຯທີ່ປົ່ງຮາກອອກຕາມ. 4. ກວດເບິ່ງການຟື້ນຕົວແບບກຳນົດເອງ. 5. ກວດເບິ່ງການໃຊ້ API ທີ່ບໍ່ປອດໄພ.
ນັກພັດທະນາຄວນປະຕິບັດການ jailbreak ຫຼືການກວດພົບຮາກໂດຍການປະຕິບັດການກວດສອບຕໍ່ໄປນີ້ໃນແອັບຯຂອງພວກເຂົາສໍາລັບອຸປະກອນ iOS:
1. ກວດພົບການໃຊ້ APIs ທີ່ຖືກຈໍາກັດ. 2. ຊອກຫາ tweaks jailbreak ເຊັ່ນ mods. 3. ຊອກຫາຮ້ານ app ທີ່ບໍ່ເປັນທາງການ, ຕົວຢ່າງ, ກວດເບິ່ງລາຍເຊັນ Cydia App Store. 4. ຊອກຫາການດັດແກ້ kernel. 5. ກວດ​ສອບ​ຄວາມ​ສົມ​ບູນ​ຂອງ​ການ​ສໍາ​ຄັນ file ລະບົບ. 6. ໃຊ້ຫ້ອງສະຫມຸດພາກສ່ວນທີສາມທີ່ອອກແບບມາເພື່ອກວດຫາອຸປະກອນ tampສຽບ.
ຂ້າງເທິງນີ້ແມ່ນພຽງແຕ່ບາງ examples ຂອງການກວດສອບການປະຕິບັດທີ່ດີທີ່ສຸດທີ່ໃຊ້ໂດຍອຸດສາຫະກໍາ. ໃນຂະນະທີ່ລະບົບນິເວດຂອງອຸປະກອນມືຖືພັດທະນາ, ການກວດສອບເຫຼົ່ານີ້ອາດຈະລ້າສະໄຫມ. ດັ່ງນັ້ນ, ນັກພັດທະນາຄວນປະຕິບັດຕາມການປະຕິບັດທີ່ດີທີ່ສຸດຂອງອຸດສາຫະກໍາຫຼ້າສຸດເພື່ອປະຕິບັດການ jailbreak ຫຼືການກວດພົບຮາກ.
39

ສິ່ງທີ່ຄວນສັງເກດການຄວບຄຸມຄວາມປອດໄພນີ້ແມ່ນອ້າງອີງຢູ່ໃນມາດຕະຖານອື່ນໆ. ກະລຸນາເບິ່ງເອກະສານທີ່ລະບຸໄວ້ໃນ:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), pg. 31. · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 319-320, 5069, ສ.
518-519. · ຄູ່ມືການຄຸ້ມຄອງຄວາມສ່ຽງດ້ານເຕັກໂນໂລຊີ MAS (2021), ໜ້າ. 50. · ENISA Smartphone Secure Development Guidelines (2016), pg. ໑໑, ໒໓.
9 https://github.com/crazykid95/Backup-Mobile-Security-Report/blob/master/Jailbreak-Root-DetectionEvasion-Study-on-iOS-and-Android.pdf
40

ຄວາມຢືດຢຸ່ນ-BP03
ການຄວບຄຸມ
app ປະຕິບັດການຊອກຄົ້ນຫາ emulator.
ລາຍລະອຽດ
Emulators ແມ່ນຊອບແວທີ່ໃຊ້ໃນການທົດສອບແອັບຯມືຖືໂດຍການໃຫ້ຜູ້ໃຊ້ສາມາດທົດສອບແອັບຯມືຖືໃນຫຼາຍໆລຸ້ນ ແລະອຸປະກອນມືຖືທີ່ເຮັດແບບຈໍາລອງໄດ້. ເຖິງແມ່ນວ່າຈະເປັນປະໂຫຍດສໍາລັບການທົດສອບ, ແອັບຯບໍ່ຄວນອະນຸຍາດໃຫ້ຕົວເອງຕິດຕັ້ງຢູ່ໃນຕົວ emulators ພາຍນອກສະພາບແວດລ້ອມການພັດທະນາ.
ໂດຍການປະຕິບັດການກວດພົບການ emulation, ນັກພັດທະນາສາມາດປ້ອງກັນບໍ່ໃຫ້ນັກສະແດງທີ່ເປັນອັນຕະລາຍຈາກການດໍາເນີນການວິເຄາະແບບເຄື່ອນໄຫວ, ການປົ່ງຮາກອອກຕາມ, ການດີບັກ, ເຄື່ອງມື, hooking, ແລະການທົດສອບ fuzz ໃນອຸປະກອນທີ່ເຂົາເຈົ້າສາມາດຄວບຄຸມໄດ້. ການເຮັດດັ່ງນັ້ນ, ນັກພັດທະນາສາມາດປ້ອງກັນບໍ່ໃຫ້ຜູ້ສະແດງທີ່ເປັນອັນຕະລາຍຈາກການຄົ້ນພົບຊ່ອງໂຫວ່ພາຍໃນ app ສໍາລັບການຂູດຮີດ.
ຄຳແນະນຳການຈັດຕັ້ງປະຕິບັດ
ນັກພັດທະນາຄວນປະຕິບັດຍຸດທະສາດການຊອກຄົ້ນຫາຕໍ່ໄປນີ້ເພື່ອກໍານົດລັກສະນະຕ່າງໆສໍາລັບການແກ້ໄຂການຈໍາລອງທີ່ໃຊ້ທົ່ວໄປ. ຄໍາແນະນໍາບາງຢ່າງຂອງສິ່ງທີ່ຕ້ອງກວດສອບແມ່ນ:
· ກວດ​ສອບ​ການ​ນໍາ​ໃຊ້​ຫມໍ້​ໄຟ​. ·ກວດສອບເວລາamps ແລະໂມງ. · ກວດ​ກາ​ເບິ່ງ​ພຶດ​ຕິ​ກໍາ​ການ​ສໍາ​ພັດ​ຫຼາຍ​. · ກວດ​ສອບ​ການ​ວິ​ເຄາະ​ຄວາມ​ຊົງ​ຈໍາ​ແລະ​ການ​ປະ​ຕິ​ບັດ​. ·ດໍາເນີນການກວດສອບເຄືອຂ່າຍ. ·ກວດເບິ່ງວ່າມັນເປັນຮາດແວທີ່ອີງໃສ່. ·ກວດເບິ່ງສິ່ງທີ່ເປັນ OS ອີງໃສ່. · ກວດເບິ່ງລາຍນິ້ວມືຂອງອຸປະກອນ. · ກວດ​ສອບ​ການ​ສ້າງ​ຕັ້ງ​. ·ກວດສອບການບໍລິການ emulator ແລະກິດ.
ຂ້າງເທິງນີ້ແມ່ນພຽງແຕ່ບາງ examples ຂອງການກວດສອບການປະຕິບັດທີ່ດີທີ່ສຸດທີ່ໃຊ້ໂດຍອຸດສາຫະກໍາ. ໃນຂະນະທີ່ລະບົບນິເວດຂອງອຸປະກອນມືຖືພັດທະນາ, ການກວດສອບເຫຼົ່ານີ້ອາດຈະລ້າສະໄຫມ. ດັ່ງນັ້ນ, ນັກພັດທະນາຄວນປະຕິບັດຕາມການປະຕິບັດທີ່ດີທີ່ສຸດຂອງອຸດສາຫະກໍາຫລ້າສຸດເພື່ອປະຕິບັດການຊອກຄົ້ນຫາ emulator. ສິ່ງທີ່ຄວນສັງເກດການຄວບຄຸມຄວາມປອດໄພນີ້ແມ່ນອ້າງອີງຢູ່ໃນມາດຕະຖານອື່ນໆ. ກະລຸນາເບິ່ງເອກະສານທີ່ລະບຸໄວ້ໃນ:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), pg. 31-32. · OWASP Mobile Application ຄູ່ມືການທົດສອບຄວາມປອດໄພ (MASTG) v1.7.0 (2023), ຫນ້າ. 325, 521.
41

ຄວາມຢືດຢຸ່ນ-BP04
ການຄວບຄຸມ
ແອັບຯດັ່ງກ່າວປະຕິບັດການກວດສອບຕ້ານ malware.
ລາຍລະອຽດ
ແອັບ Malware ຖືກໃຊ້ຫຼາຍຂຶ້ນໂດຍຜູ້ກະທຳທີ່ເປັນອັນຕະລາຍເປັນ vector ເພື່ອປະນີປະນອມອຸປະກອນມືຖືຂອງຜູ້ໃຊ້ ເນື່ອງຈາກອຸປະກອນດັ່ງກ່າວເຮັດໃຫ້ຜູ້ໃຊ້ມີຄວາມສະດວກສະບາຍທີ່ຈຳເປັນເພື່ອເຮັດທຸລະກຳໃນແຕ່ລະມື້. ແອັບ Malware ສ່ວນໃຫຍ່ໃຊ້ຄຸນສົມບັດການໂຫຼດດ້ານຂ້າງເປັນຊ່ອງທາງເພື່ອໃຫ້ຜູ້ໃຊ້ຕິດຕັ້ງ malware ໃນອຸປະກອນຂອງເຂົາເຈົ້າ.
ໂດຍການປະຕິບັດຄວາມສາມາດໃນການກວດຫາ malware ໃນແອັບຯໃນເວລາແລ່ນ, ຜູ້ພັດທະນາສາມາດປ້ອງກັນຜູ້ໃຊ້ຈາກການຖືກຂູດຮີດໂດຍຜ່ານ malware ຂຸດຄົ້ນຄວາມອ່ອນແອຂອງແອັບຯແລະຊ່ອງໂຫວ່ຂອງ OS, ການລັກເອົາຂໍ້ມູນປະຈໍາຕົວ, ການຄອບຄອງອຸປະກອນ, ແລະປະຕິບັດທຸລະກໍາການສໍ້ໂກງ.
ຄຳແນະນຳການຈັດຕັ້ງປະຕິບັດ
ນັກພັດທະນາຄວນປະຕິບັດຄວາມສາມາດໃນການກວດຫາ malware ໃນແອັບຯຂອງພວກເຂົາ. ນີ້ສາມາດເຮັດໄດ້ໃນຫຼາຍວິທີ, ແຕ່ບໍ່ຈໍາກັດພຽງແຕ່:
· ລວມເອົາຊຸດພັດທະນາຊອບແວຣ Runtime-Application-Self-Protection (RASP) (SDK) ເຂົ້າໃນແອັບຂອງເຂົາເຈົ້າ.
· ໃຊ້ RASP SDKs ເພື່ອກວດສອບ ແລະກວດຫາແອັບຯ malware ໃນ runtime. · ກວດເບິ່ງ ແລະ ປ້ອງກັນການຊ້ອນກັນ. · ປ້ອງກັນບໍ່ໃຫ້ clickjacking. · ປ້ອງ​ກັນ​ການ​ຕິດ​ຕັ້ງ​ຫນ່ວຍ​ຄວາມ​ຈໍາ app​.
ຂ້າງເທິງນີ້ແມ່ນພຽງແຕ່ບາງ examples ຂອງການກວດສອບການປະຕິບັດທີ່ດີທີ່ສຸດທີ່ໃຊ້ໂດຍອຸດສາຫະກໍາ. ໃນຂະນະທີ່ລະບົບນິເວດຂອງອຸປະກອນມືຖືພັດທະນາ, ການກວດສອບເຫຼົ່ານີ້ອາດຈະລ້າສະໄຫມ. ດັ່ງນັ້ນ, ນັກພັດທະນາຄວນປະຕິບັດຕາມການປະຕິບັດທີ່ດີທີ່ສຸດຂອງອຸດສາຫະກໍາຫລ້າສຸດເພື່ອປະຕິບັດການກວດສອບຕ້ານ malware.
ສິ່ງທີ່ຄວນສັງເກດ
ຖ້າມີຮູບແບບໃດນຶ່ງທີ່ເປັນອັນຕະລາຍຖືກກວດພົບ, ຜູ້ພັດທະນາຄວນປິດການໃຊ້ງານແອັບຯດັ່ງກ່າວ ແລະໃຫ້ຂໍ້ມູນທີ່ຈໍາເປັນແກ່ຜູ້ໃຊ້ວ່າ ເປັນຫຍັງແອັບຯຈຶ່ງຖືກປິດການນຳໃຊ້ ແລະຮຽກຮ້ອງໃຫ້ຜູ້ໃຊ້ຖອນການຕິດຕັ້ງແອັບຯທີ່ເປັນອັນຕະລາຍຢູ່ໃນອຸປະກອນຂອງເຂົາເຈົ້າ.
ອີກທາງເລືອກ, ນັກພັດທະນາຄວນເຕືອນຜູ້ໃຊ້, ແລະປິດການທໍາງານທີ່ມີຄວາມສ່ຽງສູງໃນແອັບຯຈົນກ່ວາຜູ້ໃຊ້ແກ້ໄຂແອັບຯທີ່ເປັນອັນຕະລາຍ. ການຄວບຄຸມຄວາມປອດໄພນີ້ແມ່ນອ້າງອີງຢູ່ໃນມາດຕະຖານອື່ນໆ. ກະລຸນາເບິ່ງເອກະສານທີ່ລະບຸໄວ້ໃນ:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), pg. 31. · ຄູ່ມືການຄຸ້ມຄອງຄວາມສ່ຽງດ້ານເຕັກໂນໂລຊີ MAS (2021), ໜ້າ. 40, 49. · ENISA Smartphone Secure Development Guidelines (2016), pg. 23.
42

ຄວາມຢືດຢຸ່ນ-BP05
ການຄວບຄຸມ
app ການ​ປະ​ຕິ​ບັດ​ກົນ​ໄກ​ຕ້ານ​ການ hooking​.
ລາຍລະອຽດ
Hooking ຫມາຍເຖິງເຕັກນິກທີ່ໃຊ້ໂດຍຜູ້ໂຈມຕີເພື່ອຂັດຂວາງຫຼືດັດແປງພຶດຕິກໍາຂອງແອັບຯມືຖືໃນເວລາແລ່ນ. ນີ້ກ່ຽວຂ້ອງກັບການແຊກ ຫຼືຕິດຢູ່ໃນຂັ້ນຕອນການປະຕິບັດຂອງແອັບເພື່ອຕິດຕາມການເຄື່ອນໄຫວຂອງມັນ, ປ່ຽນແປງພຶດຕິກຳຂອງມັນ, ໃສ່ລະຫັດທີ່ເປັນອັນຕະລາຍ ຫຼື ແກ້ໄຂຟັງຊັນລະຫັດທີ່ມີຢູ່ເພື່ອໃຊ້ຄວາມສ່ຽງ.
ໂດຍການປະຕິບັດກົນໄກຕ້ານການ hooking ໃນກິດ, ນັກພັດທະນາສາມາດປ້ອງກັນບໍ່ໃຫ້ການໂຈມຕີຂ້າງເທິງນີ້ເກີດຂຶ້ນແລະປ້ອງກັນການເຂົ້າເຖິງທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດ, ປົກປ້ອງການດໍາເນີນງານທີ່ມີຄວາມສ່ຽງສູງ, ກວດພົບແລະປ້ອງກັນ t.ampຄວາມ​ພະ​ຍາ​ຍາມ​ແລະ​ການ​ດັດ​ແກ້​, ປົກ​ປັກ​ຮັກ​ສາ​ຊັບ​ສິນ​ທາງ​ປັນ​ຍາ​ແລະ​ຮັກ​ສາ​ຄວາມ​ຫນ້າ​ເຊື່ອ​ຖື app​.
ຄຳແນະນຳການຈັດຕັ້ງປະຕິບັດ
ນັກພັດທະນາຄວນປະຕິບັດຕົວຢ່າງຕໍ່ໄປນີ້ample ກົນ​ໄກ​ເພື່ອ​ຫຼຸດ​ຜ່ອນ​ການ​ຕໍ່​ຕ້ານ​ການ​ໂຈມ​ຕີ hooking​:
· ປະຕິບັດການປ້ອງກັນເພື່ອສະກັດກັ້ນການສີດລະຫັດ. ·​ປະ​ຕິ​ບັດ​ການ​ປົກ​ປັກ​ຮັກ​ສາ​ເພື່ອ​ປ້ອງ​ກັນ​ການ​ຕິດ​ຕາມ​ວິ​ທີ​ການ​ໂດຍ​ການ​ປ້ອງ​ກັນ​ການ​ປັບ​ປຸງ app ໄດ້​
ລະຫັດແຫຼ່ງ (ທັງໃນລູກຄ້າແລະເຄື່ອງແມ່ຂ່າຍ). ·​ປະ​ຕິ​ບັດ​ການ​ປົກ​ປັກ​ຮັກ​ສາ​ເພື່ອ​ປ້ອງ​ກັນ​ການ​ປະ​ຕິ​ບັດ​ຂອງ​ລະ​ຫັດ​ດັດ​ແກ້​ໃນ app ຂອງ​ທ່ານ​. ·​ປະ​ຕິ​ບັດ​ການ​ປົກ​ປັກ​ຮັກ​ສາ​ເພື່ອ​ປ້ອງ​ກັນ​ການ​ເຂົ້າ​ເຖິງ​ຫນ່ວຍ​ຄວາມ​ຈໍາ​ແລະ​ການ​ຈັດ​ການ​ຫນ່ວຍ​ຄວາມ​ຈໍາ​ສໍາ​ລັບ app ຂອງ​ທ່ານ​. · ປະຕິບັດ tamper ຕ້ານ algorithms ຫຼືຕ້ານ tampSDKs (ເອີ້ນກັນທົ່ວໄປວ່າ
Runtime-Application-Self-Protection SDKs). ·ກວດເບິ່ງຕົວກໍານົດການທີ່ບໍ່ປອດໄພເຊັ່ນ APIs ທີ່ລ້າສະໄຫມແລະຕົວກໍານົດການ.
ຂ້າງເທິງນີ້ແມ່ນພຽງແຕ່ບາງ examples ຂອງການກວດສອບການປະຕິບັດທີ່ດີທີ່ສຸດທີ່ໃຊ້ໂດຍອຸດສາຫະກໍາ. ໃນຂະນະທີ່ລະບົບນິເວດຂອງອຸປະກອນມືຖືພັດທະນາ, ການກວດສອບເຫຼົ່ານີ້ອາດຈະລ້າສະໄຫມ. ດັ່ງນັ້ນ, ນັກພັດທະນາຄວນປະຕິບັດຕາມການປະຕິບັດທີ່ດີທີ່ສຸດຂອງອຸດສາຫະກໍາຫລ້າສຸດເພື່ອປະຕິບັດກົນໄກການຕ້ານການ hooking. ສິ່ງທີ່ຄວນສັງເກດການຄວບຄຸມຄວາມປອດໄພນີ້ແມ່ນອ້າງອີງຢູ່ໃນມາດຕະຖານອື່ນໆ. ກະລຸນາເບິ່ງເອກະສານທີ່ລະບຸໄວ້ໃນ:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), pg. 31. · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 135-140, 189, ສ.
318-319, 339-340, 390, 520. · ຄຳແນະນຳການຄຸ້ມຄອງຄວາມສ່ຽງດ້ານເຕັກໂນໂລຊີ MAS (2021), ໜ້າ. 56. · ENISA Smartphone Secure Development Guidelines (2016), pg. 23, 26.
43

ຄວາມຢືດຢຸ່ນ-BP06
ການຄວບຄຸມ
ແອັບປະຕິບັດການວາງຊ້ອນ, ຣີໂໝດ viewing, ແລະມາດຕະການຕອບໂຕ້ screenshot.
ລາຍລະອຽດ
ຂໍ້​ມູນ​ທີ່​ລະ​ອຽດ​ອ່ອນ​ສາ​ມາດ​ໄດ້​ຮັບ​ການ​ຈັບ​ຫຼື​ບັນ​ທຶກ​ໂດຍ​ບໍ່​ມີ​ການ​ຍິນ​ຍອມ​ເຫັນ​ດີ​ຂອງ​ຜູ້​ໃຊ້​ຢ່າງ​ຊັດ​ເຈນ​ໃນ​ເວ​ລາ​ທີ່ app ມີ​ການ​ບັນ​ທຶກ​ຫນ້າ​ຈໍ​, screenshot ຫຼື​ການ​ທໍາ​ງານ​ການ​ວາງ​ຊ້ອນ​. ຕົວຢ່າງample:
· Overlay ໂຈມຕີຫຼອກລວງຜູ້ໃຊ້ໂດຍການສ້າງ layer ປອມທີ່ເຮັດແບບຈໍາລອງກິດທີ່ເຊື່ອຖືໄດ້, ມີຈຸດປະສົງເພື່ອລັກຂໍ້ມູນລະອຽດອ່ອນ.
· ໄລຍະໄກ viewການ​ໂຈມ​ຕີ​ກ່ຽວ​ຂ້ອງ​ກັບ​ການ​ເຂົ້າ​ເຖິງ​ຫນ້າ​ຈໍ​ອຸ​ປະ​ກອນ​ໂດຍ​ບໍ່​ໄດ້​ອະ​ນຸ​ຍາດ​ໃຫ້​ຜູ້​ໂຈມ​ຕີ​ເກັບ​ກໍາ​ຂໍ້​ມູນ​ທີ່​ລະ​ອຽດ​ອ່ອນ​ຫ່າງ​ໄກ​ສອກ​ຫຼີກ​.
· ການ​ໂຈມ​ຕີ​ຮູບ​ພາບ​ຫນ້າ​ຈໍ​ເກີດ​ຂຶ້ນ​ໃນ​ເວ​ລາ​ທີ່​ຜູ້​ກະ​ທໍາ​ຮ້າຍ​ແຮງ​ຈັບ​ພາບ​ຫນ້າ​ຈໍ​ຂອງ​ອຸ​ປະ​ກອນ​ໂດຍ​ບໍ່​ມີ​ການ​ຍິນ​ຍອມ​ຂອງ​ຜູ້​ໃຊ້​, ການ​ດຶງ​ຂໍ້​ມູນ​ທີ່​ລະ​ອຽດ​ອ່ອນ​.
ການປະຕິບັດການຊ້ອນກັນ, ໄລຍະໄກ viewing ແລະ screenshot countermeasures ສາມາດຮັບປະກັນວ່າຂໍ້ມູນທີ່ລະອຽດອ່ອນຍັງຄົງປອດໄພ, ຄວາມເປັນສ່ວນຕົວຂອງຜູ້ໃຊ້ຖືກຮັກສາໄວ້ແລະຂໍ້ມູນລະອຽດອ່ອນແມ່ນໄດ້ຮັບການປົກປ້ອງຈາກການສູນເສຍໂດຍບໍ່ໄດ້ຕັ້ງໃຈຫຼືໃຊ້ໃນທາງທີ່ຜິດ.
ຄຳແນະນຳການຈັດຕັ້ງປະຕິບັດ
ນັກພັດທະນາຄວນປະຕິບັດການຕ້ານການ tampການກວດສອບການຕິດ ແລະຕ້ານ malware ຜ່ານ RASP SDKs ເພື່ອປ້ອງກັນແອັບຯທີ່ເປັນອັນຕະລາຍຈາກການໃຊ້ການວາງຊ້ອນກັນ, ແລະທາງໄກ. viewການຂູດຮີດ.
ສໍາລັບການ screenshots, ນັກພັດທະນາສາມາດນໍາໃຊ້ທຸງ FLAG_SECURE ສໍາລັບແອັບຯ Android ແລະທຸງທີ່ຄ້າຍຄືກັນສໍາລັບ iOS ເພື່ອສະກັດຄວາມສາມາດ screenshot ທັງຫມົດໃນເວລາທີ່ການນໍາໃຊ້ app ໄດ້. ຢ່າງ​ໃດ​ກໍ​ຕາມ, ສົມ​ມຸດ​ວ່າ​ຫນ້າ​ທີ່​ທຸ​ລະ​ກິດ​ຮຽກ​ຮ້ອງ​ໃຫ້​ມີ​ຄວາມ​ສາ​ມາດ screenshot (ເຊັ່ນ​: ການ​ຖ່າຍ​ຮູບ​ພາບ​ຫນ້າ​ຈໍ​ຂອງ​ການ​ສໍາ​ເລັດ​ການ PayNow​)​. ໃນກໍລະນີດັ່ງກ່າວ, ຄໍາແນະນໍາແມ່ນເພື່ອປິດຄວາມສາມາດ screenshot ສໍາລັບຫນ້າຈໍຫຼືຫນ້າທີ່ປະກອບມີຂໍ້ມູນທີ່ລະອຽດອ່ອນ (PII ແລະຂໍ້ມູນການພິສູດຢືນຢັນ).
ນັກພັດທະນາຍັງສາມາດພິຈາລະນາການປິດບັງການປ້ອນຂໍ້ມູນທີ່ມີຂໍ້ມູນລະອຽດອ່ອນ ແລະໜ້າຈໍເຊັນເຊີ ເມື່ອແອັບຖືກພື້ນຫຼັງ.
ສິ່ງທີ່ຄວນສັງເກດ
ບາງຄົນ examples ຂອງບ່ອນທີ່ຈະປິດຄວາມສາມາດ screenshot ເຫຼົ່ານີ້ປະກອບມີແຕ່ບໍ່ຈໍາກັດພຽງແຕ່: ຫນ້າເຂົ້າສູ່ລະບົບ, ຫນ້າການກວດສອບຫຼາຍປັດໄຈ, ໃບຢັ້ງຢືນຄວາມປອດໄພ, ແລະຫນ້າການປ່ຽນແປງ PII, ແລະອື່ນໆ.
ການຄວບຄຸມຄວາມປອດໄພນີ້ແມ່ນອ້າງອີງຢູ່ໃນມາດຕະຖານອື່ນໆ. ກະລຸນາເບິ່ງເອກະສານທີ່ລະບຸໄວ້ໃນ:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), pg. 31. · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 166-168, 257, ສ.
259, 265-267, 366, 480-481. · ຄູ່ມືການຄຸ້ມຄອງຄວາມສ່ຽງດ້ານເຕັກໂນໂລຊີ MAS (2021), ໜ້າ. 56. · ENISA Smartphone Secure Development Guidelines (2016), pg. 8.
44

ຄວາມຢືດຢຸ່ນ-BP07
ການຄວບຄຸມ
ແອັບດັ່ງກ່າວປະຕິບັດການຈັບພາບຕ້ານການກົດແປ້ນພິມ ຫຼືການຕ້ານການກົດແປ້ນພິມຕໍ່ກັບແປ້ນພິມສະເໝືອນຂອງພາກສ່ວນທີສາມ.
ລາຍລະອຽດ
ການຈັບປຸ່ມກົດ ແລະ ການລັອກປຸ່ມກົດແມ່ນວິທີການທີ່ຜູ້ກະທຳອັນຕະລາຍໃຊ້ເພື່ອຕິດຕາມ, ບັນທຶກ ແລະບັນທຶກປຸ່ມທີ່ກົດໃສ່ແປ້ນພິມໂດຍທີ່ຜູ້ໃຊ້ບໍ່ຮູ້ ແລະ ຍິນຍອມ. ອັນນີ້ອະນຸຍາດໃຫ້ບັນທຶກ ແລະບັນທຶກຂໍ້ມູນທີ່ມີທ່າແຮງ (ເຊັ່ນ: PII ແລະຂໍ້ມູນການພິສູດຢືນຢັນ).
ໂດຍການປະຕິບັດມາດຕະການຕອບໂຕ້ການກົດແປ້ນພິມແລະການລັອກລະຫັດ, ນັກພັດທະນາສາມາດປ້ອງກັນການສູນເສຍຂໍ້ມູນທີ່ລະອຽດອ່ອນທີ່ບໍ່ຈໍາເປັນ. ໂດຍສະເພາະ, ການຄວບຄຸມນີ້ແມ່ນແນໃສ່ອຸປະກອນ Android, ຍ້ອນວ່າແປ້ນພິມພື້ນເມືອງຂອງອຸປະກອນ Android ສາມາດປ່ຽນແປງໄດ້. ການປ່ຽນແປງດັ່ງກ່າວສາມາດເປີດເຜີຍໃຫ້ແອັບຯເຫັນຊ່ອງໂຫວ່ດ້ານຄວາມປອດໄພ ເນື່ອງຈາກເສັ້ນທາງທີ່ເຊື່ອຖືໄດ້ລະຫວ່າງການປ້ອນແປ້ນພິມ ແລະແອັບຯຕ່າງໆມີພາກສ່ວນທີ່ບໍ່ເຊື່ອຖືລະຫວ່າງພວກມັນ.
ຄຳແນະນຳການຈັດຕັ້ງປະຕິບັດ
ຜູ້ພັດທະນາບໍ່ຄວນອະນຸຍາດໃຫ້ໃຊ້ແປ້ນພິມສະເໝືອນຂອງພາກສ່ວນທີສາມທີ່ບໍ່ປອດໄພສໍາລັບການປ້ອນຂໍ້ມູນທີ່ອາດມີຂໍ້ມູນທີ່ລະອຽດອ່ອນ. ແປ້ນພິມແບບກຳນົດເອງໃນແອັບທີ່ປອດໄພແມ່ນເປັນທີ່ມັກສໍາລັບການປ້ອນຂໍ້ມູນດັ່ງກ່າວ.
ໂດຍການປະຕິບັດແປ້ນພິມໃນແອັບຯ, ນັກພັດທະນາສາມາດຄວບຄຸມບ່ອນທີ່ຂໍ້ມູນບັນທຶກໄປແລະຫຼຸດຜ່ອນຄວາມສ່ຽງຂອງແປ້ນພິມສະເໝືອນຂອງພາກສ່ວນທີສາມທີ່ບໍ່ປອດໄພເຮັດຫນ້າທີ່ເປັນຕົວລັອກເພື່ອບັນທຶກການກົດແປ້ນພິມ.
ຄຽງຄູ່ກັບການໃຊ້ແປ້ນພິມໃນແອັບຯ, ຜູ້ພັດທະນາຄວນປະຕິບັດຄໍາແນະນໍາຕໍ່ໄປນີ້ສໍາລັບການປ້ອນຂໍ້ມູນທີ່ຕ້ອງການຂໍ້ມູນລະອຽດອ່ອນ (ເຊັ່ນ: PII ແລະຂໍ້ມູນການກວດສອບຄວາມຖືກຕ້ອງ): ປິດການທໍາການແກ້ໄຂອັດຕະໂນມັດ, ຕື່ມຂໍ້ມູນອັດຕະໂນມັດ, ແນະນໍາອັດຕະໂນມັດ, ຕັດ, ສຳເນົາ ແລະວາງສໍາລັບຟັງຊັນ/ຫຼືແອັບຯທີ່ມີຂໍ້ມູນລະອຽດອ່ອນ. .
ສິ່ງທີ່ຄວນສັງເກດບາງ examples ຂອງຫນ້າທີ່ຄວນໃຊ້ແປ້ນພິມໃນແອັບຯປະກອບມີແຕ່ບໍ່ຈໍາກັດພຽງແຕ່ການເຂົ້າສູ່ລະບົບ, ການປ້ອນ OTP, ຫຼືປັດໃຈການຢັ້ງຢືນອື່ນໆ, ແລະອື່ນໆ.
ການຄວບຄຸມຄວາມປອດໄພ ແລະການປະຕິບັດທີ່ດີທີ່ສຸດນີ້ແນໃສ່ອຸປະກອນ Android ຕົ້ນຕໍ. ເປົ້າຫມາຍຕົ້ນຕໍແມ່ນເພື່ອຮັບປະກັນຄວາມປອດໄພຂອງເສັ້ນທາງທີ່ເຊື່ອຖືໄດ້. ເນື່ອງຈາກ Android ບໍ່ໄດ້ໃຫ້ວິທີການບັງຄັບໃຊ້ແປ້ນພິມພື້ນເມືອງ/ທີ່ເຊື່ອຖືໄດ້, ນັກພັດທະນາຄວນປະຕິບັດແປ້ນພິມໃນແອັບເພື່ອຮັບປະກັນວ່າແປ້ນພິມສະເໝືອນຂອງພາກສ່ວນທີສາມທີ່ບໍ່ປອດໄພຈະບໍ່ບັນທຶກຂໍ້ມູນ.
ການປະຕິບັດແປ້ນພິມໃນແອັບຯທີ່ປອດໄພບໍ່ໄດ້ຫຼຸດຜ່ອນຄວາມສ່ຽງທີ່ກ່ຽວຂ້ອງກັບອຸປະກອນທີ່ຖືກທໍາລາຍ.
ການຄວບຄຸມຄວາມປອດໄພນີ້ແມ່ນອ້າງອີງຢູ່ໃນມາດຕະຖານອື່ນໆ. ກະລຸນາເບິ່ງເອກະສານທີ່ລະບຸໄວ້ໃນ:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), pg. 31. · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), pg. 203, 214-215, ສ.
257, 259, 400, 414-415. · ຄູ່ມືການຄຸ້ມຄອງຄວາມສ່ຽງດ້ານເຕັກໂນໂລຊີ MAS (2021), ໜ້າ. 56. · ENISA Smartphone Secure Development Guidelines (2016), pg. 08, 23.
45

ເອກະສານອ້າງອີງ

S/N 1
2
3
4
5
6 7

Document OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 MAS Technology Guidelines Management Risk Guidelines, PCI Mobile Payment Acceptance Security Guidelines v2.0.0 ENISA Smartphone Secure Guidelines Android Developers Apple Developer Documentation

ແຫຼ່ງ OWASP
OWASP
ມະຫາຊົນ
PCI-DSS
ENISA
Android Apple

ລົງວັນທີ 2023
2023
2021
2017
2016
2024 2024

46

ເອກະສານ / ຊັບພະຍາກອນ

ແອັບມາດຕະຖານຄວາມປອດໄພ CSA [pdf] ຄູ່ມືຜູ້ໃຊ້ ແອັບມາດຕະຖານປອດໄພ, ມາດຕະຖານປອດໄພ, ແອັບ

ເອກະສານອ້າງອີງ

• ຄູ່ມືຜູ້ໃຊ້