ユーザー・インタフェースのマスキング

この項で説明する機能は、データベースにプレーン・テキストで格納されたデータを取得し、その値をマスキングしてからユーザー(または外部システム)に表示するために使用されます。この機能には、セキュリティ構成を使用して、マスキングされていないデータを一部のユーザーに表示できる機能が含まれています。このシステムでは、異なるフィールドに適用するために異なるマスキング・ルールを使用できます。たとえば、クレジット・カード番号は社会保障番号とは異なる方法でマスキングできます。

次のトピックでは、フィールド値をマスキングする方法を説明します。

マスキングするデータの識別

プレーン・テキストとして格納され、ユーザーに表示するためにマスキングする必要があるデータを識別します。たとえば、クレジット・カード番号および個人の連邦ID番号(たとえば、米国では社会保障番号またはSSN)を識別したとします。識別された各フィールドは、システム全体にわたって様々なユーザー・インタフェースで表示および保守されますが、データが表示される場所に関係なく指定のフィールドのマスキング・ルールはおそらく同一です。

主キーはマスキングできません。行の一意の識別子として定義されたフィールドは、マスキング対象として構成できません。主キーの一部であるフィールドのマスキングは、レコードを更新しようとする際に問題となります。この制限は、メンテナンス・オブジェクトのXML列のリストの一部である要素にも適用されます。リスト内の1つ以上の要素が、そのリストの主識別子として定義されている必要があります。リスト内の主キー要素がマスキング不要な要素であることを確認してください。

異なるタイプを含むメンバーをリストします。個人の識別番号が記載されているリストのページを考えてみます。個人の社会保障番号に運転免許証番号とは異なるマスキング・ルールが適用されるようにシステムを設定できます。このタイプの要件を実装で設定する場合は、マスキングしたフィールドのリストに、各マスキング・ルールのエントリを含める必要があります。

各フィールドについて、1つ以上のユーザー・インタフェースでマスキングされていないデータを参照する必要があるユーザーがいる場合は、セキュリティ構成が必要です。アプリケーションのすべてのページにわたってすべてのユーザーに対してフィールドの値をマスキングする必要がある場合、セキュリティ構成は必要ありません。

セキュリティ構成

次の2つの承認レベルで各フィールドのセキュリティ・タイプを定義します。

  • 1 - 表示できるのはマスキングした要素のみ

  • 2 - 表示できるのはマスキングされていない要素のみ

選択したアプリケーション・サービスに、すべてのセキュリティ・タイプをリンクします。アクセス権の付与が簡単になるように、すべてのマスキング志向セキュリティ・タイプを単一のアプリケーション・サービス(例:CM_​MASK)にリンクすることをお薦めします。

各セキュリティ・タイプについて、マスキングされていないデータを表示できるユーザーと、マスキングしたデータのみを表示できるユーザーを識別します。マスキングしたユーザーとマスキングされていないユーザーが既存のユーザー・グループに適合している場合、追加のユーザー・グループは不要です。適合しない場合は、マスキングしたユーザーとマスキングされていないユーザーに対して新しいユーザー・グループを作成します。

各セキュリティ・タイプに対してユーザー・グループを定義した後は、各ユーザー・グループを前に定義したアプリケーション・サービスにリンクします。ユーザー・グループがアプリケーション・サービスにリンクされた場合は、そのアプリケーション・サービスにリンクされている各セキュリティ・タイプに対して承認レベルを定義します。ユーザー・グループのユーザーがマスキングされていないセキュリティ・タイプのフィールド値を表示する必要がある場合は、承認レベルを2に設定し、そうでない場合は1に設定します。

注意: キャッシュをフラッシュします。アクセス権限を変更し、その変更をただちに有効にする場合は、(アプリケーションのURLにflushAll.jspを入力して)セキュリティ・キャッシュをフラッシュする必要があることに注意してください。

マスキング・アルゴリズムの構成

データ・マスキング・アルゴリズム(「機能構成 - データ・マスキング」のアルゴリズム・エンティティ値を使用)を、マスキング・ルールとセキュリティ・タイプの組合せごとに1つ作成する必要があります。これらのアルゴリズムによって、マスキングされていない特定のフィールドを表示する権限がユーザーにあるかどうか、ない場合はそのフィールドをマスキングする方法が決定されます。

