3

Say I have a private service that exposes sensitive information (PHI) via a REST API, and that I want to permit access to it from only one other service.

Is it enough to partition these services into different security groups and restrict inbound traffic only to the calling service? Would this type of authentication be HIPAA compliant?

oxdeadlocc
  • 31
  • 1
  • 2
    I can't comment on the HIPAA bit but your issue would be a lack of defense-in-depth. It would be relatively easy to accidentally alter the rules in the future inadvertently exposing the interface to an untrusted system or network (i.e. it's not fail-safe). – Andy Boura Aug 07 '14 at 09:56
  • The way I see it, @AndyBoura has answered the question. One layer--that could be altered or removed in the future--is never sufficient. – James Mishra Mar 05 '15 at 21:13

2 Answers2

1

You can have multiple API keys. It's in the basic service offering. You can audit their usage and restrict by originating IP and other factors.

https://d36cz9buwru1tt.cloudfront.net/pdf/AWS_Security_Whitepaper.pdf

It may be that you need to use the AWS identity product; http://aws.amazon.com/iam/

Amazon has published a whitepaper on HIPAA and HITECH measures for AWS

https://d36cz9buwru1tt.cloudfront.net/AWS_HIPAA_Whitepaper_Final.pdf

0

HIPAA's states: "the privacy rule requires a covered entity to reasonably safeguard PHI from any intentional or unintentional use or disclosure that is in violation of the requirements of HIPAA" Your main goal is to protect data in transit, and data at rest. Encryption covers most of this for you so let's look at your question:

"I have a private service that exposes sensitive information (PHI) via a REST API, and that I want to permit access to it from only one other service"

SERVICE (API) ---> connection ---> ONE OTHER SERVICE

ROUND 1: Your first concerns should be securing the REST API to the best of your ability (a covered entity to reasonably safeguard PHI from any intentional or unintentional use or disclosure).

SERVICE (API) [ROUND 1] ---> connection ---> ONE OTHER SERVICE

Your second concerns would be minimizing, removing, encrypting (if possible) PHI during transit. You don't want anyone being able to sniff the wire and either see data, or be able to create any kind of inference attacks. Crypto standards/guidelines on HIPAA can be searched, so they literally tell you what is and what isn't acceptable.

SERVICE (API) [ROUND 1] ---> [encrypted/tunneled] connection [encrypted/tunneled] ---> ONE OTHER SERVICE

Lastly, on the "one other service" machine, the same rules would apply. Encryption whenever possible, minimalist (need to know) access.

munkeyoto
  • 8,682
  • 16
  • 31