---
title: "Pääavaimen ja allekirjoitusavaimen kierrätys sekä hätäkäyttö"
description: "Kierrätä tallennettuja tunnistetietoja suojaava pääavain ja käytä hätäkäyttöä."
image: "https://docs.quirelms.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.quirelms.com/fi/llms.txt
> Use this file to discover all available pages before exploring further.

# Pääavaimen ja allekirjoitusavaimen kierrätys sekä hätäkäyttö

<span id="master-key-and-signing-key-rotation-and-break-glass-access"></span>

Tässä ovat hallintakeinot, joita auditoija kyselee nimeltä tiedoston 21-compliance.md kohdassa 14. Tämä sivu kuvaa toimintaohjeen; sen tuottamat tietueet ovat todisteet.

## Avaimet <!--quire:the-keys-->

Jokainen tallennettu tunnistetieto salataan erillisellä satunnaisella tietojen salausavaimella (DEK). Pääavain (KEK) suojaa DEK:n, ja pääavaimen viite tallennetaan sen viereen (`key_ref` tai viite pakatun arvon sisällä). Pääavaimen kierrätys suojaa DEK:t uudelleen. Se ei koskaan pura eikä salaa tunnistetietoa uudelleen.

| Asetus | Merkitys |
| --- | --- |
| `QUIRE_MASTER_KEY` | Nykyinen pääavain: 32 tavua base64-muodossa. Jokainen uusi salaisuus suojataan sillä. |
| `QUIRE_MASTER_KEY_VERSION` | Avaimen versiotunniste. Oletus on `v1`. Kasvata sitä aina avainta vaihdettaessa. |
| `QUIRE_MASTER_KEY_RETIRED` | Aiemmat avaimet, joilla salaisuuksia voi olla suojattu; esimerkiksi `v1=<base64>,v0=<base64>`. Avaimia käytetään vain lukemiseen, niillä ei kirjoiteta. |

Verkkopalvelutaso, työntekijä ja `bun run kek:rotate`-komento lukevat samat kolme asetusta. Niiden arvojen on oltava kaikkialla samat. Muuten osa ei pysty avaamaan toisen suojaamia tietoja.

Jos `QUIRE_MASTER_KEY` puuttuu, kukin osa pitää käytössään `QUIRE_SECRET_KEY`-avaimesta johtamansa avaimen. Toiminto toimii, järjestelmän terveystilasivu näyttää sen heikentyneeksi ja tiedot pysyvät luettavina myös pääavaimen käyttöönoton jälkeen. Näin ne voidaan siirtää pois ensimmäisellä kierrätyksellä. Kuka tahansa prosessin ympäristöä lukeva voi purkaa kaikki tallennetut tunnistetiedot. Siksi tuotantoasennuksessa tulee käyttää salaisuussäilössä olevaa pääavainta, jota ei säilytetä samassa varmuuskopiossa tietokannan kanssa.

## Kierrätys <!--quire:rotating-->

Avaimen ikä näkyy alustan hallintapaneelissa kohdassa Security, Master key sekä mittarina `quire.secrets.master_key.age` (päiviä). Päivittäinen `platform.key_age`-ajastus (03.41 UTC) lisää muistutuksen alustan auditointiketjuun, kun avain on 365 päivän ikäinen, ja sen jälkeen 30 päivän välein, kunnes avain kierrätetään. Kierrätä muistutuksen tullessa ja aina, kun avain on voinut paljastua.

1. Luo uusi avain komennolla `openssl rand -base64 32`.
2. Aseta `QUIRE_MASTER_KEY` uudeksi avaimeksi ja `QUIRE_MASTER_KEY_VERSION` seuraavaksi tunnisteeksi (`v2`). Siirrä vanha avain asetukseen `QUIRE_MASTER_KEY_RETIRED` muodossa `v1=<old base64>`. Säilytä kopio molemmista avaimista muualla kuin tällä isännällä.
3. Ota verkkopalvelutaso ja työntekijä käyttöön uusilla asetuksilla. Uudet salaisuudet suojataan nyt avainviitteellä `env:QUIRE_MASTER_KEY:v2`; vanhat avataan edelleen käytöstä poistettavalla avaimella.
4. Pyydä kierrätystä ja anna auditointijälkeen tallennettava syy:
   - hallintapaneelissa: Security, Master key, Rotate the master key; tai
   - samalla ympäristöllä varustetussa komentotulkissa: `bun run kek:rotate request --reason "Annual rotation, ticket SEC-114"`.
