Cloud Software Group, Inc. EBX®

ドキュメント > セキュリティガイド

ナビゲーションモードドキュメント > セキュリティガイド

セキュリティのベストプラクティス

ここでは、EBX® セットアップに適切なセキュリティレベルを適用するのに役立つと考えられるベストプラクティスのリストを掲載します。これらのベストプラクティスは、EBX® およびその他の環境、それらの構成、プロトコル、およびポリシーに適用されます。これらのプラクティスは一般的に有益であると見なされていますが、特定のインフラストラクチャーおよびセキュリティポリシーに関連していない場合があります。

暗号化アルゴリズム
HTTPS
インストール
Web サーバー
アプリケーションサーバー
Java
データベース
アーカイブディレクトリ
ユーザーディレクトリと管理者権限
権限

暗号化アルゴリズム

Web サーバーまたはアプリケーションサーバーは、HTTPS パラメーターを設定するときに暗号化アルゴリズムを指定する場合があります。これらのアルゴリズムに関するいくつかの推奨事項は、HTTPS セクションに記載されています。タイプとして osd:password を持つパスワードとフィールドは、SHA_512 アルゴリズムを使用して、それらの値のハッシュを格納します。これは特に、デフォルトディレクトリのユーザーのパスワードの場合です。

HTTPS

クライアントとの通信には HTTPS を使用することをお勧めします (GUI および REST または SOAP)。すべての HTTP トラフィックは HTTPS にリダイレクトする必要があります。

安全な暗号スイートとプロトコルを可能な限り使用する必要があります。これは、たとえば、Webサーバー、アプリケーションサーバー、および JDBC 接続に適用されます。

TLS v1.2 は、最新の認証済み暗号化 (AEAD とも呼ばれる) を提供する唯一のバージョンであるため、メインプロトコルである必要があります。

いくつかの廃止された暗号化プリミティブは回避する必要があります。

匿名の Diffie-Hellman (ADH) スイートは認証を提供しません。
NULL 暗号スイートは暗号化を提供しません。
エクスポート暗号スイートは、接続でネゴシエートされると安全ではありませんが、より強力なスイートを優先するサーバーに対しても使用できます (FREAK 攻撃)。
耐性の低い暗号 (通常は 40 ビットと 56 ビット) を使用するスイートは、簡単に破られる可能性のある暗号化を使用します。
RC4 は安全ではありません。
3DES は低速かつ脆弱です。

一方、許可された暗号を制限しすぎると、HTTPS 接続をネゴシエートできない可能性があるため、一部のクライアントが接続できなくなる可能性があります。

以下の構成は、EBX® でサポートされているブラウザーと互換性があります。

暗号化スイート：ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
バージョン：TLSv1.2

インストール

Web サーバーやアプリケーションサーバーなどの展開済みコンポーネントは、root 以外のユーザーまたは権限のないユーザーを使用して、可能な限り最小権限の原則に従ってインストールする必要があります。たとえば、必要なポートとプロトコルのみを開く必要があります。

Web サーバー

インターネット上で Web アプリケーションを公開する必要がある場合は、DMZ (非武装地帯) の Web サーバーでそれらを保護することをお勧めしますが、EBX® とデータベースサーバーは実稼働ゾーンに置くことができます。構成については、次の方法を検討してください。

安全な暗号スイートとプロトコルは、上記の HTTPS セクションに従って設定する必要があります。

デフォルトの構成を使用しないでください。また、Web サーバーのバージョンとタイプを公開する可能性のあるバナーを削除してください。

たとえば、Apache2 では、バナー (ルートに返されるデフォルトのページ) を削除するには、フォルダー /var/www/html を削除するだけです。

また、Apache2 では、Web サーバーを識別するヘッダーを削除するために、ファイルから ServerTokens と ServerSignature の値を削除します。security.conf の値は次のとおりです。

# ServerTokens
# This directive configures what you return as the Server HTTP response
# Header. The default is 'Full' which sends information about the OS-Type
# and compiled in modules.
# Set to one of:  Full | OS | Minimal | Minor | Major | Prod
# where Full conveys the most information, and Prod the least.
ServerTokens Prod

# Optionally add a line containing the server version and virtual host
# name to server-generated pages (internal error documents, FTP directory
# listings, mod_status and mod_info output etc., but not CGI generated
# documents or custom error documents).
# Set to "EMail" to also include a mailto: link to the ServerAdmin.
# Set to one of:  On | Off | EMail
ServerSignature Off

