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

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

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

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

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

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 認証と認可] を選択します。

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

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

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

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

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

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

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 グループに属していることを確認してください。

Authorization

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

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

以下は、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 内の場所を特定します。したがって、上記の例では AWS Managed Microsoft AD、、corp、exampleおよび の同じドメインコンポーネントを使用してcom、すべての送信先タイプを含む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

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

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

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

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