Security Foundation Map — Defense in Depth and Least Privilege

About this article

This article is the eighth deep dive in the “System Architecture” category of the Architecture Crash Course for the Generative-AI Era series, covering the security foundation to weave through the infrastructure layer.

WAF, DDoS protection, IDS/IPS, IAM, encryption, secrets management — layered into defense in depth — is the basis. Adding it later significantly increases costs. This article maps the functions to build in at the system-architecture stage; per-area deep dives (auth methods, authorization models, crypto algorithms, vulnerability assessment) live in the “Security Architecture” category.

What is a security foundation in the first place

A security foundation is, roughly speaking, “the complete set of defensive equipment to protect a system from external attacks and internal accidents.”

Imagine building security. The entrance has a gate (firewall), each floor has card keys (authentication / authorization), the vault has a combination lock (encryption), and security cameras (monitoring) are installed everywhere. Any one alone is insufficient — layering multiple defenses stops intruders. Infrastructure security follows the same “defense in depth” philosophy, combining WAF, DDoS protection, IAM, encryption, and secrets management.

Why security foundation design matters

What happens if you postpone security? Public IP addresses are scanned by bots 24/7/365. Even a tiny validation API server gets thousands of scan accesses logged within 24 hours. “Nobody knows about us yet, so we’re fine” is a premise that has never held on the Internet. Security is unbolted-on-able — build it in from day one.

”We’re too small to be a target” is the most dangerous belief

Public IP addresses are scanned by bots 24/7/365. Even tiny personal services become targets for brute force, vulnerability scans, and port scans the moment they go public. “Nobody knows about us yet, so we’re fine” is a premise that has never held on the Internet.

A small validation API server gets thousands of scan accesses logged within 24 hours of going public — not unusual. Attackers aren’t humans, they’re bots, and they scan all IPs in order without picking targets. Regardless of scale, “target the moment you publish” is the correct framing.

Security is “unbolted-on-able.” Build it in from day one — that’s the rule.

Scope of this article

This article focuses on “the system-architecture-stage map of which security functions to embed in the infrastructure layer.” Per-area deep dives (auth methods, authorization models, crypto algorithms, vulnerability assessment, etc.) are all consolidated in the “Security Architecture” category articles.

The question for this article is “where in the system architecture do you put what?” Concrete selections are in the other category’s articles.

Defense in Depth

Defense in depth is the principle of stopping attacks across multiple layers rather than relying on a single line. Build multiple gates from edge to interior so that breaching one stops at the next.

Stopping everything at the entrance is unrealistic. “Assume something gets breached somewhere” and design for damage minimization. The cloud-security default is defense in depth + Zero Trust. Configurations outside this aren’t getting picked anymore.

Don’t stop attacks at one wall. Designs where the next layer holds when the previous breaks are the basis.

Major security-foundation building blocks

The list of components to “decide what goes where” at system-architecture design time. Detailed selection (products, settings, ops rules) is in the other-category articles. Use this for placement and gap-checking.

System-architecture design must answer every row at minimum. “Later” does not exist.

List compliance requirements before design

Industry, geography, and customer requirements set the security baselines you must meet. Certification takes time and money, so listing them at design time prevents major rebuilds later. This sits at system-architecture’s first decision rather than per-area deep dives, so it’s covered here.

A SaaS provider getting SOC 2 Type II dramatically improves enterprise sales. SaaS targeting Japanese finance / public sector often must comply with ISMS + FISC (Financial Information Systems Center safety standards). Deciding SOC 2 after launch produces months of delay redesigning logging.

Phase-by-phase security adoption roadmap

“Everything at once” is unrealistic. Required vs recommended by phase. Below is in order of incident-likelihood without it.

MFA, Dependabot, Secret Scanning, HTTPS — these four are mandatory even at MVP. Postponing means hours-after-launch IAM-key leaks and dependency-chain intrusion. The December 2021 Log4Shell (Log4j CVE-2021-44228) demonstrated how one library vulnerability cascaded into chained attacks worldwide.

