PAM Access Group
senhasegura has a permission system, where is possible to segregate the actions that a user can perform within the platform. With Access Groups you limit the data that the user can use or see within the module.
In this way, we add another layer of security to ensure the principle of least privilege. Access Groups act as a filter for entities from their properties. This allows the Administrator to deliver different levels of security to the same user within their assignments in each product.
Segregated entities and their properties
All screens that a user has access to display information from privileged entities are filtered by the Access Group. Actions that can be taken also affect these privileged entities. To avoid misuse, senhasegura queries the rules applied to the user that connects the privileged entity.
If the user has more than one access group that gives them access to privileged information, senhasegura will apply the most restrictive group rule.
Restriction levels are based on the number of steps and people who are aware of the operation:
Allows access to information;
Allow access by requiring justification of the requester;
Allow access within a time range and an approver;
In the PAM module, the segregated entity is the SSH credentials and keys. And these entities have attributes that can be used as a filter:
Devices properties:
Name of the device to which they belong;
Model of the device to which they belong;
Device tags;
Device site;
Device type;
Credential properties;
Credential username;
Additional credential information;
Credential tags;
Credential type;
By using these combinations of attributes you determine what information a group of users will have access to. Some information allows the use of wildcard or masks. We'll talk better about this later.
For some examples, see the following credential list:
ID | Username | Hostname | Device type | Product | Site | Tag |
---|---|---|---|---|---|---|
1 | root | srvdns | Server | RedHat 7.0 | LAX | |
2 | administrator | msad | Server | Windows Server 2019 | LAX | |
3 | sa | mssqlprd | Database | Windows Server 2019 | NYC | dba |
4 | System | Oraprd | Database | Oracle 19c | NYC | dba |
5 | administrator | WS1092 | Workstation | Windows 10 | SEA | |
6 | administrator | WS1035 | Workstation | Windows 10 | SEA | |
7 | administrator | WS2018 | Workstation | Windows 10 | NYC | |
8 | peter.lee | WS1092 | Workstation | Windows 10 | SEA | |
9 | peter.lee | mssqlprd | Database | Windows Server 2019 | NYC | |
10 | john.ferrer | WS1035 | Workstation | Windows 10 | SEA | |
11 | john.ferrer | WS1092 | Workstation | Windows 10 | SEA | |
12 | root | vmh-www | Server | RedHat 7.0 | AWS | |
13 | root7vmh-cicd | Server | RedHat 7.0 | AWS | ||
14 | root | vmh-fw | Server | RedHat 7.0 | AWS |
Let's take a look at some examples of groups that affect this relationship.
Allow the ServiceDesk to have access only to the Administrator user of workstations.
Username:
Administrator
Device type:
Workstation
As a result, only credentials5
,6
, and7
will be made available.
Allow DBAs to have access only to privileged Oracle database credentials:
Device type:
Database
Device model:
Oracle*
Credential Tags:
DBA
As a result, only credential4
will be made available.
Allow users to have access to credentials that take their username, regardless of the device:
- Credential username:
[#USERNAME#]
As a result, only credentials whose username is the same as the user logged in to senhasegura will be made available. If the username of senhasegura is john.ferrer only credentials10
and11
will be made available.
- Credential username:
Allow virtualization administrators to access only virtual machines hosted on AWS. By the rule adopted in this fictitious company, these machines receive the prefix vmh in their hostname:
Device name:
vmh*
Website:
AWS
As a result, only credentials12
,13
, and14
will be made available.
These are just a few examples that show how filters can be combined in creating some access groups. Please note that we do not link users at this time and do not set what can be executed. The users can be linked to a diversity of groups, and each group can allow different actions and require different levels of restriction.