SSL を使用するインターフェイス

Cisco Secure Malware Analytics アプライアンスには、SSL を使用する 2 つのインターフェイスがあります。

• Cisco Secure Malware Analytics ポータルの UI と API、および統合先（ESA/WSA アプライアンス、Secure Endpoint プライベートクラウド配置更新サービス）用のクリーン インターフェイス。

• Admin UI の管理 インターフェイス。

サポートされている SSL/TLS バージョン

Cisco Secure Malware Analytics アプライアンスでは、次のバージョンの SSL/TLS がサポートされています。

• TLS v1.0：管理インターフェイスでは無効（v2.7 以降）

• TLS v3.0：管理インターフェイスでは無効（v2.7 以降）

• TLS v1.2

（注）	TLS v1.0 と TLS v3.0 は、管理インターフェイスでは無効になっており（v2.7 以降）、メインアプリケーションでもデフォルトでは無効になっています。これらのプロトコルのいずれかが統合の互換性のために必要な場合は、tgsh から再有効化できます（メイン アプリケーションの場合のみ）。

サポートされているお客様提供の CA 証明書

お客様提供の CA 証明書がサポートされており（v2.0.3 以降）、お客様独自の信頼できる証明書または CA 証明書をインポートすることができます。

自己署名デフォルト SSL 証明書

Cisco Secure Malware Analytics アプライアンスは、自己署名 SSL 証明書とキーのセットがインストールされて出荷されます。1 つのセットがクリーン インターフェイス用で、もう一つのセットが管理インターフェイス用です。管理者はこれらの SSL 証明書を置き換えることができます。

デフォルトの Cisco Secure Malware Analytics アプライアンスの SSL 証明書のホスト名（共通名）は、アプライアンスのシリアル番号（IP アドレスの追加の subjectAltName フィールドを持つ）で、1 年間有効です。v2.11 より前のリリースでは、デフォルトの SSL 証明書のホスト名は pandem です。

設定時に別のホスト名が Cisco Secure Malware Analytics アプライアンスに割り当てられた場合、証明書内のホスト名と共通名は一致しなくなります。

証明書内のホスト名は、接続先の ESA や WSA、または他の統合先のシスコデバイスやサービスによって想定されるホスト名とも一致している必要があります。多くのクライアント アプリケーションは、証明書で使用される共通名が接続するアプライアンスのホスト名と一致する SSL 証明書を必要とするためです。

NFS 要件

NFS バックアップストレージへの暗号化されたバックアップを実現するには、次の NFS 要件を満たす必要があります。

• Cisco Secure Malware Analytics アプライアンスの管理インターフェイスからアクセス可能な、TCP を介した NFSv4 プロトコルを実行する必要があります。

• ルートユーザー（UID 0）のみがマウントできます。マウント時に UID 0 が許可されていることを確認してください。Windows NFS 管理者には、その場所に書き込みできる UID 0 のユーザーが必要です。

  （注）	Linux サーバーの場合、 root_squash はデフォルトで使用可能なので重要ではありません。ただし、厳密な環境では、 no_root_squash を追加できません。

• 構成されているディレクトリは、nfsnobody（UID 65534）で書き込み可能である必要があります。

  • nfsnobody による書き込みへのファイルの公開は安全です。nfsnobody または nfsnobody として実行されている Cisco Secure Malware Analytics アプライアンスでの唯一のプロセスは、データの暗号化に関するプロセスです。プレーンテキストデータは、最小権限の原則に基づいて、さまざまなサブツリーの個別のユーザーアカウントで公開されます。アプライアンス上の PostgreSQL サービスは、Elasticsearch データやフリーザにアクセスできません。Elasticsearch サービスは、PostgreSQL やフリーザデータにアクセスできません。

  • nfsnobody アカウントを使用すると、設定が簡素化され、カスタマーサイトごとに idmap.conf を構築する必要がなくなり、ローカルとリモートのアカウント名が一緒にマッピングされます。

• NFSv4 サーバーは、10 GB 管理インターフェイス経由でアクセス可能である必要があります。

• 十分なストレージが使用可能である必要があります（「バックアップストレージの要件」を参照）。

• システムは次のパラメータを使用します。rw、 sync、 nfsvers=4、 nofail

  （注）	競合するパラメータを入力しないでください。これらと競合するパラメータを手動で入力することがサポートされないのは明白で、未定義の動作が発生する可能性があります。

