The role of infrastructure in defence

How does infrastructure contribute to defence?#

Infrastructure contributes to defence by constraining the consequences of application mistakes and unauthorized activity. It determines network reach, credential issuance, data access, deployment authority, telemetry and recovery paths. A useful architecture makes these boundaries independently understandable: an application defect should not automatically grant access to every internal system or permission to change its own controls.

Managed services shift responsibilities rather than removing the need to assign them. AWS's shared responsibility model makes the division service-dependent. For EC2, the customer retains responsibility for the guest operating system, installed applications and security-group configuration. More abstracted services move additional platform work to the provider, while the customer still needs to manage its retained data and access decisions.

Create a responsibility map for the services actually used. Identify who patches each layer, approves access, reviews exposed endpoints, restores data, maintains logs and handles emergency changes. Include external delivery and identity services. A blank owner field is an actionable architecture finding; an attractive platform diagram cannot answer who will correct a failed control.

What should a defensive boundary map contain?#

Map actors and authority before drawing subnets. Start with user-facing requests, administrator access, scheduled work, integrations and the release pipeline. Follow each flow to the data or control it can affect. Record why the connection exists and what identity authorizes it. A line between components needs an action and purpose, not just an arrow.

Distinguish data paths from control paths. An application may need to write business records without changing its database access policy. A deployment job may update one service without creating new privileged roles. If these capabilities share a credential or unrestricted execution environment, compromise of routine work can become control over the boundary intended to contain it.

Include failure and emergency paths. A backup operator, debugging tunnel or manual production console can bypass normal delivery controls. Design these paths with a purpose, owner, time limit and observable outcome. Document how legitimate work continues when identity, logging or a policy dependency is unavailable, especially where failure must prevent a protected action.

How should workloads receive authority?#

A workload identity represents a specific service, job or execution context. Its permissions describe what it can do; its trust relationship describes who or what can obtain that identity. Review both. A narrowly scoped role is still exposed if an unintended delivery job can assume it, while a tightly controlled issuance path does not correct excessively broad permissions.

AWS recommends IAM roles and temporary credentials for workloads, reducing the need to distribute long-lived access keys. Apply that guidance to a clear purpose: the report worker can read the required report inputs and write a controlled output location, while the deployment job can update the identified service. Give development and production authority separate issuance and permission decisions.

Use actual resource scope rather than a broad product-level permission whenever the workflow permits it. Include read, write, delete and policy-change capabilities independently. Review scheduled and rarely used jobs too; their credentials can outlive the person who understood them. Expiring credentials reduce one persistence problem, but the application can still cause damage while a powerful credential is valid.

Establish how identity changes take effect. Rotation, removal of a trust relationship and revocation of already issued credentials are different events. An operating procedure should say which action addresses the incident and how its effect will be verified without exposing secret material.

How should network reach be constrained?#

Network reach is the set of destinations and services a workload can actually contact under deployed rules. Inventory legitimate inbound and outbound flows, including callbacks, document retrieval, update checks and administrative tools. For each, identify the destination, protocol, purpose, owner and change mechanism. A broad outbound rule is an authority decision even when the application is intended to contact only one provider.

Server-side request forgery occurs when untrusted input causes a server to make an unintended request. OWASP's prevention guidance combines application checks with network restrictions and distinguishes known destinations from arbitrary external fetching. An application that must reach a fixed integration can use a more specific policy than a general document-fetching service.

Review destination handling across parsing, name resolution, redirects and actual connection establishment. A check on the original URL is insufficient if later behavior can reach a different destination. Treat the application and network boundary as separate verification subjects. Test legitimate and denied flows with controlled endpoints in the authorized environment.

Contain unnecessary access to internal administration, sensitive local services and metadata interfaces using controls appropriate to the platform. Do not infer containment solely from the intended hostname or a diagram. Record the effective policy and an observed denied connection alongside a successful necessary one. Keep the scope focused on your controlled endpoints rather than probing unrelated networks.

Which architecture choice changes which responsibility?#

Choose an operating model by the workload's requirements and the team's ability to maintain the controls it retains. This comparison highlights review questions; it is not a claim that any platform is inherently secure.

