代わりに 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 アプリの承認」を参照してください。
徹底的かつ永続的な承認
ユーザーにサインインした後、アプリ開発者は追加の手順を実行して、ユーザーがシステム内のデータにアクセスできるようにする必要があります。 各サインインには、メンバーシップ、アクセス、現在の SSO 状態に関する新しいチェックが必要です。
永続的で一意の id を使用してユーザーを格納する
ユーザーがサインインしてアプリケーションでアクションを実行するときは、次回サインインしたときに同じリソースへのアクセス権を付与するために、どのユーザーがそのアクションを実行したかを覚えておく必要があります。
ユーザーをデータベースに正しく格納するには、常にユーザーの id を使用します。 この値は、ユーザーに対して変更されることも、別のユーザーを指し示すために使用されることもないため、意図したユーザーへのアクセスを確実に提供できます。 ユーザーの id を GET /user REST API エンドポイントで確認できます。 「ユーザーの REST API エンドポイント」をご覧ください。
リポジトリ、組織、および企業へのリファレンスを格納する場合は、それらの id を使用して、リンクが正確であることを確認します。
ユーザー ハンドル、組織の置換フィールド、メール アドレスなど、時間の経過に伴い変化する可能性のある識別子を 絶対に 使用しないでください。
新しい認証ごとに組織へのアクセスを検証する
ユーザー アクセス トークンを使用する場合は、トークンが承認されている組織を追跡する必要があります。 組織が SAML SSO を使用していて、ユーザーが SAML SSO を実行していない場合、ユーザー アクセス トークンはその組織にアクセスできません。 REST API エンドポイントを GET /user/installations 使用して、ユーザー アクセス トークンがアクセスできる組織を確認できます。 ユーザーが組織へのアクセスを許可されていない場合は、SAML SSO を実行するまで、独自のアプリケーション内の組織所有データへのアクセスを防止する必要があります。 詳しくは、「GitHub Appインストール用 REST API エンドポイント」を参照してください。
organization コンテキストと Enterprise コンテキストを使用してユーザー データを格納する
id フィールドを使用してユーザー ID を追跡するだけでなく、各ユーザーが操作している組織または企業のデータを保持する必要があります。 これにより、ユーザーがロールを切り替えた場合に、機密情報が漏えいしないようにすることができます。
次に例を示します。
- ユーザーは、SAML SSO を必要とする
Mona組織にいて、SSO の実行後にアプリにサインインします。 これで、アプリはユーザーがMona内で行うあらゆるものにアクセスできるようになりました。 - ユーザーは、
Mona内のリポジトリから多数のコードを抜き取り、分析するためにアプリに保存します。 - その後、ユーザーはジョブを切り替え、
Mona組織から削除されます。
ユーザーがアプリにアクセスしても、ユーザー アカウントに Mona 組織のコードと分析をまだ表示できますか?
このため、アプリが保存しているデータのソースを追跡することが重要です。 それ以外の場合、アプリは組織のデータ保護にとって脅威であり、アプリがデータを正しく保護しているか信頼できない場合は、そのアプリを禁止する可能性があります。
アプリへのユーザー アクセスを検証する
OAuth アプリには、組織外または企業外のユーザーがアクセスできます。 組織または企業のメンバーのみがアプリを使用できるようにする場合は、ユーザーがアプリにサインインするときにユーザーのメンバーシップの状態をチェックする必要があります。
ユーザーがメンバーになっている組織の一覧を見つけるには、「認証済みユーザーの組織を一覧表示する」エンドポイントを使用できます。 その後、アプリに対して承認された組織の一覧に対してこの一覧を検証できます。 詳しくは、「Organization の REST API エンドポイント」を参照してください。
アプリの資格情報をセキュリティで保護する
クライアント シークレットを使用すると、アプリでユーザーを承認し、ユーザー アクセス トークンを生成できます。 これらのトークンを使用すると、ユーザーに代わって API 要求を行うことができます。
アプリのクライアント シークレットと生成されたトークンを安全に格納する必要があります。 保存方法は、統合アーキテクチャと稼働するプラットフォームによって異なります。 一般に、使用中のプラットフォームに機密データを保存することを目的とした保存方法を使用する必要があります。
クライアント シークレット
アプリが Web サイトまたは Web アプリの場合は、Azure Key Vault などのキー コンテナーにクライアント シークレットを保存するか、暗号化された環境変数またはサーバー上のシークレットとして保存することを検討してください。
アプリがネイティブ クライアントやクライアント側アプリの場合、またはユーザー デバイスで稼働している (サーバー上で稼働しているのではなく) 場合は、クライアント シークレットをセキュリティ保護することはできません。 誰でもクライアント シークレットにアクセスしてトークンを生成できるため、アプリが生成するトークンに基づいて独自のサービスへのアクセスを制御する場合は注意が必要です。
ユーザー アクセス トークン
アプリが Web サイトや Web アプリの場合は、バックエンドでトークンを暗号化し、トークンにアクセスできるシステムのセキュリティを確保する必要があります。 アクティブなアクセス トークンとは別の場所に更新トークンを保存することを検討してください。
アプリがネイティブ クライアントやクライアント側アプリの場合、またはユーザー デバイスで稼働している (サーバー上で稼働しているのではなく) 場合は、トークンとサーバー上で稼働するアプリをセキュリティ保護できないことがあります。 アプリのプラットフォームに推奨される方法を使用してトークンを保存する必要があり、保存方法が完全に安全ではないことがあることに注意してください。
適切なトークンの種類を使用する
OAuth apps は、認証済みの API 要求を行うためのユーザー アクセス トークンを生成できます。 アプリでは、認証に personal access token または GitHub パスワードを使用しないでください。
セキュリティ侵害を処理するための計画を立てる
セキュリティ侵害をタイムリーに処理できるように、計画を立てる必要があります。
アプリのクライアント シークレットが侵害された場合は、新しいシークレットを生成し、新しいシークレットを使用するようにアプリを更新し、古いシークレットを削除する必要があります。
ユーザー アクセス トークンが侵害された場合は、すぐにトークンを取り消す必要があります。 詳しくは、「OAuth 承認用 REST API エンドポイント」を参照してください。
定期的な脆弱性スキャンを実施する
アプリで定期的な脆弱性スキャンを実行する必要があります。 たとえば、アプリのコードをホストするリポジトリに対して、コード スキャンとシークレット スキャンを設定できます。 詳細については、「コード スキャンについて」および「シークレット スキャンについて」を参照してください。
適切な環境を選択する
アプリがサーバー上で稼働している場合は、サーバー環境がセキュリティ保護され、アプリで予想される量のトラフィックを処理できることを確認します。
安全な方法でサービスを使用する
アプリでサードパーティのサービスを利用する場合は、セキュリティで保護された方法で利用する必要があります。
- アプリで利用するすべてのサービスでは、固有のログイン情報とパスワードを指定する必要があります。
- アプリケーションは、SaaSサービスを管理するためのメールやデータベースサービスのようなサービスアカウントを共有するべきではありません。
- 管理業務を行う従業員のみが、アプリをホストするインフラストラクチャへの管理者アクセス権を持つ必要があります。
ログと監視を追加する
アプリにログ記録と監視機能を追加することを検討してください。 セキュリティ ログには、以下が含まれている場合があります。
- 認証及び認可イベント
- サービス設定の変更
- オブジェクトの読み書き
- ユーザーとグループのアクセス許可の変更
- ロールの管理者への昇格
ログでは、各イベントで一貫したタイムスタンプを使う必要があります。また、ログに記録されたすべてのイベントのユーザー、IP アドレス、ホスト名を記録する必要があります。
データの削除を有効にする
他のユーザーがアプリを利用できる場合は、ユーザーにデータを削除する方法を提供する必要があります。 ユーザーは、自分のデータを削除するために、サポート担当者にメールを送信したり、電話したりする必要はないはずです。