Máscara da Interface de Usuário

Identificar os Dados que Terão Máscara

Identifique os dados que estão armazenados como texto simples, mas que devem ser mascarados para exibição para os usuários. Por exemplo, imagine que identificou os Números do Cartão de Crédito e o número de ID federal de uma pessoa (por exemplo, nos Estados Unidos, o Número da Previdência Social ou SSN). Cada campo identificado pode ser exibido e atualizado em diferentes interfaces do usuário em todo o sistema, mas as regras de máscara para um determinado campo provavelmente são uniformes, independentemente de onde os dados são exibidos.

Chaves primárias não podem ter máscaras. Um campo definido como identificador exclusivo de uma linha não pode ser configurado para máscara. Aplicar máscara em um campo que faz parte da chave primária causa um problema quando se tenta atualizar o registro. Esta restrição também se aplica aos elementos que fazem parte de uma "lista" em uma coluna XML de um objeto de manutenção. Um ou mais elementos da lista devem ser definidos como identificador primário da lista. Certifique-se de que os elementos da chave primária da lista não sejam aqueles que exigem máscara.

Listar membros que contêm "tipos" diferentes. Imagine uma página com uma lista que contém números de identificação de uma pessoa. É possível configurar o sistema de modo que o número da previdência social de uma pessoa tenha regras de máscara diferentes das do número da carteira de habilitação. Se sua implementação tiver esse tipo de requisito, a lista de campos com máscara deverá conter uma entrada para cada regra de máscara.

Para cada campo, se houver alguns usuários que podem ver os dados não mascarados em uma ou mais interfaces do usuário, então a configuração de segurança é obrigatória. Se o valor de um campo tiver que ser mascarado para todos os usuários em todas as páginas do aplicativo, a configuração de segurança não será necessária.

Configuração de Segurança

Defina um tipo de segurança para cada campo com dois níveis de autorização:

• 1 - Só pode ver o elemento com máscara

• 2 - Só pode ver o elemento sem máscara

Vincule todos os tipos de segurança a um serviço de aplicativo de sua escolha. Recomendamos vincular cada tipo de segurança orientado a mascaramento a um único serviço de aplicativo (por exemplo, CM_MASK), pois isso facilita a concessão de acesso.

Para cada tipo de segurança, identifique quais usuários podem visualizar seus dados sem máscara e quais usuários podem visualizar somente os dados com máscara. Se os usuários com máscara e sem máscara se encaixarem em grupos de usuários existentes, nenhum grupo de usuários adicional será necessário. Caso contrário, crie novos grupos de usuários para os usuários com máscara e sem máscara.

Depois que forem definidos os grupos de usuários para cada tipo de segurança, vincule cada grupo de usuários ao serviço de aplicativo definido acima. Quando um grupo de usuários for vinculado ao serviço de aplicativo, você definirá o nível de autorização para cada tipo de segurança vinculado ao serviço de aplicativo. Se usuários de um grupo tiverem que visualizar os valores do campo do tipo de segurança sem máscara, defina o nível de autorização como 2, caso contrário, defina como 1.

Configurar um Algoritmo de Máscara

É preciso criar um algoritmo de máscara de dados (usando o valor de entidade do algoritmo Configuração do Recurso - Máscara de Dados) para cada combinação de regras de mascaramento e tipo de segurança. Esses algoritmos determinam se um usuário tem direitos de exibir um determinado campo sem máscara e, se não tiver, como o campo deve receber a máscara.

O pacote base fornece dois tipos de algoritmo. Ambos podem ser configurados para permitir que um conjunto de usuários veja os dados sem máscara. Os parâmetros capturam o serviço de aplicativo, o tipo de segurança e o nível de autorização definidos acima usados para avaliar isso.

• F1-MASK: usado para mascarar dados alfanuméricos. Seus parâmetros são designados para controlar a maioria das necessidades de máscara. Os parâmetros permitem configurar o volume de dados a serem mascarados e qual caractere de máscara utilizar. Consulte a descrição do tipo de algoritmo para obter mais informações.
• F1-MASKNBR: para números de máscara. Consulte a descrição do tipo de algoritmo para obter mais informações.

Determinar Como os Campos são Exibidos

