最近の検索


最近の検索はありません

Craig Lima's Avatar

Craig Lima

参加日2021年4月14日

·

前回のアクティビティ2025年1月02日

フォロー中

0

フォロワー

0

合計アクティビティ

11

投票

0

受信登録

3

アクティビティの概要

さんの最近のアクティビティ Craig Lima

Craig Limaさんがコメントを作成しました:

コメントZendesk policies and agreements

Dec 27th, 2024, added section XII to incorporate Workforce Management “WFM” into HIPAA BAA scope

コメントを表示 · 投稿日時:2025年1月02日 · Craig Lima

0

フォロワー

0

投票

0

コメント


Craig Limaさんがコメントを作成しました:

コメントZendesk policies and agreements

Dec 16th 2024

1. Added section XI to incorporate Zendesk QA into scope 

2. Changed various instances of "Answer Bot" to "AI Agents" to denote naming convention changes and broader scope.

3. Changed various instances of “must” and “shall” to “should” to denote best practices philosophy of configs, as well as to reinforce the Subscriber responsibility for interpretation of HIPAA compliance vis-a-vis Admin / Owner configurations and use case implementation  https://support.zendesk.com/hc/en-us/articles/4408833510938-The-Zendesk-Shared-Responsibility-Model

コメントを表示 · 投稿日時:2024年12月17日 · Craig Lima

0

フォロワー

0

投票

0

コメント


Craig Limaさんが記事を作成しました:

記事Zendeskのポリシー
Zendesk WFM(Tymeshift)、Zendesk QA(Klaus)、Ultimate機能はGoogle Cloud Platform(GCP)でホスティングされており、このページに記載されている地域ではホスティングできない場合があります。

Zendeskが契約者のサービスデータをホスティングしているAWSリージョン

現在、契約者のサービスデータは以下のAWSリージョンでホスティングされています。

  • 米国東部(北バージニア)
  • 米国東部(オハイオ)
  • 米国西部(オレゴン)
  • 欧州(アイルランド)
  • 欧州(フランクフルト)
  • 英国(ロンドン)
  • アジアパシフィック(東京)
  • アジアパシフィック(大阪)
  • アジアパシフィック(シドニー)

データロケーションアグリーメント

「データセンターの場所」アドオンをご購入いただいた場合(「データセンターの場所」アドオンを単体で購入した場合、または「データセンターの場所」アドオンが購入したサービスプランに含まれている場合)、Zendeskが保証するのは、契約者のサービスデータのホスティング場所についてのみです。この保証の例外については、こちらの「地域データのホスティングポリシー」をお読みください。

需要のバランスをとり、パフォーマンスを向上させ、最高のサービスを提供するために、当社は予告なくアカウントデータを地域間で移動させることがあります。  「データセンターの場所」アドオンを購入しているアカウントの場合、当社は地域間の移動が必要な国または法律の境界内にとどめるようにします。

お客様のサービスデータがホスティングされている物理的な住所を取得する

ご要望に応じて、お客様のサービスデータをホストしているアマゾンウェブサービス(AWS)の地域(AWSによって国、国内の地理的地域、州、および/または都市として説明される一般的な地域)をお知らせすることができます。

技術レベルでのAWSの運用方法により、お客様のサービスデータがホスティングされている場所について、正確な物理的住所をお知らせすることはできません。  これは、AWS自体のアーキテクチャに基づくものです。  AWSは世界中に「リージョン」があります。  これらのリージョン内には、「アベイラビリティゾーン(AZ)」という概念が存在します。  AWSで作成されたアセットは、特定のリージョン内の1つまたは複数のAZに配置されます。  リージョン内またはリージョン間でデータを複製するアセットオーナーの選択に関係なく、AWS自体はリージョン内のデータを他のAZに複製することができます。  その結果、Zendeskの契約者サービスのデータは、特定のリージョン内の多数の施設内に存在することになります。  さらに、セキュリティ上の理由から、AWSはデータセンターの建物や関連施設の特定の場所をお伝えすることを公式に認めていません。

ZendeskのサブドメインがどのAWSリージョンでホストされているか知りたい場合は、Zendeskカスタマーサポートにご連絡ください

変更履歴:

2024年4月 - Zendesk WFM(Tymeshift)およびZendesk QA(Klaus)に関する注意書きの追加

2024年7月 - Ultimateに関する注意書きの追加

2024年7月 - 新しいホスティング先の追加:英国(ロンドン)、アジアパシフィック(東京)

 

編集日時:2024年7月26日 · Craig Lima

5

フォロワー

2

投票

0

コメント


Craig Limaさんが記事を作成しました:

記事Zendeskのポリシー

Zendeskの責任共有モデル

Zendeskは、高度な設定が可能で迅速に拡張できるカスタマーサービスプラットフォームを、幅広い業種の世界的な大手企業の多くに提供しています。  Zendeskは、契約者が自社のカスタマーサービスのニーズに合わせてZendeskのクラウドプラットフォームを活用できるようサポートすることで、オーバーヘッドを削減し、需要に合わせて柔軟に拡張したり、カスタマーとの間に美しくシンプルなやりとりを提供できるようにします。

クラウドにビジネスを移行すると、上述のようなメリットが得られる反面、当事者間での管理責任が曖昧になる可能性もあります。  ご心配なく、ここを簡潔にするために、以下に当社の責任共有モデルを示します。  このフレームワークは、お客様のデータのセキュリティとプライバシーに関連する管理について、どの当事者が責任を負うかを明確にするものです。  責任をもって職務に取り組む管理者や企業のセキュリティ担当者、コンプライアンス担当者、個人情報保護担当者など、Zendesk Servicesを利用する上で適切な管理体制を構築する立場にある関係者にとって、この基準は、注意すべき範囲を明確に示すものとなります。

一言でいうと、「Zendeskはサービス自体のセキュリティを担当し、お客様はサービスの特定のインスタンス内のセキュリティを担当する」ということです。 

  1. アクセス制御とセキュリティ対策
  2. インテグレーション
  3. データ、プライバシー、コンプライアンス、規制に関する考慮事項
  4. 監視
  5. メンテナンス
  6. セキュリティインシデント(ロールと責任)
  7. 役に立つリンク
  8. 変更履歴

本記事で使用されているかぎ括弧(「」)付きの用語は、Zendeskのメインサービス契約(「MSA」)に定める意味を有するものとします。

I. アクセス制御とセキュリティ対策
機密システムとその中のデータへのアクセスを制御することは、セキュリティ原則の中核です。

  1. 「契約者」は、以下を含む、サービスのインスタンスへのすべてのアクセス制御に責任を負います。
    1. エンドユーザーおよびエージェント(オンプレミス、リモート、サードパーティのいずれでも)を含む全ユーザーのプロビジョニング、変更、継続的な保守・管理、権限の正確性の維持、およびプロビジョニングの解除を行うこと
    2. サポートされているサービスから認証方法を選択し、設定すること(パスワード、MFA、SSOなど)
    3. ログアウト、ログインしたデバイスなど、セッション処理を設定し監視すること
    4. Zendeskのサポートスタッフがお客様のSupportインスタンスに入ることを許可または拒否すること
    5. ZendeskのREST APIサービスへのアクセス(インテグレーション、Zendesk Sunshineサービスの使用など、該当する場合)を設定し、使用する意味を理解すること
    6. 必要な場合、製品がサポートするIP制限を設定すること
    7. インスタンスへのアクセス時にエージェントに使用を許可するデバイスタイプなど、製品に関連しないその他のアクセス制御や、ユーザーまたは許可されたデバイスに適用可能な物理的、論理的、またはポリシー制御を検討すること
  2. Zendeskは、以下のようなサービスを支えるシステムに対するすべてのアクセス制御に責任を負います。
    1. すべてのユーザー(オンプレミス、リモート、サードパーティの従業員含む)の安全なプロビジョニング、変更、継続的な保守・管理、権限の正確性の維持、およびプロビジョニングの解除のためのポリシーと手順を管理すること
    2. ロールベースのアクセス制御「RBAC」、最小特権の原則「PLP」、契約者のサービスデータを含む重要なシステムおよびアプリケーションへのすべての従業員および請負業者のアクセスに対する多要素認証「MFA」などの実装により、適切な資格情報セキュリティを確保すること
    3. 上記について定期的に点検すること

