GitLab Dedicatedが支える、新たな規制時代のコンプライアンス

NIS2をはじめとする規制の執行は、もはや将来の検討課題ではありません。欧州連合サイバーセキュリティ機関（ENISA）のNIS360レポートが示すとおり、監督当局はすでに重要セクター全体でサイバーセキュリティ成熟度の評価に着手しています。ガイダンスや助言の段階から、監督・精査・説明責任の追及へ。欧州企業が今まさに置かれているのは、こうした規制環境です。

マルチテナント型のクラウドプラットフォームは運用負荷を取り除きます。しかし、ソースコードとパイプラインが置かれるのは、いま規制当局が最も目を光らせている共有インフラ。Self-Managedであれば分離は確保できるものの、アップグレードサイクル、セキュリティパッチ、ディザスタリカバリ（DR）テストの責任は、すでに手一杯のプラットフォームチームが負うことになります。リスク管理、データ主権、監査エビデンスの提出。いずれの導入形態にも、こうした領域に穴が残ります。

本記事では、こうした課題にGitLab Dedicatedがどう応え、変化し続けるコンプライアンス要件への追随をどう支えるのかを解説します。GitLab Dedicatedは、ご希望のAmazon Web Services（AWS）リージョンに展開され、GitLabがホスティングと運用を担う、完全に分離されたシングルテナントSaaSです。

「NatWest Groupは、エンジニアが共通のクラウドエンジニアリングプラットフォームを利用できるよう、GitLab Dedicated SaaSの導入を進めています。高品質な自動テスト、オンデマンドのインフラ、一気通貫のデプロイにより、お客様と従業員に向けた新たな成果を、迅速かつ高い頻度で、そして安全に提供していきます」

— NatWest Group エンジニアリングプラットフォーム部門 プラットフォームリード、Adam Leggett氏

規制が変化を迫っている

EUでは、いくつかの重要な規制が、プラットフォームのあり方そのものの見直しを迫っています。これらの規制が行き着く先は、多くの企業が規制の登場前に済ませてしまった1つの決定、すなわち「デベロッパーが開発の土台とするプラットフォームをどれにするか」という選択です。かつては純粋に技術的だった判断が、いまでは監査上の帰結を伴います。

1. デジタル・オペレーショナル・レジリエンス法（DORA）は、2025年1月にEUの金融サービス分野で発効しました。金融機関には、重要なテクノロジーの耐性維持、特定プロバイダーへの過度な依存の回避、インシデント報告体制の強化が求められます。
2. NIS2指令は2022年12月に採択され、必須セクターおよび重要セクターに対して、サイバーセキュリティの強化、テクノロジーサプライチェーンの保護、そして重大インシデントのEU域内当局への迅速な報告を義務付けています。
3. EU一般データ保護規則（GDPR）は2018年5月から適用されており、個人データの保護、保管場所とアクセス主体の文書化、利用ごとの適法な根拠の確保を組織に求めています。

共有インフラが抱える運用リスク

マルチテナント環境では、実行基盤、Runner、ストレージが共有されます。そのため、たった1件のCVE（共通脆弱性識別子）や設定ミスが、複数のテナントを同時に危険にさらしかねません。一方、Self-Managedではリスクが内部に集中。シークレットや認証情報は蓄積する一方で定期的なローテーションが行われず、インシデントのたびに手作業で加えられる変更がInfrastructure as Codeのベースラインからの構成ドリフトを生みます。結果として、本当のアタックサーフェス（攻撃対象領域）が監査からは見えなくなってしまいます。

GitLab Dedicatedは運用をコードで統制する

GitLab Dedicatedのインスタンスは、分離されたAWSアカウント内でサイト信頼性エンジニア（SRE）が運用します。SREは、お客様環境への直接アクセス権をデフォルトでは持ちません。運用上の変更はすべて、定義されたコントロールプレーンを経由する、自動化された承認ゲート付きのワークフローで実行されます。稼働中のシステムに人が直接手を入れることはありません。CI/CD変数やRunnerトークンは、お客様が定めたケイデンスでローテーションできます。コード化されたプロセスによって構成ドリフトを抑え、運用面の攻撃対象領域を厳格に管理し続けられる仕組みです。

ディザスタリカバリは、すべてのGitLab Dedicatedのお客様に標準で組み込まれています。各インスタンスにはバックアップを保持するセカンダリリージョンが用意され、2つのサイト間はGeoによる非同期の継続的レプリケーションで結ばれます。この構成が目指すのは、リージョン単位のクラウド障害の影響を最小限に抑え、お客様の事業継続を支えること。GitLab Dedicatedが提供するディザスタリカバリでは、次のリカバリー目標を定めています。

