Helix Swarm管理者ガイド (2020.1)

セキュリティ

Swarmのインストール環境は、さまざまな方法で保護することができます。 このセクションでは、Swarmが制御するセキュリティ機能に関するガイダンス情報と、Swarmをホストするシステムに関する推奨事項について説明します。

ヒント

構成情報を変更しても、構成キャッシュを再ロードしない限り、その構成情報がSwarmで使用されることはありません。構成キャッシュを再ロードすると、変更した構成情報がSwarmで強制的に使用されます。 Swarm構成キャッシュを再ロードするには、admin ユーザまたはsuper ユーザでなくてはなりません。 [ユーザID]ドロップダウンメニューに移動して[システム情報]を選択し、[キャッシュ情報]タブをクリックしてから[構成の再ロード]ボタンをクリックします。

ログインの強制

重要

リリース2016.1よりも前のSwarmの場合、require_loginのデフォルト値はfalseでした。 リリース2016.1以降のSwarmでは、デフォルト値がtrueになっています。

デフォルトでは、Swarmで匿名ユーザがHelixサーバのリソースを表示することはできません。コメントやレビューなどのリソースを表示するには、システムにログインする必要があります。

Swarmの設定を変更して、読み取り可能なリソースへのアクセスを匿名ユーザに対して許可することができます(リソースの作成や編集を匿名ユーザに対して許可することはできません)。 p4エントリと同じレベルで、以下の構成ブロックをSWARM_ROOT/data/config.phpファイルに追加します。

<?php
// this block should be a peer of 'p4'
'security' => array(
'require_login' => false, // defaults to true
),

例外として、匿名ユーザを含むすべてのユーザが/queue/workerエンドポイントを使用することができます。

注意

サービスユーザとオペレータユーザは、システムにログインすることはできません。 これらのユーザの詳細については、Helix Coreサーバ管理者ガイドの「ユーザタイプ」を参照してください。

ログインの禁止

Helixサーバのレプリカに関連するサービスユーザなど、Swarmへのログインを禁止したいユーザがHelixサーバ内に存在する場合、prevent_login構成項目を使用して、そうしたユーザの認証を禁止することができます。

p4エントリと同じレベルで、以下の構成ブロックをSWARM_ROOT/data/config.phpファイルに追加します(すでに追加されている場合は、以下のように変更します)。

<?php
// this block should be a peer of 'p4'
'security' => array(
'prevent_login' => array(
'service_user1',
'service_user2',
),
),

prevent_loginのデフォルト値はarray()です。この場合、Helixサーバ内のすべてのユーザがSwarmにログインすることができます。

詳細については、Helix Coreサーバ管理者ガイドの「サービスユーザ」を参照してください。

新しいユーザの自動作成

Swarmでは、Perforceにログインする新しいユーザを自動的に作成することができます。ただし、この機能がHelixサーバで許可されていて、LDAP内にユーザが存在している必要があります。 この機能はHelixサーバで設定します。Swarmで設定を行う必要はありません。 Perforceにログインする新規ユーザを自動的に作成するようにHelixサーバを設定する手順については、『Helix Coreサーバ管理者ガイド』の「LDAPに関連する構成可能変数を定義する」セクションに記載されているauth.ldap.userautocreateauth.default.methodを参照してください。

セッション

Swarmは、ブラウザ内のクッキーとサーバ上のPHPセッションストレージを使用して、ログインセッションを管理します。 Swarmでは、クッキーとセッションの有効期間(秒単位)について、適切なデフォルト値が使用されます。この有効期間を超えた場合は、再度ログインする必要があります。 セッションの有効期間とガベージコレクションの頻度を指定するには、p4エントリと同じレベルで、以下の構成ブロックをSWARM_ROOT/data/config.phpファイルに追加します。

