Maskowanie w interfejsie użytkownika

Wskazanie danych do maskowania

Należy wskazać dane, które są przechowywane jako tekst niesformatowany, ale powinny być maskowane w celu wyświetlenia ich użytkownikom. Załóżmy przykładowo, że wskazano numery kart kredytowych i państwowy numer identyfikacyjny (np. w USA numer ubezpieczenia społecznego, czyli SSN). Każde wskazane pole można wyświetlić i obsługiwać w różnych interfejsach użytkownika w systemie, jednak reguły maskowania danego pola będą prawdopodobnie takie same, niezależnie od miejsca wyświetlania danych.

Klucze główne nie mogą być maskowane. Nie można maskować pola zdefiniowanego jako unikatowy identyfikator wiersza. Maskowanie pola będącego częścią klucza głównego powoduje problemy przy próbie aktualizacji rekordu. Ograniczenie dotyczy również elementów będących częścią "listy" w kolumnie XML w obiekcie obsługi. Należy zdefiniować co najmniej jeden element listy jako główny identyfikator listy. Należy się upewnić, czy elementy klucza głównego listy nie są tymi, które wymagają maskowania.

Lista członków zawierająca różne "typy". Rozważmy stronę, na której znajduje się lista zawierająca numery identyfikacyjne osoby. Można skonfigurować system w taki sposób, aby numer ubezpieczenia społecznego osoby miał inne reguły maskowania, niż jej numer prawa jazdy. Jeśli wdrożenie posiada ten typ wymagań, to lista maskowanych pól powinna zawierać jedną pozycję dla każdej reguły maskowania.

Jeśli istnieją użytkownicy z uprawnieniami do wyświetlania niemaskowanych danych w jednym lub w wielu interfejsach użytkownika, wówczas w każdym polu wymagana jest konfiguracja zabezpieczeń. Jeśli wartość pola ma być maskowana dla wszystkich użytkowników na wszystkich stronach aplikacji, to konfiguracja zabezpieczeń nie jest wymagana.

Konfiguracja zabezpieczeń

Dla każdego pola należy zdefiniować typ zabezpieczenia z dwoma poziomami autoryzacji:

• 1 - Można zobaczyć tylko zamaskowany element

• 2 - Można zobaczyć tylko niezamaskowany element

Należy połączyć wszystkie typy zabezpieczeń z wybraną usługą aplikacyjną. Ze względu na ułatwienia w przyznawaniu dostępu zaleca się powiązanie każdego typu zabezpieczenia zorientowanego na maskowanie z jedną usługą aplikacyjną (np. CM_MASK).

Dla każdego typu zabezpieczenia należy wskazać, którzy użytkownicy mogą widzieć dane niezamaskowane, a którzy mogą widzieć wyłącznie zamaskowane dane. Jeśli zamaskowani i niezamaskowani użytkownicy pasują do istniejących grup użytkowników, nie ma potrzeby tworzenia dodatkowych grup użytkowników. W przeciwnym wypadku należy utworzyć nowe grupy użytkowników dla zamaskowanych i niezamaskowanych użytkowników.

Po zdefiniowaniu grup użytkowników dla poszczególnych typów zabezpieczeń, należy połączyć każdą grupę użytkowników ze zdefiniowaną powyżej usługą aplikacyjną. Po połączeniu grupy użytkowników z usługą aplikacyjną należy zdefiniować poziom autoryzacji dla każdego typu zabezpieczenia połączonego z usługą aplikacyjną. Jeśli grupa użytkowników ma widzieć niezamaskowane wartości pola typu zabezpieczenia, należy ustawić poziom autoryzacji na 2, w przeciwnym wypadku na 1.

Konfigurowanie algorytmu maskowania

Dla każdej kombinacji reguł maskowania i typu zabezpieczeń należy utworzyć algorytm maskowania danych przy użyciu wartości obiektu algorytmu Konfiguracja cech - maskowanie danych. Algorytmy te określają, czy użytkownik posiada prawo do przeglądania niezamaskowanego pola i, w przeciwnym wypadku, sposób jego maskowania.

Pakiet podstawowy zawiera typ algorytmu F1-MASK, którego parametry zaprojektowano tak, aby obsługiwały większość potrzeb związanych z maskowaniem. Jeśli istnieją użytkownicy z uprawnieniami do wyświetlania niemaskowanych danych, w celu ustalenia tych uprawnień parametry pobierają usługę aplikacyjną, typ zabezpieczeń i poziom autoryzacji zdefiniowane powyżej. Ponadto za pomocą parametrów można skonfigurować ilość danych do maskowania i znaki używane w tym celu. Więcej informacji można znaleźć w opisie typu algorytmu.

Określanie sposobu wyświetlania pól

