Szerkesztés

Megosztás a következőn keresztül:

Field security tables

  • Cikk

You use field security tables to apply field-level security, which restricts field access to specified users and teams. The scope of field-level security is global, which means that it applies to all records within the organization, regardless of the business unit hierarchical level to which the record or the user belongs. Field security works in all Microsoft Dataverse clients, including the Web client, Dynamics 365 for Outlook, and Dynamics. It applies to all components, such as the Dataverse web services, reports, search, offline, filtered views, auditing, and duplicate detection. For this release, field security can be applied to both custom fields and many out-of-box (OOB) fields.

Important

Field-level security profiles prevent unintended users from getting access to Dataverse data based on the profile definitions. If the SQL Server ACLs are misconfigured, or if there is a SQL injection issue, adversaries can get direct access to data in SQL Server thereby bypassing field level security restrictions. For more information, see Overview of Web Application Security Threats.

Set up and use field security

To use field security you must do the following:

  1. Create a field security profile record.

  2. Add users or teams to the profile.

  3. Find a columns that can be secured at the field level.

  4. Secure the column, either when you create the column or by updating the column definition.

  5. Publish the customizations.

  6. Create a field permission record that defines what access (create, update, read) the profile will have for the custom column.

    For sample code about how to perform these steps, see Sample: Enable Field Security For An Entity.

    Use the following field permission columns to set whether the specified field security profile can create, read, or update a column. You can set or compare the value for these columns by using the field_security_permission_type global choice:

  • FieldPermission.CanCreate

  • FieldPermission.CanRead

  • FieldPermission.CanUpdate

Important

If low privilege users are given Read access to the field security profile entity, they can see what profiles other users have and find other users with access to secured attributes they are interested in. They can then use social engineering techniques to get assigned a profile with access to those secured attributes.

Which attributes can be secured?

To see which columns can be secured, you can query the table definition for the following properties:

  • CanBeSecuredForCreate

  • CanBeSecuredForRead

  • CanBeSecuredForUpdate

    There are a few additional rules that apply to certain attribute data types:

  • Boolean attributes can be secured for create and update operations but not for read.

  • Option set attributes can be secured for create, update, and read when a default value is unspecified.

    There are thousands of columns that can be secured, so there are two easier ways to look for this information. To view the table definition for your organization, install the Table definition browser solution described in Browse table definition in your environment. You can also browse the reference documentation for entities in the Table/entity reference.

Share secured fields

You can share secured fields much as you can share records. To do this, you create, update, or delete a PrincipalObjectAttributeAccess (field sharing) record, where you specify the user or team, the entity, and the permissions.

The following table lists the corresponding methods for securing a field compared to securing a record.

Record sharing Field access sharing
Use the GrantAccessRequest message to grant record access for a user or team. Use the CreateRequest message or the IOrganizationService.Create method to grant secured field access for a user or team.
Use the ModifyAccessRequest message to update record access for a user or team. Use the UpdateRequest message or the IOrganizationService.Update method to update secured field access for a user or team.
Use the RevokeAccessRequest message to remove record access for a user or team. Use the DeleteRequest message or the IOrganizationService.Delete method to remove secured field access for a user or team.

See also

Security and data access
FieldSecurityProfile Entity
FieldPermission Entity
PrincipalObjectAttributeAccess Entity