Security Implementation Guide

Transcription

1 Salesforce.com: Spring '10 Security Implementation Guide Last updated: January 31, 2010 Copyright salesforce.com, inc. All rights reserved. Salesforce.com is a registered trademark of salesforce.com, inc., as are other names and marks. Other marks appearing herein may be trademarks of their respective owners.

2

3 Table of Contents Table of Contents Chapter 1: Security Overview...3 Security Infrastructure...3 Trust and Salesforce.com...4 User Security...5 User Authentication...5 Network-based Security...5 CAPTCHA Security for Data Exports...6 Session Security...6 Securing Data Access...6 Key Profile Permissions...8 Auditing...9 Chapter 2: Securing and Sharing Data...10 Managing Profiles...10 User Permissions on Profiles...11 Setting Field-Level Security...25 Setting Your Organization-Wide Default Sharing Model...26 Managing Roles...28 About Sharing Rules...29 Granting Access to Records...30 Chapter 3: Configuring Salesforce.com Security Features...32 Setting Password Policies...32 Expiring Passwords...33 Setting Login Restrictions...34 Restricting Login IP Ranges for Your Organization...35 Restricting Login Hours...36 Restricting Login IP Ranges on Profiles...36 Setting Session Security...37 Chapter 4: Enabling Single Sign-On...39 Chapter 5: Monitoring Your Organization's Security...42 Monitoring Logins...42 Tracking Field History...43 Monitoring Setup Changes...46 Chapter 6: Security Tips for Apex and Visualforce Development...49 Cross-Site Scripting (XSS)...49 S-Control Template and Formula Tags...51 Cross-Site Request Forgery (CSRF)...52 SOQL Injection...53 i

4 Table of Contents Data Access Control...55 Index...56 ii

5 Chapter 1 Security Overview Salesforce.com is built with security as the foundation for the entire service. This foundation includes both protection for your data and applications and the ability to implement your own security scheme to reflect the structure and needs of your organization. The security features of Salesforce.com provide both strength and flexibility. However, protecting your data is a joint responsibility between you and salesforce.com. The security features in Salesforce.com enable you to empower your users to do their jobs efficiently, while also limiting exposure of data to the users that need to act upon it. You should implement the security controls that you think are appropriate for the sensitivity of your data. Your data is protected from unauthorized access from outside your company, and you should also safeguard it from inappropriate usage by your users. See the following topics to get more information about the various security components in Salesforce.com: Security Infrastructure on page 3 Trust and Salesforce.com on page 4 User Security on page 5 User Authentication on page 5 Network-based Security on page 5 CAPTCHA Security for Data Exports on page 6 Session Security on page 6 Securing Data Access on page 6 Key Profile Permissions on page 8 Auditing on page 9 Portal Health Check Overview in the Salesforce.com online help Security Infrastructure One of the core features of a multi-tenant platform is the use of a single pool of computing resources to service the needs of many different customers. Salesforce.com protects your organization's data from all other customer organizations by using a unique organization identifier, which is associated with each user's session. Once you log in to your organization, your subsequent requests are associated with your organization, using this identifier. Salesforce.com utilizes some of the most advanced technology for Internet security available today. When you access the application using a Salesforce.com-supported browser, Secure Socket Layer (SSL) technology protects your information using both server authentication and data encryption, ensuring that your data is safe, secure, and available only to registered users in your organization. For more information about supported browsers, see Getting Started FAQ in the Salesforce.com online help. 3

6 Security Overview Trust and Salesforce.com In addition, Salesforce.com is hosted in a secure server environment that uses a firewall and other advanced technology to prevent interference or access from outside intruders. Trust and Salesforce.com Trust starts with transparency and that is why salesforce.com displays real-time information on system performance and security on the trust site at On this site, you can find live data on system performance, current and recent phishing and malware attempts, and tips on best security practices for your organization. The Security tab on the trust site includes valuable information that can help you to safeguard your company's data. In particular, phishing and malware are Internet scams on the rise. Phishing is a social engineering technique that attempts to acquire sensitive information such as usernames, passwords and credit card details, by masquerading as a trustworthy entity in an electronic communication. Phishers often direct users to enter details at a fake website whose URL and look-and-feel are almost identical to the legitimate one. As the salesforce.com community grows, it has become an increasingly appealing target for phishers. You will never get an or a phone call from a salesforce.com employee asking you to reveal a password, so you should refuse to reveal it to anyone. You can report any suspicious activities by clicking the Report a Suspicious link under the Trust tab at Malware is software designed to infiltrate or damage a computer system without the owner's informed consent. It is a general term used to cover a variety of forms of hostile, intrusive, or annoying software, and it includes computer viruses and spyware. What Salesforce.com Is Doing Customer security is the foundation of customer success, so salesforce.com will continue to implement the best possible practices and technologies in this area. Recent and ongoing actions include: Actively monitoring and analyzing logs to enable proactive alerts to customers who have been affected. Collaborating with leading security vendors and experts on specific threats. Executing swift strategies to remove or disable fraudulent sites (often within an hour of detection). Reinforcing security education and tightening access policies within salesforce.com. Evaluating and developing new technologies both for our customers and for deployment within our infrastructure. What Salesforce.com Recommends You Do Salesforce.com is committed to setting the standards in software-as-a-service as an effective partner in customer security. So, in addition to internal efforts, salesforce.com strongly recommends that customers implement the following changes to enhance security: Modify your Salesforce.com implementation to activate IP range restrictions. This will allow users to access Salesforce.com only from your corporate network or VPN, thus providing a second factor of authentication. For more information, see Setting Session Security on page 37 and Restricting Login IP Ranges for Your Organization on page 35. Educate your employees not to open suspect s and to be vigilant in guarding against phishing attempts. Use security solutions from leading vendors such as Symantec to deploy spam filtering and malware protection. Designate a security contact within your organization so that salesforce.com can more effectively communicate with you. Contact your salesforce.com representative with this information. Consider using two-factor authentication techniques, such as RSA tokens, to restrict access to your network. Salesforce.com has a Security Incident Response Team to respond to any security issues. To report a security incident with Salesforce.com, contact security@salesforce.com. Describe the incident in detail, and the team will respond promptly. 4

