KR100833973B1 - Meta access control system - Google Patents

Abstract

The present invention relates to an access control system for a security operating system, and more particularly to a meta system that can represent known access control models. The user, a user, is assigned a defined security object to perform access control. A subject security object set and an object security object set are assigned to a subject and an object respectively, and a permission relationship is established between the subject security object set and the object security object set. In this system, the access right to the subject's object is determined based on the granted security object set, established privilege relationships, and the operations assigned to the object.

Security operating system, access control, system, security object, security object set, authority relationship, operation

Description

Meta Access Control System {META ACCESS CONTROL SYSTEM}

1 is a structural diagram of a meta access control system according to the present invention.

2 is a diagram for illustratively explaining a meta system according to the present invention;

3A illustrates the relationship between objects and operations used by the Apache daemon.

3b is an example policy description for the Apache daemon.

4A illustrates the relationship between objects and operations used by the mysql daemon.

4b is an example policy description for the mysql daemon.

5A illustrates the relationship between objects and operations used by the bind daemon.

5b is an example policy description for the bind daemon.

6A shows the relationship between objects and operations used by the samba daemon.

6b is an example policy description for the samba daemon.

<Description of the symbols for the main parts of the drawings>

11.Subject 12. Object

13. Subject Security Object Set 14. Object Security Object Set

15. Privilege Relationship 16. Operation

The present invention relates to an access control system for a security operating system, and more particularly, to a meta access control system that can be easily expressed by applying known access control models, and its structure is simple to facilitate implementation and management of a security policy.

The security operating system refers to a reliable computing environment implemented by porting a security kernel to an existing operating system and adding security functions such as authentication and encryption to solve the security problems inherent in a computer operating system. In this security operating system, functions such as identification and authentication of computer users, access control, and intrusion detection can be performed to prevent access to the kernel level and to defend, detect, and respond to unknown attacks. In this case, the access control is to determine whether the access occurring in the system is legitimate and to control it, most of the research for the system security is focused on this access control mechanism.

Traditional access control models include discretionary access control (DAC), mandatory access control (MAC), and role based access control (RBAC). DAC is the method by which the owner of an information object decides whether to grant access based on the user's identity or authority. The MAC gives the user and the information object a clearance level and secrecy level, respectively. It is a method of determining whether to grant access based on the rules. In addition, RBAC assigns a user defined role in a given organizational environment and decides whether to grant access based on the authority granted to that role.

In general, these models are optionally implemented and applied to the security operating system. However, such a security operating system is difficult to apply to the environment of a large organization (corporate or government), and there is a problem that it is difficult to accommodate the characteristics of each organization and various requirements thereof. Thus, research is currently being conducted on security frameworks or security architectures that can accommodate various access control models, such as Role Set Based Access Control (RSBAC) or SELinux. However, the methods based on the security architectures studied so far have various approaches because they implement the access control models by implementing each access control function that implements and supports the security structure similar to GFAC (Generalized Framework for Access Control) in the operating system. There are limitations in expressing control models, and in particular, as more access control models are implemented, each policy description method for access control models is needed. There is a very difficult problem to create a suitable security policy for.

For example, SELinux provides flexible access control, but only supports three models, Multi-Level Security (MLS), Type Enforcement (TE) and RBAC, which are mandatory access controls. And because of its complexity, RBAC only provides simple functionality. And too many configuration elements are needed, and the expressed policy is complex and difficult to understand. The strict policy set in Fedora Core 3 consists of more than 1,200 types, 39 kernel object classes, 197 permissions, and more than 100 macros and 40,000 rules. There are over 360,000 rules loaded and loaded into the actual Linux kernel.

An object of the present invention is to provide a meta access control system that can easily express various access control models as a policy neutral meta system. At the same time, it is to provide an access control system that is simple in structure and easy to implement and manage.

The meta system proposed in the present invention is an application system applying the E-R model used in relational database to the access control system of the security operating system. The ER model has been widely used in a useful way to represent the logical structure of systems and data since it was proposed by Peter Chen in the mid-1970s, and is the scope of research and application in the field of CASE tools, inferential modeling, expert systems, and object-oriented models. Is expanding. Early ER models included only the concepts of entities, relationships, and attributes, but later on were elements of the ER model that improved concepts such as generalization hierarchies and composite attributes. Was added.

