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

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

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

SDC とそのステータスの詳細については、 Secure Device Connector について を参照してください。

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

セキュアコネクタの概要

セキュアコネクタは、ネットワークまたはサポートされているクラウド環境で実行され、Security Cloud Control Firewall Management と管理対象リソースとの間にセキュアな通信経路を提供する、コネクタインスタンスです。セキュアコネクタは、Security Cloud Control Firewall Management がインターネットから直接到達できないデバイスを管理するのに役立ち、ロギングおよび分析ワークフローでのイベント転送をサポートします。

[セキュアコネクタ（Secure Connector）] ページを使用して、テナントのコネクタインスタンスを表示、展開、および管理します。

セキュアコネクタのタイプ

[セキュアコネクタ（Secure Connector）] ページには、次のコネクタタイプを含めることができます。

  • セキュアデバイスコネクタ（SDC）：Security Cloud Control Firewall Management とサポートされている管理対象デバイスとの間にセキュアな通信パスを提供します。

  • セキュアイベントコネクタ（SEC）：サポートされているデバイスからイベントを受信し、ロギングおよび分析のために、それらを Cisco Cloud に転送します。

Secure Device Connector について

Secure Device Connector（SDC）は、デバイスがインターネットから直接到達できない場合にシスコデバイスが Security Cloud Control Firewall Management と通信できるようにするインテリジェントプロキシです。デバイスログイン情報を使用してデバイスをオンボーディングする場合、ネットワークに SDC を展開して、デバイスと Security Cloud Control Firewall Management 間の通信をプロキシできます。デバイスがインターネットから直接到達可能である場合、SDC を使用する代わりにデバイスの外部インターフェイスを介した直接通信を許可できます。SDC は次の機能を実行します。

  • 管理対象デバイスのコマンドとメッセージを Security Cloud Control Firewall Management でモニターします。

  • Security Cloud Control Firewall Management の代わりにコマンドを実行します。

  • 管理対象デバイスにメッセージをリレーします。

  • デバイス応答を返します。

SDC と Security Cloud Control Firewall Management 間の通信では、TLS 1.3 および AES-128-GCM を使用した HTTPS が使用されます。オンボードのデバイスとサービスのすべてのログイン情報は、ブラウザから SDC に直接暗号化されるだけでなく、AES-128-GCM を使用して保存時にも暗号化されます。SDC のみがこれらのログイン情報にアクセスできます。

ネットワーク管理者ロールを持つユーザーは、Secure Device Connector またはセキュアイベントコネクタ（SEC）を作成する必要があります。

これらのデバイスを、以下の SDC を介して Secure Device Connector にオンボーディングできます。

  • Secure Firewall ASA

  • ログイン情報メソッドを使用した オンプレミス Firewall Management Center

  • Meraki MX デバイス

  • 汎用 SSH デバイス

  • Cisco IOS デバイス

クラウド提供型 Firewall Management Center によって管理される Cisco Secure Firewall Threat Defense デバイスは SDC を必要とせず、プロキシを介したオンボーディングをサポートしません。これらのデバイスが クラウド提供型 Firewall Management Center に接続できるように、適切な DNS 設定とアウトバウンド インターネット接続があることを確認してください。

SDC と Security Cloud Control 間の通信を許可する方法については、直接クラウド接続のインバウンドアクセスを許可を参照してください。

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

デバイス接続の計画

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

表 1.

接続方法

次の場合に使用

必要なネットワークアクセス

ダイレクト クラウド コネクタ

デバイスはインターネットから直接到達可能です。

ポート 443、またはデバイス管理に使用するポートで、クラウドリージョンの Security Cloud Control Firewall Management IPアドレスからのインバウンドアクセスを許可します。

SDC

デバイスがインターネットから直接到達できないか、送信元がオンプレミス SDC を明示的に必要としています。

ポート 443 またはデバイス管理に使用するポートで、SDC ホストからのフルインバウンドアクセスを許可します。SDC VMがデバイス管理インターフェイスに到達できることを確認します。

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

送信元は、以下をオンボーディングするにはオンプレミス SDC が必要であることを明確にしています。

  • クラウドからアクセスできない ASA デバイス

  • ログイン情報のオンボード方式を使用する場合にクラウドからアクセスできない FDM による管理 デバイス

  • Cisco IOS デバイス

  • SSH アクセスのあるデバイス。

Security Cloud Control Firewall Management はクラウドコネクタを使用して接続するため、他のすべてのデバイスとサービスにはオンプレミス SDC は必要ありません。

直接クラウド接続のインバウンドアクセスを許可

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

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

表 2.

地域

URL

次からのインバウンドアクセスを許可

アジア太平洋日本（APJ）

https://security.cisco.com

54.199.195.111、

52.199.243.0

オーストラリア（AUS）

https://security.cisco.com

13.55.73.159、

13.238.226.118

ヨーロッパ、中東、アフリカ（EMEA）

https://security.cisco.com

35.157.12.126、

35.157.12.15

インド（IN）

https://security.cisco.com

35.154.115.175

13.201.213.99

アメリカ合衆国（US）

https://security.cisco.com

52.34.234.2

52.36.70.147
ASA を SDC に接続する際の特別な考慮事項

具体的に述べると、ASA との接続に、SDC は ASDM で使用されるのと同じ安全な通信チャネルを使用します。

管理下の ASA も AnyConnect VPN クライアント接続を受け入れるように設定されている場合は、ASDM HTTP サーバーポートを 1024 以上の値に変更する必要があります。このポート番号は、Security Cloud Control への ASA デバイスのオンボーディングに使用されるポート番号と同じものになることに注意してください。

ASA コマンドの例

次の例では、ASA 外部インターフェイスの名前が「outside」であり、ASA で AnyConnect クライアントが設定されているため、ASDM HTTP サーバーがポート 8443 でリッスンしていると想定しています。

外部インターフェイスを有効にするには、次のコマンドを入力します。

アジア太平洋日本地域：

  • http 54.199.195.111 255.255.255.255 outside

  • http 52.199.243.0 255.255.255.255 outside

オーストラリア地域

  • http 13.55.73.159 255.255.255.255 outside

  • http 13.238.226.118 255.255.255.255 outside

EMEA 地域

  • http 35.157.12.126 255.255.255.255 outside

  • http 35.157.12.15 255.255.255.255 outside

インド地域

  • http 35.154.115.175 255.255.255.255 outside

  • http 13.201.213.99 255.255.255.255 outside

米国地域

  • http 52.34.234.2 255.255.255.255 outside

  • http 52.36.70.147 255.255.255.255 outside

AnyConnect VPN クライアントが使用されている場合に ASDM HTTP サーバーポートを有効にするには、次のコマンドを入力します。

http server enable 8443

SDC キャパシティとホストの要件を計画

各 Security Cloud Control Firewall Management 組織は SDC の数に制限はありません。SDC は 1 つの組織にのみ属しており、組織間で共有されることはありません。展開プランでは、1 つの SDC は約 500 台のデバイスをサポートすると予想されます。実際のキャパシティは、該当デバイスで有効になっている機能と、構成ファイルのサイズによって異なります。

複数の SDC を展開すると、次のことが可能になります。

  • パフォーマンスを低下させることなく、デバイス管理を拡張できます。

  • SDC を隔離されたネットワークセグメントに配置し、デバイスを同じ Security Cloud Control Firewall Management 組織内に配置します。

  • 追加の SDC ごとにブートストラップ手順に従い、ホスト上で複数の SDC を実行します。

最初の SDC の名前にはテナント名と数値 1 が含まれています。SDC が追加されるたびに、シーケンスが番号付けされます。

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

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

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

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 アドレスからのインバウンドトラフィックを許可する必要があります。

  • 適切なネットワークアクセスを確保するため、「直接クラウド接続のインバウンドアクセスを許可 の 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 つのオプションがあります。

  1. Security Cloud Control が提供する VMware イメージをダウンロードするには、次の手順を実行します。

  2. Ubuntu 20、22、または 24 を自分で展開する場合、独自の Ubuntu インスタンスを展開するときは、次のセクションをスキップして、「VM の設定」セクションに進むことができます。

