web-dev-qa-db-ja.com

認証で自分自身と単一障害点を繰り返さないでください

私の仕事では、現在資格情報データベース(asp.netフォーム認証)を共有しているが、資格情報を収集および検証するための独自のコードを持っている多数のWebアプリケーションに2要素認証を実装する任務を負っています。

この問題を検討するにあたり、すべての認証を1つのWebサービス(FWIWは私が見ている IdentityServer )に統合して、さまざまなWebアプリケーションすべてで使用できるようにするのが良い時期だと考えました。

私の考えでは、これはDRY原則に従い、2FA自体の実装とテストを容易にし、将来的にはより保守しやすいシステムにつながります。しかし、私の計画について同僚と話し合うことで、システムに単一障害点を導入していること、および認証サービスにバグが導入された場合、すべてのアプリケーションがダウンすることを明確にします。明確にするために、サービスの可用性について話しているわけではありません(サービスはホストされます)私の同僚が合理的に受け入れている他のアプリケーションと同じレベルの復元力のあるインフラストラクチャで)、ただし、単一のバグがすべてのアプリケーションを停止する可能性についてです。彼の提案は、認証を個々のアプリケーションに書き込むか、またはプライマリシステムに障害が発生した場合に備えて、ある種の冗長認証システムを提供します。

私にとって、この議論は間違った方法で感じるだけです。すべてのサービスの失敗を停止するために異なる実装に依存している場合、それは間違っています。しかし、私は同僚を説得するために説得力のある訴訟を起こすことができませんでした。私が提唱した議論のいくつか:

  • これは、プロジェクト間でライブラリを使用する場合と同じです。これらのライブラリの重大なバグが本番環境に到達した場合、多くのアプリケーションが停止する可能性があります。ただし、ここでコードを共有しないことをお勧めしません。これは概念的に違いますか?
  • 改善の余地はありますが、ひどいテスト/展開プロセスはありません。私たちは継続的な統合を使用し、自動化された単体テスト、合理的なテスト環境、および手動のテストスクリプトを用意しています(バグが発生した場合に本番環境のデプロイメントを元に戻す機能は言うまでもありません)。バグは常に発生しますが、このプロセスはそれを緩和するものであり、2回書くことはありません。
  • その性質上、認証プロセスは定期的に大きな変更が加えられるようなものではありません。機能する認証システムを取得したら、それをそのままにして、何かを壊すリスクをかなり低くします。
  • DRY原則-同じことを複数回書いていると、1つのサービスを持つよりもバグが発生し、維持するのが悪夢になる可能性が高くなりますか?
  • 冗長な認証実装のアイデアは、私にはかなりおかしいです。たぶん、私たちが旅客機用の自動操縦ソフトウェアを書いていたが、安全性が重要でないWebアプリケーション用ではなかったかもしれません。

私の同僚は確信が持てないままです。私が間違っている?そうでなければ、ここで見逃しているキラー引数は何ですか?

7
Slappywag

認証を単一のサービスに統合することは Single Sign-On と呼ばれ、30年ほどの間、これはベストプラクティスでさえありました。

彼は、個々のアプリケーションに認証を書き込むか、プライマリシステムに障害が発生した場合に備えて、何らかの冗長な認証システムを提供する必要があると提案しています。

個々のアプリケーションにASP.net認証が既にあるので、公平を期すために、「認証を個々のアプリケーションに書き込む」(多くのカットアンドペースト、または共有ライブラリなどを使用)のは、おそらく最低限の量です。作業。

冗長な認証システムの提案は、セキュリティの問題であり、メンテナンスの問題でもあり、明らかにbananasです。それは深刻な提案ではありません。

私には、プログラミングの問題ではなく、人の問題があるように見えます。あなたの人々の問題は、あなたの同僚のreal反対の理由を理解する必要があるということです。それはおそらく彼が実際に言ったことではありません。

