GitLab Dedicated

GitLab Dedicatedは、以下のようなシングルテナントSaaSソリューションです:

• 完全に分離されています。
• ご希望のAWSクラウドリージョンにデプロイされます。
• GitLabによってホストおよびメンテナンスされます。

各インスタンスには以下が用意されています:

• ディザスターリカバリーを備えた高可用性
• 最新機能を備えた定期的な更新
• エンタープライズレベルのセキュリティ対策。

GitLab Dedicatedを使用すると、次のことが可能になります:

• 運用効率性の向上。
• インフラストラクチャ管理のオーバーヘッドを削減。
• 組織の俊敏性を向上させます。
• 厳格なコンプライアンス要件を満たします。

利用可能な機能

このセクションでは、GitLab Dedicatedで利用できる主要な機能を紹介します。

セキュリティ

GitLab Dedicatedには、データを保護し、インスタンスへのアクセスを制御するための、以下のセキュリティ機能が備わっています。

認証と認可

GitLab Dedicatedは、シングルサインオン（SSO）用にSAMLおよびOpenID Connect（OIDC）プロバイダーをサポートしています。

サポートされているプロバイダーを使用して、認証用のシングルサインオン（SSO）を設定できます。お客様のインスタンスはサービスプロバイダーとして機能し、お客様はGitLabがお客様のIDプロバイダー（IdPs）と通信するために必要な設定を提供します。

セキュアなネットワーキング

以下の2つの接続オプションがあります:

• IP許可リストによるパブリック接続: デフォルトでは、インスタンスはパブリックにアクセス可能です。指定されたIP許可リストへのアクセスを制限するために、IP許可リストを構成できます。
• AWS PrivateLinkによるプライベート接続: AWS PrivateLinkを受信および送信接続用に構成できます。

パブリックでない証明書を使用した内部リソースへのプライベート接続の場合は、信頼できる証明書を指定することもできます。

Webhookとインテグレーションのためのプライベート接続

Webhookとインテグレーションがパブリックインターネットからアクセスできないサービスに接続する必要がある場合は、AWS PrivateLinkをプライベート接続に使用できます。GitLab DedicatedはSaaSサービスであるため、ネットワーク内のローカルIP許可リストアドレスに直接接続することはできません。

内部サービスのプライベート接続を設定するには:

1. 内部サービスにホスト名を割り当てます。
2. 送信プライベートリンクを介してこれらのホスト名にルーティングするように、プライベートホストゾーン（PHZ）レコードを構成します。
3. 送信プライベートリンクの10エンドポイント制限を計画します。

10個を超えるエンドポイントに接続する必要がある場合は、インフラストラクチャにリバースプロキシまたはTLSパススルーを実装します。このアプローチでは、複数のサービスをより少ないプライベートリンク接続でルーティングします。

データの暗号化

データは、最新の暗号化標準を使用して、保存時および転送時に暗号化されます。

オプションで、保存時のデータに独自のAWS Key Management Service（AWS KMS）暗号化キーを使用できます。このオプションを使用すると、GitLabに保存するデータを完全に制御できます。

詳細については、保存時の暗号化されたデータ（BYOK）を参照してください。

メールサービス

デフォルトでは、Amazon SimpleメールService（Amazon SES）は、メールを安全に送信するために使用されます。代替として、SMTPを使用して独自のメールサービスを構成できます。

ウェブアプリケーションファイアウォール

Cloudflareは、分散型サービス拒否（DDoS）保護および関連するセキュリティ機能のためのWebアプリケーションファイアウォール（WAF）として実装されています。WAFの実装と構成は、GitLab SREチームによって管理されます。WAFの構成またはログへの直接アクセスはできません。

コンプライアンス

GitLab Dedicatedは、データのセキュリティと信頼性を確保するために、さまざまな規制、認証、コンプライアンスフレームワークを遵守しています。

コンプライアンスと認証の詳細を表示

