お客様には、インターネットポータルと、ドメインにデータが入力されるユーザーがいます。 個人アカウントへのアクセスにはパスワードが必要です。パスワードがある場合、人間の物忘れもあります。
すでにパスワード変更ページがありましたが、メカニズムは最適ではありませんでした。 これがすべての出来事です。 ユーザーがパスワードを変更する要求をドメインに残しました。 応答として、システムは、管理者が手動で処理した要求を順番に残しました。 彼はドメインでパスワードを生成し、その後、アプリケーションでパスワードを割り当てました。 ユーザーは、「パスワードがこれに変更されました」という電子メール通知を受け取りました。
次の3つの点で混乱しました。
- Sharepoint。必要のない場所に残します。
- 管理者の参加の必要性。 私たちは、そのような日常的かつ頻繁な業務に対して、資格のある専門家をそらしたくありませんでした。
- パスワードをレターで直接送信しましたが、これはあまり安全ではありません。 このパスワードは画面から読み取ることができます。 漏れ方には多くの選択肢があります。
また、心理的な瞬間もありました：システムは、覚えるのが難しいほど複雑なパスワードを作成し、どこかに書き留めるだけで、安全ではありませんでした。 しかし、そのようなパスワードは忘れがちです。 この事実は、パスワードを変更するためのアプリケーションの数にも影響を与えたと推測できます。
それで、パスワードを変更するメカニズムを変更する時であることが明らかになりました。
このタイプのケースでは、情報量と節度のバランスが必要です。 ユーザーは、テキストの詳細と段落をオーバーロードしないでください。 同時に、2つの入力を記述して1つのボタンを配置することも間違っています。 そのため、デザイナーとコピーライターを持ち込みました。 この方法で、フロントエンドとバックエンドの両方でこれを最適な方法で行うための10のヒントをまとめました。
1. UIキットを使用して、パスワードを変更したレターとページを発行します
UIキットでパスワードを変更した手紙とページを作成します。つまり、サイトの一般的なスタイルで、美しくローカライズされています。 （UIキットの詳細については、 こちらをご覧ください ）。 これは、ナビゲートしやすくするためです。 人がプロセスから気をそらし、10分後に戻ってきたとしても、彼は自分がどのリソースにいるのか、なぜここにいるのかを理解します。
2.平文を書く
何が起こっているのか、ユーザーに何が必要なのかが非常に明確なテキストに取り組みます。 テキストが顧客の編集方針（コミュニケーションスタイル）に準拠し、 ベストプラクティスを考慮して編集されることは良いことです。 とても美しく有益な手紙が得られます。
3.誰がいつパスワードをリセットするかを示します
セキュリティについて考えることをお勧めします。 これを行うには、パスワードを変更するためにリンクがいつリクエストされたか、どのデバイスから、どのオペレーティングシステムおよびIPアドレスからの情報をレターに追加します。 ユーザーがリンクを要求しなかった場合、またはユーザーが所有していないデバイスを見た場合、これは間違いなく考えて、アラームを鳴らす機会です。 この情報を明るくして、目に見えるようにしますが、カルスの目は見えません。 同時に、パスワードを変更するためのメインリンクが大きな明るいボタンで描画されます-ユーザーにはすぐにそれが表示されます。
4.一時パスワードを変更するリンクを作成します
一時的なパスワード変更リンクは世界的な慣例です。 ユーザーは、パスワードの変更を申請した後、特定の時間に（たとえば、5分または24時間以内に）このパスワードを変更する必要があります。 明らかに、だれでもユーザーのパスワードを変更できる時間枠が限られていることがわかります。 したがって、セキュリティ上の理由から、この時間は制限されています。
5.パスワード変更ページでサードパーティのライブラリを使用しないでください
私たちの場合、以前のパスワード変更ページには、プロジェクト全体で共通のマスターページがあり、さまざまなサードパーティライブラリが既にロードされていました。 間違いを繰り返さないで、すぐに安全にしてください。 リンクが導かれ、パスワードが入力される新しいページでは、サードパーティのライブラリは使用されません。
6.プロセスから技術サポートを排除する（絶対に必要でない限り）
ユーザーが自分でパスワードを変更できるようにします。操作は簡単で自動化されています。 パスワードを要求し、リンクを受け取り、すべてを更新しました。 簡単！ 極端な場合にのみ、サポート部門がプロセスに接続されます-ユーザー自身がパスワードを変更できなかった場合のみ。
問題のあるアプリケーションは、エラーの技術的な原因を掘り下げて個別に修正できる専門家によって処理されます。
7.技術サポートを美しいUIにする-彼らは喜んでいます
Sharepointではなく、特別なアプリケーションシステムの美しいUIでパスワード変更要求を表示することにより、テクニカルサポートスタッフの作業を簡素化します。 作業が簡単になり、より良くなります。
8.バグ履歴を書く
テクニカルサポートの従業員は、ユーザーがパスワードを変更できなかったときに正確に何が起こったのか、つまりユーザーが受け取ったエラーの履歴全体をアプリケーションですぐに確認できれば、作業が速くなります。 この情報が与えられた理由を理解するのははるかに簡単です。
たとえば、ユーザーは特殊文字が何であるかを理解していないか、パスワードに大文字を含める必要があるというメッセージは表示されません。 彼らは、このアプリケーションを見つけるための多くの方法を持っています：ログイン、彼がこのアプリケーションを離れた時間まで、など。
9.技術サポートにパスワードを変更する機能を提供します。
テクニカルサポートサービスに自分でパスワードを変更し、ユーザーに伝える機能を提供します。 時には非常に必要です。 このパスワードの変更はセーフモードでも行うことをお勧めします。ページは別のブラウザウィンドウで表示され、サードパーティライブラリなしで作成されます。 すべての準備が整ったことをユーザーが確認した後、ユーザーは自動的に閉じます。
10.リクエストを監視し、ダイナミクスを追跡する
Serilogで監視を設定しました。 ELKでは、イベントをリセットし、Grafanaを介して、ユーザーがパスワードの変更を要求した4つのタイプの状況を監視します。
a。 緑色の線-ユーザーがドメインで見つかった、
b。 赤線-ドメインでユーザーログインが見つかりませんでした。 私たちにとって、2番目のアクションはマーカーです。 このスケジュールが忍び込んだ場合、1日に1回の試行を超えているため、悪意のある仲間が基地を集めようとしている可能性があります。
IPを無効にすることで、これに迅速に対応できます。 さらに、このアクティビティは自動化することができます-たとえば、10回のリクエスト後にIPを自動的に切断します。 ただし、一部の企業が1つのIPアドレスからインターネットをサーフィンしているため、これは常に機能するとは限りません。そのため、現時点ではこのチャートを監視しています。 彼は常にサポートサービスに注目されています。 そして、彼が突然上がった場合、その瞬間に私たちは何をすべきかを決定します。
c。 緑の線-ユーザーはパスワードの変更を正常に要求し、必要なリンクをそれぞれ開きました。すべてが正常であると想定しています。
d。 赤い線-ユーザーはパスワードを変更してもページを開くことができませんでした。 リンクに存在しないIDが使用されている、廃止されているなど。 一部のハッカーがパスワードを変更しようとしている人をキャッチするために一意の識別子を反復処理しようとしていると考えるのはかなり奇妙です。 しかし、原則として、これらのイベントを監視できます。このチャートが上昇したことがわかった場合は、イベントを分析して何が起こるかを確認できます。 たとえば、IDが破損し、一部が切り取られ、電子メールのリンクが不器用に挿入されることが判明する場合があります。
その結果、4つのスケジュールとイベントの連続タオルがあり、そこで何が起こったかを理解できます。 Grafanaをセットアップするためのすべての手順はこちらです。
そのため、目標を達成しました。パスワードの変更を自動化し、管理者の作業時間をより重要なタスクのために解放し、プロセスを可能な限り安全にしました。 このチェックリストが、同様のタスクで自分自身を確認するのに役立つことを願っています。