1. Lotus Notes Security mechanism (Lotus Development)

*** Lotus Notes Security mechanism ***

*Security mechanisms that control access to LN databases are designed to provide database protection even from DB administrators and programmers! *

Lotus Notes (LN) provides robust, proven security at multiple levels. To maximize the security of your network, Web site, applications, and servers, you must develop and implement security policies at an organizational level. By setting requirements for security concerns like remote access, passwords, modem access, administration, and firewall access, you protect your system from human error and technical weaknesses. By creating a clear policy on information distribution and employee identification, you can help eliminate unauthorized access to your system.

To develop security policies, examine each level of LN security and determine how you want to implement it in your organization. Consider weaknesses from outside your company and from inside it. Examine the tradeoffs between increased security and increased accessibility and ease of use. Also, create a plan to react to and repair breaches in security.

a) About Domino and Notes users

Domino uses ID files to secure access to servers. Every LN server and Notes user must have an ID. An ID is a unique binary file that identifies a legal LN server and Notes user. IDs are created at the time of user or server registration. An ID file contains:

· The name of its owner.

· A license number that indicates that the owner is legal and specifies whether the owner can run the North American or International edition of Domino or Notes. You can't change a license number associated with an ID.

· A public key and a private key.

· At least one certificate from a certifier ID. A certificate is an electronic stamp added to a user ID or server ID. This stamp is generated using the private key of a certifier ID that verifies that the name of the owner of the ID is correctly associated with a specific public key.

· (Optional) One or more encryption keys, created and distributed by users that allow users to encrypt and decrypt fields in a document.

If the owner of an ID creates a password for it, the password generates a key that encrypts most of the data on the ID.

b) About certification

Domino uses public key cryptography when authenticating clients to servers, for signing documents, and for encrypting mail. With public key cryptography, every user and server has a public key and a private key that are mathematically related. The private key is stored in the ID file and the public key is posted in the Public Address Book. The private key is needed to sign and decrypt messages and to authenticate as the owner of the key; the public key is needed to verify a signature, encrypt a message, or identify an authenticating user.

Public keys are not secret. Anyone may look up your public key and use it to send you encrypted mail or verify the signature on a document you signed. But it is important that someone looking up your public key learn it reliably. If someone can be fooled into believing that someone else's public key is yours, they can be fooled into believing that you signed a document when in fact you did not. For this reason, Domino does not simply list public keys in the Public Address Book. Instead, you use special IDs called certifier IDs to certify other IDs. Certifying creates special signed messages called certificates that state that a particular public key is associated with a particular name. If you can reliably learn the public key of a certifier and you have a certificate signed by that certifier, you can verify the signature on the certificate and then reliably know the public key associated with the name.

LN automatically certifies users and servers when you register them. Certificates have expiration dates so you need to recertify IDs when their expiration dates approach. Changing a name on a user or server ID or changing the public key of a user ID also involves recertification since a new certificate must be issued to bind the public key with the new name. In a hierarchical name environment, a user or server ID ordinarily has only one certificate issued by the certifier whose name is that of the user's organization or organizational unit.

In a hierarchical environment, a certification administrator can make recertification and renaming requests from the Public Address Book and the Administration Process distributes the new certificates automatically.

Multiple levels of LN security

LN security covers multiple levels, from Internet and network security down to protecting the fields in a document in a database. These levels are complementary - using a level reinforces the security above and below it. In addition to security for your network protocols, server operating systems, and client operating systems, consider the following areas:

1. Internet security

2. Network security

3. Hierarchical naming for servers and users

4. Domino server security

5. Notes client security

6. Web browser client security

7. Database security

8. Database design element security

9. Mail security

1. Internet security

1.1. About Internet security and Internet system attacks

As always, when connecting your LN environment to a network, security is a crucial issue. In addition, if you are setting up Domino as an Internet application, your organization must protect itself against attacks from outside users.

Generally, attacks on your system from the Internet come from either direct network intrusions or indirect system attacks, as follows:

· Direct attacks try to exploit the vulnerabilities of the transport protocol suite and the software programs that enable the connectivity it provides. To guard against direct attacks, construct a solid router/firewall configuration and vigilantly administer the system. These attacks typically are aimed at UNIX hosts and have been thwarted somewhat by running security checks with programs such as SATAN (System Administrator Tool for Analyzing Networks) that expose vulnerabilities.

