Мастер түлхүүр болон гарын үсэглэх түлхүүрийн эргэлт, мөн break-glass хандалт

21-compliance.md хэсэг 14 дэх хяналтууд — аудитор нэргээр нь асуудаг нь. Энэ хуудас нь процедур; үүнээс гарах бүртгэлүүд нь нотолгоо юм.

Түлхүүрүүд

Хадгалагдсан бүх итгэмжлэл шинэ өгөгдлийн шифрлэх түлхүүрээр (DEK) лаклагддог. DEK нь мастер түлхүүрээр (KEK) ороогддог бөгөөд мастер түлхүүрийн иш нь түүний хажууд хадгалагддаг (key_ref, эсвэл ороосон утган доторх иш). Мастер түлхүүрийг эргүүлэх нь DEK-үүдийг дахин ороодог. Хэзээ ч итгэмжлэлийг задалж эсвэл дахин шифрлэдэггүй.

Веб түвшин, ажилч, мөн bun run kek:rotate команда ижил гурван тохиргоог уншдаг. Тэд бүгд ижил утгатай байх ёстой, эсвэл нэг нь нөгөөний лакласныг нээж чадахгүй.

QUIRE_MASTER_KEY-гүй бол бүр дэд систем нь QUIRE_SECRET_KEY-ээс улбаалсан түлхүүрээ хадгалдаг. Энэ нь ажиллана, Системийн эрүүл мэндийн хуудас үүнийг дордуулсан гэж харуулах бөгөөд мастер түлхүүр тогтоосны дараа ч унших боломжтой хэвээр үлдэнэ — энэ нь анхны эргэлт бүх зүйлийг түүнээс гаргах арга юм. Процессын орчныг уншиж чаддаг хэн бүхэн хадгалагдсан бүх итгэмжлэлийг задалж чадна тул үйлдвэрлэлийн суулгалтад мастер түлхүүр байх ёстой — нууцлалын дэлгүүрт хадгалагдах бөгөөд өгөгдлийн сантай ижил нөөцөнд биш.

Эргүүлэх

Түлхүүрийн нас нь Platform console, Security, Master key дээр, мөн 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. Веб түвшин, ажилчийг шинэ тохиргоотойгоор байршуулна уу. Шинэ нууцлалууд одоо env:QUIRE_MASTER_KEY:v2-ийн дор ороогддог; хуучнууд хэвээр тэтгэгдсэн түлхүүрээр нээгдсээр байна.
4. Эргэлтийг шаардаад, аудитын мөрд үлдэх шалтгаантайгаар:
   • консол дээр: Security, Master key, мастер түлхүүрийг эргүүлэх; эсвэл
   • ижил орчинтой shell дээр: bun run kek:rotate request --reason "Annual rotation, ticket SEC-114".
5. Ажилч нэг минутанд хэсэг бүрийг дахин ороодог (platform.key_rotation хуваарь) мөн дахин ачаалсны дараа үргэлжлүүлнэ. Нэг суудал дээр дуусгахын тулд: bun run kek:rotate run. bun run kek:rotate status-аар хянана уу.
6. Бүртгэл дээр эргэлт шийдвэрлэгдээгүй нь тэг, амжилтгүй нь тэг гэж дууссан үед тэтгэгдсэн түлхүүрийг QUIRE_MASTER_KEY_RETIRED-аас арилгаад дахин байршуулна уу. Түүнээс өмнө хадгалаарай: түүний шилжүүлж чадаагүй утга хэвээр хуучин түлхүүр дор ороогдсон байна.

Ажил юуг тойрон явдаг вэ

Ороогдсон DEK барьдаг бүх хадгалалт: SEALED_STORES-д байгаа нь (apps/worker/src/key-rotation.ts). Хяналтын өгөгдлийн сангийн хадгалалтууд хяналтын өгөгдлийн сан дээр тойрон явдаг; байгууллагын хадгалалтууд нэг байгууллага нэгээр нь, мөр түвшний хамгаалалтын дор, аль өгөгдлийн сан тэр байгууллагыг барьж байгаагаас үл хамааран тойрон явдаг — тусгай өгөгдлийн санд бэхэлэгдсэн түрээсч тэр өгөгдлийн санд эргүүлэгдэнэ. Схем жагсаалтад нэрлээгүй ороогдсон түлхүүрийн багана нэмвэл тест амжилтгүй болох бөгөөд өөр нэг нь итгэмжлэлийн хяналт жагсаалтад ороогүй лакласан баганыг ялган таних үед амжилтгүй болно.

