This topic provides vendor-specific guidance for implementing CMS applications using certain commercial data storage service providers. This guidance neither endorses nor recommends using these providers. The guidance in this topic will be expanded in future CMS TRA releases to include additional data storage service providers frequently used by CMS applications.
Amazon Web Services – S3
The Amazon Simple Storage Service (S3) can provide CMS systems with a cost-effective means for storage access and retrieval. This topic is based on Research Spotlight Technology Review – Amazon S3 Guidance, CMS TRB Technical Topics, updated 26 April, 2023.
The CMS preferred solution is the CMS Cloud implementation. Information and guidance is available at:
The Amazon S3 service can be used in either of two ways: for internal storage of resources in the CMS enclave, or for external data dissemination open to the Internet for access.
Internal Storage within the CMS Enclave
S3 storage is attached to the CMS Zonal environment. The S3 storage may be attached to the Presentation, Application, or Data Zones. S3 must adhere to all CMS TRA and CMS ARS security requirements.
External Data Dissemination
S3 storage may also be used to disseminate data to external parties, including access to data directly from the Internet. Any decision to provide direct access to data, without the defense-in-depth mechanisms provided by the CMS Zonal architecture, should be made with great care. CMS should consider all factors, such as the type of data (e.g., sensitivity) and types of users (public vs. a limited known set of interfaces), before deciding to provide access to the data directly to the Internet.
CMS is committed to providing the highest level of protection for the data. This includes ensuring the perception of security. If a non-sensitive document interface were hacked, the perception would be that CMS security failed, even if no sensitive data were lost.
All development groups should also consider user polices in addition to limiting the availability of the URL to the S3 resource.
AWS S3 Business Rules
CMS developed the following business rules for Amazon Web Services within the CMS Processing Environments.
BR-AWS-1: Encrypt Amazon S3 Data at Rest
The CMS ARS prescribes that data must be encrypted at rest, which applies to data in AWS S3 storage. AWS S3 must be configured (in the console) because it is not a requirement from AWS to encrypt. The configuration for encryption should be validated using cloud validation services such as CloudTrail. Since January 2023, by default, Amazon S3 automatically encrypts all new objects added on buckets on the server side.
Rationale:
CMS recommends that teams use AWS services for encryption. CMS recommends that the development teams employ the SSE-KMS AWS service, a service that combines secure, highly available hardware and software to provide a key management system scaled for the cloud. KMS allows creation and management of master keys.
BR-AWS-2: The S3 Storage Must Be Attached / Accessible from Not More Than One Zone
S3 storage may be attached to the CMS Zonal environment and must comply with CMS ARS and CMS TRA requirements. If sensitive data is attached to a zone which does not meet the security posture to store sensitive data, then the sensitive data may only exist in that S3 storage temporarily, while being processed (e.g. file scanning) before moving to an appropriately secured zone (i.e. one where access has been restricted via appropriate security challenges.)
Commentary:
For example, S3 storage can be used to support data storage requirements in the Data Zone, and additional S3 services could be attached to the support the Application Zone. Additional recommendations:
-
Assigns S3 to a specific zone. This can be accomplished by setting up access to S3 to be restricted by subnet. Each of the CMS zones within the Virtual Private Cloud (VPC) is its own subnet.
-
Limit the configuration of the S3 and the requirement for access by zone. This configuration and access MUST be validated during the configuration of the VPC and as part of the monitoring tools of the VPC (e.g., CloudTrail). In addition to restricting the access by zone, the developers should consider additional security mechanisms.
BR-AWS-3: Do Not Allow Cross-Zone Access to S3
The TRA requires that S3 storage only be attached to a specific zone (see BR-AWS-2). Multiple resources from the same zone type (e.g., data) are allowed to connect to the S3, but cross-zone access is prohibited. Resources are considered within the same zone type when the security posture for access is the same. For example, CMS prohibits allowing the Application Zone to place data in S3 and then allowing the Data Zone access to the same data because the security posture for application zone resources is not the same as the data zone. A data zone S3, housing sensitive data, can only be accessed from resources that have met the security requirements for accessing sensitive data.
BR-AWS-4: External Content in S3 Requires a Data User Agreement Process
For access by external sources, projects must follow the established Data User Agreement (DUA) process.
BR-AWS-5: Users Must Be Authenticated by AWS S3 Using a CMS-Managed IAM Userid When Accessing Data in CMS S3 Buckets
To access data in CMS S3 buckets directly through the S3 API or via an S3 URL, users must be authorized and authenticated by AWS S3 using a CMS-managed AWS Identity and Access Management (IAM) UserID. CMS must provision and manage this userid. CMS is responsible for vetting the user’s identity and authorizing the user. Depending on security requirements for the data and application, multifactor authentication (MFA) or network restrictions may also be required.
Users from external networks, CMSNet, or the CMS LAN must not have direct access to the CMS files persisted in a Data Zone.
A strongly preferred alternative to permitting user access to CMS S3 buckets directly through the S3 API or via an S3 URL is to provide a CMS service that mediates access and performs the storage and retrieval of data in S3. Such a service would not necessarily require users to be provisioned with IAM userids.
Anonymous read-only access to public data in S3 via an S3 URL is permitted without authentication.
For additional related guidance, please refer to BR-URL-1, RP- BR-URL-2, AWS-1, RP-AWS-2, BR-AWS-6, and BR-AWS-7.
BR-AWS-6: External Data Upload to S3 Is Not Permitted
CMS allows S3 to be used for storing collected data only after that data was submitted through a secure collection process.
BR-AWS-7: No Direct Internet Access to an Application’s Main S3 Storage
CMS prohibits all direct Internet access to an application’s main S3 storage. All Internet-based access to S3 Storage may implement a dedicated and separate “S3 bucket” to host the data temporarily. The data should only temporarily exist in the S3 bucket and be accessed by a short-lived URL. For example, if CMS is granting access (via the short-lived Internet URL) the data should first be copied to a new temporary location, and then the URL generated. Upon access, or expiration of the URL availability time window, the data object should be deleted from this temporary storage.
When hosting static content on Amazon S3, configure CloudFront distribution to restrict access to an S3 bucket so that users can access objects only through the distribution. This can be done by using an S3 REST API endpoint as the origin. Restrict access to Amazon S3 by setting up an origin access identity (OAI), a special CloudFront user that is associated with the CloudFront distribution. Add permissions on the S3 bucket to allow access to only this OAI. When the users access the S3 objects through CloudFront, the OAI gets the object on behalf of the users. If users try to access the Amazon S3 URL directly, their access is denied. This makes sure that the client can access objects in the S3 bucket but only by CloudFront.
BR-AWS-8: Remove Data from S3 When They Are No Longer Needed
Unused, unmanaged, and unmonitored data in S3 buckets may become targets of abuse. It is more important in shared or public cloud environments to remove unneeded data and storage than in traditional or private data centers. When unneeded data becomes untraceable and orphaned, it may continue to incur costs beyond the life of an application or even a line of business.
BR-AWS-9: Remove Unneeded S3 Buckets
Unused, unmanaged, and unmonitored S3 buckets and their contents may become targets of abuse. It is more important in shared or public cloud environments to remove unneeded data and storage than in traditional or private data centers. When unneeded data becomes untraceable and orphaned, it may continue to incur costs beyond the life of an application or even a line of business.
AWS S3 Recommended Practices
CMS recommends that service developers adhere to the following recommended practices to ensure the most effective implementation of AWS S3.
RP-AWS-1: Use Amazon AWS Security / Access Features for S3
AWS S3 security/access features include, but are not limited to:
- Bucket policies and rules that apply broadly across all requests to the S3 resources
- Identity and Access Management policies to assure fine-grained control to their Amazon S3 bucket or objects while also retaining full control on what the users do
- Link to DUA Account either through capturing the DUA number at time of registration or through IAM logging policies
- Access Control Lists (ACL) and query string authentication
- With ACLs, grant specific permissions (i.e., READ, WRITE, FULL_CONTROL) to specific users for an individual bucket or object
- Enable Amazon Macie for monitoring data security and privacy.
- Use VPC Endpoints for S3 Access: Amazon S3 bucket policies are defined to control access to buckets from specific VPC endpoints, or specific VPCs. The VPC endpoint routes requests across the Amazon network to S3 and then routes responses back to the VPC, ensuring that the traffic stays on the Amazon network.
RP-AWS-2: Use Short-Lived URLs for External Access to S3
CMS recommends limiting the exposure of the data by using short-lived URL access to S3. This includes configuring a time limit and a specific number of clicks for which the URL is valid.
Amazon provides the capability to limit the time window a S3 URL is available. CMS recommends restricting a time within which the URL is available to minutes. If the data must be available for a longer period, use additional mechanisms, such as encrypting the data with a password that is provided to the end user through a medium other than the URL.
CMS recommends limiting the number of allowable clicks to access the S3 URL. CMS suggests limiting that access to one click, assuring that once the URL has been accessed, it is no longer available.
These parameters should be explicitly defined and established by the business requirements.