Skip to main content

Server-side security

This article addresses aspects of security requirements for the backend part of the AosEdge system. It covers the following aspects:

  • Security requirements
  • Suggested deployment and networking approach

The following roles were identified:

  • Unit: a regular unit that uses the service
  • Vendor: producer of units that has responsibility for the unit functionality
  • Service Provider: unit department or external company that develops services, that might be installed in units
  • Support: EPAM or vendor team that monitors, support and troubleshoot issues
  • Deployment: service user or CI/CD pipeline that run update scripts
  • Admin: admin users that has access to the part of the system
  • The table below describes how access should be limited to different roles.

Suggested deployment and networking approach​

Logical level

See the logical deployment diagram below.

The AosEdge system must be cloud-agnostic. All cloud-specific functions can be implemented by request.

The picture above shows a system deployment common approach. This approach includes public DMZ to interact with units and users via the internet. Each public DMZ should be separated. This allows for minimizing any consequences in case of a security breach in the public areas.

Service discovery may use different instances in different geographical regions with DSN based load balancing. Such an approach allows minimizing network latency and improves accessibility. The same approach may be used for AosCloud and backend API.

The CDNs used for delivering containers and updates should have read-only access and time-based tokens for access.

The internal subnet incorporates the most valuable components of the solution. DMZs have limited (whitelisted) access to the internal subnet and should not allow communicating different services with each other. It will allow us to restrict access to needed information only and minimize the impact of possible unauthorized access to the whole system. It is suggested to limit access to exposed endpoints and use VPN or IP addresses whitelists/trusted internal networks whenever possible. In any case, all communications must use TLS or mutual TLS if possible.