IT Baseline Protection Manual S 4.120 Configuration of access control lists for Lotus Notes databases
S 4.120 Configuration of access control lists for Lotus Notes databases
Initiation responsibility: Head of IT Section, IT Security Management
Implementation responsibility: Administrator
One of the most important security mechanisms of a Notes server is the control of access to databases. With this mechanism it is possible to control which users can access a Notes database and with what privileges. After a client (Notes client or browser) has passed the general check controlling access to a server (see S 4.119 Instituting restrictions on access to Lotus Notes servers), the mechanism controlling access to databases comes into play. To ensure protection for the data contained in the individual databases, the Access Control Lists (ACLs) must be correctly configured for every database. The following aspects should be considered here:
For every database an access concept must be prepared.
Databases under Notes can be roughly divided into two groups:
system databases, which are necessary to operate the Notes system (e.g. log databases, certificate administration database) and
databases which contain productive data (e.g. project databases).
The different intended uses must be considered in the access concepts.
All system databases must be protected with restrictive access authorisations, for example, names.nsf, admin4.nsf, catalog.nsf, log.nsf, event4.nsf, domcfg.nsf, domlog.nsf, setup.nsf, homepage.nsf, certlog.nsf. Note: depending on the server configuration some of the databases mentioned may not exist or additional ones may have been created.
When a group-based access control mechanism is used, the access control list should not contain the names of any individual users. "Manager" rights must be assigned to at least one group. Generally, when a database is created the user who creates it (normally an Administrator) is automatically entered in the ACL as having "Manager" rights. This entry also should be removed to ensure that only group-based privileges remain, but only once all the administrative settings have been made in the database.
When configuring the database access rights, it should not be assumed that there are any restrictions on access to the server. This avoids security loopholes arising as a result of changes to access restrictions on the server or errors contained in them.
No "Designer" rights should be granted on productive databases. Change management should exist for changes to the database design, allowing a controlled update cycle and, for example, covering the phases Proposal with rationale, Decision, Implementation, Test, Roll-out.
ACL lists do not have any effect on local client access. A user generally has full control over a database or database replica which is stored on the client computer. In particular, he can make changes to the database ACL and thus grant himself "Manager" rights.
The option "Enforce a consistent ACL across all replicas of this database" cannot be used to enforce implementation of the ACL in local access as the corresponding flag can be reset using existing administrative tools.
Replication of a database ACL beyond domain boundaries is not automatically possible as usually the namespaces will differ.
The ACL entry "-Default-"determines the authorisations for users who are not covered by any other ACL entry. Generally such users should not be allowed any access ("No Access"). The preconfigured rights for this entry should always be checked and, if necessary, amended.
The ACL entry "-Anonymous-" determines the authorisations for users who have not authenticated themselves (if the server allows anonymous connections). To control access by anonymous users, this entry should be contained in every ACL. If the entry is missing, then generally the "-Default-" entry will be used instead.
Access rights to a database must be granted not only to users but also to servers. This applies in particular to databases which are to be replicated.
As well as access rights, so-called roles for access control in scripts and agents of a database can also be used. The allocation of roles must also be considered as part of the access plan.
Additional controls:
Is there an access concept for every database?
Are the changes made to the ACLs for important databases checked at regular intervals (ACL log)?
