Firewall and Secure Access

A useful access design begins by naming what somebody or something needs to reach, what action is necessary and what would happen if the same path were abused. We map staff, administrators, contractors, customers, service accounts, workloads, branches and partner connections to applications, APIs, management planes, data stores and shared services. Each path needs a business purpose, accountable owner, expected source, permitted destination, protocol or application, authentication context, time boundary and evidence. A network object without this context may be technically valid yet impossible to govern.

The current-state review follows actual traffic and configuration. We examine firewalls, routers, VPN concentrators, wireless boundaries, cloud security groups, network access controls, load balancers, proxies, private links, identity providers, device posture sources and relevant DNS or web gateways. Rule bases are checked for broad objects, duplicate or shadowed rules, temporary entries that never expired, unused paths, inconsistent naming, direct administration, split-tunnel assumptions and logging gaps. Documentation and observed state are compared; uncertainty is recorded rather than filled with a reassuring guess.

Remote and hybrid access is treated as a service journey. A user may authenticate successfully but still arrive from an unmanaged device, carry a stolen session, use an over-broad group or reach more of a network than the application requires. Partners and support providers introduce different ownership, revocation and monitoring questions. We therefore separate identity proof, device confidence, resource authorisation, transport protection, application authorisation and continuing observation. Passing one checkpoint is not accepted as permanent trust for every later action.

Consequences set the design depth. Loss of access to a public content system is not the same as loss of control over payments, patient records, industrial equipment or privileged cloud administration. We record confidentiality, integrity, availability, safety, legal, contractual and recovery implications supplied by the client. Threat modelling identifies plausible entry, lateral movement, command, data movement and disruption paths. The result is a prioritised protect surface, not a promise that every packet or unknown dependency has been discovered.

Pricing follows this evidence boundary. The number of sites, tenants, users, applications and policies matters, as do legacy protocols, overlapping providers, business-hour constraints, high availability, encrypted-traffic inspection, data residence, migration support and testing depth. The proposal states whether the commission is assessment, target design, configuration, migration, verification or a separately defined managed service. Product purchase, certification, legal interpretation, penetration testing and continuous security operation are never implied by the service name.

Every material connection receives an explicit policy. The policy identifies the subject, device or workload, destination resource, allowed action, required signals, session conditions, enforcement point, logging expectation and owner. Default deny is meaningful only when the organisation can identify legitimate dependencies and handle exceptions without opening a permanent bypass. Least privilege therefore means the smallest useful reach, action and duration that still allows the service to operate—not a slogan attached to an undocumented rule set.

Identity-aware controls improve precision but do not replace sound authorisation. We trace authoritative identity sources, federation, role and group ownership, device enrolment, posture checks, multi-factor authentication, token and session lifetime, service identities and emergency access. A clean-looking policy can still fail if a dynamic group is over-inclusive, a device signal is stale or a workload credential cannot be rotated. The control design names the quality, age and failure state of every signal on which an access decision depends.

VPN, ZTNA, SSE and SASE answer overlapping but different needs. A VPN creates a protected tunnel and may still grant broad network reach. ZTNA brokers access around particular applications or resources using identity and contextual policy. Security Service Edge brings cloud-delivered access and security functions together, while SASE joins that security model with wide-area networking. None is automatically superior in every estate. We select or combine patterns according to applications, protocols, latency, inspection, branch connectivity, unmanaged users, service-to-service flows, resilience and operating capacity.

Segmentation limits reach and blast radius when a credential, endpoint or workload is compromised. Boundaries may sit between internet and service, user and administration, production and development, tenant and tenant, workload and database, backup and primary environment or one application tier and another. Segments follow protect surfaces and dependencies rather than arbitrary VLAN counts. Each permitted crossing has a named need; each denied path has a test; each exception has an owner and expiry.

Privileged access receives its own route. Administrative interfaces should not simply share the ordinary user path. Depending on risk, the design may require managed workstations, dedicated gateways, just-in-time elevation, stronger authentication, session recording, source restrictions, approval or isolated recovery accounts. Break-glass access must remain usable during provider or identity failure, but it is narrow, monitored, exercised and reviewed. Convenience does not silently become an enduring trust relationship.

The target design shows control and data planes separately. We record where policy is authored, approved, distributed and enforced; which component resolves identity or posture; how routes and name resolution reach the resource; and where logs prove the decision. Network firewalls, host controls, cloud-native policies, proxies, application gateways and identity-aware brokers may all participate. Overlapping enforcement is useful only when responsibilities and precedence are clear. Conflicting rules and invisible fallbacks can create both outages and unintended access.

Firewall policy is built from a documented rule model. Objects use stable naming and ownership; broad services and sources require justification; temporary rules carry expiry; administrative and machine-generated changes remain traceable. Anti-spoofing, egress control, management exposure, NAT, inspection profiles, geographic rules and encrypted traffic are considered in context. TLS inspection is not treated as a harmless checkbox: certificate trust, privacy, application compatibility, sensitive categories, bypass governance, key protection and lawful operation need explicit decisions.