基本パッケージには、ほとんどのマスキング・ニーズを処理するようにパラメータが設計されているアルゴリズム・タイプF1-MASKが用意されています。特定のユーザーにマスキングされていないデータを表示する場合は、アプリケーション・サービス、セキュリティ・タイプおよび前述の項で定義した承認レベルを取得し、これらを使用して評価します。さらに、パラメータを使用して、データをマスキングする大きさや使用するマスキング文字を構成できます。詳細は、アルゴリズム・タイプの説明を参照してください。

フィールドの表示方法の決定

マスキング構成は、ユーザー・インタフェースにアクセスするためのフィールドの取得方法によって異なります。そのため、1つの論理フィールド(個人のSSNなど)のマスキングには、すべてのアクセス方法をカバーするために、複数の構成エントリが必要になる可能性があります。指定のフィールドが表示される各ユーザー・インタフェースを確認し、次のカテゴリを作成します。

  • フィールドがビジネス・オブジェクト、ビジネス・サービスまたはサービス・スクリプトの起動によって取得される要素であるもの

  • フィールドが固定の保守ページに表示される(したがって、ページ・サービスの起動により取得される)もの

  • フィールドが固定の検索ページに表示される(したがって、検索サービスの起動により取得される)もの

  • フィールドがアドホック特性として格納されるもの

マスキングされた各要素に対する機能構成の作成

機能構成は、機能タイプの「データ・マスキング」を使用して作成します。マスキングするフィールドとデータの表示に使用する方法のすべての組合せには、オプション・タイプ「フィールド・マスキング」のオプション登録が必要です。値には、適切なデータ・マスキング・アルゴリズムを参照するニーモニックと、後述のように表示するフィールドの取得方法に応じて異なる構成が含まれます。

スキーマベース・オブジェクトのフィールド・マスキング

スキーマベースのオブジェクト・コールを介してアクセスし、UIマップに表示されるデータの場合は、マスキング対象フィールドが、そのスキーマ定義のメタデータ・フィールド名(field="fld_​name", alg="algorithm name")を参照する必要があります。

要素がスキーマのmdField要素を参照する場合は、そのフィールドがマスキング・ルールの識別に使用されます。mdField参照がなく、mapField参照のみがある場合は、そのフィールドがマスキング・ルールの識別に使用されます。たとえば、クレジット・カード番号をマスキングする場合、フィールドは、次のようにスキーマに定義されていると仮定します。

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

この場合、オプション値はfield="CCNBR", alg="algorithm name"とします。field="EXT_​ACCT_​ID", alg="algorithm name"のオプション値を指定しても、マスキングは適用されません。

where句を指定することもできます。これは、リスト内のデータで特定のタイプのデータのみをマスキングする必要がある場合に便利で、field="fld_​name", alg="algorithm name", where="fld_​name='value'"のように指定します。

たとえば、IDのコレクションがある中で、タイプが「SSN」(社会保障番号)のIDのみをマスキングする必要があるとします。パーソンIDのコレクションが格納されたパーソン・データが、ビジネス・オブジェクト・コールを介してUIマップに表示される場合は、次のようにしてコレクションが定義されると仮定します。

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

オプション値は、field="PER_​ID_​NBR", alg="algorithm name", where="ID_​TYPE_​CD='SSN'"のようになります。

