ActiveDirectoryをクラウド統合し、ID管理する方法

ID管理サービスで、ADをクラウドに移行する

Active Directory (AD)は、MicrosoftがWindows 2000 Serverで最初にリリースした1999年から存在しています。長年にわたり、IDベースの関連活動を管理するための重要なオンプレミスサービスとなっています。しかし、クラウドサービスやアプリケーションに対する需要の高まりに伴い、昨今の企業はADがクラウド中心の世界や今日のユースケース向けに構築されたものではないことに気づき始めています。

それでも、ADへの投資を無駄にしたりフルリプレイスするのではなく有効活用し、最新のシングル・サインオン(SSO)の利点を活用して、クラウドとオンプレミスのすべてのアプリケーションとリソースに単一のインターフェイスを通じてアクセスできるようにしながら、管理上のオーバーヘッドを削減する方法を求めています。

このため、先進的なIT企業は、レガシーなAD環境とクラウドネイティブなID管理サービスのSSOを目指し、統合することを検討しています。ID管理サービスとの統合は、従業員が使用したいサービスやリソースに簡単かつ安全に接続するためのゲートウェイを提供します。このドキュメントでは、その統合の計画と実装を支援するために、ADからID管理サービスへの統合の機能的および運用的な側面についての技術的な洞察を提供します。

ID管理サービスの提供するActive Directoryエージェント(ADエージェント)

ADからID管理サービスへの統合の中心にあるのは、ADエージェントです。これは、ID管理サービスとローカルのADインスタンス間のインターフェイスを提供します。ID管理サービスとADエージェントの設計はスケーラブルな性質を持っており、必要に応じてより多くのユーザーを追加し、より多くのADエージェントを簡単に展開することができます。そしてADエージェントは安全なアウトバウンド通信を採用し、ロングポーリングによるロードバランシングとジョブ管理を提供します。長い期間有効な認証用のリフレッシュ・トークンを使用するエージェントを、ADドメイン内の専用ローカル・メンバー・サーバーにインストールします。エージェントを再起動したり再インストールしたりする必要がある場合、ドメインコントローラに影響を与えることになるため、いかなる場合も、エージェントをドメインコントローラにインストールすべきではありません。この点は気をつけましょう。

次にADエージェントの2つの主要な機能について説明します。

そのうちの1つ目は委任認証(代理認証とも呼ばれます)であり、これによりオンプレミスのADインスタンスを認証ソースとして継続して使用することができます。委任認証では、すべてのパスワードがAD内に残り、ADがそのユーザーはID管理サービスにアクセスできるかどうかを決定します。ユーザーを使用してリソースにアクセスする場合、ID管理サービスはそれらのリソースで認証をオンプレミスの ADディレクトリに試行します。認証されると、ADはID管理サービスにユーザーに割り当てられたリソースへのアクセスを許可します。

ADエージェントの2つ目の主な機能は、関連する属性を持つユーザーとグループをADからID管理サービスにインポートすることです。インポートプロセスは、指定したADの組織単位(OU)に存在するすべてのユーザーオブジェクトに対して、ID管理サービスに新しいユーザーオブジェクトを作成します。その後、ID管理サービスはそれぞれのADとID管理サービスのユーザーをリンクします。これにより、ID管理サービスは必要に応じて に保存されているユーザーオブジェクトに影響を与えることなく、ユニバーサルディレクトリに保存されているオブジェクトのユーザー属性を変更することができます。ユーザーをID管理サービスに参加させることで、ユーザーが必要とするリソースがオンプレミスにあるかクラウドにあるかにかかわらず、ユーザーが必要とするリソースに対して集中的なSSOを提供するなど、ID管理サービスの機能セットを活用することができます。

アクティブ/アクティブとロングポーリング