Why is the release path part of defence?#

The release path can replace the code and configuration that enforce every runtime boundary. Map source review, build execution, artifact storage, deployment approval and runtime version verification. Identify where untrusted input reaches a privileged step and which job can change permissions. A carefully restricted service loses much of its containment if its delivery job inherits unrestricted production access.

Bind a deployment to an identifiable artifact and configuration change. The operator should be able to connect the running service to a reviewed source revision and the intended settings. A successful upload alone does not establish that the expected artifact is active. Verify the resulting runtime through the authoritative release state and a controlled functional check.

Design emergency access as an operating capability. Define the conditions for use, the permitted targets, the individual owner, the termination mechanism and the evidence of resulting changes. If an emergency procedure depends on the same unavailable identity service as the normal route, its availability claim needs testing.

Review what remains after the change. Temporary elevated access, old deployment credentials, debug endpoints and stale artifacts can preserve unintended authority. Incorporate their removal and verification into the delivery contract instead of leaving them to memory.

Fictional worked example: containing an external document worker#

This fictional example is an architectural teaching scenario, not a client incident. A business application retrieves invoices from two contracted document providers and produces a normalized preview. Its worker runs with broad outbound network access and shares the main application's data credential. The intended feature requires neither arbitrary destinations nor administrative data access.

The team writes the legitimate flows first: receive a job containing a provider identifier and document reference, resolve that reference through the selected provider integration, retrieve the document, produce a preview and store it in a tenant-scoped output location. It confirms that no product requirement calls for a user-supplied URL to be contacted directly. That design decision allows a narrow retrieval contract.

Engineering separates the worker identity, restricts its data permissions to required inputs and outputs, and constrains network access to the approved integration paths. The application validates the provider identifier and document ownership before submission. The worker still validates the job at execution because queue contents are not treated as permission by themselves.

Verification uses harmless documents and controlled denied destinations. It proves that both provider workflows continue to work, that a modified job cannot retrieve an unapproved endpoint, and that the worker cannot read an unrelated tenant's storage. The test also covers provider redirects according to the documented integration contract. A denied connection must create an understandable job result without placing remote error content into a privileged preview.

The remaining tradeoff is availability when a provider changes infrastructure. The operating procedure identifies who reviews an integration change, how a new permitted destination is tested and how pending work is reported meanwhile. Broadening access automatically in response to an outage would remove the boundary at the moment it becomes inconvenient. The team instead treats the change as an explicit, reviewable update with evidence.

What should an infrastructure defence review verify?#

Use deployed configuration and controlled runtime evidence together. A review should show the intended flow, the effective authority and the result observed under the authorized test conditions.

• Name the owner of retained responsibilities for each service and operating layer.
• Separate workload permissions from the trust relationship that issues its credentials.
• Verify required and denied network flows using controlled destinations.
• Check external fetching across original destination, redirect handling and actual connection.
• Trace one reviewed source change to its artifact, deployed configuration and running behavior.
• Confirm that development and production authority require deliberate environment selection.
• Exercise emergency access, its termination and the review of resulting changes.
• Restore representative data and configuration with access appropriate to the recovery role.
• Preserve non-secret decision and deployment evidence in a location with defined access and retention.

Where do infrastructure controls stop?#

Infrastructure controls cannot decide every business permission or validate every application meaning. Restricting network access does not prevent a service from misusing data it legitimately holds. Encryption does not correct an overbroad account. A managed runtime does not establish tenant isolation. Use infrastructure to constrain specific authority while keeping the application rules explicit.

Start with one high-consequence path: an external fetcher, production deployment, cross-tenant export or administrative operation. Draw its identity, network and data boundaries, assign owners and verify the most consequential uncertainty. Prefer an incremental change that can be observed over a large redesign whose resulting authority remains unclear.

Extra boundaries create operating work. Policies can drift, providers change destinations, recovery identities can become stale and log stores can expose sensitive evidence. Maintain clear change triggers and a repeatable verification procedure. A scoped architecture review describes the controls and flows examined; it does not guarantee the security posture of every service.