パート 5 - Web 層の構成

リファレンス アーキテクチャの Web 層には、次のコンポーネントが含まれている必要があります。

  • Tableau クライアントから HTTPS 要求を受け入れ、リバース プロキシ サーバーと通信する Web 用アプリケーション ロード バランサー。
  • リバース プロキシ: 
    • Tableau Server の独立したゲートウェイを導入することをお勧めします。
    • 冗長性とクライアント負荷の処理のために、少なくとも 2 台のプロキシ サーバーを使用することをお勧めします。
    • ロード バランサーから HTTPS トラフィックを受け取ります。
    • Tableau ホストへのスティッキー セッションをサポートします。
    • ゲートウェイ プロセスを実行している各 Tableau Server へのラウンド ロビン負荷分散用のプロキシを構成します。
    • 外部 IdP からの認証要求を処理します。
  • フォワード プロキシ: Tableau Server は、ライセンス認証とマップ機能のためにインターネットへアクセスできる必要があります。フォワード プロキシの許可リストに Tableau サービスの URL を設定する必要があります。「インターネットとの通信」 (Linux(新しいウィンドウでリンクが開く)) を参照してください。
  • クライアント関連のすべてのトラフィックは、HTTPS を介して暗号化可能:
    • クライアントからアプリケーションへのロード バランサー
    • リバース プロキシ サーバーへのアプリケーション ロード バランサー
    • Tableau Server へのプロキシ サーバー
    • IdP へのリバース プロキシで実行されている認証ハンドラ
    • IdP への Tableau Server

Tableau Server の独立したゲートウェイ

Tableau Server の独立したゲートウェイは、Tableau Server バージョン 2022.1 で導入されました。独立したゲートウェイは、Tableau 対応のリバース プロキシとして機能する Tableau ゲートウェイ プロセスのスタンドアロン インスタンスです。

独立したゲートウェイは、バックエンド Tableau Server への単純なラウンド ロビン負荷分散をサポートします。ただし、独立したゲートウェイは、エンタープライズ アプリケーションのロード バランサーとして機能するよう意図されていません。独立したゲートウェイは、エンタープライズ クラスのアプリケーション ロード バランサーの背後で実行することをお勧めします。

独立したゲートウェイには、Advanced Management ライセンスが必要です。

認証と認可

既定のリファレンス アーキテクチャでは、ローカル認証が構成された Tableau Server のインストールが指定されています。このモデルでは、クライアントは Tableau Server に接続して、ネイティブの Tableau Server ローカル認証プロセスによって認証される必要があります。このシナリオでは、認証されていないクライアントがアプリケーション層と通信する必要があり、セキュリティ上のリスクになるため、リファレンス アーキテクチャでこの認証方法を使用することはお勧めしません。

代わりに、AuthN モジュールと組み合わせてエンタープライズ グレードの外部 ID プロバイダーを構成して、アプリケーション層へのすべてのトラフィックを事前認証することをお勧めします。外部 IdP を使用して構成されている場合、ネイティブの Tableau Server ローカル認証プロセスは使用されません。Tableau Server は、IdP がユーザーを認証した後に、展開されているリソースへのアクセスを許可します。

AuthN モジュールによる事前認証

このガイドに記載されている例では、SAML SSO が構成されていますが、事前認証プロセスはほとんどの外部アイデンティティ プロバイダーおよび AuthN モジュールを使用して構成できます。

リファレンス アーキテクチャでは、リバース プロキシは、IdP を使用してクライアント認証セッションを作成してから、Tableau Server への要求をプロキシするように構成されています。このプロセスを事前認証フェーズと呼びます。リバース プロキシは、認証されたクライアント セッションのみを Tableau Server にリダイレクトします。Tableau Server はセッションを作成し、セッションの認証を IdP と確認してから、クライアント要求を返します。

次の図は、AuthN モジュールが構成された場合の事前認証と認証プロセスの詳細を示しています。リバース プロキシは、一般的なサードパーティ ソリューションでも、Tableau Server の独立したゲートウェイでもかまいません。

上の図に示されている手順。ステップ 1: Tableau クライアントが、Tableau Server のリソースを要求します。ステップ 2: リバース プロキシが、ID プロバイダーへの URL リダイレクトを使用して認証要求を作成します。ステップ 3: ID プロバイダーが、ログイン フォームをユーザーに送信します。ステップ 4: ユーザーにプロンプトが表示され、ユーザーが認証資格情報を入力します。ステップ 5: ID プロバイダーが、ユーザーによって送信された認証資格情報を確認します。ステップ 6: ID プロバイダーが、リバース プロキシ サービス プロバイダーに渡される埋め込み SAML アサーションを使用してクライアントに応答します。ステップ 7: プロキシ上のサービス プロバイダーが、アサーションを検証し、セッションを作成してから、Tableau Server 上のサービス プロバイダーにリダイレクトします。ステップ 8: Tableau Server 上のサービス プロバイダーが、ID プロバイダーへの認証要求を作成します。ステップ 9: ID プロバイダーが、現在のセッションを検証します。ステップ 10: Tableau Server 上のサービス プロバイダーが、独自のセッションを検証および作成し、応答をユーザーに送信します。ステップ 11: ユーザーが、指定されたリソースへの承認のために Tableau Server に接続します。

構成の概要

これは、Web 層を構成するプロセスの概要です。各ステップの後に接続を確認します。

  1. 2 つのリバース プロキシを構成して、Tableau Server に HTTP アクセスを提供します。
  2. プロキシ サーバー上でスティッキー セッションを使用して負荷分散ロジックを構成し、ゲートウェイ プロセスを実行している各 Tableau Server インスタンスに接続します。
  3. インターネット ゲートウェイでスティッキーセッションを使用してアプリケーションの負荷分散を構成し、リーバス プロキシ サーバーに要求を転送します。
  4. 外部 IdP を使用して認証を構成します。リバース プロキシ サーバーに認証ハンドラをインストールすることにより、SSO または SAML を構成できます。AuthN モジュールは、外部 IdP と Tableau 展開との間の認証ハンドシェイクを管理します。Tableau は IdP サービス プロバイダーとしても機能し、IdP を使用してユーザーを認証します。
  5. この展開で、Tableau Desktop を使用して認証するには、クライアントで Tableau Desktop 2021.2.1 以降が実行されている必要があります。

