ການປ່ຽນ master key ແລະ ກະແຈລາຍລານື້, ແລະ ການເຂົ້າເຖິງແບບ break-glass

ການຄວບຄຸມໃນ 21-compliance.md ບົດທີ 14 ທີ່ຜູ້ກວດກາຖາມດ້ວຍຊື່. ໜ້ານີ້ແມ່ນຂັ້ນຕອນ; ບັນທຶກທີ່ມັນຜະລິດແມ່ນຫຼັກຖານ.

ກະແຈຕ່າງໆ

ລະຫັດເຂົ້າເຖິງທຸກໆອັນທີ່ເກັບໄວ້ຖືກຜະໜວກດ້ວຍກະແຈເຂົ້າ ລະຫັດຂໍ້ມູນທີ່ສ້າງໃໝ່ (DEK). DEK ຖືກຫຸ້ມດ້ວຍ master key (KEK) ແລະ ການອ້າງອີງຂອງ master key ຖືກເກັບຢູ່ຂ້າງມັນ (key_ref, ຫຼື ການອ້າງອີງພາຍໃນຄ່າທີ່ຖືກຫຸ້ມ). ການປ່ຽນ master key ຫຸ້ມ DEK ຄືນ. ມັນບໍ່ເຄີຍຖອກລະຫັດ ຫຼື ແອບລະຫັດຄືນ ລະຫັດເຂົ້າເຖິງໃດໆ.

ຊັ້ນເວັບ, worker ແລະ ຄຳສັ່ງ bun run kek:rotate ອ່ານການຕັ້ງຄ່າ ທັງສາມດຽວກັນ. ພວກມັນຕ້ອງມີຄ່າດຽວກັນທັງໝົດ ຫຼືໜຶ່ງໃນ ພວກມັນບໍ່ສາມາດເປີດສິ່ງທີ່ຄົນອື່ນຜະໜວກໄວ້ໄດ້.

ໂດຍບໍ່ມີ QUIRE_MASTER_KEY ແຕ່ລະ subsystem ຮັກສາກະແຈທີ່ມັນ ສະແດງອອກຈາກ QUIRE_SECRET_KEY. ມັນເຮັດວຽກ, ໜ້າສຸຂະພາບ ລະບົບສະແດງມັນເປັນ degraded, ແລະ ມັນຍັງອ່ານໄດ້ຫຼັງຈາກ ທ່ານຕັ້ງ master key, ເຊິ່ງແມ່ນວິທີທີ່ການປ່ຽນຄັ້ງທຳອິດ ຍ້າຍທຸກສິ່ງອອກຈາກມັນ. ໃຜກໍ່ທີ່ສາມາດອ່ານສະພາບແວດລ້ອມ ຂອງຂະບວນການສາມາດຖອກລະຫັດລະຫັດເຂົ້າເຖິງທຸກໆອັນທີ່ ເກັບໄວ້ ດັ່ງນັ້ນການຕິດຕັ້ງການຜະລິດຄວນມີ master key, ເກັບໄວ້ໃນຮ້ານຄວາມລັບ ແລະບໍ່ຢູ່ໃນ backup ດຽວກັນກັບ ຖານຂໍ້ມູນ.

ການປ່ຽນ

ອາຍຸຂອງກະແຈສະແດງຢູ່ Platform console, Security, Master key, ແລະ ເປັນ metric quire.secrets.master_key.age (ມື້). ຕາຕະລາປັບປະຈຳ ມື້ platform.key_age (03:41 UTC) ຂຽນລາຍການເຕືອນເຂົ້າເສັ້ນ ການກວດກາຂອງເພລຟອມເມື່ອກະແຈຮອດ 365 ມື້, ແລະອີກຄັ້ງ ທຸກໆ 30 ມື້ຈົນກວ່າຈະຖືກປ່ຽນ. ປ່ຽນຕາມການເຕືອນ, ແລະ ທຸກໆຄັ້ງທີ່ກະແຈອາດຖືກເປີດເຜີຍ.

