Building a Serverless HIPAA-eligible claims processing solution with Amazon SNS, Amazon SQS and AWS KMS

Building a Serverless HIPAA-eligible claims processing solution with Amazon SNS, Amazon SQS and AWS KMS

This blog was written by Daniel Abib and Rodrigo Perez. Opinions are on our own.


Security is a high priority for any business application. This also includes securing the messaging infrastructure used by those applications.?To enhance your protection against possible data breaches, securing messaging infrastructure is crucial for businesses of all sizes. Security should be considered in any aspect of the entire business application as well as the mechanisms in which applications are connected, using integration services such as messaging or APIs calls. AWS provides a robust set of services to ensure secure messaging, with Amazon Simple Notification Service (SNS), Simple Queue Service (SQS) among others, as well as Key Management Service (KMS) for managing encryption keys.

This blog delves into how these services can be combined to create a secure, scalable messaging solution, with a special focus on the encryption & compliance capabilities offered by AWS KMS.

Amazon SNS and Amazon SQS: Primer Integrations Messaging Services

Amazon SNS and Amazon SQS are main services of the AWS messaging suite, essential for building scalable, decoupled application architectures.?

Amazon SNS, a fully managed publish/subscribe service, is designed to facilitate message-driven communication between different parts of an application, or between different applications altogether, ensuring dynamic scalability and robust message filtering capabilities.?

Amazon SQS complements this by providing a highly reliable queuing service for messaging between software components, thereby streamlining message management and allowing for asynchronous processing tasks. Together, these services fortify application responsiveness and reliability within AWS's extensive cloud infrastructure.

Amazon SQS and Amazon SNS are usually utilized in conjunction within a topic queue chaining pattern. This powerful combination allows for a highly scalable and flexible messaging architecture, where Amazon SNS serves as the publisher or message router, broadcasting messages to multiple subscribers. These subscribers can include Amazon SQS queues used as a message buffer. This pattern enables asynchronous communication and the decoupling of microservices, and developers can architect systems that are not only resilient and scalable but also capable of handling complex workflows and high volumes of data.

AWS KMS: The Backbone of Secure Messaging

AWS Key Management Service (KMS) is a complete solution engineered to simplify the creation and management of encryption keys, which are vital for protecting data. This managed service facilitates the encryption of data stored across various AWS services, ensuring secure data handling operations.?With KMS, companies benefit from centralized control over their cryptographic keys, allowing to enforce stringent access controls and the application of encryption seamlessly across AWS environments.?

Even though Amazon SQS and Amazon SNS already offer encryption at rest by default, we can add another layer of security with AWS KMS to enhance the security of messages in transit and at rest.?By encrypting the data in messages sent through Amazon SQS and notifications delivered by Amazon SNS, AWS KMS ensures that sensitive information remains protected against unauthorized access. This synergy between AWS KMS, Amazon SQS, and Amazon SNS not only fortifies data security within AWS-based applications but also maintains the integrity and confidentiality of the messaging and notification systems, crucial for building resilient and secure applications in the cloud.

Integrating SNS, SQS, and KMS for Secure Messaging

By default, both Amazon SNS and Amazon SQS support encryption at rest, using AWS KMS keys to secure your messages. When you create a new queue or topic, you can specify the AWS KMS key to use for encryption. This ensures that messages are encrypted as soon as AWS receives them and remain encrypted until they are delivered or deleted.

Configuring Encryption with AWS KMS on Amazon SQS Queue using the AWS Console

Configuring Encryption with AWS KMS on Amazon SNS Topic?using the AWS Console

If customers are looking for Server-Side Encryption (SSE) for messages stored in Amazon SNS and Amazon SQS, AWS KMS will be crucial to provides SSE strong encryption. You can select a customer master key (CMK) from KMS to be used for encrypting messages or use service-managed key.?The main difference between a Customer Master Key (CMK) and service-managed keys in the context of encryption is the level of control and responsibility.?A CMK is a customer-managed encryption key that provides more control and flexibility, but also requires the customer to manage the key lifecycle and security. Service-managed keys, on the other hand, are managed by the service provider, which simplifies key management but reduces the level of control for the customer. AWS KMS also allows you to define granular key policies that control the use of encryption keys.?

The customer can specify which IAM users and roles are allowed to use the key to encrypt and decrypt data, offering tight control over who can access your encrypted messages.

Furthermore,?AWS recommends that all messages should be encrypted in transit using HTTPS endpoints for both Amazon SNS and Amazon SQS. However, the choice of communication protocol is ultimately up to the customer. Using HTTPS protects your data as it moves between your application and the AWS services, providing an additional layer of security for your entire application.?