Web サーバーを使用して、HTTP セキュリティヘッダーで制限を設定します。オリジンに関連するヘッダーは、EBX® によって返されるすべてのリソースの許可された URL に影響を与えることに注意してください。これには、URL タイプのフィールドのコンテンツが含まれます (例：アバターの画像)。

セキュリティヘッダーのリストと、EBX® 用にそれらを設定する方法は次のとおりです。まず、HTTP セキュリティヘッダーを設定しないように EBX® を構成します。これを行うには、プロパティ ebx.security.headers.activate を false に設定するか、設定を解除します。

X-XSS-Protection

x-xss-protection ヘッダーは、最新の Web ブラウザーに組み込まれているクロスサイトスクリプティング (XSS) フィルターを有効にするように設計されています。ヘッダーは次のようになります。

x-xss-protection: 1; mode=block

Nginx での有効化

proxy_hide_header x-xss-protection;
add_header x-xss-protection "1; mode=block" always;

Apache2 での有効化

header always unset x-xss-protection
header always set x-xss-protection "1; mode=block"

x-Frame-Options

x-frame-options ヘッダーは、iframe がサイトに読み込まれないようにすることで、クリックジャッキング保護を提供します。たとえば、EBX® がフレームを介して統合されている場合、これは構成と互換性がない可能性があることに注意してください。ヘッダーは次のようになります。

x-frame-options: SAMEORIGIN

Nginx での有効化

add_header x-frame-options "SAMEORIGIN" always;

Apache2 での有効化

header always set x-frame-options "SAMEORIGIN"

X-Content-Type-Options

x-content-type-options ヘッダーは、Internet Explorer と Google Chrome が宣言されたコンテンツタイプから応答をスニッフィングするのを防ぎます。これにより、ドライブバイダウンロードの危険性が軽減され、コンテンツが適切に処理されます。ヘッダーは次のようになります。

x-content-type-options: nosniff

Nginx での有効化

add_header X-Content-Type-Options "nosniff" always;

Apache2 での有効化

header always set X-Content-Type-Options "nosniff"

Strict-Transport-Security

strict-transport-security ヘッダーは、HTTPS 経由でのみ Web サーバーにアクセスするように Web ブラウザーを制限するセキュリティ拡張機能です。これにより、攻撃に対して脆弱である可能性のある安全でない HTTP 接続を介して接続を確立できなくなります。ヘッダーは次のようになります。

strict-transport-security: max-age=31536000; includeSubDomains

Nginx での有効化

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Apache2 での有効化

header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

Content-Security-Policy

content-security-policy HTTP ヘッダーは、セキュリティの追加レイヤーを提供します。このポリシーは、承認されたコンテンツソースを定義し、ブラウザがそれらをロードできるようにすることで、クロスサイトスクリプティング (XSS) やその他のコードインジェクション攻撃などの攻撃を防ぐのに役立ちます。ヘッダーは次のようになります。必ずドメイン名 (例では server.company.com) に適合させてください。

content-security-policy: default-src 'self'; font-src * data: server.company.com; img-src * data: server.company.com; script-src * 'unsafe-inline' 'unsafe-eval'; style-src * 'unsafe-inline';

Nginx での有効化

add_header Content-Security-Policy "default-src 'self'; font-src * data: server.company.com; img-src * data: server.company.com; script-src * 'unsafe-inline' 'unsafe-eval'; style-src * 'unsafe-inline';" always;

Apache2 での有効化

header always set Content-Security-Policy "default-src 'self'; font-src * data: server.company.com; img-src * data: server.company.com; script-src * 'unsafe-inline' 'unsafe-eval'; style-src * 'unsafe-inline';"

Referrer-Policy

Referrer-Policy HTTP ヘッダーは、行われたリクエストに含めるリファラー情報を管理します。リファラーポリシーは、ユーザーが別のページにつながるリンクをクリックしたときに送信されるリファラー情報を処理する方法を Web ブラウザーに指示します。次のように指定します。

Referrer-Policy: strict-origin

Nginx での有効化

add_header Referrer-Policy: "strict-origin" always;

Apache2 での有効化

header always set Referrer-Policy "strict-origin"

Permissions-Policy

Permissions-Policy HTTP ヘッダーは、Web 開発者が iframe で使用できる機能と使用できない機能を明示的に宣言するメカニズムを提供します。サイトのコードがアクセスまたは変更できる API を制限する一連の「ポリシー」が定義され、特定の機能に対するブラウザーのデフォルトの動作が上書きされます。これは次のようになります。