· Indirect attacks, such as viruses, use the higher-level connectivity of messaging, transaction, and publishing systems to bring "stealth" software into your computing environment. They then either replicate and cause operational problems (such as flooding a hard disk or mail server) or are destructive. These are best guarded by user education, system containment, and vigilant administration. Indirect attacks can be made against any system and are difficult to detect and eliminate.

Connecting to the Internet offers your company many opportunities but also creates a number of security risks. LN allows you to control many of these risks. In developing Internet security policies, you must balance the need for communication and information transfer between your company and customers, vendors, suppliers, and the public, with the potential for harm that this access creates. Examples of weak points include password length and expiration, transferring information over the Internet without using encryption such as the Notes RSA algorithm or SSL, open ports through your corporate firewall, directory access to servers (critically important for UNIX servers and Windows NT), and receiving files from the Internet via e-mail, File Transfer Protocol (FTP), or the World Wide Web. In evaluating whether to open a port in your firewall, for example, you must weigh the value of allowing your employees to send and receive information through this port with the possibility that people can infiltrate your system through this opening or introduce harmful programs such as viruses by using it as an access point.

In addition, the Internet poses risks that involve both your system and the larger Internet infrastructure, such as DNS spoofing and denial of service attacks. Browsers may contain security flaws that allow foreign programs and users to interact with your network. Such risks are difficult to combat on your own -- work with your Internet Service Provider (ISP) to guard against problems.

A good resource for Internet security is the Computer Emergency Response Team, a unit of the National Computer Security Agency. Visit their Web page, which gives updates on known problems and solutions, at http://www.ncsa.com/ncsacert.html.

1.2. Firewalls

A firewall is a system that is designed to control access to applications on a network. Typically, a firewall controls unauthorized access to a private network from the public Internet. Consider carefully how you connect to the Internet. Many organizations install firewall software that protects their intranet from unauthorized external access. A firewall works at a hardware or software level to control access to your system. Firewalls implement such security measures as packet filtering, application-level gateways, circuit gateways, and are often used in conjunction with a proxy server. The Domino server and Notes workstation do not rely on a firewall. The Domino registered TCP socket (1352) can be left open in your firewall if you take appropriate security measures at the server and database level. Firewalls are useful to protect other parts of your system such as FTP and Internet mail.

1.3. Proxy servers

You can use a proxy server for your organization to mediate between client requests in your company, such as HTTP requests from a browser, and servers outside your firewall. Proxies mask the return address of the requesting computer, providing secure anonymity for users and denying any potential targets.

Proxies can implement protocol-specific security and allow you to filter incoming requests to the various protocols on your system. For example, you block all HTTP requests to objectionable Web sites using a proxy, or prevent users from downloading files via FTP except from specified trusted hosts. Some proxies run virus detection programs on incoming packets.

Proxies improve performance by caching information. If a user requests www.lotus.com through a proxy, the proxy will cache the HTTP information from www.lotus.com. Other users who request this site are sent the cached page information from the proxy, eliminating the need to transfer the data from www.lotus.com again. This conserves bandwidth and results in faster rendering of sites for your users. You can use a proxy to mediate requests from outside your firewall. For example, you make some internal documents available to public request by caching them on a proxy server outside your firewall.

1.4. Encryption

You should create a corporate policy instructing users to be cautious in transmitting any personal or company information over the Internet. Unless encrypted, this data is easily intercepted. This protection is particularly important for data such as user names, passwords, confidential product information, and electronic commerce information like credit card numbers. While browsers allow you to verify attaching to a secure server, there is no way to be certain of the identity of this server without using other means: a user might connect to an unsecured server, believing that it was in fact another, secure computer.

Domino supports version 3.0 of the Secure Sockets Layer (SSL) protocol, which allows secure encrypted communications in HTTP transactions. SSL is a public/private key RSA cryptographic system that uses key ring files to store the encryption codes needed for private communications. If you connect to a Domino server using SSL, information exchange is highly secure. Domino Directory Services, POP3 server, Web Navigator, and News Discussion server all use SSL for enhanced security. Domino can act as a Certifying Authority (CA) for SSL certificates.

1.5. Internet activity tracking

LN can create log files, in either text file or Notes database (.NSF) format, to track Internet activity on a server. The log stores information on what parts of a site or server is accessed, which browsers are used, which URLs are used, and any CGI errors that may occur. You can use these files to monitor activity on your sites and on your servers and to check for suspicious actions.

1.6. Notes client

