セキュリティの世界は自動化の価値を理解しています。手作業を排除し、環境の変化に基づいてポリシーを自動的に更新することで、管理作業を削減でき、セキュリティ体制が改善します。また自動化により、組織は新しいテクノロジーの採用、環境の更新または拡張からベストプラクティスの改訂などから生じる変化により迅速に適用できるようになります。ネイティブなテンプレートテクノロジーをサードパーティ製ツール (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上のリポジトリーにアクセスしてください。

参考資料