Data Storage and Access Control

NopeSight 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 NopeSight 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

Geographic Location:

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 Details:

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:

Cluster Level:      ✓ Entire cluster encrypted
Database Level:     ✓ All databases encrypted
Collection Level:   ✓ All collections encrypted
Document Level:     ✓ All documents encrypted
Field Level:        ✓ Additional application-level encryption for sensitive fields

Key Management Architecture

MongoDB Atlas Key Management:

MongoDB Atlas uses a hierarchical key structure with AWS Key Management Service (KMS):

┌─────────────────────────────────────────────────┐
│         AWS KMS Customer Master Key (CMK)       │
│         (Managed by MongoDB Atlas in AWS)       │
└─────────────────┬───────────────────────────────┘
                  │
                  ▼
┌─────────────────────────────────────────────────┐
│         Database Encryption Keys (DEK)          │
│    (One per MongoDB cluster, rotated annually)  │
└─────────────────┬───────────────────────────────┘
                  │
                  ▼
┌─────────────────────────────────────────────────┐
│         Data Encryption (AES-256)               │
│    (Encrypts actual customer data at rest)      │
└─────────────────────────────────────────────────┘

Key Storage and Protection:

1. 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)

2. 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	NopeSight	AWS Secrets Manager	NopeSight 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, NopeSight 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 Spec:

Algorithm:          AES-256-GCM
Key Derivation:     PBKDF2-SHA256 (10,000 iterations)
Salt:               Unique 32-byte salt per field
Initialization Vector (IV): Random 16-byte IV per encryption
Storage Format:     Base64-encoded ciphertext
Key Storage:        AWS Secrets Manager (encrypted at rest)

Encryption Flow:

1. Sensitive data received (e.g., API token)
2. Generate random salt (32 bytes)
3. Derive encryption key using PBKDF2
4. Generate random IV (16 bytes)
5. Encrypt data using AES-256-GCM
6. Combine: salt + IV + ciphertext + auth tag
7. Encode as Base64
8. Store in MongoDB (which applies AES-256 at rest)

Result: Sensitive fields are double-encrypted:

• Layer 1: Application-level AES-256-GCM
• Layer 2: MongoDB Atlas storage-level AES-256

Encryption in Transit

Database Connection Encryption

MongoDB Atlas Connection Security:

All connections to MongoDB Atlas are encrypted using TLS 1.2/1.3:

Connection String:
mongodb+srv://ekrem:<password>@aitsm-server.wc41n.mongodb.net/killit_v3
  ?retryWrites=true
  &w=majority
  &ssl=true              ← TLS encryption enforced
  &authSource=admin
  &authMechanism=SCRAM-SHA-256

TLS Configuration:

• Protocol: TLS 1.2 minimum (TLS 1.3 preferred)
• Cipher Suites: Strong cipher suites only
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• 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

NopeSight → MongoDB Atlas:

┌──────────────┐      HTTPS/TLS 1.2+      ┌──────────────┐
│              │◄────────────────────────►│              │
│  NopeSight   │  Encrypted Connection    │   MongoDB    │
│  Backend     │  + SCRAM-SHA-256 Auth   │    Atlas     │
│  (ECS)       │                          │   (Cluster)  │
└──────────────┘                          └──────────────┘
   AWS VPC                                  MongoDB VPC
   EU-Central-1                             EU-Central-1

Security Layers:

1. Network Layer: AWS VPC peering or private networking
2. Transport Layer: TLS 1.2/1.3 encryption
3. Authentication Layer: SCRAM-SHA-256 credentials
4. Authorization Layer: MongoDB RBAC roles

Access Control

Who Can Access Your Data

NopeSight implements strict access controls to ensure only authorized personnel and systems can access customer data:

1. Application Access (Primary)

NopeSight Application:

• Access Method: MongoDB connection string with credentials
• Authentication: SCRAM-SHA-256 with strong password
• Authorization: Database user with least-privilege permissions
• Network: AWS ECS containers in EU-Central-1 VPC
• Audit: All database operations logged in MongoDB Atlas

Permissions:

Database User: "ekrem" (NopeSight application user)
Permissions:
  - readWrite on killit_v3 database
  - No admin privileges
  - No cross-database access
  - Cannot create users or modify cluster settings

What Application Can Do:

• ✅ Read and write customer data in killit_v3 database
• ✅ Create and modify collections and indexes
• ✅ Execute aggregation queries for analytics
• ✅ Perform CRUD operations on documents

What 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

Atlas Admin Users:

• Who: NopeSight infrastructure team (2-3 designated administrators)
• Access Method: MongoDB Atlas web console (https://cloud.mongodb.com)
• Authentication: Email/password + mandatory 2FA (TOTP)
• Purpose: Cluster management, monitoring, backup configuration

What Atlas Admins Can Do:

• ✅ View cluster metrics and performance data
• ✅ Configure backups and point-in-time recovery
• ✅ Scale cluster resources (CPU, memory, storage)
• ✅ Configure network security and IP whitelisting
• ✅ View audit logs and access patterns
• ✅ Manage database users and roles

Atlas Admin Restrictions:

• ❌ Cannot decrypt data at rest (no key access)
• ❌ Cannot access customer data directly (requires database credentials)
• ✅ All admin actions logged in MongoDB Atlas audit log
• ✅ IP whitelisting enforced (only specific admin IPs allowed)

Atlas Admin Audit Trail:

All administrative actions logged:
- Login attempts and successes
- Cluster configuration changes
- User creation and permission modifications
- Backup restore operations
- Network configuration changes

3. MongoDB Support Access (Limited)

MongoDB, Inc. Support Engineers:

• 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

What MongoDB Support CAN See:

• ✅ Cluster configuration and resource usage
• ✅ Performance metrics and slow query logs
• ✅ Error logs and system diagnostics
• ✅ Database schema structure (collection names, index definitions)

What MongoDB Support CANNOT See:

• ❌ Customer data contents (encrypted at rest, keys controlled by Atlas)
• ❌ Encryption keys (managed by AWS KMS)
• ❌ Application-level encrypted fields (even if they access database)

Support Access Controls:

• Requires explicit customer authorization
• All support actions logged and auditable
• Access automatically expires after time limit
• Customer can revoke access at any time

4. AWS Personnel Access

AWS Infrastructure Team:

• Physical Access: AWS data center personnel have physical access to servers
• Data Protection: All data encrypted at rest with keys NOT accessible to AWS
• Encryption: MongoDB Atlas encryption keys stored in AWS KMS, not accessible to AWS operators
• Compliance: AWS SOC 2, ISO 27001 certified for physical security

What AWS CANNOT Do:

• ❌ Cannot decrypt customer data (no access to encryption keys)
• ❌ Cannot access MongoDB Atlas cluster data
• ❌ Cannot read data from physical disks (encrypted at rest)

Access Control Summary Table

Role	Access Level	Authentication	Can Read Data	Can Modify Data	Audit Logged
NopeSight Application	Database R/W	SCRAM-SHA-256	✅ Yes	✅ Yes	✅ Yes
NopeSight Admins	Atlas Console	Email + 2FA	❌ No (requires DB creds)	❌ 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 Network Access Control:

Allowed IP Addresses (Application Access):
- NopeSight Backend ECS: 3.120.0.0/16 (AWS VPC)
- Development: 94.xxx.xxx.xxx (office IP)
- Emergency Access: Specific admin IPs only

Blocked by Default: ALL other IP addresses

Network Architecture:

┌────────────────────────────────────────────────┐
│            Public Internet                      │
└────────────┬───────────────────────────────────┘
             │ ❌ Blocked
             │
┌────────────▼───────────────────────────────────┐
│      MongoDB Atlas Network Firewall            │
│   (IP Whitelist + TLS Requirement)             │
└────────────┬───────────────────────────────────┘
             │ ✅ Allowed
             │
┌────────────▼───────────────────────────────────┐
│        MongoDB Atlas Cluster                   │
│     (VPC: EU-Central-1, Private)               │
└────────────────────────────────────────────────┘

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

Authentication Mechanisms:

SCRAM-SHA-256 (Salted Challenge Response Authentication Mechanism):

Process:
1. Client sends username
2. Server responds with salt + iteration count
3. Client computes salted hash of password
4. Client sends proof of password knowledge
5. Server verifies and responds with proof
6. Mutual authentication established

Benefits:
✓ Password never sent over network
✓ Protection against replay attacks
✓ Mutual authentication (client + server)
✓ Works over encrypted TLS connection

MongoDB Role-Based Access Control (RBAC):

User: ekrem
Database: killit_v3
Role: readWrite
Privileges:
  - read: killit_v3 database
  - write: killit_v3 database
  - createCollection: killit_v3 database
  - createIndex: killit_v3 database

Restrictions:
  - NO access to admin database
  - NO access to config database
  - NO cluster administration privileges

Backup and Disaster Recovery

Automated Backups

MongoDB Atlas Backup Service:

Continuous Cloud Backup:

• 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

Backup Storage:

Primary Backups:     AWS S3 (EU-Central-1) - Encrypted
Cross-Region Backup: AWS S3 (EU-West-1) - Optional, Encrypted
Retention:           30 days continuous
Encryption:          AES-256 with separate encryption keys

Backup Access:

• ✅ NopeSight admins can initiate restores via Atlas console
• ✅ Restore operations create new cluster (no production impact)
• ✅ All restore operations logged and auditable
• ❌ Backups cannot be downloaded directly (security control)

Disaster Recovery

Recovery Time Objective (RTO):

• Target: < 4 hours for full cluster restore
• Actual: Typically 1-2 hours for most scenarios

Recovery Point Objective (RPO):

• Target: < 15 minutes of data loss
• Actual: Point-in-time recovery to the second

Recovery Procedures:

Scenario 1: Data Corruption
- Restore from point-in-time before corruption
- Verify data integrity
- Switch application to restored cluster

Scenario 2: Regional Failure
- Failover to cross-region backup (if configured)
- Promote backup cluster to primary
- Update application connection strings

Scenario 3: Accidental Deletion
- Identify deletion timestamp
- Restore to point before deletion
- Merge recovered data to production

Audit Logging and Monitoring

MongoDB Atlas Audit Logs

Comprehensive Audit Trail:

MongoDB Atlas logs all database access and administrative actions:

Logged Events:

Database Operations:
✓ Authentication attempts (success/failure)
✓ Authorization failures
✓ Database and collection creation/deletion
✓ User and role management
✓ Index creation and modification
✓ Query execution (slow queries)
✓ Aggregation pipeline execution

Administrative Actions:
✓ Cluster configuration changes
✓ Network access list modifications
✓ Backup and restore operations
✓ User creation and permission changes
✓ Atlas console login attempts

Audit Log Details:

{
  "timestamp": "2025-11-16T15:46:14.450Z",
  "user": "ekrem",
  "database": "killit_v3",
  "action": "insert",
  "collection": "events",
  "result": "success",
  "sourceIP": "3.120.45.123",
  "connectionId": "conn12345"
}

Log Retention:

• Storage Period: 365 days
• Access: Via MongoDB Atlas console or API
• Export: Can be exported for SIEM integration
• Analysis: Built-in query and filtering tools

Real-Time Monitoring

MongoDB Atlas Monitoring Dashboard:

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

Alerts Configured:

Critical Alerts:
- Disk usage > 80%
- Connection count > 90% of limit
- Replication lag > 10 seconds
- Failed authentication attempts (> 10/min)

Warning Alerts:
- Slow queries (> 100ms)
- High CPU usage (> 70%)
- Memory pressure
- Network saturation

Compliance and Certifications

MongoDB Atlas Compliance

MongoDB Atlas maintains compliance with major security standards:

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)