• 目標復旧時間（RTO）：セカンダリリージョンでのサービス復旧は8時間以内。
• 目標復旧時点（RPO）：データ損失は、直近のバックアップから障害発生までのタイミングに応じて、最大4時間分の変更に限定されます。

データ主権とお客様主導のセキュリティ管理

GDPRとデータ主権の観点から、監査担当者が明確な回答を求めるのは次の3点です。データの所在、アクセス権の所有者、そしてRunnerの通信が承認済みリージョンの外に出ていないかどうか。マルチテナント環境では、これらを握っているのはプロバイダー側であり、データが国境を越える可能性もあります。Self-Managedであれば、すべてを指定リージョン内に収めるために、ストレージポリシー、鍵管理、ネットワークルーティングを自社で定義しなければなりません。

GitLab Dedicatedは分離と統制を両立する

プロビジョニング時にリージョンを選択すると、オブジェクトストレージ、アーティファクト、コンピューティングのデータが、指定したAWSリージョンに固定されます。フェイルオーバー先となるセカンダリリージョンも同時に選択するため、リージョンをまたぐデータの移動は、その2リージョン間で明示的に有効化したレプリケーションのみ。EU域内のお客様であれば、両リージョンとも管轄区域内に収められます。フェイルオーバーはGitLabが管理し、定められたリカバリー目標（RTO・RPO）に沿って実施します。

BYOK（Bring Your Own Key）では、お客様が管理する鍵をプロビジョニング。鍵を失効させれば、GitLab側は暗号化されたデータにアクセスできません。AWS PrivateLinkはお客様のアカウント内にVPCエンドポイントを作成し、お客様のネットワーク、CI/CDジョブ、GitLab Dedicatedの間の通信はAWSのプライベートバックボーン内にとどまります。

ただし、インフラ層では解決できない制約が1つあります。これは主要なクラウドプロバイダーすべてに共通するものです。米国法人であるAmazon Web Servicesは、米国の法的義務の対象であり続けます。そこには、サーバーの物理的な所在地を問わずデータの開示を強制しうるCLOUD法（Clarifying Lawful Overseas Use of Data Act）も含まれます。

BYOKによって、GitLab層のリスクは解消されます。GitLabは鍵を保持せず、お客様のデータを復号できないためです。ただし、これによってAWSが負う米国法上の義務が変わるわけではありません。管轄区域に関する要件が厳しい組織では、インフラ面の統制とあわせて、法務・契約面から残余リスクに対処する必要があります。具体的には、データ処理契約、移転影響評価、そして移転の適法性を示す根拠の文書化です。

監査エビデンスの空白

マルチテナント型SaaSでは、ログやインシデントの記録が共有インフラ上に存在します。そのため、テナント固有のエビデンスを取り出すには、監査担当者はプロバイダーの協力を仰がなければなりません。Self-Managedの場合、監査上の最大のリスクはアップグレードの遅延によるCVEの放置です。リリースへの追随が遅れれば、ソースコードが置かれた環境に既知の脆弱性が残り続けます。単なるリソース不足よりも、監査担当者への説明がはるかに難しい状況といえます。

GitLabがコンプライアンス対応を簡素化する

GitLab DedicatedのSREが、あらかじめ定められた月次のアップグレードケイデンスでインスタンスを最新に保ちます。プラットフォームチームのバックログにチケットが積まれることはありません。インスタンスはN-1のマイナーリリースで稼働し、毎週固定のメンテナンス枠の中で、月に1回のマイナーリリースと2回のパッチリリースが適用されます。S1のセキュリティ問題については、この枠外で緊急メンテナンスを実施します。

セルフサービスポータルであるGitLabトラストセンターからは、GitLab Dedicatedの最新のコンプライアンス文書と保証関連資料を入手できます。たとえば、Schellman社による最新のDORA監査報告書もその1つ。すぐに使える監査報告書と一元管理されたエビデンスがあれば、規制当局への提出や年次レビューのたびに、Self-Managed環境の数年分の設定履歴をかき集めたり、共有された記録からデータを抽出したりする必要はありません。コンプライアンスチームとセキュリティチームは、監査対応への道筋を最小限の運用負荷で繰り返し再現できるようになります。

Dedicatedインスタンスの管理と運用をGitLabがどう簡素化するのか、クリックスルーデモでご確認ください。

GitLab Dedicatedへの移行

GitLab Dedicatedへの移行で得られるのは、セキュアでコンプライアンス対応のシングルテナントSaaSがもたらす、より広い選択肢とより確かな統制です。インフラのパッチ適用、可用性のエビデンス、DRテストはGitLabの監査スコープに移ります。提出のたびにインフラのエビデンスを組み立て直す必要はなくなり、自社チームはアプリケーション層の文書化と立証に専念できます。

GitLab Dedicatedがセキュリティとコンプライアンスの要件にどう応えるのか、ぜひデモでご確認ください。