A configuração da máscara difere com base em como um campo é recuperado para acesso à interface do usuário. Para a máscara de um campo "lógico" (como SSN da pessoa), pode haver várias entradas de configuração necessárias para cobrir todos os métodos de acesso. Revise cada interface do usuário onde determinado campo é exibido e crie as seguintes categorias:

• O campo é um elemento que é recuperado ao chamar um objeto de negócios, um serviço de negócios ou um script de serviço

• O campo é armazenado como uma característica ad hoc

• O campo é exibido em uma página de manutenção fixa (e, portanto, é recuperado ao chamar um serviço da página)

• O campo é exibido em uma página de pesquisa fixa (e, portanto, é recuperado ao chamar um serviço de pesquisa)

Criar uma Configuração do Recurso para Cada Elemento Mascarado

Crie uma configuração de recurso com um Tipo de Recurso de Máscara de Dados. Uma entrada de opção com o tipo de opção de Máscara de Campo é necessária para cada combinação de campo a ser mascarado e o método usado para exibir os dados. O valor conterá mnemônicos que referenciam o algoritmo de máscara de dados apropriado junto com a configuração que difere, dependendo de como o campo é recuperado para exibição, conforme descrito abaixo.

Máscara de Campo do Objeto com Base no Esquema

Para dados que são acessados por meio de uma chamada de objeto com base no esquema e exibido em um mapa de Interface do Usuário, o campo a ser mascarado deve fazer referência a um nome de campo de metadados em sua definição de esquema: field="fld_​name", alg="algorithm name"

Se o elemento fizer referência a um mdField no esquema, esse é o campo usado para identificar a regra da máscara. Se não houver referência de mdField, mas apenas uma referência de mapField, este será o campo usado para identificar a regra de máscara. Por exemplo, se quiser mascarar um número de cartão de crédito, vamos presumir que o campo que é definido no esquema é o seguinte:

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

Neste caso, o valor da opção deve ser field="CCNBR", alg="algorithm name". Um valor da opção de field="EXT_​ACCT_​ID", alg="algorithm name" não resulta em máscara.

Uma cláusula "where" também pode ser especificada. Isso é útil para os dados que residem em uma lista na qual somente os dados de um determinado tipo precisam ser mascarados: field="fld_​name", alg="algorithm name", where="fld_​name='value'"

Por exemplo, a pessoa pode ter um conjunto de IDs, e somente IDs do tipo 'SSN' (número de previdência social) devem ser mascarados. Se os dados da pessoa, que incluem seu conjunto de IDs de pessoa, forem exibidos em um mapa de Interface do Usuário por meio de uma chamada de objeto de negócios, suponha que o conjunto será definido da seguinte forma:

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

O valor da opção parece com esse: field="PER_​ID_​NBR", alg="algorithm name", where="ID_​TYPE_​CD='SSN'"

Observe os seguintes pontos importantes da máscara com base no esquema:

• Limitação do campo 'where' Embora o uso principal de uma cláusula 'where' dos elementos orientados do esquema deve mascarar determinados elementos em uma lista com base em um 'type', também é possível mascarar um campo único no esquema com base no valor de outro campo. Por exemplo, imagine que um cliente envia um formulário de registro que define um tipo e valor de ID. Embora estes dados não estejam em uma lista, a implementação talvez ainda queira mascarar somente o valor do ID se o tipo de ID for "SSN". A estrutura somente pode mascarar um elemento no esquema com base em uma cláusula "where", se o elemento nessa cláusula for um "irmão" no esquema.

  • Se o elemento a ser mascarado estiver em uma lista, o elemento na cláusula 'where' deve estar na mesma lista.

  • Se um elemento a ser mascarado for mapeado para uma coluna real em uma tabela, o elemento na cláusula 'where' também deverá ser mapeado para uma coluna real na tabela.

  • Se um elemento a ser mascarado for mapeado para a coluna XML de uma tabela como um elemento único, o elemento na cláusula 'where' também deverá ser mapeado para a mesma coluna XML de um elemento único.

