Compartilhar via

Security concepts for Microsoft Dynamics CRM

  • Artigo

 

Applies To: Dynamics CRM 2013

You can use the security model in Microsoft Dynamics CRM to protect the data integrity and privacy in or organization and also supports efficient data access and collaboration. The Microsoft Dynamics CRM security model supports recommended security best practices. The goals of the model are as follows:

  • Support a licensing model for users.

  • Provide users with access only to the appropriate levels of information that is required to do their jobs

  • Categorize users and teams by security role and restrict access based on those roles.

  • Support data sharing so that users can be granted access to objects they do not own for a one-time collaborative effort.

  • Prevent access to objects a user does not own or share.

You will combine role-based security, record-based security, and field-based security to define the overall access to information that users have in your Microsoft Dynamics CRM organization.

For more information about security topics, see the Microsoft Dynamics CRM SDK topic, The Security Model of Microsoft Dynamics CRM.

Role-based security

You can use to group sets of privileges together into roles that describe the tasks that can be performed by a user or team. Microsoft Dynamics CRM includes a set of predefined security roles, each of which is a set of privileges aggregated to make security management easier. The bulk of the privileges define the ability to create, read, write, delete and share records of a specific entity type. Each privilege also defines how broadly the privilege applies: at the user level, business unit level, the entire business unit hierarchy or across the entire organization.

For example, if you sign in as a user that is assigned the Salesperson role, you have the privileges to read, write and share accounts for the entire organization, but you can only delete account records that you own. Also, you have no privileges to perform system administration tasks such as install product updates, or to add users to the system.

A user that has been assigned the Vice President of Sales role can perform a wider set of tasks (and has a greater number of privileges) associated with viewing and modifying data and resources than can a user who has been assigned to the Salesperson role. A user assigned the Vice President of Sales role can, for instance, read and assign any account to anyone in the system, while a user assigned the Salesperson role cannot.

There are two roles that have very broad privileges: System Administrator and Customizer. Use of these two roles should be limited to a few people in your organization. Each deployment can also customize existing roles and create its own roles to meet their needs.

Record-based security

You can use record-based security to control user and team rights to perform actions on individual records. This applies to instances of entities (records) and is provided by access rights. The owner of a record can share, or grant access to a record to another user or team. When this is done, they must choose which rights they are granting. For example, the owner of an account record can grant read access to that account information, but not grant write access.

Access rights apply only after privileges have taken effect. For example, if a user does not have the privileges to view (read) account records, they will be unable to view any account, regardless of the access rights another user might grant them to a specific account through sharing.

Field-based security

You can use field-level to restrict access to specific high business impact custom fields in an entity only to specified users or teams. Like record-based security, this applies after privileges have taken affect. For example, a user may have privileges to read an account, but can be restricted from seeing specific fields in all accounts.

Deployment-wide administrative-level security

During installation, Microsoft Dynamics CRM Server Setup creates a special deployment-wide administrator role and attaches it to the user account that is used to run Setup. The Deployment Administrator role is not a security role and does not appear in the Microsoft Dynamics CRM web application as such.

Deployment Administrators have complete and unrestricted access to all organizations in Deployment Manager in the deployment. For example, Deployment Administrators can create new organizations or disable any existing organization in the deployment. On the other hand, members of the System Administrator Role only have permissions where the user and security role are located.

Important

When a deployment administrator creates an organization, that administrator must give db_owner privileges for the org’s databases to the other deployment administrators so that they also have full access to those organizations.

For more information about the Deployment Administrator role, see the Deployment Manager Help.

See Also

Administration best practices for on-premises deployments of Microsoft Dynamics CRM
Control data access
Create or edit a security role
Copy a security role
Manage users
Manage teams
Add teams or users to a field security profile
Scalable Security Modeling with Microsoft Dynamics CRM 2011
Manage security, users and teams
Invite someone to use Microsoft Dynamics CRM

© 2016 Microsoft Corporation. All rights reserved. Copyright