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

このページでは、Qt Network 認証を使用するアプリケーションのセキュリティに関する考察を扱います。ここでの内容の多くは、OAuth 2.0 Authorization FrameworkとOpenIDに焦点を当てています。

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

アクセス・コントロール

アクセス・コントロールは、アイデンティティとアクセス許可をチェックするシステムを使用して、ユーザーにリソースをプロビジョニングすることです。アクセス・コントロールには、認可、認証、ロギング・サービスが含まれます。 Qt Network 認可のAPIは、OAuth 2.0認可フレームワークに焦点を当ててアクセス制御を実装します。 Qt Network 認可は、認可コード・フロー（PKCEを使用）とデバイス認可フローをサポートします。

システムにとって、権限とパーミッションに従って意図的に分離することは、アクセス制御の最初のステップです。ユーザー・カテゴリは、特定のリソースやサービスにアクセスできるグループを指定することができます。同様に、リソースやサービスに対するパーミッションは、それらに対して利用可能なアクションを規定することができます。アプリケーションが必要とするOAuthスコープのみをリクエストしてください。スコープを限定することで、トークンが漏洩した場合の潜在的な影響を減らすことができます。

システムはまた、柔軟性と監視のためにアクセス管理を実装する必要があります。セキュリティを損なうことなく、ユーザーやリソースの追加や削除が簡単にできるように、アクセスやサービスのプロビジョニングはシステム設計の一部でなければなりません。活動ログは、監査とセキュリティ分析を支援する。

よく知られた設計は、役割ベースのアクセス制御（RBAC）である。

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

認証とは、ユーザーの身元を確認することである。認証方法が弱いと、誤ったユーザーにアクセスを許可することになり、個人データの漏洩や悪意のある行為の実行につながる可能性がある。

接続されたアプリケーションは、制限されたリソースを使用するユーザーの身元を確認する必要があります。通常、アプリケーションは、既存のデータベースにあるユーザ名やパスワードなどのユーザ認証情報を確認することで、ユーザを検証します。この方法は、誤認証やデータ漏洩に対して脆弱です。多くの緩和テクニックはユーザーの振る舞いに関するものであり、アプリケーションは強力なパスワードを要求するなどのセキュリティポリシーを強制することができます。アプリケーションは Qt のバリデータとウィジェットを使って、メッセージや弱いパスワードの作成を制限することで、ユーザーを誘導することができます。

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

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

認証とリソースの提供

認可とは、リソース上のユーザー権限とパーミッションに基づいて、ユーザーがリソースにアクセスできるかどうかをチェックすることです。適切な認可がなければ、ユーザーは権限がないにもかかわらずリソースにアクセスし、アクションを実行することができます。攻撃者はデータを改ざんして完全性を低下させたり、リソースを悪用したりして、サービス拒否を引き起こす可能性がある。

基本的な予防措置として、リソースの悪用につながる可能性のあるアクションを実行する前に、権限チェックを行う。このチェックは、ユーザがサーバ側のリソースにアクセスするたびに行われます。ユーザーの権限とリソースのパーミッションによって、ユーザーがリソース上でアクションを実行できるかどうかが決まります。リソースによっては、追加の権限チェックが必要な場合もあります。ユーザがログアウトしたときや、アプリケーションがトークンを必要としなくなったときに、アクセス・トークンやリフレッシュ・トークンを失効させます。

外部ユーザーエージェントを使用する

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

RFC8252では、認可のために埋め込みウェブビューではなく、外部ユーザエージェントを使用することを推奨しています。アプリケーションは埋め込みユーザエージェントを制御し、アプリケーションと認可ノード間の特権アクセスを分離することに失敗する。この設定は、アプリケーションがキー入力を記録することができ、ユーザを偽の安心感で騙すことができるので、安全ではありません。しかし、QtWebEngine のような適切に設定された組み込みブラウザは、外部ユーザエージェントが実用的でない場合にも使用できます。

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

PKCEとステート・パラメーター

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

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

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

リダイレクトURIの扱いはプラットフォームによって異なります。モバイルプラットフォームでは、HTTPSのリダイレクトURIはアプリが要求するURLで安全に処理できます。デスクトップ・プラットフォームでは、ローカルホストへのHTTPリダイレクトURIは、ネイティブ・アプリケーションの有効なオプションのままです。

接続アプリケーションのセキュリティ・リソース

サイバーセキュリティに関するガイダンスのリソースを以下に示します：

• Common Weakness Enumeration- 既知の問題と可能な緩和手法のカタログ。
• OWASP Cheat Sheet Series- アプリケーションのセキュリティに関する様々なトピックのリスト。
• RFC 6749- OAuth 2.0 認証フレームワーク
• RFC 8252- ネイティブアプリのための OAuth 2.0
• RFC 7636- コード交換のための証明鍵（PKCE）