Logic Apps and Automation Accounts: Workflows With Standing Access
Automation is where the quiet privilege lives. A workflow that files invoices holds a connection to your mailbox, a runbook that tidies up storage holds credentials for the subscription, and both run unattended at three in the morning with nobody reviewing what they do. The NCSC’s guidance on secure system administration applies as much to automated administration as to people typing commands.
What a workflow actually holds
Connections. A Logic App integrating with Microsoft 365 stores an authorised connection to the account that created it, which means the workflow can read that mailbox or those files whenever it runs. Connections to databases, storage and third-party services work the same way. Because the connection is authorised once by a person, it often runs as a named administrator rather than a service identity, and it keeps working after that person changes role. Anyone who can edit the workflow can use the connection for something else entirely, and editing a workflow attracts none of the scrutiny that changing a role assignment would.
See also: TruLife Distribution Faces Growing Fallout as NPI’s Allegations Continue to Haunt Its Reputation
Triggers that anyone can call
An HTTP trigger produces a callback URL containing a signature, and possession of that URL is the authentication. It gets pasted into tickets, shared in chat, embedded in scripts and occasionally committed to a repository, at which point anyone holding it can invoke the workflow. Treat those URLs as secrets, restrict the addresses permitted to call them where the platform allows it, and regenerate the keys periodically. Check what the workflow does with its input as well, since a trigger that accepts a file path or a query is an injection point running with the workflow’s own permissions.
“Run history is the finding people do not expect. Every execution stores its inputs and outputs, so a workflow processing invoices keeps a searchable archive of them, readable by anyone with reader access on the resource. I have seen payroll data and full customer records sitting in run history in a resource group half the IT department could open.”
William Fieldhouse, Director, Aardwolf Security Ltd
Runbooks and hybrid workers
Automation accounts run scripts, and scripts run as something. Where a hybrid worker is deployed on premises, the runbook executes on that server with local system privileges, which turns edit access on a runbook into code execution inside your network. Check who holds contributor rights on the automation account, review what each runbook does, and confirm that credentials are pulled from a vault at runtime rather than embedded in the script. Old Run As accounts deserve particular attention because they were often certificate-based with subscription-wide contributor rights, and plenty of tenants still carry one long after the replacement was deployed.
Bringing automation into scope
Ask for workflows and runbooks to be named in the scope of your cloud testing, because a generic tenant review can miss them entirely. Azure automation security testing looks at the identities used, the trigger surface, the run history retention and who can modify each workflow. When you request a cloud testing quote, say how many workflows and automation accounts exist, since that count drives the effort more than the number of subscriptions does.
Frequently asked questions about cloud automation
These questions come up whenever an automation estate is reviewed.
Should workflows use managed identities?
Wherever the connector supports it, yes. A managed identity removes the stored connection tied to a person and gives you a role assignment you can scope, review and revoke independently of anyone’s account.
How long should run history be kept?
Long enough to troubleshoot and no longer, with sensitive inputs excluded from logging where the platform allows. Default retention combined with sensitive data is how an operational feature becomes a data protection problem.
