JP6948749B2 - セキュリティポリシーアナライザサービス及び充足可能性エンジン - Google Patents

Description

関連出願の相互参照
本願は、「ＳＥＣＵＲＩＴＹ ＰＯＬＩＣＹ ＡＮＡＬＹＺＥＲ ＳＥＲＶＩＣＥ ＡＮＤ ＳＡＴＩＳＦＩＡＢＩＬＩＴＹ ＥＮＧＩＮＥ」と題する２０１７年６月２９日に出願された米国特許出願第１５／６３７，２２７号、及び「ＳＥＣＵＲＩＴＹ ＰＯＬＩＣＹ ＭＯＮＩＴＯＲＩＮＧ ＳＥＲＶＩＣＥ」と題する２０１７年６月２９日に出願された米国特許出願第１５／６３７，２３８号に対する優先権を主張し、それぞれの開示はその全体が参照により本明細書に援用される。

多くの状況において、コンピューティングリソース及び関連データのセキュリティの重要性は高い。一例に、コンピューティングデバイスのネットワークは、そのユーザーにロバストな一連のサービスを提供するために利用されてよい。ネットワークの中で、第１のユーザーは、特定のアクセス権を特権で与えられる場合があり、第２のユーザーは、第１のユーザーのアクセス権とは異なる場合がある第２の一連のアクセス権を有する場合がある。コンピューティングリソースサービスプロバイダという観点でのユーザーのアクセス権は、コンピューティングリソースへのユーザーアクセスを許可するのか、それとも拒否するのかを決定することの一部としてサービスプロバイダによって利用されてよいセキュリティポリシーを使用し、定義されてよい。

コンピュータシステム及びコンピュータネットワークのセキュリティを管理し、維持することは、多くの場合複雑かつ困難である。多くの場合、システムにおけるユーザーのアクセス権は経時的に変化する場合があり、これは、一部の場合にはユーザーに適用するセキュリティポリシーの変更を必要とする場合がある。コンピュータシステムまたはコンピュータネットワークでサポートされているユーザーの数及びタイプが拡大するにつれ、ユーザーと関連付けられたアクセス権が、ユーザーがアクセスする必要があるリソースに対して実際にアクセスを許可し、ユーザーがアクセスしてはならないリソースへのアクセスを拒否するかどうかを決定することが困難になる場合がある。

図面を参照して、多様な技術が説明される。

多様な実施形態を実施できる環境を示す。 コンピューティングリソースサービスプロバイダが、多様な実施形態を実施するために利用されてよい環境を示す。 クライアントが、２つのセキュリティポリシーの同等性を解析し、同等性結果を受け取る要求を発行する環境を示す。 分散型コンピュータシステムが、本明細書に説明する多様な技術を利用してよい環境を示す。 命題論理が、命題論理式の充足可能性を決定することの一部として使用される図を示す。 命題論理が、命題論理式の充足可能性を決定することの一部として使用される図を示す。 命題論理が、命題論理式の充足可能性を決定することの一部として使用される図を示す。 命題論理が、命題論理式の充足可能性を決定することの一部として使用される図を示す。 命題論理が、命題論理式の充足可能性を決定することの一部として使用される図を示す。 命題論理が、命題論理式の充足可能性を決定することの一部として使用される図を示す。 命題論理が、命題論理式の充足可能性を決定することの一部として使用される図を示す。 ２つ以上のセキュリティポリシーの同等性を決定するためのプロセスを示す図を示す。 イベント駆動型のプラットフォームが、システムに適用されているセキュリティポリシーを解析することに関連して利用される環境を示す。 システムに適用されているポリシーを監視するためのプロセスを示す図を示す。 多様な実施形態が実施されてよいグラフィックユーザーインタフェースを示す図を示す。 多様な実施形態を実施できる環境を示す。

コンピューティングリソースサービスプロバイダという観点から、クライアントは、コンピューティングリソースサービスプロバイダのリソースにアクセスする要求を行ってよい。クライアントは、ネットワークを介してサービスプロバイダに送られる場合があるアプリケーションプログラミングインタフェース（ＡＰＩ）呼び出しを介してクライアントが要求する場合があるコンピューティングリソース等、１つ以上のコンピューティングリソースに対するクライアントアクセスを許可するかどうかを決定することの一部としてセキュリティポリシーを利用し得るように、クライアントと関連付けられたセキュリティポリシーを有する場合がある。一部の場合には、コンピューティングリソースサービスプロバイダは、ユーザーに、セキュリティポリシーまたはセキュリティポリシーの部分を作成する、変更する、または削除する能力を与えてよい。セキュリティポリシーアナライザサービスは、セキュリティポリシーを比較し、第１のセキュリティポリシーが第２のセキュリティポリシーよりもより許容性があるかどうかを決定するために利用されてよい。

多様な例では、クライアントは、ポリシーの相対的な許容性を決定するためにセキュリティポリシーを解析するようにポリシーアナライザサービスに要求してよい−言い換えると、ポリシーアナライザは、２つのセキュリティポリシーが同等であるかどうか、第１のセキュリティポリシーが第２のセキュリティポリシーよりもより許容性があるかどうか等を決定するために使用されてよい。ポリシーアナライザサービスは、本開示の他の箇所に説明するもの等のコンピューティングリソースサービスのうちのサービスであってよく、ネットワークを介してサービスプロバイダに送られる場合があるＡＰＩ呼び出しを介してアクセス可能であってよい。クライアントコンピューティングデバイスは、コンピューティングリソースサービスプロバイダのサービス、コンピューティングリソース等にアクセスするよう作動してよい。多様な例では、クライアントコンピューティングデバイスは、ウェブＡＰＩ呼び出しを介してポリシーアナライザサービスと通信する。

クライアントコンピューティングデバイスは、クライアントの代わりに、２つ以上のセキュリティポリシーの同等性を決定するためにポリシーアナライザサービスを利用してよい。クライアントは、クライアントコンピューティングデバイスを使用し、２つ以上のセキュリティポリシーを含むポリシーアナライザサービスにＡＰＩ要求を行ってよい。一般的に言えば、セキュリティポリシーは、１つ以上のセキュリティ許可を指定する情報であってよい。セキュリティ許可は、システムのリソース及び／または認証対象と関連付けられたアクセス権を定義するセキュリティポリシーの要素であってよい。例えば、許可は、コンピューティングリソースサービスプロバイダのコンピューティングリソースへのアクセスを許可するまたは拒否するために使用されてよい。一部の場合には、許可は、認証対象、コンピューティングリソース、アクション、条件、及び効果を指定してよい。一部の実施形態では、許可は、例えばユーザーの集合もしくはクラス、リソースの集合体、いくつかの異なるアクション、及び／または多数の条件等のこれらの要素のうちの複数の１つ以上を指定してもよい。

セキュリティポリシーは、例えばバージョニング情報及びポリシー全体の情報等の追加の情報だけではなく１つ以上の許可ステートメントを含んでもよい。セキュリティポリシーは、例えば、異なるユーザー、コンピューティングリソースで実行中の異なるアクション、及びアクセスの異なる条件との関連で等、多様な状況においてコンピューティングリソースへのアクセスを許可するのか、それともアクセスを拒否するのかを決定するために利用できる条件の集合を含んでよい。例えば本開示の他の箇所で説明する権限付与モジュールまたは権限付与サービスは、要求に関連してセキュリティポリシーを評価することに少なくとも部分的に基づいてリソースにアクセスする要求を許可するのか、それとも拒否するのかを評価するために利用されてよい。一部の場合には、ポリシー全体の情報は、ポリシーの始めのポリシーヘッダーに含まれる、またはポリシー文書とは別個に（及び関連して）記憶される場合もある。ポリシーは、図２に関連して他の箇所に説明するステートメント等の多数のポリシーステートメントを含んでよい。

本開示を通して説明するように、ポリシーアナライザサービスは、コンピューティングリソースプロバイダのサービスであってよく、例えば第１のセキュリティポリシーが第２のセキュリティポリシーよりもより許容性があるかどうか、及び２つ以上のセキュリティポリシーが同等であるかどうかを決定するためのＡＰＩ等、クライアントがセキュリティポリシーを評価する要求をポリシーアナライザサービスに提出するために利用してよい１つ以上のＡＰＩをサポートしてよい。これに関連して、許容性は、リソースへのアクセスを記述するために使用される。例えば、第１のポリシーが第１のコンピューティングリソース（例えば、リソース「Ａ」）及び第２のリソース（例えば、リソース「Ｂ」）にアクセスするために利用でき、第２のポリシーがコンピューティングリソース「Ｂ」だけへのアクセスを許可する場合、第２のポリシーがアクセスを許可しないアクセスを第１のポリシーが許可するコンピューティングリソースが存在し、第１のポリシーがアクセスを許可しないアクセスを第２のポリシーが許可するリソースが存在しないため、次いで第１のポリシーは、第２のポリシーよりもより許容性があるとして記述されてよい。２つのポリシーは、ともに同じリソースにアクセスし、同じリソースへのアクセスを（暗示的にまたは明示的に、のどちらかで）拒否するために利用できる場合、同等であってよい。一般的に言えば、２つのポリシーが同等ではない場合、それらは同等性を欠くと言われる場合がある。一部の場合には、第１のポリシーが第１のコンピューティングリソース「Ａ」及び第２のコンピューティングリソース「Ｂ」へのアクセスを許可し、第２のポリシーが第２のコンピューティングリソース「Ｂ］及び第３のコンピューティングリソース「Ｃ」へのアクセスを許可する場合、ポリシーは比較にならないと言われる場合がある。

ポリシーアナライザサービスによりサポートされるＡＰＩ呼び出しは、２つのセキュリティポリシーを受け入れ、２つのセキュリティポリシーが同等であるかどうか、一方のポリシーが他方のポリシーよりもより許容性があるかどうか、ポリシーが比較できないかどうか等を決定してよい。第２の例として、ＡＰＩ呼び出しは、２つ以上のセキュリティポリシーを受け入れ、ＡＰＩ要求の一部として提供されるセキュリティポリシーのすべてが同等であるかどうかを決定してよい。第３の例として、ＡＰＩ呼び出しは、単一のセキュリティポリシーを受け入れ、そのセキュリティポリシーを１つ以上のベストプラクティスポリシーに比較してよい。ベストプラクティスポリシーは、許されるべきではない許可の集合であると決定されるセキュリティポリシーの集合であってよい。例えば、第１のベストプラクティスポリシーは、特定のデータコンテナが、全ユーザーに書き込み権限がある（例えば、任意の認証対象、ゲストユーザー、または匿名のユーザーさえコンテナに書き込むことができる）べきではないということである。ＡＰＩは、受け取られたポリシーがベストプラクティスポリシーのそれぞれよりもより許容性がないと決定することによって、ベストプラクティスポリシーに従っていることを検証してよい。ベストプラクティスポリシーの例は、リソースが全ユーザーが書き込み可能である、全ユーザーが読み取り可能である、全ユーザーがアクセス可能である等を含んでよい。一部の実施形態では、ベストプラクティスポリシーの集合体は、ＡＰＩ呼び出し、要求されるコンピューティングリソースのタイプ、及び他の文脈情報に基づいて決定されてよい。

ポリシーアナライザサービスは、例えばポリシーパーサー、命題論理変換装置、及び充足可能性エンジン等の多数の構成要素及び／またはモジュールを含んでよい。ポリシーパーサーは、セキュリティポリシーを受け取り、ポリシーから１つ以上の許可ステートメントを得る構成要素またはモジュールであってよい。例えば、クライアントが第１のポリシー「Ａ」及び第２のポリシー「Ｂ」を提供する場合、ポリシーパーサーは、ポリシー「Ａ」から許可ステートメントの第１の集合を、ポリシー「Ｂ」から許可ステートメントの第２の集合を得てよい。許可ステートメントは、それぞれコンピューティングリソースへのアクセスを許可するまたは拒否することと関連付けられてよい。命題論理変換装置は許可ステートメントを、命題論理を使用し、記述される１つ以上の制約に変換してよい。制約は多様なフォーマットで、及び例えばＳＭＴ−ＬＩＢ標準フォーマット、ＣＶＣ言語、及びＣｅｎｔｅｒ ｆｏｒ Ｄｉｓｃｒｅｔｅ Ｍａｔｈｅｍａｔｉｃｓ ａｎｄ Ｔｈｅｏｒｅｔｉｃａｌ Ｃｏｍｐｕｔｅｒ Ｓｃｉｅｎｃｅｓ（ＤＩＭＡＣＳ）フォーマット等の多様な規格に従って記述されてよい。命題論理変換装置により生成される命題論理式は、対応する許可ステートメントが効力を持つためには満たさなければならない制約の集合を表す場合がある。

充足可能性エンジンは、第１の命題論理式及び第２の命題論理式を比較して、一方の命題論理が他方よりもより許容性があるかどうかを決定するために使用されてよい。充足可能性エンジンは、２つ以上の命題論理式の許容性を解析するために使用されてよい。充足可能性エンジンは、第１の命題論理式が、第２の命題論理式よりもより許容性があるかどうかを決定することに一部として追加の命題論理制約を生成してよい。制約は、第１の命題論理式及び第２の命題論理式の制約に加えて、生成され、評価されてよい。制約は、クライアントが何を要求しているのかに少なくとも部分的に基づいて生成されてよい。例えば、充足可能性エンジンは、第１のポリシーがリソースへのアクセスを許可し、第２のポリシーがリソースへのアクセスを拒否する状況、または呼び出し者からの、第１の命題論理式が第２の命題論理式よりもより許容性があるかどうかを決定する要求に応えて、リソースに関して中立である状況でのみ満たされる制約を生成してよい。充足可能性エンジンは、命題論理式制約（例えば、第１の命題論理式及び第２の命題論理式から得られる制約、ならびに充足可能性エンジンにより生成される制約）を検証するために使用されてよい。一部の実施形態では、コマンドは、制約の集合が充足可能であるかどうかを決定するために使用されてよい。式は、アサ―トされたすべての式を真にする解釈がある場合、充足可能であってよい。言い換えると、制約のそれぞれがいくつかの条件下で満たされる場合、モデルは充足可能である。一部の実施形態では、充足可能性エンジンは、例えばｈｔｔｐｓ：／／ｇｉｔｈｕｂ．ｃｏｍ／Ｚ３Ｐｒｏｖｅｒ／ｚ３に説明する、Ｚ３等のＳＭＴソルバーを少なくとも部分的に使用し、実装されてよい。

上記説明及び以下の説明では、多様な技術を説明する。説明のために、具体的な構成及び詳細が、技術を実施する上で考えられる方法の完全な理解を提供するために説明される。しかしながら、以下に説明される技術が、具体的な詳細なしに異なる構成で実施されてよいことも明らかになる。さらに、説明されている技術を曖昧にするのを回避するために、周知の特徴が省略または簡略化される場合がある。

図１は、本開示の多様な実施形態を実践できる環境１００の例示的な例である。一実施形態では、環境１００は、クライアントコンピューティングデバイス１０２、セキュリティポリシー１０４、ポリシーアナライザサービス１０６、ポリシーパーサー１０８、命題論理変換装置１１０、及び充足可能性エンジン１１２を含む。環境１００は、クライアントが、ポリシーの相対的な許容性を決定するためにセキュリティポリシー１０４を解析するようにポリシーアナライザサービス１０６に要求してよい−言い換えると、ポリシーアナライザは、セキュリティポリシー１０４が同等であるかどうか、第１のセキュリティポリシー（例えば、図１に示すセキュリティポリシーＡ）が第２のセキュリティポリシー（例えば、図１に示すセキュリティポリシーＢ）よりもより許容性があるかどうか等を決定するために使用されてよい。

クライアントコンピューティングデバイス１０２は、コンピューティングリソースへのアクセスを提供するサービスのクライアントであってよい。一部の実施形態では、コンピューティングリソースは、ネットワークを介してサービスプロバイダに送られる場合があるアプリケーションプログラミングインタフェース（ＡＰＩ）を介してアクセスされる。クライアントコンピューティングデバイス１０２は、コンピューティング環境のサービス、コンピューティングリソース等にアクセスするよう作動するエンティティであってよい。一部の実施形態では、クライアントコンピューティングデバイス１０２は、ウェブＡＰＩ呼び出しを介してポリシーアナライザサービス１０６と通信してよい。

一部の実施形態では、クライアントコンピューティングデバイス１０２は、２つ以上のセキュリティポリシー１０４の同等性を決定するためにポリシーアナライザサービス１０６を利用する。クライアントは、２つ以上のセキュリティポリシー１０４を含むポリシーアナライザサービスにＡＰＩ要求を行ってよい。セキュリティポリシーは、１つ以上のセキュリティ許可を指定する（例えば、ファイル内で符号化された）情報であってよい。セキュリティ許可は、システムのリソース及び／または認証対象と関連付けられたアクセス権を定義するセキュリティポリシーの要素であってよい。例えば、許可は、コンピューティングリソースサービスプロバイダのコンピューティングリソースへのアクセスを許可するまたは拒否するために使用されてよい。ポリシーは、例えばＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）等の、言語に依存しないフォーマットで表されてよい。本開示に説明する例は、ＪＳＯＮフォーマットまたはＪＳＯＮに類似したフォーマットであってよく、実施されてよい多様な実施形態の図としてであってよい。言うまでもなく、ＪＳＯＮ及びＪＳＯＮのようなフォーマットに関連して説明する方法で利用されてよい多様な他のフォーマットも意図されてよく、本開示の範囲内である。セキュリティポリシーは、例えばバージョニング情報及びポリシー全体の情報等の追加の情報だけではなく１つ以上の許可ステートメントを含んでもよい。一部の場合には、ポリシー全体の情報は、ポリシーの始めのポリシーヘッダーに含まれる、またはポリシー文書とは別個に（及び関連して）記憶される場合もある。ポリシーは、図２に関連して他の箇所に説明するステートメント等の多数のポリシーステートメントを含んでよい。

ポリシーアナライザ１０６は、コンピューティングリソースサービスプロバイダ（例えば、図４に関連して他の箇所に説明するコンピューティングリソースサービスプロバイダ）のサービスであってよい。ポリシーアナライザサービス１０６は、ハードウェア、ソフトウェア、及びその組み合わせを使用し、実装され得る。一部の場合には、ポリシーアナライザサービス１０６は、クライアント（例えば、クライアントコンピューティングデバイス１０２）が、ポリシーアナライザサービス１０６に要求を提供するために使用してよい１つ以上のＡＰＩをサポートする。ポリシーアナライザサービス１０６は、例えば第１のセキュリティポリシーが第２のセキュリティポリシーよりもより許容性があるかどうか、及び２つ以上のセキュリティポリシーが同等であるかどうかを決定するためのＡＰＩ等、セキュリティポリシー（例えば、図１に関連して説明するセキュリティポリシー１０４）を評価するために使用される１つ以上のＡＰＩをサポートしてよい。

一部の実施形態では、許容性は、リソースへのアクセスの許可を記述するために使用される。例えば、第１のポリシーが第１のコンピューティングリソース（例えば、リソース「Ａ」）及び第２のリソース（例えば、リソース「Ｂ」）へのアクセスを許可し、第２のポリシーがコンピューティングリソース「Ｂ」だけへのアクセスを許可する場合、第２のポリシーがアクセスを許可しないアクセスを第１のポリシーが許可するコンピューティングリソースが存在し、第１のポリシーがアクセスを許可しないアクセスを第２のポリシーが許可するリソースが存在しないため、次いで第１のポリシーは、第２のポリシーよりもより許容性があるとして記述されてよい。２つのポリシーは、ともに同じリソースへのアクセスを許可し、同じリソースへのアクセスを（暗示的にまたは明示的に、のどちらかで）拒否する場合、同等であってよい。一部の場合には、同等性は、同じリソースへのアクセスを明示的に許可し、同じリソースへのアクセスを明示的に拒否する２つのポリシーを指す場合がある−言い換えると、第１のポリシーがコンピューティングリソースへのアクセスを明示的に拒否し、第２のポリシーがコンピューティングリソースへのアクセスを（例えば、デフォルトで拒否の状況でアクセスを肯定的に許可しないことにより）コンピューティングリソースへのアクセスを暗示的に拒否する場合、それらは一部の実施形態では同等性を欠く場合がある。一般的に言えば、２つのポリシーが同等ではない場合、それらは同等性を欠くと言われる場合がある。一部の場合には、第１のポリシーが第１のコンピューティングリソース「Ａ」及び第２のコンピューティングリソース「Ｂ」へのアクセスを許可し、第２のポリシーが第２のコンピューティングリソース「Ｂ」及び第３のコンピューティングリソース「Ｃ」へのアクセスを許可する場合、ポリシーは比較にならないと言われる場合がある。特別の定めのない限り、本明細書に説明する例は、コンピューティングリソースへのアクセスの明示的な許可が存在しない限り、コンピューティングリソースへのアクセスが拒否されるデフォルトで拒否モデルを実施してよいことに留意されたい。これらの説明との関連で、セキュリティポリシーは、リソースにアクセスする要求が、要求に対して適用可能なセキュリティポリシーを利用することによって、権限付与モジュールまたは権限付与サービスによって評価されてよいコンピューティングリソースサービスプロバイダという観点から、リソースへのアクセスを許可するまたは拒否するために利用されてよいことにさらに留意されたい。適用可能なセキュリティポリシーは、要求者と関連付けられたセキュリティポリシー、要求者が提示するトークンと関連付けられたセキュリティポリシー等であってよい。係る技術は、図４に関連して他の箇所に説明するコンピューティングリソースサービスプロバイダに従って実行されてよい。