Beyond encryption, governing who can access your Amazon SNS topics and Amazon SQS queues is vital. AWS Identity and Access Management (IAM) allows you to define resource policies that specify who can publish to a topic or send messages to a queue. You can also define who can subscribe to topics or receive messages from queues.

Configuring access policy for Amazon SQS queues?using the AWS Console

Configuring access policy for Amazon SNS Topics?using the AWS Console


Security and Compliance for Amazon SQS and Amazon SNS

AWS provides a secure environment that complies or eligible with various standards, including HIPAA, PCI DSS, and GDPR, which applies to services like Amazon SNS and Amazon SQS.

For HIPAA compliance, AWS enables covered entities and their business associates to process, maintain, and store protected health information (PHI) securely. AWS aligns its HIPAA risk management program with FedRAMP and NIST 800-53, which are higher security standards that map to the HIPAA Security Rule. Customers who handle PHI can utilize HIPAA-eligible AWS services listed in the AWS Business Associate Addendum (BAA).

Regarding PCI DSS, AWS services that are compliant can be used to store, process, or transmit cardholder data, with AWS providing an infrastructure that supports these services. Customers are responsible for managing their PCI DSS compliance certification.?AWS provides resources such as AWS Artifact for customers to download compliance reports and AWS PCI DSS Responsibility Summary for understanding specific control responsibilities. AWS's compliance with PCI DSS is validated by an external independent third party, ensuring that their security management program is comprehensive and follows leading industry practices.

For GDPR compliance, AWS offers resources and services that help customers align with the regulation's requirements. This includes adherence to IT security standards and providing various compliance resources and tools, such as AWS Artifact, Security and Compliance Quick Start Guides, and the AWS Security Hub.

When using?Amazon SNS and Amazon SQS, it's important for customers to understand their part of the Shared Responsibility Model, which delineates the security and compliance obligations of AWS and its customers. While AWS ensures the infrastructure and services are compliant, customers must manage their own data and applications to maintain compliance within their use cases.


Example of Business Case Scenario

Let's use an example of a Serverless architecture designed for processing reimbursement claims in a manner that is compliant / eligible with the Health Insurance Portability and Accountability Act (HIPAA).?The process is orchestrated using AWS services, ensuring that sensitive patient data is handled with the required security measures.

The workflow begins with the collection of claim data from multiple patients. This data is then processed by AWS Lambda functions, which are Serverless compute services that run code in response to events. The initial set of AWS Lambda functions perform initial checks and validations on the claim data to ensure they are complete and properly formatted.

After initial processing, the first business step is to check if the data is complete and if the patient's insurance plan covers the total of medical services that was requested. After this validation, the claims are passed to a fraud detection service, represented by subsequent AWS Lambda functions responsible to analyze the claims for patterns that might indicate fraudulent activity. It may use machine learning models and anomaly detection algorithms; the system can flag claims that require further investigation.

Once the claim surmounts the hurdles of validation and fraud scrutiny, it transitions to the payment processing stage. This phase is pivotal, where the legitimacy of the claim translates into financial transactions. It may involve checks and balances to ensure accurate and compliant fund disbursement in alignment with policy terms and regulatory mandates. In our example, this stage is also handled by AWS Lambda functions, which might integrate with financial systems to execute the transaction. They ensure that the payments are made according to the validated claims and within the compliance framework.

In this hypothetical scenario, the final stage in the workflow is the medical relation management, where the outcome of the claim and the payment details are communicated back to the healthcare providers and possibly to the patients. This could involve updating medical records, sending notifications, and making sure that all parties have the necessary information regarding the claim.

Throughout the entire process, auditing and account management are integral components and can be run in parallel with the main business process. Each action and decision in the workflow is likely logged to ensure traceability and accountability. This not only provides a clear audit trail for compliance purposes but also aids in identifying issues and improving the process over time.

Using Amazon SQS and Amazon SNS, customers can and should enforce encryption at?rest and in transit, as well as ensure that API Gateway and all AWS Lambda functions are encrypted. This means implementing server-side encryption (SSE) for messages in Amazon SQS queues using AWS KMS keys, and similarly for Amazon SNS topics.?

For API Gateway, enabling HTTPS endpoints for secure HTTP communications and configuring AWS Lambda functions with environment variable encryption helps maintain a robust security posture. By adhering to these encryption standards, we can bolster our application’s security and compliance, safeguarding sensitive data and adhering to best practices for data protection.


In this secure workflow, AWS Identity and Access Management (IAM) plays a critical role in safeguarding the data as it moves through various stages due to the fact that all services must have permission to talk with each other and no other service has access to the data in transit or at rest. It is important to note that, due to stringent IAM policies, users, accounts, principals, and roles are prohibited from accessing the data within the SQS and SNS without an explicitly defined policy granting such access. This added layer of security ensures that only authorized entities can handle the data, reinforcing the protection of sensitive information throughout the reimbursement claim process.

