Security Checklist

Use this checklist to verify your EvidentSource deployment meets security requirements.

Network Isolation

The network-as-trust-boundary model relies on proper network isolation. EvidentSource servers must only be reachable through the edge layer.

Required

• Private subnets - EvidentSource servers deployed in private subnets without public IPs
• Security groups - Only ALB security group can reach EvidentSource ports (3000, 50051)
• No direct access - Verify servers are not reachable from public internet
• VPC flow logs - Enable VPC flow logs for security monitoring

Verification

# Verify server is not directly accessible
curl https://<server-private-ip>:3000/health  # Should timeout/fail

# Verify ALB is accessible
curl https://<alb-dns-name>/health  # Should succeed

Edge Layer Configuration

ALB JWT Verification

• JWKS endpoint configured - Points to your IdP’s JWKS endpoint
• Issuer validated - Matches your IdP’s issuer claim
• Audience validated (optional) - Restricts tokens to specific audience
• RS256 algorithm - IdP signs tokens with RS256 (only algorithm supported)
• HTTPS only - ALB listeners use TLS certificates

CloudFormation Parameters

Parameter	Configured	Value
JwtIssuer	[ ]
JwtJwksEndpoint	[ ]
JwtAudience	[ ]
RequireAuth	[ ]	true

Verification

# Test with valid token
curl -H "Authorization: Bearer $VALID_TOKEN" https://<alb-dns>/health
# Should return 200

# Test with invalid token
curl -H "Authorization: Bearer invalid_token" https://<alb-dns>/api/v1/databases
# Should return 401

# Test without token
curl https://<alb-dns>/api/v1/databases
# Should return 401 (when RequireAuth=true)

Token Security

JWT Requirements

• Short lifetime - Access tokens expire within 1 hour
• Refresh flow - Clients can refresh tokens before expiration
• Signature algorithm - RS256 (asymmetric) not HS256 (symmetric)
• Secure storage - Clients store tokens securely (not localStorage)

evs:grants Claim

• Least privilege - Users only have permissions they need
• Database-scoped - Prefer database-specific grants over all_databases
• Regular review - Periodically audit user permissions

Token Vending (if applicable)

• Key rotation - RSA keys rotated at least annually
• Secrets management - Private keys stored in Secrets Manager or SSM
• JWKS endpoint - Publicly accessible for ALB verification
• Key ID (kid) - Included in JWT header for key rotation support

Server Configuration

Required Settings

Setting	Value	Status
--require-auth	true	[ ]
--scheme	https	[ ]

TLS Configuration

• TLS termination - ALB terminates TLS with valid certificate
• Certificate - Valid, not expired, trusted CA
• Modern TLS - TLS 1.2 or higher (ALB default)

Health Check Endpoints

• Unauthenticated health - /health accessible without auth for ALB checks
• No sensitive data - Health endpoint doesn’t expose internal state

Monitoring & Logging

CloudWatch Metrics

• ALB metrics - Monitor 4XX/5XX rates
• JWT validation failures - Alert on authentication failures
• Latency - Monitor authentication latency

Logging

• Access logs - ALB access logs enabled
• Server logs - Auth events logged at INFO level
• Audit trail - Principal attribution in transaction metadata
• No secrets - Tokens not logged (use subject/email only)

Alerting

• Spike in 401s - Alert on authentication failure spikes
• Unauthorized access attempts - Alert on repeated 403s
• Certificate expiry - Alert before TLS certificate expires

Data Protection

In Transit

• TLS everywhere - All connections use TLS
• Internal traffic - Consider VPC endpoints for AWS services

At Rest

• DynamoDB encryption - SSE enabled (KMS or AWS-managed)
• S3 encryption - SSE-S3 or SSE-KMS enabled
• KMS key policy - Restrict access to authorized principals

Sensitive Data

• No PII in events - Avoid storing PII in event payloads if possible
• Audit fields - Principal attribution uses subject ID not personal info

Identity Provider Security

IdP Configuration

• MFA enabled - Multi-factor authentication for users
• Password policy - Strong password requirements
• Session timeout - Reasonable session/token lifetimes
• Secure redirect URIs - Only allow registered redirect URIs

Service Accounts

• Dedicated accounts - Separate service accounts per application
• Rotate credentials - Regular credential rotation
• Least privilege - Minimal required permissions

Compliance Considerations

Audit Requirements

• Transaction attribution - Every transaction records principal info
• Immutable history - Event store provides immutable audit trail
• Retention policy - Configure appropriate data retention

Access Control

• Role segregation - Different roles for dev/staging/production
• Approval workflow - Process for granting production access
• Access review - Periodic review of user permissions

Incident Response

Preparation

• Key rotation plan - Documented process for rotating JWT signing keys
• Token revocation - Plan for revoking compromised tokens (IdP-level)
• Contact list - Security team contact information documented

Detection

• Anomaly detection - Monitor for unusual access patterns
• Failed auth tracking - Track and alert on repeated failures
• Geographic anomalies - Flag access from unexpected locations

Quick Reference

Minimum Viable Security

For any production deployment:

1. RequireAuth=true
2. JWT verification enabled (JwtIssuer + JwtJwksEndpoint)
3. Private subnets for servers
4. Security groups limiting access to ALB
5. TLS certificate on ALB
6. IdP configured with evs:grants claim

Defense in Depth

Additional protections for sensitive deployments:

1. VPC flow logs enabled
2. CloudWatch alarms on auth failures
3. WAF rules on ALB
4. Separate VPCs for production/staging
5. Regular penetration testing
6. Automated compliance checks