正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

認証および認可に関する用語集

この用語集では、GitLabにおける認証、認可、アクセス制御に関する用語を定義しています。

IDとフェデレーション

システム間でユーザーIDを確立および検証する外部Identity Providerとプロトコル。これらの用語は、GitLabがエンタープライズアイデンティティ管理システムと統合して、ユーザー認証を一元化する方法を説明しています。

Identity Provider(IdP): OktaやOneLoginなど、ユーザー認証情報を管理するサービス。

サービスプロバイダー(SP): 外部のIdentity Providerに認証を委任するアプリケーション。SAMLまたはOIDC認証用に設定されている場合、GitLabはサービスプロバイダーとして機能します。

シングルサインオン(SSO): 単一の認証情報セットで複数のアプリケーションにアクセスできる認証方法。SSOを使用すると、ユーザーはIdentity Providerを通じて1回認証するだけで、認証情報を再入力することなくGitLabおよびその他の接続されたサービスにアクセスできます。

SAML: Security Assertion Markup Language。XMLベースのプロトコルで、Identity Providerとサービスプロバイダーの間で認証および認可データを交換します。GitLabは、エンタープライズのシングルサインオン用にSAML認証をサポートしています。

LDAP: Lightweight Directory Access Protocol。ディレクトリ情報サービスにアクセスして維持するための標準です。GitLabはLDAPサーバーと統合され、ユーザーを認証し、アカウント情報を同期します。

SCIM: System for Cross-domain Identity Management。プロビジョニングとデプロビジョニングを自動化するための標準です。GitLabはSCIMをサポートしており、Identity Providerからのユーザーライフサイクルイベントを同期します。

OIDC(OpenID Connect): アイデンティティ管理検証を提供するOAuth 2.0上に構築された認証レイヤーです。GitLabは認証にOIDCをサポートしており、外部アプリケーション用のOIDCプロバイダーとして機能します。

OAuth: パスワードを共有することなく、ユーザーに代わってGitLabリソースにアクセスするための認可プロトコル。OAuthはサードパーティのインテグレーションと、GitLabをIdentity Providerとしてサポートします。

アサーション: ユーザーアイデンティティ管理に関する情報。例えば、名前やロールなど。クレームまたは属性とも呼ばれます。

クレーム: ユーザーアイデンティティ管理または認証トークンに含まれる属性に関する情報。クレームは、OAuth、OIDC、およびJWTトークンで使用され、ユーザー名、メール、グループメンバーシップなどの詳細を伝達します。

プロビジョニング: ユーザーアカウントとアクセス権を作成および構成する自動化されたプロセス。SCIMまたはLDAPを使用して、外部アイデンティティ管理システムからGitLabにユーザーを同期できます。

アサーションコンシューマサービスURL: Identity Providerでの認証が成功した後、ユーザーがリダイレクトされるGitLab上のエンドポイント。

発行者: GitLabがIdentity Providerに自身を識別する方法。信頼関係識別子とも呼ばれます。

証明書フィンガープリント: サーバーが正しい証明書で通信に署名していることを検証することにより、SAML通信が安全であることを確認します。証明書フィンガープリントとも呼ばれます。

認証

GitLabへのアクセスを許可する前に、ユーザーアイデンティティ管理を検証するメソッドと認証情報。認証は、システムへのアクセスを許可する前に、あなたが誰であるかを確認します。認証方法には、パスワード、2要素認証、SSHキー、パーソナルアクセストークン、および外部Identity Providerとのインテグレーションが含まれます。

パスキー: デバイスに保存された暗号学的認証情報を使用するパスワード不要の認証方法。パスキーは、生体認証またはデバイスのPINを使用してフィッシング耐性のある認証を提供します。

2要素認証(2FA): パスワードに加えて、2番目の形式の認証をユーザーに要求する追加のセキュリティレイヤー。GitLabは、オーセンティケーターアプリやリカバリーコードなど、さまざまな2FA方法をサポートしています。