Konfiguracja maskowania będzie się różnić w zależności od sposobu uzyskania dostępu do pola w interfejsie użytkownika. W celu zamaskowania jednego "logicznego" pola (jak numer ubezpieczenia społecznego osoby) może istnieć wiele zapisów konfiguracji wymaganych do uwzględnienia poszczególnych metod dostępu. Należy przejrzeć każdy interfejs użytkownika, w którym wyświetlane jest dane pole, i utworzyć następujące kategorie:

• Pole jest elementem pobieranym przez wywołanie obiektu biznesowego, usługi biznesowej lub skryptu usługi

• Pole jest wyświetlane na ustalonej stronie obsługi (i w związku z tym jest pobieranie przez wywołanie usługi strony)

• Pole jest wyświetlane na ustalonej stronie wyszukiwania (i w związku z tym jest pobieranie przez wywołanie usługi wyszukiwania)

• Pole jest przechowywane jako charakterystyka ad hoc

Tworzenie konfiguracji cechy dla każdego maskowanego elementu

Należy utworzyć konfigurację cechy o typie Maskowanie danych. Dla każdej kombinacji pola do maskowania i używanej metody wyświetlania danych wymagany jest zapis opcji o typie Maskowanie pola. Wartość będzie zawierać mnemoniki odwołujące się do odpowiedniego algorytmu maskowania danych, a także konfigurację różniącą się w zależności od sposobu pobierania pola do wyświetlenia, jak opisano poniżej.

Maskowanie pola obiektu opartego na schemacie

W przypadku danych dostępnych przez wywołanie obiektu opartego na schemacie i wyświetlanych w odwzorowaniu interfejsu użytkownika, pole do maskowania musi odwoływać się do nazwy pola metadanych w swojej definicji schematu: field="fld_​name", alg="algorithm name"

Jeśli element odwołuje się do pola mdField w schemacie, pole to stosowane jest do wyznaczenia reguły maskowania. Jeśli nie istnieje odwołanie do pola mdField, lecz jedynie odwołanie do pola mapField, pole to umożliwia wyznaczenie reguły maskowania. Na przykład aby zamaskować numer karty kredytowej, można założyć, że pole zdefiniowane w schemacie to:

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

W tym przypadku wartość opcji powinna być następująca: field="CCNBR", alg="algorithm name". Wartość opcji: field="EXT_​ACCT_​ID", alg="algorithm name" uniemożliwi maskowanie.

Można też określić klauzulę "where". Jest to przydatne, jeśli dane znajdują się na liście, na której należy zamaskować tylko dane określonego typu: field="fld_​name", alg="algorithm name", where="fld_​name='value'"

Na przykład dana osoba może dysponować zbiorem ID, ale powinien być maskowany wyłącznie ID typu "SSN" (numer ubezpieczenia społecznego). Jeśli dane osoby, w tym zbiór ID osoby, wyświetlane są w odwzorowaniu interfejsu użytkownika za pomocą wywołania obiektu biznesowego, można założyć, że zbiór ten zdefiniowany jest w następujący sposób:

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

Możliwa wartość opcji to: field="PER_​ID_​NBR", alg="algorithm name", where="ID_​TYPE_​CD='SSN'"

W przypadku maskowania pola obiektu opartego na schemacie należy wziąć pod uwagę:

• Ograniczenie pola "where" Chociaż głównym zastosowaniem klauzuli "where" w przypadku elementów opartych na schemacie jest maskowanie niektórych elementów listy na podstawie "typu", możliwe jest również maskowanie pojedynczego pola schematu w oparciu o wartość innego pola. Załóżmy na przykład, że klient przesyła formularz rejestracji, w którym zdefiniowano typ ID oraz wartość ID. Pomimo że te dane nie są uwzględnione na liście, w ramach danego wdrożenia można zamaskować jedynie wartość ID, jeśli typem ID jest "SSN". Platforma Framework umożliwia maskowanie elementu schematu na podstawie klauzuli "where" tylko w przypadku, gdy należący do niej element stanowi element spowinowacony w schemacie.

  • W przypadku gdy element maskowany znajduje się na liście, element klauzuli "where" musi należeć do tej samej listy.

  • W przypadku odwzorowania elementu maskowanego do rzeczywistej kolumny w tabeli, element klauzuli "where" musi także zostać odwzorowany do rzeczywistej kolumny w tabeli.

  • W przypadku odwzorowania elementu maskowanego jako pojedynczego elementu do kolumny XML w tabeli, element klauzuli "where" musi także zostać odwzorowany jako pojedynczy element do tej samej kolumny XML.

