Download Chapter 13 - Emunix Documentation on the Web

1
Chapter 13
Securing an Access
Application
13
Chapter Objectives
• Learn about the elements of security
• Explore application-level security
• Use user-level security
13
The Elements of Security
• Security
 Refers to the protection of an application from
unauthorized use
• Authorization
 Specifies who can access and update different
objects in the application
13
The Elements of Security
• Application-level security
 Makes it difficult for unauthorized users to
view the contents of the application
• User-level security
 Gives different users different permissions for
various objects that comprise an application
• Permission
 Ability to perform an action on an object
13
Stripping Source Code
• .mde file
 Compiled database file that cannot be modified,
even though it is smaller and runs more quickly
• Advantages of .mde file
 Can be distributed, but users cannot view or
change the application’s objects
 Protects a developer’s investment in the
application
13
Data Encryption and
Decryption
• Encryption
 Conversion of data from one representation into
another
 New representation is coded so that it cannot be
easily understood
• Decryption
 Reverses the process of encryption
13
Data Encryption and
Decryption
• Security measures supplied by Access apply
only to Access
 Encryption will make the data more difficult to
read
• To read encrypted files:
 You must possess processes and the decoding
key necessary to decrypt the files
13
Creating a Database
Password
• Database password
 Simplest way to prevent unauthorized access to
an Access application
 Can be set in the Set Database Password dialog
box
• You can’t set a database password if userlevel security has been defined for your
database and you do not have Administer
permission for the database
13
User-Level Security
• User account
 An object that represents a user (or developer)
of an Access application
• PID
 Case-sensitive string that can hold between 4
and 20 characters
 Used in combination with the user name to
create a 128-bit machine-readable number
13
User-Level Security
• Workgroup
 Set of accounts that tend to access the same set of
Access applications
• Accounts in the workgroup share the same
workgroup information file
 Have the .mdw extension
 Access reads file information when it starts
 Contains information about the users in a workgroup
13
User-Level Security
• Workgroup identifier (WID)
 Uniquely identifies a workgroup
 Case-sensitive string that can hold between 4
and 20 characters
• Owner of an object
 Special user who always has full permissions
on the object
 Identified by the user name and PID
13
User-Level Security
• Group
 Named collection of user accounts that share
the same set of permissions on an application’s
objects
• Permissions
 Privilege
13
Creating and Joining
Workgroups
• Workgroups are created and managed
through the Microsoft Access Workgroup
Administrator
 Workgroup Administrator
 Application separate from Access
 File name Wrkgadm.exe
• When a new workgroup is joined, the old
workgroup is no longer considered active
13
User Accounts and Passwords
• Admins group
 Group account that retains full permissions on all
databases created when the workgroup was active
• Users group
 Group account that contains all user accounts
• Secure workgroup
 A workgroup that prompts for a user name and
password
13
Creating a New User Account
Figure 13-2 Entering a user
13
Creating a New User Account
• Access applications use the user name and
PID to determine the identity of the current
user
• Users can assign themselves a password
when a database is open by using the
Change Logon Password tab of the User
and Group Accounts dialog box
13
Creating a New User Account
Figure 13-3
Change
Logon
Password
tab
13
Workgroup Dynamics
• Workgroups do not share information
including user name and password
 A user account and password must be created
for each workgroup that a particular user must
use
• You can modify passwords and create new
users within VBA
13
Users and Their Groups
• Groups with the same group name and PID,
regardless of workgroup, receive the same
permissions on a particular application
• When an application supports a large
number of users, permissions should be
managed through groups
 Easier to assign permissions to a few groups
than to each individual user
13
Users and Their Groups
• You can create or delete groups in the Group tab
of the User and Group Accounts dialog box
Figure 13-4
Entering a new
group
13
Adding and Removing Users
To and From Groups
• Creating users and groups is less
cumbersome under the ADO model than the
DAO model
 Append the new user to the Users collection or
