Security design principles in GCP - Deep Dive

Overview - Security design principles

What is it?

Security design principles are basic rules to build safe computer systems and cloud services. They guide how to protect data, control access, and reduce risks. These principles help make sure systems stay secure even if parts fail or attackers try to break in. They are like a safety checklist for building technology.

Why it matters

Without security design principles, systems would be easy targets for hackers, causing data loss, theft, or service outages. This could harm people’s privacy, damage businesses, and disrupt daily life. Using these principles helps prevent costly mistakes and builds trust in technology that people rely on every day.

Where it fits

Before learning security design principles, you should understand basic cloud concepts and networking. After mastering these principles, you can learn specific security tools and services in GCP, like Identity and Access Management or encryption methods.

Mental Model

Core Idea

Security design principles are simple, clear rules that guide building systems to keep data safe and control who can do what.

Think of it like...

Imagine building a house with locks, alarms, and fireproof materials to keep your family safe. Security design principles are like the blueprint for that house’s safety features.

┌───────────────────────────────┐
│       Security Design          │
│         Principles            │
├─────────────┬───────────────┤
│ Least Privilege │ Defense in Depth │
├─────────────┼───────────────┤
│ Fail Safe Defaults │ Separation of Duties │
├─────────────┼───────────────┤
│ Economy of Mechanism │ Complete Mediation │
├─────────────┼───────────────┤
│ Open Design │ Psychological Acceptability │
└─────────────┴───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Least Privilege

Concept: Learn that users and systems should have only the access they need, nothing more.

Least Privilege means giving people or programs the smallest amount of access needed to do their job. For example, if a user only needs to read files, they should not have permission to delete or change them. This limits damage if someone makes a mistake or is hacked.

Result

Systems limit access, reducing risks from mistakes or attacks.

Understanding least privilege helps prevent many security problems by limiting what can go wrong.

2

Foundation

What is Defense in Depth?

Concept: Learn why using multiple layers of security is safer than relying on just one.

Defense in Depth means protecting systems with several layers, like a castle with walls, guards, and moats. If one layer fails, others still protect you. For example, a cloud system might use firewalls, encryption, and strong passwords all together.

Result

Systems stay safer because attackers must break through many defenses.

Knowing defense in depth shows why relying on just one security measure is risky.

3

Intermediate

Fail Safe Defaults Explained

🤔Before reading on: Should a system deny access by default or allow it? Commit to your answer.

Concept: Learn why systems should deny access unless explicitly allowed.

Fail Safe Defaults means that if the system is unsure, it should deny access rather than allow it. This prevents accidental exposure. For example, a new user account should start with no permissions until assigned, not full access.

Result

Systems avoid accidental security holes by defaulting to deny.

Understanding fail safe defaults prevents dangerous mistakes from default settings.

4

Intermediate

Separation of Duties Concept

🤔Before reading on: Is it safer for one person to approve and execute a critical action, or should these be separate? Commit to your answer.

Concept: Learn why splitting responsibilities reduces risk of fraud or error.

Separation of Duties means dividing tasks so no one person controls everything. For example, one person requests money, another approves it. This stops a single person from doing harm alone.

Result

Systems reduce insider threats and mistakes by dividing control.

Knowing separation of duties helps design checks and balances in security.

5

Intermediate

Economy of Mechanism Principle

Concept: Learn why simple security designs are better than complex ones.

Economy of Mechanism means keeping security designs simple and small. Complex systems are harder to understand and more likely to have hidden flaws. For example, a simple password check is safer than a complicated custom system.

Result

Systems are easier to secure and maintain with simple designs.

Understanding this principle helps avoid introducing bugs that attackers can exploit.

6

Advanced

Complete Mediation in Practice

🤔Before reading on: Should a system check permissions once or every time access is requested? Commit to your answer.

Concept: Learn why systems must check permissions every time, not just once.

Complete Mediation means every access request is checked against permissions. For example, even if a user was allowed before, the system checks again each time they try to open a file. This stops attackers from exploiting cached permissions.

Result

Systems prevent unauthorized access by continuous checks.

Knowing complete mediation stops attackers from bypassing security by reusing old permissions.

7

Expert

Psychological Acceptability Importance

🤔Before reading on: Is it better for security controls to be easy or hard for users? Commit to your answer.

Concept: Learn why security must be easy to use to be effective.

Psychological Acceptability means security measures should not annoy users. If controls are too hard, users find ways around them, like writing down passwords. For example, using single sign-on makes security easier and more likely to be followed.

Result

Systems stay secure because users cooperate with security rules.

Understanding this principle helps design security that people actually use correctly.

Under the Hood

Security design principles work by shaping how systems handle access, data, and errors. Internally, they guide how permissions are stored, how checks happen on every request, and how failures default to safe states. They influence system architecture to include multiple layers, clear roles, and simple code paths that reduce bugs and vulnerabilities.

Why designed this way?