• 無効な NFS 設定（または誤って設定された NFS サーバーへのサービスをポイントした設定）の結果として、多くの場合、設定を適用するプロセスに失敗します。Admin UI でのこの設定を修正して再適用すると成功します。

バックアップ ストレージ要件

バックアップストアに合計で 5.6 TB を超えるストレージは必要ありません。バックアップ ストアは、次のコンポーネントで構成されています。

• オブジェクトストア：通常、使用されるストレージの大部分を占めています。バックアップストアの一括コンポーネントでのデータ保持は、使用中の Cisco Secure Malware Analytics アプライアンスリリース向けに文書化されたものと同じポリシーと制限に従っており、このコンポーネントの最大ストレージ使用量は 4.1 TB です。「Cisco Secure Malware Analytics アプライアンスデータの保持に関する注意事項」を参照してください。

• PostgreSQL データベースストア：PostgreSQL ストアの 2 つの完全バックアップと、保持されている完全バックアップのうち一番古いものから再生するのに十分な一連の WAL ログが含まれます。合計 500 GB 未満にする必要があります。

• Elasticsearch スナップショットストア：合計 1 TB 未満にする必要があります。

バックアップで予想される成果

次のバックアップで予想される成果を考慮する必要があります。

• バックアップに含まれる：Cisco Secure Malware Analytics アプライアンスのバックアップ プロセスの最初のリリースには、次の顧客独自の一括データが含まれます。

  • Samples

  • 分析結果、アーティファクト、フラグ付き

  • アプリケーション層の（Admin UI ではない）組織およびユーザー アカウントのデータ。

  • データベース（ユーザーおよび組織を含む）

  • Cisco Secure Malware Analytics ポータル UI 内で設定を行います。

• バックアップに含まれない - 次のものは、Secure Malware Analytics アプライアンス バックアップ プロセスに含まれていません。

  • [System logs]

  • 以前にダウンロードおよびインストールした更新

  • SSL キーと CA 証明書を含む、アプライアンス OpAdmin インターフェイスでの構成

• その他の期待：バックアッププロセスに関するその他の考慮事項は次のとおりです。

  • PostgreSQL ベースバックアップは 24 時間サイクルで実行されます。データベースのバックアップの復元はできません。少なくとも 1 回正常に完了するまで警告が表示されます。

  • Elasticsearch バックアップは 5 分ごとに段階的に行われます。

  • Freezer バックアップは、進行中のバックアップから失われたオブジェクトを処理するために、24 時間ごとに後続のジョブを使用して継続的に実行されます。

  • 新しいキーを生成すると、新しい独立したバックアップストアが作成されます。オリジナルのように、この新しいストアは、24 時間サイクルのベース バックアップが行われるまで有効になりません。

バックアップ データの保持

バックアップの際、次のようにデータが保持されます。

• PostgreSQL：最後の 2 つの正常なバックアップと、それらのバックアップ以降のすべての WAL セグメントが保持されます。

• Elasticsearch：最新の 5 分ごとのスナップショット 2 回分が保持されます。

• 一括ストレージ - 単一の Secure Malware Analytics アプライアンス向けに使用され文書化されるものと同じ保持ポリシーが、共有ストアに対して使用されます。

長期間にわたって履歴データを保持する場合は、ファイルシステムレイヤまたはブロックレイヤのスナップショットをサポートする NFS サーバーを使用することを強くお勧めします。

データベースのベースバックアップは、新しいベースバックアップが正常に作成されるまで保持されます。

（注）

バルクストレージでの障害発生後のリセット時に使用するため、仮想マシンイメージのバックアップコピーが RAID-1 ストレージアレイ上に作成されます。初期の Cisco Secure Malware Analytics アプライアンスモデル（UCS C220-M3 プラットフォームをベースとする）は、後のモデルよりもストレージが小さく、Secure Malware Analytics アプライアンス v2.9 のインストール後に、他のユニットが使用できる空き容量が、RAID-1 ファイルシステムのディスク容量の 25 % 未満になる可能性が高くなります。その場合、サービス通知がトリガーされます。 後のモデルのハードウェアで、v2.9 リリースのインストール後に、RAID-1 アレイの空きストレージが 25 % 未満になる場合、これは正常な状態ではないため、カスタマーサポートに問い合わせる必要があります。

