WO2022244179A1 - ポリシー生成装置、ポリシー生成方法及びプログラムが格納された非一時的なコンピュータ可読媒体 - Google Patents

ポリシー生成装置、ポリシー生成方法及びプログラムが格納された非一時的なコンピュータ可読媒体 Download PDF

Info

Publication number
WO2022244179A1
WO2022244179A1 PCT/JP2021/019149 JP2021019149W WO2022244179A1 WO 2022244179 A1 WO2022244179 A1 WO 2022244179A1 JP 2021019149 W JP2021019149 W JP 2021019149W WO 2022244179 A1 WO2022244179 A1 WO 2022244179A1
Authority
WO
WIPO (PCT)
Prior art keywords
policy
score
access
data
access control
Prior art date
Application number
PCT/JP2021/019149
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 US18/290,363 priority Critical patent/US20240259375A1/en
Priority to PCT/JP2021/019149 priority patent/WO2022244179A1/ja
Priority to JP2023522112A priority patent/JPWO2022244179A5/ja
Publication of WO2022244179A1 publication Critical patent/WO2022244179A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • 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/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general

Definitions

  • the present invention relates to a policy generation device, a policy generation method, and a non-transitory computer-readable medium storing a program.
  • Access control in the network is important for maintaining network security and necessary access.
  • Cited Document 1 there is an access control system that generates an access control policy using the relationship between an object group and an object, etc., and generates a different access control list for each access control implementation means that controls access to an object. disclosed.
  • this access control system even if objects with different combinations of actions, such as OSs (Operating Systems) with different file systems, coexist, and many types of access control enforcement means are connected at the same time, the same method and system as before can be used.
  • the purpose is to describe access control policies in , and to enforce access control collectively.
  • FIG. 1 is a block diagram showing an example of a policy generation device.
  • the policy generation device 10 has an acquisition unit 11 and a policy generation unit 12 .
  • Each part (each means) of the policy generation device 10 is controlled by a controller (not shown). Each part will be described below.
  • Elements related to access control indicate arbitrary information related to access control. Specific examples of elements include arbitrary IDs and attributes can be included. Specific examples of the various data of the access source include the IP address of the access source, the user ID, the device ID, the application ID, the user location, and the OS used by the device of the access source. Not limited.
  • elements related to access control include not only single elements but also arbitrarily combined different elements. Examples of combinations include a combination of elements having different attributes (user ID x user location x resource ID), and a combination of elements having the same IP address attribute such as (source IP address x destination IP address). is assumed, but the combination is not limited to this. Also, the number of elements to be combined may be any number equal to or greater than two. Hereinafter, such elements are also referred to as "entities”.
  • Relational data indicating the relationship between multiple elements indicates the relationship between different single elements, the relationship between a combination of elements and a single element, or the relationship between combinations of different elements.
  • Relational data is data in which, for example, inclusion relationships and logical relationships are defined in binary.
  • “score data” is data with scores set as real numbers.
  • the “score based on the access risk perspective” is the amount of loss and the likelihood of fraud if the access is fraudulent or erroneous.
  • the "point-of-view score” is the amount of profit obtained by the access and the probability of obtaining the profit, that is, a parameter that acts in the direction of permitting access. Therefore, both parameters have opposite values as attributes. For example, a negative value may be set as the “score based on the viewpoint of access risk” and a positive value may be set as the “score based on the viewpoint of access needs”.
  • 0 or a value close to 0 may be set as the “score based on the viewpoint of access risk”, and a value with a large absolute value may be set as the “score based on the viewpoint of access needs”.
  • Specific examples of the "relationship data" and "score data” described above will be described later in the second embodiment.
  • the policy generation unit 12 uses the relationship data and score data acquired by the acquisition unit 11 to create access control policies. By using this policy, access control becomes possible by automatically regenerating the policy even in dynamic cases such as changes in relational data or score data.
  • FIG. 2 is a flowchart showing an example of typical processing of the policy generation device 10, and the processing of the policy generation device 10 will be explained with this flowchart.
  • the acquisition unit 11 of the policy generation device 10 obtains relational data indicating the relationship between a plurality of elements related to access control, a score based on the viewpoint of access risk, and a score based on the viewpoint of access needs.
  • Score data in which at least one score is defined is acquired (step S11; acquisition step).
  • the policy generator 12 uses the relationship data and the score data to generate an access control policy (step S12; policy generation step).
  • the policy generation device 10 can automatically generate a policy using score data and relationship data indicating the relationship between multiple elements. This eliminates the need for human beings to generate the policies themselves, making it possible to reduce human time and labor in policy generation. Moreover, by reflecting at least one of access risks and needs in the score, the policy generation device 10 can quantitatively evaluate the trade-off between profit and loss associated with each access. Therefore, the policy generation device 10 can maintain the security of the system by determining access control so as to reduce the loss if the access is illegal or erroneous while maintaining the profit obtained by the access. can.
  • Embodiment 2 Embodiment 2 of the present disclosure will be described below with reference to the drawings.
  • Embodiment 2 discloses a specific example of the policy generation device 10 described in Embodiment 1.
  • FIG. 1 An illustration of the policy generation device 10 described in Embodiment 1.
  • FIG. 3 is a block diagram showing an example of a policy generation system 20 on a Zero Trust network.
  • the policy generation system 20 includes an input unit 21 , a data store 22 , a policy engine 23 , a policy presentation unit 24 and a policy enforcer 25 . The details of each unit will be described below.
  • the input unit 21 is an interface such as a keyboard, buttons, and mouse for the administrator of the policy generation system 20 to input data.
  • the data store 22 is a storage (storage unit) in which data is stored, and the policy generation system 20 stores automatically collected data in the data store 22 .
  • the input unit 21 and the data store 22 correspond to the acquisition unit 11 of the first embodiment, and provide the policy engine 23 with relationship data indicating relationships between multiple elements, scores based on the risk of access, Outputs score data with defined scores based on access need perspectives. At this time, at least one of the relationship data and score data manually input by the administrator is input from the input unit 21, and the relationship data and score data automatically collected by the policy generation system 20 are input from the data store 22. At least one will be entered.
  • the administrator can define and input needs or risk scores in the score data from the input unit 21 .
  • the administrator can set the user's needs for accessing a specific resource (access needs).
  • an administrator may classify users into groups and set access needs to specific resources for each group.
  • the administrator classifies user IDs into either the "R&D” group or the "accounting" group. Then, for the "R&D” group, the access needs to the resource IDs of the experimental environment and experimental data files are set to "1", and the access needs to the resource IDs of the other files are set to "0".
  • the administrator sets the access need to the resource ID of the settlement information file to "1", and sets the access need to the resource ID of the other files to "0".
  • “1" indicates that there is an access need
  • "0" indicates that no access need is defined.
  • Access to resources with access needs is more preferably permitted by policy than access to resources with unspecified access needs. Therefore, the administrator sets the score when there is an access need higher than the score when the access need is not defined.
  • the administrator can also input a score for a specific resource in terms of various data of other access sources in addition to the user ID or instead of the user ID.
  • Examples of other access source data include IP address, device ID, application ID, user location, and OS used by the access source device.
  • an administrator may set the need for a particular user to access a particular resource from a particular location in a similar manner as described above.
  • the administrator can also set the need to access specific resources for any one or more entities related to access control. Specific examples of entities are as described in the first embodiment. For example, an administrator may set a risk score for a particular resource at a particular time of day (or time of day).
  • the administrator may set a score as a risk to indicate the magnitude of the damage caused by inappropriate access to a specific resource. For example, the administrator can set the absolute value of the score higher as the importance of the resource increases.
  • the policy generation system 20 automatically sets the score to a default value (eg, 0) for the score that the administrator did not enter. Even if the score becomes the default value, the policy generated by the policy engine 23 does not uniformly approve or deny access. This point will be described later.
  • a default value eg, 0
  • the data store 22 stores mechanically collected data regarding the policy generation system 20 .
  • This data includes relationship data and score data.
  • This data may also be used for threat intelligence, asset databases, inventory, operational needs, authorization, resource sensitivity, authentication servers, auditing software or sensors, IDS (Intrusion Detection System), CDM (Continuous Diagnostics and Mitigation), SIEM (Security Information and Event Management), NWDAF (Network Data Analytics Function), Activity Logs, Identity Management, PKI (Public Key Infrastructure), Industry Compliance, Risk Analysis Systems, and one or more of the various other sources available.
  • IDS Intrusion Detection System
  • CDM Continuous Diagnostics and Mitigation
  • SIEM Security Information and Event Management
  • NWDAF Network Data Analytics Function
  • Activity Logs Identity Management
  • PKI Public Key Infrastructure
  • Industry Compliance Risk Analysis Systems
  • the audit software is, for example, software for at least one of security and asset management.
  • the sensor is, for example, at least one of a GPS (Global Positioning System) sensor, a motion sensor, and a temperature sensor, and may actually be installed in a building.
  • GPS Global Positioning System
  • Threat information provided by a security agency relates, for example, to suspected threat IP addresses, device IDs, applications, processes, signatures or sources of communications, user or network behavior, resource IDs, resource locations, and the like.
  • the vulnerability information provided by the security agency relates to, for example, device information such as OS and manufacturer, application information such as protocol, encryption or authentication method, version, or any combination thereof.
  • Vulnerability information discovered by system threat analysis relates to, for example, device IDs, IP addresses, applications, command IDs associated with specific operations, and communication paths.
  • this vulnerability information is based on a combination of accessing a specific device with a specific port, a combination of using a specific application on a specific OS, or a specific operation history such as a change in access authority. , personal information, or combined information for accessing specific resources such as IoT (Internet of Things) devices. These pieces of information make a negative contribution to access authorization.
  • IoT Internet of Things
  • the authentication server as the authentication history, the authentication method of the user, device, application, etc., the number of authentication failures, the elapsed time since the previous authentication succeeded, the behavior and authentication time at the time of authentication, the location of the authenticated user etc. may be stored in the data store 22 . For example, a score is set indicating that the longer the elapsed time since the previous authentication was successful, the higher the risk. Further, from the IDS, data such as subnet addresses, IP addresses, ports, applications, devices, and suspicious behavior/signatures in the network may be stored in the data store 22 .
  • Data on various risks may be stored in the data store 22 from the risk analysis system.
  • the data store 22 may store access needs based on communication history between specific users as needs-related scores.
  • the data store 22 may also store a trust score as a risk score that indicates the degree to which a user, device, application, IP address or other entity identity, or any combination thereof, can be trusted. This trust score is calculated using, for example, anomaly detection by an anomaly detection engine, authentication history of successful authentication by a secure authentication method, etc. It may be done in a way that does not If an entity's behavior is security questionable, that entity will be given a low trust score.
  • (5) is the score for the source IP address and the destination IP address
  • (6) is the score for the source user, time zone and resource. Note that (6) is a score for the same entity as (1) to (4), but is set as a different type of score to distinguish it from (1) to (4).
  • the data store 22 may store the output value as it is. This is because the policy engine 23, which will be described later, can use the output value as it is as the score.
  • the score value is a fixed binary value such as "-1" when there is a threat and "0" when there is no threat. It may be set as a value.
  • the score indicating the threat level may be set as a value of three or more levels such as 0, -1, -2, -3, .
  • the score may be normalized as necessary.
  • the numerical value setting or normalization processing described above may be performed when storing in the data store 22, or may be performed by the policy engine 23 when generating a policy.
  • the data store 22 stores mechanically collected relationship data indicating the current relationship.
  • Related data includes, for example, which application or port accesses resources such as certain data, which device the user is using, which IP address is assigned to the device, topology between devices, and communication frequency. and the like.
  • the data store 22 can obtain this related information from an authentication server, asset database, inventory, or the like.
  • FIG. 4 is an image diagram showing an example of an algorithm by which the policy engine 23 generates a policy.
  • the black circles in g in in the upper part of FIG. 4 indicate scores for each condition c, and the black circles in g out indicate each subject t.
  • the former specifies that the score represents the risk of the device by a label ⁇ representing the meaning of the score, and the score is represented by a first-order tensor.
  • FIG. 4 shows, as an example, an action score a 1′, 1′ for target (IP1, port 1) and an action score a 4′, 1′ for target (IP4, port 1).
  • the action score a for the objects (IP1 to IPL) is expressed by the following formula.
  • (14) (14) on the right side of equation (15) indicates that the input function g in is input with each component x i of the score represented by a tensor of dimension ⁇ .
  • w ⁇ on the right side of equation (14) is a weight parameter in dimension ⁇ , which is determined by policy engine 23 learning.
  • the dimension ⁇ indicates the type of score, as described above.
  • the score in the score data is expressed in tensor format. This form is scalable to any dimension ⁇ , so it can represent combinations of any number of entities.
  • the algorithm can set 0 as the score if the score is not defined for at least one of risk or need.
  • the policy engine 23 outputs the generated policy to the policy presentation unit 24 and the policy enforcer 25 .
  • the policy engine 23 may output the policy in the form of ACL (Access Control List) or access proxy, for example, but the output form is not limited to these.
  • the policy presentation unit 24 is an interface that presents the policy generated by the policy engine 23 to the administrator, and has a display unit such as a display.
  • the policy enforcer 25 actually controls access on the network according to the generated policy.
  • Score (User), Score (Device), Score (Application), Score (IP), Score (Port), Score (Device, Application) are automatically updated by referring to the information source as the score. , Score(SrcIP, DstIP). These scores are generated by the data store 22 from authentication history, anomaly detection history, vulnerability information, communication history, and the like. A score defined by a person using the input unit 21 is Score(User, Resource). This score indicates the user's need to access the resource.
  • the dimension ⁇ has values from 1 to 8 in this example, and the weight parameter w ⁇ of the policy generation algorithm is set as shown in Equation (18) below.
  • the data store 22 acquires True/False for all entity combinations between user IDs and devices, between resources and devices, between devices and IP addresses, and between resources and ports as relationship data. However, the data store 22 may acquire True and define False for other data not acquired.
  • Zero trust networks can be applied, for example, in local 5G (5th Generation) used by companies and local governments.
  • a zero trust network calculates a security score for access from all devices and determines whether or not to allow that access. As a result, even if a threat invades the network, it is possible to prevent the threat from accessing important files and prevent the spread of damage. In addition, the zero trust network does not simply block access from outside the network, but allows reliable access by making a determination based on the above-described score calculation. Therefore, both network safety and availability can be achieved.
  • the network's policy engine determines actions such as permission or denial of access by integrating various information based on the perspectives of risk, needs, trust, etc. In order to determine actions with high accuracy, it is necessary to generate detailed policies. In addition, even if the network environment (multiple elements related to access control) changes, it is preferable that the generated policy be dynamic so that the environmental change can be accurately reflected in the policy. Therefore, the policy to be generated becomes complicated, and the problem is how to define or generate such a policy.
  • model function in the second embodiment may be set in multiple layers.
  • An example of the model function in this case is as follows. (22) g 1 in equation (22) corresponds to g out in equation (14). Also, the weight parameter w in Equation (22) is a non-negative value.
  • Embodiment 2 there are two types of thresholds th, but one type, or three or more types of thresholds th may be set.
  • the policy engine 23 may use a model function different from that described above, in which case the policy engine 23 may learn a parameter different from the weight parameter w ⁇ .
  • policy generation device 11 acquisition unit 12 policy generation units 20, 30 policy generation system 21 input unit 22 data store 23 policy engine 24 policy presentation unit 25 policy enforcer 31 change unit

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)

