ຄູ່ມືການຈັດຕັ້ງປະຕິບັດ
ເຮັດໃຫ້ MFA ຂອງທ່ານປັບຕົວດ້ວຍແມ່ແບບການປະຕິບັດ
ຄວາມເປັນມາ
ການກວດສອບຄວາມຖືກຕ້ອງຫຼາຍປັດໃຈແບບປັບຕົວ (MFA) ຫຼຸດຜ່ອນຄວາມຂັດແຍ້ງສໍາລັບຜູ້ໃຊ້ທີ່ຖືກຕ້ອງຕາມກົດຫມາຍໂດຍການປະເມີນຄວາມສ່ຽງດ້ານການເຮັດທຸລະກໍາກັບການຮຽນຮູ້ເຄື່ອງຈັກ (ML) algorithms, ດັ່ງນັ້ນຜູ້ໃຊ້ທີ່ຮູ້ຈັກໃນພື້ນທີ່ປົກກະຕິຂອງພວກເຂົາຖືກຕິດຕາມຢ່າງໄວວາໃນເວທີຂອງທ່ານ.
ແຕ່, ມັນໃຊ້ເວລາເພື່ອສ້າງເຄື່ອງຈັກຄວາມສ່ຽງຈາກການເລີ່ມຕົ້ນ, ແລະການໄດ້ຮັບສິດທິ MFA ສາມາດເຮັດໃຫ້ຄວາມແຕກຕ່າງລະຫວ່າງການສ້າງຄວາມໄວ້ວາງໃຈຂອງຜູ້ບໍລິໂພກ, ແລະຜູ້ໃຊ້ປະຖິ້ມເວທີຂອງທ່ານເພາະວ່າມີຂັ້ນຕອນຫຼາຍເກີນໄປທີ່ຈະເຂົ້າສູ່ລະບົບ.
ເພື່ອໃຫ້ພະລັງງານແບບ Adaptive MFA, Okta CIC ມີຄະແນນຄວາມເຊື່ອໝັ້ນ ML ທີ່ມີຢູ່ນອກກ່ອງເພື່ອໃຫ້ເຫມາະສົມກັບຄວາມຕ້ອງການການປະເມີນຄວາມສ່ຽງຂອງທ່ານ, ເພື່ອປັບປຸງ UX ແລະຄວາມປອດໄພສໍາລັບຜູ້ໃຊ້ທຸກຄົນທີ່ຕ້ອງການເຂົ້າເຖິງເວທີຂອງທ່ານ.
ທ່ານສາມາດນໍາໃຊ້ການຄິດໄລ່ ML ນີ້ກັບການປະຕິບັດ, ແລະສ້າງໂຄງການ Adaptive MFA ຂອງທ່ານເອງທີ່ແກ້ໄຂຈຸດຕາບອດທີ່ MFA standalone ອາດຈະພາດ, ເຊັ່ນ:
- ເຈົ້າຮັກສາເຊດຊັນຂອງຜູ້ໃຊ້ທີ່ຖືກຕ້ອງຕາມກົດໝາຍແນວໃດບໍ່ໃຫ້ຕິດຂັດ ແຕ່ຂັດຂວາງການຈະລາຈອນທີ່ບໍ່ຕ້ອງການ?
- ເມື່ອໃດທີ່ເຫມາະສົມທີ່ຈະນໍາສະເຫນີປັດໄຈທີສອງຫຼືທີສາມ?
- ສິ່ງທີ່ຖືວ່າເປັນພື້ນຖານສໍາລັບການຮັກສາແພລະຕະຟອມຂອງທ່ານໃຫ້ປອດໄພກັບ MFA?
ໃນບົດຂຽນນີ້, ພວກເຮົາຈະເວົ້າເຖິງວິທີການໃຊ້ການກະ ທຳ, ແລະສິ່ງທີ່ແມ່ແບບການກະ ທຳ ທີ່ມີຢູ່ນອກກ່ອງເພື່ອຕີພື້ນທີ່ເຮັດວຽກເມື່ອເວົ້າເຖິງການປະຕິບັດທີ່ດີທີ່ສຸດຂອງ MFA.
ເປັນສ່ວນຫນຶ່ງຂອງກອບການຂະຫຍາຍຂອງພວກເຮົາ, ການປະຕິບັດແມ່ນເຫດຜົນແບບລາກແລະວາງ pro-code / no-code ທີ່ທ່ານສາມາດປັບແຕ່ງສໍາລັບຄໍາຮ້ອງສະຫມັກຂອງທ່ານເອງແລະການເຊື່ອມໂຍງທີ່ເລີ່ມຕົ້ນດ້ວຍ Identity.
ການປະຕິບັດຊ່ວຍໃຫ້ທ່ານເພີ່ມລະຫັດໃສ່ຈຸດສໍາຄັນໃນທໍ່ການພິສູດຢືນຢັນພຽງແຕ່ javascript — ແລະໂມດູນ 2M+ npm ໃນການກໍາຈັດຂອງທ່ານ.
ແມ່ແບບການກະ ທຳ ສອນໃຫ້ເຈົ້າຮູ້ວິທີໃຊ້ອຳນາດຂອງການປະຕິບັດ, ແລະເຂົ້າສູ່ຕະຫຼາດໄວກວ່າການແຂ່ງຂັນ, ແກ້ໄຂກໍລະນີການນຳໃຊ້ທົ່ວໄປທີ່ຈຳເປັນສຳລັບອົງກອນໃນທຸກມື້ນີ້.
ແມ່ແບບ #1
ຕ້ອງການການລົງທະບຽນ MFA
ການລົງທະບຽນເປັນໂອກາດທີ່ເປັນເອກະລັກເພື່ອໃຫ້ຜູ້ໃຊ້ເລືອກໃນເວລາທີ່ມັນມາກັບການກວດສອບຄວາມຖືກຕ້ອງ.
ອີງຕາມຄວາມມັກຂອງການກວດສອບຜູ້ໃຊ້, ທ່ານຫຼຸດລົງ friction ສໍາລັບພວກເຂົາ, ແລະໃຫ້ພວກເຂົາຂຶ້ນເຮືອດ້ວຍທ່າທາງຄວາມປອດໄພຂອງທ່ານ.
ໃຫ້ເລີ່ມຕົ້ນດ້ວຍ ຕ້ອງການການລົງທະບຽນ MFA ແມ່ແບບການປະຕິບັດ.
ທ່ອງໄປຫາ ຄຳສັ່ງ > ຫ້ອງສະໝຸດ > ສ້າງຈາກແມ່ແບບ.
ນີ້ແມ່ນເນື້ອໃນຂອງແມ່ແບບ:
exports.onExecutePostLogin = async (ເຫດການ, api) => {
ຖ້າ (!event.user.multifactor?.length) {
api.multifactor.enable('any', { allowRememberBrowser: false });
}
};
ມີຫຍັງເກີດຂຶ້ນຢູ່ນີ້: ຖ້າບໍ່ມີປັດໃຈ MFA ໃດໆທີ່ລົງທະບຽນ, ໃຫ້ຜູ້ໃຊ້ຂອງເຈົ້າລົງທະບຽນໃນສິ່ງທີ່ເຈົ້າມີໃຫ້.
ແມ່ແບບແມ່ນພຽງແຕ່ການເລີ່ມຕົ້ນ - ໃຫ້ພວກເຮົາເບິ່ງເຫດການແລະວັດຖຸ api:
ໄດ້ ວັດຖຸເຫດການ ມີຕົວກໍານົດການທີ່ແຕກຕ່າງກັນຫຼາຍ, ເຊິ່ງປະກອບມີຂໍ້ມູນກ່ຽວກັບຜູ້ໃຊ້, ທີ່ທ່ານສາມາດນໍາໃຊ້ເພື່ອປັບແຕ່ງຄວາມຕ້ອງການ MFA ຂອງທ່ານ; ໃນກໍລະນີນີ້, ພວກເຮົາກໍາລັງສໍາຫຼວດອາເຣຂອງປັດໄຈ MFA ທີ່ມີຢູ່, event.user.multifactor?.length , ແລະຖ້າຫາກວ່າບໍ່ມີ (!) ການລົງທະບຽນ, ສືບຕໍ່ມີການລົງທະບຽນ.
ພິຈາລະນາຮຽກຮ້ອງໃຫ້ມີຫຼືລະບຸຜູ້ໃຫ້ບໍລິການທີ່ແຕກຕ່າງກັນ ຜ່ານວັດຖຸ API — ປັດໃຈລວມມີ: duo, google-authentiator, guardian .
api.multifactor.enable(ຜູ້ໃຫ້ບໍລິການ, ທາງເລືອກ)
ຕົວເລືອກຕ່າງໆເຊັ່ນ allowRememberBrowser ກໍານົດວ່າຕົວທ່ອງເວັບຄວນຈະຖືກຈື່, ດັ່ງນັ້ນຜູ້ໃຊ້ສາມາດຂ້າມ MFA ໃນພາຍຫຼັງ. ນີ້ແມ່ນ boolean ທາງເລືອກ, ແລະຄ່າເລີ່ມຕົ້ນແມ່ນບໍ່ຖືກຕ້ອງ. ເຈົ້າສາມາດ ແກ້ໄຂທາງເລືອກນີ້ຜ່ານ API ການຈັດການ.
ໂດຍການນໍາໃຊ້, ຫຼັງຈາກນັ້ນລາກແລະການຫຼຸດລົງການປະຕິບັດໃຫມ່ຂອງທ່ານເຂົ້າໄປໃນການເຂົ້າສູ່ລະບົບ (ຄຳສັ່ງ > ກະແສ > ເຂົ້າສູ່ລະບົບ) ແລະການເລືອກ ສະໝັກ, ຜູ້ໃຊ້ຂອງທ່ານຕອນນີ້ຕ້ອງການລົງທະບຽນໃນ MFA:
ເຮັດຊ້ຳຂັ້ນຕອນຂ້າງເທິງທຸກຄັ້ງທີ່ເຈົ້າຕ້ອງການເພີ່ມການກະທຳໃສ່ຕົວກະຕຸ້ນໃນທໍ່ການພິສູດຢືນຢັນ.
ການປັບຕົວກັບ MFA ຂອງທ່ານ
ທ່ອງໄປຫາ ຄວາມປອດໄພ > ການພິສູດຢືນຢັນຫຼາຍປັດໃຈ, ແລະເລືອກປັດໃຈທີ່ທ່ານຕ້ອງການທີ່ຈະມີໃຫ້ກັບຜູ້ໃຊ້ສຸດທ້າຍຂອງທ່ານ.
ເລື່ອນລົງໄປ ທາງເລືອກເພີ່ມເຕີມ, ແລະສະຫຼັບທາງເລືອກທີ່ຈະ ປັບແຕ່ງປັດໄຈ MFA ໂດຍໃຊ້ການປະຕິບັດ. ອັນນີ້ອະນຸຍາດໃຫ້ທ່ານເພີ່ມເຫດຜົນການກະທຳຂອງທ່ານເອງດ້ວຍອັດສະລິຍະ Adaptive MFA ML ຂອງພວກເຮົານອກກ່ອງ.
ນີ້ແມ່ນບາງສ່ວນຂອງຂໍ້ມູນຕົ້ນຕໍທີ່ຈະພິຈາລະນາກ່ຽວກັບການເຮັດທຸລະກໍາຂອງຜູ້ໃຊ້ໃນເວລາທີ່ການເຂົ້າລະຫັດໃຫ້ກົງກັບ playbooks ຄວາມປອດໄພຂອງທ່ານ:
- ເງື່ອນໄຂໃດແດ່ທີ່ຂ້ອຍຕ້ອງການໃຫ້ຜູ້ໃຊ້ຂອງຂ້ອຍຢືນຢັນຄືນໃຫມ່?
- ຂໍ້ມູນກອງປະຊຸມຂອງພວກເຂົາມີຄວາມສໍາຄັນແນວໃດເມື່ອເວົ້າເຖິງການເຮັດທຸລະກໍາທີ່ມອບໃຫ້?
- ຂໍ້ຈໍາກັດນະໂຍບາຍຂອງບໍລິສັດໃດທີ່ແປເປັນນະໂຍບາຍຄໍາຮ້ອງສະຫມັກ?
ດ້ວຍການພິຈາລະນາເຫຼົ່ານີ້ຢູ່ໃນໃຈ, ໃຫ້ພວກເຮົາຍ່າງຜ່ານ, ຂັ້ນຕອນໂດຍຂັ້ນຕອນ, ວິທີການປະຕິບັດການປັບຕົວ MFA ກັບແມ່ແບບການປະຕິບັດ.
ແມ່ແບບ #2
ກະຕຸ້ນ MFA ເມື່ອເງື່ອນໄຂບັນລຸໄດ້
ແມ່ແບບນີ້ໃຊ້ການປັບຕົວຄະແນນຄວາມສ່ຽງ / ຄວາມຫມັ້ນໃຈ MFA ຂອງພວກເຮົາ - ອີງຕາມການປະເມີນຄວາມສ່ຽງ, ທ່ານສາມາດຮັກສາຕົວລະຄອນທີ່ບໍ່ດີ, ແຕ່ຍັງສ້າງຄວາມສໍາພັນດ້ານຄວາມປອດໄພກັບລູກຄ້າຂອງທ່ານເພື່ອຮັບໃຊ້ຕົນເອງດ້ວຍປັດໃຈໃນກໍລະນີທີ່ກວດພົບພຶດຕິກໍາໃຫມ່ຫຼືຜິດປົກກະຕິ.
ໃນແມ່ແບບນີ້, newDevice ແມ່ນເງື່ອນໄຂທີ່ຖືກປະເມີນສໍາລັບການເຕືອນ MFA ເພີ່ມເຕີມ; ທ່ານມີດັ່ງຕໍ່ໄປນີ້ ວັດຖຸປະເມີນຄວາມສ່ຽງ ມີໃຫ້ສໍາຫຼວດຄະແນນຄວາມຫມັ້ນໃຈ:
- ອຸປະກອນໃໝ່
- ການເດີນທາງທີ່ເປັນໄປບໍ່ໄດ້
- IP ທີ່ບໍ່ເຊື່ອຖື
- ເບີໂທລະສັບ
ທ່ານຍັງສາມາດສົມທົບການປະເມີນຜົນເພື່ອເຮັດໃຫ້ການກໍານົດກ່ຽວກັບ ຜົນຂອງການປະຕິບັດ; ສໍາລັບ example, ຖ້າຫາກວ່າການເດີນທາງເປັນໄປບໍ່ໄດ້ເກີດຂຶ້ນ, ທ່ານສາມາດເຮັດໄດ້ ຂັດຂວາງການເຮັດທຸລະກໍາຂອງຜູ້ໃຊ້ທັງຫມົດ.
exports.onExecutePostLogin = async (ເຫດການ, api) => {
// ຕັດສິນໃຈວ່າຄະແນນຄວາມໝັ້ນໃຈໃດຄວນກະຕຸ້ນ MFA, ສໍາລັບຫຼາຍກວ່ານັ້ນ
ຂໍ້ມູນອ້າງອີງ
// https://auth0.com/docs/secure/multi-factor-authentication/adaptivemfa/
customize-adaptive-mfa#confidence-scores
const promptConfidences = ['ຕໍ່າ', 'ປານກາງ'];
// ຕົວຢ່າງample ເງື່ອນໄຂ: prompt MFA ພຽງແຕ່ອີງໃສ່ NewDevice
// ລະດັບຄວາມຫມັ້ນໃຈ, ນີ້ຈະເຕືອນສໍາລັບ MFA ເມື່ອຜູ້ໃຊ້ກໍາລັງເຂົ້າສູ່ລະບົບ
in
// ຈາກອຸປະກອນທີ່ບໍ່ຮູ້ຈັກ.
const ຄວາມຫມັ້ນໃຈ =
event.authentication?.riskAssessment?.assessments?.NewDevice
?ຄວາມໝັ້ນໃຈ;
const ຄວນPromptMfa =
ຄວາມຫມັ້ນໃຈ && promptConfidences.includes(ຄວາມຫມັ້ນໃຈ);
// ມັນພຽງແຕ່ເຮັດໃຫ້ຄວາມຮູ້ສຶກທີ່ຈະກະຕຸ້ນເຕືອນສໍາລັບ MFA ເມື່ອຜູ້ໃຊ້ມີຢ່າງຫນ້ອຍ
ຫນຶ່ງ
// ປັດໄຈ MFA ລົງທະບຽນ.
const canPromptMfa =
event.user.multifactor && event.user.multifactor.length > 0;
ຖ້າ (shouldPromptMfa && canPromptMfa) {
api.multifactor.enable('any', { allowRememberBrowser: true });
}
};
ແມ່ແບບ #3
ກະຕຸ້ນ MFA ເມື່ອ IP ທີ່ຮ້ອງຂໍແມ່ນມາຈາກນອກຂອບເຂດ IP ສະເພາະ
ແມ່ແບບນີ້ຈໍາກັດການເຂົ້າເຖິງແອັບພລິເຄຊັນທີ່ໃຫ້ເວົ້າ, ເຄືອຂ່າຍຂອງບໍລິສັດ, ແລະ ໃຊ້ຫ້ອງສະໝຸດ ipaddr.js ເພື່ອວິເຄາະ IPs, ແລະ, ໃນກໍລະນີນີ້, ກະຕຸ້ນການແຈ້ງເຕືອນຜ່ານ Guardian:
exports.onExecutePostLogin = async (ເຫດການ, api) => {
const ipaddr = require('ipaddr.js');
// ໄດ້ຮັບ CIDR ທີ່ເຊື່ອຖືໄດ້ແລະໃຫ້ແນ່ໃຈວ່າມັນຖືກຕ້ອງ
const corp_network = event.secrets.TRUSTED_CIDR;
ຖ້າ (!corp_network) {
ກັບຄືນ api.access.deny('ການຕັ້ງຄ່າບໍ່ຖືກຕ້ອງ');
}
// ແຍກຄໍາຮ້ອງຂໍ IP ຈາກແລະໃຫ້ແນ່ໃຈວ່າມັນຖືກຕ້ອງ
ໃຫ້ current_ip;
ພະຍາຍາມ {
current_ip = ipaddr.parse(event.request.ip);
} ຈັບ (ຜິດພາດ) {
ກັບຄືນ api.access.deny('ຄໍາຮ້ອງຂໍບໍ່ຖືກຕ້ອງ');
}
// ວິເຄາະ CIDR ແລະຮັບປະກັນຄວາມຖືກຕ້ອງ
ໃຫ້ cidr;
ພະຍາຍາມ {
cidr = ipaddr.parseCIDR(corp_network);
} ຈັບ (ຜິດພາດ) {
ກັບຄືນ api.access.deny('ການຕັ້ງຄ່າບໍ່ຖືກຕ້ອງ');
}
// ບັງຄັບຜູ້ຄຸ້ມຄອງ MFA ຖ້າ IP ບໍ່ຢູ່ໃນການຈັດສັນທີ່ເຊື່ອຖືໄດ້
ຖ້າ (!current_ip.match(cidr)) {
api.multifactor.enable('guardian', { allowRememberBrowser: false });
}
};
ແມ່ແບບ #4
ຕ້ອງການ MFA ຫນຶ່ງຄັ້ງຕໍ່ກອງປະຊຸມ
ແມ່ແບບນີ້ເຮັດບາງສິ່ງບາງຢ່າງທີ່ແຕກຕ່າງຈາກຕົວອື່ນເລັກນ້ອຍ.
ແທນທີ່ຈະຮັກສາຜູ້ໃຊ້ອອກ, ການຕັ້ງຄ່ານີ້ຊ່ວຍໃຫ້ທ່ານບັນລຸໄດ້ ການພິສູດຢືນຢັນແບບງຽບ, ເຊິ່ງສະຫນັບສະຫນູນຜູ້ໃຊ້ທີ່ຈະໄປກ່ຽວກັບກອງປະຊຸມຂອງເຂົາເຈົ້າຈາກພື້ນຖານຂອງຕົວທ່ອງເວັບປົກກະຕິຂອງເຂົາເຈົ້າ stomping ໂດຍບໍ່ຈໍາເປັນຕ້ອງໄດ້ຮັບການກະຕຸ້ນເຕືອນສໍາລັບ MFA.
exports.onExecutePostLogin = async (ເຫດການ, api) => {
// ຖ້າ array ຂອງວິທີການກວດສອບຄວາມຖືກຕ້ອງແລະປະກອບດ້ວຍ a
ວິທີການທີ່ມີຊື່ວ່າ 'mfa', mfa ໄດ້ຖືກເຮັດໃນກອງປະຊຸມນີ້ແລ້ວ
ຖ້າ (
!event.authentication ||
!Array.isArray(event.authentication.methods) ||
!event.authentication.methods.find((ວິທີການ) => method.name === 'mfa')
) {
api.multifactor.enable('any');
}
};
ສະຫຼຸບ
ແມ່ແບບຂອງພວກເຮົາໄດ້ກວມເອົາວິທີການບັງຄັບໃຊ້ MFA ກ່ຽວກັບການລົງທະບຽນ, ພາຍນອກເຄືອຂ່າຍຂອງບໍລິສັດ, ຕໍ່ກອງປະຊຸມ, ແລະການເລີ່ມຕົ້ນຂອງການປະຕິບັດ MFA ທີ່ມີການປັບຕົວ.
ເທມເພດທັງໝົດເຫຼົ່ານີ້ເຮັດໃຫ້ການເຂົ້າສູ່ລະບົບແບບ Universal Login ຂອງພວກເຮົາເຮັດວຽກແນວໃດໃນສະພາບການການພິສູດຢືນຢັນທີ່ແຕກຕ່າງກັນ, ຊຶ່ງຫມາຍຄວາມວ່າທ່ານສາມາດອອກຈາກ UX ໃຫ້ພວກເຮົາ.
ດ້ວຍການປະຕິບັດ, ທ່ານສາມາດສ້າງກະແສຄວາມປອດໄພທັງຫມົດເພື່ອໃຫ້ກົງກັບກໍລະນີການນໍາໃຊ້ຄວາມປອດໄພຂອງອົງການຂອງທ່ານ, ແລະຍັງກໍາຈັດຄວາມຂັດແຍ້ງສໍາລັບຜູ້ໃຊ້ທີ່ຖືກຕ້ອງຕາມກົດຫມາຍທີ່ມີລະດັບຄວາມໄວ້ວາງໃຈສູງ.
ກ່ຽວກັບ Okta
Okta ແມ່ນບໍລິສັດເອກະລັກຂອງໂລກ. ໃນຖານະທີ່ເປັນຄູ່ຮ່ວມງານດ້ານການລະບຸຕົວຕົນທີ່ເປັນເອກະລາດຊັ້ນນໍາ, ພວກເຮົາປ່ອຍໃຫ້ທຸກຄົນສາມາດນຳໃຊ້ເທັກໂນໂລຢີຕ່າງໆໄດ້ຢ່າງປອດໄພ — ຢູ່ບ່ອນໃດກໍ່ຕາມ, ໃນອຸປະກອນ ຫຼືແອັບໃດກໍໄດ້. ຍີ່ຫໍ້ທີ່ເຊື່ອຖືໄດ້ຫຼາຍທີ່ສຸດໄວ້ວາງໃຈ Okta ເພື່ອເຮັດໃຫ້ການເຂົ້າເຖິງທີ່ປອດໄພ, ການກວດສອບຄວາມຖືກຕ້ອງ, ແລະອັດຕະໂນມັດ. ດ້ວຍຄວາມຢືດຢຸ່ນ ແລະຄວາມເປັນກາງຢູ່ໃນຫຼັກຂອງ Okta Workforce Identity ແລະ Customer Identity Clouds ຂອງພວກເຮົາ, ຜູ້ນໍາທຸລະກິດ ແລະນັກພັດທະນາສາມາດສຸມໃສ່ການປະດິດສ້າງ ແລະເລັ່ງການຫັນເປັນດິຈິຕອນ, ຂໍຂອບໃຈກັບການແກ້ໄຂທີ່ປັບແຕ່ງໄດ້ ແລະຫຼາຍກວ່າ 7,000 ການເຊື່ອມໂຍງກ່ອນສ້າງ. ພວກເຮົາກຳລັງສ້າງໂລກທີ່ Identity ເປັນຂອງເຈົ້າ. ສຶກສາເພີ່ມເຕີມໄດ້ທີ່ okta.com.
Auth0 ເປັນເທັກໂນໂລຍີພື້ນຖານຂອງ Okta ແລະສາຍຜະລິດຕະພັນທີ່ໂດດເດັ່ນ — Okta Customer Identity Cloud. ນັກພັດທະນາສາມາດຮຽນຮູ້ເພີ່ມເຕີມ ແລະສ້າງບັນຊີໄດ້ຟຣີທີ່ Auth0.com.
ເອກະສານ / ຊັບພະຍາກອນ
 |
okta Adaptive Multi Factor Authentication App [pdf] ຄູ່ມືຜູ້ໃຊ້ Adaptive Multi Factor Authentication, Adaptive Multi Factor Authentication App, ແອັບ |
