Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] - نسخه متنی

Roberta Bragg

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید







Rule-Based Versus Role-Based Access Control Systems


Computer access control systems can be defined according to the way that they are used. The two most often specified access control systems are rule-based access control and role-based access control. Rule-based access control requires that specific rules be written that determine who can access what. An example of rule-based access control is the Access Control Lists (ACLs) written for firewall and router configurations that allow or deny access to networks. A rule-based system for users would include a multitude of rules or statements that would indicate which files, printers, or other resources a specific user could use. Rules might state things such as "JohnP can read the chapter_5.txt file, MaryJ can read and write the Septaccount.txt file, and AndrewJ can configure TCP/IP." Rule-based access control is difficult to implement as a management control for large numbers of users.

NOTE: MAC and DAC

Another way of looking at access control is by specifying the implementation of rules using either Discretionary Access Control (DAC), where access to resources is determined by resource owners, or Mandatory Access Control, where access to resources is determined by matching one's assigned level to the level assigned to the resource. Windows systems natively use DACs.

Role-based access control is based on the assumption that people use computer systems to do a job. If you can translate the job needs into computer-speak, you have defined a role and can implement it on a computer. For example:

The need to access a records room is translated into accessing a file server over the network.

The need to issue a check in payment is translated into the ability to run a specific computer program.

The need to access a group of documents is translated into granting file access permissions for the group of documents.


Implementing Role-Based Access Control in a Windows Server 2003 Network


A strict definition of role-based access control requires implementing the role by writing a script that assigns the rights and permissions needed by the role. Then, to give users the access they require, you administratively assign users to the role. While this method can be used in Windows Server 2003, role-based access control is more frequently implemented by using the following:Chapter 4, "Restricting Access to Software; Restricting Software's Access to Resources."Default Operating System User Roles." Each default Windows group has assigned rights and predefined object permissions. To assign an individual user to one of these roles, you simply make that person a group member.Chapter 11, "Securing Infrastructure Roles," provides information on how to secure these roles. Chapter 13, "Implementing a Secure PKI," defines Certificate Services roles and additional methods for securing a Certification Authority.

Custom roles are useful when the existing operating system roles may not be granular enough for your purposes. Perhaps you want a role, such as Help Desk Operators, that can reset users' passwords but that does not have full Administrator rights. Or perhaps applications that you need to run do not present defined roles for their use. For completeness, you can build additional roles either by creating custom groups or by writing applications that create their own roles.



Chaos Rules


There are other methods of managing access control for Windows systems. While doing a security review for a large enterprise, I found that access to systems and to resources was granted based on the last call to IT. In other words, if access to a resource was needed, a manager would call IT and ask for it. That was all that was necessary.

If someone found that he could not read a file, connect to a specific server, access systems remotely, or otherwise do something on the network, he simply requested the ability to do so. In most cases, his requests were granted without review. In a few cases, an ordinary user's request was ignored, but any management request was granted. Large numbers of ill-named (no idea what they were for) and ill-conceived groups existed, and there was no control over the rights and privileges granted to these groups. Some privileges and file access were also granted to individual accounts.

To be fair, in most cases, the owner of the resource was the one requesting access, and so the access was most likely granted to legitimate valid users.

However, because there was no real control over the process and no standard procedures for granting or applying permissions, there was really no good way to determine this. In addition, there was no reasonable way to remove access when an individual left the company or transferred to another job within the company.

Having no control, no approved policy or procedure, and no documentation that details what was done and by whose authority is not all that unusual.


/ 194