In the diagram bellow, any application as Marketing, RH, etc. cannot access data in the queues or topics without explicit IAM policy.?


But, what about HIPAA use case? (or maybe GDPR or PCI DSS)

When using Amazon SQS and Amazon SNS within a HIPAA-compliant/eligible solution, it is essential to enforce encryption for PHI both at rest and in transit. The compliance auditors mandates customers to encrypt PHI in accordance with guidance from HHS. To accomplish this, we may use the AWS Key Management Service (KMS) for key management and encryption or use native features of AWS services.

Customers have flexibility in how they meet these encryption requirements and can use native encryption features of HIPAA-eligible services or other methods consistent with HHS guidance. It's important to regularly review the HHS site for any updates on these requirements. For more detailed information, you can refer to the AWS documentation on Encryption and Protection of PHI in AWS.

First Approach - Using Native Services

When utilizing AWS services for handling message data, especially when dealing with sensitive information such as PHI under HIPAA, it's possible to use the native features for data protection in Amazon SNS (link), Amazon CloudWatch logs (link) or even in Amazon CloudFront (link). These features include encryption capabilities to secure data at rest and in transit.?

The responsibility is on the AWS customer to configure these services correctly to maintain compliance with the necessary healthcare regulations. For an in-depth understanding, you should refer to the AWS documentation on encryption and protection of PHI.

Check this blog post to understand in details how Amazon SNS data protection can help customers in compliance scenarios:?https://aws.amazon.com/blogs/compute/introducing-message-data-protection-for-amazon-sns/?

One possible challenge of using Amazon SNS's message data protection is that while encryption safeguards the privacy and security of the entire or part of the data within the reimbursement claim process, it can also render the data unusable (de-identification of information) for further automated processing steps. This means that once the data is encrypted for security, systems that perform tasks such as payment processing or managing medical relationships may not be able to access or interpret the encrypted information without proper decryption mechanisms in place, which could add complexity to the workflow.


In the hypothetical workflow we are working in this blog, obfuscating PHI data to comply with privacy standards can lead to complications downstream. If the payload forwarded to subsequent stages lacks availability due to the obscured data, accessing and utilizing the necessary information later in the process can become challenging. This necessitates a balance between securing PHI and ensuring the data remains functional for subsequent processing steps.



Second Approach - Bringing AWS KMS into the play

A refined approach to manage, secure and be fully compliant?with HIPAA in this reimbursement claim process involves the use of AWS services coupled with AWS Key Management Service (KMS) for encryption, as well as other encryption mechanisms (encryption in transit and at rest as previously defined).? By creating three distinct public keys in AWS KMS and just allowing each application to access the appropriate key, the solution can encrypt and decrypt different segments of the payload, for example, patient details, medical expenses, and costs.

In the beginning of the flow, we can have a AWS Lambda function encrypting each part of the data using different encryptions keys. At each stage of the reimbursement claim, a specific AWS Lambda function processes the relevant data segment and these AWS Lambdas will have the specifically access to the keys that allow the decryption of the data they are allowed to. For instance, the Lambda function responsible for handling patient details would have access to the corresponding KMS public key to decrypt this information. Similarly, other AWS Lambda functions would utilize their respective keys to access and process medical expenses and costs data.


The use of separate encryption keys for different data types serves several benefits. It enhances the security posture by ensuring that each AWS Lambda function can only decrypt information that it is explicitly authorized to access. This minimizes the risk of unauthorized access to sensitive data and allow the information flows end-to-end. Additionally, it aligns with the principle of least privilege, reducing the attack surface and the impact of potential security breaches.?

By segregating access in this manner, the system also facilitates a modular approach to business logic, allowing for more straightforward updates and maintenance for each functional component of the reimbursement process.

Incorporating AWS CloudTrail and other AWS observability tools into this architecture provides a comprehensive audit trail. It allows monitoring of which applications or services are using each encryption key, thereby offering enhanced visibility and traceability for security audits and compliance monitoring. This facilitates a thorough review of access patterns and usage, which is critical for identifying unauthorized attempts to access sensitive data.

Best Practices for Secure Messaging

To safeguard secure messaging within AWS, following a set of best practices is essential. Firstly, modify the default encryption offered by the Amazon SQS and Amazon SNS services to use encryption. Amazon SQS offers the default the encryption using AWS KMS and for Amazon SNS customers has to switch the security configuration. Secondly,? rotation policy and procedures of AWS KMS keys significantly boosts security by updating the key material, which can be archived either automatically or manually to cut down the risk of key compromise. Enforcing strict IAM policies for both Amazon SNS and Amazon SQS is also essential, as it guarantees that only allowed users can publish, subscribe to, or process messages, maintaining a secure access control environment.

