GitHub + Copilotを企業で使う場合のセキュリティ対策

はじめに

MS開発部の松坂です。

GitHubは、ソースコード管理に加えて、IssueやPull Requestによる開発プロセスの管理、CI/CD、セキュリティ対策、GitHub CopilotによるAI支援など、ソフトウェア開発に必要なさまざまな機能を提供しています。

一方、企業で利用する場合は、Repositoryのアクセス権限、APIキーやパスワードの管理、依存パッケージの脆弱性、AI利用時のルールなどを適切に設定する必要があります。

本記事では、GitHub FreeとGitHub Copilot Businessを利用する環境を前提に、企業で検討したいセキュリティ対策を紹介します。

GitHubの設定で行う対策

まずは、GitHubの設定によって実施できるセキュリティ対策です。

GitHubには、アカウントやRepositoryのアクセス制御だけでなく、APIキーやパスワードの検出、依存パッケージの脆弱性管理、GitHub Copilotの利用制御など、さまざまなセキュリティ機能が用意されています。

企業で利用する場合は、これらの機能を適切に設定し、GitHub側で可能な限りリスクを低減しておくことが重要です。

2要素認証（2FA）を必須にする

まず設定しておきたいのが、GitHubアカウントの2要素認証（2FA）です。

GitHubアカウントが不正アクセスされると、そのユーザーがアクセスできるRepositoryのソースコードを閲覧されたり、コードを書き換えられたりする可能性があります。

そのため、パスワードだけでアカウントを保護するのではなく、2FAを有効にすることが重要です。

Organizationでは、メンバーや外部コラボレーターに対して2FAを必須にすることもできます。

企業でGitHubを利用するのであれば、単に「2FAを利用してください」と周知するだけではなく、Organization側で2FAを必須化することを検討しましょう。

権限を適切に管理する

Repositoryのアクセス権限は、業務上必要なユーザーに、必要な範囲で付与します。

Repositoryには、Read、Triage、Write、Maintain、Adminなどの権限レベルがあります。例えば、ソースコードを閲覧するだけのユーザーにAdmin権限を付与する必要はありません。

また、個人単位ではなくTeam単位で権限を管理すると、ユーザーの異動時にもTeamの所属を変更するだけで対応できます。

Secret Scanningを利用する

Secret Scanningは、Repositoryに誤って登録されたAPIキーやパスワードなどのシークレットを検出する機能です。

APIキーやパスワードはRepositoryに登録せず、Azure Key VaultやGitHub Secretsなどで安全に管理します。

Dependabotを利用する

Dependabotは、利用している依存パッケージに脆弱性がないかを確認する機能です。

脆弱性を検出するとアラートを発生させるほか、修正版へ更新するPull Requestを自動的に作成することもできます。

OSSを多く利用する開発環境では、脆弱性の発見から修正までを効率化するために活用しましょう。

Copilotのポリシーを管理する

GitHub Copilotを企業で利用する場合は、Organization側で利用者、利用可能な機能、公開コードとの一致・類似に関するポリシーなどを設定します。

また、機密性の高いファイルやRepositoryをCopilotの参照対象から除外するContent Exclusionも設定できます。

Copilotを利用できるようにするだけでなく、誰に、どの機能を、どの情報に対して利用させるのかを決めておくことが重要です。

監査ログ・Copilotの利用状況を確認する

監査ログを確認する

GitHubでは、Organizationで行われた操作を監査ログ（Audit log）から確認できます。

Repositoryやメンバーに対する操作、設定変更などを確認しましょう。

Copilotの利用状況を確認する

Copilotについても、利用状況を定期的に確認することが重要です。

誰がCopilotを利用しているのかを確認することで、ライセンスの適切な管理につながります。

AI Creditsとコストを管理する

Copilotでは、利用するモデルや機能によってAI Creditsの消費量が異なります。

そのため、Copilotを導入した後は、セキュリティだけでなく、コスト面も含めて利用状況を管理する必要があります。

特に高性能なモデルやAgentなどを利用する場合は、利用量が増える可能性もあるため、想定外のコストが発生していないか確認しておくとよいでしょう。

社内ルールとして定める対策

ここまで紹介したものは、GitHub側の設定によって対応できるセキュリティ対策です。

しかし、GitHubの機能だけですべてのリスクを防ぐことはできません。

例えば、GitHubにAPIキーを登録しないという基本的なルールや、Copilotへ機密情報を入力しないといった行動は、最終的には開発者一人ひとりの判断に委ねられます。

そのため、GitHubの設定と合わせて、開発者向けの利用ルールを定め、社内へ周知することが重要です。

GitHub Copilotの利用ルールを定める

機密情報をCopilotへ入力しない

Copilotを利用する際には、APIキーやパスワードだけでなく、顧客情報や個人情報、社外秘の業務情報などをプロンプトへ入力しないことをルールとして定めます。

「コードを質問するだけだから問題ない」と考えず、AIへ入力する情報も企業の情報資産として扱うことが重要です。

生成されたコードをそのまま利用しない

Copilotが生成したコードには、正確性やライセンス上の問題が含まれる可能性があります。内容を確認し、テストとコードレビューを行ったうえで利用しましょう。特に、認証、認可、暗号化、SQL、ファイルアクセス、外部API通信などに関するコードは、重点的に確認する必要があります。

Repositoryの管理ルールを定める

不要なRepositoryを作成しない

Organization内にRepositoryが増えすぎると、「どのRepositoryが現在利用されているのか」「誰が管理しているのか」が分からなくなります。

そのため、Repositoryを作成する際のルールを決めておくことも重要です。

例えば、次のようなルールを定めます。

• Repositoryの用途を明確にする
• 管理者を決める
• 不要になったRepositoryは整理する
• 命名規則を統一する

外部ユーザーへのアクセスに注意する

外部コラボレーターなど、Organization外のユーザーにRepositoryへのアクセス権を付与する場合には、特に注意が必要です。

外部ユーザーにアクセスを許可する必要性や期間を確認し、作業終了後には不要なアクセス権を削除するようにします。

まとめ

GitHubを企業で利用する場合、単純にRepositoryにソースコードを保存するだけではなく、アカウント、アクセス権限、APIキーやパスワード、依存パッケージ、AI利用など、複数の観点からセキュリティ対策を考える必要があります。

特に重要なのは、GitHub上で設定できる対策と、社内ルールとして周知する対策を分けて考えることです。

GitHub上では、2FA、Repositoryの権限管理、Secret Scanning、Dependabot、Copilot Businessのポリシー、監査ログなどを活用します。

一方、社内では、APIキーやパスワードをRepositoryに保存しない、機密情報をCopilotへ入力しない、生成されたコードをそのまま利用しない、といったルールを定めます。

GitHubの機能と開発者の運用ルールを組み合わせることで、「GitHubを安全に使うための仕組み」と「安全に使うためのルール」の両方を整備できます。

GitHubやGitHub Copilotを企業の開発環境として利用するのであれば、機能を導入するだけで終わらせず、技術面と運用面の両方からセキュリティを考えることが重要です。