by Michael Schulte ([email protected])
This documents describes detailed aspects of the implementation of the EU-digital-green-certificates Gateway. It is closely related to the document trust-framework_interoperability_certificates , to which describes the overarching framework and structure. The European Digital Green Certificate Gateway defines the gateway structure defines the high level architecture.
Target audience for this document are software engineers who want to get a better understanding of the insight of the implementation to be able to contribute.
This document is not finished, feedback is welcome and will change its content.
The Digital Green Certificate Gateway (DGCG) has the purpose to support the EU trust framework. It provides the operability to securely share validation and verification across the connected national backends. With the usage of DGCG Each national backend is free to distribute the keys via any preferred technology to support the national verification devices in the best way. If the Digital Green Certificate is in a correctly formatted 2D code, each verifier device can verify each code from other countries, if the verifier is connected to the backend (online verification) or if it has downloaded and stored the necessary public keys beforehand (offline verification).
| Entity | Definition |
|---|---|
| trusted_party | stores the certificate for the trusted parties |
| signer_information | stores the certificate for the signer |
| audit_event | stores all events happening in the system |
The diagram below shows the api endpoints from the DGC Gateway and the dataflow from and to national backends.
National Health Authorities acting the certificate management process.
This is a condesed overview of the comminication of the DGCG
The triangle of trust is the blueprint for Green Certificate interoperability:
-Holder: A Green Certificate (DGC) owner (i.e., a citizen with a vaccination, negative PCR test result, or positive
anti-body test result)—note that the Green Certificate can be held digitally within a wallet app or on paper (or both)
-Issuer: A national authority
-Verifier: An offline/online verifier (e.g., customs officers, police, or hotel staff)
How does the verifier know which issuer is trustworthy? In a personal relationship, one would decide by experience. In
this architecture, the DGCG tells the verifier which issuers are trustworthy by providing cryptographically anchored
information.
Exactly how each national app communicates with the corresponding national backend -whether via CDN, active push, or
otherwise - is left to each country. Important here is the cryptographically secured E2E protection between the member
states.
- Device-to-device communication is built on a standardized 2D code and verifier format defined by the EU Trust Framework.
- A direct backend-to-backend communication is not necessary, because the main purpose of the DGCG solution is to provide verification information.
To ensure that just data from trusted parties are accepted. The system contains a trust list which is signed entry by
entry air gapped by an official signer. This signer, signs with his private key each request of onboarding and provides
this signed information to the DGCG operator which can set this entry on the trust list. This guarantees that no
external attacker or another party than the trusted signer can create valid records for the trust list. The public key
of the trusted signer is shared out of band to the other parties, to establish an effective trust anchoring.
DGCG provides a simple REST API with common upload and download functionality for trusted information.
The are described further with a OpenAPI doc and in the
document European Digital Green Certificate Gateway
###Trusted Party Table
| Field | Description | Data Type |
|---|---|---|
| Id | Primary key | Long |
| Timestamp | Timestamp of the Record | Timestamp |
| Country | Country Code | varchar(2) |
| Sha256Fingerprint | SHA256-fingerprint of the certificate | varchar(*) |
| Certificate Type | Type of the certificate (Authentication, Signing, Issuer, Client, CSCA) | varchar(*) |
| RawData | Raw Data of the certificate | binary |
| Signature | Signature of the Trust Anchor | varchar(*) |
| The cerificate type is one of the following |
- Authentication Certificate which the member state is using to authenticate at DGCG (NBTLS)
- Upload Certificate which the member state is using to sign the uploaded information’s (NBUS)
- CSCA Country Signing Certificate Authority certificate (NBCSCA)
###Signer Information Table
| Field | Description | Data Type |
|---|---|---|
| Id | Primary key | Long |
| Timestamp | Timestamp of the Record | Timestamp |
| Country | Country Code | varchar(2) |
| Sha256Fingerprint | SHA256-fingerprint of the certificate | varchar(*) |
| Certificate Type | Type of the certificate (Authentication, Signing, Issuer, Client, CSCA) | varchar(*) |
| RawData | Raw Data of the certificate | binary |
| Signature | Signature of the Trust Anchor | varchar(*) |
| The cerificate type is one of the following |
-
DSC Certificate which the member state is using to sign documents (NBDSC) ###Audit Event Table
Field Description Data Type | | Id | Primary key | Long | | Timestamp | Timestamp of the Record | Timestamp | | Country | Country Code | varchar(2) | | Uploader Sha256Fingerprint | SHA256-fingerprint of the certificate | varchar() | | Authentication Sha256Fingerprint | SHA256-fingerprint of the certificate | varchar() | | Event | Event which occurs | binary| | Description | Description of the Event | varchar(*) | The Rights on the table are restricted to insert only for the application user to restrict manipulation of the audit events. The following table will contain all Audit Events. It is currently under implementation, so the list will be filled after.
| Event | Description |
|---|---|
| EventID | Description |
###Problem Report This is a List of all Possible Problem Reports that can be returned.
| Code | Problem | Send Value | Details |
|---|---|---|---|
| 0x001 | Validation Error | Not Available | Contains the exception message |
| 0x002 | You cant upload an existing certificate. | Parameters send in the request | Contains the exception message |
| 0x003 | Upload of Signer Certificate failed | Parameters send in the request | Contains the exception message |
| 0x004 | Possible reasons: Wrong Format no CMS, not the correct signing alg missing attributes, invalid signature, certificate not signed by known CA | Parameters send in the request | Contains the exception message |
| 0x005 | The certificate doesn't exists in the database | Parameters send in the request | Contains the exception message |
| 0x006 | Upload of Signer Certificate failed | Parameters send in the request | Contains the exception message |
| 0x007 | Possible reasons: Wrong Format no CMS, not the correct signing alg missing attributes, invalid signature, certificate not signed by known CA | Parameters send in the request | Contains the exception message |
| 0x008 | Internal Server Error | Not Available | Not Available |
| 0x100 | Valueset not found | The requested valueset ID | Not available |
| 0x200 | Invalid JSON | Not Available | Detailed JSON Parse Error Report |
| 0x210 | Invalid Country sent | Not Available | Detailed information which field is invalid |
| 0x220 | Invalid Version | Not Available | Detailed information what is wrong about the provided version |
| 0x230 | Invalid Upload Cert | Upload Cert Subject | Hash of Upload Cert and authenticated Country Code |
| 0x240 | Invalid Timestamp(s) | Not available | Detailed information which timestamp is wrong and what is expected |
| 0x250 | Invalid Rule ID | Not available | Detailed information what is wrong with the used Rule ID |
| 0x260 | CMS Signature is Invalid | Not available | Details about expected CMS |
| 0x270 | Validation Rule does not exist | Requested ValidationRule ID | You can only delete existing rules. |
| 0x299 | Unexpected Error | Not available | Ask Support for help |
The purpose of the audit logging is to track the usage of the system. The audit events will be additionally logged into the application log.
The target environment for this service is an Apache Tomcat Server. So all log output will be written to stdout
which is redirected to catalina.out log file. So the content of this file needs to be collected by the Ops team.
All log messages are following one format. The log format is inspired by the Splunk best practices document (link)
Each log message contains key value pairs which will represent the required data. All of these log messages are consisting of mandatory and additional fields. The mandatory fields are always at the beginning of a log message. The key value pairs are connected by a "=" and seperated by "," followed by a space. If the value consists of more than one word, the value will be wrapped within double quotes. Multiple log messages are seperated by a new line. The following mandatory fields will be sent with each log message:
| Field | Content | Example Value |
|---|---|---|
| timestamp | ISO-8601 formatted timestamp (always UTC) | 2020-08-04T16:44:45.999Z |
| level | Log Level | INFO |
| hostname | The hostname of the current node | srv01 |
| pid | Process ID | 44929 |
| traceId | Correlation ID for tracing | d058309145b9f7a3 |
| spanId | Span ID for tracing | d058309145b9f7a3 |
| thread | ID of the thread | main |
| class | The class from which the message is coming from | e.i.f.service.SignerInformationService |
| message | Information about what has happened | Uploaded certificate already exist |
| exception | Stack Trace, if available | org.springframew... |
Example:
timestamp="2020-08-04 17:19:46.038", level=INFO, pid=44929, traceId=e7d394f3b0431c68, spanId=e7d394f3b0431c68, thread=scheduling-1, class=e.i.f.service.SignerInformationService, message="Uploaded certificate already exist", exception=""
*exception field will only be written to log file. In console stack traces will be printed directly.
These key-value-pairs can be followed by additional attributes. The additional attributes are individual for each log message.
| Event | Log Level | Log Message | Additional attributes |
|---|---|---|---|
| Authentication | |||
| Authentication failed, no thumbprint or distinguish name provided | ERROR | No thumbprint or distinguish name | n/a |
| Authentication failed, country property not present in distinguish name | ERROR | Country property is missing | dnString, thumbprint |
| Authentication failed, client has used unkown cert for authentication | ERROR | Unknown client certificate | dnString, thumbprint |
| Authentication failed, normalization of hash failed (load balancer config error) | ERROR | Could not normalize certificate hash. | |
| Successful Authentication | INFO | Successful Authentication | dnString, thumbprint |
| Certificate Integrity Check | |||
| Certificate integrity check failed: Calculated thumbprint does not match stored thumbprint in database. (data manipulation!) | ERROR | Thumbprint in database does not match thumbprint of stored certificate. | certVerifyThumbprint |
| Certificate integrity check failed: Certificate signature is not issued by TrustAnchor or signature is corrupted (data manipulation!) | ERROR | Verification of certificate signature failed! | certVerifyThumbprint |
| Certificate integrity check failed: Certificate entity does not contain raw certificate or certificate signature. (Onboarding failure) | ERROR | Certificate entity does not contain raw certificate or certificate signature. | certVerifyThumbprint |
| Certificate integrity check failed: Raw certificate data does not contain a valid x509Certificate. (parsing error) | ERROR | Raw certificate data does not contain a valid x509Certificate. | certVerifyThumbprint, exception |
| Certificate integrity check failed: Could not load DGCG-TrustAnchor from KeyStore. (initialization error) | ERROR | Could not load DGCG-TrustAnchor from KeyStore. | certVerifyThumbprint |
| Certificate integrity check failed: Could not use public key to initialize verifier. (initialization error) | ERROR | Could not use public key to initialize verifier. | certVerifyThumbprint |
| Certificate integrity check failed: Signature verifier is not initialized (initialization error) | ERROR | Signature verifier is not initialized | certVerifyThumbprint |
| Certificate integrity check failed: Unknown signing algorithm used by DGCG Trust Anchor. (initialization error) | ERROR | Unknown signing algorithm used by EFGS Trust Anchor. | certVerifyThumbprint |
| Certificate integrity check failed: Parsing of signature results in error. See Parser State for more information. | ERROR | TrustAnchor Verification failed. | parserState |
| Certificate integrity check failed: Parsing of signature results in error. Signature of CMS is not matching contained certificate (data manipulation!) | ERROR | TrustAnchor Verification failed: Signature is not matching signed certificate | certVerifyThumbprint |
| Certificate integrity check failed: Parsing of signature results in error. Certificate is signed but not by TrustAnchor (data manipulation!) | ERROR | TrustAnchor Verification failed: Certificate was not signed by known TrustAnchor | certVerifyThumbprint |
| Certificate Upload Check | |||
| Verifier for certificate could not be instantiated. | ERROR | Failed to instantiate JcaContentVerifierProvider from cert | certHash |
| Certificate Issuer Check has failed | ERROR | Could not verify certificate issuance. | exception |
| Check of uploaded certificate has failed when revoking a certificate | ERROR | Verification certificate delete failed | verificationFailureReason, verificationFailureMessage |
| Check of uploaded certificate has failed when uploading a certificate | ERROR | Verification certificate upload failed | verificationFailureReason, verificationFailureReasonMessage |
| Revoking Certificate | INFO | Revoking verification certificate | signerCertSubject, payloadCertSubject |
| Uploading Certificate | INFO | Uploading new verification certificate | signerCertSubject, payloadCertSubject |
| Saving Certificate into DB (All checks passed) | INFO | Saving new SignerInformation Entity | uploadCertThumbprint, cscaCertThumbprint |
| Revoking Certificate from DB (All checks passed) | INFO | Revoking SignerInformation Entity | uploadCertThumbprint |
| Audit Service | |||
| Created new AuditEvent (id = event type) | INFO | Created AuditEvent | auditId, country |
| General | |||
| Uncaught Exception was thrown in DGCG | ERROR | Uncaught exception | exception |
| Download Interface | |||
| Trust List was downloaded by a country | INFO | Downloaded TrustList | downloadedKeys (Number of Keys), downloadedKeysCountry (Downloader Country), downloadedKeysType (optional) |
| Validation Rule | |||
| A Member State is trying to upload a new ValidationRule | INFO | Rule Upload Request | n/a |
| Upload of ValidationRule failed | ERROR | Rule Upload Failed | validationRuleUploadError, validationRuleUploadReason |
| A Member State has uploaded a new ValidationRule | INFO | Rule Upload Success | n/a |
| A Member State is trying to delete a ValidationRule | INFO | Rule Delete Request | n/a |
| A Member State has deleted ValidationRules | INFO | Rule Delete Success | validationDeleteAmount, validationDownloadId |
| A Member State is downloading ValidationRules | INFO | Rule Download Request | n/a |
| A Member State has downloaded ValidationRules | INFO | Rule Download Success | validationDownloadAmount, validationDownloadRequester, validationDownloadRequested |
The load balancer terminates TLS, executes the mutual TLS authentication and forwards the http request to a worker node.
The IP of the load balancer is assigned to registered domain name.
To allow authentication of the http request the load balancer adds header attributes containing meta information about the client certificate used to authenticate the request.
The reverse proxy distributes load over the tomcat instances. The main purpose for EDGCGS is to provide fail over behavior in case a tomcat instance is not available anymore.
The database is implemented as mySQL 5.7
Environment specific secrets are managed as part of the tomcat configuration. JDBC connections are provided as tomcat resources.
In this section, we define the security concept and security requirements for the DGCG Gateway. The meaning of the words "MUST", "MAY", and "SHOULD" is defined in RFC 2119. To each requirement, an identifier, in the format "SecReq-{Number}", is assigned.
Client: It refers to a National Backend ( see DGCG Gateway Architecture Specification) that uploads or downloads to/from the DGCG Gateway. In the section "Client Authentication", Client and National Backend are used interchangeably.
DGCG Gateway Components
-
Load Balancer: The component that receives the clients' requests (e.g., signerCertificate , trustList or audit) and forwards them to the DGCG Gateway Service after successful execution of the TLS protocol.
-
Service: The component that processes the clients' requests (e.g., signerCertificate , trustList or audit) after successful client authentication.
-
Database: The component where the information (e.g., thumbprint) of the clients' certificates is stored.
Certificates
- Authentication Certificate which the member state is using to authenticate at DGCG (NBTLS)
- Upload Certificate which the member state is using to sign the uploaded information’s (NBUS)
- CSCA Country Signing Certificate Authority certificate (NBCSCA)
- DSC Certificate which the member state is using to sign documents (NBDSC)
Batch Signature: A PKCS#7 object containing, among others, the signature of a diagnosis key batch and the Signing Certificate.
Client Authentication: The process in which a Client is authenticated (using its Authentication Certificate) and authorized to request signerCertificate , trustList or audit.
Certificate Thumbprint/Fingerprint: Hash value of a certificate. We have defined the SHA-256 hash function for calculation of the fingerprint. In this document, certificate hash, certificate fingerprint, and certificate thumbprint are used interchangeably.
##Client Authentication
As shown in the figure below, the Ditital Green Certificate Gateway Load Balancer authenticates the Clients (National Databases) via mTLS. Then, the clients' requests are forwarded to the DGCG , which validates the Client Authentication Certificate against a whitelist stored in the database. Once the certificate has been successfully verified, the DGCG passes the requests to the corresponding endpoints (e.g., signerCertificate , trustList or audit).
SecReq-001 All the clients' requests (e.g., upload diagnostic key batch) MUST be authenticated.
###Load Balancer
SecReq-002 The Load Balancer MUST perform mutual TLS (mTLS) with the clients (national backends).
SecReq-003 The Load Balancer MUST implement TLS termination.
####Certificate Validation
SecReq-004 If the client's certificate is not sent during the TLS handshake protocol, the Load Balancer MUST reject the client's request.
SecReq-005 If the client's certificate has expired, the Load Balancer MUST reject the client's request. The expiration is determined by the “notAfter” field (see RFC 5280) of the certificate.
SecReq-006 The Load Balancer MUST maintain a bundle containing the root CA certificates or intermediate CA certificates needed to verify (trust) the clients' authentication certificates. If a national backend uses a self-signed client authentication certificate, this certificate MUST be added to the CA bundle.
SecReq-007 The Load Balancer MUST validate the client's certificate chain using its CA bundle (SecReq-006). If validation fails, the Load Balancer MUST reject the client's request.
SecReq-008 The Load Balancer MAY maintain a Certificate Revocation List (CRL) ( see RFC 5280).
SecReq-009 If SecReq-008 is fulfilled, the Load Balancer MUST reject a request, if the client's certificate is present in the CRL.
####Request Forwarding
SecReq-010 If the client's certificate was successfully validated, the Load Balancer MUST forward the corresponding request to the DGCG Service via HTTP.
SecReq-011 When a client's request is forwarded to the DGCG Service (See SecReq-010), the Load Balancer MUST add the following HTTP headers to the request:
| HTTP Header | Description |
|---|---|
| X-SSL-Client-SHA256 | SHA-256 hash value of the DER encoded client's certificate. The so-called certificate fingerprint or thumbprint. (base64 encoded bytes, not base64 encoded hexadecimal string representation) |
| X-SSL-Client-DN | The subject Distinguished Name (DN) of the client's certificate (see RFC 5280 and RFC 1719). The DN MUST contain the Country (C) attribute. (it is possible to transmit DN string URL encoded) |
###Ditital Green Certificate Gateway Service
SecReq-012 The Ditital Green Certificate Gateway (DGCG) Service MUST authenticate the clients' requests using the information sent in the HTTP requests (see SecReq-011) and the certificate information stored in the DGCG Database.
SecReq-013 To authenticate a client, the DGCG Service MUST perform the following steps:
-
Extract the value of the X-SSL-Client-SHA256 and X-SSL-Client-DN headers from the HTTP request forwarded by the Load Balancer (see SecReq-011).
-
Extract the Country (C) attribute from the X-SSL-Client-DN value.
-
Query the DGCG Database using the X-SSL-Client-SHA256 value and the Country (C) attribute. Also, the certificate type (see SecReq-019) MUST be used in the query. In this case, the type is: AUTHENTICATION.
-
If the query does not return any record, the DGCG Service MUST reject the client's request.
-
If the query returns a record, the DGCG Service MUST check whether the certificate has not been revoked. If the certificate was already revoked, the DGCG Service MUST reject the request. Otherwise continue with step 4.
-
-
If the client’s request was authenticated successfully, the DGCG Service MUST forward the request to the corresponding endpoint (e.g., download or upload endpoint).
####Logging
SecReq-014 The DGCG Service MUST log each authentication attempt using the information of the X-SSL-Client-DN header.
SecReq-015 The DGCG Service MUST use the log format defined by the Cyber Defense Center (CDC) TODO:TBD.
###Storing Secrets The service has two secrets which need special handling during storage
- private key of DGCGTLS for outgoing TLS connections (for call back), to allow mTLS authentication
- public key of DGCGTA Trust Anchor
These keys need to be stored seperate from the database. They are stored in two different Java KeyStore (https://en.wikipedia.org/wiki/Java_KeyStore) and deployed manually to the Tomcat instances. The keystores are protected with a password, the password is set as JVM property.
Note that the onboarding process is not part of the DGCG Gateway (software). It is included here to inform the future operators of the EDGCGS and the operators of the member-states of key technical steps. The entire onboarding process will be defined separately as part of the overall e-Health network process.
SecReq-023 The Ditital Green Certificate Gateway (DGCG) upload endpoint MUST validate the Signing Certificate, which is sent in the PKCS#7 object (see SecReq-017), based on the requirements specified below. The file format is PKCS#12 (pfx) with a password. The password is communicated by to the DGCG by the Designated Country Technical Contact ( DCTC) during a verification call where the DGCG contacts the DCTC to verify the authenticity of the upload and get the password.
SecReq-### The Relative Distinguished Name(RDN) 'C' in the Distinguished Name (DN) must match the country of the the Country.
SecReq-### The RDN 'emailAddress' in the Distinguished Name (DN) must match the 24x7 email address of the Country.
SecReq-### The RNDs CN, O and (optional OU) should be populated with a set of human readable and operationally correct set of values. Such as '/CN=DGCGS Netherlands/OU=National Health Institute/O=Ministry of Public Health/C=NL'.
SecReq-### The PKCS#12 (pfx) Should contain the complete chain, where applicable.
SecReq-### If the Signing Certificate should be valid for at least 3 (more) month. The expiration is determined by the "notAfter" field (see RFC 5280) of the certificate.
SecReq-### The DGCG upload endpoint MUST verify the signature of the Signing Certificate. If validation failed, the DGCG upload endpoint MUST abort Onboarding..
SecReq-### In order to ensure maximum interoperability in a short timeline fields such as the Key Usage, Extended Key Usage will be operationally ignored.
SecReq-### The X.509 certificate will be of version X.509 v3 (RFC5280).
SecReq-### The key-lengths will meet or exceed the BSI Recommendations(2020) and the ECRYPT-CSA Recommendations(
- for near term production: 3072 bits (RSA) or 256 bits (EC) and SHA256.
-Digital Green Certificate Gateway (DGCG) upload endpoint MUST validate the Signing Certificate.
SecReq-### If the Signing Certificate has expired, the DGCG upload endpoint MUST reject the upload request. The expiration is determined by the "notAfter" field (see RFC 5280) of the certificate.
SecReq-### The DGCG upload endpoint MUST verify the signature of the Signing Certificate. If validation failed, the DGCG upload endpoint MUST reject the upload request.
SecReq-026 To verify whether a Signing Certificate is whitelisted, the DGCG upload endpoint MUST execute the next steps:
-
Extract the Origin value from the
-
Extract the Country (C) attribute from the X-SSL-Client-DN request header (see SecReq-011).
-
Compare the Origin with the Country.
- If the Origin is not equal to Country, the upload endpoint MUST reject the signature, and thus, reject the upload request. Otherwise, continue with step 4.
-
Extract the signing certificate (DER encoded) from the PKCS#7 object.
-
Calculate the SHA-256 value of the extracted signing certificate.
-
Query the DGCG Database using the calculated SHA-256 value and the Country (C) attribute. Also, the certificate type (see SecReq-028) MUST be used in the query. In this case, the type is: SIGNING.
-
If the query does not return any record, the upload endpoint MUST reject the signature, and thus, reject the upload request.
-
If the query returns a record, the upload endpoint MUST verify that the certificate has not been revoked. If the certificate was already revoked, the upload endpoint MUST reject the signature, and thus, reject the upload request.
-
SecReq-033 All certificates MUST be complied with the X.509 version 3 certificate standard ( see RFC 5280).
SecReq-034 All certificates MUST contain a Distinguished Name (DN) in the subject field.
SecReq-035 The Distinguished Name (DN) MUST have the Country (C) attribute, containing the country code (e.g., NL) of the National Backend.
-The Signing Certificates, which are used to verify the batch signature, CAN be self-signed. (this subject is likely to change)
SecReq-037 The Signing Certificates SHOULD set the Key Usage extension to "digitalSignature" ( see RFC 5280).
-The Authentication Certificates, which are used to authenticate the National Backends, SHOULD set the Key Extended Usage extension to "clientAuth" (see RFC 5280).
###Cryptographic Requirements
SecReq-042 The cryptographic operations performed with the National Backends certificates MUST fulfill the following requirements:
| Signature Algorithm | Minimum Key Length | Hash Algorithm |
|---|---|---|
| RSA | 2024 | SHA-256 SHA-384 SHA-512 |
| ECDSA | 250 | SHA-256 SHA-384 SHA-512 |
The above requirements were defined based on the BSI recommendations for cryptographic algorithms and key lengths.
The system contains different stages which reflect the different perspectives to the deployed software.
Stages:
- DEV
- TEST
- ACC
- PROD
This view is a generic view which outlines the structure, but does not contain any specifics related to a stage.
Tomcat hosting service – tomcat instances that are controlled together. Deployment is performed using Nexus artefact repository. We confirmed in the meantime that the rolling upgrade is possible, but we still need to analyse the requirements against the service capabilities
- Tomcat version: Tomcat 9.0.37
- JDK version : JDK 11 (OpenJDK)
- Heap Size (MB): 8GB
- Meta Space Size (MB): dynamic/default (currently we are not able to specify this)
- Direct Memory Size (MB): default (currently we are not able to specify this)
MySQL – Supported version: 5.7
- Required information to create the instance
- Character Set : utf8|latin1|utf16|utf32|other>: utf8
- Estimated DB Size: 10 GB
- Required capacity of the VM (GB of memory and number of vCPU) - 4 cores 16 GB RAM
- Number of concurrent users: 1 User for the application with max 28 sessions to store data
As per beginning of the project a dev environment exists in the OTC allowing quick and easy access for developer.
Scaling Level
- single worker node
Security Level
- full security
Test Data
- has a number of countries preloaded
Proposal
- Worker Nodes 3x [4 x Cores, 16 GB RAM, 10 GB free Storage]
- Database equivalent to 2x [4 Cores and 16 GB RAM]
Scaling Level
- fully scaled
Security Level
- full security
Test Data
- has a number of countries preloaded
Proposal
- Worker Nodes 3x [4 x Cores, 16 GB RAM, 10 GB free Storage]
- Database equivalent to 2x [4 Cores and 16 GB RAM]
Proposal
- Worker Nodes 3x [4 x Cores, 16 GB RAM, 10 GB free Storage]
- Database equivalent to 2x [4 Cores and 16 GB RAM]
The data base stores
Timezone all times and dates are interpreted as timestamps in UTC (https://en.wikipedia.org/wiki/Coordinated_Universal_Time)