Monitoring plays a crucial role in security, and taking advantages of AWS CloudTrail for this purpose is greatly recommended. CloudTrail enables the tracking of activities related to Amazon SNS topics, Amazon SQS queues, and AWS KMS keys, allowing an audit trail that is instrumental in identifying any unlawful access or changes to configurations. We can also enable?logging its API data events through AWS CloudTrail. This feature provides customers with improved visibility into Amazon SQS activities within their AWS accounts, facilitating better security practices and aiding in operational troubleshooting (link).?Lastly, for especially sensitive information, applying client-side encryption before dispatching messages adds a robust layer of security. By encrypting message content with personal keys before it is sent to AWS, the integrity and confidentiality of the data are preserved, establishing a secure messaging framework.

Amazon SNS's message data protection can be a significant advantage in the reimbursement claim process by ensuring sensitive patient information is handled according to HIPAA regulations. By scanning messages for PII and PHI, SNS helps prevent unauthorized disclosure during the transmission of claims data, aligning with privacy standards.

In the context of a reimbursement claim workflow, Amazon SNS can automate the detection of sensitive data within messages. This automation ensures that claims containing PHI are identified and handled securely, with options to block or audit such messages according to the established policies, thereby mitigating the risk of data breaches.

In a healthcare context where AWS Lambda functions process sensitive information, AWS CloudWatch Logs' data protection features (link) are vital for HIPAA compliance. By restricting? AWSLambda from logging PHI, inadvertent disclosures in log files are prevented, maintaining the confidentiality required by HIPAA. This aligns with the HIPAA Privacy Rule, which mandates safeguarding PHI against unwarranted exposure.

Moreover, AWS CloudWatch Logs allows for fine-grained access controls and encryption, ensuring log data is only accessible by authorized personnel and systems. This not only supports compliance with the HIPAA Security Rule by protecting PHI from unauthorized access but also provides a secure audit trail essential for monitoring and reviewing system activity related to PHI handling

Furthermore, the auditing capabilities of Amazon SNS message data protection allow for comprehensive tracking and reporting. This is crucial for maintaining transparent records for compliance purposes and provides a framework for accountability and traceability throughout the claim's life cycle, from submission to payment processing.

Conclusion

Security must be job the most important aspect for any company, business, and application. Securing applications that uses AWS messaging services as Amazon SNS and AmazonSQS is a critical endeavour in today's data-driven environment, where the sanctity of sensitive information is paramount.?

This blog has dissected the synergy between these services, emphasizing encryption with AWS KMS for ensuring data confidentiality. As we've navigated the secure messaging framework, we've explored how AWS's robust infrastructure supports compliance with stringent standards like HIPAA, PCI DSS, and GDPR.

In the?hypothetical scenario of a HIPAA-compliant reimbursement claim process, the services from AWS help customer to ensure that PHI is meticulously protected, from initial data capture to final medical relationship management. The layered encryption approach, coupled with AWS IAM's stringent access policies, guarantees that data is accessible only to authorized entities, upholding the integrity of the reimbursement workflow.

To conclude, it's clear that while AWS provides a series of foundation for secure messaging, so the?burden is on organizations to meticulously configure and manage these services and encryption keys. AWS's shared responsibility model underlines this, tasking users with the obligation to safeguard their applications within the AWS ecosystem. Through this partnership, AWS's combination of Amazon SNS, Amazon SQS, and AWS KMS emerges as a beacon of security in the cloud computing realm.

Hi Daniel good post! However, I have a small observation for it, and hope it helps to clarify a few things. That's not HIPAA-compliant, that's maximum HIPAA-elegible, who decides if an organization and its systems are HIPAA-compliant or not, is the OCR (a division of the HHS). In the best case what you can do to double-check/certify if an organization and its systems are HIPAA-elegible and have good chance of being considered HIPAA-compliant when facing an audit of the OCR, is running a private audit to detect failures in all levels and take actions... However, that doesn't offer a 100% guarantee, even if running frequent private audits. Also, consider that being HIPPA-compliat is not only about the system, it is also something that applies to the entire organisation and its processes and protocols. I had the opportunity to create a few HIPPA-elegible serverless solutions in the past, in all cases I had extraordinary and challenging learning/growing experiences about the topic. I would love to have more opportunities like those in the future.

要查看或添加评论,请登录

Daniel ABIB的更多文章

社区洞察

其他会员也浏览了