手順

  1. 左側のペインで [管理（Administration）] > [統合（Integrations）] > [セキュアコネクタ（Secure Connectors）] をクリックします。

  2. [Services] ページの [Secure Connectors] タブを選択し、青いプラスボタンをクリックして、[Secure Device Connector] を選択します。

  3. [Download the SDC VM image] をクリックします。新しいタブで表示されます。

  4. .zip ファイルからすべてのファイルを抽出します。これらは次のようなものです。

    • CDO-SDC-VM-ddd50fa.ovf

    • CDO-SDC-VM-ddd50fa.mf

    • CDO-SDC-VM-ddd50fa-disk1.vmdk

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


    （注）  

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

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

  6. セットアップが完了したら、SDC VM の電源を入れます。

  7. 新しい SDC VM のコンソールを開きます。

  8. CDO というユーザー名でログインします。デフォルトのパスワードは adm123 です。

VM の設定

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

  1. 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

  2. 次のコマンドを実行して、ホストの構成を開始します：

    sudo sdc host configure

  3. パスワードの入力を求められたら、Security Cloud Control 提供の VM 場合は adm123 を入力し、独自の VM の場合は、選択した管理者パスワードを入力します。

  4. プロンプトに従って、sdc ユーザーを設定します。

  5. ネットワークの設定を求められたら、次のいずれかを選択します。

    • [このホストを静的 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.）]

  6. プロンプトが表示されたら、プロキシ設定に関する質問に回答します。このトピックの上部にある詳細なリストで、すべての前提条件と、可能なプロキシ設定オプションを確認してください。

  7. プロキシが設定済みである場合は、すべてのプロキシ設定を有効にするために VM を再起動することを求められます。設定していない場合は、再起動することを求められず、手順 8 に進むことができます。

  8. カスタム インターネット アクセス テスト URL を設定します。これを行う必要があるのは、デフォルトですべてのアウトバウンド接続を拒否する場合のみです。その場合は、許可リストにある https://google.com などのパブリックにアクセス可能な Web URL を指定します。

  9. 最新のセキュリティパッチをインストールします。一部のパッチには OS ツールと Docker サーバーが必要です。

  10. プロンプトが表示されたら、スクリプトで SSH 設定を強化するかどうかを指定します。

    シスコの VM を使用している場合は、続行します。独自の VM を使用しており、SSH を自分で設定している場合は、現在の設定を変更しないように、この手順をスキップすることができます。

  11. SDC、SEC、CLI 自体の自動更新を有効にするように求められた場合は、これを実行して、バグ修正、パッチ、および新機能を最新の状態に保つことを推奨します。ポリシーによって自動更新が許可されない場合は、「Secure Device Connector の更新」を参照してください。

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

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

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

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

この手順では、独自の仮想マシンイメージを使用してネットワークに 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

左側のペインで [管理（Administration）] > [統合（Integrations）] > [セキュアコネクタ（Secure Connectors）] をクリックします。

ステップ 3

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

ステップ 4

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

ステップ 5

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

  • 8 GB の RAM

  • 10 GB のディスクスペース

ステップ 6

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

ステップ 7

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

ステップ 8

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

ステップ 9

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

ステップ 10

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

ステップ 11

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

（注）  

 

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

ステップ 12

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

（注）  

 

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

ステップ 13

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.

ステップ 14

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


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

ステップ 15

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.

ステップ 16

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


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

ステップ 17

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 ~]#

ステップ 18

/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 ~]#

ステップ 19

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

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

ステップ 20

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

ステップ 21

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

ステップ 22

ブートストラップデータは 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>"

ステップ 23

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

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

ステップ 24

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

ステップ 25

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 Device Connector のブートストラップ

手順

ステップ 1

左側のペインで [管理（Administration）] > [統合（Integrations）] > [セキュアコネクタ（Secure Connectors）] をクリックします。

ステップ 2

[Services] ページの [Secure Connectors] タブで、[+] アイコンをクリックし、[Secure Device Connector] を選択します。

ステップ 3

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

ステップ 4

管理者ユーザー（通常は cdo）と選択したパスワードを使用して、VM に SSH で接続します。

ステップ 5

「sudo su - sdc」コマンドを使用して sdc ユーザーに切り替えます。 

sudo su - sdc

ステップ 6

次のコマンドを使用して、新しい SDC をブートストラップします。

sdc bootstrap <paste-your-bootstrap-data-here>

ステップ 7

使用する SDC のバージョンを選択します。

SDC バージョンには 3 つのオプションがあります。

  • SDC 2024：これは、ほとんどの場合に実行を希望されるバージョンです。

  • FIPS が有効な SDC 2024：FedRamp 準拠の条件を満たす場合は、このバージョンを選択します。

  • SDC レガシー：このバージョンは機能の更新を受信しなくなったため、代わりに SDC 2024 を実行することを推奨します。

ステップ 8

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 インスタンスに接続するためのポートは、セキュリティ上の理由により公開されないことに注意してください。


（注）  

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

オンプレミス 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 を移行する場合は、次の手順に従います。

  1. こちらから新しい VM イメージをダウンロードします。

  2. 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

  3. ダウンロードした VM を展開します。

  4. 新しい VM に割り当てられた静的 IP アドレスまたは FQDN をメモします。

  5. SSH を使用して、CDO ユーザーとして新しい VM にログインします。

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

    sudo sdc host configure

    （注）  

    • 移行スクリプトのプロンプトに厳密に従ってください。このスクリプトは適切に文書化されており、手順ごとの説明で移行プロセスをガイドします。

    • 移行スクリプトの最後に、SDC が新しい VM に移行されたことを示すメッセージが表示されます。SDC の名前は、移行後も保持されます。

SDC の移行

手順：

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

  2. 次のコマンドを使用して 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

  3. 次のコマンドを実行し、プロンプトに従います。

    sudo sdc migrate now

確認：

  1. Security Cloud Control テナントにログインします。

  2. 移行先の SDC を選択して、[操作（Actions）] ペインで [ハートビートの要求（Request Heartbeat）] をクリックします。


（注）  

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

SEC の移行

手順：

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

  2. 次のコマンドを使用して 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

  3. 次のコマンドを実行し、プロンプトに従います。

    sudo sdc eventing migrate

  4. SEC の新しい IP アドレスをポイントするようにデバイスを設定するか、元のホストをシャットダウンし、新しいホストに元のホストと同じ IP アドレスを割り当てます（この場合、デバイスの更新は不要です）。

確認：

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

追加手順

古い SDC を再起動しない

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

失敗した移行を元に戻す

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

  1. 新しい VM にログインし、SDC ユーザーにスイッチします。

  2. 次のコマンドを使用して、SDC が現在新しい VM で実行されていないことを確認します。

    docker ps

  3. SDC が実行されている場合は、次のコマンドを実行します。

    sdc stop

  4. 再度 docker ps を実行して、SDC が実行を停止したことを確認します。

  5. 古い VM にログインし、次のコマンドを実行します。

    sdc migrate revert

  6. 古い SDC がアクティブで UI に表示されたら、新しい VM に戻り、次のコマンドを実行します。

    sdc delete <your-tenant-name-here>

  7. ブラウザを完全に更新し、SDC をクリックして、古いホストの IP がサイドバーに表示されていることを確認します。

    これらの手順を実行しても、新しい IP が表示される場合は、新しいヘルスチェックを要求し、ブラウザを更新して、もう一度確認してください。

  8. 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 SDC から別の SDC への ASA の移動

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

手順

ステップ 1

左側のペインで セキュリティデバイス をクリックします。

ステップ 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 を介して Security Cloud Control Firewall Management に接続するデバイスをオンボーディングすると、オンボーディング時に別の SDC を指定しない限り、デバイスはテナントのデフォルトの SDC に関連付けられます。

[セキュアコネクタ（Secure Connectors）] ページで、デフォルトで選択される SDC を指定できます。

手順

ステップ 1

左側のペインで、[管理（Administration）] > [セキュアコネクタ（Secure Connectors）] を選択します。

ステップ 2

デフォルトにする SDC を選択します。

ステップ 3

[操作（Actions）] ウィンドウで、[デフォルトにする（Make Default）] をクリックします。[デフォルトにする（Make Default）] アクションが表示されない場合、その SDC はすでにデフォルトの SDC になっています。

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 のセキュリティ保護と最適な機能が維持されるように、関連するセキュリティパッチを定期的に確認して適用することを強くお勧めします。

