デフォルトのセキュリティ・コンソール設定は広範なネットワーク環境に対応していますが、特定のスキャン要件を満たすため設定を変更可能です。
ヒント: 管理 ページの コンソール の横にある 管理 をクリックすると、セキュリティ・コンソール設定パネルが起動されます。
一般ページで、使用中のセキュリティ・コンソールのインスタンスのバージョンおよびシリアル番号を表示できます。
セキュリティ・コンソールは独自のウェブサーバーを実行し、ユーザーインターフェースが提供されます。
セキュリティ・コンソール・ウェブサーバーのデフォルト設定を変更するには：
まず技術サポートに問い合わせることをお薦めします。この文脈においてスレッドとは、セキュリティ・コンソールが許可する同時接続の数を指します。通常、単一ブラウザセッションが1つのスレッドを構成します。同時ユーザー需要が高い場合、スレッドカウントを上げてパフォーマンスを改善することが可能です。セキュリティ・コンソールは必要に応じてスレッドカウントを動的に増加しますので、手動で増加させる必要はないかもしれません。
本アプリケーションにより、自己署名されたX.509認証が提供されます。これはインストール中に作成されます。信頼できる認証局（CA）により署名された認証に置き換えることを推奨します。
注意: 署名された認証は、アプリケーションで生成されたCSRに基づいていることが必須です。本アプリケーションでは、任意キーペアまたはユーザーが生成した認証のインポートは、許可されていません。
認証を管理し新規認証署名リクエスト（CSR）を生成するには：
セキュリティ・コンソールに認証を管理とタイトルが付けられたボックスが表示されます。
認証を管理
セキュリティ・コンソールに、新規認証資格情報（credentials）のボックスが表示されます。
認証を管理–新規認証を作成
新規自己署名認証が作成されたことを示す、ダイアログボックスが現れます。
後でをクリックして、別の機会にこのステップに戻りプロセスを続行することが可能です。
認証を管理–認証署名リクエストをインポート
新しい認証の名前がウェブサーバーページに現れます。
セキュリティ・コンソールはネットワークを通じて分散型スキャン・エンジンと交信して、スキャンを開始しスキャン結果を検索します。スキャンステータス情報をより迅速に入手したい場合、あるいはセキュリティ・コンソールとスキャン・エンジンとの交信に必要な帯域幅やリソース消費を削減したい場合は、セキュリティ・コンソール設定パネルのスキャン・エンジン・ページでさまざまな設定を調整できます。以下のセクションをご参照ください：
セキュリティ・コンソールは分散型スキャン・エンジンとの接続を確立して、スキャンを起動しスキャン結果を検索します。この交信は、低いネットワーク帯域幅、高レイテンシー、スキャン・エンジンが何度も同時スキャンを実行する状況などにより、寸断される可能性があります。環境内にこれらの条件が存在する場合、スキャン・エンジン設定ページで接続設定を増加させることを検討してみるのも良いでしょう：
注意: これらの設定を調整する前に、技術サポートに問い合わせることをお薦めします。
これらの設定を設定するには、以下のステップを行います。
ヒント: ミリ秒の値は読み取りにくいため、各フィールドの右側に読みやすくした時間値が現れます。いずれかのタイムアウト値を変更するときは、同等値がどのように変更されるかに注意してください。
スキャン・エンジンとセキュリティ・コンソールとの間に信頼済み接続を作成して、ペアリングを作成を作成可能です。共有シークレットとは、エンジンからのインバウンド交信をコンソールが認識し信頼できるよう用いられるデータです。
注意: 生成された各共有シークレットは、複数のエンジンにより使用される場合があります。共有シークレットは、生成されてから 60 分間有効です。60 分経過後に、追加の信頼済みペアリングを作成する場合は、新しい共有シークレットを生成する必要があります。
信頼済みペアリングを作成するには：
ネットワークベースまたはホストベースのファイアウォールが、Nexposeセキュリティ・コンソール上でポート40815へのアクセスをブロックしていないことを確認します。40815 以外のポートを使用する場合、コンソール内のラインnsc.xml file (\[installation directory]\nsc\conf\nsc.xml) を使用するポートへと変更します：
<EngineListener port="40815"/>
セキュリティ・コンソールを再起動します。
screen -r
add console 10.1.1.4
show consoles
connect to console 2
show consoles
今接続したコンソール ID の、connectTo の値は 1 であるはずです。
add shared secret 2
プロンプトに、セキュリティ・コンソールからコピーした共有シークレットをペーストします。
共有シークレットの適用成功を確認するメッセージが表示されます。
enable console 2
ペアリング発生としてログされたラインが多数見られます。
デフォルトでは、この方法で信頼済みペアリングを作成すると、交信方向はエンジンからコンソールになります。上記を変更するには、コンソールでスキャン・エンジン交信方向を変更する
コンソールで、セキュリティ・コンソールと各遠隔スキャン・エンジンとの間の交信開始方向を変更することができます。どのオプションが好ましいかは、ネットワーク設定により異なります。交信方向がコンソールからエンジン（デフォルト設定）である場合、セキュリティ・コンソールがスキャン・エンジンとの交信を開始します。交信方向がエンジンからコンソールである場合、スキャン・エンジンが利用可能であることを、コンソールへとアクティブに通知します。本オプションにより、ファイアウォールの裏にありインバウンド接続可能に設定されているコンソールは、スキャン・エンジンとの交信チャネルを有することができます。
注意: エンジンからコンソールへのオプションは、ローカル・スキャン・エンジンまたはホスト型エンジンの場合には利用できません。
スキャン・エンジン交信の方向を変更するには：
また、矢印の上にカーソルをホバリングさせると、交信の現在のステータスを表示できます。
可能なオプションは以下の通りです：
コンソールとエンジンは交信できませんでしたが、エラーはありませんでした。
注意: このステータスは、最後の交信から長時間経過している場合に表示されることがあります。この場合、矢印上をホバリングするとpingが生じ、その交信が成功するとステータスはアクティブになります。
スキャン・エンジンからの交信を認証します。ユーザーガイドまたはヘルプの 分散型スキャン・エンジンを設定するをご覧ください。
コンソールとエンジンのバージョンが異なります。同じバージョンにアップデートするか、異なるエンジンを選択してペアリングしてください。
スキャン・エンジンがオンラインではありません。トラブルシューティングステップを行って、再度アクティブにしてください。
セキュリティ・コンソールは、スキャンステータス情報を検索するためのスレッド・プールを割り当てます。スレッドの数を調整可能です。これは、セキュリティ・コンソールが同時に検索可能なスキャンステータス・メッセージの数に対応しています。例えば、分散型スキャン・エンジンの数と同時に実行するスキャンの数を増やす場合、プール内のスレッドの数を増やすことが可能です。この結果、セキュリティ・コンソールはより多くのステータスメッセージを同時に検索できるようになります。
注意: これらの設定を調整する前に、技術サポートに問い合わせることをお薦めします。
検索時間は、帯域幅やレイテンシーといったネットワーク条件により変動するということに、留意してください。使用中のアクティブなスレッドの数がプール内のスレッドの総数を超えると、セキュリティ・コンソールは特定の時間が経過した後に未使用スキャン ステータスのスレッドを削除します。スキャン ステータス・メッセージの頻度が全体的に減っていると気付いたら、タイムアウト値を上げることを検討してみてください。
スキャンステータス・スレッドのプール設定を調整するには、以下のステップを行います：
ヒント: ミリ秒の値は読み取りにくいため、各フィールドの右側に読みやすくした時間値が現れます。いずれかのタイムアウト値を変更するときは、同等値がどのように変更されるかに注意してください。
セキュリティ・コンソールはネットワークを通じてスキャン・エンジンと交信し、スキャン結果を検索します。デフォルトでは、セキュリティ・コンソールは各スキャンの完了後にフルセットの結果を検索するのではなく、分散型スキャン・エンジンからスキャン結果を徐々に検索し、データを統合してウェブ・インターフェースに結果を表示します。これにより、スキャン進行中に利用可能となったスキャン結果を表示できます。
漸増検索は、スキャン中の帯域幅利用を調節します。また、特にデータセットが膨大である場合に一時的な帯域幅使用量の大幅増加を引き起こす、セキュリティ・コンソールによるスキャン終了時のすべてのデータ検索が不要となります。
セキュリティ・コンソール設定パネルのスキャン・エンジンページにスキャン結果の漸増検索のためのチェックボックスが表示されます。これはデフォルトで選択されています。技術サポートからの指示がない限り、このオプションを無効にしないでください。
セキュリティ・コンソール設定パネルのデータベースページで、セキュリティ・コンソール・データベースの名前およびタイプを表示可能です。また、表示されるデータベース設定を変更可能です。
変更を保存するには、保存をクリックします。
本アプリケーションのデータベースは、スキャン、レポート、アセット/脆弱性管理、およびユーザー管理といった、すべての主要オペレーションのコア・コンポーネントです。これらのタスク実行の効率は、データベースのパフォーマンスに大いに左右されます。PostgreSQLデータベースの現バージョン、9.4.1は、パフォーマンスおよび安定性に関して多くの点が改善されています。本アプリケーションはこれらの改善点を最大限に活用して、お客様の環境のニーズに柔軟に対応します。将来のリリースでは、最新のPostgreSQLバージョンを必要とするパワフルな機能を搭載する予定です。
注意: データベースを移行できるのは管理者のみです。
インストールが以前のバージョンのPostgreSQLを実行している場合、セキュリティ・コンソール・ウェブ・インターフェース内のツールを利用して、最新のバージョンへと容易に移行できます。
移行では5つのタスクを行います：
古いプラットフォーム依存型PostgreSQLデータベースのバックアップを新しいバージョンに移行した後に復元することは、サポートされていません。最新バージョンへの移行を実行・検証しデータベースの一貫性を確認したら、データベースを即座にバックアップして、以前のバージョンのデータベースを復元しなくてはならない事態を避けることが非常に重要です。
本書では、移行後のタスク（任意）に関する指示もご覧いただけます：
ある程度準備を行っておくことにより、移行にかかる時間が最低限となり、また成功に繋がります：
再起動コマンドを使用して行うことができます。移行を実行するためのディスク空き容量が十分でない場合、移行を開始ボタンが無効化されるケースがほとんどです。しかし一部の環境では移行を開始ボタンが有効となっていても、ディスク空き容量が原因で移行中に問題が起こる場合があります。事例については、Linuxファイルシステムについてのセクションをご参照ください。ディスク容量を空けるには、以下の列にリストされているソリューションをお試ください。各ステップ後に、移行を開始ボタンが有効化されているかを確認してください。
注意: 1.6 GB +（1.3 x database_size）以上のディスク空き容量が推奨されます。
以下のデータベース・メンテナンス・タスクを実行して、不必要なデータを削除し使われていないテーブルスペースを空けます：
これらのタスクを最近実行していない場合、上記を行うことでかなりの容量が空く可能性があります。各タスクを以下の順で、個別に実行することを推奨します。各タスクが完了したら、移行を再度実行してみます。再インデックスにより必要な容量が得られ、データベースのクリーンアップやテーブルの圧縮を行う必要がなくなるかもしれません（データベースのサイズによりますが、これらは非常に時間がかかる場合があります）。データベース・メンテナンスを実行するをご参照ください。
以下のディレクトリをホストシステムから移動して、移行が完了したら復元します：
注意: これらのディレクトリおよびファイルは、本アプリケーションがデータを蓄積するに従い、時間とともにディスク容量を大量に占めるようになります。
移行のために空き容量を作るには：
注意: 以前試行した移行が失敗した後にディスク空き容量の問題が起こった場合は、
前述のステップを行ったら、移行を再度開始してみます。それでもディスク空き容量が十分でない場合は、技術サポートまでお問い合わせください。
デフォルトでは、Linuxデフォルトシステムはディスク容量の5パーセントを権限、またはルート、プロセス用にリザーブしています。このリザーブされた容量はデータベース移行に利用可能ではありませんが、本アプリケーションでは、移行前計算の利用可能な総容量に含められています。その結果、移行を開始できてもその後失敗するということが起こり得ます。なぜなら実際のディスク空き容量は、当該計算で検出された値より低いからです。リザーブされたディスク容量を減らして、実際の空き容量を移行前計算の結果により近づけることが可能です。上記を行うには、tune2fsユーティリティを利用します。このコマンドには、リザーブされたディスク容量の割合および本アプリケーションがインストールされているパーティションについてのパラメータが含まれています。
例：tune2fs -m 1 /dev/sdf1
移行をモニタリングするには：
移行を開始をクリックすると、本アプリケーションはメンテナンス・モードとなります。スキャンまたはレポートの実行といった、通常の操作は利用できなくなります。メンテナンス・モードで実行するをご参照ください。管理者である場合、ログオンして移行ステータスメッセージをモニタリング可能です。
移行中、本アプリケーションは古いPostgreSQLデータベースからのデータを新しいPostgreSQLデータベースへとコピーします。移行には、これらのデータベース両方のための十分なディスク空き容量が必用です。
また古いPostgreSQLデータベースがバックアップされ、移行完了後にディレクトリ [installation_directory]/nsc/nxpgsql-backup-[timestamp] に保存されます。
予測移行時間はデータベースのサイズに基づいています。
すべての移行プロセスが終了したら、本アプリケーションが再起動され、通常の操作を再開可能となります。
移行完了前にキャンセルボタンをクリックして停止した場合、本アプリケーションは移行プロセスを中断します。その後、通常の操作モードで本アプリケーションを再起動可能です。
移行が失敗すると、現バージョンのPostgreSQLデータベースは完全なままですので、障害なく本アプリケーションを利用し続けることができます。
非常に稀なインスタンスにおいて、本アプリケーションがメンテナンスモードであっても、移行プロセスが実行された後、移行の結果詳細を伝えるステータスメッセージではなく、移行FAQが表示される場合があります。これが起こった場合、サーバーを再起動する前に技術サポートまでお問い合わせください。また、この状況が起こりサーバーをうっかり再起動してしまった場合、または移行後にデータベース移行ページで環境内で実行中のPostgreSQLのバージョンが9.4より前のものであると気づいたら、随時技術サポートまでお問い合わせください。
データ量によって、移行には 30 分から1 時間以上かかる場合があります。したがって、移行に長時間かかることは珍しいことではなく、かなりの期間新しいステータスメッセージが出ていないとしても、必ずしも移行が「停滞している」ということを示すものではありません。
2～3の簡易チェックを行って、ステータスメッセージが出ていない場合に移行がいまだ進行中であることを確認可能です：
プロセスが完了したら、セキュリティ・コンソールに通知が表示されます。
移行の成功を確認するには、以下のステップを行います：
移行が成功した場合、インストール済みバージョンは 9.4.1 となります。
または
以下の例に見られるように、ライン上に表示されます：
NSC 2015-06-11T18：45：01 PostgreSQL 9.4.1, compiled by Visual C++ build 1500, 64-bit
移行が成功したと確認できたら、以下のステップを行います：
これには、postgresql.confファイルを含む移行前データベースが含まれています。
注： 通常の操作を再開する前に、以下のセクションで説明されている通りに、データベースの一貫性を確認してください。
移行の前にpostgresql.confまたはpg_hba.confを修正した場合、これらの設定ファイルにカスタム設定を再適用する必要があります。
本手順には2つのステップがあります。チェックの一貫性の確認とデータベースのクリーンアップには、時間はほとんどかかりません。
データベースの一貫性を確認し適切に対応するには：
セキュリティ・コンソールにトラブルシューティングページが表示されます。
当該ページに、すべての診断テストの結果がリストされた表が現れます。文字Xを含む赤丸は、一貫性の問題があることを示しています。
セキュリティ・コンソールに、データベース・メンテナンスページが表示されます。
注意: デフォルトではすべての診断オプションが選択されていますが、移行後のデータベースの一貫性の確認のために必要なのはデータベース診断のみです。本タスクに必要な情報だけを閲覧するため、選択されているその他のボックスをクリアしてください。
この操作を開始すると、本アプリケーションはシャットダウンされメンテナンス・モードで再起動されます。進行中のスキャンやレポートがあった場合、完了する前に停止され関連データは失われます。メンテナンス操作が完了し通常モードで再起動してから、上記のレポートまたはスキャンを再度実行する必要があります。詳細については、メンテナンス・モードで実行するをご参照ください。
移行の成功を検証しデータベースの一貫性を確認したら、データベースを即座にバックアップすることが非常に重要です。これにより、移行後データベースのベースラインインスタンスが保存され、PostgreSQL 9.0データベースを復元しなくてはならない事態を避けることができます。
本ステップは、前述ステップ完了後にのみ実行してください：
データベースのバックアップの方法説明については、データベースバックアップ/復元およびデータ保持をご参照ください。
移行後に、PostgreSQL 9.0データベースがバックアップされ、移行完了後にディレクトリ[installation_directory]/nsc/nxpgsql-backup-[timestamp]に保存されます。
この特定のデータベースを復元するには、以下のステップを行います：
当該ディレクトリは、[installation_directory]/nsc/nxpgsqlにあります。
ヒント: すべての保存された元の許可属性と共に当該バックアップ・ディレクトリを移動します。上記を行うことで、nxpgsqlをディレクトリの所有者とするというLinux上の要件を回避できます。また、Windowsがシステムにディレクトリへのユーザーアクセスを与える必要性がなくなります。
移行中にバックアップされたデータベースの復元を計画している場合、いくつかの事項に留意してください：
移行後にスキャンまたはレポートを実行しその後バックアップ・データベースを復元する場合、セキュリティ・コンソール・ウェブ・インターフェースには、移行と復元との間に行われたスキャンまたはレポート・インスタンスはリストされません。なぜなら、復元されたデータベースにこれらの記録は含まれていないからです。
復元後にスキャンまたはレポートの実行を開始すると、復元されたデータベースに投入済みの関連するスキャンまたはレポート・インスタンスが、復元前にファイルシステム内で生成されたインスタンスを上書きします。
初めはグラフィック・チャートが復元されたデータベースに同期していませんが、これは最新のサイト、スキャン、またはアセット・グループ情報が常に反映されるからです。各チャートは関連するイベント後に、リフレッシュされ復元されたデータベースと同期します。例えばスキャンを実行すると、そのサイトまたはアセット・グループに関連するチャートのリフレッシュと同期が行われます。
移行後、PostgreSQLデータベースのデフォルト設定が適用されます。以前にpostgresql.confファイルを修正してデータベース・パフォーマンスを調整した場合、またはpg_hba.confを修正してデータベースへの遠隔接続を有効化した場合、これらの修正された設定を再適用する必要があります。
移行完了後に、古いアーカイブ化されたバージョンのPostgreSQL内の設定ファイルを参照可能です。これは、ディレクトリ [instsallation_directory]/nsc/nxpgsql-backup-[timestamp] に保存されています。
주의: 古い設定を新しいデータベースロケーションへと単にコピーしないでください。これにより互換性の問題が生じて、データベースが起動しなくなる場合があります。各ファイルについて設定を1つづつ比較し、以前のPostgreSQLインストールで修正したプロパティのみを編集します。
移行が失敗すると、現バージョンのPostgreSQLデータベースは完全なまま残ります。本アプリケーションを起動して、通常操作を再開します。
移行を再度実行する前に、ディスク容量のエラーが原因で失敗が起こったのかどうかを確認してください。特定のケースでは、移行前自動チェックで十分なディスク空き容量があると判定された場合であっても、移行が終わる前に利用可能なディスク空き容量を超える場合があります。
注意: 失敗後に移行を再試行しないと決めた場合、/nxpgsql-tempディレクトリを削除してください。これを行わないと、かなりのディスク容量が消費されるからです。
移行がシステム障害または停電により失敗して移行を再度実行する場合、ディスク容量制限の問題が生じるかもしれません。これは、失敗した移行試行中に本アプリケーションがnxpgsql-tempディレクトリを作成したからです。このディレクトリを削除して、移行を再度開始してください。当該ディレクトリは、[installation_directory]/nscにあります。
注意: 本アプリケーションをメンテナンス・モードで実行できるのは、グローバル管理者のみです。
メンテナンス・モードは、本アプリケーションが一般的なメンテナンス・タスクを実行し、1つまたは複数のサブシステムの致命的故障から復旧するための、スタートアップ・モードです。メンテナンス・モード中は、スキャンまたはレポートを実行できません。利用可能な機能は、ロギング、データベース、セキュリティ・コンソール・ウェブ・インターフェースなどです。
注意: 本アプリケーションは、致命的な内部エラーが起こると、自動的にメンテナンス・モードで実行します。
本アプリケーションがメンテナンス・モードで実行中の場合、ログオン時にページ/admin/maintenance/index.htmlが現れます。このページにはすべての利用可能なメンテナンス・タスクが表示されており、実行中のタスクの現在のステータスが示されます。現在のタスクが完了するまで、新規タスクを選択することはできません。その後、タスクを切り替え可能です。または再起動をクリックして、通常の操作モードに戻ります。
メンテナンス・モードで作業する：
セキュリティ・コンソールに、メンテナンス・モードページが表示されます。