W H IT E P A P E R. Salesforce Security for the IT Executive

Transcription

1 W HITEPAPER Salesforce Security for the IT Executive

2 Contents Contents...1 Introduction...1 Background...1 Settings Related to Security and Compliance...1 Password Settings... 1 Session Settings... 2 Login and Authentication Settings... 2 Time-of-Day Restrictions... 2 IP Address Restrictions... 2 Single Sign-On Options... 2 Identity Confirmation... 2 Data Privacy...3 Profiles... 3 Field-Level Security... 3 Sharing Settings... 3 Default Sharing Model... 3 Sharing Rules... 4 Roles... 4 Defaults and Recommendations... 4 Force.com Apex Code and Visualforce...4 Apex and Data Privacy... 5 Creation of Apex Classes... 5 Recommendations... 5 Force.com AppExchange...5 Audit Features...5

3 Introduction The Salesforce CRM applications include settings and features that work together to protect your data. As an information technology or information security executive responsible for data privacy, you need to understand how salesforce.com helps to secure your data. Several features and settings are enabled by default; others require specific actions from your Salesforce CRM administrator. If the administrator does not change the default configuration, every user has full access to all data. This paper is not a detailed how-to guide. Instead, it provides an overview of the most important security-related features and recommendations for enhancing your data security. For more detailed auditing and configuration guidance, see the auditing companion to this paper, the Salesforce CRM Security Audit Guide, and the Security Implementation Guide at Background Although this paper primarily focuses on application-specific features and configuration settings of Salesforce CRM, salesforce.com s overall security strategy includes a combination of technical infrastructure controls and a strong security governance framework. Our defense-in-depth strategy includes security policies and procedures, infrastructure controls, and secure application development and architectures. Information security at salesforce.com is governed by a comprehensive information security management system. Salesforce.com continues to undergo SAS/70 Type II and SysTrust audits, and it received an ISO27001 certification from BSI in April The company performs background checks on all employees; the entire company also completes regular security awareness training sessions. To ensure the highest level of data protection, salesforce.com s IT infrastructure includes a host of enhancements. All production servers use hardened UNIX/Linux operating systems; additional measures include centralized logging and alerting, intrusion detection, network access control, anti-virus/anti-malware, host-based firewalls, and data loss prevention tools. The core production servers are further protected by Juniper stateful firewalls, Cisco perimeter and core routers, and F5 load balancers. These servers are managed via bastion hosts that require two-factor authentication to access. The application development lifecycle was also designed with an emphasis on information security. Every salesforce.com developer is trained on secure coding techniques, and every feature requires a security review to be released into production. Both internal staff and third-party security experts regularly perform security assessments. Salesforce.com provides strong defense-in-depth strategies and technologies to protect our customers data. We also provide application-specific features and settings to further protect your Salesforce CRM deployment. You can ensure the ultimate security with a combination of your own security-related configuration settings and salesforce.com s features, policies, and technologies. The remainder of this paper focuses on the steps you can take to ensure the security of your Salesforce CRM deployment. Settings Related to Security and Compliance The Salesforce CRM application includes many security-related configuration settings. This section summarizes some of the most important, including password settings, session settings, and login and authorization settings. Consider the default settings as a baseline starting point for security. You can and should implement additional measures, as described in the Appendix of this document and in the Salesforce CRM Security Audit Guide. Note: Companies that have used Salesforce CRM for several years should be aware that previous default settings were much less restrictive than the current defaults. Moreover, your administrators may have modified several of the security-related parameters. Password Settings S al e sf o rc e CR M S ec u ri t y f o r t h e IT E xecutiv e 1

