ActiveMQ ブローカーの LDAP との統合 - Amazon MQ
LDAP を ActiveMQ に統合する前提条件LDAP の使用開始LDAP 統合の仕組み

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

ActiveMQ ブローカーの LDAP との統合

重要

RabbitMQ ブローカーでは LDAP 統合はサポートされません。

ActiveMQ ブローカーには、TLS が有効化されている以下のプロトコルを使用してアクセスできます。

Amazon MQ では、ユーザー許可の管理に、ネイティブ ActiveMQ 認証か LDAP 認証と認可のどちらかを選択できます。ActiveMQ のユーザー名とパスワードに関する制限の詳細については、「Users」を参照してください。

ActiveMQ のユーザーおよびグループによるキューとトピックの使用を認可するには、ブローカーの設定を編集する必要があります。Amazon MQ は、ActiveMQ の Simple Authentication Plugin を使用して、送信先に対する読み込みと書き込みを制限します。詳細情報と例については、「認可マップを常に設定する」および「authorizationEntry」を参照してください。

注記

現在、Amazon MQ はクライアント証明書認証をサポートしていません。

LDAP を ActiveMQ に統合する

Amazon MQ ユーザーは、Lightweight Directory Access Protocol (LDAP) サーバーに保存されている認証情報を使用して認証することができます。これを使用して、Amazon MQ ユーザーの追加、削除、変更、およびトピックとキューへの許可の割り当てを行うことも可能です。ブローカーの作成、更新、および削除といった管理操作には引き続き IAM 認証情報が必要となり、これらは LDAP と統合されません。

LDAP サーバーを使用した Amazon MQ ブローカーの認証と認可の簡素化と一元化を希望するお客様は、この機能を使用できます。すべてのユーザー認証情報を LDAP サーバーに保存することにより、これらの認証情報を保存して管理する一元的な場所が提供されるため、時間と労力を節約できます。

Amazon MQ は、Apache ActiveMQ JAAS プラグインを使用して LDAP サポートを提供します。このプラグインがサポートする LDAP サーバー (Microsoft Active Directory や OpenLDAP など) ならば、Amazon MQ でもサポートされます。プラグインの詳細については、ActiveMQ ドキュメントの「Security」セクションを参照してください。

ユーザーに加えて、特定のグループまたはユーザーのトピックとキューへのアクセスも、LDAP サーバー経由で指定できます。これは、LDAP サーバーでトピックとキューを表すエントリを作成してから、特定の LDAP ユーザーまたはグループに許可を割り当てることで実行します。その後、LDAP サーバーから認可データを取得するようにブローカーを設定できます。

前提条件

新規または既存の Amazon MQ ブローカーに LDAP サポートを追加する前に、サービスアカウントをセットアップする必要があります。このサービスアカウントは、LDAP サーバーへの接続を開始するために必要で、この接続を行うために適切な許可を持っている必要があります。このサービスアカウントは、ブローカーの LDAP 認証をセットアップします。後続のクライアント接続は、いずれも同じ接続を介して認証されます。

サービスアカウントは、接続を開始するためのアクセス権を持つ LDAP サーバー内のアカウントです。これは標準の LDAP 要件であり、サービスアカウントの認証情報を提供する必要があるのは 1 度だけです。接続がセットアップされると、その後のすべてのクライアント接続が LDAP サーバー経由で認証されます。サービスアカウントの認証情報は暗号化された形態でセキュアに保存され、Amazon MQ 以外はアクセスできません。

ActiveMQ との統合には、LDAP サーバーに特定のディレクトリ情報ツリー (DIT) が必要です。この構造を明確に示すサンプル ldif ファイルについては、ActiveMQ ドキュメントの「Security」セクションで「Import the following LDIF file into the LDAP server」を参照してください。

LDAP の使用開始

使用を開始するには、Amazon MQ コンソールに移動し、新しい Amazon MQ の作成時、または既存のブローカーインスタンスの編集時に [LDAP authentication and authorization] (LDAP 認証と認可) を選択します。

