Skip to content

Security Mechanisms

This section describes the main security mechanisms implemented in VeriSaaS Cloud. They apply to the services delivered from both cloud providers.

TLS 1.2/1.3 protocol

All communications to VeriSaaS APIs must use HTTPS with TLS 1.2 or TLS 1.3. Lower versions of the protocol are not allowed. TLS 1.3 is currently the latest standard for secure HTTP communications.

Supported cipher suites:

  • ECDHE-ECDSA-AES128-GCM-SHA256
  • ECDHE-RSA-AES128-GCM-SHA256
  • ECDHE-ECDSA-AES256-GCM-SHA384
  • ECDHE-RSA-AES256-GCM-SHA384
  • TLS-AES-128-GCM-SHA256
  • TLS-AES-256-GCM-SHA384
  • TLS-CHACHA20-POLY1305-SHA256

SSL Certificates

When connecting to VeriSaaS Cloud, traffic is encrypted with a valid certificate issued by a publicly trusted certificate authority and renewed automatically. Customers should only trust a valid certificate whose name matches the VeriSaaS Cloud URL they connect to.

Certificate pinning is not a recommended practice, because certificates are renewed periodically. If you require it, please contact Veridas Customer Support before implementing it.

IP Source AllowList

As shown in the architecture diagram, all requests to VeriSaaS Cloud must originate at a customer's middleware. Veridas Customer Support requires at least one public IP address for the provisioning of a LIVE account, as this is a mandatory requirement for operating the service.

Once the LIVE account for a VeriSaaS service is delivered, the customer can manage the AllowList associated to that service account using the Keymaker API service.

The AllowList can also be modified by reaching out to Veridas Service Desk (service SLA = 48-72h).

All requests coming from an unregistered source IP are automatically discarded by VeriSaaS Cloud.

IP source AllowList is a mandatory requirement for all Veridas customers.

WAF

All incoming traffic to VeriSaaS Cloud is first analyzed by a Web Application Firewall (WAF). A WAF is a firewall for web applications that filters common attacks, such as SQL injection or path traversal. In addition, VeriSaaS Cloud includes DDoS protection, not only at layer 7 but also at layers 3 and 4, to prevent attacks that could end up in a denial of service.

The Veridas WAF also silently drops every incoming request that is not valid, has a malformed syntax or comes from a suspicious source network. This protects VeriSaaS Cloud from undesired traffic that would only increase the load on its resources.

API Key authentication

For a customer request to access a service, in addition to the previous requirements, it must be authenticated with an apikey header containing the corresponding customer credential. Veridas Customer Support provides the API key when the service is delivered. The customer's middleware must add this header to all requests to the Veridas API.

We strongly recommend that customers rotate the API key before using it in a production environment. This can be done with the Keymaker API service.

Authentication is performed by the Veridas API manager. Requests with a wrong API key are rejected.

API key header example:

apikey: <YOUR_API_KEY>

API keys are passwords randomly generated by VeriSaaS, with a minimum length of 32 characters, containing uppercase letters, lowercase letters and numbers.

Request Throttling & Rate Limiting

To avoid problems caused by an accidental increase of traffic, which may later lead to high costs for customers, all customer cloud accounts are set up with a maximum number of requests per minute. This limit is high enough not to affect any normal operation. However, if for instance a process in the customer's middleware hangs, VeriSaaS Cloud could receive an unusually high amount of traffic. To avoid these situations, we implemented a request throttling mechanism that monitors the workload received by each cloud service and artificially delays the excess queries instead of dropping them.

In these circumstances, the Veridas operations team will inform the customer so that proper action is taken. We also recommend that customers notify Veridas Service Desk in advance of any unusual traffic expected to reach VeriSaaS Cloud, so that we can proactively take any measure required to ensure the best service.

If a customer plans to perform a stress or performance test against VeriSaaS Cloud, it is important to inform Veridas Customer Support beforehand. Otherwise, the test might be treated as a DDoS attack and blocked.

Continuous monitoring

VeriSaaS Cloud services and infrastructure are continuously monitored with a combination of cloud-native and specialized observability tools, covering metrics, logs and traces, in order to detect any problem that could affect the service.

An alerting system notifies the Veridas support team whenever a problem arises, so they can react as quickly as possible. See Observability & Operations.

Validations Auto-Cleaner

Services such as das-Face (face biometrics engine) or das-Peak (voice biometrics engine) are completely stateless: each query is independent of the rest, and no data is stored in the cloud after processing.

Validas, on the other hand, is a stateful service, because a validation process may require several queries to VeriSaaS Cloud (for example: upload obverse, upload reverse, upload selfie). Validas therefore uses an operational database to temporarily keep the validation data until it is processed, downloaded and deleted by the customer. If a validation is not deleted by the customer, Veridas deletes it by means of an auto-cleaner process.

The Validations Auto-Cleaner deletes all validations that reach the established expiration time. This expiration time can be customized for each customer and is usually lower than 30-60 minutes. See Data handling for the optional storage of validations.

Data Encryption

VeriSaaS Cloud encrypts data both in transit and at rest:

  • In transit: all traffic between customers and VeriSaaS Cloud is encrypted with TLS 1.2 or TLS 1.3, as described above.
  • At rest: the databases and storage that hold customer data, and their backups, are encrypted with AES-256. Encryption keys are managed by the key management services of each cloud provider (such as AWS KMS and Google Cloud KMS), which keep them in highly durable, encrypted storage and log every use of them.