FTP accounts tied to subscription, not user. Not enough auditing
In the current model, FTP credentials are tied to a user's azure login. Thus, we have no visibility into credentials that are set, as we cannot see other people's FTP credentials they've set. Furthermore, when an FTP account is created or deleted, nothing is logged. This makes it difficult to audit who has access. With the logins being tied to the user, when the user leaves, there is no way for us to reclaim that username unless they delete their ftp credentials first. This doesn't always work, as a user may depart abruptly or not on good terms. Although the credential is disabled as soon as we remove access to the subscription, we still cannot claim it.
Hello and thank you for the feedback.
We recently rolled out a set of features for auditing and disabling FTP/WebDeploy access for your app services. Please see the blog post below for details.
Joshua Summers commented
There should be an ability to not only audit the user accounts that can deploy to a web app, but allow us to remove a deployment credential from a valid AAD user account without doing the following:
1) Delete the user from AAD and recreate them
2) Remove that user from all subscriptions or resources where you have web apps...permanently
Right now, to truly secure a subscription after a user has established a deployment credential, you have to rebuild the entire subscription. Imagine having N number of administrators and they all created their own credential...with a password that never expires or requires changing.
From a security perspective, this is a BIG deal and has implication on auditing for those familiar with PCI-DSS
Joshua Summers commented
The Publish profile for a web app does not respect the FTP credentials a user has associated to their account. This is another part of the auditing that should be rectified
Ahmed Sabbour commented
The deployment credential username is not tied to the subscription, but rather to the Microsoft Account. I can have access to multiple subscriptions and my deployment credentials would be the same across all of them, hence it is required to be unique across Azure.
When deploying using visual studio via WebDeploy of FTP deploy, these events are not registered in any log. This problem prevent us to generate an audit log for our clients to ensure that all website updates are performed by the approved personnel only.
This lack of information also prevent services implemented via website to comply to security standards where this kind of information is required.