Access Security | Microsoft Corporation - Analyzing Requirements and Defining Solutions Architecture. MCSD Training Kit

Access security is an important part of the application's architecture. In simple terms, access security is about who gets to use the application and how they get to use it. With a secure application, both the user and the application are confident they are exchanging information within authentic circumstances. Applications must ensure the privacy of sensitive user information, and also protect the architectural components and services that run the application from unauthorized tampering or eavesdropping by the user.

For an application to be secure, each application service must be available only to qualified users. At the same time, every component, service, and supporting file must be protected from unauthorized viewing, tampering, or modification. The best way to protect the application's architectural elements and processes is with the built-in security services provides by the Windows NT and Windows 2000 operating systems. Windows NT and Windows 2000 prevent unauthorized access and tampering by providing user access control, resource and service protection, and audit ability.

Windows NT Access Security

Anything that can be done in Windows NT involves some type of security check. If someone attempts to access a file, a security check occurs. If someone tries to log onto a workstation, a security check occurs. These security checks also include access by other Windows NT computers. For example, if another computer attempts to access a data file or other resource, a security check occurs.

NOTE
When Windows NT is used as a desktop operating system, these security checks are generally invisible because in most situations users log onto their own computers with administrator privileges and never encounter any permission issues.

The Windows operating system provides a number of primary security functions to control access to enterprise applications, including those listed in Table 11.2.

Table 11.2 Primary Windows NT security functions

Function	Description	Discussed in this section
User and group management	Controls network logon and logoff rights, both local and remote, for users, groups and administrators.	User Access Control
Security policy definitions	Defines user and group rights (such as password aging, default access permissions, and audit policies).	User Access Control
File and object access	Protects files and directories, including removable media. This includes protecting the files that make up the operating systems.	File Protection
Registry access	Protects registry settings from remote tampering.	Windows NT Registry Security

With these Windows NT security functions, applications can control access to all Windows NT object types, including all of the application's objects, services, and resources. The list of securable object types is extensive, and includes:

Local or remote NTFS files and directories.

Processes and threads.

Named and anonymous pipes.

Console screen buffers.

File-mapping objects.

Access tokens.

Mail slots.

Registry keys.

Local or remote printers.

Windows NT network shares.

Windows NT services.

Inter-process synchronization objects.

The application may not be concerned with access permissions for each of these objects. However, for a difficult security implementation, it's useful to know that the application can not only define these permissions as administrator, but can also set and check object access permissions programmatically.

Knowing how Windows NT security works is important when protecting enterprise applications. Because IIS allows Web browsers to access files on a Windows NT system, it is especially important to understand the unique security requirements of a Web application. (We discuss the specifics of Web-based application security in a later section.)

User Access Control

Applications can use four Windows NT functions to control user access: user accounts, user groups, user rights policies and permissions, and program access control.

User Accounts

An application can control user access by using an authentication scheme, such as Windows NT challenge/response. If users can't log on to the network, they can't run the application.

Specifically when using Windows NT authentication, user accounts are the keys to Windows NT security. Every user who has access to a Windows NT system has a user account consisting of a name, password, and other logon parameters. With the Windows NT User Manager, administrators can establish, delete, or disable user accounts.

NOTE
It is preferable to disable Windows NT user accounts instead of deleting them. A disabled account cannot be used to gain access to the network. If a Windows NT account is deleted, all reference to it is removed from the system, which can seriously impede administrators who are trying to determine what a user could do and access, and can invalidate specific audit references.

Administrators (and other people with the correct permissions, such as Account Operators) can create as many accounts as needed and then restrict user access to applications and Windows NT resources on a per-account basis. This means that properly configured user accounts play a significant role in allowing users access to applications and operating system resources.

Generally, specific applications do not request the Windows NT security administrator to add or change network logon accounts. But as a first line of protection, Windows NT authentication is available if the application needs it.

NOTE
Programmatic access to the Windows NT SAM database can be made through the Active Directory Security Interface (ADSI), the Active User Object (AUO), Lightweight Directory Access Protocol (LDAP), and the ActiveX Data Object (ADO).

User Groups

Another way to limit access to an application is by collecting users into groups. A user group is a set of users who have identical network rights.

NOTE
Collections of users with the identical user rights and group memberships are often referred to as roles.

