SaaS

Zoomの録画をBYOK(Zoom CMK)で保護する – BYOKやってみたシリーズ Zoom編

セキュリティチームのぐっちーです。先日、日本で初めてZoomの録画データに対してBYOK(Zoom CMK:Zoom Customer Managed Key)をやってみました。先日公開したBYOKの一般論のブログと併せてご確認いただけたら幸いです。

ZoomにおけるBYOK(Zoom CMK)

先日公開したBYOKの一般論のブログでは、「超重要データはクラウドサービス事業者からの読み取りをケアするためにBYOKを実施することが考えられる」とお話ししました。そんな、BYOKで暗号化する重要データというとBox等のクラウドストレージを想像することが多いかと思います。

しかし、Zoomの録画データに関しても油断してはいけません。例えばもし、政府機関での重要な会議や、企業でM&Aなどに関する会議を録画するケースがあったとしたら、その録画データに関しては厳重に保護する必要があると思います。クラウドストレージの情報とは違い、ドキュメント化されてないが故に「ぶっちゃけ話」をしているケースもあるかとおもいますので、録画データの重要性は測り知れません。そこで、今回はZoomの録画データ等を当社の管理する暗号鍵で暗号化して保護する検証をしてみました。[1]

前提条件

  • 設定するにはZoomの管理者権限と自社のAWS環境、さらにAWS Key Management Service (AWS KMS) の管理権限が必要です。
  • 現在、Zoom CMK で利用できる鍵はAWS Key Management Service (AWS KMS) 上にある鍵のみが対象となります。
  • 必要なZoomのライセンス等は、Zoomの購入元にお問合せください。追加ライセンスが必要な場合があります。
  • Zoom デスクトップ クライアントは、Windows 5.7.6 以降、macOS 5.7.6 以降、Linux 5.7.6 以降、Zoom モバイル クライアントは、Android 5.7.6 以降および iOS 5.7.6 以降が対象です。
  • 本ブログは、AWS Key Management Service (AWS KMS) の詳しい利用法や、鍵管理に関するトピックは取り扱っていません。
  • 本ブログは、2022年11月25日時点の情報を元に記載しています。

対象データ

Zoomのサポートサイト [2] によると、ZoomのBYOK(Costomer Managed Key)で暗号化する対象となるデータは以下の静的データです。注意が必要な点として、現在進行形で実施されているビデオ会議の通信などの暗号化についてはBYOK(Costomer Managed Key)を利用することができません。

  • Zoom Meeting のクラウド レコーディング(文字起こしやチャット テキストなど)
  • Zoom Webinars のクラウド レコーディング
  • Zoom Phone のボイスメールとレコーディング
  • Zoom Rooms 用のカレンダーのアクセス トークン
  • ユーザーのカレンダーのアクセス トークン
  • Microsoft Teams のアクセス トークン
  • ミーティングおよびウェビナーのアーカイブ

Zoom でBYOKを設定する

AWSで鍵を生成

まず、AWSのアカウントを用意して、BYOKで利用する鍵を生成します。[AWS管理コンソール] > [KMS] でカスタマー管理型のキーを生成しましょう。作成の際の設定値は以下の通りです。尚、BYOKはリージョン指定がされていることがありますが、Zoomに関してはリージョンについては指定は特にありません。私は、東京リージョン(northeast-1)、大阪リージョン(northeast-3)、バージニア(us-east-1)、オハイオ(us-east-2)を試しました。

キーポリシー(キー仕様アクセス許可設定)には、以下を登録しました。尚、「409910850980」の部分は変更不要ですが、「自社のASWアカウントIDを入れてね」の部分は鍵を設置したAWSアカウントのIDに変更してください。また、このキーポリシーはレプリケートされたマルチリージョンキー間で同期されず、個別に設定する必要があるためご注意ください。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::自社のASWアカウントIDを入れてね:root"
            },
            "Action": "kms:*",
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::409910850980:root"
            },
            "Action": [
                "kms:Decrypt",
                "kms:DescribeKey",
                "kms:GenerateDataKey*"
            ],
            "Resource": "*"
        }
    ]
}

Zoomで鍵を登録

AWSのKMS側でARNをコピーします。

次に、Zoom側の管理画面の[詳細設定] > [セキュリティ] に遷移し、[Configure Customer Managed Key]を選択します。

ここでは、先ほどコピーしたARNを貼り付けます。下記の画像は東京リージョン(northeast-1)、大阪リージョン(northeast-3)のARNを設定している画像です。

Zoom のBYOKは全体に割り当てる他、ユーザーグループを指定することもできます。ユーザーグループを指定する場合は、Zoomでユーザーグループを作成した上で、Zoomのサポートにチケットを切って作業してもらうことが必要となります。

登録すると、登録した鍵が表示されます。ステータスが [Standby] となると、BYOK適用できる準備が整ったという証です(BYOKはまだ適用されていません)。