• Várias entradas de opção de recurso para o mesmo campo. É possível que diferentes esquemas no sistema tenham um tipo semelhante de dados que podem ser mascarados em diferentes condições. Por exemplo, imagine que uma implementação tenha diferentes esquemas que capturaram ou referenciaram identificadores da pessoa em formas diferentes:

  • Um esquema captura um único ID de pessoa sem nenhum registro "type" correspondente e deve ser sempre mascarado usando o Algoritmo CM_​SSN_​MASK:

    <personSSN mapXML=BO_DATA_AREA mdField=PER_ID_NBR/>

  • Um esquema captura um ID da pessoa e um Tipo de ID correspondente e deverá ser mascarado com o Algoritmo CM_​SSN_​MASK se o tipo for "SSN" e mascarado com o algoritmo CM_​FEIN_​MASK se o tipo for "FEIN".

    <personIdType mapXML=BO_DATA_AREA mdField=ID_TYPE_CD/>
    <personId mapXML=BO_DATA_AREA mdField=PER_ID_NBR/>

  • Um esquema captura um ID da pessoa e um Tipo de ID correspondente e tem as mesmas regras de máscara do esquema anterior, mas um nome de campo diferente é usado para o código do Tipo de ID. (Isso pode ocorrer se, por exemplo, um rótulo diferente for necessário para o Tipo de ID na interface do usuário deste esquema).

    <personIdType mapXML=BO_DATA_AREA mdField=CM_ID_TYPE/>
    <personId mapXML=BO_DATA_AREA mdField=PER_ID_NBR/>

  Para este cenário, as opções do recursos parecem com essa:

  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, o sistema primeiro detectará se o elemento aplica-se a qualquer opção de máscara. Ele encontrará 5 opções de máscara para o campo PER_​ID_​NBR. Em seguida, ele determinará se os elementos irmãos correspondem à cláusula 'where'.

  • Se mais de um elemento irmão corresponder a uma cláusula 'where', será gerado um erro de runtime. Por exemplo, se um esquema tiver um elemento que faz referência a "mdField=ID_​TYPE_​CD" e um elemento que faz referência a "mdField=CM_​ID_​TYPE", será um erro. Além disso, se vários elementos fizerem referência a mdField=ID_​TYPE_​CD", isso gerará um erro.

  • Se um e somente um elemento irmão corresponder a uma cláusula 'where', o valor do elemento será comparado aos valores definidos na cláusula "where". Se ele encontrar uma correspondência no valor, o algoritmo de máscara apropriado será aplicado. Se nenhuma correspondência for encontrada (por exemplo, o Tipo de ID da Pessoa for "LICENÇA") o elemento será exibido como está.

  • Se nenhum elemento irmão corresponder a uma cláusula 'where' e uma opção de recurso existir sem cláusula 'where' (opção 1 acima), então o algoritmo de máscara da opção sem cláusula 'where' será aplicado.

• Alterando o valor na cláusula 'where'. Se sua implementação tiver alguns usuários que não podem alterar os registros onde alguns dados foram mascarados com base em uma condição, recomendamos criar a interface do usuário para redefinir o valor mascarado, quando o valor na cláusula 'where' for alterado. Por exemplo, se um usuário for impedido de visualizar o número de previdência social de uma pessoa, mas puder fazer alterações no registro dela, alterar o valor do Tipo de ID da Pessoa deverá redefinir o Número de ID da Pessoa. Isso garantirá que o usuário não 'desmascara' o número de previdência social simplesmente alterando o Tipo de ID.

Registros Mantidos Usando a Manutenção da Página

Para os dados acessados por meio de uma chamada de serviço de manutenção de página, indique o nome da tabela e o nome do campo no qual residem os dados: table="table_​name", field="fld_​name", alg="algorithm name"

Por exemplo, se o registro Pessoa e sua coleta de identificadores forem exibidos e mantidos usando a manutenção da página, o valor da opção deverá ser table="CI_​PER_​ID", field="PER_​ID_​NBR", alg="algorithm name"

Uma cláusula "where" também pode ser especificada: table="table_​name", field="fld_​name", where="fld_​name='value'", alg="algorithm name"

Isso é útil para os dados que residem em uma tabela filho na qual somente os dados de um determinado tipo precisam ser mascarados. Para o exemplo de ID de pessoa, table="CI_​PER_​ID", field="PER_​ID_​NBR", alg="algorithm name", where="ID_​TYPE_​CD='SSN'"

Dados da Característica

