ShareFile Enterprise Security White Paper

Transcription

1 ShareFile Enterprise Security White Paper Providing security is essential when implementing an Enterprise class file sync and sharing solution Learn how ShareFile Enterprise provides industry-leading security measures to protect both ShareFile.com and our customer s data citrix.com/sharefle

2 White Paper Table of Contents Introduction SaaS application tier ShareFile servers: web, API, and database overview SaaS application tier security Encryption Hash-based message authentication code Metadata Citrix-managed StorageZones Overview Securing file upload/download requests Security Encryption in transit Encryption at rest Data backup Anti-virus Amazon Web Services security Microsoft Azure Security Customer-managed StorageZones with on-prem storage Overview Securing file upload/download requests Security Trust and encryption: on-premise StorageZone ShareFile StorageZones Controller server Encryption in transit Encryption at rest Customer-managed Restricted StorageZones Overview Encrypting file upload/download data and metadata Adding a document Enumerating files from the Restricted StorageZone External Access to encrypted file and metadata notifications Sharing/sending files Receiving a shared file Customer-managed StorageZones with Windows Azure storage Overview Securing file upload/download requests Security StorageZone Connectors Overview Securing File Upload/Download Requests Security Data Loss Prevention (DLP) integration Overview 2

3 White Paper Table of Contents Which DLP systems are supported? How ShareFile works to prevent data loss Information Rights Management Customer Managed Encryption Keys NetScaler integration Overview Requests for ShareFile data from on-premise data storage Securing ShareFile data upload/download requests with NetScaler Requests for data from StorageZones Connectors Securing ShareFile Connector upload/download requests with NetScaler SAML integration Overview Workflow Security and benefits Additional resources OAuth Overview Workflows Web authentication ShareFile credentials Parameter definitions Web authentication SAML Desktop apps Security and benefits Conclusion Appendix A. Mobile device security Appendix B. ShareFile web application security features 3

4 White Paper Introduction ShareFile is an enterprise follow-me data solution that enables IT to deliver a robust data sharing and sync service that meets the mobility and collaboration needs of users and the data security requirements of the enterprise. Securing data is critical to every enterprise and is a responsibility taken seriously by ShareFile. Savvy IT executives understand that with the plethora of free or low-cost data sharing applications available to end users, it has become critical to provide users with a more secure alternative that still empowers them to sync files across their devices and securely share files with co-workers. This paper explores the details of how ShareFile is secure by design, and highlights the set of security controls available to ShareFile Enterprise customers. Figure 1. ShareFile components overview with applicable ports 4

5 ShareFile consists of 3 primary components: the SaaS Application Tier, StorageZones, and the client. 1. SaaS Application Tier sometimes referred to the as the Control Plane, this is a Citrixmanaged component that consists of web, database, and API servers 2. StorageZones this is where customer data is stored. Customers have four options when deciding where to store their data. This paper will discuss the workflow and security processes of each option Citrix-managed cloud storage on Amazon Web Services Citrix-managed cloud storage on Microsoft Azure Customer-managed cloud storage on Microsoft Azure Customer-managed storage in corporate datacenters 3. Clients ShareFile supports a broad device list, which includes but is not limited to Windows and Mac OSX, Android and ios, Windows phone and Windows Metro 5

6 White Paper SaaS Application Tier ShareFile servers: web, API, and database overview The ShareFile SaaS Application Tier is hosted in Citrix s datacenter. The components include (see figure 2.): NetScaler used to load balance client requests to the ShareFile.com/eu webs and API webservers ShareFile.com/eu webservers designed to deliver the Web UI API webservers used for client devices and tools using the HTTPS and REST API, including the Outlook plug-in, mobile and sync applications Database SQL database instances which contain things such as account data, file and folder metadata, including access rights, user account data, logs etc. The database in the SaaS Application tier does not process or store any customer data files The NetScalers and web servers are installed in the DMZ with the SQL databases installed in the private network behind an additional firewall. The SQL database instances are securely replicated to a second datacenter for backup and disaster recovery purposes. Figure 2. SaaS Application Tier components overview SaaS application tier security Encryption To protect customer data in transit ShareFile supports TLS 1.2 with up to 256 bit AES encryption and no less than 128 bit encryption with the negotiation to TLS/AES-256 dependent on whether the end user s device or proxy supports TLS/AES-256. Hash-based message authentication code Hashing is defined as producing hash values for accessing data or for security purposes. A hash value (or simply hash) is a number generated from a string of text. The hash is substantially smaller than the text itself, and is generated by a formula in such a way that it is extremely unlikely that some other text will produce the same hash value. 6

7 White Paper In security systems, hashes are used to ensure that transmitted messages have not been tampered with. The sender generates a hash of the message, encrypts it, and sends it with the message itself. The recipient then decrypts both the message and the hash, produces another hash from the received message, and compares the two hashes. If the hashes are the same, it indicates that the message was transmitted intact. Metadata Customer files are never processed, stored or transferred to the ShareFile SaaS application tier. Instead we store metadata which when defined means data about data or data that describes other data. The metadata attributes that ShareFile stores in the SaaS application tier s database servers are as follows: User Info: First Name Last Name User Login ( Address) Company Name (Optional) Password Hash Security Question Security Answer Access Control Lists (ACL) File Info: File Name File Description File Location File Size File Hash File Creation Date Notification Access Control Lists (ACL) IP Address from which file was uploaded Other: Account Subdomains on ShareFile.com/eu Audit & Reporting 7

8 White Paper Citrix-managed StorageZones Overview ShareFile operates a hybrid cloud infrastructure, with separate application and storage tiers managed by separate entities. Citrix manages the SaaS application tier (no file content) while an enterprise class cloud services provider (either Amazon Web Services or Microsoft Azure, depending on customer contract) hosts the StorageZone servers, along with application servers running the FTP/FTPS, Antivirus, Indexing, and Thumbnail services. The Citrix-managed StorageZones architecture consists of the SaaS Application tier, StorageZone Controller server(s) and cloud storage (see Figure 3). Figure 3. Citrix-managed StorageZones architectural overview 8