ポリシーアナライザサービス１０６は、１つ以上のポリシーの許容性を決定するために使用されてよい。例えば、ポリシーアナライザサービス１０６によりサポートされるＡＰＩ呼び出しは、２つのセキュリティポリシーを受け入れ、２つのセキュリティポリシーが同等であるかどうか、一方のポリシーが他方のポリシーよりもより許容性があるかどうか、ポリシーが比較できないかどうか等を決定してよい。第２の例として、ＡＰＩ呼び出しは、２つ以上のセキュリティポリシーを受け入れ、ＡＰＩ要求の一部として提供されるセキュリティポリシーのすべてが同等であるかどうかを決定してよい。第３の例として、ＡＰＩ呼び出しは、単一のセキュリティポリシーを受け入れ、そのセキュリティポリシーを１つ以上のベストプラクティスポリシーに比較してよい。ベストプラクティスポリシーは、許されるべきではない許可の集合であると決定されるセキュリティポリシーの集合であってよい。例えば、第１のベストプラクティスポリシーは、特定のデータコンテナが、全ユーザーに書き込み権限がある（例えば、任意の認証対象、ゲストユーザー、または匿名のユーザーさえコンテナに書き込むことができる）べきではないということである。ＡＰＩは、受け取られたポリシーがベストプラクティスポリシーのそれぞれよりもより許容性がないと決定することによって、ベストプラクティスポリシーに従っていることを検証してよい。ベストプラクティスポリシーの例は、リソースが全ユーザーが書き込み可能である、全ユーザーが読み取り可能である、全ユーザーがアクセス可能である等を含んでよい。一部の実施形態では、ベストプラクティスポリシーの集合体は、ＡＰＩ呼び出し、要求されるコンピューティングリソースのタイプ、及び他の文脈情報に基づいて決定されてよい。

ポリシーアナライザサービス１０６は、例えばポリシーパーサー１０８、命題論理変換装置１１０、及び充足可能性エンジン１１２等の多数の構成要素及び／またはモジュールを含んでよい。一部の実施形態では、多様な構成要素及び／またはモジュールの機能は、ポリシーアナライザサービス１０６が利用し得る他のサービスに委譲されてよい。例えば、ポリシーアナライザサービス１０６は、一部の実施形態では、パーシングポリシーに関係する機能性を実行するための異なるサービスを利用してよい。

ポリシーパーサー１０８は、セキュリティポリシー（例えば、ＡＰＩ呼び出しに関連してクライアントから受け取られる、またはポリシー管理サービスを介して入手されるセキュリティポリシー）を受け取り、ポリシーから１つ以上の許可ステートメントを入手する構成要素またはモジュールであってよい。例えば、クライアントが第１のポリシー「Ａ」及び第２のポリシー「Ｂ」をポリシーアナライザサービス１０６に提供する場合、ポリシーアナライザサービス１０６は、ポリシー「Ａ」から許可ステートメントの第１の集合を、ポリシー「Ｂ」から許可ステートメントの第２の集合を入手するためにポリシーパーサー１０８を使用してよい。許可ステートメントは、それぞれコンピューティングリソースへのアクセスを許可することまたは拒否することと関連付けられてよい。許可ステートメントは、例えばＪＳＯＮ、Ａｓｐｅｎ等の特定のフォーマットであり得る。

本明細書に説明するように、命題論理は、評価結果が真または偽であるのどちらかである場合がある命題の評価に関係する記号論理学を指す場合がある。命題論理は、命題式の論理的な同等性を評価するために利用されてよい。命題式は、命題変項を含む構文及び命題変項を接続する論理結合子に従ったステートメントであってよい。論理結合子または論理演算子の例は、「ＡＮＤ」（論理積）、「ＯＲ」（宣言命題）、「ＮＯＴ」（否定）、及び「ＩＦ ＡＮＤ ＯＮＬＹ ＩＦ」（相互条件的な）結合記号を含んでよい。また、命題論理は、本明細書では「命題式」または「命題論理式」と記述されてもよい。一部の実施形態では、一階論理は、命題論理の代わりに利用されてよい。一階論理は、命題論理に加えて限定記号を利用する形式体系を指す場合がある。限定記号の例は、「ＦＯＲ ＡＬＬ」（全称記号）及び「ＴＨＥＲＥ ＥＸＩＳＴＳ」（存在記号）を含む。明示的に断りのない限り、命題論理に関連して説明する本開示の実施形態は、一階論理を使用し、実施されてもよい−例えば、一部の実施形態では、一階論理変換装置（図１では不図示）が、許可ステートメントを一階論理式に変換するために命題論理変換装置１１０の代わりに利用されてよく、充足可能性エンジンは、式が同等であるかどうかを決定するために１つ以上の一階論理式を評価してよい。

許可ステートメント（例えば、パーサー１０８によって入手されるステートメント）は、命題論理変換装置１１０に提供されてよい。命題論理変換装置１１０は、（例えば、ＪＳＯＮフォーマットの）許可ステートメントを受け取り、その許可ステートメントを、命題論理を使用し記述される１つ以上の制約に変換してよい。制約は多様なフォーマットで、及び例えばＳＭＴ−ＬＩＢ標準フォーマット、ＣＶＣ言語、及びＣｅｎｔｅｒ ｆｏｒ Ｄｉｓｃｒｅｔｅ Ｍａｔｈｅｍａｔｉｃｓ ａｎｄ Ｔｈｅｏｒｅｔｉｃａｌ Ｃｏｍｐｕｔｅｒ Ｓｃｉｅｎｃｅｓ（ＤＩＭＡＣＳ）フォーマット等の多様な規格に従って記述されてよい。

例えば、許可ステートメント（例えば、セキュリティポリシーの一部として含まれる許可ステートメント）は、以下として記述されてよい。
"Ｓｔａｔｅｍｅｎｔ"：［
｛
"Ｅｆｆｅｃｔ"："Ａｌｌｏｗ"，
"Ｒｅｓｏｕｒｃｅ"：^＊，
"Ｐｒｉｎｃｉｐａｌ"：^＊，
"Ａｃｔｉｏｎ"："ｐｕｔ^＊"
｝ ］

対応する命題論理制約は、例のポリシーステートメントから生成されてよく、以下として記述されてよい。
（ａｓｓｅｒｔ ｐｏｌｉｃｙ．ｓｔａｔｅｍｅｎｔ．ｒｅｓｏｕｒｃｅ）
（ａｓｓｅｒｔ ｐｏｌｉｃｙ．ｓｔａｔｅｍｅｎｔ．ｐｒｉｎｃｉｐａｌ）
（ａｓｓｅｒｔ（＝ｐｏｌｉｃｙ．ｓｔａｔｅｍｅｎｔ．ａｃｔｉｏｎ（ｏｒ（ａｎｄ （＝"ｓｔｏｒａｇｅ"ａｃｔｉｏｎＮａｍｅｓｐａｃｅ） （ｓｔｒ．ｐｒｅｆｉｘｏｆ"ｐｕｔ"ａｃｔｉｏｎＮａｍｅ）））））
（ａｓｓｅｒｔ（＝ｐｏｌｉｃｙ．ｓｔａｔｅｍｅｎｔ．ｅｆｆｅｃｔ．ａｌｌｏｗｓ（ａｎｄ ｐｏｌｉｃｙ．ｓｔａｔｅｍｅｎｔ．ａｃｔｉｏｎ ｐｏｌｉｃｙ．ｓｔａｔｅｍｅｎｔ．ｒｅｓｏｕｒｃｅ ｐｏｌｉｃｙ．ｓｔａｔｅｍｅｎｔ．ｐｒｉｎｃｉｐａｌ）））
（ａｓｓｅｒｔ（ｎｏｔ ｐｏｌｉｃｙ．ｓｔａｔｅｍｅｎｔ．ｅｆｆｅｃｔ．ｄｅｎｉｅｓ））
（ａｓｓｅｒｔ（＝ｐｏｌｉｃｙ．ａｌｌｏｗｓ（ａｎｄ（ｎｏｔ ｐｏｌｉｃｙ．ｄｅｎｉｅｓ）ｐｏｌｉｃｙ．ｓｔａｔｅｍｅｎｔ．ｅｆｆｅｃｔ．ａｌｌｏｗｓ）））
（ａｓｓｅｒｔ（＝ｐｏｌｉｃｙ．ｄｅｎｉｅｓ ｐｏｌｉｃｙ．ｓｔａｔｅｍｅｎｔ．ｅｆｆｅｃｔ．ｄｅｎｉｅｓ））

命題論理変換装置１１０により生成される命題論理式は、対応する許可ステートメントが効力を持つためには満たさなければならない制約の集合を表す場合がある。上述した制約は、「ｐｕｔ」（例えば、「ｐｕｔ−ｏｂｊｅｃｔ」）で開始するＡＰＩへのアクセスを許す上記の許可ステートメントが満たされる場合に必ず満たされる制約の集合に相当する。

一部の実施形態では、クライアントコンピューティングデバイス１０２は、（例えば、クライアントエンドユーザーの代わりに）ポリシーアナライザサービス１０６が、第１のセキュリティポリシー（例えば、図１に示すセキュリティポリシーＡ）が第２のセキュリティポリシー（例えば、図１に示すセキュリティポリシーＢ）よりもより許容性があるかどうかを決定することを要求するウェブＡＰＩ要求をポリシーアナライザサービス１０６に送信する。セキュリティポリシー１０４がウェブＡＰＩ要求で符号化される場合もあれば、セキュリティポリシー（例えば、ポリシーが入手され得る場所を示すポインタまたはＵＲＩ）を入手するために使用できる情報が提供される場合もある。ポリシーアナライザサービス１０６は、（例えば、要求から直接的に、または要求内で符号化されたＵＲＩを使用し、ポリシー管理サービスを介してのどちらかで）セキュリティポリシー１０４を入手し、第１のポリシーから許可ステートメントの第１の集合を、及び第２のポリシーから許可ステートメントの第２の集合を入手するためにポリシーパーサー１０８を利用してよい。ポリシーステートメントは、対応するポリシーステートメントが効力を持つために満たされなければならない制約に相当する命題論理式の集合を入手するために命題論理変換装置１１０に提供されてよい。第１の命題論理式は、ポリシーステートメントの第１の集合から生成されてよく、第２の命題論理式は、ポリシーステートメントの第２の集合から生成されてよい。命題論理式は、例えばＳＴＭ−ＬＩＢ２．０規格等のＳＭＴ−ＬＩＢ規格言語に従った言語で表されてよい。充足可能性エンジン１１２は、第１の命題論理式及び第２の命題論理式を比較して、一方の命題論理が他方よりもより許容性があるかどうかを決定するために使用されてよい。

充足可能性エンジン１１２は、２つ以上の命題論理式の許容性を解析するために使用されてよい。充足可能性エンジン１１２は、ハードウェア、ソフトウェア、またはその組み合わせであってよい。一部の実施形態では、充足可能性エンジン１１２は、クライアント（例えば、命題論理変換装置１１０、ポリシーアナライザサービス１０６等の内部クライアント）が、第１の命題論理式が、第２の命題論理式よりもより許容性があるかどうかを決定できるようにする。充足可能性エンジン１１２は、第１の命題論理式が、第２の命題論理式よりもより許容性があるかどうかを決定することの一部として追加の命題論理制約を生成してよい。

一部の実施形態では、充足可能性エンジン１１２は、第１のポリシー（例えば、ポリシーＡ）が、第２のポリシー（例えば、ポリシーＢ）よりもより許容性があるかどうかを決定するために以下の制約を利用する。
（ａｓｓｅｒｔ （ｏｒ ｐｏｌｉｃｙＢ．ｎｅｕｔｒａｌ ｐｏｌｉｃｙＢ．ｄｅｎｉｅｓ））
（ａｓｓｅｒｔ ｐｏｌｉｃｙＡ．ａｌｌｏｗｓ）

制約は、図１の説明に関連して上述したように符号化されてよい、第１の命題論理式及び第２の命題論理式の制約に加えて、生成され、評価されてよい。制約は、クライアントが何を要求しているのかに少なくとも部分的に基づいて生成されてよい。例えば、充足可能性エンジン１１２は、第１のポリシーがリソースへのアクセスを許可し、第２のポリシーがリソースへのアクセスを拒否する状況、または第１の命題論理式が第２の命題論理式よりもより許容性があるかどうかを決定する、呼び出し者（例えば、ポリシーアナライザサービス１０６）からの要求に応えて、リソースに関して中立である状況下だけで満たされる制約を生成してよい。係る実施形態は、中立の状況（つまり、許可が特定のリソースに対して明示的にアクセスを許可しないまたは拒否しない状況）であるデフォルトで拒否の状況で実施されてよい。デフォルトで許可の状況では、充足可能性エンジン１１２は、第１のポリシーがリソースへのアクセスを許可する、またはリソースに関して中立であり、第２のポリシーがリソースへのアクセスを拒否しない場合に満たされる異なる制約を生成してよい。

充足可能性エンジン１１２は、命題論理式制約（例えば、第１の命題論理式及び第２の命題論理式から入手される制約、ならびに充足可能性エンジンにより生成される制約）が同等であるかどうかを検証するために使用されてよい。一部の実施形態では、コマンドは、制約の集合が充足可能であるかどうかを決定するために使用されてよい。式は、アサ―トされたすべての式を真にする解釈がある場合、充足可能であってよい。言い換えると、制約のそれぞれがいくつかの条件下で満たされる場合、モデルは充足可能である。一部の実施形態では、充足可能性エンジンは、式が充足可能であるかどうかを決定するために、充足可能性モジュロ理論（ＳＭＴ）制約ソルバーを少なくとも部分的に使用し、実施されてよい。ＳＭＴベースの制約ソルバーの一例はＺ３である。他のタイプのソルバーは、充足可能性（ＳＡＴ）ソルバー及びバイナリディシジョンダイアグラム（ＢＤＤ）ソルバーを含むが、これに限定されるものではない充足可能性エンジンを実装することの一部として本明細書に説明する技術に従って利用されてよい。充足可能性エンジン１１２は、式が充足可能であるかどうか、及び転じて、２つ以上のポリシーが同等であるかどうかを示す同等性結果を生成してよい。一部の実施形態では、同等性結果は、例えば要求を発行したクライアントコンピューティングデバイス１０２、システム管理者、及び他のコンピューティングエンティティ等、別のコンピューティングエンティティが利用できる。

図２は、セキュリティ許可及び対応する命題論理式が示される例示的な例を示す。図２に示す許可２０２は、例えば図１に関連して他の箇所に説明するセキュリティポリシー等、セキュリティポリシーで指定される複数のセキュリティ許可の１つであってよい。

図２は、コンピューティングリソースポリシーと関連付けられてよい許可２０２の一例を示す。一部の実施形態では、許可２０２は、認証対象２０４、リソース２０６、アクション２０８、条件２１０、及び効果２１２を指定してよい。一部の実施形態では、許可２０２は、例えばユーザーの集合もしくはクラス、リソースの集合体、いくつかの異なるアクション、及び／または多数の条件等のこれらの要素のうちの複数の１つ以上を指定してもよい。一部の実施形態では、許可２０２は、許可２０２を異なるユーザー及びその関連付けられたリソースに適用可能にするために許可２０２が修正され得ることを示すために使用されてよい１つ以上のワイルドカードまたはそれ以外の場合修正可能な文字を指定してよい。ワイルドカードは、多様なフォーマットで表されてよい−例えば、アスタリスクは、任意の数の文字及び疑問符を表してよく、疑問符は任意の単一の文字を表してよい。一部の実施形態では、ポリシーは、例えばＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）等の、言語に依存しないフォーマットで表されてよい。本開示に説明する例は、ＪＳＯＮフォーマットまたはＪＳＯＮに類似したフォーマットであってよく、実施されてよい多様な実施形態の図としてであってよい。言うまでもなく、ＪＳＯＮ及びＪＳＯＮのようなフォーマットに関連して説明する方法で利用されてよい多様な他のフォーマットも意図されてよく、本開示の範囲内である。

認証対象２０４は、ユーザー、グループ、組織、役割、またはこれらのもしくは他の係るエンティティの集合体及び／または組み合わせであってよい。認証対象２０４は、リソースと関連付けられたアクションを実行させるＡＰＩ呼び出しを提出できる任意のエンティティ、及び／またはリソースと関連付けられた許可が許可されてよい任意のエンティティであってよい。一例として、許可２０２は、以下のように指定された認証対象２０４要素を有してよい。
"Ｐｒｉｎｃｉｐａｌ"："ｒｎ：ｗｓ：ｉａｍ：：ｄｕｃｋｓｆａｎ８"

一部の実施形態では、認証対象２０４は、認証対象２０４を一意に識別するリソース名により識別される。認証対象２０４は、認証対象に関する追加の情報を含む１つ以上の名前空間を含んでよい。例えば、「ｒｎ」は、リソース名プレフィックスを指してよく、リソース名の一部として後続の情報を識別し、「ｗｓ」は、リソースが中にあるパーティション名前空間を指してよく、「ｉａｍ」は、コンピューティングリソースサービスプロバイダのサービス（例えば、コンピューティングリソースサービスプロバイダは、アイデンティティ及びアクセス管理に関係するサービスを提供してよい）を識別するサービス名前空間を指してよく、名前空間はさらに省略されてよい（上記の例では、「ｉａｍ」と「ｄｕｃｋｓｆａｎ８」との間に２つのセミコロンがあることに留意されたい）−一部のフォーマットでは及び／または一部のリソースの場合、領域名前空間はオプションであってよく、「ｄｕｃｋｓｆａｎ８」は、例えば許可２０２で指定されたリソース２０６を所有するアカウント等、アカウントのための識別子を指してよい。

リソース２０６は、コンピューティングリソースサービスプロバイダのコンピューティングリソースを指してよい。コンピューティングリソースサービスプロバイダのコンピューティングリソースは、計算リソース（例えば、バーチャルマシンインスタンス）、ストレージリソース（例えば、スケラブルストレージ、ブロックストレージ、及び管理ファイルストレージシステム）、データベースシステム（例えば、管理リレーショナルデータベースシステム）、マイグレーションサービス（例えば、ある物理データセンタから別の物理データセンタへのデータの転送を合理化するためのアプリケーション、サービス、及びハードウェア）、ネットワーク及びコンテンツ配信、開発者用ツール、管理ツール、セキュリティ、アイデンティティ、及びアクセスの管理サービス、解析サービス、人工知能サービス等を含んでよい。コンピューティングリソース２０６は階層内で編成されてよく、コンピューティングリソースの集合をグループに編成するために、フォルダ、ディレクトリ、バケット等の構造を使用してよい。一部の場合には、ポリシー及び／または許可はバケットに直接的に適用されてよく、環境に対するクロスアカウントアクセスを許可してよい。一例として、許可２０２は、以下のように指定されたリソース２０６要素を有してよい。
"Ｒｅｓｏｕｒｃｅ"："ｒｎ：ｗｓ：ｓｔｏｒａｇｅ：：：ｂｕｃｋｅｔ／ＭＭ４＿Ｈｅｉｓｍａｎ．ｐｎｇ"

一部の実施形態では、リソース２０６は、リソース２０６を一意に識別するリソース名により識別される。一部の場合には、リソース２０６は、認証対象２０４または許可の他の要素と同じ命名規約を共用してよい。しかしながら、許可２０２のそれぞれの別個の要素が、他の要素とは関係がない命名規約、名前空間、フォーマット等を使用する場合があるので、これは当てはまる必要がない。上記に示す例のリソースでは、「ｒｎ」は、リソース名プレフィックスを指してよく、リソース名の一部として後続の情報を識別し、「ｗｓ」は、リソースが中にあるパーティション名前空間を指してよく、「ｓｔｏｒａｇｅ」は、コンピューティングリソースサービスプロバイダ（例えば、コンピューティングリソースサービスプロバイダは、オブジェクトベースのストレージに関係するサービスを提供してよい）を識別するサービス名前空間を指してよく、他の箇所に説明するように、名前空間は一部の場合には省略されてよい−例えば、領域名前空間及び／またはアカウント名前空間は省略されてよく、リソースは、リソースのタイプのインジケータを含んでもよい。上記の例では、リソースはＰｏｒｔａｂｌｅ Ｎｅｔｗｏｒｋ Ｇｒａｐｈｉｃｓ（ＰＮＧ）フォーマットの画像を示してよく、バケットに記憶される。

