davila7--claude-code-templates/cli-tool/components/skills/development/security-compliance/reference/security-architecture.md

# Security Architecture & Design

## Zero Trust Architecture

### Core Principles

Zero Trust is a security model based on the principle of "never trust, always verify." It assumes that threats exist both inside and outside the network.

**Foundational Tenets**:
1. **Verify explicitly** - Always authenticate and authorize based on all available data points
2. **Use least privilege access** - Limit user access with Just-In-Time and Just-Enough-Access (JIT/JEA)
3. **Assume breach** - Minimize blast radius and segment access. Verify end-to-end encryption

### Zero Trust Architecture Components

```
┌─────────────────────────────────────────────────────────────┐
│                     Control Plane                            │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐      │
│  │   Identity   │  │    Device    │  │  Application │      │
│  │  Management  │  │  Management  │  │   Registry   │      │
│  └──────────────┘  └──────────────┘  └──────────────┘      │
│                                                               │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐      │
│  │    Policy    │  │   Threat     │  │   Analytics  │      │
│  │    Engine    │  │ Intelligence │  │   & Logging  │      │
│  └──────────────┘  └──────────────┘  └──────────────┘      │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│                      Data Plane                              │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐      │
│  │  Policy      │  │  Policy      │  │  Policy      │      │
│  │  Enforcement │→ │  Enforcement │→ │  Enforcement │      │
│  │  Point (PEP) │  │  Point (PEP) │  │  Point (PEP) │      │
│  └──────────────┘  └──────────────┘  └──────────────┘      │
│        ↓                  ↓                  ↓               │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐      │
│  │   Resource   │  │   Resource   │  │   Resource   │      │
│  │   (App/DB)   │  │   (App/DB)   │  │   (App/DB)   │      │
│  └──────────────┘  └──────────────┘  └──────────────┘      │
└─────────────────────────────────────────────────────────────┘
```

### Zero Trust Access Flow

```
1. User/Device requests access to resource
   ↓
2. Policy Enforcement Point (PEP) intercepts request
   ↓
3. PEP queries Policy Engine
   ↓
4. Policy Engine evaluates:
   - Identity verification (MFA)
   - Device posture (compliant, patched, encrypted)
   - Location and network context
   - Resource sensitivity
   - Risk score (based on behavior analytics)
   ↓
5. Policy Decision Point (PDP) makes decision:
   - Allow (with session time limit)
   - Deny
   - Allow with step-up authentication
   ↓
6. Continuous verification during session
   - Monitor for anomalous behavior
   - Re-authenticate periodically
   - Revoke access if risk increases
```

### Zero Trust Implementation Roadmap

**Phase 1: Foundation (Months 1-3)**
- Implement strong identity and access management (IAM)
- Deploy multi-factor authentication (MFA) everywhere
- Create comprehensive asset inventory
- Establish baseline logging and monitoring

**Phase 2: Visibility (Months 4-6)**
- Map all data flows and dependencies
- Implement network traffic analysis
- Deploy endpoint detection and response (EDR)
- Establish user and entity behavior analytics (UEBA)

**Phase 3: Segmentation (Months 7-9)**
- Implement network micro-segmentation
- Create security zones based on data sensitivity
- Apply least privilege access policies
- Implement application-layer controls

**Phase 4: Automation (Months 10-12)**
- Automate policy enforcement
- Implement SOAR for incident response
- Deploy continuous compliance monitoring
- Integrate threat intelligence feeds

**Phase 5: Optimization (Ongoing)**
- Continuous policy refinement
- Regular access reviews and certifications
- Threat hunting and proactive defense
- Measure and improve security posture

---

## Defense in Depth

### Security Layers

```
Layer 7: User Education & Awareness
         ↓ (Social engineering, phishing)
Layer 6: Physical Security
         ↓ (Access badges, surveillance, locks)
Layer 5: Perimeter Security
         ↓ (Firewall, IDS/IPS, WAF)
Layer 4: Network Security
         ↓ (Segmentation, VLANs, ACLs)
Layer 3: Endpoint Security
         ↓ (EDR, antivirus, host firewall)
Layer 2: Application Security
         ↓ (Input validation, authentication, secure coding)
Layer 1: Data Security
         ↓ (Encryption, DLP, access controls)
```

