セキュリティとデータ エンティティ
メモ
データ エンティティは拡張可能なデータ セキュリティ (XDS) の概念をサポートしません。
エントリ ポイント
データ エンティティはエントリ ポイントのセキュリティをサポートします。 このサポートは、メニュー項目とページのサポートと似ています。 セキュリティ モデルを定義する際の柔軟性を高めるため、データ エンティティでは統合モードごとに個別のセキュリティ設定が可能となっています。 現在、データ エンティティに対して 2 つのエントリ ポイント/統合モードは識別されます。
| エントリ ポイント | 説明 |
|---|---|
| データ サービス | エンティティ用の OData サービス (API) を使用できる機能。 |
| データ管理 | インポート/エクスポートおよびコネクタの統合など、エンティティ用の非同期統合オプションを使用できる機能。 |
ターゲット シナリオ
データ エンティティは、シナリオの複数のカテゴリをサポートできます。 各カテゴリでは、別々に確保する必要があります。
- データ管理 (ファイルに基づくインポート/エクスポートなど) - 通常、データ マネージャーがこれらのシナリオを実行します。 これらのシナリオでは、クライアントの UI から通常アクセスできないデータにアクセスできます。 したがって、データ マネージャーがインポート/エクスポート操作のみを実行できるよう、関連ページへのアクセスとは独立してデータ管理シナリオを保護したいと考えることは多くあります。
- OData 経由の全般的な統合 – 多くの統合シナリオでは、データ エンティティをサービスとして公開する必要があるため、OData (オンライン ストアフロントや製品ライフサイクル管理 [PLM] システムなど) を介してデータにアクセスすることができます。 多くの場合、この目的のためにページ アクセスとは別に作成されている、データ エンティティへのアクセスを制御する必要があります。 つまり、クライアントの UI を使用してアクセス許可を与えることなく、サービス インターフェイスへのアクセスを許可します。
- Microsoft Office 統合 (Excel での編集など) – Office 統合シナリオでも、OData 経由でアクセスするデータ エンティティが必要です。 ただし、エンドユーザーの観点からは、これらのシナリオは、たとえば Microsoft Excel が一部の編集作業を簡略化するのに使用されるなど、クライアントの自然の拡張として見なすことができます。 したがって、通常、ページ アクセスとは独立して Microsoft Office の統合を保護する理由はありません。
権限/職務権限マッピング
データ エンティティの対象シナリオに応じて、1 つまたは複数の新しい特権を作成し、既存の職務を拡張する必要があります。 または、新しい権限をターゲット シナリオ用に特別に作成された職務にマップすることができます。 この方法は、シナリオに必要なアクセス権以上のアクセス権がユーザーに付与されないようにします。
次のテーブルに、作成する必要のある権限を示します。 また、職務にこれらの特権をマップする方法についても説明します。 データ エンティティが複数のシナリオをサポートすることを意図している場合、権限と職務権限マッピングを組み合わせたセットを作成する必要があります。
| ターゲット シナリオ | 権限 | 職務マッピング |
|---|---|---|
| データ エンティティは、データ管理を目的としています。 | 次の新しい権限を作成します:
|
新しい権限を持つ関連データの管理業務を拡張します。 詳細については、この記事で後述する「データ管理者ロール」セクションを参照してください。 |
| データ エンティティは、OData を介した一般的な統合を目的としています。 | 次の新しい権限を作成します:
|
統合シナリオの新しい職務を作成し、関連する新しい特権をこれらの職務にマッピングします。 詳細については、この記事で後述する「職務名のガイドライン」セクションを参照してください。 |
| データ エンティティは、Microsoft Office との統合を目的としています。 | 次の新しい権限を作成します:
|
新しい権限を持つ関連ページへのアクセスを提供する関連する既存の任務を拡張します。 |
前のテーブルで説明されている方法は最小特権の原則に準拠しているため、それを使用することをお勧めします。 ただし、場合によっては、次のより簡単な方法を使用することができます。 ただし、この方法は安全性が低い場合があることに注意してください。 管理および拡張が少し困難になる場合もあります。
| ターゲット シナリオ | 権限 | 職務マッピング | 潜在的な問題 |
|---|---|---|---|
| データ エンティティは、データ管理、OData による一般的な統合、および Microsoft Office との統合を目的としています。 | 次の新しい権限を作成します:
|
|
この方法を使用するときは、データのインポート/エクスポートへのアクセス許可を付与されているデータ マネージャーは、システムに Web サービスからもアクセスできます。 同様に、データ エンティティに関連付けられているページへのアクセスを許可されているユーザーは、Web サービスからでもシステムにアクセスできます。 このユーザーは、関連するデータ管理職務権限を付与されていない場合にのみ、データのインポート/エクスポートを禁止されます。 |
職務名のガイドライン
特定の統合シナリオのデータ エンティティを作成するとき、個別の職務も作成する必要があります。 これらの任務は、外部アプリケーションまたはサービスに、データ エンティティへの必要なアクセスを許可します。 作成する職務は、クライアント UI を介してアクセスするための対応する職務と同じ命名規則に従ってください。 ただし、「サービスを使用する」接尾辞を追加する必要があります。
| 職務タイプ | 職務オブジェクト名の接尾語 | 職務名のテンプレート |
|---|---|---|
| 有効化 | …IntegrationEnable | 有効化 … サービスの使用 |
| レコード | …IntegrationMaintain | メンテナンス … サービスの使用 |
| 認証する | …IntegrationApprove (リリース、確認、仕分入力) | 承認 (リリース、確認、仕訳入力) … サービスの使用 |
| 照会 | …IntegrationInquire | 照会先 … サービスの使用 |
これらのガイドラインに従う職務権限名の例を次に示します。
- サービスを使用した工順マスターの管理
- サービスを使用しているケース進捗状況の照会
データ管理者ロール
DataManagementApplicationAdministrator セキュリティ ロールによって、関連したユーザーが データ管理 ワークスペースでフル インポート/エクスポート機能を実行できます。 このセキュリティ ロールには、5 つのデータ エンティティ カテゴリに割り当てられた 2 つのセキュリティ職務があります。 1 つの関税は、関連するカテゴリのデータ エンティティを介してデータをインポートすることであり、1 つは関連するカテゴリのデータ エンティティを介してデータをエクスポートすることです。 したがって、このセキュリティ ロールには合計 10 のセキュリティ義務が割り当てられます。
- DataManagementApplicationDocumentEntitiesMaintain
- DataManagementApplicationDocumentEntitiesView
- DataManagementApplicationMasterEntitiesMaintain
- DataManagementApplicationMasterEntitiesView
- DataManagementApplicationParametersEntitiesMaintain
- DataManagementApplicationParametersEntitiesView
- DataManagementApplicationReferenceEntitiesMaintain
- DataManagementApplicationReferenceEntitiesView
- DataManagementApplicationTransactionEntitiesMaintain
- DataManagementApplicationTransactionEntitiesView
データ管理 ワークスペースで使用できるデータ エンティティを作成するとき、データ エンティティで指定される エンティティ カテゴリ プロパティに基づいて、新しいセキュリティ権限を持つこれらの職務を拡張する必要があります。 (新しいセキュリティ権限を使用して職務を拡張する方法については、この記事の前半の「特権/職務マッピング」セクションを参照してください)。また、職務を使用して、特定のデータ管理シナリオ用の新しいロールを作成することもできます。
アプリケーション エクスプローラーでの新しいエントリ ポイント セキュリティのモデリング
セキュリティのモデリングのパターンは、エントリ ポイントに対する権限を持つセキュリティのモデリングのパターンと似ています。 セキュリティをモデル化するには、次の手順を実行します。
新しい権限の作成を作成します。
新しいデータ エンティティのアクセス許可を作成します。
名前 を データ エンティティ に設定します。
アクセス レベル を選択します。
統合モードを選択します (すべて > Data Services > データ管理)。 これは、オブジェクトの種類のデータ エンティティに固有です。
- すべて - OData とデータのインポート/エクスポートの両方に適用される同じセキュリティ設定を適用します。
- データ管理 - データのインポート/エクスポートおよびコネクタの統合のみに適用されます。
- データ サービス - OData サービスにのみ適用されます。
機密データ
テーブル保護フレームワーク (TPF) は、財務と運用に格納されているデータへの厳密なアクセス制御を使用できます。 この機能は、テーブルおよびテーブルのフィールドの AOSAuthorization プロパティを介して公開されます。 AOSAuthorization を使用してテーブルまたはフィールドにマークを付ける場合、セキュリティ フレームワークでは、そのリソースへの明示的なアクセス権がユーザーに付与されている必要があります。 この要件は、テーブルまたはフィールドにデータエンティティでアクセスする場合にも適用されます。 この項では、データ エンティティの TPF アクセス許可を付与するためのガイドラインについて説明します。
データ管理
データ移行で対象となるデータ エンティティについては、TPF アクセス許可を対応するインポート/エクスポート権限に割り当てる必要があります。 この方法で、すべてのデータがインポート/エクスポートできることを保証できます。
OData を使用する統合
統合シナリオで対象とされるデータ エンティティについては、割り当てる必要がある TPF アクセス許可は、作業する全体としてのデータ エンティティに対して TPF で保護されたフィールドが必須かどうかに依存します。
- TPF で保護されたフィールドが必須の場合: 必須のフィールドは、常に読み取り/書き込みとなるフィールドです。 この場合、TPF のアクセス許可は、データ エンティティへのアクセスを許可する同じ権限に対して付与する必要があります。
- TPF で保護されたフィールドが必須ではない場合: 必須ではないフィールドの例としては、作業者の社会保障番号のフィールドおよび仕入先の銀行口座番号のフィールドがあります。 この場合、このフィールドにアクセスするための TPF アクセス許可は別の権限を通じて付与する必要があり、その権限は TPF で保護されたフィールドへのアクセスを必要とするロールに直接割り当てる必要があります。 ただし、フィールドがエンティティのマップ済フィールドである場合、そのロールはクライアント UI のページを通してフィールドへアクセスできるなら、ロールへのそのアクセスが既に許可された可能性があります。
エンティティにとって必須ではない TPF で保護されたフィールドへの明示的なアクセスを許可することには、いくつかの利点があります。
- だれが機密データへのアクセス権を持つかをより簡単に検出することができます。
- ロールに職務権限と特権の両方を割り当てる場合にのみにロールがアクセス権を取得するので、だれかが誤って機密データへのアクセスできるリスクを軽減できます。