[go: up one dir, main page]

WO2014188743A1 - アクセス制御装置及びアクセス制御方法及びプログラム - Google Patents

アクセス制御装置及びアクセス制御方法及びプログラム Download PDF

Info

Publication number
WO2014188743A1
WO2014188743A1 PCT/JP2014/052851 JP2014052851W WO2014188743A1 WO 2014188743 A1 WO2014188743 A1 WO 2014188743A1 JP 2014052851 W JP2014052851 W JP 2014052851W WO 2014188743 A1 WO2014188743 A1 WO 2014188743A1
Authority
WO
WIPO (PCT)
Prior art keywords
hierarchy
access
information
hierarchical
rank
Prior art date
Application number
PCT/JP2014/052851
Other languages
English (en)
French (fr)
Inventor
優 小杉
雅之 佐藤
仁志 楓
光義 山足
Original Assignee
三菱電機株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 三菱電機株式会社 filed Critical 三菱電機株式会社
Priority to JP2015518114A priority Critical patent/JP5980421B2/ja
Priority to CN201480029654.5A priority patent/CN105229662B/zh
Publication of WO2014188743A1 publication Critical patent/WO2014188743A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database

Definitions

  • the present invention relates to access control using a hierarchical structure.
  • multi-tenant management technology As a basic technology for realizing a cloud service and SaaS (Software as a Service), there is “multi-tenant management technology” in which one application program (hereinafter referred to as an application) is shared by a plurality of companies (tenants).
  • the purpose of the multi-tenant management technology is to reduce hardware (H / W) resources and software (S / W) resources by sharing applications among a plurality of companies, thereby reducing costs.
  • a flexible access authority can be set by associating a user attribute with an access authority (for example, Patent Document 1).
  • the “user information table” manages not only users but also attributes such as tenants and departments, and the “access authority assignment table” has what attributes for each authority to perform access control. It manages whether the user can use the application.
  • an application originally used in a certain building may be made available to other buildings or tenants belonging to other buildings in order to expand the service range.
  • an application originally used in a certain building may be made available to other buildings or tenants belonging to other buildings in order to expand the service range.
  • Patent Document 1 there is no mention of history management and no mention of an organizational hierarchical structure. If the above request is to be realized based on the technology of Patent Document 1, if the organizational hierarchy structure is changed, all access authority assignments set when the organizational hierarchy structure is changed are all It is necessary to review.
  • the main object of the present invention is to solve such a problem, and even when the definition of the hierarchical structure is changed, the main object is to minimize the amount of data repair work associated with the change. To do.
  • An access control apparatus for storing hierarchy rank information indicating ranks between hierarchies in a hierarchical structure composed of a plurality of hierarchies;
  • a hierarchy element information storage unit that stores a hierarchy element information that is a pair of hierarchy elements that are elements constituting a hierarchy, and a pair of hierarchical elements that belong to two different hierarchies is shown for each combination of hierarchies,
  • An access permission condition information storage unit that stores access permission condition information in which an access permission condition that is a condition for permitting access to an access restriction resource to which access is restricted is associated with a specific hierarchical element;
  • An access request receiving unit that receives an access request for requesting access to an access restricted resource from a user associated with any one of the hierarchical elements;
  • the hierarchy element associated with the user is determined, and based on the rank between the hierarchies indicated in the hierarchy rank information, the hierarchy element or the hierarchy element one level above which is paired with the determined hierarchy element
  • a hierarchical element of a lower hierarchy is extracted from the hierarchical element information, and
  • a hierarchy element extractor that repeats the operation until reaching a specific hierarchy, By comparing the hierarchy element determined by the hierarchy element extraction unit and the extracted hierarchy element with the specific hierarchy element indicated in the access permission condition, access to the access restricted resource is made in response to the access request. And an access permission / rejection determination unit that determines whether to permit or not.
  • hierarchical rank information indicating the rank between hierarchies is stored, and a pair of hierarchical elements belonging to two different hierarchies stores hierarchical element information indicated for each combination of hierarchies.
  • a hierarchical structure is constructed based on the hierarchical order information and the hierarchical element information, starting from the hierarchical element associated with the user who made the access request.
  • the hierarchical relationship between hierarchies is only defined, and the hierarchical relationship between hierarchical elements is not defined, even if there is a change in the hierarchical structure, it is only necessary to modify the hierarchy order information. The amount of work can be kept to a minimum.
  • FIG. 3 is a diagram illustrating an example of a system configuration according to the first embodiment.
  • 1 is a diagram illustrating a configuration example of an access control apparatus according to Embodiment 1.
  • FIG. 3 is a diagram illustrating a configuration example of an operation request according to the first embodiment.
  • FIG. 6 is a diagram showing an example of access authority information managed by an access authority management unit according to the first embodiment.
  • FIG. 6 is a diagram illustrating an example of hierarchy definition information managed by a hierarchy definition management unit according to Embodiment 1.
  • FIG. 3 is a diagram illustrating a configuration example of a business logic unit according to the first embodiment.
  • FIG. 3 is a diagram illustrating a configuration example of a business logic information management unit according to the first embodiment.
  • FIG. 4 is a flowchart showing an operation example of a process receiving unit according to the first embodiment.
  • FIG. 4 is a flowchart showing an operation example of an F-RBAC unit according to the first embodiment.
  • FIG. 3 is a flowchart showing an operation example of a business logic unit according to the first embodiment.
  • FIG. 6 is a diagram showing an example of a hierarchical structure change request according to the first embodiment.
  • FIG. 4 is a flowchart showing an operation example of an F-RBAC unit according to the first embodiment.
  • FIG. 3 is a diagram illustrating a hardware configuration example of the access control apparatus according to the first embodiment.
  • Embodiment 1 In this embodiment, in order to enable the same application to be shared by various users, data access rights and application use rights (hereinafter referred to as access rights) in a multi-tenant application are efficiently managed.
  • the structure of will be described. More specifically, in the present embodiment, a configuration that minimizes the amount of data modification work associated with a change even when the definition of the hierarchical structure is changed will be described.
  • FIG. 1 shows a system configuration example according to the present embodiment.
  • terminals 001 and 002 are terminal devices arranged in a tenant company that uses a service, and are assumed to be personal computers, mobile terminals, and the like.
  • Web browsers 001a and 002a are installed in the terminals 001 and 002. It is assumed that the user who operates the terminals 001 and 002 is an employee of another tenant company. It is also possible to install a plurality of terminals in the same tenant company and use the same application in three or more tenant companies.
  • the terminal 000 is a terminal device used by a system administrator and an operator who manages the system shown in FIG. 1, and is assumed to be a personal computer, a mobile terminal, or the like.
  • a web browser 000a is installed in the terminal 000.
  • the network 003 is a communication path used when the terminals 001 and 002 use the access control device 004, and may be the Internet and a LAN (Local Area Network).
  • the access control device 004 determines whether or not to permit access to an access restriction resource whose access is restricted.
  • business logic application that allows access only to users belonging to a specific organization and users having specific attributes is used as an example of an access restriction resource.
  • the access control device 004 includes a process accepting unit 005, a flexible role-based access control unit (Flexible Role-based Access Control unit; hereinafter referred to as F-RBAC unit) 006, a business logic unit 007, a business logic unit 007, It has a logic information management unit 008, a user information management unit 009, an access authority management unit 010, a role assignment management unit 011, a hierarchy definition management unit 012 and an organization information management unit 013.
  • F-RBAC unit Flexible Role-based Access Control unit
  • the process accepting unit 005 receives a request transmitted from the terminals 001 and 002, and performs the process described later.
  • the process reception unit 005 receives an operation request (access request) that is a request for requesting access to the access restricted resource from the terminals 001 and 002.
  • the process reception unit 005 corresponds to an example of an access request reception unit.
  • the F-RBAC unit 006 determines the presence / absence of access authority based on the request contents of the terminals 001 and 002 and information managed in the access control device 004.
  • the F-RBAC unit 006 corresponds to an example of a hierarchy element extraction unit, an access permission determination unit, and a hierarchy order change unit.
  • the business logic unit 007 performs business processing such as work management and accounting processing.
  • the business logic information management unit 008 manages information used by the business logic unit 007.
  • the user information management unit 009 manages information on users who can operate the application.
  • the access authority management unit 010 manages access authority for business logic.
  • the role assignment management unit 011 manages organizations that can access the business logic based on the correspondence between the access authority information and the organization information.
  • the role assignment management unit 011 corresponds to an example of an access permission condition information storage unit.
  • the hierarchy definition management unit 012 manages the definition of the organizational hierarchy structure used in the system.
  • the hierarchy definition management unit 012 corresponds to an example of a hierarchy order information storage unit.
  • the organization information management unit 013 manages information on the organization that uses the application.
  • the organization information management unit 013 corresponds to an example of a hierarchical element information storage unit.
  • FIG. 2 It should be noted that a plurality of elements in FIG. 2 can exist and have a redundant structure.
  • the operation request 201 in FIG. 3 is an example of request contents transmitted from the terminals 001 and 002.
  • the operation request 201 includes authentication information such as the user ID and password of the user who issued the operation request 201, operation details for the business logic unit 007, and header information necessary for communication.
  • the HTTP HyperText Transfer Protocol
  • FTP File Transfer Protocol
  • JMS Java (registered trademark) Message
  • Service or the like can be substituted if it is possible to have the above contents.
  • the operation request 201 includes a communication header 202, authentication information 203, and operation content 204.
  • the communication header 202 is header information necessary for communication between the terminal 001 and the access control apparatus 004, and includes information on a request transmission source and a request transmission destination.
  • the authentication information 203 indicates the authentication information of the request transmission source user, and includes the user ID and password of the user as an example.
  • the operation content 204 indicates an operation request content to the business logic unit 007 of the request transmission source user, and includes, for example, a business logic type and operation content (data reference, data update, etc.).
  • FIG. 4 shows an example of user information 301 managed by the user information management unit 009.
  • the user information 301 holds information on users who use the access control device 004, and each user can be uniquely identified by the user ID.
  • the user information 301 includes a user name, an organization ID of an organization to which the user belongs, and a password necessary for user authentication.
  • FIG. 5 shows an example of the access authority information 401 managed by the access authority management unit 010.
  • the access authority information 401 holds information on the operation authority range of the business logic unit 007 managed by the access control apparatus 004 and the operation authority range of the access control apparatus 004 itself. For example, whether or not to operate the business logic A and whether or not the access authority can be operated are stored as operable contents. It should be noted that some restrictions may be imposed on whether or not the operation is possible, for example, only reference is possible.
  • FIG. 6 shows an example of role assignment information 501 managed by the role assignment management unit 011.
  • the role assignment information 501 manages the correspondence between the access authority information 401 and the organization information, and holds information indicating which organization can perform the operation.
  • the authority assignment target can be set not only for the organization but also for the entire building and the entire tenant.
  • the role assignment information can be divided into information on the role itself and information representing the correspondence between the role and the organization. As shown in FIG.
  • the role assignment information 501 includes an access permission condition which is a condition for permitting access (operation and reference) to an access restriction resource (tenant A business logic, building A business logic) as a specific hierarchical element. It is shown in association with (under T001, under B001). T001 and B001 are a tenant ID and a building ID, respectively, as shown in FIG.
  • the role assignment information 501 corresponds to an example of access permission condition information
  • the role assignment management unit 011 corresponds to an example of an access permission condition information storage unit as described above.
  • FIG. 7 shows the hierarchy definition information 601 managed by the hierarchy definition management unit 012.
  • the hierarchy definition information 601 has an expiration date indicating the order of the entities such as buildings, tenants, and organizations that use the access control device 004, and the period during which the hierarchy structure is valid.
  • the hierarchy ID: ST001 in FIG. 7 defines a structure in which a building is arranged at the top of the hierarchical structure, a tenant is arranged under the building, and an organization is arranged under the tenant.
  • buildings, tenants, and organizations are listed as examples of hierarchies. For example, it is possible to define an entity called a region in the upper hierarchy of a building or an entity called a branch office under a tenant. It is.
  • the hierarchy definition information 601 indicates the rank between hierarchies in the hierarchy structure, and corresponds to an example of the hierarchy rank information.
  • the hierarchy definition management unit 012 corresponds to an example of a hierarchy order information storage unit.
  • FIG. 8 shows information managed by the organization information management unit 013.
  • the organization information management unit 013 includes building information 701, tenant information 702, organization information 703, building / tenant correspondence information 704, tenant / organization correspondence information 705, and building / organization correspondence information 706.
  • the building information 701 holds information on a building that uses the access control device 004. Each building can be identified by a building ID. In addition to the building ID, attribute information such as a building name and a building location can be held.
  • the tenant information 702 holds information on a tenant that uses the access control device 004. Each tenant can be identified by a tenant ID. In addition to the tenant ID, it is also possible to hold attribute information such as a tenant name and tenant contract details.
  • the organization information 703 holds information on the organization that uses the access control device 004. Each organization can be identified by the organization ID. In addition to the organization ID, it is also possible to hold attribute information such as the organization name and the person in charge (organization head) in the organization. In addition, about the organization, since a hierarchical structure between organizations can be considered as in the case where a section is placed under the department, the organization (parent organization) corresponding to the upper hierarchy of the organization is also included as information.
  • the building / tenant correspondence information 704 indicates a correspondence relationship between the building managed by the building information 701 and the tenant managed by the tenant information 702.
  • the building / tenant correspondence information 704 holds an attribute that uniquely identifies a building and a tenant, such as a building ID / tenant ID. Also, if the building / tenant correspondence has an expiration date, the expiration date is retained as an attribute.
  • the tenant / organization correspondence information 705 indicates a correspondence relationship between the tenant managed by the tenant information 702 and the organization managed by the organization information 703.
  • the tenant / organization correspondence information 705 holds attributes such as a tenant ID / organization ID that can uniquely identify a tenant and an organization. If the tenant / organization correspondence has an expiration date, the expiration date is stored as an attribute.
  • the building / organization correspondence information 706 indicates a correspondence relationship between the building managed by the building information 701 and the organization managed by the organization information 703.
  • the building / organization correspondence information 706 holds an attribute such as a building ID / organization ID that can uniquely identify a building and an organization.
  • the expiration date is held as an attribute.
  • the tenant / organization correspondence information 705, and the building / organization correspondence information 706, a pair of hierarchical elements that are elements constituting a hierarchy and are related to each other in two different hierarchies. are shown for each combination of hierarchies. Specifically, regarding the building hierarchy and the tenant hierarchy, in the building / tenant correspondence information 704, a pair of B001 which is a hierarchy element of the building hierarchy and T001 which is a hierarchy element of the tenant hierarchy, and B001 which is a hierarchy element of the building hierarchy. And a pair of T002 which is a hierarchical element of the tenant hierarchy is described.
  • the tenant / organization correspondence information 705 a pair of T001 that is a hierarchy element of the tenant hierarchy and ORGT001 that is a hierarchy element of the organization hierarchy, and T001 that is a hierarchy element of the tenant hierarchy and the organization hierarchy Is described as being equivalent to ORGT002, which is a hierarchical element of As for the building hierarchy and the organization hierarchy
  • the building / organization correspondence information 706 a pair of B001 which is a hierarchy element of the building hierarchy and ORGT001 which is a hierarchy element of the organization hierarchy, B001 which is a hierarchy element of the building hierarchy and the organization hierarchy Is described as being equivalent to ORGT002, which is a hierarchical element of
  • the building / tenant correspondence information 704, the tenant / organization correspondence information 705, and the building / organization correspondence information 706 correspond to examples of hierarchical element information.
  • the organization information management unit 013 corresponds to an example of a hierarchical element information storage unit as described above.
  • FIG. 9 shows the internal configuration of the business logic unit 007.
  • the business logic unit 007 includes a business logic unit A 801, a business logic unit B 802, and a business logic unit C 803.
  • the business logic unit A 801 is in charge of different tasks such as employment management
  • the business logic unit B 802 is accounting management
  • the business logic unit C 803 is in / out room management.
  • the number of logics in the business logic unit 007 is arbitrary, and the number of internal business logics can be increased or decreased in accordance with the increase or decrease in business logic handled by the access control device 004.
  • FIG. 10 shows the internal configuration of the business logic information management unit 008.
  • the business logic information management unit 008 includes a business logic A information management unit 901, a business logic B information management unit 902, and a business logic C information management unit 903.
  • the business logic A information management unit 901 manages information handled by the business logic unit A 801
  • the business logic B information management unit 902 manages the business logic unit B 802
  • the business logic C information management unit 903 manages information handled by the business logic unit C 803.
  • the business logic A information management unit 901 has an employee list, attendance record, attendance date calendar, etc. used in the work management logic. Note that the number of internal information can be increased or decreased as in the business logic unit 007. Further, if there is information that is shared by each information management unit, it can be shared.
  • the user A belonging to the tenant A operates the business logic A in the access control device 004, the user A uses the Web browser 001a of the terminal 001 to check his / her authentication information and business logic.
  • a request for operation content is issued in the form of an operation request 201.
  • the request reception unit 005 centrally executes request management and response generation.
  • FIG. 3 shows an operation request 201 transmitted by the user with the user ID: U001 using the terminal 001 and requesting data reference of the business logic A (business ID: L001).
  • the user A belongs to the organization with the organization ID: ORG001
  • the organization with the organization ID: ORG001 belongs to the tenant with the tenant ID: T001
  • the tenant with the tenant ID: T001 has the building ID: It belongs to the building of B001.
  • the access control device 004 does not hold information in which the hierarchical relationship between hierarchical elements as shown in FIG. 19 is defined in advance, and when an operation request 201 is received, as described later, the F-RBAC unit 006 analyzes the hierarchical relationship between the hierarchical elements using the information shown in FIGS. 7 and 8.
  • the process accepting unit 005 acquires the authentication information 203 and the operation content 204 from the received operation request 201, outputs the authentication information 203 and the operation content 204 to the F-RBAC unit 006, and performs an operation on the business logic of the requesting user.
  • the F-RBAC unit 006 is inquired of whether it is possible (S101).
  • the process reception unit 005 determines whether or not the user can operate from the inquiry result of the F-RBAC unit 006 (S102).
  • the process accepting unit 005 delivers the operation content 204 of the operation request 201 to the business logic unit 007 (S103). Then, the process reception unit 005 returns an operation request result to the business logic unit 007 to the terminal 001a as a response (S104).
  • the process accepting unit 005 returns a response indicating that the operation is impossible to the terminal 001a (S105).
  • the F-RBAC unit 006 acquires information necessary for authentication such as a user ID and a password from the authentication information 203 received from the process reception unit 005 (S201).
  • the F-RBAC unit 006 inquires of the user information management unit 009 about information on the user having the user ID acquired from the authentication information 203 (S202).
  • the F-RBAC unit 006 verifies whether or not the user authentication is successful (S203). Specifically, the F-RBAC unit 006 verifies by the following procedure.
  • the F-RBAC unit 006 confirms from the response of the user information management unit 009 whether there is a user having the user ID acquired in S201. If there is no corresponding user, authentication is not possible. If there is a corresponding user, it is determined whether the password acquired from the authentication information 203 matches the password managed by the user information management unit 009. If the passwords match, authentication succeeds. If they do not match, authentication fails.
  • the F-RBAC unit 006 acquires the business ID of the business logic to be operated by the user from the operation content 204 received from the processing reception unit 005, and the access authority A list of access authorities associated with the logic of the business ID is acquired in the management unit 010 (S204).
  • the F-RBAC unit 006 obtains the record of authority ID: A001 and the record of authority ID: A002 of FIG. 5 based on the business ID: L001 if the operation content 204 of FIG.
  • the F-RBAC unit 006 obtains information on the current hierarchy order from the hierarchy definition management unit 012 (S205).
  • hierarchical order information in which “building>tenant> organization” is described is acquired.
  • the F-RBAC unit 006 acquires information on the organization to which the user belongs from the organization information management unit 013 based on the information on the organization ID of the organization to which the user belongs from the user information acquired from the user information management unit 009 (S206). ).
  • the organization to which the target user A belongs is the organization with the organization ID: ORG001 from FIG.
  • the F-RBAC unit 006 based on the hierarchy order information acquired from the hierarchy definition management unit 012 and the organization information acquired from the organization information management unit 013, the building, tenant, The acquisition of organization information is repeated until there is no higher-level organization (S207). Since the hierarchy order acquired in S205 is “Build>Tenant> Organization”, the F-RBAC unit 006 first forms a hierarchy that is paired with the organization ID: ORG001 in the tenant hierarchy that is one level above the organization. Search for an element. Specifically, the F-RBAC unit 006 searches the tenant / organization correspondence information 705 in FIG. 8 and extracts the tenant ID: T001 paired with the organization ID: ORG001.
  • the F-RBAC unit 006 searches the hierarchy order “building>tenant> organization” for a hierarchy element that is paired with the tenant ID: T001 in the building hierarchy that is one hierarchy above the tenant. Specifically, the F-RBAC unit 006 searches the building / tenant correspondence information 704 in FIG. 8 and extracts the building ID: B001 paired with the tenant ID: T001.
  • the F-RBAC unit 006 acquires from the role assignment management unit 011 role assignment information that matches the access authority obtained in S204 and the organization, tenant, and building obtained in S206 and S207 (S208).
  • the F-RBAC unit 006 acquires a record with a role assignment ID: R001 and a record with a role assignment ID: R002.
  • the F-RBAC unit 006 determines whether or not the role assignment acquired in S208 exists (S209). For organizations, it is checked whether there is an assignment in order from the upper hierarchy.
  • the F-RBAC unit 006 determines that the authentication is successful and returns a success response to the process reception unit 005 (S210). Since the operation request 201 in FIG. 3 requires data reference, it matches the “role name: only building business logic A can be referred to” in FIG. 6, and the F-RBAC unit 006 succeeds in the process reception unit 005. Returns a response.
  • the F-RBAC unit 006 determines that the authentication has failed, and returns a failure response to the process reception unit 005 (S211).
  • the business logic unit 007 determines which business logic in the business logic unit 007 is designated from the operation content 204 received from the process reception unit 005, and delivers the operation content to the internal business logic ( S301). In the following, the operation will be described assuming that the business logic unit A801 in FIG. 9 is designated.
  • the business logic unit A801 performs an operation while referring to and updating information handled by the business logic A information management unit 901 in the business logic information management unit 008 based on the operation content received from the business logic unit 007 in S301 (S302). .
  • the business logic unit A 801 returns a response to the processing reception unit 005 via the business logic unit 007 for the result of performing S302 (S303).
  • FIG. 14 shows an example of a hierarchical structure change request that is a request that the system user transmits to the access control apparatus 004 using the terminal 000 when the hierarchical structure of the access control apparatus 004 is changed.
  • a system user who manages the access control device 004 transmits a hierarchical structure change request 1301 to the access control device 004 using the Web browser 000a of the terminal 000.
  • the hierarchy structure change request 1301 is a request for requesting to change the hierarchy order in the hierarchy definition information 601 of FIG.
  • the F-RBAC unit 006 changes the hierarchical order in the hierarchical definition information 601. change. Note that the operation of the process accepting unit 005 and the operation up to the authentication of the F-RBAC unit 006 are the same as S101 to S105 and S201 to S203 described above.
  • the process reception unit 005 returns a response to the terminal 000.
  • the F-RBAC unit 006 acquires the operation content 1304 describing the hierarchical structure change information from the hierarchical structure change request 1301 received from the process accepting unit 005 (S401). Next, the F-RBAC unit 006 issues a hierarchical structure definition change request to the hierarchy definition management unit 012 for the operation content 1304 acquired in S401 (S402).
  • the hierarchy definition management unit 012 changes, for example, the hierarchy definition information 601 in FIG. 7 to the hierarchy definition information 602 in FIG. 16 in accordance with the request received in S402.
  • “tenant>building> organization” is defined as a new hierarchy order. Further, the hierarchy order “building>tenant> organization” before the change is held in the hierarchy definition information 602 together with the expiration date.
  • the F-RBAC unit 006 returns the operation result to the process reception unit 005 after the processing of the hierarchy definition management unit 012 is completed (S403).
  • the F-RBAC unit 006 performs the process of FIG. 12 based on the changed hierarchy order.
  • the hierarchical element is searched in the direction toward the upper hierarchy (S207).
  • the hierarchical element may be searched in the direction toward the lower hierarchy.
  • a hierarchy definition management unit that manages the structure of the organization hierarchy and the validity period of the hierarchy structure;
  • the hierarchy is traced in order from the top while interpreting the organizational hierarchical structure, and the role assignment target is compared with the organizational hierarchy position to which the user who uses the system belongs.
  • a tenant access control device, method, and program provided with an access control unit that realizes the change of the hierarchical structure in the system by changing the expiration date of the hierarchical structure explained.
  • the tenant access control apparatus, method, and program provided with an access control unit that determines whether or not access is possible based on information on whether or not an access authority management unit can access when an individual uses an application in the system have been described.
  • Embodiment 2 FIG. In the present embodiment, differences from the first embodiment will be described. Operations and configurations other than those described below are the same as those in the first embodiment.
  • FIG. 17 shows the hierarchy definition information 610 of the hierarchy definition management unit 012 according to this embodiment.
  • information corresponding to the business logic is added as an attribute, such as a business ID, as compared with the hierarchy definition information 601 in FIG. 7.
  • the hierarchical structure can be changed for each business logic. That is, in the hierarchy definition information 610 according to the present embodiment, a hierarchy order is defined for each business logic (access restricted resource).
  • FIG. 18 shows a business logic definition 910 of the business logic information management unit 008 according to this embodiment. Unlike FIG. 10, in FIG. 18, a business ID is assigned to each business logic.
  • the F-RBAC unit 006 acquires a business ID from the operation request 201 when acquiring the hierarchical order in S205 of FIG. The hierarchical order corresponding to the acquired business ID is acquired, and the acquired hierarchical order is used for the subsequent determination of the presence of access authority.
  • It has a hierarchy definition manager with an organizational hierarchy for each application in the system,
  • a tenant access control apparatus, method, and program provided with an access control unit that switches the organizational hierarchy structure for each application by the hierarchy definition management unit when an individual uses an application in the system and determines whether access is possible have been described.
  • the access control device 004 is a computer, and each element of the access control device 004 can be realized by a program.
  • an arithmetic device 1901, an external storage device 1902, a main storage device 1903, a communication device 1904, and an input / output device 1905 are connected to the bus.
  • the arithmetic device 1901 is a CPU (Central Processing Unit) that executes a program.
  • the external storage device 1902 is, for example, a ROM (Read Only Memory), a flash memory, or a hard disk device.
  • the main storage device 1903 is a RAM (Random Access Memory).
  • the “ ⁇ management unit” illustrated in FIG. 2 is realized by the external storage device 1902 or the main storage device 1903.
  • the communication device 1904 corresponds to the physical layer of the process reception unit 005.
  • the input / output device 1905 is, for example, a mouse, a keyboard, a display device, or the like.
  • the program is normally stored in the external storage device 1902, and is sequentially read into the arithmetic device 1901 and executed while being loaded in the main storage device 1903.
  • the program is a program that realizes the functions described as “ ⁇ unit” (excluding “ ⁇ management unit”, the same applies hereinafter) shown in FIG.
  • an operating system (OS) is also stored in the external storage device 1902. At least a part of the OS is loaded into the main storage device 1903, and the arithmetic unit 1901 executes “OS” while executing “OS” shown in FIG. ”Is executed.
  • variable values are stored in the main storage device 1903 as files.
  • the encryption key / decryption key, random number value, and parameter may be stored in the main storage device 1903 as a file.
  • the configuration in FIG. 20 is merely an example of the hardware configuration of the access control device 004, and the hardware configuration of the access control device 004 is not limited to the configuration shown in FIG. Also good.
  • the access control method according to the present invention can be realized by the procedure shown in the first and second embodiments.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Storage Device Security (AREA)