9 Securing File Upload/Download Requests When a user uploads or downloads a file, ShareFile s architecture prevents forged requests by using hash-based message authentication codes or HMAC s. Figure 4. Preventing forged requests workflow diagram 1. Client requests a file. 2. A prepare message is sent by the ShareFile web application or API servers in the SaaS application tier to the StorageZone hosting the file. The location of the file is stored in the SaaS application tier database, accessed by the ShareFile web application and API servers. 3. A hash-based message authentication code (HMAC) based on the Shared Key used to establish a trust relationship between the SaaS application tier and StorageZone, is sent as part of the prepare message and is validated by the StorageZone Controller. 4. Once validated, the StorageZone confirms the validity and generates a unique one-time-use download token. 5. The ShareFile web application or API server provides the download link containing the fully qualified domain name (FQDN) of the StorageZones controller to the client with the unique download token. 6. To start the actual download, the client connects directly to the StorageZone. 7. The download token (part of the download request from the client), is validated. 8. If validation is successful, the file will be retrieved from storage, and the StorageZone will provide the file to the client. 9

10 Security Encryption in transit Client files are protected in transit between the web application and storage tier using TLS with no less than 128 bit encryption depending on end-user browser configuration. Encryption at rest All client files are encrypted using AES 256-bit symmetric key encryption, a FIPS approved encryption algorithm. Data backup Customer files are stored redundantly within the cloud storage provider s region and ShareFile backs up all files daily. We store and back up customer files according to the data retention and version settings your dedicated ShareFile admin configures via the ShareFile administrative web interface. Anti-virus We employ dedicated antivirus servers that, based on customer preference, can scan all client files for malware. Any infected file is marked with a Red exclamation mark to warn end users of the risk associated with downloading an infected file. Amazon Web Services security The ShareFile infrastructure is segmented logically from other vendors using a concept Amazon Web Services refers to as Security Groups. Think of security groups as a firewall-like implementation that segregates ShareFile s infrastructure from other vendors. Amazon EC2 provides a firewall solution to enable security groups; this mandatory inbound firewall is configured in a default deny mode and we must explicitly open any ports to allow inbound traffic. The traffic may be restricted by protocol, by service port, as well as by source IP address (individual IP or CIDR block). Amazon Web Services runs in geographically dispersed datacenters that comply with key industry standards for security, reliability and confidentiality, such as ISO/IEC 27001:2005, SOC 1 and SOC 2. Microsoft Azure security Like Amazon Web Services, Windows Azure runs in geographically dispersed datacenters that comply ISO/IEC 27001:2005, SOC 1 and SOC 2. Datacenters are managed, monitored, and administered by Microsoft operations staff that have years of experience in delivering the world s largest online services with 24 x 7 continuity. In addition to datacenter, network, and personnel security practices, Windows Azure incorporates security practices at the application and platform layers to enhance security for application developers and service administrators. 10

11 White Paper Customer-managed StorageZones with on-prem storage Overview Customer-managed StorageZones allow IT administrators to choose where corporate data will be processed and stored. IT can store data in the organization s datacenter to help meet unique data sovereignty and compliance requirements, or an organization can choose to host ShareFile data natively in a Microsoft Azure account, helping IT build the most cost-effective and customized solution for their organization. The on-premise customer-managed data can be easily integrated with an organization s existing infrastructure as it is designed to support any Common Internet File System (CIFS)- based network share. In both options the SaaS application tier is a required component. The customer-managed on-premise architecture consists of the SaaS Application tier, StorageZone Controller server(s) and customer datacenter hosted backend storage (see Figure 5). Figure 5. Customer-managed on-premise StorageZones components diagram 11

12 Securing file upload/download requests The workflow is the same as Citrix-managed StorageZones. The ShareFile architecture in customer-managed StorageZones prevents forged upload and download requests by using hash-based message authentication codes (HMAC) as well. Figure 6. Preventing forged requests workflow diagram 1. Client requests a file. 2. A prepare message is sent by the ShareFile web application or API servers in the SaaS application tier to the StorageZone hosting the file. The location of the file is stored in the SaaS application tier database, accessed by the ShareFile web application and API servers. 3. A hash-based message authentication code (HMAC) based on the Shared Key used to establish a trust relation between the SaaS application tier and StorageZone, is sent as part of the prepare message and is validated by the StorageZone Controller. 4. Once validated, the StorageZone confirms the validity and generates a unique one-time-use download token. 5. The ShareFile web application or API server provides the download link to the Client with the unique download token. 6. To start the actual download, the Client connects to the StorageZone. 7. The download token (part of the download request from the Client), is validated. 8. If validation is successful, the file will be retrieved from storage. 9. The StorageZones controller server will send the file to the Client. 12

13 Security Trust and encryption: on-premise StorageZone Shared Zone Secret Key created when StorageZone is created. Storage Encryption Key created when StorageZone Controller Encryption Key is encrypted by Passphrase when StorageZone Controller is configured. Figure 7. Security related SZ Controller configurations ShareFile StorageZones Controller server Once the pre-requisites for installation are met, installing the StorageZones Controller server software is simple and consists of launching an.msi file and clicking through until finished. Pre-requisites: Use a publicly-resolvable Internet hostname (not an IP address) Install a commercially trusted TLS certificate in IIS Allow inbound TCP requests on port 443 through the Windows firewall The installation file installs the following server components: A virtual directory and files into the IIS Default Web site. The physical location of the folder and files is c:\intetpub\wwwroot\citrix\storagecenter. An IIS application pool named StorageCenterAppPool. The installer also points the IIS Default Web Site s application pool to the newly created StorageCenterAppPool application pool. 4 windows services: ShareFile Cloud Storage Uploader Service ShareFile File Cleanup Service ShareFile File Copy Service ShareFile Management Service After installing the StorageZones Controller server software, configuration is required. Instructions on configuring the StorageZones Controller software can be found here. The configuration utility accomplishes the following tasks (see Figure 7): Creates a shared zone secret key in the customer s ShareFile account and on the StorageZones Controller server stored encrypted in the registry. Creates a storage encryption key (SCKeys.txt) and encrypts that key using 128 bit encryption when a passphrase is entered in the last step of the configuration. This encryption key is only used if the Enable Encryption box is checked during configuration which instructs the StorageZone Controller server to encrypt the files stored in your shared ShareFile data repository. 13

