Azure Security Basics: NSGs, Key Vault, and Security Center for SMEs

Azure in Mid-Market Companies: More Than Just Microsoft 365

Many mid-market companies use Azure without being aware of it: Microsoft 365 runs on Azure infrastructure, Entra ID is an Azure service, and even OneDrive and SharePoint are built on Azure Storage. But increasingly, smaller organizations are also running their own workloads in Azure: a virtual machine for a line-of-business application, an Azure SQL database for the ERP system, an App Service for the company website, Azure Backup for data protection.

The problem: the security configuration of these Azure resources is often neglected. The focus is on functionality ("It works!") while security settings remain at their defaults. And the defaults in Azure are—unlike Microsoft 365—not insecure by default, but also not optimal. A virtual machine without an NSG is reachable from the internet, a Key Vault without an access policy grants nobody access (good), but without Key Vault the passwords sit in code or in a configuration file (bad).

This article focuses on three Azure services that every organization with Azure workloads should know and configure: Network Security Groups, Key Vault, and Microsoft Defender for Cloud. These are not enterprise features for large corporations but fundamentals that are relevant even with a handful of Azure resources.

Network Security Groups: The Azure Firewall

What Are NSGs?

Network Security Groups (NSGs) are the fundamental network firewall in Azure. They filter network traffic to and from Azure resources based on rules specifying source IP, destination IP, port, and protocol. NSGs can be applied at two levels:

• Subnet level: All resources in the subnet are affected by the NSG. This is the recommended level for basic network segmentation.
• NIC level (Network Interface): The NSG is bound directly to the network interface of a virtual machine. This allows granular per-VM control but increases management complexity.

When both levels are configured, the rules of both NSGs are evaluated. Inbound traffic must pass both NSGs (subnet NSG first, then NIC NSG); outbound traffic is evaluated in reverse order.

Understanding Default Rules

Every NSG contains three default rules that cannot be deleted:

Inbound:

1. AllowVNetInBound (Priority 65000): Allows all traffic within the virtual network
2. AllowAzureLoadBalancerInBound (Priority 65001): Allows traffic from the Azure Load Balancer
3. DenyAllInBound (Priority 65500): Blocks all other inbound traffic

Outbound:

1. AllowVNetOutBound (Priority 65000): Allows all traffic within the virtual network
2. AllowInternetOutBound (Priority 65001): Allows all outbound internet traffic
3. DenyAllOutBound (Priority 65500): Blocks all other outbound traffic

This means: without additional rules, every VM can communicate with every other VM in the same VNet, communicate to the internet, but cannot be reached from the internet (unless a public IP is assigned).

NSG Design for SMEs

For a typical SME scenario with a few Azure resources, the following NSG design is recommended:

Subnet structure:

• Frontend subnet: For web servers and App Services that need to be reachable from the internet
• Backend subnet: For databases and internal applications that should not be reachable from the internet
• Management subnet: For jump hosts and management VMs

NSG rules for the frontend subnet:

• Inbound: Allow HTTPS (443) from Any
• Inbound: Allow HTTP (80) from Any (optional, better to redirect to HTTPS)
• Inbound: Block RDP (3389) and SSH (22) (management only via jump host or Bastion)
• Outbound: Allow SQL (1433) to the backend subnet
• Outbound: Allow HTTPS (443) to Any (for API calls, updates)

NSG rules for the backend subnet:

• Inbound: Allow SQL (1433) only from the frontend subnet
• Inbound: Block everything else (default DenyAllInBound)
• Outbound: Allow HTTPS (443) to Any (for updates and monitoring)

NSG rules for the management subnet:

• Inbound: Allow RDP (3389) or SSH (22) only from the office IP address
• Inbound: Block everything else
• Outbound: Allow RDP/SSH to the frontend and backend subnets

Common NSG Mistakes

Allowing RDP or SSH from the internet: Never open RDP (3389) or SSH (22) for source IP "Any." Basic network segmentation is essential even in Azure. Within minutes, automated attacks will target the open port. Use Azure Bastion (a managed jump host service) or restrict access to the office IP.

Rules that are too broad: A rule that allows "Any" to "Any" on "Any Port" renders the NSG useless. Every rule should be as specific as possible: concrete port, concrete source IP or subnet, concrete destination.

Not evaluating NSGs: NSG Flow Logs (free at the basic level) record which traffic was allowed or blocked by the NSG. Without these logs, you do not know whether your NSGs are correctly configured or whether legitimate traffic is being blocked.

Using only subnet NSGs or only NIC NSGs: Use subnet NSGs as the foundation and NIC NSGs only for exceptions. If you configure both inconsistently, troubleshooting connectivity issues becomes a nightmare.

Azure Key Vault: Managing Secrets Securely

The Problem with Credentials in Code