Even at MVP, install MFA, Secret Scanning, Dependabot, HTTPS day one. “Later” does not exist.

System-architecture-stage traps

Per-product configuration mistakes go to the other category. This article lists canonical system-architecture-stage incidents. The decision mistakes the architect needs to avoid first.

The 2022 Okta breach (some customers’ credentials accessed via a support contractor) and LastPass leak (encrypted vault copies in attacker hands) demonstrate that even security companies get breached. Design assuming “we won’t get breached” does not hold.

Design-stage decision errors become multi-month remediation projects after launch. No compromise on the first design.

AI decision axes

With AI-driven development as the assumption, the deciding axis becomes “can it be expressed as Policy as Code?”

AI-generated code carries hallucination risks; SAST and dependency scanning (Dependabot/Snyk) must be in CI — “do not deploy AI-generated code unverified.”

1. List compliance requirements first and embed in design.
2. Each layer of defense in depth gets a “who owns this” assignment.
3. IAM strategy: SSO + Role switching as default; long-term keys are exceptions.
4. Policy-as-Code support as a check item for every product selection.

Security risks of AI-generated code and automated scanning

AI-generated infrastructure code tends to have security-setting gaps. For example, opening 0.0.0.0/0 in security groups, not setting S3 bucket public access blocks, allowing * resources in IAM policies — these are patterns AI writes when prioritizing “getting it to work.”

The countermeasure is embedding tfsec, Checkov, and AWS Config Rules in the CI pipeline to automatically scan all infrastructure changes including AI-generated code. Building a system that comprehensively detects security-setting mistakes that human review alone misses becomes the assumption.

Policy as Code becomes the AI-era security guardrail

Policy as Code tools like OPA (Open Policy Agent), Cedar, and tfsec declare security policies in code and auto-detect violations. They can enforce rules against AI-generated Terraform code like “no DB in public subnets” or “no * in IAM policy Actions.”

As AI-written code volume grows, human review burden rises. Expanding the scope of automated Policy as Code checks is the key to ensuring security-operations scalability in the AI era.

”Public repo for hours” (industry case)

A new engineer accidentally pushed a script with AWS access keys to a public repo, and within hours, attackers had spun up tens of thousands of dollars of EC2 instances for crypto mining. Reported repeatedly in many countries.

The moment it lands on GitHub, bots scrape within seconds. Even after deletion, Git history retains it.

The lesson: “noticing and deleting is too late.” Detect at pre-push hooks, or — better — never issue long-term keys (OIDC / temporary credentials only). Security’s “I’ll be careful” falls apart the moment it depends on human attention.

Don’t rely on individual willpower. Defend through structure. That’s the rule.

What you must decide — what’s your project’s answer?

Articulate your project’s answer in 1-2 sentences for each:

• Compliance requirements (SOC 2 / ISMS / PCI DSS, etc.)
• Per-layer products in defense in depth (WAF / DDoS / IDS/IPS)
• ZTNA adoption (timing of VPN migration)
• IAM strategy (SSO / Role / MFA mandatory scope)
• Secrets-management foundation (Secrets Manager / Vault)
• Encryption policy (in-transit / at-rest / app-layer)
• Audit-log isolated-account storage and WORM
• Scope of Policy as Code adoption

Per-item concrete selections live in the “Security Architecture” category articles.

Related Articles

https://en.senkohome.com/arch-intro-system-cloud-vendor/ https://en.senkohome.com/arch-intro-system-application-types/ https://en.senkohome.com/arch-intro-system-bcp/

Summary

This article covered the security foundation map at the system-architecture stage — defense in depth, compliance, phase-by-phase roadmap, and the AI-era angle.

Security cannot be bolted on, so build it in from line one of the design. Even at MVP, MFA, Dependabot, Secret Scanning, HTTPS are mandatory day one; further layers stack as scale and industry require.

The next article covers monitoring and operations (the three pillars of observability, the four golden signals).

Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book

I hope you’ll read the next article as well.