Tableau Server の独立したゲートウェイを使用した Web 層構成の例

このトピックの残りの部分では、Tableau Server の独立したゲートウェイを使用して Web 層を実装するためのエンドツーエンドの手順を、AWS 参照アーキテクチャの例で説明します。リバース プロキシとして Apache を使用する設定例については、「付録 - Apache の展開例を使用した Web 層」を参照してください。

この構成例には、次のコンポーネントが含まれています。

  • AWS アプリケーション ロード バランサー
  • Tableau Server の独立したゲートウェイ
  • Mellon 認証モジュール
  • Okta IdP
  • SAML 認証

: このセクションに示されている Web 層の構成例には、サードパーティーのソフトウェアとサービスを展開するための詳細な手順が含まれています。Web 層のシナリオを有効にする手順や文書の検証には最善を尽くしていますが、サードパーティーのソフトウェアが変更される場合や、シナリオがここで説明されている参照アーキテクチャと異なっている場合があります。正式な構成の詳細情報とサポートについては、サードパーティーのドキュメントを参照してください。

このセクションの Linux の例では、RHEL のようなディストリビューションのコマンドを示します。具体的には、これらのコマンドは Amazon Linux 2 ディストリビューションで開発されたものです。Ubuntu ディストリビューションを実行している場合は、状況に応じてコマンドを編集してください。

この例の Web 層の展開では、段階的な構成と検証の手順に従います。コア Web 層を構成するには、次のステップを実行して、Tableau とインターネット間の HTTP を有効にします。AWS アプリケーション ロード バランサーの背後でリバース プロキシと負荷分散を行うために、独立したゲートウェイを実行し、設定します。

  1. 環境の準備
  2. 独立したゲートウェイのインストール
  3. 独立したゲートウェイ サーバーの構成
  4. AWS アプリケーション ロード バランサーを構成します。

Web 層を設定して Tableau との接続を確認したら、外部プロバイダーを使用して認証を構成します。

環境の準備

独立したゲートウェイを展開する前に、次のタスクを完了してください。

  1. AWS セキュリティ グループの変更。独立したゲートウェイのハウスキーピングを行う、Private セキュリティ グループからのインバウンド通信 (TCP 21319) を許可するように、Public セキュリティ グループを設定します。

  2. パート 4 - Tableau Server のインストールと構成」で説明されているように、バージョン 22.1.1 (またはそれ以降) を 4 ノードの Tableau Server クラスタにインストールします。

  3. ホスト コンピューターを構成する」で説明されているように、パブリック セキュリティ グループに 2 つのプロキシ EC2 インスタンスを構成します。

独立したゲートウェイのインストール

Tableau Server の独立したゲートウェイには、Advanced Management ライセンスが必要です。

Tableau Server の独立したゲートウェイは、.rpm パッケージをインストールして実行し、初期状態を設定することにより導入します。このガイドの手順は、参照アーキテクチャに導入するための規範的なガイダンスです。

導入環境が参照アーキテクチャと異なる場合は、Tableau Server のコア ドキュメントである「独立したゲートウェイを使用した Tableau Server のインストール (Linux(新しいウィンドウでリンクが開く))」を参照してください。

重要: 独立したゲートウェイを構成する作業は、エラーが発生しやすいプロセスです。独立したゲートウェイ サーバーの 2 つのインスタンス間で構成の問題をトラブルシューティングすることは非常に困難です。このため、独立したゲートウェイ サーバーは一度に 1 つ構成することをお勧めします。最初のサーバーを構成した後、機能を確認してから、2 つ目の独立したゲートウェイ サーバーを構成します。

独立したゲートウェイの各サーバーは別々に設定しますが、Public セキュリティ グループにインストールした両方の EC2 インスタンスで次のインストール手順を実行します。 

  1. アップデートを実行して、Linux OS に最新の修正を適用します。

    sudo yum update

  2. Apache がインストールされている場合は、Apache を削除します。

     sudo yum remove httpd
  3. バージョン 2022.1.1 以降の独立したゲートウェイのインストール パッケージを Tableau ダウンロード ページ(新しいウィンドウでリンクが開く)から、Tableau Server を実行するホスト コンピューターにコピーします。

    たとえば、Linux RHEL のようなオペレーティング システムを実行しているコンピューターでは、次のコマンドを実行します。

    wget https://downloads.tableau.com/esdalt/2022<version>/tableau-server-tsig-<version>.x86_64.rpm

  4. インストール プログラムを実行します。たとえば、Linux RHEL のようなオペレーティング システムでは、次のコマンドを実行します。

    sudo yum install <tableau-tsig-version>.x86_64.rpm

  5. /opt/tableau/tableau_tsig/packages/scripts.<version_code>/ ディレクトリに変更し、そのディレクトリにあるスクリプト initialize-tsig を実行します。--accepteula フラグに加えて、Tableau Server デプロイメントを実行しているサブネットの IP 範囲を含める必要があります。-c オプションを使用して IP 範囲を指定します。AWS サブネット (例) を指定したコマンドの例を次に示します。

    sudo ./initialize-tsig --accepteula -c "ip 10.0.30.0/24 10.0.31.0/24"

  6. 初期化が完了したら、tsighk-auth.conf ファイルを開き、認証シークレットをファイルにコピーします。バックエンドの Tableau Server を構成するときに、独立したゲートウェイのインスタンスごとに次のコードを送信する必要があります。

    sudo less /var/opt/tableau/tableau_tsig/config/tsighk-auth.conf

  7. 独立したゲートウェイの両方のインスタンスで前の手順を実行した後、tsig.json 構成ファイルを準備します。構成ファイルは、「independentGateways」(独立したゲートウェイ) 配列で構成されています。配列では、独立したゲートウェイのインスタンスに対する各接続の詳細を定義する構成オブジェクトを保持します。

    次の JSON をコピーして、ご利用の導入環境に応じてカスタマイズします。この例は、サンプルの AWS 参照アーキテクチャ用のファイルを示しています。

    以下のサンプル JSON ファイルには、1 つの独立したゲートウェイの接続情報のみが含まれています。プロセスの後半で、2 つ目の独立したゲートウェイ サーバーの接続情報を含めます。

    この後の手順のために、ファイルを tsig.json という名前を付けて保存します。

    {
    "independentGateways": [
     {
     	"id": "ip-10-0-1-169.ec2.internal",
     	"host": "ip-10-0-1-169.ec2.internal",
     	"port": "21319",
     	"protocol" : "http",
     	"authsecret": "13660-27118-29070-25482-9518-22453"
     	}]
     }

    • "id" - 独立したゲートウェイを実行している AWS EC2 インスタンスのプライベート DNS の名前。
    • "host" - "id" と同じ。
    • "port" - ハウスキーピングポート。デフォルトでは "21319"
    • "protocol" - クライアント トラフィックのプロトコル。初期設定ではこれを http のままにしておきます。
    • "authsecret" - 前の手順でコピーしたシークレット。

