テナントの暗号化

テナント作成時、Qlik Cloud は複数のセキュリティ レイヤーを使ってデータを保護します。既定では、各テナントが Qlik 暗号化サービスにより管理される一連の暗号化キーを個別に生成することにより、テナントのコンテンツを暗号化して、区別されます。各テナントのキーは、Qlik がサービス間通信をセキュリティ保護するのに使用するキーから区別されます。

Qlik Cloud は、次の暗号化標準を使用します:

• 転送中 — TLS 1.2 暗号化

• 保存中 — AES-256-GCM 暗号化

• プラットフォーム内 (指定の IdP で認証された後) — 整合性、信頼性、および非否認性を確保するため署名済みの JSON Web トークン (JWT)

カスタマー マネージド キー (CMK)

ヘルスケアなど規制が厳しい業界では、セキュリティとコンプライアンスの厳格な規制を満たす必要があります。さらに、多くの商業的顧客は市場機密データに対してデータ分類アプローチを利用し、追加のセキュリティ技術が特定のデータ セットに必要かどうかを判断しています。これらの厳格なセキュリティ要件には、機密性の高いクラウド データを暗号化および復号化するのに使用される暗号化キーを制御する要件が含まれている可能性があります。Qlik Cloud では、カスタマー マネージド キー を使って、Qlik クラウド内の保存中テナント データをセキュリティ保護する暗号化オプションとして、自身のキー (BYOK) を持ち込むことが許可されています。

CMK を使った暗号化は、テナント レベルに適用されます。テナント管理者は、CMK を使用するテナント暗号化を構成できます。Qlik Cloud は、次のキー管理サービス (KMS) プロバイダーをサポートしています:

• Qlik 内部 KMS (既定)

• Amazon Web Services (AWS) KMS

カスタマー マネージド キー および HIPAA

Qlik Cloud は、お客様が カスタマー マネージド キー を使用し、HIPAA ビジネス アソシエイト契約 (BAA) に署名することを条件に、米国 健康保険の相互運用性と説明責任に関する法律 of 1996 (HIPAA) の規制の対象となる個人健康情報 (PHI) をホストできます。Qlik Cloud は HIPAA の規制要件を通じて顧客をサポートできますが、Qlik Cloud を使用している顧客は、独自の HIPAA コンプライアンスに責任を負います。PHI を Qlik Cloud に組み込むには、カスタマー マネージド キー の使用が必須です。詳細については、「Qlik の信頼とセキュリティ」を参照してください。

Qlik Cloud 暗号化アーキテクチャの概要

次の図は、テナントでデータを暗号化する Qlik Cloud 暗号化サービスの概要です。テナントが AWS KMS を使って CMK 向けに構成されている場合、Qlik Cloud のサービスがデータの暗号化・復号化に必要となるたびに、暗号化サービスは AWS KMS を呼び出して AWS KMS キーを使用します。そうでない場合、既定で、テナント データは Qlik 内部 KMS で生成されたデータキーを使って暗号化されます。

カスタマー マネージド キー に対する顧客の責任

CMK では、顧客が自分のキーを完全に制御できます。顧客の組織は、以下の領域を含むキーのライフサイクルのすべての側面を作成、維持、管理する責任を負います。

AWS KMS のキー セットアップ

• AWS アカウントの作成と KMS の使用。

• キーの作成と Identity and Access Management (IAM) 権限とロールに関する AWS KMS キー管理ポリシーの確立、およびキーの作成、無効化、および削除などの関数を誰が実行できるか。

AWS KMS のキー管理

テナントで AWS KMS キーを使用して保存中のデータを暗号化するように構成すると、キーの管理について責任が発生します。AWS KMS キーが誤って削除されたり無効化されたりしないように保護することは重要です。Qlik は、これらのキー管理関数とその他に関するプロセスを確立することをお勧めします。これらは顧客管理キーであるため、Qlik Cloud は CMK を無効化または非アクティブ化するのを防ぐことはできません。

