How to Build a DIY Database Proxy for Better Security

You’ve set up proper user roles and permissions for your database. You even have audit logs enabled. Yet when you try to trace who actually executed that suspicious query, all you see is “user: app_service” – the same shared service account used by dozens of microservices. Who actually triggered that sensitive data access? Your expensive database logs have no idea.

This visibility gap isn’t just frustrating – it’s dangerous. As one database administrator put it, “90% of the time, it’s just DB user-level info (roles, grants, maybe audit logs).” But the moment you have shared DB users or service accounts reused across services, “you lose context” about who or what is actually accessing your data.

Enterprise-grade database security solutions promise to solve this problem, but their price tags can be astronomical. The good news? You can build your own database proxy that provides accessor-level visibility without breaking the bank.

What is a Database Proxy? The Gatekeeper Your Database Needs

A database proxy is an intermediary server that sits between your applications and your database. Think of it like a restaurant manager (the proxy) coordinating orders (database requests) between waiters (applications) and the chef (database).

As a specific type of reverse proxy designed for databases, it provides several critical security benefits:

1. Acts as a Security Gatekeeper: It enforces security policies and blocks unauthorized access before requests ever reach your database, creating a crucial choke point for monitoring.
2. Provides Accessor-Level Visibility: Unlike basic database logs that only show which database user executed a query, a properly configured proxy can track which specific application, service, or human accessor initiated the request.
3. Monitors for Suspicious Patterns: By logging all database traffic, the proxy can detect out-of-pattern access, excessive queries, or potential data exfiltration attempts.
4. Enhances Authentication: It can integrate with your existing Privileged Access Management (PAM) systems and secrets management tools for better authorization controls.

Beyond security, a database proxy offers performance advantages through connection pooling (reducing database overhead), query caching (improving response times), and load balancing (distributing queries across replicas).

The DIY Advantage: Why Open-Source Beats Pricey Alternatives

Commercial solutions like AWS RDS Proxy provide robust features but can be “obscenely overpriced” according to many users. They also may not work with external databases outside your cloud environment.

Building your own proxy using open-source tools offers several advantages:

1. Cost-Effectiveness: Open-source proxies like ProxySQL, HAProxy with PGBouncer, or NGINX can be deployed at a fraction of the cost of commercial solutions.
2. Flexibility: DIY proxies work with any database, regardless of where it’s hosted – on-premises, in multiple clouds, or hybrid environments.
3. Customization: You can tailor logging, alerting, and security rules to your specific requirements rather than being constrained by a vendor’s implementation.
4. Transparency: With full visibility into the proxy’s code and configuration, you know exactly how your security controls are implemented.

Planning Your Proxy: An Essential Pre-Build Checklist

Before diving into implementation, assess your environment against these criteria:

• Traffic Patterns: Do you have high-volume applications or many short-lived connections (like serverless functions)?
• Security Requirements: What level of monitoring do you need? Are you handling sensitive data requiring strict access controls?
• Performance Needs: Is connection pooling important for your workload?
• Scalability Considerations: Will you need to distribute traffic across multiple database instances?
• Compliance Requirements: Do you need to maintain detailed audit trails for regulatory purposes?

With these questions answered, let’s build a basic database proxy using ProxySQL for MySQL databases. This approach can be adapted for PostgreSQL using PGBouncer or other database types.

Step-by-Step Guide: Building a Secure Proxy with ProxySQL and AWS

Step 1: Set Up Your Infrastructure

1. Launch an EC2 Instance: Select an Ubuntu instance in the same VPC as your database for low-latency communication.
2. Configure Security Groups:
   • Allow inbound MySQL traffic (port 3306) from your application servers
   • Allow outbound MySQL traffic to your database
   • Restrict SSH access to admin IPs only
3. Install ProxySQL: # Update package list sudo apt-get update # Install ProxySQL sudo apt-get install -y proxysql # Start and enable ProxySQL service sudo systemctl start proxysql sudo systemctl enable proxysql

Step 2: Configure ProxySQL

