Zscalerのブログ

Zscalerの最新ブログ情報を受信

製品およびソリューション

Zscaler Zero Trust Cloud Terraformプロバイダーとは

image

Zero Trust Cloudを自動化する理由

現代のクラウド環境では自動化が求められます。ワークロードの規模拡大や縮小、地域やアカウント間の移動に伴い、インフラは絶えず変化します。セキュリティ制御はその変化に自動的に追従する必要があり、手動のUI操作や場当たり的なスクリプトに頼るべきではありません。

Zscaler Zero Trust Cloud(ZTC)は、インライン検査、エグレス制御、そしてワークロードからインターネットへの分離(Workload-to-Internet Isolation)を、クラウドネイティブ環境に直接組み込みます。数十から数百ものアカウントにわたってZTCを大規模に運用するには、クラウドのスピードに見合った自動化モデルが必要です。Zscaler Cloud Connector 向け Terraform デプロイメントテンプレート は、これまでも、すべての対応クラウドにおいて Terraform モジュール を用いた、ゼロタッチのインフラ・プロビジョニング自動化を実現する推奨のクラウド非依存アプローチでした。デプロイだけにとどまらず、ZTC の管理、設定、ポリシー制御まで含めた自動化ライフサイクル全体へのサポートを強化することは、自然な流れです。

Zscaler Zero Trust Cloud用のTerraformプロバイダーとは

Zscaler Zero Trust Cloud (ZTC)用Terraformプロバイダーの提供を開始します。これは、クラウド、プラットフォーム、セキュリティ部門がZero Trust Cloudを大規模に自動化するための強力な手段です。UIを通じたゲートウェイの構成、アカウントのオンボーディング、転送ポリシーの作成に加え、ZTC環境をコードとして宣言できるようになりました。これにより、完全なバージョン管理、ピアレビュー、CI/CDパイプラインを通じた展開が可能になります。

このプロバイダーは、Zero Trust Cloudの構成オブジェクトに直接対応する豊富なリソースを公開しており、あらゆるクラウド環境において一貫した再現性のある展開を実現します。

ZTCに関する主なリソース

データ ソース

このプロバイダーには、モジュールがクラウド リージョン、クラウド プロバイダー、既存のテナント構成に動的に適応できるようにするためのデータ ソースも含まれています。

これらのリソースとデータ ソースを組み合わせることで、担当部門はVPC、VNet、IAM、ネットワーク ファイアウォールを自動化するのと同様に、Zero Trust Cloudを再現性・テスト可能性・拡張性のあるInfrastructure as Codeのワークフローで自動化できるようになります。

数分で利用開始

ZTC用Terraformプロバイダーを使用する前に、テナントに必要な認証方法が設定されていることを確認してください。このプロバイダーは、環境に応じてOneAPIOAuth 2.0クライアントZTCの従来のAPI認証情報の両方をサポートします。Zscalerは、すべてのお客様にOneAPIの利用を推奨しています。

前提条件

Terraformプランを初めて実行する前に、以下の準備が必要となります。

  1. APIアクセスが有効になっているZscaler Zero Trust Cloud (ZTC)テナント
  2. インストール済みのTerraform 1.3以降
  3. 以下のいずれかの認証方法

オプション1—OneAPI (推奨)

Zero Trust Cloudに必要なスコープを備えたOneAPI OAuthクライアントをZIdentityに作成します。

  • OneAPIは、OAuth 2.0クライアント認証情報フローを使用します。
  • Terraformプロバイダーは、client_idとclient_secretをアクセス トークンと交換することで認証します。
  • すでにOneAPIとZIdentityフレームワークに移行済みのテナントに推奨される方法です。
Image

ドキュメント

オプション2—従来のZTC認証

OneAPIまたはZIdentityへの移行が完了していないテナントに推奨されます。

  • ネイティブのZTC用APIキーと管理者認証情報(従来のフレームワーク)を使用してください。
  • このプロバイダーは、従来のCloud Connector認証を使用している組織との下位互換性を維持しています。
