Azure ‘Just in time’ VM access

When I first saw “’Just in time…(JIT)” as a new preview announcement for Azure VMs, my mind was cast back to one of my first roles in IT, working for an automotive firm who supplied parts for car manufacturers. JIT was (or is!) a supply chain strategy whereby the parts or products arrive at a specific point only when required. Although I wasn’t directly involved, it used to fill me with dread as some of the penalties for holding up the supply chain were eye watering Smile with tongue out Anyway, I digress…

In relation to the Azure announcement, JIT is a security process currently in preview in Azure, whereby access is granted to a virtual machine only when required. It is simple in it’s architecture, in that it uses ACLs/NSGs to lock down access to specific inbound ports until a request by an authorised user is made. This drastically reduces the attack surface of your virtual and reduces any potential attacks through basic port scanning and brute force.

Licensing wise, JIT is part of the standard tier of Azure Security. Azure Security Center comes in two tiers:

  1. Free tier – this is enabled by default on your subscription and provides access to key security recommendations to help protect your infrastructure
  2. Standard Tier – extends the cloud and on-premises capabilities of Azure Security Center. Additional features are noted below:
    • Hybrid Security
    • Advanced Threat Detection
    • JIT VM access
    • Adaptive application controls

The following link provides pricing details: https://docs.microsoft.com/en-us/azure/security-center/security-center-pricing (Note: the standard tier is free for the first 60 days to allow you to evaluate the components!)

Over the next few weeks I’ll aim to create blog posts for each of these areas to provide a rounded picture of what the standard security tier can provide for your organisation.

The preview of JIT can be found within the Azure Security Center pane, on the home page as seen in the below screenshot. As it is a preview you need to activate it:

image

An overview of some of the alert types and an activation link can be found on the next page:

image

If you click through the following page you will receive information around pricing and have the ability to “on-board” into the standard tier:

image

Once you click through, you need to apply the plan to your resources, select upgrade and then save the applicable settings:

image

If you navigate back to Security Center homepage – you will now see all of the new features activated within your subscription:

image

Enabling JIT is very simple. Click within the JIT context in the screenshot above, and you’ll be presented with the JIT pane. From within here, click the “Recommended” option, and you should see any VMs you have in your subscription not currently enabled for JIT:

image

From here simply click on the VM on the left hand side, review the current state/severity and then click “Enable JIT on x VMs”… A pane will appear recommending key ports that should be locked down. It is important to note from here you can add any additional ports, and also specific key things like source IPs that will be allowed access upon request, and the duration for which access will be granted.

image

image

Following this your VM will now go into a “resolved state” and you will be able to head back to the main JIT screen, navigate to the “configured” tab, and hit request access…

image

The request access screen will allow you to permit access to specific ports from either “MyIP” (which will detect the current IP you are accessing from) or a specific IP range. You can also specific a time frame, up to the maximum limit configured in an earlier step.

Note: the ability to request access will depend upon your user role and any configured RBAC settings in the Resource Group or Virtual Machine.

image

In summary? I think JIT is a great feature and another measure of the investment Microsoft are making in security on the Azure platform. It is a feature I will be talking about with clients and in conjunction with the other features of Security Center I think it is an investment many organisations will look to make.

Advertisements

Visibility and increasing your Azure Subscription limits and quotas

Azure contains a number of default subscription limits that should be considered as part of any Azure design phase. Majority of these limits are soft and you can raise a support case to have them raised. To avoid delays to any project I always recommend this is one of the first areas of consultation as there can be a lag between the request and it being actioned. The limitations are there for a number of reasons, primarily to help Microsoft control and capacity plan the environment whilst also ensuring usage is limited to protect the platform.

There is a very handy  view in the Azure Portal from which you can view by going to the new, preview “Cost Management + Billing” blade. From here go to “Subscriptions” and click the subscription you would like to view. From here you get some great statistics, e.g. spending rate, credit remaining, forecast, etc. all of which holds great value to assist you in planning and controlling your cost. If you navigate to “Usage and quotas” under the “Settings” menu you will see the following view:

image

There are other ways to view your usage quotas via PowerShell, however these are individual commands per resource. It wouldn’t take much to create a quick script that you can run regularly to expose this however the above view deals with it nicely I think. One of the example commands include “Get-AzureRmVmUsage –location <location>”

image

The bottom part of the page shows your current usage against your limits. It is now also very easy to “Request an Increase” – if you click this link you will be taken through a guided wizard to increase your limits.

image

Bear in mind this is resource and type specific, e.g. you will be asked to demonstrate the model you are using (Classic/ARM) , the impact on your business so they can set a priority, the location you need a request in and also the SKU family.

image

The final screen asks you to supply contact details and who should be notified throughout the ticket.

image

.. and there you go! – limits raised. Evidently this can take some time and it asks you to be pretty specific about what you are requesting therefore I highly recommend you take time to plan your deployments correctly to avoid any frustration.

Servicing in a Cloud World

To kick things off on this rather derelict looking blog ;-), I wanted to start with a topic that I’ve been discussing with several customers recently, namely ‘Servicing in a Cloud World’. Why? Because it’s super important and requires a step change in the way IT organisations react to change, and communicate/engage this with their end-users.

Widespread adoption of Cloud technologies is almost old news now, organisations have been, and are currently, actively migrating services to a variety of cloud models. This includes anything from IaaS to PaaS to SaaS and they are therefore handing responsibilities over to the provider on a sliding scale. The most extreme end of this scale is any SaaS based solution as the provider not only manages/administers the solution for you, but also owns the roadmap which includes both feature additions and deprecations.

The following diagram taken from the “Change Management for Office 365 clients” guide by Microsoft, illustrates the difference between a traditional release model vs a servicing release model:

clip_image001

In a traditional release model with infrastructure/platform or services managed and administered by the organisation, typically releases happen after several months of planning, developing and testing. The actual “release” is then usually governed through change/release management processes which would generally involve some form of impact assessment as well as a mechanism by which to alert the target user base that the release is coming. This may then be supported by engagement through training / user guides, etc.

clip_image002

In a servicing release model where the infrastructure/platform or service is managed and administered by the provider, releases typically happen much faster and much more aggressively. This is due to the provider being incentivised (generally through a PAYG subscription approach) to be innovative on the platform to retain or attract new custom. As illustrated in the figure, this means the each stage of the lifecycle of the release is generally much smaller. This model is advantageous for organisations as it means they can leverage capability much sooner rather than having to invest in the planning/development and testing themselves. A well-understood benefit of Cloud, right?!

Onto the point of this post; organisations typically have well-defined and robust change and release management processes grown through many years of managing and delivering services out to their userbase (as discussed earlier in reference to the traditional release model). They are experts at managing changes and releases that are under their own control. However, it is crucial that organisations adapt these processes in reaction to the “servicing world”. These include gaining a full understanding of the providers roadmap in the following areas:

  • Minor / Major Changes
  • Feature additions
  • Feature modifications
  • Feature deprecations
  • New product releases (in the same portfolio)
  • Servicing (which can include downtime)
  • Maintenance

As noted earlier, these releases are typically much more frequent than previous, and will require roles and responsibilities across the IT org to adapt – making sure that they not only focus on the actual release but to understand how this will impact end users as well, who will likely require support as the frequency of change and adoption of new features/technologies will be unfamiliar.

To provide some support to this post, Office 365 Message Centre averages about 12-15 “notifications” per week (note, this changes frequently!) – anything from a new product, a feature change or a service announcement. Ultimately, as more services move to Cloud – the roles and responsibilities within IT need to adapt accordingly as IT professionals work to support their organisations operating in a cloud servicing world.