---
title: "Gako nagusiaren eta sinadura-gakoaren biraketa, eta larrialdiko sarbidea"
description: "Biratu gordetako kredentzialak babesten dituen gako nagusia, eta erabili larrialdiko sarbidea."
image: "https://docs.quirelms.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://docs.quirelms.com/eu/llms.txt
> Use this file to discover all available pages before exploring further.
# Gako nagusiaren eta sinadura-gakoaren biraketa, eta larrialdiko sarbidea
Ikuskariek izenez eskatzen dituzten 21-compliance.md ataleko 14. ataleko kontrolak. Orrialde honek prozedura azaltzen du; sortzen dituen erregistroak dira frogak.
## Gakoak
Gordetako kredentzial bakoitza datuak zifratzeko gako fresko batekin (DEK) zigilatzen da. Gako nagusiak (KEK) DEKa inguratzen du, eta gako nagusiaren erreferentzia ondoan gordetzen da (`key_ref`, edo bildutako balioaren barruko erreferentzia). Gako nagusia biratzean DEKen bilgarriak berriro sortzen dira. Kredentzialak ez dira inoiz deszifratu edo berriro zifratzen.
| Ezarpena | Esanahia |
| --- | --- |
| `QUIRE_MASTER_KEY` | Uneko gako nagusia: 32 byte, base64. Sekretu berri bakoitza horrekin inguratzen da |
| `QUIRE_MASTER_KEY_VERSION` | Haren bertsio-etiketa. `v1` ezarrita ez dagoenean. Handitu gakoa aldatzen duzun bakoitzean |
| `QUIRE_MASTER_KEY_RETIRED` | Sekretuak gordeta eduki ditzaketen aurreko gakoak, `v1=,v0=` gisa. Irakurtzeko baino ez dira, ez idazteko |
Web-mailak, worker-ak eta `bun run kek:rotate` komandoak hiru ezarpen berberak irakurtzen dituzte. Guztiek balio berak izan behar dituzte, bestela batek ezin du besteak zigilatutakoa ireki.
`QUIRE_MASTER_KEY` ez badago, azpisistema bakoitzak `QUIRE_SECRET_KEY` aldagaitik eratorritako gakoa gordetzen du. Horrek funtzionatzen du, Sistemaren osasun-orriak egoera hondatu gisa erakusten du, eta gako nagusia ezarri ondoren ere irakurgai izaten jarraitzen du; lehen biraketan dena hortik kanpora eramateko modua da. Prozesuaren ingurunea irakur dezakeen edonork gordetako kredentzial guztiak deszifra ditzake; beraz, produkzioko instalazioak gako nagusia izan behar du, sekretu-biltegi batean gordeta eta datu-basearen babeskopia berean egon gabe.
## Biraketa
Gakoaren adina Plataforma kontsola, Segurtasuna, Gako nagusia atalean eta `quire.secrets.master_key.age` metrikan (egunak) erakusten da. Eguneroko `platform.key_age` programazioak (03:41 UTC) gogorarazpen bat idazten du plataformako auditoretza-katean gakoak 365 egun betetzean, eta ondoren 30 egunean behin biratu arte. Biratu gogorarazpena jasotzean, eta gakoa agerian geratu ahal izan denean ere.
1. Sortu gako berria: `openssl rand -base64 32`.
2. Ezarri `QUIRE_MASTER_KEY` gako berriaren balioarekin eta `QUIRE_MASTER_KEY_VERSION` hurrengo etiketarekin (`v2`). Eraman gako zaharra `QUIRE_MASTER_KEY_RETIRED` aldagaian, `v1=` gisa. Gorde bien kopia bat ostalari honetatik kanpo.
3. Zabaldu web-maila eta worker-a ezarpen berriekin. Hemendik aurrera, sekretu berriak `env:QUIRE_MASTER_KEY:v2` erabiliz inguratzen dira; zaharrak, berriz, erretiratutako gakoarekin irekitzen dira.
4. Eskatu biraketa, auditoretza-arrastoan agertuko den arrazoia emanez:
- kontsolan: Segurtasuna, Gako nagusia, Biratu gako nagusia; edo
- ingurune berarekin shell batean: `bun run kek:rotate request --reason "Annual rotation, ticket SEC-114"`.
5. Worker-ak zatia minutu bakoitzeko berriz inguratzen du (`platform.key_rotation` scheduler-aren programazioaren bidez), eta berrabiarazi ondoren jarraitzen du. Saio bakarrean amaitzeko: `bun run kek:rotate run`. Jarraitu egoera `bun run kek:rotate status` erabiliz.
6. Erregistroak biraketa amaitutzat eta **konpondu gabeko zero eta huts egindako zero** erakusten dituenean, kendu erretiratutako gakoa `QUIRE_MASTER_KEY_RETIRED` aldagaitik eta zabaldu berriro. Ordura arte, gorde: mugitu ezin izan duen balioa oraindik gako zaharrarekin dago inguratuta.
### Lanak zer aztertzen duen
DEK inguratua gordetzen duten biltegi guztiak: `SEALED_STORES` barrukoak (`apps/worker/src/key-rotation.ts`). Kontrol-datu-baseko biltegiak kontrol-datu-basean aztertzen dira; erakundeen biltegiak, berriz, erakunde bana eta errenkada-mailako segurtasunaren pean, erakundea dagoen datu-basean. Horrela, datu-base bereizi bati finkatutako maizter bat datu-base horretan bertan biratzen da. Proba batek huts egiten du eskemari gako-inguratuko zutabe bat gehitu baina zerrendan sartu ez bada; beste proba batek gauza bera egiten du kredentzial-berrikuspenak zutabe zigilatu bat sailkatu baina zerrendan ez badago.
### Erregistroa
- `ops.key_rotation`: biraketa bakoitzeko errenkada bat, arrazoia, eskaera egin duena, egoera eta guztizkoak jasotzeko (berriro inguratua, dagoeneko eguneratua, konpondu gabea, huts egina).
- `ops.key_rotation_progress`: aztertutako biltegi eta esparru bakoitzeko errenkada bat; irakurri ezin izan diren gako-erreferentziak eta bakoitzaren azpian zeuden balioen kopurua jasotzen ditu. Berrekin den biraketa batek horiek saltatzen ditu.
- Plataformako auditoretza-katea: `platform/key_rotation_request` (arrazoi eta guzti), biltegi bakoitzeko `platform/key_rotation_store` sarrera bat kopuruekin, eta `platform/key_rotation_complete` edo `platform/key_rotation_fail`; gogorarazpenerako, `platform/key_age_reminder`.
- Metrikak: `quire.secrets.master_key.age` eta `quire.secrets.rewrap.outstanding` (azken biraketak mugitu ezin izan zituen balioak).
### Balioak konpondu gabe daudenean
Konpondu gabeko balio bat instalazio honek ez duen gako-erreferentzia batekin inguratuta dago, edo zutabeak agintzen duen formatua ez du. Aurrerapen-erregistroak erreferentzia adierazten du (adibidez, `env:QUIRE_MASTER_KEY:v0 (unreadable)`). Berreskuratu gako hori `QUIRE_MASTER_KEY_RETIRED` aldagaian eta exekutatu beste biraketa bat; edo, gakoa betiko galdu bada, eskatu erakundearen administratzaileari kredentziala berriro sartzeko: oraingo gakoarekin zigilatuko da. Huts egindako biraketek errorea erakusten dute erregistroan; konpondu kausa eta eskatu berriro.
## Sinadura-gakoak
Gako nagusitik bereizita, erakunde bakoitzak bere OpenID Connect tokenak eta LTI mezuak sinatzen ditu RSA gakoarekin, `/.well-known/jwks.json` helbidean argitaratuta. Hemen ez du operadoreak ezer egin behar. Orduko `platform.signing_keys` programazioak ordezko gakoa argitaratzen du oraingoaren 90 egunak amaitu baino zazpi egun lehenago; astebete geroago ordezkoak sinatzen hasten da eta gako zaharra erretiratzen ari dela markatzen da; eta handik 90 egunera gako zaharra ezabatu eta gako-sortatik kentzen da. Urrats bakoitza `platform/signing_key_advance` sarrera gisa gehitzen da plataformako auditoretza-katean.
Erakunde baten gakoa aurrez ordezkatzeko, adibidez agerian geratu delako:
- kontsolan: Segurtasuna, Gako nagusia, Argitaratu sinadura-gako berria (`platform/keys_manage` baimena behar du); edo
- worker-aren ingurunea duen shell batean: `bun run kek:rotate signing-keys rotate
--tenant --reason "Key exposed, INC-3310"`. `bun run kek:rotate
signing-keys status` komandoak erakunde guztietako gakoen fasea zerrendatzen du.
Gako berria berehala argitaratzen da, eta zazpi egunen buruan hasten da sinatzen, oraingoa erretiratzen denean. Astebeteko tartea nahita ezarri da: alderdi fidagarriek gako-sorta cacheatzen dute, eta gainjartze laburragoak tresna guztiak batera hondatuko lituzke. Erretiratutako gakoak beste 90 egunez jarraitzen du gako-sortan, lehendik sinatutako tokenak egiaztatzen jarrai dezaten. Agerian geratu izanak lehenago fidagarri izateari utzi behar diola esan nahi badu, gakoaren errenkada ezabatzea operadorearen datu-baseko sarbide propioarekin egiten den aldaketa da, aldaketa-erregistro baten pean (larrialdiko sarbidea irakurtzeko soilik da); orduan, harekin sinatutako tokenek ez dute egiaztapena gaindituko. Behartutako biraketa `platform/signing_key_rotate` gisa erregistratzen da auditoretza-katean, arrazoi eta guzti. Worker-ak web-mailaren `QUIRE_MASTER_KEY` ezarpen berak behar ditu gako berria inguratzeko; gako nagusirako `bun run kek:rotate` komandoak sinadura-gakoak ere berriz inguratzen ditu (`oauth_signing_key` `SEALED_STORES` barruan dago).
## Produkziorako larrialdiko sarbidea
Inork ez du produkziorako sarbide iraunkorrik. Zerbait itxaron ezin denean, jabe batek larrialdiko baimen bat ematen du: Plataforma kontsola, Segurtasuna, Larrialdiko sarbidea.
- Baimenak esparrua du (erakunde bakarra edo plataforma-erregistroa), gertakaria edo txartela izendatzen duen gutxienez 20 karaktereko arrazoia, eta 5 eta 240 minutu arteko iraupena. Berez iraungitzen da: instrukzio bakoitzean erlojuarekin alderatzen da.
- Baimena eman dion jabeari edo beste jabe bati eman dakioke (bi pertsonako modua). Baimena jaso duenak soilik erabil dezake. Emateko `platform/break_glass_issue` behar da, erabiltzeko `platform/break_glass_use`; biak jabeentzat soilik dira lehenespenez.
- Instrukzioak atebidetik exekutatzen dira, ez datu-baseko saio-hasiera bidez: irakurtzeko soilik, banan-banan, erakundera edo kontrol-erregistrora mugatuta, bost segundoko denbora-mugarekin eta gehienez 500 errenkadarekin. Datu bitarrak tamainaren bidez erakusten dira.
- Plataformako auditoretza-kateak baimenaren ematea (arrazoiarekin), baliogabetzea, exekutatu aurreko instrukzio bakoitza (`platform/break_glass_statement`, ukatutakoak `denied` emaitzarekin) eta emaitza bakoitza (`platform/break_glass_result`) erregistratzen ditu. `ops.break_glass_statement` taulak auditoretza-sarreren IDak ditu, emate-erregistroa dagozkion auditoretza-sarrerekin lotzeko.
- Idazteko aukerarik ez dago. Bertsiorik itxaron ezin duen aldaketa bat operadoreak datu-basean duen sarbide propioarekin egiten da, bere aldaketa-erregistroaren pean eta produktu honetatik kanpo; erregistroak hemen erabilitako gorabehera-erreferentzia aipatu behar du.
Zergatik ez eman datu-baseko kredentzialik? Postgres saio-hasiera erabiltzeko eskatu zuen saioa amaitu ondoren ere erabil daiteke; aplikazioak darabilen errenkada-mailako segurtasuna saihesten du; eta ezin du produktu honen auditoretza-katean idatzi. Hortaz, haren instrukzioak zerbitzari-erregistroa argitaratu arte baino ez lirateke ikuskatuko. Ategibideari esker, auditoretza-arrastoa sarbidearen berezko ezaugarria da, haren inguruko ohitura bat baino gehiago.
Auditoretza-eskaera bati erantzuteko: zerrendatu aldiko baimenak (Larrialdiko sarbidea), ireki baimen baten historia haren instrukzioak eta auditoretza-sarreren IDak ikusteko, eta irakurri sarrera horiek plataformako auditoretza-katean (`bun run audit:verify --platform` komandoak katea osorik dagoela frogatzen du).
Source: https://docs.quirelms.com/eu/ops/key-rotation/index.mdx