Serverに統合する手順について説明します。この章の内容は次のとおりです。Serverのセキュリティの詳細は、表16-1にリストするドキュメントを参照してください。Server上で実行されます。(LDAP)サーバーが含まれます。Serverと通信するデフォルトのJpsUserProviderを提供します。Server管理コンソール・オンライン・ヘルプの組込みLDAPサーバーの構成に関する説明を参照してください。Content本番システムのアイデンティティ・ストアを外部LDAP認証プロバイダに再度関連付ける必要があります。新規LDAP認証プロバイダを構成した後、組込みLDAPプロバイダから新規LDAPプロバイダにユーザーを移行します。(OID)など)は、デフォルトの認証プロバイダを含め、その他すべての認証プロバイダの前にリスト表示されます。Contentのインストールと構成』を参照してください。Directoryライブラリ(libOVD)機能の使用がサポートされており、この機能を使用すると、ログインやグループ・メンバーシップ情報に対してサイトで複数のプロバイダを使用できます。(OID)プロバイダをユーザーおよびロール情報のソースとして使用できる場合もあります。Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。表16-1に、ユーザー認証用に構成できるLDAPプロバイダを示します。Contentが認識する権限を持つディレクトリに動的グループ(および静的グループ)が存在する場合は、追加の構成が必要になります。Serverプロバイダと比較されたときに、別のメカニズムを使用してディレクトリ・サーバーの情報を収集します。WebCenterおよび外部LDAPサーバーの動的グループのブログを参照してください。Middlewareを構成できます。MiddlewareではSSLバージョン3に加えて、TLSバージョン1をサポートしています。この項の内容は次のとおりです。Serverのセキュリティの管理のSSLの構成に関する項を参照してください。MiddlewareでのSSLの構成に関する項を参照してください。(SSL)スタックを使用します。Serverライブラリを使用します。JDKライブラリを使用します。Serverを起動します。次のファイルを開きます。UNIXオペレーティング・システムでは、$MIDDLEWARE_HOME/user_projects/domains/domain_name/bin/setDomainEnv.shを開きます。Windowsオペレーティング・システムでは、MIDDLEWARE_HOME\user_projects\domains\domain_name\bin\setDomainEnv.batを開きます。サーバーが一方向SSL(サーバー認可のみ)に対して有効な場合は、次の行をJAVA_OPTIONSセクションに追加します。-Djavax.net.ssl.trustStore=your_truststore_location双方向SSLの場合は、キーストア情報(場所とパスワード)は不要です。Contentが別のアプリケーションを呼び出すために双方向SSLを有効化する手順は、次のとおりです。注意:サーバーとクライアントの両方が相互認証でSSL用に構成されていることが前提となります。クライアント側で、キーストアの場所を指定します。「SOAインフラストラクチャ」メニューから、「SOA管理」、「共通プロパティ」の順に選択します。ページの下部で、「詳細SOAインフラ拡張構成プロパティ」をクリックします。「KeystoreLocation」をクリックします。「値」列に、キーストアの場所を入力します。「適用」をクリックします。「戻る」をクリックします。クライアント側のDOMAIN_HOME\config\soa-infra\configuration\soa-infra-config.xmlでキーストアの場所を指定します。JDeveloperでの設計時に、composite.xmlファイル内の参照セクションをoracle.soa.two.way.ssl.enabledプロパティで更新します。Middleware管理コンソールで、「WebLogicドメイン」、「ドメイン名」の順に選択します。「ドメイン名」を右クリックし、「セキュリティ」、「資格証明」の順に選択します。「マップの作成」をクリックします。「マップ名」フィールドに名前(SOAなど)を入力し、「OK」をクリックします。「キーの作成」をクリックします。次の詳細を入力します。フィールド説明マップの選択ステップ7で作成したマップ(この例ではSOA)を選択します。名を入力します(KeystorePasswordがデフォルトです)。タイプ「パスワード」を選択します。ユーザー名ユーザー名を入力します(KeystorePasswordがデフォルトです)。パスワードキーストアに対して作成したパスワードを入力します。ServerドメインでSSLを設定する場合、キーの別名が必要です。別名の値として「mykey」を入力する必要があります。Controlコンソールでキーストアの場所を設定します。方法については、ステップ1を参照してください。Contentを起動するようにcomposite.xml構文を変更します。次の太字で示されている構文を変更します。namespace="http://xmlns.example.com/CustomApps/EchoBPELSync/BPELProcess1"location="http://hostname:port/soa-infra/services/default/EchoBPELSync/BPELProcess1.wsdl"importType="wsdl"/>httpsおよびsslportを使用するように変更します。Contentからの外部参照として呼び出す場合は、サーバーの証明書名(CN)とホスト名が完全に一致することを確認します。これにより、正しいSSLハンドシェイクが保証されます。Webサービスの名前がadfbcで、証明書のサーバー名がhostの場合は、次のコードでSSLハンドシェーク例外が発生します。importの順序を入れ替えると、SSLハンドシェイクに成功します。この問題に関連して次の制限があります。JDeveloperにありません。JDeveloperで使用されているSSLキットが異なるためです。トラスト・ストアのみコマンドラインから構成できます。他のすべての証明書引数は渡されません。WSDLファイルで、https://hostnameは前述のように証明書内の名前と一致する必要があります。ブラウザで行う場合と同じ手順は実行できません。証明書のCNのホスト名がhost.example.comの場合、ブラウザではhost、host.example.comまたはIPアドレスを使用できます。JDeveloperでは、必ず証明書内の名前と同じ名前(host.example.com)を使用する必要があります。Server間でSSL通信を構成する手順について説明します。Middleware管理者ガイド』のWeb層でのSSLの構成に関する項を参照してください。ServerのSSL通信を構成する手順は、次のとおりです。/cs>ロケーション・ディレクティブを追加します。この場合のportはターゲットの管理対象サーバーのポート番号です。Serverを起動します。Serverの証明書を構成する手順は、次のとおりです。Serverウォレットからユーザー証明書をエクスポートします。Serverトラストストアに信頼できる証明書としてインポートします。Serverトラストストアから証明書をエクスポートします。Serverウォレットに信頼できる証明書としてインポートします。Serverを再起動します。Serverを再起動します。Server管理コンソールで「フロントエンド・ホスト」および「フロントエンドHTTPSポート」フィールドを設定する必要があります。設定しないと、To-Doタスクを作成するときに例外エラーが発生します。Server管理コンソールにログインします。「環境」セクションで「サーバー」を選択します。管理対象サーバーの名前(UCM_server1など)を選択します。「プロトコル」を選択してから、「HTTP」を選択します。Contentドメインが配置されているホスト名を入力します。「フロントエンドHTTPSポート」フィールドに、SSLリスナー・ポートを入力します。「Save」をクリックします。WebCacheとの通信が必要になる場合があります。Serverトラストストアに信頼できる証明書としてインポートします)。CacheエンドポイントでのSSLの有効化に関する項を参照してください。JDeveloperで次の操作を実行します。参照セクションでWSDLファイルをフェッチするには、「ツール」、「プリファレンス」、「HTTPアナライザ」、「HTTPS設定」、「クライアントの信頼する証明書キーストア」の順でトラスト・ストア情報を設定します。SSL対応サーバーへのデプロイメント時に、コマンドラインでJSSEプロパティを使用します。非同期プロセスの呼び出しのための非同期プロセスの有効化SSL対応の管理対象サーバーにデプロイされた非同期プロセスを有効化して、別の非同期プロセスをHTTPで呼び出すには、まず次の環境を作成することを前提とします。非同期BPELプロセスAが非同期BPELプロセスBを呼び出す非同期BPELプロセスAは一方向SSL対応の管理対象サーバーにデプロイされるすべてのWSDL参照およびバインディングでプレーンHTTPを使用する実行時に、WSDLはHTTPSを介して検索され、非同期BPELプロセスBからのコールバック・メッセージが失敗します。この問題を解決するには、callbackServerURLプロパティをcomposite.xmlファイルの参照バインディング・レベルで渡す必要があります。これは、特定の参照呼出しのコールバックURLの値を示します。クライアント・コンポジットがSSL管理対象サーバーで実行されている場合、コールバックはデフォルトでSSLになります。(RIDC)および自己署名証明書を使用するには、証明書をローカルのJVM証明書ストアにインポートして証明書が信頼されるようにする必要があります。コンテンツ・サーバー・インスタンスからキーを取得します。CERTIFICATE-----行で囲まれたサーバー証明書をコピーして貼り付けます。証明書を新しいファイルに保存します。CERTIFICATE-----証明書をローカルのJVM証明書ストアにインポートします。キーストア・パスワードが必要になります。例を次に示します(パスワードはchangeitです)。Content向けの次のシングル・サインオン(SSO)ソリューションのいずれかを構成できます。Middlewareエンタープライズ・クラスのインストールに推奨するシングル・サインオン(SSO)ソリューションです。OAMは、ID管理およびセキュリティに使用するエンタープライズ・クラス製品のOracleスイートの一部です。Middlewareアプリケーション・セキュリティ・ガイド』のデプロイメントに最適なSSOソリューションの選択に関する項を参照してください。(WNA)のシングル・サインオンの構成はオプションの場合があります。WNAの詳細は、第16.3.6項を参照してください。Serverのセキュリティの管理の認証プロバイダの構成に関する項を参照してください。(/dav)は、WebDAVプロトコルごとにBasic認証によって保護されていますが、通常はフォームベースのログインが必要となるSSOによっては保護されていません。WebDAVに対してカスタムSSOソリューションを使用する場合は、カスタム・コンポーネントが必要となります。構成情報は次の項で説明します。11gの統合方法について説明します。(SS)についての構成情報が提供されます。Managementのインストールと構成に関する項で提供されている手順に従って、ソフトウェアをインストールします。(OHS)およびWebゲートを構成します。(URI)を追加します。次の例から適切なロケーション・エントリを使用します。Serverにマップします。Serverのポート番号を示します。hostnameおよびportnumberは、使用しているシステムのホスト名とポート名に置き換えます。Content機能により異なります。機能に応じて適切なロケーション・エントリを使用します。/cs、/adfAuthentication、/_ocsh、/ibr、/urmなどです。Studioの場合、転送するURIはお客様が構成します。サイトが/mysiteとしてアクセスされる場合、/mysiteのロケーション・エントリを追加する必要があります。注意:コンテンツ・サーバーのロケーション/csはカスタマイズできるため、/cs指定ではHTTPリクエストが正しいロケーションを含むことを保証できません。/csが変更されると、管理者が構成したロケーションが転送されます。ContentのURIを指定して、OAMエージェントを登録します。11gでのOAMエージェントのプロビジョニングに関する項を参照してください。Managementインストレーション・ガイド』のOAMエージェントの設定に関する項を参照してください。Content機能により異なります。Studioの場合、保護するURIはお客様が構成します。/mysiteを指定する必要があります。/oamsso/logout.htmlをAccessGateのログアウトURL設定に追加します。Management管理者ガイド』のシングル・サインオン・ログアウトURLおよびAccessGate構成パラメータの構成に関する説明を参照してください。Contentドメインを構成します。SSOソリューションのデプロイに関する項を参照してください。OAMアイデンティティ・アサータを構成します。OAMアイデンティティ・アサータの制御フラグは、REQUIREDに設定される必要があり、OAM_REMOTE_USERおよびObSSOCookieはアクティブなタイプとして選択される必要があります。11gでのSSO用IDアサーションの構成に関する項を参照してください。認証プロバイダを構成します。(OVD)のような、OAMで使用されるLDAPサーバーと一致する、ユーザー・ストア用の外部LDAPサーバーを指定するのに必要です。Contentドメインに追加される必要があります。Contentはユーザー権限をロードできません。新しい認証プロバイダがDefaultAuthenticatorプロバイダよりも前にリストされるように、認証プロバイダの順番を変更してください。DefaultAuthenticator制御フラグがSUFFICIENTに設定されていることを確認してください。詳細は、第16.3.4項を参照してください。IDアサーションのプロバイダの設定に関する項を参照してください。10gでの認証プロバイダ実装タスクの違いに関する項にある表を参照してください。(OAM)シングル・サインオン・プロバイダを構成します。Serverの構成に関する項を参照してください。11gのインストールおよび構成後、すべての構成済アプリケーションにアクセスできることと、ログインにより再度サインインすることを要求されずにすべての構成済アプリケーションにアクセスできることを確認します。可能な場合、グローバル・ログアウトをテストし、その他のすべての関連アプリケーションからログアウトしていることを確認します。11gの集中管理されたログアウトの構成に関する項を参照してください。10gの統合方法について説明します。(SS)についての構成情報が提供されます。OAMを構成する前に、ソフトウェアをインストールします。Managementインストレーション・ガイド』を参照してください。(OHS)およびWebゲートを構成します。(URI)を追加します。次の例から適切なロケーション・エントリを使用します。Serverへの受信パスをマップします。Serverのポート番号を示します。hostnameおよびportnumberは、使用しているシステムのホスト名とポート名に置き換えます。Content機能により異なります。機能に応じて適切なロケーション・エントリを使用します。/cs、/adfAuthentication、/_ocsh、/ibr、/urmなどです。Studioの場合、転送するURIはお客様が定義します。サイトが/mysiteとしてアクセスされる場合、/mysiteのロケーション・エントリを追加する必要があります。注意:コンテンツ・サーバーのロケーション/csはカスタマイズできるため、/cs指定ではHTTPリクエストが正しいロケーションを含むことを保証できません。/csが変更されると、管理者が構成したロケーションが転送されます。OAM構成ツールはコマンドライン・ユーティリティで、情報を要求する一連のスクリプトを起動し、OAMで必要なプロファイルとポリシーを設定するために使用します。Middlewareアプリケーション・セキュリティ・ガイド』のOAMCfgToolの概要に関する項を参照してください。Content機能により異なります。Studioの場合、保護するURIはお客様が構成します。/mysiteを指定する必要があります。ContentのURLが正しくリンクしていない場合、サーバー・ホストとサーバーのポート値の変更が必要な場合があります。詳細は、第16.3.5項を参照してください。OAMグローバル・ログアウトの設定を完了するには、end_urlが処理されるようWebゲートを構成します。この構成を追加しない場合、ログアウトしても、end_urlが処理されないため、終了URLへのリダイレクトが行われません。Webゲートのグローバル・ログアウトの構成に関する項を参照してください。/oamsso/logout.htmlをAccessGateのログアウトURL設定に追加します。Management管理者ガイド』のシングル・サインオン・ログアウトURLおよびAccessGate構成パラメータの構成に関する説明を参照してください。Contentバージョン11gR1をOAMバージョン10gを使用する環境にデプロイするには、ログアウト・リクエストを適切に処理するための追加の構成が必要です。Webゲートのグローバル・ログアウトの構成に関する項を参照してください。Contentドメインを構成します。10gでのSSOソリューションのデプロイに関する項を参照してください。OAMアイデンティティ・アサータを構成します。OAMアイデンティティ・アサータの制御フラグをREQUIREDに設定する必要があります。IDアサーションの構成に関する項を参照してください。認証プロバイダを構成します。(OVD)のような、OAMで使用されるLDAPサーバーと一致する、ユーザー・ストア用の外部LDAPサーバーを指定するのに必要です。Contentドメインに追加される必要があります。Contentはユーザー権限をロードできません。新しい認証プロバイダがDefaultAuthenticatorプロバイダよりも前にリストされるように、認証プロバイダの順番を変更してください。DefaultAuthenticator制御フラグがSUFFICIENTに設定されていることを確認してください。詳細は、第16.3.4項を参照してください。10gのオーセンティケータの構成に関する項を参照してください。10gでの認証プロバイダ実装タスクの違いに関する項にある表を参照してください。(OAM)シングル・サインオン・プロバイダを構成します。10gを使用したシングル・サインオンの構成に関する項を参照してください。10gのインストールおよび構成後、すべての構成済アプリケーションにアクセスできることと、ログインにより再度サインインすることを要求されずにすべての構成済アプリケーションにアクセスできることを確認します。可能な場合、グローバル・ログアウトをテストし、その他のすべての関連アプリケーションからログアウトしていることを確認します。Management管理者ガイド』を参照してください。Serverスイートの一部です。11gと組み合せたOC4Jアプリケーション・サーバーで使用できるエンタープライズ・レベルのシングル・サインオン・ソリューションです。Middlewareは、既存のOSSOソリューションを引き続きサポートします。Sign-onソリューションへのアップグレードを検討することをお薦めします。ContentとOSSOの統合に関する情報について説明します。(SS)についての構成情報が提供されます。Managementアップグレード・ガイド』も参照してください。OSSOを構成する前に、ソフトウェアがインストールされていることを確認します。リリースの一部ではありません。Serverインフラストラクチャを形成する、これらの製品の10.1.4.*バージョンをダウンロードする必要があります。Serverエンタープライズ・デプロイメント・ガイド(原本部品番号B28184-02)のJAZN-SSO/DASのインストールおよび構成に関する説明を参照してください。Networkから使用可能です。http://download.oracle.com/docs/cd/B28196_01/core.1014/b28184/toc.htmOSSOを構成します。10gを使用したシングル・サインオンの構成に関する項を参照してください。(URI)エントリをmod_wl_ohs.confファイルに追加します。次の例から適切なロケーション・エントリを使用します。Serverにマップします。Serverのポート番号を示します。hostnameおよびportnumberは、使用しているシステムのホスト名とポート名に置き換えます。Content機能により異なります。機能に応じて適切なロケーション・エントリを使用します。/cs、/adfAuthentication、/_ocsh、/ibr、/urmなどです。Studioの場合、転送するURIはお客様が構成します。サイトが/mysiteとしてアクセスされる場合、/mysiteのロケーション・エントリを追加する必要があります。注意:コンテンツ・サーバーのロケーション/csはカスタマイズできるため、/cs指定ではHTTPリクエストが正しいロケーションを含むことを保証できません。/csが変更されると、管理者が構成したロケーションが転送されます。(URI)を含めるようにmod_osso.confファイル(ORACLE_HOME/ohs/conf/)を変更します。Content機能により異なります。Studioの場合、保護するURIはお客様が構成します。/mysiteを指定する必要があります。Contentドメインを構成します。10gを使用したシングル・サインオンの構成に関する項を参照してください。ServerのOSSOアイデンティティ・アサータを追加および構成します。認証プロバイダとして、OSSOアイデンティティ・アサータ、OIDオーセンティケータ、デフォルト・オーセンティケータを推奨します。Directoryサーバー用で、本稼働レベルのシステムで使用されます。Server組込みLDAPサーバー用です。Directoryサーバーから取得できるようにします。必要な場合、リストされているように制御フラグを設定し、プロバイダの順序を変更して次の順序で表示されるようにします。Contentはユーザー権限をロードできません。新しい認証プロバイダがDefaultAuthenticatorプロバイダよりも前にリストされるように、認証プロバイダの順番を変更してください。DefaultAuthenticator制御フラグがSUFFICIENTに設定されていることを確認してください。詳細は、第16.3.4項を参照してください。認証プロバイダを構成します。(OVD)のような、OAMで使用されるLDAPサーバーと一致する、ユーザー・ストア用の外部LDAPサーバーを指定するのに必要です。Contentドメインに追加される必要があります。ContentのURLが正しくリンクしていない場合、サーバー・ホストとサーバーのポート値の変更が必要な場合があります。詳細は、第16.3.5項を参照してください。Directoryまたはその他のLDAPプロバイダなど)用にデフォルトの認証プロバイダ以外の認証プロバイダを使用するように構成されている場合、プライマリ・プロバイダはセキュリティ・レルム構成の最初の認証プロバイダである必要があります。ないと、ログイン認証が失敗します。Contentはユーザーのグループ・メンバーシップを正常にロードできず、その結果、ユーザー権限もロードできません。Server管理コンソールを使用して、構成済み認証プロバイダが呼び出される順番を変更できます。Serverのセキュリティの管理を参照してください。Directoryで定義される必要があります。Serverユーザー・ストアに定義された管理ユーザーに割り当てます。Directoryが使用されているかどうかに関わらず当てはまります。Serverが定義した管理ユーザーのロールを取得するリクエストは失敗します。Directoryライブラリ(libOVD)機能の使用がサポートされており、この機能を使用すると、ログインやグループ・メンバーシップ情報に対してサイトで複数のプロバイダを使用できます。Directoryの両方をユーザーおよびロール情報のソースとして使用できます。Controlを使用した、複数のLDAP用のサービスの構成に関する項を参照してください。Doclibサービスなど)への相対Webルートが提供されます。GET_ENVIRONMENTにより提供される値は、使用するSSO構成には適切でない場合があります。OHSサーバー・ホストおよびサーバー・ポートを使用するアプリケーション・サービスをリダイレクトする場合(OAMおよびOSSOソリューションは両方ともOHSを使用するフロント・エンド・アプリケーションが必要なため)、コンテンツ・サーバー・ホストおよびサーバー・ポートの構成値を変更する必要があります。次の2つのいずれかの方法を使用して、コンテンツ・サーバー・ホストおよびサーバー・ポート値を変更できます。Server管理コンソールを使用します。Contentシステム・プロパティ・アプリケーションを使用します。Contentドメイン・ディレクトリに移動します。ディレクトリをucm/cs/binに変更します。スタンドアロン・アプリケーションを実行します。./SystemProperties「システム・プロパティ」ウィンドウで、「インターネット」タブを選択します。HTTPサーバー・アドレスをOHS(またはロード・バランサ)サーバー・ホストおよびサーバー・ホスト値に更新します。「システム・プロパティ」ウィンドウを閉じます。Serverドメインを再起動します。Serverドメインが必要です。Serverのセキュリティの管理のMicrosoftクライアントでのシングル・サインオンの構成に関する項に記載されています。DirectoryにアクセスするようにLDAP認証プロバイダを指定する必要があります。Directory認証プロバイダを提供します。Serverのセキュリティの管理のLDAP認証プロバイダの構成に関する項を参照してください。Contentはユーザー権限をロードできません。新しい認証プロバイダがDefaultAuthenticatorプロバイダよりも前にリストされるように、認証プロバイダの順番を変更してください。DefaultAuthenticator制御フラグがSUFFICIENTに設定されていることを確認してください。詳細は、第16.3.4項を参照してください。Serverセキュリティ・レルムにネゴシエートIDアサーション・プロバイダを構成する必要があります。(SPNEGO)トークンをデコードしてKerberosトークンを取得し、このKerberosトークンを検証してWebLogicユーザーにマップします。Server管理コンソールを使用して、ドメイン構造内の適切なセキュリティ・レルムに新しいプロバイダを追加し、名前を付けて、そのタイプとしてNegotiateIdentityAsserterを選択します。Serverを再起動します。サーバーはKerberosチケットを使用できるようになり、それはブラウザから受信します。Refinery、Records)を再デプロイする必要があります。デプロイ・プランはXMLドキュメントです。Contentアプリケーションのそれぞれに対して、cs-deployment-plan.xml、ibr-deployment-plan.xml、urm-deployment-plan.xmlというプランを提供します。Toolを使用してデプロイ・プランを実装することもできます。Server管理コンソールにログインします。「ドメイン構造」ナビゲーション・ツリーで、「デプロイメント」をクリックします。Contentデプロイメントが表示されるまで「次へ」をクリックします。Records変更するデプロイメントの左のチェック・ボックスを選択します。「更新」をクリックします。デプロイ・プラン・パスの下で「パスの変更」を選択します。適切なプラン・ファイルに移動して選択します。(Records用)「このアプリケーションを次のデプロイメント・ファイルを使用して再デプロイします。」が選択されていることを確認します。「次へ」をクリックします。「終了」をクリックします。WebアプリケーションまたはWebサービスへのブラウザをポイントします。Directoryサーバーから取得したKerberos資格証明がある場合、ユーザー名またはパスワードを指定せずにWebアプリケーションまたはWebサービスにアクセスできるはずです。cs-deployment-plan.xml提供されたcs-deployment-plan.xmlファイルを使用するか、または.xmlファイルを作成してそれにcs-deployment-plan.xmlという名前を付けます。</module-override></deployment-plan>ibr-deployment-plan.xml提供されたibr-deployment-plan.xmlファイルを使用するか、または.xmlファイルを作成してそれにibr-deployment-plan.xmlという名前を付けます。</module-override></deployment-plan>urm-deployment-plan.xml提供されたurm-deployment-plan.xmlファイルを使用するか、または.xmlファイルを作成してそれにurm-deployment-plan.xmlという名前を付けます。Webサービスでは、ポリシー・セットを作成してグローバル・スコープのサブジェクト(ドメイン、サーバー、アプリケーションまたはSOAコンポジット)にアタッチする機能が提供されています。EEランタイム・アーキテクチャを定義したものです)。Webサービスにはこれらがすべて実装されています。Webサービスのためのセキュリティおよび管理者ガイドのWebサービスへのポリシーのアタッチに関する項を参照してください。WebSphereでのWebサービスの管理に関する項を参照してください。reserved.法律上の注意点ライブラリ。