2

Edited for emphasis: This is a client-side console app, not a web app.

I have a C# console app which downloads files from Azure blob storage. The app will run unattended as a scheduled task so can't prompt a user to log in. I figured out how to use Azure Key Vault to store the connection string and I created a service principle for the app in Azure Active Directory. The app authenticates with AAD using a client id and client secret, and then gets the connection string from Key Vault. But this still leaves me needing to store the client id and client secret somewhere. Have I really gained anything, or have I just moved the problem, from 'how to protect the connection string?' to 'how to protect the client secret?'

Brendan Reynolds
  • 991
  • 2
  • 9
  • 19
  • There's a better way to authenticate to gain access to the secrets in the Key Vault : [Managed Identities](https://learn.microsoft.com/en-us/azure/key-vault/managed-identity) – StuartLC Mar 25 '20 at 14:39
  • Have you read [How to secure Azure client Id and Secret without using App Settings of App Service](https://stackoverflow.com/questions/44822092)? – mason Mar 25 '20 at 14:39
  • Key Vault is also used for API keys for third party services. So if you only have one connection string, and you're keeping your Azure client id and secret in this way, yes, there are minimal gains. But if you have a connection string, plus API keys into a few other web services, it helps you only need to secure the ONE id and secret. And again, that's *if* you keep the client id and secret that way. Follow other answers to properly handle those, as well, and things get even better. – Joel Coehoorn Mar 25 '20 at 14:41
  • @StuartLC Does that not require an App Service application? This is just a client-side console app. – Brendan Reynolds Mar 25 '20 at 14:52
  • @mason Same question, that answer talks about an App Service or Azure VM, can I do that from a client-side console app? – Brendan Reynolds Mar 25 '20 at 14:54
  • Not sure. I haven't worked with Key Vault personally (yet). – mason Mar 25 '20 at 15:06
  • Your question demonstrates two things (1) you are thinking clearly about security, and (2) you have discovered a fundamental fact of security: it's all about leveraging one kind of protection into another kind of protection. You might consider going one step further in this journey and write up a formal threat model of your system, so that you can apply this sort of clear thinking to other aspects of your system. – Eric Lippert Mar 25 '20 at 20:00
  • @EricLippert Thanks. I've modified the app so that the first time I run it, I pass the client secret as a parameter on the command line. The app checks for an incoming argument, and if one is present, saves it to the registry. When there is no incoming argument, the app reads the secret from the registry. I could encrypt the secret before storing it in the registry, but then I'd have to store the encryption key somewhere so I could decrypt it again. – Brendan Reynolds Mar 26 '20 at 10:13
  • That doesn't sound like a best practice. Wouldn't it be better to call CryptProtectData or similar Windows service to encrypt the data so that only the current user can decrypt it? Let windows manage the keys for you; it's good at that. https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.protecteddata?redirectedfrom=MSDN&view=netframework-4.8 – Eric Lippert Mar 26 '20 at 18:15
  • @EricLippert Thanks, I'll check that out. – Brendan Reynolds Mar 27 '20 at 16:02

1 Answers1

0

Approach:

You should create a managed identity for the app service itself and use the managed identity of the app service access the secrets and other confidential entities stored and managed in the key vault. More resources on how to create and integrate such managed identities are available on Azure documentation.

Benefits:

You no longer have to deal with app secrets such as app id's and client id's as this is now taken care of via Azure managed identities.

Raunak Jhawar
  • 1,541
  • 1
  • 12
  • 21
  • It's a client-side console app. There's no app service. – Brendan Reynolds Mar 26 '20 at 10:03
  • In such a case there is no real benefit of using key vault, the only upside which you way consider would entail you to add certificates to access the key vault and have this client-side console app authenticate itself to the vault using a private key which you maintain within the realm of this app ecosystem itself – Raunak Jhawar Mar 26 '20 at 10:12
  • "have this client-side console app authenticate itself to the vault using a private key which you maintain within the realm of this app ecosystem itself" I'm not clear how that differs from what I'm already doing? – Brendan Reynolds Mar 26 '20 at 10:57
  • In your context, you have an option to authenticate your console app with AD using certificates as an alternate measure. This will also allow you to access AZ resources. – Raunak Jhawar Mar 26 '20 at 11:27
  • Pls remember to mark the response as answered if this was useful. Keep's us motivated. – Raunak Jhawar Mar 26 '20 at 12:18
  • While I am grateful for your suggestions, which have given me avenues for further investigation, I don't feel I can in good conscience say that this was the answer to my question. I feel that Eric Lippert's comment above was as near to an answer as I've got, but I can't mark a comment as an answer. – Brendan Reynolds Mar 26 '20 at 12:36