--- title: Rotazione delle chiavi icon: rotate --- Twenty ha due famiglie di chiavi indipendenti: * **Chiavi di firma JWT** — coppie di chiavi asimmetriche ES256 (con tag `kid`) archiviate in `core."signingKey"`, utilizzate per firmare e verificare i token di accesso / aggiornamento. * **Chiave di crittografia a riposo** — `ENCRYPTION_KEY`, utilizzata per crittografare token OAuth, variabili dell'applicazione, chiavi private delle chiavi di firma, valori di configurazione sensibili e segreti TOTP all'interno di un involucro `enc:v2:`. `APP_SECRET` è un segreto legacy mantenuto per compatibilità con le versioni precedenti: quando `ENCRYPTION_KEY` non è impostata funge da fallback per la crittografia a riposo / cookie di sessione e continua a verificare i token di accesso HS256 preesistenti. Sarà deprecata. ## Chiavi di firma JWT Ogni chiave contiene una `publicKey` (mantenuta indefinitamente così da poter verificare i token emessi in precedenza), una `privateKey` crittografata (utilizzata solo mentre la chiave è quella corrente), un flag `isCurrent` (esattamente una riga alla volta) e un campo `revokedAt` opzionale. ### Ruotare la chiave corrente Imposta `SIGNING_KEY_ROTATION_DAYS` per aderire: un cron giornaliero emette quindi una nuova chiave corrente quando quella esistente è più vecchia di tale soglia. Le chiavi precedenti *non* vengono revocate, quindi i token firmati con esse continuano a essere verificati. Lascia la variabile non impostata per disattivare la rotazione automatica. La rotazione automatica è disponibile a partire dalla versione v2.6+. ### Revocare una chiave (solo in caso di fuga di dati / emergenza) **Settings → Admin Panel → Signing keys → Revoke** su una riga non corrente. Cancella il materiale privato crittografato, imposta `revokedAt` e rifiuta ogni token esistente firmato con quel `kid`. ## Ruotare `ENCRYPTION_KEY` Il comando `secret-encryption:rotate` descritto di seguito è disponibile dalla v2.6+. Ogni valore crittografato è incapsulato come `enc:v2:\:\`, dove `\` è un prefisso esadecimale a 8 caratteri derivato dalla chiave grezza. La rotazione è online e riprendibile. 1. **Generare una nuova chiave**: `openssl rand -base64 32`. 2. **Configurare entrambe le chiavi affiancate** in `.env`, quindi riavviare: ```ini ENCRYPTION_KEY=NEW_VALUE FALLBACK_ENCRYPTION_KEY=OLD_VALUE ``` Le nuove scritture usano la nuova chiave, le righe esistenti vengono ancora decrittate tramite il fallback. 3. **Ricrittografare le righe esistenti**: ```bash docker exec -it {server_container} yarn command:prod secret-encryption:rotate ``` Il comando passa in rassegna sei sezioni (`connected-account-tokens`, `application-variable`, `application-registration-variable`, `signing-key-private-keys`, `sensitive-config-storage`, `totp-secrets`). Un filtro SQL salta le righe già con il nuovo `\`, quindi il comando è idempotente: interrompi e riesegui secondo necessità. Esce con codice diverso da zero se una qualsiasi riga fallisce — riesegui per riprovare. | Opzione | Descrizione | | ---------------------------------------- | ----------------------------------------------------------- | | `-s, --site \` | Limita a un singolo sito. | | `-b, --batch-size \` | Righe per batch (predefinito `200`, massimo `5000`). | | `-d, --dry-run` | Decrittografa + ricrittografa in memoria, salta l'`UPDATE`. | 4. **Eliminare il fallback** una volta che `--dry-run` mostra zero righe rimanenti: rimuovere `FALLBACK_ENCRYPTION_KEY` e riavviare. ## Supporto legacy per `APP_SECRET` Le istanze meno recenti che non hanno mai impostato `ENCRYPTION_KEY` usano `APP_SECRET` come chiave di crittografia a riposo (e come segreto del cookie di sessione, derivato da essa). Questo percorso è mantenuto per compatibilità con le versioni precedenti ma è **deprecato** — imposta una `ENCRYPTION_KEY` dedicata e segui la procedura di rotazione sopra per migrare. `APP_SECRET` continua a essere utilizzata per verificare i token di accesso HS256 legacy.