セキュリティのベストプラクティス

Zendeskでは、プライベート情報を確実に保護し安全性を維持するためのさまざまなセキュリティオプションを提供しています。

この記事のベストプラクティスに従うことで、Zendeskのセキュリティを強化し、セキュリティ侵害のリスクを減らすことができます。ただし、最善のセキュリティポリシーを採用していても、そのポリシーが守られなければ、いつかセキュリティは侵害されます。Zendeskでは、エージェントと管理者がベストプラクティスに従って、確実に安全な運用環境を実現することをお勧めします。

Zendeskシステムのセキュリティについて不審な点がありましたら、Zendeskに直接お問い合わせください。セキュリティ侵害の疑いがある場合は、チケットに詳細を記述し、件名を「セキュリティ」として送信してください。メールにて[e-mail]までご相談ください。

この記事では、次のトピックについて説明します。

• エージェントのパスワードセキュリティを強化する
• ユーザー名、メールアドレス、パスワードは開示してはならない
• 管理者アクセス権を持つエージェントの数を制限する
• Zendeskアカウントを定期的に監査する
• アカウントの監査ログを監視する
• エージェントにユーザーアカウントの監視を勧める
• シングルサインオンのユーザーをリモートで認証する
• IPアドレスの範囲を制限してZendesk Supportへのアクセスを制限する
• REST APIを使用している場合のアクセス制限または安全なコーディング方法への順守
• クレジットカード番号をチケットで非表示にする
• プライベート添付ファイルを有効にする
• フォーラムのスパム対策

エージェントのパスワードセキュリティを強化する

Zendeskが提供するパスワードセキュリティは、「低」、「標準」、「高」のレベルに分かれています。独自のカスタムパスワードセキュリティレベルを指定することもできます。エンドユーザー向けのセキュリティと、エージェント/管理者向けのセキュリティで、異なるレベルを設定することができます。

パスワード要件を強化することで、権限のないユーザーがエージェントのパスワードを推測できないように防御することができます。セキュリティレベルを「高」に設定した場合、エージェントは90日間隔でパスワードの更新を求められます。詳細については、「パスワードのセキュリティレベルの設定」を参照してください。

管理者とエージェントに対しては、Zendeskアカウント専用のパスワードを作成するよう要求してください。つまり、管理者やエージェントは、SalesforceやGoodDataなどの他社のシステムで使用しているパスワードとは異なるパスワードを使用する必要があります。もし、いずれかのアカウントがハッキングされ、パスワードが破られたとしても、ハッカーはハッキングしたアカウント以外にはアクセスできません。

また、エージェントと管理者に2要素認証を要求することもできます。「2要素認証の管理」を参照してください。エージェントガイドの「2要素認証の使用」の記事へのリンクを含んだメッセージをサポートチームに送信することをお勧めします。

ユーザー名、メールアドレス、パスワードは開示してはならない

ユーザーのニーズを満たすことと、セキュリティを維持することの間には微妙な境界がありますが、ベストプラクティスは、Zendeskエージェントと管理者がユーザー名、メール、パスワードを決して開示しないことです。

標準のZendeskログイン認証を使用している場合、パスワードをリセットする唯一の安全な方法は、Zendeskのログイン画面で「パスワードを忘れた場合」リンクをクリックすることです。このリンクをクリックすると、有効なメールアドレス（アカウントの正規のユーザーであることを確認済みのアドレス）を入力するよう求められます。入力したメールアドレス宛に、パスワードをリセットできるリンクが記載されたメールが届きます。

Active Directory、Open Directory、LDAP、SAMLなど、サードパーティ製のシングルサインオン認証システムを使用している場合も、同様の方法でパスワードをリセットできます。

ハッカーは、ユーザーのアカウントのパスワードを強引に聞き出そうとして、ソーシャルエンジニアリングテクニックを使用することがあります。時には、夜間や週末など、上級スタッフの配置が普段より手薄になりそうな時間帯を狙って、カスタマーサービスの担当者に問い合わせることもあります。ハッカーは、セキュリティ侵害が発生したためパスワードをすぐに変更する必要があると訴え、変更する新しいパスワードを自ら提示するかもしれません。

一部のハッカーは、ユーザーになりすますために、メールが正規のドメインから送信されたかのようにメールアドレスを偽装するツールを備えています。そのようなツールを使用して送られたメールは、ユーザーからの正規のメールリクエストのように見えても、実際には別のアドレスから送信されている場合があります。誰かが、問い合わせを行った本人あるいはその管理者であると申し立てている場合、IPアドレス（チケットのイベントまたは通知ビューに表示される）を書きとめ、本人の身元を別途確認してください（ユーザープロフィールにある連絡先電話番号に電話を掛けてみるなど）。疑わしい場合は、決して機密情報を提供したり、ユーザーの代理でアカウントを変更したりしてはなりません。正規のユーザーであれば、前述の方法を使用して、アカウント設定を自分で変更できるはずです。

この種のセキュリティリスクについてエージェントを教育すること、そしてこのような事象が発生したときに参照できるようにセキュリティポリシーを作成し、社員全員に周知することをお勧めします。

