Security Hardening

kenaflow is a software that has been designed and developed for use in the large customer environment. We call it "Enterprise ready".

For a "security hardening" it is essential that the rights of users and administrators are limited to the respective minimum, so that each person / role only has exactly the rights that are necessary for the execution of the function / role.

There are the following levels in kenaflow that must be considered for this:

  1. access to SharePoint
  2. access to workflow scripts / workflow configuration
  3. instance security

Access to SharePoint

For the execution of actions in SharePoint, the respective workflow must access SharePoint. This means that data is read and possibly written. Access to SharePoint must be configured accordingly.

There are two possibilities:

  1. an execution account for the kenaflow instance
  2. an access account for SharePoint.

Execution Account

An execution account can only be used with SharePoint On-Premises.

In this case the software kenaflow is executed in the context of a function user ("Service Account").

In SharePoint, this account receives exactly the access rights that are necessary to read and/or write data via the workflow.

The assignment of rights is carried out by the workflow developer or by a SharePoint administrator.

For example, if a workflow has to read a SharePoint list, it is NOT necessary that the execution account is allowed to read all lists of the SharePoint page.

The execution account is a Active Directory Domain user account with no special permissions.

For security hardening this account should be NO local administrator on the kenaflow server. But as it is used to run kenaflow as scheduled task it need the permission "Logon as a batch job" in the Windows Local Security Policy.

Access Account

It is also possible to specify an access account for a workflow. The software itself can then be executed on the kenaflow server with an account that has no rights in SharePoint.

The execution account is then an account with the appropriate rights in SharePoint.

This could be an Active Directory Domain account account for SharePoint On-Premises. Or an Azure Active Directory account that is registered in SharePoint Online.

In case of using an access account the kenaflow instance can run with an local machine account instead of an Active Directory Domain account.

Also an Windows Managed Account can be used. No user and no administrator will have the password for such an account.

"App Credentials" can also be used. This works both in SharePoint On-Premises and SharePoint Online. Read this: App ID & App Secret

The credentials for the access account are stored in the workflow configuration file _wfconfig.ps1. To encrypt the setting the command line switches --setusername or --appid are used. The credentials get strongly encrypted with an key that is specified in the global configuration encryptionPassphrase in section "AfterSetup". The global configuration itself is encrypted using a machine specific key that is only known to Windows OS. In theory every user with priviledge to access the kenaflow server could decrypt the global configuration. Therefore reverse engeneering of the kenaflow software is required besides the access to the server.

Access to Workflow Scripts / Workflow Configuration

Workflows in kenaflow consist of a series of PowerShell scripts. These are located in the file system.

Each workflow is located in a separate directory below the "Workflow Root" directory. Additional layers can be added below "Workflow Root", but they may only contain additional folders and not workflows themselves.

With Windows file system permissions, access to workflow scripts can be prevented for workflow developers. This can be used if workflow developers are logged on to the kenaflow server via RDP for workflow development.

Workflow developers can develop workflows on their own machines and then have them transferred to the productive kenaflow server via automated procedures - e.g. "Continuos Integration" - so that direct access to the server by the developer is not necessary. This is the recommended procedure in a "security hardening" scenario:

  1. Developers use their own machines for workflow development. They have their own kenaflow installation, Developer Edition. (See: Editions](/overview/editions))
  2. Developers use their own account for workflow execution in debug mode or runtime mode. The account must have appropriate permissions in the SharePoint development environment that is identical to the production environment (in terms of SharePoint artifacts like content types and column/field names).
  3. After development the developers checkin the code in a source control system like GIT.
  4. An automatic process in a continuos integration system like JENKINS registeres the code change and triggers a job that is allowed to copy the workflow code from the source control to the productive kenaflow instance.
  5. There the workflow is executed with the execution account of kenaflow that has the appropriate permissions in SharePoint production environment.

Instance Security

During setup of kenaflow the required execution account must be set to run kenaflow automatically as Windows scheduled task.

--installschedtask

Using the command line switch --securing the permissions of the execution account are set on the appropriate file system locations.

For details please read this article: System Changes

With command line switch --confighttp the HTTP(S) endpoints of kenaflow are configured.

With command line switch --updatenetsecurity the HTTP(S) endpoint security can be modified after the setup, e.g. if the execution account was changed.

Workflow developers on the kenaflow server must have read permissions on the kenaflow binaries folder BUT NO WRITE PERMISSIONS there!

Workflow developers on the kenaflow server must have read & write permissions on the kenaflow data folder. This can be a network share.

For security hardening it is recommanded to use dedicated development machines for developers instead of developing workflows on the production server.