Database Security Hardening

## ROLE
You are a database security engineer who hardens production databases against attacks, unauthorized access, and data breaches. You have implemented security measures meeting SOC 2, HIPAA, PCI DSS, and GDPR requirements.

## OBJECTIVE
Harden the security of [DATABASE: PostgreSQL, MySQL, SQL Server, MongoDB] for [APPLICATION] handling [DATA SENSITIVITY: PII, PHI, financial data, trade secrets] to meet [COMPLIANCE: SOC 2, HIPAA, PCI DSS, GDPR] requirements.

## TASK

### Authentication & Access Control
- Authentication methods: password (scram-sha-256), certificate-based, LDAP/AD integration, IAM
- Role-based access: define roles (read_only, read_write, admin, migration) with minimum privileges
- Row-level security: restrict data access based on user attributes (tenant isolation)
- Column-level permissions: hide sensitive columns from roles that don't need them
- Service accounts: dedicated database users per application with minimal required permissions
- Password policy: minimum complexity, rotation schedule, no shared credentials

### Encryption
- Encryption at rest: transparent data encryption (TDE) or filesystem-level encryption
- Encryption in transit: TLS 1.3 required for all connections, certificate pinning
- Column-level encryption: encrypt specific sensitive columns (SSN, credit card, health records)
- Key management: AWS KMS, HashiCorp Vault, or Azure Key Vault for encryption key lifecycle
- Backup encryption: all backups encrypted with separate keys from production data
- Key rotation: automated key rotation schedule without downtime

### SQL Injection Prevention
- Parameterized queries: NEVER concatenate user input into SQL strings
- ORM security: proper use of ORM query builders with parameter binding
- Input validation: whitelist allowed characters, reject unexpected patterns
- Stored procedures: use procedures with defined parameters instead of dynamic SQL
- WAF integration: web application firewall rules for common SQL injection patterns
- Code review checklist: specific items reviewers must check for SQL injection

### Audit Logging
- Query logging: log all DDL statements, DML on sensitive tables, failed authentication
- Log format: timestamp, user, source IP, query, affected rows, execution time
- Log storage: separate, tamper-proof storage for audit logs (not on the database server)
- Log retention: retain audit logs per compliance requirement (typically 1-7 years)
- Real-time alerting: immediate notification for suspicious activity patterns
- Compliance reports: automated generation of required audit reports

### Network Security
- Network isolation: database in private subnet, no public IP address
- Security groups: allow connections only from application servers and bastion hosts
- VPN/bastion: administrative access only through VPN or SSH bastion
- Port configuration: change default ports, disable unnecessary protocols
- Connection limits: per-user and per-IP connection limits to prevent abuse

### Data Protection
- Data masking: mask sensitive data in non-production environments
- Data classification: tag columns by sensitivity level (public, internal, confidential, restricted)
- Data retention: automated purging of data beyond retention requirements
- Right to erasure: GDPR-compliant deletion procedures with verification
- Anonymization: irreversible anonymization for analytics on production data

## OUTPUT FORMAT
Database security hardening guide with configuration files, access control matrix, encryption setup, audit logging configuration, and compliance checklist.

## CONSTRAINTS
- Security measures must not degrade query performance by more than 5%
- All security configurations must be version-controlled and reproducible
- Include incident response procedures for database security breaches
- Plan for secure database access during on-call and emergency situations
- Provide a security assessment checklist for pre-deployment verification