Zscalerのブログ
Zscalerの最新ブログ情報を受信
HashiCorp Terraformを使用したZscaler Infrastructure as Codeの管理
Infrastructure as code (IaC)
セキュリティの世界は自動化の価値を確信しています。手作業を排除し、環境の変化に合わせてポリシーを自動で更新すれば、管理作業を削減できるだけでなく、セキュリティ態勢も向上します。また自動化によって、新しいテクノロジーの採用、環境の更新や拡張、ベスト プラクティスの改訂などから生じる変化にこれまで以上に迅速に適応できるようになります。ネイティブのテンプレート技術とサードパーティー製ツール(Terraformなど)を組み合わせると、アプリ開発のフレームワークにセキュリティを簡単に組み込むことができます。
コードで構成を書くことで、設定の一貫性を保ち、エラーを招く機会が減り、デプロイメント間の偏差を軽減できます。
例えば、展開プロセスを熟知しているのがたった1人のエンジニアであった場合、そのエンジニアが退職すれば当然その知識も失われます。その結果、残りのメンバーは失われた情報を得るために奔走することになるでしょう。
インフラストラクチャーをコードとして定義することで、このプロセスはチーム全員にチーム全体のために文書化されます。エンジニア達は、一元化されたコードを見て、各種サービスとプロセスがどのように紐づけられているかを読み取ることができ、貴重な知識を失うリスクを最小限に抑えることができます。情報は個別に文書化することもできますが(たとえば、Wiki内で)、正しい情報を見つけようとするのがいかに困難かは誰もが知っています。Infrastructure as Code (IaC) は、これらの懸念に対処し、さらに重要なことに、効率を高めるための戦略を提供します。
Terraformを選ぶ理由
HashiCorpのTerraformは、最も人気がある拡張可能なオープンソース ツールの1つで、クラウド インフラの定義と作成をコード化することで再現性を担保します。Terraformでは、HashiCorp Configuration Language (HCL)を用いてインフラとサービスを構成できます。
プロバイダーは、リソースの作成、更新、削除に必要な各種APIと相互作用します。Terraformは、AWS、GCP、Azureなどのプロバイダーを通じてインフラを管理するために使用されますが、Platform as a Service (PaaS)やSoftware as a Service (SaaS)のリソース管理にも使用できます。
Zscaler環境の管理にTerraformを使用する場合、Zscalerプラットフォームでリソースを作成、編集、削除するための単一のソースとして利用することが一般的なユース ケースです。自社のクラウド インフラの他の部分を定義するツールにTerraformを使用している組織が、定義されたすべてのリソース構成を1か所で維持するようにZscaler環境を構成したいと考えるのは当然のことでしょう。
Terraformが実行されるたびに、使用しているサービス構成に関する情報が保存されます。デフォルトでは、この情報はterraform.tfstateという名前のファイルにローカルで保存されますが、チームの環境で使用するためにリモートで保存することも可能です。
Terraform プロバイダーはお使いの Zscaler 環境に何を提供できるのでしょうか？
ZPAとZIAを自社のゼロトラスト プラットフォームとして使用する組織は、これらの製品の一方または両方をその継続的インテグレーション(CI)、継続的デリバリー(CD)、および開発パイプラインに簡単に統合できます。
Zscalerプラットフォームでは、使いやすい管理UIとAPIを介して管理者が複数の設定を柔軟に構成できますが、API経由で行われた変更が管理UIで行われた設定を上書きする(またはその逆)こともあるため、大規模な構成の管理は常に大きな課題となっています。そしてこの課題によって、IaCアプローチで構成設定を管理したい部門と、コードを書くことなく管理UIを介して設定のチェックと修正を迅速に行いたい管理、セキュリティ、ITなどの部門の間で競合が発生するという事態が引き起こされます。
しかし、Terraformを介して行われた変更は、ZPAやZIAのコンソールにすぐに表示されるため、どちらかのアプローチを選択する必要はありません。反対に、Terraformで管理されている設定を変更するためにZPAやZIAの管理者用ダッシュボードが意図的に(または誤って)使用された場合、その変更はTerraformの次回実行時にフラグが付けられます。つまり、Zscaler環境内の予期しない構成変更には、追加の保護レイヤーが提供されるというわけです。
Zscaler Terraform プロバイダーとは
HashiCorpは先日、Zscaler Private Access (ZPA)とZscaler Internet Access (ZIA)の両方のTerraformプロバイダーを検証しました。プロバイダーはTerraformレジストリーで公開されており、Terraform構成ファイルから参照できます。
ZPA および ZIA 用に新しく利用可能になったこれら2つの Terraform プロバイダーは、ゼロトラスト ポリシー、クラウドでのベスト プラクティス、デプロイメント、および ZPA App Connectorsの構成を自動化して施行します。
Terraformの最新バージョンは、こちらから入手できます。プロバイダーを使用する前に、適切なバイナリー ファイルをダウンロードし、Terraformをインストールする必要があります。
Terraform と プロバイダー の詳細は、HashiCorpのWebサイトをご覧ください。
Zscaler + Terraform のユースケース
ユース ケース 1: Zscaler 管理者用UI の代わりに Terraform を使用する
Terraformは、ZPAとZIAのAPIエンドポイントへのAPIコールでリクエストされた状態を構築することで、Zscalerテナントのプロビジョニングと展開のプロセスを自動化します。TerraformとZscalerを併用する主なメリットは次のとおりです。
- 状態ファイル構成に基づいて ZPA および ZIA インフラストラクチャーをより予測可能かつ決定論的にすることで、メンテナンスを削減します。
- 新しいアプリケーションをオンボーディングするとき、または新しいセキュリティポリシーを施行するときのZPA/ZIA管理コストを最小限に抑えます。
- システム管理者の記憶に依存するのではなく、ソース ファイルを定義して使用することで、ZPA および ZIA インフラストラクチャーの バス ファクター(チームメンバー間で共有がなされていないこと）のリスク を下げます。
ここからは、ZPAの管理UIから一般的な作業を実行するためのZPAとZIAのTerraform構成の例を紹介します。
ZPA プロバイダー - Application Segment
Application Segment、サーバー グループ、セグメント グループ、および App Connectors グループの作成に加えて、ZPA プロバイダーを使用して以下を管理することもできます：
- アプリケーション サーバー コントローラー
- Application SegmentのBrowser Access
- アクセス ポリシー ルール
- アクセス ポリシー タイムアウト ルール
- アクセス ポリシー転送ルール
- アクセス ポリシー検査ルール
ZIA プロバイダー クラウド ファイアウォール ルール
ZIA クラウド ファイアウォール ポリシーの管理に加えて、プロバイダーは以下の管理もサポートします：
- 管理者ユーザーと役割
- ユーザ アカウント
- URLフィルタリングのルール
- URLカテゴリ
- 高度な脅威対策 (ATP) による URL の許可リストと許可されていないリスト
- DLP Web ルール
- DLP辞書
- その他
ユース ケース 2: 構成ドリフトの解消
複数の異なる部門や管理者がZPAやZIAの構成ポリシーを編集する可能性があるため、さまざまな構成変更をすべて追跡することは時間の経過とともに難しくなっていきます。Terraformを信頼できる唯一のソースとして使用すれば、意図的か偶発的かにかかわらず、ZPAまたはZIAインフラへの変更をTerraformのドリフト管理機能に基づいて即座に検出できます。
これにより、以下が可能になります：
- 変更された構成を見つけるために監査ログを分析する必要性が減ります。
- 不正な構成変更が検出された場合のセキュリティが改善されます。
Terraformを使用する際の重要な考慮事項は、状態ファイルが最新のインフラ構成の信頼できるソースとして機能するという点です。オペレーターは、Terraform Cloudのリモート状態ストレージ機能を用いて、更新または変更を行う際に必要な状態ファイルを使用できるため、安全なストレージと組織の状態ファイルへの安全なアクセスが実現し、構成ミスやエラーの発生リスクが軽減されます。
これらの種類の変更は今まで識別が困難でしたが、Terraformは次回の実行時に不要な変更を特定できます。
構成ドリフトに関連するリスクの詳細については、当社の記事「開発者ワークフローへのInfrastructure as Code (IaC)の埋め込みによるインフラストラクチャーのセキュリティ保護」をご覧ください。
ユース ケース 3: ポリシーの遵守と管理
Terraformは、どの部門が特定のタイプのリソースをプロビジョニングして使用できるかをカバーするポリシーの施行に役立ちます。ZPAまたはZIAプロバイダーを活用することで、組織は自動化を使用してZscalerプラットフォームを管理、拡張できます。
- ITSM:チケットベースのレビュー プロセスは、開発を遅らせる可能性のあるボトルネックです。代わりに、ServiceNow承認ワークフローの展開を使用したZscaler Private AccessとHashiCorp Terraformで説明されているような統合ワークフローを使用できます。
- ワークスペースの管理：組織がZIA Terraformプロバイダーを活用して、セキュリティ部門が管理するクラウド ファイアウォール モジュールを構成する場合、特定のワークスペースに制限して、その機能に関連付けられていない他の機能やリソースを構成できないようにできます。ZPA Terraformプロバイダーを利用している場合も同様で、特定の部門はApplication Segmentを変更できるようにしながら、他の部門はアクセス ポリシーを作成または変更できるように設定できます。
Terraformを使用することで、Zscalerのお客様はセキュリティをより簡単に自動化できます。また、CI/CDパイプラインの一部としてIaCを採用する際に、アプリケーション環境のすべての側面に一貫してセキュリティを組み込むことができます。このシフトレフト アプローチにより、開発部門とセキュリティ部門間の摩擦が軽減され、迅速なアプリケーション展開が可能になり、セキュリティ態勢も向上します。
ZPAおよびZIAプロバイダーの詳細については、HashiCorpのTerraformサイトにあるプロバイダーのドキュメントを参照してください。ZPAおよびZIAプロバイダー プロジェクトに質問や意見がある場合は、GitHub上のリポジトリーにアクセスしてください。
参考資料
免責事項：このブログは、Zscalerが情報提供のみを目的として作成したものであり、「現状のまま」提供されています。記載された内容の正確性、完全性、信頼性については一切保証されません。Zscalerは、ブログ内の情報の誤りや欠如、またはその情報に基づいて行われるいかなる行為に関して一切の責任を負いません。また、ブログ内でリンクされているサードパーティーのWebサイトおよびリソースは、利便性のみを目的として提供されており、その内容や運用についても一切の責任を負いません。すべての内容は予告なく変更される場合があります。このブログにアクセスすることで、これらの条件に同意し、情報の確認および使用は自己責任で行うことを理解したものとみなされます。