コンプライアンスと認証の詳細を表示し、GitLab Dedicatedトラストセンターからコンプライアンスアーティファクトをダウンロードできます。

アクセス制御

GitLab Dedicatedは、環境を保護するために厳格なアクセス制御を実装しています:

• 必要な最小限の権限のみを付与する最小特権の原則に従います。
• AWS組織へのアクセスを、選択されたGitLabチームメンバーに制限します。
• ユーザーアカウントに対する包括的なセキュリティポリシーとリクエストを実装します。
• 自動化されたアクションと緊急アクセスのために、単一のHubアカウントを使用します。
• GitLab Dedicatedのエンジニアは、顧客環境に直接アクセスできません。

緊急時、GitLabエンジニアは次のことを行う必要があります:

1. Hubアカウントを使用して顧客リソースにアクセスします。
2. 承認プロセスを通じてアクセスをリクエストします。
3. Hubアカウントを介して一時的なIAMロールを引き受けます。

Hubアカウントとテナントアカウントのすべてのアクションは、CloudTrailにログ記録されます。

モニタリング

テナントアカウントでは、GitLab Dedicatedは以下を使用します:

• 侵入検出およびマルウェアスキャン用のAWS GuardDuty。
• 異常なイベントを検出するためのGitLabセキュリティインシデント対応チームによるインフラストラクチャログのモニタリング。

監査と可観測性

監査と可観測性のために、アプリケーションログにアクセスできます。これらのログは、システムのアクティビティーとユーザーアクションに関するインサイトを提供し、インスタンスのモニタリングとコンプライアンス要件の維持に役立ちます。

独自のドメインの使用

デフォルトのtenant_name.gitlab-dedicated.com URLの代わりに、独自のカスタムドメインを使用してGitLab Dedicatedインスタンスにアクセスできます。たとえば、gitlab.company.comを使用してインスタンスにアクセスできます。

カスタムドメインは、次のような場合に使用します:

• URLを変更せずに、既存のSelf-Managedインスタンスから移行する。
• 組織のツール全体で一貫したブランドを維持します。
• 既存の証明書管理またはドメインポリシーと統合します。

Kubernetes用メインGitLabインスタンス、バンドルされたコンテナレジストリ、およびKubernetes向けGitLabエージェントサーバーにカスタムドメインを構成できます。

詳細については、独自のドメインの使用（BYOD）を参照してください。

オブジェクトストレージのダウンロード

デフォルトでは、GitLab Dedicatedは、最適なパフォーマンスを得るために、S3からの直接ダウンロードを有効にします（proxy_download = false）。直接ダウンロードをサポートするオブジェクトタイプは次のとおりです:

• CI/CDジョブアーティファクト
• 依存プロキシファイル
• マージリクエストの差分
• Git Large File Storage (LFS)オブジェクト
• プロジェクトパッケージ（例: PyPI、Maven、NuGet）
• コンテナレジストリコンテナ
• ユーザーアップロード

上記のオブジェクトタイプのいずれかをダウンロードすると、ブラウザまたはクライアントは、GitLabインフラストラクチャを経由するのではなく、Amazon S3に直接接続します。

ネットワークセキュリティポリシーでS3エンドポイントへの直接アクセスが禁止されている場合は、GitLabインフラストラクチャを介してプロキシされたダウンロードをリクエストできます。この構成（proxy_download = true）により、すべてのダウンロードがGitLab Dedicatedインスタンスを経由してルーティングされるようになります。

プロキシされたダウンロードをリクエスト

プロキシされたダウンロードをリクエストするには:

1. ユースケースの詳細を添えて、アカウントエグゼクティブに連絡してください。
2. ネットワークセキュリティ要件に関する情報を記載してください。
3. プロキシアクセスが必要なオブジェクトタイプを指定します。

詳細については、プロキシダウンロードを参照してください。

アプリケーション

