Cómo se puede usar la seguridad de campos para controlar el acceso a los valores de campo en Microsoft Dynamics 365
Publicado: enero de 2017
Se aplica a: Dynamics 365 (online), Dynamics 365 (on-premises), Dynamics CRM 2016, Dynamics CRM Online
En Microsoft Dynamics 365 y Microsoft Dynamics 365 (online), se usa la seguridad de nivel de campo para restringir el acceso a los campos de alto impacto de negocio a usuarios y equipos específicos. Por ejemplo, use esta opción para permitir únicamente a ciertos usuarios leer o actualizar la cuenta de crédito para un cliente. Para esta versión, la seguridad de nivel campo se puede aplicar a los campos personalizados y a muchos campos predefinidos (OOB).
Los pasos siguientes describen cómo restringir el acceso a un campo:
Habilitar la seguridad de nivel de campo para un atributo
Crear un perfil de seguridad de nivel de campo
Asociar usuarios o equipos al perfil
Agregar al perfil permisos de campo específicos, como Crear, Actualizar o Leer para un atributo específico
En el siguiente diagrama se muestra la interacción entre la seguridad basada en roles, la seguridad basada en registros y la seguridad a nivel de campo.
.jpeg "Comparación de seguridad basado en roles con seguridad de nivel de campo")
La seguridad basada en roles le permite ver un tipo de entidad específica, la seguridad basada en registros le permite ver registros individuales y la seguridad de nivel de campo le permite ver campos específicos.
Vídeo: Seguridad a nivel de campo en Microsoft Dynamics CRM 2015
Preguntas más frecuentes
¿Qué atributos se pueden proteger?
¿Qué roles de seguridad le permiten ver campos seguros?
¿Cómo se comportan los campos protegidos Retrieve y RetrieveMultiple?
¿Cómo se comportan los campos protegidos para crear o actualizar?
¿Cómo se comportan los campos protegidos cuando se comparten registros?
¿Cómo se comportan los campos protegidos de las vistas filtradas?
¿Cómo se comportan los campos protegidos para la sincronización sin conexión?
¿Qué atributos se pueden proteger?
Para ver qué atributos se puede proteger, puede consultar los metadatos de la entidad para las siguientes propiedades:
Existen miles de atributos que pueden protegerse, por lo que hay dos formas más fáciles de búsqueda de esta información.Para ver los metadatos de la entidad de su organización, instale la solución Explorador de metadatos que se describe en Examinar los metadatos de la organización. También puede ver los metadatos de una organización no personalizada en una hoja de cálculo de Excel denominada EntityMetadata.xlsx que se incluye en la carpeta de nivel superior de la descarga del SDK.
Hay algunas reglas adicionales que se aplican a determinados tipos de datos de atributo:
Los atributos booleanos se pueden proteger para crear y actualizar operaciones, pero no para leer.
Los atributos de conjunto de opciones se pueden proteger para crear, actualizar y leer cuando no se especifica un valor predeterminado.
¿Qué roles de seguridad le permiten ver campos seguros?
El perfil de seguridad del campo Administrador del sistema proporciona acceso completo a todos los campos protegidos en Microsoft Dynamics 365. De forma predeterminada, todos los usuarios con el rol de seguridad Administrador del sistema tienen este perfil. Este perfil es administrado por el sistema y no se puede actualizar ni eliminar.
¿Cómo se comportan los campos protegidos Retrieve y RetrieveMultiple?
Cuando se llama a los métodos o mensajes Retrieve o Microsoft Dynamics 365, RetrieveMultiple evalúa si el si el autor de la llamada y el usuario suplantado tienen acceso a cada registro recuperado (este es el proceso normal de seguridad) y a cada campo protegido. La llamada no genera una excepción si los criterios contienen campos protegidos a los que el autor de la llamada no tiene acceso. En su lugar, se devuelven valores nulos para los campos protegidos si estos forman parte del conjunto de columnas de salida.
A continuación, se describen con más detalle los distintos comportamientos de los campos protegidos.
Cuando un atributo protegido está en el conjunto de columnas
Si el autor de la llamada (o el usuario suplantado) no tiene acceso de lectura a los campos protegidos incluidos en un conjunto de columnas, se devuelve un valor como null. No se puede indicar la diferencia entre un valor null devuelto a causa de que no había datos o debido a un acceso insuficiente.
Cuando un atributo protegido está en la condición del filtro
Si el autor de la llamada (o el usuario suplantado) no tiene acceso a los campos protegidos incluidos en los criterios de filtro, el valor del campo se sustituye por null durante la evaluación del filtro.
En la siguiente tabla, el autor de la llamada tiene acceso a todos los atributos excepto los indicados con un asterisco (*).
Número de registro |
Valor del atributo Nombre |
Valor del atributo Descripción |
Valor del atributo Puede ser contactado |
|---|---|---|---|
1 |
E |
AAA |
Verdadero |
2 |
B |
BBB |
Falso |
3 |
C |
CCC |
VERDADERO* |
4 |
E |
DDD |
Null |
5* |
E* |
EEE* |
Null* |
Cuando el filtro es CanbeContacted == True, solo se devuelve el registro uno.
Cuando el filtro es IsNULL (CanbeContacted), se devuelven los registros 3 y 4. Puesto que el registro 3 está oculto del usuario, se trata como null durante la evaluación de la condición y se evaluará como True en ISNull.
Al agregar atributos protegidos
Los valores protegidos se sustituyen por un valor nulo, de manera que se aplica el comportamiento normal de agregación de SQL.
Al agrupar atributos protegidos
Si el autor de la llamada (o el usuario suplantado) no tiene acceso al atributo usado para agrupar, se trata el valor como null y los resultados se agrupan junto con todos los valores null.
En el ejemplo siguiente, el autor de la llamada tiene acceso a algunos atributos.Negrita indica que no hay acceso a los atributos, también indicado con *.Cursiva indica un registro para el cual el autor de la llamada no tiene acceso de lectura, también indicado con **.
Nombre |
Descripción |
Número de pedidos |
Est. |
|---|---|---|---|
E |
AAA |
1 |
WA |
B |
BBB |
4 |
WA |
C |
CCC |
4 |
CA |
E** |
DDD** |
3** |
MA** |
E |
EEE |
0 |
Cantabria |
F |
FFF |
0 |
WA* |
G |
GGG |
2 |
Cantabria* |
Select State, Total(orders) Group by (STATE) da el resultado siguiente:
WA–5
CA–4
null–2
Al ordenar atributos protegidos
Si el autor de la llamada (o el usuario suplantado) no tiene acceso a los campos protegidos incluidos en una condición de tipo Ordenar por, los valores se tratarán como si fuesen null.
En el ejemplo siguiente, el autor de la llamada tiene acceso a los atributos en texto sin formato.Negrita indica que no hay acceso a los atributos, también indicado con un asterisco *.Cursiva indica un registro para el cual el autor de la llamada no tiene acceso de lectura, también indicado con **.
Nombre |
Descripción |
CanbeContacted |
|---|---|---|
E |
AAA |
Verdadero |
B |
BBB |
Falso |
C |
CCC* |
VERDADERO* |
E |
DDD |
Null |
E |
EEE* |
Null* |
F** |
FFF** |
VERDADERO** |
G |
Null |
Verdadero |
Select Name order by Description ascending da el resultado siguiente:
{G,E,C},A, B, D, se devolverán.
¿Cómo se comportan los campos protegidos para crear o actualizar?
Un programador puede compilar un cliente que use Create y los métodos de Update que interactúan con los campos protegidos. Cuando se llama al método Create o Update, pasando los datos de los campos protegidos, y el autor de la llamada no tiene permisos suficientes, se genera una excepción.
¿Cómo se comportan los campos protegidos cuando se comparten registros?
Un usuario con acceso a un campo protegido en un registro puede compartirlo con otro usuario o equipo. El usuario solo puede otorgar el acceso que tiene sobre el registro. Por ejemplo, para compartir el registro y conceder privilegios de actualización, el usuario debe tener privilegios de actualización.
Puede compartir un campo protegido en un registro determinado derechos de Lectura y/o Actualización con una entidad de seguridad (usuario o equipo). El usuario o los miembros del equipo con los que se haya compartido el registro tienen ahora ese tipo de acceso a campo protegido solo a los campos protegidos compartidos de solo dicho registro concreto, incluso si el usuario o miembro del equipo con el que se ha compartido no tiene un perfil de seguridad de campo que les dé acceso.
¿Cómo se comportan los campos protegidos de las vistas filtradas?
Un administrador protege varios campos para el acceso desde la aplicación y no quiere que los campos estén disponibles en los informes. Esto permite mantener el mismo conjunto de informes para todos los usuarios. Las vistas filtradas no devolverán los datos de los campos protegidos si el usuario autor de la llamada no tiene autorización para los campos. Si no se aplica ninguna seguridad de campo a los atributos de la vista, las vistas filtradas devolverán datos completos.
¿Cómo se comportan los campos protegidos para la sincronización sin conexión?
Si usa Microsoft Dynamics 365 para Microsoft Office Outlook con acceso sin conexión, solo los valores de campos protegidos a los que tenga acceso se replicarán en la base de datos sin conexión. Si no dispone de acceso a los datos, no se guardarán sin conexión.
Ver también
Vídeo: Seguridad a nivel de campo en Microsoft Dynamics CRM 2015
El modelo de seguridad de Microsoft Dynamics 365
Cómo se puede usar la seguridad basada en roles para controlar el acceso a las entidades de Microsoft Dynamics 365
Cómo se puede usar la seguridad basada en registros para controlar el acceso a registros de Microsoft Dynamics 365
Microsoft Dynamics 365
© 2017 Microsoft. Todos los derechos reservados. Copyright