### Security Control Types by Layer

**Preventive Controls** (Stop attacks before they occur):
- Firewalls and network segmentation
- Multi-factor authentication
- Encryption at rest and in transit
- Secure coding practices
- Access control lists (ACLs)
- Security awareness training

**Detective Controls** (Identify attacks when they occur):
- Security Information and Event Management (SIEM)
- Intrusion Detection Systems (IDS)
- Log monitoring and analysis
- File integrity monitoring (FIM)
- Vulnerability scanning
- User and Entity Behavior Analytics (UEBA)

**Corrective Controls** (Fix issues after detection):
- Incident response procedures
- Patch management
- Malware removal
- Account lockout and password reset
- Backup and recovery
- Forensic analysis

**Deterrent Controls** (Discourage attackers):
- Warning banners
- Security policies and consequences
- Legal agreements and NDAs
- Audit trails and accountability

---

## Secure Network Architecture

### Network Segmentation Design

```
Internet
   ↓
┌─────────────────────────────────────────────────────────────┐
│  DMZ (Demilitarized Zone)                                   │
│  - Web servers (public-facing)                              │
│  - Reverse proxies                                          │
│  - Email gateways                                           │
│  Security: WAF, DDoS protection, IDS                        │
└─────────────────────────────────────────────────────────────┘
   ↓ (Firewall)
┌─────────────────────────────────────────────────────────────┐
│  Application Tier                                           │
│  - Application servers                                      │
│  - API gateways                                             │
│  - Microservices                                            │
│  Security: Application firewall, API security               │
└─────────────────────────────────────────────────────────────┘
   ↓ (Firewall)
┌─────────────────────────────────────────────────────────────┐
│  Data Tier                                                  │
│  - Database servers                                         │
│  - Data warehouses                                          │
│  - File storage                                             │
│  Security: Database firewall, encryption, DLP               │
└─────────────────────────────────────────────────────────────┘
   ↓ (Firewall)
┌─────────────────────────────────────────────────────────────┐
│  Management Network (Separate VLAN)                         │
│  - Jump servers/bastion hosts                              │
│  - Monitoring systems                                       │
│  - Backup infrastructure                                    │
│  Security: PAM, MFA, session recording                      │
└─────────────────────────────────────────────────────────────┘
```

### Micro-segmentation Strategy

Traditional segmentation creates large security zones. Micro-segmentation creates granular controls around individual workloads.

**Benefits**:
- Limits lateral movement
- Reduces blast radius of breaches
- Enables Zero Trust networking
- Improves compliance (isolate regulated data)

**Implementation Approaches**:

1. **Network-based** (VLANs, ACLs, firewalls)
   - Pros: Mature technology, hardware-based
   - Cons: Static, difficult to manage at scale

2. **Software-Defined** (SDN, NSX, Cisco ACI)
   - Pros: Dynamic, policy-based, scales well
   - Cons: Requires new infrastructure, complexity

3. **Host-based** (iptables, Windows Firewall, Security Groups)
   - Pros: Granular, follows workloads, cloud-native
   - Cons: Requires agent management

**Micro-segmentation Policy Example**:

```yaml
# Allow web tier to communicate with app tier only on port 443
source:
  tier: web
  environment: production
destination:
  tier: app
  environment: production
protocol: tcp
port: 443
action: allow

# Deny all other traffic from web tier to app tier
source:
  tier: web
destination:
  tier: app
action: deny
```

### Secure Remote Access Architecture

```
Remote Users
   ↓
┌─────────────────────────────────────────────────────────────┐
│  Step 1: Identity Verification                              │
│  - MFA (TOTP, push, biometric)                             │
│  - Device posture check (patch level, encryption)          │
│  - Conditional access policies (location, risk score)      │
└─────────────────────────────────────────────────────────────┘
   ↓
┌─────────────────────────────────────────────────────────────┐
│  Step 2: Secure Connection                                  │
│  Options:                                                    │
│  A) VPN (IPsec, SSL VPN) - Network-level access            │
│  B) ZTNA (Zero Trust Network Access) - Application access  │
│  C) Privileged Access Workstation (PAW) for admins         │
└─────────────────────────────────────────────────────────────┘
   ↓
┌─────────────────────────────────────────────────────────────┐
│  Step 3: Access Broker                                      │
│  - Evaluate access policies                                 │
│  - Grant least privilege access                            │
│  - Establish session with time limit                       │
│  - Monitor session for anomalies                           │
└─────────────────────────────────────────────────────────────┘
   ↓
Corporate Resources (Applications, Files, Databases)
```