1. Connect to ProxySQL Admin Interface: mysql -u admin -padmin -h 127.0.0.1 -P 6032
2. Add Your Database Backend: # Replace with your actual database endpoint INSERT INTO mysql_servers (hostgroup_id, hostname, port, weight) VALUES (0, 'your-db-endpoint.rds.amazonaws.com', 3306, 100); # Apply changes LOAD MYSQL SERVERS TO RUNTIME; SAVE MYSQL SERVERS TO DISK;
3. Configure User Authentication: # Create proxy users that applications will use to connect INSERT INTO mysql_users (username, password, default_hostgroup) VALUES ('app_service', 'secure_password', 0); # Apply changes LOAD MYSQL USERS TO RUNTIME; SAVE MYSQL USERS TO DISK;
4. Set Up Basic Query Rules: # Create a rule that logs all queries INSERT INTO mysql_query_rules (rule_id, active, match_digest, apply, log) VALUES (1, 1, '.', 1, 1); # Apply changes LOAD MYSQL QUERY RULES TO RUNTIME; SAVE MYSQL QUERY RULES TO DISK;

Step 3: Configure Advanced Logging for Accessor-Level Visibility

The key to solving the “who actually triggered what” problem is capturing and correlating the right metadata. ProxySQL allows us to log detailed information about each connection:

1. Enable Verbose Query Logging: # Set log level to debug for more detailed information UPDATE global_variables SET variable_value='debug' WHERE variable_name='mysql-log_level'; # Configure the log file location UPDATE global_variables SET variable_value='/var/log/proxysql.log' WHERE variable_name='mysql-log_file'; # Apply changes LOAD MYSQL VARIABLES TO RUNTIME; SAVE MYSQL VARIABLES TO DISK;
2. Capture App/Service Identifiers: Modify your application connection strings to include identifiers in comments: # Example Java connection with metadata String url = "jdbc:mysql://proxy:6033/mydb?useSSL=true&connectionComment=service:inventory-api;team:fulfillment;env:prod";
3. Create a Rule to Parse Service Info: INSERT INTO mysql_query_rules (rule_id, active, match_digest, replace_pattern, apply) VALUES (2, 1, '\/\*.*service:(.*?);.*\*\/', '\1', 1); LOAD MYSQL QUERY RULES TO RUNTIME; SAVE MYSQL QUERY RULES TO DISK;

Hardening Your Proxy: Advanced Security and Management

Now that your proxy is operational, let’s enhance its security posture:

Implement Encryption with SSL/TLS

1. Enable SSL Between Applications and Proxy: UPDATE global_variables SET variable_value='/path/to/cert.pem' WHERE variable_name='mysql-ssl_cert'; UPDATE global_variables SET variable_value='/path/to/key.pem' WHERE variable_name='mysql-ssl_key'; UPDATE global_variables SET variable_value='true' WHERE variable_name='mysql-ssl'; LOAD MYSQL VARIABLES TO RUNTIME; SAVE MYSQL VARIABLES TO DISK;
2. Enable SSL Between Proxy and Backend Database: UPDATE mysql_servers SET use_ssl=1 WHERE hostgroup_id=0; LOAD MYSQL SERVERS TO RUNTIME; SAVE MYSQL SERVERS TO DISK;

Implement Row-Level Security for Granular Control

While the proxy controls who can connect, row-level security (RLS) determines what specific data rows each user can access once connected. This creates a powerful multi-layered security model:

1. Implement RLS in Your Database: For MySQL, this typically involves using stored procedures with user-specific logic.
2. Configure the Proxy to Route Queries to Appropriate Procedures: INSERT INTO mysql_query_rules (rule_id, active, match_pattern, replace_pattern, apply) VALUES (3, 1, '^SELECT .* FROM sensitive_data', 'CALL get_filtered_data(\'$service_name\')', 1); LOAD MYSQL QUERY RULES TO RUNTIME; SAVE MYSQL QUERY RULES TO DISK;

Set Up Monitoring and Alerting for Security Threats

1. Configure Thresholds for Suspicious Activity: # Alert on excessive query volume INSERT INTO mysql_query_rules (rule_id, active, match_digest, apply, flagOUT) VALUES (4, 1, '^DELETE', 1, 1); # Create an alert if more than 10 deletes in 5 minutes # (Implementation depends on your monitoring system)
2. Monitor for Over-Privileging and Out-of-Pattern Access: Regularly review the proxy logs to identify:
   • Unexpected query patterns from specific services
   • Attempts to access tables not normally used by a service
   • Failed authentication attempts that might indicate brute force attacks
