IAMエンタープライズ・デプロイメントについて

3 IAMエンタープライズ・デプロイメントについて

この章では、コモディティ・ハードウェアでのOracle Identity and Access Managementデプロイメント・トポロジについて概説します。これらのトポロジは、標準的なエンタープライズ・デプロイメントについてで説明した概念の具体的な参照用実装です。

この章のトピックは、次のとおりです:

親トピック: エンタープライズ・デプロイメントの理解

プライマリおよび独自構築のエンタープライズ・デプロイメント・トポロジの理解

このガイドでは、Oracle Identity and Access Managementの2つのプライマリ参照用トポロジを中心に説明しています。各トポロジにインストールされるコンポーネントは同じです。異なる点は、1つのデプロイメントは少数の特定サーバーに集中しており、もう1つのデプロイメントは多数の小規模マシンに分散されていることです。

組織でインストールおよび構成するOracle Identity and Access Managementトポロジは、正確にはこの2つのプライマリ・トポロジと異なる可能性がありますが、このガイドでは、これらのトポロジをインストールして構成するための詳細なステップを説明します。インストールおよび構成プロセスを単純にするために、このガイドではIAMデプロイメント・ウィザードを使用します。ウィザードでトポロジのレイアウト方法を設定すると、トポロジが自動的に構成されます。

デプロイメントの作成後、このガイドでは、デプロイメントを拡張して使用を希望するIAM製品を追加する方法を説明します。このドキュメントで説明する手順は、すべてのIAM製品に該当するわけではありません。このガイドで説明するステップは、追加を希望する他のIAM製品に簡単に適用できます。

親トピック: IAMエンタープライズ・デプロイメントについて

分散ハードウェアでのOracle Identity and Access Managementのダイアグラム

この項のトポロジの例は、8ノードの分散トポロジを表しています。

このトポロジでは、ソフトウェアが8つのホスト(Web層に2つ、アプリケーション層に4つ、ディレクトリ・サービスに2つ)の間で分散されています。

このトポロジは、比較的性能が低いが作成や管理が容易な仮想マシン(VM)を使用している場合に標準的なデプロイメントです。独自の専用ホストに、Oracle Access Management、Oracle Identity Governance、ディレクトリ・サービスなどの主要コンポーネントをデプロイします。

次の図は、Oracle Identity and Access Managementトポロジを示しています。ダイアグラムではコンポーネントが完全に分離して示されます。使用するハードウェアを少なくする場合は、必要に応じてコンポーネントをまとめて配置できます。各ホストのシステム要件の詳細は、「ホスト・コンピュータのハードウェア要件」を参照してください。

図3-1 Oracle Identity and Access Managementトポロジ

「図3-1 Oracle Identity and Access Managementトポロジ」の説明

親トピック: IAMエンタープライズ・デプロイメントについて

プライマリOracle Identity and Access Managementトポロジ・ダイアグラムについて

この項では、プライマリOracle Identity and Access Managementトポロジ・ダイアグラムについて説明します。

この項には次のトピックが含まれます:

親トピック: IAMエンタープライズ・デプロイメントについて

製品の分離

IAMデプロイメントは、複数のコンポーネントから構成されています。次のコンポーネントが含まれます。

Webサーバー
WebLogicアプリケーション・サーバー
LDAP
データベース

Oracle Identity and Access Managementのコンポーネントは、IAMAccessDomainおよびIAMGovernanceDomainの2つのドメインに分割されています。製品は次のように配置されています。

IAMAccessDomainには、Oracle Access Management (OAM)が含まれます。
IAMGovernanceDomainには、Oracle Identity Governanceが含まれます。

このように分割されているのは、各コンポーネントで要求される操作要件および可用性要件が異なるためです。通常、IAMAccessDomain内のコンポーネントの可用性要件は、IAMGovernanceDomain内のコンポーネントより高くなります。これらのコンポーネントを分離することによって、可用性要件を別々に管理できます。アクセス・コンポーネントとは関係なくガバナンス・コンポーネントにパッチを適用でき、アクセス・コンポーネントに影響を与えずにガバナンス・インスタンスを停止できます。

この分離は、多くの場合Web層およびアプリケーション層のコンポーネントとは別の時点にリリースされるディレクトリ層にも拡張できます。ディレクトリの分離によって、ドメインの分割と同様の利点(独立したアップグレードやパッチ適用など)を得られます。

