クライアントとサーバー間のトラフィックの保護

この章では、Tableau Server が他のコンピュータとどのように通信し、そのトラフィックをより安全にするために何ができるかを説明しています。

 

先のいくつかのカーブ

Tableau Server: 全ユーザー向けインストール ガイド のこれまでの章では、見通しの良い高速道路のように順調に感じたかもしれませんが、この章では、山道のように険しくなっていきます。1 車線の側道ほどではないものの、以前より高い集中力が求められます。

そのように聞くと安心されるかもしれませんが、一部の操作は IT プロフェッショナルにとっても厄介なものです。しかし、機密データのセキュリティについて説明する際に、アプローチがあまりに簡単過ぎるとしたら、それを信用できるでしょうか。

ここまで本ガイドを頼りに単独で操作してこられた方も、ここではローカルにいる IT プロフェッショナルの助けを求めてください。社内に IT 担当者がいない場合は、Tableau プロフェッショナル サービスの助けを導入することを検討してください。

IT 担当者の助けを導入してさえ、Tableau Server を管理するすべての人が環境の保護の原理と手順を理解することは重要です。加えて、学習して何を楽しむのか、または自分自身でプロになることさえ願っているのか、決めてしまいたくありません。そういうわけで、セットアップをおこなっていくために必要となるものを伝えるため、ここに最善を尽くします。その他、オンラインには豊富な情報が提供されており、Tableau 独自のヘルプやナレッジ ベースの記事もあります。

HTTP およびクライアント/サーバー通信の概要

既定では、Tableau Server は、多くのサーバー アプリケーションのように、標準の Web プロトコル、すなわち HTTP を使用してクライアントと通信します。HTTP では、ときにブラウザがサーバに要求を送信し、サーバが応答すると、情報が前後にクリア テキストで送信されます。それは、誰でもその通信をスヌープできる人がそのコンテンツを読み取ることができることを意味します。

ユーザーとサーバーが前後に送る情報の一部は、敏感である可能性があります。たとえば、ユーザーが Web ブラウザを介して Tableau Server にアクセスし、サーバーにサインインするためのユーザー名とパスワードを送信することがあります。または、ユーザーが機密データで作成された Tableau ビューを要求することがあります。誰かがこのトラフィックを見ることができるなら(経験豊富な IT 担当者にとって、HTTP 上でスヌーピングするのは難しいことではありません)、見てはならない情報を見る可能性があります。

セキュリティの目標: プライバシーと信頼

Tableau Server とクライアントの間の通信を確保することになると、プライバシーと信頼が後になります。プライバシーを実現するには、スヌープの可能性があるすべての人がコンテンツを読めないようにします。トラフィックを暗号化することによって、これを行います。

しかし、サーバとクライアント間の信頼関係も必要です。これは、クライアントが、サーバーから送信される情報は、自分が通信しているサーバーからのものであると信頼できることを意味しています。信頼は認証によって確立されます。それは、自分のコンピュータにサインインするためにユーザー名とパスワードを入力して、ユーザとして認証されるのと同様です。認証は、悪質なサイトとの通信にクライアントがだまされるのを防ぐのに役立ちます。

SSL を使用して Tableau Server 通信を暗号化する

SSL (セキュア ソケット レイヤー) はプロトコルとして HTTP に似ていますが、コンピュータにウェブのようなネットワークを介して暗号化された情報を送信させる点で異なっています。(SSL という用語をこのプロトコルの総称として使用していますが、TLS と呼ばれる場合もあります。)SSL は、前に述べたプライバシーと信頼という 2 つの目標を、いま述べている暗号化と認証を通して達成します。SSL が Tableau Server で有効になっている場合、ユーザーは https://http:// の代わりに使用し、サーバーからのコンテンツを要求することができます。

SSL の有効化は、クライアントとサーバー間のトラフィック セキュリティを著しく向上させます。Tableau Server のインスタンスがインターネット (内部ネットワーク上だけではなく) からアクセス可能である場合には、サーバーのために SSL を構成することは不可欠です。SSL なしでパブリック ネットワーク上でサーバを利用可能にすることは、セキュリティ上の重大な問題です。サーバーが公的にアクセス可能でない場合であっても、ローカル ネットワーク上においてクライアントとサーバ間の通信のために SSL を有効にしておくことをお勧めします。

