セキュリティ・プロトコルを何にするかの決定とそれらの実装は、WebCenter Sites管理者の重要な役割です。テンプレートのコーディングやアセット・タイプの設計を始める前に、管理者とサイト開発者は、セキュリティを管理システムと配信システムの両方に構成する方法を検討し、決定する必要があります。
この章は、次の項で構成されています。
開発者がオンライン・サイトの設計や管理システムのユーザー・インタフェースの変更の検討を開始する前に、管理者はセキュリティ・プロトコルを決定し、実装する必要があります。セキュリティ構成に関する決定は、オンライン・サイトのコード化および実装方法に影響を与えます。
定期的にシステムを確認し、それらが期待どおりに機能しているかどうかを判断する必要があります。図6-1は、セキュアなWebCenter Sitesシステムの例を示しています。
この項は、次のトピックで構成されています。
第4章「ACLおよびロールの使用」で説明したように、ACL (アクセス制御リスト)は、WebCenter Sitesシステムでセキュリティおよびユーザー管理モデルの基盤として機能します。ACLは、データベース表およびWebCenter Sitesページの両方へのアクセスを制限する権限のセットです。
ACLの制限は、futuretense.iniファイル内のcc.securityプロパティおよびsecurity.checkpageletsプロパティがtrueに設定されている場合にのみ実施されます。これらのプロパティは、デフォルトでtrueに設定されています。なんらかの理由でセキュリティを無効にする必要がある場合は、プロパティ・エディタを開き、cc.securityプロパティをfalseに設定します。ただし、サイトの開発が確実にセキュリティを有効にした状態で行われるようにするため、このプロパティはすべてのシステムでtrueのままにすることをお薦めします。
システムのセキュリティ対策を計画する際には、デフォルトのACL (第31章「システム・デフォルト」を参照)のリストを調べ、追加のACLが必要かどうかを判断します。開発者が新しい表の作成またはユーザー・インタフェースへの追加を計画している場合には、システムACLとは異なる権限の組合せでACLを作成する必要が生じる場合があります。
注意: どのような状況においても、システムのデフォルトACLを変更したり、WebCenter Sitesのシステム表またはSitesのコンテンツ・アプリケーションの表に割り当てられたACLを変更しないでください。 |
WebCenter Sitesとそのコンテンツ・アプリケーションには、いくつかのデフォルトのユーザー・アカウントが付属しており、その1つがDefaultReaderというものです。このアカウントは権限のないすべてのサイト訪問者に割り当てられます(WebCenter Sitesにホストされるサイトのすべての訪問者にWebCenter SitesのユーザーIDが必要なため)。
DefaultReaderユーザー・アカウントには、デフォルトで、BrowserおよびVisitorのACLがあります。Visitorにより、統計を目的とする訪問者の追跡が有効になります。データベース表の多くにもBrowser ACLが割り当てられており、様々なEngage表にはVisitor ACLが割り当てられているため、セキュリティの問題が生じます。これにより、DefaultReaderアカウントを使用していれば、だれでもその表内の情報を調べることが可能となります(ただし、このユーザーとして表に書き込むことはできません)。DefaultReaderユーザー・アカウントを使用してWebCenter Sitesデータベース内の表を閲覧できないようにするには、futuretense.iniファイル内の次のプロパティをtrueに設定します。
secure.CatalogManager
secure.TreeManager
これらのプロパティがtrueに設定されている場合、DefaultReaderユーザーは、読取り専用データであっても、CatalogManagerおよびTreeManagerサーブレットにはアクセスできません。
注意: Oracle WebCenter Sites: Engage ACL ( |
BLOBにセキュリティを実装する場合は、BlobServerサーブレットのセキュリティ機能を有効にする必要があります。このためには、futuretense.iniファイル内のbs.securityパラメータをtrueに設定します。
bs.security=trueの場合、BLOBのURLにその要求者が有効なユーザーとして認証されていることの証拠が含まれていなければ、BlobServerはそのBLOBの提供を拒否します。証拠とは、URL内にある、csblobid
というセッション変数と値が一致するcsblobid
パラメータからの値です。したがって、BlobServerセキュリティが有効な場合、開発者は、通常とは異なる方法で、BLOBへのリンクをコード化する必要があります。
これらのリンクをコード化する方法については、『Oracle Fusion Middleware WebCenter Sites開発者ガイド』を参照してください。
一般的には、WebCenter Sitesシステム(開発システム、管理システムおよび配信システム)ごとに、異なるセキュリティの目的があります。
この項は、次のトピックで構成されています。
開発システムは一般的にはファイアウォールの内側にありますが、開発システムにおいても、開発者が設計対象とするシステム(管理または配信)で実装されるものと同じセキュリティ構成を実装する必要があります。なぜでしょうか。両方のシステムで条件を同じにすることで、コードがターゲット・システムで適切に機能するようにするためです。
配信システムでBlobServerセキュリティの使用を計画している場合、BLOBのURLを作成するテンプレートは異なる方法でコード化する必要があります。したがって、開発システムでもBlobServerセキュリティを有効にする必要があります。
オンライン・サイトで、訪問者が自分自身を識別することが要求される場合、開発システムには、配信システムで使用するものと同じセキュリティ構成が必要です。
管理システムのセキュリティには、次の2つの主な概念が含まれています。
有効なWebCenter Sitesユーザーのみがシステムにアクセスできるようにする(この章で説明します)。
有効なユーザーが、そのユーザーに適した機能のみにアクセスできるようにする。詳細は、第4章「ACLおよびロールの使用」を参照してください。
サイトを一般に配信する際には、訪問者はサイト上のコンテンツにアクセスできるようにする一方、ハッカーが公開しない領域にアクセスできないようにすることも必要なため、元来配信システムでの警戒はより厳しいものとなります。
配信システムを構成する際には、WebCenter Sitesのユーザー・インタフェースを無効にし、このインタフェースや開発者ツールを使用してアセットやコードを追加できないようにします。さらに、一部のWebCenter Sitesサーブレットへのアクセスを制限します。
この項では、実装することになったセキュリティ対策を構成するために必要な手順を説明します。これには、プロパティの設定、デフォルトのユーザー・アカウントのパスワードの変更、企業ネットワーク外にアクセスできるシステムに対するSSLの使用、特定のWebCenter SitesサーブレットのURLのマッピング、および配信システム上のアプリケーションの特定部分の無効化があります。
各項では、どのシステムでどの手順を実行するのかが示されています。
この項は、次のトピックで構成されています。
この項では、様々なセキュリティを実装するfuturetense.iniファイル内のプロパティを構成する方法を説明します。
すべてのシステム対象
プロパティ・エディタを使用して、futuretense.iniファイルを開き、次のプロパティがtrueに設定されていることを確認します。
cc.security
security.checkpagelets
secure.CatalogManager
secure.TreeManager
BlobServerセキュリティの使用を計画している場合は、次のプロパティをtrueに設定します。
bs.security
セッション・タイムアウト値が各システムに適した値になるよう、次のプロパティも設定します。
cs.timeout
開発システムおよび管理システムでは、支障なく設定できると考えられるかぎり長いタイムアウト値を設定します。配信システムでは、訪問者にフラストレーションを感じさせることなく可能なかぎり短いタイムアウト値を設定します。
配信システムの場合
前の項で説明したプロパティに加え、配信システムでは、もう1つのプロパティ、cs.wrapperを指定します。
ラッパーとは、Webサーバー上のfuturetense_cs
ディレクトリにあるHTMLファイルです。このディレクトリには、Dev
というサブディレクトリも含まれ、これは配信システムから削除する必要があります。
ただし、配信システム上のWebサーバーからfuturetense_cs
ディレクトリ全体を削除する場合は、cs.wrapper
プロパティをfalse
に設定する必要があります。
詳細は、第6.2.5項「WebCenter Sitesフォームとページ(配信システムのみ)」を参照してください。
WebCenter Sitesのインストール後にすべてのシステムでデフォルトのユーザー・アカウントがセキュアになったことを確認してください。
すべてのシステム対象
開発、管理および配信の全システムで、次の手順を実行します。
fwadmin
ユーザー・アカウントのデフォルトのパスワードを変更します(管理者インタフェースの「管理」タブにある「ユーザー・アクセス管理」の下の「ユーザー」ノード)。
インストール時に作成されたWebCenter SitesユーザーがContentServer
という名前の場合、そのパスワードがデフォルトのパスワード(password
)ではないことを確認します。使用しているパスワードがデフォルトのパスワードの場合は、これを変更します(管理者インタフェースの「管理」タブにある「ユーザー・アクセス管理」の下の「ユーザー」ノード)。
アプリケーション・サーバーのデフォルトの管理者ユーザー名およびパスワードを変更します。
Webサーバーのデフォルトの管理者ユーザー名およびパスワードを変更します。
サンプル・サイトがインストールされている場合、サーバーへのミラーリングのパブリッシュ方法に対してミラー・ユーザーが作成されています(名前: mirroruser
、パスワード: mirroruser
)。このユーザーのパスワードを変更します。
SiteGod ACLを持つユーザー・アカウントの場合、頻繁にパスワードを変更してください(管理者インタフェースの「管理」タブにある「ユーザー・アクセス管理」の下の「ユーザー」ノード)。SiteGod ACLを持つユーザー・アカウントは、UNIX root
ユーザーのように対処してください、
注意: DefaultReaderユーザーのデフォルト・パスワードは変更しないでください。 |
管理システムおよび配信システムの場合
AviSportsおよびFirstSiteII以外のサンプル・サイトが管理システムまたは配信システムにインストールされている場合、エディタを含むすべてのサンプル・ユーザーを削除しますが、xceleditor ACLは削除しないでください。また、fwadminユーザーは削除しないでください。さらに、mirroruserユーザーのパスワードを変更します。
配信システムの場合
配信システムでは、そのシステムのシステム管理者以外のユーザーに、xceleditor ACLを割り当てないでください。WebCenter Sitesのコンテンツ・アプリケーションがその配信システムにインストールされている場合、このACLにより、このコンテンツ・アプリケーションへのアクセスが可能になります。
リモートの従業員でもアクセスできる管理システムなど、企業ネットワーク外からアクセス可能なシステムや専用データを含むシステムでは、SSLを使用して、暗号化されたセキュアな接続を確立することをお薦めします。
自己署名証明書ではなく、信頼できる機関により承認されたデジタル証明書を使用する必要があります。自己署名証明書を使用すると、次のような結果になる場合があります。
Javaによるシステムへの内部コールが失敗する可能性がある。
左側のナビゲーション・ツリーやパブリッシュなど、ユーザー・インタフェースの一部の機能が正常に動作しない可能性がある。
配信システムのWebサーバーでは、次のWebCenter Sitesサーブレットのみにアクセス権を与えるようにします。どのようにするのでしょうか。それらのURLのみをアプリケーション・サーバーにマップします。
ContentServer
BlobServer
Satellite
CookieServer
その他のWebCenter Sitesサーブレットのアプリケーション・サーバーには、URLをマップしないでください。かわりに、次のサーブレットのURLは、「404 見つかりません」ページなどのエラー・ページにマップします。
HelloCS
CatalogManager
TreeManager
DebugServer
CacheServer
Inventory
配信システムでは、必ずWebCenter Sitesアプリケーションの次の部分を無効にするか、完全に削除してください。
Webサーバーからfuturetense_cs/Dev
ディレクトリを削除します。このディレクトリには開発者にとって便利なフォームが含まれており、配信システムではこれらは不要です。
注意: このディレクトリは、アプリケーション・サーバーからは削除しないでください。削除するのはWebサーバーからのみです。 |
Webサーバーからfuturetense_cs
ディレクトリ全体を削除することもできます。(アプリケーション・サーバーからは、これを削除しないでください。)この場合、futuretense.ini
ファイルのcs.wrapper
プロパティは、必ずfalse
に設定してください(ラッパーはそのフォルダのHTMLファイルです)。これを行わない場合、サイトの訪問者には、システム・エラー・メッセージではなく、「404 ページが見つかりません」が表示されます。
SiteCatalog/OpenMarket/Xcelerate/UIFramework
に移動し、すべてのページの名前を変更します。最低でも、LoginPage
とLoginPost
の名前は変更してください。
セキュリティ対策を実装したら、システムをテストします。
すべてのシステムに対するセキュリティ・テスト
開発、管理および配信の各システムで、次の手順を実行します。
Sites Explorerで、デフォルトのユーザー・アカウントを使用して、データベースへのログインを試みます。
DefaultReader
パスワードにSomeReader
を使用してログインできる場合、secure.CatalogManager
およびsecure.TreeManager
プロパティはfalse
に設定されています。これらはtrue
に変更してください。
ContentServer
パスワードにpassword
を使用してログインできる場合は、このパスワードをただちに変更してください。
editor
パスワードにxceleditor
を使用してログインできる場合は、このパスワードをただちに変更してください。
fwadmin
パスワードにxceladmin
を使用してログインできる場合は、このパスワードをただちに変更してください。
管理システムと配信システムには、サンプル・サイト・ユーザーが存在しないことを確認します。
次のCatalogManager URLを使用して、ContentServer/password
でログインできないことを確認します。
http://<server>:<port>/<context>/CatalogManager?ftcmd=login&username=ContentServer&password=password
次のCacheServer URLを使用して、ContentServer/password
でキャッシュ全体をフラッシュできないことを確認します。
http://<server>:<port>/<context>/CacheServer?all=true&authusername=ContentServer&authpassword=password
デフォルトの管理者ユーザーとしてアプリケーション・サーバーにログインできないことを確認します。
デフォルトの管理者ユーザーとしてデータベースにログインできないことを確認します。
デフォルトの管理者ユーザーとしてWebサーバーにログインできないことを確認します。