Skip to main content
Version: 3.23

Introduction

Many senhasegura features needs to perform assyncronous tasks into target systems. And these systems runs with common protocols or interfaces that can be easelly managed by senhasegura over its plugins (as you will understand better reading this manual).

Facing this real deal, senhasegura Execution module will centralize all common operations targeting execute commands or interactions over remote systems. Keeping all clients modules notified, giving a rich audit trail, logs, retrying over failures and rich data dashboards to increase the client secure governance.

What you need first

This section requires to have already a first experience with senhasegura and have an instance of the solution with at least one device and one credential registered. Before continuing reading, if you have not yet had this, you should consult the Getting Started.

Execution module​

As said before, the Execution module has many others senhasegura modules as client. For an example, it can be used to:

  • Automated password change in senhasegura PAM Proxy;

  • When its valid period expires;

  • When its was requested plain-text by some user;

  • When its was used into a proxy session;

  • When its was requested by some WebService A2A Application;

  • When its parent credential started a chained change action;

  • Credential activation or inactivation by senhasegura PAM Proxy;

  • When some user needs to start a proxy session using a locked credential;

  • When some user needs to start a proxy session using a JIT credential;

  • When some user finished a proxy session;

  • When a automated task needs to start in the Task Manager Module;

  • The task execution can be triggered by some user;

  • The task execution schedule triggered the execution;

  • When a SSL certificate, managed by Certificate Manager Module, needs some action;

  • A certificate request should be released;

  • A certificate need to be signed into a specif CA or a commercial CA;

  • A certificate need to be revoked;

  • A certificate need to be published;

We recommend reading your specific manuals for better understanding.

Through the Executions module the user will have control over the following actions:

  • Request privileged information changing;

  • Track privileged information operations;

  • Detail attempts to change privileged informations;

  • Request a privileged information changing reconciliation;

  • Configure privileged information operations automation;

  • Know the privileged information changing parameters;

  • Create new privileged information changing templates;

  • Segregate devices and credentials through profiles;

  • Configure threaded automations;

To accomplish its functions, the Execution module can be divided into three major entities.

Operation​

An operation representing a confirmed task to be done. It is registered by the client module which defines its target credential, device and also the starting time. An operation is composed by a target System, a target privileged information, an Executor and a Template.

Executor​

Also known as plugin, represents the protocol or engine to be used to connect and interact to a target system. The system can be a SSH server, a Windows over RPC, a website, a Webserver, a Cloud Provider, or any other interactible system!

Templates​

are the source-code of the task to be executed. Its have a particular syntax defined by its Executor, but every template can be composed using some masks representing Credentials, SSH Keys, Devices, Certificates, DevOps Secrets or User defined values. These masks will be replaced at the execution time.

We will explain better one-by-one in this manual. But let's take a look at the following chart to understand how they interact.

A password change running by Execution module example

As demonstrated in the image, the trigger origin will request an assinchronous execution to the Execution module. As stated earlier, many modules can request this execution.

A trigger can be the user whom requested a password view, the credential used at a proxy session, a password valid period which expired, the administrator request for change a bulk of credentials, and others modules particular triggers.

This request will then be registered as an operation in the Execution module, and when the time determined by the client is achieved, this operation will be executed.

In this example the operation is composed of an Executor to perform the interface with the target system, a Template containing the interactions that must be performed, and a target Credential that will be affected by the template commands in the target system.

At the end of the operation, the result will be recorded in the senhasegura and the requesting module will be noticed. All operation details, from its start to finish, are recorded in the client module reports and also in the Execution module. SYSLOG/SIEM messages will be echoed and dashboards will be updated to ensure corporation governance.

Chained operation using parent-child credential schema​

senhasegura allow Administrators to create a simple chained operation using parent and child credential configuration. Into this schema, when the parent credential has its password is changed successfully, the Execution module will register and schedule password change operations to all child's credentials. Each credential can be configured with a particular executor and template.

The child operation result will not affect the parent result and others child's operations.

A chained operation using parent-child schema