Abstract

　階層定義管理部（０１２）は、階層間の順位を記憶する。組織情報管理部（０１３）は、階層要素の対が、階層の組合せごとに示される情報を記憶する。ロール割当管理部（０１１）は、アクセスを許可する条件が特定の階層要素に対応付けられている情報を記憶する。処理受付部（００５）は、ユーザからの、リソースへのアクセスを要求する操作要求を入力する。Ｆ－ＲＢＡＣ部（００６）は、前記ユーザと対応付けられている階層要素を判別し、階層間の順位に基づき、判別した階層要素と対になっている一つ上の階層の階層要素を織情報管理部（０１３）の情報から抽出し、抽出した階層要素と対になっている一つ上の階層の階層要素を抽出する動作を繰り返し、判別した階層要素及び抽出した階層要素とロール割当管理部（０１１）で定義される階層要素とを照合して、アクセス許否を判定する。

Description

アクセス制御装置及びアクセス制御方法及びプログラム
　本発明は、階層構造を用いたアクセス制御に関する。
　クラウドサービスやＳａａＳ（Ｓｏｆｔｗａｒｅ　ａｓ　ａ　Ｓｅｒｖｉｃｅ）を実現するための基盤技術として、一つのアプリケーションプログラム（以下、アプリケーションという）を複数の企業（テナント）で共用させる「マルチテナント管理技術」がある。
　マルチテナント管理技術の目的として、複数企業によるアプリケーション共用によってハードウェア（Ｈ／Ｗ）リソース及びソフトウェア（Ｓ／Ｗ）リソースを削減し、コストを削減することが挙げられる。
　従来技術では、ユーザの属性をアクセス権限と対応付けることにより柔軟なアクセス権限の設定を可能にしている（例えば、特許文献１）。
　特許文献１では、「ユーザ情報表」で、ユーザだけでなくテナント・部門等の属性を管理しており、「アクセス権限割当表」で、アクセス制御を行う権限ごとに、どのような属性をもつユーザがアプリケーションを利用可能かを管理している。
特開２０１２－６９０８７号公報
　マルチテナントアプリケーションでは、新規にシステムを開発するだけでなく、開発コストを削減するために従来単一のテナントで利用していたアプリケーションを最大限有効活用してマルチテナントで利用可能にすることがある。
　また、元々あるビルで利用していたアプリケーションを、サービス範囲を拡大するために他のビルや他のビルに属するテナントも利用可能にすることがある。
　つまり、ビルに属しているあるテナントが、別のビルにも入居したため、ビルを跨ってテナントにアクセス制御を設定する必要がある。
　そのため、ビル、テナント、会社内の総務部、営業部といった組織という順序の階層構造から、ある時点で、テナント、ビル、組織という階層構造に変更する必要が出てくる。
　特許文献１では、履歴管理に関する言及がなされていない上に、組織階層構造に対する言及もなされていない。
　仮に、特許文献１の技術を元に、上記要求を実現しようとする場合、組織階層構造が変更になった場合に、組織階層構造が変更になった時点で設定されているアクセス権限割当を全て見直す必要がある。
　本発明はこのような課題を解決することを主な目的としており、階層構造の定義が変更された場合にも、変更に伴うデータ改修作業の作業量を最小限にとどめることを主な目的とする。
　本発明に係るアクセス制御装置は、
　複数の階層で構成される階層構造における階層間の順位が示される階層順位情報を記憶する階層順位情報記憶部と、
　階層を構成する要素である階層要素の対であって、異なる二つの階層に属する互いに関連する階層要素の対が、階層の組合せごとに示される階層要素情報を記憶する階層要素情報記憶部と、
　アクセスが制限されるアクセス制限リソースへのアクセスを許可する条件であるアクセス許可条件が特定の階層要素に対応付けて示されるアクセス許可条件情報を記憶するアクセス許可条件情報記憶部と、
　いずれかの階層要素と対応付けられているユーザからの、アクセス制限リソースへのアクセスを要求するアクセス要求を受信するアクセス要求受信部と、
　前記ユーザと対応付けられている階層要素を判別するとともに、前記階層順位情報に示される階層間の順位に基づき、判別した階層要素と対になっている一つ上の階層の階層要素又は一つ下の階層の階層要素を前記階層要素情報から抽出し、抽出した階層要素と対になっている一つ上の階層の階層要素又は一つ下の階層の階層要素を前記階層要素情報から抽出する動作を特定の階層に到達するまで繰り返す階層要素抽出部と、
　前記階層要素抽出部により判別された階層要素及び抽出された階層要素と前記アクセス許可条件に示される前記特定の階層要素とを照合して、前記アクセス要求に対して前記アクセス制限リソースへのアクセスを許可するか否かを判定するアクセス許否判定部とを有することを特徴とする。
　本発明では、階層間の順位が示される階層順位情報を記憶し、また、異なる二つの階層に属する互いに関連する階層要素の対が、階層の組合せごとに示される階層要素情報を記憶し、アクセス要求があった時点で、アクセス要求を行ったユーザに対応付けられている階層要素を起点にして階層順位情報と階層要素情報に基づいて階層構造を構築する。
　このように、本発明では、階層間の上下関係が定義されるのみで階層要素間の上下関係は定義されていないので、階層構造に変更があった場合でも階層順位情報の改修ですみ、改修作業の作業量を最小限にとどめることができる。
実施の形態１に係るシステム構成例を示す図。 実施の形態１に係るアクセス制御装置の構成例を示す図。 実施の形態１に係る操作要求の構成例を示す図。 実施の形態１に係るユーザ情報管理部で管理されているユーザ情報の例を示す図。 実施の形態１に係るアクセス権限管理部で管理されているアクセス権限情報の例を示す図。 実施の形態１に係るロール割当管理部で管理されているロール割当情報の例を示す図。 実施の形態１に係る階層定義管理部で管理されている階層定義情報の例を示す図。 実施の形態１に係る組織情報管理部で管理されている情報の例を示す図。 実施の形態１に係る業務ロジック部の構成例を示す図。 実施の形態１に係る業務ロジック情報管理部の構成例を示す図。 実施の形態１に係る処理受付部の動作例を示すフローチャート図。 実施の形態１に係るＦ－ＲＢＡＣ部の動作例を示すフローチャート図。 実施の形態１に係る業務ロジック部の動作例を示すフローチャート図。 実施の形態１に係る階層構造変更要求の例を示す図。 実施の形態１に係るＦ－ＲＢＡＣ部の動作例を示すフローチャート図。 実施の形態１に係る階層定義管理部で管理されている階層順位変更後の階層定義情報の例を示す図。 実施の形態２に係る階層定義管理部で管理されている階層定義情報の例を示す図。 実施の形態２に係る業務ロジック情報管理部の構成例を示す図。 実施の形態１に係るユーザと所属組織と所属ビルと所属テナントとの関係を示す図。 実施の形態１に係るアクセス制御装置のハードウェア構成例を示す図。
　実施の形態１．
　本実施の形態では、様々な利用者に対し同一アプリケーションを共用可能にするために、マルチテナント型アプリケーションでのデータへのアクセス権やアプリケーションの利用権（以下、アクセス権限）を効率よく管理するための構成を説明する。
　より具体的には、本実施の形態では、階層構造の定義が変更された場合にも、変更に伴うデータ改修作業の作業量を最小限にとどめる構成を説明する。
　また、本実施の形態では、保持する操作履歴の情報を最小限にとどめる構成を説明する。
　企業等においては、内部統制の関係から、アプリケーション操作に対する操作履歴を管理し、履歴の追跡を実施する必要がある。
　そのため、過去の時刻における階層構造を再現する必要がある。
　特許文献１の技術では、操作履歴として保持しなければならないデータも膨大になってしまうが、本実施の形態によれば、保持する操作履歴の情報を最小限にすることができる。
　図１は、本実施の形態に係るシステム構成例を示す。
　図１において、端末００１、端末００２は、サービスを利用するテナント企業に配置されている端末装置であり、パーソナルコンピュータ、モバイル端末等を想定している。
　端末００１、端末００２内にはＷｅｂブラウザ００１ａ、００２ａがインストールされている。
　なお、端末００１、００２を操作するユーザは別のテナント企業の従業員を想定している。
　また、同一テナント企業内で複数の端末を設置したり、同一のアプリケーションを３テナント企業以上で利用したりすることも可能である。
　端末０００は、図１に示すシステムを管理するシステム管理者、運用者が利用する端末装置であり、パーソナルコンピュータ、モバイル端末等を想定している。
　端末０００内にはＷｅｂブラウザ０００ａがインストールされている。
　ネットワーク００３は、端末００１、００２がアクセス制御装置００４を利用する際に用いる通信路であり、インターネットおよびＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）であってもよい。
　アクセス制御装置００４は、アクセスが制限されるアクセス制限リソースへのアクセスを許可するか否かを判定する。
　なお、以下では、特定の組織に属するユーザ、特定の属性を有するユーザにのみアクセスが許可される業務ロジック（アプリケーション）をアクセス制限リソースの例として用いる。
　アクセス制御装置００４は、図２に示すように、処理受付部００５、フレキシブルロールベースアクセスコントロール部（Ｆｌｅｘｉｂｌｅ　Ｒｏｌｅ－ｂａｓｅｄ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ部；以下、Ｆ－ＲＢＡＣ部とする）００６、業務ロジック部００７、業務ロジック情報管理部００８、ユーザ情報管理部００９、アクセス権限管理部０１０、ロール割当管理部０１１、階層定義管理部０１２、組織情報管理部０１３を有する。
　アクセス制御装置００４において、処理受付部００５は、端末００１、００２から発信されたリクエストを受信し、後述する処理を実施する。
　処理受付部００５は、例えば、端末００１、００２から、アクセス制限リソースへのアクセスを要求するリクエストである操作要求（アクセス要求）を受信する。
　処理受付部００５は、アクセス要求受信部の例に相当する。
　Ｆ－ＲＢＡＣ部００６は、端末００１、００２のリクエスト内容とアクセス制御装置００４内で管理している情報を元に、アクセス権限の有無を判定する。
　Ｆ－ＲＢＡＣ部００６は、階層要素抽出部、アクセス許否判定部、階層順位変更部の例に相当する。
　業務ロジック部００７は、就業管理や経理処理といった業務用処理を実施する。
　業務ロジック情報管理部００８は、業務ロジック部００７で利用する情報を管理する。
　ユーザ情報管理部００９は、アプリケーション操作が可能なユーザの情報を管理する。
　アクセス権限管理部０１０は、業務ロジックのアクセス権限を管理する。
　ロール割当管理部０１１は、業務ロジックへアクセス可能な組織をアクセス権限情報と組織情報の対応関係によって管理する。
　ロール割当管理部０１１は、アクセス許可条件情報記憶部の例に相当する。
　階層定義管理部０１２は、システムで利用する組織階層構造の定義を管理する。
　階層定義管理部０１２は、階層順位情報記憶部の例に相当する。
　組織情報管理部０１３は、アプリケーションを利用する組織の情報を管理する。
　組織情報管理部０１３は、階層要素情報記憶部の例に相当する。
　なお、図２内の各要素を複数存在させ、冗長構造を持たせることが可能である。
　図３の操作要求２０１は、端末００１、００２から送信されるリクエスト内容の一例である。
　操作要求２０１は、操作要求２０１の発行元のユーザのユーザＩＤ、パスワード等の認証情報、業務ロジック部００７への操作内容、通信を行う上で必要なヘッダ情報を含む。
　なお、本実施の形態ではＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）形式を利用するものとしているが、プロトコルに関してＦＴＰ（Ｆｉｌｅ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）、ＪＭＳ（Ｊａｖａ（登録商標）　Ｍｅｓｓａｇｅ
　Ｓｅｒｖｉｃｅ）等であっても上記内容を持たせることが可能であれば代用可能である。
　操作要求２０１は、通信ヘッダ２０２、認証情報２０３、操作内容２０４を有する。
　通信ヘッダ２０２は、端末００１とアクセス制御装置００４との間で通信を行う上で必要なヘッダ情報であり、リクエスト送信元、リクエスト送信先の情報を有する。
　認証情報２０３は、リクエスト送信元ユーザの認証情報を示し、例としてユーザのユーザＩＤ、パスワードを有する。
　操作内容２０４は、リクエスト送信元ユーザの業務ロジック部００７への操作要求内容を示し、例として業務ロジックの種類、操作内容（データの参照、データの更新等）を有する。
　図４は、ユーザ情報管理部００９で管理されるユーザ情報３０１の例を示す。
　ユーザ情報３０１は、アクセス制御装置００４を利用するユーザの情報を保持しており、ユーザＩＤにより各ユーザを一意に識別可能であるものとする。
　なお、ユーザ情報３０１は、ユーザＩＤ以外に、ユーザ名称や、ユーザの属する組織の組織ＩＤ、ユーザの認証に必要なパスワードを有する。
　図５は、アクセス権限管理部０１０で管理されるアクセス権限情報４０１の例を示す。
　アクセス権限情報４０１は、アクセス制御装置００４で管理する業務ロジック部００７の操作権限範囲やアクセス制御装置００４自体の操作権限範囲の情報を保持している。
　例えば、業務ロジックＡに対する操作可否や、アクセス権限の操作可否が操作可能内容として保持されている。
　なお、操作可否については参照のみ可能等、一部制限をつけることが可能とする。
　図６は、ロール割当管理部０１１で管理されるロール割当情報５０１の例を示す。
　ロール割当情報５０１は、アクセス権限情報４０１と組織情報との対応関係を管理し、どの組織がその操作を実施することが可能かの情報を保持している。
　なお、権限の割当対象は、組織だけでなくビル全体、テナント全体といった設定も可能である。
　さらに、組織の配下（指定した組織の子組織以下も該当する場合）や、直下（指定した組織の子組織は含まず）といった指定も可能とする。
　なお、ロール割当情報はロール自体の情報と、ロールと組織との対応関係を表す情報に分割することも可能である。
　図６に示すように、ロール割当情報５０１には、アクセス制限リソース（テナントＡ業務ロジック、ビルＡ業務ロジック）へのアクセス（操作、参照）を許可する条件であるアクセス許可条件が特定の階層要素（Ｔ００１配下、Ｂ００１配下）に対応付けて示さている。
　なお、Ｔ００１とＢ００１は、図８に示すように、それぞれテナントのＩＤとビルのＩＤである。
　ロール割当情報５０１は、アクセス許可条件情報の例に相当し、ロール割当管理部０１１は、前述したように、アクセス許可条件情報記憶部の例に相当する。
　図７は、階層定義管理部０１２で管理される階層定義情報６０１を示す。
　階層定義情報６０１は、アクセス制御装置００４を利用するビル、テナント、組織等のエンティティ間の順位、及び階層構造が有効である期間を示す有効期限を有する。
　例えば、図７中の階層ＩＤ：ＳＴ００１は、階層構造の頂点にビルを配し、ビルの下にテナント、テナントの下に組織を配する構造を定義している。
　なお、図７では、階層の例としてビル、テナント、組織を挙げているが、例えばビルの上位階層に地域というエンティティを定義したり、テナントの下に支社というエンティティを定義したりすることも可能である。
　図７に示すように、階層定義情報６０１には、階層構造における階層間の順位が示されており、階層順位情報の例に相当する。
　そして、階層定義管理部０１２は、階層順位情報記憶部の例に相当する。
　図８は、組織情報管理部０１３で管理される情報を示す。
　組織情報管理部０１３は、ビル情報７０１、テナント情報７０２、組織情報７０３、ビル・テナント対応情報７０４、テナント・組織対応情報７０５、ビル・組織対応情報７０６を有する。
　ビル情報７０１は、アクセス制御装置００４を利用するビルの情報を保持する。
　各ビルは、ビルＩＤにより識別可能である。
　また、ビルＩＤ以外にビル名称、ビルの所在地といった属性情報を保持することも可能である。
　テナント情報７０２は、アクセス制御装置００４を利用するテナントの情報を保持する。
　各テナントは、テナントＩＤにより識別可能である。
　また、テナントＩＤ以外にテナント名称、テナントの契約内容といった属性情報を保持することも可能である。
　組織情報７０３は、アクセス制御装置００４を利用する組織の情報を保持する。
　各組織は、組織ＩＤにより識別可能である。
　また、組織ＩＤ以外に組織名称、組織における責任者（組織長）といった属性情報を保持することも可能である。
　なお、組織については部の配下に課が置かれるケースのように組織間での階層構造も考えられるため、組織の上位階層に当たる組織（親組織）についても情報として有する。
　ビル・テナント対応情報７０４は、ビル情報７０１で管理するビルと、テナント情報７０２で管理するテナントとの対応関係を示す。
　ビル・テナント対応情報７０４は、ビルＩＤ・テナントＩＤのようにビルとテナントとを一意に特定できる属性を保持している。
　また、ビル・テナントの対応関係に有効期限がある場合は、属性として有効期限を保持する。
　テナント・組織対応情報７０５は、テナント情報７０２で管理するテナントと組織情報７０３で管理する組織との対応関係を示す。
　テナント・組織対応情報７０５は、テナントＩＤ・組織ＩＤのようにテナントと組織とを一意に特定できる属性を保持している。
　また、テナント・組織の対応関係に有効期限がある場合は、属性として有効期限を保持する。
　ビル・組織対応情報７０６は、ビル情報７０１で管理するビルと組織情報７０３で管理する組織との対応関係を示す。
　ビル・組織対応情報７０６は、ビルＩＤ・組織ＩＤのようにビルと組織とを一意に特定できる属性を保持している。
　また、ビル・組織の対応関係に有効期限がある場合は、属性として有効期限を保持する。
　ビル・テナント対応情報７０４、テナント・組織対応情報７０５、ビル・組織対応情報７０６では、階層を構成する要素である階層要素の対であって、異なる二つの階層に属する互いに関連する階層要素の対が、階層の組合せごとに示されている。
　具体的には、ビル階層とテナント階層については、ビル・テナント対応情報７０４において、ビル階層の階層要素であるＢ００１とテナント階層の階層要素であるＴ００１との対、ビル階層の階層要素であるＢ００１とテナント階層の階層要素であるＴ００２との対が記述されている。
　また、テナント階層と組織階層については、テナント・組織対応情報７０５において、テナント階層の階層要素であるＴ００１と組織階層の階層要素であるＯＲＧＴ００１との対、テナント階層の階層要素であるＴ００１と組織階層の階層要素であるＯＲＧＴ００２との対等が記述されている。
　また、ビル階層と組織階層については、ビル・組織対応情報７０６において、ビル階層の階層要素であるＢ００１と組織階層の階層要素であるＯＲＧＴ００１との対、ビル階層の階層要素であるＢ００１と組織階層の階層要素であるＯＲＧＴ００２との対等が記述されている。
　ビル・テナント対応情報７０４、テナント・組織対応情報７０５、ビル・組織対応情報７０６は、階層要素情報の例に相当する。
　そして、組織情報管理部０１３は、前述したように、階層要素情報記憶部の例に相当する。
　図９は、業務ロジック部００７の内部構成を示している。
　業務ロジック部００７は内部に業務ロジック部Ａ８０１、業務ロジック部Ｂ８０２、業務ロジック部Ｃ８０３を有しており、それぞれ担当する業務ロジックが異なる。
　例えば、業務ロジック部Ａ８０１では就業管理、業務ロジック部Ｂ８０２では経理管理、業務ロジック部Ｃ８０３では入退室管理といったように別々の業務を担当する。
　なお、業務ロジック部００７内にあるロジックの数は任意でありアクセス制御装置００４で扱う業務ロジックの増減にあわせて、内部の業務ロジックの数も増減可能とする。
　図１０は、業務ロジック情報管理部００８の内部構成を示す。
　業務ロジック情報管理部００８では、業務ロジックＡ情報管理部９０１、業務ロジックＢ情報管理部９０２、業務ロジックＣ情報管理部９０３を有している。
　それぞれ、業務ロジックＡ情報管理部９０１は業務ロジック部Ａ８０１、業務ロジックＢ情報管理部９０２は業務ロジック部Ｂ８０２、業務ロジックＣ情報管理部９０３は業務ロジック部Ｃ８０３で扱う情報を管理している。
　例えば業務ロジックＡ情報管理部９０１では就業管理ロジックで利用する社員名簿、勤怠記録、出勤日のカレンダー等を有する。
　なお、業務ロジック部００７と同様に内部で持つ情報の数も増減可能である。
　また、各情報管理部で共通に利用する情報がある場合、共用することも可能である。
　次に、アクセス制御装置００４を利用するユーザが自身の端末から業務ロジック操作要求を出す場合の、動作について説明する。
　テナントＡに所属するユーザＡがアクセス制御装置００４内の業務ロジックＡの操作を行う場合、ユーザＡは、端末００１のＷｅｂブラウザ００１ａを用いてアクセス制御装置００４に対し自身の認証情報及び業務ロジックの操作内容を操作要求２０１の形式で要求を出す。
　アクセス制御装置００４では、端末から操作要求を受信した際の、リクエストの管理及びレスポンスの生成を一元的に処理受付部００５で実施する。
　図１１のフローチャートを参照して、処理受付部００５の動作について述べる。
　なお、以下では、図３に示す操作要求２０１が受信された場合を例にして説明を進める。
　図３では、ユーザＩＤ：Ｕ００１のユーザが端末００１を利用して送信した操作要求２０１であって、業務ロジックＡ（業務ＩＤ：Ｌ００１）のデータ参照を要求する操作要求２０１が示されている。
　なお、図１９に示すように、ユーザＡは、組織ＩＤ：ＯＲＧ００１の組織に属し、組織ＩＤ：ＯＲＧ００１の組織は、テナントＩＤ：Ｔ００１のテナントに属し、テナントＩＤ：Ｔ００１のテナントは、ビルＩＤ：Ｂ００１のビルに属している。
　しかしながら、アクセス制御装置００４では、図１９に示すような階層要素間の上下関係が予め定義した情報は保持しておらず、操作要求２０１を受信した際に、後述するように、Ｆ－ＲＢＡＣ部００６が、図７及び図８に示す情報を用いて、階層要素間の上下関係を分析する。
　処理受付部００５は、受信した操作要求２０１から認証情報２０３、操作内容２０４を取得し、認証情報２０３、操作内容２０４をＦ－ＲＢＡＣ部００６に出力し、要求元のユーザの業務ロジックへの操作可否をＦ－ＲＢＡＣ部００６に問い合わせる（Ｓ１０１）。
　次に、処理受付部００５は、Ｆ－ＲＢＡＣ部００６の問い合わせ結果からユーザの操作可否を判定する（Ｓ１０２）。
　Ｓ１０２の結果が操作可能であった場合（Ｓ１０２でＹＥＳ）、処理受付部００５は、操作要求２０１の操作内容２０４を業務ロジック部００７へ受け渡す（Ｓ１０３）。
　そして、処理受付部００５は、業務ロジック部００７への操作要求結果を端末００１ａにレスポンスとして返却する（Ｓ１０４）。
　一方、Ｓ１０２の結果が操作不可であった場合（Ｓ１０２でＮＯ）は、処理受付部００５は、操作不可であることをレスポンスとして端末００１ａにレスポンスとして返却する（Ｓ１０５）。
　次に、図１２のフローチャートを参照して、Ｆ－ＲＢＡＣ部００６のユーザの操作可否の判定処理の動作を説明する。
　Ｆ－ＲＢＡＣ部００６は、処理受付部００５から受信した認証情報２０３からユーザＩＤ及びパスワード等の認証に必要な情報を取得する（Ｓ２０１）。
　次に、Ｆ－ＲＢＡＣ部００６は、ユーザ情報管理部００９に対し、認証情報２０３から取得したユーザＩＤを持つユーザの情報を問い合わせる（Ｓ２０２）。
　次に、Ｆ－ＲＢＡＣ部００６は、ユーザ認証に成功したかどうかを検証する（Ｓ２０３）。
　具体的には、Ｆ－ＲＢＡＣ部００６は以下の手順により検証する。
　Ｆ－ＲＢＡＣ部００６は、ユーザ情報管理部００９のレスポンスより、Ｓ２０１で取得したユーザＩＤを持つユーザが存在するかどうか確認する。
　該当するユーザが存在しない場合は認証不可とする。
　また、該当するユーザが存在する場合、認証情報２０３から取得したパスワードが、ユーザ情報管理部００９で管理されているパスワードと一致するかどうかを判定する。
　パスワードが一致した場合は認証成功、一致しない場合は認証失敗とする。
　Ｆ－ＲＢＡＣ部００６は、Ｓ２０３において認証成功であった場合（Ｓ２０３でＹＥＳ）は、処理受付部００５から受信した操作内容２０４からユーザの操作対象となる業務ロジックの業務ＩＤを取得し、アクセス権限管理部０１０に当該業務ＩＤのロジックが紐付いているアクセス権限の一覧を取得する（Ｓ２０４）。
　Ｆ－ＲＢＡＣ部００６は、図３の操作内容２０４であれば、業務ＩＤ：Ｌ００１に基づき、図５の権限ＩＤ：Ａ００１のレコードと、権限ＩＤ：Ａ００２のレコードを取得する。
　次に、Ｆ－ＲＢＡＣ部００６は、階層定義管理部０１２から現時点における階層順位の情報を取得する（Ｓ２０５）。
　図７の例では、「ビル＞テナント＞組織」が記述された階層順位の情報を取得する。
　Ｆ－ＲＢＡＣ部００６は、ユーザ情報管理部００９より取得したユーザ情報からユーザの所属する組織の組織ＩＤの情報を元に、組織情報管理部０１３からユーザの所属する組織の情報を取得する（Ｓ２０６）。
　図３の操作要求２０１の場合は、ユーザＩＤ：Ｕ００１であるため、図４から、対象となるユーザＡが所属する組織は、組織ＩＤ：ＯＲＧ００１の組織である。
　次に、Ｆ－ＲＢＡＣ部００６は、階層定義管理部０１２より取得した階層順位の情報と、組織情報管理部０１３から取得した組織の情報とを元に、より上位の階層に属するビル、テナント、組織の情報の取得を、上位階層の組織が存在しなくなるまで繰り返す（Ｓ２０７）。
　Ｓ２０５で取得した階層順位が「ビル＞テナント＞組織」であるため、Ｆ－ＲＢＡＣ部００６は、まず、組織の一つ上の階層であるテナント階層で組織ＩＤ：ＯＲＧ００１と対になっている階層要素を探す。
　具体的には、Ｆ－ＲＢＡＣ部００６は、図８のテナント・組織対応情報７０５を検索して、組織ＩＤ：ＯＲＧ００１と対になっているテナントＩＤ：Ｔ００１を抽出する。
　次に、Ｆ－ＲＢＡＣ部００６は、階層順位「ビル＞テナント＞組織」より、テナントの１つの上の階層であるビル階層でテナントＩＤ：Ｔ００１と対になっている階層要素を探す。
　具体的には、Ｆ－ＲＢＡＣ部００６は、図８のビル・テナント対応情報７０４を検索して、テナントＩＤ：Ｔ００１と対になっているビルＩＤ：Ｂ００１を抽出する。
　次に、Ｆ－ＲＢＡＣ部００６は、ロール割当管理部０１１から、Ｓ２０４で取得したアクセス権限とＳ２０６、Ｓ２０７で取得した組織、テナント、ビルと合致するロール割当情報を取得する（Ｓ２０８）。
　図６の例では、Ｆ－ＲＢＡＣ部００６は、ロール割当ＩＤ：Ｒ００１のレコードと、ロール割当ＩＤ：Ｒ００２のレコードを取得する。
　次に、Ｆ－ＲＢＡＣ部００６は、Ｓ２０８において取得したロール割当が存在するかどうか判定する（Ｓ２０９）。
　なお、組織については上位階層から順に割当があるかどうか確認を行う。
　Ｆ－ＲＢＡＣ部００６は、Ｓ２０９で割当が存在していた場合、認証成功と判断し処理受付部００５に対して成功のレスポンスを返す（Ｓ２１０）。
　図３の操作要求２０１では、データ参照が要求されているため、図６の「ロール名称：ビル業務ロジックＡ参照のみ可能」に合致し、Ｆ－ＲＢＡＣ部００６は、処理受付部００５に成功のレスポンスを返す。
　Ｓ２０３で認証失敗もしくはＳ２０９でロールの割当が存在しなかった場合は、Ｆ－ＲＢＡＣ部００６は、認証失敗と判断し、処理受付部００５に失敗のレスポンスを返す（Ｓ２１１）。
　図１３のフローチャートを参照して、業務ロジック部００７の動作を説明する。
　業務ロジック部００７は、処理受付部００５から受信した操作内容２０４から、業務ロジック部００７内のどの業務ロジック内の操作が指定されているかを判定し、内部の業務ロジックへ操作内容を受け渡す（Ｓ３０１）。
　なお、以下では、図９の業務ロジック部Ａ８０１が指定されたものとして動作を説明する。
　業務ロジック部Ａ８０１は、Ｓ３０１で業務ロジック部００７より受信した操作内容を元に業務ロジック情報管理部００８内の業務ロジックＡ情報管理部９０１で扱う情報を参照・更新しながら操作を行う（Ｓ３０２）。
　業務ロジック部Ａ８０１は、Ｓ３０２を実施した結果について業務ロジック部００７経由で処理受付部００５へレスポンスを返却する（Ｓ３０３）。
　次に、アクセス制御装置の管理者（以下、システムユーザ）が、アクセス制御装置００４の階層構造を変更する際の動作について説明する。
　図１４は、アクセス制御装置００４の階層構造を変更する際に、システムユーザが端末０００を用いてアクセス制御装置００４に対して送信するリクエストである階層構造変更要求の一例を示す。
　アクセス制御装置００４を管理するシステムユーザは、端末０００のＷｅｂブラウザ０００ａを用いてアクセス制御装置００４に階層構造変更要求１３０１を送信する。
　階層構造変更要求１３０１は、図７の階層定義情報６０１内の階層順位を変更することを要求するリクエストである。
　アクセス制御装置００４では、処理受付部００５が階層構造変更要求１３０１を受信し、Ｆ－ＲＢＡＣ部００６がシステムユーザの認証を実施した後に、Ｆ－ＲＢＡＣ部００６は階層定義情報６０１内の階層順位を変更する。
　なお、処理受付部００５の動作、Ｆ－ＲＢＡＣ部００６の認証までの動作は前述のＳ１０１～Ｓ１０５、Ｓ２０１～Ｓ２０３と同様である。
　階層順位の変更後、処理受付部００５が端末０００に対してレスポンスを返却する。
　図１５のフローチャートを参照して、階層構造定義変更の際のＦ－ＲＢＡＣ部００６の動作を説明する。
　Ｆ－ＲＢＡＣ部００６は、処理受付部００５より受信した階層構造変更要求１３０１から、階層構造の変更情報が記載されている操作内容１３０４を取得する（Ｓ４０１）。
　次に、Ｆ－ＲＢＡＣ部００６は、Ｓ４０１で取得した操作内容１３０４について、階層定義管理部０１２へ階層構造定義の変更要求を出す（Ｓ４０２）。
　階層定義管理部０１２は、Ｓ４０２で受け取った要求に沿って、例えば図７の階層定義情報６０１を図１６の階層定義情報６０２に変更する。
　図１６では、新たな階層順位として「テナント＞ビル＞組織」が定義されている。
　また、変更前の階層順位「ビル＞テナント＞組織」は、有効期限とともに階層定義情報６０２に保持される。
　Ｆ－ＲＢＡＣ部００６は、階層定義管理部０１２の処理が完了した後に、処理受付部００５に対し操作結果を返却する（Ｓ４０３）。
　また、以上の手順により階層定義情報の階層順位が変更された後に操作要求２０１を受信した場合は、Ｆ－ＲＢＡＣ部００６は、変更後の階層順位に基づいて図１２の処理を行う。
　以上の動作により、システム内で管理する組織の階層構造が時間の経過とともに変更する場合でも、有効期限を持つ階層構造定義を持つことにより、階層構造の定義の変更に合わせて、階層構造定義のみを変更することが可能である。
　また、階層構造が有効期限を持つことにより、指定した時刻での階層構造を再現することが可能である。
　また、アクセス権限の割当情報の更新が不要となりシステムで管理するデータの変更を最小限にとどめ、かつシステムで保持する過去のログ情報も含めたデータ量を最小限にとどめることができる。
　なお、図１１の説明では、上位階層に向かう方向で階層要素を検索した（Ｓ２０７）が、これに代えて、下位階層に向かう方向で階層要素を検索するようにしてもよい。
　以上、本実施の形態では、
　ロールと、複数の個人及び組織とロールとの対応関係を示すロール割当情報を管理するロール割当管理部と、
　組織階層の構造及び階層構造の有効期間を管理する階層定義管理部と、
　ロール割当管理部と階層定義部が持つ階層構造定義を元に組織階層構造を解釈しながら上位から順に階層を辿っていき、ロール割当対象とシステムを利用するユーザの所属する組織階層位置とを比較し、システムで管理する情報へのアクセス権限やシステムの利用権限が保持されているかどうかを判定するアクセス制御部を備えたテナントアクセス制御装置、方式、及びプログラムを説明した。
　また、本実施の形態では、
　組織の階層構造を任意時刻に変更する際に、階層構造の有効期限を変更することで、システム内の階層構造の変更を実現するアクセス制御部を備えたテナントアクセス制御装置、方式、及びプログラムを説明した。
　また、本実施の形態では、
　システム内のアプリケーションごとのアクセス可否を管理するアクセス権限管理部を備え、
　個人がシステム内のアプリケーションを利用する際に、アクセス権限管理部のアクセス可否の情報を元にアクセス可否を判断するアクセス制御部を備えた、テナントアクセス制御装置、方式、及びプログラムを説明した。
　実施の形態２．
　本実施の形態では、実施の形態１との相違点を述べる。
　以下で説明している以外の動作、構成は、実施の形態１と同じである。
　図１７は、本実施の形態に係る階層定義管理部０１２の階層定義情報６１０を示す。
　図１７の階層定義情報６１０では、図７の階層定義情報６０１と比較して、属性として業務ＩＤのように業務ロジックに対応する情報が付加されている。
　本実施の形態では、図１７に示すように、業務ロジックごとに階層構造を変更できるようにしている。
　つまり、本実施の形態に係る階層定義情報６１０では、業務ロジック（アクセス制限リソース）ごとに、階層順位が定義されている。
　図１８は、本実施の形態に係る業務ロジック情報管理部００８の業務ロジック定義９１０を示す。
　図１０と異なり、図１８では、業務ロジックごとに業務ＩＤを割り振っている。
　ユーザが端末を用いて業務ロジックの操作要求２０１を送信した場合に、図１２のＳ２０５において、階層順位を取得する際に、Ｆ－ＲＢＡＣ部００６は、操作要求２０１中から業務ＩＤを取得し、取得した業務ＩＤに対応する階層順位を取得し、取得した階層順位を、以後のアクセス権限有無の判定に用いる。
　このような構成にすることで、実施の形態１と同様の効果が得られると同時に、アプリケーションごとに用いる階層構造定義を切り替えることができる。
　このため、様々なアプリケーションを一つのシステムに集約しつつ、共通のロジックが利用できるため、集約度が高くなる効果が得られる。
　以上、本実施の形態では、
　システム内のアプリケーションごとの組織の階層構造を持つ階層定義管理部を備え、
　個人がシステム内のアプリケーションを利用する際に階層定義管理部によりアプリケーションごとに組織階層構造を切り替えてアクセス可否を判断するアクセス制御部を備えたテナントアクセス制御装置、方式、及びプログラムを説明した。
　最後に、実施の形態１及び２に示したアクセス制御装置００４のハードウェア構成例を図２０を参照して説明する。
　アクセス制御装置００４はコンピュータであり、アクセス制御装置００４の各要素をプログラムで実現することができる。
　アクセス制御装置００４のハードウェア構成としては、バスに、演算装置１９０１、外部記憶装置１９０２、主記憶装置１９０３、通信装置１９０４、入出力装置１９０５が接続されている。
　演算装置１９０１は、プログラムを実行するＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）である。
　外部記憶装置１９０２は、例えばＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）やフラッシュメモリ、ハードディスク装置である。
　主記憶装置１９０３は、ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）である。
　図２に示した「～管理部」は、外部記憶装置１９０２又は主記憶装置１９０３により実現される。
　通信装置１９０４は、処理受付部００５の物理層に対応する。
　入出力装置１９０５は、例えばマウス、キーボード、ディスプレイ装置等である。
　プログラムは、通常は外部記憶装置１９０２に記憶されており、主記憶装置１９０３にロードされた状態で、順次演算装置１９０１に読み込まれ、実行される。
　プログラムは、図２に示す「～部」（但し、「～管理部」を除く。以下も同様）として説明している機能を実現するプログラムである。
　更に、外部記憶装置１９０２にはオペレーティングシステム（ＯＳ）も記憶されており、ＯＳの少なくとも一部が主記憶装置１９０３にロードされ、演算装置１９０１はＯＳを実行しながら、図１に示す「～部」の機能を実現するプログラムを実行する。
　また、実施の形態１及び２の説明において、「～の判断」、「～の判定」、「～の判別」、「～の抽出」、「～の照合」、「～の取得」、「～の設定」、「～の登録」、「～の選択」、「～の生成」、「～の受信」、「～の出力」等として説明している処理の結果を示す情報やデータや信号値や変数値が主記憶装置１９０３にファイルとして記憶されている。
　また、暗号鍵・復号鍵や乱数値やパラメータが、主記憶装置１９０３にファイルとして記憶されてもよい。
　なお、図２０の構成は、あくまでもアクセス制御装置００４のハードウェア構成の一例を示すものであり、アクセス制御装置００４のハードウェア構成は図２０に記載の構成に限らず、他の構成であってもよい。
　また、実施の形態１及び２に示す手順により、本発明に係るアクセス制御方法を実現可能である。
　０００　端末、００１　端末、００２　端末、００３　ネットワーク、００４　アクセス制御装置、００５　処理受付部、００６　Ｆ－ＲＢＡＣ部、００７　業務ロジック部、００８　業務ロジック情報管理部、００９　ユーザ情報管理部、０１０　アクセス権限管理部、０１１　ロール割当管理部、０１２　階層定義管理部、０１３　組織情報管理部。