アクション２０８は、許可により許されるまたは拒否される１つまたは複数の特定のアクションであってよい。異なるタイプのサービス（例えば、異なるサービス名前空間を有する）は、異なるアクションをサポートしてよい。例えば、アイデンティティ及びアカウント管理サービスは、パスワードを変更するためのアクションをサポートしてよく、ストレージサービスは、オブジェクトを削除するためのアクションをサポートしてよい。アクションは、リソースと関連して実行されてよく、例えば一種のＡＰＩ呼び出し、ライブラリ呼び出し、プログラム、プロセス、一連のステップ、ワークフロー、またはなんらかの他の係るアクションによって識別されてよい。一例として、許可２０２は、以下のように指定されたアクション２０８要素を有してよい。
"Ａｃｔｉｏｎ"："ｓｔｏｒａｇｅ：ＧｅｔＯｂｊｅｃｔ"

この例では、許されるまたは拒否される（許可で指定される効果２１２に基づいて決定される）アクションは、ＧｅｔＯｂｊｅｃｔのためのアクション（例えば、ＡＰＩ呼び出し）をサポートするストレージサービスに相当し、ＧｅｔＯｂｊｅｃｔは、オブジェクト及び／またはストレージサービスのオブジェクトへのアクセスを入手することに関連して使用されてよい。他の箇所に説明するように、多様な名前空間は、アクションを指定することに関連して使用されてよい。ワイルドカードは、複数のアクションを指定するために使用されてよい。例えば、"Ａｃｔｉｏｎ"："ｓｔｏｒａｇｅ：^＊"として記述されるアクション要素は、ストレージサービスによりサポートされるすべてのＡＰＩを指してよい。第２の例として、"Ａｃｔｉｏｎ"："ｉａｍ：^＊ＡｃｃｅｓｓＫｅｙ^＊"として記述されるアクション要素は、サービスのアクセスキーに関連してアイデンティティ及びアクセス管理サービスによりサポートされるアクションを指してよい−例示的な例は、アクセスキーを作成すること（例えば、「ＣｒｅａｔｅＡｃｃｅｓｓＫｅｙ」アクションが存在する場合）、アクセスキーを削除すること（例えば、「ＤｅｌｅｔｅＡｃｃｅｓｓＫｅｙ」）、アクセスキーをリストすること（例えば、「ＬｉｓｔＡｃｃｅｓｓＫｅｙｓ」）、及び既存のアクセスキーを更新すること（例えば、「ＵｐｄａｔｅＡｃｃｅｓｓＫｅｙ］）に関係するアクションを含んでよい。

条件２１０要素は、ポリシーが効果があるときを指定する１つ以上の条件であってよい。一部の実施形態では、条件要素は任意選択であり、一部の許可では省略される場合がある。条件は、ポリシーが効果があるかどうか（例えば、式の評価結果がＴＲＵＥでなければならないかどうか）、それとも効果がないかどうか（つまり、式の評価結果がＦＡＬＳＥでなければならないかどうか）を決定するために使用されてよいブール演算式として記述されてよい。効果がないポリシーは、（この中の他の箇所に説明する権限付与モジュール等の）権限付与モジュールによって施行されていないまたは無視される場合がある。一部の実施形態では、許可の中の条件は、アクション２０８要素で指定された１つ以上のＡＰＩに対応するウェブＡＰＩ要求の一部として提供された値に対して評価されてよい。一例として、許可２０２は、以下のように指定された条件２１０要素を有してよい。
"Ｃｏｎｄｉｔｉｏｎ"：｛ "ＤａｔｅＬｅｓｓＴｈａｎ"：｛ "ｗｓ：ＣｕｒｒｅｎｔＴｉｍｅ"："２０１４−１２−１３" ｝ ｝

この例では、条件、つまり要求の「ｗｓ：ＣｕｒｒｅｎｔＴｉｍｅ」値が、条件が満たされるかどうかを評価するために使用されてよい、条件演算子「ＤａｔｅＬｅｓｓＴｈａｎ」を使用し、リテラル値「２１０４−１２−１３」に対して比較される。この例では、条件は、現在時刻（例えば、要求がサービスプロバイダにより受け取られる時刻）が２０１４年１２月１３日という供給された日付に満たないとき真であってよい。キー値（例では、現在時刻）が、リテラル値だけではなく、ポリシー変数にも比較され得ることに留意されたい。文字列条件、数値条件、ブール条件、バイナリ条件（例えば、バイナリフォーマットで値を試験すること）、ＩＰアドレス条件（例えば、特定のＩＰアドレスまたはＩＰアドレスの範囲に対して値を試験すること）等を比較するために使用され得る多様な他のタイプの条件演算子が存在する場合がある。条件は、限定記号をさらに含んでよい。例えば、文字列条件は、２つの文字列が等しいかどうかを比較する「ＳｔｒｉｎｇＥｑｕａｌｓ」等の演算子を含んでよく、類似する演算子は、「ＳｔｒｉｎｇＥｑｕａｌｓＩｆＥｘｉｓｔｓ」が、キー値が評価という観点から存在するときに２つの文字列を比較するために使用され得るように限定記号を含んでよい。限定記号は、ワイルドカード式に一致する多数のリソースが異なるコンテキストキーをサポートしてよいワイルドカードと併せて使用されてよい。係る例は、図５〜図１１に関連して後述される。条件が限定記号を含む実施形態等の一部の実施形態では、命題論理よりむしろ一階論理が利用されてよい。

効果２１２は、許可２０２が、リソース要素２０６の許可２０２で指定されたコンピューティングリソースへのアクセスを許可するまたは拒否するために使用されるかどうかを参照してよい。効果２１２は、リソースへのアクセスを許可するＡＬＬＯＷ効果、及びリソースへのアクセスを拒否するＤＥＮＹ効果であってよい。一部の実施形態では、コンピューティングリソースサービスプロバイダのコンピューティングリソースへのアクセスはデフォルトで拒否され、ＡＬＬＯＷ効果を肯定的に含んだ許可が必要とされる。一例として、許可２０２は、以下のように指定された効果２１２要素を有してよい。
"Ｅｆｆｅｃｔ"："ＡＬＬＯＷ"

したがって、特定の条件が真である（例えば、ＡＰＩ要求が２０１６年１２月１３日以前になされる）ときにストレージサービスＡＰＩ（例えば「Ｓｔｏｒａｇｅ：ＧｅｔＯｂｊｅｃｔ」）を呼び出し、特定の画像（例えば、「ｒｎ：ｗｓ：ｓｔｏｒａｇｅ：：：ｂｕｃｋｅｔ／ＭＭ４＿Ｈｅｉｍａｎ．ｐｎｇ」）を入手するために特定の認証対象（例えば、「ｒｎ：ｗｓ：ｉａｍ：：ｄｕｃｋｓｆａｎ８」）にアクセスを許可する許可ステートメントは、以下のように指定されてよい。
"Ｓｔａｔｅｍｅｎｔ"：［
｛
"Ｅｆｆｅｃｔ"："ＡＬＬＯＷ"，
"Ｐｒｉｎｃｉｐａｌ"："ｒｎ：ｗｓ：ｉａｍ：：ｄｕｃｋｓｆａｎ８"，
"Ａｃｔｉｏｎ"："ｓｔｏｒａｇｅ：ＧｅｔＯｂｊｅｃｔ"，
"Ｒｅｓｏｕｒｃｅ"："ｒｎ：ｗｓ：ｓｔｏｒａｇｅ：：：ｂｕｃｋｅｔ／ＭＭ４＿Ｈｅｉｓｍａｎ．ｐｎｇ"，
"Ｃｏｎｄｉｔｉｏｎ"：｛
"ＤａｔｅＬｅｓｓＴｈａｎ"：｛
"ｗｓ：ＣｕｒｒｅｎｔＴｉｍｅ"："２０１４−１２−１３"
｝
｝
｝
］

上記に説明する例が、許可を表し得る多くの方法のうちの１つを記述したにすぎないことに留意されたい。言うまでもなく、他の実施形態で、図２に関連して上述した原理に対する変形形態が多様な方法で適用され得る。

一部の実施形態では、要素は、逆の（例えば負の）項で記述される場合がある。逆元は、要素内で指定された一致を除く、すべての一致に適用されてよい。例えば、許可ステートメントが「ＮｏｔＰｒｉｎｉｃｉｐａｌ：ｄｕｃｋｓｆａｎ８」として記述される場合、次いで許可ステートメントは、許可ステートメントに記載される特定の１つまたは複数の認証対象を除くすべての認証対象に適用する−この場合、許可ステートメントは、ｄｕｃｋｓｆａｎ８を除くすべての認証対象に適用する。逆元は、認証対象要素（例えば、「ＮｏｔＰｒｉｎｃｉｐａｌ」要素は、記載されている認証対象を除くすべての認証対象に適用する）、アクション要素（例えば、「ＮｏｔＡｃｔｉｏｎ」要素は、記載されているアクションを除くすべてのアクションに適用する）、リソース要素（例えば、「ＮｏｔＲｅｓｏｕｒｃｅ」要素は、記載されているリソースを除くすべてのリソースに適用する）等と併せて使用されてよい。

図２に示すように、許可２０２は、命題論理式２１４を生成するために使用されてよい。命題論理式２１４は、許可２０２を表す論理式の集合を含んでよい。命題論理式は、式が充足可能であるかどうかを決定するために評価されてよい。例えば、命題論理は、リソースが、許可の第１の集合を含んだ第１のセキュリティポリシーに対応する第１の命題論理式の下で許され、リソースが、許可の第２の集合を含んだ第２のセキュリティポリシーに対応する第２の命題論理式の下で許されない（例えば、ＡＬＬＯＷ効果を明示的に拒否される、及び／または明示的に許可されない）ことが充足可能であるかどうか決定するために使用されてよい。一部の実施形態では、許可２０２ステートメントは、命題論理式２１４を生成するために使用されてよい。認証対象２０４要素は、命題論理内のステートメント、及び式が充足可能であるかどうかに関する制約として使用される１つ以上のアサーションを含んでよい認証対象命題論理式２１６にマッピングしてよい。このマッピングの例は、図５〜図１１に関連して後述される。同様に、リソース２０６要素は、リソース命題論理式２１８にマッピングしてよく、アクション２０８要素はアクション命題論理式２２０にマッピングしてよく、条件２１０要素は、条件命題論理式２２２にマッピングしてよく、効果２１２要素は、効果命題論理式２２４にマッピングしてよい。これらのマッピングに関連する多様な例は、図５〜図１１に関連して後述される。

図３は、本開示の多様な実施形態を実践できる環境３００の例示的な例である。環境３００は、クライアントが、２つのセキュリティポリシーの同等性を解析し、ポリシーが同等であるかどうかを示す同等性結果を受け取る要求を発行し得る例を示す。環境３００は、例えば図１、図２、及び図４に関連して説明する構成要素等、本開示の他の箇所に説明する構成要素を利用してよい。

一部の実施形態では、図１に関連して他の箇所に説明するもの等のクライアントコンピューティングデバイス３０２は、クライアントの代わりに、２つ以上のセキュリティポリシー間の同等性を決定するために要求を発行してよい。一部の実施形態では、要求は、要求の一部として解析されるセキュリティポリシーを符号化するウェブＡＰＩ要求である。しかしながら、これはそうである必要はない−一部の実施形態では、セキュリティクライアントコンピューティングデバイスは、要求の受取人が１つ以上のセキュリティポリシーを入手するために使用し得る１つ以上のセキュリティポリシーに対する参照を提供してよい。一部の実施形態では、ウェブＡＰＩ要求は、図４に関連して説明するものに従って、クライアントコンピューティングデバイスからコンピューティングリソースサービスプロバイダに送信される。要求は、例えば図１及び図４に関連して説明するもの等、ポリシーアナライザサービスによって満たされてよい。第１のセキュリティポリシー３０４Ａは、１つ以上の許可ステートメント３０６Ａを入手するために構文解析されてよく、許可ステートメントは、命題論理式３０８に対する制約の機能を果たす場合がある命題論理式の第１の集合に変換されてよい。同様に、第２のセキュリティポリシー３０４Ｂは、１つ以上の許可ステートメント３０６Ｂを入手するために構文解析されてよく、許可ステートメントは、命題論理式３０８に対する制約としての機能を果たす場合がある命題論理式の第２の集合に変換されてよい。システム（例えば、ポリシーアナライザサービスまたはその中の構成要素）は、２つの命題論理式が同等であるかどうか、一方が他方よりもより許容性があるかどうか等を決定するために、図１に関連して説明するもの等、充足可能性エンジン３１０を利用してよい。

決定は、本開示の他の箇所に説明する技術に従って行われてよい。一部の実施形態では、同等性結果３１２は、２つのポリシーが同等であることを示す場合がある。２つのポリシーは、第１のポリシー及び第２のポリシーからのセキュリティ許可が、すべてのアクション、リソース、及び認証対象に同じように適用する場合に同等であると言われてよい−言い換えると、第１のポリシーと第２のポリシー両方ともが（拒否ステートメントに基づいて明示的にもしくはアクセスを許可する許可の欠如に基づいて暗示的に、のどちらかで）アクセスを拒否する、または両方ともがアクセスを許可するアクション、リソース、及び認証対象の任意の所与の集合の場合−一方のポリシーがアクセスを許可し、他方が拒否することは当てはまらない。あるポリシーが別のポリシーよりもより許容性があると決定される場合、あるポリシーは、別のポリシーがアクセスを拒否するパラメータの集合の下でアクセスを許可する場合がある。

一部の実施形態では、同等性結果３１２は、ウェブＡＰＩ要求に対する応答としてクライアントコンピューティングデバイス３０２に送信されてよい。一部の実施形態では、同等性結果３１２は、許容性結果（例えば、１つのポリシーが、第２のポリシーよりもより許容性があるかどうか）を符号化してよい。一部の実施形態では、許容性結果の代わりにまたは許容性結果に加えてのどちらかで他の情報が提供される。例えば、第１のポリシーが第２のポリシーよりもより許容性がある場合、同等性結果３１２は、第１のポリシーによるアクセスの許可、及び第２のポリシーによるアクセスの拒否を生じさせるパラメータの集合を符号化してよい（例えば、認証対象、リソース、及びアクションは、第１のポリシーが、リソース上でアクションを実行するために認証対象にアクセスを許可し、第２のポリシーが、リソース上でアクションを実行することから認証対象へのアクセスを拒否するように応答で符号化されてよい）。

環境３００は、多様な実施形態を実施するために使用されてよい。一部の実施形態では、コンピューティングデバイスは、（例えば要求で符号化された）ポリシーが最小のセキュリティ基準の集合に準拠するかどうかを決定する要求を行ってよい。コンピューティングリソースサービスプロバイダは、要求を受け取り、セキュリティ基準と関連付けられたセキュリティポリシーを送り、入手し、提供されたポリシー及びセキュリティ基準ポリシーの相対的な許容性を決定してよい。提供されたポリシーがセキュリティ基準よりもより許容性がある場合、応答は、ポリシーがセキュリティ基準に準拠していないことを示す場合がある。例えば、一部の実施形態では、クライアントは、例えば図４に関連して他の箇所に説明するもの等のポリシー管理サービスを使用し、セキュリティポリシーを設定しようと試みてよい。ポリシー管理サービスは、クライアントのセキュリティポリシーが１つ以上のセキュリティ基準に準拠しているかどうかを決定するために、ポリシーアナライザサービス４２２を利用してよい。ポリシーが準拠していない場合、次いでポリシー管理サービスは、要求を満たすのを拒否し、要求が満たされなかったことをクライアントに示し、セキュリティポリシーが１つ以上のセキュリティ基準ポリシーよりもより許容性があったことを符号化してよい。

図４は、分散型コンピュータシステムが、本明細書に説明する多様な技術を利用してよい環境４００の例示的な例を示す。一実施形態では、認証対象４０２は、ネットワーク４０４を介してコンピューティングリソースサービスプロバイダ４０６と通信するためにコンピューティングデバイスを使用してよい。コンピューティングリソースサービスプロバイダ４０６と認証対象４０２との間の通信は、例えば、コンピューティングリソースサービスプロバイダ４０６により操作される多くのサービスのうちの１つであってよい、コンピューティングリソースサービスプロバイダ４０６により操作されるサービス４０８にアクセスする目的であってよい。サービス４０８は、サービスフロントエンド４１０及びサービスバックエンド４１４を含んでよい。認証対象４０２は、関連付けられたコンピューティングデバイスを通して、コンピューティングリソースサービスプロバイダ４０６により提供されたサービス４０８へのアクセスに対する要求（及び／またはサービス４０８と関連付けられたリソースへのアクセスに対する要求）を発行してよい。要求は、例えばウェブサービスアプリケーションプログラミングインタフェース要求であってよい。認証対象は、ユーザー、もしくはユーザーのグループ、もしくはユーザーのグループと関連付けられた役割、もしくは（コンピューティングリソースサービスプロバイダ４０６に対して）リモートの１つ以上のコンピュータシステム上で実行している場合があるこれらのエンティティのうちの１つ以上を表すプロセスである場合もあれば、なんらかの他の係るコンピュータシステムエンティティ、ユーザー、もしくはプロセスである場合もある。各ユーザー、グループ、役割、または認証対象の他の係る集合体は、対応するユーザー定義、グループ定義、役割定義、またはその集合体の属性及び／またはメンバーシップを定義する他の定義を有してよい。例えば、グループは、同じ地理的な場所を有する認証対象のグループであってよい。その認証対象のグループの定義は、グループのメンバーシップ、場所、ならびにそのグループと関連付けられた他のデータ及び／またはメタデータを含んでよい。本明細書で使用するように、認証対象は、コンピューティングリソースサービスプロバイダにより管理されるアイデンティティに対応するエンティティであり、コンピューティングリソースサービスプロバイダは、アイデンティティに対する許可を管理し、エンティティは、それ自体アイデンティティを有する場合がある１つ以上のサブエンティティを含んでよい。

認証対象４０２は、１つ以上の接続（例えば、トランスミッションコントロールプロトコル（ＴＣＰ）接続）を介してコンピューティングリソースサービスプロバイダ４０６と通信してよい。認証対象４０２は、コンピューティングリソースサービスプロバイダ４０６に接続するためにコンピュータシステムクライアントデバイスを使用してよい。クライアントデバイスは、例えば以下に説明する例のデバイス等、ネットワークを介してコンピュータシステムと接続できる任意のデバイスを含んでよい。ネットワーク４０４は、例えばインターネットまたは以下に説明する別のネットワークもしくはネットワークの組み合わせを含んでよい。

コンピューティングリソースサービスプロバイダ４０６は、サービス４０８を通して、例えばバーチャルマシン（ＶＭ）インスタンス、自動スケーリンググループ、ファイルベースのデータベースストレージシステム、ブロックストレージサービス、冗長データストレージサービス、データアーカイブサービス、データウェアハウスサービス、ユーザーアクセス管理サービス、アイデンティティ管理サービス、コンテンツ管理サービス、及び／または係るコンピュータシステムサービス等の１つ以上のコンピューティングリソースへのアクセスを提供してよい。他の例のリソースは、ユーザーリソース、ポリシーリソース、ネットワークリソース、及び／またはストレージリソースを含むが、これに限定されるものではない。一部の例では、コンピュータサービスと関連付けられたリソースは、物理デバイス、仮想装置、物理デバイス及び／または仮想装置の組み合わせ、または他の係るデバイス実施形態であってよい。

サービス４０８へのアクセスに対する要求は、一部の例では、係る要求を受け取り、サービス４０８と関連付けられた１つ以上のポリシーに従ってそれらを処理するように構成されたウェブサーバを含むサービスフロントエンド４１０により受け取られてよい。サービス４０８へのアクセスに対する要求は、デジタル署名された要求である場合があり、結果としてデジタル署名を与えられてよい。一部の実施形態では、ウェブサーバは、要求を処理することと同期して、本明細書で説明する技術を利用する。サービスフロントエンド４１０は、次いで検証に対する要求及びデジタル署名を認証サービス４１６に送信してよい。認証サービス４１６は、スタンドアロンサービスである場合もあれば、サービスプロバイダまたは他のエンティティの一部である場合もある。認証サービス４１６は、一実施形態で、認証対象の認証に関与する動作を実行するように構成されたコンピュータシステムである。

要求を無事に認証すると、認証サービス４１６は、次いで要求に適用可能なポリシーを入手してよい。ポリシーは、認証対象４０２、要求の達成の一部としてアクセスされるリソース、認証対象４０２がメンバーであるグループ、認証対象４０２が引き受けた役割、及び／またはそれ以外と関連付けられていることにより要求に適用可能であってよい。要求に適用可能なポリシーを入手するために、認証サービス４１６は、ポリシー管理サービス４２０によって管理されるポリシーレポジトリ４１８にクエリーを送信してよい。ポリシーレポジトリ４１８に対するクエリーは、要求に適用可能なポリシーの集合を決定するほど十分な情報を含む要求であってよい。ポリシーレポジトリに対するクエリーは、例えば要求のコピーを含んでよい、及び／または例えば認証対象、リソース、及び／またはアクション（要求の達成の一部として実行される操作）を識別する情報等、要求内の情報に少なくとも部分的に基づいたパラメータを含んでよい。

