Geoセキュリティレビュー（Q&A）

以下の Geo 機能セットのセキュリティレビューは、GitLab インスタンスを運用しているお客様に適用される機能のセキュリティ面に焦点を当てています。レビュアーは、owasp.org のOWASP Application Security Verification Standard Projectに基づいています。

ビジネスモデル

そのアプリケーションがサービスを提供する地域は？

  • これはお客様によって異なります。Geoでは、複数の地域にデプロイすることができ、お客様はその地域を選択することができます。
  • 地域とノードの選択はすべて手動です。

データエッセンシャル

アプリケーションはどのようなデータを受け取り、生成し、処理しますか？

  • Geo は GitLab インスタンスが保持するほぼ全てのデータをサイト間でストリームします。これには、データベースの完全なレプリケーション、ユーザーがアップロードした添付ファイルのようなほとんどのファイル、リポジトリと Wiki のデータが含まれます。典型的な設定では、これは公開インターネット上で行われ、TLSで暗号化されます。
  • PostgreSQLのレプリケーションはTLSで暗号化されています。
  • TLSv1.2のみをサポートすべきです。

データの機密性に応じて、データをどのように分類できますか？

  • GitLabの感度のモデルは、公開プロジェクト対内部プロジェクト対非公開プロジェクトが中心です。Geoはそれらすべてを無差別にレプリケートします。ファイルやリポジトリには “Selective sync”（選択的同期）があり（データベースのコンテンツにはありません）、必要であれば、機密性の低いプロジェクトだけをセカンダリサイトにレプリケートすることができます。
  • こちらもご覧ください：GitLabデータ分類ポリシー。

アプリケーションに対して、どのようなデータのバックアップと保持の要件が定義されていますか？

  • Geo は、アプリケーションデータの特定のサブセットのレプリケーションを提供するように設計されています。問題の一部ではなく、ソリューションの一部です。

エンドユーザー

アプリケーションのエンドユーザーは誰ですか？

  • セカンダリサイトは、GitLabのメインインストール（プライマリサイト）から（インターネットレイテンシの点で）離れた地域に作成されます。セカンダリ・サイトは、通常プライマリ・サイトを利用する人が、セカンダリ・サイトの方が（インターネットのレイテンシの点で）近いと判断した場合に利用することを想定しています。

エンドユーザーはどのようにアプリケーションとやりとりするのでしょうか？

  • セカンダリサイトは、プライマリサイトが提供するすべてのインターフェイス（特に HTTP/HTTPS ウェブアプリケーションと HTTP/HTTPS または SSH による Git リポジトリへのアクセス）を提供しますが、読み取り専用のアクティビティに制限されます。主なユースケースは、プライマリサイトを優先してセカンダリサイトからGit リポジトリをクローンすることですが、エンドユーザーは GitLab ウェブインタフェースを使ってプロジェクト、イシュー、マージリクエスト、スニペットなどの情報を見ることができます。

エンドユーザーはどのようなセキュリティを期待していますか？

  • レプリケーション・プロセスはセキュリティで保護されていなければなりません。例えば、データベースの全コンテンツや、すべてのファイルやリポジトリを平文で公開インターネットに送信することは、通常受け入れられません。
  • セカンダリ・サイトは、プライマリ・サイトと同じようにコンテンツへのアクセス制御を行わなければなりません。認証されていないユーザーが、セカンダリ・サイトにクエリを行ってプライマリ・サイトの特権情報にアクセスすることはできません。
  • 攻撃者がセカンダリ・サイトから プライマリ・サイトになりすまし、特権情報にアクセスできないこと。

管理者

アプリケーションの管理者は誰ですか？

  • Geo 固有のものではありません。データベースでadmin: true が設定されているユーザーは、スーパーユーザー権限を持つ管理者とみなされます。
  • より詳細なアクセス制御（Geo 固有ではない）も参照してください。
  • Geo のインテグレーション(例えばデータベースのレプリケーション)の多くは、通常システム管理者 がアプリケーションと共に設定する必要があります。

アプリケーションにはどのような管理機能がありますか？

  • セカンダリサイトは、管理者権限を持つユーザーによって追加、変更、削除することができます。
  • レプリケーション・プロセスは、Sidekiq管理コントロールにより制御（開始/停止）できます。

ネットワーク

ルーティング、スイッチング、ファイアウォール、ロードバランシングに関する詳細はどのように定義されていますか？

  • Geo では、プライマリサイトと セカンダリサイトがTCP/IP ネットワークを介して相互に通信できる必要があります。特に、セカンダリサイトは プライマリサイトのHTTP/HTTPS と PostgreSQL サービスにアクセスできなければなりません。

アプリケーションをサポートするコア・ネットワーク・デバイスは？

  • お客様によって異なります。