7 Security Overview User Security User Security Salesforce.com provides each user in your organization with a unique username and password that must be entered each time a user logs in. Salesforce.com issues a session cookie only to record encrypted authentication information for the duration of a specific session. The session cookie does not include either the username or password of the user. Salesforce.com does not use cookies to store other confidential user and session information, but instead implements more advanced security methods based on dynamic data and encoded session IDs. There are several settings you can configure to ensure that your users' passwords are strong and secure. If needed, you can force the expiration of passwords for all users. See Setting Password Policies on page 32 and Expiring Passwords on page 33. User Authentication Salesforce.com has its own system of user authentication, but some companies prefer to use an existing single sign-on capability to simplify and standardize their user authentication. You have two options to implement single sign-on federated authentication using Security Assertion Markup Language (SAML) or delegated authentication. Federated authentication using Security Assertion Markup Language (SAML) allows you to send authentication and authorization data between affiliated but unrelated Web services. This enables you to sign-on to Salesforce.com from a client application. Federated authentication using SAML is enabled by default for your organization. Delegated authentication single sign-on enables you to integrate Salesforce.com with an authentication method that you choose. This enables you to integrate authentication with your LDAP (Lightweight Directory Access Protocol) server, or perform single sign-on by authenticating using a token instead of a password. You manage delegated authentication at the profile level, allowing some users to use delegated authentication, while other users continue to use their Salesforce.com-managed password. Delegated authentication is set by profile, not organization wide. You must request that this feature be enabled by salesforce.com. Contact salesforce.com to enable delegated authentication single sign-on for your organization. The primary reasons for using delegated authentication include: - Using a stronger type of user authentication, such as integration with a secure identity provider - Making your login page private and not part of the general Internet, but rather, part of your corporate network, behind your corporate firewall - Differentiating your organization from all other organizations that use Salesforce.com in order to reduce phishing attacks For more information, see About Single Sign-On in the Salesforce.com online help. Network-based Security User authentication determines who can log in, while network-based security limits where they can log in from and when. Use network-based security to limit the window of opportunity for an attacker by restricting the origin of user logins. Network-based security can also make it more difficult for an attacker to use stolen credentials. To enhance network-based security, Salesforce.com includes the ability to restrict the hours during which users can log in and the range of IP addresses from which they can log in. If IP address restrictions are defined for a user's profile and a login originates from an unknown IP address, Salesforce.com does not allow the login. This helps to protect your data from unauthorized access and phishing attacks. 5

