Aller au contenu principal

Data Security Policy

Application: Aaperture
Version: 1.0
Last Updated: 2025-01-26
Effective Date: 2025-01-26

1. Overview​

This document outlines Aaperture's data security policy, specifically addressing the protection of user data accessed through Google OAuth 2.0. This policy ensures compliance with Google's security requirements and industry best practices.

2. Scope​

This policy applies to:

  • All user data stored in the application
  • OAuth tokens and credentials (Google Calendar)
  • Email metadata and content (sent via SMTP)
  • User authentication data
  • Application configuration and secrets

3. Data Classification​

3.1 Highly Sensitive Data​

OAuth Tokens:

  • Google OAuth access tokens
  • Google OAuth refresh tokens
  • Encryption: AES-256-GCM
  • Storage: Encrypted in database
  • Access: Application services only

Authentication Credentials:

  • User passwords (bcrypt hashed)
  • JWT secrets
  • Encryption keys
  • Storage: Environment variables or encrypted in database

3.2 Sensitive Data​

User Personal Information:

  • Email addresses
  • Names
  • Contact information
  • Storage: Database (unencrypted, but access-controlled)
  • Access: User-specific access control

Email Metadata:

  • Recipient addresses
  • Email subjects
  • Send dates and status
  • Storage: Database (unencrypted, but access-controlled)
  • Access: User-specific access control

3.3 Non-Sensitive Data​

Application Data:

  • Session information
  • Calendar events metadata
  • Business data (quotes, invoices)
  • Storage: Database
  • Access: User-specific access control

4. Email Data Protection​

4.1 Email Sending via SMTP​

Email Sending:

  • The application sends emails via SMTP (Simple Mail Transfer Protocol)
  • No access to user's email account or inbox
  • Emails are sent from the configured SMTP server
  • Professional email sending (quotes, invoices, contracts) is a core feature

4.2 Data Stored for Email Operations​

Stored Data:

  • Email metadata: recipient, subject, date, status, message ID
  • NOT Stored: Email content, email body, attachments content

Storage Location:

  • Email metadata: scheduled_emails table (unencrypted, but access-controlled)

Retention Policy:

  • Email metadata: Retained for business purposes (quotes, invoices tracking)
  • Automatic cleanup of temporary files after email sending

4.3 Data Transmission​

SMTP Email Sending:

  • All email transmission uses SMTP over TLS/SSL
  • Email content transmitted securely via SMTP
  • No intermediate storage of email content

Internal Processing:

  • Email content processed in memory only
  • No logging of email content
  • Temporary files cleaned up immediately after use

5. Encryption Standards​

5.1 OAuth Token Encryption​

Algorithm: AES-256-GCM (Authenticated Encryption)

Key Management:

  • Encryption key: 32 bytes (256 bits) stored as environment variable
  • Key derivation: scrypt with random salt
  • Key rotation: Manual process (planned for future automation)

Implementation:

  • Random IV for each encryption
  • Authentication tag for tamper detection
  • Secure key storage in environment variables

Files:

  • backend/src/common/encryption.service.ts

5.2 Data in Transit​

HTTPS/TLS:

  • TLS 1.2+ required for all connections
  • Let's Encrypt certificates
  • Secure cipher suites only
  • HSTS enabled

API Communications:

  • All Google API calls use HTTPS
  • OAuth token exchange over HTTPS
  • Email sending over HTTPS

5.3 Data at Rest​

Database:

  • OAuth tokens encrypted before storage
  • User passwords hashed with bcrypt
  • Sensitive configuration in environment variables

File Storage:

  • Temporary attachments on Cloudflare R2
  • Signed URLs with expiration
  • Automatic cleanup after use

6. Access Control​

6.1 User Data Access​

Principle: Users can only access their own data

Implementation:

  • User ID verification on all endpoints
  • Resource ownership verification
  • Active user status check
  • Permission-based access control

Files:

  • backend/src/auth/active-user.guard.ts
  • backend/src/permissions/permission.guard.ts
  • backend/src/common/permission.utils.ts

6.2 OAuth Token Access​

Principle: Tokens are user-specific and isolated

Implementation:

  • Tokens stored per user in user_metadata table
  • No token sharing between users
  • Token access only by authenticated user's requests
  • Automatic token refresh per user

6.3 Administrative Access​

Principle: Minimal administrative access

Implementation:

  • No default admin accounts
  • Admin operations logged
  • Access control for administrative functions
  • Regular access reviews