単一のテナントで複数の Secure Device Connector を使用

テナントにインストールできる SDC の数に制限はありません。複数の SDC により、より多くのデバイスを管理し、それらのデバイスを同じ Security Cloud Control Firewall Management テナントに配置したまま、コネクタを異なるネットワークセグメントに配置できます。2 つ目以降の SDC を展開する手順は、最初の SDC の手順と同じです。最初の SDC 名前にはテナント名と数字の「1」が含まれています。追加の各 SDC には、順番に番号が付けられます。

  • 2 番目以降の SDC を展開する手順は、最初の SDC を展開する手順と同じです。

  • テナントの最初の SDC には、テナントの名前と番号 1 が組み込まれています。追加の各 SDC には、順番に番号が付けられます。

同じ Secure Device Connector を介するデバイスを検索

同じ SDC を介して接続するデバイスを検索するには、次の手順を実行します。

手順

ステップ 1

左側のペインで セキュリティデバイス をクリックします。

ステップ 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 で管理しているすべてのデバイスとサービスを表示します。

Secure Device Connector を削除

SDC の削除は元に戻せません。削除後、新しい SDC をインストールしてデバイスを再接続するまで、その SDC に接続されていたデバイスは管理できません。デバイスを再接続する場合、管理者のログイン情報を再度入力する必要がある場合があります。

SDC を削除する前に、接続されているデバイスを別の SDC に移動するか、Security Cloud Control Firewall Management から削除してください。

手順

ステップ 1

削除する SDC に接続されているデバイスをすべて削除します。この操作は、次の 2 つの方法で実行できます。

  • 一部のデバイスを別の SDC に移動するか、SDC から完全に切り離します。詳細については、次のトピックを参照してください。

  • 削除する SDC に接続されているすべてのデバイスを Security Cloud Control から削除します。

    1. SDC で使用されるすべてのデバイスを特定するには、「同一 SDC を使用した Security Cloud Control に接続するすべてのデバイスを見つける」を参照してください。

    2. [セキュリティデバイス（Security Devices）] ページで、識別したすべてのデバイスを選択します。

    3. [デバイス アクション（Device Actions）] ウィンドウで [削除（Remove）] をクリックし、[OK] をクリックして操作を確定します。

ステップ 2

左側のペインで [管理（Administration）] > [統合（Integrations）] > [セキュアコネクタ（Secure Connectors）] をクリックします。

ステップ 3

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

ステップ 4

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

ステップ 5

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

警告

 

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

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

  • ご質問や懸念事項がある場合は、[キャンセル（Cancel）] をクリックして、Security Cloud Control サポートにお問い合わせください。

  • 続行するには、下のテキストボックスに <sdc_name> を入力して、[OK] をクリックします。

ステップ 6

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

ステップ 7

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

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

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

* amqplib *

amqplib copyright (c) 2013, 2014

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 *

Copyright (c) 2010-2016 Caolan McMahon

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）

Copyright (c) 2013-2015 Petka Antonov

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.

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

* cheerio *

Copyright (c) 2012 Matt Mueller <mattmuelle@gmail.com>

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)

Copyright (c) 2015 Lloyd Brookes <75pound@gmail.com>

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 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,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.

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

* ip *

This software is licensed under the MIT License.

Copyright Fedor Indutny, 2012.

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 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,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.

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

* json-buffer *

Copyright (c) 2013 Dominic Tarr

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

Copyright (c) Isaac Z. Schlueter and Contributors

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 *

Copyright JS Foundation and other contributors <https://js.foundation/>

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 *

Copyright 2015 Gareth Jones (with contributions from many other people)

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 *

Copyright 2010 James Halliday (mail@substack.net)

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

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.

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

* node-forge *

New BSD License (3-clause)

Copyright (c) 2010, Digital Bazaar, Inc.

All rights reserved.

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

Copyright (c) Isaac Z. Schlueter and Contributors

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.

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

* uuid *

Copyright (c) 2010-2012 Robert Kieffer

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

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

* validator *

Copyright (c) 2016 Chris O'Hara <cohara87@gmail.com>

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

Copyright (c) 2011 Brian Cavalier

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 Firewall Management でサポートされるデバイス、ソフトウェア、ハードウェア

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

このセクションでは、Security Cloud Control Firewall Management でファイアウォール、クラウド、SD-WAN、Cisco IOS、Cisco Umbrella、および管理センターの統合を管理するためにサポートされているデバイスタイプ、ソフトウェア、ハードウェア、および制約事項について説明します。

サポートの範囲

Security Cloud Control Firewall Management は、複数のセキュリティ プラットフォームにおけるセキュリティポリシーとデバイス設定を管理できるクラウドベースの管理ソリューションです。この送信元では、次の管理領域のサポートが特定されています。

  • 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 Firewall Management ドキュメントでは、Security Cloud Control Firewall Management がサポートするデバイス、ソフトウェア、およびハードウェアが示されています。ドキュメントにソフトウェアのバージョンまたはデバイスタイプのサポートが明示的に記載されていない場合、Security Cloud Control Firewall Management はそれをサポートしません。

Cisco Secure Firewall ASA

Cisco 適応型セキュリティアプライアンス（ASA）は、ファイアウォール、VPN、および侵入防御機能を統合したセキュリティデバイスです。Security Cloud Control は、ASA デバイスの管理をサポートし、設定管理を合理化する機能と、ネットワーク インフラストラクチャ全体で適合規格を確実に遵守する機能を提供します。

Cisco Secure Firewall Threat Defense

Cisco Cisco Secure Firewall Threat Defense は、従来のファイアウォール機能と高度な脅威防御機能を統合します。侵入防御、アプリケーション制御、URL フィルタリング、高度なマルウェア防御などを含む包括的なセキュリティ機能を提供します。

Cisco Secure Firewall Threat Defense デバイスは、Cisco ASA ハードウェアアプライアンス、シスコのファイアウォール ハードウェア アプライアンス、および仮想環境にデプロイできます。Cisco Firewall Management Center、Firewall Device Manager などの管理インターフェイスを使用して、脅威防御デバイスを管理できます。

Firewall Threat Defense は、従来のファイアウォール機能と高度な脅威防御機能を統合します。侵入防御、アプリケーション制御、URL フィルタリング、高度なマルウェア防御などを含む包括的なセキュリティ機能を提供します。FTD は、ASA ハードウェアアプライアンス、Cisco ファイアウォール ハードウェア アプライアンス、および仮想環境に展開できます。Threat Defense デバイスの管理は、Cisco Firewall Management Center、Security Cloud Control Firewall Management、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 は、セキュアな統合を確立し、セキュリティデバイスを検出し、一元化されたポリシー管理を有効にすることで、オンプレミスの Firewall Management Center の管理を簡素化します。ファイアウォールルール、VPN 設定、侵入防御ポリシーなどのセキュリティポリシーを、FMC 下にあるすべてのデバイスにわたって効率的に管理および展開できます。

Cisco Meraki MX

Cisco Meraki MX アプライアンスは、分散型展開用に設計されたエンタープライズグレード セキュリティおよび SD-WAN の次世代ファイアウォール アプライアンスです。Security Cloud Control Firewall Management は、Cisco Meraki MX デバイス上のレイヤ 3 ネットワークルールの管理をサポートします。

Cisco Meraki デバイスを Security Cloud Control Firewall Management にオンボーディングすると、Security Cloud Control Firewall Management は Cisco Meraki ダッシュボードと通信してそのデバイスを管理します。Security Cloud Control Firewall Management は設定要求を Cisco Meraki ダッシュボードに転送し、Cisco Meraki ダッシュボードは新しい設定をデバイスに適用します。

Cisco Meraki MX をサポートする Security Cloud Control Firewall Management の主な機能には、ポリシーの一元管理、バックアップと復元、モニタリングとレポート、コンプライアンスチェック、自動化機能などがあります。

Cisco IOS デバイス

Cisco IOS ソフトウェアは、ルーティング、スイッチング、およびその他のネットワークプロトコルなどのネットワーク機能を管理します。Cisco IOS には、Cisco ネットワークデバイスを設定および維持するための機能とコマンドが含まれています。

Cisco Umbrella

