Defining who can access Security Center - Security Center 5.12

Security Center Administrator Guide 5.12
Product
Security Center
Content type
Guides > Administrator guides
Version
5.12
Language
English
Last updated
2024-09-13

When configuring who can access Security Center, you should first define the security partitions (responsibility boundaries), and then select the user groups and individual users who can access these partitions.

What you should know

While Security Center protects your company's assets (buildings, equipment, important data collected in the fields, and so on), your job as administrator is to protect the Security Center software against illegal access.
When securing access to your software, you should ask the three following questions:
  • Who needs to use the system? – Which users and user groups can log on?
  • What do they use it for? – What privileges must they have?
  • Which parts of the system are they responsible for? – Which partitions must they have access to?
Best Practice: It is easier to define security partitions when you first set up your system. That way, as you create entities in your system, you can place them directly into the partitions where they belong. If you start by creating users first, you might end up having to revisit their access rights every time you add a new partition to your system.

Procedure

  1. Decide whether partitions are helpful in your situation.
  2. If partitions are helpful, identify the parts of your system that are relatively independent of each other, and create a partition for each part.
    If your system covers multiple sites, and if the security staff at each site work independently of the security staff at other sites, then create a partition for each site.
  3. Identify the groups of users who share the same roles and responsibilities, create a user group for each.
    All security operators can form one group, and all investigators can form another group.
  4. If you have groups of personnel working on different partitions, define a user group for each of them, add them as members of the larger user group, and give them access to their respective partitions.

    Each individual subgroup would be allowed to access a different partition. With this organization, the purpose of the parent user groups is to separate users according to their roles and responsibilities (operators, investigators, supervisors, and so on). The purpose of the child user groups is to separate the users according to their areas of responsibility.

    Depending on whether you want the user management to be centralized or decentralized, each individual subgroup can belong to the same partition as their parent user group, managed by the same administrator, or can belong to different partitions, managed by different administrators.

  5. Define the individual users and add them as members of the user groups.
    Best Practice: Try to add the users as members of the smallest group. Let each user inherit everything from the parent user group, and only resort to configuring them individually for exceptions.