SPC SubjectUnit 1
SPC Unit 1: Complete Concepts Guide
Unit 1: Fundamentals of Cloud Security, Design and Architecture for Cloud -> Generated and Prepared By Thiruselvan (ThiruXD)
TABLE OF CONTENTS
- Overview of Cloud Security
- Security Services in Cloud Computing
- Security Design Principles for Cloud Computing
- Comprehensive Data Protection
- End-to-End Access Control
- Common Attack Vectors and Threats
- Network and Storage Security
- Secure Isolation Strategies, Virtualization Strategies
- Inter-tenant Network Segmentation Strategies
- Data Protection Techniques
- Data Retention, Deletion, and Archiving Procedures for Tenant Data
- Public Key Infrastructure (PKI) and Key Management
Chapter Overview
This comprehensive guide covers the foundational concepts of cloud security design and architecture as presented in Unit I. The material is organized to provide a structured understanding of cloud security principles, controls, and implementation strategies.
1. Core Concepts
1.1 What is Cloud Security?
Definition: Cloud security is the collection of policies, technologies, processes, and controls used to protect cloud-based systems, data, and services.
Key Components:
- Identity and Access Management (IAM)
- Encryption
- Network security
- Data protection
- Monitoring
- Secure configuration
- Compliance
- Incident response
- Tenant isolation
Why Cloud Security is Different:
- Systems are no longer limited to internal data centers
- Users access services from multiple devices and locations
- Applications run across multiple regions
- Data moves between services through APIs
- Security must be identity-centered, automated, and continuously monitored
1.2 The Shared Responsibility Model
This model divides security responsibilities between the cloud provider and the customer:
| Service Model | Provider Responsibility | Customer Responsibility |
|---|---|---|
| IaaS | Physical infrastructure, hardware, networking | OS, applications, identities, data |
| PaaS | Infrastructure + platform | Applications, data, access policies |
| SaaS | Most of the application environment | Users, data classification, access policies, safe usage |
Important Principle: Cloud security is NOT only the provider’s responsibility. Customers must configure services securely, manage identities carefully, protect data, and monitor usage.
2. Security Services in Cloud Computing
Major Service Categories:
| Category | Examples | Function |
|---|---|---|
| Identity & Access | IAM, SSO, MFA, Directory Service | Manage users, groups, roles, permissions |
| Network Security | Firewall, WAF, Security Groups, Network ACLs | Filter traffic, protect endpoints |
| Data Protection | KMS, Secret Manager, Backup, DLP | Protect data, keys, secrets, recovery |
| Threat Detection | Cloud Threat Detection, Vulnerability Scanning | Find suspicious activity, exposed resources |
| Logging & Monitoring | Cloud Logs, SIEM, Metrics | Collect events for investigation |
| Compliance | Security Posture Management, Policy Enforcement | Check regulatory compliance |
| Resilience | Backup, Replication, DR | Support availability during failures |
Best Practice: Enable logging, MFA, encryption, and backup early in the cloud design phase.
3. Security Design Principles
Core Principles:
| Principle | Meaning | Cloud Example |
|---|---|---|
| Shared Responsibility | Understand what provider secures vs. customer secures | Customer configures IAM even when provider secures hardware |
| Defense in Depth | Use multiple layers of protection | IAM + Private Network + Encryption + WAF + Logging |
| Least Privilege | Grant only needed permissions | Backup service can read storage but cannot delete databases |
| Secure by Default | Start with restricted access | Storage buckets are private by default |
| Zero Trust | Verify every access request | Require MFA and policy checks even from internal networks |
| Segmentation | Separate workloads, tenants, trust zones | Use separate VPCs for web, app, database tiers |
| Automation | Use templates and policies to reduce manual errors | Infrastructure as Code with security checks |
| Continuous Monitoring | Observe logs, metrics, behavior | Generate alerts for unusual login or public exposure |
4. Comprehensive Data Protection
Data Lifecycle Protection:
| Data State | Risk | Protection Technique |
|---|---|---|
| Data at Rest | Unauthorized access to stored files | Storage encryption, access policies, backup protection |
| Data in Transit | Interception during network transfer | TLS, VPN, private connectivity, certificate validation |
| Data in Use | Exposure during processing | Least privilege, secure enclaves, application controls |
| Data Shared Externally | Accidental sharing | DLP, expiration links, data classification, tokenization |
| Data Archived | Long-term exposure | Retention schedule, encrypted archive, access review |
| Data Deleted | Recoverable remnants | Secure deletion, crypto-shredding, documented process |
Data Protection Strategies:
- Classification - Identify data sensitivity (public, internal, confidential, PII, financial, medical, restricted)
- Minimization - Collect only necessary information
- Encryption - Protect at rest, in transit, and in use
- Access Control - Restrict who can view or change data
- Backup & Recovery - Tested backups protected from deletion
- DLP & Monitoring - Detect unauthorized sharing
- Retention & Deletion - Keep data only as long as required
5. End-to-End Access Control
Access Control Components:
| Component | Description | Example |
|---|---|---|
| Authentication | Verifies identity | Password + MFA, SSO, certificate-based identity |
| Authorization | Determines allowed actions | Read-only role for auditors; admin role for security team |
| Policy Enforcement | Applies access rules | Deny public storage access unless approved |
| Privileged Access | Controls administrative accounts | Just-in-time admin access with approval and expiry |
| Access Review | Checks if access is still needed | Remove accounts of completed students or ex-employees |
| Audit Logging | Records access attempts | Log successful and failed console/API actions |
Pseudo-Policy Example:
ALLOW user_group = "BackupOperators"
ACTION = ["read_storage", "create_backup", "restore_backup"]
RESOURCE = "production-storage"
DENY ACTION = ["delete_storage", "change_encryption_key"]
CONDITION = "MFA required and request logged"6. Common Attack Vectors and Threats
Major Cloud Threats:
| Threat | Example | Main Control |
|---|---|---|
| Credential Theft | Attacker uses leaked access key | MFA, secret scanning, key rotation, least privilege |
| Misconfiguration | Public database or storage bucket | Policy checks, secure defaults, configuration scanning |
| Insecure API | API accepts unauthorized requests | API gateway, authentication, authorization, rate limiting |
| DDoS | Flood of traffic against web application | DDoS protection, CDN, WAF, scaling, rate limits |
| Malware/Ransomware | Compromised VM encrypts files | Endpoint protection, backups, segmentation, patching |
| Insider Threat | Authorized user downloads excessive data | DLP, monitoring, access review, separation of duties |
| Supply Chain Attack | Compromised container image deployed | Image scanning, trusted registries, signed artifacts |
Three-Phase Threat Management:
- Prevention: Secure configuration, least privilege, policies
- Detection: Logging, anomaly detection, alerts
- Response: Containment, investigation, recovery, lessons learned
7. Network and Storage Security
Network Security Controls:
| Area | Control | Purpose |
|---|---|---|
| Virtual Network | VPC/VNet segmentation | Creates isolated network boundaries |
| Subnet Design | Public, private, data subnets | Separates internet-facing and internal resources |
| Firewall Rules | Security groups, network ACLs | Allows only necessary ports and directions |
| Private Connectivity | VPN, private link, direct connection | Reduces exposure to public internet |
Storage Security Controls:
| Type | Controls | Purpose |
|---|---|---|
| Object Storage | Bucket policy, encryption, versioning | Prevents public leakage, supports recovery |
| Database Storage | Encryption, backup, private endpoint | Protects confidentiality and availability |
| Backup Storage | Immutable backups, retention lock | Defends against ransomware and accidental deletion |
Practical Design Rule: Expose only the minimum required endpoints to the internet. Keep databases, message queues, internal APIs, and backup storage in private zones.
8. Secure Isolation Strategies
Isolation Layers:
| Layer | Technique | Example |
|---|---|---|
| Organizational | Separate accounts/projects | Production, development, testing in separate accounts |
| Network | Virtual networks, subnets, firewalls | Database subnet not reachable from internet |
| Identity | Separate roles and service accounts | Application role cannot access security audit logs |
| Compute | VM isolation, container namespaces | Untrusted jobs run in restricted containers |
| Data | Separate storage, row-level rules | Each tenant can read only their own records |
| Key Management | Separate keys per tenant | Tenant A data encrypted with Tenant A key |
Virtualization Security:
| Model | Security Consideration |
|---|---|
| Virtual Machine | Patch OS, secure images, restrict management ports |
| Container | Scan images, avoid privileged mode, protect secrets |
| Serverless | Secure functions, IAM roles, triggers, environment variables |
| Bare Metal | Useful for strict compliance or licensing needs |
| Confidential Computing | Protects data in use with hardware-backed TEE |
Important: Containers are not automatically more secure than VMs. Their security depends on image quality, host security, runtime settings, network policy, and secrets handling.
9. Inter-Tenant Segmentation Strategies
Segmentation Approaches:
| Strategy | How It Works | Use Case |
|---|---|---|
| Separate Virtual Networks | Each tenant gets isolated network | Large enterprise tenants or regulated workloads |
| Subnet Segmentation | Web, app, data layers use separate subnets | Three-tier application security |
| Security Groups/Firewall Rules | Only approved traffic allowed between zones | Allow app-to-database traffic on required port |
| Private Endpoints | Access managed services through private paths | Private database or storage access |
| Tenant-Aware Authorization | Application checks tenant identity | Multi-tenant SaaS with shared application layer |
| Microsegmentation | Fine-grained control between workloads | High-security environments and zero trust |
Note: In SaaS applications, network isolation alone isn’t enough - the application must also enforce tenant identity, tenant IDs, row-level access, and audit logging.
10. Data Protection Techniques
10.1 Encryption
| Technique | Description | Example |
|---|---|---|
| Symmetric | Same key for encryption and decryption | AES-based storage encryption |
| Asymmetric | Public key encrypts; private key decrypts | TLS certificates, digital signatures |
| Hashing | One-way transformation for verification | Password hashing, file integrity checks |
| TLS | Protocol for secure network communication | HTTPS access to web applications |
| Envelope Encryption | Data key encrypts data; master key encrypts data key | Cloud KMS protecting storage encryption keys |
| Client-Side | Data encrypted before reaching cloud provider | Sensitive file encrypted before upload |
Important: Encryption protects confidentiality but doesn’t replace access control, logging, backup, or secure application design.
10.2 Data Redaction
Removes or masks sensitive information from documents, logs, or reports.
| Type | Example | Use Case |
|---|---|---|
| Full Redaction | Name: [REDACTED] | Remove sensitive fields from reports |
| Partial Redaction | Phone: ******7890 | Show limited identifying information |
| Dynamic Redaction | Different users see different detail levels | Admin sees full value; support sees masked |
| Log Redaction | Password parameter removed from logs | Prevent secrets in monitoring systems |
10.3 Tokenization
Replaces sensitive data with non-sensitive tokens stored in a secured vault.
| Original Data | Tokenized Form | Why It Helps |
|---|---|---|
| Card number | tok_pay_7H9K2 | Process payments without storing card numbers |
| Student ID | tok_stu_20491 | Link records without exposing actual identifier |
| Bank account | tok_acc_83FA1 | Customer service tools use token |
| Patient number | tok_med_01X9B | Research data pseudonymized before analysis |
Comparison: Encryption is reversible using a key. Tokenization is reversible only through a controlled token mapping system. Both require strong access control.
10.4 Obfuscation
Makes data, code, or configuration harder to understand.
| Technique | Description | Example |
|---|---|---|
| Masking | Hide part of the value | Email: a***@example.com |
| Substitution | Replace real value with fake | Amit → User001 |
| Shuffling | Rearrange values between records | Shuffle dates of birth in test dataset |
| Generalization | Reduce precision | Exact address → city only |
| Code Obfuscation | Make code harder to understand | Renaming variables, restructuring code |
| Synthetic Data | Generate artificial records | Fake student dataset for lab practice |
11. Data Retention, Deletion, and Archiving
Key Procedures:
| Procedure | What It Defines | Security Requirement |
|---|---|---|
| Retention Policy | How long each category is kept | Must match legal, academic, or business requirements |
| Archiving | How inactive data is moved to long-term storage | Archive must remain encrypted and access-controlled |
| Deletion Request | How a tenant requests removal | Verify tenant identity and authorization |
| Secure Deletion | How data is removed or made unrecoverable | Delete records, remove indexes, manage backups and keys |
| Crypto-shredding | Destroy encryption key to make data unreadable | Useful when direct deletion is difficult |
| Audit Evidence | Proof that deletion/archiving was completed | Maintain logs without exposing deleted data |
Best Practice: Retention and deletion should be documented before collecting tenant data. Otherwise, organizations may keep sensitive information longer than necessary.
12. PKI and Key Management
Public Key Infrastructure (PKI):
The framework for creating, managing, distributing, validating, and revoking digital certificates.
Components:
| Element | Purpose | Security Consideration |
|---|---|---|
| Certificate Authority | Issues and signs certificates | Must be trusted and protected |
| Certificate | Binds identity to a public key | Renew before expiry, revoke if compromised |
| Public Key | Shared key for encryption/verification | Can be distributed openly |
| Private Key | Secret key for decryption/signing | Must be protected, never exposed in code or logs |
Key Management Lifecycle:
- Generation - Create keys using secure cryptographic standards
- Storage - Protect keys in secure services
- Distribution - Securely transmit keys when necessary
- Use - Apply keys for encryption/decryption with logging
- Rotation - Replace old keys with new keys periodically
- Backup - Maintain secure copies for recovery
- Revocation - Invalidate compromised keys
- Expiration - Set key expiry dates
- Destruction - Securely destroy keys when no longer needed
Cloud Key Management Services:
| Service | Function | Security Features |
|---|---|---|
| KMS | Manages cryptographic keys in cloud | IAM policies, rotation, audit logs |
| HSM | Hardware-backed secure key storage | High-value keys, compliance requirements |
| Secret Manager | Stores secrets, passwords, API keys | Encrypted storage, rotation, access logging |
Best Practice: Store secrets and private keys in a dedicated key management or secrets management service. Never hard-code passwords, API keys, or private keys in source code.
SPC Index
Complete unit-wise directory mapping interactive concept guides, question banks, and source PDFs -> Generated and Prepared By Thiruselvan (ThiruXD).
SPC Unit 1: Questions & Answers
Unit 1: Fundamentals of Cloud Security, Design and Architecture for Cloud -> Generated and Prepared By Thiruselvan (ThiruXD)