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

次のGeo機能セットのセキュリティレビューでは、独自のGitLabインスタンスを実行している顧客に適用される、この機能のセキュリティ面に焦点を当てています。レビューの質問は、OWASPアプリケーションセキュリティ検証標準プロジェクト （owasp.org）の一部に基づいています。

ビジネスモデル

アプリケーションサービスはどの地域を対象としていますか？

• これは顧客によって異なります。Geoを使用すると、顧客は複数の領域にデプロイでき、顧客はデプロイ場所を選択できます。
• 地域とノードの選択は完全に手動です。

データエッセンシャル

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

• Geoは、GitLabインスタンスが保持するほぼすべてのデータをサイト間で同期します。これには、完全なデータベースレプリケーション、ユーザーがアップロードした添付ファイルなどのほとんどのファイル、リポジトリ + Wikiデータが含まれます。一般的な設定では、これはパブリックインターネット経由で行われ、TLSで暗号化された状態になります。
• PostgreSQLレプリケーションはTLSで暗号化された状態になります。
• 参考：TLSv1.2のみをサポートする必要があります

データの機密性に応じて、データをカテゴリに分類するにはどうすればよいですか？

• GitLabの機密性モデルは、パブリック、内部、プライベートのプロジェクトを中心としています。Geoは、それらをすべて無差別にレプリケートします。「選択的同期」は、ファイルとリポジトリ（ただしデータベースコンテンツではない）に存在し、必要に応じて、機密性の低いプロジェクトのみをセカンダリサイトにレプリケートすることを許可します。

アプリケーションに定義されているデータのバックアップと保持の要件は何ですか？

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

エンドユーザー

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

• セカンダリサイトは、（インターネットレイテンシーに関して）メインのGitLabインストール（プライマリサイト）から遠い地域に作成されます。これらは、通常のプライマリサイトを使用するすべての人、つまり、セカンダリサイトが（インターネットレイテンシーに関して）自分に近いと感じる人が使用することを目的としています。

エンドユーザーはアプリケーションとどのように対話しますか？

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

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

• レプリケーションプロセスは安全である必要があります。たとえば、データベースの内容全体またはすべてのファイルとリポジトリをパブリックインターネット経由で平文で送信することは、通常は容認できません。
• セカンダリサイトは、プライマリサイトと同じコンテンツに対するアクセス制御を持つ必要があります。認証されていないユーザーは、プライマリサイトの特権情報にセカンダリサイトにクエリを実行してアクセスできるようになってはなりません。
• 攻撃者は、セカンダリサイトになりすましてプライマリサイトにアクセスし、特権情報にアクセスできるようになってはなりません。

管理者

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

• 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-ED2などの「フルマシン」アプローチと、AWS-RDSやAzureなどの「ホストされたデータベース」アプローチ

環境

アプリケーションの作成には、どのようなフレームワークとプログラミング言語が使用されていますか？

• Ruby on Rails、Ruby。

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

• Geoに固有のものはありません。

どのようなデータベースとアプリケーションサーバーがアプリケーションをサポートしていますか？

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

データベース接続文字列、暗号化キー、およびその他の機密コンポーネントを保護するにはどうすればよいですか？

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

データ処理

アプリケーションはどのようなデータエントリパスをサポートしていますか？

• データは、GitLab自体が公開しているWebアプリケーションを介してエントリされます。一部のデータは、GitLabサーバー上のシステム管理コマンド（たとえば、gitlab-ctl set-primary-node）を使用してエントリすることもできます。
• セカンダリサイトは、プライマリサイトからのPostgreSQLストリーミングレプリケーションを介して入力も受信します。

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

• プライマリサイトは、PostgreSQLストリーミングレプリケーションを介してセカンダリサイトに出力します。それ以外の場合は、主にGitLab自体が公開するWebアプリケーションを介して、およびエンドユーザーが開始したSSH git clone操作を介して行われます。

アプリケーションの内部コンポーネント全体でデータはどのようにトラフィックしますか？

• セカンダリサイトとプライマリサイトは、HTTP/HTTPS（JSON Webトークンで保護）およびPostgreSQLストリーミングレプリケーションを介して相互作用します。
• プライマリサイトまたはセカンダリサイト内では、SSOTは、ファイルシステムとデータベース（セカンダリサイトのGeoトラッキングデータベースを含む）です。さまざまな内部コンポーネントがオーケストレーションを行い、これらのストアに変更を加えます。

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

• セカンダリサイトは、プライマリサイトのデータの忠実なレプリケーションを持っている必要があります。

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

• Gitリポジトリとファイル、それらに関連する追跡情報、およびGitLabデータベースの内容。

どのようなデータを暗号化する必要がありますか？どのようなキー管理要件が定義されていますか？

• プライマリサイトもセカンダリサイトも、保存時にGitリポジトリまたはファイルシステムのデータを暗号化しません。データベース列のサブセットは、db_otp_keyを使用して保存時に暗号化されます。
• GitLabデプロイ内のすべてのホスト間で共有される静的なシークレット。
• 転送時、データは暗号化された状態である必要がありますが、アプリケーションは暗号化されていない通信の続行を許可します。2つの主な転送は、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インストールにインジェストすることもできます。