次のセクションでは、SSL がどのように機能するかについてのいくつかの背景情報を提供します。また、インターネット上またはローカル ネットワーク上のいずれの安全なトラフィックの支援を望むとしても、Tableau Server で SSL を使用するための要件についても説明します。SSL を有効にする方法と、追加の情報に関する外部リソースについて説明します。ローカル ネットワーク上でどのように SSL を有効にするかは、環境内の多くの要因に依存します。IT に詳しい友人なら、特定のサーバーのインストールのためにそれを処理する最善の方法を知っていることでしょう。

SSL と VPN

Tableau Server ユーザーの中には、ネットワークへの VPN (仮想プライベート ネットワーク) 接続を使用してオフサイトからサーバーにアクセスする人がいるかもしれません。その場合、ユーザーはオフサイトですが、VPN 接続自体は、プライバシーと信頼の両方を提供します。やはり SSL を有効にすることをお勧めしますが、ユーザーが Tableau Server へ VPN を渡ってアクセスする場合、それは必須ではありません。

SSL 証明書

SSL をサポートするために、サーバーは、デジタル証明書を必要とします。デジタル証明書は、認証局、または CA として知られる、公的に信頼されたサードパーティのエンティティから取得することができます。信頼される CA は、組織の身元を確認した後、組織に固有の署名付き証明書を発行します。信頼できる CA の例には、シマンテック社 (VeriSign 社)、thawte 社、および GlobalSign 社が含まれます。その他、多くのものがあります。

"公的に信頼できる" とは、すべてのオペレーティングシステム、Tableau がサポートされているブラウザー、および他のクライアントが、本質的にこれらの CA からのルート証明書を信頼することを意味します。彼らは推奨される暗号化のための Web 業界標準を満たしているので、クライアントとサーバ間の信頼関係を構成するための負担を軽減します。

証明書を取得する手順を行った後、CA はファイルのセットとして証明書を送信します。証明書ファイルを受信したら、サーバーにそれらをインストールします。クライアントがサーバーにアクセスしようとするとき、サーバーの証明書から取得した情報によってサーバに認証されます。これは信頼の目標をカバーしています。証明書には公開キーが含まれますが、それによってクライアントはサーバとの暗号化通信を確立することが可能になります。これはプライバシーの目標をカバーしています。