サービスアカウントに関する以下の情報を入力します。

  • Fully qualified domain name (完全修飾ドメイン名) 認証リクエストと認可リクエストが発行される LDAP サーバーの場所です。

    注記

    入力する LDAP サーバーの完全修飾ドメイン名には、プロトコルまたはポート番号を含めないでください。Amazon MQ は、完全修飾ドメイン名の先頭にプロトコル ldaps を付加し、末尾にポート番号 636 を付加します。

    例えば、example.com という完全修飾ドメインを指定する場合、Amazon MQ は URL ldaps://example.com:636 を使用して LDAP サーバーにアクセスします。

    ブローカーホストが LDAP サーバーと正常に通信できるようにするには、完全修飾ドメイン名がパブリックに解決可能である必要があります。LDAP サーバーをプライベートかつセキュアに保つには、サーバーのインバウンドルールでインバウンドトラフィックを制限して、ブローカーの VPC 内からのトラフィックのみを許可します。

  • Service account username (サービスアカウントのユーザーネーム) LDAP サーバーへの初期バインドを実行するために使用されるユーザーの識別名です。

  • Service account password (サービスアカウントのパスワード) 初期バインドを実行するユーザーのパスワードです。

以下の画像では、これらの詳細情報を指定する場所が強調されています。

LDAP サービスアカウントの詳細情報を指定する場所。

[LDAP login configuration] (LDAP ログイン設定) セクションで、以下の必須情報を入力します。

  • User Base (ユーザーベース) ユーザーの検索先となる、ディレクトリ情報ツリー (DIT) 内のノードの識別名です。

  • User Search Matching (ユーザー検索のマッチング) userBase 内のユーザーを検索するために使用される LDAP 検索フィルターです。検索フィルターの {0} プレースホルダーにはクライアントのユーザーネームが代入されます。詳細については、認証 および 認可 を参照してください。

  • Role Base (ロールベース) ロールの検索先となる、DIT 内のノードの識別名です。ロールは、ディレクトリ内の明示的な LDAP グループエントリとして設定できます。一般的なロールエントリは、ロール名の 1 つの属性 (共通名 (CN)など)、もう一つの属性 (member など)、およびロールグループに属するユーザーの識別名またはユーザーネームを表す値で構成することができます。例えば、組織単位 group がある場合には、識別名 ou=group,dc=example,dc=com を指定できます。

  • Role Search Matching (ロール検索のマッチング) roleBase 内のロールを検索するために使用される LDAP 検索フィルターです。検索フィルターの {0} プレースホルダーには、userSearchMatching に一致するユーザーの識別名が代入されます。{1} プレースホルダーには、クライアントのユーザーネームが代入されます。例えば、ディレクトリ内のロールエントリに member という名前の属性が含まれ、そのロール内のすべてのユーザーのユーザーネームが含められている場合は、検索フィルター (member:=uid={1}) を指定できます。

以下の画像では、これらの詳細情報を指定する場所が強調されています。

LDAP ログインの詳細を指定する場所。

[Optional settings] (オプション設定) セクションでは、以下のオプション情報を指定できます。

  • User Role Name (ユーザーロール名) ユーザーのグループメンバーシップに関するユーザーのディレクトリエントリ内の LDAP 属性の名前です。場合によっては、ユーザーのディレクトリエントリ内の属性の値によって、ユーザーロールを識別できることもあります。userRoleName オプションは、この属性の名前を指定することを可能にします。例えば、以下のユーザーエントリについて考えてみましょう。

    dn: uid=jdoe,ou=user,dc=example,dc=com
