基本的なGithub情報

Reading time: 27 minutes

基本構造

大規模な企業の基本的なGithub環境構造は、エンタープライズを所有し、そのエンタープライズがいくつかの組織を所有し、それぞれがいくつかのリポジトリといくつかのチームを含むことです。小規模な企業は、1つの組織とエンタープライズを持たない場合があります。

ユーザーの観点から見ると、ユーザーは異なるエンタープライズや組織のメンバーであることができます。それらの中で、ユーザーは異なるエンタープライズ、組織、リポジトリの役割を持つことがあります。

さらに、ユーザーは異なるチームの一員であり、異なるエンタープライズ、組織、またはリポジトリの役割を持つことがあります。

最後に、リポジトリには特別な保護メカニズムがある場合があります。

権限

エンタープライズの役割

• エンタープライズオーナー: この役割を持つ人々は、管理者を管理し、エンタープライズ内の組織を管理し、エンタープライズ設定を管理し、組織全体にポリシーを強制することができます。ただし、彼らは組織の設定やコンテンツにアクセスすることはできません。組織のオーナーに任命されるか、組織所有のリポジトリへの直接アクセスが与えられない限り。
• エンタープライズメンバー: あなたのエンタープライズが所有する組織のメンバーは、自動的にエンタープライズのメンバーでもあります。

組織の役割

組織内でユーザーは異なる役割を持つことができます：

• 組織オーナー: 組織オーナーは、組織に対する完全な管理アクセス権を持っています。この役割は制限されるべきですが、組織内で2人以上の人に制限する必要があります。
• 組織メンバー: デフォルトの非管理者役割は組織メンバーです。デフォルトでは、組織メンバーはいくつかの権限を持っています。
• 請求管理者: 請求管理者は、組織の請求設定を管理できるユーザーです。たとえば、支払い情報などです。
• セキュリティマネージャー: 組織オーナーが組織内の任意のチームに割り当てることができる役割です。適用されると、チームのすべてのメンバーに組織全体のセキュリティアラートや設定を管理する権限、ならびに組織内のすべてのリポジトリに対する読み取り権限が与えられます。
• 組織にセキュリティチームがある場合、セキュリティマネージャー役割を使用して、チームのメンバーに組織に必要な最小限のアクセスを与えることができます。
• Githubアプリ管理者: 組織が所有するGitHubアプリを管理するために、オーナーはGitHubアプリ管理者権限を付与できます。
• 外部コラボレーター: 外部コラボレーターは、1つ以上の組織リポジトリにアクセスできるが、明示的に組織のメンバーではない人です。

これらの役割の権限を比較することができます。この表で: https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles

メンバーの権限

https://github.com/organizations/<org_name>/settings/member_privileges で、組織の一部であることによってユーザーが持つ権限を確認できます。

ここで設定された内容は、組織のメンバーの以下の権限を示します：

• 組織のすべてのリポジトリに対して管理者、ライター、リーダー、または権限なしであること。
• メンバーがプライベート、内部、またはパブリックリポジトリを作成できるかどうか。
• リポジトリのフォークが可能かどうか。
• 外部コラボレーターを招待できるかどうか。
• 公開またはプライベートサイトを公開できるかどうか。
• 管理者がリポジトリに対して持つ権限。
• メンバーが新しいチームを作成できるかどうか。

リポジトリの役割

デフォルトでは、リポジトリの役割が作成されます：

• 読み取り: コードに貢献しない人々がプロジェクトを表示または議論するために推奨されます。
• トリアージ: 書き込みアクセスなしで問題やプルリクエストを積極的に管理する必要がある貢献者に推奨されます。
• 書き込み: プロジェクトに積極的にプッシュする貢献者に推奨されます。
• メンテナンス: リポジトリを管理する必要があるプロジェクトマネージャーに推奨されますが、機密または破壊的なアクションへのアクセスはありません。
• 管理者: プロジェクトに完全にアクセスする必要がある人々に推奨されます。これには、セキュリティの管理やリポジトリの削除などの機密かつ破壊的なアクションが含まれます。

