ការបង្វិលសោ master និងសោហត្ថលេខា និងការចូលប្រើបំពេញអាសន្ន

ការគ្រប់គ្រងក្នុង 21-compliance.md ផ្នែក 14 ដែលអ្នកសវនកម្មសុំតាមឈ្មោះ។ ទំព័រនេះជាដំណើរការ។ កំណត់ត្រាដែលវាផលិតជាភស្តុតាង។

សោទាំងនេះ

លិខិតសម្គាល់ដែលបានរក្សាទុកនីមួយៗត្រូវបានបិទភ្ជិតជាមួយសោអ៊ីនគ្រីបទិន្នន័យថ្មី (DEK)។ DEK ត្រូវបានរុំដោយសោ master (KEK) ហើយយោងនៃសោ master ត្រូវបានរក្សាទុកនៅជាប់វា (key_ref ឬយោងខាងក្នុងតម្លៃដែលបានផ្គរ)។ ការបង្វិលសោ master រុំ DEK ឡើងវិញ។ វាមិនដែលឌិគ្រីប ឬអ៊ីនគ្រីបលិខិតសម្គាល់ឡើងវិញទេ។

ស្រទាប់ web worker និងពាក្យបញ្ជា bun run kek:rotate អានការកំណត់ទាំងបីដដែល។ ពួកគេត្រូវតែមានតម្លៃដដែលទាំងអស់ ឬមួយក្នុងចំណោមពួកគេមិនអាចបើកអ្វីដែលមួយផ្សេងបានបិទភ្ជិត។

គ្មាន QUIRE_MASTER_KEY ប្រព័ន្ធផ្សេងៗនីមួយៗរក្សាសោដែលវាបង្កើតពី QUIRE_SECRET_KEY។ នេះដំណើរការ។ ទំព័រសុខភាពប្រព័ន្ធបង្ហាញវាជាថយចុះ ហើយវានៅតែអាចអានបានបន្ទាប់ពីអ្នកកំណត់សោ master ដែលជារបៀបដែលការបង្វិលដំបូងផ្លាស់ប្តូរអ្វីៗចេញពីវា។ អ្នកណាដែលអាចអានបរិស្ថានដំណើរការអាចឌិគ្រីបលិខិតសម្គាល់ដែលបានរក្សាទុកទាំងអស់ ដូច្នេះការដំឡើងផលិតគួរតែមានសោ master ដែលរក្សាក្នុងហាងសំណង់ ហើយមិននៅក្នុងការបម្រុងទុកដដែលជាមួយមូលដ្ឋានទិន្នន័យ។

ការបង្វិល

អាយុសោបង្ហាញលើ 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. ដាក់ស្តារស្រទាប់ web និង worker ជាមួយការកំណត់ថ្មី។ សំណង់ថ្មីឥឡូវនេះត្រូវបានរុំក្រោម env:QUIRE_MASTER_KEY:v2។ ចាស់ៗនៅតែបើកតាមសោដែលបានដក។
4. សុំការបង្វិល ជាមួយមូលហេតុដែលនឹងស្ថិតក្នុងផ្លូវសវនកម្ម៖
   • ក្នុងកុងសូល៖ 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 និង zero failed យកសោដែលបានដកចេញពី QUIRE_MASTER_KEY_RETIRED ហើយដាក់ស្តារឡើងវិញ។ រហូតដល់ពេលនោះរក្សាវា៖ តម្លៃដែលវាមិនអាចផ្លាស់ទីបាននៅតែរុំក្រោមសោចាស់។

អ្វីដែលការងារដើរ

ឃ្លាំងទាំងអស់ដែលកាន់ DEK ដែលបានរុំ៖ ទាំងនោះក្នុង SEALED_STORES (apps/worker/src/key-rotation.ts)។ ឃ្លាំងមូលដ្ឋានទិន្នន័យត្រួតពិនិត្យដើរលើមូលដ្ឋានទិន្នន័យត្រួតពិនិត្យ។ ឃ្លាំងអង្គការដើរមួយអង្គការម្តងក្រោមសុវត្ថិភាពជួរដេក ក្នុងមូលដ្ឋានទិន្នន័យណាដែលកាន់អង្គការនោះ ដូច្នេះ tenant ដែលខ្ទាស់ទៅមូលដ្ឋានទិន្នន័យលាក់ត្រូវបានបង្វិលក្នុងមូលដ្ឋានទិន្នន័យនោះ។ ការសាកល្បងបរាជ័យនៅពេល schema ទទួលជួរសោដែលបានរុំដែលបញ្ជីមិនដាក់ឈ្មោះ ហើយមួយទៀតនៅពេលការត្រួតពិនិត្យលិខិតសម្គាល់ចាត់ថ្នាក់ជួរដែលបានបិទភ្ជិតដែលបញ្ជីខក។