1. ສ້າງກະແຈໃໝ່: openssl rand -base64 32.
2. ຕັ້ງ QUIRE_MASTER_KEY ເປັນມັນ ແລະ QUIRE_MASTER_KEY_VERSION ເປັນປ້າຍຕໍ່ໄປ (v2). ຍ້າຍກະແຈເກົ່າໄປ QUIRE_MASTER_KEY_RETIRED ເປັນ v1=<old base64>. ເກັບສຳເນົາທັງສອງໄວ້ໃນບ່ອນອື່ນນອກ ເໜືອເຊີບເວີນີ້.
3. ສົ່ງຊັ້ນເວັບ ແລະ worker ດ້ວຍການຕັ້ງຄ່າໃໝ່. ຄວາມລັບໃໝ່ ຕອນນີ້ຖືກຫຸ້ມໄວ້ພາຍໃຕ້ env:QUIRE_MASTER_KEY:v2; ອັນເກົ່າ ຍັງເປີດຜ່ານກະແຈທີ່ຫຍັກລົບແລ້ວ.
4. ຂໍການປ່ຽນ, ພ້ອມເຫດຜົນທີ່ຈະຢູ່ໃນເສັ້ນການກວດກາ:
   • ໃນ console: Security, Master key, Rotate the master key; ຫຼື
   • ໃນ shell ທີ່ມີສະພາບແວດລ້ອມດຽວກັນ: bun run kek:rotate request --reason "Annual rotation, ticket SEC-114".
5. Worker ຫຸ້ມສ່ວນໜຶ່ງຕໍ່ນາທີ (ຕາຕະລາປັບ platform.key_rotation ຂອງ scheduler) ແລະ ສືບຕໍ່ຫຼັງການເລີ່ມລະບົບຄືນ. ເພື່ອ ສຳເລັດມັນໃນການນັ່ງດຽວ: bun run kek:rotate run. ຕິດຕາມມັນ ດ້ວຍ bun run kek:rotate status.
6. ເມື່ອບັນທຶກສະແດງວ່າການປ່ຽນສຳເລັດພ້ອມ zero unresolved and zero failed, ລຶບກະແຈທີ່ຫຍັກລົບອອກຈາກ QUIRE_MASTER_KEY_RETIRED ແລະ ສົ່ງຄືນ. ຈົນຮອດເວລານັ້ນ ຮັກສາມັນໄວ້: ຄ່າທີ່ມັນຍ້າຍບໍ່ໄດ້ຍັງຖືກຫຸ້ມໄວ້ພາຍໃຕ້ ກະແຈເກົ່າ.

ສິ່ງທີ່ງານນີ້ກວດເບິ່ງ

ຮ້ານເກັບທຸກໆແຫ່ງທີ່ຖືກຫຸ້ມ DEK: ອັນທີ່ຢູ່ໃນ SEALED_STORES (apps/worker/src/key-rotation.ts). ຮ້ານເກັບຂອງຖານຂໍ້ມູນ ຄວບຄຸມຖືກກວດເບິ່ງເທິງຖານຂໍ້ມູນຄວບຄຸມ; ຮ້ານເກັບຂອງ ອົງການຖືກກວດເບິ່ງອົງການໜຶ່ງຄັ້ງພາຍໃຕ້ການປ້ອງກັນຂັ້ນ ແຖວ, ໃນຖານຂໍ້ມູນໃດກໍ່ທີ່ຖືກອົງການນັ້ນ, ດັ່ງນັ້ນ tenant ທີ່ຖືກຜູກກັບຖານຂໍ້ມູນສະເພາະຈະຖືກປ່ຽນໃນຖານຂໍ້ມູນນັ້ນ. ການທົດສອບລົ້ມເມື່ອ schema ໄດ້ຖານກະແຈທີ່ຫຸ້ມເພີ່ມເຂົ້າມາ ທີ່ລາຍຊື່ບໍ່ລະບຸຊື່, ແລະອີກອັນໜຶ່ງເມື່ອການທວດສອບ ລະຫັດເຂົ້າເຖິງຈັດປະເພດຖານທີ່ຜະໜວກທີ່ລາຍຊື່ພາດ.

