Lesson 29 — Microsoft Defender for Open-Source Relational Databases
Open-source relational databases power web applications, business systems, APIs and data platforms across Azure and AWS.
Microsoft Defender for Open-Source Relational Databases detects anomalous activities that may indicate unusual or harmful attempts to access or exploit supported PostgreSQL, MySQL and MariaDB workloads.
This lesson explains plan scope, supported database services, suspicious authentication, brute-force activity, credential misuse, unusual queries, network controls, diagnostic logging, alert investigation, containment and recovery.
What you will learn
This lesson follows open-source database protection from plan enablement through threat investigation and recovery.
How Microsoft Defender for Open-Source Relational Databases works
↓
PostgreSQL, MySQL or MariaDB authenticates the request
↓
Defender monitors database activity and access patterns
↓
Behavioural analytics and threat intelligence are applied
↓
Anomalous authentication or suspicious database activity is detected
↓
A Defender for Cloud alert is generated
↓
Agent Foskett reviews the user, source, query activity and network path
↓
Compromised credentials or unsafe exposure are identified
↓
Accounts are disabled and passwords are rotated
↓
Firewall rules and identity permissions are tightened
↓
Monitoring confirms the suspicious activity has stopped
Open-source database protection layers
| Layer | Purpose | Example |
|---|---|---|
| Identity | Identify the connecting user or workload. | Microsoft Entra identity or database user. |
| Authorisation | Limit database permissions. | Least-privilege database role. |
| Network | Restrict connection paths. | Private endpoint and firewall. |
| Transport | Protect credentials and data in transit. | TLS enforcement. |
| Application security | Prevent unsafe query construction. | Prepared statement. |
| Threat detection | Detect anomalous database activity. | Defender alert. |
| Investigation | Reconstruct access and impact. | Database logs and Azure Activity Log. |
Learning objectives
- Explain Defender for Open-Source Relational Databases.
- Identify supported Azure and AWS database services.
- Recognise anomalous authentication and query behaviour.
- Review identity, credential and network risk.
- Investigate Defender alerts.
- Contain compromised accounts and exposed passwords.
- Validate secure recovery.
What are open-source relational databases?
PostgreSQL, MySQL and MariaDB are widely used relational database engines that store structured application and business data.
What is Defender for Open-Source Relational Databases?
Microsoft Defender for Open-Source Relational Databases is part of Defender for Databases and provides continuous monitoring and threat detection for supported open-source relational database services.
Azure support
On Azure, the plan protects supported Azure Database for PostgreSQL and Azure Database for MySQL services. MariaDB appears in Microsoft alert-response guidance for supported open-source database workloads.
AWS support
Supported AWS RDS and Aurora PostgreSQL, MySQL and MariaDB workloads can also receive database threat protection when correctly connected and onboarded.
PaaS protection
The plan is designed for supported platform database services. Do not assume the same coverage applies to self-managed databases on arbitrary virtual machines.
Continuous monitoring
Defender monitors database activity and analyses patterns for indicators of unusual or harmful access.
Anomalous authentication
Repeated failures, successful logins from unfamiliar locations or access by an identity outside its normal pattern can trigger investigation.
Brute-force activity
A high number of failed sign-in attempts using different credentials may indicate a brute-force attack against the database endpoint.
Successful suspicious logins
A successful login can be more serious than repeated failures when it originates from an unexpected source or uses a rarely seen administrative account.
Credential reuse
Database passwords reused across systems can be exposed through unrelated breaches and later used against cloud databases.
Long-lived passwords
Credentials that remain unchanged for years increase the window in which old disclosures, support tickets or developer copies can be abused.
Administrator accounts
Highly privileged database accounts should not be used by routine applications. Separate administration from application access.
Database roles
Use database-native roles to grant only the schemas, tables and operations required by each user or application.
Least privilege
An application that only reads selected tables should not have permission to create users, export all data or modify database configuration.
Microsoft Entra authentication
Where supported, Microsoft Entra authentication can reduce reliance on static database passwords and improve identity attribution.
Managed identities
Managed identities allow Azure workloads to access supported databases without embedding long-lived credentials in application configuration.
Secrets management
Store unavoidable credentials in a controlled secret-management system such as Azure Key Vault rather than source code, scripts or support notes.
Credential rotation
Rotate database credentials after suspected exposure and according to the organisation's credential lifecycle policy.
Public endpoints
Public database endpoints should be restricted to approved networks and applications. Internet reachability increases scanning and password-attack exposure.
Firewall rules
Review server-level firewall rules and remove broad ranges, obsolete developer addresses and temporary exceptions.
Private endpoints
Private endpoints can provide private network connectivity to supported Azure database services and reduce exposure through public paths.
TLS enforcement
Require encrypted database connections and reject clients that cannot meet the supported TLS configuration.
Certificate validation
Applications should validate the database server certificate rather than accepting any certificate presented during connection setup.
Threat intelligence
Microsoft threat intelligence adds context when database access originates from known malicious infrastructure or suspicious hosting providers.
Behavioural analytics
Defender compares activity with established patterns to identify behaviour that differs from expected application or administrator use.
Suspicious query behaviour
Unexpected query volume, broad table access, unusual administrative statements or repeated schema discovery can indicate compromise.
Data exfiltration indicators
Large exports, rapid reads across many tables or access outside normal business hours can signal attempted data theft.
SQL injection
Application vulnerabilities can allow untrusted input to alter database queries. Defender alerts supplement but do not replace secure query construction.
Parameterised queries
Use parameterised queries and prepared statements so user input is treated as data rather than executable query structure.
Input validation
Validate expected format, length and range before data reaches the database layer.
Diagnostic settings
Enable supported database logging and diagnostic settings to provide evidence for security investigations and operational troubleshooting.
Azure Monitor
Use Azure Monitor and Log Analytics to centralise relevant database, platform and activity information.
Azure Activity Log
Review control-plane events such as firewall changes, server configuration, role assignments, Defender enablement and deletion actions.
Database audit logs
Database audit or general logs can provide user, source, connection, query and object-access context depending on the engine and configuration.
Application telemetry
Application logs help map suspicious database sessions back to a user action, code path, host or deployment.
Microsoft Sentinel
Send relevant alerts and logs to Microsoft Sentinel when cross-service correlation, hunting and automated response are required.
Defender alerts
Alerts contain details about anomalous database activity, affected resources, possible causes and recommended response steps.
Initial triage
Confirm the database server, engine, account, source IP, location, authentication result, time range and activity type.
Authentication investigation
Review failed and successful logins, username patterns, credential age, password resets and access from unfamiliar sources.
Query investigation
Identify which tables, schemas and statements were accessed and whether the activity matches the application's normal function.
Identity investigation
Review Microsoft Entra identities, database users, service principals, managed identities and administrator accounts associated with the activity.
Network investigation
Compare the source with approved firewall rules, private endpoints, application hosts and expected administration networks.
Scope investigation
Search for the same credential, source address, identity or attack pattern across other database servers and cloud resources.
Containment
- Disable compromised database users.
- Rotate exposed passwords and connection strings.
- Revoke or restrict affected identities.
- Remove broad firewall rules.
- Block malicious sources.
- Restrict public access.
- Preserve database and platform logs.
Recovery
Update approved applications with new credentials or managed identity, restore required access and confirm the database remains available.
Validation
Confirm old credentials no longer work, suspicious connections have stopped, firewall restrictions are effective and legitimate applications function normally.
Agent Foskett investigation: “The password wasn’t guessed…”
↓
Defender detected repeated successful logins from an unexpected country
↓
The sessions used a privileged administrator account
↓
Large exports followed shortly afterwards
↓
Agent Foskett reviewed the authentication history
↓
The password had not changed for three years
↓
The same credential had appeared in an old developer backup
↓
The attacker did not brute-force the password
↓
They reused a credential that still worked
↓
The administrator account was disabled
↓
Database passwords and connection strings were rotated
↓
The application moved to Microsoft Entra authentication where supported
↓
Broad firewall rules were removed
↓
Private network access was enforced
↓
Export activity was reviewed to determine affected data
↓
The password was not guessed
↓
It had simply been valid for far too long
Open-source database investigation checklist
| Area | Question | Evidence |
|---|---|---|
| Database | Which engine, server and database were involved? | Defender alert and resource inventory. |
| Authentication | Were attempts failed, successful or both? | Database logs and alert evidence. |
| Identity | Which database user or Entra identity connected? | Username, object ID and role assignments. |
| Source | Where did the activity originate? | IP address, geography and hosting provider. |
| Query activity | Which schemas, tables and statements were accessed? | Audit, general or application logs. |
| Volume | Was data exported or accessed at unusual scale? | Query volume, duration and result size. |
| Credential | Could the same password or connection string still be used? | Credential age and rotation status. |
| Network | Was the source allowed by current firewall rules? | Firewall, endpoint and routing configuration. |
| Recovery | Were credentials rotated and access retested? | Change records and validation results. |
Key takeaways
- Defender for Open-Source Relational Databases protects supported PostgreSQL, MySQL and MariaDB workloads.
- It detects anomalous access, brute-force behaviour and suspicious database activity.
- Azure and supported AWS RDS workloads can receive threat protection when correctly onboarded.
- Successful logins from unexpected sources require investigation.
- Long-lived and reused database passwords create significant risk.
- Microsoft Entra authentication and managed identities can reduce static credential exposure.
- Firewall rules, private endpoints and TLS reduce network and transport risk.
- Prepared statements and parameterised queries reduce SQL injection risk.
- Database and platform logs provide essential investigation evidence.
- Containment is complete only when old credentials and unsafe network paths no longer work.
What Agent Foskett checked
- Defender alert
- Database engine
- Server and database
- Authentication outcome
- Database user
- Source IP
- Credential age
- Query activity
- Export volume
- Firewall rules
- Private access
- Other affected servers
Best practices
- Enable Defender protection.
- Use least-privilege roles.
- Prefer Entra authentication where supported.
- Rotate long-lived passwords.
- Store secrets in Key Vault.
- Restrict public access.
- Use private endpoints where suitable.
- Require TLS.
- Enable diagnostic logging.
- Investigate unusual successful logins.
Related Agent Foskett resources
Continue learning
What is Microsoft Defender for Open-Source Relational Databases?
Microsoft Defender for Open-Source Relational Databases is a Microsoft Defender for Cloud plan that detects anomalous access, brute-force behaviour and suspicious activity across supported PostgreSQL, MySQL and MariaDB workloads.
Microsoft Defender for Open-Source Relational Databases Lesson
This Agent Foskett lesson explains database threat detection, credential misuse, authentication, network controls, diagnostic logging, alert investigation, containment and recovery.