The E-R model expresses the meaning of the real world through conceptual systems such as interconnected entity / relationship types, attributes and value types. The present invention has been completed in view of the fact that the conceptual system established in the E-R model can be applied to the access control of the computing model. Each entity / relationship type present in the E-R model can be understood in terms of a repeating "access control pattern." In other words, the entire E-R model representing an object is a pattern for one access control expressed by a particular rule. Therefore, by combining a series of behavioral elements with the interconnected entity / relationship types of the E-R model and expressing them in a certain way, the behavioral characteristics of subjects and objects, which are the basic elements of access control, can be represented.

According to the present invention, an authorization relationship between a security entity, a security entity set, and a security entity set is applied to objects, relations, and properties, which are basic elements of the ER model, for access control. In this paper, we propose a meta access control system that can represent known access control models.

The meta access control system according to the present invention comprises: a subject security entity set and a set of subjects defined as a subject, an object, and a set of subjects assigned to a specified security entity. Object Security Entity Set defined by the definition, Authorized Relationship established between the subject security object set and the object security object set, and granting the subject and object to belong to the subject security object set and the object security object set respectively. grant). Access control is performed in a way to determine the access right of the subject object based on the security object set granted, the set privilege relationship, and the operation assigned to the object property.

In this system, subjects and objects that are not granted a security object set are inherently denied all privileges, and thus no access of the subject to the subject is allowed. In addition, even if a subject and an object that have been granted the subject security object set and the object security object set have no authority relationship established between them, all access actions of the subject to the object are denied.

Security subjects as subjects and objects can be defined according to the position (function), organization, characteristics, etc. in the organization, and can be given a subject security object set, which is a set of subjects, or an object security object set, which is a set of objects. Access rights are not obtained from the direct relationship between the subject and the object, but from the permission relationship established between security object sets. Therefore, the system can be said to be suitable for an organization environment with a large number of users and information objects.

On the other hand, "security object" can be expressed as the concept of all access subjects and access objects in various security policies, "security object set" is, for example, the security level set corresponding to the security level of mandatory access control, It can be expressed as a concept such as a role set or permission set corresponding to a role or permission of role-based access control. Thus, the system can be easily applied to known access controls.

The meta access control system according to the present invention will be referred to as SEEN ( SE curity EN tity) system, and the SEEN system will be described in more detail below. 1 shows the basic structure of a SEEN system. The SEEN system includes the subject 11 and the object 12 corresponding to the security object, the subject security object set 13, the object security object set 14, the authority relationship 15, the operation 16, and the set of security objects. Authorization 17 or the like.

The subject 11 is a security entity that performs access to the object 12. In the real world, the user is generally the subject 11. Employers become members of organizations based on their positions and duties within the organization. Positions and duties have a special structure, depending on the nature of the organization, and are assigned to members of the organization. Similarly, in a computing environment, the subject 11 may be a user having a right in the corresponding system, and unlike the real world, a process may be the subject 11. Users and processes are closely related, and in a Unix-like system environment, user information is included in the process data structure and works on a process basis. Most security operating systems up to now have used processes as subjects to perform actual actions on objects in the computing environment.

The object 12 is a security object that the subject 11 performs the actual action, and all available resources become the object 12. In some cases, the subject 11 may also be used as a kind of object 12. Attributes of the object 12 include allowed operations 16 and information representing the state of the object 12. Most objects in computing environments such as Unix-like systems are managed as files. However, if all objects are managed in the same file type for access control service, it is difficult to control access according to the characteristics of the object and complicated to implement and manage, including unnecessary data structures. Manage them by class with similar characteristics.

Operations 16 are a series of specific or logical actions that the subject 11 performs on the object 12 and are the operations allowed for the object 12. When the operation 16 is assigned to the object 12, the object 12 becomes the authorized object 12, allowing the subject 11 to perform an access control action, and the operation 16 is not granted. Since the object 12 does not have a permission, the subject 11 may not perform an access control action. In the SEEN system, an operation is assigned to a privilege relationship 15 between the subject security object set 13 and the object security object set 14. When the object 12 is included in the object security object set 14, the operation granted to the object security object set 14 is allowed to the object 12. In general, operations used in Unix-like computing environments are defined using system calls. For example, operations allowed on file objects are defined as open, read, write, and so on.