スキーマベースのマスキングについて、次の重要な点に注意してください。

  • whereフィールドの制限。スキーマ志向の要素に対するwhere句の主な用途は、タイプに基づいてリスト内の特定の要素をマスキングすることですが、別のフィールドの値に基づいてスキーマ内の1つのフィールドをマスキングすることも可能です。たとえば、顧客が、IDタイプとID値を定義する登録フォームを発行するとします。このデータはリストにありませんが、実装ではIDタイプが「SSN」の場合にのみID値をマスキングする必要があります。フレームワークでは、where句の要素がスキーマ内で「兄弟」の場合は、where句に基づいてスキーマ内の要素を単純にマスキングできます。

    • マスキング対象要素がリストにある場合は、where句の要素も同じリスト内に存在する必要があります。

    • マスキング対象要素を表内の実在する列にマップする場合は、where句の要素も表内の実在する列にマップする必要があります。

    • マスキング対象要素を表のXML列に単一の要素としてマップする場合は、where句の要素も同じXML列に単一の要素としてマップする必要があります。

  • 同じフィールドに対する複数の機能オプションの登録。システム内の異なるスキーマには、異なる状態に基づいてマスキングされる同じタイプのデータを保持できます。たとえば、実装には、異なる方法でパーソン識別子が取得または参照される異なるスキーマがあるとします。

    • あるスキーマでは、対応する「タイプ」レコードを使用せずに単一のパーソンIDを取得し、そのIDはCM_​SSN_​MASKというアルゴリズムを使用して常にマスキングされます。

      <personSSN mapXML=BO_DATA_AREA mdField=PER_ID_NBR/>

    • あるスキーマでは、パーソンIDおよび対応するIDタイプを取得し、タイプが「SSN」の場合はCM_​SSN_​MASKというアルゴリズムを使用してIDがマスキングされ、タイプが「FEIN」の場合はCM_​FEIN_​MASKというアルゴリズムを使用してIDがマスキングされます。

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

    • あるスキーマでは、パーソンIDおよび対応するIDタイプを取得して、前述のスキーマと同様のマスキング・ルールがありますが、IDタイプ・コードには別のフィールド名が使用されます。(このシナリオは、たとえば、このスキーマのユーザー・インタフェースでIDタイプに対して異なるラベルが必要な場合に生じます。)

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

    このシナリオの場合、機能オプションは次のようになります。

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

    各スキーマについて、要素がマスキング・オプションに適用されるかどうかが最初に検索されます。PER_​ID_​NBRフィールドに対して5個のマスキング・オプションが検出されます。次に、兄弟要素がwhere句と一致するかどうかが判断されます。

    • 複数の兄弟要素がwhere句と一致した場合は、ランタイム・エラーが発行されます。たとえば、あるスキーマに"mdField=ID_​TYPE_​CD"を参照する要素と"mdField=CM_​ID_​TYPE"を参照する要素があると、エラーになります。さらに、複数の要素が"mdField=ID_​TYPE_​CD"を参照する場合も、エラーになります。

    • 単一の兄弟要素がwhere句と一致する場合は、要素の値がwhere句に定義された値と比較されます。値の一致が検出された場合は、適切なマスキング・アルゴリズムが適用されます。一致が検出されなかった場合(パーソンIDタイプが"LICENSE"の場合など)は、要素がそのまま表示されます。

    • where句と一致する兄弟要素がなく、where句がない機能オプションが存在する場合(前述のオプション1)は、where句がないオプションのマスキング・アルゴリズムが適用されます。

  • where句の値の変更。条件に基づいて一部のデータがマスキングされたレコードを変更できるユーザーが実装によって割り当てられている場合は、where句の値が変更されたときに、マスキングされた値をリセットするユーザー・インタフェースを設計することをお薦めします。たとえば、ユーザーにパーソンの社会保障番号が表示されないようにする一方で、パーソンのレコードの更新をユーザーに許可する場合は、パーソンIDタイプの値の変更によって、パーソンID番号をリセットします。単純にIDタイプを変更することでユーザーが社会保障番号のマスキングを解除できないようになります。

ページ保守を使用して保守されるレコード

ページ保守サービス・コールを介してアクセスされるデータの場合は、そのデータがある表名とフィールド名(table="table_​name", field="fld_​name", alg="algorithm name")を指定します。

たとえば、パーソン・レコードとその識別子のコレクションが、ページ保守を使用して表示および保守される場合、オプション値はtable="CI_​PER_​ID", field="PER_​ID_​NBR", alg="algorithm name"のようになります。

table="table_​name", field="fld_​name", where="fld_​name='value'", alg="algorithm name"のように、where句も指定できます。

これは、子表内のデータで特定のタイプのデータのみをマスキングする必要がある場合に便利です。たとえば、パーソンIDはtable="CI_​PER_​ID", field="PER_​ID_​NBR", alg="algorithm name", where="ID_​TYPE_​CD='SSN'"のようにします。

特性データ

