System

Security

Last updated on 11-Apr-2024 by Stephan Boersma
Stephan Boersma

Developer
boersma@scifeon.com
, Jakob Jakobsen Boysen
Jakob Jakobsen Boysen

Platform Lead
boysen@scifeon.com
On this page

System description

Scifeon customers usually have two Scifeon cloud environments: a test-environment located at https://-test.scifeon.cloud and a production-environment located at https://.scifeon.cloud. The * is specific to the given customer.

It’s possible to limit access to these environments to only certain IP-addresses or -ranges. General authentication and data access is described in later sections.

Scifeon environments are completely separated (i.e. single-tenant) from each other and always consists of the following services:

  • A HTTP server with all endpoints for the Scifeon browser client
  • A SQL Server Database
  • A file storage service
  • A browser client served from the HTTP server and CDN’s managed by Scifeon (the browser client doesn’t include any data or state, which means it is shared between all customers)

The different environment types are never hosted on in the same databases or HTTP servers.

Traffic

Access to storage and database is limited to internal communication between services at the cloud provider, or if necessary made public for only specific IP-addresses.

All communication to the Scifeon HTTP server must be encrypted using the HTTPS-protocol. HTTP is disabled, and all traffic using HTTP will be redirected to HTTPS. The cryptographic protocol TLS version 1.2 or above is required to communicate with the Scifeon HTTP server.

All internal communication to storage services and SQL databases must also be secure (ensured by Azure).

Data storage

The Scifeon HTTP server and database are both located in the Azure region West Europe within the geographical location Europe. This region is located in Netherlands.

Microsoft guarantees all data stays within a defined geographical region: “Microsoft may copy customer data between regions within a given geo for data redundancy or other operational purposes.” https://azure.microsoft.com/en-us/global-infrastructure/data-residency/#more-information