7. Data Retention and Deletion​

7.1 Retention Policy​

OAuth Tokens:

  • Retained until user revokes access
  • Automatically invalidated on revocation
  • No retention after user account deletion

Email Metadata:

  • Retained for business purposes (quotes, invoices tracking)
  • Retention period: As long as business records are needed
  • User can request deletion

Temporary Files:

  • Deleted immediately after email sending
  • Automatic cleanup on error
  • No retention of temporary attachments

7.2 Data Deletion​

User Request:

  • Users can request data deletion
  • OAuth tokens deleted on revocation
  • Email metadata deleted on request
  • Account deletion removes all user data

Automatic Deletion:

  • Temporary files deleted after use
  • Expired tokens cleaned up
  • Orphaned records removed

8. Incident Response​

8.1 Security Incident Detection​

Monitoring:

  • Real-time security alert system
  • Failed authentication tracking
  • Rate limit violation detection
  • CSRF violation tracking
  • Suspicious activity detection

Alerting:

  • Email alerts for HIGH/CRITICAL incidents
  • Logging of all security events
  • Automated detection of anomalies

8.2 Incident Response Procedures​

Detection:

  1. Automated detection via security alerts
  2. Manual review of security logs
  3. User reports of suspicious activity

Response:

  1. Immediate assessment of incident severity
  2. Containment of affected systems
  3. Investigation and root cause analysis
  4. Remediation and prevention measures
  5. User notification if required
  6. Documentation and lessons learned

Files:

  • backend/src/security/security-alerts.service.ts

9. Compliance​

9.1 GDPR/RGPD Compliance​

User Rights:

  • Right to access personal data
  • Right to rectification
  • Right to erasure ("right to be forgotten")
  • Right to data portability
  • Right to object to processing

Implementation:

  • Privacy policy available
  • User data export functionality
  • User data deletion on request
  • Transparent data usage documentation

9.2 Google OAuth Compliance​

Requirements Met:

  • Restricted scope usage justified
  • User consent obtained
  • Privacy policy available
  • Secure token storage
  • Scope validation
  • Error handling

Compliance Status: ✅ COMPLIANT

10. Security Measures for Email Operations​

10.1 Email Content Protection​

Content Handling:

  • Email content processed in memory only
  • No storage of email body
  • HTML sanitization before sending
  • Temporary attachments with automatic cleanup

10.2 Error Handling​

SMTP Errors:

  • Clear error messages for users
  • Guidance for resolving SMTP configuration issues
  • No exposure of SMTP credentials in errors

11. Monitoring and Auditing​

11.1 Security Event Logging​

Logged Events:

  • OAuth token acquisition (without token values)
  • Token refresh operations (without token values)
  • Email sending operations (metadata only)
  • Security incidents and violations
  • Failed authentication attempts

Not Logged:

  • OAuth token values
  • Email content
  • User passwords
  • Sensitive configuration

11.2 Audit Trail​

Email Operations:

  • All email sends recorded in scheduled_emails table
  • Traceability: user, recipient, date, status
  • Message IDs for SMTP sends
  • Error logs for failed sends

Security Events:

  • All security incidents logged
  • Audit trail for administrative actions
  • Access logs for sensitive operations

12. Third-Party Services​

12.1 Google Services​

Google Calendar API:

  • OAuth 2.0 authentication
  • HTTPS/TLS for all API calls
  • Scope validation
  • Error handling

Google Calendar API:

  • OAuth 2.0 authentication
  • HTTPS/TLS for all API calls
  • Scopes:
    • calendar.events.owned (most restrictive, limité aux événements créés par l'application)
    • calendar (nécessaire pour créer/maintenir l'agenda dédié "Aaperture")

12.2 Cloudflare R2​

File Storage:

  • Temporary attachment storage
  • Signed URLs with expiration
  • Automatic cleanup
  • S3-compatible API

13. Policy Review and Updates​

13.1 Review Schedule​

  • Quarterly Review: Every 3 months
  • After Security Incidents: Immediate review
  • After Major Changes: Review before deployment
  • Annual Comprehensive Review: Full policy review

13.2 Update Process​

  1. Identify need for policy update
  2. Draft updated policy
  3. Review by security team
  4. Approval process
  5. Communication to stakeholders
  6. Implementation

Document Version: 1.0
Last Updated: 2025-01-26
Next Review: 2025-04-26