GitLab Dedicatedには、例外が少数あるSelf-ManagedインスタンスのUltimate機能セットが付属しています。詳細については、利用できない機能を参照してください。

高度な検索

GitLab Dedicatedは、高度な検索機能を使用します。

ClickHouse

ClickHouseインテグレーションを介して、高度な分析機能にアクセスできます。これは、対象となる顧客に対してデフォルトで有効になっています。次の場合は対象となります:

• GitLab Dedicatedテナントが商用AWSリージョンにデプロイされている。政府機関向けGitLab Dedicatedはサポートされていません。
• テナントのプライマリリージョンがClickHouse Cloudでサポートされている。サポートされているリージョンのリストについては、ClickHouse Cloudでサポートされているリージョンを参照してください。

ClickHouseは、GitLab Dedicatedインスタンスのセカンダリデータストアとして機能し、高度な分析機能を有効にします。

GitLab Dedicatedインスタンスには、テナントのプライマリリージョンにデプロイされたClickHouse Cloudデータベースが含まれています。データベースはパブリックにアクセスできず、AWS PrivateLinkを介して接続します。データは、クラウドプロバイダー管理のAES 256キーと透過的なデータ暗号化を使用して、転送時および保存時に暗号化されます。GitLab Dedicatedインスタンスを構成して送信リクエストをフィルタリングすると、ClickHouseエンドポイントアドレスが自動的に許可リストに追加されます。

GitLab DedicatedのClickHouseには、次の制限があります:

• 独自のキー（BYOK）の使用はサポートされていません。
• SLAは適用されません。目標リカバリー時間（RTO）と目標リカバリー時点（RPO）は、ベストエフォートです。

GitLab Pages

GitLab DedicatedでGitLab Pagesを使用して、静的Webサイトをホストできます。GitLab Pagesはデフォルトで有効になっています。

Webサイトはドメインtenant_name.gitlab-dedicated.siteを使用します。tenant_nameはインスタンスのURLと一致します。

以下を使用して、Webサイトへのアクセスを制御します:

• GitLab Pagesアクセス制御
• IP許可リスト

既存のIP許可リストがGitLab PagesWebサイトに適用されます。

ディザスターリカバリー中にフェイルオーバーが発生した場合、サイトはセカンダリリージョンから引き続き動作します。

ホストされるRunner

GitLab Dedicated用ホストランナーを使用すると、メンテナンスのオーバーヘッドなしでCI/CDワークロードをスケールできます。

Self-Managed Runner

ホストランナーを使用する代わりに、GitLab Dedicatedインスタンスに独自のランナーを使用できます。

セルフマネージドランナーを使用するには、所有または管理するインフラストラクチャにGitLab Runnerをインストールします。

OpenID ConnectとSCIM

インスタンスへのIP許可リスト制限を維持しながら、ユーザー管理にSCIMを使用したり、OpenID ConnectIDプロバイダーとしてのGitLabを使用したりできます。

IP許可リストでこれらの機能を使用するには:

• IP許可リストのSCIMプロビジョニングを有効にする
• IP許可リストのOpenID Connectを有効にする

プレ本番環境

GitLab Dedicatedは、本番環境の設定に一致するプレ本番環境をサポートしています。プレ本番環境を使用して、次のことができます:

• 本番環境に実装する前に、新機能をテストします。
• 本番環境に適用する前に、設定の変更をテストします。

プレ本番環境は、追加のライセンスを必要とせずに、GitLab Dedicatedサブスクリプションのアドオンとして購入する必要があります。

次の機能を使用できます:

• 柔軟なサイジング: 本番環境のサイズに一致させるか、より小さいリファレンスアーキテクチャを使用します。
• バージョンの一貫性: 本番環境と同じGitLabのバージョンを実行します。

制限事項:

• シングルリージョンデプロイのみ。
• SLAのコミットメントはありません。
• 本番環境よりも新しいバージョンを実行できません。

利用できない機能

このセクションでは、GitLab Dedicatedで使用できない機能を示します。