最後にBYOKの対象データを選択することで、設定は完了です。この対象範囲の設定はユーザーが任意に増やすことはできますが、減らす場合はZoomのサポートに連絡して作業をしてもらう必要があるのでご注意ください。

さらにオプションとして、鍵のステータスが変更された場合のアラートメールの送信先を登録可能です。数名のシステム管理者のアドレスを登録しておくと良いと思います。

動作確認

現時点では、ZoomのBYOKは設定後に作成・保管されるデータのみが、BYOKによる暗号化の対象のようです。そのため、初期設定が全部終わった後、録画等の「暗号化が発生するアクション」をしないと、BYOKは開始されません。実際にZoomのクラウド録画などをすると以下のように、キーステータスが変わります。

個別の録画にアクセスした場合、BYOKが適用されている証として、上の部分(下記画像赤枠)にマークが出現します。ちなみに、Zoom CMKで暗号化できるデータは、CMKを適用した状態で生成された録画データであり、CMKを適用する前に生成された録画データは対象外のようです。

AWS のCloudTrailを確認すると、録画データにアクセスしたり、ダウンロードした時間に、AWS KMSで復号されるイベントが発生していることがわかりました。

鍵を破壊してみた

動作確認をしましたが、正直、BYOKでデータが暗号化されているかの実感が湧きません。暗号化マークは出現するものの、ユーザー体験としては何も変わることがなかったため、逆に「BYOKをやった気になっただけでは?」とちょっとだけ不安になりました。ということで鍵を破壊(無効化)して、本当にBYOKが実施されているか確認してみることにしました。まず、AWS上でキーを無効化してみます。

厳重注意

この検証は失敗すると、Zoom上のデータを失ったり、サービス継続に影響をもたらす可能性があるものです。まずは検証環境で動作確認の上で実施いただくことを推奨いたします。

すると、Zoomの「復号化クエリステータス」が [Faild] に変わります。この時点ではサブの方の鍵が参照されており、ロク録画データの閲覧などは問題なく利用することはできます。

ちなみに、KMSの鍵が動作していないことをZoom側が検知すると、以下のようなアラートのメールを発報してくれました。

そして、サブの鍵も無効化して、動作確認をしてみました。録画データのダウンロードに関してはすぐにダウンロード不可の状態となりました。その際の挙動については下記の動画をご確認ください。

また、Zoom管理画面上からの閲覧ですが、鍵を無効化してすぐは録画データを閲覧することができましたが、しばらくすると下記画像のように、閲覧ができない状態となりました。

エンドユーザーに影響がある点としては、鍵を破壊した状態で、新規のクラウドレコーディングを実施しようとすると、レコーディングがエラーとなり失敗する形となりました。Zoomの会議自体は通常通りできたのですが、鍵がないと録画ができない点は考慮しておかないと万が一の際にパニックになりそうです。

鍵を無効化した状態で会議等をやってみて様子を見ましたが、データ保管などに関わる動作以外は通常通り動いているように感じました。ちなみに、今回は厳密な鍵破壊ではなく、鍵を「無効化」をしてみて検証しておりますが、再度有効化戻すとZoomにおいても元の状態に戻りました。

鍵を破壊して差し直したらどうなるのか?

鍵を破壊して、その後、新しい差し直すオペレーションをしたら、どうなるのかを検証してみました。前提として、これはZoom社としては意図した利用方法ではないと思うので、実際に本番環境ではやることを推奨していません。

まず、検証ではアメリカのバージニア・オレゴンに設置した鍵を破壊して、その後AWS KMSの東京・大阪に新しい鍵を作成し、Zoomに差し直します。すると「古い鍵(バージニア・オレゴン)で暗号化されたデータ」は引き続き閲覧不可の状態でしたが、新しい鍵(東京・大阪)は通常通り利用が可能で、新規生成される録画データを暗号化することができました。

BYOKを辞めたい時はどうするのか?

BYOKを辞めて、Zoom社によって管理する鍵の利用に戻したい場合については、管理コンソール上からは作業ができません。Zoomのサポートチームと連携して作業が必要なようですので、Zoomの購入元にお問い合わせください。

おわりに

以前、Zoomはセキュリティ不安が叫ばれていましたが、最近ではエンタープライズ水準のセキュリティ仕様・機能が拡充し、ますます欠かせないツールになってきたなという印象です。今後の他サービスのBYOKなどの検証ブログは適宜掲載していきたいと思います。SaaSにおけるBYOKはそもそも対象サービスが少ないですが、徐々に普及し始めている印象を持っているので、今後も注視していきたいと思います。

参考文献・注釈 等

  1. Using Customer Managed Key https://support.zoom.us/hc/en-us/articles/4410211313293
  2. 独自の暗号鍵を使用可能に — Zoom カスタマー マネージドキーの活用 https://blog.zoom.us/ja/zoom-customer-managed-key/

ぐっちー

コンサル会社にてISO27017やISMAP等のセキュリティ規格案件を経験した後、クラティブに転職。趣味はダンス(Soul, Lock, Waack)です。