オンライン事業者にとって、SSL／TLS暗号化を採用することは、従来セキュリティ上のベストプラクティスでしたが、より安全なインターネットの構築を目指す大手テクノロジー企業からの圧力によって、これが必須要件となりつつあります。たとえば、Google ChromeのWebブラウザーでは、2016年末より、HTTPSを使用しないWebサイトをユーザーに「安全でない」と明示するようになりました。それと同時に、MozillaのFireFoxのWebブラウザーでは、HTTPSによって保護されていない情報フォームを提出しようとするユーザーに対して、深刻な警告を出すようになりました。2
このフォームを送信することにより、お客様はCloudflareのプロダクト、イベント、特別オファーに関連する情報を受け取ることに同意したものとみなされます。いつでも、メッセージの配信を停止することができます。Cloudflareは決してお客様のデータを販売することはなく、みなさまのプライバシーに関する選択を尊重します。詳細情報につきましては、プライバシーポリシーをお読みください。
CloudflareのSSL for SaaSでは、SaaS企業のエンドカスタマーはカスタムバニティドメインを使用したまま、SSLによる通信を確保できます。エンドカスタマーのメリットには、ブランド名が含まれる訪問者の体験、信頼性の向上、SEOランキング、HTTP/2を使用した高速化などがあります。Cloudflareでは、購入から導入までのSSLライフサイクル全体を自動化しており、証明書の更新は数分で完了するため、顧客のオンボーディングフローの一環として、SaaS企業はこのメリットを提供できます。
SSLを使用しないカスタムバニティドメインは、SSLによるパフォーマンスの利点がなく安全にデータを転送できません。のぞき見に対して脆弱なために訪問者が閲覧する前にコンテンツが編集されたりインジェクション攻撃を受けるおそれがあります。
SaaSプロバイダーを通じてSSLに対応済みでカスタムバニティドメインでないドメインは結果的にブランド力やSEOランキングが低くなります。
暗号化したうえでブランド名を含むバニティドメインを希望するSaaSプロバイダーはSSLのライフサイクルを手動で管理することができますが、展開期間が長期に及んで間接費がかかるか、複雑な自動ソリューションを社内で構築する結果になります。
Cloudflareにお問い合わせください。
ブランド名の含まれる訪問者の体験
ブランド名が含まれるカスタムドメインをエンドカスタマーに提供するオプションを持つSaaSプロバイダーは、それを継続したまま完全に管理されたSSL証明書の追加メリットを得ることができます。ブランド名が含まれるドメインは、エンドカスタマーに高いSEOランキングを提供し、訪問者の信頼を向上させます。
顧客資産の安全性とパフォーマンスを確保
エンドカスタマードメインのSSL/TLS証明書は、重要な顧客データの安全な転送を保証し、中間者攻撃やネットワークのスヌーピング（のぞき見）を防ぎます。さらに、HTTP/2プロトコルを使用することで、さらに高速になります。
SSLライフサイクルの自動管理
Cloudflareは、SaaSプロバイダーが提供する顧客のバニティドメインのSSLのライフサイクル全体において、プライベートキーの作成や保護から、ドメインの検証、発行、更新、再発行にいたるまで管理します。
グローバルSSLを迅速に展開
SSL発行のプロセス中に、Cloudflareは200都市にあるデータセンターのグローバルネットワークに新しい証明書をデプロイし、訪問者に可能な限り近い場所で数分以内にHTTPSが使用可能になります。
カスタムバニティドメイン向けの社内SSLソリューションを構築するためには、2つの方法があります。ただし、どちらもSaaSプロバイダーとエンドカスタマーの両者に大きな負担がかかります。下図の自動化されたパス（上部）はSSLプロセスを自動化しますが、大規模な技術的作業が必要で、数々の複雑なセキュリティの課題も伴います。手動のパス（下部）は、SaaSプロバイダーと顧客の双方の作業が必要となり、証明書有効期限の喪失と停止が見逃される可能性が高くなります。どちらのパスを選択するとしても、大規模なグローバル配信ネットワークにSSL証明書を展開できない限り、パフォーマンスが低下する可能性があります。
HTTPのみのCNAME
SaaSプロバイダーのエンドカスタマーは、CNAMEを設定したカスタムバニティドメインでHTTPトラフィックを送受信しているだけです。
手動で証明書をアップロード
カスタムCNAMEを設定したバニティドメインにSSLを追加するプロセスを開始するために、顧客が手動でアップロードするために購入した証明書をSaaSプロバイダーに送信することで、プロセスが設定されます。
手動で証明書のライフサイクルを管理
顧客の証明書をアップロードする際には、前述の証明書のライフサイクルを処理するために手動による管理が必要となります。これには、プライベートキーの発行や保護から、ドメインの検証、発行、更新、再発行までが含まれます。
API統合（例：Let’s Encrypt使用）の構築
SaaSプロバイダーのサービスを利用しているWebサイトと顧客の合計数が増え始めると、次のいずれかの選択が必要になります。1つはカスタムドメインのSSLライフサイクルプロセスの自動化です。これには高度な技術的作業が必要となります。もう1つは手動によるライフサイクル管理の継続構築です。こちらは技術的作業は少なくて済みますが、社内チームやエンドカスタマーに負担がかかります。
暗号化キーの安全な取り扱い
安全なストレージや暗号化の保存にはプライベートキーが必要です。また、プライベートキーは平文でディスクに書き込まれることはありません。キーの暗号化は簡単ですが、手動による作業または多くの技術的作業が必要となるため、オンザフライで解読することは困難です。プライベートキー管理のベストプラクティスはOWASP.orgに掲載されています。Cloudflareは、Universal SSL、専用証明書、SSL for SaaS製品を使用して、数百万ものドメインのプライベートキーの作成や保護を行うエキスパートです。
グローバルに証明書を配布するネットワーク
世界中に系統的に証明書を配布し、顧客の訪問者に可能な限り近いものを利用できるようにするためには、パフォーマンスの低下を軽減することが必要です。エンドカスタマーの訪問者との距離が遠くなると、ページ読み込み速度は遅くなります。TLS 1.2では、最初のTLSハンドシェイクに2回の往復が必要となり、このハンドシェイクが少数の場所でしか実行されないと、パフォーマンスは低下します。
継続的な保守とサポート続行のための労力（自動パス）
社内のSSLソリューションを構築するにあたり、自動化によるアプローチを選択したSaaS企業における主な保守作業は、コードベースの更新と認証機関の統合や標準との互換性を維持することです。
顧客対応チームの立ち上げ／トレーニング
SaaSプロバイダー企業内の新規または既存のチームは、エンドカスタマーの証明書のライフサイクルを手動で管理する必要があります。顧客対応チームは、期限切れの証明書の更新や新しい証明書の更新を提案するために、顧客に連絡する必要があります。
顧客の作業を伴う手動による更新
顧客は、証明書の更新プロセスに加わり、アップロードプロセスの管理を担当するチームにこれらの証明書を更新して再送信する必要があります。また、この更新プロセスは、既存の証明書の有効期限が切れる前に行う必要があります。既存の証明書の有効期限が切れてしまうと、予防措置が講じられない限り、顧客のインターネットアセットはオフラインになる可能性が高くなります。
継続的な保守とサポート続行のための労力（手動パス）
社内のSSLソリューションを構築するにあたり、手動によるアプローチを選択したSaaS企業における主な保守作業には、プライベートキーの安全な保護、証明書のライフサイクル管理、顧客への更新連絡、新しい証明書の再アップロードなど継続して手動での管理があります。SaaSプロバイダーのエンドカスタマーは証明書のライフサイクルプロセスに加わり、定期的に証明書を更新して再送する必要があるため、負担を負うことになります。
簡単なCloudflare API/UI統合
CloudflareのSSL for SaaSソリューションは、技術的作業を最小限に抑え、SaaSプロバイダーとエンドカスタマーの両者にSSLライフサイクル管理の負担をかけません。
CloudflareがSSL for SaaSのプロセスをすべて行います。SaaSプロバイダーに必要な操作は、エンドカスタマーのカスタムドメインオンボーディングワークフローの一環として、単一のAPI呼び出しを送信するか、Cloudflareのダッシュボード内で数回クリックするのみです。その後、SaaSプロバイダーのエンドカスタマーは、最初のCNAMEをSaaSプロバイダーのドメインに追加するだけです。残りのカスタムドメインのオンボーディングプロセスは、Cloudflareがすべて管理します。
このプロセスの残りの部分はCloudflareによって管理され、以下が含まれます。
Q：顧客のトラフィックはどのように配信元に送信されますか。それは安全ですか。
A：はい、安全です。Cloudflareでは、FullまたはStrict SSLモードの使用を推奨しています。そうすることで、配信元へのトラフィックはHTTPSを使用します。このオプションは、ゾーンのCryptoタブで設定できます。Strictモードを使用している場合は、配信元の証明書に顧客のホスト名と一致するSubject Alternative Names（SAN：サブジェクトの別名）が含まれていることを確認する必要があります（例：support.yourcustomer.site.）CloudflareのOrigin CA製品は、Strictモードでこれらの証明書を作成するために使用できます。
Q：証明書を発行して使用できるまで、どのくらい時間がかかりますか。
A：証明書は通常数分以内に検証・発行され、Cloudflareのエッジにプッシュされます。GETを呼び出すことにより、初期化中、検証保留中、発行保留中、展開保留中、アクティブなどの進行状況を確認できます。
$ curl -sXGET -H "X-Auth-Key: [YOUR KEY]" -H "X-Auth-Email: [YOUR EMAIL]" https://www.cloudflare.com/api/v4/zones/[ZONEID]/custom_hostnames?hostname=support.yourcustomer.site
{ "result": { "id": "cdc2a12a-99b3-48b8-9039-ad1b48c639e5", "hostname": "support.yourcustomer.site", "ssl": { "id": "3463325d-8116-48f3-ab4e-a75fb9727326", "type": "dv", "method": "http", "status": "active" } }, "success": true }
Q：更新や再発行の際に、プロバイダーまたは顧客に必要な手続きはありますか。
A：いいえ。Cloudflareがすべての手続きを代行します。発行する証明書は1年間（365日）有効で、有効期限の少なくとも30日前に自動更新が行われます。これらの証明書は顧客のホスト名で一意的に発行されるため、CNAMEが存在する限り、そのホスト名の「ドメイン検証コントロール」を実証することで簡単に更新を続けることができます。顧客が他のサービスに乗り換えた場合は、CloudflareにDELETE（削除）リクエストを送信してください。Cloudflareがエッジから証明書を引き出すことで、更新を停止できます。
Q：私たちのお客様にとって、Cloudflareを使うメリットは何ですか。
A：（Cloudflareの権威ネームサービスをご利用ではない）顧客のDNSインフラストラクチャの保護を除いて、お客様はすべてのメリットを受けることができます。トラフィックがホワイトラベル化されたホスト名へと向けられると、Cloudflareが業界をリードするDDoS保護、CDN、WAF、HTTP/2、負荷分散などをご提供できるようになります。
Q：私たちのお客様がすでにカスタムホスト名でHTTPSを使用している場合はどうなりますか。移行中にダウンタイムを避ける方法はありますか。
A：顧客から提供されたキーマテリアルに基づいて、すでに内部的にソリューションを組み合わせている場合があります。または、顧客がHTTPSを提供する競合他社（または社内ソリューション）で希望のホスト名を使用していて、短期の保守期間が許容されない場合もあります。
このようなケース向けに、SSL for SaaS製品（メールとCNAME）の専用証明書に利用できる、2つの代替の「事前検証」の手法をご用意しました。上のAPI呼び出しでSSLの手法を「http」から「email」または「cname」に変更してリクエストを送信するだけです。詳細については、APIの資料を参照してください。
他の代替手法であるCNAMEトークンは、一般的にバニティネームのDNSをコントロールする際に使用されます（SaaSの一部の顧客、特にWebサイトの構築サービスやホスティングサービスを提供する顧客の一部で、カスタムドメインをワークフローの一部として登録できるようにします）。
最後に、配信元の「http」検証手法によって返されたHTTPトークンを自由に提供できます（Cloudflareがリバースプロキシ中に挿入するのではなく）。Cloudflareの自動再試行キューは、実行された時点で検出します。いったんCloudflareを実行してすぐに再試行を希望する場合は、POST中に送信したのと同じSSL本体を使用してPATCHをエンドポイントに送信すると、Cloudflareはただちにチェックを行います。
1 https://motherboard.vice.com/en_us/article/google-chrome-shaming-http-unencrypted-websites-january
2 https://blog.mozilla.org/security/2017/01/20/communicating-the-dangers-of-non-secure-http/
To provide you with the best possible experience on our website, we may use cookies, as described here.By clicking accept, closing this banner, or continuing to browse our websites, you consent to the use of such cookies.