Prokuria Tech Infrastructure and Security

2 years ago
diana
6 minutes

Introduction and Background

Prokuria is a cloud-based, Software-as-a-Service Platform, that offers procurement tools to procurement departments. With Prokuria, organizations can publish eRFQs, eRFIs, eRFPs, or eAuctions, as well as manage Purchase Requisitions, Approval flows, Contracts, or Purchase Orders.

Tech Infrastructure

In terms of technical implementation, Prokuria is based on an API model and is written in Microsoft .Net, Angular, and SQL Server.

Key points regarding Prokuria’s infrastructure: 

  • Cloud-based infrastructure, deployed in the Microsoft Azure Cloud
  • Fully scalable infrastructure with automatic scaling   
  • Database redundancy, and geo-replication with automatic backups
  • Service-oriented architecture
  • Powerful API for seamless integrations

Data Security

The only access route to data is via the API layer, with OAuth 2.0 authentication according to the current industry best practice.

Moreover, the SQL database itself is deployed and hosted on Microsoft Azure. As an Azure-hosted application, Prokuria benefits from Transparent Data Encryption (TDE) which ensures real-time protection and encryption of the database, associated backups, and transaction log files at rest.

Transparent data encryption encrypts the storage of an entire database by using a symmetric key called the database encryption key. This database encryption key is protected by the transparent data encryption protector. The protector is either a service-managed certificate (service-managed transparent data encryption) or an asymmetric key stored in Azure Key Vault (Bring Your Own Key). The transparent data encryption protector is set at the server level for Azure SQL Database and Azure Synapse, and instance level for Azure SQL Managed Instance.

In Azure, the default setting for transparent data encryption is that the database encryption key is protected by a built-in server certificate. The built-in server certificate is unique for each server and the encryption algorithm used is the industry best practice AES 256.

Protection of data

Our Azure SQL Database helps secure our client data by providing encryption for:

• data in motion through Transport Layer Security (TLS).

• data at rest through transparent data encryption.

• data in use through Always Encrypted.

Encryption in motion

All connections to Azure SQL Database require encryption (TLS/SSL) at all times while data is “in transit” to and from the database. SQL Database uses TLS/SSL to authenticate servers and clients and then use it to encrypt messages between the authenticated parties.

Encryption at rest

Transparent data encryption helps protect against the threat of malicious activity. It performs real-time encryption and decryption of the database, associated backups, and transaction log files at rest without requiring changes to the application.

Transparent data encryption encrypts the storage of an entire database by using a symmetric key called the database encryption key. In SQL Database, the database encryption key is protected by a built-in server certificate. The built-in server certificate is unique for each SQL Database server.

Encryption in use (client)

Always Encrypted is a feature designed to protect sensitive data stored in Azure SQL Database or SQL Server databases. Always Encrypted allows clients to encrypt sensitive data inside client applications and never reveal the encryption keys to the database engine (SQL Database or SQL Server).

Always Encrypted provides a separation between people who own the data (and can view it) and people who manage the data (but should have no access). It helps ensure that on-premises database administrators, cloud database operators, or other high-privileged but unauthorized users cannot access the encrypted data.

In addition, Always Encrypted makes encryption transparent to applications. An Always Encrypted-enabled driver is installed on the client computer so that it can automatically encrypt and decrypt sensitive data in the client application. The driver encrypts the data in sensitive columns before passing the data to the database engine. The driver automatically rewrites queries so that the semantics to the application are preserved. Similarly, the driver transparently decrypts data, stored in encrypted database columns, contained in query results.

Access control

To provide security, SQL Database controls access by using:

  • Firewall rules that limit connectivity by IP address.
  • Authentication mechanisms that require users to prove their identity.
  • Authorization mechanisms that limit users to specific actions and data.

SQL Information Protection

SQL Information Protection automatically discovers and classifies potentially sensitive data, provides a labeling mechanism for persistently tagging sensitive data with classification attributes, and provides a detailed dashboard showing the classification state of the database.

In addition, it calculates the result set the sensitivity of SQL queries, so that queries that extract sensitive data can be explicitly audited, and the data can be protected. For more details on SQL Information Protection, see Azure SQL Database Data Discovery and Classification.

Key security standards in use

  • SSL certificates for all communication between Prokuria’s components, including data transfer between the client and Prokuria.
  • Oauth 2.0 bearer tokens authentication. Every request handled by the API must bear the authentication token. Tokens cannot be altered, therefore it’s impossible to access sensitive information from Prokuria without a generated token.
  • Prokuria benefits from all Microsoft Azure Security features, such as Denial of Service (in case of brute force attacks), Firewalls, and Flooding.
  • Secured database inside Microsoft Azure. Can only be accessed by the API and the Logic App. No external users have access to the database. 
  • Database encryption to render data unusable in case of unauthorized access. 

Data residency

Prokuria is using the Microsoft Azure data center. 

Datacenter Region: North Europe

Location: Ireland

Microsoft secures data using multiple layers of security and encryption protocols. Get an overview of Microsoft data security capabilities here.

By default, Microsoft Managed Keys protects customer data that persists on any physical media is always encrypted using FIPS 140-2 compliant encryption protocols.

All data traffic moving between data centers is also protected using IEEE 802.1AE MAC Security Standards, preventing physical “man-in-the-middle” attacks.

Additionally, to minimize privacy risk, Microsoft generates “pseudonymous identifiers” that enable Microsoft to offer a world-class 24×7 cloud service (including operating and improving services, billing, and fraud protection). In all cases, pseudonymous identifiers cannot be used to directly identify an individual, and access to the customer data that identifies individuals is always protected as described above.

All Azure services are used in compliance with the GDPR.

More information on Azure Data residency can be found here.

Data Back-up & Recovery Strategy

Database backups are an essential part of any business continuity and disaster recovery strategy because they protect your data from corruption or deletion. These backups enable database restore to a point in time within the configured retention period.

Databases in Azure uses SQL Server engine technology to back up and restore data

Backup frequency

There are 3 types of backup full backups every week, differential backups every 12-24 hours, and transaction log backups every 5 to 10 minutes. The frequency of transaction log backups is based on the compute size and the amount of database activity.

When restored a database, the service determines which full, differential, and transaction log backups need to be restored.

Backup storage redundancy

By default, Azure Database store data in geo-redundant storage blobs that are replicated to paired regions. Geo-redundancy helps to protect against outages impacting backup storage in the primary region and allows to restore servers to a different region in the event of a disaster.

More information on Azure Data recovery can be found here.