Permission-Policy: "*=()"

Nginx での有効化

add_header Permissions-Policy: "*=()" always;

Apache2 での有効化

Header always set Permissions-Policy "*=()"

この値はニーズに応じて変更される可能性があることに注意してください。EBX® インストールに関連 API を使用するカスタマイズされたフロントエンドコードがある場合は、それを適応させる必要がある場合があります。

アプリケーションサーバー

Web サーバーについても、同じベストプラクティスが適用されます。アプリケーションサーバーで技術情報を公開しないでください。たとえば、Tomcat の場合、server.xml の connector の属性 server に一般的な値 AppServer を入力することをお勧めします。

 <Connector port="8080" enableLookups="false" protocol="HTTP/1.1" useBodyEncodingForURI="true" server="AppServer"/>

アプリケーションサーバーが HTTPS を介して公開されている場合は、上記のセクション HTTPS に従って安全な暗号スイートとプロトコルを設定する必要があります。

Web サーバーがある場合は、1024 を超えるポートを使用し、Web サーバーにプロキシを実行させることもお勧めします。

Web サーバーがない場合は、上記のようにアプリケーションサーバーがセキュリティヘッダーを設定する必要があります。

Java

Oracle のセキュリティのベストプラクティスに従うことをお勧めします。最後にサポートされたパッチも、特にセキュリティパッチが含まれている場合は、利用可能になり次第適用する必要があります。アプリケーションサーバーやその他の長時間実行されるバックエンドプロセスなどのサーバーシステムには、サーバー JRE の使用を検討してください。サーバー JRE は、Web ブラウザープラグインが含まれていないことを除いて、通常の JRE と同じです。

EBX® では、カスタムコードを使用して非常に高度なカスタマイズが可能です。統合されたすべての Java モジュールは、EBX® によって信頼できると見なされます。したがって、EBX® に基づくすべての開発をレビューおよび検証する必要があります。例として、開発者は適切なエスケープなしでデータベースからの値から HTML を生成するべきではありません。詳細については、Cross Site Scripting prevention on the OWASP site を参照してください。適切なエスケープの例を次に示します。ストアの名前は、HTML フォームに表示される前にエンコードされます。Apache CommonsLang に含まれている StringEscapeUtils クラスは、文字列のエンコードに使用されます。

public class StoreMainPane implements UIFormPane
{
	public static final String STORE_NAME_STYLE = "font-weight: bold; padding-top:20px; padding-bottom:20px";

	@Override
	public void writePane(final UIFormPaneWriter writer, final UIFormContext context)
	{

		String storeName = (String) context.getValueContext().getValue(Paths._Store._Name);

		writer.add("<div ").addSafeAttribute("style", STORE_NAME_STYLE).add(">");
		writer.addSafeInnerHTML("Data stored for " + storeName);
		writer.add("</div>");

		// ...
	}
}

データベース

データベースは、保存時および転送中に暗号化する必要があります。暗号化用のプライベートキーがある場合は、データファイルと同じ場所に保存しないでください。JDBC 接続に関しては、SSL/TLS を使用するように JDBC ドライバーを構成することを検討してください。詳細な手順については、データベース管理者に問い合わせてください。ドライバーを含め、常に最後にサポートされたバージョンまたは RDBMS を使用する必要があります。

アーカイブディレクトリ

アーカイブディレクトリは適切に保護され、かつ/または暗号化されている必要があります。実際、EBX® インスタンスからエクスポートされたアーカイブはすべてそこに作成され、これらのアーカイブは暗号化もパスワードによる保護もされていません。その結果、これらのファイルにアクセスできるユーザーは、EBX® で定義された権限に関係なく、コンテンツを見ることができるようになります。

ユーザーディレクトリと管理者権限

実稼働プラットフォームとテストプラットフォームの場合、EBX® をカスタムディレクトリと統合して、会社のパスワードポリシーを適用する必要があります。デフォルトのディレクトリは、開発プラットフォームでのみ使用できます。

Separation of Duties のベストプラクティスによると、管理者はユーザーを管理してアクセスを許可できますが、機能的な権限を持たないようにする必要があります。

権限

EBX® で権限を定義する場合は、特別な注意が必要です。担当者は、権限の内容、特に権限に関する重要な考慮事項セクションで提供される情報を把握している必要があります。

ドキュメント > セキュリティガイド