管理者アクセス権を持つエージェントの数を制限する

メモ：Enterprise以上のプランでは、エージェントの追加権限やカスタムエージェントロールを利用できます。

管理者は、標準のエージェントがアクセスできないZendeskの領域にアクセスできます。たとえば、本書で説明しているセキュリティ機能をすべて使用できるのは管理者だけです。管理者アクセス権を持つエージェントの数を制限することで、セキュリティ上のリスクを緩和できます。エージェントロールでは、標準的なエージェントがチケットの管理と解決を行うのに必要なアクセス権が提供されます。

既定のエージェントロールを選択することで、エージェントのアクセス権限を拡張することができます。また、カスタムのエージェントロールを独自に作成し、エージェントロールがアクセスできるZendesk Supportの領域を指定することもできます。ただし、これらのアクセス許可は、Zendesk Supportのユーザー、チケット、フォーラム、およびワークフロー管理の領域のみに制限されています。たとえば、セキュリティ設定へのアクセスは、アカウントオーナーと管理者だけに制限されています。

エンドユーザーに関する情報にエージェントがアクセスすることに懸念がある場合は、ロールを作成し、そのロールにエンドユーザーのプロフィールの編集と、全エンドユーザーの一覧の閲覧を禁止することもできます。アクセスを禁止するには、以下の2つのアクセス許可を設定します。

• 「このエージェントはエンドユーザーのプロフィールに対してどのようなアクセス許可を持っていますか？」を「読み取り専用」に設定します。
• 「このユーザーはユーザープロフィールのリストを表示できますか？」を「ユーザーを参照または検索することはできない」に設定します。

詳しくは、「カスタムロールの作成とエージェントの割り当て」を参照してください。

Zendeskアカウントを定期的に監査する

前述のテクニックをすべて採用していれば、Zendeskアカウントの機密情報は常に安全に保たれます。それでも、ベストプラクティスとしては、不審な活動が行われていないか定期的にチェックした方がよいとされています。次のチェックリストを月に1回以上使用し、システムに脆弱性を残すようなミスがなかったことを確認してください。

• エージェントのアクセスとロールをチームメンバーページで確認し、知らないエージェントや管理者がいないか、会社のドメインに見慣れないメールアドレスがないかを確認する。
• メールアーカイブを使用している場合は、そのメールアドレスが正規のものであることを確認してください。「チケットメール通知のアーカイブ」を参照してください。
  メモ：メールアーカイブは、Enterprise以上のプランで利用できます。
• ブランド設定ページのロゴのURLが正しく、改変されていないことを確認する。
• 使用しているすべてのターゲットが有効であり、既知の正しいアドレスを指していることを確認する。「外部ターゲットへの通知」を参照してください。
• 通知を送信するすべてのターゲットおよび自動化を見直し、通知の宛先が正しいことを確認する。

これらのイベントが発生すると、ほとんどの場合は、自動的にすべての管理者に通知されますが、管理者はこれらの通知を適切なメンバーに周知する必要があります。これらのアラート通知の宛先として、Zendesk内にグループを作成することもできます。

アカウントの監査ログを監視する

メモ：監査ログは、Enterprise以上のプランで利用できます。

さまざまなセキュリティイベントを監視できます。たとえば、ユーザーの利用停止、パスワードポリシーの変更、別のユーザーとして代理ログイン、カスタマーデータのエクスポート、カスタムロールの定義の変更や、その他多数のイベントを監視できます。監査ログにより、アカウントに対する重要な変更の大半を追跡できます。詳しくは、「監査ログでの変更の確認」を参照してください。

エージェントにユーザーアカウントの監視を勧める

エージェントロールにはエンドユーザーより高い権限があるため、ハッカーによってZendeskへのアクセス権が不正に取得されたときに、不正アクセスを察知する警報のような役割を果たすことも可能です。侵入者は、それ以降のアクセスを確保するために、新しいメールアドレスを管理者プロフィールに追加し、パスワードのリセットを実行しようとするかもしれません。

Zendeskは、エージェントのパスワードが変更されたときに、エージェントにメール通知を送信します。また、エージェントは初めてのデバイスからログインが行われた場合にメールで警告を送るように設定することで、自分のアカウントを監視できます（Zendeskエージェントガイドで「アカウントにアクセスしたデバイスとアプリケーションの確認」を参照）。不審な場所で初めてのログインが行われた場合、そのデバイスを削除してユーザーセッションを終了させてから、新しいパスワードを設定してください。

シングルサインオンのユーザーをリモートで認証する

Zendeskが提供するユーザー認証に加えて、Zendesk外部でユーザーを認証するシングルサインオンを使用することもできます。これには、ソーシャルメディアシングルサインオンとエンタープライズシングルサインオンの2種類があります。

ソーシャルメディアシングルサインオンは追加のログインオプションで、これを使用するとカスタマーの利便性が向上します。たとえば、ヘルプセンターのサインインページで、FacebookやGoogle、Twitterのログインを提供できます。カスタマーは、Zendeskアカウントだけでなく、いずれかのソーシャルメディアアカウントを使用して、Zendeskにログインすることができます。

