注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
プライバシーと市民的自由の原則は、組織がシステムのライフサイクル全体を通じて、意思決定、プロセス、技術的な制御に落とし込むことで意味を持ちます。まず、ワークフローの目的と、その目的を達成するために必要なデータを定義します。誰にアクセス権を付与すべきか、どの意思決定に人によるレビューが必要か、いつデータを保持または削除するかを明確にします。
このページで紹介する機能は、組織独自のポリシーと責任を実践に移すうえで役立ちます。これらの機能は、利用が適法、必要、または相応であるかを判断するものではなく、法律、規制、ポリシーへの準拠を保証するものでもありません。組織のデータ所有者、およびプライバシー、法務、コンプライアンス、セキュリティ、ガバナンスの各チームと連携し、適切な制御を選択して維持してください。
比例性とは、ワークフローでのデータ利用とその影響が、正当な目的に照らして適切かを問うものです。最小化とは、収集、アクセス、利用、保持を、その目的に必要な範囲に絞ることです。データを取り込む前にこれらの原則を検討し、ワークフローや目的が変わったときに再検討します。
Sensitive Data Scanner を使用すると、組織固有の機密性の定義に一致するデータを特定する際に役立ちます。マーキングとプロジェクトロールを使用して、一元管理された適格性基準とプロジェクトでの責任に応じてアクセスを制限します。ワークフローで直接識別子が不要な場合は、Cipher を使用して、ハッシュ化や暗号化など、プライバシーを強化する暗号学的変換を適用します。
これらの制御が最小化に役立つのは、どのデータとアクセスが必要かについて慎重に検討した判断が、その設定に反映されている場合に限られます。検出、制限、難読化は、その判断の代わりにはなりません。
製造チームが、設備の保全が必要になる時期を予測する Pipeline Builder ワークフローを作成します。ソースのレコードには、機械のテレメトリー、作業指示のメモ、技術者の連絡先情報が含まれています。チームは Sensitive Data Scanner を使用して機密フィールドを特定し、連絡先情報は予測ワークフローに役立たないため削除します。また、生データセットにマーキングを適用する一致アクションを設定します。繰り返し発生する保守作業のパターンをワークフローで認識する必要がある場合は、Cipher を使用して技術者の識別子を一貫した値にハッシュ化します。
比例性と最小化を早い段階で適用すると、機密データがモデル、アプリケーション、下流のデータセットに伝播する前に、どのフィールドが必要かをチームが判断しやすくなります。この分析とそれを支える制御がなければ、予測ワークフローの改善に寄与しないにもかかわらず、技術者の連絡先情報が下流のアセットにコピーされる可能性があります。こうして作成されたワークフローは、有用な保全の兆候を保持しつつ、不要な収集とアクセスを減らします。
目的の限定は、データの収集、アクセス、利用を、具体的かつ正当な目的に結び付けるものです。アクセス権を付与する前に許可する目的を定義し、目的が終了または変更されたときに権限を再評価します。
Checkpoints では、機密性の高いインタラクションの前にユーザーに理由の入力を求め、その記録をレビュー用に保持できます。Approvals では、変更やアクセスのリクエストを指定されたレビュー担当者に回すことができます。そのうえで、マーキングとプロジェクト権限により、組織が定めたアクセス境界を適用できます。これらの機能を組み合わせることで、承認されたリクエストがあらゆる目的に適切であるとみなすことなく、ポリシー、理由、レビュー、アクセスを結び付けられます。
業務チームが、仕入先の納入記録を計画システムに送信する Data Connection エクスポートを作成します。チームは、エクスポートを納入予測に必要なフィールドに限定し、プロジェクト権限を使用して設定できるユーザーを制限します。また、エクスポート用プロジェクトへのアクセス権のリクエストを Approvals に回します。ユーザーが Workshop の計画アプリケーションから詳細な仕入先オブジェクトをエクスポートする場合、Checkpoint によって、そのエクスポートを必要とする配送または計画タスクの記録を求めることができます。
目的の限定を適用すると、データを共有する前に許可する目的を定義し、新しい受信者、フィールド、利用について再レビューが必要になるタイミングを特定しやすくなります。こうした境界がなければ、その後の変更により、改めて精査されることなく、既存のエクスポートに無関係なフィールドや受信者が追加される可能性があります。承認は、ある時点での判断を記録するものであり、将来の無関係な利用を許可するものではありません。
アクセスガバナンスには、ある種類のデータを扱う適格性と、特定のワークフローにおける担当者の役割の両方を反映する必要があります。最小権限のアクセスを適用し、可能な場合はグループを使用して、責任の変更に応じてアクセスを見直します。
マーキングは、保護されたリソースと派生データに引き続き適用される強制アクセス制御を提供し、プロジェクトロールと権限は、プロジェクト内のアクセスを管理します。Approvals では、アクセス権のリクエストのワークフローに人によるレビューを組み込めます。Compass は、リソースをプロジェクトに整理し、リソースの所在を把握して、ガバナンスの適用されたワークフローを通じてアクセス権をリクエストする際に役立ちます。
単一の権限モデルで組織のポリシーが定まるわけではありません。データ所有者と管理者は、強制アクセス制御、ロール、グループ、プロジェクトの境界、レビュープロセスのどの組み合わせが適切かを判断する必要があります。
施設管理チームが、建物の収容能力データと仕入先契約を組み合わせた Workshop アプリケーションを作成します。ほとんどのユーザーに必要なのは拠点単位の集計値ですが、より少人数の契約チームには詳細な取引条件が必要です。チームは契約リソースにマーキングを適用し、プロジェクトロールを使用してアプリケーションの作成者と閲覧者を分離し、Compass に所有者を記録します。例外的なアクセス権がリクエストされたときには、Approvals がレビューの機会を設けます。
適格性とワークフロー固有の必要性を分けることで、契約データへのアクセス権を誰に付与すべきかをチームが判断しやすくなります。基になるリソースに個別の制御がなければ、施設管理アプリケーションへのアクセスによって、すべての閲覧者に詳細な契約条件が公開される可能性があります。こうした制御により、広範なアプリケーションへのアクセスが、基になるすべてのリソースへの広範なアクセスにつながることを防ぎます。
プライバシーを強化する変換では、直接識別子を置き換えたり、元の値を利用できる場面を制限したりすることで、データの露出を抑えられます。ワークフローの目的、再識別のリスク、権限に基づく復元が必要かどうかに応じて、手法を選択します。
Cipher は、運用ワークフローでのハッシュ化、暗号化、管理された復号をサポートします。これらの変換をアクセス制御やガバナンスプロセスと組み合わせ、データを変換または開示する権限が、定義された責任と目的に対応するようにします。値を変換しても、データが自動的に匿名化されたり、プライバシーリスクがなくなったりするわけではありません。
サポートチームは、サービス記録全体で繰り返し発生する問題を分析するため、Pipeline Builder でパイプラインを作成します。アナリストは、同じアカウントに関連する記録をグループ化する必要がありますが、アカウントの直接識別子は必要ありません。このパイプラインでは、Cipher を使用して各識別子を一貫したハッシュ値に置き換えます。一方、元の記録は、権限を持つ担当者がフォローアップできるように、アクセスを制限したプロジェクトに保持されます。
プライバシーを強化する変換を早期に検討することで、チームは、安定した識別子が必要かどうかを判断し、ほかのフィールドから依然として個人の属性が明らかになる可能性がないかを評価できます。変換しなければ、アカウントの直接識別子が、それを必要としない人が使用する派生分析やエクスポートにまで広がるおそれがあります。難読化によって露出は抑えられますが、チームは、変換後のデータセットへのアクセスと、そのデータセットをソースに再び結び付けられるすべてのプロセスを引き続き管理する必要があります。
人間の主体性と監督は、重大な影響を伴う操作を引き続きレビューできるようにし、指定された意思決定者が、提案された方針に疑問を呈し、承認、拒否、変更できるようにするために役立ちます。人間の判断が必要な箇所を特定し、レビュー担当者が実質的な判断を下せるよう、十分な背景情報を提示します。
Approvals は、変更が適用される前に、適格なレビュー担当者に変更を回付します。Checkpoints は、機密性の高いインタラクションを中断し、理由の入力や確認を求めることができます。承認や確認を形式的な手続きとして扱うのではなく、実質的なレビュー基準と明確な責任の所在に基づいて、これらの機能を設定します。
AIP Logic 関数は、機器のテレメトリーとサービス記録を分析し、オントロジーで表現される保守スケジュールを変更するアクションを提案します。Automate は、機器の状態が変わると関数を実行し、人間によるレビューに向けた提案としてアクションをステージングします。保守計画担当者は、提案を受け入れるか拒否する前に、裏付けとなる情報とエージェントの判断ログを確認できます。計画担当者が代わりに Workshop アプリケーションから手動でスケジュール変更アクションを実行する場合は、Checkpoint で理由の記録を求めることができます。
人間の主体性と監督の原則を適用することで、チームは、人間の判断が必要なアクションと、レビュー担当者に必要な背景情報を特定できます。アクションの適用前にレビューを行わなければ、誤った提案や裏付けが不十分な提案によって、保守作業が自動的に変更され、業務に支障が生じるおそれがあります。人間によるレビューが意味を持つのは、レビュー担当者に、結果を変更するための十分な情報、権限、時間がある場合に限られます。
説明責任を果たすには、組織がワークフローの責任者を定め、レビュー、調査、改善を支える記録を保持する必要があります。ガバナンス上の決定を文書化し、制御が意図どおりに機能しているかを監視し、問題に対応するプロセスを確立します。
監査ログは、Foundry 全体の操作の記録を提供し、ユーザーはそれを監視、分析できます。Audit Explorer では、レビュー担当者が監査ログを検索、レビューできます。また、検索のたびにログを記録するため、レビュー担当者自身による監査データの使用も監査できます。送信された Checkpoint にはユーザーが入力した理由が記録され、Approvals で完了した申請には提案された変更に関する決定が保存されます。Compass は、わかりやすいプロジェクトとリソースの構造を提供し、チームが所有関係を把握し、ガバナンスの対象となるリソースを管理するのに役立ちます。
記録だけでは説明責任は果たせません。組織は、どのイベントをレビューするか、誰がレビューを実施するか、どの頻度で実施するか、アクティビティがポリシーに反する場合にどう対応するかを決める必要があります。
ある組織では、Workshop アプリケーションを使用して契約をレビューし、契約ステータスのアクションを実行します。Compass でプロジェクトの所有者を特定でき、送信された Checkpoint には契約のエクスポートとアクションの実行に関する理由が記録され、監査ログには権限の変更やオブジェクトのエクスポートなどのアクティビティが記録されます。ガバナンスチームは、定められたスケジュールに従って Audit Explorer で関連イベントをレビューし、プロジェクトで明示された目的に合わないアクティビティを調査します。
説明責任の原則を適用することで、組織は、どのイベントが重要か、誰が確認すべきか、確認結果をどのように対応につなげるかを決められます。所有関係とレビューが定められていなければ、不適切な権限変更やエクスポートが Foundry に記録されていても、見過ごされるおそれがあります。このアプローチは、説明責任のプロセスに必要な量を超えて監視データを収集、保持することを避けるうえでも役立ちます。
保持と削除のポリシーには、データを保持する目的、適用される義務、データシステム全体にわたる削除の影響を反映する必要があります。これらの要件を早期に定義し、目的が変わったときに見直すとともに、派生コピーも考慮します。
Data Lifetime では、組織がデータセットとその派生データに対して、リネージを考慮した保持ポリシーを設定できます。Compass は、リソースのゴミ箱への移動やプロジェクトの管理など、リソース管理のワークフローをサポートします。これらの機能は、ポリシーの責任者を割り当て、対象範囲を検証し、必要な記録を保持し、結果を確認する、より包括的な保持プロセスの一部として使用します。
あるチームは、期間を限定した保証調査のために、機器の診断情報、サービス記録、派生分析を組み合わせる Compass プロジェクトと Pipeline Builder ワークフローを作成します。作業を開始する前に、データの所有者が生データと派生データの保持期間を定義し、異なる保持期間を必要とする記録を分離します。Data Lifetime は、データセットのリネージに沿って選択された削除ポリシーを適用し、Compass でプロジェクトの所有者を特定でき、監査ログはポリシー変更のレビューを支えます。
保持と削除を早期に計画することで、チームは、無期限の保持がデフォルトになることを避け、プロジェクトが終了する前に下流のコピーも考慮できます。リネージを考慮したポリシーがなければ、一時的な生データと派生データセットが、調査終了後も長期間にわたって利用可能なままになるおそれがあります。チームには引き続き、ポリシーの適用範囲、削除の結果、必要な記録の保存を確認するプロセスが必要です。
機密データとガバナンス上の責任に関する詳しいガイダンスについては、データ保護とガバナンスを参照してください。