翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # ActiveMQ ブローカーの LDAP との統合 **重要** Amazon MQ では、プライベート CA によって発行されたサーバー証明書はサポートされません。 ActiveMQ ブローカーには、TLS が有効化されている以下のプロトコルを使用してアクセスできます。 + [AMQP](http://activemq.apache.org/amqp.html) + [MQTT](http://activemq.apache.org/mqtt.html) + MQTT over [WebSocket](http://activemq.apache.org/websockets.html) + [OpenWire](http://activemq.apache.org/openwire.html) + [STOMP](http://activemq.apache.org/stomp.html) + STOMP over WebSocket Amazon MQ では、ユーザー許可の管理に、ネイティブ ActiveMQ 認証か LDAP 認証と認可のどちらかを選択できます。ActiveMQ のユーザー名とパスワードに関する制限の詳細については、「[[ユーザー]](amazon-mq-limits.md#activemq-user-limits)」を参照してください。 ActiveMQ のユーザーおよびグループによるキューとトピックの使用を認可するには、[ブローカーの設定を編集](amazon-mq-creating-applying-configurations.md)する必要があります。Amazon MQ は、ActiveMQ の [Simple Authentication Plugin](http://activemq.apache.org/security.html#Security-SimpleAuthenticationPlugin) を使用して、送信先に対する読み込みと書き込みを制限します。詳細情報と例については、「[認可マップを常に設定する](using-amazon-mq-securely.md#always-configure-authorization-map)」および「`authorizationEntry`」を参照してください。 **注記** 現在、Amazon MQ はクライアント証明書認証をサポートしていません。 **Topics** + [LDAP を ActiveMQ に統合する](#integrate-ldap) + [前提条件](#ldap-prerequisites) + [LDAP の使用開始](#ldap-get-started) + [LDAP 統合の仕組み](#ldap-support-details) ## 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](https://activemq.apache.org/security)」セクションを参照してください。 ユーザーに加えて、特定のグループまたはユーザーのトピックとキューへのアクセスも、LDAP サーバー経由で指定できます。これは、LDAP サーバーでトピックとキューを表すエントリを作成してから、特定の LDAP ユーザーまたはグループに許可を割り当てることで実行します。その後、LDAP サーバーから認可データを取得するようにブローカーを設定できます。 **重要** LDAP を使用する場合、認証では大文字と小文字は区別されませんが、認可ではユーザー名の大文字と小文字が区別されます。 ## 前提条件 新規または既存の Amazon MQ ブローカーに LDAP サポートを追加する前に、サービスアカウントをセットアップする必要があります。このサービスアカウントは、LDAP サーバーへの接続を開始するために必要で、この接続を行うために適切な許可を持っている必要があります。このサービスアカウントは、ブローカーの LDAP 認証をセットアップします。後続のクライアント接続は、いずれも同じ接続を介して認証されます。 サービスアカウントは、接続を開始するためのアクセス権を持つ LDAP サーバー内のアカウントです。これは標準の LDAP 要件であり、サービスアカウントの認証情報を提供する必要があるのは 1 度だけです。接続がセットアップされると、その後のすべてのクライアント接続が LDAP サーバー経由で認証されます。サービスアカウントの認証情報は暗号化された形態でセキュアに保存され、Amazon MQ 以外はアクセスできません。 ActiveMQ との統合には、LDAP サーバーに特定のディレクトリ情報ツリー (DIT) が必要です。この構造を明確に示すサンプル `ldif` ファイルについては、ActiveMQ ドキュメントの「[Security](https://activemq.apache.org/security)」セクションで「*Import the following LDIF file into the LDAP server*」を参照してください。 ## LDAP の使用開始 使用を開始するには、Amazon MQ コンソールに移動し、新しい Amazon MQ ブローカーインスタンスの作成時または既存のブローカーインスタンスの編集時に **[LDAP 認証と認可]** を選択します。 サービスアカウントに関する以下の情報を入力します。 + **[完全修飾ドメイン名]** 認証リクエストと認可リクエストを発行する先の 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 サービスアカウントの詳細情報を指定する場所。\]](http://docs.aws.amazon.com/ja_jp/amazon-mq/latest/developer-guide/images/active-mq-ldap-service-account.png) [**LDAP login configuration**] (LDAP ログイン設定) セクションで、以下の必須情報を入力します。 + **User Base (ユーザーベース)** ユーザーの検索先となる、ディレクトリ情報ツリー (DIT) 内のノードの識別名です。 + **User Search Matching (ユーザー検索のマッチング)** `userBase` 内のユーザーを検索するために使用される LDAP 検索フィルターです。検索フィルターの `{0}` プレースホルダーにはクライアントのユーザーネームが代入されます。詳細については、「[認証](#ldap-authentication)」および「[Authorization](#ldap-authorization)」を参照してください。 + **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 ログインの詳細を指定する場所。\]](http://docs.aws.amazon.com/ja_jp/amazon-mq/latest/developer-guide/images/active-mq-ldap-login-configuration.png) [**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` によって定義されたノード下にあるサブツリー全体を検索するように範囲が設定されます。 以下の画像では、これらのオプション設定を指定する場所が強調されています。 ![\[Optional settings for LDAP attributes and search scope in role search matching.\]](http://docs.aws.amazon.com/ja_jp/amazon-mq/latest/developer-guide/images/amazon-mq-active-ldap-optional-settings.png) ## 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 内のこの場所でユーザーを検索します。 ![\[ユーザーを検索する場所\]](http://docs.aws.amazon.com/ja_jp/amazon-mq/latest/developer-guide/images/active-mq-ldap-structure.png) ActiveMQ ソースコードは、ユーザーの属性名を `uid` にハードコードするため、各ユーザーにこの属性セットがあることを確認する必要があります。簡略化のため、ユーザーの接続ユーザーネームを使用できます。詳細については、[activemq](https://github.com/apache/activemq/blob/c3d9b388e4f1fe73e348bf466122fe6862e064a0/activemq-broker/src/main/java/org/apache/activemq/security/SimpleCachedLDAPAuthorizationMap.java#L89) ソースコードと「[Configuring ID mappings in Active Directory Users and Computers for Windows Server 2016 (and subsequent) versions](https://www.ibm.com/support/knowledgecenter/en/STXKQY_5.0.3/com.ibm.spectrum.scale.v5r03.doc/bl1adm_confidmapaduc.htm)」を参照してください。 特定のユーザーに対して ActiveMQ コンソールアクセスを有効にするには、ユーザーが `amazonmq-console-admins` グループに属していることを確認してください。 ### Authorization 認可のため、ブローカーの設定に許可の検索ベースが指定されています。認可は、ブローカーの `activemq.xml` 設定ファイルにある `cachedLdapAuthorizationMap` 要素を通じて、送信先ごと (またはワイルドカード、送信先セット) に行われます。詳細については、「[Cached LDAP Authorization Module](https://activemq.apache.org/cached-ldap-authorization-module)」を参照してください。 **注記** ブローカー`activemq.xml`の設定ファイルで `cachedLDAPAuthorizationMap`要素を使用するには、 [を使用して設定を作成する AWS マネジメントコンソール](amazon-mq-creating-applying-configurations.md)ときに **LDAP 認証および認可**オプションを選択するか、 [を使用して設定を作成する AWS マネジメントコンソール](amazon-mq-creating-applying-configurations.md)ときに を設定するか、Amazon MQ API を使用して新しい設定を作成する`LDAP`ときに [https://docs.aws.amazon.com//amazon-mq/latest/api-reference/configurations.html#configurations-model-authenticationstrategy](https://docs.aws.amazon.com//amazon-mq/latest/api-reference/configurations.html#configurations-model-authenticationstrategy)プロパティを に設定する必要があります。 `cachedLDAPAuthorizationMap` 要素の一部として、以下の 3 つの属性を指定する必要があります。 + `queueSearchBase` + `topicSearchBase` + `tempSearchBase` **重要** ブローカーの設定ファイルに機密情報が直接配置されることを防ぐため、Amazon MQ は `cachedLdapAuthorizationMap` での以下の属性の使用をブロックします。 `connectionURL` `connectionUsername` `connectionPassword` ブローカーを作成すると、Amazon MQ は、 を介して AWS マネジメントコンソール、または API リクエストの [https://docs.aws.amazon.com//amazon-mq/latest/api-reference/brokers.html#brokers-prop-createbrokerinput-ldapservermetadata](https://docs.aws.amazon.com//amazon-mq/latest/api-reference/brokers.html#brokers-prop-createbrokerinput-ldapservermetadata)プロパティで指定した値を上記の属性に置き換えます。 以下は、`cachedLdapAuthorizationMap` の実用例です。 ``` ``` これらの値は、送信先の各タイプに対する許可が指定されている、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 ``` ![\[キュー検索ベースの場所。\]](http://docs.aws.amazon.com/ja_jp/amazon-mq/latest/developer-guide/images/active-mq-ldap-queue-structure.png) 同様に、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.\$1. で始まるすべてのキューの認可ルールを提供するには、以下の OU を作成できます。 ``` OU=DEMO.EVENTS.$,OU=Queue,OU=Destination,OU=corp,DC=corp,DC=example,DC=com ``` **注記** `DEMO.EVENTS.$` OU は `Queue` OU 内にあります。 ActiveMQ でのワイルドカードの詳細については、「[Wildcards](https://activemq.apache.org/wildcards)」を参照してください。 DEMO.MYQUEUE などの特定のキューの認可ルールを提供するには、以下のように指定します。 ``` OU=DEMO.MYQUEUE,OU=Queue,OU=Destination,OU=corp,DC=corp,DC=example,DC=com ``` ![\[特定のキューの認可ルール\]](http://docs.aws.amazon.com/ja_jp/amazon-mq/latest/developer-guide/images/active-mq-ldap-authorization-rules.png) ### セキュリティグループ 送信先またはワイルドカードを表す各 OU 内には、3 つのセキュリティグループを作成する必要があります。ActiveMQ のすべての許可と同様に、これらは読み取り/書き込み/管理者許可です。これらの許可のそれぞれがユーザーに許可する操作の詳細については、ActiveMQ ドキュメントの「[Security](https://activemq.apache.org/security)」を参照してください。 これらのセキュリティグループには、`read`、`write`、および `admin` という名前を付ける必要があります。これらの各セキュリティグループ内でユーザーまたはグループを追加することができ、そうすることで、そのユーザーとグループが関連付けられたアクションを実行する許可を得ます。これらのセキュリティグループは、各ワイルドカード送信先セット、または個々の送信先に必要になります。 ![\[セキュリティグループ\]](http://docs.aws.amazon.com/ja_jp/amazon-mq/latest/developer-guide/images/active-mq-ldap-security-groups.png) **注記** 管理グループを作成すると、グループ名で競合が発生します。この競合は、Windows 2000 より前のレガシールールが、グループによる同一名の共有を、グループが DIT 内の別の場所にある場合でも許可しないために発生します。[**Windows 2000 より前**] テキストボックス内の値はセットアップに影響しませんが、グローバルに一意である必要があります。この競合を回避するには、各 `admin` グループに `uuid` サフィックスを追加できます。 ![\[これが画像です。\]](http://docs.aws.amazon.com/ja_jp/amazon-mq/latest/developer-guide/images/active-mq-ldap-admin-qualifier.png) 特定の送信先の `admin` セキュリティグループにユーザーを追加すると、ユーザーがそのトピックの作成および削除を実行できるようになります。ユーザーを `read` セキュリティグループに追加すると、送信先からの読み取りが可能になり、`write` グループに追加すると、送信先への書き込みが可能になります。 セキュリティグループ許可に個々のユーザーを追加することに加えて、グループ全体を追加することもできますが、ActiveMQ はグループの属性名をハードコードするため、[activemq](https://github.com/apache/activemq/blob/c3d9b388e4f1fe73e348bf466122fe6862e064a0/activemq-broker/src/main/java/org/apache/activemq/security/SimpleCachedLDAPAuthorizationMap.java#L86) ソースコードにあるように、追加するグループにオブジェクトクラス `groupOfNames` があることを確実にする必要があります。 これを行うには、ユーザーの `uid` と同じプロセスに従ってください。「[Configuring ID mappings in Active Directory Users and Computers for Windows Server 2016 (and subsequent) versions](https://www.ibm.com/support/knowledgecenter/en/STXKQY_5.0.3/com.ibm.spectrum.scale.v5r03.doc/bl1adm_confidmapaduc.htm)」を参照してください。