Data Storage Services Introduction

This chapter addresses Data Storage Services generally as any form of online data storage, whether physical, virtual, shared, dedicated, or cloud. The services may include SAN, NAS, object stores, remote or network backup devices, and databases (when used to store files). The Data Storage Services, as defined in this chapter do NOT include dedicated, locally attached storage devices.

A special focus in this chapter is on a subset of data storage services called “File-Level Storage Services” or “File Storage Services,” which store data as files.

Storage Service Types, Access Methods, and Terms

This chapter classifies all data storage services and access methods as follows in Tables 10 and 11. The important terms used in this chapter are:

• Storage Service Client – Any component that directly accesses a data storage service. A storage service client may be a component of a business application, or a component of a storage mediation service. The component may be a driver, a data access layer, a utility, or a service.

• Storage Mediation Service – A service that uses a data storage service to store, retrieve, or manipulate files to meet the storage needs of one or more business applications. A storage mediation service hides from its clients the API and/or file directory structure of the data storage service and implements its own access controls.

Storage Service Types

This chapter classifies all data storage services into the generic storage types described in the table below: Generic Types of Data Storage Services.

Generic Types of Data Storage Services

Data Storage Service Type	Description	Directory and Access Control	Access Enforced By
Tape / Archival Storage	Used for offline storage, files are catalogued; requires multiple steps to locate and retrieve a given file in a catalog and in the storage media.	The service maintains the catalogs and locates files. File-level access control may not be available.	The service.
Block Storage	The device or partition is mounted by a customer’s OS, which implements a file system.	The customer’s OS implements a file system on the block device or partition.	The customer’s OS provides access controls over the files; the storage service may or may not provide access control over the block device or partition.
File-Level Storage (a.k.a., Object Storage)	Files are stored as file or blob objects.	The service maintains a file system to locate and retrieve files.	The service.

Access Methods

This chapter classifies all methods of accessing data storage services into the following five types of generic access as shown in Generic Access Methods for Data Storage Services.

Generic Access Methods for Data Storage Services

Access Method Type	Description	Directory and Access Control	Access Enforced By
Block Device Mount	The remote storage is mounted or mapped to appear as a block storage device or drive to the client OS. Example protocols: iSCSI	The customer’s OS implements a file system.	The customer’s OS provides access controls over the files; the storage service may or may not provide access control over the block device or partition.
Network File Share	May be used to access individual files or directories via URIs. The remote storage may also be mounted or mapped to appear to the client OS as a device or drive with a file system. When mounted, it can be multiuser, single user, or single session within the customer’s OS or browser. Example Protocols: NFS, CIFS, FTP, WebDAV	The service implements the remote file system.	The service enforces access control, and authorized users can change the access controls through the service.
Mirrored Network File Share	Similar to a Network File Share, except that a mirror copy on the client’s local drive periodically syncs with the remote storage and may be used when the remote storage is unavailable. Example Protocols: rsync or local client software using Network File Share protocols.	The service implements the remote file system. The file system of the local mirrored copy is managed by the customer OS and may be a different file system format.	The customer’s OS manages access control at the file system level; the service enforces access control.
Query-based	The service is queried like a database for files matching given criteria. Example protocols: SQL, ODBC	The service maintains a file system to locate and retrieve files.	The service enforces access controls. Authorized users using the service may change the metadata of files including access controls.
Uniform Resource Locator (URL)-based	Same as the Network File Share and Query access methods but using a URL. Example Protocols: WebDAV, SMB, FTP, Amazon S3	The service implements the remote file system.	The service enforces access control, and authorized users can change the access controls through the service.

All five access-method types are network based and describe shared, dedicated, or cloud storage services. Regardless of the method of access used, access to the file storage service, and to the CMS files managed by that service, must be limited to authorized authenticated users. The service must comply with all CMS TRA requirements in the effective Defense in Depth of CMS systems and CMS files.

Securing Access

In all storage service access methods, except for the Block Device Mount method, the access control is tied to user identities and/or roles defined in a directory domain used by the storage service. The directory domain may be local to the storage service or the CSP providing the storage service, or the storage service may use the CMS LDAP service.

To comply with the CMS TRA, users from external networks, CMSNet, or the CMS LAN must not have direct access to the CMS files persisted by the storage services in a Data zone and must use intermediate services in a Presentation and/or Application zone to access the persisted file data indirectly. This requirement applies for other services needing access to files. For example, an intermediate service may provide access to a temporary copy of the persisted file, with the temporary copy in the same zone as the intermediate service.

In addition, users from external networks, CMSNet, or the CMS LAN must be authenticated to access CMS files, unless those files are intended for the public. Therefore, the intermediate services or the storage service itself must authenticate users using a CMS directory domain.

A file storage service must be configured to deny access to all unauthenticated users and all unauthorized users. If the intermediate services, or the storage service itself, cannot directly use a CMS directory domain for authentication, there must be a CMS-approved trust relationship or federation mechanism between the service’s local or CSP-provided directory service and a CMS directory domain service.