These principles were created from decades of security failures and successes. Early systems often trusted users too much or had complex code that hid bugs. Designers learned that simple, layered, and user-friendly rules reduce risks and make systems easier to secure and maintain. Alternatives like all-or-nothing access or complex hidden controls proved unsafe.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│   User/Actor  │──────▶│ Access Control│──────▶│  Resource     │
└───────────────┘       └───────────────┘       └───────────────┘
        │                      ▲                       ▲
        │                      │                       │
        ▼                      │                       │
┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│  Audit Logs   │◀──────│  Security     │◀──────│  Fail Safe    │
│  & Monitoring │       │  Checks       │       │  Defaults     │
└───────────────┘       └───────────────┘       └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does least privilege mean users get no access at all? Commit yes or no.

Common Belief: Least privilege means giving users almost no access to be safe.

Reality: Least privilege means giving only the access needed, not zero access. Users must have enough rights to do their job.

Why it matters: Giving too little access breaks workflows and frustrates users, leading to insecure workarounds.

Quick: Is one strong firewall enough to protect a system? Commit yes or no.

Common Belief: One strong security layer, like a firewall, is enough to keep systems safe.

Reality: No single layer is enough; defense in depth requires multiple layers to handle different threats.

Why it matters: Relying on one layer risks total failure if that layer is bypassed.

Quick: Should security always be strict even if it annoys users? Commit yes or no.

Common Belief: Security should be as strict as possible, even if users find it hard to use.

Reality: If security is too hard, users bypass it, making systems less safe overall.

Why it matters: Ignoring user experience leads to insecure behavior and weakens protection.

Quick: Does complete mediation mean checking permissions once per session? Commit yes or no.

Common Belief: Checking permissions once when a user logs in is enough for security.

Reality: Permissions must be checked every time access is requested to prevent misuse.

Why it matters: Skipping checks allows attackers to exploit cached permissions and gain unauthorized access.

Expert Zone

1

Some security principles conflict in practice, like strict separation of duties vs. operational efficiency, requiring careful balance.

2

Psychological acceptability often determines real security success more than technical strength because users are the weakest link.

3

Fail safe defaults can cause usability issues if too restrictive, so exceptions must be managed carefully.

When NOT to use

Security design principles are guidelines, not strict rules. In some fast-moving startups, speed may temporarily outweigh strict separation of duties. For very low-risk systems, full defense in depth may be overkill. Alternatives include risk-based security and adaptive access controls.

Production Patterns

In GCP, these principles appear as IAM roles with least privilege, multi-layer firewalls, audit logging for complete mediation, and user-friendly authentication like OAuth. Enterprises use automated policy enforcement and continuous monitoring to maintain these principles at scale.

Connections

Zero Trust Security

Builds on

Understanding security design principles helps grasp Zero Trust, which applies least privilege and complete mediation everywhere.

Human Factors Psychology

Cross-domain influence

Psychological acceptability in security design connects to human factors psychology, showing how user behavior impacts system safety.

Supply Chain Management

Similar pattern

Separation of duties in security mirrors checks and balances in supply chains to prevent fraud and errors.

Common Pitfalls

#1 Giving users too many permissions by default.

Wrong approach:

gcloud projects add-iam-policy-binding my-project --member='user:[e-mail]' --role='roles/editor'

Correct approach:

gcloud projects add-iam-policy-binding my-project --member='user:[e-mail]' --role='roles/viewer'

Root cause:

Misunderstanding least privilege leads to over-permissioning, increasing risk.

#2 Relying on a single firewall without other protections.

Wrong approach:

Only configuring network firewall rules and ignoring identity or encryption.

Correct approach:

Configuring firewall rules plus IAM roles, encryption, and audit logging.

Root cause:

Ignoring defense in depth causes single points of failure.

#3 Making security controls too complex and hard to use.

Wrong approach:

Requiring users to change passwords daily with complex rules and no single sign-on.

Correct approach:

Using multi-factor authentication with single sign-on for ease and security.

Root cause:

Neglecting psychological acceptability leads to user workarounds.

Key Takeaways

Security design principles are simple rules that guide building safe systems by controlling access and reducing risks.

Applying least privilege and defense in depth limits damage from mistakes or attacks by restricting access and layering protections.

Fail safe defaults and complete mediation ensure systems deny access by default and check permissions every time.

Separation of duties and psychological acceptability balance security with operational safety and user cooperation.

Understanding these principles helps design cloud systems that stay secure, usable, and resilient against threats.

Practice

1. Which security design principle means giving users only the access they need and nothing more?

easy

A. Secure by default

B. Defense in depth

C. Continuous monitoring

D. Least privilege

Solution

1. Step 1: Understand the principle of least privilege

   Least privilege means users get only the minimum access needed to do their job.

2. Step 2: Compare with other principles

   Defense in depth means multiple layers of security, secure by default means safe settings initially, monitoring means watching for issues.

