翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 例 1: OPA と Rego を使用した基本的な ABAC
<a name="opa-abac-examples"></a>

このセクションでは、架空のペイロールマイクロサービス内の情報へのアクセスをどのユーザーに許可するかについて、OPA を使用してアクセスを決定するシナリオについて説明します。Rego コードスニペットは、Rego を使用してアクセスコントロールの決定をレンダリングする方法を示すために提供されています。これらの例は、Rego および OPA 機能の網羅的な調査でも、完全な調査でもありません。Rego の詳細については、OPA ウェブサイトの [Rego ドキュメント](https://www.openpolicyagent.org/docs/latest/#rego)を参照することをお勧めします。

![OPA と Rego を使用した基本的な ABAC](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/opa-example-1.png)


## 基本的な OPA ルールの例
<a name="basic-rules"></a>

前の図では、ペイロールマイクロサービスに対して OPA によって適用されるアクセスコントロールルールの 1 つを以下に示します。

*従業員は自分の給与を読み取ることができます。*

Bob が給与マイクロサービスにアクセスして自分の給与を確認しようとすると、給与マイクロサービスは API コールを OPA RESTful API にリダイレクトしてアクセスを決定できます。ペイロールサービスは、次の JSON 入力を使用して OPA に決定をクエリします。

```
{
    "user": "bob",
    "method": "GET",
    "path": ["getSalary", "bob"]
}
```

OPA は、クエリに基づいてポリシーを選択します。この場合、次のポリシーは Rego で記述され、JSON 入力を評価します。

```
default allow = false
allow = true {
    input.method == "GET"
    input.path = ["getSalary", user]
    input.user == user
}
```

このポリシーは、デフォルトでアクセスを拒否します。次に、クエリ内の入力をグローバル変数 にバインドして評価します`input`。ドット演算子は、変数の値にアクセスするためにこの変数とともに使用されます。ルールの式も true の場合、Rego ルールは true `allow`を返します。Rego ルールは、入力`method` の が GET と等しいことを確認します。次に、リスト内の 2 番目の要素を変数 に割り当てる`getSalary`前に、リスト内の最初の要素`path` が であることを確認します`user`。最後に、アクセスするパスが、リクエスト`user`を行う が `user`変数`input.user`と一致することを確認する`/getSalary/bob` ことによって であることを確認します。このルール`allow`は if-then ロジックを適用して、出力に示すようにブール値を返します。

```
{
    "allow": true
}
```

## 外部データを使用した部分的なルール
<a name="partial-rules"></a>

追加の OPA 機能を実証するために、適用するアクセスルールに要件を追加できます。前の図のコンテキストでこのアクセスコントロール要件を適用するとします。 

*従業員は、自分の部下の給与を読み取ることができます。*

この例では、OPA は、アクセス決定を行うためにインポートできる外部データにアクセスできます。

```
"managers": {
        "bob": ["dave", "john"],
        "carol": ["alice"]
}
```

 OPA で部分的なルールを作成することで、任意の JSON レスポンスを生成できます。このルールは、固定レスポンスの代わりに値のセットを返します。これは部分的なルールの例です。

```
direct_report[user_ids] {
    user_ids = data.managers[input.user][_]
}
```

 このルールは、 の値に報告するすべてのユーザーのセットを返します。この場合`input.user`、 は です`bob`。ルールの `[_]`コンストラクトは、セットの値を繰り返し処理するために使用されます。これはルールの出力です。

```
{
    "direct_report": [
      "dave",
      "john"
    ]
}
```

この情報を取得すると、ユーザーがマネージャーの直属部下であるかどうかを判断できます。一部のアプリケーションでは、シンプルなブールレスポンスを返すよりも動的 JSON を返すことをお勧めします。

## まとめ
<a name="abac-combination"></a>

最後のアクセス要件は、両方の要件で指定された条件を組み合わせるため、最初の 2 つよりも複雑です。

*従業員は、自分の給与と自分の部下の給与を読み取ることができます。*

この要件を満たすには、次の Rego ポリシーを使用できます。

```
default allow = false
 
allow = true {
    input.method == "GET"
    input.path = ["getSalary", user]
    input.user == user
}
 
allow = true {
    input.method == "GET"
    input.path = ["getSalary", user]
    managers := data.managers[input.user][_]
    contains(managers, user)
}
```

ポリシーの最初のルールでは、前述のように、自分の給与情報を表示しようとするすべてのユーザーが にアクセスできます。同じ名前の 2 つのルールを持つ は`allow`、Rego の論理**または**演算子として機能します。2 番目のルールは、 `input.user` (前の図のデータから) に関連付けられているすべてのダイレクトレポートのリストを取得し、このリストを `managers`変数に割り当てます。最後に、ルールは、自分の名前が `managers`変数に含まれていることを確認`input.user`して、給与を確認しようとしているユーザーが の直接レポートであるかどうかをチェックします。

このセクションの例は非常に基本的なものであり、Rego と OPA の機能を完全にまたは徹底的に調べることはできません。詳細については、[OPA ドキュメント](https://www.openpolicyagent.org/docs/latest/)を参照し、[OPA GitHub README](https://github.com/open-policy-agent/opa) ファイルを参照し、[Rego プレイグラウンド](https://play.openpolicyagent.org/)で実験してください。