Restricting Access for Anonymous Devices

Once you have enabled access for trusted devices – creating secure routes to your applications and data sources on-premise and in the cloud – you can now start to lock down your data sources by preventing "anonymous" device access.

An anonymous device is any device that is not sanctioned by your organization. This includes:

• An attacker's laptop
• A personal iPhone that is not User Enrolled
• A spouse's laptop
• A cafe PC

It is more important than ever to restrict access to trusted devices only, but this is complicated by cloud and remote work where the "on-premise" perimeter has disappeared. Nonetheless, the Trusted Access solution and architecture calls for supporting lock down of all data sources, including on-premise and cloud.

Locking Down On-Premise / Data Center Resources

Many organizations house a significant amount of their sensitive applications and data on servers that are under their direct control and management. These servers are installed in a private facility, or properly secured data center.

Fortunately these applications already exist behind a firewall already, cloaking them from open internal access. However, there are a few things to check:

• Remove any mapped public IPs (within an ISP-issued CIDR range) from the destination server. Servers should only be reachable via Private IP addresses.
  • Remove any 1-to-1 NAT or firewall pinhole exceptions that map connections from a public IP address to the server's internal IP address(es). This is particularly important for risky protocols like HTTP and RDP.
• If the application is particularly sensitive, configure network ACLs (Access Control Lists) either on the server(s) or in LAN to only allow application inbound connections from the Jamf Subnet as defined in your IPSec inteconnect's Encryption Domain settings.

Trusted users and their devices will reach these resources via a Custom IPSec Interconnect Gateway, which will be seamlessly reachable with the Jamf Trust deployed and actviated on their device.

Locking Down Infrastructure as a Service (IaaS) Resources

Infrastructure as a Service is defined as third-party vendor-provided cloud-based services that allow you to run your applications and store your data without having to manage the physical infrastructure itself. The most common IaaS platforms on the market is Amazon Web Services, Google Cloud Platform, and Microsoft Azure.

Restricting access to resources in these environments is actually very similar to On-Premise / Data Center Resources in that resources are generally configured on private virtual networks within the IaaS provider. However, the big difference is that it is much more common for applications and data resources to be made publicly available. Whether on purpose or accident (since it is easy to do!), this overly-open access has been the root cause of many significant hacks in recent years.

Trusted users and devices can reach these resources using any of the following interconnect options:

• AWS Interconnect
• Azure Interconnect
• Custom IPSec Interconnect Gateway
• By restricting inbound access via IaaS access policies from a Jamf Internet Cloud Gateway only, blocking all other connections.
• Configuring AWS Verified Access for macOS to restrict access to managed and compliant devices.

Locking Down Software as a Service (SaaS) Resources

Software as a Service is defined as applications you've purchased but don't own the operation of in any way. Common business SaaS services include Microsoft 365, Salesforce, Slack, Box, and Zoom. There is a good chance your orgnization has at least one SaaS app and it contains some sensitive company data!

However, without any native control of the SaaS app's underlying infrastructure – including network connections – you are at the whim of the SaaS provider to provide (or not provide) access controls that may be used to identify a sanctioned user and device.

There are generally two techniques available to lock down access to SaaS apps: via source IP or the Identity Provider (IdP).

Using Source IP Address

Some SaaS providers allow individual customers to define the source IP address ranges that are allowed to login to their specific customer tenant to access the SaaS application or service. While relatively rare, source IP lockdown is a reliable way to only allow access from devices connecting via the Jamf Private Access infratructure.

You can use Jamf's shared global IP addresses or a public IP on the other side of a Custom IPSec Interconnect Gateway.

A powerful example of this is using Access Client Access Rules to limit Microsoft Exchange connectivity to only Private Access-enabled devices.

Using an Identity Provider

Most SaaS providers support Single Sign On, which uses your organization's Identity Provider (e.g. Okta, Azure AD) to allow or deny access in to that application, instead of relying on a separate set of credentials. While this is great for user identity, SaaS providers rarely provide device access controls.

Fortunately, identity providers do provide support for device-level awareness that we can use to distinguish a sanctioned device from an unsanctioned one.

Via Jamf Source IP

The market's three leading IdPs support defining sign-on access policies that consider source IP address as a criteria for being able to login to a given SaaS app.

Using this critiera, you can use Jamf's cloud IP addresses as a way to identify if an incoming login originated from a device that has Private Access deployed and active. An unauthorized device will not present a source IP belonging to the Jamf Security Cloud, and will therefore be blocked by the IdPs access policy.

For details on configuring this for your IdP, see these guides:

• Okta: Restricting Login Access
• Azure AD: Restricting Login Access
• Google Workspace: Restricting Login Access

You can see what this experience looks like on the BYOD demo video found here.

Via an IdP Endpoint App/Agent

Some IdPs provide endpoint apps/agents that may be used to deliver device identity and authentication as part of the login process. While this method is better than using source IPs, it requires additional deployment and activation considerations and complexities.

• Okta: See Managed Devices and Add an Authentication Policy (specifically using "Device Management" as a criteria).
  • Note: Requires Okta Identity Engine (OIE)
• Microsoft Azure AD: Use Device-based Conditional Access Policies along with Jamf Pro and Microsoft Conditional Access integration

See Enhancing and Securing Logins for details.