この分離による更なる利点は、トポロジをモジュラ形式で構築できることです。ディレクトリから開始してアクセス・コンポーネントに拡張し、後でガバナンス・コンポーネントに拡張すると、これらを接続しないかぎり、デプロイされているソフトウェア、または既存のコンポーネントの構成に影響を与えません。

親トピック: プライマリOracle Identity and Access Managementトポロジ・ダイアグラムについて

ディレクトリ層の理解

ディレクトリ層は、LDAP対応ディレクトリがインストールされている2つ以上の物理ホスト・コンピュータで構成されています。通常、これはOracle Unified Directory (OUD)です。

多くの場合、ディレクトリ層はデータ層に結合されています。

このリリースのエンタープライズ・デプロイメント・ガイドでは、3つの異なるLDAPディレクトリをサポートしています。このディレクトリを初めて作成するか、または組織内の既存のディレクトリを使用できます。Oracle Unified Directory (OUD)ディレクトリがサポートされます。

選択するディレクトリは組織によって異なります。

親トピック: プライマリOracle Identity and Access Managementトポロジ・ダイアグラムについて

Oracle Unified Directory保証レプリケーションの理解

Oracle Unified Directoryサーバー・インスタンスは、本来、レプリケーションを使用して、埋込みデータベースの同期状態を保持します。デフォルトでは、レプリケーションは、操作結果がアプリケーションに戻った後に更新をレプリカにレプリケーションするゆるやかな一貫性モデルを使用します。したがってこのモデルでは、データをレプリカに書き込んでから、書込みの少し後に古い情報を別のレプリカから読み取ってしまう可能性があります。レプリケーション・プロセスが高速で1ミリ秒の桁で達成できるように、Oracle Unified Directoryレプリケーションで多くの作業が行われました。

レプリカ内のデータの一貫性を保証するように開発された保証レプリケーション・モデルを使用するようにOracle Unified Directoryを構成できます。保証レプリケーションの安全読取りモードを使用すると、アプリケーションは、レプリケーション・プロセスが書込み操作の結果を返す前に完了することを保証します。

保証レプリケーションを使用すると、書込み操作の応答時間に悪影響があります。これは、保証レプリケーションではリモート・レプリカとの通信の後に操作結果を返す必要があるためです。遅延時間は、使用するネットワークおよびOracle Unified Directoryをホストしているサーバーの容量によって異なります。保証レプリケーションを使用しても、読取り操作への影響はほとんどありません。

ディレクトリへの大量の書込みを定期的に実行することが予想される場合、ロード・バランサを構成して、アクティブ/パッシブ・モードでOracle Unified Directoryインスタンスにリクエストを分散することを検討してください。こうすることによって、レプリカから古いデータ読み取る機会がなくなりますが、使用しているOracle Unified Directoryホストがすべてのリクエストを処理する能力がない場合、全体のパフォーマンスが低下する可能性があります。

このガイドの目的のために、複数のサーバーにリクエストを処理させる機能の方が保証モードでのリクエストの書込みによって生じる追加のオーバーヘッドより重要であると想定されます。この目的のために、このガイドでは、保証レプリケーションを使用したOracle Unified Directoryの構成を示します。ただし、次のOracle Unified Directoryの構成は両方ともサポートされます。

保証構成のアクティブ/アクティブ
非保証構成のアクティブ/パッシブ

詳細は、Oracle Fusion Middleware Oracle Unified Directory管理者ガイドの保証レプリケーションに関する項を参照してください。

親トピック: プライマリOracle Identity and Access Managementトポロジ・ダイアグラムについて

Oracle Identity and Access Managementのロード・バランサ仮想サーバー名のサマリー

サーバー上のロードをバランシングして高可用性を実現するには、ハードウェア・ロード・バランサが必要です。可用性を最大化するために、このハードウェア・ロード・バランサは冗長ハードウェアに存在する必要があります。ハードウェア・ロード・バランサは、一連の仮想サーバー名を認識するように構成する必要があります。

Oracle Identity and Access Managementデプロイメントのハードウェア・ロード・バランサは、次の仮想サーバー名を認識する必要があります。