Claims (8)

  1. 　複数の階層で構成される階層構造における階層間の順位が示される階層順位情報を記憶する階層順位情報記憶部と、
    　階層を構成する要素である階層要素の対であって、異なる二つの階層に属する互いに関連する階層要素の対が、階層の組合せごとに示される階層要素情報を記憶する階層要素情報記憶部と、
    　アクセスが制限されるアクセス制限リソースへのアクセスを許可する条件であるアクセス許可条件が特定の階層要素に対応付けて示されるアクセス許可条件情報を記憶するアクセス許可条件情報記憶部と、
    　いずれかの階層要素と対応付けられているユーザからの、アクセス制限リソースへのアクセスを要求するアクセス要求を受信するアクセス要求受信部と、
    　前記ユーザと対応付けられている階層要素を判別するとともに、前記階層順位情報に示される階層間の順位に基づき、判別した階層要素と対になっている一つ上の階層の階層要素又は一つ下の階層の階層要素を前記階層要素情報から抽出し、抽出した階層要素と対になっている一つ上の階層の階層要素又は一つ下の階層の階層要素を前記階層要素情報から抽出する動作を特定の階層に到達するまで繰り返す階層要素抽出部と、
    　前記階層要素抽出部により判別された階層要素及び抽出された階層要素と前記アクセス許可条件に示される前記特定の階層要素とを照合して、前記アクセス要求に対して前記アクセス制限リソースへのアクセスを許可するか否かを判定するアクセス許否判定部とを有することを特徴とするアクセス制御装置。
  2. 　前記階層要素情報記憶部は、
    　異なる二つの階層に属する上下関係にある階層要素の対が、いずれの階層要素が上位でいずれの階層要素が下位であるかの定義を含まずに、階層の組合せごとに示される階層要素情報を記憶していることを特徴とする請求項１に記載のアクセス制御装置。
  3. 　前記アクセス制御装置は、更に、
    　前記階層順位情報の階層間の順位を変更する階層順位変更部を有し、
    　前記アクセス許否判定部は、
    　前記階層順位変更部により前記階層順位情報の階層間の順位が変更された後に受信されたアクセス要求に対しては、変更後の階層間の順位に基づき、階層要素を抽出することを特徴とする請求項１に記載のアクセス制御装置。
  4. 　前記階層順位変更部は、
    　前記階層順位情報の階層間の順位を変更する場合に、変更前の階層間の順位を、有効期限とともに前記階層順位情報記憶部に保持させておくことを特徴とする請求項３に記載のアクセス制御装置。
  5. 　前記アクセス許可条件情報記憶部は、
    　アクセス許可条件が特定のユーザに対応付けて示されるアクセス許可条件情報を記憶し、
    　前記アクセス許否判定部は、
    　前記アクセス要求の送信元のユーザが、前記アクセス許可条件情報に示される前記特定のユーザに該当するか否かを判断して、前記アクセス要求に対して前記アクセス制限リソースへのアクセスを許可するか否かを判定することを特徴とする請求項１に記載のアクセス制御装置。
  6. 　前記アクセス制御装置は、
    　複数のアクセス制限リソースについてのアクセス制御を行っており、
    　前記階層順位情報記憶部は、
    　各アクセス制限リソースに対して、階層順位情報を記憶しており、
    　前記アクセス要求受信部は、
    　いずれかのアクセス制限リソースへのアクセスを要求するアクセス要求を受信し、
    　前記アクセス許否判定部は、
    　前記アクセス要求でアクセスが要求されているアクセス制限リソースに対する階層順位情報に示される階層間の順位に基づき、階層要素を抽出することを特徴とする請求項１に記載のアクセス制御装置。
  7. 　複数の階層で構成される階層構造における階層間の順位が示される階層順位情報を、コンピュータが記憶領域から読み出し、
    　階層を構成する要素である階層要素の対であって、異なる二つの階層に属する互いに関連する階層要素の対が、階層の組合せごとに示される階層要素情報を、前記コンピュータが前記記憶領域から読み出し、
    　アクセスが制限されるアクセス制限リソースへのアクセスを許可する条件であるアクセス許可条件が特定の階層要素に対応付けて示されるアクセス許可条件情報を、前記コンピュータが前記記憶領域から読み出し、
    　いずれかの階層要素と対応付けられているユーザからの、アクセス制限リソースへのアクセスを要求するアクセス要求を前記コンピュータが受信し、
    　前記コンピュータが、前記ユーザと対応付けられている階層要素を判別するとともに、前記階層順位情報に示される階層間の順位に基づき、判別した階層要素と対になっている一つ上の階層の階層要素又は一つ下の階層の階層要素を前記階層要素情報から抽出し、抽出した階層要素と対になっている一つ上の階層の階層要素又は一つ下の階層の階層要素を前記階層要素情報から抽出する動作を特定の階層に到達するまで繰り返し、
    　前記コンピュータが、判別された階層要素及び抽出された階層要素と前記アクセス許可条件に示される前記特定の階層要素とを照合して、前記アクセス要求に対して前記アクセス制限リソースへのアクセスを許可するか否かを判定することを特徴とするアクセス制御方法。
  8. 　複数の階層で構成される階層構造における階層間の順位が示される階層順位情報を、記憶領域から読み出す階層順位情報読み出し処理と、
    　階層を構成する要素である階層要素の対であって、異なる二つの階層に属する互いに関連する階層要素の対が、階層の組合せごとに示される階層要素情報を、前記記憶領域から読み出す階層要素情報読み出し処理と、
    　アクセスが制限されるアクセス制限リソースへのアクセスを許可する条件であるアクセス許可条件が特定の階層要素に対応付けて示されるアクセス許可条件情報を、前記記憶領域から読み出すアクセス許可条件情報読み出し処理と、
    　いずれかの階層要素と対応付けられているユーザからの、アクセス制限リソースへのアクセスを要求するアクセス要求を受信するアクセス要求受信処理と、
    　前記ユーザと対応付けられている階層要素を判別するとともに、前記階層順位情報に示される階層間の順位に基づき、判別した階層要素と対になっている一つ上の階層の階層要素又は一つ下の階層の階層要素を前記階層要素情報から抽出し、抽出した階層要素と対になっている一つ上の階層の階層要素又は一つ下の階層の階層要素を前記階層要素情報から抽出する動作を特定の階層に到達するまで繰り返す階層要素抽出処理と、
    　前記階層要素抽出処理により判別された階層要素及び抽出された階層要素と前記アクセス許可条件に示される前記特定の階層要素とを照合して、前記アクセス要求に対して前記アクセス制限リソースへのアクセスを許可するか否かを判定するアクセス許否判定処理とをコンピュータに実行させることを特徴とするプログラム。