ポリシー管理サービス４２０は、コンピューティングリソースへのアクセスに対する要求（例えば、ウェブサービスアプリケーションプログラミングインタフェース要求）に適用可能なポリシーへのアクセス及びポリシーの管理を提供してよい。例えば、ポリシー管理サービスは、未決の要求に適用可能なポリシーを選択するために十分な情報を受け取ってよい。一部の実施形態では、情報は、要求のコピーである場合もあれば、要求に少なくとも部分的に基づいて生成された情報である場合もある。例えば、サービスフロントエンド４１０等のサービスは、リソースへのアクセスに対する要求を受け取ってよく、要求により指定された情報に少なくとも部分的に基づいたポリシー管理サービスに対するクエリーを生成してよい。

要求に適用可能な任意のポリシーを入手した場合で、認証サービス４１６は、認証応答、及び該当する場合、入手したポリシーをサービスフロントエンド４１０に提供し直してよい。認証応答は、応答が無事に認証されたかどうかを示してよい。サービスフロントエンド４１０は、次いでサービス４０８へのアクセスに対する要求の達成が、権限付与モジュール４１２を使用し、入手されたポリシーに準拠するかどうかをチェックしてよい。一部の実施形態では、ポリシーは、要求の達成がポリシーに違反するかどうかが、一意性制約の違反が発生したかどうかに依存するように構成されてよいことに留意されたい。例えば、一部のデータは、他のデータよりも機密性が低いと見なされてよく、機密性が低いデータに対する要求は、一意性制約の違反の検出に関わらず満たされてよい。一方、より機密に関わるデータへのアクセスは、一意性制約違反が、要求の認証で使用されるために指定された公開鍵に関連して発生していないことを必要とする場合がある。類似する技術は、例えばコンピューティングデバイス、ストレージ場所、データ、アイデンティティ、ポリシー等の他のタイプのコンピューティングリソースのために利用されてよい。

権限付与モジュール４１２は、要求をポリシーの１つ以上の許可と比較して、サービスが要求を満たし得るかどうか（つまり、要求の達成が許可されるかどうか）を決定するよう作動するサービスフロントエンド上で実行中のプロセスであってよい。例えば、権限付与モジュールは、要求と関連付けられたＡＰＩ呼び出しを、ポリシーにより指定された、許可されたＡＰＩ呼び出しと比較して、要求が許されているかどうかを決定してよい。権限付与モジュール４１２が、要求をポリシーにより指定された許可に適合させることができない場合、権限付与モジュール４１２は、例えばサービスフロントエンドに要求を拒否させるメッセージをサービスフロントエンドに提供すること、及び拒否された要求をポリシー管理サービス４２０に記録させること等、１つ以上のデフォルトアクションを実行してよい。権限付与が、要求をポリシーにより指定された１つ以上の許可に適合させる場合、権限付与モジュール４１２は、（ポリシーによって定義される）最も制限的ではない応答を選択することによって、及びサービスフロントエンドに、要求の達成が、その選択した応答に基づいて許可される（つまり、適用可能なポリシーに準拠する）のかどうかを知らせることによってこれを解決してよい。また、権限付与モジュール４１２は、最も制限的な応答を選択する場合もあれば、なんらかの他の係る応答を選択し、要求の達成がその選択した応答に基づいて許可されるのかどうかをサービスフロントエンドに知らせてもよい。図４は、権限付与モジュール４１２をサービスフロントエンド４１０の構成要素として示すが、一部の実施形態では、権限付与モジュール４１２は、コンピューティングリソースサービスプロバイダ４０６により提供された別個のサービスであり、フロントエンドサービスは、ネットワークを介して権限付与モジュール４１２と通信してよいことにも留意されたい。

最後に、サービス４０８へのアクセスに対する要求の達成が適用可能な入手されたポリシーに準拠する場合、サービスフロントエンド４１０は、サービスバックエンド４１４を使用し、要求を満たしてよい。サービスバックエンド４１４は、サービスフロントエンド４１０から許可された要求を受け取るように構成され、係る要求を満たすように構成されたサービスの構成要素であってよい。サービスフロントエンド４１０は、例えば、要求を満たすことに関与する１つ以上の操作を実行させる要求をサービスバックエンド４１４に提出してよい。一部の例では、サービスバックエンド４１４は、サービスフロントエンドが認証対象４０２からの要求に応えて提供するデータをサービスフロントエンド４１０に提供し直す。一部の実施形態では、要求が許されたのか、それとも拒否されたのか、及び許された場合、要求の１つ以上の結果を示す認証対象４０２に対する応答が、サービスフロントエンド４１０から提供されてよい。

図５は、命題論理が、少なくとも部分的にポリシーに基づいて命題論理式の充足可能性を決定することの一部として使用される例示的な例を示す。図５は、例えば図１〜図４に関連して等、本開示の他の箇所に説明するものに従ってよい例のポリシー５０２を示す。図５は、（点線の下方に示す）命題論理が、ポリシー５０２が充足可能であるかどうかを決定するために使用される態様を示す。ポリシー５０２は、命題論理に対する制約である場合がある１つ以上のポリシーステートメントを含む場合がある。例のポリシーステートメント（例えば、許可ステートメント）は、図４に関連して本開示の他の箇所で説明される。

図５は、ポリシー５０２が充足可能であるかどうかを決定するために部分的に使用される命題論理を示す。図５では、命題論理は、ポリシーの充足可能性を決定するために部分的に使用される制約を示す。特に、図５は、ポリシーが許すことが、ポリシーにより明示的に拒否されなかったことであり、かつポリシーの１つ以上のステートメントのいずれかにより許されることに同等でなければならない旨の制約を示す。一部の実施形態では、命題論理は、１つ以上のＳＭＴ−ＬＩＢ規格に従ってよいＳＭＴ言語に従って表されてよい。ＣＶＣ言語、及びＣｅｎｔｅｒ ｆｏｒ Ｄｉｓｃｒｅｔｅ Ｍａｔｈｅｍａｔｉｃｓ ａｎｄ Ｔｈｅｏｒｅｔｉｃａｌ Ｃｏｍｐｕｔｅｒ Ｓｃｉｅｎｃｅｓ（ＤＩＭＡＣＳ）フォーマット等の他のフォーマットが、命題論理を記述するために使用されてよい。ＳＭＴ−ＬＩＢ規格：バージョン２．５、ＳＭＴ−ＬＩＢ規格バージョン２．０、ＳＭＴ−ＬＩＢ規格バージョン１．２、及びＳＭＴ−ＬＩＢ規格バージョン１．０は、参照により本明細書に援用される。

例えば、ＳＴＭ−ＬＩＢ規格ｖ２．０に従った実装は、以下の形で上述した制約を含んでよい。
（ａｓｓｅｒｔ（＝ｐｏｌｉｃｙＡ．ａｌｌｏｗｓ（ａｎｄ（ｎｏｔ ｐｏｌｉｃｙＡ．ｄｅｎｉｅｓ）（ｏｒ ｐｏｌｉｃｙＡ．ｓｔａｔｅｍｅｎｔ０．ａｌｌｏｗｓ ｐｏｌｉｃｙＡ．ｓｔａｔｅｍｅｎｔ１．ａｌｌｏｗｓ ｐｏｌｉｃｙＡ．ｓｔａｔｅｍｅｎｔ２．ａｌｌｏｗｓ...））））

ここで及び他の箇所で、例が、本開示の教示に従って多様な実施形態を実施する方法の概念を示すために示されることに留意されたい。例えば、上記例では、楕円は、２つを超える許可ステートメントを有するポリシーが、ＯＲステートメントを使用し結合されるより多くの制約を有することを示すために使用される。命題論理は、例えば多様なＳＴＭ−ＬＩＢ規格に従った実施形態等の多様な実施形態でのポーランド表記法（つまり、前置表記法）を使用し、表されてよいことに留意されたい。

図６は、命題論理が、少なくとも部分的にポリシーに基づいて命題論理式の充足可能性を決定することの一部として使用される例示的な例を示す。図６は、例えば図１〜図５に関連して等、本開示の他の箇所に説明するものに従ってよい例のポリシー６０２を示す。図６は、（点線の下方に示す）命題論理が、ポリシー６０２が充足可能であるかどうかを決定するために使用される態様を示す。ポリシー６０２は、命題論理に対する制約であってよい１つ以上のポリシーステートメントを含んでよい。例のポリシーステートメント（例えば、許可ステートメント）は、図２に関連して本明細書の他の箇所に説明される。

図６は、少なくとも部分的にポリシーに基づいて命題論理式の充足可能性を決定することの一部として使用されてよい命題論理を示す。図６では、命題論理は、ポリシーの充足可能性を決定するために部分的に使用される制約を示す。特に、図６は、ポリシーが拒否することが、ポリシーの１つ以上のステートメントのいずれかにより拒否されることに同等でなければならない旨の制約を示す。一部の実施形態では、命題論理は、１つ以上のＳＭＴ−ＬＩＢ規格に従ってよいＳＭＴ言語に従って表されてよい。ＣＶＣ言語、及びＣｅｎｔｅｒ ｆｏｒ Ｄｉｓｃｒｅｔｅ Ｍａｔｈｅｍａｔｉｃｓ ａｎｄ Ｔｈｅｏｒｅｔｉｃａｌ Ｃｏｍｐｕｔｅｒ Ｓｃｉｅｎｃｅｓ（ＤＩＭＡＣＳ）フォーマット等の他のフォーマットが、命題論理を記述するために使用されてよい。

例えば、ＳＴＭ−ＬＩＢ規格ｖ２．０に従った実装は、以下の形で上述した制約を含んでよい。
（ａｓｓｅｒｔ（＝ｐｏｌｉｃｙＡ．ｄｅｎｉｅｓ（ｏｒ ｐｏｌｉｃｙＡ．ｓｔａｔｅｍｅｎｔ０．ｄｅｎｉｅｓ ｐｏｌｉｃｙＡ．ｓｔａｔｅｍｅｎｔ１．ｄｅｎｉｅｓ ｐｏｌｉｃｙＡ．ｓｔａｔｅｍｅｎｔ２．ｄｅｎｉｅｓ...）））

言い換えると、上記の例によって提供されるのは、ポリシー（例えば、ポリシーＡ）が拒否することが、任意の個々のステートメント（例えば、ｓｔａｔｅｍｅｎｔ１、ｓｔａｔｅｍｅｎｔ２、ｓｔａｔｅｍｅｎｔ３等）が拒否することに同等である制約である。

図７は、命題論理が、少なくとも部分的にポリシーに基づいて命題論理式の充足可能性を決定することの一部として使用される例示的な例を示す。図７は、例えば図１〜図６に関連して等、本開示の他の箇所に説明するものに従ってよい例のポリシー７０２を示す。図７は、（点線の下方に示す）命題論理が、ポリシー７０２が充足可能であるかどうかを決定するために使用される態様を示す。ポリシー７０２は、命題論理に対する制約であってよい１つ以上のポリシーステートメントを含んでよい。例のポリシーステートメント（例えば、許可ステートメント）は、図２に関連して本明細書の他の箇所に説明される。

図７は、少なくとも部分的にポリシーに基づいて命題論理式の充足可能性を決定することの一部として使用されてよい命題論理を示す。図７では、命題論理は、ポリシーの充足可能性を決定するために部分的に使用される制約を示す。特に、図７は、ポリシーが中立であることが、ポリシーにより許可されないこと、及びポリシーによって拒否されないことに同等でなければならない旨の制約を示す。一部の実施形態では、命題論理は、１つ以上のＳＭＴ−ＬＩＢ規格に従ってよいＳＭＴ言語に従って表されてよい。ＣＶＣ言語、及びＣｅｎｔｅｒ ｆｏｒ Ｄｉｓｃｒｅｔｅ Ｍａｔｈｅｍａｔｉｃｓ ａｎｄ Ｔｈｅｏｒｅｔｉｃａｌ Ｃｏｍｐｕｔｅｒ Ｓｃｉｅｎｃｅｓ（ＤＩＭＡＣＳ）フォーマット等の他のフォーマットが、命題論理を記述するために使用されてよい。

例えば、ＳＴＭ−ＬＩＢ規格ｖ２．０に従った実装は、以下の形で上述した制約を含んでよい。
（ａｓｓｅｒｔ（＝ｐ０．ｎｅｕｔｒａｌ（ａｎｄ（ｎｏｔ ｐ０．ａｌｌｏｗｓ）（ｎｏｔ ｐ０．ｄｅｎｉｅｓ））））

言い換えると、上記の例によって提供されるのは、ポリシー（例えば、ポリシーＡ）が中立であることが、ポリシーにより許可されなかったこと及びポリシーにより拒否されなかったことに同等である制約である。

図５〜図７に関する説明に関連して、記述された制約は、以下の形で記述してよいポリシー（例えば、ポリシーＡ）のための制約を定義するために組み合わせて使用されてよい。
"Ｓｔａｔｅｍｅｎｔ"：［
｛
"Ｅｆｆｅｃｔ"："ＡＬＬＯＷ"，
"Ｐｒｉｎｃｉｐａｌ"："^＊"，
"Ａｃｔｉｏｎ"："^＊"，
"Ｒｅｓｏｕｒｃｅ"："^＊"
｝
］

同様に、第２のポリシー（つまり、ポリシーＢ）のための制約は、以下の形で記述されてよい。
"Ｓｔａｔｅｍｅｎｔ"：［
｛
"Ｅｆｆｅｃｔ"："ＡＬＬＯＷ"，
"Ｐｒｉｎｃｉｐａｌ"："^＊"，
"Ａｃｔｉｏｎ"："ｓｎｓ：^＊"，
"Ｒｅｓｏｕｒｃｅ"："^＊"
｝，
｛
"Ｅｆｆｅｃｔ"："ＡＬＬＯＷ"，
"Ｐｒｉｎｃｉｐａｌ"："^＊"，
"ＮｏｔＡｃｔｉｏｎ"："ｓｎｓ：Ｄｅｌｅｔｅ"，
"Ｒｅｓｏｕｒｃｅ"："^＊"
｝
］

したがって、これらの制約に加えて、追加の制約が、あるポリシーが別のポリシーよりもより許容性があるかどうかを決定するために利用されてよい。例えば、２つのポリシー（例えば、上記例のポリシーＡ及びポリシーＢ）を所与として、以下の制約が、第１のポリシー（例えば、ポリシーＡ）が、第２のポリシー（例えば、ポリシーＢ）よりもより許容性があるかどうかを決定するために使用されてよい。
（ａｓｓｅｒｔ（ｏｒ ｐＢ．ｎｅｕｔｒａｌ ｐＢ．ｄｅｎｉｅｓ））
（ａｓｓｅｒｔ ｐＡ．ａｌｌｏｗｓ）

多様な実施形態では、ポリシーアナライザサービスは、上記のポリシー（上述したポリシーＡ及びポリシーＢ）が同等であると決定するために利用されてよい。

デフォルトで拒否システムを実装する実施形態等の一部の実施形態では、権限付与モジュールは、要求者（例えば、認証対象）が（例えば、リソースへのアクセスを肯定的に許す許可ステートメントを介して）明示的にアクセスを許可されていないコンピューティングリソースサービスプロバイダの任意のリソースへのアクセスを拒否する。

例えば、ＳＴＭ−ＬＩＢ規格ｖ２．０に従った実装は、以下の形で上述した制約を含んでよい。
（ａｓｓｅｒｔ（＝ｐ０．ｎｅｕｔｒａｌ（ａｎｄ（ｎｏｔ ｐ０．ａｌｌｏｗｓ）（ｎｏｔ ｐ０．ｄｅｎｉｅｓ））））

言い換えると、上記の例によって提供されるのは、ポリシー（例えば、ポリシーＡ）が中立であることが、ポリシーにより許可されなかったこと及びポリシーにより拒否されなかったことに同等である制約である。

図８は、要素が（例えば、ポリシーの一部として）命題論理に変換される例示的な例を示す。変換は、例えば図１に関連して説明する命題論理変換装置等の任意の適切な構成要素によって実行されてよい。図８は、（点線の上方に示す）ＪＳＯＮ要素が（点線の下方に示す）命題論理に変換される例を示す。命題論理は、１つ以上のＳＭＴ−ＬＩＢ規格に従ってよいＳＭＴ言語に従って表されてよい。

一例として、（例えば、許可ステートメントの他の箇所で指定された）いくつかのリソースへのアクセスを許す許可ステートメントの効果要素は、以下の制約とともに命題論理として表されてよい。
（ａｓｓｅｒｔ（＝ｐｏｌｉｃｙ．ｓｔａｔｅｍｅｎｔ．ａｌｌｏｗｓ（ａｎｄ ｐｏｌｉｃｙ．ａｃｔｉｏｎ ｐｏｌｉｃｙ．ｒｅｓｏｕｒｃｅ ｐｏｌｉｃｙ．ｐｒｉｎｃｉｐａｌ）））
（ａｓｓｅｒｔ（ｎｏｔ ｐｏｌｉｃｙ．ｓｔａｔｅｍｅｎｔ．ｄｅｎｉｅｓ））

言い換えると、許可効果は、命題論理の２つの制約−ポリシーステートメントが許可効果を有する旨、及びアクション、リソース、及び認証対象の制約が満たされる旨の第１の制約、ならびにポリシーステートメントが拒否効果を有していない旨の第２の制約−を生成する。アクション、リソース、及び認証対象の制約は、図８〜図１１に関連して説明する制約に従ってよい。また、制約は、どの要素が許可ステートメントに含まれるのかに応じて異なる場合もある。例えば、許可ステートメントが条件を含む場合、制約は、条件が、満たされるべき制約のために満たされることをさらに含んでよい。一部の実施形態では、アクション、リソース、及び認証対象の要素のうちの少なくとも１つは、有効なポリシーステートメントが、アクション、リソース、及び認証対象の要素のうちの少なくとも１つを有さなければならないように、許可ステートメントの必須要素となる。

図９は、要素が（例えば、ポリシーの一部として）命題論理に変換される例示的な例を示す。変換は、例えば図１に関連して説明する命題論理変換装置等の任意の適切な構成要素によって実行されてよい。図９は、（点線の上方に示す）ＪＳＯＮ要素が（点線の下方に示す）命題論理に変換される例を示す。命題論理は、１つ以上のＳＭＴ−ＬＩＢ規格に従ってよいＳＭＴ言語に従って表されてよい。

一例として、（例えば、許可ステートメントの他の箇所に指定された）いくつかのリソースへのアクセスを（許可ステートメントの効果要素に応じて）許可するまたは拒否する許可ステートメントのアクション要素は、以下の制約とともに命題論理として表されてよい。
（ａｓｓｅｒｔ（＝ｐｏｌｉｃｙ．ａｃｔｉｏｎ（ｏｒ（ａｎｄ（＝"ｓｔｏｒａｇｅ"ａｃｔｉｏｎＮａｍｅｓｐａｃｅ）（ｓｔｒ．ｐｒｅｆｉｘｏｆ"Ｄｅｌｅｔｅ"ａｃｔｉｏｎＮａｍｅ）））））

言い換えると、図９の点線の上方のアクション要素は、アクションが「ｓｔｏｒａｇｅ」名前空間、及び例えば「ＤｅｌｅｔｅＯｂｊｅｃｔ」または「ＤｅｌｅｔｅＡｌｌＯｂｊｅｃｔｓ」または「ＤｅｌｅｔｅＣｏｎｔａｉｎｅｒ」等の「Ｄｅｌｅｔｅ」の文字列プレフィックスを有するアクション名を有するときに満たされる制約を有する命題論理に変換されてよい。一部の実施形態では、多様な文字列評価関数は、例えば、文字列のプレフィックス、サフィックス、長さ、部分列（例えば、特定の文字列が第２の文字列の一部として含まれるかどうか）等を評価すること等、制約の一部として使用されてよい。文字列の比較は、例えば大文字と小文字を区別しない比較を行うこと、記号及び句読点を無視すること、付加記号を無視すること、ひらがな文字とカタカナ文字の違いを無視すること等の追加の比較パラメータをさらに含んでよい。効果、アクション、リソース、及び認証対象の制約は、図８〜図１１に関連して説明する制約に従ってよい。また、制約は、どの要素が許可ステートメントに含まれるのかに応じて異なる場合もある。例えば、許可ステートメントが条件を含む場合、制約は、条件が、満たされるべき制約のために満たされることをさらに含んでよい。一部の実施形態では、効果、アクション、リソース、及び認証対象の要素のうちの少なくとも１つは、有効なポリシーステートメントが、効果、アクション、リソース、及び認証対象の要素のうちの少なくとも１つを有さなければならないように、許可ステートメントの必須要素となる。

図１０は、要素が（例えば、ポリシーの一部として）命題論理に変換される例示的な例を示す。変換は、例えば図１に関連して説明する命題論理変換装置等の任意の適切な構成要素によって実行されてよい。図１０は、（点線の上方に示す）ＪＳＯＮ要素が（点線の下方に示す）命題論理に変換される例を示す。命題論理は、１つ以上のＳＭＴ−ＬＩＢ規格に従ってよいＳＭＴ言語に従って表されてよい。