With the Notes client, Domino uses an RSA public-private key algorithm that is even more secured than SSL and that virtually eliminates the possibility of data interception or packet sniffing. The Domino - Notes combination is the most secure client - server package available and has a security model that has been proven through time and use.

You can use Notes features such as Read access lists, Edit access lists, Authors fields, and Readers fields in your Internet databases to control access to documents.

2. Network security

2.1. About network security

Your network comprises the infrastructure behind your firewall, the firewall and any proxy servers, and computers outside the firewall that you use to communicate with the Internet. Key network security issues are guarding against unauthorized network access and authenticating user identities, protecting against viruses, and ensuring the physical security of the network.

2.2. Guarding against unauthorized access

Guarding against unauthorized network access involves, at a minimum, installing a layer of challenge - response that must be passed before access is allowed. Typically, this involves providing a user name and password, which should be encrypted. Further challenge - response points can be used to protect server access or access to particularly confidential information. An enhanced form of this security uses digital signatures to authenticate user identities. The Notes client has a digital signature based on the RSA public - private key algorithm. With browsers or other Web clients, X.509 certificates play the same role. Establish policies on keeping passwords and user names confidential and instructing users to guard their digital signatures. Instruct users to use long alphanumeric passwords to defeat dictionary attacks, where a program attempts to crack passwords by running combinations of letters against the password challenge, and remind them not to write down passwords.

The major concern for network security is intentional, malicious access by unauthorized users. Following the security precautions in these sections aids in protecting your network against these attacks. Monitor server log files for suspicious queries or attempts to access your system. Limit root access to servers and protect system files carefully. Remove unneeded services and protocols from your firewall to deny potential access points. Both firewalls and proxies can log activity, which helps you detect suspicious actions. Use a tool such as SATAN (System Administrator Tool for Analyzing Networks) to check your network for security flaws.

Remote access is often a source of risk. Ensure that modems and remote servers have the same access protections as the other access points in your organization. Utilize dial-back and password protections for modems.

Domino can encrypt data that travels through its system and over your network. This option encrypts data packets at the port level. If you are using the Internet to transfer data, encrypt the data by selecting Encrypt Network Data.

2.3. Guard against viruses

Viruses have the potential to cripple your network by destroying or corrupting data and interfering with applications and communications. Viruses are commonly introduced by users who receive programs from outside the network or who connect with a contaminated source, such as a disk with a virus. E-mail is often a source of viruses. Set up a network-wide virus scanner that checks all file attachments in e-mail and that searches for viruses on the network. In addition, install virus-scanning software on all computers and configure it to run frequent scans. Instruct users not to bring disks from outside the network into it. Warn users to be cautious of files received via or downloaded from the Internet; some are disguised viruses. Macro viruses hide inside files created by programs that allow macro scripting. Familiarize users with the security features of their applications and encourage them to use these features. When installing applications, set security defaults to a high level of protection. Viruses and other similar programs, such as Trojan horses, are data driven attacks: they operate inside a firewall when a user runs them. There are a number of products that work with Domino to scan your system for viruses.

The Notes client has a security feature called the Execution Control List (ECL) that guards against the unauthorized execution of programs received via e-mail or in a database. The ECL allows you to restrict the access and execution rights of programs depending on the digital signature of the document's author. You can allow programs created or sent by a colleague to run without restrictions but deny programs received via the Internet. If you receive a file from an unknown sender, you can choose not to run the file, to run it once but not to trust the sender, or to trust the sender and run programs sent by the same person in the future.

2.4. Guard the physical system

Your network must be physically secure. Protect servers by requiring passwords to access them and keep the server machines in a locked room with controlled access. Most operating systems allow you to password-protect keyboard access. For UNIX servers, password-protect the server account and limit permission to the data directory and program files. The Domino SET SECURE server command lets you set a password that limits access for some administration tasks, such as adding or deleting users. Password protects workstations if possible. Establish security procedures that prevent unauthorized individuals from gaining access to your network.

3. Hierarchical naming for servers and users

3.1. About hierarchical naming

Hierarchical naming gives users and servers ID files with names that are based on a cascading series of certificates. It helps differentiate users and servers, increases your control over access and authentication, allows for decentralized administration, and helps you manage your extranet. Use an organizational map to help you plan and implement hierarchical naming. When you set up the first Domino server in your organization, Domino creates an organization-level certifier (CERT.ID), a binary file, which it uses to certify, or stamp, the server's ID and an administrator's user ID. ID files contain a private key, used for authentication and digital signatures, and a series of certificates that help authenticate the ID. These certificates are the stamps created by certifier IDs and are central to hierarchical naming. While hierarchical naming requires planning and knowledge of your organizational hierarchy, it confers significant security and administration advantages.