<?php
// this block should be a peer of 'p4'
'session' => array(
'cookie_lifetime' => 0, // 0=expire when browser closed
'remembered_cookie_lifetime' => 60*60*24*30, // 30 days
'gc_maxlifetime' => 60*60*24*30, // 30 days
'gc_divisor' => 100, // 100 user requests
),
  • cookie_lifetime

    任意: セッションクッキーの有効期間を制限します。 デフォルト値は0です。この場合、ユーザがブラウザを終了したときに、セッションクッキーが期限切れになります。

    注意

    ログインダイアログ [ログイン情報を記憶]チェックボックスを選択すると、remembered_cookie_lifetimeの値がcookie_lifetimeで使用されます。

  • remembered_cookie_lifetime

    任意: ログインダイアログ[ログイン情報を記憶]チェックボックスを選択すると、セッションクッキーの有効期間を制限することができます。 デフォルト値は60*60*24*30秒(30日間)です。

  • gc_maxlifetime

    任意: 非アクティブなセッションのユーザをログアウトするまでの時間を秒単位で指定します。この時間が経過すると、ユーザがシステムからログアウトされます。 デフォルト値は60*60*24*30秒(30日間)です。 ユーザのセッションは、SWARM_ROOT/data/sessions/に保管されます。

    注意

    ユーザのPerforceチケットのデフォルトの有効期間は12時間です。この時間が経過した場合も、ユーザがシステムからログアウトされます。

  • gc_divisor

    任意: 発行されたユーザ要求の数に基づいて、ガベージコレクションの実行頻度を設定します。 設定値の範囲は1~100です。 ガベージコレクションを実行すると、gc_maxlifetime設定の値よりも古いユーザセッションファイルがSWARM_ROOT/data/sessions/から削除されます。

    • gc_divisor = 100: ユーザ要求が100件発行されるたびに、ガベージコレクションが実行されます。 100が、デフォルトの設定値です。
    • gc_divisor = 1: ユーザ要求が1件発行されるたびに、ガベージコレクションが実行されます。
    重要

    Swarmシステムのユーザ数が多い場合は、gc_divisorに低い値を設定すると、パフォーマンスが低下する可能性があります。

X-Frame-Optionsヘッダ

Swarmは、SAMEORIGINという値が設定されているHTTPヘッダのX-Frame-Optionsをデフォルトで出力します。 これにより、Swarmインタフェースが別のWebページに組み込まれることがなくなるため、クリックジャッキング攻撃を防ぐことができます。

Swarmの展開環境を別のWebインタフェースに統合する必要がある場合は、SWARM_ROOT/data/config.phpファイルのセキュリティ構成ブロック内に記述されているx_frame_options項目を編集することにより、X-Frame-Optionsヘッダを調整することができます。 以下に例を示します。

<?php
// this block should be a peer of 'p4'
'security' => array(
'x_frame_options' => value,
),
),

以下に示すいずれかの値を指定することができます。

  • 'SAMEORIGIN' - 同じドメイン上でホストされているフレーム内でのみ、Swarmを表示することができます。
  • 'DENY' - Swarmをフレーム内で表示することはできません。
  • 'ALLOW-FROM URI' - 指定されたURIでホストされているフレーム内でのみ、Swarmを表示することができます。
  • false - X-Frame-Optionsヘッダは出力されません。そのため、Swarmを組み込む場合の制限はありません。

X-Frame-Optionsヘッダの詳細については、Mozilla Developer Networkの記事を参照してください。

クリックジャッキング攻撃の詳細については、Wikipediaの記事を参照してください。

コミットを無効にする

Swarmでは、Swarmのインタフェース内でレビューをコミットすることができます。 この機能を無効にすると、レビュー作成者以外のユーザによるレビューのコミットを禁止することができます。 この機能を無効にすると、[承認してコミット]オプションが、コードレビューの状態リストに表示されなくなります(レビューがすでに承認済みになっている場合は、[コミット]オプションも非表示になります)。

コミット機能を無効にするには、SWARM_ROOT/data/config.phpファイルのレビュー項目で、disable_committrueに設定します。 以下に例を示します。

<?php
// this block should be a peer of 'p4'
'reviews' => array(
'disable_commit' => true,
),
),

制限付きの変更