独立したゲートウェイ: 直接接続とリレー接続

先に進む前に、ご利用の導入環境で設定する接続方式 (直接接続またはリレー接続) を決定する必要があります。ここでは、各オプションについて、関連する意思決定のデータ ポイントとともに簡単に説明します。

リレー接続: クライアント通信を単一のポートで Tableau Server のゲートウェイ プロセスに中継するように独立したゲートウェイを構成することができます。この通信をリレー接続と呼びます。

  • 中継プロセスにより、独立したゲートウェイからバックエンドの Tableau Server ゲートウェイ プロセスへの余分なホップが発生します。余分なホップのために、パフォーマンスは直接接続の構成と比較して低下します。
  • TLS は、リレー モードでサポートされています。リレー モードでのすべての通信は単一のプロトコル (HTTP または HTTPS) に制限されているため、TLS で暗号化および認証できます。

直接接続: 独立したゲートウェイは、複数のポートを介してバックエンドの Tableau Server プロセスと直接通信できます。この通信を直接接続と呼びます。

  • バックエンドの Tableau Server に直接接続されるため、クライアントのパフォーマンスはリレー接続オプションと比較して大幅に向上します。
  • 独立したゲートウェイから Tableau Server コンピューターへの直接プロセス通信には、パブリック サブネットからプライベート サブネットに 16 個以上のポートを開く必要があります。
  • TLS は、独立したゲートウェイから Tableau Server へのプロセスではまだサポートされていません。

Tableau Server と独立したゲートウェイの間で TLS を実行するには、リレー接続を使用して構成する必要があります。EDG のサンプル シナリオは、リレー接続を使用して構成されています。

  1. tsig.json を Tableau Server 展開のノード 1 に移動します。

  2. ノード 1 で次のコマンドを実行して、独立ゲートウェイを有効にします。

    tsm stop
    tsm configuration set -k gateway.tsig.proxy_tls_optional -v none
    tsm pending-changes apply
    tsm topology external-services gateway enable -c tsig.json
    tsm start

直接接続は TLS をサポートしていないため、すべてのネットワーク トラフィックを他の手段で保護できる場合にのみ、直接接続を構成することをお勧めします。Tableau Server と独立したゲートウェイの間で TLS を実行するには、リレー接続を使用して構成する必要があります。EDG のサンプル シナリオは、リレー接続を使用して構成されています。

独立したゲートウェイを Tableau Server に直接接続するように構成している場合は、通信をトリガーするように構成を有効にする必要があります。Tableau Server が独立したゲートウェイと通信すると、プロトコルのターゲットが確立されます。次に、proxy_targets.csv を独立したゲートウェイのコンピューターから取得する必要があります。AWS のパブリック セキュリティ グループからプライベート セキュリティ グループへの対応するポートを開きます。

  1. tsig.json を Tableau Server 展開のノード 1 に移動します。

  2. ノード 1 で次のコマンドを実行して、独立ゲートウェイを有効にします。

    tsm stop
    tsm topology external-services gateway enable -c tsig.json
    tsm start
  3. 独立したゲートウェイのコンピューターで次のコマンドを実行して、Tableau Server クラスタが使用しているポートを表示します。

    less /var/opt/tableau/tableau_tsig/config/httpd/proxy_targets.csv
  4. AWS セキュリティ グループを構成します。proxy_targets.csv にリストされている TCP ポートを追加し、パブリック セキュリティ グループからプライベート セキュリティ グループへの通信を許可します。

    Tableau Server 展開が変更されるとポートが変更される可能性があるため、ポート入力構成を自動化することをお勧めします。Tableau Server 展開にノードを追加したり、プロセスを再構成したりすると、Independent Gateway が必要とするポート アクセスが変更されます。

検証: 基本トポロジ構成

http://<gateway-public-IP-address> をブラウザーに表示すると、Tableau Server の管理ページにアクセスできます。

Tableau Server サインイン ページが読み込まれない場合、または Tableau Server が起動しない場合は、次のトラブルシューティング ステップに従ってください。