各役割の権限を比較することができます。この表で https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role

また、https://github.com/organizations/<org_name>/settings/roles で独自の役割を作成することもできます。

チーム

https://github.com/orgs/<org_name>/teams で、組織内に作成されたチームをリストできます。他のチームの子チームを表示するには、各親チームにアクセスする必要があります。

ユーザー

組織のユーザーは、https://github.com/orgs/<org_name>/people でリストできます。

各ユーザーの情報には、ユーザーがメンバーであるチームや、ユーザーがアクセスできるリポジトリが表示されます。

Github認証

Githubは、アカウントに認証し、あなたの代わりにアクションを実行するためのさまざまな方法を提供しています。

ウェブアクセス

github.comにアクセスすると、ユーザー名とパスワード（および2FAが必要な場合があります）を使用してログインできます。

SSHキー

1つまたは複数の公開鍵でアカウントを構成でき、関連する秘密鍵があなたの代わりにアクションを実行できるようにします。https://github.com/settings/keys

GPGキー

これらのキーでユーザーを偽装することはできませんが、使用しない場合、署名なしでコミットを送信することで発見される可能性があります。詳細については、ここで警戒モードについて学んでください。

個人アクセストークン

アプリケーションにアカウントへのアクセスを与えるために個人アクセストークンを生成できます。個人アクセストークンを作成する際、ユーザーはトークンが持つ権限を指定する必要があります。https://github.com/settings/tokens

Oauthアプリケーション

Oauthアプリケーションは、あなたのGithub情報の一部にアクセスするための権限を要求したり、あなたを偽装していくつかのアクションを実行したりすることがあります。この機能の一般的な例は、いくつかのプラットフォームで見られるGithubでログインボタンです。

• https://github.com/settings/developers で独自のOauthアプリケーションを作成できます。
• https://github.com/settings/applications で、あなたのアカウントにアクセス権を持つすべてのOauthアプリケーションを確認できます。
• https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps で、Oauthアプリが要求できるスコープを確認できます。
• https://github.com/organizations/<org_name>/settings/oauth_application_policy で、組織内のアプリケーションのサードパーティアクセスを確認できます。

いくつかのセキュリティ推奨事項：

• OAuthアプリは常にGitHub全体で認証されたGitHubユーザーとして行動するべきです（たとえば、ユーザー通知を提供する場合）し、指定されたスコープにのみアクセスします。
• OAuthアプリは、認証されたユーザーのために「GitHubでログイン」を有効にすることで、アイデンティティプロバイダーとして使用できます。
• 単一のリポジトリでアクションを実行するアプリケーションを作成したい場合は、OAuthアプリを構築しないでください。repo OAuthスコープを使用すると、OAuthアプリは認証されたユーザーのすべてのリポジトリに対してアクションを実行できます。
• チームや会社のためのアプリケーションとして機能するためにOAuthアプリを構築しないでください。OAuthアプリは単一のユーザーとして認証されるため、1人が会社のためにOAuthアプリを作成し、その後会社を離れた場合、他の誰もそれにアクセスできなくなります。
• 詳細はこちらで。

Githubアプリケーション

Githubアプリケーションは、あなたのGithub情報にアクセスしたり、あなたを偽装して特定のリソースに対して特定のアクションを実行したりするための権限を要求できます。Githubアプリでは、アプリがアクセスできるリポジトリを指定する必要があります。

