Protección de Interface de Usuario

La funcionalidad que se describe en esta sección se utiliza para tomar los datos almacenados como texto sin formato en la base de datos y proteger el valor antes de presentarlo al usuario (o un sistema externo). Esta característica incluye la capacidad de permitir que algunos usuarios visualicen los datos sin proteger mediante la configuración de seguridad. El sistema permite que se apliquen diferentes reglas de protección a diferentes campos. Por ejemplo, un número de tarjeta de crédito puede tener una protección diferente que un número de seguro social.

Los siguientes temas describen cómo proteger valores de campo.

Identificación de los Datos que se Deben Proteger

Identifique los datos almacenados como texto sin formato que deben protegerse y no desplegarse a los usuarios. Por ejemplo, imagínese que identificó Números de Tarjeta de Crédito y el número de ID federal de una persona (en los Estados Unidos, el Número de Seguro Social o SSN). Cada campo identificado puede desplegarse y mantenerse en diferentes interfaces de usuario del sistema, pero las reglas de protección para un campo determinado son probablemente uniformes independientemente de dónde se desplieguen los datos.

Las claves primarias no se pueden proteger. Un campo que está definido como un identificador único de una fila no se puede configurar para protección. La protección de un campo que es una parte de la clave primaria ocasiona un problema cuando se intenta actualizar el registro. Esta restricción se aplica también a elementos que son parte de una "lista" en una columna XML de un objeto de mantenimiento. Uno o más elementos de la lista deben estar definidos como identificador primario de la lista. Asegúrese de que los elementos de clave primaria de la lista no sean aquéllos que requieren protección.

Miembros de lista que contienen diferentes "tipos". Considere una página con una lista que contiene los números de identificación de una persona. Puede configurar el sistema de modo que el número de seguro social de una persona tenga reglas de protección distintas a las del número de licencia de conducir. Si la implementación tiene este tipo de requerimiento, la lista de campos protegidos debe contener un ingreso para cada regla de protección.

Para cada campo, si existen usuarios que pueden ver los datos sin proteger en una o varias de las interfaces de usuario, se requiere una configuración de seguridad. Si el valor de un campo debe protegerse para todos los usuarios en todas las páginas de la aplicación, no es necesaria la configuración de seguridad.

Configuración de Seguridad

Defina un tipo de seguridad para cada campo con dos niveles de autorización:

1: Sólo se puede ver el elemento protegido
2: Sólo se puede ver el elemento desprotegido

Enlace todos los tipos de seguridad a un servicio de aplicación de su elección. Recomendamos enlazar cada tipo de seguridad orientado a protección a un servicio de aplicación único (p. ej., CM_MASK) puesto que esto facilita el otorgamiento de acceso.

Para cada tipo de seguridad, identifique los usuarios que pueden ver sus datos sin protección y aquéllos que sólo pueden verlos protegidos. Si los usuarios protegidos y sin protección corresponden a grupos de usuarios existentes, no son necesarios grupos de usuarios adicionales. Si no es así, cree nuevos grupos de usuarios para los usuarios protegidos y sin protección.

Después de que se definen los grupos de usuarios para cada tipo de seguridad, enlace cada grupo de usuarios al servicio de aplicación definido anteriormente. Cuando un grupo de usuarios esté enlazado al servicio de aplicación, defina el nivel de autorización para cada tipo de seguridad enlazado al servicio de aplicación. Si los usuarios de un grupo de usuarios deben ver sin protección los valores de campo del tipo de seguridad, defina el nivel de autorización en 2; en caso contrario, defínalo en 1.

Nota: Vaciar el caché. Recuerde que cada vez que cambia los derechos de acceso, debe eliminar el caché de seguridad (ingresando flushAll.jsp en el URL de la aplicación) si desea que el cambio sea efectivo inmediatamente.

Configuración de un Algoritmo de Protección

Se debe crear un algoritmo de protección de datos sensibles (utilizando el valor de entidad de algoritmo Configuración de Funciones: Protección Datos Sensibles) para cada combinación de reglas de protección y tipo de seguridad. Estos algoritmos determinan si un usuario tiene los derechos para visualizar un campo determinado desprotegido y, si no los tiene, la forma en que se debe proteger el campo.

El paquete base proporciona el tipo de algoritmo F1-MASK cuyos parámetros están diseñados para manejar la mayoría de las necesidades de protección. Si determinados usuarios pueden ver los datos sin proteger, los parámetros capturan el servicio de aplicación, el tipo de seguridad y el nivel de autorización definidos anteriormente y utilizados para evaluar esto. Además, los parámetros permiten configurar qué parte de los datos proteger y qué carácter de protección utilizar. Consulte la descripción de tipo de algoritmo para obtener más información.

