メイン コンテンツをスキップする

サービス証明書

プロキシとブラウザー、または 2 つの内部サービスなど、2 つのエンティティ間の安全な通信には証明書が使用されます。

Qlik Sense には、サーバー証明書およびトラスト ゾーン証明書の 2 種類の証明書があります。

  • サーバー証明書は、Qlik Sense Proxy Service と、ブラウザーで実行されている Qlik Sense クライアントとの通信を保護するために使用します。
  • トラスト ゾーン証明書は、 内部サービス間の通信を保護するために使用します。Qlik Sense
注: この後の説明ではトラスト ゾーン証明書に焦点を当てます。サーバー証明書についてはこれ以上詳細には説明しません。

相互認証による TLS に使用される Qlik Sense トラスト ゾーン証明書とキー

Qlik Sense トラスト ゾーンは、内部サービス間の相互認証による Transport Layer Security (TLS) をベースにしています。

TLS 相互認証を確立するには、すべてのサービスで以下の 3 つの証明書および 2 つのプライベート キーが必要です。

ルート証明書

ルート証明書は、通信先とするサービスによって送信された証明書を検証するために使用します。

Windows 証明書の格納場所:[ローカル コンピューター] > [信頼されたルート証明機関]

サービス証明書とサービス プライベート キー

サービスがサーバーの役割を果たす場合、つまり別のサービスがお使いのサービス内で API を呼び出すときに、サーバー認証としてサービス証明書およびサービス プライベート キーが使用されます。

Windows 証明書の格納場所:[ローカル コンピューター] > [個人用] > [証明書]

クライアント証明書とクライアント プライベート キー

サービスがクライアントの役割を果たす場合、つまりお使いのサービスが別のサービスで API を呼び出すときに、クライアント認証としてクライアント証明書およびクライアント プライベート キーが使用されます。

Windows 証明書の格納場所:[ローカル サービス ユーザー] > [個人証明書]

node.js に実装されるサービスの場合、証明書のコピーが次のフォルダー内にあります: ProgramData%\Qlik\Sense\...\ExportedCertificates。次の例では、サービスがサーバーの役割を果たします。

The Client Service connects to the Server Service through HTTPS GET/api/. Both contain a Trust zone Root Certificate, a Trust zone Client Certificate, and the Trust zone Client private key.

サービスがサーバーの役割を果たす例

サーバー証明書のコモン ネームにはサーバーのホスト名が含まれており、サーバーのドメイン名が証明書の情報と一致することを検証するためにクライアントが使用します。次の例では、クライアント サービスが TLS に関してサーバー server.domain.com とネゴシエートします。

Two client services pass a Trust zone Server Certificate (Subject CN = server.domain.com) back and forth, via HTTPS GET server.domain.com/api/ and TLS Server hello.

クライアント サービスが TLS に関してサーバーとネゴシエートする例

サーバー証明書のコモン ネームは、QMC でのノード登録プロセス中に管理者が入力します。

QlikServiceCluster 証明書

QlikServiceCluster 証明書は、Qlik Sense Enterprise on Windows からマルチクラウド展開にアプリを配布するために使用します。

Windows 証明書の格納場所:[ローカル コンピューター] > [個人用] > [証明書]

手動構成

手動構成は、アプリ配布を使用している、または使用する予定のあるマルチノード サイトをアップグレードする場合に必要です。

2020 年 6 月 (以前) から 2020 年 9 月 (以降) にアップグレードする場合は、こちらを参照してください: 「FAQ: Windows 上の Qlik Sense Enterprise からアプリを配布するための QlikServiceCluster 証明書」。

次の場合は、手動で構成する必要はありません。

  • シングルノードまたはマルチノード サイトの新規展開。
  • シングルノード サイトのアップグレード。
  • アプリ配布を使用する予定のないマルチノード サイトのアップグレード。

Qlik Sense トラスト ゾーンのキー管理

すべてのキーおよび証明書の作成元すべてのノード キーおよび証明書は、セントラル ノードによって作成されます。キーはランダムに生成され、対応する証明書は、トラスト ゾーンの Root プライベート キーによって署名されます。トラスト ゾーンの Root プライベート キーは、Qlik Sense が使用する第 3 のプライベート キーです。ただし、このキーは新しい証明書を発行するためにのみ使用され、相互の TLS の確立では使用されません。セントラル ノードが新しいノードの証明書およびキーを生成した場合には、ランダムに生成されたパスワードで暗号化され、新しいノードの REST エンドポイントに送信されます。

管理者は新しいノードでこのパスワードを入力して、キーおよび証明書を復号化し、新しいノードにインストールできるようにする必要があります。localhost の役割のみを果たす Web ページでパスワードを入力します。実際には、これはすべて、QMC でのノード登録ワーク フローで発生します。

証明書およびキーの配布手順について、次の例で説明します。

The central node creates a Trust zone Root Certificate, as well as a Trust zone Root Certificate, Trust zone Server Certificate, Trust zone Client Certificate, Trust zone Server private key, and Turst zone Client private key that are encrypted by a user's password. With the password, these are sent via HTTP POST/setup/certificate distribution to a new node.

証明書とキーの配布手順

証明書の拡張を使用して Qlik 証明書として証明書を識別し、この拡張の値で証明書のロールを 「root」、「service」、または「client」 のいずれかとして定義します。

データベースの暗号化

データベースの一部の項目は、アプリケーション レイヤーで Qlik Sense によって暗号化されます。これは通常、接続用パスワードなどの認証情報を含む項目です。データベースの項目は、すべての Qlik Sense ノードで使用可能にする必要のある対称キーで暗号化され、トラスト ゾーン サーバー証明書を使用してキーを保持します。

データベースの暗号化アルゴリズムおよびキーは、トラスト ゾーン サーバー証明書に拡張として格納されます。すべての拡張は 1 つのオブジェクト ID (OID) によって識別され、拡張の内容を示します。

  • 1.3.6.1.5.5.7.13.1: 対称データベース キー
  • 1.3.6.1.5.5.7.13.2: データベース キーのアルゴリズム

これら両方の項目は、トラスト ゾーン サーバー証明書のパブリック キーで暗号化されます。つまり、これはトラスト ゾーン サーバーのパブリック キーへのアクセス権を持つ唯一のエンティティであるため、項目を復号化できる唯一のサービスであるということです。