エンタープライズシングルサインオンは、ソーシャルメディアシングルサインオンとは異なります。エンタープライズシングルサインオンは、オプションではなく、Zendeskアカウントログインに追加されることもありません。他のすべてのログインオプションに取って代わるものです。管理者のZendeskアカウントでこの機能を有効にすると、ヘルプセンターのサインインページはカスタマーに表示されなくなり、使用できなくなります。代わりに、カスタマーは社内ネットワークにログインしてリンクをクリックするだけで、Zendesk Supportに自動的にログインしてアクセスできるようになります。すべてのユーザー管理と認証は、Zendeskの外部で行われます。Zendeskでは、SAML（Secure Assertion Markup Language）およびJWT（JSON Web Token）を使用したシングルサインオンがサポートされます。

JWTベースまたはSAMLベースのSSOを使用する場合はユーザーのメールアドレスの確認など、ユーザーの身元確認の責任を負うことになることを覚えておいてください。ユーザーとそのメールアドレスを確認しないと、お客様のアカウントが不正アクセスの危険にさらされ、Zendeskはアカウントのセキュリティを保証できません。

どちらの方法を使用する場合も、エンタープライズシングルサインオンまたはソーシャルメディアシングルサインオンをユーザーに提供するときには、管理者とそのエンドユーザーがこれらのサービスによって提供される二要素認証（多要素認証）を使用することをお勧めします。このようにすることで、身元証明がもう1種類必要となり、保護レベルを強化できます。JWTまたはSAMLを使用する場合は、Zendesk側で設定を行う必要があります。ソーシャルメディアシングルサインオンを使用する場合は、ユーザー自身で設定を行う必要があります。ソーシャルメディアサービスの設定に必要な作業については、マニュアルがサービス各社から提供されています。

シングルサインオンの詳細については、以下のトピックを参照してください。

• ソーシャルメディアシングルサインオンの有効化
• JWT(JSON Webトークン)を使用したシングルサインオンの設定
• SAMLを使用したシングルサインオン

IPアドレスの範囲を制限してZendesk Supportへのアクセスを制限する

特定のIPアドレス以外からはアクセスできないよう管理者が制限することができます。つまり、管理者が手作業でアカウントに追加したIPアドレスからアクセスするユーザーだけが、Zendesk Supportにサインインできるようになります。

この制限は、すべてのユーザーに適用することも、エージェントだけに適用することもできます。エージェントのみへの適用を選択した場合、エージェントによるアクセスは制限されますが、エンドユーザーによるアクセスは制限されません。

この機能の詳細については、「IPアドレス範囲の制限によるZendeskへのアクセス制限」を参照してください。

REST APIを使用している場合のアクセス制限または安全なコーディング方法への順守

Zendesk REST APIおよびZendesk Apps frameworkを使用して、Zendesk Supportインスタンスの機能を拡張できます。

これらのツールでZendesk Supportの機能を拡張しない場合は、APIを無効のままにしておきます。「管理」>「チャネル」>「API」を選択し、「トークンアクセス」オプションと「パスワードアクセス」オプションの選択を解除します。

Zendeskの機能を拡張する場合は、安全なコーディングに関するベストプラクティスに従うことを強くお勧めします。Open Web Application Security Project（OWASP）がよい参考になります。参照するにはこちらをクリックしてください。

さらに、Zendesk APIにアクセスするアプリケーションは、管理者のユーザー名とパスワードを使用することは決してありませんが、その代わりにOAuthトークンを使用します（「アプリケーションでのOAuth認証の使用」を参照）。これにより、アプリケーションによって実行されているアクションを分離し、そのアプリケーションが侵害されている疑いがある場合に、トークンを取り消すことができます。

クレジットカード番号をチケットで非表示にする

メモ：クレジットカード番号の墨消し機能がサポートされているのは、Professional以上のプランです。

エンドユーザーは、その必要がないときにも、クレジットカード番号をサポートリクエストに不用意に含めてしまうことがあります。カード番号は、チケットにアクセスできるメンバー全員に表示されてしまうだけでなく、チケット内の他の情報と一緒にデータベースに自動保存されてしまいます。クレジットカード番号を墨消ししたり、番号の一部を削除したりすることで、番号の流出を防ぐことができます。「クレジットカード番号をチケットで自動的に墨消しする方法」を参照してください。

プライベート添付ファイルを有効にする

添付ファイルはZendesk Support内へのリンクとして示されます。プライベート添付ファイルを有効にしない場合、Zendeskにログインしていない状態でも、添付ファイルへのリンクへアクセスできるようになってしまいます。業務上どうしても有効にできない場合を除き、プライベート添付ファイルは有効にしてください。「チケットにファイルを添付してやりとりする方法」を参照してください。

フォーラムのスパム対策

ヘルプセンターのフィルターを有効にして、スパムと見なされたエンドユーザーの投稿を、ヘルプセンターに表示しないようにできます。不審な投稿はスパムキューに送られ、管理者はそれらの投稿を確認し、処理します。詳しくは、「スパムフィルターを使用してヘルプセンターのスパム表示を防止する方法」を参照してください。