14 Creates a proprietary folder structure and the SCKeys.txt file in the ShareFile Storage Location network share location defined during the configuration. Enables StorageZone Connectors if Enable StorageZone Connector for Network File Shares and Enable StorageZone Connector for SharePoint are checked. Enabling the Connectors creates the IIS apps cifs (Connector for Network File Shares) and sp (Connector for SharePoint). Encryption in transit If a NetScaler is not used in the architecture, customer files are protected in transit between the web application and the customer-managed on-premise storage location using TLS with a minimum 128 bit encryption depending on end-user browser or proxy configuration. If customers are using Windows Azure, files are protected in transit between the web application and the customer-managed on-premise storage location and to the Windows Azure storage container using the same TLS protocols as above. If a NetScaler is used in the architecture, the TLS connection will be terminated at the NetScaler in the DMZ and files will be sent to the storage location either over http or https, depending on your configuration. If HTTP is used, files will traverse the internal network to the storage location un-encrypted. If HTTPS is used, files will traverse the internal network to the storage location using TLS. The storage server will then decrypt the files and store them. Encryption at rest The StorageZones Controller software has the ability to encrypt the files located in the Storage Location defined during configuration. If data encryption is enabled, all zone files are encrypted with 128 bit encryption using the same key stored in SCKeys.txt. It is therefore critical that the SCKeys.txt file and passphrase be backed up to a secondary secure location. If the SCKeys.txt file is lost, all zone files become inaccessible. Because this directory resides in a customer- managed datacenter it is a Citrix best practice to not have the StorageZones Controller software encrypt the data and leverage encryption options from your storage subsystem instead. If encrypted by the StorageZone Controller software, processes like anti-virus scanning and file indexing will not work. If customers are using Windows Azure, the StorageZones Controller software has the ability to encrypt the files located in the temporary storage location defined during configuration. If the files are encrypted they will be transferred to the Windows Azure storage container encrypted. Decryption happens when a file is requested for download. The file gets copied from the Azure storage container to the temporary storage location in the customer datacenter where it is decrypted and sent from the StorageZones controller server to the client. All communications from the StorageZones servers and Windows Azure storage containers happen over TLS. 14

15 White Paper Customer-managed Restricted StorageZones Overview In some highly regulated industries and organizations, having ShareFile data stored in customer-managed on-premises StorageZones still presents some privacy concerns. The first is that metadata, specifically file and folder names are still visible to Citrix, and secondly, as the authentication provider, Citrix must be trusted to authorize access to files. Customer-managed Restricted StorageZones is the solution to this problem. The onpremises StorageZones Controller encrypts the metadata with a customer-owned encryption key before writing that data to the Citrix SaaS application tier (sharefile.com/ sharefile.eu). Access to decrypted files and metadata only happens via the StorageZones Controller server, which acts as an authenticating encryption/decryption proxy. Figure 8. Customer-managed Restricted StorageZone Encrypting file upload/download data and metadata During the configuration of a Restricted StorageZone, customer-owned private encryption keys are created and used for the encryption and decryption of file data and metadata. An HTTPS binding occurs to a new proxy service used to authenticate all requests to the Restricted StorageZone and serves as the only communication path to that Restricted StorageZone. Adding a document 1. Unencrypted file and metadata is uploaded from a client to the StorageZones Controller via the proxy service 2. Both the file and metadata are encrypted with the customer-owned encryption key 3. Encrypted file metadata is uploaded to ShareFile with a sample file name of!zk!@ OwYB92ryh-m9MvrQ6ejLQ$$!ZK! 4. Encrypted file is written to the Restricted StorageZones repository Enumerating files from the Restricted StorageZone 1. User logs in to ShareFile using either ShareFile credentials or via SAML and Active Directory. 2. The user is redirected to the StorageZone Controller s proxy service with a request for metadata. 15

16 White Paper 3. The StorageZone Controller initiates an authentication to Active Directory prompting the user for domain credentials with appropriate permissions to view encrypted metadata. As part of the authentication process, the StorageZones Controller server also verifies that the address in Active Directory matches the address used to authenticate to ShareFile. 4. The StorageZone Controller server fetches the encrypted metadata from ShareFile and decrypts it for the user. 5. The unencrypted metadata is returned to the client. External access to encrypted file and metadata Encrypted file and metadata are being delivered from the customer-managed StorageZones Controller server. For this reason, to enable access for users not on the internal network or VPN, a NetScaler Gateway is used to server as the Restricted StorageZone s external domain address. The architecture is similar to how we architect authentication to SharePoint and Network Share connectors (section 8). The traffic headed to those connectors is stopped at the NetScaler in the DMZ, authenticated and then those credentials are passed to the appropriate location using SSO. With Restricted StorageZones all traffic destined for the StorageZone Controller server can be stopped at the NetScaler, authenticated and credentials passed back to the StorageZone Controller using SSO. notifications The ShareFile SaaS application tier cannot see the folder and file names, therefore sharing and upload/download notification s cannot be sent by Shar efile. Using Restricted Zones, customers will need to point to an SMTP server that is reachable by the onpremises StorageZones Controller server. Notification content with encrypted info is downloaded by the StorageZones Controller via the use of an Azure service bus, decrypted, and then sent via SMTP. Sharing/sending files 1. Client initiates the request to share an encrypted document 2. The share object is requested and digitally signed by the StorageZones Controller 3. In ShareFile a share message object is created with encrypted file names 4. The StorageZones Controller downloads the encrypted message using the Azure service bus 5. The message is decrypted by the StorageZones Controller server and sent to the SMTP server where it is sent to all recipients Receiving a shared file 1. User clicks the Share URL from ShareFile.com 2. ShareFile.com redirects the user to the StorageZones Controller server where they are required to authenticate with Active Directory credentials 3. After successful authentication the StorageZones Controller fetches the signed shared object, validates the signature and enforces security policies 4. The file is obtained from the StorageZone data storage repository and delivered to the client from the StorageZones Controller server 16

