SSLとZendeskの連携で強化する安全なカスタムドメイン設定法

目次

はじめに

この記事は、ZendeskでのSSL(通信の暗号化)設定と運用について、わかりやすく解説する入門記事です。

読者対象は、Zendeskを利用するサポート担当者やシステム担当者、これからカスタムドメインで運用を始める方です。専門的な前提知識がなくても理解できるよう、用語は最小限にし、具体例を交えて説明します。

本記事で扱う主な内容は以下の通りです。

  • Zendeskの標準的なSSL対応の仕組み
  • カスタムドメイン(ホストマッピング)でのSSL証明書の選択肢
  • 証明書の取得と設定手順(実務で使える手順)
  • SSL以外のセキュリティ強化策や運用時の注意点

「設定方法がわからない」「どの証明書を選べばよいか悩んでいる」といった疑問にお答えします。この記事を読むことで、ZendeskのSSL運用の基本がつかめ、実際の設定や運用に自信を持って臨めるようになります。

検索キーワード「ssl zendesk」の意図

“ssl zendesk”と検索する人は、Zendeskにおける通信の安全性や独自ドメインでの表示に関する情報を求めています。主な意図は次の3つに分かれます。

  • ZendeskのSSL運用方法を確認したい
  • サービス側で自動でSSLが有効になるのか、自社で証明書を用意する必要があるのかを知りたいです。例:ヘルプセンターのURLがhttpsになるかどうか。

  • カスタムドメイン(ホストマッピング)でのSSL対応を調べたい

  • 独自ドメインを使う際に必要な設定や、どの種類の証明書が使えるかを知りたいです。例:support.example.comを安全に公開する手順。

  • セキュリティ強化・ベストプラクティスを把握したい

  • 証明書の更新方法や有効期限、ブラウザ警告を回避する方法など運用上の注意点を知りたいです。例:証明書切れを防ぐ監視方法。

想定ユーザーは、Zendeskを管理する担当者(IT管理者・サポートリーダー)、ウェブ担当、外部の開発・運用パートナーです。それぞれが直面する具体的な疑問(設定手順、費用、運用負担、トラブル対応)を踏まえて、実務に役立つ情報を求めています。次章以降では、これらのニーズに沿って具体的な選択肢と手順を丁寧に解説します。

ZendeskのSSL対応概要

本章の趣旨

Zendesk上の通信がどのようにSSL/TLSで保護されるかを分かりやすく説明します。公式サブドメインとカスタムドメインで扱いが異なる点を押さえましょう。

公式サブドメイン(例:mycompany.zendesk.com)

公式サブドメインはZendesk側で自動的にSSL化されます。管理者側で証明書を用意したり設定を行ったりする必要はありません。ブラウザのアドレスバーに鍵マークが出れば安全に通信できています。

カスタムドメイン(ホストマッピング)との違い

カスタムドメインを使う場合は設定が少し増えます。カスタムドメインをZendeskに向けるためのDNS設定(CNAMEなど)が必要です。SSLについてはZendeskの管理下で証明書を自動発行する方法と、自分で取得した証明書を使う方法があります。どちらを選ぶかで設定手順や更新の手間が変わります。

管理者が押さえるべきポイント

  • 公式サブドメインは操作不要で常に保護されます。
  • カスタムドメインはDNS設定と証明書の管理が必要です。
  • ページ内の画像やスクリプトがHTTPだと警告が出ることがあるため、混在コンテンツには注意してください。

カスタムドメイン(ホストマッピング)でのSSL証明書の選択肢

選べる主な2つの方法

  • Zendesk提供のSNIベース無料SSL証明書(最大100個まで)
  • ユーザーが用意するSNIベースのSSL証明書(期限管理はユーザー責任)

両者に共通する要点

  • どちらもSNI(サーバー名インジケータ)対応が必須です。古いクライアントやサーバーでは接続できない場合があります。
  • SHA-1など古い暗号化方式はサポート外です。最新のSHA-2系証明書を使ってください。

Zendesk提供のメリット・注意点

  • メリット:設定が簡単で自動更新されます。運用負担を減らせます。
  • 注意点:提供枠(最大100ホスト)を超えると使えません。また、細かい証明書ポリシー(EVなど)を選べない場合があります。

ユーザー提供のメリット・注意点

  • メリット:発行元や種類(EV、ワイルドカード等)を自由に選べます。会社のポリシーに合せられます。
  • 注意点:証明書の期限や更新作業は自社で管理する必要があります。失効を防ぐための運用ルールを用意してください。

選び方の目安

  • 手間を減らしたい中小規模ならZendesk提供が向きます。
  • EVや特定のCA、ワイルドカードが必須なら自前の証明書を用意してください。

カスタムドメインSSL証明書の取得・設定手順

以下は、例として support.mycompany.com を使った手順です。できるだけ実務で使えるよう簡潔に説明します。

1. 独自ドメインの用意とサブドメイン決定

ドメインを取得し、サブドメイン(例:support.mycompany.com)を用意します。ドメインの管理権限があることを確認してください。

2. DNS設定(CNAME登録)

ホスティング側のDNSでサブドメインに CNAME を追加し、Zendeskが指定するターゲット(例: yoursubdomain.zendesk.com)を指すようにします。TTLは短め(300秒など)にすると反映確認が早くなります。

3. Zendesk管理画面でホストマッピング設定

Zendeskの管理画面(ヘルプセンター/Guide設定)でホストマッピング(カスタムドメイン)を追加します。入力欄にサブドメインを入れると、指示が表示されます。DNSが正しく設定されると検証が通ります。