ບັນທຶກ

• ops.key_rotation: ແຖວໜຶ່ງຕໍ່ການປ່ຽນ, ພ້ອມເຫດຜົນຂອງມັນ, ໃຜຂໍມັນ, ສະຖານະຂອງມັນ ແລະ ລວມທັງໝົດຂອງມັນ (ຫຸ້ມຄືນ, ປັດຈຸບັນຢູ່ແລ້ວ, ບໍ່ສຳເລັດ, ລົ້ມແຫຼວ).
• ops.key_rotation_progress: ແຖວໜຶ່ງຕໍ່ຮ້ານເກັບ ແລະ scope ໜຶ່ງ ຄັ້ງທີ່ກວດແລ້ວ, ພ້ອມການອ້າງອີງກະແຈທີ່ມັນບໍ່ສາມາດອ່ານ ໄດ້ ແລະ ມີຈຳນວນຄ່ານັ່ງໃດຢູ່ພາຍໃຕ້ແຕ່ລະອັນ. ການປ່ຽນ ທີ່ສືບຕໍ່ຂ້າມສິ່ງເຫຼົ່ານີ້.
• ເສັ້ນການກວດກາຂອງເພລຟອມ: platform/key_rotation_request (ພ້ອມເຫດຜົນ), platform/key_rotation_store ໜຶ່ງຕໍ່ຮ້ານເກັບ ພ້ອມຈຳນວນຂອງມັນ, ແລະ platform/key_rotation_complete ຫຼື platform/key_rotation_fail; platform/key_age_reminder ສຳລັບການເຕືອນ.
• Metrics: quire.secrets.master_key.age ແລະ quire.secrets.rewrap.outstanding (ຄ່າທີ່ການປ່ຽນຄັ້ງສຸດທ້າຍ ຍ້າຍບໍ່ໄດ້).

ເມື່ອຄ່າບໍ່ສຳເລັດ

ຄ່າທີ່ບໍ່ສຳເລັດແມ່ນຄ່າທີ່ຖືກຫຸ້ມພາຍໃຕ້ການອ້າງອີງກະແຈ ທີ່ການຕິດຕັ້ງນີ້ບໍ່ຖືກໄວ້, ຫຼືບໍ່ຢູ່ໃນຮູບແບບທີ່ຖານຂອງ ມັນສັນຍາໄວ້. ບັນທຶກຄວາມຄືບໜ້າລະບຸການອ້າງອີງ (ຕົວຢ່າງ env:QUIRE_MASTER_KEY:v0 (unreadable)). ກູ້ກະແຈນັ້ນຄືນເຂົ້າ QUIRE_MASTER_KEY_RETIRED ແລະ ແລ່ນການປ່ຽນອີກຄັ້ງ, ຫຼື, ຖ້າ ກະແຈຫາຍໄປຖາວ, ໃຫ້ຜູ້ບໍລິຫານຂອງອົງການນັ້ນໃສ່ລະຫັດ ເຂົ້າເຖິງຄືນ: ມັນຈາກນັ້ນຖືກຜະໜວກພາຍໃຕ້ກະແຈປະຈຸບັນ. ການປ່ຽນທີ່ລົ້ມແຫຼວສະແດງຂໍ້ຜິດພາດຂອງພວກມັນຢູ່ໃນ ບັນທຶກ; ແກ້ເຫດຜົນ ແລະ ຂໍອີກຄັ້ງ.

ກະແຈລາຍລານື້

