【Alteryx Server運用】ユーザが作成したワークフローをAdminがアップロードする際の資格情報について

[Chikuma_Murakami]

Alteryx serverの運用で以下の点で困っています。

有識者の方、お手数ですが運用ルールについてアドバイスを頂きたく存じます。

前提条件

・どこにでもアクセス可能なマスターアカウント作成不可能

・DCMの共有はあまりしたくない（ID/PW共有扱いになる可能性あるため）

運用方法

１．ユーザがワークフロー作成

２．Adminにアップロード申請（WFも提出）

３．申請内容をもとに、Adminが入力元/出力先情報をテスト用から本番用に変更する（例: \\hogehoge\test.txt => \\hogehoge\prod.txt）

３．Adminがアップロード（必要に応じてスケジュール設定）

４．ユーザがテスト実行

問題

・ファイルベースの入出力の場合、ワークフロー内の入出力先パスを変更するだけでOKだが、DBの場合は入出力先を変更するのにDBアクセスの資格情報が必要になる。DCMごとサーバで共有することができるが、これは会社的にNG寄り。

・スケジュール実行設定をAdminがする際に、Adminがアクセス権がないところが入出力先になっている場合、適切なRun as User設定ができない

以前、ワークフローの入出力でDCMを使用していないという話を他企業の方から聞いたことがあります。また、ワークフロー内にID/PWを埋め込めるということも聞いたことがあります。このあたりがヒントとなるのでしょうか。

[AkimasaKajitani]

@Chikuma_Murakami さん

DCMのコラボレーション用の共有だとうまく行かないでしょうか？「共有されたユーザー：オーナーは認証情報を一部共有」だと認証情報は共有されないはずです・・・。

あと、DesignerとServerでDCMを同期する設定もあるのでこれも考慮した方が良い気がします。アップロード方向のみにするか、全禁止にする、というところです。

もしくは、おっしゃるとおり、DCM使わずに埋め込み、という手もあります（が、一部はDCM使わないと使えない認証方式もあるので要注意です）。

参考URL：

https://help.alteryx.com/current/ja/server/use-alteryx-server-ui/data-connection-manager--server-ui....

[gawa · Accepted solution]

@Chikuma_Murakami 「マスターアカウント作成不可」ということは、実在ユーザベースの認証情報あるいはローカルシステムアカウントが利用されるということですね。マスターアカウントが使えないとAlteryx Serverでのコラボレーションは結構難しく、どこかのタイミングで何かしらの形でユーザ認証情報の委譲・共有が避けられません。雑文で恐縮ですが、いくつかの方式でのPros/Consをまとめてみます：

1) DCMの共有

@AkimasaKajitani も書いていますが、DCMを共有してもID/PWは共有先に開示されず、利用権だけ与えられます。認証情報の共有という観点で、Alteryx Serverで最もSecureな方式といえます。DCM共有には以下２つの方式があります(DCM毎にどちらにするか選べます）：

1-1)Share for Collaboration

'Share for Collaboration'でDCMを共有すると、ユーザはDesignerでもServerでもDCMを使ってデータにアクセス可能です。Designer上でDCMを利用してWFを作れてしまうので、ユーザ側でDCMを利用してデータにアクセスされても、トレースできない。開発用DBは問題ないと思いますが、本番DBはこの方式での共有は避けた方が良いと思います。

1-2)Share to Run on Server Only

'Share to Run on Server Only'でDCMを共有すると、ユーザには当該DCMを含むWFをServerで実行する権限が与えられます。当該DCMを利用したWFをDesignerでは作成できないため、共有したDCMをユーザに勝手に使われないよう制御できます。今回のケースでは、ユーザから受け取ったWFの入出力のところを、Adminが保有しているDCMに書き換えたうえでServerにアップロードし、そのDCMを'Share to Run on Server Only'で実行ユーザに共有する流れになろうかと思います。

2) Credentialの共有　※Serverがドメイン参加している場合

