[Lightning AC-16] Customer Data Storage & Security Attribute Design ¶
1. Purpose ¶
This document describes where Customer Data is stored within the system and how security and privacy attributes are associated, maintained, and reviewed throughout the data lifecycle, including:
- Data in storage
- Data in process
- Data in transmission
The purpose of this document is to provide transparency into how customer data is handled and to support compliance with internal security requirements related to security attribute management and customer data protection.
2. System Overview ¶
The system provides a service status platform used to publish operational status information.
The platform provides two main interfaces:
Status Page ¶
A public interface that displays:
- Incidents
- Maintenance events
- Service updates
- Calendar events
Users can optionally subscribe to receive notifications related to incidents and maintenance events.
Admin Page ¶
An internal administrative interface used by authorized operators to:
- Create incidents
- Update incidents
- Schedule maintenance
- Publish service updates
- Manage calendar events
The system primarily manages service operational data, while customer data is limited to subscription identifiers.
3. AWS Infrastructure Architecture ¶
The system is deployed in AWS using a multi-region architecture to support high availability.
| Component | Technology |
|---|---|
| Frontend Hosting | Amazon S3 |
| CDN | Amazon CloudFront |
| Backend Service | Spring Boot |
| Application Platform | AWS Elastic Beanstalk |
| Compute | Amazon EC2 |
| Database | Amazon RDS PostgreSQL |
| Cache | Amazon ElastiCache Redis |
| DNS & Failover | Amazon Route53 |
Two AWS regions are deployed with Route53 health checks to provide automatic failover.
4. High-Level Architecture Diagram ¶
Refer to GSS for Service Map Requirements
5. System Functional Components ¶
The system manages operational service status information.
| Feature | Description |
|---|---|
| Incident Management | Create and update service incidents |
| Maintenance Management | Schedule and publish maintenance events |
| Updates | Publish service updates |
| Calendar | Manage service calendar events |
| Email Subscription | Users can subscribe to receive notifications |
Incident, maintenance, updates, and calendar records contain service operational information only and do not contain customer personal data.
6. Customer Data Definition ¶
Customer Data refers to information associated with users who subscribe to service notifications.
The system stores minimal personal data, limited to a hashed identifier derived from the user’s email address.
| Data Element | Description |
|---|---|
| shaEmail | SHA-based hash of the user email address used for subscription identification |
Plaintext email addresses are not stored in the system.
Before storage, email addresses are transformed into a one-way SHA hash (shaEmail) to prevent recovery of the original email address.
7. Customer Data Inventory ¶
| Data Element | Storage Location | Format | Classification |
|---|---|---|---|
| shaEmail | RDS PostgreSQL | SHA Hash | Confidential |
| Subscription Preferences | RDS PostgreSQL | Structured Data | Confidential |
Customer data is stored only within the RDS PostgreSQL database.
8. Customer Data Storage Locations ¶
Customer data is stored within the following system components.
| Component | Storage Type | Customer Data | Security Controls |
|---|---|---|---|
| Amazon RDS PostgreSQL | Database | shaEmail, subscription preferences | VPC isolation, encryption at rest, IAM access control |
| Amazon S3 | Object storage | Static frontend assets only | Bucket policies |
| CloudFront | CDN | No persistent customer data | HTTPS delivery |
No plaintext personal data is stored in any system component.
9. Customer Data Flow ¶
The following diagram illustrates how customer data flows through the system.
Users
|
Status Page
(CloudFront + S3 Frontend)
|
Backend API
(Spring Boot)
|
Email Address Submitted
|
SHA Hash Generated
|
shaEmail
|
RDS PostgreSQL
(Primary Customer Data Storage)
10. Operational Data Flow ¶
Operational service status data follows a separate flow.
Admin Users
|
Admin Page
|
Backend Service
|
Incident / Maintenance / Updates / Calendar
|
Stored in RDS PostgreSQL
|
Displayed on Status Page
These records contain service operational information only and do not contain customer personal data.
12. Security Attributes ¶
Security attributes are associated with customer data to define protection requirements.
| Attribute | Description | Value |
|---|---|---|
| Data Classification | Sensitivity level | Confidential |
| Data Owner | Responsible team | GSS Engineering |
| Encryption at Rest | Storage protection | Enabled |
| Encryption in Transit | Transport security | TLS/HTTPS |
These attributes apply to customer data stored and processed within the system.
13. Attribute Association with Data ¶
Security attributes are enforced through system architecture and infrastructure configuration.
| Data Location | Attribute Application |
|---|---|
| PostgreSQL database | Data classified as Confidential |
| Network traffic | Encrypted using TLS |
| S3 storage | Encryption enabled |
| Backend services | IAM-based access control |
Attributes remain associated with the data throughout storage and processing.
14. Data Protection Controls ¶
The system implements multiple controls to protect customer data.
| Control | Implementation |
|---|---|
| Encryption at Rest | Amazon RDS and S3 encryption |
| Encryption in Transit | HTTPS / TLS |
| Access Control | AWS IAM roles and security groups |
| Network Isolation | AWS VPC |
| High Availability | Multi-region deployment with Route53 failover |
15. Attribute Change Auditing ¶
Changes affecting customer data storage or security attributes are audited through the following mechanisms.
| Change Type | Audit Mechanism |
|---|---|
| Database schema changes | Version-controlled migration scripts |
| Application configuration changes | Git version control |
| Deployment changes | CI/CD pipeline logs |
These audit mechanisms provide traceability for changes affecting customer data.
16. Security Attribute Review ¶
Security attributes and data storage configurations are periodically reviewed.
| Review Item | Frequency | Responsible Team |
|---|---|---|
| Customer data inventory | Annually | Engineering |
| Security attributes | Annually | Engineering / Security |
| Access permissions | Periodically | DevOps |
Updates to system architecture will trigger review and update of this documentation.
17. Customer Data Minimization ¶
The system is designed following the principle of data minimization, ensuring that only the minimum amount of customer data required for functionality is collected and stored.
Key characteristics include:
- Only a hashed identifier (shaEmail) is stored for subscription management.
- Plaintext email addresses are never stored in the system.
- The system does not store other personal information such as names, addresses, phone numbers, or payment data.
- Customer data storage is limited to a single controlled database location.
By minimizing the amount of stored personal data and using a hashed identifier, the system significantly reduces the potential exposure of customer information.
18. Summary ¶
The system stores minimal customer data limited to hashed email identifiers used for notification subscriptions.
Customer data is stored securely within Amazon RDS PostgreSQL, protected by AWS security controls including encryption, network isolation, and access control.
Security attributes are associated with customer data and are periodically reviewed to ensure continued compliance with organizational security requirements.