Secure access permissions
It must be possible to clearly assign a unique user id to a registered user. If access authorizations are assigned that go beyond the usual standard, this must be justified. In this case, we refer to Privileged Access Management, i.e., the management of privileged access authorizations. This can also be done electronically, e.g., by means of a special login whose name and password are made known to the users to be set up. The data entered should then be checked, e.g., by the supervisor. A password given to a user for initial system use must be changed afterwards. This should be initiated by the system.
A limited number of rights profiles should be defined. A new user is then assigned to such a profile and thus receives exactly the rights required for his or her activity. The system-specific options for setting up users and groups must be taken into account. It makes sense to define naming conventions for the user and group names (e.g., with user ID, organizational unit abbreviation, sequential number, etc.).
Access authorization for files should be limited to users or groups with a legitimate interest. If several people need to access a file, a group should be set up for them. Each user must be assigned their own user ID and login, no more than one user may work under the same ID.
An administrative role should be created for the setup work in the system. The setup should be done with the help of a special login, under which an appropriate program or script is started. Thus, the responsible administrators can set up users or user groups only in a defined way. It is not necessary to give them rights for other administration tasks.
Setup, modification and revocation of access permissions
In companies and organizations, many different authorizations must be assigned and managed per user. A role and rights model should be developed for the respective application or system, with which task-specific authorizations can be assigned and managed.
User IDs and authorizations are subject to a life cycle; they are created, changed and deleted. Authorizations should be managed centrally. Appropriate user and rights management tools are helpful here to reduce the administration and maintenance effort.
Setting up and changing access permissions
When setting up user IDs and authorizations, there are often many approval steps that need to be compiled and tracked. It is therefore advisable to use a standardized and, if possible, automated application and allocation procedure for this purpose.
In identity and access management, the following generic roles can be considered:
- User: This is the individual who accesses the information, applications or IT systems under the user ID. Except for group IDs, the user is usually the same as the owner.
- Approvers: These are the individuals who approve the granting of access, access rights, or access privileges, typically the functional managers. An approver should not be allowed to approve rights for themselves.
- Business managers: Business owners are the owners of information, applications, business procedures, business processes, or systems. They have the final say on all issues relating to content and use, as well as on requirements for the information, applications or systems in question.
- IT operations: The IT operations employees have the task of technically setting up the approved authorizations.
In general, user IDs and authorizations should always be assigned only as necessary for the performance of the task (need-to-know principle). Authorizations should also always be assigned restrictively (least privileges principle).
Control access permissions by password
In principle, it must be considered whether passwords should be used at all as the sole authentication method or whether other authentication methods or additional authentication features can be used instead of passwords, such as certificates or multi-factor authentication.
There must be fixed rules for creating and handling passwords. The users of IT systems must be instructed in this regard. This must prevent the use of weak passwords and the incorrect handling of them.
The following rules for password use must be observed:
- Passwords must be kept secret and known only to the user personally.
- Passwords may only be stored in writing. A distinction must be made between physical storage, e.g., on paper, and digital storage, e.g., in a password manager.
- In the case of physical deposit, the password must be stored securely in a sealed envelope.
- Passwords must not be stored on programmable function keys of keyboards or mice.
- Since people generally have difficulty remembering long and complicated passwords, and also since a different password must be used for each application, the use of a password manager should be considered. Security measures for these are described below.
- A password must be changed if it has become known or suspected to unauthorized persons.
- Reuse of passwords already in use should be prevented. If necessary, regulations can be issued to allow passwords to be reused after a reasonable period of time.
- Passwords may only be entered unobserved.
- Preset passwords and identifiers, e.g., from the manufacturer when IT systems are delivered, must be replaced by individual passwords and, if possible, identifiers.
One for All – One Password for Everything
As outlined above, the creation of secure passwords and changing them on a regular basis can quickly become very time-consuming. Especially when you consider how many systems and applications a user has to log on to every day.
Singe Sign On
This is where Single Sign On solutions come into play. Single sign-on means that after a single authentication at a workstation, a user can access all systems and applications for which he is authorized from the same workstation without having to log on to the individual services each time. If the user changes workstations, the authentication, as well as the local authorization, becomes invalid.
The purpose of Single Sign On is that the user only has to authenticate once with the aid of an authentication procedure (e.g., by entering a password). For subsequent authentications, the SSO mechanism now takes over this task by automating the authentication process.
The advantages of Single Sign On are obvious:
- Time savings, as only one authentication is required to access all systems.
- Security gain, since the password only has to be transmitted once.
- Security gain, as the user only has to remember one password.
- Phishing attacks are made more difficult because users only have to enter their username and password in one place and no longer in numerous, scattered places. This one place can be more easily checked for correctness (URL, SSL server certificate, etc.).
- Awareness is created as to where one can enter username and password in good conscience. Users of a single sign-on system are more difficult to entrust their password (which may have been used multiple times) to external sites.
How does Single Sign On work?
Single sign-on is based on a relationship of trust between a service provider (for example, a system or an application) and an identity service. This relationship of trust is usually based on a certificate that is exchanged between the service provider and the identity service. This certificate can be used to sign and thus validate the identity data sent by the identity service to the service provider. In this way, the service provider recognizes that this data originates from a trustworthy source. In the single sign-on process, the identity data is in the form of tokens that contain specific information for uniquely identifying a user, such as the e-mail address or username.
A logon process with Single Sign On proceeds as follows:
- A user opens the application he wants to access (i.e., the service provider).
- The service provider sends a token with information identifying the user to the single sign-on system (i.e., the identity service), requesting authentication of the user.
- The identity service first checks whether the user has already been authenticated. If so, the user is granted access to the application or system and the following step is skipped.
- If the user has not yet been authenticated, the identity service prompts him to enter his credentials. These credentials could be, for example, a username and password combination or another type of authentication such as a one-time password.
- Once the identity service has validated the credentials received, it sends a token back to the service provider to confirm successful authentication.
- This token is passed to the service provider via the user’s requesting application.
- The service provider now validates the received token against the certificate that was exchanged with the identity service during initial configuration to establish a trust relationship.
- The user is granted access to the desired application or website.
Secure management of access permissions and Single Sign On – conclusion and outlook
Properly deployed, Single Sign On has benefits for productivity, IT monitoring and management, and security control. With a single security token (for example, username and password), users can be granted and revoked access to multiple systems, platforms, applications and other resources. Reducing to one set of credentials also significantly reduces the risk of using weak, easily decrypted passwords or forgetting credentials.
A well-planned and executed single sign-on strategy can minimize costs and downtime associated with password resets and risks from insider threats. It can also improve the ease of use for users and the authentication process itself, ultimately giving the organization absolute control over user access privileges.
Utilize our expertise from numerous projects and secure your business!
Our Identity and Access Management Services
Consulting
Our profound know-how form the basis of our comprehensive portfolio of Consulting Services.
Training
We are happy to pass on our know-how to our customers and offer customized Training Services.
24/7 Support
Our 24/7 Support Services ensure that our specialists are always available to our customers.
