ガバナンスと保持

現在、保持はサービスによって管理されます

現在のMeGovernanceResponseはretention.status=operator_managed、retention.available=falseを報告します。アカウントごとの自動保持ルールは設定できません。archive、forget、clearの操作には明示的なアカウント操作が必要です。このページは実装済みの方針を説明するもので、自動保持スケジュールを約束するものではありません。

{
  "retention": {
    "status": "operator_managed",
    "available": false
  },
  "delete": {
    "status": "self_service",
    "available": true
  }
}

削除とエクスポートには別々の方針があります

個別メモリの削除はself-serviceで行えます。アカウントを閉鎖するとアクセスを取り消し、Personal purge workflowをキューに入れます。response contractでは、teamで共有されたデータはTeamに残ると定めています。エクスポートは、runtime configurationに応じてself-service downloadまたはrequest-onlyとなり、準備済みartifactは自動的に期限切れになります。

• delete — 個別メモリのself-service削除が利用できます。
• export — runtimeが有効にした場合だけstatusはself_service_downloadとなり、それ以外はrequest_onlyです。
• data_boundary — アカウント単位です。アカウントをまたぐアクセスは許可されません。

ガバナンス操作は監査証拠を残す

ガバナンスresponseはaudit.status=enabledを報告し、アカウント操作がaudit eventを発生させると説明します。audit-logへのアクセスとself-service audit exportは、引き続きサービスチームが管理します。メモリ削除も、忘れられたcontentを公開結果に残さず、mode、reasonの有無、target referenceをmemory audit outboxに記録します。

{
  "data_boundary": {
    "status": "account_scoped",
    "available": true
  },
  "audit": {
    "status": "enabled",
    "available": true
  }
}

modeを選ぶ前に有効な方針を確認する

Security modeとガバナンス方針は別の制御です。Cloud modeではserver-side processingが可能です。Keyguardは監査付きの一時復号とcustomer key wrappingを使います。Vaultはメモリ本体をclient-encryptedで保ち、通常はlocal recallを必要とします。保持、削除、security handlingは、3つすべてを1つの設定が制御すると仮定せず、現在のresponse contractに基づいて選択してください。

retention  = operator_managed
delete     = self_service
audit      = enabled
security   = resolve the effective Cloud, Keyguard, or Vault mode