PCT/JP2014/052851 2013-05-23 2014-02-07 アクセス制御装置及びアクセス制御方法及びプログラム WO2014188743A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2015518114A JP5980421B2 (ja) 2013-05-23 2014-02-07 アクセス制御装置及びアクセス制御方法及びプログラム
CN201480029654.5A CN105229662B (zh) 2013-05-23 2014-02-07 访问控制装置和访问控制方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2013-108925 2013-05-23
JP2013108925 2013-05-23

Publications (1)

Publication Number Publication Date
WO2014188743A1 true WO2014188743A1 (ja) 2014-11-27

Family

ID=51933310

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2014/052851 WO2014188743A1 (ja) 2013-05-23 2014-02-07 アクセス制御装置及びアクセス制御方法及びプログラム

Country Status (3)

Country Link
JP (1) JP5980421B2 (ja)
CN (1) CN105229662B (ja)
WO (1) WO2014188743A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019204350A (ja) * 2018-05-24 2019-11-28 清水建設株式会社 設備利用状況公開システム、設備利用状況公開方法およびプログラム

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111988173B (zh) * 2020-08-19 2023-09-12 北京安瑞志远科技有限公司 基于多层父子结构租户的租户管理平台和租户管理方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007172154A (ja) * 2005-12-20 2007-07-05 Mitsubishi Space Software Kk アクセス制御装置及びアクセス制御方法及びアクセス制御プログラム
JP2008210376A (ja) * 2007-02-01 2008-09-11 Hitachi Software Eng Co Ltd 組織階層定義システム、グループ階層の構成方法、及び組織階層の表示方法
JP2011076569A (ja) * 2009-10-02 2011-04-14 Ariel Networks Co Ltd アクセス権管理装置およびアクセス権管理プログラム
US20110213789A1 (en) * 2010-02-26 2011-09-01 Salesforce.Com, Inc. System, method and computer program product for determining an amount of access to data, based on a role

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3956149B2 (ja) * 2005-12-19 2007-08-08 インターナショナル・ビジネス・マシーンズ・コーポレーション リソース・コンテンツのアクセス制御方法、システム、およびプログラム
CN103038778A (zh) * 2010-06-23 2013-04-10 惠普发展公司，有限责任合伙企业 授权控制

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007172154A (ja) * 2005-12-20 2007-07-05 Mitsubishi Space Software Kk アクセス制御装置及びアクセス制御方法及びアクセス制御プログラム
JP2008210376A (ja) * 2007-02-01 2008-09-11 Hitachi Software Eng Co Ltd 組織階層定義システム、グループ階層の構成方法、及び組織階層の表示方法
JP2011076569A (ja) * 2009-10-02 2011-04-14 Ariel Networks Co Ltd アクセス権管理装置およびアクセス権管理プログラム
US20110213789A1 (en) * 2010-02-26 2011-09-01 Salesforce.Com, Inc. System, method and computer program product for determining an amount of access to data, based on a role

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019204350A (ja) * 2018-05-24 2019-11-28 清水建設株式会社 設備利用状況公開システム、設備利用状況公開方法およびプログラム
WO2019225097A1 (ja) * 2018-05-24 2019-11-28 清水建設株式会社 設備利用状況公開システム、設備利用状況公開方法およびプログラム
JP7107745B2 (ja) 2018-05-24 2022-07-27 清水建設株式会社 設備利用状況公開システム、設備利用状況公開方法およびプログラム

