Security Features Quick Start

Overview

HeliosDB provides comprehensive security features including row-level security, column-level encryption, ABAC, and audit logging to protect sensitive data.

Key Concepts

Security Layers

1. Authentication: Who are you? (User identity)
2. Authorization: What can you do? (Permissions)
3. Encryption: How is data protected? (Data at rest/in transit)
4. Audit: Who did what? (Compliance tracking)

Quick Start

1. Enable Security Features

-- Check security status
SELECT setting, unit FROM pg_settings
WHERE name LIKE 'security%';

-- Enable column encryption
SET column_encryption_enabled = true;

-- Enable audit logging
SET audit_logging_enabled = true;

2. Row-Level Security (RLS)

RLS automatically filters rows based on user context.

-- Create a sales table
CREATE TABLE sales (
  id SERIAL PRIMARY KEY,
  salesperson VARCHAR(100),
  amount DECIMAL(10,2),
  customer VARCHAR(100)
);

-- Enable RLS
ALTER TABLE sales ENABLE ROW SECURITY;

-- Create policy: salespeople see only their own sales
CREATE POLICY sales_filter ON sales
  FOR SELECT
  USING (salesperson = current_user);

-- Insert test data
INSERT INTO sales (salesperson, amount, customer) VALUES
  ('alice', 1000, 'Company A'),
  ('bob', 2000, 'Company B');

-- As 'alice', only sees alice's rows
SELECT * FROM sales;  -- Returns 1 row

3. Column-Level Encryption

Encrypt sensitive columns transparently.

-- Create table with encrypted columns
CREATE TABLE customers (
  id SERIAL PRIMARY KEY,
  name VARCHAR(100),
  email ENCRYPTED VARCHAR(256),  -- Encrypted
  ssn ENCRYPTED VARCHAR(11),      -- Encrypted
  phone VARCHAR(20)
);

-- Insert data (encryption automatic)
INSERT INTO customers (name, email, ssn, phone) VALUES
  ('Alice', 'alice@example.com', '123-45-6789', '555-0100');

-- Queries work transparently
SELECT * FROM customers WHERE email = 'alice@example.com';

-- Check encryption status
SELECT column_name, is_encrypted
FROM information_schema.columns
WHERE table_name = 'customers';

4. Attribute-Based Access Control (ABAC)

Fine-grained access based on attributes.

-- Define attributes
CREATE ATTRIBUTE department VALUES ('Sales', 'Engineering', 'Finance');
CREATE ATTRIBUTE region VALUES ('EMEA', 'APAC', 'Americas');

-- Create policy
CREATE POLICY employee_access ON employees
  FOR SELECT
  USING (
    current_attribute('department') = employees.department
    OR current_attribute('region') = employees.region
  );

-- Assign attributes to users
GRANT ATTRIBUTE department:Sales TO alice;
GRANT ATTRIBUTE region:Americas TO alice;

5. Audit Logging

Track all database access for compliance.

-- Enable audit for sensitive table
AUDIT SELECT, INSERT, UPDATE, DELETE ON customers;

-- View audit logs
SELECT
  timestamp,
  user_name,
  operation,
  object_name,
  result
FROM pg_audit_log
WHERE object_name = 'customers'
ORDER BY timestamp DESC
LIMIT 10;

-- Archive logs for compliance
SELECT * FROM pg_audit_log
WHERE timestamp < CURRENT_TIMESTAMP - INTERVAL '90 days'
ORDER BY timestamp DESC;

Common Scenarios

Scenario 1: Protect PII

-- Create table with encrypted PII
CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  username VARCHAR(100),
  email ENCRYPTED VARCHAR(256),
  phone ENCRYPTED VARCHAR(20),
  ssn ENCRYPTED VARCHAR(11)
);

-- Only data owners can see full SSN
GRANT SELECT ON users TO data_owner;

Scenario 2: Department-Level Access

-- Each user sees only their department's data
CREATE POLICY department_isolation ON orders
  USING (department_id = current_department());

-- Engineering sees engineering orders
-- Sales sees sales orders
-- No cross-department visibility

Scenario 3: Compliance Audit Trail

-- All changes logged automatically
AUDIT ALL ON customers, orders, payments;

-- Generate compliance report
SELECT
  DATE(timestamp) as audit_date,
  COUNT(*) as total_operations,
  COUNT(DISTINCT user_name) as unique_users
FROM pg_audit_log
GROUP BY DATE(timestamp)
ORDER BY audit_date DESC;

Performance Considerations

1. Encryption Overhead: ~5-10% depending on algorithm
2. RLS Overhead: Minimal if policies are simple
3. Audit Logging: Adds I/O but can be batched

-- Monitor performance impact
SELECT
  query,
  mean_time,
  calls
FROM pg_stat_statements
WHERE query LIKE '%encrypted%'
ORDER BY mean_time DESC;

Security Best Practices

1. Encryption Keys Management

   -- Store keys securely (use external KMS)
   SET encryption_key = 'aws:kms:arn:...';
   

2. Least Privilege Access

   -- Grant minimal required permissions
   GRANT SELECT (customer_id, order_date) ON orders TO analyst;
   

3. Regular Audits

   -- Schedule audit review
   SELECT COUNT(*) FROM pg_audit_log
   WHERE timestamp > NOW() - INTERVAL '1 day';
   

4. Strong Authentication

   -- Require strong passwords
   ALTER SYSTEM SET password_min_length = 12;
   ALTER SYSTEM SET password_complexity = 'strong';
   

Compliance Frameworks

• GDPR: Column encryption + RLS + Audit
• HIPAA: Full encryption + RLS + Audit logging
• PCI DSS: Column encryption for cards
• SOC 2: Comprehensive audit trail
• ISO 27001: Access control policies

Troubleshooting

Q: RLS not working?

A: Ensure table security is enabled and policies are defined.

Q: Performance degradation after encryption?

A: Monitor with pg_stat_statements and optimize key management.

Q: Audit logs growing too fast?

A: Archive old logs and adjust audit scope.

Next Steps

1. Read /docs/features/packages/30-security-readme.md for full feature list
2. Review /docs/features/packages/31-security-column-encryption.md for encryption details
3. Check encryption quick start: /docs/features/encryption/COLUMN_ENCRYPTION_QUICK_START.md

Related Features

• Backup & Encryption: /docs/guides/user/BACKUP_ENCRYPTION_CONSUMER_PROTECTION_GUIDE.md
• Compliance Guide: /docs/guides/user/BACKUP_ENCRYPTION_REGULATORY_COMPLIANCE_MATRIX.md
• Security Hardening: /docs/guides/user/SECURITY_HARDENING_V7.md

---

Document Version: 1.0 Last Updated: December 30, 2025 Audience: Database administrators, security engineers Reading Time: 10 minutes