8 Security Overview CAPTCHA Security for Data Exports To set the organization-wide list of trusted IP addresses from which users can always log in without a login challenge, see Restricting Login IP Ranges for Your Organization on page 35. To restrict login hours by profile, see Restricting Login Hours on page 36. To restrict logins by IP addresses for specific profiles, see Restricting Login IP Ranges on Profiles on page 36. CAPTCHA Security for Data Exports By request, salesforce.com can also require users to pass a user verification test to export data from Salesforce.com. This simple, text-entry test helps prevent malicious programs from accessing your organization's data, as well as reducing the risk of automated attacks. CAPTCHA is a type of network-based security. To pass the test, users must type two words displayed on an overlay into the overlay's text box field, and click a Submit button. Salesforce.com uses CAPTCHA technology provided by recaptcha to verify that a person, as opposed to an automated program, has correctly entered the text into the overlay. CAPTCHA stands for Completely Automated Public Turing Test To Tell Computers and Humans Apart. Session Security After logging in, a user establishes a session with the platform. Use session security to limit exposure to your network when a user leaves their computer unattended while still logged on. It also limits the risk of internal attacks, such as when one employee tries to use another employee's session. You can control the session expiration time window for user logins. Session expiration allows you to select a timeout for user sessions. The default session timeout is two hours of inactivity. When the session timeout is reached, users are prompted with a dialog that allows them to log out or continue working. If they do not respond to this prompt, they are automatically logged out. Note: When a user closes a browser window or tab they are not automatically logged off from their Salesforce.com session. Please ensure that your users are aware of this, and that they end all sessions properly by clicking Logout. By default, Salesforce.com uses SSL (secure sockets layer) and requires secure connections (HTTPS) for all communication. It is not required. The Require secure connections (HTTPS) setting determines whether SSL (HTTPS) is required for all access to Salesforce.com. If you disable this setting and you change the URL from to you can still access the application. However, you should require all sessions to use SSL for added security. For more information, see Setting Session Security on page 37. Securing Data Access Choosing the data set that each user or group of users can see is one of the key decisions that affects data security. You need to find a balance between limiting access to data, thereby limiting risk of stolen or misused data, versus the convenience of data access for your users. To enable users to do their job without exposing data that they do not need to see, Salesforce.com provides a flexible, layered sharing design that allows you to expose different data sets to different sets of users. To specify the objects and tabs that a user can access, you can assign a profile. To specify the fields that a user can access, you can use field-level security. To specify the individual records that a user can view and edit, you can set your organization-wide defaults, define a role hierarchy, and create sharing rules. 6

9 Security Overview Securing Data Access Tip: When implementing security and sharing rules for your organization, make a table of the various types of users in your organization. In the table, specify the level of access to data that each type of user needs for each object and for fields and records within the object. You can refer to this table as you set up your security model. The following describes these security and sharing settings: Object-Level Security (Profiles) Object-level security provides the bluntest way to control data in Salesforce.com. Using object-level security you can prevent a user from seeing, creating, editing, or deleting any instance of a particular type of object, such as a lead or opportunity. Object-level security allows you to hide whole tabs and objects from particular users, so that they do not even know that type of data exists. You specify object-level security settings on profiles. A profile is a collection of settings and permissions that determine what a user can do in the application, similar to a group in a Windows network, where all of the members of the group have the same folder permissions and access to the same software. Profiles are typically defined by a user's job function (for example, system administrator or sales representative), but you can have profiles for anything that makes sense for your organization. A profile can be assigned to many users, but a user can be assigned to only one profile at a time. It is worth spending the necessary time up-front to align your various user sets with profiles, depending on what they need to see and do in the application. Field-Level Security Once you have restricted access to objects as a whole with profiles, you may want to limit access to individual object fields. Field-level security controls whether a user can see, edit, and delete the value for a particular field on an object. It allows you to protect sensitive fields without having to hide the whole object from certain profiles. Field-level security is controlled within profiles. Unlike page layouts, which only control the visibility of fields on detail and edit pages, field-level security controls the visibility of fields in any part of the app, including related lists, list views, reports, and search results. To be absolutely sure that a user cannot access a particular field, it is important to use the field-level security page for a given object to restrict access to the field. There are no other shortcuts that provide the same level of protection for an individual field. Important: Field-level security does not prevent searching on the values in a field. If you do not want users to be able to search and retrieve records that match a value in a field hidden by field-level security, contact salesforce.com Customer Support for assistance with setting up your organization to prevent unwanted access to those field values. Record-Level Security (Sharing) After setting object- and field-level access permissions for your various profiles, you need to configure the access permissions for the actual records themselves. Record-level security allows you to grant users access to some object records, but not others. To specify record-level security, set your organization-wide defaults, define a role hierarchy, and create sharing rules: The first step in record-level security is to determine the organization-wide defaults for each object. Organization-wide defaults specify the default level of access to records and can be set separately for accounts (including assets and contracts), activities, contacts, campaigns, cases, leads, opportunities, calendars, price books, and custom objects. For most objects, organization-wide defaults can be set to Private, Public Read Only, or Public Read/Write. You use organization-wide defaults to lock down your data to the most restrictive level, and then use the other record-level security and sharing tools (role hierarchies, sharing rules, and manual sharing) to open up the data to other users who need to access it. For example, for users whose profiles allow them to see and view opportunities, you can set the default to Read-Only. Those users are able to read all opportunity records, but cannot edit any unless they own the record or are granted additional permissions. The first way you can share access to records is by defining a role hierarchy. Similar to an organization chart, a hierarchy represents a level of data access that a user or group of users needs.the role hierarchy ensures that a manager 7