**VPN vs. ZTNA Comparison**:

| Aspect | VPN | ZTNA |
|--------|-----|------|
| Access model | Network-level | Application-level |
| Trust model | Implicit trust once connected | Continuous verification |
| Lateral movement | Possible | Prevented |
| Deployment | On-premises appliance | Cloud-native service |
| User experience | Full network access | Seamless app access |
| Security | Perimeter-based | Identity-based |

---

## Cloud Security Architecture

### Multi-Cloud Security Architecture

```
┌─────────────────────────────────────────────────────────────┐
│  Centralized Security Management                            │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐   │
│  │   SIEM   │  │   CSPM   │  │   CASB   │  │   PAM    │   │
│  └──────────┘  └──────────┘  └──────────┘  └──────────┘   │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌──────────────────┬──────────────────┬──────────────────────┐
│   AWS            │   Azure          │   GCP                │
├──────────────────┼──────────────────┼──────────────────────┤
│ • Security Hub   │ • Defender       │ • Security Command   │
│ • GuardDuty      │ • Sentinel       │   Center             │
│ • IAM            │ • Entra ID       │ • Cloud IAM          │
│ • KMS            │ • Key Vault      │ • Cloud KMS          │
│ • WAF            │ • WAF            │ • Cloud Armor        │
│ • VPC Flow Logs  │ • NSG Flow Logs  │ • VPC Flow Logs      │
└──────────────────┴──────────────────┴──────────────────────┘
```

### Shared Responsibility Model

**Cloud Provider Responsibilities** (Security OF the cloud):
- Physical security of data centers
- Hardware and infrastructure
- Network infrastructure
- Hypervisor and virtualization layer
- Managed service security (e.g., RDS, DynamoDB)

**Customer Responsibilities** (Security IN the cloud):
- Data encryption and classification
- Identity and access management (IAM)
- Application security and patching
- Network configuration and firewalls
- Operating system security (for IaaS)
- Compliance and governance

**Shared Responsibilities** (varies by service model):
- IaaS (e.g., EC2): Customer manages OS and above
- PaaS (e.g., App Service): Customer manages application and data
- SaaS (e.g., Office 365): Customer manages data and access policies

### Cloud Security Best Practices

**Identity & Access Management**:
```bash
# Enforce MFA for all users
aws iam create-virtual-mfa-device --virtual-mfa-device-name root-mfa

# Use least privilege IAM policies
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "s3:GetObject",
      "s3:PutObject"
    ],
    "Resource": "arn:aws:s3:::my-bucket/specific-prefix/*"
  }]
}

# Enable IAM Access Analyzer
aws accessanalyzer create-analyzer --analyzer-name my-analyzer --type ACCOUNT

# Rotate access keys regularly (max 90 days)
aws iam update-access-key --access-key-id AKIAIOSFODNN7EXAMPLE --status Inactive
```

**Data Encryption**:
```bash
# Enable S3 bucket encryption by default
aws s3api put-bucket-encryption \
  --bucket my-bucket \
  --server-side-encryption-configuration '{
    "Rules": [{
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "aws:kms",
        "KMSMasterKeyID": "arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012"
      },
      "BucketKeyEnabled": true
    }]
  }'

# Enable EBS encryption by default
aws ec2 enable-ebs-encryption-by-default --region us-east-1

# Enable RDS encryption at rest
aws rds create-db-instance \
  --db-instance-identifier mydb \
  --storage-encrypted \
  --kms-key-id arn:aws:kms:us-east-1:123456789012:key/12345678
```