• AWS KMS キーの無効化。このアクションは、一時的に Qlik Cloud が AWS KMS がデータ キー (暗号化に使用される) の生成と復号化操作のための API コールを行うことを防ぎます。例えば、スケジュールされたリロードまたは Qlik Cloud の背景で実行され、データの暗号化と復号化が必要なタスクは、キー (またはキーへのアクセス) が無効な状態であれば失敗します。キーを再有効化すると、テナントへのアクセスが再確立されます。

• AWS KMS キーの削除。このアクションは、Qlik Cloudテナントが完全に無効化されます。キーの削除をスケジュールすると、テナントはすぐに無効モードに入ります。これにょり、キーへのアクセスが防止され、テナントがロックされます。AWS KMS には、キーの削除について広範な制御があり、ニーズに合わせてカスタマイズできます。例えば、キーが削除されるまでの待機時間を設定して、アラートを使用し、待機時間中に削除をキャンセルできます。

• AWS KMS のキーの回転。キーを削除する際は、AWS KMS [自動キー回転] オプションを選択できます。これにより、1 年間に 1 度、KMS キーの新しい暗号化素材が生成されます。AWS KMS は、暗号化素材の過去のバージョンをすべて保存しているため、その KMS キーで暗号化されたデータならどれでも復号化できます。AWS KMS は、KMS キーが削除されるまでは、回転されたキー素材を削除しません。AWS KMS は、適切なキー素材を使って透過的に復号化するため、回転された KMS キーを安全に使用しても、Qlik Cloudカスタマー マネージド キー 統合に影響することはありません。これは、完全に新しい AWS キーおよび、その新しいキーに Qlik CMK キー プロバイダーを変更し、テナントの完全な再暗号化を強制する操作とは異なることに注意してください。「テナント暗号化の構成」を参照してください。

• キー使用の監査 — AWS CloudTrail などの KMS キー監視ツールを使って、暗号化操作を監視すうることを検討します。operations.

• キー アクセスの制御 — キー ポリシーをセキュリティ保護して、不要なアクセスまたは変更を阻止します。

• キー可用性の確保 — キーがアクティブな状態を維持および徹底します。アクセスの喪失を招きかねないアクションを防ぎます。他の AWS サービスと同様、AWS KMS へのアクセスが中断された場合、テナント データは利用できません。AWS KMS には、インフラストラクチャの冗長性を達成するための、地域と高アベイラビリティ ゾーン経由のレジリエンスが内蔵されています。AWS KMS セキュリティについては、「AWS キー管理サービスのレジリエンス」を参照してください。

詳細については、AWS KMS のマニュアルを参照してください。

• キーの管理
• 認証とアクセス制御
• セキュリティ

単一リージョン キーからマルチリージョン キーへの移行

カスタマー マネージド キー は、ディザスター リカバリ プロセスをサポートするためにマルチリージョン キーをサポートしています。現在単一リージョン キーを使用している場合は、プライマリ リージョンで障害が発生した場合にバックアップ リージョンでテナントをシームレスに使用できるように、マルチリージョン キーを作成することをお勧めします。

マルチリージョン キーの作成方法については、「AWS KMS ディザスターリカバリ (DR) のためのマルチリージョン キー」を参照してください。

CMK 制限と考慮事項

次のセクションでは、Qlik Cloud の CMK に関する制限事項と注意事項が説明されています。

• 独自の CMK を使用するようにテナントを構成すると、Qlik 内部 KMS 暗号化を使用したり、別の CMK にキーを変更するよう戻すことができるようになります。

• CMK は、外部キー プロバイダーとして AWS KMS のみをサポートします。

• CMK は、左右対称の暗号化キーのみをサポートします。

• CMK は、ディザスター リカバリ プロセスをサポートするために、単一リージョン キーからマルチリージョン キーに移行しました。

• カスタマー マネージド キー は、Qlik Mobile Client、データ ゲートウェイ - 直接アクセス、または Qlik Sense Business で使用できません。