どのようなネットワーク・パフォーマンス要件がありますか？

  • プライマリサイトと セカンダリサイト間の最大レプリケーション速度は、サイト間で利用可能な帯域幅によって制限されます。レプリケーション完了までの時間（およびプライマリサイトの変更に追従する能力）は、データセットのサイズ、待ち時間に対する耐性、および利用可能なネットワーク容量の関数です。
  • ネットワークはお客様が自由に選択できます。サイトは地理的に離れていることを想定しているため、一般的なデプロイではレプリケーション・トラフィックが公開インターネットを通過することを想定していますが、これは必須条件ではありません。

システム

アプリケーションをサポートするオペレーティングシステムは？

  • Geoはオペレーティングシステムに関する追加的な制限を課していません（詳しくはGitLabのインストールページをご覧ください）が、Geoのドキュメントに記載されているオペレーティングシステムの使用を推奨しています。

必要な OS コンポーネントやロックダウンの必要性に関する詳細はどのように定義されていますか？

  • サポートされているLinuxパッケージのインストール方法は、ほとんどのコンポーネントを自らパッケージ化します。
  • システムにインストールされた OpenSSH デーモン (Geo はユーザがカスタム認証方法を設定する必要があります) と、Linux パッケージ提供またはシステム提供の PostgreSQL デーモン (TCP をリッスンするように設定する必要があります、ユーザとレプリケーションスロットを追加する必要があります、など) には大きな依存性があります。
  • セキュリティアップデートに対処するためのプロセス（例えば、OpenSSH やその他のサービスに重大な脆弱性があり、ユーザーが OS 上でそれらのサービスにパッチを当てたい場合）は、Geo を使用しない場合と同じです。OpenSSH のセキュリティアップデートは、通常のディストリビューションチャネルを通じてユーザーに提供されます。Geo はそこに遅れをもたらしません。

インフラモニタリング

どのようなネットワークとシステムのパフォーマンス監視要件が定義されていますか？

  • Geoに特化したものはありません。

悪意のあるコードや侵害されたアプリケーションコンポーネントを検出するためのメカニズムはありますか？

  • Geoに特化したものはありません。

どのようなネットワークとシステムのセキュリティ監視要件が定義されていますか？

  • Geoに特化したものはありません。

仮想化と外部化

アプリケーションのどの部分が仮想化に適していますか？

  • すべてです。

アプリケーションにはどのような仮想化要件が定義されていますか？

  • Geoに特化したものはありませんが、GitLabのすべてがそのような環境で完全に機能する必要があります。

製品のどの部分がクラウド・コンピューティング・モデルでホスティングされるのでしょうか、されないのでしょうか？

  • GitLabは “クラウドネイティブ “であり、これは製品の他の部分と同様にGeoにも当てはまります。クラウドでのデプロイは一般的で、サポートされているシナリオです。

該当する場合、クラウドコンピューティングに対してどのようなアプローチ（マネージドホスティング対 “ピュア “クラウド、AWS-EC2 のような “フルマシン “アプローチ対 AWS-RDS や Azure のような “ホステッドデータベース “アプローチなど）を取っていますか？

  • お客様のオペレーションニーズに応じて決定します。

環境

アプリケーションを作成するために、どのようなフレームワークやプログラミング言語が使用されましたか？

  • Ruby on Rails、Rubyです。

アプリケーションにはどのようなプロセス、コード、インフラストラクチャの依存関係が定義されていますか？

  • Geoには特にありません。

そのアプリケーションをサポートしているデータベースとアプリケーションサーバーは何ですか？

  • PostgreSQL >= 12、Redis、Sidekiq、Puma。

データベース接続文字列、暗号化キー、その他の機密コンポーネントをどのように保存し、アクセスし、不正な検出から保護することができますか？

  • Geo 固有の値がいくつかあります。いくつかの値は共有シークレットであり、セットアップ時にプライマリサイトからセカンダリサイトに安全に送信する必要があります。当社のドキュメントでは、プライマリサイトからSSH 経由でシステム管理者に送信し、同じ方法でセカンダリサイトに戻すことを推奨しています。特に、これにはPostgreSQLのレプリケーション認証情報と、db_key_baseデータベースの特定の列を復号化するために使用 db_key_baseする秘密鍵（）が含まれます。db_key_baseこの db_key_baseシークレットはファイルシステム上の/etc/gitlab/gitlab-secrets.json、他の多くのシークレットと一緒に暗号化されずに保存されます。これらの秘密鍵はファイルシステム上に暗号化されずに保存されます。

データ処理

