• Blog
  • Webinars
  • Partner
  • Support
  • Contact
ScriptRunner
  • About us
    • Team
    • Jobs
    • Press
  • Why
  • Use Cases
  • Software
    • ScriptRunner Server
    • ScriptRunner Portal
    • ScriptRunner Portal Widget
    • ScriptRunner Connectors
    • ScriptRunner ActionPacks
  • Try Now
  • Search
  • Menu Menu
You are here: Home1 / ScriptRunner Blog2 / PowerShell & Systems3 / Secure communication with ScriptRunner – the shell model

Secure communication with ScriptRunner – the shell model

Author: Frank Kresse | Reading time: 3 minutes | Category: PowerShell & Systems, Security

Secure communication with ScriptRunner

This article has been translated automatically.

ScriptRunner is the central hub for PowerShell and communicates with its users, the target systems as well as with third party systems. Several aspects are important for communication:

  • the underlying safety concept
  • the communication protocols used
  • The communication partners involved

In this blog article you get to know the shell model and learn which security concept ScriptRunner is based on and how the communication relationships of ScriptRunner look like in a typical customer environment.

  • Shell by shell – the shell model as a security concept
  • The communication partners

Shell by shell – the shell model as a security concept

Before we deal in detail with the individual communication protocols and partners, it is worth taking a look at the basic security concept, which ScriptRunner depicts. The starting point is a shell model. In contrast to conventional views of network sections, firewalls and VPNs, the shell model offers the advantage of defining security levels and thus zones independently of the concrete infrastructure.

ScriptRunner security zones: The innermost shell is the

The shell model: ScriptRunner security zones

Three security levels are defined in the figure:

  1. The first, inner zone accommodates the central IT resources, e.g. Active Directory, Exchange Server, etc. From ScriptRunner’s point of view, the target systems are located in this zone. The necessary security level is highest here.
  2. A second zone contains the ScriptRunner host and central PowerShell code management. The necessary security level is high.
  3. The user zone is the area in which the users and their resources are located. In the case of ScriptRunner these are Service Desk users and administrators who use the browser apps and DevOps who work with the PowerShell ISE Add-on. The security level here would be “normal.”

The core principle in this model is that communication between two partners may only take place across a shell boundary. Access from the user zone to the inner zone is not permitted.

This means that communication can only take place between actors in neighboring shells.

This results in the following permitted communication relationships:

  • An administrator or service desk employee uses the browser app to start a PowerShell action in ScriptRunner.
  • An external system can start an action for automation only via a connector in ScriptRunner. The call by the source system would be assigned to the user zone.
  • Only the ScriptRunner host is allowed to run PowerShell scripts on the target systems.

As a consequence, there are significant advantages for the entire IT security because only this model enables an effective separation of rights and access. A service desk employee only has access to the actions assigned to him with his user account. Only the ScriptRunner host has the necessary rights to execute the script of the action on the target system. The user is completely decoupled from this and therefore requires no knowledge of the administrative rights for the target systems. The same applies to calling systems such as monitoring, ITSM and workflows.

The concept of security shells can be extended by further shells, e.g. for administrative access via the Internet or from Internet-based monitoring or ITSM systems to ScriptRunner.

The communication partners

In a typical customer environment, different actors are involved in the communication with ScriptRunner. The communication partners are distributed over the three levels mentioned above:

  1. Client in the user zone
  2. ScriptRunner host in the ScriptRunner zone
  3. Target systems in the system zone
ScriptRunner Kommunikation

The ScriptRunner Communication Relationships

1st Client in the User Zone

At this level, users as well as various third party systems call functions in ScriptRunner:

  • The ScriptRunner Admin and Delegate App user interfaces are browser-based. Authorized users can administrate ScriptRunner as well as start ScriptRunner Actions.
  • You can use the PowerShell ISE to execute commands and write PowerShell scripts. The ScriptRunner ISE Add-on allows DevOps to directly access the script repository on the host.
  • This level also includes the third-party web service clients (monitoring, ITSM, workflows) and the ScriptRunner mailbox for the email inbound connector.

2. ScriptRunner Host in the ScriptRunner Zone

At the ScriptRunner level two central components of ScriptRunner are shown:

  • The Internet Information Server (IIS) from Microsoft serves as the web server for the web apps, but other web servers can also be used. The functionality serves exclusively to deliver the JavaScript and HTML files of the Web Apps to the calling browser.
  • The core of ScriptRunner, the ScriptRunner Host is the central instance for all activities around PowerShell. It controls and monitors all central functions for automating, executing, monitoring, managing, and developing PowerShell scripts. Installed on a Windows server, it also monitors licenses, access rights, and host configuration.

At the execution level, there are typically the various target systems on which PowerShell scripts are to be executed in a controlled manner, for example:

  • Hyper-V and Windows Server
  • Windows clients
  • exchange server
  • VMWare, Citrix or others
  • Office365 Services
  • Azure Services

From ScriptRunner’s point of view, there are optionally two further systems on this level:

    • SQL Server for the reporting/auditing database for long-term storage
    • Mail Server for sending reports

The communication flow

The following example shall illustrate the entire process. A user starts the Delegate App and performs an Action in his role context.

The web browser contacts the IIS to call up the Delegate App and requests the website content.

The IIS web server returns the requested content in HTML, JavaScript and CSS format to the browser. Communication takes place via the standardized transmission protocols HTTP and HTTPS, usually via port 80 (HTTP) and port 443 (HTTPS).