Every application has secrets: database passwords, API keys, certificates, connection strings. A well-designed secrets management approach is the foundation for secure applications. The question is where these secrets are stored. In practice, there are four common locations, three of which are wrong:

1. In source code (hard-coded): The worst case. The secret ends up in the Git repository and is visible to all developers—potentially even publicly (if the repo is public).
2. In configuration files on the server: Better than in code, but still risky. Anyone with server access can read the file. Backups contain the secrets in plain text.
3. In environment variables: Even better, but not ideal. Environment variables can be accidentally exposed through misconfigurations or debugging output.
4. In Azure Key Vault (correct): Secrets are stored centrally, encrypted, and access-controlled. Applications authenticate via Managed Identity and receive secrets at runtime.

Setting Up Key Vault

Step 1: Create a Key Vault Create one Key Vault per environment (Development, Staging, Production). The name must be globally unique.

• Region: Same region as the application (minimizes latency)
• Pricing tier: Standard (sufficient for most scenarios; Premium offers HSM-backed keys)
• Soft delete: Enabled (prevents accidental permanent deletion, 90-day retention)
• Purge protection: Enabled (prevents even forced deletion during the soft-delete retention period)

Step 2: Configure access policy Key Vault supports two access control models:

• Vault Access Policy (classic): Access permissions are configured directly on the Key Vault
• Azure RBAC (recommended): Access permissions are managed via Azure Role-Based Access Control

Recommendation: Use Azure RBAC. The roles "Key Vault Secrets User" (read) and "Key Vault Administrator" (manage) cover most scenarios.

Step 3: Add secrets Store database passwords, API keys, connection strings, and other secrets as Secrets in the Key Vault. Each secret has a name, a value, and optionally an expiration date and tags.

Step 4: Managed Identity for applications Create a Managed Identity for each Azure resource that needs Key Vault access (VM, App Service, Azure Function). The Managed Identity authenticates automatically with Azure AD without requiring a password or certificate to be configured.

Key Vault for Certificates

In addition to secrets, Key Vault can also manage TLS/SSL certificates:

• Import certificates: Upload existing certificates (PFX format) to the Key Vault
• Create certificates: Key Vault can request certificates directly from integrated CAs (DigiCert, GlobalSign) and automatically renew them
• Distribute certificates: App Services and Application Gateways can pull certificates directly from the Key Vault

Automatic certificate renewal is an often-underestimated benefit: no manual renewal, no forgotten expiration dates, no outages due to expired certificates.

Key Vault Monitoring

Enable the Key Vault's Diagnostics Settings and route logs to a Log Analytics Workspace or a Storage Account:

• AuditEvent: Every Key Vault access is logged (who read which secret and when?)
• AllMetrics: Performance metrics (latency, error rate)

Set up Alert Rules for:

• Key Vault access from unknown IP addresses
• Failed access attempts (401/403 errors)
• Expiring secrets or certificates (warn 30 days before expiration)

Microsoft Defender for Cloud: Monitoring and Compliance

What Is Defender for Cloud?

Microsoft Defender for Cloud (formerly Azure Security Center and Azure Defender) is the central security management platform for Azure. It consists of two components:

Cloud Security Posture Management (CSPM) - free:

• Assessment of the security posture of all Azure resources
• Secure Score for Azure (similar to the Microsoft Secure Score for M365)
• Security recommendations based on the Azure Security Benchmark and other standards
• Regulatory Compliance Dashboard (ISO 27001, NIST, CIS Benchmarks)

Cloud Workload Protection Platform (CWPP) - paid:

• Defender for Servers: EDR protection for VMs (based on Defender for Endpoint)
• Defender for SQL: Threat detection for Azure SQL and SQL Server
• Defender for Storage: Malware scanning for Azure Storage
• Defender for Key Vault: Detection of suspicious Key Vault access
• Defender for App Service: Threat detection for web apps
• Additional plans for containers, DNS, Resource Manager, etc.

CSPM: The Free Starting Point

The free CSPM tier is sufficient to get started. Enable Defender for Cloud in the Azure Portal and review the Secure Score and recommendations:

Secure Score: The Secure Score evaluates the security posture on a scale from 0 to 100 percent. Every recommendation you implement increases the score. The score aggregates status across all Azure subscriptions and resources.

Recommendations: Defender for Cloud provides actionable recommendations grouped by severity (High, Medium, Low):

• "Enable MFA for accounts with owner permissions on subscriptions"
• "Storage accounts should restrict network access using virtual network rules"
• "Subnets should be associated with a Network Security Group"
• "SQL databases should have vulnerability findings resolved"

Each recommendation includes a risk description, remediation guidance, and the affected resources. You can mark recommendations as "Risk accepted" (with justification) or as "Exempt" (if the recommendation is not relevant to your environment).