new group to the Groups collection
• A reciprocal relationship exists between the
objects in a user’s Groups collection and the
objects in the group’s Users collection
13
Adding and Removing Users
To and From Groups
Figure 13-6
Relationship
between
securityrelated
objects in
collections
13
Using and Assigning
Permissions
• Permissions can be assigned to:




All database objects
Database
Individual users
Groups of users
 All members of the group have the same
permissions
13
Using and Assigning
Permissions
• Permissions can be assigned through the User and
Group Permissions dialog box
Figure 13-7
User and
Group
Permissions
dialog box
13
Assigning Permissions Through
User and Group Permissions
Dialog Box
• With OwnerAccess Option declaration
 Used when the developer would like the user to
update data in a table, but does not want the
user to view the details of the table’s design
 When possessed by a query, a user can run the
query as long as the owner of the query has the
appropriate permissions
13
Setting and Using Permissions
in VBA
• Access stores information related to
Permissions in properties of the Container
and Document objects
 Containers collection
 Located inside a database object
 A container exists for every type of object used in an
Access application
 Contains a document collection,which also exists for
every object
13
Setting and Using Permissions
in VBA
• SetPermissions method
 Sets a value that establishes the permissions for the user
or group identified by the Group or User object
• GetPermissions method
 Retrieves permissions once they have been set
• Bitwise arithmetic
 Involves a bit-by-bit comparison of identically
positioned bits in two numeric expressions
13
Owner and Admins Group
Security Problems
• User-level security is not complete until you have
considered the special capabilities of Admins
group members and owners
• Owners of an object always have the ability to
assign themselves full permissions on the object
• If an application was created in an unsecured
environment, the Admin account is the owner of
all objects
13
Owner and Admins Group
Security Problems
Table 13-1 Permissions granted to users
13
Owner and Admins Group
Security Problems
• Important implications of these
relationships:
 Admin account should not own any object in a
secure application
 Workgroup used to create an application should
not be distributed as part of the application
• Developers can restrict the permissions of
the Admin account and Admin group
13
Changing Object Ownership and
Creating a Secure Application
• Object owner
 User who creates an Access object
 Always has full permissions applicable to an
object
• Administer permission
 Exists regardless of whether the user is a
member of the Admins group or whether an
account in the Admins group attempts to
change owner’s permission
13
Changing Object Ownership and
Creating a Secure Application
• If an object is not a database, it’s ownership may
be changed through the Change Owner tab on the
User and Group Permissions dialog box
Figure 13-8
Change Owner
tab
13
Changing Object Ownership
• Owners of a database always have the right
to open the database
• To change the ownership of an entire
database:
 Import the database into Access while you are
logged on using the account of the new owner
13
Changing Object Ownership
Figure 13-9
Import
Objects
dialog box
13
Changing Database Ownership
and Securing an Application
• The import database technique is one way
to secure an unsecured application
 Allows ownership of all objects, including the
database, to be transferred from an unsecured
database
13
The User-Level Security
Wizard
• User-Level Security Wizard WILL:




Create a new database
Import all the objects from the old database
Remove all permissions from the Users group
Encrypt the new database
• Application’s performance will be degraded
slightly because it now uses an encrypted
database
13
Preparing a Workgroup for
Distribution
• Each computer that runs an Access
application must have access to:
 The application files
 The workgroup information file
 The Access default workgroup information file is
used to run an application or
 The developer will distribute a workgroup
information file
13
Chapter Summary
• Security can be provided at both the
application and the user levels
• Application-level security has the same
effect on all users of a particular Access
database file
• Database files can be encrypted and
assigned a password
13
Chapter Summary
• User-level security
 Provides different types of security for different
users
• Key to understanding how user-level
security is implemented is to understand the
relationships between workgroups, groups,
users, owners, and permissions
13
Chapter Summary
• Admins members can always modify their
own permissions when the workgroup that
created an Access application is active
• Owners can modify their own permissions
no matter which workgroup is active
• Security features can be implemented
through Access menus and VBA