Skip to main content

Assets

Assets represent tenant-scoped devices known to OneProtect.

Implemented:

  • Asset records are created or updated from validated events.
  • Unauthorized device demo assets are visible through API-backed UI panels.
  • Data is tenant-scoped through Postgres RLS in the canonical runtime path.
  • Asset Discovery v1 contracts now define future asset identity, fingerprints, collectors, classifications, telemetry association, and command history.
  • Asset Discovery storage/read APIs now exist for asset lists, asset details, asset timelines, collectors, and command history.
  • A narrow heartbeat ingestion flow can emit asset events, update asset and collector last_seen values, preserve stronger identifiers, and mark unmanaged assets through the existing alert/evidence/audit workflow.
  • The Assets console shows API-backed hostname, classification, lifecycle state, last seen, source confidence, collector, and source type fields when available.
  • Agent enrollment runtime-lite can create tenant-scoped agent identities from bounded enrollment token exchange. The Assets console shows enrolled agent identity status when present.
  • Enrolled agents can now submit runtime-lite heartbeat telemetry that updates agent identity status and the asset read model after validating the stored agent identity.
  • macOS endpoint enrollment posture is supported through the same enrollment and heartbeat path using agent_class=endpoint and platform=darwin; the asset posture is stored as macOS after validation.
  • The asset detail panel shows hardware, network, source, linked alert/evidence, and timeline context from current read APIs.
  • Operators and tenant admins can create an investigation ticket from asset context through the existing ticket API. Auditors see read-only asset detail with mutation controls hidden.
  • Tenant admins and system admins can create and update discovery authorization policies from the Assets console using the existing discovery policy APIs. Operators and auditors see read-only policy/status context.
  • Operators, tenant admins, and system admins can request a browser SSH JIT grant for enrolled SSH-capable assets and open an xterm.js terminal after the gateway reports session_active. The terminal uses the real SSH relay; no fake terminal output, remote desktop, or file-transfer control is shown.

Planned:

  • Standalone Go endpoint agent binary and osquery/Fleet inventory source.
  • OpenTelemetry host telemetry.
  • Production CA signing and enforced agent mTLS.
  • Offline/stale asset policy.
  • Rich asset health and inventory history.
  • Server-derived SSH transcript parsing and object-store recording persistence.
  • Command execution after command contracts and runtime are reviewed.
  • Network scanning, SNMP/WMI runtime, DHCP/ARP/NetFlow ingest runtime, topology mapping, patching, remote shell, and remote desktop remain out of scope for this page today.