いくつかの可能性:

  1. 各アプリケーションの認証スタック全体を書き換えるのは大変な作業になると彼は感じています。
  2. 彼は、各アプリケーションの認証スタック全体を書き換えることは、既存の資格情報認証を破壊する可能性があるという点で、危険すぎると感じています。
  3. 彼はIdentityServerソリューションを理解していません。そのため、それには慣れていません。
  4. 彼は自分でIdentityServerソリューションを思いついたわけではありません。そのため、それは快適ではありません。
  5. 彼は、OpenID/OAuthなどを使用せずに、2FAを使用することで、対処するのに十分な新しいテクノロジーと、アプリに追加するのに十分な新しい複雑さを感じると感じています。
  6. 私が考えていない何か他のもの

その根本的な異論を見つけ、それを公正に評価する必要があります。 (彼は正しいかもしれません!)

1つのアプローチは、それぞれが提唱した特定のソリューションから後退し、少なくとも、技術的リスク、短期vsのそれぞれの好みを考慮して、ソリューションを選択するために使用する必要がある基準に同意することです。長期的なワークロードなど(交渉学校では、これを 興味とポジションを区別する と呼びます。)

結局のところ、彼が正しいこと、そしてあなたが間違っていることをまだ確信している、そしてあなたが正しいこと、そして彼が間違っていることを確信している場合、それぞれの好みのオプションを提示できるレベルまでレベルを上げる必要があります。電話をかける権限を与えられた誰かに。そして、あなたはどちらも決定を受け入れる必要があります。

9
David Moles

同じコードに依存しているため、単一障害点としてカウントされるのは必ずしも間違っているわけではなく、ばかげているという考えです。そのロジックを使用すると、そのルールに従うランダムなことを考え続けることができます-なぜ同じルーター、スイッチ、Webサーバー、プログラミング言語、フレームワークなどを使用するのですか?

実際には、あなたはalready同じ資格情報データベースを使用しており、alreadyは単一障害点を持っています。実際、各システムがこのデータベースに直接アクセスできる場合、他のアプリケーションを妨害する方法でデータベースにアクセスする可能性があります。コードを信頼しなくなったという論理からすると、N個の認証システムを使用することにより、実際にはN個の単一点障害があると主張できます。一方、APIが1つの場合は、アクセスを制御してNを1に減らすことができます。

7
Kevin Raoofi

私も同じような議論をしてきましたが、あなたの同僚は間違っていません。高可用性アーキテクチャを使用することでリスクを軽減できるという結論に達しました(私たちはAtalasianのCrowdを使用していますが、考え方はIdentityServerと同じです)。サービスが停止すると、ユーザーが認証できなくなるリスクがあります。このリスクを軽減するために、IdentityServerの可用性を高めることを検討することをお勧めします。基本的に、ロードバランサー(私はHAプロキシまたはNginxが好きです)を実行し、IdentityServerの複数のインスタンスを実行します。次に、インスタンスはデータベースのクラスターに接続します。

この高可用性には、いくつかの利点があります。 1つ目は、ノードまたはデータベースがダウンしても機能が持続し、可用性に影響がないことです。 2つ目は、ノード間でユーザーの負荷を分散することです。前もってもう少し作業が必要ですが、結局それだけの価値があります。

高可用性のための典型的なデプロイメントを示すドキュメントページは次のとおりです。 http://docs.identityserver.io/en/release/topics/deployment.html

2
Thomas Hastings

価値のあるものとして、あなたが提案しているアーキテクチャは、最も健全な大規模組織が必要とするものです。認証は独自のサービスであるため、サードパーティがAPIを使用するためのOAuth2認証などの新機能を簡単に作成できます。

実際、OAuth2仕様では、承認サーバーがリソースサーバーから分離されていると想定されているため、この内部設計が明らかになっています。私が何を話しているのかわからない場合は、 http://search.cpan.org/~tilly/LWP-Authen-OAuth2-0.07/lib/LWP/Authen/OAuth2/Overview.podを参照してください。 OAuth2がどのように機能するかについて数年前に書いた説明について。

1
btilly