サービスの説明
会社のウェブサービスへの外部アクセス用の追加の認証サービスは、アクセス元のIPアドレスとユーザーエージェントデータに基づくUIDで確認する必要があります。 検証の結果、UIDが信頼できるデータベースにない場合、ユーザーの電話番号またはメールアカウントに送信されたワンタイムパスワードを入力することにより、認証が必要です。
許可後、UIDは認証システムベースに追加されます。
サービスの概略図とコンポーネントのスキームを以下に示します。
基本的なシステムアーキテクチャ
次のように、私たち自身の機能の要件を決定しました。
- 会社のWebサービスのユーザーのIPによる動的承認（TCP：80、443）;
- SMTP、IMAP、Jabber、FTPなどのサービスの認証を有効にする機能 （ユーザーに不便を伴う）;
- Webサービス（メール、トラッカーなど）によってアクセス（フィルタリング）を区別する機能。
- 新しいアドレスは、以前に入力したmobでユーザーが受け取ったワンタイムパスワードを入力することで認証する必要があります。 電話またはメール;
- ユーザーデータベースはLDAPである必要があります。
- ユーザーに対応する携帯電話は、LDAP、ポータルアドレス帳、またはローカルシステムデータベース（1つ以上のオプションを実装）に保存する必要があります。
- システムのモジュール性：（システムの他の部分に重大な影響を与えることなく、システムの個々のモジュールを交換する能力：認証の種類を交換する能力、ファイアウォールまたは他のソフトウェアの種類を交換する能力）;
- 共通グループ（ユーザーにサービスのメインセットへのアクセスを許可するベースグループ/ロール）によるユーザーのフィルタリング。
- 追加のグループ（個々のサービス用）を追加し、これらのグループでフィルタリングする機能。
- 許可されたUIDのフローティングストレージ期間、次のパラメーターを考慮する必要があります。
-最後のエントリの処方（タイムアウト）
-入力の総数。 - CAPTCHA +ワンタイムパスワードを連続して2〜3回送信した後（5分など）、5〜10回送信した後の繰り返し送信のタイムアウト-ブロック。
- 認証が成功した場合と失敗した場合、ユーザーは次のメッセージを受信する必要があります。
-成功すると、「Successful login」バナーが数秒間表示され、探しているアドレスに送信されます
-認証が失敗した場合、エラーメッセージが表示され、テクニカルサポートの連絡先と再認証のリンクが表示されます - ユーザーが認証を受けたすべてのIPアドレスの保存。
- ユーザーが認証を要求したすべてのIPアドレスの保存。
- IPジオロケーションとTORの制限。
- 外部/内部アドレスの比率の普遍性;
- 信頼できるIPグループのみの多数のサービスの可用性（オプションのフィルターによって実装されます）;
- ワンタイムパスワードの受信に使用できる電子メールサーバーを制限する機能。
読者は、二要素認証を編成する提案された方法についてどう思いますか？ コメントとご提案をお待ちしております。
また、同様のシステムを実装した経験を誰かが共有できるかもしれません。