Security and Architecture Guide
This guide provides an overview of the security design and architectural controls implemented in DICOM Store SCP for AWS HealthImaging. It is intended for architecture and security reviewers, compliance teams, and technical decision-makers evaluating the solution.
The information presented here summarizes security-relevant aspects of the architecture. This guide does not replace the customer’s own security review, risk assessment, or compliance validation processes.
Architecture Components
The solution is built on the following AWS services:
Compute and Networking
Amazon ECS Fargate: Serverless container execution environment for the DICOM Store SCP server
Amazon VPC: Network isolation with public and private subnets
Network Load Balancer: Layer 4 load balancing for DICOM traffic with optional TLS termination
Storage and Data Management
Amazon S3: Object storage for received DICOM files and processing results
AWS HealthImaging: DICOM-compliant medical image storage and management service
Amazon DynamoDB: Metadata storage for import job tracking and status management
Orchestration and Processing
AWS Lambda: Serverless functions for workflow automation and event processing
AWS Step Functions: State machine orchestration for DICOM import workflows
Security and Monitoring
AWS IAM: Role-based access control for all service interactions
Amazon CloudWatch: Logging and monitoring for operational visibility
VPC Flow Logs: Network traffic visibility and analysis
Key Security Considerations
Customer-Managed Deployment
The solution is deployed entirely within the customer’s AWS account. The vendor does not have access to the customer’s environment, infrastructure, or data. All operational control and data governance remain with the customer.
Network Isolation
All components operate within the customer’s VPC. Network traffic is controlled through security groups, network ACLs, and subnet routing. DICOM clients connect through a Network Load Balancer, and internal communication occurs within the VPC.
IAM-Based Access Control
All interactions between AWS services use IAM roles with least privilege permissions. The solution does not use long-term credentials or access keys. Customers can review and modify IAM policies to meet their security requirements.
Encryption in Transit
DICOM communication can be encrypted using TLS at the Network Load Balancer
Communication between AWS services uses AWS-managed encryption
Customers configure TLS policies and certificate management
Encryption at Rest
S3 buckets use server-side encryption with AWS-managed keys (SSE-S3)
DynamoDB tables use default encryption
AWS HealthImaging uses AWS-managed encryption
Customers can configure customer-managed keys (CMK) where supported
Separation of Environments
The vendor and customer environments are completely separated. The vendor provides the container image and deployment templates but does not access customer data, logs, or infrastructure. No telemetry or usage data is collected by the vendor.
Logging and Operational Visibility
CloudWatch Logs, VPC Flow Logs, and service-level logging provide visibility into system operations. Customers configure log retention, analysis, and alerting according to their operational and compliance requirements.
Recommended Customer Controls
Customers should implement the following controls as part of their deployment and operational practices:
Network Security
Review and configure security groups to allow DICOM traffic only from trusted sources
Restrict inbound access using CIDR blocks or security group references
Enable VPC Flow Logs for network traffic analysis
Consider using AWS PrivateLink or VPC endpoints for service communication
Access Management
Apply least privilege IAM policies to all roles
Review IAM permissions before production deployment
Use IAM policy conditions to restrict access based on source IP, time, or other factors
Enable CloudTrail for API activity logging and auditing
Encryption
Enable TLS for DICOM communication at the Network Load Balancer
Review encryption settings for S3, DynamoDB, and AWS HealthImaging
Consider using customer-managed keys (CMK) for additional control over encryption keys
Validate that encryption meets organizational and regulatory requirements
Monitoring and Logging
Enable CloudWatch Logs for all Lambda functions and ECS tasks
Configure log retention policies according to compliance requirements
Set up CloudWatch alarms for operational and security events
Review logs regularly for anomalies or security incidents
Configuration Validation
Review all CloudFormation parameters before deployment
Test the deployment in a non-production environment first
Validate security group rules, IAM policies, and network configurations
Document configuration decisions and deviations from defaults
Operational Security
Establish procedures for monitoring import job status and errors
Define incident response processes for security events
Plan for regular review of IAM permissions and network configurations
Keep deployment templates and container images up to date with vendor releases
Compliance and Regulatory Considerations
This solution is designed with healthcare data security in mind and follows AWS best practices for HIPAA-eligible services. However, customers are responsible for:
Determining applicability of regulations such as HIPAA, GDPR, or other data protection laws
Configuring the solution to meet specific compliance requirements
Conducting compliance assessments and audits
Maintaining documentation for regulatory review
Implementing additional controls as required by their compliance framework
The vendor does not make claims about compliance certifications or regulatory approval. Customers must validate compliance based on their own requirements and risk assessments.
Note
This guide provides architectural and security information to support customer review processes. It does not constitute security advice, legal guidance, or compliance certification. Customers are responsible for their own security review, risk assessment, and compliance validation.