Also Published As

Publication number Publication date
JP5980421B2 (ja) 2016-08-31
CN105229662A (zh) 2016-01-06
JPWO2014188743A1 (ja) 2017-02-23
CN105229662B (zh) 2018-02-02

Similar Documents

Publication Publication Date Title
US11750609B2 (en) Dynamic computing resource access authorization
US10855790B2 (en) Servicing asset requests via proxy
US10826844B2 (en) Transmission of tags and policies with data objects
CN115335827B (zh) 用于实现基于角色的访问控制聚类机器学习模型执行模块的方法和装置
Ananthakrishnan et al. Globus platform‐as‐a‐service for collaborative science applications
CN105324750B (zh) 开发环境系统、开发环境装置以及开发环境提供方法
US11539707B2 (en) Dynamic security policy consolidation
US20220058285A1 (en) Systems and methods for computer-implemented data trusts
JP5623271B2 (ja) 情報処理装置、権限管理方法、プログラムおよび記録媒体
Chard et al. Globus Nexus: A platform-as-a-service provider of research identity, profile, and group management
EP2715971B1 (en) Automating cloud service reconnections
EP3669296B1 (en) Compliance boundaries for multi-tenant cloud environment
CN113094055A (zh) 维持对于在部署到云计算环境期间的受限数据的控制
KR102295593B1 (ko) 인증 문서를 자동으로 생성하는 기법
CN116940931B (zh) 使用谓词的字符串自动推理的分布式分解
Jin et al. Role and attribute based collaborative administration of intra-tenant cloud iaas
EP3513316B1 (en) Personalized search environment
US11233787B2 (en) Automated on call and ad hoc access to restricted resources
JP6927282B2 (ja) 情報処理装置、端末装置、プログラム及び情報処理システム
US11556238B1 (en) Implementation of architecture document via infrastructure as code
US20220046002A1 (en) System and method for authentication as a service
JP5980421B2 (ja) アクセス制御装置及びアクセス制御方法及びプログラム
US20170235924A1 (en) System and Network for Controlling Content and Accessibility
US20240168972A1 (en) Data Distribution and Access within a Multi-Zone Computing Platform
WO2015045048A1 (ja) アプリデータ記憶領域生成方法，アプリデータ記憶領域生成装置，及びアプリデータ記憶領域生成プログラム

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201480029654.5

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14800483

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2015518114

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: IDP00201507441

Country of ref document: ID

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14800483

Country of ref document: EP

Kind code of ref document: A1