Grouping user accounts simplifies user-access administration. User groups also make it easier to grant multiple users access to a designated network resource, because all that must be done is to grant a specific access permission to the group (instead of to each individual user).

Defining user groups creates the application's security model, which specifies which groups have access to which application permissions. To develop such a security model, the application's use cases can be used to:

Identify the system's participants (referred to as actors in UML).

List the data and resource access operations that each participant needs (often captured in the use case diagrams, activity diagrams, and usage scenarios).

Group users according to their participation to set access permissions.

For example, a set of user groups based on levels of permissions could be Public, Private, Confidential, Secret, and Top Secret.

User Rights Policy and Permissions

User rights policy controls the rights granted to user groups and individual accounts. User rights policy also specifies restrictions, such as password expiration and lockout duration. Permissions apply to specific securable resource objects, such as files, directories, and services.

NOTE
For most security-conscious environments, password expiration should be set no higher than every 45 days, and the minimum password length should be eight characters.

User-access rights can control network resources and services, such as "logging onto a server", "running resources as services", or "backing up and restoring data." Setting control via user rights policy is accomplished by first assigning specific users to a group, then using Windows NT User Manager to grant the user or group permissions to the securable resource objects. These permissions help to specify who can use securable resource objects and under what conditions. With careful coordination of user and group access rights, enterprise applications can easily leverage Windows NT security to control user access.

Program Access Control

Applications can also control access by programmatically limiting access rights to certain users or groups. For example, selected component interfaces can be assigned to certain users, thereby preventing others from using the component's method. Security modules operating as "gatekeepers" for any component's method can be created as part of the application.

However, program access control can require a lot of administration. If the access control is "hard coded" into the objects, each time the access permissions need to be changed, the component must typically be rebuilt and redistributed. A better choice is to leverage the access security built into MTS. MTS significantly simplifies the administration of component access privileges, uses the access permissions already set up with user and group accounts, and abstracts the security from the actual components.

File Protection

Developers can protect files through the capabilities of two file systems offered by Microsoft operating systems: File Allocation Table (FAT) and the Windows NT File System (NTFS). If developers are concerned with truly controlling access to files, they should use only NTFS. FAT does not provide adequate security measures.

Applying NTFS File Permissions

An application might have many different kinds of non-database support files and folders, including .ini, .txt, .prf, or other special files that maintain program information. If the application has support files that need protection, specific and explicit permissions such as No Access, Read, Change, and Full Control can be applied.

To set access permissions for a file, the following conditions must be met:

Use a secure file system (NTFS).

Own the object.

Have object change permission.

Have full control of the object.

The most common approach to setting file access permissions is to use Windows NT Explorer. Windows NT Explorer can easily set file permissions on a file-by-file basis or for the entire folder (including all files contained within that folder).

Another tool for setting file permissions is the Cacls.exe utility. This command-line, batch mode utility displays or modifies access control lists. Cacls.exe has limited functionality: It can only grant or deny Read, Change, and Full Control permissions.

NOTE
One additional benefit of Cacls.exe is its ability to append a new permission to the permissions that already exist for a file, directory, or subdirectories. For example, the Tester group could be added to the groups that have Full Control permission for a directory and its subdirectories. The subdirectories could also have different permissions already associated with their files.

For an enterprise application (such as a Web site) that is exposed to external user access, it's not unusual to first protect all of the files on the entire server where the application resides, and then apply specific Windows NT file permissions where access is needed.

CAUTION
Use extreme caution when changing the permissions for the root directory as well as for the Windows NT system files. Careless administrators can create permission problems that prevent users from logging onto their computers.

Distributed Component Protection

If the application uses distributed COM (DCOM), the components that are deployed and registered also need to be secured. In the context of remote component deployment, security means configuring each component's access and launch permissions and protecting the component from tampering.

Security for creating remote objects is important because of the simplicity of DCOM. Whether a client uses a local ActiveX component or the same component running on a remote computer is determined by the client computer's Windows Registry entry for the component. The default configuration of DCOM allows only computer administrators to access and launch objects from a remote client. After the components are distributed, registered, and NTFS file permissions are applied, access and launch permissions can be configured.

Object permissions can be configured with the DCOMCNFG utility. With DCOMCNFG, DCOM-specific settings in the registry are defined that specify where the component runs and who can launch and access the object.

