AKStream.Next · 文档中心

Complete 6 security tasks before going live

Complete 6 security tasks before going live

This is not a list of security terms. Complete six settings that can be verified in the UI or on the server: administrator, personal accounts, API tokens, HTTPS, network ports, and backups.

See the security boundary first

flowchart LR
    U["Administrator browser"] -->|"HTTPS"| N["Nginx or Kestrel"]
    N --> A["AKStream.Next WebUI / API"]
    A --> D["MySQL"]
    A --> M["MediaServer"]
    C["Camera / NVR"] -->|"ONVIF / SIP / RTSP / RTP"| M
    X["External business service"] -->|"Dedicated API Token"| A

Do not expose every port to the Internet. Apply separate access scopes to management, database, media service API, and camera protocols.

Task 1: protect the super administrator

  1. Sign in with the super administrator created during initial setup.
  2. Confirm that its password is not shared with the database, cameras, or server OS accounts.
  3. Store it in an approved team password manager, not chat, scripts, or browser notes.
  4. Use personal accounts for daily work and reserve the super administrator for security and recovery.

If the administrator password may have leaked, run admin-password reset with the platform management script and confirm that old sessions are invalid afterward.

Task 2: create a personal account for each operator

Open Access Control → Users:

  1. Create one account for each operator.
  2. Bind roles according to job duties instead of granting super administrator to everyone.
  3. Sign in with the new account and confirm it can only see and run permitted functions.
  4. Disable accounts immediately when staff leave or behavior is abnormal, then review Security Audit.

Success means the page can answer “who performed this action” without a shared administrator account.

Task 3: use a dedicated API Token for each integration

Open Access Control → API Token:

  1. Create a token and name its purpose, for example “Recording query service”.
  2. Select only permissions the integration actually needs.
  3. Set an expiration; when the caller has a fixed server, enter allowed IP/CIDR values.
  4. Expand a token to verify every effective permission. Use Edit when its grant, IP range, or expiry must change; the new scope applies immediately without changing the token string.
  5. Copy the full token once and store it in the caller's secret manager.
  6. Confirm creation or update events in Security Audit and revoke this token alone when the integration is retired.

Do not place a super administrator password or long-lived token in browser code, URLs, Git, screenshots, or ordinary logs.

Task 4: configure HTTPS for sign-in and WebRTC

Open System → HTTPS / Certificates:

  1. HTTP is acceptable for a temporary internal trial; public sign-in or browser WebRTC requires HTTPS.
  2. When Nginx already exists, prefer loading the certificate in Nginx and proxying to AKStream.Next.
  3. Enter the domain users really open, not 127.0.0.1 or an address valid only on the server.
  4. Run configuration preview and validation. Nginx configuration must pass nginx -t before reload.
  5. Open the final HTTPS address from another computer and confirm there is no certificate warning and sign-in and WebSocket work.

Success means HTTP is no longer the public management entry and API, WebSocket, and media resources have no mixed-content errors.

Task 5: open only required ports

Port type Who needs access Who should not have access
WebUI/API Management network or HTTPS reverse proxy Unrelated Internet sources
MySQL AKStream.Next business nodes Cameras, ordinary users, and the Internet
MediaServer API/WebHook AKStream.Next and trusted nodes Ordinary clients and public scanners
SIP, RTP, RTSP Planned device networks and upstream/downstream platforms Unrestricted Internet sources
RTC, TURN Real browser user networks Environments that do not use RTC

Compare with Port and firewall reference and the port list generated by initial setup. When a module is disabled, close its firewall entry too.

Task 6: back up and perform one restore check

Back up at least:

  • Config: runtime and node configuration;
  • Data/Security: token, signing, and security material;
  • MySQL: users, devices, channels, recording index, and audit;
  • recording directories according to business retention requirements.

Encrypt backups and restrict access. “Backup job succeeded” is not enough. Restore once into an isolated directory or test instance and confirm configuration, database, and security material come from the same point in time.

Weekly checks

  • Review Access Control → Security Audit for repeated sign-in failures, denied actions, or abnormal token operations.
  • Review System → Logs and Audit for configuration deployment, service restart, and high-risk deletion.
  • Check whether privileged accounts, API tokens, and certificates are near expiration.
  • Confirm that database, Config, and security directories have a new recoverable backup.

If a secret leaks

  1. Identify whether it is an account, API token, device password, database password, MediaServer secret, or certificate private key.
  2. Revoke and rotate only affected material. Do not delete audit logs first.
  3. Review sign-in, denied permission, configuration deployment, device deletion, and recording deletion after the leak time.
  4. After service recovery, verify that old credentials no longer work.

See Backup, restore, upgrade, and rollback for more recovery steps.

Go-live success criteria

  • No shared administrator or default password remains.
  • The public management entry uses valid HTTPS.
  • MySQL and MediaServer management APIs are not exposed to unrelated networks.
  • Every integration has a dedicated, least-privilege, revocable token.
  • A backup has passed a restore test.
  • Security audit can answer who did what and when.