GOVERNANCE EVIDENCE COLLECTION IN BASTION-ONLY ENVIRONMENTS
Built for a Bastion-restricted production environment
A read-only evidence collector gathers access-governance metadata from isolated production VMs using outbound-only HTTPS. It needs no inbound ports, no SSH or WinRM exposure and no bypass of Azure Bastion controls.
By Yashwant Daniel · Solvstrat
Key
Facts
- Sector
- Regulated production
- Built
- Lightweight governance metadata collector
- Stack
- Azure VMs · Bastion · TLS 1.2+ · Entra ID
- Constraint
- No inbound connectivity; read-only; no business data
- Outcome
- Audit evidence without weakening production isolation
Challenges
Production VMs sat in restricted network segments with administrative access brokered exclusively through Azure Bastion. Traditional collection agents assumed inbound connectivity or elevated sessions, both of which the security model prohibited.
No inbound path
There was no direct inbound or private routing path into production subnets, and none could be opened.
No persistent agents
Long-running agents and elevated sessions conflicted with server hardening and least-privilege policy.
Evidence still required
Access certification and audit still needed current identity and entitlement metadata from those hosts.
Constraints
Outbound-only HTTPS/TLS 1.2 or higher from the VM.
No inbound ports, SSH or WinRM exposure.
Read-only metadata collection with no business-data inspection.
No persistent elevated sessions and no continuous scanning.
Deployment must align with existing hardening and change-control policy.
Reference
Architecture
Collector component
A small scheduled process reads governance metadata locally — identities, local accounts, entitlement signals — and prepares a minimal payload. It holds no plaintext credentials.
Scheduled task · Least privilege · No plaintext secrets
Payload protection
The payload is optionally signed or encrypted before transmission so the ingestion endpoint can verify origin and integrity.
Payload signing · Encryption
Outbound transport
The collector initiates HTTPS to a secure ingestion endpoint. No inbound rule, private route or Bastion exception is required.
HTTPS · TLS 1.2+
Ingestion and relay options
Metadata can go directly to a secure endpoint or through an internal relay or staging host inside the trusted boundary, depending on policy.
Direct ingestion · Internal relay · Staging host
Audit and monitoring
Collection activity is logged, and the component’s read-only behaviour is verifiable through its scope and payload definition.
Audit logging · Collection telemetry
Data
Flow
- 1
The scheduler triggers the collector inside the restricted segment.
- 2
The collector reads approved governance metadata locally.
- 3
A minimal payload is assembled and optionally signed or encrypted.
- 4
The collector opens an outbound HTTPS connection to the ingestion endpoint or relay.
- 5
The endpoint verifies and normalizes the payload.
- 6
Metadata is written to the governance platform and collection activity is logged.
Delivery
Design
Scope, payload definition and security review with infrastructure teams.
Collector
Scheduled read-only collection and payload protection.
Transport
Direct ingestion and internal relay options.
Validation
Read-only verification, audit logging and rollout.
Hard
Problems
Collecting without inbound access
Problem: Every conventional agent design assumed a route into production that the security model forbade.
Resolution: The transport direction was inverted: the VM initiates outbound HTTPS, so no inbound rule or Bastion exception is needed.
Credential handling
Problem: A collector that stores credentials becomes a new privileged target.
Resolution: The component uses least-privilege local execution and avoids plaintext credential storage; deployment is aligned with existing secret-management practice.
Proving read-only behaviour
Problem: Security teams need evidence that the collector does not touch business data.
Resolution: The payload is explicitly scoped to governance metadata, and collection activity is logged so behaviour can be reviewed.
Results
Isolation preserved
No inbound ports, no SSH or WinRM exposure and no Bastion bypass were introduced.
Evidence delivered
Identity and entitlement metadata reached the governance platform on a reliable schedule.
Low operational footprint
Scheduled execution, minimal CPU and memory, and no persistent elevated session.
Technology
Used
Azure
TLS 1.2+
Microsoft Entra ID
Azure VM extensions
PowerShell / Python
Lessons
When inbound access is impossible, invert the transport direction instead of weakening the control.
The smallest possible payload is also the easiest one to approve.
Deployment method matters as much as the collector — fit the existing change process.
CLIENT SUCCESS STORIES
More Case Studies
Explore how Solvstrat engineers custom digital architectures and software platforms for leading brands.
FAQ
Frequently asked questions
A Bastion-only environment is one where administrative access to production is brokered exclusively through Azure Bastion, with no direct inbound or private routing path to the VMs. Collecting data from it requires designs that do not open inbound connectivity.
No. The collector initiates outbound HTTPS to a secure endpoint. No inbound ports, SSH or WinRM exposure and no Bastion bypass are required.
Only governance metadata needed for access certification and audit — identity and entitlement signals. It does not inspect business or application data.
Yes. Metadata can be sent directly to a secure ingestion endpoint or through an internal relay or staging host inside the trusted boundary, depending on security policy.
SEE THE PROTOTYPE WE'D BUILD
Give us 30 minutes.
We'll show you the fix.
Tell us where the work slows you down. We'll come back with a prototype of the custom software, internal tools or automation we'd build to remove it — working in weeks, and you own the code.