NHS Digital have issued new guidance about the hosting of NHS and Social Care data, including guidance as to how off-shoring can be used.
This means a couple of things:
No longer the case that data can only be stored within English data centres
The OFFICIAL categorisation means no special security requirements are put on NHS and Social Care data over and above the usual security requirements - no ‘special snowflake’ treatment
Of course, making use of off-shoring will need all of the same risk assessments and governance frameworks in place - this does not just mean “it’s safe to store data off shore” - it means “it’s ok to store it off-shore if you can guarrantee the security just as you would on-shore”.
Ironically, the change to offshoring means that cloud provider regions that were previously off-limits can now be used, so suppliers could have adopted cloud about 5 years ago …
You’ll be pleased to hear that there are secure mechanisms for linking N3/HSCN to cloud resources - this massively lowers the barrier as with a little bit of thought we can develop solutions on internet-facing environments that can be easily deployed to N3/HSCN connected environments.
Excellent news @dunmail. I’d heard of services like RedCentric being used to link N3 to cloud services but haven’t personally used them yet.
Do you have experience of linking N3 to deployed cloud services Dunmail? If so, would you be up for writing a blog-post style HOWTO on here? I’d love to start turning openhealthhub into a resource for helping people solve these kinds of problems.
I’m wary that a blog post might not make it to the top of my TODO list for quite a while, so here’s a summary of how Black Pear are using AWS, including links to all the relevant resources:
AWS DirectConnect (https://aws.amazon.com/directconnect/) is used to securely route traffic from N3/HSCN to the Gateway VPC on AWS. (The Gateway VPC is then effectively a little bubble of N3 running on AWS).
Host proxy servers for both inbound and outbound traffic in the Gateway VPC. Choose your favourite software! (We run Ubuntu + haproxy/nginx/squid/postfix).
Create a second VPC on AWS - this is the Private VPC and must not be routable from the internet.
The Private VPC is used to host application servers.
AWS have published a helpful set of guidance describing Cloud architectures for UK-OFFICIAL workloads: https://aws.amazon.com/quickstart/architecture/accelerator-uk-official/. This includes a candidate architecture that can quickly be adapted to NHS requirements. You can try these out on any AWS account …
Design documentation (the Logical Connection Architecture) is used to show that the connection will be safe, secure and comply with NHS requirements.
The Information Governance Toolkit (https://www.igt.hscic.gov.uk/) is used to show that your organisation has a robust information governance framework in place.
Once the agreement and documentation were in place, the connection took less than a morning.
My top tips:
Start the IGToolkit and Logical Connection Architecture early. You can then make design decisions that make it easy to meet the requirements.
Use the Infrastructure as Code practice, for example AWS CloudFormation (https://aws.amazon.com/cloudformation/). Use this to build and deploy a development environment that matches the production environment exactly - including network configuration, firewall rules and virtual machine images.
Remember that not all AWS services run in all regions (e.g. Kinesis Firehose) and some must be internet connected (e.g. ApiGateway). Check that you’ll be able to use the service when you deploy to production.
Make friends with the NHS Digital DNS team - you may want their help to configure some non-standard records (e.g. a CNAME record on N3 DNS servers that points to a CNAME record on internet DNS servers that points to the CNAME record of a private load balancer on AWS DNS servers, that finally resolves to A records describing IP addresses in the Gateway VPC)
Probably worth cross-posting on the CCIO/CIO Network, there are many on there who would be really interested. @matthew.stibbs do you want to post it? (or I can do it if you prefer)
Thanks, Dunmail.
That was really helpful.
Would it be the same for our product( we are building iOS application for NHS clinical teams to communicate and manage tasks during oncall) to follow the same steps as you highlighted?
I assume that your app uses web-services of some description to manage the communication between different instances of the app. If this is the case, you could use exactly the same approach to provide N3/HSCN-facing web-services.
The world has moved on a bit since I wrote that post:
Check to see if the capability of the AWS platform has been extended e.g. I think ApiGateway can now be used for private and internal gateways.
The NHS guidance published in Jan 2018 does provide the option of using Internet-facing services. This may allow you to choose a simpler architecture. At this stage, I think there are 2 caveats about this:
There is a default position in some quarters of ‘N3 good, Internet bad’. Using N3/HSCN-facing endpoints is established practice and doesn’t push the comfort zone of customers’ information security advisors. If you use internet-facing endpoints you’ll need to be able to respond to this position before users will adopt the service!
Internet-facing endpoints will be exposed to a significantly higher level of threat and both the system architecture and operations will need to reflect this. Managing this is likely to be a distraction from the core business of providing a useful app for users.
Hi Dunmail, thanks for your write-up, it’s extremely helpful, and some of the only advice I could find around using HSCN with AWS. We’re trying to do something similar and are running into a particular issue; it’s a long shot but I thought I’d throw it on here and see if you or someone else has run into it.
We have our Direct Connect established (via redcentric as well) and our servers can be reached from the HSCN side. However, our servers also need to be able to get to the internet-at-large, and therein lies the problem. It seems that if we route default traffic to our NAT gateway, we lose the ability to connect to HSCN. I think the problem is with the BGP route propagation; when enabled, the propagated route is the default route, pointing to the VGW. Obviously you can only have one default route, so I can’t figure out how to enable internet and HSCN connectivity at the same time.
Is that something you ran into with your setup? Any help you can give is much appreciated!
Ian
Like, I would!