ユーザー アカウント、認証、パスワード管理に関する 13 のベスト プラクティス2021 年版
Google Cloud Japan Team
※この投稿は米国時間 2021 年 5 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。
2021 年用に更新: この投稿には、Google のホワイトペーパー「パスワード管理のベスト プラクティス」のユーザー向けとシステム設計者向けの両方の最新情報を含む、更新されたベスト プラクティスが含まれています。
アカウント管理、認証、パスワード管理には十分な注意を払う必要があります。多くの場合、アカウント管理は開発者や製品マネージャーにとって最優先事項ではなく、盲点になりがちです。そのため、ユーザーが期待するデータ セキュリティやユーザー エクスペリエンスを提供できていないケースがよくあります。
幸い、Google Cloud には、ユーザー アカウント（ここでは、システムに対して認証を受けるすべてのユーザー、つまりお客様または内部ユーザー）の作成、安全な取り扱い、認証に関して適切な意思決定を行なえるよう支援するいくつかのツールが用意されています。この投稿では、Google Kubernetes Engine でホストしているウェブサイト、Apigee 上の API、Firebase を使用するアプリ、などのユーザー認証を使用するサービスを管理している方を対象に、アカウント認証システムを安全かつスケーラブルで、実用的なものにするためのベスト プラクティスを紹介します。
1. パスワードをハッシュ化する
アカウント管理における最も重要なルールは、パスワードなどの機密性の高いユーザー情報を安全に保存することです。このようなデータを重大なものとして慎重に取り扱い、適切に処理する必要があります。
どのような状況でも、パスワードを平文で保存してはなりません。代わりに、Argon2id や Scrypt で作成された、暗号として強力な、復元できないパスワード ハッシュを保存すべきです。ハッシュには、その特定のログイン認証情報に固有の値をソルトとして加えるようにします。MD5 や SHA1 などの非推奨のハッシュ技術を使用しないでください。また、どのような状況でも、復元可能な暗号化を使用したり、独自のハッシュ アルゴリズムを考案しようとしたりてはなりません。侵害に備えて、データベースに保存されていないペッパーを使用してデータの保護を強化し、パスワードを何度も繰り返し再ハッシュすることの利点も考慮しましょう。
いつか侵害されるような事態が生じることを想定してシステムを設計しましょう。「もし今日データベースに侵入されたとしたら、自分の組織のサービスや、ユーザーが使用する他のサービスで、ユーザーの安全やセキュリティが危険にさらされることはないだろうか」、そして「漏洩した場合の損害の潜在的なリスクを軽減するために何ができるだろうか」と自問してみてください。
もう 1 つのポイント: ユーザーがパスワードを入力した直後以外のタイミングで、ユーザーのパスワードを平文で生成できてしまう場合は、実装に問題があります。
「Password」から「pAssword1」への変更など、重複に近いパスワードを検出する必要がある場合は、禁止する一般的なバリアントのハッシュを、すべての文字を正規化して小文字に変換してから保存します。これは、パスワードの作成時または既存のアカウントへのログインが成功した時点で行うことができます。ユーザーが新しいパスワードを作成したときに、同じタイプのバリアントを生成し、そのハッシュを以前のパスワードのハッシュと比較します。実際のパスワードと同じレベルのハッシュ セキュリティを使用してください。
2. 可能であれば、サードパーティの ID プロバイダを許可する
サードパーティの ID プロバイダを許可すると、信頼できる外部サービスを利用してユーザーの ID を認証できます。一般的に使用されるプロバイダとして、Google、Facebook、Twitter があります。
Identity Platform などのプラットフォームを使用すると、既存の内部認証システムとともに外部 ID プロバイダを実装できます。Identity Platform には、管理の簡素化、攻撃対象領域の縮小、マルチプラットフォーム SDK など、多くの利点があります。このリスト全体を通して、その他の利点についても触れていきます。
3. ユーザー ID とユーザー アカウントのコンセプトを分離する
ユーザーはメールアドレスではありません。電話番号でもありません。一意のユーザー名でさえありません。これらの認証要素はいずれも、アカウント内のコンテンツや個人を特定できる情報（PII）を変更しなくても変更できるようにする必要があります。ユーザーは、独自の個人データやサービス内でのエクスペリエンスを多面的に結集したものであり、認証情報の集合ではありません。適切に設計されたユーザー管理システムでは、ユーザーのプロファイルの各部分間の結合度が低く、凝集度が高くなります。
ユーザー アカウントと認証情報のコンセプトを分離すると、サードパーティの ID プロバイダを実装したり、ユーザーにユーザー名の変更を許可したり、複数の ID を単一のユーザー アカウントにリンクしたりするプロセスが大幅に簡素化されます。実務では、すべてを 1 つのレコード内に積み重ねるのではなく、各ユーザーに抽象的な内部グローバル ID を設定して、その ID を介してユーザーのプロファイルと 1 つ以上の認証データセットを関連付けておくと有益な場合があります。
4. 単一のユーザー アカウントに複数の ID をリンクできるようにする
ある週にユーザー名とパスワードを使用してサービスへの認証を行なった後で、アカウントが重複して作成される可能性があることを知らずに、次の週に Google ログインを選択するユーザーがいるかもしれません。同様に、正当な理由があってユーザーがサービスに複数のメールアドレスをリンクする場合も考えられます。ユーザー ID と認証を適切に分離していれば、複数の認証方法を単一ユーザーに簡単な手順でリンクできます。
バックエンドでは、ユーザーがシステム内の既存のアカウントにリンクされていない新しいサードパーティ ID を使用していることに気付く前に、ユーザーがサインアップ プロセスの一部または全部を完了してしまう可能性を考慮する必要があります。この問題を最も簡単に解決するには、ユーザーにメールアドレス、電話番号、ユーザー名などの一般的な識別情報の入力を求めることです。そのデータがシステム内の既存のユーザーと一致する場合は、既知の ID プロバイダでも認証して、新しい ID を既存のアカウントにリンクするようにユーザーに要求します。
5. 長いパスワードや複雑なパスワードをブロックしない
NIST では、パスワードの複雑さと強度に関するガイドラインを公開しています。パスワードの保存に強力な暗号化ハッシュを使用している（または今後使用する）のであれば、それで多くの問題は解決されます。ハッシュでは、入力する長さに関係なく常に固定長の出力を生成するため、ユーザーはパスワードを好きなだけ長くすることができます。パスワードの長さを制限する必要がある場合は、インフラストラクチャの制限に基づいて制限してください。問題になるのは多くの場合、メモリ使用量（1 ログイン操作あたりの使用メモリ x 1 マシンあたりの可能性のある同時ログイン数）で、またそれ以上に可能性が高いのは、サーバーで許容される最大 POST サイズです。これは数百 KB から 1 MB を超えるほどの数値にすぎません。大げさではなくその程度です。大量入力による不正行為を防ぐためには、アプリケーションを強化しておく必要があります。クレデンシャル スタッフィングを防ぎ、できるだけ早く入力をハッシュしてメモリを解放する管理方法を採用している場合は、これによって新たに不正行為の機会が生��れることはありません。
ハッシュ化されたパスワードは、すでにサイズの小さい ASCII 文字セットになっていることがほとんどです。そうでない場合は、バイナリ ハッシュを Base64 に簡単に変換できます。そのことを念頭に置いて、ユーザーがパスワードにどんな文字でも使用できるようにすべきです。クリンゴン語、絵文字、両端に空白を含むASCII アートで作成されたパスワードにしたい人がいれば、それを拒否する技術的な理由はありません。ただし、クロス プラットフォームの互換性を確保するために、必ず Unicode 正規化を行ってください。Unicode と、パスワードでサポートされている文字の詳細については、システム設計者向けホワイトペーパー（PDF）をご覧ください。
極端なパスワードを使用しようとしているユーザーは、おそらくパスワードのベスト プラクティス（PDF）に従って、パスワード マネージャーを使用しています。これを使用すると、制約のあるモバイル デバイスのキーボードでも複雑なパスワードを入力できます。そもそもユーザーが文字列を入力できる場合（パスワード入力の HTML 仕様で改行が許可されていない場合）、そのパスワードは許容されるべきです。
6. ユーザー名に不当なルールを課さない
サイトまたはサービスで 2 文字または 3 文字以上のユーザー名を要求する、隠し文字をブロックする、ユーザー名の最初と最後の空白を禁止するといったルールは不当ではありません。ただし、一部のサイトでは、最小文字数が 8 文字であったり、7 ビットの ASCII 文字や数字以外の文字をブロックしたりするなど、要件が厳しすぎる場合があります。
ユーザー名に対する制限が厳しいサイトは、開発者にとっては便利で手っ取り早いかもしれませんが、ユーザーを犠牲にすることになり、極端な場合はユーザーが登録を思いとどまることにもなりかねません。
場合によっては、ユーザー名を割り当てるのが最善の方法になります。その場合は、割り当てられたユーザー名をユーザーが思い出して使用できるよう、割り当てるユーザー名がユーザー フレンドリーなものになるようにしてください。英数字で生成される ID では、「Il1O0」などの視覚的に見分けにくい記号を避ける必要があります。また、ランダムに生成された文字列に対して辞書スキャンを実行して、ユーザー名に意図しないメッセージが埋め込まれていないか確認することをおすすめします。パスワードを自動生成する場合にも、この同じガ��ドラインが適用されます。
7. ユーザーの ID を検証する
ユーザーに連絡先情報の入力を求める場合は、その連絡先をできるだけ早く検証する必要があります。検証コードまたはリンクをメールアドレスまたは電話番号に送信します。そうしないと、ユーザーが連絡先情報を間違って入力した場合、次にログインしようとしたときに、自分の情報に一致するアカウントがないとわかるまでにかなりの時間が費やされる可能性があります。このようなアカウントは使用できないまま残されることが多く、手作業による介入なしには回復できません。さらに悪いことに、間違った連絡先情報が他の人のもので、そのアカウントの完全な制御権が第三者にわたってしまうこともあります。
8. ユーザーがユーザー名を変更できるようにする
古いシステムや、メール アカウントを提供するプラットフォームでは、ユーザーがユーザー名を変更できないようになっていることが非常によくあります。ユーザー名を自動的に解放して再利用できるようにしないのには正当な理由があります。しかし、システムを長期にわたって使用していると、ユーザーはいずれ何らかの重要な理由により別のユーザー名も使用しなければならなくなります。そして、その際には新しいアカウントの作成を望まないことがほとんどです。
ユーザー名を変更したいというユーザーの要望を尊重するには、複数のユーザー名の使用を許可したうえで、ユーザーがメインのユーザー名を選択できるようにします。この機能を整備すれば、これに付け加える形で必要なビジネスルールを適用できます。組織によっては、1 年間に行えるユーザー名の変更の回数を制限したり、表示や連絡にメインのユーザー名以外のユーザー名を使用できないようにしていたりする場合もあります。メールアドレス プロバイダは、メールアドレスを再発行しないよう推奨されています。それでも、発行済みのメールアドレスのユーザー名を新しいユーザー名に変更することはあります。先進的なメールアドレス プロバイダであれば、ユーザーが独自ドメイン名を使用できるようにしたり、好きなアドレスを持てるようにしたりしている場合もあります。
古い形式のアーキテクチャを使用している場合、このベスト プラクティスを満たすのは非常に困難な場合があります。Google のような企業でさえ技術的なハードルがあり、思っている以上に困難が伴います。新しいシステムを設計するときに、ユーザー ID とユーザー アカウントのコンセプトを分離し、複数の ID を単一のユーザー アカウントにリンクできるようにするための措置を最大限講じておくと、この問題はかなり小さくなります。既存のコードを使用する場合でも、これからコードを開発する場合でも、ユーザーが後で拡張や変更を行なえるようにすることに重点を置いて、組織に適したルールを選択してください。
9. ユーザーがアカウントを自分で削除できるようにする
アカウントと関連付けられた PII をユーザー自身が削除できるようにするための手段を提供していないサービスは非常に多くあります。サービスの性質によって、投稿やアップロードなどのユーザーが作成した公開コンテンツも削除できない場合もあれば、できる場合もあります。ユーザーには、アカウントを永久的に閉鎖して PII をすべて削除する正当な理由が多数あります。ユーザーのこうした懸念と、ユーザー エクスペリエンス、セキュリティ、コンプライアンスのニーズとのバランスを取る必要があります。ほとんどではないにしても、多くのシステムはなんらかの規制管理（PCI や GDPR など）の下で運用されています。こうした規制では、少なくとも一部のユーザーデータに対してはデータ保持に関する具体的なガイドラインが規定されています。コンプライアンスに関する不安を避け、データ侵害が発生する可能性を抑えるための一般的な解決策に、将来アカウントを自動的に削除するスケジュール設定をユーザーが行えるようにするというものがあります。
状況によっては、PII を適時に削除するというユーザーの要求に応じることが法的に義務付けられる場合もあります。また、「閉鎖された」アカウントからデータが漏洩してデータ侵害が発生した場合には、大量の個人情報が流出してしまうことになります。
10. セッションの長さを意識的に決定する
セキュリティと認証の見落とされがちな側面として、セッションの長さがあります。Google では、ユーザーの本人確認を確実に行えるよう尽力しており、特定のイベントや行動に基づいて再確認しています。ユーザーはセキュリティをさらに強化するための措置を講じることができます。
重要ではない分析が目的の場合など、サービスのセッションを無期限に開いたままにするべき理由があることもありますが、しきい値を設けて、その経過後にパスワードや第 2 の要素などのユーザー検証を求めるようにすることをおすすめします。
ユーザーが再認証を要求されずに非アクティブでいられる時間を検討しましょう。誰かがパスワードの再設定を行った場合は、すべてのアクティブなセッションでユーザー ID を検証してください。ユーザーがプロファイルの主な要素を変更した場合、または機密性の高い操作を実行している場合は、認証または第 2 の要素の入力を求めます。ユーザーの現在位置が短時間のうちに大きく変わった場合は、再認証を求めるようにします。一度に複数のデバイスまたは場所からログインできないようにするのが適切であるかどうかも検討しましょう。
サービスでユーザー セッションが期限切れになったり、再認証を要求したりする場合は、ユーザーにリアルタイムでプロンプトを表示するか、最後に認証されてからまだ保存していないアクティビティを保持するメカニズムを提供します。時間をかけてフォームに入力したのに、入力した内容がすべて失われて再度ログインしなければならなくなると、ユーザーは強いいらだちを感じます。
11. 2 段階認証プロセスを使用する
2 段階認証プロセス（2 要素認証、MFA、2FA とも呼ばれます）を選択する場合は、アカウントが盗まれた場合のユーザーへの実質的な影響を考慮します。時間ベースのワンタイム パスワード（TOTP）、メール確認コード、「マジックリンク」は、ユーザー フレンドリーで比較的安全です。SMS 2FA 認証には複数の弱点があるため、NIST で非推奨になりましたが、重要とはみなさない些細なサービスでユーザーが受け入れる認証方法としては、最も安全な選択肢になる場合もあります。
合理的に可能な最も安全な 2FA 認証を提供してください。Titan セキュリティ キーなどのハードウェア 2FA がアプリケーションで実行可能な場合には、これを使用するのが理想的です。アプリケーションで TOTP ライブラリを使用できない場合でも、サードパーティの ID プロバイダが提供するメール確認や 2FA を使用すれば、多大な費用や労力をかけずに簡単にセキュリティを強化できます。最も弱い 2FA またはアカウント復元方法以上に安全な方法でユーザー アカウントのセキュリティを確保することを忘れないでください。
12. ユーザー ID の大文字と小文字を区別しない
ユーザーはユーザー名の大文字と小文字に注意を払わず、どちらを使用したか正確に覚えていない場合さえあります。そのため、ユーザー名の大文字と小文字を区別しないことをおすすめします。ユーザー名とメールアドレスをすべて���文字で保存しておき、比較する前に入力を小文字に変換するのは簡単なことです。変換時にはロケールを指定するか、Unicode 正規化を使用するようにします。
ユーザー デバイスの中でスマートフォンが占める割合は増え続けています。ほとんどのスマートフォンが、書式なしテキスト フィールドの自動修正と自動大文字化の機能を搭載しています。UI レベルでこの動作を防ぐのは望ましくないか、まったく効果がない場合もあるので、意図せず自動大文字化されたメールアドレスやユーザー名を処理できるような強固なサービスにすべきです。
13. 安全な認証システムを構築する
Identity Platform のようなサービスを使用すると、多くのセキュリティ上の懸念が自動的に処理されます。ただし、不正行為を防ぐためには、サービスを常に適切に設計する必要があります。主な考慮事項として、パスワード復旧の代わりとなるパスワードの再設定の実装、詳細なアカウント アクティビティのログ記録、クレデンシャル スタッフィングを防ぐためのレート制限ログイン試行、ログイン試行の失敗が多すぎる場合のアカウントのロックアウト、長期間アイドル状態であった認識されていないデバイスまたはアカウントの 2 要素認証プロセスの要求などがあります。安全な認証システムにはその他にも多くの側面があるため、以下の関連情報セクションで詳細情報へのリンクをご覧ください。
関連情報
アカウントと認証管理システムの開発、更新、移行の手順を説明した優れたリソースが数多くあります。はじめに以下をご覧になることをおすすめします。
NIST 800-063B には、認証とライフサイクル管理が取り上げられています
OWASP はパスワード保存のクイック リファレンスを継続的に更新しています
OWASP が認証のクイック リファレンスでさらに詳しく説明しています
Google Cloud Identity Platform は、堅牢な認証機能を備えたマルチプロトコルの顧客 ID とアクセス管理のソリューションです
Google の Firebase Authentication サイトには、ガイド、参考資料、サンプルコードの豊富なライブラリがあります
- GCP ソリューション アーキテクト Ian Maddox