認証、セキュリティ、およびネットワーキング

コミュニケーションとコラボレーション

開発およびAI機能

AI機能の詳細については、GitLab Duoを参照してください。

機能フラグ

GitLabは、新しい機能や試験的な機能の開発とロールアウトをサポートするために、機能フラグを使用します。GitLab Dedicated:

• デフォルトで有効になっている機能フラグの背後にある機能は使用できます。
• デフォルトで無効になっている機能フラグの背後にある機能は使用できず、管理者が有効にすることもできません。

デフォルトで無効になっているフラグの背後にある機能は、本番環境での使用準備ができていないため、GitLab Dedicatedでは安全ではありません。

機能が一般的に使用可能になり、フラグが有効になるか削除されると、その機能は同じバージョンのGitLab Dedicatedで使用できるようになります。GitLab Dedicatedは、バージョンのデプロイに関する独自のリリーススケジュールに従います。

GitLab Pages

運用機能

以下の運用機能は利用できません:

• デフォルトのセカンダリリージョンを超えるGeoレプリケーション用の複数のセカンダリリージョン
• Geoプロキシと統合URLの使用
• セルフサービスによる購入と設定
• GCPやAzureなど、AWS以外のクラウドプロバイダーへのデプロイのサポート
• スイッチボードの可観測性ダッシュボード（GrafanaやOpenSearchなど）

サーバーアクセスを必要とする機能

次の機能は、サーバーへの直接アクセスが必要であり、設定できません:

サービスレベルの可用性

GitLab Dedicatedは、月間サービスレベル目標99.5%の可用性を維持します。

サービスレベルの可用性は、GitLab Dedicatedが1か月間に使用できる時間の割合を測定します。GitLabは、次のコアサービスに基づいて可用性を計算します:

サービスレベルの除外

以下は、サービスレベルの可用性の計算には含まれていません:

• 顧客の設定ミスが原因で発生したサービスの停止
• GitLabの制御外にある顧客またはクラウドプロバイダーのインフラストラクチャに関するイシュー
• スケジュールされたメンテナンス期間
• 重大なセキュリティまたはデータのイシューに対する緊急メンテナンス
• 自然災害、広範囲にわたるインターネット停止、データセンターの故障、またはGitLabの制御外にあるその他のイベントによって発生したサービスの停止。

GitLab Dedicatedへの移行

データをGitLab Dedicatedに移行するには:

• 別のGitLabインスタンスから:
  • 直接転送を使用します。
  • ダイレクト転送APIを使用します。
• サードパーティサービスから:
  • インポート元を使用します。
• 複雑な移行の場合:
  • プロフェッショナルサービスを利用します。

期限切れのサブスクリプション

サブスクリプションの有効期限が切れる前に、終了日が近づいているという通知が届きます。

サブスクリプションの有効期限が切れると、30日間インスタンスにアクセスできます。

データを保持するには、アカウントチームに連絡するか、有効期限から15日以内にサポートにメールで連絡して、データの保持をリクエストしてください。

この30日間の期間中に、次のことができます:

• メールサポートに連絡して、データを取得するための追加時間をリクエストします。
• プロフェッショナルサービスを利用して、移行の支援やオフボーディングのサポートを受けます。

30日後、データがアーカイブされていない場合、または別のインスタンスに移行されていない場合、インスタンスは終了し、すべてのお客様コンテンツが削除されます。これには、すべてのプロジェクト、リポジトリ、イシュー、マージリクエスト、およびその他のデータが含まれます。

インスタンスの終了後90日後に、アカウント削除の確認をリクエストできます。確認は、アカウントが閉じられたことを示すAWSからのメールとして提供されます。

始める

GitLab Dedicatedの詳細、またはデモをリクエストするには、GitLab Dedicatedを参照してください。

GitLab Dedicatedインスタンスの設定の詳細については、GitLab Dedicatedインスタンスの作成を参照してください。