II. インテグレーション
サードパーティの活用は効率を大幅に向上させますが、同時にセキュリティ上の考慮も必要となります。

  1. 「契約者」は、以下を含む本サービスとのすべてのサードパーティインテグレーションを利用する際のセキュリティへの影響を考慮する責任を負うものとします。
    1. APIまたはSDKを経由して行われるインテグレーション
    2. マーケットプレイスアプリのインストールまたはサードパーティチャネルの有効化を通じて行われるインテグレーション
    3. スタッフ、ツール、コードの提供、またはZendeskインスタンスへの直接サービス提供により、契約者を支援するサードパーティとのインテグレーション
  2. Zendeskは、信頼できるサードパーティを慎重にサービスに統合する責任があります。
    1. すべての「副処理者」を審査し、継続的なデューデリジェンスを実行すること
    2. 買収したビジネスを安全な方法でサービスに統合すること
    3. サードパーティとの製品パートナーシップやサービスインテグレーションで適切なセキュリティ上の配慮を行うこと 

III. データ、プライバシー、コンプライアンス、規制に関する考慮事項
使用中のデータ、その適切な取り扱い、関連する規制の枠組み、第三者の保証の重要性を説明することは必須です。

  1. 「契約者」は、取り込んで使用するデータについて、以下を含む適切な取り扱いに責任を負います。
    1. 特定のユースケースに関連するデータのタイプを理解すること
    2. 自社のデータ分類およびプライバシーポリシー、データ自体に関連する適用法、データを提供するユーザー、契約者の業種、および関連する法域に従って、かかるデータを取り扱うこと
    3. サービスのインスタンスとの通信を許可するチャネルを選択すること
    4. 契約者の業種、ユーザー、またはユースケースに適用されるコンプライアンス、法律、または規制の枠組みに従って、インスタンスおよび「サービスデータ」を管理すること
    5. Zendesk UIやAPIとのトラフィックを暗号化するために、Zendesk以外の親ドメインへのホストマッピングが必要な場合、代替のTLS証明書をZendeskに提供すること
    6. 転送中のデータが暗号化されない可能性のあるチャネルやプロトコルを理解し、そのようなチャネルやプロトコル(主にメール、SMS、または暗号化をサポートしない、契約者の単独の裁量で行われるサードパーティのインテグレーション)に対応すること
    7. 契約者のインスタンスに含まれるデータのタイプが、Zendeskのメインサービス契約の利用規約(Zendesk MSAを参照)に違反していないこと
    8. 契約者が選択したアップタイムおよびディザスタリカバリのレベルが、契約者が従うべきポリシーまたは規制に従っていること
  2. Zendeskは以下について責任を負います。
    1. すべての「サービスデータ」が開示されないようサービスレベル(インフラやコードなど)で適切に保護する
    2. パブリックネットワーク上でのUIまたはAPIを介したデータの送受信時に、転送データを暗号化する
    3. すべての保管中の「サービスデータ」を暗号化する
    4. 製品内のCookieによって収集されたデータおよびサービスのデフォルト使用に関する情報を契約者に提供する
    5. 匿名化および非匿名化された「個人データ」を含む「サービスデータ」を、サービスの提供またはその他の目的にどのように使用するかを正確に説明する
    6. 個人データまたは規制データの適切な取り扱いに関する自らの義務を果たすのに役立つツールおよび機能を「契約者」に提供する
    7. 弊社の提供するサービスおよび事業拠点に関連する適用法および規制の枠組みを遵守する
    8. 弊社のサービス提供に関連する独立した第三者によるコンプライアンス保証を取得し提供する

IV. 監視
適切なセキュリティには、プロセスとアクティビティに対する洞察が必要です。

  1. 「契約者」は、以下を含む、サービスのインスタンスへのすべてのアクティビティの監視に責任を負います。
    1. ユーザーのアクティビティを監視すること(UIビューまたはAPIログのいずれかによる)
    2. 未知の個人とのコミュニケーション、またはサービスを介して派生する信頼できないコンテンツについて、デューデリジェンスを実施すること
    3. 適用される規制に従って、本「サービス」から取得したログまたはデータを管理すること
  2. Zendeskは、以下のようなサービス自体のプロセスやアクティビティの監視に責任を負います。
    1. 本番ネットワーク内の特権アクセスやアクティビティ
    2. 既知の不正な送信や不正なIPアドレスをアラートまたはブロックする着信トラフィック
    3. サービスのアップタイム
    4. 企業ネットワークまたは本番ネットワーク資産内の異常な動作
    5. コード、インフラ、トラフィック、関連する従業員や請負業者のセキュリティ

V. メンテナンス
システムやコードを最新の状態に保ち、パッチを適用することで、セキュリティ上の問題の多くを防ぐことができます。

  1. 「契約者」は、Zendeskのアーキテクチャおよび契約上の境界*を超えて、以下のシステムまたはコードの保守およびパッチ適用を行う責任を負います。
    1. 従業員のエンドポイント、ネットワーク、カスタムインフラストラクチャ、またはZendeskサービスへのアクセスや、Zendeskシステムへの接続前、または接続後のサービスデータの処理に使用するサードパーティ製ミドルウェアを含む独自のインフラストラクチャ
    2. 「Zendeskサービス」に追加機能を提供するために利用される、契約者独自の非標準コード。これには、契約者が独自に開発したコード、また「Zendeskサービス」で使用するために購入したサードパーティのコードが含まれます。また、「Zendeskプロフェッショナルサービス」が「契約者」の要望に応じて開発したカスタムコードも含まれます。ただし、カスタム契約の一部として、当該コードの責任とメンテナンスが契約者に移譲されている場合に限ります。
  2. Zendeskは、以下のものを含む、アーキテクチャ上または契約上の境界内にあるすべてのシステムおよびコードの保守およびパッチ適用を行う責任を負います。
    1. 本「サービス」を提供するために使用されるホスティングプロバイダー施設内で独自の論理的に管理されたインフラストラクチャ(オペレーティングシステム、セキュリティインフラストラクチャ、直接管理下にあるシステム、コンテナおよびオーケストレーションシステムなどが含まれる)。
    2. 従業員のエンドポイント、社内ネットワークインフラなど、Zendeskの社内環境で使用される物理的または論理的に管理されたインフラストラクチャ。
    3. 「Zendeskサービス」の基盤となる独自のコードベース。

* マーケットプレイスアプリはZendeskのアーキテクチャの境界内で実行されますが、Zendesk標準の「メインサービス契約」の対象ではなく、弊社のマーケットプレイスアプリケーション利用規約で示されているように、契約者とアプリケーション開発者自身の間の特定の条件によって取り扱われます。マーケットプレイスアプリのメンテナンスは、マーケットプレイスアプリのサードパーティ開発者の責任となります。

VI. セキュリティインシデント
最善の努力にもかかわらず、物事がうまくいかないことがあります。  セキュリティインシデントをどのように認識し、対応し、回復するかが、セキュリティインシデントの軽減策を成功させ、顧客の信頼を維持するための鍵となります。  このセクションでは、セキュリティインシデント発生時の各当事者の役割と責任について説明します。

  1. 「契約者」は、サービス自体の脆弱性またはインシデントに起因しない、特定のインスタンス内で発生したセキュリティインシデントまたはセキュリティ侵害に対して、以下のような責任を負います。 
    1. 特定のインスタンス内で、以下の原因による侵害の疑いまたは実際の侵害を調査し、是正すること。(i) 不十分なアクセス制御または保守・管理(脆弱または悪用されうる公開資格情報の使用を含む)、(ii) ユーザー活動の不十分な監視、(iii)ユーザーとのやりとりを介して派生したコミュニケーションまたは信頼できないコンテンツに対するデューデリジェンスの不履行、または (iv) サードパーティとのインテグレーションを介して引き起こされたインシデントまたは侵害(かかるインテグレーションが契約者の単独の裁量で行われたもの)。
    2. 「契約者」のアクションや統合されたサードパーティに起因する侵害、またはZendeskから受信したサービスデータの侵害通知に関連して、政府機関または法執行機関、エンドユーザーに必要な通知を行うこと
  2. Zendeskは、セキュリティインシデントの調査、およびサービス経由で発生した「サービスデータの侵害」に関する契約者への通知の管理について以下のような責任を負います。 
    1. セキュリティインシデント対応ポリシーの文書化およびセキュリティに関連する役割と責任を持つスタッフを配置する
    2. 異常な活動を調査する
    3. 確認された「サービスデータの侵害」を封じ込める
    4. 法律で義務付けられている場合、影響を受ける契約者または関連する政府機関や法執行機関に通知する
    5. 堅牢なバックアッププロセスおよび災害復旧プロセスを導入し、テストを行なう

