Automated Deployment into a Restricted Environment¶
Illustrative Scenario
This scenario is a fictional composite. It deliberately omits identifiable platforms, suppliers, environment names and implementation details.
Scenario¶
An organisation develops infrastructure and application changes within an engineering environment and promotes approved artefacts into a more restricted operational environment.
Deployment is performed through a controlled automation path rather than routine direct administrator access.
The architecture introduces orchestration services, execution components, artefact repositories, credentials and approval mechanisms.
Traditional Assurance View¶
Conventional assurance may examine:
- source integrity;
- peer review;
- artefact integrity;
- separation of duties;
- privileged access;
- deployment authorisation;
- vulnerability assessment; and
- audit logging.
The ORSM Lens¶
ORSM asks whether the deployment mechanism itself has become a critical operational dependency.
Can the organisation still administer, recover or rebuild the restricted environment if the normal automation chain is unavailable?
Relevant Domains¶
- Protection Intent
- Complexity Management
- Operational Resilience
- Recovery Engineering
- Dependency Resilience
Key Questions¶
- How many services must remain healthy for a deployment to succeed?
- Where is trust established between orchestration and execution components?
- Does the deployment mechanism create standing privileged trust?
- Can execution components validate the source and integrity of instructions?
- Can the restricted environment be recovered without the primary orchestration capability?
- What happens if the artefact repository is unavailable?
- Is there an independently controlled recovery path?
- Has automation reduced risk, or merely moved privileged trust into another architectural layer?
Illustrative Finding¶
The automated deployment model may substantially reduce direct privileged access while simultaneously concentrating trust in a small number of orchestration services.
The resulting architecture is therefore dependent upon those services remaining secure, available and recoverable.
Potential ORSM Outcome¶
Improve / Redesign
Potential improvements may include:
- stronger instruction authenticity;
- simplified execution dependencies;
- independent recovery capability;
- separation between routine deployment and emergency recovery; and
- explicit testing of orchestration failure scenarios.
ORSM Lesson¶
Removing human privilege does not remove architectural trust.
Automation changes where trust resides.
ORSM requires those trust relationships to remain visible, justified and survivable.