セッション: ユーザーがGitLabにサインインした後に保持される一時的な認証済み状態。セッションは、セッションの有効期限が切れるか終了するまで、複数のリクエストにわたって保持されます。

SSHキー: Gitリポジトリにアクセスする際に安全な認証のために使用される暗号学的キー。SSHキーは、Git操作のパスワードベースの認証に代わる安全な手段を提供します。

パーソナルアクセストークン: GitLab APIまたはHTTPS経由でGitを使用する際に、認証のためのパスワードの代わりとして機能するトークン。パーソナルアクセストークンには、実行できるアクションを制限する定義済みスコープがあります。

グループアクセストークン: 特定のグループとそのサブグループでの自動タスクのために、特定のグループにスコープ設定されたトークン。グループアクセストークンはグループ権限を継承し、APIアクセスとGit操作をサポートします。

プロジェクトアクセストークン: 特定のプロジェクトでの自動タスクのために、特定のプロジェクトにスコープ設定されたトークン。プロジェクトアクセストークンは、CI/CDパイプラインやプロジェクト固有のアクセスが必要なインテグレーションで一般的に使用されます。

デプロイトークン: デプロイ自動化のためにスコープが制限されたトークン。デプロイトークンは、ユーザーアカウントを必要とせずに、リポジトリおよびパッケージレジストリへの読み取り専用または書き込みアクセスを提供します。

JWT(JSON Webトークン): 当事者間で情報を安全に送信するためのコンパクトなトークン形式。GitLabは、CI/CDジョブ認証、OAuthフロー、およびサービス間通信にJWTを使用します。

代理: 認可されたユーザーが一時的に別のユーザーとして行動できる管理機能。代理は、ユーザー固有のイシューのトラブルシューティングを行うために使用されることがあります。

ユーザーとアカウント管理

GitLabで異なるアクセスレベルと機能性を定義するアカウントタイプとユーザーカテゴリ。これらの用語は、システムと対話できるさまざまな種類のアカウントを説明しています。

ユーザーアカウント: GitLabにアクセスする個人を表す個別のアカウント。ユーザーアカウントは、異なるグループやプロジェクトにわたってさまざまなロールを割り当てることができます。

ユーザータイプ: 許可されたアクションのセットを暗黙的に付与するユーザーアカウントに割り当てられたタイプ。タイプには、Regular、監査担当者、および管理者が含まれます。タイプはロールと権限とは異なります。

管理者ユーザー: 最高のシステムアクセスレベルを持つユーザータイプ。管理者アクセス権を持つユーザーは、インスタンス全体の設定を構成し、他のユーザーを管理し、すべてのグループおよびプロジェクトにわたって管理タスクを実行できます。

監査担当者ユーザー

すべてのグループ、プロジェクト、および管理機能への読み取り専用アクセス権を持つ特別なユーザータイプ。監査担当者ユーザーは変更を行うことはできませんが、コンプライアンスとセキュリティのためにコンテンツを閲覧できます。

外部ユーザー: 組織外として指定されたユーザーで、内部プロジェクトおよびグループへのアクセスが制限されています。外部ユーザーは、直接メンバーシップを持つプロジェクトのみにアクセスできます。

サービスアカウント: 自動アクションの実行、データへのアクセス、またはスケジュールされたプロセスの実行のために設計された非人間ユーザーアカウント。サービスアカウントは、パイプラインまたはサードパーティのインテグレーションで一般的に使用されます。

認可とアクセス制御

認証済みユーザーがGitLabで何ができるかを決定するフレームワークとプロセス。認可は、ユーザーアイデンティティ管理、ロール、およびリソースの所有権に基づいて権限を評価します。

アクセス制御: 認証(ユーザーが誰であるかを検証する)と認可(ユーザーが何ができるかを決定する)に基づいてリソースへのアクセスを制限する慣行。

