ここでは、デプロイの際に AEM インストールのセキュリティを確保するために必要となる様々な手順について説明します。このチェックリストは、上から順に適用するように設計されています。
開発段階に適用されるその他のセキュリティに関する考慮事項も参照してください。
詳しくは、実稼動準備モードでの AEM の実行を参照してください。
インスタンスの安全を確保するには、オーサーインスタンスとパブリッシュインスタンスの両方の HTTPS トランスポート層を有効にする必要があります。
詳しくは、HTTP over SSL の有効化を参照してください。
アドビが提供する最新のセキュリティホットフィックスがインストールされていることを確認してください。
インストール後に、(すべてのインスタンスに対する)権限のある AEM admin
アカウントのパスワードを変更することを強くお勧めします。
以下のアカウントが該当します。
AEM admin
アカウント
AEM管理者アカウントのパスワードを変更した後は、CRXにアクセスする際に新しいパスワードを使用する必要があります。
OSGi Webコンソールのadmin
パスワード
この変更は、Webコンソールへのアクセスに使用する管理者アカウントにも適用されるので、アクセスする際に同じパスワードを使用する必要があります。
これらの 2 つのアカウントは、個別の資格情報を使用する異なるアカウントです。デプロイメントをセキュリティで保護するには、それぞれに強力なパスワードを設定することが不可欠です。
AEM の admin アカウントのパスワードは、Granite の操作 - ユーザーコンソールで変更できます。
このコンソールでは、admin
アカウントの編集とパスワードの変更をおこなうことができます。
admin アカウントを変更すると、OSGi Web コンソールのアカウントも変更されます。admin アカウントの変更後は、OSGi アカウントを変更してください。
AEM admin
アカウントとは別に、OSGi Web コンソールのデフォルトのパスワードを変更しない場合は、次の問題が発生する可能性があります。
Web コンソールのパスワードの変更について詳しくは、以下の OSGi Web コンソールの admin パスワードの変更を参照してください。
また、Webコンソールへのアクセスに使用するパスワードも変更する必要があります。これは、Apache Felix OSGi管理コンソールの次のプロパティを設定することで行います。
ユーザー 名と パスワード。Apache Felix Web Management Consoleにアクセスするための秘密鍵証明書です。
インスタンスのセキュリティを確保するために、最初のインストール後にパスワードを変更する必要があります。
次の手順を実行します。
<server>:<port>/system/console/configMgr
にあるWebコンソールに移動します。
Apache Felix OSGi Management Consoleに移動し、ユーザー名とパスワードを変更します。
「Save」をクリックします。
情報が開示されないようにするには、(404 および 500 HTTP 応答コード専用の)カスタムエラーハンドラーページを定義することをお勧めします。
詳しくは、カスタムスクリプトまたはエラーハンドラーの作成方法に関するナレッジベースの記事を参照してください。
AEM ディスパッチャーはインフラストラクチャの重要な部分です。ディスパッチャーのセキュリティチェックリストを確認することを強くお勧めします。
Dispatcher を使用して「.form」セレクターを無効にする必要があります。
AEM の標準インストールでは、admin
をデフォルトのレプリケーションエージェント内のトランスポート資格情報のユーザーとして指定します。また、admin ユーザーはオーサーシステムでレプリケーションのソースを特定する場合にも使用されます。
セキュリティを考慮して、特定の使用事例に対応するように両方のユーザーを変更してください。その際の注意事項を次に示します。
トランスポートユーザーは管理者ユーザーにしないでください。代わりに、パブリッシュシステムの関連する部分へのアクセス権限のみを持つユーザーをパブリッシュシステムに設定し、そのユーザーの秘密鍵証明書をトランスポートに使用します。
バンドルされたレプリケーション受信者ユーザーから開始し、状況に合わせてそのユーザーのアクセス権限を設定できます。
レプリケーションユーザーまたはエージェントユーザー ID も admin 以外のユーザー(ただし、レプリケーションされるコンテンツの確認のみ可能なユーザー)にする必要があります。レプリケーションユーザーは、レプリケーション対象のコンテンツを、発行者に送信する前に作成者システムで収集するために使用します。
AEM 6 には新しく操作ダッシュボードが導入されています。このダッシュボードは、システムオペレーターが問題のトラブルシューティングやインスタンスのヘルスの監視をおこなうためのものです。
また、このダッシュボードには一連のセキュリティヘルスチェック機能が用意されています。実稼動インスタンスの運用を開始する前に、すべてのセキュリティヘルスチェックのステータスを確認しておくことをお勧めします。詳しくは、操作ダッシュボードのドキュメントを参照してください。
実稼動システムを公開する前に、そのシステム上のすべてのサンプルコンテンツ/ユーザー(Geometrixx プロジェクトやそのコンポーネントなど)を完全にアンインストールして削除しておく必要があります。
実稼動のオーサーシステムとパブリッシュシステムへのアクセスを可能にする前に、それらの両方のシステムで、以下の開発用 OSGi バンドルをアンインストールしておく必要があります。
AEM Developer Tools for Eclipse は Apache Sling Tooling Support Install(org.apache.sling.tooling.support.install)をデプロイします。
実稼動のオーサーシステムとパブリッシュシステムへのアクセスを可能にする前に、それらの両方のシステムで、この OSGi バンドルをアンインストールしておく必要があります。
AEM 6.1 には、クロスサイトリクエストフォージェリから保護する CSRF 対策フレームワークと呼ばれるメカニズムが搭載されています。使用方法について詳しくは、ドキュメントを参照してください。
CRX WebDAV および Apache Sling のクロスサイトリクエストフォージェリ(CSRF)に関する既存のセキュリティ問題に対応するには、リファラーフィルターを使用するために設定を追加する必要があります。
リファラーフィルターサービスは OSGi のサービスの 1 つであり、次の設定が可能です。
フィルター処理する HTTP メソッド
空のリファラーヘッダーを使用できるかどうか
サーバ・ホストに加えて、サーバのリストも許可されます。
デフォルトでは、localhostとサーバーがバインドされる現在のホスト名のすべてのバリエーションがリスト内にあります。
リファラーフィルターサービスを設定するには:
次の場所にあるApache Felixコンソール(設定)を開きます。
https://<server>:<port_number>/system/console/configMgr
admin
としてログインします。
Configurations メニューで、次の項目を選択します。
Apache Sling Referrer Filter
「Allow Hosts
」フィールドに、リファラーとして許可するすべてのホストを入力します。各エントリは、次の形式にする必要があります。
<protocol>://<server>:<port>
次に例を示します。
https://allowed.server:80
の場合、特定のポートを使用して、このサーバーからの要求がすべて許可されます。0
を使用できます。空の、または欠落しているリファラーヘッダーを許可する場合は、「Allow Empty
」フィールドを選択します。
空の値を許可するのではなく cURL
などのコマンドラインツールを使用する場合は、リファラーを指定することをお勧めします。これは、システムが CSRF 攻撃を受ける可能性があるためです。
「Filter Methods
」フィールドを使用して、このフィルターがチェックに使用する方法を編集します。
「保存」をクリックして変更を保存します。
一部の OSGi 設定は、アプリケーションのデバッグを容易におこなえるようにデフォルトで設定されます。実稼動のパブリッシュインスタンスとオーサーインスタンスでは、これらの設定を変更して、内部情報が公開されないようにする必要があります。
Day CQ WCM Debug Filter を除く以下のすべての設定は、自動的に実稼動準備モードの対象になります。このため、インスタンスを実稼動環境にデプロイする前にすべての設定を見直すことをお勧めします。
以下に示す各サービスについて、記載されている設定を変更してください。
Adobe Granite HTML Library Manager:
Apache Sling Java Script Handler:
Apache Sling JSP Script Handler:
詳しくは、OSGi 設定を参照してください。
AEM を操作しているときは、このようなサービスの設定を管理する方法がいくつかあります。詳細および推奨事項については、OSGi の設定を参照してください。
サービス拒否(DoS)攻撃は、対象となるユーザーがコンピューターリソースを使用できない状態にするものです。多くの場合、この攻撃ではリソースを過負荷状態にします。次に例を示します。
外部のソースから大量の要求を送信する。
システムが正常に提供可能な量を超える情報を要求する。
例えば、リポジトリ全体の JSON 表現を要求します。
無制限の数の URL を含むコンテンツページを要求する。URL にはハンドル、複数のセレクター、拡張子およびサフィックスを含めることができます。それらのいずれかを変更できます。
例えば、.../en.html
は次のように要求することもできます。
.../en.ExtensionDosAttack
.../en.SelectorDosAttack.html
.../en.html/SuffixDosAttack
有効なすべてのバリエーション(例えば、200
という応答が返され、バリエーションをキャッシュするように設定されている場合)がディスパッチャーによってキャッシュされるので、最終的にはファイルシステムがいっぱいになり、以降の要求に対してサービスを提供できなくなります。
このような攻撃を防ぐための設定のポイントは多数ありますが、ここでは AEM に直接関連する設定についてのみ説明します。
DoS を防ぐための Sling の設定
Sling はコンテンツ中心型です。**つまり、(HTTP)要求がそれぞれ JCR リソース(リポジトリノード)の形式でコンテンツにマップされるので、コンテンツに焦点を当てた処理がおこなわれるということです。
詳しくは、Sling の要求処理を参照してください。
このアプローチにより Sling が強化され、柔軟性も向上しますが、これまでどおり柔軟性の管理には注意が必要です。
DoS の悪用を防ぐ方法は次のとおりです。
アプリケーションレベルで制御を組み込みます。バリエーションの数が原因で、デフォルト設定が適していない可能性があります。
アプリケーションで必要な処理は次のとおりです。
404
を返します。問題点となっている可能性のあるデフォルトのレンダラーの設定を確認します。
具体的には、ツリー構造が複数のレベルに及ぶ JSON レンダラーです。
例えば、リクエストは次のようになります。
http://localhost:4502/.json
リポジトリ全体をJSON表現でダンプできました。 これにより、サーバーで重大な問題が発生します。そのため、Sling では結果の最大数に制限を設定します。JSONレンダリングの深さを制限するには、次の値を設定します。
JSONの最大結果 ( json.maximumresults
)
Apache SlingGETサーブレットの設定に含まれています。 この制限を超えると、レンダリングは行われません。AEM 内での Sling 用のデフォルト値は 200
です。
予防策として、デフォルトの他のレンダラー(HTML、プレーンテキスト、XML)を無効にします。この場合も Apache Sling GET Servlet を設定します。
JSON レンダラーを無効にしないでください。これは AEM の通常の処理に必要なレンダラーです。
ファイアウォールを使用してインスタンスへのアクセスをフィルタリングします。
フォームセレクターを使用することで生じる DoS を軽減
この軽減策は、Forms を使用していない AEM 環境でのみ実行するべきです。
AEM は FormChooserServlet
用の標準インデックスを提供していないため、クエリでフォームセレクターを使用すると、高コストのリポジトリートラバーサルが発生し、大抵の場合 AEM インスタンスが停止します。フォームセレクターは、*.formの存在によって検出できます。クエリ内の*文字列。
これを軽減するために、以下の手順に従ってください。
Webコンソールに移動し、ブラウザでhttps://<serveraddress>:<serverport>/system/console/configMgrを指定します。
Day CQ WCM Form Chooser Servlet を検索します。
エントリをクリックした後、次のウィンドウで「Advanced Search Require」を無効にします。
「保存」をクリックします。
アセットダウンロードサーブレット使用することで生じる DoS を軽減
AEM のデフォルトアセットダウンロードサーブレットを使用すると、認証されたユーザーは、表示可能なアセットの ZIP ファイルを作成するために任意のサイズの同時ダウンロード要求を発行することができますが、その結果、サーバーやネットワークに過剰な負荷をかけるおそれがあります。
この機能で生じる可能性がある DoS リスクを軽減するために、最新の AEM バージョンでは、パブリッシュインスタンスに対して、AssetDownloadServlet
OSGi コンポーネントがデフォルトで無効になっています。
セットアップでアセットダウンロードサーブレットを有効にする必要がある場合、詳細についてはこの記事をご覧ください。
WebDAV は、オーサリングとパブリッシュの両方の環境で無効にする必要があります。そのためには、適切な OSGi バンドルを停止します。
Felix Management Console に接続します。
https://<*host*>:<*port*>/system/console
例えば、http://localhost:4503/system/console/bundles
のように指定します。
バンドルのリストで、次の名前のバンドルを探します。
Apache Sling Simple WebDAV Access to repositories (org.apache.sling.jcr.webdav)
(「Actions」列にある)停止ボタンをクリックして、このバンドルを停止します。
再び、バンドルのリストで、次の名前のバンドルを探します。
Apache Sling DavEx Access to repositories (org.apache.sling.jcr.davex)
停止ボタンをクリックして、このバンドルを停止します。
AEM の再起動は不要です。
ユーザーの保護に重要なのは、リポジトリユーザーのホームパスに個人を特定できる情報を公開しないことです。
AEM 6.1 以降では、新しく実装された AuthorizableNodeName
インターフェイスにより、ユーザー ID(または許可可能 ID)のノード名を保存する方法が変わりました。新しいインターフェイスでは、ノード名にユーザー ID を表示する代わりに、ランダムな名前を生成します。
これは現在は AEM で許可可能 ID を生成するデフォルトの方法なので、これを有効にするために設定を変更する必要はありません。
推奨されませんが、既存のアプリケーションとの後方互換性確保のために以前の実装が必要な場合は、この機能を無効にすることもできます。これをおこなうには、次の手順を実行する必要があります。
Webコンソールに移動し、Apache Jackrabbit Oak SecurityProviderのプロパティrequiredServicePidsから org.apache.jackrabbit.oak.security.user.RandomAuthorizableNodeNameエントリを削除します。
また、OSGi 設定の org.apache.jackrabbit.oak.security.internal.SecurityProviderRegistration PID を探すことで、Oak Security Provider を見つけることもできます。
Web コンソールから Apache Jackrabbit Oak Random Authorizable Node Name OSGi 設定を削除します。
この設定の PID である org.apache.jackrabbit.oak.security.user.RandomAuthorizableNodeName を検索すると、簡単に該当箇所が見つかります。
詳しくは、「Oak Documentation」のAuthorizable Node Name Generation(英語)を参照してください。
クリックジャッキングを防ぐには、SAMEORIGIN
に設定した HTTP ヘッダー X-FRAME-OPTIONS
を指定するように Web サーバーを設定することをお勧めします。
クリックジャックに関する詳細は、OWASPサイトを参照してください。
特定の AEM 機能および認証スキームでは、すべての AEM インスタンスに暗号鍵をレプリケーションする必要があります。
これをおこなう前に、6.3 とそれ以前のバージョンでは鍵を保存する方法が異なるので、鍵のレプリケーションはバージョン間で異なることに注意してください。
詳しくは、以下を参照してください。
以前のバージョンではレプリケーション鍵はリポジトリに保存されましたが、AEM 6.3 からはファイルシステム上に保存されます。
したがって、インスタンス間で鍵をレプリケーションするには、ソースインスタンスからターゲットインスタンスのファイルシステム上の場所に鍵をコピーする必要があります。
具体的には、以下をおこなう必要があります。
コピーする鍵要素を含む AEM インスタンス(通常はオーサーインスタンス)にアクセスします。
ローカルファイルシステム内で、com.adobe.granite.crypto.file を見つけます。例えば、次のパスにあります。
<author-aem-install-dir>/crx-quickstart/launchpad/felix/bundle21
各フォルダー内の bundle.info
ファイルは、バンドル名を示します。
データフォルダーに移動します。次に例を示します。
<author-aem-install-dir>/crx-quickstart/launchpad/felix/bundle21/data
HMAC とマスターファイルをコピーします。
次に、HMAC 鍵の複製先となるターゲットインスタンスにアクセスし、データフォルダーに移動します。次に例を示します。
<publish-aem-install-dir>/crx-quickstart/launchpad/felix/bundle21/data
前の手順でコピーした 2 つのファイルを貼り付けます。
ターゲットインスタンスが既に実行されている場合は、Crypto バンドルを更新します。
鍵のレプリケーション先のすべてのインスタンスに対して上記の手順を繰り返します。
最初に AEM をインストールするときに次のパラメーターを追加することによって、6.3 よりも前の鍵の保存方法に戻すことができます。
-Dcom.adobe.granite.crypto.file.disable=true
AEM 6.2以前のバージョンでは、キーは/etc/key
ノードの下のリポジトリに保存されます。
インスタンス全体で鍵を安全にレプリケーションするために推奨される方法は、このノードのみをレプリケーションすることです。CRXDE Lite によって、ノードを選択してレプリケーションできます。
/etc/key
ノードを選択します。実稼動に移行する前に、AEM インフラストラクチャの侵入テストを実施することを強くお勧めします。
AEM 環境の安全を確保するには、新規開発においてセキュリティのベストプラクティスに従うことが重要です。