កំណត់ត្រា

• 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 ហើយដំណើរការការបង្វិលមួយទៀត ឬបើសោបាត់ជានិច្ច ឱ្យអ្នកគ្រប់គ្រងនៃអង្គការនោះបញ្ចូលលិខិតសម្គាល់ម្តងទៀត៖ វាត្រូវបានបិទភ្ជិតក្រោមសោបច្ចុប្បន្ន។ ការបង្វិលដែលបរាជ័យបង្ហាញកំហុសរបស់ពួកវាលើកំណត់ត្រា។ កែមូលហេតុ ហើយសុំម្តងទៀត។

សោហត្ថលេខា

ដាច់ពីសោ master៖ អង្គការនីមួយៗហត្ថលេខាថូខេន OpenID Connect និងសារ LTI របស់វាជាមួយសោ RSA ផ្ទាល់ ដែលបានផ្សាយនៅ /.well-known/jwks.json។ គ្មានអ្វីនៅទីនេះត្រូវការអ្នកប្រតិបត្តិករទេ។ កាលវិភាគរាល់ម៉ោង platform.signing_keys ផ្សាយអ្នកបន្តបួនថ្ងៃមុននឹងសោបច្ចុប្បន្ន 90 ថ្ងៃរបស់វាអស់។ មួយសប្តាហ៍ក្រោយមកអ្នកបន្តចាប់ផ្តើមហត្ថលេខា ហើយសោចាស់ក្លាយជាកំពុងដក។ 90 ថ្ងៃបន្ទាប់មកសោចាស់ត្រូវបានលុប ហើយចេញពីបញ្ជីសោ។ ជំហាននីមួយៗជាធាតុ platform/signing_key_advance លើខ្សែសវនកម្មប្រព័ន្ធ។

ដើម្បីជំនួសសោរបស់អង្គការមួយមុនពេល ឧទាហរណ៍បន្ទាប់ពីការប៉ះពាល់៖

• ក្នុងកុងសូល៖ 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 រាយសោរបស់អង្គការនីមួយៗតាមដំណាក់ការ។

សោថ្មីត្រូវបានផ្សាយភ្លាមៗ ហើយចាប់ផ្តើមហត្ថលេខាបន្ទាប់ពីបួនថ្ងៃ នៅពេលសោបច្ចុប្បន្នដក។ សប្តាហ៍នេះត្រូវបានគិតពិចារណា៖ ភាគីដែលពឹងផ្អែកផ្ទុកបញ្ជីសោ ហើយគម្លាតខ្លីជាងបរាជ័យឧបករណ៍ទាំងអស់ក្នុងពេលតែមួយ។ សោដែលកំពុងដកនៅតែស្ថិតក្នុងបញ្ជីសោ 90 ថ្ងៃបន្ថែមទៀត ដូច្នេះថូខេនដែលវាបានហត្ថលេខារួចនៅតែផ្ទៀងផ្ទាត់បាន។ បើការប៉ះពាល់មានន័យថាវាត្រូវឈប់ទទួលទុកចិត្តមុនពេល ការលុបជួររបស់វាជាការផ្លាស់ប្តូរដែលបានធ្វើជាមួយការចូលដំណើរការមូលដ្ឋានទិន្នន័យផ្ទាល់របស់អ្នកប្រតិបត្តិករក្រោមកំណត់ត្រាផ្លាស់ប្តូរ (ការចូលប្រើបំពេញអាសន្នតែអាន) ហើយថូខេនដែលបានហត្ថលេខាជាមួយវាបន្ទាប់មកបរាជ័យការផ្ទៀងផ្ទាត់។ ការបង្វិលដែលត្រូវបានបង្ខំជា platform/signing_key_rotate ក្នុងខ្សែសវនកម្ម ជាមួយមូលហេតុ។ worker ត្រូវការការកំណត់ QUIRE_MASTER_KEY ដដែលជាមួយស្រទាប់ web ដើម្បីរុំសោថ្មី។ bun run kek:rotate សម្រាប់សោ master រុំសោហត្ថលេខាឡើងវិញជាមួយអ្វីៗផ្សេងទាំងអស់ (oauth_signing_key ស្ថិតក្នុង SEALED_STORES)។

ការចូលផលិតបំពេញអាសន្ន

