Zscalerのブログ
Zscalerの最新ブログ情報を受信
購読するHashiCorp Terraformを使用したZscaler Infrastructure as Codeの管理
Infrastructure as code (IaC)
セキュリティの世界は自動化の価値を理解しています。手作業を排除し、環境の変化に基づいてポリシーを自動的に更新することで、管理作業を削減でき、セキュリティ体制が改善します。また自動化により、組織は新しいテクノロジーの採用、環境の更新または拡張からベスト プラクティスの改訂などから生じる変化により迅速に適用できるようになります。ネイティブなテンプレート テクノロジーをサードパーティ製ツール (Terraform など) と組み合わせると、アプリケーション開発フレームワークにセキュリティを簡単に埋め込むことができます。
コードで構成を書くことで、設定の一貫性を保ち、エラーを招く機会が減り、デプロイメント間の偏差を軽減できます。
組織内のただ一人のエンジニアが、そのデプロイメント プロセスの唯一のナレッジ ソースであった時を想像してみてください。そのエンジニアの退職により当人がもっている知識失われ時、いかに大変だったかを覚えていますか？おそらく、残りのチーム メンバーらは、失われた情報を見つけるために奔走する必要があったでしょう。
インフラストラクチャーをコードとして定義することで、このプロセスはチーム全員にチーム全体のために文書化されます。エンジニア達は、一元化されたコードを見て、各種サービスとプロセスがどのように紐づけられているかを読み取ることができ、貴重な知識を失うリスクを最小限に抑えることができます。情報は個別に文書化することもできますが(たとえば、Wiki内で)、正しい情報を見つけようとするのがいかに困難かは誰もが知っています。Infrastructure as Code (IaC) は、これらの懸念に対処し、さらに重要なことに、効率を高めるための戦略を提供します。
Terraformを選ぶ理由
HashiCorpのTerraformは、コードを通じて反復可能なクラウド インフラストラクチャーの定義と作成に使用される最も人気があり拡張可能なオープン ソース ツールの1つです。Terraformにより、HashiCorp Configuration Language(HCL)を使ってインフラストラクチャーとサービスを構成できるようになります。
プロバイダーは、リソースの作成、更新、および削除に必要な各種のAPI と相互作用します。Terraform は、AWS、GCP、Azure などのプロバイダーを通じてインフラストラクチャーを管理するために使用されますが、サービスとしてのプラットフォーム (PaaS) やSoftware as a Service (SaaS)のリソース管理にも使用できます。
Terraform を使って Zscaler 環境を管理する上での一般的なアイデアとは、Zscaler プラットフォームでリソースを作成、編集、削除するための単一のソースとしてTerraformを利用することです。自社のクラウド インフラストラクチャーの他の部分を定義するために選択したツールとして Terraform を使用している組織は、当然のように、すべてのリソース構成を 1 か所で定義できるようにZscaler 環境を構成することを好むようです。
Terraformが実行されるたびに、使用しているサービス構成に関する情報が保存されます。デフォルトでは、この情報は terraform.tfstate という名前のファイルにローカルで保存されるか、チーム環境で使用するためにリモートで保存することもできます。
Terraform プロバイダーはお使いの Zscaler 環境に何を提供できるのでしょうか？
ZPAとZIAを自社のゼロトラスト プラットフォームとして使用する組織は、これらの製品の一方または両方をその継続的インテグレーション(CI)、継続的デリバリー(CD)、および開発パイプラインに簡単に統合できます。
Zscaler プラットフォームを使用すると、管理者は使いやすい管理者用 UI と API を介して複数の設定を柔軟に構成できます。ただし、大規模な構成の管理は常に困難であり、API を介して行われた変更によって管理者用UIで行われた設定が上書きされたり、その逆が行われたりすることもあります。これにより、IaC アプローチを使って構成設定を管理するチームと、コードを書く必要がなく管理者用UI を介して設定のチェックと修正を迅速に行える自律性を必要とする管理、セキュリティ、および IT チームの間で競合が発生します。
どちらかのアプローチを選択するのではなく、Terraformを介して行われた変更は、ZPAおよび/またはZIAコンソールにすぐに表示されます。逆に、ZPA および ZIA 管理者用ダッシュボードが意図的に (または誤って) Terraform によって管理される設定を変更するために使用されると、その変更は次回の実行時に 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 クラウドのリモート状態ストレージ機能を使用して、更新または変更を行う際に必要な状態ファイルを使用できます。これにより、セキュアなストレージと組織の状態ファイルへアクセスできるようになり、構成ミスやエラーの発生リスクが軽減されます。
これらの種類の変更は今まで識別が困難でしたが、Terraformは次回の実行時に不要な変更を特定できます。
構成ドリフトに関連するリスクの詳細については、当社の記事「開発者ワークフローへのInfrastructure as Code (IaC)の埋め込みによるインフラストラクチャーのセキュリティ保護」をご覧ください。
ユース ケース 3: ポリシーの遵守と管理
Terraform は、特定の種類のリソースをプロビジョニングして使用できるチームを対象とするポリシーを施行する上で役立ちます。ZPAまたはZIAプロバイダーを活用することで、組織は自動化を使用して Zscaler プラットフォームを運営および調整できます。
- ITSM:チケットベースのレビュー プロセスは、開発を遅らせる可能性のあるボトルネックです。代わりに、ServiceNow承認ワークフローの展開を使用したZscaler Private AccessとHashiCorp Terraformで説明されているような統合ワークフローを使用できます。
- ワークスペース管理：組織が ZIA Terraform プロバイダーを活用して、セキュリティ チームが管理するクラウド ファイアウォール モジュールを構成する場合、それらを特定のワークスペースに制限して、その機能に関連付けられていない他の機能やリソースを構成できないようにできます。組織がZPA Terraformプロバイダーを利用している場合も同じことが適用されます：特定のチームがアプリケーション セグメントの変更を実行するように設定し、一方で他のチームがアクセス ポリシーを作成または変更できるようにできます。
Terraform を使用することで、Zscaler のお客様はセキュリティをより容易にに自動化し、そのCI/CD パイプラインの一部として IaC を採用する際に、セキュリティがアプリケーション環境のすべての側面に一貫して組み込まれるようにできます。このシフト レフト アプローチにより、開発チームとセキュリティチーム間の摩擦が軽減され、迅速なアプリケーション展開が可能になり、セキュリティ体制が向上します。
ZPAおよびZIAプロバイダーの詳細については、HashiCorpのTerraformサイトにあるプロバイダーのドキュメントを参照してください。ZPAおよびZIAプロバイダー プロジェクトに質問や意見がある場合は、GitHub上のリポジトリーにアクセスしてください。
参考資料