一例として、リソースへのアクセスを（許可ステートメントの効果要素に応じて）許可するまたは拒否する許可ステートメントのリソース要素は、以下の制約とともに命題論理として表されてよい。
（ａｓｓｅｒｔ（＝ｐｏｌｉｃｙ．ｒｅｓｏｕｒｃｅ（ｏｒ（ａｎｄ（＝"ｓｔｏｒａｇｅ"ｒｅｓｏｕｒｃｅＳｅｒｖｉｃｅ）（＝""ｒｅｓｏｕｒｃｅＡｃｃｏｕｎｔ）（ｓｔｒ．ｐｒｅｆｉｘｏｆ"ｆｏｏ／"ｒｅｓｏｕｒｃｅＲｅｓｏｕｒｃｅ））（ａｎｄ（＝"ｓｔｏｒａｇｅ"ｒｅｓｏｕｒｃｅＳｅｒｖｉｃｅ）（＝"ｕｓｅｒ"ｒｅｓｏｕｒｃｅＡｃｃｏｕｎｔ）（ｓｔｒ．ｐｒｅｆｉｘｏｆ"ｂａｒ／"ｒｅｓｏｕｒｃｅＲｅｓｏｕｒｃｅ）））））

言い換えると、図９の点線の上方のリソース要素は、一部の実施形態では、リソースが「ｓｔｏｒａｇｅ」サービス名前空間、空白のリソースアカウント、及び「ｆｏｏ／」を有するリソース存在を有するとき、またはリソースが「ｓｔｏｒａｇｅ」サービス名前空間、「ｕｓｅｒ」アカウント、及び「ｂａｒ／」を有するリソース存在を有するときに満たされる制約を有する命題論理に変換されてよい。効果、アクション、リソース、及び認証対象の制約は、図８〜図１１に関連して説明する制約に従ってよい。また、制約は、どの要素が許可ステートメントに含まれるのかに応じて異なる場合もある。例えば、許可ステートメントが条件を含む場合、制約は、条件が、満たされるべき制約のために満たされることをさらに含んでよい。一部の実施形態では、効果、アクション、リソース、及び認証対象の要素のうちの少なくとも１つは、有効なポリシーステートメントが、効果、アクション、リソース、及び認証対象の要素のうちの少なくとも１つを有さなければならないように、許可ステートメントの必須要素となる。

図１１は、要素が（例えば、ポリシーの一部として）命題論理に変換される例示的な例を示す。変換は、例えば図１１に関連して説明する命題論理変換装置等の任意の適切な構成要素によって実行されてよい。図１１は、（点線の上方に示す）ＪＳＯＮ要素が（点線の下方に示す）命題論理に変換される例を示す。命題論理は、１つ以上のＳＭＴ−ＬＩＢ規格に従ってよいＳＭＴ言語に従って表されてよい。

一例として、（例えば、許可ステートメントの他の箇所で指定された）いくつかのリソースへのアクセスを許す許可ステートメントの効果要素は、以下の制約とともに命題論理として表されてよい。
（ａｓｓｅｒｔ（＝ｐｏｌｉｃｙ．ｃｏｎｄｉｔｉｏｎ（＝＞ＳｏｕｒｃｅＶｐｃｅ＿ｅｘｉｓｔｓ｜（＝"ｂａｚ"ＳｏｕｒｃｅＶｐｃｅ））））

言い換えると、図１１の点線の上方のリソース要素は、リソースに対して「ｓｏｕｒｃｅＶｐｃｅ」条件キー（例えば、ソースバーチャルＰＣインスタンスの名前を指定するフィールド）が存在し、そのリソース上に「ｂａｚ」の値を有するときに満たされる制約を有する命題論理に変換されてよい。一部の実施形態では、含意演算子は、制約の一部として利用されてよい。一部の実施形態では、含意は、図１１に示す「＝＞」等の演算子で示されてよく、前提条件が真であるときかつそのときに限り評価される述部を含んでよい。例えば、部分的に以下のように読める点線の上方に示す式を検討する。
ＳｔｒｉｎｇＥｑｕａｌｓＩｆＥｘｉｓｔｓ"：｛"ｓｏｕｒｃｅＶｐｃｅ"："ｂａｚ"｝

この式は、前提条件が真であるときかつそのときに限り、述部が評価されるように命題論理制約に変換されてよい。図１１では、前提条件は、「ｓｏｕｒｃｅＶｐｃｅ」条件キーが存在することであってよく、述部は、「ｓｏｕｒｃｅＶｐｃｅ」条件キーの値が、図１１の点線の下方に記述する文字列「ｂａｚ」に等しいことであってよい。例えば、図１１に関連して記述された条件が、図１０に関連して記述されたリソースに適用する許可ステートメントに含まれる場合を考える。係る場合、「ｓｏｕｒｃｅＶｐｃｅ」条件キーを有する「ｆｏｏ／」及び「ｂａｒ」内のいくつかのリソース及び／またはリソースのタイプ、ならびに条件キーを有していない他のリソース及び／またはリソースのタイプがある場合がある。リソースまたはリソースのタイプが「ｓｏｕｒｃｅＶｐｃｅ」条件キーを有さない場合、述部は評価されない（または述部が満たされたかのように意味論的に扱われてよい）。一部の実施形態では、「ｓｏｕｒｃｅＶｐｃｅ」フィールドがリソースについて存在しない場合、条件はそのリソースについて評価されない。効果、アクション、リソース、及び認証対象の制約は、図８〜図１１に関連して説明する制約に従ってよい。また、制約は、どの要素が許可ステートメントに含まれるのかに応じて異なる場合もある。例えば、許可ステートメントが条件を含む場合、制約は、条件が、満たされるべき制約のために満たされることをさらに含んでよい。一部の実施形態では、効果、アクション、リソース、及び認証対象の要素のうちの少なくとも１つは、有効なポリシーステートメントが、効果、アクション、リソース、及び認証対象の要素のうちの少なくとも１つを有さなければならないように、許可ステートメントの必須要素となる。

図１２は、２つ以上のセキュリティポリシーの同等性を決定するためのプロセス１２００の例示的な例を示す。概して、プロセス１２００は、図１に関連して説明したもの等、本開示の他の箇所で説明するポリシーアナライザサービス等の任意の適切なシステムによって実行されてよい。プロセスは、ハードウェア、ソフトウェア、及びその組み合わせを使用し、実装され得る。一実施形態では、プロセス１２００は、第１のセキュリティポリシー及び第２のセキュリティポリシーを指定する情報を受け取ること１２０２を含む。一部の実施形態では、システムは、例えばウェブＡＰＩ要求等、インタフェースの一部として情報を受け取る。一部の実施形態では、セキュリティポリシーは、例えばＪＳＯＮ等の、言語に依存しないフォーマットで表されてよい、セキュリティ許可の集合をそれぞれ符号化する。セキュリティ許可は、図２に関連して等、本開示の他の箇所に説明するものに従ってよい。一部の実施形態では、どちらかまたは両方のポリシーを指定する情報は、直接的に（例えば、要求のデータペイロードの一部として符号化されてよい）または間接的に（例えば、ポリシーに対する参照は、参照が、例えばポリシー管理サービスから等、ポリシーを入手するために使用され得るように、システムによって受け取られる）指定されてよい。

システムは、少なくとも部分的に第１のセキュリティポリシーに基づいて第１の命題論理式を決定してよい（１２０４）。決定はさらに、第１のセキュリティポリシーと関連付けられるセキュリティ許可の第１の集合に基づいて行われてよい。決定は、本開示の他の箇所に説明する多様な実施形態に従って行われてよい。例えば、システムは、パーサーを使用し、第１のセキュリティポリシーからセキュリティ許可の第１の集合を入手するためにパーサーを使用してよく、例えば図１〜図１１に関連して上述したように、セキュリティ許可の第１の集合を命題論理の制約の集合に変換してよい。一部の実施形態では、システムは、ＪＳＯＮで表されるセキュリティポリシーを、例えばＳＴＭ−ＬＩＢ２．０規格等のＳＭＴ−ＬＩＢ規格に従って記述された（例えば、１つ以上の制約を含んだ）命題論理式に変換する。

システムは、第１の命題論理式を決定すること（１２０４）に関連して上述したのと同じように、または実質的に類似したように第２の命題論理式を決定してよい（１２０６）。しかしながら、一部の実施形態では、ステップは異なる場合がある。例えば、一部の場合には、第２のセキュリティポリシーが要求の中で間接的に参照される（例えば、要求は、第１のセキュリティポリシーが標準セキュリティポリシーに準拠するかどうかを決定する要求である）のに対して、システムは、要求で第１のセキュリティポリシーを直接的に受け取ってよい（例えば、ポリシーを符号化するデータが要求に含まれてよい）。係る実施形態では、システムは、第２のセキュリティポリシーを指定する要求に含まれる情報を使用し、第２のセキュリティポリシーを入手し、次いで入手した第２のセキュリティポリシーを使用し、第２の命題論理式を入手してよい。例えば図１〜図１１に関連して説明する技術等の技術が利用されてよい。

システムは、第１の命題論理及び第２の命題論理が同等であるかどうか（１２０８）を決定してよい。２つのポリシーは、第１のポリシー及び第２のポリシーからのセキュリティ許可が、すべてのアクション、リソース、及び認証対象に同じように適用する場合に同等であると言われてよい−言い換えると、第１のポリシーと第２のポリシー両方ともが（拒否ステートメントに基づいて明示的にもしくはアクセスを許可する許可の欠如に基づいて暗示的に、のどちらかで）アクセスを拒否する、または両方ともがアクセスを許可するアクション、リソース、及び認証対象の任意の所与の集合の場合−一方のポリシーがアクセスを許可し、他方が拒否することは当てはまらない。あるポリシーが別のポリシーよりもより許容性があると決定される場合、あるポリシーは、別のポリシーがアクセスを拒否するパラメータの集合下でアクセスを許可する場合がある。

充足可能性エンジンは、２つ以上の命題論理式の許容性を解析するために使用されてよく、これは２つの命題論理式が同等であるかどうかを決定することを含む。充足可能性エンジンは、命題論理制約（例えば、第１の命題論理式及び第２の命題論理式から入手される制約、ならびに充足可能性エンジンにより生成される制約）が同等であるかどうかを検証するために使用されてよい。一部の実施形態では、２つ以上の命題論理式が同等であるかどうかを決定することは、少なくとも部分的に、例えばＺ３等のＳＭＴソルバーを使用し、実施されてよい。より一般的には、命題論理式及び命題論理制約の許容性、相対的な許容性、及び／または同等性を決定するための、本明細書に説明する技術は、第１の命題論理式及び第２の命題論理式が同等であるかどうか（１２０８）を決定することに関連して使用されてよい。

一部の実施形態では、プロセス１２００は、セキュリティポリシーが、ＳＭＴソルバーにより認識される特定のフォーマットで命題論理式にマッピングされるように１つ以上の変換を実行することを含んでよい。例えば、Ｚ３ソルバーが、同等性を決定することに関連して使用される場合、次いでセキュリティポリシーは、例えばＳＴＭ−ＬＩＢ２．０規格等のＳＭＴ−ＬＩＢ規格言語に従ったフォーマットにマッピングされてよい。

システムが、第１の命題論理式及び第２の命題論理式が同等であると決定する場合、次いでシステムは、ポリシーが同等である旨の表示を提供してよい（１２１４）。一部の実施形態では、表示は、ウェブＡＰＩ要求に応えて符号化されてよい。

しかしながら、システムが、第１の命題論理式及び第２の命題論理式が同等ではないと決定する場合、次いでシステムは、第１の命題論理式及び第２の命題論理式が同等性を欠くと決定するために十分であるパラメータの集合を識別してよい（１２１０）。パラメータの集合は、１つ以上のリソース、１つ以上の認証対象、１つ以上のアクション、またはそのなんらかの組み合わせを符号化してよい。一部の実施形態では、パラメータの集合は、パラメータの集合を使用する第１のセキュリティポリシー−言い換えると、結果がアクセスの許可であるのか、それともアクセスの拒否であるのかーを評価することの結果が、パラメータの同じ集合を使用し、第２のセキュリティポリシーを評価することの結果とは異なるため、第１の命題論理に対応する第１のセキュリティポリシー、及び第２の命題論理に対応する第２のセキュリティポリシーが同等ではないことを明示するために使用されてよい。別の言い方をすれば、パラメータの特定の集合の場合、第１のセキュリティポリシーは、それらのパラメータに基づいてアクセスを許可し、第２のセキュリティポリシーは、それらの同じパラメータに基づいてアクセスを拒否する、または逆もまた同様である場合もある。一部の実施形態では、システムは、命題論理式が同等であるかどうか（１２０８）を決定することの一部としてパラメータの集合を識別してよい（１２１０）。一部の場合には、システムは、セキュリティポリシーが同等ではない旨の表示としてウェブＡＰＩ応答の一部としてパラメータの集合を提供してよい（１２１２）。一部の実施形態では、パラメータの集合は提供されない場合があるが、代わりに表示（例えば戻りコード）が、ポリシーが同等であるかどうかを示してよい。例えば、セキュリティポリシーが同等である場合にＴＲＵＥが返され、セキュリティポリシーが同等ではない場合にＦＡＬＳＥが返されるようにブール値が返されてよい。代わりに、セキュリティポリシーが同等である場合に０が返され、第１のセキュリティポリシーが第２のセキュリティポリシーよりもより許容性がある場合に−１が返され、第２のセキュリティポリシーが第１のセキュリティポリシーよりもより許容性がある場合に１が返されるように、整数値が返されてよい。

プロセス１２００に示す多様なステップの順序は単に例示的にすぎず、第２の命題論理式の決定すること（１２０６）は、第１の命題論理式の決定すること（１２０４）の前に及び／またはと同時に、のどちらかで発生する場合もある。実際には、一部の実施形態では、順序付けが非決定性である場合もある。例えば、決定１２０４及び１２０６は同時に実行されてよく、異なる計算性能特性を有する場合がある計算インスタンスのプールの計算インスタンスを分離するためにアウトソーシングされる場合がある。

図１３は、本開示の多様な実施形態を実践できる環境１３００の例示的な例である。一実施形態では、環境１３００は、クライアントコンピューティングデバイス１３０２、ポリシー管理サービス１３０４、ポリシーレポジトリ１３０６、イベント駆動型プラットフォーム１３１０、ポリシー監視サービス１３１２、及びポリシーアナライザサービス１３１４を含む。環境１３００は、クライアントが、対応するイベント１３０８を生成するポリシーを適用してよく、イベント１３０８が次にイベント駆動型プラットフォーム１３１０をトリガして、１つ以上のポリシーを解析する例を示す。クライアントコンピュータシステムが、一連の規則に適合しないセキュリティポリシーを適用するまたは適用しようと試みる等の一部の場合には、ネットワークの管理者１３１６は、おそらく例えば非準拠のポリシーを適用する要求を満たすことを拒否する等の他のアクションに加えて通知されてよく、ポリシーが非準拠である旨の警告をクライアントに提供してよい、または追加の監査ステップを実行してよい。

一部の実施形態では、例えば図４に関連して説明するもの等、コンピューティングリソースサービスプロバイダは、コンピューティングリソースサービスプロバイダのクライアントが環境の中でセキュリティポリシーを適用できるように構成される。一部の実施形態では、クライアントは、ポリシー管理サービス１３０４によりサポートされるウェブＡＰＩを使用し、セキュリティポリシーを設定するためにコマンドラインインタフェースを使用する。ポリシー管理サービス１３０４は、セキュリティポリシーを適用するウェブＡＰＩ要求を受け取り、要求を満たすことの一部として、１つ以上の権限付与手順及び認証手順を実行してよい。ポリシーは、適用され、それが後で用いるために取り出すことが可能であるポリシーレポジトリ１３０６に記憶されてよい。一部の実施形態では、ポリシーを適用すること、及び／または適用したポリシーをポリシーレポジトリ１３０６に記憶することは、ロギングシステムを介して対応するロギングエントリを生成する。ロギングシステムは、例えばコンピューティングリソースサービスプロバイダに対してなされたウェブＡＰＩ要求に関する情報を記録する等、ネットワーク全体で一部のまたはすべての活動を記録に残すために使用されてよい。

イベント１３０８は、セキュリティポリシーの適用、またはセキュリティポリシーを適用することから生じる１つ以上の下流のアクションに応えて生成されてよい。例えば、イベント１３０８は、セキュリティポリシーを適用するためのウェブＡＰＩ呼び出し、ポリシーをポリシーレポジトリに記憶すること、セキュリティポリシーの適用及び／またはポリシーのポリシーレポジトリへの記憶を記録に残すこと、またはそのなんらかの組み合わせによってトリガされてよい。

イベント駆動型プラットフォーム１３１０は、いつイベント１３０８が発生するのかを決定し、イベントがトリガされることに応えてカスタム論理を実行してよい。イベントトリガは、例えば、ポリシーが適用されるときに検出される場合もあれば、例えば非同期プロセス（例えば、毎日実行される）がロギングイベントを処理し、セキュリティポリシーが適用されたことを検出する場合等、後の時点で決定される場合もある。イベント駆動型プラットフォーム１３１０は、ソフトウェア、ハードウェア、またはその組み合わせで実装され得る。一部の実施形態では、分散型コンピューティングリソースは、イベントに応えてカスタム論理／コードをプロビジョニングし、ロードし、コードを実行し、次いでコードをアンロードし、コンピューティングリソースをデプロビジョニングする場合がある。イベント駆動型プラットフォーム１３１０は、コンピューティングリソースサービスプロバイダの構成要素である場合もあれば、別個の構成要素である場合もある。

イベント駆動型プラットフォーム１３１０は、イベント駆動型のアーキテクチャを使用し、実装されてよい。例えば、セキュリティポリシーを適用するウェブＡＰＩ要求等の特定のイベントが発生すると、イベント駆動型プラットフォーム１３１０は、（例えば認証サービスにより）そのイベントを通知されてよく、イベント駆動型プラットフォームは、別個に（例えば、要求が向けられているポリシー管理サービスから）入手されてよい、要求に関する追加の情報をさらに受け取ってよい。イベント駆動型プラットフォーム１３１０は、要求について入手された情報に基づいて選択されるカスタマコードまたはカスタマ論理によって部分的に処理されてよい、イベントの処理方法を決定してよい−例えば、カスタム論理は、セキュリティポリシーが適用するリソースのタイプに基づいてセキュリティポリシーについて異なってよい。一部の実施形態では、イベント駆動型プラットフォーム１３１０は、イベントのために認証サービスから通知メッセージをサブスクライブしてよく、認証サービスは、イベント駆動型プラットフォームが通知を受け取るためにサブスクライブするイベントに応えて（例えば、ラムダ式等の）コールバック関数を呼び出してよい。

イベント駆動型プラットフォーム１３１０は、イベント１３０８を受け取り、内部で（例えば、イベント駆動型プラットフォームの構成要素を使用し）または外部で（例えば、別のサービスに委譲することによって）イベントを処理する方法を決定してよい。一例として、イベント駆動型プラットフォームは、適用されている特定のタイプのセキュリティポリシー、または適用されているセキュリティポリシーと関連付けられた他のメタデータに基づいて、カスタム論理のリストの中でどれが呼び出されるべきなのかに関する規則を含んでよい。セキュリティポリシータイプのカスタム論理に対するマッピングが存在してよい。例えば、第１のカスタム論理は、第１のサービス名前空間を有するコンピューティングリソースに適用するセキュリティポリシーに基づいて呼び出されてよく、第２のカスタム論理は、第２のサービス名前空間を有するコンピューティングリソースに適用するセキュリティポリシーに基づいて呼び出されてよい。

ポリシー監視サービス１３１２は、イベント駆動型プラットフォーム１３１０によって呼び出されてよい。一部の実施形態では、イベント駆動型プラットフォーム１３１０は、ポリシー監視サービス１３１２を呼び出し、イベント１３０８をトリガしたセキュリティポリシーに関する文脈情報を提供し、それによりポリシー監視サービス１３１２が、例えば適用したポリシーの多様なパラメータに基づいて多様なカスタム論理を実行できるようにする。例えば、コンピューティングリソースサービスプロバイダは、多様なタイプのコンピューティングリソースのためのいくつかのサービスをサポートしてよく、一連のベストプラクティス規則は、セキュリティポリシーが適用するコンピューティングリソースのタイプに基づいて異なる場合がある。ポリシー監視サービス１３１２は、リソースタイプのための基準ポリシーを決定し、ポリシーアナライザサービス１３１４を利用して、適用したポリシーが基準ポリシーよりもより許容性があるかどうかを決定してよい。ポリシーアナライザサービス１３１４は、図１〜図１２に関連して等、本開示の他の箇所に説明するものに従ってよい。

