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

# よくある質問
<a name="faq"></a>

このセクションでは、マルチテナント SaaS アプリケーションでの API アクセスコントロールと認可の実装に関してよく寄せられる質問に対する回答を提供します。

**Q. 認可と認証の違いは何ですか？**

**A.**認証とは、ユーザーが誰であるかを検証するプロセスです。認可は、特定のリソースにアクセスするためのアクセス許可をユーザーに付与します。

**Q. SaaS アプリケーションの認可とテナント分離の違いは何ですか？**

**A. **テナント分離とは、共有インフラストラクチャで運用されている場合でも、各テナントのリソースを分離するために SaaS システムで使用される明示的なメカニズムを指します。マルチテナント認可とは、インバウンドアクションを承認し、間違ったテナントに実装されないようにすることです。架空のユーザーは認証および認可される可能性がありますが、別のテナントのリソースにアクセスできる可能性があります。認証と認可は必ずしもこのアクセスをブロックするものではありませんが、この目標を達成するにはテナントの分離が必要です。これらの 2 つの概念の詳細については、「SaaS アーキテクチャの基礎」ホワイトペーパーの[「テナント分離](https://docs.aws.amazon.com/whitepapers/latest/saas-architecture-fundamentals/tenant-isolation.html)に関する説明」を参照してください。 *AWS SaaS * 

**Q. SaaS アプリケーションのテナント分離を検討する必要があるのはなぜですか？**

**A.**SaaS アプリケーションには複数のテナントがあります。テナントは、顧客組織でも、その SaaS アプリケーションを使用する外部エンティティでもかまいません。アプリケーションの設計方法によっては、テナントが共有 APIs、データベース、またはその他のリソースにアクセスしている可能性があります。テナント分離を維持することが重要です。つまり、リソースへのアクセスを厳密に制御し、別のテナントのリソースにアクセスしようとする試みをブロックするコンストラクトは、あるテナントが別のテナントの個人情報にアクセスできないようにすることが重要です。SaaS アプリケーションは、多くの場合、テナントの分離がアプリケーション全体で維持され、テナントが独自のリソースにのみアクセスできるように設計されています。

**Q. アクセスコントロールモデルが必要なのはなぜですか？**

**A.**アクセスコントロールモデルは、アプリケーション内のリソースへのアクセスを許可する方法を決定する一貫した方法を作成するために使用されます。これは、ビジネスロジックと密接に整合しているユーザーにロールを割り当てることで実行できます。または、時刻やユーザーが事前定義された条件を満たしているかどうかなど、他のコンテキスト属性に基づいて実行できます。アクセスコントロールモデルは、ユーザーのアクセス許可を決定する認可を決定する際にアプリケーションが使用する基本ロジックを形成します。

**Q. API アクセスコントロールはアプリケーションに必要ですか？**

**A.**はい。APIs、発信者が適切なアクセス権を持っていることを常に確認する必要があります。また、広範な API アクセスコントロールにより、適切な分離を維持できるように、テナントに基づいてのみアクセスが許可されます。

**Q. ポリシーエンジンまたは PDPs が認可に推奨されるのはなぜですか？**

**A.**ポリシー決定ポイント (PDP) では、アプリケーションコードの認可ロジックを別のシステムにオフロードできます。これにより、アプリケーションコードを簡素化できます。また、APIs、マイクロサービス、バックエンド for Frontend (BFF) レイヤー、またはその他のアプリケーションコンポーネントの承認を決定するためのeasy-to-useべき等インターフェイスも提供します。

**Q. PEP とは**

**A.**ポリシー適用ポイント (PEP) は、評価のために PDP に送信される認可リクエストを受信する責任があります。PEP は、データとリソースを保護する必要があるアプリケーション、または認可ロジックが適用されるアプリケーション内の任意の場所に配置できます。PEPsは PDPs と比較して比較的簡単です。PEP は認可決定のリクエストと評価にのみ責任を負い、認可ロジックを組み込む必要はありません。

**Q. Amazon Verified Permissions と OPA のどちらを選択すればよいですか****？**

**A. **Verified Permissions と Open Policy Agent (OPA) のどちらかを選択するには、ユースケースと固有の要件を常に考慮してください。Verified Permissions は、きめ細かなアクセス許可を定義し、アプリケーション全体のアクセス許可を監査し、アプリケーションのポリシー管理システムを一元化するフルマネージド型の方法を提供しながら、ミリ秒単位の処理でアプリケーションのレイテンシー要件を満たします。OPA は、オープンソースの汎用ポリシーエンジンであり、アプリケーションスタック間でポリシーを統一するのに役立ちます。OPA を実行するには、通常はコンテナまたは AWS Lambda 関数を使用して、 AWS 環境でホストする必要があります。

Verified Permissions はオープンソースの Cedar ポリシー言語を使用し、OPA は Rego を使用します。したがって、これらの言語の 1 つに精通していると、そのソリューションを選択するのを妨げられる可能性があります。ただし、両方の言語について読み、解決しようとしている問題から戻り、ユースケースに最適な解決策を見つけることをお勧めします。

**Q: Verified Permissions と OPA に代わるオープンソースの代替手段はありますか****？**

**A.** [共通表現言語 (CEL](https://opensource.google/projects/cel)) など、Verified Permissions や Open Policy Agent (OPA) に似たオープンソースシステムがいくつかあります。このガイドでは、スケーラブルなアクセス許可管理ときめ細かな認可サービスとしての Verified Permissions と、さまざまなタイプのアプリケーションと認可要件に広く採用、文書化され、適応可能な OPA の両方に焦点を当てています。

**Q. OPA を使用するには認可サービスを記述する必要がありますか、それとも OPA と直接やり取りできますか？**

**A.** OPA を直接操作できます。このガイダンスのコンテキストにおける認可サービスは、認可決定リクエストを OPA クエリに変換するサービスを指します。その逆も同様です。アプリケーションが OPA レスポンスを直接クエリして受け入れることができる場合、この複雑さを追加する必要はありません。

**Q. 稼働時間と監査の目的で OPA エージェントをモニタリングするにはどうすればよいですか？**

**A.**OPA はログ記録と基本的な稼働時間モニタリングを提供しますが、そのデフォルト設定はエンタープライズデプロイでは不十分である可能性があります。詳細については、このガイドの前半の[「DevOps、モニタリング、ログ記録](devops.md)」セクションを参照してください。

**Q. 稼働時間と監査の目的で Verified Permissions をモニタリングするにはどうすればよいですか？**

**A.**検証済みアクセス許可は AWS マネージドサービスであり、 を通じて可用性をモニタリングできます AWS Health Dashboard。さらに、Verified Permissions は、Amazon CloudWatch Logs AWS CloudTrail、Amazon S3、Amazon Data Firehose へのログ記録が可能です。

**Q. OPA の実行に使用できるオペレーティングシステムと AWS サービスはどれですか？**

**A.** [macOS、Windows、Linux で OPA を実行できます](https://www.openpolicyagent.org/docs/latest/#running-opa)。OPA エージェントは、Amazon Elastic Compute Cloud (Amazon EC2) エージェントだけでなく、Amazon Elastic Container Service (Amazon ECS) や Amazon Elastic Kubernetes Service (Amazon EKS) などのコンテナ化サービスでも設定できます。

**Q. Verified Permissions の実行に使用できるオペレーティングシステムと AWS****サービスはどれですか？**

**A.**Verified Permissions は AWS マネージドサービスであり、 によって運用されています AWS。Verified Permissions を使用するには、サービスに認可リクエストを行う機能を除いて、追加の設定、インストール、ホスティングは必要ありません。

**Q. OPA は で実行できますか AWS Lambda？**

**A.** Go ライブラリとして Lambda で OPA を実行できます。[API Gateway Lambda オーソライザー](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html)に対してこれを行う方法については、 AWS ブログ記事[「オープンポリシーエージェントを使用したカスタム Lambda オーソライザーの作成](https://aws.amazon.com/blogs/opensource/creating-a-custom-lambda-authorizer-using-open-policy-agent/)」を参照してください。

**Q. 分散 PDP アプローチと集中型 PDP アプローチのどちらを決定すればよいですか？**

**A.**これはアプリケーションによって異なります。ほとんどの場合、分散型 PDP モデルと集中型 PDP モデルのレイテンシーの違いに基づいて決定されます。概念実証を構築し、アプリケーションのパフォーマンスをテストしてソリューションを検証することをお勧めします。

**Q: APIs 以外のユースケースに OPA を使用できますか？**

**A.**はい。OPA ドキュメントには、[Kubernetes](https://www.openpolicyagent.org/docs/kubernetes)、[Envoy](https://www.openpolicyagent.org/docs/envoy)、[Docker](https://www.openpolicyagent.org/docs/latest/docker-authorization/)、[Kafka](https://www.openpolicyagent.org/docs/latest/kafka-authorization/)、[SSH と sudo](https://www.openpolicyagent.org/docs/latest/ssh-and-sudo-authorization/)、[Terraform](https://www.openpolicyagent.org/docs/latest/terraform/) の例が記載されています。さらに、OPA は Rego 部分ルールを使用してクエリに任意の JSON レスポンスを返すことができます。クエリに応じて、OPA を使用して JSON レスポンスで多くの質問に回答できます。

**Q: API 以外のユースケースに Verified Permissions** **を使用できますか? APIs**

**A.**はい。Verified Permissions は、受信した認可リクエストに対して `ALLOW`または `DENY`レスポンスを提供できます。Verified Permissions は、認可の決定を必要とするアプリケーションまたはサービスに対して認可レスポンスを提供できます。

**Q. IAM ポリシー言語を使用して Verified Permissions でポリシーを作成できますか？**

**A. **いいえ。ポリシーを作成するには Cedar ポリシー言語を使用する必要があります。Cedar はお客様のアプリケーションリソースのアクセス許可管理をサポートするように設計されていますが、 AWS Identity and Access Management (IAM) ポリシー言語は AWS リソースのアクセスコントロールをサポートするように進化しました。