17 White Paper Customer-managed StorageZones with Windows Azure storage Overview The Microsoft Azure customer-managed solution (Figure 8) integrates ShareFile with Microsoft Azure s Binary Large Object (Blob) storage, a cloud service for storing large amounts of unstructured data that can be accessed from anywhere in the world via HTTP or HTTPS. The Azure Storage architecture is similar to the customer-managed on-premise StorageZones architecture with one minor difference. Azure storage is customer-managed storage hosted in the Azure cloud. File uploads are initially deposited into a temporary storage area shared by all StorageZone controllers. Then, a background service copies those files to the Windows Azure storage container and deletes the local cached copy of the file(s). Figure 9. Customer-managed StorageZones with Windows Azure components diagram 17

18 Securing file upload/download requests Overview Because the architecture is very similar to the customer-managed on premise StorageZones architecture, the workflow is the same with one small difference highlighted in bold below. Figure 10. Preventing forged requests workflow diagram 1. Client requests a file. 2. A prepare message is sent by the ShareFile web application or API servers in the SaaS application tier to the StorageZone hosting the file. The location of the file is stored in the SaaS application tier database, accessed by the ShareFile web application and API servers. 3. A hash-based message authentication code (HMAC) based on the Shared Key used to establish a trust relation between the SaaS application tier and StorageZone, is sent as part of the prepare message and is validated by the StorageZone Controller. 4. Once validated, the StorageZone confirms the validity and generates a unique onetime-use download token. 5. The ShareFile web application or API server provides the download link to the Client with the unique download token. 6. To start the actual download, the Client connects to the StorageZone. 7. The download token (which is part of the download request from the Client), is validated. 8. If validation is successful, the file will be retrieved from Windows Azure storage and placed in the shared storage location in the customer datacenter. 9. The StorageZones controller server will send the file to the Client. 18

19 Security The installation of the StorageZones controller software is identical to the customermanaged on premise installation instructions, but the configuration of the software requires some additional steps. Instructions on configuring the StorageZones Controller software with Windows Azure support can be found here and there is a video of the configuration located here. The configuration utility accomplishes the following tasks (see Figure 7 above) with the difference in configuration in bold below: Creates a shared zone secret key in the customer s ShareFile account and on the StorageZones Controller server stored encrypted in the registry. Creates a storage encryption key (SCKeys.txt) and encrypts that key when a passphrase is entered in the last step of the configuration. This encryption key is only used if the Enable Encryption box is checked during configuration which instructs the StorageZone. Controller server to encrypt the files stored in your shared ShareFile data repository Creates a proprietary folder structure and the SCKeys.txt file in the ShareFile Storage Location network share location defined during the configuration. Enables StorageZone Connectors if Enable StorageZone Connector for Network File Shares and Enable StorageZone Connector for SharePoint are checked. Enabling the Connectors creates the IIS apps cifs (Connector for Network File Shares) and sp (Connector for SharePoint). Connects the StorageZones controller server to the Windows Azure account using the account name and 512-bit authentication key generated in Azure when the Azure storage container is created. Once the StorageZones controller authenticates to Azure the administrator is presented with a list of available storage containers to choose from for the ShareFile data storage location. 19

20 White Paper StorageZone Connectors Overview ShareFile StorageZone Connectors, enabled by a customer-managed implementation of a StorageZones controller server, help organizations leverage and mobilize existing enterprise data platforms. This feature, available in the ShareFile mobile app for iphone, ipad and Android devices, allows mobile users to create a secure connection to existing CIFS network shares and SharePoint document libraries. The StorageZone Connectors architecture consists of the SaaS application tier, a customermanaged implementation of a StorageZones Controller server, network shares and SharePoint document libraries. Figure 11. StorageZone Connectors component architecture 20

21 Securing file upload/download requests Figure 12. StorageZone Connectors workflow diagram without NetScaler 1. User login request sent to subdomain.sharefile.com 2. Top-level StorageZone connectors are displayed 3. User login request sent to organizations Active Directory 4. User authenticated to Active Directory 5. Network shares enumeration 6. SharePoint document libraries enumeration 7. Files are uploaded/downloaded Security When using StorageZone Connectors, an additional authentication step (Step 3 in Figure 10) is introduced when users access a Connector, and the file upload/download authorization step from sharefile.com is removed. Additional StorageZone Connectors security information: Clients always use HTTPS when initiating connections to the StorageZones Controller HTTPS Basic authentication is required to support all mobile applications Passwords are never sent in clear text by ShareFile clients ShareFile administrators can control through user permissions which users have the ability to create connectors Administrators can also whitelist/blacklist connectors to specific file shares and SharePoint libraries 21

22 White Paper Data Loss Prevention (DLP) integration Overview ShareFile integrates with several market-leading Data Loss Prevention (DLP) products enabling content-aware sharing restrictions. Documents stored in your on-premises StorageZone can be examined by any third-party DLP security suite that supports ICAP, a standard network protocol for inline content scanning. Sharing and access privileges can then be adjusted based on the results of the DLP scan and your preferences for how strictly you want to control access. Which DLP systems are supported? Because we rely on the ICAP standard for interaction with your DLP server the ShareFile DLP integration will work with any ICAP-compliant solution and requires no changes to policies or servers in your existing security suite. ICAP-compliant solutions include: Symantec Data Loss Prevention McAfee DLP Prevent Websense Forcepoint Tying ShareFile security policies to your existing DLP security suite means you can maintain a single point of policy management for data inspection and security alerts. If you already use one of the solutions mentioned above for scanning outgoing attachments or web traffic, you can point the ShareFile StorageZones Controller to the same server. How ShareFile works to prevent data loss Figure 13. Graphical overview of DLP integration solution. 22