3. Integrate with Security Tools: Forward logs to your SIEM or security monitoring platform to correlate database access with other security events.

Practical Security Enhancements

Here are additional steps to further strengthen your database security posture:

1. Implement Precise Authorization Controls: Create specific query rules for different application services, limiting each to only the SQL operations they legitimately need.
2. Add Circuit Breakers for Abuse Prevention: Configure the proxy to temporarily block connections that exceed normal query volume thresholds.
3. Implement Inputs/Outputs Logging: For particularly sensitive operations, log both the query inputs and the data returned to spot potential data exfiltration.
4. Rotate Credentials Regularly: Update the mysql_users table with new passwords on a schedule, coordinating with your secrets management system.

Conclusion: Taking Control of Your Database Security

A DIY database proxy provides the accessor-level visibility that standard database logs lack. By tracking which specific application, service, or human accessor initiated each database request, you gain crucial context for security monitoring and incident response.

The approach outlined here costs a fraction of commercial solutions while providing similar security benefits. It works across any database environment, giving you flexibility that vendor-locked solutions can’t match.

Start small by implementing a proxy in a development environment, then expand to production once you’re comfortable with the configuration. The enhanced security and performance benefits make this a worthwhile investment for any organization dealing with sensitive data.

For ongoing management, regularly review your proxy logs and query patterns, updating rules as your application evolves. This proactive approach to database security will help you stay ahead of threats while maintaining the granular visibility needed for effective security monitoring.

Remember: When it comes to database security, knowing who actually triggered what isn’t just a nice-to-have—it’s essential for protecting your most valuable data assets.

Frequently Asked Questions

What is a database proxy?

A database proxy is an intermediary server that sits between your applications and your database, managing all incoming database requests. Think of it as a security gatekeeper that intercepts queries, allowing it to enforce security policies, log detailed information about the request’s origin, and even improve performance through connection pooling and caching before the request ever reaches the database.

Why use a database proxy if my database already has audit logs?

Standard database audit logs often can’t identify the true origin of a query when shared service accounts are used; they only show the generic database user (e.g., app_service). A database proxy solves this critical visibility gap. It captures metadata from the application’s connection—like the specific microservice name—and logs it with the query, allowing you to trace every action back to the specific service that initiated it.

How does a DIY proxy provide more visibility than standard logs?

A DIY proxy achieves greater visibility by capturing application-level metadata passed in the database connection string and logging it with the corresponding query. You can modify your application’s connection string to include unique identifiers in comments (e.g., service:inventory-api). The proxy is then configured with rules to parse this information and record it in its logs, linking every database action to a specific, identifiable application.

What are the main advantages of a DIY database proxy over a commercial solution?

The primary advantages of a DIY database proxy are cost-effectiveness, flexibility, and full customization. Commercial solutions can be very expensive and may lock you into a specific cloud ecosystem. Building your own with open-source tools like ProxySQL or PGBouncer significantly reduces costs, works with on-premise or multi-cloud databases, and allows you to tailor security rules and logging precisely to your organization’s needs.

What tools can I use for a PostgreSQL database proxy?

For PostgreSQL databases, a popular and effective open-source tool for creating a database proxy is PGBouncer, which is excellent for connection pooling. You can also use general-purpose proxies like HAProxy or NGINX, often in combination with PGBouncer, to build a robust and secure proxy solution for a PostgreSQL environment using the same principles outlined in this article.

Can a database proxy also improve performance?

Yes, a database proxy can significantly improve performance in addition to enhancing security. Key features like connection pooling reduce the overhead of opening and closing database connections, query caching serves frequent requests instantly, and load balancing distributes traffic across multiple database replicas to prevent bottlenecks.

Is setting up a database proxy a complex project?

Setting up a basic database proxy can be a straightforward project, especially when starting in a non-production environment. While advanced configurations with high availability and complex routing rules require more expertise, the steps for a basic setup are achievable for teams with DBA or DevOps skills. The key is to start small, test thoroughly, and roll out the proxy incrementally.