保持期限の厳密な適用

TGSH（v2.6 以降）の strict_retention オプションを使用すると、分析済みのアーティファクトを 15 日間を超えて保存しないことにより、保持期間の制限を厳密に適用することができます。このオプションを有効にすると、最初の夜間プルーニングの際に、15 日間を超えて保存されているファイルが削除されます。

（注）	15 日の期間を設定または変更することはできません。

アーティファクトとは、サンプル自体と、サンプルから生成されたその他のものを意味します。アーティファクトには分析レポートの HTML が含まれていません。分析レポートの HTML は、別途記載されているとおり、最初から制限の対象となります。アーティファクトには、データベースエントリや検索インデックスも含まれません。

strict_retention オプションは、デフォルトでは無効（false）になっています。15 日後のアーティファクトのハードプルーニングを有効にするには、TGSH でこのオプションを true に設定します。

configure set strict_retention true

バックアップ頻度

データのバックアップ頻度は次のとおりです。

• サンプル、アーティファクト、レポートのバルクストレージの場合、コンテンツは継続的にバックアップされます。さらに、パスが実行されると、24 時間サイクルで不足しているコンテンツが検索されて転送されます。

• PostgreSQL データベースの場合、ベースバックアップが 24 時間サイクルで作成され、その後は、新たに書き込まれたデータベースコンテンツが 16 MB のしきい値に達するごとに、または 5 分ごとに、増分コンテンツが継続的に追加されます。

• Elasticsearch データベースの場合、コンテンツはバックアップ ストアに 5 分間サイクルで段階的に追加されます。

バックアップの頻度を制御または調整することはできません。頻度を変更すると、ストレージ使用率、復元の処理時間、パフォーマンスのオーバーヘッドに関する想定が無効になるためです。

バックアップ関連のサービス通知

バックアッププロセス中に、次のサービス通知が表示される場合があります。

• 「ネットワークストレージがマウントされていません（Network storage not mounted）」：バックエンドとして使用されているネットワーク ファイル システムが完全に動作していることを確認して、Admin UIOpAdmin で設定を再適用するか、アプライアンスを再起動します。

• 「Network storage not working（ネットワークストレージが動作していません）」：バックエンドとして使用されているネットワーク ファイル システムが完全に動作していることを確認します。システムが NFS サーバーの問題の修正から 15 分以内に回復しない場合は、アプライアンスを再起動してください。

• 「Backup file system access failure（バックアップ ファイル システムのアクセスに失敗しました）」：カスタマーサポートまでお問い合わせください。

• PostgreSQL のバックアップが見つかりません：これは、バックアップ ストアが設定された時間内のポイントと（自動的に 24 時間サイクルで実行される）最初のベース バックアップが行われる時間内のポイント間で正常な状態です。これが完了するまで、バックアップ完了とは見なされず、復元することはできません。このメッセージが 48 時間を超えて続く場合または続く場合に限り、カスタマー サポートに連絡してください。

• 「Newest PostgreSQL base backup more than two days old（最新の PostgreSQL ベース バックアップは 3 日以上前です）」：システムが PostgreSQL の新しいベースバックアップの生成に成功していないことを示します。修正されない場合、（古くなりつつあるバックアップ ポイントから復元するために必要な書き込みの完全なチェーンを保持するための）バックアップ ストアでの使用が制限されなくなり、行われる復元に必要な処理時間が許容できる長さを超えます。サポートにお問い合わせください。

• 「Backup Creation Messages（バックアップ作成メッセージ）」：バックアップの開始またはトリガーの際に検出されたエラーを反映しています。

• 非アクティブの ES バックアップ（作成）：Elasticsearch が開始して、バックアップ ストアが使用不可能であることを示します。この状態は、アプライアンスを再起動するか、（NFS と暗号化サービスが機能している場合）TGSH にログインして restart elasticsearch.service コマンドを実行することで改善できます。

• バックアップのメンテナンス メッセージ：以前に作成されたバックアップのステータスを確認するときにこれらのリフレクト エラーが検出されました。

