Securing Your Database Estate Against AI-Driven Threats with VMware Data Services Manager

Ernest Nichols, Dave Cook
Field Application Engineers • VCF • VMware by Broadcom

---

The threat landscape facing enterprise databases has changed, and quickly. Attackers are using AI not as an experiment, but as an operational tool.

AI-assisted malware adapts faster than signature-based defenses can track. Ransomware attack campaigns that once required days of manual reconnaissance by infiltrators can now be orchestrated in hours. As frontier AI models evolve, they introduce unprecedented cyber threats by powering autonomous exploits. These advanced systems can scan infrastructure, chain complex vulnerabilities, and locate mismanaged databases at machine speed. Unlike earlier generations of cyber attacks, frontier AI-driven campaigns can independently execute sophisticated, lateral movements across an entire enterprise network before traditional defenses can react.

Most enterprise databases were not designed to withstand this kind of pressure. Not because the technology is inherently weak, but because of how database infrastructure has typically been built and managed over time.

The Hidden Risk: Database VM Sprawl and Configuration Drift

In most organizations, the database estate grew organically over years, which is another way of saying it grew without a consistent plan. Each new application needed a database, a DBA provisioned a VM, configured it by hand, and moved on to the next ticket. Add multiple database engines, a few rounds of staff turnover, evolving security policies, and the result is what I call “Database VM Sprawl”: hundreds of handcrafted database VMs, each one slightly different from the next.

Different OS patch levels. Different configuration parameters. Different security settings (or missing security settings) applied after some instances were already deployed. No reliable, complete inventory of what’s actually running, and no practical way to verify that every instance is consistently configured.

This is precisely the attack surface that AI-driven exploit tools are optimized for. They probe for the inconsistencies: the one VM that was missed in the last patching cycle, the overly permissive configuration parameter that predates your current security policy, the forgotten service account with excessive privileges. These are predictable outcomes of manual database management, and modern automated threats are specifically designed to find and exploit them.

Why On-Premises Requires Active Security

There’s an assumption worth examining: that keeping databases on-premises makes them inherently more secure than the cloud. Physical control of your infrastructure matters, particularly when it comes to data sovereignty and the ability to enforce your own policies without shared-responsibility ambiguity. But physical control doesn’t automatically translate into a secure database posture. It means you are responsible for achieving that security.

For organizations in regulated industries (e.g. government, healthcare, financial services), this responsibility has very specific requirements:

• FIPS 140-2 validated cryptography. STIG compliance across the platform and base OS images.
• Tamper-resistant audit trails that feed into your SIEM.
• Demonstrable, consistent configuration across your entire database estate.
• And critically, the ability to show auditors not just that a policy exists, but that it is enforced uniformly and continuously.

A Hardened Foundation from Day One

The security architecture of DSM starts at the infrastructure layer, and the choices made there have implications that cascade through the entire system.

Microsoft SQL Server runs on Ubuntu 22.04 nodes within managed Kubernetes clusters. This specific operating system configuration is used because it complies with the Microsoft technical support policy for running SQL Server on Linux. PostgreSQL and MySQL databases managed by DSM run on Photon OS 5.0 base images.

Direct, persistent root access to database VMs is not supported. This is an intentional architectural decision, not a limitation. Database VMs are treated as secure, disposable appliances — not as general-purpose Linux servers that happen to run a database engine. The operating environment is owned and managed by the platform. This design removes an entire class of attack vector: a compromised credential cannot be leveraged to modify the underlying OS, install persistence mechanisms, or pivot to other systems from the database node itself.

The DSM appliance and all base OS images ship already compliant with STIG standards. This means you land on a security baseline rather than having to work toward one after deployment. There is no post-installation hardening sprint to budget for; the starting condition is already correct.

Every management operation (provisioning, configuration changes, patching, scaling) generates a detailed audit log entry. Those logs can be forwarded to external SIEM destinations, including Aria Operations for Logs or any syslog-compatible target. Database operations become visible within your existing security monitoring infrastructure, with no changes required to your operational workflows and no risk of management activity falling outside the visibility of your security team.

Identity, Access, and Network Controls

Authentication is where database security most commonly breaks down in practice. Default credentials that were never rotated. Local accounts that predate directory services integration. Service accounts with passwords unchanged for years because rotating them risks breaking a dependent application. These are not edge cases; they are the predictable outputs of database environments that were built without centralized identity governance.

DSM integrates database authentication directly into your existing identity management structure rather than creating a parallel authentication system that exists outside your standard controls.

For Microsoft SQL Server, DSM supports Windows Authentication via Active Directory and Kerberos integration. SQL Server databases are governed by the same AD policies, the same account lifecycle management, and the same access review processes that govern the rest of your enterprise environment. There are no separate SQL Server logins to audit separately, no local accounts to inventory and manage outside your standard IAM tooling.

