What’s the safest way to publish internal web apps to managed and BYOD mobile devices?

0
5
Asked By MellowCedar42 On

We have a growing collection of internal web apps, developed quickly with AI coding tools, so we assume the application code may contain ordinary security mistakes and should not be trusted as the only security boundary. The apps currently run in Docker containers on-premises, with a future move to Kubernetes, and already use Entra ID through OIDC for single sign-on. Users need mobile access from a mix of Intune-managed devices and unmanaged BYOD devices, so the solution must work from a mobile browser or through a custom app without requiring agents or certificates on every personal device.

Our network has a firewall, a DMZ, and a load balancer with a WAF. We have Microsoft 365 E5 licensing, but would prefer to keep application traffic within our own infrastructure instead of sending it through a third-party cloud proxy. The team is small, so low operational overhead matters. How would you design the overall solution, including pre-authentication, network segmentation, access controls for unmanaged devices, and protection against flaws in the applications themselves? Practical experiences and approaches that failed are welcome too.

5 Answers

Answered By BriskOtter7 On

I’d put an identity-aware reverse proxy or ZTNA gateway in front of everything and make sure the applications are never directly reachable. The gateway should authenticate the user before forwarding any request, enforce Entra-based access policies, and ideally apply MFA and device or risk conditions where available. That way, a vulnerable app is not responsible for deciding whether an unauthenticated request should be allowed. Keep the containers on private network segments, allow the proxy to reach only the specific app backends it needs, and still treat authorization inside each application as necessary defense in depth.

Answered By QuietLynx29 On

A mesh VPN with subnet and service-level segmentation is another practical option. You can keep the applications completely off the public internet and publish only the required HTTPS services through the VPN layer. This works well when the organization is comfortable with users opening a browser through a managed access path, but BYOD usability and onboarding need careful testing. I’d avoid relying on a memorable VPN URL as a security control; use proper identity policies, short-lived sessions, logging, and a clear separation between user access and administrative access.

CopperVale88 -

The main concern with this approach is user friction. If the workforce is not very technical, requiring a VPN client or special access flow on personal phones can create a support burden, so a browser-only identity proxy may be easier.

Answered By AmberQuill63 On

A cloud access gateway or tunnel is usually the simplest operationally. It can publish internal services without inbound firewall exposure and apply Entra authentication before traffic reaches the applications. The tradeoff is that requests pass through a third party, which conflicts with your stated preference and introduces another dependency, so I’d treat it as a deliberate exception rather than the default. If you choose this route, review data processing, logging, outage behavior, vendor access, and whether the licensing and free-tier terms are appropriate for production.

Answered By SageNimbus51 On

If keeping the traffic on-premises is the priority, use the existing DMZ load balancer and WAF as the public edge, but add a dedicated pre-authentication layer rather than forwarding directly to the apps. Put the proxy and WAF in the DMZ, keep application containers on isolated internal networks, and permit only narrowly defined east-west flows. For BYOD, authenticate with Entra ID and enforce MFA, session timeouts, conditional access, and restrictions on downloads or copy/paste where the tooling supports it. Managed devices can receive stronger device-compliance policies, while unmanaged devices should get a more limited access profile.

Answered By VelvetMaple16 On

Whatever edge design you choose, don’t assume pre-authentication makes unsafe code safe. Run the apps with least-privilege service accounts, isolate namespaces and workloads, restrict outbound traffic, keep secrets outside images, scan dependencies and container images, and add centralized logging and alerting. Test for broken authorization, IDOR, injection, SSRF, insecure file handling, and overly broad API permissions. The gateway should reduce exposure, but each application still needs its own authorization checks because users may be authenticated yet not entitled to every function or record.

Related Questions

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.