ファイル入出力やMS SQLなどWindows認証ベースの入出力がある場合、ご指摘の通りRun Asに誰を指定すべきかは重要なポイントになります。Server Admin(Curator)であれば、Adminメニューの'Credential'でWindows資格情報を明示的に登録できます。例えばAdminユーザの資格情報をCredentialに登録しておき、そのCredentialを実行ユーザに共有するのが良いと思います。こうすることで、Credentialを共有されたユーザは、共有されたAdminのWindows資格情報でWFを実行可能です。(WF実行時に、共有されたCredentialがAuto Fillingされるので入力不要です。PWはマスクされますのでご安心ください）

ただ、この方式を使うのであれば、やはりマスターアカウントを作って、それを共有するのが望ましいです。ちなみに当社はそのようにしています。(部門やプロジェクトなど必要最低限の粒度で作る・アカウント管理者を決める・利用範囲と期間を限定する、などの工夫をしてガバナンスを損なわない運用を心がけています）

[Yoshiro_Fujimori]

> 以前、ワークフローの入出力でDCMを使用していないという話を他企業の方から聞いたことがあります。

弊社では DBへの接続 ではDCMではなく <データ接続> を使っています。

（DCMを使わないと使えない接続ではDCMを使っているのですが）

前提条件

DBに接続するための共通のIDが1個必要です。

（ただし 保存される接続文字列では下記の様な感じになり、Passwordは見えません）

odbc:DSN=ALX_Oracle;UID=alxuser;PWD=__EncPwd1__

提示頂いた運用方法にこれを当てはめると以下の様な流れになるかと思います。

1. Curator権限で データ接続 にアクセスできるユーザーを管理できる（<データ接続の共有>）
   この管理機能を使って、ユーザーにはテスト用DBへのデータ接続権限のみを与えておく
2. ユーザーはテスト用DBへのデータ接続でワークフローを作成する
3. 申請を受けた管理者がワークフローの接続を本番用DBへのデータ接続に書き換えてからアップロードする
4. 当該ワークフローの利用を限定する場合はコレクションに入れて共有する

このような運用を自分でやっている訳ではありませんので、そのまま使えるかは分かりませんが何かのご参考になれば幸いです。

[Yoshiro_Fujimori]

...と、言ったそばからで恐縮ですが、Alteryx社としては データ接続 より DCM を推しています。

(How to migrate Server Data Connections to DCM というブログ記事もあるくらいで...)

弊社の場合は DCM 以前から使っていたものが残っているものですので

これから接続定義をされるのであれば DCM を使うのが正道だと思います。

[Chikuma_Murakami]

@gawaさん
ご丁寧にご説明いただき、誠にありがとうございました。

アドバイスいただいた通り、小さい範囲のマスターアカウントを作成し、DCM共有で運用をするのが現実的かと思いました。

一方で、マスターアカウントでワークフローの入出力変更/サーバへアップロードを行う場合、マスターアカウントごとにライセンスが必要であるという問題があります。

また、自分の個人のアカウントで変更を行うには、個人アカウントが全てのDBへアクセスできるようにしてもらう必要が出てきます。

何かこのあたりで良い解決方法はありますでしょうか。

[gawa]

@Chikuma_Murakami 

Curatorの方が、複数のマスターアカウントによるDCMを一元管理し、WFごとにDCMを書き換える役を担うことでよいと思います。

マスターアカウントごとにDesignerで作業するようになると、ご指摘のようにライセンス本数も懸念ですし、「そのマスターアカウントとしてDesignerをいじる環境」を用意するのも大変です。

※本件と直接関係しませんが、Alteryx Serverにユーザ登録するだけであれば、追加ライセンス不要で、登録ユーザは無制限に増やせます。ご存じかもしれませんが、結構誤解の多いところなので念のため。

結論としては、あまり期待に沿えないかもしれませんが、Curatorの方にDBアクセス権が集中させることはトレードオフとして避けられないと思います。あるいは、開発と本番でステージングするという意味では、Sandboxライセンスで開発Serverをたて、WFのMigrationをするということになるかと思います。（Sandbox購入されているか分かりかねますが）

Server管理の話は、会社固有の制約事項・環境起因でベストプラクティスが様々なので、なかなか具体的な回答を提供できず申し訳ないです。