feat: add rule AZ-DB-008 SQL Server minimum TLS version below 1.2

[dipeshrayg]

What does this PR do?

Adds rule AZ-DB-008: detects Azure SQL Servers that do not enforce a minimum TLS version of 1.2.

Type of change

• New scan rule
• Remediation playbook
• Compliance mapping

Rule details

• Rule ID: AZ-DB-008
• Severity: HIGH
• Category: Database
• Frameworks mapped: NIST / ISO 27001 / SOC 2 (CIS has no numbered control for this specific setting, see below)

Testing

• Returns correct JSON output
• All seven CI checks pass locally
• No hardcoded credentials or secrets
• Tested against a real Azure free trial subscription (no live subscription available in this environment)

Notes on scoping

Checked the actual installed azure-mgmt-sql SDK model before writing this: Server.minimal_tls_version is a plain string (not an enum), and the real Azure API allows an explicit "None" value alongside "1.0"/"1.1"/"1.2"/"1.3", different from the TLS1_0-style values some other Azure services use. The rule and tests match that, flagging a missing attribute, an explicit "None", "1.0", or "1.1".

Verified against the official CIS Azure Foundations Benchmark 2.0.0 control mapping that no numbered control exists for this SQL-server-specific setting (only the storage-account minimum TLS control, 3.15, is numbered, and it doesn't apply to Microsoft.Sql/servers), so this follows the repo's existing N/A-* convention already used for AZ-STOR-006 through AZ-STOR-009.

Related issue

Closes #246

Checklist

• Every commit includes a DCO Signed-off-by trailer
• My code follows the rule template in CONTRIBUTING.md
• I added the matching CLI playbook
• I added all four compliance framework mappings
• I have not committed any real Azure credentials
• My branch name follows the convention: feat/description

[parthrohit22]

Hi @dipeshrayg, thanks for picking up #246! Before I do a full review, could you test this against a real Azure environment? Create a SQL server, set its minimum TLS to different values, run the scanner, then run the playbook. It'll help you understand both your change and how OpenShield behaves end to end. You can get free Azure credits with a student account (Azure for Students).
One thing worth checking there: since Microsoft retired TLS 1.0/1.1 for Azure SQL, what does minimalTlsVersion actually return for new and existing servers, and does the rule still fire the way the tests assume?
If that isn't possible for you, just let me know and I'll review it thoroughly as is. Thanks!

[TFT444]

Reviewed f2aa197. CI all green. Approving.

Rule (az_db_008.py)

• _COMPLIANT_VERSIONS = {"1.2", "1.3"} is the right set: future TLS 1.3 adoption is pre-allowed without needing a code change.
• getattr(server, "minimal_tls_version", None) correctly handles a missing attribute as non-compliant. The inline comment explaining that Azure's API allows the string "None" (distinct from Python None) is exactly the kind of why-not-what comment this codebase needs.
• CIS N/A convention is correctly applied with a clear justification citing the actual CIS Azure Foundations Benchmark 2.0.0 document. The CIS description explains why no numbered control exists (storage-account TLS 3.15 does not apply to Microsoft.Sql/servers).
• Framework mappings are accurate: NIST PR.DS-2 (data-in-transit protection), ISO 27001 A.10.1.1 (cryptographic controls policy), SOC 2 CC6.7 (protects data in transit). All four match the rule's intent without overreach.
• enisa_pqc.json and ncsc_pqc.json are PQC-specific frameworks; correctly not modified here.

Playbook (fix_az_db_008.sh)

• set -euo pipefail is set.
• Empty-server guard prevents a no-op run from producing misleading output.
• The TLS check allows 1.2 or 1.3 before remediating, consistent with _COMPLIANT_VERSIONS.
• --minimal-tls-version 1.2 (not 1.3) is the right default: remediation brings the server to the minimum acceptable baseline, not the maximum.

Tests (test_rules_database.py)
Six cases cover: compliant 1.2, compliant 1.3, non-compliant 1.0, non-compliant 1.1, explicit string "None", and missing attribute. Every flagged case asserts rule_id, severity, category, resource_type, and the metadata.minimal_tls_version payload. The _REQUIRED_FIELDS assertion on the 1.0 case verifies the full finding schema.