ネットワーク: 

  • Tableau Server ノード 1 から wget コマンド (wget http://<独立したゲートウェイの内部 IP アドレス>:21319) を実行して、Tableau の展開と独立したゲートウェイ インスタンスの間の接続を確認します。このコマンドの例は次のとおりです。

     wget http://ip-10-0-1-38:21319

    接続が拒否されるか、失敗する場合は、独立したゲートウェイのハウスキーピングを行う、プライベート セキュリティ グループからのトラフィック (TCP 21319) を許可するようにパブリック セキュリティ グループが構成されていることを確認します。

    セキュリティ グループが正しく構成されている場合は、独立したゲートウェイの初期化中に正しい IP アドレスまたは IP 範囲を指定したことを確認します。/etc/opt/tableau/tableau_tsig/environment.bash にある environment.bash ファイルの構成を表示して変更できます。このファイルに変更を加えた場合は、以下の説明に従って、tsig-http サービスを再起動します。

プロキシ ホスト 1 で次の手順を実行します。

  1. httpd.conf ファイルを独立したゲートウェイのスタブ ファイルで上書きします。

    cp /var/opt/tableau/tableau_tsig/config/httpd.conf.stub /var/opt/tableau/tableau_tsig/config/httpd.conf
  2. 最初のトラブルシューティング手順として、tsig-httpd を再起動します。
    sudo su - tableau-tsig
    systemctl --user restart tsig-httpd
    exit

Tableau ノード 1 で次の手順を実行します。

  • tsig.json ファイルをもう一度チェックします。エラーを見つけた場合は、修正してから tsm topology external-services gateway update -c tsig.json を実行します。
  • 直接接続を実行している場合は、proxy_targets.csv にリストされている TCP ポートが、パブリック セキュリティ グループからプライベート セキュリティ グループへの入力ポートとして構成されていることを確認してください。

AWS アプリケーション ロード バランサーの構成

ロード バランサーを HTTP リスナーとして構成します。ここでの手順では、AWS にロード バランサーを追加する方法について説明します。

ステップ 1: ターゲット グループの作成

ターゲット グループは、プロキシ サーバーを実行する EC2 インスタンスを定義する AWS 構成です。これらは、LBS からの通信のターゲットになります。

  1. [EC2] > [ターゲット グループ] > [ターゲット グループの作成] の順に選択

  2. [作成] ページで次を実行

    • ターゲット グループ名を入力 (例: TG-internal-HTTP)
    • ターゲット タイプ: インスタンス
    • プロトコル: HTTP
    • ポート: 80
    • VPC: お使いの VPC を選択
    • [ヘルス チェック] > [ヘルス チェックの詳細設定] > [成功コード] で、読み取るコードの一覧 200,303 を追加します。
    • [作成] をクリック
  3. 作成したターゲット グループを選択し、[ターゲット] タブをクリックします。 

    • [編集] をクリックします。
    • プロキシ アプリケーションを実行している EC2 インスタンス (または一度に 1 つずつ構成している場合は単一のインスタンス) を選択し、[登録済みに追加] をクリックします。
    • [保存] をクリックします。

ステップ 2: ロード バランサー ウィザードの起動

  1. [EC2] > [ロード バランサー] > [ロード バランサーの作成] を選択

  2. [ロード バランサーの種類の選択] ページで、アプリケーション ロード バランサーを作成

: ロードバランサーを構成するために表示される UI は、AWS データセンター全体で一貫性がありません。以下の「ウィザードの構成」の手順は、ステップ 1 ロードバランサーの構成から始まる AWS 構成ウィザードにマッピングされます。 

データセンターですべての構成が単一のページに表示され、ページの下部に [ロード バランサーの作成] ボタンが含まれている場合は、以下の「単一ページの構成」の手順に従います。

  1. [ロード バランサーの構成] ページで次を実行

    • 名前を指定
    • スキーム: インターネットへ接続 (デフォルト)
    • IP アドレス タイプ: ipv4 (デフォルト)
    • リスナー (リスナーとルーティング):
      1. HTTP リスナーは既定のままにします
      2. [リスナーの追加] をクリックして HTTPS:443 を追加します
    • VPC: すべてをインストールした VPC を選択
    • アベイラビリティー ゾーン:
      • データセンターのリージョンとして ab を選択
      • 対応する各ドロップダウンから、パブリック サブネット (プロキシ サーバーがある場所) を選択
    • [セキュリティ設定の構成] をクリック
  2. [セキュリティ設定の構成] ページで次を実行

    • パブリック SSL 証明書をアップロード
    • [次へ: セキュリティ グループの構成] をクリック
  3. [セキュリティ グループの構成] ページで次を実行

    • パブリック セキュリティ グループを選択します。既定のセキュリティ グループが選択されている場合は、その選択をクリアする
    • [次へ: ルーティングの構成] をクリック
  4. [ルーティングの構成] ページで次を実行

    • ターゲット グループ: 既存のターゲット グループ
    • 名前: 以前に作成したターゲット グループを選択
    • [次へ: ターゲットの登録] をクリック
  5. [ターゲットの登録] ページで次を実行

    • 以前に構成した 2 つのプロキシ サーバー インスタンスが表示される
    • [次へ: レビュー] をクリック
  6. [レビュー] ページで次を実行

    [作成] をクリックします。

基本構成

  • 名前を指定
  • スキーム: インターネットへ接続 (デフォルト)
  • IP アドレス タイプ: ipv4 (デフォルト)

ネットワーク マッピング

  • VPC: すべてをインストールした VPC を選択
  • マッピング:
    • データセンターのリージョンとして、ab (または同等の) アベイラビリティー ゾーンを選択
    • 対応する各ドロップダウンから、パブリック サブネット (プロキシ サーバーがある場所) を選択

セキュリティ グループ

  • パブリック セキュリティ グループを選択します。既定のセキュリティ グループが選択されている場合は、その選択をクリアする
  • リスナーとルーティング

    • HTTP リスナーは既定のままにします。[Default action (既定のアクション)] で、以前設定したターゲット グループを指定します。
    • [リスナーの追加] をクリックして HTTPS:443 を追加します。[Default action (既定のアクション)] で、以前設定したターゲット グループを指定します。

    セキュリティで保護されたリスナー設定

    • パブリック SSL 証明書をアップロード

    [ロード バランサーの作成] をクリックします。

    ステップ 3: スティッキネスの有効化

    1. ロード バランサーを作成したら、ターゲット グループでスティッキネスを有効にする必要がある

      • AWS ターゲット グループ ページ ([EC2] > [ロード バランス] > [ターゲット グループ]) を開き、セットアップしたロード バランサーのインスタンスを選択します。[アクション] メニューで [属性の編集] を選択します。
      • [属性の編集] ページで [スティッキー] を選択して、期間 "1 day" を指定し、[変更を保存] します。
    2. ロード バランサーで、HTTP リスナーのスティッキネスを有効化。構成したロード バランサーを選択し、[リスナー] タブをクリックする

      • [HTTP:80] で、[ルールの表示/編集] をクリックします。表示される [ルール] ページで、編集アイコンを (ページ上部で 1 回、ルールのそばでもう 1 回) クリックして、ルールを編集します。既存の THEN ルールを削除し、[アクションの追加] > [転送先...] をクリックしてルールを置き換えます。結果の THEN 構成で、作成したものと同じターゲット グループを指定します。[Group-level stickiness (グループ レベルのスティッキー)] で、スティッキーを有効にし、期間を 1 日に設定します。設定を保存し、[更新] をクリックします。

    ステップ 4: ロード バランサーでアイドル タイムアウトを設定する

    ロード バランサーで、アイドル タイムアウトを 400 秒に更新します。

    この展開で構成したロード バランサーを選択し、[アクション] > [属性の編集] の順にクリックします。アイドル タイムアウト400 秒に設定し、[保存] をクリックします。

    ステップ 5: LBS 接続の検証

    [EC2] > [ロード バランサー] から [AWS ロード バランサー] ページを開き、設定したロード バランサー インスタンスを選択します。

    [説明] で DNS 名をコピーしてブラウザーに貼り付け、Tableau Server のサインイン ページにアクセスします。

    500 レベルのエラーが発生した場合は、プロキシ サーバーを再起動する必要がある場合があります。

    パブリック Tableau URL で DNS を更新

    AWS ロード バランサーの説明にあるドメイン DNS ゾーン名を使用して、DNS に CNAME 値を作成します。URL (tableau.example.com) へのトラフィックは、AWS パブリック DNS 名に送信する必要があります。

    接続の確認

    DNS の更新が完了すると、パブリック URL (たとえば、https://tableau.example.com) を入力して、Tableau Server のサインイン ページに移動できるようになります。

    認証構成の例: 外部 IdP を使用した SAML

    次の例では、AWS 参照アーキテクチャで実行されている Tableau の展開のために、Okta IdP と Mellon 認証モジュールを使用して SAML の設定と構成を行う方法について説明します。

    この例は前のセクションからの抜粋であり、独立したゲートウェイを一度に 1 つ構成することを前提としています。

    この例では、 HTTP を介した Tableau Server と Independent Gateway を設定する方法を説明します。Okta は HTTPS を介して AWS ロード バランサーに要求を送信しますが、すべての内部トラフィックは HTTP を介して伝送されます。このシナリオ用に構成する場合は、URL 文字列を設定するときに HTTP プロトコルと HTTPS プロトコルに注意してください。

    この例では、独立したゲートウェイ サーバー上の事前認証サービス プロバイダー モジュールとして Mellon を使用しています。この構成により、認証されたトラフィックのみが Tableau Server に接続されます。Tableau Server は、Okta IdP を使用したサービス プロバイダーとしても機能します。したがって、2 つの IdP アプリケーションを構成する必要があります。1 つは Mellon サービス プロバイダー用で、もう 1 つは Tableau サービス プロバイダー用です。

    Tableau 管理者アカウントの作成

    SAML を構成する際のよくある間違いは、SSO を有効にする前に、Tableau Server で管理者アカウントを作成するのを忘れることです。

    最初のステップでは、サーバー管理者ロールを持つ Tableau Server でアカウントを作成します。Okta シナリオの例では、ユーザー名は、user@example.com などの有効なメール アドレスの形式である必要があります。このユーザーのパスワードを設定する必要がありますが、SAML を構成した後はパスワードは使用されません。

    Okta 事前認証アプリケーションの構成

    このセクションで説明するエンドツーエンドのシナリオには、2 つの Okta アプリケーションが必要です。

    • Okta 事前認証アプリケーション
    • Okta Tableau Server アプリケーション

    これらの各アプリケーションは、リバース プロキシと Tableau Server でそれぞれ構成する必要がある異なるメタデータに関連付けられています。

    この手順では、Okta 事前認証アプリケーションを作成および構成する方法について説明します。このトピックの後半で、Okta Tableau Server アプリケーションを作成します。ユーザー制限が設定されている無料のテスト Okta アカウントについては、Okta Developer Web ページ(新しいウィンドウでリンクが開く)を参照してください。

    Mellon 事前認証サービス プロバイダー用の SAML アプリ統合を作成します。

    1. Okta 管理ダッシュボード > [アプリケーション] > [アプリ統合の作成] を開きます。

    2. [新しいアプリ統合の作成] ページで [SAML 2.0] を選択し、[次へ] をクリックします。

    3. [一般設定] タブでアプリ名 (たとえば、Tableau Pre-Auth) を入力し、[次へ] をクリックします。

    4. [SAML の構成] タブで、次を設定します。

      • シングル サインオン (SSO) URLシングル サインオン URL のパスの最後の要素は、この手順の後半で説明する mellon.conf 構成ファイルの中で MellonEndpointPath と呼ばれます。必要なエンドポイントを指定できます。この例では sso がエンドポイントです。https://tableau.example.com/sso/postResponse の最後の要素 postResponse は必須です。
      • [Use this for Recipient URL and Destination URL (受信者 URL と宛先 URL 用に使用する)] チェックボックスをオフにします。
      • 受信者 URL: SSO URL と同じですが、HTTP を使用します。たとえば、http://tableau.example.com/sso/postResponse のように使用します。
      • 宛先 URL: SSO URL と同じですが、HTTP を使用します。たとえば、http://tableau.example.com/sso/postResponse のように使用します。
      • オーディエンス URI (SP エンティティ ID): たとえば、https://tableau.example.com のように使用します。
      • 名前 ID の形式: EmailAddress
      • アプリケーションのユーザー名: Email
      • 属性ステートメント: 名前 = mail。名前の形式 = Unspecified。値 = user.email

      [次へ] をクリックします。

    5. [フィードバック] タブで、次を選択します。

      • [I'm an Okta customer adding an internal app (私は Okta の顧客であり、内部アプリを追加しています)]
      • [これは私たちが作成した内部アプリです]
      • [完了] をクリックします。
    6. 事前認証 IdP メタデータ ファイルを作成します。

      • Okta で、[アプリケーション] > [アプリケーション] > 使用する新しいアプリケーション (例: Tableau Pre-Auth) > [サインオン] を選択します。
      • [SAML Signing Certificates (SAML 署名証明書)] の横にある [View SAML setup instructions (SAML セットアップ手順の表示)] をクリックします。
      • [How to Configure SAML 2.0 for <pre-auth> Application (<pre-auth> アプリケーションの SAML 2.0 を構成する方法)] ページで、[Optional (オプション)] セクションの [Provide the following IDP metadata to your SP provider (次の IDP メタデータを SP プロバイダーに指定する)] まで下にスクロールします。
      • XML フィールドのコンテンツをコピーして、pre-auth_idp_metadata.xml というファイルに保存します。
    7. (オプション) 多要素認証を構成します。

      • Okta で、[アプリケーション] > [アプリケーション] > 使用する新しいアプリケーション (例: Tableau Pre-Auth) > [サインオン] を選択します。
      • [サインオン ポリシー] の下で、[ルールの追加] をクリックします。
      • [アプリのサインオン ルール]で、名前とさまざまな MFA オプションを指定します。機能をテストするには、すべてのオプションを既定のままにします。ただし、[アクション] で、[係数の確認] を選択してから、ユーザーがサインインする必要がある頻度を指定する必要があります。[保存] をクリックします。

    Okta ユーザーの作成と割り当て

    1. Okta で、[ディレクトリ] > [ユーザー] > [ユーザーの追加] を選択し、Tableau で作成したのと同じユーザー名 (user@example.com) でユーザーを作成します。
    2. ユーザーが作成されたら、新しい Okta アプリをそのユーザーに割り当てます。ユーザー名をクリックしてから、[アプリケーションの割り当て] でアプリケーションを割り当てます。

    Mellon を事前認証用にインストール

    この例では、人気のあるオープン ソース モジュールである mod_auth_mellon を使用しています。一部の Linux ディストリビューションでは、廃止された mod_auth_mellon バージョンを古いリポジトリからパッケージ化しています。これらの廃止されたバージョンには、未知のセキュリティの脆弱性や機能上の問題が含まれている可能性があります。mod_auth_mellon を使用する場合は、現在のバージョンを使用していることを確認してください。

    mod_auth_mellon モジュールはサードパーティ製ソフトウェアです。このシナリオを有効にする手順や文書の検証には最善を尽くしていますが、サードパーティー製ソフトウェアが変更される場合や、シナリオがここで説明されている参照アーキテクチャと異なっている場合があります。正式な構成の詳細情報とサポートについては、サードパーティーのドキュメントを参照してください。

    1. 独立したゲートウェイを実行しているアクティブな EC2 インスタンスで、最新バージョンの Mellon 認証モジュールをインストールします。

    2. /etc/mellon ディレクトリを作成します。

      sudo mkdir /etc/mellon

    Mellon を事前認証モジュールとして構成

    この手順を、独立したゲートウェイの最初のインスタンスで実行します。

    Okta 構成から作成した pre-auth_idp_metadata.xml ファイルのコピーがある必要があります。

    1. ディレクトリを変更します。

      cd /etc/mellon

    2. サービス プロバイダーのメタデータを作成します。スクリプト mellon_create_metadata.sh を実行します。コマンドには、組織のエンティティ ID と戻り URL を含める必要があります。

      戻り URL は、Okta では シングル サインオン URL と呼ばれます。戻り URL のパスの最後の要素は、この手順の後半で説明する mellon.conf 構成ファイルの中で MellonEndpointPath と呼ばれます。この例では、エンドポイント パスとして sso を指定します。

      例:

      sudo /usr/libexec/mod_auth_mellon/mellon_create_metadata.sh https://tableau.example.com "https://tableau.example.com/sso"

      スクリプトが、サービス プロバイダーの証明書、キー、およびメタデータ ファイルを返します。

    3. 読みやすくするために、mellon ディレクトリ内のサービス プロバイダー ファイルの名前を変更します。今後このドキュメントでは、これらのファイルを次の名前で参照します。

      sudo mv *.key mellon.key
      sudo mv *.cert mellon.cert
      sudo mv *.xml sp_metadata.xml

    4. pre-auth_idp_metadata.xml ファイルを同じディレクトリにコピーします。

    5. /etc/mellon ディレクトリ内のすべてのファイルの所有権と権限を変更します。

      sudo chown tableau-tsig mellon.key
      sudo chown tableau-tsig mellon.cert
      sudo chown tableau-tsig sp_metadata.xml
      sudo chown tableau-tsig pre-auth_idp_metadata.xml 
      sudo chmod +r * mellon.key
      sudo chmod +r * mellon.cert
      sudo chmod +r * sp_metadata.xml
      sudo chmod +r * pre-auth_idp_metadata.xml 

    6. /etc/mellon/conf.d ディレクトリを作成します。

      sudo mkdir /etc/mellon/conf.d
    7. global.conf ファイルを /etc/mellon/conf.d ディレクトリに作成します。

      以下のようにファイルの内容をコピーしますが、MellonCookieDomain をルート ドメイン名で更新します。たとえば、Tableau のドメイン名が tableau.example.com の場合、ルート ドメインとして example.com を入力します。

      <Location "/">
      AuthType Mellon
      MellonEnable auth
      Require valid-user
      MellonCookieDomain <root domain>
      MellonSPPrivateKeyFile /etc/mellon/mellon.key
      MellonSPCertFile /etc/mellon/mellon.cert
      MellonSPMetadataFile /etc/mellon/sp_metadata.xml
      MellonIdPMetadataFile /etc/mellon/pre-auth_idp_metadata.xml
      MellonEndpointPath /sso
      </Location>
      
      <Location "/tsighk">
      MellonEnable Off
      </Location>
    8. mellonmod.conf ファイルを /etc/mellon/conf.d ディレクトリに作成します。

      このファイルは、mod_auth_mellon.so ファイルの場所を指定する単一のディレクティブを保持します。この例の場所は、ファイルのデフォルトの場所です。ファイルがこの場所にあることを確認するか、このディレクティブのパスを変更して、mod_auth_mellon.so の実際の場所と一致させます。

      LoadModule auth_mellon_module /usr/lib64/httpd/modules/mod_auth_mellon.so

    Okta で Tableau Server アプリケーションを作成

    1. Okta ダッシュボードで、[アプリケーション] > [アプリケーション] > [アプリ カタログの参照] を選択します。
    2. [アプリ統合カタログの参照] で、Tableau を検索して、Tableau Server タイルを選択し、[追加] をクリックします。
    3. [Tableau Server の追加] > [一般設定] を選択して、ラベルを入力し、[次へ] をクリックします。
    4. [サインオン オプション] で [SAML 2.0] を選択してから、[サインオンの詳細設定] まで下にスクロールします。
      • [SAML エンティティ ID]: パブリック URL (たとえば、https://tableau.example.com) を入力します。
      • [アプリケーションのユーザー名の形式] では、メールを指定します。
    5. [Identity Provider metadata (アイデンティティ プロバイダーのメタデータ)] リンクをクリックして、ブラウザーを起動します。ブラウザーのリンクをコピーします。このリンクは、次の手順で Tableau を構成するときに使用します。
    6. [完了] をクリックします。
    7. 新しい Tableau Server Okta アプリをユーザー (user@example.com) に割り当てます。ユーザー名をクリックし、[アプリケーションの割り当て] でアプリケーションを割り当てます。

    Tableau Server で認証モジュールを設定する

    Tableau Server ノード 1 で以下のコマンドを実行します。これらのコマンドは、リモートの独立したゲートウェイ コンピューター上の Mellon 構成ファイルに対してファイルの場所を指定します。これらのコマンドで指定したファイル パスが、リモートの独立したゲートウェイ コンピューター上のパスとファイルの場所にマッピングされていることをもう一度チェックします。

    tsm configuration set -k gateway.tsig.authn_module_block -v "/etc/mellon/conf.d/mellonmod.conf" --force-keys
    tsm configuration set -k gateway.tsig.authn_global_block -v "/etc/mellon/conf.d/global.conf" --force-keys

    ダウンタイムを減らすために、次のセクションで説明するように、SAML を有効にするまで変更を適用しないでください。

    IdP 用の Tableau Server で SAML を有効化

    Tableau Server ノード 1 で次の手順を実行します。

    1. Okta から Tableau Server アプリケーションのメタデータをダウンロードします。前の手順で保存したリンクを使用します。

      wget https://dev-66144217.okta.com/app/exk1egxgt1fhjkSeS5d7/sso/saml/metadata -O idp_metadata.xml

    2. TLS 証明書および関連するキー ファイルを Tableau Server にコピーします。キー ファイルは RSA キーである必要があります。SAML 証明書と IdP 要件の詳細については、「SAML 要件」を参照してください (Linux(新しいウィンドウでリンクが開く))。

      証明書の管理と展開を簡素化するため、およびセキュリティのベスト プラクティスとして、信頼性の高い主要なサード パーティーの認証局 (CA) によって生成された証明書を使用することをお勧めします。または、自己署名証明書を生成するか、TLS 用の PKI からの証明書を使用することもできます。

      TLS 証明書を持っていない場合は、以下の埋め込み手順に従って自己署名証明書を生成できます。

      自己署名証明書の生成

      Tableau Server ノード 1 でこの手順を実行します。

      1. ルート認証局 (CA) の署名キーを生成します。

        openssl genrsa -out rootCAKey-saml.pem 2048

      2. ルート CA 証明書を作成します。

        openssl req -x509 -sha256 -new -nodes -key rootCAKey-saml.pem -days 3650 -out rootCACert-saml.pem

        証明書フィールドに値を入力するように求められます。例:

        Country Name (2 letter code) [XX]:US
        State or Province Name (full name) []:Washington
        Locality Name (eg, city) [Default City]:Seattle
        Organization Name (eg, company) [Default Company Ltd]:Tableau
        Organizational Unit Name (eg, section) []:Operations
        Common Name (eg, your name or your server's hostname) []:tableau.example.com
        Email Address []:example@tableau.com
      3. 証明書と関連キー (この例では server-saml.csr と server-saml.key) を作成します。証明書のサブジェクト名は、Tableau ホストのパブリック ホスト名と一致する必要があります。サブジェクト名は、-subj オプションと "/CN=<host-name>" の形式を使用して設定します。例:

        openssl req -new -nodes -text -out server-saml.csr -keyout server-saml.key -subj "/CN=tableau.example.com"

      4. 上記で作成した CA 証明書を使用して、新しい証明書に署名します。次のコマンドも crt 形式で証明書を出力します。

        openssl x509 -req -in server-saml.csr -days 3650 -CA rootCACert-saml.pem -CAkey rootCAKey-saml.pem -CAcreateserial -out server-saml.crt

      5. キー ファイルを RSA に変換します。Tableau では、SAML 用の RSA キー ファイルが必要です。キーを変換するには、次のコマンドを実行します。

        openssl rsa -in server-saml.key -out server-saml-rsa.key

    3. SAML を構成します。次のコマンドを実行して、エンティティ ID とリターン URL を指定し、メタデータ ファイル、証明書ファイル、キー ファイルへのパスを指定します。

      tsm authentication saml configure --idp-entity-id "https://tableau.example.com" --idp-return-url "https://tableau.example.com" --idp-metadata idp_metadata.xml --cert-file "server-saml.crt" --key-file "server-saml-rsa.key"

      tsm authentication saml enable

    4. 組織で Tableau Desktop 2021.4 以降を実行している場合は、次のコマンドを実行して、リバース プロキシ サーバーを介した認証を有効にする必要があります。

      事前認証モジュール (Mellon など) がトップレベル ドメインの Cookie を保持できるように構成されている場合、Tableau Desktop バージョン 2021.2.1 ~ 2021.3 は、このコマンドを実行しなくても動作します。

      tsm configuration set -k features.ExternalBrowserOAuth -v false

    5. 構成の変更を適用します。

      tsm pending-changes apply

    tsig-httpd サービスを再起動する

    Tableau Server の展開で変更を適用したら、Tableau Server の独立したゲートウェイ コンピューターに再度サインインし、次のコマンドを実行して、tsig-httpd サービスを再起動します。

    sudo su - tableau-tsig
    systemctl --user restart tsig-httpd
    exit

    SAML 機能の検証

    エンドツーエンドの SAML 機能を検証するには、この手順の最初に作成した Tableau 管理者アカウントからパブリック URL (https://tableau.example.com など) を使用して Tableau Server にサインインします。

    TSM が起動しない場合 (「ゲートウェイ エラー」)、または接続しようとしたときにブラウザ エラーが発生する場合は、「Tableau Server の独立したゲートウェイのトラブルシューティング」を参照してください。

    独立したゲートウェイの 2 つ目のインスタンスで認証モジュールを構成

    独立したゲートウェイの最初のインスタンスを正常に構成したら、2 つ目のインスタンスをデプロイします。この例は、本トピックで説明する AWS / Mellon / Okta シナリオをインストールするための最終プロセスです。この手順では、このトピック (独立したゲートウェイのインストール) で前述したように、独立したゲートウェイが 2 つ目のインスタンスにすでにインストールされていることを前提としています。

    2 つ目の独立したゲートウェイをデプロイするプロセスでは、次の手順が必要です。

    1. 独立したゲートウェイの 2 つ目のインスタンスで Mellon 認証モジュールをインストールします。

      このトピックで前述したように Mellon 認証モジュールを構成しないでください。その代わり、以降の手順で説明しているように、構成のクローンを作成します。

    2. 独立したゲートウェイの構成済み (最初の) インスタンスで次の手順を実行します。

      既存の Mellon 構成の tar コピーを取得します。この tar バックアップでは、すべてのディレクトリ階層と権限を保持しています。次のコマンドを実行します。

      cd /etc
      sudo tar -cvf mellon.tar mellon

      mellon.tar を、独立したゲートウェイの 2 つ目のインスタンスにコピーします。

    3. 独立したゲートウェイの 2 つ目のインスタンスで、次の手順を実行します。

      tar ファイルを /etc ディレクトリの 2 目のインスタンスに抽出 (「解凍」) します。次のコマンドを実行します。

      cd /etc
      sudo tar -xvf mellon.tar

    4. Tableau Server 展開のノード 1: 接続ファイル (tsig.json) を 2 つ目の独立したゲートウェイの接続情報を使用して更新します。このトピックで前述したように (Independent Gatewayのインストール)、認証キーを取得する必要があります。

      接続ファイルの例 (tsig.json) は次のとおりです。

      {
      "independentGateways": [
       {
         "id": "ip-10-0-1-169.ec2.internal",
         "host": "ip-10-0-1-169.ec2.internal",
         "port": "21319",
         "protocol" : "http",
         "authsecret": "13660-27118-29070-25482-9518-22453"
       },
       {
         "id": "ip-10-0-2-230.ec2.internal",
         "host": "ip-10-0-2-230.ec2.internal",
         "port": "21319",
         "protocol" : "http",
         "authsecret": "9055-27834-16487-27455-30409-7292"
       }]
       }
    5. Tableau Server 展開のノード 1: 次のコマンドを実行して構成を更新します。

      tsm stop
      tsm topology external-services gateway update -c tsig.json
      
      tsm start
    6. 独立したゲートウェイの両方のインスタンスで Tableau Server が起動しているときに、tsig-httpd プロセスを再起動します。

      sudo su - tableau-tsig
      systemctl --user restart tsig-httpd
      exit
    7. AWS EC2 > ターゲット グループ: ターゲット グループを更新して、2 つ目の独立したゲートウェイのインスタンスを実行している EC2 インスタンスを含めます。

      作成したターゲット グループを選択し、[ターゲット] タブをクリックします。 

      • [編集] をクリックします。
      • 2 つ目の独立したゲートウェイ コンピューターの EC2 インスタンスを選択して [登録済みに追加] をクリックし、[保存] をクリックします。
    フィードバックをお送りいただき、ありがとうございます。フィードバックは正常に送信されました。ありがとうございます!