objectClass: user
uid: jdoe
sn: jane
cn: Jane Doe
mail: j.doe@somecompany.com
memberOf: role1
userPassword: password

    上記の例に正しい userRoleName を提供するには、memberOf 属性を指定します。認証が成功すると、ユーザーにロール role1 が割り当てられます。

  • Role Name (ロール名) ロールエントリ内のグループ名属性で、値がそのロールの名前になってます。例えば、グループエントリの共通名には cn を指定できます。認証が成功すると、ユーザーには、メンバーになっている各ロールエントリの cn 属性の値が割り当てられます。

  • User Search Subtree (ユーザー検索サブツリー) LDAP ユーザー検索クエリの範囲を定義します。true の場合、userBase によって定義されたノード下にあるサブツリー全体を検索するように範囲が設定されます。

  • Role Search Subtree (ロール検索サブツリー) LDAP ロール検索クエリの範囲を定義します。true の場合、roleBase によって定義されたノード下にあるサブツリー全体を検索するように範囲が設定されます。

以下の画像では、これらのオプション設定を指定する場所が強調されています。

LDAP 統合の仕組み

統合は、認証の構造と認可の構造という 2 つの主要カテゴリに分けて考えることができます。

認証

認証では、クライアントの認証情報が有効である必要があります。これらの認証情報は、LDAP サーバーのユーザベース内のユーザーに対して検証されます。

ActiveMQ ブローカーに提供されるユーザーベースは、LDAP サーバーでユーザーが保存されている DIT 内のノードをポイントしている必要があります。例えば、AWS Managed Microsoft AD を使用していて、ドメインコンポーネント corp、example、および com があり、これらの中に組織単位 corp および Users がある場合は、以下をユーザーベースとして使用します。

OU=Users,OU=corp,DC=corp,DC=example,DC=com

ActiveMQ ブローカーは、ブローカーに対するクライアント接続リクエストを認証するために、DIT 内のこの場所でユーザーを検索します。

ユーザーを検索する場所

ActiveMQ ソースコードは、ユーザーの属性名を uid にハードコードするため、各ユーザーにこの属性セットがあることを確認する必要があります。簡略化のため、ユーザーの接続ユーザーネームを使用できます。詳細については、activemq ソースコードと「Configuring ID mappings in Active Directory Users and Computers for Windows Server 2016 (and subsequent) versions」を参照してください。

特定のユーザーに対して ActiveMQ コンソールアクセスを有効にするには、ユーザーが amazonmq-console-admins グループに属していることを確認してください。

認可

認可のため、ブローカーの設定に許可の検索ベースが指定されています。認可は、ブローカーの activemq.xml 設定ファイルにある cachedLdapAuthorizationMap 要素を通じて、送信先ごと (またはワイルドカード、送信先セット) に行われます。詳細については、「Cached LDAP Authorization Module」を参照してください。

注記

ブローカーの activemq.xml 設定ファイルで cachedLDAPAuthorizationMap 要素を使用できるようにするには、AWS Management Console を使用して設定を作成するときに [LDAP Authentication and Authorization (LDAP 認証と認可)] オプションを選択するか、Amazon MQ API を使用して新しい設定を作成するときに authenticationStrategy プロパティを LDAP に設定する必要があります。

cachedLDAPAuthorizationMap 要素の一部として、以下の 3 つの属性を指定する必要があります。

  • queueSearchBase

  • topicSearchBase

  • tempSearchBase

重要

ブローカーの設定ファイルに機密情報が直接配置されることを防ぐため、Amazon MQ は cachedLdapAuthorizationMap での以下の属性の使用をブロックします。

  • connectionURL

  • connectionUsername

  • connectionPassword

ブローカーの作成時、Amazon MQ は上記の属性の代わりに、AWS Management Console経由で提供される値、または API リクエストの ldapServerMetadata プロパティに指定する値を使用します。

以下は、cachedLdapAuthorizationMap の実用例です。

<authorizationPlugin>
    <map>
        <cachedLDAPAuthorizationMap
            queueSearchBase="ou=Queue,ou=Destination,ou=corp,dc=corp,dc=example,dc=com"
            topicSearchBase="ou=Topic,ou=Destination,ou=corp,dc=corp,dc=example,dc=com"
            tempSearchBase="ou=Temp,ou=Destination,ou=corp,dc=corp,dc=example,dc=com"
            refreshInterval="300000"
            legacyGroupMapping="false"
        />
    </map>
