Enterprise-Scale
Enterprise-Scale copied to clipboard
Azure
Feature Request - Separate workspace for Microsoft Sentinel
Community Note
- Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
- Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
- If you are interested in working on this issue or have submitted a pull request, please leave a comment
Description
Describe the solution you'd like
In general we could say that it's recommended to separate performance/event (ops) logging from security logging by using separate Log Analytics workspaces. (Let's call them security & non-security logging from here) Main drivers are cost reduction, as Sentinel won't be processing non-security logging, and separation of duty as it's easier to separate access on workspace level.
What are your thoughts on separating the workspaces in the CAF module? Some additional benefits I see:
- Easier for demo environments to turn off non-security logging (my subscription recently got disabled because my AKS cluster was pushing several GBs per day into the workspace that caused the subscription to be disabled. This works the other way round as well: for a simple demo environment you might only want to collect non-security logs to see how your test app performs.
- On policy level we can separate the diagnostics logging per resource type.
Additional context
LA Workspace decision tree: https://docs.microsoft.com/en-us/azure/sentinel/design-your-workspace-architecture#decision-tree (we might also want to consider having a separate log analytics workspace per region)
As discussed offline @DevSecNinja, I have moved this issue to the Enterprise-Scale repository as such changes would require a review at the broader architectural level rather than that of an individual implementation option.
As you have correctly identified, the decision tree for designing your workspace architecture has some deviations from the current ALZ guidance which we will look into.
Thank you
Hi @DevSecNinja
We plan to refresh the Azure Monitor recommendations in the coming months. We have this on our backlog already.
Relating to your specific request, we will include this use case as part of the above feature. We have identified a number of dependencies, including the updated Azure Monitor Agent to support multi-homing.
In terms of implementation, we will have to perform some policy refactoring to allow for the separation of security and performance/event logging. We have a good idea of how to do this already. Note that we plan to only support multiple Azure Monitor Logs instances in the Bicep and Terraform implementations, the portal deployment will remain supporting only a single workspace.
Please bear with us whilst we get this planned out :)
Here for similar cost reduction reasons. The national security team happy to pick up our Microsoft Sentinel costs, but only if it's only security related. Thus, needing to split operational/metric data off to a separate Log Analytics workspace.
(And yes, AKS diagnostic settings logs are also killing us,)
