How Secure is Salesforce?

• Salesforce.com is dedicated to helping its customers to be more secure when accessing Salesforce accounts. With the evolving threat landscape, Salesforce encourages customers to take action & help to prevent unauthorized access in their Salesforce org.
• 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 protects the organization’s data from all other customer organizations by using a unique organization identifier, which is associated with each user’s session. Once you login to your organization, your subsequent requests are associated with your organization, using this identifier.
• Salesforce utilizes some of the most advanced technology for Internet security available today. When you access the application using a Salesforce-supported browser, Transport Layer Security (TLS) 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.
• Salesforce is hosted in a secure server environment that uses a firewall and other advanced technology to prevent interference or access from outside intruders.
• Trust starts with transparency. That’s why Salesforce displays real-time information on system performance and security on the trusted site at http://trust.salesforce.com. This site provides live data on system performance, alerts for current and recent phishing and malware attempts, and tips on best security practices for your organization.
• Salesforce is committed to setting the standards in software-as-a-service as an effective partner in customer security. 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.

Evaluating and developing new technologies both for our customers and for deployment in our infrastructure.

What is Data Encryption?

Data encryption is the act of changing electronic information into an unreadable state by using algorithms or ciphers. Originally, data encryption was used for passing government and military information electronically.

Encryption In Data Transmission:

Salesforce.com invests heavily in network defense. Salesforce uses the same world-class security as global banks possess for their banking infrastructure. For example, Salesforce encrypts all data transmissions that involve its 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. Salesforce employs perimeter firewalls and edge routers to block unused transmission protocols, and use internal firewalls to segregate traffic between the application and database tiers.

Encryption Of 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.

Crypto Class:

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 as well as functions for encrypting and decrypting information. These functions allow you to protect the confidentiality of data as well as allow external systems to verify the integrity of messages and authenticity of the sender.

The cryptographic capabilities of the Crypto class are normally used in the following scenarios:

• Confidentiality – the protection of data either at rest or in transit from unauthorized parties
• Integrity – the data is complete and correct
• Authenticity – proof of the authenticity of the sender or receiver of the message

Data Access Security for Internal Users

To enable users to do their job without exposing data that they do not need to see, Salesforce provides a flexible, layered sharing design that allows you to expose different data sets to different sets of users.

• To specify the objects that users can access, you can assign permission sets and profiles.
• To specify the fields that users can access, you can use field-level security.
• To specify the individual records that users can view and edit, you can set your organization-wide sharing settings, define a role hierarchy, and create sharing rules.

The following describes these security and sharing settings:

Object-Level Security (Permission Sets and Profiles)

Object-level security—or object permissions—provide the bluntest way to control data. Using object permissions you can prevent a user from seeing, creating, editing, or deleting any instance of a particular type of objects, such as a lead or opportunity. Object permissions let you hide whole tabs and objects from a particular user so that they don’t even know that type of data exists.

Field – Level Security (Permission Sets and Profiles)

In some cases, you may want users to have access to an object, but limit their access to individual fields in that object. Field-level security or field permissions control whether a user can see, edit, and delete the value for a particular field on an object. They let you protect sensitive fields without having to hide the whole object from users. Field permissions are also controlled by permission sets and profiles.

Record – Level Security (Sharing)

After setting object- and field-level access permissions, you may want to configure access settings for the actual records themselves. Record level security lets you give users access to some object records, but not others. Every record is owned by a user or a queue. The owner has full access to the record. In a hierarchy, users higher in the hierarchy always have the same access to users below them in the hierarchy. This access applies to records owned by users, as well as records shared with them.

To specify record-level security, set your organization-wide sharing settings, define a hierarchy, and create sharing rules.

Data Access Security for Community/Portal Users

If your organization has enabled a community and has portal licenses provisioned for it, User Sharing is enabled automatically. When User Sharing is on, you can choose which other users community users can see by default. If your organization has Customer or Partner Portals, you can choose a default for them as well. Users who can see one another can interact with all the communities or portals in your organization. For example, if you would like to have a more private community, you can deselect the Community User Visibility checkbox and use other sharing features like sharing rules, manual shares, or portal access.

For Communities and Portals, you can choose different defaults.

Communities:

The initial default is to allow community users to be seen by all other internal and external users in communities they are a member of. You can change the default to allow external users in communities to be seen only by themselves and their superiors in the role hierarchy. The setting provides Read access only and applies to all communities in your organization.

Visibility to users as a result of the Community User Visibility preference is not inherited through the role hierarchy. If a manager in the role hierarchy is not a member of a community, but their subordinate is, the manager does not gain access to other members of the community.

Portals:

The initial default is to allow portal users to be seen by other portal users within the same account. You can change the default to allow external users in portals to be seen by only themselves and their superiors in the role hierarchy. The setting provides Read access only and applies to all of the portals in your organization.

References:

1. https://developer.salesforce.com/page/Security
2. https://help.salesforce.com/apex/HTViewHelpDoc?id=security_sharing_owd_external_user_settings.htm&language=en_US
3. https://help.salesforce.com/HTViewHelpDoc?id=security_data_access.htm
4. https://www.salesforce.com/developer/docs/api/Content/sforce_api_concepts_security.htm
5. https://help.salesforce.com/apex/HTViewHelpDoc?id=fields_about_encrypted_fields.htm