Microsoft Azure, along with cloud platforms in general, provides developers with the tools necessary to build sophisticated development, deployment, and operations DevOps pipelines. However, teams often dive right into DevOps practices without understanding fundamental concepts. This not only minimizes the inherent benefits of Azure but often introduces new security issues.
Four key concepts that I’d recommend teams have a working knowledge of include:
- How to use Active Directory
- The difference between authorization models
- How to develop strategies for integrating security
- How to monitor security compliance
Azure Active Directory
Protecting resources typically begins with authentication and authorization. Azure Active Directory allows you to centrally create and manage multiple users and accounts by assigning each its own username and password, and optionally, a method of multi-factor authentication. Most importantly, Azure can use federated authentication to synchronize and access your Azure Active Directory accounts using credentials from your corporate directory.
Azure Role-Based Access Control (RBAC)
To control access to Azure resources, you create role assignments consisting of three elements:
- A security principal - an identity that corresponds to an Active Directory user, group, or service identity
- The role definition - list of operations allowed through that role.
- Scope of the assignment - defines which resources the role assignment applies to
You can create and manage role assignments in the Azure portal for each service using the Access Control (IAM) blade, through PowerShell, the Azure CLI, the REST API, or using a resource template.
Azure Active Directory also provides an advanced feature for access control beyond simple RBAC called Conditional Access. Using Conditional Access, the conditions -or signals- that must be met before granting access can be defined. For example, a condition can be created that requires multi-factor authentication for any developers performing privileged deployment tasks or completely blocking access to these tasks from untrusted networks. Some signals for conditional access are user or group membership; IP ranges or location; device platform or management state; client application; and real-time and calculated risk detection. Conditional Access policies are a valuable security tool, especially in complex DevOps environments.
Privileged Identity Management (PIM)
One of the key tenets of DevOps is developer involvement in all stages of the deployment workflow. However, it’s also a best practice to always provide a minimal set of privileges required for any role. Do not make every user an administrator. To allow developers access to privileged operations without granting too many permissions, Azure AD offers PIM. This service allows granting just-in-time or temporary privileged access to Azure resources based on start and end dates, manual approval before activation, and multi-factor authentication.
By limiting the time that a user has privileged access, damage of a compromised account can be mitigated, especially those accounts that have access to the application resources and deployment. Without using all features of PIM right away, it can still be used to monitor and review existing privileged access.
Azure Policy
One goal for integrating security into DevOps is to achieve continuous compliance along with continuous deployment. Azure Policy provides a framework for developing policies, ensuring compliance, and managing remediation. Using either built-in policy definitions or creating policy definitions, you can control resource allocations and configurations, enforce resource tagging, or configure resource monitoring.
Infrastructure as Code
To ensure a well-documented and repeatable Azure architecture, both the infrastructure and security configuration should be treated as any other code in the continuous integration/continuous delivery CI/CD pipeline.
Azure facilitates this through two key services
- Azure Resource Manager (ARM) templates - JSON files that contain all the parameters necessary to create and deploy a resource based on established security policies and standards. The definitions define not only the characteristics of the resource but also the access permissions. Furthermore, since an Azure Policy is a resource, it allows for managing security compliance at scale.
- Azure Blueprints - allow you to define an entire security-compliant environment that consists of resource groups, policies, role assignments, and Resource Manager templates. This allows, for example, for including all artifacts and resources to set up a testing or production environment for the application.
Pipeline Security Strategies
To inject security into the pipeline, focus on three main strategies:
- Identify where in each stage both automated and manual security testing can be performed
- Consider what secrets, such as encryption keys or service credentials, need protecting
- Ensure encryption of all data in transit and at rest
Identifying where to perform security testing largely depends on the type of product and how it’s built. For example, a web application may require both Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), Interactive Application Security Testing (IAST), and fuzzing. Each of these could be integrated into the pipeline via PowerShell or other shell scripts, Azure Functions, or a Security and Compliance Assessment task.
Securing Secrets
In the DevOps pipeline, there are a variety of secrets: API keys, encryption keys, certificates, or passwords to other services such as a database or another external account. The most common and secure way to centrally create and manage secrets is using Key Vaults. Key Vaults allows storing RSA keys, secrets, and certificates in a secure manner that allows controlling and monitoring the use of each. Management and use of keys can be authorized either through RBAC or Key Vault access policies.
Another way to manage secrets is through a Pipelines Library, where variable groups to store a set of key/value pairs for use in the pipeline can be defined, or secure files such as certificates and signing keys can be uploaded.
Key Vaults are typically the best choice for storing secrets, although creating a Pipelines Library can be useful for situations where it makes more sense for local management of secrets in the pipeline itself. Note that variables in variable groups can be linked directly to Key Vault values for use in the pipeline.
Azure Security Center
A solid DevSecOps pipeline must provide feedback to each of the development, security, and operations teams. Feedback and metrics require insights, which can be obtained through the Azure Security Center.
The Azure Security Center is a unified infrastructure security management service that provides advanced threat protection, monitoring, and remediation across cloud resources and workloads. It monitors cloud infrastructure to identify configurations that are not compliant to selected standards. It also provides an overview of the security posture and allows viewing of non-compliant resources along with any recommendations.
In addition to the built-in standards and recommendations, custom policies can be developed. To respond to evolving threats, Azure Security Center provides advanced protections and alerts based on Microsoft’s ongoing security research, telemetry, and threat intelligence. Through this threat intelligence, behavioral analysis, and anomaly detection, Azure Security Center will continuously monitor and alert emerging threats.
Azure Sentinel
Because DevOps largely depends on automation for success, it’s vital that the proper tools are set up for monitoring and alerting. Azure Sentinel is Microsoft’s cloud-native security information and event management (or SIEM) service. It collects and aggregates log and configuration data from both cloud and on-premises devices and applications. Using advanced analytics, you can detect, investigate, and respond to security events in real-time.
Integrating security into an Azure DevOps pipeline requires preparation and planning, but even a small commitment to security leveraging these best practices can lead to great improvements across the entire process.
About Ed Adams, CEO
Ed Adams is a software quality and security expert with over 20 years of experience in the field. He served as a member of the Security Innovation Board of Directors since 2002 and as CEO since 2003. Ed has held senior management positions at Rational Software, Lionbridge, Ipswitch, and MathSoft. He was also an engineer for the US Army and Foster-Miller earlier in his career.
Ed is a Ponemon Institute Research Fellow, Privacy by Design Ambassador by the Information & Privacy Commissioner of Canada, Forbes Technology Council Member, and recipient of multiple SC Magazine’s Reboot Leadership Awards. He sits on the board of Cyversity, a non-profit committed to advancing minorities in the field of cyber security, and is a BoSTEM Advisory Committee member.