Image

ドキュメント

Zscaler OneAPIサポート

Zscaler Zero Trust Cloud用Terraformプロバイダーは、Zscalerプラットフォームの統合APIフレームワークであるOneAPIと従来の認証方法の両方をサポートするように構築されています。この柔軟性により、担当部門は現在のテナント構成を問わず、すぐに自動化を開始できると同時に、Zscalerの長期的なOneAPI導入への明確な道筋も提供できます。

Terraformの自動化においてOneAPIが重要な理由

OneAPIは、すべてのZscaler製品とサービスに対して、一貫性があり、最新の標準に基づいたプログラミング インターフェイスを提供します。Terraformユーザーにとって、これはより予測可能でスケーラブルな自動化体験を意味します。

Image

異なる認証モデルや製品固有のエンドポイントを管理する代わりに、OneAPIはZIA、ZPA、ZDX、ZCC、ZTCと連携するための単一で一貫した制御プレーンを提供します。

OneAPIは、OAuth 2.0ベースの認証とZIdentityとの統合も提供し、APIクライアントを完全なマネージドIDとして扱うことができるようにします。そして、完全な監査証跡、動作の可視化、組織向けのIAM標準への対応が可能となります。これにより、ガバナンスが大幅に向上し、自動化を最新のCI/CDセキュリティ対策と適合させます。

OneAPIによるTerraform自動化の強化

OneAPIを有効にすることで、ZTC用Terraformプロバイダーは以下のメリットを提供できます。

•Zscalerサービス全体で統一されたエンドポイント
• 新機能導入時にも一貫したAPIパターン
• 複数の認証方式の排除による運用負荷の削減
•Terraformのplan/apply操作におけるトレーサビリティーと監査性を強化

以上の強化により、OneAPIは、Zscalerを大規模かつ長期的に自動化するための戦略的な基盤となります。

従来の認証方式のサポート(OneAPI以外のテナント向け)

一部の組織では、依然として製品固有の従来型のAPIキーやポータル スコープの認証情報に依存している場合があります。このプロバイダーはこうしたモデルを全面的にサポートしており、既存のワークフローを再構築することなく、自動化を今すぐ開始できます。これは、まだZIdentityに移行していないテナントや、APIキーのパイプラインがすでに確立されている環境にとって有益です。

認証モデルの選定

大抵は以下の2通りのいずれかをたどります。

  • 新規の展開:Zscalerの長期モデルに合わせるため、まずはOneAPIから開始します。
  • 既存の展開:OAuth 2.0ベースの自動化への準備状況を評価しながら、従来の認証方式を継続します。

OneAPIへの移行

従来のAPIキーからOneAPIへの移行は通常、Terraformプロバイダーの認証情報を更新するだけで済み、Terraformモジュールの書き換えは必要ありません。OAuth 2.0を設定し、ステージング環境で検証を行い、キーをローテーションし、長期的なガバナンスのためにZIdentityを導入してください。

結論

OneAPIは、Zscalerプラットフォーム全体にわたって、より安全でスケーラブル、かつ保守性に優れた自動化基盤を提供します。ZTC用Terraformプロバイダーは両方のモデルをサポートしており、担当部門に最新の柔軟性と将来に向けた明確なアップグレードの道筋を提供します。

ZTC用Terraform構成の設定

ZTC用TerraformプロバイダーのGitHubリポジトリーにある、事前に構築されたサンプル構成の1つをテストしてみましょう。

main.tfファイルには、以下のZTC用Terraformのリソースが含まれています。

  • ztc_forwarding_gateway
  • ztc_traffic_forwarding_rule

この構成により、転送ゲートウェイ直接転送ルールが作成されます。

  • Image

それでは、実際にTerraformの構成を適用してみましょう。

1. 次のコマンドで、構成で定義されているプロバイダーをダウンロードし、インストールします。

terraform init

2.このコマンドを実行し、作成されるリソースの計画を確認します。

terraform plan

3. 構成を適用します。

terraform apply