ポリシーアナライザサービス１３１４が、適用したポリシーが適用可能な基準ポリシーよりもより許容性があることを示す場合、次いでポリシー監視サービス１３１２は、多様な軽減手順を実行してよい。例えば、ポリシー管理サービス１３０４は、セキュリティポリシーを適用するウェブＡＰＩ要求が、基準ポリシーよりもより許容性があることを通知され、ポリシー管理サービス１３０４に要求を拒否する（つまり、要求を満たすことを拒絶する）ように指示する場合がある。一部の場合には、セキュリティポリシーを適用する要求の達成は、ポリシー管理サービス１３０４がポリシー監視サービスから、要求が許可されるべきである旨の表示を受け取ることを条件にする場合がある。要求者（例えば、クライアント）は、要求のセキュリティポリシーが許容性がありすぎると通知される場合がある。一部の場合には、要求者は、セキュリティポリシーを改正するまたはそれを適用するための機会を与えられる。許容性がありすぎるセキュリティポリシーを適用した結果、システム管理者１３１６が通知され、セキュリティポリシーが後の時点で監査される別個のシステムに記録され、多様な他の軽減を生じさせる場合がある。言うまでもなく、例えばネットワークセキュリティチーム等の組織の中の他のエンティティが知らされてよい。

図１４は、システムに適用されているポリシーを監視するためのプロセス１４００の例示的な例を示す。概して、プロセス１４００は、図１３に関連して説明したもの等、本開示の他の箇所で説明するイベント駆動型プラットフォーム等の任意の適切なシステムによって実行されてよい。プロセスは、ハードウェア、ソフトウェア、及びその組み合わせを使用し、実装され得る。一実施形態では、プロセス１４００は監視ルーチンを含む。一例として、システムは、コンピューティングリソースサービスプロバイダの入ってくる要求を監視してよい（１４０２）。監視エージェントは、要求（例えば、ウェブＡＰＩ呼び出し）のために入ってくるトラフィックを構文解析し、要求がポリシーを適用するかどうかを決定する（１４０４）ために利用されてよい。これに関連して、監視１４０２ステップが、（例えば、監視エージェントが積極的にロギングシステムをポーリングして、要求が受け取られたかどうかを決定する場合等）アクティブな監視プロセス、または（例えば、サービスフロントエンドが、入ってくる要求がポリシーを適用すると決定すると、監視エージェントを呼び出す場合等）パッシブな監視プロセスである場合があることにさらに留意されたい。

より一般的には、監視エージェントは、入ってくる要求自体または要求により生じる下流効果を追跡するために利用できる。例えば、一部の場合には、コンピューティングリソースサービスプロバイダへのウェブＡＰＩ要求はサービスフロントエンドで構文解析され、コンピューティングリソースサービスプロバイダのいくつかのサービスの間で分散される。一部の場合には、監視エージェントは、いつ要求がポリシー管理サービスに転送されるのかを検出し、それらの要求を構文解析して、要求がポリシーを適用するかどうかを決定してよい。別の例として、いくつかのまたはすべての要求は、要求が受け取られると、ロギングシステムに記録されてよい。ロギングシステムは、呼び出された特定のウェブＡＰＩ、ＡＰＩ呼び出しのパラメータ等、要求についての情報を記録してよい。監視エージェントは、いつ要求がポリシーを適用するのかを決定するために要求により生成されるログを読み取ってよい。係るシステムは、要求のロギングに同時期に、または後に、のどちらかで実行されてよい−例えば、監視エージェントは、システムに課された規則に違反する場合がある任意のポリシーが実施されているかどうかをチェックするために、１日に１度ログを監査してよい。

システムが、要求がポリシーを適用しないと決定する場合、次いでシステムは要求を監視し続けてよい。代わりに、システムが、要求がセキュリティポリシーを適用すると決定する場合、システムは、セキュリティポリシーの１つ以上のセキュリティ許可に少なくとも部分的に基づいてポリシー検証ルーチンを選択してよい（１４０６）。例えば、ポリシー検証ルーチンは、セキュリティ許可の認証対象要素に基づいたポリシー検証ルーチンのリストから選択されてよい−ゲストまたは匿名ユーザーと関連付けられたポリシー検証ルーチンは、ゲストまたは匿名ユーザーが受け取る場合がある特権の最大限に許容性のある集合を制限し得る。第２の例として、ポリシー検証ルーチンは、セキュリティ許可のリソース要素で符号化されたサービス名前空間に基づいて選ばれてよい−サービス名前空間で指定される特定のリソースタイプのための特権の最大限に許容性のある集合は、サービスごとに変わる場合がある。

ポリシー検証ルーチンが選択されると、ポリシー検証ルーチンが呼び出されてよい。イベント駆動型プラットフォームは、ポリシー検証ルーチンを選択すること、及び選択したポリシー検証ルーチンを呼び出すことに関連してステップのうちの少なくともいくつかを実行してよい。１つ以上のベースラインポリシーは、選択したポリシー検証ルーチンに関連して入手されてよい（１４０８）。システムは、多数のベースラインポリシーを有してよく、１つ以上のベースラインポリシーの選択は、ポリシー検証ルーチン及び呼び出されるポリシー検証ルーチンをトリガしたセキュリティポリシーに付けられた許可に基づいてよい。

ポリシー検証ルーチンにより入手された１つ以上のベースラインポリシーは、要求に適用されているセキュリティポリシーに対して比較されてよい（１４１０）。基準ポリシーは、ポリシーを適用しているウェブＡＰＩ要求の入力パラメータ等の多様な要因に基づいて選択されてよい。ベースラインポリシーは、許可されてはならない許可の集合であると決定されるベストプラクティスポリシーである場合がある。例えば、ベースライン慣例ポリシーは、ストレージサービスのリソースが全ユーザーに書き込み権限がある（例えば、任意の認証対象、ゲストユーザー、または匿名のユーザーがコンテナに書き込むことができる）べきではないということであってよい。

システムは、要求により適用されているポリシーが、基準ポリシーよりもより許容性があるかどうかを決定してよい（１４１２）。例えば図１〜図４に関連して説明するもの等のポリシーアナライザサービスは、要求の中で適用されているセキュリティポリシーを基準ポリシーに比較するために利用されてよい。より一般的には、ＳＭＴベースの制約ソルバー（例えば、Ｚ３）等の制約ソルバーは、要求の中で適用されているセキュリティポリシーが、より許容性があるのか、それとも基準ポリシーと等しく許容性があるのかを決定するために利用されてよい。

一部の実施形態では、要求により適用されているポリシーが、基準ポリシーよりもより許容性があるのかを決定することは、ファザーを使用し、実行されてよい。ファザーは、インタフェースへの入力の集合を決定することによってソフトウェア構成要素を試験し、出力が予測値と一致することを検証するように構成可能な実行可能コードを含むソフトウェアモジュールであってよい。例えば、ファザーは、ルックアップテーブルから入力の集合を選択し、演算の集合（例えば、除算）を実行することによってプロセッサの算術演算を試験し、出力ルックアップテーブルに基づいて結果が正しいことを検証するために利用できる。ファザーは、パラメータ（例えば、認証対象、アクション、及びコンピューティングリソース）の集合を選択し、パラメータの集合に対応する要求が、要求のセキュリティポリシー及び基準ポリシーの下で満たされるかどうかを決定してよい。一方のポリシーが要求を満たし、他方が要求を拒否する場合、次いで２つのポリシーの相対的な許容性が決定されてよい（例えば、その一方のポリシーが他方よりもより許容性がある、２つのポリシーが比較できない等）。一部の実施形態では、ファザーは、試験するパラメータの所定のリストを有してよい。一部の実施形態では、ファザーは、パラメータの集合を無作為に選択してよい。

システムが、要求のセキュリティポリシーが基準ポリシーよりもより許容性がないと決定する場合、係る情報は示されてよい。一部の実施形態では、ポリシー管理サービスがセキュリティポリシーを設定する要求を受け取ると、要求のセキュリティポリシーは、上述したように解析されて、セキュリティポリシーが適用可能なベースラインポリシーに準拠するかどうかを決定してよい。一部の場合には、要求の達成（例えば、ポリシーデータベースにセキュリティポリシーを適用すること）は、要求の中で適用されているセキュリティポリシーが、ありとあらゆる適用可能なポリシー検証ルーチンに準拠している旨の表示を受け取ることを条件にする。したがって、セキュリティポリシーを適用する要求が受け取られると、ポリシー管理サービスは、要求を満たす前にポリシー検証ルーチンからの応答を待機してよく、ポリシー検証ルーチンは、要求が満たされるべきである旨の表示（１４１６）を提供してよい。しかしながら、これが当てはまる必要はない−一部の場合には、ポリシー管理サービスは、ポリシー検証ルーチンからの表示を待機することなくセキュリティポリシーを設定する。

代わりに、システムが、要求のセキュリティポリシーが基準ポリシーよりもより許容性があると決定する場合、係る情報は示されてよい（１４１４）。一部の実施形態では、クライアントは、セキュリティポリシーを適用する要求を提出するためにＧＵＩを使用してよい。要求のセキュリティポリシーが基準ポリシーよりもより許容性があることを検出したことに応えて、失敗コードがクライアントに返されてよく、失敗コードは例えばポップアップウィンドウとしてＧＵＩで提示されてよい。クライアントがコマンドラインインタフェースを使用する場合、失敗コードはテキストとしてインラインで提示されてよい。

一部の実施形態では、システムは、要求のセキュリティポリシー及び基準ポリシーが同等性を欠くと決定するために十分であるパラメータの集合を提供してもよい。図１〜図４に関連して説明されるもの等のポリシーアナライザサービスは、図１２に関連して等、本開示の他の箇所に説明する技術を利用する。

要求のセキュリティポリシー及び基準ポリシーが同等である場合、次いでシステムは多様な適切なアクションを実行してよい。一部の実施形態では、セキュリティポリシーは、基準ポリシーよりもより許容性があるとシステムが決定した場合と同じように処理されてよい。代わりに、セキュリティポリシーは、基準ポリシーよりもより許容性がないとシステムが決定した場合と同じように処理されてよい。セキュリティポリシーが同等であるときにシステムがどのようにして事例を処理するのかは、構成可能な設定であってよい。

一部の実施形態では、セキュリティポリシーが比較される多数のベースラインポリシーがある場合がある。係る場合、要求により適用されているセキュリティポリシーは各基準ポリシーに対して個別に比較されてよい。これらの比較は、互いに同時にだけではなく、連続して行われてもよい。

図１５は、本開示の実施形態に従って実装されてよいグラフィックユーザーインタフェース（ＧＵＩ）を示す。一部の例では、ＧＵＩは実装され、クライアントコンピューティングデバイスを介してクライアント（例えば、図１〜図４に関連して等、他の箇所に説明するもの）等のユーザーに提示されてよい。ＧＵＩは、ウェブページ、アプリケーション等の一部として提示されてよい。

第１のグラフィックユーザーインタフェース１５０２は、図１５に示される。第１のグラフィックユーザーインタフェース１５０２は、第１の入力領域１５０４、第２の入力領域１５０６、ボタン１５０８、及び結果の視覚的な表示１５１０を含んでよい。第１の入力領域１５０４は、クライアントがポリシーを入力できるＧＵＩの領域であってよい。例えば、第１の入力領域１５０４は、クライアントが、本開示の他の箇所に説明するもの等、ポリシーを入力してよいテキストボックスであってよい。クライアントは、（例えば、タッチスクリーンキーボードまたは物理的なキーを使用し）テキストボックスにポリシーを入力することによって、クリップボードからポリシーをペーストすることによって等いくつかの方法でポリシーを入力してよい。ＧＵＩは、第１の入力領域１５０４の中に入力されるポリシーとは異なる場合がある第２のポリシーのための入力機構をサポートしてよい第２の入力領域１５０６をさらに含んでよい。また、ＧＵＩは、押されると、入力領域１５０４及び１５０６に含まれるポリシーの許容性を解析するために利用されてよいボタン１５０８を含んでもよい。例えば、クライアントコンピューティングデバイスに提示されるＧＵＩ上で「Ｓｕｂｍｉｔ」ボタン１５０８を押すことで、ウェブＡＰＩ要求はポリシーアナライザサービス（例えば、図１〜図４に関連して説明されるもの等）に提出されて、第１の入力領域１５０４に含まれる第１のポリシー及び第２の入力領域１５０６に含まれる第２のポリシーの許容性を比較してよい。要求を満たすために、コンピューティングリソースサービスプロバイダ、ポリシーアナライザサービス、または本開示の他の箇所に説明する他の適切なシステムが利用されてよい。ウェブＡＰＩ要求に対する応答は、ＧＵＩの他の領域だけではなく、視覚的な表示１５１０で提示されてもよい。例えば、図１５に示すＧＵＩ１５０２は、２つのポリシーが同等である旨の視覚的な表示１５１０を、２つの等号「＝＝」により提示してよく、ポリシーが同等であることをさらに説明するテキストをＧＵＩ内の他のどこかの箇所に含んでよい。一部の実施形態では、ＧＵＩは、２つのポリシーの同等性に関する追加の情報を提示してよい。一部の場合には、２つのポリシーが同等性を欠くとき、ＧＵＩは、同等性を欠く２つのポリシーの例を提供する場合があるパラメータの集合を提示してよい。例えば、認証対象、及びコンピューティングリソースアクションを含むパラメータの集合は、第２のセキュリティポリシーをパラメータの同じ集合に適用すると、異なる効果が生じる（例えば、アクセスが拒否される）のに対し、第１のセキュリティポリシーをパラメータの集合に適用すると、第１の効果が生じる（例えば、アクセスが許可される）ように記載されてよい。

第２のグラフィックユーザーインタフェース１５１２は、図１５に示される。第２のグラフィックユーザーインタフェース１５１２は、入力領域１５１４、ドロップダウンリスト１５１６、ドロップダウンリストを拡大するために使用され得るドロップダウン矢印１５１８、ボタン１５２０、及び結果の視覚表示１５２２を含んでよい。第２のグラフィックユーザーインタフェースは、第１のグラフィックユーザーインタフェース１５０２に関連して上述した技術を使用し、実装されてよい。一部の実施形態では、入力領域１５１４は、本開示の他の箇所に説明するものに従ってよい。ドロップダウンリスト１５１６は、例えば上述の基準ポリシー等、１つ以上の所定のポリシーを記述する項目のリストであってよい。ドロップダウンリストの項目は、例えば基準ポリシー等の多様な所定のポリシーの記述を含んでよく、それらの記述は、例えばＪＳＯＮフォーマットのポリシー等、それぞれの基本的なポリシーにマッピングされてよい。一部の実施形態では、ドロップダウンリスト１５１６は、ドロップダウン矢印１５１８を押すことによってリストの多数のポリシーを示すために拡大されてよい。他の箇所に説明するように、ボタン１５２０は、２つのポリシーを比較するウェブＡＰＩ要求を提出するために利用されてよい。例えば、クライアントが、第２のグラフィックユーザーインタフェース１５１２に示す「Ｓｕｂｍｉｔ」ボタン１５２０を押すと、システムは、入力領域１５１４に含まれるポリシー、及びドロップダウンリストの項目をその対応するポリシーにマッピングするマッピングから入手される第２のポリシーを比較するウェブＡＰＩ要求を提出してよい。第２の例として、クライアントがボタン１５２０を押すと、システムは、入力１５１４及び例えば基準ポリシー等の所定のポリシーに対応する識別子を含むウェブＡＰＩ要求を提出してよく、要求を受け取るサービスは、対応するポリシーに対する識別子のマッピングを実行してよい。要求を満たすために、コンピューティングリソースサービスプロバイダ、ポリシーアナライザサービス、または本開示の他の箇所に説明する他の適切なシステムが利用されてよい。ウェブＡＰＩ要求に対する応答は、ＧＵＩの他の領域だけではなく、視覚的な表示１５２２に提示されてもよい。例えば、図１５に示すＧＵＩ１５１２は、入力領域のポリシー及びドロップダウンリストのポリシーが同等である旨の視覚的な表示１５２２を、２つの等号「＝＝」により提示してよく、ポリシーが同等であることをさらに説明するテキストをＧＵＩ内の他のどこかの箇所に含んでよい。一部の実施形態では、ＧＵＩは、２つのポリシーの同等性に関する追加の情報を提示してよい。一部の場合には、入力領域のポリシー及びドロップダウンリストのポリシーが同等性を欠くとき、ＧＵＩは、同等性を欠く２つのポリシーの例を提供する場合があるパラメータの集合を提示してよい。例えば、認証対象、アクション、及びコンピューティングリソースアクションを含むパラメータの集合は、選択されたドロップダウンリスト項目に対応するセキュリティポリシーを同じパラメータの集合に適用すると、異なる効果が生じる（例えば、アクセスが拒否される）のに対し、入力領域１５１４のセキュリティポリシーをパラメータの集合に適用すると、第１の効果が生じる（例えば、アクセスが許可される）ように記載されてよい。

図１６は、多様な実施形態に従って態様を実施するための例の環境１６００の態様を示す。理解されるように、ウェブベースの環境が説明の目的のために使用されるが、多様な実施形態を実施するために異なる環境が必要に応じて使用され得る。環境は、電子クライアントデバイス１６０２を含み、これは、要求、メッセージ、または情報を、適切なネットワーク１６０４を介して送信及び受信するように、ならびに一部の実施形態では、デバイスのユーザーに情報を伝達し直すよう作動する任意の適切なデバイスを含む場合がある。係るクライアントデバイスの例は、パーソナルコンピュータ、携帯電話、ハンドヘルドメッセージングデバイス、ラップトップコンピュータ、タブレットコンピュータ、セットトップボックス、携帯情報端末、埋め込み式コンピュータシステム、電子ブックリーダ等を含む。ネットワークは、イントラネット、インターネット、セルラーネットワーク、ローカルエリアネットワーク、衛星ネットワーク、もしくは任意の他の係るネットワーク、及び／またはその組み合わせを含んだ任意の適切なネットワークを含む場合がある。係るシステムに使用される構成要素は、選択されるネットワーク及び／または環境のタイプに少なくとも部分的に依存する場合がある。係るネットワークを介して通信するための多くのプロトコル及び構成要素は周知であり、本明細書で詳細に説明しない。ネットワーク上の通信は、有線接続または無線接続及びその組み合わせによって可能にされる場合がある。この例では、他のネットワークについて、当業者に明らかであるように、類似する目的に適う代替のデバイスが使用できるが、環境は要求を受け取り、それに応えてコンテンツを供給するためのウェブサーバ１６０６を含むので、ネットワークはインターネット及び／または他の公にアドレス指定可能な通信ネットワークを含む。

例示的な環境は、少なくとも１つのアプリケーションサーバ１６０８及びデータストア１６１０を含む。いくつかのアプリケーションサーバ、層もしくは他の要素、プロセス、または構成要素が存在する場合があり、それらは、繋がれ、または他に構成され得、適切なデータストアからデータを入手すること等のタスクを実行するために相互作用できることを理解されたい。本明細書で使用するように、サーバは、例えばハードウェアデバイスまたはバーチャルコンピュータシステム等、多様な方法で実装されてよい。一部の状況では、サーバは、コンピュータシステム上で実行されているプログラミングモジュールを指す場合がある。本明細書で使用するように、特に明記しない限りまたは文脈から明らかでない限り、用語「データストア」は、データを記憶し、データにアクセスし、かつデータを取り出すことができる任意のデバイスまたはデバイスの組み合わせを指し、任意の標準的な環境、分散型の仮想環境、またはクラスタ化された環境において、任意の組み合わせおよび任意の数のデータサーバ、データベース、データストレージデバイス、及びデータ記憶媒体を含み得る。アプリケーションサーバは、必要に応じてデータストアと統合して、クライアントデバイスのための１つ以上のアプリケーションの態様を実行し、データアクセス及びアプリケーションのためのビジネス論理の一部またはすべてを処理するための任意の適切なハードウェア、ソフトウェア、及びファームウェアを含む場合がある。アプリケーションサーバは、データストアと協働してアクセス制御サービスを提供してよく、ユーザーに提供されるために使用できるテキスト、グラフィックス、音声、ビデオ、及び／または他のコンテンツ等を含むが、これに限定されるものではないコンテンツを生成することができ、コンテンツは、ハイパーテキストマークアップ言語（「ＨＴＭＬ」）、拡張マークアップ言語（「ＸＭＬ」）、ＪａｖａＳｃｒｉｐｔ（登録商標）、Ｃａｓｃａｄｉｎｇ Ｓｔｙｌｅ Ｓｈｅｅｔｓ（「ＣＳＳ］）、ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）、及び／または別の適切なクライアント側の構造言語の形でウェブサーバによりユーザーに提供されてよい。クライアントデバイスに転送されたコンテンツは、聞こえるように、視覚的に、及び／または他の感覚を通してユーザーが知覚可能な形を含むが、これに限定されるものではない１つ以上の形でコンテンツを提供するために、クライアントデバイスにより処理されてよい。クライアントデバイス１６０２とアプリケーションサーバ１６０８との間でのコンテンツの配信だけではなく、すべての要求及び応答の処理も、この例では、ＰＨＰ、つまりハイパーテキストプリプロセッサ（「ＰＨＰ」）、Ｐｙｔｈｏｎ、Ｒｕｂｙ、Ｐｅｒｌ、Ｊａｖａ（登録商標）、ＨＴＭＬ、ＸＭＬ、ＪＳＯＮ、及び／または別の適切なサーバ側構造言語を使用し、ウェブサーバによって処理できる。さらに、単一のデバイスにより実行されているとして本明細書に説明する演算は、文脈から明らかでない限り、分散型システム及び／または仮想システムを形成する場合がある多数のデバイスにより集合的に実行されてよい。

