リリースに関する考慮事項について
学習の目的
- Identity Connect をユーザープロビジョニングに使用するための基本的な要件を説明する。
- どのような場合に保護されたネットワーク内または DMZ 内で Identity Connect を使用するかを説明する。
- Identity Connect のインスタンスおよび環境を定義する。
- 高可用性クラスターについて説明する。
- Identity Connect を複数の組織および複数のドメインに使用できるかどうかを判断する。
リリースアーキテクチャ
ここでは、Identity Connect のリリースに必要なネットワークリソースを見ていきましょう。これは肝心なポイントです。Identity Connect をネットワークにどのようにリリースしますか? ネットワークのどこに配置しますか? Identity Connect を実行する専用サーバーは必要ですか? 高可用性をどのように確保しますか?
Salesforce システム管理者にとってはさほど重要なことではないかもしれません。けれども、ネットワークエンジニアにとって重要事項であることに間違いありません。この単元では、IT 部門が抱くであろう質問にお答えします。Jedeye Technologies では新規に Identity Connect のリリースを検討しており、適切に行いたいと考えています。この単元の情報を参考に、リリースに協力することができます。
Identity Connect は、ファイアウォールの内側に存在し、データを Salesforce に転送するオンプレミス型のソフトウェアです。Identity Connect のサーバーは企業ネットワーク内で実行され、LDAP(S) 経由で AD サーバーと通信します。クラウドにある Salesforce とは HTTPS を介して通信します。ネットワークエンジニアと連携し、適切なファイアウォールポートが開いていて、Identity Connect が AD と Salesforce の両方と確実に接続できるようにします。
専用サーバーは必要か?
必ずしもそうとは言えません。Identity Connect を共有サーバーにインストールする場合は、Identity Connect に適切なリソースがあり、Java のサポートされているバージョンが実行されていることを確認します。
他のすべてのアプリケーションも同じバージョンで実行可能であることをチェックします。あるいは、Identity Connect 専用の Java のインスタンスをインストールします。
Identity Connect のデフォルトの OrientDB データベースを使用する場合、同じサーバーでインスタンスを 2 つ以上実行することはできません。そのため、1 台のマシンで複数のテスト環境をサポートする場合は、MySQL や MS SQL のような外部データベースを使用します。
ファイアウォールを使用しているが問題になるか?
Identity Connect は、ファイアウォールの内側に存在し、データを Salesforce に転送するオンプレミス型のソフトウェアです。
多くの企業はファイアウォールを使用して、企業ネットワーク外からのインバウンド接続を制御する一方で、アウトバウンドトラフィックを許可しています。つまり、オフィスからはインターネットにアクセスできますが、自宅やコーヒーショップから内部リソースにアクセスするには VPN に接続している必要があります。
DMZ (Demilitarized Zone: 非武装地帯) とは、内部ネットワークを、インターネットなど信頼できない他のネットワークと隔離するサブネットワークです。ただし、DMZ もオンプレミスで、企業ネットワーク内に存在します。Identity Connect はファイアウォールの内側ではなく、DMZ にインストールできます。
Identity Connect を SSO に使用する場合、次の事項に該当するときは Identity Connect を DMZ に配置します。
- ユーザーは、信頼できるネットワーク外から Salesforce にログインする。こうすると、外部ユーザーが VPN を使用しなくても Identity Connect ログインページにアクセスできます。
- ユーザーがモバイルデバイスから Salesforce にログインできるようにする。DMZ に配置しない場合は、ユーザーがモバイル VPN に接続している必要があります。
Identity Connect を複数の組織に使えるか?
もちろんです。Identity Connect は複数の Salesforce 組織で機能するように設計されています。このすべての組織を同時に管理するように Identity Connect を設定できます。
各組織は独自の Identity Connect の対応付けがあるため、組織ごとにユーザーの属性やエンタイトルメントを制御できます。
Jedeye Tech では銀河系全域の惑星に従業員が存在し、エアリアル惑星にある中央 AD で全員を管理しています。惑星ごとに個別の Salesforce 組織を配備する一方で、エアリアルの AD サーバーおよび Identity Connect サーバーから全ユーザーを管理することができます。
Identity Connect を複数の AD ドメインに使えるか?
Identity Connect は 1 つの AD ドメインに機能するように設計されています。けれども、Identity Connect を複数の AD ドメインに使用することも可能です。
最近 Treble Association を買収した Jedeye Technologies では、複数ドメインの設定が役立っています。Treble でも AD を使用しているためです。AD を利用して、Treble Association のユーザーが各自の AD ログイン情報で Salesforce にすぐアクセスできるようになります。Salesforce ユーザー名とパスワードを求める必要がありません。
2 つの AD ドメインに Identity Connect を設定する場合は、2 つの方法があります。グローバルカタログを使用してすべてのドメインに対応する 1 つの Identity Connect 環境を設定するか、ドメインごとに新しい Identity Connect を設定します。
すべての AD ドメインに 1 つの Identity Connect で対応
1 つの Identity Connect 環境を設定する場合は、グローバルカタログを使用します。グローバルカタログとは、すべての AD ドメインのユーザーおよびグループのあらゆる情報を中央リポジトリに結集させる特殊なドメインコントローラーです(ドメインコントローラーとは、AD がインストールされているコンピューターです)。
Identity Connect は、このカタログに接続して、両方のディレクトリのすべてのユーザーとグループを管理します。
各 AD ドメインに個々の Identity Connect 環境で対応
AD ドメインごとに個別の Identity Connect を設定する場合は、Jedeye Tech の AD ドメインには一方の Identity Connect 環境が、Treble Association の AD ドメインにはもう一方の Identity Connect 環境が接続します。
ここ Salesforce では、Salesforce を ExactTarget と統合したときにこの Identity Connect 設定を使用しました。ExactTarget に Identity Connect の個別のインスタンスを設定し、ExactTarget のユーザーがすぐにアクセスできるようにしました。その後、ユーザーを徐々に Salesforce ドメインに移行しました。
HA (高可用性) クラスターについてはどうか?
複数のサーバーからなる Identity Connect クラスターをリリースすると、1 つのサーバーがダウンしても Identity Connect を機能させることができます。この方法では、ネットワークで Identity Connect が常時使用可能であることを保証できます。
プライマリサーバーがダウンしても、バックアップサーバーが継続的に要求を処理します。この形態を高可用性クラスターといいます。
高可用性クラスターの場合、Identity Connect のプライマリインスタンスが設定のすべての変更をデータベースに書き込みます。プライマリサーバーに障害が発生した場合に処理を続行するセカンダリサーバーに Identity Connect をインストールできます。プライマリインスタンスがダウンしても、データベースが引き続き使用可能であれば、セカンダリサーバーが機能を引き継ぎます。
Identity Connect をプロビジョニングのみに使用する場合は、高可用性クラスターが不要なこともあります。状況に応じて判断してください。不測の事態でサーバーがダウンすると、その間は新規採用者に対するプロビジョニングや退職者に対する解除が行われません。このリスクを厭わないのであれば、通常の設定のほうが簡単です。
Identity Connect を SSO に使用する場合は、1 か所の障害による不具合の拡大を回避するために、複数のインスタンスからなるクラスターに Identity Connect を設定します。全社ごと Salesforce にログインできなくなれば、大問題です。
大規模な組織で高可用性クラスター設定を行う場合は、ロードバランサーと MySQL データベースを設定することをお勧めします。ロードバランサーは、SSO ログイン要求を Identity Connect の各インスタンスに分散させます。1 つがダウンしても、ロードバランサーが別のインスタンスにログインするようユーザーをリダイレクトします。MySQL データベースは、Identity Connect の設定をセカンダリサーバーに格納するために使用します。
この設定の利点は、Identity Connect を複数のサーバーにインストールする場合に追加料金が発生しないことです。競合製品は CPU ごとに課金されます。Salesforce のライセンスは、ハードウェアではなくユーザー数に基づきます。Identity Connect の設定は、価格ではなく、障害発生時の回復度に基づいて判断してください。
ロードバランサーは必要か?
ロードバランサーを使用すると、AD ドメインコントローラーがオフラインになっても、認証やプロビジョニングに影響しなくなります。
他方、ロードバランサーや LiveSync (ライブ更新) を使用する場合は、特定のドメインコントローラーに固定される設定にすることをお勧めします。ドメインコントローラーがオンラインである限りそのコントローラーを使い続けるようにすると、LiveSync プロセスの信頼性が高まります。
SSO での Identity Connect の使用は?
Identity Connect の利点は、SSO の設定に簡単に使用できることです。1 回のクリックでユーザーが設定されます。
属性を対応付けたら、SSO を利用するために必要な情報がすべて Identity Connect に備わります。
SSO ソリューションをすでに実装している場合は、Identity Connect をプロビジョニングに使用するときに SSO ソリューションを利用できます。Identity Connect は既存のあらゆる SSO ソリューションと適切に連動します。
本番組織と Sandbox 組織を同じ環境に設置できるか?
できません。ただし、複数の本番組織を管理するように Identity Connect を設定することはできます。また、複数の非本番組織を管理するように Identity Connect を設定することもできます。けれども、1 つの Identity Connect 環境に本番組織と Sandbox 組織を混在させることはできません。
その理由は次のとおりです。
- Sandbox は通常、維持や管理がさほど厳格ではありません。Sandbox で対応付けられた権限セットやロールを誰かが削除しても、Identity Connect は引き続き管理しようとします。つまり、エラーが集積していきます。スループットが低下し、何もプロビジョニングされなくなります。イライラが募ります。
- 本番組織と Sandbox 組織を隔離しておくことで、Sandbox の設定の問題が本番組織に影響を及ぼしているかどうかを Salesforce サポートが判断しやすくなります。
テスト環境を作成する方法は?
Sandbox で本格的な設定テストを行う場合、大半のお客様は Full Sandbox またはユーザー受け入れテスト (UAT) Sandbox で Identity Connect 設定のテストを行います。
Full Sandbox の利点
- メンテナンスが最小限で済む。インスタンスの更新頻度が少なく、多くの場合はユーザーが本番組織のユーザーと同じです。
- 本番の AD アカウントを使用できる。
UAT Sandbox (本番環境の完全レプリカ) の利点は、次の目的で使用が可能だということです。
- 本番にリリースする前の最終検証を行う。
- 本番への影響を回避するために Identity Connect のパッチをテストする。