Security Cloud Control Firewall Management は、Cisco Umbrella ASA の統合などの統合を介して Cisco Umbrella を管理します。この統合により、管理者はインターフェイスごとのポリシーを使用して、Cisco Adaptive Security Appliance（ASA）デバイスを Cisco Umbrella 設定に含めることができます。

この統合により、ASA デバイスが DNS クエリを Cisco Umbrella にリダイレクトすることが可能になり、Cisco Umbrella の DNS セキュリティ、Web フィルタリング、および脅威インテリジェンス機能を活用できます。

AWS セキュリティグループ

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

ASA サポートの詳細

Security Cloud Control Firewall Management ASA のサポートには次の制約事項があります。

  • Security Cloud Control Firewall Management は、ASAv インスタンスを含む、現在サポートされているコードバージョンを実行するすべての ASA プラットフォームを管理できます。

  • Security Cloud Control Firewall Management は ASA サービスモジュール（ASASM）をサポートしていません。

  • Security Cloud Control Firewall Management ではサポート終了の ASA コードバージョンはテストされていないため、実稼働での使用は推奨されません。

  • 最適な結果が得られるように、現在サポートされている ASA コードバージョンを使用することを推奨します。

  • ASA 8.3 は、新しいポリシービューではサポートされていません。

  • Security Cloud Control Firewall Management は、ASA とは異なるオペレーティングシステムを実行するため、 ASA FirePOWER モジュールを管理しません。ASA FirePOWERモジュールを、Cisco Secure Firewall Management Center または ASDM を使用して個別に管理します。

  • サポート終了コードとハードウェアは Security Cloud Control Firewall Management で引き続き動作する場合があります。サポート終了コードおよびハードウェアは Security Cloud Control Firewall Management のテストの一部ではないため、サポート終了のソフトウェアおよびハードウェアでの正しい動作は保証されません。

    シスコの「推奨リリース」または「ゴールドスター」バージョンについては、「version download」ページを参照してください。

  • Cisco ASA バージョン 8.x、9.1、および 9.2 は、管理プレーンで TLS 1.2 をサポートしておらず、Cisco ASA ソフトウェアの安全でない管理方法と見なされます。

ASA、ASDM、およびハードウェア互換性の詳細については、「Cisco Secure Firewall ASA Compatibility」 [英語] ガイドを参照してください。

クラウドデバイスのサポートの詳細

次の表で、クラウドベースのデバイスのソフトウェアとデバイスタイプのサポートについて説明します。次の表の関連リンクで、デバイスタイプのオンボーディングと機能や特長に関する詳細な情報を確認してください。

デバイスタイプ

注記

Google Cloud Platform

Google Cloud Platform（GCP）は、GCP コンソールを介して更新を受信します。プラットフォームと利用可能なサービスの詳細については、Google Cloud のドキュメントを参照してください。

Microsoft Azure

Azure は、Azure コンソールを介して更新を受信します。プラットフォームと利用可能なサービスの詳細については、Azure のドキュメントを参照してください。

Secure Firewall ASA の導入準備

この章では、Secure Firewall ASA をオンボードするために使用できるさまざまな方法について説明します。

ASA デバイスの Security Cloud Control への導入準備

この手順を使用して、ASA モデルではなく単一のライブ ASA デバイスを Security Cloud Control にオンボーディングします。複数の ASA を一度にオンボーディングする場合は、「一括での ASA のオンボード」を参照してください。

始める前に

デバイスの前提条件

  • 直接クラウド接続のインバウンドアクセスを許可を確認してください。

  • デバイスは、バージョン 8.4 以降を実行している必要があります。


    （注）  

    TLS 1.2 は、バージョン 9.3(2) まで ASA 管理プレーンでは使用できませんでした。バージョン 9.3(2) では、Security Cloud Control へのオンボーディングにローカル SDC が必要です。

  • ASA の実行コンフィギュレーション ファイルは 4.5 MB 未満である必要があります。

    実行コンフィギュレーション ファイルのサイズを確認するには、「ASA 実行設定サイズの確認」を参照してください。

  • IP アドレッシング：各 ASA、ASAv、または ASA セキュリティコンテキストには一意の IP アドレスが必要であり、SDC は管理トラフィックを受信するように設定されたインターフェイスでその IP アドレスに接続する必要があります。

証明書の前提条件

ASA デバイスに互換性のある証明書が存在しない場合、デバイスのオンボーディングが失敗する可能性があります。次の要件が満たされていることを確認します。

  • デバイスで TLS バージョン 1.0 以降を使用している。

  • デバイスにより提示される証明書が有効期限内であり、発効日が過去の日付である（すなわち、すでに有効になっており、後日に有効化されるようにスケジュールされていない）。

  • 証明書は、SHA-256 証明書であること。SHA1 証明書は受け入れられません。

  • 次のいずれかが該当すること。

    • デバイスは自己署名証明書を使用し、その証明書は認可されたユーザーにより信頼された最新の証明書と同じである。

    • デバイスは、信頼できる認証局（CA）が署名した証明書を使用し、提示されたリーフ証明書から関連 CA にリンクしている証明書チェーンを形成している。

オンボーディングプロセス中に証明書エラーが発生した場合は、詳細について証明書エラーのため ASA の導入準備ができないを参照してください。

オープン SSL 暗号の前提条件

互換性のある SSL 暗号スイートがデバイスにない場合、デバイスは Secure Device Connector（SDC）と正常に通信できません。次のいずれかの暗号スイートを使用します。

  • ECDHE-RSA-AES128-GCM-SHA256

  • ECDHE-ECDSA-AES128-GCM-SHA256

  • ECDHE-RSA-AES256-GCM-SHA384

  • ECDHE-ECDSA-AES256-GCM-SHA384

  • DHE-RSA-AES128-GCM-SHA256

  • ECDHE-RSA-AES128-SHA256

  • DHE-RSA-AES128-SHA256

  • ECDHE-RSA-AES256-SHA384

  • DHE-RSA-AES256-SHA384

  • ECDHE-RSA-AES256-SHA256

  • DHE-RSA-AES256-SHA256

ASA で使用する暗号スイートがこのリストにない場合、SDC はそれをサポートしていないため、ASA で暗号スイートを更新する必要があります。

手順

ステップ 1

左側のペインで セキュリティデバイス をクリックします。

ステップ 2

[Onboard device or service]（）アイコンをクリックします。

ステップ 3

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

ステップ 4

[デバイスの特定（Locate Device）] ステップで、次の手順を実行します。

  1. [Secure Device Connector] ボタンをクリックし、ネットワークにインストールされている Secure Device Connector を選択します。SDC を使用しない場合、Security Cloud Control は Cloud Connector を使用して ASA に接続できます。どちらを選択するかは、Security Cloud Control を管理対象デバイスに接続する方法によって異なります。

  2. デバイスに名前を付けます。

  3. デバイスまたはサービスのロケーション（IP アドレス、FQDN、または URL）を入力します。デフォルトのポートは 443 です。

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

ステップ 5

[ログイン情報（Credentials）] ステップで、Security Cloud Control がデバイスへの接続に使用する、ASA 管理者または同様の最高特権の ASA ユーザーのユーザー名とパスワードを入力し、[次へ（Next）] をクリックします。

ステップ 6

（オプション） [完了（Done）] ステップで、デバイスのラベルを入力します。このラベルでデバイスのリストをフィルタリングできます。詳細については、『Labels and Label Groups』を参照してください。

ステップ 7

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

（注）  

 

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

ASA デバイスの高可用性ペアの Security Cloud Control Firewall Management に対する導入準備

プライマリ ASA のみを Security Cloud Control Firewall Management にオンボードします。セカンダリ ASA は、フェールオーバーリンクを介して自動的に管理され、別個のオンボーディングプロセスは必要ありません。ASA デバイスの Security Cloud Control への導入準備 を参照してください。

マルチコンテキストモードでの Security Cloud Control に対する ASA の導入準備

マルチコンテキストモードについて

物理アプライアンスにインストールされている単一の ASA を、コンテキストと呼ばれる複数の論理デバイスに分割できます。マルチコンテキストモードで設定された ASA で使用される設定には、次の 3 種類があります。

  • セキュリティコンテキスト

  • 管理コンテキスト

  • システム設定

セキュリティ コンテキストについて

