How Do You Detect Critical Configurations and Data Outflow?

Every Dataverse environment has doors to the outside. Most of them are intended: the connection to the ERP, a data export to DATEV, the mail service, an API query or the document storage. It gets critical with the doors that nobody has on their radar anymore. The good news: almost all of these routes leave traces in the solution export, and you can search for them systematically.

The inventory of outbound connections

HTTP actions in flows. The flow definitions are available in the solution export as JSON, and an HTTP action appears there with its full target address. A search across the Workflows folder returns the list of all endpoints that flows call. Someone should be able to attribute every address on it, especially those that do not look like your own company. The quickest way to get a searchable export is to unpack it with the pac CLI, as described in the overview of free analysis tools.

Connection references and custom connectors. They reveal which services are connected at all: standard connectors can be recognized by name, custom connectors bring their target address with them. A connector to a service the organization does not officially use is a finding worth following up, to see whether shadow IT or an old project is behind it.

Webhooks and service endpoints. The classic variant of outbound integration: platform events reported to an external address or a Service Bus. They appear as components of their own in the export. This is exactly where a look pays off, because these registrations often date from early project phases and keep silently sending data, even when nobody operates the target anymore.

Scripts with external calls. JavaScript web resources that call addresses outside your own environment can be found with a text search across the unpacked files. Unencrypted targets are a double finding. The same goes for JavaScript libraries that are loaded from a server at runtime. If such a library is compromised, that can lead to considerable problems.

What the export does not see

Honesty is part of the inventory: compiled plug-in code is not readable in the export. A plug-in can send data to any target without the export showing it. Only the registrations are visible, meaning on which events the code runs. For assemblies from an unclear source, only the source code or a conversation with the vendor helps. Also invisible: anything that works directly against the API from outside the solution.

Critical is a combination, not a single finding

An HTTP action is not a problem in itself. The combination is what makes it critical: an event on a table with sensitive data, an external target that nobody can attribute, and no documentation for it. That is why the check works best as a cross table: which outbound connection hangs on which table, and who confirms that it is intended? Which other configurations inside the environment allow more than intended is covered in security issues in Dynamics 365 solutions.

Setting up this list once takes a morning for a normal solution. Keeping it current costs almost nothing afterwards, because new outbound connections are rarely added. And in an emergency, a data protection request or an incident, this list is exactly the document you need immediately and can never create fast enough.