GDPR Data Processing:

MongoDB Atlas acts as a data processor under GDPR:

• MongoDB processes customer data only on instruction from NopeSight
• 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 (< 72 hours)

Security Best Practices

For NopeSight Administrators

Access Control:

1. Enable 2FA on all MongoDB Atlas admin accounts
2. Use strong, unique passwords (20+ characters)
3. Regularly review and rotate database credentials
4. Implement IP whitelisting for all access
5. Review audit logs weekly for suspicious activity

Monitoring:

1. Set up alerts for critical security events
2. Monitor slow query logs for performance issues
3. Track connection patterns for anomalies
4. Review backup success/failure reports
5. Conduct quarterly disaster recovery tests

Configuration Hardening:

1. Disable MongoDB Atlas public access (use VPC peering)
2. Enable cluster auto-scaling for availability
3. Configure cross-region backups for critical deployments
4. Implement network encryption for all connections
5. Use separate databases for dev/staging/production

For Application Developers

Secure Coding:

1. Never hardcode database credentials in source code
2. Use environment variables or AWS Secrets Manager
3. Implement query parameterization to prevent injection
4. Validate and sanitize all user inputs
5. Use least-privilege database permissions

Data Protection:

1. Encrypt sensitive fields before storing
2. Never log database credentials or connection strings
3. Implement proper error handling without exposing DB details
4. Use connection pooling for efficiency
5. Close database connections properly

Incident Response

Data Breach Protocol

In the Event of a Security Incident:

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

Customer Support:

• Dedicated incident response hotline
• Regular status updates during incident
• Post-incident analysis report
• Remediation plan and preventive measures

Contact Information

Security Incidents:

• Email: security@nopesight.com
• Emergency: +1-800-SECURITY
• Portal: https://security.nopesight.com

Data Access Requests:

• Email: privacy@nopesight.com
• Data Protection Officer: dpo@nopesight.com

---

Summary

Key Takeaways:

✅ 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

✅ Who Can Access:

• NopeSight application (authorized database user)
• NopeSight admins (Atlas console, no data access without DB credentials)
• MongoDB support (only with customer permission, cannot decrypt data)
• AWS (no access to encrypted data or keys)

✅ 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

---

Trust and Transparency: NopeSight is committed to complete transparency about data storage and access. This document will be updated as security practices evolve. Last updated: November 2025.