ロールベース セキュリティ

この記事では、財務と運用のロールベースのセキュリティの要素の概要を説明します。

ロールベース セキュリティでは、個々のユーザーではなく、セキュリティ ロールに対してのみアクセスを許可します。 ユーザーはロールに割り当てられます。 セキュリティ ロールに割り当てられているユーザーは、そのロールに関連付けられている一連の権限にアクセスできます。 任意のロールに割り当てられていないユーザーには権限がありません。

財務と運用アプリでは、ロール ベース セキュリティが業務の構造で調整されます。 ユーザーは、組織内の担当と業務プロセスへの参加に基づいて、セキュリティ ロールに割り当てられます。 管理者は、ユーザーが使用する必要があるプログラム要素へのアクセスではなく、ロールのユーザーが実行する職務権限へのアクセスを許可します。

自動ロール割り当てのルールを設定できるため、ユーザーの職責が変更されるたびに管理者が関与する必要はありません。 セキュリティ ロールとルールが設定された後、業務管理者は、業務データに基づく日常的なユーザーのアクセスを制御できます。

ロール ベースのセキュリティの概要

このセクションでは、ロールベースのセキュリティの要素の概要を提供します。 セキュリティ モデルは階層型であり、階層内の各要素は異なるレベルの詳細を表します。 アクセス許可は、メニュー項目やテーブルなどの個々のセキュリティ保護可能なオブジェクトへのアクセスを表します。 権限は、アクセス許可で構成されており、支払のキャンセルや預金残高の処理などのタスクへのアクセスを表します。 職務は特権で構成され、銀行取引の維持などビジネス プロセスの一部を表します。 職務と権限の両方をロールに割り当てて、財務と運用へのアクセスを許可することができます。

次の図は、ロールベースのセキュリティとそれらの関係の要素を示しています。

セキュリティ ロール

すべてのユーザーは財務と運用にアクセスするため少なくとも 1 つのセキュリティ ロールに割り当てられている必要があります。 ユーザーに割り当てられたセキュリティ ロールにより、ユーザーが実行できる職務と、ユーザーが表示できるユーザー インターフェイスの部分が決まります。

管理者は、データ セキュリティ ポリシーを適用して、ロールのユーザーがアクセス権を持つデータを制限します。 たとえば、ロールのユーザーは、単一の組織からのみ、データへアクセスできる場合があります。 管理者は、ロールのユーザーが持つ、過去、現在、および将来のレコードに対するアクセスのレベルも指定できます。 たとえば、ロールでのユーザーは、すべての期間のレコードを表示できるよう特権を割り当てられますが、現在の期間のみのレコードを変更できます。

セキュリティ ロールによるアクセスを管理することで、ユーザーごとに個別にアクセスを管理する必要がないため管理者は時間を節約できます。 セキュリティ ロールは、すべての組織で 1 回定義されます。 さらに、ユーザーを業務データに基づくロールに自動的に割り当てることができます。 たとえば、管理者は、セキュリティ ロールで人事管理の職位に関連付けるルールを設定できます。 ユーザーがその位置に割り当てられるたびに、それらのユーザーは適切なセキュリティ ロールに自動的に追加されます。

セキュリティ ロールは、階層構造に編成することができます。 ロール階層を使用すると、管理者は別のロールに基づいてロールを定義できます。 たとえば、販売マネージャー ロールは、マネージャー ロールおよび営業担当者ロールの親ロールとして定義されます。 親ロールは、職務、権限、およびその子ロールに割り当てられている条件を自動的に継承します。 したがって、親ロールに割り当てられているユーザーは、子ロールのユーザーが実行できるすべてのタスクを実行できます。 ロールは、1 つ以上の子ロールまたは 1 つ以上の親ロールを持つことができます。