Security entity sets (13, 14) are the core elements of the SEEN system and are abstract concepts defined to represent the functions that can be assigned to the components of an organization, the departments for which they belong, and the appropriate business functions for those positions. The security object set 13 and 14 may be represented as a set of subjects 11 and objects 12 which are components of access control. A set of subjects 11 is defined as a subject security object set 13 and a set of objects 12 as an object security object set. For example, the set of subjects 11 corresponding to the web administrator and the set of objects 12 used by the web administrator become a security object set, wherein the set of subjects 11 is a subject security object set 13, an object. The set of (12) is the object security object set (14). That is, the security object sets 13 and 14 may be granted to the subject 11 or the object 12 which are all members of the organization, and the security object set granted to the subject 11 is referred to as the subject security object set 13. The security object set granted to the object 12 is referred to as an object security object set 14. An inheritance relationship exists between the security object sets 13 and 14, and the security object sets 13 and 14 may be collected to form a new security object set.

The secured object set grant 17 is a special relationship between the subject secured object set 13 and the object secured object set 14. By granting the security object set (17), the established authority relationship (15) between the subject security object set (13) and the object security object set (14) is the subject (11), which is the actor of the actual access control action, and the object that is the object of the access control action Each of them is assigned to 12. The secure object set grant 17 includes granting the subject security object set 13 to the subject 11 and granting the object security object set 14 to the object 12. By granting (17) the subject security object set 13 to the subject 11, the subject 11 receives an object security object set 14 to which the subject security object set 13 and the authority relationship 15 are set. Perform the allowed operation 16 for (12). Similarly, the object 12 granted the object security object set 14 allows the operation 16 defined to the subject 11 granted the subject security object set 13 in which the authority relationship 15 is set.

A security entity set life cycle is defined, which means the duration of granting a security entity set (17), and the security entity set is defined as a static security entity set by the security entity set life cycle. ) And a dynamic security entity set. The static security object set means a security object set permanently granted to the subject 11 or the object 12, and the dynamic security object set means a security object set temporarily granted. When a security object set is assigned to a subject 11 or an object 12, the security object set becomes a static security object set or a dynamic security object set by the security object set life cycle. Dynamic security object sets are temporarily granted for special operations that are limited by the authority of the static security object set, and the privileges of the dynamic security object set are revoked after the operation is finished.

The authority relationship 15 between the subject security object set 13 and the object security object set 14 is a many-to-many relationship, and the subjects 11 belonging to the subject security object set 13 are set by the authority relationship 15. The authority for the object 13 belonging to the security object set 14 is granted. Define the roles of users and objects necessary to perform the work of the organization as security object sets, and assign the subject security object set 13 and the object security object set 14 to the user 11 and the object 12, respectively. If authority is required for the object 12, the authority relationship 15 of the subject security object set 13 and the object security object set 14 is set so that the user 11 can perform operations on the object 12. 16). This method provides an advantage of easily performing access control in an environment in which the number of users 11 and objects 12 is large.

Constraints 18 restrict the characteristics of subject 11 or object 12 belonging to subject security object set 13 and object security object set 14. Operations (16) allowed on objects (12) included in object security object set (14) that are authorized by the privilege relationship (15) between the subject security object set (13) and the object security object set (14) Can be limited through constraint (18).

Referring to FIG. 2, the SEEN system will be described by way of example. In the organization of a hospital, there are doctors, nurses, and patients as security entities corresponding to the subject 101 of the access act. For example, as nurses are divided into nurses, general nurses, and nurse assistants, doctors and nurses may be classified according to positions and roles within the organization. In addition, as a security object corresponding to the object 102 of the accessing behavior, medical information / medical record related to the patient, patient information / medical history related to the patient, etc. have.

An authority relationship (AR3) is established between the Pseudo-Security Object Set (103), which is a set of doctors, and the Medical Record Security Object Set (108), which is a set of obligation-related records. Constraints 109 have been set. In addition, an authority relationship AR2 is set between the Pseudo-Security Object Set 103 and the Patient Record Security Object Set 106, which is a set of patient-related records, and the authority relationship AR2 includes a constraint that enables a read operation ( 110) is set. In addition, an authority relationship AR1 is set between the nurse security object set 105, which is a set of nurses, and the patient record security object set 106, and a constraint 110 for enabling a read operation in the authority relationship AR1. Is set.

