Security Cloud Control でのデバイスのオンボーディング
Secure Device Connector
サポートされるデバイス、ソフトウェア、ハードウェア
- Secure Firewall Threat Defense デバイスのサポートの詳細
FDM-Managedデバイスのオンボード

Security Cloud Control でのデバイスのオンボーディング

ライブデバイスとモデルデバイスの両方を Security Cloud Control に導入準備できます。モデルデバイスはアップロードされた構成ファイルであり、Security Cloud Control を使用して表示および編集できます。

ほとんどのライブデバイスおよびサービスでは、Secure Device Connector が Security Cloud Control をデバイスまたはサービスに接続できるように、オープンな HTTPS 接続が必要となります。

この章は、次のセクションで構成されています。

Secure Device Connector

Secure Device Connector（SDC）は、シスコデバイスが Security Cloud Control と通信できるようにするインテリジェントプロキシです。インターネット経由で直接到達できないデバイスをデバイスのログイン情報を使用して Security Cloud Control にオンボーディングする場合は、ネットワークに SDC を展開して、デバイスと Security Cloud Control の間の通信をプロキシできます。または、必要に応じて、デバイスが Security Cloud Control からの外部インターフェイスを介して直接通信を受信できるようにすることができます。

適応型セキュリティアプライアンス（ASA）、Meraki MX、Cisco Secure Firewall Management Center デバイス、汎用 SSH および IOS デバイスは、SDC を使用して Security Cloud Control に対して導入準備できます。Cloud-Delivered Firewall Management Center によって管理される Cisco Secure Firewall Threat Defense デバイスは、SDC を使用した導入準備を必要とせず、プロキシを介した導入準備をサポートしません。Cloud-Delivered Firewall Management Center に接続するための適切な DNS 設定とアウトバウンドインターネット接続が脅威防御デバイスにあることを確認します。詳細については、「Onborading Overview」を参照してください。

（注）

Secure Device Connector および Secure Event Connector を作成するには、スーパー管理者ユーザーロールが必要です。

SDC は、管理対象デバイスで実行する必要があるコマンドと、管理対象デバイスに送信する必要があるメッセージについて、Security Cloud Control を監視します。SDC は、Security Cloud Control に代わってこのコマンドを実行し、管理対象デバイスに代わって Security Cloud Control にメッセージを送信し、管理対象デバイスからの応答を Security Cloud Control に返します。

SDC は、AES-128-GCM over HTTPS（TLS 1.3）を使用して署名および暗号化された安全な通信メッセージを使用して、Security Cloud Control と通信します。導入準備されたデバイスとサービスのすべてのログイン情報は、ブラウザから SDC に直接暗号化されるだけでなく、AES-128-GCM を使用して保存時にも暗号化されます。SDC だけがデバイスのログイン情報にアクセスできます。他の Security Cloud Control サービスはログイン情報にアクセスできません。

SDC と Security Cloud Control 間の通信を許可する方法については、管理対象デバイスへの Security Cloud Control の接続を参照してください。

SDC は、任意の Ubuntu インスタンスにインストールできます。便宜上、SDC CLI がプリインストールされた、強化された Ubuntu 22 インスタンス用の OVA を提供しています。CLI を使用すると、VM を設定し、必要なすべてのシステムパッケージをインストールし、SDC を Docker コンテナとしてホストにブートストラップできます。または、独自の Ubuntu インスタンス（バージョン 20 〜 24 が現在テスト済み）をロールし、CLI を個別にダウンロードできます。

各 Security Cloud Control テナントは、無制限の数の SDC を持つことができます。これらの SDC はテナント間で共有されず、1 つのテナント専用です。1 つの SDC が管理できるデバイスの数は、それらのデバイスに導入された機能と、設定ファイルのサイズによって異なります。ただし、展開を計画するために、1 つの SDC が約 500 台のデバイスをサポートすることを想定してください。

テナントに複数の SDC を展開すると、次の利点もあります。

パフォーマンスを低下させることなく、Security Cloud Control テナントでより多くのデバイスを管理できます。
ネットワーク内の隔離されたネットワークセグメントに SDC を展開し、そのセグメント内のデバイスを同じ Security Cloud Control テナントで引き続き管理できます。複数の SDC がない場合、これらの隔離されたネットワークセグメント内のデバイスを、異なる Security Cloud Control テナントで管理する必要があります。

単一のホストで複数の SDC を実行できます。実行する各 SDC のブートストラップ手順に従ってください。テナントの最初の SDC には、テナントの名前と番号 1 が組み込まれており、Security Cloud Control の [サービス（Services）] ページの [セキュアコネクタ（Secure Connectors）] タブに表示されます。追加の各 SDC には、順番に番号が付けられます。

詳細については、Secure Device Connector および Secure Event Connector を実行するための VM の展開を参照してください。

管理対象デバイスへの Security Cloud Control の接続

Security Cloud Control は、クラウドコネクタまたは Secure Device Connector（SDC）を介して管理対象デバイスに接続します。

インターネットからデバイスに直接アクセスできる場合は、クラウドコネクタを使用してデバイスに接続する必要があります。デバイスを設定できる場合は、クラウドリージョンの Security Cloud Control IP アドレスからのポート 443 でのインバウンドアクセスを許可します。

インターネットからデバイスにアクセスできない場合は、ネットワークにオンプレミスの SDC を展開して、Security Cloud Control がデバイスと通信できるようにすることができます。

ポート 443（またはデバイス管理用に設定したポート）のデバイスサブネット/IP から完全なインバウンドアクセスを許可するようにデバイスを設定します。

FDM-managed デバイスは、インターネットから直接アクセスできるかどうかに関係なく、デバイスのログイン情報、登録キー、またはシリアル番号を使用して Security Cloud Control へのオンボーディングを実行できます。FDM-managed デバイスがインターネットに直接アクセスできないものの、インターネットに直接アクセスできるネットワーク上に存在する場合、このデバイスの一部として提供される Security Services Exchange コネクタは Security Services Exchange クラウドに到達できるため、FDM-managed デバイスのオンボーディングが可能になります。

オンボードするには、ネットワークにオンプレミスの SDC が必要です。

クラウドからアクセスできない FDM-managed デバイスで、ログイン情報のオンボード方式が使用されます。

他のすべてのデバイスとサービスには、オンプレミス SDC は必要ありません。Security Cloud Control はクラウドコネクタを使用して接続します。インバウンドアクセスの許可が必要な IP アドレスについては、次のセクションを参照してください。

Cloud Connector を介したデバイスの Security Cloud Control への接続

クラウドコネクタを介して Security Cloud Control をデバイスに直接接続する場合、EMEA、米国、または APJ 地域のさまざまな IP アドレスに、ポート 443（またはデバイス管理用に設定したポート）でのインバウンドアクセスを許可する必要があります。

アジア - 太平洋 - 日本（APJ）地域のお客様が https://security.cisco.com で Security Cloud Control に接続する場合は、次の IP アドレスからのインバウンドアクセスを許可します。

54.199.195.111
52.199.243.0

オーストラリア（AUS）地域のお客様が https://security.cisco.com で Security Cloud Control に接続する場合は、次の IP アドレスからのインバウンドアクセスを許可します。

13.55.73.159
13.238.226.118

ヨーロッパ、中東、またはアフリカ（EMEA）地域のお客様で、https://security.cisco.com で Security Cloud Control に接続している場合は、次の IP アドレスからのインバウンドアクセスを許可します。

35.157.12.126
35.157.12.15

インド（IN）地域のお客様が https://security.cisco.com で Security Cloud Control に接続する場合は、次の IP アドレスからのインバウンドアクセスを許可します。

35.154.115.175
13.201.213.99

米国（US）地域のお客様が https://security.cisco.com で Security Cloud Control に接続する場合は、次の IP アドレスからのインバウンドアクセスを許可します。

52.34.234.2
52.36.70.147

SDC への Security Cloud Control の接続

SDC を介して Security Cloud Control をデバイスに接続する場合、Security Cloud Control で管理するデバイスで、ポート 443（またはデバイス管理用に設定したポート）の SDC ホストからの完全なインバウンドアクセスを許可する必要があります。この許可は、管理アクセス制御ルールを使用して設定されます。

また、SDC が展開されている仮想マシンが、管理対象デバイスの管理インターフェイスにネットワーク接続されていることを確認する必要があります。

Secure Device Connector および Secure Event Connector を実行するための VM の展開

デバイスのログイン情報を使用して Security Cloud Control をデバイスに接続する場合、Security Cloud Control とデバイス間の通信を管理するために、ネットワークに SDC をダウンロードして展開することがベストプラクティスです。通常、これらのデバイスは、非境界ベースでパブリック IP アドレスを持たないか、外部インターフェイスに開かれたポートを持っています。

1 つの SDC が管理できるデバイスの数は、それらのデバイスに実装されている機能と、構成ファイルのサイズによって異なります。ただし、展開を計画するために、1 つの SDC で約 500 台のデバイスをサポートすることを想定しています。詳細については、「単一の Security Cloud Control テナントで複数の SDC を使用する」を参照してください。

この手順では、Security Cloud Control の VM イメージを使用してネットワークに SDC をインストールする方法について説明します。これは、SDC を作成するために推奨される、最も信頼できる方法です。

はじめる前に

Security Cloud Control は、厳密な証明書チェックを必要とし、Secure Device Connector（SDC）とインターネットの間の Web またはコンテンツプロキシ検査をサポートしていません。プロキシサーバーを使用している場合は、SDC と Security Cloud Control の間のトラフィックの検査を無効にします。
SDC には、TCP ポート 443 またはデバイス管理用に設定したポートでのインターネットへの完全なアウトバウンドアクセスが必要です。
Security Cloud Control によって管理されるデバイスは、SDC VM の IP アドレスからのインバウンドトラフィックを許可する必要があります。
適切なネットワークアクセスを確保するため、「管理対象デバイスへの Security Cloud Control の接続の Secure Device Connector への接続」を参照してください。
ネットワークでプロキシを使用している場合は、ホストセットアップコマンドを実行する前に、必要なすべての詳細情報があることを確認します。ほとんどの問題は、誤ったプロキシ設定に関連しています。重要な詳細情報は次のとおりです。
- プロキシの IP/ホスト名。
- プロキシが、トラフィックを代行受信し、独自の証明書を使用してそれを再暗号化するかどうか。この詳細情報が、SDC VM セットアップに関する複雑さのほとんどの原因です。
  - プロキシがトラフィックを代行受信する場合は、VM を設定するときにルート証明書を準備します。プロンプトが表示されたら、それを貼り付けることで、プロキシによって生成された証明書をホストと SDC が認識して信頼できるようになります。
  - プロキシがトラフィックを代行受信しない場合、ここでは他に何もする必要はありません。
- 以下の項目は、ほとんどの場合、プロキシされる HTTP および HTTPS 接続で同じです。ただし、プロトコルごとに異なるプロキシを使用する場合は、それぞれに次のすべてが必要になります。
  - プロキシの IPアドレス
  - プロキシが使用するポート
  - プロキシが、プロキシ自体への接続が HTTPS を介したものである必要があるかどうか（通常はそうではありません）。たとえば、プロキシのアドレスが https://proxy.corp.com:80 と表示された場合は、「yes」と応答します。表示されるアドレスが http://proxy.corp.com:80 の場合は、「no」と応答します。どちらの URL もポート 80 を使用しますが、プロトコルが異なることに注意してください。
  - 以下を含むプロキシの認証の詳細情報：
    - プロキシに認証が必要かどうか（ほとんどの場合、必要ありません）
    - 必要な場合は、ホストを設定するときに使用できるユーザー名とパスワードが必要です。

サポートされているインストール

Security Cloud Control は、vSphere Web クライアントまたは ESXi Web クライアントを使用した SDC VM OVF イメージのインストールをサポートしています。
Security Cloud Control は、vSphere デスクトップクライアントを使用した SDC VM OVF イメージのインストールをサポートしていません。
Security Cloud Control は、独自の Ubuntu インスタンスへの SDC のインストールをサポートしています。現在、バージョン 20LTS ～ 24LTS がサポートされています。
ESXi 5.1 ハイパーバイザ。

システム要件

1 つの SDC を持つ VM のシステム要件は、次のとおりです。
- 2 vCPU
- 2 GB のメモリ
- 64 GB のディスク容量
ホストに追加する各 SDC には、追加の 1 つの vCPU と 1 GB の RAM が必要です。
1 つの SEC（Cisco Security Analytics and Logging で使用されるコンポーネント）を持つ VM のシステム要件は、次のとおりです。
- 4 つの vCPU（最小）
- 8 GB のメモリ
ホストに追加する SEC ごとにリソースを倍にする必要があります。そのため、これらは 1 つの SDC と 1 つの SEC を持つ VMware ESXi ホストの要件です。
- 6 vCPU
- 10 GB のメモリ
- 64 GB のディスク容量

設置の準備

ホストにおいてネットワーキングを手動で設定するには、次の情報を収集します。
- VM に使用する静的 IP アドレス
- cdo ユーザー（または sudo アクセスを持つユーザー）と「sdc」ユーザー（Docker を実行するユーザー）に使用するパスワード
- 組織で使用する DNS サーバーの IP アドレス
- SDC アドレスが存在するネットワークのゲートウェイ IP アドレス
- タイム/NTP サーバーの FQDN または IP アドレス

SDC 仮想マシンは、セキュリティパッチを定期的にインストールするように設定されており、これを行うには、ポート 80 のアウトバウンドを開く必要があります。

ネットワークでアウトバウンド接続に許可/拒否リストを使用している場合は、ubuntu.com への接続を許可して、それらのセキュリティ更新を適用できるようにする必要があります。

（注）

Ubuntu はチェックサムで更新を保護し、HTTPS ではなく HTTP のみを使用します。セキュリティ更新をプルするには、ubuntu.com への HTTP 接続を許可する必要があります。

VM の展開

SDC と SEC の実行に使用される VM を展開するには、2 つのオプションがあります。

Security Cloud Control が提供する VMware イメージをダウンロードするには、次の手順を実行します。
Ubuntu 20、22、または 24 を自分で展開する場合、独自の Ubuntu インスタンスを展開するときは、次のセクションをスキップして、「VM の設定」セクションに進むことができます。

手順

Cisco Security Cloud Control ホームページから、[Products] > [Firewall] を選択します。
左側のペインで Administration > Integrations > Secure Connectors をクリックします。
[Services] ページの [Secure Connectors] タブを選択し、青いプラスボタンをクリックして、[Secure Device Connector] を選択します。
[Download the SDC VM image] をクリックします。新しいタブで表示されます。
.zip ファイルからすべてのファイルを抽出します。これらは次のようなものです。
- CDO-SDC-VM-ddd50fa.ovf
- CDO-SDC-VM-ddd50fa.mf
- CDO-SDC-VM-ddd50fa-disk1.vmdk

vSphere Web クライアントを使用して、管理者として VMware サーバーにログインします。

（注）

ESXi Web クライアントは使用しないでください。

プロンプトに従って、OVF テンプレートから Secure Device Connector 仮想マシンを展開します。

セットアップが完了したら、SDC VM の電源を入れます。
新しい SDC VM のコンソールを開きます。
CDO というユーザー名でログインします。デフォルトのパスワードは adm123 です。

VM の設定

これで、展開した VM イメージのコンソールを起動できます（また、VM を自作しており、SSH を有効にしている場合は、その VM に SSH 接続できます）。ホストで SDC または SEC Docker コンテナを実行できるようにするには、設定スクリプトを実行する必要があります。