For more information on using DCOMCNFG to configure object access and launch permissions, search for DCOMCNFG in the MSDN Library.

Operating System Services Protection

Windows NT protects all of its services by allowing only its own kernel mode components to directly access operating system resources. User processes can't directly access these resources. When the application requests an operating system service, the Windows NT security system performs a validation check of the service permissions. If the service access permission matches the requesting user, the service is provided.

With Windows NT, explicit access control can be set for every operating system service. These operating system objects include processes, threads, shares, files, folders, and devices.

Windows NT Registry Security

The initialization and configuration information used by an enterprise application is typically stored in the registry. For example, the configuration information for an application's distributed components is kept in the registry. Because the default Windows NT workstation setup for the Registry Editor allows administrators to have remote access, external tampering could put the application's registry data at risk.

Take the following steps to protect the application's registry information:

Protect the registry files.

Restrict network access to the registry on each workstation that uses the application.

NOTE
For Windows NT 4.x, the registry files are in the SystemRoot\System32\Config directory. By default, the SystemRoot directory is \WINNT.

The default operating system installation on Windows NT workstations lets any administrator have remote access to the registry from another computer. If the winreg key does not appear in the registry, any user who can connect to the computer can also connect to the registry and damage the configuration information.

NOTE
The default Windows NT Workstation installation does not define the winreg key and remote registry access is allowed by default. However, Windows NT Server does define this key and allows only the administrator to remotely access the registry.

To restrict network access to the registry, the following key should be created on each workstation that uses the application:

 HKEY_LOCAL_MACHINE\SYSTEM\CurrentcontrolSet\Control\SecurePipeServers\winreg

Then the registry permissions of the winreg key should be edited to grant or revoke specific access privileges.

CAUTION
It is important to check with the network administrator before coding these registry settings into the application and component installations, as these settings may conflict with other security measures being taken by the organization.

ASP and HTML Page Security

The primary function of IIS is to download, under controlled access conditions, HTML and ASP pages from the local server to the remote browsers. Access to the application's Web pages and graphics can be limited by setting directory and file permissions for files such as those with .htm, .asp, .gif, and .jpg extensions.

Access to certain pages can be controlled programmatically by establishing user-level permissions in a Session object. The logon name and password provided by the user should be validated against a database. More secure and robust applications use the built-in security groups within Windows NT and check permissions against the Windows NT account database.

NOTE
Windows NT 4.x has a practical limit of 50,000 to 100,000 users. Third-party products, as well as Microsoft Site Server's Membership system, provide excellent security systems for Web sites with larger user communities (millions of users). With Windows 2000, the Active Directory provides additional security and scalability for very large Web communities.

Setting Web Server Permissions

The Web server's permissions can be configured to limit how users view, run, and use ASP pages. These Web server permissions apply to all users and do not differentiate between user accounts. A very basic setup would be to:

Enable the Read permissions for virtual directories containing .asp files without scripts.

Enable Read and Script permissions for virtual directories containing .asp and .htm files that contain scripts.

Enable Read and Execute permissions for virtual directories containing both .asp and other executable files, such as .exe and .dll files, which require the Execute permission to run.

After these general Web server permissions have been applied to the virtual directories, either securing the ASP and HTML pages or using TCP/IP access restrictions can specify additional access limitations at the individual file level.

MTS Application and Data Security

In a three-tier or N-tier application, users no longer access data directly from their client application. Instead, users access components from the middle tier running on MTS. This splitting of access from user to component and from component to data involves two types of security:

Application security This involves authorizing user access to the application code within the MTS packages. Developers should implement application security in the business service layer.

Data security This involves authorizing MTS packages for access to the data. Developers should implement data security in the data service layer.

Security Isolation

Server packages are the units of trust for MTS. Calls into a package can be secured. Calls within the package are trusted. Thus, application security requirements have a big impact on package design. If calls into a component must be authorized, the clients and the component must be located in different packages. Only components that can safely call each other without requiring an authorization check should be located in the same package.

MTS roles are defined on a per-package basis. Multiple components that use the same roles can be placed in the same package. Generally, this grouping is safe. Because the components can be called by the same set of users, they should be trusted to call each other. Placing components that use the same roles in one package simplifies administration because the system administrator does not need to remember to populate the role in multiple packages.

