5

そのため、ここ数日、私は API セキュリティの「ベスト プラクティス」またはテクニック、特にサーバーからサーバーへ (サーバーからサーバーへ) 直接アクセスされる API について、インターネットを探し回っています。さまざまな意見があるようで、それらを実行可能なアイデアにまとめるのは難しい.

多くの人によると、OAuth が進むべき道です。セキュア ソケット プロトコルを使用したくないかどうかに応じて、それぞれ OAuth 1.0A または OAuth 2.0 を選択できます。

OAuth に関して、私の理解では、OAuth 1.0A の主な関心事は要求のデジタル サイネージですが、OAuth 2.0 は基盤となる HTTPS に依存して整合性を保証しています。では、次の仮定を立てても安全でしょうか?

前提: HTTPS を使用する場合、リプレイ攻撃、中間者攻撃を防ぎ、整合性を維持するために、HMAC または任意の形式のデジタル署名を使用する必要はありません。

これにより、交換されたトークンを介して OAuth が管理する承認が残ります。しかし、なぜそれほど複雑なのですか？たとえば、すべてのサーバー (プライベート コンシューマー) にグローバルに一意のユーザー名とシークレットを与えて、各「リクエスト」がシークレット、ユーザー名、およびリクエスト パラメーターのハッシュで「署名」されるようにすることはできますか?

私が知る限り、これは承認と認証を意味します。認証はハッシュの確認によって管理され、承認は禁止されます。これは、重要なことに、すべてのサーバーがそれぞれのリソースに対して同じ特権を持っているためです。

そのため、厳密にサーバー間 (または "2-legged") 通信用の API を設計する場合の最善のアプローチは何ですか? 単純に HTTPS を使用し、各リクエストにパーソナライズされたハッシュで署名することは安全ですか。これは、認証、承認を意味し、状態/セッションを維持する必要もありません。

標準への準拠は、サービスを利用するためのコードを作成する開発者、および一般的な Web 文化にとって有益であることは理解できます。そのため、OAuth の「サブセット」への準拠は魅力的に聞こえます。ここで必要かどうかはわかりません。

4

2 に答える 2

5

システム S2 との信頼関係が既にあるシステム S1 があるとします。OAuth が行うことは、S1 が S3 に S2 へのアクセスを許可できるメカニズムを提供することです。つまり、S3 には、S1 のアクセス許可の一部を使用して、S2 を操作するアクセス許可を与えることができます。これは、S1 が制御できる方法で行われます。

Q: 「たとえば、すべてのサーバー (プライベート コンシューマー) にグローバルに一意のユーザー名とシークレットを与えることはできますか?」 A: もちろん、これを行うことができます。通信したいすべてのシステムでユーザー名と固有のパスワードがあれば、OpenID や OAuth は必要ありません。しかし、これを管理するのは非常に困難になります。OAuth を使用すると、1 つのシステムで 1 つのシークレットを保持し、1 つのシークレットに基づいて任意の数の他のシステムを承認できます。それが存在する唯一の理由です。

OAuth の機能を見ると、基本的には、与えられるアクセスの種類ごとに新しい一意の共有シークレット (トークンと呼ばれますが、必要に応じてパスワードと呼ぶこともできます) が作成されます。その一意の秘密は S2 によって生成されますが、S1 から S3 に渡され、S3 が S2 にアクセスするためのパスワードとして使用できます。アクセスを「制御」しているのはS2です。OAuth が行う唯一のことは、トークンを S3 に取得することです。これにより、パスワードを設定する必要がなくなり、システム間で手動で持ち運ぶことができます。

「2 本足」の通信について話すとき、問題は、それらの間で共有秘密がどのように設定されたのかということです。手動で (つまり、物理的に携帯して) 両方のシステムにパスワードを設定する場合、OAuth は必要ありません。しかし、システムがたくさんある場合、それは大変なことです。N 個のシステムには (N*(N-1)/2) 個のパスワードが必要です。

通常、1 つのサーバーを「認証サーバー」として機能させ、すべてのサーバーがそれと信頼関係を持つようにする必要があります。次に、OAuth を使用して、他の 2 つのサーバー間の対話を承認します。それが複雑さのすべてです。

サーバー間の基本的な信頼関係を確立したら、その上でリクエストに署名したり、応答に署名したりできます (否認防止の目的で)。

サービスを設計するときは、アクセス権を与える方法を考える必要があります。たとえば、7 日間だけ有効な時間制限付きのアクセスが必要ですか? 「読み取り専用」アクセスを利用可能にしますか? これにより、S3 に与える S2 へのアクセスの種類に関する S1 オプションが与えられます。

具体例を挙げて説明しましょう。雪がいいので、スキーに行きたいと思っています。スキー場は開いていますが、お金はすべて銀行にあります。あなたがしたいことは、スキー場があなたの銀行口座から資金を引き出すことを承認することです。あなたはスキー場にすべてのお金を与えたくありません. 完全なパスワードで彼らを信頼していません。代わりに、まず銀行に連絡して、特定の金額を引き出すための「許可」を手配します。これはトークンで表されます。次に、そのトークンをスキー場に渡します。そのトークンを使用して、スキー場は指定された金額の資金を引き出すことができます。は常に資金を保護する責任があり、権限を設定できるトランザクションの種類を定義するのは銀行です。OAuth は、トークンを安全に渡すための標準的な方法です。

于 2013-01-05T04:22:20.237 に答える
2

「HTTPS通信にクライアント証明書を使用する」または「相互SSL」と呼ばれるソリューションとして説明したもの-サーバーはその証明書をドメインで提示し、クライアントは何らかの方法で自分自身を識別する証明書を提示します。サーバー対サーバーの場合に適しています。

このアプローチにより、サーバー/ユーザーを安全かつ標準的な方法で認証できます。着信要求を受信するサーバーは、呼び出し元によって提示された証明書に基づいて承認の決定を行うことができます。呼び出し元のサーバーは、独自の証明書をサービスに登録するか、定義済みの証明書を取得してサービスを呼び出す必要があります。

このアプローチは、クライアント証明書の配布を適切に制御できる場合、またはサーバーが外部から取得した証明書を受け入れる場合に有効です。通信の両端を制御する場合 (つまり、独自の多層システムのコンポーネント間のトラフィックを保護する場合)、このアプローチは最も単純なアプローチの 1 つです。

于 2013-01-05T03:51:47.963 に答える