この審査のプロセスのハイ レベルな説明として、クライアントはサーバーとの暗号化されたセッションを開始したい場合、サーバーの証明書を要求します。(ところで、これはユーザーが URL の初めの https:// を入力したときに自動的に行われます。)サーバーは、その証明書で応答します。一般的に、サーバー証明書は発行者の証明書を指します。発行者の証明書が別の発行者による証明書を指し、そのサイクルが CA にまで至ることがあります。このように、通常は大きな証明書の連鎖が存在します。クライアントはその証明書、またはチェーン内のすべての証明書を検査し、その CA 情報とクライアントがすでに持っている CA 情報を比較します。(ブラウザや他のクライアントは、既知の CA のストアを維持します。)クライアントが、証明書が有効かつ信頼されていると判断した場合、クライアントとサーバは暗号化されたセッションや情報交換を開始することができます。

相互 (2 方向) SSL

ここではただ、相互 SSL または双方向 SSL とも呼ばれる構成が可能であることに言及します。そこは、サーバーとクライアントの両方が証明書を持つところとなります。相互 SSL は、ユーザーが公共の場所から、特に公共のワイファイを介してサーバーにアクセスする場合に非常に有用です。なぜなら、事前構成されたクライアントだけがサーバーへアクセスできることを確認するのに役立つからです。

相互 SSL のクライアント証明書は、一般的に、組織内の IT 担当者によって生成されます。クライアント証明書には、ユーザー名と、偽造できない証明書であることを確認するための情報が含まれています。相互 SSL によって、クライアントはサーバーでとセッションを開始し、いつものようにサーバーの証明書を要求し検証します。それから、サーバーはクライアントの証明書を要求および検証し、その有効性を判断します。

このガイドでは、相互 SSL についての説明は以上ですが、この章の後半には、Tableau Server をインストールする際に有効と思える機能についてのより多くの情報へのリンクがあります。

自己署名証明書

組織は、CA が提供する審査プロセスを経ることなく、独自の証明書を生成することができます。これは、自己署名証明書を作成します。自己署名証明書は、クライアントとサーバが暗号化されたセッションを確立することを可能にします。しかし、クライアントはサーバの身元 (サーバーの認証) を確認することはできません。ユーザーがサーバーに接続すると、次のようなメッセージが表示されます。"この証明書は信頼されていません。"正確なテキストは、ブラウザや他のクライアントに依存します。

既定では、Tableau Mobile を含む多くの Tableau クライアントは、Tableau Server 上で自己署名証明書で動作しません。(iOS デバイスなど) いくつかのクライアントでは、自己署名証明書を信頼するようにデバイスを設定することができます。これについてさらに知りたい場合は、SSL サーバでの Tableau Mobile の使用に関するナレッジ ベースの記事を参照してください。この章の最後にある追加リソースのセクションにそれがリストされています。

"この証明書は信頼されていません"というブラウザー警告の解決を試みたり、自己署名証明書 (信頼できない結果になる可能性がある) で動作するようにデバイスを構成したりするのではなく、既知の CA から信頼できる公的証明書を取得することをお勧めします。

組織内のクライアント/サーバー トラフィックの SSL

信頼できる CA から取得する証明書や、サーバーと、組織外でユーザーが操作するコンピューターの間のトラフィック (インターネットからのトラフィック) を保護するのに役立ちます。このシナリオでは、クライアントはサーバーの完全修飾 (パブリック) ドメイン名を使用します (例: https://www.example.com/)。(https:// の末尾の s に注意してください)

また、ローカル ネットワークのトラフィックに SSL 暗号化を有効にすることもできます。これにより、同僚が社内ホスト名を使用したサーバー (https://tableauserver など) にアクセスする際、トラフィックを保護します。

次のセクションでは、内部トラフィックで SSL を有効化するオプションについて説明します。説明に続き、推奨事項を示します。IT パートナーと連携して御社の環境に最も適したものを決定し、構成に関するサポートを求めます。

組織の既存の社内 CA または自己署名ルート証明書を使用する

組織に IT チームがある場合は、独自の社内認証局があるかどうかを確認してください。ある場合は、そこで証明書の作成を依頼してください。多くの場合、Tableau ユーザーのコンピューターによってこれらの証明書は自動的に信頼されます。そのため、各クライアントで証明書を信頼する構成プロセスを行う必要はありません。

社内 CA がない場合、代わりに OpenSSL (Tableau Server に付属のオープン ソース ツール) を使用して社内 CA を作成します。次に、各クライアントで社内 CA を信頼するよう設定します。証明書の更新が必要な場合は、使用中のシステム管理ツール (Group Policy など) を介して証明書をクライアントにプッシュします。

この手順は Tableau Server ヘルプや Web にも記載されていますが、コンピューターのシステム レベルで多くの可動部品を調節する必要があります。経験豊富な IT パートナー以外がこれを実行することは、推奨されていません。

サーバーに自己署名証明書を作成し、クライアントでサポートされるように構成する

これは、パブリック トラフィックでの自己署名証明書の使用に関するセクションで説明した内容と全く反対です。ただし、これでも問題がない理由について説明します。組織のプライベート ネットワーク内部から隔離されているクライアント/サーバー トラフィックでは、CA が発行した証明書を使用するパブリック レベルの信頼性は必要ありません。

たとえ内部トラフィックであっても、各ユーザー コンピューター、iOS デバイスやその他のクライアントで自己署名証明書をサポートするようブラウザーを構成する必要があります。そうでない場合、接続を試みた時にブラウザーに表示される「信頼できないサイト」警告メッセージの対応方法をユーザーに説明する必要があります。さらに、たとえクライアントを構成していても、証明書の期限が切れた際はもう一度構成し、再発行する必要があります。

使用するオプションの決定方法

Tableau Server への内部トラフィックに SSL を有効化する場合、設定順序は次のようになります。組織で優先オプションが実用的でない場合 (社内 CA がない場合など) は、次のオプションを試してください。

  1. 組織に社内 CA がある場合はそれを使用します。これにより内部で SSL を有効化し、面倒な「信頼できない証明書」のブラウザー メッセージを減らすことができます。

  2. 自己署名証明書を使用し、クライアントで信頼するように構成するか、Tableau Server を例外にして「信頼できないサイト」ブラウザー メッセージを無視しても問題ないことをユーザーに説明します。

  3. 世間から信頼されている CA から証明書を取得します。

  4. 最初の 3 つのオプションがいずれも使用できない場合、IT 部門に協力を求め、社内 CA の作成方法を説明したプロセスをサポートしてもらいます。

Tableau Server のパブリック証明書の取得とインストール

証明書の取得プロセスは各 CA によって異なり、費用は CA および取得する証明書のレベルによって異なります。組織に IT 部門がない場合、まず「SSL 証明書の取得」などの語句を使用して Web で検索し、さまざまな CA のオファーを読むことをお勧めします。

組織に IT 部門がある場合は、彼らにパブリック認証局と関わりがあるかを尋ね、取得プロセスを効率化することができます。

IT 担当者は、Tableau Server にインストールする証明書に対し、次の要件を把握する必要があります。(略語は異なる暗号化アルゴリズムを表します。現時点では、好奇心を満たす以外に詳細を学習する必要はありません。)

  • サーバー証明書は PEM 暗号化 x509 証明書である必要があります。

    その他の形式も可能です。そのため、PEM 暗号化証明書を取得するか、OpenSSL などのツールを使用して証明書を PEM 形式で保存するようにしてください。

  • 証明書 .key ファイルには、RSA または DSA 形式のキーと埋め込まれたパスフレーズが含まれており、ファイル自体はパスワードで保護されていません。

  • サーバー証明書をルート CA が直接署名していない場合、発行者はチェーン ファイルを提供します。

    チェーン ファイルは同様に PEM 形式を使用し、サーバー証明書とルート証明書の間のすべての中間証明書を含める必要があります。ルート証明書 (または「トラスト アンカー」) を含めることはオプションです。Mac で Tableau Mobile または Tableau Desktop を使用してユーザーがサーバーに接続するよう設定する場合は、チェーン ファイルが必要です。

SSL の有効化

  1. ブラウザで TSM を開きます。

    https://<tsm-computer-name>:8850詳細については、「Tableau Services Manager の Web UI へのサインイン」(Link opens in a new window)を参照してください。

  2. [構成] タブで [セキュリティ] > [外部 SSL] を選択します。

  3. [外部 Web サーバーの SSL][SSL でサーバー通信を有効にする} を選択します。

  4. 証明書ファイルおよびキー ファイルをアップロードし、お使いの環境に必要な場合には、チェーン ファイルをアップロードして次のパスフレーズ キーを入力します。

    SSL の構成のスクリーンショット

  5. [保留中の変更を保存] をクリックします。

  6. ページ上部の [変更を保留中] をクリックします。

  7. [変更を適用して再起動] をクリックします。

証明書の表示

ファイルをインストール後、ブラウザーでサイトに移動し、証明書を表示できます。Google Chrome で Tableau Online を使用し、このしくみについて説明します。

  1. ブラウザーを開き、online.tableau.com に移動します。

  2. アドレス バーに表示された緑の錠前をクリックします。

  3. [詳細] リンクをクリックします。サイトのセキュリティの概要が表示されます。

    ディスプレイに、サイトは有効な信頼できる証明書を使用していると Chrome が判断したと表示されます。セキュリティの概要をクリックすると、証明書を発行した CA と信頼連鎖を確認できます。より具体的な情報を見るには、こちらの [証明書の表示] をクリックしてください (内容は単純です)。

    さまざまなブラウザーで試し、各ブラウザーで証明書情報や、サインインするさまざまなサイト (オンライン バンキング アカウントなど) がどのように表示されるかを確認できます。

将来の使用に備える

証明書ファイルを取得したら、有効期限を書き留め、期限切れになる前に証明書を更新する計画を策定します。有効期限の 3 か月前にカレンダーでリマインダーを設定します。証明書を取得するために連絡した相手の名前を書き留めます (注文書、領収書、チケット番号を含む)。

また、次回のこの作業を行う可能性がある人物のために、この情報をシステム ドキュメントに含めます。

インターネットとの通信の設定に続きます。

追加リソース

ありがとうございます!