Skip to content

Latest commit

 

History

History
94 lines (76 loc) · 14.1 KB

C06.アイデンティティと認証管理の実装.md

File metadata and controls

94 lines (76 loc) · 14.1 KB
Raw

C06:アイデンティティと認証管理の実装

説明

デジタルアイデンティティは、ユーザがオンライン取引を行う際の独自の表現です。 認証は、個人またはエンティティが正しい個人またはエンティティであることを確認するプロセスです。セッション管理は、サーバがユーザ認証の状態を維持するプロセスであり、ユーザは再認証せずにシステムを使用し続けることができます。NIST Special Publication 800-63B：デジタルアイデンティティガイドライン（認証およびライフサイクルマネジメント）は、デジタルアイデンティティ、認証、およびセッション管理制御の実装に関する確固たるガイドを提供します。 以下に、セキュアな実装のための推奨事項を示します。

認証レベル

NIST 800-63bは、認証保証レベル（AAL）と呼ばれる認証保証の3つのレベルを定義しています。AALレベル1は、PIIやその他の個人データを含まない低リスクのアプリケーション用です。 AALレベル1では、通常はパスワードを使用したシングルファクタ認証のみが必要です。

レベル1：パスワード

パスワードは本当に重要です。ポリシーを作成し、それらを安全に保管する必要があります。またユーザが時々パスワードをリセットできるようにする必要があります。

パスワード要件

パスワードは最低でも以下の要件を満たす必要があります。

  • マルチファクタ認証（MFA）やその他の制御も使用している場合には、少なくとも長さが8文字以上になるようにしてください。MFAが不可能な場合は、これを少なくとも10文字に増やす必要があります。
  • すべてのASCII文字とスペース文字を、秘密の質問で利用可能にするべきです。
  • 長いパスワードとパスフレーズの使用を推奨します。
  • 有効性が限られていることが判明した複雑な要件を削除する。 代わりに、MFAの採用またはより長いパスワードの採用を推奨します。
  • 使用されたパスワードが、以前のシステムへの不正アクセスで既に漏洩したパスワードではないことを確認します。漏洩したパスワードリストにある最も一般的なパスワードの上位1000または10000のうち、上記の長さの要件を満たしているパスワードをブロックすることを選択できます。以下のリンクには、最も一般的に使われているパスワードが記載されています：https://github.com/danielmiessler/SecLists/tree/master/Passwords
セキュアなパスワード復元機構の実装

アプリケーションでは、パスワードを忘れた場合にユーザが自分のアカウントにアクセスするための機構を持つのが一般的です。 パスワード復元機能の優れたデザインワークフローとしてマルチファクタ認証要素が使用されます。例えば、セキュリティに関する質問（彼らが知っていること）を求め、生成されたトークンをデバイス（彼らが持っているもの）に送信してもよい。 詳細は、Forgot_Password_Cheat_SheetおよびChoosing_and_Using_Security_Questions_Cheat_Sheetを参照してください。

セキュアなパスワードストレージの実装

強力な認証制御を提供するには、アプリケーションがユーザの資格情報をセキュアに保存する必要があります。さらに、資格情報（例えば、パスワード）が漏洩した場合、攻撃者がすぐにこの情報にアクセスすることができないように、暗号化により制御するべきです。

PHPにおけるパスワードストレージの例

以下は、password_hash（）関数（5.5.0から利用可能）を使用してPHPでセキュアにパスワードのハッシュ化を行う例です。この関数は、デフォルトでbcryptアルゴリズムを使用しています。 この例では、15回ハッシュ化の処理が行われています。

<?php
  $cost = 15;
  $password_hash = password_hash("secret_password", PASSWORD_DEFAULT, ["cost" => $cost] );
?>

詳細は、OWASP Password Storage Cheat Sheetを参照してください。

レベル2：マルチファクタ認証

NIST 800-63b AALレベル2は、「自己申告されたPIIまたはその他の個人情報がオンラインで利用可能になる」リスクの高いアプリケーション用です。 AALレベル2では、OTPや他の形式のマルチファクタ実装からなるマルチファクタ認証が必要です。 マルチファクタ認証（MFA）は、ユーザが以下のものを組み合わせて自分自身であることを示すことによって、自分が正しい人物であることを保証します。

  • 知っているもの - パスワードまたはPIN
  • 所有しているもの - トークンまたは電話
  • あなた自身- 指紋などのバイオメトリクス パスワード認証を唯一の方法として使用するとセキュリティが弱くなります。 マルチファクタソリューションは、サービスで認証するために複数の要素を取得するよう攻撃者に要求することにより、より堅牢なソリューションを提供します。 バイオメトリクスを認証の唯一の方法として使用する場合、デジタル認証において許容可能な秘密としてはみなされないことに注意する必要があります。バイオメトリクス情報は、オンライン、誰かがカメラ付き電話（例えば、顔画像）で撮影した写真、知識の有無にかかわらず、誰かが触れた物体（例えば、指紋）、または高解像度画像（例えば、虹彩）から得ることができます。バイオメトリクスは、身分証明書（自分が所有するもの）を使用したマルチファクタ認証の一部としてのみ使用する必要があります。例えば、ユーザが検証対象に対して手動で入力するワンタイムパスワードを生成するマルチファクタワンタイムパスワード（OTP）デバイスにアクセスします。

