User Access

Access control provides a framework for maintaining users, roles, and security parameters, and for assigning access rights at the system, application, record, and field levels.

  • User accounts allow users to log on to Archer.
  • User groups provide a means of grouping users based on organizational structure or geographic locations.
  • Access roles are collections of application-level and page-level rights that an administrator can create and assign to any number of users and groups to control user privileges (create, read, update, and delete).
  • Security parameters are rules for controlling user access to Archer and its individual pages.
  • LDAP synchronization streamlines the administration of users and groups by allowing updates and changes that were made in the LDAP server to be reflected automatically in Archer.

Supporting your users

It is important to have well-defined policies around Help Desk procedures for your Archer installation. Help Desk administrators must understand the importance of password strength and the sensitivity of data, such as user logon names and passwords. Creating an environment where an end user is frequently asked for this kind of sensitive data increases the opportunity for social engineering attacks. Train end users to provide, and Help Desk administrators to request, the least amount of information needed in each situation.

Preventing social engineering attacks

Fraudsters frequently use social engineering attacks to trick unsuspecting employees or individuals into divulging sensitive data that they can then use to gain access to protected systems. It is recommended that you use the following guidelines to help reduce the likelihood of a successful social engineering attack:

  • If Help Desk administrators need to initiate contact with a user, they should not request any user information. Instead, users should be instructed to call the Help Desk back at a well-known Help Desk telephone number to ensure that the original request is legitimate.
  • The Help Desk telephone number should be well known to all users.
  • Help Desk administrators should only ask for user name of the user over the phone when they call the Help Desk. Help Desk administrators should never ask for user passwords.
  • Help Desk administrators should authenticate the user's identity before performing any administrative action on a user's behalf. It is recommended that you verify user identity using the following methods:
    • Call the user back on a phone owned by the organization and on a number that is already stored in the system.

      Important: Be careful when using mobile phones for identity confirmation, even if they are owned by the company because mobile phone numbers are often stored in locations that are vulnerable to tampering or social engineering.

    • Send an email to the user at a company email address. If possible, use encrypted email.
    • Work with the manager of the employee to verify the user identity.
    • Verify the identity in person.
    • Use multiple open-ended questions from employee records. For example: "Name one person in your group." or "What is your badge number?" Avoid yes or no questions.

Confirming user identities

It is critical that your Help Desk administrators verify each end-user identity before performing any Help Desk operations. It is recommended that you verify user identities using the following methods:

  • Call the end-user back on a phone owned by the organization and on a number that is already stored in the system.

    Important: Be careful when using mobile phones for identity confirmation, even if they are owned by the company. Mobile phone numbers are often stored in locations that are vulnerable to tampering or social engineering.

  • Send an email to the user at a company email address. If possible, use encrypted email.
  • Work with the employee's manager to verify the user's identity.
  • Verify the identity in person.
  • Use multiple open-ended questions from employee records. For example: "Name one person in your group." or "What is your badge number?" Avoid yes or no questions.

Advice for your users

It is recommended that you instruct your users to do the following:

  • Never give their passwords to anyone, not even to Help Desk administrators.
  • Change their passwords at regular intervals.
  • Be aware of what information requests to expect from Help Desk administrators.
  • Always log off from the Archer web interface when finished.
  • Always lock their desktops when they step away from their computers.
  • Regularly close their browser and clear their cache of data.
  • Do not upload any files to Archer from sources other than themselves.
  • Before they upload files to Archer, run a local virus scan to search for any malicious content.
  • Never enable active content when opening CSV files with spreadsheet applications like Microsoft Excel or LibreOffice Calc.

Note: It is recommended that you conduct regular training to communicate this guidance to users.

Entity permissions

Archer supports user permissions on multiple system components. It is recommended that you grant permissions only to users who need to access these components. When granting permissions to these components, it is recommended that you do not select the Everyone group because that group grants rights for all users. Additionally, it is recommended that you review the granted permissions on a routine basis to ensure that the correct access is granted to the users.

The following table explains how user permission is configured on the supported components.

Component

Permissions Explanation

Workspaces,
Dashboards,
Global iViews

Configured from the Access tab in a workspace or dashboard. It is recommended that you configure these components to be private.

Global Reports

Configured when you save a report. It is recommended that you set the Permissions field to Global Report.

Record Permissions

Configured in a Record Permissions field in an application or questionnaire.

Field Permissions

Configured in the Access tab in a field in an application or questionnaire. It is recommended that you configure fields to be private.

Configuration Administrators

 

Configuration administrators have rights to the configuration aspects (for example, fields, layout, data-driven events, notifications) of an application, questionnaire or sub-form. Configuration administrators have read rights to the content page for the application or questionnaires.

Content Administrators

Configured in applications and questionnaires. Inherently grants CRUD rights to all content within the application or questionnaire regardless of record permissions.

Global Report Administrators

Configured in Application Builder for the assigned report owners in a specific application or questionnaire.