Potentially outdated

This page was last updated 31 months ago (on 2023-08-22). Verify the information is still accurate before relying on it.

• Introduction
  • Network
  • VPC
  • Subnet
    • Service Endpoint
    • NACL
    • Security Groups
    • Site-to-Site VPN’s
    • Site-to-Site Options
    • HSCN Site-to-Site VPN’s (UK only)
  • Appliances
  • OS
  • Security Software
  • Automation
  • Access & Authentication
  • SSO
    • Authentication
    • Access
  • Rhapsody Access
  • Monitoring & Security
  • DataDog
    • Authentication
    • Agent
    • SIEM
  • Grafana
  • PagerDuty
  • SentinelOne
  • CloudTrail
  • Storage
  • Certification

Introduction

The RaaS Cloud Security WhitePaper is a technical glossary of services used in deploying and running “ Rhapsody as a Service” .
Within this document we will cover the service type and it’s reason for use, we will where possible reference AWS documentation to help explain reasoning behind the choices that were made.

Network

VPC

The following section details the security controls, features and services in place within the networking layer of the “ Rhapsody as a Service” architecture.

• VPC (Virtual Private Cloud)

RaaS is built within a single VPC - the VPC is tagged and named in accordance with the subscribed customer, as in the following example.

• Customer Name

• Subscriber (customer, management)

• Resource type

An example of the above would look as follows mycustomer-customer-vpc or raas-management-vpc, the former being a customer VPC and the latter being assigned to an internal management stack.
Tag’s for the service are generated and taken from the CloudFormation stack used for creating each component.
Naming helps to identify the owner, location and account of each subscriber.

In order to manage network level auditing, we attach “AWS Flow Logs” to each VPC, these flow logs help us to address intrusion detection and network related anomalies.

IP Address allocation is defined from an internal system - we manage IP addresses per region per customer. The CIDR (Classless Inter-Domain Routing) address space is /24 or 255.255.255.0 netmask, this allows us to divide the VPC into four subnets

Subnet

Four subnets are created inside the VPC and each subnet serves a service related purpose.
Two of the four subnets are designed to manage the forward facing proxy service, allowing http/https traffic to egress out from the Rhapsody application.
The two proxy service subnets have a netmask of /28 or 255.255.255.240.

The final two subnets host the “Rhapsody“ application.
These two subnets have a netmask of /27 or 255.255.255.224.

Each subnet is connected with a route table that directs network traffic flow between subnets and other additional services, such as AWS S3 endpoint, or management network access for configuration management.

Service Endpoint

Each customer account configured has a secure connection directly to AWS S3 using a Gateway Endpoint service. By enabling this service the appliances within the AWS VPC have the ability to access S3 buckets directly and securely using HTTPS and without the need to traverse the public internet, essentially using the AWS backbone.
Each appliance requires access to S3 in order to ship log data, retrieve bootstrap data and store backups.

NACL

Each subnet has an open NACL (network access control list) policy, the engineering team have designed it in this way due to the nature of “Rhapsody’s“ interface and comm point management. When Rhapsody is running, the service consumers will allocate high and usually random ports - as this service is self managed and there currently is no way to allow the consumer to manage both security groups and NACL’s we leave the latter open.

Security Groups

Security groups are appliance based firewall rules and as such will always belong to the instance using it. In some cases, for common rules, security groups are shared across instances.
Security groups have an open TCP port policy, that is locked directly to VPN traffic - this ensures that only ingress VPN traffic can access set ports defined on the appliance and prevents having to constantly raise requests for port access in the security group.
If a consumer of the RaaS/Envoy platform requires ingress access from anything other than a VPN a formal request is made via the appropriate channels and a rule set is added to cater for the required change.

Site-to-Site VPN’s

In order to maintain a high level of security over data in transit, Rhapsody Health offer customers the ability to peer with their RaaS/Envoy platform using AWS Site-to-Site VPN’s.
These VPN’s will ensure that all traffic egressing a customer environment will be encrypted to meet customer and Rhapsody Health’s security requirements.

Site-to-Site Options

AWS Site-to-Site VPN connections privately connects your VPC to your on-premises network. Data that's transferred between your VPC and your network routes over an encrypted VPN connection to help maintain the confidentiality and integrity of the data in transit. Amazon supports Internet Protocol security (IPsec) VPN connections. IPsec is a protocol suite for securing IP communications by authenticating and encrypting each IP packet in a data stream.