• GitHubアプリをインストールするには、組織のオーナーまたはリポジトリの管理者権限を持っている必要があります。
• GitHubアプリは個人アカウントまたは組織に接続する必要があります。
• https://github.com/settings/apps で独自のGithubアプリケーションを作成できます。
• https://github.com/settings/apps/authorizations で、あなたのアカウントにアクセス権を持つすべてのGithubアプリケーションを確認できます。
• これらはGithubアプリケーションのAPIエンドポイントです https://docs.github.com/en/rest/overview/endpoints-available-for-github-app。アプリの権限に応じて、いくつかのエンドポイントにアクセスできるようになります。
• https://github.com/organizations/<org_name>/settings/installations で、組織内のインストールされたアプリを確認できます。

いくつかのセキュリティ推奨事項：

• GitHubアプリはユーザーとは独立してアクションを実行するべきです（アプリがuser-to-serverトークンを使用している場合を除く）。ユーザーからサーバーへのアクセストークンをより安全に保つために、8時間後に期限切れになるアクセストークンと、新しいアクセストークンと交換できるリフレッシュトークンを使用できます。詳細については、「ユーザーからサーバーへのアクセス トークンの更新」を参照してください。
• GitHubアプリが特定のリポジトリと統合されていることを確認してください。
• GitHubアプリは個人アカウントまたは組織に接続する必要があります。
• GitHubアプリがユーザーができるすべてのことを知って行動することを期待しないでください。
• 「GitHubでログイン」サービスが必要なだけの場合は、GitHubアプリを使用しないでください。ただし、GitHubアプリは、ユーザーをログインさせるためにuser identification flowを使用して、ユーザーをログインさせることができます_そして_他のことを行うことができます。
• GitHubユーザーとしてのみ行動し、そのユーザーができるすべてのことを行いたい場合は、GitHubアプリを構築しないでください。
• GitHub Actionsを使用してアプリを使用し、ワークフローファイルを変更したい場合は、workflowスコープを含むOAuthトークンを使用してユーザーの代わりに認証する必要があります。ユーザーは、ワークフローファイルを含むリポジトリに対して管理者または書き込み権限を持っている必要があります。詳細については、「OAuthアプリのスコープの理解」を参照してください。
• 詳細はこちらで。

Github Actions

これはgithubで認証する方法ではありませんが、悪意のあるGithub Actionがgithubに不正アクセスする可能性があり、与えられた権限に応じて、いくつかの異なる攻撃が行われる可能性があります。詳細については以下を参照してください。

Gitアクション

Gitアクションは、イベントが発生したときにコードの実行を自動化することを可能にします。通常、実行されるコードはリポジトリのコードに関連している（おそらくDockerコンテナをビルドするか、PRに秘密が含まれていないかを確認するなど）。

設定

https://github.com/organizations/<org_name>/settings/actions で、組織のGithubアクションの設定を確認できます。

Githubアクションの使用を完全に禁止することも、すべてのGithubアクションを許可することも、特定のアクションのみを許可することもできます。

また、Github Actionを実行するために承認が必要な人や、Github Actionが実行されるときのGITHUB_TOKENの権限を設定することもできます。

Git Secrets

Github Actionは通常、Githubやサードパーティアプリケーションと対話するために何らかの秘密を必要とします。リポジトリに平文で置かないようにするために、GithubはそれらをSecretsとして配置することを許可します。

これらの秘密は、リポジトリまたは組織全体のために設定できます。その後、Actionが秘密にアクセスできるようにするために、次のように宣言する必要があります：

steps:
- name: Hello world action
with: # Set the secret as an input
super_secret:${{ secrets.SuperSecret }}
env: # Or as an environment variable
super_secret:${{ secrets.SuperSecret }}

Bashを使用した例

steps:
- shell: bash
env: SUPER_SECRET:${{ secrets.SuperSecret }}
run: |
example-command "$SUPER_SECRET"

リポジトリまたは組織に設定されると、github のユーザーは再度アクセスできなくなります。彼らはただ 変更することができる だけです。

したがって、github シークレットを盗む唯一の方法は、Github Action を実行しているマシンにアクセスできることです（そのシナリオでは、Action に対して宣言されたシークレットのみアクセス可能になります）。