Para dados que são armazenados como uma característica, basta indicar o tipo de característica: CHAR_​TYPE_​CD='char type', alg="algorithm name"

Isso precisa ser definido somente uma vez, independentemente da entidade da característica em que o tipo de característica reside. Observe que somente as características ad-hoc são suportadas.

Mascarando Campos nas Zonas do Explorador ou nas Strings de Informações

Nas zonas do explorador os dados geralmente são recuperados usando SQL diretamente do banco de dados. Nenhuma máscara aplicada automaticamente, neste caso. Se houver dados nos resultados da zona do explorador que devem ser mascarados, a máscara deve ser aplicada, chamando um serviço de negócios.

Da mesma forma, um algoritmo de Informações de Objeto de Manutenção não podem usar a interação do Objeto de Negócios para obter dados. Pode acessar os dados usando SQL para fins de eficiência. Nenhuma máscara aplicada ao recuperar dados por meio de SQL. Para aplicar mascaramento a uma string antes de incluí-la em uma string de informações, ele deverá ser aplicado chamando um serviço de negócios.

O sistema fornece dois serviços de negócios a serem chamados para determinar se as regras de mascaramento aplicam-se a um campo específico.

• F1-TableFieldMask. Mascarar um campo da Tabela. Este serviço de negócios recebe um nome de tabela, nome de campo e um ou mais valores de campo. Se a máscara for aplicada, ele retornará o valor da máscara.

• F1-SchemaFieldMask. Mascarar um campo de Esquema. Este serviço de negócios recebe um nome e tipo de esquema, XPath e valor de campo. Se a máscara for aplicada, ele retornará o valor da máscara.

Pesquisar Resultados de Serviço

Dados que são exibidos em uma página de pesquisa "fixa" são recuperados por meio de uma chamada de serviço de pesquisa. Indica o nome da pesquisa e o campo apropriado para mascarar junto com o algoritmo de máscara. Por exemplo: search="SearchServiceName", field="PER_​ID_​NBR", where="ID_​TYPE_​CD='SSN'", alg="algorithm name"

Para localizar o nome do serviço de pesquisa, acione a pesquisa em questão, clique com o botão direito do mouse na área do filtro e escolha Inspecionar. Pesquise "serviceName". O nome do serviço será listado aqui. Para encontrar o nome do campo a ser mascarado, procure por "Informações sobre Dispositivos". Dois resultados devem ser encontrados, um para a área do filtro e outro para a área dos resultados. A área dos resultados tem o texto "SEARCH_​RESULTS" como prefixo para cada campo. Os nomes dos campos são aqueles após o x$. Não faça referência a x$ quando definir o nome do campo. Observe que a instrução "where" só pode ser aplicada a campos que não fazem parte dos resultados da pesquisa.

Informações Adicionais sobre Máscara

Os pontos a seguir fornecem informações adicionais para auxiliar na configuração da máscara:

• Se o banco de dados de demonstração tiver uma configuração do recurso Máscara de Dados, revise as configurações porque elas provavelmente contêm regras de máscara que serão compatíveis com as suas.

• Em páginas de entrada, um usuário pode inserir ou alterar dados com máscara, como um número de conta bancária, mas não pode ver depois o que foi adicionado ou alterado.

• Sistemas externos podem solicitar informações realizando uma chamada de serviço via serviço Web. Saiba que algumas solicitações de serviço Web exigem que dados tenham máscara e outras não. Por exemplo, uma solicitação de um sistema externo para sincronizar informações de pessoas precisa que o número de previdência social da pessoa não tenha máscara, enquanto uma solicitação de um aplicativo de autosserviço na Web para recuperar as mesmas informações da pessoa para fins de exibição precisa que o número de previdência social da pessoa seja mascarado. Para implementar esse tipo de solicitação, usuários diferentes devem ser associados a cada uma das solicitações e esses usuários devem pertencer a grupos de usuários separados com direitos de acesso diferentes.

• Se um objeto de manutenção contiver um campo com um documento XML e uma chamada de serviço chamar o programa de serviço do objeto de manutenção diretamente, o sistema mascarará os elementos XML individuais no campo se um algoritmo Determinar Objeto de Negócios tiver sido implantado no objeto de manutenção e os elementos no respectivo esquema do objeto de negócios tiverem sido protegidos conforme descrito acima.