VII. 役に立つリンク

Zendesk Securityでカスタマーサービスを安全に提供

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

Zendesk法務情報ポータル

アクセス制御とセキュリティ対策

Zendesk Supportのセキュリティとユーザーアクセス(リンクをまとめたページ)

Chatのユーザーロール

Chatにおけるユーザー認証

Zendeskにアカウントへの一時アクセスを許可する方法

インテグレーション

Zendesk API

Zendeskマーケットプレイスアプリ

Zendeskの副処理者

Zendesk Connectの副処理者

Zendeskパートナー

データ、プライバシー、コンプライアンス、規制に関する考慮事項

Zendesk製品内Cookieポリシー

Zendeskメインサービス契約

Zendeskデータとプライバシーの保護

監視

Supportインスタンスの変更監査ログ(UI / API

Support チケットイベント監査ログAPI

Chatダッシュボード

チャット履歴のUI

ChatのIncremental ExportsおよびReal-Time API

Talkダッシュボード

Talk Incremental API

Sunshine Custom Objects, Events, and Profiles API

Sell Real-Time/Firehose API

 

ご不明な点があれば、security@zendesk.comまでお問い合わせください。

VIII. 変更履歴
2023年6月16日

  1. 追加の変更履歴
  2. 「V. メンテナンス」のセクションの追加
  3. 「VI. セキュリティインシデント」において、「契約者」およびその「エンドユーザー」が使用する、脆弱な、または公に悪用されうる資格情報の使用に起因するインシデントの詳細を、契約者の責任として明示

翻訳に関する免責事項:この記事は、お客様の利便性のために自動翻訳ソフ トウェアによって翻訳されたものです。Zendeskでは、翻訳の正確さを期すために相応の努力を払っておりますが、翻訳の正確性につ いては保証いたしません。

翻訳された記事の内容の正確性に関して疑問が生じた場合は、正式版である英語の記事 を参照してください。

編集日時:2024年5月08日 · Craig Lima

0

フォロワー

2

投票

0

コメント


Craig Limaさんが記事を作成しました:

記事Zendeskのポリシー

現在のプランを確認

Suiteすべて

データをクラウドに預けるには多くの信頼が必要です。逆に、情報を共有するパートナーがセキュリティを最優先事項としているということを理解してもらいましょう。「契約者」は、それぞれ異なる標準とフレームワークを使用して機密情報を管理しています。そのため、お客様のデータを安全かつコンプライアンスに保つために、以下のような国際標準化機構(ISO)のベンチマークを当社のサービス全体に適用しています。

ISO 27001 

ISO/IEC 27000規格は、組織がデータの取り扱いをベンチマークするための一連のフレームワークを提供しています。最も一般的な「ISO/IEC 27001」は、情報セキュリティマネジメントシステム(ISMS)の要件を規定し、監査を通った組織について要件が満たされていることの保証を与えています。

ISO 27018 

ISO/IEC 27018」は、「ISO/IEC 27002」をベースにしたガイドラインを提供しており、Zendeskなどのクラウドサービスプロバイダーの個人情報(PII)の保護に焦点を当てています。

ISO 27701 

ISO/IEC 27701:2019は、プライバシー情報マネジメントシステム(PIMS)の構築、実装、維持、および継続的な改善のための要件とガイダンスを規定しています。これは、組織内のプライバシー管理に関するISO/IEC 27001およびISO/IEC 27002を補完するものです。これは、データ管理者とデータ処理者が使用する個人データを管理するためのフレームワークを構築し、セキュリティとプライバシーの管理を連携させます。

これらの監査の対象となるZendeskのサービスとプロセス

ISO/IEC 27001:2013、ISO/IEC 27018:2014、およびISO/IEC 27701:2019認証の範囲は、Zendesk, Inc.のグローバルネットワークインフラストラクチャと対応する製品およびサービス(開発、運用の管理など)によって拘束されます。 Zendesk本社の外で一元管理され、以下のオフィス所在地からサポートされています。カリフォルニア州サンフランシスコ、ウィスコンシン州マディソン(アメリカ合衆国)、コペンハーゲン(デンマーク)、ダブリン(アイルランド)、マニラ(フィリピン)、メルボルン(オーストラリア)、モンペリエ(フランス)、シンガポール。

さらに、IaaS(サービスとしてのインフラストラクチャ)データセンタープロバイダーは 、IaaSで提供されるすべてのサービスを実行するインフラストラクチャを保護するために 使用されます。クラウド。IaaS環境を管理するためのZendeskのセキュリティ対策は、 ただし、物理的および環境的な規制を除きます。

現在ホスティングサービスの復処理者はAWSであり、独自にいくつかのISO認証を取得しています。詳細については、コンプライアンスページを参照してください こちら_

お客様にとってのメリット

社内におきましても、弊社のセキュリティ管理とプライバシーに関わる部門が先端産業の基準に準拠していることを確証するために、ISO認定とは別個にこのような監査を実施しております。お客様にとって、社外で検証されたこれらのコンプライアンス基準が意味するものは、Zendeskがお客様のデータをどのように扱うかという点で、お客様に対し当社の義務を果たしているということの確証です。さらに、ISO/IEC 27701では、監査基準の一部として適用される法律および規制を宣言することを組織に求めています。この基準を一般データ保護規制(GDPR)、カリフォルニア消費者プライバシー法(CCPA)などの要件にマッピングすることができます。 」でツリーベースの最大権限を有効にします。

対象製品を使用されるすべてのお客様は、このセキュリティ保護を受けることができます。

これらの証明は、上記に挙げた当社のサービスのためのものです。これらの証明によって保護を受けるために、追加料金を支払う必要も、インスタンスを構成する必要もまったくありません。

ZendeskのISO 27001、ISO 27018およびISO 27701の認証と顧客認証の比較

ZendeskのISO 27001、ISO 27018およびISO 27701の認証は、Zendeskサービスの特定の範囲におけるセキュリティおよびプライバシーの管理プロセスを対象としています。Zendeskを利用したサービスの運用中にこれらの認定資格のいずれかを取得したい場合は、自動的に証明機関の認定を受けることはできません。ただし、Zendeskの認定により、ご自身のインスタンスでより簡単に認定を取得することができます。

ZendeskのISO認証を取得する

次のフォーム:https://www.zendesk.com/product/zendesk-security/#anchor-security-resources

 

 

翻訳に関する免責事項:この記事は、お客様の利便性のために自動翻訳ソフ トウェアによって翻訳されたものです。Zendeskでは、翻訳の正確さを期すために相応の努力を払っておりますが、翻訳の正確性につ いては保証いたしません。

翻訳された記事の内容の正確性に関して疑問が生じた場合は、正式版である英語の記事 を参照してください。

編集日時:2024年5月08日 · Craig Lima

3

フォロワー

2

投票

0

コメント


Craig Limaさんが記事を作成しました:

記事Zendeskのポリシー

HIPAAおよびHDS有効アカウント(総称して「ヘルスケア有効アカウント」):

本文書で使用されているすべての大文字の用語は、ZendeskのBusiness Associate Agreement(「BAA」)またはZendeskのマスターサブスクリプション契約に記載のHDS規約(英語)に記載されている意味を有するものとします。 「医療提供契約」)。

HIPAA対応アカウントの場合、「PHI」は「保護対象医療情報」を意味し、HDS対応アカウントの場合は「PHI」は「個人医療情報」を意味します。

