JSON Web Tokens-キーを安全に保存する方法
認証のための従来のCookieの代わりとしてJSON Web Tokenに出会ったとき、私はRESTful Webサービスを構築していました。この方法の概念的なコアは、ペイロードをダイジェストする（通常はHS256を使用して）ために使用される秘密鍵を知っている唯一のエージェントであるため、クライアントがメッセージの内容を変更したかどうかを判断できるのは彼だけです。このアプローチに関する私の懸念は、ペイロードを暗号化するためにサーバーが使用する秘密鍵を安全に保存するにはどうすればよいですか？定期的に交換すべきですか？ 「ランダムに」生成する必要がありますか？
RESTful Webサービスが初期化されるときに「ランダムな」文字列を生成し、後でペイロードをダイジェストするために使用される「グローバル変数」に格納することを考えました。ただし、別のプロセスが私のREST api 'memory space'にアクセスする可能性、または私のオペレーティングシステムの virtual memory feature が私の秘密鍵を公開する可能性を恐れています。
実際には、他のプロセスがプロセスメモリまたは仮想マシンの機能にアクセスできる場合、すでに危険にさらされているためゲームは終了しています。プロセスがこのレベルでアクセスできる場合、トークンを取得する前に認証に使用される初期認証情報や、実際の検証結果にもかかわらずトークン検証がtrueになるように結果を変更するなど、他の情報を取得する可能性があります。極端な可能性についての多く。ほとんどの侵害は、はるかに単純なエクスプロイトまたは構成エラーによって発生します。たとえば、ファイルシステムにプライベートキーを保存することで、誰でも読み取り可能で、Webサーバーからアクセスできます。
キーとシークレットを管理する最良の方法は、プラットフォームによって多少異なります。一部のプラットフォームはキー管理フレームワークを提供し、おそらくそれらの1つを使用することが適切でしょう。
これが秘密の鍵であるという事実にあまり重点を置かないでください。実際には、管理する必要がある他の資格情報ほど重要ではありません。たとえば、データベースへのアクセスを許可する資格情報をどのように管理しますか？そのソリューションがデータベースに対して十分である場合、おそらく秘密鍵に対しても十分です。そうでない場合は、実際にデータベースにとって十分かどうかを尋ねます。現実には、誰かがシステムに危害を加えようとしている場合、インターフェースが提供するあらゆるデータ/サービスにアクセスするために、彼らがそうしている可能性があります。ほとんどの場合、この基盤となるサービスまたはデータベースには資格情報と資格情報の管理も必要であり、これらは王国の真の鍵です。
一貫したアプローチを使用してアプリケーションが必要とするすべての資格情報を管理し、トークンの作成/検証のための秘密鍵を特別なものとして扱わないことが最善だと思います。 「鍵」や「秘密」などの単語が含まれているという理由だけで解決策を考えすぎないでください。すべての資格情報は機密データであり、安全な方法で管理する必要があります。行われるミスの大部分は、保守が困難になり、間違いを起こしやすくなる、過度に設計された複雑なソリューションが原因です。 keytool、キーチェーンマネージャーなど、既存の既知のテスト済みの機能/フレームワークを使用するソリューションを検討してください。それができない場合は、簡単に理解および保守できるものを使用してください。データベースと同じくらい簡単なもので十分かもしれません。情報を定数またはグローバル変数として格納するソリューションは避けてください。キーを変更するとコードが変更され、テスト、変更管理を行って本番環境にプロモートする必要があるため、これを維持することが困難になる可能性があります。
どのようにキーを生成するかについては、環境と管理する必要のあるリスクのタイプ/レベルによって異なります。経験則として、私は「ランダム」に依存するものには常に非常に注意しています。真のランダム値を生成することは非常に困難であり、セキュリティを向上させるために何もしません。実際、後でランダムではないことが判明したランダム性の仮定はパターンを明らかにする可能性があり、これは、将来の値を予測できる可能性を意味します。このシナリオでは、システム管理者がキーを知らないことが重要な環境でない限り、ランダム性がセキュリティの観点から多くを得るとは思いません。同様に、キーを定期的に変更しても、ユーザーに不便さ以外の多くのことをもたらすことはほとんどありません。キーを変更すると、現在発行されているすべてのトークンが無効になります。スタッフが辞任または役割を変更したときにキーを変更するポリシーを検討することをお勧めします。ソフトウェアが更新されるたびにキーを変更するポリシーを検討することもできます。
しかし、毎週など、宗教的に鍵を変更しても、セキュリティに関しては何も提供されないでしょう。
上記はすべてのキーに当てはまるわけではないことに注意してください。ルートCAの秘密キーなど、秘密キーを細心の注意を払って管理する必要がある状況があります。すべてのキーが等しいわけではありません。管理アプローチは、保護する必要がある要件とリスクに一致する必要があります。 JWTの場合、大部分が閉じたエコシステムを扱っています。キーは、トークンの生成/署名および検証に使用されます。目的は、改ざんの検出であり、秘密の保護ではありません。リスクは、誰かがキーを取得した場合、偽造されたトークンを作成し、サービスへの不正アクセスを取得できることです。これが最終的に何を意味するかは、サービスによって異なります。誰かがこれを行おうとする程度は、基礎となるサービスとその認識された価値にも依存します。キーを保護するために使用する長さは、脅威を反映している必要があります。