2 Oracle Directory Integration Platformのセキュリティ機能
この章では、Oracle Directory Integration Platformのセキュリティにおける最も重要な事項について説明します。
トピック:
2.1 Oracle Directory Integration Platformでの認証の概要
認証は、Oracleディレクトリ・サーバーが、そのディレクトリに接続するユーザーの正確なアイデンティティを確認するプロセスです。ldapbind
操作によってLDAPセッションが確立されるときに、発生します。
Oracle Directory Integration Platformの各コンポーネントが、ディレクトリへのアクセスを許可される前に適切に認証されることは重要です。
トピック:
2.1.1 Secure Sockets LayerとOracle Directory Integration Platform
Oracleバックエンド・ディレクトリは、Secure Socket Layer(SSL).を使用するように構成する必要があります
Oracle Unified DirectoryまたはOracle Directory Server Enterprise EditionがOracleバックエンド・ディレクトリである場合、Oracle Directory Integration Platformは最初にインストールされたときには非SSLモードで動作します。一方、Oracle Internet DirectoryがOracleバックエンド・ディレクトリである場合は、Secure Socket Layer (SSL)接続が必要となります。
Oracle Directory Integration Platformでは、次のSSL実装モードをサポートします。
-
認証なし(SSLモード1): SSLデータ暗号化を提供しますが、認証にはSSLを使用しません。
ノート:
Oracleバックエンド・ディレクトリがOracle Internet Directoryである場合、Oracle Directory Integration Platformでは、認証なしSSLモード(SSLモード1)とSSLサーバー認証(SSLモード2)の両方がサポートされます。Oracle Unified DirectoryまたはOracle Directory Server Enterprise EditionがOracleバックエンド・ディレクトリである場合、使用できるSSLはSSLサーバー認証(SSLモード2)のみとなります。
認証なし(SSLモード1)の使用は推奨されません。
-
SSLサーバー認証(SSLモード2): Oracle Directory Integration Platformにはこのモードをお薦めします。これには、SSLデータ暗号化と、クライアントに対するサーバーのSSL認証の両方が含まれます。Oracle Directory Integration Platformでは、サーバーはディレクトリ・サーバーであり、クライアントはOracle Directory Integration Platformです。
ノート:
Oracle Directory Integration Platform 12c
では、接続ディレクトリとの通信でTransport Layer Security (TLS) v1.2プロトコルがサポートされます。「Transport Layer Securityプロトコルと暗号スイート」を参照してください。
サーバーは、信頼できる認証局(CA)が発行する証明書を送信することにより、クライアントに対して自身のアイデンティティを検証します。このモードでは、公開キーインフラストラクチャ(PKI)と証明書がJavaキーストア(JKS)に格納される必要があります。
Oracle Directory Integration PlatformでSSLを使用するには、Oracleバックエンド・ディレクトリとOracle Directory Integration Platformの両方を、同じSSLモードで起動する必要があります。たとえば、Oracleバックエンド・ディレクトリがSSLモード2で実行されている場合、Directory Integration Platformは、同じSSLモード2を使用してOracleバックエンド・ディレクトリに接続するように構成されている必要があります。
関連項目:
Oracle Internet DirectoryをOracleバックエンド・ディレクトリとして使用している場合は、SSLモードでのOracleディレクトリ・サーバーの起動手順について、『Oracle Fusion Middleware Oracle Internet Directoryの管理』を参照してください。
2.1.2 SSLモードでのOracle Directory Integration Platformの認証
ディレクトリ・サーバーのアイデンティティを設定するには、Oracleバックエンド・ディレクトリとDirectory Integration Serverの両方をSSLサーバー認証モードで起動します。この場合、ディレクトリ・サーバーは自身の証明書をDirectory Integration Serverに提供し、Directory Integration ServerはOracleバックエンド・ディレクトリのクライアントとして機能します。
サード・パーティのディレクトリに接続するときにSSLを使用するようにOracle Directory Integration Platformを構成することもできます。この場合は、「バックエンド・ディレクトリと接続ディレクトリのSSL証明書の管理」で説明されているように、接続ディレクトリ証明書をJavaキーストア(JKS)に保存します。
2.1.3 Transport Layer Securityプロトコルと暗号スイート
Oracle Directory Integration Platform 12cでは、接続ディレクトリとの通信でTransport Layer Security (TLS) v1.2プロトコルがサポートされ、データの暗号化と復号化に暗号スイートが使用されます。
TLSプロトコルはSSLプロトコルの後継です。TLSは、ネットワーク経由のデータ送信を伴うアプリケーションで現在広く使用されているプロトコルです。TLSプロトコルの主要目的は、通信している2つのアプリケーション間に強化されたセキュリティおよびデータの整合性を提供することです。
Transport Layer Securityプロトコルには、現在、セキュリティの強化されたTLS 1.0、TLS 1.1およびTLS 1.2という3つのバージョンがあります。Oracle Directory Integration Platformで使用されるデフォルト・バージョンは、TLS 1.2です。
トピック:
2.1.3.1 サポートされる即時利用可能な暗号スイート
Oracle Directory Integration Platformでは、即時利用可能な数多くの暗号スイートがサポートされます。
TLSハンドシェイクの際に、Oracle Directory Integration Platformおよび接続ディレクトリは、次にリストされた順序でTLSv1.2プロトコルとサポートされる暗号を使用して接続を開始します。
ノート:
Oracle Directory Integration Platformでは、即時利用可能ではない接続ディレクトリによって使用される暗号スイートを追加するオプションも提供されます。「暗号スイートのOracle Directory Integration Platformへの追加」を参照してください。表2-1 即時利用可能な暗号スイート
TLSプロトコル | 暗号スイート |
---|---|
TLSバージョン1.2 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 |
TLSバージョン1.2 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 |
TLSバージョン1.2 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 |
TLSバージョン1.2 | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 |
TLSバージョン1.2 | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 |
TLSバージョン1.2 | TLS_RSA_WITH_AES_128_GCM_SHA256 |
TLSバージョン1.2 | TLS_RSA_WITH_AES_256_GCM_SHA384 |
TLSバージョン1.2 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 |
TLSバージョン1.2 | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 |
TLSバージョン1.2 | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 |
TLSバージョン1.2 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 |
TLSバージョン1.2 | TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 |
TLSバージョン1.2 | TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 |
TLSバージョン1.2 | TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 |
TLSバージョン1.2 | TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 |
TLSバージョン1.2 | TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 |
TLSバージョン1.2 | TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 |
TLSバージョン1.2 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 |
TLSバージョン1.2 | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA |
TLSバージョン1.2 | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA |
TLSバージョン1.2 | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA |
TLSバージョン1.2 | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA |
TLSバージョン1.2 | TLS_DHE_DSS_WITH_AES_128_CBC_SHA |
TLSバージョン1.2 | TLS_DHE_RSA_WITH_AES_128_CBC_SHA |
TLSバージョン1.2 | TLS_DHE_DSS_WITH_AES_256_CBC_SHA |
TLSバージョン1.2 | TLS_DHE_RSA_WITH_AES_256_CBC_SHA |
TLSバージョン1.2 | TLS_DH_DSS_WITH_AES_128_GCM_SHA256 |
TLSバージョン1.2 | TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 |
TLSバージョン1.2 | TLS_DH_DSS_WITH_AES_256_GCM_SHA384 |
TLSバージョン1.2 | TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 |
TLSバージョン1.2 | TLS_RSA_WITH_AES_128_CBC_SHA256 |
TLSバージョン1.2 | TLS_DH_DSS_WITH_AES_128_CBC_SHA256 |
TLSバージョン1.2 | TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 |
TLSバージョン1.2 | TLS_RSA_WITH_AES_256_CBC_SHA256 |
TLSバージョン1.2 | TLS_DH_DSS_WITH_AES_256_CBC_SHA256 |
TLSバージョン1.2 | TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 |
TLSバージョン1.2 | TLS_RSA_WITH_AES_128_CBC_SHA |
TLSバージョン1.2 | TLS_DH_DSS_WITH_AES_128_CBC_SHA |
TLSバージョン1.2 | TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA |
TLSバージョン1.2 | TLS_RSA_WITH_AES_256_CBC_SHA |
TLSバージョン1.2 | TLS_DH_DSS_WITH_AES_256_CBC_SHA |
TLSバージョン1.2 | TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA |
TLSバージョン1.2 | TLS_DH_RSA_WITH_AES_128_GCM_SHA256 |
TLSバージョン1.2 | TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 |
TLSバージョン1.2 | TLS_DH_RSA_WITH_AES_256_GCM_SHA384 |
TLSバージョン1.2 | TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 |
TLSバージョン1.2 | TLS_DH_RSA_WITH_AES_128_CBC_SHA256 |
TLSバージョン1.2 | TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 |
TLSバージョン1.2 | TLS_DH_RSA_WITH_AES_256_CBC_SHA256 |
TLSバージョン1.2 | TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 |
TLSバージョン1.2 | TLS_DH_RSA_WITH_AES_128_CBC_SHA |
TLSバージョン1.2 | TLS_ECDH_RSA_WITH_AES_128_CBC_SHA |
TLSバージョン1.2 | TLS_DH_RSA_WITH_AES_256_CBC_SHA |
TLSバージョン1.2 | TLS_ECDH_RSA_WITH_AES_256_CBC_SHA |
TLSバージョン1.2 | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA |
TLSバージョン1.2 | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA |
TLSバージョン1.2 | TLS_RSA_WITH_3DES_EDE_CBC_SHA |
2.1.3.2 Oracle Directory Integration Platformで無効化されている暗号スイート
次に、Oracle Directory Integration Platformではデフォルトで無効化されている弱い暗号スイートのリストを示します。
-
SSL_RSA_WITH_RC4_128_MD5
-
SSL_RSA_WITH_RC4_128_SHA
-
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
-
TLS_ECDHE_RSA_WITH_RC4_128_SHA
-
TLS_ECDH_ECDSA_WITH_RC4_128_SHA
-
TLS_ECDH_RSA_WITH_RC4_128_SHA
-
SSL_RSA_WITH_3DES_EDE_CBC_SHA
-
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
-
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
-
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
2.1.3.3 暗号スイートのOracle Directory Integration Platformへの追加
バックエンド・ディレクトリまたは接続ディレクトリで構成された暗号スイートがOracle Directory Integration Platformで使用または認識できない場合、Oracle Fusion MiddlewareシステムMBeanブラウザを使用してそれらのスイートをOracle Directory Integration Platformに追加する必要があります。
ノート:
-
クラスタ環境では、クラスタ内のすべてのOracle Directory Integration Platform管理対象サーバーで次のステップを繰り返す必要があります。
-
WLSTコマンドを使用して暗号スイートを追加することもできます。『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティの管理』のWLSTを使用した暗号スイートの設定の例に関する項を参照してください。
2.1.3.4 SSL/TLSプロトコル・バージョンの指定
Fusion Middleware Controlコンソールを使用して、SSLハンドシェイクに対応するSSL/TLSプロトコル・バージョンを指定できます。ほとんどの場合、SSLプロトコルまたはTLSプロトコルの最新バージョンが適切ですが、ピアがこれをサポートしていない場合もあります。様々な状況(互換性、SSLパフォーマンス、および最高のセキュリティ要件のある環境)に基づいて有効なSSLまたはTLSプロトコルを指定できます。
2.1.4 プロファイルの認証
Oracleバックエンド・ディレクトリでは、統合プロファイルは、識別名(DN)とパスワードを持つユーザーを表します。
プロファイルにアクセスできるユーザーは次のとおりです。
-
Oracle Directory Integration Platformの管理者。
バックエンド・ディレクトリでは、管理者は
cn=dipadmin,cn=dipadmins,cn=directory integration platform,cn=products,cn=oraclecontext
というDNで表されます。 -
Oracle Directory Integration Platform管理者グループのメンバー。
バックエンド・ディレクトリでは、管理者グループは
cn=odisgroup,cn=dipadmins,cn=directory integration platform,cn=products,cn=oraclecontext
というDNで表されます。
Oracle Directory Integration Platformが統合プロファイルに基づいてOracleバックエンド・ディレクトリにデータをインポートする場合、その統合プロファイルとしてディレクトリにプロキシ・バインドします。Oracle Directory Integration Platformは、SSLモードでも非SSLモードでもバインドできます。
2.2 アクセス制御、認可およびOracle Directory Integration Platformについて
認可は、ユーザーが権限を持つ情報のみの読取りまたは更新を行うことを保証するプロセスです。
ディレクトリ・セッション内でディレクトリ操作が行われようとすると、ディレクトリ・サーバーは、その操作の実行に必要な権限がユーザーに与えられていることを確認します(ユーザーの識別は、セッションに対応付けられた認可識別子によって行われます)。ユーザーに権限がない場合、ディレクトリ・サーバーはこれらの操作を許可しません。この方法(アクセス制御)によって、ディレクトリ・サーバーは、ディレクトリ・ユーザーによる不正操作からディレクトリ・データを保護します。
-
Oracle Unified Directoryがバックエンド・ディレクトリとして使用される場合、一部の権限がOracle Directory Integration Platformユーザーに割り当てられます。詳細は、『Oracle Unified Directoryの管理』のrootユーザーと特権サブシステムの理解に関する項を参照してください。
-
Oracle Internet Directoryがバックエンド・ディレクトリとして使用される場合、アクセスをOracle Internet Directoryデータの必要なサブセットのみに制限するには、Directory Integration Serverとコネクタの両方に対する適切なアクセス・ポリシーをディレクトリに設定します。
次の項では、これらのポリシーについて説明します。
2.2.1 Oracle Directory Integration Platformのアクセス制御の理解
Oracle Directory Integration Platformは、ディレクトリへのバインドをそれ自身として行う場合と、プロファイルのかわりに行う場合があります。
-
それ自身としてバインドする場合、様々な統合プロファイルに情報をキャッシュできます。これによって、Directory Integration Serverは、様々なコネクタによって実行される同期アクションをスケジュールできます。
-
Oracle Unified Directoryと接続するときに、Directory Integration Serverがプロファイルのかわりに動作する場合、Directory Integration Serverはプロファイルのプロキシとして動作します(プロファイル資格証明を使用してディレクトリにバインドし、様々な操作を実行します)。Directory Integration Serverは、プロファイルで許可されているディレクトリでそれらの操作のみを実行できます。
-
Oracle Unified DirectoryまたはOracle Directory Server Enterprise Editionと接続するときに、Directory Integration Serverは、Oracle Directory Integration Platformユーザーを使用してバインドし、プロキシ認可v2制御(RFC 4370)を使用して、プロファイルとして機能するディレクトリ・サーバーに対してアクションを実行します。
Directory Integration Serverに付与されるアクセス権限を設定し管理するために、Oracle Directory Integration Platformはインストール時にodisgroup
と呼ばれるグループ・エントリを作成します。Directory Integration Serverは、登録時にこのグループのメンバーになります。
バックエンド・ディレクトリで、odisgroup
のDNは次のとおりです。
cn=odisgroup,cn=directory admins,cn=directory integration platform,cn=products,cn=oraclecontext
odisgroup
エントリにアクセス制御ポリシーを配置することによって、Directory Integration Serverに付与されるアクセス権限を制御します。デフォルトのポリシーは、プロファイルにアクセスするための様々な権限をDirectory Integration Serverに付与します。たとえば、デフォルトのポリシーは、Directory Integration ServerがOracleバックエンド・ディレクトリと、プロファイルのかわりにプロキシとしてバインドされる接続ディレクトリとの間でユーザー・パスワードを比較できるようにします。また、Directory Integration Serverが、最終正常実行時間や同期ステータスなどのプロファイルのステータス情報を変更できるようにします。
2.2.2 プロファイルのアクセス制御の理解
インストール時に、Oracle Directory Integration Platformは、様々なプロファイルに付与されるアクセス権限の制御を可能にするodipgroup
と呼ばれるグループ・エントリを作成します。
セキュリティを追加するために、dipConfigurator
コマンドを使用してodipigroup
グループおよびodipegroup
グループも構成時に作成されます。すべてのインポート・プロファイルはodipigroup
グループに割り当てられ、すべてのエクスポート・プロファイルはodipegroup
グループに割り当てられます。権限は、odipgroup
エントリに適切なアクセス・ポリシーを配置することによって制御されます。デフォルトのアクセス・ポリシー(製品とともに自動的にインストールされる)は、所有する統合プロファイルに対する特定の標準アクセス権限をプロファイルに付与します。このような権限の1つとして、orclodipConDirLastAppliedChgTime
という名前のパラメータなどの統合プロファイルのステータス情報を変更する機能があります。また、デフォルトのアクセス・ポリシーは、プロファイルがバックエンド・ディレクトリの変更ログにアクセスできるようにします(これ以外の場合、バックエンド・ディレクトリへのアクセスは制限されます)。
関連項目:
-
『Oracle Fusion Middleware Oracle Unified Directory管理者ガイド』の「データへのアクセスの制御」の章。
-
『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の「ディレクトリ・アクセス制御の管理」の章。
-
Oracle Fusion Middleware Oracle Directory Server Enterprise Edition管理者ガイドの「Directory Serverのアクセス制御」の章。
2.3 データ整合性とOracle Directory Integration Platformについて
Oracle Directory Integration Platformは、SSLを使用して、送信時にデータの変更、削除または再現が行われていないことを保証します。このSSL機能は、暗号方式の保護メッセージ・ダイジェストを、Message-Digest algorithm 5(MD5)またはSecure Hash Algorithm(SHA)を使用する暗号チェックサムを使用して生成し、ネットワークを介して送信する各パケットにそのメッセージ・ダイジェストを組み込みます。
2.4 データ・プライバシとOracle Directory Integration Platformについて
Oracle Directory Integration Platformは、SSLで使用可能な公開キー暗号を使用して、データが送信中に開示されないことを保証します。公開キー暗号では、メッセージの送信側が受信側の公開キーを使用してメッセージを暗号化します。メッセージが送達されると、受信側は、受信側の秘密キーを使用して、メッセージを復号化します。
Directory Integration Serverとディレクトリの間でデータを安全に交換するには、両方のコンポーネントを同じSSLモードで実行する必要があります。
2.5 ツール・セキュリティとOracle Directory Integration Platformについて
一般的に使用されているツール(Oracle Enterprise Manager Fusion Middleware Controlを含む)は、すべてSSLモードで実行することによりバックエンド・ディレクトリにデータを安全に送信できます。
2.6 Oracle Directory Integration Platformの資格証明ストア・フレームワーク
Oracle Directory Integration PlatformではOracle Fusion Middlewareインフラストラクチャの資格証明ストア・フレームワークが使用されます。Oracle Directory Integration Platformによってこの資格証明ストア・フレームワークに格納される資格証明について説明します。
Oracle Directory Integration Platformによってこの資格証明ストア・フレームワークに格納される資格証明および説明を次に示します。
-
Oracle Directory Integration Platformのユーザー名:
cn=odisrv,cn=Registered Instances,cn=Directory Integration Platform,cn=products,cn=oraclecontext
-
Oracle Directory Integration Platformのユーザー・パスワード。このパスワードはインストール時に作成されるもので、読取り専用として格納され、ランタイム操作で読み取られます。
-
JKSパスワード。JKSのパスワードは、Oracleバックエンド・ディレクトリまたはサード・パーティ・ディレクトリへの接続に対して、サーバーのみ(モード2)SSL設定が構成されている場合に使用されます。WebLogic Scripting Tool(WLST)の
createCred()
コマンドを使用して、キーストアのパスワードを資格証明ストア・フレームワークに書き込むことができます。たとえば、WLSTシェルを呼び出し、connect()
コマンドを使用してOracle WebLogic Administration Serverに接続した後で、次のように入力します。createCred(map="dip", key="jksKey", user="jksUser", password="password", desc="DIP SSL JKS")
表2-2 createCredコマンド
引数 説明 map
資格証明のマップ名(フォルダ)を指定します。
mapオプションは固定されており、サポートされる値は
dip
のみです。key
資格証明のキー名を指定します。
keyオプションは固定されており、サポートされる値は
jksKey
のみです。user
資格ユーザー名を指定します。
user
属性はキーストアへのアクセスには使用されず、JKS password
属性がキーストアへのアクセスに使用されます。user
には任意の値を指定できます。password
資格のパスワードを指定します。キーストアへのアクセスには
password
属性が使用されます。desc
資格を説明する文字列を指定します。
キーストア・パスワードを新しい値に変更するには、
updateCred()
コマンドを実行します。updateCred(map="dip", key="jksKey", user="jksUser", password="password"
ノート:
-
『Oracle Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護』の「Oracle Fusion Middleware監査フレームワークの概要」を参照してください。
-
WLSTコマンドの詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』を参照してください。
-