成績証明書
IL-SUNG LEE: 皆さん、こんにちは。それではここから始めましょう。私の名前はイ・イルソンです。私の他に、PayPal の Greg King と同僚の Joseph Valente がいます。そして、私たちがここに来たのは、データのセキュリティと透明性のための、さらなる制御、新しいサービスの提供についてです。それでまず第一に、今日私たちが何を話すか知っている人はいますか?誰でも？ OK、ティムは当社のエンジニアリングディレクターであり、不正行為をしているのでカウントされません。わかりました、はい?
聴衆: ゼロトラストですか?
IL-SUNG LEE: ゼロトラストですか?いや、全然違いますね？とても近いです。それが何であるかを説明する前に、昨年、私は実際にこれと同様のステージに上がり、どのようにして Cloud HSM を発表したかについて話しました。そしてそれは安堵でした。ようやく妻に自分が取り組んできたことを伝えることができたので、とても安心しました。なぜなら彼女には何も分からなかったからだ。彼女には言いません。そして最終的にリリースしたとき、私が彼女に「これが私がやっていることなんです」と尋ねたところ、彼女は「まだ理解できないんですよね？」と言いました。そして今回も同じことをしてみました。私は、私が今取り組んでいることを話してもいいよ、と言いました。それで彼女に説明しましたが、彼女は「まだ理解できない」と言っていました。それで、ご存知のとおり、私はあきらめました。ただし、GCP の現在の暗号化については話しません。外部キー管理について話します。いいですか?
今朝基調講演に行った人なら、トーマスとスザンヌが話しているのを聞いたことがあるでしょう。それから、重要なアクセスの正当化です。ご質問がございましたら、できるだけお声がけください。聞いてみます。そうでない場合は、セッション後に会いに来てください。ただし、GCP での現在の暗号化に関して私たちが行っていることを簡単に復習したいと思います。そしてこれは、次に話すことについての良い枠組みを与えるでしょう。そこで私はこのスライドを何度も見せてきました。また、基本的には、Google Cloud で保存データを暗号化するための現在のサービスが何であるかを説明しています。
さて、まず第一に、このスケールは左側で、基本的に Google がすべてのキーを制御していることを示しています。ここで、デフォルトの暗号化などについて話します。そして、実際に以前にも述べたように、当社はこれを実現した最初のクラウドであり、保存されているすべてのデータはデフォルトで暗号化されます。そして、それをオフにする方法はありません。私たちはそれを大規模に行います。私たちは影響を与えない方法でそれを行います。透明です。ただし、これは、お客様がクラウドに持ち込むすべてのデータに対して行われます。そして、左側で、または右側で、申し訳ありませんが、Google はキーを制御できません。その中間には、さまざまな選択肢がありますよね?したがって、鍵とデフォルトの暗号化をより詳細に制御したい場合は、Cloud KMS を提供します。
Cloud KMS を使用してデータを直接暗号化できます。あるいは、当社のストレージ サービスの一部と統合することもできますよね?そして、キーを無効にするという意味で実際にキーを制御できるようになります。回転させることができます。それらを使ってあらゆる種類のことができます。しかしその後、顧客は、たとえば FIPS 認定を取得したものが必要なので、コンプライアンスを支援するものが必要だと言い始めます。そこで、Cloud HSM を提供しました。これにより、クラウドでホストされ管理される HSM サービスを実際に利用できるようになり、キーを FIPS 140-2 レベル 3 サービスに配置できるようになります。また、GCS (クラウド ストレージ) と Compute Engine の両方に暗号キーを提供する顧客もいます。そのデータへのアクセスが必要な通話を行うたびにキーを持参する必要があります。なので毎回持っていく必要があるものです。この 2 つのサービスでのみ利用可能です。そしてついに、一部のお客様が「自分のデバイスを持ち込みたい」と言うところまでたどり着きました。デバイスにアクセスできないようにしたいのですが。私にはコントロールがあります。したがって、私はいくつかの [聞き取れない] データセンターで HSM を使用するつもりです。また、同様のことを行っている顧客も多数います。
さて、クラウドのパワーと処理能力を活用したい一方で、キーの所有と制御をどのように維持するかという問題が残ります。その場合、実際に、このスケールのまさに右側に選択肢があれば素晴らしいと思いませんか?ここで、外部キー マネージャーが登場します。これは現在アルファ版ですが、間もなくベータ版になる予定です。そして本質的に、これは、Google の外部でキーを使用して、保存されているデータを実際に暗号化することに関するものです。ここで、外部キー マネージャーについてもう少し詳しく説明します。
その前に、少し戻って、Google Cloud で保存データの暗号化を行う方法について少し復習しましょう。つまり、お客様がデータを当社のクラウドに持ち込むとき、私たちはそのデータを取得し、それをシャードに分割します。それを管理可能な塊に分割します。そして、これらの小さなチャンクごとに、暗号化に使用される独自の AS キーが与えられます。さて、そのキーはデータ自体に残りますね?そして私たちはこれを大規模に行っています。そして、そのキーはデータと一緒に残るため、より高いレベルのキーを使用してラップする必要があります。用語を理解していれば、私たちはエンベロープ暗号化を行っています。そして、そのキーは当社独自の内部 KMS システムのいずれかに存在します。あるいは、ご自身で使用している場合は、Cloud KMS または Cloud HSM システム内に置くこともできます。したがって、制御はできますが、それは当社のクラウド内でホストされます。さて、外部キー管理の場合、そのキーは実際には Google の外部に存在します。 Google の敷地外のシステムにあります。したがって、BigQuery または GCE Persistent Disk でデータをホストしている場合、または基本的に Cloud KMS への直接対称暗号化呼び出しを行っている場合は、実際に HTTPS チャネルを通じてクラウドの外部にあるこの鍵を利用して、この外部エンティティ。現在、私たちのために準備ができているパートナーが多数います。実際にベータ版をリリースする際には、すぐに統合する準備ができています。そのため、Equinix、Fortanix、Ionic、Talis、Unbound のパートナーはすべて、EKM ソリューションとすぐに統合できるソリューションを提供しています。
さて、これを行うことの主な利点は何でしょうか?まず第一に、あなたは重要な出所を維持していますよね?つまり、私が言いたいのは、鍵がどこから来たのかを正確に知って、実際に理解して推論できるようになるということです。鍵がどこにあるかは正確に知っています。なぜなら、鍵は私の管理下にあるからです。何部あるのか、誰がアクセス権を持っているのかはわかっています。そして、それは私自身次第なので、おそらく私自身の独立した監査ログを持つこともできます。別の理由として、キー アクセス制御の要件があることが考えられます。そして、これはかなり大きな問題ですよね？したがって、ここでは、キーが常に Google の外部にあるという事実について話しています。その外部暗号化キーが Google 内部に持ち込まれることはありません。これは自分の鍵を持参するわけではありませんね?その鍵は私たちの境界の外側にあります。したがって、そのキーは保存データを復号化するために必要です。そのキーにアクセスできなければ、実際にそのデータを保存して使用データにすることはできません。
その結果、たとえばデータを BigQuery に保存し、その鍵を私たちが利用できない場合、実際に復号化するためにできることは何もありません。暗号化されたままになります。お客様からよく聞かれる 3 番目の理由は、鍵を一元管理したいということです。オンプレミスで使用しているキー管理システムが 1 つあります。私はそれを自分用に使用しています。クラウド内の自分のキーとして使用したいと考えています。そして、それを使用して実際に特定のポリシーを適用し、それらのキーへのアクセスを実際に許可または禁止したり、キーを削除したり、必要なことをすべて実行できる単一ポイントを持ちたいと考えています。これにより、マルチクラウドやハイブリッド クラウドなども容易になります。しかし、これは、キーに関するポリシーを実際に適用する、非常に興味深い方法を提供します。そして、これはすぐに重要になります。このサービスの設定は非常に簡単になりました。これは、ベータ版を出荷した後の UI がどのようになるかのスナップショットです。
したがって、以前に Cloud KMS を使用したことがある場合は、通常、実際に鍵が提供され、その鍵の種類が示されることをご存知でしょう。 HSM が必要ですか?ソフトウェアが欲しいですか?ただし、キーの生成場所を選択するため、少し異なります。今日、先ほど発表しましたが、たとえば、Cloud HSM には外部ソースからキーを実際にインポートできる機能が追加されました。そしてそれがGAです。これでキーをインポートできるようになります。そして、実際に 3 番目のオプションを使用できるようになりました。それは、外部で管理されたキーを使用することです。 UI を見ればわかるように、その仕組みは、私たちと外部システムの間で少しのハンドシェイクが行われることです。外部システムは、サービス アカウントにキーへのアクセスを許可する必要があります。そのため、一番下にサービス アカウントが用意されています。ここではうまく機能しません、申し訳ありません。ただし、その最下部には実際にサービス アカウントが提供されているため、Cloud KMS 用のサービス アカウントが何であるかがわかります。
そして外部側では、キーを作成すると、キー URI が与えられるので、その URI ボックスに一番下に入力します。それが完了したら、キーを作成します。キーが存在し、到達可能であることを検証します。基本的に、このキーは他のすべてのキーと同様に Cloud KMS にキーとして表示されますが、プロパティで外部であることが示される点が異なります。したがって、これを実際に達成するためのワークフローは非常に簡単です。対称キーでのみ使用できます。将来的には拡張も検討していきたいと考えております。すべての地域でご利用いただけます。リージョンが EKM サポートを持つということの実際の意味は、外部キーに送信して通信するために必要な情報が、作成したリージョンから開始されることです。
つまり、この KMS キーをたとえばフランクフルト地域で作成した場合、その外部キーにアクセスしようとするたびに、フランクフルト経由でアクセスされることになります。または、マルチリージョンの 1 つを介して実行する場合は、そのマルチリージョンの一部であるデータ センターのいずれかを介して実行される可能性があります。さて、もう 1 つは、やはり URI が外部から提供されることです。そして、パートナー側で実際にこれを実現する方法についてのドキュメントがパートナーから提供されています。次に進む前に何か質問はありますか?わかりました、素晴らしいです。そこで、このサービスが提供するものを本当に理解していただくために、いくつかの注意点もお伝えしたいと思います。繰り返しになりますが、BigQuery、GCE、対称キー暗号化で利用できます。ご存知のとおり、この機能はそれらのサービスのために設計されました。今後、他のことについて議論が行われる可能性があります。しかし、それが私たちが実際にこれを設計した目的です。
さて、明らかに、重要なシステムが私たちの制御の外、クラウドの外、インターネット上にある場合、追加の障害点が発生することになります。それは単にシステムに固有のものです。その結果、信頼性が低下する可能性があります。ご存知のとおり、Google Cloud 内に完全に含まれているわけではありません。したがって、キーが常に到達可能であること、ネットワークが常に到達可能であることなどを完全に保証することはできません。したがって、そのようなことがあなたにとって非常に大きな懸念事項である場合は、データセンター内ですべてを管理する Cloud KMS への Cloud HSM の使用を検討する必要があります。そして、それらは非常に、非常に、より高い信頼性をもたらします。外部キーに対する暗号化または復号化リクエストから生じるエラーは、ユーザー エラーとして現れます。これらは、私たちのドメイン外にあるため制御できないと一般に考えられているエラーです。したがって、これらのエラーが表示されると、ユーザー エラーとして表示されます。これは、エラーの計算にはカウントされないことも意味します。そして、これらの外部キーの使用によって発生したエラーには、大量の情報が含まれるようにして、失敗した理由をすぐに確認できるようにします。これは当社のシステムまたは外部システムの問題であることをご理解いただきたいと思います。そして、エラーはエラー メッセージ自体とそのデータ アクセス ログ内に表示されます。したがって、データ アクセス ログを有効にすると、すべての情報がそこに記録され、実際に確認することもできます。
もう 1 つの考慮事項は、前の画面の UI で見たように、基本的に URI フィールドが 1 つあるということです。つまり、お客様には 1 つのエンドポイントがあるか、当社がターゲットとするエンドポイントは 1 つあるということになります。高可用性などが非常に重要である場合は、ソリューションに障害ドメインやグローバル ロード バランサーなどの機能が含まれているかどうかを外部側で検討する必要があります。したがって、それは考慮する必要があります。そして最後に、最も重要なことは、間もなくベータ版が公開されることです。実際にいつなのかを正確に言うことは禁じられています。でも、もうすぐ来るということだけは言っておきます、いいですか？さて、そうは言っても、私は少し話すのをやめるか、話す量を減らします。そして、グレッグ・キングをステージに招待して、これがどのように機能するかを実際に見せてもらいます。
[拍手] グレッグ・キング: ありがとうございます。よし。
IL-SUNG LEE: それで、グレッグ、では、実際にデモに行く前に、私の理解では、PayPal は外部キー マネージャーの使用を検討していると考えています。
グレッグ・キング: はい、そうです。
IL-SUNG LEE: –あなたの難しい問題のいくつかを解決するために。それでは、なぜこれがあなたにとって重要なのか説明していただけますか?
グレッグ・キング: そうですね、ご質問ありがとうございます。実際、PayPal のような企業に対して私たちが考えられる主な焦点は、セキュリティの強化ソリューションになるでしょう。その一部はイルソン氏のスライドを通じて言及されていたことを私は知っています。しかし、外部でキーを管理できることを考えると、クラウド サービスから独立したセキュリティ制御ができる追加機能が実際に導入されます。そしてそれは、多層防御などのことを考え始めるときに非常に重要です。特に PayPal に関しては、従来はオンプレミス型のサービスでした。そのため、私たちは自分のデータの管理、自分の鍵と暗号化システムの管理について非常に快適に感じています。それに伴い、PayPal が生成した HSM を使用して自分のキーを管理する必要があるなど、特定のポリシーが導入されます。クラウドに移行すると、そのコントロールが失われます。データとキーはクラウド内の共有サービスに依存しています。したがって、外部 HSM は、それを外部から制御できる機能をもたらします。イルソンが先ほど言ったように、キーをオフにしたりオンにしたりすることはできます。キーは完全に制御できます。もう 1 つの利点は、先ほど述べたように、PayPal の制限により、実際に新しいビジネス ユースケースをクラウド環境に移行できるようになるという点です。データの種類に応じて、データ管理の程度やレベルは異なります。また、一部のデータはクラウド型サービスに対応していない可能性があります。しかし、外部のキー マネージャーを使用することで、それらをクラウド環境に導入できる可能性があります。これは PayPal にとって非常に大きなことであり、これまで存在しなかったユースケースが可能になります。
IL-SUNG LEE: わかりました。システムがどのように設定されているかについて少し説明してもらえますか?
グレッグ・キング: ああ、確かに。したがって、EKM を実行するには実際には 2 つのオプションがあります。そのうちの 1 つは非常に複雑になるため、独自の外部 HSM サービスを使用する可能性があります。オンプレミスを使用することも、予算、リソース、制約がある場合は独自の HSM をデプロイすることもできます。もう 1 つのオプションは、Google と提携した HSM サービスのいずれかを使用することです。そして、CMEK を機能させるために必要な相互接続はすでに完了しています。そのうちの 1 つである Fortanix SDKMS をデモします。したがって、私たちが探しているもう 1 つのことは、グローバルな可用性です。そのため、KMS のサービス、外部 KMS を GCP 内の使用するリージョンにローカルにデプロイして、レイテンシを抑えることができます。そして明らかに、可用性に関しては高い制約を設けたいと考えています。以上が主な展開です。
イルソン・リー: わかりました、素晴らしいです。それで、グレッグ、ここで何が起こるのか教えてもらえますか?
GREG KING: Sure, let me get logged in. So I’ve got two slides up, or two web pages. And one of them is going to be the GCP or the Cloud Platform. And what I’ve done is implemented a BigQuery table, a very simple table just for demonstration purposes. And then I have the Fortanix SDKMS GUI, which is where I would control the external keys which I’ve generated. Il-Sung went through the methods and the interconnects for how you would generate those keys, so I won’t repeat that here. But what I do want to show you is when you have the BigQuery set up, and you’re trying to access the data, if you enable and disable those keys, obviously the data will go away. So you’re going to be able to enforce the restrictions on that data external to the cloud service itself, which is really the key point.
So within BigQuery, like I said, I just created a very small sample set. And I’m going to show you one thing real quick before the data is the details. So since this was pre-set-up, I wanted to point out at the bottom, which hopefully that’s visible, you’ll see it is a customer managed key. From this particular point of view, the way it’s developed– you wouldn’t necessarily be able to tell it’s an EKM key. But when you go and implement it the way Il-Sung discussed, it’ll be clear that it is.
I’ve got it labeled as an EKM 002. For me, when I bring up Fortanix, you’ll see the equivalence to the key that’s in there. OK, so to preview the data, you can just see it’s a very simple database structure– nothing elaborate, just enough that you can show the data. Obviously, I’ve brought the data up so that that would relatively make it apparent that the key to unlock the data is available and is usable from the service.
So if I go over to Fortanix, their SDKMS interfaces– and just to give you a quick representation, the key that I brought up before– you’ll see that I’ve got a key developed here with a similar name. They’re not necessarily the same. But for relational purposes, I do have it in there so I know the relationship to the key that’s in CMEK in GCP. So within the service, the application is set up. It is the service account through the external KMS in GCP.
It’s connectivity that Fortanix has implemented into their service to enable this to work. And in this particular service, I’ve got an enable and a disable feature on the side. So I can just hit the switch there. And from this perspective, the key has now been disabled. To make that apparent, you come back over to the key table. And if I try and do a preview, it’s going to give me an error saying the key itself or the data itself can’t be reconstructed because the key is not available.
So if I circle back out, go back to SDKMS with my application and re-enable that feature, come back to BigQuery– and when you preview the table now, the data is back available. So obviously you know that the access to the key is dependent on the external service under the control of PayPal or the customer, whichever customer is going to be using it. And that’s the key feature to the service.
IL-SUNG LEE: That’s great. Well, thank you very much, Greg. That’s a really, really a great demonstration. I think what we’d like to do now is to invite Joseph Valente onto the stage. And he is going to talk a little bit about the access justifications.
[APPLAUSE]
JOSEPH VALENTE: Thanks, Il-Sung. Thanks, everyone, for coming. I’m crunched in the last thing between your end-of-day snacks, so I’ll keep it short. I know that Il-Sung’s just given a very detailed presentation where he’s walked through all of the control that we get from having our keys in an external key manager. And so at this point, you’re probably wondering, what do I actually get from getting key access justifications as well? I already have this tremendous level of control having my keys outside of Google. What benefit does this give me?
And what I’m going to hope to address in this part of the presentation is precisely what that benefit is and how that works. And I’m going to do that by walking through an example of how encryption works within a service that runs on Google Cloud Platform.
So I want you to imagine that just in the demonstration you just saw, you are running a query on BigQuery. But this time, instead of using an externally-managed or customer-managed encryption key, you’re just going to use Google’s default encryption at rest to encrypt your data. So your BigQuery table data is going to be encrypted. And the key is going to live in Google’s internal key management system. And when you run this query. It’s going to fire off a request to that internal key management system saying, hey, please decrypt this table so I can do whatever it is the good customer is asking me to do.
When that decryption event happens, some plain-text data is going to be loaded up by the BigQuery binary. And it’s going to be able to perform your query for you.
So, for example, if your query was, give me all of the sales in Q1 2019, it’s going to go ahead, decrypt all of the rows of data that have the transactions for that quarter, sum them all together, and then return you the result. Now, as you all would know, and as Il-Sung has covered in his presentation, we also have the ability for you to replace those keys with keys that you manage. And those keys are going to live in the customer’s own cloud key management service instance. And what you can do there is have management over the key so that when you delete it, Google can no longer access the data.
Already, I’m sure you’re probably thinking this is getting to a pretty high level of control. I have the keys within the key management service. I can delete them when I no longer want Google to have access. And that access goes away. But there’s a few things that remain. One of those is the BigQuery engineers, or the engineers who are administering or running or developing whatever service it is that you’re using on the cloud. The other thing, of course, is the cloud key management service engineers. So there’s a degree of trust that you need to place in these people. Google already offers industry-leading controls in both these spaces. We have Access Approval and Access Transparency, which very, very heavily lock down what these administrators are able to do. In many cases, actually in BigQuery itself, when you’re using some of these controls, they won’t even have access to the underlying table data. However, there’s still an element of control that’s there. And you will need to obviously read the documentation for these products to understand what their limitations are.
So you want to remove these people from the trust equation as much as you can. Now, when you use the external key manager service, Google’s cloud key management service engineers can no longer access the keys that live inside the external key manager. So that’s a huge leap over what we had previously.
But as you can see, on the left-hand side of this diagram, all of that infrastructure is still Google-managed. And you still have to trust what’s going on there. You have to trust that we’re correctly administering the controls. You have to trust that our administrators have their access locked down. And you also need to trust that the software itself is not doing anything malicious with your data. And so in order to do that, we want to give you visibility into whether or not the requests that are coming to decrypt your data are originating from you, the customer, from the software itself, or from the engineers who are the administrators and developers of that software. And the way in which we’re doing this is by providing you a justification each time we request a decryption from the external key manager.
So let’s walk through some details about what exactly is going to be inside these justifications. So as I mentioned on the previous slide, there are three broad ways in which your data may be decrypted. The first is that you yourself are running some query or some access to your data via the service.
And an example of this is what we saw before. I’m using BigQuery. I’m trying to run a query. And that’s going to need to access my decrypted data in order to work. The second broad category is the decryption events that occur as a result of system operations. Now, from time to time, Google’s systems are going to do certain things.
For example, BigQuery every now and then performs optimizations on your data so that is much quicker to query a BigQuery query than if the optimization hadn’t taken place. That’s obviously what you’re paying for when you get this high speed and performance from using a GCP service. But you want to have visibility into when that’s happening and understand the boundaries of that activity so that you can be comfortable putting your data onto the cloud. And so we’re going to now, for the first time, give you visibility into that with a justification showing where a system operation is taking place. The third and final set is the broad set in green at the bottom of Google administrative activity. You’ll notice, for those of you who are familiar with our Access Transparency product, that these are the exact same justifications that you get with Access Transparency and Access Approval.
And so you may be wondering at this point, isn’t this just the same set of controls? And the answer is yes, it is. We’re building on the same set of controls. We’re bringing those justifications through all the way to the key manager so that you can actually use encryption to enforce your access policies.
And finally, through the functionality provided by our partners and integrators, you can use blocking policy at your external key manager to block these requests. Now, obviously, if you set a policy that says block all customer-initiated access, you’re going to lose access to your own data. So please be aware if you’re planning to do that. That’s probably not a good idea. But if you were to go and, for example, set a policy that said, block all Google administrative access to my data, that would be a valid policy.
You could continue using your BigQuery service or whatever service it is you happen to be running. And while it may be difficult for you to get support, you would still be able to use the service and have that access enforced at the key manager. Now, at this point, you’re probably saying, that’s really nice that I get a justification and that you’ve got all these controls in place. But what confidence do I actually have that all of these things are going to work in practice? And that’s where our integrity commitment comes into play. So Google Cloud is going to give you a commitment to protect the integrity of the controls and the justifications. And you can find out more about this when you’re on-boarded for the product. So, Key Access Justifications– it’s coming very soon to alpha. I can’t say when, but it’s coming soon. So watch this space.
It’ll be available for Google Compute Engine and Persistent Disk, as well as BigQuery. And it covers the transition from data at rest to data in use. Like I said, it’s going to give you that justification when your data is decrypted And it’s going to appear at your external key manager. And you can block it if you don’t want it to happen.
Using External Key Manager and Key Access Justifications together is going to make you the ultimate arbiter of access to your data. And that’s really, really important. Why is that really important? Because no other cloud provider is going to give you this level of control. This is something you can only get from GCP. Some little fine print and details– you can’t turn this on yourself right now. Like I said, it’s not actually available just yet. But even when it is available, you’ll be considered based on a variety of criteria. So we’re just looking for customers who are going to help us make the service successful. Please register your interest.
There’s a link in our blog post if you are interested in using this product. Secondly, do you need to use Google’s External Key Manager Service to get Key Access Justifications? The answer is yes. This is only available if you use the External Key Manager. And then finally, what data is in scope for Key Access Justifications? It’s, generally speaking, the same things that are in scope for both customer-managed encryption key access, as well as External Key Manager product. So it’s the highly sensitive data, things like the underlying table data inside BigQuery.
So let’s do a quick demonstration, and let’s walk through a short video of how this might work when I’m using this in a service on GCP. So I want you to imagine that you’re running a query now on BigQuery similar to what we saw before. And I’m going to click the Run button. And my query went ahead and ran as intended. And now I’m going to jump to my External Key Manager software. And I can clearly see here that a customer-initiated access has taken place and that my External Key Manager access policy allowed that access to happen. I’m going to go ahead and refresh my EKM page. And I can now see that there is a new request that’s come through that was authorized, but I didn’t actually do anything.
When I scroll down, I can see that that was actually a Google-initiated system operation and that my access policy allowed that access to happen. So that’s all good. Now let’s imagine that something goes terribly wrong, and you need to contact Google support. You’ve completely lost access to your storage. Things are coming up completely corrupted. You’re seriously worried. You smash all the red buttons you can smash. And Google goes and calls the engineer who is the most highly privileged person for the service who is on call. And that person pulls up a tool. Just FYI, this is not the actual tool. We can’t show you our internal tools, so this is an animation. And they have to put in a justification. And that justification will show you the ticket number of the request that you open up– excuse me, sorry– ticket number of the request that you open up. And it will be validated automatically by our systems to ensure that that ticket was actually something you as a customer opened and that you want this request to be happening.
Once that’s validated, the access will go ahead and take place. But there’s a catch. In this case, you’ve set your External Key Manager access policy to deny all administrative access. And so when you see this customer-initiated support request come in, it will register as a deny, and the access will be denied to the Google administrator. So no matter how high this person’s privileges are, they won’t be able to do it. But in this case, because you really need support, you probably want to change that. So here, we are seeing us updating our EKM access policy to remove that reason from the blocklist. And we’re going to see the administrator going and trying this again and trying to get that access to go through. So we’re going to send this off, and voila. So it’s now allowed. The access has gone through. And we can see the customer-initiated support justification.
So that’s a quick demonstration of what you’re going to get when we ship Key Access Justifications for GCP. But overall, from today’s presentation, I want to just reinforce a few takeaways. So the first thing is, please look out for the release announcements for External Key Manager beta and Key Access Justifications alpha. Both of those are coming soon. Be on the lookout for a blog post. And let us know if you would like to be on-boarded once the products are released. The second thing is, keep your data in our cloud, not your keys. So you can now finally get this unprecedented level of control when you use External Key Manager to secure your data at rest in GCP.
And then finally, if it’s available to you, you can use Key Access Justifications to make yourself the ultimate arbiter over access to your data and get an incredible amount of granularity over that access by using key access policies to govern why your data can be accessed. So that’s all I have for today. I believe we have some time remaining, and we also have some roving microphones. So if there are any questions, I’d like to invite Il-Sung back on stage, and we can take those from you.
[APPLAUSE]
IL-SUNG LEE: Are there any questions that anyone has?
AUDIENCE: The External Key Manager used a service account to get access to the on-premise solution. Does that mean the person who needs access to the data also needs access to the service account? Or is that kind of just grouped in together?
IL-SUNG LEE: Yeah, so what’s happening is that the external key manager’s authorizing KMS to access that key, right? And so never minding Key Access Justifications. You’re basically authorizing KMS to access it for whatever need that it actually says. So if it needs to do something for offline compaction or fulfill customer requests, then that’s what it is. And then Key Access Justifications gives you that extra level of clarity around when you might want to actually say no to the decryption. But yes, you’re actually authorizing the entire service.
AUDIENCE: So do you need to authorize the customer or the analyst who wants to see the data?
IL-SUNG LEE: I’m sorry, could you speak up a little?
AUDIENCE: Do you need to authorize the analyst who wants to see the data to be able to use the service account as well as being able to see the data?
IL-SUNG LEE: No, no. So you don’t have to actually authorize the data itself because the data– like, for example, in our examples, it was BigQuery. BigQuery’s already authorized KMS to access the data. Or KMS has authorized BigQuery to use a key to do the encryption/decryption. And then the EKM is authorizing KMS to actually authorize outside keys. So it’s a chain of permissions that happen.
聴衆：ありがとうございます。
イルソン・リー: どういたしまして。素晴らしい質問でした。
聴衆：はい、こんにちは。私の質問は[INAUDIBLE]信頼に関するものです。私の理解では、マスターキーを使用してデータキーを復号化するように外部パートナーに依頼するからです。ただし、暗号化の開始時にデータキーを使用して暗号化します。実際、顧客として、データキーがまだお客様側で利用できないことをどうやって信頼できるのでしょうか?
IL-SUNG LEE: それは本当に、本当に良い指摘ですね。つまり、すべてのデータ暗号化キーは私たちが管理しているため、システムに対する信頼レベルを維持する必要があります。そして、私たちが実行している規模では、これらすべてが透過的であるという事実から、エンベロープタイプの暗号化システムを実行する必要があるため、そうする必要があります。したがって、この種のことは、Google が不適切なことは一切行っていないという Google の取り組みに関してジョセフが述べたことに遡ります。そして、システムが機能する方法は、私たちがシステムが機能すると公言している方法ですよね?そして、あなたは完全に正しいです。ここのステージで声を大にして言えるのは、私たち KMS やキー管理システムでは、実際にはキーをキャッシュしていないということです。ストレージ サービスは、たとえば BigQuery のように、少し異なる動作をする場合があります。デフォルトでは、基本的に結果セットをキャッシュします。同じクエリを何度も実行すると、結果セットがキャッシュされます。そのキャッシュをオフにすることができます。あるいは、結果セットを暗号化することもできます。その場合、クエリを実行するたびに、外部に出て外部キーにアクセスする必要があります。 GCE は、実際に VM の起動時に永続ディスクを実際に復号化するためのキーのみを必要とするため、少し異なります。 VM が実行されると、そのインスタンス キーがメモリ内に保持されるため、永続ディスクへの高速な読み取りと書き込みが可能になります。その VM がダウンし、再起動したい場合は、再び外部キーにアクセスする必要があります。したがって、ストレージ システムが異なれば、キーに対して異なる処理を行う可能性があります。ただし、KMS 側または EKM 側では、これらのキーは実際にはキャッシュされません。ありがとう。後ろに1人います。
聴衆：こんにちは。 Google が自分のキーの管理者であることを信頼できない場合、なぜ他のクラウド ベンダーを信頼する必要があるでしょうか?そして、もし私が Google を信頼していないのなら、なぜあなたが自分の正当性について正直に語ると信じられるのでしょうか?
イルソン・リー: 素晴らしい質問ですね。つまり、多くの人にとって、責任を分割することには価値があるということですね。したがって、システムを破壊するために 2 つの独立した関係者が協力する必要があることは、1 つのシステムだけを信頼することとは大きく異なります。それが一番です。 2 番目は、5 つのパートナーをリストアップしたことです。中にはクラウド サービスを提供しているところもありますが、基本的にはクラウド キー管理サービスを提供していますよね。したがって、当然ながら、彼らのシステムを信頼する必要があります。他のパートナーの中には、実際には、自社の施設内で実行できるインフラストラクチャなどを購入するオンプレミス タイプのソリューションを多く出荷しているところもあります。そして、この外部キー管理のストーリー全体をさらに進めていくにつれて、そのシナリオの実現がますます容易になっていきます。ただし、一部のソリューションを実際に使用してインフラストラクチャを購入し、それを独自の物理的に保護された境界内に配置し、そのインターフェイスを EKM と使用できる場合は可能です。
聴衆: はい、申し訳ありませんが、フォローアップのためですが、2 番目の部分 – あなたを信頼していないのに、なぜあなたが自分の正当性について常に正直であると信じなければなりませんか?
ジョセフ・ヴァレンテ: はい、その点では、ここでの主な違いは、私たちがあなたにコミットメントを与えているということだと思います。したがって、私たちは実際に、コントロールを回避するつもりはない、と率直に言いたいのです。正当な理由が真実であることを確認します。そしてそれが私たちがステージ上で表明している約束です。そしてそれを持ち帰ることもできます。そして明らかに、あなたがまだ Google を信頼しておらず、本当に本当に Google を信頼していない場合は、その時点から私たちにできることは何もありません。しかし、私たちからのコミットメントが本当にあるという点で、これは非常に大きな前進だと思います。
IL-SUNG LEE: そうですね、明らかにしていただきたいのは、私たちは皆さんからの信頼を決して取り除くことができないように努めているということです。しかし、私たちは、あなたが私たちに対して抱いている信頼の大きさを、より快適なレベルにしたいと考えています。そして、これに伴ってさらに快適になるように私たちは努めています。しかし、確かに、最終的には平文データをクラウドにアップロードすることになります。しかし、私たちは、それやいつアクセスできるかなどを制御できるように、追加の制御を提供しようとしています。はい、そこに質問があります。
聴衆: ねえ、それでは、キーリクエストのようなビッグデータへの同時リクエストがある場合、それぞれが行ってキーをリクエストすることになりますか、それともキーを一度フェッチしてすべてのリクエストに使用しようとした場合などですか?
イルソン・リー：ちょっと複雑ですね。ほとんどの人は、BigQuery に異なるデータセットがある場合、職務を最大限に分離したい場合は、別のキーを使用するでしょう。したがって、1 つのデータ セットで 1 つのキーを使用できます。別のデータ セットは他のキーを使用できます。つまり、それらはすべて同じ外部ソリューションでホストできます。でもそういう場合は独立しているんですよね？したがって、そのキーはその 1 つのクエリの存続期間中のみ存続します。そして、このキーは、その 1 つのクエリの存続期間中のみ存続します。両方が同じキーを使用している場合、それはクエリがどのように重複するかによって決まります。したがって、それらがまったく重複していない場合は、明らかに、一方のクエリが終了すると、もう一方のキーは消えます。もう 1 つのケースでは、どちらの場合でも、キーが不要になるとすぐにキーが消えてしまいますよね。ただし、この例ではキーの実際のキャッシュはありません。基本的には、必要な限りプロセスが継続されます。そしてその後、実際にパージされます。
イルソン・リー：ちょっと複雑ですね。ほとんどの人は、BigQuery に異なるデータセットがある場合、職務を最大限に分離したい場合は、別のキーを使用するでしょう。したがって、1 つのデータ セットで 1 つのキーを使用できます。別のデータ セットは他のキーを使用できます。つまり、それらはすべて同じ外部ソリューションでホストできます。でもそういう場合は独立しているんですよね？したがって、そのキーはその 1 つのクエリの存続期間中のみ存続します。そして、このキーは、その 1 つのクエリの存続期間中のみ存続します。両方が同じキーを使用している場合、それはクエリがどのように重複するかによって決まります。したがって、それらがまったく重複していない場合は、明らかに、一方のクエリが終了すると、もう一方のキーは消えます。もう 1 つのケースでは、どちらの場合でも、キーが不要になるとすぐにキーが消えてしまいますよね。ただし、この例ではキーの実際のキャッシュはありません。基本的には、必要な限りプロセスが継続されます。そしてその後、実際にパージされます。
IL-SUNG LEE: そうですね、それは別のリクエストであるべきだと私は考えています。しかし、基盤となる BigQuery システムがどのように動作するかについてさらに詳細がわかってきたので、確認する必要があります。だから、後で来て話してくれたらもっと気が楽になるのに。情報交換はしますが、必ず確認します。
聴衆：ありがとうございます。
イルソン・リー: そうですね。他に何か質問はありますか?ああ、もう一つあります。
聴衆：こんにちは。 BigQuery データの暗号化について少しお話しました。しかし、少し前、数か月前、私たちがワークフローの一部をテストしていたとき、私たちのセットアップはデータが暗号化されていない侵害や状況をカバーしていました。たとえば、ハッシュ テーブルが暗号化されていないことが判明しました。現在はどのように見えますか？
イルソン・リー: 聞こえましたか?
聴衆: キャッシュです。
JOSEPH VALENTE: 申し訳ありませんが、BigQuery をどこで使用しているかについて話したときの最後の部分だけ繰り返してもらえますか。ごめん。
聴衆: BigQuery によって作成されるハッシュ テーブル、つまりハッシュの暗号化が現在どのようになっているのかを尋ねています。
IL-SUNG LEE: ああ、ハッシュ テーブルですね。正直に言うと、それについてはわかりません。つまり、基本的に私たちが説明しようとしているのは、BigQuery がディスクからデータを読み取る必要があるときは必ず、データが私たちに来る必要があるということですよね?したがって、ハッシュ テーブルがメモリ自体の中でどのように表現されるのかはわかりません。すでにメモリ内にある場合は、私たちのところに来る必要はありません。ただし、重要なことは、データが保存データから使用データに変換されるたびに、外部キーの使用が必要になるということです。
聴衆: 問題は、この種のデータが 24 時間持続する可能性があることです。
IL-SUNG LEE: キャッシュ – キャッシュの結果セットのことを言っているのですか?ああなるほど。そうですね。その場合、BigQuery 側ではその特定のクエリの結果セットがすでにキャッシュされており、その時点では私たちとは何の関係もないため、私たちに連絡する必要はありません。そのデータを保存状態から使用状態に移動する必要はもうありません。したがって、実際に外部のキー マネージャーにアクセスすることなく、実際にアクセスしてクエリを実行できるようになります。
聴衆: わかりました。ありがとう。
IL-SUNG LEE: それで、私が先ほど、潜在的にいくつかのことができると言ったのはそのためです。キャッシュされた結果をオフにすることができます。または、結果セットを暗号化する場合は、実際にクエリを実行するたびに外部キー マネージャーを呼び出す必要があります。したがって、できることはこの 2 つです。良い質問。他に何かお手伝いできることはありますか? 1回、2回行っても大丈夫です。皆さん、本当にありがとうございました。
ジョセフ・ヴァレンテ: 皆さん、ありがとう。
