セキュリティチームのぐっちーです。クラウドサービスにおいて利用される暗号鍵を自社で管理する取り組み（BYOK）をいろいろなサービスで行ってきましたが、これから取り組みをブログにしていきたいと思います。第一弾として、特定の製品の話ではなくBYOKの全般的な話をしていきたいと思います。
クラウド上に格納したデータはブラックボックス
何年にも渡って語り尽くされ「今更かよ！」というレベルの話ですが、基本のおさらいのために改めて整理します。クラウドサービスでは、取り扱うデータの管理はクラウドサービス事業者（CSP：Cloud Service Provider）に依拠し、基本的にブラックボックスです。仕組み上、アップロードしたデータやクラウドサービス上で生成したデータはクラウドサービス事業者から閲覧可能です。
利用規約・プライバシーポリシーにおいても、格納したデータにクラウドサービス事業者がアクセス可能となっているケースもあります。実際に、クラウドサービス事業者が利用規約を根拠に、顧客データを研究開発に利用したり、国や裁判所の命令でデータを提出するケースがあります。
さらに、クラウドサービス事業者側の内部不正や人的ミス、安全管理処置の不備等々により、利用規約の範囲を超えてデータが取り扱われることも考えられます。プライバシーポリシーの範囲を超えたデータ利用で炎上したニュースを見たことある方も多いと思います。
少し煽りすぎかもしれませんが、その辺も含めてクラウドサービス上のデータはブラックボックスであるとい言うことができるかと思います。
クラウドサービス事業者の従業員個人の内部不正によるデータの閲覧・不正利用は、それが発覚した際の懲戒などのリスクがあるため、不正を行う動機は薄いものだと考えられます。
また、組織的な不正に関しては、それが公となった場合の風評被害（だれもそのサービスを利用しない）や損害賠償を考えると、そちらも動機や発生可能性は低いものではあると考えられます。
なんでこのような話をするかというと、極端に怖がりすぎるのも、極端に甘く見すぎるのも、どちらもよろしくないと思ので、まずは事実を整理しようと思ったからです。
CSP側の対応やコスト視点
こんなことを言い出すと、誰もクラウドサービスを利用しなくなるのでクラウドサービス事業者も黙ってはいません。特に大手のクラウドサービス事業者は、クラウドサービス利用者（お客様）との責任範囲を設定し、複数のセキュリティ専門家やプライバシーの専門家と自らの責任範囲におけるデータの取り扱い方法を定義した上で、それを担保するために信じられないほどのガチガチの内部統制を整備しているケースが多いです。
僕も、過去に複数の大手クラウドサービス事業者の監査を行いましたが、一般の企業では考えられないほどの対策を行っているケースを何件も見てきました。超厳密なアクセス権の管理、特権管理、権限の分離、ログ取得、監視など様々な手法を通じてお客様のデータを管理しています。
クラウドサービス利用者がそれだけの内部統制を行うのは簡単ではないので、普通の企業ではインフラ部分の管理委託の意味合いも含めてクラウドサービスを利用した方が、インフラ部分の運用まで含めたトータルコストの効率が良く、多くの恩恵を得られるケースが多いと思います。これがクラウドサービスが爆発的に普及している大きな要因の1つですね。
また、「お客様（ユーザー）」側の責任範囲についてやるべきことをしっかりとやっていないユーザーを多く見受けられます。例えば、ユーザー側の権限の範囲がガバガバだったりなどですが、クラウドサービス事業者側の責任範囲を気にする前に、自社でできることをどうにかした方がいい会社も多いでしょう。
大手でグローバルでもエンタープライズに導入実績が多いサービスの内部統制は厳しいことが多いですが、新興SaaSなどでは情報の取り扱いが酷い会社もあります。 自社が利用しているクラウドサービスの統制について、クラウドサービス事業者が発行するセキュリティホワイトペーパーや、SOC 2レポートなどの監査報告書、各種認証の取得状況等を参考に総合的に評価しつつ、そのクラウドサービスで取り扱うデータの重要度に応じて利用をご検討ください。
CSP任せにできないデータの暗号化鍵を自社管理する
クラウドサービス事業者と責任分解点を定義し、責任分解点の向こう側を「任せる」ことで、トータルコスト的にも恩恵が得られることを先ほど紹介しました。しかし、クラウドサービス事業者任せにできない超重要データを取り扱っている場合はこの限りではありません。
例えば、国家機密に関連する情報や、航空宇宙・防衛産業に関わる情報などは、クラウドサービス事業者からのデータ閲覧を気にするのも理解できます。「クラウドサービス事業者が不正に情報を読み取る動機は薄い」とは言いましたが、これぐらいの機微情報になると話は変わります。不正をするインセンティブはあると言えると思います。
また、民間企業であっても大量のマイナンバー情報や、大量の遺伝子データなど、要配慮個人情報を大量に取り扱うケースにおいて説明責任を果たすには、クラウドサービス事業者側の責任範囲においての情報漏洩を気にする必要もあるかもしれません。
そんなケースに有効なのが、暗号化鍵を自社管理すること（BYOK[2]）です。BYOKは、クラウドサービスのユーザーが自身の環境で暗号鍵を生成し、それらの暗号鍵を自社のコントロール下に置きながら、利用しているクラウドサービス上のデータの暗号化で利用する機能です。クラウドサービス事業者の従業員は暗号化されたデータを復号することができないので、クラウドサービス事業者側によるデータ読み取りを懸念する場合には有効な手段です。
政府調達クラウドサービスでは（ほぼ）必須要件
BYOKは世間一般的にはそれほど浸透していないかもしれませんが、日本の政府機関が調達するクラウドサービスの調達要件となりつつあります。2020年に運用開始された、政府機関のクラウドサービス調達要件である政府情報システムのためのセキュリティ評価制度（ISMAP） [3] では、原則統制除外できない基本要件[4]としてBYOKが定められています[5] 。
また、「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」においても利用者データ（利用者が作成・管理するデータ）を国外に設置されるクラウドに保管する場合はBYOKを利用することと定められていたりします [6] 。
政府機関が全てのデータ管理にBYOKを採用しているわけではないですが、政府機関はBYOKの機能を備えたクラウドサービスを調達し、必要に応じて利用していることがわかります。政府機関にとってはBYOKは大事な考え方であることは間違ありません。
BYOKがハマるユースケース
クラウドサービス事業者からの読み取りを抑制する
BYOKの最も需要があり有効なシナリオ（ユースケース）としては、クラウドサービス事業者からの読み取りを抑制するという点がまず考えられます。通常、SaaSのデータストレージ領域はクラウドサービス事業者の統制下にあり、技術的には閲覧可能となっていますが、自社の暗号鍵を使って暗号化することでクラウドサービス事業者からの読み取りはできなくなります。
そうすることで、クラウドサービス事業者にデータを2次利用されたり、海外に保管しているデータに海外法令が適用されて、いつの間にか合法的にデータが開示されていたというようなケースにも対応することができます。
データが消去されたことを自社で担保する
また、データが消去されたことを自社で担保することにもBYOKは利用できます。通常、クラウド上にアップロードしたデータはクラウドサービス事業者によって管理されているので、確実にデータを消したかどうかはクラウドサービス事業者しかわかりません。もちろん廃棄証明書をもらうことでそれを担保することができますが、あくまで「契約的な側面」での担保であり、廃棄証明書では「技術的な側面」での担保をすることはできません。
そこで、BYOKで利用する暗号鍵を破壊し、元のデータの復号を不可能にすることで、データが論理消去されたことを自社で担保することができます [7]。
クラウドサービス事業者側の侵害リスクを低減する
発生可能性はかなり低いとは思いますが、クラウドサービス事業者側が侵害され、データとクラウドサービス事業者が管理する暗号鍵が全部抜かれてしまったという絶望的な状況が発生する可能性はあります。また、クラウドサービス事業者側のサーバーの公開設定が誤っており、インターネットに公開されてしまったという状況も考えられます。
そのようなケースであっても、BYOKを利用すれば、ユーザー側の暗号鍵が漏洩してなければ、データが閲覧されてしまうことはないという利点もあります。
BYOKの課題
BYOKのいいところばかりを述べてきましたが、BYOKにも当然デメリットがあります。クラウドサービスの性質によって詳細は異なりますが、一般的なものだけ紹介します。BYOKの採否は、以下のデメリット・注意点や取り扱われる情報の重要度、運用コストや費用などを考慮して決定されることが望ましいと考えています。
そもそも対応しているサービスが少ない（SaaSは難しい）
BYOKは対応しているサービスが多くありません。特に、SaaSではBYOKに対応サービスが少ない傾向があります。サービスの性質によって異なりますが、そもそもクラウドサービス事業者としての開発・実装が難しいという側面などもあり、対応しているサービスは多くない1つの要因です。BYOKをクラウドサービスの選定要件とする場合は、かなりサービスが限られてきますし、自由度がかなり落ちることから、私の観測範囲ではBYOKがクラウドサービスの選定基準になることは民間企業ではごく限られています。
鍵管理は自社で実施しなければならない
BYOKを実施すると当然、鍵管理は自社で実施しなければなりませんが、そもそも「鍵管理」というトピックスは複雑・難解なトピックです。
もちろん、何となく管理するだけだったら少し学習すれば誰でもできますし、AWSのKMSなど初心者であっても比較的簡単に鍵管理をできるソリューションは存在します。しかし、鍵を誤って破壊してしまったら、データが失われてしまいます。また、鍵が漏洩すると暗号化しているデータの安全性にも関わります。そんなことを考え始めたらこの領域は本当に沼ですし、その辺を踏まえた運用設計や管理をセキュリティポリシー（管理基準・手順）に落とし込むことはかなり骨が折れると思います。
利用できなくなる機能があったり、パフォーマンスに影響が出ることも
BYOKを実施すると利用できなくなる機能があったり、パフォーマンスに影響が出ることもあります。その辺は本当にサービスによって様々なので、今後書いていくブログで細かくは言及したいと思いますが、例えばクラウドバックアップのサービスであるDruva InSyncではBYOKを実施すると、侵害時の影響調査や内部犯の調査で利⽤する Enterprise Search 機能や e-Discovery 機能が利用できなくなります [8] 。これはDruva社システム側からのデータ読み取りができなくなるためです。
また、自社で管理する鍵と、クラウドサービスとの疎通ができなくなった場合、サービスが一時的に利用できなくなる可能性があります。自社で管理する鍵とクラウドサービスはAPIを通じてやりとりするため、何らかの原因で疎通ができなくなると、場合によっては利用しているクラウドサービス全体がダウンしてしまうという可能性もあります。
対象データが限られることもある
BYOKでは対象データが限られることもあるという点も忘れてはなりません。全てのデータをクラウドサービス利用者によって暗号化されてしまうと、そもそもサービスが提供できなくなるケースがあるので、BYOKによって暗号化するデータの対象範囲はサービスごとに定義されています。自社が保護したいデータとBYOKで保護できるデータが本当に一致しているかは、慎重に確認が必要かと思います。
BYOKの展望
SaaSのBYOKに関しては、現時点では対象サービスが少なく、世の中的にはなかなか普及していないというのが現状です。そのため政府機関など、特殊な要件を持った組織で限定的に利用されています。しかし、ここ数年でSaaSのBYOKの対象サービスが増え、一般化する準備が整ってきたかという印象です。もちろん、BYOKより先に自社の責任範囲での対策を充実させなければならない組織が多いと思うので、すぐに普及するとは思っていませんが、厳しいデータ保護要件を持った企業を中心に利用が徐々に増えていくのではと個人的には思っています。
終わりに
BYOKの概要的な話をしてきました。BYOKによって期待した結果が得られるかどうかはは取り扱う情報資産やユースケース次第かと思いますが、クラウドサービスを安全に利用するための重要なコンセプトの1つであることには間違ありません。次回ブログではZoomを題材に、BYOKの実装方法や実装した際の挙動について見ていきたいと思います。
【余談】そもそも「BYOK」という用語はおかしいもの？
余談ですが、そもそも「BYOK」という用語は技術的におかしいという考え[9][10]もあるので、参考までに紹介させていただきます。考え方の概要は以下の通りです。
- BYOKはBring your “OWN” keyなので、ユーザーが「OWN（所有）する」鍵を持ち込んで使うのがBYOKである。
- NIST SP 800-57 PART 1 REV. 5[11]の定義では「鍵の所有者（Key Owner）」とは、「暗号鍵又は鍵ペアの使用を認可され、その識別子が当該暗号鍵又は鍵ペアに関連付けられているエンティティ」である。
- NISTの「鍵の所有者（Key Owner）」の定義を現在のBYOKスキームに当てはめると、「所有者」はユーザーとクラウドサービス事業者の2者となることがほとんどである。（マスターキーはユーザーで管理するものの、クラウドサービス事業者も一時的なデータ復号で鍵を利用するため）
このような考えもあり、このブログのタイトルは非常に悩みました。実際、海外の文献や最近発表された製品名を見ると「Hold Your Own Key」「Enterprise Key Management」「Costomer Managed Key」や「Key Management in the Cloud Service」「Bring Your Own Encryption」などという表現がなされており、そちらを採用するという考え方もありました。
しかし、日本国内においてはBYOKという表現が最もポピュラーであることと、日本政府が発行するドキュメント[6]においてはBYOKという表現がなされていることを決め手に、BYOKという呼び方を本ブログでは採用させていただきました。また、いきなりこのブログで違う用語を使っても混乱を招くかと思います。
真の意味で技術的にBYOKを実現することは難しいかもしれませんが、世間の様子を見つつ「考え方」としてBYOKという用語を個人的に使おうと思っています。
参考文献・注釈 等
- AWS 責任共有モデル https://aws.amazon.com/jp/compliance/shared-responsibility-model/
- BYOK: Bring your own keyの略
- 政府情報システムのためのセキュリティ評価制度（ISMAP） https://www.ismap.go.jp/csm
- ISMAP管理基準2.2.4には、基本言明要件として、末尾にBが付された詳細管理策（X.X.X.X.B及びX.X.X.X.PB）は原則として実施すべきとありますが、BYOKに関わる管理策（8.1.2.7.PB・10.1.2.20.PB） はそれに該当します。 https://www.ismap.go.jp/csm?id=kb_article_view&sysparm_article=KB0010028&sys_kb_id=0841e2f9db3ed510d2b773f4f3961940&spa=1
- 基本言明要件（8.1.2.7.PB及び10.1.2.20.PB）を採用することによるサービス提供の困難性が認められ、かつ、クラウドサービス事業者内部からの不正アクセス対策を別の手段で実現することで、例外的に基本言明要件（8.1.2.7.PB及び10.1.2.20.PB）を選択しないことも考えられます。また、実際にISMAPサービスリストを確認すると、基本言明要件を除外しているクラウドサービスも存在しています。 https://www.ismap.go.jp/csm?sys_kb_id=cfb60af91baebc1013a78665cc4bcb12&id=kb_article_view&sysparm_rank=2&sysparm_tsqueryId=2db0907cdb879150d2b773f4f39619f6
- 政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針 https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/27e5d72f/20220930_resources_standard_guidelines_policy_01.pdf
- 暗号化消去が適切な抹消手段か否かは組織のデータ抹消処理要件によって決まるかと思います。この辺に関わる考え方や詳細な話は「NIST SP 800-88 媒体のデータ抹消処理（サニタイズ）に関するガイドライン」等をご確認ください。 https://www.ipa.go.jp/files/000094547.pdf
- 「経済産業省 デジタルプラットフォーム構築事業報告書 – DX オフィス関連プロジェクト管理業務等の効率化に関するデジタルツールの導⼊実証・調査事業」では、 Druva inSync は BYOK に対応しているが、侵害時の影響調査や内部犯の調査で利⽤する Enterprise Search 機能や e-Discovery 機能が利⽤できなくなることから、本事業では BYOK の適⽤を⾒送ったとしています。https://www.meti.go.jp/meti_lib/report/2020FY/000143.pdf
- Key Management in Cloud Services:Understanding Encryption’s Desired Outcomes and Limitations https://cloudsecurityalliance.org/artifacts/key-management-when-using-cloud-services/
- NISTIR 7956. Cryptographic Key Management Issues and Challenges in Cloud Services, September 2013. https://csrc.nist.gov/publications/detail/nistir/7956/final
- NIST SP 800-57 PART 1 REV. 5 https://www.ipa.go.jp/files/000090943.pdf
