GitHub Actions 認証情報リスクと権限昇格対策

GitHub ActionsはCI/CDの強力なツールですが、認証情報の扱い方を誤ると深刻なセキュリティリスクにつながります。開発現場では、トークンやシークレットの漏洩が権限昇格の入り口になるケースが少なくありません。ここでは、実際のリスクパターンと実践的な対策を整理します。

📑目次

GitHub Actionsにおける認証情報リスクの概要
OIDCを活用した短期認証のメリットと導入手順
permissionsキーで実現する最小権限の設定方法
Secretsの安全な管理とログ漏洩防止策
Self-hosted runnerが抱える特有のリスク
権限昇格パターンの具体例と攻撃シナリオ
実践的な対策チェックリストと比較表
よくある質問（FAQ）
まとめ

GitHub Actionsにおける認証情報リスクの概要

GitHub Actionsでは、さまざまな認証情報が利用されます。代表的なものはPersonal Access Token (PAT)、GitHub Appのインストールトークン、OIDC経由のクラウド認証情報です。これらのうち、PATは有効期限が長く、権限範囲が広いため漏洩時の影響が大きい傾向があります。一方、OIDCは一時的なトークンを発行するため、漏洩リスクを大幅に低減できます。

実際のインシデントでは、PATがリポジトリにハードコードされたまま公開され、攻撃者に悪用される事例が報告されています。こうしたリスクを正しく理解することが、第一歩です。

OIDCを活用した短期認証のメリットと導入手順

OIDC (OpenID Connect) を利用すると、GitHub Actionsからクラウドプロバイダー (AWS、GCP、Azure) へ一時的な認証情報を取得できます。長期的なクレデンシャルを保存する必要がなく、権限昇格の機会を減らせます。

導入手順は以下の通りです。まず、クラウド側でOIDCプロバイダーを設定し、GitHubリポジトリを信頼できる発行元として登録します。次に、ワークフローファイルで permissions を明示的に指定し、必要な権限のみを付与します。最後に、 id-token: write を有効にしてトークンを取得します。

この方法により、シークレット管理の手間が減り、セキュリティが向上します。

permissionsキーで実現する最小権限の設定方法

GitHub Actionsのワークフローファイルでは、トップレベルまたはジョブレベルで permissions を設定できます。デフォルトはリポジトリの権限を継承しますが、明示的に最小限に絞ることでリスクを抑えられます。

例えば、コンテンツの読み取りのみが必要な場合、以下のように記述します。

permissions:
  contents: read

書き込み権限が必要な場面でも、pull-requests や issues など特定のリソースに限定することが推奨されます。これにより、万一トークンが漏洩しても被害範囲を限定できます。

Secretsの安全な管理とログ漏洩防止策

SecretsはGitHubの暗号化ストレージに保存されますが、ワークフロー内で誤ってログに出力すると漏洩します。 echo コマンドやデバッグログでシークレットが露出するケースが典型的です。

対策として、Secretsを扱うステップでは set +x を使用してコマンド出力を抑制し、ログにマスクされるよう ::add-mask:: コマンドを活用します。また、Secretsは必要最小限のスコープで作成し、定期的にローテーションを行うことが重要です。

Self-hosted runnerが抱える特有のリスク

Self-hosted runnerはオンプレミスや自社サーバーで実行されるため、GitHubの管理外となります。runnerがマルウェアに感染したり、ホストマシンのファイルシステムにアクセスされたりするリスクがあります。

GitHubホストのランナーと異なり、ネットワーク隔離やOSレベルのセキュリティパッチ適用が運用者の責任になります。機密性の高い作業では、ephemeral runnerの利用や、runnerのネットワークを制限した運用を検討してください。

権限昇格パターンの具体例と攻撃シナリオ

典型的な攻撃シナリオは、漏洩したPATを使ってリポジトリのコードを改ざんし、CI/CDパイプラインを通じて本番環境へ侵入するものです。あるいは、Actionsのログから一時トークンを取得し、クラウドリソースを操作するケースもあります。

こうしたシナリオを防ぐには、トークンのスコープを厳格にし、定期的な監査を行うことが有効です。

実践的な対策チェックリストと比較表

以下は主な認証方法の比較表です。

認証方法	有効期限	権限範囲	漏洩時の影響	おすすめ度
PAT	長期間	広い	大	低
OIDC	短期	最小限	小	高
GitHub App	中期間	限定	中	中
Self-hosted	運用依存	広範	大	条件付き

出典: GitHub公式ドキュメントおよびセキュリティガイドライン (2026年時点)

この表を参考に、自社のワークフローに合った方法を選択してください。

よくある質問（FAQ）

Q: OIDCの設定が複雑そうですが、初心者でも導入できますか？

クラウドプロバイダーの公式ガイドに従えば、30分程度で基本設定が完了します。テンプレートも公開されています。

Q: permissionsを設定しても、なぜリスクが残るのですか？

設定を忘れたジョブや、継承された権限が原因になることがあります。リポジトリ全体でスキャンを行い、明示的に設定しているか確認してください。

Q: Secretsのログ漏洩を完全に防ぐ方法はありますか？

完全な防止は難しいですが、マスク設定とレビュー文化の徹底で大幅に低減できます。

Q: Self-hosted runnerは使わない方が安全ですか？

ユースケースによります。GitHubホストで十分な場合はそちらを優先し、必要に応じて厳格な運用ポリシーを設けましょう。

Q: 既存のワークフローを修正する優先順位は？

まずPATをOIDCへ移行し、次にpermissionsの見直し、Secretsの扱い方を改善する順が効果的です。

関連記事:

まとめ

GitHub Actionsのセキュリティは、認証情報の選択と権限管理が鍵となります。OIDCの導入やpermissionsの最小化により、権限昇格のリスクを大幅に下げることが可能です。まずは自社のワークフローを棚卸しし、表の比較を参考に改善を進めてください。定期的な見直しを習慣にすることで、安全なCI/CD環境を維持できます。

関連する新しい記事:

FeliCa 脆弱性公表の背景と実務的な影響 – This published update adds current operational context for GitHub Actions 認証情報リスクと権限昇格対策 | 実践ガイド.

著者

krona23

IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。

DevGENT について →

📚 次に読む