Overview of Access security (MDB)

The simplest method of protection is to encode the database. Encoding a database compacts the database file and helps protect it from being read by a word processor. Encoding a database that employs no security measures has no effect because anybody can open the database and gain full access to all objects in the database. Encoding is particularly useful when you transmit a database electronically, or when your store it on floppy disk, tape, or compact disc.

Before you can encode or decode a Microsoft Access database, you must be either the owner of the database or, if the database employs security measures, a member of the Admins group of the workgroup information file that contains the accounts used to help protect the database. You must also be able to open the database in exclusive mode, which means you must have Open/Run and Open Exclusive permissions.

Decoding a database reverses the encoding.

Another method of protecting the objects in your database from casual users is to hide the objects in the Database window. This method of protection provides the least security because it is relatively simple to show any hidden objects.

You use the startup options to specify settings such as a startup form, which opens automatically when your database opens, and your database application title and icon. You can also hide the Database window, and set your own switchboard form. In a new database, the startup properties do not exist until a user makes a change to the default settings in the Startup dialog box.

Another simple method of providing security is to set a password for opening the Microsoft Access database. Once a password is set, a dialog box that requests the password will be displayed whenever the database is opened. Only users who type the correct password will be allowed to open the database. Once a database is open, all its objects are available to the user (unless other types of security have already been defined, as described later in this topic). For a database that is shared among a small group of users or on a single computer, setting a password is often all that is required.

Microsoft Access stores the database password in an unencrypted form. If this will compromise the security of the password-protected database, you should not use a database password to protect the database. Instead, you should define user-level security to help control access to sensitive data in that database.

Do not use a database password if you will be replicating a database. Replicated databases can't be synchronized if database passwords are defined.

The most flexible and extensive method of implementing security measures for a database is called user-level security. With user-level security, you can establish different levels of access to sensitive data and objects in your database. To use a database with user-level security, users type a password when they start Microsoft Access. Access reads a workgroup information file, where each user is identified by a unique identification code. The level of access and the objects that a user has access to are established based on this identification code and password.

Although setting up user-level security on most databases can be a daunting task, the User-Level Security Wizard makes it easy to quickly help protect your Access database in a one-step process. Furthermore, by implementing common security schemes, the User-Level Security Wizard minimizes and may even eliminate the need to use the Security command from the Tools menu.

After running the User-Level Security Wizard, you can create your own groups of users and assign or remove permissions for various users or group of users for a database and its existing tables, queries, forms, reports, and macros. You can also set the default permissions that Microsoft Access assigns for any new tables, queries, forms, reports, and macros that are created in a database. Permissions are granted to groups and users to regulate how they are allowed to work with each table, query, form, report, and macro in a database.

In a multiuser environment, there are many situations where you might need to employ security measures for your database. You might want to prevent users from replicating a database. Replicating a database allows a user to make a copy of a shared database and also adds fields and makes other changes to the current database. You might want to prevent users from setting a database password, because if they do, no other user will be able open the database without providing that password. You might also want to keep users from changing startup properties that specify features such as custom menus, custom toolbars, or the startup form.

If a shared database doesn't have user-level security defined, you can't prevent a user from making any of these changes. When user-level security is defined, a user or group must have Administer permission for the database to replicate a database, set a database password, or change its startup properties. Only members of the Admins group of the current workgroup have Administer permission.

If a user or group currently has Administer permission for a database, removing that permission will prevent the user or group from making any of these changes. If you need to allow a user or group to perform any of these tasks, you can assign the Administer permission to that user or group. You can't control access to these three tasks independently.

There are two different ways you can help protect Microsoft Visual Basic for Applications (VBA) code in standard modules and class modules (such as code behind forms and reports).

You can help protect your code with a password, which you enter once per session. The password helps prevent unauthorized users from editing, cutting, pasting, copying, exporting, and deleting VBA code.

When your VBA code is error-free and working correctly, you can remove it from your database by saving it as an MDE file. This helps protect the intellectual property of your code, and prevent modifications to the design of forms, reports, and modules in your database.

Data access pages are HTML pages that contain references to the data in a Microsoft Access file. However, the data access pages aren't actually stored in the Access file; they are stored as HTML files either in the local file system, in a folder on a network share, or on an HTTP server. For this reason, Microsoft Access has no control over the security of data access page files. To help protect the data access page, you must employ security measures for its link and HTML file by using the file system security of the computer where you have stored these files. To help protect the data accessed by the page, you must either employ security measures for the database that the page is connected to or configure Microsoft Internet Explorer security settings to prevent unauthorized access.