23 We ve developed a flexible policy-based system that offers granular access and sharing controls based on a new classification attribute that will be associated with each file. The system uses the DLP scan results to classify every version of every file in your StorageZone. There are three data classifications: 1. Scanned: OK Files that were scanned by a DLP system and passed OK 2. Scanned: Blocked Files that were scanned by a DLP system and were found to contain sensitive data 3. Unscanned Files that have not yet been scanned (in cases where files exist before DLP is configured, or when the external DLP system is unavailable or slow to respond) Next, the ShareFile platform enforces different access and sharing restrictions for each data classification. For each of the three categories, the ShareFile administrator chooses which actions to allow: Whether employees can download or share the file Whether 3rd-party users can download share the file Whether anonymous users can download the file These settings constrain the normal permissions and sharing controls available to users as they interact with their ShareFile data and collaborate with others. For instance, when sending someone a file, users could choose to block anonymous access even if DLP settings would allow them to share it anonymously. But if they attempt to share a file in a way that the DLP settings prohibit, the platform prevents them from doing so. This flexibility allows you to control the trade-offs between security and usability as best fits your organization. If a document is flagged as sensitive, you could still allow sharing between employees but block sending to anyone outside your organization. Or you could take a stricter approach and block all users (even the owner of the file) from downloading or sharing the file with anyone. If you block downloads, an employee would not be able to access ShareFile from an unmanaged device, get the file and share it by other means. For any files that are not yet scanned, you can configure the same sets of constraints. This means ShareFile could take an innocent until proven guilty or guilty until proven innocent approach according to your approach for impeding the flow of information. When the StorageZones Controller sends files to the DLP system for scanning, it includes metadata indicating the owner of the file and the folder path where the file resides in ShareFile. This allows the DLP server to log incidents and create notifications with enough detail to be actionable. 23

24 White Paper Information Rights Management Overview When you are working with an application or service like ShareFile, control over access to content can be easily maintained as long as the end-users interact and share content with other users of the same service. This works great as long as the interaction is contained within the application. However, in the world where mobility is becoming the norm and users have the ability to download applications, the control can disappear once the document leaves the application. With the ever growing mobilization of the workforce, data has a tendency to develop legs. Once the recipient has downloaded a file, the authentication and authorization controls no longer apply. They are free to re-distribute that file to anyone using any means (USB drive, attachment, Personal cloud account, etc.). A file you intended to only be seen by one recipient, suddenly has found its way to an unauthorized user that you never intended. How can I ensure that content I sent to a recipient is only viewed by that person? This is where Information Rights Management or IRM can help. It s a follow-me security model that allows for security protections to continue being enforced no matter where the data goes. Securing documents likely means different things to different people. If you are familiar with the on-premises world, its defined as securing at the share level and then maybe the file and folder level. But in the mobile-first, cloud enabled world this means something different and you need a security model that allows defined security settings to follow documents. 24

25 White Paper Information Rights Management applies file-level encryption, authentication and authorization controls to downloaded documents. You set some very simple and straightforward sharing permissions to a file you intend to send to a collaborator. Controls like: Whether the document can only be viewed Whether it can view and printed Or whether it can be view, printed or edited Those permission controls will be packaged with the file. This results in securing the file no matter where it lives or ends up. The great thing is, at any point in time if you no longer desire the recipients to have access, you can revoke the share and thus removing their access. What can I control using Rights Management for ShareFile? The following are the actions that you can control when using Rights Management for ShareFile: Limit access to browser view only Require Authentication to open downloaded file Revoke access to downloaded file Apply watermark Block printing and the clipboard Expire access after a set number of days Amount of time offline file access is allowed Allow Editing Screen sharing or screenshots How it works To explain how this works we will use an example where Bob is working on a project with Alice an outside consultant. Bob needs to collaborate with Alice and needs to share a document with her regarding the project. Bob wants to control how the file is used after he shares it with Alice, 25

26 White Paper 1. Bob selects a file he has stored in ShareFile that he wants to share with Alice. This file is stored in a StorageZone that is associated with an on-premises storagezone controller. 2. Bob defines Rights Management Security settings to be applied to the file he intends to share. The ShareFile StorageZone Controller will obtain an encryption key from the Rights Management policy server located within the ShareFile control plane and wraps the file using this encryption key. 3. Bob sends the file to Alice, who subsequently downloads the file. Alice then attempts to open the downloaded file. At this time she will need to authenticate to ShareFile and the Rights Management policy server will be consulted for the allowed permissions. This check is done in real time and the permissions are also enforced in real time. Up to this point all of the interaction between Bob, Alice and the file have been with ShareFile. During her interaction with the file Alice decides that she needs to consult Charlie for guidance. However, Charlie is not authorized to view content associated with the project. Alice isn t aware of this and shares the file with Charlie anyway. 4. Alice constructs an to Charlie and attaches her downloaded copy of file to the Charlies receives the and attempts to open the attached file. At this point the file open will initiate a process where ShareFile and the Rights Management Policy server will be consulted. This is similar to the earlier process where Alice s permissions are checked in real time. 6. The open request will be disallowed as Charlie will not be able to authenticate to ShareFile. This will result in the Rights Management policy server being unable to validate the actions attempted on the file. Even though Charlie has a physical copy of the file, it is still wrapped with the initial security settings defined by Bob back in step #2. Just because a copy of the file was downloaded by Alice the Rights Management setting were not removed. To provide this level of security, Citrix ShareFile has partnered with Seclore to provide this follow-me security model. Securing files within ShareFile is easy and is extended to sharing via the web UI, Outlook Plug-in, ios and Android devices and the ShareFile Desktop. In order to utilize Rights Management with a share, the sender will select from a list of straightforward sharing options: 26

27 White Paper View and Print This allows a recipient to only be capable of printing or viewing the file. They will be unable to edit the file View, Print and Edit This will allow essentially full control on a shared file. View (online and offline) Recipient will be allowed view only. No printing or editing abilities will be provided to the recipient. Should a user download the file and later go offline, they will still be allowed access to the file for a period of time while offline. As the above example shows, there is a direct interaction between the recipient and the ShareFile environment. In order to allow a user to download a file and work offline, that interaction has to be suspended in order to allow continued access. This is important when somebody is in an environment where they do not have internet access available to them (travelling, in a customer site with no available access, etc). When a file is downloaded and offline use is allowed, the user will be granted access offline for a defined period of time. A timer will begin. As long as the user is offline and the period of offline access is not exceeded, they will be allowed to work with the file. Once the offline access period expires, the user will be required to restore online access in order to continue working with the file. This is done to ensure there is a periodic check available to validate the recipient s access rights and usage ability has not been revoked or changed. What is required for this to work In order for a recipient to work with protected files there is additional software they will need to install. This software is available for Mac OS, ios / Android and Windows operating systems. When a recipient receives a rights management protected share and they do not have the software installed, the recipient is presented with a page that provides further guidance on how to interact with the file. Should a recipient not download the necessary software and attempt to open the file, they will be presented with an additional message advising them hey have received a protected document. The document will display a user friendly unencrypted message that references similar details as above. 27

