Security Overview¶

Data security is foundational to Carbon Connect. Companies trust us with sensitive business and carbon data, and we take that responsibility seriously. This page explains our security approach in plain language.

Security Philosophy¶

We follow a defense-in-depth strategy: multiple independent layers of protection so that no single point of failure can compromise data. Even if one layer were breached, other layers would prevent unauthorized access.

Encryption: Data Is Protected Everywhere¶

In Transit (Moving Between Systems)¶

Every piece of data moving through the platform is encrypted using TLS 1.2 or higher -- the same encryption standard used by banks and governments. This applies to:

• Data traveling between your browser and our servers
• Data moving between our servers and our database
• Data moving between our servers and our cache
• Data moving between our servers and our file storage

What this means: Even if someone intercepted the data in transit, they would see only encrypted gibberish.

At Rest (Stored on Disk)¶

All stored data is encrypted using AES-256 -- a military-grade encryption standard:

What this means: Even if someone gained physical access to our storage hardware, the data would be unreadable without the encryption keys -- which are stored separately in a dedicated key management service.

Multi-Tenant Isolation: Your Data Is Yours Alone¶

Carbon Connect serves many customers from a single platform (this is called "multi-tenancy"). To ensure no customer can ever see another customer's data, we implement row-level security at the database level.

This is the same isolation approach used by enterprise SaaS platforms serving Fortune 500 companies.

Secrets Management: No Credentials in Code¶

All sensitive credentials (database passwords, API keys, encryption keys) are stored in AWS Secrets Manager, a dedicated vault service. This means:

• Credentials are never stored in source code
• Credentials are never stored in configuration files
• Every access to a secret is logged and auditable
• Credentials can be rotated without changing application code
• Different environments (development, staging, production) use different credentials

Automated Vulnerability Scanning¶

We do not wait for security problems to find us. The platform undergoes eight automated security checks on every code change:

Network Security¶

Private Cloud Architecture¶

The platform runs inside a Virtual Private Cloud (VPC) -- a logically isolated section of the cloud with strictly controlled network access:

What this means: The database and cache are not directly accessible from the internet at all. They exist in a private network that can only be reached through the application layer, which enforces authentication and authorization.

Security Groups¶

Each component has a firewall (called a "security group") that specifies exactly which other components can communicate with it. These rules follow the principle of least privilege -- each component can only access what it absolutely needs.

Authentication and Access Control¶

User Authentication¶

• JWT tokens with configurable expiration for secure session management
• Refresh tokens for seamless session renewal without re-entering credentials
• Password hashing using bcrypt -- passwords are never stored in readable form
• Token blacklisting for immediate logout capability

Application Security¶

Operational Security¶

Monitoring and Alerting¶

• Real-time monitoring of all system components via AWS CloudWatch
• Automated alerting for unusual activity or performance degradation
• Audit logging of all data access and administrative actions
• Database query logging for DDL changes and slow queries (over 1 second)

Backup and Recovery¶

Compliance Posture¶

Summary¶