データストア１６１０は、いくつかの別個のデータテーブル、データベース、データ文書、動的データストレージ方式、及び／または本開示の特定の態様に関係するデータを記憶するための他のデータストレージ機構及びデータ記憶媒体を含む場合がある。例えば、示されるデータストアは、生産データ１６１２及びユーザー情報１６１６を記憶するための機構を含んでよく、これは、生産側にコンテンツを提供するために使用できる。また、データストアは、報告、解析または他の係る目的のために使用できるログデータ１６１４を記憶するための機構を含むと示される。必要に応じて上記に記載された機構のいずれか、またはデータストア１６１０内の追加の機構に記憶できるページ画像情報及びアクセス権情報等、データストアに記憶する必要がある場合がある多くの他の態様がある場合があることを理解されたい。データストア１６１０は、それと関連付けられたロジックを通じて、アプリケーションサーバ１６０８から命令を受け取り、それに応答して、データを入手、更新、または他に処理するよう作動する。アプリケーションサーバ１６０８は、受け取った命令に応えて静的データ、動的データ、または静的データと動的データの組み合わせを提供してよい。例えばウェブログ（ブログ）、ショッピングアプリケーション、ニュースサービス、及び他の係るアプリケーションで使用されるデータ等の動的データは、本明細書に説明するサーバ側構造言語によって生成される場合もあれば、アプリケーションサーバ上で、またはアプリケーションサーバの制御下で動作するコンテンツ管理システム（「ＣＭＳ」）によって提供される場合もある。一例では、ユーザーは、ユーザーによって操作されるデバイスを通して、特定のタイプの項目に対する検索要求を提出する可能性がある。この場合、データストアは、ユーザーのアイデンティティを検証するためにユーザー情報にアクセスする可能性があり、そのタイプの項目についての情報を入手するためにカタログ詳細情報にアクセスする場合がある。情報は、次いで、ユーザーがユーザーデバイス１６０２上のブラウザを介して見ることができるウェブページ上の結果リスト等で、ユーザーに返すことができる。専用ページまたはブラウザのウインドウ内で、関心のある特定の項目についての情報を見ることができる。しかしながら、本開示の実施形態が、必ずしもウェブページの文脈に限定されるのではなく、要求が必ずしもコンテンツに対する要求ではない一般的な要求を処理することにもより一般的に適用可能であってよいことに留意されたい。

各サーバは、通常、そのサーバの一般的な管理及び操作のための実行可能なプログラム命令を提供するオペレーティングシステムを含み、通常、サーバのプロセッサによって実行されるときに（つまり、実行された結果として）、サーバがその意図される機能を実行できるようにする命令を記憶するコンピュータ可読記憶媒体（例えば、ハードディスク、ランダムアクセスメモリ、読み出し専用メモリ等）を含む。

一実施形態における環境は、１つ以上のコンピュータネットワークまたは直接接続を使用して、通信リンクを介して相互接続されるいくつかのコンピュータシステム及び構成要素を利用する分散型及び／または仮想コンピューティング環境である。しかしながら、係るシステムは、図１６に示すよりも少ない数または多い数の構成要素を有するシステムにおいて同等に良好に動作できることが当業者により理解される。したがって、図１６のシステム１６００の説明は、本質的に例示的であり、本開示の範囲を限定するものではないと捉えられるべきである。

本開示の実施形態は、以下の条項を考慮して説明することができる。
１．コンピュータ実施方法であって、
インタフェースを介して、
セキュリティ許可の第１の集合を符号化する第１のセキュリティポリシーと、
セキュリティ許可の第２の集合を符号化する第２のセキュリティポリシーと、
を指定する情報を受け取ることと、
セキュリティ許可の第１の集合に少なくとも部分的に基づいて、第１の命題論理式を決定することと、
セキュリティ許可の第２の集合に少なくとも部分的に基づいて、第２の命題論理式を決定することと、
第１のセキュリティポリシーをパラメータの集合に適用すると、パラメータの集合と関連付けられたコンピューティングリソースへのアクセスの拒否が生じ、第２のセキュリティポリシーをパラメータの集合に適用すると、コンピューティングリソースへのアクセスの許可が生じるように、第１の命題論理及び第２の命題論理が同等性を欠くと決定するために十分であるパラメータの集合を識別することと、
インタフェースを介して、
第１のセキュリティポリシー及び第２のセキュリティポリシーが同等性を欠く旨の表示と、
パラメータの集合と、
を提供することと、
を含む、コンピュータ実施方法。

２．第１の命題論理及び第２の命題論理が同等性を欠くと決定することが、第１の命題論理及び第２の命題論理に少なくとも部分的に基づいて生成された制約が充足可能であるかどうかを決定するために充足可能性モジュロ理論（ＳＭＴ）ソルバーを利用することを含む、条項１に記載のコンピュータ実施方法。

３．第１の命題論理及び第２の命題論理に少なくとも部分的に基づいて生成された制約が、ＳＭＴ−ＬＩＢ規格に従う、条項２に記載のコンピュータ実施方法。

４．第１のセキュリティポリシー及び第２のセキュリティポリシーが同等性を欠く旨の表示が、第１のセキュリティポリシーが第２のセキュリティポリシーよりもより許容性があるかどうかの表示を含む、条項１〜３のいずれかに記載のコンピュータ実施方法。

５．システムであって、
１つ以上のプロセッサと、
実行される場合、システムに、
少なくとも部分的にセキュリティ許可の第１の集合に基づいて、第１の命題論理を決定させ、
少なくとも部分的にセキュリティ許可の第２の集合に基づいて、第２の命題論理を決定させ、
第１の命題論理及び第２の命題論理を使用し、第１の命題論理及び第２の命題論理が同等性を欠くと決定させ、
セキュリティ許可の第１の集合及びセキュリティ許可の第２の集合が同等性を欠く旨の表示を提供させる、
コンピュータ実行可能命令を記憶するメモリと、
を備える、システム。

６．第１の命題論理及び第２の命題論理が同等性を欠くと決定するコンピュータ実行可能命令が、実行される場合、システムに、第１の命題論理及び第２の命題論理に少なくとも部分的に基づいて生成された制約が充足可能であるかどうかを決定するために充足可能性モジュロ理論（ＳＭＴ）ソルバーを利用させるコンピュータ実行可能命令をさらに含む、条項５に記載のシステム。

７．セキュリティ許可の第１の集合が第１のポリシーに含まれ、セキュリティ許可の第２の集合が第２のポリシーに含まれる、条項５または６に記載のシステム。

８．第１の命題論理及び第２の命題論理に少なくとも部分的に基づいて生成された制約が、ＣＶＣフォーマットまたはＤＩＭＡＣＳフォーマットに従う、条項６に記載のシステム。

９．第１の命題論理及び第２の命題論理が同等性を欠くと決定するコンピュータ実行可能命令が、実行される場合、システムに、
セキュリティ許可の第１の集合のアクセス許可に対応する制約の第１の集合を生成させ、
セキュリティ許可の第１の集合のアクセス拒否に対応する制約の第２の集合を生成させる
コンピュータ実行可能命令をさらに含む、条項５〜８のいずれかに記載のシステム。

１０．第１の命題論理及び第２の命題論理が同等性を欠くと決定するコンピュータ実行可能命令が、実行される場合、システムに、セキュリティ許可の第１の集合のアクセス中立制約に対応する制約の第３の集合を生成させるコンピュータ実行可能命令をさらに含む、条項９に記載のシステム。

１１．セキュリティ許可の第２の集合が、セキュリティ許可の所定の複数の集合からセキュリティ許可の第２の集合を選択するユーザーから入手される、条項５〜１０のいずれかに記載のシステム。

１２．第１の命題論理及び第２の命題論理が同等性を欠くと決定するコンピュータ実行可能命令が、実行される場合、システムに、第１の命題論理及び第２の命題論理が比較できないと決定させるコンピュータ実行可能命令をさらに含む、条項５〜１１のいずれかに記載のシステム。

１３．非一過性コンピュータ可読記憶媒体であって、コンピュータシステムの１つ以上のプロセッサによって実行された結果として、コンピュータシステムに、少なくとも
セキュリティ許可の第１の集合から決定された第１の命題論理、及びセキュリティ許可の第２の集合から決定された第２の命題論理が同等性を欠くと決定するために十分である、セキュリティ許可の第１の集合またはセキュリティ許可の第２の集合のどちらかと関連付けられたセキュリティ許可が存在するかどうかを識別させ、
セキュリティ許可の第１の集合及びセキュリティ許可の第２の集合が同等性を欠く旨の表示を提供させる、
実行可能命令を記憶している、非一過性コンピュータ可読記憶媒体。

１４．実行された結果として、コンピュータシステムに、セキュリティ許可が存在するかどうかを識別させる実行可能命令が、充足可能性モジュロ理論（ＳＭＴ）ソルバーを使用する実行可能命令をさらに含む、条項１３に記載の非一過性コンピュータ可読媒体。

１５．実行された結果として、コンピュータシステムに、第１の命題論理及び第２の命題論理が同等性を欠くかどうかを決定するために十分であるセキュリティ許可が存在するかどうかを識別させる実行可能命令が、充足可能性（ＳＡＴ）ソルバーを使用する実行可能命令をさらに含む、条項１３または１４に記載の非一過性コンピュータ可読記憶媒体。

１６．ＳＡＴソルバーが（バイナリディシジョンダイアグラム）ＢＤＤ ＳＡＴソルバーである、条項１５に記載の非一過性コンピュータ可読記憶媒体。

１７．セキュリティ許可の第１の集合が、少なくとも
認証対象と、
アクションと、
コンピューティングリソースと、
許可効果または拒否効果のどちらかと
を識別する、条項１３〜１６のいずれかに記載の非一過性コンピュータ可読記憶媒体。

１８．セキュリティ許可の第１の集合が、少なくとも１つの条件述部を識別する、条項１７に記載の非一過性コンピュータ可読記憶媒体。

１９．セキュリティ許可の第１の集合、及びセキュリティ許可の第２の集合の少なくとも１つが、複数の適用されたセキュリティポリシーを含むポリシーレポジトリから入手され、適用されたセキュリティポリシーがセキュリティ許可の集合を含む、条項１３〜１８のいずれかに記載の非一過性コンピュータ可読記憶媒体。

２０．コンピュータシステムの１つ以上のプロセッサによって実行された結果として、コンピュータシステムにさらに、少なくとも
第１の命題論理及び第２の命題論理が同等性を欠くと決定するために十分であるセキュリティ許可を識別させ、
第１の命題論理及び第２の命題論理の同等性を決定する要求に対する応答の一部として識別したセキュリティ許可を提供させる、
条項１３〜１９のいずれかに記載の非一過性コンピュータ可読記憶媒体。

２１．コンピュータ実施方法であって、
アプリケーションプログラミングインタフェース呼び出しのログからレコードにアクセスすることであって、レコードがアプリケーションプログラミングインタフェース呼び出しのアプリケーションプログラミングインタフェースに対応する、アクセスすることと、
レコードに少なくとも部分的に基づいて、アプリケーションプログラミングインタフェース呼び出しが、１つ以上のコンピューティングリソースへのアクセスを許可するまたは拒否するために使用できる第１のポリシーを適用すると決定することと、
ポリシー検証ルーチンを呼び出すことであって、ポリシー検証ルーチンが、
第１のポリシーに少なくとも部分的に基づいて複数のセキュリティポリシーから基準ポリシーを選択することと、
第１のポリシーと関連付けられたセキュリティ許可の第１の集合に少なくとも部分的に基づいて、第１の命題論理式を決定することと、
基準ポリシーと関連付けられたセキュリティ許可の第２の集合に少なくとも部分的に基づいて、第２の命題論理式を決定することと、
第１の命題論理式が第２の命題論理式よりもより許容性があるかどうかを決定することと、
第１の命題論理式が第２の命題論理式よりもより許容性があると決定したことに応えて、第１のポリシーを修正するまたは無効にする軽減ルーチンを実行することと、
を含む、コンピュータ実施方法。

２２．充足可能性モジュロ理論（ＳＭＴ）ソルバーが、第１の命題論理式が第２の命題論理式よりもより許容性があるかどうかを決定することの一部として利用される、条項２１に記載のコンピュータ実施方法。

２３．軽減ルーチンが、第１のポリシーがアクセスを可能にする少なくとも１つのコンピューティングリソースへのアクセスを拒否することを含む、条項２１または２２に記載のコンピュータ実施方法。

２４．第１の命題論理式が第２の命題論理式よりもより許容性があると決定することが、パラメータの集合を識別することを含み、
パラメータの集合が、認証対象、アクション、及びコンピューティングリソースを識別し、
第１のポリシーのパラメータの集合への適用により、コンピューティングリソースが許可され、
基準ポリシーのパラメータの集合への適用により、コンピューティングリソースへのアクセスが拒否される、
条項２１〜２３のいずれかに記載のコンピュータ実施方法。

２５．システムであって、
１つ以上のプロセッサと、
コンピュータ実行可能命令を記憶するメモリであって、コンピュータ実行可能命令が、実行される場合、システムに、
複数の受け取られたアプリケーションプログラミングインタフェース呼び出しに少なくとも部分的に基づいて、複数のうちの１つのアプリケーションプログラミングインタフェース呼び出しが、１つ以上のコンピューティングリソースへのアクセスを許可するまたは拒否するために使用できる第１のポリシーを適用すると決定させ、
ポリシー検証ルーチンを呼び出させ、システムにポリシー検証ルーチンを呼び出させる命令が、実行される場合、システムに、
複数の所定のセキュリティポリシーから基準ポリシーを選択させ、
命令論理を含む第１の式への第１のポリシーの第１のマッピング、及び命令論理を含む第２の式への基準ポリシーの第２のマッピングに少なくとも部分的に基づいて制約の集合を決定させ、
制約の集合が充足可能であるかどうかに少なくとも部分的に基づいて、第１のポリシーが基準ポリシーよりもより許容性があるかどうかを決定させ、
第１のポリシーが基準ポリシーよりもより許容性があるかどうかを決定したことに少なくとも部分的に基づいて情報を送信させる、
コンピュータ実行可能命令を記憶するメモリと、
を備える、システム。

２６．第１の式が一階論理をさらに備える、条項２５に記載のシステム。

２７．システムに、第１のポリシーが基準ポリシーよりもより許容性があるかどうかを決定させる命令が、実行される場合、システムに、制約の集合が充足可能であるかどうかを評価するために充足可能性モジュロ理論（ＳＭＴ）ソルバーを使用させる、条項２５または２６に記載のシステム。

２８．Ｚ３ソルバーがＳＭＴソルバーである、条項２７に記載のシステム。

２９．コンピュータ実行可能命令が、実行される場合、システムに、さらに、
第１のポリシーがアクセスを可能にするすべてのコンピューティングリソースへのアクセスを拒否させ、
第１のポリシーを適用したアプリケーションプログラミングインタフェース呼び出しに関連付けられたエンティティに、第１のポリシーが第２のポリシーよりもより許容性がある旨の表示を提供させる、
条項２５〜２８のいずれかに記載のシステム。

３０．ポリシー検証ルーチンが、パラメータの集合の表示を提供することをさらに含み、
パラメータの集合が、
認証対象と、
アクションと、
コンピューティングリソースと、
許可効果または拒否効果と、
を備え、
第１のポリシーのパラメータの集合への適用により、コンピューティングリソースへのアクセスが許可され、
基準ポリシーのパラメータの集合への適用により、コンピューティングリソースへのアクセスが拒否される、
条項２５〜２９のいずれかに記載のシステム。

３１．パラメータの集合が、対応するポリシーが有効であるかどうかを定義する少なくとも１つの条件述部をさらに備える、条項３０に記載のシステム。

３２．基準ポリシーが、アプリケーションプログラミングインタフェース呼び出しで符号化されたコンピューティングリソースと関連付けられたサービス名前空間に少なくとも部分的に基づいて選択される、条項２５〜３１のいずれかに記載のシステム。

３３．非一過性コンピュータ可読記憶媒体であって、コンピュータシステムの１つ以上のプロセッサによって実行された結果として、コンピュータシステムに、少なくとも、
複数の要求を監視させ、複数のうちの少なくともいくつかの要求が、コンピューティングリソースサービスプロバイダのコンピューティングリソースへのアクセスを許可するまたは拒否するセキュリティポリシーを適用し、
第１のポリシーを適用する複数のうちの要求を識別させ、
ポリシー検証ルーチンを呼び出させ、ポリシー検証ルーチンが、コンピュータシステムに、少なくとも、
命令論理を含む第１の式への第１のポリシーの第１のマッピング、及び命令論理を含む第２の式への基準ポリシーの第２のマッピングに少なくとも部分的に基づいて制約の集合を決定させ、
制約の集合が充足可能であるかどうかを評価することによって、第１のポリシーが基準ポリシーよりもより許容性があるかどうかを決定させ、
第１のポリシーが基準ポリシーよりもより許容性があると決定したことに応えて、軽減ルーチンを実行させる、
実行可能命令を記憶している、非一過性コンピュータ可読記憶媒体。

３４．第２の式が一階論理を備える、条項３３に記載の非一過性コンピュータ可読記憶媒体。

３５．第１のポリシーが基準ポリシーよりもより許容性があると決定する実行可能命令が、実行された結果として、コンピュータシステムに、制約の集合が充足可能であるかどうかを評価するために充足可能性モジュロ理論（ＳＭＴ）ソルバーを使用させる、条項３３または３４に記載の非一過性コンピュータ可読記憶媒体。

３６．制約が、ＳＭＴ−ＬＩＢ規格に従ったフォーマットで符号化される、条項３５に記載の非一過性コンピュータ可読記憶媒体。

３７．第１のポリシーが、ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）フォーマットで符号化される、条項３３〜３６のいずれかに記載の非一過性コンピュータ可読記憶媒体。

３８．第２のポリシーが、所定の複数のセキュリティポリシーから入手される、条項３３〜３７のいずれかに記載の非一過性コンピュータ可読記憶媒体。

３９．実行可能命令が、コンピュータシステムの１つ以上のプロセッサにより実行された結果として、さらに、コンピュータシステムに、第１のポリシー及び基準ポリシーが同等であると決定したことに応えて軽減ルーチンを実行させる、条項３３〜３８のいずれかに記載の非一過性コンピュータ可読記憶媒体。

４０．実行可能命令が、コンピュータシステムの１つ以上のプロセッサによって実行された結果として、さらに、コンピュータシステムに、第１のポリシー及び基準ポリシーが比較できないと決定したことに応えて軽減ルーチンを実行させる、条項３３〜３９のいずれかに記載の非一過性コンピュータ可読記憶媒体。

多様な実施形態は多種多様な動作環境でさらに実装可能であり、動作環境は、一部の場合には、いくつかのアプリケーションのいずれかを操作するために使用できる１つ以上のユーザーコンピュータ、コンピューティングデバイスまたは処理デバイスを含む場合もある。ユーザーデバイスまたはクライアントデバイスは、標準オペレーティングシステムを実行するデスクトップコンピュータ、ラップトップコンピュータ、またはタブレットコンピュータ等のいくつかのコンピュータのいずれか、ならびにモバイルソフトウェアを実行し、いくつかのネットワーキングプロトコル及びメッセージプロトコルをサポートできるセルラーデバイス、無線デバイス、及びハンドヘルドデバイスを含む場合がある。また、係るシステムは、市販されている様々なオペレーティングシステム、ならびに開発及びデータベース管理のための他の既知のアプリケーションのいずれかを実行するいくつかのワークステーションを含む場合もある。また、これらのデバイスは、ダミー端末、シンクライアント、ゲーム機、及びネットワークを介して通信可能な他のデバイス等の他の電子機器を含む場合もある。また、これらのデバイスは、バーチャルマシン、ハイパーバイザ、及びネットワークを介して通信可能な他の仮想装置等の仮想装置を含む場合もある。