Cloud and hybrid environments require provider-specific responsibility. Security groups, network access lists, cloud firewalls, private endpoints, transit networks, service meshes and identity policies can enforce different parts of a path. We map account and subscription structure, route propagation, peering, public endpoints, control-plane access, provider-managed services and cross-cloud connections. A central appliance is not assumed to see every flow, and a cloud-native control is not assumed to inherit the organisation's on-premise rule intent.

Availability and performance form part of secure access. Capacity calculations consider normal and peak throughput, concurrent sessions, connection rate, inspected protocols, encryption, logging, failover behaviour and provider limits. High availability is tested as a real state transition, including configuration synchronisation, routing convergence, DNS, certificates and session impact. A redundant pair connected to one power, carrier, region or identity dependency is not an end-to-end resilient service.

Product selection follows requirements rather than reversing them. We compare supported protocols, policy granularity, identity and device integrations, logging, APIs, deployment patterns, regional availability, data handling, administrative separation, portability, licensing units, exit paths and operator skill. Open-source and existing products may be suitable where the organisation can operate and verify them. A branded feature name is not accepted as proof of capability, and no vendor is represented as universally compatible or risk-free.

Migration begins with dependency discovery and a reversible sequence. Rules may appear unused because logging is absent, because traffic is seasonal or because a recovery process has not run recently. We combine configuration analysis, owner interviews, flow evidence and controlled observation before removal. Changes are grouped by service and risk, then moved through approval, staging or limited cohorts where available. Rollback conditions, configuration backups, access to the old and new control planes and an authorised decision maker are defined before the maintenance window begins.

A rule lifecycle prevents the new environment from becoming the old problem. Requests identify purpose, owner, source, destination, action, duration and validation. Reviews distinguish still-needed, reducible, replaceable and removable access. Temporary or emergency changes expire automatically where the platform supports it; otherwise they enter a dated review register. Orphaned objects, disabled rules, shadowed entries and duplicate routes are reported. Policy-as-code can improve review and repeatability, but it does not remove the need for accountable approval and safe deployment.

Monitoring verifies both security and service health. We identify allow and deny events, authentication outcomes, posture failures, administrative changes, policy distribution, tunnel state, route changes, capacity, certificate expiry, log delivery and control outages that matter to the scoped service. Each signal needs a time source, retention boundary, access rule and owner. Logging every event is not automatically useful; missing logs are not interpreted as safe silence. Detection and response duties are stated separately from collection.

Operations must handle identity, certificate and provider failure. We define how access behaves when a posture source is unavailable, a directory cannot be reached, a policy engine is degraded or a cloud point of presence fails. Fail-open and fail-closed are consequences, not abstract preferences. Some services may need a limited fallback route; others must remain denied. The decision is documented, tested and monitored. Recovery credentials, certificates, keys and configuration exports are protected outside the same failure domain where practical.

Handover includes diagrams, data-flow and policy records, object and rule conventions, configuration evidence, change and exception processes, monitoring responsibilities, renewal dates, recovery steps and known limitations. Named administrators receive the access and training needed for their role. Ongoing rule administration, health monitoring, threat response, vendor support and reporting exist only if commissioned. The project does not silently create a 24/7 security operations service or an unlimited change desk.

Acceptance is scenario-based. For each in-scope service we define an actor, identity state, device state, source, resource, action, expected decision, expected route, visible evidence and owner. Positive tests prove necessary access, while negative tests prove that adjacent users, devices, networks, ports, applications and administrative paths remain blocked. Session revocation, group removal, device non-compliance, expired exceptions and terminated supplier access are tested where relevant. A single successful connection cannot demonstrate least privilege.

Configuration is checked against the approved policy and the observed path. We review rule order, shadowing, objects, zones, NAT, routing, encryption, identity mapping, logging, administrative access and configuration synchronisation according to the agreed platforms. Where safe and authorised, controlled scans or connection tests can supplement evidence. Penetration testing is a separate method with explicit targets, timing, safety rules and authority; it is not performed merely because a firewall was configured.

Failure and recovery tests expose operational assumptions. Depending on scope, we may exercise an enforcement node, tunnel, identity connector, logging path, carrier, DNS route, certificate, cloud region or configuration rollback. Tests avoid unsafe disruption and use agreed windows and abort criteria. We record whether sessions persisted, traffic rerouted, policy remained consistent, alerts reached an owner and normal operation returned. Any untested dependency remains a stated limitation rather than an implied success.

Performance results require context. Throughput, connection rate, latency and session scale depend on traffic mix, inspection features, encryption, hardware or service tier, path location and test method. We record the configuration and conditions under which measurements were taken. A vendor maximum is not presented as achieved production capacity. User experience is checked for the representative applications and locations that the client makes available, while global carrier performance and every future workload remain outside the evidence boundary.

The closeout record separates delivered, accepted, deferred and excluded items. Known exceptions keep an owner, reason, compensating control and review date. Change records and evidence are handed to the organisation in agreed formats, and secrets are transferred through an approved secure channel rather than embedded in reports. The architecture can reduce attack surface and make access more accountable; it cannot guarantee the absence of compromise, uninterrupted service, regulatory acceptance, insurer approval, ranking, leads or revenue.