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