3.2. Verifying identities

Certification allows LN to verify the identities of users and servers. An ID file is like a passport; certification is the border control process that stamps passports. If a user or server possesses a passport with the correct stamp, they can enter the destination. Cross-certificates are like visas; they allow controlled access to areas outside your organization, or permit you to give people outside your organization-controlled access to certain parts of it. With cross-certificates, Notes users from different organizations can authenticate with your servers. Each organization cross-certifies one ID file from the other and stores the cross-certificate in its Public Address Book. Cross-certification can occur at all levels of certification and can limit access to a given OU level. Cross-certification does not have to be at the same level in both directions. To restrict access by other organizations to certain servers, use Server access lists. Both certificates and cross-certificates can have expiration dates, limiting the risk of a lost or compromised ID file. This forces users and servers to have their ID files restamped at set intervals or by a certain date.

Certification affects server and user registration, server access, and electronic signatures. It verifies users and servers securely in both directions. Users and servers are referred to in Domino and Notes by their hierarchical names, or their user/server name plus their certificates. Judy Smith, who works for MicroMace and whose certificates are /MICROMACE and /SALES /MICROMACE, would be recognized as Judy Smith/SALES/MICROMACE. Always use hierarchical names in access control lists and Server access lists to prevent people with the same given name but different hierarchical names from accessing each other's files.

3.3. Organize the company

You use two types of certifiers for hierarchical naming, one organizational certifier (O) and up to three organizational unit certifiers (OU). Certifiers are analogous to families; lower-level certifiers inherit the characteristics of the certifiers above them. For example, the OU certifier /SALES/EAST/MICROMACE has a stamp for the organizational unit certifier /EAST/MICROMACE, which is certified by the organizational certifier /MICROMACE. Large organizations need more levels of certifiers than smaller organizations.

Organization certifiers generally use the company name as the stamp, such as /MICROMACE for the MicroMace Corporation, and have the file name CERT.ID. Organizational unit certifiers are commonly used to differentiate business units or geographic locations, such as /FINANCE/MICROMACE or /SOUTH/MICROMACE, and take the name of the OU for their file, such as FINANCE.ID. OU certifiers are commonly referred to by their OU name, such as the "Finance OU" for /FINANCE/MICROMACE. Each additional OU allows you to add another level with which you can distinguish users and servers. Use your first OU certifier based on the primary groups in your organization, which are frequently distinguished by geographic location or business function. For example, MicroMace might use geographic location for its first OU certifiers, /WEST/MICROMACE and /NORTH/MICROMACE, then use business units for the second OU certifiers, /SALES/WEST/MICROMACE and /ACCOUNTING/WEST/MICROMACE, and a third business unit for the individual office in which a server or user is located, such as /PHILADELPHIA/ACCOUNTING/WEST/MICROMACE. With these certifiers, MicroMace can limit access to the Sales servers to employees with the /SALES certificate on their IDs.

Lotus recommends reserving one OU to distinguish servers; for example, /H/MICROMACE could identify a hub server and /M/MICROMACE a mail server. Guard certifiers vigilantly - if compromised, they could allow unwanted access to your system.

You can create organizational unit certifiers to decentralize administration, improve security in case a certifier is compromised, to provide context for servers and users, and to distinguish people with the same name. By creating multiple certifiers, you allow more than one person to create and certify new users. You can use wildcards in access control lists (ACLs), such as */MICROMACE, which would allow anyone with the /MICROMACE certificate to access a database. Should an OU certifier file be lost or compromised, there is less work to recertify users than if an O certifier is lost, since you only recertify the employees and servers stamped with that certifier. If a certifier is lost, recertify all servers and users stamped with that certifier and then deny access for IDs with that certificate to all servers. Certificates help provide context to the function of a server or user; the certified name of the server Data1/Finance/Boston/MicroMace indicates what the server's role is. Multiple certifiers reduce the risk of having multiple people with the same name and the same certificates. For example, Domino regards Jane Doe in Marketing and Jane Doe in Administration as separate people, even though they have the same name, because they have different certificates: Jane Doe/MARKETING and Jane Doe/ADMIN. In addition, certificates conform to the X.500 naming convention.