ID管理サービスは、ADエージェントを、プライマリまたはセカンダリのエージェントを持たないアクティブ/アクティブ構成で展開します。その結果、エージェントを積極的にロードバランシングする必要はありません。配置されたすべてのエージェントは常にアクティブであり、それらのジョブを処理する能力が許す限り、常に新しいジョブを探すために長時間のポーリングを使用します。そのため、従来のクライアントサーバーの関係で起こるようなエージェントからのリクエストを待つのではなく、ID管理サービスはエージェントからのリクエストを待つことになります。
長時間のポーリングモデルでは、ID管理サービスは継続的にジョブをジョブプールにプッシュし、エージェントは可能な限りすぐにジョブを取得します。ジョブはほぼすぐに取得されるため、待ち時間がなくなり、ジョブの処理時間を短縮できます。従来のモデルでは起こりえなかったことです。

ADエージェント接続

ID管理サービスの提供するADエージェントは、TLS サーバー認証を使用して証明書を使用して、ID管理サービスのクラウドサーバーへのアウトバウンドHTTPS 接続を作成します。そしてその各接続は30 秒間持続します。その接続時間の間、ADエージェントはAD認証イベントなど、処理できるID管理サービスからのイベントを受信する事ができます。もし何かしらのイベントが受信された場合、AD エージェントは処理のためにそれを使用し、通信を終了します。その後、ADエージェントは直ちに新しい接続を開き、新しいジョブを再度受信します。接続の30秒ウィンドウの間にイベントが現れない場合、エージェントは接続を閉じ、新しい30秒接続を開始して 別のジョブを探索します。

ADエージェントの権限付与

認証レベルでの通信はID管理サービスのAPIに対して認証するために、APIトークンとしても知られるベアラートークンを使用してADエージェントとの間で行われます。ADエージェントはID管理サービスへの各リクエストでHTTP認可ヘッダー内にそのトークンを渡します。ADエージェントは、エージェントの展開中にOAuthフローを介してトークンを取得します。

展開プロセスの一部として、管理者はトークンの登録を承認する必要があります。ベアラートークンの有効期限は30日ですが、スライディングスケールの有効期限を使用しているため、ADエージェントは自動的に更新します。トークンはリクエストが発生し続ける限り、各リクエストの有効期限を継続します。

ADエージェントのジョブ管理

認証ジョブは迅速に処理する必要のある頻繁に発生する小さなジョブであり、インポートジョブは時間がかかるかなり大きなジョブであるため、ID管理サービスではジョブタイプごとに異なるワークロード配分方法を使用しています。これにより、ID管理サービスはジョブタイプの固有の違いにうまく対応することができます。利用可能なエージェントはすべて認証ジョブを処理することができます。そのため、ID管理サービスは個々の認証ジョブに対して、利用可能なエージェントのプールからランダムにエージェントを選択します。

インポートジョブでは、優先エージェントを使用します。最初のエージェントの割り当てはランダムですが、ID管理サービスはその後のタスクでは、そのエージェントが が圧倒されているか、利用できない場合があります。その時点で、ID管理サービスはインポートタスクを処理するために別のエージェントを割り当てます。デフォルトでは、ID管理サービスは各エージェントを2つのスレッドで構成します。しかし、エージェントの通信要求に対応するために必要であれば、最大10スレッドでエージェントを構成することができます。通常、リアルタイムかつダウンタイムに認証タスクを処理するために、常に1つのスレッドがエージェント内で利用可能な状態になっています。例えば、エージェントがインポートジョブを発行された場合、ID管理サービスは追加のジョブが完了するまで、そのエージェントにジョブをインポートしますが、そのエージェントの2番目のスレッドは、常時受け入れ可能なままの状態になります。

ID管理サービスとのAD統合の計画