**Network Security**:
```bash
# Create security group with minimal access
aws ec2 create-security-group \
  --group-name my-app-sg \
  --description "App tier security group" \
  --vpc-id vpc-12345678

# Only allow traffic from specific sources
aws ec2 authorize-security-group-ingress \
  --group-id sg-12345678 \
  --protocol tcp \
  --port 443 \
  --source-group sg-87654321  # Only from load balancer SG

# Enable VPC Flow Logs
aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-12345678 \
  --traffic-type ALL \
  --log-destination-type s3 \
  --log-destination arn:aws:s3:::my-flow-logs-bucket
```

**Monitoring & Logging**:
```bash
# Enable CloudTrail for all regions
aws cloudtrail create-trail \
  --name my-trail \
  --s3-bucket-name my-cloudtrail-bucket \
  --is-multi-region-trail

# Enable GuardDuty
aws guardduty create-detector --enable

# Enable AWS Config
aws configservice put-configuration-recorder \
  --configuration-recorder name=default,roleARN=arn:aws:iam::123456789012:role/config-role
```

### Container Security Architecture

```
┌─────────────────────────────────────────────────────────────┐
│  Build Time Security                                        │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐      │
│  │ Base Image   │→ │ Vulnerability│→ │  Image       │      │
│  │ Scanning     │  │  Scanning    │  │  Signing     │      │
│  └──────────────┘  └──────────────┘  └──────────────┘      │
│  Tools: Trivy, Snyk, Clair, Anchore                         │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│  Registry Security                                          │
│  • Private registries (ECR, ACR, GCR, Harbor)              │
│  • Image signing and verification (Cosign, Notary)        │
│  • Access control (IAM, RBAC)                              │
│  • Vulnerability scanning on push                          │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│  Runtime Security                                           │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐      │
│  │  Admission   │  │   Runtime    │  │   Network    │      │
│  │  Control     │  │  Protection  │  │   Policies   │      │
│  └──────────────┘  └──────────────┘  └──────────────┘      │
│  Tools: OPA, Falco, Sysdig, Calico                          │
└─────────────────────────────────────────────────────────────┘
```

**Kubernetes Security Best Practices**:

```yaml
# 1. Use Pod Security Standards
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

# 2. Run containers as non-root
apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 1000
  containers:
  - name: app
    image: myapp:1.0
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL
      readOnlyRootFilesystem: true

# 3. Use Network Policies
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: app-network-policy
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: loadbalancer
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 5432

# 4. Use Resource Limits
apiVersion: v1
kind: Pod
metadata:
  name: resource-limited-pod
spec:
  containers:
  - name: app
    image: myapp:1.0
    resources:
      limits:
        cpu: "1"
        memory: "512Mi"
      requests:
        cpu: "500m"
        memory: "256Mi"

# 5. Enable audit logging
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata
  resources:
  - group: ""
    resources: ["secrets", "configmaps"]
- level: RequestResponse
  users: ["system:serviceaccount:kube-system:*"]
```

---

## Data Security Architecture

### Data Classification Framework

```
┌─────────────────────────────────────────────────────────────┐
│  Level 4: Highly Confidential (Top Secret)                 │
│  • National security information                            │
│  • Encryption: AES-256, encryption at rest AND in transit  │
│  • Access: Named individuals only, MFA + biometric         │
│  • Storage: Air-gapped systems, hardware encryption        │
│  • Retention: Indefinite or per legal requirements         │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│  Level 3: Confidential (Restricted)                        │
│  • PII, PHI, financial data, trade secrets                 │
│  • Encryption: AES-256, encryption at rest and in transit  │
│  • Access: Role-based, MFA required, annual certification  │
│  • Storage: Encrypted databases, secure file shares        │
│  • Retention: Per compliance requirements (7 years)        │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│  Level 2: Internal Use Only                                │
│  • Internal documents, employee data, project plans        │
│  • Encryption: TLS in transit, optional at rest            │
│  • Access: All employees, SSO authentication               │
│  • Storage: Corporate file shares, intranet                │
│  • Retention: 3-5 years                                    │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│  Level 1: Public                                            │
│  • Marketing materials, published documentation            │
│  • Encryption: Optional                                    │
│  • Access: Public                                          │
│  • Storage: Public website, public repositories            │
│  • Retention: Indefinite                                   │
└─────────────────────────────────────────────────────────────┘
```