The File URL topic has business rules concerning defensed in depth protections against unauthorized access to the CMS files managed by file storage services.

Some file storage services offer a way to address individual files using a network URL. If the URL is accessible from external networks, CMSNet, or the CMS LAN, additional defense-in-depth protections are required as described in File URL.

The reader should refer to other related CMS TRA and CMS ARS requirements that, in addition to the guidance presented here for File Storage Services, prohibit direct access to CMS data, require data encryption at rest and in transit, require files be stored in the Data Zone, prevent access to the Data Zone from other than the Application Zone, and prevent network traffic from traversing zones.

Storage Service Concerns and Considerations

System designs that include Data Storage Services should consider and address the following issues at a minimum:

• Mutual authentication. In the default configuration for most Data Storage Services, the service trusts its authenticated clients and users but the clients and users do not have a way to authenticate the service. Mutual authentication or other mechanisms should be considered even in circumstances when the CMS TRA does not require mutual authentication.

• Storage mediation services. A storage mediation service can hide the storage service interface and file system directory from other business application components. A storage mediation service or other mechanisms should be considered even in circumstances when the CMS TRA does not require storage mediation.

A common misconception is that the CMS TRA always requires separation of storage clients from storage services that use network zones and network gateways or firewalls. Although separation is a good practice, an acceptable alternative is to keep the client and storage service together in the same zone and allow the client to be accessed as a mediation service by other CMS services. By eliminating a gateway between the client and service, the alternative offers the following advantages:

• Improved performance and reliability

• The client’s credentials for accessing the service are not stored or exposed outside the immediate zone.

• The storage service’s interface and API are not exposed outside the immediate zone.

Naturally, when the storage service is external, it must be separated from storage clients by gateways and firewalls. There can be other circumstances where separation may be technically necessary or where it is easier to implement defense-in-depth mechanisms. The choice becomes an engineering tradeoff.

Please refer to RP-DSS-3 for additional related guidance.

Impeding Attacks

CMS TRA guidance and recommendations do more than lock down vulnerabilities and minimize attack vectors—,they also impede the progress of successful attacks. Impeding means to limit how far into CMS systems or data stores an attack may reach, or to force the attacker to engage in activities that increase the likelihood of detection. For storage services, the threat is an attack that succeeds in gaining access to a business application server or process that, in turn, has an interface with a storage service or a storage mediation service. With enough determination and sophistication, such an attack may eventually succeed in gaining access to CMS files, but it is more likely the attack will grab what is readily available from the compromised business application server or process. Therefore, impeding the progress of a smash-and-grab attack should be a design consideration for any system component that has direct access to a storage service or to a storage mediation service.

To protect the storage service from a smash-and-grab attacker on a compromised business application server or process, CMS requires establishing the following attack impedance priorities:

• Prevent the attacker from detecting the existence of the storage service.

• Prevent the attacker from having file system-like access to the files, such as through a mirrored, mounted, or mapped network file share.

• Prevent the attacker from having access to the file system directory, so the attacker does not know the existing files or directory structure.

To do this, on all application servers, CMS requires limitations on the users, local user, processes, or sessions that have access to a mounted or mapped network file share or block storage device. CMS prohibits mounting storage services at boot time or allowing all OS users and processes access to mounted storage services. When possible, the network file share should be mounted only within a user session, or only within a process, or only by specific non-root users.

This same principle of least privilege also applies to file transfer services. If an application uses a file transfer service, CMS recommends against using root or other privileged user accounts. Any user account should only see the least number of files necessary, and in the case of file upload, the user should only see files that the user has uploaded. In the case of file download, the user account should only see files the account is authorized to see.

Example Design Patterns

The following commonly used design patterns or approaches provide access to files managed by a File-Level Storage Service while maintaining compliance with related CMS TRA requirements. Other approaches may be possible, but the most common examples are:

• Mediated. Configure the File-Level Storage Service so the files are only available to an application server in the Application Zone. Configure the File-Level Storage Service to deny all except for a CMS-defined role held only by the application server. User requests are made to the application server, which retrieves a copy of the file for the user into either the application server’s memory or the application server’s dedicated local virtual block storage drive and file system. The copy of the file must be deleted or transferred to the File Storage Service when the user session is complete or the file is no longer needed by the application server.

• Federated. Configure the File-Level Storage Service to deny all except for a CMS-defined role. Then use federation (e.g., SAML) to give CMS users (authenticated through ePortal, for example) a temporary credential with the CMS-defined role that exists only during the user session.

The Mediated and Federated example approaches have these important characteristics:

• The File-Level Storage Service is configured to deny all except for a CMS-defined role.

• No one can access the file without first authenticating to CMS.

• Data encryption at rest and in transit is still required.

• An intermediary application accesses the files managed by the file storage service.

If the File-Level Storage Service permits file access by URL, the URL may safely be open to external networks (if necessary) when unauthenticated, and unauthorized disclosure via those networks is still prevented by ACLs, encryption, and other defense-in-depth mechanisms.