ແຍກອອກຈາກ master key: ແຕ່ລະອົງການລາຍລານື້ OpenID Connect tokens ແລະ ຂໍ້ຄວາມ LTI ຂອງຕົນດ້ວຍກະແຈ RSA ເອງ, ເຜີຍແຜ່ ຢູ່ /.well-known/jwks.json. ບໍ່ມີຫຍັງທີ່ນີ້ຕ້ອງການຜູ້ດຳເນີນ ການ. ຕາຕະລາປັບລຳດັບຊົ່ວໂມງ platform.signing_keys ເຜີຍ ແຜ່ຜູ້ສືບທອດເຈົ້າ 7 ມື້ກ່ອນທີ່ 90 ມື້ຂອງກະແຈປະຈຸບັນຈະ ໝົດ, ໜຶ່ງອາທິດຕໍ່ມາຜູ້ສືບທອດເລີ່ມລາຍລານື້ ແລະ ກະແຈ ເກົ່າກາຍເປັນກະແຈລຳລັບການປ່ຽນ, ແລະ 90 ມື້ຫຼັງຈາກ ນັ້ນກະແຈເກົ່າຖືກລຶບ ແລະ ອອກຈາກຊຸດກະແຈ. ທຸກຂັ້ນຕອນ ແມ່ນລາຍການ platform/signing_key_advance ໃນເສັ້ນການກວດກາ ຂອງເພລຟອມ.

ເພື່ອແທນກະແຈຂອງອົງການກ່ອນເວລາ, ຕົວຢ່າງຫຼັງຈາກການ ເປີດເຜີຍ:

• ໃນ console: Security, Master key, Publish a new signing key (ຕ້ອງການ platform/keys_manage); ຫຼື
• ໃນ shell ທີ່ມີສະພາບແວດລ້ອມຂອງ worker: bun run kek:rotate signing-keys rotate --tenant <slug or id> --reason "Key exposed, INC-3310". bun run kek:rotate signing-keys status ລາຍຊື່ກະແຈຂອງແຕ່ລະອົງການຕາມຂັ້ນຕອນ.

ກະແຈໃໝ່ຖືກເຜີຍແຜ່ທັນທີ ແລະ ເລີ່ມລາຍລານື້ຫຼັງ 7 ມື້, ເມື່ອກະແຈປະຈຸບັນປ່ຽນ. ໜຶ່ງອາທິດແມ່ນການຕັ້ງໃຈ: relying parties ເກັບຊຸດກະແຈໄວ້ໃນ cache, ແລະຊ່ວງທີ່ທັບກັນສັ້ນ ກວ່າຈະເຮັດໃຫ້ເຄື່ອງມືທຸກໆອັນລົ້ມແຫຼວທັນທີ. ກະແຈທີ່ ກຳລັງປ່ຽນຢູ່ໃນຊຸດກະແຈຕໍ່ອີກ 90 ມື້ເພື່ອໃຫ້ tokens ທີ່ມັນ ລາຍລານື້ແລ້ວສືບຕໍ່ຜ່ານການກວດສອບ; ຖ້າການເປີດເຜີຍໝາຍ ຄວາມວ່າມັນຕ້ອງຢຸດການໄວ້ເຊື່ອຖືໄວ້ໄວ້ກວ່ານັ້ນ ການລຶບ ແຖວຂອງມັນເປັນການປ່ຽນແປງທີ່ເຮັດດ້ວຍການເຂົ້າເຖິງຖານ ຂໍ້ມູນຂອງຜູ້ດຳເນີນການເອງພາຍໃຕ້ບັນທຶກການປ່ຽນແປງ (ການເຂົ້າເຖິງແບບ break-glass ເປັນແຕ່ອ່ານ), ແລະ tokens ທີ່ ລາຍລານື້ດ້ວຍມັນຈາກນັ້ນລົ້ມການກວດສອບ. ການປ່ຽນທີ່ບັງ ຄັບແມ່ນ platform/signing_key_rotate ໃນເສັ້ນການກວດກາ, ພ້ອມ ເຫດຜົນ. Worker ຕ້ອງການການຕັ້ງຄ່າ QUIRE_MASTER_KEY ດຽວກັນ ກັບຊັ້ນເວັບເພື່ອຫຸ້ມກະແຈໃໝ່; bun run kek:rotate ສຳລັບ master key ຫຸ້ມກະແຈລາຍລານື້ຄືນພ້ອມສິ່ງອື່ນທັງໝົດ (oauth_signing_key ຢູ່ໃນ SEALED_STORES).

ການເຂົ້າເຖິງ production ແບບ break-glass