4 Password complexity and expiration settings within Salesforce CRM should be configured to comply with your internal policies. Note that the default settings may not be appropriate for companies with stronger security policies. These default settings also do not meet the requirements of the Payment Card Industry Data Security Standards (PCI-DSS). The available password settings include items such as expiration timers, history and complexity restrictions, invalid lockout attempts, and lockout timers. Session Settings Several settings can be used to place restrictions on active user sessions. These include configuring the idle session timeout, locking sessions to the IP address used at login, and requiring secure (HTTPS) connections. Many of the default settings should be modified to improve security. In particular, note that the default idle session timeout value is 2 hours and should be lowered for most customers. Login and Authentication Settings By default, all users can log in to Salesforce CRM from any IP address at any time of day, subject to the restrictions of the Identity Confirmation feature described below. You can restrict user login access to specific work hours and/or defined ranges of IP addresses. These restrictions are defined based on User Profiles (see Profiles below). Time-of-Day Restrictions User logins can be restricted to specific times of the day. Different time-of-day restrictions can be defined for different types of users. See Profiles below. IP Address Restrictions User logins can be restricted to specific IP addresses or ranges of IP addresses. IP range restrictions can be configured for the entire organization or for each particular class of user. Single Sign-On Options In addition to the standard username and password authentication, Salesforce CRM supports two types of single sign-on methods. To improve user account management, salesforce.com recommends enabling one of the following options: :: Delegated Authentication When delegated authentication is enabled, Salesforce CRM makes a Web services call to your organization to authenticate your users, rather than using the native Salesforce CRM passwords. :: Federated Authentication Federated authentication directs Salesforce CRM to use the Security Assertion Markup Language (SAML) for user authentication. Identity Confirmation The Identity Confirmation feature was developed in part to provide a defense against phishing attacks and/or stolen user credentials. This feature is enabled for all organizations. It cannot be disabled. When users attempt to log in to Salesforce CRM via the Web API or a client such as Force.com Connect for Microsoft Outlook, the user login is verified against time-of-day restrictions and IP address restrictions. If IP address restrictions are used, the Identity Confirmation feature, as described here, is not used because of the enhanced protection already provided by IP address restrictions. If IP address restrictions are not used, Salesforce CRM checks whether the user s browser or current IP address was previously used to log in to Salesforce CRM. This check is performed by looking for the presence of a certain cookie that is created during a successful login and by referencing an internally stored list of IP addresses from previous successful logins by this user. If the browser has the cookie or is using a previously known IP address, the login proceeds. If the cookie is not present and the connection is coming from a new IP address, the user is directed to a special screen and prompted to click a Send Activation Link button, which sends an activation S al e sf o rc e CR M S ec u ri t y f o r t h e IT E xecutiv e 2

5 to the address on record for the user s account. This contains a link for activating the browser. Data Privacy Data privacy, or access to your data, is controlled by several features. At the core of data privacy is your default sharing model, which consists of the default settings that control access to standard and custom objects. These default settings can be extended with custom sharing rules, profile settings, and role hierarchies. In addition, you can place restrictions on individual fields on a particular record. The following sections will provide an introduction to these parameters and highlight important considerations. Auditing for access to data within Salesforce CRM can become very confusing since several factors must be considered at once. Access to Salesforce CRM data is determined by a combination of Profiles, Field-Level Security, and Sharing Settings as described below. More details regarding auditing for data privacy can be found in the Salesforce CRM Security Audit Guide and in the sharing cheat sheet at Profiles A profile is similar to a role is many enterprise applications, except that each user must have one profile and cannot have more than one profile. Every profile includes one or more permissions that define what a user can do within Salesforce CRM, such as adding and removing users or creating custom fields and object types. In addition to detailed permissions, a profile defines the default access privileges to standard and custom objects, such as contacts, accounts, leads, opportunities, and more. Salesforce CRM defines several default profiles, referred to as standard profiles. The available standard profiles depend on the edition of Salesforce CRM in use, and the standard profiles cannot be modified. Reviewing standard profiles for data privacy is relatively simple since only the System Administrator profile has full administrative access. For larger companies, however, these standard profiles often do not provide enough fine-grained entitlements. Organizations using Salesforce CRM Enterprise or Unlimited Editions can define custom profiles using any combination of more than 60 individual permissions. Since profiles are the first step in determining data access rights, they should be reviewed closely. If custom profiles have been used, each profile should be examined to determine which privileges are included and which users have been assigned to the profile. Field-Level Security Field-level security provides granular control over specific fields related to Salesforce CRM objects. For example, the address is a field of the Contact object. Every field in every object can be assigned unique access privileges based on the user s profile. For example, the address of a contact could be restricted to read-only for one profile, not visible for another profile, and fully editable by yet a third profile. Field-level security rules should be reviewed periodically since they potentially override other types of data access settings. Sharing Settings The default sharing model and sharing rules are at the core of controlling access to Salesforce CRM data. The sharing settings define the access rights to each Salesforce CRM object and are often confusing if they have been customized over time. In summary, sharing permissions are based on the default permissions (the sharing model) and exception rules (the sharing rules). Note: Each object type (Account, Contact, Lead, etc ) can have independent sharing models and rules. Default Sharing Model S al e sf o rc e CR M S ec u ri t y f o r t h e IT E xecutiv e 3