5. Työntekijä suojaa minuutin välein osan tiedoista uudella avaimella (ajastuksella `platform.key_rotation`) ja jatkaa käynnistyksen jälkeen. Voit suorittaa kaiken yhdellä kertaa: `bun run kek:rotate run`. Seuraa edistymistä komennolla `bun run kek:rotate status`.
6. Kun tietueessa näkyy kierrätyksen valmistuneen ilman selvittämättömiä tai epäonnistuneita arvoja, poista vanha avain asetuksesta `QUIRE_MASTER_KEY_RETIRED` ja ota palvelut käyttöön uudelleen. Säilytä vanha avain siihen asti, koska siirtämättä jäänyt arvo on yhä suojattu sillä.

### Työn läpikäymät tallennuspaikat <!--quire:what-the-job-walks-->

Työ käsittelee kaikki suojattua DEK-avainta säilyttävät kohdat, jotka on lueteltu tiedostossa `SEALED_STORES` (`apps/worker/src/key-rotation.ts`). Ohjaustietokannan tiedot käsitellään siellä. Organisaatioiden tiedot käsitellään riviin kohdistuvan tietoturvan piirissä yksi organisaatio kerrallaan siinä tietokannassa, johon se kuuluu. Myös omaan tietokantaansa kiinnitetty vuokraaja kierrätetään omassa tietokannassaan. Testi epäonnistuu, jos skeemaan lisätään luettelosta puuttuva suojatun avaimen sarake. Toinen testi havaitsee tietoturvatarkastuksessa suojatuksi merkityn sarakkeen, joka puuttuu luettelosta.

### Tietueet <!--quire:the-record-->

- `ops.key_rotation`: yksi rivi kierrätystä kohden. Sisältää syyn, pyytäjän, tilan ja määrät (uudelleen suojatut, jo ajan tasalla olevat, selvittämättömät ja epäonnistuneet).
- `ops.key_rotation_progress`: yksi rivi tallennuspaikkaa ja laajuutta kohti käsittelyn jälkeen. Sisältää avainviitteet, joita ei voitu lukea, sekä niitä käyttävien arvojen määrän. Jatkettu kierrätys ohittaa nämä kohdat.
- Alustan auditointiketju: `platform/key_rotation_request` syineen, yksi `platform/key_rotation_store` tallennuspaikkaa kohden määrineen sekä `platform/key_rotation_complete` tai `platform/key_rotation_fail`. Muistutuksesta lisätään `platform/key_age_reminder`.
- Mittarit: `quire.secrets.master_key.age` ja `quire.secrets.rewrap.outstanding` (arvot, joita viimeisin kierrätys ei voinut siirtää).

### Selvittämättömät arvot <!--quire:when-values-are-unresolved-->

Arvoa ei voida selvittää, jos se on suojattu avainviitteellä, jota asennus ei tunne, tai sen muoto ei vastaa sarakkeen lupausta. Edistymistietue kertoo viitteen, esimerkiksi `env:QUIRE_MASTER_KEY:v0 (unreadable)`. Lisää kyseinen avain takaisin asetukseen `QUIRE_MASTER_KEY_RETIRED` ja käynnistä uusi kierrätys. Jos avain on lopullisesti kadonnut, pyydä organisaation ylläpitäjää antamaan tunnistetieto uudelleen. Se suojataan nykyisellä avaimella. Epäonnistuneiden kierrätysten virhe näytetään tietueessa; korjaa sen syy ja pyydä kierrätystä uudelleen.

## Allekirjoitusavaimet <!--quire:signing-keys-->

Jokainen organisaatio allekirjoittaa OpenID Connect -tokeninsa ja LTI-viestinsä omalla RSA-avaimellaan, joka julkaistaan osoitteessa `/.well-known/jwks.json`. Tämä ei vaadi ylläpitäjän toimia. Ajastus `platform.signing_keys` julkaisee seuraaja-avaimen tuntien välein seitsemän päivää ennen nykyisen 90 päivän käyttöajan loppua. Viikkoa myöhemmin uusi avain alkaa allekirjoittaa ja vanha siirtyy poistettavaksi. 90 päivän kuluttua vanha avain poistetaan ja lakkaa näkymästä avainjoukossa. Jokainen vaihe kirjataan alustan auditointiketjuun tunnisteella `platform/signing_key_advance`.

Jos organisaation avain on vaihdettava ennenaikaisesti esimerkiksi paljastumisen vuoksi:

- hallintapaneelissa: Security, Master key, Publish a new signing key (edellyttää oikeutta `platform/keys_manage`); tai
- työntekijän ympäristöllä varustetussa komentotulkissa: `bun run kek:rotate signing-keys rotate
  --tenant <slug or id> --reason "Key exposed, INC-3310"`. `bun run kek:rotate
  signing-keys status` luettelee kaikkien organisaatioiden avaimet vaiheittain.