Determinación de Cómo se Despliegan los Campos

La configuración de protección difiere según cómo se recupera un campo para el acceso a la interface de usuario. Por lo tanto, para proteger un campo "lógico" (como el SSN de una persona), es posible que se requieran múltiples registros de configuración para abarcar todos los métodos de acceso. Revise cada interface de usuario donde se despliega un campo determinado y cree las siguientes categorías:

El campo es un elemento que se recupera invocando un objeto de negocio, un servicio de negocio o un script de servicio.
El campo se despliega en una página de mantenimiento fija (y, por lo tanto, se recupera invocando un servicio de página).
El campo se despliega en una página de búsqueda fija (y, por lo tanto, se recupera invocando un servicio de búsqueda).
El campo se almacena como una característica ad hoc.

Creación de una Configuración de Característica para Cada Elemento Protegido

Cree una configuración de característica con un Tipo de Característica de Protección de Datos Confidenciales. Se necesita una entrada de opción con el tipo de opción Protección de Campo para cada combinación de campo para proteger y el método utilizado para desplegar los datos. El valor contendrá mnemotécnicos que hacen referencia al algoritmo de protección de datos sensibles adecuado junto con una configuración que difiere según la manera en que se recupera el campo para despliegue, como se describe a continuación.

Protección de Campo de Objeto Basado en Esquema

Para los datos a los que se accede mediante una llamada de objeto basada en esquema y que se despliegan en un mapa de Interface de Usuario, (UI), el campo que se protegerá debe hacer referencia a un nombre de campo de metadatos en su definición de esquema: field="fld_name", alg="algorithm name"

Si el elemento hace referencia a un mdField en el esquema, ese es el campo que se usa para identificar la regla de protección. Si no hay ninguna referencia de mdField pero únicamente una referencia a mapField, ese es el campo que se usa para identificar la regla de protección. Por ejemplo, si desea proteger un número de tarjeta de crédito, supongamos que el campo que se define en el esquema es el siguiente:

<creditCard mdField="CCNBR" mapField="EXT_ACCT_ID"/>

En este caso, el valor de opción debe ser field="CCNBR", alg="algorithm name". El valor de opción field="EXT_ACCT_ID", alg="algorithm name" no resultará en protección.

También se puede especificar una cláusula "where". Ésta es útil para los datos que residen en una lista donde sólo es necesario proteger los datos de un determinado tipo: field="fld_name", alg="algorithm name", where="fld_name='value'"

Por ejemplo, la persona puede tener una recolección de IDs y únicamente se pueden proteger los IDs del tipo "SSN" (número de seguro social). Si los datos de la persona, incluida su recolección de IDs se despliega en un mapa de Interface de Usuario (UI) mediante una llamada de objeto de negocio, supongamos que la recolección está definida en una de las siguientes maneras:

<personIDs type="list" mapChild=CI_PER_ID">
  <isPrimaryId mapField="PRIM_SW"/>
  <idType mapField="ID_TYPE_CD"/>
  <personIdNumber mapField="PER_ID_NBR"/>
</personIds>

Es posible que el valor de opción sea: field="PER_ID_NBR", alg="algorithm name", where="ID_TYPE_CD='SSN'"

Observe que los siguientes puntos importantes para la protección basada en esquemas:

Limitación del campo "where" Aunque el uso principal de una cláusula "where" para elementos orientados a esquema es la protección de determinados elementos en una lista basada en un "tipo", también es posible proteger un campo único del esquema sobre la base del valor de otro campo. Por ejemplo, supongamos que un cliente ejecuta un formulario de registro que define un tipo de ID y un valor de ID. Aunque los datos no están en una lista, es posible que la implementación aún desee proteger únicamente el valor de ID si el tipo de ID es "SSN". El marco únicamente puede proteger un elemento del esquema sobre la base de una cláusula "where" si el elemento de la cláusula "where" es "secundaria" en el esquema.
- Si el elemento que se protegerá está en una lista, el elemento de la cláusula "where" deberá estar en la misma lista.
- Si un elemento que se protegerá está mapeado a una columna real de una tabla, el elemento de la cláusula "where" también deberá estar mapeado a una columna real de la tabla.
- Si un elemento que se protegerá está mapeado a una columna XML en la tabla como un elemento único, el elemento de la cláusula "where" deberá estar mapeado a la misma columna XML como un elemento único.
Múltiples entradas de opción de características para el mismo campo. Es posible que diferentes esquemas del sistema tenga un tipo similar de datos que se pueden proteger según diferentes condiciones. Por ejemplo, supongamos que una implementación tiene diferentes esquemas que capturan o hacen referencia a identificadores de personas de diferentes maneras:
- Un esquema captura un ID de una única persona sin el registro de "tipo" correspondiente y siempre se debe proteger mediante el Algoritmo CM_SSN_MASK:
```
<personSSN mapXML=BO_DATA_AREA mdField=PER_ID_NBR/>
```
- Un esquema captura un ID de persona el Tipo de ID correspondiente, y siempre se debe proteger con el algoritmo CM_SSN_MASK si el tipo es "SSN" y se debe proteger con el algoritmo CM_FEIN_MASK si el tipo es "FEIN".
```
<personIdType mapXML=BO_DATA_AREA mdField=ID_TYPE_CD/>
<personId mapXML=BO_DATA_AREA mdField=PER_ID_NBR/>
```
- Un esquema captura un ID de persona y el Tipo de ID correspondiente, y tiene las mismas reglas de protección que el esquema anterior, pero se usa un nombre de campo diferente para el código Tipo de ID. (Este escenario ocurriría, por ejemplo, si se desea una etiqueta diferente para Tipo de ID en la interface de usuario para este esquema).
```
<personIdType mapXML=BO_DATA_AREA mdField=CM_ID_TYPE/>
<personId mapXML=BO_DATA_AREA mdField=PER_ID_NBR/>
```
Para este escenario, las opciones de características pueden ser similares a:
1. field="PER_ID_NBR", alg="CM_SSN_MASK"
2. field="PER_ID_NBR", alg="CM_SSN_MASK", where="ID_TYPE_CD='SSN'"
3. field="PER_ID_NBR", alg="CM_FEIN_MASK", where="ID_TYPE_CD='FEIN'"
4. field="PER_ID_NBR", alg="CM_SSN_MASK", where="CM_ID_TYPE='SSN'"
5. field="PER_ID_NBR", alg="CM_FEIN_MASK", where="CM_ID_TYPE='FEIN'"
Para cada esquema, el sistema primero buscará si el elemento se aplica a una opción de protección. Encontrará 5 opciones de protección para el campo PER_ID_NBR. A continuación, determinará si alguno de los elementos secundarios coinciden con la cláusula "where".
- Si más de un elemento secundario coincide con una cláusula "where", se mostrará un error de tiempo de ejecución. Por ejemplo, si un esquema tiene un elemento que hace referencia a "mdField=ID_TYPE_CD" y un elemento que hace referencia a "mdField=CM_ID_TYPE", esto es un error. Además, si varios elementos hacen referencia a mdField=ID_TYPE_CD", esto es un error.
- Si un único elemento secundario coincide con una cláusula "where", el valor del elemento se compara con los valores definidos en la cláusula "where". Si encuentra una coincidencia con el valor, se aplica el algoritmo de protección adecuado. Si no se encuentra una coincidencia (por ejemplo, el Tipo de ID de Persona es "LICENSE") el elemento se muestra tal como está.
- Si no hay un elemento secundario que coincida con la cláusula "where" y si existe una opción de característica sin cláusula "where" (opción 1 de arriba), se aplicará el algoritmo de protección de la opción sin cláusula "where".
Cambio del valor en la cláusula "where". Si la implementación tiene algunos usuarios con permiso para cambiar registros donde algunos datos están protegidos según una condición, se recomienda diseñar la interface de usuario para restablecer el valor protegido cuando el valor de la cláusula "where" cambia. Por ejemplo, si un usuario no puede ver el número de seguro social de una persona, pero el usuario puede realizar actualizaciones del registro de la persona, si se cambia el valor de Tipo de ID de Persona se restablecerá el Número de ID de Persona. Esto garantiza que el usuario no "quitará la protección" del número de seguridad social si cambia el Tipo de ID.

Registros Mantenidos Mediante Mantenimiento de Página

Para los datos a los que accede mediante una llamada de solicitud servicio de mantenimiento de página, indique el nombre de la tabla y el nombre del campo donde residen los datos: table="table_name", field="fld_name", alg="algorithm name"

Por ejemplo, si el registro de la persona y su recolección de identificadores se despliegan y se mantienen mediante el mantenimiento de página, el valor de opción debe ser table="CI_PER_ID", field="PER_ID_NBR", alg="algorithm name"

También se puede especificar una cláusula "where": table="table_name", field="fld_name", where="fld_name='value'", alg="algorithm name"