The JavaScript application then starts in the browser and contacts the ScriptRunner host via the web service interface. The client uses the web service protocol ODATA/REST on the standard port 8091 for this purpose. If the authentication was successful, the data is loaded into the application. The Delegate App displays the tiles assigned to the user or group.

Now the user can select an Action, fill in the necessary entries and start the action. All execution policies, target systems, connectors, administrative accounts, roles and settings are organized in the central ScriptRunner repository. The host now starts an isolated PowerShell process in the script policy with all necessary data and information, contacts the target system and sends it the job “Execute this script”. After the scripts in the PowerShell have been executed on the target system, the result data is sent back to the ScriptRunner host.

The ScriptRunner Service then checks the result. If it is correct, it is forwarded to the application and the user is informed about the successful execution or, alternatively, an error.

The communication between ScriptRunner Service and target system depends primarily on the target system. This can be done using the standard PowerShell protocol (ports 5985 and 5986), http/https (Exchange), or management protocols from products from various vendors. In this case, the protocol conversion takes place in the PowerShell module of the respective product.

For an error-free function it is very important to understand the communication and the process of the specific target system and to adapt the configuration in ScriptRunner accordingly.

PowerShell Security Ebook: Everything you need to know about PowerShell Security. Get it for free!

PowerShell Security Ebook: Everything you need to know about PowerShell Security. Get it for free!

Share this article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn
  • Share on Reddit
  • Share by Mail

You might also be interested in these posts:

Article: How to Establish Simple Server Monitoring via PowerShell, by Adam BertramScriptRunner Software GmbH

How to Establish Simple Server Monitoring via PowerShell

20. January 2021
Read more
https://www.scriptrunner.com/wp-content/uploads/2021/01/PowerShell-monitoring.png 1000 1000 Adam Bertram https://www.scriptrunner.com/wp-content/uploads/2018/05/ScriptRunner_Logo_RGB-300x45.png Adam Bertram2021-01-20 09:29:522021-03-31 11:49:30How to Establish Simple Server Monitoring via PowerShell
Article: Parameter Validation Concepts in Powershell and ScriptRunner - Bruno BuyckScriptRunner Software GmbH

Parameter Validation

26. August 2020
Read more
https://www.scriptrunner.com/wp-content/uploads/2020/08/Featured-image-Parameter-Validation-concepts.jpg 441 441 Bruno Buyck https://www.scriptrunner.com/wp-content/uploads/2018/05/ScriptRunner_Logo_RGB-300x45.png Bruno Buyck2020-08-26 10:00:102021-01-07 17:13:03Parameter Validation
Webinar: Centralize PowerShell management easily and securely

Manage PowerShell centrally: How to do it in 5 steps

2. June 2019
Read more
https://www.scriptrunner.com/wp-content/uploads/2019/05/Zentralisierung1zu1-t.jpg 500 500 Heiko Brenn, Head of International Business https://www.scriptrunner.com/wp-content/uploads/2018/05/ScriptRunner_Logo_RGB-300x45.png Heiko Brenn, Head of International Business2019-06-02 21:00:492021-01-14 14:35:27Manage PowerShell centrally: How to do it in 5 steps

About the author:

Frank Kresse

Frank Kresse is the Head of Product and CEO of ScriptRunner. As the inventor of the automation and delegation solution for PowerShell, he advises clients on use case scenarios and develops solutions for the automation and the digitalization of their processes. He is also involved in technology start-ups.

Latest posts:

  • Article: PowerShell PSDefaultParameterValuesScriptRunner Software GmbHPowerShell PSDefaultParameterValues24. March 2021 - 14:10
  • Article: ScriptRunner is sponsoring the PowerShell + DevOps Global Summit 2021ScriptRunner Software GmbHScriptRunner is sponsoring the PowerShell + DevOps Global Summit 202119. March 2021 - 10:00
  • ScriptRunner ActionPack for CitrixScriptRunner Software GmbHScriptRunner ActionPack for Citrix11. March 2021 - 13:02
  • Artikelbild:ScriptRunner Software GmbH5 PowerShell Scripting Best Practices – From Runnable to Professional Code10. March 2021 - 10:00
  • Artikelbild: Vorschau auf das Produktjahr 2021ScriptRunner Software GmbHPreview of the product year 20219. March 2021 - 10:00

Product

  • ScriptRunner Platform
  • ScriptRunner Server
  • ScriptRunner Portal
  • ScriptRunner Portal Widget
  • ScriptRunner Apps
  • ScriptRunner Connectors
  • Script Collections
  • Licensing
Get your free trial

Solutions

  • IT Administrators
  • IT Team Leaders
  • Use Cases

Resources

  • Blog
  • Documentation
  • Knowledge Base
  • Webinars
  • PowerShell Lexicon
  • PowerShell Poster
  • PowerShell Security Ebook

Company

  • About us
  • Team
  • Jobs
  • Press
  • References
  • Partner

Contact

ScriptRunner Software GmbH
Ludwig-Erhard-Straße 2
76275 Ettlingen
Germany

T: +49 7243 20715-0
M: info(at)scriptrunner.com

Request Demo
© ScriptRunner Software GmbH is a subsidiary of AppSphere AG
  • LinkedIn
  • Xing
  • Twitter
  • Facebook
  • Youtube
  • Imprint
  • Privacy Policy
  • Newsletter
ScriptRunner Professional Services and Workshops ScriptRunner Professional Services und Workshops ScriptRunner release version 2018R1 ScriptRunner 2018R1 with dynamic PowerShell queries
Scroll to top