Domino maintains a certification log with a document for each user and server with their name, license type, ID number, and date of certification and expiration. You create additional certifiers in the Public Address Book.

4. Domino server security

LN provides the most advanced, proven security available. In addition to the physical and password security, Domino servers use a server access list to determine who can access the information on that server. The server access list is configured in the Server document in the Public Address Book. You can allow or deny access to users, servers, and groups on an individual level, permit everyone to access the server, or deny all access. In addition, you can set the server to permit only users in the Public Address Book. Setting this limit denies anonymous browser access.

The access lists controls who can create databases and replicas on the server and how the server works with passthru. Passthru controls whether users can route requests through the server to another server as a steppingstone. Denying passthru limits internal access to servers and can help reduce network traffic. By using the server access list on each Domino server in your organization, you can leave the Notes port in your firewall open without concern. Domino does not allow passthru for Web browsers, who are restricted to viewing databases for which they have access on the server they are connected to.

However, you can allow anonymous Notes access to your servers by selecting Yes in the Allow Anonymous Notes Access field in the Security section of the Server document in the Public Address Book. If you allow this access, close the Notes port in your firewall, do not allow passthru access to this server, and do not allow further access from this server to the rest of your network. With this option, Server access lists and database ACLs control access to data on the server.

Domino servers authenticate with one another in the same way that Notes clients authenticate with Domino: via public - private key encryption based on an RSA algorithm. The private key is stored in the user ID file or in the server ID file. Secure connections and data integrity are assured by this method.

You can control the default level of access that Notes clients allow to executable files via the ECL. The Public Address Book contains an Administration ECL that Domino copies automatically to the Notes workstation during workstation setup. Use the Edit Administration ECL agent in the Public Address Book to update this default ECL. You can send updates of the ECL to users via Notes mail.

For administrator and server IDs, you can set multiple passwords on the ID file and require that a certain number of those passwords be entered before the ID can be used. For example, if you had four administrators with access to the server ID for a server with confidential data, you could set four passwords on the ID, give one to each administrator, and require a minimum of two passwords to use the ID. This prevents a single person from misusing critical information.

5. Notes client security

The Notes client is the most secure client available. The Notes client security model interacts with the Domino server security framework. When a Notes client attempts to access a Domino server, the server validates the client ID file by establishing that it trusts the client public key, and then authenticates the ID through a challenge-response procedure using the public and private keys of the client and server. Trust validating a common certificate on the two IDs. The certificates on the active user ID for the client determine whether the server authenticates it. Certificates generate a code associated with the name of the certifier, such as /FINANCE/MICROMACE, and consist of the association of that name plus the code. Authentication is possible when two entities, such as a server and a client, have common certificates.

The association between public and private keys created by certificates avoids the problem of public key spoofing, where a user attempts to convince another user or server that a valid public key belonging to someone else belongs to that user. Certificates can be compared to notarized messages stating that a public key is associated with a particular name. If an entity has a certificate signed by a certifier and can determine the certifier's public key, it can verify the signature on the certificate.

Notes public keys are used both for authentication and for mail encryption. You can create new public keys for users but must recertify the ID files for those users. Domino can keep clients from using the old public key and can be set to authenticate only clients whose public keys match the public keys in the Public Address Book.

Notes client ID files contain a private key that is mathematically related to the public key stored in the Public Address Book. Information encrypted with one key can be decrypted with the other. Lotus strongly recommends that you protect all ID files with passwords. Encourage users to use long alphanumeric passwords. Passwords should be at least 13 characters in length. Using mixed uppercase and lowercase letters and numbers improves password security. Using a phrase for a password makes the password easier to remember and reduces the chance that an attacker could guess it. It is important for users to remember their passwords and to keep backup copies of their ID files; if they forget the password or lose their ID file permanently, they can no longer access data encrypted with that password.

To defeat dictionary or brute force attacks on ID file passwords and to reduce the risk of password capture, Notes employs an anti-spoofing password dialog box. If users enter an incorrect password, Notes waits for several seconds before allowing them to try again. This delay increases with each incorrect attempt to a maximum of thirty seconds. The delay feature makes it difficult to try rapidly many passwords in succession in the hope of guessing the right combination. Also, the dialog box has a series of hieroglyphic symbols on the left side that change as users enter their password. These dynamic symbols make it more difficult to substitute a false dialog box that captures passwords in place of the Notes dialog box. Tell users to be alert to the symbols as they enter their passwords - if they notice that the symbols do not change or are not present, they should stop entering their password and click Cancel.