3. Final Answer:

   Least privilege -> Option D

4. Quick Check:

   Minimum access = Least privilege [OK]

Hint: Minimum access means least privilege [OK]

Common Mistakes:

• Confusing defense in depth with least privilege
• Thinking secure by default means limited access
• Mixing monitoring with access control

2. Which of the following is the correct way to assign a role to a user in GCP IAM using the gcloud CLI?

easy

A. gcloud iam roles assign [e-mail] roles/viewer

B. gcloud iam add-role [e-mail] viewer

C. gcloud projects add-iam-policy-binding my-project --member=user:[e-mail] --role=roles/viewer

D. gcloud iam set-role [e-mail] roles/viewer

Solution

1. Step 1: Recall correct gcloud command syntax for IAM role assignment

   The correct command uses 'projects add-iam-policy-binding' with --member and --role flags.

2. Step 2: Check each option

   gcloud projects add-iam-policy-binding my-project --member=user:[e-mail] --role=roles/viewer matches the correct syntax; others use invalid commands or flags.

3. Final Answer:

   gcloud projects add-iam-policy-binding my-project --member=user:[e-mail] --role=roles/viewer -> Option C

4. Quick Check:

   IAM role assignment uses add-iam-policy-binding [OK]

Hint: Use add-iam-policy-binding with --member and --role [OK]

Common Mistakes:

• Using incorrect gcloud commands like 'iam roles assign'
• Omitting --member or --role flags
• Confusing roles with users in command syntax

3. Consider this GCP IAM policy snippet:

{
  "bindings": [
    {
      "role": "roles/storage.objectViewer",
      "members": ["user:[e-mail]"]
    },
    {
      "role": "roles/storage.objectAdmin",
      "members": ["user:[e-mail]"]
    }
  ]
}

What access does Alice have on the storage bucket?

medium

A. Full control including deleting objects

B. Read-only access to objects

C. No access at all

D. Can create and delete buckets

Solution

1. Step 1: Identify Alice's assigned role

   Alice has the role 'roles/storage.objectViewer' which grants read-only access to objects.

2. Step 2: Understand role permissions

   ObjectViewer allows viewing objects but not modifying or deleting them.

3. Final Answer:

   Read-only access to objects -> Option B

4. Quick Check:

   ObjectViewer = read-only access [OK]

Hint: Viewer roles mean read-only access [OK]

Common Mistakes:

• Confusing objectAdmin with objectViewer
• Assuming viewer can delete objects
• Mixing bucket-level and object-level permissions

4. You wrote this IAM policy JSON but get an error when applying it:

{
  "bindings": [
    {
      "role": "roles/storage.objectViewer",
      "members": ["user:[e-mail]"]
    },
    {
      "role": "roles/storage.objectAdmin",
      "members": ["[e-mail]"]
    }
  ]
}

What is the error and how to fix it?

medium

A. Missing 'user:' prefix before bob's email in members; add 'user:'

B. Role 'roles/storage.objectAdmin' does not exist; use 'roles/storage.admin'

C. JSON syntax error; remove trailing commas

D. Members list must be empty for objectAdmin role

Solution

1. Step 1: Check members format in IAM policy

   Each member must have a prefix like 'user:', 'serviceAccount:', etc.

2. Step 2: Identify the missing prefix for [e-mail]

   Bob's member entry lacks 'user:' prefix, causing the error.

3. Final Answer:

   Missing 'user:' prefix before bob's email in members; add 'user:' -> Option A

4. Quick Check:

   Member identifiers need prefixes like 'user:' [OK]

Hint: Always prefix members with user: or serviceAccount: [OK]

Common Mistakes:

• Omitting user: prefix in members list
• Assuming roles names are incorrect without checking
• Misreading JSON syntax errors

5. You want to design a GCP project with strong security. Which combination of principles and practices best protects your resources?

hard

A. Use least privilege IAM roles, enable defense in depth with multiple controls, and monitor with continuous auditing

B. Use secure by default settings only, no need for monitoring or role restrictions

C. Grant all users owner role for flexibility, disable monitoring to reduce noise, and use default network settings

D. Assign broad roles to users, enable audit logging, and rely on firewall rules only

Solution

1. Step 1: Identify key security principles for GCP

   Least privilege limits access, defense in depth adds multiple security layers, and continuous auditing monitors activity.

2. Step 2: Evaluate options for best security practice

   Use least privilege IAM roles, enable defense in depth with multiple controls, and monitor with continuous auditing combines these principles correctly; others either grant excessive access or skip monitoring.

3. Final Answer:

   Use least privilege IAM roles, enable defense in depth with multiple controls, and monitor with continuous auditing -> Option A

4. Quick Check:

   Least privilege + defense in depth + monitoring = strong security [OK]

Hint: Combine least privilege, defense in depth, and monitoring [OK]

Common Mistakes:

• Granting overly broad roles
• Ignoring monitoring and auditing
• Relying only on default settings