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.

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=<old base64> 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 <slug or id> --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).