Information Security

Convier Information Security Officer: Petter Chr. Bjelland (CTO): petter.bjelland@convier.com

Access

There are multiple levels of authentication and authorization in Convier:

Access to Convier

The first level is firewall/network configuration. As Convier is installed within your infrastrcture, only clients within the internal network should be able to reach the server. The second level of security is user authentication and authorization with OIDC/OAuth. A client (Enterprise Application in Azure) is created, which Convier uses for access control. Users and groups are granted access to this client. Users without access cannot reach the application or any projects. Along with access to Convier, the client also assigns each user a role, typically either Read or Manage. By default, only users with the Manage role can create projects in Convier.

Access to projects

Within a project, users have the role of Read, Manage, or Own. Users with the Own role control who has access to the project.

Projects can be shared with users, including those who have not logged in yet (though they still need to pass the first level to gain access). Users are assigned a role in the project. Projects can also be made available to all users with access to Convier, with the Read role.

It’s also possible to create new App Roles in the OIDC client and grant access to projects based on these. Users must then be assigned the App Role, for example through the Application Registration page in the Azure Portal, to gain access.

Difference between Read and Manage in a project:

  • Manage users can create configurations for other users within the project.
  • Read users can make changes for themselves and propose changes but cannot save changes for others.

It is possible to share projects with users who haven’t logged in yet, but not with users who don’t have access to the application. Access to the application is controlled through your existing AD and access control/SSO.

Access to data sources

Similar to projects, individual data sources within a project, like databases or APIs, may be associated with a role. If a required role is specificed, users without the role will be prevented from seeing, connecting to, or retrieving data from the source. In addition to preventing access to the source, Convier makes a best effort to remove any metadata about the source from the configuration available to the user. Metadata that is removed includes the names of the fields loaded from the source, how it is presented, and how it is reported on.

Note: The data model configured from a restricted data source will be visible to all users who have access to the project. The data model contains type name (like “Customer”), icon and fields (like “Name”). This information is not removed as it would break configuration functionality. If the data model itself is considered too sensitive to be visible, a separate project should be created for the data source.

Encryption

In transit

Convier supports encrypted communication with both client and data sources. How TLS is implemented on client-server communication depends on the installation pattern that is used. Convier can boot with a PKCS12 export (e.g. Let’s Encrypt) directly, or behind a proxy that handles encryption, e.g. Azure App Service.

At rest

Convier stores project configuration, including data source credentials, in a database. This database can be configured to be stored in an external database server, but by default it is stored in a SQLite database persisted locally next to the service. The contents of the configuration is by default encrypted with AES256, but a different encryption method may be configured. The symmetric AES256 key is provided to the service as an environment variable, either in the .env file next to docker-compose.yml, or through the configuration of the Azure App Service.

Secrets

Other sensitive information Convier needs to operate includes the secret for the OIDC client used for authentication. This secret, as well as other OIDC configuration is provided to the service as environment variables, either in the .env file next to docker-compose.yml, or through the configuration of the Azure App Service.

Software Development Life Cycle

Our Software Development Life Cycle (SDLC) is designed to provide both high development speed and secure deployments. It also enables customers to anticipate and test future releases by setting up development. We actively use internal and external static code analysis, dependency analysis, unit and integration tests to ensure the security and correctness of our software. All changes that are shipped to customers are first reviewed by at least two Convier employees. Our source code is hosted on Github Enterprise and Docker images are hosted in Azure.