In addition, a server package runs as a particular identity, and all components in the package run as the package identity. However, some components in the package might need to run as different identities because they need different access rights to some resource or in order to maintain an audit trail. Components that need to run as different user identities should be located in separate packages. Although the exact identity each server package will run as generally can't be defined during development, any identity recommendations, along with the permissions required by package components, should be documented. For example, if a data object in a given package requires read/write access to a particular data store, the fact that the identity used to run that package must have read/write access to the data store should be documented.

Benefits of MTS Roles

Roles are a key security feature of MTS. Roles within the MTS N-tier model provide the following benefits:

Encapsulated access Database access can be totally encapsulated by MTS components because users do not access the database directly.

Connection pooling MTS can utilize connection pooling because multiple concurrent connections can be accessed between the database and MTS. Utilizing concurrent connections dramatically improves application scalability.

Streamlined security Database security administration can be streamlined because application user accounts don't need to be managed at the database level. Instead, package identities can be assigned database access which is much more efficient and manageable.

Inter-package authentication MTS security can authenticate package-to-package calls without the need for additional logons or sessions.

Declarative Security

To implement this security within Windows NT, user groups that represent the appropriate categories for application security need to be defined. Within MTS, roles are defined for a set of components within an MTS package. When the multi-service layer solution is implemented, Windows NT user groups are assigned to the appropriate MTS role. This way, users and groups are not directly associated with the data, and changing user security involves simply modifying the user groups that have access to the MTS packages. This implementation of MTS security is called declarative security.

NOTE
Traditionally, components were written to impersonate the client running the initial application that was retrieving the data. However, this method runs contrary to multi-service layer application design, where application security is separated from data security. With MTS, package identities should be set for each package, and all components running in the package share this identity. Package identities allow developers to associate a Windows NT user with the package.

Programmatic Security

Security can be programmed directly into MTS components. This programmatic security provides more granular security within the components. For example, multiple groups can be assigned to a role for a component, and the groups can be programmatically accessed within the component to further manipulate security.

MTS makes programmatic security available within its components using two methods within the ObjectContext object:

IsSecurityEnabled Developers can query the IsSecurityEnabled method to return a true value meaning that security is enabled or a false value meaning that it is not.

IsCallerRole Developers can query the IsCallerRole method to return a true or false value. This method determines whether a caller is a member of a role by accepting a string value of the role's name and comparing it with the current user account. After the comparison, IsCallerRole returns either a true value meaning the user is contained in the role or a false value meaning the user is not.

NOTE
By default, error checking should be implemented to deny access if errors occur.

Enabling MTS Security

MTS contains a system package that is automatically installed with MTS. MTS uses the components contained within the system package for internal functions. For MTS security to work, it must be properly enabled and a valid Windows NT user must be assigned to the Administrator role for this system package.

MTS security is enabled at two levels: the package level and the component level. Both levels have only two settings: enabled or disabled. The package-level setting takes precedence over the component-level setting. For example, if security is disabled at the package level, all component security is disabled. However, if package-level security is enabled, component-level security may be selectively disabled.

NOTE
It is important to keep in mind that security is triggered when a component from one package calls a component from another package. However, security is not triggered when components call one another in the same package.

SQL Server Access Permissions

Regardless of whether a component uses standard or integrated security to make a connection, SQL Server identifies the connection using the logon. Being allowed to make a connection does not mean that the component has permissions to perform any operations on the database. The component's permissions depend on its logon.

Each logon is mapped to a set of permissions for each database object. The permissions are either enabled or disabled. For example, suppose a particular user's logon contains Select permissions on the Authors table. These permissions allow the specified user to perform Select statements only on the Authors table. If this user has no Select permissions on the Employees table, the user cannot get any data from that table.

Permissions must be granted to a logon before any components using that logon can access databases or the objects inside those databases. The permissions describe the capabilities of each logon. The permissions also designate which statements a logon can issue against database tables, such as Select, Insert, Update, and Delete. In addition, the permissions determine whether or not a logon can execute specific stored procedures.

If a logon has execute permissions on a stored procedure, that logon may run the stored procedure. The stored procedure runs even if it performs actions for which the logon has no permissions. For example, a particular user's logon may be required to execute permissions on a stored procedure named AddCustomer. Even though this particular user does not have Insert permissions on the Customers table, the AddCustomer stored procedure can successfully execute an Insert statement to add a new customer.