Security by design becomes practical when a deployment team can answer who has access, what is exposed, how failures are investigated and how the service is recovered. Those decisions should be part of the delivery plan.
This checklist is informed by my network, IAM and certificate-management labs. It is a technical review aid, not a compliance certificate or a substitute for the system owner’s security requirements. It has a different purpose from the resilience article: preparing the deployment and handover.
Identify infrastructure owners and required traffic flows
Name the service owner, technical approver and operator. Describe the resource, expected users and required connections. Record the difference between application access, administrative access and automated service identities.
Use that information to review exposed interfaces and management paths. A rule without an owner or purpose becomes harder to maintain. Likewise, a shared administrator account can make an incident difficult to attribute.
Review identity and administrative access
Check least-privilege assignments, the intended scope of service accounts and how access is removed. Confirm that sensitive actions are enforced by the server or underlying service, not only by the interface.
Use a permitted identity and a denied identity in the acceptance checks. Test expiration and recovery paths where the system supports them. The IAM access-review article expands these questions with Keystone examples.
Make certificate and secret handling maintainable
List which endpoints need certificates, who requests and approves them, and how expiry or revocation becomes visible. Keep private keys, passwords and tokens out of source code and ordinary handover documents.
My certificate-management portal illustrates a lifecycle workflow. A portal does not by itself establish the security of a deployment; issuance rules, key storage, permissions and operations still need review.
Check monitoring and recovery before release
Verify that a useful event appears when a test action is allowed, denied or fails. Record where the operator can find it and which timestamps or identifiers connect related observations. Logs that exist but cannot be located during an incident provide limited operational value.
Confirm the restore or rollback inputs and responsible person. Keep the expected validation steps with the change. Recovery should be an exercised procedure rather than a line in a template.
Record security and recovery checks before infrastructure release
For each requirement, record the control, owner, evidence, result and open exception. Avoid a yes/no checklist that does not identify what was tested. The UK NCSC’s secure design collection provides a reference for further design review; this checklist is not a claim of full alignment.
For deeper questions, continue to resilience and recovery testing or the related IDMUI and PKI projects. If a Python workflow or infrastructure application needs a targeted review, describe the implementation and expected result. Scope and validation are agreed before work begins.