GitLab トークン管理標準

目的

トークン管理標準は、GitLab 製品で使用される様々なシステムおよびサブシステム内で認証と認可を提供する目的のために、承認された GitLab のトークン使用、設定、配布を定義します。

本標準のいくつかの要素では、現在実装されていない技術、テクニック、設定、およびそれらのバリエーションが参照されます。それらの場合、本標準は将来の開発と実装に対する具体的なガイダンスを提供することを意図しています。

トークン管理標準により、GitLab 内でのトークン使用に対するより一貫したアプローチ、業界標準やコンプライアンスフレームワーク（FedRAMP など）へのより容易な適応、そして全体としてよりセキュアな製品と作業環境が可能になります。さらに、ほとんどのコンプライアンスフレームワークが NIST 標準に基づいており、NIST が世界中の多くの組織で採用される確かな推奨事項を一貫して提供していることから、本標準のほとんどは NIST（National Institute of Standards and Technology）の推奨事項に基づいています。

適用範囲

トークン管理標準は、GitLab データを取り扱う、管理する、保存する、または送信するすべての GitLab チームメンバー、契約社員、コンサルタント、ベンダー、その他のサービスプロバイダーに適用されます。

これは、GitLab 製品自体のトークンを伴うアカウントおよび認証子管理だけでなく、コーディングのベストプラクティスにも必須です。基本的に、GitLab または GitLab 顧客データに触れるものであれば、本標準が適用されます。

役割と責任

GitLab の責任

GitLab チームメンバー、契約社員、コンサルタント、ベンダー、その他のサービスプロバイダーは、本トークン管理標準を定期的にレビューして理解し、セキュリティを維持するために GitLab トークンをどのように要求、承認、配布、使用、保護するかを把握することが求められます。本書はいつでも更新される対象であり、上記の人々は変更を追跡する責任を負います。

顧客の責任

GitLab の顧客は、自身のアカウントとトークンの管理に責任を負い、これらの標準を強く推奨されるものとみなし、自身の内部要件に応じて採用することが求められます。GitLab は Mutual Non-Disclosure Agreement に明記された秘密保持義務に従って Customer Data を内部で扱い、本標準で特定されているコントロールを使用します。

標準

コンプライアンスおよび認証標準

一般的な前提

• 本標準は GitLab 製品内では現在完全には実装されていませんが、本標準を達成するために将来の開発を導く助けとなります。
• 本標準は関連するすべてのコンプライアンスニーズ（例: FedRAMP の要件）を満たします。
• Personal Access Tokens（PAT）は GitLab 本番環境内で強く非推奨とされ、可能な限り無効化／不許可となります。既存のトークンは残りますが、追加の発行は許可／可能ではなくなります。
• 多くのトークンは無効化が可能で、特定の環境内（例: FedRAMP）では、以下に定義する作成、使用、保管、アクセスの基準を満たせない限り、無効化されなければなりません。
• GitLab 環境内で作成・使用されるデータの主要な仲介者は、Site Administrator ** と呼ばれます。

トークンとアカウントの管理

