Shared Responsibility Model
MyOwnProxy operates the product control plane and MyOwnProxy-managed software. The Customer operates the infrastructure, physical environment, applications, and access assigned to its users and systems.
| Area | MyOwnProxy responsibility | Customer responsibility |
|---|---|---|
| Control plane | Operate product configuration, customer-facing authorization, lifecycle, health/status functions, and supported administration. | Protect user accounts, decide who receives ADMIN or VIEWER access, and review access when responsibilities change. |
| Gateway application software | Provide and manage the MyOwnProxy application-software lifecycle. | Do not replace or modify MyOwnProxy-managed software; coordinate unexpected versions or required recovery with Support. |
| Gateway host and operating system | Provide the supported installation workflow and product-side health reporting. | Provide, secure, size, and maintain the host or virtual machine; manage Ubuntu lifecycle, upgrades, OS security updates, availability, and connectivity. |
| Node application software | Provide and manage the MyOwnProxy Node software lifecycle. | Keep the supported Node hardware available and do not make unsupported persistent software or configuration changes. |
| Supported Node OS maintenance | MyOwnProxy administrators perform supported Node OS security-patch and reboot operations. | Coordinate required access or maintenance windows and verify service afterward. Confirm other OS, firmware, or vendor maintenance with Support. |
| Node hardware and location | Provide product-side Node status and health functionality. | Provide and physically secure the Raspberry Pi, microSD card, power supply, Ethernet, local network, Internet connectivity, and suitable cooling. |
| Customer network and capacity | Operate the MyOwnProxy functions within their supported boundary. | Secure and operate the local network, provide sufficient Gateway and Node capacity and connectivity, and assess destination-access policies. |
| Proxy Credentials | Enforce supported scope, lifecycle, and role controls; display new passwords only in the issuance, creation, or rotation result. | Store passwords securely, limit distribution, configure applications safely, and rotate or revoke persistent credentials when exposure is suspected. |
| Temporary SSH access | Issue short-lived access material to an authorized ADMIN and provide supported emergency Node rescue. | Protect the SSH private key and issued material, use the privileged session only for intended work, and close it promptly. |
| Applications | Provide supported SOCKS5 Pool and direct Node entry points. | Configure the correct endpoint and credential, protect application secrets, and implement retry, reconnection, and failure handling appropriate to the workload. |
Gateway and Node OS distinction
The Customer manages the Gateway operating system, including Ubuntu upgrades and OS security updates. MyOwnProxy manages only the MyOwnProxy application software installed on that Gateway.
For Nodes, MyOwnProxy administrators perform the currently supported OS security-patch and reboot operations. This does not mean every Raspberry Pi operating-system, firmware, or vendor update is automatically covered. Confirm work outside the supported Node maintenance workflow with MyOwnProxy Support rather than applying an unapproved change.
See Software Updates, Gateway Software Updates, and Node Security Patches and Reboots for operational procedures.
Temporary SSH access boundary
An ADMIN supplies only an SSH public key when requesting temporary Node access; the corresponding private key remains with the Customer. The submitted public key is used for that request and is not saved as a reusable customer key. The issued certificate is returned in the current result, and the portal does not provide certificate history. MyOwnProxy retains administrative audit information about the issuance, such as the actor, Node, time, duration, and certificate fingerprint, rather than the submitted public key or issued certificate.
Certificate expiration prevents new SSH authentication after the displayed Valid Before time but does not close a session that is already connected. The portal provides no early revocation, and multiple certificates or sessions can overlap. Treat the resulting Node session as highly privileged, use the shortest practical duration, and close it promptly. See Accessing Your Nodes Remotely for the full workflow.
Security incident actions
- If a persistent Proxy Credential password may have been exposed, rotate it or permanently revoke it and update affected applications.
- If a temporary Proxy Credential may have been exposed, stop using it and create a replacement. The earlier credential remains usable until its displayed expiration.
- If SSH material may have been exposed, stop using it and contact MyOwnProxy Support. The portal does not provide early certificate revocation.
- If Node provisioning material, a prepared microSD card, or a physical Node that is still in PENDING_ENROLLMENT is lost, stolen, exposed, or suspected compromised, an ADMIN should permanently remove the affected Node. Do not wait for pending Node provisioning to expire. If a Node is still needed, create a new Node and prepare it with new provisioning material.
- If Gateway enrollment material may have been exposed, stop using it and follow Installing a Gateway or contact MyOwnProxy Support. Gateway enrollment remains time-limited and is separate from Node provisioning.
- If a customer user account or Customer infrastructure may have been exposed, limit access through the controls you manage and contact MyOwnProxy Support for product-side assistance.
See Contacting Support before sharing diagnostic information.