Бүртгэл

• ops.key_rotation: эргэлт бүрт нэг мөр, түүний шалтгаан, хэн шаардсан, төлөв, нийт дүнгээр (дахин орогдсон, аль хэдийн одоогийн, шийдвэрлэгдээгүй, амжилтгүй).
• ops.key_rotation_progress: хадгалалт, хүрээ бүрт тойрон явсныхаа дараа нэг мөр — тэр уншиж чадаагүй түлхүүрийн ишүүд, мөн тэдгээрийн дор хэдэн утга байсныг. Үргэлжилсэн эргэлт эдгээрийг алгасдаг.
• Платформын аудитын хэлхээ: platform/key_rotation_request (шалтгаантай), хадгалалт бүрт тоонуудтай нэг platform/key_rotation_store, мөн platform/key_rotation_complete эсвэл platform/key_rotation_fail; сануулгын хувьд platform/key_age_reminder.
• Хэмжигдэхүүд: quire.secrets.master_key.age болон quire.secrets.rewrap.outstanding (сүүлд эргэлт шилжүүлж чадаагүй утгууд).

Утгууд шийдвэрлэгдээгүй үед

Шийдвэрлэгдээгүй утга нь энэ суулгалт эзэмшдэггүй түлхүүрийн ишийн дор ороогдсон, эсвэл түүний багана амласан хэлбэрийн биш байна. Явцын бүртгэл ишийг нэрлэнэ (жишээ нь env:QUIRE_MASTER_KEY:v0 (unreadable)). Тэр түлхүүрийг QUIRE_MASTER_KEY_RETIRED-рүү сэргээгээд өөр эргэлт ажиллуулна уу, эсвэл тэр түлхүүр бүрмөсөн алдагдсан бол байгууллагын администратор итгэмжлэлийг дахин оруулахыг хийнэ үү: ингэснээр тэр одоогийн түлхүүр дор лаклагдана. Амжилтгүй эргэлтүүд алдаагаа бүртгэл дээр харуулна; шалтгааныг засаад дахин шаардана уу.

Гарын үсэглэх түлхүүрүүд

Мастер түлхүүрөөс тусад нь: бүр байгууллага өөрийн OpenID Connect token болон LTI мессежүүдийг өөрийн RSA түлхүүрээр гарын үсэглэдэг бөгөөд /.well-known/jwks.json дээр нийтлэгдэнэ. Энд хэн ч оператор шаардлагагүй. Цаг тутмын platform.signing_keys хуваарь нь одоогийн түлхүүрийн ерэн өдөр дуусахаас долоо хоногийн өмнө өв залгамжлагчийг нийтлэдэг, долоо хоногийн дараа өв залгамжлагч гарын үсэглэж эхэлж, хуучин түлхүүр тэтгэгдэх төлөвт ордог, түүнээс дараа ерэн хоногийн дараа хуучин түлхүүр устгагдаж түлхүүрийн багцаас гардаг. Бүх алхам нь платформын аудитын хэлхээ дэх platform/signing_key_advance бичлэг юм.

Байгууллагын түлхүүрийг эрт солихын тулд, жишээ нь ил болсны дараа:

• консол дээр: Security, Master key, Шинэ гарын үсэглэх түлхүүр нийтлэх (platform/keys_manage шаардлагатай); эсвэл
• ажилчийн орчинтой shell дээр: bun run kek:rotate signing-keys rotate --tenant <slug or id> --reason "Key exposed, INC-3310". bun run kek:rotate signing-keys status нь бүх байгууллагын түлхүүрүүдийг үе шаттай нь жагсаана.