Helixサーバには、public (デフォルト)とrestrictedという2種類のチェンジリストがあります。 Swarmは、チェンジリストに対するアクセスと、そのチェンジリストに関連するすべてのコメントやアクティビティに対するアクセスを禁止することにより、制限付きの変更を優先します。

チェンジリスト内の1つ以上のファイルに対してlistレベルの権限を持っているユーザの場合、Swarmでチェンジリストを表示することができます。また、表示権限が設定されているファイルを表示することもできます。

重要な情報が誤って漏れてしまうことを防ぐため、制限付き変更の電子メール通知はデフォルトで無効になっています。 制限付き変更の電子メール通知を有効にするには、SWARM_ROOT/data/config.phpファイルのセキュリティ項目で、email_restricted_changestrueに設定します。 以下に例を示します。

<?php
// this block should be a peer of 'p4'
'security' => array(
'email_restricted_changes' => true,
),
),
注意

email_restricted_changestrueに設定すると、制限付き変更の表示権限が設定されていないユーザも含めて、すべての関連ユーザに制限付き変更の電子メール通知が送信されます。 その場合、重要な情報が外部に漏れてしまう可能性があります。

Swarmでは、レポートの対象を、admin レベルの権限を持つユーザがアクセスできる変更のみに制限することができます。 そのため、制限付きの変更を使用する場合は、制限付きファイルに対してSwarmadmin レベルのユーザアクセス権限を設定し、require_login = trueを設定して、権限のないユーザに情報が漏れないようにすることをお勧めします。

プロジェクトの追加を管理者のみに制限する

重要

Swarm 2016.1では、構成項目add_project_admin_onlyが、securityブロックからprojectsブロックに移動され、この構成項目の名前がadd_admin_onlyに変更されました。 ただし、この構成項目の機能は変わっていません。

SWARM_ROOT/data/config.php構成ファイルを更新しなかった場合は、プロジェクトの作成を管理者のみに制限するための古い構成がそのまま使用されます。

新しい構成項目add_admin_onlyprojectsブロックに追加すると、securityブロック内のすべてのadd_project_admin_only設定よりも優先されます。

プロジェクトの追加を特定のグループメンバーのみに制限する

重要

Swarm 2016.1では、構成項目add_project_groupsが、securityブロックからprojectsブロックに移動され、この構成項目の名前がadd_groups_onlyに変更されました。 ただし、この構成項目の機能は変わっていません。

SWARM_ROOT/data/config.php構成ファイルを更新しなかった場合は、プロジェクトの作成を特定のグループのみに制限するための古い構成がそのまま使用されます。

新しい構成項目add_groups_onlyprojectsブロックに追加すると、securityブロック内のすべてのadd_project_groups設定よりも優先されます。

IPアドレスベースのプロテクション機能のエミュレーション

プロテクション」機能を使用してHelixサーバを構成し、IPアドレスなどのさまざまな方法を使用して、ディポへのアクセスを制限することができます。 Swarmは、Helixサーバのクライアントとして機能するWebアプリケーションであるため(通常は、admin レベルの権限が使用されます)、SwarmでIPアドレスベースのプロテクション機能をエミュレートする必要があります。 そのためSwarmは、ユーザのIPアドレスを確認し、必要な制限を各種操作(ファイルの参照、ファイルの内容の表示、ファイルのコメントの表示、ファイルへのコメントの追加など)の実行中に適用することにより、IPアドレスベースのプロテクション機能をエミュレートします。

Swarmは、IPアドレスベースの標準プロテクション機能のエミュレーションのみでなく、プロキシベースのプロテクション機能のエミュレーションも実行します。 ただし、Swarmは、プロキシ構文を使用するプロテクションテーブルのエントリをエミュレートするのみで、SwarmがHelixプロキシに接続されているかどうかについては検出しません。

IPアドレスベースのプロテクション機能のエミュレーションは、デフォルトで有効になっています。 このエミュレーションを無効にすると、Swarmのパフォーマンスがある程度向上します。Swarmのインストール環境でエミュレーションを行う必要がない場合は、以下のように設定すると、エミュレーションが無効になります。

