ハードニング - 設定推奨事項

一般的なハードニングのガイドラインは、ハードニングに関する主な文書に概説されています。

GitLabインスタンスに対するいくつかの堅牢化の推奨事項には、設定ファイルによる追加サービスや制御が含まれます。注意点として、設定ファイルに変更を加える場合は、編集する前にバックアップを取っておきましょう。さらに、多くの変更を行う場合は、一度にすべての変更を行わず、変更のたびにテストを行ってすべてが機能していることを確認することをお勧めします。

NGINX

NGINXは、GitLabインスタンスへのアクセスに使用されるウェブインターフェースを提供するために使用されます。NGINXはGitLabにコントロールされインテグレーションされているため、/etc/gitlab/gitlab.rb 。NGINX自体のセキュリティを向上させるための推奨事項をいくつか紹介します：

  1. Diffie-Hellmanキーを作成します：

    sudo openssl dhparam -out /etc/gitlab/ssl/dhparam.pem 4096

  2. /etc/gitlab/gitlab.rb を編集し、以下を追加します：

    #
# Only strong ciphers are used
#
nginx['ssl_ciphers'] = "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256"
#
# Follow preferred ciphers and the order listed as preference
#
nginx['ssl_prefer_server_ciphers'] = "on"
#
# Only allow TLSv1.2 and TLSv1.3
#
nginx['ssl_protocols'] = "TLSv1.2 TLSv1.3"
   
##! **Recommended in: https://nginx.org/en/docs/http/ngx_http_ssl_module.html**
nginx['ssl_session_cache'] = "builtin:1000  shared:SSL:10m"
   
##! **Default according to https://nginx.org/en/docs/http/ngx_http_ssl_module.html**
nginx['ssl_session_timeout'] = "5m"
   
# Should prevent logjam attack etc
nginx['ssl_dhparam'] = "/etc/gitlab/ssl/dhparams.pem" # changed from nil
   
# Turn off session ticket reuse
nginx['ssl_session_tickets'] = "off"
# Pick our own curve instead of what openssl hands us
nginx['ssl_ecdh_curve'] = "secp384r1"

  3. GitLab を再設定します：

    sudo gitlab-ctl reconfigure

Consul

ConsulはGitLab環境にインテグレーションすることができ、大規模なデプロイを想定しています。一般的に、セルフマネジメントやスタンドアロンで1000ユーザー以下のデプロイでは、Consulは必要ないかもしれません。Consulが必要な場合は、まずConsulのドキュメントをレビューし、さらに重要なこととして、通信中に暗号化が使用されていることを確認してください。Consulのより詳細な情報については、HashiCorpのウェブサイトをご覧ください。

環境変数

自己管理システムでは、複数の環境変数をカスタマイズできます。セキュリティの観点から利用すべき主な環境変数は、インストールプロセス中のGITLAB_ROOT_PASSWORD です。インターネットに公開された IP アドレスで自己管理システムをインストールする場合、パスワードが強力なものに設定されていることを確認してください。歴史的に、GitLabであろうと他のアプリケーションであろうと、どのような種類の公開サービスをセットアップしても、そのようなシステムが発見されるとすぐに日和見的な攻撃が起こることがわかっています。

オペレーティング・システムの推奨事項で述べたように、理想的にはGitLabのインストールが始まる前にすでにファイアウォール・ルールが設定されているべきですが、それでも、GITLAB_ROOT_PASSWORDを通してインストールの前に安全なパスワードを設定すべきです。

Git プロトコル

作成者だけがSSHを使ってGitにアクセスできるようにするには、/etc/ssh/sshd_config ：

# Ensure only authorized users are using Git
AcceptEnv GIT_PROTOCOL

これにより、SSHでgit オペレーションを実行できる有効なGitLabアカウントを持っていない限り、ユーザーはSSHを使ってプロジェクトをプルダウンできないようになります。詳細はGitプロトコルの設定にあります。

受信メール

GitLabセルフマネージドインスタンスでは、GitLabインスタンスに登録したユーザーによるコメントやイシューの作成、マージリクエストに受信メールを使用できるように設定することができます。ハード化された環境では、外部からの通信が情報を送信することになるため、この機能を設定すべきではありません。

この機能が必要な場合は、受信メールのドキュメントの指示に従ってください。セキュリティを最大限に確保するために、以下のことを推奨します：

Redisのレプリケーションとフェイルオーバー

Redisは、レプリケーションとフェイルオーバーのためにLinuxパッケージインストールで使用され、スケーリングがその機能を必要とする場合に設定できます。Redis用にTCPポート6379 、Sentinel用にTCPポート26379 。レプリケーションとフェイルオーバーのドキュメントに従いますが、すべてのノードのIPアドレスを記録し、他のノードが特定のポートにアクセスすることのみを許可するようにノード間でファイアウォールルールを設定します。

Sidekiqの設定

外部Sidekiqの設定手順には、IP範囲の設定に関する記述が多数あります。HTTPSを設定し、Sidekiqが通信する特定のシステムにこれらのIPアドレスを制限することを検討する必要があります。オペレーションシステムレベルのファイアウォールルールも調整する必要があるかもしれません。

電子メールのS/MIME署名

GitLabインスタンスがユーザーにEメール通知を送信するように設定されている場合は、受信者がEメールが正当なものであることを確認できるようにS/MIME署名を設定します。送信メールへの署名に関する指示に従ってください。

コンテナレジストリ

Lets Encryptが設定されている場合、コンテナレジストリはデフォルトで有効になっています。これにより、プロジェクトは独自のDockerイメージを保存できるようになります。コンテナレジストリの設定手順に従って、新しいプロジェクトでの自動有効化を制限したり、コンテナレジストリを完全に無効にしたりすることができます。アクセスを許可するためにファイアウォールルールを調整する必要があるかもしれません - 完全にスタンドアロンシステムの場合、コンテナレジストリへのアクセスをlocalhostのみに制限する必要があります。使用するポートとその設定の具体例もドキュメントに含まれています。