Publishing a service does not start with port forwarding. It starts by naming an owner, a business purpose, and a person authorised to accept the risk. This procedure covers web applications, partner portals, APIs, and other company services. It is not an instruction for actively testing systems owned by others.
1. Name the owner and purpose
The business owner describes who uses the service, why they need it, required availability, and the impact of downtime or data disclosure. The technical owner is responsible for configuration, patching, logs, and recovery. The approver makes a documented launch decision. One person may hold several roles, but no role may remain implicit.
Record the domain, public address, provider, protocol, and owners in the internet exposure worksheet. “Needed remotely” is not sufficient: identify the users, function, and expected publication period.
2. Confirm scope and authorisation
Verify that the team has approval to change DNS, firewall, cloud, and the target system. Scope should list the environment, names, addresses, ports, providers, and schedule. Separately record what must not be published: the administration interface, database, file shares, hypervisor console, or test environment.
If the service handles personal data, payments, or contract-controlled information, obtain the appropriate legal or compliance approval. Perform tests only against company assets or assets covered by explicit authorisation.
3. Choose the architecture
Draw the flow: client, DNS, edge layer, service, dependencies, and administration path. Place the public component in a separate zone. Network segmentation limits permitted connections between zones, while isolation reduces the number of components that can be compromised through one account or failure.
Choose the narrowest suitable option:
- A reverse proxy fits a public HTTP/S application. It centralises TLS, headers, rate limits, and logs, but it does not fix a vulnerable application.
- A VPN is appropriate when a closed user group needs access and full public availability is unnecessary. It requires maintained clients, identities, and endpoint devices.
- An access gateway provides a controlled entry point, per-application policies, and often MFA. It increases dependence on the gateway or provider.
- Direct publication is an exception that requires justification. Do not directly expose RDP, SSH, or administration panels. For remote desktops, apply the guidance in Internet-facing RDP is not a remote-work plan.
4. Configure the controls
Use a central identity provider when the service supports one. Require MFA at least for administrators and access to sensitive data; prefer phishing-resistant methods. Service accounts should not permit interactive login. Separate administration accounts from ordinary accounts and restrict roles to required actions.
Open only the required protocol and port to the specific destination. Restrict sources when recipients use known networks. Block management interfaces from the public side. Rules for outbound traffic and database connections must also be explicit rather than “any”.
Use TLS for every path carrying data or credentials. The certificate must match the name, have a monitored expiry date, and have automatic renewal tested before launch. Enforce current protocols and a safe redirect from HTTP if HTTP is needed at all.
Patch the operating system, application, container images, proxy, and edge devices. Record versions and the next maintenance window. Store secrets in a dedicated vault or secure configuration, not in the repository, image, or script. Give each secret minimal scope, a rotation process, and an owner.
5. Prepare observability and recovery
Log at least successful and failed sign-ins, MFA use, permission and configuration changes, application errors, and proxy or gateway decisions. Synchronise clocks. Restrict access to logs and define retention. Each alert needs a recipient and response: unavailability, an increase in errors, unusual denials, a privileged-account change, loss of a log source, and approaching certificate expiry.
Back up data and configuration, then verify recovery. The rollback plan must explain how to restore the previous version, DNS, and rules without losing administrative access. Define stop criteria for the launch, such as authentication errors, missing logs, or a failed recovery test.
6. Pre-launch checklist
- Owners, purpose, users, scope, and approver are recorded.
- The architecture and inter-zone flows are approved.
- Only required names, protocols, and ports are public.
- MFA, least-privilege roles, and separate administration are verified.
- TLS, certificate renewal, versions, and the patching process are ready.
- Secrets are absent from code and images.
- Logs reach the agreed destination, and alerts have an owner.
- Backup, recovery, and rollback have been verified.
- A functional test was completed from an allowed external network.
- The business owner and authorised approver accepted the launch.
Support for architecture and scope verification is described in the network security, security assessment, and system administration services. The network security lab demonstrates a technical approach.
7. Launch and change record
Launch during the agreed window with the technical owner available. The launch record should include the date and time zone, change number, implementer and approver, deployed version, domains, addresses and ports, test results, dashboard links, and the “keep” or “roll back” decision. After launch, observe the service for the agreed period and close the change only after confirming logs, alerts, and the business function.
8. Review and decommission
At least quarterly, and after an incident or material change, reconfirm the owner, business need, users, roles, MFA, versions, certificate, rules, dependencies, alerts, retention, and recovery effectiveness. Every exception needs a rationale, an approver, and an expiry date.
When the service is no longer needed, announce the date, archive required data and evidence, revoke accounts and tokens, invalidate secrets and certificates, remove rules, DNS records, and cloud resources, and retain monitoring for the agreed period. Finally, update the exposure worksheet and record evidence that the name and address no longer lead to an abandoned service.