Zendeskおよび「契約者」は、ユースケースに応じて、以下の構成、または「契約者」が評価した代替手段を評価し、1つまたはすべての「ヘルスケア有効アカウント」について、適用法の下で遵守要件を満たすべきと判断した場合は、「ヘルスケア契約」を締結することを推奨します。サービスにPHIを導入する前に、までに確認することもできます。

「契約者」が単独の裁量により、以下に推奨される設定のいずれかを実行しないことを選択した場合、「契約者」は、 「契約者」が推奨する設定からの違反。

加入者は適切なレベルでサービスプランを購入し、必要な関連アドオンを持っている必要があります(不明な場合は、営業担当者にお問い合わせください)。

加入者がHDS有効のアカウントを持っている場合、加入者は Zendeskのサブ処理者ポリシー の「フォローする」ボタンをクリックして、サービスを提供するために使用されるサブ処理者に変更の通知を受け取る必要があります。

Zendeskサービスでは、以下の最小セキュリティ構成が実施され、ヘルスケア有効アカウントのヘルスケア契約上、承認される必要があります。

I.Zendesk Support:

  1. 次の2つの方法のいずれかを使用して、エージェント認証を保護します。
    1. パスワードを設定したネイティブのZendesk Supportを使用する方法:(i) 「推奨」に設定する;または「推奨」設定で確立された要件よりも安全な要件を確立する方法で、「契約者」がカスタマイズした要件。さらに、このサブセクションのオプションでは、「契約者」は「サービス」内でネイティブに2要素認証(「2FA」)を有効にし、適用する必要があります。そして、管理者がエンドユーザーのパスワードを設定できるような管理コントロールは無効にする必要があります。または
    2. Zendeskの「推奨」パスワード設定で確立された要件よりも安全性の高い要件が設定された外部のシングルサインオン(「SSO」)ソリューションを利用し、すべてのエージェントのアクセスに対して、選択したソリューション内で2要素認証を有効にして実施すること。管理者がエンドユーザーのパスワードを設定できる管理コントロールは無効にする必要があります。
    3. 認証方法としてSSOを利用した場合は 、パスワードアクセスを無効にする必要があります
  2. ヘルスケア有効アカウントのSecure Socket Layer(SSL)暗号化を、常に有効にしておく必要があります。ヘルスケア有効 zendesk.com以外のドメインを利用するアカウントは、 ホストSSLを確立し、維持する必要があります」でツリーベースの最大権限を有効にします。
  3. 可能であれば、エージェントのアクセスは「契約者」の管理下にある 特定のIPアドレスのみに制限される 必要があります。 ただし、上記の要件1.aまたは1.bに記載されているように、契約者がエージェントの多要素認証を有効にしている場合を除きます(ネイティブサービス内またはエンタープライズSSOと結合された契約者環境のいずれか)。  疑義が生じるのを避けるため、「エージェントアクセス」とは、ユーザーインターフェイス(「UI」)を介してサービスデータにアクセスする人間のエージェントに付与されたアクセスを示すものとします。
  4. 「契約者」のヘルスケア有効アカウントによりZendeskアプリケーションプログラミングインターフェイス(以下「API」)への呼び出しが可能になる範囲内で、「契約者」は作成、アクセス、修正、または削除が許可されたすべての「契約者」または「サードパーティ」のエンティティのセキュリティに及ぼす影響を理解する全責任を負うものとします。かかるアクセスおよび/またはインテグレーションを介したサービスデータおよびPHI。当該のAPIへのアクセスについては、以下に説明するようにZendeskがさまざまな方法を提供しており 、「契約者」は使用されているAPIモデルに基づいて以下のセキュリティのベストプラクティスを実装するものとします。
    1. OAuth 2.0アプローチ」でツリーベースの最大権限を有効にします。  このモデルは、最も詳細なセキュリティ機能を提供しますが、エンドユーザーがアクセス権限を受け入れる必要があります。  「契約者」は、可能な場合は、OAuth 2.0アプローチと認証スキーマを利用する必要があります。」でツリーベースの最大権限を有効にします。サブスクライバーは各OAuthクライアントに、説明的な一意のクライアント名と一意のID指定機能を提供する必要があります。各OAuthトークンに付与される権限は、必要なタスクを達成するために必要な最低限の権限のみを許可するものです。
    2. REST APIトークンアプローチ」でツリーベースの最大権限を有効にします。  このモデルは最も広範なモデルであり、APIトークンでAPIモデルのすべての機能を利用できます。メッセージングは、その性質上、最も広範なアクセスと機能を提供するため、慎重に使用する必要があります。このアプローチを使用する場合、「契約者」は(i)サービスごとに固有のトークンを使用し、トークンに説明的な名前指定機能を付与する必要があります。 (ii) 合理的に必要な場合およびエンドツーエンドで暗号化された転送方法に従った場合を除き、APIトークンを第三者と共有しないこと。 (iii) APIトークンがサードパーティと共有されており、「契約者」がサードパーティの「データ違反」を認識した場合、「契約者」は直ちに関連するトークンを回転させる必要があることを了承します。および (iv) 少なくとも、「契約者」の「組織ポリシー」に従って、トークンを頻繁にローテーションする。  
    3. 「契約者」は、APIへのパスワードアクセスを可能な限り無効にする必要があります。このアプローチでは、リクエストごとにユーザー資格情報を送信するため、一般に公開することで、ユーザーが悪意のある第三者によって傍受されやすくなるからです。  
  5. 添付ファイルへのアクセスに認証を要求するには、「ダウンロード時に認証が必要」を 有効にする必要があります」でツリーベースの最大権限を有効にします。これを行わない場合、制限のない添付ファイルは、当該添付ファイルの正しいURLにアクセスできる誰でもアクセスできるようになります。このような場合、「契約者」は添付ファイルの内容、および添付ファイルデータへのアクセスにすべての責任を負うものとします。
  6. 「契約者」は、「エージェント、管理者」および「オーナー」がエンドポイントにアクセスするすべてのシステムに対し、パスワードロック付きのスクリーンセーバーまたはスタートアップ画面を組織的に適用し、システムが非アクティブの状態が最大15分継続するように設定する必要があります。
  7. 加入者は、ユーザーがインスタンス/ブランド/組織全体の更新を表示できるようにする閲覧権限を変更したり、ユーザー自身のチケットまたはグループを超えたアクセスを許可するデフォルト設定を変更したりしないでください。ただし、加入者が、以降のすべてのデータへのアクセス)。「エンドユーザー」組織の権限は、ユーザープロフィールおよび組織自体の権限で設定できること、および設定が競合する場合は、 より許容度の高い設定は、許容度の低い設定を上書きします
  8. 加入者は、エンドユーザーからの電子メール送信、および関連するサービスデータを、加入者のZendesk Supportインスタンスで受信する前に、セキュリティ保護に対してZendeskが責任を負わないことを承諾します。これには、 Zendesk Supportチケットへの返信を介してメールで渡されるすべてのPHI(チケットのコメントや添付ファイルを含みますが、これらに限定されません)が含まれます。
  9. 「契約者」は、「契約者」のエージェントがメールチャネル経由でZendesk Supportチケットに返信した場合や自動化やトリガによって開始された場合など、さまざまな状況でZendesk Supportがエンドユーザーにメールを送信することを了承します。デフォルトでは、このメールには、自動通知に含まれるように設定された最新のチケットの対応やその他の情報が含まれます。これらの情報にはPHIを含む可能性があります。「契約者」をさらに保護するには、 Zendesk Supportインスタンスを エージェントが応答したことをエンドユーザーに警告のみを表示し、メッセージの内容を確認するにはZendesk Supportへの認証を求めるように設定されています。
  10. 加入者は、Zendeskサービス内で単独の裁量で利用できるテキストメッセージ機能がSMSおよび/または関連するプロトコルによってサポートされることを了承します。これらの機能では、サービスへのメッセージの暗号化なし、またはサービス外でのメッセージの送信が含まれる場合があります。  したがって、テキストメッセージ機能には、次のいずれかが必要です。
    1. ヘルスケア有効のアカウント*で使用されないこと、または
    2. 使用されている場合、「契約者」はその機能の使用にすべての責任を負います。
  11. 加入者は、サービスの 旧バージョンの顧客満足度アンケート(「旧バージョンのCSAT」) 機能を使用して、ユーザーの評価を得るために、Supportチケットに関連付けられたサービスデータ(PHIを含む場合がある)をメールで送信することを了承します。このデータの暗号化ステータスは制御されません。 。したがって、旧バージョンのCSAT機能では、次のいずれかが必要です。
    1. ヘルスケア有効のアカウント*で使用されないこと、または
    2. 使用されている場合、「契約者」はその機能の使用にすべての責任を負います。
  12. 加入者はサービスの顧客満足度アンケート(CSAT)機能の使用を承諾します チケットチャネル:適切に設定されていない場合、ユーザーの評価を取得するために、 Supportチケットに関連付けられたサービスデータ(PHIを含む場合がある)をメールで送信します。その暗号化ステータスはZendeskでは制御されません。また、特定のCSAT URLがあれば、誰でも特定のチケットの回答にアクセスできます。このため、チケットチャネルでCSAT機能を使用する場合、「契約者」は
    1. CSAT自動化メールの本文にPHIを含まないように設定し、 {{satisfaction.survey_url}} プレースホルダのみ
    2. 自由回答形式の質問機能を使用しない

