OT センサーでプロキシ設定を構成する
この記事は、Microsoft Defender for IoT を使用した OT 監視のデプロイ パスについて説明するシリーズ記事の 1 つであり、Azure に接続するように OT センサーでプロキシ設定を構成する方法について説明します。
次の場合は、この手順をスキップできます。
エアギャップ環境とローカル管理センサーで作業している場合
OT センサーと Azure の間で直接接続を使用している場合。 この場合は、クラウド管理用にセンサーをプロビジョニングしたときに、必要なすべての手順が既に実行されています
前提条件
この記事で説明されている手順を実行するには、次の条件を満たしている必要があります。
OT ネットワーク センサーがインストールされ、構成され、アクティブ化されています。
クラウドに接続された Defender for IoT センサーでサポートされている接続方法と、各センサーに使用する接続方法を含む OT サイト デプロイの計画について理解していること。
管理者ユーザーとして OT センサーにアクセスできること。 詳細については、Defender for IoT を使用した OT 監視のためのオンプレミスのユーザーとロールに関するページを参照してください。
この手順は、デプロイ チームと接続チームによって実行されます。
OT センサーでプロキシ設定を構成する
このセクションでは、OT センサー コンソールで既存のプロキシの設定を構成する方法について説明します。 プロキシがまだない場合は、次の手順を使用してプロキシを構成します。
OT センサーでプロキシ設定を構成するには:
OT センサーにサインインし、[システム設定] > [センサー ネットワーク設定] の順に選択します。
[プロキシの有効化] オプションをオンに切り替え、プロキシ サーバーの次の詳細を入力します。
- プロキシ ホスト
- プロキシ ポート
- プロキシのユーザー名 (省略可能)
- プロキシのパスワード (省略可能)
次に例を示します。
関連する場合は、[クライアント証明書] を選択して、SSL/TLS プロキシ サーバーにアクセスするためのプロキシ認証証明書をアップロードします。
注意
Zscaler や Palo Alto Prisma などのサービスを使用する場合など、SSL/TLS トラフィックを検査するプロキシ サーバーには、クライアント SSL/TLS 証明書が必要です。
[保存] を選択します。
Azure プロキシを設定する
次の状況では、Azure プロキシを使用してセンサーを Defender for IoT に接続できます。
- センサーと Azure との間にプライベート接続が必要である
- サイトが ExpressRoute 経由で Azure に接続されている
- サイトが VPN 経由で Azure に接続されている
プロキシが既に構成されている場合は、センサー コンソールでプロキシ設定を直接定義して続行します。
プロキシがまだ構成されていない場合は、このセクションの手順を使用して、Azure VNET で設定します。
前提条件
開始する前に、以下を用意してください。
ログを監視するための Log Analytics ワークスペース
Azure VNET へのリモート サイト接続
センサーから Defender for IoT に必要なエンドポイントへのポート 443 でのアウトバウンド HTTPS トラフィックが許可されている。 詳細については、「クラウド管理用の OT センサーをプロビジョニングする」を参照してください。
Microsoft クラウド サービスを利用するためのファイアウォール アクセス許可があるプロキシ サーバー リソース。 この記事で説明した手順では、Azure でホストされている Squid サーバーを使用します。
重要
Microsoft Defender for IoT では、Squid またはその他のプロキシ サービスに対するサポートは提供されていません。 プロキシ サービスの設定と管理は、お客様の責任で行う必要があります。
センサーのプロキシ設定を構成する
このセクションでは、OT センサーで使用するために Azure VNET でプロキシを構成する方法について説明します。次の手順を使用します。
- NSG ログ用のストレージ アカウントを定義する
- 仮想ネットワークとサブネットを定義する
- 仮想またはローカル ネットワーク ゲートウェイを定義する
- ネットワーク セキュリティ グループを定義する
- Azure 仮想マシン スケール セットを定義する
- Azure Load Balancer を作成する
- NAT ゲートウェイを構成する
手順 1: NSG ログ用のストレージ アカウントを定義する
Azure portal からで、次の設定で新しいストレージ アカウントを作成します。
| 領域 | 設定 |
|---|---|
| 基本操作 | パフォーマンス: 標準 アカウントの種類: Blob Storage レプリケーション: LRS |
| Network | 接続方法: パブリック エンドポイン (選択したネットワーク) 仮想ネットワーク内: なし ルーティングの優先順位: Microsoft ネットワーク ルーティング |
| データ保護 | オプションはすべてオフのまま |
| 詳細 | すべて既定値のまま |
手順 2: 仮想ネットワークとサブネットを定義する
次の VNET とその中のサブネットを作成します。
| 名前 | 推奨サイズ |
|---|---|
MD4IoT-VNET |
/26 または/25 (Bastion を含む) |
| サブネット: | |
- GatewaySubnet |
/27 |
- ProxyserverSubnet |
/27 |
- AzureBastionSubnet (省略可) |
/26 |
手順 3: 仮想またはローカル ネットワーク ゲートウェイを定義する
Azure に対するオンプレミス ネットワークの接続方法に応じて、仮想ゲートウェイ用の VPN または ExpressRoute ゲートウェイを作成するか、ローカル ゲートウェイを作成します。
先ほど作成した GatewaySubnet サブネットにゲートウェイを接続します。
詳細については、次を参照してください。
手順 4: ネットワーク セキュリティ グループを定義する
NSG を作成し、次の受信ルールを定義します。
センサー (ソース) からロード バランサーのプライベート IP アドレス (宛先) へのトラフィックを許可するルール
100を作成します。 ポートtcp3128を使用します。65001システム ルールの複製としてルール4095を作成します。 これはルール65001が、ルール4096によって上書きされるためです。マイクロセグメンテーションのトラフィックをすべて拒否するルール
4096を作成します。省略可能。 Bastion を使用している場合は、ルール
4094を作成して、サーバーに対する Bastion の SSH を許可します。 Bastion サブネットをソースとして使用してください。
先ほど作成した
ProxyserverSubnetに NSG を割り当てます。NSG のログを定義します。
新しい NSG を選択し、[Diagnostic setting] (診断設定) > [診断設定の追加] を選択します。
診断設定の名前を入力します。 [カテゴリ] で [allLogs] を選択します。
[Log Analytics ワークスペースへの送信] を選択し、使用する Log Analytics ワークスペースを選択します。
NSG フロー ログを送信するように選択し、次の値を定義します。
[基本] タブ:
- わかりやすい名前を入力します
- 先ほど作成したストレージ アカウントを選択します
- 必要なリテンション期間日数を定義します
[構成] タブ:
- バージョン 2 を選択します
- [トラフィック分析の有効化] を選択します
- Log Analytics ワークスペースを選択する
手順 5: Azure 仮想マシン スケール セットを定義する
仮想マシンの数を必要に応じて自動的に増減できる負荷分散仮想マシンのグループを作成、管理するための Azure 仮想マシン スケール セットを定義します。
詳細については、「仮想マシン スケール セットとは」を参照してください。
センサー接続に使用するスケール セットを作成するには:
次のパラメーターの定義を使用してスケール セットを作成します。
- オーケストレーション モード: 均一
- セキュリティの種類: 標準
- イメージ: Ubuntu server 18.04 LTS – Gen1
- サイズ: Standard_DS1_V2
- 認証: 社内の標準に基づく
[ディスク] の設定は、既定値のままにしてください。
先ほど作成した
Proxyserverサブネットにネットワーク インターフェイスを作成します。ただし、まだロード バランサーは定義しないでください。次のようにスケーリング設定を定義します。
- 初期インスタンス数を 1 として定義します
- スケーリング ポリシーを [手動] として定義します
次の管理設定を定義します。
- アップグレード モードには、[Automatic - instance will start upgrading] (自動 - インスタンスがアップグレードを開始) を選択します
- ブート診断を無効にします
- [ID] と [Microsoft Entra ID] の設定をクリアします
- [オーバープロビジョニング] を選択します
- [Enabled automatic OS upgrades] (自動 OS アップグレード有効) を選択します
次の正常性設定を定義します。
- [アプリケーションの正常性監視を有効にする] を選択します
- TCP プロトコルとポート 3128 を選択します
詳細設定で、[拡散アルゴリズム] を [最大拡散] として定義します。
カスタム データ スクリプトで次の手順を実行します。
使用するポートとサービスに応じて次の構成スクリプトを作成します。
# Recommended minimum configuration: # Squid listening port http_port 3128 # Do not allow caching cache deny all # allowlist sites allowed acl allowed_http_sites dstdomain .azure-devices.net acl allowed_http_sites dstdomain .blob.core.windows.net acl allowed_http_sites dstdomain .servicebus.windows.net acl allowed_http_sites dstdomain .download.microsoft.com http_access allow allowed_http_sites # allowlisting acl SSL_ports port 443 acl CONNECT method CONNECT # Deny CONNECT to other unsecure ports http_access deny CONNECT !SSL_ports # default network rules http_access allow localhost http_access deny allスクリプト ファイルの内容を base-64 でエンコードします。
エンコードしたファイルの内容をコピーして、次の構成スクリプトを作成します。
#cloud-config # updates packages apt_upgrade: true # Install squid packages packages: - squid run cmd: - systemctl stop squid - mv /etc/squid/squid.conf /etc/squid/squid.conf.factory write_files: - encoding: b64 content: <replace with base64 encoded text> path: /etc/squid/squid.conf permissions: '0644' run cmd: - systemctl start squid - apt-get -y upgrade; [ -e /var/run/reboot-required ] && reboot
手順 6: Azure ロード バランサーを作成する
Azure Load Balancer は、ハッシュベースの分散アルゴリズムを使用して正常な仮想マシン インスタンスに受信トラフィックを分散するレイヤー 4 ロード バランサーです。
詳細については、Azure Load Balancer のドキュメントを参照してください。
センサー接続用の Azure Load Balancer を作成するには:
ロード バランサーがインターネットに公開されないよう、SKU が Standard で種類が [内部] のロード バランサーを作成します。
先ほど作成した
proxysrvサブネットに動的フロントエンド IP アドレスを定義します。可用性はゾーン冗長に設定してください。バックエンドには、先ほど作成した仮想マシン スケール セットを選択します。
センサーに定義されているポートで、フロントエンド IP アドレスをバックエンド プールに接続する TCP 負荷分散規則を作成します。 既定のポートは 3128 です。
新しい正常性プローブを作成し、ポート 3128 で TCP 正常性プローブを定義します。
ロード バランサーのログ記録を定義します。
Azure portal で、作成したロード バランサーに移動します。
[診断設定]>[診断設定を追加する] を選択します。
わかりやすい名前を入力し、カテゴリを [allMetrics] と定義します。
[Log Analytics ワークスペースへの送信] を選択し、Log Analytics ワークスペースを選択します。
手順 7: NAT ゲートウェイを構成する
センサー接続用に NAT ゲートウェイを構成するには:
新しい NAT ゲートウェイを作成します。
[送信 IP] タブで、[新しいパブリック IP アドレスの作成] を選択します。
[サブネット] タブで、先ほど作成した
ProxyserverSubnetサブネットを選択します。
これでプロキシが完全に構成されます。 OT センサーでプロキシ設定を定義して続行します。
プロキシ チェーン経由で接続する
次の状況では、プロキシ チェーンを使用してセンサーを Azure の Defender for IoT に接続できます。
- OT ネットワークからクラウドに到達するためには、センサーにプロキシが必要
- 単一ポイントを介して複数のセンサーを Azure に接続したい
プロキシが既に構成されている場合は、センサー コンソールでプロキシ設定を直接定義して続行します。
プロキシがまだ構成されていない場合は、このセクションの手順を使用して、プロキシ チェーンを構成します。
詳細については、「プロキシ チェーンを使用したプロキシ接続」を参照してください。
前提条件
開始する前に、プロキシ プロセスを実行しているホスト サーバーがサイト ネットワーク内にあることを確認してください。 プロキシ プロセスには、センサーとチェーン内の次のプロキシの両方からアクセスできる必要があります。
この手順は、オープンソースの Squid プロキシを使用して検証しました。 このプロキシでは、HTTP トンネリングと HTTP CONNECT コマンドが接続に使用されます。 その他、CONNECT コマンドをサポートするあらゆるプロキシ チェーン接続をこの接続方法に使用できます。
重要
Microsoft Defender for IoT では、Squid またはその他のプロキシ サービスに対するサポートは提供されていません。 プロキシ サービスの設定と管理は、お客様の責任で行う必要があります。
プロキシ チェーン接続を構成する
この手順では、Ubuntu サーバーで最新バージョンの Squid を使用して、センサーと Defender for IoT 間の接続をインストールして構成する方法について説明します。
各センサーでプロキシの設定を定義します。
OT センサーにサインインし、[システム設定] > [センサー ネットワーク設定] の順に選択します。
[プロキシの有効化] オプションをオンにし、プロキシのホスト、ポート、ユーザー名、パスワードを定義します。
Squid プロキシをインストールします。
プロキシ Ubuntu マシンにサインインし、ターミナル ウィンドウを起動します。
システムを更新し、Squid をインストールします。 次に例を示します。
sudo apt-get update sudo apt-get install squidSquid 構成ファイルを探します。 たとえば、
/etc/squid/squid.confや/etc/squid/conf.d/にあります。このファイルをテキスト エディターで開いてください。Squid の構成ファイルで、
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTSというテキストを検索します。ファイルに
acl <sensor-name> src <sensor-ip>とhttp_access allow <sensor-name>を追加します。 次に例を示します。# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS acl sensor1 src 10.100.100.1 http_access allow sensor1必要に応じてセンサーの行を追加して、他のセンサーを追加します。
Squid サービスを起動時に開始するよう構成します。 次を実行します。
sudo systemctl enable squid
プロキシを Defender for IoT に接続します。 センサーから Defender for IoT に必要なエンドポイントへのポート 443 でのアウトバウンド HTTPS トラフィックが許可されていることを確認します。
詳細については、「クラウド管理用の OT センサーをプロビジョニングする」を参照してください。
これでプロキシが完全に構成されます。 OT センサーでプロキシ設定を定義して続行します。
マルチクラウド環境の接続を設定する
このセクションでは、1 つまたは複数のパブリック クラウドにデプロイされたセンサーから Azure の Defender for IoT にセンサーを接続する方法について説明します。 詳細については、「マルチクラウド接続」を参照してください。
前提条件
開始する前に、パブリック クラウド (AWS、Google Cloud など) にデプロイされたセンサーがあって、SPAN トラフィックを監視するように構成されていることを確認します。
マルチクラウド接続方法を選択する
どの接続方法を使用するかについては、次のフロー チャートを使用して判断してください。
データの交換にプライベート IP アドレスを使用する必要がない場合は、インターネットでパブリック IP アドレスを使用します。
次のいずれも "不要" である場合のみ、インターネットでサイト間 VPN を使用します。
- 予測可能なスループット
- SLA
- 大量データの転送
- パブリック インターネットを使用しない接続
予測可能なスループット、SLA、大量データの転送、パブリック インターネットを使用しない接続のどれか 1 つでも必要である場合は、ExpressRoute を使用します。
この場合、次のようになります。
- 接続を確立するルーターを所有、管理したい場合は、ExpressRoute とカスタマー マネージド ルーティングを使用します。
- 接続を確立するルーターを所有、管理する必要がなければ、ExpressRoute とクラウド エクスチェンジ プロバイダーを使用します。
構成
Azure クラウド導入フレームワークで推奨されているいずれかの方法を使用してクラウドに接続するようセンサーを構成します。 詳細については、「他のクラウド プロバイダーへの接続」を参照してください。
VPC と Defender for IoT 間のプライベート接続を有効にするには、VPN 接続で VPC を Azure VNET に接続します。 AWS VPC から接続する場合の例については、TechCommunity ブログ「マネージド ソリューションのみを使用して Azure と AWS との間に VPN を作成する方法」を参照してください。
VPC と VNET を構成したら、OT センサーでプロキシ設定を定義します。
次のステップ
OT センサーでオンプレミス ユーザーを管理したり、SNMP を使用してセンサーの正常性監視を設定したりするために、Active Directory 接続を構成することをお勧めします。
デプロイ中にこれらの設定を構成しない場合は、後で戻って構成することもできます。 詳細については、次を参照してください。