Infrastructure and security: design for the failure you will have

Old principles, still the right ones

In 1975 Jerome Saltzer and Michael Schroeder set out design principles for protecting information. Most of them still read as practical advice today.

• Least privilege. Give every person and program only the access it needs.
• Fail-safe defaults. Access is denied unless explicitly granted.
• Complete mediation. Check every access, every time.
• Economy of mechanism. Simpler designs are easier to verify.
• Open design. Security should not depend on the design being secret.
• Separation of privilege. Sensitive actions need more than one condition.

Zero trust, now described in NIST SP 800-207, is these ideas applied to modern networks: do not trust a request because of where it comes from, verify it.

Limit the blast radius

Assume something will go wrong and decide in advance how far the damage can spread. Separate environments, narrow credentials that expire, and isolated components mean one failure stays one failure. Infrastructure defined as code and kept in version control makes environments reproducible, so you can rebuild instead of repair.

Measure reliability and spend it deliberately

The Site Reliability Engineering practice from Google describes service level objectives, a target for how reliable a service should be, and the error budget, the amount of unreliability you can afford before you stop shipping new features. It turns an argument about risk into a number both product and engineering can see.

You cannot fix what you cannot see

Observability rests on three kinds of signal: metrics that show trends, logs that record events, and traces that follow a request across services. Together they let you ask a question you did not plan for when an incident starts.

Practise recovery before you need it

• Write down how much data you can afford to lose (recovery point objective) and how long you can be down (recovery time objective).
• Test restores from backup. A backup you have never restored is a hope.
• Run a game day: break something in a safe environment and watch how the team responds.

After the incident

Hold a review that asks what in the system made the mistake easy, not who made it. Record what you will change, assign an owner, and follow up.

Infrastructure & Security is 20% of the ATP exam and 18% of the CTP exam. The specialist Cloud Architecture Practitioner (CAP) and IoT and Embedded Systems (IESP) exams give it 34% and 30%. See exam facts.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.