Security and Compliance

Security is a critical element in ensuring user trust in the platform.

Data Security

Data Encryption

Encryption of data at rest and in transit depends on the storage service providers for SeaweedFS and PostgreSQL. In the Kubernetes deployment, the QALITA Helm Chart does not include default encryption configuration.

warning

It is the responsibility of the system administrator deploying the platform to configure data encryption at rest and in transit. They may be assisted by a Database Administrator and a Network Engineer.

At Rest

Systems use storage media to read and write data. These systems are called "stateful" because their state is saved on storage media. In most cases, these systems offer methods for encrypting data "at rest," meaning encryption before writing data to storage media and decryption after reading from storage media. This ensures that raw data cannot be exploited by hackers who compromise storage media.

PostgreSQL	SeaweedFS	Redis
For PostgreSQL, you need to modify the database engine configuration in the Helm chart to include encryption at rest. Helm PostgreSQL - Database Engine Configuration	SeaweedFS allows blob encryption using a unique key stored in the blob metadata, which is stored in the Filer Store. You can ensure robustness by separating the Filer Store (metadata storage) and Volume Store (raw data storage). File System Storage Configuration	In the QALITA Platform implementation, Redis operates in "stateless" mode as a cache, so no storage media is used, and no specific configuration is required.
For further details, you can explore the native encryption options offered by PostgreSQL: PostgreSQL Documentation - Encryption Options

In Transit

---

Encryption in transit corresponds to data transfer over the ports of data storage systems. For us, this corresponds to:

• 5432 for PostgreSQL
• 8333 for SeaweedFS
• 6379 for Redis

The configuration of storage or database systems provides a layer of encryption in transit through their ports.

PostgreSQL	SeaweedFS	Redis
Helm PostgreSQL - Encryption in Transit	SeaweedFS - Security Configuration	Helm Redis - Encryption in Transit

For HTTP servers:

• 3080 for QALITA Backend
• 3000 for QALITA Frontend
• 80 for QALITA Documentation Server

Port mapping with an ingress domain and its TLS certificate is required.

HTTP Request Encryption

Encryption of requests depends on the configuration of network endpoints and the TLS certificates used.

warning

It is the responsibility of the system administrator to configure network endpoints and provide valid and exclusive certificates to ensure request security.

In the Kubernetes deployment, the QALITA Helm Chart by default requires a properly configured cert-manager to provide valid and exclusive certificates for network endpoints.

The following endpoints are created:

• frontend | domain.com ---> qalita-frontend-service:3000
• backend | api.domain.com ---> qalita-backend-service:3080
• doc | doc.domain.com ---> qalita-doc-service:80

Metrics Management

Metrics are computed by packs and stored in the platform's relational database. They are used to generate analysis reports, dashboards, and issues. Some packs generate metrics that are directly related to data without aggregation operations. These metrics are stored in the platform's relational database and are sensitive. They must be accessed with the same level of security as the source data.

danger

Be sure to read the pack documentation to understand the generated metrics and their sensitivity.

Data Compliance

Depending on your industry, you may be subject to data compliance regulations and standards. The platform aims to follow and comply with the following regulations and standards, but does not guarantee results or certification:

• GDPR
• HIPAA
• HDS
• SOC 2
• ISO 27001
• ISO 27017
• MLPS 2.0

Activity Monitoring

Access Management

Access to the platform is managed by an authentication and authorization system. For more information, see User/Roles/Permissions Management.

Log Management

There are two types of logs:

• User Activity Logs: User action logs are stored in the platform's relational database in the logs table. They are used to audit user behavior, both on the web app and with agents, due to the shared use of authentication tokens provided by the backend for both the web app and agents.

• Task Execution Logs: Task execution logs are stored in the platform's SeaweedFS storage. They are used to audit pack behavior on data. You can view them in the "LOGS" folder on the platform's Agent page or directly in SeaweedFS storage in the logs bucket.

Exporting User Logs

You can export user logs directly from the interface:

You can also export logs using a SQL query directly from the PostgreSQL database:

SELECT * FROM logs

Deleting User Logs

You can delete user logs directly from the interface:

You can also clear the logs table using a SQL query:

TRUNCATE logs