*疑義が生じるのを避けるため、SMSに関するセクション10のPHIに関連するデータに関する注意事項は、製品内2FAの使用には適用されません(セクション1.aで説明)。この2FA機能は、本人確認のための数値文字列の送信にすぎないためです。

II. Zendesk GuideおよびGather:

  1. 加入者は、GuideおよびGatherサービスが本来パブリックであることを確認し(制限付きの記事を利用しない 非公開型または制限付きのインスタンスを使用しない)、したがって、加入者はZendesk GuideまたはGatherサービスのテキストまたはテキストで、PHIが含まれないようにする必要があります。記事または記事への添付ファイル、または記事内の画像として メールを送信することができます
  2. 契約者は、エンドユーザーがZendesk Guideで コメントを追加できる機能を無効に するか、 またはすべてのコメントからPHIを削除する機能をモデレートし、削除する必要があります(以下のセクション3で説明)
  3. Zendesk GuideサービスがGuide ProfessionalまたはEnterpriseの場合、「契約者」はできるだけ、 Zendesk Guideで Gather機能をオフにして 、エンドユーザーが新しい投稿を作成できるようにする必要があります。 または、契約者が意図してGatherの機能をオフにした場合は、その機能を追跡できなくなります。ユースケースでは、「契約者」は Zendesk Guideサービスでコンテンツの審査を有効にして、「すべてのコンテンツをモデレート」に設定する必要があります。」でツリーベースの最大権限を有効にします。PHIを含む投稿は承認しないでください。
  4. 加入者によるGatherサービス内での従業員以外の「コミュニティモデレーター」の使用は、PHI(該当する場合)の可能性のあるデータへのアクセスに対して、加入者が責任を負わない限り、許可されるべきではありません。
  5. サブスクライバーは、エンドユーザーにパブリックプロフィールを持つことを許可する場合、Gatherコミュニティメンバーの「@メンション」が可能であることを確認します。この機能がユースケースにリスクがあるとみなされた場合は、 パブリックプロフィールをオフにする か、@メンションを無効にする必要があります

III.Zendeskメッセージング:

  1. サブスクライバーは、(i)ソーシャルメディアメッセージにPHIが存在しないことを確認すること、または(ii)統合されたメッセージングプラットフォームで独自のBAAを締結することについて全責任を負わない限り、ソーシャルメディアメッセージングチャネルのインテグレーションを有効にしてはなりません。
  2. 加入者は、メッセージングの会話にファイルを添付できるエンドユーザーの機能を無効にする必要があり、 安全な添付ファイルを有効にする(i)機能のいずれについても全責任を負うものとします。(ii) エージェントがメッセージングの会話にePHIを含むファイルを添付しないことを保証する。これを行わない場合、制限のない添付ファイルは、当該添付ファイルの正しいURLにアクセスできる誰でもアクセスできるようになります。  このような場合、「契約者」はURLおよび/または添付ファイルデータの内容、およびこれらへのアクセスに対してすべての責任を負うものとします。
  3. 加入者は、すべてのエージェントおよびライトエージェントがすべてのエンドユーザーからのすべての受信メッセージを閲覧できることを保証することに全責任を負うものとします。
  4. 加入者またはそのエージェントがAPIおよびWebhookのためのインテグレーション(例: AIエージェント用に作成されたフローの一部として)にアクセスまたは開発する場合、またはメッセージングエクスペリエンスをカスタマイズする場合、加入者はすべてのカスタムワークフローおよびサブスクライバーまたはサードパーティエンティティ(チャットボットプロバイダーを含む)は、かかるアクセスおよび/またはインテグレーションを介して「サービスデータ」およびePHIを作成、アクセス、変更、または削除することができます。
  5. 「メッセージングの会話」が進行中の状態で、「契約者」がエージェントのメッセージング会話への参加権限を削除したい場合、「契約者」はその「エージェント」のZendeskへのアクセスを強制的に終了させるすべての責任を負うものとします。
  6. デフォルトでは、エンドユーザーとのWeb Widgetの会話は永続的であり、エンドユーザーが同じデバイスからWebチャットに戻ったときに確認できるようになります。加入者は、この機能を無効にするか、またはエンドユーザーがデバイスを共有しないようにするためのすべての責任を負うものとします。
  7. 加入者がエンドユーザーに対して認証の実装を希望する場合、加入者はベストプラクティスおよび業界標準に従って安全な方法でこれを実装する全責任を負うものとします。
    1. このアプローチを使用する場合、「契約者」は(i)各認証チャネルに対して固有のJWT署名キーを使用し、トークンに説明的な名前指定機能を付与する必要があります。 (ii) 合理的に必要な場合およびエンドツーエンドで暗号化される転送方法に準拠する場合を除き、JWT署名キーを第三者と共有しないこと。 (iii) JWT署名キーが第三者と共有されており、「契約者」に第三者のデータ侵害を認識させた場合、「契約者」は直ちに関連するJWT署名キーを回転させる必要があります。および (iv) 少なくとも、「契約者」の組織ポリシーに従って頻繁にJWT署名キーを更新すること。
    2. サブスクライバーは期限切れJWT属性を使用し、15分以内に値を設定する必要があります。
  8. 加入者は、エンドユーザーとAIエージェントとの間で人間のエージェントに引き継がれ、チケットに転送されないインタラクションはまだシステムに保存されることを承諾します。加入者は、義務に従ってそれらを削除する責任があります。また、これらの会話が保存されたときにサブスクライバーに警告し、 Sunshine Conversations API経由で自動的に削除をトリガするWebhookを使用します。 
  9. 契約者は、エンドユーザーとAIエージェントとの間の会話が 変換されたことを了承する チケットへの追加は現在墨消しできません。チケットを削除することで削除が可能になります。 
  10. 契約者は、メッセージングチャネル上のエンドユーザーの添付ファイルは現在、Zendeskではマルウェアのスキャンが行われていないことを了承します。加入者は、加入者の資産に対するリスクを軽減するために、手続きおよびポリシーを導入することに全責任を負うものとします。 
  11. 加入者は、「サイドカンバセーション」機能を使用すると、「子チケット」および/または「サイドカンバセーション」メッセージが内で作成されるか、または加入者のSupportインスタンスからチケット、メール、 Slack、またはインテグレーションを介して受信者に送信される可能性があることを承諾します(エージェントの裁量で)。 」でツリーベースの最大権限を有効にします。「契約者」が「ヘルスケア有効」アカウントでこの機能を使用することを選択した場合、(i)そのようなメッセージにPHIが存在しないことを確認するか、または(ii)メッセージにPHIが含まれる可能性がある場合、「契約者」はいずれかの責任を負うものとします。 「サイドカンバセーション」機能を介したメッセージの交換に起因するPHIの不正な取得、アクセス、使用、または開示に関連する一切の責任、費用、損害または損害の保証を提供するものとします。