展開のクリーンアップ

作成したすべてのリソースを削除するには、次のコマンドを実行します。

terraform destroy

このコマンドは、Terraformステートで指定されているすべてのリソースを削除します。Terraform destroyは、現在のTerraformプロジェクトで管理されていない他の場所で実行中のリソースを削除することはありません。

重要となる主な自動化パターン

プラットフォーム エンジニア、クラウド アーキテクト、セキュリティ担当者のいずれであっても、このプロバイダーは影響力の大きい複数のワークフローを加速させます。

  1. 複数アカウントのオンボーディング:クラウド部門は、数十から数百ものAWS/Azureアカウントを管理していることが多いです。Terraformでは、アカウントのメタデータを一度定義するだけで、プロバイダーが各環境のオンボーディングを処理します。

    パターン例

    1. ztc_public_cloud_infoztc_account_groupsを組み合わせる
    2. 一貫した外部IDとリージョンを適用する
    3. ワークロード把握のためにタグ付け標準を推進する
  2. コードによるトラフィック エンジニアリング:ztc_forwarding_gateway、ztc_dns_forwarding_gateway、各種トラフィック転送ルール リソースを介して、インターネット エグレス、プライベート アプリケーション、DNS検査の動作をモデル化します。これにより、すべてのVPC/VNetがポータルを手動で編集することなく、適切なネクスト ホップを継承できるようになります。
  3. エッジ コネクターの共有ガードレール:ztc_location_templateとztc_location_managementを使用して
    Zero Trust Gatewayアーキテクチャーで説明されているトランジット ゲートウェイと分散型ゲートウェイ ロード バランサー(GWLBe)の構成を事前定義し、
    それを各環境のZscaler Zero Trust Gatewayに適用します。
  4. 決定論的な状態に基づく運用上のレジリエンス:Terraformのステート ファイルが信頼できる情報源となり、担当部門は以下を実現できます。
    1. ドリフトを瞬時に検出する
    2. レビューされていないコンソール編集を防止する
    3. 一貫した成果物でトラブルシューティングを加速させる
    4. 変更管理(例:ServiceNowの承認フロー)を統合する
    5. 複数の部門が同じテナントで運用する大規模組織では、この施行レイヤーが不可欠となります。

ZscalerとTerraformerによる既存の展開の制御

すでにCloud ConnectorまたはZero Trust Gateway (ZTGW)を手動で展開していますか?問題ありません。

Zscaler-Terraformer CLIは、既存のZTC構成をリバース エンジニアリングし、以下の構成に変換します。

  • Terraform (HCL)ファイル
  • ステート ファイル
  • プロバイダーの初期構成
  • モジュール対応ディレクトリー構造

これにより、ほとんどのInfrastructure as Code (IaC)に必要とされる「すべてをゼロから書き直す」という煩わしい段階が不要になります。

Terraformerにより、以下を実行します。

  • 転送ゲートウェイ、IPプール、ルール、オブジェクトをインポートする
  • Bootstrapバージョン管理
  • ドリフトを理解するためterraform planをすぐに実行する
  • 担当部門を段階的にUIからInfrastructure as Code (IaC)にリソース単位で移行させる

ZscalerとTerraformの詳細については、以前のブログ記事のZscaler用のTerraformerツールとはをご覧ください

 

ZscalerとTerraformerのデモ

ZscalerとTerraformerのデモ

ZTC用Terraformプロバイダーのインポーター

 