Each Site-to-Site VPN connection consists of two encrypted IPsec VPN tunnels that link AWS and your network. Traffic in each tunnel can be encrypted with AES128 or AES256 and use Diffie-Hellman groups for key exchange, providing Perfect Forward Secrecy. AWS authenticates with SHA1 or SHA2 hashing functions.

HSCN Site-to-Site VPN’s (UK only)

Rhapsody Health allows its customers to peer with their RaaS/Envoy environment directly over the HSCN (Health and Social Care Network). Rhapsody Health can peer with the HSCN with restrictions in place to guarantee a compliant connection.
In order to achieve this connection Rhapsody Health create a VPN tunnel directly to the HSCN using a software appliance called StrongSwan this connection is not made publicly but privately away from the public internet.

The HSCN VPN connection is very similar connection options to that of the AWS Site-to-Site VPN, all traffic is encrypted in transit using AES256 or below (not recommended) and uses Diffie-Hellman groups for key exchange.

Appliances

“ Rhapsody as a Service” is deployed onto AWS EC2 instances, these EC2’s are built from a prebuilt AMI created using Ansible playbooks. Rhapsody Health’s CloudOps team harden the AMI using Security Technical Implementation Guides STIG, the AMI is then provisioned with critical updates to the OS along with the removal of any un-required packages.

RaaS and Envoy environments also have the addition of a Proxy service, which allows for http/https egress traffic to transit out onto the public internet. As with the application, this service also utilises AWS EC2 as its underlying host and like the application is built using the same base AMI.
The Proxy service is in a scaling group of one, which is fronted by an AWS NLB. Access to this network load-balancer is made via an internal DNS request that is resolvable within the network and from the application EC2’s.

Each underlying AMI is shared to the designated customer/management account and the underlying snapshot is encrypted using an AWS KMS's symmetric managed key, this key is only known to the account the AMI is shared to and has a policy that allows the AWS EC2 service to encrypt/decrypt the underlying key.

OS

Rhapsody Health currently uses Centos 7.9 for RaaS/Envoy’s underlying operating system, as mentioned previously, this AMI is hardened to STIG benchmarks and has very controlled access to the internet.

Security Software

The base image for RaaS/Envoy contains various security tooling to help detect malicious activity, malicious software and unauthorised access. The AV technology used within RaaS/Envoy is SentinelOne Cloud Workload Security.

DataDog is installed for monitoring, logging and Cloud SIEM activities, the latter are tracked and have policies assigned to them that can alert our on-call team should something occur on the EC2 that is seen as a potential threat.

Automation

All RAAS and Envoy solutions are deployed and managed using configuration management and infrastructure as code.
The RAAS Cloud Engineering team deploy customer infrastructure using CloudFormation as well as Terraform. All code is checked and tested using integrated pipeline tools, for areas that pipelines cannot verify, the team will run manual testing within a environment that is completely isolated in relation to any customer.

When deploying and managing Rhapsody and it’s underlying host platform, the Cloud Engineering team use Ansible to automate the upkeep and maintenance without an engineer accessing the underlying host.

Access & Authentication

Access is granted and controlled at a service and user level. Each service that requires access to AWS resources in controlled by creating granular IAM policies and attaching them to IAM roles. A role is created based on the service that is intended to use it, this is defined within the trust policy and sets the service principal that requires access to it.
User access is controlled based on whom requires it.
As for the Rhapsody Health engineering all access will be assigned by way of AWS SSO - permissions are then defined on role.

SSO

Authentication

We govern authentication using AWS SSO as the IDP (Identity Provider) which is federated with Azure to manage users and groups.
Only users that are in the AzureAD domain can be provisioned for use with AWS and is requested to go through the Rhapsody Health IT team and management approval.

Groups are created within AzureAD and are then SCIM (System for Cross-domain Identity Management) provisioned into AWS.
User access is also controlled by MFA, this way a user can only access Rhapsody Health resources by way of authenticating by username, password and MFA token.

Access

As part of our ongoing efforts to manage user access across the Rhapsody Health AWS estate, AWS SSO is used to create and assign permission sets and policies that allow access to users of groups enabling access to the resources they require.

https://aws.amazon.com/iam/features/manage-permissions

Where possible we aim to implement best practices following AWS' guidance.