Git Environments

Github は 環境 を作成することを許可しており、そこに シークレット を保存できます。次に、環境内のシークレットへのアクセスを github action に与えることができます。

jobs:
deployment:
runs-on: ubuntu-latest
environment: env_name

環境をすべてのブランチ（デフォルト）、保護されたブランチのみ、またはアクセスできるブランチを指定するように構成できます。
また、環境を使用してアクションを実行する前に必要なレビューの数を設定したり、デプロイメントが進行する前に一定の時間待機することもできます。

Git Action Runner

Github Actionはgithub環境内で実行することも、ユーザーが構成したサードパーティのインフラストラクチャで実行することもできます。

いくつかの組織は、サードパーティのインフラストラクチャでGithub Actionsを実行することを許可します。これは通常安価だからです。

組織のセルフホストランナーをリストするには、_https://github.com/organizations/<org_name>/settings/actions/runners_にアクセスします。

非Githubインフラストラクチャで実行されているGithub Actionsを見つける方法は、Github Actionの設定yamlでruns-on: self-hostedを検索することです。

異なる組織のセルフホストボックス内で組織のGithub Actionを実行することはできません。これは、ランナーを構成する際にユニークなトークンが生成され、ランナーがどこに属しているかを知るためです。

例えば、カスタムGithub RunnerがAWSやGCP内のマシンに構成されている場合、アクションはメタデータエンドポイントにアクセスでき、マシンが実行しているサービスアカウントのトークンを盗むことができます。

Git Action Compromise

すべてのアクション（または悪意のあるアクション）が許可されている場合、ユーザーは悪意のあるGithubアクションを使用して、実行されているコンテナを侵害することができます。

Branch Protections

ブランチ保護は、ユーザーにリポジトリの完全な制御を与えないように設計されています。目標は、特定のブランチ内でコードを書く前にいくつかの保護方法を設けることです。

リポジトリのブランチ保護は、_https://github.com/<orgname>/<reponame>/settings/branches_で見つけることができます。

ブランチに適用できるさまざまな保護（例えばmaster）：

• マージ前にPRを要求できます（したがって、ブランチに直接コードをマージすることはできません）。これが選択されると、他のさまざまな保護が適用される可能性があります：
• 承認の数を要求します。PRを承認するために1人または2人以上の人の承認を要求することは非常に一般的で、単一のユーザーが直接コードをマージできないようにします。
• 新しいコミットがプッシュされたときに承認を無効にする。そうでない場合、ユーザーは正当なコードを承認し、その後悪意のあるコードを追加してマージする可能性があります。
• コードオーナーからのレビューを要求します。リポジトリの少なくとも1人のコードオーナーがPRを承認する必要があります（したがって「ランダム」なユーザーは承認できません）。
• プルリクエストレビューを無効にできる人を制限します。プルリクエストレビューを無効にできる人やチームを指定できます。
• 指定されたアクターがプルリクエスト要件をバイパスできるようにします。これらのユーザーは以前の制限をバイパスできます。
• マージ前にステータスチェックが通過することを要求します。コミットをマージする前にいくつかのチェックが通過する必要があります（例えば、クリアテキストの秘密がないことを確認するGithubアクションなど）。
• マージ前に会話の解決を要求します。コードに対するすべてのコメントは、PRをマージする前に解決される必要があります。
• 署名されたコミットを要求します。コミットは署名される必要があります。
• 線形履歴を要求します。マージコミットが一致するブランチにプッシュされるのを防ぎます。
• 管理者を含める。これが設定されていない場合、管理者は制限をバイパスできます。
• 一致するブランチにプッシュできる人を制限します。PRを送信できる人を制限します。

References

• https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization
• https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprisehttps://docs.github.com/en/enterprise-server
• https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github
• https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/permission-levels-for-user-owned-project-boards
• https://docs.github.com/en/actions/security-guides/encrypted-secrets