Our organization recently undertook a significant initiative to reduce our external attack surface, particularly focusing on the proliferation of SaaS applications that had historically been exposed directly to the internet. The traditional model of placing applications behind a VPN, while secure, created user friction and operational overhead. We evaluated Banyan Security as a Zero Trust Network Access (ZTNA) solution to lock down these apps, and I wanted to document our implementation journey, focusing on the concrete steps and configuration patterns we used.
The core principle we adopted was that no SaaS admin console or internal tool should have a public IP or DNS record. Access should be granted based on device trust and user role, not just network location. Our stack includes Google Workspace, GitHub Enterprise, several data pipeline tools (like Airbyte and Metabase), and a suite of custom apps. Here is the high-level workflow we implemented with Banyan:
* **Device Inventory & Trust Scoring:** We integrated Banyan's TrustProvider with our existing MDM (JAMF) and endpoint security platform. This allows Banyan to assess device posture (disk encryption, screen lock, OS version, etc.) before granting access.
* **Service Definition:** Each application is defined as a "Service" within Banyan. This is a critical shift from network-centric to identity-centric policy.
* **Policy Creation:** Policies bind user roles (e.g., `data_engineer`, `finance_team`) to specific services, often with the additional requirement of a "TrustScore" exceeding a threshold.
* **Access via Banyan Access Tiers:** We deployed Banyan's lightweight connectors ("Access Tiers") in our cloud VPC. These act as the policy enforcement points, receiving encrypted traffic from user devices and only proxying requests to the backend service if the user/device is authorized.
A representative service definition for our internal Airbyte instance, which we wanted to make accessible only to trusted devices owned by the data team, looked similar to this in our Terraform configuration (Banyan's API is fully manageable as code):
```hcl
resource "banyan_service_web" "airbyte" {
name = "airbyte-internal"
description = "Airbyte instance for ETL pipelines"
access_tier = "connector-us-west1"
backend {
target {
name = "airbyte.internal.net"
port = 8000
}
}
policy {
trust_level = "High"
roles = ["data_engineer", "data_analyst"]
}
}
```
The operational results have been substantial. We've eliminated public DNS entries for over 15 internal tools. The user experience is notably smoother than a VPN; they authenticate via SSO and are granted seamless access only to the apps their role permits, provided their device is compliant. From a security logging perspective, we now have immutable, identity-aware audit trails for every access attempt to these previously opaque admin consoles.
However, the implementation was not without its complexities. The initial mapping of all our user groups to Banyan roles required careful planning. We also had to stage the rollout, starting with low-risk applications, to refine our device trust score thresholds. A key lesson was ensuring our "break-glass" procedures for administrator access were robust before locking down critical systems like our cloud console. Overall, Banyan provided the policy framework and enforcement mechanism we needed to materially shrink our attack surface while improving the day-to-day access experience for our distributed teams.
Extract, transform, trust