Server管理
認証
認証は、個人のIDを検証します。Serverでは、認証方法は システム設定 で設定します。管理者は、利用可能な4つの方法のいずれかを選択できます。
ビルトイン : Serverのユーザーインターフェース(Server UI)へのアクセスに使用するEメールアドレスとパスワードをユーザーが選択して指定します。
統合Windows認証 : ユーザーが内部ネットワーク資格情報でServerにアクセスできるようにします。
統合Windows Kerberos認証 : Kerberos認証プロトコルを使用して、ユーザーが内部ネットワーク資格情報でServer UIにアクセスできるようにします。
SAML認証 : ユーザーが認証IDプロバイダー(IDP)資格情報を使用してServer UIにアクセスできるようにします。
ビルトイン | IWA | SAML | |
|---|---|---|---|
認証メカニズム | E メールとパスワード | Windows ドメイン資格情報 | SAMLトークン |
資格情報ストレージ | MongoDB | ドメインコントローラー(Active Directory) | IDプロバイダー(IdP) |
アカウント作成 | ユーザーがサインアップまたは管理者が追加 | 自動 | IdP経由 |
グループ統合 | はい(コレクションとアクセス許可) 2020.4時点 | はい(コレクションとアクセス許可) | はい(コレクションとアクセス許可) 2020.4時点 |
セッションのタイムアウト | はい | いいえ | はい |
多要素 | いいえ | いいえ | はい |
重要
認証タイプは慎重に選択してください。一度選択したあとは、変更しないでください。MongoDBの構造は、認証タイプと密接に関連しています。認証を変更する場合は、サポートに連絡して計画を作成してください。
統合Windows認証は、最高の機能とユーザーエクスペリエンスを提供します。
組織でシングルサインオンソリューションが必要な場合は、SAMLを使用します。
ビルトイン認証は、たとえば一般公開アクセスが必要な場合や、使用可能なActive Directoryがない場合などに適しています。
これらの方法の詳細については、「 Server認証の設定 」を参照してください。
承認
認証は、ユーザーがServer UIで実行できるアクションを決定します。この場合、認証はユーザーのロールと権限によって決まります。次の表で、さまざまなロールで実行できるアクションを確認してください。詳細については、 ユーザーロールと権限 のヘルプページを参照してください。
グループ
グループは、Serverユーザーのグループです。グループの割り当てによってユーザーのロールを割り当てることができますが、ユーザー権限はプロファイルに明示的に関連付けられています。グループは、2つの方法で設定できます。Active DirectoryからActive Directory (AD)グループをインポートできます。Server UIからカスタムでユーザーのグループを作成することもできます。詳細については、 グループの管理 のヘルプページを参照してください。
Server構成のセキュリティ設定
構成設定では、ユーザー、ワークフロー、Server UIにグローバル設定を適用することにより、Serverのセキュリティレベルを強化できます。セキュリティに関しては、これらの設定を確認することが重要です。これらの設定により、Server UIで実行できるアクセスやアクションの許可または制限ができるためです。各設定を確認し、Serverのセキュリティを確保するためにはどのように適用すればよいかを確認してください。
既定のロール : 既定のロールは、ユーザーまたはグループ経由で割り当てられたロールを持たないすべてのユーザーに適用されます。既定のロールは、既定ではビューアーに設定されています。既定のロールを「アクセスなし」に設定すると、明示的に定義しない限りServer UIへのアクセスが防止され、セキュリティが強化されます。
ユーザーによる登録が可能 : この設定では、ログインページでサインアップオプションが有効になり、新規ユーザーがServer UIにアクセスするための新しいアカウントを作成できます。この設定は、ビルトインとSAMLの認証タイプでのみ使用できます。無効にした場合、Server管理者は明示的にアクセスを許可する必要があります。
未登録ユーザーがホームページでパブリックワークフローを実行できるようにする : 既定では、サインインしたユーザーのみがワークフローを実行できます。この設定を有効にすると、ホームページで公開されたワークフローをサインインせずに実行できます。パブリックワークフローの管理の詳細については、 Server UIホーム のヘルプページを参照してください。
ワークフローの資格情報の設定 :この設定は、Server UIでワークフローを実行するためにユーザーがワークフロー資格情報を入力する必要があるかどうかを制御します。
ユーザーによるワークフローのスケジュール設定が可能 : このServerレベルの設定により、環境レベルでジョブをスケジュールできるようになります。対応するユーザーレベルのジョブのスケジュール権限がユーザーにある場合は、Server UIでジョブをスケジュールできます。ユーザーレベルの設定の詳細については、 ユーザーロールと権限 のヘルプページを参照してください。
直接ダウンロードを無効にする : この設定により、ServerユーザーがServer UIからワークフローをダウンロードすることができなくなります。
これらの設定の詳細については、 Alteryx Server設定 のヘルプページを参照してください。
Run Asとワークフローの資格情報
既定では、Serverはシステムユーザーとしてワークフローを実行します。別のサービスアカウントを使用するようにServerを構成すると、Serverはそのアカウントを使用してワークフローを実行します。
ほとんどのワークフローでは、アクセス制御されたディレクトリに保存された入力ファイルと出力ファイルを必要とするため、Run Asユーザーを使用する必要があります。Run Asユーザーを使用すると、特定のユーザーとしてワークフローを実行できます。これにより、データソースへのアクセスとマシン上の権限の制御がサポートされます。Run Asユーザーを使用すると、エンジンがそのユーザーとしてワークフローを実行できます。これにより、保護されたファイルパスや、信頼できるWindows統合セキュリティ接続をサポートするデータベースの読み取りと書き込みが、ユーザー資格情報の必要なくアクセス可能になります。
API OAuthパラメーター
APIを使用する場合は、クエリパラメーターの代わりにヘッダーパラメーターOAuthパラメーターを使用することをお勧めします。詳細については、 Server API の概要 を参照してください。