Oracle Cloud Infrastructure Documentation

Security for Public Safety and Security

Use OCI IAM, OCI Identity Domains, Radio authorization, and channel access together to protect Public Safety and Security resources and communications.

Security in the cloud is a shared responsibility between you and Oracle. Oracle secures the cloud infrastructure and operations; you are responsible for securely configuring your cloud resources and protecting the devices that you use with the service.

Securing Oracle Public Safety and Security

Oracle's security responsibilities include:

  • Physical security: Protect the global infrastructure that runs OCI services, including its hardware, software, networking, and facilities. Oracle also provides cloud operator access controls and infrastructure security patching.

Your security responsibilities include:

  • Access control: Give users only the access necessary to perform their work. Configure OCI IAM policies and Oracle Radio permissions for their roles, and review access regularly.
  • Physical security: Limit physical access to devices used with Oracle Public Safety and Security, including mobile devices running Oracle Radio.

Use the following guidance to protect credentials, device registrations, and communications data. For registered Radio application installations, see device management.

Security Layers

  1. OCI IAM policies authorize Public Safety and Security instance and work-request operations.
  2. OCI Identity Domains provides authentication for people and supported clients.
  3. An enabled Radio user and Radio group permissions authorize application operations.
  4. Channel access rules can further constrain visibility, subscription, transmission, and critical messaging.

Credential Handling

  • Public Safety and Security provisions and maintains the authentication applications required for a Public Safety and Security instance. You can't replace them or change their callback, grants, scopes, or offline-access settings by using the Public Safety and Security create or update operation.
  • Keep bearer access tokens out of URLs, logs, crash reports, and persistent browser storage.
  • Do not accept caller-supplied trusted identity headers at a public ingress.
  • Use TLS for REST and secure WebSocket connections.
  • Grant least-privilege OCI and Radio permissions and review them regularly.

Mobile Device Registration

  • A registration QR value is short-lived, intended for one enabled Radio user, and can be used only once. Provide it only to the intended user.
  • The QR value doesn't contain the installed application's callback URI, a client secret, an access token, or a refresh token. It isn't proof of user or device identity.
  • The installed Radio mobile application owns its callback URI. Don't copy a returned callback URI or authorization code into a command, log, crash report, or support record.
  • The client-supplied advertising ID and the Radio device ID identify one application installation. Neither value is a credential or replaces the user's Identity Domain bearer access token.
  • Store mobile OAuth tokens in platform-protected storage. Don't log tokens, authorization codes, PKCE verifiers, registration codes, or QR values.

Communications Data

Apply organizational privacy and retention policy to messages, stored audio, transcripts, presence, notifications, and location information. Limit access to operational history and do not copy sensitive communication content into support tickets unless the approved support process requires it.