4. SSL証明書の選択と設定

  • Zendesk管理の無料証明書(Zendesk管理/自動更新)を選べば手間が少ないです。運用上はこちらを推奨します。
  • 独自証明書を使う場合は、証明書(PEM形式)、秘密鍵、そして中間証明書チェーンを準備してZendeskにアップロードします。CSRの作成は一般的なサーバーツールで行います。期限管理はご自身で行ってください。

5. 有効性確認と運用チェック

  • SSL Labsなどの外部ツールで証明書チェーン、共通名(SAN)、有効期限を確認します。
  • ブラウザでHTTPS接続、リダイレクト(http→https)、混在コンテンツがないかを確認してください。
  • 反映にはDNS伝搬や証明書発行の時間がかかることがあるため、最大で24〜48時間待って再確認してください。

よくある注意点(簡潔に)

  • CNAMEをAレコードで設定してしまう、または中間証明書をアップロードし忘れるとエラーになります。
  • 自動更新が必要ならZendesk提供の証明書を選ぶと運用負担を下げられます。

SSL以外のZendeskセキュリティベストプラクティス

概要

SSLは重要ですが、それだけで全てのリスクを防げません。Zendeskを安全に運用するため、認証・権限・連携・監査の面での対策を組み合わせます。

SAML/SSOの導入

Google WorkspaceやTrustLoginなどのIdPと連携してSAML/SSOを有効にします。これにより社内IDで一括管理でき、アカウントの新規発行や無効化が素早く行えます。具体的にはZendeskの管理画面でSAML設定を登録し、IdP側でアプリを作成します。

スタッフ・エンドユーザーごとの認証設定

スタッフにはSSOと2要素認証(2FA)を必須にします。外部ユーザーは必要に応じてメール認証やSNSログインを使い分けます。役割ごとにアクセス範囲を絞ることで被害を限定できます。

パスワードポリシーと二要素認証

パスワード長や有効期限のルールを設定し、2FAを全スタッフに展開します。認証アプリを推奨し、SMSは補助手段に留めます。

不要な外部連携の無効化とAPI管理

使っていないアプリやOAuth連携は無効にします。APIトークンは最小権限で発行し、定期的にローテーションします。

監査ログと定期レビュー

管理ログ・監査ログを有効にしてログを定期確認します。定期的にアカウント権限と連携一覧を見直し、不審な挙動があれば速やかに対処します。

教育と運用ルール

現場での誤操作を防ぐために運用ルールを文書化し、スタッフ教育を行います。これにより運用リスクを減らせます。

SSL設定・運用時の注意点

証明書の有効期限管理

証明書の期限切れはサービス停止につながります。自社で証明書を発行する場合は、発行日と有効期限をカレンダーや監視ツールで管理してください。自動更新が使える場合は積極的に設定し、期限前にテスト環境で更新手順を確認します。手動更新では最低でも30日前に担当者へアラートを出す運用をおすすめします。

暗号化方式とアルゴリズム

SHA-2(例: SHA-256)対応の証明書を選んでください。SHA-1など旧式のハッシュは避けます。鍵長は2048ビット以上を基準にし、可能であればECDSAなど新しい方式も検討します。旧式プロトコル(SSLv3、古いTLS)は無効化してください。

証明書チェーンとOCSP Stapling

中間証明書が正しく設定されているか確認します。チェーンが抜けると警告が出ます。OCSP Staplingを有効にすると検証が速く安定します。

プライベートキーの管理

プライベートキーは厳重に保管し、アクセス権を限定してください。秘密鍵が漏れると証明書を取り消す必要が出ます。HSMや専用のキーストア利用を検討します。

運用時の外部チェックと脆弱性確認

SSL Labsや同様の外部ツールで定期的にスキャンし、設定の評価や脆弱性を確認します。脆弱性が見つかったら速やかに修正し、回帰テストを行います。

混在コンテンツ・リダイレクト・HSTS

サイト内でHTTP資源が混在するとブラウザがブロックします。すべてHTTPSへリダイレクトし、HSTSを段階的に導入してください。HSTSは有効期限やプリロードを慎重に設定します。

ワイルドカード/SANの選択と運用

ワイルドカード証明書は管理が楽ですが、広範囲で使うほどリスクが増します。用途に応じてSAN(複数ドメインを列挙)と使い分けしてください。

監視と手順書

期限通知、更新手順、障害対応フローを文書化し、オンコール担当者がすぐ動ける体制を作ります。定期的に模擬更新やリカバリ訓練を行ってください。

まとめと運用のポイント

要点のまとめ

  • 公式サブドメイン(*.zendesk.com)はZendesk側が自動でSSLを管理します。運用負荷が少なく、まずはこちらを検討してください。
  • カスタムドメインを使う場合は、Zendeskの無料自動証明書か自分で用意する証明書を選べます。簡単さを優先するなら自動証明書が便利です。

運用チェックリスト

  • 証明書の有効期限を定期確認(自動証明書はZendeskが更新します)。
  • カスタムドメインはDNS設定(CNAME)を正しくする。
  • HTTPSリダイレクトを有効にして常に暗号化通信にする。
  • サポートメールやAPI鍵は最小権限で管理する。

トラブル時の対応

  • ブラウザで「鍵マーク」が表示されない場合、まずDNSと証明書の適用状況を確認します。
  • サービス障害が疑われる時はZendeskのステータスページやサポートに問い合わせてください。

運用のポイント(実務向け)

  • ロール分離とログ監視を導入し、設定変更の追跡を習慣にします。
  • 証明書更新の通知をチームで共有し、担当を決めておきます。
  • 定期的にSSL/TLSの設定を簡易チェックツールで点検します。

まとめると、まずは公式サブドメインで始め、必要に応じてカスタムドメインと証明書管理を検討してください。運用ルールと担当を決めておくと安定運用につながります。

よかったらシェアしてね!
  • URLをコピーしました!

この記事を書いた人

目次