Security Cloud Control 提供の VM をダウンロードした場合は、CLI がすでにインストールされているため、手順 2 に進むことができます。独自の VM を展開した場合は、その VM に SSH 接続し、次のコマンドを実行して CLI をインストールします。
```
curl -O https://s3.us-west-2.amazonaws.com/download.defenseorchestrator.com/sdc-cli/sdc-cli-package-latest.tgz && tar -xvf sdc-cli-package-latest.tgz && chmod +x ./install.sh && ./install.sh
```
次のコマンドを実行して、ホストの構成を開始します：
```
sudo sdc host configure
```
パスワードの入力を求められたら、Security Cloud Control 提供の VM 場合は adm123 を入力し、独自の VM の場合は、選択した管理者パスワードを入力します。
プロンプトに従って、sdc ユーザーを設定します。
ネットワークの設定を求められたら、次のいずれかを選択します。
- [このホストを静的 IP で手動設定する（Manually configure this host with a static IP）]：このホストの IP、ゲートウェイ、DNS サーバーなどを指定し、それを VM 上のシステム設定に書き込みます。
- [DHCP]：VM に静的 IP を割り当てる DHCP サーバーがある場合。
- [静的 IP が設定済みで、今すぐネットワーキングを変更したくない。（Static IP is already configured and I don't want to change my networking now.）]
プロンプトが表示されたら、プロキシ設定に関する質問に回答します。このトピックの上部にある詳細なリストで、すべての前提条件と、可能なプロキシ設定オプションを確認してください。
プロキシが設定済みである場合は、すべてのプロキシ設定を有効にするために VM を再起動することを求められます。設定していない場合は、再起動することを求められず、手順 8 に進むことができます。
カスタムインターネットアクセステスト URL を設定します。これを行う必要があるのは、デフォルトですべてのアウトバウンド接続を拒否する場合のみです。その場合は、許可リストにある https://google.com などのパブリックにアクセス可能な Web URL を指定します。
最新のセキュリティパッチをインストールします。一部のパッチには OS ツールと Docker サーバーが必要です。
プロンプトが表示されたら、スクリプトで SSH 設定を強化するかどうかを指定します。

シスコの VM を使用している場合は、続行します。独自の VM を使用しており、SSH を自分で設定している場合は、現在の設定を変更しないように、この手順をスキップすることができます。
SDC、SEC、CLI 自体の自動更新を有効にするように求められた場合は、これを実行して、バグ修正、パッチ、および新機能を最新の状態に保つことを推奨します。ポリシーによって自動更新が許可されない場合は、「Secure Device Connector の更新」を参照してください。

自身の VM 上での Secure Device Connector の展開

デバイスのログイン情報を使用して Security Cloud Control をデバイスに接続する場合、Security Cloud Control とデバイス間の通信を管理するために、ネットワークに Secure Device Connector（SDC）をダウンロードして展開することがベストプラクティスです。通常、これらのデバイスは非境界ベースであり、パブリック IP アドレスを持たないか、外部インターフェイスに開かれたポートを持っています。適応型セキュリティアプライアンス（ASA）、FDM-managedデバイス、および Firepower Management Center（FMC）デバイスはすべて、デバイスのログイン情報を使用して Security Cloud Control に対して導入準備することができます。

1 つの SDC が管理できるデバイスの数は、それらのデバイスに実装されている機能と、構成ファイルのサイズによって異なります。ただし、展開計画の目安として、1 つの SDC で約 500 台のデバイスをサポートできることを想定しています。詳細については、単一の Security Cloud Control テナントで複数の SDC を使用するを参照してください。

この手順では、独自の仮想マシンイメージを使用してネットワークに SDC をインストールする方法について説明します。

（注）

SDC をインストールするために推奨される、最も簡単で信頼できる方法は、Security Cloud Control の SDC OVA イメージをダウンロードしてインストールすることです。

始める前に

Security Cloud Control は、厳密な証明書チェックを必要とし、SDC とインターネットの間の Web/コンテンツプロキシをサポートしていません。
SDC が Security Cloud Control と通信するためには、TCP ポート 443 でのインターネットへの完全なアウトバウンドアクセスが必要です。
SDC を介して Security Cloud Control に到達するデバイスは、ポート 443 で SDC からのインバウンドアクセスを許可する必要があります。
ネットワークのガイドラインについては、「Secure Device Connector を使用した Security Cloud Control への接続」を参照してください。

vCenter Web クライアントまたはr ESXi Web クライアントを使用してインストールされた VMware ESXi ホスト。

（注）

vSphere デスクトップクライアントを使用したインストールはサポートしていません。

ESXi 5.1 ハイパーバイザ。
Ubuntu 22.04 および Ubuntu 24.04 オペレーティングシステム。
SDC のみを持つ VM のシステム要件：
- VMware ESXi ホストには 2 つの CPU が必要です。
- VMware ESXi ホストには 2 GB 以上のメモリが必要です。
- VMware ESXi では、プロビジョニングの選択に応じて、仮想マシンをサポートするために 64 GB のディスク容量が必要です。これは、必要に応じてディスク領域を拡張できるように、パーティションで論理ボリューム管理（LVM）を使用していることを想定した値です。
テナント用の SDC と単一の Secure Event Connector（SEC）を備えた VM のシステム要件。（SEC は Cisco Security Analytics and Logging で使用されるコンポーネント）：

VMware ESXi ホストに追加する各 SEC には、4 つの追加 CPU と 8 GB の追加メモリが必要です。

したがって、これらは 1 つの SDC と 1 つの SEC を持つ VMware ESXi ホストの要件です。
- VMware ESXi ホストには 6 つの vCPU が必要です。
- VMware ESXi ホストには 10 GB 以上のメモリが必要です。
- VMware ESXi では、プロビジョニングの選択に応じて、仮想マシンをサポートするために 64 GB のディスク容量が必要です。
VM の CPU とメモリを更新したら、VM の電源を入れ、[セキュアコネクタ（Secure Connectors）] ページに SDC が「アクティブ」状態であることが示されていることを確認します。
この手順を実行するユーザーは、Linux 環境の操作に親しんでおり、vi ビジュアルエディタを使用してファイルを編集している必要があります。
オンプレミスの SDC を CentOS 仮想マシンにインストールする場合は、Yum セキュリティパッチを定期的にインストールすることをお勧めします。Yum の更新を取得するための設定に応じて、ポート 443 だけでなくポート 80 でもアウトバウンドアクセスを開く必要がある場合があります。また、更新をスケジュールするために yum-cron または crontab も設定する必要があります。セキュリティ運用チームと連携して、Yum の更新を取得するためにセキュリティポリシーを変更する必要があるかどうかを判断します。

（注）

始める前に：手順内のコマンドは、コピーして端末ウィンドウに貼り付けるのではなく入力するようにしてください。一部のコマンドに含まれる「n ダッシュ」は、カットアンドペーストのプロセスで「m ダッシュ」として適用される場合があり、コマンドが失敗する原因となります。

手順

ステップ 1

SDC を作成する Security Cloud Control テナントにログオンします。

ステップ 2

Cisco Security Cloud Control ホームページから、[Products] > [Firewall] を選択します。

ステップ 3

左側のペインで Administration > Integrations > Secure Connectors をクリックします。

ステップ 4

[サービス（Services）] ページの [セキュアコネクタ（Secure Connectors）] タブで、青いプラスボタンをクリックし、[Secure Device Connector] を選択します。

ステップ 5

ウィンドウの手順 2 のブートストラップデータをメモ帳にコピーします。

ステップ 6

少なくとも次の RAM とディスク領域が SDC に割り当てられている CentOS 7 仮想マシンをインストールします。

8 GB の RAM
10 GB のディスクスペース

ステップ 7

インストールしたら、SDC の IP アドレス、サブネットマスク、ゲートウェイの指定など、ネットワークの基本設定を行います。

ステップ 8

DNS（ドメインネームサーバー）を設定します。

ステップ 9

NTP（ネットワークタイムプロトコル）サーバーを設定します。

ステップ 10

SDC の CLI と簡単にやり取りできるように、CentOS に SSH サーバーをインストールします。

ステップ 11

Yum の更新を実行し、open-vm-tools、nettools、および bind-utils パッケージをインストールします。

[root@sdc-vm ~]# yum update -y 
               [root@sdc-vm ~]# yum install -y open-vm-tools net-tools bind-utils

ステップ 12

AWS CLI パッケージをインストールします。https://docs.aws.amazon.com/cli/latest/userguide/awscli-install-linux.htmlを参照してください。

（注）

--user フラグは使用しないでください。

ステップ 13

Docker CE パッケージをインストールします。https://docs.docker.com/install/linux/docker-ce/centos/#install-docker-ceを参照してください。

（注）

「リポジトリを使用したインストール」方法を使用します。

ステップ 14

Docker サービスを開始し、起動時に開始できるようにします。


 [root@sdc-vm ~]# systemctl start docker
 [root@sdc-vm ~]# systemctl enable docker
 Created symlink from /etc/systemd/system/multiuser.target.wants/docker.service to
     /usr/lib/systemd/system/docker.service.

ステップ 15

cdo と sdc の 2 つのユーザーを作成します。cdo ユーザーを使用すれば、ルートユーザーに直接アクセスせずに管理タスクを実行できます。sdc ユーザーは、SDC docker コンテナを実行するために指定します。


  [root@sdc-vm ~]# useradd cdo
  [root@sdc-vm ~]# useradd sdc –d /usr/local/cdo

ステップ 16

sdc ユーザーのパスワードを設定します。


  [root@sdc-vm ~]# passwd cdo
  Changing password for user cdo.
  New password: <type password> 
  Retype new password: <type password> 
  passwd: all authentication tokens updated successfully.

ステップ 17

sdc ユーザーを wheel グループに追加して、管理者（sudo）権限を付与します。


   [root@sdc-vm ~]# usermod -aG wheel cdo 
   [root@sdc-vm ~]#

ステップ 18

Docker がインストールされると、ユーザーグループが作成されます。CentOS/Docker のバージョンに応じて、「docker」または「dockerroot」と呼ばれます。/etc/group ファイルでどのグループが作成されたかを確認したら、sdc ユーザーをそのグループに追加します。


  [root@sdc-vm ~]# grep docker /etc/group
   docker:x:993:
  [root@sdc-vm ~]#
  [root@sdc-vm ~]# usermod -aG docker sdc
  [root@sdc-vm ~]#

ステップ 19

/etc/docker/daemon.json ファイルが存在しない場合は作成し、以下の内容を入力します。作成したら、docker デーモンを再起動します。

（注）

「group」キーに入力したグループ名が、前の手順の /etc/group ファイルで見つけたグループと一致していることを確認してください。

[root@sdc-vm ~]# cat /etc/docker/daemon.json
         {
            "live-restore": true,
            "group": "docker"
         }
         [root@sdc-vm ~]# systemctl restart docker 
         [root@sdc-vm ~]#

ステップ 20

現在 vSphere コンソールセッションを使用している場合は、SSH に切り替えて、cdo ユーザーでログインします。ログインしたら、sdc ユーザーに切り替えます。パスワードの入力を求められたら、cdo ユーザーのパスワードを入力します。

[CDO@sdc-vm ~]$ sudo su sdc
               [sudo] password for cdo: <type password for cdo user>
               [sdc@sdc-vm ~]$

ステップ 21

ディレクトリを /usr/local/CDO に変更します。

ステップ 22

bootstrapdata という新しいファイルを作成し、[オンプレミスの Secure Device Connector の展開（Deploy an On-Premises Secure Device Connector）] ウィザードの手順2 のブートストラップデータを、このファイルに貼り付けます。[保存（Save）] をクリックしてファイルを保存します。[vi] または [nano] を使用してファイルを作成できます。

ステップ 23

ブートストラップデータは base64 でエンコードされていますので、復号して extractedbootstrapdata というファイルにエクスポートします。

[sdc@sdc-vm ~]$ base64 -d /usr/local/ CDO/bootstrapdata > /usr/local/CDO/extractedbootstrapdata
              [sdc@sdc-vm ~]$

cat コマンドを実行して復号したデータを表示します。コマンドおよび復号したデータは次のようになります。

[sdc@sdc-vm ~]$ cat /usr/local/ CDO/extractedbootstrapdata
               CDO_TOKEN="<token string>"
               CDO_DOMAIN="www.defenseorchestrator.com"
               CDO_TENANT="<tenant-name>"
               CDO_BOOTSTRAP_URL="https://www.defenseorchestrator.com/sdc/bootstrap/tenant-name/<tenant-name-SDC>"

ステップ 24

以下のコマンドを実行して、復号したブートストラップデータの一部を環境変数にエクスポートします。

[sdc@sdc-vm ~]$ sed -e 's/^/export /g' extractedbootstrapdata > sdcenv && source sdcenv
              [sdc@sdc-vm ~]$

ステップ 25

Security Cloud Control からブートストラップバンドルをダウンロードします。

[sdc@sdc-vm ~]$ curl -O -H "Authorization: Bearer $CDO_TOKEN" "$CDO_BOOTSTRAP_URL"
               100 10314 100 10314 0 0 10656 0 --:--:-- --:--:-- --:--:-- 10654
               [sdc@sdc-vm ~]$ ls -l /usr/local/ CDO/*SDC
               -rw-rw-r--. 1 sdc sdc 10314 Jul 23 13:48 /usr/local/CDO/tenant-name-SDC

ステップ 26

SDC tarball を展開し、bootstrap.sh ファイルを実行して SDC パッケージをインストールします。

[sdc@sdc-vm ~]$ tar xzvf /usr/local/CDO/tenant-name-SDC
               <snipped – extracted files>
               [sdc@sdc-vm ~]$
               [sdc@sdc-vm ~]$ /usr/local/ CDO/bootstrap/bootstrap.sh
               [2018-07-23 13:54:02] environment properly configured
               download: s3://onprem-sdc/toolkit/prod/toolkit.tar to toolkit/toolkit.tar
               toolkit.sh
               common.sh
               [2018-07-23 13:54:04] startup new container
               Unable to find image 'ciscodefenseorchestrator/sdc_prod:latest' locally
               sha256:d98f17101db10e66db5b5d6afda1c95c29ea0004d9e4315508fd30579b275458: Pulling from
               ciscodefenseorchestrator/sdc_prod
               08d48e6f1cff: Pull complete
               ebbd10b629b1: Pull complete
               d14d580ef2ed: Pull complete
               45421d451ab8: Pull complete
               <snipped – downloads>
               no crontab for sdc

すると、Security Cloud Control で SDC が「アクティブ」と表示されるはずです。

次のタスク

Secure Event Connector をインストールする場合は、SDC 仮想マシンへの Secure Event Connector のインストールに戻ります。
テナントに 2 つ以上の Secure Event Connector をインストールする場合は、「テナントに複数の SEC をインストールする」に戻ります。

展開されたホストでの Secure Device Connector のブートストラップ

手順

ステップ 1	Cisco Security Cloud Control ホームページから、[Products] > [Firewall] を選択します。
ステップ 2	左側のペインで Administration > Integrations > Secure Connectors をクリックします。
ステップ 3	[Services] ページの [Secure Connectors] タブで、[+] アイコンをクリックし、[Secure Device Connector] を選択します。
ステップ 4	ウィンドウの手順 2 のブートストラップデータをメモ帳にコピーします。
ステップ 5	管理者ユーザー（通常は `cdo`）と選択したパスワードを使用して、VM に SSH で接続します。
ステップ 6	「sudo su - sdc」コマンドを使用して `sdc` ユーザーに切り替えます。 `sudo su - sdc`
ステップ 7	次のコマンドを使用して、新しい SDC をブートストラップします。 `sdc bootstrap <paste-your-bootstrap-data-here>`
ステップ 8	使用する SDC のバージョンを選択します。 SDC バージョンには 3 つのオプションがあります。 SDC 2024：これは、ほとんどの場合に実行を希望されるバージョンです。 FIPS が有効な SDC 2024：FedRamp 準拠の条件を満たす場合は、このバージョンを選択します。 SDC レガシー：このバージョンは機能の更新を受信しなくなったため、代わりに SDC 2024 を実行することを推奨します。
ステップ 9	CLI はコンテナイメージをプルして SDC を起動します。また、以下を実行して、SDC がアクティブでユーザーインターフェイスおよびホスト上で動作していることを検証できます。 `sdc show running`

テナントの SDC が表示されます。

Terraform を使用した vSphere への Secure Device Connector の展開

始める前に

この手順では、vSphere 用 Security Cloud Control SDC Terraform モジュールを Security Cloud Control Terraform プロバイダーと組み合わせて使用して、vSphere に SDC を展開する方法について詳しく説明します。このタスク手順を実行する前に、次の前提条件を確認してください。

vSphere データセンターバージョン 7 以降が必要です
次を実行する権限を持つデータセンターの管理者アカウントが必要です。
- VM の作成
- フォルダの作成
- コンテンツライブラリの作成
- コンテンツライブラリへのファイルのアップロード
Terraform の知識

手順

ステップ 1	Security Cloud Control で API のみのユーザーを作成し、API トークンをコピーします。API のみのユーザーの作成方法については、「API のみのユーザーを作成する」を参照してください。
ステップ 2	「Security Cloud Control Terraform Provider」の手順に従って、Terraform リポジトリで Security Cloud Control Terraform プロバイダーを構成します。例: `terraform { required_providers { cdo = { source = "CiscoDevNet/cdo" version = "0.7.0" } } } provider "cdo" { base_url = “<the CDO URL you use to access CDO>” api_token = “<the API Token generated in step 1>” }`
ステップ 3	Security Cloud Control Terraform プロバイダーを使用して `cdo_sdc` リソースを作成するための Terraform コードを記述します。詳細については、Security Cloud Control-sdc リソースの Terraform レジストリを参照してください。例: `Resource “cdo_sdc” “my-sdc” { name = “my-sdc-in-vsphere” }` このリソースの `bootstrap_data` 属性には、Security Cloud Control ブートストラップデータの値が入力され、次のステップで `cdo_sdc` Terraform モジュールに提供されます。
ステップ 4	Security Cloud Control_sdc Terraform モジュールを使用して、vSphere で SDC を作成するための Terraform コードを記述します。例: data "cdo_tenant" "current" {} module "vsphere-cdo-sdc" { source = "CiscoDevNet/cdo-sdc/vsphere" version = "1.0.0" vsphere_username = "<replace-with-username-with-admin-privileges>" vsphere_password = "<super-secure-password>" vsphere_server = "<replace-with-address-of-vsphere-server>" datacenter = "<replace-with-datacenter-name>" resource_pool = "<replace-with-resource-pool-name>" cdo_tenant_name = data.cdo_tenant.current.human_readable_name datastore = "<replace-with-name-of-datastore-to-deploy-vm-in>" network = "<replace-with-name-of-network-to-deploy-vm-in>" host = "<replace-with-esxi-host-address>" allow_unverified_ssl = <boolean; set to true if your vsphere server does not have a valid SSL certificate> ip_address = "<sdc-vm-ip-address; must be in the subnet of the assigned network for the VM>" gateway = "<replace-with-network-gateway-address>" cdo_user_password = "<replace-with-password-for-cdo-user-in-sdc-vm>" root_user_password = "<replace-with-password-for-root-user-in-sdc-vm>" cdo_bootstrap_data = cdo_sdc.sdc-in-vsphere.bootstrap_data } 作成された VM には 2 人のユーザー（`root` ユーザーと `cdo` というユーザー）があり、VM の IP アドレスは静的に設定されていることに注意してください。`cdo_bootstrap_data` 属性には、`cdo_sdc` リソースの作成時に生成された `bootstrap_data` 属性の値が指定されます。
ステップ 5	通常どおり、`terraform plan` と `terraform apply` を使用して Terraform を計画および適用します。完全な例については、CiscoDevNet の「Security Cloud Control Automation Repository」[英語] を参照してください。

SDC がオンボーディング状態のままである場合は、リモートコンソールを使用して vSphere VM に接続し、CDO ユーザーとしてログインして、次のコマンドを実行します。

sdc host status

資料によっては、以下を手動で実行する必要がある場合があります。

sdc host configure

（注）

Security Cloud Control Terraform モジュールは、Apache 2.0 ライセンスの下でオープンソースソフトウェアとして公開されています。サポートが必要な場合は、GitHub で問題を報告できます。

Terraform モジュールを使用した AWS VPC 上での Secure Device Connector の展開

始める前に

AWS VPC に SDC を展開する前に、次の前提条件を確認してください。

Security Cloud Control は、厳密な証明書チェックを必要とし、SDC とインターネットの間の Web/コンテンツプロキシ検査をサポートしていません。プロキシサーバーを使用している場合は、Secure Device Connector（SDC）と Security Cloud Control の間のトラフィックの検査を無効にします。
適切なネットワークアクセスを確保するため、「Security Cloud Controlの Secure Device Connector への接続」を参照してください。
AWS アカウント、少なくとも 1 つのサブネットを持つ AWS VPC、および AWS Route53 でホストされるゾーンが必要です。
Security Cloud Control ブートストラップデータ、AWS VPC ID、およびそのサブネット ID が手元にあることを確認します。
SDC を展開するプライベートサブネットに NAT ゲートウェイが接続されていることを確認します。
ファイアウォール管理 HTTP インターフェイスが実行されているポートで、ファイアウォールから NAT ゲートウェイに接続された Elastic IP へのトラフィックを開きます。

手順

ステップ 1

Terraform ファイルに次のコード行を追加します。変数の入力は手動で入力してください。

module "example-sdc" {
  source             = "git::https://github.com/cisco-lockhart/terraform-aws-cdo-sdc.git?ref=v0.0.1"
  env                = "example-env-ci"
  instance_name      = "example-instance-name"
  instance_size      = "r5a.xlarge"
  cdo_bootstrap_data = "<replace-with-cdo-bootstrap-data>"
  vpc_id             = <replace-with-vpc-id>
  subnet_id          = <replace-with-private-subnet-id>
}

入力変数と説明のリストについては、「Secure Device Connector Terraform module」を参照してください。

ステップ 2

Terraform コードの出力として instance_id を登録します。

output "example_sdc_instance_id" {
  value = module. example-sdc.instance_id
}

instance_id を使用して SDC インスタンスに接続し、AWS Systems Manager Session Manager（SSM）を使用してトラブルシューティングを行うことができます。使用可能な出力のリストについては、「Secure Device Connector Terraform module」の「Outputs」を参照してください。

次のタスク

SDC のトラブルシューティングでは、AWS SSM を使用して SDC インスタンスに接続する必要があります。インスタンスへの接続方法の詳細については、「AWS Systems Manager Session Manager」を参照してください。SSH を使用して SDC インスタンスに接続するためのポートは、セキュリティ上の理由により公開されないことに注意してください。

（注）

オンプレミス Secure Device Connector および Secure Event Connector の CentOS 7 仮想マシンから Ubuntu 仮想マシンへの移行

Security Cloud Control のオンプレミス Secure Device Connector（SDC）は、これまで CentOS 7 仮想マシンにインストールされていました。CentOS 7 はサポートが終了し、Security Cloud Control によって廃止されたため、すべての SDC を CentOS 7 から Ubuntu 仮想マシンに移行できるように、こちらの移行プロセスを準備しました。

移行する前に

SDC には TCP ポート 443 でのインターネットへの完全なアウトバウンドアクセスが必要です。
SDC を実行している Ubuntu 仮想マシンには、ASA や Cisco IOS デバイスなど、通信するデバイスの管理インターフェイスへのネットワークアクセスが必要です。
デバイスに到達するため、元の SDC VM の IP アドレスまたは FQDN で作成されたネットワークルールを、新しい SDC VM の IP アドレスまたは FQDN を使用して作成し直す必要があります。
移行には 10 ～ 15 分かかります。移行中、デバイスは引き続きセキュリティポリシーを適用し、ネットワークトラフィックを回送しますが、SDC を介した通信はできません。

前提条件

「Secure Device Connector および Secure Event Connector を実行するための VM の展開」の手順に従って新しいホストを展開します。

ホストの設定

SDC や SEC を移行する場合は、次の手順に従います。

こちらから新しい VM イメージをダウンロードします。
CDO-SDC_VM.zip ファイルを解凍します。次のような名前の 3 つの VM ファイルが表示されます。
- CDO-SDC-VM-708cd33-2024-05-30-2031-disk1.vmdk
- CDO-SDC-VM-708cd33-2024-05-30-2031.mf
- CDO-SDC-VM-708cd33-2024-05-30-2031.ovf
ダウンロードした VM を展開します。
新しい VM に割り当てられた静的 IP アドレスまたは FQDN をメモします。
SSH を使用して、CDO ユーザーとして新しい VM にログインします。

プロンプトに次のコマンドを入力します。

sudo sdc host configure

（注）

移行スクリプトのプロンプトに厳密に従ってください。このスクリプトは適切に文書化されており、手順ごとの説明で移行プロセスをガイドします。
移行スクリプトの最後に、SDC が新しい VM に移行されたことを示すメッセージが表示されます。SDC の名前は、移行後も保持されます。

SDC の移行

手順：

SSH を使用して、CDO ユーザーとして元の（CentOS）SDC にログインします。

次のコマンドを使用して CLI をインストールします。

curl -O https://s3.us-west-2.amazonaws.com/download.defenseorchestrator.com/sdc-cli/sdc-cli-package-latest.tgz && tar -xvf sdc-cli-package-latest.tgz && chmod +x ./install.sh && ./install.sh

次のコマンドを実行し、プロンプトに従います。
```
sudo sdc migrate now
```

確認：

Security Cloud Control テナントにログインします。
移行先の SDC を選択して、[操作（Actions）] ペインで [ハートビートの要求（Request Heartbeat）] をクリックします。

（注）

SDC が [アクティブ（Active）] 状態であることを確認します。

SEC の移行

手順：

SSH を使用して、CDO ユーザーとして元の（CentOS）SDC にログインします。

次のコマンドを使用して CLI をインストールします。

curl -O https://s3.us-west-2.amazonaws.com/download.defenseorchestrator.com/sdc-cli/sdc-cli-package-latest.tgz && tar -xvf sdc-cli-package-latest.tgz && chmod +x ./install.sh && ./install.sh

次のコマンドを実行し、プロンプトに従います。
```
sudo sdc eventing migrate
```
SEC の新しい IP アドレスをポイントするようにデバイスを設定するか、元のホストをシャットダウンし、新しいホストに元のホストと同じ IP アドレスを割り当てます（この場合、デバイスの更新は不要です）。

確認：

SEC の状態に関する詳細は、「Secure Event Connector の状態を把握するためのヘルスチェックの使用」を参照してください。

追加手順

古い SDC を再起動しない

移行が完了したら、元の仮想マシンで古い SDC を再起動しないでください。

失敗した移行を元に戻す

何らかの理由で移行が失敗した場合、または期待どおりの結果でなかったため、元の SDC に戻す場合は、次の手順に従います。

新しい VM にログインし、SDC ユーザーにスイッチします。
次のコマンドを使用して、SDC が現在新しい VM で実行されていないことを確認します。
```
docker ps
```
SDC が実行されている場合は、次のコマンドを実行します。
```
sdc stop
```
再度 docker ps を実行して、SDC が実行を停止したことを確認します。
古い VM にログインし、次のコマンドを実行します。
```
sdc migrate revert
```
古い SDC がアクティブで UI に表示されたら、新しい VM に戻り、次のコマンドを実行します。
```
sdc delete <your-tenant-name-here>
```
ブラウザを完全に更新し、SDC をクリックして、古いホストの IP がサイドバーに表示されていることを確認します。

これらの手順を実行しても、新しい IP が表示される場合は、新しいヘルスチェックを要求し、ブラウザを更新して、もう一度確認してください。
SEC 移行を元に戻すには、以下のコマンドを実行します。
```
sdc eventing revert
```

Secure Device Connector の IP アドレスの変更

始める前に

このタスクを実行するには、管理者である必要があります。
SDC には、TCP ポート 443 またはデバイス管理用に設定したポートでのインターネットへの完全なアウトバウンドアクセスが必要です。

（注）

SDC の IP アドレスを変更した後、デバイスを Security Cloud Control に再度オンボーディングする必要はありません。

手順

ステップ 1

SDC への SSH 接続を作成するか、仮想マシンのコンソールを開き、CDO ユーザーとしてログインします。

ステップ 2

IP アドレスを変更する前に SDC VM のネットワークインターフェイス設定情報を表示するには、コマンドを使用します。

[cdo@localhost ~]$ ip addr

ステップ 3

インターフェイスの IP アドレスを変更するには、次のコマンドを使用してホスト設定を再度開始します。

[cdo@localhost ~]$ sdc host configure network

ステップ 4

プロンプトが表示されたら、パスワードを入力します。

ステップ 5

設定スクリプトは、ネットワーク設定について尋ね、新しい IP を使用して新しい設定ファイルを書き込み、その設定を適用します。

（注）

この時点で、SSH 接続は失われます。

ステップ 6

SDC に割り当てた新しい IP アドレスを使用して SSH 接続を作成し、ログインします。

ステップ 7

SDC は自動的に起動しますが、起動しない場合は以下のコマンドを実行します。

[cdo@localhost ~]$ sudo su - sdc

[cdo@localhost ~]$ sdc start

（注）

VM のコンソールでこの手順を実行している場合、値が正しいことを確認すると、接続ステータスのテストが自動的に実行され、ステータスが表示されます。

ステップ 8

Security Cloud Control ユーザーインターフェイスを介して SDC の接続を確認することもできます。確認するには、Security Cloud Control アプリケーションを開き、 Administration > Integrations > Secure Connectors ページに移動します。

ステップ 9

ページを一度更新し、IP アドレスを変更したセキュアコネクタを選択します。

ステップ 10

[操作（Actions）] ペインで、[ハートビートの要求（Request heartbeat）] をクリックします。「ハートビートが正常に要求された」というメッセージが表示され、[Last Heartbeat] に現在の日付と時刻が表示されるはずです。

Secure Device Connector の削除

警告	この手順により、Secure Device Connector（SDC）が削除されます。この操作は元に戻せません。この操作を行った後は、新しい SDC をインストールしてデバイスを再接続するまで、その SDC に接続されているデバイスを管理できなくなります。デバイスを再接続するには、再接続が必要なデバイスごとに管理者ログイン情報を再入力する必要がある場合があります。

テナントから SDC を削除するには、次の手順を実行します。

手順

ステップ 1

削除する SDC に接続されているデバイスをすべて削除します。

1. SDC で使用されるすべてのデバイスを特定するには、「同一 SDC を使用した Security Cloud Control に接続するすべてのデバイスを見つける」を参照してください。
2. [セキュリティデバイス（Security Devices）] ページで、識別したすべてのデバイスを選択します。
3. [デバイスアクション（Device Actions）] ウィンドウで [削除（Remove）] をクリックし、[OK] をクリックして操作を確定します。

ステップ 2

Cisco Security Cloud Control ホームページから、[Products] > [Firewall] を選択します。

ステップ 3

左側のペインで Administration > Integrations > Secure Connectors をクリックします。

ステップ 4

[サービス（Services）] ページの [セキュアコネクタ（Secure Connectors）] タブが選択された状態で、青いプラスボタンをクリックし、[Secure Device Connector] を選択します。

ステップ 5

[セキュアコネクタ（Secure Connectors）] テーブルで、削除する SDC を選択します。これで、デバイス数はゼロになっているはずです。

ステップ 6

[アクション（Actions）] ペインで、[削除（Remove）] アイコンをクリックします。次の警告が表示されます。

警告	<sdc_name> を削除しようとしています。SDC の削除は元に戻せません。SDC を削除すると、デバイスをオンボーディングまたは再オンボーディングする前に、新しい SDC を作成してオンボーディングする必要があります。

現在オンボーディング済みのデバイスがあるため、SDC を削除するには、これらのデバイスを再接続し、新しい SDC を設定した後にログイン情報を再度入力する必要があります。

ご質問や懸念事項がある場合は、[キャンセル（Cancel）] をクリックして、Security Cloud Control サポートにお問い合わせください。
続行するには、下のテキストボックスに <sdc_name> を入力して、[OK] をクリックします。

ステップ 7

続行する場合は、警告メッセージに記載されている SDC の名前を確認ダイアログボックスに入力します。

ステップ 8

[OK] をクリックして、SDC の削除を確定します。

ある SDC から別の SDC への ASA の移動

Security Cloud Control では、1 つのテナントあたり 1 つ以上の SDC の使用がサポートされます。次の手順を使用して、管理対象 ASA を、ある SDC から別の SDC に移動できます。

手順

ステップ 1

左側のペインで Security Devices をクリックします。

ステップ 2

[ASA] タブをクリックします。

ステップ 3

別の SDC に移動する 1 つ以上の ASA を選択します。

ステップ 4

[デバイスアクション（Device Actions）] ペインで、[資格情報の更新（Update Credentials）] をクリックします。

ステップ 5

[セキュアデバイスコネクタ（Secure Device Connector）] ボタンをクリックし、デバイスの移動先の SDC を選択します。

ステップ 6

Security Cloud Control がデバイスにログインするために使用する管理者のユーザー名とパスワードを入力し、[更新（Update）] をクリックします。変更されていない限り、管理者のユーザー名とパスワードは、ASA のオンボードに使用したログイン情報と同じです。これらの変更をデバイスに展開する必要はありません。

（注）

すべての ASA が同じログイン情報を使用している場合、複数の ASA を、ある SDC から別の SDC に一括で移動できます。複数の ASA のログイン情報が異なる場合、各 ASA をある SDC から別の SDC に 1つずつ移動する必要があります。

Secure Device Connector の名前変更

手順

ステップ 1	左側のペインで、Administration > Integrations > Secure Connectors を選択します。
ステップ 2	名前を変更する SDC を選択します。
ステップ 3	詳細ペインで、SDC の名前の横にある編集アイコンをクリックします。
ステップ 4	SDC の名前を変更します。

この新しい名前は、Security Cloud Control インターフェース内の SDC 名が表示される場所に、[Security Devices] ペインの Secure Device Connector フィルタを含めて表示されます。

Secure Device Connector の更新

この手順は、トラブルシューティングツールとして使用してください。通常、SDC は自動的に更新されるため、この手順を使用する必要はありません。エラーが発生した場合は、手動更新を開始する必要がある可能性があります。

手順

ステップ 1

SDC に接続します。SSH を使用して接続するか、ハイパーバイザのコンソールビューを使用できます。

ステップ 2

管理者ユーザー（通常は cdo）として SDC にログインします。

ステップ 3

SDC ユーザーに切り替えて、SDC Docker コンテナを更新します。

 [cdo@sdc-vm ~]$ sudo su sdc
                [sudo] password for cdo: <type password for cdo user>
                [sdc@sdc-vm ~]$

ステップ 4

SDC をアップグレードします。

sdc upgrade

（注）

SDC 仮想マシンで推奨される更新およびメンテナンス

必ず、組織の内部 IT セキュリティおよびパッチ管理ポリシーに従って、Ubuntu Linux で動作する SDC VM をモニターし、更新を適用してください。ネットワーク環境内で SDC VM のセキュリティ保護と最適な機能が維持されるように、関連するセキュリティパッチを定期的に確認して適用することを強くお勧めします。

単一の Security Cloud Control テナントで複数の SDC を使用する

テナントに複数の SDC を展開すると、パフォーマンスを低下させることなく、より多くのデバイスを管理できます。1 つの SDC が管理できるデバイスの数は、それらのデバイスに実装されている機能と、構成ファイルのサイズによって異なります。

テナントにインストールできる SDC の数に制限はありません。各 SDC は 1 つのネットワークセグメントを管理できます。これらの SDC は、それらのネットワークセグメント内のデバイスを同一の Security Cloud Control テナントに接続します。複数の SDC がない場合、隔離されたネットワークセグメント内のデバイスを、異なる Security Cloud Control テナントで管理する必要があります。

2 番目以降の SDC を展開する手順は、最初の SDC を展開する手順と同じです。
テナントの最初の SDC には、テナントの名前と番号 1 が組み込まれています。追加の各 SDC には、順番に番号が付けられます。

同じ SDC を使用する Security Cloud Control デバイス

次の手順に従って、同じ SDC を使用して Security Cloud Control に接続するすべてのデバイスを識別します。

手順

ステップ 1	左側のペインで Security Devices をクリックします。
ステップ 2	[デバイス（Devices）] タブをクリックしてデバイスを見つけます。
ステップ 3	適切なデバイスタイプのタブをクリックします。
ステップ 4	フィルタ基準がすでに指定されている場合は、[セキュリティデバイス（Security Devices）] ページの上部にある [クリア（Clear）] ボタンをクリックして、Security Cloud Control で管理しているすべてのデバイスとサービスを表示します。
ステップ 5	フィルタボタンをクリックして、[フィルタ（Filter）] メニューを展開します。
ステップ 6	フィルタの [Secure Device Connector] セクションで、必要な SDC の名前をクリックします。[セキュリティデバイス（Security Devices）] ページには、フィルタでチェックした SDC を使用して Security Cloud Control に接続しているデバイスのみが表示されます。
ステップ 7	（オプション）検索をさらに絞り込むには、フィルタメニューで追加のフィルタをチェックします。
ステップ 8	（オプション）完了したら、[セキュリティデバイス（Security Devices）] ページの上部にある [クリア（Clear）] ボタンをクリックして、Security Cloud Control で管理しているすべてのデバイスとサービスを表示します。

SDC のオープンソースおよびサードパーティライセンス

================================================================================

* amqplib *

Michael Bridgen <mikeb@squaremobius.net>

This package, "amqplib", is licensed under the MIT License. A copy maybe found in the file LICENSE-MIT in this directory, or downloaded from

http://opensource.org/licenses/MIT

================================================================================

* async *

Permission is hereby granted, free of charge, to any person obtaining a copyof this software and associated documentation files（the "Software"）, to dealin the Software without restriction, including without limitation the rightsto use, copy, modify, merge, publish, distribute, sublicense, and/or sellcopies of the Software, and to permit persons to whom the Software isfurnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included inall copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS ORIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THEAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHERLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS INTHE SOFTWARE.

================================================================================

* bluebird *

The MIT License（MIT）

The above copyright notice and this permission notice shall be included inall copies or substantial portions of the Software.

================================================================================

* cheerio *

Permission is hereby granted, free of charge, to any person obtaining a copyof this software and associated documentation files (the 'Software'), to dealin the Software without restriction, including without limitation the rightsto use, copy, modify, merge, publish, distribute, sublicense, and/or sellcopies of the Software, and to permit persons to whom the Software isfurnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included inall copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND, EXPRESS ORIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THEAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHERLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS INTHE SOFTWARE.

================================================================================

* command-line-args *

The MIT License (MIT)

The above copyright notice and this permission notice shall be included in allcopies or substantial portions of the Software.

================================================================================

* ip *

This software is licensed under the MIT License.

The above copyright notice and this permission notice shall be included in allcopies or substantial portions of the Software.

================================================================================

* json-buffer *

Permission is hereby granted, free of charge,to any person obtaining a copy of this software andassociated documentation files (the "Software"), todeal in the Software without restriction, includingwithout limitation the rights to use, copy, modify,merge, publish, distribute, sublicense, and/or sellcopies of the Software, and to permit persons to whomthe Software is furnished to do so,subject to the following conditions:

The above copyright notice and this permission noticeshall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIESOF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FORANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THESOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

================================================================================

* json-stable-stringify *

This software is released under the MIT license:

Permission is hereby granted, free of charge, to any person obtaining a copy ofthis software and associated documentation files (the "Software"), to deal inthe Software without restriction, including without limitation the rights touse, copy, modify, merge, publish, distribute, sublicense, and/or sell copies ofthe Software, and to permit persons to whom the Software is furnished to do so,subject to the following conditions:

The above copyright notice and this permission notice shall be included in allcopies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS ORIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESSFOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS ORCOPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHERIN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR INCONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

================================================================================

* json-stringify-safe *

The ISC License

Permission to use, copy, modify, and/or distribute this software for anypurpose with or without fee is hereby granted, provided that the abovecopyright notice and this permission notice appear in all copies.

THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIESWITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OFMERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FORANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGESWHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN ANACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF ORIN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

================================================================================

* lodash *

Based on Underscore.js, copyright Jeremy Ashkenas,

DocumentCloud and Investigative Reporters & Editors<http://underscorejs.org/>

This software consists of voluntary contributions made by manyindividuals. For exact contribution history, see the revision historyavailable at https://github.com/lodash/lodash

The following license applies to all parts of this software except as

documented below:

====

Permission is hereby granted, free of charge, to any person obtaininga copy of this software and associated documentation files（the"Software"）, to deal in the Software without restriction, includingwithout limitation the rights to use, copy, modify, merge, publish,distribute, sublicense, and/or sell copies of the Software, and topermit persons to whom the Software is furnished to do so, subject tothe following conditions:

The above copyright notice and this permission notice shall beincluded in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OFMERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE ANDNONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BELIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTIONOF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTIONWITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

====

Copyright and related rights for sample code are waived via CC0. Samplecode is defined as all source code displayed within the prose of thedocumentation.

CC0: http://creativecommons.org/publicdomain/zero/1.0/

====

Files located in the node_modules and vendor directories are externallymaintained libraries used by this software which have their ownlicenses; we recommend you read them, as their terms may differ from theterms above.

================================================================================

* log4js *

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions andlimitations under the License.

================================================================================

* mkdirp *

This project is free software released under the MIT/X11 license:

The above copyright notice and this permission notice shall be included inall copies or substantial portions of the Software.

================================================================================

* node-forge *

New BSD License (3-clause)

Redistribution and use in source and binary forms, with or withoutmodification, are permitted provided that the following conditions are met:

* Redistributions of source code must retain the above copyrightnotice, this list of conditions and the following disclaimer.

* Redistributions in binary form must reproduce the above copyrightnotice, this list of conditions and the following disclaimer in thedocumentation and/or other materials provided with the distribution.

* Neither the name of Digital Bazaar, Inc. nor thenames of its contributors may be used to endorse or promote productsderived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" ANDANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIEDWARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE AREDISCLAIMED. IN NO EVENT SHALL DIGITAL BAZAAR BE LIABLE FOR ANYDIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED ANDON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THISSOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

================================================================================

* request *

Apache License

Version 2.0, January 2004

http://www.apache.org/licenses/

TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

1. Definitions.

"License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document.

"Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License.

"Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.

"You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License.

"Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files.

"Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types.

"Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below).

"Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.

"Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution."

"Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work.

2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.

3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:

You must give any other recipients of the Work or Derivative Works a copy of this License; and

You must cause any modified files to carry prominent notices stating that You changed the files; and

You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and

If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.

5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.

6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.

7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.

8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages.

9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability.

END OF TERMS AND CONDITIONS

================================================================================

* rimraf *

The ISC License

================================================================================

* uuid *

MIT License - http://opensource.org/licenses/mit-license.php

================================================================================

* validator *

Permission is hereby granted, free of charge, to any person obtaininga copy of this software and associated documentation files（the"Software"）, to deal in the Software without restriction, includingwithout limitation the rights to use, copy, modify, merge, publish,distribute, sublicense, and/or sell copies of the Software, and topermit persons to whom the Software is furnished to do so, subject tothe following conditions:

The above copyright notice and this permission notice shall beincluded in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OFMERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE ANDNONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BELIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTIONOF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTIONWITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

================================================================================

* when *

Open Source Initiative OSI - The MIT License

http://www.opensource.org/licenses/mit-license.php

Permission is hereby granted, free of charge, to any person obtaininga copy of this software and associated documentation files（the"Software"）, to deal in the Software without restriction, includingwithout limitation the rights to use, copy, modify, merge, publish,distribute, sublicense, and/or sell copies of the Software, and topermit persons to whom the Software is furnished to do so, subject tothe following conditions:

The above copyright notice and this permission notice shall beincluded in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OFMERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE ANDNONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BELIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTIONOF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTIONWITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.================================================================================

サポートされるデバイス、ソフトウェア、ハードウェア

Security Cloud Control は、複数のセキュリティプラットフォームにおけるセキュリティポリシーとデバイス設定を管理できるクラウドベースの管理ソリューションです。Security Cloud Control は、以下のポリシーと設定を集中管理します。

Cisco Secure Firewall ASA（オンプレミスと仮想）
Cisco Secure Firewall Threat Defense（FTD）（オンプレミスと仮想）
Cisco Catalyst SD-WAN Manager
Cisco Secure Firewall Management Center（オンプレミス）
Cisco Meraki MX
Cisco IOS デバイス
Cisco Umbrella
AWS セキュリティグループ

ドキュメントでは、デバイス、ソフトウェア、およびハードウェア Security Cloud Control サポートについて説明しています。Security Cloud Control がサポートしていないソフトウェアやデバイスについては触れていません。ソフトウェアのバージョンまたはデバイスタイプのサポートを明示的に記載していない場合、それはサポートされません。

Cisco Secure Firewall ASA

Cisco 適応型セキュリティアプライアンス（ASA）は、ファイアウォール、VPN、および侵入防御機能を統合したセキュリティデバイスです。不正アクセス、サイバー脅威、データ侵害からネットワークを保護し、単一のプラットフォームで堅牢なセキュリティサービスを提供します。Security Cloud Control は、Cisco ASA デバイスの管理をサポートし、設定管理を合理化してネットワークインフラストラクチャ全体で規制遵守を確保する機能を提供します。

Cisco Secure Firewall Threat Defense

Firewall Threat Defense は、従来のファイアウォール機能と高度な脅威防御機能を統合します。侵入防御、アプリケーション制御、URL フィルタリング、高度なマルウェア防御などを含む包括的なセキュリティ機能を提供します。FTD は、ASA ハードウェアアプライアンス、Cisco ファイアウォールハードウェアアプライアンス、および仮想環境に展開できます。Threat Defense デバイスの管理は、Cisco Firewall Management Center、Security Cloud Control、Firewall Device Manager などのさまざまな管理インターフェイスを介して実行できます。

ソフトウェアおよびハードウェア互換性の詳細については、Cisco Secure Firewall Threat Defense 互換性ガイドを参照してください。

Firewall Device Manager は、Threat Defense デバイス管理用に明示的に設計された Web ベースの管理インターフェイスです。Threat Defense デバイスを設定およびモニターするためのシンプルなアプローチを提供するため、小規模な展開や、直感的なインターフェイスを求める組織に最適です。

FDM は、ネットワーク設定、アクセスコントロールポリシー、NAT ルール、VPN 設定、モニタリング、および基本的なトラブルシューティングに関する基本的な設定機能を提供します。通常、Web ブラウザを介してアクセスする FDM は、FTD デバイスで直接使用できるため、追加の管理サーバーやアプライアンスは必要ありません。

Cisco Catalyst SD-WAN Manager

Security Cloud Control によって、Catalyst SD-WAN およびブランチ WAN の環境を中央管理できるようになり、組織がネットワーク全体でセキュリティポリシーを効率的に設定、監視、および適用できるようになります。この統合により、Catalyst SD-WAN Manager での高度なトラブルシューティング、ルールの最適化、および変更管理も容易になります。

ソフトウェアとハードウェアの互換性の詳細については、「Cisco Catalyst SD-WAN Device Compatibility」を参照してください。

Cisco Secure Firewall Management Center

Security Cloud Control は、セキュアな統合を確立し、セキュリティデバイスを検出し、一元化されたポリシー管理を有効にすることで、オンプレミスの Firewall Management Center の管理を簡素化します。ファイアウォールルール、VPN 設定、侵入防御ポリシーなどのセキュリティポリシーを、FMC 下にあるすべてのデバイスにわたって効率的に管理および展開できます。

Cisco Meraki MX

Cisco Meraki MX アプライアンスは、分散型展開用に設計されたエンタープライズグレードセキュリティおよび SD-WAN の次世代ファイアウォールアプライアンスです。Security Cloud Control は、Cisco Meraki MX デバイス上のレイヤ 3 ネットワークルールの管理をサポートします。Meraki デバイスを Security Cloud Control にオンボーディングすると、Meraki ダッシュボードと通信してそのデバイスを管理します。Security Cloud Control は設定要求を Meraki ダッシュボードに安全に転送し、新しい設定をデバイスに適用します。Cisco Meraki MX をサポートする Security Cloud Control の主な機能には、ポリシーの一元管理、バックアップと復元、モニタリングとレポート、コンプライアンスチェック、自動化機能などがあります。

Cisco IOS デバイス

Cisco IOS は、ルーティング、スイッチング、その他のネットワーキングプロトコルなどのネットワーク機能を管理および制御できます。シスコのネットワークデバイスを設定および維持するための一連の機能とコマンドを提供し、さまざまな規模および複雑さのネットワークでの効率的な通信と管理を可能にします。

Cisco Umbrella

Security Cloud Control は、Cisco Umbrella ASA 統合などの統合を通じて Cisco Umbrella を管理します。これにより管理者は、インターフェイスごとのポリシーを使用して、Cisco 適応型セキュリティアプライアンス（ASA）を Cisco Umbrella 設定に含めることができます。この統合により、ASA が DNS クエリを Cisco Umbrella にリダイレクトすることが可能になり、Cisco Umbrella の DNS セキュリティ、Web フィルタリング、および脅威インテリジェンス機能を活用してネットワークセキュリティを強化できます。

AWS セキュリティグループ

Security Cloud Control は、Amazon Web Services（AWS）仮想プライベートクラウド（VPC）向けの簡素化された管理インターフェイスを提供します。主な機能には、AWS サイト間 VPN 接続のモニタリング、AWS デバイスへの変更の追跡、AWS サイト間 VPN トンネルの表示が含まれます。

Secure Firewall Threat Defense デバイスのサポートの詳細

Secure Firewall Threat Defense はシスコ⁪の次世代ファイアウォールです。さまざまなハードウェアおよび仮想プラットフォームにインストールできます。Cisco Secure Firewall Threat Defense Compatibility Guide を参照してください。

Firewall Threat Defense with Secure Firewall Device Manager

Firewall Device Manager を使用して、Threat Defense のバージョン 6.4 以降に Security Cloud Control 管理を追加できます。ただし、このオプションは、テナントでデバイスマネージャのサポートがすでに有効になっている場合にのみ、リクエストに応じて使用できます。参照：

TAC でサポートチケットを開くを参照してこのオプションをリクエストしてください。
サポートしている機能の詳細については、「Security Cloud Control での FDM デバイスの管理」を参照してください。
導入の前提条件と要件の詳細については、「FDM-managed デバイスの導入準備」を参照してください。

Snort

Threat Defense バージョン 6.7 以降（デバイスマネージャを使用）およびバージョン 7.0 以降（Management Center を使用）では、Snort 3 がデフォルトの検査エンジンです。

重要	まだ Snort 2 検査エンジンを使用している場合は、検出とパフォーマンスを向上させるために、今すぐ Snort 3 に切り替えてください。Snort 2 は将来のリリースで廃止され、最終的に Threat Defense のアップグレードを妨げるものになります。

FDM-Managedデバイスのオンボード

FDM-managed デバイス管理

FDM-managed Firewall Threat Defense デバイスは Security Cloud Control にのみオンボーディングできます。これらのデバイスは Cloud-Delivered Firewall Management Center では管理できません。

デバイスがローカル管理用に設定されていない場合は、デバイスをオンボードする前にローカル管理に切り替える必要があります。『Cisco Secure Firewall Threat Defense Configuration Guide for Firepower Device Manager』[英語] の「Switching Between Local and Remote Management」[英語] の章を参照してください。

ライセンシング

デバイスを Security Cloud Control にオンボードするには、デバイスに少なくともライセンスがインストールされている必要があります（ただし状況によってはスマートライセンスを適用できる場合もあります）。


オンボーディング方式	Secure Firewall Device Manager ソフトウェアバージョン	90 日間の評価ライセンスは許可されていますか？	オンボーディングするデバイスに予めスマートライセンスを付与できますか？	オンボーディングするデバイスを予め Cisco Cloud サービスに登録できますか？
ログイン情報（ユーザー名とパスワード）	6.4 以降	対応	対応	対応
登録キー	6.4 または 6.5	○	いいえ。スマートライセンスを登録解除してからデバイスをオンボードしてください。	該当なし
登録キー	6.6 以降	対応	対応	いいえ。Cisco Cloud サービスからデバイスを登録解除してからデバイスをオンボードしてください。
Zero-Touch Provisioning	6.7 以降	対応	対応	対応
シリアル番号によるデバイスのオンボーディング	6.7 以降	対応	対応	対応

詳細については『Cisco Firepower システム機能ライセンス』を参照してください。

デバイスのアドレス指定

FDM-managed デバイスのオンボードに使用するアドレスは、静的アドレスにすることをお勧めします。デバイスの IP アドレスが DHCP によって割り当てられている場合は、デバイスの新しい IP アドレスが変更された際に、DDNS（ダイナミックドメインネームシステム）を使用して、デバイスのドメイン名エントリを自動的に更新するのが最適な方法です。

（注）

FDM-managed デバイスはネイティブで DDNS をサポートしていないため、独自の DDNS を設定する必要があります。

重要	デバイスが DHCP サーバーから IP アドレスを取得するようにした後、DDNS サーバーの FDM-managed デバイスのドメイン名エントリを新しい IP アドレスで更新していない場合、またはデバイスが新しいアドレスを受け取った場合は、マネージャがデバイス用に管理する IP アドレスを変更し、その後デバイスを再接続できます。さらに良い方法は、登録キーを使用してデバイスをオンボードすることです。

内部インターフェイスからの FDM-Managed デバイスの管理

専用の MGMT インターフェイスに組織内でルーティングできないアドレスが割り当てられている場合は、内部インターフェイスを使用して FDM-managed デバイスを管理することが望ましい場合があります。たとえば、データセンターまたはラボ内からしか到達できない場合などです。

リモートアクセス VPN の要件

Security Cloud Control で管理する FDM-managed デバイスがリモートアクセス VPN（RA VPN）接続を管理する場合、Security Cloud Control は内部インターフェイスを使用してデバイスを管理する必要があります。

次に行う作業：

FDM-managed デバイスを設定する手順については、内部インターフェイスからの FDM-Managed デバイスの管理に進んでください。

内部インターフェイスからの FDM-Managed デバイスの管理

設定方法は次のとおりです。

FDM-managed デバイスが Security Cloud Control にオンボードされていないことが前提です。
データインターフェイスを内部インターフェイスとして設定します。
MGMT トラフィック（HTTPS）を受信するように内部インターフェイスを設定します。
Cloud Connector のアドレスがデバイスの内部インターフェイスに到達できるようにします。

始める前に

この設定の前提条件を以下で確認してください。

内部インターフェイスからの FDM-Managed デバイスの管理
管理対象デバイスへの Security Cloud Control の接続

手順

ステップ 1	Secure Firewall Device Manager にログインします。
ステップ 2	[システム設定（System Settings）] メニューで、[管理アクセス（Management Access）] をクリックします。
ステップ 3	[データインターフェース（Data Interfaces）] タブをクリックし、[データインターフェースの作成（Create Data Interface）] を選択します。 [インターフェース（Interface）] フィールドで、インターフェースのリストから「 inside 」という名前のインターフェースを選択します。 [プロトコル（pre-named）] フィールドがまだ選択されていない場合は、[HTTPS] を選択します。 [許可されたネットワーク（Allowed Networks）] フィールドで、組織内に配置され FDM-managed デバイスの内部アドレスへのアクセスが許可されているネットワークを示すネットワークオブジェクトを選択します。SDC または Cloud Connector の IP アドレスは、デバイスの内部アドレスへのアクセスが許可されているアドレス群の中にある必要があります。「インターフェイスアドレス」図の中では、SDC の IP アドレス 192.168.1.10 が 192.168.1.1 に到達可能である必要があります。
ステップ 4	変更を展開します。これで、内部インターフェイスを使用してデバイスを管理できるようになりました。

次のタスク

Cloud Connector を使用している場合

上記の手順に加えて、以下の手順を実行します。

外部インターフェイス（203.0.113.2）から内部インターフェイス（192.168.1.1）への「NAT」を実行するステップを追加します。「インターフェイスアドレス」を参照してください。
上記の手順のステップ 3c では、「許可されたネットワーク」は、クラウドコネクタのパブリック IP アドレスを含むネットワークグループオブジェクトです。
クラウドコネクタのパブリック IP アドレスから外部インターフェイス（203.0.113.2）へのアクセスを許可するアクセス制御ルールの作成ステップを追加します。さまざまな Security Cloud Control リージョンのクラウドコネクタ IP アドレスのリストについては、参照してください。

FDM-Managed デバイスの導入準備

Security Cloud Control への FDM-managed デバイスの導入準備をする際、登録トークンを使用した導入準備方法をお勧めします。Cloud Connector から FDM-managed デバイスへの管理アクセスを許可するように内部インターフェイスを設定した後に、ユーザー名とパスワードを使用して FDM-managed デバイスの導入準備をします。詳細については、「ユーザー名、パスワード、IP アドレスを使用した FDM-managed デバイスの導入準備」を参照してください。内部インターフェイスの IP アドレスを使用して接続します。上記シナリオでは、そのアドレスは 192.168.1.1 です。

外部インターフェイスからの FDM-Managed デバイスの管理

分散拠点に 1 つのパブリック IP アドレスが割り当てられていて、Security Cloud Control が別の場所にある Cloud Connector を使用して管理されている場合は、外部インターフェイスから Cloud-Delivered Firewall Management Center デバイスを管理することを推奨します。

この設定により、MGMT 物理インターフェイスがデバイスの管理インターフェイスでなくなるわけではありません。Cloud-Delivered Firewall Management Center デバイスの設置場所にいる場合は、MGMT インターフェイスのアドレスに接続して、デバイスを直接管理できます。

リモートアクセス VPN の要件

Cloud-Delivered Firewall Management Center を使用して管理するデバイスで、リモートアクセス VPN（RA VPN）接続を管理する場合、Cloud-Delivered Firewall Management Center は外部インターフェイスを使用して Cloud-Delivered Firewall Management Center デバイスを管理できません。代わりに、「内部インターフェイスからの FDM-Managed デバイスの管理」を参照してください。

次に行う作業：

Cloud-Delivered Firewall Management Center デバイスを設定する手順については、FDM-Managed デバイスの外部インターフェイスを管理するに進んでください。

FDM-Managed デバイスの外部インターフェイスを管理する

設定方法は次のとおりです。

FDM-managed デバイスが Security Cloud Control にオンボードされていないことが前提です。
データインターフェイスを外部インターフェイスとして設定します。
外部インターフェイスで管理アクセスを設定します。
Cloud Connector のパブリック IP アドレス（ファイアウォールによる NAT 処理済み）が外部インターフェイスに到達できるようにします。

始める前に

この設定の前提条件を以下で確認してください。

FDM-Managed デバイスの外部インターフェイスを管理する
管理対象デバイスへの Security Cloud Control の接続

手順

ステップ 1	Secure Firewall Device Manager にログインします。
ステップ 2	[システム設定（System Settings）] メニューで、[管理アクセス（Management Access）] をクリックします。
ステップ 3	[データインターフェース（Data Interfaces）] タブをクリックし、[データインターフェースの作成（Create Data Interface）] を選択します。 [インターフェイス] フィールドで、インターフェイスのリストから「outside」という名前のインターフェイルを選択します。 [プロトコル（Protocols）] フィールドでまだ選択されていない場合は、[HTTPS] を選択します。Security Cloud Control には HTTPS アクセスのみが必要です。 [許可ネットワーク（Allowed Networks）] フィールドで、ファイアウォールによる NAT 処理済みの Cloud Connector のパブリック方向 IP アドレスを含むホストネットワークオブジェクトを作成します。「外部インターフェイスからのデバイス管理」のネットワーク図では、Cloud Connector の IP アドレス 10.10.10.55 が 203.0.113.2 に NAT 処理されています。許可ネットワークの場合は、203.0.113.2 という値を使用してホストネットワークオブジェクトを作成します。
ステップ 4	SDC または Cloud Connector のパブリック IP アドレスから FDM-managed デバイスの外部インターフェイスへの管理トラフィック（HTTPS）を許可するアクセスコントロールポリシーを、Secure Firewall Device Manager で作成します。このシナリオでは、送信元アドレスは 203.0.113.2 で、送信元プロトコルは HTTPS です。また、宛先アドレスは 209.165.202.129 で、宛先プロトコルは HTTPS です。
ステップ 5	変更を展開します。これで、外部インターフェイスを使用してデバイスを管理できるようになります。

次のタスク

Cloud Connector を使用している場合

プロセスは非常によく似ていますが、次の 2 つの点が異なります。

上記の手順のステップ 3c では、「許可されたネットワーク」は、クラウドコネクタのパブリック IP アドレスを含むネットワークグループオブジェクトです。さまざまな Security Cloud Control リージョンのクラウドコネクタ IP アドレスのリストについては、「Cloud Connector を介したデバイスの Security Cloud Control への接続」を参照してください。
上記の手順のステップ 4 では、Cloud Connector のパブリック IP アドレスから外部インターフェイスへのアクセスを許可するアクセス制御ルールを作成します。

FDM-managed デバイスの Security Cloud Control への導入準備を行う際は、「登録トークンの導入準備」のアプローチを推奨します。Cloud Connector からの管理アクセスを許可するように外部インターフェイスを設定した後に、FDM-managed デバイスの導入準備を行います。外部インターフェイスの IP アドレスを使用して接続します。このシナリオでは、該当するアドレスは 209.165.202.129 です。

Security Cloud Control への FDM-Managed デバイスのへのオンボード

次の手順を使用して、次の方法で FDM-managed を Security Cloud Control にオンボードします。

ユーザー名、パスワード、IP アドレスを使用した FDM-Managed デバイスの導入準備

この手順に従い、デバイスのログイン情報とデバイスの管理 IP アドレスのみを使用して FDM-managed デバイスの導入準備を行います。これは、FDM-managed デバイスを導入準備する際の最も簡単な方法です。

ただし、Security Cloud Control への FDM-managed デバイスの導入準備で推奨される方法は、登録キーの使用です。

始める前に

重要	Security Cloud Control に FDM-managed デバイスを導入準備する前に、「FDM-managed デバイスの導入準備」および管理対象デバイスへの Security Cloud Control の接続を確認してください。これらの資料には、デバイスのオンボーディングに必要な一般的なデバイス要件とオンボーディングの前提条件が示されています。

ログイン情報方式を使用して FDM-managed デバイスを導入準備するには、次の情報が必要です。
- Security Cloud Control がデバイスへの接続に使用するデバイスログイン情報。
- デバイスの管理に使用しているインターフェイスの IP アドレス。このインターフェイスは、ネットワークの設定方法に応じて、管理インターフェイス、内部インターフェイス、または外部インターフェイスになります。
- デバイスを Security Cloud Control に導入準備するには、Secure Firewall Device Manager で管理し、ローカル管理用に設定する必要があります。Secure Firewall Management Center では管理できません。

（注）

FDM-managed デバイスがソフトウェアバージョン 6.4 を実行しており、https://security.cisco.com に接続する場合は、この方法を使用する必要があります。ソフトウェアバージョン 6.5 以降を実行している FDM-managed デバイスのみを導入準備できます。

手順

ステップ 1

Security Cloud Control にログインします。

ステップ 2

左側のペインで Security Devices をクリックします。

ステップ 3

青色のプラスボタンをクリックして、デバイスをオンボードします。

ステップ 4

[FTD] をクリックします。

重要	FDM-managed デバイスを導入準備しようとすると、Security Cloud Control では、Secure Firewall Threat Defense エンドユーザーライセンス契約書（EULA）に目を通して同意するように求められます。これはテナントで 1 回限りのアクティビティです。EULA に同意すると、EULA が変更されない限り、Security Cloud Control が同意を求めるプロンプトを再度表示することはありません。

ステップ 5

導入準備ウィザードで、[クレデンシャルの使用（Use Credentials）] をクリックします。

ステップ 6

[デバイスの詳細（Device Details）] ステップで、以下の手順を実行します。

[Secure Device Connector] ボタンをクリックし、ネットワークにインストールされている Secure Device Connector（SDC）を選択します。SDC を使用しない場合、Security Cloud Control は Cloud Connector を使用して FDM-managed デバイスに接続できます。

どちらを選択するかは、Security Cloud Control を管理対象デバイスに接続する方法によって異なります。
[デバイス（Device Name）] フィールドにデバイス名を入力します。デバイスのホスト名またはその他の任意の名前にすることができます。
[ロケーション（Location）] フィールドに、デバイスの管理に使用しているインターフェイスの IP アドレス、ホスト名、またはデバイスの完全修飾ドメイン名を入力します。デフォルトのポートは 443 です。

重要

SecureX または Cisco Threat Response（CTR）アカウントをすでにお持ちの場合、デバイスを SecureX に登録するには、Security Cloud Control テナントと SecureX/CTR アカウントをマージする必要があります。アカウントは、SecureX ポータルから統合できます。手順については「Security Cloud Control アカウントと SecureX アカウントのマージ」を参照してください。アカウントがマージされるまで、デバイスのイベントを SecureX で表示したり、他の SecureX 機能を利用したりすることはできません。

ステップ 7

[データベースの更新（Database Updates）] 領域では、[セキュリティ更新を即時に実行し、定期更新を有効にする（Enable Immediately security updates、and enable recurring updates）] がデフォルトで有効になっています。このオプションは、セキュリティ更新をすぐにトリガーするとともに、毎週月曜日の午前 2 時に追加の更新をチェックするようにデバイスを自動的にスケジュールします。詳細については、『Update FTD Security Databases』と『Schedule a Security Database Update』を参照してください。

このオプションを無効にしても、以前に FDM を使用して設定したスケジュール済みの更新には影響しません。

[次へ（Next）] をクリックします。

ステップ 8

デバイス管理者のユーザー名とパスワードを入力し、[次へ（Next）] をクリックします。

ステップ 9

デバイスの Secure Firewall Device Manager に保留中の変更がある場合は通知され、変更を元に戻すか、マネージャにログインして保留中の変更を展開できます。Secure Firewall Device Manager に保留中の変更がない場合、プロンプトは表示されません。

ステップ 10

（任意）デバイスにラベルを追加します。詳細については、『Labels and Label Groups』を参照してください。

登録キーを使用したソフトウェアバージョン 6.4 または 6.5 を実行する FDM-Managed デバイスの導入準備

この手順では、登録キーを使用して FDM-managed デバイスを導入準備する方法について説明します。この方法は FDM-managed デバイスを Security Cloud Control に導入準備するための推奨される方法であり、DHCP を使用して FDM-managed デバイスに IP アドレスが割り当てられている場合に適しています。その IP アドレスが何らかの理由で変更されても、FDM-managed デバイスは Security Cloud Control に接続されたままになります。さらに、FDM-managed デバイスはローカルエリアネットワーク上のアドレスを持つことができ、外部ネットワークにアクセスできる限り、この方法で Security Cloud Control に導入準備できます。

警告

SecureX または Cisco Threat Response（CTR）アカウントをすでにお持ちの場合、デバイスを SecureX に登録するには、Security Cloud Control テナントと SecureX/CTR アカウントを統合する必要があります。アカウントがマージされるまで、デバイスのイベントを SecureX で表示したり、他の SecureX 機能を利用したりすることはできません。SecureX で Security Cloud Control モジュールを作成する前に、アカウントをマージすることを強くお勧めします。アカウントは、SecureX ポータルからマージできます。手順については、「アカウントの統合」を参照してください。

オンボーディング前

バージョン 6.4 を実行しているお客様の場合、このオンボーディング方法は US リージョン（https://security.cisco.com）でのみサポートされます。
バージョン 6.4 を実行し、EU リージョンに接続しているお客様の場合、デバイスのユーザー名、パスワード、および IP アドレスを使用してデバイスをオンボードする必要があります。
バージョン 6.5 以降を実行しており、US、EU、または APJ リージョンのいずれかに接続しているお客様は、登録キーを使用してオンボードできます。
Security Cloud Control を FDM-managed デバイスに接続するために必要なネットワーク要件を管理対象デバイスへの Security Cloud Control の接続で確認します。
ではなく、Secure Firewall Device Manager でデバイスが管理されていることを確認してください。
バージョン 6.4 および 6.5 を実行しているデバイスは、登録キーを使用してデバイスをオンボーディングしてから、デバイスを Cisco Smart Software Manager に登録する必要があります。それらの FDM-managed デバイスを Security Cloud Control にオンボーディングする前に、デバイスのスマートライセンスを登録解除する必要があります。下の「スマートライセンス取得済みの Firewall Device Manager の登録解除」を参照してください。
デバイスが 90 日間の評価ライセンスを使用している可能性があります。
FDM-managed デバイスにログインし、デバイスで待機している保留中の変更がないことを確認します。
FDM-managed デバイスで DNS が正しく設定されていることを確認します。
FDM-managed デバイスでタイムサービスが正しく設定されていることを確認します。
FDM-managed デバイスに正しい日付と時刻が表示されていることを確認します。そうでない場合はオンボーディングが失敗します。

次の作業

次の 2 つの操作のいずれかを実行します。

FDM-managed デバイスにすでにスマートライセンスが適用されている場合は、Cisco Smart Software Manager から、このデバイスの登録を解除します。登録キーを使用してデバイスを Security Cloud Control にオンボードする前に、Cisco Smart Software Manager からデバイスの登録を解除する必要があります。スマートライセンス取得済み FDM-Managed デバイスの登録解除に進みます。
デバイスにスマートライセンスが適用されていない場合は、登録キーを使用したソフトウェアバージョン 6.4 または 6.5 を実行する FDM-Managed デバイスの導入準備手順に進みます。

スマートライセンス取得済み FDM-Managed デバイスの登録解除

導入準備するデバイスがバージョン 6.4 または 6.5 を実行しており、すでにスマートライセンスが付与されている場合、デバイスは Cisco Smart Software Manager に登録されている可能性があります。登録キーを使用してデバイスを Security Cloud Control にオンボードする前に、Cisco Smart Software Manager からデバイスの登録を解除する必要があります。登録を解除すると、仮想アカウントでデバイスに関連付けられている基本ライセンスとすべてのオプションライセンスが解放されます。

デバイスの登録を解除すると、デバイスの現在の設定とポリシーはそのまま機能しますが、変更を加えたり展開したりすることはできません。

手順

ステップ 1	Secure Firewall Device Manager を使用してデバイスにログオンします。
ステップ 2	上部のタブのデバイスアイコンをクリックします。
ステップ 3	[スマートライセンス（Smart License）] 領域で、 [設定の表示（View Configuration）] をクリックします。
ステップ 4	[クラウドサービスに移動（Go to Cloud Services）] 歯車メニューをクリックして、[デバイスの登録解除（Unregister Device）] を選択します。
ステップ 5	警告を確認し、[登録解除（Unregister）] をクリックしてデバイスの登録を解除します。

次のタスク

Security Cloud Control に導入準備するためにデバイスの登録を解除した場合は、登録キーを使用したソフトウェアバージョン 6.4 または 6.5 を実行する FDM-Managed デバイスの導入準備手順に進みます。

登録キーを使用したソフトウェアバージョン 6.4 または 6.5 を実行する FDM-Managed デバイスの導入準備手順

登録キーを使用して FDM-managed をオンボードするには、次の手順に従います。

始める前に

登録キーを使用したソフトウェアバージョン 6.4 または 6.5 を実行する FDM-Managed デバイスの導入準備で説明されている前提条件を確認します。

手順

ステップ 1

Security Cloud Control にログインします。

ステップ 2

左側のペインで Security Devices をクリックします。

ステップ 3

青色のプラスボタンをクリックして、デバイスをオンボードします。

ステップ 4

[FTD] をクリックします。

重要	FDM-managed デバイスをオンボーディングしようとすると、Security Cloud Control では、Firepower Threat Defense エンドユーザーライセンス契約書（EULA）に目を通して同意するように求められます。これはテナントで 1 回限りのアクティビティです。この契約に同意すると、以降の FDM-managed オンボーディングで Security Cloud Control から再度プロンプトが表示されることはありません。EULA 契約に将来変更が生じた場合はプロンプトが表示され、再度同意する必要があります。

ステップ 5

[FTD デバイスのオンボード（Onboard FTD Device）] 画面で、[登録キーの使用（Use Registration Key）] をクリックします。

ステップ 6

[デバイス（Device Name）] フィールドにデバイス名を入力します。デバイスのホスト名またはその他の任意の名前にすることができます。

ステップ 7

[データベースの更新（Database Updates）] 領域では、[セキュリティ更新を即時に実行し、定期更新を有効にする（Enable Immediately security updates、and enable recurring updates）] オプションがデフォルトで有効になっています。このオプションは、セキュリティ更新をすぐにトリガーするとともに、毎週月曜日の午前 2 時に追加の更新をチェックするようにデバイスを自動的にスケジュールします。詳細については、『Update FTD Security Databases』と『Schedule a Security Database Update』を参照してください。

（注）

このオプションを無効にしても、以前に Secure Firewall Device Manager を使用して設定したスケジュール済みの更新には影響しません。

ステップ 8

Security Cloud Control によって [登録キーの作成（Create Registration Key）] 領域に登録キーが生成されます。

（注）

キーが生成された後でデバイスが完全にオンボーディングされる前にオンボーディング画面から移動すると、オンボーディング画面に戻ることができません。ただし、Security Cloud Control によって [セキュリティデバイス（Security Devices）] ページにそのデバイスのプレースホルダが作成されます。デバイスのプレースホルダを選択すると、右側にあるアクションペインに、そのデバイスのキーが表示されます。

ステップ 9

[コピー（Copy）] アイコンをクリックして登録キーをコピーします。

（注）

登録キーのコピーをスキップして [次へ（Next）] をクリックすると、デバイスのプレースホルダエントリを完了した後でデバイスを登録できます。このオプションは、最初にデバイスを作成してから登録する場合、またはシスコネットワークパートナーがカスタマーネットワークに価値の実証（POV）デバイスをインストールする場合に役立ちます。

[セキュリティデバイス（Security Devices）] ページで、デバイスの接続状態が「プロビジョニング解除（Unprovisioned）」になっていることを確認できます。[プロビジョニング解除（Unprovisioned）] の下に表示される登録キーを Firewall Device Manager にコピーして、オンボーディングプロセスを完了します。

ステップ 10

Security Cloud Control にオンボードするデバイスの Secure Firewall Device Manager にログインします。

ステップ 11

[システム設定（System Settings）] で、[クラウドサービス（Cloud Services）] をクリックします。

ステップ 12

Security Cloud Control タイルで、[はじめに（Get Started）] をクリックします。

ステップ 13

[リージョン（Region）] フィールドで、テナントが割り当てられている Cisco Cloud のリージョンを選択します。

（注）

この手順は、バージョン 6.4 を実行している FDM-managed デバイスには適用されません。

ステップ 14

[登録キー（Registration Key）] フィールドに、Security Cloud Control で生成した登録キーを貼り付けます。

ステップ 15

[登録（Register）] をクリックし、[シスコの開示情報を受け入れる（Accept the Cisco Disclosure）] をクリックします。

ステップ 16

Security Cloud Control に戻ります。デバイスに適用するすべてのライセンスを選択します。

詳細については、「スマートライセンスの適用または更新」を参照してください。[スキップ（Skip）] をクリックして、90 日間の評価ライセンスでオンボーディングを続行することもできます。

ステップ 17

Security Cloud Control に戻り、[セキュリティデバイス（Security Devices）] ページを開き、デバイスのステータスが [プロビジョニング解除（Unprovisioned）] から [検索中（Locating）]、[同期中（Syncing）]、[同期済み（Synced）] に変わっていくことを確認します。

登録キーを使用したソフトウェアバージョン 6.6 以降を実行する FDM-Managed デバイスの導入準備

この手順では、登録キーを使用して、バージョン 6.6 以降を実行している FDM-managed デバイスを導入準備する方法について説明します。この方法は FDM-managed デバイスを Security Cloud Control に導入準備するための推奨される方法であり、DHCP を使用して FDM-managed デバイスに IP アドレスが割り当てられている場合に適しています。その IP アドレスが何らかの理由で変更されても、FDM-managed デバイスは Security Cloud Control に接続されたままになります。さらに、FDM-managed デバイスはローカルエリアネットワーク上のアドレスを持つことができ、外部ネットワークにアクセスできる限り、この方法で Security Cloud Control に導入準備できます。

警告

バージョン 6.4 または 6.5 を実行している FDM-managed デバイスを導入準備する場合は、「登録キーを使用したソフトウェアバージョン 6.4 または 6.5 を実行する FDM 管理対象デバイスの導入準備」を参照してください。

オンボーディング前

このオンボーディング方法は、現在、バージョン 6.6 以降で、https://security.cisco.com、https://security.cisco.com、または https://security.cisco.com に接続するお客様にご利用いただけます。
Security Cloud Control を FDM-managed デバイスに接続するために必要なネットワーク要件を管理対象デバイスへの Security Cloud Control の接続で確認します。
ではなく、Secure Firewall Device Manager でデバイスが管理されていることを確認してください。
デバイスで 90 日間の評価ライセンスを使用することも、スマートライセンスを使用することもできます。バージョン 6.6 以降を実行しているデバイスは、インストールされているスマートライセンスを登録解除することなく、登録キーを使用して Security Cloud Control に導入準備できます。
デバイスはまだ Cisco Cloud サービスに登録することはできません。導入準備の前に、以下の「Cisco Cloud サービスから FDM-Managed デバイスを登録解除する」を参照してください。
デバイスの Secure Firewall Device Manager UI にログインし、デバイスで待機している保留中の変更がないことを確認します。
FDM-managed デバイスで DNS が正しく設定されていることを確認します。
FDM-managed デバイスでタイムサービスが設定されていることを確認します。
FDM-managed デバイスに正しい日付と時刻が表示されていることを確認します。そうでない場合はオンボーディングが失敗します。

次に行う作業：

次のいずれかの操作を実行します。

バージョン 6.6 以降を実行している FDM-managed デバイスがすでに Cisco Cloud サービスに登録されている場合は、デバイスを導入準備する前に登録を解除する必要があります。Cisco Cloud サービスから FDM-Managed デバイスを登録解除するに進みます。
デバイスが Cisco Cloud サービスに登録されていない場合は、登録キーを使用してソフトウェアバージョン 6.6 以降を実行している FDM-Managed デバイスの導入準備手順に進みます。

Cisco Cloud サービスから FDM-Managed デバイスを登録解除する

次に、Cisco Cloud サービスからデバイスを登録解除する手順を示します。登録キーを使用して Security Cloud Control への FDM-managed デバイスの導入準備をする前に、この方法を使用します。

（注）

バージョン 7.0 以降を実行している仮想 FDM-managed デバイスを導入準備する場合、仮想 FDM-managed デバイスを Security Cloud Control に登録すると、パフォーマンス階層型のスマートライセンスの選択が、デフォルトの階層である [可変（Variable）] に自動的にリセットされます。オンボーディング後に、Secure Firewall Device Manager UI を使用して、デバイスに関連付けられたライセンスに一致する層を手動で再選択する必要があります。

そのデバイスが Cisco Cloud サービスに登録されていないことをチェックして確認するには、次の手順を実行します。

手順

ステップ 1	Secure Firewall Device Manager を使用してデバイスにログオンします。
ステップ 2	上部のタブのデバイスアイコンをクリックします。
ステップ 3	[システム設定（System Settings）] メニューを展開し、[クラウドサービス（Cloud Services）] をクリックします。
ステップ 4	[クラウドサービス（Cloud Services）] ページで、歯車メニューをクリックし、[クラウドサービスの登録解除（Unregister Cloud Services）] を選択します。
ステップ 5	警告を確認し、[登録解除（Unregister）] をクリックしてデバイスの登録を解除します。

次のタスク

ソフトウェア 6.6 以降を実行している FDM-managed デバイスのオンボードを試みている場合は、登録キーを使用してソフトウェアバージョン 6.6 以降を実行している FDM-Managed デバイスの導入準備手順に進みます。

登録キーを使用してソフトウェアバージョン 6.6 以降を実行している FDM-Managed デバイスの導入準備手順

登録キーを使用して FDM-managed デバイスを導入準備するには、次の手順に従います。

手順

ステップ 1

Security Cloud Control にログインします。

ステップ 2

左側のペインで Security Devices をクリックします。

ステップ 3

青色のプラスボタンをクリックして、デバイスをオンボードします。

ステップ 4

[FTD] をクリックします。

重要	FDM-managed デバイスを導入準備しようとすると、Security Cloud Control では、エンドユーザーライセンス契約書（EULA）に目を通して同意するように求められます。これはテナントで 1 回限りのアクティビティです。この契約に同意すると、以降の導入準備で Security Cloud Control から再度プロンプトが表示されることはありません。EULA 契約に将来変更が生じた場合はプロンプトが表示され、再度同意する必要があります。

ステップ 5

[FTD デバイスのオンボード（Onboard FTD Device）] 画面で、[登録キーの使用（Use Registration Key）] をクリックします。

ステップ 6

[デバイス（Device Name）] フィールドにデバイス名を入力します。デバイスのホスト名またはその他の任意の名前にすることができます。

ステップ 7

[データベースの更新（Database Updates）] 領域では、[セキュリティ更新を即時に実行し、定期更新を有効にする（Immediately perform security updates, and enable recurring updates）] がデフォルトで有効になっています。このオプションは、セキュリティ更新をすぐにトリガーするとともに、毎週月曜日の午前 2 時に追加の更新をチェックするようにデバイスを自動的にスケジュールします。詳細については、『Update FTD Security Databases』と『Schedule a Security Database Update』を参照してください。

（注）

このオプションを無効にしても、以前に Secure Firewall Device Manager を使用して設定したスケジュール済みの更新には影響しません。

ステップ 8

Security Cloud Control によって [登録キーの作成（Create Registration Key）] 領域に登録キーが生成されます。

（注）

キーが生成された後でデバイスが完全にオンボーディングされる前にオンボーディング画面から移動すると、オンボーディング画面に戻ることができません。ただし、Security Cloud Control によって [セキュリティデバイス（Security Devices）] ページにそのデバイスのプレースホルダが作成されます。デバイスのプレースホルダを選択すると、そのページにそのデバイスのキーが表示されます。

ステップ 9

[コピー（Copy）] アイコンをクリックして登録キーをコピーします。

（注）

登録キーのコピーをスキップして [次へ（Next）] をクリックすると、デバイスのプレースホルダエントリを完了した後でデバイスを登録できます。このオプションは、最初にデバイスを作成してから登録する場合、またはシスコパートナーがカスタマーネットワークに価値の実証（POV）デバイスをインストールする場合に役立ちます。

ステップ 10

オンボーディングするデバイスの Secure Firewall Device Manager にログインします。

ステップ 11

[システム設定（System Settings）] で、[クラウドサービス（Cloud Services）] をクリックします。

ステップ 12

[リージョン（Region）] フィールドで、テナントが割り当てられている Cisco Cloud のリージョンを選択します。

ステップ 13

[登録タイプ（Enrollment Type）] 領域で、[セキュリティ/アカウント（Security/Account）] をクリックします。

（注）

バージョン 6.6 を実行しているデバイスの場合、Security Cloud Control の [テナンシー（Tenancy ）] タブのタイトルは [セキュリティアカウント（Security Account）] であり、Secure Firewall Device Manager で Security Cloud Control を手動で有効にする必要があることに注意してください。

ステップ 14

[登録キー（Registration Key）] フィールドに、Security Cloud Control で生成した登録キーを貼り付けます。

ステップ 15

バージョン 6.7 以降を実行しているデバイスの場合、[サービス登録（Service Enrollment）] 領域で、[Security Cloud Controlを有効にする（Enable Cisco Defense Orchestrator）] をオンにします。

ステップ 16

Cisco Success Network Enrollment の登録に関する情報を確認します。参加しない場合は、[Cisco Success Networkに登録（Enroll Cisco Success Network）] チェックボックスをオフにします。

ステップ 17

[登録（Register）] をクリックし、[シスコの開示情報を受け入れる（Accept the Cisco Disclosure）] をクリックします。Secure Firewall Device Manager により登録要求が Security Cloud Control に送信されます。

ステップ 18

Security Cloud Control に戻り、[登録キーの作成（Create Registration Key）] 領域で [次へ（Next）] をクリックします。

ステップ 19

デバイスに適用するすべてのライセンスを選択します。[次へ（Next）] をクリックします。

ステップ 20

デバイスのシリアル番号を使用した FDM-Managed デバイスの導入準備

この手順により、FDM-managed デバイスを簡単にセットアップして Security Cloud Control にオンボーディングできます。必要なのは、デバイスのシャーシのシリアル番号または PCA シリアル番号だけです。デバイスのオンボード時に、スマートライセンスを適用するか、90 日間の評価ライセンスを使用できます。

オンボーディング手順を実行する前に、使用例を読んで概念を理解してください。

重要	FDM-managed デバイスをオンボーディングするためのこれらの方法は、バージョン 6.7 以降を実行しているデバイスでのみ使用できます。

使用例

ネットワークに追加され、インターネットを介して到達できる、工場出荷状態の新しい FDM-managed デバイスのオンボーディング。デバイスの初期デバイスセットアップウィザードは完了してしない。
デバイスのシリアル番号を使用した構成済み FDM-Managed デバイスの導入準備：ネットワークにすでに追加されインターネットから到達可能な、設定済みの FDM-managed デバイス、またはアップグレードされたデバイスのオンボーディング。初期デバイスセットアップウィザードは、デバイスで完了している。

重要	この方法を使用して、デバイスでサポートされる古いソフトウェアバージョンで実行されているデバイスをオンボーディングする場合は、アップグレードではなく、そのデバイスでソフトウェアの新規インストール（再イメージ化）を実行する必要があります。

FDM-Managedを使用した Zero-Touch Provisioning デバイスの導入準備ワークフローと前提条件

Zero-Touch Provisioningは、工場出荷状態の新しい Firepower 1000、Firepower 2100、または Secure Firewall 3100 シリーズのデバイスを自動的にプロビジョニングして設定できるようにする機能です。これにより、Security Cloud Control へのデバイスの導入準備にともなう手動タスクの多くが不要になります。zero-touch provisioningは、従業員がネットワークデバイスの操作に慣れていないリモートオフィスやその他の場所を対象としています。

zero-touch provisioning プロセスを使用するには、デバイスを Security Cloud Control に導入準備し、インターネットにアクセスできるネットワークに接続して、デバイスの電源を入れます。詳細については、「デバイスのシリアル番号を使用した構成済み FDM-Managed デバイスの導入準備」を参照してください。

（注）

Security Cloud Control にオンボーディングする前か後にデバイスの電源を入れますが、最初にデバイスを Security Cloud Control にオンボーディングしてから、デバイスの電源を入れてブランチネットワークに接続することをお勧めします。Security Cloud Control にデバイスをオンボーディングすると、デバイスは Cisco Cloud の Security Cloud Control テナントに関連付けられ、Security Cloud Control は自動的にデバイス構成を同期させます。

この手順を使用して、外部ベンダーから購入したデバイスをオンボードしたり、別のリージョンにある別のクラウドテナントによってすでに管理されているデバイスをオンボードしたりもできます。ただし、デバイスが外部ベンダーのクラウドテナントまたは別のリージョンのクラウドテナントにすでに登録されている場合、Security Cloud Control はデバイスをオンボードせず、「デバイスのシリアル番号がすでに要求されている（Device serial number already claimed）」というエラーメッセージを表示します。このような場合、Security Cloud Control 管理者は、デバイスのシリアル番号を以前のクラウドテナントから登録解除してから、独自のテナントで Security Cloud Control デバイスを要求する必要があります。トラブルシューティングの章の「デバイスのシリアル番号がすでに要求されている」を参照してください。

デバイスの [接続（Connectivity）] ステータスが [オンライン（Online）] に変更され、[設定（Configuration）] ステータスが [同期済み（Synced）] に変更されます。FDM-managed デバイスは Security Cloud Control に導入準備されています。

ハードウェアの背面パネルでステータス LED（Firepower 1010）、SYS LED（Firepower 2100）、または S LED（Secure Firewall 3100）が緑色に点滅しているのを確認できます。デバイスがクラウドに接続されている場合、デバイスの LED は緑色で点滅し続けます。デバイスが Cisco Cloud に接続できない場合、または接続後に接続が失われた場合、ステータス LED（Firepower 1010）、SYS LED（Firepower 2100）、または M LED（Secure Firewall 3100）が交互に緑色とオレンジ色に点滅しているのを確認できます。

LED インジケータについて理解するには、「Zero-Touch Provisioningを使用した Cisco Firepower ファイアウォールのインストール」のビデオをご覧ください。

重要

これまでに FDM-managed デバイスコンソール、SSH、Secure Firewall Threat Defense にログインしている場合は、最初のログイン時にデバイスのパスワードを変更しているはずです。それでも、Security Cloud Control を使用したデバイスの導入準備にzero-touch provisioning プロセスを使用できます。Secure Firewall Threat Defense にログイン後、デバイスのセットアップウィザードで、外部インターフェイスの設定ステップを完了しないでください。このステップを完了すると、デバイスはクラウドから登録解除され、zero-touch provisioning プロセスを使用できなくなります。

Secure Firewall Threat Defense にログインすると、ダッシュボードに次の画面が表示されます。

Secure Firewall Threat Defense UI では先に進まず、シリアル番号のオンボーディングウィザードに移動し、デバイスをオンボーディングしてください。ここでは、デバイスパスワードが変更されているため、[デフォルトパスワード変更済み（Default Password Changed）] を選択する必要があります。

前提条件

ソフトウェアおよびハードウェアの要件

FDM-managed デバイスは、シリアル番号による導入準備をサポートするソフトウェアを実行している必要があります。参考として次の表をご覧ください。

表 1. ハードウェアとソフトウェアのサポート
Zero-Touch Provisioningをサポートするファイアウォールモデル番号	サポート対象のファイアウォールソフトウェアバージョン	ソフトウェアパッケージ
Firepower 1000 シリーズデバイスモデル：1010、1120、1140、1150	6.7 以降	SF-F1K-TDx.x-K9
Firepower 2100 シリーズデバイスモデル：2110、2120、2130、2140	6.7 以降	SF-F2K-TDx.x-K9
Secure Firewall 3100 シリーズデバイスモデル：3110、3120、3130、3140	7.1 以降	SF-F3K-TDx.x-K9

管理プラットフォームが正しいバージョンを実行していることを確認します。

表 2. サポートされる FTD マネージャのバージョン
マネージャ	サポートされるバージョン
Secure Firewall Device Manager	7.0 以降
On-Premises Firewall Management Center	7.2 以降
Cloud-Delivered Firewall Management Center	N/A

ハードウェア設置に関する構成の前提条件

分散拠点のネットワークは 192.168.1.0/24 アドレス空間を使用できません。イーサネット 1/1（外部）上のネットワークは、192.168.1.0/24 アドレス空間を使用できません。FDM 6.7 を実行している 1000 および 2100 シリーズデバイスのイーサネット 1/2 「内部」インターフェイスのデフォルト IP アドレスは 192.168.1.1 であり、WAN モデムがそのサブネット上にある場合、WAN モデムによって割り当てられた DHCP アドレスと競合する可能性があります。
- 内部：イーサネット 1/2、IP アドレス 192.168.1.1
- 外部：イーサネット 1/1、DHCP からの IP アドレス、またはセットアップ時に指定したアドレス
外部インターフェイスの設定を変更できない場合は、Secure Firewall Device Manager を使用してイーサネット 1/2 の「内部」インターフェイス設定のサブネットを変更し、競合を回避します。たとえば、次のサブネット設定に変更できます。
- IP アドレス：192.168.95.1
- DHCP サーバーの範囲：192.168.95.5 ～ 192.168.95.254
物理インターフェイスの設定手順については、『Secure Firewall Device Manager Configuration Guide』[英語] を参照してください。「Interfaces」の章の「Configure a Physical Interface」を参照してください。
Firewall Threat Defense デバイスがインストールされ、Cisco Cloud に接続されている必要があります。

デバイスの外部インターフェイスまたは管理インターフェイスは、DHCP アドレッシングを提供するネットワークに接続する必要があります。通常、デバイスには外部インターフェイスまたは管理インターフェイスにデフォルトの DHCP クライアントがあります。

（注）

管理インターフェイスが DHCP サーバーを備えたネットワークに接続されている場合、Linux スタックによって開始されるトラフィックの外部インターフェイスよりも優先されます。

シリアルオンボーディング方法の次の Security Services Exchange ドメインにアクセスできるようにするには、外部または管理インターフェイスにアクセスする必要があります。
- オーストラリア地域
  - api.aus.sse.itd.cisco.com
  - est.sco.cisco.com（地理的に共通）
  - mx*.aus.sse.itd.cisco.com（現在は mx01.aus.sse.itd.cisco.com のみ）
  - dex.aus.sse.itd.cisco.com（カスタマーサクセス用）
  - eventing-ingest.aus.sse.itd.cisco.com（CTR および Security Cloud Control 用）
  - registration.aus.sse.itd.cisco.com（地域の Cisco Cloud へのデバイス登録が可能）
- APJ リージョン
  - api.apj.sse.itd.cisco.com
  - est.sco.cisco.com（地理的に共通）
  - mx*.apj.sse.itd.cisco.com（現在は mx01.apj.sse.itd.cisco.com のみ）
  - dex.apj.sse.itd.cisco.com（カスタマーサクセス用）
  - eventing-ingest.apj.sse.itd.cisco.com（CTR および Security Cloud Control 用）
  - registration.apj.sse.itd.cisco.com（リージョンの Cisco Cloud へのデバイス登録を可能にする）
- EU リージョン
  - api.eu.sse.itd.cisco.com
  - est.sco.cisco.com（地理的に共通）
  - mx*.eu.sse.itd.cisco.com（現在は mx01.eu.sse.itd.cisco.com のみ）
  - dex.eu.sse.itd.cisco.com（カスタマーサクセス用）
  - eventing-ingest.eu.sse.itd.cisco.com（CTR および Security Cloud Control 用）
  - registration.eu.sse.itd.cisco.com（地域の Cisco Cloud へのデバイス登録が可能）
- インド地域
  - api.in.sse.itd.cisco.com
  - est.sco.cisco.com（地理的に共通）
  - mx*.in.sse.itd.cisco.com（現在は mx01.in.sse.itd.cisco.com のみ）
  - dex.in.sse.itd.cisco.com（カスタマーサクセス用）
  - eventing-ingest.in.sse.itd.cisco.com（CTR および Security Cloud Control 用）
  - registration.in.sse.itd.cisco.com（地域の Cisco Cloud へのデバイス登録が可能）
- US リージョン
  - api sse.cisco.com
  - est.sco.cisco.com（地理的に共通）
  - mx*.sse.itd.cisco.com（現在は mx01.sse.itd.cisco.com のみ）
  - dex.sse.itd.cisco.com（カスタマーサクセス用）
  - eventing-ingest.sse.itd.cisco.com（CTR および Security Cloud Control 用）
  - registration.us.sse.itd.cisco.com（地域の Cisco Cloud へのデバイス登録が可能）
デバイスの外部インターフェイスから、Cisco Umbrella DNS に DNS アクセスできる必要があります。

Security Cloud Control でデバイスを要求する前に

Security Cloud Control でデバイスを要求する前に、次の情報があることを確認してください。

Firewall Threat Defense デバイスのシャーシのシリアル番号または PCA 番号。この情報は、ハードウェアシャーシの下部、またはデバイスが納品された段ボール箱に記載されています。次の図の例では、Firepower 1010 シャーシの下部にシリアル番号「*******X0R9」が表示されています。
デバイスのデフォルトのパスワード。
追加機能を使用するために Cisco Smart Software Manager から生成されたスマートライセンス。ただし、90 日間の評価ライセンスを使用してデバイスのオンボーディングを完了し、後にスマートライセンスを適用できます。

Zero-Touch Provisioning を使用した Secure Firewall Threat Defense デバイスの導入準備

注意	Security Cloud Control でデバイスの導入準備をしている場合は、Secure Firewall Device Manager を使用してデバイスの簡易セットアップを実行しないことをお勧めします。簡易セットアップを実行すると、Security Cloud Control でプロビジョニングエラーが発生します。

始める前に

Firewall Threat Defense デバイスは、以前または現在 Firewall Device Manager または Firewall Management Center によって管理されていてはなりません。デバイスが現在プラットフォームによって管理されている場合は、デバイスのシリアル番号を使用した構成済み FDM-Managed デバイスの導入準備を参照してください。
on-premises Firewall Management Center で管理するためにデバイスを導入準備する場合、on-premises Firewall Management Center はバージョン 7.4 以降を実行している必要があります。

手順

ステップ 1

外部ベンダーから購入したデバイスの導入準備をする場合は、まずデバイスを再イメージ化する必要があります。詳細については、『Cisco FXOS Troubleshooting Guide 』の「Reimage Procedures」の章を参照してください。[英語]

ステップ 2

Security Cloud Control にログインします。

ステップ 3

ナビゲーションウィンドウで、[セキュリティデバイス（Security Devices）] をクリックします。

ステップ 4

青色のプラスボタンをクリックして、デバイスをオンボードします。

ステップ 5

[FTD] タイルをクリックします。

重要	デバイスを導入準備しようとすると、Security Cloud Control では、エンドユーザーライセンス契約書（EULA）に目を通して同意するように求められます。これはテナントで 1 回限りのアクティビティです。この契約に同意すると、以降の導入準備で Security Cloud Control から再度プロンプトが表示されることはありません。EULA 契約に将来変更が生じた場合はプロンプトが表示され、再度同意する必要があります。

ステップ 6

[FTDデバイスの導入準備（Onboard FTD Device）] 画面で、[シリアル番号の使用（Use Serial Number）] をクリックします。

ステップ 7

[FMCの選択（Select FMC）] ステップで、ドロップダウンメニューを使用して、すでに Security Cloud Control にオンボーディングされている on-premises Firewall Management Center を選択します。[次へ（Next）] をクリックします。

on-premises Firewall Management Center はバージョン 7.4 以降を実行している必要があります。on-premises Firewall Management Center がオンボーディングされていない場合は、オンボーディングウィザードの [オンプレミスFMCをオンボーディング（+Onboard On-Prem FMC）] をクリックします。

ステップ 8

[接続（Connection）] ステップで、デバイスのシリアル番号とデバイス名を入力します。[次へ（Next）] をクリックします。

ステップ 9

zero-touch provisioning の場合、デバイスは新規であるか、再イメージ化されている必要があります。[パスワードのリセット（Password Reset）] では、[はい、この新しいデバイスはログインもマネージャの設定もされていません（Yes, this new device has never been logged into or configured for a manager）] を必ず選択してください。デバイスの新しいパスワードを入力し、[次へ（Next）] をクリックします。

ステップ 10

[ポリシー割り当て（Policy Assignment）] で、ドロップダウンメニューを使用して、デバイスの導入準備後に展開するアクセスコントロールポリシーを選択します。カスタマイズされたポリシーがない場合、Security Cloud Control では、デフォルトのアクセスコントロールポリシーが自動選択されます。[次へ（Next）] をクリックします。

ステップ 11

デバイスに適用するすべてのライセンスを選択します。[次へ（Next）] をクリックします。

ステップ 12

（オプション）デバイスにラベルを追加します。デバイスが正常に導入準備されると、Security Cloud Control によって、これらのラベルが適用されます。

次のタスク

Security Cloud Control がデバイスの要求を開始すると、右側に要求メッセージが表示されます。 Security Cloud Control が 1 時間継続してポーリングを行い、デバイスがオンラインであるか、およびクラウドに登録されているかどうかを判断します。クラウドに登録されると、Security Cloud Control は初期プロビジョニングを開始し、デバイスを正常に導入準備します。デバイスの LED ステータスが緑色に点滅することで、デバイスが登録されていることを確認できます。デバイスが Cisco Cloud に接続できない場合、または接続後に接続が失われた場合、ステータス LED（Firepower 1000）または SYS LED（Firepower 2100）が緑色とオレンジ色に交互に点滅しているのを確認できます。

最初の 1 時間以内にデバイスがクラウドに登録されない場合、タイムアウトが発生し、Security Cloud Control は 10 分ごとに定期的にポーリングしてデバイスのステータスを確認し、[要求中（Claiming）] の状態を維持します。デバイスの電源が入っていてクラウドに接続されている場合、オンボーディングステータスを把握するために 10 分間待つ必要はありません。[ステータスのチェック（Check Status）] リンクをクリックして、いつでもステータスを確認できます。Security Cloud Control は初期プロビジョニングを開始し、デバイスを正常に導入準備します。

重要

デバイスセットアップウィザードをすでに完了したと仮定すると（「Onboard an Already Configured FDM-Managed Device（すでに設定済みの FDM 管理対象デバイスの導入準備）」を参照）、デバイスはクラウドから登録解除され、この場合、Security Cloud Control は [要求中（Claiming）] 状態のままになります。Secure Firewall Device Manager を Security Cloud Control に追加するには、FDM から手動登録を完了する必要があります。（Secure Firewall Device Manager で、[システム設定（System Settings）] > [クラウドサービス（Cloud Services）] に移動し、[Security Cloud Controlからテナントへの自動登録（Auto-enroll with Tenancy from Cisco Defense Orchestrator）] オプションを選択して [登録（Register）] をクリックします。）次に、[ステータスの確認（Check Status）] をクリックします。

デバイスのシリアル番号を使用した構成済み FDM-Managed デバイスの導入準備

この手順は、すでにローカル管理用に構成されているデバイスが対象です。デバイスセットアップウィザードは設定済みの FDM-managed デバイスで完了するため、デバイスはクラウドから登録解除されます。zero-touch provisioning プロセスを使用して登録解除されたデバイスを Security Cloud Control に導入準備することはできません。

デバイスが新規であり、一度も管理または構成されていない場合は、zero-touch provisioning を使用してデバイスを導入準備できます。詳細については、「Zero-Touch Provisioning を使用した Secure Firewall Threat Defense デバイスの導入準備」を参照してください。

（注）

デバイスが Cisco Cloud に接続されていない場合、ステータス LED（Firepower 1000）、SYS LED（Firepower 2100）、または M LED（Secure Firewall 3100）が緑色とオレンジ色に交互に点滅しているのを確認できます。

次のタスクを実行するためにデバイスセットアップウィザードを完了している可能性があります。

デバイスはバージョン 6.7 以降を実行している必要があります。
デバイスの管理インターフェイスで静的 IP アドレスを設定します。インターフェイスが必要なダイナミック IP アドレスを取得できない場合、または DHCP サーバーでゲートウェイルートが提供されない場合は、静的 IP アドレスを設定する必要があります。
PPPoE を使用してアドレスを取得し、外部インターフェイスを設定します。
Secure Firewall Device Manager またはを使用して、バージョン 6.7 以降のデバイスを実行しているデバイスを管理します。

重要

Secure Firewall Threat Defense デバイスのマネージャを Secure Firewall Device Manager からに、またはその逆に切り替えできます。デバイスが実行しているバージョンの Cisco Firepower Threat Defense コンフィギュレーションガイド（Firepower Device Manager 用）[英語] の「System Management」の章にある「Switching Between Local and Remote Management」で説明されている手順を実行します。https://www.cisco.com/c/en/us/support/security/firepower-ngfw/products-installation-and-configuration-guides-list.html#anchor854

デバイスを導入準備する場合は、次の手順を実行します。

手順

ステップ 1	導入準備の前提条件を「Procedure for Onboarding FDM-Managed Device using Device Serial Number」 [英語] で確認します。
ステップ 2	Secure Firewall Device Manager UI で、[システム設定（System Settings）] > [クラウドサービス（Cloud Services）]に移動し、[Security Cloud Controlからテナントへの自動登録（Auto-enroll with Tenancy from Cisco Defense Orchestrator）] オプションを選択して [登録（Register）] をクリックします。
ステップ 3	Security Cloud Control にログインします。
ステップ 4	ナビゲーションウィンドウで、[セキュリティデバイス（Security Devices）] をクリックします。
ステップ 5	[FTD] タイルをクリックします。
ステップ 6	[FTDデバイスの導入準備（Onboard FTD Device）] 画面で、[シリアル番号の使用（Use Serial Number）] をクリックします。
ステップ 7	[FMCの選択（Select FMC）] ステップで、ドロップダウンメニューを使用して、すでに Security Cloud Control にオンボーディングされている on-premises Firewall Management Center を選択します。[次へ（Next）] をクリックします。 on-premises Firewall Management Center はバージョン 7.4 以降を実行している必要があります。on-premises Firewall Management Center がオンボーディングされていない場合は、オンボーディングウィザードの [オンプレミスFMCをオンボーディング（+Onboard On-Prem FMC）] をクリックします。
ステップ 8	[接続（Connection）] ステップで、デバイスのシリアル番号とデバイス名を入力します。[次へ（Next）] をクリックします。
ステップ 9	デバイスが新規ではなく、すでに管理用に構成されている場合は、[パスワードのリセット（Password Reset）] に [はい、この新しいデバイスはログインもマネージャの設定もされていません（Yes, this new device has never been logged into or configured for a manager）] を選択します。[次へ（Next）] をクリックします。
ステップ 10	[ポリシー割り当て（Policy Assignment）] で、ドロップダウンメニューを使用して、デバイスの導入準備後に展開するアクセスコントロールポリシーを選択します。カスタマイズされたポリシーがない場合、Security Cloud Control では、デフォルトのアクセスコントロールポリシーが自動選択されます。[次へ（Next）] をクリックします。
ステップ 11	デバイスに適用するすべてのライセンスを選択します。[次へ（Next）] をクリックします。

Security Cloud Control は、デバイスの [接続（Connectivity）] ステータスを [オンライン（Online）] に変更し、[設定（Configuration）] ステータスを [同期（Synced）] 状態に変更します。FDM-managed デバイスは Security Cloud Control に導入準備されています。ハードウェアの背面パネルでステータス LED（Firepower 1000）、SYS LED（Firepower 2100）、または M LED が緑色に点滅しているのを確認できます。デバイスが Cisco Cloud に接続されている場合、デバイスの LED は緑色で点滅し続けます。デバイスが Cisco Cloud に接続できない場合、または接続後に接続が失われた場合、同じステータス LED が緑色とオレンジ色に交互に点滅しているのを確認できます。

FDM-Managed ハイアベイラビリティペアの導入準備

Secure Firewall Threat Defense HA ペアを Security Cloud Control にオンボーディングするには、ペアの各デバイスを個別にオンボーディングする必要があります。ペアの両方のピアがオンボーディングされると、Security Cloud Control はそれらを [セキュリティデバイス（Seurity Devices）] ページの 1 つのエントリとして自動的に組み合わせます。ログイン情報または登録キーを使用してデバイスをオンボーディングします。両方のデバイスを同じ方法でオンボーディングすることをお勧めします。また、先にスタンバイモードのデバイスをオンボーディングすると、Security Cloud Control はそのデバイスの展開機能または読み取り機能を無効にすることに注意してください。HA ペア内のアクティブなデバイスに対してのみ読み取りまたは展開を実行できます。

（注）

Security Cloud Control は、登録キーを使用してデバイスをオンボーディングすることを強く推奨します。登録キーを使用したオンボーディングは、特定のバージョンを実行している Firewall Threat Defense デバイスでは若干異なります。詳細については、「バージョン 6.4 またはバージョン 6.5 を実行する FDM-Managed HA ペアのオンボーディング」と「Threat Defense バージョン 6.6 またはバージョン 6.7 以降を実行する FDM-Managed HA ペアのオンボーディング」を参照してください。

Firewall Threat Defense HA ペアを Security Cloud Control にオンボードする前に、以下を確認してください。

HA ペアは、Security Cloud Control にオンボーディングされる前にすでに形成されている。
両方のデバイスは正常な状態である。ペアは、プライマリ/アクティブモードとセカンダリ/スタンバイモード、またはプライマリ/スタンバイモードとセカンダリ/アクティブモードのいずれかである。異常なデバイスは、Security Cloud Control に正常に同期されない。
HA ペアは、ではなく Secure Firewall Device Manager によって管理されます。
Cloud Connector は https://security.cisco.com で Security Cloud Control に接続します。

登録キーを使用した FDM-Managed 高可用性ペアのオンボード

登録キーを使用して FDM-managed 高可用性（HA）ペアのオンボードを開始する前に、次の前提条件に注意してください。

バージョン 6.4 を実行しているデバイスの登録キーを使用したオンボードは、米国地域（https://security.cisco.com）でのみサポートされています。EU 地域（https://security.cisco.com）に接続するには、ユーザー名、パスワード、および IP アドレスを使用して HA ペアをオンボードする必要があります。
バージョン 6.5 以降を実行しており、US、EU、または APJ リージョンのいずれかに接続しているお客様は、登録キーを使用してオンボードできます。
バージョン 6.4 および 6.5 を実行しているデバイスは、登録キーを使用してデバイスをオンボーディングしてから、デバイスを Cisco Smart Software Manager に登録する必要があります。それらの FDM-managed デバイスを Security Cloud Control にオンボーディングする前に、デバイスのスマートライセンスを登録解除する必要があります。詳細については、「スマートライセンス取得済み FDM-Managed デバイスの登録解除」を参照してください。

バージョン 6.4 またはバージョン 6.5 を実行する FDM-Managed HA ペアのオンボーディング

ソフトウェアバージョン 6.4 または 6.5 を実行している FDM-managed HA ペアをオンボーディングするには、一度に 1 つずつデバイスをオンボーディングする必要があります。オンボーディングするデバイスがアクティブであるかスタンバイであるか、プライマリであるかセカンダリであるかは関係ありません。

（注）

登録キーを使用して HA ペアのいずれかのデバイスをオンボーディングする場合、もう一方のピアデバイスのオンボーディングにも同じ方法を使用する必要があります。

バージョン 6.4 または 6.5 を実行している HA ペアをオンボーディングするには、以下の手順に従ってください。

手順

ステップ 1

ピアデバイスをオンボーディングします。ペアの最初のデバイスをオンボードするには、登録キーを使用したソフトウェアバージョン 6.4 または 6.5 を実行する FDM-Managed デバイスの導入準備手順を参照してください。

ステップ 2

左側のペインで Security Devices をクリックします。

ステップ 3

[デバイス（Devices）] タブをクリックして、デバイスを見つけます。

ステップ 4

[FTD] タブをクリックします。デバイスが同期されたら、デバイスを選択してハイライトします。[デバイスの詳細（Devie Details）] のすぐ下にある操作ウィンドウで、[デバイスのオンボーディング（Onboard Device）] をクリックします。

ステップ 5

すでにオンボーディングされているピアデバイスの HA ピアデバイス名を入力します。[次へ（Next）] をクリックします。

ステップ 6

最初のデバイスのスマートライセンスを提示した場合、Security Cloud Control はそのライセンスを再入力して、このデバイスのオンボーディングに使用できるようにします。[次へ（Next）] をクリックします。

（注）

FDM-managed デバイスをオンボーディングするためにデバイスのスマートライセンスを登録解除した場合は、ここでスマートライセンスを再適用します。

ステップ 7

Security Cloud Control は、オンボーディングの準備をしているデバイスの登録キーを自動的に生成します。[コピー（Copy）] アイコンをクリックして登録キーをコピーします。

ステップ 8

オンボーディング中のデバイスの Secure Firewall Device Manager UI にログインします。

ステップ 9

[システム設定（System Settings）] で、[クラウドサービス（Cloud Services）] をクリックします。

ステップ 10

Security Cloud Control タイルで、[はじめに（Get Started）] をクリックします。

ステップ 11

[登録キー（Registration Key）] フィールドに、Security Cloud Control で生成した登録キーを貼り付けます。

ステップ 12

[リージョン（Region）] フィールドで、テナントが割り当てられている Cisco Cloud のリージョンを選択します。

（注）

この手順は、バージョン 6.4 を実行している FDM-managed デバイスには適用されません。

ステップ 13

[登録（Register）] をクリックし、[シスコの開示情報を受け入れる（Accept the Cisco Disclosure）] をクリックします。

ステップ 14

Security Cloud Control に戻り、[登録キーの作成（Create Registration Key）] 領域で [次へ（Next）] をクリックします。

ステップ 15

[セキュリティデバイスに移動（Go to Security Devices）] をクリックします。 Security Cloud Control は自動的にデバイスをオンボーディングし、それらを単一のエントリとして結合します。オンボーディングした最初のピアデバイスと同様に、デバイスのステータスは「プロビジョニング解除（Unprovisioned）」から「取得中（Locating）」、「同期中（Syncing）」、「同期済み（Synced）」に変わります。

Threat Defense バージョン 6.6 またはバージョン 6.7 以降を実行する FDM-Managed HA ペアのオンボーディング

Threat Defense バージョン 6.6 または 6.7 を実行している FDM-managed HA ペアをオンボーディングするには、一度に 1 つずつデバイスをオンボーディングする必要があります。オンボーディングするデバイスがアクティブであるかスタンバイであるか、プライマリであるかセカンダリであるかは関係ありません。

（注）

バージョン 6.6 または 6.7 を実行している HA ペアをオンボーディングするには、以下の手順に従ってください。

手順

ステップ 1

ピアデバイスをオンボーディングします。登録キーを使用したソフトウェアバージョン 6.6 以降を実行する FDM-Managed デバイスの導入準備を参照してください

ステップ 2

左側のペインで Security Devices をクリックします。

ステップ 3

[デバイス（Devices）] タブをクリックして、デバイスを見つけます。

ステップ 4

ステップ 5

すでにオンボーディングされているピアデバイスの HA ピアデバイス名を入力します。[次へ（Next）] をクリックします。

ステップ 6

ステップ 7

ステップ 8

Security Cloud Control にオンボードするデバイスの Secure Firewall Device Manager UI にログインします。

ステップ 9

[システム設定（System Settings）] で、[クラウドサービス（Cloud Services）] をクリックします。

ステップ 10

[登録タイプ（Enrollment Type）] 領域で、[セキュリティ/Security Cloud Controlアカウント（Security/CDO Account）] をクリックします。

（注）

バージョン 6.6 を実行しているデバイスの場合、Security Cloud Control の [テナンシー（Tenancy）] タブのタイトルは [セキュリティアカウント（Security Account）] であり、Secure Firewall Device Manager UI で Security Cloud Control を手動で有効にする必要があることに注意してください。

ステップ 11

[リージョン（Region）] フィールドで、テナントが割り当てられている Cisco Cloud のリージョンを選択します。

ステップ 12

[登録キー（Registration Key）] フィールドに、Security Cloud Control で生成した登録キーを貼り付けます。

ステップ 13

ステップ 14

ステップ 15

[登録（Register）] をクリックし、[シスコの開示情報を受け入れる（Accept the Cisco Disclosure）] をクリックします。FDM が Security Cloud Control に登録要求を送信します。

ステップ 16

Security Cloud Control に戻り、[登録キーの作成（Create Registration Key）] 領域で [次へ（Next）] をクリックします。

ステップ 17

[スマートライセンス（Smart License）] 領域で、スマートライセンスを FDM-managed デバイスに適用して [次へ（Next）] をクリックするか、[スキップ（Skip）] をクリックして、90 日間の評価ライセンスでオンボーディングを続行するか、デバイスがすでにスマートライセンスを取得している場合は、続行できます。詳細については、FTD デバイスの既存のスマートライセンスの更新を参照してください。

（注）

デバイスがバージョン 6.6 を実行している場合は、Security Cloud Control への通信を手動で有効にする必要があります。デバイスの FDM-managed UI から、[システム設定（System Settings）] > [クラウドサービス（Cloud Services）]に移動し、[Security Cloud Control] タイルで [有効化（Enable）] をクリックします。

ステップ 18

Security Cloud Control に戻り、[セキュリティデバイスに移動（Go to Security Devices）] をクリックします。Security Cloud Control は自動的にデバイスをオンボーディングし、それらを単一のエントリとして結合します。オンボーディングした最初のピアデバイスと同様に、デバイスのステータスは「プロビジョニング解除（Unprovisioned）」から「取得中（Locating）」、「同期中（Syncing）」、「同期済み（Synced）」に変わります。

FDM-Managed ハイアベイラビリティペアの導入準備

（注）

HA ペアの最初のデバイスをオンボーディングする方法が何であっても、もう一方のピアデバイスのオンボーディングにも同じ方法を使用する必要があります。

Security Cloud Control の外部で作成された FDM-managed HA ペアを導入準備するには、次の手順に従います。

手順

ステップ 1	HA ペア内のピアデバイスの片方をオンボードします。ユーザー名、登録キー、またはシリアル番号を使用してデバイスをオンボーディングします。
ステップ 2	デバイスが同期されたら、[セキュリティデバイス（Security Devices）] ページで [デバイス（Devices）] タブをクリックします。
ステップ 3	[FTD] タブをクリックします。
ステップ 4	デバイスを選択します。[デバイスの詳細（Devie Details）] のすぐ下にある操作ウィンドウで、[デバイスのオンボーディング（Onboard Device）] をクリックします。
ステップ 5	ポップアップウィンドウで、HA ピアのデバイス名と場所を入力します。
ステップ 6	[デバイスのオンボード（Onboard Device）] をクリックします。両方のデバイスが Security Cloud Control に正常に同期されると、HA ペアが単一のエンティティとして [セキュリティデバイス（Security Devices）] ページに表示されます。

FTD クラスタのオンボード

クラスタ化された Secure Firewall Threat Defense デバイスのオンボーディング

次の手順で、すでにクラスタ化されている Firewall Threat Defense デバイスをオンボーディングします。

始める前に

次のデバイスは、クラスタリングをサポートしています。

Secure Firewall 3100 デバイス
Firepower 4100 デバイス
Firepower 9300 デバイス
Firewall Threat Defense Virtual デバイス（AWS、Azure、VMware、KVM、GCP）

クラスタ化されたデバイスについては、次の制限事項に注意してください。

デバイスは、バージョン 6.4 以降を実行している必要があります。
デバイスは、物理または仮想 Secure Firewall Management Center により管理されている必要があります。
Firepower 4100 および Firepower 9300 デバイスは、デバイスのシャーシマネージャを介してクラスタ化する必要があります。
Secure Firewall 3100 デバイス、KVM、および VMware 環境は、Secure Firewall Management Center UI を使用してクラスタ化する必要があります。
Azure、AWS、および GCP 環境クラスタは、独自の環境を介して作成し、Secure Firewall Management Center にオンボーディングする必要があります。

手順

ステップ 1	Security Cloud Control にログインします。
ステップ 2	左側のペインで Security Devices をクリックします。
ステップ 3	青色のプラスボタンをクリックして、デバイスをオンボードします。
ステップ 4	[FTD] をクリックします。
ステップ 5	[管理モード] で、[FTD] が選択されていることを確認します。 [FTD] を選択すると、管理プラットフォームとして Cisco Secure Firewall Management Center が保持されます。[FDM] を選択すると、マネージャが Secure Firewall Management Center から Firewall Device Manager や Cloud-Delivered Firewall Management Center などのローカルマネージャに切り替わります。スイッチングマネージャは、インターフェイス設定を除くすべての既存のポリシー設定をリセットするため、デバイスのオンボーディング後にポリシーを再設定する必要があることに注意してください。
ステップ 6	[FTDデバイスのオンボーディング（Onboard FTD Device）] 画面で、[CLI登録キーを使用（Use CLI Registration Key）] をクリックします。
ステップ 7	[デバイス（Device Name）] フィールドにデバイス名を入力します。デバイスのホスト名またはその他の任意の名前にすることができます。
ステップ 8	[ポリシーの割り当て] ステップで、ドロップダウンメニューを使用して、デバイスの導入準備後に展開するアクセスコントロールポリシーを選択します。ポリシーが設定されていない場合は、[デフォルトのアクセスコントロールポリシー（Default Access Control Policy）] を選択します。
ステップ 9	オンボーディングするデバイスが物理デバイスか仮想デバイスかを指定します。仮想デバイスを導入準備している場合は、ドロップダウンメニューからデバイスのパフォーマンス階層を選択する必要があります。
ステップ 10	デバイスに適用する Essentials ライセンスを選択します。[次へ（Next）] をクリックします。
ステップ 11	Security Cloud Control が登録キーを使用してコマンドを生成します。登録キー全体をそのままデバイスの CLI に貼り付けます。
ステップ 12	デバイスのオンボーディングが開始されます。任意の手順として、[セキュリティデバイス（Security Devices）] ページの並べ替えとフィルタ処理に役立つラベルをデバイスに追加します。ラベルを入力し、青いプラスボタンを選択します。.

次のタスク

デバイスが同期されると、Security Cloud Control はデバイスがクラスタ化されていることを自動的に検出します。ここから、[セキュリティデバイス（Security Devices）] ページから導入準備したばかりのデバイスを選択し、右側にある [管理（Management）] ペインに一覧表示されているオプションのいずれかを選択します。次のアクションの実行を強く推奨します。

まだ作成していない場合、カスタムアクセスコントロールポリシーを作成して、環境のセキュリティをカスタマイズします。詳細については、FDM-Managed アクセスコントロールポリシーを参照してください。
Cisco Security Analytics and Logging（SAL）を有効にして、Security Cloud Control ダッシュボードでイベントを表示します。またはセキュリティ分析のためにデバイスを Secure Firewall Management Center に登録します。

スマートライセンスの適用または更新

FDM-Managed デバイスへの新しいスマートライセンスの適用

次のいずれかの手順を実行して、Firepower Threat Defense（FTD）デバイスのスマートライセンスを取得します。

登録キーを使用して導入準備するときに FDM-managed デバイスにスマートライセンスを付与します。
登録キーまたは管理者のログイン情報を使用してデバイスを導入準備した後、FDM-managed デバイスにスマートライセンスを付与します。

（注）

FDM-managed デバイスで 90 日間の評価ライセンスを使用しているか、ライセンスが登録解除されている可能性があります。

登録キーを使用してオンボードする場合の FDM-Managed デバイスのスマートライセンス付与

手順

ステップ 1	Cisco Smart Software Manager にログインして、新しいスマートライセンスキーを生成します。新しく生成したキーをコピーします。詳細については、スマートライセンスの生成に関するビデオをご覧ください。
ステップ 2	登録キーを使用して FDM-managed デバイスのオンボードを開始します。詳細については、「登録キーを使用したソフトウェアバージョン 6.6 以降を実行している FDM 管理対象デバイスのオンボード」または「登録キーを使用したソフトウェアバージョン 6.4 または 6.5 を実行している FDM 管理対象のオンボード」を参照してください。
ステップ 3	導入準備ウィザードのステップ 4 で、[スマートライセンス情報（Smart License here）] ボックス内の [アクティブ化（Activate）] フィールドにスマートライセンスを貼り付けて、[次へ（Next）] をクリックします。
ステップ 4	[Security Devices] をクリックします。
ステップ 5	[FTD] タブをクリックして、導入準備プロセスの進行状況を確認します。デバイスで同期が開始され、スマートライセンスが適用されます。デバイスがオンライン接続状態になったことを確認する必要があります。デバイスがオンライン接続状態にない場合は、右側の [デバイスアクション（Device Actions）] ペインで、[ライセンス管理（Manage Licenses）] > [ライセンスの更新（Refresh Licenses）]をクリックして、接続状態を更新します。
ステップ 6	スマートライセンスが FDM-managed デバイスに正常に適用されたら、[ライセンスの管理（Manage Licenses）] をクリックします。デバイスのステータスは [接続済み（Connected）]、[十分なライセンス（Sufficient License）] と表示されます。また、オプションライセンスを有効化または無効化できます。詳細については、「FDM-managed スマートライセンスのタイプ」を参照してください。

登録キーまたはログイン情報を使用したデバイスのオンボード後の FDM-Managed デバイスのスマートライセンス付与

手順

ステップ 1	左側のペインで Security Devices をクリックします。
ステップ 2	[デバイス（Devices）] タブをクリックしてデバイスを見つけます。
ステップ 3	[FTD] タブをクリックして、ライセンスを付与するデバイスを選択します。
ステップ 4	右側の [デバイスアクション（Device Actions）] ペインで、[ライセンスの管理（Manage Licenses）] をクリックします。
ステップ 5	画面の指示に従って Smart Software Manager で生成されたスマートライセンスを入力します。
ステップ 6	ボックスに新しいライセンスキーを貼り付け、[デバイスの登録（Register Device）] をクリックします。デバイスと同期すると、接続状態が「オンライン（Online）」に変わります。スマートライセンスが FDM-managed デバイスに正常に適用されると、デバイスのステータスに [接続済み（Connected）]、[十分なライセンス（Sufficient License）] と表示されます。また、オプションライセンスを有効化または無効化できます。詳細については、「FDM-managed スマートライセンスのタイプ」を参照してください。

FTD デバイスの既存のスマートライセンスの更新

スマートライセンスが適用された FTD デバイスに、新しいスマートライセンスを適用できます。デバイスのオンボーディングで選択した方法に基づいて、適切な手順を選択します。

登録キーを使用してオンボードした FDM-Managed デバイスに適用されているスマートライセンスの変更

手順

ステップ 1	Security Cloud Control から対応する FDM-managed デバイスを削除します。
ステップ 2	当該デバイスの Secure Firewall Device Manager にログインし、スマートライセンスを登録解除します。詳細については、「スマートライセンス取得済み FDM-Managed デバイスの登録解除」を参照してください。
ステップ 3	Security Cloud Control で、登録キーを使用して FDM-managed デバイスを再度オンボードします。詳細については、「登録キーを使用した FDM 管理対象デバイスのオンボード」を参照してください。
ステップ 4	[デバイス（Devices）] タブをクリックしてデバイスを見つけます。
ステップ 5	タブをクリックします。
ステップ 6	新しいスマートライセンスの適用は導入準備プロセス中に行うか、または右側の [デバイスアクション（Device Actions）] ペインで [ライセンス管理（Manage Licenses）] をクリックします。

ログイン情報を使用してオンボードした FDM-Managed デバイスに適用されているスマートライセンスの変更

手順

ステップ 1	当該デバイスの Secure Firewall Device Manager にログインし、スマートライセンスを登録解除します。詳細については、「登録キーを使用した FDM 管理対象デバイスのオンボード」を参照してください。
ステップ 2	Secure Firewall Device Manager の FDM-managed デバイスに新しいスマートライセンスを適用します。 [スマートライセンス（Smart License）] 領域で、 [設定の表示（View Configuration）] をクリックします。 [今すぐ登録（Register Now）] をクリックして、画面上の指示に従います。
ステップ 3	左側のペインで、Security Cloud Control の Security Devices ページをクリックした後、[Devices] タブをクリックします。
ステップ 4	FTD デバイスをクリックします。FDM-managed デバイス設定の変更内容を確認します。Security Cloud Control により FDM-managed デバイスの展開された設定のコピーが作成され、Security Cloud Control データベースに保存されます。詳細については、「設定変更の読み取り、破棄、チェック、および展開」を参照してください。

FDM-Managed デバイスの DHCP アドレス指定に関する Security Cloud Control サポート

FDM-managed デバイスで使用されている IP アドレスが変更されるとどうなりますか。

適応型セキュリティアプライアンス（ASA）や FDM-managed デバイスを使用する Security Cloud Control のお客様の多くは、DHCP を介してサービスプロバイダーから提供される IP アドレスを使用してデバイスをオンボードします。

デバイスの IP アドレスが何らかの理由で変更された場合、静的 IP アドレスの変更であるか、DHCP による IP アドレスの変更であるかにかかわらず、Security Cloud Control がデバイスへの接続に使用する IP アドレスを変更して、デバイスを再接続できます。

分散拠点に展開されている FDM-managed デバイスを Security Cloud Control によって管理することについて、開発現場では懸念の声が上がっています。FDM-managed デバイスの外部インターフェイスには静的 IP が必要で、一部の SE は、FDM-managed デバイスで外部インターフェイスに DHCP アドレスが設定されている場合、Security Cloud Control は管理ソリューションとして使用できないと考えています。

ただし、この状況は、リモートブランチファイアウォールへの VPN トンネルを使用しているお客様には影響しません。また、お客様の大多数が、分散拠点からデータセンターへのサイト間トンネルを使用していることがわかっています。サイト間 VPN を使用してデバイスからセントラルサイトに接続する場合、外部インターフェイスの DHCP は関係ありません。Security Cloud Control（および任意の管理プラットフォーム）は内部の静的アドレスが指定されたインターフェイスを介して（そのように設定されている場合） FW に接続できます。これは推奨される方法であり、デバイス数が多い（1,000 超）Security Cloud Control のお客様は、この展開モードを使用しています。

また、インターフェイスの IP アドレスが DHCP 経由で発行されている場合でも、お客様がその IP を使用してデバイスを管理することの妨げにはなりません。繰り返しますが、これは最適な方法ではありませんが、Security Cloud Control で IP アドレスを定期的に変更する必要があっても、お客様の不利益にはなりません。この状況は Security Cloud Control に限ったものではなく、ASDM、FDM、または SSH などの外部インターフェイスを使用するすべてのマネージャで発生します。

FDM-Managed デバイスのライセンスタイプ

スマートライセンスのタイプ

次の表に、FDM-managed デバイスで使用可能なライセンスを示します。

FDM-managed デバイスを購入すると、自動的に基本ライセンスが含まれます。すべての追加ライセンスはオプションです。


ライセンス	期間	付与される機能
ライセンス（自動的に含まれます）	永続	サブスクリプションタームライセンスでカバーされないすべての機能。 [このトークンに登録した製品でエクスポート制御機能を許可する（Allow export-controlled functionality on the products registered with this token）] かどうかも指定する必要があります。このオプションは、自国が輸出管理の標準規格に適合している場合のみ選択できます。このオプションは、高度な暗号化や、高度な暗号化を必要とする機能の使用を制御します。
	タームベース	侵入検知および防御：侵入ポリシーが侵入とエクスプロイトを検出するためネットワークトラフィックを分析し、またオプションで違反パケットをドロップします。ファイル制御：ファイルポリシーが特定タイプのファイルを検出し、オプションでこれらのファイルのアップロード（送信）またはダウンロード（受信）をブロックできます。マルウェアライセンスが必要な AMP for Firepower を使用すると、マルウェアを含むファイルのインスペクションを実行してブロックできます。任意のタイプのファイルポリシーを使用するには、ライセンスが必要です。セキュリティインテリジェンスフィルタ：トラフィックがアクセスコントロールルールによって分析を受ける前に、選択されたトラフィックをドロップします。ダイナミックフィードを使用することで、最新のインテリジェンスに基づいて接続をただちにドロップできます。
マルウェア	タームベース	マルウェアを確認するポリシーであり、Cisco Advanced Malware Protection（AMP）と一緒に AMP for Firepower （ネットワークベースの高度なマルウェア保護）と Cisco Threat Grid を使用します。ファイルポリシーは、ネットワーク上で伝送されるファイルに存在するマルウェアを検出してブロックできます。
URL ライセンス	タームベース	カテゴリとレピュテーションに基づく URL フィルタリング。このライセンスなしでも、個々の URL で URL フィルタリングを実行できます。
	ライセンスタイプに基づきタームベースまたは永久	リモートアクセス VPN の設定RA VPN を設定するには、Essentials ライセンスによるエクスポート制御機能を許可する必要があります。デバイスを登録するときに、エクスポート要件を満たすかどうかを選択します。 Firepower Device Manager は、AnyConnect の任意の有効なライセンスを使用できます。使用可能な機能は、ライセンスタイプによる違いはありません。まだライセンスを購入していない場合は、「リモートアクセス VPN のライセンス要件」を参照してください。『Cisco AnyConnect 発注ガイド』（ http://www.cisco.com/c/dam/en/us/products/collateral/security/anyconnect-og.pdf）も参照してください。

仮想 FDM-Managed デバイスの階層型ライセンス

バージョン 7.0 では、スループット要件と RA VPN セッションの制限に基づいて、仮想 FDM-Managed デバイスのパフォーマンス階層型のスマートライセンスのサポートが導入されています。使用可能なパフォーマンスライセンスのいずれかを使用して仮想 FDM-Managed デバイスのライセンスが付与されると、次の 2 つのことが発生します。インストールされている仮想 FDM-Managed デバイスプラットフォームのエンタイトルメント層によって RA VPN のセッション制限が決定され、レートリミッタを介して適用されます。

現時点では、Security Cloud Control は階層型スマートライセンスを完全にはサポートしていません。次の制限事項を参照してください。

階層型ライセンスは Security Cloud Control を使用して変更できません。Secure Firewall Device Manager UI で変更する必要があります。
Cloud-Delivered Firewall Management Center によって管理されるように仮想 FDM-Managed デバイスを登録すると、階層型ライセンスの選択が自動的にデフォルト階層の [変数（Variable）] にリセットされます。
バージョン 7.0 以降を実行している仮想 FDM-Managed デバイスをオンボードし、オンボードプロセス中にデフォルトライセンスではないライセンスを選択すると、階層型ライセンスの選択は、デフォルト階層の [変数（Variable）] に自動的にリセットされます。

上記の問題を回避するために、デバイスのオンボード後に仮想 FDM-Managed デバイスライセンスの階層を選択することを強く推奨します。詳細については、「スマートライセンスの管理」を参照してください。

デバイスのスマートライセンスの表示

手順

ステップ 1	左側のペインで Security Devices をクリックします。
ステップ 2	[デバイス（Devices）] タブをクリックして、デバイスを見つけます。
ステップ 3	[FTD] タブをクリックします。
ステップ 4	FDM-managed デバイスを選択して、現在のライセンスステータスを表示します。
ステップ 5	右側の [デバイスアクション（Device Actions）] ペインで、[ライセンスの管理（Manage Licenses）] をクリックします。[ライセンスの管理] 画面には、次の情報が表示されます。 [スマートライセンスエージェントのステータス（Smart License Agent status）]：90 日間の評価ライセンスを使用しているかどうか、または Cisco Smart Software Manager に登録済みかどうかが表示されます。スマートライセンスエージェントのステータスは次のとおりです。 [接続済み（Connected）]、[十分なライセンス（Sufficient Licenses）]：デバイスは認証局に正しく登録され、アプライアンスのソフトウェア利用資格が承認されています。このデバイスはインコンプライアンスの状態です。 [コンプライアンス違反（Out-of-Compliance）]：デバイスで使用可能なソフトウェア利用資格がありません。ライセンスされた機能は動作を継続します。ただし、コンプライアンスに遵守するためには、追加の権限を購入するか、権限を解放する必要があります。 [認証期限切れ（Authorization Expired）]：デバイスは 90 日以上ライセンス認証局と通信していません。ライセンスされた機能は動作を継続します。この状態の場合、スマートライセンスエージェントは認証要求を再試行します。再試行に成功すると、エージェントは [コンプライアンス違反（Out-of-Compliance）] または [認証済み（Authorized）] 状態に切り替わり、新しい認証期間が開始されます。手動でデバイスの同期を試します。 [ライセンス登録（License Registration）]：オンボードされている FDM-managed デバイスにスマートライセンスを適用できます。登録が完了すると、Cisco Smart Software Manager への接続のステータス、および各ライセンスタイプのステータスを確認できます。 [ライセンスステータス（License Status）]：FDM-managed デバイスで使用可能なオプションライセンスのステータスが表示されます。ライセンスを有効にすると、ライセンスによって制御される機能を使用できます。

オプションライセンスの有効化と無効化

90 日間の評価ライセンスまたはフルライセンスを使用している FDM-managed デバイスでオプションライセンスを有効化（登録）できます。ライセンスによって制御される機能を使用するには、ライセンスを有効にする必要があります。

オプションのタームライセンスの対象となる機能を使用しなくなった場合、ライセンスを無効化（解除）できます。ライセンスを無効にすると、Cisco Smart Software Manager アカウントでライセンスが解除されるため、別のデバイスにそのライセンスを適用できるようになります。

評価モードでは、オプションライセンスの評価版を有効にして、すべての操作を実行することもできます。このモードでは、デバイスを登録するまでライセンスは Cisco Smart Software Manager に登録されません。

（注）

評価モードではライセンスは有効にできません。

始める前に

ライセンスを無効にする前に、そのライセンスが使用中でないことを確認します。ライセンスを必要とするポリシーは書き換えるか削除します。

高可用性の設定で動作する装置の場合は、アクティブな装置でのみライセンスを有効化または無効化します。スタンバイ装置が必要なライセンスを要求（または解放）すると、次の設定の展開時にスタンバイ装置に変更内容が反映されます。ライセンスを有効にする際は、Cisco Smart Software Manager アカウントで十分な数のライセンスが使用可能であることを確認する必要があります。これを確認しないと、一方の装置が準拠、もう一方の装置が非準拠になる可能性があります。

オプションライセンスを有効または無効にするには、次の手順を実行します。

手順

ステップ 1

[Security Devices] ページで、必要な FDM-managed デバイスを選択し、[Device Actions] ペインで [Manage Licenses] をクリックすると [Manage Licenses] 画面が表示されます。

ステップ 2

それぞれのオプションライセンスのスライダコントロールをクリックして、ライセンスを有効または無効にします。有効になっている場合、ライセンスのステータスには [OK] と表示されます。

[有効化（Enable）]：Cisco Smart Software Manager アカウントにライセンスを登録し、制御された機能が有効になります。ライセンスによって制御されるポリシーを設定し、展開できます。
[無効化（Disable）]：Cisco Smart Software Manager アカウントのライセンスを登録解除し、制御された機能が無効になります。新しいポリシーの機能の設定も、その機能を使用するポリシーの展開もできません。

ステップ 3

[保存（Save）] をクリックして、変更内容を保存します。

期限切れまたは無効なオプションライセンスの影響

オプションのライセンスが期限切れになっても、そのライセンスを必要とする機能を使用し続けることはできます。ただし、ライセンスは非準拠とマークされます。ライセンスを準拠状態に戻すには、ライセンスを購入してアカウントに追加する必要があります。

オプションのライセンスを無効にすると、システムは次のように反応します。

[マルウェア防御ライセンス（Malware Defense license）]：システムは AMP クラウドへの問い合わせを停止し、AMP クラウドから送信されたレトロスペクティブイベントの認証も停止します。既存のアクセスコントロールポリシーにマルウェア検出を適応するファイルポリシーが含まれている場合、このアクセスコントロールポリシーを再展開することはできません。[マルウェア防御ライセンス（Malware Defense license）] が無効にされた後、システムが既存のキャッシュファイルの性質を使用できるのはごく短時間です。この時間枠の経過後、システムは Unavailable という性質をこれらのファイルに割り当てます。
[IPS]：システムは侵入またはファイル制御ポリシーを適用しなくなります。セキュリティインテリジェンスポリシーの場合、システムはこのポリシーを適用せず、フィード更新のダウンロードを停止します。ライセンスを必要とする既存のポリシーを再展開することはできません。
[URL]：URL カテゴリ条件が指定されたアクセス制御ルールは URL のフィルタリングをただちに停止し、システムは URL データへの更新をダウンロードしなくなります。既存のアクセスコントロールポリシーに、カテゴリベースまたはレピュテーションベースの URL 条件を含むルールが含まれている場合は、それらのポリシーを再展開することができません。
[Cisco Secure Client]：リモートアクセス VPN 設定は編集できませんが、削除は可能です。ユーザーは引き続き RA VPN 設定を使用して接続できます。ただし、デバイスの登録を変更してシステムがエクスポートに準拠しなくなると、リモートアクセス VPN 設定はただちに停止し、リモートユーザーは VPN に接続できなくなります。

Firewall Device Manager モデルの作成とインポート

Security Cloud Control では、Security Cloud Control テナントにある FDM-managed デバイスの完全な設定を JSON ファイル形式でエクスポートできます。エクスポートしたファイルは、Firewall Device Manager モデルとして別のテナントにインポートし、そのテナントの新しいデバイスに適用できます。この機能は、管理対象のさまざまなテナントで FDM-managed デバイスの設定を使用する際に役立ちます。

（注）

FDM-managed デバイスにルールセットが存在する場合、設定をエクスポートする際、そのルールセットに関連付けられている共有ルールはローカルルールとして変更されます。その後、モデルが別のテナントにインポートされ、FDM-managed デバイスに適用されると、デバイスにローカルルールが表示されます。

FDM-Managed デバイス設定のエクスポート

FDM-managed デバイスに次の設定がある場合、エクスポート設定機能は使用できません。

高可用性
Snort 3 の有効化

手順

ステップ 1	左側のペインで、[セキュリティデバイス（Security Devices）] をクリックします。
ステップ 2	[デバイス（Devices）] タブをクリックしてデバイスを見つけるか、[テンプレート（Templates）] タブをクリックしてモデルデバイスを見つけます。
ステップ 3	[FTD] タブをクリックします。
ステップ 4	FDM-managed デバイスを選択し、右側の [デバイスアクション（Device Actions）] ペインで [設定のエクスポート（Export Configuration）] をクリックします。

FDM-Managed デバイス設定のインポート

手順

ステップ 1

[Security Devices] ページで青いプラス（）ボタンをクリックして設定をインポートします。

ステップ 2

[インポート（Import）] をクリックして、オフライン管理用に設定をインポートします。

ステップ 3

[デバイスタイプ（Device Type）] として [FTD] を選択します。

ステップ 4

[参照（Browse）] をクリックし、アップロードする設定ファイル（JSON 形式）を選択します。

ステップ 5

設定が確認されると、デバイスまたはサービスにラベルを設定するよう求められます。詳細については、『Labels and Label Groups』を参照してください。

ステップ 6

モデルデバイスにラベルを設定すると、[セキュリティデバイス（Security Devices）] リストでラベルを確認できます。

（注）

設定のサイズ、および他のデバイスまたはサービスの数によっては、設定の分析に時間がかかる場合があります

FDM-Managed デバイスのバックアップ

Security Cloud Control を使用して FDM-managed デバイスのシステム設定をバックアップし、デバイスを以前の状態に復元することができます。バックアップには設定だけが含まれ、システムソフトウェアは含まれません。デバイスを完全に再イメージ化する必要がある場合、ソフトウェアを再インストールしてからバックアップをアップロードして、設定を回復する必要があります。Security Cloud Control は、デバイスに対して作成された最新の 5 つのバックアップを保存します。新しいバックアップが作成されると、最新のバックアップを保存するために、最も古いバックアップが削除されます。

（注）

バックアップには管理 IP アドレスの設定は含まれません。したがって、バックアップファイルを復元しても、管理アドレスがバックアップコピーにより置き換えられることはありません。これにより、アドレスに対する変更はすべて保持され、また異なるネットワークセグメント上の別のデバイスに設定を復元することもできます。

バックアップ中は設定データベースがロックされます。バックアップの間はポリシー、ダッシュボードなどを表示できますが、設定を変更することはできません。復元を行っている間、システムは完全に使用できません。

デバイス間でバックアップスケジュールの一貫性を保つために、独自のデフォルトのバックアップスケジュールを設定できます。特定のデバイスのバックアップをスケジュールする場合、独自のデフォルト設定を使用するか、設定を変更することができます。毎日から月に一度の頻度で定期的なバックアップをスケジュールでき、オンデマンドバックアップを実行できます。バックアップをダウンロードし、Firewall Threat Defense デバイスマネージャを使用してバックアップを復元することもできます。

Security Cloud Control を使用して FDM-managed デバイスをバックアップおよび復元するための要件とベストプラクティス

Security Cloud Control は、ソフトウェアバージョン 6.5 以降を実行している FDM-managed デバイスをバックアップできます。
FDM-managed デバイスは、登録キーを使用して Security Cloud Control にオンボードされる必要があります。
交換用デバイスにバックアップを復元できるのは、2 つのデバイスが同じモデルであり、同じリリースというだけでなく、同じバージョンのソフトウェア（ビルド番号を含む）を実行している場合のみです。たとえば、ソフトウェアバージョン 6.6.0-90 を実行している FDM-managed デバイスのバックアップは、6.6.0-90 を実行している FDM-managed デバイスにのみ復元できます。アプライアンス間で設定をコピーするためにバックアップおよび復元プロセスを使用しないでください。バックアップファイルには、この方法で共有することができないようにアプライアンスを一意に特定する情報が含まれます。
Secure Firewall Threat Defense バックアップ機能が Security Cloud Control で動作するには、Firewall Threat Defense がテナントリージョンに基づいてこれらの Security Cloud Control URL のいずれかにアクセスする必要があります。
- edge.apj.cdo.cisco.com
- edge.aus.cdo.cisco.com
- edge.eu.cdo.cisco.com
- edge.in.cdo.cisco.com
- edge.us.cdo.cisco.com
ポート 443 に HTTPS プロトコルの外部およびアウトバウンドアクセスがあることを確認します。ポートがファイアウォールの背後でブロックされている場合、バックアップと復元のプロセスが失敗する可能性があります。

ベストプラクティス

バックアップしようとしているデバイスは、Security Cloud Control で同期状態である必要があります。Security Cloud Control はデバイスの設定を、Security Cloud Control ではなくデバイスからバックアップします。したがって、デバイスが [非同期（Not Synced）] 状態の場合、Security Cloud Control での変更はバックアップされません。デバイスが [競合検出（Conflict Detected）] 状態の場合、変更はバックアップされます。

FDM-Managed デバイスをオンデマンドでバックアップする

この手順では、必要に応じて復元できるように FDM-managed デバイスをバックアップする方法について説明します。

はじめる前に

FDM-managed デバイスをバックアップする前に、要件とベストプラクティスを参照してください。

手順

ステップ 1	（任意）バックアップの変更要求を作成します。
ステップ 2	左側のペインで Security Devices をクリックします。
ステップ 3	[デバイス] タブをクリックします。
ステップ 4	[FTD] タブをクリックして、バックアップするデバイスを選択します。
ステップ 5	右側の [デバイスアクション（Device Actions）] ウィンドウで、[バックアップの管理（Manage Backups）] をクリックします。
ステップ 6	[すぐにバックアップ（Backup Now）] をクリックします。デバイスはバックアップ構成の状態になります。バックアップが完了すると、Security Cloud Control ではバックアップ開始前のデバイス構成の状態が表示されます。変更ログページを開くと、「バックアップが正常に完了しました」という説明が付けられた直近の変更ログレコードが見つかります。ステップ 1 で変更要求を作成した場合は、変更要求の値でフィルタ処理して、変更ログエントリを見つけることもできます。
ステップ 7	ステップ 1 で変更要求を作成した場合は、変更要求の値をクリアして、誤って別の変更をその変更要求に関連付けないようにします。

単一 FDM-Managed デバイスの定期バックアップスケジュールの設定

はじめる前に

FDM-managed デバイスをバックアップする前に、要件とベストプラクティスを参照してください。

手順

ステップ 1	左側のペインで Security Devices をクリックします。
ステップ 2	[デバイス] タブをクリックします。
ステップ 3	[FTD] タブをクリックして、バックアップするデバイスを選択します。
ステップ 4	右側の [デバイスアクション（Device Actions）] ウィンドウで、[バックアップの管理（Manage Backups）] をクリックします。
ステップ 5	[デバイスのバックアップ（Device Backups）] ページで、[定期バックアップの設定（Set Recurring Backup）] をクリックするか、[定期バックアップ（Recurring Backup）] フィールドのスケジュールをクリックします。Security Cloud Control では、テナントにあるすべての FDM-managed デバイスに対してデフォルトのバックアップスケジュールが提示されます。詳細については、「すべての FDM 管理対象デバイスのデフォルトの定期バックアップスケジュールの設定」を参照してください。
ステップ 6	バックアップを実行する時間を 24 時間制で選択します。協定世界時（UTC）でバックアップ時間をスケジュールすることに注意してください。
ステップ 7	[頻度（Frequency）] フィールドで、 [日次（Daily）]、[週次（Weekly）]、または [月次（Monthly）] を選択します。日次バックアップの場合：スケジュールしたバックアップに名前と説明を付けます。週次バックアップの場合：バックアップを実行する曜日のチェックボックスをオンにします。スケジュールしたバックアップの時間に名前と説明を付けます。月次バックアップの場合：[日付（Days of Month）] フィールドをクリックして、バックアップをスケジュールする日付を追加します。注：31 日を入力しても、その月に 31 日が含まれていない場合、バックアップは行われません。スケジュールしたバックアップの時間に名前と説明を付けます。
ステップ 8	[保存（Save）] をクリックします。[バックアップデバイス（Backup Device）] ページの [定期バックアップ（Recurring Backup）] フィールドは、設定したバックアップスケジュールに置き換えられ、現地時間が反映されます。

デバイスのバックアップのダウンロード

この手順では、FDM-managed デバイスのバックアップを含む .tar ファイルをダウンロードする方法を説明します。

手順

ステップ 1

ナビゲーションバーで、Security Devices を選択します。

ステップ 2

[デバイス] タブをクリックします。

ステップ 3

[FTD] タブをクリックし、バックアップをダウンロードするデバイスをクリックします。

ステップ 4

右側の操作ウィンドウで、[バックアップの管理（Manage Backups）] をクリックします。

ステップ 5

ダウンロードするバックアップを選択し、その行で [ダウンロードリンクを生成（Generate Download Link）] ボタンをクリックします。ボタンが [バックアップイメージのダウンロード（Download Backup Image）] に変わります。

ステップ 6

[バックアップイメージのダウンロード（Download Backup Image）] というボタンが表示されたら、次のいずれかの操作を実行します。

復元するデバイスの Firewall Device Manager にもアクセスできるデバイスを使用している場合は、[Download Backup Image] ボタンをクリックして、ダウンロードしたファイルを保存します。覚えやすい名前で保存してください。

復元するデバイスの FDM にもアクセスできるデバイスを使用していない場合は以下を実行します。

[バックアップイメージのダウンロード（Download Backup Image）] ボタンを右クリックし、リンクのアドレスをコピーします。

重要	リンクのアドレスは、[ダウンロードリンクの生成（Generate Download Link）] ボタンをクリックしてから 15 分後に期限切れになります。

イメージを復元する Secure Firewall Threat Defense の Firewall Device Manager にもアクセスするデバイスでブラウザを開きます。
ブラウザのアドレスバーにダウンロードリンクを入力し、バックアップファイルをそのデバイスにダウンロードします。覚えやすい名前で保存してください。

バックアップの編集

この手順では、成功した FDM-managed デバイスのダウンロードの名前または説明を編集できます。

手順

ステップ 1	左側のペインで Security Devices をクリックします。
ステップ 2	[デバイス] タブをクリックします。
ステップ 3	[FTD] タブをクリックして、編集するデバイスを選択します。
ステップ 4	右側の [操作（Actions）] ウィンドウで、[バックアップの管理（Manage Backups）] をクリックします。
ステップ 5	編集するバックアップとその行を選択し、編集アイコンをクリックします。
ステップ 6	バックアップの名前または説明を変更します。[デバイスのバックアップ（Device Backups）] ページで新しい情報を確認できます。

バックアップの削除

Security Cloud Control は、デバイスに対して作成された最新の 5 つのバックアップを保存します。新しいバックアップが作成されると、最新のバックアップを保存するために、最も古いバックアップが削除されます。既存のバックアップを削除すると、保持するバックアップと削除するバックアップの管理に役立つ場合があります。

手順

ステップ 1	左側のペインで Security Devices をクリックします。
ステップ 2	[デバイス] タブをクリックします。
ステップ 3	[FTD] タブをクリックして、削除するデバイスを選択します。
ステップ 4	右側の [操作（Actions）] ウィンドウで、[バックアップの管理（Manage Backups）] をクリックします。
ステップ 5	削除するバックアップとその行を選択し、ゴミ箱アイコンをクリックします。
ステップ 6	[OK] をクリックして確定します。

デバイスバックアップの管理

Security Cloud Control を使用して作成した FDM-managed デバイスのバックアップは、[デバイスのバックアップ（Device Backups）] ページに表示されます。

手順

ステップ 1	左側のペインで、[セキュリティデバイス（Security Devices）] をクリックします。
ステップ 2	[デバイス] タブをクリックします。
ステップ 3	[FTD] タブをクリックします。
ステップ 4	フィルタアイコンをクリックし、[デバイス/サービス（Devices/Services）] の [FDM] をオンにして、デバイステーブルに FDM-managed デバイスのみを表示します。
ステップ 5	必要なデバイスを選択します。
ステップ 6	[デバイスアクション（Device Actions）] ペインで、[バックアップの管理（Manage Backups）] をクリックします。そのデバイスから作成された最新のバックアップが最大 5 つ表示されます。

次のタスク

バックアップを復元する場合は、FDM-Managed デバイスへのバックアップの復元を参照してください。

FDM-Managed デバイスへのバックアップの復元

FDM-managed 管理対象 Firewall Threat Defense デバイスのバックアップを復元する前に、この情報を確認してください。

バックアップを FDM-managed Firewall Threat Defense デバイスに復元する前に、要件とベストプラクティスを確認してください。
復元するバックアップコピーがまだデバイスに存在しない場合、復元する前にまずバックアップをアップロードする必要があります。
復元している間、システムはまったく使用できません。バックアップが復元された後、デバイスが再起動します。
この手順では、デバイスに復元する準備ができているデバイスの既存のバックアップがあることを前提としています。
このデバイスがハイアベイラビリティペアの一部である場合、バックアップは復元できません。まず、[デバイス（Device）] > [ハイアベイラビリティ（High Availability）] ページから HA を無効化することで、バックアップを復元できます。バックアップに HA の設定が含まれている場合、デバイスは HA グループに再度参加します。両方のユニットで同じバックアップを復元しないでください（両方のユニットがアクティブになってしまうため）。代わりに、まず、アクティブにする装置でバックアップを復元し、その後に、別のユニットで同等のバックアップを復元してください。

（注）

手順

ステップ 1

左側のペインで Security Devices をクリックします。

ステップ 2

[デバイス] タブをクリックします。

ステップ 3

[FTD] タブをクリックして、復元するデバイスを選択します。

ステップ 4

右側の [デバイスアクション（Device Actions）] ウィンドウで、[バックアップの管理（Manage Backups）] をクリックします。

ステップ 5

復元するバックアップを選択します。その行で、[ダウンロードリンクの生成（Generate Download Link）] ボタンをクリックします。

（注）

リンクのアドレスは、[ダウンロードリンクの生成（Generate Download Link）] ボタンをクリックしてから 15 分後に期限切れになります。

ステップ 6

[バックアップイメージのダウンロード（Download Backup Image）] というボタンが表示されたら、次のいずれかの操作を実行します。

復元するデバイスの Firewall Device Manager にもアクセスできるデバイスを使用している場合は、[バックアップイメージのダウンロード（Download Backup Image）] ボタンをクリックして、ダウンロードしたファイルを保存します。覚えやすい名前で保存してください。
復元するデバイスの Firewall Device Manager にもアクセスできるデバイスを使用していない場合は以下を実行します。
1. [バックアップイメージのダウンロード（Download Backup Image）] ボタンを右クリックし、リンクのアドレスをコピーします。
2. イメージを復元する Firewall Device Manager にもアクセスするデバイスでブラウザを開きます。
3. ブラウザのアドレスバーにダウンロードリンクを入力し、バックアップファイルをそのデバイスにダウンロードします。覚えやすい名前で保存してください。

ステップ 7

復元するデバイスの Firewall Device Manager にログインします。

ステップ 8

『Cisco Firepower Threat Defense コンフィギュレーションガイド（Firepower Device Manager 用』の 6.5 以降を開きます。「システム管理」の章に移動し、「バックアップの復元」を見つけます。この手順に従って、FDM-managed デバイスにダウンロードしたイメージを復元します。

ヒント

復元するには、イメージを Firewall Device Manager にアップロードする必要があります。

ステップ 9

Firewall Device Manager のプロンプトに従います。復元が開始されると、ブラウザは Firewall Device Manager から切断されます。復元が終了すると、デバイスが再起動します。

FDM ソフトウェアのアップグレードパス

FDM バージョンのアップグレード

Security Cloud Control を使用して FDM-managed ファイアウォールをアップグレードする場合、どのバージョンがアップグレード可能かを Security Cloud Control が判断するので、このトピックは必要ありません。このトピックでは、FDM イメージの独自のリポジトリを保持している状況で、独自のイメージを使用して FDM 管理対象デバイスをアップグレードする場合に使用可能なアップグレードパスについて説明します。

FDM 管理対象デバイスは、あるメジャーバージョンまたはメンテナンスバージョンから別のバージョンに直接アップグレードできます。たとえば、バージョン 6.4.0 > 6.5.0、またはバージョン 6.4.0 > 7.0.1 のようにアップグレードできます。特定のパッチレベルを実行する必要はありません。

直接アップグレードが不可能な場合は、アップグレードパスに中間バージョンを含める必要があります（バージョン 6.4.0 > 7.0.0 > 7.1.0 など）。

表 3. メジャーリリースのアップグレードパス
ターゲットバージョン	ターゲットバージョンにアップグレードできる最も古いリリース
7.3.x	7.0.0
7.2.x	6.6.0
7.1.x	6.5.0
7.0.x	6.4.0
6.7.x	6.4.0
6.6.x	6.4.0
6.5.0	6.4.0

FDM 管理対象デバイスへのパッチ適用

バージョン 6.4.0.1 > 6.5.0.1 など、あるバージョンのパッチから別のバージョンのパッチに直接アップグレードすることはできません。まずメジャーリリースにアップグレードしてから、そのリリースにパッチを適用する必要があります。たとえば、バージョン 6.4.0.1 > 6.5.0 > 6.5.0.1 のようにアップグレードする必要があります。

Firepower のホットフィックス

Security Cloud Control は、ホットフィックスの更新またはインストールをサポートしていません。使用中のデバイスモデルまたはソフトウェアバージョンで利用可能なホットフィックスがある場合は、設定済みマネージャのダッシュボードまたは UI を使用することを強くお勧めします。ホットフィックスがデバイスにインストールされると、Security Cloud Control はアウトオブバンドの設定変更を検出します。

FDM アップグレードの削除

Security Cloud Control を使用して、メジャー、メンテナンス、またはパッチのいずれかのリリースタイプを削除またはダウングレードすることはできません。

Secure Firewall Threat Defense 防御バージョン 6.7.0 以降では、Firepower Device Manager または FTD CLI を使用して、正常にアップグレードされたデバイスを、最後のメジャーアップグレードまたはメンテナンスアップグレードの直前の状態（スナップショットとも呼ばれる）に戻すことができます。パッチ適用後に復元すると、パッチも必然的に削除されます。復元の後、アップグレードと復元の間に行った設定変更があれば再適用する必要があります。メジャーアップグレードまたはメンテナンスアップグレードを FDM バージョン 6.5.0 ～ 6.6.x に戻すには、再イメージ化が必要であることに注意してください。詳細については、『Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager』の「System Management」セクションを参照してください。

FDM パッチの削除

Security Cloud Control または FDM のいずれかを使用して FDM パッチを削除することはできません。パッチを削除するには、メジャーリリースまたはメンテナンスリリースに再イメージ化する必要があります。

Snort のアップグレード

Snort はこの製品の主要な検査エンジンであり、利便性のために Secure Firewall Threat Defense ソフトウェアにパッケージ化されています。バージョン 6.7 では、パッケージの更新が導入されており、いつでもアップグレードまたは元に戻すことができます。Snort のバージョンは自由に切り替えることができますが、Snort 2.0 の一部の侵入ルールは Snort 3.0 に存在しない場合があり、その逆の場合もあります。詳細については、Firepower Device Manager バージョン 6.7.0 のコンフィギュレーションガイドで、両者の相違点を確認することを強くお勧めします。

Snort 3 を使用できるように FDM-managed デバイスをアップグレードするか、Security Cloud Control UI を使用して Snort 3 から Snort 2 に戻すには、「Snort 3.0 へのアップグレード」および「FTD の Snort 3.0 からの復元」をそれぞれ参照してください。

その他アップグレードの制限事項

2100 シリーズデバイス

Firepower 2100 シリーズデバイスがアプライアンスモードで稼働している場合のみ、Security Cloud Control はデバイスをアップグレードできます。

Firepower Threat Defense デバイスは常にアプライアンスモードです。

次のタスク

これらのコマンドの詳細については、『Cisco Firepower 2100 スタートアップガイド』を参照してください。

4100 シリーズおよび 9300 シリーズデバイス

Security Cloud Control は、4100 または 9300 シリーズデバイスのアップグレードをサポートしていません。これらのデバイスは Security Cloud Control の外部でアップグレードする必要があります。

FDM-Managed デバイスのアップグレードの前提条件

Security Cloud Control では、個々のデバイスまたは HA ペアにインストールされている Firewall Device Manager（FDM）イメージをアップグレードするのに役立つウィザードを使用できます。

このウィザードに従って、互換性のあるイメージを選択してインストールし、デバイスを再起動してアップグレードを完了するプロセスを実行できます。Security Cloud Control で選択したイメージが FDM-managed デバイスにコピーおよびインストールされたものであることを検証することにより、アップグレードプロセスを保護します。アップグレードする FDM-managed デバイスのインターネットへのアウトバウンドアクセスを可能にすることを強く推奨します。

FDM-managed デバイスにインターネットへのアウトバウンドアクセスがない場合は、必要なイメージを Cisco.com からダウンロードして独自のリポジトリに保存し、アップグレードウィザードにそれらのイメージへのカスタム URL を入力できます。そうすると、Security Cloud Control はそれらのイメージを使ってアップグレードを実行します。とはいえ、このケースでは、アップグレードするイメージを自分で決定することになります。Security Cloud Control は、イメージの完全性チェックやディスク容量チェックを実施しません。

設定要件

FDM-managed デバイスで DNS が有効になっていること。詳細については、デバイスが実行しているバージョンの『Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager』に含まれる「System Administration」の章の「Configuring DNS」セクションを参照してください。
Security Cloud Control のイメージリポジトリからアップグレードイメージを使用する場合は、FDM-managed デバイスがインターネットに接続できること。
FDM-managed デバイスが Security Cloud Control に正常にオンボーディングされていること。
FDM-managed デバイスが到達可能であること。
FDM-managed デバイスが同期されていること。
- Security Cloud Control に保留中の変更があるデバイスの変更を受け入れずにそのデバイスを更新した場合、保留中の変更はアップグレードの完了後に失われます。ベストプラクティスは、保留中の変更をすべて展開してからアップグレードすることです。
- Firewall Device Manager で変更を段階的に実行しており、デバイスが同期されていない場合、Security Cloud Control でのアップグレードは利用資格のチェックで失敗します。

FTD を実行中の 4100 および 9300 シリーズ

ソフトウェアおよびハードウェアの要件

Security Cloud Control はクラウド管理プラットフォームです。ソフトウェアの更新は時間の経過とともに継続的にリリースされ、通常はハードウェアに依存しません。

サポートされているハードウェアタイプの詳細については、「Security Cloud Control でサポートされるソフトウェアとハードウェア」を参照してください。

Firewall Device Manager ソフトウェアを実行しているデバイスには、最適なパフォーマンスを得るための推奨されるアップグレードパスがあります。詳細については、「Firepower ソフトウェアアップグレードパス」を参照してください。

アップグレードに関する注意事項

アップグレード中にデバイスに変更を展開することはできません。

単一 FDM-Managed デバイスのアップグレード

はじめる前に

アップグレードする前に、「FTD アップグレードの前提条件」、「Firepower ソフトウェアアップグレードパス」、および「Security Cloud Control でサポートされるデバイス、ソフトウェア、ハードウェア」を必ずお読みください。

「サポートされるデバイス、ソフトウェア、ハードウェア」を参照してください。

このドキュメントでは、目的のバージョンの Firepower ソフトウェアにアップグレードする前に知っておくべき要件と注意について説明します。

Security Cloud Control のリポジトリからのイメージを使用した単一の FDM-Managed のアップグレード

次の手順を使用して、Security Cloud Control のリポジトリに保存されているソフトウェアイメージを使用してスタンドアロン FDM-managed デバイスをアップグレードします。

手順

ステップ 1

ナビゲーションバーで Security Devices をクリックします。

ステップ 2

[デバイス（Devices）] タブをクリックしてデバイスを見つけます。

ステップ 3

[FTD] タブをクリックします。

ステップ 4

アップグレードするデバイスを選択します。

ステップ 5

[デバイスアクション（Device Actions）] ペインで、[アップグレード（Upgrade）] をクリックします。

ステップ 6

ステップ 1 で、[Security Cloud Controlイメージリポジトリの使用（Use Security Cloud Control Image Repository）] をクリックしてアップグレードするソフトウェアイメージを選択し、[続行（Continue）] をクリックします。アップグレード可能なデバイス互換性のある選択肢のみが表示されます。

ステップ 7

手順 2 で、選択内容を確認し、デバイスへのイメージのダウンロードのみを実行するか、それともイメージをコピーしてインストールしデバイスを再起動するかを決定します。

ステップ 8

準備ができたら、[アップグレードの実行（Perform Upgrade）] をクリックします。[Security Devices] ページで、アップグレード中のデバイスの設定ステータスが「アップグレード中（Upgrade in Progress）」になります。

警告	アップグレードの進行中にアップグレードをキャンセルする場合は、[アップグレード（Upgrade）] ページで [アップグレードの中止（Abort Upgrade）] をクリックします。開始後にアップグレードをキャンセルすると、Security Cloud Control はデバイスからの変更を展開もチェックもせず、デバイスは以前の設定にロールバックされません。その結果、デバイスが異常な状態になる場合があります。アップグレードの過程で何らかの問題が発生した場合は、Cisco TAC までお問い合わせください。

ステップ 9

後で Security Cloud Control にアップグレードを実行させる場合は、[アップグレードのスケジュール設定（Schedule Upgrade）] チェックボックスをオンにします。フィールドをクリックして、将来の日時を選択します。日時の選択が完了したら、[アップグレードのスケジュール設定（Schedule Upgrade）] ボタンをクリックします。

ステップ 10

[通知（notifications）] タブ（通知タブ）で一括アップグレードアクションの進行状況を確認します。一括アップグレードジョブのアクションがどのように成功または失敗したかについての詳細な情報が必要な場合は、青色の [レビュー（Review）] リンクをクリックして [ジョブ（Jobs）] ページ（ジョブのページ）に移動します。

ステップ 11

システムデータベースをアップグレードします。Firewall Device Manager でこのステップを実行する必要があります。詳細については、『Firepower Device Manager 向け Cisco Firepower Threat Defense 構成ガイド』、バージョン 6.4 の「システムデータベースのアップデート」を参照してください。

独自のリポジトリからのイメージを使用した単一の FDM-Managed デバイスのアップグレード

次の手順を使用して、ソフトウェアイメージを見つけるための URL プロトコルを使用してスタンドアロン FDM-managed デバイスをアップグレードします。

手順

ステップ 1

左側のペインで Security Devices をクリックします。

ステップ 2

[デバイス（Devices）] タブをクリックしてデバイスを見つけます。

ステップ 3

[FTD] タブをクリックします。

ステップ 4

アップグレードするデバイスを選択します。

ステップ 5

[デバイスアクション（Device Actions）] ペインで、[アップグレード（Upgrade）] をクリックします。

ステップ 6

手順 1 で、[イメージURLの指定（Specify Image URL）] をクリックしてアップグレードするソフトウェアイメージを選択し、[続行（Continue）] をクリックします。アップグレード可能なデバイス互換性のある選択肢のみが表示されます。

ステップ 7

ステップ 8

準備ができたら、[アップグレードの実行（Perform Upgrade）] をクリックします。[Security Devices] ページで、アップグレード中のデバイスの設定ステータスが「アップグレード中（Upgrade in Progress）」になります。

警告	アップグレードの進行中にアップグレードをキャンセルする場合は、[アップグレード（Upgrade）] ページで [アップグレードの中止（Abort Upgrade）] をクリックします。開始後にアップグレードをキャンセルすると、Security Cloud Control はデバイスからの変更を展開もチェックもせず、デバイスは以前の設定にロールバックされません。その結果、デバイスが異常な状態になる場合があります。アップグレードの過程で何らかの問題が発生した場合は、Cisco TAC までお問い合わせください。

ステップ 9

ステップ 10

ステップ 11

システムデータベースをアップグレードします。Firewall Device Manager でこのステップを実行する必要があります。詳細については、『Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager』、バージョン 6.4 の「Updating System Databases」を参照してください。

アップグレードプロセスの監視

[Security Devices] ページでデバイスを選択し、アップグレードボタンをクリックすると、単一のデバイスの進行状況を確認できます。Security Cloud Control により当該デバイスの [Device Upgrade] ページが表示されます。

いずれかの時点でアップグレードが失敗すると、Security Cloud Control にメッセージが表示されます。Security Cloud Control では、アップグレードプロセスは自動的に再起動されません。

警告	自己署名証明書を持つデバイスをアップグレードすると、問題が発生する可能性があります。詳細については、「新しい証明書の検出」を参照してください。

FDM-Managed デバイスの一括アップグレード

はじめる前に

アップグレードする前に、「FDM 管理対象デバイスのアップグレードの前提条件」、「Firepower ソフトウェアアップグレードパス」、および「Security Cloud Control でサポートされるデバイス、ソフトウェア、ハードウェア」を必ずお読みください。

「サポートされるデバイス、ソフトウェア、ハードウェア」を参照してください。

このドキュメントでは、目的のバージョンの Firepower ソフトウェアにアップグレードする前に知っておくべき要件と注意について説明します。

（注）

すべてを同じソフトウェアバージョンにアップグレードする場合にのみ、FDM-managed デバイスを一括アップグレードできます。

Security Cloud Control のリポジトリからのイメージを使用した FDM-Managed デバイスの一括アップグレード

次の手順を使用して、Security Cloud Control のリポジトリに保存されているソフトウェアイメージを使用して複数の FDM-managed デバイスをアップグレードします。

手順

ステップ 1

左側のペインで Security Devices をクリックします。

ステップ 2

[デバイス（Devices）] タブをクリックして、デバイスを見つけます。

ステップ 3

[FTD] タブをクリックします。

ステップ 4

フィルタを使用して、一括アップグレードに含めるデバイスのリストを絞り込みます。

ステップ 5

フィルタ処理されたデバイスのリストから、アップグレードするデバイスを選択します。

ステップ 6

[デバイスアクション（Device Actions）] ペインで、[アップグレード（Upgrade）] をクリックします。

ステップ 7

[デバイスの一括アップグレード（Bulk Device Upgrade）] ページに、アップグレード可能なデバイスが表示されます。選択したどのデバイスもアップグレードできない場合、Security Cloud Control にはアップグレードできないデバイスのリンクが表示されます。

ステップ 8

ステップ 9

ステップ 1 で、[Security Cloud Controlイメージリポジトリの使用（Use Security Cloud Control Image Repository）] をクリックしてアップグレードするソフトウェアイメージを選択します。アップグレード可能なデバイスと互換性のある選択肢のみが表示されます。[続行（Continue）] をクリックします。

ステップ 10

ステップ 11

警告	アップグレードの進行中にアップグレードをキャンセルする場合は、[アップグレード（Upgrade）] ページで [アップグレードの中止（Abort Upgrade）] をクリックします。開始後にアップグレードをキャンセルすると、Security Cloud Control はデバイスからの変更を展開したり、変更に関してポーリングしたりしません。アップグレードがキャンセルされた後も、デバイスは以前の構成にロールバックしません。その結果、デバイスが異常な状態になる場合があります。アップグレードの過程で何らかの問題が発生した場合は、Cisco TAC までお問い合わせください。

ステップ 12

[通知（notifications）] タブ（通知タブ）で一括アップグレードアクションの進行状況を確認します。一括アップグレードジョブのアクションがどのように成功または失敗したかについての詳細な情報が必要な場合は、青色の [Review] リンクをクリックして [Jobs] ページ（ジョブのページ）に移動します。

ステップ 13

システムデータベースをアップグレードします。Firewall Device Manager でこのステップを実行する必要があります。デバイスが実行しているバージョンについては、『Firepower Device Manager 向け Cisco Firepower Threat Defense 構成ガイド』の「システムデータベースのアップデート」を参照してください。

独自のリポジトリからのイメージを使用した FDM-Managed デバイスの一括アップグレード

次の手順を使用して、ソフトウェアイメージを見つけるための URL プロトコルを使用して複数の FDM-managed デバイスをアップグレードします。

手順

ステップ 1

左側のペインで Security Devices をクリックします。

ステップ 2

[デバイス（Devices）] タブをクリックして、デバイスを見つけます。

ステップ 3

[FTD] タブをクリックします。

ステップ 4

フィルタを使用して、一括アップグレードに含めるデバイスのリストを絞り込みます。

ステップ 5

フィルタ処理されたデバイスのリストから、アップグレードするデバイスを選択します。

ステップ 6

[デバイスアクション（Device Actions）] ペインで、[アップグレード（Upgrade）] をクリックします。

ステップ 7

ステップ 8

ステップ 9

手順 1 で、[イメージURLの指定（Specify Image URL）] をクリックしてアップグレードするソフトウェアイメージを選択し、[続行（Continue）] をクリックします。

ステップ 10

ステップ 11

警告	アップグレードの進行中にアップグレードをキャンセルする場合は、[アップグレード（Upgrade）] ページで [アップグレードの中止（Abort Upgrade）] をクリックします。アップグレードの開始後にアップグレードをキャンセルすると、Security Cloud Control はデバイスからの変更を展開したり、変更に関してポーリングしたりせず、デバイスは以前の設定にロールバックされません。その結果、デバイスが異常な状態になる場合があります。アップグレードの過程で何らかの問題が発生した場合は、Cisco TAC までお問い合わせください。

ステップ 12

ステップ 13

一括アップグレードプロセスの監視

[Devices & Services] ページでデバイスを選択し、[Upgrade] ボタンをクリックすると、一括アップグレードに含まれていた単一のデバイスでの進行状況を表示できます。左側のペインで [ジョブ（Jobs）] をクリックして一括操作を展開しても、進行状況の詳細を表示できます。

FDM-Managed ハイアベイラビリティペアのアップグレード

スタンバイデバイスが、セカンダリデバイスがアップグレードされている間もトラフィック検出を処理し続けるため、トラフィックを中断することなく HA ペアをアップグレードします。

HA ペアをアップグレードすると、Security Cloud Control は適格性チェックを実行し、アップグレードを開始する前にイメージの場所をコピーまたは識別します。ハイアベイラビリティペアのセカンダリデバイスは、それが現在アクティブなデバイスであっても、最初にアップグレードされます。セカンダリデバイスがアクティブな Security Cloud Control デバイスの場合、ペアリングされたデバイスはアップグレードプロセスの役割を自動的に切り替えます。セカンダリデバイスが正常にアップグレードされたら、デバイスの役割が切り替わり、新しいスタンバイデバイスがアップグレードされます。アップグレードが完了すると、プライマリデバイスがアクティブになり、セカンダリデバイスがスタンバイになるように、デバイスが自動的に構成されます。

アップグレードプロセス中に HA ペアに展開することはお勧めしません。

はじめる前に

アップグレードする前に、保留中のすべての変更をアクティブなデバイスに展開します。
アップグレード中に実行されるタスクがないことを確認します。
HA ペアの両方のデバイスが正常で、
アップグレードする準備ができていることを確認します。Security Cloud Control で以前のバージョンにロールバックすることはできません。
「FTD アップグレードの前提条件」、「Firepower ソフトウェアアップグレードパス」、および「Security Cloud Control がサポートするソフトウェアとハードウェア」を読み、アップグレードプロセス中に発生する可能性のある要件と警告を確認します。

Cisco Security Cloud のリポジトリからのイメージを使用した FDM-Managed HA ペアのアップグレード

次の手順を使用して、Security Cloud Control のリポジトリに保存されているソフトウェアイメージを使用して FDM-managed HA ペアをアップグレードします。

手順

ステップ 1

左側のペインで Security Devices をクリックします。

ステップ 2

[デバイス（Devices）] タブをクリックして、デバイスを見つけます。

ステップ 3

[FTD] タブをクリックします。

ステップ 4

アップグレードする HA ペアを選択します。

ステップ 5

[デバイスアクション（Device Actions）] ペインで、[アップグレード（Upgrade）] をクリックします。

ステップ 6

ステップ 7

ステップ 8

警告	アップグレードの進行中にアップグレードをキャンセルする場合は、[アップグレード（Upgrade）] ページで [アップグレードの中止（Abort Upgrade）] をクリックします。開始後にアップグレードをキャンセルすると、Security Cloud Control はデバイスからの変更を展開したり、ポーリングしたりせず、デバイスは以前の設定にロールバックしません。その結果、デバイスが異常な状態になる場合があります。アップグレードの過程で何らかの問題が発生した場合は、Cisco TAC までお問い合わせください。

ステップ 9

ステップ 10

ステップ 11

システムデータベースをアップグレードします。この手順を FDM で実行する必要があります。詳細については、『Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager』、バージョン 6.4 の「Updating System Databases」を参照してください。

独自のリポジトリからのイメージを使用した FDM-Managed HA ペアのアップグレード

ソフトウェアイメージを見つけるための URL プロトコルを使用して FDM-managed HA ペアをアップグレードするには、次の手順を実行します。

手順

ステップ 1

左側のペインで Security Devices をクリックします。

ステップ 2

[デバイス（Devices）] タブをクリックして、デバイスを見つけます。

ステップ 3

[FTD] タブをクリックします。

ステップ 4

アップグレードする HA ペアを選択します。

ステップ 5

[デバイスアクション（Device Actions）] ペインで、[アップグレード（Upgrade）] をクリックします。

ステップ 6

ステップ 7

ステップ 8

警告	アップグレードの進行中にアップグレードをキャンセルする場合は、[アップグレード（Upgrade）] ページで [アップグレードの中止（Abort Upgrade）] をクリックします。開始後にアップグレードをキャンセルすると、Security Cloud Control はデバイスからの変更を展開したり、ポーリングしたりせず、デバイスは以前の設定にロールバックしません。その結果、デバイスが異常な状態になる場合があります。アップグレードの過程で何らかの問題が発生した場合は、Cisco TAC までお問い合わせください。

ステップ 9

ステップ 10

ステップ 11

アップグレードプロセスの監視

[Security Devices] ページでデバイスを選択し、アップグレードボタンをクリックすると、単一のデバイスの進行状況を確認できます。Security Cloud Control により当該デバイスの [Device Upgrade] ページが表示されます。

アップグレードの間、システムライブラリの更新中（自動展開を含む）に HA が一時停止され、アップグレードプロセス全体が正常な状態ではないことがあります。これは予想どおりの結果です。このプロセスの最後の部分で、デバイスは SSH 接続が可能になるため、アップグレードの適用後すぐにログインすると、HA が一時停止ステータスになっている場合があります。アップグレードプロセス中にシステムで問題が発生し、HA ペアが一時停止しているように見える場合は、アクティブデバイスの Firewall Device Manager コンソールから手動で HA を再開します。

（注）

警告	自己署名証明書を持つデバイスをアップグレードすると、問題が発生する可能性があります。詳細については、「新しい証明書の検出」を参照してください。

Snort 3.0 へのアップグレード

Snort 3 は、最新の Snort エンジン、つまりオープンソースの侵入防御システム（IPS）を使用する強力なプリプロセッサであり、Firepower バージョン 6.7 以降で使用できます。Snort エンジンは、悪意のあるネットワークアクティビティを定義するのに役立つ一連のルールを使用して、ルールに一致するパケットを見つけ、ユーザーに対してアラートを生成します。Snort エンジンは、パケットスニファ、パケットロガー、またはより従来型のスタンドアロンネットワーク IPS として使用するのに適しています。

Snort 3 では、カスタム侵入ポリシーの作成が可能で、Snort 3 を実行するすべての FDM-managed デバイスには、シスコの Talos Intelligence Group（Talos）が事前定義した一連の侵入ポリシーがあります。Snort 3 ではこれらのデフォルトポリシーを変更できますが、より堅牢なポリシーに対するベースの上に構築することを強くお勧めします。

Snort 2 ではカスタムポリシーは作成できません。

Snort 2 から Snort 3 への切り替え

Snort のバージョンは自由に切り替えられますが、Snort 2.0 の一部の侵入ルールは Snort 3.0 に存在しない場合があります（その逆もあります）。既存ルールのルールアクションを変更した場合、Snort 3 に切り替えてから Snort 2 に戻るか、または再度 Snort 3 に戻った場合、変更は保持されません。両方のバージョンに存在するルールのルールアクションに対する変更は保持されます。Snort 3 と Snort 2 のルール間マッピングは 1 対 1 または 1 対多にすることができるため、変更の保存はベストエフォートベースで行われることに注意してください。

Snort 2 から Snort 3 へのアップグレードを選択した場合、Snort エンジンのアップグレードはシステムアップグレードと同等であることに注意してください。ネットワークのトラフィックモニタリングの中断を最小限に抑えるために、メンテナンス時間中にアップグレードすることを強くお勧めします。Snort バージョンの切り替えがルールのトラフィック処理にどのように影響するかについては、Firepower Device Manager 設定ガイド [英語] の「Managing Intrusion Policies (Snort3)」を参照してください。https://www.cisco.com/c/en/us/td/docs/security/firepower/670/fdm/fptd-fdm-config-guide-670/fptd-fdm-intrusion.html#Cisco_Task_in_List_GUI.dita_9a2ed29f-0ef8-47bf-ac36-2f183fd2b055

ヒント

[セキュリティデバイス（Security Devices）] ページでは Snort バージョンでフィルタリングできます。選択したデバイスの [詳細（Details）] ウィンドウには、デバイスで実行されている現在のバージョンが表示されます。

Snort 3 の制限事項

ライセンス要件

Snort エンジンが侵入およびマルウェア分析のトラフィックを処理できるようにするには、FDM-managed デバイスに対して ライセンスを有効にする必要があります。Firewall Device Manager を介して IPS ライセンスを有効にするには、Firewall Device Manager UI にログインし、[デバイス（Device）] > [設定の表示（View Configuration）] > [有効化/無効化（Enable/Disable）]に移動し、ライセンスを有効にします。

ハードウェアサポート

次のデバイスは Snort 3 をサポートしています。

FTD 1000 シリーズ
FTD 2100 シリーズ
FTD 4100 シリーズ
AWS を搭載した FTD 仮想
Azure を搭載した FTD 仮想
FTD を搭載した ASA 5500-X シリーズ

ソフトウェアサポート

デバイスは Firewall Device Manager バージョン 6.7 以降を実行している必要があります。Security Cloud Control は、バージョン 6.7 以降を実行しているデバイスの Snort 3 機能をサポートします。

FTD 1000 および 2000 シリーズの場合、FXOS パッチサポートの詳細については、「FXOS bundled support」を参照してください。

構成の制限

デバイスに次の設定がある場合、Security Cloud Control は Snort 3 へのアップグレードをサポートしません。

デバイスがバージョン 6.7 以降を実行していない。
デバイスに保留中の変更がある場合。アップグレードする前に変更を展開します。
デバイスが現在アップグレード中の場合。デバイスが同期されるまで、デバイスへのアップグレードや展開を試みないでください。
デバイスが仮想ルータで設定されている場合。

（注）

Snort のバージョンをアップグレードまたは元に戻すと、Snort 2 侵入ポリシーと Snort 3 侵入ポリシー間の変更を実装するために自動的に展開されます。

ルールセットと Snort 3

現時点では、Snort 3 は完全な機能をサポートしていないことに注意してください。Security Cloud Control ルールセットは Snort 3 デバイスではサポートされていません。デバイスを Firewall Device Manager 6.7 以降にアップグレードし、同時に Snort 2 から Snort 3 にアップグレードする場合、アップグレード前に設定されたルールセットはすべて分割され、ルールは個別のルールとして保存されます。

Snort 3 用に設定されたデバイスに関するルールセットサポートの完全なリストについては、ルールセットを参照してください。

デバイスと侵入防御エンジンの同時アップグレード

Security Cloud Control では、デバイスをバージョン 6.7 および Snort 3 にアップグレードできます。次の手順を使用して、FDM-managed デバイスをアップグレードします。

手順

ステップ 1

左側のペインで Security Devices をクリックします。

ステップ 2

[デバイス] タブをクリックします。

ステップ 3

[FTD] タブをクリックし、アップグレードする 1 つまたは複数のデバイスを選択します。

ステップ 4

右側にある [デバイスアクション（Device Actions）] ペインで、[アップグレード（Upgrade）] をクリックします。

ステップ 5

アップグレードの切り替えを [FTD システムアップグレード（FTD System Upgrade）] に設定します。

ステップ 6

（任意）後で Security Cloud Control にアップグレードを実行させる場合は、[アップグレードのスケジュール設定（Schedule Upgrade）] チェックボックスをオンにします。フィールドをクリックして、将来の日時を選択します。

ステップ 7

手順 1 でアップグレード方法を選択します。Security Cloud Control イメージリポジトリか、独自のリポジトリのイメージを使用します。

[Security Cloud Controlイメージリポジトリの使用（Use Security Cloud Control Image Repository]）] - このオプションをクリックしてアップグレードするソフトウェアイメージを選択し、[続行（Continue）] をクリックします。アップグレード可能なデバイス互換性のある選択肢のみが表示されます。
[イメージ URL の指定（Specify Image URL）] - このオプションをクリックして現在自分のリポジトリに保存されているソフトウェアイメージを選択し、[続行（Continue）] をクリックします。アップグレード可能なデバイス互換性のある選択肢のみが表示されます。

ステップ 8

ステップ 9

[Snort 3 エンジンへのアップグレード（Upgrade to Snort 3 Engine）] をチェックします。

ステップ 10

警告	アップグレードの進行中にアップグレードをキャンセルする場合は、[アップグレード（Upgrade）] ページで [アップグレードの中止（Abort Upgrade）] をクリックします。開始後にアップグレードをキャンセルすると、Security Cloud Control はデバイスからの変更を展開もチェックもせず、デバイスは以前の設定にロールバックされません。その結果、デバイスが異常な状態になる場合があります。アップグレードの過程で何らかの問題が発生した場合は、Cisco TAC までお問い合わせください。

侵入防御エンジンのアップグレード

Snort 2 でバージョン 6.7 を既に実行しているデバイスの場合、次の手順を使用して、Snort エンジンのみをバージョン 3 に更新します。

手順

ステップ 1	ナビゲーションバーで Security Devices をクリックします。
ステップ 2	[デバイス] タブをクリックします。
ステップ 3	[FTD] タブをクリックし、アップグレードする 1 つまたは複数のデバイスを選択します。
ステップ 4	右側にある [デバイスアクション（Device Actions）] ペインで、[アップグレード（Upgrade）] をクリックします。
ステップ 5	アップグレードトグルを [侵入防御エンジン（Intrusion Prevention Engine）] に切り替えます。
ステップ 6	[Snort 3.0へのアップグレード（Upgrade to Snort 3.0）] をクリックします。
ステップ 7	[Security Devices] ページで、アップグレード中のデバイスの設定ステータスが「アップグレード中（Upgrade in Progress）」になります。

アップグレードプロセスの監視

警告	アップグレードの進行中にアップグレードをキャンセルする場合は、[アップグレード（Upgrade）] ページで [アップグレードの中止（Abort Upgrade）] をクリックします。開始後にアップグレードをキャンセルすると、Security Cloud Control はデバイスからの変更を展開もチェックもせず、デバイスは以前の設定にロールバックされません。その結果、デバイスが異常な状態になる場合があります。アップグレードの過程で何らかの問題が発生した場合は、Cisco TAC までお問い合わせください。

警告	自己署名証明書を持つデバイスをアップグレードすると、問題が発生する可能性があります。詳細については、「新しい証明書の検出」を参照してください。

FDM-Managed デバイスの Snort 3.0 からの復元

Snort 2.0 の一部の侵入ルールは Snort 3.0 には存在しない場合があります。2.0 にダウングレードすると、作成したカスタム侵入ポリシーはすべて、カスタムポリシーで使用される基本ポリシーに変換されます。可能なかぎり、ルールアクションオーバーライドは保持されます。複数のカスタムポリシーが同じ基本ポリシーを使用する場合は、最も多くのアクセス制御ポリシーで使用されるカスタムポリシーのオーバーライドが保持され、その他のカスタムポリシーのオーバーライドは失われます。これらの「重複」ポリシーを使用していたアクセス制御ルールは、最もよく使用されるカスタムポリシーから作成された基本ポリシーを使用するようになります。すべてのカスタムポリシーが削除されます。

Snort 3.0 からの復帰を選択する前に、『Firepower Device Manager コンフィギュレーションガイド』の「侵入ポリシーの管理（Snort2）」を読み、snort エンジンのバージョンの切り替えが現在のルールとポリシーにどのように影響するかを確認してください。

（注）

バージョン 2 に戻しても、Firepower ソフトウェアバージョンはアンインストールされません。

Snort 3.0 からの復元

Snort バージョンを変更すると、システムは自動展開を実行して変更を実装します。Snort 3.0 からバージョン 2 に戻すことができるのは個々のデバイスのみであることに注意してください。

侵入防御エンジンを元に戻すには、次の手順を使用します。

手順

ステップ 1	ナビゲーションウィンドウで、Security Devices をクリックします。
ステップ 2	[デバイス] タブをクリックします。
ステップ 3	[FTD] タブをクリックし、元に戻すデバイスをクリックします。
ステップ 4	右側にある [デバイスアクション（Device Actions）] ペインで、[アップグレード（Upgrade）] をクリックします。
ステップ 5	アップグレードトグルを [侵入防御エンジン（Intrusion Prevention Engine）] に切り替えます。
ステップ 6	ステップ 1 で、Snort バージョン 3 から元に戻すことを確認し、[Snortエンジン2に戻す（Revert to Snort Engine 2）] をクリックします。
ステップ 7	[Security Devices] ページで、アップグレード中のデバイスの設定ステータスが「アップグレード中（Upgrade in Progress）」になります。

セキュリティデータベース更新のスケジュール設定

次の手順を使用して、FDM-managed デバイスのセキュリティデータベースを確認および更新するスケジュールされたタスクを作成します。

手順

ステップ 1

左側のペインで Security Devices をクリックします。

ステップ 2

[デバイス] タブをクリックします。

ステップ 3

[FTD] タブをクリックし、目的の FDM-managed デバイスを選択します。

ステップ 4

[アクション（Actions）] ペインで、[セキュリティデータベースの更新（Security Database Updates）] セクションを見つけて、追加ボタン [+] をクリックします。

（注）

選択したデバイスに既存のスケジュールされたタスクがある場合は、編集アイコンをクリックして新しいタスクを作成します。新しいタスクを作成すると、既存のタスクが上書きされます。

ステップ 5

スケジュールされたタスクを次のように設定します。

[頻度（Frequency）]：日次、週次、または月次から更新の頻度を選択します。
[時刻（Time）]：時刻を選択します。時刻は UTC で表示されることに注意してください。
[曜日の選択（Select Days）]：更新を実行する曜日を選択します。

ステップ 6

[保存（Save）] をクリックします。

ステップ 7

デバイスの [設定ステータス（Configuration Status）] が [データベースの更新中（Updating Databases）] に変わります。

セキュリティデータベースの更新スケジュールの編集

FDM-managed デバイスのセキュリティデータベースの検証および更新を実行する既存のスケジュール済みタスクを編集するには、次の手順を実行します。

手順

ステップ 1	左側のペインで Security Devices をクリックします。
ステップ 2	[デバイス] タブをクリックします。
ステップ 3	[FTD] タブをクリックし、目的の FDM-managed デバイスを選択します。
ステップ 4	[操作（Actions）] ウィンドウで、[データベースの更新（Database Updates）] セクションを見つけて、編集アイコンをクリックします。
ステップ 5	次の項目を使用して、スケジュールされたタスクを編集します。 [頻度（Frequency）]：日次、週次、または月次から更新の頻度を選択します。 [時刻（Time）]：時刻を選択します。時刻は UTC で表示されることに注意してください。 [曜日の選択（Select Days）]：更新を実行する曜日を選択します。
ステップ 6	[保存（Save）] をクリックします。
ステップ 7	デバイスの [設定ステータス（Configuration Status）] が [データベースの更新中（Updating Databases）] に変わります。

FDM-Managed デバイスのセキュリティデータベースの更新

FDM-managed デバイスのセキュリティデータベースを更新することにより、SRU（侵入ルール）、セキュリティインテリジェンス（SI）、脆弱性データベース（VDB）、地理位置情報データベースが更新されます。Security Cloud Control UI を使用してセキュリティデータベースを更新することを選択した場合、言及されているすべてのデータベースが更新されることに注意してください。更新するデータベースを選択することはできません。

セキュリティデータベースの更新は元に戻せないことに注意してください。

（注）

セキュリティデータベースを更新すると、一部のパケットがドロップされるか、検査されずに通過する場合があります。メンテナンス期間中に、セキュリティデータベースの更新をスケジュールすることをお勧めします。

導入準備中に FDM-Managed デバイスのセキュリティデータベースを更新する

FDM-managed デバイスを Security Cloud Control にオンボーディングする場合、オンボーディングプロセスの一部を使用して、[データベースのスケジュール済みの定期更新の有効化（Enable scheduled recurring updates for databases）] を実行できます。このオプションは、デフォルトでオンです。有効にすると、Security Cloud Control はすぐにセキュリティの更新を確認して適用し、追加の更新を確認するようにデバイスを自動的にスケジュールします。また、デバイスがオンボードされた後は、スケジュール済みのタスクの日時を変更することもできます。

オンボーディングプロセス中に自動スケジューラを有効にして、セキュリティデータベースの更新を定期的に確認して適用することをお勧めします。この方法により、デバイスが常に最新の状態になります。FDM-managed デバイスの導入準備中にセキュリティデータベースを更新するには、「Onboard an FDM-Managed Device with a Registration Key（登録キーを使用した FDM 管理対象デバイスの導入準備）」を参照してください。

（注）

登録キー方式でデバイスをオンボーディングする場合、デバイスをスマートライセンスに登録することはできません。ライセンスを登録するようお勧めします。別の方法として、デバイスのユーザー名、パスワード、および IP アドレスを使用してデバイスをオンボーディングすることができます。

導入準備後に FDM-Managed デバイスのセキュリティデータベースを更新する

FDM-managed デバイスが Security Cloud Control にオンボーディングされた後、更新をスケジュールすることにより、セキュリティデータベースの更新を確認するようにデバイスを設定できます。更新がスケジュールされているデバイスを選択して、スケジュールされたタスクをいつでも変更できます。詳細については、「FTD セキュリティデータベースの更新」を参照してください。

Cisco Security Cloud Controlを使用した FDM デバイスの管理

偏向のない言語

翻訳について

検索結果

章のタイトル： Security Cloud Control でのデバイスのオンボーディング

Security Cloud Control でのデバイスのオンボーディング

Secure Device Connector

管理対象デバイスへの Security Cloud Control の接続

Cloud Connector を介したデバイスの Security Cloud Control への接続

SDC への Security Cloud Control の接続

Secure Device Connector および Secure Event Connector を実行するための VM の展開

サポートされているインストール

システム要件

設置の準備

VM の展開

VM の設定

自身の VM 上での Secure Device Connector の展開

始める前に

手順

次のタスク

展開されたホストでの Secure Device Connector のブートストラップ

手順

Terraform を使用した vSphere への Secure Device Connector の展開

始める前に

手順

例:

例:

例:

Terraform モジュールを使用した AWS VPC 上での Secure Device Connector の展開

始める前に

手順

次のタスク

オンプレミス Secure Device Connector および Secure Event Connector の CentOS 7 仮想マシンから Ubuntu 仮想マシンへの移行

移行する前に

前提条件

ホストの設定

SDC の移行

SEC の移行

追加手順

Secure Device Connector の IP アドレスの変更

始める前に

手順

Secure Device Connector の削除

手順

ある SDC から別の SDC への ASA の移動

手順

Secure Device Connector の名前変更

手順

Secure Device Connector の更新

手順

単一の Security Cloud Control テナントで複数の SDC を使用する

同じ SDC を使用する Security Cloud Control デバイス

手順

SDC のオープンソースおよびサードパーティライセンス

サポートされるデバイス、ソフトウェア、ハードウェア

Cisco Secure Firewall ASA

Cisco Secure Firewall Threat Defense

Cisco Catalyst SD-WAN Manager

Cisco Secure Firewall Management Center

Cisco Meraki MX

Cisco IOS デバイス

Cisco Umbrella

AWS セキュリティグループ

Secure Firewall Threat Defense デバイスのサポートの詳細

Firewall Threat Defense with Secure Firewall Device Manager

Snort

FDM-Managedデバイスのオンボード

FDM-managed デバイス管理

ライセンシング

デバイスのアドレス指定

内部インターフェイスからの FDM-Managed デバイスの管理

リモートアクセス VPN の要件

次に行う作業：

内部インターフェイスからの FDM-Managed デバイスの管理

始める前に

手順

次のタスク

外部インターフェイスからの FDM-Managed デバイスの管理

リモートアクセス VPN の要件

次に行う作業：

Security Cloud Control への FDM-Managed デバイスのへのオンボード

スマートライセンスのタイプ