GitHubのセキュリティに関する21のベストプラクティス
GitHub は、ユーザーとそのコードのセキュリティの保護に非常に積極的に取り組んでいます。多要素認証 (MFA) の使用を推奨または強制することに加えて、不正アクセスや機密情報がパブリック リポジトリに公開されるのを防ぐためのツールも開発および導入しています。その結果、GitHub 関連のセキュリティ インシデントの大部分は、ユーザーのミスによって引き起こされています。この記事では、GitHub を使用する組織が GitHub リポジトリとそこに含まれるコードやデータのセキュリティを確保するために採用できるベスト プラクティスをいくつか紹介します。
GitHub のセキュリティに関するベストプラクティス トップ 21
GitHub のセキュリティに関する 21 のベスト プラクティスは次のとおりです。
#1。認証情報や機密データをGithubに保存しない
GitHub はバージョン管理システムなので、そこに保存されたデータは永久に残ります。git-secrets などのツールを使用すると、機密データを含むコードが GitHub にプッシュされるのをブロックできます。
#2. フォークを無効にする
フォークすると、元のコードベースに影響を与えずに GitHub リポジトリのコピーが作成されます。フォークを無効にして、ソース コードに対する制御を維持し、機密データが不正なフォークによって追加されて公開されないようにします。
#3. 表示設定の変更を無効にする
GitHub はパブリック リポジトリとプライベート リポジトリの両方をサポートしており、特権ユーザーはリポジトリの可視性を変更できます。GitHub のメンバー権限で組織のすべてのメンバーに対して「リポジトリの可視性の変更」を変更する権限を無効にすることで、これを実行できるユーザーのセットを制限します。
#4. GitHub アプリケーションを検証する
組織は、GitHub アカウントにアクセスできるサードパーティの開発者と連携することがよくあります。これらの外部ユーザーのアクセスは制限する必要があり、すべてのコミットはリポジトリに追加する前に検証される必要があります。
#5. 2要素認証を強制する
GitHub では、組織が2 要素認証(2FA) の使用を強制できます。すべてのユーザーに 2FA を要求すると、安全でないアカウントによるコード漏洩や悪意のあるコードのリスクが軽減されます。
#6. SSO を実装する (GitHub Enterprise のみ)
GitHub Enterprise を使用すると、組織はさまざまなリソースに細かく権限を割り当てることができます。さらに、SAMLシングル サインオン(SSO) により、GitHub と組織のIAMソリューションの統合が可能になります。
#7. 許可されたIPアドレスへのアクセスを制限する
IP 許可リストを使用すると、組織はオンプレミスのデバイスまたは企業の VPN へのアクセスを制限できます。これにより、元従業員や不正なデバイスによるリポジトリへのアクセスから保護されます。
#8. 外部貢献者の権限を厳密に管理する
外部貢献者は短期間のみプロジェクトに参加でき、役割が完了したらアクセスを削除する必要があります。外部アカウントを管理すると、セキュリティギャップが軽減され、GitHub の「ユーザーごと」の価格設定が緩和されます。
#9. 適切なタイミングで権限を取り消す
ユーザーは、会社またはプロジェクトを離れた後にリポジトリへのアクセスが必要なくなる場合があります。アクセスを取り消したり、読み取り専用に切り替えたりすると、アカウントに関連するリスクが軽減されます。
#10。コミット署名を要求する
GitHub では、git 設定を変更するだけで、ユーザーの認識された ID を変更できます。コード署名は、コミットに暗号的に署名して、信頼性と追跡可能性を確保します。
#11。コミット前にコードレビューを実施する
コードレビューにより、コミット内の潜在的なセキュリティ上の脆弱性や悪意のある機能を特定できます。GitHub は、すべての送信がプル リクエストになるように構成でき、マージ前にレビューできるようになります。
#12。Security.mdファイルを追加する
security.md ファイルには、リポジトリのセキュリティ ポリシーが正式に文書化されています。これを使用して、セキュリティ要件と脆弱性の報告手段を共有できます。
#13。SSH キーと個人アクセス トークン (PAT) をローテーションする
GitHub は認証にパスワードの代わりに SSH キーと PAT を使用します。侵害された可能性のある資格情報を消去するために、これらを定期的にローテーションする必要があります。
#14。GitHub にアップロードされたすべてのコードを監査する
レガシー コードベースと外部コードベースは、アプリケーションの一部として GitHub リポジトリに追加される場合があります。このコードは、コードベースに受け入れられる前に、潜在的な脆弱性がないか監査される必要があります。
#15。GitHub 監査ログで疑わしいアクティビティを確認する
GitHub は、組織の GitHub 内のアクティビティの強力なログ記録を提供します。これらのログを定期的に確認すると、疑わしい可能性のあるアクティビティや侵害されたアカウントを特定するのに役立ちます。
#16。脆弱な依存関係のアラートを有効にする
アプリケーションは、依存関係、特にサードパーティやオープンソースの依存関係から脆弱性を継承する可能性があります。GitHub は、組織のパブリック リポジトリ内の脆弱性の自動レポート機能を提供します。
#17。事前コミット時に自動シークレットスキャンを採用する
アプリケーションにハードコードされた資格情報は、プライベート リポジトリであっても公開される危険性があります。自動化された秘密スキャンは、これらの資格情報を識別し、コミットされたコードに含まれることをブロックします。
#18。GitHubの履歴を消去する
コードに機密データが含まれている場合、GitHub の広範なバージョン履歴は問題になる可能性があります。履歴は git filter-branch コマンドを使用して書き換えることができます。
#19。Gitブランチ保護を有効にする
Git ブランチ保護は、特定のブランチへの不正な変更を防止します。これにより、これらのブランチを、誤った削除や git squash マージによるコードやデータの損失から保護できます。
#20。機密ファイルを.gitignoreに追加する
ローカル Git リポジトリでは、Git リポジトリにプッシュすべきではない特定の SSK キーとアクセス トークンへのアクセスが必要になる場合があります。これらのファイルを.gitignoreに含めるアップロードされないようにします。
#21。「秘密保管庫」サービスを利用する
シークレット ボールトには、アプリケーションがアクセスする必要がある機密情報 (パスワード、暗号化キーなど) が保存されます。ボールトは、GitHub で利用できるものよりも強力な保護を提供します。
Achieving GitHub Security with Check Point
GitHub リポジトリを使用する組織にとって、リポジトリのセキュリティを確保することは、そこに含まれる可能性のあるコードや機密データを保護するために不可欠です。
For more advice on keeping your GitHub repos safe, check out this more comprehensive list of GitHub security best practices. Check Point offers solutions to secure applications throughout the software development lifecycle (SDLC).
Learn more about how your organization can enhance GitHub security with Check Point Developer Security.