アプリケーションはどのようなデータ入力経路をサポートしていますか？

  • データはGitLab自身が公開しているウェブアプリケーションから入力します。また、GitLabサーバーのシステム管理コマンド（例えばgitlab-ctl set-primary-node）を使って入力されるデータもあります。
  • セカンダリサイトはまた、プライマリサイトからPostgreSQLストリーミングレプリケーション経由で入力を受け取ります。

アプリケーションはどのようなデータ出力経路をサポートしていますか?

  • プライマリ・サイトはPostgreSQL ストリーミング・レプリケーションでセカンダリ・サイトに出力します。それ以外では、主にGitLab自身によって公開されたウェブアプリケーションと、エンドユーザーによって開始されたSSHgit clone オペレーションを経由します。

アプリケーション内部でのデータの流れは？

  • セカンダリサイトと プライマリサイトは、HTTP/HTTPS（JSONウェブトークンでセキュリティ保護）とPostgreSQLストリーミングレプリケーションを介してやり取りします。
  • プライマリサイトまたはセカンダリサイト内では、SSOTはファイルシステムとデータベース（セカンダリサイトのGeoトラッキングデータベースを含む）です。様々な内部コンポーネントは、これらのストアに変更を加えるためにオーケストレーションされます。

どのようなデータ入力検証要件が定義されていますか？

  • セカンダリー・サイトは、プライマリー・サイトのデータを忠実に複製する必要があります。

アプリケーションはどのデータをどのように保存しますか？

  • Gitリポジトリとファイル、それらに関連するトラッキング情報、GitLabデータベースの内容。

どのようなデータが暗号化されているか、あるいは暗号化する必要があるか、そしてどのような鍵管理要件が定義されていますか？

  • プライマリー・サイトも セカンダリー・サイトも、Git リポジトリやファイル・システムのデータを静止時に暗号化することはありません。データベース・カラムのサブセットは、db_otp_key を使って静止時に暗号化されます。
  • GitLabデプロイの全ホストで共有される静的なシークレット。
  • トランジットでは、データは暗号化されるべきですが、アプリケーションは暗号化されていない通信を許可します。セカンダリサイトのPostgreSQLのレプリケーションとGitリポジトリ/ファイルのレプリケーションです。どちらもTLSを使って保護すべきです。そのための鍵は、GitLabへのエンドユーザーアクセスの既存の設定に従ってLinuxパッケージが管理します。

機密データの漏えいを検知する機能はありますか？

  • 包括的なシステムログが存在し、GitLabとPostgreSQLへのすべての接続を追跡します。

WAN、LAN、SecureFTP、http:やhttps:のような公開プロトコルでの送信を含め、送信中のデータにはどのような暗号化要件が定義されていますか？

  • データは転送中に暗号化されるオプションがあり、受動的攻撃と能動的攻撃の両方に対してセキュリティが確保されていなければなりません（例えば、MITM攻撃は不可能でなければなりません）。

アクセス

アプリケーションはどのユーザー権限レベルをサポートしていますか？

  • Geo は 1 種類の特権を追加します:セカンダリサイトは特別な Geo API にアクセスし、HTTP/HTTPS を使ってファイルをダウンロードしたり、HTTP/HTTPS を使ってリポジトリをクローンしたりできます。

どのようなユーザー識別および認証要件が定義されていますか？

  • セカンダリサイトは、共有データベース（HTTPアクセス）またはPostgreSQLレプリケーションユーザー（データベースレプリケーション用）に基づいて、OAuthまたはJWT認証を介してプライマリサイトをGeoに識別します。データベースのレプリケーションでは、IP ベースのアクセス制御も定義する必要があります。

どのようなユーザー認証要件が定義されていますか？

  • セカンダリー・サイトはデータの読み込みのみが可能でなければなりません。現在のところ、プライマリ・サイトのデータを変異させることはできません。

どのようなセッション管理要件が定義されていますか？

  • Geo JWT は、再生成が必要になるまで 2 分間しか持続しないと定義されています。
  • Geo JWTは、以下の特定のスコープのいずれかに対して生成されます：
    • Geo API アクセス。
    • Gitへのアクセス。
    • LFSとファイルID。
    • アップロードとファイルID
    • ジョブアーティファクトとファイルID。

URIとサービス呼び出しにはどのようなアクセス要件が定義されていますか？

  • セカンダリ・サイトは、プライマリ・サイトのAPIに対して多くのコールを行います。例えば、ファイルのレプリケーションがそうです。このエンドポイントには、JWTトークンでのみアクセスできます。
  • プライマリ・サイトはまた、ステータス情報を得るためにセカンダリ・サイトを呼び出します。

アプリケーションの監視

どのようなアプリケーション監査要件が定義されていますか？監査ログとデバッグログはどのようにアクセス、保存、セキュリティ保護されますか?

  • 構造化された JSON ログがファイルシステムに書き込まれ、さらに分析するために Kibana インストールに取り込むこともできます。