ADとの統合(インテグレーション)を計画し、構築する際には、それぞれの違いを理解することが重要です。ユーザー認証機能とユーザーインポート機能を比較してみましょう。以下のような場合には、例えばこれらのジョブタイプの頻度とそのユーザーの操作性に異なる影響を与えます。ActiveDirectory(AD)とID管理サービスの統合と同じくらい、いつそれぞれが各ジョブタイプを実行するかどうかは重要です。ユーザーのサイズを知ることよりも、重要ではないにしても同じベースを使用しています。統合計画を支援するために 構築の取り組みでは、他の記事で詳しく紹介しているので、是非他の記事もご覧ください。

ユーザー認証ジョブ

ユーザーが認証のためにID管理サービスのUserインターフェースに資格情報を入力すると、ID管理サービスはそのユーザーがADによりマスタリングされたユーザーであるかどうかを判断します。ユーザーがADマスタリングされたユーザーである場合、ID管理サービスはユーザーのディレクトリインスタンスに関連付けられたジョブリストに認証要求を追加します。認証ジョブがジョブリストに追加されると、ID管理サービスはジョブのポーリングを行っている利用可能なADエージェントにランダムにジョブを割り当て、割り当てられたエージェントが実行しているサーバー上でジョブを開きます。

次に、ADエージェントは、ユーザー・プリンシパル名(UPN)などのAD統合設定で指定されたユーザー名の形式を使用して、ユーザーのルックアップを実行します。エージェントがユーザを見つけると、ユーザによって入力された資格情報を使用して、ADインスタンスへのBINDを実行します。次の引用は、ADエージェントがユーザを見つけるために使用するUPNクエリの例です。

(&(sAMAccountType=123456789) (userPrincipalName=useraa@example.com))

ユーザーのインポートに比べて、ユーザー認証のジョブは迅速に実行されます。統合の設定が完了した瞬間に、エージェントは大量の認証を実行し始めることができます。必要に応じて、統合の一部として複数の追加エージェントを配置して、認証のためにより多くのリソースを割り当てることができます。

認証用のADエージェントを追加で配置する理由の1つは、季節的な傾向のニーズに対応するためかもしれません。例えば小売店では、ホリデーシーズンに大きな変動が発生することがよくあります。高可用性の必要性も、組織が認証用のADエージェントを追加で導入することが多い理由の 1 つです。

さらに、グローバルな組織では、異なる地理的な場所のそれぞれに近接した場所に、追加の AD エージェントを配備することがよくあります。ドメインコントローラまたはドメインコントローラプールに近接しているメンバーサーバ上にADエージェントを配備することで、認証中のレイテンシを減らすことができます。前述したように ADエージェントは、ドメインコントローラ上ではなく、専用のメンバーサーバ上にのみ展開するようにすることが重要です。

ユーザーインポートジョブ

ユーザーインポートは、スケジュールされたインポートのいずれかによって開始することができます。または手動でインポートします。どちらの方法も ID管理サービスにアクセスし、そのジョブを優先エージェントに割り当てます。認証ジョブと同様に、ADエージェントはID管理サービスに手を伸ばし、ジョブをプルダウンし、エージェントを実行しているローカル・サーバ上でそれを開き、ジョブを実行します。エージェントはまず、AD構造全体のトポロジーの読み取りを実行します。エージェントは次にユーザーとグループを更新し、インクリメンタル・インポートの場合には、各オブジェクトに対して読み込んだusnChanged AD属性値に基づいてインポートを実行します。読み込んだオブジェクトのスコープは、各オブジェクトで有効にしたID管理サービスの保持するテナントのAD連携設定がADエージェントのインポート設定に反映されます。

以下は、ADエージェントが実行するインポートクエリジョブの例です。