ID files allow Notes clients to create verifiable digital signatures on documents. These signatures assure readers of the identity of the document author and confirm that the document has not been tampered with since it was created. For example, digital signatures allow you to be sure that a mail message is really from a colleague and not from an untrusted third party.

6. Web browser client security

Browser clients participate interactively with all Domino features. Domino provides extensive security that allows you to control which Internet users can view and use each part of your site and who has access to your servers from browsers. Create Person documents in the Public Address Book for each Internet user whom you wish to identify individually. Person documents include HTTP passwords, which are encrypted. Authentication between a Domino server and a Web browser takes place via challenge - response and occurs when the browser tries to perform an action for which access is restricted. The browser client must provide the user name and password that match those in a user's Person document. To gain access to data, that user must be included in the database ACL as an individual or a member of a group. You can force users to supply a name and password by appending "&Login" to a URL command, but this is not a true security feature since users can delete &Login from the URL.

Domino allows SSL connections for secure communication with browsers and can act as a Certifying Authority (CA) for SSL certificates. Domino can also send certification requests to third-party CAs.

To prevent anonymous browser access to your Domino servers, select No in the Allow anonymous HTTP connections field of the Security section in the Server document. This negative setting overrides greater permissions for anonymous users in the ACLs of individual databases. To prevent anonymous access to a database, create an entry for Anonymous in the ACL and assign it No Access. You can control the maximum level of access for any user from a browser client with the Maximum Internet name & password access field, which overrides greater permissions in the ACL.

7. Database security

7.1. About database security

Database security begins with the database access control list (ACL), the checkpoint which governs access to the database. The ACL lists users, servers, and groups who have varying levels of access to the database. Entities not listed explicitly have the access granted to the Default entry. Each ACL entry has a type (Unspecified, Person, Server, Person Group, Server Group, Mixed Group) and an access level (Manager, Designer, Editor, Author, Reader, Depositor, No Access). The type designation prevents two entities with the same name from accessing a database with the same permissions. For example, by designating the server Sales as a Server and the group Sales as a Person Group, you can give the server and the group different levels of access. Using groups can help make access and administration easier - by entering a group in the ACL and then adding members to that group in the Public Address Book, you can make changes in one place and eliminate the need for adding individual entries to multiple databases.

7.2. Access levels

Access levels control the type of actions an entity can perform on the contents of a database and on the database itself. Each access level has the permissions of those below it; for example, authors can perform all of the functions of a Depositor and a Reader. No Access denies access to an entity. Depositor does not allow an entity to view the contents of the database but allows them to create certain documents in it. Readers can read documents in the database that do not have Readers fields and Authors can create documents that do not have specific access restrictions. Editors can change the content of saved documents. Designers can modify the design of all database elements and Managers can change the ACL itself.

Entities may have different levels of access in an ACL if they appear in multiple groups or as individual entries and as members of a group. The access granted in an individual entry takes precedence over that granted through a group entry. If in multiple groups, the group with the highest level of access controls. If an entity has one level of access in the ACL and another level in a Read list or View access list, the element (document, view, etc.) list can lower that entity's access.

7.3. Permissions

You can control what actions entities can take in a database with ACL Permissions. Permissions include the ability to create documents, delete documents, create personal agents, create personal folders/views, create shared folders/views, create LotusScript agents, read public documents, and write public documents. Public documents are documents designed to be accessed by a wide audience, such as the busy and free times in your personal calendar. Users with the Write public documents permission can read, create, edit, and delete public documents from a database.

7.4. Roles

The ACL structure described above applies to all databases. However, you may want to create permissions that apply only to one database. Use roles to accomplish this. Roles grant access to individual elements in a database, such as forms or views. For example, your company has a phone number database with two forms: a Phone Number form and a Request Change form. You want all employees to create a Request form, but only the office manager to create a Phone Number form. You create a Role called Phone and change the security on the Phone Number form so that only users with the Phone role can create documents with that form. You can leave employees with Author access, knowing that only the office manager can create the Phone Number form.

You can ensure that all replicas of a database have the same ACL by selecting the Enforce consistent ACL across all replicas option on the “Advanced” panel of the ACL. This prevents users from creating a replica and modifying its ACL to gain access to confidential information.

