Reminds me of an Azure Support ticket I submitted a few years ago when some developer clicked the "Fix this now" button in Application Insights, which then proceeded to double the scale of an already too-large App Service Plan. [1]
The Audit log showed the service identity of Application Insights, not the user that pressed the button! The cloud ops team changed the size back, and then the mysterious anonymous developer... changed it back. We had to have an "all hands" meeting to basically yell at the whole room to cut that out. Nobody fessed up, so we still don't know who it was.
The Azure Support tech argued with me vehemently that this was by design, that Azure purposefully obscures the identity of users in audit logs!!! He mumbled something about GDPR, which is nonsense, because we're on the opposite side of the planet from Europe.
At first I was absolutely flabbergasted that anyone even remotely associated with a security audit log design could be this stupid, but then something clicked for me and it all started making sense:
Entra Id logs are an evolution of Office 365 logs.
Microsoft developed Entra ID (original Azure Active Directory) initially for Microsoft 365, with the Azure Public Cloud platform a mere afterthought.They have a legitimate need to protect customer PII, hence the logs don't contain their customers' private information when this isn't strictly necessary. I.e.: Microsoft's subcontractors and outsourced support staff don't need and shouldn't see some of this information!
The problem was that they re-used the same code, the same architecture decisions, the same security tradeoffs for what are essentially 100% private systems. We need to see who on our payroll is monkeying around with our servers! There is NO expectation of privacy for staff! GDPR does NOT apply to non-European government departments! Etc...
To this day I still see gaps in their logging where some Microsoft dev just "oops" forgot to log the identity of the account triggering the action. The most frustrating one for me is that Deployments don't log the identity of the user. It's one of only three administrative APIs that they have!
[1] As an aside: The plan had a 3-year Reservation on it, which meant that we were now paying for the original plan and something twice the size and non-Reserved! This was something like 5x the original cost, with no warning and no obvious way to see from the Portal UI that you're changing away from a Reserved size.
> He mumbled something about GDPR, which is nonsense, because we're on the opposite side of the planet from Europe.
It was also nonsense because the GDPR is crystal clear about where PII may be used. Audit logs are one of those exceptions where the goal of identifying users simply permits storing usernames and associated attributes (certainly in the case of upgrading a paid plan).
This wasn't about the GDPR; you were being told to sod off.
> There is NO expectation of privacy for staff! GDPR does NOT apply to non-European government departments! Etc...
There is just... not for this. This is literally the case allowed by GDPR, only thing that GDPR requires is making sure those logs can only be accessed by people designated in organisation to parse it