Regulatory Compliance: The Compliance Dashboard shows how well your Azure environment meets the requirements of various standards. For the ISMS, the ISO 27001 assessment is particularly relevant: it automatically checks which ISO 27001 controls are covered by your Azure configuration and where gaps exist.

CWPP: Activating Paid Plans Selectively

Paid Defender plans are billed per resource type. You do not need to activate all plans—only those relevant to your workloads.

Recommended plans for SMEs:

Defender for Servers P1 vs. P2:

• P1 offers EDR protection (based on Defender for Endpoint), vulnerability scanning, and network hardening recommendations
• P2 additionally offers Just-in-Time VM Access, Adaptive Application Controls, and file integrity monitoring
• P1 is sufficient for most SMEs

Cost Control

Azure security services can cause unexpected costs if you are not careful. Here are some cost-control measures:

• Only activate needed plans: Enable Defender plans only for resource types you actually run in Azure
• Use Cost Analysis: Regularly check in Cost Management what costs the security services are generating
• Budget Alerts: Set budget limits and get notified when costs exceed a threshold
• Log Analytics Workspace: Data retention in the Log Analytics Workspace incurs costs. Set retention to 90 days (default) and extend only when needed

Additional Azure Security Measures

Beyond the three main services, there are further measures to consider for Azure workloads:

Azure Bastion Instead of Open RDP/SSH Ports

Azure Bastion is a managed jump host service that provides RDP and SSH access to VMs through the browser without requiring the VMs to have a public IP address. Access runs over TLS and is authenticated by Entra ID, enabling MFA and Conditional Access.

Cost: from approx. EUR 130/month (Basic SKU). For organizations with only a few VMs, a dedicated jump host may be cheaper, but Azure Bastion is easier to manage and more secure.

Azure Backup

Azure Backup provides automated data protection for VMs, SQL databases, Azure Files, and other resources. Configure Backup Policies with:

• Daily backup, 30-day retention
• Weekly backup, 12-week retention
• Monthly backup, 12-month retention
• Enable soft delete for backups (prevents accidental or malicious deletion of backups). In ISMS Lite, all Azure security measures can be documented as TOMs and the Secure Score can be tracked as a KPI

Resource Locks

Resource Locks prevent accidental deletion or modification of Azure resources:

• CanNotDelete: The resource cannot be deleted but can be modified
• ReadOnly: The resource can neither be deleted nor modified

Set CanNotDelete locks on critical resources: production VMs, databases, Key Vaults, Backup Vaults.

Azure Policy

Azure Policy enforces configuration standards at the subscription or resource group level:

• "Allowed locations": Resources may only be created in specific regions (e.g., West Europe, North Europe)
• "Require tag on resources": Every resource must have certain tags (e.g., Environment, Owner, CostCenter)
• "Audit VMs without managed disks": VMs with unmanaged disks are marked as non-compliant

Azure Policy is free and helps enforce governance standards before misconfigurations occur.

Azure Security in the ISMS

The described Azure security measures cover multiple ISO 27001 controls:

A.8.20 (Network security):

• NSGs as network firewall
• Subnet segmentation
• NSG Flow Logs for monitoring

A.8.21 (Security of network services):

• Azure Bastion for secure management access
• No RDP/SSH from the internet

A.8.24 (Use of cryptography):

• Key Vault for secrets management
• Certificate management and automatic renewal
• Managed Identities instead of credentials in code

A.5.33 (Protection of records):

• Azure Backup for data protection
• Soft delete for backups
• Retention policies

A.8.8 (Management of technical vulnerabilities):

• Defender for Cloud recommendations
• Vulnerability scanning for VMs and SQL
• Secure Score as KPI

A.8.15 (Logging) and A.8.16 (Monitoring):

• Defender for Cloud Alerts
• Key Vault Audit Logs
• NSG Flow Logs
• Activity Log for all Azure management operations

Documentation in the ISMS

For the ISMS, a dedicated "Cloud security policy" document or a section in the overarching IT security policy is recommended, covering the following points:

• Responsibilities: Who manages the Azure subscription? Who configures NSGs? Who manages Key Vault?
• Network architecture: Documentation of VNets, subnets, and NSG rules
• Secrets management: Process for creating, rotating, and deleting secrets in Key Vault
• Monitoring: Who reviews Defender for Cloud recommendations? How often? What happens with critical findings?
• Cost control: Budget and thresholds for Azure security services
• Change management: Process for changes to NSGs, Key Vault access policies, and Defender configurations

Further Reading

• Securing Microsoft 365: The 15 Most Important Security Settings
• Cloud Security for SMEs: Responsibilities, Risks, and Measures
• Network Segmentation for Mid-Market Companies: Concept and Implementation
• Backup Strategy and Restore Tests: The 3-2-1 Rule in Practice
• Microsoft Secure Score: What It Measures and How to Improve It