IV. Zendesk Sunshine Conversations:

  1. サブスクライバーは、(i)サードパーティのチャネルメッセージにPHIが存在しないこと、または(ii)統合されたメッセージングプラットフォームで独自のBAAを締結することについて全責任を負わない限り、サードパーティチャネルのインテグレーションを有効にしてはなりません。
  2. 加入者は、 Sunshine Conversationsアプリケーションプログラミングインターフェイス(以下「API」)を介してサービスデータおよびPHIを作成、アクセス、修正、または削除できるすべての加入者またはサードパーティエンティティのセキュリティへの影響を理解する全責任を負うものとします。上記のAPIへのアクセスについて、「契約者」は使用するAPIモデルに基づいて以下のセキュリティのベストプラクティスを実装するものとします。
    1. OAuth 2.0アプローチ」でツリーベースの最大権限を有効にします。  このモデルは、最も詳細なセキュリティ機能を提供しますが、エンドユーザーがアクセス権限を受け入れる必要があります。  「契約者」は、可能な場合は、 OAuth 2.0アプローチと認証スキーマ」でツリーベースの最大権限を有効にします。サブスクライバーは各OAuthクライアントに、説明的な一意のクライアント名と一意のID指定機能を提供する必要があります。 
    2. REST APIトークンアプローチ」でツリーベースの最大権限を有効にします。  このモデルは最も広範なモデルであり、APIトークンでAPIモデルのすべての機能を利用できます。  メッセージングは、その性質上、最も広範なアクセスと機能を提供するため、慎重に使用する必要があります。このアプローチを使用する場合、「契約者」は(i)サービスごとに固有のトークンを使用し、トークンに説明的な名前指定機能を付与する必要があります。 (ii) 合理的に必要な場合およびエンドツーエンドで暗号化された転送方法に従った場合を除き、APIトークンを第三者と共有しないこと。 (iii) APIトークンがサードパーティと共有されており、「契約者」がサードパーティの「データ違反」を認識した場合、「契約者」は直ちに関連するトークンを回転させる必要があることを了承します。 (iv) 「契約者」の組織ポリシーに従ってトークンを頻繁にローテーションすること。  
    3. 「契約者」または「そのエージェント」がAPIおよびWebhookのインテグレーションにアクセスしたり、 Sunshine Conversationsのエクスペリエンスをカスタマイズしたりする場合、「契約者」はすべてのカスタムワークフローおよび許可された「契約者」または「サードパーティ」のエンティティ(チャットボットプロバイダーを含む)のプライバシーとセキュリティの影響を理解する全責任を負うものとします。当該のアクセスおよび/またはインテグレーションを介して「サービスデータ」およびPHIを作成、アクセス、変更、または削除することができます。
  3. サブスクライバーは、 Zendesk Support用に設定されたIP制限がSunshine Conversations APIに拡張されないことを承諾します。加入者は、2.bに記載されている通り、 Sunshine Conversations APIおよびAPIトークンへのアクセスを制限することに全責任を負うものとします。クライアントのポリシーに従って機能します。 
  4. 加入者は、 Sunshine Conversationsの会話にファイルを添付できるエンドユーザーの機能を無効にする必要があり、 安全な添付ファイルを有効にすることについては全責任を負うものとします。 エージェントがメッセージングの会話にPHIを含むファイルを添付しないようにすることができます。これを行わない場合、制限のない添付ファイルは、当該添付ファイルの正しいURLにアクセスできる誰でもアクセスできるようになります。このような場合、「契約者」は添付ファイルの内容、および添付ファイルデータへのアクセスにすべての責任を負うものとします。
  5. 「エンドユーザー向け認証」の実装を希望される場合、「セキュリティのベストプラクティス」および「業界標準」に従って堅牢な方法でこれを実装する全責任を負うものとします。
    1. このアプローチを使用する場合、「契約者」は(i)各認証チャネルに対して固有のJWT署名キーを使用し、トークンに説明的な名前指定機能を付与する必要があります。 (ii) 合理的に必要な場合およびエンドツーエンドで暗号化される転送方法に準拠する場合を除き、JWT署名キーを第三者と共有しないこと。 (iii) JWT署名キーが第三者と共有されており、「契約者」に第三者のデータ侵害を認識させた場合、「契約者」は直ちに関連するJWT署名キーを回転させる必要があります。および (iv) 少なくとも、「契約者」の組織ポリシーに従って頻繁にJWT署名キーを更新すること。
    2. サブスクライバーは期限切れJWT属性を使用し、15分以内に値を設定する必要があります。
  6. 加入者は、エンドユーザーとAIエージェントとの間で人間のエージェントに引き継がれ、チケットに転送されたインタラクションはまだシステムに保存されていることを確認し、Webhookを実装するなどして、義務に従ってそれらを削除するのは加入者の責任となります。会話が保存されたときに「契約者」に警告し、 Sunshine Conversations APIを介して自動的に削除をトリガします。 
  7. 契約者は、チケットに変換されたエンドユーザーとAIエージェントとの会話は現在墨消しできないことを了承します。チケットを削除することで削除が可能になります。 
  8. 契約者は、 Sunshine Conversations API経由で削除されたメッセージは、エンドユーザーに対してのみ削除され、Zendeskエージェントワークスペース上では削除されないことを承諾します。これは、チケット自体の削除または墨消し機能の使用で達成できます(制限事項については7.を参照)。 
  9. サブスクライバーは、 Sunshine Conversationチャネルのすべての添付ファイルについて、現在Zendeskではマルウェアの検出は行っていないことを了承します。加入者は、加入者の従業員のリスクを軽減するために、手続きおよびポリシーを導入することに全責任を負うものとします。 

V. Zendesk Chat:

  1. 「Zendesk Supportサービス」との接続および認証を行って、 「Zendesk Chatサービスへのエージェントのアクセスを制限する」ようにします。
  2. サブスクライバーは、(a) メールパイピングを無効にする、 (b)従来版のWeb Widgetの メールチャットの会話ログオプションを無効にする 、および(c) Chatダッシュボードからメールでエクスポートを共有しないことによって、Chatの会話ログをメールで送信 しないでください
  3. サブスクライバーは(i)Chat内にPHIが存在しないこと、および/または(ii)サブスクライバーによってすべてのエージェントがそのようなデータを表示できることを保証することについて、全責任を負うものとします。

VI. Zendesk Exploreサービス:

加入者は、ユーザー名、チケットのタイトル、フィールドおよびフォームの選択、および自由フォームのテキストフィールドにあるコンテンツを介してPHIがExplore製品内に表示される可能性があることを承諾します。

  1. PHIを含む対象サービスインスタンスについて、「契約者」は(i)親サービスインスタンスにPHIを含む可能性のあるすべてのチケット/コール/チャットにアクセスできるエージェントにのみ、Exploreインターフェイスへのアクセスを許可するものとします。 (ii) アカウントの環境内でExploreを使用するために必要な最低限の権限を考慮して、権限を付与する必要があります。Exploreでアクセスレベルを設定する方法の詳細については、 こちらを参照してください。
  2. 「エクスポート」機能を利用する場合、(i)契約者は、エージェントのインターフェイスへのアクセスを許可したデバイスにPHIが転送される可能性があることを了承します。また、そのデバイスに関するすべての付随する管理は契約者の責任であり、(ii)契約者はその使用を拒否する必要があります。 (a)PHIがエクスポートに含まれていないことを確認する、または(b)そのような転送に使用されるメールサービスが最低限の暗号化プロトコルで暗号化に対応できるようにすることのいずれかの責任を負わない限り、そのエクスポートされたレポートにメール経由のネイティブエクスポート機能を提供できます。準拠かどうかを確認します。

* Explore Enterpriseの使用に関する特別な考慮事項:

サブスクライバーは、Explore Enterpriseサービスを使用することで、データ共有およびエクスポート機能が拡張される可能性があることを承諾します。加入者は:

  1. (i)そのようなダッシュボードにPHIが存在しないことを確認する、または(ii)そのようなデータの閲覧およびデータの受信を承認されたエージェント、グループ、リスト、またはエンドユーザーとのみダッシュボードを共有する。
  2. IP制限を活用
  3. URL(Uniform Resource Locator)を介してダッシュボードを共有する場合、「契約者」は、個別またはグループのユーザーアカウントと共有するのではなく、アクセスリンクによってデータを共有することを承諾します。(i)パスワード保護を有効にし、(ii)選択したパスワードの複雑さ、ローテーション、保管および受領者への配布を、ダッシュボードに含まれるデータの保護に関する「契約者」のパスワードポリシーに準拠していることを確認し、(iii)ローテーションを行う必要があります。情報開示請求の疑いまたは確認時に、必要な遅延を与えずに

VII. 展開中の関連サービス(「アドオン」)の製品内機能に関するお知らせ:

  1. コラボレーション展開関連サービス:「サイドカンバセーション」加入者は、「サイドカンバセーション」機能を使用すると、「子チケット」および/または「サイドカンバセーション」メッセージが内で作成されるか、または加入者のSupportインスタンスからチケット、メール、 Slack、またはインテグレーションを介して受信者に送信される可能性があることを承諾します(エージェントの裁量で)。 」でツリーベースの最大権限を有効にします。「契約者」が「ヘルスケア有効」アカウントでこの機能を使用することを選択した場合、(i)そのようなメッセージにPHIが存在しないことを確認するか、または(ii)メッセージにPHIが含まれる可能性がある場合、「契約者」はいずれかの責任を負うものとします。 「サイドカンバセーション」機能を介したメッセージの交換に起因するPHIの不正な取得、アクセス、使用、または開示に関連する一切の責任、費用、損害または損害の保証を提供するものとします。

VIII. Zendeskモバイルアプリケーション(またはスマートフォンやタブレットなどのモバイルデバイスからのアクセス):

  1. 使用には、デバイスレベルの暗号化も含まれます
  2. デバイスの上限値に設定された生体認証またはPINアクセスを活用する必要がある
  3. チケットコメントをそのようなデバイスのロック画面に表示できる通知は無効にする必要があります。
  4. 画面の非アクティブ時のロックを有効にし、非アクティブな状態が15分を超えないようにロックするように設定する必要があります。
  5. 加入者は、墨消し 機能が Supportモバイルアプリでは利用できないことを了承し、エージェントが墨消し機能を使用したい場合は、ブラウザ経由でログインする必要があります。
  6. Zendeskメッセージングで「エンドユーザー」を認証するよう「契約者」が選択した場合、「契約者」は「エンドユーザーの認証ステータスがSupportモバイルアプリに表示されない」ことを確認します。

IX.Zendeskインサイト: このサービスのサポートは2021年2月5日をもって提供を終了しています。   

X.Zendesk AI機能に関するお知らせ(「Zendesk AI」、「高度なAI」、「生成AI」など):

  1. 加入者は、Zendesk AI機能 がZendeskサービスの生産性を高めることを目的としており、(i) 医療または健康に関するアドバイスの提供、(ii) 状態の診断の提供、または兆候(iii)治療を指示すること、または(iv)ユーザーが医療専門家にアドバイス、診断、または治療を求めることを何らかの方法で妨げるもの。医療サービスの検索または受信に影響を与える可能性のある医療計画、治療プログラム、テストサービス、またはその他の医療サービス(ただし、「契約者」が独自のユースケースおよびユーザーとのやりとりに基づいてこの決定に全責任を負う場合を除く)。 (このような方法でAIを使用することの潜在的な意味)」を参照してください。
  2. 契約者は、生成AI機能を使用する場合、生成されるAI出力は人間によるものではなくコンピュータによって生成され、不正確な出力を生成する可能性があることを了承します。Zendeskは、これらの出力の正確性を保証していません。
  3. 加入者は、AIエージェントの会話ボットのメッセージ を使用して「加入者のエンドユーザー」に必要な免責事項のメッセージを提供する場合、メッセージの内容の完全性を確保するために、「バリエーションを生成する」機能がアクティブにされないことを了承します。 
  4. サブスクライバーは、管理センターで拡張テキスト機能を有効にすると、ロールと権限に関係なく、インスタンス内のすべてのエージェントがこの機能を有効にすることを承諾します。 

XI.Zendesk QA

  1. 加入者は、 Zendesk QA AI機能がZendeskサービスの生産性を向上させることを目的としており、(i) 医療またはヘルスケアに関するアドバイスの提供、(ii) 状態の診断の提供などに利用できる方法で使用しないものとします。 (iii) 治療を指示すること。または (iv) ユーザーが医療専門家にアドバイス、診断、または治療を求めることをあらゆる方法で妨げること。(v) またはその他の方法でユーザーに情報を提供し、またはそれらを適用または除外する意思決定を行うこと。 (ただし、「契約者」が独自のユースケースおよび「ユーザー」とのやりとりに基づいて決定した場合を除く)。およびこのような方法でAIを使用することの潜在的な影響についても説明します。
  2. 「契約者」は、Zendeskインスタンス内の削除または墨消しがZendesk QAと直ちに同期されず、その後3〜6時間後に引き継がれることを承諾します。
  3. アンケート機能を使用する場合、「契約者」は(i) Zendesk QA AI支援機能を無効にする必要があります(または、 QA作業を実行するすべてのエージェントがその取引内の潜在的なデータを参照できるようにするとともに、ポイント1の原則を満たしていることを確認する必要があります)。 ii) アンケートの質問や説明にPHIが含まれないようにアンケートを設定する必要があります(または、日後取引のStartTLS経由で送信されるメールの中でそのようなデータの責任を引き受けます)。
  4. 「Zendesk Chat」カスタムインテグレーションを使用する場合、「契約者」は、「データが無制限に保持されないように」、「契約者」のポリシーに沿ったデータ保持期間を設定することを検討する必要があります。
  5. サブスクライバーは、 Sunshine Conversations APIを使用してZendeskメッセージングの会話の一部を削除する場合、この変更はZendesk QAに反映されないことを了承します。代わりに、墨消し機能を使用して元のチケットから情報を削除するか、会話全体を削除する必要があります。
  6. 契約者は、 Zendesk QAが現時点ではZendeskの「プライベート添付ファイル」機能をサポートしていないことを了承します。つまり、添付ファイルの正しいURLにアクセスできる人なら誰でもアクセスすることができ、PHIを含む機密データを使用しないでください。加入者は、当該URLおよび/または添付ファイルデータの内容に、またこれらへのアクセスにすべての責任を負うものとします。
  7. 「契約者」は、 Zendesk QAの初期プロビジョニングでは、最初の同期後にのみ高度な接続構成が可能であることを了承します。

XII.Zendeskワークフォースマネジメント「WFM」:

  1. 契約者が再確認する場合
    1. デフォルトのWFM管理者ロールは、 WFMサービスに適用されるすべてのエージェントのアクティビティと設定にアクセスできます(下記のポイント2で説明したタグを含む)。
    2. デフォルトのエージェントロールは、管理者がカスタムロールの作成を介して別のアクセス権を使用できるように設定されていない限り、エージェントのアクティビティにアクセスできます。この設定は こちらで説明しています。
  2. 加入者は、エージェント、管理者、またはSupportチケット内に既定のシステムロジックによって適用されたタグが、 WFM製品内で、このようなチケットアクティビティを表示できるユーザーに表示されることを承諾します。「契約者」がタグの機密性を認識する場合、アクセス権限は適切に設定しなければなりません。

免責事項:法律や規制の変更やZendeskサービスの変更などにより、本文書のセキュリティ構成は今後変更される可能性があります。このドキュメントには、上記のZendesk製品内でPHIを保護するために有効な最低限のセキュリティ構成に関するZendeskの推奨事項が記載されています。本文書は、このようなデータに関するすべての管理の包括的なテンプレートを構成するものではなく、また法的アドバイスを構成するものでもありません。Zendeskの契約者は、 HIPAAまたはHDSのコンプライアンス要件に関して、自身の法律コンサルタントに相談する必要があります。また、契約者自身の独自の分析結果に従って、セキュリティ構成に追加の変更を行う必要があります。ただし、そのような変更がZendeskのセキュリティを妨げたり低下させたりしない限り、追加の変更を行う必要はありません。説明する設定のみです。

 


