Go through the following documentation :

Object-Level Security (Profiles)
Object-level security provides the bluntest way to control data in Salesforce. 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 doesn't prevent searching on the values in a field. To set up your organization to prevent users from searching and retrieving records that match a value in a field hidden by field-level security, contact salesforce.com Customer Support.

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. Every record is owned by a user or a queue. The owner has full access to the record. Hierarchies allow administrators to ensure that users higher in a hierarchy (such as managers in a role hierarchy) always have access to the data visible 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:

* The first step in record-level security is to determine the organization-wide sharing settings for each object. Organization-wide sharing settings 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 sharing settings can be set to Private, Public Read Only, or Public Read/Write.

You use organization-wide sharing settings 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 role hierarchy represents a level of data access that a user or group of users needs. The role hierarchy ensures that a manager 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.

* Sharing rules let you make automatic exceptions to organization-wide sharing settings 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 sharing settings, 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.