Security and architecture of Seald servers

External architecture

Seald operates in "Cloud" hosted at OVH; no server installation is required at the customer's premises to operate the solution.

Architecture schema
Seald's simplified architecture

Services used by Seald

The Seald desktop client application, as well as its lightweight version in the browser, must have access to various services to operate:

Seald's API

Domain: api.seald.io
Flow type: HTTPS/443
Mandatory flow: Yes

The Seald API is the main communication link of the Seald application. It is on this interface that are exchanged most information such as users' public keys and message keys from files (see key concepts and protocols).

Notification service

Domain: crossbar.galactica.seald.io Flow type: HTTPS/443
Mandatory flow: No, but highly recommended

The Seald notification service has two main features:

  • Allow a Seald instance to receive "live" notifications, such as opening a file or adding a device to an account. These notifications are also available and replicated on the Seald API, but the API of Seald does not allow for immediate visibility.
  • Allow Seald instances (or the lightweight client) to communicate directly with each other.

Support service and ticketing

Domain: zammad.galactica.seald.io
Flow type: HTTPS/443
Mandatory flow: No

The support and ticketing service allows Seald users to contact support directly via the application, whether for assistance or bug reporting.

Bug reporting service

Domain: sentry.galactica.seald.io
Flow type: HTTPS/443
Mandatory flow: No

The bug reporting service allows the application to retrieve technical information in the event of a crash related to the bug. This information is anonymized and only allows the Seald development team to to have information about the origin of the bug.

Update service

Domain: github.com
Flow type: HTTPS/443
Mandatory flow: No, but highly recommended

The update service allows the storage and recovery of binaries from the Seald application. It is necessary to to access this service to get an up-to-date version of Seald.

Security

Availability

  • Seald's database is hosted in OVH's data centers. It is dimensioned to be highly available and is replicated three times.
  • Seald's API service is hosted in OVH's data centers. The underlying application is also configured in high availability.
  • The database is backed up daily.
  • The file systems of the Seald servers are backed up on a weekly basis.
  • The availability of services is monitored by the Cabot application. A report of the availability metrics of the services can be made available on request.

Integrity

  • All servers are updated on a monthly basis.
  • A continuous monitoring of component vulnerabilities is carried out.
  • Security scans are performed on a weekly basis. Safety reports can be made available on request.
  • The production servers all have an identical test environment (called "Staging").

Confidentiality

  • All incoming flows from the servers are either secure (TLS / SSH) or redirecting to secure flows (HTTP + HSTS).
  • Sensitive fields in the database are encrypted, so these data cannot be extracted from backups databases without the decryption key.
  • The weekly backup of the disk systems of the Seald servers is also encrypted with a unique key for each server.
  • Administrative and server maintenance accesses are only available to authorized employees, according to the principle of the least privilege.

Traceability

  • System operations (Unix) are logged via Syslogs and integrated with weekly backups.
  • Application operations (Docker) are logged in log files and integrated into weekly backups.
  • User events (Seald) are logged in the database and integrated into daily backups.
  • Team events (Seald) are logged in the database and integrated into daily backups.

Security sizing

Seald follows the recommendations of the ANSSI and the NIST in terms of security sizing:

  • HTTPS communication: all communications between users and Seald servers is secure by the TLS protocol, using only secure protocol versions and cryptographic suites safe.
  • Database encryption : some database fields are considered sensitive. Only when these fields are encrypted (AES256_CBC + PBKDF2HMAC), with a key not stored on the database.