変更履歴:

2025年1月24日

  • HIPAAおよびHDSの統合構成

2024年12月27日

  • Zendeskワークフォースマネジメント(「WFM」)をスコープに組み込むために、セクションXIIを追加

2024年12月16日

  • Zendesk QAをスコープに組み込むために、セクションXIを追加
  • 「Answer Bot」のさまざまなインスタンスを「AIエージェント」に変更し、命名規則の変更と適用範囲を拡大。

2024年10月10日

  • セクションI、 Support、番号12(CSAT)を追加し、新しい機能に対応するためにセクションI、 Support、番号11(旧バージョンのCSAT)を編集しました。 

2024年3月7日

  • セクションX、Zendesk AI機能に関するお知らせを追加
  • セクションI - Support- 番号7(閲覧権限):
    • 「閲覧権限」は、「組織」に対してではなく、「インスタンス/ブランド/組織」全体に適用されることを明確にする。
    • エンドユーザー固有の組織の動作に関する新しい規定を追加しました。 
  • セクションI、Support、番号9(メール):  
    • Zendesk Supportがエンドユーザーにメールを送信する状況を拡張。エージェントがチケットに回答するだけでなく、メールチャネル経由の返信や、自動化やトリガによって開始された返信を含むようになりました。
    • デフォルトでは、自動通知に、最新のチケットの対応またはその他の設定済み情報(PHIなど)が含まれるように指定します。

2023年10月25日

  • はじめに:HIPAA対応アカウント向けの明確な開始言語
  • セクションⅡ「GuideとGather」の#1(ヘルプセンターの制限):説明のためにIP制限を制限付きの記事に置き換えました。

2023年4月13日

  • セクションI. Support番号4(API): 
    • 明確にするために認証方法へのリンクを追加しました 
    • b)業界のベストプラクティスに合わせてローテーションの推奨時間を正確に削除し、REST API利用規約(冗長性への参照を削除しました。
    • を追加し、c)を使用して、APIの基本認証の使用について警告を追加。 
  • セクションⅡ、Guide:
    • 番号1(ヘルプセンターの制限):製品の機能に合わせて、非公開型または制限付きのヘルプセンターへの参照を追加します。
    • 番号5(@メンション):製品に合わせて@メンションを無効にするオプションの追加 機能 
  • セクション III メッセージング: 
    • 番号1と2(サードパーティチャネルとプライベート添付ファイル):明確のためにセクション ID (i)と(ii)を追加しました
    • 2(プライベート添付ファイル):説明のために「URLまたは」を追加しました。
    • 番号7-10(エンドユーザー認証、Answer Bot会話削除、墨消し、マルウェアスキャニング):透明性のために完全なセクションが追加されている
  • セクション*** Zendesk SuiteのSunshine Conversations Sunshine ConversationsがBAAの一部として追加されたため、セクション全体が追加されました 
  • セクションV. チャット番号3(エージェントワークスペース):ちょっとした言い回しの修正
  • セクションV III モバイルアプリ 番号5-7(マルウェアスキャニング、墨消し、エンドユーザー認証):透明性のためにセクション全体を追加

2023年2月24日

  • 「I. Support」セクション(No.3)では、UIの統一に伴い、 SupportとChatのIP制限間の個別の制限が削除されました。
  • セクションI.SupportNo.5:要件を満たせなかった場合の説明を追加 
  • セクションI.Support()、番号7:「契約者はその必要がない」は「契約者はその必要はありません」に変更されました。
  • セクション IV.Chat番号2:メールを使用したChatからのデータのすべてのエクスポート機能が禁止されており、会話ログとパイピングのみの対象ではないことを示しています。 
  • セクション III.メッセージング:Zendesk Business Associate Agreementの範囲に加え、Zendeskメッセージング機能のアカウントに追加されたセクション。

2021年7月9日

  • エージェントワークスペースの使用に関する責任についてChatセクションにポイント3.を追加します。

2021年1月21日

  • 番号1.11の追加により、アンケートの一部としてメールで送信されたデータについて「契約者」が責任を負わない限り、 CSATの利用は無効になります。 
  • 第1.7項:ユーザー側で当該データへのアクセスを既に行っているユーザーに対して、閲覧権限を変更する権限を「契約者」に拡大するための警告。
  • インラインURLではなく、テキスト内の埋め込みリンクを会社のスタイルに合わせて、ドキュメント全体を更新 (設定コンテンツには影響しない)。

2020年8月

  • Explore Enterpriseの追加で、ダッシュボード共有機能を拡張
  • Chatの添付ファイルの利用禁止の解除(Supportの認証要件の対象となる)
  • カスタムフィールドでのePHIの使用禁止が、インサイトの使用にのみ適用され、グローバルに適用されることはありません
  • 展開済みサービスのアドオンを提供する新しいセクションの追加。
  • さまざまな文法/書式の編集(コンテンツとは無関係)

2020年7月13日:

  • 製品内2FAとしてのSMSのネイティブ使用とは対照的に、サービス経由でのSMSの使用に関する曖昧さを排除: * 疑義が生じるのを避けるため、SMSに関するセクション10のePHIに関連するデータに関する注意事項は、製品内2FAの使用(セクション1.aで説明)には適用されません。なぜなら、この2FA機能は本人確認のために数字の文字列を送信するだけであるからです。」

2019年12月13日 

  • エージェントのアクセスに関するMFAが適用されている限り、このような制限は許可されません。

2019年12月17日 

  • エージェントがエンドユーザーのコメントをモデレートし、すべてのPHIを削除する限り、Guideのエンドユーザーのコメントを許可します。

2019年11月6日

  • 記事が更新され、「契約者」が単独の裁量で選択した変更を反映して、特定の構成を延期または置き換えることができるようになりました。

「以下に記載した特定の設定または以下に記載した一連の必要な設定を実装および遵守しなかった契約者は、

加入者自身の責任と加入者の単独の裁量:およびそのような失敗により、「Zendesk」およびその従業員、エージェント、および関連会社は、このような失敗に起因する「電子保護対象の医療情報を含む」の不正アクセスまたは不適切な使用または開示に関して、一切の責任を負わないものとします。 」でツリーベースの最大権限を有効にします。 "

  • その他の変更点:
    • 1. 契約者がSMSの送信にPHIが含まれないことを確認するすべての責任を負う場合において、SMSを使用する機能。
    • 2.Chatで添付ファイルを使用する場合、添付ファイルにPHIが含まれていないことを確認することを契約者が全責任を負う必要があります。

2019年3月6日 

  • が更新され、 Zendesk Exploreの設定も追加されました

2019年1月17日

  •  さんがを更新しました。これにより、Chatで添付ファイルを無効にすることができます。

翻訳に関する免責事項:この記事は、お客様の利便性のために自動翻訳ソフ トウェアによって翻訳されたものです。Zendeskでは、翻訳の正確さを期すために相応の努力を払っておりますが、翻訳の正確性につ いては保証いたしません。

翻訳された記事の内容の正確性に関して疑問が生じた場合は、正式版である英語の記事 を参照してください。

編集日時:2025年1月28日 · Craig Lima

0

フォロワー

1

投票

0

コメント


Craig Limaさんがコメントを作成しました:

コメントZendesk policies and agreements

July 9th 2021 edit:

1. Adds point 3. under Chat section for responsibilities around Agent Workspace usage.

コメントを表示 · 投稿日時:2021年7月09日 · Craig Lima

0

フォロワー

0

投票

0

コメント


Craig Limaさんがコメントを作成しました:

コメントZendesk policies and agreements

January 21st, 2021

Addition of number 1.11 disallows CSAT unless Subscriber assumes responsibility of data sent via email as part of the survey. 

Caveat in number 1.7 to make allowances for Subscribers altering viewing permissions due to users already having approval to access such data on their ends.

Updated entire document to match company stle of embedded links within text as opposed to inline URLs (no impact to configuration content). 

コメントを表示 · 投稿日時:2021年1月21日 · Craig Lima

0

フォロワー

0

投票

0

コメント