代わりに GitHub App を使用する
可能な場合、OAuth app の代わりに GitHub App を使用することを検討してください。 通常、GitHub Apps が OAuth apps より優先されます。 GitHub Apps では、きめ細かいアクセス許可が使われ、アプリでアクセスできるリポジトリをより細かく制御でき、有効期間の短いトークンが使われます。 これらの特徴により、アプリの資格情報が漏洩した場合に発生するおそれがある損害を制限することで、アプリのセキュリティを強化できます。
OAuth apps と同様に、GitHub Apps でも引き続き OAuth 2.0 を使って、OAuth トークンの種類 (別名、ユーザー アクセス トークン) を生成し、ユーザーに代わってアクションを実行できます。 ただし、GitHub Apps は、ユーザーとは関係なく動作することもできます。
GitHub Apps について詳しくは、「GitHub App の作成について」をご覧ください。
既存の OAuth app の GitHub App への移行について詳しくは、「OAuth アプリからGitHub Appへの移行」をご覧ください。
最小限のスコープを使用する
OAuth app は、アプリが意図されている機能を実行するために必要なスコープのみを要求する必要があります。 アプリのトークンが侵害された場合、これにより発生するおそれのある損害の量を制限できます。 詳しくは、「OAuth アプリの承認」を参照してください。
アプリの資格情報をセキュリティで保護する
クライアント シークレットを使用すると、アプリでユーザーを承認し、ユーザー アクセス トークンを生成できます。 これらのトークンを使用すると、ユーザーに代わって API 要求を行うことができます。
アプリのクライアント シークレットと生成されたトークンを安全に格納する必要があります。 保存方法は、統合アーキテクチャと稼働するプラットフォームによって異なります。 一般に、使用中のプラットフォームに機密データを保存することを目的とした保存方法を使用する必要があります。
クライアント シークレット
アプリが Web サイトまたは Web アプリの場合は、Azure Key Vault などのキー コンテナーにクライアント シークレットを保存するか、暗号化された環境変数またはサーバー上のシークレットとして保存することを検討してください。
アプリがネイティブ クライアントやクライアント側アプリの場合、またはユーザー デバイスで稼働している (サーバー上で稼働しているのではなく) 場合は、クライアント シークレットをセキュリティ保護することはできません。 誰でもクライアント シークレットにアクセスしてトークンを生成できるため、アプリが生成するトークンに基づいて独自のサービスへのアクセスを制御する場合は注意が必要です。
ユーザー アクセス トークン
アプリが Web サイトや Web アプリの場合は、バックエンドでトークンを暗号化し、トークンにアクセスできるシステムのセキュリティを確保する必要があります。 アクティブなアクセス トークンとは別の場所に更新トークンを保存することを検討してください。
アプリがネイティブ クライアントやクライアント側アプリの場合、またはユーザー デバイスで稼働している (サーバー上で稼働しているのではなく) 場合は、トークンとサーバー上で稼働するアプリをセキュリティ保護できないことがあります。 アプリのプラットフォームに推奨される方法を使用してトークンを保存する必要があり、保存方法が完全に安全ではないことがあることに注意してください。
適切なトークンの種類を使用する
OAuth apps は、認証済みの API 要求を行うためのユーザー アクセス トークンを生成できます。 アプリでは、認証に personal access token または GitHub パスワードを使用しないでください。
セキュリティ侵害を処理するための計画を立てる
セキュリティ侵害をタイムリーに処理できるように、計画を立てる必要があります。
アプリのクライアント シークレットが侵害された場合は、新しいシークレットを生成し、新しいシークレットを使用するようにアプリを更新し、古いシークレットを削除する必要があります。
ユーザー アクセス トークンが侵害された場合は、すぐにトークンを取り消す必要があります。 詳しくは、「OAuth 承認用 REST API エンドポイント」を参照してください。
組織へのユーザー アクセスを検証する
OAuth アプリには、組織外または企業外のユーザーがアクセスできます。 組織または企業のメンバーのみがアプリを使用できるようにする場合は、ユーザーがアプリにサインインするときにユーザーのメンバーシップの状態をチェックする必要があります。
ユーザーがメンバーになっている組織の一覧を見つけるには、「認証済みユーザーの組織を一覧表示する」エンドポイントを使用できます。 その後、アプリに対して承認された組織の一覧に対してこの一覧を検証できます。 詳しくは、「Organization の REST API エンドポイント」を参照してください。
注: マネージド ユーザー アカウント または マネージド ユーザーを含む Organization によって作成された OAuth app にも、企業外のユーザーがアクセスできます。
定期的な脆弱性スキャンを実施する
アプリで定期的な脆弱性スキャンを実行する必要があります。 たとえば、アプリのコードをホストするリポジトリに対して、コード スキャンとシークレット スキャンを設定できます。 詳細については、「コード スキャンについて」および「シークレット スキャンについて」を参照してください。
適切な環境を選択する
アプリがサーバー上で稼働している場合は、サーバー環境がセキュリティ保護され、アプリで予想される量のトラフィックを処理できることを確認します。
安全な方法でサービスを使用する
アプリでサードパーティのサービスを利用する場合は、セキュリティで保護された方法で利用する必要があります。
- アプリで利用するすべてのサービスでは、固有のログイン情報とパスワードを指定する必要があります。
- アプリケーションは、SaaSサービスを管理するためのメールやデータベースサービスのようなサービスアカウントを共有するべきではありません。
- 管理業務を行う従業員のみが、アプリをホストするインフラストラクチャへの管理者アクセス権を持つ必要があります。
ログと監視を追加する
アプリにログ記録と監視機能を追加することを検討してください。 セキュリティ ログには、以下が含まれている場合があります。
- 認証及び認可イベント
- サービス設定の変更
- オブジェクトの読み書き
- ユーザーとグループのアクセス許可の変更
- ロールの管理者への昇格
ログでは、各イベントで一貫したタイムスタンプを使う必要があります。また、ログに記録されたすべてのイベントのユーザー、IP アドレス、ホスト名を記録する必要があります。
データの削除を有効にする
他のユーザーがアプリを利用できる場合は、ユーザーにデータを削除する方法を提供する必要があります。 ユーザーは、自分のデータを削除するために、サポート担当者にメールを送信したり、電話したりする必要はないはずです。