In the figure, since doctor 1 has been granted the pseudo-security object set 103, the patient record security object set 110 and the medical record security object set 109 in the authority relationship (AR2, AR3) with the pseudo-security object set 103. ), You have access rights within the scope of the set operation. For example, a test record file has read and write operations as attributes, so read and write operations are permitted for the test record file. In the medical record security object set 109, since the read / write operation on the file object is set as the constraint 109, the pseudo1 is for the inspection record file which is an object to which the medical record security object set 109 is assigned. Read and write operations can be performed.

In addition, since nurse 1 has been granted the nurse security object set 105, the nurse security object set 105 and the patient record security object set 106 in the authority relationship (AR1) have access rights within the set operation range. Has Since the read operation is set as the constraint 110 in the patient record secure object set 106, the nurse 1 may perform only a read operation on the patient information to which the patient record secure object set 106 is granted. However, since nurse 1 has not been granted the subject security object set in which the authority record security entity set 109 has the authority relationship, nurse 1 is not allowed to operate on the inspection record file. In the example of FIG. 3, the allowed access is <doctor 1, examination record, {read, write}>, <doctor 1, patient information, {read}>, <nurse 1, patient information, {read}>.

The SEEN system described above is formalized as follows. Definition 1 defines the basic components of the SEEN system, and Definition 2 defines the security object set grant and the authority relationship establishment between security object sets.

[Definition 1] Basic Components

-S : set of subjects that are subjects of access

O : set of objects to be accessed

A : set of operations

-E : set of security object sets

[Definition 2] Security Object Set Grant and Permission Relationship Setting

-SEG ⊆ S ㅧ E

(A grant of a security object set to a subject is a subset of the set of products of the subject and the security object set that have a many-to-many relationship.)

-OEG ⊆ O ㅧ E

(A grant of a security object set to an object is a subset of the set of products of the object-to-many-to-many relationship and the security object set.)

-OAG ⊆ O ㅧ A

(Operations are given to objects, which is a subset of the set of products of operations and objects in a many-to-many relationship.)

- AE ⊆ E E ㅧ

(Establishes the authorization relationship between security object set and security object set. It is a subset of the set of multiplication of subject security object set and object security object set which are many-to-many relationship.)

GrantedSubject ( e : E ) → 2 ^S ( Maps security object set e to subject set.)

GrantedSubject ( e ) = { s ∈ S │ ( s, e ) ∈ SEG }

GrantedObject ( e : E ) → 2 ^O ( Map security object set e to object set.)

GrantedOubject ( e ) = { o ∈ O │ ( o, e ) ∈ OEG }

GrantedAction ( o : O ) → 2 ^A ( Maps object o to a set of operations.)

GrantedAction ( o ) = { a ∈ A │ ( a, o ) ∈ OAG }

AuthorizedEntity ( e : E ) → 2 ^E (Map security entity set e to security entity set E. )

AuthorizedEntity ( e ) = { e ∈ E │ ( e, e ) ∈ AE }

Based on definitions 1 and 2, we describe how to determine access rights in the SEEN system. In the SEEN system, access rights determinations include: the subject and the object obtain a subject security object set and an object security object set, respectively; An authorization relationship between the subject security object set and the object security object set is established; Check that the operation is allowed; If the operation is allowed, the access decision is made. Otherwise, the access decision is made. In this case, GRANT is returned if the access is allowed, and DENY is returned if the access is denied. Definition 3.3 defines the SEEN system's access decision function and its associated set of access results.

[Definition 3] Decision function for access right AccessDecision  And result sets

-D : Result set of access right decision.

D = { GRANT, DENY }

AccessDecision (s : S, o : O, a : A ; out result : 2 ^D ) ^◁

s ∈ S ; o ∈ O ; a ∈ A ; e _s ∈ E ; e _o ∈ E ;

s ∈ GrantedSubject ( e _s );

o ∈ GrantedOubject ( e _o );

e _s ∈ AuthorizedEntity ( e _o );

a ∈ GrantedAction ( e _s, e _o );

result = { d : D } ^▷

Below, we define the basic grammar of subjects, objects and security object sets that are components of the SEEN system. Subjects and objects that do not have the security object set are denied access by default because all privileges are denied. Also, even if the subject security object set and the object security object set are granted, the subject and the object are denied all accesses if the authority relationship between these security object sets is not established.

Table 1 shows the definition syntax and usage examples of the operation. Defines operations assigned to objects by object type. Only defined operations are allowed on that object. Object types include files, memory, processes, and systems.