ບໍ່ມີໃຜຖືການເຂົ້າເຖິງຖາວອນກັບ production. ເມື່ອສິ່ງໃດບໍ່ ສາມາດລໍຖ້າໄດ້ ເຈົ້າຂອງອອກການອະນຸມັດແບບ break-glass: Platform console, Security, Break-glass access.

• ການອະນຸມັດມີ scope (ອົງການໜຶ່ງ, ຫຼື platform registry), ເຫດຜົນຢ່າງໜ້ອຍ 20 ຕົວອັກສອນທີ່ລະບຸເຫດການ ຫຼື ເທິກເກັດ ແລະຊ່ວງເວລາ 5 ຫາ 240 ນາທີ. ມັນໝົດອາຍຸ ໂດຍຕົນເອງ: ມັນຖືກກວດສອບທຽບກັບເວລາໃນທຸກຖາອ້າງ.
• ມັນສາມາດອອກໃຫ້ເຈົ້າຂອງຜູ້ທີ່ອອກມັນ, ຫຼືໃຫ້ເຈົ້າ ອື່ນ (ຮູບແບບສອງຄົນ). ແຕ່ຄົນທີ່ມັນຖືກອອກໃຫ້ເທົ່າ ນັ້ນທີ່ສາມາດໃຊ້ມັນ. ການອອກຕ້ອງການ platform/break_glass_issue ແລະການໃຊ້ຕ້ອງການ platform/break_glass_use; ທັງສອງເປັນເຈົ້າຂອງເທົ່ານັ້ນ ໂດຍຄ່າເລີ່ມຕົ້ນ.
• ຖາອ້າງແລ່ນຜ່ານ gateway, ບໍ່ແມ່ນການເຂົ້າສູ່ຖານຂໍ້ມູນ: ແຕ່ອ່ານ, ທີ່ລະຄັ້ງ, ຖືກຈຳກັດໄວ້ຕໍ່ອົງການ ຫຼື platform registry, ພ້ອມ timeout 5 ວິນາທີ ແລະສູງສຸດ 500 ແຖວ. ຄ່າ binary ຖືກສະແດງຕາມຂະໜາດ.
• ເສັ້ນການກວດກາຂອງເພລຟອມບັນທຶກການອອກ (ພ້ອມເຫດ ຜົນ), ການຍົກເລີກ, ຖາອ້າງທຸກໆອັນກ່ອນທີ່ຈະແລ່ນ (platform/break_glass_statement, ອັນທີ່ຖືກປະຕິເສດພ້ອມ outcome denied) ແລະຜົນລັບທຸກໆອັນ (platform/break_glass_result). ops.break_glass_statement ເກັບ ids ຂອງລາຍການການກວດກາ ດັ່ງນັ້ນບັນທຶກການອອກ ຕິດກັບລາຍການການກວດກາຂອງມັນ.
• ການຂຽນບໍ່ຖືກສະເໜີ. ການປ່ຽນແປງທີ່ບໍ່ສາມາດລໍຖ້າ ສະບັບເຜີຍແຜ່ໃຊ້ການເຂົ້າເຖິງຖານຂໍ້ມູນຂອງຜູ້ດຳເນີນ ການເອງພາຍໃຕ້ບັນທຶກການປ່ຽນແປງຂອງຕົນ, ນອກເໜືອ ຜະລິດຕະພັນນີ້, ແລະບັນທຶກຄວນອ້າງເຫດການອ້າງອີງ ທີ່ໃຊ້ຢູ່ທີ່ນີ້.

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

ເພື່ອຕອບຄຳຂໍການກວດກາ: ລາຍຊື່ການອະນຸມັດໃນໄລຍະເວລາ (Break-glass access), ເປີດປະຫວັດຂອງການອະນຸມັດໜຶ່ງເພື່ອ ຖາອ້າງ ແລະ ids ຂອງລາຍການການກວດກາ, ແລະອ່ານລາຍການ ເຫຼົ່ານັ້ນເທິງເສັ້ນການກວດກາຂອງເພລຟອມ (bun run audit:verify --platform ພິສູດວ່າເສັ້ນຄົບຖ້ວນ).