<?php
// this block should be a peer of 'p4'
'security' => array(
'emulate_ip_protections' => false,
),
ヒント

Swarmが複数のHelixサーバインスタンスに接続されている場合、emulate_ip_protectionsを以下のように使用することができます。

  • Swarmが接続されているすべてのHelixサーバインスタンスに対して、emulate_ip_protections設定をグローバルに適用するには、上記のように、securityブロックでemulate_ip_protectionsを設定します。
  • 特定のHelixサーバインスタンスに対して、emulate_ip_protections設定を個別に適用するには、適用先のサーバインスタンスに対して、serveridブロックでemulate_ip_protectionsを設定します。 この値により、Helixサーバインスタンスのsecurityブロックのグローバル設定が上書きされます。

複数のHelixサーバインスタンス用にSwarmを構成する方法については、Swarm構成ファイルをHelixサーバ用に設定するを参照してください。

既知の制約事項

  • レビューやコミットの電子メール通知には、影響を受けるファイルのリストが記載されます。 Swarmは、この電子メール通知を取得するためのIPアドレスを認識できないため、通知に記載されているファイル、ディポパス、詳細情報のいずれについても、フィルタリングが実行されません。 ただし、電子メール通知に記載されているリンクをユーザがクリックした場合は、そのリンクへのアクセスが拒否されます。
  • Swarmは、アクティビティストリームのコメントをフィルタリングしますが、2013.3リリースにアップグレードする前に作成されたコメントについてはフィルタリングできないため、重要な情報が外部に漏れる可能性があります。
  • Swarmでは、コードレビューリスト、コードレビュー、ジョブ、アクティビティストリームでコメントの数が表示されますが、この数には、ユーザが表示できないコメント(そのユーザが表示を制限されているファイルに関連するコメント)は含まれていません。
  • Swarmユーザがプロキシ経由またはVPN経由でSwarmに接続した場合、通常は、そのプロキシまたはVPNのIPアドレスがプロテクション機能で使用されます。
  • ユーザのIPアドレスとSwarmのIPアドレスの両方に制限が適用されている場合、そのユーザには、これら2つのIPアドレスベースの制限のうち、より制約が厳しい方の制限が適用されます。一方、Swarmは、適用されている制限をバイパスすることはできません。
  • Swarmは、ユーザに代わって、admin レベルの権限を使用してさまざまな操作を実行します。 特定のバージョンデータへのアクセスを制限する目的でインストールされたIPアドレスベースまたはユーザIDベースのプロテクション機能をHelixサーバで使用している場合であっても、通常は、Swarmからそのデータにアクセスすることができます。 そのため、Swarmで情報漏洩が発生しないと保証することはできません(特に、カスタムモジュールを使用する場合や、Swarmのソースをカスタマイズした場合など)。

詳細については、Helix Coreサーバ管理者ガイドの「アクセスの認証」を参照してください。

システム情報を無効にする

Swarmには、admin 権限を持つユーザとsuper 権限を持つユーザが使用できる[システム情報]ページがあります。このページには、Swarmで使用されるHelixサーバの情報、PHPの情報、Swarmログファイルの情報が表示されます。

これらの情報は、Perforceのサポートエンジニアとやり取りを行う場合に重要な情報ですが、必要に応じて非表示にすることができます。 [システム情報]ページを無効にするには、p4エントリと同じレベルで、以下の構成ブロックをSWARM_ROOT/data/config.phpファイルに追加します。

<?php
// this block should be a peer of 'p4'
'security' => array(
'disable_system_info' => true, // defaults to false
),

[システム情報]ページを無効にすると、[システム情報]リンクが[Swarmのバージョン情報]ダイアログに表示されなくなり、[システム情報]ページにアクセスしようとすると、403エラーが表示されます。

HTTPクライアントのオプション

Swarmでは、ベースとなるLaminas FrameworkのHTTPクライアントに渡されるオプションを設定することができます。 これらのオプションを使用して、SSL証明書の場所や要求のタイムアウトなどを指定することができます。これらのオプションは、システム全体でグローバルに指定することも、ホストごとに個別に指定することもできます。