本開示の多様な実施形態は、例えば伝送制御プロトコル／インターネットプロトコル（「ＴＣＰ／ＩＰ」）、ユーザーデータグラムプロトコル（「ＵＤＰ」）、オープンシステムインターコネクション（「ＯＳＩ」）モデルの多様な層で動作するプロトコル、ファイルトランスポートプロトコル（「ＦＴＰ」）、ユニバーサルプラグアンドプレイ（「ＵｐｎＰ」）、ネットワークファイルシステム（「ＮＦＳ」）、共通インターネットファイルシステム（「ＣＩＦＳ」）及びＡｐｐｌｅＴａｌｋ等の様々な市販のプロトコルのいずれかを使用し、通信をサポートするための当業者によく知られている少なくとも１つのネットワークを利用する。ネットワークは、例えば、ローカルエリアネットワーク、広域ネットワーク、仮想プライベートネットワーク、インターネット、イントラネット、エクストラネット、公衆交換電話網、赤外線ネットワーク、無線ネットワーク、衛星ネットワーク、及びその任意の組合せである場合がある。一部の実施形態では、コネクション型プロトコルが、ネットワークエンドポイント間で通信するために使用されてよい。（接続ベースのプロトコルとも呼ぶ）コネクション型プロトコルは、順序付けられたストリームでデータを伝送できる。コネクション型プロトコルは信頼性がある場合もあれば、信頼性がない場合もある。例えば、ＴＣＰプロトコルは信頼性のあるコネクション型プロトコルである。非同期転送モード（「ＡＴＭ」）及びフレームリレーは、信頼性のないコネクション型プロトコルである。コネクション型プロトコルは、例えば、順序付けを保証せずにパケットを伝送するＵＤＰ等のパケット型プロトコルとは対照的である。

ウェブサーバを利用する実施形態では、ウェブサーバは、ハイパーテキストトランスポートプロトコル（「ＨＴＴＰ」）サーバ、ＦＴＰサーバ、共通ゲートウェイインタフェース（「ＣＧＩ」）サーバ、データサーバ、Ｊａｖａサーバ、Ａｐａｃｈｅサーバ、及びビジネスアプリケーションサーバを含む様々なサーバまたは中間層アプリケーションのいずれかを実行できる。また、サーバ（複数可）は、例えばＪａｖａ（登録商標）、Ｃ、Ｃ＃、もしくはＣ＋＋等の任意のプログラミング言語、またはＲｕｂｙ、ＰＨＰ、Ｐｅｒｌ、Ｐｙｔｈｏｎ、もしくはＴＣＬ等の任意のスクリプト言語、ならびにその組み合わせで作成された１つ以上のスクリプトまたはプログラムとして実装され得る１つ以上のウェブアプリケーションを実行することによって、ユーザーデバイスからの要求に応えてプログラムまたはスクリプトを実行できる場合もある。また、サーバ（複数可）は、またはＯｒａｃｌｅ（登録商標）、Ｍｉｃｒｏｓｏｆｔ（登録商標）、Ｓｙｂａｓｅ（登録商標）、及びＩＢＭ（登録商標）から市販されているサーバ、ならびにＭｙＳＱＬ、Ｐｏｓｔｇｒｅｓ、ＳＱＬｉｔｅ、ＭｏｎｇｏＤＢ、及び構造化または非構造化データを記憶し、取り出し、及びアクセスすることが可能な任意の他のサーバ等のオープンソースサーバを含むがこれに限定されるものではない、データベースサーバを含んでもよい。データベースサーバは、テーブルベースサーバ、ドキュメントベースサーバ、非構造化サーバ、関係サーバ、非関係サーバ、もしくはこれらの組み合わせ、及び／または他のデータベースサーバを含んでもよい。

環境は、様々なデータストアならびに上述の他のメモリ及び記憶媒体を含む場合がある。これらは、コンピュータの１つ以上に対してローカルな（及び／またはコンピュータの中に常駐する）、またはネットワーク全体でコンピュータのいずれかもしくはすべてからリモートな記憶媒体等、様々な場所に常駐する場合がある。実施形態の特定の集合では、情報は、当業者によく知られたストレージエリアネットワーク（「ＳＡＮ」）に常駐する場合がある。同様に、コンピュータ、サーバ、または他のネットワークデバイスに属する機能を実行するための任意の必要なファイルは、適宜、ローカルに及び／またはリモートで格納されてよい。システムがコンピュータ化されたデバイスを含む場合、それぞれの係るデバイスはバスを介して電気的に結合されてよいハードウェア要素を含む場合があり、要素は、例えば、少なくとも１つの中央演算処理装置（「ＣＰＵ」または「プロセッサ」）、少なくとも１つの入力装置（例えば、マウス、キーボード、コントローラ、タッチスクリーンまたはキーパッド）及び少なくとも１つの出力装置（例えば、表示装置、プリンタまたはスピーカ）を含む。また、係るシステムは、ディスクドライブ、光学式ストレージデバイス等の１つ以上のストレージデバイス、ランダムアクセスメモリ（「ＲＡＭ」）または読み出し専用メモリ（「ＲＯＭ」）等のソリッドステートストレージデバイス、ならびに取り外し可能媒体デバイス、メモリカード、フラッシュカード等を含んでもよい。

また、係るデバイスは、上述のようにコンピュータ可読記憶媒体読取装置、通信装置（例えば、モデム、ネットワークカード（無線または有線）、赤外線通信装置等）、及び作業メモリを含み得る。コンピュータ可読記憶媒体読み取り装置は、リモートストレージデバイス、ローカルストレージデバイス、固定ストレージデバイス、及び／または取り外し可能ストレージデバイスを表すコンピュータ可読記憶媒体、ならびにコンピュータ可読情報を一時的に及び／またはより恒久的に含有する、記憶する、送信する及び取り出すための記憶媒体と接続できる、またはそれらを受け取るように構成される場合がある。また、システム及び多様なデバイスは、通常、オペレーティングシステム、及びクライアントアプリケーションまたはウェブブラウザ等のアプリケーションプログラムを含む、少なくとも１つのワーキングメモリデバイス内に位置するいくつかのソフトウェアアプリケーション、モジュール、サービス、または他の要素を含む。さらに、カスタマイズされたハードウェアが使用される可能性がある、及び／または特定の要素がハードウェア、ソフトウェア（アプレット等のポータブルソフトウェアを含む）、もしくは両方で実装される可能性がある。さらに、ネットワーク入出力装置等の他のコンピューティングデバイスへの接続が利用される場合がある。

コードまたはコードの部分を包含するための記憶媒体及びコンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、電気的消去可能プログラマブル読み出し専用メモリ（「ＥＥＰＲＯＭ」）、フラッシュメモリもしくは他のメモリ技術、コンパクトディスク読み出し専用メモリ（「ＣＤ−ＲＯＭ］）、デジタルバーサタイルディスク（ＤＶＤ）もしくは他の光学ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、または所望の情報を記憶するために使用することができ、かつシステムデバイスによってアクセスできる任意の他の媒体を含む、コンピュータ可読命令、データ構造、プログラムモジュールまたは他のデータ等の情報の記憶及び／または伝送のために任意の方法または技術で実装される揮発性及び不揮発性の媒体、取り外し可能及び取り外し不可能な媒体等であるが、これに限定されるものではない記憶媒体及び通信媒体を含む当該分野において既知の、または使用される任意の適切な媒体を含む場合がある。本明細書に提供される開示及び教示に基づいて、当業者は、多様な実施形態を実施するための他の方式及び／または方法を理解する。

したがって、明細書及び図面は、限定的な意味ではなく例示的であると見なされることになる。しかしながら、「特許請求の範囲」に説明する本発明のより広範な趣旨及び範囲から逸脱することなく、それに対して多様な修正及び変更をなし得ることは明らかである。

他の変形形態は、本開示の趣旨の範囲内である。ゆえに、開示された技術は多様な修正形態及び代替構成の影響を受けるが、その特定の例示される実施形態は図面に示され、上記に詳細に説明されている。しかしながら、本発明を特定の開示される形式（複数可）に限定する意図があるのではなく、逆に、意図は、添付の特許請求の範囲において定義される本発明の趣旨及び範囲に該当するすべての修正、代替構造、及び等価物を網羅することであることを理解されたい。

開示される実施形態を説明する文脈における（特に以下の特許請求の範囲の文脈における）用語「ａ」及び「ａｎ」及び「ｔｈｅ」ならびに同様の指示語の使用は、本明細書において別段の指示がない限り、または文脈に明らかに矛盾するものでない限り、単数及び複数の両方を網羅すると解釈されるべきである。用語「備える」、「有する」「含む」及び「包含する」は、特に断りのない限り、オープンエンド用語（すなわち「を含むが、これらに限定されるものではない」を意味する）として解釈されるべきである。用語「接続された」は、修飾されず、物理的な接続を指すときには、たとえ介在するものがあっても部分的にまたは完全に、中に含まれる、取り付けられるまたは互いに結合されるとして解釈されるべきである。本明細書での値の範囲の列挙は、本明細書に別段の指示がない限り、単に、範囲内に入るそれぞれの個別の値に個別に言及する短縮方法として機能することが意図され、各個別の値は、それが個別に本明細書に記載されているかのように本明細書に組み込まれる。用語「集合」の使用（例えば、「項目の集合」）または「部分集合」は、特に断りがないまたは文脈と矛盾しない限り、１つ以上の要素を含んだ非空の集合体として解釈されるべきである。さらに、特に断りがないまたは文脈と矛盾しない限り、用語対応する集合の「部分集合」は、対応する集合の適切な部分集合を必ずしも示すのではなく、部分集合及び対応する集合が等しい場合がある。

特に断りのない限りまたは明確に文脈と矛盾しない限り、例えば表現形式「Ａ、Ｂ、及びＣの少なくとも１つ」または「Ａ、Ｂ及びＣの少なくとも１つ」の言い回し等の連言的な語法はそうでなければ、項目、用語等がＡもしくはＢもしくはＣ、またはＡ及びＢ及びＣの集合の任意の非空部分集合のどちらかであってよいことを示すために概して使用されるとして文脈で理解される。例えば、３つの要素を有する集合の例示的な例では、連言的な言い回し「Ａ、Ｂ、及びＣの少なくとも１つ」または「Ａ、Ｂ及びＣの少なくとも１つ」は、以下の集合のいずれかを指す。｛Ａ｝、｛Ｂ｝、｛Ｃ｝、｛Ａ，Ｂ｝、｛Ａ，Ｃ｝、｛Ｂ，Ｃ｝、｛Ａ，Ｂ，Ｃ｝。したがって、係る連言的な語法は、概してある実施形態が、Ａの少なくとも１つ、Ｂの少なくとも１つ、及びＣの少なくとも１つがそれぞれ存在することを必要とすることを含意することを意図していない。さらに、特に断りがないまたは文脈と矛盾しない限り、用語「複数」は、複数である状態を示す（例えば、「複数の項目」は多数の項目を示す）。複数の中の項目の数は少なくとも２つであるが、明示的にまたは文脈からのどちらかでそのように示されるとき、より多い場合がある。

本明細書中記載されるプロセスの操作は、本明細書中特に記載がない限り、または文脈と明らかに矛盾しない限り、任意の適切な順序で実行できる。本明細書に説明するプロセス（またはその変形形態及び／またはその組み合わせ）は、実行可能命令で構成された１つ以上のコンピュータシステムの制御下で実行されてよく、ハードウェアまたはその組み合わせにより１つ以上のプロセッサで集合的に実行するコード（例えば、実行可能命令、１つ以上のコンピュータプログラム、または１つ以上のアプリケーション）として実装されてよい。コードは、例えば、１つ以上のプロセッサによって実行可能な複数の命令を含むコンピュータプログラムの形でコンピュータ読み取り可能な記憶媒体に記憶されてよい。コンピュータ可読記憶媒体は非一過性であり得る。一部の実施形態では、コードは、コンピュータシステムの１つ以上のプロセッサによって実行されるとき（つまり、実行された結果として）、コンピュータシステムに本明細書に説明する操作を実行させる実行可能命令を記憶している１つ以上の非一過性コンピュータ可読記憶媒体の集合に記憶される。非一過性コンピュータ可読記憶媒体の集合は、多数の非一過性コンピュータ可読記憶媒体を含んでよく、多数の非一過性コンピュータ可読記憶媒体の個々の非一過性記憶媒体の１つ以上がコードのすべてを欠く場合がある。一方、多数の非一過性コンピュータ可読記憶媒体は、コードのすべてを集合的に記憶する。さらに、一部の例では、実行可能命令は、異なる命令が異なるプロセッサにより実行されるように実行される。例示的な例として、非一過性コンピュータ可読記憶媒体は命令を記憶してよい。メインＣＰＵが命令のいくつかを実行する場合があり、グラフィックスプロセッサユニットが命令の他の命令を実行する場合がある。概して、コンピュータシステムの異なる構成要素は別々のプロセッサを有してよく、異なるプロセッサは命令の異なる部分集合を実行してよい。

したがって、一部の例では、コンピュータシステムは、本明細書に説明するプロセスの操作を単独でまたは集合的に実行する１つ以上のサービスを実装するように構成される。係るコンピュータシステムは、例えば、操作の実行を可能にする適用可能なハードウェア及び／またはソフトウェアで構成されてよい。さらに、本開示の多様な実施形態を実施するコンピュータシステムは、一部の例では、単独のデバイスである場合があり、他の例では、分散型コンピュータシステムが本明細書に説明する操作を実行するように、及び単独のデバイスがすべての操作を実行し得ないように異なるふうに動作する多数のデバイスを含んだ分散型コンピュータシステムである場合もある。

本明細書内に提供される任意及びすべての実施例、または例示的言語（例えば、「など」）の使用は、単に本発明の実施形態をより良く明らかにすることが意図され、別段の請求がない限り、本発明の範囲に対して制限を課すものではない。明細書の用語は、本発明の実施に不可欠な任意の非請求の要素を示すものと解釈されるべきではない。

本開示を実施するために本発明者らに知られているベストモードを含む本発明の実施形態を本明細書に記載する。それらの実施形態の変形形態は、前述の説明を読むと当業者に明らかになり得る。本発明者らは、当業者がこのような変形形態を必要に応じて利用することを期待し、本発明者らは本開示の実施態様が本明細書に具体的に説明するものとは別の方法で実践されることを意図する。したがって、本開示の範囲は、適用法によって許容されるように、本明細書に添付された特許請求の範囲に記載された主題の全ての修正形態及び均等物を含む。さらに、本明細書に別段の指示がない限り、または文脈に明らかに矛盾しない限り、上述の要素のすべての考え得る変形形態での上述の要素の任意の組み合わせが本開示の範囲に包含される。

本明細書で引用される出願公開、特許出願、特許を含む全ての参考文献は、各々の参考文献が参照によって個々にかつ具体的に組み込まれるものと示される、その全体が本明細書で示されているのと同じ程度に参照によって本明細書に組み込まれる。

Claims (16)

1. システムであって、
   １つ以上のプロセッサと、
   実行される場合、前記システムに、
   セキュリティ許可の第１の集合に少なくとも部分的に基づいて、第１の命題論理を決定させ、
   セキュリティ許可の第２の集合に少なくとも部分的に基づいて、第２の命題論理を決定させ、
   前記第１の命題論理及び前記第２の命題論理を使用し、前記第１の命題論理及び前記第２の命題論理が同等性を欠くと決定させ、
   セキュリティ許可の前記第１の集合及びセキュリティ許可の前記第２の集合が同等性を欠く旨の表示を提供させる、
   コンピュータ実行可能命令を記憶するメモリと、
   を備え、前記第１の命題論理及び前記第２の命題論理が同等性を欠くと決定する前記コンピュータ実行可能命令が、実行される場合、前記システムに、前記第１の命題論理及び前記第２の命題論理が比較できないと決定させるコンピュータ実行可能命令をさらに含む、システム。
2. 前記第１の命題論理及び前記第２の命題論理が同等性を欠くと決定する前記コンピュータ実行可能命令が、実行される場合、前記システムに、前記第１の命題論理及び前記第２の命題論理に少なくとも部分的に基づいて生成された制約が充足可能であるかどうかを決定するために充足可能性モジュロ理論（ＳＭＴ）ソルバーを利用させるコンピュータ実行可能命令をさらに含む、請求項１に記載のシステム。
3. セキュリティ許可の前記第１の集合が第１のポリシーに含まれ、セキュリティ許可の前記第２の集合が第２のポリシーに含まれる、請求項１または２に記載のシステム。
4. 前記第１の命題論理及び前記第２の命題論理に少なくとも部分的に基づいて生成された前記制約が、ＣＶＣフォーマットまたはＤＩＭＡＣＳフォーマットに従う、請求項２に記載のシステム。
5. 前記第１の命題論理及び前記第２の命題論理が同等性を欠くと決定する前記コンピュータ実行可能命令が、実行される場合、前記システムに、
   セキュリティ許可の前記第１の集合のアクセス許可に対応する制約の前記第２の集合を生成させ、
   セキュリティ許可の前記第１の集合のアクセス拒否に対応する制約の第２の集合を生成させる
   コンピュータ実行可能命令をさらに含む、請求項１から４のいずれか一項に記載のシステム。
6. 前記第１の命題論理及び前記第２の命題論理が同等性を欠くと決定する前記コンピュータ実行可能命令が、実行される場合、前記システムに、セキュリティ許可の前記第１の集合のアクセス中立制約に対応する制約の第３の集合を生成させるコンピュータ実行可能命令をさらに含む、請求項５に記載のシステム。
7. セキュリティ許可の前記第２の集合が、セキュリティ許可の所定の複数の集合からセキュリティ許可の前記第２の集合を選択するユーザーから入手される、請求項１から６のいずれか一項に記載のシステム。
8. システムであって、
   １つ以上のプロセッサと、
   実行される場合、前記システムに、
   セキュリティ許可の第１の集合に少なくとも部分的に基づいて、第１の命題論理を決定させ、
   セキュリティ許可の第２の集合に少なくとも部分的に基づいて、第２の命題論理を決定させ、
   前記第１の命題論理及び前記第２の命題論理を使用し、前記第１の命題論理及び前記第２の命題論理が同等性を欠くと決定させ、
   セキュリティ許可の前記第１の集合及びセキュリティ許可の前記第２の集合が同等性を欠く旨の表示を提供させる、
   コンピュータ実行可能命令を記憶するメモリと、
   を備え、前記第１の命題論理及び前記第２の命題論理が同等性を欠くと決定する前記コンピュータ実行可能命令が、実行される場合、前記システムに、
   セキュリティ許可の前記第１の集合のアクセス許可に対応する制約の前記第２の集合を生成させ、
   セキュリティ許可の前記第１の集合のアクセス拒否に対応する制約の第２の集合を生成させる
   コンピュータ実行可能命令をさらに含む、システム。
9. コンピュータシステムの１つ以上のプロセッサによって実行された結果として、前記コンピュータシステムに、少なくとも
   セキュリティ許可の第１の集合から決定された第１の命題論理、及びセキュリティ許可の第２の集合から決定された第２の命題論理が同等性を欠くと決定するために十分である、セキュリティ許可の前記第１の集合またはセキュリティ許可の前記第２の集合のどちらかと関連付けられたセキュリティ許可が存在するかどうかを識別させ、
   前記第１の命題論理及び前記第２の命題論理が同等性を欠くと決定した場合にさらに前記第１の命題論理及び前記第２の命題論理が比較できないと決定させ、
   セキュリティ許可の前記第１の集合及びセキュリティ許可の前記第２の集合が同等性を欠く旨の表示を提供させる、
   コンピュータプログラム。
10. 実行された結果として、前記コンピュータシステムに、前記セキュリティ許可が存在するかどうかを識別させる実行可能命令が、充足可能性モジュロ理論（ＳＭＴ）ソルバーを使用する実行可能命令を含む、請求項９に記載のコンピュータプログラム。
11. 実行された結果として、前記コンピュータシステムに、前記第１の命題論理及び前記第２の命題論理が同等性を欠くかどうかを決定するために十分である前記セキュリティ許可が存在するかどうかを識別させる実行可能命令が、充足可能性（ＳＡＴ）ソルバーを使用する実行可能命令を含む、請求項９または１０に記載のコンピュータプログラム。
12. セキュリティ許可の前記第１の集合が、少なくとも
    認証対象と、
    アクションと、
    コンピューティングリソースと、
    許可効果または拒否効果のどちらかと
    を識別する、請求項９から１１のいずれか一項に記載のコンピュータプログラム。
13. セキュリティ許可の前記第１の集合が、少なくとも１つの条件述部を識別する、請求項９から１２のいずれか一項に記載のコンピュータプログラム。
14. セキュリティ許可の前記第１の集合、及びセキュリティ許可の前記第２の集合の少なくとも１つが、複数の適用されたセキュリティポリシーを含むポリシーレポジトリから入手され、前記複数の適用されたセキュリティポリシーがセキュリティ許可の集合を含む、請求項９から１３のいずれか一項に記載のコンピュータプログラム。
15. コンピュータシステムの１つ以上のプロセッサによって実行された結果として、前記コンピュータシステムにさらに、少なくとも
    前記第１の命題論理及び前記第２の命題論理が同等性を欠くと決定するために十分である前記セキュリティ許可を識別させ、
    前記第１の命題論理及び前記第２の命題論理の同等性を決定する要求に対する応答の一部として前記識別したセキュリティ許可を提供させる、
    請求項９から１４のいずれか一項に記載のコンピュータプログラム。
16. 請求項９から１５のいずれか一項に記載のコンピュータプログラムが記憶されている、コンピュータ可読記憶媒体。

Images