Policy Acknowledgement Policy Acknowledgementは、SharePointのポリシーハブに運用データを保存します。記録モードは、通常の従業員の確認を書き込む方法を決定します。ソリューションのデータを別のストレージサイトに移すものではありません。
ハブに保存するもの
| リストまたはライブラリ | 用途 |
|---|---|
Policies | ポリシーカード、現在のバージョン、閲覧条件。 |
PolicyVersions | バージョンのメタデータと、対応している場合のドキュメントスナップショット。 |
PolicyCategories | カテゴリとその確認文。 |
PolicyCampaigns | 対象者の定義、期限、リマインダー設定。 |
PolicyAssignments | 従業員への割り当てと現在の状態。 |
PolicyAcknowledgements | ハッシュで連結された確認とその他の証跡イベント。 |
PolicyQuestions | 従業員の質問、理由、回答。 |
PolicyNotificationLog | 通知ログの保存先。 |
PolicyAuditLog | 管理とワークフローのイベント。 |
PolicySettings | 製品の設定。 |
PolicyRoleAssignments | ロールとグループの対応付け。 |
ソースドキュメントは設定されたURLに残ります。同一オリジンのドキュメントを公開するとPolicyVersionsにスナップショットを保存できる場合があります。外部ソースにはそのようなスナップショットやコンテンツハッシュは作成されません。
記録モードを比較する
| 項目 | Direct | Service |
|---|---|---|
| 通常の確認の書き込み | Webパーツが従業員のセッションでSharePointに書き込みます。 | Webパーツが接続されたサービスに確認を送信します。 |
| ロールマトリックスの従業員権限 | 割り当てと確認への投稿権限。 | この二つのリストへの読み取り権限。 |
| この書き込みに別のサービスが必要か | いいえ。 | はい。動作するエンドポイントと同意が必要です。 |
| 自動リマインダーと対象者の更新 | Directモードには含まれません。 | 接続されたサービスの実装と稼働に依存します。 |
既定の設定はDirectモードです。Serviceを選択してもサービスはインストールされず、すべての動作が検証されるわけでもありません。
モード変更を設定して検証する
- Policy Adminで通知を開きます。
- Serviceモードでは、リマインダーサービスURLを入力し、管理者同意を開いて同意の確認を実行します。
- 閲覧確認の記録方法で必要なオプションを選択し、保存します。
- 役割を開いて保存して権限を適用するを選択します。
- SharePointの実効権限を確認し、別の従業員アカウントで確認をテストします。
モード設定を保存しても権限は自動で再適用されません。ServiceモードにURLまたは確認済みの同意がない場合、閲覧画面は通常の送信をブロックします。その後サービスが停止した場合は、送信エラーとして報告されます。
アプリ内でレコードの流れを追う
カード、割り当て、確認は別々のレコードです。カードは現在のポリシーを説明し、割り当てはバージョンとキャンペーンに対する個人の作業を識別し、確認は証跡イベントを記録します。受領証は証跡の一部フィールドを表示します。送信成功後は通常これらが一致しますが、不可分の単一オブジェクトとして扱うべきではありません。
直接経路では、アプリが前のハッシュを読み、確認を追加し、割り当てを更新します。サービス経路では、設定されたエンドポイントにペイロードを送り、生成されたレコードを取得します。先の書き込みが成功しても、その後の読み取りや更新が失敗する場合があります。このため、従業員に再試行を求める前に、割り当ての参照と証跡レコードを比較して調査します。
記録モードの変更は通常の確認の経路を変えるもので、すべてのポリシーデータの場所やすべての管理操作を変えるものではありません。過去のイベントを新しい証跡モデルに書き換えることもありません。元のレコードを保持し、展開の有効権限とサービス動作が意図する保護要件をどう支えるか確認します。
モード変更に必要な確認を分ける
| 確認 | 検証すること |
|---|---|
| 構成 | 保存モード、エンドポイント、同意状態が目的の設定に一致する。 |
| 権限 | 製品マトリックスが再適用され、実際のリスト権限が確認された。 |
| 従業員の確認 | 代表的な従業員が送信して正しい受領証を取得できる。 |
| 割り当ての照合 | 対応する割り当てに期待する状態と証跡参照がある。 |
| 例外ワークフロー | 権限のある操作担当者が、使用する場合は別の免除経路も含めてテストケースを解決できる。 |
| バックグラウンド処理 | サービス所有者が必要な定期ジョブと配信動作を実証できる。 |
本番のロールを代表するアカウントで確認します。同期管理者だけでテストすると、そのアカウントに残る追加のフルコントロール付与を見落とす可能性があります。同様に、同意応答の成功は、サーバー側のすべての書き込み、予定処理、配信が健全なことを確定しません。
整合性を保護の一部として解釈する
ハッシュチェーンはレコードをリンクし、変更されたレコードや特定の欠落レコードが不一致を生むようにします。存在すべきすべてのものの独立した信頼できる台帳を提供するわけではありません。チェーン末尾の削除や全体の置き換えを検出するには、他の制御や保持された証跡が必要な場合があります。そのため、緑の表示は、読み込まれたチェーンが実装された整合性チェックに合格したことを意味します。
整合性結果は権限、ソースとバージョンの証跡、運用記録と合わせて使います。レコードハッシュの一致は、リーダーがアーカイブファイルを表示したこと、必要な従業員イベントがすべて存在すること、従業員が文言を理解したことを証明しません。不整合を見つけたら、修正前に識別子と元データを保持します。KB10533. 確認ログの整合性を検証する方法とKB10538. 確認の失敗と通知が届かない問題を解決するを参照してください。
証跡保護の限界を理解する
証跡イベントには、識別情報、ポリシーとバージョンの情報、タイムスタンプ、確認文、閲覧条件のデータ、ハッシュが含まれます。アプリケーションはレコードのハッシュチェーンをチェックして不整合を検出します。これは絶対的な不変性の保証ではありません。
❗ 重要
画面ではServiceモードは管理者を含めて直接書き込みを防止すると説明されていますが、現在の権限同期コードは、同期するアカウントのフルコントロールを維持します。昇格された権限や既存の権限も確認する必要があります。Directモードは従業員に投稿権限を付与し、マトリックスは従業員ごとにレコードを分離しません。すべての証跡が技術的に変更不可能であるとか、Webパーツのフィルターがレコード単位のセキュリティを提供するといった主張はしないでください。
免除イベントは現在、ServiceモードでもSharePointへの直接書き込みを使用します。この経路では、文書化されたマトリックスの権限だけを持つコンプライアンス管理者の操作が失敗する場合があります。KB10507. ポリシーの質問に対応し、従業員を免除する方法を参照してください。別のサービスの実装はWebパーツのプロジェクトに含まれていないため、そのアプリケーション権限、バックグラウンド処理、保護の仕組みは実際の展開で検証する必要があります。