以下に構成例を示します。

<?php
// this block should be a peer of 'p4'
'http_client_options' => array(
'timeout' => 5,
// path to the SSL certificate directory
'sslcapath' => '',
// the path to a PEM-encoded SSL certificate
'sslcert' => '', // the path to Certificate Authority file 'sslcafile' => '',
// the passphrase for the SSL certificate file
'sslpassphrase' => '',
// optional, per-host overrides;
// host as key, array of options as value
'hosts' => array(
'jira.example.com' => array(
'sslcapath' => '/path/to/certs',
'sslcert' => 'jira.pem',
'sslpassphrase' => 'keep my JIRA secure',
'timeout' => 15,
), 'jenkins.example.com' => array( 'sslcafile' => '/path/to/certs/jenkins.pem', 'sslpassphrase' => 'keep my jenkins very secure', 'timeout' => 15, ),
),
),

詳細については、Laminas Frameworkのソケットアダプタのドキュメントを参照してください。

注意

Swarmは、LICENSE.txtファイルに記載されているバージョンのLaminasコンポーネントをサポートしています。それ以降のバージョンのLaminasで導入されたLaminasドキュメントは、Swarmでは動作しません。 LICENSE.txtファイルは、Swarmのインストール環境のreadmeフォルダに保管されています。

警告

自己署名SSL証明書を使用することができますが、そのための構成を追加すると、証明書の妥当性チェックが無効になるため、構成されているホストに対する接続が不安定になります。 そのため、この構成オプションは使用しないことを強くお勧めします。

ただし、継続的な統合、展開、またはJIRAの接続を構成し、これらの接続で自己署名SSL証明書を使用する必要がある場合は、対象となるホストに対してsslallowselfsigned項目をtrue に設定します。以下に例を示します。

<?php
// this block should be a peer of 'p4'
'http_client_options' => array(
'hosts' => array(
'jira.example.com' => array(
'sslallowselfsigned' => true,
),
),
),

制限の厳しいHTTPS

Swarmの操作時(特に、ネットワークの外部で操作する場合)におけるセキュリティを強化するため、SwarmにはWebブラウザで強制的にHTTPSを使用するための機能が付属しています。 この機能を有効にすると、Swarmの動作が以下のように変わります。

  • Swarmに対するHTTP要求に、HTTPSバージョン用のmeta-refreshが挿入されます。 要求がSwarmに渡される前にロードバランサによって暗号化が処理された場合は、meta-refreshが無効になります。 こちらを参照してください。
  • すべての要求について、制限の厳しいトランスポートセキュリティヘッダを挿入すると、Swarmのインストール環境内のブラウザで、HTTPSが30日間強制的に使用されることになります。
  • Swarmが生成するすべての修飾URLで、スキーム用のHTTPSが使用されます。
  • HTTPS専用であることを示すフラグがクッキーに設定されます。

制限の厳しいHTTPSを有効にするには、以下のように指定します。

<?php
// this block should be a peer of 'p4'
'security' => array(
'https_strict' => true,
'https_strict_redirect' => true, // optional; set false to avoid meta-refresh
'https_port' => null, // optional; specify if HTTPS is
// configured on a non-standard port
),

https_strict_redirect項目をfalseに設定すると、SwarmでHTTPクライアント用のmeta-refreshが追加されなくなります。 これにより、Swarmの前面に配置されているロードバランサがクライアントとロードバランサ間の接続に対してHTTPSを適用する際に、無限にリダイレクトされることがなくなります。これは、クライアントからロードバランサに対する接続の場合の動作です。ロードバランサからSwarmに対する接続の場合、この動作は発生しません。

Apacheのセキュリティ