28 White Paper This level of protection is available across a wide range of file types. Information Rights Management settings can be applied to traditional office types, PDF, TXT/RTF files, Open Office, image files (bmp, jpg, png, tif), AutoCAD / AutoDesk and Visio. As of the last published date of this document the solution is supported for the on-premises deployment of ShareFile storagezone data. In addition to the above the environment will need a ShareFile Storagezone controller deployed and configured to store customer data on-premises. You will need to ensure that your storagezone controller is running the latest revision of the ShareFile storagezone controller software. There is no additional software to deploy beyond those requirements. The Information Rights Management server software and infrastructure itself is deployed and managed by Citrix within the ShareFile application tier or control plane. 28

29 White Paper Customer Managed Encryption Keys Overview ShareFile provides customers with flexibility in storing content through our StorageZones architecture. Customers can choose between hosting content entirely in the cloud in a ShareFile Managed zone, on-premises via our StorageZone Controller software, in your own cloud storage container and finally a hybrid approach that uses a combination of the previous options. Some primary factors considered when deciding which option to use are: performance (proximity to primary user base), compliance / regulatory or geographic specific needs. Beyond the above, security becomes the next concern for customers how is my data secured if I select to store my data entirely in the ShareFile cloud? Data stored within the ShareFile cloud is always encrypted utilizing encryption keys generated by the ShareFile service. Even with this level of assurance by Citrix, this still can present some hesitancy by customers to adopt the service due to a lack of provider trust. Customers desire the ability to control the encryption of content in the cloud using their own encryption keys and subsequently be capable of revoking access should they have the need to for security reasons. This is where customer managed encryption keys offered by ShareFile can assist. What are Customer Managed Encryption Keys ShareFile Customer Managed Encryption Keys is a feature leveraging Amazon s Key Management Solution to assist customers in providing the data security control they desire. Customer files will still reside within the ShareFile application, but the generation (and control) of the encryption keys will occur within Amazon KMS. What is Amazon KMS? It s a service offered by Amazon utilizing two kinds of keys to secure content: Master and Data Keys. An Amazon KMS customer will have a single master key that can be used to encrypt or decrypt up to 4KB of data but more importantly it s used to generate / protect data keys. As a feature available to ShareFile the KMS master key is only used to generate and protect data keys. The actual encryption of data will occur within ShareFile. A master key is stored securely within a customer s Amazon KMS account and never exported outside of that environment. In contrast, a data key can be generated and exported outside of the KMS environment. So how does Amazon KMS work when generating data keys and securing data: 1. A request is initiated to encrypt data using a Customer s Amazon KMS account by a service or application 2. The Request is sent to Amazon KMS 3. Within an Amazon KMS Customer account their Master Key will generate (2) data keys: one plain text and one encrypted copy of the plain text key 4. Both of these keys are returned to the requesting service. 5. The requesting service will utilize the plain text key to encrypt the data to be stored in the service 6. Once the data has been encrypted by the service, the plain text copy of the key is discarded. 7. The service will write the encrypted file to disk and alongside it the encrypted copy of the data key used to secure the file. The encrypted copy of the data key will be used later for decrypting the stored data. 29

30 White Paper The benefit of this solution is that it simplifies the management of encrypted data and at the same time it allows for a level of trust to be established between the cloud service provider and the customer. After the data has been stored within the service in encrypted format, should someone gain access to the data they would be unable to open the file without having the ability to decrypt the secured file. This moves the control over encryption closer to the customer. If a file encrypted with KMS need to be accessed the following steps are followed to decrypt the file: 1. A client or application makes a request to access a KMS encrypted file to the service storing the file. 2. The service initiates a conversation with Amazon KMS, sending the encrypted data key associated with the saved file over to be decrypted 3. Amazon KMS will utilize the associated customer master key to decrypt the encrypted data key 4. Amazon KMS will return the plaintext copy to the requesting service that initiated the conversation 5. The service will use the plaintext key to decrypt the file requested by the client / application 6. The service will discard the plaintext copy of the key and return the now unencrypted file to the requesting client or application So how does all of this fit into the context of ShareFile. Below are brief walk-throughs of uploading and downloading files from ShareFile when using Customer Managed Encryption Keys. Upload a file to ShareFile 1. Customer initiates a request to upload a file to their ShareFile cloud StorageZone 2. ShareFile initiates a conversation with Amazon KMS associated with the Customers KMS Account. Requesting a data key that can be used to encrypt the file 3. Amazon KMS generates the plain text data key and the encrypted copy, returning both to ShareFile 4. ShareFile encrypts the customers file using the plain text key and discards the plaintext key. The encrypted copy of the key and the encrypted customer file are then stored in ShareFile 30

31 White Paper Download a file from ShareFile 1. Client initiates a download of a file secured via a KMS encryption key. ShareFile retrieves the encrypted file and the associated secure data key (ie: encrypted data key). 2. ShareFile initiates a conversation with Amazon KMS and sends the encrypted data key to KMS 3. Amazon KMS locates the master key associated with the KMS customer, decrypts the data key and returns the plain text data key back to ShareFile 4. ShareFile now decrypts the file using the plain text copy of the key. The plain text copy of the key is discarded and the requested file is returned to the client initiating the download request. As you can see the reliance on securing data is heavily dependent on the customers Amazon KMS Master key. At any point the customer can revoke ShareFile s access to their Master Key. Once access has been revoked it would it would make all the data secured using data keys tied to that master key inaccessible. Currently this security feature is supported for cloud storage zones only. If an environment is using theon-premises storage model having deployed a Citrix ShareFile StorageZone controller, the control over encryption keys is already within the customer s domain. When using onpremises storagezone a customer has option of using encryption through StorageZone controller itself or take advantage of the encryption services available on the destination CIFS repository where the on-premises data is stored. Once the feature is enabled and configured for a ShareFile account only new data will use the customer managed keys. Data stored prior to enabling the feature will use ShareFile encryption keys for storage. The feature is designed to work in parallel to existing ShareFile encrypted files. 31

