About protecting a Microsoft Access database
This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.
This topic provides reference information about:
Securing a Microsoft Access database file
Securing database objects with user-level security
Securing Visual Basic for Applications (VBA) Code
Securing data access pages
Securing an application
Security in a multiuser environment
Return to top
Securing a Microsoft Access database file
The simplest method of protection is to set a password for opening a Microsoft Access database (.mdb). 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. This method is secure (Microsoft Access encrypts the password so that it can't be accessed by reading the database file directly), but it only applies to opening a 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.
Caution Do not use a database password if you will be replicating a database. Replicated databases can't be synchronized if database passwords are defined.
To further protect the database, you can encrypt it. Encrypting a database compacts the database file and makes it indecipherable by a utility program or word processor. Decrypting a database reverses the encryption.
Return to top
Securing database objects with user-level security
The most flexible and extensive method of securing a database is called user-level security. This form of security is similar to methods used in most network systems. The two main reasons to use user-level security are to:
Prevent users from inadvertently breaking an application by changing tables, queries, forms, reports, and macros on which the application depends.
Protect sensitive data in the database.
Under user-level security, users are required to identify themselves by an id, and then type a password when they start Microsoft Access. Within the workgroup information file, they are identified as members of a group. Microsoft Access provides two default groups: administrators (named the Admins group) and users (named the Users group), but you can define additional groups.
Although setting up user-level security on most databases can be a daunting task, the User-Level Security Wizard makes it easy to quickly secure your Access database in a one-step process. Furthermore by implementing common security schemes, the User-Level Security Wizard minimizes and even eliminates the need to use the Security command from the Tools menu.
After running the User-Level Security Wizard, you can assign or remove permissions for user and group accounts in your workgroup 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. For example, members of the Users group might be allowed to view, enter, or modify data in a Customers table but not to change the design of that table. While the Users group might be allowed to only view data in a table containing order data, they might be totally denied any access to a Payroll table. Members of the Admins group have full permissions on all of a database's tables, queries, forms, reports, and macros . You can set up more fine-grained control by creating your own group accounts, assigning appropriate permissions to those groups, and then adding users to those groups.
If you only need an administrators group and users group for your security purposes, you don't need to create additional groups; you can use the default Admins and Users groups. In this case, you only need to assign the appropriate permissions to the default Users group, and add any additional administrators to the default Admins group. Any new users you add are automatically added to the Users group. Typical permissions for the Users group might include Read Data and Update Data for tables and queries, and Open/Run for forms and reports.
If you need more fine-grained control of different groups of users, you can create your own groups, assign different sets of permissions to those groups, and then add users to the appropriate groups. To simplify the management of permissions, it is recommended that you only assign permissions to groups (not users), and then add users to the appropriate groups.
Note For more information on the Microsoft Access security model, see the .
Return to top
Securing Visual Basic for Applications (VBA) Code
You can protect Microsoft Visual Basic for Applications (VBA) code in modules and modules behind forms and reports with a password, which you enter once per session. The password prevents unauthorized users from editing, cutting, pasting, copying, exporting, and deleting VBA code.
To protect the intellectual property of your code, you can remove editable VBA code from your database, and prevent modifications to the design of forms, reports, and modules by saving it as an MDE file.
Learn about protecting VBA code.
Return to top
Securing data access pages
To protect a data access page and the data it accesses, do the following:
Protect the Access database containing the shortcut to the data access page and its corresponding HTML file by using the file system security of the computer where you have stored these files.
Protect the database connected to the data access page by securing the database against unauthorized users, controlling the level of access once a user logs in, and not saving the database password with the data access page.
Prevent unauthorized access from a malicious Visual Basic script by using Microsoft Internet Explorer security options and using three-tier data access.
Learn about how to protect a data access page.
Return to top
Securing an application
Finally, you can prevent curious or malicious end users from accidentally or intentionally damaging your application by hiding database objects from the database window and setting several startup options to control the applications appearance and behavior and protect menus and command bars.
Return to top
Security in a multiuser environment
In many situations, you will 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 will probably want to prevent users from setting a database password, too. If a user sets a database password for a shared database, 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. Running the User-Level Security Wizard on a database defines user-level security, which allows you to control access to certain features and determines how database objects can be used. 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. After running the User-Level Security Wizard, only members of the Admins group of the current workgroup have Administer permission.
If user-level security is already defined and 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.
Return to top