GitLab パスワード標準
This is a Controlled Document
In line with GitLab’s regulatory obligations, changes to controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged.目的
本書は、技術的に実現可能な範囲において、機密情報（Red および Orange）を含む GitLab の情報システムやその他のリソースを不正利用から保護することを目的とした、情報セキュリティのパスワード標準を定めます。
適用範囲
GitLab のコンピューティングリソースに関わり、機密データにアクセスするすべての GitLab チームメンバー、契約社員、アドバイザー、契約当事者に適用されます。
役割と責任
| 役割 | 責任 |
|---|---|
| GitLab チームメンバー | 本標準に記載された要件を遵守する責任を負います |
| Security | クリティカルなアプリケーションについて、本標準の定義および導入状況のモニタリングを行う責任を負います |
| Security Management（コードオーナー） | 本標準への重大な変更および例外を承認する責任を負います |
標準
セキュアなパスワードを構築し、適切なパスワード管理を確保することは不可欠です。GitLab のパスワード標準は、NIST 800-63B の推奨事項を一部参考にしています。本当にセキュアなパスワードとは何かについて学ぶには、こちらの記事、またはパスワード強度に関するカンファレンス発表をご覧ください。
注: 技術的な制約により、システムが本標準の特定の設定をサポートできない場合は、本標準に最も近い設定を行わなければなりません。例外はこちらで起票し、リクエスト Issue 内のマトリクスに従って関連するリスク評価と例外レビュー期限が割り当てられます。
パスワード要件
- 最小長 = 12 文字
- 特殊文字 = 不要
- パスワードの再利用 = 不可
- パスワードの有効期限 = なし
- 多要素認証（MFA） = 可能な限り使用すること
覚えやすくセキュアなパスワードを作るには、5 個以上のランダムな単語の組み合わせを使うか、1Password で生成して保存することを検討してください。これにより、パスワードが容易に推測されず、サイトごとに一意になることが保証されます。
パスワード管理
- パスワードはプライベートに保ち、安全に保管してください。
- 個人アカウントのパスワードを共有してはなりません。
- パスワードを平文で保存したり、紙に書き留めたりしてはなりません。
- パスワードの「ヒント」を使用してはなりません。パスワードを忘れた場合は、パスワードリセットを要求した者の身元を検証する十分なコントロールを伴う仕組みでパスワード／パスフレーズを置き換えるメカニズムが必要です。
- パスワードはオフライン攻撃に耐性のある方法で保存され、適切な一方向の鍵導出関数を用いてソルト処理およびハッシュ化されなければなりません。
- パスワードを保存する必要がある場合は、承認されたパスワードまたはシークレットマネージャー内に保存する必要があります。
- アカウントまたはパスワードが侵害されたと疑われる場合は、直ちに Security にインシデントを報告し、速やかに指示に従ってください。
システムパスワード設定要件
- パスワードを設定可能なシステムでは、最小パスワード長を 12 文字に設定する必要があります。
- 特殊文字の使用は必須ではなく、推奨もされません。
- 特定のシステムでパスワード履歴が必要な場合は、25 個の記憶パスワードに設定してください。
- 既知の漏洩パスワードリスト、辞書ワード、繰り返しまたは連続する文字、サービス名・ユーザー名やその派生といったコンテキスト固有の単語など、よく使われるまたは予測されるパターンと一致するパスワードは許容されず、これらに対してチェックされなければなりません。
- アプリケーションおよび／またはデバイスのシステム管理者は、デフォルトのパスワードを変更しなければなりません。
- システム管理者は、該当する場合、サードパーティアプリケーションおよび／またはツールでパスワード強度設定を有効にする必要があります。
- パスワードのみが認証ソースとなるアプリケーションでは、パスワードは最大 90 暦日以内に有効期限切れにしなければなりません。
- システムはログイン失敗を監視し記録するべきです。
- 認証ログイン失敗に関する情報は、技術的に可能であれば、アプリケーションログ内に記録される必要があります。例えば、名前、日付、失敗回数、一意のログ識別子など。
- 繰り返しのログイン失敗は、10 回失敗後に一時的なアカウントロックアウトをトリガーする必要があります。特定のシステムが 10 回以下のロックアウトをサポートしない場合、そのシステムが許容する最小値にロックアウトを設定する必要があります。ロックアウトは指定期間後に解除されるか、アプリケーションのプロファイルに応じて手動アンロックを必要とする場合があります。
- 多要素認証（MFA）を強制する必要があります。
多要素認証（MFA または 2FA）
すべての GitLab チームメンバーは 多要素認証（MFA）を使用することが必須です。GitLab チームメンバーが本番環境にアクセスするには MFA の使用が 必須 です。
以下の表は、認証器の種類を保証レベルでランク付けしています。 すべての MFA 方式が同等の保護を提供するわけではありません。重要なセキュリティ上の区別は フィッシング耐性 です。これは、認証が依拠当事者のオリジンに暗号学的に結び付けられており、偽装サイトに対して資格情報を再利用できないかどうかを指します。
GitLab チームメンバーは、利用できる中で最も強力な方式を使用するべきです。
| 保証レベル | 認証器 | 例 | 要素（所持 / 知識 / 生体） | フィッシング耐性 | ハードウェア保護 | デバイス固定 | ユーザー検証 | 脆弱性 |
|---|---|---|---|---|---|---|---|---|
| 高 | FIDO2 ローミング認証器 | YubiKey（FIDO2 モード）、Google Titan | 所持 + 生体または知識 | ✅ | ✅ | ✅ | ✅ | 物理的な盗難または紛失 |
| 高 | FIDO2 プラットフォーム認証器 | Touch ID、Face ID、Windows Hello、Android Fingerprint | 所持 + 生体または知識 | ✅ | ✅ | ✅ | ✅ | デバイスの侵害、物理的アクセス |
| 高 | Okta FastPass（生体認証または PIN） | Okta Verify + FastPass | 所持 + 生体または知識 | ✅ | ✅ ¹ | ✅ | ✅ | デバイスの侵害。デバイスの存在のみを確認するモードは MFA を満たしません |
| 高 | 同期パスキー | 1Password、iCloud Keychain、Chrome/Google Password Manager | 所持 + 生体または知識 ² | ✅ | ❌ | ❌ | ✅ | 同期アカウントまたは保管庫の侵害 |
| 中 | プッシュ通知 | Okta Verify Push | 所持（+ 生体）³ | ❌ | ✅ ¹ | — | ✅ | AiTM フィッシング、MFA 疲労（プッシュ爆撃） |
| 中 | ハードウェア OTP トークン | YubiKey OTP モード、RSA SecurID | 所持 | ❌ | ✅ | ✅ | ❌ | AiTM リアルタイムフィッシング、物理的な紛失 |
| 低 | TOTP / ソフトトークン | Okta Verify OTP、Google Authenticator、1Password TOTP | 所持 | ❌ | ❌ | ❌ | ❌ | AiTM リアルタイムフィッシング、シードの盗難 |
| 制限 | SMS / 音声 | — | 所持 | ❌ | ❌ | ❌ | ❌ | SIM スワップ、SS7 傍受、ソーシャルエンジニアリング |
| 許可しない | セキュリティ質問 | 秘密の質問、アカウント復旧プロンプト | 知識 | ❌ | ❌ | ❌ | ❌ | 推測、ソーシャルエンジニアリング、データ侵害への露出 |
| 許可しない | パスワードヒント | — | 知識 | ❌ | ❌ | ❌ | ❌ | 推測、ソーシャルエンジニアリング。設計上、パスワードのエントロピーを低下させます |
¹ ハードウェア保護はデバイスに依存します。Device Trust を有効にして Okta Verify に登録する必要があります。
² パスキーは所持要素です。保護する保管庫または同期アカウントには、生体または知識が必要です。組み合わせた保証は、そのアカウントの保護方法に左右されます。
³ プッシュ承認の生体認証による有効化は、デバイスと設定に依存します。
生体認証に関する注記: 生体認証のプロンプト（Touch ID、Face ID）は有効化の仕組みであり、暗号学的な認証器のロックを解除します。それ自体が認証器ではありません。
MFA が GitLab にどのように適合するかをより理解するには、パスワード設定、FIDO2 トークンの取得、追加リソースへのリンクを含む Accounts and Passwords セクションを参照してください。FIDO2/WebAuthnおよびその他の 2FA 方式に関する詳細は、Tools and Tips ページを参照してください。
アプリケーション認証要件
- FY23 Q3 以降、GitLab の機密データを格納するすべてのサードパーティアプリケーションは、GitLab の集中認証・認可アプローチに従って Okta 経由で認証することが必須です。Okta がサポートされていないすべてのケースでは、Security Notices が必要となります。
- アプリケーションへの認証には多要素認証（トークン、OTP ジェネレーター、SSO、YubiKey）が含まれるべきです。
- 認証ポータルへのログイン後の OIDC、SAML、WS-Federation は、技術的に可能な場合（例: Okta）必須です。
- アプリケーションへの認証は、グループではなく個別のユーザーをサポートするべきです。
例外
本標準への例外は、情報セキュリティポリシー例外管理プロセス に従って追跡されます。
参考資料
c955a93f)