1. GitLab アプリケーションの性質、および GitLab インスタンスにアクセスを持つ悪意のあるアクターがインスタンス内に含まれる情報に損害を与える可能性から、アカウントタイプの定義が必要です。GitLab インスタンスはアプリケーション内に特権アカウントと非特権アカウントの両方を持ちます。この特権レベルは、システム全体のアカウント特権レベルとは独立しています。GitLab アプリケーションアカウントは「Development」アカウントタイプです。「Development」アカウントタイプ内をさらに区別するために、特権アカウントと非特権アカウントがあります。((AC-2(a), AC-2(7) *)。トークンに関連付けられる役割:

   役割	特権状態
   Site Administrator **	特権
   Developers ***	特権と非特権の両方、特定の役割による
   Group Owner	特権
   Group Maintainer	特権
   Project Owner	特権
   Project Maintainer	特権
   Group Developer	非特権
   Group Reporter	非特権
   Group Guest	非特権
   Project Developer	非特権
   Project Reporter	非特権
   Project Guest	非特権

2. Group Owner、Group Maintainer、Project Owner、Project Maintainer ロールのすべての割り当ては、制限され、文書化され、Site Administrator により承認されなければなりません（AC-2(i), AC-5, IA-4 *）。
3. すべての Impersonation トークンは Site Administrator により承認されなければなりません（AC-5 *）。
4. すべてのグループおよびプロジェクトメンバーシップは、それぞれの Group および Project Owner により承認されなければなりません（AC-5 *）。すべての既存のグループおよびプロジェクトメンバーシップは半年ごとにレビューされ、もはや適切でないメンバーシップは削除されます（AC-2(j), AC-2(7) *）。
5. すべての登録済み Runner は半年ごとにレビューされ、不要なインスタンスは削除されます。
6. Group および Project の Maintainer および Owner ロールは、それぞれの Group または Project に対する「Account Manager」の責任を引き受けて共有します。これにはトークンの承認、作成、失効、使用状況の監視が含まれますが、これらに限定されません（AC-2(b)(e)(f)(g) *）。これらのロールは、Group および Project レベルでトークンを作成できるためここに識別されています。これは本質的にアカウント作成です。トークンの作成は関連付けられた Bot アカウントの作成も意味するためです。
7. すべての Group、Project、Runner Registration、Deploy トークンは Account Manager により承認されなければなりません。（AC-2(c)(d)(e) *）
8. 小規模なチームと 2 つの役割を持つ人員の可能性を許容しつつ、プロセスの完全性のレベルを維持するために、アカウントマネージャーはトークンの作成と報告のために他のアカウントマネージャーを動員すべきです。Account Manager は自身のトークンを承認することはできません（AC-5 *）。
9. アクティブなトークンのログまたはインベントリは、各グループの Account Manager により維持されます。（多数のトークンを発行する大規模チームには、これは大きな管理負担となります。）
10. Account Manager は少なくとも毎月、トークンの使用状況をレビューし、不要または未使用のトークンを失効させます（AC-2(j), AC-2(3) *）。
11. Account Manager は、トークン保持者から侵害が報告されたトークンを失効させます（AC-2(12) *）。
12. GitLab の上司／GitLab の顧客は、権利と権限の調整を必要とする可能性のある雇用ステータスの変更について、すべての Group オーナーに通知します（AC-2(h) *）。
13. メンバーが解雇または再配置でグループまたはプロジェクトを離れる場合、グループおよびプロジェクトのトークンは失効させます（AC-2(h) *）。
14. GitLab 環境外でのトークンの保管には、トークンがアクセスを与える Group または Project と同等以上のレベルの適切な保護が必要です（IA-5(6) *）。

トークンの作成と配布

1. トークンの共有および配布は制限され、文書化と、トークンが配布される相手の身元検証を含まなければなりません（IA-5(a) *）。
2. GitLab チームメンバーは、トークンを非チームメンバーに配布しません（AC-21, AC-22 *）。
3. トークン名には Group/Project 名と作成日（YYYYMMDD）を含めます（IA-2, IA-5(b) *）。
4. トークンは、目的のタスクを実行するために必要な最小のロールとスコープで作成します（AC-6 *）。
5. トークンは Maintainer または Owner ロールで作成してはなりません（AC-6 *）。
6. トークンは目的のタスクを達成するための最も短い妥当な有効期限で作成しますが、いかなる場合も以下を超える有効期限は持ちません: (AC-2(3) *)
   • Personal Access Tokens - 30 日
   • Group Tokens – 1 年
   • Project Tokens – 1 年
   • Deploy tokens – 72 時間
   • Deploy keys – 72 時間
   • Impersonation Tokens – 24 時間
   • Runner Tokens – 1 年
   • Runner Registration Keys – 72 時間
7. トークンの「ランダム」な部分（プレフィクスやその他の追加部分を除く）は、FIPS 認定で暗号学的に承認されたアルゴリズムを使用して生成します。

トークンの保管

1. トークンの保管はセキュアでなければなりません。暗号化される必要があります。推奨される方法には、セキュリティボールトまたは鍵管理システムの使用が含まれます。クラウドまたは Self-Managed 環境では、Hashicorp Vaults Pro、Amazon KMS または Google Secret Manager を含むことができます。ローカル（例: ラップトップ）の保管にも暗号化は必要であり、パスワードマネージャー（例: 1Password）の使用が推奨されます。トークンのコピーやバックアップは、構成ファイル、テキストファイル、その他の平文での保管方法に保存して はいけません。

トークンの侵害

1. 侵害されたトークンは直ちに対処する必要があります。侵害されたトークンは、機密データの開示、不正アクセス、場合によっては権限昇格などの様々な危険につながる可能性があるため、いかなる侵害も真剣に受け止める必要があります。GitLab では、トークンの即時失効に続いて潜在的な影響を評価する調査を実施することが標準です。侵害されたトークンの即時失効が、既存のアクセスや自動化を破壊する可能性があることは理解されています。この影響は、有効なトークンが悪意のあるアクターによって使用されるリスクと比較して、通常はるかに小さなものです。検出メソッドの一部を自動化して侵害されたトークンの検出を支援できるため、これらの自動検出メソッドには、失効を自動化する能力も含めるべきです。

2. 侵害されたトークンを軽減するためのすべてのメソッド、手順、通知、自動化は完全に文書化される必要があります。GitLab では、プロセスへの変更はすべて Security Department、特に SIRT により承認される必要があります。gitlab.com への重大な変更（例: 本番環境への潜在的な影響）は、すべての関連する関係者に事前に伝達される必要があります。

3. GitLab は、ユーザーアカウントを保護するために漏洩していると識別されたトークンを失効させます。失効後、トークン所有者はトークンが失効されたことを知らせる自動通知を受け取ります。

トークンのロギングと監査

1. トークンのライフサイクル（作成、属性、使用、削除）は、監査目的でログに記録される必要があります。
2. トークンアクティビティのロギングは限定された数量で「ローカル」に保存できますが、バックアップ／オフサイトのストレージが推奨されます。
3. ロギングでは、トークンの侵害を防ぐためにトークン値自体は隠蔽またはマスキングされたままでなければなりません。

トークンの使用

1. トークンを使用するために開発されたコードには、次のものを含むドキュメントが必要です:
   • トークンの定期的な交換のための方法論。
   • 交換用トークンに必要なスコープ（権限）。
   • トークンが実行する想定のタスク（アプリケーション、プロセス、関数呼び出し名）の特定。
2. トークンの使用は、トークン認証をトリガーするコードによってログに記録される必要があります（AC-6(9) *）。ログイベントには最低限以下を含めます:
   • トークン認証の成功または失敗。
   • トークンがアクセスしたオブジェクト、プロセス、または関数。
   • トークンによって実行された変更。
   • トークンによって実行されたデータアクセス、変更、削除。
   • 日付と時刻。
   • トークンを利用したオブジェクト、関数、またはプロセス。
   • どのアカウントがトークンの使用を起動したか。
3. トークンを所有する GitLab チームメンバーは、それらのトークンの管理と保護を維持し、トークンが破損したか何らかの方法で侵害されたと考えられる場合は Account Manager に通知します。
4. 本番環境と開発環境では異なるトークンの使用が必要です。トークンを環境間で共有してはなりません。

例外

本ポリシーへの例外は、情報セキュリティポリシー例外管理プロセス に従って追跡され、現在、潜在的な例外は Security Assurance の許可が必要です。

参考資料

• 管理対象ドキュメント手順

* 参照（例: 「AC-2(a)」）は NIST SP 800-53 Rev. 5 に詳述されています。

** 「administrator」または「site administrator」のロールは、GitLab インスタンスの主たる責任ある監督者を意味します。GitLab SaaS 内ではこれは Owner として知られています。Self-Managed インスタンスや Dedicated では、これは Admin です。

*** Developer はコーディングを意味しますが、様々な自動化目的でトークンを必要とするプロジェクトの「開発者」もこのコンテキストでは「developers」とみなされます。

ページのソースコードを見る - ページの編集 - please contribute.