Skip to main content

​
Network segmentation

Resources in each OroCloud environment are isolated in a dedicated GCP project or OCI subtenancy, providing complete resource segregation per instance. The production network is divided into two subnets:
  • Application subnet — All nodes running Oro application components and storing production data.
  • Maintenance DMZ subnet — Reserved for the VPN gateway node used for maintenance purposes.

​
Application subnet

All nodes that run Oro application components and store production data reside in the application subnet. The incoming traffic rules differ by CDN configuration:
  • No public IP addresses are directly connected to the application subnet. The only publicly accessible IP address points to the Google load balancer.
  • The Oro application web server accepts connections only from this load balancer via port 80 (HTTP) and port 8080 (WebSocket).
  • The load balancer terminates all HTTPS traffic.
The following rules apply for all CDN configurations:
  • Nodes in the application subnet accept connections only to service-specific ports originating exclusively from the application subnet.
  • Outgoing public traffic is remapped by the NAT node with a public IP address. This IP address can be added to external whitelists to control outgoing traffic.
  • The NAT node does not accept any incoming connections on its public IP interface.
  • Only the bridge host can connect to nodes in the application subnet. The bridge host has two network interfaces: one connected to the application subnet and one to the maintenance DMZ subnet.
  • OroCloud support team accesses the application subnet via SSH for maintenance.

​
Maintenance DMZ subnet

The maintenance DMZ subnet is reserved exclusively for the VPN gateway node. It shields the application subnet from external attacks while reducing the risk of a web-facing node being compromised. The OroCloud support team or your authorized IT support accesses the VPN Gateway via a secure OpenVPN connection. OpenVPN uses multi-factor authentication to protect information transferred between the client workstation and OroCloud resources.

​
Traffic and firewall rules

In the application subnet, incoming traffic is allowed via:
  • From the load balancer or Cloudflare tunnel: see the respective port information in the CDN sections above.
  • From the OpenVPN bridge: ICMP and port 22
Traffic that stays within the network and outgoing traffic are not restricted. For network information protection, outgoing traffic is remapped via the NAT node. In the maintenance DMZ subnet, incoming traffic is allowed only from the OpenVPN bridge via UDP on port 31194. Traffic within the network and outgoing traffic are not restricted.

​
Connecting via VPN

The OroCloud support team provides individual maintenance access (using SSH2 protocol) via VPN to the production instance hosts for your company’s authorized IT support.
Do not share access credentials. Sharing credentials violates information security best practices and standards, including PCI-DSS.
To gain VPN access, submit a request to the Oro Inc. Support Desk. See Connect OroCloud VPN for OS-specific setup instructions.

​
DDoS mitigation

Cloudflare and Google Cloud Platform both provide tools to prevent and defend against DDoS attacks.

Shared security responsibility

Best practices and the shared responsibility model for OroCloud security.

PCI DSS shared responsibility

Understanding the shared responsibility model in PCI DSS v4.0.1.

Build docs developers (and LLMs) love

Get started for freeTalk to us