login.example.com - この仮想サーバー名はすべての受信アクセス・トラフィックに使用されます。これは、ランタイムAccess ManagementコンポーネントへのすべてのHTTPトラフィックのアクセス・ポイントとして機能します。ロード・バランサは、この仮想サーバー名へのすべてのリクエストをSSLを介してルーティングします。その結果、クライアントは、次のセキュア・アドレスを使用してこのサービスにアクセスします。

login.example.com:443
prov.example.com - この仮想サーバー名はすべての受信ガバナンス・トラフィックに使用されます。これは、ランタイム・ガバナンス・コンポーネントへのすべてのHTTPトラフィックのアクセス・ポイントとして機能します。ロード・バランサは、この仮想サーバー名へのすべてのリクエストをSSLを介してルーティングします。その結果、クライアントは、次のセキュア・アドレスを使用してこのサービスにアクセスします。

prov.example.com:443

以前のリリースのエンタープライズ・デプロイメント・ガイドでは、login.example.comおよびprov.example.comは同じエントリ・ポイントであったことに注意してください。このリリースではこれらを分離できます。これによって、ロード・バランサからのルーティング機能が向上し、モジュラ・デプロイメントが実現して、将来のマルチ・データ・センター・デプロイメントが容易になります。必要な場合は、これら2つのエントリ・ポイントを結合して、IAMデプロイメントへの単一エントリ・ポイントにすることも可能です。
iadadmin.example.com - この仮想サーバー名は、ロード・バランサ上で有効です。これは、IAMAccessDomain内の管理サービスに送信されるすべての内部HTTPトラフィック用のアクセス・ポイントとして機能します。クライアントからの受信トラフィックはすべて非SSLに対応しています。したがって、クライアントは、次のアドレスを使用してこのサービスにアクセスします。

iadadmin.example.com:80

これは、WEBHOST1およびWEBHOST2のポート7777に転送されます。

この仮想ホスト上でアクセスされるサービスには、WebLogic管理サーバー・コンソール、Oracle Enterprise Manager Fusion Middleware Controlなどがあります。

ファイアウォールでルールを作成し、この仮想ホストを使用して外部トラフィックが/console URLおよび/em URLにアクセスすることを防止します。DMZ内部のトラフィックのみがiadadmin.example.com仮想ホスト上のこれらのURLにアクセスできる必要があります。
igdadmin.example.com - この仮想サーバー名は、ロード・バランサ上で有効です。これは、IAMGovernanceDomain内の管理サービスに送信されるすべての内部HTTPトラフィック用のアクセス・ポイントとして機能します。クライアントからの受信トラフィックはすべて非SSLに対応しています。したがって、クライアントは、次のアドレスを使用してこのサービスにアクセスします。

igdadmin.example.com:80

これは、WEBHOST1およびWEBHOST2のポート7777に転送されます。

この仮想ホスト上でアクセスされるサービスには、WebLogic管理サーバー・コンソール、Oracle Enterprise Manager Fusion Middleware Controlなどがあります。

ファイアウォールでルールを作成し、この仮想ホストを使用して外部トラフィックが/console URLおよび/em URLにアクセスすることを防止します。DMZ内部のトラフィックのみがigdadmin.example.com仮想ホスト上のこれらのURLにアクセスできる必要があります。
igdinternal.example.com - この仮想サーバー名は、カバナンス・ドメイン内のアプリケーション層のコンポーネント間の内部通信専用であり、インターネットには公開されません。この仮想サーバーは、Oracle OIM SuiteおよびOracle SOA Suiteの両方の内部通信で使用されます。

クライアントからこの仮想サーバーへのトラフィックは、SSL対応ではありません。クライアントは次のアドレスを使用してこのサービスにアクセスします。そして、リクエストは、WEBHOST1とWEBHOST2のポート7777に転送されます。

igdinternal.example.com:7777
idstore.example.com - この仮想サーバー名はすべての受信アイデンティティ・ストア・トラフィックに使用されます。これは、LDAPディレクトリ・インスタンスへのアクセス・ポイントとして機能します。この仮想サーバーは、インターネットには公開されません。