</authorizationPlugin>

これらの値は、送信先の各タイプに対する許可が指定されている、DIT 内の場所を特定します。したがって、同じ corp、example、および com ドメインコンポーネントを使用する、AWS Managed Microsoft AD での上記の例には、destination という名前の組織単位を指定して、すべての送信先タイプを含めます。その OU 内で、queues、topics、および temp の各送信先の OU を作成します。

これは、Queue タイプの送信先の認可情報を提供するキュー検索ベースの場所が、DIT 内の以下の場所になることを意味します。

OU=Queue,OU=Destination,OU=corp,DC=corp,DC=example,DC=com
キュー検索ベースの場所。

同様に、Topics および Temp 送信先の許可ルールの場所も、DIT 内の同じレベルになります。

OU=Topic,OU=Destination,OU=corp,DC=corp,DC=example,DC=com
OU=Temp,OU=Destination,OU=corp,DC=corp,DC=example,DC=com

各送信先タイプ (Queue、Topic、Temp) の OU 内には、ワイルドカードまたは特定の送信先名を指定できます。例えば、プレフィックス DEMO.EVENTS.$. で始まるすべてのキューの認可ルールを提供するには、以下の OU を作成できます。

OU=DEMO.EVENTS.$,OU=Queue,OU=Destination,OU=corp,DC=corp,DC=example,DC=com
注記

DEMO.EVENTS.$ OU は Queue OU 内にあります。

ActiveMQ でのワイルドカードの詳細については、「Wildcards」を参照してください。

DEMO.MYQUEUE などの特定のキューの認可ルールを提供するには、以下のように指定します。

OU=DEMO.MYQUEUE,OU=Queue,OU=Destination,OU=corp,DC=corp,DC=example,DC=com
特定のキューの認可ルール

セキュリティグループ

送信先またはワイルドカードを表す各 OU 内には、3 つのセキュリティグループを作成する必要があります。ActiveMQ のすべての許可と同様に、これらは読み取り/書き込み/管理者許可です。これらの許可のそれぞれがユーザーに許可する操作の詳細については、ActiveMQ ドキュメントの「Security」を参照してください。

これらのセキュリティグループには、read、write、および admin という名前を付ける必要があります。これらの各セキュリティグループ内でユーザーまたはグループを追加することができ、そうすることで、そのユーザーとグループが関連付けられたアクションを実行する許可を得ます。これらのセキュリティグループは、各ワイルドカード送信先セット、または個々の送信先に必要になります。

セキュリティグループ
注記

管理グループを作成すると、グループ名で競合が発生します。この競合は、Windows 2000 より前のレガシールールが、グループによる同一名の共有を、グループが DIT 内の別の場所にある場合でも許可しないために発生します。[Windows 2000 より前] テキストボックス内の値はセットアップに影響しませんが、グローバルに一意である必要があります。この競合を回避するには、各 admin グループに uuid サフィックスを追加できます。

これが画像です。

特定の送信先の admin セキュリティグループにユーザーを追加すると、ユーザーがそのトピックの作成および削除を実行できるようになります。ユーザーを read セキュリティグループに追加すると、送信先からの読み取りが可能になり、write グループに追加すると、送信先への書き込みが可能になります。

セキュリティグループ許可に個々のユーザーを追加することに加えて、グループ全体を追加することもできますが、ActiveMQ はグループの属性名をハードコードするため、activemq ソースコードにあるように、追加するグループにオブジェクトクラス groupOfNames があることを確実にする必要があります。

これを行うには、ユーザーの uid と同じプロセスに従ってください。「Configuring ID mappings in Active Directory Users and Computers for Windows Server 2016 (and subsequent) versions」を参照してください。