10 Security Overview Key Profile Permissions always has access to the same data as his or her employees, regardless of the organization-wide default settings. Role hierarchies do not have to match your organization chart exactly. Instead, each role in the hierarchy should represent a level of data access that a user or group of users needs. You can also use a territory hierarchy to share access to records. A territory hierarchy grants users access to records based on criteria such as zip code, industry, revenue, or a custom field that is relevant to your business. For example, you could create a territory hierarchy in which a user with the North America role has access to different data than users with the Canada and United States roles. Note: Although it is easy to confuse profiles with roles, they control two very different things. Profiles control a user's object- and field-level access permissions. Roles primarily control a user's record-level access permissions through role hierarchy and sharing rules. Sharing rules let you make automatic exceptions to organization-wide defaults for particular sets of users to give them access to records they do not own or cannot normally see. Sharing rules, like role hierarchies, are only used to open up record access to more users, and can never be stricter than your organization-wide default settings. Sharing rules work best when they are defined for a particular set of users that you can determine or predict in advance, rather than a set of users that is frequently changing. A set of users can be a public or personal group, a role, a territory, or a queue. Sometimes it is impossible to define a consistent group of users who need access to a particular set of records. In those situations, record owners can use manual sharing to give read and edit permissions to users who would not have access to the record any other way. Although manual sharing is not automated like organization-wide defaults, role hierarchies, or sharing rules, it gives record owners the flexibility to share particular records with users that need to see them. If sharing rules and manual sharing do not give you the control you need, you can also use Apex managed sharing. Apex managed sharing allows developers to use Apex to programmatically share custom objects. When you use Apex managed sharing to share a custom object, only users with the Modify All Data permission can add or change the sharing on the custom object's record, and the sharing access is maintained across record owner changes. Key Profile Permissions Profiles contain administrative permissions and general user permissions, which in turn control what actions a user can take. There are several permissions that are particularly powerful, and deserve special discussion. Caution: Permissions are very powerful. They greatly expand access to data. Exercise caution when deciding to enable these permissions for a profile. Manage Users A user with this permission can grant any other permission to themselves and other users. This permission makes a user a super administrator. Customize Application This permission grants a broad range of permissions that allow a user to control all aspects of an application from creating, editing, and deleting custom fields, to implementing workflow rules. Application developers need this permission, but you should be aware of the range of operations this permission grants. 8

11 Security Overview Auditing Modify All Data This permission overrides any restrictions on modifying data in all objects. It also circumvents the entire system of record-based sharing. If you only need to give users the ability to modify all data for a particular object, you can assign the object-level permission Modify All. View All Data This permission overrides any restrictions on viewing data in all objects. It also circumvents the entire system of record-based sharing. If you only need to give users the ability to view all data for a particular object, you can assign the object-level permission View All. Edit Read Only Fields This permission allows users to edit fields marked as read-only by field-level security or by the page layout. View Encrypted Data This permission allows users to view data in encrypted fields as plain-text data. For more information about encrypted fields, see About Encrypted Custom Fields in the Salesforce.com online help. Auditing Auditing features do not secure your organization by themselves, but these features provide information about usage of the system, which can be critical in diagnosing potential or real security issues. It is important that someone in your organization perform regular audits to detect potential abuse. The other security features provided by Salesforce.com are preventative. To verify that your system is actually secure, you should perform audits to monitor for unexpected changes or usage trends. Auditing features include: Record Modification Fields All objects include fields to store the name of the user who created the record and who last modified the record. This provides some basic auditing information. Login History You can review a list of successful and failed login attempts to your organization for the past six months. See Monitoring Logins on page 42. Field History Tracking You can also enable auditing for individual fields, which will automatically track any changes in the values of selected fields. Although auditing is available for all custom objects, only some standard objects allow field-level auditing. See Tracking Field History on page 43. Setup Audit Trail s can also view a Setup Audit Trail, which logs when modifications are made to your organization's configuration. See Monitoring Setup Changes on page 46. 9

12 Chapter 2 Securing and Sharing Data Review the following sections for detailed instructions and tips on securing access to your data in Salesforce.com. Managing Profiles User Permissions Needed To create, edit, or delete profiles: Manage Users A profile contains the user permissions that control different functions within Salesforce.com, the partner portal, and the Customer Portal. Profiles also control: Which standard and custom apps the user can view (depending on user license) Which tabs the user can view (depending on user license and other factors, such as access to Salesforce CRM Content) Which permissions a user is granted to create, read, edit, and delete records for each object Which page layouts the user sees Which console layouts the user sees The field-level security access that the user has to view and edit specific fields Which record types are available to the user The hours during which and IP addresses from which the user can log in Which desktop clients users can access and related options Note: This functionality is not available in Developer Edition. Whether the user can edit Apex Which users can execute methods in a particular top-level Apex class (see Setting Apex Class Security in the Salesforce.com online help) The public access settings for Force.com Sites users To create, edit, and delete profiles, click Setup Manage Users Profiles. There are standard profiles in every Salesforce.com organization. In Contact Manager, Group, and Professional Edition organizations, you can assign the standard profiles to your users. However, you cannot view or edit the standard profiles or create custom profiles. In Enterprise, Unlimited, and Developer Edition organizations, you can use the standard profiles or create, edit, and delete custom profiles. For the standard profiles, only certain settings can be changed. Each standard or custom profile belongs to exactly one user license type. 10

