The ScriptRunner security concept
With ScriptRunner you implement a security concept that is based on several zones with different security levels.
The inner system zone contains the central IT resources, e.g. Active Directory, Exchange Server, Office 365 etc. From the ScriptRunner perspective, the target systems are located in this zone. The required security level is highest here.
The second zone contains the ScriptRunner Server and the central script repository. The required security level is high. Only ScriptRunner admins can access this zone via ScriptRunner Portal for Administrators.
The user zone is the area where users and their resources are located. In the case of ScriptRunner, these are help desk and end users who use the ScriptRunner Portal and developers who work with the ISE add-on. The security level here is “normal”.
Communication may only take place across one zone boundary. Access from the user zone to the inner zone is not possible. This model allows national and international security standards to be implemented.
ScriptRunner secures the complete PowerShell lifecycle
ScriptRunner serves as a central repository for your PowerShell scripts and modules and thus ensures that they can be found quickly.
You can upload scripts from a directory or synchronize them from a branch of an external code management tool like Git, Gitlab or TFS. Modules are installed once on the ScriptRunner server and are then available for all further activities.
Centralization is an important step towards standardization: It ensures that the current version of the respective script is always used consistently for all tasks.
With the ScriptRunner ISE add-on, you can conveniently check scripts out and in for editing.
More about professional script development with ScriptRunner >
With ScriptRunner you can centrally store credentials required for script execution, which makes administration much easier, especially when using multiple ScriptRunner instances.
The main advantage, however, is that no credentials need to be stored within Powershell scripts, since the ScriptRunner server retrieves them from the password server at script runtime.
You can use the Windows Credential Store on the ScriptRunner server for this, or alternatively use password servers such as Cyber-Ark, Pleasant and Thycotic via the ScriptRunner password server connectors.
The ScriptRunner security concept ensures an effective separation of permissions and access: Help desk and self-service users of ScriptRunner Portal remain standard domain users without administrative access rights to the target systems. They simply give the command to the ScriptRunner Server to start an Action.
When an Action is called, ScriptRunner Server starts the corresponding PowerShell script as administrative proxy based on the stored policies. The script is then executed on the target system.
For each target system, one or more service accounts can be configured, thus enabling the implementation of managed service provider scenarios.
ScriptRunner ensures that PowerShell scripts can be executed and monitored in a centralized and secure environment.
Execution policies are the basis for this. A ScriptRunner admin uses them to define the conditions under which a script can be executed when creating an Action.
When an Action is called, ScriptRunner server checks that all policies are followed. Only if this is the case, the script in question is executed on the target system. The execution log and the results of each Action are logged centrally in the ScriptRunner Portal for Administrators.
ScriptRunner Actions can be delegated to Help Desk and end users, so they can launch them from the ScriptRunner Portal App.
The user selects an Action, fills in the required information (= script parameters) via the interface if necessary, and starts the Action. Execution policies, target systems, connectors, access rights, roles and settings are centrally managed in ScriptRunner Server.
The server now starts an isolated PowerShell process, according to the execution policy, with all necessary data and information and contacts the target system with the instruction to execute the script.
After the script is executed on the target system, the result data is sent back to the ScriptRunner server.
ScriptRunner Server now checks the result. If it is correct, it is forwarded to the Delegate/Self-Service App and the user is notified of the successful execution or error.
This allows ScriptRunner users to safely and easily execute PowerShell scripts even without PowerShell knowledge.