Uusi avain julkaistaan heti ja se alkaa allekirjoittaa seitsemän päivän kuluttua, kun nykyinen avain poistuu käytöstä. Viikko annetaan tarkoituksella, sillä vastaanottavat järjestelmät tallentavat avainjoukon välimuistiin. Lyhyempi päällekkäisyys rikkoisi kaikkien välineiden toiminnan kerralla. Käytöstä poistuva avain pysyy joukossa vielä 90 päivää, jotta sillä allekirjoitettujen tokenien tarkistus onnistuu. Jos paljastuminen edellyttää luottamuksen päättämistä aiemmin, rivin poistaminen omalla tietokantayhteydellä on ylläpitäjän muutos, joka tehdään muutoslokin kanssa. Hätäkäyttö on vain lukua varten. Poistetulla avaimella allekirjoitetut tokenit eivät enää läpäise tarkistusta. Pakotettu kierrätys kirjataan syineen auditointiketjuun tunnisteella `platform/signing_key_rotate`. Uuden avaimen suojaamiseen työntekijä tarvitsee samat `QUIRE_MASTER_KEY`-asetukset kuin verkkopalvelutaso. Pääavaimen `bun run kek:rotate` suojaa myös allekirjoitusavaimet muiden tietojen mukana (`oauth_signing_key` kuuluu `SEALED_STORES`-luetteloon).

## Hätäkäyttö tuotannossa <!--quire:break-glass-production-access-->

Kukaan ei saa jatkuvaa tuotantokäyttöoikeutta. Jos asia ei voi odottaa, omistaja myöntää hätäkäyttöluvan kohdassa Platform console, Security, Break-glass access.

- Luvalla on laajuus (yksi organisaatio tai alustan rekisteri), vähintään 20 merkin syy, jossa nimetään häiriö tai tiketti, sekä 5–240 minuutin voimassaoloaika. Lupa vanhenee itsestään: sen voimassaolo tarkistetaan jokaisen käskyn yhteydessä.
- Luvan voi myöntää itselleen tai toiselle omistajalle kahden henkilön menettelyllä. Vain nimetty henkilö voi käyttää sitä. Myöntäminen edellyttää `platform/break_glass_issue`-oikeutta ja käyttäminen `platform/break_glass_use`-oikeutta. Oletuksena molemmat ovat vain omistajille.
- Käskyt suoritetaan yhdyskäytävän kautta, ei tietokantakirjautumisella. Käyttö on vain luku -muotoista, yksi käsky kerrallaan ja rajoitettu organisaatioon tai ohjausrekisteriin. Aikakatkaisu on viisi sekuntia ja tulos sisältää enintään 500 riviä. Binääriarvot näytetään kokonsa perusteella.
- Alustan auditointiketjuun kirjataan luvan myöntäminen syineen, sen peruminen, jokainen käsky ennen suoritusta (`platform/break_glass_statement`; hylätyillä tulos on `denied`) ja jokainen tulos (`platform/break_glass_result`). `ops.break_glass_statement` säilyttää auditointimerkintöjen tunnisteet, joiden avulla myöntämistietue yhdistetään auditointimerkintöihin.
- Kirjoitustoimintoja ei tarjota. Julkaisua odottamaton muutos tehdään tässä tuotteessa käytetyn hätäkäytön ulkopuolella ylläpitäjän omalla tietokantayhteydellä ja erillisellä muutoslokilla. Tietueessa tulee mainita sama häiriöviite kuin tässä.

Tietokantatunnistetietoja ei jaeta, koska Postgres-kirjautuminen säilyy istunnon päättymisen jälkeen, ohittaa sovelluksen käyttämän rivikohtaisen tietoturvan eikä voi kirjoittaa tuotteen auditointiketjuun. Sen käskyistä olisi loki ainoastaan, jos palvelinloki toimitettaisiin. Yhdyskäytävä tekee auditointijäljestä käyttöoikeuden ominaisuuden eikä sen ympärille muodostuvaa käytäntöä.

Auditointipyyntöön vastataan luettelemalla ajanjakson luvat (Break-glass access), avaamalla luvan historia käskyineen ja auditointitunnisteineen sekä tarkistamalla merkinnät alustan auditointiketjusta. Ketjun eheyden voi todistaa komennolla `bun run audit:verify --platform`.

Source: https://docs.quirelms.com/fi/ops/key-rotation/index.mdx
