;)
Cloud design patterns are reshaping the way developers think. No longer can we sit back and let others set up and secure our apps. We need to understand cloud infrastructure and have knowledge around security to perform our job efficiently. For example, owning a microservice from concept to completion requires that you understand containers, orchestration, access, integrations, and more. This is now the expected role of the cloud software developer.
With this paradigm established let’s begin to understand how Azure has facilitated these activities.
- Infrastructure as Code (IaC)
- Security as Code (SaC)
These terms should make developers feel right at home. Automating processes is what we do and incorporating a bit DevOps and DevSecOps into our toolbelt can only help our companies and portfolios.
What are some of the ways Azure tackles these concepts?
- Code
- Tools
- VS Code
- https://shell.azure.com (PowerShell or Bash)
- PowerShell
- Azure CLI
- Azure Portal UI
Familiarize yourself with the above by installing the tools and running through the docs for each. Once complete you will have a base knowledge of automating infrastructure and security within Azure.
Azure Cloud Shell
Azure Web App Security for Developers
There are the typical security actions, such as the below list, that should be taken as a matter of habit by developers, but we want to go further by setting up an Azure environment that has resiliency, scales, is decomposed, durable, and keeps the weasels out.
- HTTPS
- Robust logging
- Pen Tests
- Disable remote debugging
- Data encryption
How do you start scoping resources to clearly delineate between environments such as DEV, TEST, and PROD? We will touch on subnet separation, but for our purposes let’s start with the RBAC.
Role-Based Access Control (RBAC)
RBACs allow us to scope subscriptions, resource groups, and individual resources to a certain role refining who can and cannot perform actions on the given Azure resource. There are three main roles (see below); however, there are over 50 built-in roles that will cover almost every scenario. You can also create your own roles if desired.
- Ownerhas full access to all resources including the right to delegate access to others.
- Contributorcan create and manage all types of Azure resources but can’t grant access to others.
- Readercan view existing Azure resources.
Architecting RBAC rules needs to be well thought as they can get complex quickly. Start by restricting your Resource Groups and work from there.
Typical RBAC Creation UI
RBACs are great for restricting portal resources access, but what if I need to have partners or other applications access resources within my subscription?
Shared Access Signatures (SAS)
Use SAS when you want to grant outside access to any of your Azure Storage Accounts. SAS URIs can be scoped to a single service item, such as a blob, or an entire storage account. When setting up your SAS you will need to specify the following:
- Start Time
- Expiry Time
- Permissions (Read, Write, Delete, Add, …)
- Optional
- IP Range
- Protocol (HTTPS)
There are other options as well, which you can discover on your own, but these are the main objects that make up a SAS. Another benefit to using SAS is that you never give out your storage Access Key, which is typically used by internal applications for authentication to the REST API for that storage account.
Typical Shared Access Signature Generation Account Level UI
Network Security Group (NSG)
NSG’s contain a list of allow/deny inbound/outbound security rules that can be applied to the following Azure components:
- Virtual Network (VNet)
- Subnet (Plan your subnets to segregate your various environments such as DEV, UAT, QA, and PROD)
- Virtual Machine (VM)
- Network Interface (NIC)
NSG placement must be well thought as every resource below an NSG is subject to its list of associated rules. The below image shows a drill down from ‘myVNet’ to ‘myVM’ where we will attach the ‘myNetworkSecurityGroup’ NSG.
NSGs are made up of typical properties such as Name, Region Location, Resource Group, and Rules (see below). Inbound and outbound rules consist of the following parameters:
- Priority – This sets the order of rule execution low to high
- Port – Specify the rule port
- Protocol – Matching protocol for the rule
- Source – IP or Default Tag for the rule
- Destination – IP or Default Tag for the rule
- Action – Allow or Deny
Notice below we finish by locking down everything. If none of the previous rules are hit then the ‘DenyAllInbound’ will catch any nonsense that got through our rules.
Azure Subnet Segregation
Now that we understand a few of the components around securing Azure resources, let’s look at best practice usage. The below diagram depicts a typical Azure N-Tier setup. Note the subnet segregation of web, business, and data. You can apply these same principles to DEV, TEST, and PROD environments securing subnet access via NSG. Now you can clearly delineate who receives access to each environment. I’m a developer and I have control. That’s refreshing.
There are MANY other setup and security features for developers within Azure; however, with knowledge around RBAC, SAS, NSGs, and Subnets Azure developers can confidently secure their work and keep the bad guys out.
Credits and further research on Azure Security components for developers