特性として格納されるデータの場合は、CHAR_​TYPE_​CD='char type', alg="algorithm name"のように単純に特性タイプを指定します。

これは、特性タイプがどの特性エンティティに存在するかに関係なく、1回のみ定義する必要があります。アドホック特性のみがサポートされることに注意してください。

エクスプローラ・ゾーンまたは情報文字列のフィールドのマスキング

エクスプローラ・ゾーンでは、多くの場合、データはSQLを使用してデータベースから直接取得されます。この場合、マスキングは自動的には適用されません。結果をマスキングする必要があるデータがエクスプローラ・ゾーンにある場合は、ビジネス・サービスをコールしてマスキングを適用する必要があります。

同様に、メンテナンス・オブジェクト情報アルゴリズムは、データを取得する際にビジネス・オブジェクト相互作用を使用しません。効率上の理由でSQLを使用してデータにアクセスする可能性があります。SQLを介してデータを取得する際、マスキングは適用されません。文字列にマスキングを適用してから情報文字列に挿入する場合は、ビジネス・サービスをコールしてマスキングを適用する必要があります。

システムには、特定のフィールドに対してマスキング・ルールを適用するかどうかを判断する際にコールする2つのビジネス・サービスが用意されています。

  • F1-TableFieldMask。表フィールドをマスキングします。このビジネス・サービスは、表名、フィールド名および1つ以上のフィールド値を受け取ります。マスキングが適用される場合は、マスキング済の値が返されます。

  • F1-SchemaFieldMask。スキーマ・フィールドをマスキングします。このビジネス・サービスは、スキーマ名とタイプ、XPathとフィールド値を受け取ります。マスキングが適用される場合は、マスキング済の値が返されます。

検索サービスの結果

固定の検索ページに表示されるデータの場合は、検索サービス・コールを介して取得されます。検索名およびマスキングする適切なフィールドをマスキング・アルゴリズムとともに指定します。例: search="SearchServiceName", field="PER_ID_NBR", where="ID_TYPE_CD='SSN'", alg="algorithm name"

検索サービスの名前を見つけるには、問題の検索を起動し、フィルタ領域を右クリックして「Inspect」を選択します。"serviceName"を検索します。サービス名がリストされます。マスクするフィールド名を見つけるには、"Widget Info"を検索します。結果は2つ見つかり、1つはフィルタ領域、1つは結果領域のものです。この結果領域には、各フィールドの接頭辞として"SEARCH_​RESULTS"というテキストがあります。フィールド名はx$の後のものです。フィールド名を定義するときにx$を参照しないでください。where文は、検索結果の一部でもあるフィールドにのみ適用できます。

マスキングに関する追加情報

次に、マスキング構成に役立つ追加情報をいくつか示します。

  • デモンストレーション・データベースに「データ・マスキング」機能構成が含まれている場合は、自社に適したマスキング・ルールが含まれている可能性があるため、設定を確認してください。

  • データ入力のページでは、ユーザーは銀行口座番号などのマスキングしたデータを入力または変更できますが、追加または変更した内容を後で表示することはできません。

  • 外部システムによる情報の要求は、Webサービスを介したサービス・コールで実行できます。一部のWebサービス要求ではデータのマスキングが要求され、他の一部では要求されないことに注意してください。たとえば、パーソン情報を同期化する外部システムの要求では、そのパーソンの社会保障番号がマスキングされていないことが必要ですが、表示目的で同じパーソン情報を取得するWebセルフサービス・アプリケーションの要求ではマスキングされていることが必要です。このタイプの要件を実装するには、各要求に異なるユーザーを関連付ける必要があり、これらのユーザーは異なるアクセス権限を備えた個別のユーザー・グループに属している必要があります。

  • XMLドキュメントを保持しているフィールドがメンテナンス・オブジェクト(MO)に含まれているときにサービス・コールによってメンテナンス・オブジェクトのサービス・プログラムが直接起動された場合、「ビジネス・オブジェクトの決定」アルゴリズムがメンテナンス・オブジェクトにプラグインされ、各ビジネス・オブジェクト・スキーマ内の要素が前述のように保護されていれば、そのフィールド内の個々のXML要素がマスキングされます。