Securing Azure Machine Learning

Azure Machine Learning is a great resource to use for any machine learning needs. With this technology comes different attack vectors so it’s important to be aware of them.

Below are some considerations to run your eyes over, if you are looking to run AZML within your environment.

---

Opt for Private Networks

The first consideration is how you are going to use AZML. If you run an instance with the defaults, Azure will create multiple resources which it needs to function. It also creates the Workspace to be accessible from anywhere.

Having your AZML studio and compute on the internet will bring obvious risk, so if possible, look to use Private Endpoints.

Once the Private Endpoint is connected to the AZML workspace, you can start to use private compute. You will now be able to assign the compute to a VNET.

If you are wanting to go fully private, and the VNET has the correct route tables to allow Internet Access, you can choose to assign No Public IP.

Connectivity for linked data sources however will still go external unless you disable the Public Access under Networking:

Disable SSH

Although Microsoft try to secure the compute instances by default, you must remember that it’s still a host. If this is sitting within your network, you still need to treat it like you would any other Linux host.

Remember that even if this is option is disabled, AZML users can still connect via console to these boxes via the AZML Studio. This is an attack vector, as if compromised, the attacker could use this method to connect to a box sitting on your network.

MFA the Portal

MFA should be the minimum requirement for accessing the Azure Portal and via Azure Machine learning Studio. Ensuring that these methods of connectivity are running via a conditional access policy is critical.

Remember that by default, or even by accident, the Studio can be lifted to the internet. If this studio is, then attackers can do a lot of things, including those mentioned above.

This is why it’s important to secure the portals as well of the data sources and compute.

Manage Access

This furthers the points above. Because the Studio can be used to create compute, and execute automation commands, it’s important to enforce least privilege access.

If you have data scientists that only query the data, then they don’t need to be able to create new data sources/compute. This should be done by a trusted admin. The reason being is that if a user was to spin-up an instance or connect to an untrusted data source, it could put your data and environment at risk.

Once you’ve perfected the access, remember to review it on schedule. Assign ‘Owners’ of the AZML workspaces and hold them accountable for user access reviews.

System access is also a consideration as you need to decide how the resources are going to connect. Service principals can be used for data sources (Assets), however you may also want to secure the Storage account access. This is done via the creation process, and if enabled moves to an identity access model. This is something you will have to consider as the RBAC policies on that Storage account will need to match.

Restrict Internet Outbound Access

Now that we’ve secured the portal and compute creation, we need to make sure that those compute instances and data sources have defined restrictions.

Remember those compute can be consoled into, and execute multiple scripts. You don’t want someone installing multiple services, or dropping malicious files. Limiting the Internet access via a Firewall, will help dampen the risk of this.

It’s not all attack based. You have to remember that data extraction would also be possible, so again limiting access is key. If the compute has access to data, it can be used to funnel this out of your network.

Automate Compute Hardening

If for instance you want to put further security checks in place, you can look for automation. These compute instances will still adhere to Azure Policies, however if you are wanting to set automation scripts, you can. Perhaps you could use this to deploy your tools, or harden the OS.

Encryption

Now that we’ve considered the portal, studio, access and compute. We need to think about the data. Microsoft give you two options. Although most will just go with the Microsoft option, it’s something to consider. Some companies will opt to manage their own keys as it will put all the power into the companies hands, however the trade off is that Microsoft won’t be able to support should those keys be deleted.

You will obviously need to consider the data on the other side. For instance the data at rest and in transit from the data sources. How the AZML workspace connects and touches this data. Each data source needs to be reviewed.

This would be a good time to record those connection. As the network is the main security control, it’s good to review data sources being connected to workspaces. If the firewall is less restrictive, unexpected data sources may be connected, or sources that haven’t been secured.

Logging

The final consideration I’m going to mention is logging. This should follow your logging strategy and policy. If you don’t have one, review the below and log what matters.

Security should be the first consideration and application second. Although you want to be able to troubleshoot and run metrics, if your security team cannot track who created an instance, connect to a data source, made RBAC modifications, accessed data etc… then they are on the back foot should a security incident occur.

Remember that is Azure, logging is broken up and granular, so don’t just assume you have all you need. Run though these with a comb and make sure you are covered.

If you enjoyed reading my content and want to support, why not consider signing up and becoming a member. It’s $5 a month, for unlimited access to all stories on Medium. Join now! 🙂

You could also clap, should this provide some help!

Regardless, thanks for reading and take care! 🙂