គ្មានអ្នកណាកាន់ការចូលអចិន្រ្តៃយ៍ទៅកាន់ផលិតទេ។ នៅពេលមានអ្វីមិនអាចរង់ចាំបាន ម្ចាស់មួយរូបចេញការអនុញ្ញាតបំពេញអាសន្ន៖ Platform console, Security, Break-glass access។

• ការអនុញ្ញាតមានវិស័យ (អង្គការមួយ ឬបញ្ជីប្រព័ន្ធ) មូលហេតុយ៉ាងតិច 20 តួអក្សរដែលដាក់ឈ្មោះហេតុការណ៍ ឬសំណើ និងបង្អួចពី 5 ដល់ 240 នាទី។ វាផុតកំណត់ដោយខ្លួនឯង៖ វាត្រូវបានពិនិត្យប្រឆាំងនឹងនាឡិកាលើសេចក្តីថ្លែងនីមួយៗ។
• វាអាចត្រូវបានចេញឱ្យម្ចាស់ដែលចេញវា ឬឱ្យម្ចាស់ផ្សេង (ទម្រង់ពីរនាក់)។ តែមនុស្សដែលវាត្រូវបានចេញឱ្យប៉ុណ្ណោះអាចប្រើវា។ ការចេញត្រូវការ platform/break_glass_issue ហើយការប្រើត្រូវការ platform/break_glass_use។ ទាំងពីរជាម្ចាស់តែប៉ុណ្ណោះតាមលំនាំដើម។
• សេចក្តីថ្លែងដំណើរការតាម gateway មិនមែនលើការចូលមូលដ្ឋានទិន្នន័យទេ៖ តែអាន មួយក្នុងពេលតែមួយ កំណត់ទៅអង្គការ ឬបញ្ជីត្រួតពិនិត្យ ជាមួយការផុតកំណត់ប្រាំវិនាទី និងយ៉ាងច្រើន 500 ជួរ។ តម្លៃ Binary ត្រូវបានបង្ហាញតាមទំហំ។
• ខ្សែសវនកម្មប្រព័ន្ធកត់ត្រាការចេញ (ជាមួយមូលហេតុ) ការដក សេចក្តីថ្លែងនីមួយៗមុនវាដំណើរការ (platform/break_glass_statement ដែលបដិសេធជាមួយលទ្ធផល denied) និងលទ្ធផលនីមួយៗ (platform/break_glass_result)។ ops.break_glass_statement កាន់ id ធាតុសវនកម្ម ដូច្នេះកំណត់ត្រាការចេញភ្ជាប់ទៅធាតុសវនកម្មរបស់វា។
• ការសរសេរមិនត្រូវបានផ្តល់ទេ។ ការផ្លាស់ប្តូរដែលមិនអាចរង់ចាំកំណែប្រើការចូលមូលដ្ឋានទិន្នន័យផ្ទាល់របស់អ្នកប្រតិបត្តិករក្រោមកំណត់ត្រាផ្លាស់ប្តូរផ្ទាល់របស់វា ក្រៅផលិតផលនេះ ហើយកំណត់ត្រាគួរតែយោងលេខសំគាល់ហេតុការណ៍ដែលបានប្រើនៅទីនេះ។

ហេតុអ្វីមិនចេញលិខិតសម្គាល់មូលដ្ឋានទិន្ន័យ៖ ការចូល Postgres នៅសល់អាយុជាង session ដែលសុំវា កំណត់ផ្លូវសុវត្ថិភាពជួរដេកដែលកម្មវិធីពឹងផ្អែក ហើយមិនអាចសរសេរទៅខ្សែសវនកម្មនៃផលិតផលនេះបានទេ ដូច្នេះសេចក្តីថ្លែងរបស់វានឹងត្រូវបានសវនកម្មតែដល់អ្នកណាបានផ្ញើកំណត់ត្រាម៉ាស៊ីនបម្រើប៉ុណ្ណោះ។ gateway ធ្វើឱ្យផ្លូវសវនកម្មជាគុណសមត្ថិភាពនៃការចូល ជំនួសការអនុវត្តជុំវិញវា។

ដើម្បីឆ្លើយសំណើសវនកម្ម៖ រាយការអនុញ្ញាតក្នុងរយៈពេល (Break-glass access) បើកប្រវត្តិនៃការអនុញ្ញាតមួយសម្រាប់សេចក្តីថ្លែង និង id ធាតុសវនកម្ម ហើយអានធាតុទាំងនោះលើខ្សែសវនកម្មប្រព័ន្ធ (bun run audit:verify --platform បញ្ជាក់ថាខ្សែនៅតែគង់វង់)។