• Wprowadzanie wielu wartości opcji cechy dla tego samego pola. Może się zdarzyć, że w różnych schematach systemu istnieją dane podobnego typu, które mogą być maskowane w oparciu o różne warunki. Na przykład w ramach danego wdrożenia mogą istnieć różne schematy, w których pobrano identyfikatory osób lub utworzono odwołania do nich na różne sposoby:

  • W schemacie pobierany jest jeden ID osoby bez odpowiadającego mu rekordu "typu". W tym przypadku ID powinien być zawsze maskowany przy użyciu algorytmu CM_​SSN_​MASK:

    <personSSN mapXML=BO_DATA_AREA mdField=PER_ID_NBR/>

  • W schemacie pobierany jest ID osoby i odpowiadający mu typ ID. ID powinien być maskowany przy użyciu algorytmu CM_​SSN_​MASK, jeśli jest identyfikatorem typu "SSN" lub przy użyciu algorytmu CM_​FEIN_​MASK, jeśli jest identyfikatorem typu "FEIN".

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

  • W schemacie pobierany jest ID osoby i odpowiadający mu typ. Wykorzystywane są te same reguły maskowania, co w przypadku poprzedniego schematu, ale przy użyciu innej nazwy pola dla kodu typu ID. (Jest to możliwe np. gdy dla danego schematu wymagane jest zastosowanie innej etykiety typu ID w interfejsie użytkownika.)

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

  Możliwe opcje cechy w przypadku tego scenariusza:

  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'"

  W przypadku każdego schematu system najpierw sprawdza, czy do danego elementu można zastosować jedną z opcji maskowania. System wyszuka 5 opcji maskowania dla pola PER_​ID_​NBR. Następnie określi, czy istnieją elementy spowinowacone odpowiadające klauzuli "where".

  • Jeśli istnieje więcej niż jeden element spowinowacony odpowiadający klauzuli "where", zgłaszany jest błąd wykonania programu. Na przykład jeśli w danym schemacie istnieje element odwołujący się do "mdField=ID_​TYPE_​CD" oraz element odwołujący się do "mdField=CM_​ID_​TYPE", zgłaszany jest błąd. Błąd zgłaszany jest również w przypadku, gdy wiele elementów odwołuje się do parametru "mdField=ID_​TYPE_​CD".

  • Jeśli klauzuli "where" odpowiada wyłącznie jeden element spowinowacony, jego wartość porównywana jest do wartości zdefiniowanych w klauzuli. W przypadku znalezienia dopasowania wartości stosowany jest odpowiedni algorytm maskowania. Natomiast w przypadku braku dopasowania (np. typ ID osoby to "LICENSE") element wyświetlany jest w niezmienionej formie.

  • Jeśli nie istnieje żaden element spowinowacony odpowiadający klauzuli "where", a w opcji cechy klauzula "where" nie jest uwzględniona (opcja 1 powyżej), stosowany jest algorytm maskowania zawarty w opcji nieobejmującej klauzuli "where".

• Zmianę wartości klauzuli "where". Jeśli w ramach danego wdrożenia istnieje grupa użytkowników, którzy mają możliwość dokonywania zmian w rekordach zawierających dane maskowane na podstawie określonego warunku, zalecane jest zaprojektowanie interfejsu użytkownika w sposób umożliwiający resetowanie maskowanej wartości, gdy ulega zmianie wartość klauzuli "where". Na przykład jeśli użytkownik nie może wyświetlić numeru ubezpieczenia społecznego osoby, ale ma możliwość aktualizowania rekordu tej osoby, zmiana wartości typu ID osoby powinna spowodować zresetowanie numeru ID osoby. Uniemożliwia to anulowanie maskowania numeru ubezpieczenia społecznego poprzez zmianę typu ID.

Rekordy obsługiwane przy użyciu obsługi strony

W przypadku danych dostępnych poprzez wywołanie usługi obsługi strony należy wskazać nazwy tabeli i pola, w których znajdują się dane: table="table_​name", field="fld_​name", alg="algorithm name"

Na przykład jeśli rekord osoby oraz zbiór ID osoby są wyświetlane i obsługiwane przy użyciu funkcji obsługi strony, wymagana wartość opcji to: table="CI_​PER_​ID", field="PER_​ID_​NBR", alg="algorithm name"

Można również określić klauzulę "where": table="table_​name", field="fld_​name", where="fld_​name='value'", alg="algorithm name"

Jest to przydatne, jeśli dane znajdują się w tabeli podrzędnej, w której należy maskować tylko dane określonego typu. Przykładowa wartość ID osoby: table="CI_​PER_​ID", field="PER_​ID_​NBR", alg="algorithm name", where="ID_​TYPE_​CD='SSN'"

Dane charakterystyki

Jeśli dane są przechowywane w postaci charakterystyki, wystarczy podać typ charakterystyki: CHAR_​TYPE_​CD='char type', alg="algorithm name"

