ການເຂົ້າເຖິງທີ່ມອບໝາຍ
ເຊີນນັກພັດທະນາເຂົ້າມາ, ມອບໝາຍການຮຽກເກັບເງິນໃຫ້ບັນຊີຂອງທ່ານ, ໃຫ້ລູກຄ້າເບິ່ງເວັບໄຊຂອງເຂົາເຈົ້າເອງແບບອ່ານໄດ້ຢ່າງດຽວ, ຫຼື ໃຫ້ທີມງານຊ່ວຍເຫຼືອຂອງພວກເຮົາກວດເບິ່ງບັນຫາ. ການອະນຸຍາດແຕ່ລະອັນແມ່ນບົດບາດທີ່ມີສິດກຳນົດໄວ້ຢ່າງຊັດເຈນ, ກຳນົດຂອບເຂດຕາມອົງກອນ, ບັງຄັບໃຊ້ໃນຖານຂໍ້ມູນ, ແລະ ບັນທຶກລົງໃນບັນທຶກການກວດສອບທີ່ເພີ່ມຂໍ້ມູນໄດ້ຢ່າງດຽວ.
ການແບ່ງປັນຂໍ້ມູນເຂົ້າສູ່ລະບົບດຽວກັນແມ່ນສາເຫດທີ່ເຮັດໃຫ້ການເຂົ້າເຖິງບັນຊີເກີດຄວາມຜິດພາດ. ຢູ່ Zinn Digital® ແຕ່ລະຄົນມີຕົວຕົນສະເພາະຂອງຕົນເອງ, ແລະ ການເຂົ້າເຖິງແມ່ນການເປັນສະມາຊິກ — ຜູ້ໃຊ້, ອົງກອນ, ແລະ ບົດບາດ — ທີ່ທ່ານສາມາດມອບໃຫ້, ປ່ຽນແປງ ຫຼື ຖອນຄືນໄດ້ດ້ວຍຕົວມັນເອງ.
ຜູ້ຮ່ວມງານແຕ່ລະຄົນເຂົ້າສູ່ລະບົບດ້ວຍບັນຊີຂອງຕົນເອງຜ່ານ Keycloak, ເຊິ່ງແມ່ນລະບົບຈັດການຕົວຕົນຂອງພວກເຮົາ. ບໍ່ມີໃຜພິມລະຫັດຜ່ານຂອງທ່ານ, ບໍ່ມີໃຜແບ່ງປັນເຊດຊັນຂອງບຣາວເຊີ, ແລະ ການລຶບໃຜຄົນໜຶ່ງອອກແມ່ນດຳເນີນການພຽງແຕ່ຂັ້ນຕອນດຽວ ແທນທີ່ຈະຕ້ອງປ່ຽນລະຫັດຜ່ານ ແລະ ວຸ້ນວາຍຊອກຫາວ່າໃຜແດ່ທີ່ຮູ້ລະຫັດນັ້ນ.
ບັນຊີມີລໍາດັບຊັ້ນ — ອົງກອນຕົວແທນຈໍາໜ່າຍຈະຄອບຄອງອົງກອນລູກຄ້າ, ແລະ ອົງກອນລູກຄ້າຈະຄອບຄອງເວັບໄຊ. ການເປັນສະມາຊິກມີຜົນຕໍ່ອົງກອນ ແລະ ທຸກຢ່າງທີ່ຢູ່ພາຍໃຕ້ມັນ, ດັ່ງນັ້ນທ່ານຈຶ່ງສາມາດມອບສິດການຄວບຄຸມອົງກອນຂອງຕົນເອງໃຫ້ກັບລູກຄ້າຕົວແທນໄດ້ ໂດຍບໍ່ເປີດເຜີຍລູກຄ້າລາຍອື່ນໆ ຂອງທ່ານເລີຍ.
ການແຍກຜູ້ເຊົ່າບໍ່ແມ່ນຕົວກັ່ນຕອງໃນໂຄ້ດແອັບພລິເຄຊັນທີ່ຂໍ້ຜິດພາດສາມາດຂ້າມໄປໄດ້. ຄວາມປອດໄພລະດັບແຖວ (Row-Level Security) ຂອງ Postgres ໄດ້ກຳນົດຂອບເຂດທຸກການສອບຖາມໄປຍັງຕົ້ນໄມ້ຍ່ອຍຂອງອົງກອນຂອງຜູ້ຮຽກໃຊ້, ດັ່ງນັ້ນຄຳຮ້ອງຂໍທີ່ຢູ່ນອກຂອບເຂດຂອງທ່ານຈຶ່ງບໍ່ມີສິ່ງໃດທີ່ຈະສົ່ງຄືນ.
ຮ້ອງຂໍອົງກອນ ຫຼື ເວັບໄຊທີ່ຢູ່ນອກຂອບເຂດຂອງທ່ານ ແລ້ວ API ຈະຕອບກັບດ້ວຍຂໍ້ຄວາມທຳມະດາທີ່ບໍ່ພົບ ແທນທີ່ຈະເປັນຂໍ້ຜິດພາດດ້ານການອະນຸຍາດ. ຂໍ້ຜິດພາດດ້ານການອະນຸຍາດຈະຢືນຢັນວ່າມີບັນທຶກນັ້ນຢູ່; ສ່ວນການບໍ່ພົບຈະບໍ່ບອກຫຍັງເລີຍຕໍ່ຄົນພາຍນອກ.
ສິດອະນຸຍາດແມ່ນຄີລະອຽດ — ໂມດູນບວກກັບການດຳເນີນການ, ເຊັ່ນ sites.restart ຫຼື billing.refund — ແລະ ບົດບາດຈະຮວບຮວມພວກມັນໄວ້. ສີ່ບົດບາດກວມເອົາຮູບແບບທີ່ທີມງານຕົວຈິງຕ້ອງການ, ແລະ ແຕ່ລະບົດບາດແມ່ນຂໍ້ມູນທີ່ພວກເຮົາປ້ອນໄວ້ລ່ວງໜ້າ, ບໍ່ແມ່ນຕັກກະທີ່ຝັງຢູ່ໃນໂຄ້ດ.
ການຄວບຄຸມຢ່າງເຕັມຮູບແບບ: ສ້າງອົງກອນຍ່ອຍ, ເຊີນ ແລະ ລຶບສະມາຊິກ, ປ່ຽນແປງບົດບາດ, ຈັດການຄີ API, ສ້າງ, ເລີ່ມໃໝ່, ລຶບລ້າງ, ລະງັບ ແລະ ລຶບເວັບໄຊ, ຈັດການການຮຽກເກັບເງິນ ແລະ ໃບແຈ້ງໜີ້, ສົ່ງຄຳຮ້ອງຂໍ ແລະ ອ່ານບັນທຶກການກວດສອບ. ບົດບາດທີ່ທ່ານເກັບໄວ້ສຳລັບຕົວທ່ານເອງ.
ເບິ່ງເຫັນອົງກອນ, ສະມາຊິກ ແລະ ລາຍການແພັກເກດ, ພ້ອມທັງຈັດການໃບແຈ້ງໜີ້, ວິທີການຊຳລະເງິນ ແລະ ຄ່າບໍລິການຕ່າງໆ. ບໍ່ມີສິດເຂົ້າເຖິງໃນການສ້າງ, ແກ້ໄຂ ຫຼື ລຶບເວັບໄຊໃດໜຶ່ງເລີຍ — ຮູບແບບທີ່ຖືກຕ້ອງຊັດເຈນທີ່ນັກບັນຊີພາຍນອກຄວນມີ.
ເບິ່ງ ແລະ ສ້າງເວັບໄຊ, ຣີສະຕາດການບໍລິການ, ລຶບລ້າງແຄຊ, ຈັດການຄີ API ແລະ ຈັດການກັບປີ້ແຈ້ງບັນຫາ. ຍົກເວັ້ນໂດຍເຈດຕະນາ: ການຮຽກເກັບເງິນ, ໃບແຈ້ງໜີ້, ວິທີການຊຳລະເງິນ, ການຈັດການສະມາຊິກ, ການລະງັບເວັບໄຊ ແລະ ການລຶບເວັບໄຊ. ຜູ້ຮັບເໝົາສາມາດສ້າງໄດ້ໂດຍບໍ່ສາມາດຮຽກເກັບເງິນຈາກທ່ານ ຫຼື ທຳລາຍສິ່ງໃດໆເລີຍ.
ເຫັນອົງກອນ, ສະມາຊິກ, ເວັບໄຊ, ການຮຽກເກັບເງິນ, ລາຍການແຜນ, ປີ້, ສະຖານະການແປ ແລະ ບັນທຶກການກວດສອບ — ແລະ ບໍ່ສາມາດປ່ຽນແປງສິ່ງໃດໄດ້ເລີຍ. ການອະນຸຍາດທີ່ຖືກຕ້ອງສຳລັບລູກຄ້າທີ່ຕ້ອງການການເບິ່ງເຫັນ, ຜູ້ກວດສອບບັນຊີ ຫຼື ຜູ້ມີສ່ວນຮ່ວມທີ່ຕ້ອງການພຽງແຕ່ເບິ່ງ.
ການມອບສິດການເຂົ້າເຖິງຈະປອດໄພກໍຕໍ່ເມື່ອບັນຊີທີ່ທ່ານມອບສິດໃຫ້ນັ້ນຍາກທີ່ຈະຖືກຍຶດຄອງ. ການກວດສອບສິດດຳເນີນການຜ່ານ Keycloak ສຳລັບທຸກໆຄົນໃນບັນຊີ, ໃນທຸກໆພາກສ່ວນ.
ວຽກງານສະໜັບສະໜູນບາງຄັ້ງອາດໝາຍເຖິງການກວດສອບພາຍໃນບັນຊີຂອງທ່ານ. ການເຂົ້າເຖິງນັ້ນແມ່ນຖືກຄວບຄຸມໂດຍຮູບແບບການອະນຸຍາດດຽວກັນກັບສິ່ງອື່ນໆທັງໝົດ — ພະນັກງານພຽງແຕ່ຢູ່ໃນອົງກອນພະນັກງານ, ເຊິ່ງຖືກຈັດແບ່ງອອກເປັນພະແນກຕ່າງໆ ພ້ອມກັບການອະນຸຍາດທີ່ຈຳກັດສະເພາະ.
ພະນັກງານຖືກຈັດເປັນກຸ່ມຄື: ຝ່າຍຊ່ວຍເຫຼືອ, ຝ່າຍຮຽກເກັບເງິນ ແລະ ການເງິນ, ຝ່າຍການລະເມີດ ແລະ ຄວາມໄວ້ວາງໃຈ-ຄວາມປອດໄພ, ຝ່າຍຂາຍ, ຝ່າຍແນະນຳເລີ່ມຕົ້ນ, ຝ່າຍວິສະວະກຳ ແລະ ປະຕິບັດການ, ຝ່າຍການຕະຫຼາດ, ແລະ ຝ່າຍບໍລິຫານ. ແຕ່ລະບົດບາດຈະໃຫ້ສິດເຂົ້າເຖິງໂມດູນ ແລະ ການດຳເນີນການສະເພາະ, ດັ່ງນັ້ນຕົວແທນຈະເຫັນສະເພາະສ່ວນຂອງຄອນໂຊນຜູ້ເບິ່ງແຍງລະບົບທີ່ວຽກຂອງພວກເຂົາຕ້ອງການເທົ່ານັ້ນ ແລະ ບໍ່ເຫັນສ່ວນທີ່ເຫຼືອ.
ບົດບາດ Support Agent ມອບສິດພຽງແຕ່ສິ່ງເຫຼົ່ານີ້ຢ່າງແນ່ນອນ: ເບິ່ງລູກຄ້າ, ເບິ່ງ ແລະ ຕອບກັບປີ້ແຈ້ງບັນຫາ, ເບິ່ງເວັບໄຊ, ເລີ່ມຕົ້ນເວັບໄຊໃໝ່ ແລະ ລຶບລ້າງແຄຊ໌ຂອງມັນ. ບົດບາດນີ້ບໍ່ມີການຕັ້ງຄ່າການຮຽກເກັບເງິນ, ບໍ່ມີການສົ່ງເງິນຄືນ, ບໍ່ມີການແກ້ໄຂແພັກເກດ ແລະ ບໍ່ມີການຈັດການກຸ່ມເຊີບເວີ. ການແກ້ໄຂບັນຫາທີ່ຕົວແທນສາມາດດຳເນີນການໄດ້ແມ່ນຖືກຈຳກັດໂດຍບົດບາດ, ບໍ່ແມ່ນໂດຍເຈດຕະນາດີ.
ສິດອະນຸຍາດ customer.impersonate ບໍ່ໄດ້ເປັນສ່ວນໜຶ່ງຂອງບົດບາດ Manager — ມັນຖືກຖືໂດຍ Super Admin ເທົ່ານັ້ນ. ເມື່ອມີເຊດຊັນກຳລັງເຮັດວຽກໃນນາມຂອງທ່ານ, ແຜງໜ້າປັດຈະສະແດງແຖບປ້າຍການປອມຕົວແບບຖາວອນ ເພື່ອບໍ່ໃຫ້ເກີດຄວາມກຳກວມວ່າໃຜເປັນຜູ້ດຳເນີນການ.
ທຸກໆການກະທຳທີ່ມີສິດພິເສດ ແລະ ການບໍລິຫານ ຈະຖືກເພີ່ມໃສ່ບັນທຶກການກວດສອບແບບເພີ່ມຂໍ້ມູນໄດ້ເທົ່ານັ້ນ ເຊິ່ງບັນທຶກຜູ້ກະທຳ, ການກະທຳ, ເປົ້າໝາຍ, ຂໍ້ມູນເມຕາທີ່ກ່ຽວຂ້ອງ, ທີ່ຢູ່ IP ແລະ ເວລາ — ເຊິ່ງຖືກແບ່ງສ່ວນຕາມເວລາໃນລະບົບໃຊ້ງານຈິງ. ເຈົ້າຂອງ ແລະ ສະມາຊິກທີ່ມີສິດອ່ານຢ່າງດຽວ ສາມາດອ່ານບັນທຶກຂອງອົງກອນຕົນເອງໄດ້.
ການກະທຳຂອງພະນັກງານທີ່ມີຄວາມອ່ອນໄຫວ ແລະ ອາດສ້າງຄວາມເສຍຫາຍ ສາມາດກຳນົດໃຫ້ມີການຢືນຢັນຕົວຕົນຂັ້ນສູງ ຫຼື ການອະນຸມັດຈາກສອງຄົນກ່ອນທີ່ຈະດຳເນີນການໄດ້, ແລະ ພະແນກ ພ້ອມທັງບົດບາດໃໝ່ແມ່ນຂຶ້ນກັບການຕັ້ງຄ່າຫຼາຍກວ່າການປ່ຽນແປງໂຄດ.
ສະຄຣິບ, CI pipelines, CLI, ຜູ້ໃຫ້ບໍລິການ Terraform ແລະ ຕົວແທນ AI ທັງໝົດແມ່ນຢັ້ງຢືນຕົວຕົນຜ່ານຮູບແບບການອະນຸຍາດດຽວກັນກັບຄົນ — ບໍ່ມີຂໍ້ມູນປະຈໍາຕົວຂອງມະນຸດທີ່ໃຊ້ຮ່ວມກັນ, ບໍ່ມີຄວາມລັບທີ່ໃຊ້ໄດ້ດົນນານຖືກວາງໃສ່ໃນການສ້າງ (build).
ກະແຈເປັນຂອງອົງກອນ ແລະ ມີຂອບເຂດລະອຽດທີ່ເຊື່ອມໂຍງກັບສິດອະນຸຍາດ RBAC ດຽວກັນ — ສຳລັບອ່ານເທົ່ານັ້ນ, ການຮຽກເກັບເງິນ, ການຈັດສັນ. ກະລຸນາມອບຂອບເຂດທີ່ຈຳກັດເທົ່າທີ່ຈຳເປັນໃຫ້ກັບ pipeline ແທນທີ່ຈະໃຫ້ບັນຊີທັງໝົດຂອງສະມາຊິກ.
ຄີໂໝດທົດສອບ ແລະ ໂໝດນຳໃຊ້ຕົວຈິງແມ່ນແຕກຕ່າງກັນ, ດັ່ງນັ້ນການເຊື່ອມໂຍງລະບົບທີ່ກຳລັງພັດທະນາຈຶ່ງບໍ່ສາມາດເຂົ້າເຖິງຂໍ້ມູນການຜະລິດໄດ້ໂດຍບັງເອີນ ຫຼື ຜ່ານຕົວປ່ຽນສະພາບແວດລ້ອມທີ່ຖືກສຳເນົາໄວ້.
ພວກເຮົາເກັບຮັກສາ SHA-256 hash ຂອງຄວາມລັບ ແລະ ຄຳນຳໜ້າສຳລັບການຊອກຫາ — ບໍ່ເຄີຍເກັບຮັກສາຄີຕົ້ນສະບັບເລີຍ. ທ່ານຈະເຫັນຄີພຽງຄັ້ງດຽວໃນຕອນສ້າງ. ແຕ່ລະຄີຈະຕິດຕາມເວລາທີ່ມັນຖືກນຳໃຊ້ຫຼ້າສຸດ ແລະ ສາມາດຖືກຍົກເລີກໄດ້ດ້ວຍຕົວມັນເອງໂດຍບໍ່ລົບກວນສິ່ງອື່ນ.
ເຊີບເວີ MCP ຂອງພວກເຮົາຊ່ວຍໃຫ້ຕົວແທນໃດໆກໍຕາມທີ່ຮອງຮັບ MCP ສາມາດຈັດການໂຮສຕິ້ງຂອງທ່ານດ້ວຍພາສາທຳມະຊາດ, ຢືນຢັນຕົວຕົນດ້ວຍ OAuth 2.1 ແລະ ກຳນົດຂອບເຂດຕາມອົງກອນ ແລະ ບົດບາດ RBAC ຂອງທ່ານ, ພ້ອມທັງມີໂທເຄັນທີ່ສາມາດຍົກເລີກໄດ້ຕາມແຕ່ລະເຄື່ອງມື, ການຢືນຢັນສຳລັບການກະທຳທີ່ອາດສ້າງຄວາມເສຍຫາຍ, ການຈຳກັດການໃຊ້ຈ່າຍ ແລະ ບັນທຶກການກວດສອບແບບຄົບຖ້ວນ.
ການເຂົ້າເຖິງບັນຊີ ແລະ ການເຂົ້າເຖິງເຊີບເວີແມ່ນບັນຫາທີ່ແຕກຕ່າງກັນ. ຂໍ້ມູນປະຈຳຕົວລະດັບເວັບໄຊແມ່ນຖືກຈັດການຢູ່ໃນແຜງຄວບຄຸມ, ຖືກອອກໃຫ້ໂດຍມີສິດທິໜ້ອຍທີ່ສຸດ ແລະ ຖືກແຍກໄວ້ສະເພາະເພື່ອໃຫ້ແຊວຂອງຜູ້ຮ່ວມງານຄົນໜຶ່ງເປັນແຊວຂອງເວັບໄຊດຽວເທົ່ານັ້ນ.
ຜູ້ດຳເນີນງານຄົນດຽວຈະຮັກສາອົງກອນດຽວ ແລະ ການເປັນສະມາຊິກເຈົ້າຂອງໜຶ່ງລາຍການໄວ້, ແລະ ເພີ່ມບົດບາດນັກພັດທະນາເມື່ອມີຜູ້ຮັບເໝົາເຂົ້າມາຮ່ວມໂຄງການ. ເມື່ອໂຄງການສິ້ນສຸດລົງ, ການເປັນສະມາຊິກຈະຖືກລຶບອອກ ແລະ ການເຂົ້າສູ່ລະບົບຂອງພວກເຂົາຈະຢຸດເຮັດວຽກທັນທີ — ບໍ່ມີຂໍ້ມູນປະຈຳຕົວທີ່ໃຊ້ຮ່ວມກັນຫຼົງເຫຼືອໄວ້ໃຫ້ຕ້ອງປ່ຽນແທນ.
ເອເຈນຊີໃຊ້ໂຄງສ້າງອົງກອນແບບຕົ້ນໄມ້. ລູກຄ້າແຕ່ລະຄົນຈະໄດ້ຮັບອົງກອນລູກຂອງຕົນເອງ, ເຊິ່ງບັນຈຸເວັບໄຊທ໌ຂອງລູກຄ້ານັ້ນ, ແລະ ພະນັກງານຂອງລູກຄ້າເອງຈະໄດ້ຮັບສະມາຊິກຢູ່ທີ່ນັ້ນ — ສິດອ່ານຢ່າງດຽວສຳລັບຜູ້ມີສ່ວນຮ່ວມທີ່ຕ້ອງການເບິ່ງຂໍ້ມູນ, ສິດເຈົ້າຂອງສຳລັບລູກຄ້າທີ່ຕ້ອງການຈັດການດ້ວຍຕົນເອງ. ພະນັກງານຂອງທ່ານມີສະມາຊິກຢູ່ໃນລະດັບທີ່ສູງກວ່າໃນໂຄງສ້າງຕົ້ນໄມ້ ແລະ ເຫັນຜົນງານທັງໝົດ; ລູກຄ້າຈະເຫັນສະເພາະສາຂາຂອງຕົນເອງເທົ່ານັ້ນ, ແລະ Row-Level Security ແມ່ນສິ່ງທີ່ເຮັດໃຫ້ສິ່ງນັ້ນເປັນຈິງແທນທີ່ຈະເປັນພຽງຄຳສັນຍາ.
ຕົວແທນຈໍາໜ່າຍເຮັດວຽກໃນຮູບແບບດຽວກັນ, ໃນລະດັບທີ່ສູງຂຶ້ນໄປອີກຂັ້ນໜຶ່ງ: ອົງກອນຕົວແທນຈໍາໜ່າຍຈະຄຸ້ມຄອງອົງກອນລູກຄ້າ, ເຊິ່ງແຕ່ລະອົງກອນມີສະມາຊິກ, ມຸມມອງການຮຽກເກັບເງິນ ແລະ ເວັບໄຊຂອງຕົນເອງ. ໂຄງສ້າງພື້ນຖານດຽວກັນນີ້ຮອງຮັບບັນຊີຍ່ອຍ, ທີມງານເອເຈນຊີ ແລະ ລໍາດັບຊັ້ນຂອງຕົວແທນຈໍາໜ່າຍ — ບໍ່ມີກົນໄກທີ່ແຍກຕ່າງຫາກ ຫຼື ດ້ອຍປະສິດທິພາບກວ່າສໍາລັບພາກສ່ວນໃດເລີຍ.
ທຸກຢ່າງແມ່ນພ້ອມໃຊ້ງານໃນໄລຍະທົດລອງໃຊ້ 14 ມື້ໂດຍບໍ່ຕ້ອງໃຊ້ບັດ. ລົງທະບຽນໂດຍບໍ່ຕ້ອງໃຊ້ຂໍ້ມູນການຊຳລະເງິນ, ເຊີນເພື່ອນຮ່ວມງານ, ເບິ່ງສິ່ງທີ່ແຕ່ລະບົດບາດສາມາດ ແລະ ບໍ່ສາມາດເຂົ້າເຖິງໄດ້, ແລະ ກວດເບິ່ງບັນທຶກການກວດສອບຂອງທ່ານຄືນ.
ໃນປະຈຸບັນ, ການເປັນສະມາຊິກຈະໃຫ້ສິດທິບົດບາດຂອງຕົນໃນທົ່ວອົງກອນ ແລະ ທຸກຢ່າງທີ່ຢູ່ພາຍໃຕ້ມັນໃນໂຄງສ້າງຕົ້ນໄມ້, ດັ່ງນັ້ນວິທີການແຍກຊຸດເວັບໄຊແມ່ນການແຍກອົງກອນ — ໃຫ້ວາງເວັບໄຊເຫຼົ່ານັ້ນໄວ້ໃນອົງກອນຍ່ອຍຂອງພວກມັນເອງ ແລະ ໃຫ້ສິດການເປັນສະມາຊິກຢູ່ທີ່ນັ້ນ. ນີ້ແມ່ນຮູບແບບທີ່ຊັດເຈນສຳລັບຕົວແທນ ແລະ ຜູ້ຂາຍຕໍ່, ເຊິ່ງລູກຄ້າແຕ່ລະຄົນຕ້ອງການຂອບເຂດຂອງຕົນເອງຢູ່ແລ້ວ. ການກຳນົດຂອບເຂດຊັບພະຍາກອນຕາມການເປັນສະມາຊິກ, ເຊັ່ນ: ການປັກໝຸດການເປັນສະມາຊິກດຽວໃສ່ເວັບໄຊທີ່ລະບຸຊື່ພາຍໃນອົງກອນດຽວ, ແມ່ນການປັບປຸງທີ່ໄດ້ວາງແຜນໄວ້ ຫຼາຍກວ່າສິ່ງທີ່ມີໃຫ້ໃຊ້ງານໃນຕອນນີ້.
ບົດບາດ Developer ບໍ່ມີສິດໃນການລຶບເວັບໄຊ ຫຼື ລະງັບເວັບໄຊ — ສິດເຫຼົ່ານັ້ນເປັນຂອງບົດບາດ Owner. ບົດບາດນີ້ອະນຸຍາດໃຫ້ເບິ່ງ ແລະ ສ້າງເວັບໄຊ, ເລີ່ມການເຮັດວຽກຂອງບໍລິການຄືນໃໝ່, ລຶບລ້າງ cache, ຈັດການ API keys ແລະ ຈັດການກັບ tickets. ສິດການນຳໃຊ້ (deployment) ແລະ push-to-live ກໍບໍ່ໄດ້ເປັນສ່ວນໜຶ່ງຂອງສິດທີ່ Developer ໄດ້ຮັບເຊັ່ນກັນ ດັ່ງນັ້ນການຍ້າຍໄປສູ່ production ຈຶ່ງຍັງຄົງຢູ່ກັບເຈົ້າຂອງບັນຊີ. ຄວນໃຊ້ຄູ່ກັບ staging ເພື່ອໃຫ້ການສ້າງວຽກດຳເນີນຢູ່ນອກເວັບໄຊຕົວຈິງຕັ້ງແຕ່ເລີ່ມຕົ້ນ.
ມັນຂຶ້ນກັບບົດບາດຂອງພະນັກງານທັງໝົດ, ແລະ ແຕ່ລະບົດບາດແມ່ນຊຸດຄີສິດອະນຸຍາດທີ່ສະເພາະເຈາະຈົງ. ຕົວຢ່າງ, Support Agent ສາມາດເບິ່ງບັນຊີ ແລະ ເວັບໄຊຕ໌ຂອງທ່ານ, ເບິ່ງ ແລະ ຕອບກັບປີ້ບັນຫາຂອງທ່ານ, ຣີສະຕາດເວັບໄຊຕ໌ ແລະ ລຶບແຄສ (cache) ຂອງມັນໄດ້ — ແລະ ບໍ່ສາມາດແຕະຕ້ອງຂໍ້ມູນການຕັ້ງຄ່າການຮຽກເກັບເງິນ, ການສົ່ງເງິນຄືນ, ແຜນການ ຫຼື ກຸ່ມເຊີບເວີ (fleet) ໄດ້. ການເຂົ້າສູ່ລະບົບໃນຖານະເປັນລູກຄ້າແມ່ນສິດອະນຸຍາດແຍກຕ່າງຫາກທີ່ມີພຽງແຕ່ Super Admin ເທົ່ານັ້ນ, ແລະ ເມື່ອມັນເກີດຂຶ້ນ ແຜງຄວບຄຸມຈະສະແດງປ້າຍແຈ້ງເຕືອນການປອມຕົວ (impersonation banner) ຢູ່ຕະຫຼອດເວລາ. ທຸກໆການດຳເນີນການທີ່ມີສິດທິພິເສດຈະຖືກບັນທຶກໄວ້ໃນບັນທຶກການກວດສອບ (audit log) ພ້ອມກັບຜູ້ກະທຳ, ການກະທຳ, ເປົ້າໝາຍ, IP ແລະ ວັນເວລາ, ແລະ ທ່ານສາມາດອ່ານບັນທຶກຂອງອົງກອນຂອງທ່ານໄດ້ດ້ວຍຕົນເອງ.
ລຶບສະມາຊິກພາບອອກ ແລ້ວການເຂົ້າເຖິງອົງກອນດັ່ງກ່າວຂອງພວກເຂົາຈະສິ້ນສຸດລົງ — ພວກເຂົາຍັງຄົງມີຕົວຕົນຂອງຕົນເອງຢູ່, ແຕ່ຈະບໍ່ມີບົດບາດ ແລະ ບໍ່ມີສິດອະນຸຍາດໃດໆໃນບັນຊີຂອງທ່ານ. ຄີ API ຈະຖືກຍົກເລີກເປັນລາຍອັນ, ດັ່ງນັ້ນຄີ pipeline ຈຶ່ງສາມາດຖືກຕັດອອກໄດ້ໂດຍບໍ່ລົບກວນສິ່ງອື່ນ. ຖ້າທ່ານໃຊ້ການລົງຊື່ເຂົ້າໃຊ້ຄັ້ງດຽວແບບ SAML, ການຍົກເລີກການຈັດສັນໃນຜູ້ໃຫ້ບໍລິການລະບຸຕົວຕົນຂອງທ່ານຈະຈັດການການລົງຊື່ເຂົ້າໃຊ້ຈາກສູນກາງ. ຂໍ້ມູນປະຈຳຕົວລະດັບເວັບໄຊ ເຊັ່ນ ຄີ SSH ແມ່ນຖືກຍົກເລີກຢູ່ໃນໜ້າປັດຄວບຄຸມ, ແລະ ການລຶບນັ້ນເອງກໍຈະຖືກບັນທຶກໄວ້ໃນບັນທຶກການກວດສອບ.
ບໍ່ — ແຕ່ມັນຄຸ້ມຄ່າທີ່ຈະລະບຸໃຫ້ຊັດເຈນວ່າເປັນຫຍັງ. ຄີ API ເປັນຂອງອົງກອນ, ບໍ່ແມ່ນຂອງສະມາຊິກແຕ່ລະຄົນ, ແລະ ພວກມັນມີຂອບເຂດລະອຽດຂອງຕົນເອງທີ່ເຊື່ອມໂຍງກັບລາຍການການອະນຸຍາດດຽວກັນ. ດັ່ງນັ້ນ, ແທນທີ່ຈະມອບຄີໃຫ້ບຸກຄົນໃດໜຶ່ງ, ທ່ານສ້າງຄີສຳລັບໜ້າວຽກທີ່ມັນເຮັດດ້ວຍຂອບເຂດທີ່ແຄບທີ່ສຸດທີ່ວຽກນັ້ນຕ້ອງການ, ແລະ ຍົກເລີກຄີນັ້ນເມື່ອວຽກສິ້ນສຸດລົງ. ມີພຽງ hash ຂອງຂໍ້ມູນລັບເທົ່ານັ້ນທີ່ຖືກຈັດເກັບໄວ້, ແລະ ແຕ່ລະຄີຈະບັນທຶກເວລາທີ່ມັນຖືກນຳໃຊ້ຫຼ້າສຸດ ເພື່ອໃຫ້ຄີທີ່ບໍ່ໄດ້ໃຊ້ສາມາດຊອກຫາ ແລະ ຍົກເລີກການນຳໃຊ້ໄດ້ງ່າຍ.
ແມ່ນແລ້ວ. ເຊີບເວີ MCP ຂອງພວກເຮົາຢືນຢັນຕົວຕົນຂອງຕົວແທນດ້ວຍ OAuth 2.1 ແລະ ຈຳກັດຂອບເຂດໃຫ້ກັບອົງກອນຂອງທ່ານ ແລະ ບົດບາດ RBAC ຂອງທ່ານ, ພ້ອມດ້ວຍໂທເຄັນທີ່ສາມາດຖອນຄືນໄດ້ຕາມແຕ່ລະເຄື່ອງມື, ດັ່ງນັ້ນທ່ານຈຶ່ງມອບຄວາມສາມາດສະເພາະແທນທີ່ຈະເປັນການເຂົ້າເຖິງແບບທັງໝົດ. ການດຳເນີນການທີ່ມີຜົນກະທົບຮ້າຍແຮງຕ້ອງມີການຢືນຢັນ, ມີການນຳໃຊ້ຂີດຈຳກັດການໃຊ້ຈ່າຍ, ແລະ ທຸກໆການດຳເນີນການຈະຖືກບັນທຶກໄວ້ໃນບັນທຶກການກວດສອບດຽວກັນກັບການເຄື່ອນໄຫວຂອງມະນຸດ.
Postgres Row-Level Security ຈຳກັດຂອບເຂດການສອບຖາມໄປຍັງໂຄງສ້າງຍ່ອຍຂອງອົງກອນຂອງຜູ້ຮຽກໃຊ້ໃນຖານຂໍ້ມູນເອງ, ໂດຍມີຕົວກັ່ນຕອງລະດັບແອັບພລິເຄຊັນເປັນການປ້ອງກັນແບບຮອບດ້ານຫຼາຍກວ່າທີ່ຈະເປັນພຽງດ່ານດຽວ. ຄຳຮ້ອງຂໍສຳລັບບັນທຶກທີ່ຢູ່ນອກຂອບເຂດຈະສົ່ງຄືນວ່າບໍ່ພົບແທນທີ່ຈະເປັນຂໍ້ຜິດພາດດ້ານການອະນຸຍາດ, ດັ່ງນັ້ນຈຶ່ງບໍ່ມີສິ່ງໃດຖືກເປີດເຜີຍກ່ຽວກັບສິ່ງທີ່ມີຢູ່. ໃນດ້ານເຊີບເວີ, ການແຍກສະເພາະແຕ່ລະເວັບໄຊຜ່ານ CageFS ຈະຮັກສາແຊວ ແລະ ໄຟລ໌ຂອງແຕ່ລະຜູ້ເຊົ່າໄວ້ສະເພາະເວັບໄຊຂອງພວກເຂົາເອງ.
ແມ່ນແລ້ວ. ການທົດລອງໃຊ້ 14 ວັນແມ່ນບໍ່ຕ້ອງໃຊ້ບັດ — ບໍ່ມີລາຍລະອຽດການຊຳລະເງິນ, ບໍ່ມີຂໍ້ຜູກມັດໃດໆ — ແລະ ກວມເອົາ Footprint-Free hosting ສູງສຸດເຖິງຫ້າເວັບໄຊ. ມັນພຽງພໍທີ່ຈະເຊື້ອເຊີນເພື່ອນຮ່ວມງານ, ກຳນົດບົດບາດ, ແລະ ຢືນຢັນວ່າຂອບເຂດຕ່າງໆ ເຮັດວຽກຕາມທີ່ທ່ານຕ້ອງການກ່ອນທີ່ທ່ານຈະຕັດສິນໃຈຜູກມັດ.
ເລີ່ມຕົ້ນດ້ວຍການທົດລອງໃຊ້ 14 ວັນໂດຍບໍ່ຕ້ອງໃຊ້ບັດ, ເຊີນຜູ້ໃດຜູ້ໜຶ່ງ, ແລະ ເບິ່ງຮູບແບບການອະນຸຍາດເຮັດວຽກຂອງມັນ — ບົດບາດທີ່ທ່ານສາມາດຕັ້ງຊື່ໄດ້, ຂອບເຂດທີ່ທ່ານສາມາດຍົກເລີກໄດ້, ແລະ ບັນທຶກການກວດສອບທີ່ບອກຢ່າງຊັດເຈນວ່າໃຜເຮັດຫຍັງ.
ເລີ່ມຕົ້ນຟຣີ