ຄວາມປອດໄພຂອງບັນຊີ
ຄວາມປອດໄພຂອງເຊີບເວີປົກປ້ອງເວັບໄຊຕ໌. ຄວາມປອດໄພຂອງບັນຊີປົກປ້ອງກະແຈຂອງພວກມັນ. ການເຂົ້າສູ່ລະບົບ Zinn Digital® ທຸກຄັ້ງແມ່ນເຮັດວຽກຢູ່ເທິງລະບົບພິສູດຕົວຕົນມາດຕະຖານດຽວ — ລະຫັດຜ່ານ ແລະ WebAuthn, ລະຫັດຢືນຢັນສອງຂັ້ນຕອນ TOTP, ການເຂົ້າສູ່ລະບົບດ້ວຍລິ້ງມະຫັດສະຈັນ, SAML SSO ສຳລັບທີມງານລະດັບວິສາຫະກິດ ແລະ ອົງກອນ — ພ້ອມດ້ວຍບົດບາດລະອຽດ, ກະແຈ API ຕໍ່ອົງກອນ ແລະ ບັນທຶກການກວດສອບທີ່ເພີ່ມໄດ້ຢ່າງດຽວຢູ່ເບື້ອງຫຼັງ.
ບັນຊີໂຮດຕິ້ງສ່ວນໃຫຍ່ແມ່ນໃຊ້ລະຫັດຜ່ານໃນຖານຂໍ້ມູນ, ເຊິ່ງຜູກໄວ້ກັບແຜງຄວບຄຸມ. ແຕ່ຂອງພວກເຮົາແມ່ນລະບົບຢັ້ງຢືນຕົວຕົນແບບສະເພາະ — Keycloak, ທີ່ຮອງຮັບ OIDC ແລະ SAML — ເຊິ່ງເຮັດວຽກຢູ່ຕໍ່ໜ້າທຸກຢ່າງ: ແຜງຄວບຄຸມລູກຄ້າ, ຄອນໂຊນຜູ້ດູແລລະບົບຂອງພະນັກງານ, ເວັບໄຊສາທາລະນະ ແລະ ຖານຄວາມຮູ້ນີ້, ລວມເຖິງຕັ່ງຕອບຄຳຖາມບໍລິການຊ່ວຍເຫຼືອຂອງທ່ານ. ເຂົ້າສູ່ລະບົບພຽງຄັ້ງດຽວ ແລະ ທ່ານຈະສາມາດເຂົ້າໃຊ້ງານໄດ້ທຸກສ່ວນ.
ຍ້ອນວ່າມັນຖືກສ້າງຂຶ້ນໃນມາດຕະຖານເປີດ ຫຼາຍກວ່າລະບົບເຂົ້າສູ່ລະບົບທີ່ເປັນກຳມະສິດ, ຊັ້ນຕົວຕົນຈຶ່ງສາມາດປ່ຽນແທນໄດ້ໃນຮູບແບບດຽວກັນກັບທຸກໆ ສ່ວນປະກອບອື່ນໆ ຂອງແພລດຟອມ. ບໍ່ມີສ່ວນໃດຂອງຮູບແບບການເຂົ້າເຖິງຂອງທ່ານຖືກກັກຂັງໄວ້ໃນຜະລິດຕະພັນຂອງຜູ້ສະໜອງ, ແລະ ບໍ່ມີການຢືນຢັນຕົວຕົນໃດໆ ຂອງທີມງານຂອງທ່ານທີ່ຂຶ້ນກັບການທີ່ພວກເຮົາຕ້ອງຮັກສາຜູ້ສະໜອງໃດໜຶ່ງໄວ້. ນັ້ນແມ່ນຫຼັກການທີ່ບໍ່ມີການຜູກຂາດດຽວກັນກັບທີ່ພວກເຮົາໃຊ້ກັບບັນຊີ CDN, DNS ແລະ ຜູ້ໃຫ້ບໍລິການຊຳລະເງິນ.
ການເຂົ້າສູ່ລະບົບແມ່ນໄດ້ຖືກປັບໃຫ້ເຂົ້າກັບທ້ອງຖິ່ນ, ແລະການສົ່ງຕໍ່ຈາກເວັບໄຊໄປຫາໜ້າຈໍເຂົ້າສູ່ລະບົບແມ່ນນຳພາພາສາຂອງທ່ານໄປນຳ — ດັ່ງນັ້ນທີມງານທີ່ກະຈາຍຢູ່ທົ່ວ ໆ ໄປ ຕາມປະເທດຕ່າງ ໆ ຈຶ່ງບໍ່ຖືກບັງຄັບໃຫ້ຜ່ານການເຂົ້າສູ່ລະບົບທີ່ມີແຕ່ພາສາອັງກິດເທົ່ານັ້ນ.
ສີ່ວິທີ, ທຸກວິທີແມ່ນໄດ້ມາດຕະຖານສູງ, ທຸກວິທີສາມາດ ກຳນົດຄ່າໄດ້ຕໍ່ແຕ່ລະບຸກຄົນ. ບໍ່ມີໃຜຖືກບັງຄັບໃຫ້ໃຊ້ຕົວເລືອກທີ່ຮ້ອນກວ່າເພາະລາຄາມັນແມ່ນຕົວເລືອກດຽວທີ່ມີໃຫ້.
ປ້ອນອີເມວຂອງທ່ານ, ຄລິກລິ້ງ, ແລ້ວທ່ານກໍ່ເຂົ້າສູ່ລະບົບໄດ້ເລີຍ. ບໍ່ມີລະຫັດຜ່ານໃຫ້ຖືກ phishing, ນຳກັບມາໃຊ້ຊ້ຳ, ຫຼື ຮົ່ວໄຫລໃນການຮົ່ວໄຫລຂອງຂໍ້ມູນ. ນີ້ແມ່ນເສັ້ນທາງເລີ່ມຕົ້ນສຳລັບບັນຊີໃຫມ່, ແລະ ສຳລັບຄົນສ່ວນໃຫຍ່ມັນເປັນພຽງແຕ່ອັນດຽວທີ່ພວກເຂົາຕ້ອງການຕະຫຼອດການ.
ລົງທະບຽນ passkey — Touch ID, Face ID, Windows Hello, ຫຼື ຮາດແວຄີ ຢ່າງ YubiKey — ແລະ ເຂົ້າສູ່ລະບົບໂດຍບໍ່ຕ້ອງໃຊ້ ລະຫັດຜ່ານ ເລີຍ. Passkey ຖືກຜູກໄວ້ກັບ ໂດເມນຕົ້ນທາງ, ດັ່ງນັ້ນ ໜ້າເຂົ້າສູ່ລະບົບ ທີ່ປອມແປງ ຈະບໍ່ສາມາດ ລັກເອົາມັນໄດ້. ແພຼດຟອມນີ້ ຮອງຮັບ ອຸປະກອນຢືນຢັນຕົວຕົນ ແບບ ES256 ແລະ RS256 ແລະ ແນະນຳໃຫ້ໃຊ້ ການຢືນຢັນຕົວຕົນຜູ້ໃຊ້.
ເຂົ້າສູ່ລະບົບດ້ວຍ Google ຜ່ານການເຊື່ອມຕໍ່ຜູ້ໃຫ້ບໍລິການຕົວຕົນມາດຕະຖານ, ດັ່ງນັ້ນບັນຊີຈະສືບທອດການຄວບຄຸມໃດກໍຕາມທີ່ Google Workspace ຂອງທ່ານບັງຄັບໃຊ້ຢູ່ແລ້ວ. ຜູ້ໃຫ້ບໍລິການເພີ່ມເຕີມຈະເຊື່ອມຕໍ່ໃນຮູບແບບດຽວກັນ — ບໍ່ມີຫຍັງກ່ຽວກັບມັນທີ່ເປັນການເຊື່ອມໂຍງແບບພິເສດ.
ເກັບຮັກສາໄວ້ສຳລັບຜູ້ໃຊ້ ແລະ ຊຸດຂໍ້ມູນທີ່ຈຳເປັນ, ແລະ ຈັດຕັ້ງປະຕິບັດຕາມນະໂຍບາຍຕົວຈິງ: ຢ່າງໜ້ອຍສິບສອງຕົວອັກສອນ, ຫ້າມໃຊ້ຊື່ຜູ້ໃຊ້ ຫຼື ອີເມວຂອງທ່ານ, ຫ້າມໃຊ້ລະຫັດຜ່ານ 3 ຄັ້ງຫຼ້າສຸດຊ້ຳກັນ, ເຂົ້າລະຫັດດ້ວຍ Argon2. ທີ່ຢູ່ອີເມວຈະຖືກກວດສອບກ່ອນທີ່ບັນຊີຈະສາມາດໃຊ້ງານໄດ້.
ປັດໄຈທີສອງແມ່ນສ່ວນໜຶ່ງຂອງລະບົບການພິສູດຕົວຕົນ, ບໍ່ແມ່ນສ່ວນເສີມທີ່ທ່ານຊື້ ຫຼື ປລັກອິນທີ່ທ່ານຕິດຕັ້ງໃນເວັບໄຊຂອງທ່ານເອງ.
ຖ້າຫາກວ່າອົງກອນຂອງທ່ານມີຜູ້ໃຫ້ບໍລິການຢັ້ງຢືນຕົວຕົນຢູ່ແລ້ວ — Okta, Entra ID, Google Workspace, ຫຼື ລະບົບໃດກໍຕາມທີ່ຮອງຮັບ SAML — ທ່ານສາມາດເຊື່ອມຕໍ່ມັນ ແລະ ໃຫ້ທີມງານຂອງທ່ານລົງຊື່ເຂົ້າໃຊ້ Zinn Digital® ດ້ວຍຂໍ້ມູນການເຂົ້າສູ່ລະບົບຂອງອົງກອນທີ່ມີຢູ່ແລ້ວ. ທີມງານຂອງທ່ານບໍ່ຈຳເປັນຕ້ອງຈັດການລະຫັດຜ່ານທີສອງ ແລະ ບໍ່ມີລາຍການກວດສອບການຍົກເລີກສິດການເຂົ້າໃຊ້ງານທີສອງທີ່ຕ້ອງກັງວົນວ່າຈະຫຼົງລືມ.
ສິ່ງນັ້ນແມ່ນສຳຄັນທີ່ສຸດໃນລະດັບອົງການ ແລະ ຜູ້ຂາຍຕໍ່, ບ່ອນທີ່ການລາອອກຂອງພະນັກງານແມ່ນເຫດການຄວາມປອດໄພທີ່ແທ້ຈິງ. ເມື່ອມີຄົນອອກ ແລະ ທ່ານປິດການໃຊ້ງານພວກເຂົາໃນລາຍຊື່ຜູ້ໃຊ້ຂອງທ່ານ, ທ່ານກໍ່ໄດ້ປິດເສັ້ນທາງເຂົ້າສູ່ລະບົບໂຮດຕິ້ງຂອງທ່ານເຊັ່ນກັນ. ການເຂົ້າເຖິງແມ່ນເປັນໄປຕາມສະຖານະການຈ້າງງານ, ຈາກສູນກາງ, ແທນທີ່ຈະຕ້ອງໄປໄລ່ປິດໃນເຄື່ອງມື SaaS ຫລາຍກວ່າສິບຕົວ.
SAML ນັ່ງຄຽງຄູ່ກັບທຸກສິ່ງທຸກຢ່າງແທນທີ່ຈະທົດແທນມັນ: ຜູ້ຮັບເໝົາຍັງສາມາດໄດ້ຮັບບັນຊີລິ້ງວິເສດພາຍໃນບົດບາດທີ່ມີຂອບເຂດ, ໃນຂະນະທີ່ພະນັກງານປະຈຳເຂົ້າມາຜ່ານ SSO. ໜຶ່ງອົງກອນ, ໜຶ່ງຮູບແບບການອະນຸຍາດ, ສອງປະຕູໜ້າ.
ການເຂົ້າເຖິງແມ່ນຖືກຈຳກັດຂອບເຂດຕາມໂຄງສ້າງອົງກອນ — ຕັ້ງແຕ່ຜູ້ຂາຍຕໍ່ ຈົນເຖິງລູກຄ້າ ແລະ ເວັບໄຊ — ແລະ ຖືກບັງຄັບໃຊ້ຢູ່ມາດຕະຖານຖານຂໍ້ມູນເອງໂດຍຜ່ານຄວາມປອດໄພລະດັບແຖວ (row-level security), ບໍ່ແມ່ນພຽງແຕ່ໃນແອັບພລິເຄຊັນເທົ່ານັ້ນ. ການເຂົ້າເຖິງຂ້າມຜູ້ໃຊ້ງານ (Cross-tenant) ບໍ່ແມ່ນນະໂຍບາຍທີ່ເຮົາຂໍໃຫ້ຄົນອື່ນປະຕິບັດຕາມ; ແຕ່ມັນແມ່ນຄຳສັ່ງສອບຖາມ (query) ທີ່ບໍ່ສາມາດສົ່ງຄືນຂໍ້ມູນແຖວໃດໆໄດ້. ບົດບາດລູກຄ້າ 4 ແບບແມ່ນຄອບຄຸມການແບ່ງໜ້າທີ່ຮັບຜິດຊອບຕາມຄວາມເປັນຈິງ.
ການຄວບຄຸມອົງກອນ ແລະ ບັນຊີຍ່ອຍທັງໝົດຢ່າງສົມບູນ: ສ້າງອົງກອນລູກ, ເຊີນ ແລະ ລຶບສະມາຊິກ, ກຳນົດບົດບາດ, ຈັດການທຸກເວັບໄຊ, ດຳເນີນການຮຽກເກັບເງິນ ແລະ ໃບແຈ້ງໜີ້, ຈັດການຄີ API, ແລະ ອ່ານບັນທຶກການກວດສອບ.
ໃບແຈ້ງໜີ້, ການສະໝັກໃຊ້ບໍລິການ, ວິທີການຊຳລະເງິນ ແລະ ແຄັດຕາລັອກແພັກເກດ — ແລະ ບໍ່ມີສິ່ງອື່ນໃດນອກຈາກນີ້. ພະນັກງານການເງິນ ຫຼື ບັນຊີຂອງທ່ານສາມາດຊຳລະໃບແຈ້ງໜີ້ໄດ້ໂດຍບໍ່ມີສິດໃນການເຂົ້າເຖິງ, ລະງັບ ຫຼື ລົບເວັບໄຊທີ່ກຳລັງອອນໄລນ໌ຢູ່ເລີຍ.
ເວັບໄຊ ແລະ ການເຂົ້າເຖິງ API ໂດຍບໍ່ມີການຄວບຄຸມການຮຽກເກັບເງິນ: ເບິ່ງ ແລະ ຈັດສັນເວັບໄຊ, ຣີສະຕາດບໍລິການ, ລ້າງແຄຊ, ຈັດການກະແຈ API ແລະ ປຶ້ມປ້ຳວຽກ. ບໍ່ມີການເຂົ້າເຖິງວິທີການຈ່າຍເງິນ, ໃບແຈ້ງໜີ້ ຫຼື ການປ່ຽນແພັກເກດໂດຍເຈດຕະນາ.
ເບິ່ງຢ່າງດຽວທົ່ວອົງກອນ — ເວັບໄຊ, ການບບິນ, ແພັກເກດ, ປີ້ຊັບພອດ, ສະຖານະການແປພາສາ ແລະ ບັນທຶກການກວດສອບ. ບົດບາດທີ່ເໝາະສົມສຳລັບຜູ້ກວດສອບ, ລູກຄ້າທີ່ຕ້ອງການເບິ່ງຄວາມຄືບໜ້າ, ຫຼື ພະນັກງານໃໝ່ໃນອາທິດທຳອິດຂອງພວກເຂົາ.
ແຜງຄວບຄຸມແມ່ນໜຶ່ງໃນເສັ້ນທາງເຂົ້າ. API, CLI, Terraform provider ແລະ MCP server ແມ່ນເສັ້ນທາງອື່ນໆ — ແລະພວກມັນຖືກຮັກສາໄວ້ພາຍໃຕ້ຮູບແບບການເຂົ້າເຖິງດຽວກັນ, ເພາະວ່າຄີທີ່ບໍ່ມີຂອບເຂດແມ່ນການຫຼີກລ້ຽງທຸກບົດບາດທີ່ທ່ານຫາກໍກຳນົດຄ່າ.
ລະຫັດ API ຈະຖືກອອກໃຫ້ອົງກອນ, ບໍ່ແມ່ນໃຫ້ບຸກຄົນໃດໜຶ່ງ, ແລະ ມີຂອບເຂດສິດຂອງຕົນເອງ. ໃຫ້ປະຕິບັດຕໍ່ມັນຄືກັບຂໍ້ມູນປະຈຳຕົວທີ່ໃຊ້ຮ່ວມກັນ: ຕັ້ງຊື່ຕາມຈຸດປະສົງຂອງມັນ, ມອບຂອບເຂດສິດທີ່ແຄບທີ່ສຸດທີ່ສາມາດໃຊ້ງານໄດ້, ແລະ ປ່ຽນໃໝ່ເມື່ອຜູ້ສ້າງມັນຍ້າຍອອກໄປ.
ລະຫັດລັບດິບຈະຖືກສະແດງໃຫ້ທ່ານເຫັນພຽງຄັ້ງດຽວ, ເມື່ອສ້າງ. ສິ່ງທີ່ພວກເຮົາເກັບຮັກສາໄວ້ແມ່ນຄ່າແຮດ SHA-256 ແລະຄຳນຳໜ້າສັ້ນໆສຳລັບການຊອກຫາ. ພວກເຮົາບໍ່ສາມາດສະແດງລະຫັດລັບໃຫ້ທ່ານເຫັນອີກຄັ້ງໄດ້, ແລະ ການຖືກເຈາະຖານຂໍ້ມູນກໍ່ຈະບໍ່ເຮັດໃຫ້ຜູ້ບໍ່ຫວັງດີໄດ້ຮັບຂໍ້ມູນຢັ້ງຢືນຕົວຕົນທີ່ໃຊ້ງານໄດ້.
ກະແຈແຕ່ລະດັບມີຂອບເຂດລະອຽດທີ່ຜູກມັດກັບລາຍການສິດອະນຸຍາດດຽວກັນກັບທີ່ບົດບາດຕ່າງໆໃຊ້, ບັນທຶກເວລາທີ່ມັນຖືກໃຊ້ຄັ້ງຫຼ້າສຸດ, ແລະ ສາມາດຖືກຖອນຄືນໄດ້ທັນທີທີ່ມັນເບິ່ງຄືວ່າຜິດປົກກະຕິ. ກະແຈແຊນບັອກແຍກຕ່າງຫາກແມ່ນທົດສອບ API ໂດຍບໍ່ມີການເກັບເງິນ ຫຼື ການຈັດສັນທີ່ແທ້ຈິງຢູ່ເບື້ອງຫຼັງພວກມັນ.
ເຊີເວີ MCP ຊ່ວຍໃຫ້ຕົວແທນໃດກໍຕາມທີ່ມີຄວາມສາມາດ MCP ຈັດການໂຮດຕິ້ງຂອງທ່ານໄດ້ — ແລະ ມັນຢືນຢັນຕົວຕົນຜ່ານ OAuth 2.1, ໂດຍກຳນົດຂອບເຂດຕາມອົງກອນຂອງທ່ານ ແລະ ສິດທິ RBAC ຂອງມັນ, ພ້ອມທັງມີໂທເຄັນທີ່ສາມາດຍົກເລີກໄດ້ຕາມແຕ່ລະເຄື່ອງມື, ການຢືນຢັນກ່ອນດຳເນີນການທີ່ມີຜົນຮ້າຍແຮງ, ເພດານຄ່າໃຊ້ຈ່າຍ ແລະ ການບັນທຶກປະວັດການທຳງານຢ່າງສົມບູນ. ການເຊື່ອມຕໍ່ຜູ້ຊ່ວຍ AI ບໍ່ໄດ້ໝາຍຄວາມວ່າທ່ານຕ້ອງມອບສິດທັງໝົດໃຫ້ກັບມັນ.
ທຸກໆການກະຳລິດສິດທິພິເສດແມ່ນຂຽນບັນທຶກແບບເພີ່ມຢ່າງດຽວ — ໃຜເປັນຜູ້ເຮັດ, ເຂົາເຈົ້າເຮັດຫຍັງ, ເຂົາເຈົ້າເຮັດຫຍັງກັບມັນ, ຫຼັກຖານສະໜັບສະໜູນ, ແລະ ທີ່ຢູ່ IP ຕົ້ນທາງ, ພ້ອມດ້ວຍເວລາ. ມັນບໍ່ແມ່ນຄວາມສະດວກໃນການແກ້ໄຂຂໍ້ຜິດພາດ; ມັນແມ່ນເສັ້ນທາງຫຼັກຖານ.
ບໍ່ — ແລະ ພວກເຮົາບໍ່ຢາກໃຫ້ທ່ານເຮັດແບບນັ້ນ. ການເຂົ້າສູ່ລະບົບຜ່ານອີເມວ Magic-link ແມ່ນຄ່າເລີ່ມຕົ້ນ, ແລະ ທ່ານສາມາດລົງທະບຽນ passkey (Touch ID, Face ID, Windows Hello ຫຼື ຄີຮາດແວ) ແລ້ວເຂົ້າສູ່ລະບົບໂດຍບໍ່ຕ້ອງຕັ້ງລະຫັດຜ່ານເລີຍ. ຕົວເລືອກອີເມວ ແລະ ລະຫັດຜ່ານ ຍັງມີໃຫ້ໃຊ້ເປັນວິທີສຳຮອງ, ໂດຍກຳນົດ ຂັ້ນຕ່ຳສິບສອງຕົວອັກສອນ, ຫ້າມໃຊ້ລະຫັດຜ່ານເກົ່າສາມຄັ້ງລ້າສຸດຊ້ຳ, ແລະ ເຮັດ Hash ດ້ວຍ Argon2.
ການຢືນຢັນຕົວຕົນແບບສອງປັດໄຈແບບ TOTP ແມ່ນຖືກສ້າງຂຶ້ນມາໃນຊັ້ນລະບົບກຳນົດຕົວຕົນ ແລະ ສາມາດບັງຄັບໃຊ້ຜ່ານນະໂຍບາຍທົ່ວທັງອົງກອນໄດ້ ໂດຍທີ່ບໍ່ຕ້ອງປ່ອຍໃຫ້ສະມາຊິກແຕ່ລະຄົນເປັນຜູ້ເລືອກເປີດໃຊ້ງານເອງ. Passkeys ເປັນທາງເລືອກທີ່ມີຄວາມປອດໄພກວ່າໃນກໍລະນີທີ່ອຸປະກອນຂອງທີມງານຂອງທ່ານຮອງຮັບ, ຍ້ອນວ່າພວກມັນຈະຊ່ວຍລຶບລະຫັດຜ່ານທີ່ຜູ້ໂຈມຕີມັກໃຊ້ໃນການຫຼອກລວງທາງອີເມວອອກໄປ.
ແມ່ນແລ້ວ. ບົດບາດຜູ້ຈັດການການຮຽກເກັບເງິນແມ່ນໃຫ້ສິດເຂົ້າເຖິງໃບເກັບເງິນ, ການສະໝັກໃຊ້, ວິທີການຊຳລະເງິນ ແລະ ແຄັດຕາລັອກແຜນບໍລິການ ແລະ ບໍ່ມີສິດອື່ນອີກ — ບໍ່ມີສິດເບິ່ງ, ຈັດສັນ, スタート (ຣີສະຕາດ), ລະງັບ ຫຼື ລຶບເວັບໄຊ. ແລະ ກົງກັນຂ້າມ: ບົດບາດຜູ້ພັດທະນາແມ່ນຈັດການເວັບໄຊ ແລະ ການເຂົ້າເຖິງ API ໂດຍບໍ່ມີການຄວບຄຸມການຮຽກເກັບເງິນເລີຍ. ບົດບາດຖືກມອບໝາຍຕໍ່ອົງກອນ, ດັ່ງນັ້ນບົດບາດໃນອົງກອນໜຶ່ງຈຶ່ງບໍ່ໃຫ້ສິດເຂົ້າເຖິງໃນອົງກອນອື່ນທີ່ແຍກຕ່າງຫາກ ແລະ ບໍ່ກ່ຽວຂ້ອງກັນ — ເຖິງແມ່ນວ່າບົດບາດໃນອົງກອນຫຼັກຈະມີຜົນຕໍ່ອົງກອນທີ່ຢູ່ພາຍໃຕ້ມັນກໍຕາມ.
ຍົກເລີກມັນຈາກແດຊບອດ ແລ້ວມັນຈະຢຸດທຳງານທັນທີ. ຂອບເຂດຄວາມເສຍຫາຍແມ່ນຖືກຈຳກັດໂດຍສິ່ງທີ່ຄີມົນສາມາດເຮັດໄດ້ໃນຕອນທຳອິດ, ເຊິ່ງແມ່ນເຫດຜົນທີ່ຄີຕ່າງໆ ມີຂອບເຂດລະອຽດ ແລະ ບັນທຶກປະວັດເວລາການໃຊ້ງານລ້າສຸດ — ຂອບເຂດທີ່ແຄບ ແລະ ປະວັດການໃຊ້ງານທີ່ເຫັນໄດ້ ແມ່ນສິ່ງທີ່ປ່ຽນການຮົ່ວໄຫຼໃຫ້ກາຍເປັນເຫດການທີ່ຖືກຄຸ້ມຄອງໄດ້ ແທນທີ່ຈະເປັນການສູນເສຍບັນຊີທັງໝົດ. ກະລຸນານຳວ່າ ຄີຕ່າງໆ ຖືກອອກໃຫ້ກັບອົງກອນ ຫຼາຍກວ່າບຸກຄົນ, ດັ່ງນັ້ນຈົ່ງປະຕິບັດກັບພວກມັນຄືກັບຂໍ້ມູນປະຈຳຕົວທີ່ໃຊ້ຮ່ວມກັນ ແລະ ປ່ຽນພວກມັນເມື່ອມີຄົນຍ້າຍອອກໄປ. ມີພຽງແຮຊຂອງຄີເທົ່ານັ້ນທີ່ຖືກຈັດເກັດໄວ້ຢູ່ຝ່າຍເຮົາ, ດັ່ງນັ້ນການຮົ່ວໄຫຼຈາກຖານຂໍ້ມູນຂອງເຮົາ ຈຶ່ງບໍ່ໄດ້ສ້າງຂໍ້ມູນປະຈຳຕົວທີ່ໃຊ້ງານໄດ້.
ແມ່ນແລ້ວ. ທຸກໆການກະຳສິດພິເສດແມ່ນຖືກບັນທຶກໄວ້ໃນບັນທຶກການກວດສອບທີ່ຂຽນເພີ່ມໄດ້ເທົ່ານັ້ນ ພ້ອມດ້ວຍຜູ້ກະທຳ, ການກະທຳ, ເປົ້າໝາຍ, ຫຼັກຖານສະໜັບສະໜູນ, IP ຕົ້ນທາງ ແລະ ປະທັບເວລາ. ບົດບາດເຈົ້າຂອງ ແລະ ອ່ານຢ່າງດຽວສາມາດອ່ານມັນໄດ້ໂດຍກົງ. ການກະທຳຂອງພະນັກງານໃນບັນຊີຂອງທ່ານແມ່ນຖືກບັນທຶກໄວ້ໃນເສັ້ນທາງດຽວກັນ, ແລະ ການກະທຳຂອງພະນັກງານທີ່ລະອຽດອ່ອນ ຫຼື ທຳລາຍອາດຈະຕ້ອງມີການຢັ້ງຢືນຕົວຕົນເພີ່ມເຕີມ ຫຼື ການອະມຸມັດຈາກສອງຄົນກ່ອນ.
ແມ່ນແລ້ວ — ຮອງຮັບ SAML SSO ສຳລັບບັນຊີວິສາຫະກິດ ແລະ ເອເຈນຊີ, ດັ່ງນັ້ນ ພະນັກງານຂອງທ່ານຈຶ່ງຢືນຢັນຕົວຕົນດ້ວຍຂໍ້ມູນປະຈຳຕົວຂອງອົງກອນທີ່ມີຢູ່ ແລະ ການຍົກເລີກສິດໃນ ໄດເຣັກໂທຣີ ຂອງທ່ານຈະລົບການເຂົ້າເຖິງຂອງພວກເຂົາຢູ່ທີ່ນີ້ເຊັ່ນກັນ. ທ່ານສາມາດປະສົມປະສານວິທີການໄດ້: SSO ສຳລັບພະນັກງານປະຈຳ, ບັນຊີ magic-link ທີ່ກຳນົດຂອບເຂດສຳລັບຜູ້ຮັບເໝົາ, ທັງໝົດຢູ່ພາຍໃນຮູບແບບສິດເບິ່ງແຍງດຽວກັນ.
ບໍ່ — ລະຫັດຜ່ານແມ່ນຖືກຈົງໃຈບໍ່ໃຫ້ຖືກຍ້າຍມານຳ. ບັນຊີຂອງທ່ານຖືກນໍາເຂົ້າໂດຍບໍ່ມີລະຫັດຜ່ານ, ແລະໃນການເຂົ້າສູ່ລະບົບຄັ້ງທຳອິດ ທ່ານສາມາດໃຊ້ລິ້ງເວດມົນ ຫຼື ຕັ້ງລະຫັດຜ່ານໃໝ່ພາຍໃຕ້ນະໂຍບາຍປັດຈຸບັນ. ການໂອນຍ້າຍແຮຊລະຫັດຜ່ານເກົ່າອາດຈະນຳເອົາຈຸດອ່ອນເກົ່າເຂົ້າມາສູ່ລະບົບໃໝ່, ສະນັ້ນພວກເຮົາຈຶ່ງບໍ່ເຮັດແນວນັ້ນ.
ການທົດລອງໃຊ້ Footprint-Free ແມ່ນ 14 ມື້, ບໍ່ຕ້ອງໃຊ້ບັດເຄຣດິດ, ແລະ ຮອງຮັບເຖິງຫ້າເວັບໄຊ. ທ່ານຈະໄດ້ຮັບຊັ້ນຂໍ້ມູນຕົວຕົນແບບເຕັມຮູບແບບໃນລະຫວ່າງການທົດລອງ — ລະຫັດຜ່ານຜ່ານ, ການຢືນຢັນຕົວຕົນສອງຂັ້ນຕອນ, ບົດບາດ, ລະຫັດ API ແລະ ບັນທຶກການກວດສອບແມ່ນບໍ່ໄດ້ຖືກຈຳກັດໄວ້ສະເພາະແພັກເກດທີ່ຕ້ອງຈ່າຍເງິນ.
ລົງທະບຽນຄີຜ່ານ, ເຊີນທີມງານຂອງທ່ານເຂົ້າໃນບົດບາດທີ່ຖືກຕ້ອງ, ແລະ ອອກ API ຄີທີ່ມີຂອບເຂດ — ທັງໝົດໃນການທົດລອງໃຊ້ 14 ວັນໂດຍບໍ່ຕ້ອງໃຊ້ບັດ ແລະ ບໍ່ຈຳເປັນຕ້ອງໃສ່ລາຍລະອຽດບັດ.
ເລີ່ມຕົ້ນຟຣີ