• 「ES Backup (Maintenance) snapshot (...) status FAILED（ES バックアップ（メンテナンス）スナップショット（...）のステータスが [FAILED] になっています）」：Elasticsearch データベースのバックアップの最近の更新で、インデックスが正常に書き込まれなかったことを示します。NFS サーバーが機能していて空き領域があることを確認します。問題を特定できず、解決しない場合は、カスタマー サポートにお問い合わせください。

• 「ES Backup (Maintenance) snapshot (...) status INCOMPATIBLE（ES バックアップ（メンテナンス）スナップショット（...）のステータスが [INCOMPATIBLE] になっています）」：アプライアンスのアップグレードで新しいバージョンの Elasticsearch がインストールされた直後にのみ発生します。バックアップストアがアップグレードされて、新しいリリースとの互換性を持つようになるまで表示されます。この状態の間に障害が発生した場合、互換性のないバックアップからの復元には、カスタマーサービスの支援が必要になることがあります。

• 「ES Backup (Maintenance) snapshot (...) status PARTIAL（ES バックアップ（メンテナンス）スナップショット（...）のステータスが [PARTIAL] になっています）」：本文に次の 2 つのメッセージのうちのいずれかが含まれています。「No prior successful backups seen, so retaining（以前に成功したバックアップが見つからないため、そのまま保持します）」（バックアップは存在するものの部分的でしかない場合）。または「Prior successful backups exist, so removing（以前に成功したバックアップが存在するため、削除します）」（後で再試行するために部分的なバックアップを破棄しようとしている場合）。

• 「ES Backup (Maintenance) - Backup required (...) ms（ES バックアップ（メンテナンス）：バックアップに（...）分間かかります）」：バックアップに 60 秒を超える時間が必要な場合に発生します。これは必ずしもエラーとは限りません。Elasticsearch では定期的なメンテナンスを実行し、これがアイドル状態のシステムにも重要な書き込み負荷を発生させることがあります。ただし、これが負荷が少ない期間で一貫して発生する場合は、ストレージ パフォーマンスを調査するか、サポートが必要な場合はカスタマー サービスに連絡してください。

• 「ES Backup (Maintenance) - Unable to query Elasticsearch snapshot status（ES バックアップ（メンテナンス）：Elasticsearch スナップショット ステータスのクエリを実行できませんでした）」：Elasticsearch に接続できませんでした。この障害は、バックアップの作成が正常に開始された後に発生します。一般に、他のアプライアンスの障害と同時に発生するため、それらの問題の修復に重点を置く必要があります。アプライアンスが他の点では完全に機能しているときにこのエラーが発生し、自分では解決できない場合は、カスタマー サポートに問い合わせてください。

機能

Cisco Secure Malware Analytics アプライアンスのクラスタリングは、次の機能を提供します。

• 共有データ：クラスタ内のすべての Cisco Secure Malware Analytics アプライアンスは、スタンドアロンであるかのように使用できます。それぞれが同じデータにアクセスして表示することができます。

• サンプル送信処理：送信されたサンプルは、いずれかのクラスタメンバーで処理され、他のメンバーは分析結果を確認できます。

• レート制限：各メンバーの送信レート制限を積算した値がクラスタの制限になります。

• クラスタサイズ：推奨されるクラスタのサイズは、3、5、または7 メンバーです。4 および 6 ノードのクラスタはサポートされますが、ノードが 1 つ多いものの機能が低下したクラスタ（1 つ以上のノードが動作していないクラスタ）と同様の可用性になります。

• タイブレーカー：クラスタに偶数のノードを含めるように設定すると、タイブレーカーとして指定されたノードは、どのノードがプライマリデータベースを持つかを決定するイベントで二番手に位置付けられます。

  クラスタ内の各ノードにはデータベースが含まれていますが、プライマリノードのデータベースのみが実際に使用されます。プライマリノードがダウンした場合、他のノードがその役割を引き継ぐ必要があります。条件を設定していると、ノードがちょうど半分失敗したとき、ただし、条件が失敗したノード上ではない場合のみ、クラスタがダウンするのを防止できます。

  奇数クラスタには、関連付けられた投票はありません。奇数クラスタでは、（タイブレーカーではない）ノードがクラスタからドロップされた場合にのみ、タイブレーカーロールが関係することになります。その場合、クラスタは偶数クラスタになります。

制限事項

