It's not a secret, some things are meant to be private. Thankfully, with the use of a few security features, you can keep the peeping toms of the world out, hide what you don't want them to see, and eliminate the ability for them to modify data.
As your first step for setting up security, you can set organization-wide defaults for any Force.com object. As the name implies, the organization-wide default specifies the level of sharing for all records in that object for all users within the organization. Organization-wide defaults specify the absolute minimum level of access to the records in an object, and everyone has at least the privileges granted by organization-wide defaults.
Once you have locked down access with organization-wide defaults, you can open up access for others through sharing. You can use sharing to grant access to any set of privileges greater than those established by organization-wide defaults, such as granting read-write privileges for a user to a record that had either private or read-only established for its organization-wide default.
The platform security architecture also lets you define administrative security permissions, and with functional permission control you determine who has access to which features and components - ranging from the Setup menu all the way through to read-write settings on an object or field.
This article will briefly cover the different ways you can control what people can see and can do with your org data.
When creating a user in your org you must specify a role, which defines the user's place in a role hierarchy. In a role hierarchy, all users automatically have all the sharing privileges granted to those in subordinate roles in the hierarchy. In other words, a user with a manager role has all sharing privileges granted to all users in roles which report to that manager role. You can only have one role hierarchy in an organization.
You can also combine users into public groups. All users within a public group have the sharing privileges of that group. Groups can share privileges with other groups, which means that both groups have the same sharing privileges. This reciprocal sharing is different from the hierarchical sharing implemented with roles, but defines sharing privileges nonetheless.
The following picture is a snapshot of a sharing rule creation screen on an invoice object. It allows Invoice records created by members of the Director (Channel Sales) role to be shared with all members and subordinates of the Channel Sales Team role. In addition, sharing is granted at a Read/Write access level.
A profile defines a user's permission to access records and perform actions. Everyone in your org is assigned a profile. By assigning different profiles to different users, you can create unique work environments for each user and control how each set of users can view and manipulate data.
To create and modify profiles, navigate to Setup | Manage Users | Profiles. Profiles give you control over low level permissions around data manipulation on objects, as well as access permissions on components (apps, tabs, classes, pages, etc). Profiles also allow you to assign administrative privileges and permissions on all of the standard and custom objects in the org.
In addition to profiles, Force.com also has permission sets to grant additional access to one or more users without changing or reassigning profiles. Permission sets open up permissions and are used to grant additional access, but not to deny or restrict access.
Before the existence of permission sets, you often had to create a profile for a single use case, but no longer. Now you can add a permission set, or multiple permission sets, to any user and give the person exactly the access they need without changing their profile. Permission sets are especially useful in the context of apps, because you can grant access for all of the elements (objects, classes, pages, etc) to any user that would need it in the org, regardless of their role or profile. Permission sets can be thought of an as extension to profiles, and a more flexible way to control functional access.
If you would like more granular control into the visibility of certain fields rather than just overall read/write control of a given object, you can use field-level security. Field-level security controls not only the visibility to see the field on a page, but also the ability to edit the field from a record. The third step of the custom field wizard allows you to grant edit access to the field itself.
In short, all of the security elements listed above layer access: roles/groups, profiles, permission sets, and field level security. Sharing roles and groups determine record level access and are ideal for mitigating what records a user can see or edit. Profiles and permission sets are functional access controls and determine what users can do within their sharing model.
It is important to set up your sharing model at an organization-wide level first, and then if your apps become more complex setup sharing rules for objects that need to be restricted to certain users. Of those users that can see the record, you can configure which set of users can modify it. Finally, if you need to customize tailor your restrictions more specifically than simply the record or object itself, you can control this level of access all the way down to the field level.