This topic provides a core set of Data Storage Services business rules that are binding on all CMS business applications. To achieve their intended purpose, these business rules and recommended practices depend on compliance with BRs found elsewhere in the CMS TRA and controls in the CMS ARS. The BRs for this topic address Data Storage Services (DSS), File Uniform Resource Locators (URL), and Common Commercial Services, such as Amazon Web Services (AWS).
The business rules and recommended practices in this chapter depend on adherence to CMS ARS and CMS TRA mandates, and have the following specific dependencies:
Configure File Storage Services to Deny All Access by Default
Consistent with CMS TRA Network Services, BR-ACID-1 and CMS ARS Security Control AC-6 - Least Privilege, File-Level Storage Services must be configured to deny all access by default, and only permit authorized access. This least privilege rule is here for emphasis because failure to properly configure cloud-based file-level storage services is the reason behind many recent highly publicized data thefts. The Example Design Patterns described above rely on this rule to function properly with CSP storage services.
Rationale:
The CMS ARS requires systems to be configured for least privilege. Disclosure of CMS data to unauthorized users may result in harm to individuals, the Agency, or the government.
Deny Unauthenticated Access to Non-public CMS Files
CMS TRA Network Services, BR-ACID-1 and BR-ACID-2 prohibit unauthenticated access to non-public CMS files from external networks, CMSNet, or the CMS LAN. Unauthenticated downloading may be permitted if the files are intended for download by the public. To enforce this BR and maintain compliance with related CMS TRA requirements, file-level storage services should be configured to deny access to unauthenticated users, and an intermediary application must be used to access the files through the file storage service.
Rationale:
Disclosure of CMS data to unauthorized users may result in harm to individuals, the Agency, or the government.
Deny Anonymous Access to Non-Public CMS Files
CMS must know the identity of users accessing CMS files. CMS systems must be designed to prevent anonymous access to CMS files from external networks, CMSNet, or the CMS LAN, and to log the identity of external users or systems that access CMS files.
Rationale:
Refer to CMS TRA Network Services, BR-ACID-2.
In some environments, it may be possible that a file-level storage service and associated logging services may not know the identity of a user accessing a file even though the user is authenticated. Anonymous access may be a result of the systems’ architecture or a recent change in the user’s profile such as their name or email address. Anonymous downloading maybe permitted if the files are intended for download by the public.
For further discussion about the causes of authenticated, but anonymous users accessing files, please refer to “Anonymous or unknown people in a file” and “Anonymous animals” in the online support and documentation for Google Drive or Google Docs (https://support.google.com/drive). The problem is not exclusive to Google services, but their support documentation provides insights into how legitimate users may appear to an application or file log as authenticated but anonymous users.
Data Storage Services
CMS developed the following business rules and recommended practices for Data Storage Services within the CMS Processing Environments.
BR-DSS-1: Do Not Use UDP for Data Storage Services or File Transfer Services
Do not use the User Datagram Protocol (UDP) for File Storage Services or File Transfer Services.
Rationale:
UDP can be easily spoofed or intercepted.
RP-DSS-2: Use a Trust Relationship or Federation for Authenticated Access to CMS Files
To enforce BR-FSS-1 and maintain compliance with related CMS TRA requirements, configure file-level storage services to deny access to unauthenticated users and use an intermediary application to access the files managed by the file storage service. If both the intermediary application and the files storage service are unable to authenticate users directly with the CMS LDAP services, a CMS-approved directory trust relationship or federation method may be used to provide CMS users with temporary authentication to access the CMS files managed by the file storage service. Users must first authenticate using CMS credentials and a CMS authentication service before receiving temporary access to the CMS files managed by the file storage service.
Rationale:
A CMS-approved directory trust relationship or federation method enables CMS to know and log the identity of users accessing CMS files.
RP-DSS-3: Avoid Unnecessarily Separating Storage Clients and Storage Services into Different Zones
Using zones to separate storage clients from storage services may not be necessary. Mounting a storage service in one zone to a storage service client in another zone negates an important goal of CMS zone data separation because the storage service interface (API and file system directory) would be the same in both zones. Therefore, having a storage service client in a different zone from the storage service does not hide the storage service interface from the client’s zone, which is a goal of the CMS TRA Multi-Zone Architecture. Any protections this separation may provide may be outweighed by performance issues or other considerations. An exception is external storage services, such as those provided by remote storage providers or CSPs.
Please refer to Storage Service Concerns and Considerations for additional related guidance.
Rationale:
CMS recognizes that, in some circumstances, the design tradeoff decision for security and performance may be worth the risk to allow location of storage clients and storage services in the same zone.
RP-DSS-4: External Storage Services Are External to Any CMS Zone
External storage services, such as those provided by remote storage providers or CSPs, are external services. They may be accessible from a storage client in a zone, but are not themselves in a CMS zone, and must be treated as external services for CMS TRA compliance purposes.
Outbound communications with external services must traverse the CMS zones in the CMS TRA Multi-Zone Architecture. An exception may be allowed for a CSP-provided storage service when the storage client is in the same CSP hosting environment or if there is a secure VRF between the storage client and the storage service.
Rationale:
To be supplied.
RP-DSS-5: A Storage Service Data Store Should Not Be Accessible from More Than One Zone
A storage service data store (such as a single volume, bucket, or directory) should not be accessible from more than one zone. To provide access to data from more than one zone, a storage mediation service may be used. A storage mediation service may serve clients in multiple zones.
Rationale:
If the service is accessible from multiple zones, then it becomes a potential conduit for data transfer between zones. Having multiple storage mediation services for the same data store is allowed but may not be a best practice for data integrity or performance.
File Uniform Resource Locators
CMS developed the following BRs for File URLs within the CMS Processing Environments.
BR-URL-1: Authentication Is Required to Access a Non-Public CMS File Referenced by a URL
Unauthenticated downloading may be permitted if the files are intended for download by the public.
Rationale:
CMS must know the identity of users accessing CMS files. Securing Access above describes some approaches to systems designs that comply with this BR.
BR-URL-2: Authentication and Authorization Are Required to Upload a File to a CMS Location Referenced by a URL
Rationale:
CMS must know the identity of users sending or uploading files to CMS.
BR-URL-3: Logs Must Identify the Users Who Access a CMS File Referenced by a URL from the External Networks or CMSNet
Rationale:
CMS must know the identity of users accessing CMS files.
BR-URL-4: Logs Must Identify the Users Who Upload a File to a CMS Location Referenced by a URL from the External Networks or CMSNet
Some remote storage services allow the username of a user to change; therefore, the username alone is not adequate for logging purposes. Logged data from that service should include a user identifier that is not subject to change.
Rationale:
CMS must know the identity of users sending or uploading files to CMS.
BR-URL-5: URLs May Not Include Passwords or Decryption Keys
URLs may not include passwords or decryption keys.
Rationale:
CMS cannot control the protection of URLs in external networks or non-CMS environments, nor can it ensure only authorized use or sharing of URLs within CMS office automation systems. URLs with passwords or decryption keys pose the risk for unauthorized access to CMS services or data and may disclose sensitive passwords or decryption keys.
RP-URL-6: Use Signed URLs to Indicate the Source and Creation Time of a CMS File
Signed URLs for CMS files may be used to indicate the source, creation time, or other characteristics of a CMS file. A signed URL provides the user with some confidence that CMS is the source of the file. Including other characteristics of the file may help the user in processing the file or determining its validity. Signed URLs do NOT provide user authentication as required by BR-URL-1.
Rationale:
Signed URLs are an optional mechanism that may aid the user in processing CMS files or determining a file’s validity.
RP-URL-7: Use Time Limits and/or Click Limits to Control How Long a CMS File Is Available to Unauthenticated External Users for Download through a URL
Unauthenticated downloading without time limits and/or click limits may be permitted if the files are intended for download by the public. For non-public files, it is preferable to set time limits and/or click limits when providing external users with an externally accessible URL for a CMS file.
Although authentication is required to access a CMS file referenced by a URL (as specified by BR-URL-1), time limits and/or click limits provide additional Defense-in-Depth by impeding unauthorized users from taking advantage of a misconfiguration or compromised user account to try to download a CMS file.
CMS permits storing sensitive, PII, or PHI data temporarily in the Application Zone. Temporary files and cached data must be removed from the Application Zone once the transfer or processing is confirmed and successful or time limits and/or click limits have been exceeded.
Rationale:
Limiting the number of clicks on a URL (or the file downloaded) helps prevent unauthorized users from accessing the file. Having a time limit on how long the file is available for download ensures the file becomes unavailable to unauthorized users even if the authorized user never uses the URL to download the file.