Protecting Your Data in the Cloud
Protecting Your Data in the Cloud
An Under the Hood Look at Force.com
Many organizations today already use or plan to use cloud computing to help address their business requirements. Why? Because modern cloud computing solutions just make sense when you compare them to traditional, time-consuming, and costly on-premises solutions. Among other things, cloud computing can help you reduce capital expenditures, minimize application deployment times, eliminate maintenance tasks, and refocus your IT staff on adding value to your core business.
The same is true for security in the cloud. Cloud providers have highly skilled security teams and economies of scale to invest in the latest security technologies. Cloud providers are also assessed by many different customers, have to comply with a broad range of security regulations, and are motivated to ensure customer security success since this is foundational to the cloud business. In many cases, the security resources that a cloud provider offer exceed those that organizations can afford independently.
Even with all of these compelling benefits of moving to the cloud, it’s important that you are confident that your cloud provider has the world-class security and privacy solutions that can adequately protect your data. So what does it take to trust a cloud? Like any other system, a cloud provider must protect your assets from internal and external threats, maintain the privacy of your data, remain available and reliable, and perform consistently. The cloud must also be transparent. Transparency builds trust, and customers need to retain the ability to maintain oversight into how clouds protect their data and who is accessing it.
A good cloud solution can be measured by the level of control you maintain over your assets. In addition to understanding your specific risk tolerance, data security, data privacy, and regulatory compliance requirements, you should carefully choose a service that can provide you with adequate controls for meeting your business requirements.
This paper explains why you should trust salesforce.com cloud solutions with your assets. First, you’ll learn about our commitment to earning and maintaining your trust. Next, you’ll discover the core operational and functional security measures that our platforms use to protect your data. And finally, you’ll explore the built-in features of our services that you can draw on to build applications that satisfy even the most stringent security requirements.
Your Trust, Our #1 Concern
Trust has always been a core principle at salesforce.com since the company’s inception in 1999. As co-founder and Executive Vice President of Technology Parker Harris states, “Nothing is more important to our company than the privacy of our customer's data.” With this core belief in mind, let’s learn more about what salesforce.com does to ensure that your data remains secure, private, and available.
How We Certify Our Business Practices
Salesforce.com’s services are certified as compliant with some of the most rigorous, industry-accepted security, privacy, and reliability standards. We are certified and audited to standards as a service provider with the ISO/IEC 27001:2005 standard (including ISO 27001), SAS 70 Type II (now SSAE No. 16), SysTrust, and the EU-US and Swiss-US Safe Harbor frameworks). Our customers can also use our cloud services to deliver solutions that comply with HIPPA, PCI DSS, and FISMA (moderate level). Additional information about salesforce.com’s security and privacy programs is available at http://trust.salesforce.com.
How We Communicate With You
At trust.salesforce.com, you can review the current and archived history of system status and performance metrics, as well as planned upgrades and maintenance windows. Here, you’ll also see detailed information about system performance incidents, including when an incident happened, why and how it was resolved, and how we plan to prevent it from happening again.
How We Operate Internally
Salesforce.com's commitment to security, privacy, reliability, and trust permeates the entire company. It starts at the very top with executives who lead teams responsible for the implementation of comprehensive information security governance policies based on the ISO 27002 framework and a robust privacy program.
- Employees – All of our employees receive information security and privacy training. Employees that handle data receive additional training specific to their roles.
- Security staff – We have a dedicated security staff, including a Chief Trust Officer, a Vice President of Information Security, and a full staff of highly skilled security professionals.
- Privacy counsel – We have a team of privacy lawyers who are responsible for helping ensure that we comply with global privacy laws.
- Assessments – We regularly conduct both internal vulnerability assessments (for example, architecture reviews by security professionals) and external vulnerability assessments (for example, vulnerability assessments by managed security services providers, or MSSPs). In addition, our largest and most stringent customers assess us over 100 times per year.
- Policies – Detailed internal policies dictate how we detect, investigate, and respond to security and privacy incidents.
How We Build Secure Products
Salesforce.com incorporates OWASP recommendations and other security best practices into its system development processes at all stages. Here's a summary of some of the development phases we go through.
- Design phase – Guiding security principles and required security training help ensure that our technologists make the best security decisions possible. Assessing threats to high-risk features helps us identify potential security issues as early in the development lifecycle as possible.
- Coding phase – We address standard vulnerability types with secure coding patterns and anti-patterns, and use static code analysis tools to identify security flaws. We give every salesforce.com software release a code review and fix all our significant security findings before our applications go live.
- Testing phase – Our internal staff and independent security consultants use third-party tools, proprietary tools, and manual security testing to identify potential security issues.
In addition to all the steps above, we regularly use third parties to evaluate the security of our solutions. These reports are available to prospects and customers under a non-disclosure agreement.
Along with the testing we perform on our own products, we also require that all software vendors who want to list their products in our AppExchange submit those products for a security review by the salesforce.com application security team. AppExchange does not list a product until it has been reviewed, and all significant issues have been remediated.
How We Fortify Our Data Centers
The physical security of each salesforce.com facility is comparable to the best civilian data centers in the world. The exterior perimeter of each anonymous building is bullet resistant, has concrete vehicle barriers, closed-circuit television coverage, alarm systems, and manned guard stations, all of which help defend against non-entrance attack points. Inside each building, multiple biometric scans and guards limit access through interior doors and cages at all times. You can read more about our infrastructure design here.
How We Secure Our Networks
Salesforce.com invests heavily in network defense. We use the same world-class security as global banks do for their banking. For example, we encrypt all data transmissions that involve our systems using SSL 3.0/TLS 1.0 global step-up certificates from VeriSign to ensure that prying eyes cannot use data that might be intercepted. We employ perimeter firewalls and edge routers to block unused transmission protocols, and use internal firewalls to segregate traffic between the application and database tiers. You can read more about our secure network design here.
How We Monitor for Threats
Salesforce.com employs several sophisticated security tools that monitor system activity in real time to expose many types of malicious events, threats, and intrusion attempts. For example, our state-of-the-art intrusion detection systems (IDS) detect common types of external attacks. We also monitor application and database activity, and use event management tools that actively correlate user actions and event data, then call attention to potential internal and external threats.
How We Safeguard Your Data
Salesforce.com uses a layered approach to protect your data from simple storage device errors, catastrophic failures, and everything in between. To support basic database recovery scenarios, we back up all of your data on a rotating schedule of incremental and full backups that let us restore service more efficiently should the need arise. Our disaster recovery mechanisms use real-time replication to disk at each data center, and near real-time data replication between the production data center and the disaster recovery center. You can read more about our database backup and disaster recovery designs here.
How We Harden Our Servers
Salesforce.com implements industry-accepted best practices to harden all underlying host computers that support the various software layers of our clouds. For instance, all of our servers use Linux or Solaris distributions with non-default software configurations and minimal processes, user accounts, and network protocols. Application services never execute under root, and they log their activity in a remote, central location for inspection and safekeeping.
How We Secure Force.Com Database
Force.com’s database is the underlying data persistence technology at the heart of most salesforce.com cloud services, so it implicitly plays a significant role in the security of the applications that use it, including:
- Custom apps built with Force.com
- Our own line of business applications (e.g., Sales Cloud, Service Cloud)
- Many partner apps (e.g., RemedyForce, InForce Everywhere)
Force.com includes many features that help provide a secure environment and protect the privacy of your business data. One simple example is the way that Force.com protects customer passwords—with the application of a salted SHA-256, one-way cryptographic hash function.
Force.com’s innovative metadata-driven, multitenant database architecture delivers automatic scalability for cloud-based applications without compromising the security of each organization’s data.
- When a user establishes a connection, Force.com assigns the session a client hash value.
- Along with forming and executing each application request, Force.com confirms that the user context (an organization ID, or “orgID”) accompanies each request and includes it in the WHERE clause of all SQL statements to ensure the request targets the correct organization’s data. When data is returned, Force.com validates that every row in the return set of a database query matches the session’s orgID.
And again at the application layer, before returning results to an application request, Force.com confirms that the calculated client hash value matches the client hash value that was set during the login phase. This is a simplified view into how we enable secure multitenancy. We also use additional validation checks to ensure that accidental or intentional accessing other customers’ data is virtually impossible.
Standard Features You Can Use to Build Secure Apps
Information security governance in the cloud requires work from both the cloud platform provider (i.e., salesforce.com) and the application provider or developer (i.e., you). Now that you understand some of the things that salesforce.com does internally to care for your applications and data, it’s time to turn your attention to the many standard features of Force.com–and the products above it, such as the Sales Cloud–that you can use to build secure applications and meet the requirements of your specific security policy.
How You Can Control System Access
Force.com and all of its dependent clouds have a full complement of features for managing users, authenticating and restricting their system access, and auditing logins. You, the customer, retain complete control over who has access and are encouraged to integrate into your existing on-premises access management systems to ensure the highest degree of accuracy, efficiency, and auditability.
For example, you can create users declaratively using a browser-based console, bulk-load new user data, use SAML-based automatic provisioning, or have your application make API calls that handle user registrations in real time. Once your users are set up, you can authenticate login requests in several ways: with traditional username/password authentication, federated authentication single sign-on (i.e., SAML), delegated authentication (e.g., LDAP), or OAuth2. Additionally, you can configure user profiles to enforce time- and IP-based login restrictions. For auditing purposes, Force.com maintains a history of login requests.
How You Can Control Data Access
You can use several Force.com features to control the objects, fields, and specific data records to which your users have access. Here’s a preview of how it’s done.
- Create profiles and permission sets – Identify the different types of users you need for your application, based on the different functions each type needs to access. Create a base level profile for each type of user so that each profile has only the permissions required for that type of user to perform these functions. Then create permission sets to handle exceptions—situations in which a user may need a few more permissions.
- Assign users – Assign each user to the appropriate profile and permission sets.
- Set sharing models – For each object, set the organization-wide default record sharing settings to determine whether the records that each user owns are public or private.
- Share private records – Use roles, groups, record sharing rules, and other means to share private records with other users.
How You Can Audit Data Modifications
Force.com makes it painless to comply with auditing requirements that are commonly part of security policies. With a few mouse clicks, you can configure Force.com to audit who changed the value of a field, when it was changed, and what the value of the field was before and after the edit. History data is readily available for reporting, so you can easily create audit trail reports that help you comply with your security policy requirements.
How You Can Encrypt Selected Data at Rest
Force.com lets you declare encrypted custom fields so that you can address concerns over data like social security and credit card numbers that your company might define as requiring additional protection. After creating an encrypted custom field, Force.com automatically encrypts this data using AES 128. It then uses key splitting to separate the keying material between application server and database so that no single salesforce.com administrator can recover both parts of the key.
However, encrypted custom fields do have some restrictions that might be important to your use case; they cannot be an external ID and do not have default values, and they are not searchable or available for use in filters such as list views, reports, roll-up summary fields, and rule filters.
When your application requires more control than what’s possible with declarative encrypted fields, you can use methods in Apex Crypto class to programmatically encrypt and decrypt sensitive information in Force.com. Apex Crypto also provides you with methods for creating digests, message authentication codes, and signatures.
How You Can Help Reduce the Risk of Automated Attacks
You can configure several data download areas within salesforce.com products to require users to pass a user verification test known as CAPTCHA. This simple text-entry test ensures that the platform is interacting with a human being, and it can help reduce the risk of automated attacks, preventing malicious programs from accessing your organization's data.
How You Can Analyze Your Security Implementation
Security Health Check is a free application, which was developed by the salesforce.com information security team, that you can use to check security-related settings and make recommendations for improving CRM security and limiting data loss.
How Can Specific Data Fields Get Additional Protection?
Some customers have policies that require certain data to be afforded extra protection. Salesforce.com’s Data Residency Option (DRO) is an advanced solution that lets your organization benefit from salesforce.com cloud solutions, even when your security policy requires that certain data fields be readable only within the boundaries of your organization.
Salesforce.com’s customers can decide what data fields to encrypt or tokenize using DRO, and what data fields to submit to the salesforce.com services in readable format, depending on their respective business needs and policy compliance requirements.
DRO ensures that protected data fields are in readable format for only you—they are not readable on salesforce.com’s systems. Encrypted data is stored on salesforce.com’s servers in data centers pursuant to your main agreement. However, salesforce.com does not maintain the decryption keys, which are controlled solely by you, and which permit your designated users to view the data in a readable format in the Salesforce application.
Similarly, tokenized data is stored on salesforce.com’s servers and is used to render the data in readable format for the user when you, the customer, activate the token.
In certain situations, you may be subject to regulations or policies that limit what data can be stored in the cloud. In this section of the paper, you’ll learn more about how you can use advanced features of Force.com to tackle some of the toughest requirements for protecting and retaining control over cloud data storage while still realizing the benefits of cloud computing.
What Can Salesforce.Com’s Data Residency Option Do for You?
Salesforce.com DRO is an advanced solution that lets your organization benefit from salesforce.com cloud solutions, even when you have unique data privacy or data residency requirements. Examples might include regulatory requirements, contractual obligations, or company policies. At the same time, DRO provides you with this functionality in a transparent manner so that all of your users and developers can work in the same way that they do today. Note that depending on the DRO encryption options you apply for different fields, you can preserve or might lose functionality such as searching, sorting and reporting. This section describes the various options provided by DRO so that you can make the most appropriate risk decision for your organizations. DRO policy allows you to select different options for different fields, depending on your needs.
How DRO Provides You the Control to Protect Your Sensitive Data
With DRO, your organization retains control over its sensitive data because you are solely responsible for its readable versions of this data. DRO protects selected data fields before transmitting them from your enterprise to our cloud, using either encryption or tokenization (see the next section for more details), and then decrypts the sensitive data on your DRO system before presenting it to your users.
How You Can Use DRO to Meet Specific Requirements
DRO does not force you into a one-size-fits-all approach, but instead is a flexible solution that you can implement to meet the security and functional requirements of the individual fields of data that your applications use. Certain fields might not require DRO, others might use DRO’s encryption option, and still others might use DRO’s tokenization option. Let’s take a brief look at each DRO option and learn when each one makes sense.
With DRO encryption, your organization maintains local control of the keys that DRO uses to encrypt and decrypt data. Before submitting sensitive data to salesforce.com, DRO encrypts it. Encrypted data in the salesforce.com data centers is unreadable to anyone that does not have the encryption keys, including salesforce.com personnel. And because you control the keys that decipher the data, you have control over who can see your information. DRO’s encryption option is a good choice when your policy states that you must encrypt your sensitive data, and when the salesforce.com functionality you want to retain is just editing and viewing data. In cases like this, it makes sense to use DRO encryption, store data in Force.com, and make your security policy implementation simpler. This encryption option employs AES, which is a standard, NIST-approved and FIPS-certified algorithm commonly used for sensitive data.
DRO’s search-enabled encryption option is a good choice when a key requirement of your policy is being able to search within encrypted data. With DRO search-enabled encryption, your organization maintains local control over encryption keys and benefits from the simplicity of storing the encrypted data in the cloud. This option works similarly to DRO encryption in that data is encrypted before submitting it to salesforce.com and decrypted before being presented to the end user. In addition, it preserves the search functionality within the encrypted data, by employing AES in a special mode.
With DRO tokenization, your organization maintains sensitive data fields in a local database that is under your control. Meanwhile, to maintain normal application functionality, DRO tokenizes sensitive data elements before sending tokens to salesforce.com data centers. DRO employs specialized, patent-pending tokenization algorithms that let Force.com retain the ability to properly sort tokenized data, perform lexicographic logical operations with tokens, search within the data, and execute queries using random tokens. DRO’s tokenization option is a good choice when your business requirements include having the ability to search and sort within the data. Use tokenization only when necessary, as it involves deploying, using, and managing a local tokens dictionary database.
Salesforce.com is committed to earning and maintaining your trust as a cloud computing provider. We certify our data centers and all of our internal operations to some of the highest industry-accepted standards for data security, privacy controls, and operational reliability. We also offer you many Force.com features that you can use to deploy applications that secure your data. And when your internal policies require you to keep certain fields readable only within your company, you can use Data Residency Option (DRO) encryption or tokenization schemes.
About the Author
Steve Bobrowski is an Architect Evangelist within the Technical Enablement team of the salesforce.com Customer-Centric Engineering group. The team’s mission is to help customers understand how to implement technically sound Salesforce solutions. Check out all of the resources that this team maintains on the Architect Core Resources page of Developer Force.