既定では、サンプルのセキュリティ ロールが提供されています。 すべての機能は少なくとも 1 つのサンプル セキュリティ ロールに関連付けられています。 管理者は、サンプル セキュリティ ロールにユーザーを割り当てるか、企業のニーズに合わせてサンプル セキュリティ ロールを変更するか、または新しいセキュリティ ロールを作成することができます。 既定では、サンプル ロールは階層内に配置されません。

職務

職務は、ビジネス プロセスの一部に対応します。 管理者は、職務をセキュリティ ロールに割り当てます。 1 つの職務権限に、複数のロールを割り当てることができます。

セキュリティ モデルでは、職務に権限が含まれます。 たとえば、銀行トランザクションの管理職務は、入金伝票の生成および支払のキャンセル権限を含みます。 職務および権限の両方をセキュリティ ロールに割り当てられますが、職務を使用して財務と運用へのアクセスを許可することをお勧めします。

関連する職務を別々のロールに割り当てることができます。 これらの職務は分離されていると言われています。 職務を分離することにより、企業改革 (SOX)、国際財務報告基準 (IFRS)、米国食品医薬品局 (FDA) などの規制要件をよりよく遵守することができます。 さらに、職務分掌により、不正のリスクを減らし、エラーや反則を検出できます。

既定の職務が用意されています。 管理者は、職務権限に関連付けられている権限を変更するか、新しい職務権限を作成することができます。

権限

セキュリティ モデルでは、ジョブを実行したり、問題を解決したり、割り当てを完了したりするために必要なアクセス許可のレベルが権限によって指定されます。 権限はロールに直接割り当てることができますが、職務をロールのみに割り当てることをお勧めします。 職務をロールに割り当てることで、権限が職務にまとめられるため、メンテナンスが容易になります。

権限には、ユーザー インターフェイス要素やテーブルなどの個別のアプリケーション オブジェクトへのアクセス許可が含まれています。 たとえば、支払のキャンセル権限には、支払のキャンセルに必要なメニュー項目、フィールド、およびテーブルへのアクセス許可が含まれています。

既定では、財務と運用のすべての機能に対して権限が提供されます。 管理者は、権限に関連付けられているアクセス許可を変更するか、新しい権限を作成することができます。

アクセス許可

フォームまたはサービスなどの各機能は、エントリ ポイントを使ってアクセスします。 メニュー項目、Web コンテンツ項目、およびサービス工程は、総称してエントリ ポイントと呼ばれます。

セキュリティ モデルでは、セキュリティ保護可能なオブジェクトと機能を実行するために必要なアクセス レベルは権限によってグループ化されます。 このグループには、エントリ ポイントからアクセスされるテーブル、フィールド、フォーム、またはサーバー側のメソッドが含まれます。

Dynamics 365 でのサービス更新後のセキュリティ オブジェクトの管理

セキュリティ オブジェクトを確実に更新し、最新のサービス アップデートに対応させるために、サービス アップデート後に考慮すべき一般的な手順を以下に示します。

• 更新されたセキュリティの役割を確認する: サービスの更新時に提供されるリリース ノートまたはドキュメントを確認し、標準のセキュリティ役割の変更点を把握します。
• 現在のセキュリティ設定の監査 変更を加える前に、現在のセキュリティ構成を監査し、基本的な権限とアクセス権を把握します。
• サンドボックス環境で変更をテストします: サービスの更新を本番環境以外の環境に最初に適用して、変更がセキュリティの役割とビジネスプロセスにどのように影響するかを確認します。
• カスタム セキュリティ ロールの更新: カスタム セキュリティ ロールがある場合は、新しい標準ロール定義に対応するために、セキュリティ ロールを更新する必要がある場合があります。
• 必要に応じてロールを再割り当てする: 更新後、必要に応じてセキュリティ ロールをユーザーに割り当て直し、適切なアクセスができるようにします。
• 更新後の監視と監査: システムを継続的に監視し、セキュリティ ロールの割り当てを事後更新で監査して、すべてが予期した状態で機能します。