各セキュリティコンテキストは、独自のセキュリティポリシー、インターフェイス、および管理者を持つ独立したデバイスとして機能します。複数のセキュリティコンテキストは、複数のスタンドアロンデバイスを持つことに似ています。セキュリティコンテキストは、プライベート クラウド インフラストラクチャにインストールされた仮想マシンイメージという意味での仮想 ASA ではありません。セキュリティコンテキストは、ハードウェアアプライアンスにインストールされた ASA で設定されます。各コンテキストは、そのアプライアンスの物理インターフェイスで設定されます。

マルチコンテキストモードの詳細については、ASA CLI および ASDM のコンフィギュレーション ガイド [英語] を参照してください。

Security Cloud Control は、各セキュリティコンテキストを個別の ASA としてオンボードし、個別の ASA であるかのように管理します。

管理コンテキストについて

管理コンテキストはセキュリティコンテキストと似ていますが、管理コンテキストにログインしたユーザーは、システム管理者権限を持つので、システムコンテキストや他のすべてのコンテキストにアクセスできる点が異なります。管理コンテキストは制限されていないため、通常のコンテキストとして使用できます。ただし、管理コンテキストにログインすると、すべてのコンテキストへの管理者特権が付与されるため、場合によっては、管理コンテキストへのアクセスを適切なユーザーに制限する必要があります。

Security Cloud Control は、各管理コンテキストを個別の ASA としてオンボーディングし、個別の ASA であるかのように管理します。Security Cloud Control は、アプライアンスの ASA および ASDM ソフトウェアをアップグレードするときにも管理コンテキストを使用します。

システムの設定について

システム管理者は、各コンテキスト コンフィギュレーションの場所、割り当てられたインターフェイス、およびその他のコンテキスト操作パラメータをシステム コンフィギュレーションに設定することで、コンテキストを追加および管理します。このコンフィギュレーションは、シングル モードのコンフィギュレーション同様、スタートアップ コンフィギュレーションです。システム コンフィギュレーションは、ASA の基本設定を識別します。システム コンフィギュレーションには、ネットワーク インターフェイスやネットワーク設定は含まれません。その代わりに、ネットワーク リソースにアクセスする必要が生じたときに（サーバーからコンテキストをダウンロードするなど）、システムは管理コンテキストとして指定されているコンテキストのいずれかを使用します。

Security Cloud Control はシステム設定をオンボードしません。

セキュリティおよび管理コンテキストのオンボーディングの前提条件

セキュリティおよび管理コンテキストをオンボーディングするための前提条件は、他の ASA をオンボーディングする場合と同じです。前提条件のリストについては、ASA デバイスの Security Cloud Control への導入準備を参照してください。

マルチコンテキストモードで ASA をサポートする Cisco アプライアンスについては、実行している ASA ソフトウェアバージョンの CLI ブック 1：Cisco ASA シリーズ CLI コンフィギュレーション ガイド（一般的な操作）[英語] の「Multiple Context Mode」の章を参照してください。

シングル コンテキスト ファイアウォールとして実行されている ASA、およびマルチコンテキスト ファイアウォールの管理コンテキストでは、ASDM および Security Cloud Control アクセスにさまざまなポート番号を使用できます。ただし、セキュリティコンテキストの場合、ASDM および Security Cloud Control アクセスポートはポート 443 に固定されています。これは ASA の制限です。

ASA セキュリティおよび管理コンテキストのオンボーディング

セキュリティコンテキストまたは管理コンテキストをオンボーディングする方法は、他の ASA をオンボーディングする場合と同じです。オンボーディングの手順については、ASA デバイスの Security Cloud Control への導入準備または複数の ASA の Security Cloud Control に対する導入準備を参照してください。

セキュリティコンテキストのアップグレード

Security Cloud Control は、マルチコンテキスト ASA の各セキュリティおよび管理コンテキストを個別の ASA として扱い、個別にオンボーディングします。ただし、マルチコンテキスト ASA のすべてのセキュリティおよび管理コンテキストは、アプライアンスにインストールされている同じバージョンの ASA ソフトウェアを実行します。

ASA のセキュリティコンテキストで使用される ASA および ASDM のバージョンをアップグレードするには、管理コンテキストをオンボードし、そのコンテキストでアップグレードを実行します。

詳細については、単一 ASA 上の ASA と ASDM イメージのアップグレードまたはSecurity Cloud Control での ASA と ASDM の一括アップグレード Security Cloud Control での ASA と ASDM の一括アップグレードを参照してください。

複数の ASA の Security Cloud Control に対する導入準備

Security Cloud Control を使用すると、.csv ファイルですべての ASA に必要な情報を提供することで、ASA を一括でオンボードできます。ASA がオンボーディングされているときに、フィルタペインを使用して、キューに入っている、ロードされている、完了している、または失敗したオンボーディングの試行を表示できます。

始める前に

  • 直接クラウド接続のインバウンドアクセスを許可を確認してください。

  • オンボードする ASA の接続情報を含む .csv ファイルを準備します。1 つの ASA に関する情報を独自の行に追加します。行の先頭に # を使用して、コメントを示すことができます。

    • ASA の場所（IP アドレスまたは FQDN）

    • ASA 管理者ユーザー名

    • ASA 管理者パスワード

    • （任意）Security Cloud Control のデバイス名

    • SDCName フィールドで、Security Cloud Control を ASA に接続するために使用するネットワーク内の Secure Device Connector（SDC）の名前を指定します。SDC を使用して ASA を Security Cloud Control に接続しない場合は、「none」と入力することもできます。デバイスをオンボードするときに、SDCName フィールドに「none」と指定すると、Cloud Connector を使用して ASA がオンボードされます。Cloud Connector を使用すると、SDC をインストールせずにデバイスを Security Cloud Control に接続できます。どちらを選択するかは、Security Cloud Control を管理対象デバイスに接続する方法によって異なります。

    • （任意）Security Cloud Control のデバイスラベル

    • ラベルを 1 つ追加するには、ラベル名を最後の CSV フィールドに追加します。

    • デバイスに複数のラベルを追加するには、値を引用符で囲みます。例：alpha,beta,gamma。

    • カテゴリと選択肢のラベルを追加するには、2 つの値をコロン（:）で区切ります。例：Rack:50。

構成ファイルの例：


#Location,Username,Password,DeviceName,SDCName,DeviceLabel 
192.168.3.2,admin,CDO123!,ASA3,sdc1,"HA-1,Rack:50" 
192.168.4.2,admin,CDO123!,ASA4,sdc1,"HA-1,Rack:50" 
ASA2.example.com,admin,CDO123!,ASA2,none,Rack:51 
asav.virtual.io,admin,CDO123!,ASA-virtual,sdc3,Test

注意    

Security Cloud Control は .csv ファイル内のデータを検証しないため、エントリの正確性を保証する必要があります。

手順

ステップ 1

左側のペインで セキュリティデバイス をクリックします。

ステップ 2

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

ステップ 3

[オンボーディング（Onboarding）] ページで、[複数のASA（Multiple ASAs）] タイルをクリックします。

ステップ 4

[参照（Browse）] をクリックして、ASA エントリを含む .csv ファイルを見つけます。指定したデバイスは、オンボーディングの準備ができている [ASA一括オンボーディング（ASA Bulk Onboarding）] テーブルのキューに入れられました。

注意    

 

オンボーディングプロセスが完了するまで、[ASA一括オンボーディング（ASA Bulk Onboarding）] ページから移動しないでください。移動すると、オンボーディングプロセスが停止します。

ステップ 5

[開始（Start）] をクリックします。[ASA一括オンボーディング（ASA Bulk Onboarding）] テーブルのステータス列に、オンボーディングプロセスの進行状況が表示されます。デバイスが正常にオンボーディングされると、ステータスが [完了（Complete）] に変わります。

次のタスク

一括オンボーディングを一時停止し、後で再開する必要がある場合は、 複数の ASA のオンボーディングの一時停止と再開を参照してください。

.

複数の ASA のオンボーディングの一時停止と再開

オンボーディングプロセスを一時停止する必要がある場合は、[一時停止（Pause）] をクリックします。Security Cloud Control は、オンボーディングを開始したデバイスのオンボーディングを終了します。一括オンボーディングプロセスを再開するには、[開始（Start）] をクリックします。Security Cloud Control は、キューに入っている次のデバイスのオンボーディングを開始します。