Abstract

本開示の一実施の形態にかかるポリシー生成装置（１０）は、アクセス制御に関係する複数の要素について、複数の要素間の関係を示す関係データと、アクセスのリスクの観点に基づくスコア及びアクセスのニーズの観点に基づくスコアの少なくとも１つが定義されたスコアデータと、を取得する取得部（１１）と、関係データ及びスコアデータを用いて、アクセス制御のポリシーを生成するポリシー生成部（１２）を備える。これにより、人間がアクセス制御のポリシーを定義する必要がなくなるため、人間の時間や労力を削減することができる。

Description

ポリシー生成装置、ポリシー生成方法及びプログラムが格納された非一時的なコンピュータ可読媒体
　本発明はポリシー生成装置、ポリシー生成方法及びプログラムが格納された非一時的なコンピュータ可読媒体に関する。
　ネットワークにおけるアクセス制御は、ネットワークのセキュリティ及び必要なアクセスの維持にとって重要である。
　例えば、引用文献１には、オブジェクトグループとオブジェクトとの関係等を用いてアクセス制御ポリシーを生成し、オブジェクトへのアクセスを制御するアクセス制御実施手段毎に異なるアクセス制御リストを生成するアクセス制御システムが開示されている。このアクセス制御システムは、ファイルシステムが異なるＯＳ（Operating System）等、アクションとの組み合わせの異なるオブジェクトが混在し、同時に多種類のアクセス制御実施手段が接続されていても、これまでと同じ方法やシステムでアクセス制御ポリシーを記述し、アクセス制御を一括して実施することを目的としている。
特許第５４２４０６２号公報
　この開示は、人間の時間や労力を削減することが可能なポリシー生成装置、ポリシー生成方法及びプログラムが格納された非一時的なコンピュータ可読媒体を提供するものである。
　一実施の形態にかかるポリシー生成装置は、アクセス制御に関連する複数の要素について、複数の要素間の関係を示す関係データと、アクセスのリスクの観点に基づくスコア及びアクセスのニーズの観点に基づくスコアの少なくとも１つが定義されたスコアデータと、を取得する取得手段と、関係データ及びスコアデータを用いて、アクセス制御のポリシーを生成するポリシー生成手段を備える。
　一実施の形態にかかるポリシー生成方法は、アクセス制御に関連する複数の要素について、複数の要素間の関係を示す関係データと、アクセスのリスクの観点に基づくスコア及びアクセスのニーズの観点に基づくスコアの少なくとも１つが定義されたスコアデータと、を取得し、関係データ及びスコアデータを用いて、アクセス制御のポリシーを生成することをコンピュータが実行するものである。
　一実施の形態にかかる非一時的なコンピュータ可読媒体は、アクセス制御に関連する複数の要素について、複数の要素間の関係を示す関係データと、アクセスのリスクの観点に基づくスコア及びアクセスのニーズの観点に基づくスコアの少なくとも１つが定義されたスコアデータと、を取得し、関係データ及びスコアデータを用いて、アクセス制御のポリシーを生成することをコンピュータに実行させるプログラムが格納されたものである。
　この開示により、人間の時間や労力を削減することが可能なポリシー生成装置、ポリシー生成方法及びプログラムが格納された非一時的なコンピュータ可読媒体を提供することができる。
実施の形態１にかかるポリシー生成装置の一例を示すブロック図である。 実施の形態１にかかるポリシー生成装置の処理の一例を示すフローチャートである。 実施の形態２にかかるポリシー生成システムの一例を示すブロック図である。 実施の形態２にかかるポリシーを生成するアルゴリズムの一例を示す概略図である。 実施の形態２にかかるポリシーを示すテーブルの一例を示す概略図である。 実施の形態３にかかるポリシー生成システムの一例を示すブロック図である。 各実施の形態にかかる装置のハードウェア構成の一例を示すブロック図である。
　実施の形態１
　以下、図面を参照してこの開示の実施の形態１について説明する。
　図１は、ポリシー生成装置の一例を示すブロック図である。ポリシー生成装置１０は、取得部１１及びポリシー生成部１２を備える。ポリシー生成装置１０の各部（各手段）は、不図示の制御部（コントローラ）により制御される。以下、各部について説明する。
　取得部１１は、アクセス制御に関連する複数の要素について、複数の要素間の関係を示す関係データと、アクセスのリスクの観点に基づくスコア及びアクセスのニーズの観点に基づくスコアの少なくとも１つが定義されたスコアデータを取得する。なお、取得部１１は、ポリシー生成装置１０の内部又は外部から情報を取得するインタフェースで構成される。取得の処理は、取得部１１が自動的に実行しても良いし、手動での入力によってなされても良い。
　「アクセス制御に関連する要素」は、アクセス制御に関連する任意の情報を示すものである。要素の具体例としては、アクセス元の各種データ、接続ポート、送信先ＩＰ（Internet Protocol）アドレス、アクセスの時間帯（又は時刻）、アクセス対象のリソースＩＤなど、アクセス制御に関連する任意のＩＤや属性が含まれ得る。なお、アクセス元の各種データの具体例としては、アクセス元のＩＰアドレス、ユーザＩＤ、デバイスＩＤ、アプリケーションＩＤ、ユーザ位置、アクセス元の機器が使用しているＯＳといったものが含まれるが、これらに限られない。
　また、「アクセス制御に関連する要素」として、要素単独だけでなく、異なる要素を任意に組み合わせたものも含まれる。組み合わせの例として、（ユーザＩＤ×ユーザ位置×リソースＩＤ）という異なる属性を有する要素の組み合わせや、（送信元ＩＰアドレス×送信先ＩＰアドレス）のような、ＩＰアドレスという同じ属性を有する要素の組み合わせが想定されるが、組み合わせはこれに限られない。また、組み合わせる対象の要素の数は、２以上の任意の数であって良い。以下、このような要素を、「エンティティ」とも称する。
　そして、「複数の要素間の関係を示す関係データ」は、異なる単独の要素同士の関係、要素の組み合わせと単独の要素との関係、又は異なる要素の組み合わせ同士の関係を示す。関係データは、例えば、包含関係や論理関係がバイナリで定義されたものである。
　また、「スコアデータ」は、実数値としてのスコアが設定されたデータである。「アクセスのリスクの観点に基づくスコア」は、そのアクセスが不正や誤りであった場合の損失の量や不正の生じやすさ、つまりアクセスを否認する方向に働くパラメータであり、「アクセスのニーズの観点に基づくスコア」は、そのアクセスによって得られる利益の量や利益が得られる確度、つまりアクセスを許可する方向に働くパラメータである。そのため、両者のパラメータは、属性として逆の値を有する。例えば、「アクセスのリスクの観点に基づくスコア」としてマイナスの値が設定され、「アクセスのニーズの観点に基づくスコア」としてプラスの値が設定されても良い。別の例として、「アクセスのリスクの観点に基づくスコア」として０又は０に近い値が設定され、「アクセスのニーズの観点に基づくスコア」として絶対値の大きな値が設定されても良い。以上に示した「関係データ」及び「スコアデータ」の具体例については、実施の形態２で後述する。
　ポリシー生成部１２は、取得部１１が取得した関係データ及びスコアデータを用いて、アクセス制御のポリシーを生成する。このポリシーを用いることにより、関係データ又はスコアデータに変更が生じるような動的な場合でも、ポリシーを自動的に再生成することによりアクセス制御が可能となる。
　図２は、ポリシー生成装置１０の代表的な処理の一例を示したフローチャートであり、このフローチャートによって、ポリシー生成装置１０の処理が説明される。まず、ポリシー生成装置１０の取得部１１は、アクセス制御に関連する複数の要素について、複数の要素間の関係を示す関係データと、アクセスのリスクの観点に基づくスコア及びアクセスのニーズの観点に基づくスコアの少なくとも１つが定義されたスコアデータを取得する（ステップＳ１１；取得ステップ）。次に、ポリシー生成部１２は、関係データ及びスコアデータを用いて、アクセス制御のポリシーを生成する（ステップＳ１２；ポリシー生成ステップ）。
　以上のようにして、ポリシー生成装置１０は、複数の要素間の関係を示す関係データと、スコアデータとを用いて、ポリシーを自動的に生成することができる。そのため、人間がポリシー自体を生成する必要がなくなり、ポリシー生成の際における人間の時間や労力を削減することが可能となる。また、アクセスのリスクあるいはニーズの少なくとも１つがスコアに反映されることで、ポリシー生成装置１０は、それぞれのアクセスに伴う利益と損失とのトレードオフを定量的に評価することができる。そのため、ポリシー生成装置１０は、アクセスによって得られる利益を保ちつつ、アクセスが不正や誤りであった場合の損失を小さくするようにアクセスの制御を決定することで、システムのセキュリティを維持することができる。
　実施の形態２
　以下、図面を参照してこの開示の実施の形態２について説明する。実施の形態２では、実施の形態１にて説明したポリシー生成装置１０の具体例を開示する。　
　図３は、ゼロトラストネットワーク上におけるポリシー生成システム２０の一例を示すブロック図である。ポリシー生成システム２０は、入力部２１、データストア２２、ポリシーエンジン２３、ポリシー提示部２４及びポリシーエンフォーサ２５を備える。以下、各部の詳細について説明する。
　入力部２１は、キーボード、ボタン、マウス等、ポリシー生成システム２０の管理者がデータを入力するためのインタフェースである。データストア２２は、データが格納されたストレージ（記憶部）であり、ポリシー生成システム２０は自動的に収集したデータをデータストア２２に格納する。入力部２１及びデータストア２２は、実施の形態１の取得部１１に対応するものであり、ポリシーエンジン２３に、複数の要素間の関係を示す関係データと、アクセスのリスクの観点に基づくスコア及びアクセスのニーズの観点に基づくスコアが定義されたスコアデータを出力する。このとき、入力部２１からは、管理者が手動で入力する関係データ、スコアデータの少なくともいずれかが入力され、データストア２２からは、ポリシー生成システム２０が自動で収集した関係データ、スコアデータの少なくともいずれかが入力されることになる。
　管理者は、入力部２１から、スコアデータにおけるニーズ又はリスクのスコアを定義し、入力することができる。例えば、管理者は、アクセス元である特定のユーザについて、そのユーザが特定のリソースにアクセスするニーズ（アクセスニーズ）を設定することができる。詳細には、管理者は、複数のユーザを複数のグループに分類し、各グループの特定のリソースへのアクセスニーズを設定しても良い。一例として、管理者は、ユーザＩＤを「Ｒ＆Ｄ」グループと「経理」グループのいずれかに分類する。そして、「Ｒ＆Ｄ」グループについて、実験環境及び実験データのファイルのリソースＩＤへのアクセスニーズを「１」と設定し、その他のファイルのリソースＩＤへのアクセスニーズを「０」と設定する。また、管理者は、「経理」グループについて、決算情報のファイルのリソースＩＤへのアクセスニーズを「１」と設定し、その他のファイルのリソースＩＤへのアクセスニーズを「０」と設定する。ここで「１」は、アクセスニーズがあることを示し、「０」は、アクセスニーズが定められないことを示す。アクセスニーズがあるリソースについてのアクセスについては、アクセスニーズが定められないリソースについてのアクセスと比較して、ポリシーで許可することがより好ましい。したがって、管理者は、アクセスニーズがある場合のスコアを、アクセスニーズが定められない場合のスコアよりも高く設定する。
　また、管理者は、特定のリソースについて、ユーザＩＤに加えて、又はユーザＩＤに代えて、その他のアクセス元の各種データの観点からスコアを入力することもできる。その他のアクセス元の各種データの例は、ＩＰアドレス、デバイスＩＤ、アプリケーションＩＤ、ユーザ位置、アクセス元の機器が使用しているＯＳである。例えば、管理者は、特定のユーザについて、特定の場所から特定のリソースにアクセスするニーズを、上述と同様に設定しても良い。
　さらに、管理者は、アクセス制御に関連する任意の１又は複数のエンティティについて、特定のリソースにアクセスするニーズを設定することも可能である。エンティティの具体例は、実施の形態１で説明した通りである。例えば、管理者は、特定のリソースの特定の時間帯（又は時刻）におけるリスクスコアを設定しても良い。
　さらに、管理者は、特定のリソースについて、３種類以上のスコアを設定しても良い。例えば、あるユーザＡが、時間帯１２：００－１５：００にリソースαにアクセスするニーズがある場合、管理者はスコアを次の通り設定する。
Score(User=A, Time=12:00-15:00, Resource=α)=+1 　　　　　　　　　 　・・・（１）
また、ニーズを特に定めない場合は、スコアは次の通り設定される。
Score(User=A, Time=12:00-15:00, Resource=α)=0 　　　　　　　　　　　・・・（２）
ニーズが低い場合は、スコアは次の通り設定される。
Score(User=A, Time=12:00-15:00, Resource=α)=-1　　　　　　　　　　　・・・（３）
逆に、ニーズが非常に高い場合は、管理者はスコアを次の通り設定する。
Score(User=A, Time=12:00-15:00, Resource=α)=10　　　　　　　　　　  ・・・（４）
このようにして、管理者は、特定のリソースの総合的なアクセスニーズを設定することができる。
　また、管理者は、特定のリソースについて、仮に不適切なアクセスが行われた場合の被害の大きさを、リスクとしてスコアで設定しても良い。例えば、管理者は、リソースの重要度が大きくなるほど、スコアの絶対値を大きく設定することができる。
　なお、管理者が入力しなかったスコアについては、ポリシー生成システム２０は、スコアを自動的にデフォルト値（例えば０）とする。スコアがデフォルト値となった場合でも、ポリシーエンジン２３が生成したポリシーにおいて、一律にアクセスの認可又は否認はされない。この点については後述する。
　一方、データストア２２には、ポリシー生成システム２０に関して機械的に収集されたデータが格納される。このデータは、関係データ及びスコアデータを含む。また、このデータは、脅威インテリジェンス、アセットデータベース、インベントリ、運用ニーズ、承認、リソースの感度、認証サーバ、監査ソフトウェア又はセンサ、ＩＤＳ（Intrusion Detection System）、ＣＤＭ（Continuous Diagnostics and Mitigation）、ＳＩＥＭ（Security Information and Event Management）、ＮＷＤＡＦ（Network Data Analytics Function）、活動ログ、ＩＤマネジメント、ＰＫＩ（Public Key Infrastructure）、インダストリーコンプライアンス、リスク分析システム、その他利用可能な様々な１又は複数の情報源に関するデータである。これらの情報源は、ゼロトラストネットワーク上に位置しても良いし、ゼロトラストネットワーク外に位置していても良い。また、監査ソフトウェア又はセンサは、デバイス上に設けられていても良い。
　なお、監査ソフトウェアは、例えばセキュリティ又はアセット管理の少なくともいずれかについてのソフトウェアである。センサは、例えばＧＰＳ（Global Positioning System）センサ、人感センサ又は温度センサの少なくともいずれかであり、実際には建物に設けられていても良い。
　脅威インテリジェンスに関しては、セキュリティ機関が提供する脅威情報及び脆弱性情報、また、システムの脅威分析により発見された脆弱性情報に関するデータが用いられても良い。セキュリティ機関が提供する脅威情報は、例えば、脅威が疑われるＩＰアドレス、デバイスＩＤ、アプリケーション、プロセス、通信のシグネチャ又は製造元、ユーザ又はネットワークの挙動、リソースＩＤ、リソースの場所等に関する。セキュリティ機関が提供する脆弱性情報は、例えば、ＯＳや製造元等のデバイス情報、プロトコル、暗号化又は認証方式、バージョン等のアプリケーション情報、又はそれらの任意の組み合わせ等に関する。システムの脅威分析により発見された脆弱性情報は、例えば、デバイスＩＤ、ＩＰアドレス、アプリケーション、特定の操作に伴うコマンドのＩＤや通信経路に関する。また、この脆弱性情報は、特定のデバイスに特定のポートでアクセスするという組み合わせ、特定のＯＳで特定のアプリケーションを利用するという組み合わせ、又は、アクセス権限変更のような特定の操作履歴のもとで、個人情報又はＩｏＴ（Internet of Things）機器といった特定のリソースにアクセスするという組み合わせの情報等についても含んでいても良い。これらの情報は、アクセスの認可についてマイナスの寄与を生じさせるものである。
　また、認証サーバからは、認証履歴として、ユーザ、デバイス、アプリケーションなどの認証方式、認証の失敗回数、前回の認証における成功からの経過時間、認証時の挙動や認証時刻、認証がなされたユーザ位置等のデータがデータストア２２に格納されても良い。例えば、前回の認証における成功からの経過時間が長いほど、リスクが高いことを示すスコアが設定される。また、ＩＤＳからは、ネットワークにおけるサブネットアドレス、ＩＰアドレス、ポート、アプリケーション、デバイスなどの怪しい挙動・シグネチャ等のデータがデータストア２２に格納されても良い。
　リスク分析システムからは、各種のリスクに関するデータがデータストア２２に格納されても良い。さらに、データストア２２には、ニーズに関するスコアとして、特定のユーザ間の通信履歴によるアクセスニーズが格納されても良い。また、データストア２２には、リスクスコアとして、ユーザ、デバイス、アプリケーション、ＩＰアドレス若しくはその他のエンティティのＩＤ、又はそれらの任意の組み合わせ等が信頼できる度合いを示す信頼スコアが格納されても良い。この信頼スコアは、例えば異常検知エンジンにおける異常検知や、安全な認証方式で認証に成功した認証履歴等を用いて算出されたものであり、この算出自体は、ゼロトラストネットワークのトラストエンジン等、図示しない手段でなされても良い。あるエンティティの挙動がセキュリティ上疑わしいものである場合には、そのエンティティには低い信頼スコアがつけられることになる。
　以下に、具体的なスコアの数値を列挙する。例えば、アクセス元とアクセス先の間の通信履歴から判断したニーズスコアとして、以下の値が設定される。
Score(SrcIP=192.168.1.10, DstIP=192.168.1.1)=+0.5　　　　　　　　　　・・・（５）
Score_2(User=B, Time=12:00-15:00, Resource=β)=+1.5　　　　　 　 　　・・・（６）
（５）は、送信元のＩＰアドレスと送信先のＩＰアドレスに関するスコアであり、（６）は、送信元のユーザ、時間帯及びリソースに関するスコアである。なお、（６）は、（１）～（４）と同じエンティティに関するスコアであるが、（１）～（４）と区別するために、異なる種類のスコアとして設定されている。
　その他、送信元の機器のＯＳと送信元のブラウザに関するスコアとして、次のようなものが設定されても良い。
Score(OS=***.ver.19.01, Application=***)=-1　　　　　 　　　　　 　　・・・（７）
さらに、ユーザに関するスコアとして、次のようなものが設定されても良い。
Score(User=C)=-2　　　　　　　　　　　　　　　　　　　　　　　　 　　・・・（８）
　なお、例えば情報源からの出力が異常度のような実数の場合、データストア２２はその出力値をそのまま格納しても良い。後述のポリシーエンジン２３は、その出力値をそのままスコアとして利用することができるからである。また、情報源からの出力が脅威の有無のような離散的な情報である場合、脅威がある場合が「－１」、ない場合が「０」のように、スコアの値が２値の固定値として設定されても良い。あるいは、脅威レベルに応じて、その脅威レベルを示すスコアが０，－１，－２，－３，・・・のように３段階以上の値として設定されても良い。また、スコアには、必要に応じて正規化処理がなされても良い。以上に示した数値の設定又は正規化処理は、データストア２２に格納する際になされても良いし、ポリシーエンジン２３がポリシー生成の処理の際に実行しても良い。
　また、データストア２２には、機械的に収集された、現在の関係を示す関係データが格納されている。関係データは、例えば、あるデータ等のリソースに対してどのアプリケーション又はポートがアクセスするか、ユーザがどのデバイスを使っており、デバイスにどのＩＰアドレスが割り当てられているか、デバイス間のトポロジー、通信頻度等を示すデータである。
　以下に、関係データの具体例を列挙する。例えば、ユーザＡがデバイス１を使っているが、デバイス２は使っていない場合、関係データは次の通りになる。
relation((User=A),(Device=1))=True, 　
relation((User=A),(Device=2))=False　　　　　　　　　　　　　　　　　・・・（９）
また、リソースrにアクセスするために、ポート１０００を使用し、ポート２０００は使用されない場合、関係データは次の通りになる。
relation((Resource=r),(Port=1000))=True, 
relation((Resource=r),(Port=2000))=False　　　　　　　　　　　　　 ・・・（１０）
また、ユーザＡと、ユーザＡ及びリソースαとの組に関する組み合わせの間の包含関係について、関係データの例は次の通りになる。
relation((User=A, Resource=α), (Resource=α))=True, 
relation((User=A, Resource=α), (Resource=β))=False　　　　　　　 ・・・（１１）
以上と同様に、Ｔｒｕｅ又はＦａｌｓｅにより、全ての関係性が表される。データストア２２は、これらの関係情報を、認証サーバやアセットデータベース、インベントリ等から取得することができる。
　また、上記に示した関係データを用いることで、ポリシー生成システム２０は、新たな関係データを算出することができる。例えば、アクセス元ユーザがＡ、アクセス先リソースがｒで、ＡはＩＰアドレスとして１９２．１６８．１．１０を使っており、リソースｒがＩＰアドレス１９２．１６８．１．１に位置する場合、新しい関係データが次のように算出できる。
relation((User=A, Resource=r),(SrcIP=192.168.1.10, DstIP=192.168.1.1))=True,
relation((User=A, Resource=r),(SrcIP=192.168.1.10, DstIP=192.168.1.2))=False
   ・・・（１２）
