მასტერ გასაღებისა და ხელმოწერის გასაღების როტაცია და საგანგებო წვდომა

კონტროლები 21-compliance.md მე-14 სექციაში, რომლებსაც აუდიტორი სახელით ითხოვს. ეს გვერდი პროცედურაა; ჩანაწერები, რომლებსაც ის ქმნის, მტკიცებულებაა.

გასაღებები

ყოველი შენახული რწმუნებათა სიგელი ილუქება ახალი მონაცემთა დაშიფვრის გასაღებით (DEK). DEK იხვევა მასტერ გასაღებით (KEK), ხოლო მასტერ გასაღების მითითება ინახება მის გვერდით (key_ref ან მითითება შეფუთულ მნიშვნელობაში). მასტერ გასაღების როტაცია ხელახლა ხვევს DEK-ებს. ის არასდროს შიფრავს ან ხელახლა შიფრავს რწმუნებათა სიგელს.

ვებ-დონე, worker-ი და bun run kek:rotate ბრძანება კითხულობენ იმავე სამ პარამეტრს. ყველას ერთი და იგივე მნიშვნელობები უნდა ჰქონდეს, თორემ ერთ-ერთი ვერ გახსნის იმას, რაც მეორემ დალუქა.

QUIRE_MASTER_KEY-ის გარეშე ყოველი ქვესისტემა ინახავს გასაღებს, რომელსაც ის იღებს QUIRE_SECRET_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. გაშალეთ ვებ-დონე და worker-ი ახალი პარამეტრებით. ახალი საიდუმლოებები ახლა იხვევა env:QUIRE_MASTER_KEY:v2-ის ქვეშ; ძველები კვლავ იხსნება საპენსიო გასაღებით.
4. მოითხოვეთ როტაცია მიზეზით, რომელიც აუდიტის კვალში დარჩება:
   • კონსოლში: უსაფრთხოება, მასტერ გასაღები, მასტერ გასაღების როტაცია; ან
   • გარსში იგივე გარემოთი: bun run kek:rotate request --reason "Annual rotation, ticket SEC-114".
5. worker-ი ხელახლა ხვევს ნაჭერს წუთში (განრიგის 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 ტოკენებს და LTI შეტყობინებებს საკუთარი RSA გასაღებით, გამოქვეყნებული /.well-known/jwks.json-ში. აქ ოპერატორი არაფერს საჭიროებს. საათობრივი platform.signing_keys განრიგი აქვეყნებს მემკვიდრეს ამჟამინდელი გასაღების ოთხმოცდაათის ამოწურვამდე შვიდი დღით ადრე, კვირის შემდეგ მემკვიდრე იწყებს ხელმოწერას და ძველი გასაღები საპენსიო ხდება, ხოლო ოთხმოცდაათი დღის შემდეგ ძველი გასაღები იშლება და ტოვებს გასაღებების ნაკრებს. ყოველი ნაბიჯი platform/signing_key_advance ჩანაწერია პლატფორმის აუდიტის ჯაჭვში.

ორგანიზაციის გასაღების ადრე შესაცვლელად, მაგალითად გამჟღავნების შემდეგ:

• კონსოლში: უსაფრთხოება, მასტერ გასაღები, ახალი ხელმოწერის გასაღების გამოქვეყნება (საჭიროებს platform/keys_manage-ს); ან
• გარსში worker-ის გარემოთი: 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, მიზეზით. worker-ს სჭირდება იგივე QUIRE_MASTER_KEY პარამეტრები, რაც ვებ-დონეს, ახალი გასაღების შესახვევად; bun run kek:rotate მასტერ გასაღებისთვის ხელახლა ხვევს ხელმოწერის გასაღებებს ყველა დანარჩენთან ერთად (oauth_signing_key არის SEALED_STORES-ში).

საგანგებო საწარმოო წვდომა

არავის აქვს მუდმივი წვდომა საწარმოოზე. როცა რაღაც ვერ იცდის, მფლობელი გასცემს საგანგებო ნებართვას: პლატფორმის კონსოლი, უსაფრთხოება, საგანგებო წვდომა.

• ნებართვას აქვს არეალი (ერთი ორგანიზაცია ან პლატფორმის რეესტრი), მიზეზი მინიმუმ 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 შესვლა აღემატება სესიას, რომელმაც ის ითხოვა, გვერდს უვლის სტრიქონის დონის უსაფრთხოებას, რომელსაც აპლიკაცია ეყრდნობა, და ვერ წერს ამ პროდუქტის აუდიტის ჯაჭვში, ასე რომ მისი განცხადებები აუდიტირებული იქნებოდა მხოლოდ იქამდე, რამდენადაც ვიღაცამ სერვერის ჟურნალი გაგზავნა. კარიბჭე აუდიტის კვალს წვდომის თვისებად აქცევს და არა მის გარშემო პრაქტიკად.

აუდიტის მოთხოვნაზე საპასუხოდ: ჩამოთვალეთ ნებართვები პერიოდში (საგანგებო წვდომა), გახსენით ნებართვის ისტორია მისი განცხადებებისა და აუდიტის ჩანაწერის id-ებისთვის და წაიკითხეთ ის ჩანაწერები პლატფორმის აუდიტის ჯაჭვში (bun run audit:verify --platform ამტკიცებს, რომ ჯაჭვი ხელუხლებელია).