[一時停止（Pause）] をクリックしてこのページから移動した場合は、このページに戻って、最初からバルクオンボーディング手順を最初から再度実行する必要があります。ただし、Security Cloud Control はすでにオンボーディングされたデバイスを認識し、このデバイスを新しいオンボーディング試行で「重複」としてマークし、リストをすばやく移動して、キューに入ったデバイスをオンボーディングします。

Cisco ASA モデルの作成と Security Cloud Control へのインポート

手順

ステップ 1

左側のペインで セキュリティデバイス をクリックします。

ステップ 2

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

ステップ 3

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

ステップ 4

ASA デバイスを選択し、左側のペインの [管理] で、[設定（Configuration）] をクリックします。

ステップ 5

[ダウンロード（Download）] をクリックしてデバイス設定をローカルコンピュータにダウンロードします。

ASA 設定のインポート

注意：導入準備する ASA 実行設定ファイルは 4.5 MB 未満である必要があります。導入準備する前に、設定ファイルのサイズを確認してください。

手順

ステップ 1

左側のペインで セキュリティデバイス をクリックします。

ステップ 2

青いプラス（）ボタンをクリックして、設定をインポートします。

ステップ 3

[オフライン管理用設定のインポート（Import configuration for offline management）] をクリックします。

ステップ 4

[デバイスタイプ（Device Tipe）] で [ASA] を選択します。

ステップ 5

[参照（Browse）] をクリックし、アップロードする構成ファイル（テキスト形式）を選択します。

ステップ 6

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

ステップ 7

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

（注）  

 

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

オフラインデバイス管理用の設定のインポート

オフライン管理用にデバイスの設定をインポートすると、ネットワーク内の稼働中のデバイスを操作することなく、デバイスの設定を確認して最適化できます。これらのアップロードされた設定ファイルは Security Cloud Control では「モデル」とも呼ばれます。モデルは、ポリシーの確認、計画、および再利用に使用できるデバイス設定のコピーを表します。

次のデバイスタイプの設定を Security Cloud Control にインポートできます。

  • 適応型セキュリティアプライアンス（ASA）：ASA 設定ファイルをアップロードして、オフラインで確認および管理できる ASA モデルを作成できます。詳細については、 「ASAモデルの作成およびインポート」を参照してください。

  • アグリゲーション サービス ルータ（ASR）や統合サービスルータ（ISR）などの Cisco IOS デバイス：テキストベースの実行コンフィギュレーション ファイルをアップロードして、オフライン分析と再利用のための IOS モデルを作成できます。

構成ファイルをインポートして処理すると、そのモデルが [セキュリティデバイス（Security Devices）] リストに表示されます。このリストでは、Security Cloud Control でサポートされている他のデバイスと同様に、ラベル付け、確認、および管理ができます。

Security Cloud Control での ASA と ASDM のアップグレードの前提条件

Security Cloud Control では、ASA および ASDM イメージのアップグレードに役立つウィザードが提供されます。個別の ASA、複数の ASA、アクティブ/スタンバイ構成の ASA、およびシングルコンテキストモードまたはマルチコンテキストモードで実行されている ASA にインストールされているイメージが対象です。

Security Cloud Control は、アップグレード可能な ASA および ASDM イメージのリポジトリを保持します。Security Cloud Control のイメージリポジトリからアップグレードイメージを選択すると、Security Cloud Control は必要なすべてのアップグレード手順をバックグラウンドで実行します。このウィザードに従って、互換性のある ASA ソフトウェアおよび ASDM イメージを選択してインストールし、デバイスを再起動してアップグレードを完了するプロセスを実行できます。Security Cloud Control で選択したイメージが ASA にコピーされ、 インストールされていることを検証することで、アップグレードプロセスを保護します。Security Cloud Control は ASA バイナリのインベントリを定期的に確認し、最新の ASA および ASDM イメージが使用可能になったらリポジトリに追加します。これは、ASA にインターネットへのアウトバウンドアクセスがある場合に最適なオプションです。

Security Cloud Control のイメージリポジトリには、一般的に利用可能な（GA）イメージのみが含まれています。リストに特定の GA イメージがない場合は、[サポートに問い合わせ（Contact Support）] ページから Cisco TAC または電子メールサポートにお問い合わせください。確立されたサポートチケット SLA によってリクエストを処理し、リストにない GA イメージをアップロードします。

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

すべての ASA の構成の前提条件

  • ASA で DNS を有効にする必要があります。

  • Security Cloud Control のイメージリポジトリからアップグレードイメージを使用する場合、ASA はインターネットにアクセスできる必要があります。

  • ASA とリポジトリ FQDN 間の HTTPS 接続を確認します。

  • ASA は Security Cloud Control に正常にオンボードされている必要があります。

  • ASA で Security Cloud Control に同期している必要があります。

  • ASA はオンラインになっている必要があります。

  • カスタム URL アップグレードの場合：

Firepower 1000 および Firepower 2100 シリーズ デバイスの構成の前提条件

ASA を実行する Firepower 4100 および Firepower 9300 シリーズ デバイス

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

アップグレードのガイドライン

  • Security Cloud Control は、アクティブ/スタンバイの「フェールオーバー」ペアとして設定された ASA をアップグレードできます。Security Cloud Control は、アクティブ/アクティブの「クラスタ化」ペアで設定された ASA をアップグレードできません。

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

アップグレード可能な ASA および ASDM の最小バージョン：

  • ASA：ASA 9.1.2

  • ASDM：最小バージョンなし

サポート対象のハードウェアバージョン

Security Cloud Control での ASA と ASDM の一括アップグレード

手順

ステップ 1

ASA および ASDM イメージのアップグレードに関するアップグレード要件と重要な情報については、「ASA と ASDM のアップグレードの前提条件」を参照してください。

（注）  

 

ASA 1000 または 2000 シリーズデバイスをアップグレードする場合は、「1000 および 2000 シリーズの設定の前提条件」を必ずお読みください。

ステップ 2

（任意）左側のペインで セキュリティデバイス をクリックします。

ステップ 3

変更要求ラベルを作成して、このアクションによってアップグレードされたデバイスを変更ログで識別します。

ステップ 4

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

ステップ 5

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

ステップ 6

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

ステップ 7

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

ステップ 8

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

ステップ 9

ステップ 1 で、[Security Cloud Controlイメージリポジトリの使用（Use CDO Image Repository）] をクリックしてアップグレードする ASA ソフトウェアイメージを選択し、[続行（Continue）] をクリックします。

このリストは、選択したソフトウェアバージョンにアップグレードできる、選択した ASA の数を示しています。次の例では、すべてのデバイスをバージョン 9.9(1.2) にアップグレードでき、2 つのデバイスを 9.8(2) にアップグレードでき、1 つのデバイスを 9.6(1) にアップグレードできます。

選択したソフトウェアバージョンのいずれかが、選択したいずれのデバイスとも互換性がない場合、Security Cloud Control は警告を表示します。次の例では、Security Cloud Control は 10.82.109.176 デバイスを、すでに実行されているバージョンより前のバージョンにアップグレードできません。

ステップ 10

ステップ 2 で、アップグレードする ASDM イメージを選択します。アップグレード可能な ASA と互換性のある ASDM の選択肢のみが表示されます。

ステップ 11

ステップ 3 で、選択内容を確認し、ASA へのイメージのダウンロードのみを実行するか、あるいはイメージをコピーしてインストールしデバイスを再起動するかを決定します。

ステップ 12

準備ができたら、[アップグレードの実行（Perform Upgrade）] をクリックします。

（注）  

 

アップグレードが失敗すると、Security Cloud Control からメッセージが表示されます。アップグレードの失敗は、多くの場合、ネットワークの問題によって ASA イメージと ASDM イメージの ASA への転送が阻害されることが原因です。

ステップ 13

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

ステップ 14

（マルチコンテキストモードの場合）管理コンテキストとセキュリティコンテキストが起動すると、セキュリティコンテキストに「新しい証明書が検出されました（New certificate detected）」というメッセージが表示されることがあります。このメッセージが表示された場合は、すべてのセキュリティコンテキストの証明書を受け入れます。アップグレードによって生じる他のすべての変更も受け入れます。

ステップ 15

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

ステップ 16

変更リクエストラベルを作成してアクティブ化した場合は、他の設定変更を誤ってこのイベントに関連付けないように、忘れずにラベルをクリアしてください。