7.5. Internet

Use the Maximum Internet name & password access field to choose the maximum level of access users have when accessing a database from a Web browser. This access overrides individual levels set in the ACL.

Domino logs all ACL changes for auditing.

8. Database design element security

8.1. About controlling access to database design elements

You can control access to forms, fields, views, folders, sections, and documents without using the database ACL.

8.1.1. Forms

You can control who can read a form, create documents with a form, set up default encryption keys for a form, allow users with the "Write public documents" permission to create documents with the form, and prevent users from printing, forwarding, or copying the document to the Clipboard. You can also generate encryption keys for a form, encrypt it, and then distribute the keys to people whom you want to have access.

8.1.2. Fields

You can control who can view and enter data into a field by encrypting it with an encryption key.

8.1.3. Views

You can control who can use a view and whether users with access to public documents can see it.

8.1.4. Folders

You can control who can use a folder, whether users with access to public documents can see it, and who can update the contents of the folder.

8.1.5. Sections

You can control who can edit the contents of a section of document.

8.1.6. Documents

You can control who can read a particular document with a Readers field. This allows you to control readers on a document-by-document basis instead of for all documents created with a form. With a Readers field, three types of users can read the document: those listed in the Readers field, those listed in the read access list for the form with which the document was created, and those listed in an Authors field on the document.

You can control who can edit a particular document with an Authors field. Authors fields allow you to grant editing privileges on a document-by-document basis. An Authors field affects only entities with Author access to a database. Users with lower access cannot edit a document; users with higher access can edit a document regardless of the contents of an Authors field.

You can use an existing encryption key to encrypt a document.

9. Mail security

Domino works with standards-based Internet mail, Notes mail, cc:Mail, and X.400 mail. Mail security is a critical concern for most organizations, who need to ensure that messages are not read or tampered with by people other than the intended recipients and to verify the identity of the message author. For Internet mail, Domino supports Secure Sockets Layer version 3.0, which allows for mail encryption, digital signatures, and message content validation.

Notes mail has proven security features which offer unmatched security and features. Notes mail users can encrypt mail with the public - private key algorithm in Domino, attach digital signatures to messages to ensure that the contents are not tampered with, encrypt their mail databases, encrypt saved mail, and generate return receipts that notify the sender when the recipient has read the message. To encrypt mail, you must have the public key of the recipient stored in either the Public Address Book or your Personal Address Book.

Your Domino administrator can control how mail routes within the system by not allowing mail to route from a domain to other domains.

Extranet Security

With LN, there is little or no additional work needed to set up an extranet. Domino security allows you to set access to your intranet information as you choose. You can do this in a controlled fashion, by strictly limiting who has access to information and what information they can see, or in a general fashion, which allows anyone with a Web browser to view your organization's information. Most organizations separate their Internet site, which can be seen by anyone, from their extranet, which is treated as a business resource for customers, suppliers, vendors, consultants, and other trusted firms and people.

For example, you create a Job Postings database on your intranet for your employees to browse and then decide to make this information publicly available. By allowing Web browser access to the server and Job Postings database, you let prospective employees see the open positions in your company. At the same time, the rest of your intranet remains completely secure.

You can also make a database available only to individuals or groups - for example, you give Human Resources and managers access to a Salary database but prevent access by the rest of the company.

There are two types of extranet access: general and individual. General access is based on the Default or Anonymous entries in a database ACL to anyone who views the site. In the ACL for the database, create an entry named Anonymous and assign it the access level, roles, and permissions you want anonymous Web users to have. If you do not create an Anonymous entry, anonymous Web users have the access granted to the Default entry.

Individual access requires specific entries in the ACL, either as individual names or as members of a Group. Groups are managed in the server's Public Address Book. You can have both general and individual access concurrently. For example, you have an extranet where the Job Postings database is accessible to everyone on the Internet or with a Notes client, but the Software Specifications database is accessible to a few external consultants. Using Notes security, you can have general and individual access to different elements within a single database.

Conclusion: Security mechanisms that control access to LN database are designed to provide database protection even from DB administrators and programmers!

Literature:

1. Lotus Notes and Domino Server 4.5, Unleashed, Second Edition, Randall Tamura

2. Lotus Notes 4 Administrator’s Survival Guide, Andrew Dahl

3. Intranets Unleashed, Dwayne Gifford

4. Lotus Notes 4.5 Administrator’s Guide, Bret Swedeen