Edit

Share via

Azure Sandbox

Azure Bastion
Azure Database for MySQL
Azure SQL Database
SQL Server on Azure Virtual Machines
Azure Virtual Machines

Azure Sandbox is a collection of interdependent cloud computing configurations for implementing common Azure services on a single subscription. This collection provides a flexible and cost effective sandbox environment for experimenting with Azure services and capabilities.

Depending on your Azure offer type and region, a fully provisioned Azure Sandbox environment can be expensive to run. You can reduce costs by stopping or deallocating virtual machines (VMs) when not in use or by skipping optional configurations that you don't plan to use.

Architecture

Diagram that shows the Azure Sandbox environment.

Download a Visio file of this architecture.

Components

You can deploy each of the following sandbox configurations or only the ones that you need:

Deploy the sandbox

The Azure Sandbox environment requires the following prerequisites:

For more information about how to prepare for a sandbox deployment, see Prerequisites.

To integrate AzureSandbox with an Azure landing zone, consider the following strategies:

  • Place the sandbox subscription in the Sandboxes management group.
  • Keep the sandbox isolated from your private network.
  • Audit sandbox subscription activity.
  • Limit sandbox access, and remove access when it's no longer required.
  • Decommission sandboxes after an expiration period to control costs.
  • Create a budget on sandbox subscriptions to control costs.

For more information, see Landing zone sandbox environments.

To deploy Azure Sandbox, go to the AzureSandbox GitHub repository and begin with Getting started. For more information about how to deploy your sandbox environment, see Default Sandbox Deployment and known issues.

Use cases

A sandbox is ideal for accelerating Azure projects. After you deploy your sandbox environment, you can add services and capabilities. You can use the sandbox for activities like:

  • Self-learning
  • Hackathons
  • Testing
  • Development
  • Tabletop exercises
  • Red team/blue team simulations
  • Incident response drills

Important

Azure Sandbox isn't intended for production use. The deployment uses some best practices, but others intentionally aren't used in favor of simplicity and cost.

Capabilities

Foundational prerequisites can block experimentation with certain Azure services or capabilities. A sandbox environment can accelerate your project by provisioning many of the mundane core infrastructure components. You can focus on the services or capabilities that you need to work with.

For example, you can use the following capabilities and configurations that the Azure Sandbox environment provides.

  • Connect to a Windows jump box VM from the internet.

    • Option 1: Internet-facing access by using a web browser and Azure Bastion
    • Option 2: Point-to-site VPN connectivity through Virtual WAN

  • Use a preconfigured Active Directory Domain Services local domain as a domain administrator.

    • Preconfigured integrated DNS server
    • Preconfigured integration with Azure private DNS zones
    • Preconfigured integration with Azure Private Link private endpoints

  • Use an Azure Files preconfigured file share.

  • Use a Windows jumpbox VM as a developer workstation.

    • Domain joined to local domain
    • Administer Active Directory and DNS with preinstalled Windows Server Remote Server Administration Tools (RSAT)
    • Visual Studio Code preinstalled with Remote-SSH into a Linux jump box
    • Azure Storage Explorer, AzCopy, and Azure Data Studio preinstalled
    • SQL Server Management Studio preinstalled
    • MySQL Workbench preinstalled

  • Use a Linux jump box VM as a DevOps agent.

    • Domain joined to local domain using Winbind
    • Azure CLI, PowerShell, and Terraform preinstalled
    • Dynamic CIFS mount to Azure Files preconfigured file share

  • Use a preconfigured SQL Server VM.

    • Domain joined to local domain

  • Use a preconfigured SQL database or Azure Database for MySQL Flexible Server through private endpoints.

Security

Security provides assurances against deliberate attacks and the abuse of your valuable data and systems. For more information, see Design review checklist for Security.

Important

Sandbox environments represent an attack surface that can be exploited. To reduce risk, consider the following security best practices.

  • Implement strong authentication in the Microsoft Entra ID tenant associated with Azure subscriptions used to provision sandbox environments. Follow the recommendations in SE:05 - Recommendations for identity and access management.

    • Use multifactor authentication (MFA) for all users.
    • Use Conditional Access policies to restrict access to sandbox environments.
    • Use integrated Microsoft Entra authentication to authorize access to Azure platform as a service (PaaS) services like SQL Database and Azure Storage.

  • Start with a least privilege approach to authorize sandbox use.

    • Limit Owner Azure RBAC role assignments to sandbox subscription owners.
    • Limit Contributor Azure RBAC role assignments to sandbox subscription users.
    • Use Microsoft Entra Privileged Identity Management (PIM) to manage privileged Azure RBAC role assignments scoped to sandbox subscriptions, such as Owner, Contributor, and User Access Administrator.

  • Maintain your data classification compliance. For example, avoid hosting personally identifiable information (PII) or other sensitive data in a sandbox environment. If you must use sensitive data, use synthetic data or de-identified data.

Also, consider the Secure Futures Initiative principles when you're designing and implementing sandbox environments. The AzureSandbox implementation on GitHub showcases many of these principles.

Secure by design

  • Limit the use of shared secrets and use Azure Key Vault to secure them when required. When you have to use shared secrets, use managed identities at run time to retrieve from Key Vault. If secrets must be persisted, ensure that they're encrypted and not stored in plain text. Never echo secrets to the console or to log files, and never check secrets into source control.

  • Set an expiration date for Key Vault secrets.

  • When you select a guest operating system (OS) for VMs, only use OSs that are currently supported and eligible to receive security updates.

Secure by default

  • Use encryption as recommended by SE:07 - Recommendations for data encryption.
    • Ensure that cryptographic protocols and algorithms, such as TLS 1.2 or higher and SHA-256 or higher, are up to date.
    • Consider using host encryption or Azure Disk Encryption for encryption of data in transit. For managed disks attached to VMs, data is encrypted at rest by default.
  • Avoid the use of public IP addresses. Use Azure Bastion for secure remote access to VMs.
  • Use private endpoints to communicate with Azure services.
  • Disable public network access to Azure services like Storage and SQL Database.
  • Disable default outbound access and use Azure Firewall threat intelligence-based filtering.

Secure operations

Contributors

This article is maintained by Microsoft. It was originally written by the following contributor.

Principal author:

To see non-public LinkedIn profiles, sign in to LinkedIn.

Next steps