6 Each standard and custom object can be assigned a default sharing rule/model. Some of the possible options include full read and write to all users, full read and limited write, fully private, or other similar combinations. When using a restrictive sharing model such as private or read-only, data access is restricted to the record owner with two exceptions. First, a sharing rule (described below) can be used to allow additional access. Second, a role hierarchy (described below) can be configured and then users higher in the role (organizational chart) will automatically inherit the privileges of the record owner. The salesforce.com security team recommends using a private default sharing model and defining an accurate role hierarchy to better protect sensitive data. Sharing Rules Depending on the edition of Salesforce CRM, you can set up rules to define exceptions to the default sharing settings of most objects. In general, a sharing rule consists of three components: the owner, the user with whom to share, and access permission. Roles Roles within Salesforce CRM do not completely relate to the traditional concept of a role in Role- Based Access Control (RBAC). Instead, a role in Salesforce CRM is more closely tied to the organizational chart and each user can only be assigned to a single role. Roles are used by the sharing settings to control access to records. By default, the role hierarchy is not used because the default sharing settings are Public Read/Write (See Sharing Settings below). Once more restrictive sharing settings are enabled (such as a private model) the roles and role hierarchies are the primary criteria used to control data access. To properly use role-based sharing, an accurate organization-based role hierarchy should be defined and all users assigned to a role. You can create up to 500 unique roles for your organization; the names of each role are fully customizable. The default sharing rules follow the role hierarchy and users higher in the hierarchy automatically inherit the privileges of the subordinate roles. Defaults and Recommendations The default settings within Salesforce CRM assign Public Read/Write permissions to nearly all records, including leads, contacts, accounts, and custom objects. As a result, all users have full access to every record. When different users require varying levels of data access, salesforce.com strongly recommends defining a role hierarchy that matches your company and specifying a private sharing model for sensitive object types. Restricting access to Salesforce CRM data requires advance planning and testing and involves the following steps. :: Defining a role hierarchy and assigning a role to every user. :: Modifying the organization-wide default sharing settings for sensitive object types by setting them to Private. :: Defining sharing rules to provide role-based exceptions to the default settings. Force.com Apex Code and Visualforce (Apex and Visualforce are only available in Force.com Developer Edition and the Salesforce CRM Enterprise and Unlimited Editions.) Apex is a programming language developers can use to create custom business logic or complete applications on Force.com platform server. Visualforce is a tag-based markup language (similar to HTML and JSP) to give developers a more powerful way to build applications and customize the Salesforce CRM user interface. A very typical use of Apex and Visualforce will be to create a customized Visualforce page that is supported by Apex code written by your developers. This powerful ability to customize Salesforce CRM also presents potential security risks that should be monitored. First, Apex and Visualforce S al e sf o rc e CR M S ec u ri t y f o r t h e IT E xecutiv e 4

7 pages can have many of the same security vulnerabilities as any web application might have and should be reviewed in the same way other internal web applications are reviewed. Second, Apex code can bypass all of the data privacy restrictions previously discussed in this paper. Apex and Data Privacy Apex classes are essentially custom code segments you can use to modify almost any data, business logic, or even outbound Web services and HTTP requests. One of the most important features of Apex is that, by default, it runs with full system privileges. That means that the user s profile-based permissions, field-level security, and sharing rules are not taken into account during script execution. Security must be enforced by the author of the Apex Code. For more information about Apex access controls, see the Data Access Control section of the Apex and Visualforce Security Tips article at Security Controls Creation of Apex Classes Apex classes can be created by any user with the Author Apex permission. By default, only the Administrator profile has this permission. However, users can be granted this permission or Salesforce CRM administrators can install code written by internal or external developers. Recommendations Because Apex classes are so powerful, review the code closely before deploying it. Developers writing Apex should be trained in secure coding practices. A brief summary of some of the more important Apex and Visualforce security concerns can be found in the Apex and Visualforce Security Tips article at Force.com AppExchange The Force.com AppExchange is an on-demand application-sharing service from salesforce.com. You can use the AppExchange to browse, install, and share apps and components stored in packages and built for the Force.com platform. You can review apps submitted by other salesforce.com customers, take a test drive, and install the apps. These apps work just like other custom apps within your Salesforce CRM organization. All AppExchange applications were checked for security flaws by salesforce.com. Salesforce.com reviews AppExchange applications annually. Patches and version upgrades since the last security review have not been reviewed by salesforce.com and you should review the application in the same manner you review any thirdparty product. The applications listed on the AppExchange are packaged in one of two ways native or composite. Native applications consist of only Salesforce CRM entities such as custom objects, reports, workflows, Apex classes, or Visualforce pages. When native applications are installed, no data is sent to a third-party site. Composite applications include a combination of native features as well as connections to and/or from a third-party data center. The details vary with each application, but data is typically shared between Salesforce CRM and the database of the company providing the application. The application uses the session ID of the currently authenticated user to make a Web services connection to the Force.com API. Because of the nature of this integration, composite applications have the same access rights as the user currently logged in. Audit Features The Salesforce CRM application provides several types of audit logs for monitoring logins and changes to your Salesforce CRM organization. All the audit features can be viewed by your Salesforce CRM administrator, including: :: User Login History All successful and failed login attempts are recorded and saved for 180 days. S al e sf o rc e CR M S ec u ri t y f o r t h e IT E xecutiv e 5

8 :: Setup Audit Trail Every configuration (Setup) change is logged and archived for 180 days. The Setup Audit Trail shows any change and who made the change. This audit log is especially helpful for organizations with multiple administrators. :: Object History Tracking You can select certain standard and custom fields to track the change history. Each time a user modifies one of the tracked fields, an entry is added to the History Related List on the object, showing the time, user, and the change made. By default, no specific fields are tracked until activated by the administrator. For More Information Contact your account executive to learn how we can help you accelerate your CRM success. 6 S al e sf o rc e CR M S ec u ri t y f o r t h e IT E xecutiv e