White Paper for Adoption of Compucare (on Azure)

Contents

• 1. Executive Summary
  • Key Benefits
• 2. Introduction
  • Current Scenario
  • Challenges Faced 
  • Need for Transition
• 3. Benefits of Transition
• 4. Overview of Azure SQL Databases and MS Entra ID (ex AAD) Authentication
  • Typical Topology
  • Overview of Authentication
  • Tenant Permissions/Claims
• 5. Migration Strategy
  • Assessing Your Current Implementation
  • Simplified Migration Example
  • Testing and Validation
• 6. Security and Compliance
  • Data Encryption
  • Firewall Configuration for Azure SQL Database
  • Compliance and Auditing
• 7. Pre-Requisites
• 8. Contact Information

1. Executive Summary

This white paper outlines a transformative journey that involves migrating from an existing on-prem/SH hosted Compucare implementation to Streets Heaver's new Compucare SaaS utilising Azure SQL database while implementing Microsoft EntraID (formerly knows as Azure Active Directory (AAD)) authentication via API's. This transition not only addresses the challenges of the current environment but also unlocks opportunities for resilience & disaster recovery, efficiency, security, and scalability.

Key Benefits

The implementation of Azure SQL databases and Microsoft EntraID (AAD):

• Enhanced Security: implementation of MS EntraID 's authentication protocols.
• Streamlined User Access: Simplify user management with single sign-on and multi-factor authentication through MS EntraID.
• Reduced Maintenance: Automated backups, updates, and optimisations, reducing the burden on IT resources.
• Improved Performance: Leverage Azure's scalable infrastructure for application performance.
• Resilience: Geo Failover for the Report Generator database and web app, globally distributed static web apps.
• Disaster Recovery: Azure Active Geo-Replication, 1 month retention with point in time restore capability.
• Continuous Deployments: Latest features are deployed as they are made available, unavailable to the original Report Generator on-prem installation
• Early Access Preview: your users will have access to the latest web application offerings, unavailable to on-premise installations

2. Introduction

Current Scenario

Compucare is currently implemented either within a clients infrastructure or with SH's datacentre (deployed as a desktop application over RDP+Citrix). When deployed on-premise, this incurs local technical resource to provision the infrastructure and allows generates an ongoing overhead for applying application updates. When deployed in SH DC, whilst updates are centrally managed by Streets Heaver, there is an overhead and bottleneck regarding named user registration.

Challenges Faced 

The main challenges are around keeping up to date with updates, due to local resource capabilities or processes. Other fundamental challenges include Disaster Recovery (DR) polices of either on-prem or SH DC. There is an increasing requirement for clients to want to improve their DR strategy. The SH Datacentre is unable to provide geo-redundancy, and the hardware is located with Streets Heaver's main office, a single location in Lincoln, UK.

Need for Transition

Moving to a public, MS Azure, hosted and Streets Heaver centrally managed architecture gives an always up to date solution, allowing clients to make the most of all released features. Being able to present this new approach leverages Azure services and AAD authentication to address the challenges mentioned earlier. This transition aims to position our clients for future growth and success.

3. Benefits of Transition

1. Ownership
   1. Streets Heaver complete ownership of all hosted services
   2. The client is responsible for laptop/pc specification, and adequate internet access (and VPN tunnel bandwidth based on user base)
2. Deployment
   1. Compucare 8 deployed using a self-updating client, running from within  the user profile directory - avoiding administrative evaluated privileges.
   2. All updates are centrally managed and rolled out, features pushed every 3 weeks, and maintenance releases rolled out near real time.
3. Security
   1. MS Azure SQL database secured with MS EntraID authentication via API's
   2. Allowed IP's to SAL for Compucare 8 client 
4. User Changes
   1. Client is able to manage the users within the limits of their licence (max named users) - providing the users are created within the clients MS EntraID tenant, and guest users are invited into the MS Entra ID .
5. Updates
   1. 3 weekly updates deployed
   2. Database and all web applications automatically upgraded
   3. Self updating client auto-downloads and updates on every users machine
6. Data and Storage
   1. Azure SQL database for core data
   2. Azure storage for blob data (attachments)
7. Connectivity
   1. Access to compucare.streets-heaver.com, reports.streets-heaver.com, clinician.streets-heaver.com and other streets-heaver hosted domains.
8. Resilience
   1. Azure SQL db
      1. Geo Failover for SQL
      2. Replica db used for Read-Only access for reporting and 3rd party access
   2. Static Web apps
      1. Globally distributed
   3. App Service
      1. Geo replicated (UK South > UK West)
9. Disaster Recovery
   1. Azure SQL Active Geo-Replication (UK South > UK West)
   2. Backups 1 month retention, with point in time restore capability

4. Overview of Azure SQL Databases and MS Entra ID (ex AAD) Authentication

Typical Topology

Overview of Authentication

Prerequisites

1. An admin grants consent for the Compucare 8 app registration (owned by Streets Heaver) into their tenant. This allows SSO in Compucare as well as communication with the Tenant Server

The process is as follows for databases that Streets Heaver host in Azure SQL:

Installing Compucare:

1. User downloads the Compucare Installer from the Compucare Homepage (https://compucare.streets-heaver.com)
2. User will be prompted to sign in with their credentials for their tenant, which uses the Microsoft Authentication Library (MSAL). Compucare not receive the users email or password.
3. Once authenticated, the Installer receives an access token back from MSAL.
4. At this point, the Installer retrieves a list of available releases that the user has been granted access to (based on their available data sources) using the access token, from the Streets Heaver Tenant Server (https://tenants.streets-heaver.com

Once installed:

1. User launches Compucare
2. If user had authenticated via EntraID in the Installer, this same token will be utilised. They may be asked to authenticate again, e.g. if their token has expired or your organisation access policy requires it.
3. Compucare retrieves a list of data sources for the user from the Tenant Server. These are returned encrypted.
4. When database connection is requested, Compucare uses the EntraID access token to request an access token for the Azure SQL connection from the Tenant Server. This is cached for around 60 minutes.

SSO login method in Compucare:

1. Once EntraID authentication has been set up within Compucare (in Single Sign On Settings), Compucare users can be linked to their EntraID.
   1. This can be done manually per user or doing a bulk lookup, based on their Compucare email address.
2. User can select the SSO option on the login screen. If the signed-in user has been added against a Compucare user, they will be logged in - as long as the access token is valid.

Tenant Permissions/Claims

Application.ReadWrite.All

DelegatedPermissionGrant.ReadWrite.Al

5. Migration Strategy

Assessing Your Current Implementation

We would do a full survey of your existing setup, along with any connected services and build a implementation plan. If you are already a SH Datacentre client, we the transition is much simpler.

Simplified Migration Example

1. Pre-requisites:
   1. Compucare 7 clients will need to be migrated to Compucare 8, and Report Generator
   2. Implement Report Generator (online)
   3. All existing app's and api's within SH Azure
2. Register Tenant Id with Streets Heaver for Compucare
3. Move SQL database to Azure
4. Re-point endpoints
   1. Report Generator -> Geo-Replica
   2. 3rd party read only access -> Geo-Replica
5. Sign off

Testing and Validation

Whilst a bespoke implementation programme will be established, the recommended approach would be migrate a clients Test environment (including interfaces and endpoints), and have a fixed timeframe for testing and sign-off before migrating the live environment. During post-live, a fixed period of monitoring and feedback will be observed to address any questions raised.

6. Security and Compliance

Data Encryption

In addition to TLS 1.2, Azure SQL Database always enforces encryption (TLS) for all connections. This means that regardless of the specific settings defined in the connection string, such as the "Encrypt" or "TrustServerCertificate" options, all data exchanged between the client and the Azure SQL Database server is encrypted "in transit."

By enforcing encryptions for all connections, Azure SQL Database mitigates the risk of data interception and ensures that sensitive information remains protected throughout the entire communication process. This comprehensive encryption approach provides customers with peace of mind, as their data remains secure regardless of the specific connection configuration or network environment.

In summary, Azure SQL Database prioritizes the security of customer data by encrypting it during transmission using the TLS 1.2 protocol. Furthermore, encryption (TLS) is enforced for all connections, guaranteeing that data is consistently protected "in transit" between the client and the Azure SQL Database server. These robust security measures contribute to maintaining high standards of data security and privacy for customers utilizing Azure SQL Database.

The default encryption level for Azure SQL Database is AES 256-bit.

Azure SQL also uses Encryption at rest (Transparent Data Encryption). TDE encrypts the entire database using an AES encryption algorithm, which doesn't require application developers to make any changes to existing applications. All newly created databases are encrypted by default and the database encryption key is protected by a built-in server certificate. Certificate maintenance and rotation are managed by the service and require no input from the user.  TDE performs real-time encryption and decryption of the database, associated backups, and transaction log files at rest without requiring changes to the application. More information on TDE can be found here.

Authentication for Compucare to access an Azure SQL database is by a Service Principle obtaining a short-lived access token by calling a hosted API that authenticates a user's AzureAD token obtained using OAuth2 Authorization code flow. The users Azure AD token must contain a role assigned by the client's organisation to allow the user to login to Compucare.

Firewall Configuration for Azure SQL Database

We allowlist clients' external IP to their SQL database, providing an additional layer of protection, all access to the SQL database will only be granted via a white listed list provided by a client. The expectation is all traffic will be routed via a clients VPN to Azure SQL.

Compliance and Auditing

• Data Storage and Handling: All data including is stored within UK only regions in Azure (UK South & West). 
• Logging and Monitoring: The application's activities are logged and monitored to identify and respond to potential security incidents.
• Regular Security Audits: The application undergoes annual external CREST approved PEN testing, as well as regular vulnerability audits to assess its security posture and identify vulnerabilities. Any findings are promptly addressed to maintain a robust security posture. Internal and external reports are available upon request.

7. Pre-Requisites

1. See Minimum System Requirements for Compucare (on Azure)

8. Contact Information

Please contact marketing@streets-heaver.com for further information.