Your customer data platform (CDP) holds millions of records, accessible to marketing teams, analytics tools, and third-party integrations. One misconfigured endpoint can expose everything.
Consider the case of McDonald's Indonesia, where over 40 million records became publicly accessible through their CDP. This exposure included 28 million customer records (names, emails, phone numbers, device IDs) and over 71,000 corporate records with ad campaign data. Cybernews discovered the open database and reported it before it was closed. This wasn't a sophisticated attack; it was an exposed database anyone could access.
Preparing for Security
Before securing your CDP, gather these essential assets:
Access inventory: Document every system, service, and person with credentials to your CDP, including API keys, service accounts, and third-party integrations. If you can't list who has access, you can't secure it.
Network diagram: Map where your CDP sits in your infrastructure. Identify which networks can reach it, what firewall rules apply, and where data flows in and out.
Data classification: Understand what's in the platform. Are there personal identifiers under GDPR Article 4(1)? Special category data under Article 9? Corporate confidential information? You can't apply appropriate controls without knowing what you're protecting.
Existing authentication mechanisms: Document current access controls, such as username and password, API keys, or SAML, before making changes.
Step-by-Step Implementation
1. Eliminate Public Exposure
Start with the most critical risk: databases accessible from the internet.
Run a port scan against your CDP's public IP addresses. Use nmap with the -sV flag to identify open ports and services:
nmap -sV -p- [your-cdp-ip-range]
Any database port (3306 for MySQL, 5432 for PostgreSQL, 27017 for MongoDB) visible from the internet is a critical finding. Close it immediately by updating your network security group or firewall rules to block inbound traffic from 0.0.0.0/0.
Your CDP should be behind a private subnet with no direct internet routing. If external access is necessary, place it behind an API gateway or application load balancer that enforces authentication before requests reach the database layer.
2. Implement Network Segmentation
Create a dedicated network segment for your CDP with explicit ingress and egress rules.
Define an allowlist of IP ranges that can reach the CDP. This typically includes:
- Your application servers that write customer data
- Analytics platforms that query aggregated data
- Administrative jump hosts for database maintenance
Configure security groups or firewall rules that deny all traffic by default, then add specific allow rules for each legitimate source. Document the business justification for each rule in your change management system.
For AWS environments, use VPC security groups with rules like:
Inbound: Allow TCP 5432 from 10.0.1.0/24 (app servers)
Inbound: Allow TCP 5432 from 10.0.2.50/32 (admin jump host)
Outbound: Deny all
3. Enforce Authentication and Authorization
Replace any default credentials immediately. Generate strong, unique passwords for each database user and store them in a secrets management system like HashiCorp Vault or AWS Secrets Manager.
Create role-based database accounts with minimum necessary privileges:
- Read-only analytics accounts:
SELECTonly on specific tables - Application service accounts:
INSERT,UPDATE,DELETEon customer data tables, noDROPorALTER - Administrative accounts: Full privileges, restricted to specific IP addresses, require MFA
Implement this in PostgreSQL with:
CREATE ROLE analytics_reader WITH LOGIN PASSWORD '[generated-password]';
GRANT SELECT ON customer_data TO analytics_reader;
REVOKE ALL ON SCHEMA public FROM PUBLIC;
For API access, rotate API keys every 90 days. Set expiration timestamps in your secrets manager and create calendar reminders to regenerate keys before they expire.
4. Enable Comprehensive Logging
Configure your CDP to log every access attempt, query execution, and schema change.
Enable database audit logging. In PostgreSQL, modify postgresql.conf:
log_connections = on
log_disconnections = on
log_statement = 'all'
log_duration = on
Forward logs to a centralized SIEM or log management platform. Don't store logs on the same server as the database, if the CDP is compromised, you'll lose your audit trail.
Set up alerts for suspicious patterns:
- Queries returning more than 10,000 rows
- Access attempts from unrecognized IP addresses
- Failed authentication attempts exceeding three in five minutes
- Schema modifications outside maintenance windows
5. Apply Data-Level Controls
Implement Column-Level Security for sensitive fields. Encrypt email addresses, phone numbers, and device IDs at rest using your database's native encryption features.
For PostgreSQL, use the pgcrypto extension:
CREATE EXTENSION pgcrypto;
ALTER TABLE customers ADD COLUMN email_encrypted bytea;
UPDATE customers SET email_encrypted = pgp_sym_encrypt(email, '[encryption-key]');
Store encryption keys in your secrets manager, not in application code or configuration files.
Create database views that mask or redact sensitive fields for users who don't need full access:
CREATE VIEW customers_masked AS
SELECT
customer_id,
CONCAT(LEFT(name, 1), '***') AS name_masked,
CONCAT('***@', SPLIT_PART(email, '@', 2)) AS email_masked
FROM customers;
Grant analytics teams access to the masked view instead of the underlying table.
Validation
Test your controls systematically.
External exposure test: From a machine outside your network (home internet, mobile hotspot), attempt to connect to your CDP's IP address on database ports. The connection should time out or be refused.
Authentication test: Try connecting with an old password or revoked API key. The attempt should fail and generate an alert.
Authorization test: Log in with a read-only account and attempt to execute an INSERT or DELETE statement. It should fail with a permissions error.
Logging verification: Execute a test query and verify it appears in your centralized logs within 60 seconds. Confirm the log entry includes timestamp, user, source IP, and full query text.
Data encryption check: Query your encrypted columns directly. You should see encrypted bytea values, not plaintext.
Maintenance and Ongoing Tasks
Security isn't a one-time implementation. Schedule these recurring tasks:
Weekly: Review access logs for anomalies. Look for unusual query patterns, off-hours access, or geographic outliers.
Monthly: Audit user accounts and API keys. Remove accounts for departed employees. Rotate API keys that are approaching their 90-day expiration.
Quarterly: Re-run external port scans to verify no new exposures have been introduced by infrastructure changes. Update your network diagram if your CDP architecture has changed.
After any schema change: Review which accounts have access to new tables or columns. Apply encryption to new sensitive fields. Update your data classification documentation.
When integrating a new tool: Document the integration in your access inventory. Create a dedicated service account with minimum necessary privileges. Set a calendar reminder to review whether the integration is still needed in six months.
The McDonald's Indonesia exposure happened because basic controls weren't in place. You don't need sophisticated tooling to prevent it; you need consistent application of access controls, network segmentation, and monitoring. Implement these steps systematically, validate each control, and maintain them through operational discipline.