クライアントからこの仮想サーバーへのトラフィックは、使用するLDAPディレクトリのタイプに応じて、SSL対応の場合とそうでない場合があります。通常、これはOracle Unified Directoryに対してはSSL非対応になります。クライアントはこの仮想サーバー名を使用してこのサービスにアクセスし、リクエストがLDAPインスタンスに転送されます。
oam.example.com:5575 - これはマルチ・データセンター・デプロイメントでのみ使用される追加のロード・バランサ仮想ホストです。この仮想ホストはリクエストをOAM管理対象サーバー上のOracle Access Management (OAM)プロキシ・ポートにルーティングします。たとえば、5575です。

親トピック: プライマリOracle Identity and Access Managementトポロジ・ダイアグラムについて

アプリケーション層ホストの管理対象サーバーとクラスタのサマリー

アプリケーション層は、Oracle WebLogic Serverドメイン内の管理サーバーおよび管理対象サーバーをホストします。

選択したコンポーネントに応じて、Oracle Identity and Access Management用のOracle WebLogic Serverドメインは、表3-1に示すクラスタで構成されています。これらのクラスタは、アクティブ/アクティブ高可用性構成として機能します。

表3-1 ドメインのクラスタおよび管理対象サーバー

ドメイン	クラスタ	管理対象サーバー
IAMAccessDomain	Oracle Access Manager	WLS_OAM1、WLS_OAM2
該当なし	Oracle Policy Manager	WLS_AMA1、WLS_AMA2
IAMGovernanceDomain	Oracle Identity Governance	WLS_OIM1、WLS_OIM2
該当なし	Oracle SOA Suite	WLS_SOA1、WLS_SOA2
該当なし	Oracle Web Services Manager。	WLS_WSM1、WLS_WSM2

親トピック: プライマリOracle Identity and Access Managementトポロジ・ダイアグラムについて

パスワードを忘れた場合の機能について

ユーザーがシステムで作成されるとき、そのパスワードをリセットできるメカニズムが存在する必要があります。Oracle 11gでは、これはOracle Identity Governanceから提供されました。Oracle 12cでは、2つの方法があります。

Oracle Access Management (OAM)とOracle Identity Governance (OIG)の統合:

このシナリオでは、ユーザーは初めてログオンするときに、OIGに格納される複数のチャレンジ質問を設定できます。ユーザーが自分のパスワードを忘れても、チャレンジ質問に正しく解答できれば、OIG経由でパスワードをリセットできるようになります。
Oracle Access Management:

このシナリオでは、OAMはOracle User Messaging Serviceに接続します。各ユーザーは自分に電話番号または電子メール・アドレスのいずれかを関連付けます。ユーザーがパスワードを忘れた場合のリンクをリクエストすると、ワン・タイムPINが送信され、これをアプリケーションに入力してパスワードをリセットできます。

このガイドでは、両方のシナリオを設定する方法について説明します。

親トピック: IAMエンタープライズ・デプロイメントについて

OIG、OAMおよびLDAPの統合

以前のOracle Identity Managerリリースでは、LDAPディレクトリとの統合はLDAPSyncというプロセスを使用して行われ、これはOracle Identity Managerの構成中に有効化されました。Oracle Identity Manager 12c以降では、LDAP syncは非推奨になり、LDAPコネクタが優先されます。

LDAPディレクトリおよびOracle Access Managerとの統合を提供するために、LDAPコネクタはOracle 12cで拡張されました。以前はOAM/OIM統合の一環として有効化された機能は、LDAPコネクタに組み込まれました。

ユーザーの無効化または強制終了時にユーザー・セッションを強制終了する機能。

この機能を取得するために、次のバージョンのLDAPコネクタ(12.2.1.3)をダウンロードします。

この項では、LDAP用のOracleコネクタを取得、インストールおよび構成する方法について説明します。

Oracleコネクタについて

LDAPコネクタは、Identity Connector Framework (ICF)を使用して実装されます。ICFは、すべてのOracle Identity Managerコネクタに共通の基本的なリコンシリエーションおよびプロビジョニング操作を提供するコンポーネントです。ICFは、Oracle Identity Managerに付属しています。したがって、ICFを構成したり変更する必要はありません。

LDAPコネクタはJNDIを使用してターゲット・システムにアクセスします。このコネクタは、次のモードのいずれかで実行されるように構成できます。

