Data Storage and Access Control
Tripl-i v3 stores all customer data in MongoDB Atlas, a fully managed cloud database service hosted on AWS in the EU-Central-1 (Frankfurt) region. This document provides complete transparency about where your data is stored, how it's encrypted, who can access it, and the security controls protecting your information.
Data Storage Architecture
MongoDB Atlas Cloud Database
Primary Data Repository:
- Service Provider: MongoDB Atlas (managed MongoDB service)
- Cloud Provider: Amazon Web Services (AWS)
- Region: EU-Central-1 (Frankfurt, Germany)
- Cluster Type: Dedicated M10+ cluster with replica sets
- Network: AWS VPC with private networking
What Data is Stored: All Tripl-i operational data is stored in MongoDB Atlas:
- Configuration Items (CIs): Servers, workstations, network devices, software, cloud resources
- Discovery Data: Network scan results, agent discoveries, infrastructure mappings
- Relationships: CI dependencies, service mappings, business service relationships
- User Data: User accounts, authentication credentials (hashed), permissions, preferences
- Events: System events, monitoring alerts, correlation data, AI analysis results
- Compliance Data: Attestations, policies, controls, assessment results, audit trails
- AI Analysis: Infrastructure insights, relationship analysis, recommendations
- System Metadata: Tenants, departments, settings, workflows, templates
Data NOT Stored:
- Credit card information (not collected)
- Social security numbers (not collected)
- Raw passwords (only bcrypt hashes stored)
- Temporary session data (stored in Redis, not MongoDB)
Data Residency and Sovereignty
| Aspect | Detail |
|---|---|
| Primary Region | EU-Central-1 (Frankfurt, Germany) |
| Backup Location | EU-West-1 (Ireland) — optional cross-region backup |
| Data Sovereignty | All data remains within EU borders |
Customer Benefits:
- GDPR compliance through EU data residency
- Reduced latency for European customers
- No data transfer to US or non-EU jurisdictions
- EU privacy law protection
Cross-Border Data Transfer:
- Default: All data processing occurs within the EU
- AI Services: AWS Bedrock API calls use EU-Central-1 endpoints only
- Backups: Optional cross-region backup within EU (Ireland)
- No US Transfer: Customer data never transferred to US servers
Encryption at Rest
MongoDB Atlas Encryption
Storage-Level Encryption:
MongoDB Atlas provides transparent encryption at rest using AES-256 encryption for all customer data.
| Encryption Property | Value |
|---|---|
| Algorithm | AES-256-GCM (Galois/Counter Mode) |
| Key Length | 256-bit encryption keys |
| Block Cipher | Advanced Encryption Standard (AES) |
| Mode | GCM for authenticated encryption |
| FIPS Compliance | FIPS 140-2 validated cryptographic modules |
What Gets Encrypted:
- All database data files (WiredTiger storage engine)
- System databases and metadata
- Indexes (including encrypted field indexes)
- Journal files (write-ahead logging)
- Temporary files created during operations
- Snapshot and backup files
Encryption Scope: Encryption covers the entire cluster, all databases, all collections, all documents, and additional application-level encryption is applied for sensitive fields.
Key Management Architecture
MongoDB Atlas uses a hierarchical key structure with AWS Key Management Service (KMS):
| Layer | Component | Details |
|---|---|---|
| Top | AWS KMS Customer Master Key (CMK) | Managed by MongoDB Atlas in AWS |
| Middle | Database Encryption Keys (DEK) | One per MongoDB cluster, rotated annually |
| Bottom | Data Encryption (AES-256) | Encrypts actual customer data at rest |
Key Storage and Protection:
-
Customer Master Keys (CMK)
- Stored in: AWS Key Management Service (KMS)
- Region: EU-Central-1 (same as data)
- Access: Controlled by MongoDB Atlas service role
- Rotation: Automatic annual rotation
- Backup: AWS KMS handles redundancy and availability
- Protection: FIPS 140-2 Level 2 validated hardware security modules (HSMs)
-
Data Encryption Keys (DEK)
- Generated by: AWS KMS using CMK
- Storage: Encrypted with CMK and stored alongside data
- Lifecycle: Created per cluster, rotated annually
- Access: Only accessible to MongoDB Atlas cluster processes
- Deletion: Securely wiped when cluster is terminated
Key Hierarchy Benefits:
- Defense in Depth — Multiple encryption layers
- Easy Rotation — Annual automatic CMK rotation without downtime
- Secure Storage — Keys never stored in plaintext
- Access Control — Keys isolated from data access paths
Who Controls the Encryption Keys:
| Key Type | Managed By | Stored In | Access Control |
|---|---|---|---|
| Customer Master Key (CMK) | MongoDB Atlas | AWS KMS (EU-Central-1) | MongoDB Atlas service role |
| Data Encryption Keys (DEK) | MongoDB Atlas | Encrypted with CMK, stored with data | MongoDB cluster processes only |
| Application-Level Keys | Tripl-i | AWS Secrets Manager | Tripl-i application IAM role |
Customer Note: MongoDB Atlas manages all database-level encryption keys. Customers do not need to manage keys manually, ensuring zero-configuration security while maintaining enterprise-grade protection.
Application-Level Encryption
In addition to MongoDB Atlas encryption, Tripl-i implements field-level encryption for highly sensitive data:
Sensitive Fields with Additional Encryption:
- User authentication TOTP secrets (2FA)
- Discovery agent API tokens
- Third-party integration credentials
- SNMP community strings
- SSH private keys and connection passwords
- Cloud provider credentials (AWS, Azure, GCP)
Application Encryption Details:
| Property | Value |
|---|---|
| Algorithm | AES-256-GCM |
| Key Derivation | PBKDF2-SHA256 (10,000 iterations) |
| Salt | Unique 32-byte salt per field |
| Initialization Vector | Random 16-byte IV per encryption |
| Storage Format | Base64-encoded ciphertext |
| Key Storage | AWS Secrets Manager (encrypted at rest) |
Encryption Process:
- Sensitive data is received (e.g., API token)
- A random salt (32 bytes) is generated
- An encryption key is derived using PBKDF2
- A random initialization vector (16 bytes) is generated
- Data is encrypted using AES-256-GCM
- Salt, IV, ciphertext, and authentication tag are combined
- The result is Base64 encoded
- The encrypted value is stored in MongoDB (which applies AES-256 at rest)
Result: Sensitive fields are double-encrypted — first at the application level with AES-256-GCM, then at the storage level by MongoDB Atlas.
Encryption in Transit
Database Connection Encryption
All connections to MongoDB Atlas are encrypted using TLS 1.2/1.3.
TLS Configuration:
- Protocol: TLS 1.2 minimum (TLS 1.3 preferred)
- Cipher Suites: Strong cipher suites only (AES-256-GCM with ECDHE key exchange)
- Certificate Validation: MongoDB Atlas X.509 certificates validated
- Perfect Forward Secrecy: Enabled (ECDHE key exchange)
- Authentication: SCRAM-SHA-256 over encrypted channel
Network Security:
- All database queries encrypted in transit
- Replica set communication encrypted
- Backup data transfer encrypted
- Atlas UI access via HTTPS only
Application Communication
The Tripl-i backend (running on AWS ECS in EU-Central-1) connects to MongoDB Atlas (also in EU-Central-1) using an encrypted connection with SCRAM-SHA-256 authentication over TLS 1.2+.
Security Layers:
- Network Layer — AWS VPC peering or private networking
- Transport Layer — TLS 1.2/1.3 encryption
- Authentication Layer — SCRAM-SHA-256 credentials
- Authorization Layer — MongoDB RBAC roles
Access Control
Who Can Access Your Data
Tripl-i implements strict access controls to ensure only authorized personnel and systems can access customer data:
1. Application Access (Primary)
The Tripl-i application connects with a dedicated database user that has read/write permissions only on the application database.
What the Application Can Do:
- Read and write customer data in the application database
- Create and modify collections and indexes
- Execute aggregation queries for analytics
- Perform CRUD operations on documents
What the Application CANNOT Do:
- Access other databases on the cluster
- Create or modify database users
- Modify cluster configuration
- Access encryption keys directly
- Bypass authentication or authorization
2. MongoDB Atlas Administrative Access
- Who: Tripl-i infrastructure team (2-3 designated administrators)
- Access Method: MongoDB Atlas web console
- Authentication: Email/password + mandatory 2FA (TOTP)
- Purpose: Cluster management, monitoring, backup configuration
- All admin actions are logged in the MongoDB Atlas audit log
- IP whitelisting is enforced (only specific admin IPs allowed)
3. MongoDB Support Access (Limited)
- Access: Only granted with explicit customer permission
- Use Case: Technical support tickets, troubleshooting assistance
- Duration: Time-limited access (24-48 hours)
- Scope: Read-only cluster metadata and diagnostics
- Customer Control: Can be revoked immediately by customer
- MongoDB Support cannot see customer data contents (encrypted at rest)
4. AWS Personnel Access
- AWS data center personnel have physical access to servers
- All data is encrypted at rest with keys NOT accessible to AWS
- AWS cannot decrypt customer data or access MongoDB Atlas cluster data
- AWS SOC 2 and ISO 27001 certified for physical security
Access Control Summary
| Role | Access Level | Authentication | Can Read Data | Can Modify Data | Audit Logged |
|---|---|---|---|---|---|
| Tripl-i Application | Database R/W | SCRAM-SHA-256 | Yes | Yes | Yes |
| Tripl-i Admins | Atlas Console | Email + 2FA | No (requires DB credentials) | No | Yes |
| MongoDB Support | Limited (with permission) | SSO + MFA | No (encrypted) | No | Yes |
| AWS Personnel | Physical hardware | N/A | No (encrypted) | No | Yes |
| Unauthorized Users | None | N/A | No | No | Blocked |
Network Security
IP Whitelisting and Network Isolation
MongoDB Atlas enforces strict network access controls. Only the Tripl-i backend ECS instances, designated development IPs, and specific admin IPs are whitelisted. All other IP addresses are blocked by default.
VPC Peering (Optional):
- Available for enhanced security
- Direct private connection between AWS VPC and MongoDB VPC
- No traffic over public internet
- Reduced latency and enhanced security
Database Authentication
Tripl-i uses SCRAM-SHA-256 (Salted Challenge Response Authentication Mechanism) for database authentication. This ensures that passwords are never sent over the network, provides protection against replay attacks, enables mutual authentication (client and server), and works over the encrypted TLS connection.
Role-Based Access Control: The application database user has read/write access only to the application database, with no access to admin or configuration databases and no cluster administration privileges.
Backup and Disaster Recovery
Automated Backups
| Backup Property | Value |
|---|---|
| Snapshot Frequency | Every 12 hours |
| Retention Period | 30 days rolling retention |
| Snapshot Encryption | AES-256 (same as primary data) |
| Storage Location | AWS S3, EU-Central-1 |
| Point-in-Time Recovery | Up to the second within 30-day window |
| Cross-Region Backup | Optional, AWS S3 (EU-West-1), encrypted |
Backup Access:
- Tripl-i admins can initiate restores via Atlas console
- Restore operations create a new cluster (no production impact)
- All restore operations are logged and auditable
- Backups cannot be downloaded directly (security control)
Disaster Recovery
| Metric | Target | Actual |
|---|---|---|
| Recovery Time Objective (RTO) | Less than 4 hours | Typically 1-2 hours |
| Recovery Point Objective (RPO) | Less than 15 minutes | Point-in-time recovery to the second |
Recovery Scenarios:
- Data Corruption — Restore from point-in-time before corruption, verify integrity, switch to restored cluster
- Regional Failure — Failover to cross-region backup (if configured), promote backup cluster
- Accidental Deletion — Identify deletion timestamp, restore to point before deletion, merge recovered data
Audit Logging and Monitoring
MongoDB Atlas Audit Logs
MongoDB Atlas logs all database access and administrative actions including:
Database Operations Logged:
- Authentication attempts (success and failure)
- Authorization failures
- Database and collection creation/deletion
- User and role management
- Index creation and modification
- Slow query execution
- Aggregation pipeline execution
Administrative Actions Logged:
- Cluster configuration changes
- Network access list modifications
- Backup and restore operations
- User creation and permission changes
- Atlas console login attempts
Log Retention: 365 days, accessible via MongoDB Atlas console, exportable for SIEM integration.
Real-Time Monitoring
Metrics Tracked:
- Database operations per second (reads, writes, updates, deletes)
- Query execution times and slow query identification
- Connection count and pool utilization
- Disk usage, IOPS, and storage capacity
- Network traffic (bytes in/out)
- CPU and memory utilization
Configured Alerts:
| Alert Level | Triggers |
|---|---|
| Critical | Disk usage above 80%, connection count above 90% of limit, replication lag above 10 seconds, failed authentication above 10/minute |
| Warning | Slow queries above 100ms, high CPU usage above 70%, memory pressure, network saturation |
Compliance and Certifications
MongoDB Atlas Compliance
Certifications:
- SOC 2 Type II (Security, Availability, Confidentiality)
- ISO 27001 (Information Security Management)
- ISO 27017 (Cloud Security)
- ISO 27018 (Cloud Privacy)
- PCI DSS Level 1 (Payment Card Industry)
- HIPAA Eligible (with BAA)
- GDPR Compliant (EU data residency)
AWS Infrastructure Compliance:
- FedRAMP Moderate
- FIPS 140-2 (cryptographic modules)
- CSA STAR Level 2
- BSI C5 (German cloud security)
Data Processing Agreement (DPA)
MongoDB Atlas acts as a data processor under GDPR:
- MongoDB processes customer data only on instruction from Tripl-i
- Standard Contractual Clauses (SCCs) in place
- EU data residency maintained
- Data subject rights supported (access, deletion, portability)
- Sub-processor list maintained and updated
Customer Rights Under GDPR:
- Right to access your data
- Right to data portability (export)
- Right to deletion (data removal)
- Right to rectification
- Data breach notification within 72 hours
Security Best Practices
For Tripl-i Administrators
Access Control:
- Enable 2FA on all MongoDB Atlas admin accounts
- Use strong, unique passwords (20+ characters)
- Regularly review and rotate database credentials
- Implement IP whitelisting for all access
- Review audit logs weekly for suspicious activity
Monitoring:
- Set up alerts for critical security events
- Monitor slow query logs for performance issues
- Track connection patterns for anomalies
- Review backup success/failure reports
- Conduct quarterly disaster recovery tests
Incident Response
Data Breach Protocol
Response Process: Detection, Assessment, Containment, Eradication, Recovery, Lessons Learned
Notification Timeline:
- Internal: Immediate notification to security team
- Customers: Within 72 hours (GDPR requirement)
- Regulators: Within 72 hours (if required by law)
- Public: Coordinated disclosure if necessary
Contact Information
- Security Incidents: security@tripl-i.com
- Data Access Requests: privacy@tripl-i.com
- Data Protection Officer: dpo@tripl-i.com
Summary
- Data Location: All data stored in MongoDB Atlas, EU-Central-1 (Frankfurt, Germany)
- Encryption: AES-256 encryption at rest, TLS 1.2/1.3 in transit
- Keys: Managed by MongoDB Atlas using AWS KMS, automatic rotation
- Access: Strictly controlled via authentication, authorization, IP whitelisting, and audit logging
- Backups: Automated encrypted backups every 12 hours, 30-day retention
- Compliance: SOC 2, ISO 27001, GDPR, HIPAA eligible, PCI DSS
- Monitoring: 24/7 monitoring, audit logging, real-time alerts
Tripl-i is committed to complete transparency about data storage and access. This document will be updated as security practices evolve.