diff --git a/pages/manage_and_operate/kms/architecture-overview/guide.de-de.md b/pages/manage_and_operate/kms/architecture-overview/guide.de-de.md index fa2bf1129e3..3e358c4491f 100644 --- a/pages/manage_and_operate/kms/architecture-overview/guide.de-de.md +++ b/pages/manage_and_operate/kms/architecture-overview/guide.de-de.md @@ -1,7 +1,7 @@ --- title: "OKMS Architecture overview" excerpt: "Discover how we handle the security of the OKMS infrastructure" -updated: 2025-10-21 +updated: 2025-10-24 --- ## Objective @@ -10,7 +10,7 @@ This guide explains how we handle the resilience of the OKMS infrastructure used ## Instructions -The OKMS architecture has 3 main objectives: +The OKMS architecture has three main objectives: - **Confidentiality**: Assure that no one except you can access your key. - **Availability**: Offering a high level of resilience and therefore high availability. @@ -23,11 +23,23 @@ Only the users allowed by an IAM policy can manage the keys or use them to encry Even the OVHcloud employees cannot access your keys. -### KMS architecture +### OKMS architecture -The OKMS infrastructure is by design replicated across multiple datacenters. +Each OKMS region is fully independent from the others and uses dedicated hosts. -![Architecture overview](images/KMS_Overview.png){.thumbnail} +#### 1-AZ regions + +The architecture of a single-AZ region is based on two zones located in distinct buildings within one or more datacenters of the same region, where the servers are spread. + +To increase resilience in 1-AZ regions, a database replica server is deployed in a distinct nearby region. Replication to the remote region may take a few seconds longer than replication to the main region. + +![Architecture overview](images/KMS_Overview_1AZ.png){.thumbnail} + +#### 3-AZ regions + +On 3-AZ regions, mono-AZ architecture is duplicated across 3 Availability Zones. + +![Architecture overview](images/KMS_Overview_3AZ.png){.thumbnail} ### KMS components location @@ -39,87 +51,85 @@ These hosts are partitioned into two different zones so that any single hardware - **DB Replication** -The KMS will not return a success status for the creation or import of key material unless that data was successfully replicated to both zones. This is to ensure that if one of the databases is lost, no key will be lost. As a consequence, if one zone becomes unavailable, the KMS will refuse to create new keys. However, existing keys will still be available to perform cryptographic operations. +The KMS will not return a success status for write operations (e.g. creation or import of key material) unless the data has been successfully replicated to at least 2 database hosts (the primary and the synchronous replica). This is to ensure that if one of the databases hosts is lost, no data will be lost. + +An auto-failover mechanism in also in place to automatically reassign the database hosts roles in case the current primary or synchronous replica becomes unavailable. This means that if any of the 3 database hosts becomes unavailable, there will be no service interruption, except during the short failover phase (approximately one minute). -The key material is also replicated to a third database, in a different region. Because replication to a remote region has a higher latency, we do not wait for that replication to be complete before returning a success status to the user. Replication to the remote region will typically lag a few seconds at most behind the main region. +However, if 2 zones or 2 databases hosts become unavailable simultaneously, the OKMS will switch to read-only mode and write operations will fail (creation of new keys, secrets management, metadata updates, etc.). Existing keys will still be available to perform any cryptographic operations, and existing secrets will remain readable. - **DB Backups** -Regular backups are taken from the replica every 5 minutes. Each backup is stored in two regions, different from the main OKMS region.
+Incremental backups are taken every 5 minutes at most, and a full backup is taken daily. Each backup is stored in two different regions. These backups are kept for 30 days. #### Data security -All customer data are always stored encrypted in the databases and in the backups. +All customer data is always stored encrypted in the databases, and the database backups themselves are encrypted. #### Backup location The backup location depends on the location of the OKMS. -- **EU_WEST_RBX** - - KMS Backup Region 1 : EU_WEST_SBG - - KMS Backup Region 2 : EU_WEST_GRA -- **EU_WEST_SBG** - - KMS Backup Region 1 : EU_WEST_RBX - - KMS Backup Region 2 : EU_WEST_GRA -- **EU_WEST_PAR** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_SBG -- **EU_WEST_GRA** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_RBX -- **EU_WEST_LIM** - - KMS Backup Region 1 : EU_WEST_LIM - - KMS Backup Region 2 : EU_WEST_SBG -- **EU_SOUTH_MIL** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_SBG -- **CA_EAST_BHS** - - KMS Backup Region 1 : CA_EAST_BHS - - KMS Backup Region 2 : CA_EAST_TOR -- **CA_EAST_TOR** - - KMS Backup Region 1 : CA_EAST_BHS - - KMS Backup Region 2 : CA_EAST_TOR -- **AP_SOUTHEAST_SGP** - - KMS Backup Region 1 : AP_SOUTHEAST_SGP - - KMS Backup Region 2 : AP_SOUTHEAST_SYD -- **AP_SOUTHEAST_SYD** - - KMS Backup Region 1 : AP_SOUTHEAST_SGP - - KMS Backup Region 2 : AP_SOUTHEAST_SYD +- **EU-WEST-RBX** + - KMS Backup Region 1 : EU-WEST-SBG + - KMS Backup Region 2 : EU-WEST-GRA +- **EU-WEST-SBG** + - KMS Backup Region 1 : EU-WEST-RBX + - KMS Backup Region 2 : EU-WEST-GRA +- **EU-WEST-PAR** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-SBG +- **EU-WEST-GRA** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-RBX +- **EU-WEST-LIM** + - KMS Backup Region 1 : EU-WEST-LIM + - KMS Backup Region 2 : EU-WEST-SBG +- **EU-SOUTH-MIL** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-SBG +- **CA-EAST-BHS** + - KMS Backup Region 1 : CA-EAST-BHS + - KMS Backup Region 2 : CA-EAST-TOR +- **CA-EAST-TOR** + - KMS Backup Region 1 : CA-EAST-BHS + - KMS Backup Region 2 : CA-EAST-TOR +- **AP-SOUTHEAST-SGP** + - KMS Backup Region 1 : AP-SOUTHEAST-SGP + - KMS Backup Region 2 : AP-SOUTHEAST-SYD +- **AP-SOUTHEAST-SYD** + - KMS Backup Region 1 : AP-SOUTHEAST-SGP + - KMS Backup Region 2 : AP-SOUTHEAST-SYD ### Disaster scenarios #### What happens if one host in a zone is lost? -Keys remain available and traffic is redirected to the other zone.
-Requests in flight can timeout or return errors.
-If the database is down, the KMS will refuse to create or import new keys. +Keys remain available and traffic is redirected to another zone. +Requests in flight can timeout or return errors, depending on which host is affected. -#### What happens if a zone is lost? +#### What happens if one zone is lost? -Keys remain available.
-The other zone stays available to serve user queries but will refuse to create or import new keys. +Keys remain available and traffic is redirected to another zone. +Requests in flight can timeout or return errors. -#### What happens if the primary region is lost? +#### What happens if a whole region is lost? -The keys created in the last seconds can be lost and the KMS becomes unavailable.
-Database replica will be used at the region and rebuilt to retrieve stored keys. +3-AZ regions are designed to prevent this scenario, however it could occur on 1-AZ regions. -#### What happens if the primary region and the remote replica are lost? - -The keys created in the last 5 minutes can be lost and the KMS becomes unavailable.
-Database backup will be used at the region and rebuilt to retrieve stored keys. +In that case, the keys created in the last seconds can be lost and the OKMS becomes unavailable. +Database replica will be used at the region and rebuilt to retrieve stored keys. ## PCI-DSS certification Regions available for PCI-DSS certification: -- EU_WEST_RBX -- EU_WEST_SBG -- EU_WEST_GRA -- EU_WEST_LIM -- CA_EAST_BHS +- EU-WEST-RBX +- EU-WEST-SBG +- EU-WEST-GRA +- EU-WEST-LIM +- CA-EAST-BHS ## Go further -Join our [community of users](/links/community). +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/manage_and_operate/kms/architecture-overview/guide.en-asia.md b/pages/manage_and_operate/kms/architecture-overview/guide.en-asia.md index fa2bf1129e3..3e358c4491f 100644 --- a/pages/manage_and_operate/kms/architecture-overview/guide.en-asia.md +++ b/pages/manage_and_operate/kms/architecture-overview/guide.en-asia.md @@ -1,7 +1,7 @@ --- title: "OKMS Architecture overview" excerpt: "Discover how we handle the security of the OKMS infrastructure" -updated: 2025-10-21 +updated: 2025-10-24 --- ## Objective @@ -10,7 +10,7 @@ This guide explains how we handle the resilience of the OKMS infrastructure used ## Instructions -The OKMS architecture has 3 main objectives: +The OKMS architecture has three main objectives: - **Confidentiality**: Assure that no one except you can access your key. - **Availability**: Offering a high level of resilience and therefore high availability. @@ -23,11 +23,23 @@ Only the users allowed by an IAM policy can manage the keys or use them to encry Even the OVHcloud employees cannot access your keys. -### KMS architecture +### OKMS architecture -The OKMS infrastructure is by design replicated across multiple datacenters. +Each OKMS region is fully independent from the others and uses dedicated hosts. -![Architecture overview](images/KMS_Overview.png){.thumbnail} +#### 1-AZ regions + +The architecture of a single-AZ region is based on two zones located in distinct buildings within one or more datacenters of the same region, where the servers are spread. + +To increase resilience in 1-AZ regions, a database replica server is deployed in a distinct nearby region. Replication to the remote region may take a few seconds longer than replication to the main region. + +![Architecture overview](images/KMS_Overview_1AZ.png){.thumbnail} + +#### 3-AZ regions + +On 3-AZ regions, mono-AZ architecture is duplicated across 3 Availability Zones. + +![Architecture overview](images/KMS_Overview_3AZ.png){.thumbnail} ### KMS components location @@ -39,87 +51,85 @@ These hosts are partitioned into two different zones so that any single hardware - **DB Replication** -The KMS will not return a success status for the creation or import of key material unless that data was successfully replicated to both zones. This is to ensure that if one of the databases is lost, no key will be lost. As a consequence, if one zone becomes unavailable, the KMS will refuse to create new keys. However, existing keys will still be available to perform cryptographic operations. +The KMS will not return a success status for write operations (e.g. creation or import of key material) unless the data has been successfully replicated to at least 2 database hosts (the primary and the synchronous replica). This is to ensure that if one of the databases hosts is lost, no data will be lost. + +An auto-failover mechanism in also in place to automatically reassign the database hosts roles in case the current primary or synchronous replica becomes unavailable. This means that if any of the 3 database hosts becomes unavailable, there will be no service interruption, except during the short failover phase (approximately one minute). -The key material is also replicated to a third database, in a different region. Because replication to a remote region has a higher latency, we do not wait for that replication to be complete before returning a success status to the user. Replication to the remote region will typically lag a few seconds at most behind the main region. +However, if 2 zones or 2 databases hosts become unavailable simultaneously, the OKMS will switch to read-only mode and write operations will fail (creation of new keys, secrets management, metadata updates, etc.). Existing keys will still be available to perform any cryptographic operations, and existing secrets will remain readable. - **DB Backups** -Regular backups are taken from the replica every 5 minutes. Each backup is stored in two regions, different from the main OKMS region.
+Incremental backups are taken every 5 minutes at most, and a full backup is taken daily. Each backup is stored in two different regions. These backups are kept for 30 days. #### Data security -All customer data are always stored encrypted in the databases and in the backups. +All customer data is always stored encrypted in the databases, and the database backups themselves are encrypted. #### Backup location The backup location depends on the location of the OKMS. -- **EU_WEST_RBX** - - KMS Backup Region 1 : EU_WEST_SBG - - KMS Backup Region 2 : EU_WEST_GRA -- **EU_WEST_SBG** - - KMS Backup Region 1 : EU_WEST_RBX - - KMS Backup Region 2 : EU_WEST_GRA -- **EU_WEST_PAR** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_SBG -- **EU_WEST_GRA** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_RBX -- **EU_WEST_LIM** - - KMS Backup Region 1 : EU_WEST_LIM - - KMS Backup Region 2 : EU_WEST_SBG -- **EU_SOUTH_MIL** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_SBG -- **CA_EAST_BHS** - - KMS Backup Region 1 : CA_EAST_BHS - - KMS Backup Region 2 : CA_EAST_TOR -- **CA_EAST_TOR** - - KMS Backup Region 1 : CA_EAST_BHS - - KMS Backup Region 2 : CA_EAST_TOR -- **AP_SOUTHEAST_SGP** - - KMS Backup Region 1 : AP_SOUTHEAST_SGP - - KMS Backup Region 2 : AP_SOUTHEAST_SYD -- **AP_SOUTHEAST_SYD** - - KMS Backup Region 1 : AP_SOUTHEAST_SGP - - KMS Backup Region 2 : AP_SOUTHEAST_SYD +- **EU-WEST-RBX** + - KMS Backup Region 1 : EU-WEST-SBG + - KMS Backup Region 2 : EU-WEST-GRA +- **EU-WEST-SBG** + - KMS Backup Region 1 : EU-WEST-RBX + - KMS Backup Region 2 : EU-WEST-GRA +- **EU-WEST-PAR** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-SBG +- **EU-WEST-GRA** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-RBX +- **EU-WEST-LIM** + - KMS Backup Region 1 : EU-WEST-LIM + - KMS Backup Region 2 : EU-WEST-SBG +- **EU-SOUTH-MIL** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-SBG +- **CA-EAST-BHS** + - KMS Backup Region 1 : CA-EAST-BHS + - KMS Backup Region 2 : CA-EAST-TOR +- **CA-EAST-TOR** + - KMS Backup Region 1 : CA-EAST-BHS + - KMS Backup Region 2 : CA-EAST-TOR +- **AP-SOUTHEAST-SGP** + - KMS Backup Region 1 : AP-SOUTHEAST-SGP + - KMS Backup Region 2 : AP-SOUTHEAST-SYD +- **AP-SOUTHEAST-SYD** + - KMS Backup Region 1 : AP-SOUTHEAST-SGP + - KMS Backup Region 2 : AP-SOUTHEAST-SYD ### Disaster scenarios #### What happens if one host in a zone is lost? -Keys remain available and traffic is redirected to the other zone.
-Requests in flight can timeout or return errors.
-If the database is down, the KMS will refuse to create or import new keys. +Keys remain available and traffic is redirected to another zone. +Requests in flight can timeout or return errors, depending on which host is affected. -#### What happens if a zone is lost? +#### What happens if one zone is lost? -Keys remain available.
-The other zone stays available to serve user queries but will refuse to create or import new keys. +Keys remain available and traffic is redirected to another zone. +Requests in flight can timeout or return errors. -#### What happens if the primary region is lost? +#### What happens if a whole region is lost? -The keys created in the last seconds can be lost and the KMS becomes unavailable.
-Database replica will be used at the region and rebuilt to retrieve stored keys. +3-AZ regions are designed to prevent this scenario, however it could occur on 1-AZ regions. -#### What happens if the primary region and the remote replica are lost? - -The keys created in the last 5 minutes can be lost and the KMS becomes unavailable.
-Database backup will be used at the region and rebuilt to retrieve stored keys. +In that case, the keys created in the last seconds can be lost and the OKMS becomes unavailable. +Database replica will be used at the region and rebuilt to retrieve stored keys. ## PCI-DSS certification Regions available for PCI-DSS certification: -- EU_WEST_RBX -- EU_WEST_SBG -- EU_WEST_GRA -- EU_WEST_LIM -- CA_EAST_BHS +- EU-WEST-RBX +- EU-WEST-SBG +- EU-WEST-GRA +- EU-WEST-LIM +- CA-EAST-BHS ## Go further -Join our [community of users](/links/community). +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/manage_and_operate/kms/architecture-overview/guide.en-au.md b/pages/manage_and_operate/kms/architecture-overview/guide.en-au.md index fa2bf1129e3..3e358c4491f 100644 --- a/pages/manage_and_operate/kms/architecture-overview/guide.en-au.md +++ b/pages/manage_and_operate/kms/architecture-overview/guide.en-au.md @@ -1,7 +1,7 @@ --- title: "OKMS Architecture overview" excerpt: "Discover how we handle the security of the OKMS infrastructure" -updated: 2025-10-21 +updated: 2025-10-24 --- ## Objective @@ -10,7 +10,7 @@ This guide explains how we handle the resilience of the OKMS infrastructure used ## Instructions -The OKMS architecture has 3 main objectives: +The OKMS architecture has three main objectives: - **Confidentiality**: Assure that no one except you can access your key. - **Availability**: Offering a high level of resilience and therefore high availability. @@ -23,11 +23,23 @@ Only the users allowed by an IAM policy can manage the keys or use them to encry Even the OVHcloud employees cannot access your keys. -### KMS architecture +### OKMS architecture -The OKMS infrastructure is by design replicated across multiple datacenters. +Each OKMS region is fully independent from the others and uses dedicated hosts. -![Architecture overview](images/KMS_Overview.png){.thumbnail} +#### 1-AZ regions + +The architecture of a single-AZ region is based on two zones located in distinct buildings within one or more datacenters of the same region, where the servers are spread. + +To increase resilience in 1-AZ regions, a database replica server is deployed in a distinct nearby region. Replication to the remote region may take a few seconds longer than replication to the main region. + +![Architecture overview](images/KMS_Overview_1AZ.png){.thumbnail} + +#### 3-AZ regions + +On 3-AZ regions, mono-AZ architecture is duplicated across 3 Availability Zones. + +![Architecture overview](images/KMS_Overview_3AZ.png){.thumbnail} ### KMS components location @@ -39,87 +51,85 @@ These hosts are partitioned into two different zones so that any single hardware - **DB Replication** -The KMS will not return a success status for the creation or import of key material unless that data was successfully replicated to both zones. This is to ensure that if one of the databases is lost, no key will be lost. As a consequence, if one zone becomes unavailable, the KMS will refuse to create new keys. However, existing keys will still be available to perform cryptographic operations. +The KMS will not return a success status for write operations (e.g. creation or import of key material) unless the data has been successfully replicated to at least 2 database hosts (the primary and the synchronous replica). This is to ensure that if one of the databases hosts is lost, no data will be lost. + +An auto-failover mechanism in also in place to automatically reassign the database hosts roles in case the current primary or synchronous replica becomes unavailable. This means that if any of the 3 database hosts becomes unavailable, there will be no service interruption, except during the short failover phase (approximately one minute). -The key material is also replicated to a third database, in a different region. Because replication to a remote region has a higher latency, we do not wait for that replication to be complete before returning a success status to the user. Replication to the remote region will typically lag a few seconds at most behind the main region. +However, if 2 zones or 2 databases hosts become unavailable simultaneously, the OKMS will switch to read-only mode and write operations will fail (creation of new keys, secrets management, metadata updates, etc.). Existing keys will still be available to perform any cryptographic operations, and existing secrets will remain readable. - **DB Backups** -Regular backups are taken from the replica every 5 minutes. Each backup is stored in two regions, different from the main OKMS region.
+Incremental backups are taken every 5 minutes at most, and a full backup is taken daily. Each backup is stored in two different regions. These backups are kept for 30 days. #### Data security -All customer data are always stored encrypted in the databases and in the backups. +All customer data is always stored encrypted in the databases, and the database backups themselves are encrypted. #### Backup location The backup location depends on the location of the OKMS. -- **EU_WEST_RBX** - - KMS Backup Region 1 : EU_WEST_SBG - - KMS Backup Region 2 : EU_WEST_GRA -- **EU_WEST_SBG** - - KMS Backup Region 1 : EU_WEST_RBX - - KMS Backup Region 2 : EU_WEST_GRA -- **EU_WEST_PAR** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_SBG -- **EU_WEST_GRA** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_RBX -- **EU_WEST_LIM** - - KMS Backup Region 1 : EU_WEST_LIM - - KMS Backup Region 2 : EU_WEST_SBG -- **EU_SOUTH_MIL** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_SBG -- **CA_EAST_BHS** - - KMS Backup Region 1 : CA_EAST_BHS - - KMS Backup Region 2 : CA_EAST_TOR -- **CA_EAST_TOR** - - KMS Backup Region 1 : CA_EAST_BHS - - KMS Backup Region 2 : CA_EAST_TOR -- **AP_SOUTHEAST_SGP** - - KMS Backup Region 1 : AP_SOUTHEAST_SGP - - KMS Backup Region 2 : AP_SOUTHEAST_SYD -- **AP_SOUTHEAST_SYD** - - KMS Backup Region 1 : AP_SOUTHEAST_SGP - - KMS Backup Region 2 : AP_SOUTHEAST_SYD +- **EU-WEST-RBX** + - KMS Backup Region 1 : EU-WEST-SBG + - KMS Backup Region 2 : EU-WEST-GRA +- **EU-WEST-SBG** + - KMS Backup Region 1 : EU-WEST-RBX + - KMS Backup Region 2 : EU-WEST-GRA +- **EU-WEST-PAR** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-SBG +- **EU-WEST-GRA** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-RBX +- **EU-WEST-LIM** + - KMS Backup Region 1 : EU-WEST-LIM + - KMS Backup Region 2 : EU-WEST-SBG +- **EU-SOUTH-MIL** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-SBG +- **CA-EAST-BHS** + - KMS Backup Region 1 : CA-EAST-BHS + - KMS Backup Region 2 : CA-EAST-TOR +- **CA-EAST-TOR** + - KMS Backup Region 1 : CA-EAST-BHS + - KMS Backup Region 2 : CA-EAST-TOR +- **AP-SOUTHEAST-SGP** + - KMS Backup Region 1 : AP-SOUTHEAST-SGP + - KMS Backup Region 2 : AP-SOUTHEAST-SYD +- **AP-SOUTHEAST-SYD** + - KMS Backup Region 1 : AP-SOUTHEAST-SGP + - KMS Backup Region 2 : AP-SOUTHEAST-SYD ### Disaster scenarios #### What happens if one host in a zone is lost? -Keys remain available and traffic is redirected to the other zone.
-Requests in flight can timeout or return errors.
-If the database is down, the KMS will refuse to create or import new keys. +Keys remain available and traffic is redirected to another zone. +Requests in flight can timeout or return errors, depending on which host is affected. -#### What happens if a zone is lost? +#### What happens if one zone is lost? -Keys remain available.
-The other zone stays available to serve user queries but will refuse to create or import new keys. +Keys remain available and traffic is redirected to another zone. +Requests in flight can timeout or return errors. -#### What happens if the primary region is lost? +#### What happens if a whole region is lost? -The keys created in the last seconds can be lost and the KMS becomes unavailable.
-Database replica will be used at the region and rebuilt to retrieve stored keys. +3-AZ regions are designed to prevent this scenario, however it could occur on 1-AZ regions. -#### What happens if the primary region and the remote replica are lost? - -The keys created in the last 5 minutes can be lost and the KMS becomes unavailable.
-Database backup will be used at the region and rebuilt to retrieve stored keys. +In that case, the keys created in the last seconds can be lost and the OKMS becomes unavailable. +Database replica will be used at the region and rebuilt to retrieve stored keys. ## PCI-DSS certification Regions available for PCI-DSS certification: -- EU_WEST_RBX -- EU_WEST_SBG -- EU_WEST_GRA -- EU_WEST_LIM -- CA_EAST_BHS +- EU-WEST-RBX +- EU-WEST-SBG +- EU-WEST-GRA +- EU-WEST-LIM +- CA-EAST-BHS ## Go further -Join our [community of users](/links/community). +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/manage_and_operate/kms/architecture-overview/guide.en-ca.md b/pages/manage_and_operate/kms/architecture-overview/guide.en-ca.md index fa2bf1129e3..3e358c4491f 100644 --- a/pages/manage_and_operate/kms/architecture-overview/guide.en-ca.md +++ b/pages/manage_and_operate/kms/architecture-overview/guide.en-ca.md @@ -1,7 +1,7 @@ --- title: "OKMS Architecture overview" excerpt: "Discover how we handle the security of the OKMS infrastructure" -updated: 2025-10-21 +updated: 2025-10-24 --- ## Objective @@ -10,7 +10,7 @@ This guide explains how we handle the resilience of the OKMS infrastructure used ## Instructions -The OKMS architecture has 3 main objectives: +The OKMS architecture has three main objectives: - **Confidentiality**: Assure that no one except you can access your key. - **Availability**: Offering a high level of resilience and therefore high availability. @@ -23,11 +23,23 @@ Only the users allowed by an IAM policy can manage the keys or use them to encry Even the OVHcloud employees cannot access your keys. -### KMS architecture +### OKMS architecture -The OKMS infrastructure is by design replicated across multiple datacenters. +Each OKMS region is fully independent from the others and uses dedicated hosts. -![Architecture overview](images/KMS_Overview.png){.thumbnail} +#### 1-AZ regions + +The architecture of a single-AZ region is based on two zones located in distinct buildings within one or more datacenters of the same region, where the servers are spread. + +To increase resilience in 1-AZ regions, a database replica server is deployed in a distinct nearby region. Replication to the remote region may take a few seconds longer than replication to the main region. + +![Architecture overview](images/KMS_Overview_1AZ.png){.thumbnail} + +#### 3-AZ regions + +On 3-AZ regions, mono-AZ architecture is duplicated across 3 Availability Zones. + +![Architecture overview](images/KMS_Overview_3AZ.png){.thumbnail} ### KMS components location @@ -39,87 +51,85 @@ These hosts are partitioned into two different zones so that any single hardware - **DB Replication** -The KMS will not return a success status for the creation or import of key material unless that data was successfully replicated to both zones. This is to ensure that if one of the databases is lost, no key will be lost. As a consequence, if one zone becomes unavailable, the KMS will refuse to create new keys. However, existing keys will still be available to perform cryptographic operations. +The KMS will not return a success status for write operations (e.g. creation or import of key material) unless the data has been successfully replicated to at least 2 database hosts (the primary and the synchronous replica). This is to ensure that if one of the databases hosts is lost, no data will be lost. + +An auto-failover mechanism in also in place to automatically reassign the database hosts roles in case the current primary or synchronous replica becomes unavailable. This means that if any of the 3 database hosts becomes unavailable, there will be no service interruption, except during the short failover phase (approximately one minute). -The key material is also replicated to a third database, in a different region. Because replication to a remote region has a higher latency, we do not wait for that replication to be complete before returning a success status to the user. Replication to the remote region will typically lag a few seconds at most behind the main region. +However, if 2 zones or 2 databases hosts become unavailable simultaneously, the OKMS will switch to read-only mode and write operations will fail (creation of new keys, secrets management, metadata updates, etc.). Existing keys will still be available to perform any cryptographic operations, and existing secrets will remain readable. - **DB Backups** -Regular backups are taken from the replica every 5 minutes. Each backup is stored in two regions, different from the main OKMS region.
+Incremental backups are taken every 5 minutes at most, and a full backup is taken daily. Each backup is stored in two different regions. These backups are kept for 30 days. #### Data security -All customer data are always stored encrypted in the databases and in the backups. +All customer data is always stored encrypted in the databases, and the database backups themselves are encrypted. #### Backup location The backup location depends on the location of the OKMS. -- **EU_WEST_RBX** - - KMS Backup Region 1 : EU_WEST_SBG - - KMS Backup Region 2 : EU_WEST_GRA -- **EU_WEST_SBG** - - KMS Backup Region 1 : EU_WEST_RBX - - KMS Backup Region 2 : EU_WEST_GRA -- **EU_WEST_PAR** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_SBG -- **EU_WEST_GRA** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_RBX -- **EU_WEST_LIM** - - KMS Backup Region 1 : EU_WEST_LIM - - KMS Backup Region 2 : EU_WEST_SBG -- **EU_SOUTH_MIL** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_SBG -- **CA_EAST_BHS** - - KMS Backup Region 1 : CA_EAST_BHS - - KMS Backup Region 2 : CA_EAST_TOR -- **CA_EAST_TOR** - - KMS Backup Region 1 : CA_EAST_BHS - - KMS Backup Region 2 : CA_EAST_TOR -- **AP_SOUTHEAST_SGP** - - KMS Backup Region 1 : AP_SOUTHEAST_SGP - - KMS Backup Region 2 : AP_SOUTHEAST_SYD -- **AP_SOUTHEAST_SYD** - - KMS Backup Region 1 : AP_SOUTHEAST_SGP - - KMS Backup Region 2 : AP_SOUTHEAST_SYD +- **EU-WEST-RBX** + - KMS Backup Region 1 : EU-WEST-SBG + - KMS Backup Region 2 : EU-WEST-GRA +- **EU-WEST-SBG** + - KMS Backup Region 1 : EU-WEST-RBX + - KMS Backup Region 2 : EU-WEST-GRA +- **EU-WEST-PAR** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-SBG +- **EU-WEST-GRA** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-RBX +- **EU-WEST-LIM** + - KMS Backup Region 1 : EU-WEST-LIM + - KMS Backup Region 2 : EU-WEST-SBG +- **EU-SOUTH-MIL** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-SBG +- **CA-EAST-BHS** + - KMS Backup Region 1 : CA-EAST-BHS + - KMS Backup Region 2 : CA-EAST-TOR +- **CA-EAST-TOR** + - KMS Backup Region 1 : CA-EAST-BHS + - KMS Backup Region 2 : CA-EAST-TOR +- **AP-SOUTHEAST-SGP** + - KMS Backup Region 1 : AP-SOUTHEAST-SGP + - KMS Backup Region 2 : AP-SOUTHEAST-SYD +- **AP-SOUTHEAST-SYD** + - KMS Backup Region 1 : AP-SOUTHEAST-SGP + - KMS Backup Region 2 : AP-SOUTHEAST-SYD ### Disaster scenarios #### What happens if one host in a zone is lost? -Keys remain available and traffic is redirected to the other zone.
-Requests in flight can timeout or return errors.
-If the database is down, the KMS will refuse to create or import new keys. +Keys remain available and traffic is redirected to another zone. +Requests in flight can timeout or return errors, depending on which host is affected. -#### What happens if a zone is lost? +#### What happens if one zone is lost? -Keys remain available.
-The other zone stays available to serve user queries but will refuse to create or import new keys. +Keys remain available and traffic is redirected to another zone. +Requests in flight can timeout or return errors. -#### What happens if the primary region is lost? +#### What happens if a whole region is lost? -The keys created in the last seconds can be lost and the KMS becomes unavailable.
-Database replica will be used at the region and rebuilt to retrieve stored keys. +3-AZ regions are designed to prevent this scenario, however it could occur on 1-AZ regions. -#### What happens if the primary region and the remote replica are lost? - -The keys created in the last 5 minutes can be lost and the KMS becomes unavailable.
-Database backup will be used at the region and rebuilt to retrieve stored keys. +In that case, the keys created in the last seconds can be lost and the OKMS becomes unavailable. +Database replica will be used at the region and rebuilt to retrieve stored keys. ## PCI-DSS certification Regions available for PCI-DSS certification: -- EU_WEST_RBX -- EU_WEST_SBG -- EU_WEST_GRA -- EU_WEST_LIM -- CA_EAST_BHS +- EU-WEST-RBX +- EU-WEST-SBG +- EU-WEST-GRA +- EU-WEST-LIM +- CA-EAST-BHS ## Go further -Join our [community of users](/links/community). +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/manage_and_operate/kms/architecture-overview/guide.en-gb.md b/pages/manage_and_operate/kms/architecture-overview/guide.en-gb.md index fa2bf1129e3..3e358c4491f 100644 --- a/pages/manage_and_operate/kms/architecture-overview/guide.en-gb.md +++ b/pages/manage_and_operate/kms/architecture-overview/guide.en-gb.md @@ -1,7 +1,7 @@ --- title: "OKMS Architecture overview" excerpt: "Discover how we handle the security of the OKMS infrastructure" -updated: 2025-10-21 +updated: 2025-10-24 --- ## Objective @@ -10,7 +10,7 @@ This guide explains how we handle the resilience of the OKMS infrastructure used ## Instructions -The OKMS architecture has 3 main objectives: +The OKMS architecture has three main objectives: - **Confidentiality**: Assure that no one except you can access your key. - **Availability**: Offering a high level of resilience and therefore high availability. @@ -23,11 +23,23 @@ Only the users allowed by an IAM policy can manage the keys or use them to encry Even the OVHcloud employees cannot access your keys. -### KMS architecture +### OKMS architecture -The OKMS infrastructure is by design replicated across multiple datacenters. +Each OKMS region is fully independent from the others and uses dedicated hosts. -![Architecture overview](images/KMS_Overview.png){.thumbnail} +#### 1-AZ regions + +The architecture of a single-AZ region is based on two zones located in distinct buildings within one or more datacenters of the same region, where the servers are spread. + +To increase resilience in 1-AZ regions, a database replica server is deployed in a distinct nearby region. Replication to the remote region may take a few seconds longer than replication to the main region. + +![Architecture overview](images/KMS_Overview_1AZ.png){.thumbnail} + +#### 3-AZ regions + +On 3-AZ regions, mono-AZ architecture is duplicated across 3 Availability Zones. + +![Architecture overview](images/KMS_Overview_3AZ.png){.thumbnail} ### KMS components location @@ -39,87 +51,85 @@ These hosts are partitioned into two different zones so that any single hardware - **DB Replication** -The KMS will not return a success status for the creation or import of key material unless that data was successfully replicated to both zones. This is to ensure that if one of the databases is lost, no key will be lost. As a consequence, if one zone becomes unavailable, the KMS will refuse to create new keys. However, existing keys will still be available to perform cryptographic operations. +The KMS will not return a success status for write operations (e.g. creation or import of key material) unless the data has been successfully replicated to at least 2 database hosts (the primary and the synchronous replica). This is to ensure that if one of the databases hosts is lost, no data will be lost. + +An auto-failover mechanism in also in place to automatically reassign the database hosts roles in case the current primary or synchronous replica becomes unavailable. This means that if any of the 3 database hosts becomes unavailable, there will be no service interruption, except during the short failover phase (approximately one minute). -The key material is also replicated to a third database, in a different region. Because replication to a remote region has a higher latency, we do not wait for that replication to be complete before returning a success status to the user. Replication to the remote region will typically lag a few seconds at most behind the main region. +However, if 2 zones or 2 databases hosts become unavailable simultaneously, the OKMS will switch to read-only mode and write operations will fail (creation of new keys, secrets management, metadata updates, etc.). Existing keys will still be available to perform any cryptographic operations, and existing secrets will remain readable. - **DB Backups** -Regular backups are taken from the replica every 5 minutes. Each backup is stored in two regions, different from the main OKMS region.
+Incremental backups are taken every 5 minutes at most, and a full backup is taken daily. Each backup is stored in two different regions. These backups are kept for 30 days. #### Data security -All customer data are always stored encrypted in the databases and in the backups. +All customer data is always stored encrypted in the databases, and the database backups themselves are encrypted. #### Backup location The backup location depends on the location of the OKMS. -- **EU_WEST_RBX** - - KMS Backup Region 1 : EU_WEST_SBG - - KMS Backup Region 2 : EU_WEST_GRA -- **EU_WEST_SBG** - - KMS Backup Region 1 : EU_WEST_RBX - - KMS Backup Region 2 : EU_WEST_GRA -- **EU_WEST_PAR** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_SBG -- **EU_WEST_GRA** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_RBX -- **EU_WEST_LIM** - - KMS Backup Region 1 : EU_WEST_LIM - - KMS Backup Region 2 : EU_WEST_SBG -- **EU_SOUTH_MIL** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_SBG -- **CA_EAST_BHS** - - KMS Backup Region 1 : CA_EAST_BHS - - KMS Backup Region 2 : CA_EAST_TOR -- **CA_EAST_TOR** - - KMS Backup Region 1 : CA_EAST_BHS - - KMS Backup Region 2 : CA_EAST_TOR -- **AP_SOUTHEAST_SGP** - - KMS Backup Region 1 : AP_SOUTHEAST_SGP - - KMS Backup Region 2 : AP_SOUTHEAST_SYD -- **AP_SOUTHEAST_SYD** - - KMS Backup Region 1 : AP_SOUTHEAST_SGP - - KMS Backup Region 2 : AP_SOUTHEAST_SYD +- **EU-WEST-RBX** + - KMS Backup Region 1 : EU-WEST-SBG + - KMS Backup Region 2 : EU-WEST-GRA +- **EU-WEST-SBG** + - KMS Backup Region 1 : EU-WEST-RBX + - KMS Backup Region 2 : EU-WEST-GRA +- **EU-WEST-PAR** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-SBG +- **EU-WEST-GRA** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-RBX +- **EU-WEST-LIM** + - KMS Backup Region 1 : EU-WEST-LIM + - KMS Backup Region 2 : EU-WEST-SBG +- **EU-SOUTH-MIL** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-SBG +- **CA-EAST-BHS** + - KMS Backup Region 1 : CA-EAST-BHS + - KMS Backup Region 2 : CA-EAST-TOR +- **CA-EAST-TOR** + - KMS Backup Region 1 : CA-EAST-BHS + - KMS Backup Region 2 : CA-EAST-TOR +- **AP-SOUTHEAST-SGP** + - KMS Backup Region 1 : AP-SOUTHEAST-SGP + - KMS Backup Region 2 : AP-SOUTHEAST-SYD +- **AP-SOUTHEAST-SYD** + - KMS Backup Region 1 : AP-SOUTHEAST-SGP + - KMS Backup Region 2 : AP-SOUTHEAST-SYD ### Disaster scenarios #### What happens if one host in a zone is lost? -Keys remain available and traffic is redirected to the other zone.
-Requests in flight can timeout or return errors.
-If the database is down, the KMS will refuse to create or import new keys. +Keys remain available and traffic is redirected to another zone. +Requests in flight can timeout or return errors, depending on which host is affected. -#### What happens if a zone is lost? +#### What happens if one zone is lost? -Keys remain available.
-The other zone stays available to serve user queries but will refuse to create or import new keys. +Keys remain available and traffic is redirected to another zone. +Requests in flight can timeout or return errors. -#### What happens if the primary region is lost? +#### What happens if a whole region is lost? -The keys created in the last seconds can be lost and the KMS becomes unavailable.
-Database replica will be used at the region and rebuilt to retrieve stored keys. +3-AZ regions are designed to prevent this scenario, however it could occur on 1-AZ regions. -#### What happens if the primary region and the remote replica are lost? - -The keys created in the last 5 minutes can be lost and the KMS becomes unavailable.
-Database backup will be used at the region and rebuilt to retrieve stored keys. +In that case, the keys created in the last seconds can be lost and the OKMS becomes unavailable. +Database replica will be used at the region and rebuilt to retrieve stored keys. ## PCI-DSS certification Regions available for PCI-DSS certification: -- EU_WEST_RBX -- EU_WEST_SBG -- EU_WEST_GRA -- EU_WEST_LIM -- CA_EAST_BHS +- EU-WEST-RBX +- EU-WEST-SBG +- EU-WEST-GRA +- EU-WEST-LIM +- CA-EAST-BHS ## Go further -Join our [community of users](/links/community). +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/manage_and_operate/kms/architecture-overview/guide.en-ie.md b/pages/manage_and_operate/kms/architecture-overview/guide.en-ie.md index fa2bf1129e3..3e358c4491f 100644 --- a/pages/manage_and_operate/kms/architecture-overview/guide.en-ie.md +++ b/pages/manage_and_operate/kms/architecture-overview/guide.en-ie.md @@ -1,7 +1,7 @@ --- title: "OKMS Architecture overview" excerpt: "Discover how we handle the security of the OKMS infrastructure" -updated: 2025-10-21 +updated: 2025-10-24 --- ## Objective @@ -10,7 +10,7 @@ This guide explains how we handle the resilience of the OKMS infrastructure used ## Instructions -The OKMS architecture has 3 main objectives: +The OKMS architecture has three main objectives: - **Confidentiality**: Assure that no one except you can access your key. - **Availability**: Offering a high level of resilience and therefore high availability. @@ -23,11 +23,23 @@ Only the users allowed by an IAM policy can manage the keys or use them to encry Even the OVHcloud employees cannot access your keys. -### KMS architecture +### OKMS architecture -The OKMS infrastructure is by design replicated across multiple datacenters. +Each OKMS region is fully independent from the others and uses dedicated hosts. -![Architecture overview](images/KMS_Overview.png){.thumbnail} +#### 1-AZ regions + +The architecture of a single-AZ region is based on two zones located in distinct buildings within one or more datacenters of the same region, where the servers are spread. + +To increase resilience in 1-AZ regions, a database replica server is deployed in a distinct nearby region. Replication to the remote region may take a few seconds longer than replication to the main region. + +![Architecture overview](images/KMS_Overview_1AZ.png){.thumbnail} + +#### 3-AZ regions + +On 3-AZ regions, mono-AZ architecture is duplicated across 3 Availability Zones. + +![Architecture overview](images/KMS_Overview_3AZ.png){.thumbnail} ### KMS components location @@ -39,87 +51,85 @@ These hosts are partitioned into two different zones so that any single hardware - **DB Replication** -The KMS will not return a success status for the creation or import of key material unless that data was successfully replicated to both zones. This is to ensure that if one of the databases is lost, no key will be lost. As a consequence, if one zone becomes unavailable, the KMS will refuse to create new keys. However, existing keys will still be available to perform cryptographic operations. +The KMS will not return a success status for write operations (e.g. creation or import of key material) unless the data has been successfully replicated to at least 2 database hosts (the primary and the synchronous replica). This is to ensure that if one of the databases hosts is lost, no data will be lost. + +An auto-failover mechanism in also in place to automatically reassign the database hosts roles in case the current primary or synchronous replica becomes unavailable. This means that if any of the 3 database hosts becomes unavailable, there will be no service interruption, except during the short failover phase (approximately one minute). -The key material is also replicated to a third database, in a different region. Because replication to a remote region has a higher latency, we do not wait for that replication to be complete before returning a success status to the user. Replication to the remote region will typically lag a few seconds at most behind the main region. +However, if 2 zones or 2 databases hosts become unavailable simultaneously, the OKMS will switch to read-only mode and write operations will fail (creation of new keys, secrets management, metadata updates, etc.). Existing keys will still be available to perform any cryptographic operations, and existing secrets will remain readable. - **DB Backups** -Regular backups are taken from the replica every 5 minutes. Each backup is stored in two regions, different from the main OKMS region.
+Incremental backups are taken every 5 minutes at most, and a full backup is taken daily. Each backup is stored in two different regions. These backups are kept for 30 days. #### Data security -All customer data are always stored encrypted in the databases and in the backups. +All customer data is always stored encrypted in the databases, and the database backups themselves are encrypted. #### Backup location The backup location depends on the location of the OKMS. -- **EU_WEST_RBX** - - KMS Backup Region 1 : EU_WEST_SBG - - KMS Backup Region 2 : EU_WEST_GRA -- **EU_WEST_SBG** - - KMS Backup Region 1 : EU_WEST_RBX - - KMS Backup Region 2 : EU_WEST_GRA -- **EU_WEST_PAR** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_SBG -- **EU_WEST_GRA** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_RBX -- **EU_WEST_LIM** - - KMS Backup Region 1 : EU_WEST_LIM - - KMS Backup Region 2 : EU_WEST_SBG -- **EU_SOUTH_MIL** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_SBG -- **CA_EAST_BHS** - - KMS Backup Region 1 : CA_EAST_BHS - - KMS Backup Region 2 : CA_EAST_TOR -- **CA_EAST_TOR** - - KMS Backup Region 1 : CA_EAST_BHS - - KMS Backup Region 2 : CA_EAST_TOR -- **AP_SOUTHEAST_SGP** - - KMS Backup Region 1 : AP_SOUTHEAST_SGP - - KMS Backup Region 2 : AP_SOUTHEAST_SYD -- **AP_SOUTHEAST_SYD** - - KMS Backup Region 1 : AP_SOUTHEAST_SGP - - KMS Backup Region 2 : AP_SOUTHEAST_SYD +- **EU-WEST-RBX** + - KMS Backup Region 1 : EU-WEST-SBG + - KMS Backup Region 2 : EU-WEST-GRA +- **EU-WEST-SBG** + - KMS Backup Region 1 : EU-WEST-RBX + - KMS Backup Region 2 : EU-WEST-GRA +- **EU-WEST-PAR** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-SBG +- **EU-WEST-GRA** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-RBX +- **EU-WEST-LIM** + - KMS Backup Region 1 : EU-WEST-LIM + - KMS Backup Region 2 : EU-WEST-SBG +- **EU-SOUTH-MIL** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-SBG +- **CA-EAST-BHS** + - KMS Backup Region 1 : CA-EAST-BHS + - KMS Backup Region 2 : CA-EAST-TOR +- **CA-EAST-TOR** + - KMS Backup Region 1 : CA-EAST-BHS + - KMS Backup Region 2 : CA-EAST-TOR +- **AP-SOUTHEAST-SGP** + - KMS Backup Region 1 : AP-SOUTHEAST-SGP + - KMS Backup Region 2 : AP-SOUTHEAST-SYD +- **AP-SOUTHEAST-SYD** + - KMS Backup Region 1 : AP-SOUTHEAST-SGP + - KMS Backup Region 2 : AP-SOUTHEAST-SYD ### Disaster scenarios #### What happens if one host in a zone is lost? -Keys remain available and traffic is redirected to the other zone.
-Requests in flight can timeout or return errors.
-If the database is down, the KMS will refuse to create or import new keys. +Keys remain available and traffic is redirected to another zone. +Requests in flight can timeout or return errors, depending on which host is affected. -#### What happens if a zone is lost? +#### What happens if one zone is lost? -Keys remain available.
-The other zone stays available to serve user queries but will refuse to create or import new keys. +Keys remain available and traffic is redirected to another zone. +Requests in flight can timeout or return errors. -#### What happens if the primary region is lost? +#### What happens if a whole region is lost? -The keys created in the last seconds can be lost and the KMS becomes unavailable.
-Database replica will be used at the region and rebuilt to retrieve stored keys. +3-AZ regions are designed to prevent this scenario, however it could occur on 1-AZ regions. -#### What happens if the primary region and the remote replica are lost? - -The keys created in the last 5 minutes can be lost and the KMS becomes unavailable.
-Database backup will be used at the region and rebuilt to retrieve stored keys. +In that case, the keys created in the last seconds can be lost and the OKMS becomes unavailable. +Database replica will be used at the region and rebuilt to retrieve stored keys. ## PCI-DSS certification Regions available for PCI-DSS certification: -- EU_WEST_RBX -- EU_WEST_SBG -- EU_WEST_GRA -- EU_WEST_LIM -- CA_EAST_BHS +- EU-WEST-RBX +- EU-WEST-SBG +- EU-WEST-GRA +- EU-WEST-LIM +- CA-EAST-BHS ## Go further -Join our [community of users](/links/community). +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/manage_and_operate/kms/architecture-overview/guide.en-sg.md b/pages/manage_and_operate/kms/architecture-overview/guide.en-sg.md index fa2bf1129e3..3e358c4491f 100644 --- a/pages/manage_and_operate/kms/architecture-overview/guide.en-sg.md +++ b/pages/manage_and_operate/kms/architecture-overview/guide.en-sg.md @@ -1,7 +1,7 @@ --- title: "OKMS Architecture overview" excerpt: "Discover how we handle the security of the OKMS infrastructure" -updated: 2025-10-21 +updated: 2025-10-24 --- ## Objective @@ -10,7 +10,7 @@ This guide explains how we handle the resilience of the OKMS infrastructure used ## Instructions -The OKMS architecture has 3 main objectives: +The OKMS architecture has three main objectives: - **Confidentiality**: Assure that no one except you can access your key. - **Availability**: Offering a high level of resilience and therefore high availability. @@ -23,11 +23,23 @@ Only the users allowed by an IAM policy can manage the keys or use them to encry Even the OVHcloud employees cannot access your keys. -### KMS architecture +### OKMS architecture -The OKMS infrastructure is by design replicated across multiple datacenters. +Each OKMS region is fully independent from the others and uses dedicated hosts. -![Architecture overview](images/KMS_Overview.png){.thumbnail} +#### 1-AZ regions + +The architecture of a single-AZ region is based on two zones located in distinct buildings within one or more datacenters of the same region, where the servers are spread. + +To increase resilience in 1-AZ regions, a database replica server is deployed in a distinct nearby region. Replication to the remote region may take a few seconds longer than replication to the main region. + +![Architecture overview](images/KMS_Overview_1AZ.png){.thumbnail} + +#### 3-AZ regions + +On 3-AZ regions, mono-AZ architecture is duplicated across 3 Availability Zones. + +![Architecture overview](images/KMS_Overview_3AZ.png){.thumbnail} ### KMS components location @@ -39,87 +51,85 @@ These hosts are partitioned into two different zones so that any single hardware - **DB Replication** -The KMS will not return a success status for the creation or import of key material unless that data was successfully replicated to both zones. This is to ensure that if one of the databases is lost, no key will be lost. As a consequence, if one zone becomes unavailable, the KMS will refuse to create new keys. However, existing keys will still be available to perform cryptographic operations. +The KMS will not return a success status for write operations (e.g. creation or import of key material) unless the data has been successfully replicated to at least 2 database hosts (the primary and the synchronous replica). This is to ensure that if one of the databases hosts is lost, no data will be lost. + +An auto-failover mechanism in also in place to automatically reassign the database hosts roles in case the current primary or synchronous replica becomes unavailable. This means that if any of the 3 database hosts becomes unavailable, there will be no service interruption, except during the short failover phase (approximately one minute). -The key material is also replicated to a third database, in a different region. Because replication to a remote region has a higher latency, we do not wait for that replication to be complete before returning a success status to the user. Replication to the remote region will typically lag a few seconds at most behind the main region. +However, if 2 zones or 2 databases hosts become unavailable simultaneously, the OKMS will switch to read-only mode and write operations will fail (creation of new keys, secrets management, metadata updates, etc.). Existing keys will still be available to perform any cryptographic operations, and existing secrets will remain readable. - **DB Backups** -Regular backups are taken from the replica every 5 minutes. Each backup is stored in two regions, different from the main OKMS region.
+Incremental backups are taken every 5 minutes at most, and a full backup is taken daily. Each backup is stored in two different regions. These backups are kept for 30 days. #### Data security -All customer data are always stored encrypted in the databases and in the backups. +All customer data is always stored encrypted in the databases, and the database backups themselves are encrypted. #### Backup location The backup location depends on the location of the OKMS. -- **EU_WEST_RBX** - - KMS Backup Region 1 : EU_WEST_SBG - - KMS Backup Region 2 : EU_WEST_GRA -- **EU_WEST_SBG** - - KMS Backup Region 1 : EU_WEST_RBX - - KMS Backup Region 2 : EU_WEST_GRA -- **EU_WEST_PAR** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_SBG -- **EU_WEST_GRA** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_RBX -- **EU_WEST_LIM** - - KMS Backup Region 1 : EU_WEST_LIM - - KMS Backup Region 2 : EU_WEST_SBG -- **EU_SOUTH_MIL** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_SBG -- **CA_EAST_BHS** - - KMS Backup Region 1 : CA_EAST_BHS - - KMS Backup Region 2 : CA_EAST_TOR -- **CA_EAST_TOR** - - KMS Backup Region 1 : CA_EAST_BHS - - KMS Backup Region 2 : CA_EAST_TOR -- **AP_SOUTHEAST_SGP** - - KMS Backup Region 1 : AP_SOUTHEAST_SGP - - KMS Backup Region 2 : AP_SOUTHEAST_SYD -- **AP_SOUTHEAST_SYD** - - KMS Backup Region 1 : AP_SOUTHEAST_SGP - - KMS Backup Region 2 : AP_SOUTHEAST_SYD +- **EU-WEST-RBX** + - KMS Backup Region 1 : EU-WEST-SBG + - KMS Backup Region 2 : EU-WEST-GRA +- **EU-WEST-SBG** + - KMS Backup Region 1 : EU-WEST-RBX + - KMS Backup Region 2 : EU-WEST-GRA +- **EU-WEST-PAR** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-SBG +- **EU-WEST-GRA** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-RBX +- **EU-WEST-LIM** + - KMS Backup Region 1 : EU-WEST-LIM + - KMS Backup Region 2 : EU-WEST-SBG +- **EU-SOUTH-MIL** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-SBG +- **CA-EAST-BHS** + - KMS Backup Region 1 : CA-EAST-BHS + - KMS Backup Region 2 : CA-EAST-TOR +- **CA-EAST-TOR** + - KMS Backup Region 1 : CA-EAST-BHS + - KMS Backup Region 2 : CA-EAST-TOR +- **AP-SOUTHEAST-SGP** + - KMS Backup Region 1 : AP-SOUTHEAST-SGP + - KMS Backup Region 2 : AP-SOUTHEAST-SYD +- **AP-SOUTHEAST-SYD** + - KMS Backup Region 1 : AP-SOUTHEAST-SGP + - KMS Backup Region 2 : AP-SOUTHEAST-SYD ### Disaster scenarios #### What happens if one host in a zone is lost? -Keys remain available and traffic is redirected to the other zone.
-Requests in flight can timeout or return errors.
-If the database is down, the KMS will refuse to create or import new keys. +Keys remain available and traffic is redirected to another zone. +Requests in flight can timeout or return errors, depending on which host is affected. -#### What happens if a zone is lost? +#### What happens if one zone is lost? -Keys remain available.
-The other zone stays available to serve user queries but will refuse to create or import new keys. +Keys remain available and traffic is redirected to another zone. +Requests in flight can timeout or return errors. -#### What happens if the primary region is lost? +#### What happens if a whole region is lost? -The keys created in the last seconds can be lost and the KMS becomes unavailable.
-Database replica will be used at the region and rebuilt to retrieve stored keys. +3-AZ regions are designed to prevent this scenario, however it could occur on 1-AZ regions. -#### What happens if the primary region and the remote replica are lost? - -The keys created in the last 5 minutes can be lost and the KMS becomes unavailable.
-Database backup will be used at the region and rebuilt to retrieve stored keys. +In that case, the keys created in the last seconds can be lost and the OKMS becomes unavailable. +Database replica will be used at the region and rebuilt to retrieve stored keys. ## PCI-DSS certification Regions available for PCI-DSS certification: -- EU_WEST_RBX -- EU_WEST_SBG -- EU_WEST_GRA -- EU_WEST_LIM -- CA_EAST_BHS +- EU-WEST-RBX +- EU-WEST-SBG +- EU-WEST-GRA +- EU-WEST-LIM +- CA-EAST-BHS ## Go further -Join our [community of users](/links/community). +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/manage_and_operate/kms/architecture-overview/guide.en-us.md b/pages/manage_and_operate/kms/architecture-overview/guide.en-us.md index fa2bf1129e3..3e358c4491f 100644 --- a/pages/manage_and_operate/kms/architecture-overview/guide.en-us.md +++ b/pages/manage_and_operate/kms/architecture-overview/guide.en-us.md @@ -1,7 +1,7 @@ --- title: "OKMS Architecture overview" excerpt: "Discover how we handle the security of the OKMS infrastructure" -updated: 2025-10-21 +updated: 2025-10-24 --- ## Objective @@ -10,7 +10,7 @@ This guide explains how we handle the resilience of the OKMS infrastructure used ## Instructions -The OKMS architecture has 3 main objectives: +The OKMS architecture has three main objectives: - **Confidentiality**: Assure that no one except you can access your key. - **Availability**: Offering a high level of resilience and therefore high availability. @@ -23,11 +23,23 @@ Only the users allowed by an IAM policy can manage the keys or use them to encry Even the OVHcloud employees cannot access your keys. -### KMS architecture +### OKMS architecture -The OKMS infrastructure is by design replicated across multiple datacenters. +Each OKMS region is fully independent from the others and uses dedicated hosts. -![Architecture overview](images/KMS_Overview.png){.thumbnail} +#### 1-AZ regions + +The architecture of a single-AZ region is based on two zones located in distinct buildings within one or more datacenters of the same region, where the servers are spread. + +To increase resilience in 1-AZ regions, a database replica server is deployed in a distinct nearby region. Replication to the remote region may take a few seconds longer than replication to the main region. + +![Architecture overview](images/KMS_Overview_1AZ.png){.thumbnail} + +#### 3-AZ regions + +On 3-AZ regions, mono-AZ architecture is duplicated across 3 Availability Zones. + +![Architecture overview](images/KMS_Overview_3AZ.png){.thumbnail} ### KMS components location @@ -39,87 +51,85 @@ These hosts are partitioned into two different zones so that any single hardware - **DB Replication** -The KMS will not return a success status for the creation or import of key material unless that data was successfully replicated to both zones. This is to ensure that if one of the databases is lost, no key will be lost. As a consequence, if one zone becomes unavailable, the KMS will refuse to create new keys. However, existing keys will still be available to perform cryptographic operations. +The KMS will not return a success status for write operations (e.g. creation or import of key material) unless the data has been successfully replicated to at least 2 database hosts (the primary and the synchronous replica). This is to ensure that if one of the databases hosts is lost, no data will be lost. + +An auto-failover mechanism in also in place to automatically reassign the database hosts roles in case the current primary or synchronous replica becomes unavailable. This means that if any of the 3 database hosts becomes unavailable, there will be no service interruption, except during the short failover phase (approximately one minute). -The key material is also replicated to a third database, in a different region. Because replication to a remote region has a higher latency, we do not wait for that replication to be complete before returning a success status to the user. Replication to the remote region will typically lag a few seconds at most behind the main region. +However, if 2 zones or 2 databases hosts become unavailable simultaneously, the OKMS will switch to read-only mode and write operations will fail (creation of new keys, secrets management, metadata updates, etc.). Existing keys will still be available to perform any cryptographic operations, and existing secrets will remain readable. - **DB Backups** -Regular backups are taken from the replica every 5 minutes. Each backup is stored in two regions, different from the main OKMS region.
+Incremental backups are taken every 5 minutes at most, and a full backup is taken daily. Each backup is stored in two different regions. These backups are kept for 30 days. #### Data security -All customer data are always stored encrypted in the databases and in the backups. +All customer data is always stored encrypted in the databases, and the database backups themselves are encrypted. #### Backup location The backup location depends on the location of the OKMS. -- **EU_WEST_RBX** - - KMS Backup Region 1 : EU_WEST_SBG - - KMS Backup Region 2 : EU_WEST_GRA -- **EU_WEST_SBG** - - KMS Backup Region 1 : EU_WEST_RBX - - KMS Backup Region 2 : EU_WEST_GRA -- **EU_WEST_PAR** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_SBG -- **EU_WEST_GRA** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_RBX -- **EU_WEST_LIM** - - KMS Backup Region 1 : EU_WEST_LIM - - KMS Backup Region 2 : EU_WEST_SBG -- **EU_SOUTH_MIL** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_SBG -- **CA_EAST_BHS** - - KMS Backup Region 1 : CA_EAST_BHS - - KMS Backup Region 2 : CA_EAST_TOR -- **CA_EAST_TOR** - - KMS Backup Region 1 : CA_EAST_BHS - - KMS Backup Region 2 : CA_EAST_TOR -- **AP_SOUTHEAST_SGP** - - KMS Backup Region 1 : AP_SOUTHEAST_SGP - - KMS Backup Region 2 : AP_SOUTHEAST_SYD -- **AP_SOUTHEAST_SYD** - - KMS Backup Region 1 : AP_SOUTHEAST_SGP - - KMS Backup Region 2 : AP_SOUTHEAST_SYD +- **EU-WEST-RBX** + - KMS Backup Region 1 : EU-WEST-SBG + - KMS Backup Region 2 : EU-WEST-GRA +- **EU-WEST-SBG** + - KMS Backup Region 1 : EU-WEST-RBX + - KMS Backup Region 2 : EU-WEST-GRA +- **EU-WEST-PAR** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-SBG +- **EU-WEST-GRA** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-RBX +- **EU-WEST-LIM** + - KMS Backup Region 1 : EU-WEST-LIM + - KMS Backup Region 2 : EU-WEST-SBG +- **EU-SOUTH-MIL** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-SBG +- **CA-EAST-BHS** + - KMS Backup Region 1 : CA-EAST-BHS + - KMS Backup Region 2 : CA-EAST-TOR +- **CA-EAST-TOR** + - KMS Backup Region 1 : CA-EAST-BHS + - KMS Backup Region 2 : CA-EAST-TOR +- **AP-SOUTHEAST-SGP** + - KMS Backup Region 1 : AP-SOUTHEAST-SGP + - KMS Backup Region 2 : AP-SOUTHEAST-SYD +- **AP-SOUTHEAST-SYD** + - KMS Backup Region 1 : AP-SOUTHEAST-SGP + - KMS Backup Region 2 : AP-SOUTHEAST-SYD ### Disaster scenarios #### What happens if one host in a zone is lost? -Keys remain available and traffic is redirected to the other zone.
-Requests in flight can timeout or return errors.
-If the database is down, the KMS will refuse to create or import new keys. +Keys remain available and traffic is redirected to another zone. +Requests in flight can timeout or return errors, depending on which host is affected. -#### What happens if a zone is lost? +#### What happens if one zone is lost? -Keys remain available.
-The other zone stays available to serve user queries but will refuse to create or import new keys. +Keys remain available and traffic is redirected to another zone. +Requests in flight can timeout or return errors. -#### What happens if the primary region is lost? +#### What happens if a whole region is lost? -The keys created in the last seconds can be lost and the KMS becomes unavailable.
-Database replica will be used at the region and rebuilt to retrieve stored keys. +3-AZ regions are designed to prevent this scenario, however it could occur on 1-AZ regions. -#### What happens if the primary region and the remote replica are lost? - -The keys created in the last 5 minutes can be lost and the KMS becomes unavailable.
-Database backup will be used at the region and rebuilt to retrieve stored keys. +In that case, the keys created in the last seconds can be lost and the OKMS becomes unavailable. +Database replica will be used at the region and rebuilt to retrieve stored keys. ## PCI-DSS certification Regions available for PCI-DSS certification: -- EU_WEST_RBX -- EU_WEST_SBG -- EU_WEST_GRA -- EU_WEST_LIM -- CA_EAST_BHS +- EU-WEST-RBX +- EU-WEST-SBG +- EU-WEST-GRA +- EU-WEST-LIM +- CA-EAST-BHS ## Go further -Join our [community of users](/links/community). +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/manage_and_operate/kms/architecture-overview/guide.es-es.md b/pages/manage_and_operate/kms/architecture-overview/guide.es-es.md index fa2bf1129e3..3e358c4491f 100644 --- a/pages/manage_and_operate/kms/architecture-overview/guide.es-es.md +++ b/pages/manage_and_operate/kms/architecture-overview/guide.es-es.md @@ -1,7 +1,7 @@ --- title: "OKMS Architecture overview" excerpt: "Discover how we handle the security of the OKMS infrastructure" -updated: 2025-10-21 +updated: 2025-10-24 --- ## Objective @@ -10,7 +10,7 @@ This guide explains how we handle the resilience of the OKMS infrastructure used ## Instructions -The OKMS architecture has 3 main objectives: +The OKMS architecture has three main objectives: - **Confidentiality**: Assure that no one except you can access your key. - **Availability**: Offering a high level of resilience and therefore high availability. @@ -23,11 +23,23 @@ Only the users allowed by an IAM policy can manage the keys or use them to encry Even the OVHcloud employees cannot access your keys. -### KMS architecture +### OKMS architecture -The OKMS infrastructure is by design replicated across multiple datacenters. +Each OKMS region is fully independent from the others and uses dedicated hosts. -![Architecture overview](images/KMS_Overview.png){.thumbnail} +#### 1-AZ regions + +The architecture of a single-AZ region is based on two zones located in distinct buildings within one or more datacenters of the same region, where the servers are spread. + +To increase resilience in 1-AZ regions, a database replica server is deployed in a distinct nearby region. Replication to the remote region may take a few seconds longer than replication to the main region. + +![Architecture overview](images/KMS_Overview_1AZ.png){.thumbnail} + +#### 3-AZ regions + +On 3-AZ regions, mono-AZ architecture is duplicated across 3 Availability Zones. + +![Architecture overview](images/KMS_Overview_3AZ.png){.thumbnail} ### KMS components location @@ -39,87 +51,85 @@ These hosts are partitioned into two different zones so that any single hardware - **DB Replication** -The KMS will not return a success status for the creation or import of key material unless that data was successfully replicated to both zones. This is to ensure that if one of the databases is lost, no key will be lost. As a consequence, if one zone becomes unavailable, the KMS will refuse to create new keys. However, existing keys will still be available to perform cryptographic operations. +The KMS will not return a success status for write operations (e.g. creation or import of key material) unless the data has been successfully replicated to at least 2 database hosts (the primary and the synchronous replica). This is to ensure that if one of the databases hosts is lost, no data will be lost. + +An auto-failover mechanism in also in place to automatically reassign the database hosts roles in case the current primary or synchronous replica becomes unavailable. This means that if any of the 3 database hosts becomes unavailable, there will be no service interruption, except during the short failover phase (approximately one minute). -The key material is also replicated to a third database, in a different region. Because replication to a remote region has a higher latency, we do not wait for that replication to be complete before returning a success status to the user. Replication to the remote region will typically lag a few seconds at most behind the main region. +However, if 2 zones or 2 databases hosts become unavailable simultaneously, the OKMS will switch to read-only mode and write operations will fail (creation of new keys, secrets management, metadata updates, etc.). Existing keys will still be available to perform any cryptographic operations, and existing secrets will remain readable. - **DB Backups** -Regular backups are taken from the replica every 5 minutes. Each backup is stored in two regions, different from the main OKMS region.
+Incremental backups are taken every 5 minutes at most, and a full backup is taken daily. Each backup is stored in two different regions. These backups are kept for 30 days. #### Data security -All customer data are always stored encrypted in the databases and in the backups. +All customer data is always stored encrypted in the databases, and the database backups themselves are encrypted. #### Backup location The backup location depends on the location of the OKMS. -- **EU_WEST_RBX** - - KMS Backup Region 1 : EU_WEST_SBG - - KMS Backup Region 2 : EU_WEST_GRA -- **EU_WEST_SBG** - - KMS Backup Region 1 : EU_WEST_RBX - - KMS Backup Region 2 : EU_WEST_GRA -- **EU_WEST_PAR** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_SBG -- **EU_WEST_GRA** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_RBX -- **EU_WEST_LIM** - - KMS Backup Region 1 : EU_WEST_LIM - - KMS Backup Region 2 : EU_WEST_SBG -- **EU_SOUTH_MIL** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_SBG -- **CA_EAST_BHS** - - KMS Backup Region 1 : CA_EAST_BHS - - KMS Backup Region 2 : CA_EAST_TOR -- **CA_EAST_TOR** - - KMS Backup Region 1 : CA_EAST_BHS - - KMS Backup Region 2 : CA_EAST_TOR -- **AP_SOUTHEAST_SGP** - - KMS Backup Region 1 : AP_SOUTHEAST_SGP - - KMS Backup Region 2 : AP_SOUTHEAST_SYD -- **AP_SOUTHEAST_SYD** - - KMS Backup Region 1 : AP_SOUTHEAST_SGP - - KMS Backup Region 2 : AP_SOUTHEAST_SYD +- **EU-WEST-RBX** + - KMS Backup Region 1 : EU-WEST-SBG + - KMS Backup Region 2 : EU-WEST-GRA +- **EU-WEST-SBG** + - KMS Backup Region 1 : EU-WEST-RBX + - KMS Backup Region 2 : EU-WEST-GRA +- **EU-WEST-PAR** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-SBG +- **EU-WEST-GRA** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-RBX +- **EU-WEST-LIM** + - KMS Backup Region 1 : EU-WEST-LIM + - KMS Backup Region 2 : EU-WEST-SBG +- **EU-SOUTH-MIL** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-SBG +- **CA-EAST-BHS** + - KMS Backup Region 1 : CA-EAST-BHS + - KMS Backup Region 2 : CA-EAST-TOR +- **CA-EAST-TOR** + - KMS Backup Region 1 : CA-EAST-BHS + - KMS Backup Region 2 : CA-EAST-TOR +- **AP-SOUTHEAST-SGP** + - KMS Backup Region 1 : AP-SOUTHEAST-SGP + - KMS Backup Region 2 : AP-SOUTHEAST-SYD +- **AP-SOUTHEAST-SYD** + - KMS Backup Region 1 : AP-SOUTHEAST-SGP + - KMS Backup Region 2 : AP-SOUTHEAST-SYD ### Disaster scenarios #### What happens if one host in a zone is lost? -Keys remain available and traffic is redirected to the other zone.
-Requests in flight can timeout or return errors.
-If the database is down, the KMS will refuse to create or import new keys. +Keys remain available and traffic is redirected to another zone. +Requests in flight can timeout or return errors, depending on which host is affected. -#### What happens if a zone is lost? +#### What happens if one zone is lost? -Keys remain available.
-The other zone stays available to serve user queries but will refuse to create or import new keys. +Keys remain available and traffic is redirected to another zone. +Requests in flight can timeout or return errors. -#### What happens if the primary region is lost? +#### What happens if a whole region is lost? -The keys created in the last seconds can be lost and the KMS becomes unavailable.
-Database replica will be used at the region and rebuilt to retrieve stored keys. +3-AZ regions are designed to prevent this scenario, however it could occur on 1-AZ regions. -#### What happens if the primary region and the remote replica are lost? - -The keys created in the last 5 minutes can be lost and the KMS becomes unavailable.
-Database backup will be used at the region and rebuilt to retrieve stored keys. +In that case, the keys created in the last seconds can be lost and the OKMS becomes unavailable. +Database replica will be used at the region and rebuilt to retrieve stored keys. ## PCI-DSS certification Regions available for PCI-DSS certification: -- EU_WEST_RBX -- EU_WEST_SBG -- EU_WEST_GRA -- EU_WEST_LIM -- CA_EAST_BHS +- EU-WEST-RBX +- EU-WEST-SBG +- EU-WEST-GRA +- EU-WEST-LIM +- CA-EAST-BHS ## Go further -Join our [community of users](/links/community). +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/manage_and_operate/kms/architecture-overview/guide.es-us.md b/pages/manage_and_operate/kms/architecture-overview/guide.es-us.md index fa2bf1129e3..3e358c4491f 100644 --- a/pages/manage_and_operate/kms/architecture-overview/guide.es-us.md +++ b/pages/manage_and_operate/kms/architecture-overview/guide.es-us.md @@ -1,7 +1,7 @@ --- title: "OKMS Architecture overview" excerpt: "Discover how we handle the security of the OKMS infrastructure" -updated: 2025-10-21 +updated: 2025-10-24 --- ## Objective @@ -10,7 +10,7 @@ This guide explains how we handle the resilience of the OKMS infrastructure used ## Instructions -The OKMS architecture has 3 main objectives: +The OKMS architecture has three main objectives: - **Confidentiality**: Assure that no one except you can access your key. - **Availability**: Offering a high level of resilience and therefore high availability. @@ -23,11 +23,23 @@ Only the users allowed by an IAM policy can manage the keys or use them to encry Even the OVHcloud employees cannot access your keys. -### KMS architecture +### OKMS architecture -The OKMS infrastructure is by design replicated across multiple datacenters. +Each OKMS region is fully independent from the others and uses dedicated hosts. -![Architecture overview](images/KMS_Overview.png){.thumbnail} +#### 1-AZ regions + +The architecture of a single-AZ region is based on two zones located in distinct buildings within one or more datacenters of the same region, where the servers are spread. + +To increase resilience in 1-AZ regions, a database replica server is deployed in a distinct nearby region. Replication to the remote region may take a few seconds longer than replication to the main region. + +![Architecture overview](images/KMS_Overview_1AZ.png){.thumbnail} + +#### 3-AZ regions + +On 3-AZ regions, mono-AZ architecture is duplicated across 3 Availability Zones. + +![Architecture overview](images/KMS_Overview_3AZ.png){.thumbnail} ### KMS components location @@ -39,87 +51,85 @@ These hosts are partitioned into two different zones so that any single hardware - **DB Replication** -The KMS will not return a success status for the creation or import of key material unless that data was successfully replicated to both zones. This is to ensure that if one of the databases is lost, no key will be lost. As a consequence, if one zone becomes unavailable, the KMS will refuse to create new keys. However, existing keys will still be available to perform cryptographic operations. +The KMS will not return a success status for write operations (e.g. creation or import of key material) unless the data has been successfully replicated to at least 2 database hosts (the primary and the synchronous replica). This is to ensure that if one of the databases hosts is lost, no data will be lost. + +An auto-failover mechanism in also in place to automatically reassign the database hosts roles in case the current primary or synchronous replica becomes unavailable. This means that if any of the 3 database hosts becomes unavailable, there will be no service interruption, except during the short failover phase (approximately one minute). -The key material is also replicated to a third database, in a different region. Because replication to a remote region has a higher latency, we do not wait for that replication to be complete before returning a success status to the user. Replication to the remote region will typically lag a few seconds at most behind the main region. +However, if 2 zones or 2 databases hosts become unavailable simultaneously, the OKMS will switch to read-only mode and write operations will fail (creation of new keys, secrets management, metadata updates, etc.). Existing keys will still be available to perform any cryptographic operations, and existing secrets will remain readable. - **DB Backups** -Regular backups are taken from the replica every 5 minutes. Each backup is stored in two regions, different from the main OKMS region.
+Incremental backups are taken every 5 minutes at most, and a full backup is taken daily. Each backup is stored in two different regions. These backups are kept for 30 days. #### Data security -All customer data are always stored encrypted in the databases and in the backups. +All customer data is always stored encrypted in the databases, and the database backups themselves are encrypted. #### Backup location The backup location depends on the location of the OKMS. -- **EU_WEST_RBX** - - KMS Backup Region 1 : EU_WEST_SBG - - KMS Backup Region 2 : EU_WEST_GRA -- **EU_WEST_SBG** - - KMS Backup Region 1 : EU_WEST_RBX - - KMS Backup Region 2 : EU_WEST_GRA -- **EU_WEST_PAR** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_SBG -- **EU_WEST_GRA** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_RBX -- **EU_WEST_LIM** - - KMS Backup Region 1 : EU_WEST_LIM - - KMS Backup Region 2 : EU_WEST_SBG -- **EU_SOUTH_MIL** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_SBG -- **CA_EAST_BHS** - - KMS Backup Region 1 : CA_EAST_BHS - - KMS Backup Region 2 : CA_EAST_TOR -- **CA_EAST_TOR** - - KMS Backup Region 1 : CA_EAST_BHS - - KMS Backup Region 2 : CA_EAST_TOR -- **AP_SOUTHEAST_SGP** - - KMS Backup Region 1 : AP_SOUTHEAST_SGP - - KMS Backup Region 2 : AP_SOUTHEAST_SYD -- **AP_SOUTHEAST_SYD** - - KMS Backup Region 1 : AP_SOUTHEAST_SGP - - KMS Backup Region 2 : AP_SOUTHEAST_SYD +- **EU-WEST-RBX** + - KMS Backup Region 1 : EU-WEST-SBG + - KMS Backup Region 2 : EU-WEST-GRA +- **EU-WEST-SBG** + - KMS Backup Region 1 : EU-WEST-RBX + - KMS Backup Region 2 : EU-WEST-GRA +- **EU-WEST-PAR** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-SBG +- **EU-WEST-GRA** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-RBX +- **EU-WEST-LIM** + - KMS Backup Region 1 : EU-WEST-LIM + - KMS Backup Region 2 : EU-WEST-SBG +- **EU-SOUTH-MIL** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-SBG +- **CA-EAST-BHS** + - KMS Backup Region 1 : CA-EAST-BHS + - KMS Backup Region 2 : CA-EAST-TOR +- **CA-EAST-TOR** + - KMS Backup Region 1 : CA-EAST-BHS + - KMS Backup Region 2 : CA-EAST-TOR +- **AP-SOUTHEAST-SGP** + - KMS Backup Region 1 : AP-SOUTHEAST-SGP + - KMS Backup Region 2 : AP-SOUTHEAST-SYD +- **AP-SOUTHEAST-SYD** + - KMS Backup Region 1 : AP-SOUTHEAST-SGP + - KMS Backup Region 2 : AP-SOUTHEAST-SYD ### Disaster scenarios #### What happens if one host in a zone is lost? -Keys remain available and traffic is redirected to the other zone.
-Requests in flight can timeout or return errors.
-If the database is down, the KMS will refuse to create or import new keys. +Keys remain available and traffic is redirected to another zone. +Requests in flight can timeout or return errors, depending on which host is affected. -#### What happens if a zone is lost? +#### What happens if one zone is lost? -Keys remain available.
-The other zone stays available to serve user queries but will refuse to create or import new keys. +Keys remain available and traffic is redirected to another zone. +Requests in flight can timeout or return errors. -#### What happens if the primary region is lost? +#### What happens if a whole region is lost? -The keys created in the last seconds can be lost and the KMS becomes unavailable.
-Database replica will be used at the region and rebuilt to retrieve stored keys. +3-AZ regions are designed to prevent this scenario, however it could occur on 1-AZ regions. -#### What happens if the primary region and the remote replica are lost? - -The keys created in the last 5 minutes can be lost and the KMS becomes unavailable.
-Database backup will be used at the region and rebuilt to retrieve stored keys. +In that case, the keys created in the last seconds can be lost and the OKMS becomes unavailable. +Database replica will be used at the region and rebuilt to retrieve stored keys. ## PCI-DSS certification Regions available for PCI-DSS certification: -- EU_WEST_RBX -- EU_WEST_SBG -- EU_WEST_GRA -- EU_WEST_LIM -- CA_EAST_BHS +- EU-WEST-RBX +- EU-WEST-SBG +- EU-WEST-GRA +- EU-WEST-LIM +- CA-EAST-BHS ## Go further -Join our [community of users](/links/community). +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/manage_and_operate/kms/architecture-overview/guide.fr-ca.md b/pages/manage_and_operate/kms/architecture-overview/guide.fr-ca.md index 3271ac25504..f865cf7fb6c 100644 --- a/pages/manage_and_operate/kms/architecture-overview/guide.fr-ca.md +++ b/pages/manage_and_operate/kms/architecture-overview/guide.fr-ca.md @@ -1,7 +1,7 @@ --- title: "OKMS - Aperçu de l'architecture" excerpt: "Découvrez comment nous gérons la sécurité de l'infrastructure OKMS" -updated: 2025-10-21 +updated: 2025-10-24 --- ## Objectif @@ -10,7 +10,7 @@ Ce guide explique comment nous gérons la résilience du service de gestion de c ## En pratique -L’architecture OKMS poursuit 3 objectifs principaux : +L’architecture OKMS poursuit trois objectifs principaux : - **Confidentialité** : vous assurer que personne d'autre que vous ne puisse accéder à votre clé. - **Disponibilité** : vous offrir un haut niveau de résilience et donc une haute disponibilité. @@ -18,107 +18,118 @@ L’architecture OKMS poursuit 3 objectifs principaux : ### Gestion des accès -L’accès aux clés est contrôlé par l'[IAM OVHcloud](/pages/account_and_service_management/account_information/iam-policy-ui) +L’accès aux clés est contrôlé par l'[IAM OVHcloud](/pages/account_and_service_management/account_information/iam-policy-ui). Seuls les utilisateurs autorisés par une stratégie IAM peuvent gérer les clés ou les utiliser pour chiffrer ou signer des données. Même les employés OVHcloud n’ont pas accès à vos clés. -### Architecture KMS +### Architecture OKMS -L'infrastructure OKMS est par conception répliquée sur plusieurs centres de données. +Chaque région OKMS est complètement indépendante des autres régions et utilise des ressources dédiées. -![Présentation de l'architecture](images/KMS_Overview.png){.thumbnail} +#### Régions 1-AZ + +L'architecture d'une région mono-AZ repose sur deux zones situées dans des bâtiments distincts au sein d'un ou de plusieurs centres de données d'une même région, où les serveurs sont répartis. + +Pour accroître la résilience des régions 1-AZ, un serveur de base de données réplica est déployé dans une région voisine. La réplication vers la région distante peut prendre quelques secondes de plus que la réplication vers la région principale. + +![Présentation de l'architecture](images/KMS_Overview_1AZ.png){.thumbnail} + +#### Régions 3-AZ + +Pour les régions 3-AZ, l'architecture mono-AZ est dupliquée sur les 3 zones de disponiblité. + +![Architecture overview](images/KMS_Overview_3AZ.png){.thumbnail} ### Emplacement des composants KMS Chaque région OKMS se compose de plusieurs hôtes dans une seule région OVHcloud. -Ces hôtes sont partitionnés en deux zones différentes, de sorte qu'une panne matérielle unique rendant indisponible les deux zones en même temps est aussi peu probable que possible. +Ces hôtes sont partitionnés en deux zones différentes, de sorte qu'une panne matérielle unique rendant les deux zones indisponibles en même temps est aussi peu probable que possible. #### Résilience des données - **Réplication de base de données** -Le service de gestion de clés ne renvoie pas d'état de réussite pour la création ou l'importation de matériel clé, sauf si les données ont été répliquées avec succès dans les deux zones. Cela permet de s'assurer qu'en cas de perte de l'une des bases de données, aucune clé ne sera perdue. En conséquence, si une zone devient indisponible, le KMS refusera de créer de nouvelles clés. Toutefois, les clés existantes resteront disponibles pour effectuer des opérations de chiffrement. +Le service de gestion de clés ne renvoie pas d'état de réussite pour les opérations d'écriture (par exemple, la création ou l'importation de matériel de clé), sauf si les données ont été répliquées avec succès dans au moins deux bases de données (la principale et le réplica synchrone). Cela permet de s'assurer qu'en cas de perte de l'une des bases de données, aucune donnée ne sera perdue. + +Un système d'auto-basculement est également en place pour réassigner automatiquement la base de données dans le cas où la base principale ou le réplica synchrone ne serait plus disponible. Ainsi, la perte d’une seule base de données parmi les trois n’entraîne aucune interruption de service, hormis durant la courte phase de basculement (environ une minute). -Le matériel clé est également répliqué dans une troisième base de données, dans une région différente. La réplication vers une région distante ayant une latence plus élevée, nous n'attendons pas que cette réplication soit terminée avant de renvoyer un état de réussite à l'utilisateur. La réplication vers la région distante prend généralement au maximum quelques secondes de retard par rapport à la région principale. +Néanmoins, si deux zones ou deux bases de données ne sont plus disponibles simultanément, le service OKMS bascule en mode lecture seule : toutes les opérations d’écriture (création de clés, gestion de secrets, mise à jour de métadonnées, etc.) échouent. Les clés existantes restent disponibles pour les opérations cryptographiques, et les secrets restent accessibles. - **Sauvegarde de base de données** -Des sauvegardes régulières sont effectuées à partir de la réplication toutes les 5 minutes. Chaque sauvegarde est stockée dans deux régions différentes de la région principale OKMS.
+Des sauvegardes incrémentales régulières sont effectuées toutes les 5 minutes maximum, et un backup complet est réalisé quotidiennement. Chaque sauvegarde est stockée dans deux régions différentes. Ces sauvegardes sont conservées pendant 30 jours. #### Sécurité des données -Toutes les données des clients sont toujours stockées chiffrées dans les bases de données et dans les sauvegardes. +Toutes les données des clients sont toujours stockées chiffrées dans les bases de données, et les sauvegardes sont elles-mêmes chiffrées. #### Emplacement de sauvegarde -L'emplacement de la sauvegarde dépend de l'emplacement du OKMS. - -- **EU_WEST_RBX** - - KMS Backup Region 1 : EU_WEST_SBG - - KMS Backup Region 2 : EU_WEST_GRA -- **EU_WEST_SBG** - - KMS Backup Region 1 : EU_WEST_RBX - - KMS Backup Region 2 : EU_WEST_GRA -- **EU_WEST_PAR** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_SBG -- **EU_WEST_GRA** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_RBX -- **EU_WEST_LIM** - - KMS Backup Region 1 : EU_WEST_LIM - - KMS Backup Region 2 : EU_WEST_SBG -- **EU_SOUTH_MIL** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_SBG -- **CA_EAST_BHS** - - KMS Backup Region 1 : CA_EAST_BHS - - KMS Backup Region 2 : CA_EAST_TOR -- **CA_EAST_TOR** - - KMS Backup Region 1 : CA_EAST_BHS - - KMS Backup Region 2 : CA_EAST_TOR -- **AP_SOUTHEAST_SGP** - - KMS Backup Region 1 : AP_SOUTHEAST_SGP - - KMS Backup Region 2 : AP_SOUTHEAST_SYD -- **AP_SOUTHEAST_SYD** - - KMS Backup Region 1 : AP_SOUTHEAST_SGP - - KMS Backup Region 2 : AP_SOUTHEAST_SYD - -### Scenarios d'incidents +L'emplacement de la sauvegarde dépend de l'emplacement du service OKMS. + +- **EU-WEST-RBX** + - KMS Backup Region 1 : EU-WEST-SBG + - KMS Backup Region 2 : EU-WEST-GRA +- **EU-WEST-SBG** + - KMS Backup Region 1 : EU-WEST-RBX + - KMS Backup Region 2 : EU-WEST-GRA +- **EU-WEST-PAR** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-SBG +- **EU-WEST-GRA** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-RBX +- **EU-WEST-LIM** + - KMS Backup Region 1 : EU-WEST-LIM + - KMS Backup Region 2 : EU-WEST-SBG +- **EU-SOUTH-MIL** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-SBG +- **CA-EAST-BHS** + - KMS Backup Region 1 : CA-EAST-BHS + - KMS Backup Region 2 : CA-EAST-TOR +- **CA-EAST-TOR** + - KMS Backup Region 1 : CA-EAST-BHS + - KMS Backup Region 2 : CA-EAST-TOR +- **AP-SOUTHEAST-SGP** + - KMS Backup Region 1 : AP-SOUTHEAST-SGP + - KMS Backup Region 2 : AP-SOUTHEAST-SYD +- **AP-SOUTHEAST-SYD** + - KMS Backup Region 1 : AP-SOUTHEAST-SGP + - KMS Backup Region 2 : AP-SOUTHEAST-SYD + +### Scénarios d'incidents #### Que se passe-t-il en cas de perte d’un hôte dans une zone ? -Les clés restent disponibles et le trafic est redirigé vers l’autre zone.
-Les demandes en cours de traitement peuvent expirer ou retourner des erreurs.
-Si la base de données est indisponible, le service de gestion de clés refusera de créer ou d'importer de nouvelles clés. +Les clés restent disponibles et le trafic est redirigé vers une autre zone. +Les demandes en cours de traitement peuvent expirer ou retourner des erreurs, en fonction de l'hôte affecté. #### Que se passe-t-il en cas de perte d’une zone ? -Les clés restent disponibles.
-L'autre zone reste disponible pour répondre aux requêtes des utilisateurs mais refusera de créer ou d'importer de nouvelles clés. +Les clés restent disponibles et le trafic est redirigé vers une autre zone. +Les demandes en cours de traitement peuvent expirer ou retourner des erreurs. -#### Que se passe-t-il en cas de perte de la région principale ? +#### Que se passe-t-il en cas de perte d'une région ? -Les clés créées au cours des dernières secondes peuvent être perdues et le KMS devient indisponible.
-La réplication de la base de données sera utilisée lors de la reconstruction de la région pour récupérer les clés stockées. +Les régions 3-AZ sont conçues pour pallier ce scénario, néanmoins celui-ci peut apparaître sur les régions 1-AZ. -#### Que se passe-t-il en cas de perte de la région principale et de la réplication distante ? +Dans ce cas, les clés créées au cours des dernières secondes peuvent être perdues et le service OKMS devient indisponible. -Les clés créées au cours des 5 dernières minutes peuvent être perdues et le KMS devient indisponible.
-La sauvegarde de la base de données sera utilisée lors de la reconstruction de la région pour récupérer les clés stockées. +La réplication de la base de données sera utilisée lors de la reconstruction de la région pour récupérer les clés stockées. ## Certification PCI-DSS Les régions concernées par la certification PCI-DSS sont : -- EU_WEST_RBX -- EU_WEST_SBG -- EU_WEST_GRA -- EU_WEST_LIM -- CA_EAST_BHS +- EU-WEST-RBX +- EU-WEST-SBG +- EU-WEST-GRA +- EU-WEST-LIM +- CA-EAST-BHS ## Aller plus loin diff --git a/pages/manage_and_operate/kms/architecture-overview/guide.fr-fr.md b/pages/manage_and_operate/kms/architecture-overview/guide.fr-fr.md index 3271ac25504..f865cf7fb6c 100644 --- a/pages/manage_and_operate/kms/architecture-overview/guide.fr-fr.md +++ b/pages/manage_and_operate/kms/architecture-overview/guide.fr-fr.md @@ -1,7 +1,7 @@ --- title: "OKMS - Aperçu de l'architecture" excerpt: "Découvrez comment nous gérons la sécurité de l'infrastructure OKMS" -updated: 2025-10-21 +updated: 2025-10-24 --- ## Objectif @@ -10,7 +10,7 @@ Ce guide explique comment nous gérons la résilience du service de gestion de c ## En pratique -L’architecture OKMS poursuit 3 objectifs principaux : +L’architecture OKMS poursuit trois objectifs principaux : - **Confidentialité** : vous assurer que personne d'autre que vous ne puisse accéder à votre clé. - **Disponibilité** : vous offrir un haut niveau de résilience et donc une haute disponibilité. @@ -18,107 +18,118 @@ L’architecture OKMS poursuit 3 objectifs principaux : ### Gestion des accès -L’accès aux clés est contrôlé par l'[IAM OVHcloud](/pages/account_and_service_management/account_information/iam-policy-ui) +L’accès aux clés est contrôlé par l'[IAM OVHcloud](/pages/account_and_service_management/account_information/iam-policy-ui). Seuls les utilisateurs autorisés par une stratégie IAM peuvent gérer les clés ou les utiliser pour chiffrer ou signer des données. Même les employés OVHcloud n’ont pas accès à vos clés. -### Architecture KMS +### Architecture OKMS -L'infrastructure OKMS est par conception répliquée sur plusieurs centres de données. +Chaque région OKMS est complètement indépendante des autres régions et utilise des ressources dédiées. -![Présentation de l'architecture](images/KMS_Overview.png){.thumbnail} +#### Régions 1-AZ + +L'architecture d'une région mono-AZ repose sur deux zones situées dans des bâtiments distincts au sein d'un ou de plusieurs centres de données d'une même région, où les serveurs sont répartis. + +Pour accroître la résilience des régions 1-AZ, un serveur de base de données réplica est déployé dans une région voisine. La réplication vers la région distante peut prendre quelques secondes de plus que la réplication vers la région principale. + +![Présentation de l'architecture](images/KMS_Overview_1AZ.png){.thumbnail} + +#### Régions 3-AZ + +Pour les régions 3-AZ, l'architecture mono-AZ est dupliquée sur les 3 zones de disponiblité. + +![Architecture overview](images/KMS_Overview_3AZ.png){.thumbnail} ### Emplacement des composants KMS Chaque région OKMS se compose de plusieurs hôtes dans une seule région OVHcloud. -Ces hôtes sont partitionnés en deux zones différentes, de sorte qu'une panne matérielle unique rendant indisponible les deux zones en même temps est aussi peu probable que possible. +Ces hôtes sont partitionnés en deux zones différentes, de sorte qu'une panne matérielle unique rendant les deux zones indisponibles en même temps est aussi peu probable que possible. #### Résilience des données - **Réplication de base de données** -Le service de gestion de clés ne renvoie pas d'état de réussite pour la création ou l'importation de matériel clé, sauf si les données ont été répliquées avec succès dans les deux zones. Cela permet de s'assurer qu'en cas de perte de l'une des bases de données, aucune clé ne sera perdue. En conséquence, si une zone devient indisponible, le KMS refusera de créer de nouvelles clés. Toutefois, les clés existantes resteront disponibles pour effectuer des opérations de chiffrement. +Le service de gestion de clés ne renvoie pas d'état de réussite pour les opérations d'écriture (par exemple, la création ou l'importation de matériel de clé), sauf si les données ont été répliquées avec succès dans au moins deux bases de données (la principale et le réplica synchrone). Cela permet de s'assurer qu'en cas de perte de l'une des bases de données, aucune donnée ne sera perdue. + +Un système d'auto-basculement est également en place pour réassigner automatiquement la base de données dans le cas où la base principale ou le réplica synchrone ne serait plus disponible. Ainsi, la perte d’une seule base de données parmi les trois n’entraîne aucune interruption de service, hormis durant la courte phase de basculement (environ une minute). -Le matériel clé est également répliqué dans une troisième base de données, dans une région différente. La réplication vers une région distante ayant une latence plus élevée, nous n'attendons pas que cette réplication soit terminée avant de renvoyer un état de réussite à l'utilisateur. La réplication vers la région distante prend généralement au maximum quelques secondes de retard par rapport à la région principale. +Néanmoins, si deux zones ou deux bases de données ne sont plus disponibles simultanément, le service OKMS bascule en mode lecture seule : toutes les opérations d’écriture (création de clés, gestion de secrets, mise à jour de métadonnées, etc.) échouent. Les clés existantes restent disponibles pour les opérations cryptographiques, et les secrets restent accessibles. - **Sauvegarde de base de données** -Des sauvegardes régulières sont effectuées à partir de la réplication toutes les 5 minutes. Chaque sauvegarde est stockée dans deux régions différentes de la région principale OKMS.
+Des sauvegardes incrémentales régulières sont effectuées toutes les 5 minutes maximum, et un backup complet est réalisé quotidiennement. Chaque sauvegarde est stockée dans deux régions différentes. Ces sauvegardes sont conservées pendant 30 jours. #### Sécurité des données -Toutes les données des clients sont toujours stockées chiffrées dans les bases de données et dans les sauvegardes. +Toutes les données des clients sont toujours stockées chiffrées dans les bases de données, et les sauvegardes sont elles-mêmes chiffrées. #### Emplacement de sauvegarde -L'emplacement de la sauvegarde dépend de l'emplacement du OKMS. - -- **EU_WEST_RBX** - - KMS Backup Region 1 : EU_WEST_SBG - - KMS Backup Region 2 : EU_WEST_GRA -- **EU_WEST_SBG** - - KMS Backup Region 1 : EU_WEST_RBX - - KMS Backup Region 2 : EU_WEST_GRA -- **EU_WEST_PAR** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_SBG -- **EU_WEST_GRA** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_RBX -- **EU_WEST_LIM** - - KMS Backup Region 1 : EU_WEST_LIM - - KMS Backup Region 2 : EU_WEST_SBG -- **EU_SOUTH_MIL** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_SBG -- **CA_EAST_BHS** - - KMS Backup Region 1 : CA_EAST_BHS - - KMS Backup Region 2 : CA_EAST_TOR -- **CA_EAST_TOR** - - KMS Backup Region 1 : CA_EAST_BHS - - KMS Backup Region 2 : CA_EAST_TOR -- **AP_SOUTHEAST_SGP** - - KMS Backup Region 1 : AP_SOUTHEAST_SGP - - KMS Backup Region 2 : AP_SOUTHEAST_SYD -- **AP_SOUTHEAST_SYD** - - KMS Backup Region 1 : AP_SOUTHEAST_SGP - - KMS Backup Region 2 : AP_SOUTHEAST_SYD - -### Scenarios d'incidents +L'emplacement de la sauvegarde dépend de l'emplacement du service OKMS. + +- **EU-WEST-RBX** + - KMS Backup Region 1 : EU-WEST-SBG + - KMS Backup Region 2 : EU-WEST-GRA +- **EU-WEST-SBG** + - KMS Backup Region 1 : EU-WEST-RBX + - KMS Backup Region 2 : EU-WEST-GRA +- **EU-WEST-PAR** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-SBG +- **EU-WEST-GRA** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-RBX +- **EU-WEST-LIM** + - KMS Backup Region 1 : EU-WEST-LIM + - KMS Backup Region 2 : EU-WEST-SBG +- **EU-SOUTH-MIL** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-SBG +- **CA-EAST-BHS** + - KMS Backup Region 1 : CA-EAST-BHS + - KMS Backup Region 2 : CA-EAST-TOR +- **CA-EAST-TOR** + - KMS Backup Region 1 : CA-EAST-BHS + - KMS Backup Region 2 : CA-EAST-TOR +- **AP-SOUTHEAST-SGP** + - KMS Backup Region 1 : AP-SOUTHEAST-SGP + - KMS Backup Region 2 : AP-SOUTHEAST-SYD +- **AP-SOUTHEAST-SYD** + - KMS Backup Region 1 : AP-SOUTHEAST-SGP + - KMS Backup Region 2 : AP-SOUTHEAST-SYD + +### Scénarios d'incidents #### Que se passe-t-il en cas de perte d’un hôte dans une zone ? -Les clés restent disponibles et le trafic est redirigé vers l’autre zone.
-Les demandes en cours de traitement peuvent expirer ou retourner des erreurs.
-Si la base de données est indisponible, le service de gestion de clés refusera de créer ou d'importer de nouvelles clés. +Les clés restent disponibles et le trafic est redirigé vers une autre zone. +Les demandes en cours de traitement peuvent expirer ou retourner des erreurs, en fonction de l'hôte affecté. #### Que se passe-t-il en cas de perte d’une zone ? -Les clés restent disponibles.
-L'autre zone reste disponible pour répondre aux requêtes des utilisateurs mais refusera de créer ou d'importer de nouvelles clés. +Les clés restent disponibles et le trafic est redirigé vers une autre zone. +Les demandes en cours de traitement peuvent expirer ou retourner des erreurs. -#### Que se passe-t-il en cas de perte de la région principale ? +#### Que se passe-t-il en cas de perte d'une région ? -Les clés créées au cours des dernières secondes peuvent être perdues et le KMS devient indisponible.
-La réplication de la base de données sera utilisée lors de la reconstruction de la région pour récupérer les clés stockées. +Les régions 3-AZ sont conçues pour pallier ce scénario, néanmoins celui-ci peut apparaître sur les régions 1-AZ. -#### Que se passe-t-il en cas de perte de la région principale et de la réplication distante ? +Dans ce cas, les clés créées au cours des dernières secondes peuvent être perdues et le service OKMS devient indisponible. -Les clés créées au cours des 5 dernières minutes peuvent être perdues et le KMS devient indisponible.
-La sauvegarde de la base de données sera utilisée lors de la reconstruction de la région pour récupérer les clés stockées. +La réplication de la base de données sera utilisée lors de la reconstruction de la région pour récupérer les clés stockées. ## Certification PCI-DSS Les régions concernées par la certification PCI-DSS sont : -- EU_WEST_RBX -- EU_WEST_SBG -- EU_WEST_GRA -- EU_WEST_LIM -- CA_EAST_BHS +- EU-WEST-RBX +- EU-WEST-SBG +- EU-WEST-GRA +- EU-WEST-LIM +- CA-EAST-BHS ## Aller plus loin diff --git a/pages/manage_and_operate/kms/architecture-overview/guide.it-it.md b/pages/manage_and_operate/kms/architecture-overview/guide.it-it.md index fa2bf1129e3..3e358c4491f 100644 --- a/pages/manage_and_operate/kms/architecture-overview/guide.it-it.md +++ b/pages/manage_and_operate/kms/architecture-overview/guide.it-it.md @@ -1,7 +1,7 @@ --- title: "OKMS Architecture overview" excerpt: "Discover how we handle the security of the OKMS infrastructure" -updated: 2025-10-21 +updated: 2025-10-24 --- ## Objective @@ -10,7 +10,7 @@ This guide explains how we handle the resilience of the OKMS infrastructure used ## Instructions -The OKMS architecture has 3 main objectives: +The OKMS architecture has three main objectives: - **Confidentiality**: Assure that no one except you can access your key. - **Availability**: Offering a high level of resilience and therefore high availability. @@ -23,11 +23,23 @@ Only the users allowed by an IAM policy can manage the keys or use them to encry Even the OVHcloud employees cannot access your keys. -### KMS architecture +### OKMS architecture -The OKMS infrastructure is by design replicated across multiple datacenters. +Each OKMS region is fully independent from the others and uses dedicated hosts. -![Architecture overview](images/KMS_Overview.png){.thumbnail} +#### 1-AZ regions + +The architecture of a single-AZ region is based on two zones located in distinct buildings within one or more datacenters of the same region, where the servers are spread. + +To increase resilience in 1-AZ regions, a database replica server is deployed in a distinct nearby region. Replication to the remote region may take a few seconds longer than replication to the main region. + +![Architecture overview](images/KMS_Overview_1AZ.png){.thumbnail} + +#### 3-AZ regions + +On 3-AZ regions, mono-AZ architecture is duplicated across 3 Availability Zones. + +![Architecture overview](images/KMS_Overview_3AZ.png){.thumbnail} ### KMS components location @@ -39,87 +51,85 @@ These hosts are partitioned into two different zones so that any single hardware - **DB Replication** -The KMS will not return a success status for the creation or import of key material unless that data was successfully replicated to both zones. This is to ensure that if one of the databases is lost, no key will be lost. As a consequence, if one zone becomes unavailable, the KMS will refuse to create new keys. However, existing keys will still be available to perform cryptographic operations. +The KMS will not return a success status for write operations (e.g. creation or import of key material) unless the data has been successfully replicated to at least 2 database hosts (the primary and the synchronous replica). This is to ensure that if one of the databases hosts is lost, no data will be lost. + +An auto-failover mechanism in also in place to automatically reassign the database hosts roles in case the current primary or synchronous replica becomes unavailable. This means that if any of the 3 database hosts becomes unavailable, there will be no service interruption, except during the short failover phase (approximately one minute). -The key material is also replicated to a third database, in a different region. Because replication to a remote region has a higher latency, we do not wait for that replication to be complete before returning a success status to the user. Replication to the remote region will typically lag a few seconds at most behind the main region. +However, if 2 zones or 2 databases hosts become unavailable simultaneously, the OKMS will switch to read-only mode and write operations will fail (creation of new keys, secrets management, metadata updates, etc.). Existing keys will still be available to perform any cryptographic operations, and existing secrets will remain readable. - **DB Backups** -Regular backups are taken from the replica every 5 minutes. Each backup is stored in two regions, different from the main OKMS region.
+Incremental backups are taken every 5 minutes at most, and a full backup is taken daily. Each backup is stored in two different regions. These backups are kept for 30 days. #### Data security -All customer data are always stored encrypted in the databases and in the backups. +All customer data is always stored encrypted in the databases, and the database backups themselves are encrypted. #### Backup location The backup location depends on the location of the OKMS. -- **EU_WEST_RBX** - - KMS Backup Region 1 : EU_WEST_SBG - - KMS Backup Region 2 : EU_WEST_GRA -- **EU_WEST_SBG** - - KMS Backup Region 1 : EU_WEST_RBX - - KMS Backup Region 2 : EU_WEST_GRA -- **EU_WEST_PAR** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_SBG -- **EU_WEST_GRA** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_RBX -- **EU_WEST_LIM** - - KMS Backup Region 1 : EU_WEST_LIM - - KMS Backup Region 2 : EU_WEST_SBG -- **EU_SOUTH_MIL** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_SBG -- **CA_EAST_BHS** - - KMS Backup Region 1 : CA_EAST_BHS - - KMS Backup Region 2 : CA_EAST_TOR -- **CA_EAST_TOR** - - KMS Backup Region 1 : CA_EAST_BHS - - KMS Backup Region 2 : CA_EAST_TOR -- **AP_SOUTHEAST_SGP** - - KMS Backup Region 1 : AP_SOUTHEAST_SGP - - KMS Backup Region 2 : AP_SOUTHEAST_SYD -- **AP_SOUTHEAST_SYD** - - KMS Backup Region 1 : AP_SOUTHEAST_SGP - - KMS Backup Region 2 : AP_SOUTHEAST_SYD +- **EU-WEST-RBX** + - KMS Backup Region 1 : EU-WEST-SBG + - KMS Backup Region 2 : EU-WEST-GRA +- **EU-WEST-SBG** + - KMS Backup Region 1 : EU-WEST-RBX + - KMS Backup Region 2 : EU-WEST-GRA +- **EU-WEST-PAR** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-SBG +- **EU-WEST-GRA** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-RBX +- **EU-WEST-LIM** + - KMS Backup Region 1 : EU-WEST-LIM + - KMS Backup Region 2 : EU-WEST-SBG +- **EU-SOUTH-MIL** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-SBG +- **CA-EAST-BHS** + - KMS Backup Region 1 : CA-EAST-BHS + - KMS Backup Region 2 : CA-EAST-TOR +- **CA-EAST-TOR** + - KMS Backup Region 1 : CA-EAST-BHS + - KMS Backup Region 2 : CA-EAST-TOR +- **AP-SOUTHEAST-SGP** + - KMS Backup Region 1 : AP-SOUTHEAST-SGP + - KMS Backup Region 2 : AP-SOUTHEAST-SYD +- **AP-SOUTHEAST-SYD** + - KMS Backup Region 1 : AP-SOUTHEAST-SGP + - KMS Backup Region 2 : AP-SOUTHEAST-SYD ### Disaster scenarios #### What happens if one host in a zone is lost? -Keys remain available and traffic is redirected to the other zone.
-Requests in flight can timeout or return errors.
-If the database is down, the KMS will refuse to create or import new keys. +Keys remain available and traffic is redirected to another zone. +Requests in flight can timeout or return errors, depending on which host is affected. -#### What happens if a zone is lost? +#### What happens if one zone is lost? -Keys remain available.
-The other zone stays available to serve user queries but will refuse to create or import new keys. +Keys remain available and traffic is redirected to another zone. +Requests in flight can timeout or return errors. -#### What happens if the primary region is lost? +#### What happens if a whole region is lost? -The keys created in the last seconds can be lost and the KMS becomes unavailable.
-Database replica will be used at the region and rebuilt to retrieve stored keys. +3-AZ regions are designed to prevent this scenario, however it could occur on 1-AZ regions. -#### What happens if the primary region and the remote replica are lost? - -The keys created in the last 5 minutes can be lost and the KMS becomes unavailable.
-Database backup will be used at the region and rebuilt to retrieve stored keys. +In that case, the keys created in the last seconds can be lost and the OKMS becomes unavailable. +Database replica will be used at the region and rebuilt to retrieve stored keys. ## PCI-DSS certification Regions available for PCI-DSS certification: -- EU_WEST_RBX -- EU_WEST_SBG -- EU_WEST_GRA -- EU_WEST_LIM -- CA_EAST_BHS +- EU-WEST-RBX +- EU-WEST-SBG +- EU-WEST-GRA +- EU-WEST-LIM +- CA-EAST-BHS ## Go further -Join our [community of users](/links/community). +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/manage_and_operate/kms/architecture-overview/guide.pl-pl.md b/pages/manage_and_operate/kms/architecture-overview/guide.pl-pl.md index fa2bf1129e3..3e358c4491f 100644 --- a/pages/manage_and_operate/kms/architecture-overview/guide.pl-pl.md +++ b/pages/manage_and_operate/kms/architecture-overview/guide.pl-pl.md @@ -1,7 +1,7 @@ --- title: "OKMS Architecture overview" excerpt: "Discover how we handle the security of the OKMS infrastructure" -updated: 2025-10-21 +updated: 2025-10-24 --- ## Objective @@ -10,7 +10,7 @@ This guide explains how we handle the resilience of the OKMS infrastructure used ## Instructions -The OKMS architecture has 3 main objectives: +The OKMS architecture has three main objectives: - **Confidentiality**: Assure that no one except you can access your key. - **Availability**: Offering a high level of resilience and therefore high availability. @@ -23,11 +23,23 @@ Only the users allowed by an IAM policy can manage the keys or use them to encry Even the OVHcloud employees cannot access your keys. -### KMS architecture +### OKMS architecture -The OKMS infrastructure is by design replicated across multiple datacenters. +Each OKMS region is fully independent from the others and uses dedicated hosts. -![Architecture overview](images/KMS_Overview.png){.thumbnail} +#### 1-AZ regions + +The architecture of a single-AZ region is based on two zones located in distinct buildings within one or more datacenters of the same region, where the servers are spread. + +To increase resilience in 1-AZ regions, a database replica server is deployed in a distinct nearby region. Replication to the remote region may take a few seconds longer than replication to the main region. + +![Architecture overview](images/KMS_Overview_1AZ.png){.thumbnail} + +#### 3-AZ regions + +On 3-AZ regions, mono-AZ architecture is duplicated across 3 Availability Zones. + +![Architecture overview](images/KMS_Overview_3AZ.png){.thumbnail} ### KMS components location @@ -39,87 +51,85 @@ These hosts are partitioned into two different zones so that any single hardware - **DB Replication** -The KMS will not return a success status for the creation or import of key material unless that data was successfully replicated to both zones. This is to ensure that if one of the databases is lost, no key will be lost. As a consequence, if one zone becomes unavailable, the KMS will refuse to create new keys. However, existing keys will still be available to perform cryptographic operations. +The KMS will not return a success status for write operations (e.g. creation or import of key material) unless the data has been successfully replicated to at least 2 database hosts (the primary and the synchronous replica). This is to ensure that if one of the databases hosts is lost, no data will be lost. + +An auto-failover mechanism in also in place to automatically reassign the database hosts roles in case the current primary or synchronous replica becomes unavailable. This means that if any of the 3 database hosts becomes unavailable, there will be no service interruption, except during the short failover phase (approximately one minute). -The key material is also replicated to a third database, in a different region. Because replication to a remote region has a higher latency, we do not wait for that replication to be complete before returning a success status to the user. Replication to the remote region will typically lag a few seconds at most behind the main region. +However, if 2 zones or 2 databases hosts become unavailable simultaneously, the OKMS will switch to read-only mode and write operations will fail (creation of new keys, secrets management, metadata updates, etc.). Existing keys will still be available to perform any cryptographic operations, and existing secrets will remain readable. - **DB Backups** -Regular backups are taken from the replica every 5 minutes. Each backup is stored in two regions, different from the main OKMS region.
+Incremental backups are taken every 5 minutes at most, and a full backup is taken daily. Each backup is stored in two different regions. These backups are kept for 30 days. #### Data security -All customer data are always stored encrypted in the databases and in the backups. +All customer data is always stored encrypted in the databases, and the database backups themselves are encrypted. #### Backup location The backup location depends on the location of the OKMS. -- **EU_WEST_RBX** - - KMS Backup Region 1 : EU_WEST_SBG - - KMS Backup Region 2 : EU_WEST_GRA -- **EU_WEST_SBG** - - KMS Backup Region 1 : EU_WEST_RBX - - KMS Backup Region 2 : EU_WEST_GRA -- **EU_WEST_PAR** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_SBG -- **EU_WEST_GRA** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_RBX -- **EU_WEST_LIM** - - KMS Backup Region 1 : EU_WEST_LIM - - KMS Backup Region 2 : EU_WEST_SBG -- **EU_SOUTH_MIL** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_SBG -- **CA_EAST_BHS** - - KMS Backup Region 1 : CA_EAST_BHS - - KMS Backup Region 2 : CA_EAST_TOR -- **CA_EAST_TOR** - - KMS Backup Region 1 : CA_EAST_BHS - - KMS Backup Region 2 : CA_EAST_TOR -- **AP_SOUTHEAST_SGP** - - KMS Backup Region 1 : AP_SOUTHEAST_SGP - - KMS Backup Region 2 : AP_SOUTHEAST_SYD -- **AP_SOUTHEAST_SYD** - - KMS Backup Region 1 : AP_SOUTHEAST_SGP - - KMS Backup Region 2 : AP_SOUTHEAST_SYD +- **EU-WEST-RBX** + - KMS Backup Region 1 : EU-WEST-SBG + - KMS Backup Region 2 : EU-WEST-GRA +- **EU-WEST-SBG** + - KMS Backup Region 1 : EU-WEST-RBX + - KMS Backup Region 2 : EU-WEST-GRA +- **EU-WEST-PAR** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-SBG +- **EU-WEST-GRA** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-RBX +- **EU-WEST-LIM** + - KMS Backup Region 1 : EU-WEST-LIM + - KMS Backup Region 2 : EU-WEST-SBG +- **EU-SOUTH-MIL** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-SBG +- **CA-EAST-BHS** + - KMS Backup Region 1 : CA-EAST-BHS + - KMS Backup Region 2 : CA-EAST-TOR +- **CA-EAST-TOR** + - KMS Backup Region 1 : CA-EAST-BHS + - KMS Backup Region 2 : CA-EAST-TOR +- **AP-SOUTHEAST-SGP** + - KMS Backup Region 1 : AP-SOUTHEAST-SGP + - KMS Backup Region 2 : AP-SOUTHEAST-SYD +- **AP-SOUTHEAST-SYD** + - KMS Backup Region 1 : AP-SOUTHEAST-SGP + - KMS Backup Region 2 : AP-SOUTHEAST-SYD ### Disaster scenarios #### What happens if one host in a zone is lost? -Keys remain available and traffic is redirected to the other zone.
-Requests in flight can timeout or return errors.
-If the database is down, the KMS will refuse to create or import new keys. +Keys remain available and traffic is redirected to another zone. +Requests in flight can timeout or return errors, depending on which host is affected. -#### What happens if a zone is lost? +#### What happens if one zone is lost? -Keys remain available.
-The other zone stays available to serve user queries but will refuse to create or import new keys. +Keys remain available and traffic is redirected to another zone. +Requests in flight can timeout or return errors. -#### What happens if the primary region is lost? +#### What happens if a whole region is lost? -The keys created in the last seconds can be lost and the KMS becomes unavailable.
-Database replica will be used at the region and rebuilt to retrieve stored keys. +3-AZ regions are designed to prevent this scenario, however it could occur on 1-AZ regions. -#### What happens if the primary region and the remote replica are lost? - -The keys created in the last 5 minutes can be lost and the KMS becomes unavailable.
-Database backup will be used at the region and rebuilt to retrieve stored keys. +In that case, the keys created in the last seconds can be lost and the OKMS becomes unavailable. +Database replica will be used at the region and rebuilt to retrieve stored keys. ## PCI-DSS certification Regions available for PCI-DSS certification: -- EU_WEST_RBX -- EU_WEST_SBG -- EU_WEST_GRA -- EU_WEST_LIM -- CA_EAST_BHS +- EU-WEST-RBX +- EU-WEST-SBG +- EU-WEST-GRA +- EU-WEST-LIM +- CA-EAST-BHS ## Go further -Join our [community of users](/links/community). +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/manage_and_operate/kms/architecture-overview/guide.pt-pt.md b/pages/manage_and_operate/kms/architecture-overview/guide.pt-pt.md index fa2bf1129e3..3e358c4491f 100644 --- a/pages/manage_and_operate/kms/architecture-overview/guide.pt-pt.md +++ b/pages/manage_and_operate/kms/architecture-overview/guide.pt-pt.md @@ -1,7 +1,7 @@ --- title: "OKMS Architecture overview" excerpt: "Discover how we handle the security of the OKMS infrastructure" -updated: 2025-10-21 +updated: 2025-10-24 --- ## Objective @@ -10,7 +10,7 @@ This guide explains how we handle the resilience of the OKMS infrastructure used ## Instructions -The OKMS architecture has 3 main objectives: +The OKMS architecture has three main objectives: - **Confidentiality**: Assure that no one except you can access your key. - **Availability**: Offering a high level of resilience and therefore high availability. @@ -23,11 +23,23 @@ Only the users allowed by an IAM policy can manage the keys or use them to encry Even the OVHcloud employees cannot access your keys. -### KMS architecture +### OKMS architecture -The OKMS infrastructure is by design replicated across multiple datacenters. +Each OKMS region is fully independent from the others and uses dedicated hosts. -![Architecture overview](images/KMS_Overview.png){.thumbnail} +#### 1-AZ regions + +The architecture of a single-AZ region is based on two zones located in distinct buildings within one or more datacenters of the same region, where the servers are spread. + +To increase resilience in 1-AZ regions, a database replica server is deployed in a distinct nearby region. Replication to the remote region may take a few seconds longer than replication to the main region. + +![Architecture overview](images/KMS_Overview_1AZ.png){.thumbnail} + +#### 3-AZ regions + +On 3-AZ regions, mono-AZ architecture is duplicated across 3 Availability Zones. + +![Architecture overview](images/KMS_Overview_3AZ.png){.thumbnail} ### KMS components location @@ -39,87 +51,85 @@ These hosts are partitioned into two different zones so that any single hardware - **DB Replication** -The KMS will not return a success status for the creation or import of key material unless that data was successfully replicated to both zones. This is to ensure that if one of the databases is lost, no key will be lost. As a consequence, if one zone becomes unavailable, the KMS will refuse to create new keys. However, existing keys will still be available to perform cryptographic operations. +The KMS will not return a success status for write operations (e.g. creation or import of key material) unless the data has been successfully replicated to at least 2 database hosts (the primary and the synchronous replica). This is to ensure that if one of the databases hosts is lost, no data will be lost. + +An auto-failover mechanism in also in place to automatically reassign the database hosts roles in case the current primary or synchronous replica becomes unavailable. This means that if any of the 3 database hosts becomes unavailable, there will be no service interruption, except during the short failover phase (approximately one minute). -The key material is also replicated to a third database, in a different region. Because replication to a remote region has a higher latency, we do not wait for that replication to be complete before returning a success status to the user. Replication to the remote region will typically lag a few seconds at most behind the main region. +However, if 2 zones or 2 databases hosts become unavailable simultaneously, the OKMS will switch to read-only mode and write operations will fail (creation of new keys, secrets management, metadata updates, etc.). Existing keys will still be available to perform any cryptographic operations, and existing secrets will remain readable. - **DB Backups** -Regular backups are taken from the replica every 5 minutes. Each backup is stored in two regions, different from the main OKMS region.
+Incremental backups are taken every 5 minutes at most, and a full backup is taken daily. Each backup is stored in two different regions. These backups are kept for 30 days. #### Data security -All customer data are always stored encrypted in the databases and in the backups. +All customer data is always stored encrypted in the databases, and the database backups themselves are encrypted. #### Backup location The backup location depends on the location of the OKMS. -- **EU_WEST_RBX** - - KMS Backup Region 1 : EU_WEST_SBG - - KMS Backup Region 2 : EU_WEST_GRA -- **EU_WEST_SBG** - - KMS Backup Region 1 : EU_WEST_RBX - - KMS Backup Region 2 : EU_WEST_GRA -- **EU_WEST_PAR** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_SBG -- **EU_WEST_GRA** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_RBX -- **EU_WEST_LIM** - - KMS Backup Region 1 : EU_WEST_LIM - - KMS Backup Region 2 : EU_WEST_SBG -- **EU_SOUTH_MIL** - - KMS Backup Region 1 : EU_WEST_GRA - - KMS Backup Region 2 : EU_WEST_SBG -- **CA_EAST_BHS** - - KMS Backup Region 1 : CA_EAST_BHS - - KMS Backup Region 2 : CA_EAST_TOR -- **CA_EAST_TOR** - - KMS Backup Region 1 : CA_EAST_BHS - - KMS Backup Region 2 : CA_EAST_TOR -- **AP_SOUTHEAST_SGP** - - KMS Backup Region 1 : AP_SOUTHEAST_SGP - - KMS Backup Region 2 : AP_SOUTHEAST_SYD -- **AP_SOUTHEAST_SYD** - - KMS Backup Region 1 : AP_SOUTHEAST_SGP - - KMS Backup Region 2 : AP_SOUTHEAST_SYD +- **EU-WEST-RBX** + - KMS Backup Region 1 : EU-WEST-SBG + - KMS Backup Region 2 : EU-WEST-GRA +- **EU-WEST-SBG** + - KMS Backup Region 1 : EU-WEST-RBX + - KMS Backup Region 2 : EU-WEST-GRA +- **EU-WEST-PAR** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-SBG +- **EU-WEST-GRA** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-RBX +- **EU-WEST-LIM** + - KMS Backup Region 1 : EU-WEST-LIM + - KMS Backup Region 2 : EU-WEST-SBG +- **EU-SOUTH-MIL** + - KMS Backup Region 1 : EU-WEST-GRA + - KMS Backup Region 2 : EU-WEST-SBG +- **CA-EAST-BHS** + - KMS Backup Region 1 : CA-EAST-BHS + - KMS Backup Region 2 : CA-EAST-TOR +- **CA-EAST-TOR** + - KMS Backup Region 1 : CA-EAST-BHS + - KMS Backup Region 2 : CA-EAST-TOR +- **AP-SOUTHEAST-SGP** + - KMS Backup Region 1 : AP-SOUTHEAST-SGP + - KMS Backup Region 2 : AP-SOUTHEAST-SYD +- **AP-SOUTHEAST-SYD** + - KMS Backup Region 1 : AP-SOUTHEAST-SGP + - KMS Backup Region 2 : AP-SOUTHEAST-SYD ### Disaster scenarios #### What happens if one host in a zone is lost? -Keys remain available and traffic is redirected to the other zone.
-Requests in flight can timeout or return errors.
-If the database is down, the KMS will refuse to create or import new keys. +Keys remain available and traffic is redirected to another zone. +Requests in flight can timeout or return errors, depending on which host is affected. -#### What happens if a zone is lost? +#### What happens if one zone is lost? -Keys remain available.
-The other zone stays available to serve user queries but will refuse to create or import new keys. +Keys remain available and traffic is redirected to another zone. +Requests in flight can timeout or return errors. -#### What happens if the primary region is lost? +#### What happens if a whole region is lost? -The keys created in the last seconds can be lost and the KMS becomes unavailable.
-Database replica will be used at the region and rebuilt to retrieve stored keys. +3-AZ regions are designed to prevent this scenario, however it could occur on 1-AZ regions. -#### What happens if the primary region and the remote replica are lost? - -The keys created in the last 5 minutes can be lost and the KMS becomes unavailable.
-Database backup will be used at the region and rebuilt to retrieve stored keys. +In that case, the keys created in the last seconds can be lost and the OKMS becomes unavailable. +Database replica will be used at the region and rebuilt to retrieve stored keys. ## PCI-DSS certification Regions available for PCI-DSS certification: -- EU_WEST_RBX -- EU_WEST_SBG -- EU_WEST_GRA -- EU_WEST_LIM -- CA_EAST_BHS +- EU-WEST-RBX +- EU-WEST-SBG +- EU-WEST-GRA +- EU-WEST-LIM +- CA-EAST-BHS ## Go further -Join our [community of users](/links/community). +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/manage_and_operate/kms/architecture-overview/images/KMS_Overview.png b/pages/manage_and_operate/kms/architecture-overview/images/KMS_Overview.png deleted file mode 100644 index 214a07ca5f9..00000000000 Binary files a/pages/manage_and_operate/kms/architecture-overview/images/KMS_Overview.png and /dev/null differ diff --git a/pages/manage_and_operate/kms/architecture-overview/images/KMS_Overview_1AZ.png b/pages/manage_and_operate/kms/architecture-overview/images/KMS_Overview_1AZ.png new file mode 100644 index 00000000000..c8f5a800dd1 Binary files /dev/null and b/pages/manage_and_operate/kms/architecture-overview/images/KMS_Overview_1AZ.png differ diff --git a/pages/manage_and_operate/kms/architecture-overview/images/KMS_Overview_3AZ.png b/pages/manage_and_operate/kms/architecture-overview/images/KMS_Overview_3AZ.png new file mode 100644 index 00000000000..2a4ea302ee6 Binary files /dev/null and b/pages/manage_and_operate/kms/architecture-overview/images/KMS_Overview_3AZ.png differ