Ubicazioni, tenancy e disponibilità

Key Protect è un servizio regionale a più tenant.

Puoi creare risorse Key Protect in una delle regioni IBM Cloud supportate, che rappresentano l'area geografica in cui vengono gestite ed elaborate le tue richieste Key Protect. Ogni regione IBM Cloud contiene più zone di disponibilità per soddisfare i requisiti di accesso locale, bassa latenza e sicurezza della regione.

Ci sono tre regioni, us-south (situata a Dallas, Texas, Stati Uniti), jp-tok (situata a Tokyo, Giappone) e eu-de (situata a Francoforte, Germania) in cui Key Protect ha il supporto di failover in una regione separata in cui i dati vengono replicati in un'infrastruttura di standby se si seleziona il piano tariffario Cross-region resiliency. I dati della regione dell' us-south o sono replicati nella regione dell' us-east o (situata a Washington DC, Stati Uniti), i dati della regione dell' jp-tok o sono replicati nella regione dell' jp-osa o (situata a Osaka, Giappone) e i dati della regione dell' eu-de o sono replicati in un centro dati nella regione di Parigi. Ciò significa che se il servizio in us-south, jp-tok o eu-de viene interrotto, le richieste a Key Protect in quelle regioni vengono instradate verso la regione in cui i dati sono già stati replicati.

Si noti che l'infrastruttura di standby nella regione con supporto failover è completamente separata dal servizio di Key Protect disponibile in quella regione, e che il failover va solo in una direzione e in modo attivo-passivo, dove i server nella regione trasversale elaborano le richieste solo se la regione principale è inattiva. I tuoi dati in us-east, ad esempio, non sono attualmente replicati in us-south.

Il punto di obiettivo di recupero (RPO) e il tempo di obiettivo di recupero (RTO) per l' Key Protect, sono rispettivamente inferiori a un'ora e inferiori a nove ore (per un guasto regionale).

Poiché le richieste vengono instradate automaticamente, è possibile continuare a richiamare l'endpoint originale. Inizialmente, le operazioni di sola lettura sono tutte disponibili. Tuttavia, se c'è motivo di ritenere che l'interruzione durerà per un periodo prolungato, le operazioni di scrittura saranno abilitate il più presto possibile. In caso contrario, le operazioni di sola lettura sono le uniche disponibili per un massimo di sei ore prima che vengano abilitate le operazioni di scrittura.

Quando si pianifica la propria strategia di crittografia con IBM Cloud, si ricorda che il provisioning di Key Protect in una regione più vicina all'utente ha maggiori probabilità di ottenere connessioni più veloci e affidabili quando si interagisce con le API Key Protect. Inoltre, i requisiti normativi potrebbero influenzare la regione o le regioni da utilizzare. Nota che Key Protect non limita l'utilizzo delle chiavi tra le regioni e le ubicazioni geografiche. Ad esempio, un utente potrebbe utilizzare le chiavi da us-south per crittografare l'archiviazione a Francoforte. Scegli la regione migliore per il tuo caso di utilizzo in generale.

Alta disponibilità a livello di applicazione

Se importi una chiave root in Key Protect, ti invitiamo a mantenere un backup sicuro del materiale della chiave in modo da poter ripristinare la chiave root se viene accidentalmente eliminata e il periodo di tolleranza di 30 giorni per ripristinare una chiave eliminata è scaduto. In altre parole, entro 30 giorni, Key Protect consente ai clienti di ripristinare una chiave eliminata senza dover utilizzare un backup.

Poiché due chiavi create utilizzando lo stesso materiale della chiave sono effettivamente identiche (entrambe possono spacchettare tutte le chiavi di crittografia dei dati (DEK) create da entrambe le chiavi root), è possibile eseguire in modo sicuro il backup delle tue chiavi root creando una chiave duplicata per ogni chiave root importata all'interno della tua istanza. Ogni chiave duplicata deve essere creata in una regione Key Protect diversa dalla chiave originale, il che significa che l' key_id e l'ID istanza servizio delle chiavi saranno diversi. La tua applicazione sarà quindi in grado di utilizzare entrambe le chiavi purché conosca gli ID e gli endpoint rilevanti di entrambe le chiavi.

Nota che ogni volta che una chiave root viene ruotata, viene aggiunto nuovo materiale della chiave, che crea una nuova versione della chiave. Pertanto, assicurarsi di utilizzare questo materiale chiave aggiornato quando si ruotano le chiavi duplicate.

Le applicazioni che comunicano attraverso le reti sono soggette a errori transitori. Dovresti progettare la tua applicazione per interagire con Key Protect utilizzando le moderne tecniche di resilienza, ad esempio un backoff esponenziale che ritenta le richieste con ritardi in aumento esponenziale tra ciascuna richiesta.

const maxRetries = 3
attempt := 1
delay := time.Second * 1
var ok bool
for !ok && attempt <= maxRetries {
    ok = makeRequest()
    if !ok {
        time.Sleep(delay)
        delay = delay * 2
        attempt += 1
    }
}

Ripristino di emergenza

Key Protect segue i requisiti IBM Cloud per la pianificazione e il ripristino da eventi di emergenza.

Le impostazioni dell'endpoint privato, in particolare l'indirizzo IP ( Internet Protocol ), potrebbero dover essere aggiornate manualmente durante le azioni di ripristino di emergenza e di continuità aziendale.

Per ulteriori informazioni sulle responsabilità che tu e IBM condividi nella manutenzione delle tue chiavi e dei tuoi carichi di lavoro, vedi Descrizione delle tue responsabilità con l'utilizzo di Key Protect.