アイデンティティ・リコンシリエーション: アイデンティティ・リコンシリエーションは、認可ソースまたは信頼できるソースのリコンシリエーションとも呼ばれます。この形式のリコンシリエーションでは、ターゲット・システムでのユーザーの作成または更新に対応してOIMユーザーが作成または更新されます。アイデンティティ・リコンシリエーション・モードでは、ユーザー・オブジェクトのリコンシリエーションのみがサポートされることに注意してください。
アカウント管理: アカウント管理は、ターゲット・リソース管理とも呼ばれます。このモードのコネクタでは、プロビジョニングとターゲット・リソースのリコンシリエーションが有効化されます。

プロビジョニング

プロビジョニングでは、Oracle Identity Managerを使用して、ターゲット・システムでユーザー、グループ、ロールおよび組織単位(OU)を作成、更新または削除します。

ターゲット・システム・リソースをOIMユーザーに割り当てる(プロビジョニングする)と、この操作によって、ターゲット・システムにそのユーザーのアカウントが作成されます。Oracle Identity Manager関連では、プロビジョニングという用語は、Oracle Identity Managerを使用したターゲット・システム・アカウントに対する更新(有効化または無効化など)を意味する場合にも使用されます。

ユーザーおよび組織は、ターゲット・システムで階層形式に編成されます。ターゲット・システムで必要な組織単位(OU)にユーザーをプロビジョニングする(ユーザーを作成する)には、ターゲット・システムで使用されるOUのリストをOracle Identity Managerにフェッチする必要があります。これは、参照同期のためのLDAP Connector OU Lookup Reconciliationスケジュール済ジョブを使用して行います。

同様に、ターゲット・グループの必須グループまたはロールにユーザーをプロビジョニングするには、事前にターゲット・システムで使用されるすべてのグループとロールのリストをOracle Identity Managerにフェッチする必要があります。これは、参照同期のためのLDAP Connector Group Lookup ReconciliationおよびLDAP Connector Role Lookup Reconスケジュール済ジョブを使用して行います。

ターゲット・リソースのリコンシリエーション

ターゲット・リソースのリコンシリエーションを実行するには、LDAP Connector User Search ReconciliationまたはLDAP Connector User Sync Reconciliationスケジュール済ジョブが使用されます。コネクタは、フィルタを適用してターゲット・システムからリコンサイルされるユーザーを検索し、それらのユーザーの属性値をフェッチします。

リコンサイルしようとするデータに応じて様々なスケジュール済ジョブを使用します。たとえば、LDAP Connector User Search Reconciliationスケジュール済ジョブを使用して、ターゲット・リソース・モードでユーザー・データをリコンサイルします。

Oracle LDAPコネクタは、Oracle Identity Managerにローカルにデプロイすることも、コネクタ・サーバーにリモートにデプロイすることもできます。コネクタ・サーバーを使用すると、アイデンティティ・コネクタをリモートで実行することができます。エンタープライズ・デプロイメント・ガイドでは、コネクタをOracle Identity Managerにローカルにインストールおよび構成するステップを示します。

親トピック: IAMエンタープライズ・デプロイメントについて

プライマリIAM Suiteトポロジの実装のロードマップ

表3-2に、コモディティ・ハードウェアでのプライマリIAM Suiteトポロジの実装のロードマップを示します。

表3-2 コモディティ・ハードウェアでのプライマリIAM Suiteトポロジの実装のロードマップ

シナリオ	タスク	詳細の参照先
コモディティ・ハードウェアでのIAMエンタープライズ・デプロイメントの手動作成	標準的なエンタープライズ・デプロイメントの理解、およびプライマリ・デプロイメント・トポロジの確認。	エンタープライズ・デプロイメントの概要標準的なエンタープライズ・デプロイメントについて IAMエンタープライズ・デプロイメントについて IAM Exalogicエンタープライズ・デプロイメントについてマルチデータ・センター・デプロイメントについて
	ハードウェアおよびソフトウェアの要件の確認、およびエンタープライズ・デプロイメント用のリソースの取得。	エンタープライズ・デプロイメント用のリソースの取得
	ロード・バランサとファイアウォールの準備。	エンタープライズ・デプロイメントのロード・バランサとファイアウォールの準備
	記憶域の準備、およびディレクトリ構造の理解。	エンタープライズ・デプロイメント用のファイル・システムの準備
	ホスト・コンピュータの構成。	エンタープライズ・デプロイメント用のホスト・コンピュータの準備
	データベースを準備します。	エンタープライズ・デプロイメント用のデータベースの準備
	Oracle LDAPを構成します。	エンタープライズ・デプロイメント用のOracle LDAPの構成
	Oracle Access Management用のOracle Fusion Middleware Infrastructureの作成。	Oracle Access Managementのインフラストラクチャの作成
	Oracle Identity Governance用のOracle Fusion Middleware Infrastructureの作成。	Oracle Identity Governanceのインフラストラクチャの作成
	Oracle HTTP Serverの構成または Oracle Traffic Directorの構成	エンタープライズ・デプロイメント用のOracle HTTP Serverの構成エンタープライズ・デプロイメント用のOracle Traffic Directorの構成
	Oracle Access Management (OAM)の構成。	Oracle Access Managementの構成
	Oracle Identity Governance (OIG)または(OIM)の構成。	Oracle Identity Governanceの構成
	サーバー移行設定の構成。	エンタープライズ・デプロイメントでのサーバー全体の移行とサービスの移行の使用
	シングル・サインオン(SSO)の構成。	エンタープライズ・デプロイメント用のシングル・サインオンの構成

