ドキュサインのエンタープライズ展開

組織における活用と管理方法

People walking

今回のブログでは、ドキュサインの電子署名(製品名:DocuSign eSignature)の企業全体への展開について考えてみたいと思います。この場合、企業全体で組織を構成し、この組織というもっとも大きな単位においてドキュサインのアカウントユーザーエンベロープを管理することになります。これらはDocuSign管理機能で設定管理を行います。

Enterprise

ドメイン

ここでは前提として、ユーザーの認証をSAML2.0対応のIdP(AzureAD, Okta, G Suite, HENNGE, OneLoginなど)を使ったシングルサインオンを利用するものとします。シングルサインオンの利用のためには、ドキュサインのユーザーアカウントを識別するためのメールアドレスのドメイン(例:@hogehoge.com)などが、その組織が管理しているということを証明する必要があります。これがドメイン予約です。

組織でドメインを予約することにより以下の制限ができ、これにより、企業におけるドキュサイン利用のガバナンスを強化することができます。

  • 常にIdP経由でのログインを行わせる
  • 管理されていないサインナップの禁止
  • ユーザーにエンベロープ開封時にログインを強制

ドメインの予約を行うには、ドキュサインの組織からユニークに発行されたテキストトークンを自社のDNSのTXTに追加する必要があります。これにより自社のドメインの所有を証明することができ、はじめてそのドメインのユーザーが組織でシングル・サインオンできることになります。

組織におけるドメインについては以下のようになります。

  • ドメインは複数登録可能
  • IdPも複数登録可能
    • IdPに対して複数のドメインのマッピングは可能(ドキュサイン側での設定)
    • 一つのドメインは複数のIdPに所属は不可

ユーザーのログインのポリシーを組織全体で決められます。IdP経由かドキュサインの認証のどちかかを組織全体のポリシーで設定します。個別のユーザーに対してログインポリシーの変更も可能です。このようにドメインのユーザーを一元化できます。

関連記事:毎日使うSaaSをSSOでまとめて管理して、利便性+セキュリティを一気に解決♪

管理者

組織管理においては、組織管理者がアカウント管理者と別に必要です。組織の管理者は完全な管理者のほか、設定管理者とユーザー管理者と細分化した管理者権限を割り当てることが可能です。

アカウント

組織にアカウントを追加します。アカウントは、一つのアカウントをサブアカウントに分割する方法と、個別契約のアカウントを追加する方法があります。サブアカウントに分割する場合は、契約をそのまま引き継ぎます。個別のアカウントの場合は、異なるエディションでも問題ありません。Part 11対応の場合は、サブアカウントでは対応できないので追加のアカウント契約が必要になります。

アカウントの数が多くなれば管理オーバーヘッドが増えることもありますので、必要なアカウント数になるように最適化する必要があります。サブアカウントが必要なケースは、「複数のDocuSignアカウントが 必要な場合」を参考にしてください。

サブアカウントの作成はドキュサイン側で実施します。サブアカウントも管理者がアクティベーションする必要があります。管理者が同じ場合は、複数サブアカウントを同時にアクティベーションできない点に注意してください。

作成されたサブアカウントは、デフォルト設定になり、親アカウントの設定などは自動で引き継ぎません。必要に応じて一括アクションにてアカウント設定のインポート・エクスポートなどを行うことができます。

関連記事:ドキュサインが定義する「アカウント」とは?

ユーザー

組織を介した、ドキュサインのユーザーに関しては、ユーザー作成(プロビジョニング)の必要があります。ユーザープロビジョニングは以下の方法があります。

  • ジャストインタイムプロビジョニング(JIT)を使って新規ログイン時にドキュサインユーザーを作成
    • アクティベーションをメールからユーザーが実施しない自動アクティベーションが可能
    • 組織で設定されたデフォルトアカウントとデフォルトの権限セットでユーザーが作成される
  • CSVファイルで組織から事前にユーザー作成を実施
    • 通常ユーザーは事前にアクティベーションメールからアクティベーションを実施だが、AutoActivateを有効化にすることも可能
  • APIを使った自動化

JITで作成する場合は、ユーザーが最初に作成されるデフォルトアカウトを組織で設定できます。ユーザーを事前作成すれば、JITによる作成は行われません。組織からはアカウント横断でユーザー作成および更新、クローズが可能です。ユーザーの属性や権限プロファイルなども指定する必要があります。

JITの機能は無効化できません。ですので、IdP側でドキュサインへのアクセス権限を与えれば、ドメインユーザーにドキュサインユーザーが作成されることになります。この場合、JITのデフォルトアカウントに運用上、企業内のなににも紐付かないアカウントに最低限の権限プロファイル(DS Viewer)でユーザーを一旦作成し、適時適切なアカウントへの登録することも考えられます。

JITでは、IdP側でドキュサインの属性情報とカスタムマッピングの情報が設定できれば、JITユーザー作成時のアカウントと権限プロファイルと言語をユーザー毎に指定することも可能です。このオプションがない場合はデフォルトアカウントへのプロビジョニングおよび言語は英語で設定されます。ユーザー操作で日本語に切り替えることは可能です。

ユーザーはCSVファイルにより組織横断で一括で更新もできます。一括のアクセス権の剥奪(クローズ)も可能です。ユーザーアカウントのクローズを行ってもアカウント内のエンベロープはそのままで影響はありません。

ユーザーは複数のアカウントへの所属が可能です。ただし、デフォルトアカウントを一つ持ちます。これはユーザー自身が設定可能です。

関連記事:【ドキュサイン活用術】ユーザーの管理方法

エンベロープ

アカウント内のユーザーは、エンベロープを取り扱います。

受信するエンベロープはデフォルトアカウントの受信箱から参照できます。また、署名や押印などの設定もデフォルトアカウントに従います。

また送信するアカウントは、ユーザーが手動でアカウント切り替えが可能で、そのアカウントから送信した場合に、送信箱に置かれます。アカウント内のエンベロープの所有権はエンベロープ所有者にありますが、組織管理下においては、(送信エンベロープに関しては)組織管理者がアカウントをまたいでエンベロープ所有権を転送することもできます。

企業の実組織の人事異動などに伴い、ユーザーの所属アカウントを変更する場合、それまでのアカウントにある、受信エンベロープは別のアカウントに引き継ぎをすることができません。

アカウントをまたいだユーザーメンテナンスが発生する場合、以下のようなパターンが考えられます。

  • 前所属アカウントをクローズし、新しいアカウントにユーザー作成
    • これまでのエンベロープはそのアカウント管理者が引き継ぎます。エンベロープ共有により受信エンベロープもアカウント内のユーザーに参照可能にすることができます。
  • 前所属アカウントをそのままに、新しいアカウントにユーザーを作成
    • 新アカウントをユーザーがデフォルトアカウントに設定し、送信は新規アカウントから実施、これまでの受信エンベロープは、アカウントを切り替えて引き続き参照できます。

関連記事:ドキュサインの電子署名に出てくるエンベロープっていったい何?

以上、比較的大きな組織でのドキュサインの運用体系についてご紹介しました。導入される企業や組織体系によって運用方法も異なってくると考えますが、上記を参考に、スケーラブルで柔軟性があり、コーポレートガバナンスを伴う運用をしていただければと思います。

公開
関連トピック