GA: Enhanced Audit in Azure Security Baseline for Linux
We’re thrilled to announce the General Availability (GA) of the Enhanced Azure Security Baseline for Linux—a major milestone in cloud-native security and compliance. This release brings powerful, audit-only capabilities to over 1.6 million Linux devices across all Azure regions, helping enterprise customers and IT administrators monitor and maintain secure configurations at scale. What Is the Azure Security Baseline for Linux? The Azure Security Baseline for Linux is a set of pre-configured security recommendations delivered through Azure Policy and Azure Machine Configuration. It enables organizations to continuously audit Linux virtual machines and Arc-enabled servers against industry-standard benchmarks—without enforcing changes or triggering auto-remediation. This GA release focuses on enhanced audit capabilities, giving teams deep visibility into configuration drift and compliance gaps across their Linux estate. For our remediation experience, there is a limited public preview available here: What is the Azure security baseline for Linux? | Microsoft Learn Why Enhanced Audit Matters In today’s hybrid environments, maintaining compliance across diverse Linux distributions is a challenge. The enhanced audit mode provides: Granular insights into each configuration check Industry aligned benchmark for standardized security posture Detailed rule-level reporting with evidence and context Scalable deployment across Azure and Arc-enabled machines Whether you're preparing for an audit, hardening your infrastructure, or simply tracking configuration drift, enhanced audit gives you the clarity and control you need—without enforcing changes. Key Features at GA ✅ Broad Linux Distribution Support 📘 Full distro list: Supported Client Types 🔍 Industry-Aligned Audit Checks The baseline audits over 200+ security controls per machine, aligned to industry benchmarks such as CIS. These checks cover: OS hardening Network and firewall configuration SSH and remote access settings Logging and auditing Kernel parameters and system services Each finding includes a description and the actual configuration state—making it easy to understand and act on. 🌐 Hybrid Cloud Coverage The baseline works across: Azure virtual machines Arc-enabled servers (on-premises or other clouds) This means you can apply a consistent compliance standard across your entire Linux estate—whether it’s in Azure, on-prem, or multi-cloud. 🧠 Powered by Azure OSConfig The audit engine is built on the open-source Azure OSConfig framework, which performs Linux-native checks with minimal performance impact. OSConfig is modular, transparent, and optimized for scale—giving you confidence in the accuracy of audit results. 📊 Enterprise-Scale Reporting Audit results are surfaced in: Azure Policy compliance dashboard Azure Resource Graph Explorer Microsoft Defender for Cloud (Recommendations view) You can query, export, and visualize compliance data across thousands of machines—making it easy to track progress and share insights with stakeholders. 💰 Cost There’s no premium SKU or license required to use the audit capabilities with charges only applying to the Azure Arc managed workloads hosted on-premises or other CSP environments—making it easy to adopt across your environment. How to Get Started Review the Quickstart Guide 📘 Quickstart: Audit Azure Security Baseline for Linux Assign the Built-In Policy Search for “Linux machines should meet requirements for the Azure compute security baseline” in Azure Policy and assign it to your desired scope. Monitor Compliance Use Azure Policy and Resource Graph to track audit results and identify non-compliant machines. Plan Remediation While this release does not include auto-remediation, the detailed audit findings make it easy to plan manual or scripted fixes. Final Thoughts This GA release marks a major step forward in securing Linux workloads at scale. With enhanced audit now available, enterprise teams can: Improve visibility into Linux security posture Align with industry benchmarks Streamline compliance reporting Reduce risk across cloud and hybrid environmentsDesigning for Certainty: How Azure Capacity Reservations Safeguard Mission‑Critical Workloads
Why capacity reservations matter now Cloud isn’t running out of metal, but demand is compounding and often spikes. Resource strain shows up in specific regions, zones, and VM SKUs, especially for popular CPU families, memory-optimized sizes, and anything involving GPUs. Seasonal events (retail peaks), regulatory cutovers, emergency response, and bursty AI pipelines can trigger sudden surges. Even with healthy regional capacity, a single zone or a specific SKU can be tight. Capacity reservations acknowledge this reality and make it designable instead of probabilistic. Root reality: Capacity is finite at the SKU-in-zone granularity, and demand arrives in waves. Risk profile: The risk is not “no capacity in the cloud,” but “no capacity for this exact size in this exact place at this exact moment.” Strategic move: Reserve what matters, where it matters, before you need it. What capacity means in practice Think of three dimensions: region, zone, and SKU. Your workload’s SLO ties to all three. Region: The biggest pool of resources. It gives you flexibility but doesn’t guarantee availability in a specific zone. Zone: This is where fault isolation happens and where you’ll often feel the pinch first when demand spikes. SKU: The specific type of machine you’re asking for. This is usually the tightest constraint, especially for popular sizes like Dv5, Ev5, or anything with GPUs. Azure Capacity Reservations let you lock capacity for a specific VM size at the regional or zonal scope and then place VMs/scale sets into that reservation. Pay‑as‑you‑go vs capacity reservations vs reserved instances Attribute Pay‑as‑you‑go Capacity Reservations Reserved Instances Primary purpose Flexibility, no commitment Guarantee availability for a VM size Reduce price for steady usage What it guarantees Nothing beyond current availability Capacity in region/zone for N of a SKU Discount on matching usage (1‑ or 3‑year term) Scope Region/zone at runtime, best‑effort Bound to region or specific zone Billing benefit across scope rules Commitment None Active while you keep it (on‑demand) Term commitment (1 or 3 years) Key clarifications Capacity reservations ≠ discount tool: They exist to secure availability. You pay while the reservation is active (even if idle) because Azure is holding that capacity for you. Reserved Instances ≠ capacity guarantee: They reduce the rate you pay when you run matching VMs, but they don’t hold hardware for you. Together: Use Capacity Reservations to ensure the VMs can run; use Reserved Instances to lower the cost of the runtime those VMs consume. This is universal, not just Azure Every major cloud faces the same physics: finite hardware, localized spikes, SKU-specific constraints, and growth in high-demand families (especially GPUs). AWS offers On‑Demand Capacity Reservations; Google Cloud offers zonal reservations. The names differ; the pattern and the need are the same. If your architecture depends on “must run here, as this size, and right now,” you either design for capacity or accept availability risk. When mission‑critical means “reserve it” If failure to acquire capacity breaks your SLO, treat capacity as a dependency to engineer, not a variable to assume. High-stakes cutovers and events: Examples: Black Friday, tax deadlines, trading close, clinical batch windows. Action: Pre‑reserve the exact SKU in the exact zones for the surge window. HA across zones: Goal: Survive a zone failure by scaling in active zones. Action: Consider keeping extra capacity in each zone based on your failover plan, whether that’s N+1 or matching peak load, depending on active/active vs. active/passive. Change windows that deallocate/recreate: Risk: If a VM is deallocated during maintenance, it might not get the same placement when restarted. Action: Associate VMs/VMSS with a capacity reservation group before deallocation. Fixed‑SKU dependencies: Signal: Performance needs, licensing rules, or hardware accelerators that lock you into a specific VM family. Action: Reserve by SKU. If possible, define fallback SKUs and split reservations across them. Regulated or latency‑sensitive workloads: Constraint: Must run in a specific zone or region due to compliance or latency. Action: Prefer zonal reservations to control both locality and availability. How reserved instances complement capacity reservations Two-layer strategy: Layer 1: Availability: Capacity reservations ensure your compute can be placed when needed. Layer 2: Economics: Reserved Instances (or Savings Plans) apply a pricing benefit to the steady‑state hours you actually run. Practical pairing: Steady base load: Cover with 1/3‑year Reserved Instances for maximum savings. Critical surge headroom: Hold with Capacity Reservations; if the surge is predictable, you can still layer partial RI coverage aligned to expected utilization. Dynamic burst: Leave as pay‑as‑you‑go or use short‑lived reservations during known windows. FinOps hygiene: Coverage ratios: Track RI coverage and capacity reservation utilization separately. Rightsizing: Align reservations to the SKU mix you truly run; shift or cancel idle capacity reservations quickly. Chargeback: Attribute the cost of “insurance” (capacity) to the workloads that require the SLO, separate from the cost of “fuel” (compute hours). Conclusion In today’s cloud landscape, resilience isn’t just redundancy; it’s about assured access to the exact resources your workload demands. Capacity Reservations remove uncertainty by guaranteeing placement, while Reserved Instances drive cost efficiency for predictable use. Together, they form a strategic duo that keeps mission‑critical services running smoothly under any demand surge. Build with both in mind, and you turn capacity from a risk into a controlled asset.🚨 Azure Service Health Built-In Policy (Preview) – Now Available!
Resiliency is a key focus for Microsoft in making sure our customers experience minimal impact due to planned or unexpected outages that may occur. Up until now there has been no native scalable solution to provide consistent notifications across Azure subscriptions for Service Health events. Building on the success of Azure Monitor Baseline Alerts (AMBA) where this functionality is currently available, the AMBA team has combined with the Service Health Product team to include this capability into the Azure native experience. We’re excited to announce the release of Azure Service Health Built-In Policy (Preview), a new built-in Azure Policy designed to simplify and scale the deployment of Service Health alerts across your Azure environment. This policy enables customers to automatically deploy Service Health alerts across subscriptions, ensuring consistent visibility into platform-level issues that may impact workloads. Existing subscriptions can be remediated in bulk and new Azure subscriptions, created once the Policy has been assigned, will automatically be configured for receiving Service Health alerts. 🔍 What's the purpose of this announcement? It addresses situations where customers only permit the use of built-in policies. It automates the setup of Service Health alerts across all subscriptions when deployed at the management group level. It ensures consistent alert coverage for platform events. It helps reduce manual setup and ongoing maintenance. 🛠️ What options are available with the Policy? All the learnings from AMBA have been taken into consideration in designing and creating this policy. There are now a wide range of options available to provide flexibility based on your needs. These options are surfaced as parameters within the policy: It audits the existing environment for compliance. It ensures the ability to provide custom alert rules that align with the naming standards. It gives the ability to choose the types of Service Health events to monitor. It supports Bring-your-own Action Group, or the ability to create a new Action Group as part of the Policy assignment. For ARM role notification, it ensures the ability to choose from a pre-set list of built-in roles for notifications. It provides the ability to choose from email, Logic App, Event Hubs, webhook, and Azure Functions within the Action Group. It enables naming Resource groups, and location flexibility. It gives the ability to add Resource tags. 🧩 What about Azure Monitor Baseline Alerts? The AMBA team have been working to incorporate the newly built-in policy into a future release. The team plans to roll this out in the next few weeks along with details for existing customers on replacing the existing AMBA custom policy. These changes will then be consumed into Azure Landing Zones. AMBA continues to offer a wide range of alerts for both platform and workload services in addition to Service Health alerts. This announcement does not serve as a replacement for AMBA but simply compliments the AMBA solution. 📣 What’s Next? Check out the guidance on leveraging this policy in your environment Deploy Service Health alert rules at scale using Azure Policy - Azure Service Health Should you require support for this policy please raise a support ticket via the portal as comments raised below may not be addressed in a timely mannerEverything New in Azure Governance @ Build 2025
You've come to the right place if you're looking for everything happening with Azure Governance at Microsoft Build, May 19-22, 2025. Azure Governance is an ecosystem of neatly integrated services that provide the ability to ensure speed and control across your cloud environment. From enforcing rules in your cloud environment to querying the state of your resources at-scale, Azure Governance services keep your resources secure and compliant with corporate standards. Join us at Microsoft Build! #MSBuild Session: "Unlock developer agility with a well governed environment" - Thurs, May 22 @ 8:30 AM PDT In a world where app and env requirements are ever changing, maintaining control can be a moving target. Come learn how to empower your developers to achieve more, without compromising on security, compliance, or operational best practices through Azure Governance products. In this session we'll be discussing newly released features within Azure Policy, dive deep into Policy as code, and announce a new grouping construct called Service groups designed to optimize cross subscription management Join the session here: https://aka.ms/AzGovBuild25 Sign up for our #MSBuild Product Roundtable Sessions! Are you going to attend Build 2025 in person in Seattle? If the answer is Yes, Azure product teams would like to invite you to the following Customer Feedback Roundtable sessions at Microsoft Build 2025. Sign up here to join our roundtable sessions: https://aka.ms/AzGovRoundtable. This is a unique opportunity for you to share your insights and help shape the future of Azure. These roundtables will be filled on a first come, first serve basis, so don't miss your chance to sign up now! If you are not attending Build in person, no problem! If you are interested, we would like to invite you to participate in future online feedback sessions. New Releases @ Build 2025 The Azure Governance team is excited to share all the following new features across our product portfolio. For each of the features, you will find an accompanying announcement with scenario details, documentation and blog posts to follow along! Jump to section (New!) Azure Service Groups Azure Policy Azure Machine Configuration Azure Resource Graph (ARG) Azure Resource Manager (ARM) (New!) Azure Service Groups Azure Service Groups - Public Preview A Service Group (SG) is a new grouping structure in Azure that supports flexible grouping of cross-subscription resources and multiple hierarchies of groups. Service Groups provide a unified view and management capabilities, enabling: Low Privilege Management: Service Groups are designed to operate with minimal permissions, ensuring that users can manage resources without needing excessive access rights and appealing to multiple personas. Flexible Cross-Subscription Grouping: Azure resources and scopes, from anywhere in the tenant, can become members of one or multiple service groups. Varying Hierarchies: Service Groups can be self-nested providing the ability to have multiple hierarchy structures of resource containers. Data Aggregation & Views: Aggregate data from resources across subscriptions for practical workloads. View application health (via Health Model) and important data values centered around your wanted perspective. You can reach our team by email at mailto:azureservicegroups@microsoft.com for any questions or comments! TechCommunity Blog: https://aka.ms/servicegroupspreview MS Learn Documentation: http://aka.ms/servicegroups Azure Policy New Features currently in Private Preview Many of the Azure Policy enhancements, including user-based exemptions, caller-type based enforcement (e.g., type user or service principal) and IP filtering are currently in private preview and will soon be available to the public. Stay tuned! Azure Machine Configuration Linux SSH Posture Control Policy - Generally Available We are excited to announce additional built-in capabilities for Linux management scenarios through Azure policy and Machine Configuration. Through new built-in policies, you can manage your SSH configuration settings declaratively at-scale. SSH Posture Control enables you to use the familiar workflows of Azure Policy and Machine Configuration to: Ensure compliance with standards in your industry or organization Reduce attack surface of remote management features Ensure consistent setup across your fleet for security and productivity SSH Posture Control also provides detailed Reasons describing how compliance or non-compliance was determined. These Reasons help you to document compliance for auditors with confidence and evidence. They also enable you to take action when non-compliance is observed. MS Learn Documentation: What is SSH Posture Control? | Microsoft Learn Windows Server 2025 Audit Policy (powered by OSConfig) - Generally Available You can now deploy the Windows Server 2025 security baseline to your environment and ensures that desired security measures are in place, providing a comprehensive and standardized security framework. The Windows Server 2025 baseline includes over 300 security settings to ensure that it meets industry-standard security requirements. It also provides co-management support for both on-premises and Azure Arc-connected devices. The OSConfig tool is a security configuration stack that uses a scenario-based approach to deliver and apply the desired security measures for your environment. MS Learn documentation: Configure security baselines for Windows Server 2025 | Microsoft Learn Onboarding Arc Machines at-scale to Machine Config in Azure Portal - Public Preview With the integration of Machine Configuration audit policies in the Arc at-scale onboarding experience, you can now quickly deploy audit policies to get a deeper look at the security posture of your Arc-enabled servers. Whether you're seeking to test Machine Configuration on an Arc machine or looking to deploy a policy across a broader scope of machines, your deployment workflow just got incredibly easy with this new integration. Azure Resource Graph (ARG) ARG GET/LIST API - Private Preview Now in Private Preview is the Azure Resource Graph GET/LIST API, a highly scalable, fast, and performant alternative to existing control plane GET and List API calls within the Azure ecosystem. This API allows you to mitigate issues related to throttling, such as performance degradation and failed requests offering a 10X higher Read throttling quota to callers, ensuring faster and more efficient read operations for your critical cloud native workload. Contact argpms@microsoft.com to join the private preview program! Azure Resource Graph Copilot – Generally Available With the release of the Azure Resource Graph (ARG) skill within Copilot, customers can access the ARG query skill through Azure Portal or Github Copilot. Questions about resource governance like “how many Linux VMs do I own” will be sent to the ARG Skill. With this release, customers can easily turn natural language questions into ARG queries. ARG Copilot helps users create queries to quickly surface insights about resources and simplify operational investigations. MS Learn documentation: https://learn.microsoft.com/azure/copilot/get-information-resource-graph Azure Resource Manager (ARM) EU Data Boundary enabled by ARM - Generally Available Going beyond Azure's existing data storage commitments, you can now store and process EU Data in the EU by leveraging Azure data boundaries enabled by Azure Resource Manager. With Azure Resource Manager, you can ensure that in-scope, global Azure metadata data, including EUII, EUPI, Customer Content, and Support Data, are routed, processed, and stored entirely within EU data boundary countries and datacenter locations. This builds on Azure's existing regional metadata privacy commitments and helps our European customers achieve greater control over data locality to meet regulatory, compliance, and sovereignty requirements. MS Learn Documentation: What is the EU Data Boundary? - Microsoft Privacy | Microsoft Learn Stay Updated Keep in touch with Azure Governance products, announcements, and key scenarios. Bookmark the Azure Governance Tech Community Blog, then follow us @AzureGovernance on X (previously known as Twitter) Share Product feedback/ideas with us here- Azure Governance · Community For questions, you can reach us at: Azure Policy: policypm@microsoft.com Azure Resource Graph: argpms@microsoft.com[Public Preview] Dynamically organize your cloud resources with Azure Service Groups!
[Public Preview] Dynamically organize your cloud resources with Azure Service Groups! With Service Groups, you can now leverage flexible cross-subscription grouping, low privilege management, nested resource hierarchies, and data aggregation for practical workloads and application monitoring.
Why Even Stateless AKS Clusters Might Need Backup
When we talk about backup solutions for Kubernetes clusters, the need is usually most obvious in the context of stateful workloads those managing persistent data like databases, file systems, or applications with long lived storage. For such workloads, backups are non-negotiable, acting as the safety net for data recovery, disaster protection, and business continuity. But what about stateless AKS clusters? At first glance, stateless workloads seem like perfect candidates to not back up. After all, by design: They don’t rely on persistent volumes or databases Their deployments can be recreated from container images, Helm charts, or Git repositories The infrastructure is defined declaratively using infrastructure-as-code (IaC) or GitOps pipelines CI/CD systems can tear down and recreate entire environments on demand In such idealized environments, backup appears redundant. Any failure or disaster can be handled by simply re-running the pipeline or restoring manifests from Git. If everything is version-controlled, reproducible, and ephemeral, why invest in backup infrastructure and introduce the complexity and cost of a backup solution? This line of thinking is valid in theory. In fully mature DevOps setups with no manual drift, strict Git hygiene, no compliance overhead, and zero state stored in-cluster, the cost and complexity of backups might outweigh their limited benefits. The answer lies in real world operational gaps, compliance requirements, and reliability expectations that engineering teams encounter, even in seemingly “stateless” environments. In this article, we'll explore the key scenarios where backing up stateless AKS clusters adds value, even in cloud native, DevOps driven organizations. When Stateless Doesn't Mean Disposable In organizations with well-established DevOps practices, GitOps and infrastructure as code pipelines manage everything declaratively. The entire cluster state from workloads to configurations is reproducible from Git. In such environments, backup may seem redundant. However, not every team is operating at peak DevOps maturity. Even in mature teams, gaps and exceptions exist. Let’s look at situations where backup for stateless clusters becomes essential. It’s important to note that most Kubernetes backup solutions, including Azure Backup for AKS, capture the desired state by backing up YAML manifests, Custom Resources, and selected cluster metadata while typically opting out of backing up the full etcd store, which is Kubernetes’ actual source of truth. As a result, a restore usually reflects what was intended to run, not necessarily what was actually running at the moment of failure. This distinction underscores the importance of regular, automated backups to bridge the gap between configuration intent and operational reality. 1. Absence or Inconsistency in GitOps Practices While GitOps aims to be the single source of truth, reality often diverges from this ideal: Manual changes are introduced in the heat of production incidents. Drift occurs between the declared and actual cluster state. Some components are not version controlled (e.g., in cluster secrets, ad hoc cron jobs, Helm releases with local values). Consider this as an example: A retail engineering team hot-fixed a frontend deployment by patching environment variables directly in the cluster during a Black Friday outage. They never committed the changes to Git, and after the dust settled, the service stopped working during redeployment. The backup captured the exact deployment spec from that moment—environment variables included—allowing the team to restore the working state without guesswork. In such cases, a backup acts as a point in time capture of the actual cluster state, allowing teams to recover or audit what truly ran in the environment not just what was intended as per the Git repositories. 2. Compliance and Regulatory Requirements Industries with strict governance—such as finance, healthcare, and government—often require: Auditability of production configurations Retention of infrastructure state for post mortem or regulatory reviews Proof of controls around cluster state Even for stateless workloads, backups can satisfy these compliance demands, especially when you need to demonstrate that critical workloads and configurations can be recovered exactly as they were. Consider this as an example: A fintech company undergoing a routine audit had to produce a record of its production deployments from the previous quarter. Their GitOps pipeline had undergone changes, and some manifests were overwritten. Fortunately, they were able to generate historical records from AKS backup snapshots, satisfying audit requirements and avoiding potential penalties. 3. Forensic Analysis and Post Incident Review When investigating a production outage or security incident, engineers often need to understand: What was deployed? What configmaps or secrets were present? Were any unusual workloads running? Consider this as an example: After a failed release, a security team launched an investigation and discovered that a crypto-mining container had been injected as a sidecar. It wasn’t in source control, and log retention had expired. A namespace-level backup taken a few hours before the incident provided a complete snapshot, enabling them to analyze the rogue container’s configuration and timeline. Backups offer a forensic lens into the cluster state at a specific point in time. This is invaluable for root cause analysis and may reveal insights that are no longer visible due to pod churn or log retention limits. 4. Accelerated Recovery and Operational Simplicity Even stateless applications can take time to recover in the event of: Cluster level failures Region outages Misconfigured redeployments In contrast to rehydrating from scratch, restoring a cluster or a namespace from a backup snapshot can significantly reduce RTO (Recovery Time Objective) especially for complex environments with multiple microservices, RBAC settings, custom resources, and interdependencies. Consider this as an example: An e-commerce platform hosted in a single AKS cluster experienced a regional outage. Though all apps were stateless and versioned in Git, restoring the entire namespace from a recent backup complete with network policies, secrets, and service bindings allowed them to relaunch in a new region within minutes, far faster than a redeployment pipeline alone would have allowed. 5. Preserving the Actual Source of Truth In many organizations, Git is not always the full source of truth: Onboarding of legacy applications with partial IaC coverage Teams using Helm or Kustomize without consistent repo structures Clusters with long lived manual tweaks In these cases, the cluster itself becomes the de facto source of truth. A backup ensures you can retain and reproduce what worked even if the corresponding manifests don’t exist (or are outdated). Consider this as an example: A SaaS provider relied on Helm charts with custom values set locally by different teams. During a platform upgrade, they lost track of multiple override configurations not committed to Git. The backup captured the running state, including those local Helm values, allowing for an exact rollback and informing future IaC improvements. Conclusion Stateless does not mean disposable and certainly not irrelevant in backup planning. While there are cases where backup for stateless AKS clusters can be safely skipped, many real-world environments face drift, compliance demands, or operational complexity that make backups not just helpful, but necessary. If your organization isn’t yet at peak GitOps hygiene or operates in regulated industries then backing up even your stateless workloads is a wise investment. Not because they hold data, but because they hold context and context is critical for resilience, auditability, and operational excellence. To get started with protecting both stateless and stateful workloads, explore Azure Backup for AKS and see how it fits into your Kubernetes resilience strategy.SSH Posture Control for Linux is now GA!
With the increasing importance of reducing the attack surface of any fleet of devices, SSH Posture Control provides a comprehensive solution to ensure your servers are configured according to best practices and your environment specific requirements. This results in enhanced security, improved compliance, and increased efficiency throughout your IT infrastructure. This feature not only audits your current SSH server settings but also can auto-remediate configurations to enhance your security posture. Key Features: Comprehensive Auditing: SSH Posture Control performs a thorough audit of your SSH server settings, and identifying potential misconfigurations. Automated Configuration: Save time and reduce errors with automated configuration options that align your SSH server settings with industry best practices. Support for Multiple Distros: Whether you're using Ubuntu, Red Hat, Azure Linux, or other supported distributions, SSH Posture Control has you covered. Azure Governance: SSH Posture Control integrates seamlessly with Azure Governance services such as Azure Policy and Machine Configuration. Each compliance check includes evidence via the Reasons field, indicating how compliance or non-compliance was determined. You can customize the SSH parameters or use the policy default values, which are aligned with the Azure security baseline for Linux Getting Started Ready to enhance your SSH server security? Take the first step towards a more secure and compliant server environment. For more information and detailed documentation click on the links below: https://aka.ms/SshPostureControlOverview https://aka.ms/SshPostureControlQuickstart https://aka.ms/SshPostureControlBrownfield SSH Posture Control | Not JUST Port 22 - YouTube
