[ PROMPT_NODE_25351 ]
Security Architecture
[ SKILL_DOCUMENTATION ]
# 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: "[email protected]"
roles: ["Admin"]
- email: "[email protected]"
roles: ["Manager"]
- email: "[email protected]"
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:
Source: claude-code-templates (MIT). See About Us for full credits.