見出し画像

GitHubの新機能Push protectionを試してみた

Dentsu Digital Tech Blog

電通デジタル 事業戦略室 開発部の佐藤です。

コードのバージョン管理システムとしてGitHubを利用する企業も増えるなか、機密情報の漏洩も増加傾向にあります。そこで、GitHubのEnterpriseプランへ加入してセキュリティの強化について試してみました。
※IoT OT Security News「GitHub 調査：不適切なソースコード管理によりパスワードなどの機密情報が漏洩」

EnterpriseプランではSecret scanningというセキュリティ機能に加えて、今年の4月より利用可能になったSecret scanningの機能の一部であるPush protectionという強力なセキュリティ機能が使えるようになります。Secret scanningについてはすでに具体的な記事がいくつかあがっている一方、Push protectionに関してはまだ具体的な記事があがっていなかったため、本記事にてPush protectionに関する検証結果をまとめることとしました。

GitHubを使用されている組織の担当者や開発者向けに、開発における情報漏洩リスクの低減に少しでも寄与できれば幸いです。

Push protectionとは

GitHubに搭載のSecret scanningに含まれるセキュリティ機能の一つです。

Secret scanning自体はリモートリポジトリの履歴全体をスキャンして、GitHubのパートナーが提供するシークレット情報（APIキー、アクセストークン等）を検知してアラートを出す機能です。Secret scanningに加えてPush protectionを利用することで、シークレット情報をリモートリポジトリへpushされる前に防ぐことができます。

例えば、ローカルからGitHub OAuthアクセストークンのようなシークレット情報をcommit履歴に含めてpushしようとした場合、そのpushは防がれます。

今まではpush前チェックをするためのツールを利用しようとすると次のような問題がありましたが、Push protectionによってこれらは解決できます。

  • 端末インストール型のため、利用者個人の設定に依存してしまう。
    →サーバ側で制御するため、利用者全員に共通の設定が適用できる。

  • ツールによってカバー範囲が違うので複数使わないといけない。
    →検知によるカバー範囲が広く、今後も検知パターンが増える可能性があるため、複数のツールを使わなくて済む。

  • ツールの流行り廃りが激しい。
    →GitHub公式のセキュリティ機能であるため、ツールを利用者に追加でインストールする必要がそもそもない。

Push protectionを利用するには

Push protectionはEnterpriseプランへの加入かつGitHub Advanced Securityのライセンスを保有することで利用できます。調査時点（2022/05/06）ではEnterpriseプランの利用では1ユーザーにつき、$21/月が必要です。加えてGitHub Advanced Securityオプション購入には別途料金（詳細はGitHub社への問い合わせが必要）がかかります。

実際に検証してみた

検証のシナリオと期待する結果

対象はもちろんGitHub利用ユーザーです。実運用の中でGitHub利用ユーザーがシークレット情報を故意・過失に関わらずpushすることをシステム制御で防ぎたいので、Push protectionによってシークレット情報をリモートリポジトリにpushすることを実際に防ぐことができるか検証します。

ソースの変更をリモートリポジトリへ反映する方法は次の2通りのやり方があります。

  • ローカルからシークレット情報を履歴に含むブランチをpush

  • GitHubの画面から直接ファイルを編集してcommit

加えてSecret scanningにはサポートされていないシークレットのパターンに対応するために、利用者側で独自に検知したいパターンを定義できるCustom patternsという機能があります。このCustom patternsで定義したシークレット情報をPush protectionで防げるかを含めた3通りを検証していきます。

  • ローカルからCustom patternsで定義したシークレット情報を履歴に含むブランチをpush

検証の用意

  • まずリポジトリにPushするためのファイルを用意します。（例：.envファイル）Push protectionに検知させるために、検証用にダミーのAWSアクセスキーIDとシークレットアクセスキーを用意します。

  • リポジトリあるいはOrganizationのSetting画面のCode security and Analysisメニューにて、Push protectionが有効になっていることを確認します。

ローカルからpush

想定ケース：利用者がシークレット情報をローカルでcommitしてpushしようとした場合

ローカルで偽のシークレット情報をcommitしておきます。
commitしたブランチをローカルからpushしようとすると次のように検知され、pushが防がれました。

画面からcommit

想定フロー：利用者がGitHubのWeb画面上からファイル編集してcommitしようとした場合
 
GitHubの画面からファイルを編集してシークレット情報を入れた状態で、Commit changesを押下します。

このケースでもPush protectionで防ぐことができました。

会社独自のパターンに対応

想定フロー：Custom patternsで定義したシークレット情報をローカルでcommitしてpushしようとした場合

Custom patternsで独自のシークレットパターンを定義しておきます。

定義したパターンに該当する記載含むファイルをcommitして、pushします。

結果として、この検証ではPush protectionによってpushを防ぐことができませんでした。Custom patternsの機能としてアラートは上がるので、アラートを確認してリモートリポジトリから該当のシークレット情報を削除する必要があります。具体的には「commit履歴から該当のファイルを削除、GitHub Supportへの連絡（Pull requestsやキャッシュ削除のため）、認証情報の差し替え」等の対応が必要そうです。


検証によって判明したおまけ

検証を通して以下のことも分かったので記載しておきます。

検証で用意したシークレットについて
今回検証用にダミーのAWSアクセスキーIDとシークレットアクセスキーを用意しましたが、この二つはペアでファイルに記載がないとPush protectionによって検知されずpushが防がれませんでした。そのため、あまりないパターンかもしれませんがAWSアクセスキーIDとシークレットアクセスキーが片方のみ別々のコミット履歴に存在すると、履歴を辿ることでペアが揃います。

Push protectionで防がれたブランチの扱いについて
記事の途中にも記載していますが、push時に最新のファイルにシークレット情報がなくてもcommit履歴にシークレット情報が存在するとpushは防がれます。再度pushするためにはシークレット情報がないブランチから切り直したり、git resetでシークレット情報をcommitした履歴まで削除する必要があります。

Custom patternsに対するPush protectionの有効性について
Push protectionの対象はGitHubが事前に登録したパートナーが提供するパターンのみで、Custom patternの場合はSecret Scanningで検知後に対応が必要になることが分かりました。対応内容については会社独自のパターンに対応の項に記載した通りです。

まとめ

ここまではPush protectionの検証結果を見てきました。組織が大きくなるにつれてGitHubの運用ルールは策定できても、個々人が適切な設定をしているかを逐次確認することは難しいため、システム的に制御できるPush protectionの恩恵は大きそうです。

参考文献

GitHub Advanced Securityのシークレットスキャンで、シークレットトークンの漏えいを事前に防止（GitHub, Inc.）

みんなにも読んでほしいですか？

オススメした記事はフォロワーのタイムラインに表示されます！