独自のリポジトリからのイメージを含む複数の ASA のアップグレード

手順

ステップ 1

ASA および ASDM イメージのアップグレードに関するアップグレード要件と重要な情報については、「ASA と ASDM のアップグレードの前提条件」を参照してください。

ステップ 2

（任意）左側のペインで セキュリティデバイス をクリックします。

ステップ 3

変更要求ラベルを作成して、このアクションによってアップグレードされたデバイスを変更ログで識別します。

ステップ 4

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

ステップ 5

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

ステップ 6

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

ステップ 7

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

ステップ 8

手順 1 で、[イメージURLの指定（Specify Image URL）] をクリックし、アップグレードする ASA イメージを [ソフトウェアイメージURL（Software Image URL）] フィールドで選択して、[続行（Continue）] をクリックします。URL シンタックスの詳細については、「カスタム URL のアップグレード」を参照してください。

（注）  

 

下の図は、[ソフトウェアイメージURL（Software Image URL）] フィールドに表示された HTTPS URL を示しています。FTP、TFTP、HTTP、HTTPS、SCP、および SMB のいずれかのプロトコルを使用して、リポジトリからイメージを取得できます。URL シンタックスの詳細については、「カスタム URL のアップグレード」を参照してください。

ステップ 9

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

ステップ 10

ステップ 3 で、選択内容を確認し、ASA へのイメージのダウンロードのみを実行するか、あるいはイメージをコピーしてインストールしデバイスを再起動するかを決定します。

ステップ 11

準備ができたら、[アップグレードの実行（Perform Upgrade）] をクリックします。

（注）  

 

アップグレードが失敗すると、Security Cloud Control からメッセージが表示されます。アップグレードの失敗は、多くの場合、ネットワークの問題によって ASA イメージと ASDM イメージの ASA への転送が阻害されることが原因です。

ステップ 12

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

ステップ 13

（マルチコンテキストモードの場合）管理コンテキストとセキュリティコンテキストが起動すると、セキュリティコンテキストに「新しい証明書が検出されました（New certificate detected）」というメッセージが表示されることがあります。このメッセージが表示された場合は、すべてのセキュリティコンテキストの証明書を受け入れます。アップグレードによって生じる他のすべての変更も受け入れます。

ステップ 14

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

ステップ 15

変更リクエストラベルを作成してアクティブ化した場合は、他の設定変更を誤ってこのイベントに関連付けないように、忘れずにラベルをクリアしてください。
次のタスク

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

  • [Security Devices] ページを開き、テーブルの [Configuration Status] 列を表示して、アップグレードのバッチの進行状況を監視することもできます。

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

単一 ASA 上の ASA と ASDM イメージのアップグレード

単一の ASA 上で ASA および ASDM イメージをアップグレードするには、次の手順に従います。

手順

ステップ 1

ASA および ASDM イメージのアップグレードに関するアップグレード要件と重要な情報については、「ASA と ASDM のアップグレードの前提条件」を参照してください。

（注）  

 

ASA 1000 または 2000 シリーズデバイスをアップグレードする場合は、「1000 および 2000 シリーズの設定の前提条件」を必ずお読みください。

ステップ 2

左側のペインで セキュリティデバイス をクリックします。

ステップ 3

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

ステップ 4

（オプション）変更要求ラベルを作成して、このアクションによってアップグレードされたデバイスを変更ログで識別します。

ステップ 5

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

ステップ 6

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

ステップ 7

[デバイスのアップグレード（Device Upgrade）] ページで、ウィザードに表示される指示に従います。

  1. ステップ 1 で、[Security Cloud Controlイメージリポジトリの使用（Use CDO Image Repository）] をクリックしてアップグレードする ASA ソフトウェアイメージを選択し、[続行（Continue）] をクリックします。

    （注）  

     

    ASA および ASDM を独自のリポジトリに保存されたイメージにアップグレードする場合、[メージURLの指定（Specify Image URL）] を選択して、[ソフトウェアイメージのURL（Software Image URL）] フィールドに ASA または ASDM イメージの URL を入力します。FTP、TFTP、HTTP、HTTPS、SCP、および SMB のいずれかのプロトコルを使用して、リポジトリからイメージを取得できます。URL シンタックスの詳細については、「カスタム URL のアップグレード」を参照してください。

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

  2. ステップ 2 で、アップグレードする ASDM イメージを選択します。アップグレード可能な ASA と互換性のある ASDM の選択肢のみが表示されます。

  3. ステップ 3 で、選択内容を確認し、ASA へのイメージのダウンロードのみを実行するか、あるいはイメージをコピーしてインストールしデバイスを再起動するかを決定します。

ステップ 8

準備ができたら、[アップグレードの実行（Perform Upgrade）] をクリックします。

ステップ 9

（マルチコンテキストモードの場合）管理コンテキストとセキュリティコンテキストが起動すると、セキュリティコンテキストに「新しい証明書が検出されました（New certificate detected）」というメッセージが表示されることがあります。このメッセージが表示された場合は、すべてのセキュリティコンテキストの証明書を受け入れます。アップグレードによって生じる他のすべての変更も受け入れます。デモを確認しますか？この手順のスクリーンキャストをご覧ください。

次のタスク

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

  • アップグレードするイメージを選択した後で気が変わった場合は、ソフトウェアイメージに関連付けられている [アップグレードをスキップ（Skip Upgrade）] チェックボックスをオンにします。イメージはデバイスにコピーされず、デバイスがイメージでアップグレードされることもありません。

  • アップグレードの実行手順で、イメージを ASA にコピーすることだけを選択した場合は、後で [デバイスのアップグレード（Device Upgrade）] ページに戻り、[今すぐアップグレード（Upgrade Now）] をクリックしてアップグレードを実行できます。コピータスクが完了すると、[セキュリティデバイス（Security Devices）] ページにそのデバイスの「アップグレードの準備ができました」というメッセージが表示されます。

  • イメージのコピー、インストール、デバイスの再起動のプロセス中は、デバイスでアクションを実行できません。イメージをインストールしてから再起動するデバイスは、[セキュリティデバイス（Security Devices）] ページで「アップグレード中」と表示されます。

  • アップグレードプロセス中、つまりイメージのインストールおよびデバイスの再起動を行っている間は、デバイスでアクションを実行することはできません。

  • イメージをデバイスにコピーすることのみを選択した場合、デバイス上でアクションを実行できます。イメージをコピーしているデバイスは、[セキュリティデバイス（Security Devices）] ページで [イメージをコピーしています] と表示されます。

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

高可用性ペアの Cisco ASA と ASDM イメージのアップグレード

Security Cloud Control Firewall Management は、アクティブ/スタンバイ高可用性（HA）ペアで設定されている Cisco Secure Firewall ASA デバイスのアップグレードをサポートしています。

アップグレード中、 Security Cloud Control Firewall Management はトラフィックの中断を最小限に抑えるためにデバイスを順番にアップグレードします。

  1. スタンバイ Cisco ASA が最初にアップグレードされます。

  2. スタンバイデバイスがリブートされ、スタンバイ準備完了状態に戻ります。

  3. Security Cloud Control Firewall Management フェールオーバーを開始し、アップグレードされたデバイスをアクティブな Cisco ASA にします。

  4. その後、プライマリ ASA デバイスがアップグレードされ、再起動されます。

ほとんどのプロセス中において単一のデバイスがアクティブなままであるため、アップグレードでは ダウンタイムがほとんどゼロに近い状態になります。フェールオーバーイベント中、ネットワーク環境によっては、トラフィックの短い中断または少数のドロップされたパケットが発生する可能性があります。

ASA の設定方法、およびフェールオーバーモードでの動作方法についての詳細については、ASA のマニュアルの「Failover for High Availability」を参照してください。

Cisco ASA 高可用性ペアをアップグレードするためのワークフロー

