Design and implement authentication and authorization methods
Authentication is the process of verifying a user or system's identity, while authorization determines what they are allowed to do. In Azure DevOps, the primary method for authentication is Azure Active Directory (Azure AD). This service manages user identities and can connect to on-premises directories. It provides a single sign-on experience, meaning a user logs in once to access multiple services. For automated processes like scripts or pipelines, service principals or managed identities are used instead of passwords. A service principal is a security identity created for an application, while a managed identity is an Azure AD identity automatically managed by Azure and assigned to an Azure resource, like a virtual machine, to securely access other Azure services.
Authorization is controlled through permissions and roles. In Azure DevOps, you assign users and groups to built-in security groups like Contributors or Readers, or you create custom groups with specific permissions. These permissions control access to areas like code repositories, build pipelines, or test plans. The principle of least privilege should guide these assignments, meaning users receive only the minimum permissions necessary to perform their job. For Azure resources themselves, Azure role-based access control (Azure RBAC) is used. You assign roles, such as Owner or Contributor, to users or groups at different scopes like a subscription, resource group, or individual resource to govern their management actions.
Automation tools like pipelines and scripts often need access to secrets such as passwords, connection strings, or API keys. Storing these values directly in code is a major security risk. Instead, you should use a dedicated secret management service. In Azure, the primary service for this is Azure Key Vault. It provides a secure, centralized store for secrets, certificates, and encryption keys. Access to Key Vault is controlled through its own access policies and integrates with Azure AD for authentication.
Within an Azure DevOps pipeline, you should never hardcode secrets. Instead, you link to secrets stored in Azure Key Vault using a dedicated task or service connection. The pipeline retrieves the secret at runtime and passes it to the task that needs it, like a deployment script, without exposing the value in logs. For secrets that are specific to the pipeline itself and not shared elsewhere, you can use Azure DevOps pipeline variables marked as secret. These variables are encrypted and hidden from logs, but they are scoped to the DevOps service and are less manageable for secrets needed across multiple applications or teams compared to Key Vault.
Automate security and compliance scanning
Security and compliance should be continuously verified, not just checked manually before a release. This means integrating automated scanning tools directly into the development and deployment pipeline. For code, you can use tools like SonarQube or Microsoft Security Code Analysis to scan for vulnerabilities and coding flaws as part of the build process. These tools analyze the source code and dependencies, failing the build if critical issues are found, which shifts security left to earlier in the development lifecycle.
For the infrastructure and deployed applications, you can use Microsoft Defender for Cloud. It continuously assesses Azure resources against security benchmarks and compliance standards. To automate responses, you can use its recommendations within Azure Policy. You create policy definitions that enforce rules, such as requiring all storage accounts to use encryption. When a policy is assigned, Azure automatically evaluates existing and new resources against it. Non-compliant resources can be flagged, denied creation, or even automatically remediated. This creates a cycle where infrastructure is constantly checked and enforced to meet security standards without manual intervention.
StudyCerts
StudyCerts