[Table 1] Calculation Definition Example

(Grammar of operation calculation) operations operation_list_name {operation_list}; operations object_name {operation_list}; (Example) operations FILE {open, read, write, execute, close}; operations MEMORY {read, write, mmap}; operations / usr / bin / ls {open, read, execute, close};

Table 2 shows the syntax and usage examples of security object sets. Declare a set of security objects that correspond to a subject security object set and an object security object set. A security object set may contain inheritance relationships and may specify a parent security object set. Security object set declarations use entity reserved words, and inheritance uses parent reserved words.

[Table 2] Security Object Set Declaration Syntax and Examples

(Secure entity declaration syntax) entity E [parent T]; entity entity_name_list; (Example) entity apache_s_entity; entity apache_o_entity, mysql_o_entity; entity apache_o_entity parent generic_home_entity;

Table 3 shows the syntax and usage examples. Permission relationship between subject security object set and object security object set is set. If a privilege relationship is established, the subject security object set can perform the privileges defined in the object security object set. Unauthorized subject security object sets and subjects or objects belonging to the object security object sets are denied access when requesting access control. Privilege relationships are set using the authorize reserved word. Constraints use constraint reserved words to limit the characteristics of object security object sets. If you omit the object type (object_type), it means the default file type (FILE) object type.

[Table 3] Permission Relationship Syntax and Usage Examples

(Authorization related settings grammar) authorize S_S_E O_S_E constraint object_type (operation_list ); authorize S_S_E O_S_E constraint_list; (Example) authorize apache_s_entity apache_o_entity constraint FILE (read); authorize apache_s_entity apache_o_entity constraint (read); authorize cybersun_s_entity cybersun_o_entity constraint FILE (write), constraint DIR (write, read);

Table 4 shows the security object set syntax and usage examples. Grant a security object set to a subject or object using the grant reserved word. When assigning a subject security object set, use the subject reserved word. When granting an object security object set, Use the object reserved word. All subjects and objects must be granted security object set to perform access control. That is, subjects or objects that do not have the security object set cannot perform access control.

[Table 4] Security Object Set Grant Syntax and Examples

Grant subject user_name {entity_list}; grant subject user_name_list {entity_list}; grant object object_name {entity_list}; grant object object_name_list {entity_list}; (Example) grant subject webmaster {apache_s_entity}; grant subject cybersun {mysqld_s_entity, home_s_entity}; grant object /var/www(/.*)? {apache_o_entity}; grant object / home / cybersun, / usr / bin {cybersun_o_entity};

Table 5 shows the event definition syntax and usage examples. Events are used to assign dynamic beam fogsets to users. A security object set is a security object set temporarily granted to a user for special tasks required in addition to the static security object set granted to the user. After the operation is completed, the authority of the dynamic security object set is lost. The when statement is a conditional check statement that is used when there are necessary conditions when granting a set of dynamic security objects. If the conditions are not met, no dynamic security object set is granted.

[Table 5] Event definition syntax and usage examples

(Event definition syntax) event user_name S_S_E_name [when condition_list]; (Example) event cybesrun passwd_s_entity when current.pid = passwd;

In the following, the Apache web service daemon, MySQL database service daemon, etc., which are application services running on the Linux operating system, are described using the SEEN system-based policy. Creating a policy requires accurate analysis of subjects, objects, and the operations required.

[Example 1] Apache (Web)

3A shows the relationship between objects and operations used by the Apache daemon. Apache is basically a server application that provides web services, and its functionality can be extended through external applications such as authentication, Common Gateway Interface (CGI), database, and Server-Side Script language (PHP, JSP, etc.). Due to the nature of Apache, it is quite difficult to create a rule that expresses all policies for near-infinity scalability. Apache provides web services by default, accessing various objects corresponding to web content, and using other objects in the system. Port 443 is used for tcp and udp sockets, which are used by default, or for Web services running on port 80 and SSL. If Kerberos authentication is used, access to '/etc/krb5.conf' file containing Kerberos authentication information is required for this, and authentication using PAM or other httpd.conf file is defined. If you use authentication via a '.access' file, you will need access to different files. Also, if you're going to use CGI or a database, there's more to consider. 3B illustrates an example in which an access control policy for basic services (authentication, CGI, web service) of Apache is described as a SEEN policy with reference to the objects and arithmetic relations of FIG. 3A.

[Example 2] MySQL (DB)

