Security Guidelines

The security recommendations for the administrator of AVEVA™ Gateway Data Publisher are as follows:

• Use the principle of least privilege

  • For the users of AVEVA™ Gateway Data Publisher: Grant Read/Write access to the folders (staging areas) that you have configured for watching by the AVEVA™ Gateway Data Publisher instances. Grant Read/Write access fo the AVEVA™ Gateway Data Publisher logs folder.

  • For the users of AVEVA Gateways: Change the access to Read/Write only to the specific files and folders the gateway needs to modify. For example, you can grant Read/Write access to the Staging Area folders. Grant ReadOnly access to the AVEVA™ Gateway Data Publisher logs folder.

  • For AVEVA™ Ingestion Service: Grant Read/Write access to target folder (Asset Id) for the specific CONNECT account user.

• Please ensure that the system does not have any specific rules implemented for blocking AVEVA™ Gateway Data Publisher from connecting to AVEVA™ Ingestion Service.

  Note: If the above security recommendations are not suitable for your environment, you must investigate what is the most suitable approach for your environment and apply those practices.

When you run AVEVA™ Gateway Data Publisher as a Windows service for the first time, the service is started using the Local Service account. For enhanced security, it is recommended to switch to a dedicated service account that has required access privileges. To do this, open the Services window, and edit the Log On properties of the service.

Some security related settings can be managed using the following file (it becomes available after the first run of GDP):

%LOCALAPPDATA%\Gdp\Aveva.Gdp.Instance.appsettings.overrides.json

User with administrator rights can configure following settings:

• Startup/WorkspaceDirectories: Defines which root directories are treated as trusted workspaces by the application. Example values:

  • %AVEVA_P_DRIVE%

  • C:\Gateways

  • D:\Gateways

• Enqueuer/AllowFileFilters: Defines a whitelist of allowed file patterns that can be queued/processed ( for example: **/*.csv, **/*.json, **/*.xml, **/*.dwg, **/*.ifc, and so on.)

Security goals of manipulating those settings are:

• Limit processing to approved storage locations

• Limit processing to approved file types only

• Reduce risk of accidental or malicious ingestion of unexpected files

Security guidelines for workspace directories:

• Only configure trusted locations

  • Use folders managed by your organization

  • Avoid personal, temporary, or download directories

• Restrict write access

  • Only authorized users/services should be able to write into workspace roots

  • Remove broad permissions such as Everyone: Modify

• Avoid broad roots

  • Do not configure high-level paths like C:\ or D:\

  • Prefer dedicated folders such as C:\Gateways

• Use controlled network mappings

  • If %AVEVA_P_DRIVE% points to a network path, ensure it is access-controlled and monitored

  • Verify the environment variable resolves to the expected location on every machine

• Protect configuration changes

  • Treat changes to WorkspaceDirectories as security-relevant

  • Apply change control and approval before adding new workspace roots

Security guidelines for allowed file filters:

• Keep the allowlist minimal

  • Only keep file extensions required by business workflows

  • Remove unused types to reduce attack surface

• Never use permissive wildcard rules

  • Do not add patterns like **/*

  • Do not add broad catch-all patterns that permit unknown file types

• Validate business need before adding new file types

  • Each added extension increases risk and should be justified

  • Review parser/handler support before enabling new formats

• Consider high-risk document formats carefully

  • Office and document formats (for example .docx, .xlsx, .pptx, .pdf) may carry embedded content risks in downstream tooling

  • Enable only when strictly necessary

• Keep filter behavior predictable

  • Use explicit extensions and consistent pattern style (**/*.ext)

  • Avoid overlapping or ambiguous patterns