本番運用
本番環境に ClickStack をデプロイする際は、セキュリティ、安定性、および適切な構成を確保するために、いくつかの追加の考慮事項があります。
ネットワークとポートのセキュリティ
デフォルトでは、Docker Compose はホスト上でポートを公開するため、ufw (Uncomplicated Firewall) のようなツールが有効になっている場合でも、コンテナ外部からアクセス可能な状態になります。これは Docker のネットワークスタックの挙動によるもので、明示的に設定しない限り、ホストレベルのファイアウォールルールをバイパスしてしまうことがあります。
推奨事項:
本番利用に必要なポートのみを公開してください。通常は OTLP エンドポイント、API サーバー、およびフロントエンドです。
たとえば、docker-compose.yml ファイル内で不要なポートマッピングを削除するか、コメントアウトするようにしてください。
コンテナの分離やアクセス保護の強化に関する詳細は、Docker ネットワークのドキュメントを参照してください。
セッションシークレットの設定
本番環境では、セッションデータを保護し改ざんを防ぐために、環境変数 EXPRESS_SESSION_SECRET に強力なランダム値を必ず設定する必要があります。
アプリケーションサービス用の docker-compose.yml ファイルにこれを追加する方法は次のとおりです。
openssl を使用して強度の高いシークレットを生成できます:
シークレットをソースコード管理にコミットしないでください。本番環境では、環境変数管理ツール(例: Docker Secrets、HashiCorp Vault、または環境ごとの CI/CD 設定)の利用を検討してください。
セキュアなインジェスト
すべてのインジェストは、ClickStack ディストリビューションに含まれる OpenTelemetry (OTel) コレクターが公開する OTLP ポート経由で行う必要があります。デフォルトでは、これには起動時に生成されるセキュアなインジェスト API key が必要です。このキーは OTel ポートへデータを送信する際に必須であり、HyperDX UI の Team Settings → API Keys から確認できます。

さらに、OTLP エンドポイント向けに TLS を有効化し、ClickHouse インジェスト専用のユーザーを作成することを推奨します。
ClickHouse
本番環境でのデプロイメントには、標準的なセキュリティプラクティス(強化された暗号化・認証・接続性や、マネージドなアクセス制御を含む)がデフォルトで適用される ClickHouse Cloud の利用を推奨します。ClickHouse Cloud をベストプラクティスに沿って利用するためのステップバイステップガイドについては、「ClickHouse Cloud」を参照してください。
ユーザー権限
HyperDX ユーザー
HyperDX 用の ClickHouse ユーザーは、以下の設定を変更できる権限を持つ readonly ユーザーであれば十分です:
max_rows_to_read(少なくとも 100 万まで)read_overflow_modecancel_http_readonly_queries_on_client_closewait_end_of_query
既定では、OSS と ClickHouse Cloud の両方で default ユーザーがこれらの権限を持っていますが、これらの権限を持つ新しいユーザーを作成することを推奨します。
データベースとインジェスト用ユーザー
OTel collector が ClickHouse にインジェストするための専用ユーザーを作成し、インジェスト先を特定のデータベース(例:otel)にすることを推奨します。詳細については、「インジェスト用ユーザーの作成」を参照してください。
セルフマネージド環境でのセキュリティ
自前で ClickHouse インスタンスを運用している場合は、TLS を有効化し、認証を強制し、アクセス保護強化のベストプラクティスに従うことが不可欠です。実際の設定ミスの事例とその回避方法については、このブログ記事を参照してください。
ClickHouse OSS は、標準で堅牢なセキュリティ機能を提供しています。ただし、これらは別途設定が必要です。
config.xmlのtcp_port_secureおよび<openSSL>を利用して TLS を使用 します。詳しくは guides/sre/configuring-tls を参照してください。defaultユーザーに対して 強力なパスワードを設定 するか、無効化します。- 明示的に公開する場合を除き、ClickHouse を外部に公開しない ようにします。デフォルトでは、
listen_hostが変更されない限り、ClickHouse はlocalhostのみにバインドされます。 - パスワード、証明書、SSH キー、または external authenticators などの 認証方式を使用 します。
- IP フィルタリングおよび
HOST句を用いて アクセスを制限 します。詳しくは sql-reference/statements/create/user#user-host を参照してください。 - ロールベースアクセス制御 (RBAC) を有効化して、きめ細かな権限を付与します。詳しくは operations/access-rights を参照してください。
- quotas、settings profiles、および読み取り専用モードを使用して、クォータと制限を強制 します。
- 保存データを暗号化 し、安全な外部ストレージを使用します。詳しくは operations/storing-data および cloud/security/CMEK を参照してください。
- 認証情報のハードコーディングは避けてください。 named collections または ClickHouse Cloud の IAM ロールを使用します。
- system logs および session logs を使用して、アクセスとクエリを監査 します。
ユーザー管理およびクエリ/リソース制限の管理には、external authenticators および query complexity settings も参照してください。
有効期限 (TTL) を設定する
ClickStack デプロイメントに対して 有効期限 (TTL) が適切に設定されていることを確認します。これはデータの保持期間を制御するものであり、デフォルトの 3 日は変更が必要になることが多いです。
MongoDB ガイドライン
公式の MongoDB セキュリティチェックリスト に従ってください。
ClickHouse Cloud
以下は、ベストプラクティスを満たす ClickHouse Cloud を用いたシンプルな ClickStack のデプロイメント例です。
サービスを作成する
サービスを作成するには、ClickHouse Cloud のクイックスタートガイドに従ってください。
接続情報をコピーする
HyperDX 用の接続情報を確認するには、ClickHouse Cloud コンソールを開き、サイドバーの Connect ボタンをクリックし、HTTP 接続情報、特に URL を控えてください。
このステップで表示されるデフォルトのユーザー名とパスワードを使用して HyperDX に接続することも可能ですが、専用ユーザーの作成を推奨します(下記参照)。

HyperDX 用ユーザーを作成する
HyperDX 専用のユーザーを作成することを推奨します。Cloud SQL コンソールで次の SQL コマンドを実行し、複雑性要件を満たす安全なパスワードを指定してください。
ClickStack をデプロイする
ClickStack をデプロイします。Helm または Docker Compose(ClickHouse を除外するように修正したもの)のデプロイメントモデルを利用することを推奨します。
上級ユーザーの場合は、OTel collector と HyperDX を、それぞれのスタンドアロンデプロイメントモードで個別にデプロイすることもできます。
ClickHouse Cloud を Helm チャートと組み合わせて利用する手順はこちらを参照してください。Docker Compose 向けの同等の手順はこちらにあります。
HyperDX UI にアクセスする
http://localhost:8080 にアクセスして HyperDX UI を開きます。
要件を満たすユーザー名とパスワードを指定してユーザーを作成します。

Create をクリックすると、接続情報の入力を求められます。
ClickStack にデータを送信する
ClickStack にデータを送信する方法については、"Sending OpenTelemetry data" を参照してください。
