Security_standard_acia on GitLab ハンドブック (非公式日本語訳)

GitLab パスワード標準

Thu, 02 Apr 2026 12:48:42 -0700

Visibility: Audit

目的

本書は、技術的に実現可能な範囲において、機密情報（Red および Orange）を含む GitLab の情報システムやその他のリソースを不正利用から保護することを目的とした、情報セキュリティのパスワード標準を定めます。

適用範囲

GitLab のコンピューティングリソースに関わり、機密データにアクセスするすべての GitLab チームメンバー、契約社員、アドバイザー、契約当事者に適用されます。

役割と責任

役割	責任
GitLab チームメンバー	本標準に記載された要件を遵守する責任を負います
Security	クリティカルなアプリケーションについて、本標準の定義および導入状況のモニタリングを行う責任を負います
Security Management（コードオーナー）	本標準への重大な変更および例外を承認する責任を負います

標準

セキュアなパスワードを構築し、適切なパスワード管理を確保することは不可欠です。GitLab のパスワード標準は、NIST 800-63B の推奨事項を一部参考にしています。本当にセキュアなパスワードとは何かについて学ぶには、こちらの記事、またはパスワード強度に関するカンファレンス発表をご覧ください。

注: 技術的な制約により、システムが本標準の特定の設定をサポートできない場合は、本標準に最も近い設定を行わなければなりません。例外はこちらで起票し、リクエスト Issue 内のマトリクスに従って関連するリスク評価と例外レビュー期限が割り当てられます。

パスワード要件

最小長 = 12 文字
特殊文字 = 不要
パスワードの再利用 = 不可
パスワードの有効期限 = なし
多要素認証（MFA） = 可能な限り使用すること

覚えやすくセキュアなパスワードを作るには、5 個以上のランダムな単語の組み合わせを使うことを検討してください。「好きな色は何ですか？母親の旧姓は何ですか？」のようなセキュリティ質問は、当てにくいランダムな単語または単語のセットで回答してください。1Password で回答を生成し、ノートとして保存できます。これにより回答が容易に推測されず、サイトごとに一意になることが保証されます。

アクセスレビュー手順

Fri, 16 Jan 2026 15:03:53 -0600

Visibility: Audit

目的

GitLab のユーザーアクセスレビューは、内部および外部の IT 監査に必要な重要なコントロールアクティビティであり、脅威を最小化し、適切な人々が重要なシステムやインフラストラクチャに対する適切なアクセス権を持っていることを保証するのに役立ちます。この手順では、プロセスのステップを詳述し、アクセスレビューに関するコントロールオーナー向けのガイダンスを提供します。

組織への利益

セキュリティリスクを低減する
休眠アカウントや無効化されたアカウントを特定する
必要なチームメンバーのみがシステムにアクセスできることを保証する
ロールが変更されたユーザーが、もはや関連性のないアクセス権を保持していないことを検証する
退職したチームメンバーが会社のシステムにアクセスできなくなることを保証する
顧客の信頼を維持する GitLab のコンプライアンスおよび規制要件をサポートする

範囲

対象システム

セキュリティコンプライアンスは、要因のサブセットに基づいて対象システムのアクセスレビューを実施します。以下を含みます。

起源: 外部認証への影響、Red Data System
重要度: ミッションクリティカル
Lumos コネクタが利用可能な場合のビジネスクリティカル

すべての GitLab システムとベンダー、および関連するクリティカルシステムティアの最新リストについては、テックスタックを参照してください。

対象外システム

上記の対象システム要因のしきい値の範囲外にあるシステム。一般的なベストプラクティスとして、すべてのシステムオーナーは、このプロセスをガイドとして使用し、自分が所有するシステムに対して少なくとも年次の退職者アクセスレビューを実施することを強く推奨されます。

役割と責任

役割	責任
セキュリティコンプライアンスチーム	完全な権限レビュー、特権アクセス、退職ユーザーレビューの実行特定された所見に対する観察事項の作成と是正活動の監督
IT コンプライアンスチーム	SOX 対象システムに対する完全な権限レビュー、特権アクセス、退職ユーザーレビューの実行特定された所見に対する観察事項の作成と是正活動の監督
システムオーナー	特権権限の検証ユーザー権限の検証タイムリーな証拠サポート特定された観察事項に対する是正計画の実行 * アクセス削除の実行
システム管理者	特権権限の検証ユーザー権限の検証タイムリーな証拠サポート特定された観察事項に対する是正計画の実行 * アクセス削除の実行
マネージャー	特権権限の検証をサポートユーザー権限の検証をサポート
IT 運用	* アクセス削除の実行
セキュリティアシュアランスマネジメント (Code Owners)	この手順への重要な変更や例外の承認に責任を持つ

Lumos とは何か、なぜ Okta タイルがあるのか？

Lumos は GitLab のユーザーアクセスレビューツールです。すべてのユーザーアクセスレビューを促進するために使用されます。デフォルトでは、すべてのチームメンバーはオンボーディング時に Lumos へのアクセス権を受け取ります。Lumos にアクセスするには、チームメンバーは Okta の Lumos タイルを選択できます。アクセスレビューが割り当てられた場合は、以下にリンクされているランブックに従ってアクセスレビューを完了してください。

アクセスリクエスト（AR）

Wed, 19 Nov 2025 12:25:32 -0800

Visibility: Audit

アクセスリクエストは IT チームが所有し、オンボーディング、オフボーディング、内部異動リクエストは People Operations チームが所有します。

アクセスリクエストに関する質問がある場合は、Slack の #it_help またはツールのプロビジョナーにお問い合わせください。

アクセスリクエストに関連するページ

はじめに

すべてのオープンおよびクローズ済みの AR は access-requests project で確認でき、新しい Issue はこちらから作成できます。

新しい AR を作成すると、リクエストを満たすために必要な追加情報や追加の承認が必要かを正確に判断するため、さまざまなテンプレートから選択するオプションが与えられます。各 Issue タイプに必要なすべてのラベルを追加するよう努めましたが、見落としがあるかもしれませんので、送信前にリクエストを再確認してください。

利用可能なテンプレートは多数ありますが、通常以下のいずれかのカテゴリに該当します。

利用可能なすべてのテンプレートの完全なリストはこちらで確認できます

個別または一括アクセスリクエスト

個別または一括アクセスリクエストは、他のテンプレートが希望するものと一致しない場合に使用してください。

このテンプレートは、すべての人が同じシステムへのアクセスをリクエストする限り、個人または複数人のアクセスをリクエストするのに使用できます。複数人が異なるシステムへのアクセスを必要とする場合は、複数の Issue を作成してください。

アクセス変更リクエスト

アクセス変更リクエストは、チームメンバーが現在プロビジョニング済みのシステムへのアクセスを必要としなくなった場合や、同じレベルのアクセスを必要としなくなった場合（管理者からユーザーへのアクセスダウングレードなど）に記録されます。追加情報については、GitLab ハンドブックの For Total Rewards Analysts: Processing Promotions & Compensation Changes セクションを参照してください。