Ésta es útil para los datos que residen en una tabla secundaria donde sólo es necesario proteger los datos de un determinado tipo. Para el ejemplo de ID de persona, table="CI_PER_ID", field="PER_ID_NBR", alg="algorithm name", where="ID_TYPE_CD='SSN'"

Datos de Característica

Para los datos que se almacenan como una característica, simplemente indique el tipo de característica: CHAR_TYPE_CD='char type', alg="algorithm name"

Esto sólo debe definirse una vez, independientemente de en qué entidad de característica pueda residir el tipo de característica. Observe que sólo se soportan las características ad-hoc.

Protección de Campos en Zonas de Explorador o Cadenas de Información

Los datos de las zonas del explorador generalmente se recuperan mediante SQL directamente desde la base de datos. En este caso, no se aplicar la protección automáticamente. Si hay datos en los resultados de la zona del explorador que se debe proteger, la protección se deberá aplicar mediante la llamada al servicio de negocios.

De manera similar, es posible que el algoritmo Información de Objeto de Mantenimiento no use la interacción de Objeto de Negocio para obtener los datos. Puede acceder a los datos mediante SQL para una mayor eficiencia. No se aplica protección cuando se recuperan datos mediante SQL. Para aplicar protección a una cadena antes de incluirla en una cadena de información, se debe aplicar la protección mediante el llamado del servicio de negocios.

El sistema suministra la llamada de dos servicios de negocios para determinar si las reglas de protección se aplican a un campo específico.

F1-TableFieldMask. Proteger un campo de Tabla. Este servicio de negocios recibe un nombre de tabla, el nombre de campo y uno o más valores de campo. Si se aplica la protección, devuelve el valor protegido.
F1-SchemaFieldMask. Proteger un campo de Esquema. Este servicio de negocios recibe un nombre y un tipo de esquema, el valor de campo y XPath. Si se aplica la protección, devuelve el valor protegido.

Resultados del Servicio de Búsqueda

Para los datos que se despliegan en una página de búsqueda "fija", la recuperación se realiza mediante una llamada de solicitud de servicio de búsqueda. Indique el nombre de la búsqueda y el campo apropiado que se protegerá junto con el algoritmo de protección. Por ejemplo: search="SearchServiceName", field="PER_ID_NBR", where="ID_TYPE_CD='SSN'", alg="algorithm name"

Para encontrar el nombre del servicio de búsqueda, inicie la búsqueda en cuestión, haga click con el botón derecho del mouse en el área de filtro y seleccione Inspeccionar. Busque "serviceName". El nombre del servicio se lista ahí. Para encontrar el nombre del campo que se debe proteger, busque "Información de Widget". Deberían encontrarse dos resultados, uno para el área de filtro y otro para el área de resultados. Esta área de resultados tiene el texto "SEARCH_RESULTS" como prefijo para cada campo. Los nombres de los campos aparecen después de x$. No haga referencia a x$ al definir el nombre del campo. Observe que la sentencia "where" sólo se puede aplicar a los campos que además son parte de los resultados de la búsqueda.

Información Adicional de Protección

Los puntos siguientes proporcionan información adicional como ayuda para la configuración de protección:

Si la base de datos de demostración incluye una configuración de característica de Protección de Datos, revise la configuración porque es probable que contenga reglas de protección que coincidan con las suyas.
En páginas de entrada de datos, un usuario puede ser capaz de ingresar o cambiar datos protegidos, tales como un número de cuenta bancaria, pero no podrá ver posteriormente lo que agregó o cambió.
Los sistemas externos pueden solicitar información realizando una llamada de solicitud de servicio mediante un servicio web. Tenga en cuenta que algunas solicitudes de servicio web requieren datos protegidos, mientras que otras no los requieren. Por ejemplo, una solicitud de un sistema externo para sincronizar información de persona necesita que el número de seguro social de la persona no esté protegido; mientras que una solicitud de una aplicación de autoservicio por red para recuperar la misma información de persona para despliegue necesita que el número de seguro social de la persona esté protegido. Para implementar este tipo de requerimiento, distintos usuarios deben estar asociados con cada una de las solicitudes y estos usuarios deben pertenecer a grupos de usuarios por separado con distintos derechos de acceso.
Si un objeto de mantenimiento contiene un campo que incluye un documento XML y una llamada de solicitud de servicio invoca directamente al programa de servicio del Objeto de Mantenimiento, el sistema protege elementos XML individuales en el campo si un algoritmo Determinar Objeto de Negocio se ha conectado al objeto de mantenimiento y los elementos del esquema de Objeto de Negocio respectivo se han asegurado como se describió anteriormente.