このコンテンツは自動機械翻訳サービスによる翻訳版であり、皆さまの便宜のために提供しています。原本の英語版と異なる誤り、省略、解釈の微妙な違いが含まれる場合があります。ご不明な点がある場合は、英語版原本をご確認ください。
Cloudflareプラットフォームは、Cloudflareにとって極めて重要なシステムです。当社は自社のカスタマーゼロであり、自社の製品を使って自社サービスを安全にし、最適化しています。
セキュリティ部門では、専任のCustomer Zeroチームが独自のポジションを活かして、常に忠実度の高いフィードバックループを製品およびエンジニアリングに提供し、製品の継続的改善を推進しています。 そして、これはグローバル規模で行われますので、1つの設定ミスが数秒でエッジ全体に伝播し、意図しない結果につながる可能性があります。たった1つの小さなミスが重要なアプリケーションから従業員をロックアウトしたり、本番サービスを停止させたりする可能性があることを知って、本番環境への変更を躊躇したことがあるなら、その気持ちはわかります。意図しない結果のリスクは現実的であり、夜も眠れません。
これには興味深い課題があります。人的ミスを最小限に抑えながら、数百もの内部本番Cloudflareアカウントを一貫して保護する方法は？
Cloudflareのダッシュボードは可観測性と分析には優れているものの、数百ものアカウントを手動でクリックしてセキュリティ設定が同じであることを確認するのは間違いです。私たちの健全性とセキュリティを維持するために、設定を手作業のポイントアンドクリックタスクとして扱うのを止め、コードとして扱うようになりました。当社は、「シフトレフト」の原則を採用し、セキュリティチェックを開発の最も早い段階に移動させました。
これは当社にとって抽象的な企業目標ではありません。インシデントが起こる前にエラーをキャッチするためのサバイバルメカニズムであり、ガバナンスアーキテクチャを根本的に変える必要がありました。
「シフトレフト（Shift left）」は、ソフトウェア開発ライフサイクル（SDLC）において検証手順をより早い段階で移動させることを指します。現実的には、テスト、セキュリティ監査、ポリシーコンプライアンスチェックを、継続的インテグレーションおよび継続的デプロイメント（CI/CD）パイプラインに直接統合することを意味します。マージリクエストの段階で問題や設定ミスを検知することで、デプロイ後に発見するのではなく、修正コストが最も少ない時に問題を特定します。
Cloudflareでシフトレフトの原則を適用する際、4つの重要な原則が注目されます。
一貫性: 設定はアカウント間で簡単にコピーして再利用できる必要があります。
スケーラビリティ：大規模な変更は、複数のアカウントに迅速に適用できます。
Observability：設定は、現在の状態、正確性、セキュリティを誰でも監査できる必要があります。
ガバナンス：Guardrailsは事前予防的である必要があります。つまり、インシデントを避けるために、デプロイ前に強制適用するのです。
このモデルをサポートするために、すべての本番アカウントをInfrastructure as Code（IaC）で管理するように移行しました。すべての変更は追跡され、ユーザー、コミット、および内部チケットに結びつけられます。チームは引き続きダッシュボードを使用して分析やインサイトを確保しますが、本番環境での重大な変更はすべてコードで行われます。
このモデルは、すべての変更をピアレビューすることを保証し、ポリシーはセキュリティチームによって設定されますが、所有するエンジニアリングチームによって実装されます。
このセットアップは、TerraformとカスタムCI/CDパイプラインの2つの主要なテクノロジーに基づいています。
当社がTerraformを選択した理由は、成熟したオープンソースエコシステム、強力なコミュニティサポート、Policy as Codeツールとの深い統合にあります。さらに、Cloudflare Terraform Providerを社内で使用することで、ユーザーのために積極的にドッグフーディングし、ユーザーのために体験を改善することができます。
数百のアカウントと1日あたり約30件のマージリクエスト規模に対応するため、CI/CDパイプラインはGitLabと統合されたAtlantisで稼働しています。また、ステートファイルを安全に保存するためのブローカーとして機能するカスタムgoプログラムであるtfstate-butlerを使用することもできます。
tfstate-butlerは、TerraformのHTTPバックエンドとして動作します。設計の主な推進要因はセキュリティでした。ステートファイルごとに一意の暗号化キーを確保し、潜在的な侵害の影響範囲を制限することができるからです。
すべての内部アカウント構成は、中央管理型のmonorepoで定義されます。個々のチームが特定の設定を所有およびデプロイし、この中央リポジトリの各セクションの指定されたコード所有者であることから、説明責任を確保します。この構成の詳細については、CloudflareがTerraformを使用してCloudflareを管理する方法をご覧ください。
コードとしてのインフラストラクチャのデータフロー図
シフトレフト戦略全体の要点は、すべての社内本番Cloudflareアカウントの強力なセキュリティベースラインを確立することです。ベースラインは、コードで定義されたセキュリティポリシーの集合です（Policy as Code）。このベースラインは単なるガイドラインではなく、当社がプラットフォーム全体に適用する必要なセキュリティ設定（最大セッション長、必要なログ、特定のWAF設定など）です。
このセットアップでは、ポリシーの適用が手動による監査から自動化されたゲートに移行します。当社では、Atlantis Conftest Policy Checking機能を通じて、Open Policy Agent (OPA)フレームワークとそのポリシー言語であるRegoを使用しています。
Regoポリシーは、すべてのCloudflareプロバイダーリソースのベースラインを構成する特定のセキュリティ要件を定義します。現在、約50のポリシーを維持しています。
たとえば、アクセスポリシーで使用を許可される@cloudflare.comのメールのみを検証するRegoポリシーがあります。
# validate no use of non-cloudflare email
warn contains reason if {
r := tfplan.resource_changes[_]
r.mode == "managed"
r.type == "cloudflare_access_policy"
include := r.change.after.include[_]
email_address := include.email[_]
not endswith(email_address, "@cloudflare.com")
reason := sprintf("%-40s :: only @cloudflare.com emails are allowed", [r.address])
}
warn contains reason if {
r := tfplan.resource_changes[_]
r.mode == "managed"
r.type == "cloudflare_access_policy"
require := r.change.after.require[_]
email_address := require.email[_]
not endswith(email_address, "@cloudflare.com")
reason := sprintf("%-40s :: only @cloudflare.com emails are allowed", [r.address])
}
ポリシーチェックはすべてのマージリクエスト（MR）に対して実行され、デプロイ前に設定が準拠していることを確認します。ポリシーチェックの出力は、GitLab MRのコメントスレッドに直接表示されます。
ポリシーの適用は2つのモードで動作します。
警告：MRにコメントを残しますが、マージは許可されます。
拒否：デプロイメントを完全にブロックします。
ポリシーチェックが、MRで適用されている設定がベースラインから逸脱していると判断した場合、出力はどのリソースがコンプライアンス違反になっているかを返します。
以下の例は、マージリクエストの3つの不一致を特定するポリシーチェックの出力を示しています。
WARN - cloudflare_zero_trust_access_application.app_saas_xxx :: "session_duration" must be less than or equal to 10h
WARN - cloudflare_zero_trust_access_application.app_saas_xxx_pay_per_crawl :: "session_duration" must be less than or equal to 10h
WARN - cloudflare_zero_trust_access_application.app_saas_ms :: you must have at least one require statement of auth_method = "swk"
41 tests, 38 passed, 3 warnings, 0 failures, 0 exception
例外が必要であることは理解していますが、ポリシー自体と同じ厳格さで管理する必要があります。チームで例外が必要な場合は、Jira経由でリクエストを提出します。
Customer Zeroチームによって承認されると、中央例外.regoリポジトリにプルリクエストを送信することで、例外が正式化されます。さまざまなレベルで例外が発生する場合があります：
アカウント：account_xをポリシーyから除外します。
リソースカテゴリ: account_xのすべてのリソース_aをポリシーyから除外します。
特定のリソース: account_xのリソース_a_1をポリシーyから除外します。
この例では、2つの個別のCloudflareアカウントの下にある5つの特定のアプリケーションでのセッション長の例外を示しています。
{
"exception_type": "session_length",
"exceptions": [
{
"account_id": "1xxxx",
"tf_addresses": [
"cloudflare_access_application.app_identity_access_denied",
"cloudflare_access_application.enforcing_ext_auth_worker_bypass",
"cloudflare_access_application.enforcing_ext_auth_worker_bypass_dev",
],
},
{
"account_id": "2xxxx",
"tf_addresses": [
"cloudflare_access_application.extra_wildcard_application",
"cloudflare_access_application.wildcard",
],
},
],
}
私たちの道のりは障害がなかったわけではありません。何年ものクリック操作（ダッシュボード内で直接行う手動変更）が、何百ものアカウントに散在していました。既存のカオスをコードシステムとして厳格なインフラストラクチャにインポートしようとすることは、まるで動いている車のタイヤを交換しようとしているような感じでした。現在まで、リソースのインポートは継続的なプロセスとして続いています。
自社ツールの限界にも直面しました。Cloudflare Terraformプロバイダーには、この規模のインフラストラクチャを管理しようとする場合にのみ発生するエッジケースが見つかりました。これは、ほんのわずかな速度のバンプではありませんでした。彼らは、自社のドッグフーディングの必要性を痛感させられ、それにより、より良いソリューションを構築することができました。
この摩擦によって、私たちが立ち位置が何であるかが明確になり、3つの努力の教訓につながりました。
大規模なIaCの展開における最初の課題は、手動で設定された既存のリソースのオンボーディングです。チームには、Terraformリソースを手動で作成してブロックをインポートする方法と、cf-terraformingを使用する方法の2つの選択肢がありました。
Terraformの流暢性はチームによって異なることがすぐにわかり、既存のリソースを手動でインポートするための学習曲線は、私たちが予想していたよりもはるかに急であることが判明しました。
幸いなことに、cf-terraformingコマンドラインユーティリティは、Cloudflare APIを使用して、必要なTerraformコードとimportステートメントを自動的に生成し、移行プロセスを大幅に加速します。
また、経験豊富なエンジニアがチームをガイドしてプロバイダーの微妙な違いなどを説明し、複雑なインポートを解除する手助けをする社内コミュニティも形成しました。
また、緊急の変更を促すためにIaCプロセスがバイパスされるときに発生する設定のドリフトにも対処しなければなりませんでした。ダッシュボードで直接編集を行うと、インシデント発生時に迅速に作業できますが、Terraformの状態を現実と同期したままではありません。
Terraformで定義された状態と、Cloudflare APIを介して実際にデプロイされた状態を常に比較する、カスタムドリフト検出サービスを実装しました。ドリフトが検出されると、自動システムが内部チケットを作成し、さまざまなサービスレベル契約（SLA）とともに所有チームに割り当てて修正します。
Cloudflareは革新が速く、製品やAPIは増え続けています。残念ながら、それは私たちのTerraformプロバイダーが製品との機能パリティの観点で後れを取ることがあったことを意味しました。
この問題は、OpenAPI仕様に基づいてTerraformプロバイダーを自動生成するv5プロバイダーのリリースにより解決しました。この移行には、コード生成へのアプローチを強化したため、問題が生じましたが、このアプローチにより、APIとTerraformが同期され、機能がドリフトする可能性が減ります。
セキュリティベースラインを一元化し、ピアレビューを義務付け、変更を本番環境に適用する前にポリシーを適用することで、設定ミス、偶発的な削除、ポリシー違反の可能性を最小限に抑えます。このアーキテクチャは手作業によるミスを防ぐだけでなく、チームが変更をコンプライアンスに準拠していると確信できるため、エンジニアリングのベロシティを向上させるのに役立ちます。
Customer Zeroとの取り組みから得られた重要な教訓は次のとおりです。Cloudflareダッシュボードは日常的な運用には優れているものの、エンタープライズレベルの規模と一貫したガバナンスを実現するには、異なるアプローチが必要であるということです。Cloudflare設定を実行するコードとして扱うことで、安全かつ自信を持ってスケーリングできます。
コードとしてのインフラストラクチャに関するご意見をお聞かせくださいcommunity.cloudflare.comで会話を続け、あなたの経験を共有してください。