Figure 4a shows the relationship between the objects used by the MySQL service daemon and the required operations. MySQL is a relational database management system (DBMS) based on SQL. It can be used under two licensing rules, such as the GNU GPL open source system or a MySQL network subscription for business, and on a variety of platforms, including Unix / Linux and Windows. It is the most widely used DB system by providing the best query response performance among open DBs and interworking with various server-side scripts. MySQL server applications run with mysql user privileges. MySQL is a complex structure internally, but the configuration itself is simpler than Apache because the structure of the parts exposed to the operating system is very simple and intuitive. As shown in Fig. 4a, access authority for the configuration file used by MySQL must be set, and permission for the port (3306) used by MySQL and the files and log objects in which the actual DB data are stored. Figure 4b shows an example described in the SEEN policy with reference to the relationship between objects and operations used by the MySQL service daemon.

[Example 3] bind daemon policy

5A shows the relationship between objects and operations used by the bind service daemon. Domain service is a service that provides information between domain and IP. Domain information is composed of text files. One of the daemon programs that provides domain services is bind. The bind server application runs with the named user. The latest version of bind, bind9, also provides a way to remotely control the server through the rndc service. Therefore, bind, which used only port 53, also uses port 953, which uses rndc. In addition, since the configuration file method using fake root is commonly used, the object configuration for / var / named should be set to all subdirectories and regular files. FIG. 5B illustrates an example described in the SEEN policy with reference to the relationship between objects and operations used by the bind service daemon.

[Example 4] samba daemon policy

Figure 6a shows the relationship between objects and operations used by the samba service daemon. samba is a server application that supports resource sharing between different operating systems by supporting the SMB protocol. The samba server maintains configuration files in the / etc / samba directory. It consists of two daemon programs, smbd and nmbd, and the port uses port 445 of MS Windows and port 137 and 138 UDP used by SMB protocol based on port 139. In addition, log files and cache files are frequently recorded in addition to the configuration file, so the permission setting has been added. Since the samba server can have user-defined shared resources (directory, printer, etc.) depending on the configuration file, the above basic setting You need to configure the resources to be added based on this. FIG. 6B shows an example in which the SEEN policy is described with reference to the relationship between objects and operations used by the samba service daemon.

The access control system according to the present invention is a meta system that can be easily applied to the security operating system by expressing various existing access control systems in an easy-to-understand structure. This system simplifies the management of security policies and provides flexibility in implementing specific security policies for enterprises and users. In addition, users are assigned security objects according to their job titles and duties to perform access control. Privilege relationships are established between security object sets, which can be used for large organizational environments with a large number of subjects and objects.

Claims (10)

A system provided for implementing an access control policy in a security operating system; Subjects and objects assigned to the specified security object; A subject security object set and an object security object set defined by a set of subjects and a set of objects, respectively; A privilege relationship established between the subject security object set and the object security object set; And granting the subject and the object to belong to the subject security object set and the object security object set, respectively; Meta access control system, characterized in that to determine the access authority to the subject's object based on the granted security object set and the set permissions relationship. The method of claim 1, The object has an assigned operation as an attribute, and meta-access control system, characterized in that the subject's access to the disallowed operation is denied. The method of claim 1, The meta-access control system, characterized in that the authority relationship (15) between the subject security object set (13) and the object security object set (14) is a many-to-many relationship. The method of claim 1, The subject is a meta-access control system, characterized in that the security object is defined according to the position or job in the organization. The method of claim 1, The object is a meta-access control system, characterized in that the security object is defined according to the information characteristics. The method of claim 1, The meta access control system includes a restriction that restricts the characteristics of a subject or an object belonging to the subject security object set or the object security object set. The method of claim 6, The constraint is a meta-access control system, characterized in that the operation allowed to the objects included in the object security object set authorized by the permission relationship. The method of claim 1, The subject security object set or the object security object set are gathered in plurality to form a new subject security object set or object security object set meta access control system. The method of claim 1, Meta access control system, characterized in that there is an inheritance relationship in which the set of higher concepts inherit the rights of the lower concept between the subject security object set or the object security object set. The method of claim 1, When the subject security object set or the object security object set is assigned to a subject or object, the subject security object set or the object security object set becomes a static security object set or a dynamic security object set by a life cycle, and the dynamic security object set is extinguished when a certain time or operation is completed. Meta access control system.

Images