Best Approach To Security in Azure DevOps
Based on research when a bare computer is exposed to the internet without protection or firewalls, there are malicious scanners that will have access within a minute and in another 2 mins, more hackers and 4 minutes, you are under a malware attack so you must have security intuition. In personal intuition, engineers/experts must consider the following:
- Denial by default
- Least privilege
- Segmentation
- Encryption (data, network traffic and the rest)
- Logging
Azure has a Security centre that helps to evaluate security standards for application architecture. Look out for the dashboard and we must check for security policy for looking out for our architecture. Azure Security Center is the beating heart of security in Azure. Any security-related information you want to find is likely to be contained in some part of the security centre, even if it is not contained in the dashboard.
Many security options are turned on by default, so if you leave a virtual machine running for some time, you’ll certainly see alerts crop up. Additionally, you can check resource compliance with policies in the Azure Security Centre, and list tasks that need to be completed to increase compliance. Although as DevOps engineers, we won’t spend much time in Azure Security Center, it’s prudent for us to know where alerts, policy failures, and other security information is surfaced.
These pieces of information are also contained in the CLI, but since it lends itself well to being displayed graphically, we suggest using the portal unless you are writing security automation. As always, you should feel free to play around yourself — the Azure CLI help messages will guide you.
Security With Azure Policies
Azure Policies are as important as the cloud platform itself and very relevant in DevOps. It is not just a security tool but to enforce organization structure and compliance. It can be used to manage costs, ensure security best practices and reduce the scope of the search when things go wrong and help in default and custom policies. In DevOps, Azure Policies are vital for the providing technical security and consistency in enforcing industry and business standards then ultimately compliance. Let’s have a look.
As a DevOps expert, some key points to not let go are shown thus:
- They give us a way to manage costs by restricting specific resources.
- Because of the policy-enabled secure architecture, we can determine the scope, source, and solution of problems more quickly.
- Through policy-enabled configuration management, unexpected or even unwanted configuration changes can be prevented.
Custom Policy Definitions
Azure policies are written in JSON (JS Object Notation) and can be deployed in the portal or the CLI. Policies have two modes:
- Indexed: This evaluates only resource types that support tags and locations.
- All: This evaluates resource groups, subscriptions, and all resource types.
However, the rules themselves follow a simple if-then structure, where if the conditions in the policy rule are met, the effect specified in the “then” block occurs.
If you are interested in knowing more on policy definition then I suggest you look at the documentation here.
Network Security Groups
Network Security Groups (NSGs) are a collection of networking rules that dictate the flow of traffic to and from resources in Azure. When you create NSGs, there are numerous customization you can make and some of them are:
- Name
- Priority: Ranges from 100–4096
- Source or Destination: You can consider an individual IP or CIDR
- Protocol: All the networking protocols
- Direction: Tells us whether the rule applies to the traffic into the network
- Port Range: 3000–30010
- Allow or Deny Action = Allow
Azure Security Best Practices
After a few years using Azure DevOps, I have come up with a comprehensive list of best practices while considering security. Some of them include:
- Treat Identity as security perimeter (like for verification and access. You must centralize Identity management).
- Don’t have two references to an identity.
- Enable single sign-on so users can use the same credentials to resources so you can easily control things.
- There must be strong network controls to connect VM across networks and control the traffic for the VMs.
- Segment subnets must be controlled logically while resources belong to the strongest security zone.
- Allocate more network space than you need when setting up the infrastructure.
- Don’t assign NSG rules with broad ranges and be particular with who has access to what in the system.
- Finally, I’d say explore the goodies of the Azure security centre.
We’ve talked about a handful of key best practices here. If you’d like to dig deeper, Microsoft provides additional Best Practices in the Azure documentation.
Disclaimer: Everything written are purely born out of my experiences over the years.
Now, remember, this article is not only for experts in the software space, even newbies could hop in and learn a lot and that is why I try to make everything clear both in layman and professional terms, so if you have any questions, shoot or you can also reach out to me on Twitter or find me on GitHub.
Thanks for reading ❤️
Please leave a comment if you have any thoughts about the topic — I am open to learning and knowledge explorations.
