| Oracle® Enterprise Manager Cloud Controlセキュリティ・ガイド 12c リリース5 (12.1.0.5) E49736-06 |
|
 前 |
 次 |
この章では、Enterprise Managerを保護するためのガイドラインについて説明します。
Oracle Enterprise Managerのデプロイメントを保護するには、OMSおよびリポジトリが配置されている基礎となるオペレーティング・システムから、Enterprise Managerコンポーネント自体に至るまでのスタックのすべてのレイヤーを保護することが必要になります。ここで取り上げる推奨事項は、特定のDoS攻撃を防ぐだけでなく全体のセキュリティも強化します。
Linuxプラットフォーム上のrsh、rlogin、telnetおよびrexecなどの非保護サービスをすべて削除することによって、マシン自体を強化します(非保護サービスのリストおよび異なるプラットフォーム上でそれらを削除する方法については、CISベンチマークを参照してください)。また、必須ではないサービスを停止してホストのアタック・フットプリントを最小限に抑え、不要なサービスのリソース消費を削減してシステム・リソースを解放し、OMSから最良のパフォーマンスを引き出すことをお薦めします。
sudoやPowerBrokerなどのユーティリティを使用して、すべての「Oracleホーム」への間接または偽装ベースのアクセスのみをサポートすることによって、OSのアクセスを制限します。WebLogic Serverホーム・ディレクトリ、特に構成ファイル、セキュリティ・ファイル、ログ・ファイルおよび他のWebLogicドメイン用Java EEリソースを含むドメイン・ディレクトリを保護します。WebLogic Serverを実行する1人のみのOSユーザーにこのディレクトリへのアクセス権限を付与します。
すべてのOracleホームが最新のCPU (Critical Patch Update)を使用してパッチ適用されていることを確認します。これは、Oracle Management Service、リポジトリ、エージェントおよび管理対象ターゲットを保護するための推奨のベスト・プラクティスです。My Oracle Supportの資格証明を、「パッチ・アドバイザ」から新規のセキュリティ・アラートおよびCPUを検出するように設定します。デフォルトの「Oracle製品用のセキュリティ推奨」コンプライアンス標準では、ターゲットに最新のセキュリティ・パッチがない場合、コンプライアンス標準違反がトリガーされます。さらに、「ホストのセキュアな構成」がOMSおよびリポジトリのホストに関連付けられている必要があります。セキュリティ・レベルに応じて適用できる、データベースおよびWLS用の追加のコンプライアンス標準もあります。使用可能なコンプライアンス標準およびターゲットの関連付け方法の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。
OMSは、Oracle WebLogic Server上で実行します。Oracle WebLogic Serverを保護するためのベスト・プラクティスの多くは、OMSの保護にも適用できます。詳細は、『Oracle Fusion Middleware Oracle WebLogic Server本番環境の保護』のOracle WebLogic Serverの保護に関する説明を参照してください。
OMS、リポジトリおよびエージェントがファイル・システムの領域について監視されていることを確認します。OMSはログおよびトレース・ファイルに多くの情報を書き込むため、正常な操作およびトラブルシューティングには、適切な領域が必要となります。エージェントも、ログ・ファイル、トレース・ファイルおよびターゲット・メトリックの収集用にファイル・システム領域を必要とします。
前述の推奨事項に加えて、Oracle Management Repositoryを保護する手順が必要です。Oracle Management RepositoryはOracle Database内にあるため、Oracle Database自体を保護する多くのベスト・プラクティスをリポジトリの保護にも適用できます。Oracle Databaseセキュリティのベスト・プラクティスについては、Oracle Databaseセキュリティ・チェックリストを参照してください。
前述のドキュメントには、データベースを保護するために実行する必要のある特定のオペレーティング・システム・レベルの手順についても記載されています。Enterprise Managerのデプロイメントにおいて実装される追加の推奨事項を次に説明します。
OMSとリポジトリとの間の高度なセキュリティ・オプション(ASO)を有効にして、OMSとリポジトリとの間のデータが機密保護および整合性の両方の観点から見て確実にセキュアであるようにします。リポジトリ・データベースで必要なASO構成に加えて、OMSとエージェントをセキュアなリポジトリ・データベースに接続するように構成する必要もあります。Enterprise Managerに対するASOの実装手順の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』のEnterprise Managerのセキュリティに関する説明を参照してください。
ASOの詳細は、『Oracle Database Advanced Securityガイド』を参照してください。
リポジトリ・データベースをファイアウォール内に置き、ネットワークIPアドレスを確認することによって、リポジトリが配置されているホストへのネットワーク・アクセスを制限します。リスナーは、TNS_ADMIN/protocol.oraファイルに次のパラメータを追加して、OMSノードからのみのリクエストを受けるように構成する必要があります。
tcp.validnode_checking =YES
tcp.excluded_nodes = (IPアドレスのリスト)
tcp.invited_nodes = (IPアドレスのリスト)(すべてのOMSノードをここにリストする)
最初のパラメータでこの機能を有効にし、次のパラメータはそれぞれOracleリスナーへの接続を拒否および許可する特定のクライアントのIPアドレスを指定します。詳細は、『Oracle Databaseセキュリティ・ガイド』のネットワーク接続の保護に関する項を参照してください。
AUDIT_SYS_OPERATIONS = TRUEに設定して、すべてのSYS (スキーマ)操作をデータベース・レベルで監査します。
オペレーティング・システムsyslog監査証跡を使用して、リポジトリのデータベースのバージョンが10gR2以降の場合に、データベース管理者のような権限を持つユーザーが、オペレーティング・システム証跡に格納された監査レコードを変更または削除できるリスクを最小限に抑えます。
10gR2 DBの場合、syslog監査証跡の詳細は、監査のドキュメントを参照してください。
11g DBでは、AUDIT_SYS_LEVEL初期化パラメータをsyslog監査証跡を使用するように適切に設定します。詳細は、11gのドキュメントを参照してください。
ユーザーは、自分の個別のアカウントを使用してコンソールにログインする必要があり、SYSMANユーザーは使用しません。SYSMANはスキーマの所有者で、Enterprise Managerスーパー管理者よりも権限が高くなっています。SYSMANアクセスの必要性を減らすため、複数のユーザーにスーパー管理者を付与する必要があります。複数のスーパー管理者アカウントを作成する大きな理由は、あるユーザーが辞書攻撃または総当たり攻撃によりロックされた場合に、別のユーザーがアカウント・アクセスを維持できるようにするためです。スーパー管理者権限は、スーパー管理者であることにより得られるすべての権限が本当に必要なユーザーにのみ制限する必要があります。
状況によっては、リポジトリ・データベースでSYSMANユーザーとして次のSQL文を実行して、SYSMANがコンソールにログインしないようにした方がよい場合があります。
UPDATE MGMT_CREATED_USERS SET SYSTEM_USER='-1' WHERE user_name='SYSMAN'
SYSMANのコンソールへのログインを無効にした後、次のようにすると有効にできます。
UPDATE MGMT_CREATED_USERS SET SYSTEM_USER='1' WHERE user_name='SYSMAN'
リポジトリベースの認証を使用しながらEnterprise Manager管理者のパスワード制御を強化するには、パスワード・プロファイルを使用します。すぐに使用できるEnterprise Manager管理者用のパスワード・プロファイル、MGMT_ADMIN_USER_PROFILEがあり、これは次のパラメータ設定になっています。
FAILED_LOGIN_ATTEMPTS=10
PASSWORD_LIFE_TIME=180
PASSWORD_REUSE_TIME=UNLIMITED
PASSWORD_REUSE_MAX=UNLIMITED
PASSWORD_LOCK_TIME=1
PASSWORD_GRACE_TIME=7
PASSWORD_VERIFY_FUNCTION=MGMT_PASS_VERIFY
すぐに使用できるパスワード検証関数MGMT_PASS_VERIFYでは、パスワードがユーザー名と同じではなく、長さが8文字以上で、1つ以上の英数字および句読点を含んでいることを確認します。特別な要件を満たす様々な値、たとえば、厳しい複雑さのパスワード要件を満たす新しいパスワード検証関数を使用して、カスタマイズしたパスワード・プロファイルを作成できます。
SYSMANおよびMGMT_VIEWユーザーのパスワードは、『Oracle Enterprise Manager Cloud Control管理者ガイド』のセキュリティに関する説明に記載された方法のみを使用して定期的に変更します。ドキュメントに記載された(update_db_password())コマンドを使用すると、OMSおよびリポジトリ・データベースでのSYSMAN関連のパスワードの変更に役立ちます。このコマンドを正しく実行しないと、複数あるアカウントのうちの1つに対する一貫したパスワードが得られないため、OMSは起動に失敗する場合があります。新旧のSYSMANパスワードを入力するよう求められます。
MGMT_VIEWパスワードを変更する際、-auto_generateを選択してだれにもわからないランダム・パスワードを生成できます。MGMT_VIEWパスワードはレポート・システムによってのみ使用され、ログインには使用できないため、auto_generateフラグでこのパスワードが知られないようにできます。
内部ユーザーのロックアウトによるサービスの中断を防ぐため、SYSMANおよびMGMT_VIEWユーザーはインストール時にMGMT_INTERNAL_USER_PROFILEと関連付けられます。パスワード・パラメータはすべて、UNLIMITEDに設定されます。さらに、リソースの消費制限によりセッションがハングしたり時間がかからないように、MGMT_INTERNAL_USER_PROFILEのカーネル・パラメータがデフォルトで無制限に設定されます。
暗号化鍵は、リポジトリに格納されているパスワードや優先資格証明などの機密データの暗号化または復号化に使用されるマスター・キーです。この鍵自体は最初にリポジトリに保存され、インストールが完了すると自動的に削除されます。これはアップグレードの間のみ、リポジトリに置かれている必要があります。鍵をEnterprise Managerスキーマとは別に保管することで、スキーマの所有者およびSYSDBAユーザー(データベースのメンテナンス・タスクを行える特権ユーザー)が、優先資格証明などの機密データにアクセスできないようにします。鍵をEnterprise Managerスキーマとは別にすることで、リポジトリ・バックアップはアクセスされても、機密データはアクセスされないようにします。さらに、Enterprise Managerスキーマの所有者(SYSMAN)は、emkeyの読取りや上書きをしないように、OMSのOracleホームへアクセスできないようにします。Enterprise Managerの暗号化サポートおよびemkeyの詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。暗号化鍵を保護するには次に説明するプロセスを実行します。
次のコマンドを実行してファイルに暗号化鍵をバックアップし、この暗号化ファイルを別のマシンに安全に保持し、アクセスをOMSソフトウェアの所有者のみに制限します。暗号化鍵が消失または破損した場合、リポジトリ内の暗号化データは使用できなくなります。
$ emctl config emkey –copy_to_file_from_credstore –emkey_file emkey.ora
Enterprise Managerパッチおよびアップグレードなどの一部の操作では、暗号化キーがリポジトリに必要です。
操作が終了したら、リポジトリから鍵を削除します。
$ emctl config emkey –remove_from_repos
エージェントのインストール時に高いセキュリティを確保するには、セキュアなSSHプロトコルを使用するEnterprise Managerの「エージェント・デプロイ」を使用してエージェントをデプロイする必要があります。ユーザーが認可されていないエージェントをインストールする可能性がなくなるよう、手動でエージェントをデプロイする場合、永続的な登録パスワードのかわりに、適切な有効期限のあるワンタイム登録パスワードを使用してください。登録パスワードは、コンソールで作成するか、emctl secure setpwdコマンドを使用して作成できます。
認可されていない変更を防ぐには、エージェントをOMSのインストールとは別のユーザーとしてインストールし、インストール後、sudoまたはPowerBrokerなどのこのアカウントへの偽装べースのアクセスのみをサポートします。
エージェントのインストールには、Enterprise Managerの「エージェント・デプロイ」方法を使用する
有効期限のあるワンタイム登録パスワードを使用する
OMSまたはターゲットとは別のユーザーとしてエージェントをインストールする
|
注意: リモート・サーバー上のエージェントは、そのサーバーにターゲットの個別のOSユーザーとしてインストールする必要がありますが、これは連鎖しているエージェントには適用されません。連鎖しているエージェントはOMSとともにインストールされるため、個別のユーザーとしてインストールすることはできません。 |
OMSとエージェントとの間の通信をセキュアにするには、ファイアウォール、OMSセキュアロック機能、TLSv1の有効化、強力な暗号スイートおよび証明書の有効化など、方法がいくつかあります。次の項では、これらについて詳細に説明します。
エージェントが適切なタイミングまたは予期した間隔でアップロードまたは応答しなかった場合、Enterprise Managerは業界標準のInternet Control Message Protocol (ICMP)エコー・リクエストを使用して、ターゲット・ホスト・マシンの状態を確認します。ICMPが無効化されている場合、ターゲットは停止しているように見えます。不適切な停止ターゲット・アラートを防ぐには、ICMPを許可するようにファイアウォールを構成する必要があります。
ビーコンは、管理エージェントがサービスをリモートで監視できるようにするターゲットです。ビーコンは、常に1つ以上のサービスを監視できます。ICMPおよびユーザー・データグラム・プロトコル(UDP)をビーコン・ターゲット間でのデータ転送に使用して、監視しているサービスおよびネットワーク・コンポーネントをエージェントが監視するようにもできます。Webアプリケーション・コンポーネントとそれらのコンポーネントの監視に使用しているビーコンとの間に、ファイアウォールまたはACLがある場合、ICMP、UDPおよびHTTP通信を許可するように構成する必要があります。
エージェントが配置されているホストがファイアウォールで保護されている場合、エージェントをプロキシを使用するように構成するか、ファイアウォールをOMSからの通信を受信するように構成する必要があります。ファイアウォールを構成するには、エージェントに割り当てられるポートを決定し、通信がHTTPであるかHTPSであるかを決定する必要があります。この情報は、emctl status agentを実行することで得られます。
プロキシを構成するには、Enterprise Managerコンソールを使用して「エージェント」のプロパティを編集するかemctl setproperty agentを実行して次のプロパティを設定し、エージェントを再起動します。すべての環境において、プロキシのレルム、ユーザーおよびパスワードは不要です。
$ emctl setproperty agent -name REPOSITORY_PROXYHOST -value proxy42.acme.com $ emctl setproperty agent -name REPOSITORY_PROXYPORT -value 80 $ emctl setproperty agent -name REPOSITORY_PROXYREALM –value <value if needed> $ emctl setproperty agent -name REPOSITORY_PROXYUSER –value <value if needed> $ emctl setproperty agent -name REPOSITORY_PROXYPWD –value <value if needed>
Oracle Management Serviceがファイアウォール内にある場合、エージェントへのプロキシ通信やファイアウォールを介した通信の受信を可能にする構成が必要になります。
ファイアウォール内のエージェントが異なるドメインにある場合、プロキシをこれらのエージェントへの通信を許可し、dontProxyForパラメータを使用してファイアウォール内のエージェントを識別するように構成できます。管理サービスでプロキシを構成するには、emctl set propertyを使用して次のプロパティを設定します。すべての環境において、プロキシのレルム、ユーザーおよびパスワードは不要です。
$ emctl set property -name REPOSITORY_PROXYHOST -value proxy42.acme.com $ emctl set property -name proxyPort -value 80 $ emctl set property -name dontProxyFor –value ”.acme.com, .acme.us.com”
メトリック・アップロードのためにエージェントからの通信の受信を許可するようにファイアウォールを構成するには、アップロード・ポートでHTTPまたはHTTPS通信を受け付けるようにファイアウォールを構成する必要があります。デフォルトのポートは、4889 (HTTP)および1159 (HTTPS)です。ポートがカスタマイズされている場合には、それらのポートを使用してください。
ブラウザとEnterprise Managerコンソールとの間にファイアウォールがある場合には、コンソールがポート7788または7799(デフォルト)を経由してHTTPまたはHTTPS通信を受信できるように、ファイアウォールを構成する必要があります。ポートは、コンソールをアクセスするURLを参照することで検証できます。
https://mgmthost.acme.com:7799/em
JVMD、APDおよびBIなどの追加コンポーネントのインストールには、さらにポート要件があります。たとえば、BI Publisherがインストールされた場合、レポート用のコンソールにアクセスするために追加のポートが必要になる場合があります。デフォルトのポートは、9702/9703 (http/https)です。詳細は、コンポーネント専用のドキュメントを参照してください。
ファイアウォール内で構成されたデータベース・ターゲットを管理するには、リスナー・ポート(通常1521ですが、カスタマイズされることが多い)でのOracle Net通信を許可する必要があります。Oracle Databaseのファイアウォール用の構成方法の詳細は、『Oracle Database 2日でセキュリティ・ガイド』を参照してください。
SHA (セキュア・ハッシュ・アルゴリズム)は、セキュア・ハッシュ・アルゴリズムの連邦標準で、デジタル認証および整合性検証を可能にします。1995年に最初に制定されたSHA1にはセキュリティ上の脆弱性があるため、より強力に暗号化されたSHA2標準への置き換えが進んでいます。最高レベルのセキュアな通信を維持するには、SHA1ハッシュ関数を使用するSSL証明書を、より新しいSHA2ハッシュ関数に切り替える必要があります。
SSL接続では、次の2つの場合にSHA2が使用されます。
証明書署名: 証明書の整合性を検証します。
証明書署名は、証明書の暗号化されたハッシュです。ここで使用されるハッシュ・アルゴリズムは、発行者がサーバー証明書に署名するときに選択されます。
MAC (メッセージ認証コード): 最初のSSLハンドシェイクの後、クライアントおよびサーバーは暗号化モードで通信します。MACを使用すると、暗号化データの整合性をチェックできます。MACで使用されるハッシュ・アルゴリズムは、ハンドシェイク中に選択される暗号スイートに基づいて決定されます。例: SSL_RSA_WITH_RC4_128_SHA。この例では、MACにSHAが使用されます。
Oracle Software Security Assuranceの標準に準拠して、SHA1はTLS/SSLで許可されます。SHA2は、TLS 1.2のTLS/SSL MACでのみサポートされます。
次の表に、Enterprise ManagerのバージョンごとのSHA2サポートのレベルを示します。
| Enterprise Managerのバージョン | SHA2証明書のサポート | デフォルトのエージェントおよびOMS証明書がSHA2か | MAC/暗号スイートのSHA2 (TLS 1.2サポート) |
|---|---|---|---|
| 12.1.0.5 | はい | はい | いいえ |
| 13.1 | はい | はい | はい* |
* Enterprise Manager 13cリリース1では、管理エージェント/Oracle Management Service (OMS)とデータベース・ターゲットの間のTLS 1.2通信はサポートされていません。
セキュリティ・コンソールを介してEnterprise Manager環境内で使用されている証明書を確認できます。コンソールには、現在の証明書構成に関する情報が表示されるため、証明書をSHA2に更新する必要があるかどうかを判断できます。
Enterprise Manager Cloud Controlのセキュリティ・コンソールにアクセスする手順は、次のとおりです。
「設定」メニューから、「セキュリティ」を選択し、「セキュリティ・コンソール」を選択します。「セキュリティ・コンソール」が表示されます。
右ペインの「セキュアな通信」をクリックし、「現在の構成」タブをクリックします。
Oracle Management Service (OMS)のアップロード証明書を確認する手順は、次のとおりです。
「セキュリティ・コンソール」から「OMSのセキュアな構成」リージョンに移動し、「証明書の詳細」列の「詳細」リンクをクリックして「コンソールの証明書詳細」ダイアログを表示します。
「アルゴリズム」の値を確認します。オラクル社の推奨事項に準拠するには、値をSHA2 (SHA256やSHA512など)にします。値をSHA1またはMD5にしないでください。
「アルゴリズム」の値がSHA2の場合、この項の残りの手順は無視できます。そうでない場合は、手順3に進みます。
「発行者」列の値が、EnterpriseManager on omshostnameなど、OMSのデフォルトの認証局(CA)に設定されているかどうかを確認します。
「発行者」がOMSのデフォルトのCAに設定されていない場合は、サード・パーティのCA証明書を使用しています。この場合は、手順4をスキップして手順5に進むことができます。
OMSのデフォルトのCAが使用されている場合:
OMSのCA証明書がSHA2かどうかを確認します。「認証局の詳細」リージョンで、「アルゴリズム」列を確認します。
OMSのCA証明書がSHA2の場合は、emctl secure omsコマンドを使用して、OMS証明書を更新します(BIGIPの場合はSLB証明書)。これにより、新しいSHA2証明書が発行されます。エージェントを再保護する必要はありません。
OMSのCA証明書がSHA2でない場合は、次のことを実行します。
A.emctl secure createcaコマンドを使用して、新しいCAを作成します。このことによってOMS証明書が変更されることはありません。このコマンドの使用方法の詳細は、次を参照してください。
http://www.oracle.com/pls/topic/lookup?ctx=em131&id=EMSEC13034
B.emcli secure_agentsコマンドを使用して複数のエージェントをまとめて保護し、すべての管理エージェントを保護します。このコマンドの使用方法の詳細は、次を参照してください。
http://www.oracle.com/pls/topic/lookup?ctx=em131&id=EMCLI1333
これは複数のフェーズで実行できます。古い証明書およびトラスト・ストアを使用しているエージェントは、OMSが再保護されるまで機能します。
C.すべての管理エージェントが保護されている場合(ステータスは「エージェントの証明書詳細」リージョンで確認できます)は、emctl secure omsコマンドを使用して、新しいCAでOMS証明書を更新します。このコマンドの使用方法の詳細は、次を参照してください。
http://www.oracle.com/pls/topic/lookup?ctx=em131&id=EMSEC13066
管理エージェントは新しいCA詳細で保護されたため、追加の変更なしで引き続き機能します。
サード・パーティのCA証明書が使用されている場合:
同じCAで新しいSHA2証明書を取得し、emctl secure omsコマンドを使用してこれを更新します。管理エージェントを再保護する必要はありません。
新しいSHA2証明書に別のCAがある場合:
A.emctl secure oms -trust_certs_loc <loc>コマンドを使用して、Enterprise Managerのトラスト・ストアを更新します。新しいトラスト・ストアには、古いCA証明書および新しいCA証明書の両方が必要です。B. OMSが古い証明書を使用しているため、管理エージェントは機能します。emcli secure_agentsコマンドを使用して、環境内のすべての管理エージェントを再保護します。
C.emctl secure omsコマンドを使用してすべてのOMSインスタンスを保護し、これらを新しい証明書で更新します。D. 必須ではありませんが、トラスト・ストアから古いCAを削除し、すべての管理エージェントを再保護してエージェント側でトラスト・ストアを更新することをお薦めします。
|
注意: ロード・バランサを使用する高可用性構成のEnterprise Managerを実行している場合、OMSの保護の詳細は、Oracle® Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイドの高可用性に関する項を参照してください。 |
管理エージェントをまとめて保護するには、emcli secure_agents動詞を使用します。
「セキュリティ・コンソール」の「OMSのセキュアな構成」リージョンに移動して、コンソール・ポートの「証明書の詳細」列で「詳細」をクリックします。
「コンソールの証明書詳細」ダイアログが表示されます。「アルゴリズム」の値がSHA1またはMD5でないことを確認します。これはSHA2 (SHA256、SHA512など)になります。
「アルゴリズム」の値がSHA2でない場合は、emctl secure omsコマンドを使用してOMSインスタンスを更新します。
OMSのCA証明書は、OMSとそれに関連付けられた管理エージェントの証明書を発行するためにデフォルトで使用されます。同じ証明書が発行されるため、OMSのCA証明書がSHA2であることを確認します。
「セキュリティ・コンソール」の「認証局の詳細」リージョンに移動して、「アルゴリズム」列の値がSHA2であることを確認します。
「アルゴリズム」の値がSHA2でない場合は、emctl secure createcaコマンドを使用して、アルゴリズムがSHA2である新しいCAを作成します。
新しいCAが作成されると、この新しいCAによってすべての証明書が発行されます。そのため、OMSを保護する前にすべての管理エージェントを先に保護する必要があります。
「セキュリティ・コンソール」の「エージェントの証明書詳細」リージョンで、すべての管理エージェントの証明書を確認します。
管理エージェントの証明書がSHA2でない場合は、管理エージェントを再保護する必要があります。ただし、管理エージェントを再保護する前に、OMSのCAがSHA2であることを確認してください。
管理エージェントをまとめて保護するには、emcli secure_agents動詞を使用します。
また、管理エージェント側でカスタム証明書を使用している場合は、次のMy Oracle Supportノートを参照してください。
12c Cloud Control: Steps to Import Third Party Trusted SSL Certificate into 12c Cloud Control Agent URL(ドキュメントID 1593183.1)
次のデータベース問合せを使用して、SHA1証明書またはMD5証明書を特定することもできます。
SHA1証明書またはMD5証明書を使用するエージェントをリストします。
select * from mgmt_agent_sec_info where sign_alg in ('md5', 'sha1');
SHA1証明書またはMD5証明書を使用するCAをリストします。
select * from mgmt_sec_info where sign_alg in ('md5', 'sha1');
SHA1証明書またはMD5証明書を使用するOMSアップロード・ポートをリストします。
select * from MGMT_OMS_UPLOAD_SEC_INFO where sign_alg in ('md5', 'sha1');
SHA1証明書またはMD5証明書を使用するOMSコンソール・ポートをリストします。
select * from MGMT_OMS_CONSOLE_SEC_INFO where sign_alg in ('md5', 'sha1');
セキュリティ・コンソールはスーパー管理者のみが使用可能で、セキュリティ関連のすべての構成情報を1箇所で提供し、これによって管理された環境のセキュリティを表示、分析および最適化できます。セキュリティ・コンソールにアクセスするには、「設定」メニューから、「セキュリティ」を選択し、「セキュリティ・コンソール」を選択します。
「セキュリティ・コンソール」が最初に表示された際には、2つのメイン・ウィンドウ(左側にメニュー・ウィンドウ、右側に情報ウィンドウ)に分割されています。
「セキュリティ・コンソール」には、静的(テキスト)情報と動的情報の両方が含まれています。テキストは、簡単な要約コンテキストをデータに提供するものであり、ドキュメントの代替となるものではありません。
「セキュリティ・コンソール」は、次のセキュリティ領域に分類されます。
「概要」セクションでは、「セキュリティ・コンソール」の各カテゴリの概要を説明します。
「プラガブル認証」セクションは、さらに2つのタブに分類されます。「概要」タブと「構成」タブです。
「概要」セクションには、ドキュメントのテキストが含まれますが、ドキュメントの代替となるものではありません。Enterprise Managerの認証は、Enterprise Managerにアクセスしようとするユーザーの妥当性を確認するプロセスです。認証機能は、Enterprise ManagerコンソールやEnterprise Managerコマンドライン・インタフェース(EM CLI)などの様々なインタフェースで使用可能です。Oracle Enterprise Manager 12cは外部認証方法についてWebLogic Serverに依存しています。同じ理由で、Enterprise Manager 12cは、Oracle WebLogic Serverでサポートされる認証方法を使用して認証できます。
また、このセクションでは、Enterprise Managerでサポートされている認証スキームを識別します(詳細は、第2章「セキュリティ機能」の「認証の構成」を参照してください)。
このセクションには、認証に関連するエンタープライズ内の現在の構成情報が表示されます。
認証構成
認証モード: このパラメータは、Enterprise Manager環境に構成されている様々なプラガブル認証スキームに関する情報を提供します。
外部ユーザー・サポート有効: 外部ユーザー認証が有効かどうかを表示します。リポジトリ認証以外の認証を使用している場合は、「はい」を表示します。
サポートされている自動プロビジョニング: 自動プロビジョニングのステータスも表示されます。自動プロビジョニングにより、外部で認証されているユーザーはEnterprise Manager内に事前構成されなくても、Enterprise Managerにログインできるようになり、情報は認証アプリケーションから転送されます。これには、OMSプロパティのoracle.sysman.core.security.auth.autoprovisioningを設定する必要があります。詳細は、第2章「セキュリティ機能」の第2.1.8項「外部ロールを使用した外部認可」を参照してください。
パスワード・プロファイル
管理者を作成する(「設定」→「セキュリティ」→「管理者」メニュー)際には、ユーザーがログイン時に使用するパスワード・プロファイルのタイプを入力します。この表は、様々なパスワード・プロファイルを割り当てられたEnterprise Manager内のユーザーの数を示しています。パスワード・プロファイルの詳細は、「ユーザー・アカウントの保護」を参照してください。
Enterprise Managerはターゲットおよび他のリソースへのアクセスを制御する詳細な権限を実装し、管理者は職務を有効に分割できます。たとえば、プロビジョニングの設計担当者と運用担当者の職責について検討してみましょう。前者(ソフトウェア・ライブラリのコンポーネントの作成)は後者(デプロイメントの発行)よりも多くの職責を担っています。Flexible DBアクセス制御では、権限とロールおよび、それらがEnterprise Manager内の異なるアプリケーション、グループ、サービスおよびターゲットに対する様々なレベルのアクセス制御を提供するためにどのように機能するかについて説明します。システムにの最後にログインした管理者、その管理者に付与された権限とロールの数、およびロールと権限の適切な使用に関するベスト・プラクティスの推奨事項に関する情報は、このセクションで確認できます。
「Flexible DBアクセス制御」領域は、5つのタブ(「概要」タブ、「管理者」タブ、「権限」タブ、「ロール」タブおよび権限の伝播の集計タブ)に分類されます。
すべてのシステムに対して同じレベルのアクセス権をすべての管理者に付与することは危険ですが、グループのすべての新規メンバーに数十、数百、場合によっては数千ものターゲットに対するアクセス権を個別に付与するのは時間のかかる作業です。Enterprise Managerの管理者の権限およびロール機能を使用すると、このタスクを何時間もかけずに数秒で実行できます。認可により、システム、ターゲットおよびオブジェクト・レベルの権限およびロールを介してEnterprise Managerによって管理されるセキュアなリソースへのアクセスを制御します。
この項では、ユーザー・クラス、およびユーザー・クラスごとに割り当てられるロールと権限などのEnterprise Managerの認可モデルについて説明します。この項の項目は次のとおりです。
ユーザーのクラス
権限およびロール
Oracle Enterprise Managerでは、管理している環境や、Oracle Enterprise Managerを使用しているコンテキストに応じて、Oracleユーザーの様々なクラスをサポートしています。複数のカテゴリにわたって次の3人の管理者が存在します。
スーパー管理者: Enterprise Manager環境のすべてのターゲットおよび管理者アカウントに対して完全なアクセス権限を持つ強力なEnterprise Manager管理者。スーパー管理者(SYSMAN)は、Enterprise Managerがインストールされる際にデフォルトで作成されます。スーパー管理者アカウントは、他のすべての管理者アカウントを管理でき、すべての管理者資格証明を設定できます。スーパー管理者は次のことができます。
Enterprise Managerの権限およびロールの作成
電子メール構成の定義や通知のグローバル・ルールの定義など、Enterprise Managerの初期設定の実行
Enterprise Managerへのターゲットの追加
システムでの全ターゲットに対する全アクションの実行
管理者: 通常のEnterprise Manager管理者。
リポジトリ所有者: 管理リポジトリ用のデータベース管理者です。このアカウントは、変更、複製または削除できません。
権限およびロール
ユーザー権限は、Enterprise Managerの基本レベルのセキュリティを提供します。権限は、ターゲット権限とリソース権限の2つのカテゴリに分けられます。
ロールとは、管理者や他のロールに付与できるEnterprise Managerのリソース権限またはターゲット権限、あるいはその両方の集合です。これらのロールは、地理的位置(カナダのシステムを管理するためのカナダの管理者用ロールなど)、業務系列(人事管理システムや販売システムの管理者用ロールなど)または他のモデルに基づいて作成できます。
あらかじめ用意されているロール
Enterprise Manager Cloud Control 12cには、様々なリソースとターゲット・タイプを管理するためのロールがあらかじめ定義されて含まれています。
外部ロール
Enterprise Manager Cloud Control 12cは、外部ロールを定義することでActive Directoryなどの外部認可ソースと統合できます。
プライベート・ロール
デフォルトでスーパー管理者に付与されない安全な権限(FULL_CREDENTIALやFULL_JOBなど)は、プライベート・ロールに付与できます。
プライベート・ロールをシステム・ロールに変換することはできません。プライベート・ロールの作成者は、そのライフ・サイクルを管理します。
プライベート・ロールは、Enterprise Manageのコマンドライン・インタフェース(EMCLI)からWITH_ADMINオプションを使用して管理者に付与できるので、管理者は他の管理者に対してプライベート・ロールの付与または取消ができます。
これは、Enterprise Manager内で現在作成されているすべての管理者をリストし、それらが最後にログインした日時もリストします。
これは、管理者に直接付与された権限の数が最も多い、上位5位の管理者をリストします。権限の数の多い管理者は、権限が効率的に使用されていないことを示しているので、かわりにロールを使用するようにします。管理者には、自身のタスクの実行に必要な最小数の権限を付与することをお薦めします。権限およびロールの詳細は、第2.2.3項「権限伝播グループを使用した権限の管理」を参照してください。
このセクションには、Enterprise Managerで使用可能なすべてのターゲット権限とリソース権限、権限が単一ターゲット、特定のターゲット、ターゲット・タイプに適用できるかどうか、その権限に別の権限が含まれているかどうかについても表示されます。
このセクションはロール数が最も多い上位5位の管理者を表示し、ロール付与の数が多い場合には、効率的な管理を行うためにロールを統合するよう推奨し、非効率的なロール階層が示されます。
ここには、ネストされたロールが最も多いロールが表示されます。
集計ターゲットは、グループやシステムなどの1つ以上のメンバー・ターゲットで構成されるターゲットです。Enterprise Managerは、権限伝播メカニズムに基づいた2つのタイプの集計ターゲットをサポートします。
標準集計ターゲット: 集計ターゲットに権限を付与すると、表示権限のみがそのメンバーに伝播されます。
権限伝播集計ターゲット: 集計ターゲットに権限を付与すると、同じ権限がそのメンバーに伝播されます。
集計ターゲットのターゲット権限の場合、次の機能がサポートされます。
集計ターゲットへの権限付与とそのメンバー間の区別
メンバーに同じ権限を伝播するデフォルトの既存の動作に加えて、ユーザーは集計ターゲットの権限付与とメンバーの権限付与を選択できます。ユーザーはメンバーに対する権限を持たないということも選択できます。
非権限伝播集計ターゲットでは、表示権限のみがデフォルトでメンバーに付与され、権限伝播集計ターゲットでは、管理者が指定するいかなる権限も適切に付与されます。
この機能は、ユーザー・インタフェースのユーザーとロール管理ページおよびターゲット・アクセス・ページから使用できます。表の詳細な権限を表示するには、これらのページの「ターゲット権限」表の上の「詳細な権限設定」ボタンをクリックします。
この新機能に対しても、EM CLIサポートを使用できます。使用状況の詳細は、既存の関連する動詞のEM CLIヘルプを確認してください。
特定の管理者に対するターゲット権限について、次のスナップショットを考えてみます。
「ターゲット権限付与の管理」列の下にリストされている権限をグループおよびメンバーに適用できます。
「集計専用の権限付与の管理」列の下にリストされている権限をグループのみに適用できます。
「メンバー専用の権限付与の管理」列の下にリストされている権限をメンバーのみに適用できます。
次の例では、PPG_DB_group1はデータベース・ターゲットの権限伝播グループです。PPG_HOST_group2はホスト・ターゲットの権限伝播グループです。NORMAL_group1は非権限伝播グループです。
上の表の最初の行を考えてみます。この構成は、特定のユーザーがグループPPG_group1およびメンバーの表示権限を持っていることを意味します。これとともに、グループPPG_group1にのみターゲットの構成権限があり、メンバーにのみブラックアウト・ターゲット権限があります。つまり、画像の現在のユーザーはグループPPG_group1のメンバーにブラックアウトを作成できますが、グループ自体に実行できず、PPG_group1を構成できますが、メンバーを構成できないことを意味します。ユーザーはグループおよびメンバーを表示できます。
2番目の行を考えてみます。PPG_HOST_group2は権限伝播グループです。この構成は、特定のユーザーに、グループPPG_group2のみに対するターゲットの構成権限があり、メンバーには表示権限もないことを意味します。
3番目の行では、ユーザーにグループに対するブラックアウト・ターゲット権限およびメンバー対する表示権限がある、非権限伝播グループを確認できます。
ホスト・ターゲットなどの非集計ターゲットの場合に2つの新しい拡張権限列値を適用できないことに注意してください。
前述した機能は一般的にすべての集計ターゲットに適用できることに注意してください。前述の例は、集計ターゲット・タイプ(グループ)の1つを示しています。
この項では、Enterprise Manager内で使用されるセキュアな通信の条件とプロトコルについての概要を示します。保護されたEnterprise Managerコンポーネントの現在のステータス、それらの証明書問題および詳細について表示できます。
Enterprise Manager Framework Securityは、次のようなEnterprise Managerコンポーネント間のセキュアな接続を実装します。
管理サービスと管理エージェントの間の通信用の署名されたデジタル証明書も含む、HTTPSおよび公開鍵インフラストラクチャ(PKI)コンポーネント。
管理サービスと管理リポジトリの間の通信のためのOracle Advanced Security。
管理サービスに対してEnterprise Manager Framework Securityを有効にするには、emctl secure omsユーティリティを使用して、次のアクションを実行します。
管理リポジトリ内にルート鍵を生成します。ルート鍵は、管理エージェントに対する一意のデジタル証明書を含むOracle Walletの配布時に使用されます。
Web層を変更し、管理サービスと管理エージェント間のHTTPSチャネルを有効化します。
Enterprise Manager Framework Securityを使用した管理エージェントからのリクエストを管理サービスが受諾できるようにします。
ホストに管理エージェントをインストールする際は、管理エージェントによって使用される管理サービスを指定する必要があります。管理エージェントに対してEnterprise Manager Framework Securityを有効にするには、emctl secure agentユーティリティを使用します。
管理サービスのHTTPSチャネルを使用するセキュアな管理エージェント・インストールのみが、管理リポジトリにデータをアップロードでき、Cloud ControlコンソールにはHTTPS経由でのみアクセス可能にすることが重要です。
Enterprise Managerでは、Oracle Management AgentのインストールがデータをOracle Management Serviceにロードする権限を持つことを検証するために、エージェント登録パスワードを使用します。
エージェント登録パスワードは、Oracle Management Serviceに対してセキュリティが有効な場合、インストール時に作成されます。Enterprise Managerコンソールから登録パスワードを直接追加、編集、削除できます。
エージェントの証明書詳細: セキュアなエージェントをその証明書の詳細(アルゴリズム、強度、作成時期、有効期限、エージェントが保護された時期など)とともに表示します。
保護されていないエージェント数: エンタープライズ内で、現在セキュアでない操作を行っているエージェントの数を示します。
期限が切れている登録パスワード数: 証明書の有効期限が切れたために実行を停止したエージェントの数を示します。
認証局の詳細: Enterprise Managerのインストール内で使用されている証明書をリストします。
OMSのセキュアな構成: Enterprise Manager構成およびManagement Servicesとの通信の詳細を表示し、コンソールおよびアップロード証明書詳細を含むそれぞれのセキュアな構成詳細をSLB詳細とともに示します。
OMSと管理リポジトリ/ターゲット・データベースの間の暗号化の構成詳細は、次のようになります。クライアントがサポートしている暗号化アルゴリズムとチェックサム・アルゴリズムのリストを次に示します。詳細は、前述の「管理リポジトリ・データベースのセキュリティの有効化」の項を参照してください。
サポートされている暗号化アルゴリズム: サポートされているすべての暗号化アルゴリズムの詳細をリストします。
使用中の暗号化アルゴリズム: 現在使用されているアルゴリズムをリストします。
サポートされているチェックサム・アルゴリズム: 現在サポートされているチェックサム・アルゴリズムをリストします。それらはMD5とSHA1です。
使用中のチェックサム・アルゴリズム: 現在使用されているアルゴリズムをリストします。
ユーザー名やパスワードなどの資格証明は、通常、データベース、アプリケーション・サーバーおよびホストなどのターゲットにアクセスする際に必要です。資格証明は暗号化され、Enterprise Managerに保存されます。Enterprise Manager 12c以降、基本のユーザー名/パスワード以外に、PKI、SSH鍵、Kerberosなどの強力な認証スキームが資格証明サブシステムでサポートされます。ジョブ、デプロイメント・プロシージャおよび他のEnterprise Mangerサブシステムで使用されるSSH鍵ベースのホスト認証は現在サポートされます。
適切な資格証明を使用することにより、次が可能になります。
バックグラウンドおよびリアルタイムでのメトリックの収集
バックアップ、パッチ適用、クローニングなどのジョブの実行
起動および停止などのリアルタイムのターゲット管理の実行
My Oracle Supportへの接続
資格証明はその使用方法に基づいて、次のカテゴリに分類できます。
名前付き資格証明
監視資格証明
優先資格証明
資格証明管理の現在の構成
暗号化鍵: 暗号化鍵は、リポジトリに格納されているパスワードや優先資格証明などの機密データの暗号化/復号化に使用されるマスター・キーです。鍵は最初にリポジトリに格納され、最初のOMSのインストール時にリポジトリから削除され、Fusion Middlewareで管理される資格証明ストアにコピーされます。
資格証明管理の使用状況統計
「使用状況統計」タブでは、資格証明の使用状況の情報を表示します。
包括的な監査では、現在の監査可能な操作およびそれらがディスクへの外部バックアップ用に構成されているかどうかを表示します。最も使用されている操作および最もアクティブな管理者の上位5位の統計も表示されます。
ユーザーの作成、権限の付与、パッチ適用またはクローニングのようなリモート・ジョブの開始などのEnterprise Manager管理者が実行するすべての操作を監査して、サービス組織の請け負った内部統制の準拠を確認する必要があります。
非拒否は監査の原則です。Enterprise Managerの包括的な監査は、すべての重要な操作の改ざんされていない監査証跡を提供します。
「使用状況」タブでは次のことを表示できます。
現在の監査構成
特定の監査操作
監査の使用状況統計(過去7日間の上位5位の操作および過去7日間の上位5位の管理者)
アクティブ・ユーザー・セッション数では、セッション・タイムアウト、1ユーザー・アカウント当たりの最大セッション数、1ユーザー・アカウント当たりのアクティブ・セッション数などのセッション管理に関連する情報を表示します。
すべての認証されたオープンなユーザー・セッションがこの領域に表示されます。
「アクティブ・ユーザー・セッション数」領域から、次の情報を表示できます。
セッション設定(セッション・タイムアウト、ユーザーごとに許可されるセッションの最大数、許可された数のアクティブ・セッション)
アクティブ・セッション
前述のカテゴリでの情報の監視に基づいて、ベスト・プラクティス・アドバイスがこのセクションに示され、リポジトリ暗号化鍵の管理、監査操作管理などの領域について説明します。推奨されたOracleセキュリティ・プロトコルのEnterprise Managerセキュリティ構成の準拠を迅速に表示できます。また、推奨されるベスト・プラクティスは、Enterprise Manager環境の固有な条件に基づいて提供されます。
「ベスト・プラクティス分析」領域から、次のことを表示できます。
プラガブル認証: 環境のプラガブル認証スキームに応じて調整されたベスト・プラクティス・アドバイス。
Flexible DBアクセス制御: ロールおよび権限管理に関するベスト・プラクティス・アドバイス。
セキュアな通信: 管理サービス、エージェントおよびEnterprise Managerコンソール間のセキュアな通信に関するベスト・プラクティス。
この項では、次のSSLのガイドラインについて説明します。
OMSおよびエージェントを、SSL v3の後継プロトコルであるTLS v1プロトコルのみを通信用にサポートするように構成することをお薦めします。デフォルトでは、OMSはSSLv3プロトコルとTLSv1プロトコルの両方を受け付ける混合モードで構成されています。
OMSをTLS v1プロトコル専用に構成するには、次のようにします。
次のコマンドを入力してOMSを停止します。
<OMS_ORACLE_HOME>/bin/emctl stop oms
次のコマンドを入力します。
<OMS_ORACLE_HOME>/bin/emctl secure oms -console -protocol TLSv1
Domain_Home/bin/startEMServer.shのJAVA_OPTIONSに次のように追加します。このプロパティがすでに存在する場合、値をTLS1に更新します。
-Dweblogic.security.SSL.protocolVersion=TLS1
次のコマンドを入力してOMSを再起動します。
$ emctl start oms
エージェントがサーバーとしてリスニングする間TLS v1プロトコルのみをサポートするようにエージェントを構成するには、Enterprise Managerコンソールでエージェントのプロパティを編集するか、コマンドラインでemctl setpropertyを使用します。複数のエージェントを一度に編集するには、「設定」→「エージェント」の順に進み、変更するエージェントを選択して「プロパティ」をクリックします。これによりジョブが作成され、「パラメータ」ページでエージェントのプロパティ変更を指定できます。この変更は、選択されたすべてのエージェントに適用されます。コマンドラインを使用するには、次のように実行します。
$ emctl setproperty agent -name allowTLSOnly -value true
Oracle Management ServiceおよびOracle Management Agentは、非セキュア(HTTP)モードまたはセキュア(HTTPS)モードで実行できます。デフォルトのインストールではOMSを自動的にセキュアロックするため、常にセキュア・モードを使用することをお薦めします。セキュアロック・モードでは、エージェントがHTTPSポートのみ(HTTPポートはロック)を介して通信することを必要とする点で、一歩先に踏み込んだセキュリティを実現できます。そのため、OMSとエージェントとの通信が常に暗号化され互いに認証されます。セキュアではないエージェントからのリクエストはすべて、OMSにより拒否されます。同様に、OMSからのセキュアではないリクエストは、エージェントにより拒否されます。これは、インフラストラクチャ内から発生する悪質な「介在者」による攻撃から管理システムを保護するうえで役立ちます。
インストールがOracle Enterprise Manager 10gリリース5よりも前に行われた場合、OMSを手動でセキュアロックする必要がある場合があります。アップグレードの場合、アップグレード前の環境が保護されていれば、アップグレードはセキュア・モードに留まりますが、OMSをセキュアロックしません。アップグレード前の環境がすでにセキュアロックされている場合には、アップグレードはOMSとエージェントの間でセキュアロック・モードに留まります。
OMSのセキュア状態をチェックし、OMSとエージェントとの間の通信をセキュアロックするには、次のコマンドを実行しOMSを再起動します。
$ emctl status oms –details Oracle Enterprise Manager Cloud Control 12c Release 12.1.0.3.0 Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. Enter Enterprise Manager Root (SYSMAN) Password : Console Server Host : mgmthost.acme.com HTTP Console Port : 7790 HTTPS Console Port : 7803 HTTP Upload Port : 4890 HTTPS Upload Port : 4904 OMS is not configured with SLB or virtual hostname Agent Upload is locked. OMS Console is locked. Active CA ID: 1 Console URL: https://mgmthost.acme.com:7803/em Upload URL: https://mgmthost.acme.com:4904/empbs/upload … $ emctl secure lock –upload Oracle Enterprise Manager Cloud Control 12c Release 12.1.0.3.0 Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. Enter Enterprise Manager Root (SYSMAN) Password : Agent Upload is locked. Agents must be secure and upload over HTTPS port. Restart OMS.
OMSがセキュアロック・モードで実行を始めると、セキュアではないエージェントはOMSにデータをアップロードできなくなります。ステータスを確認し、エージェントの問題を保護するには次のコマンドを実行します。ここで、登録パスワードが求められます。
$ emctl status agent –secure Oracle Enterprise Manager 12c Cloud Control 12.1.0.1.0 Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. Checking the security status of the Agent at location set in /scratch/cllamas/oracle/em12/agent/agent_inst/sysman/config/emd.properties... Done. Agent is secure at HTTPS Port 3872. Checking the security status of the OMS at https://mgmthost.acme.com:4904/empbs/upload/... Done. OMS is secure on HTTPS Port 4904 $ emctl secure agent Oracle Enterprise Manager 12c Cloud Control 12.1.0.1.0 Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. Agent successfully stopped... Done. Securing agent... Started. Enter Agent Registration Password : Agent successfully restarted... Done. EMD gensudoprops completed successfully Securing agent... Successful.
SSLまたはTSLを介したクライアント・ブラウザからのコンソール・アクセスが確実にセキュアであるようにするには、コンソールもロックされている必要があります。Oracle Enterprise Manager 10gリリース5からは、インストールはデフォルトでセキュアロックされています。アップグレードの場合、アップグレード前の環境がセキュアロックされていなければ、アップグレード後に次のコマンドを実行してコンソール・アクセスをセキュアロックする必要があります。
$ emctl secure lock –console
暗号スイートは、認証、キー・アグリーメント、暗号化、整合性保護に使用されるセキュリティ・アルゴリズムと鍵サイズを定義する暗号パラメータの組合せです。暗号スイートは、通信の整合性を保護します。たとえば、RSA_WITH_RC4_128_MD5という暗号スイートは、鍵交換にRSA、バルク暗号化に128ビット鍵のRC4、メッセージ・ダイジェストにMD5を使用します。Enterprise Managerでは、OMSとエージェントとの間の通信に強力な暗号スイートが使用可能です。デフォルトでは、エージェントでの通信に次の暗号スイートが使用可能です。
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
現在有効になっている暗号スイートを確認するには、Enterprise Managerコンソールでエージェントのプロパティを表示するか、次のコマンドを実行します。
$ emctl getproperty agent -name SSLCipherSuites Oracle Enterprise Manager 12c Release 1 12.1.0.1.0 Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. SSLCipherSuites is unset; default value is SSL_RSA_WITH_RC4_128_MD5:SSL_RSA_WITH_RC4_128_SHA:SSL_RSA_WITH_3DES_EDE_CBC_SHA:SSL_RSA_WITH_DES_CBC_SHA:SSL_RSA_EXPORT_WITH_RC4_40_MD5:SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
強力な暗号スイートがエージェントのSSLまたはTLS通信に使用されるように構成するには、Enterprise Managerコンソールでエージェントのプロパティを編集するか、次のようにsetpropertyコマンドを使用します。
$ emctl setproperty agent -name SSLCipherSuites -value <values>
サポートされる強力な暗号スイートは次のとおりです。
SSL_RSA_WITH_AES_128_CBC_SHA
SSL_DH_anon_WITH_3DEC_EDE_CBC_SHA
SSL_DH_anon_WITH_RC4_128_MD5
SSL_DH_anon_WITH_DES_CBC_SHA
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
OMSに使用される強力な暗号スイートを制限するには、$INSTANCE_HOME/WebTierIH1/config/OHS/ohs1/httpd_em.confファイルをおよびssl.confファイルのSSLCipherSuiteパラメータを適切な値で編集してください。デフォルトの値は次のとおりです。
„h SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
よく知られた認証局(CA)からの証明書を使用し、異なる有効期間および鍵サイズのよく知られた信頼できる証明書を活用して、OMSとエージェントとの間の通信およびコンソール・アクセスを保護します。
Oracleウォレットは、認証および署名資格証明(秘密鍵、証明書、SSLで必要な信頼できる証明書など)の格納に使用されるパスワード保護されたコンテナです。
カスタムの認証局を使用してコンソールを保護するには、ウォレット・ロケーションを作成し、そのウォレット・ロケーションに対してコンソールを保護する必要があります。ウォレットの作成方法の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
次の例では、Oracle Enterprise Managerとのセキュアな通信で使用できる自己署名付き証明書を作成する方法を示します。
ウォレット・コンテナを作成します。
|
注意: 現在、サポートされるのはシングル・サインオン(SSO)のウォレットのみです。 |
S /u01/app/oracle/middleware/oracle_common/bin/orapki wallet create -wallet /home/oracle/labs/mywallet -auto_login_only
ウォレットに証明書を追加します。ウォレットを作成する際、共通名(CN)をOMSがインストールされているマシンのホスト名またはSLB名(OMSがSLBの背後にある場合)として指定する必要があります。OMSがSLBの背後にある次の例では、test.example.comです。
S /u01/app/oracle/middleware/oracle_common/bin/orapki wallet add -wallet /home/oracle/labs/mywallet -dn 'CN=test.example.com, OU=Oracle, O=Department, L=Boise, ST=ID, C=US' -keysize 2048 -self_signed -validity 3650 -auto_login_only
必要な環境変数を設定します:
$ . setDomainEnv.sh
ウォレットで証明書を確認します。
S /u01/app/oracle/middleware/oracle_common/bin/orapki wallet display -wallet /home/oracle/labs/mywallet
Enterprise Manager Cloud Control 12cには、認証の方法が複数あります。事前定義された方法に加えて、カスタマイズされたプロバイダまたはモジュールをCloud Controlの認証にプラグインできます。デフォルトのシステム認証の方法は、標準のリポジトリ・ベースの認証です。事前定義済の方法にはさらに次のものがあります。
Oracleシングル・サインオン(OSSO)
エンタープライズ・ユーザー・セキュリティ(EUS)
Oracle Access Managerシングル・サインオン(OAM SSO)との統合
ダイレクトなLDAP統合(Oracle Internet Directory、Microsoft Active Directory)
事前定義済プロバイダを使用してEnterprise Managerを構成する方法の詳細は、「認証の構成」を参照してください。
拡張された認証モジュールのいずれかを使用することで、エンタープライズ全体にわたる一元的なアイデンティティ管理を利用できます。こうすることで、パスワードのセキュリティ・コンプライアンス、パスワード変更およびリセットについて、外部のアイデンティティ管理システムに依存できるようになります。外部認証を使用してEnterprise Managerでユーザーを作成するには、作成時に「外部」フラグを選択します。Enterprise Managerでの各新しいユーザーの作成の間、Oracle Access Manager (OAM)、LDAPまたはOracle Internet Directory (OID)などの外部のアイデンティティ・ストアを介すか、または内部的にEnterprise Managerリポジトリを介すかについて、認証のユーザー・モードを決定するように求められます。次の図は、ユーザー作成の間に表示されるデフォルトのウィンドウを示しています。
アイデンティティ管理システムからアカウントが削除されると、Enterprise Managerでは認証しなくなりますが、手動で削除する必要があります。アイデンティティ管理システムからユーザーが削除されたら、スクリプトまたはジョブを実行して、Enterprise Managerからユーザーを削除することが理想的です。
外部認証を使用した場合、Enterprise Managerではアイデンティティ管理システム・グループに名前でマッピングされる、外部ロールを作成できます(Enterprise Managerロール「DBA」はLDAPグループの「DBA」にマッピングされます)。そのため、外部グループ・メンバーシップに基づいた同期ユーザー・アクセスおよび権限が可能です。
ターゲット認証では、Enterprise Managerを介して管理されたホスト、データベースまたはアプリケーション・ターゲットへのアクセスが可能になります。強力なターゲット認証方法、名前付き資格証明を使用して、データベース・パスワード・プロファイルを構成することは、セキュアなターゲット認証を確保する数少ない方法です。
ターゲットと認証のセキュリティを確保するには、強力なホストおよびデータベース認証方法を選択します。ターゲット・アクセスの資格証明は暗号化され、Enterprise Managerに保存されます。Enterprise Manager Cloud Control 12cでは、現在、ホスト用のSSH鍵やデータベース用のKerberosチケットなどの強力な認証がサポートされています。これらの資格証明は、ジョブ、デプロイメント・プロシージャおよび他のサブシステムで使用できます。
認可は、認証されたサブジェクトの権限と許可を検証する行為です。認可の悪用を避けるため、職務の分離のポリシーを実装する必要があります。つまり、関連する複数の機能に対する職責を1人のユーザーに与えないことです。
会社内のEnterprise Managerユーザーには幅広い人材がいて、異なるロールや目的を持っています。
Enterprise Manager 12cには、種々の操作ロール用のロール・ベース認証を提供する、あらかじめ用意されているロールがいくつかあります。パッチ適用、プロビジョニング、クラウド、コンプライアンスおよびプラグインのための、オペレータ、デザイナおよび管理者の分離機能を使用すると、粒度のより高いユーザーの認証が可能になります。「類似作成」機能を使用すると、必要に応じて操作をさらに強化または制限できます。
|
注意: 既存のロールに対して「類似作成」操作を実行すると、新たに作成されたロールに元のロールのすべての権限を含めることができます。 |
ロール・ベース・アクセス制御(RBAC)を使用すると、権限の管理が容易になります(ロール付与の管理の方が権限付与の管理よりも簡単です)。あらかじめ用意されているロールの完全なリストは、『Oracle Enterprise Manager Cloud Control管理者ガイド』の権限とロールに関する項を参照してください。
Enterprise Manager 12cには、ターゲット権限およびリソース権限を指定する機能があります。ターゲット権限では、管理者はターゲットに対する操作を実行できます。新しいターゲット権限の一部としては、「表示可能な任意のターゲットに接続」、「任意の場所でのコマンドの実行」、「任意のエージェントとしてコマンドを実行」などがあります。ターゲット権限は、すべてのターゲットにも特定のターゲットにも適用できます。リソース権限では、Enterprise Managerの機能、ボタンまたはページへのアクセス権を付与します。新しいリソース権限の一部には、「バックアップ構成」、「クラウド・ポリシー」、「コンプライアンス・フレームワーク」、Enterprise Managerプラグイン、「ジョブ・システム」、「パッチ計画」、「自己更新」および「テンプレート・コレクション」があります。完全なリストは、「権限とロール認可の構成」を参照してください。これらの新しい権限を使用すると、職務と一致するファイングレイン権限が割り当てられた特定のロールを作成することによって、最低限の権限の原則の実装がさらに簡単になります。
強化された監査システムでは、定期的に付与される権限を容易に監視でき、どのユーザーがどの権限を行使したかを追跡できます。主な権限に関連する監査可能なアクションは次のとおりです。
ジョブ権限の付与
権限の付与
ロールの付与
ターゲット権限の付与
システム権限の付与
ジョブ権限の取消し
権限の取消し
ロールの失効
ターゲット権限の取消し
システム権限の取消し
スーパー管理者は、ターゲット、レポート、テンプレートまたはジョブに対する完全な権限を持ちます。これらのユーザーは、他のユーザーおよびスーパー管理者を作成し、他のユーザーに対して権限の付与または取消しができる唯一のユーザーとなります。スーパー管理者権限は、慎重に付与する必要があります。次の問合せを使用して、スーパー管理者のリストを取得します。
SELECT grantee FROM MGMT_PRIV_GRANTS WHERE PRIV_NAME = ’SUPER_USER'
ユーザーに権限を付与するのではなく、意味のあるロールを作成し、ロールをユーザーに付与する。
ファイングレイン権限またはロールを必要なときのみ付与することによって、職責の実行を必要とするユーザーに最小セットの権限のみを付与する。
完全な監視およびアカウンタビリティを実現するため、権限およびロールのアクションを監査する。
スーパー管理者の人数を制限する。
Enterprise Managerに用意されている粒度の高い権限では、最低限の権限の原則を実装できます。この原則では、管理者は正当な目的で必要とされる情報またはリソースにのみアクセスできるようにすることを推奨しています。
グループおよびシステムを使用してターゲットを編成すると、セキュリティ管理のオーバーヘッドを削減するうえで役立ちます。Enterprise Manager 12cには、権限の管理や認可を簡素化するうえで役立つ2種類のグループがあります。ロールをユーザーではなくグループに付与し、権限伝播グループを使用することで、直接の付与を減らし、ユーザーが必要に応じてターゲットにアクセスできるようにできます。
権限伝播グループを使用すると、割り当てられた権限をグループのすべてのメンバーに伝播することによって、グループ管理に伴う権限の割当て、取消しおよび管理が容易になります。たとえば、1人のユーザーに権限伝播グループSalesへのアクセス権が付与されると、メンバーはグループ内のすべてのターゲットへのアクセス権が得られます。
管理グループは、グループへの結合時にターゲットに対する監視設定の適用を自動化する権限伝播グループです。ターゲットはグループに直接割当てできませんが、メンバーシップ基準に基づいて自動的に追加されます。
システムも権限伝播であり、特定のアプリケーションまたは機能の関連ターゲットをすべて1つのシステムにグループ化できます。
Enterprise Managerには、アクセスされたジョブおよび資格証明を含む、Enterprise Managerで実行されたインフラストラクチャのアクションの追跡と検証に利用できる監査機能が追加されています。Enterprise Manager 12cでは、基本監査およびインフラストラクチャ監査がデフォルトで有効になっています。
監査対象操作のサブセットに対する監査を有効にするには、次のEMCLI動詞を使用してください。
$ emcli update_audit_settings -audit_switch="ENABLE/DISABLE" -operations_to_enable="name of the operations to enable,for all operations use ALL" -operations_to_disable="name of the operations to disable, for all operations use ALL"
たとえば、ログオンまたはログオフのみを監査するには、次のように実行します。
$ emcli update_audit_settings –audit_switch=”ENABLE” –operations_to_enable=”LOGIN;LOGOUT”
Enterprise Managerにより監査された操作のリストは、「監査の構成と管理」の項を参照してください。
Enterprise Manager 12cには、150個を超える監査用オプションがあります。次のコマンドを実行すると、Enterprise Managerで監査できる操作のリストが表示されます。
$ emcli show_operations_list
次に、このコマンドを実行した場合の出力例を示します。
$ ./emcli 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 AGENT_REGISTRATION_PASSWORD_USAGE Registration Password Usage NO AGENT_RESYNC Resync Agent NO AG_AUD_CREATE Create Administration Groups NO AG_AUD_DELETE Delete Administration Groups NO AG_AUD_MODIFY Modify Administration Groups NO APPLY_TEMPLATE Apply Monitoring Template NO APPLY_UPDATE Apply Update YES ATTACH_MEXT Attach Metric Extension NO
監査が有効化されると、監査レコードがリポジトリのMGMT$AUDIT_LOGビューに保持されます。Enterprise Manager Cloud Controlコンソールを使用して、監査データをスーパー管理者権限を持つユーザーとして監視します。「設定」→「セキュリティ」→「監査データ」の順にクリックします。
EMCLI動詞update_audit_settingsによる外部化サービスでは、監査データがリポジトリから外部ファイル・システムへ定期的に外部化されます。ディレクトリに監査ログ・ファイル用の十分な領域があることを確認してください。
$ emcli update_audit_settings -file_prefix=<file_prefix> -directory_name=<directory_name> -file_size = <file size> -data_retention_period=<period in days>
次の例では、監査データが14日間リポジトリに保持され、このデータがエクスポート後にgc12_auditの接頭辞が付いたファイル名でデータベース・ディレクトリAUDITに対応するOSディレクトリに保存され、ファイル・サイズはそれぞれ50Mバイトになることを示しています。
$ emcli update_audit_settings -externalization_switch=ENABLE -file_prefix=gc12_audit -directory=AUDIT -file_size=50000000 -data_retention_period=14
外部化済監査データが保存されたディレクトリへのアクセスを制限することによって、職務の分離を実現します。Enterprise Managerのユーザーは、外部化済監査データへのアクセス権を持つことはできません。
優先資格証明を使用すると、管理リポジトリ内にターゲットのログイン資格証明を格納することによって、管理対象ターゲットへのアクセスが簡素化されます。ユーザーは、これらの資格証明を認識するEnterprise Managerターゲットに、ログインを要求されずにアクセスできます。優先資格証明はユーザー単位で設定されるため、管理対象のエンタープライズ環境のセキュリティを確保できます。デフォルトの資格証明は、特定のターゲット・タイプ、および特定のターゲット用のターゲット資格証明にも設定できます。ターゲット資格証明は、デフォルトの資格証明より優先されます。
SYSMANなどのグループまたは共通アカウントに優先資格証明を設定しないでください。共通アカウントに優先資格証明が設定された場合、これらの資格証明の使用のアカウンタビリティは失われます。次のSQL文を使用して、優先資格証明セットを持つユーザーのリストをレポートできます。
SELECT t.target_name,tc.user_name,tc.credential_set_name FROM MGMT_TARGET_CREDENTIALS tc, MGMT_TARGETS t WHERE tc.target_guid=t.target_guid SELECT t.target_name,tc.user_name, tc.set_name FROM EM_TARGET_CREDS tc, MGMT_TARGETS t WHERE tc.target_guid=t.target_guid and tc.user_name = 'SYSMAN'
資格証明は名前付き資格証明として保存でき、他のユーザーにこの資格証明の使用、更新または所有するための権限が付与されます。これらの資格証明は、特定のターゲットに対してまたはグローバルに、ジョブ、パッチ適用または他の管理タスクのために使用できます。適用可能な資格証明のタイプには、ユーザー名またはパスワード、ホストに対するSSH鍵、データベースに対するKerberosがあります。この方法では、管理者が特権アクセス用の名前付き資格証明を構成し、特定のユーザーに付与できます。監査では、名前付き資格証明の作成、変更および使用を追跡します。
名前付き資格証明を使用すると、ターゲットの権限委任から権限管理を切り離すことができるセキュアなメカニズムがEnterprise Managerに提供されます。名前付き資格証明を使用して、組織は特定のユーザー名、パスワードまたは認証の詳細の管理を、これらの資格証明を使用する実際の認証局から分離させることができます。これは、悪質なユーザーが内部のCloud Controlから得た既知の資格証明のセットを使用して、Enterprise Manager以外から操作を確実に実行できないようにする必要のある、現代の安全な組織において不可欠な手段です。さらに、名前付き資格証明の一元化されたセットを管理すると、多くのEnterprise Manager管理者にわたって、資格証明情報の急増による著しい負荷をなくすことができるため、これらがEnterprise Manager環境以外から使用される可能性を低くし、資格証明が誤って公開されないようにできます。