親トピック: IAMエンタープライズ・デプロイメントについて

独自のOracle Identity and Access Managementトポロジの構築

このドキュメントの「プライマリOracle Identity and Access Management Exalogicエンタープライズ・トポロジのダイアグラム」では、Oracle Identity and Access Managementの2つのプライマリ・エンタープライズ・トポロジを構成するステップを説明しています。

ただし、お客様が購入するOracle Fusion Middleware製品セットやデプロイするアプリケーションのタイプによって、組織の要件が異なる場合があります。

多くの場合、代替トポロジ(追加コンポーネントを含むトポロジ、またはプライマリ・トポロジ・ダイアグラムに示したOracle Identity and Access Management製品の一部を含まないトポロジ)のインストールおよび構成が可能です。

次の項では、実装可能ないくつかの代替Oracle Identity and Access Managementトポロジについて、このガイドに示した手順に多少の変更を加えて説明します。

既存のディレクトリのみを含むOAM
既存のディレクトリのみを含むOIM
モジュラ・デプロイメントに統合されたOAM/OIM
既存のディレクトリと統合されたOAM/OIM

ノート:

デプロイメントは、Oracle Adaptive Access ManagerまたはOracle Privileged Account Managerを含むように拡張できます。詳細は、MAAのWebサイトを参照してください。

ノート:

このガイドで説明している環境とは異なるカスタム環境をデプロイする場合、通常はOracle Identity and Access Managementを手動でデプロイします。インストールおよびデプロイメントを自動化するために用意されているライフ・サイクル管理(LCM)ツールは、すべての代替トポロジをサポートしているわけではありません。

親トピック: IAMエンタープライズ・デプロイメントについて

サービスまたはサーバー移行によるエンタープライズ・トポロジの高可用性化について

Oracle Identity Governance製品およびコンポーネントの高可用性を実現するために、このガイドでは、参照用トポロジの一部として作成するOracle Identity ManagerおよびOracle SOA Suiteのクラスタに対してOracle WebLogic Serverのサーバー全体の移行を有効にすることをお薦めします。

静的クラスタの場合、構成ウィザードの「高可用性のオプション」画面を使用して自動サービス移行を構成できます。「自動サービス移行の有効化」オプションを選択すると、自動サービス移行に必要な移行可能ターゲットの定義が構成されます。同じ画面で「JTAトランザクション・ログ永続性」オプションと「JMSサーバー永続性」オプションを使用すると、自動的にJDBCストアとして構成することができます。OIMエンタープライズ・デプロイメントで静的クラスタを構成するときには、これらのオプションを有効にすることをお薦めします。

動的クラスタの場合、移行可能ターゲットは必要ありません。自動サービス移行の一部の機能は、動的クラスタに当初から用意されているからです。構成ウィザードの「高可用性のオプション」画面は、動的クラスタでは使用しませんが、リースと永続ストアの移行ポリシーを構成するには、追加のステップが必要です。OIMエンタープライズ・デプロイメントで動的クラスタを構成するときには、これらの事後のステップを実行することをお薦めします。

詳細は、「エンタープライズ・デプロイメントでのサーバー全体の移行とサービスの移行の使用」を参照してください。

親トピック: IAMエンタープライズ・デプロイメントについて