Cisco Secure Malware Analytics アプライアンスのクラスタリングには、次の制限があります。

• 既存のスタンドアロンの Cisco Secure Malware Analytics アプライアンスのクラスタを作成するとき、第 1 ノード（最初のノード）のみがそのデータを保持できます。クラスタに既存のデータをマージすることは許可されないため、他のノードは手動でリセットする必要があります。

  「バックアップ復元ターゲットとしてのアプライアンスのリセット」に記載されているとおり、destroy-data コマンドを使用して既存のデータを削除します。

  重要	シスコに返却してイメージを再作成しない限りアプライアンスが稼働しなくなるため、ワイプアプライアンス機能は使用しないでください。

• ノードを追加または削除すると、クラスタのサイズとメンバー ノードのロールによって、短時間停止することがあります。

• M3 サーバーのクラスタリングはサポートされていません。ご不明な点がありましたら、Threat Grid サポートまでお問い合わせください。

• 2.20 SMA アプライアンス リリース以降、2 ノード クラスタはサポートされていません。ノードが予期せずダウンした場合、2 つのノードではクォーラムを十分に維持できず、タイブレーカー ノードの以前のサポートがあっても、可用性の保証はありません。

要　件

重要	エアギャップ展開でのクラスタリングは強く非推奨：デバッグの複雑さが増大するため、エアギャップ展開や、顧客がデバッグへの L3 サポートアクセスを提供できない、または提供を望まないシナリオでは、アプライアンスのクラスタリングは推奨されません。

Cisco Secure Malware Analytics アプライアンスをクラスタリングする場合は、次の要件を満たす必要があります。

• バージョン：サポートされている設定でクラスタをセットアップするには、すべての Cisco Secure Malware Analytics アプライアンスが同じバージョンを実行している必要があります。常に使用可能な最新のバージョンにしておきます。

• Clust インターフェイス：各 Cisco Secure Malware Analytics アプライアンスには、クラスタ内の他の Cisco Secure Malware Analytics アプライアンスへのダイレクトインターコネクトが必要です。クラスタ内の各 Cisco Secure Malware Analytics アプライアンスの Clust インターフェイススロットに SFP+ を設置する必要があります（スタンドアロン構成の場合には該当しません）。

  ダイレクトインターコネクトとは、すべての Cisco Secure Malware Analytics アプライアンスが同じレイヤ 2 ネットワークセグメント上にあり、他のノードに到達するためのルーティングが不要で、大幅な遅延やジッターがないことを意味します。ノードが単一の物理ネットワーク セグメント上にないネットワーク トポロジはサポートされていません。

• データ： Cisco Secure Malware Analytics アプライアンスは、データが含まれていない場合にのみクラスタに結合できます（初期ノードのみがデータを保持できます）。既存の Cisco Secure Malware Analytics アプライアンスをデータのない状態に移行するには、データベース リセット プロセスを使用する必要があります（v2.2.4 以降で使用可能）。

  重要	破壊的なワイプアプライアンスプロセスを使用しないでください。このプロセスにより、すべてのデータが削除され、シスコに返却してイメージを再作成しない限りアプライアンスが稼働しなくなります。

• SSL 証明書：1 つのクラスタノードにカスタム CA によって署名された SSL 証明書をインストールする場合、他のノードすべての証明書も同じ CA によって署名されている必要があります。

ネットワーキングと NFS ストレージ

Cisco Secure Malware Analytics アプライアンスをクラスタリングするには、ネットワーキングおよび NFS ストレージに関して次の点を考慮する必要があります。

• Cisco Secure Malware Analytics アプライアンスクラスタでは、NFS ストアを有効にして設定する必要があります。NFS ストアが管理インターフェイス経由で使用可能で、すべてのクラスタノードからアクセス可能になっている必要があります。

• 各クラスタは、キーが 1 つある 1 つの NFS ストアによってバックアップする必要があります。既存の Cisco Secure Malware Analytics アプライアンスのデータを使用して NFS ストアを初期化することはできますが、クラスタの動作中は、クラスタのメンバーではないシステムからアクセスすることはできません。

• NFS ストアはシングルポイント障害であり、そのロールに見合った、冗長性があり信頼性の高い機器を使用することが不可欠です。

• クラスタリングに使用される NFS ストアは、遅延を常に低い状態に保つ必要があります。