Шинэ түлхүүр шууд нийтлэгдээд долоо хоногийн дараа гарын үсэглэж эхэлнэ — одоогийн түлхүүр тэтгэгдэх үед. Тэр долоо хоног санаатай: найдвар эзэмшигчид түлхүүрийн багцыг кэшлэдэг бөгөөд илүү богино давхцаалт бүх хэрэгслийг нэгэн зэрэг унагана. Тэтгэгдэж буй түлхүүр дахин ерэн хоног түлхүүрийн багцад үлддэг — ингэснээр тэр аль хэдийн гарын үсэглэсэн token-ууд баталгаажсаар байна; хэрэв ил болсноос болж итгэхээ эрт зогсоох шаардлагатай бол түүний мөрийг устгах нь операторын өөрийн өгөгдлийн сангийн хандалгаар, өөрчлөлтийн бүртгэлийн дор хийгдэх өөрчлөлт юм (break-glass хандалт зөвхөн унших эрхтэй), мөн түүний гарын үсэгтэй token-ууд дараа нь баталгаажуулалтанд амжилтгүй болно. Хүчингүй эргэлт нь аудитын хэлхээ дэх шалтгаантай platform/signing_key_rotate юм. Ажилчид шинэ түлхүүрийг ороохын тулд веб түвшинтэй ижил QUIRE_MASTER_KEY тохиргоонууд шаардлагатай; мастер түлхүүрийн bun run kek:rotate нь гарын үсэглэх түлхүүрүүдийг бусад бүх зүйлтэй хамт дахин ороодог (oauth_signing_key нь SEALED_STORES-д байна).

Яаралтай үйлдвэрлэлийн хандалт (break-glass)

Хэн ч үйлдвэрлэлд байнгын хандалт эзэмшдэггүй. Юу ч хүлээж чадахгүй үед эзэмшигч break-glass эрх олгодог: Platform console, Security, Break-glass access.

• Эрх нь хүрээтэй (нэг байгууллага эсвэл платформын реестр), инцидент эсвэл дугаарыг нэрлэсэн хамгийн багадаа 20 тэмдэгт шалтгаантай, мөн 5-аас 240 минутын цонхтой. Үүнийг хугацаа нь өөрөө дуусдаг: бүр мэдэгдэл бүрт цагийн зүүтэй харьцуулагдана.
• Эрхийг өөрөө олгодог эзэмшигчид, эсвэл өөр эзэмшигчид олгож болно (хоёр хүний хэлбэр). Зөвхөн эрхийг хүлээн авсан хүн л ашиглах боломжтой. Олгоход platform/break_glass_issue, ашиглахад platform/break_glass_use шаардлагатай; хоёулаа өгөгдсөнөөр зөвхөн эзэмшигчид.
• Мэдэгдлүүд шүглээр дамжуулан ажилладаг, өгөгдлийн сангийн нэвтрэлтээр биш: зөвхөн унших, нэг нэгээр нь, байгууллага эсвэл хяналтын реестрт хязгаарлагдсан, таван секундийн хугацаатай, хамгийн ихдээ 500 мөр. Хоёртын утгууд хэмжээгээр харуулагдана.
• Платформын аудитын хэлхээ олголтыг (шалтгаантай), цуцалтыг, ажиллахаасаа өмнөх бүх мэдэгдлийг (platform/break_glass_statement, татгалзсан нь denied үр дүнтэй), мөн бүх үр дүнг бүртгэнэ (platform/break_glass_result). ops.break_glass_statement нь аудитын бичлэгийн id-үүдийг хадгалдаг тул олголтын бүртгэл нь аудитын бичлэгүүдтэйгээ холбогддог.
• Бичлэгүүд санал болгогдохгүй. Хувилбар хүлээж чадахгүй өөрчлөлт нь энэ бүтээгдэхүүнээс гадуур, өөрийн өөрчлөлтийн бүртгэлийн дор операторын өөрийн өгөгдлийн сангийн хандалгаар хийгдэх бөгөөд бүртгэлд энд ашигласан инцидентийн иш-ийг дурдах ёстой.

Яагаад өгөгдлийн сангийн итгэмжлэл олгохгүй вэ: PostgreSQL нэвтрэлт нь түүнийг хүсэж байсан сессийн насанд урт байдаг, аппликейшн найддаг мөр түвшний хамгаалалтыг тойрдог, мөн энэ бүтээгдэхүүний аудитын хэлхээд бичиж чадахгүй тул түүний мэдэгдлүүд зөвхөн хэн нэгэн серверийн логийг илгээсэн хэрээр аудитлагдана. Шүгэл нь аудитын мөрийг түүний эргэн тойронд биш, хандалгын шинж чанар болгон хувиргадог.

Аудитын хүсэлтэд хариулахын тулд: хугацааны доторх эрхүүдийг жагсаарай (Break-glass access), эрхийн түүхийг нээж мэдэгдлүүд болон аудитын бичлэгийн id-үүдийг аваад, тэдгээр бичлэгийг платформын аудитын хэлхээ дээр уншина уу (bun run audit:verify --platform хэлхээ гэмтээгүйг нотолно).