### Encryption Architecture

**Encryption at Rest**:

```
Application Layer Encryption (ALE)
↓
Database Layer Encryption (TDE - Transparent Data Encryption)
↓
File System Encryption (dm-crypt, BitLocker, FileVault)
↓
Disk/Volume Encryption (LUKS, BitLocker)
↓
Hardware Encryption (Self-Encrypting Drives - SEDs)
```

**Encryption in Transit**:

```python
# TLS 1.3 configuration (nginx)
ssl_protocols TLSv1.3;
ssl_ciphers 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256';
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;

# HSTS header (force HTTPS)
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

# Certificate pinning (optional, advanced)
add_header Public-Key-Pins 'pin-sha256="base64+primary=="; pin-sha256="base64+backup=="; max-age=5184000; includeSubDomains';
```

**Key Management Architecture**:

```
┌─────────────────────────────────────────────────────────────┐
│  Key Management Service (KMS)                               │
│                                                              │
│  ┌──────────────────────────────────────────────────────┐  │
│  │  Master Keys (Customer Master Keys - CMKs)           │  │
│  │  - Stored in Hardware Security Module (HSM)         │  │
│  │  - Never leave HSM in plaintext                     │  │
│  │  - Used to encrypt Data Encryption Keys (DEKs)      │  │
│  └──────────────────────────────────────────────────────┘  │
│                              ↓                               │
│  ┌──────────────────────────────────────────────────────┐  │
│  │  Data Encryption Keys (DEKs)                        │  │
│  │  - Generated per object/database/volume             │  │
│  │  - Encrypted by CMK (envelope encryption)           │  │
│  │  - Stored alongside encrypted data                  │  │
│  └──────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│  Encrypted Data                                             │
│  - Application databases                                    │
│  - File storage                                             │
│  - Backups                                                  │
└─────────────────────────────────────────────────────────────┘
```

**Envelope Encryption Example (AWS KMS)**:

```python
import boto3
import base64

kms_client = boto3.client('kms')

# Generate data encryption key
response = kms_client.generate_data_key(
    KeyId='arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012',
    KeySpec='AES_256'
)

# Plaintext DEK (use to encrypt data, then discard)
plaintext_dek = response['Plaintext']

# Encrypted DEK (store alongside encrypted data)
encrypted_dek = response['CiphertextBlob']

# Encrypt data with plaintext DEK
from cryptography.fernet import Fernet
cipher = Fernet(base64.urlsafe_b64encode(plaintext_dek))
encrypted_data = cipher.encrypt(b"Sensitive data")

# Store encrypted_data and encrypted_dek together
# Discard plaintext_dek from memory

# To decrypt later:
# 1. Decrypt the DEK using KMS
decrypt_response = kms_client.decrypt(CiphertextBlob=encrypted_dek)
plaintext_dek_decrypted = decrypt_response['Plaintext']

# 2. Use DEK to decrypt data
cipher = Fernet(base64.urlsafe_b64encode(plaintext_dek_decrypted))
decrypted_data = cipher.decrypt(encrypted_data)
```

### Data Loss Prevention (DLP) Architecture

```
┌─────────────────────────────────────────────────────────────┐
│  Data Discovery & Classification                            │
│  • Scan repositories for sensitive data (PII, PHI, PCI)    │
│  • Apply classification labels automatically               │
│  • Tools: Microsoft Purview, Varonis, BigID               │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│  Policy Enforcement Points                                  │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐      │
│  │   Endpoint   │  │   Network    │  │    Cloud     │      │
│  │     DLP      │  │     DLP      │  │     DLP      │      │
│  └──────────────┘  └──────────────┘  └──────────────┘      │
│  • Block file transfers with PII                           │
│  • Prevent copy/paste of sensitive data                    │
│  • Encrypt emails containing confidential data            │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│  Monitoring & Alerting                                      │
│  • Log DLP policy violations                               │
│  • Alert security team for high-risk events               │
│  • User education on policy violations                     │
└─────────────────────────────────────────────────────────────┘
```

**DLP Policy Example**:

```yaml
policy:
  name: "Prevent PII Exfiltration"
  description: "Block transfer of SSNs via email or cloud storage"

  content_detection:
    - type: pattern
      pattern: '\d{3}-\d{2}-\d{4}'  # SSN pattern
      confidence: high
    - type: keyword
      keywords: ["SSN", "Social Security Number"]
      proximity: 50  # characters

  actions:
    email:
      - block_send
      - encrypt_if_internal
      - notify_sender
      - alert_security_team

    cloud_storage:
      - block_upload
      - notify_user
      - log_incident

    endpoint:
      - block_copy_to_usb
      - block_print
      - allow_with_justification

  exceptions:
    - group: "HR Department"
      action: allow_with_audit
    - application: "Payroll System"
      action: allow
```

---

## Identity & Access Management (IAM) Architecture

### Authentication Architecture

```
┌─────────────────────────────────────────────────────────────┐
│  Identity Provider (IdP)                                    │
│  • Okta, Azure AD, Auth0, Google Workspace                 │
│  • Central user directory (LDAP, AD)                       │
│  • MFA enforcement                                         │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│  Authentication Protocol                                     │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐      │
│  │    SAML      │  │    OAuth     │  │    OIDC      │      │
│  │     2.0      │  │     2.0      │  │ (OpenID      │      │
│  │              │  │              │  │  Connect)    │      │
│  └──────────────┘  └──────────────┘  └──────────────┘      │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│  Applications & Services                                    │
│  • SaaS applications (Service Provider in SAML)            │
│  • Internal web applications                               │
│  • APIs (OAuth 2.0 protected)                              │
│  • Infrastructure (SSH, RDP via certificates)             │
└─────────────────────────────────────────────────────────────┘
```

**Multi-Factor Authentication (MFA) Methods**:

```
Tier 1 (Most Secure):
├─ Hardware Security Keys (FIDO2/WebAuthn: YubiKey, Titan)
├─ Biometric (Face ID, Touch ID, Windows Hello)
└─ Smart Cards with PKI

Tier 2 (Secure):
├─ Authenticator Apps (TOTP: Google Authenticator, Authy)
├─ Push Notifications (Duo, Okta Verify)
└─ Mobile Device Certificates

Tier 3 (Less Secure, Avoid):
├─ SMS One-Time Passcodes (vulnerable to SIM swapping)
└─ Email Codes
```

### Authorization Models

**Role-Based Access Control (RBAC)**:

```yaml
# Example: Enterprise application RBAC
roles:
  - name: "Admin"
    permissions:
      - "users:read"
      - "users:write"
      - "users:delete"
      - "settings:write"
      - "audit_logs:read"

  - name: "Manager"
    permissions:
      - "users:read"
      - "users:write"
      - "reports:read"
      - "reports:write"

  - name: "User"
    permissions:
      - "users:read_self"
      - "reports:read"

# User assignment
users:
  - email: "admin@company.com"
    roles: ["Admin"]

  - email: "manager@company.com"
    roles: ["Manager"]

  - email: "employee@company.com"
    roles: ["User"]
```

**Attribute-Based Access Control (ABAC)**:

```json
{
  "policy": "Allow read access to medical records",
  "effect": "Allow",
  "principal": {
    "attributes": {
      "department": "Healthcare",
      "role": "Doctor",
      "clearance_level": ">=3"
    }
  },
  "resource": {
    "type": "MedicalRecord",
    "attributes": {
      "sensitivity": "High"
    }
  },
  "action": "read",
  "conditions": {
    "time_of_day": "business_hours",
    "location": "on_premises OR vpn_connected",
    "device_compliance": "compliant"
  }
}
```

**Relationship-Based Access Control (ReBAC)**:

```python
# Example: Document sharing platform
# "User can edit a document if they are the owner OR a collaborator"

relationships = {
    "document:123": {
        "owner": "user:alice",
        "collaborators": ["user:bob", "user:charlie"]
    }
}

def can_edit(user, document):
    doc_rels = relationships.get(document)
    return (
        user == doc_rels["owner"] or
        user in doc_rels["collaborators"]
    )

# Using authorization service like Ory Keto or SpiceDB
# Tuple format: <object>#<relation>@<subject>
# "document:123#owner@user:alice"
# "document:123#collaborator@user:bob"
```