Swarmのセキュリティを強化する目的で、いくつかのApache構成が変更されました。

  • 識別機能を無効にする

    デフォルトでは、Web要求に対するApacheの各応答には、インストールされている各モジュールとそのバージョンとともに、Apacheとそのバージョンを識別するトークンのリストが挿入されます。 また、同じような情報が含まれているApacheの各応答に、署名行を追加することもできます。 これらの識別情報自体は、セキュリティに対するリスク要因にはなりませんが、攻撃者が攻撃方法を特定する場合の手がかりになる可能性があります。

    Apacheの識別機能を無効にするには、以下の2行をApache構成に追加します。

    ServerSignature Off
    ServerTokens ProductOnly
  • TRACE要求の無効化

    TRACE要求を使用すると、受信したすべての情報に対してApacheから応答することができます。これは、デバッグ環境で使用すると便利です。 ただし、TRACE要求を悪用してクッキー情報を入手できるため、Swarmにログインするための資格情報に不正にアクセスされる可能性があります。

    TRACE要求を無効にするには、以下の行をApache構成に追加します。

    TraceEnable off
  • SSL構成の更新

    Swarmは、SSLが有効になっているApacheで正しく機能します。 最近になって、標準的なSSL構成に対する攻撃がいくつか報告されています。 そのため、以下の行をApache構成に追加することをお勧めします。

    <IfModule mod_ssl.c>
    SSLHonorCipherOrder On
    SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH
    SSLCompression Off
    </IfModule>

PHPのセキュリティ

Swarmのセキュリティを強化するため、いくつかのPHP構成が変更されました。

  • 識別機能を無効にする

    デフォルトでは、PHPがWeb要求に関係していることを示す情報(PHPのバージョン情報など)が、PHPからApacheに渡されます。

    PHPの識別機能を無効にするには、システムのphp.iniファイルを編集用として開き、expose_php行の設定を以下のように変更します。

    expose_php = Off
  • phpinfo()が含まれているスクリプトの削除

    モジュールの開発作業やデバッグ作業で、phpinfo()を呼び出す場合があります。この関数を呼び出すと、PHPのアクティブな構成、コンパイルの詳細情報、関係するモジュールとその構成が表示されます。 通常は、以下の行が記述されているスクリプトをSwarmのパブリックディレクトリに追加します。

    <?php phpinfo() ?>

    こうしたスクリプトは、Swarmの実稼働インスタンスから削除する必要があります。

proxy_mode

デフォルト設定の場合、Swarmはプロキシモードで稼働し、エンドユーザが使用しているブラウザのIPアドレスがHelixサーバに渡されます。 Helixサーバは、IPプロテクションテーブルに対してIPアドレスを確認し、エンドユーザに対して付与されている権限を判断します。

SWARM_ROOT/data/config.phpファイルのp4構成ブロック内に記述されているSwarmproxy_modeを以下のように設定します。

<?php
'p4' => array(
'proxy_mode' => true, // defaults to true
),
  • true: Swarmは、エンドユーザが使用しているブラウザのIPアドレスをHelixサーバに渡します。これによりHelixサーバは、エンドユーザに割り当てられている権限を判断することができます。 これはデフォルトの設定です。
  • false: SwarmサーバのIPアドレスがHelixサーバに渡されます。 Helixサーバは、プロテクションテーブルに対してSwarmのIPアドレスを確認し、エンドユーザに割り当てられている権限を判断します。 この場合、すべてのSwarmユーザに同じ権限が割り当てられているという結果になります。
ヒント

Swarmが複数のHelixサーバインスタンスに接続されている場合、proxy_modeを以下のように使用することができます。

  • Swarmが接続されているすべてのHelixサーバインスタンスに対して、proxy_mode設定をグローバルに適用するには、上記のように、p4ブロックでproxy_modeを設定します。
  • 特定のHelixサーバインスタンスに対して、proxy_mode設定を個別に適用するには、適用先のサーバインスタンスに対して、serveridブロックでproxy_modeを設定します。 この値により、Helixサーバインスタンスのp4ブロックのグローバル設定が上書きされます。

複数のHelixサーバインスタンス用にSwarmを構成する方法については、Swarm構成ファイルをHelixサーバ用に設定するを参照してください。