　以上のようにして、データストア２２は、任意のエンティティについてのスコアデータ及び関係データを取得することができる。なお、設定されなかったスコアについては、入力部２１の場合と同様に、ポリシー生成システム２０は、スコアを自動的にデフォルト値（例えば０）とする。
　ポリシーエンジン２３は、実施の形態１のポリシー生成部１２に対応し、入力部２１及びデータストア２２から出力されたスコアデータ及び関係データを用いて、ポリシー生成アルゴリズムに基づき、認可アルゴリズムとしてのポリシーを生成する。ここで、あるアクセスに関して、そのアクセス元及びアクセス先のエンティティであるＩＰアドレス、ポートといったアクセス制御の対象を対象ｔとし、上述のスコアデータ及び関係データを各対象ｔのアクセス制御の仕方を決めるための条件ｃと設定する。この場合、ポリシーは、各対象ｔに対するアクセスの認可、承認待ち、否認といったアクセス制御の仕方の一覧である。ポリシーは、次のようなモデル関数fθにより算出されるアクションスコアと、具体的なアクセス制御の仕方（アクション）とを対応付けることで決定されるものである。
fθ (t,c)=a　　　　　　　　　　　　　　　　　　　　　　　　　　    ・・・（１３）
条件ｃには、上述の通り、管理者が定義したスコアデータが含まれている。
　なお、適切なモデル関数fθを生成するためには、リスクが上がった場合、又はニーズが下がった場合に、管理者の意図を反映して、アクセス制御のアクションを厳しくするという必要条件が存在する。
　ポリシーエンジン２３は、前記必要条件を満たすため、スコアに対して単調（Monotonic）なモデル関数fθを生成する。モデル関数fθが単調であり、ポリシーが設定するアクションが全順序集合であることにより、実数値で定義されるスコアデータの各スコアに対し、アクションが順序同型となる。単調となる関数の例として、ここでは非負の数による重み付き和が用いられた関数を定義して説明するが、関数はこれに限られない。これにより、ニーズが下がった場合又はリスクが上がった場合に、アクションがアクセスを許可しない方向に変化することから、上述の必要条件は満たされる。
　図４は、ポリシーエンジン２３がポリシーを生成するアルゴリズムの一例を示すイメージ図である。図４上部のｇｉｎにおける黒丸は各条件ｃに関するスコア、ｇｏｕｔにおける黒丸は、各対象ｔを示す。ｇｉｎの左側は、各デバイスｉ（ｉ＝１～デバイス数）のリスク（当該デバイスが不正にアクセスされることの危険性、信頼の低さ）スコアを示し、ｇｉｎの右側は、２個のエンティティの組み合わせである(ユーザｉ，リソースｊ）のニーズスコアを示す。前者は、スコアの意味を表すラベルγによって、当該スコアがデバイスのリスクを表すことを特定し、当該スコアは一階テンソルで表現される。後者は、スコアの意味を表すラベルγによって、ユーザがリソースへアクセスするニーズを当該スコアが表すことを特定し、当該スコアは二階テンソルで表現される。つまり、γは、あるスコアにおけるエンティティの個数を示すとともに、スコアがどのようなものであるか、その種類を示している。
　なお、図４においては、一階テンソルの一部の成分が＋１の値を有し、二階テンソルの一部の成分が０の値を有することが示されている。この０の値は、上述の通り、リスク又はニーズの少なくともいずれかについてスコアが定義されない場合に設定される値である。また、脅威が存在するなど、アクセスにリスクが生じるような場合には、スコアの成分はマイナスの値となる。
　また、図４のｇｏｕｔの黒丸は、詳細には、各対象ｔに対してどのようなアクセス制御の仕方（アクション）を行うかを示すスコアである、アクションスコアａの出力を示す。図４には、例として、対象 （ＩＰ１，ポート１）のアクションスコアａ１’，１’と、対象 （ＩＰ４，ポート１）のアクションスコアａ４’，１’が示されている。
　図４にて、ｇｉｎの黒丸とｇｏｕｔの黒丸の関連性を示すのがモデル関数fθであり、ｇｉｎとｇｏｕｔの間の矢印の有無は、関係データによって示される関係を表す。さらに、ｇｉｎとｇｏｕｔとの矢印間の結びつきの度合いを示す重みｗγは、上述の各条件ｃに関するスコアの意味を表すラベルγ毎に、ポリシーエンジン２３が設定する。例えば、γ＝２が、ユーザがリソースへアクセスするニーズを表す場合、重みｗγ=2は、（（ＩＰ，ポート），（ユーザ，リソース））の組み合わせで示される四階テンソルで表現される。重みｗγは、例えば、ラベルγによって表されるリスク又はニーズのスコアが、不正なアクセスによって引き起こされる損失又はアクセスの認可によって得られる利益に寄与する度合いの推定値である。
　以上に基づくと、対象（ＩＰ１～ＩＰＬ）に関するアクションスコアａは、次の式で表される。
Figure JPOXMLDOC01-appb-M000001
 ・・・（１４）
（１４）式の右辺における
Figure JPOXMLDOC01-appb-M000002
 ・・・（１５）
は、入力関数ｇｉｎに、次元γのテンソルで表されたスコアの各成分ｘｉが入力されることを示す。また、（１４）式右辺におけるｒγは、次元γにおけるエンティティ同士の関係を示し、
Figure JPOXMLDOC01-appb-M000003
 ・・・（１６）
のように設定される。ｒ＝０はエンティティ同士が無関係であることを示し、ｒ＝１はエンティティ同士が関係を有することを示す。さらに、（１４）式の右辺におけるｗγは、次元γにおける重みパラメータであり、ポリシーエンジン２３が学習をすることにより決定される。次元γは、上述の通り、スコアの種類を示す。
　（１４）式の左辺は、ポリシー計算の結果得られたアクションスコアａであり、ポリシーエンジン２３はアクションスコアａと、１種類以上の閾値ｔｈとの大小関係により、ある対象に対しての離散化されたアクションを決定する。一例として、アクションスコアがａｉであり、ａｉが０以上１以下の値を取り得る値であって、アクションがアクセスの認可（Accept）、承認待ち（Wait）、否認（Drop）の３種類を取り得る場合、ポリシーエンジン２３は、アクションを次のように決定する。
Figure JPOXMLDOC01-appb-M000004
 ・・・（１７）
（１７）式において、認可と承認待ちとを分ける閾値ｔｈは２／３であり、承認待ちと否認とを分ける閾値ｔｈは１／３である。このように、ポリシーエンジン２３は、アクションスコアが小さい値となるほど、アクセスを許可しない方向にアクションを決定する。
　以上に示したアルゴリズムでは、スコアデータにおけるスコアをテンソル形式で表現している。この形式は、任意の次元γに対して拡張性を有するため、任意の個数のエンティティの組み合わせを表現することができる。
　また、リスク又はニーズの少なくともいずれかについてスコアが定義されない場合に、アルゴリズムは、スコアとして０を設定することができる。
　さらに、（１４）式で示す通り、モデル関数fθは単調な関数である。かつ、アルゴリズムでは、アクションスコアが減少するほど、適用されるアクションがアクセスを認めないような閾値ｔｈが設定される。
　また、ポリシーエンジン２３は、入力部２１及びデータストア２２からのデータに基づいて条件ｃを特定した上で、その条件下で様々な対象ｔに対するアクションを列挙して生成することができる。そのため、ポリシーエンジン２３は、ポリシーエンフォースメント時（及びポリシー生成時）において、ポリシーエンフォーサ２５とのアクセスデータの送受信をする必要がない。入力部２１及びデータストア２２からのデータが時間的に変化する場合であっても、ポリシーエンジン２３は、当該変化に応じてアクションスコアを再計算し、ポリシーを再生成してポリシーエンフォーサ２５へ一方的に送信する。これにより、各アクセスに対するポリシーエンフォースメントはポリシーエンフォーサ２５の内部で完結することができる。
　また、ポリシーエンジン２３は、管理者が学習などによって重みｗγを調整することにより、管理者の意図をポリシー生成の仕方、換言すればリスクとニーズの間のトレードオフの取り方に反映することができる。したがって、入力部２１及びデータストア２２から入力されるデータが同じであっても、デバイスのリスク回避とアクセスニーズを満足することを同程度に実現するポリシーだけでなく、デバイスのリスク回避をより優先したポリシーや、アクセスニーズを満足することをより優先したポリシーなど、様々な意図やセキュリティ戦略に基づく異なるポリシーを生成することができる。
　図３に戻り、説明を続ける。ポリシーエンジン２３は、生成したポリシーをポリシー提示部２４及びポリシーエンフォーサ２５に出力する。なお、ポリシーエンジン２３は、例えばＡＣＬ（Access Control List）又はアクセスプロキシの形でポリシーを出力しても良いが、出力する形式はこれらに限られない。
　ポリシー提示部２４は、ポリシーエンジン２３で生成されたポリシーを管理者に提示するインタフェースであり、例えば、ディスプレイ等の表示部を有する。ポリシーエンフォーサ２５は、生成されたポリシーに従ってネットワーク上のアクセスを実際に制御する。
　（計算例）
　以上のポリシー生成システム２０の説明に基づき、具体的な値を用いたポリシー生成のアルゴリズム計算例について以下で説明する。
　まず、計算の前提について定義する。ここでは、エンティティとして、ユーザＩＤ、デバイス、アプリケーション、リソース、ＩＰアドレス、ポートを例示する。また、この例において、ポリシーエンジン２３は、（送信元ＩＰアドレス、送信先ＩＰアドレス、送信先ポート）→Ａｃｔｉｏｎという、ＩＰアドレス及びポートベースのＡＣＬ形式でポリシーを出力する。この形式において、括弧内のエンティティが上述の対象ｔである。また、Ａｃｔｉｏｎは、認可、承認待ち、否認のいずれかを取り得るとする。
　また、スコアとして、情報源を参照して自動的に更新されるものをＳｃｏｒｅ（Ｕｓｅｒ），Ｓｃｏｒｅ（Ｄｅｖｉｃｅ），Ｓｃｏｒｅ（Ａｐｐｌｉｃａｔｉｏｎ），Ｓｃｏｒｅ（ＩＰ）,Ｓｃｏｒｅ（Ｐｏｒｔ），Ｓｃｏｒｅ（Ｄｅｖｉｃｅ，Ａｐｐｌｉｃａｔｉｏｎ），Ｓｃｏｒｅ（ＳｒｃＩＰ，ＤｓｔＩＰ）とする。これらのスコアは、認証履歴、異常検知履歴、脆弱性情報、通信履歴等によってデータストア２２によって生成される。また、入力部２１を用いて人が定義するスコアを、Ｓｃｏｒｅ（Ｕｓｅｒ，Ｒｅｓｏｕｒｃｅ） とする。このスコアは、ユーザがリソースにアクセスするニーズを示す。
　また、次元γはこの例で１～８までの値を有しており、ポリシー生成アルゴリズムの重みパラメータｗγは、以下の式（１８）のように設定される。
Figure JPOXMLDOC01-appb-M000005
・・・（１８）
　また、データストア２２は、関係データとして、ユーザＩＤとデバイス間、リソースとデバイス間、デバイスとＩＰアドレス間、リソースとポート間の全てのエンティティの組み合わせに対する、Ｔｒｕｅ／Ｆａｌｓｅを取得する。ただし、データストア２２は、Ｔｒｕｅを取得し、取得していないその他のデータについてＦａｌｓｅを定義しても良い。
　ポリシーエンジン２３は、以上の取得情報に基づいて、上述の計算を実行し、ＡＣＬ形式のポリシーを更新する。この例において、ポリシーエンジン２３は、（ＳｒｃＩｐ＝１９２．１６８．１．１０，ＤｓｔＩＰ＝１９２．１６８．１．１，ＤｓｔＰｏｒｔ＝１０００）のアクセスに対して取るべき、最新のＡｃｔｉｏｎを計算する。
　まず、ポリシーエンジン２３は、関係データに基づき、（ＳｒｃＩＰ＝１９２．１６８．１．１０，ＤｓｔＩＰ＝１９２．１６８．１．１，ＤｓｔＰｏｒｔ＝１０００）に関係する集合を取得する。取得する集合は、ユーザの集合、デバイスの集合、アプリケーションの集合、ＩＰアドレスの集合、ポートの集合、（デバイス，アプリケーション）の集合、（ＳｒｃＩＰ，ＤｓｔＩＰ）の集合、（ユーザ，リソース）の集合である。
　具体的には、ユーザ＝Ａ、ポート１０００を使用するアプリケーション、ＩＰ＝１９２．１６８．１．１０及び１９２．１６８．１．１、（ユーザ＝Ａ，リソース＝ｒ）、 （ＳｒｃＩＰ＝１９２．１６８．１．１０，ＤｓｔＩＰ＝１９２．１６８．１．１）の集合に関して、式（１６）で示した関係ｒが１となり、その他の集合については、関係ｒは０となる。
　以上に基づき、アクションスコアは、式（１８）で示された重みパラメータｗγを用いると、次のように計算される。
Action Score = Score(User=A)* wγ=1 + Score(Device=1) * wγ=2+ …
+ Score(SrcIP=192.168.1.10, DstIP=192.168.1.1) * wγ=7
+ Score (User=A, Resource=r) * wγ=8
= (-1)* 1 - 1 * 2 + … +1 * 0.5 + 1 * 1 = -1.5　　　　　　　　　　・・・（１９）
ここで、単調の関数ｇｏｕｔとして
Figure JPOXMLDOC01-appb-M000006
 ・・・（２０）
を用い、アクションの決定基準として式（１７）を用いると、
gout (-1.5) < 1/3                                                   ・・・（２１）
となり、このアクセスは否認される。
　ポリシーエンジン２３は、同様にして、全てのＳｒｃＩＰ，ＤｓｔＩＰ，Ｐｏｒｔに対するアクションを生成し、ＡＣＬ形式で列挙することができる。図５は、そのようなＡＣＬ形式のポリシーを例示したテーブルである。図５では、（ＳｒｃＩＰ＝１９２．１６８．１．１０，ＤｓｔＩＰ＝１９２．１６８．１．１）であり、ＳｒｃＰｏｒｔが任意、ＤｓｔＰｏｒｔが２２、８０、４４３の場合のポリシーが示されている。ＤｓｔＰｏｒｔが２２、８０、４４３の場合のそれぞれのスコアは０．１１、０．６、０．８１なので、それぞれのアクションは認可、承認待ち、否認となる。
　また、ポリシーエンジン２３は、あらかじめアクションを生成するのではなく、アクセスの検出時に、そのアクセスに対するアクションをアクセスプロキシとして計算することもできる。ポリシーエンジン２３は、入力されるデータの時間変化に応じて、出力するポリシーを変化させることができる。
　近年、ゼロトラストネットワークの技術が進展することで、当該ネットワークにおけるアクセス制御の重要性が増している。ゼロトラストネットワークは、例えば、会社や自治体等で用いられるローカル５Ｇ（5th Generation）において適用することができる。
　ゼロトラストネットワークは、全てのデバイスからのアクセスについてセキュリティに関するスコアを算定し、そのアクセスを許可するか否かを決定するものである。これにより、ネットワーク内部に脅威が侵入しても、その脅威が重要なファイルにアクセスすることを防止し、被害の拡大を防ぐことができる。また、ゼロトラストネットワークは、ネットワーク外部からのアクセスについても、一概に遮断するのではなく、上述のスコア算定に基づく判定をすることで、信頼できるアクセスについては許可することができる。そのため、ネットワークの安全性と可用性を両立させることができる。
　このようなゼロトラストネットワークにおいては、ネットワークのポリシーエンジンが、リスク、ニーズ、信頼等の観点に基づく様々な情報を統合することによって、アクセスの許可や否認といったアクションを決める。アクションを精度良く決定するためには、詳細なポリシーを生成することが必要となる。また、ネットワークの環境（アクセス制御に関連する複数の要素）が変化した場合でも、環境変化をポリシーに的確に反映させられるようにするため、生成するポリシーは動的であることが好ましい。そのため、生成するポリシーが複雑になり、このようなポリシーをどうやって定義又は生成するかが課題となる。
　例えば、管理者がポリシーを生成する場合、上述の様々な情報に基づいてポリシーを生成する必要があるため、ポリシー生成のための時間や労力が大きくなってしまう。また、詳細なポリシーを生成するための具体的な認可アルゴリズムの一例として、決定木と信頼スコアを用いることも考えられるが、その場合でも、決定木を作成するためのポリシー生成のための時間や労力が膨大なものになってしまうという課題があった。特に、人間のあいまいで抽象的な意図を厳密で具体的なポリシーの形に変換する点について、掛かる時間や労力が大きい。また、人間の作業工程上、必要なポリシーの定義漏れが生ずる可能性もあった。
　これに対し、この開示に係るポリシー生成システム２０は、管理者のあいまいで抽象的な意図を、リスク及び運用ニーズの観点に基づくスコアとして、数値化して入力部２１から入力させている。そして、厳密な細かいポリシーは、ポリシー生成システム２０が、入力部２１からのスコアデータ及びデータストア２２からのデータに基づいて自動で作成し、提示部２６で管理者に提示する。管理者は最初のスコアデータだけを最小限の設定として入力すれば良く、具体的で厳密なポリシーを生成する必要がないため、ポリシー生成に必要な時間や労力を大幅に削減できるほか、ポリシー生成システム２０は、管理者の意図を反映したポリシーを生成することができる。また、管理者が明示的にポリシーを設定しない設定漏れがあった場合でも、ポリシー生成システム２０は、信頼度が低いアクセスを一律に許可せず、リスクに応じて否認するような中間的なポリシーを生成することができ、管理者の意図を補間することができる。したがって、ポリシー生成システム２０は、管理者の意図を反映させた、ネットワークの安全性と可用性を両立させることができるポリシーを生成することができる。ポリシーとして、例えば上述のようなエンフォーサ用のＡＣＬが生成されても良い。
　例えば、関係データとして、ＩＰアドレスとポートの組み合わせが用いられた場合に、ポリシーエンジン２３は、ユーザやデバイスの状況の動的な変化に応じて、ニーズが存在せず、リスクがある通信だけを遮断するポリシーを生成することができる。ユーザやデバイスの状況の変化とは、上述の通り、ユーザ位置、デバイスの認証履歴、時間帯等の変化をいう。この場合、信頼度が非常に低下した機器は他のリソースにアクセスすることができず、通信から隔離されても良い。また、信頼度がやや低下した機器（セキュリティ上疑わしい機器）については、ニーズ又はアクセス先のリソースの重要度に応じて、一部のポートにおける通信が制限されても良い。
　また、ポリシー生成システム２０は、テンソル表現で、関係データ及びスコアデータを組み合わせた情報を扱うことができるほか、重みを調節することで、各情報の重要性を補正できる。そのため、ポリシー生成システム２０は、多様な種類の情報を扱うことができるため、適用できる用途を広く取ることができる。
　また、ポリシー生成システム２０は、一時的なＡＣＬの形で、現在のネットワークの背景情報に応じたポリシーを動的に生成できるので、ポリシーエンフォーサ２５がポリシーエンジン２３をトリガさせなくとも、背景情報に応じたアクセス制御が実行できる。そのため、アクセス制御を低レイテンシとすることができる。
　また、ポリシー生成システム２０は、管理者がスコアデータを入力する入力部２１を有する。そのため、管理者は、アクセス制御に関して、自身の意図をポリシーに反映させることができる。
　また、ポリシーエンジン２３は、一部のスコアが定義されていないスコアデータを用いて、ポリシーを生成することもできる。そのため、ポリシーエンジン２３が生成するポリシーは、状況に関しての汎用性が高くなる。
　また、ポリシーエンジン２３は、ポリシーが設定するアクションが全順序集合であり、実数値で定義されるスコアデータの各スコアに対し、アクションが順序同型となるようにポリシーを生成することもできる。ニーズが下がった場合又はリスクが上がった場合に、ポリシーで規定されるアクションはアクセスを許可しない方向に変化するため、ポリシー生成システム２０は、アクションを管理者の意図を反映したものにすることができる。
　また、ポリシーエンジン２３は、アクセス制御の対象以外の対象に関するスコアデータを用いて、アクセス制御の対象に関するアクションを設定するポリシーを生成することもできる。そのため、ポリシーエンジン２３は、ポリシーをより精度高く決定することができる。
　なお、実施の形態２におけるモデル関数は、多層のものが設定されても良い。この場合のモデル関数の一例は次の通りである。
Figure JPOXMLDOC01-appb-M000007
 ・・・（２２）
式（２２）におけるｇ１は、式（１４）のｇｏｕｔに相当する。また、式（２２）における重みパラメータｗは非負の値である。
　実施の形態３
　以下、図面を参照してこの開示の実施の形態３について説明する。実施の形態３では、実施の形態２にて説明したポリシー生成システム２０のさらなるバリエーションを開示する。
　実施の形態２では、デバイス、ユーザ、リソース、時間帯（又は時刻）といった要素に関するリスクやニーズをスコアとしてポリシーエンジンに入力することで、実際のアクセスで用いられるＩＰアドレスやポート番号に応じて、それらの間のトレードオフが自動的に評価される方法を開示した。これにより、実際の当該アクセスによって得られる利益を維持しつつ、当該アクセスが不正であった場合の損害を小さくするポリシー（アクセス制御の仕方）を自動生成することが可能となった。
　しかしながら、実施の形態２においては、管理者が直接ポリシーを定義することなく、ポリシーエンジンがリスクやニーズからポリシーを全て自動生成するため、生成されたポリシーの中で不適切なものがあった場合、管理者が不適切なポリシーを個別に変更する必要がある。例えば、ユーザのアクセスニーズを満足するために、リスクの高いデバイスに対してもアクセスを許可してしまうポリシーが生成され、管理者がそのポリシーを許容できない場合、管理者はリスクの高いデバイスに関連するポリシーを全て変更する必要があり、タイムコストを要する。
　これに対し、実施の形態３は、管理者が不適切なポリシーの一部を変更するだけで、その他の全ての不適切なポリシーにも自動的に変更を波及させるポリシー生成システムを開示する。例えば、ポリシー生成システムは、当該変更の目的がデバイスのリスクを優先するものであることを自動的に推定することで、全ての不適切なポリシーを変更することができる。これにより、不適切なポリシーの変更に必要なコストを抑制できる。
　図６は、ゼロトラストネットワーク上におけるポリシー生成システム３０の一例を示すブロック図である。ポリシー生成システム３０は、ポリシー生成システム２０と比較して、構成要素として変更部３１をさらに備える。
　管理者は、ポリシー提示部２４で提示されたポリシーを視認して、ポリシーを修正するように、入力部２１を用いて新たに当該ポリシーの変更情報を入力する。この際に、管理者は、実施の形態２と同様に、当該ポリシーを生成するスコアをさらに入力しても良い。入力部２１は、関係データやニーズ・リスクのスコアを管理者が実施の形態２に示したように手動設定する手段としてだけでなく、ポリシーを管理者が変更又は事前に固定するための入力を受け付けるポリシー設定入力手段としても機能する。このときに、変更部３１は、入力部２１から入力された変更情報を反映するようにポリシーエンジン２３のモデル関数を調節して、一旦生成されたポリシーを変更させる。
　このとき、変更部３１は、入力部２１から入力された変更情報によっては変更されなかったポリシーのパターンについても、生成するポリシーを変更する。このポリシーの変更は、入力部２１及びデータストア２２から現在取得した関係データ及びスコアデータが変更情報の入力前後で変わっていない場合であっても、実行される。管理者が一部のポリシーのパターンを変更した結果、ポリシーエンジン２３内部のモデル関数は、当該パターンを実現するよう、変更部３１によって調節される。これにより、リスクやニーズの間のトレードオフの取り方そのものが変化することで、管理者が直接変更しなかったポリシーについても、その変更が実現される。なお、ポリシーエンジン２３内部のモデル関数が調節されることで、管理者が直接変更したポリシーと、管理者が直接変更しなかったポリシーの両方が、ポリシーエンジン２３の内部で同時に変更される。
　管理者の直接の変更対象ではないエンティティについて当初導出されたアクションは、不適切なリスクやニーズの間のトレードオフの取り方に起因して生成されていたと考えられる。そのため、このようなエンティティについても、直接管理者が変更する対象と同様に、新たな前提（トレードオフの取り方）の下で異なるアクションを導出する必要がある。
　具体例として、管理者は、入力部２１を用いて、ポリシーのうち一部のものを教師データとして入力することができる。この教師データは、ポリシーの正解を定義するものである。変更部３１は、その教師データがポリシーに反映されるように、重みパラメータを学習し、調整する。つまり、変更部３１は、教師データとして変更されなかったポリシーを含む全てのポリシーについて、教師データが変更内容として反映されるように、ポリシーを決定する重みパラメータを調整する。
　変更部３１は、例えば、管理者が入力部２１から入力したポリシーの変更情報を解析して、変更情報で示されたポリシーと、従前に生成されたポリシーとを比較することにより、変更の理由を推定しても良い。一例として、変更部３１は、変更情報を用いて、管理者の変更の意図が、デバイスのリスク回避をより優先させるようにすること、又は、アクセスニーズを満足することをより優先させるようにすることを自動的に推定する。この推定結果を用いて、変更部３１は、ポリシーエンジン２３内部のモデル関数を調節することができる。なお、変更部３１は、例えば教師あり学習やクラスタリングなどの手法を用いて、変更の理由を推定することができる。
　なお、所定のアクセスに対して取るべきアクション（例えば認可や否認）が最初から決まっていれば、管理者は、そのようなアクションが導出されるように、入力部２１を操作して、ポリシー生成前（事前）からポリシーを固定することもできる。
　（計算例）
　以上のポリシー生成システム３０の説明に基づき、具体的な値を用いたポリシー生成のアルゴリズム計算例について説明する。この例では、実施の形態２の計算例において、アクションが承認、認証待ち、否認の場合にアクションスコアａがそれぞれ０．９、０．５、０．１となるように、管理者が教師データを入力部２１から入力する。
　実施の形態２の計算例におけるアルゴリズムが、（ＳｒｃＩＰ＝１９２．１６８．１．１０, ＤｓｔＩＰ＝１９２．１６８．１．１, ＤｓｔＰｏｒｔ＝１０００）の組み合わせに対してａ＝０．６を出力する一方、この組み合わせについて管理者が定義したポリシーが「Ｄｒｏｐ」であるとする。この場合、変更部３１は、同じ入力に対する出力をｙ＝０．１に近づけるように、機械学習などにより重みパラメータを更新する。
　以上のようにして、変更部３１は、管理者の入力に応じてポリシーを変更することができるため、ポリシーを状況変化等に応じた的確なものに変更することができる。このとき、変更部３１は、管理者によって直接変更されなかったポリシーのパターンについても重みパラメータを介して自動的に変更することで、変更の対象ではないエンティティについても、当初のポリシーによるアクションよりも適切なアクションを導出することができる。
　なお、この開示は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。例えば、実施の形態２において、閾値ｔｈは２種類としたが、１種類、又は３種類以上の閾値ｔｈが設定されても良い。実施の形態２、３において、ポリシーエンジン２３はモデル関数として上述のものと異なるものを用いても良く、その場合、ポリシーエンジン２３は、重みパラメータｗγとは異なるパラメータを学習しても良い。
　以上に示した実施の形態では、この開示をハードウェアの構成として説明したが、この開示は、これに限定されるものではない。この開示は、上述の実施形態において説明されたポリシー生成装置又はポリシー生成システムの処理（ステップ）を、コンピュータ内のプロセッサにコンピュータプログラムを実行させることにより実現することも可能である。
　図７は、以上に示した各実施の形態の処理が実行される情報処理装置（信号処理装置）のハードウェア構成例を示すブロック図である。図７を参照すると、この情報処理装置９０は、信号処理回路９１、プロセッサ９２及びメモリ９３を含む。
　信号処理回路９１は、プロセッサ９２の制御に応じて、信号を処理するための回路である。なお、信号処理回路９１は、送信装置から信号を受信する通信回路を含んでいても良い。
　プロセッサ９２は、メモリ９３からソフトウェア（コンピュータプログラム）を読み出して実行することで、上述の実施形態において説明された装置の処理を行う。プロセッサ９２の一例として、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＦＰＧＡ（Field-Programmable Gate Array）、ＤＳＰ（Demand-Side Platform）、ＡＳＩＣ（Application Specific Integrated Circuit）のうち一つを用いてもよいし、そのうちの複数を並列で用いてもよい。
　メモリ９３は、揮発性メモリや不揮発性メモリ、またはそれらの組み合わせで構成される。メモリ９３は、１個に限られず、複数設けられてもよい。なお、揮発性メモリは、例えば、ＤＲＡＭ (Dynamic Random Access Memory)、ＳＲＡＭ (Static Random Access Memory)等のＲＡＭ (Random Access Memory)であってもよい。不揮発性メモリは、例えば、ＰＲＯＭ (Programmable Random Only Memory)、ＥＰＲＯＭ (Erasable Programmable Read Only Memory) 等のＲＯＭ (Random Only Memory)、フラッシュメモリや、ＳＳＤ（Solid State Drive）であってもよい。
　メモリ９３は、１以上の命令を格納するために使用される。ここで、１以上の命令は、ソフトウェアモジュール群としてメモリ９３に格納される。プロセッサ９２は、これらのソフトウェアモジュール群をメモリ９３から読み出して実行することで、上述の実施形態において説明された処理を行うことができる。
　なお、メモリ９３は、プロセッサ９２の外部に設けられるものに加えて、プロセッサ９２に内蔵されているものを含んでもよい。また、メモリ９３は、プロセッサ９２を構成するプロセッサから離れて配置されたストレージを含んでもよい。この場合、プロセッサ９２は、Ｉ/Ｏ（Input/Output）インタフェースを介してメモリ９３にアクセスすることができる。
　以上に説明したように、上述の実施形態における各装置が有する１又は複数のプロセッサは、図面を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む１又は複数のプログラムを実行する。この処理により、各実施の形態に記載された信号処理方法が実現できる。
　プログラムは、コンピュータに読み込まれた場合に、実施形態で説明された１又はそれ以上の機能をコンピュータに行わせるための命令群（又はソフトウェアコード）を含む。プログラムは、非一時的なコンピュータ可読媒体又は実体のある記憶媒体に格納されてもよい。限定ではなく例として、コンピュータ可読媒体又は実体のある記憶媒体は、random-access memory（RAM）、read-only memory（ROM）、フラッシュメモリ、solid-state drive（SSD）又はその他のメモリ技術、CD-ROM、digital versatile disk（DVD）、Blu-ray（登録商標）ディスク又はその他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ又はその他の磁気ストレージデバイスを含む。プログラムは、一時的なコンピュータ可読媒体又は通信媒体上で送信されてもよい。限定ではなく例として、一時的なコンピュータ可読媒体又は通信媒体は、電気的、光学的、音響的、またはその他の形式の伝搬信号を含む。
　以上、実施の形態を参照して本開示を説明したが、本開示は上記によって限定されるものではない。本開示の構成や詳細には、開示のスコープ内で当業者が理解し得る様々な変更をすることができる。
１０　　　　　　ポリシー生成装置
１１　　　　　　取得部　　　　　　　　　１２　　　ポリシー生成部
２０、３０　　　ポリシー生成システム
２１　　　　　　入力部　　　　　　　　　２２　　　データストア
２３　　　　　　ポリシーエンジン　　　　２４　　　ポリシー提示部
２５　　　　　　ポリシーエンフォーサ
３１　　　　　　変更部　　　　　

Claims (10)

  1. 　アクセス制御に関連する複数の要素について、前記複数の要素間の関係を示す関係データと、アクセスのリスクの観点に基づくスコア及びアクセスのニーズの観点に基づくスコアの少なくとも１つが定義されたスコアデータと、を取得する取得手段と、
    　前記関係データ及びスコアデータを用いて、アクセス制御のポリシーを生成するポリシー生成手段と、を備える
    　ポリシー生成装置。
  2. 　前記取得手段は、人物が前記スコアデータを前記ポリシー生成装置に入力する入力手段を有する、
    　請求項１に記載のポリシー生成装置。
  3. 　前記ポリシー生成手段は、一部のスコアが定義されていない前記スコアデータを用いて、前記ポリシーを生成する、
    　請求項１又は２に記載のポリシー生成装置。
  4. 　前記ポリシー生成手段は、前記ポリシーが設定するアクションが全順序集合であり、実数値で定義される前記スコアデータの各スコアに対し、前記アクションが順序同型となるように前記ポリシーを生成する、
    　請求項１乃至３のいずれか１項に記載のポリシー生成装置。
  5. 　前記ポリシー生成手段は、アクセス制御の対象以外の対象に関する前記スコアデータを用いて、アクセス制御の対象に関するアクションを設定するポリシーを生成する、
    　請求項１乃至４のいずれか１項に記載のポリシー生成装置。
  6. 　前記ポリシー生成手段が生成した前記ポリシーを人物に提示する提示手段と、
    　前記ポリシーを人物が変更又は事前に固定するための入力を受け付けるポリシー設定入力手段と、をさらに備える
    　請求項１乃至５のいずれか１項に記載のポリシー生成装置。
  7. 　前記ポリシー設定入力手段によって人物が変更しなかった前記ポリシーのパターンについても、前記変更の理由を推定することによって変更するポリシー変更手段をさらに備える
    　請求項６に記載のポリシー生成装置。
  8. 　前記ポリシー設定入力手段によって人物が変更しなかった前記ポリシーのパターンについても、前記ポリシーを決定する重みを調整することによって変更するポリシー変更手段をさらに備える
    　請求項６に記載のポリシー生成装置。
  9. 　アクセス制御に関連する複数の要素について、前記複数の要素間の関係を示す関係データと、アクセスのリスクの観点に基づくスコア及びアクセスのニーズの観点に基づくスコアの少なくとも１つが定義されたスコアデータと、を取得し、
    　前記関係データ及びスコアデータを用いて、アクセス制御のポリシーを生成する、
    　コンピュータが実行するポリシー生成方法。
  10. 　アクセス制御に関連する複数の要素について、前記複数の要素間の関係を示す関係データと、アクセスのリスクの観点に基づくスコア及びアクセスのニーズの観点に基づくスコアの少なくとも１つが定義されたスコアデータと、を取得し、
    　前記関係データ及びスコアデータを用いて、アクセス制御のポリシーを生成する、
    　ことをコンピュータに実行させるプログラムが格納された非一時的なコンピュータ可読媒体。
PCT/JP2021/019149 2021-05-20 2021-05-20 ポリシー生成装置、ポリシー生成方法及びプログラムが格納された非一時的なコンピュータ可読媒体 WO2022244179A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US18/290,363 US20240259375A1 (en) 2021-05-20 2021-05-20 Policy generation apparatus, policy generation method, and nontransitory computer readable medium storing program
PCT/JP2021/019149 WO2022244179A1 (ja) 2021-05-20 2021-05-20 ポリシー生成装置、ポリシー生成方法及びプログラムが格納された非一時的なコンピュータ可読媒体
JP2023522112A JPWO2022244179A5 (ja) 2021-05-20 ポリシー生成装置、ポリシー生成方法及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/019149 WO2022244179A1 (ja) 2021-05-20 2021-05-20 ポリシー生成装置、ポリシー生成方法及びプログラムが格納された非一時的なコンピュータ可読媒体

Publications (1)

Publication Number Publication Date
WO2022244179A1 true WO2022244179A1 (ja) 2022-11-24

Family

ID=84141525

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/019149 WO2022244179A1 (ja) 2021-05-20 2021-05-20 ポリシー生成装置、ポリシー生成方法及びプログラムが格納された非一時的なコンピュータ可読媒体

Country Status (2)

Country Link
US (1) US20240259375A1 (ja)
WO (1) WO2022244179A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009140041A (ja) * 2007-12-04 2009-06-25 Nec Corp セキュリティ運用管理システム、方法、及び、プログラム
JP2009296036A (ja) * 2008-06-02 2009-12-17 Hitachi Ltd Ｐ２ｐ通信制御システム及び制御方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009140041A (ja) * 2007-12-04 2009-06-25 Nec Corp セキュリティ運用管理システム、方法、及び、プログラム
JP2009296036A (ja) * 2008-06-02 2009-12-17 Hitachi Ltd Ｐ２ｐ通信制御システム及び制御方法

Also Published As

Publication number Publication date
JPWO2022244179A1 (ja) 2022-11-24
US20240259375A1 (en) 2024-08-01

Similar Documents

Publication Publication Date Title
US11995205B2 (en) Centralized event detection
Balamurugan et al. Enhanced intrusion detection and prevention system on cloud environment using hybrid classification and OTS generation
US10972461B2 (en) Device aware network communication management
US20070157311A1 (en) Security modeling and the application life cycle
Ghosh et al. SoftAuthZ: a context-aware, behavior-based authorization framework for home IoT
US20070157156A1 (en) Information models and the application life cycle
US11882147B2 (en) Method and apparatus for determining a threat using distributed trust across a network
Papanikolaou et al. An autoML network traffic analyzer for cyber threat detection
US20230336591A1 (en) Centralized management of policies for network-accessible devices
US12010133B2 (en) Security threat monitoring for network-accessible devices
US20240111904A1 (en) Secure hashing of large data files to verify file identity
WO2022244179A1 (ja) ポリシー生成装置、ポリシー生成方法及びプログラムが格納された非一時的なコンピュータ可読媒体
US20240283792A1 (en) Analysis apparatus, analysis method, and non-transitory computer readable medium
WO2023144905A1 (ja) 情報処理装置、情報処理方法及び非一時的なコンピュータ可読媒体
WO2023144906A1 (ja) 分析装置、分析方法及び非一時的なコンピュータ可読媒体
US20230069924A1 (en) Information Security
Banerjee et al. Digital Communications and Networks

Legal Events

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

Ref document number: 21940793

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023522112

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 18290363

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21940793

Country of ref document: EP

Kind code of ref document: A1