トポロジー読込: (|(objectCategory=organizationalUnit)
(&(objectCategory=container)
(!showInAdvancedViewOnly=TRUE))
ユーザーアカウント読み込み:(&(&(sAMAccountType=805306368)
(uSNChanged>=889511)(uSNChanged<=889547)

一度サーバーがインポートを実行すると、そのサーバーが優先インポートサーバーになることを覚えておくことが重要です。つまりそれ以降のインポートジョブは、ADエージェントから同じサーバーに送られることになります。その結果、ADエージェントを複数のサーバーに配置した場合、インポート・ジョブはそれらすべてのサーバーに分散されることはありません。代わりに、現在の優先順位の高いサーバーを選択することになります。さらに、インポートの速度はディレクトリのサイズ、インポートスコープ、頻度に依存することを理解することが重要です。例えば、前回のインポート以降に更新された数百万人のユーザーを含む10,000 OUを含むインポートスコープは、5,000 OUと更新されていないユーザーを含むインポートよりも時間がかかります。

リアルタイム同期を行うジョブ

ユーザー認証とユーザーのインポートに加えて、ジャストインタイム(JIT)更新を有効にしている場合、ID管理サービスのADエージェントはリアルタイム同期ジョブも実行します。リアルタイム同期ジョブは、ユーザー属性、グループメンバーシップ、およびログイン時にID管理サービスで新しいグループを作成します。これを行うためにADエージェントは、ランダムに選択されたADサーバーへのBINDを実行します。BINDが成功するとサーバーは、現在のユーザーが属するグループ・セキュリティ識別子(SID)のリストを含むセキュリティ・トークンを受け取ります。それに対してADエージェントは、このトークンからSIDを引き出し、SIDを使用してローカルSIDキャッシュ内のグループを見つけ、ID管理サービスがユーザーをグループに追加できるようにメンバーシップをID管理サービスに送信します。ローカル・キャッシュにSIDが存在しない場合、エージェントはAD内でSIDを検索します。

ADと連携することで生まれる大きなメリット

ADとID管理サービスをADエージェントで統合することで、次のことが可能になります。現代のアプリケーションを最大限に活用するためにモバイルアプリ、SaaSアプリ、オンプレミスアプリなど、これらのアプリをID管理サービスに追加することで、自動的にアクセスできるようになります。

ID管理サービスはまた、次のようなことも簡単にできます。ID管理サービスのマスター機能群を介してアプリへのアクセスを確保するために、ポリシー、リスクベース認証を用いた多要素認証(MFA)、およびパスワードレスを実現するようなオプションもあります。ID管理サービスを活用することでID管理サービスのRADIUSエージェントとID管理サービスのLDAPインターフェースを利用し、セキュリティ機能の一部を拡張することもできます。これを実行することで、Wi-Fiルーターは勿論VPNなどのローカルネットワーク機器、その他のネットワークアプライアンスとの連携を実現することも可能です。

アイデンティティ・アクセス管理(IAM)により、ユーザーとしての従業員がアクセスするための単一のログイン・インターフェースを提供することができます。彼らが必要とするすべてのアプリやサービスは、セキュリティ責任者の管理上の負担を大幅に削減し、IDのライフサイクルに依存するアプリの提供開始をより早くすることができます。またこれは、ユーザーによりシームレスで一貫性のあるアクセスを提供することにも繋がります。そしてそれは全体的にセキュリティを強化することにもつながるのです。レガシーな認証はセキュリティホールになりかねません。モダンな認証機能を利用することは現代社会において必須の事項です。

ADは、現在のお客様の環境に欠かせない存在となっています。しかしそれはレガシーな環境を前提とした過去のことです。勿論AD自体は将来的にも価値を提供し続けることができますが、現代ではその多くの利点を活用しながら、より効率的にセキュリティの実現、従業員のUX強化、ID管理サービスの手間のない管理を実現する必要があります。ADの役割が変わる時が来ているのです。ID管理サービスは、増え続ける現代的なアプリへの安全なアクセスを簡単に実現するサービスを提供しています。ID管理サービスを介することで、全てのシステム・リソースに安全に接続することができるようにし、ビジネスを推進するために必要な柔軟性を提供します。

SNSでもご購読できます。

コメントを残す

*