All data stored in the Scifeon database and file storage is encrypted at rest (https://docs.microsoft.com/en-us/azure/security/fundamentals/encryption-atrest). On request we can use customer’s own encryption keys for encrypting data at rest, i.e. data in databases and files uploaded. We are using standard Azure functionality for enabling this feature: https://docs.microsoft.com/en-us/azure/azure-sql/database/transparent-data-encryption-byok-overview?view=azuresqldb-current

Hosting infrastructure

Scifeon is a SaaS offering hosted in the Microsoft cloud-environment Azure. Each of the components outlined above are hosted using the following managed services:

As a company Scifeon doesn’t own or run any virtual machines, nor internal or customer facing. Our Active Directory is hosted in Azure, we use Sharepoint for documents and Office365 is used for emails. Task tracking is also done using cloud services.

This means we don’t manage any anti-virus, patching, etc. of any cloud server, and the Shared responsibility model below, shows what Scifeon should take responsibility of. Each of the responsibilities are outlined below:

https://docs.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility

Microsoft responsibilities

Microsoft does network penetration testing of their data centers: https://gallery.technet.microsoft.com/Cloud-Red-Teaming-b837392e

The physical security of their data centers are described:

“Microsoft designs, builds, and operates datacenters in a way that strictly controls physical access to the areas where your data is stored. Microsoft has hundreds of Azure datacenters in 54 regions (as of 2019), and each of these has extensive multilayered protections to ensure unauthorized users cannot gain physical access to your customer data. Layered physical security measures at Microsoft datacenters include access approval:

  • At the facility’s perimeter.
  • At the building’s perimeter.
  • Inside the building.
  • On the datacenter floor.

Physical security reviews of the facilities are conducted periodically to ensure the datacenters properly address Azure security requirements.”

Trusted Cloud eBook: https://go.microsoft.com/fwlink/?LinkId=392408&clcid=0x409

Information and data

Cloud environments are created using automated pipelines and templates, which follow all Azure security recommendations.

The Azure services used have certain security baseline recommendations described here:

Application penetration testing and vulnerability scans are periodically performed by third-party for Scifeon. These reports are made public if requested.

Devices (Mobile and PCs)

Scifeon offices are locked with chip+pin and keys to individual offices. Computer are always locked when leaving office, and passwords are at least 15 characters long.

Accounts and identities

All access to relevant information security management systems in Azure is controlled through AD roles in the internal Scifeon AzureAD.

Scifeon personnel who can access audit logs in production environments are restricted using AzureAD groups.

Source code & deployments

Our DevOps pipelines log all deployments to all environments, including production. The logging includes who initiated the deployment, when it was done, which components were updated during the deployment, the version of the deployment, and if everything were successfully deployed.

Installing and uninstalling apps are also logged with the same level of detail as general deployments.

Accounts and identities

All access to source code of Scifeon is located in Git repositories in Azure DevOps. Azure DevOps access is controlled by AzureAD groups.

Authentication

Authentication is typically initiated through the Scifeon browser client and the calls to the HTTP server.

Successful signins generates an accessToken (valid for 30 minutes) used for authenticating to the Scifeon HTTP server. A refreshToken (no expiration unless “Keep me signed in” is not checked, then it expires after 8 hours) is also generated, this is used for generating new accessTokens when these are expired. On each regenerate of the accessToken, the refreshToken is also regenerated, if it has an expiration.

Using the Scifeon client in the browser the accessToken is automatically regenerated every 20 minutes, i.e. before it is actually expired. This is to ensure all requests to the HTTP server is authenticated successfully.

The accessToken is provided in the header of each HTTP request and is validated using standard libraries, as described here: https://devblogs.microsoft.com/aspnet/jwt-validation-and-authorization-in-asp-net-core/

Tokens are signed using the standard algorithm HMAC+SHA256 and a unique key for each Scifeon system. Tokens are validated on each HTTP request.

Password based

Users can authenticate using a username (typically email or initials) and password. Currently the password must be at least 8 characters long. When new users are added to the system they are asked to create a new password immediately.

After 3 unsuccessful signins to the same user account, i.e. using the same username, the account is locked. The account can only be unlocked by requesting a password reset, which will send an email with instructions on how to reset the password.

Azure AD based

Users can authenticate using their AzureAD (or better known as Microsoft or Office365) login. The first time a user uses this method, they must accept to allow Scifeon to access their AzureAD.

Backup

Data is stored in databases and file storage services, these are regurlaly backed up as described below.

Files

Files are geo-replicated in Europe, so if the primary data-center fails, the secondary data-center is used automatically: https://docs.microsoft.com/en-us/azure/storage/common/storage-disaster-recovery-guidance https://docs.microsoft.com/en-us/azure/storage/common/storage-redundancy

Databases

Point-in-time backups are available for the last week. Backups are stored in geo-redundant (RA-GRS) storage blobs that are replicated to a paired region: https://docs.microsoft.com/en-us/azure/azure-sql/database/automated-backups-overview?tabs=single-database

Long-term retention backups are enabled per customer.

Manual backup

At all times a backup of the database and files stored can be downloaded in the live instance. This is done by an administrator in the Administration module and then the Backup section. All files ever uploaded to Scifeon can be downloaded into a zip-file, and the database with all information can be downloaded into a BACPAC-format, which can be loaded into any SQL Server. It is your own responsibility to regularly download these backups, and test they are working as intended. A log of when previous backups were downloaded can be found as well.

Audit Trail

All data entities in Scifeon have an audit trail which provides a total overview of an entity's history. A new entry is added to the audit trail when a record is created or updated. The audit entry contains detailed information such as what fields have been populated or changed as well as when the update took place and by whom.

The audit trail can be accessed by any user with read permissions by opening an entity's detail page and navigating to the Activity Log in the bottom.

Audit Events

In addition to the audit trail, Scifeon also manages audit events related to user and role management. These events encompass actions such as user creation and deactivation, as well as the granting and revoking of roles and permissions.

The list of Audit Events can be access by a user with the Data Manager role on the Administration page.

Data access

In Scifeon you are always part of a department (group). Further, you can have read/write access to other departments. You can also have read/write access to projects. Data is always associated with a specific user and department. Some data can also be associated with projects.

Scifeon can be configured into 3 security modes:

  1. Everybody can read and write all data
  2. Everybody can read all data, but you can only write data in departments or projects you have write access to
  3. You can only read data from departments or projects you have read access to, and you can only write data in departments or projects you have access to

All changes of data is logged by time and who.

Permissions

There are two user levels:

  • Regular user
  • Administrator: can change system settings, manage departments, projects and users, and read all data

Further user roles with permissions can be defined. Currently the following permissions are available:

  • Create project
  • Create user in specific departments
On this page