32 White Paper NetScaler integration Overview A demilitarized zone (DMZ) provides an extra layer of security for the internal network. A DMZ proxy, such as Citrix NetScaler VPX, is an optional component used to: Ensure all requests to a StorageZones originate from sharefile.com or sharefile.eu, so that only approved traffic reaches the StorageZone Controllers Validates URI signatures before forwarding messages to StorageZone controllers reducing load on the StorageZone controllers Load balance requests to StorageZone Controllers using real-time status indicators Offload TLS from StorageZone Controllers Ensure requests for files on SharePoint or network drives are authenticated before passing through the DMZ In this scenario, two firewalls stand between the Internet and the secure network. StorageZone Controllers reside in the internal network. User connections to ShareFile must traverse the first firewall and use the TLS protocol on port 443 to establish this connection. To support this connectivity, you must open port 443 on the firewall and install a public TLS certificate on the NetScaler appliances (if they terminate the user connection). 32

33 Figure 15. NetScaler configuration architectural diagram NetScaler content switching virtual server sends user requests for data from ShareFile and from StorageZones Connectors to the appropriate NetScaler load balancing virtual server NetScaler load balancing virtual server Load balances the traffic for your StorageZones Controllers and also handles requests for data from your on-premise data storage and from StorageZone Connectors Requests for ShareFile data from on-premise data storage A load balancing virtual server performs hash validation, to ensure valid URI signatures are present on incoming requests. Figure 16. NetScaler configuration architectural diagram for ShareFile data Securing ShareFile data upload/download requests with NetScaler The following diagram and table describe the network connections that occur when a user logs onto ShareFile and then downloads a document from an on-premise storage zone deployed behind NetScaler. File activity is accessed via NetScaler in the DMZ, which terminates TLS, authenticates user requests and then accesses the StorageZone Controller in the trusted network on behalf of authenticated users. The NetScaler external address for ShareFile is accessed using the Internet FQDN szc.company.com (See Figure 17). 33

34 Figure 17. Securing requests for on-premise ShareFile data with NetScaler 1. The client makes a user logon request to company.sharefile.com over HTTPS 2. The client makes a file/folder enumeration and download request to company.sharefile. com over HTTPS 3. A file download authorization comes from sharefile.com to the szc.company.com (external address) over HTTP(S) 4. A file download authorization is sent from the NetScaler NSIP to the StorageZones Controller over HTTPS 5. A file download request comes from the Client to the szc.company.com (external address) over HTTPS 6. A file download request is sent from the NetScaler NSIP to the StorageZones Controller server over HTTP(S) 7. The file is downloaded In between steps 4 and 5 the NetScaler strips the HMAC from the URI and sends the URI & HMAC to the StorageZones Controller server. The HMAC is validated by the StorageZones Controller server which then sends confirmation to NetScaler. The process completes and file is uploaded or downloaded. Requests for data from StorageZones Connectors A load balancing virtual server performs user authentication. It stops a user request at the NetScaler, authenticates the user, and then performs single sign-on of the user to the StorageZones Controller. Although authentication to NetScaler is optional, it is a recommended best practice. 34

35 Figure 18. NetScaler configuration architectural diagram for StorageZone Connectors Securing ShareFile Connector upload/download requests with NetScaler The following diagram and table extend the previous scenario (see Figure 17) to show the network connections for StorageZone Connectors. This scenario includes the use of NetScaler in the DMZ to terminate TLS and perform user authentication for Connectors access. Figure 19. Securing requests for ShareFile Connector data with NetScaler 1. The client makes a user logon request to company.sharefile.com over HTTPS 2. The client requests top-level connector enumeration from company.sharefile.com over HTTPS 3. The client then sends a user logon to the StorageZones Controller server via the szc. company.com (external address) over HTTPS 4. The user is authenticated from the NetScaler SNIP to the AD domain controller over LDAP(S) 5. The NetScaler SNIP sends file/folder enumeration and upload/download requests to the StorageZones Controller over HTTP(S) 6. The StorageZones Controller server sends network share enumeration and upload/ download requests to the customer file server over CIFS or DFS 7. The StorageZones Controller server sends SharePoint enumeration and upload/ download requests to the internal customer SharePoint server over HTTP(S) 35

36 White Paper SAML integration Overview Security Assertion Markup Language (SAML) is a standard for exchanging authentication and authorization data between security domains. SAML is an XML-based protocol that uses security tokens to pass information about a principal (usually an end user) between a SAML authority, (an identity provider), and a SAML consumer, (a service provider). SAML enables web-based authentication and authorization scenarios including cross-domain single sign-on (SSO), which helps reduce the administrative overhead of distributing multiple authentication tokens to an end user. ShareFile supports single sign-on via SAML 2.0 and integrates with a number of federated identity management solutions. ShareFile requires SAML assertions to include a NameID in the format address. Workflow Figure 20. ShareFile SAML 2.0 Workflow 1. Client requests from sharefile.com 2. Client discovers identity provider 3. Client is redirected via an HTTPS 302 redirect to identity com/ idroot with SAML request 4. Client requests identity 5. Identity provider authenticates the user and redirects client to Assertion Consumer with SAML response 6. Client posts SAML response to the Assertion Consumer sharefile.com/saml/acs 7. Assertion Consumer Service validates SAML response and authenticates the user if successful ShareFile sets a session cookie and redirects Client to sharefile.com 8. Client requests 9. Access to granted. End user defaults to personal folder 36

37 Security and benefits User passwords never cross the firewall, since user authentication occurs inside of the firewall and multiple web application passwords are no longer required. Web applications with no passwords are virtually impossible to hack, as the user must authenticate against an enterprise-class Identity Provider first, which can include strong authentication mechanisms. Service Provider (SP)-initiated SAML SSO provides access to web apps for users outside of the firewall. If an outside user requests access to a web application, the SP can automatically redirect the user to an authentication portal located at the Identity Provider. After authenticating, the user is granted access to the application, while their login and password remains locked safely inside the firewall. Centralized federation provides a single point of web application access, control and auditing, which has security, risk and compliance benefits. The ability to offer secure, scalable, standards-based Internet SSO to customers, either as a value-added service, a competitive differentiator, or to satisfy customer demands. Ability to federate with other service providers, sharing user identity in order to deliver seamless, transparent, value-added services without requiring an additional login. Additional resources These additional resources can be used to get more information on ShareFile SAML configuration. 1. Configure Single Sign-on for SAML-Based Federation using ADFS 2. Configure Single Sign-on for SAML-Based Federation using Ping Federate 3. Configure Single Sign-on for SAML-Based Federation using CA SiteMinder 4. Configure Single Sign-on for SAML-Based Federation using OKTA 37