13 Securing and Sharing Data User Permissions on Profiles User Permissions on Profiles User Permissions Needed To create, edit, or delete profiles: To view profiles: Manage Users View Setup and Configuration User permissions are divided into the following: Administrative Permissions General Permissions Standard and Custom Object Permissions Desktop Integration Client Permissions Apex Class Permissions Administrative Permissions The following table shows the administrative permissions associated with each standard profile. Administrative Permissions Permission Name Affected by Divisions API Enabled Functions Controlled Filter a user s search results, list views, and reports by division. With this permission deselected, a user s searches, list views, and reports always show records in all divisions. Enterprise, Unlimited, and Developer Edition organizations can edit this user permission on standard and custom profiles Grants access to the API, Bulk API, and Metadata API Profiles Standard User Solution Manager Marketing User Contract Manager API Only User Author Apex Customize Application Prevents access to Salesforce.com except via the API or Bulk API Can modify and deploy Apex classes and triggers, set security on Apex classes, and create services Edit messages and custom links; Modify standard picklist values; Create, edit, and delete custom fields; Create, edit, and delete page layouts (also requires the Edit permission for the record, for example, Edit on accounts); None 11

14 Securing and Sharing Data User Permissions on Profiles Permission Name Administrative Permissions Functions Controlled Set field-level security; Create, edit, and delete custom links; Edit the Lead Settings; Activate big deal alerts; Create record types; Set up Web-to-Case and response rules; Set up Web-to-Lead and response rules; Set up assignment and escalation rules; Set up business hours; Set up -to-Case or On-Demand -to-Case; Edit Self-Service page layouts and portal color theme (also requires the Manage Self-Service Portal permission to set up and maintain Self-Service settings and delete your organization's Self-Closed Case Status value); Set up and enable multilingual solutions; Set up team selling; Set up account teams; Map custom lead fields; Manage queues; Create, edit, and delete workflow rules, tasks, field updates, outbound messages, and alerts; Create, edit, and delete custom s-controls, custom objects, and custom tabs; Rename tabs; Manage custom apps; Create and edit public calendars and resources; Set up the console; Enable, set up, and modify the Salesforce.com Customer Portal; Profiles 12

15 Securing and Sharing Data User Permissions on Profiles Permission Name Administrative Permissions Functions Controlled Set up and schedule analytic snapshots to run; Create communities for ideas and answers; Create Visualforce templates Profiles Delegated Portal User Edit HTML Templates Edit Read Only Fields Manage Analytic Snapshots Manage Billing Allows Customer Portal and Partner None Portal users to create, edit, deactivate, and reset passwords for other portal users (also requires Portal Super User to create and view cases for Customer Portal users) Create, edit, and delete both custom HTML templates and HTML templates using letterheads Edit fields marked as read-only (by field-level security or by the page layout) for all other users Set up and schedule analytic snapshots to run (also requires the Schedule Dashboards, Run Reports, and View Setup and Configuration permissions) Add user licenses; Edit billing and credit card information Marketing User Manage Business Hours Holidays Manage Call Centers 'Manage Categories Manage Custom Report Types Create and edit business hours; create, edit, and delete holidays (also requires View Setup and Configuration ) Import, view, edit, and delete a call center (also requires View Setup and Configuration ) Define and modify solution categories; Edit Solution Settings to enable solution browsing This permission only applies to solution categories, not data categories Create, edit, and delete custom report types (also requires View Setup and Configuration to view the organization Setup pages where custom report types are managed) 13

16 Securing and Sharing Data User Permissions on Profiles Permission Name Manage Dashboards Manage Data Categories Manage Data Integrations Administrative Permissions Functions Controlled Create, edit, and delete dashboards (also requires Modify All Data to edit a dashboard created by another user) Create, edit, and delete data categories This permission only applies to data categories, not solution categories Monitor Bulk API jobs Profiles Manage Client Configurations Manage Letterheads Create, edit, and delete Outlook configurations for Salesforce CRM for Outlook. Salesforce CRM for Outlook is available through a pilot program. For information on enabling Salesforce CRM for Outlook for your organization, contact salesforce.com. Create, edit, and delete letterheads for HTML s Marketing User Manage Mobile Configurations Manage Package Licenses Manage Partners Manage Public Documents Manage Public List Views Edit the Mobile User checkbox on a user's personal information. Enabling the Mobile User checkbox allocates one Salesforce Mobile license to the user, granting the user access to Salesforce Mobile capabilities. Grant or revoke user licenses for an installed app in a managed package Create partner accounts and partner users; Disable partner accounts and partner users; Merge partner users (also requires Delete on contacts) Create, update, and delete public document folders Create, edit, and delete public list views Marketing User 14

17 Securing and Sharing Data User Permissions on Profiles Permission Name Manage Public Reports Manage Public Templates Manage Synonyms Manage Salesforce CRM Content Manage Salesforce Knowledge Manage Translation Manage Users Administrative Permissions Functions Controlled Create, edit, and delete public reports; Customize the Reports tab Create, edit, and delete text and mail merge templates; Edit public folders for templates and store templates in folders Create, edit, and delete synonym groups Create, edit, and delete workspaces; Edit workspace membership Enable Salesforce Knowledge Create, edit, and delete article types Edit settings Add supported languages and translators; Enter translated values for any supported language; Translate solution categories Create, edit, and deactivate users; Define and assign user roles; Define sharing model and sharing rules; View storage use; View login history; View training history; Manage and assign profiles; Assign page layouts to profiles; Set password policies; Activate or deactivate opportunity update reminders; Set login restrictions Profiles Marketing User Modify All Data Create, edit, and delete all data; Import accounts and contacts for organization; Mass update addresses (also requires Activate Contract and Activate Order 15

18 Securing and Sharing Data User Permissions on Profiles Permission Name Password Never Expires Portal Super User Schedule Dashboards Schedule Reports Send Outbound Messages Tag Manager Transfer Record Administrative Permissions Functions Controlled to update the addresses of contracts and orders); Mass delete data; Undelete other users data; Create and edit divisions, and transfer divisions for multiple records Create an organization-wide address Prevent password from ever expiring Allows Customer Portal users to view and edit all cases for their account Schedule when dashboards refresh and send notifications to users that include refreshed dashboards in HTML format Schedule reports to run and have the results automatically ed in HTML format to Salesforce.com users Allows you to send outbound messages, such as when you close an opportunity and need to send an outbound API message to another server to generate an order. See Setting Up Outbound Messaging in the Force.com Web Services API Developer's Guide. Rename, delete, or restore public tags (available only when public tags are enabled) Transfer ownership of one or more accounts, campaigns, cases, contacts, contracts, leads, and custom objects that are owned by another user. To transfer records owned by another user, you must also have at least the Edit object permission and access to view the records. Profiles None None Standard User Solution Manager Marketing User Read Only Contract Manager Standard Platform User Standard Platform One App User 16

19 Securing and Sharing Data User Permissions on Profiles Permission Name Use Team Reassignment Wizards View All Data View Data Categories View Encrypted Data View Setup and Configuration Weekly Data Export Administrative Permissions Functions Controlled Mass reassign account team and opportunity team members View all data owned by other users View the Setup Customize Data Categories page This permission only applies to data categories, not solution categories View the value of encrypted fields in plain text View the organization setup details on the Setup pages; Run user reports; View the setup audit trail; Check field accessibility for users Run the weekly data export service Profiles None Standard User Solution Manager Marketing User Read Only Contract Manager General Permissions The following table shows the general permissions associated with each standard profile. General User Permissions Permission Name Activate Contracts Approve Contracts Convert Leads Functions Controlled Change contract status to Activate; Create, edit and delete contracts Apply an approved status to a contract Convert leads into accounts, contacts, and opportunities Profiles Contract Manager Contract Manager Standard User 17

20 Securing and Sharing Data User Permissions on Profiles Permission Name Create and Customize Reports Create AppExchange Packages Create Workspaces Delete Activated Contracts General User Permissions Functions Controlled View the Reports tab; Run, create, edit, save, and delete reports; View dashboards based on reports Create AppExchange packages Create Salesforce CRM Content workspaces Delete contracts regardless of status; Activate, create, and edit contracts Profiles Solution Manager Marketing User Contract Manager Standard User Solution Manager Marketing User Read Only Contract Manager Deliver Uploaded Files and Personal Content Enables non-content users to create content deliveries and enablessalesforce CRM Content users to create content deliveries using documents in their Standard User personal workspaces. Note that Salesforce Solution Manager CRM Content users do not need this perm to create content deliveries in Marketing User shared workspaces. Read Only Contract Manager Download AppExchange Packages Install or uninstall AppExchange packages from the AppExchange Edit Case Comments Edit Events Enables users to edit and delete case comments that they have added to cases (also requires Edit on cases) Create, edit, and delete events None Standard User Solution Manager Marketing User 18

21 Securing and Sharing Data User Permissions on Profiles Permission Name General User Permissions Functions Controlled Profiles Contract Manager Edit Forecasts Create, edit, and delete forecasts. This permission is not available for customizable forecasts. When you convert to customizable forecasts, custom Standard User profiles that have the Edit Forecasts Solution Manager permission get the Edit Personal Quota and Override Forecasts permissions. Marketing User Contract Manager Edit Opportunity Product Sales Prices Edit Personal Quota Enable users to change the sales price on products Change your individual quota (available only for customizable forecasts) Standard User Solution Manager Marketing User Contract Manager Standard User Solution Manager Marketing User Contract Manager Edit Self-Service Users For the Self-Service portal: enable and deactivate contacts; For the Salesforce.com Customer Portal: Standard User enable, disable, and deactivate contacts; disable accounts; merge Customer Portal Solution Manager users (also requires Delete on contacts) Marketing User Edit Tasks Create, edit, and delete tasks Contract Manager Standard User Solution Manager Marketing User Contract Manager 19

22 Securing and Sharing Data User Permissions on Profiles Permission Name Export Reports Import Leads Import Personal Contacts Import Solutions Manage Articles Manage Cases General User Permissions Functions Controlled Use Export Details and Printable View to export reports Import leads and update campaign history using import wizards Import personal accounts and contacts Import solutions for the organization Create, edit, assign, publish, delete, and archive Salesforce Knowledge articles This permission provides full access to the Article Management tab Modify support settings Close multiple cases Profiles Standard User Solution Manager Marketing User Contract Manager Marketing User Standard User Solution Manager Marketing User Contract Manager Solution Manager None Manage Content Permissions Create, edit, and delete workspace permissions in Salesforce CRM Content Manage Content Properties Manage Content Types Create, edit, and delete custom fields in Salesforce CRM Content Create, edit, and delete content types in Salesforce CRM Content 20

23 Securing and Sharing Data User Permissions on Profiles General User Permissions Permission Name Manage Entitlements Functions Controlled Set up and maintain entitlement management; Enable and disable entitlement management, including entitlements, service contracts, and contract line items; Create, edit, and delete entitlement templates; Create, edit, and delete milestones; Create, edit, and delete entitlement processes Profiles Manage Leads Manage Published Solutions Manage Self-Service Portal Manage Territories Mass Change Status of multiple leads in a list view Create, edit, and delete solutions that are accessible to the public on your Self-Service portal or website; Categorize solutions Set up and maintain Self-Service settings (also requires the Customize Application permission to modify Self-Service page layouts and delete your organization's Self-Closed Case Status value); Run Self-Service reports Create and edit territories; Add and remove users from territories; Create and edit account assignment rules; Manually assign accounts to territories; Configure organization-wide territory management settings Send bulk s to contacts and leads Solution Manager Standard User Solution Manager Marketing User Contract Manager 21

24 Securing and Sharing Data User Permissions on Profiles Permission Name Mass Edit from Lists Override Forecasts Products Show in Offline Run Reports Send General User Permissions Functions Controlled Allow users to edit two or more records simultaneously from a list with inline editing Override your own forecast, as well as forecasts for users that report directly to you in the role hierarchy (available only for customizable forecasts) Specify if products and price books are available in Connect Offline View the Reports tab; Run reports; View dashboards based on reports Send to a single contact or lead; Send Stay-in-Touch update s Profiles Standard User Solution Manager Marketing User Contract Manager, Standard Platform User Standard Platform One App User Standard User Solution Manager Marketing User Contract Manager Standard User Solution Manager Marketing User Read Only Contract Manager Standard User Solution Manager Marketing User Read Only Contract Manager Standard User Solution Manager Marketing User 22

25 Securing and Sharing Data User Permissions on Profiles Permission Name Send Stay-in-Touch Requests General User Permissions Functions Controlled Send Stay-in-Touch requests Profiles Contract Manager Standard User Solution Manager Marketing User Contract Manager Show Custom Sidebar On All Pages Transfer Cases Transfer Leads Upload AppExchange Packages If you have custom home page layouts None that include components in the sidebar, displays your custom sidebar on all pages in Salesforce.com. If the Show Custom Sidebar Components on All Pages user interface setting is selected, the Show Customer Sidebar On All Pages permission is not available. Transfer one or more cases that are owned by another user, if you also have at least the Edit object permission and access to view the records Transfer one or more leads that are owned by another user, if you also have at least the Edit object permission and access to view the records Upload AppExchange packages to AppExchange; Create test drives Uses Single Sign-On View All Forecasts Username and password authentication is delegated to a corporate database such as Active Directory or LDAP, instead of the Salesforce.com user database. See About Single Sign-On in the Salesforce.com online help. View any user s forecast regardless of the forecast role hierarchy. This permission is only available for customizable forecasts. When you convert to customizable forecasts, custom profiles that have the View All Data permission get the View All Forecasts permissions. None 23

26 Securing and Sharing Data User Permissions on Profiles Permission Name View Articles View Content in Portals General User Permissions Functions Controlled Read articles in Salesforce Knowledge This permission provides full access to the Articles tab Allows Customer Portal and Partner Portal users to view Salesforce CRM Content Profiles Standard User Solution Manager Marketing User Contract Manager None Standard and Custom Object Permissions The following permissions specify the access that users have to standard and custom objects. These permissions either respect the sharing model, or override sharing: Object-Level Permissions that Respect Sharing Read users can only view records of this type Create users can read and create records Edit users can read and update records Delete users can read, edit, and delete records Object-Level Permissions that Override Sharing for Delegated Data Administration View All users can view all records associated with this object, regardless of sharing settings Modify All users can read, edit, delete, transfer, and approve all records associated with this object, regardless of sharing settings Modify All on documents allows access to all shared and public folders, but not the ability to edit folder properties or create new folders. To edit folder properties and create new folders, users must have the Manage Public Documents permission. View All and Modify All are not available for ideas, price books, and products. The View All and Modify All permissions ignore sharing rules and settings, allowing administrators to quickly grant access to records associated with a given object across the organization. View All and Modify All are for delegated administrators who are responsible for managing the records belonging to a given object, while the global permissions View All Data and Modify All Data are for the administrator of your entire organization. Tasks where these permissions may be applicable include data cleansing, deduplication, mass deletion, mass transferring, and managing record approvals. If providing the View All Data or Modify All Data administrative permission is too permissive for a particular profile, consider using the View All or Modify All object-level permission to restrict data access and management on an object basis. See Comparing Security Models in the Salesforce.com online help. Note: The View All and Modify All permissions allow for delegation of object permissions only. To delegate some user administration and custom object administration duties, you can define delegated administrators. 24

27 Securing and Sharing Data Setting Field-Level Security If your organization has deployed Salesforce Mobile, you can edit the mobile object properties to prevent mobile users from creating, editing, and deleting records in the mobile application, regardless of their standard object permissions in Salesforce.com. Desktop Integration Client Permissions Connect for Outlook, Connect Offline, Connect for Office, and Connect for Lotus Notes are desktop clients that integrate Salesforce.com with your PC. As an administrator, you can control which desktop clients your users can access as well as whether users are automatically notified when updates are available. See Setting User Permissions for Desktop Clients in the Salesforce.com online help. Apex Class Permissions In Unlimited, Enterprise, and Developer Edition organizations, users can use profiles to control which users can execute methods in a particular top-level Apex class. Setting Field-Level Security User Permissions Needed To set field-level security: Customize Application You can define which fields users can access. Field-level security settings let administrators restrict users access to view and edit specific fields on detail and edit pages and in related lists, list views, reports, Connect Offline, search results, and mail merge templates, custom links, the PRM portal, the Salesforce.com Customer Portal, and when synchronizing data or importing personal data. The fields that users see on detail and edit pages are a combination of page layouts and field-level security settings. The most restrictive field access settings of the two always apply. For example, if a field is required in the page layout and read only in the field-level security settings, the field-level security overrides the page layout and the field will be read only for the user. Important: Field-level security does not prevent searching on the values in a field. If you do not want users to be able to search and retrieve records that match a value in a field hidden by field-level security, contact salesforce.com Customer Support for assistance with setting up your organization to prevent unwanted access to those field values. You can define field-level security from a profile or from a particular field. To define field-level security: 1. Do one of the following: To set field-level security for all fields on a particular profile: a. Select Setup Manage Users Profiles. b. Select a profile to change the field access for users with that profile. c. In the Field-Level Security section, click View next to the tab you want to modify, and then click Edit. To set field-level security for a particular field on all profiles: a. Select Setup Customize, click a tab or activity link, and click Fields. b. Select the field you want to modify. c. Click Set Field-Level Security. 25

28 Securing and Sharing Data Setting Your Organization-Wide Default Sharing Model 2. Specify whether the fields should be visible, hidden, read only, or editable (visible without read only) for users based on their profile. Note that these field access settings apply throughout Salesforce.com. The settings also override any less-restrictive field access settings on the page layouts or article-type layouts. 3. Click Save. After setting field-level security for users based on their profiles, you can: Create page layouts to organize the fields on detail and edit pages; see Managing Page Layouts in the Salesforce.com online help. Tip: Use field-level security as the means to restrict users access to fields; then use page layouts primarily to organize detail and edit pages within tabs. This reduces the number of page layouts for you to maintain. Verify users access to fields by checking the field accessibility grid; see Checking Field Accessibility in the Salesforce.com online help. Set the fields that display in search results, in lookup dialog search results, and in the key lists on tab home pages; see Customizing Search Layouts in the Salesforce.com online help. Note: Roll-up summary and formula fields are always read only on detail pages and not available on edit pages. They may also be visible to users even though they reference fields that your users cannot see. Universally required fields always display on edit pages regardless of field-level security. The relationship group wizard allows you to create and edit relationship groups regardless of field-level security. For more information on the behaviors of relationship group members, see Relationship Group Considerations in the Salesforce.com online help. Setting Your Organization-Wide Default Sharing Model User Permissions Needed To set default sharing access: Manage Users AND Customize Application An administrator can define the default sharing model for your organization by setting organization-wide defaults. Organization-wide defaults specify the default level of access to records and can be set separately for accounts (including assets and contracts), activities, contacts, campaigns, cases, leads, opportunities, calendars, price books, and custom objects. For most objects, organization-wide defaults can be set to Private, Public Read Only, or Public Read/Write. See Sharing Model Fields in the Salesforce.com online help for the various options. Tip: Developers can use Apex to programmatically share custom objects. For more information, see Apex Managed Sharing in the Salesforce.com online help and the Force.com Apex Code Developer's Guide. By default, Salesforce.com uses hierarchies, like the role or territory hierarchy, to automatically grant access of records to users above the record owner in the hierarchy. Professional, Enterprise, Unlimited, and Developer Edition organizations can disable this for custom objects using the Grant Access Using Hierarchies checkbox next to the organization-wide defaults setting. 26