次のワークフローでは 、Cisco Secure Firewall Management Center がアクティブ/スタンバイの高可用性ペアにある Cisco ASA デバイスをアップグレードする方法について説明します。

  1. 両方のデバイスへのイメージのダウンロード

    Cisco Secure Firewall Management Center が、Cisco ASA および ASDM イメージを、高可用性ペアの両方のデバイスにダウンロードします。


    （注）  

    ユーザーは、ASA および ASDM イメージのダウンロードを選択できますが、すぐにはアップグレードできません。Cisco ASA および ASDM イメージが以前にダウンロードされている場合、Security Cloud Control はそれらのイメージを再度ダウンロードしません。Security Cloud Control は次のステップでアップグレードワークフローを続行します。

  2. Cisco Secure Firewall Management Center スタンバイデバイスをアップグレードします。

    セカンダリ ASA（スタンバイデバイス）はアップグレードされて再起動され、プライマリ ASA はトラフィックの処理を続行します。

  3. スタンバイの準備状況の確認

    リブート後、アップグレードされたデバイスはスタンバイ準備完了状態になります。

  4. フェールオーバーを開始します。

    Cisco Secure Firewall Management Center がフェールオーバーを開始して、アップグレードされたデバイスがアクティブな Cisco ASA になります。

  5. 残りのデバイスをアップグレード

    スタンバイデバイスになった元のプライマリ ASA がアップグレードされ、再起動されました。

  6. 元のアクティブデバイスを復元

    デバイスがスタンバイ準備完了状態に戻ると、Cisco Secure Firewall Management Center は別のフェールオーバーを開始して、元のプライマリASAが再度アクティブになります。

このプロセスにより、アップグレード中も確実に 1 つのデバイスをアクティブにすることができ、サービスの中断を最小限に抑えられます。


警告

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

Cisco ASA 高可用性ペアをアップグレードするための前提条件

Cisco ASA 高可用性ペアをアップグレードする前に、次の要件が満たされていることを確認してください。

  • ASA および ASDM イメージのアップグレードに関する要件と重要な情報については、「ASA と ASDM のアップグレードの前提条件」を参照してください。

  • Cisco ASA は、スキャン/スタンバイ フェールオーバーモードで設定されます。

  • プライマリ ASA は、アップグレード時のアクティブデバイスです。

  • プライマリとセカンダリの Cisco ASA デバイスは、同じソフトウェアバージョンを実行しています。

  • Cisco Secure Firewall Management Center と両方のデバイス間の接続は動作可能です。


重要

Cisco Secure Firewall Management Centerで Cisco ASA のアクティブまたはスタンバイの高可用性ペアを管理する場合は、プライマリ ASAのみをオンボーディングします。セカンダリ ASA は、Cisco ASA フェールオーバーリンクを介して管理されるため、個別にオンボーディングする必要はありません。

高可用性ペアの Cisco ASA と ASDM イメージのアップグレード

手順

ステップ 1

左側のペインで セキュリティデバイス をクリックします。

ステップ 2

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

ステップ 3

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

ステップ 4

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

デバイスのフェールオーバー モードがアクティブ/スタンバイであることに注意してください。

Cisco ASA HA ペアのデバイスの詳細を表示します

ステップ 5

（オプション）後で Cisco Secure Firewall Management Center にアップグレードを実行させる場合は、[Schedule Upgrade] チェックボックスをオンにします。フィールドをクリックして、将来の日時を選択します。完了したら、[Done] をクリックします。

ステップ 6

ステップ 1 で、[Use SCC Image Repository] をクリックしてアップグレードする Cisco ASA ソフトウェアイメージを選択し、[Continue] をクリックします。

独自のリポジトリに保存されているイメージからアップグレードする場合は、[Specify Image URL] を選択し、イメージの場所を入力します。サポートされるプロトコルは、FTP、TFTP、HTTP、HTTPS、SCP、SMB です。

URL シンタックスの詳細については、「カスタム URL のアップグレード」を参照してください。

ステップ 7

ステップ 2 で、アップグレードする ASDM イメージを選択します。アップグレード可能な ASA と互換性のある ASDM の選択肢のみが表示されます。

ステップ 8

ステップ 3 で、選択内容を確認し、ASA へのイメージのダウンロードのみを実行するか、あるいはイメージをコピーしてインストールしデバイスを再起動するかを決定します。

ステップ 9

[Perform Upgrade] をクリックします。

Cisco Secure Firewall Management Center は、前述の HA アップグレードワークフローを自動的に実行します。


（注）  

アップグレードプロセスは、ダウンタイムがほぼゼロになるように設計されています。スタンバイデバイスのアップグレードに失敗すると、プロセスが停止し、失敗 通知が電子メールまたはウェブフック（設定されている場合）、または ユーザーインターフェイスに表示されます。

独自のイメージを使用した ASA または ASDM のアップグレード

ASA を新しい ASA ソフトウェアおよび ASDM イメージでアップグレードする場合、Security Cloud Control のイメージリポジトリに格納されているイメージを使用するか、ユーザー独自のイメージリポジトリに格納されているイメージを使用することができます。ASA にインターネットへのアウトバウンドアクセスがない場合、ユーザー独自のイメージリポジトリを維持することが、Security Cloud Control を使用して ASA をアップグレードするための最良のオプションです。

Security Cloud Control は ASA の copy コマンドを使用してイメージを取得し、それを ASA のフラッシュドライブ（disk0:/）にコピーします。[イメージURLの指定（Specify Image URL）] フィールドに、copy コマンドの URL 部分を指定します。たとえば、copy コマンド全体が次のようになっているとします。 

 ciscoasa# copy ftp://admin:adminpass@10.10.10.10/asa991-smp-k8.bin disk:/0

この場合、[イメージURLの指定（Specify Image URL）] フィールドに 

ftp://admin:adminpass@10.10.10.10/asa991-smp-k8.bin

と入力します。

Security Cloud Control は、アップグレードイメージを取得する http、https、ftp、tftp、smb、および scp の各方式をサポートします。

URL 構文の例

ASA copy コマンドの URL 構文の例を次に示します。これらの URL の例では、以下を想定しています。

  • イメージリポジトリのアドレス：10.10.10.10

  • イメージリポジトリにアクセスするためのユーザー名：admin

  • パスワード：adminpass

  • パス：images/asa

  • イメージファイル名：asa991-smp-k8.bin

http[s]:// [[ user [ : password ] @ ] server [ : port ] / [ path / ] filename ]

https://admin:adminpass@10.10.10.10:8080/images/asa/asa991-smp-k8.bin 
HTTP[s] example without a username and password: 
https://10.10.10.10:8080/images/asa/asa991-smp-k8.bin

ftp:// [[ user [ : password ] @ ] server [: port ] / [ path / ] filename [ ;type= xx ]] type は次のいずれかのキーワードになります。ap（ASCII パッシブモード）、an（ASCII通常モード）、ip（デフォルト：バイナリパッシブモード）、in（バイナリ通常モード）。

ftp://admin:adminpass@10.10.10.10:20/images/asa/asa991-smp-k8.bin 
FTP example without a username and password: 
ftp://10.10.10.10:20/images/asa/asa991-smp-k8.bin

tftp:// [[ user [ : password ] @ ] server [ : port ] / [ path / ] filename [ ;int= interface_name ]]

tftp://admin:adminpass@10.10.10.10/images/asa/asa991-smp-k8.bin outside 
TFTP example without a username and password: 
tftp://10.10.10.10/images/asa/asa991-smp-k8.bin outside

（注）  

パス名にスペースを含めることはできません。パス名がスペースを含む場合は、copy tftp コマンドの代わりに tftp-server コマンドでパスを設定します。;int= interface オプションは、ルートルックアップをバイパスし、常に指定したインターフェイスを使用して TFTP サーバーに到達します。

smb:/[[ path / ] filename ]：UNIX サーバーのローカルファイルシステムを示します。 

smb:/images/asa/asa991-smp-k8.bin

scp:// [[ user [ : password ] @ ] server [ / path ] / filename [ ;int= interface_name ]]]：;int= interface オプションはルートルックアップをバイパスし、常に指定したインターフェイスを使用してセキュアコピー（SCP）サーバーに到達します。

 scp://admin:adminpass@10.10.10.10:8080/images/asa/asa991-smp-k8.bin outside 
SCP example without a username and password: 
scp://10.10.10.10:8080/images/asa/asa991-smp-k8.bin outside

URL 構文を含む完全な copy コマンドについては、『Cisco ASA Series Command Reference, A - H Commands』ガイドを参照してください。

カスタム URL を使用した ASA および ASDM イメージのアップグレードの詳細については、「ASA と ASDM のアップグレードの前提条件」を参照してください。