認可: 認証済みユーザーがGitLabで実行できるアクションを決定するプロセス。認可は、割り当てられたユーザーロール、権限、およびグループとプロジェクトへのメンバーシップに基づいています。

RBAC(ロールベースのアクセス制御): 権限がユーザーに直接ではなくロールを介して割り当てられるアクセス制御モデル。GitLabでは、ユーザーはグループまたはプロジェクトに割り当てられたロールに基づいて権限を受け取ります。

ポリシー: プリンシパルがリソースに対して実行できるアクションを決定する認可規則のセット。GitLabは、宣言型ポリシーフレームワークを使用してアクセス制御の決定を適用します。

権限とロール

ユーザーがリソースに対して実行できるアクションを定義する構成要素。権限はロールに結合され、ユーザーに特定の機能を与えるために割り当てられます。

権限: ユーザーがGitLabリソースで実行できる特定のアクション。たとえば、イシューの作成、コードのプッシュ、またはプロジェクト設定の管理などです。

ロール: グループおよびプロジェクトで実行できるアクションを定義するために、ユーザーに割り当てられる1つ以上の権限のセット。ロールには、デフォルトロールとカスタムロールの両方が含まれます。

デフォルトロール: すべてのGitLabインスタンスで利用可能な事前定義されたロール。各ロールには、特定の権限セットが含まれます。次のデフォルトロールが利用可能です: Minimal AccessGuestPlannerReporterSecurity ManagerDeveloperMaintainerOwner

カスタムロール: 組織のニーズを満たすためにGitLabインスタンス用に作成するロール。各カスタムロールは、追加の権限を持つデフォルトロールを拡張します。

スコープ: 特定の組織レベルでトークンまたはOAuthアプリケーションに利用可能な権限。GitLabは、スコープを使用して、パーソナルアクセストークン、グループアクセストークン、プロジェクトアクセストークン、およびOAuthアプリケーションに付与されるアクセスを決定します。

組織構造

リソースを整理し、アクセス制御を行う階層コンテナと関係。これらの構造は、グループ、プロジェクト、およびネームスペースを介して権限がどのようにフローするかを決定します。

ネームスペース: グループとプロジェクトを階層構造で整理するコンテナ。ネームスペースは、リソースパスと権限の継承を決定します。各ユーザーはパーソナルネームスペースを持ち、グループはチームのために共有ネームスペースを提供します。

グループ: 効率的な組織化と権限管理を可能にする関連プロジェクトとユーザーのコレクション。グループはサブグループを含むことができ、親グループから権限を継承します。

メンバー: 特定のグループまたはプロジェクトへのアクセスを許可されたユーザー。メンバーは、そのリソースでの権限を決定する割り当てられたロールを持っています。

メンバーシップ: ユーザーと特定のグループまたはプロジェクトとの関連付けで、そのリソースでのアクセス権を定義します。ユーザーは、複数のグループやプロジェクトにわたって異なるメンバーシップとロールを持つことができます。

境界: 権限とポリシーを適用できる組織レベル:

  • インスタンス: GitLabインスタンス全体に適用されます。
  • グループ: 特定のグループ、および任意のサブグループまたはプロジェクトに適用されます。
  • プロジェクト: 単一のプロジェクトにのみ適用されます。
  • ユーザー: 特定のユーザーによって、またはユーザーに代わって実行されるアクションに適用されます。

継承: 親グループから子グループとプロジェクトへの権限の自動的なフロー。継承は、上位レベルで付与された権限をすべてのネストされたサブグループおよびプロジェクトに適用することにより、アクセス制御管理を簡素化します。

表示レベル: コンテンツを閲覧アクセスできるユーザーを制御する設定:

  • 公開: GitLabアカウントを持たないユーザーを含むすべての人に表示されます。
  • 内部: すべての認証済みGitLabユーザーに表示されます。
  • プライベート: メンバーにのみ表示されます。