| Oracle® Enterprise Manager Cloud Controlセキュリティ・ガイド 12c リリース5 (12.1.0.5) E49736-06 |
|
 前 |
 次 |
この章の内容は、次のとおりです。
Enterprise Managerの認証は、Enterprise Managerにアクセスするユーザーの妥当性を確認するプロセスです。認証機能は、Enterprise ManagerコンソールやEnterprise Managerコマンドライン・インタフェース(EM CLI)などの様々なインタフェースで使用可能です。
Enterprise Managerの認証フレームワークは、環境に最も適した認証プロトコルを使用可能にするプラガブルな認証スキームで構成されています。
|
注意: Oracle Enterprise Manager 12cは、外部認証方法について、OMSスタックの一部である基礎となるWebLogic Serverに依存しています。そのため、Enterprise Manager 12cは、Oracle WebLogic Serverでサポートされる認証方法を使用して認証できます。 |
Enterprise Managerは、次の認証スキームをサポートしています。
このスキームでは、ユーザーがEnterprise Managerコンソールにログオンすると常に、管理者のユーザー名およびパスワードをEnterprise Managerのリポジトリに保存し、これらの保存された値に対して検証を行います。作成されたEnterprise Managerユーザーは、リポジトリ(データベース)ユーザーでもあります。このオプションを使用すると、この認証方法によって得られるOracle Databaseユーザー管理の利便性(パスワード・プロファイル、パスワードの複雑性の強化、パスワードの有効期限および許容される失敗試行回数によるパスワードの制御など)を利用できます。パスワードの猶予期間の間は管理者はパスワードを変更するように求められますが、パスワードが期限切れになった場合には必ず変更する必要があります。詳細は、第2.1.2項「新規管理者の作成」を参照してください。
Oracle Access Manager (OAM)シングル・サインオン(SSO)ベースの認証: Oracle Access Managerは、Oracle Fusion Middlewareのシングル・サインオン・ソリューションです。ベースとなるアイデンティティ・ストアは、Oracle Access Managerでサポートされているエンタープライズ・ディレクトリ・アイデンティティ・ストアです。この認証スキームは、すべてのエンタープライズ・アプリケーションにわたる認証用の中心的ツールとしてOracle Access Managerで標準化されたデータ・センターに使用されます。Kerberosなどのプロトコルを認証用にサポートする場合には、これに合せてOAMを構成する必要があります。OAMの詳細は、『Oracle Fusion Middleware Oracle Access Manager管理者ガイド12cリリース1 (11.1.1)』を参照してください。
シングル・サインオン(SSO)ベースの認証: シングル・サインオンベースの認証により、エンタープライズ全体にわたって強化された一元的なユーザー・アイデンティティ管理を実現します。Oracle Application Server Single Sign-Onを使用するようにEnterprise Managerを構成すると、シングル・サインオン・ユーザーをEnterprise Manager管理者として登録できます。これにより、シングル・サインオン資格証明を入力してOracle Enterprise Managerコンソールにアクセスできるようになります。
エンタープライズ・ユーザー・セキュリティベースの認証: エンタープライズ・ユーザー・セキュリティ(EUS)オプションを使用すると、LDAP準拠ディレクトリ・サーバーでOracle Databaseのエンタープライズ・ユーザーおよびロールを作成および保存できます。EUSを使用してEnterprise Managerリポジトリを構成した後、第2.1.5項「エンタープライズ・ユーザー・セキュリティベースの認証」の説明に従って、Enterprise ManagerをEUSを認証メカニズムとして使用するよう構成できます。任意のEUSユーザーをEnterprise Manager管理者として登録できます。
EUSは、Enterprise Manager管理者の認証に使用できる他、データベースのターゲット資格証明の管理を簡素化するためにも使用できます。EUSは、複数のデータベース間におけるユーザーとロールの管理を一元化する上で役に立ちます。管理対象データベースがEUSを使用して構成されている場合、これらのデータベースへのログイン・プロセスが容易になります。管理対象データベースにドリルダウンすると、Enterprise ManagerはEnterprise Managerの資格証明を使用してデータベースへの接続を試行します。成功すると、ログオン・ページを表示することなくEnterprise Managerが直接データベースに接続されます。
LDAP認証オプション: Oracle Internet DirectoryおよびMicrosoft Active Directory
Oracle Internet Directory (OID)ベースの認証 - Oracle Internet DirectoryはOracleデータベースに構築されたLDAP v3準拠ディレクトリで、Oracle Fusion MiddlewareおよびOracle Applicationsに完全に統合されています。そのため、Oracle環境やOracleデータベースのノウハウを持つ企業に適しています。OIDをアイデンティティ・ストアとする認証スキームを使用する場合、アプリケーションでOIDによるユーザーの認証を行うことができます。
Microsoft Active Directoryベースの認証 - Microsoft Active DirectoryはWindowsネットワークで認証および認可機能を提供するディレクトリ・サービスです。Microsoft Active Directoryをアイデンティティ・ストアとして使用する場合、このスキームを組み込み、アプリケーションでMicrosoft Active Directoryによるユーザーの認証を行うことができます。
|
注意: Enterprise Managerは、特定の認証スキームがサポートされ、WebLogic Serverに統合されているかぎり、外部の認証をサポートします。 |
これらの認証スキームは組織内でテストされており、次に示す外部認証スキームの一部はemctl config authユーティリティ・コマンドを使用して構成できます。このコマンドは、必要なWebLogicプロバイダを構成し、さらに必要なOMSプロパティを設定します。
emctlユーティリティ・コマンドがWebLogic認証プロバイダを構成する認証スキームでは、このコマンドは必要な構成パラメータを設定し、他のほとんどのパラメータをデフォルト値のままにします。管理者は、本番に入る前に、WebLogicプロバイダの構成パラメータが環境に合ったパフォーマンス用に調整されていることを確認する必要があります。これはWebLogic管理コンソールで実行できます。
プロバイダの調整の詳細は、『Oracle® Fusion Middleware Oracle WebLogic Serverの保護』を参照してください。
Enterprise Managerでは、新しい管理者アカウントを作成して管理できます。管理者アカウントには、それぞれ独自のログオン資格証明や、アカウントに割り当てられた一連のロールおよび権限が含まれています。管理者にパスワード・プロファイルを割り当てることもできます。新規の管理者アカウントを作成および管理するには、Enterprise Managerのスーパー管理者権限が必要になります。
管理者アカウントを作成、編集または表示する手順は、次のとおりです。
「設定」メニューから、「セキュリティ」、「管理者」の順に選択します。管理者ページが表示されます。
「管理者」ページで適切なタスク・ボタンをクリックします。「認証」ページが表示されます。
デフォルトの認証方法として、リポジトリ・ベースの認証が選択されています。
リポジトリ・ベースの認証は、Enterprise Managerの認証のデフォルトの方法です。この認証方法では、新規管理者がリポジトリ内に作成されます。次のページが表示され、新規管理者を定義できます。
|
注意: リポジトリ・ベースの認証が、デフォルトの認証の方法です。 |
このページでは、作成する管理者アカウントのタイプを指定し、パスワード・プロファイルを選択できます。「パスワード変更の回避」チェック・ボックスを選択した場合、管理者はパスワードを変更できません。
「パスワード即期限切れ」チェック・ボックスを選択すると、新規の管理者アカウントのパスワードは有効期限切れの状態に設定されます。パスワードの有効期限が切れている場合、新規の管理者がログインするとパスワードの変更ページが表示され、管理者はパスワードを変更するよう求められます。
管理者は、現在のパスワードと新しいパスワードを入力し、「適用」をクリックします。これで、Enterprise Managerを使用できるようになります。
次の例では、User1をEnterprise Managerユーザーにします。ここでは、ユーザーについての説明を指定し、パスワードを変更できないようにしています。他のスーパー管理者のみがパスワードを変更できます。プロファイルはMGMT_ADMIN_USER_PROFILEとして設定されます。
次の各項では、Enterprise Managerのデフォルトの認証方法に復元する方法について説明します。
OMSがSSO、OAMまたはその他の認証方法を使用するよう構成されている場合、シングル・サインオンまたはOAM認証を省略する必要がある場合があります。SSOログオン・ページを省略するには、次のURLに接続します。
https://ms_host:ms_https_port/emに接続します。
ms_hostとms_https_portは、WLS管理対象サーバーのホスト名とポート番号です。これらのパラメータは、EM_INSTANCE_HOME/emgc.propertiesファイルに含まれています。このファイルでは、EM_INSTANCE_HOSTとMS_HTTPS_PORTとリストされています。
リポジトリ・ユーザーの資格証明を使用してログインします。
OMSごとに次のコマンドを実行します。
emctl config auth repos [-sysman_pwd <pwd>]
コマンドの出力例:
Oracle Enterprise Manager Cloud Control 12c Release 12.1.0.3.0 Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. Configuring Repos Authentication ... Started Configuring Repos Authentication ... Successful If you have updated files like httpd.conf (for example, while installing WebGate), rollback them. If this is a multi-OMS environment, execute this command on remaining servers. After that, restart OMS(s) using: 'emctl stop oms -all' and 'emctl start oms'
OMSごとに次のコマンドを実行します。
emctl stop oms-all
emctl start oms
OAM SSOを構成した場合、手動でWebgateをアンインストールし、WebgateディレクティブをApache httpd.confから削除します。
OSSOで構成した場合、OSSOディレクティブをhttpd.confから削除します。
管理者アカウントを削除するには:
「設定」メニューから、「セキュリティ」、「管理者」の順に選択します。管理者ページが表示されます。
削除する管理者を選択し、「削除」をクリックします。
確認のページで、「はい」をクリックします。
管理者にリソースが割り当てられている場合、管理者の削除ページが表示されます。管理者の削除ページを使用して、管理者をEnterprise Managerから削除する際に管理者が所有していたオブジェクトをどのように扱うかを指定できます。このページでは、次の操作が可能です。
Enterprise Manager管理者とともにすべての管理者所有オブジェクトを削除管理者と関連のジョブ・タイプ、ジョブ、修正処理、レポート定義、レポート、テンプレートを削除します。ブラックアウトは削除されません。
別のEnterprise Manager管理者へのオブジェクトの再割当て管理者のオブジェクトを別の管理者に割り当てます。その管理者に属する資格証明は、再割当てが行われる前にリポジトリから削除されます。
使用上のヒント
「オブジェクトの表示」をクリックすると、削除するEnterprise Manager管理者が現在所有しているすべてのオブジェクトが表示されます。
オブジェクトを別の管理者に再割当てするには、「新規所有者」テキスト・ボックスに新規管理者の名前を入力するか、懐中電灯アイコンをクリックして使用可能な管理者のリストを表示します。
スーパー管理者のみが他のEnterprise Manager管理者を削除できます。Enterprise Managerでは、管理者は次の処理を行うことができません。
自身の削除。
管理リポジトリ所有者の削除。
管理者オブジェクトの再割当ては、次のように処理されます。
「ブラックアウト」は、ブラックアウトの影響を受けるすべてのターゲットに対して「オペレータ」権限を持つ任意のユーザーに再割当てできます。
「ジョブ」は任意の管理者に再割当てできます。ただし、ジョブに関連付けられているすべての資格証明は削除され、ジョブは「一時停止中」状態のままになります。このため、新規ジョブ所有者は新規資格証明を明示的に設定する必要があります。現在実行中のジョブは実行を継続できます。新規ジョブ所有者が資格証明を設定すると、ジョブは「SCHEDULED」状態に戻ります。
「修正処理」は、修正処理の操作対象となるターゲットに対して「オペレータ」権限を持つ任意の管理者に再割当てできます。
「レポート定義」は、任意の管理者に再割当てできます。
「レポート」は、任意の管理者に再割当てできます。
「監視テンプレート」は、任意の管理者に再割当てできます。
Oracle Access Managerシングル・サインオン(OAM SSO)認証スキームを使用する場合、ベースとなるアイデンティティ・ストアは、Oracle Access Managerでサポートされているエンタープライズ・ディレクトリ・アイデンティティ・ストアで構成されます。この項では、OAM SSOベースの認証スキームを構成する手順を示します。
OAM SSOを介した外部認証を使用して新規ユーザーを作成したら、次の図に示すように「外部ユーザーのアイデンティティ・ストア」ボタンを選択します。
Oracle Access Manager (OAM)は別個のホストにインストールされます。Webgateは、サーバーが稼働している各OMSホストにインストールする必要があります。Webgateインストールの場合、次のURLを参照してください:
http://docs.oracle.com/cd/E21764_01/install.1111/e12002/webgate.htm
Enterprise Managerには、OAMRequest.xml.templateというOAMテンプレートがあり、これはOAM SSOサーバーを使用してEnterprise Managerアプリケーションを登録するときに使用する必要があるテンプレートです。このテンプレートは、次の場所にあります。
$MW_HOME/oms/sysman/config
登録に使用する前に、サーバー、ホスト識別子およびエージェント情報を置き換える必要があります。登録方法の詳細は、『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド』のパートナ(エージェントおよびアプリケーション)のリモート登録に関する説明を参照してください。
登録プロセスの一部として特定の構成ファイルが生成され、これはOMSホストでのWebgateの構成の間に必要になります。詳細は、『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』の「OAMのためのOracle HTTP Server 11g Webゲートのインストールと構成」を参照してください。
各OMSでemctl config authコマンドを実行します。
emctl config auth oam [-sysman_pwd <pwd>] -oid_host <host> -oid_port <port>
-oid_principal <principal> [-oid_credential <credential>] [-use_anonymous_bind]
-user_base_dn <dn> -group_base_dn <dn>
-oam_host <host< -oam_port <port> [-logout_url <url>] [-is_oam10g]
[-user_dn <dn>] [-group_dn <dn>] [-enable_auto_provisioning] [-auto_provisioning_minimum_role <min_role>] [-minimum_privilege <min_priv>]
[-use_ssl] [-cert_file <cert>] [-trust_cacerts] [-keystore_pwd <passwd>]
コマンド・オプションは次のとおりです。
[-enable_auto_provisioning] 指定されると、Enterprise Managerでの自動プロビジョニングを有効にします。外部LDAPユーザーをEnterprise Managerで手動でプロビジョニングする必要がなくなります。
[-auto_provisioning_minimum_role <min_role>] 指定されると、LDAPにおいてmin_roleが付与されたEnterprise Manager内の外部ユーザーのみを自動プロビジョニングします。
[-minimum_privilege <min_priv>] 指定されると、min_privが付与されていないユーザーへのEnterprise Managerへのアクセスが禁止されます。
[-use_ssl] LDAPサーバーへの接続にsslを使用します。
[-cert_file <cert>] 渡されたLDAPサーバー証明書を使用して、sslによるLDAPサーバーへの接続の間に信頼性を確立します。このオプションは、LDAPサーバーによく知られていない(信頼されない)認証局により署名された証明書がある場合に指定します。注意: これは単一の証明書を想定しています。証明連鎖のインポートはサポートしていません。keytoolユーティリティを使用してインポートしてから、このコマンドを実行してください。
[-trust_cacerts] LDAPサーバーへの接続の間、LDAPサーバーの証明書を信頼します。これは通常、証明書がよく知られたCAにより署名されている場合に使用します。
[-keystore_pwd <passwd>] デフォルトのDemoTrust.jksキーストア(デフォルトのパスワードが変更された場合)または検証の一部としてLDAPサーバーの証明書がインポートされるカスタムのキーストアのパスワード。
[-use_anonymous_bind] 指定されると、LDAPサーバーに接続するために匿名バインドを使用します。
注意: -is_oam10gオプションは、OAMのバージョンが10gの場合にのみ渡します。
各OMSを停止します。
emctl stop oms-all
各OMSを再起動します。
emctl start oms
SSO構成を削除するには、emctl config auth reposコマンドを実行します。これにより、emctl config auth oamコマンドで構成されたWeblogicプロバイダおよびOMSプロパティが削除されます。
|
注意: 管理者は手動でWebgateをアンインストールし、httpd.confを編集してWebgate関連のエントリを削除する必要があります。 |
現在Oracle Application Server Single Sign-On (Oracle SSO)を使用してエンタープライズ・アプリケーションのアクセスと認可を制御している場合、これらの機能をEnterprise Managerコンソールに拡張できます。
デフォルトでは、Enterprise Managerにはメインのログオン・ページが表示されます。ただし、Oracle Application Server Single Sign-Onを使用してEnterprise Managerのユーザーを認証するようにEnterprise Managerを構成できます。ユーザーには、Enterprise Managerのログオン・ページではなく、Oracle Application Server Single Sign-Onの標準のログオン・ページが表示されます。管理者は、このログオン・ページで各自のOracle Application Server Single Sign-On資格証明を使用してOracle Enterprise Manager 12c Cloud Controlコンソールにアクセスできます。
|
注意:
|
次の項では、Enterprise ManagerをOracle Application Server Single Sign-Onパートナ・アプリケーションとして構成する方法について説明します。
Enterprise Managerをパートナ・アプリケーションとして手動で登録するには、次の手順を実行します。
各OMSでemctl stop omsを実行し、すべてのOMSを停止します。
次のURLを入力してSSO管理ページにナビゲートします。
https://sso_host:sso_port/pls/orasso
orcladminユーザーとしてログインし、「SSOサーバー管理」をクリックします。
「パートナ・アプリケーション管理」をクリックして「パートナ・アプリケーションの追加」をクリックします。
「パートナ・アプリケーションの追加」ページで次の情報を入力します。
Name: <EMPartnerName> Home URL: protocol://em_host:em_port Success URL: protocol://em_host:em_port/osso_login_success Logout URL: protocol://em_host:em_port/osso_logout_success Administrator Email: user@host.com
注意1: host、portおよびprotocolは、使用されるEnterprise Managerのホスト、ポートおよびプロトコル(httpまたはhttps)のことです。
注意2: em_host、em_port、emailおよびEnterprise Managerパートナ名は適切な値に置き換える必要があります。この例のとおりに入力しないでください。
パートナ・アプリケーション管理ページに戻り、<EMPartnerName>の「編集」アイコンをクリックします。
「ID」、「トークン」、「暗号化鍵」、「ログインURL」、「シングル・サインオフURL」、「ホームURL」の値を記録し、ファイルosso.txtに次の内容を含めます。
sso_server_version= v1.2 cipher_key=<value of EncryptionKey> site_id=<value of ID> site_token=<value of Token> login_url=<value of Login URL> logout_url=<value of Single Sign-Off URL> cancel_url=<value of Home URL> sso_timeout_cookie_name=SSO_ID_TIMEOUT sso_timeout_cookie_key=9E231B3C1A3A808A
ORACLE_HOME環境変数をWebTier Oracleホームの場所に設定します。
setenv ORACLE_HOME /scratch/12c/MWHome/Oracle_WT
次のように実行します。
$ORACLE_HOME/ohs/bin/iasobf <location of osso.txt> <location of osso.conf>
OMSごとに次のコマンドを実行します。
emctl config auth sso -ossoconf <osso.conf file loc> -dasurl <DAS URL> [-unsecure] [-sysman_pwd <pwd>] [-domain <domain>]-ldap_host <ldap host> -ldap_port <ldap port> -ldap_principal <ldap principal> [-ldap_credential <ldap credential>] -user_base_dn <user base DN> -group_base_dn <group base DN> [-logout_url <sso logout url>]
ldap_host、ldap_port、ldap_principalおよびldap_credentialは、SSOのLDAPの詳細です。
このコマンドの出力例を次に示します。
Oracle Enterprise Manager Cloud Control 12c Release 12.1.0.3.0 Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. SSO Configuration done successfully. Please restart Admin & Managed Servers.
OMSごとに次のコマンドを実行します。
emctl stop oms -all emctl start oms
シングル・サインオン構成を削除するには、次のようにします。
OMSごとに次のコマンドを実行します。
emctl config auth repos [-sysman_pwd <pwd>]
コマンドの出力例:
Oracle Enterprise Manager Cloud Control 12c Release 12.1.0.3.0 Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. Configuring Repos Authentication ... Started Configuring Repos Authentication ... Successful
httpd.conf (WebGateのインストール時)などのファイルを更新した場合、またはその他の必要なファイルは、この手順中のロールバックのために、事前にバックアップする必要があります。複数OMS環境を使用している場合、残りのサーバーで、emctl config auth reposコマンドを実行する必要があります。
各OMSで次のコマンドを発行し、すべてのOMSを再起動します。
emctl stop oms -all emctl start oms
シングル・サインオン・ログオン・ページを使用するようにEnterprise Managerを構成すると、シングル・サインオン・ユーザーをEnterprise Manager管理者として登録できます。シングル・サインオン・ユーザーを登録するには、次のインタフェースを使用します。
Enterprise Managerグラフィカル・ユーザー・インタフェース
Enterprise Managerコマンドライン・インタフェース
グラフィカル・ユーザー・インタフェースを使用してシングル・サインオン・ユーザーを登録するには、次の手順を実行します。
Enterprise ManagerコンソールのURLに移動します。
ブラウザはシングル・サインオンの標準ログオン・ページにリダイレクトされます。
有効なシングル・サインオン・ユーザーの資格証明を入力します。注意: このステップでは、SSOユーザーがEnterprise Managerに登録済である必要があります。
SSOユーザーがEnterprise Managerユーザーとしてまだ登録されていない場合、次の手順を使用して作成できます。
管理対象サーバー(MS)に直接接続し、Enterprise Managerにログインします。たとえば、https://ms_host:ms_https_port/emです。
リポジトリ・ユーザーとしてログインします。
「設定」メニューから、「セキュリティ」、「管理者」の順に選択します。
SSOユーザーを作成します。
スーパー管理者としてEnterprise Managerにログインします。
「設定」メニューから、「セキュリティ」、「管理者」の順に選択し、管理者ページを表示します。
Enterprise Managerはシングル・サインオンを使用するように構成されているため、管理者の作成ウィザードの最初のページには、管理者を外部ユーザーとリポジトリ・ユーザーのいずれで作成するかのオプションが表示されます。
「外部ユーザーのアイデンティティ・ストア」を選択し、ウィザードの次のページに進みます。
外部ユーザー・アイデンティティ・ストア・ユーザーの名前と電子メール・アドレスを入力するか、懐中電灯アイコンをクリックしてOracle Internet Directoryでユーザー名を検索します。
ウィザードの残りのページを使用してEnterprise Manager管理者のロール、システム権限、その他の特徴を定義してから「終了」をクリックします。
Enterprise Managerには、管理者アカウントの特徴をリストする概要ページが表示されます。
「終了」をクリックして、新しいEnterprise Manager管理者を作成します。
これで、外部ユーザー・アイデンティティ・ストア・ユーザーがEnterprise Manager管理者のリストに含まれます。Cloud Controlコンソールからログアウトし、シングル・サインオン・ログオン・ページで外部ユーザー・アイデンティティ・ストア・ユーザーの資格証明を使用してログインしなおすことで、アカウントを検証できます。
次のEM CLIコマンドを使用してシングル・サインオン・ユーザーを作成できます。
emcli create_user -name=ssouser -type=EXTERNAL_USER
このコマンドは、ssouserという名前でユーザーを作成します。このユーザーは、Oracleシングル・サインオンにより認証されます。
| パラメータ | 説明 |
|---|---|
| -name | 管理者の名前。 |
| -type | ユーザーのタイプ。このパラメータのデフォルト値はEM_USERです。その他に次の値が可能です。
|
| -password | 管理者のパスワード。 |
| -roles | 該当の管理者に付与できるロールのリスト。 |
| 該当の管理者の電子メール・アドレスのリスト。 | |
| -privilege | 管理者に付与できるシステム権限。このオプションは、複数回指定できます。 |
| -profile | データベース・プロファイルの名前。これはオプションのパラメータです。使用されるデフォルトのプロファイルはDEFAULTです。 |
| -desc | 追加するユーザーの説明です。 |
| -expired | このパラメータは、パスワードを「期限切れ」ステータスに設定する場合に使用されます。これはオプションのパラメータであり、デフォルトではFalseに設定されます。 |
| -prevent_change_password | このパラメータをTrueに設定すると、ユーザーはパスワードを変更できません。これはオプションのパラメータであり、デフォルトではFalseに設定されます。 |
| -input_file | このパラメータにより、管理者は、入力ファイルにこれらの引数の値を提供できます。値の形式はname_of_argument:file_path_with_file_nameになります。 |
例1
emcli create_user
-name="new_admin"
-email="first.last@mycompany.com;joe.shmoe@shmoeshop.com"
-roles="public"
-privilege="view_job;923470234ABCDFE23018494753091111"
-privilege="view_target;<host>.com:host"
この例では、new_adminというEnterprise Manager管理者を作成します。この管理者には、ID 923470234ABCDFE23018494753091111のジョブを表示する機能と、ターゲット<host>.com:hostを表示する機能の2つの権限があります。管理者new_adminにはPUBLICロールが付与されます。
例2
emcli create_user
-name="User1"
-type="EXTERNAL_USER"
-input_file="privilege:/home/user1/priv_file"
Contents of priv_file are:
view_target;<host>.com:host
この例では、Enterprise Managerユーザーとして外部で作成されたuser1を作成します。user1には、<host>.com:hostに対する表示権限があります。
例3
emcli create_user
-name="User1"
-desc="This is temp hire."
-prevent_change_password="true"
-profile="MGMT_ADMIN_USER_PROFILE"
この例では、user1をEnterprise Managerユーザーとして、説明付きで設定します。prevent_change_passwordは、user1によってパスワードを変更できないようにtrueに設定され、profileはMGMT_ADMIN_USER_PROFILEに設定されます。
例4
emcli create_user
-name="User1"
-desc="This is temp hire."
-expire="true"
この例では、user1をEnterprise Managerとして、説明付きで設定します。パスワードの有効期限はすぐに切れるように設定されるため、ユーザーが初めてログインすると、パスワードの変更が求められます。
OMSがSSO、OAMまたはその他の認証方法を使用するよう構成されている場合、シングル・サインオンまたはOAM認証を省略する必要がある場合があります。SSOログオン・ページを省略するには、次のURLに接続します。
https://ms_host:ms_https_port/emに接続します。
ms_hostとms_https_portは、WLS管理対象サーバーのホスト名とポート番号です。これらのパラメータは、EM_INSTANCE_HOME/emgc.propertiesファイルに含まれています。このファイルでは、EM_INSTANCE_HOSTとMS_HTTPS_PORTとリストされています。
リポジトリ・ユーザーの資格証明を使用してログインします。
OMSごとに次のコマンドを実行します。
emctl config auth repos [-sysman_pwd <pwd>]
コマンドの出力例:
Oracle Enterprise Manager Cloud Control 12c Release 12.1.0.3.0 Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. Configuring Repos Authentication ... Started Configuring Repos Authentication ... Successful If you have updated files like httpd.conf (for example, while installing WebGate), rollback them. If this is a multi-OMS environment, execute this command on remaining servers. After that, restart OMS(s) using: 'emctl stop oms -all' and 'emctl start oms'
OMSごとに次のコマンドを実行します。
emctl stop oms -all emctl start oms
エンタープライズ・ユーザー・セキュリティでは、Oracle Internet Directory (OID)やMicrosoft Active DirectoryなどのLDAP準拠のディレクトリ・サーバーにOracle Databaseの情報をディレクトリ・オブジェクトとして作成して格納できます。たとえば、管理者は、Oracle Databaseのエンタープライズ・ユーザーとロールをディレクトリに作成したり、格納できるため、複数のデータベースのユーザーとロールの管理の一元化に役立ちます。
|
関連項目: 『Oracle Database Advanced Securityガイド』のエンタープライズ・ユーザー・セキュリティ構成のタスクおよびトラブルシューティングに関する項 |
現在、エンタープライズ・ユーザー・セキュリティを使用してすべてのOracle DatabaseのOracleユーザーやロールを管理している場合、この機能を拡張してEnterprise Manager管理者アカウントも管理するようにできます。エンタープライズ・ユーザー・セキュリティで使用するようにEnterprise Managerを構成すると、Oracle Enterprise Managerコンソールで管理しているデータベース・ターゲットへのログイン・プロセスが簡単になります。
エンタープライズ・ユーザー・セキュリティで使用するようにEnterprise Managerを構成するには、次の手順を実行します。
Oracle Management Repositoryデータベースと、Cloud Controlコンソールで管理するデータベース・ターゲットに対してエンタープライズ・ユーザー・セキュリティが有効であることを確認します。詳細は、『Oracle Database Advanced Securityガイド』を参照してください。
emctl set propertyコマンドを使用して次のプロパティを設定します。
oracle.sysman.emSDK.sec.DirectoryAuthenticationType=EnterpriseUser
|
注意: 複数OMS構成の場合、このコマンドは各OMSで実行される必要があります。 |
例:
emctl set property -name oracle.sysman.emSDK.sec.DirectoryAuthenticationType -value EnterpriseUser
Oracle Management Serviceを停止します。
emctl stop oms-all
|
関連項目: 24-4ページの「Oracle Management Serviceの制御」 |
管理サービスを開始します。
emctl start oms
次回Oracle Enterprise Managerコンソールを使用して管理対象データベースにドリルダウンすると、Enterprise Managerはエンタープライズ・ユーザー・セキュリティを使用してデータベースへの接続を試みます。これが成功した場合、ログオン・ページは表示されずにEnterprise Managerによってデータベースに接続します。エンタープライズ・ユーザー・セキュリティの使用が失敗した場合、Enterprise Managerからデータベースの資格証明が求められます。
エンタープライズ・ユーザー(EUS)を使用するようにEnterprise Managerを構成すると、既存のエンタープライズ・ユーザーをEnterprise Managerユーザーとして登録し、Enterprise Managerを効率的に管理できるようにそのユーザーに必要な権限を付与できます。
既存のエンタープライズ・ユーザーを登録するには、次のインタフェースを使用します。
Enterprise Managerコンソール
Enterprise Managerコマンドライン・インタフェース(EM CLI)
Enterprise Managerコンソールを使用してエンタープライズ・ユーザーを登録するには、次の手順を実行します。
スーパー管理者としてEnterprise Managerにログインします。
「設定」メニューから、「セキュリティ」、「管理者」の順に選択し、管理者ページを表示します。Enterprise Managerはエンタープライズ・ユーザーを使用するように構成されているため、管理者の作成ウィザードの最初のページには、登録されているOracle Internet Directoryユーザーまたは通常のデータベース・ユーザーに基づいて管理者を作成するオプションが表示されます。
Oracle Internet Directoryを選択し、「続行」をクリックしてウィザードの次のページに移動します。
Oracle Internet Directoryユーザーの名前と電子メール・アドレスを入力するか、懐中電灯アイコンをクリックしてOracle Internet Directoryでユーザー名を検索します。
ウィザードの残りのページを使用してEnterprise Manager管理者のロール、システム権限、その他の特徴を定義してから「終了」をクリックします。Enterprise Managerには、管理者アカウントの特徴をリストする概要ページが表示されます。
「終了」をクリックして、新しいEnterprise Manager管理者を作成します。
これで、OIDユーザーがEnterprise Manager管理者のリストに含まれます。Cloud Controlコンソールからログアウトし、シングル・サインオン・ログオン・ページでOIDユーザーの資格証明を使用してログインしなおすことで、アカウントを検証できます。
EM CLIを使用してエンタープライズ・ユーザーをEnterprise Managerユーザーとして登録するには、次のコマンドを入力します。
emcli create_user -name=eususer -type=DB_EXTERNAL_USER
このコマンドでは、eususerをEnterprise Managerユーザーとして登録します。eususerは、既存のエンタープライズ・ユーザーです。詳細は、「EM CLIを使用したシングル・サインオン・ユーザーの登録」を参照してください。
OIDベースの認証スキームを実装し、Enterprise ManagerでOIDによるユーザーの認証を行うことができます。
OMSでemctl config auth oidコマンドを実行して、コマンドで指定した構成パラメータ値を使用する、OracleInternetDirectoryAuthenticatorタイプのWebLogic認証プロバイダを作成します。指定しない構成値はデフォルト値のままです。拡張OID構成パラメータのチューニングと変更は、emctl config auth oidコマンドではなく、WebLogic Server管理コンソールを使用して実行されます。
|
注意: LDAPトラブルシューティングを実行する必要があるイベントでは、WebLogic Serverコンソールから、LDAPトレース・ログ・ファイル(ldap_trace.logATN)の生成を有効にします。詳細は、「Enterprise Managerでの認証問題のトラブルシューティング」を参照してください。 |
Oracle Internet Directory LDAPサーバーが設定され、実行中です。
WebLogic管理サーバーが起動され、実行中であること。
各OMSでemctl config auth oidコマンドを実行します。
emctl config auth ad -ldap_host <ldap host> -ldap_port <ldap port>
-ldap_principal <ldap principal> [-ldap_credential <ldap credential>] [-sysman_pwd <pwd>]
-user_base_dn <user base DN> -group_base_dn <group base DN> [-user_dn <dn>] [-group_dn <dn>]
[-enable_auto_provisioning] [-auto_provisioning_minimum_role <min_role>] [-minimum_privilege <min_priv>]
[-use_ssl] [-cert_file <cert>] [-trust_cacerts] [-use_anonymous_bind] [-keystore_pwd <passwd>]
説明:
ldap_host: LDAPホスト名
ldap_port: LDAPポート
ldap_principal: WebLogic ServerがLDAPサーバーとの接続に使用するLDAPユーザーの識別名(DN)。
ldap_credential: ldap_principalで指定されたユーザーのパスワード。
user_base_dn: ユーザーが含まれているLDAPディレクトリのツリーの基本識別名(DN)。
group_base_dn: グループが含まれているLDAPディレクトリのツリーの基本識別名(DN)。
enable_auto_provisioning: 指定されると、Enterprise Managerで自動プロビジョニングを有効にします。外部LDAPユーザーをEnterprise Managerで手動でプロビジョニングする必要がなくなります。
auto_provisioning_minimum_role <min_role>: 指定されると、LDAPにおいてmin_roleが付与されたEnterprise Manager内の外部ユーザーのみを自動プロビジョニングします。
minimum_privilege <min_priv>: 指定されると、min_privが付与されていないユーザーへのEnterprise Managerへのアクセスが禁止されます。
use_ssl: LDAPサーバーへの接続にSSLを使用します。
cert_file <cert>: 渡されたLDAPサーバー証明書を使用して、sslによるLDAPサーバーへの接続の間に信頼性を確立します。このオプションは、LDAPサーバーによく知られていない(信頼されない)認証局により署名された証明書がある場合に指定します。注意: これは単一の証明書を想定しています。証明連鎖のインポートはサポートしていません。keytoolユーティリティを使用してインポートしてから、このコマンドを実行してください。
trust_cacerts: LDAPサーバーへの接続の間、LDAPサーバーの証明書を信頼します。これは通常、証明書がよく知られたCAにより署名されている場合に使用します。
keystore_pwd <passwd>: デフォルトのDemoTrust.jksキーストア(デフォルトのパスワードが変更された場合)または検証の一部としてLDAPサーバーの証明書がインポートされるカスタムのキーストアのパスワード。
use_anonymous_bind: 指定されると、LDAPサーバーに接続するために匿名バインドを使用します。
例:
emctl config auth oid -ldap_host "ldaphost" -ldap_port "3060" -ldap_principal "cn=orcladmin,cn=users,dc=us,dc=oracle,dc=com" -user_base_dn "cn=users,dc=us,dc=oracle,dc=com" -group_base_dn "cn=groups,dc=us,dc=oracle,dc=com" -ldap_credential "my_ldap_password" -sysman_pwd "my_sysman_password"
OMSを停止します。
emctl stop oms-all
OMSを再起動します。
emctl start oms
|
注意: 複数OMSインスタンスで構成されるEnterprise Managerのデプロイメントの場合、emctl config auth oidを各OMSで実行する必要があります。変更内容を有効にするには、各OMSを再起動する必要があります。 |
Microsoft ADベースの認証スキームを実装し、Enterprise ManagerでActive Directoryに対するユーザーの認証を行うことができます。
OMSでemctl config auth adコマンドを実行すると、このコマンドで指定した構成パラメータ値を使用する、ActiveDirectoryAuthenticatorタイプのWebLogic認証プロバイダが作成されます。指定しない構成値はデフォルト値のままです。拡張AD構成パラメータのチューニングと変更は、emctl config auth adコマンドではなく、WebLogic Server管理コンソールを使用して実行されます。
次の手順を実行する前に、Active DirectoryのLDAPサーバーが起動され実行中であることを確認します。
各OMSでemctl config auth oidコマンドを実行します。
emctl config auth ad -ldap_host <ldap host> -ldap_port <ldap port> -ldap_principal <ldap principal> [-ldap_credential <ldap credential>] [-sysman_pwd <pwd>] -user_base_dn <user base DN> -group_base_dn <group base DN>
説明:
ldap_host: Active Directoryがインストールされているマシンの名前。
ldap_port: Active Directoryがリクエストをリスニングしているアクティブ・ポート。
ldap_principal: ユーザーの妥当性を確認するために、WebLogic ServerがLDAPサーバーとの接続に使用するActive Directoryユーザーの識別名(DN)。
ldap_credential: ldap_principalで指定されたユーザーのパスワード。
sysman_pwd: SYSMANパスワード。このパスワードは、必要なプロパティ値の変更をEnterprise Managerに設定するために必要です。
user_base_dn: ldap_principalとして指定されたユーザーには、このディレクトリへの読取りアクセス権が必要です。ユーザーが複数のベースDNに配置されている場合、このフィールドには最上位の最も一般的なDNを入力します。このフィールドは、複数エントリは受け付けません。
group_base_dn: ldap_principalとして指定されたユーザーには、このディレクトリへの読取りアクセス権が必要です。
例:
emctl config auth ad -ldap_host "ldaphost" -ldap_port "3060" -ldap_principal "cn=orcladmin" -user_base_dn "cn=users,dc=us,dc=oracle,dc=com" -group_base_dn "cn=groups,dc=us,dc=oracle,dc=com" -ldap_credential "my_ldap_password" -sysman_pwd "my_sysman_password"
OMSを停止します。
emctl stop oms-all
OMSを再起動します。
emctl start oms
|
注意: 複数OMSインスタンスで構成されるEnterprise Managerのデプロイメントの場合、emctl config auth adを各OMSで実行する必要があります。変更内容を有効にするには、各OMSを再起動する必要があります。 |
Enterprise Managerをユーザーの外部認証用に構成する場合、外部認証プロバイダとともに機能するように構成して認可を管理することもできます。これは外部ロールを使用して行われます。これは、自動プロビジョニングされたユーザーがEnterprise Managerロールを付与されていない場合(この場合に限定されません)など、多くのシナリオで役立ちます。外部ロールの背景にあるアイデアは、適切な権限を使用してEnterprise Managerでロールを作成し、ロールの名前をLDAPグループの名前と一致させることです。LDAPグループの一部であるユーザーは、Enterprise Managerに一度ログオンするとそのロールでの権限を自動的に付与されます。
外部ロールを設定するには、Enterprise Managerでロールを作成し、それを外部としてマークします。このロールの名前は、外部LDAPグループと同じである必要があります。必要なロールと権限でこのロールを設定します。たとえば、Enterprise Managerで、外部としてマークされたEM_ADMINというロールを作成できます。EM_ADMINという名前は、LDAPグループのEM_ADMINという名前と一致します。JohnDoeがEM_ADMIN LDAPグループのメンバーだとすると、Enterprise Managerのユーザーでもあります。JohnDoeがEnterprise Managerにログオンすると、Enterprise ManagerのロールEM_ADMINで定義されたすべての権限が付与されます。
通常、外部LDAPユーザーは、Enterprise Managerコンソールにログインできるようになる前に、Enterprise Managerで作成される必要があります。自動プロビジョニングでは、ユーザーが最初にEnterprise Managerに正常にログオンすると、Enterprise Managerのユーザー・アカウントが自動的に作成されるため、この必要がなくなります。
自動プロビジョニングを有効にするには、OMSプロパティのoracle.sysman.core.security.auth.autoprovisioningをtrueに設定します。
このパラメータは、emctlまたはコンソールを使用して設定できます。
これにより外部ユーザーは、Enterprise ManagerリポジトリでEnterprise Managerユーザーとして最初に作成されなくてもログインできるようになります。このユーザー・アカウントは、最初のログインで自動的に作成されます。このプロパティが一度設定されると、すべての外部LDAPユーザーがEnterprise Managerコンソールにログインできるようになります。自動プロビジョニング機能を特定のLDAPグループのメンバーのみなど、ユーザーのサブセットにさらに制限するには、別のOMSプロパティのoracle.sysman.core.security.auth.autoprovisioning_minimum_roleを設定します。このプロパティは、メンバーが自動プロビジョニングされる必要のあるLDAPグループに設定される必要があります。たとえば、EM_ADMINに設定された場合、EM_ADMINというLDAPグループのメンバーのみがEnterprise Managerにログインでき、Enterprise Managerで自動的に作成されたユーザー・アカウントを持つことになります。
デフォルトでは、WebLogicコンソール>「セキュリティ・レルム」>「myrealms」>「ユーザーとグループ」>「ユーザー・リスト」に表示されるユーザー名を使用してOracle Enterprise Managerにログインする必要があります。外部プロバイダでOracle Enterprise Managerを認証すると、WebLogicコンソールのユーザー・リストに外部ユーザーのcn値が表示されます。
一部の環境では、cn値の形式は'FIRST NAME LAST NAME'です。sAMAccountNameまたはユーザーID (UID)を使用してOracle Enterprise Managerにログインする場合は、プロバイダの構成を更新する必要があります。
たとえば、WebLogicコンソールにユーザー名'TEST USER'と表示されるユーザーが、このユーザーのsAMAccountNameである'tuser'としてOracle Enterprise Managerにログインするとします。
|
注意: この例ではsAMAccountNameが使用されています。UIDを使用するには、次の手順でsAMAccountNameをuidに置き換えます。 |
外部プロバイダで、外部ユーザーに構成されているパラメータ/プロパティをチェックします。
パラメータ'cn'の値は'TEST USER'です。
同じファイルで、ユーザーの値が'tuser'のパラメータを探します。そのパラメータは'sAMAccountName'です。
外部ユーザー(tuser)のsAMAccountNameを使用してOracle Enterprise Managerにログインするには:
<GC DOAMIN>/config/config.xmlファイルをバックアップします。
WebLogicコンソールで、「セキュリティ・レルム」>「myrealm」>「プロバイダ」>外部オーセンティケータに移動します。
「ロックと編集」をクリックしてこのページを編集します。
「プロバイダ固有」タブをクリックします。
名前指定によるユーザー・フィルタを探します。
名前指定によるユーザーの値を(&(cn=%u)(objectclass=person))から(&(sAMAccountName=%u)(objectclass=person))に変更します。
「ユーザー名属性」を探します。
「ユーザー名属性」の値をcnからsAMAccountNameに変更します。
「保存」をクリックし、「変更のアクティブ化」をクリックします。
-allオプションを使用して、Oracle Management Serverを再起動します。
<OMS_HOME>/bin>./emctl stop oms -all -force
<OMS_HOME>/bin>./emctl start oms
WebLogicコンソール>「セキュリティ・レルム」>「myrealms」>「ユーザーとグループ」>「ユーザー・リスト」にログインして、ユーザー'tuser'がユーザー・リストに存在することを確認します。これで、ユーザー名'tuser'を使用してOracle Enterprise Managerにログインできるようになりました。
Oracle Enterprise Managerリリース12.1.0.4以上では、Oracle Virtual Directoryレイヤでユーザー名の変更を更新するために、次の追加の手順を実行する必要があります。
<MW_HOME>/oracle_common/common/bin/wlst.sh and <GCDomain>/config/fmwconfig/ovd/default/adapter.os_xmlファイルをバックアップします。
<MW_HOME>/oracle_common/common/bin/wlst.shファイルをテキスト・エディタで開き、次のパラメータをWLST_PROPERTIESに追加します。
-Dweblogic.ssl.JSSEEnabled=true -Djavax.net.ssl.keyStore=<MW HOME>/wlserver_10.3/server/lib/DemoIdentity.jks -Djavax.net.ssl.keyStorePassword=DemoIdentityKeyStorePassPhrase -Djavax.net.ssl.trustStore=<MW HOME>/wlserver_10.3/server/lib/DemoTrust.jks -Djavax.net.ssl.trustStorePassword=DemoTrustKeyStorePassPhrase -Dweblogic.security.SSL.trustedCAKeyStore=<MW HOME>/wlserver_10.3/server/lib/DemoTrust.jks -Dweblogic.security.SSL.ignoreHostnameVerification=true
例:
WLST_PROPERTIES="-Dweblogic.ssl.JSSEEnabled=true
-Djavax.net.ssl.keyStore=/u01/mwr/wlserver_10.3/server/lib/DemoIdentity.jks
-Djavax.net.ssl.keyStorePassword=DemoIdentityKeyStorePassPhrase
-Djavax.net.ssl.trustStore=/u01/mwr/wlserver_10.3/server/lib/DemoTrust.jks
-Djavax.net.ssl.trustStorePassword=DemoTrustKeyStorePassPhrase
-Dweblogic.security.SSL.trustedCAKeyStore=/u01/mwr/wlserver_10.3/server/lib/DemoTrust.jks
-Dweblogic.security.SSL.ignoreHostnameVerification=true ${WLST_PROPERTIES}
-DORACLE_HOME='${ORACLE_HOME}' -DCOMMON_COMPONENTS_HOME='${COMMON_COMPONENTS_HOME}'"
export WLST_PROPERTIES
|
注意: サード・パーティ証明書またはカスタム証明書をWebLogic Serverにインポートした場合は、前述の例で、パスをそれぞれのキーストアに置き換える必要があります。カスタム・パスはconfig.xmlファイルにあります。 |
<MW_HOME>/oracle_common/common/bin/wlst.shを起動します。
次のコマンドを入力して管理サーバーに接続します。
connect('weblogic','<weblogic password>','t3s://<ADMIN SERVER HOSTNAME>:<ADMIN SERVER PORT>')
例:
connect('weblogic','<weblogic password>','t3s://hostname.domain.com:7102')
次のコマンドを入力します。
$addPlugin(adapterName='ADAPTER_NAME',pluginName='changerdn',pluginClass='oracle.ods.virtualization.engine.chain.plugins.changeuserrdn.ChangeUserRDN',paramKeys='replaceValue|fromRDN|toRDN',paramValues='true|cn|sAMAccountName')
|
注意: 前述のコマンドのadapterNameパラメータに、管理サーバー・コンソール上のLDAPプロバイダの名前を指定する必要があります。 |
次のコマンドを入力してOMSを停止します。
<OMS HOME>/bin>./emctl stop oms -all -force
OMSパスからプロセスが実行されていないことを確認します。
次のコマンドを入力して、管理サーバーとOMSを起動します。
<OMS HOME>/bin>./emctl start oms -admin_only<OMS HOME>/bin>./emctl start oms
外部認証が有効な場合、「ユーザーの作成」フローの名前フィールドの横に懐中電灯のアイコンが表示されます。
|
注意: Enterprise Managerで、管理者が初めて作成されると、外部認証が有効になります。 |
この懐中電灯をクリックするとポップアップ・ウィンドウが表示され、Enterprise Managerの管理者は構成済の外部LDAPサーバー(たとえばADまたはOID)のエンタープライズ・ユーザーを検索できます。また、そのユーザーのLDAP属性も表示されます。これにより、Enterprise Managerの管理者はEnterprise Managerで外部ユーザーの属性を作成する前にその属性を確認できます。次のスクリーン・ショットは、外部LDAPユーザー「johndoe」および彼のすべてのLDAPアカウント属性が表示されたポップアップの例です。
外部認証を構成したら、多くの場合LDAPのユーザーに対して定義された電子メールアドレス、部署などのユーザー情報が対応するEnterprise Managerのユーザー・アカウントに自動的に伝搬されることが期待されます。これは、OMSプロパティのoracle.sysman.core.security.auth.ldapuserattributes_emuserattributes_mappingsを設定することでできるようになります。このプロパティには、ユーザー・プロパティの移入に使用される、Enterprise Managerのユーザー・プロパティと対応するLDAPユーザー属性との間のマッピングが含まれます。Enterprise ManagerプロパティとLDAP属性との間のマッピングは、<キー>={%属性%}の形式で表現されます。各項目の意味は次のとおりです。
キー: Enterprise Managerのユーザー・プロパティです。ユーザー・プロパティの値は、次のとおりです。
USERNAME
CONTACT
LOCATION
DEPARTMENT
COSTCENTER
LINEOFBUSINESS
DESCRIPTION
これ以外の値がキーに指定された場合は無視されます。
属性: LDAPからフェッチされ、Enterprise Managerでユーザーのプロパティの設定に使用される必要のあるユーザー属性。属性は、{%属性%}の形式(たとえば、{%mail%})で指定する必要があります。
%間の値はLDAPサーバーの有効な属性である必要があります。属性値を指定する場合、次の例のようにリテラル文字列を指定することもできます。
DESCRIPTION={%firstname% %lastname% employee}
この例では、LDAPから名前と姓のみがフェッチされますが、ユーザーの説明は「名姓従業員」となります。たとえば、「John Doe従業員」となります。
別の例では、CONTACT={電話番号%phone%}のようにもできます。リテラル文字列値にカンマを指定する必要がある場合、次の例のように「\」を使用してエスケープする必要があります。
DESCRIPTION={%lastname% \, %firstname% \, %phone%}
この結果は、「Doe, John, 212-454-0000」と説明されるユーザーとなります。リテラル文字列で指定される場合で、バックスラッシュ(\)を使用してエスケープする必要がある他の文字は、「:」、「=」で、これらは\:または\=のように入力します。
したがって、OMSプロパティoracle.sysman.core.security.auth.ldapuserattributes_emuserattributes_mappingsは、カンマで区切られたキーと属性のペアのセットで設定する必要があります。
例として、ユーザーJOHNDOEはLDAPに存在し、次の属性を持つものとします。
uid=johndoe,mail=johndoe@company.com,description=EM LDAP Admin,postalcode=90210,department=EnterpriseAdmin,telephone=2124540000,displayname=JohnDoe
OMSプロパティを、
oracle.sysman.core.security.auth.ldapuserattributes_emuserattributes_mappings to "USERNAME={%uid%},EMAIL={%mail%},CONTACT={%telephone%},DEPARTMENT={%department%},DESCRIPTION={%description%},LOCATION={%postalcode%}"
のように設定した場合、ポップアップ・ウィンドウでユーザーを選択して「OK」を押すと、ユーザーの属性が「ユーザーの作成」ページの該当するフィールドに自動的に移入されます。
LDAP環境の一部では、ユーザーが数字のログインIDを持つことになる場合があります。Enterprise Managerには、ユーザーが数字のIDを使用してログインしたときに、わかりやすいユーザー名を表示する機能があります。ユーザーがEnterprise Managerコンソールにログオンすると、この数字のIDは、監査レコードなどユーザー名が表示されるところにはどこにでも表示され、使用されます。名前をもっとわかりやすく表示するために、OMSプロパティのoracle.sysman.core.security.auth.enable_username_mappingを使用して、Enterprise Managerに表示される名前よりも直感的な外部の名前をマッピングできます。このプロパティは、emctlを使用して変更できます。
emctl set property –name ”oracle.sysman.core.security.auth.enable_username_mapping” –value ”true”
これは、Enterprise Managerコンソールを使用して設定することもできます。動的プロパティがあり、管理サービスをバウンスする必要がありません。
有効にすると、Enterprise Managerにログオンするユーザーに使用される名前またはIDを含む「外部ユーザーID」フィールドが追加されます(この名前またはIDは有効なユーザーとしてLDAPに存在します)。管理者の作成ページが表示されます。
たとえば、外部ユーザー123456がログインし、johndoeをログインユーザーとして表示する場合には、「名前」フィールドに「johndoe」と指定します。管理者の作成ページが次のように表示されます。
ユーザー123456は、そのユーザーがLDAPサーバーに123456として存在するため、そのIDとしてログインしますが、名前「johndoe」がユーザー名としてEnterprise Managerコンソールに表示されます。
OMSプロパティoracle.sysman.core.security.auth.ldapuserattributes_emuserattributes_mappingsをこの環境で使用して、ユーザーの名前および外部IDを自動的に移入することもできます。EXTERNALUSERIDという追加フィールドに設定する必要があります。前述の例を使用して、次のようにOMSプロパティを設定します。
"USERNAME={%displayname%},EXTERNALUSERID={%uid%},EMAIL={%mail%},CONTACT="{%telephone%},DEPARTMENT={%department%},DESCRIPTION={%description%},LOCATION={%postalcode%}"
前述の機能は、EM CLIでも使用できます。OMSプロパティが設定された状態でEM CLI create_user動詞を使用して、LDAP属性が自動的に移入されるユーザーを作成できます。
現在、Oracle Enterprise Managerは、Oracle Internet Directory、Oracle Access Manager、Active Directoryおよびシングル・サインオンのネイティブ・サポートを提供しています。ネイティブ・サポートでは、EMCTLコマンドを使用してWebLogic ServerおよびEnterprise Managerを外部認証用に構成できます。Oracle Internet DirectoryでのEnterpriseの構成の詳細は「Oracle Internet Directory (OID)」を、Oracle Access Managerでの構成の詳細は「Oracle Access Managerシングル・サインオン・ベースの認証」を、Active Directoryでの構成の詳細は「Microsoft Active Directoryベースの認証」を参照してください。Oracle 『Fusion Middleware Oracle WebLogic Serverの保護11gリリース1』ドキュメントの「認証プロバイダの構成」の章を参照してください。
LDAPプロバイダはSUFFICIENTとマークされ、プロバイダのリストにおいてEnterprise Managerリポジトリ・オーセンティケータよりも前にある必要があります。
SSOプロバイダについては、特定のSSOプロバイダ構成の要件を参照してください。Enterprise Managerを機能させるには、適切な認証プロバイダを構成することに加えて、特定のOMSプロパティを設定する必要もあります。
他のLDAPサーバーのタイプを使用してEnterprise Managerを構成するには、次のOMSプロパティを設定する必要があります。これらのプロパティは、emctlまたはコンソールを使用して設定できます。プロパティは、各OMSに対して設定する必要があります。
emctl set property -name "oracle.sysman.core.security.auth.is_external_authentication_enabled" -value "true"
oracle.sysman.core.security.auth.is_external_authentication_enabled=true
oracle.sysman.emSDK.sec.DirectoryAuthenticationTypeはLDAP。
他のSSOソリューションのタイプを使用してEnterprise Managerを構成するには、weblogic認証またはアイデンティティ・アサーション・プロバイダの構成に加え、次のOMSプロパティを設定する必要があります。
oracle.sysman.core.security.auth.is_external_authentication_enabled=true
oracle.sysman.core.security.sso.type=OTHERSSO
oracle.sysman.core.security.sso.logout_url=<SSOサーバーでのログアウト構成用に提供された任意の値>
oracle.sysman.emSDK.sec.DirectoryAuthenticationType=SSO
この項の内容は、次のとおりです。
Oracle Access Managerシングル・サインオン認証スキームを使用する場合、ベースとなるアイデンティティ・ストアは、Oracle Access Managerでサポートされているエンタープライズ・ディレクトリ・アイデンティティ・ストアで構成されます。この項では、OAM SSOベースの認証スキームを構成する手順を示します。
前提条件
Oracle Access Managerがインストールされています。
Oracle Access Managerシングル・サインオン・サーバーは、Oracle HTTP Server、Web GateおよびOracle Access Managerアイデンティティ・ストアを使用するよう構成されています。
emctl config authコマンドを実行します。
emctl config auth oam [-sysman_pwd <pwd>] -oid_host <host> -oid_port <port> -oid_principal <principal> [-oid_credential <credential>] -user_base_dn <dn> -group_base_dn <dn> -oam_host <host< -oam_port <port> [-logout_url <url>] [-is_oam10g] [-user_dn <dn>] [-group_dn <dn>]
注意: OAMのバージョンが10gの場合にのみ、-is_oam10gオプションを使用します。
各OMSを停止します。
emctl stop oms-all
各OMSを再起動します。
emctl start oms
現在Oracle Application Server Single Sign-Onを使用してエンタープライズのアクセスと認可を制御している場合、これらの機能をEnterprise Managerコンソールに拡張できます。
デフォルトでは、Enterprise Managerにはメインのログオン・ページが表示されます。ただし、Oracle Application Server Single Sign-Onを使用してEnterprise Managerのユーザーを認証するようにEnterprise Managerを構成できます。ユーザーには、Enterprise Managerのログオン・ページではなく、Oracle Application Server Single Sign-Onの標準のログオン・ページが表示されます。管理者は、このログオン・ページで各自のOracle Application Server Single Sign-On資格証明を使用してOracle Enterprise Manager 12c Cloud Controlコンソールにアクセスできます。
|
注意:
|
パートナー・アプリケーションは、OracleAS Single Sign-Onサーバーに認証を委任するように設計されたアプリケーションです。次の項では、Enterprise ManagerをOracleAS Single Sign-Onパートナ・アプリケーションとして構成する方法について説明します。
Enterprise Managerをパートナ・アプリケーションとして手動で登録するには、次の手順を実行します。
各OMSでemctl stop omsを実行し、すべてのOMSを停止します。
次のURLを入力してSSO管理ページにナビゲートします。
https://sso_host:sso_port/pls/orasso
orcladminユーザーとしてログインし、「SSOサーバー管理」をクリックします。
「パートナ・アプリケーション管理」をクリックして「パートナ・アプリケーションの追加」をクリックします。
「パートナ・アプリケーションの追加」ページで次の情報を入力します。
Name: <EMPartnerName> Home URL: protocol://em_host:em_port Success URL: protocol://em_host:em_port/osso_login_success Logout URL: protocol://em_host:em_port/osso_logout_success Administrator Email: user@host.com
注意1: host、portおよびprotocolは、使用されるEnterprise Managerのホスト、ポートおよびプロトコル(httpまたはhttps)のことです。
注意2: em_host、em_port、emailおよびEnterprise Managerパートナ名は適切な値に置き換える必要があります。この例のとおりに入力しないでください。
パートナ・アプリケーション管理ページに戻り、<EMPartnerName>の「編集」アイコンをクリックします。
「ID」、「トークン」、「暗号化鍵」、「ログインURL」、「シングル・サインオフURL」、「ホームURL」の値を記録し、ファイルosso.txtに次の内容を含めます。
sso_server_version= v1.2 cipher_key=<value of EncryptionKey> site_id=<value of ID> site_token=<value of Token> login_url=<value of Login URL> logout_url=<value of Single Sign-Off URL> cancel_url=<value of Home URL> sso_timeout_cookie_name=SSO_ID_TIMEOUT sso_timeout_cookie_key=9E231B3C1A3A808A
ORACLE_HOME環境変数をWebTier Oracleホームの場所に設定します。
setenv ORACLE_HOME /scratch/12c/MWHome/Oracle_WT
次のように実行します。
$ORACLE_HOME/ohs/bin/iasobf <location of osso.txt> <location of osso.conf>
OMSごとに次のコマンドを実行します。
emctl config auth sso -ossoconf <osso.conf file loc> -dasurl <DAS URL> [-unsecure] [-sysman_pwd <pwd>] [-domain <domain>]-ldap_host <ldap host> -ldap_port <ldap port> -ldap_principal <ldap principal> [-ldap_credential <ldap credential>] -user_base_dn <user base DN> -group_base_dn <group base DN> [-logout_url <sso logout url>]
ldap_host、ldap_port、ldap_principalおよびldap_credentialは、SSOのLDAPの詳細です。
このコマンドの出力例を次に示します。
Oracle Enterprise Manager Cloud Control 12c Release 12.1.0.3.0 Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. SSO Configuration done successfully. Please restart Admin & Managed Servers.
OMSごとに次のコマンドを実行します。
emctl stop oms -all emctl start oms
シングル・サインオン構成を削除するには、次のようにします。
OMSごとに次のコマンドを実行します。
emctl config auth repos [-sysman_pwd <pwd>]
コマンドの出力例:
Oracle Enterprise Manager Cloud Control 12c Release 12.1.0.3.0 Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. Configuring Repos Authentication ... Started Configuring Repos Authentication ... Successful
httpd.conf (WebGateのインストール時)などのファイルを更新した場合、またはその他の必要なファイルは、この手順中のロールバックのために、事前にバックアップする必要があります。複数OMS環境を使用している場合、残りのサーバーで、emctl config auth reposを実行する必要があります。
各OMSで次のコマンドを発行し、すべてのOMSを再起動します。
emctl stop oms -all emctl start oms
シングル・サインオン・ログオン・ページを使用するようにEnterprise Managerを構成すると、シングル・サインオン・ユーザーをEnterprise Manager管理者として登録できます。シングル・サインオン・ユーザーを登録するには、次のインタフェースを使用します。
Enterprise Managerグラフィカル・ユーザー・インタフェース
Enterprise Managerコマンドライン・インタフェース
グラフィカル・ユーザー・インタフェースを使用してシングル・サインオン・ユーザーを登録するには、次の手順を実行します。
Enterprise ManagerコンソールのURLに移動します。
ブラウザはシングル・サインオンの標準ログオン・ページにリダイレクトされます。
有効なシングル・サインオン・ユーザーの資格証明を入力します。注意: このステップでは、SSOユーザーがEnterprise Managerに登録済である必要があります。
SSOユーザーがEnterprise Managerユーザーとしてまだ登録されていない場合、次の手順を使用して作成できます。
1. OMSに直接接続し、Enterprise Managerに移動します。たとえば、https://oms_host:oms_https_port/emです。
2. リポジトリ・ユーザーとしてログインします。
3. 「設定」メニューから、「セキュリティ」、「管理者」の順に選択します。
4. SSOユーザーを作成します。
スーパー管理者としてEnterprise Managerにログインします。
「設定」メニューから、「セキュリティ」、「管理者」の順に選択し、管理者ページを表示します。
Enterprise Managerはシングル・サインオンを使用するように構成されているため、管理者の作成ウィザードの最初のページには、管理者を外部ユーザーとリポジトリ・ユーザーのいずれで作成するかのオプションが表示されます。
「外部ユーザーのアイデンティティ・ストア」を選択し、ウィザードの次のページに進みます。
外部ユーザー・アイデンティティ・ストア・ユーザーの名前と電子メール・アドレスを入力するか、懐中電灯アイコンをクリックしてOracle Internet Directoryでユーザー名を検索します。
ウィザードの残りのページを使用してEnterprise Manager管理者のロール、システム権限、その他の特徴を定義してから「終了」をクリックします。
Enterprise Managerには、管理者アカウントの特徴をリストする概要ページが表示されます。
「終了」をクリックして、新しいEnterprise Manager管理者を作成します。
これで、外部ユーザー・アイデンティティ・ストア・ユーザーがEnterprise Manager管理者のリストに含まれます。Cloud Controlコンソールからログアウトし、シングル・サインオン・ログオン・ページで外部ユーザー・アイデンティティ・ストア・ユーザーの資格証明を使用してログインしなおすことで、アカウントを検証できます。
次のEM CLIコマンドを使用してシングル・サインオン・ユーザーを作成できます。
emcli create_user -name=ssouser -type=EXTERNAL_USER
このコマンドは、ssouserという名前でユーザーを作成します。このユーザーは、シングル・サインオン・ユーザーと照らし合せて認証されます。
| 引数 | 説明 |
|---|---|
| -name | 管理者の名前。 |
| -type | ユーザーのタイプ。このパラメータのデフォルト値はEM_USERです。その他に次の値が可能です。
|
| -password | 新規に作成した管理者のパスワード。 |
| -roles | 該当の管理者に付与できるロールのリスト。 |
| 該当の管理者の電子メール・アドレスのリスト。 | |
| -privilege | 管理者に付与できるシステム権限。このオプションは、複数回指定できます。 |
| -profile | データベース・プロファイルの名前。これはオプションのパラメータです。使用されるデフォルトのプロファイルはDEFAULTです。 |
| -desc | 追加するユーザーの説明です。 |
| -expired | このパラメータは、パスワードを「期限切れ」ステータスに設定する場合に使用されます。これはオプションのパラメータであり、デフォルトではFalseに設定されます。 |
| -prevent_change_password | このパラメータをTrueに設定すると、ユーザーはパスワードを変更できません。これはオプションのパラメータであり、デフォルトではFalseに設定されます。 |
| -input_file | このパラメータにより、管理者は、入力ファイルにこれらの引数の値を提供できます。値の形式はname_of_argument:file_path_with_file_nameになります。 |
例1
emcli create_user
-name="new_admin"
-email="first.last@mycompany.com;joe.shmoe@shmoeshop.com"
-roles="public"
-privilege="view_job;923470234ABCDFE23018494753091111"
-privilege="view_target;<host>.com:host"
この例では、new_adminというEnterprise Manager管理者を作成します。この管理者には、ID 923470234ABCDFE23018494753091111のジョブを表示する機能と、ターゲット<host>.com:hostを表示する機能の2つの権限があります。管理者new_adminにはPUBLICロールが付与されます。
例2
emcli create_user
-name="User1"
-type="EXTERNAL_USER"
-input_file="privilege:/home/user1/priv_file"
Contents of priv_file are:
view_target;<host>.com:host
この例では、Enterprise Managerユーザーとして外部で作成されたuser1を作成します。user1には、<host>.com:hostに対する表示権限があります。
例3
emcli create_user
-name="User1"
-desc="This is temp hire."
-prevent_change_password="true"
-profile="MGMT_ADMIN_USER_PROFILE"
この例では、user1をEnterprise Managerユーザーとして、説明付きで設定します。prevent_change_passwordは、user1によってパスワードを変更できないようにtrueに設定され、profileはMGMT_ADMIN_USER_PROFILEに設定されます。
例4
emcli create_user
-name="User1"
-desc="This is temp hire."
-expire="true"
この例では、user1をEnterprise Managerとして、説明付きで設定します。パスワードの有効期限はすぐに切れるように設定されるため、ユーザーが初めてログインすると、パスワードの変更が求められます。
OMSがSSO、OAMまたはその他の認証方法を使用するよう構成されている場合、シングル・サインオンまたはOAM認証を省略する必要がある場合があります。SSOログオン・ページを省略するには、次のURLに接続します。
https://ms_host:ms_https_port/emに接続します。
ms_hostとms_https_portは、WLS管理対象サーバーのホスト名とポート番号です。これらのパラメータは、EM_INSTANCE_HOME/emgc.propertiesファイルに含まれています。このファイルでは、EM_INSTANCE_HOSTとMS_HTTPS_PORTとリストされています。
リポジトリ・ユーザーの資格証明を使用してログインします。
OMSごとに次のコマンドを実行します。
emctl config auth repos [-sysman_pwd <pwd>]
コマンドの出力例:
Oracle Enterprise Manager Cloud Control 12c Release 12.1.0.3.0 Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. Configuring Repos Authentication ... Started Configuring Repos Authentication ... Successful If you have updated files like httpd.conf (for example, while installing WebGate), rollback them. If this is a multi-OMS environment, execute this command on remaining servers. After that, restart OMS(s) using: 'emctl stop oms -all' and 'emctl start oms'
OMSごとに次のコマンドを実行します。
emctl stop oms -all emctl start oms
エンタープライズ・ユーザー・セキュリティで使用するためにEnterprise Managerを構成する手順は、「エンタープライズ・ユーザー・セキュリティベースの認証の構成」を参照してください。
次の項では、Enterprise Managerで使用されるデフォルトの認証方法を復元する手順について説明します。
OMSがSSO、OAMまたはその他の認証方法を使用するよう構成されている場合、シングル・サインオンまたはOAM認証を省略する必要がある場合があります。SSOログオン・ページを省略するには、次のURLに接続します。
https://ms_host:ms_https_port/emに接続します。
ms_hostとms_https_portは、WLS管理対象サーバーのホスト名とポート番号です。これらのパラメータは、EM_INSTANCE_HOME/emgc.propertiesファイルに含まれています。このファイルでは、EM_INSTANCE_HOSTとMS_HTTPS_PORTとリストされています。
リポジトリ・ユーザーの資格証明を使用してログインします。
OMSごとに次のコマンドを実行します。
emctl config auth repos [-sysman_pwd <pwd>]
コマンドの出力例:
Oracle Enterprise Manager Cloud Control 12c Release 12.1.0.3.0 Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. Configuring Repos Authentication ... Started Configuring Repos Authentication ... Successful If you have updated files like httpd.conf (for example, while installing WebGate), rollback them. If this is a multi-OMS environment, execute this command on remaining servers. After that, restart OMS(s) using: 'emctl stop oms -all' and 'emctl start oms'
OMSごとに次のコマンドを実行します。
emctl stop oms -all emctl start oms
すべてのターゲットに対して同じレベルのアクセス権をすべての管理者に付与することは危険です。また、グループのすべての新規メンバーに数十、数百、場合によっては数千ものターゲットに対するアクセス権を個別に付与するのは時間のかかる作業です。Enterprise Managerの管理者権限およびロール機能を使用すると、これらのタスクを合理化でき、企業の成長とともに容易にスケール変更できるようになります。認可により、システム、ターゲットおよびオブジェクト・レベルの権限およびロールを介してEnterprise Managerによって管理されるセキュアなリソースへのアクセスを制御します。この項では、ユーザー・クラスごとに割り当てられるロールと権限などのEnterprise Managerの認可モデルについて説明します。
|
注意: 権限または割り当てられたターゲットのない管理者は、Enterprise Manager内から監視ターゲットを参照できません。割り当てられたロールまたは権限のない新しい管理者としてEnterprise Managerにログインすると、EXEMPT ACCESS POLICY権限がEnterprise Managerスーパー管理者SYSMANに対して取り消されないかぎり、すべてのターゲットが表示されます(セキュリティ上の問題)。システム権限EXEMPT ACCESS POLICYを持つユーザーは、すべてのSELECTまたはDML操作(INSERT、UPDATEおよびDELETE)において、ファイングレイン・アクセス・コントロール・ポリシーの対象から除外されます。これによって、インストールや、SYS以外のスキーマを介したデータベースのインポートとエクスポートなどの管理アクティビティが使いやすくなります。 また、使用されているユーティリティまたはアプリケーションにかかわらず、ユーザーにEXEMPT ACCESS POLICY権限が付与されている場合、ユーザーはVPDおよびOracle Label Securityポリシーの実施が免除されます。つまり、ユーザーはデータ・アクセスに適用されるVPDまたはOracle Label Securityポリシーを持ちません。 この問題を解決するには: SYSまたはSYSTEMユーザーとしてEnterprise Managerリポジトリ・データベースに接続し、次のSQL文を実行します。
|
Enterprise Manager管理者がユーザーをシステムに追加する場合、主要な考慮事項は、このユーザーが仕事を行うために実行する必要がある内容です。この新規ユーザーのジョブが定義され認識された後、適切な権限がこのユーザーに割り当てられる必要があり、ジョブを完了するために必要なシステムへのアクセス権が付与される必要があります。
権限は最終的には、管理者がEnterprise Managerでターゲットを管理できるように管理者に付与されます。特定の権限を個々の管理者に付与できますが、多くの管理者にわたり多くのターゲットに対する権限を追跡および付与するとエラーが起こりやすく、それ自体が管理上の負荷となってしまいます。そのためロールを定義して使用し、管理者への権限の付与を管理することをお薦めします。
ロールは通常、複数のユーザーからなるチームに対して付与する権限のセットを含む、ユーザー定義の権限セットです。ロールには、他のロールも含めることができます。たとえば、管理者がターゲットでのインシデントを確認および管理するために必要な権限を含むFirst Line Supportロールを作成できます。このロールを作成すると、これらのインシデントを自分の職責の一部として管理することになる適切な管理者に、このロールを付与できるようになります。管理者用の権限のセットを変更する(新しい権限の追加や権限の削除など)必要がある場合には、ロールを更新するだけですみます。ロール内の更新された権限のセットは、ロールを付与された管理者に対して自動的に有効になります。同様に、新規の管理者が追加された場合、その管理者に対して個々の権限を付与するのではなく、適切なロールを付与するだけですみます。詳細は、「ユーザーのクラス」を参照してください。
ロールを使用すると、一歩大きく進んだ権限の管理が可能になります。とはいえ、新しいターゲットがEnterprise Managerに追加されるたびに、それらの権限を備えたロールを更新し続けなければならない課題があります。
Oracle Enterprise Managerでは、管理している環境や、Oracle Enterprise Managerを使用しているコンテキストに応じて、Oracleユーザーの様々なクラスをサポートしています。
Enterprise Managerコンソールで作成および管理されるEnterprise Manager管理者には、Enterprise Managerコンソールにログインして特定のターゲット・タイプを管理したり、特定の管理タスクを行うための権限とロールが付与されます。Enterprise Managerコンソールのデフォルト・スーパー管理者はSYSMANユーザーで、これは、Oracle Management Repositoryに関連付けられているデータベース・ユーザーです。SYSMANアカウントのパスワードは、Enterprise Managerのイントール手順の間に定義します。
Oracle Enterprise Manager 12cコンポーネント間の通信を保護するために、権限を持つユーザーのアクセスを制限したり、ツールを提供したりすることで、Enterprise ManagerはOracle Management Repositoryの重要情報を保護します。
管理リポジトリには、エンタープライズ全体のパフォーマンスや可用性の監視に役立つようにEnterprise Managerで使用される管理データが含まれています。このデータによって、デプロイしたハードウェアとソフトウェアのタイプに関する情報や、管理するアプリケーション、データベース、アプリケーション・サーバー、その他のターゲットの履歴パフォーマンスや固有の特徴が提供されます。また、管理リポジトリには、管理データへのアクセス権限を持つEnterprise Manager管理者に関する情報もあります。
Enterprise Manager管理者アカウントを作成および管理できます。管理者アカウントには、それぞれ独自のログイン資格証明や、アカウントに割り当てられた一連のロールおよび権限が含まれています。次の3つのユーザーのクラスがあります。
スーパー管理者: スーパー管理者はスーパー管理者権限を持つユーザーです。この権限を持つユーザーは、ユーザーまたはロールを作成、編集および削除できる強力なユーザーです。スーパー管理者はシステムのすべてのリソースを管理できますが、次の制限があります。
- 他のユーザーが作成した名前付き資格証明へのアクセス権がない。 - 他のユーザーが作成したジョブ、デプロイメント・プロシージャを管理できない。
Enterprise Managerがインストールされると、スーパー管理者であるSYSMANがデフォルトで作成されます。スーパー管理者は、他の管理者アカウントを作成できます。
管理者が実行できる管理タスクおよびアクセスできるターゲットは、その管理者に付与されているロール、システム権限、リソース権限およびターゲット権限に依存します。スーパー管理者は他の管理者に対して、特定の管理タスクのみの実行、特定のターゲットのみへのアクセス、または特定のターゲットに対する特定の管理タスクの実行を許可するよう選択できます。このようにスーパー管理者は、管理者がジョブを行うために必要な最小レベルの権限を割り当てることができます。
集計ターゲット権限は、1つ以上のメンバー・ターゲットを持つターゲットです(たとえば、グループ、システム、Real Application Clusterなど)。集計ターゲット権限を使用すると、管理者は異なるレベルの権限をメンバー・ターゲットおよび集計ターゲットに付与できます。たとえば、管理者は、集計グーループ・レベルに対してはVIEW権限を付与し、グループ内の各メンバー・ターゲットに対してはFULL権限を付与する場合があります。管理者が集計とそのメンバーに対して特定の権限を付与しない場合、デフォルトは集計とそのメンバーに対する権限と同じになります。
たとえば、VIEW権限をグループ(集計レベル)で付与し、メンバー・ターゲット・レベルでFULLを付与できます。これにより、ターゲットの削除などの全ライフサイクル・タスクを実行するように、DBAはメンバー・ターゲットに対してFULLを付与できます。DBAは、グループを削除しないように、グループに対してはVIEW権限を持っています。
Enterprise Manager管理者を作成または編集する場合、これらの権限設定を表示または変更できます。「設定」メニューから、「セキュリティ」、「管理者」の順に選択します。ターゲット権限ページに移動します。
「ターゲット権限」ページの下部で、「ターゲット権限」リージョンを確認します。
「詳細な権限設定」オプションをチェックして、ユーザーに追加された集計ターゲット・タイプの設定を表示します。
追加の列が2つ表示されます。
集計専用の権限付与の管理
メンバー専用の権限付与の管理
編集(鉛筆)アイコンをクリックして、権限付与プロパティを変更します。
ユーザー固有の権限の付与は、Enterprise Managerの基本レベルのセキュリティを提供します。ユーザー権限は、データへのアクセスを制御し、監視設定の変更やターゲットのパッチ適用などのEnterprise Managerで実行できる管理操作を制限するように設計されています。
Enterprise Managerのインストール時、SYSMANユーザー(スーパー管理者)がデフォルトで作成されます。SYSMANスーパー管理者は、日常的な管理作業用に別の管理者アカウントを作成します。SYSMANアカウントは、頻度の低いシステム全体のグローバル構成タスクにのみ使用する必要があります。
スーパー管理者は、管理者がEnterprise Manager内でタスクを実行するために必要な最小レベルの権限を割り当てることができます。たとえば、スーパー管理者は、一部の管理者にはエンタープライズ内の全ターゲットの表示および追加を許可し、他の管理者には担当するターゲットのメンテナンスやクローニングなど、特定の操作の実行のみを許可できます。
データベースに対するDBA権限を持つと、ユーザーは、別のデータベース・ユーザーの削除、表の削除およびその他の管理操作の実行が許可されます。したがって、リポジトリ・データベースに対するDBA権限を持つと、管理者は、Enterprise Managerスーパー管理者として実行できるすべての操作を行うことができるようになります。管理者は暗黙的にスーパー管理者として扱われます。これは、DBA権限を持つOSユーザーがOracleサーバーに接続でき、SYSDBA権限を行使できるデータベースによってサポートされているOS認証と似ています。
このレベルのアクセス権では意図した動作を得られない場合は、次のいずれかを使用することをお薦めします。
Enterprise Managerリポジトリ・データベースは特別なデータベースとして考慮する必要があります。Enterprise Managerのスーパー管理者権限を持つユーザー以外に、データベースでは、いかなるユーザーに対してもDBA権限を付与しないでください。
外部認証を設定し、Enterprise ManagerユーザーをActive DirectoryまたはLDAPに統合してください。これにより、作成されるEnterprise Managerアプリケーション・ユーザーのシャドウ・データベース・ユーザーが確実にいなくなるので、DBA権限はEnterprise Managerユーザーに付与できなくなります。
|
ベスト・プラクティス: Enterprise Manager管理者にはDBA権限を付与しないでください。Enterprise Managerスーパー管理者がDBA権限を持っている状況では、DBA権限が削除されるまで、SYSMANはそのユーザーを通常の管理者(スーパー管理者でない)に変換できません。 |
権限は、Enterprise Manager内で管理アクションを実行する権利です。権限は、2つのカテゴリに分けることができます。
ターゲット権限
リソース権限
ターゲット権限: 管理者は、この権限を使用してターゲットに対する操作を実行できます。そのため、ターゲット権限を次のレベルに分類する定義済の権限階層があります。
オペレータ: 特定の管理アクションを許可する中間レベル。オペレータ権限は、他の権限を含むことができる権限の例でもあります。たとえば、オペレータ権限にはブラックアウト権限が含まれ、オペレータターゲット権限を付与されたユーザーには自動的にブラックアウト・ターゲット権限が付与されます。詳細は、表B-2「特定のターゲットに適用可能なターゲット権限」を参照してください。
2種類のターゲット権限があります。
すべてのターゲットに適用可能な権限。これらの権限では、管理者はEnterprise Managerインフラストラクチャを使用して、すべてのコンポーネントに対する操作を実行できます。
特定のターゲット・インスタンスに適用できる権限。これらの権限では、管理者はEnterprise Managerインフラストラクチャ内の特定のターゲットに対する操作を実行できます。
「ターゲット権限」ページには、すべてのターゲットに付与されている権限のリストが表示されます。ターゲット権限の詳細なリストは、付録B「権限」を参照してください。
リソース権限: 管理者は、この権限を使用してEnterprise Manager内の特定の機能へアクセスできます。リソース権限の例には、「バックアップ構成」、「クラウド・ポリシー」、「コンプライアンス・フレームワーク」、Enterprise Managerプラグイン、「ジョブ・システム」、「パッチ計画」、「自己更新」および「テンプレート・コレクション」があります。完全なリストは、『Oracle Enterprise Manager Cloud Controlセキュリティ・ガイド』の権限とロールの項を参照してください。
たとえば、管理者に名前付き資格証明の新規作成の権限を付与する手順は、次のとおりです。
「設定」メニューから、「セキュリティ」、「管理者」の順に選択します。「管理者」ページが表示されます。
既存の管理者を編集するか新しい管理者を作成して、「管理者」ウィザードへアクセスします。
「リソース権限」ページに進みます。
「リソース・タイプ」列で、「名前付き資格証明」までスクロールします。
「権限付与の管理」列で、該当の鉛筆アイコンをクリックします。「リソース・タイプ権限」ページが表示されます。
「名前付き資格証明の新規作成」の権限を選択し、「続行」をクリックして管理者の作成および編集プロセスへ進みます。
Enterprise Managerはターゲットおよび他のリソースへのアクセスを制御する詳細な権限を実装し、管理者は職務を有効に分割できます。たとえば、プロビジョニングの設計担当者と運用担当者の職責について検討してみましょう。前者(ソフトウェア・ライブラリのコンポーネントの作成)は後者(デプロイメントの発行)よりも多くの職責を担っています。セキュリティ・コンソールからは、次を表示できます。
スーパー管理者のリスト
最も多くのDirect権限を持つ管理者
ターゲット権限
リソース権限
最も多くのロールを持つ上位5人の管理者
ネストされたロールを最も多く持つロール
ロールとは、管理者や他のロールに付与できるEnterprise Managerのリソース権限またはターゲット権限、あるいはその両方の集合です。これらのロールは、地理的位置(カナダのシステムを管理するためのカナダの管理者用ロールなど)、業務系列(人事管理システムや販売システムの管理者用ロールなど)または他のモデルに基づいて作成できます。管理者は、何千ものターゲットへのアクセス権をグループの各新規メンバーに個々に付与するタスクは行いたくありません。ロールを作成すると、管理者は、様々な権限を付与する必要はなく、すべての適切な権限を含むロールをチームのメンバーに割り当てるだけですみます。ターゲット・アクセスまたは管理タスクへのアクセス、あるいはその両方をフィルタして、管理者間でワークロードを分割できます。Enterprise Managerを外部認証プロバイダとともに機能するように構成して、外部ロールを使用して認可も管理することもできます。詳細は、「外部ロールを使用した外部認可」を参照してください。
あらかじめ用意されているロール: Enterprise Manager Cloud Control 12cには、様々なリソースとターゲット・タイプを管理するためのロールがあらかじめ定義されて含まれています。次の表に、ロールの一部とその機能を示します。表示されるロールの数とタイプは、インストールしたプラグインの数とタイプによって異なります。あらかじめ用意されているロールの完全なリストは、付録A「ロール」を参照してください。
パブリック・ロール: Enterprise Managerでは、デフォルトでPublicというロールが1つ作成されます。このロールは、スーパー管理者以外の新規の管理者が作成されると、全員に自動的に割り当てられるという点でユニークです。デフォルトでは、このロールに割り当てられる権限はありません。パブリック・ロールは、作成する非スーパー管理者の大部分に割り当てるつもりのデフォルト権限を定義するために使用します。権限は、最初にパブリックに割り当てる必要はありません。いつでも追加できます。ロールは、企業で使用する必要がなくなれば、削除できます。削除しても、後から実装を決めた場合は、また元どおりに追加できます。
プライベート・ロールは、Enterprise Managerリリース12.1.0.4で導入された新しいロール・タイプであり、管理者またはロールに対する機密性の高い強力な権限の付与を制御するために使用されます。Enterprise Managerがスーパー管理者に対して使用を許可しない機密性の高い特定の権限があります。具体的には次のとおりです。
LAUNCH_DP
FULL_DP
GET_CREDENTIAL
EDIT_CREDENTIAL
FULL_CREDENTIAL
FULL_JOB
これらの権限は特に機密性が高く強力で、そのためEnterprise Managerではこれらの権限をロールに付与しません。これらの権限をロールに付与すると、別の管理者がそれらを使用できるようになります。
これらのタイプの権限の付与をよりセキュアな方法で行うために、ロールはシステム・ロールとプライベート・ロールの2つのカテゴリに分けられています。
プライベート・ロールは、「create_role」権限を持つ管理者によって管理されます。「create_role」権限(プライベート・ロール)が付与される管理者は、名前付き資格証明とジョブ・ロールのライフサイクルを保持し、管理者がこれらのフル・ジョブ権限および完全な資格証明権限を別の管理者とロールに付与することを許可します。
システム・ロールは、「manage_system_role」権限を持つすべての管理者へのアクセスが可能なすべてのロールを定義します。
プライベート・ロールは、Enterprise ManagerコンソールやEM CLIからemcli create_role動詞を使用して、別の管理者およびロールに付与でき、またemcli grant_privs動詞を使用して付与可能にすることができます。
例1:
emcli create_role
-name="my_private_role"
-type="EM_ROLE"
-desc="This is a new private role called my_private_role"
-roles="role1;role2;role3"
-privilege="full_job;923470234ABCDFE23018494753091111"
-privilege="FULL_CREDENTIAL;CRED_NAME=cred1:CRED_OWNER=user2"
-users="USER1;USER2:WITH_ADMIN"
-private_role[ Optional ]
これは、ログイン・ユーザーによって所有されるmy_private_roleを作成します。
USER1はWITHOUT_ADMINオプションとしてこのロールが付与され、USER2はWITH_ADMINオプションとしてこのロールが付与されます。
このロールは、各オブジェクトのFULL_JOBおよびFULL_CREDENTIAL権限で構成されます。
プライベート・ロールの所有者は、このロールを管理者に付与でき、別の管理者がさらに別の管理者(–WITH_ADMINオプションを使用して)またはプライベート・ロールに、このプライベート・ロールを付与する権限を持つかどうかを指定できます。実質的に、このロールの所有者は、プライベート・ロールという名前ゆえに、このロールへのアクセスを個別に管理しています。システム・ロールはプライベート・ロールに対して付与できますが、プライベート・ロールはシステム・ロールに対して付与できません。
-WITH_ADMINオプションがサポートされる動詞:
create_role -users
modify_role -users
create_user -roles
modify_user -roles
grant_roles -roles
権限は最終的には、管理者がEnterprise Managerでターゲットを管理できるように管理者に付与されます。特定の権限を個々の管理者に付与できますが、多くの管理者にわたり多くのターゲットに対する権限を追跡および付与するとエラーが起こりやすく、それ自体が管理上の負荷となってしまいます。そのためロールを定義して使用し、管理者への権限の付与を管理することをお薦めします。ロールは通常、複数のユーザーからなるチームに対して付与する権限のセットを含む、ユーザー定義の権限セットです。ロールには、他のロールも含めることができます。たとえば、管理者がターゲットでのインシデントを確認および管理するために必要な権限を含むFirst Line Supportロールを作成できます。このロールを作成すると、これらのインシデントを自分の職責の一部として管理することになる適切な管理者に、このロールを付与できるようになります。管理者用の権限のセットを変更する(新しい権限の追加や権限の削除など)必要がある場合には、ロールを更新するだけですみます。ロール内の更新された権限のセットは、ロールを付与された管理者に対して自動的に有効になります。同様に、新規の管理者が追加された場合、その管理者に対して個々の権限を付与するのではなく、適切なロールを付与するだけですみます。
ロールを使用すると、一歩大きく進んだ権限の管理が可能になります。とはいえ、新しいターゲットがEnterprise Managerに追加されるたびに、それらの権限を備えたロールを更新し続けなければならない課題があります。以降で説明する権限伝播グループは、これらの課題に対処することを目的としています。
何百または何千ものターゲットにわたる可能性のある権限を大規模な管理者のセットに付与するよう管理するには、ロールと併用して権限伝播グループを使用します。グループとはユーザー定義のターゲットの集まりで、ターゲットを1つの単位としてまとめて管理および監視するために作成できます。権限伝播グループは特殊なタイプのグループです。このグループで1人のユーザーに1つの権限を付与すると、自動的にそのグループのすべての既存および新規のメンバーに同じ権限が付与されます。
Enterprise Managerの管理グループは、本質的に権限伝播となっています。つまり、ユーザーまたはロールに付与された管理グループに対する権限は、サブグループを含むグループのすべてのメンバーに自動的に伝播します。管理グループに新しいターゲットが追加された場合、管理グループは権限伝播であるため、これによりこの管理グループに対する権限を持つユーザーまたはロールは、新しく追加されたこのグループに参加するターゲットに対する権限を自動的に得ます。新しいターゲットに対する権限を付与するための追加作業は不要です。そのため、グループに対する権限をロールに付与する1回の設定のみでよいので、権限の付与が極めて容易になります。
異なるジョブ職責に対するロールの作成
様々なジョブ職責を計画し、これらをEnterprise Managerの対応する権限にマップした後の次のステップでは、各ジョブ職責に必要な権限を含むロールをEnterprise Managerで作成します。次の例では、各ジョブ職責に対して作成する必要のある様々なロールを示しています。管理グループのターゲットに対する権限については、管理グループの権限伝播の特性を活用するために、個別のターゲットではなく管理グループに対して権限を付与することをお薦めします。
表 2-1 様々なジョブ職責に対して作成できるロールの例*
| ジョブ職責 | Enterprise Managerでのロール | ロールでの権限(最小セット) |
|---|---|---|
|
グループ管理者 グループ・メンバーシップを定義し、グループに対する権限を他の管理者に付与をします。 |
GROUP_ADMIN_ROLE |
グループに対するグループ管理 |
|
シニア管理者 Enterprise Managerでのターゲットの追加と削除、ターゲットに対する監視設定の計画と設定を行います。また、イベントのインシデントの作成に関するルールの設定および通知の送信を行います。 |
SENIOR_ADMIN_ROLE |
任意のターゲットの追加 エンタープライズ・ルール・セットの作成 グループのオペレータ ジョブ・システムでの作成 EM_TC_DESIGNERロール |
|
ターゲット所有者 所有するターゲットに対して、監視設定の設定、イベントまたはインシデントに対する応答、メンテナンス操作の実行を行います。 |
TARGET_OWNER_ROLE |
管理している管理グループのオペレータ ジョブ・システムでの作成 任意の監視テンプレートの表示 管理しているグループに関連付けられたテンプレート・コレクションの表示 |
|
第1レベルのサポート ターゲットでのイベントまたはインシデントに対する応答を行います。操作手順の一部として、ダウンしているターゲットのブラックアウトができます。 |
FIRST_LEVEL_SUPPORT |
適切な管理グループでターゲット・イベントを管理 適切な管理グループでターゲットをブラックアウト |
表に一覧した権限は、ロールでの権限の最小セットを示しています。他の職責に基づいてさらに権限を追加できます。また、ロールの作成にはスーパー管理者権限が必要です。ロールが定義されると、これらのロールをEnterprise Managerの管理者に付与できるようになります。これを行うには、いくつかの方法があります。
Enterprise Manager管理者の作成または編集時にロールを割り当てます。
ロールの作成または編集の一部として、ロールを付与する管理者を選択します。
Enterprise Managerコマンドライン・ツール(EM CLI)を使用して管理者を作成または編集する際に、ユーザーに付与されるロールを指定できます。また、EM CLIを使用して既存のユーザーに直接ロールを付与できます。
たとえば、開発チームで使用するホスト・ターゲットに対するオペレータ権限を開発チームのすべてのメンバーに付与する場合を考えます。最初に、関連するホスト・ターゲットを含む権限伝播グループ(Devt-Group)を作成できます。次に、ロール(Devt-Role)を作成し、このロールにDevt-Groupでのオペレータ権限を含めます。最後に、Devt-Roleを開発チームのすべてのメンバーに付与します。これによって、開発チームのすべてのメンバーに、Devt-Groupでのすべてのターゲットに対するオペレータ権限が付与されます。新規のホスト・ターゲットが追加されるとき、これらの新規ターゲットをDevt-Groupに追加するだけで、開発チームのすべてのメンバーは自動的に新規に追加されたターゲットに対するオペレータ権限を取得できます。次のシナリオでは、権限伝播グループをロールとともに使用する他の例を示します。
ここでは、権限伝播グループを使用するベストなタイミングと、ターゲット・グループを作成し、このグループにメンバーを追加し、これらのターゲット・グループにロールと管理者を割り当てる方法をまとめた2つのユースケースを紹介します。
ある組織内のデータベース・インスタンスおよびWebLogic Serverのコレクションが、組織内の別々のチームで管理されていることを考えます。いずれのチームもEnterprise Managerを使用して自らのターゲットを管理しています。DBAは、データベース・インスタンスに対する完全なアクセス権限とWebLogic Serverの表示権限を必要とします。同様に、WebLogic Server管理者は、WebLogic Serverに対する完全な権限とデータベース・インスタンスに対する表示権限を必要とします。
2つのチームにまたがって権限を管理するには、まずそれぞれのチームのターゲットを含む2つの権限伝播グループを作成します。たとえば、データベース・インスタンスを含むDBAGroupというターゲット・グループと、Oracle WebLogic Serverを含むWLSGroupという別のターゲット・グループを作成できます。DBAGroupには、DBAが修正および管理できるデータベース・インスタンスが含まれます。これに対し、WLSGroupはWeb Logic Server管理者が修正および管理するWeb Logic Serverのグループです。さらに、DBAはWeb Logic Serverターゲットを表示することを必要とし、Web Logic Server技術者はデータベース・インスタンスを表示することを必要とします。次の手順では、これらのターゲット・グループ、権限およびロールの設定方法と、正しい管理者への適切なロールの付与方法を説明します。
この手順は次のとおりです。
ターゲット・グループを作成します。コンソールの「ターゲット」でドロップダウン・メニューから「グループ」を選択します。
メニューから「作成」をクリックし、ドロップダウン・メニューから「グループ」を選択します。
名前をDBAGroupと入力します。
チェック・ボックスを選択して「権限の伝播」を有効にします。これにより管理者は、グループに対する権限をユーザーに一度で付与でき、この権限は自動的にグループの各メンバーに伝播(適用)されます。
追加したいデータベース・ターゲットを新しいデータベース・グループDBAGroupに追加します。これは、リストからデータベース・インスタンス・ターゲットを選択して、「追加」ボタンを押すことで追加されます。「選択」ボタンをクリックします。
「OK」を選択します。
新しいグループDBAGroupが使用可能なグループのリストに表示されます。
ここで、手順1から6を繰り返して、WLSGroupとして、このグループに適切なWebLogice Serverターゲットを追加して、2つ目の権限伝播グループを作成します。
2つ目のグループ(WLSGroup)が、使用可能なグループのリストに表示されます。
次に、ロールを作成します。ロールには、管理者に付与できる権限が含まれます。「ロール」ページに進みます。「設定」→「セキュリティ」→「ロール」ページと進みます。
「作成」をクリックします。
「プロパティ」ページでロールの名前を入力します。この例ではDBA-ROLEという名前にしています。このロールにはDBAチームの権限が含められます。これには、DBAGroupのすべてのデータベース・インスタンスに対する「完全」権限と、WLSGroupのすべてのWebLogicサーバー・インスタンスに対する「表示」権限が含められます。「次へ」ボタンをクリックします。
ロール・ページで、「次へ」をクリックします。
「ターゲット権限」ページで、ページ下部の「ターゲット権限」セクションまでスクロール・ダウンします。「追加」ボタンをクリックします。使用可能なターゲットのリストが表示されます。検索結果を向上させるには、「グループ」ターゲット・タイプを選択します。今作成した2つのグループ、DBAGroupおよびWLSGroupを選択します。
2つのグループが表示されます。このロールDBA-ROLEには、DBAGroupのすべてのデータベースに対して「完全」を付与し、WLSGroupのすべてのWebLogicサーバー・ターゲットに対し「表示」を付与する必要があります。デフォルトの権限が「表示」であるため、このロールではWLSGroupをデフォルトの「表示」権限としたまま、DBAGroupの権限を変更するだけですみます。これは、「ターゲット権限付与の管理」列の「表示」の右側にある鉛筆アイコンを選択して行います。「続行」ボタンをクリックします。
「完全」の権限をクリックし、「続行」ボタンを選択します。
新しい権限が表示されます。「次へ」ボタンを選択します。
「リソース権限」ページで「次へ」を選択します。
このロールDBA-ROLEを付与する管理者を選択します。「次へ」ボタンを選択します。
新規のロールDBA-ROLEの設定を確認します。
次に2つ目のロールWLS-ROLEを作成します。このロールでは、WLSGroupのすべてのWebLogic Serverに対する完全な権限DBAGroupのすべてのデータベース・インスタンスに対する表示権限をユーザーに付与できます。2つ目のロールをWLS-ROLEという名前にして、手順10から19を繰り返します。次に示された確認ページに進みます。
通常データセンター内のDBAでは、基礎となるデータベースに対するアプリケーションの影響についての情報を直接表示できるように、アプリケーション開発者にデータベース・パフォーマンス・ページへの読取り専用アクセスを提供すること、およびデータベースでのすべての書込み操作からそれらを制限します。DBAは、開発者とデータベース・ユーザー・アカウント情報を共有したり、各データベース・インスタンスに対する個別のユーザー・アカウントを作成することを必要としない場合があります。
ターゲットに対して読取り専用アクセスを有効にするには、「読取り専用でのターゲットの接続」権限を使用できます。多くのデータベース間で開発者チームに対するこの権限の付与を管理するために、権限伝播グループを作成し、このターゲット・グループ(たとえば、DevGroupと呼びます)にデータベース・インスタンスを追加できます。たとえばDEV-ROLEというロールを作成し、このロールに対して権限「読取り専用でのターゲットの接続」を付与し、この作業の中でこのロールを各開発者に割り当て、データベース・インスタンスのパフォーマンス・データへのアクセス権を付与します。これらのエンジニアは各データベース・インスタンスに対する個々のユーザー・アカウントを持っていないため、データベース・ユーザー資格証明を含むDevCredという名前付き資格証明を作成し、この名前付き資格証明をデータベース・インスタンスのパフォーマンス・データにアクセスする必要のある各開発者に割り当てます。次の手順では、ターゲット・グループを設定し、このグループにロールおよび名前付き資格証明を割り当てる方法を説明します。
この手順は次のとおりです。
ターゲットのグループを作成します。コンソールの「ターゲット」でドロップダウン・メニューから「グループ」を選択します。
「作成」をクリックし、ドロップダウン・メニューから「グループ」を選択します。
新しいターゲット・グループの名前を入力します。このユーザー・ケースではDevGroupとします。
チェック・ボックスを選択して「権限の伝播」を有効にします。これにより管理者は、グループに対する権限を1人のユーザーに一度で付与でき、その権限を自動的にグループの各メンバーに伝播(適用)できます。追加するデータベース・ターゲットをこのグループに追加します。これは、「追加」ボタンを押して、リストから「ターゲット」を選択して行います。
「OK」を選択します。
新しいターゲット・グループDevGroupが使用可能なグループのリストに表示されます。
次に、ターゲットのDevGroupの表示専用ロールを作成します。ロールは管理者に付与される権限です。「ロール」ページに行き、「設定」→「セキュリティ」→「ロール」と進みます。
「作成」ボタンをクリックします。
「プロパティ」ページで新しいロール名、DEV-ROLEを入力し、「次へ」ボタンをクリックします。
「ロール」ページで「次へ」をクリックします。
「ターゲット権限」ページで、ページ下部の「ターゲット権限」セクションまでスクロール・ダウンします。「追加」ボタンをクリックします。使用可能なターゲットが表示されます。検索結果を向上させるには、「グループ」ターゲット・タイプを選択します。今作成したグループ、DevGroupを選択します。「選択」ボタンをクリックします。
ターゲット・グループが表示されます。このロールDEV-ROLEには、DevGroupのすべてのデータベースに対して「読取り専用でのターゲットの接続」を付与する必要があります。これは、「ターゲット権限付与の管理」列の「表示」の右側にある鉛筆アイコンを選択して行います。
「読取り専用でのターゲットの接続」権限をクリックし、ページ下部までスクロールします。「続行」ボタンを選択します。
新しい権限が表示されます。「次へ」ボタンを選択します。
「リソース権限」ページで「次へ」を選択します。
このロールDEV-ROLEを付与する管理者を選択します。「次へ」ボタンを選択します。
新規のロールDEV-ROLEの設定を確認します。
次に、名前付き資格証明を作成します。このケースでは名前付き資格証明に、データベースのログオンに使用されたデータベース資格証明が含まれています。これは、開発者がEnterprise Managerのデータベース・パフォーマンス・ページにアクセスするときに使用されます。「設定」→「セキュリティ」→「名前付き資格証明」とリンクをたどります。
「作成」ボタンをクリックします。
この名前付き資格証明がデータベースへのログオンに使用するユーザー名およびパスワード情報を入力します。次の情報を選択しています。
「資格証明名」: DevCred
認証ターゲット・タイプ: データベース・インスタンス -このユース・ケースでは、DevGroupのデータベース・インスタンスに対する開発エンジニアのアクセス権を付与することに関心を持っています。
「資格証明のタイプ」: 「データベース資格証明」 - このユース・ケースでは、さきほど指定したターゲット・タイプのユーザー名およびパスワードを入力します。
「有効範囲」: 「グローバル」 - このユース・ケースでは、このユーザー名およびパスワードが各データベースに適用されます。「テストと保存」ボタンをクリックします。
有効な「テスト・ターゲット名」を入力し、「テストと保存」クリックします。
新しい名前付き資格証明が表示されます。この名前付き資格証明を開発エンジニアの1人に付与するには、「アクセスの管理」をクリックします。
「権限の追加」ボタンをクリックします。
この名前付き資格証明を使用する開発エンジニアを選択します。「選択」ボタンをクリックします。
ページの下部にユーザー情報が表示されます必要であれば、さらにユーザーを追加することもできます。
この開発エンジニアがEnterprise Managerにログオンすると、パフォーマンス情報などの必要なデータを表示するアクセス権を取得します。ただし、予想されるように、データベースへの書込み操作は実行できません。ユーザーかデータベースに対して書込み操作を行った場合、Enterprise Managerに次のエラーが表示されます。
この項の内容は、次のとおりです。
Enterprise Manager Framework Securityによって、Enterprise Managerコンポーネント間の安全な通信チャネルが実現します。たとえば、Framework SecurityではOracle Management Serviceとその管理エージェントの間の接続が保護されます。またセキュアな通信では、盗聴などのネットワークの脅威から保護し、公開鍵暗号などの技術を使用して機密保護および整合性を確保します。
|
関連項目: Enterprise Managerコンポーネントの概要は『Oracle Enterprise Manager概要』。 |
Enterprise Manager Framework Securityは、次のようなEnterprise Managerコンポーネント間のセキュアな接続を実装します。
管理サービスに対してEnterprise Manager Framework Securityを有効にするには、管理サービスのホーム・ディレクトリの次のサブディレクトリにあるemctl secure omsユーティリティを使用します。
<OMS_ORACLE_HOME>/bin
emctl secure omsユーティリティでは次の処理が実行されます。
管理リポジトリ内にルート鍵を生成します。ルート鍵は、管理サービスおよび管理エージェントに対する一意のデジタル証明書を含むOracle Walletの配布時に使用されます。Oracle Walletは、Oracle Clientおよびサーバーへのセキュリティ資格証明の保存に使用されます。Oracle Walletの詳細は、『Oracle Database Advanced Securityガイド』を参照してください。
WebTier内にある既存のHTTPS構成とは別に、管理サービスと管理エージェントの間のHTTPSチャネルが有効になるようにWebTierを変更します。
Enterprise Manager Framework Securityを使用した管理エージェントからのリクエストを管理サービスが受諾できるようにします。
emctl secure omsユーティリティを実行するには、エージェント登録パスワードを最初に選択する必要があります。エージェント登録パスワードは、Oracle Management Agentの今後のインストールでデータをEnterprise Managerインストールにロードする権限があることを検証するために使用されます。
Oracle Management Serviceに対してEnterprise Manager Framework Securityを有効にするには、次のようにします。
次のコマンドを使用して管理サービス、WebTierを停止します。
<OMS_ORACLE_HOME>/bin/emctl stop oms
次のコマンドを入力します。
<OMS_ORACLE_HOME>/bin/emctl secure oms
Enterprise Managerのルート・パスワードを入力するよう求められます。SYSMANのパスワードを入力します。
エージェント登録パスワードを指定するよう求められます。このパスワードは、管理サービスを使用してセキュアな通信を確立しようとする管理エージェントに必要なパスワードです。管理サービスのエージェント登録パスワードを指定します。
OMSを再起動します。
管理サービスが再起動した後、HTTPSプロトコルを使用して次のセキュアなURLを参照し、管理サービスへの保護された接続をテストします。
https://hostname.domain:https_console_port/em
注意: Enterprise ManagerコンソールURLは、"emctl status oms -details"コマンドを実行して確認できます。
例:
$ emctl status oms -details Oracle Enterprise Manager Cloud Control 12c Release 3 Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. Enter Enterprise Manager Root (SYSMAN) Password : ... Console URL: https://omshost.mydomain.com:5416/em
管理サービスのセキュリティが正常に有効化された場合、ブラウザにEnterprise Managerのログイン・ページが表示されます。
$ emctl secure oms Oracle Enterprise Manager Cloud Control 12c Release 3 Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. Securing OMS... Started. Enter Enterprise Manager Root (SYSMAN) Password : Enter Agent Registration Password : Securing OMS... Successful Restart OMS
サーバー・ロード・バランサ(SLB)の裏で使用可能な管理サービスをデプロイする場合は、その管理サービスが使用可能なDNSホスト名に対して特別の注意が必要です。管理サービスは、myhost.mycompany.comなどの特定のローカル・ホストで稼働している場合もありますが、管理エージェントは、サーバー・ロード・バランサに割り当てられているホスト名を使用して管理サービスにアクセスします。たとえば、oracleoms.mycompany.comです。
このため、管理サービスに対してEnterprise Manager Framework Securityを有効化する場合は、サーバー・ロード・バランサのホスト名が、SSL通信のために管理サービスによって使用される証明書に埋め込まれていることを確認してください。これは、emctl secure omsを使用し、次のように、追加の-hostパラメータを使用してホスト名を指定することにより行うことができます。
|
注意: コマンドを実行する前に、まずSLBのホスト名、ポートを指定し、SLBが構成されていることを確認する必要があります。 |
次のコマンドを入力して管理サービス上でセキュリティを有効化します。
emctl secure oms -host <slb_hostname> [-slb_console_port <slb UI port>] [-slb_port <slb upload port>] [other params]
各OMSでこのコマンドを実行します。'emctl secure oms'コマンドの実行後、各OMSを再起動する必要があります。
サーバー・ロード・バランサ上に仮想サーバーとプールを作成します。
次のURLを使用してコンソールにアクセスできることを検証します。
https://slb_hostname:slb_console_port/em
次のコマンドを使用して、サーバー・ロード・バランサでエージェントを再度保護します。
emctl secure agent -emdWalletSrcUrl <SLB Upload or UI URL>
例:
Agent_Home/bin/emctl secure agent -emdWalletSrcUrl https://slb_hostname:slb_upload_port/em
1つのロード・バランサをアップロード操作用に、もう1つをコンソール操作用に指定して、Oracle Enterprise Managerを構成できます。それには、両方のSLBのプールをそれぞれのポートで構成し、次のコマンドを使用して、コンソール操作とアップロード操作に対して個別にOMSを保護する必要があります。
$emctl secure oms -host <slb_hostname>[-slb_port <slb upload port>] [other params] $emctl secure console -host <slb_hostname> other params
現在の認証局(CA)の有効期限が切れる場合や、鍵の強度や署名アルゴリズムを変更する場合は、新しいCAを作成する必要があります。各CAに一意の識別子が割り当てられます。たとえば、インストール時に作成されたCAの識別子はID 1となり、以降のCAの識別子はID 2、ID 3といった具合になります。最後に作成されたCAが常にアクティブであり、OMSとエージェントの証明書を発行します。
OMSマシンのいずれかでemctl secure createcaコマンドを実行します。
使用している環境に複数のOMSがある場合、emctl secure createcaが実行されたマシンから<EM_Instance_Home>/sysman/config/b64LocalCertificate.txtを他のすべてのOMSマシンの同じ場所(つまり、<EM_Instance_Home>/sysman/config/b64LocalCertificate.txt)にコピーします。
すべてのOMSを再起動します。
例2-4 新しい認証局の作成
emctl secure createca [-sysman_pwd <pwd>] [-host <hostname>] [-key_strength <strength>] [-cert_validity <validity>] [-root_dc <root_dc>] [-root_country <root_country>] [-root_email <root_email>] [-root_state <root_state>] [-root_loc <root_loc>] [-root_org <root_org>] [-root_unit <root_unit>] [-sign_alg <md5|sha1|sha256|sha384|sha512>] [-cert_validity <validity>] Oracle Enterprise Manager 12c Release 3 Cloud Control Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. Creating CA... Started. Successfully created CA with ID 2
例2-5 認証局に関する情報の表示
emcli get_ca_info -ca_id="1;2" -details Info about CA with ID: 1 CA is not configured DN: CN=myhost.example.com, C=US Serial# : 3423643907115516586 Valid From: Tue Mar 16 11:06:20 PDT 2011 Valid Till: Sat Mar 14 11:06:20 PDT 2020 Number of Agents registered with CA ID 1 is 1 myhost.mydomain.com:3872 Info about CA with ID: 2 CA is configured DN: CN=myhost.example.com, C=US, ST=CA Serial# : 1182646629511862286 Valid From: Fri Mar 19 05:17:15 PDT 2011 Valid Till: Tue Mar 17 05:17:15 PDT 2020 There are no Agents registered with CA ID 2
セキュリティ・ステータスとOMSポート情報を表示するには、次のコマンドを使用します。
例2-6 emctl status oms -details
Oracle Enterprise Manager Cloud Control 12c Release 3 Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. Console Server Host : mymachine.mycompany.com HTTP Console Port : 7802 HTTPS Console Port : 5416 HTTP Upload Port : 7654 HTTPS Upload Port : 4473 EM Instance Home : /ade/myadmin_txn48/oracle/work/em/EMGC_OMS1 OMS Log Directory Location : /ade/myadmin_txn48/oracle/work/em/EMGC_OMS1/sysman/log OMS is not configured with SLB or virtual hostname Agent Upload is locked. OMS Console is unlocked. Active CA ID: 2 Console URL: https://mymachine.mycompany.com:5416/em Upload URL: https://mymachine.mycompany.com:4473/empbs/upload WLS Domain Information Domain Name : EMGC_DOMAIN Admin Server Host : mymachine.mycompany.com Admin Server HTTPS Port: 7022 Admin Server is RUNNING Managed Server Information Managed Server Instance Name: EMGC_OMS1 Managed Server Instance Host: mymachine.mycompany.com WebTier is Up Oracle Management Server is Up
Oracle Management Serviceは次のモードで構成できます。
TLSv1専用モード: TLSv1接続のみを使用するようにOMSを構成するには、次の操作を実行します。
次のコマンドを入力してOMSを停止します。
<OMS_ORACLE_HOME>/bin/emctl stop oms
次のコマンドを入力します。
emctl secure oms -protocol TLSv1
Domain_Home/bin/startEMServer.shまたはstartEMServer.cmdのJAVA_OPTIONSに-Dweblogic.security.SSL.protocolVersion=TLS1を追加します。このプロパティがすでに存在する場合、値をTLS1に更新します。プラットフォームに応じてstartEMServer.shまたはstartEMServer.cmdを使用します。
次のコマンドでOMSを再起動します。
<OMS_ORACLE_HOME>/bin/emctl start oms
SSLv3専用モード: SSLv3接続のみを受け付けるようにOMSを構成するには、次の操作を実行します。
次のコマンドを入力してOMSを停止します。
<OMS_ORACLE_HOME>/bin/emctl stop oms
次のコマンドを入力します。
emctl secure oms -protocol SSLv3
WindowsのDomain_Home/bin/startEMServer.shまたはstartEMServer.cmdでJAVA_OPTIONSに-Dweblogic.security.SSL.protocolVersion=SSL3を追加します。このプロパティがすでに存在する場合、値をSSL3に更新します。
次のコマンドでOMSを再起動します。
<OMS_ORACLE_HOME>/bin/emctl start oms
混合モード: SSLv3接続とTLSv1接続をどちらも使用するようにOMSを構成するには、次の操作を実行します。
次のコマンドを入力してOMSを停止します。
<OMS_ORACLE_HOME>/bin/emctl stop oms
次のコマンドを入力します。
emctl secure oms
Domain_Home/bin/startEMServer.shでJAVA_OPTIONSに-Dweblogic.security.SSL.protocolVersion=ALLを追加します。このプロパティがすでに存在する場合、値をALLに更新します。
次のコマンドでOMSを再起動します。
<OMS_ORACLE_HOME>/bin/emctl start oms
|
注意: OMSはデフォルトで混合モードを使用するように構成されます。TLSv1専用モードで管理エージェントを構成するには、emd.propertiesファイルでallowTLSOnly=trueを設定してエージェントを再起動します。 |
ホストに管理エージェントをインストールする際は、管理エージェントによって使用される管理サービスを指定する必要があります。管理エージェントに対してEnterprise Manager Framework Securityを有効にするには、管理エージェントのホーム・ディレクトリの次のディレクトリにあるemctl secure agentユーティリティを使用します。
<AGENT_INSTANCE_HOME>/bin (UNIX) <AGENT_INSTANCE_HOME>\bin (Windows)
emctl secure agentユーティリティでは次の処理が実行されます。
管理エージェントに対する一意のデジタル証明書を含むOracle Walletを管理サービスから取得します。この証明書は、管理エージェントがセキュアな管理サービスとSSL通信を行うために必要です。
管理サービスで登録されている管理エージェントのエージェント・キーを取得します。
ネットワーク上でHTTPS経由で使用可能となるように管理エージェントを構成し、それによって管理サービスとのすべての通信で管理サービスのHTTPSアップロードURLを使用するように構成します。
管理エージェントに対してEnterprise Manager Framework Securityを有効にするには、次のようにします。
管理サービスと管理リポジトリを稼働状態にします。
管理エージェントを停止します。
emctl stop agent
次のコマンドを入力します。
emctl secure agent
emctl secure agentユーティリティはエージェント登録パスワードを要求し、そのパスワードを管理サービスに対して認証して、Enterprise Manager Framework Securityを使用するように管理エージェントを再構成します。
例2-7「emctl secure agentユーティリティのサンプル出力」は、emctl secure agentユーティリティのサンプル出力を示しています。
管理エージェントを再起動します。
emctl start agent
管理エージェントのホームページをチェックして、管理エージェントが保護されていることを確認します。
|
注意: また、emctl status agent -secureコマンドを実行するか、emctl status agentコマンドの出力に含まれるエージェントおよびリポジトリのHTTPS URLをチェックすることによっても、管理エージェントが保護されているかどうかを確認できます。 |
管理エージェントのホームページの「セキュア・アップロード」フィールドに、Enterprise Manager Framework Securityが管理エージェントに対して有効になっているかどうかが示されます。
例2-7 emctl secure agentユーティリティの出力例
emctl secure agent Oracle Enterprise Manager 12c Release 3 Cloud Control. Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. Securing agent... Started Securing agent... Successful.
例2-8 emctl status agent secureコマンドの出力例
$ emctl status agent -secure Oracle Enterprise Manager Cloud Control 12c Release 3 Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. Checking the security status of the Agent at location set in /ade/pchebrol_emkey/oracle/work/agentStateDir/sysman/config/emd.properties... Done. Agent is secure at HTTPS Port 1838. Checking the security status of the OMS at http://adc4110148.us.mycompany.com:7654/empbs/upload/... Done. OMS is secure on HTTPS Port 4473
Enterprise Managerでは、Oracle Management AgentのインストールがデータをOracle Management Serviceにロードする権限を持つことを検証するために、エージェント登録パスワードを使用します。
エージェント登録パスワードは、Oracle Management Serviceに対してセキュリティが有効な場合、インストール時に作成されます。Enterprise Managerコンソールから登録パスワードを直接追加、編集、削除できます。
|
注意: 新しいエージェントがOMSに登録されないようにするには、すべての登録パスワードを削除してください。 |
Cloud Controlコンソールを使用して既存の登録パスワードの管理、または追加の登録パスワードの作成ができます。
「設定」メニューから、「セキュリティ」、「登録パスワード」の順に選択します。
Enterprise Managerに「登録パスワード」ページが表示されます(図2-4)。インストール中に指定された登録パスワードは、「登録パスワード」表に<I初期エージェント登録パスワード>の記載とともに表示されます。
「登録パスワード」ページを使用して登録パスワードの変更、追加の登録パスワードの作成、または現在の管理リポジトリに関連付けられている登録パスワードの削除を行います。
「登録パスワード」ページで管理エージェント登録パスワードを作成または編集するとき、パスワードを永続的にして複数の管理エージェントで使用するのか、1回のみまたは事前定義した期間のみ使用するのかを選択できます。
たとえば、管理者が特定のホストに管理エージェントをインストールすることを要求した場合、管理者が1つの管理エージェントをインストールおよび構成するために使用する、1回のみのパスワードを作成できます。
このケースとは逆に、期限切れになり管理者が新規パスワードを求めることが必要になるまで、次の2週間ずっと管理者が使用できる永続的なパスワードを作成することもできます。
新しいエージェント登録パスワードを追加するには、管理サービスがインストールされているマシン上で次のemctlコマンドを使用します。
emctl secure setpwd [sysman pwd] [new registration pwd]
emctl secure setpwdコマンドを使用するには、エージェント登録パスワードの追加を認証するため、Enterprise Managerのスーパー管理者ユーザーであるsysmanのパスワードが必要になります。
他のセキュリティ・パスワードと同様に、定期的かつ頻繁にエージェント登録パスワードを変更し、パスワードが広く知られることのないようにしてください。
管理サービスのHTTPSチャネルを使用するセキュアな管理エージェント・インストールのみが、管理リポジトリにデータをアップロードでき、Cloud ControlコンソールにはHTTPS経由でのみアクセス可能にすることが重要です。
管理エージェントがHTTPS経由でのみ管理サービスにデータをアップロードできるようにアクセスを制限するには、次のようにします。
次のコマンドを使用して管理サービス、WebTierを停止します。
cd <OMS_ORACLE_HOME>/bin emctl stop oms
次のコマンドを入力して、管理エージェントがHTTP経由で管理サービスにデータをアップロードできないようにします。
emctl secure lock -upload
コンソールをロックしてコンソールへのHTTPアクセスを防ぐには、次のコマンドを入力します。
emctl secure lock -console
両方ともロックするには次のコマンドのいずれかを入力します。
emctl secure lock or emctl secure lock -upload -console
管理サービス上でセキュリティを有効化する一方で、コンソール・アクセスとエージェントからのアップロードの両方をロックするには、次のコマンドを入力します。
emctl secure oms -lock [other options]
管理サービス、WebTier、およびその他のアプリケーション・サーバー・コンポーネントを再起動します。
emctl start oms
HTTPプロトコルを使用してOMSアップロードURLにアクセスできないことを確認します。
たとえば、次のURLにナビゲートします。
http://hostname.domain:4889/empbs/upload
次のメッセージと同様のエラー・メッセージが返されます。
Forbidden You are not authorised to access this resource on the server.
注意: HTTPアップロード・ポート番号はemctl status oms -detailsコマンドを使用して確認できます。「HTTPアップロード・ポート」の検索
HTTPSプロトコルを使用してOMSアップロードURLにアクセスできることを確認します。
たとえば、次のURLにナビゲートします。
https://hostname.domain:4888/empbs/upload
次のメッセージが返されますが、これは管理エージェントを保護するためにセキュアなアップロード・ポートが使用可能であることを示すものです。
Http XML File receiver Http Recceiver Servlet active!
管理サービスがセキュアではない管理エージェントからのアップロードを受け取れるようにするには、次のコマンドを使用します。
emctl secure unlock -upload
|
注意:
|
例2-9 emctl secure lockコマンドの出力例
emctl secure lock Oracle Enterprise Manager 12c Release 3 Cloud Control Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. OMS Console is locked. Access the console over HTTPS ports. Agent Upload is locked. Agents must be secure and upload over HTTPS port. Restart OMS
例2-10 emctl secure unlockコマンドの出力例
emctl secure unlock Oracle Enterprise Manager 12c Release 3 Cloud Control Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. OMS Console is unlocked. HTTP ports too can be used to access console. Agent Upload is unlocked. Unsecure Agents may upload over HTTP. Restart OMS
|
注意: Enterprise Manager 12c以降、Oracle Management Serviceはデフォルトでロックされます(コンソールとアップロードの両方)。 |
この項ではOracle Management Repositoryのセキュリティを有効にする方法を説明します。この項の内容は、次のとおりです。
管理リポジトリのセキュリティはOracle Advanced Securityを使用して有効にします。Oracle Advanced SecurityはOracleデータベースと双方向に転送されるデータのセキュリティを強化します。
|
関連項目: 『Oracle Database Advanced Securityガイド』 |
管理リポジトリのデータベースについてOracle Advanced Securityを有効にするには、sqlnet.ora構成ファイルを変更する必要があります。sqlnet.ora構成ファイルは、Oracle Advanced Securityパラメータなどの様々なデータベース接続パラメータを定義するために使用されます。
sqlnet.oraファイルはデータベース・ホームの次のサブディレクトリにあります。
<OMS_ORACLE_HOME>/network/admin
管理リポジトリおよびその管理リポジトリと通信する管理サービスについてセキュリティを有効にした後で、管理エージェント・ホーム・ディレクトリのsqlnet.ora構成ファイルを変更して、管理エージェントに対するOracle Advanced Securityも構成する必要があります。
管理サービスおよび管理リポジトリの両方がOracle Advanced Securityを使用するように構成されていることが重要です。構成されていない場合、管理サービスが管理リポジトリへの接続を試行した際にエラーが発生します。たとえば、管理サービスでは次のエラーが返される場合があります。
ORA-12645: Parameter does not exist
この問題を解決するには、管理サービスおよび管理リポジトリの両方が次の項で記述されているとおりに構成されるようにしてください。
|
注意: この項の手順は、Oracle Advanced Securityが有効になるようにsqlnet.ora構成ファイルを手動で変更する方法を示しています。もう1つの方法として、『Oracle Database Advanced Securityガイド』に記述されている管理ツールを使用してこの変更を行うことができます。 |
管理サービス・データベースに対してOracle Advanced Securityを有効にしている場合、または管理リポジトリ・データベースに対してOracle Advanced Securityを有効にする予定の場合は、次の手順を実行し、管理サービスに対してOracle Advanced Securityを有効にします。
管理サービスを停止します。
<OMS_ORACLE_HOME>/bin/emctl stop oms
emctl set propertyコマンドを使用して、Enterprise Manager操作プロパティを設定します。次の表に、設定する必要のあるemomsプロパティを示します。
表2-2 Enterprise Managerプロパティ内のOracle Advanced Securityプロパティ
| プロパティ | 説明 |
|---|---|
|
Enterprise Managerが管理サービスと管理リポジトリ間の暗号化を使用するかどうかを定義します。可能な値はTRUEおよびFALSEです。デフォルト値はTRUEです。次に例を示します。
|
|
|
管理サービスの暗号化要件を定義します。使用可能な値は、REJECTED、ACCEPTED、REQUESTEDおよびREQUIREDです。 重要: Enterprise Managerがサーバー生成アラート(表領域フルなど)からの通知を受け取ることができなくなるため、encryption_clientプロパティをREQUIREDに設定しないでください。現在、Enterprise ManagerはREQUIRED設定でのサーバー生成アラートをサポートしていません。REQUESTED設定の場合のみサポートされます。 デフォルト値はREQUESTEDです。データベースでセキュアな接続がサポートされている場合は管理サービスでセキュアな接続が使用され、サポートされていない場合はセキュアでない接続が使用されます。 例:
|
|
|
クライアントでサポートされる様々な暗号化アルゴリズムを定義します。使用可能な値を丸カッコ内にリストします。デフォルト値は 例:
|
|
|
クライアントのチェックサム要件を定義します。 可能な値は、REJECTED、ACCEPTED、REQUESTEDおよびREQUIREDです。 デフォルト値はREQUESTEDです。つまり、サーバーでチェックサム対応接続がサポートされている場合は管理サービスでその接続が使用され、サポートされていない場合は通常接続が使用されます。 例:
|
|
|
クライアントでサポートされている別の種類のチェックサム・アルゴリズムを定義します。 可能な値は丸カッコで囲まれています。デフォルト値は( MD5 )です。 例:
|
管理サービスを再起動します。
<OMS_ORACLE_HOME>/bin/emctl start oms
データベースが保護され、暗号化されたデータのみがデータベース・サーバーとその他のソースの間で転送されることを確実にするため、Oracle Databaseのドキュメント・ライブラリで入手可能なセキュリティに関するドキュメントを参照します。
|
関連項目: 『Oracle Database Advanced Securityガイド』 |
次の手順は、管理リポジトリ・データベースおよびそのデータベースと管理サービスとの接続に対してOracle Advanced Securityが有効になっていることを確認する方法の例です。
データベースのOracleホームの次のディレクトリにあるsqlnet.ora構成ファイルを探します。
<OMS_ORACLE_HOME>/network/admin
テキスト・エディタを使用して、sqlnet.oraファイル内で次のエントリ(または同様のエントリ)を探します。
SQLNET.ENCRYPTION_SERVER = REQUESTED SQLNET.CRYPTO_SEED = "abcdefg123456789"
|
関連項目: 『Oracle Application Server管理者ガイド』のOracleサーバーおよびクライアントに対するネットワーク・データ暗号化および整合性の構成に関する項 |
変更を保存してテキスト・エディタを終了します。
管理リポジトリについてOracle Advanced Securityを有効にした後で、管理リポジトリを監視する管理エージェントについてもOracle Advanced Securityを有効にする必要があります。
管理リポジトリを監視している管理エージェントのホーム・ディレクトリの、次のディレクトリにあるsqlnet.ora構成ファイルを探します。
AGENT_HOME/network/admin (UNIX) AGENT_HOME\network\admin (Windows)
テキスト・エディタを使用して、sqlnet.ora構成ファイルに次のエントリを追加します。
SQLNET.CRYPTO_SEED = "abcdefg123456789"
SQLNET.CRYPTO_SEEDは、10から70文字の任意の文字列になります。
|
関連項目: 『Oracle Application Server管理者ガイド』のOracleサーバーおよびクライアントに対するネットワーク・データ暗号化および整合性の構成に関する項 |
変更を保存してテキスト・エディタを終了します。
管理エージェントを再起動します。
Enterprise Manager Cloud Controlの一部としてインストールされたWebLogic Server (管理サーバーおよび管理対象サーバー)は、デフォルトのアイデンティティ・キーストア(DemoIdentity.jks)とデフォルトのトラスト・キーストア(DemoTrust.jks)で構成されます。また、WebLogic Serverは、JDKのcacertsファイルのCA証明書を信頼します。このデフォルトのキーストア構成は、テストや開発を目的とする場合に適しています。ただし、これらのキーストアは本番環境では使用しないでください。
WLS用に構成されたデフォルトのデモ証明書は、512ビットのキー長です。最小の証明書キー長用のMicrosoftのセキュリティ更新(KB2661254)がブラウザ・マシンに適用された場合、WebLogic管理コンソールはInternet Explorerでアクセスできません。Internet Explorerを使用してWebLogic管理コンソールにアクセスするには、WLS用にカスタム証明書を構成してください。
次の項では、カスタムWeblogic Server証明書の構成を順を追って説明します。
|
注意: この手順は、Enterprise Manager 12c Cloud Control (12.1.0.2)以降に適用できます。 |
環境内の各OMS用のJavaキーストア(JKS)を作成します。
OMSがサーバーのロード・バランサを使用して構成されているかどうかにかかわらず、証明書署名リクエスト(CSR)の生成時には、CNに対するOMSマシン名を指定します(例: CN=myoms.mydomain.com)。OMSマシン名は、EM_INSTANCE_HOST property in <EM_Instance_Home>/emgc.propertiesの値からわかります。
各キーストアの、キーストア・パスワード、秘密鍵のエントリの別名、秘密鍵のパスワードを書き留めてください。
注意: WLSでサポートされている署名アルゴリズムのみを使用してください。
キーストアを対応するOMSマシンにコピーするか、またはOMSマシンからアクセスできる場所に配置します。
キーストアの例: /scratch/oms1.jks、/scratch/oms2.jks、/scratch/oms3.jks
個別のファイルにCA証明書を作成します(ファイルごとに1つのCA証明書)。これらの証明書ファイルをOMSマシンにコピーするか、またはOMSマシンからアクセスできる場所に配置します。
ファイル名の例: /scratch/ca1cert.cer、/scratch/ca2cert.cer、/scratch/ca3cert.cer
OMSとともにインストールされたOMSマシン上で実行中の管理エージェントで次の手順を実行します。
|
注意: OMSとともにインストールされたエージェント上のみで必要で、他のエージェントでは必要ありません。 |
エージェントを停止します。
<Agent_Instance_Home>/bin/emctl stop agent
カスタムCA証明書をエージェントにインポートします。
<Agent_Instance_Home>/bin/emctl secure add_trust_cert_to_jks -trust_certs_loc <ca_cert_file> -alias <certalias> [-password <montrust_jks_pwd>]
例:
<Agent_Instance_Home>/bin/emctl secure add_trust_cert_to_jks -trust_certs_loc /scratch/ca1cert.cer -alias ca1certalias [-password welcome]
カスタム証明書の発行に関連する各CAに対してこの手順を繰り返します。
毎回、異なる別名を指定します。
エージェントを起動します。
<Agent_Instance_Home>/bin/emctl
各OMSで次の手順を実行します。
OMSを停止します。
<OMS_Home>/bin/emctl stop oms
次のコマンドを実行します。
emctl secure wls (-jks_loc <loc> -jks_pvtkey_alias <alias> [-jks_pwd <pwd>] [-jks_pvtkey_pwd <pwd>] | -wallet <loc>) Specify jks_loc,jks_pvtkey_alias or wallet
例:
<OMS_OH>/bin/emctl secure wls -jks_loc /scratch/oms1.jks -jks_pvtkey_alias pvtkey1alias <OMS_OH>/bin/emctl secure wls -wallet /scratch/omswallet
OMSを停止します。
<OMS_Home>/bin/emctl stop oms -all
OMSを起動します。
|
注意: 前述の手順をすべての管理サービスで繰り返す必要があります。 |
<OMS_Home>/bin/emctl start oms
デフォルトのWebLogicデモ証明書を使用するように切り替える必要がある場合、各OMSで次の手順を実行します。
OMSを停止します。
<OMS_Home>/bin/emctl stop oms
次のコマンドを実行します。
<OMS_Home>/bin/emctl secure wls -use_demo_cert
OMSを停止します。
<OMS_Home>/bin/emctl stop oms -all
OMSを起動します。
<OMS_Home>/bin/emctl start oms
|
注意: 前述の手順をすべての管理サービスで実行する必要があります。 |
HTTPS WebTier仮想ホスト用のサード・パーティの証明書を構成する手順は、次のとおりです。
クラウド内のOMSごとにウォレットを作成します。OMSがインストールされているマシンのホスト名、またはロード・バランサ名(OMSがロード・バランサ内にある場合)を共通名に指定します。
各OMSで次のコマンドを実行し、そのOMSを再起動します。
emctl secure console -wallet <location of custom wallets> -self_signed [-host]
|
注意: 引数-walletまたは-self_signedのいずれかは必須です。 |
|
注意: サポートされるのはシングル・サインオン(SSO)のウォレットのみです。 |
次の2種類の方法で、HTTPSアップロード仮想ホスト用のサード・パーティの証明書を構成できます。
方法1
クラウド内のOMSごとにウォレットを作成します。
ウォレットを作成する際に、OMSがインストールされているマシンのホスト名、またはロード・バランサ名(OMSがロード・バランサ内にある場合)を共通名に指定します。
証明連鎖に含まれるすべての認証局(ルート認証局、中間認証局など)の証明書をtrusted_certs.txtという名前のファイルに記述します。
OMSと通信する各エージェントを実行中のホスト・マシンにtrusted_certs.txtファイルをダウンロードまたはコピーします。
次のコマンドを実行して、カスタムCA証明書をエージェント用のトラスト証明書としてインポートします。
emctl secure add_trust_cert -trust_certs_loc <location of the trusted_certs.txt file>
エージェントを再起動します。
OMSを保護して再起動します。
emctl secure oms -wallet <location of wallet> -trust_certs_loc <loc of trusted_certs.txt> [any other options]
方法2
クラウド内のOMSごとにウォレットを作成します。
OMSがインストールされているマシンのホスト名、またはロード・バランサ名(OMSがロード・バランサ内にある場合)を共通名に指定します。
証明連鎖に含まれるすべての認証局(ルート認証局、中間認証局など)の証明書をtrusted_certs.txtという名前のファイルに記述します。
OMSを保護します。
emctl secure oms -wallet <location of wallet> -trust_certs_loc <loc of trusted_certs.txt> [any other options]
OMSを再起動します。
emctl secure agentコマンドを実行(すべてのエージェントで実行)してエージェントを再度保護するか、emctl secureコマンドを実行してトラスト・ポイントをインポートします。
|
注意: 信頼できるcertsファイル(trusted_certs.txt)には、base64形式の証明書のみが含まれ、特殊文字やコメントは含められません。 |
Oracle Management Serviceは次のモードで構成できます。
TLSv1専用モード: TLSv1接続のみを使用するようにOMSを構成するには、次の操作を実行します。
次のコマンドを入力してOMSを停止します。
<OMS_ORACLE_HOME>/bin/emctl stop oms
次のコマンドを入力します。
emctl secure oms -protocol TLSv1
Domain_Home/bin/startEMServer.shまたはstartEMServer.cmdのJAVA_OPTIONSに-Dweblogic.security.SSL.protocolVersion=TLS1を追加します。このプロパティがすでに存在する場合、値をTLS1に更新します。
次のコマンドでOMSを再起動します。
<OMS_ORACLE_HOME>/bin/emctl start oms
SSLv3専用モード: SSLv3接続のみを使用するようにOMSを構成するには、次の操作を実行します。
次のコマンドを入力してOMSを停止します。
<OMS_ORACLE_HOME>/bin/emctl stop oms
次のコマンドを入力します。
emctl secure oms -protocol SSLv3
WindowsのDomain_Home/bin/startEMServer.shまたはstartEMServer.cmdでJAVA_OPTIONSに-Dweblogic.security.SSL.protocolVersion=SSL3を追加します。このプロパティがすでに存在する場合、値をSSL3に更新します。
次のコマンドでOMSを再起動します。
<OMS_ORACLE_HOME>/bin/emctl start oms
混合モード: SSLv3接続とTLSv1接続をどちらも使用するようにOMSを構成するには、次の操作を実行します。
次のコマンドを入力してOMSを停止します。
<OMS_ORACLE_HOME>/bin/emctl stop oms
次のコマンドを入力します。
emctl secure oms
Domain_Home/bin/startEMServer.shでJAVA_OPTIONSに-Dweblogic.security.SSL.protocolVersion=ALLを追加します。このプロパティがすでに存在する場合、値をALLに更新します。
次のコマンドでOMSを再起動します。
<OMS_ORACLE_HOME>/bin/emctl start oms
|
注意: OMSはデフォルトで混合モードを使用するように構成されます。TLSv1専用モードで管理エージェントを構成するには、emd.propertiesファイルでallowTLSOnly=trueを設定してエージェントを再起動します。 |
次のemctlコマンドは、Enterprise Managerインフラストラクチャの様々なコンポーネントの保護に使用されます。
emctl secure oms [-sysman_pwd <sysman password>] [-reg_pwd <registration password>]
[-host <hostname>] [-ms_hostname <Managed Server hostname>]
[-slb_port <SLB HTTPS upload port>] [-slb_console_port <SLB HTTPS console port>] [-no_slb]
[-secure_port <OHS HTTPS upload Port>] [-upload_http_port <OHS HTTP upload port>]
[-reset] [-console] [-force_newca]
[-lock_upload] [-lock_console] [-unlock_upload] [-unlock_console]
[-wallet <wallet_loc> -trust_certs_loc <certs_loc>]
[-key_strength <strength>] [-sign_alg <md5|sha1|sha256|sha384|sha512>]
[-cert_validity <validity>] [-protocol <protocol>]
[-root_dc <root_dc>] [-root_country <root_country>] [-root_email <root_email>]
[-root_state <root_state>] [-root_loc <root_loc>] [-root_org <root_org>] [-root_unit <root_unit>]
| パラメータ | 説明 |
|---|---|
| sysman_pwd | Oracle Management Repositoryのユーザー・パスワードです。 |
| reg_pwd | 管理エージェントの登録パスワードです。 |
| host | Oracle Management Serviceで使用される証明書で使用されるホスト名です。管理サービスの前にSLBがある場合は、SLBホスト名を使用する必要がある場合があります。 |
| reset | 新しい認証局が作成されます。すべてのエージェントとOracle Management Serviceを再保護する必要があります。 |
| secure_port | WebTierのHTTPSアップロード・ポートを変更する場合、これを指定します。 |
| upload_http_port | WebTierのHTTPアップロード・ポートを変更する場合、これを指定します。 |
| slb_port | サーバー・ロード・バランサを使用する場合、このパラメータは必須です。サーバー・ロード・バランサに構成されているセキュアなアップロード・ポートを指定します。 |
| slb_console_port | サーバー・ロード・バランサを使用する場合、このパラメータは必須です。サーバー・ロード・バランサに構成されているセキュアなコンソール・ポートを指定します。 |
| no_slb | SLB構成を削除します。 |
| root_dc | ルート証明書で使用されるドメイン・コンポーネントです。デフォルト値はcomです。 |
| root_country | ルート証明書で使用される国です。デフォルト値はUSです。 |
| root_state | ルート証明書で使用される州です。デフォルト値はCAです。 |
| root_loc | ルート証明書で使用される場所です。デフォルト値は、EnterpriseManager on <hostname>です。 |
| root_org | ルート証明書で使用される組織名です。デフォルト値は、EnterpriseManager on <hostname>です。 |
| root_unit | ルート証明書で使用される組織単位です。デフォルト値は、EnterpriseManager on <hostname>です。 |
| root_email | ルート証明書で使用される電子メール・アドレスです。デフォルト値は、EnterpriseManager@<hostname>です。 |
| wallet | サード・パーティの証明書を含むウォレットの場所です。このパラメータは、サード・パーティの証明書を構成する際に指定する必要があります。 |
| trust_certs_loc | trusted_certs.txtの場所です(サード・パーティの証明書を使用する場合に必要)。 |
| key_strength | 使用される鍵の強度です。有効な値は、512、1024、2048、および4096です。
注意: IBM AIXプラットフォームの場合、key_strengthに使用できるのは最大で2048ビットです。 |
| cert_validity | 自己署名付き証明書の有効日数です。有効な範囲は、1から3650です。 |
| protocol | TLSv1専用またはSSLv3専用、あるいは混合モード(デフォルト)でOracle Management Serviceを構成する場合に使用されます。有効な値は、ApacheのSSLProtocolディレクティブにより許可された値になります。
注意: key_strengthおよびcert_validityパラメータは、-walletオプションが使用されない場合にのみ適用可能です。 |
| force_newca | これを指定すると、従前どおり古い認証局を使用するよう構成されているエージェントは無視されます。 |
| ms_hostname | 管理対象サーバーのホスト名。 |
| sign_alg | 署名アルゴリズム。 |
| lock | アップロードをロックします。 |
| lock_console | コンソールをロックします。 |
| console | これを指定すると、HTTPSコンソールのポート用の証明書も再作成されます。 |
OMSに対してエージェントを保護します。登録パスワード(またはパスワード・ファイル)を指定する必要があります。
emctl secure agent <registration password> [-passwd_file <absolute path to file>]
emctl secure wls (-jks_loc <loc> -jks_pvtkey_alias <alias> | -wallet <loc> | -use_demo_cert)
Specify jks_loc,jks_pvtkey_alias or wallet or use_demo_cert
[-jks_pwd <pwd>] [-jks_pvtkey_pwd <pwd>]
-jks_loc : Location of JKS containing the custom cert for Admin & Managed Servers
-jks_pvtkey_alias : JKS's private key alias
-jks_pwd : JKS's keystore password
-jks_pvtkey_pwd : JKS's private key password
-wallet : Location of wallet containing the custom cert for Admin & Managed Servers
-use_demo_cert: Configure the demo cert for Admin & Managed Servers
次に対してサード・パーティの証明書を構成できます。
HTTPSコンソール・ユーザー
HTTPSアップロード仮想ホスト
|
注意: サポートされるのはシングル・サインオンのウォレットのみです。 |
HTTPS WebTier仮想ホスト用のサード・パーティの証明書を構成する手順は、次のとおりです。
OMSごとにウォレットを作成します。OMSがインストールされているマシンのホスト名、またはロード・バランサ名(OMSがロード・バランサ内にある場合)を共通名に指定します。
各OMSで次のコマンドを実行し、そのOMSを再起動します。
emctl secure console -wallet <location of custom wallets> -self_signed [-host]
|
注意: 引数-walletまたは-self_signedのいずれかは必須です。 |
|
注意: サポートされるのはシングル・サインオンのウォレットのみです。 |
次の2種類の方法で、HTTPSアップロード仮想ホスト用のサード・パーティの証明書を構成できます。
方法1
OMSごとにウォレットを作成します。
ウォレットを作成する際に、OMSがインストールされているマシンのホスト名、またはロード・バランサ名(OMSがロード・バランサ内にある場合)を共通名に指定します。
証明連鎖に含まれるすべての認証局(ルート認証局、中間認証局など)の証明書をtrusted_certs.txtという名前のファイルに記述します。
OMSと通信する各エージェントを実行中のホスト・マシンにtrusted_certs.txtファイルをダウンロードまたはコピーします。
各エージェントでadd_trust_certコマンドを実行し、エージェントを再起動します。
emctl secure add_trust_cert -trust_certs_loc <location of the trusted_certs.txt file>
OMSを保護して再起動します。
emctl secure oms -wallet <location of wallet> -trust_certs_loc <loc of trusted_certs.txt> [any other options]
方法2
クラウド内のOMSごとにウォレットを作成します。
OMSがインストールされているマシンのホスト名、またはロード・バランサ名(OMSがロード・バランサ内にある場合)を共通名に指定します。
証明連鎖に含まれるすべての認証局(ルート認証局、中間認証局など)の証明書をtrusted_certs.txtという名前のファイルに記述します。
OMSを保護した後、再起動します。
emctl secure oms -wallet <location of wallet> -trust_certs_loc <loc of trusted_certs.txt> [any other options]
emctl secure agentコマンドを実行(すべてのエージェントで実行)してエージェントを再度保護するか、emctl secure add_trust_cert -trust_certs_loc <trusted_certs.txtファイルの場所>コマンドを実行してトラスト・ポイントをインポートします。-trust_certs_locパラメータには、trusted_certs.txtファイルのパスとファイル名を含める必要があります。
|
注意: このファイルには、Base64形式の証明書のみが含まれ、特殊文字や空の行は含まれません。 |
内容は次のとおりです。
資格証明サブシステム
プラガブル認証モジュール(PAM)のサポート
sudoおよびPowerbrokerのサポート
ユーザー名やパスワードなどの資格証明は、通常、データベース、アプリケーション・サーバーおよびホストなどのターゲットにアクセスする際に必要です。次のフロー・チャートは、一般的な資格証明設定ワークフローを示しています。
資格証明は暗号化され、Enterprise Managerに保存されます。Enterprise Manager 12c以降、基本のユーザー名/パスワード以外に、PKI、SSH鍵、Kerberosなどの強力な認証スキームが資格証明サブシステムでサポートされます。ジョブ、デプロイメント・プロシージャおよび他のEnterprise Mangerサブシステムで使用されるSSH鍵ベースのホスト認証は現在サポートされます。
適切な資格証明を使用することにより、次が可能になります。
バックグラウンドおよびリアルタイムでのメトリックの収集
バックアップ、パッチ適用、クローニングなどのジョブの実行
起動および停止などのリアルタイムのターゲット管理の実行
My Oracle Supportへの接続
資格証明はその使用方法に基づいて、次のカテゴリに分類できます。
資格証明は、Enterprise Manager内に名前付きのエンティティとして格納されます。管理者は、Enterprise Managerで資格証明を定義および格納し、資格証明名を使用して資格証明を参照します。資格証明を格納すると次のような利点があります。
資格証明の詳細をすべてのユーザーに公開する必要がありません。
それぞれのOracleホームまたはホスト・マシンに対し、ユーザー名およびパスワードを毎回指定する必要がなくなり、かわりに、保存された資格証明を使用する名前付きプロファイルを選択できるので、時間と手間が省けます。
名前付き資格証明はオペレーティング・システムのログイン資格証明のようにユーザー名/パスワードのペアで指定でき、Oracleホームの所有者の資格証明は主にジョブの実行、パッチ適用およびその他の管理タスクなどの操作を実行する場合に使用されます。たとえば、管理者は、パッチの適用に使用するユーザー名とパスワードを"MyPatchingCreds"として格納できます。その後、"MyPatchingCreds"を使用するパッチ適用ジョブを発行して、本番環境のデータベースにパッチを適用できます。
上位のDBAのみが上位特権資格証明、データベース用のsys資格証明についての知識を持つデータ・センターでは、たとえば、これらの資格証明を名前付き資格証明に保存し、これらを下位の管理者と共有できます。下位の管理者は、実際の資格証明が何であるかは知らなくても、名前付き資格証明を使用して仕事を行うことができます。
複数の管理者が1つのターゲットに対して同じ資格証明を持つデータ・センター。管理者はこれらの資格証明を含む名前付き資格証明を1つ作成し、この名前付き資格証明を適切な担当者と共有できます。これにより、同じ資格証明を含む名前付き資格証明のコピーを複数作成する必要がなくなるため、資格証明の保守(パスワードの変更など)が簡単になります。
|
注意: 名前付き資格証明を使用したビデオ・チュートリアルの参照:Oracle Enterprise Manager 12c: 名前付き資格証明の作成と使用 https://apex.oracle.com/pls/apex/f?p=44785:24:0::NO:24:P24_CONTENT_ID,P24_PREV_PAGE:5460,1 |
名前付き資格証明の適用範囲には2つのカテゴリがあります。
グローバル名前付き資格証明は、ターゲット・タイプに関する認証情報を含むエンティティです。グローバル名前付き資格証明は、作成時または後で、任意のEnterprise Managerターゲット・タイプに適用できます。グローバル名前付き資格証明は、資格証明タイプ(認証スキーマとも呼ばれる)と資格証明プロパティ(認証パラメータとも呼ばれる)で構成されます。
個々のターゲット・タイプは、1つ以上の資格証明タイプを持つ場合があります。
例:
hostAはパスワード・ベース(ユーザー名/パスワードが必要)およびSSHキー(公開鍵/秘密鍵のペアが必要)の資格証明タイプを持ち、データベースinstanceAはパスワード・ベースおよびKerberosベースの資格証明タイプを持ちます。
資格証明プロパティは、資格証明タイプに必要な情報で構成され、権限委任(PDP)で使用されている場合はパラメータを含むことがあります(PDPの詳細は権限委任の項で使用可能なコマンドとパラメータを参照)。
グローバル名前付き資格証明は独立したエンティティとして初期設定されるため、Enterprise Manger管理者は、このタイプの資格証明とターゲット・タイプを後で関連付けることができます。
ターゲット名前付き資格証明は、特定のターゲットに適用される資格証明情報を含むエンティティです。ターゲット名前付き資格証明は、Enterprise Managerターゲットに適用でき、作成時に適用されます。このエンティティには、ターゲット・タイプに関する、資格証明タイプ(ユーザー名/パスワードまたは公開鍵/秘密鍵のペアなのかを示す)と資格証明パラメータ(PDP設定の場合は使用されるPDPユーティリティの場所、およびパラメータと実行されるコマンド)も含まれます。
名前付き資格証明を作成するには、管理者はCREATE_CREDENTIAL権限が必要です。CREATE_CREDENTIAL権限を持つ管理者が名前付き資格証明を作成すると、その管理者はその名前付き資格証明の所有者とみなされます。名前付き資格証明の所有者は、その名前付き資格証明へのアクセスをいつでも共有できます。その管理者は、権限付与管理者とみなされます。名前付き資格証明へのアクセスが付与された管理者は、権限受領管理者とみなされます。所有者は、適切なレベルの権限を1人または多数の権限受領管理者に付与することで、名前付き資格証明へのアクセスを共有できます。名前付き資格証明の所有者によって付与された権限のタイプは、権限受領管理者が必要とするアクセス・レベルに応じて異なります。次の権限レベルがすべての名前付き資格証明に使用できます。
VIEW: VIEW権限はデフォルトの権限レベルです。名前付き資格証明に対するVIEW権限を持つ権限受領管理者は、その名前付き資格証明を使用して、Enterprise Manager内でのジョブの実行、パッチ操作およびその他のシステム管理アクティビティを行うことができます。また、権限受領管理者は、機密ではない詳細(SUDOまたはPowerBroker、使用されているコマンドなど)および名前付き資格証明のユーザー名を表示できます権限受領管理者は、パスワードや公開鍵/秘密鍵などの名前付き資格証明の機密情報は表示できません。
EDIT: EDIT権限レベルにはVIEWレベル権限も含まれます。名前付き資格証明に対するEDIT権限を持つ権限受領管理者は、その名前付き資格証明を使用して、Enterprise Manager内でのジョブの実行、パッチ操作およびその他のシステム管理アクティビティを行うことができます。権限受領管理者は、名前付き資格証明のパスワードや公開鍵/秘密鍵のペアなどの機密情報も変更できます。権限受領管理者は、名前付き資格証明の資格証明タイプ(ホスト、SSHキーなど)および資格証明のユーザー名の両方を変更できます。認証ターゲット・タイプは、変更できません。
FULL: FULL権限にはVIEWとEDITの両方が含まれます。名前付き資格証明に対するFULL権限を持つ権限受領管理者は、その名前付き資格証明を使用して、Enterprise Manager内でのジョブの実行、パッチ操作およびその他のシステム管理アクティビティを行うことができます。権限受領管理者は、名前付き資格証明のユーザー名やパスワード、公開鍵/秘密鍵のペア、認証タイプ(ホスト、SSHキーなど)などの機密情報も変更できます。名前付き資格証明に対するFULL権限を持つ管理者は、その名前付き資格証明の削除もできます。
名前付き資格証明を作成するには、名前付き資格証明リソース権限が必要です。
名前付き資格証明の作成手順:
Cloud Controlで、「設定」メニューから「セキュリティ」、「名前付き資格証明」の順に選択します。
「名前付き資格証明」ページで、「作成」をクリックします。
「資格証明の作成」ページの「一般プロパティ」セクションに、次の詳細を指定します。
一意の資格証明名入力し、説明を指定します。
認証ターゲット・タイプに「ホスト」を、資格証明タイプに「ホスト資格証明」を選択します。
すべてのターゲットに対して同じ資格証明を使用するには「グローバル」を選択します。
「資格証明の作成」ページの「資格証明プロパティ」セクションに、ホスト・マシンのアクセスに必要な「ユーザー名」および「パスワード」を入力し、「実行権限」ドロップ・ダウン・リストから、次のいずれかを実行します。
オペレーティング・システム・ホストの資格証明(Oracleなど)またはOracleホームの所有者の資格証明を使用している場合、「なし」を選択します。
オペレーティング・システムのホストの資格証明またはホスト・マシンのroot資格証明へのアクセス権がない場合、「Sudo」または「PowerBroker」を選択して、別のオペレーティング・システム・ユーザーの資格証明を使用して、ホスト・マシンへのSUDO (またはpbrun)を実行します。別のユーザーの資格証明を使用するには、「別名実行」フィールドに、オペレーティング・システム・ホストの資格証明(Oracleなど)またはホスト・ユーザーのOracleホームの所有者の資格証明を入力する必要があります。
「資格証明の作成」ページの「アクセス制御」セクションで、「権限の追加」をクリックし、選択した管理者またはロールに名前付けプロファイルの権限を付与します。デフォルトでは、選択した管理者に表示権限が付与されます。
|
注意: OMSエージェント・ファイルシステム上のソフトウェア・ライブラリの場所に管理者(またはユーザー)がアクセスして、その場所を使用できるように、名前付き資格証明の所有者は必ず、OMSエージェント上の場所にアクセスするすべての管理者に明示的な表示権限を付与する必要があります。そのためには、この項で説明しているように、名前付き資格証明の作成時に「権限の追加」をクリックして管理者の名前を追加するか、既存の名前付き資格証明を編集して、次の手順で他の管理者(またはユーザー)に権限を付与する必要があります。
たとえば、CloudプラグインがインストールされていてEnterprise Managerでクラウド機能を使用している場合には、ソフトウェア・ライブラリに関連付けられた資格証明に対する emcli login -username=<username> -password=<password> emcli grant_privs -name=CLOUD_ENGINE_USER -privilege="GET_CREDENTIAL;CRED_NAME=<>:CRDED_OWNER=<>" |
権限を変更するには、管理者を選択し、「権限の変更」をクリックします。「権限の選択」ダイアログ・ボックスで、権限を「編集」または「完全」に変更し、「OK」をクリックします。
すべての詳細を入力したら、「テストと保存」をクリックします。ホストの資格証明が正しければテストは正常に終了し、資格証明は保存されます。
Enterprise Manager管理者は、資格証明の作成時または資格証明の編集時に権限を付与することで、他の管理者に権限を付与できます。
「名前付き資格証明」ページで、新規名前付き資格証明の作成、既存の資格証明の編集、アクセスの管理(権限の付与/取消し)、削除、テスト、参照の表示を行えます。また、「例による問合せ」アイコンをクリックすると、名前付き資格証明のリストを絞り込めます。
資格証明所有者のみが自分の資格証明へのアクセスを管理できます。資格証明所有者がリファレンスを表示すると、所有していないリファレンスであってもすべてを見ることができます。一方、資格証明を所有していないユーザーは自分のリファレンスのみを見ることができます。
|
注意: 名前付き資格証明を作成するには、名前付き資格証明リソース権限が必要です。 |
名前付き資格証明のアクセス制御モデルは、次のルールに従います。
名前付き資格証明の所有者のみが、自分が作成した名前付き資格証明に対する権限を他のEnterprise Manager権限受領管理者に対して付与できます。
Enterprise Managerスーパー管理者が新たに作成された名前付き資格証明に対する権限を得るのは、その名前付き資格証明に対する権限が明示的に付与された後です。
Enterprise Manager管理者は、権限レベルに関係なく、パスワードや秘密鍵などの機密性の高いフィールドをコンソールUIで表示できません。これは、パスワードを「*」文字に置き換えることによって行われます。
名前付き資格証明権限はロールに割り当てることはできません。これによって、アクセス権が明示的に付与されていない資格証明に対する権限を、Enterprise Managerスーパー管理者が自身に不正に付与できないようにします。
Enterprise Manager権限受領管理者は、所有者によって明示的に許可されていないかぎり、他の管理者の資格証明を表示できません。デフォルトでは、Enterprise Managerスーパー管理者でさえも、他のユーザーの名前付き資格証明を表示できません。
Enterprise Manager管理者は、自身の名前付き資格証明を作成し、デフォルトで、所有する名前付き資格証明に対してフル権限を持つことができます。
認証スキームは、ターゲット・タイプでサポートされる認証タイプです。たとえば、ホストでは、ユーザー名/パスワード・ベースの認証、公開鍵認証、Kerberos認証がサポートされます。実際は、エンタープライズ内の各ターゲット・タイプで異なる認証スキームがサポートされる場合があります。管理対象環境で使用可能な様々な認証スキームに対応するために、Enterprise Mangerでこれらの認証スキーム用の資格証明を構成できます。
|
注意: Enterprise Manager管理者が所有する資格証明は、その管理者がEnterprise Managerから削除されると、すべて削除されます。その名前付き資格証明の権限受領管理者へのすべての参照および付与も削除されます。デフォルトでは、名前付き資格証明へのアクセスはスーパー管理者には付与されないため、スーパー管理者は別の管理者が所有する名前付き資格証明を再割当てできません。 |
特権資格証明はシステム上のrootユーザーの認証情報を指定します。特権資格証明は、rootスクリプトの実行といった特権的な処理を行うために使用するrootアカウントの詳細の資格証明です。特権資格証明は特権ユーザーまたはパワー・ユーザーのためのものです。Enterprise Manager 11gでは、プロビジョニングするユーザーごとにSUDO権限が明示的に付与されている必要がありました。一方、Enterprise Manager 12cでは、SUDO権限で通常のルート・ユーザーのアクションを実行する特権資格証明を設定する必要があります。
特権資格証明を作成するには、次の手順に従います。
「名前付き資格証明の作成」で説明した手順を使用して名前付き資格証明を作成します。
「名前付き資格証明」ページで、資格証明を選択してから「編集」をクリックします。
「資格証明プロパティの編集」ページの「資格証明プロパティ」セクションに、ホスト・マシンのアクセスに必要な既存の「ユーザー名」および「パスワード」を編集し、「実行権限」ドロップ・ダウン・リストから、次のいずれかを実行します。
オペレーティング・システム・ホストの資格証明(Oracleなど)またはOracleホームの所有者の資格証明を使用している場合、「なし」を選択します。
オペレーティング・システムのホストの資格証明またはホスト・マシンのroot資格証明へのアクセス権がない場合、「Sudo」または「PowerBroker」を選択して、別のオペレーティング・システム・ユーザーの資格証明を使用して、ホスト・マシンへのsudo (またはpbrun)を実行します。別のユーザーの資格証明を使用するには、「別名実行」フィールドに、オペレーティング・システム・ホストの資格証明(Oracleなど)またはホスト・ユーザーのOracleホームの所有者の資格証明を入力する必要があります。
監視資格証明は、特定のタイプのターゲットを監視する場合に管理エージェントでのみ使用されます。監視資格証明を必要とするターゲットは、コンソールに表示されます。ターゲットがEnterprise Managerに追加されると、適切な権限を持つ管理者が監視資格証明を設定します。管理者は、ターゲットを検出するためのADD_TARGET権限を持つ必要があり、そのターゲットの資格証明を入力するためにはCONFIGURE_TARGET権限が必要です。監視資格証明は、リポジトリに格納され、エージェントに伝播されます。資格証明が設定されていない場合、ターゲットは中断状態または停止状態として表示され、エージェントは資格証明なしでは監視ができなくなるため、メトリック収集エラーも表示されます。
監視資格証明を作成または編集するには、「設定」メニューで、「セキュリティ」、「監視資格証明」の順に選択します。
監視資格証明を変更するには、ターゲット・タイプを選択して「監視資格証明の管理」をクリックします。選択したターゲット・タイプの「監視資格証明」ページが表示されます。かわりに、次の例に示すようにEM CLIを使用して監視資格証明を変更できます。
./emcli set_monitoring_credential -target_name=mytarget.myco.com -target_type=host -cred_type=HostCreds -set_name=Bob -attributes="HostUserName:dwwolf;HostPassword:xxxxx:PDPTYPE:SUDO;RUNAS:root"
優先資格証明は、これらのターゲットのログイン情報を管理リポジトリに格納し、管理対象ターゲットへのアクセスを簡略化するために使用されます。たとえば、データベース・ターゲットでは、あるユーザーが複数のログインを持っていても、特定の操作を実行するために、優先設定したユーザー名/パスワード資格証明を格納してログインする場合があります。優先資格証明を使用すると、ターゲットへのログインを求めるプロンプトが表示されずに、これらの優先資格証明を使用して自動的にログインされるため、管理者はこれらの資格証明を認識するEnterprise Managerターゲットにアクセスできます。優先資格証明は、ジョブ・システムを使用した管理操作の実行にも使用できます。ユーザー名/パスワードまたは公開鍵/秘密鍵、および名前付き資格証明所有者によって権限受領管理者に付与される資格証明タイプとオプションのパラメータを含む、独立したエンティティを定義する名前付き資格証明と異なり、優先資格証明は、より便利な方法でアクセスすることを望む、個々の管理者によって任意のターゲットに対して設定されます。
優先資格証明を作成する手順は、次のとおりです。
「設定」メニューから、「セキュリティ」を選択し、「優先資格証明」を選択します。「優先資格証明」ページが表示されます。
リストからターゲット・タイプを選択します。
「優先資格証明の管理」をクリックします。選択したターゲット・タイプの「優先資格証明」ページが表示されます。
例: Enterprise Managerターゲット所有者は、ホスト・ターゲットに対して2つの優先資格証明セット(1つはHostCredNormalと呼ばれ、もう1つはHostCredPrivと呼ばれる)を定義します。簡単な操作の場合は、HostCredNormal(oracle/oracle123など、通常のユーザー(myusername/password)を使用する)を使用します。これに対し、そのホストでより多くの権限が必要な操作の場合は、HostCredPriv(rootユーザー(root/rootpasswd)を使用する)を使用します。ジョブを発行する場合、ジョブに応じて、これらの資格証明セットのいずれかを使用できます。
デフォルトの優先資格証明: デフォルトの優先資格証明は、特定のターゲット・タイプに構成され、そのターゲット・タイプのすべてのターゲットに使用できます。ターゲットの優先資格証明が優先されます。
「通常ホスト資格証明」 (例ではHostCredNormal): 通常の管理操作を実行します。
「特権ホスト資格証明」(例ではHostCredPriv): root権限を必要とする権限付き操作を実行します。
ターゲット優先資格証明: ターゲット優先資格証明は、特定のターゲットに設定される資格証明セットです。ターゲット優先資格証明は、ジョブ・システム、通知、パッチ適用などのアプリケーションで使用できます。たとえば、管理者がジョブの発行時にターゲット優先資格証明を使用するように選択すると、ターゲット(ターゲット資格証明)に設定されたターゲット優先資格証明が使用されます。ターゲット優先資格証明がない場合は、デフォルトの優先資格証明が(ターゲット・タイプに対して)使用されます。デフォルトの優先資格証明がない場合、ジョブは失敗します。指定がない場合、優先資格証明は、優先ターゲット資格証明のことです。
たとえば、ホスト優先資格証明を設定するには、「設定」メニューで、「セキュリティ」、「優先資格証明」の順に選択します。「優先資格証明」ページで、表から「ホスト」ターゲット・タイプを選択し、「優先資格証明の管理」をクリックします。「ホスト優先資格証明」が表示されます。
このページで、ホスト・ターゲット・タイプのデフォルトの資格証明と明示的な優先資格証明のどちらも設定できます。
Enterprise Managerリリース12.1.0.4以上では、優先資格証明をグローバル範囲指定することができます。グローバル優先資格証明は、管理者(必要な権限を持つ)が、これらの資格証明を特定のターゲットのすべてのユーザー、またはあるターゲット・タイプのすべてのユーザーに適用できるようにすることによって、システム全体に資格証明を実装する便利な方法を提供します。
次の図は、「ホスト優先資格証明」ページを示しています。「プリファレンス」タブでの設定は、特定のターゲットまたはターゲット・タイプに適用されるように、管理者によって設定された優先資格証明を参照します。
「グローバル・プリファレンス」タブでの設定は、特定のターゲットのすべてのユーザー、またはすべてのターゲット・タイプのすべてのユーザーに適用されるように、管理者(必要な権限を持つ)によって設定された優先資格証明を参照します。
グローバル優先資格証明を使用するには、次の権限が必要です。
OPERATOR_ TARGET: グローバル優先資格証明の使用に必要です。
FULL_TARGET: グローバル・プリファレンス・レベルでターゲット固有の範囲を設定するために必要です。
FULL_ANY_TARGET: グローバル・プリファレンス・レベルでターゲット・タイプの範囲を設定するために必要です。
優先資格証明は特定の順序で解決されます。ユーザーが範囲を指定したプリファレンスは、常に優先されます。Enterprise Managerは、最初にターゲット・レベルで、そのターゲット名の優先資格証明を検索することから始めます。見つからなかった場合、次にターゲット・タイプ(デフォルト)の優先資格証明を検索します。ユーザーが範囲指定したこれらのプリファレンスが見つからなかった場合、Enterprise Managerはグローバル範囲で同様の検索(最初にターゲット名の優先資格証明を検索し、その後ターゲット・タイプ(デフォルト)の優先資格証明を検索する)を繰り返します。
Enterprise Managerには、システムで使用する優先資格証明を判断する階層を示す「資格証明階層」表が表示されます。
次の表に示すように、資格証明の検索順序は常に同じで、優先資格証明が見つかるまで続きます(1つのレベルで資格証明が見つからなかった場合、Enterprise Managerは次のレベルへ順番に移動します)。
表2-3 資格証明プリファレンスの階層
| ユーザー/ターゲット | ユーザー1 | ユーザー2 | ユーザー3 | ... | すべてのユーザー |
|---|---|---|---|---|---|
|
ターゲット1 |
|||||
|
ターゲット2 |
|||||
|
ターゲット3 |
レベル1 |
レベル3 |
|||
|
. . . |
|||||
|
すべてのターゲット |
レベル2 |
レベル4 |
この例は、ジョブ実行中に明示的に選択されるものがなかった場合に、ジョブを完了させるために選択される優先資格証明の階層を示しています。優先資格証明が選択される順番は常に同じです。この例では、ジョブはユーザー2として実行しているとします。次の順序は、優先資格証明がそのレベルで設定されるまで常に監視されます。
レベル1 - プリファレンス、ターゲット優先資格証明
レベル2 - プリファレンス、デフォルト(ターゲット・タイプ)優先資格証明
レベル3 - グローバル・プリファレンス、ターゲット優先資格証明
レベル4 - グローバル・プリファレンス、デフォルト(ターゲット・タイプ)優先資格証明
資格証明は設定時にテスト済であることが前提です。資格証明が特定のレベルで設定されていない場合、資格証明サブシステムは資格証明が見つかるまで、レベル1からレベル4の順に確認しながら次のレベルへ移動します。最初に見つかった資格証明がジョブに使用する資格証明です。それ以降のレベルで設定された資格証明は無視されます。
ユーザー・プリファレンス(優先資格証明)が設定されている場合は、常にグローバル・プリファレンスより優先されます。
Cloud Controlで資格証明を優先資格証明として保存する場合は、次の手順に従います。
Cloud Controlで、「設定」メニューから「セキュリティ」、「優先資格証明」の順に選択します。「優先資格証明」ページが表示されます。
「優先資格証明」ページで、ターゲット・タイプ・リストから「ホスト」または「Oracleホーム」のいずれかを選択し、「優先資格証明の管理」をクリックします。
注意: 仮想サーバー・ターゲットの優先資格証明の設定のため、ターゲット・タイプとして「Oracle VM Server」を選択し、「資格証明の設定」をクリックします。
プロビジョニング・タスクに「ホスト」を選択すると、「ホスト優先資格証明」ページが表示されます。
ホストの「優先資格証明」ページの「ターゲット優先資格証明」セクションで、プロビジョニングを行うホスト・ターゲットを選択し、「設定」をクリックします。
「優先資格証明」ページで、表から「ホスト」または「Oracleホーム」のいずれかを選択し、「優先資格証明の管理」をクリックします。
パッチ適用タスクに「Oracleホーム」を選択すると、Oracleホームの「優先資格証明」ページが表示されます。
Oracleホームの「優先資格証明」ページの「ターゲット優先資格証明」セクションで、パッチを適用するOracleホームを選択します。選択したターゲットに対し通常および特権資格証明の両方が設定されていることを確認し、「設定」をクリックします。
Cloud ControlでMy Oracle Supportの資格証明を優先資格証明として保存する場合は、次の手順に従います。
Cloud Controlで、「設定」メニューから「My Oracle Support」を選択し、「資格証明の設定」をクリックします。
「My Oracle Support」ページで、My Oracle Supportの資格証明を入力し、「適用」をクリックします。
Cloud ControlでMy Oracle Supportの資格証明を優先資格証明として登録して、My Oracle Supportコンソール(Cloud Controlコンソールに統合されます)にアクセスするたびに資格証明を明示的に指定する必要がないようにすることをお薦めします。
EM CLI動詞を使用してパスワードを管理できます。EM CLIを使用して次のようなアクション実行できます。
ターゲット・データベースとEnterprise Managerの両方でデータベース・ユーザー・パスワードを変更します。
emcli update_db_password -change_at_target=Yes|No -change_all_reference=Yes|No
ホスト・ターゲットですでに変更されているパスワードを更新します。
emcli update_host_password -change_all_reference=Yes|No
指定のユーザーの優先資格証明を設定します。
emcli set_preferred_credential -set_name="set_name" -target_name="target_name" -target_type="ttype" -credential_name="cred_name" [-credential_owner ="owner]"
および
emcli set_preferred_credential -set_name="set_name" -target_name="target_name" -target_type="ttype" -credential_name="cred_name" [-credential_owner ="owner]"
特定のターゲット・タイプに優先資格証明が構成されているかどうかを判断します。
bin/emcli list -res=PreferredCredentials -bind="TargetType = 'host'
資格証明管理動詞の完全なリストは、Enterprise Managerコマンドライン・インタフェース・ガイドを参照してください。
この項の内容は、次のとおりです。
Secure Shell (SSH)では、セキュアなチャネルを使用してネットワーク越しに2つのデバイス間でデータを交換できます。SSHは主にLinuxまたはUNIXシステムで使用されます。SSHは、情報(特にパスワード)が平文で送信されるため、盗聴の可能性のあるFTP、telnetやその他のセキュアでないリモート・シェルに代わるものとして設計されました。SSHで使用される暗号化によって、セキュアでないネットワークでの機密保護とデータの完全性が実現されます。SSHは、DNSスプーフィング攻撃からもシステムを保護します。このため、本番環境には、telnet、FTPやその他のユーザー名/パスワード・ベースの認証よりもSSHの方が適しています。
管理操作の実行時、SSHを使用するようにEnterprise Managerを構成し、Enterprise Manager管理者が、SSHによって提供されるセキュリティ機能とEnterprise Managerの管理機能の両方を利用できるようにすることができます。このモードの認証時、エージェントはJava SSHクライアントとして機能し、資格証明に指定されているユーザー名/パスワードを使用してホストに接続します。
Enterprise Managerで管理者の公開鍵と秘密鍵のペアを格納でき、管理者は、公開鍵をホストで表示およびインストールできます。管理者は、操作を実行するために秘密鍵を参照する資格証明を指定したジョブやパッチ適用操作を発行できます。OMSは、コマンド、コマンド・パラメータとともに秘密鍵をエージェントに渡します。エージェントはJava SSHクライアントを起動し、秘密鍵を使用してホストに接続を試みます。ホストにはすでに公開鍵がインストールされているため、秘密鍵が識別され、エージェントのJava SSHクライアントが正常に認証されます。これで、エージェントは、SSHクライアントを介してホストでコマンドを実行し、リクエストされた操作を行うことできます。通信に使用するユーザー名はホストとOMSの両方で有効なOSユーザーである必要があります。これは名前付き資格証明で使用されるユーザー名であって、操作を起動する管理者のユーザー名ではありません。
|
注意: Enterprise Manager Grid Controlリリース12.1.0.3以前の場合、権限委任ありでSSH資格証明を使用するには、次のパラメータと値をemd.propertiesファイルに追加する必要があります。
EMPDP_PASSWORD_PROMPT_SUDO=FALSE リリース12.1.0.4以降、これは自動的に処理されます。 |
SSH認証鍵の生成、管理または変換を行うには、UNIXシステムで使用可能なSSH-keygenユーティリティを使用します。このSSH-keygenユーティリティ・ツールには、異なる強度で鍵を作成(SSHプロトコル・バージョン1の場合はRSA鍵を、SSHプロトコル・バージョン2による使用の場合はRSA鍵またはDSA鍵を作成)する様々なオプションが用意されています。
|
注意: この例に示す手順では、SSHの設定手順およびSSHを使用する公開鍵と秘密鍵のペアを介したユーザーとホストの等価についてきちんと理解しているものとします。 |
例2-11 SSH鍵ベースの認証の設定
$ ssh-keygen -t rsa
コマンド・オプションによって、SSH鍵(RSA鍵のペア)を生成するようユーティリティに指示されます。
Generating public/private rsa key pair. Enter file in which to save the key (/home/myhome/.ssh/id_rsa):
指定されるパスは、SSH鍵が格納される場所の標準のパス($HOME/.ssh)です。
Enter passphrase (empty for no passphrase)
重要: パスフレーズでは名前付き資格証明のSSHキーとの使用はサポートされません。
Enter same passphrase again: (empty for no passphrase) Your identification has been saved in /home/admin1/.ssh/id_rsa. Your public key has been saved in /home/admin1/.ssh/id_rsa.pub. The key fingerprint is: bb:da:59:7a:fc:24:c6:9a:ee:dd:af:da:1b:1b:ed:7f admin1@myhost2170474
これで、ssh-regkeyユーティリティによって、2つのファイルが.sshディレクトリに生成されました。
$ ls id_rsa id_rsa.pub
パスワードを求めるSSHプロンプトなしでホストにアクセスできるようにするには、公開鍵をそのシステムのauthorized_keysファイルにコピーします。
$ cp id_rsa.pub authorized_keys
これ以降、そのファイルにリストされているすべての鍵はアクセスが許可されます。
次に、SSHを使用してリモート・ログオンを行います。システムからパスワードを要求されません。
$ ssh myhost The authenticity of host 'myhost (10.229.147.184)' can't be established. RSA key fingerprint is de:a0:2a:d5:23:f0:8a:72:98:74:2c:6f:bf:ad:5b:2b. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'myhost,10.229.147.184' (RSA) to the list of known hosts. Last login: Mon Aug 29 16:48:45 2012 from anotherhost.example.com $
これで、資格証明をEnterprise Managerに追加する準備ができました。
「設定」メニューから、「セキュリティ」、「名前付き資格証明」の順に選択します。
「名前付き資格証明」ページで、「作成」をクリックします。資格証明の作成ページが表示されます。
「資格証明名」を入力します。たとえば、SSHCRED1などです。
注意: SSHCRED1資格証明セットは第2.4.1.8.4項「SSHキー資格証明を使用したホスト優先資格証明の設定(12.1.0.4より前)」で使用します。
「認証ターゲット・タイプ」ドロップダウン・メニューから「ホスト」を選択します。
次の図に示すように、「資格証明のタイプ」ドロップダウン・メニューから「SSHキー資格証明」を選択します。
SSH秘密鍵と公開鍵のファイルが、ブラウザが実行されているホストにコピーされていることを確認します。このようにすることで、次の手順で「参照」をクリックする場合に、コンソール内からのファイルへの移動が便利になります。
「資格証明プロパティ」リージョンで、「ユーザー名」を入力します。このユーザー名は、ホストとOMSに存在する有効なOSユーザーです。
「資格証明プロパティ」リージョンで公開鍵と秘密鍵の「参照」をクリックし、生成された公開鍵と秘密鍵のファイルをアップロードします。
「テストと保存」をクリックして資格証明を確認し、保存します。次の図に示すような新しい名前付き資格証明が表示されます。
|
注意: インストラクション・ビデオを見るには、次のサイトのOracle Enterprise Manager 12c: SSHキー名前付き資格証明の作成を参照してください。https://apex.oracle.com/pls/apex/f?p=44785:24:0::NO:24:P24_CONTENT_ID,P24_PREV_PAGE:5724,1 |
Enterprise Managerは、優先資格証明として使用できる、SSHキー資格証明の使用をデフォルトでサポート(12.1.0.4)しています。SSHキー資格証明セットは、エージェント・ターゲットの認証に使用されます。SSHキー資格証明セットの導入は、ユーザー名とパスワードの資格証明が不明な場合や代替のキュリティ・オプションを考えている場合に役立ちます。SSHキーは、潜在的にセキュアでないネットワークであってもデータの高い機密性と整合性が提供される、暗号化メソッドを使用しています。このサポートをデフォルトで提供することで、管理者はカスタムSSHキー資格証明を作成する必要がなくなり、使用が容易になります。
|
注意: SSH資格証明はWindowsオペレーティング・システムに対してサポートされていません。 |
SSH資格証明を優先資格証明に設定するには、次の手順を実行します。
「設定」メニューから、「セキュリティ」を選択し、「優先資格証明」を選択します。
ターゲット・タイプに「エージェント」または「ホスト」を選択し、「優先資格証明の管理」をクリックします。
エージェントの優先資格証明の設定ページが表示されます。詳細は、「優先資格証明」を参照してください。
このページは、デフォルトで管理者が最後に参照したページになります。優先資格証明を設定するには、次に示すように、「プリファレンス」タブをクリックします。
「デフォルトの優先資格証明」リージョン(このリージョンでは選択したターゲット・タイプのすべてのターゲットに対して優先資格証明を設定する)の下では、エージェント・ターゲット・タイプが選択されていました。前述の図を参照してください。
「ホスト資格証明」を選択して「設定」をクリックします。
ダイアログが表示され、このエージェント・ターゲット・タイプに適した使用可能な名前付き資格証明の現在の選択がリストされます。この管理者の場合、「SSH資格証明」を選択して、「保存」をクリックします。
「デフォルトの優先資格証明」には、この管理者のすべてのホスト・ターゲット・タイプに使用される資格証明が表示されます。次の図は、「資格証明セット」がホスト資格証明であり、「ターゲット・ユーザー名」がtestであることを示しています(これは名前付き資格証明でOSユーザーが使用されることを示します)。
この設定は、この管理者では、すべてのエージェント接続は、すべてのエージェントで認証するために、この資格証明セットを使用することを意味します。
|
注意: 次に説明する方法は、Enterprise Managerの12.1.0.4より前のバージョンで使用するための回避策です。 |
HostSSHCreds資格証明タイプを使用する新しい資格証明を作成することで、SSHキーを使用するホスト優先資格証明を設定できます。次にEnterprise Manager管理者はこの資格証明セットを使用する優先資格証明を設定します。各Enterprise Managerターゲット・タイプは、事前定義済の資格証明タイプの1つ以上の優先資格証明セットを持つことができます。
次の手順は、EM CLIを使用して、SSHキー資格証明をサポートするホスト優先資格証明セットを作成します。この例では、前の項で作成したタイプSSHキー資格証明の名前付き資格証明SSHCRED1があると仮定しています。
Enterprise Managerスーパー管理者としてEM CLIにログインします。
タイプHostSSHCredsの新しい資格証明セットを作成します。
$ emcli create_credential_set -set_name=HostSSHCredSet -target_type=host -supported_cred_types=HostSSHCreds Credential set "HostSSHCredSet" created successfully.
資格証明セットが作成されると、Enterprise Manger管理者はEM CLIまたはEnterprise Manager consoleコンソールのいずれかを使用して、この新しく作成された資格証明セットの優先資格証明を設定できます。
新しく作成された資格証明セットの優先資格証明を設定します。EM CLIまたはEnterprise Managerコンソールを使用できます。次のEM CLIの例では、タイプSSHキー資格証明の名前付き資格証明SSHCRED1はすでに作成されていると改定しています。
$ emcli set_preferred_credential -target_type=host -target_name=myhost.mycompany.com -set_name=HostSSHCredSet -credential_name=SSHCRED1 Successfully set preferred credentials for target myhost.mycompany.com:host.
資格証明セットが作成され、優先資格証明が設定されていると、HostSSHCredSet資格証明セットがなんらかのEnterprise Manager操作で使用されるたびに、その操作は名前付き資格証明SSHCRED1で定義されているSSH資格証明を使用します。次の図に、ホスト・ターゲットのデフォルトの優先資格証明としてリストされたHostSSHCredSet資格証明セットを示します。
管理者を編集および作成し、名前付き資格証明リソース権限を付与することで、SSHCRED1名前付き資格証明を使用する通常のEnterprise Manager管理者の優先資格証明を設定できるようになります。次の図に、名前付き資格証明の「権限付与の管理」UIを示します。
Enterprise Managerエージェントでは、OS資格証明の認証に次の2つの方法を使用できます。
従来の認証では、ユーザーが提出した資格証明は、システムのパスワード・データベース、つまり、/etc/passwdと関連ファイルにあるエントリ、および/etc/nsswitch.confまたは/etc/netsvc.confなどのOS特有の構成によって定義されたファイルへのリモート拡張にあるエントリと比較されます。
PAM認証では、エージェントはPAM(プラガブル認証モジュール)と呼ばれるオペレーティング・システムの機能を使用して、ユーザーが提出した資格証明を検証します。PAMは、様々な認証メカニズム(LDAP、Kerberos、RADIUSなど)のうち、PAM認識アプリケーションが使用すべきメカニズムを管理者が指定できるフレームワークです。アプリケーションは、サービス名を使用してPAMに対して自身を識別します。管理者がそのサービス名に対するPAM定義を構成している場合には、その定義内のルールがアプリケーションの認証リクエストに適用されます。構成していない場合には、特別なデフォルト・サービス名「その他」に対するルールが使用されます。
Enterprise Managerエージェントは、サービス名「emagent」を使用してPAMに対して自身を識別します。管理者が明示的に「emagent」PAMサービスを定義している場合、エージェントはPAM認証のみを試行します(「emagent」サービスに対して定義された方法が資格証明のセットを受け付けない場合には、これらの資格証明に関連付けられた操作は失敗となります)。
管理者が明示的に「emagent」PAMサービスを定義していない場合、エージェントはまず従来の認証を試行します。この試行が失敗の場合、「その他」サービス定義を使用してPAM認証を試行します。従来の認証またはPAM認証のどちらかが成功する場合には、その資格証明に関連付けられた操作が続行します。
PAMは複雑で制限のないフレームワークですが、この構成方法の一般的なアドバイスはこのドキュメントでは割愛します。ただし通常、PAMを使用してEnterprise Managerにホスト資格証明を認証させたい顧客は、同じPAMルールを使用するように定義されたその他のサービスをすでに持っており、このその他のサービスの定義でemagentサービスの基本を形成できます。
たとえば、顧客のOracle Enterprise Linuxホストは、接続を受け付ける際にSSHデーモンがKerberosとローカル認証の組み合せを使用するようにすでに構成されているとします。SSHDサービス定義ファイル/etc/pam.d/sshdには、次のセットの認証ルールがある場合があります。
auth sufficient pam_fprintd.so auth sufficient pam_unix.so nullok auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_krb5.so use_first_pass auth required pam_deny.so
ここで、顧客にホストに取り付けられた指紋スキャナへのアクセス権がある場合、それに基づいて認証します。指紋認証が動作しない場合は、従来の認証を試行します。これに失敗し、さらにユーザーのUIDが500以上の場合、kerberos認証を試行します。これも失敗する場合には、認証全体が失敗となります。
Enterprise Managerは、ジョブの実行または認証済メトリックの収集の必要があるときに、通常ユーザーの指へのアクセスがないため、顧客はEnterprise Managerが指紋スキャナ・チェック以外の、同じ認証プロセスをするように決断します。そのため、新しいサービス定義ファイル/etc/pam.d/emagentを作成し、pam_fprintd.soの行を除く前述のSSHD定義にあるものと同じ「auth」行を含めます。
auth sufficient pam_unix.so nullok auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_krb5.so use_first_pass auth required pam_deny.so
使用される認証方法の詳細は、顧客により異なり、実際の構成方法はプラットフォームにより異なります。ただし、エージェントPAMサービス定義を定義するこの一般的なアプローチ(使用する既存のサービスをベースとして識別し、このサービスの定義をコピーし、Enterprise Managerの使用に当てはまらないルールを削除すること)は、多くの場合に役立ちます。
権限委任(PDP)を使用すると、管理者は別のユーザーの権限を使用して権限アクティビティを実行できます。Enterprise Managerは、SudoとPowerBrokerという2つの認証ユーティリティ・ツールを使用して権限委任を行います。
Sudo: Sudoを使用すると、許可されたユーザーはスーパーユーザーまたはsudoersファイルに指定されている別のユーザーとしてコマンドを実行できます。コマンド起動元のユーザーがrootである、またはターゲット・ユーザーがコマンド起動元のユーザーと同じ場合は、パスワードが不要です。そうでない場合はデフォルト時、ユーザーはパスワードを使用して自分自身の認証を実行する必要があります。ユーザーが認証されると、タイムスタンプが更新され、ユーザーはパスワードなしで短期間(sudoersファイル内で上書きされないかぎり5分間)Sudoを使用できます。Sudoは、/etc/sudoersファイルを確認して、許可されているユーザーを特定します。詳細は、UNIXでSudoのマニュアル・ページ(man sudo)を参照してください。Enterprise Managerでは、sudoを使用してユーザーを認証し、sudoとしてスクリプトを実行します。たとえば、実行されるコマンドがfoo -arg1 -arg2の場合、sudo -S foo -arg1 -arg2として実行されます。
|
注意: 動作保証されているSUDOバージョンは1.6.7から1.6.9です。また、SUDO 1.7.2以降のバージョンもサポートされていることにも注意してください。動作保証されているPBRUNバージョンは4.0.8および5.xです。これらのユーティリティのそれ以降のバージョンは、根本的な変更がその動作に導入されないかぎり、引き続き動作する可能性があります。 |
PowerBroker: BeyondTrust PowerBrokerの場合、UNIXのシステム管理者は、root(または他の重要なアカウント)などの他のユーザーが特定のプログラムを実行できる環境を指定できます。そのため、ユーザー・アカウントの追加やライン・プリンタ・キューの固定といったアクションの担当を、rootのパスワードを公開することなく、適切な要員に安全に割り当てることができます。その結果、rootの権限全体を、データベースやファイルの権限の変更、ディスクの消去、またはより捉えにくい破損といった誤用や乱用から保護できます。BeyondTrust PowerBrokerは、一般的なシステム管理タスクを実行する既存のプログラムや、その独自のユーティリティ・セットにアクセスできます。BeyondTrust PowerBroker上で動作するように開発されているユーティリティでは、パスワード、アカウント、バックアップ、ライン・プリンタ、ファイルの所有権や削除、再起動、ユーザーのログアウト、ユーザー・プログラムの中断、どのユーザーがどこからどこにログインが許可されているかのチェックなどを管理できます。また、TCP/IP、ロード・バランサ、cron、NIS、NFS、FTP、rlogin、アカウンティング・サブシステムの管理も提供できます。ユーザーは、制限付きのシェルやエディタを使用し、rootとして特定のプログラムやファイルにアクセスできます。設定および構成の詳細は、PowerBrokerに関するドキュメントを参照してください。
|
注意: PowerBroker 7.1.1はテスト済で、推奨の最小バージョンです。 |
Enterprise Managerの権限委任は、これらのツール(SudoとPowerBroker)を名前付き資格証明とともに使用して、管理者が権限アクティビティを実行できるフレームワークを提供します。
組織内には、管理者が特定のタスクを実行するために昇格権限を持つ必要のある、多くの操作が存在します。たとえば、Cloud Controlでのすべてのプロビジョニングおよびパッチ適用タスクでは、オペレーティング・システムの通常のユーザー・アカウント(oracle)用に名前付き資格証明が設定されている必要があり、特権ユーザー・アカウント(root)用にも名前付き資格証明が設定されている必要があります。これらのアカウントのどちらにもアクセスを持っていない場合、SUDOまたはPowerBrokerアクセスを使用して、タスクを実行するユーザーを切り替えることができます。権限
委任には次の利点があります。
同じフレームワーク内でSUDOまたはPowerBrokerのいずれかを使用する柔軟性があります。
フレームワークを使用して、PowerBrokerをパスワードレスまたはパスワード保護モードで実行できます。
これらの権限委任設定を使用してテンプレートを作成し、そのテンプレートを複数のホストで再利用できます。これにより、エンタープライズ全体で権限委任設定を標準化できるだけでなく、権限委任設定の構成と管理のプロセスも促進および簡略化できます。
権限委任設定はデプロイメント・プロシージャに対してのみでなく、Cloud Controlのジョブに対しても使用できます。
次の例では、権限委任プロセスにおける異なるユーザーを説明しています。
例: 次の3つのユーザーを考えます。
ユーザー1: EMUSERと呼ばれ、Cloud ControlまたはEM CLIにログインしたEnterprise Manager管理者です。
ユーザー2: OSUSER1と呼ばれ、ターゲット・ホストOSのユーザーです。
ユーザー3: OSUSER2と呼ばれ、ターゲット・ホストOSのユーザーです。
EMUSERは、OSUSER1に対して名前付き資格証明を持っています。ここでは、Sudoは構成されています。名前付き資格証明はOSUSER2として実行されます。
権限委任の内部手順は次のようになります。
OSUSER1としてシステムにログインします。
OSUSER1のパスワードを使用して認証します。
sudoを起動してOSUSER2になります。
指定したコマンドをOSUSER2として実行します。
指定したコマンドが実行されている場合は、そのコマンドは、OSUSER2がログインしたかのように実行されます。たとえば、idコマンドが実行している場合には、OSUSER2として表示されます。
Enterprise Managerでサポートされている認証ツールはsudoとpbrunです。これらのツールは、管理エージェントとともにターゲット・ホスト内に存在しており、正しく操作を行う前に、適切に構成されている必要があります。次の各項では、これらのツールおよび関連する構成ファイルについて説明します。
管理者は、sudoまたはpbrunの構成ファイル・エントリに基づいて、sudoまたはpbrunを設定し、Enterprise Managerの特定機能の権限をそのOSユーザーに割り当てることができます。管理エージェントは、nmosudoという信頼できる実行可能ファイルを使用します(nmosudo実行可能ファイルを使用することで、このエージェントは暗号ハンドシェイクを介してリクエスト元を検証できます)。これにより、sudoまたはpbrunの構成ファイルに基づいて、権限の低いユーザーが権限の高いユーザーとしてnmosudoを実行できるようになります。
Enterprise Managerにより、実行可能ファイルnmosudoは、OMSからエージェントを介したリモート操作実行要求のみを受け取ることが保証されます。nmosudoは、要求がエージェントからのものであることを検証できないと、該当するリモート操作を実行しません。そのため、ユーザーjohndoeがnmosudoをコマンドラインから直接起動し、ユーザーoracleとしてPerlスクリプトを実行することはできません。
Enterprise Manager Cloud Control 12cリリース1 (12.1.0.1) [バンドル・パッチ1ありまたはなし]では、nmosudoはエージェント・インスタンス・ディレクトリにありました。たとえば、/u01/oracle/agent/agent_inst/bin/nmosudoです。
Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)と後続のリリースでは、この場所が変更されました。現在は、nmosudoはエージェントのベース・ディレクトリ内のsbinディレクトリにあります。たとえば、/u01/oracle/agent/sbin/nmosudoなどです。
したがって、Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)をインストール、またはアップグレードする場合、nmosudoの新しい場所を含めるようにPDP構成ファイルを変更する必要があります。
|
注意: 動作保証されているSUDOバージョンは1.6.7から1.6.9です。また、SUDO 1.7.2以降のバージョンもサポートされていることにも注意してください。詳細は、UNIXでsudoのマニュアル・ページ(man sudo)を参照してください。 |
sudo構成ファイル(/etc/sudoers)のエントリ例は次のとおりです。このファイルの一般的な書式は次のとおりです。
root ALL=(ALL) ALL
これは、rootユーザーは、すべてのユーザーとして、すべての端末からすべてのコマンドを実行できることを意味しています。
サンプル1
# Sample /etc/sudoers file should have following entry # If you do not have access to oracle and root accounts, # then add the following entries into the file: #usage: #[user] [terminal]=[as other user] [command] #where: user = the user terminal = terminal from where user can run sudo # cmd # as other user = which user the first user may act # as # command = which commands can be run which using # sudo johndoe ALL=(oracle) /u01/oracle/agent/sbin/nmosudo * johndoe ALL=(root) /u01/oracle/agent/sbin/nmosudo * #Where, the user johndoe can access sudo from any terminal #to run as oracle the nmosudo executable with all commands, #passed from the console.
サンプル2
# If you have access to the oracle account, # but not to the root account, # then only add the following entry into the file: johndoe ALL=(root) /u01/oracle/agent/sbin/nmosudo * #Where, the user johndoe can access sudo from any terminal #to run as root the nmosudo executable with all commands, #passed from the console.
|
注意: この例では、ユーザーがコマンドのサブセットのみを制限できるようにSUDOERSファイルを構成する方法を示しています。SUDOを使用してEnterprise Managerを通じて実行されるすべてのコマンドには、次の接頭辞が付きます。 <AGENT_HOME>/sbin/nmosudo DEFAULT_PLGUIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ ACTION <Command-to-executed-with-args> これを使用して、ユーザーに使用させたいコマンドのリストを制限することができます。 たとえば、johndoeがrootとしてroot.shのみ実行できる場合は、次の文字列をSUDOERSファイルに追加できます。 johndoe ALL=(root) <AGENT_HOME>/sbin/nmosudo DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION root.sh |
サンプル3
ALL=(ALL)/u01/oracle/agent/sbin/nmosudo DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION perl -e exit 0,/u01/oracle/agent/sbin/nmosudo DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION id This example allows the user to perform a basic PERL test, and run only id command.
BeyondTrust PowerBrokerの場合、UNIXのシステム管理者は、root (または他の重要なアカウント)として特定のプログラムを他のユーザーが実行できる環境を指定できます。そのため、ユーザー・アカウントの追加やライン・プリンタ・キューの固定といったアクションの担当を、rootのパスワードを公開することなく、適切な要員に安全に割り当てることができます。その結果、rootの権限全体を、データベースやファイルの権限の変更、ディスクの消去、またはより捉えにくい破損といった誤用や乱用から保護できます。BeyondTrust PowerBrokerは、一般的なシステム管理タスクを実行する既存のプログラムや、その独自のユーティリティ・セットにアクセスできます。BeyondTrust PowerBroker上で動作するように開発されているユーティリティでは、パスワード、アカウント、バックアップ、ライン・プリンタ、ファイルの所有権や削除、再起動、ユーザーのログアウト、ユーザー・プログラムの中断、どのユーザーがどこからどこにログインが許可されているかのチェックなどを管理できます。また、TCP/IP、ロード・バランサ、cron、NIS、NFS、FTP、rlogin、アカウンティング・サブシステムの管理も提供できます。ユーザーは、制限付きのシェルやエディタを使用し、rootとして特定のプログラムやファイルにアクセスできます。設定および構成の詳細は、PowerBrokerに関するドキュメントを参照してください。
|
注意: PowerBroker 7.1.1はテスト済で、推奨の最小バージョンです。 |
PBRUN認証ユーティリティを使用する場合、デプロイメント・プロシージャを編集する前に、/etc/pb.confファイルを更新して、通常ユーザーがデプロイメント・プロシージャを実行する権限を持つ別のユーザーに切り替えられるようにします。PowerBrokerのサンプル構成ファイル(/etc/pb.conf)には、次のサンプルが含まれています。
サンプル:
if(user=="johndoe") if(command=="/u01/oracle/agent/sbin/nmosudo *" )
// /u01/oracle/agent/ Agent Home location
{
switch (requestuser)
{
case "root":
runuser="root";
break;
case "oracle":
runuser="oracle";
break;
default:
reject;
}
accept;
}
前述の例を使用すると、ユーザーjohndoeは、nmosudoを介してコンソールから渡されるすべてのコマンドをrootおよびoracleとして実行できます。構成の詳細は、sudoまたはPowerBrokerに関するドキュメントを参照してください。
Enterprise Managerでは、ホスト・ターゲット上で設定を直接作成するか、複数のホストに適用可能な権限委任設定テンプレートを作成することにより、権限委任設定を作成できます。
VIEW: これらのホスト・ターゲットに対する表示権限を持っている管理者は、その権限委任設定を表示できます。
FULL: ホスト・ターゲットに対するFULL権限を持っている管理者は、そのホストに対する権限委任設定を作成できます。
Enterprise Managerスーパー管理者は、どのホスト・ターゲットに対する権限委任設定でも構成できます。
次の方法を使用して、権限委任の使用を起動できます。
Cloud Controlコンソール
EM CLI
権限委任テンプレート
権限委任テンプレート: Enterprise Managerでは、デフォルトの権限委任テンプレートの設定およびテンプレートの複数ホストへの適用もできます。これにより、特に同じ権限委任設定がすべてのホスト・ターゲットに適用されている場合に、管理者はホストごとに権限委任設定を適用する必要がなくなります。この機能は、多くのホスト・ターゲットがEnterprise Managerに同時に追加される場合に特に便利です。この機能は、set_default_privilege_delegation_setting動詞を使用することによって、EM CLIで使用することも可能です。
Cloud Controlからの権限委任の設定
Cloud Controlコンソールから権限委任を設定する手順は、次のとおりです。
「設定」メニューから、「セキュリティ」、「権限委任」の順に選択します。
「権限委任設定の管理」ページで、ホスト名を選択してから「編集」をクリックします。ホスト権限委任の編集ダイアログが表示されます。
「Sudo」または「PowerBroker」を選択し、SUDOまたはPowerBrokerが配置された場所(PowerBrokerの場合、オプションでパスワード・プロンプトを指定できます)を指定して、権限委任設定を使用したホストの構成を行います。
「保存」をクリックします。
権限委任設定は、ホスト単位で適用することも、同時に複数のホストに適用することもできます。Enterprise Managerでは、権限委任の設定を複数のホストに適用するデフォルトの権限委任テンプレートを定義できます。テンプレートは、多くのホスト・ターゲットがEnterprise Managerに同時に追加される場合に特に便利です。この機能は、EM CLIを介してset_default_privilege_delegation_setting動詞を使用して利用することも可能です。詳細は、「EM CLIを介した権限委任の設定」を参照してください。
Cloud Controlで、「設定」メニューから「セキュリティ」、「権限委任」の順に選択します。「権限委任の管理」ページが表示されます。
「テンプレート」タブをクリックして、権限委任の管理テンプレート・ページを表示します。
「作成」をクリックします。「テンプレートの作成」ダイアログが表示されます。
権限委任タイプ(SudoまたはPowerBroker)を選択します。
テンプレートの名前を入力し、SUDOまたはPowerBrokerが配置された場所(PowerBrokerの場合、オプションでパスワード・プロンプトを指定できます)を指定して、「保存」をクリックします。
たとえば、SUDOを選択し、sudoが/usr/sbin/ディレクトリに配置されている場合、「sudoコマンド」フィールドに/usr/sbin/sudo -E -u %RUNAS% %COMMAND%と入力する必要があります。
|
注意: 権限委任テンプレートをターゲットに適用しない場合、およびデプロイメント・プロシージャの手順を権限委任モードで実行するように構成する場合、そのターゲット用のデプロイメント・プロシージャはその手順を通常モードで実行します。 |
権限委任設定を作成したら、選択したターゲットにこの設定を適用する必要があります。この設定はもう1つのホストやコンポジット(グループ)・ターゲットに適用できます(グループには少なくとも1つのホスト・ターゲットが含まれている必要があります)。Cloud Controlコンソールを使用して、権限委任設定を適用できます。「設定」メニューで、「セキュリティ」、「権限委任」の順に選択します。
次の例では、sudo_settingという名前の設定を作成します。設定のタイプはSUDOで、使用するsudoパスは/usr/local/bin/sudoです。sudo引数は次のとおりです。
-S-u %RUNAS%%COMMAND%
例1: コマンドライン
emcli create_privilege_delegation_setting
-setting_name=sudo_setting
-setting_type=SUDO
-settings="SETTINGS:/usr/local/bin/sudo -S -u %RUNAS% %COMMAND%"
例2 - スクリプトおよび対話形式
create_privilege_delegation_setting
(setting_name="sudo_setting",
setting_type="SUDO",
settings="SETTINGS:/usr/local/bin/sudo -S -u %RUNAS% %COMMAND%")
次の例では、pb_settingという名前の設定を作成します。設定のタイプはPOWERBROKERで、使用するPowerBrokerパスは/etc/pbrunです。引数は次のとおりです。
%RUNAS%%PROFILE%%COMMAND%
例3: コマンドライン
emcli create_privilege_delegation_setting
-setting_name="pb_setting"
-setting_type="POWERBROKER"
-settings="SETTINGS,/etc/pbrun %RUNAS% %PROFILE% %COMMAND%"
-separator="settings=;"
-subseparator="settings=,"
例4 - スクリプトおよび対話形式
create_privilege_delegation_setting
(setting_name=pb_setting
,setting_type=POWERBROKER
,settings="SETTINGS,/etc/pbrun %RUNAS% %PROFILE% %COMMAND%"
,separator="settings=;"
,subseparator="settings=,")
次の例は、例3および4に似ていますが、さらにPASSWORD_PROMPT_STRINGとパスワードも追加しています。
例5: コマンドライン
emcli create_privilege_delegation_setting
-setting_name="pb_setting"
-setting_type="POWERBROKER"
-settings="SETTINGS,/etc/pbrun %RUNAS% %PROFILE% %COMMAND%";
PASSWORD_PROMPT_STRING,password:"
-separator="settings=;"
-subseparator="settings=,"
例6 - スクリプトおよび対話形式
create_privilege_delegation_setting
(setting_name=pb_setting
,setting_type=POWERBROKER
,settings="SETTINGS,/etc/pbrun %RUNAS% %PROFILE% %COMMAND%";
PASSWORD_PROMPT_STRING,password:"
,separator="settings=;"
,subseparator="settings=,")
権限委任テンプレートの作成後、デプロイメント・プロシージャの適用前に、権限委任設定をテストすることをお薦めします。
次の例で、資格証明を優先資格証明として登録し、さらに別のユーザーとして実行するように選択し、コマンドが通常ユーザーとして、または権限委任メカニズムを使用して別のユーザーとして実行されているかをチェックするジョブを作成することで設定をテストできる方法を説明します。
Cloud Controlで、「設定」メニューから「セキュリティ」、「優先資格証明」の順に選択します。「優先資格証明」ページが表示されます。
権限委任設定の管理ページの「関連リンク」セクションで「優先資格証明」をクリックします。
「ターゲット・タイプ」リストから「ホスト」を選択し、「優先資格証明の管理」をクリックします。「ホスト優先資格証明」ページが表示されます。
「ターゲット優先資格証明」リージョンから「ホスト」を選択し、「設定」をクリックします。
「名前付き資格証明の選択」ダイアログ・ボックスで、通常ユーザー名、通常パスワード、および権限委任メカニズムを使用して切り替えたいユーザー名として「実行」を指定します。次に、「テスト」、「保存」を順にクリックします。
優先資格証明として資格証明を登録した後、「エンタープライズ」メニューから「ジョブ」を選択し、「ジョブ・アクティビティ」をクリックします。
「ジョブ・アクティビティ」ページで「ジョブの作成」リストから「OSコマンド」を選択し、「実行」をクリックします。
OSコマンドのジョブの作成ページの「一般」タブに、ジョブの名前を指定します。次に、「ターゲット」セクションから「追加」をクリックし、OSコマンドを実行するホストを追加します。
「パラメータ」タブで「コマンド」にコマンドidを指定します。
「発行」をクリックします。
「ジョブ・アクティビティ」ページで、作成したジョブ名をクリックします。ジョブのステータスが表示されます。「ステータス」列をクリックしてその結果を表示します。
Cloud Controlは、優先資格証明で参照されるユーザーとしてコマンドを実行します。
Cloud Controlからエージェント制御操作(エージェントの起動、停止など)を実行すると、Enterprise Managerは、操作を行うためにエージェントがインストールされているマシンへのセキュア・シェル(SSH)接続を作成します。Enterprise Managerリリース12.1.0.4以降、エージェント制御操作はSudoまたはPowerBroker資格証明を使用して実行できます。たとえば、管理者はエージェントのホームページに移動して、「エージェント」メニューからエージェント制御操作を実行できます。
sudoを使用することで、許可されているユーザーは、sudoの構成ファイル(通常/etc/sudoersにある)で定義されているセキュリティ・ポリシーで指定されているsuperユーザーまたは他のユーザーとしてコマンドを実行できます。コマンド起動元のユーザーがrootである、またはターゲット・ユーザーがコマンド起動元のユーザーと同じ場合は、パスワードが不要です。そうでない場合はデフォルト時、ユーザーはパスワードを使用して自分自身の認証を実行する必要があります。ユーザーが認証されると、タイムスタンプが更新され、ユーザーはパスワードなしで短期間(/etc/sudoersファイル内で上書きされないかぎり5分間)sudoを使用できます。sudoは、/etc/sudoersファイルを確認して、許可されているユーザーを特定します(このファイルは特定のコマンドへのsudoアクセスを指定するようにも構成できます)。
Enterprise Managerでは、ホスト・ターゲット上で設定を直接作成するか、複数のホストに適用可能な権限委任設定テンプレートを作成することにより、権限委任設定を作成できます。
ホスト・ターゲットに対するFULL権限を持っている管理者は、そのホストに対する権限委任設定を作成できます。これらのホスト・ターゲットに対する表示権限を持っている管理者は、その権限委任設定を表示できます。Enterprise Managerスーパー管理者は、どのホスト・ターゲットに対する権限委任設定でも構成できます。
ホスト上で権限委任設定を直接作成する手順は、次のとおりです。
「設定」メニューから、「セキュリティ」、「権限委任」の順に選択します。「権限委任の管理」画面が表示されます。
表からホストを選択し、「編集」をクリックします。「ホスト権限委任設定の編集」ダイアログが表示されます。
権限委任タイプ(sudoまたはPowerBroker)を選択します。
使用する権限委任コマンドを入力します。PowerBrokerの場合、オプションの「パスワード・プロンプト」を入力します。
「保存」をクリックし、設定をホストに適用します。次の図は、PowerBroker設定のための「ホスト権限委任設定」ダイアログを示しています。
権限委任設定を作成したら、選択したターゲットにこの設定を適用する必要があります。この設定はもう1つのホストやコンポジット(グループ)・ターゲットに適用できます(グループには少なくとも1つのホスト・ターゲットが含まれている必要があります)。Cloud Controlコンソールを使用して、権限委任設定を適用できます。「設定」メニューで、「セキュリティ」、「権限委任」の順に選択します。
Enterprise Managerでは、機密データの完全性を守るためにemkeyと呼ばれるサイン・オン検証方法が使用されます。暗号化鍵は、リポジトリに格納されているパスワードや優先資格証明などの機密データの暗号化/復号化に使用されるマスター・キーです。emkeyはリポジトリの作成時間に生成され、最初はリポジトリ・データベースに保存されます。初めてOMSをインストールする際、emkeyは資格証明ストアにコピーされ、リポジトリから削除されます(emkeyは初めから保護されています)。バックアップは、OMS_ORACLE_HOME/sysman/config/emkey.oraに作成されます。
emkeyが破損したりバックアップemkey.oraファイルが消失した場合、リポジトリ内の暗号化されたデータはすべて使用不可になります。このため、OMSマシンがクラッシュしたりemkeyが破損した場合に、バックアップしたファイルを使用して環境をリカバリできるように、このファイルのバックアップを他のマシンに作成することを強くお薦めします。
起動時、OMSはemkeyを資格証明ストアとリポジトリから読み取ります。emkeyが見つからない場合または破損している場合、起動に失敗します。鍵をEnterprise Managerスキーマとは別に保管することで、スキーマの所有者およびSYSDBAユーザー(データベースのメンテナンス・タスクを行える特権ユーザー)が、リポジトリ内の名前付き資格証明などの機密データにアクセスできないようにします。さらに、鍵をスキーマとは別にすることで、リポジトリ・バックアップはアクセスされても、機密データはアクセスされないようにします。また、スキーマの所有者は、OMS/リポジトリOracleホームにアクセスできないようにします。
リポジトリ暗号化アルゴリズム
Enterprise Manager Cloud Controlリリース12.1.0.2以降、Advanced Encryption Standard (AES)アルゴリズムがEnterprise Managerリポジトリでのデータの暗号化に使用されます。暗号化鍵のサイズは256ビットです。
リリース12.1.0.2より前は、Triple Data Encryption Standard (3DES)がリポジトリ・データの暗号化に使用されていた暗号化アルゴリズムでした。
emkeyは、ホストのパスワード、データベースのパスワードなど、Enterprise Manager内の機密性の高いデータを暗号化および複合化するために使用される暗号化キーです。emkey.oraファイルはemkeyのコピーで、リストアのために安全な場所に保存しておく必要があります。
起動時に、Oracle Management Serviceは、emkeyのステータスを確認します。emkeyが適切に構成されている場合、OMSはこれを暗号化および複合化データに使用します。emkeyが適切に構成されていない場合、次のエラー・メッセージが表示されます。
Oracle Enterprise Manager 12c Release 3 Cloud Control Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. emctl start oms Starting HTTP Server ... Starting Oracle Management Server ... Checking Oracle Management Server Status ... Oracle Management Server is not functioning because of the following reason: The Em Key is not configured properly. Run "emctl status emkey" for more details.
emkeyに関連するemctlコマンドを次に示します。
emctl status emkey [-sysman_pwd <パスワード>]
emctl config emkey -copy_to_credstore [-sysman_pwd <パスワード>]
emctl config emkey -remove_from_repos [-sysman_pwd <パスワード>]
emctl config emkey -copy_to_file_from_credstore -admin_host <ホスト> -admin_port <ポート> -admin_user <ユーザー名> [-admin_pwd <パスワード>] [-repos_pwd <パスワード>] -emkey_file <emkeyファイル>
emctl config emkey -copy_to_file_from_repos (-repos_host <ホスト> -repos_port <ポート> -repos_sid <SID> | -repos_conndesc <接続記述子>) -repos_user <ユーザー名> [-repos_pwd <パスワード>] [-admin_pwd <パスワード>] -emkey_file <emkeyファイル>
emctl config emkey -copy_to_credstore_from_file -admin_host <ホスト> -admin_port <ポート> -admin_user <ユーザー名> [-admin_pwd <パスワード>] [-repos_pwd <パスワード>] -emkey_file <emkeyファイル>
emctl config emkey -copy_to_repos_from_file (-repos_host <ホスト> -repos_port <ポート> -repos_sid <SID> | -repos_conndesc <接続記述子>) -repos_user <ユーザー名> [-repos_pwd <パスワード>] [-admin_pwd <パスワード>] -emkey_file <emkeyファイル>
例: 使用している環境がサービス名で構成されている場合は例1を使用します。その他のすべての場合は例2を使用します。
Example 1 emctl config emkey -copy_to_repos_from_file -repos_conndesc '"(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<>)(PORT=<>)))(CONNECT_DATA=(SERVICE_NAME=<>)))"' -repos_user <> [-repos_pwd <pwd> ] [-admin_pwd <pwd>] -emkey_file < emkey file> Example 2 emctl config emkey -copy_to_repos_from_file -repos_host <host> -repos_port <port> -repos_sid <sid> -repos_user <username> [-repos_pwd <pwd> ] [-admin_pwd <pwd>] -emkey_file <emkey file>
このコマンドは、emkeyの状態またはステータスを示します。emkeyのステータスに応じて、次のメッセージが表示されます。
emkeyが資格証明ストアおよびリポジトリで正しく構成されている場合、次のメッセージが表示されます。
emkeyが資格証明ストアで正しく構成され、管理リポジトリから削除されている場合、次のメッセージが表示されます。
emkeyが資格証明ストアで破損し、管理リポジトリから削除されている場合、次のメッセージが表示されます。
例2-15 emctl status emkey - 例3
Oracle Enterprise Manager 12c Release 3 Cloud Control Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. The EMKey is not configured properly or is corrupted in the credential store and does not exist in the Management Repository. To correct the problem: 1) Get the backed up emkey.ora file. 2) Configure the emkey by running "emctl config emkey -copy_to_credstore_from_file"
このコマンドは、emkeyを資格証明ストアから指定のファイルにコピーします。
例2-17 emctl config emkey -copy_to_file_from_credstoreコマンドの出力例
emctl config emkey -copy_to_file_from_credstore -admin_host <host> -admin_port <port> -admin_user <username> [-admin_pwd <pwd>] [-repos_pwd <pwd>] -emkey_file <emkey file> Oracle Enterprise Manager 12c Release 3 Cloud Control Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. The EMKey has been copied to file.
このコマンドは、emkeyを管理リポジトリから指定のファイルにコピーします。
例2-18 emctl config emkey -copy_to_file_from_reposコマンドの出力例
emctl config emkey -copy_to_file_from_repos (-repos_host <host> -repos_port <port> -repos_sid <sid> | -repos_conndesc <conn desc>) -repos_user <username> [-repos_pwd <pwd>] [-admin_pwd <pwd>] -emkey_file <emkey file> Oracle Enterprise Manager 12c Release 3 Cloud Control Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. The EMKey has been copied to file.
注意: repos_host、repos_port、repos_sidまたはrepos_conndescのいずれかを指定する必要があります。
このコマンドはemkeyをリポジトリから削除します。これは、すぐに使用できるように構成されているemkeyを保護します。
例2-19 emctl config emkey -copy_to_credstore_from_fileコマンドの出力例
emctl config emkey -copy_to_credstore_from_file -admin_host <host> -admin_port <port> -admin_user <username> [-admin_pwd <pwd>] [-repos_pwd <pwd>] -emkey_file <emkey file> Oracle Enterprise Manager 12c Release 3 Cloud Control Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. The EMKey has been copied to the Credential Store.
このコマンドは、emkeyを指定のファイルからリポジトリにコピーします。
例2-20 emctl config emkey -copy_to_repos_from_fileコマンドの出力例
emctl config emkey -copy_to_repos_from_file (-repos_host <host> -repos_port <port> -repos_sid <sid> | -repos_conndesc <conn desc>) -repos_user <username> [-repos_pwd <pwd>] [-admin_pwd <pwd>] -emkey_file <emkey file> Oracle Enterprise Manager 12c Release 3 Cloud Control Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. The EMKey has been copied to the Management Repository. This operation will cause the EMKey to become unsecure. After the required operation has been completed, secure the EMKey by running "emctl config emkey -remove_from_repos".
このコマンドは、リポジトリからemkeyを削除します。
例2-21 emctl config emkey -remove_from_reposコマンドの出力例
emctl config emkey -remove_from_repos [-sysman_pwd <pwd>] Oracle Enterprise Manager 12c Release 3 Cloud Control Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. The EMKey has been removed from the Management Repository.
|
注意: emkeyが資格証明ストア内で破損している場合、管理リポジトリから削除できません。 |
この項では、emkeyのシナリオのインストールとアップグレードについて説明します。
Oracle Management Serviceをインストールすると、インストーラはemkeyを資格証明ストアにコピーして、リポジトリからemkeyを削除します(emkeyはすぐに保護されます)。
管理リポジトリは通常どおりアップグレードされます。OMSのアップグレード時に、omsca (OMSコンフィギュレーション・アシスタント)はemkeyを資格証明ストアにコピーし、リポジトリから削除します。omscaは古いOMS Oracleホームにあるemkey.oraファイルからemkeyを読み込み、資格証明ストアにコピーします。
|
注意: バージョン12.1より前は、アップグレードを開始する前に、emkeyを管理リポジトリにコピーする必要があります。Oracle Management Serviceをアップグレードすると、emkeyを保護できます(つまり、次のコマンドを実行して管理リポジトリからemkeyを削除します)。
バージョン12.1以降は、再インストール・チェックが導入され、この手順はアップグレードの際に実行されます。 |
管理リポジトリを再作成すると、新しいemkeyが生成されます。この新しい鍵は、資格証明ストア内の既存のemkeyと同期しません。鍵を同期するには、次の手順を実行します。
新しいemkeyを資格証明ストアにコピーするには、emctl config emkey -copy_to_credstoreコマンドを使用します。
バックアップを作成するには、emctl config emkey -copy_to_file_from_reposコマンドまたはemctl config emkey -copy_to_file_from_credstoreコマンドを入力します。
emkeyを保護するには、emctl config emkey -remove_from_reposコマンドを使用します。
ユーザーの作成、権限の付与、パッチまたはクローニングのようなリモート・ジョブの起動など、Enterprise Managerユーザーによって実行されるすべての操作は、Sarbanes-Oxley Act of 2002(SAS 70)に準拠していることを確認するために、監査を受ける必要があります。この法令は、サービス組織の契約に基づく内部統制を評価するために監査者が使用する基準を定義するものです。操作の監査を行うことで、管理者は問題を監視、検出および調査し、エンタープライズ全体にセキュリティ・ポリシーを強制できます。
ユーザーがどのようにEnterprise Managerにログインしたかに関係なく、監査が有効になっている場合は各ユーザー・アクションが監査され、監査の詳細が記録されます。
Enterprise Manager 12cでは、BASIC監査がデフォルトで有効になっているため、資格証明の作成、編集、アクセス、関連付けおよび削除の監査証跡が作成されます。名前付き資格証明は、権限を付与したり、取り消すことができる第1級のセキュリティ・オブジェクトです。つまり、複数のEnterprise Manager管理者が資格証明オブジェクトを使用および変更できます。資格証明は、システムで様々な操作を行うために使用される機密データであるため、資格証明に対する操作を監査する必要があります。
Enterprise Mangerではすべての資格証明操作の監査をサポートしていますが、最初に有効にする必要があります。監査情報には、現在のユーザー名、資格証明名、行われた操作、操作ステータス(成功または失敗)などがあります(これら以外にもあります)。監査ログには、資格証明の所有者、アクションの開始者、資格証明名、ユーザー名、ターゲット名、ジョブ名および操作の日時に関する情報が含まれます。パスワードや秘密鍵などの資格証明のフィールドは記録されません。
次の操作が監査されます。
名前付き資格証明の作成: 新規Enterprise Manager資格証明の作成が監査されます。
名前付き資格証明の編集: 資格証明の編集には、ユーザー名や機密性の高い資格証明の属性の変更が含まれる場合があります。資格証明の編集には、資格証明の認証スキームの変更も含まれる場合があります。
名前付き資格証明の削除: 資格証明のEnterprise Managerからの削除が監査されます。
名前付き資格証明の関連付け: 名前付き資格証明は、資格証明セットの優先資格証明としてターゲット・レベルまたはターゲット・タイプ・レベルで設定できます。名前付き資格証明は、ジョブから直接参照することもできます。名前付き資格証明の優先資格証明としての設定およびジョブまたはデプロイメント・プロシージャでの使用に伴うすべての操作が監査されます。
名前付き資格証明へのアクセス: Enterprise Managerサブシステムでは、様々なシステム管理タスクを行うために資格証明ストアから資格証明をリクエストします。
デフォルトでは、ユーザーがEnterprise Managerのログインまたはログアウトを行うたびに、アクションが監査されます。次のリストでは、デフォルトで監査されるEnterprise Managerインフラストラクチャ操作を示します。
更新の適用
MGMT_VIEWユーザー・パスワードの変更
リポジトリ・パスワードの変更
認証の構成
リポジトリへのEMキーのコピー
リポジトリからのEMキーの削除
カスタムCAの作成
更新の削除
セキュア・コンソール
ロックの保護
OMSの保護
次のEM CLIコマンドを使用して、Enterprise Manager監査システムを構成できます。
enable_audit: すべてのユーザー操作に対して監査を有効にします。
disable_audit: すべてのユーザー操作に対して監査を無効にします。
show_operations_list: 監査対象のユーザー操作のリストを表示します。
show_audit_settings: 監査ステータス、操作リスト、外部化サービスの詳細およびパージ期間の詳細を表示します。
update_audit_settings: リポジトリの現在の監査設定を更新します。
監査データは、数年間保護および保管する必要があります。監査データは非常に大量になる可能性があり、システムのパフォーマンスに影響を与える場合があります。リポジトリに保存されるデータの量を制限するために、定期的に監査データを外部化するかアーカイブする必要があります。アーカイブされた監査データは、ODL形式に準拠したXMLファイルで保存されます。監査データを外部化するには、EM_AUDIT_EXTERNALIZATION APIが使用されます。<ファイルの接頭辞>.NNNNN.xmlというフォーマットのレコード(NNNNは番号)が生成されます。番号は00001から99999までが使用されます。
update_audit_setting -externalization_switchコマンドを使用して、監査データをファイルシステムにエクスポートするように監査外部化サービスを設定できます。
EM監査外部化サービス・ジョブによって、監査システム・データの外部化が実行されます。デフォルトでは、このジョブは毎日1回実行されるようにスケジュールされています。次の図に示すように、Enterprise Managerコンソールの「リポジトリ・スケジューラ・ジョブ・ステータス」領域で、このジョブの現在のステータスを表示できます。
このページにアクセスするには、「設定」メニューから「Cloud Controlの管理」、「リポジトリ」の順に選択します。
update_audit_settingsコマンドは、リポジトリの現在の監査設定を更新して管理サービスを再起動します。
例2-22 update_audit_settingコマンドの使用方法
emcli update_audit_settings
-audit_switch="ENABLE/DISABLE"
-operations_to_enable="name of the operations to enable, for all oprtations
use ALL"
-operations_to_disable="name of the operations to disable, for all
oprtations use ALL"
-externalization_switch="ENABLE/DISABLE"
-directory_name="directory_name (DB Directory)"
-file_prefix="file_prefix"
-file_size="file_size (Bytes)"
-data_retention_period="data_retention_period (Days)"
-audit_switch: Enterprise Managerでの監査を有効にします。可能な値はENABLE/DISABLEです。デフォルト値はDISABLEです。
-operations_to_enable: 指定した操作の監査を有効にします。すべての操作を有効にするにはAllを入力します。
-operations_to_disable: 指定した操作の監査を無効にします。すべての操作を無効にするにはAllを入力します。
-externalization_switch: 監査データのエクスポート・サービスを有効にします。可能な値はENABLE/DISABLEです。デフォルト値はDISABLEです。
-directory: エクスポート・サービスが監査データ・ファイルをアーカイブするOSディレクトリにマップされるデータベース・ディレクトリ。
-file_prefix: 監査データが格納されるファイルを作成する際にエクスポート・サービスで使用するファイルの接頭辞。
-file_size: 監査データが格納されるファイルのサイズ。デフォルト値は5000000バイトです。
data_retention_period: 監査データがリポジトリ内に保持される期間です。デフォルト値は365日です。
指定した期間内に生成された監査データを検索できます。次のような検索も可能です。
特定のユーザー操作またはすべてのユーザー操作に関する監査の詳細。
成功または失敗のステータスを持つ操作またはすべての操作に関する監査の詳細。
「設定」メニューから、「セキュリティ」、「監査データ」の順に選択します。「監査データ」ページが表示されます。フィールドに検索条件を指定し、「実行」をクリックします。結果が「サマリー」表に表示されます。
検索条件と一致するレコードごとの詳細を表示するには、「表示」ドロップダウン・リストから「詳細」を選択します。レコードの完全な詳細にドリルダウンするには、「タイムスタンプ」をクリックします。
Enterprise Managerでサポートされる監査操作の完全なリストは、EM CLI show_operations_list動詞を使用してください。
Operation ID Operation Name Infrastructure Operation ADD_AGENT_REGISTRATION_PASSWORD Add Registration Password NO ADD_CS_TARGET_ASSOC Add Standard-Target Association NO SECURITY_AUTH_CONFIG Configure Authentication YES
.
.
.
UPDATE_PASSWORD Update Password NO
Oracle Enterprise Manger Cloud Controlリリース3から。Enterprise Managerでは、基本およびインフラストラクチャ監査がデフォルトで有効になっています。Enterprise Managerには、150個を超える監査用オプションがあります。監査インフラストラクチャ操作は常に有効で無効にはできません。強化された「監査中」ページでは、定期的に付与される権限を容易に確認でき、どのユーザーがどの権限を行使したかを追跡できるため、ユーザー・アカウンタビリティが向上します。インフラストラクチャ・アクティビティはすぐに監査され、これらには更新、ダウンロード、OMSパスワードの変更およびemkeyのコピーおよびリポジトリからの削除が含まれます。
また、Cloud Controlコンソールからのすべての監査アクションの検索機能が強化されて向上し、監査操作のサブセットを検索したり、特定のクライアント・ホストおよびクライアント・タイプ(ブラウザまたはCLI)からの操作をフィルタリングして確認できます。これにより、監査担当者は効果的な方法で対象の特定操作を検索できます。
次の表に監査可能なすべてのイベントを示します。有効として表示されている監査可能イベントはインフラストラクチャ監査イベントで、デフォルトで有効に設定されており無効にすることはできません。
表2-4 監査可能なイベント
| イベント | 有効/無効(デフォルト) |
|---|---|
|
更新の適用 |
有効 |
|
MGMT_VIEWユーザー・パスワードの変更 |
有効 |
|
リポジトリ・パスワードの変更 |
有効 |
|
認証の構成 |
有効 |
|
Enterprise Managerキーをリポジトリにコピー |
有効 |
|
カスタムCAの作成 |
有効 |
|
Enterprise Managerにログイン |
有効 |
|
Enterprise Managerをログアウト |
有効 |
|
Enterprise Managerキーをリポジトリから削除 |
有効 |
|
更新の削除 |
有効 |
|
セキュア・コンソール |
有効 |
|
ロックの保護 |
有効 |
|
OMSの保護 |
有効 |
|
WebLogic Serverの保護 |
有効 |
|
名前付き資格証明へのアクセス |
無効 |
|
登録パスワードの追加 |
無効 |
|
ソフトウェア・ライブラリの記憶域の追加 |
無効 |
|
標準-ターゲット・アソシエーションの追加 |
無効 |
|
エンティティのテンプレート・コレクションへの追加 |
無効 |
|
監視テンプレートの適用 |
無効 |
|
テンプレート・コレクションを管理グループに関連付け |
無効 |
|
メトリック拡張のアタッチ |
無効 |
|
監査エクスポート設定 |
無効 |
|
監査設定 |
無効 |
|
コネクタ設定の変更 |
無効 |
|
パスワードの変更 |
無効 |
|
優先資格証明の変更 |
無効 |
|
手動ルール違反のクリア |
無効 |
|
コネクタの構成 |
無効 |
|
管理グループの作成 |
無効 |
|
変更管理設定の作成 |
無効 |
|
コネクタの作成 |
無効 |
|
資格証明セットの作成 |
無効 |
|
カスタム構成の仕様の作成 |
無効 |
|
カスタム構成仕様パーサーの作成 |
無効 |
|
カスタム・ターゲット・タイプの作成 |
無効 |
|
ファセットの作成 |
無効 |
|
ファセット・パラメータの作成 |
無効 |
|
ファセット・パターンの作成 |
無効 |
|
フレームワークの作成 |
無効 |
|
メトリック拡張の作成 |
無効 |
|
モニタリング・テンプレートの作成 |
無効 |
|
名前付き資格証明の作成 |
無効 |
|
リアルタイム・モニタリング・ルールの作成 |
無効 |
|
解決状態の作成 |
無効 |
|
ロールの作成 |
無効 |
|
ルールの作成 |
無効 |
|
ルール・セットの作成 |
無効 |
|
標準の作成 |
無効 |
|
テンプレート・コレクションの作成 |
無効 |
|
ユーザーの作成 |
無効 |
|
データベース・ログイン |
無効 |
|
データベース・ログアウト |
無効 |
|
データベースの再起動 |
無効 |
|
データベースの停止 |
無効 |
|
データベースの起動 |
無効 |
|
管理グループの削除 |
無効 |
|
資格証明セットの削除 |
無効 |
|
カスタム構成の仕様の削除 |
無効 |
|
カスタム構成仕様パーサーの削除 |
無効 |
|
ファセットの削除 |
無効 |
|
ファセット・パラメータの削除 |
無効 |
|
ファセット・パターンの削除 |
無効 |
|
フレームワークの削除 |
無効 |
|
ジョブの削除 |
無効 |
|
管理コネクタの削除 |
無効 |
|
メトリック拡張の削除 |
無効 |
|
モニタリング・テンプレートの削除 |
無効 |
|
名前付き資格証明の削除 |
無効 |
|
リアルタイム・モニタリング・ルールの削除 |
無効 |
|
登録パスワードの削除 |
無効 |
|
解決状態の削除 |
無効 |
|
ロールの削除 |
無効 |
|
ルールの削除 |
無効 |
|
ルール・セットの削除 |
無効 |
|
ソフトウェア・ライブラリ・エンティティの削除 |
無効 |
|
ソフトウェア・ライブラリ・フォルダの削除 |
無効 |
|
標準の削除 |
無効 |
|
ターゲットの削除 |
無効 |
|
テンプレート・コレクションの削除 |
無効 |
|
更新の削除 |
無効 |
|
ユーザーの削除 |
無効 |
|
カスタム構成の仕様のデプロイ |
無効 |
|
メトリック拡張のデタッチ |
無効 |
|
ルールの無効化 |
無効 |
|
ルール・セットの無効化 |
無効 |
|
標準-ターゲット・アソシエーションの無効化 |
無効 |
|
管理グループからテンプレート・コレクションの関連付けを解除 |
無効 |
|
更新のダウンロード |
無効 |
|
フレームワークの編集 |
無効 |
|
ジョブの編集 |
無効 |
|
モニタリング・テンプレートの編集 |
無効 |
|
登録パスワードの編集 |
無効 |
|
ルールの編集 |
無効 |
|
ルール・セットの編集 |
無効 |
|
標準の編集 |
無効 |
|
標準-ターゲット・アソシエーションの編集 |
無効 |
|
テンプレート・コレクションの編集 |
無効 |
|
ルールの有効化 |
無効 |
|
ルール・セットの有効化 |
無効 |
|
標準-ターゲット・アソシエーションの有効化 |
無効 |
|
エージェントとしてコマンドを実行 |
無効 |
|
ファイル転送ジョブ |
無効 |
|
ファイル取得ジョブ |
無効 |
|
権限の付与 |
無効 |
|
ロールの付与 |
無効 |
|
ファセットのインポート |
無効 |
|
フレームワークのインポート |
無効 |
|
リアルタイム・モニタリング・ルールのインポート |
無効 |
|
ルールのインポート |
無効 |
|
標準のインポート |
無効 |
|
アクションをモニターに含める |
無効 |
|
フィルタ・ファセットを含める |
無効 |
|
モニタリング・ファセットを含める |
無効 |
|
ジョブ実行処理 |
無効 |
|
情報更新を既読としてマーク |
無効 |
|
管理グループの変更 |
無効 |
|
変更管理設定の変更 |
無効 |
|
カスタム構成の仕様の変更 |
無効 |
|
ファセットの変更 |
無効 |
|
ファセット・コンテンツの変更 |
無効 |
|
ファセット・パラメータの変更 |
無効 |
|
ファセット・パターンの変更 |
無効 |
|
メトリック設定の変更 |
無効 |
|
名前付き資格証明の変更 |
無効 |
|
リアルタイム・モニタリング・ルールの変更 |
無効 |
|
解決状態の変更 |
無効 |
|
ロールの変更 |
無効 |
|
ユーザーの変更 |
無効 |
|
ソフトウェア・ライブラリ・エンティティの移動 |
無効 |
|
メトリック拡張の公開 |
無効 |
|
ソフトウェア・ライブラリの記憶域のパージ |
無効 |
|
エージェントとしてファイルを配置 |
無効 |
|
ファイル配置ジョブ |
無効 |
|
Enterprise Managerストアからのリフレッシュ |
無効 |
|
登録パスワードの使用 |
無効 |
|
リモート操作ジョブ |
無効 |
|
アクションをモニターから削除 |
無効 |
|
変更管理設定の削除 |
無効 |
|
フィルタ・ファセットの削除 |
無効 |
|
モニタリング・ファセットの削除 |
無効 |
|
権限委任設定の削除 |
無効 |
|
ソフトウェア・ライブラリの記憶域の削除 |
無効 |
|
標準-ターゲット・アソシエーションの削除 |
無効 |
|
エンティティのテンプレート・コレクションからの削除 |
無効 |
|
テンプレート・コレクションの名前の変更 |
無効 |
|
ルールの並替え |
無効 |
|
ルール・セットの並替え |
無効 |
|
ジョブの再開 |
無効 |
|
エージェントの再同期 |
無効 |
|
リポジトリの再同期 |
無効 |
|
ジョブの再試行 |
無効 |
|
権限の取消し |
無効 |
|
ロールの取消し |
無効 |
|
モニタリング設定の保存 |
無効 |
|
権限委任設定の設定 |
無効 |
|
ジョブの停止 |
無効 |
|
ジョブの発行 |
無効 |
|
更新サブスクライブ・タイプ |
無効 |
|
違反の抑止 |
無効 |
|
ジョブの一時停止 |
無効 |
|
ターゲット・ログイン |
無効 |
|
ターゲット・ログアウト |
無効 |
|
カスタム構成の仕様のアンデプロイ |
無効 |
|
更新サブスクライブ解除タイプ |
無効 |
|
違反の抑止解除 |
無効 |
|
データベース・パスワードの更新 |
無効 |
|
メトリック拡張の更新 |
無効 |
|
パスワードの更新 |
無効 |
|
更新があります |
無効 |
Enterprise Managerのコンポーネントとフレームワークに対してセキュリティを有効にした場合、セキュリティのその他の考慮事項があります。ここでは、次の内容について説明します。
この項では、SYSMANパスワードおよびMGMT_VIEWパスワードの変更に使用されるコマンドについて説明します。
SYSMANユーザー・アカウントは、Oracle Management Repositoryにログインして、すべてのアクティビティの格納および問合せを行うために、Oracle Management Serverによって使用されます。パスワードは暗号化されて格納されます。すべての操作で、Enterprise Manager Cloud Controlが適切に機能するために、SYSMANパスワードがOMRで変更された場合は、OMSでも変更する必要があります。
|
注意: 12c以降では、SYSMANのパスワード、または、リポジトリ・データベース上の他の任意のリポジトリ・ユーザーのパスワードを直接変更することは推奨しません。したがって、パスワードは次にリストする方法のいずれかを使用して変更してください。 |
emctl stop omsを使用して、すべてのOMSインスタンスを停止します。
OMS_Home/bin/emctl stop oms
BIPが構成されている場合: 次を実行することによって各マシンでBIPを停止します。
OMS_Home/bin/emctl stop oms -bip_only JVMDまたはADPあるいはその両方が構成されている場合は、JVMD/ADPエンジンを停止します。
emctl extended oms jvmd stop –all
emctl extended oms adp stop -all
プライマリOMSマシンも含め、すべてのOMSマシンで同じコマンドを実行します。この操作中も管理サーバーは稼働している必要があるので、「-all」は含めないでください。
SYSMANパスワードを変更します。
cd <OMS_HOME>/bin
emctl config oms -change_repos_pwd [-old_pwd <old_pwd>] [-new_pwd <new_pwd>] [-use_sys_pwd [-sys_pwd <sys_pwd>]]
emctl config oms -change_repos_pwd'
コマンドのパラメータ
| パラメータ | 説明 |
|---|---|
| -change_repos_pwd | SYSMANのパスワードの変更に使用されます。 |
-old_pwd |
現在のSYSMANパスワードです。 |
-new_pwd |
新しいパスワードです。 |
-use_sys_pwd |
このパラメータはオプションです。SYSユーザーとしてデータベースに接続する場合に使用されます。SYSMANアカウントが失効したり、ロックされた場合、このオプションを使用します。 |
-sys_pwd |
SYSユーザーのパスワードです。-use_sys_pwdが指定される場合にのみ必要です。 |
コマンドの動作
|
注意: 前述のコマンドは、SYSMANユーザーの現在のパスワードと新しいパスワードを要求します。 パスワードは、OMSおよびリポジトリ・ターゲット用に、リポジトリ・データベースおよび監視資格証明で変更されます。 SYSMANパスワードとともに、このコマンドはリポジトリ・データベースで作成されたパスワードをEMユーザー(SYSMAN_MDS、BIP、SYSMAN_OPSS、SYSMAN_APM、SYSMAN_RO)用に変更します。 |
コマンドの出力例:
emctl config oms -change_repos_pwd Oracle Enterprise Manager Cloud Control 12c Release 12.1.0.1.0 Copyright (c) 1996, 2011 Oracle Corporation. All rights reserved. Enter Repository User's Current Password : Enter Repository User's New Password : Changing passwords in backend ... Passwords changed in backend successfully. Updating repository password in Credential Store... Successfully updated Repository password in Credential Store. Restart all the OMSs using 'emctl stop oms -all' and 'emctl start oms'. Successfully changed repository password.
プライマリOMSマシン上の管理サーバーを停止してから、すべてのOMSを再起動します。
cd <OMS_HOME>/bin
emctl stop oms –all
すべての管理サービスを再起動します。
cd <OMS_HOME>/bin
emctl start oms
すべてのOMSを停止します。
cd <OMS_HOME>/bin
emctl stop oms
プライマリOMSマシンでも同じコマンドを実行します。この操作中も管理サーバーは稼働している必要があるので、「-all」は含めないでください。
SYSMANパスワードを変更します。
cd <OMS_HOME>/bin
emctl config oms -change_repos_pwd -use_sys_pwd -sys_pwd <sys user password> -new_pwd <new sysman password>
|
注意: 「-use_sys_pwd」は、SYSユーザーとしてデータベースに接続するために使用され、SYSMANパスワードをリポジトリ・データベース内で変更します。 現在のSYSMANパスワードは要求されず、新しいパスワードのみを入力するよう要求されます。これにより、古いパスワードが、入力した新しいパスワードに再設定されます。 パスワードは、OMSおよびリポジトリ・ターゲット用に、リポジトリ・データベースおよび監視資格証明で変更されます。 SYSMANパスワードとともに、このコマンドはリポジトリ・データベースで作成されたパスワードをEMユーザー(SYSMAN_MDS、BIP、SYSMAN_OPSS、SYSMAN_APM、SYSMAN_RO)用に変更します。 |
プライマリOMSマシン上の管理サーバーを停止してから、すべてのOMSを再起動します。
cd <OMS_HOME>/bin
emctl stop oms-all
emctl start oms
MGMT_VIEWユーザーのパスワードを変更するには、次のコマンドを使用します。
emctl config oms -change_view_user_pwd [-sysman_pwd <sysman_pwd>] [-user_pwd <user_pwd>] [-auto_generate]
| パラメータ | 説明 |
|---|---|
-change_view_user_pwd |
MGMT_VIEWユーザーのパスワードの変更に使用されます。 |
-sysman_pwd |
SYSMANユーザーのパスワード。 |
-user_pwd |
MGMT_VIEWユーザーの新規パスワード。 |
-auto_generate |
このオプションを指定する場合、パスワードは自動生成されます。 |
すべてのOMSを停止します。
<OMS_HOME>/bin/emctl stop oms
OMSのいずれかで次のコマンドを実行します。
<OMS_HOME>/bin/emctl config oms -change_view_user_pwd [-old_pwd <old_pwd>] [ -new_pwd <new_pwd>]
AdminServerとすべてのOMSを再起動します。
emctl stop oms-all
emctl start oms
Enterprise ManagerにHTTPSを介して接続する場合、管理サービスではブラウザに管理サービスのアイデンティティを確認する証明書が表示されます。この証明書は、使用しているコンピュータが信頼するサード・パーティにより検証されています。Webブラウザで信頼できない証明書が検出されると、セキュリティ・アラート・メッセージが生成されます。Enterprise Managerの証明書がブラウザに信頼されていない認証局によって発行されるため、セキュリティ・アラート・ダイアログ・ボックスが表示されます。
警告を無視して、Enterprise Managerセッションを継続することもできます。または、CA証明書をブラウザの信頼できる"ルート"証明書のリストにインポートして、以降のブラウザ・セッションで証明書のセキュリティ・アラートを排除できます。
次の高度なレベルの手順は、Enterprise Managerがサード・パーティの証明書を使用する設定に含まれます。
セキュリティは、管理サービスに対してデフォルトでは有効です。ただし、Web層の拡張セキュリティ機能を有効にしていない場合、「このWebサイトのセキュリティ証明書には問題があります。」という警告が表示されます。これは、Enterprise Managerの証明書がブラウザに信頼されていない認証局によって発行されるためです。
Internet Explorerに証明書の警告ページが表示された場合、次の手順で証明書をインストールし、今後Enterprise Managerセッションでこのページが再度表示されないようにします。
証明書の警告ページで、「このサイトの閲覧を続行する(推奨されません)。」をクリックします。
「はい」をクリックします。これより前のInternet Explorerセッションで「今後、この警告を表示しない」を選択していない場合、Internet Explorerは「セキュリティの警告」ダイアログを表示します。「OK」をクリックしてダイアログ・ボックスを閉じます。
Enterprise Managerコンソールのログオン・ページが表示されます。
ブラウザの最上部の「証明書のエラー」をクリックすると、「証明書」のポップアップが表示されます。
「証明書の表示」をクリックします。「証明書」ダイアログが表示されます。
「証明書のパス」タブをクリックし、次の図に示すような証明書のリストの最初のエントリを選択します。
「証明書の表示」をクリックして別の「証明書」ダイアログ・ボックスを表示します。
「証明書のインストール」をクリックして証明書のインポート・ウィザードを表示します。
ウィザードでデフォルトの設定を受け入れ、終了したら「完了」をクリックします。
Internet Explorerから、証明書をインストールするかどうかをたずねる「セキュリティの警告」が表示されます。「はい」をクリックします。証明書が正常にインポートされたことを示すメッセージがInternet Explorerから表示されます。
「OK」をクリックして各セキュリティ・ダイアログ・ボックスを終了し、「セキュリティの警告」ダイアログ・ボックスで「はい」をクリックしてブラウザ・セッションを続けます。
このブラウザを使用する場合のEnterprise Managerへの以降の接続で「セキュリティの警告」ダイアログ・ボックスが表示されなくなります。
Enterprise Managerの証明書がブラウザに信頼されていない認証局によって発行されると、Firefoxも接続の警告を発行します。Mozilla FirefoxでHTTPS URLを使用して初めてCloud Controlコンソールを表示すると、接続が信頼できないため、警告が表示されます。
Firefoxから「接続の安全性を確認できません」ページが表示された場合、次の手順で証明書をインストールし、今後Enterprise Managerセッションでこのページが再度表示されないようにします。
手順と情報を確認します。「危険性を理解した上で接続するには」をクリックします。Firefoxによって、詳細情報と証明書を追加するオプションが表示されます。
「例外を追加...」をクリックします。Firefoxによって、「セキュリティ例外の追加」ダイアログが表示されます。
「次回以降にもこの例外を有効にする」オプションが選択されていることを確認します。
現在のブラウザを使用する際に新しいサイト証明書ダイアログ・ボックスは表示されなくなります。
「セキュリティ例外を承認」をクリックします。Enterprise Managerコンソールが表示されます。
このブラウザを使用した以降のEnterprise Managerへの接続で、接続の安全性を確認できないという警告は表示されなくなりました。
Google Chromeでは、このWebのセキュリティ証明書が信頼できない場合、警告が表示されます。Google ChromeでHTTPS URLを使用して初めてCloud Controlコンソールを表示すると、接続が信頼できないため、警告が表示されます。
Google Chromeから「接続の安全性を確認できません」ページが表示された場合、次の手順で証明書をインストールし、今後Enterprise Managerセッションでこのページが再度表示されないようにします。
|
注意: Google Chromeでこの方法を使用して証明書をインストールすると、パフォーマンスの低下が生じることがあります。この問題を解決する最適なオプションは、選択したベンダーから信頼できる証明書を取得することです。 |
URLアドレス・バーの左側の×印の付いた南京錠アイコンをクリックします。
メニューの「証明書情報」をクリックします。
証明書のパス・タブを選択します。
OMSホスト名を選択します(赤い十字アイコン)。
「証明書の表示」をクリックします。
「詳細」タブを選択します。
「ファイルへコピー」をクリックします。
ウィザードに従って処理を行います。ウィザードに従い、すべてデフォルトのオプションを選択します。
デスクトップに証明書を保存します。たとえば、次のように保存できます。
adc1110000.cer
Google Chromeのニューから、「ツール」に移動し、「設定」をクリックして、「詳細設定を表示」を選択します。
「証明書の管理」をクリックします。
「信頼されたルート証明機関」タブを選択します。
「インポート」をクリックします。
ウィザードが保存された証明書のインポート・プロセスをガイドします。
インポートしている証明書が検証できないというメッセージが警告ウィンドウに表示され、続行するかどうか確認されます。次に進むには、「はい」をクリックします。
保存された証明書が「信頼されたルート証明機関」表に表示されているかどうかを確認します。
Google Chromeブラウザを再起動し、Enterprise Manager URLをロードします。証明書エラーアイコンがアドレス・バーに表示されていない場合、証明書は有効で信頼できます。
Safariでは、証明書を個別にインストールするオプションはサポートされません。この問題を解決するには、選択したベンダーから信頼できる証明書を取得することです。
