Qt Network Authorization セキュリティに関する考慮事項

このページでは、以下の技術を使用するアプリケーションにおけるセキュリティ上の考慮事項について解説します Qt Network Authorization。ここでの内容の多くは、OAuth 2.0 認証フレームワークと OpenID に焦点を当てています。

OAuth 2.0 プロトコルのフローについてはRFC 6749を、ネイティブアプリケーションに関するセキュリティ上の問題についてはRFC 8252を参照してください。

アクセス制御

アクセス制御とは、身元や権限を確認するシステムを使用して、ユーザーにリソースを割り当てることを指します。したがって、アクセス制御には、承認、認証、およびログ記録サービスが含まれます。Qt Network Authorization のAPIは、OAuth 2.0認証フレームワークに重点を置いてアクセス制御を実装しています。Qt Network Authorization は、承認コードフロー（PKCE付き）およびデバイス認証フローをサポートしています。

システムにおいて、権限やアクセス許可に応じた意図的な分離は、アクセス制御の第一歩です。ユーザーカテゴリによって、特定のリソースやサービスにアクセスできるグループを決定できます。同様に、リソースやサービスに対するアクセス許可によって、それらに対して実行可能な操作を決定できます。アプリケーションに必要な OAuth スコープのみをリクエストしてください。スコープを制限することで、トークンが漏洩した場合の影響を最小限に抑えることができます。

また、システムは柔軟性と監視のために、アクセス管理を実装する必要があります。セキュリティを損なうことなくユーザーやリソースを容易に追加・削除できるよう、アクセスおよびサービスのプロビジョニングはシステム設計の一部として組み込まなければなりません。アクティビティログは、監査やセキュリティ分析に役立ちます。

よく知られている設計手法として、ロールベースのアクセス制御（RBAC）があります。

認証とシングルサインオン

認証とは、ユーザーの身元を確認することです。脆弱な認証方法では、不適切なユーザーにアクセス権が与えられ、機密データの漏洩や悪意のある行為の実行につながる可能性があります。

接続されたアプリケーションは、制限付きリソースを利用するユーザーの身元を確認する必要があります。通常、アプリケーションは既存のデータベース内のユーザー名やパスワードなどの認証情報を照合することでユーザーを検証します。この方法は、不正な認証やデータ漏洩に対して脆弱です。 多くの対策はユーザーの行動に焦点を当てており、アプリケーションは強力なパスワードの要求といったセキュリティポリシーを強制することができます。アプリケーションは、QtのバリデータやWidgetsを使用して、メッセージによるユーザーへの誘導や、脆弱なパスワードの作成制限を行うことができます。

シングルサインオン（SSO）のような一元化された認証システムを利用することで、パスワードやIDの管理ミスを最小限に抑えることができます。

Qt Network Authorization OAuth 2.0 の上に構築されたアイデンティティ層である OpenID Connect を通じて、JSON Web Tokens (JWT) を取得できます。多くの場合、認証と認可は同一システムの一部を構成しています。アクセストークン、リフレッシュトークン、ID トークンは機密データとして扱ってください。プラットフォームのセキュアストレージや暗号化を利用して、これらを安全に保存してください。トークンを平文で保存してはなりません。

認可とリソースのプロビジョニング

認可とは、ユーザーの権限およびリソースに対するアクセス許可に基づいて、ユーザーがリソースにアクセスできるかどうかを確認することです。適切な認可が行われない場合、ユーザーは許可されていないにもかかわらずリソースにアクセスし、操作を実行できてしまいます。攻撃者はデータを改ざんして完全性を損なったり、リソースを悪用してサービス拒否（DoS）を引き起こしたりする可能性があります。

基本的な予防策として、リソースの悪用につながる可能性のある操作を実行する前に、認可チェックを行ってください。このチェックは、ユーザーがサーバーサイドのリソースにアクセスするたびに実行できます。 ユーザーの権限およびリソースに対するアクセス許可によって、そのユーザーがリソースに対して操作を実行できるかどうかが決まります。リソースによっては、追加の認証チェックが必要になる場合があります。ユーザーがログアウトしたとき、またはアプリケーションがそれらを必要としなくなったときは、アクセストークンおよびリフレッシュトークンを無効化してください。

外部ユーザーエージェントの使用

RFC 8252 によると、アプリケーションはOAuth 2.0 で定義されているように、認証エンドポイントに対して外部ユーザーエージェントまたは埋め込みユーザーエージェントのいずれかを使用できます。埋め込みユーザーエージェントとは、通常、アプリケーション内で提供および制御される WebView を指します。 外部ユーザーエージェントとは、リクエスト元のアプリケーションによって制御されていないシステムブラウザやその他のアプリケーションを指します。

RFC 8252では、認証には組み込みWebビューではなく、外部ユーザーエージェントの使用を推奨しています。 アプリケーションは埋め込みユーザーエージェントを制御するため、アプリケーションと認証ノード間の特権アクセスを分離することができません。この構成は、アプリケーションがキー入力を記録したり、ユーザーに誤った安心感を抱かせたりする可能性があるため、安全ではありません。ただし、外部ユーザーエージェントの使用が現実的でない場合は、Qt WebEngine のように適切に構成された埋め込みブラウザを使用することも可能です。

また、システムブラウザを外部ユーザーエージェントとして使用することで、ブラウザのタブや保存された認証情報により、ユーザーエクスペリエンスを簡素化できます。例えば、ユーザーはブラウザに保存されたユーザー名やパスワードを利用できます。同様に、パスワードマネージャーを外部ユーザーエージェントとして使用することで、利便性と信頼性が向上します。

PKCEとstateパラメータ

Proof Key for Code Exchange（PKCE）は、認証コードフローにおける認証コードの傍受攻撃から保護します。Qt Network Authorization では、PKCEがデフォルトで有効になっています。

Qt Network Authorization は、クロスサイトリクエストフォージェリ（CSRF）攻撃を防ぐため、デフォルトでランダムな状態値を生成します。stateパラメータを上書きする場合は、ハードコーディングされた文字列の使用を避けてください。

プラットフォームに関する考慮事項

リダイレクト URI の処理はプラットフォームによって異なります。モバイルプラットフォームでは、HTTPS リダイレクト URI はアプリが主張する URL を通じて安全に処理できます。デスクトッププラットフォームでは、ローカルホストへの HTTP リダイレクト URI は、ネイティブアプリケーションにとって依然として有効な選択肢です。

接続されたアプリケーション向けのセキュリティリソース

サイバーセキュリティに関するガイダンスのリソースは以下の通りです：

• Common Weakness Enumeration（CWE） - 既知の問題と、その緩和策のリスト。
• OWASP チートシートシリーズ- アプリケーションのセキュリティ確保に関するさまざまなトピックをまとめたリスト。
• RFC 6749- OAuth 2.0 認証フレームワーク
• RFC 8252- ネイティブアプリ向け OAuth 2.0
• RFC 7636- コード交換用証明キー（PKCE）