Looking at the Azure JIT VM Access Activity Log

Azure Just-in-time VM Access is a pretty cool feature, and in a previous post I discussed initial steps for onboarding the service.  In this post, I'd like to examine the auditing features of the service.

Currently, there is an activity log that you can review.  The activity log is nothing special, it is just the Azure activity log with the operation name of Microsoft.Security/locations/jitNetworkAccessPolicies/initiate/action.

You can view this pretty easily from the ASC itself by right clicking on the server in scope and requesting the activity log.  You can also see all the requests across all resources by using the AzureActivity solution in OMS, or by using the activity log tab in the Azure portal.

Upon request, I can see that 4 events are created in the Activity log.





Now, I'm assuming the order presented is probably incorrect, and this is due to the time resolution of the activity log.  This follows logically, since I don't think a write to the NSG could occur before I made the request :)

In any event, lets take a look at them in order:

The first event (starting from the bottom.... shoutout to my man Drake!) is the write to the network security group.  Key points here are the following:

- The resource under scope is actually the NSG that protects the target VM (this makes sense)
- The event is initiated from the Windows Azure Security Resource Provider.  This will probably lead to interesting RBAC control issues for this service ( think about NSGs used for IR and other types of activities)
-  Deep in the request body, you can see where the port is being opened for the requested IP.  The description around the rule itself is generic  "ASC JIT Network Access rule for policy 'default' of VM 'xxxx'.\"
- The rule name that is created has some identifiers on it, and looks like SecurityCenter-JITRule_-1xxx9_5xxxx2

The next event up is an initiate event on the VM itself.  Interesting.  Key points:

- Operation name
    "operationName": { 
    "value": "Microsoft.Security/locations/jitNetworkAccessPolicies/initiate/action",
    "localizedValue": "Microsoft.Security/locations/jitNetworkAccessPolicies/initiate/action"},

- There is a properties section that seems to contain all the information for the policy being applied.



Moving on up the stack, there is now a request which seems to contain very similar information to the previous request, but this one is targeted at the locations/westus/jitNetworkAccessPolicies/default resources (this must be the initial request to the ASC subsystem).

The one above that (the first one in the list) is a pretty blank request to the same resources.

Conclusion

In conclusion, there seems to be a few events that are generated as it relates to an access request.  This makes sense, and it follows that the user request is first handled by the security subsystem, then forwarded to the VM (this is probably how write permissions are checked) and lastly sent to edit/modify the NSG.

One thing that I found interesting while doing is that there doesn't seem to be an easy/logical way to track the NSG rule name created to a particular request.  I tried searching the activity log for the various components of the NSG rule name, and only found the write NSG activity log.  Of course the write NSG does not link itself to the request, so you start to lose the trail.  Will be interesting to investigate this further (which is code word for I probably did something wrong).