### Privileged Access Management (PAM)

```
┌─────────────────────────────────────────────────────────────┐
│  Just-In-Time (JIT) Access                                  │
│  1. User requests elevated access via portal               │
│  2. Manager approves (or auto-approved if policy allows)   │
│  3. User granted access for limited time (e.g., 4 hours)   │
│  4. Access automatically revoked after time expires        │
│  5. Session is recorded for audit                          │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│  Privileged Access Workstation (PAW)                        │
│  • Hardened jump server / bastion host                     │
│  • No internet access                                      │
│  • MFA required to access                                  │
│  • All sessions recorded                                   │
│  • Credential rotation after each session                  │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│  Target Systems                                             │
│  • Production databases                                    │
│  • Cloud admin consoles                                    │
│  • Network infrastructure                                  │
│  • Domain controllers                                      │
└─────────────────────────────────────────────────────────────┘
```

**PAM Best Practices**:

1. **Eliminate standing privileges**: Use JIT access instead of permanent admin rights
2. **Rotate credentials**: Auto-rotate privileged passwords after each session
3. **Session monitoring**: Record all privileged sessions for audit and forensics
4. **Break-glass procedures**: Emergency access when PAM is unavailable
5. **Separate admin accounts**: Never use privileged accounts for regular tasks
6. **Remove local admin rights**: Users should not have admin on their workstations

---

## Secure Software Development Lifecycle (SDLC)

See [application-security.md](./application-security.md) for detailed coverage of secure SDLC, DevSecOps, and application security practices.

---

## Security Architecture Review Checklist

### Network Architecture Review
- [ ] Network segmentation properly implemented (DMZ, app tier, data tier)
- [ ] Firewall rules follow least privilege (deny by default)
- [ ] No overly permissive security groups (0.0.0.0/0)
- [ ] VPN or ZTNA for remote access (no direct RDP/SSH from internet)
- [ ] Network traffic logging enabled (VPC Flow Logs, NSG Flow Logs)
- [ ] DDoS protection enabled for public-facing services
- [ ] WAF deployed for web applications
- [ ] IDS/IPS deployed and tuned

### Identity & Access Review
- [ ] MFA enforced for all users
- [ ] Privileged access managed (PAM solution in place)
- [ ] No shared accounts or default credentials
- [ ] Regular access reviews and certifications conducted
- [ ] Least privilege access enforced (RBAC/ABAC)
- [ ] Service accounts have minimal permissions
- [ ] SSO implemented for applications
- [ ] Password policy enforces complexity and rotation

### Data Protection Review
- [ ] Data classified and labeled
- [ ] Encryption at rest for sensitive data (AES-256)
- [ ] Encryption in transit (TLS 1.2+)
- [ ] Key management using KMS or HSM
- [ ] DLP policies enforced
- [ ] Database activity monitoring enabled
- [ ] Backups encrypted and tested regularly
- [ ] Data retention policies enforced

### Cloud Security Review
- [ ] Cloud Security Posture Management (CSPM) enabled
- [ ] Security services enabled (GuardDuty, Security Hub, Defender)
- [ ] S3 buckets not publicly accessible (unless required)
- [ ] CloudTrail/Activity Log enabled for all regions
- [ ] Automated remediation for misconfigurations
- [ ] Container images scanned for vulnerabilities
- [ ] Secrets not hardcoded in code or config
- [ ] Infrastructure as Code (IaC) security scanned

### Monitoring & Detection Review
- [ ] SIEM deployed and ingesting logs
- [ ] Critical security events generate alerts
- [ ] Log retention meets compliance requirements (typically 1 year)
- [ ] EDR deployed on all endpoints
- [ ] Network traffic monitored for anomalies
- [ ] Threat intelligence feeds integrated
- [ ] Regular threat hunting performed
- [ ] Security metrics tracked and reported

### Incident Response Review
- [ ] Incident response plan documented and tested
- [ ] Incident response team (CIRT) identified
- [ ] Playbooks created for common scenarios
- [ ] Forensic capabilities available
- [ ] Communication plan for breaches
- [ ] Regulatory notification procedures documented
- [ ] Tabletop exercises conducted annually
- [ ] Lessons learned process in place