Typ ten definiuje się tylko raz, niezależnie od obiektu charakterystyki, w którym może się on znajdować. Należy pamiętać, że obsługiwane są jedynie charakterystyki ad hoc.

Maskowanie pól w strefach eksploratora lub ciągach informacji

Dane zawarte w strefach eksploratora często pobierane są za pomocą instrukcji SQL bezpośrednio z bazy danych. W tym przypadku automatyczne maskowanie nie ma zastosowania. Jeśli w wynikach strefy eksploratora pojawią się dane wymagające maskowania, należy zastosować maskowanie poprzez wywołanie usługi biznesowej.

Podobnie w algorytmie informacji obiektu obsługi nie można zastosować interakcji obiektu biznesowego w celu pobrania danych. Ze względu na wydajność dostęp do danych uzyskuje się za pomocą instrukcji SQL. W tym przypadku maskowanie nie jest stosowane. Aby zastosować maskowanie ciągu przed uwzględnieniem go w ciągu informacji, konieczne jest wywołanie usługi biznesowej.

W systemie dostępne są dwie usługi biznesowe wywoływane w celu określenia, czy reguły maskowania mają zastosowanie do danego pola.

• F1-TableFieldMask. Maskowanie pola tabeli. Ta usługa biznesowa umożliwia pobranie nazwy tabeli, nazwy pola oraz wartości co najmniej jednego pola. Jeśli maskowanie ma zastosowanie, zwracana jest wartość maskowana.

• F1-SchemaFieldMask. Maskowanie pola schematu. Ta usługa biznesowa umożliwia pobranie nazwy i typu schematu, ścieżki XPath oraz wartości pola. Jeśli maskowanie ma zastosowanie, zwracana jest wartość maskowana.

Wyniki usługi wyszukiwania

Dane wyświetlane na "ustalonej" stronie wyszukiwania są pobierane poprzez wywołanie usługi wyszukiwania. Należy wskazać nazwę wyszukiwania i odpowiednie pole do maskowania wraz z algorytmem maskowania. Na przykład: search="SearchServiceName", field="PER_​ID_​NBR", where="ID_​TYPE_​CD='SSN'", alg="algorithm name"

Aby znaleźć nazwę usługi wyszukiwania, należy uruchomić wybrane wyszukiwanie, kliknąć prawym przyciskiem myszy w obszarze filtra i wybrać opcję Zbadaj. Następnie należy wyszukać wartość "serviceName". Nazwa usługi znajduje się na liście. Aby znaleźć nazwę pola do maskowania, należy wyszukać wartość "Informacje o widżetach". Powinny wyświetlić się dwa wyniki: jeden dla obszaru filtra i jeden dla obszaru wyników. Ten obszar wyników zawiera tekst "SEARCH_​RESULTS" jako prefiks dla każdego pola. Nazwy pól to wartości występujące po x$. Podczas definiowania nazwy pola nie należy odwoływać się do x$. Klauzula "where" dotyczy tylko pól wchodzących w skład wyników wyszukiwania.

Dodatkowe informacje dotyczące maskowania

Poniżej przedstawiono dodatkowe informacje, pomocne przy konfiguracji maskowania:

• Jeśli w demonstracyjnej bazie danych uwzględniono konfigurację cechy Maskowanie danych, wskazane jest sprawdzenie ustawień, ponieważ prawdopodobnie zawierają one reguły maskowania dopasowane do reguł użytkownika.

• Użytkownik będzie mógł wprowadzić lub zmienić zamaskowane dane na stronach danych wejściowych, takie jak numer konta bankowego, lecz następnie nie będzie w stanie zobaczyć, co dodano lub zmieniono.

• Systemy zewnętrzne mogą żądać informacji, wywołując usługę za pomocą usługi WWW. Należy pamiętać, że niektóre żądania usługi WWW wymagają maskowanych danych, a inne nie. Na przykład żądanie z systemu zewnętrznego dotyczące synchronizacji informacji o osobie potrzebuje niezamaskowanego numeru ubezpieczenia społecznego. Natomiast żądanie pochodzące z aplikacji dostępu przez Internet, pobierające tę samą informację o osobie w celu jej wyświetlenia, potrzebuje numeru ubezpieczenia społecznego w formie zamaskowanej. Aby wdrożyć ten typ wymagań, użytkownicy muszą być powiązani z każdym z żądań i muszą oni należeć do różnych grup użytkowników posiadających różne prawa dostępu.

• Gdy obiekt obsługi zawiera pole przechowujące dokument XML, a wywołanie usługi bezpośrednio wywołuje program usługi obiektu obsługi, to, jeśli algorytm Określanie obiektu biznesowego został powiązany z obiektem obsługi, a elementy w odpowiednim schemacie obiektu biznesowego zostały zabezpieczone w opisany powyżej sposób, system zamaskuje poszczególne elementy pola.