Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
1  
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 7 at 9:56

2 Answers 2

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

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.