മാസ്റ്റർ കീയും ഒപ്പിടൽ കീ റൊട്ടേഷനും, ബ്രേക്ക്-ഗ്ലാസ് പ്രവേശനവും

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, മാസ്റ്റർ കീ റൊട്ടേറ്റ് ചെയ്യൂ; അല്ലെങ്കിൽ
   • അതേ എൻവിരോൺമെന്റുള്ള ഒരു ഷെല്ലിൽ: 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-ലേക്ക് പുനഃസ്ഥാപിച്ച് മറ്റൊരു റൊട്ടേഷൻ പ്രവർത്തിപ്പിക്കൂ, അല്ലെങ്കിൽ കീ ശാശ്വതമായി പോയെങ്കിൽ, സ്ഥാപനത്തിന്റെ അഡ്മിനിസ്ട്രേറ്റർ ക്രെഡൻഷ്യൽ വീണ്ടും നൽകട്ടെ: അപ്പോൾ അത് നിലവിലെ കീയ്ക്കു കീഴിൽ സീല് ചെയ്യപ്പെടും. പരാജയപ്പെട്ട റൊട്ടേഷനുകൾ രേഖയിൽ അവയുടെ പിശക് കാണിക്കും; കാരണം തിരുത്തി വീണ്ടും അഭ്യർത്ഥിക്കൂ.

ഒപ്പിടൽ കീകൾ

മാസ്റ്റർ കീയിൽ നിന്ന് വേറിട്ട്: ഓരോ സ്ഥാപനവും /.well-known/jwks.json-ൽ പ്രസിദ്ധീകരിക്കുന്ന സ്വന്തം കീ ഉപയോഗിച്ച് തങ്ങളുടെ OpenID Connect ടോക്കണുകളും LTI സന്ദേശങ്ങളും ഒപ്പിടും. ഇവിടെ ഒരു ഓപ്പറേറ്ററും ആവശ്യമില്ല. മണിക്കൂറിലൊരിക്കൽ പ്രവർത്തിക്കുന്ന platform.signing_keys ഷെഡ്യൂൾ നിലവിലെ കീയുടെ തൊണ്ണൂറ് ദിവസം തീരും ഏഴ് ദിവസം മുമ്പ് ഒരു അടുത്ത കീ പ്രസിദ്ധീകരിക്കും, ഒരാഴ്ച കഴിഞ്ഞ് അടുത്ത കീ ഒപ്പിടാൻ ആരംഭിക്കുകയും പഴയ കീ റിട്ടയർ ചെയ്യുന്നതായും മാറും, അതിന് ശേഷം തൊണ്ണൂറ് ദിവസം കഴിഞ്ഞ് പഴയ കീ ഇല്ലാതാക്കപ്പെടുകയും കീ സെറ്റ് വിട്ടുപോവുകയും ചെയ്യും. ഓരോ ഘട്ടവും പ്ലാറ്റ്ഫോം ഓഡിറ്റ് ചെയിനിലെ ഒരു platform/signing_key_advance എൻട്രിയാണ്.

ഉദാഹരണത്തിന് ഒരു ചോർച്ചയ്ക്ക് ശേഷം, ഒരു സ്ഥാപനത്തിന്റെ കീ നേരത്തേ മാറ്റാൻ:

• കൺസോളിൽ: Security, Master key, പുതിയ ഒപ്പിടൽ കീ പ്രസിദ്ധീകരിക്കൂ (platform/keys_manage ആവശ്യം); അല്ലെങ്കിൽ
• വർക്കറിന്റെ എൻവിരോൺമെന്റുള്ള ഒരു ഷെല്ലിൽ: bun run kek:rotate signing-keys rotate --tenant <slug or id> --reason "Key exposed, INC-3310". bun run kek:rotate signing-keys status ഓരോ സ്ഥാപനത്തിന്റെയും കീകൾ ഘട്ടം അനുസരിച്ച് പട്ടികപ്പെടുത്തും.