https://aws.amazon.com/iam/resources/best-practices

Rhapsody Access

For security and integrity of our customer deployed solutions no engineer , support or professional services personal have access to Rhapsody. The only exception here is in the case of an Envoy setup, then the only personal to have direct access will be professional services.

Monitoring & Security

DataDog

Rhapsody Health monitor RAAS/Envoy products using DataDog.

Authentication

DataDog is a cloud based platform monitoring solution, that is accessible through SSO authentication and group/policy based access controls.
Users are given access via IT and team management approval.

Agent

RAAS/Envoy and any other appliance(s) that can be configured to use DataDog will have the DataDog agent installed.
DataDog collects server logs for audit and inspection purposes only, we do not send any ePHI or data from EHR systems.

SIEM

SIEM data for both Cloud Resources and Appliance OS uses DataDog’s Cloud SIEM solution to monitor and alert on anomalous behaviour patterns.
Rule set have been configured within the platform to alert when specific behaviour thresholds are met. Once a threshold is met an alert is sent to SecOps on-call team member and they start will start the incident management process.

Grafana

In some cases, regional based deployments are restricted due to local compliance regulations In these instances monitoring of customer VPN connections has been configured to use Grafana and Prometheus.

For more information on the tooling used please see the below links.
https://prometheus.io/

https://grafana.com/

PagerDuty

PagerDuty has been the go-to incident response solution for Rhapsody Health and has been integrated with all monitoring and security solutions that are currently in use within the RAAS/Envoy cloud ecosystem.

SentinelOne

For AV scanning and threat detection, Rhapsody Health have opted to use SentinelOne.
SentinelOne is an agent based scanning service that monitors the host it has been deployed to, in order to verify it has not been compromised with a malicious payload.

Rhapsody as a Service and Rhapsody as a Service Managed (Envoy) run every EC2 with a deployed SentinelOne agent - these agents are managed by SentinelOne and updated or patched when a new release is available.

We manage each host with a globally set policy that sets the protection, detection and visibility level across our customer base.

CloudTrail

Rhapsody Health tracks all auditable AWS events using a multi-regional CloudTrail configuration - these trails are centralised and are then streamed into DataDog. From DataDog we manage account event anomalies and trigger alerts if should certain criteria be met.

Storage

Rhapsody Health store backups, files and scripts within the following two locations.

• AWS S3

  • Every bucket created by the SRE team enables encryption by default.

  • This encryption is set at the bucket level and object level.

  • The encryption type is as follows;
    Server-side encryption protects data at rest. Amazon S3 encrypts each object with a unique key. As an additional safeguard, it encrypts the key itself with a key that it rotates regularly. Amazon S3 server-side encryption uses one of the strongest block ciphers available to encrypt your data, 256-bit Advanced Encryption Standard (AES-256). (AWS -https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingServerSideEncryption.html)

  • In some cases Rhapsody Health create S3 buckets that are public, in these scenarios Rhapsody Health will add ACL’s and Bucket Policies that prevent unauthorised access.

  • Where possible and when required Rhapsody Health will replicate some buckets into alternative, but geographically close regions this type of storage helps to maintain a high level of redundancy.

• AWS EBS

  • Rhapsody as a Service managed or not use Elastic Block Storage (EBS) disks for the following locations

  • 1 x Log directory - this disk manages the log directory of the host and as such is considered to be of high importance to the application, as such this disk will be detached and not deleted upon potential host failure

  • 2 x Data directory (Rhapsody App) - these disks are partitioned in a RAID 1 configuration and due to their importance are set to be detached and not deleted upon potential host failure.

  • 1 x Root - this disk managed the root directory of the application and as such will be removed upon potential host failure

  • Each disk has been encrypted using the AWS Key Management Service (KMS -https://aws.amazon.com/kms/)

  • Rhapsody Health utilises AWS Managed Keys within KMS. These keys are as stated, managed by AWS.

    • AWS Managed Keys are configured with Symmetric encryption, please see the following article for more information. https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#symmetric-cmks

  • AWS manages all aspects of compliance of the encryption techniques they provide, for more information please see: https://aws.amazon.com/kms/features/#Compliance

Data stored on EBS volumes are not accessed by employees of Rhapsody Health

Certification

Rhapsody Health currently holds the following compliance certification

ISO27001

SOC 2

Cyber Essentials

Cyber Essentials Plus