「申し込む」ボタンを押す前に知っておくべきベスト プラクティス

  • Gitベースのワークフローの採用:プルリクエスト、レビュー担当者、マージ前のチェックを活用し、ネットワーク/セキュリティの変更にもアプリケーション展開と同等の厳格さを適用します。
  • ZTCをSDLCの一部として扱う方法:既存のリリース ワークフローに変更を組み込み、ネットワークの更新もアプリケーションの展開と同じレビュー、テスト、承認基準に従うようにします。
  • トポロジーごとのモジュール化:転送ゲートウェイ ハブ、分散型VPCエンドポイント、ハイブリッド パターン用のモジュールを分離することで、アカウントの重複やパートナー接続に基づいてアーキテクチャーを簡単に組み合わせることが可能です。これは、Zscaler Zero Trust Gatewayのブログで概説されているモデルを反映しています。
  • 動的なデータ ソースの活用:ztc_supported_regionsをモジュールに入力することで、AWSリージョンやクラウド タイプをハードコーディングする必要がなくなります。特に、ZscalerがAzureやGCPへのサポートを継続的に拡大している状況では有効です。
  • 運用との整合:プロビジョニングURL、アクティベーション ステータス、ログ転送設定などのTerraform出力値をランブックに反映させることで、2日目の運用担当者が信頼できる唯一の情報源を利用できるようにします。

ZscalerとTerraform:実践的なユース ケース

Zscalerのお客様はすでに、既存のTerraformプロバイダーを使用してZPAとZIAを自動化しています。Zero Trust Cloudがエコシステムに追加されたことで、担当部門は一貫したワークフローと共有モジュールを使用し、3つのプラットフォームすべてにまったく同じIaCパターンを拡張できます。

ユース ケース1: UIクリックを宣言型の自動化に置き換え

Terraformは以下を提供します。

  • 決定論的構成
  • 手作業によるミスの削減
  • 再現性のあるアプリケーションとオンボーディング ワークフロー
  • クラウドとアカウント間の一貫性

ユース ケース2:ドリフトの排除

Terraformは特に以下に対応します。

  • 予期しない変更
  • UIベースの編集
  • 環境間の矛盾

これは、コンプライアンスが重視される部門にとって非常に重要です。

ユース ケース3:ポリシーの順守と最小特権

Terraformにより、担当部門は以下を実現できます。

  • ドメインごとにワークスペースを作成する(ZIA FW、ZPAアクセス ポリシー、ZTC転送)
  • 管理者のアクセスを担当モジュールのみに制限
  • SentinelまたはOPAを介してポリシーを施行する
  • ITSMワークフローとの統合

結果として、自社のSDLCとクラウド展開モデルに適合する、スケーラブルで自動化に優れたゼロトラスト エコシステムとなります。

Zscaler Zero Trust Cloud用Terraformプロバイダーは、俊敏性が不可欠なクラウド環境において、予測可能でスケーラブルかつ自動化されたセキュリティを提供します。数十ものAWS/Azureアカウントのオンボーディング、転送ポリシーの施行、またはドリフトの排除といったどのような場合でも、TerraformはZTC導入を一貫性のあるコード主導型にし、現代のクラウド部門が好む働き方を可能にします。

既存の展開を持つ部門の場合は、ZscalerとTerraformerが現在の構成をTerraform対応のファイルとステートに変換することで移行を加速させます。

その結果、統一されたGitベースのワークフローが実現します。セキュリティを強化し、展開を加速させ、クラウド ネットワーキングをDevOpsのベスト プラクティスと整合させるのです。

まずは、Terraform Registryでプロバイダーを確認するか、Terraformerツールを使って既存の展開を数分でコード化してみましょう。

form submtited
お読みいただきありがとうございました

このブログは役に立ちましたか?

免責事項:このブログは、Zscalerが情報提供のみを目的として作成したものであり、「現状のまま」提供されています。記載された内容の正確性、完全性、信頼性については一切保証されません。Zscalerは、ブログ内の情報の誤りや欠如、またはその情報に基づいて行われるいかなる行為に関して一切の責任を負いません。また、ブログ内でリンクされているサードパーティーのWebサイトおよびリソースは、利便性のみを目的として提供されており、その内容や運用についても一切の責任を負いません。すべての内容は予告なく変更される場合があります。このブログにアクセスすることで、これらの条件に同意し、情報の確認および使用は自己責任で行うことを理解したものとみなされます。

Zscalerの最新ブログ情報を受信

このフォームを送信することで、Zscalerのプライバシー ポリシーに同意したものとみなされます。