レベル3：暗号化ベース認証

NIST 800-63b AAL3は、侵害されたシステムの影響が人身傷害、著しい財政紛失、公益に害を及ぼしたり、民事または犯罪による暴動を招く可能性がある場合に必要です。AAL3は、「暗号プロトコルによる鍵の所持の証明に基づく」認証を要求します。 このタイプの認証は、最も強力な認証保証レベルを達成するために使用されます。 これは、通常、ハードウェア暗号化モジュールを介して行われます。

セッション管理

ユーザ認証が成功すると、アプリケーションは、限られた期間、この認証状態を追跡・維持することを選択することができます。これによりユーザは、各要求に対して再認証を受けることなく、アプリケーションの使用を続けることができます。このユーザの認証状態をトラッキングすることをセッション管理と呼びます。

セッション生成および破棄

ユーザの認証状態はセッション内で追跡されます。このセッションは、通常、Webベースのセッション管理のためにサーバに保存されます。 次に、セッション識別子がユーザに与えられ、ユーザは正しいユーザデータを含むサーバ側のセッションを識別することができます。 クライアントは、このセッション識別子を維持する必要があります。これにより、機微なサーバ側のセッションデータがクライアントから引き離されます。 セッション管理ソリューションを構築または実装する際に考慮すべきいくつかの制御を以下に示します。

  • セッションIDが長く、一意であり、かつ、ランダムであることを確認します。
  • アプリケーションは、認証および再認証中に新しいセッションを生成するか、少なくともセッションIDをローテーションする必要があります。
  • アプリケーションには、各セッションの非アクティブ期間と絶対最大存続期間の後のアイドルタイムアウトを実装する必要があります。タイムアウト後には、ユーザは再認証する必要があります。タイムアウトの長さは、保護されるデータの価値に反比例する必要があります。 詳細は、Session Management Cheat Sheetをご確認ください。ASVSセクション3では、追加のセッション管理要件を説明しています。
ブラウザCookie

ブラウザCookieは、Webアプリケーションがセッション管理技術を実装するWebアプリケーション用のセッション識別子を格納する一般的な方法です。以下にブラウザCookieを使用する際に考慮すべきいくつかの防御策を示します。

  • ブラウザCookieが認証されたユーザのセッションを追跡するための機構として使用されている場合、これらは最小限のドメインとパスのセットからアクセス可能であり、セッションの有効期間またはその直後に切れるようにタグ付けする必要があります。
  • セキュリティで保護されたチャネルのみ（TLS）を介して転送が行われるようにするには、secure属性を設定する必要があります。
  • JavaScript経由でCookieにアクセスできないようにするにはHttpOnly属性を設定する必要があります。
  • Cookieにsamesite属性を追加すると、現代のブラウザの中にはサイト間のリクエストでクッキーを送信できなくなり、クロスサイトリクエストフォージェリや情報漏えい攻撃に対する保護機能が提供されます。
トークン

サーバサイドのセッションは、いくつかの認証形式を制限する可能性があります。 「ステートレスサービス」は、パフォーマンス目的でクライアントサイドでのセッションデータの管理を可能にするため、サーバはユーザセッションを保存および検証する負担が少なくなります。 これらの「ステートレス」アプリケーションは、短期間のアクセストークンを生成します。このアクセストークンにより、最初の認証後には、ユーザの資格情報を送信せずにクライアント要求を認証することができます。

JWT (JSON Webトークン)

JSON Webトークン（JWT）は、JSONオブジェクトとして当事者間で情報をセキュアに伝送するコンパクトで自立的な方法を定義するオープンスタンダード（RFC 7519）です。この情報はデジタル署名されているため、検証および信頼することができます。JWTトークンは認証時に作成され、処理前にサーバ（またはサーバ群）によって検証されます。 しかし、JWTは最初の作成後にサーバによって保存されないことがよくあります。 JWTは、通常、作成された後、サーバに保存されずにクライアントに渡されます。 トークンの完全性はデジタル署名の使用によって維持されるので、サーバは後でJWTが有効であり、作成後に改ざんされていないことを検証できます。 このアプローチは、クライアントとサーバの技術が異なるがまだ相互作用する方法であり、ステートレスと移植性の両方を備えています。

注意

デジタルアイデンティティ、認証、セッション管理は非常に大きなトピックです。 私たちはここでデジタルアイデンティティの話題の表面を傷つけています。最も能力の高いエンジニアが、ほとんどのアイデンティティソリューションの複雑さを維持する責任があることを保証します。

脆弱性の防止

参考資料

ツール