| Oracle® Fusion Middleware Oracle Enterprise Data Qualityの保護 12c (12.2.1.2.0) E88270-01 |
|
 前 |
 次 |
この章では、EDQ環境を保護するためのヒントについて説明します。
この章の内容は以下のとおりです。
WebLogic ServerでのSSLの構成手順は、次のWebLogicのドキュメントを参照してください。
WebLogic ServerでのSSL構成の概要
Tomcatで暗号化された接続を有効化するには、次の手順を使用してHTTPSコネクタを構成する必要があります。
Tomcatインストールでserver.xmlファイルを検索します(通常、これはTomcatディレクトリ内のconf/server.xmlです)。これには、デフォルトで次のようなセクションが含まれます。
<!-- Define a SSL/TLS HTTP/1.1 Connector on port 8443 This connector uses the NIO implementation that requires the JSSE style configuration. When using the APR/native implementation, the OpenSSL style configuration is required as described in the APR/native documentation --> <!-- <Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" maxThreads="150" SSLEnabled="true" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" /> -->
前後のXMLコメント文字を削除してConnector要素を有効にします。
必要に応じてHTTPSのポート値を設定します。デフォルトは8443であるため、異なる値を使用する場合は、HTTPコネクタのredirectPort値も一致するように変更してください。
1024未満のポートを使用する場合、OSによっては、サーバーで特別な権限が必要になることに注意してください。
サーバーの鍵と証明書を生成し、信頼できる認証局からの署名をその証明書に付与します。自己署名証明書も使用できますが、それらが認識されるためには、クライアント・マシンにインストールする必要があります。
|
注意: 証明書は、Javaキーストア(JKS形式)に格納されるか、PKCS#12ファイルとして格納されます。PKCS#12ファイルを操作するための多くのツールが使用できるため、一定の場合には後者の方が推奨されます。 |
次のようにpathtokeystorefile、keystorepasswordおよびkeystoretypeを参照先の情報に置き換えて、connector要素を更新します。
<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreFile="pathtokeystorefile" keystorePass="keystorepassword" keystoreType="keystoretype" />
必要に応じてkeystoreType値をJKSまたはPKCS12に設定します。キーストアに複数の証明書が含まれる場合、keyAlias属性を使用して別名を設定します。
一部のTomcatディストリビューションには、Apache Portable Runtime (APR)ネイティブ・ライブラリが含まれます。この場合、証明書は、Apache HTTPD mod_sslスタイル属性を使用して構成する必要があります。次に例を示します。
<Connector port="8443" protocol="org.apache.coyote.http11.Http11AprProtocol" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" clientAuth="false" SSLCertificateFile="pathtocrtfile" SSLCertificateKeyFile="pathtokeyfile" />
Tomcatの詳細は、次の場所にある『Apache Tomcat Configuration Reference』を参照してください
http://tomcat.apache.org/tomcat-8.0-doc/config/http.html
mod_sslの詳細は、次の場所にある『Apache Module mod_ssl』を参照してください
http://httpd.apache.org/docs/2.2/mod/mod_ssl.html
EDQ 12.2.1.2では、EDQプロセッサのセキュリティ・レベルを向上するために使用可能なセキュリティ制御をオプションで使用できるようになりました(スクリプト・プロセッサのセキュアでない使用をブロックするなど)。下位互換性を確保するため、プロセッサ・セキュリティはデフォルトでオフになっていますが、次の行を[EDQローカル・ホーム]/director.propertiesに追加することで有効にできます。
processor.security= off/low/medium/high
プロセッサ・セキュリティ・オプションは、Javaセキュリティ・マネージャの使用と連携して動作します。Javaセキュリティ・マネージャの使用は、サーバーで指定されたJavaオプション(-Djava.security.manager)によって制御されます。これは、EDQサーバーの起動グループのJavaオプションを設定するsetStartupEnv.shスクリプトで指定されるため、WebLogic ServerにEDQを新規インストールすると、デフォルトで有効になります。他のインストールでは、手動で指定する必要があります。
次に、様々なprocessor.security設定ごとのセキュリティ・レベルをまとめます。
Off:
セキュリティ制限は適用されません。
Low
次の制限が適用されます。
プロセスで直接使用するためのツール・パレットからのスクリプト・プロセッサの使用は、システムでJavaセキュリティ・マネージャが実行されていない場合、無効になります。
システムでJavaセキュリティ・マネージャが実行されている場合、スクリプト・プロセッサは使用できますが、データ処理に制限された、デフォルト権限のごく一部のみが付与されます。スクリプトは、アプリケーションの外部でネットワーク接続を行ったり、コマンドを発行することができません。
|
注意: jarにパッケージ化されたJavaプロセッサおよびスクリプトは、制限なしで実行されますが、jarにpermissions要素が含まれる場合、それらの権限のみがプロセッサに付与されます。 |
Medium:
Lowと同じ制限が適用されますが、jarにパッケージ化されたJavaプロセッサおよびスクリプトには、非常に制限された権限セットが付与されます。プロセッサに必要な追加の権限は、permissions要素にリストする必要があります。
この違いを説明すると、'low'レベルでは、すべての権限が付与され、permissions要素で権限を制限するのに対し、'medium'レベルでは、権限は制限され、permissions要素で権限を拡張するということになります。どちらのレベルでも、permissions要素を持つプロセッサは、まったく同じ権限セットで実行されます。
High:
'medium'と同じ制限が適用されますが、Oracle EDQ証明書または承認済パートナに付与された証明書によって署名されたプロセッサのみが、プロセッサに追加の権限を付与するpermissions要素を含むことができます。
未署名のjarにpermissions要素が検出されると、そのjarのプロセッサは拒否され、プロセッサ・パレットに表示されません。
プロセッサ・セキュリティ・セットがmediumまたはhighに設定された状態で実行されると、プロセッサに付与された権限により、次のシステム・プロパティを読み取ることができます。
java.version
java.vendor
java.vendor.url
java.class.version
os.name
os.version
os.arch
file.separator
path.separator
line.separator
java.specification.version
java.specification.vendor
java.specification.name
java.vm.specification.version
java.vm.specification.vendor
java.vm.specification.name
java.vm.version
java.vm.vendor
java.vm.name
他の権限は付与されません。
インストールはセキュアなスクリプトで実行できますが、ユーザーもアドホック・スクリプトで追加操作を実行できます。典型的な例は、Webサービス・コールの実行です。この追加機能を実現するため、システムでは、アドホック・スクリプト用の追加権限がリストされた構成ファイルがサポートされます。
追加権限ファイルは、ローカル構成ディレクトリのsecurity/permissionsフォルダにあります。スクリプト・プロセッサでは、ファイル名はscriptprocessor.xmlで、スクリプト一致ガジェットでは、ファイル名はscriptgadget.xmlです。ファイルのXML形式は次のとおりです。
<permissions> <permission type="permissionclass" [name="targetname" [action="action"]]/> … </permissions>
権限クラスは、任意のJava権限クラスの完全名です。name属性は、権限にターゲット名が含まれる場合に指定します(クラスには2つまたは3つの引数のコンストラクタがあります)。actionは、権限にアクションが含まれる場合に指定します(クラスには3つの引数のコンストラクタがあります)。
たとえば、ファイル/etc/hostsを読み取る権限を付与するには、次のようにします。
<permission type="java.io.FilePermssion" name="file:/etc/hosts" action="read"/>
システム・プロパティは、${…}置換を使用してnameに含めることができます。標準のシステム・プロパティとともに、次の追加プロパティを使用できます。
rootdir: Webアプリケーションのルートの場所。
webinfdir: WebアプリケーションのWEB-INFディレクトリの場所。
config.path: 構成ディレクトリのパス。そのnameに${config.path}を使用するpermissionsエントリは、パス内の各場所のエントリで置換されます。
EDQからLDAPディレクトリへの接続は、SSL/TLS接続レイヤーを使用するか、接続の確立後に暗号化をネゴシエーションすることで(StartTLS)暗号化できます。
TLSを介した接続のためのJDBC URL構文は、使用されているデータベース・ドライバに応じて異なります。Oracle Databaseへの接続は、次のプロパティをデータソースの接続プール構成に追加することで暗号化できます。
oracle.net.encryption_client = REQUIRED
詳細は、http://docs.oracle.com/database/121/JJDBC/clntsec.htm#JJDBC28296を参照してください
個々のユーザーによる同時ログインの数は、login.propertiesに制限を指定できます。この制限は、アプリケーションごとの同時ログインです。つまり、sessionlimitが1の場合、あるユーザーは、同時にディレクタ、サーバー・コンソール、ケース管理にログインできますが、どれにも2回ログインすることはできません。
これは、グローバルに構成するか、レルム単位で構成することができます。すべてのレルムでグローバルにこれを設定するには、次の行を使用します。
sessionlimit = 1
レルムごとに異なる設定を使用するには、次のようにパラメータの前にレルム名を指定します。
internal.sessionlimit = 1
|
注意: 前述の行を使用すると、内部レルム(ユーザーがEDQ自体で設定および管理されるという意味)の同時ログインも制限できます。 |
<external realm name>.sessionlimit = 1
最適なセキュリティのため、不要な環境では、EDQへのFTP/SFTPアクセスを無効にする必要があります。標準のFTPは、ローカル構成フォルダ内のdirector.propertiesに次の行を追加して無効にできます。
launch.ftpserver = 0
SFTP/SCPは、同じファイル内の次の行を使用して無効にできます。
launch.sshd = 0
管理者以外のユーザーがFTP/SFTPにアクセスできる場合、次のようにSFTPサーバーから構成フォルダに対するアクセス権を削除することをお薦めします。
まだ存在しない場合、oedq.local.home内にextras/ftpserver/confおよびextras/sshd/confフォルダを作成します。
ファイルextras/ftpserver/conf/ftpserver.xmlおよびextras/sshd/conf/sshd.xmlを、oedq.home構成ディレクトリからoedq.local.homeの対応するサブフォルダにコピーします。
前の手順の2つのファイルそれぞれで、次の行をコメント・アウトします。
<!-- Configuration area --> <ref bean="configspaces"/> <!-- Command areas --> <ref bean="commandspaces"/>
最初の参照は構成ディレクトリを示し、2番目の参照は外部タスクで使用されるコマンド領域を示します。
アプリケーション・サーバーを再起動します。これで、FTPおよびSFTPサーバーに認識される場所は、ランディング領域のみとなります。
Siebelがバッチ・ジョブ用にEDQと統合されている場合、EDQジョブを開始するには、ユーザー・アカウントに管理(JMX)ポートに接続する権限も必要です。これは、「システム/システム管理」機能権限によって制御されます。また、メッセージング・システムへの接続が、「システム/メッセージング・システムへの接続」としてリストされている必要があります。セクションでOracle Data Integrator (ODI)を参照する必要もあります。ODI統合に使用するEDQアカウントには、同じ権限が必要です(実際には、現在、「メッセージング・システムへの接続」は必要ありませんが、将来のことを考慮して含めておくことをお薦めします)。そのため、次のようなものが必要です。
SiebelやOracle Data Integratorなどのリモート・システムによって使用されるEDQアカウントには、EDQシステムに対する最低限の権限セットが必要です。具体的には、アカウントは次の権限のみを持つカスタム・グループに属している必要があり、ユーザー・アプリケーションにログインしたり、他の機能を実行するためのアクセス権は付与しません。
システム/メッセージング・システムへの接続 - EDQ WebサービスおよびJMSと通信する権限を付与します。
システム/システム管理 - EDQ管理(JMX)ポートに接続してジョブを開始できる権限を付与します。
コールを可能にする必要があるサービス・インタフェース(Webサービスまたはジョブ)を含む任意のプロジェクトに対する権限。
特定の手順を実行しないかぎり、EDQのユーザーは、既存のデータソースのJNDI名に対する参照を使用してデータ・ストアを設定し、これらのスキーマの(機密情報を含む可能性のある)データにアクセスできます。EDQのJNDIデータソースを保護するには、次のようにdirector.propertiesに名前(または名前に一致する正規表現)を指定します。
protected.jndi.datasources = <space separated list of JNDI names>
次に例を示します。
protected.jndi.datasources = jdbc/edqconfig jdbc/edqresults
プロパティは正規表現の空白区切りのリストであるため、次の方法も使用できます。
protected.jndi.datasources = jdbc/edq.*
|
注意: この値をローカルのdirector.propertiesに設定する場合、必ずベース・プロパティ・ファイルのデフォルト設定を含めてください。この設定により、WebLogicの内部データソースとEDQデータソースの両方に対するアクセスを防止します。 |