For PostgreSQL, certificate-based authentication provides a cryptographically strong identity mechanism that integrates with your PKI infrastructure. Across the platform, DSM supports LDAP and LDAPS for both platform login and database authentication, meaning your organization’s access policies are enforced uniformly regardless of which database engine a user or application is connecting to.

Network architecture is equally important — because authentication controls the front door, but network segmentation controls what can happen after a breach occurs inside your perimeter. DSM integrates with NSX VPCs to provide each project or tenant with dedicated, isolated networking policies. Development environment databases are not reachable from production workloads. Through integration with the NSX Distributed Firewall, administrators can implement micro-segmentation rules that strictly limit east-west traffic between database workloads, containing the blast radius if any workload elsewhere in the environment is compromised.

Automated Lifecycle Management as a Security Control

Consistent, timely patching is the most impactful security control available for database infrastructure. Not the most sophisticated. Not the most architecturally elegant. Simply the most impactful, because the majority of successful database attacks exploit known vulnerabilities for which patches were available long before the breach occurred.

In manually managed database environments, patching is structurally difficult to sustain at scale. It requires scheduling maintenance windows, testing across potentially hundreds of instances, and coordinating execution across an estate where every instance is slightly different. The result, in most organizations, is a patching backlog which reads like an inventory of exploitable vulnerabilities.

DSM supports patching across the entire database fleet: PostgreSQL, MySQL, and Microsoft SQL Server with a 99.5% patch success rate.  While PostgreSQL leverages a fully automated model for minor patch applications, MySQL and SQL Server currently utilize an administrator-authorized mechanism for engine updates. Consistent with platform safety standards, all major version transitions remain manual operations. The patching backlog disappears because it cannot accumulate; the system keeps the fleet
current without requiring manual scheduling or preparation.

This is what makes automated lifecycle management a security control, not just an operational convenience. When the base images are STIG-compliant, when FIPS-enabled cryptography is the platform baseline, when every database is provisioned from the same secure template with the same policies applied, and when patching runs automatically across the entire fleet, you have structurally eliminated the configuration inconsistency that makes automated attack frameworks effective.

Policy-based governance extends this consistency to every provisioning event. Regardless of whether a database instance is provisioned by an experienced DBA or by a developer using the self-service portal, it is created according to the same organizational security policies: meeting the same security baseline, integrated with the same authentication infrastructure, subject to the same network controls. The variation inherent in manual provisioning is removed by design, and with it, the unintended vulnerabilities that variation introduces.

Getting Started: A Practical Path Forward

The security improvements described here are real, but they are not automatic. NSX integration for network isolation requires configuration. Active Directory integration for SQL Server needs to be established. SIEM forwarding for audit logs needs to be pointed at the right destination. DSM provides the architecture, the automation, and the secure foundations; the organizational policies that define the right security posture for your environment are yours to configure.

What the platform does is enforce those policies relentlessly, at scale, without requiring ongoing human intervention to maintain consistency. Once established, the security posture holds across every database engine, every new provisioning operation, and every patch cycle just as reliably as during an annual compliance review. Standard operational policy dictates that if a custom schedule is not defined at the time of database instantiation, the platform defaults to a six-hour maintenance window commencing every Saturday at 23:59. After an administrator has staged a designated patch bundle, all compatible database instances will automatically proceed with their OS and operator updates during this recurring window (with PostgreSQL also receiving fully automated engine updates).

For organizations looking to make meaningful progress, a staged approach works well. Start by gaining visibility into your current database estate: understanding what is actually running, where the patch gaps are, and where manual configuration drift is most significant. Identify the highest-risk workloads: the most critical databases currently managed manually with the greatest potential for compliance exposure. Migrate those first, not because DSM requires a disruptive cutover, but because the security improvement is largest and most immediate where the inconsistency risk is highest.

From there, DSM’s policy enforcement and automated lifecycle management maintain the posture you establish without the constant operational overhead that manual management requires.

AI-driven threats are going to continue getting faster and more sophisticated. The question isn’t whether your database estate needs to operate at a higher security baseline. It      does. The question is whether you have the architecture and automation to maintain that baseline consistently across your entire fleet.

VMware Data Services Manager gives you both.

---

Learn more about VMware Data Services Manager:

• VMware Data Services Manager Product Page
• VMware Data Services Manager – previous blogs on VMware.com
  • Achieve Infrastructure-as-Code for Databases: A Guide for Platform Engineers
  • VMware Data Services Manager Brings more Agile and Resilient Data Infrastructure to Private Clouds
  • Data Services Manager: The Hidden Gem Powering Modern Workloads
  • The CFO’s Case for On-Premises DBaaS: Repatriation and Cost Control