Show user friendly message when Azure Policy does not meet compliance
We have created custom policy which checking tags existence when a user creates a new resource group. The policy works great. But we have faced unexpected behavior. When we tried to create a new resource group for test purposes (without tags) we had an uninformative error (Unexpected error while creating the resource group.). We think some people might have a misunderstanding about this message (From this message they won’t understand why they cannot create a new resource group). We investigated this issue but have not found trouble in the policy itself therefore right now we think it is an azure policy issue. Does somebody meet this kind of issue? Is there a workaround for the issue? The original feedback: https://feedback.azure.com/forums/915958-azure-governance/suggestions/36599173-show-user-friendly-message-when-azure-policy-does
Azure Policy – New Zealand Information Security Manual (NZISM) [Preview]
Whilst working with a number of organizations that needed to have compliance with https://www.nzism.gcsb.govt.nz (amongst other standards and regulations), it was a laborious path to have decent visibility against Azure resources and the NZISM compliance without customization or outside custom automation. The NZISM is measure from the https://www.protectivesecurity.govt.nz/ policy framework. The Azure Security Benchmark and ISO 27001 in https://portal.azure.com/#blade/Microsoft_Azure_Security/SecurityMenuBlade/22 supplied great general visibility towards standardized security compliance in general, but lacked the translation and mapping against NZISM requirements. The only other Azure Policy option available was to create a custom Azure Policy Set (Initiative) to map and show compliance. In-steps the new https://docs.microsoft.com/en-us/azure/governance/policy/samples/new-zealand-ism to save the day! With this being a built-in or out-of-the-box feature it means less overhead compared with the custom route. As with all things, each policy in the policy set should be reviewed prior to application to ensure it fits with expectations. The policy set should also not be used in isolation, i.e. it should be used in conjunction with other policies and features (such as the https://portal.azure.com/#blade/Microsoft_Azure_Expert/AdvisorMenuBlade/overview) to have a well rounded view. The policy set is also available on https://github.com/Azure/azure-policy/blob/master/built-in-policies/policySetDefinitions/Regulatory%20Compliance/nz_ism.json and open to contributions for any improvements or alignments needed towards the NZISM. Periodic reviews for compliance (of the policies themselves and their compliance against your resources) should also be in place as part of due diligence as always. There are a number of methods in which you can look to apply or deploy the policy set; https://docs.microsoft.com/en-us/azure/governance/policy/assign-policy-portal https://docs.microsoft.com/en-us/azure/governance/policy/assign-policy-azurecli (automation) https://docs.microsoft.com/en-us/azure/governance/policy/assign-policy-powershell (automation) https://docs.microsoft.com/en-us/azure/governance/policy/assign-policy-dotnet (automation) https://docs.microsoft.com/en-us/azure/governance/policy/assign-policy-javascript (automation) https://docs.microsoft.com/en-us/azure/governance/policy/assign-policy-python (automation) https://docs.microsoft.com/en-us/azure/governance/policy/assign-policy-rest-api (automation) https://docs.microsoft.com/en-us/azure/governance/policy/assign-policy-template (automation) https://docs.microsoft.com/en-us/azure/governance/policy/assign-policy-terraform (automation) All of the above automation tagged options you can pull into pipelines and automation vehicles (such as https://docs.microsoft.com/en-us/azure/devops/user-guide/services?view=azure-devops) to make life repeatable and easier. Even better is to include this in your Cloud Adoption Framework journey through https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/govern/policy-compliance/. The Policy can also be applied at various levels; Tenant Management Group(s) Subscription(s) Resource Group(s) All that aside, how does it look in the real world? The two options that I ran through were the Azure Portal and PowerShell (AzModule) to test the waters for the policy at a subscription level scope. This is with a view to move towards subscription or management group level ARM deployments via an Azure DevOps pipeline. The application of the policy was reasonably straight forwards. Taking all of the current defaulted values from the policy (post review of each policy) set as-is means the following policy parameters need to be defined when applying: "Allowed locations" listOfAllowedLocations-e56962a6-4747-49cd-b67b-bf8b01975c4c Value = ['australiaeast','australiasoutheast'] "Allowed locations for resource groups" listOfAllowedLocations-e765b5de-1225-4ba3-bd56-1ac6695af988 Value = ['australiaeast','australiasoutheast'] "Audit Windows machines missing any of specified members in the Administrators group" MembersToInclude-30f71ea1-ac77-4f26-9fc5-2d926bbd4ba7 Value = [] "Audit Windows machines that have the specified members in the Administrators group" MembersToExclude-69bf4abd-ca1e-4cf6-8b5a-762d42e61d4f Value = [] Note: If you wish to include the Australia Central regions, these will need to be added into the values above. By default this is limited overall to Australasian and global regions. With the NZISM policy applied to the subscription, it took the usual time for it to evaluate the resources and produce it's compliance statistics. The only defaulted blocking feature of the policyset is the regional resource group and resource creations. Anything outside of the allowed regions or Global will be denied after the policy is applied. All existing resource will be allowed to exist, but show as non-compliant. This can be adjusted by setting the default action of the Policy Enforcement from Enabled (default) to Disabled. There are also optional settings to have configurable non-complaint messages (to display when a policy that is denying is blocking), but the defaulted message and appearance has enough details for the resource blocking, but the resource group blocking looks to be slightly less friendly by default at the moment: Example of Policy in “Deny” effect for disallowed locations for resource creation Example of Policy in “Deny” effect for disallowed locations for resource group creations All in all it is great built-in feature that can be very useful for those needing to comply with NZISM now with a lower amount of effort upfront. Further details are below for the two method of application used. PowerShell Note: Prior authentication and setting context to the appropriate subscription required. ################################################################# ## Register the Azure Policy Insights resource provider [One off against subscription] Register-AzResourceProvider -ProviderNamespace 'Microsoft.PolicyInsights' ###################################################################### # Assign a Policy Set/Initiative $policySetName = "d1a462af-7e6d-4901-98ac-61570b4ed22a" # New Zealand Information Security Manual $policySetAssignmentDisplayName = "New Zealand Information Security Manual" $policySetDefinition = (Get-AzPolicySetDefinition -Name $policySetName) $context=(Get-AzContext) $location='Australia East' # Region for the Managed Identity used for remediation $logAnalyticsWorkspaceId='*ADD_LA_WORKSPACE_RESOURCEID_HERE*' # LA Workspace Resource ID $parameters = [ordered]@{'MembersToInclude-30f71ea1-ac77-4f26-9fc5-2d926bbd4ba7'=('');` 'MembersToExclude-69bf4abd-ca1e-4cf6-8b5a-762d42e61d4f'=('');` 'listOfAllowedLocations-e56962a6-4747-49cd-b67b-bf8b01975c4c'=('australiaeast','australiasoutheast');` 'listOfAllowedLocations-e765b5de-1225-4ba3-bd56-1ac6695af988'=('australiaeast','australiasoutheast');` 'logAnalyticsWorkspaceId-f47b5582-33ec-4c5c-87c0-b010a6b2e917'=(''+$logAnalyticsWorkspaceId+'')} # Assign to subscription scope New-AzPolicyAssignment ` -PolicySetDefinition $policySetDefinition ` -Name $policySetName ` -AssignIdentity ` -Scope ("/subscriptions/"+$context.Subscription.Id) ` -Location $location ` -DisplayName $policySetAssignmentDisplayName ` -PolicyParameterObject $parameters ` -EnforcementMode DoNotEnforce ###################################################################### # Allow Policy System Identity access to remediate against subscription $roleDef=(Get-AzRoleDefinition -Name 'Contributor') $policySetAssignment=(Get-AzPolicyAssignment -Name $policySetName) New-AzRoleAssignment -Scope ("/subscriptions/"+$context.Subscription.Id) -ObjectId $policySetAssignment.Identity.principalId -RoleDefinitionId $roleDef.Id ###################################################################### Azure Portal Initiative/Definition Set Browse to the Azure Policy Initiative/Definition Set for the NZISM built in policy: https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyMenuBlade/Definitions Definition ID: /providers/Microsoft.Authorization/policySetDefinitions/d1a462af-7e6d-4901-98ac-61570b4ed22a Go into the Policy by left-clicking on the policy name. Assign the policy to a scope by left-clicking the Assign button. Assign the scope as appropriate and required; Management group(s), Subscription(s), Resource Group(s). Basics Set the assignment Basics information, then left-click Next. Recommendation: Set the Policy enforcement as Disabled initial to review compliance prior to harder restrictions being put in place. Parameters Review and set all parameters for the assignment, then left-click next: Recommendation: Initially set policies to Audit (AuditIfNotExist) to review compliance prior to enforcement. Current values that should be set outside of the defaults are the following allowed locations policies: "Allowed locations" listOfAllowedLocations-e56962a6-4747-49cd-b67b-bf8b01975c4c "value": 'australiaeast','australiasoutheast' "Allowed locations for resource groups" listOfAllowedLocations-e765b5de-1225-4ba3-bd56-1ac6695af988 "value": 'australiaeast','australiasoutheast' Remediation Review and set the appropriate location for the compliance remediation managed identity to be created. Non-compliance messages Review and set either a default non-compliance message, or an individual non-compliance message per policy, then left-click next. Review + create Review the settings on the summary page and if no adjustments are required, left-click Create to set the assignment. After the creation completes, the policy will appear and start the evaluation process. This can take some time to complete. Once completed, the policy compliance can be reviewed to see what remediation is required or if appropriate, what exemptions (time based or permanent) can be approved and put in place. References Microsoft Doc’s References https://docs.microsoft.com/en-us/compliance/regulatory/offering-nz-cc-framework-nz https://docs.microsoft.com/en-us/azure/governance/policy/samples/new-zealand-ism Microsoft Github Initiative Reference https://github.com/Azure/azure-policy/blob/master/built-in-policies/policySetDefinitions/Regulatory%20Compliance/nz_ism.json NZISM https://www.nzism.gcsb.govt.nz/ Protective Security Requirements https://www.protectivesecurity.govt.nz/
Azure NSG insecure inbound/Outbound access rules
Hello all, my Azure subscription has security groups that allow unrestricted inbound or outbound access on port and protocol combinations. Allowing unrestricted inbound/ingress or outbound/egress access can increase opportunities for malicious activity such as hacking, loss of data, and brute-force attacks or Denial of Service (DoS) attacks. How can I configure the allowed ports by assigning a policy to my subscription. Is there a built-in policy for that?