പുതിയ കീ ഉടൻ പ്രസിദ്ധീകരിക്കപ്പെടുകയും ഏഴ് ദിവസം കഴിഞ്ഞ്, നിലവിലെ കീ റിട്ടയർ ചെയ്യുമ്പോൾ, ഒപ്പിടാൻ ആരംഭിക്കുകയും ചെയ്യും. ആ ആഴ്ച ഉദ്ദേശപൂർവ്വമാണ്: ആശ്രയിക്കുന്ന കക്ഷികൾ കീ സെറ്റ് ക്യാഷ് ചെയ്യും, ചെറിയ ഒരു കാലയളവ് എല്ലാ ടൂളുകളെയും ഒരേ സമയം പരാജയപ്പെടുത്തും. റിട്ടയർ ചെയ്യുന്ന കീ ഇനിയും തൊണ്ണൂറ് ദിവസം കീ സെറ്റിൽ നിൽക്കും, അതിനാൽ അത് ഇതിനകം ഒപ്പിട്ട ടോക്കണുകൾ പരിശോധന തുടർന്നും കടന്നുപോകും; ചോർച്ച അർത്ഥമാക്കുന്നത് അതിനെ വേഗത്തിൽ വിശ്വസിക്കുന്നത് നിർത്തണമെന്നാണെങ്കിൽ, അതിന്റെ വരി ഇല്ലാതാക്കുന്നത് ഒരു മാറ്റ രേഖയോടെ, ഓപ്പറേറ്ററുടെ സ്വന്തം ഡാറ്റാബേസ് പ്രവേശനം ഉപയോഗിച്ചുള്ള ഒരു മാറ്റമാണ് (ബ്രേക്ക്-ഗ്ലാസ് പ്രവേശനം വായന മാത്രമാണ്), അതിനാൽ അതോടൊപ്പം ഒപ്പിട്ട ടോക്കണുകൾ പരിശോധനയിൽ പരാജയപ്പെടും. നിർബന്ധിത റൊട്ടേഷൻ കാരണത്തോടെ ഓഡിറ്റ് ചെയിനിലെ platform/signing_key_rotate ആണ്. പുതിയ കീ റാപ്പ് ചെയ്യാൻ വർക്കറിന് വെബ് ടയറിന്റെ അതേ QUIRE_MASTER_KEY ക്രമീകരണങ്ങൾ ആവശ്യമാണ്; മാസ്റ്റർ കീയ്ക്കുള്ള bun run kek:rotate ബാക്കിയെല്ലാം സഹിതം ഒപ്പിടൽ കീകൾ വീണ്ടും റാപ്പ് ചെയ്യും (oauth_signing_key SEALED_STORES-ൽ ഉണ്ട്).

ബ്രേക്ക്-ഗ്ലാസ് പ്രൊഡക്ഷൻ പ്രവേശനം

ഒരാളും പ്രൊഡക്ഷനിൽ സ്ഥിരമായ പ്രവേശനം വഹിക്കുന്നില്ല. എന്തെങ്കിലും കാത്തിരിക്കാൻ കഴിയാത്തപ്പോൾ, ഒരു ഉടമ ഒരു ബ്രേക്ക്-ഗ്ലാസ് അനുമതി നൽകും: 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-കൾ സൂക്ഷിക്കുന്നു, അതിനാൽ നൽകിയ രേഖ അതിന്റെ ഓഡിറ്റ് എൻട്രികളുമായി ബന്ധപ്പെടും.
• എഴുത്തുകൾ വാഗ്ദാനം ചെയ്യുന്നില്ല. ഒരു റിലീസിനായി കാത്തിരിക്കാൻ കഴിയാത്ത ഒരു മാറ്റം സ്വന്തം മാറ്റ രേഖയോടെ, ഈ ഉൽപ്പന്നത്തിന് പുറത്ത്, ഓപ്പറേറ്ററുടെ സ്വന്തം ഡാറ്റാബേസ് പ്രവേശനം ഉപയോഗിക്കും, ഇവിടെ ഉപയോഗിച്ച സംഭവ റഫറൻസ് രേഖയിൽ ഉദ്ധരിക്കണം.

ഡാറ്റാബേസ് ക്രെഡൻഷ്യലുകൾ നൽകാത്തത് എന്തുകൊണ്ട്: ഒരു Postgres ലോഗിൻ അത് ആവശ്യപ്പെട്ട സെഷനേക്കാൾ ദീർഘകാലം നിലനിൽക്കും, ആപ്ലിക്കേഷൻ ആശ്രയിക്കുന്ന റോ-ലെവൽ സെക്യൂരിറ്റി മറികടക്കും, ഈ ഉൽപ്പന്നത്തിന്റെ ഓഡിറ്റ് ചെയിനിൽ എഴുതാൻ കഴിയില്ല, അതിനാൽ അതിന്റെ സ്റ്റേറ്റ്മെന്റുകൾ ആരെങ്കിലും സെർവർ ലോഗ് അയച്ച വരെ മാത്രമേ ഓഡിറ്റ് ചെയ്യപ്പെടൂ. ഗേറ്റ്വേ ഓഡിറ്റ് ട്രെയിലിനെ അതിന് ചുറ്റുമുള്ള ഒരു പ്രോസസ്സ് അല്ലാതെ പ്രവേശനത്തിന്റെ ഒരു ഗുണമാക്കി മാറ്റും.

ഒരു ഓഡിറ്റ് അഭ്യർത്ഥനയ്ക്ക് ഉത്തരം നൽകാൻ: ആ കാലയളവിലെ അനുമതികൾ പട്ടികപ്പെടുത്തൂ (Break-glass access), സ്റ്റേറ്റ്മെന്റുകൾക്കും ഓഡിറ്റ് എൻട്രി id-കൾക്കുമായി ഒരു അനുമതിയുടെ ചരിത്രം തുറക്കൂ, പ്ലാറ്റ്ഫോം ഓഡിറ്റ് ചെയിനിൽ ആ എൻട്രികൾ വായിക്കൂ (bun run audit:verify --platform ചെയിൻ അഴിഞ്ഞിട്ടില്ലെന്ന് തെളിയിക്കും).