38 White Paper OAuth Overview OAuth is an open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications. ShareFile supports the OAuth 2.0 framework which enables applications like the ShareFile mobile, sync, and Outlook Plug-In to obtain limited access to an HTTP service like ShareFile. com. The great thing about OAuth is that it uses access tokens to provide authentication protecting the end-user s account credentials. The following ShareFile clients support OAuth: iphone and ipad With the exception of the MDX-wrapped versions of this client. Those will ask Worx Home for a SAML token during every login attempt Android With the exception of the MDX-wrapped versions of this client. Those will ask Worx Home for a SAML token during every login attempt Windows Phone 8 Windows 8 Modern App ShareFile Sync for Windows and ShareFile Sync for MAC Outlook Plug-In Workflows Web authentication ShareFile credentials Below is a graphical representation of how the ios mobile client exchanges a user s credentials with an OAuth token. Please refer to section for the definitions of specific terms used in the following workflow. In most scenarios our latest mobile apps will use the Web authentication flow for authenticating the exception for mobile is the MDX builds of ios and Android get a SAML token directly from Worx Home and authenticates without OAuth. 38

39 Figure 21. IOS mobile client web authentication flow using ShareFile credentials 1. The first step in the request of an OAuth token will be either a GET or POST request with the following parameters: response_type Needed to determine whether the endpoint returns an authorization code. For web applications (like ShareFile.com) the value of code is used. client_id This is hard coded in the code of the mobile client. redirect_uri An HTTPS URI or custom URL scheme where the response will be redirected. This is also hardcoded into the mobile client and gets set when the mobile client is initially installed on the mobile device. 2. Next in the sequence will be calls for account discovery. This is when a user enters their ShareFile credentials and subdomain. 3. Once the client has finished account discovery an HTTP 302 is sent to the client with the redirecturi and the following parameters: code authorization code returned from ShareFile expires_in the amount of time the authorization code is valid for subdomain the user s subdomain from account discovery appcp the web application control plane (ShareFile.com etc) apicp the API control plane for the user 4. Next in the sequence will be the POST request sent to subdomain.appcp/oauth/token with the following parameters found in our API documentation: Header: Content-Type: application/x-www-form-urlencoded Content: grant_type authorization_code (this has to be authorization_code.) code the authorization code received in the previous step client_id comes from the mobile client code client_secret this is a client specific secret hardcoded into the software An example request in curl looks like: curl \ -d grant_ type=authorization_ code&code={your_code}&client_id={your_client_ id}&client_secret={your_client_ secret} \ -X POST 39

40 5. If successful the client will receive an HTTP 200 response with a JSON encoded object with the following data: access_token The access token. refresh_token The refresh token. token_type The token type. apicp The user s ShareFile API control plane, i.e. sharefile.com for the above example. appcp The user s ShareFile account control plane, i.e. for the above example. subdomain The user s ShareFile subdomain, i.e. if they access their ShareFile account through this value would return mycompany. Some username / password combinations may be active on multiple accounts. The user would need to choose an account in this case. expires_in The expiration time in seconds. A sample OAuth token would look like this: Figure 22. A sample OAuth token. 40

41 You ll notice that the response includes an access_token and a refresh_token. Access_ tokens are designed to expire in 8 hours and can be revoked at any time by the ShareFile administrator. Refresh_tokens are designed to have a lifetime assigned to them after which they expire and force re-authentication. The default lifetime for the refresh_token is set to never expire but can be changed by the ShareFile administrator to 1, 7 or 30 days, this OAuth Lifetime setting is located in your ShareFile account on the Admin Advanced Preferences Password, Login and Security Policy page and ShareFile support can set a custom timeframe if one is needed. These tokens can also be revoked at any time by the ShareFile administrator and if an employee leaves the company, disabling or deleting their account in ShareFile will automatically revoke all of their tokens and break their access to ShareFile. The way that the tokens work is as follows. When you configure your ShareFile account on a mobile client the client checks the Device Security configuration and if Automatic Login is enabled the client will store the access and refresh tokens on the device. This makes opening and using the ShareFile client much easier. If Automatic Login is disabled the user will be prompted with their address and password every time they use the ShareFile client. What needs to be stressed here is that we are not storing user credentials in the client we are storing access and refresh tokens that are linked to the user s credentials. Anytime a user opens the ShareFile application the application checks to see whether the access_token has expired. If it hasn t expired the access_token is used to authenticate the user to ShareFile and the user is presented with his or her files and folders. If the access_ token has expired, an example of this would be the user hasn t opened the application in less than 8 hours, the refresh_token is used to refresh the access_token and restarts the 8 hour expiration clock. The user doesn t know this is happening and authentication happens instantaneously bringing the user to his or her files and folders. Parameter definitions Field access_token refresh_token token_type apicp appcp subdomain expires_in Description Short lived token presented to ShareFile to obtain an authid. Long lived token used to acquire new access token. Token type typically will be bearer. API Control Plane for the user. Control Plane for the web app (sharefile.com, securevdr.com, etc.). Subdomain for the user s account. Lifetime of the access_token in seconds. 41

42 Web authentication SAML The workflow for the IOS and Android mobile client using SAML is very similar to the above workflow with the exception of the redirection and authentication with the SAML IdP. Figure 24. Mobile client web authentication flow using SAML. Desktop apps Our desktop apps that support OAuth (Desktop Sync and Outlook Plug-in) will only do the account discovery part of the web authentication natively. If the user can login using their ShareFile address/password the desktop app will use the Password Authentication flow in Figure 23 below. If the customer uses an IdP that can do some sort of integrated authentication the desktop app will natively capture the SAML token and use the SAML Authentication Native flow in Figure 24 for exchanging the SAML token for OAuth token. And finally, if the customer uses forms authentication the application will switch to the Web authentication SAML flow in Figure 25 and provide the username and subdomain, auto- advancing the flow to the IdP and bypassing all calls for account discovery. Password authentication ShareFile credentials Figure 25. Password Authentication flow for desktop apps using ShareFile credentials 42