Security App Registrations

%3CLINGO-SUB%20id%3D%22lingo-sub-2108318%22%20slang%3D%22en-US%22%3ESecurity%20App%20Registrations%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2108318%22%20slang%3D%22en-US%22%3E%3CP%3EHello%2C%3C%2FP%3E%3CP%3EI%20am%20reaching%20to%20see%20what%20people%20are%20doing%20around%20security%20app%20registrations.%20We've%20been%20working%20with%20our%20Dev%20teams%2C%20and%20have%20come%20across%20this%20app%20registration%20that's%20highly%20secure.%20Our%20developers%20want%20to%20come%20in%20with%20the%20client%20credentials%20flow%20which%20require%20an%20App%20ID%20and%20a%20Secret%2C%20which%20would%20basically%20expose%20that%20data%20to%20anyone%20that%20has%20that%20information.%20I%20am%20wondering%20what%20people%20are%20currently%20doing%20in%20these%20instances.%20It%20seems%20to%20me%20once%20you%20set%20up%20an%20app%20registration%20the%20info%20is%20there%20for%20anyone%20to%20setup%20pretty%20much%20any%20OAuth%20flow%20against%20it%20given%20they%20have%20the%20right%20information...or%20maybe%20I%20am%20missing%20something.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-2108318%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EAzure%20Active%20Directory%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EIdentity%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3ESecurity%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2110094%22%20slang%3D%22en-US%22%3ERe%3A%20Security%20App%20Registrations%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2110094%22%20slang%3D%22en-US%22%3EThere%20is%20no%20way%20to%20integrate%20Service%20Principals%20with%20Conditional%20Access.%20You%20can%20monitor%20sign-ins%20however%20to%20make%20sure%20that%20the%20service%20principals%20aren't%20used%20from%20an%20unknown%20IP.%3CBR%20%2F%3ECheck%20this%20out%20for%20an%20example%3A%20%3CA%20href%3D%22https%3A%2F%2Fthecollective.eu%2Fblog%2Fmonitoring-service-principals-with-watchlists-in-azure-sentinel%2F%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fthecollective.eu%2Fblog%2Fmonitoring-service-principals-with-watchlists-in-azure-sentinel%2F%3C%2FA%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2108367%22%20slang%3D%22en-US%22%3ERe%3A%20Security%20App%20Registrations%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2108367%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F906140%22%20target%3D%22_blank%22%3E%40cpateman%3C%2FA%3E%26nbsp%3BThank%20you%20for%20your%20response%2C%20once%20you%20have%20the%20keyvault%20and%20secret%20stored%20within%2C%20how%20do%20you%20then%20secure%20the%20keyvault.%20As%20long%20as%20the%20developer%20has%20access%20to%20the%20keyvault%2C%20couldn't%20they%20programmatically%20get%20access%20to%20that%20from%20anywhere%3F%20is%20there%20a%20way%20to%20keep%20keyvault%20behind%20conditional%20access%20so%20that%20access%20is%20only%20accessible%20internally%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2108345%22%20slang%3D%22en-US%22%3ERe%3A%20Security%20App%20Registrations%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2108345%22%20slang%3D%22en-US%22%3E%3CP%3EHello%20%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F506573%22%20target%3D%22_blank%22%3E%40bglmarks%3C%2FA%3E%20%2C%3CBR%20%2F%3E%3CBR%20%2F%3EI%20am%20using%20this%20type%20of%20flow.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20think%20your%20concerns%20are%20controlled%20by%20permissions.%3C%2FP%3E%3CP%3EYou%20should%20have%20Active%20Directory%20permission%20on%20your%20Azure%20Portal%20users%20to%20restrict%20who%20can%20create%20the%20App%20Registrations.%3C%2FP%3E%3CP%3EThen%20once%20you%20have%20generated%20the%20App%20Registration%20plus%20the%20Client%20Secret%2C%20you%20need%20to%20secure%20these%20somewhere%20safe%20like%20encrypted%20database%20or%20better%20would%20be%20Azure%20Key%20Vault.%3C%2FP%3E%3CP%3EYou%20would%20then%20also%20want%20to%20limit%20what%20the%20Client%20can%20do%20to%20make%20sure%20it%20cannot%20create%20or%20destroy%20everything.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EFor%20example%2C%20only%20the%20Admin%20in%20our%20AD%20can%20create%20the%20App%20Reg%2C%20so%20I%20can't%20create%20them.%20The%20Service%20Principle%20only%20has%20read%20access%20to%20a%20certain%20Subscription.%20The%20details%20are%20then%20saved%20securely%20for%20use%2C%20so%20we%20cannot%20read%20them%20while%20using%20in%20the%20code.%3C%2FP%3E%3C%2FLINGO-BODY%3E
New Contributor

Hello,

I am reaching to see what people are doing around security app registrations. We've been working with our Dev teams, and have come across this app registration that's highly secure. Our developers want to come in with the client credentials flow which require an App ID and a Secret, which would basically expose that data to anyone that has that information. I am wondering what people are currently doing in these instances. It seems to me once you set up an app registration the info is there for anyone to setup pretty much any OAuth flow against it given they have the right information...or maybe I am missing something.

3 Replies

Hello @bglmarks ,

I am using this type of flow.

 

I think your concerns are controlled by permissions.

You should have Active Directory permission on your Azure Portal users to restrict who can create the App Registrations.

Then once you have generated the App Registration plus the Client Secret, you need to secure these somewhere safe like encrypted database or better would be Azure Key Vault.

You would then also want to limit what the Client can do to make sure it cannot create or destroy everything.

 

For example, only the Admin in our AD can create the App Reg, so I can't create them. The Service Principle only has read access to a certain Subscription. The details are then saved securely for use, so we cannot read them while using in the code.

@cpateman Thank you for your response, once you have the keyvault and secret stored within, how do you then secure the keyvault. As long as the developer has access to the keyvault, couldn't they programmatically get access to that from anywhere? is there a way to keep keyvault behind conditional access so that access is only accessible internally?

There is no way to integrate Service Principals with Conditional Access. You can monitor sign-ins however to make sure that the service principals aren't used from an unknown IP.
Check this out for an example: https://thecollective.eu/blog/monitoring-service-principals-with-watchlists-in-azure-sentinel/