AWS、Azure、GCP における顧客管理暗号化キー (CMK) の比較と理解比較と理解

セキュリティの設定ミスを回避し、データを効果的に保護するために、AWS、Azure、GCP で顧客管理暗号化キー (CMK) を扱う場合の重要な違いについてご紹介します。

Tenable の存在意義

顧客管理暗号化キー (CMK) は、顧客が作成して管理し、所有している暗号化キーです。 このキーによって、顧客はアクセス管理を制御できます。つまり、誰が (何が) アクセスできて、どのようなアクションを行えるかを決定できるのです。

CMK は、クラウドサービスプロバイダーがキーのライフサイクルとアクセス権限を管理する、プロバイダー管理キーとは異なります。 

CMK は、AWS、Azure、GCP などのさまざまなクラウドサービスプロバイダーで利用可能です。 

AWS において CMK による暗号化と復号化に適用されるパラダイムは、Azure および GCP で適用されるパラダイムとは大きく異なります。 セキュリティ担当者が状況を認識していない場合、この違いが理解できていないことにより、何らかの悪影響が出るおそれがあります。このブログではこの違いと、区別がなぜ重要であるのかについて掘り下げて考えていきます。

AWS での CMK の使用

AWS では、CMK は AWS Key Management Service (KMS) で利用できます。 

S3 バケットのようなデータリソースが CMK を使用して暗号化される場合、 (例えば S3 リクエストを通じた) データへのアクセスには復号化プロセスが含まれます。 AWS KMS のアクションは、データアクセスのリクエストを開始したアイデンティティの認証情報を使用して行われます。 こちらから、この仕組みと aws:CalledVia 条件キーについての詳しい情報をご覧いただけます。 以前の投稿でも、この条件キーや、その他の知っておくべき重要なキーについて当社独自の解説を行っています。

なぜこの運用方法が重要であるかというと、データへのアクセスの管理に影響を与えるからです。

AWS では、プリンシパルにデータを取得するためのアクセス権限を付与した場合でも (例えばバケット内のオブジェクトへのアクセスのために S3 へのアクセス権限を与えるなど) 、そのプリンシパルが復号を許可されていない CMK でオブジェクトが暗号化されている場合、プリンシパルは依然として Access Denied (アクセス拒否) のエラーメッセージを受け取ります。 これは、プリンシパルの認証情報が復号プロセスに使用されるため、そのプリンシパルが復号に必要な権限を持っていることが求められるからです。

この二重の要求によって暗号化データへのアクセスに両方の権限が必要となるため、セキュリティにさらなる層が追加されます。

AWS のマネージドポリシーは、大抵はとてもぎこちない方法で使用される一方で、非常に幅広く使用されています。したがって、これは非常に重要です、例えば、非常に限られたバケットのみへのアクセス権限を必要としている場合であっても、プリンシパルは AmazonS3FullAccess を付与される場合があります。 あるいは、ユーザー管理の IAM ポリシーであっても、適切な場所 (見方によっては不適切な場所) に「*」を配置することで簡単に設定でき、これによってプリンシパルはアカウント内のすべてのバケットにアクセスできるようになります。 

機密データを持つバケットが CMK で暗号化されたものである場合、プリンシパルは、アカウント内のすべてのバケットから情報を取得するアクセス権限を持っていたとしても、そのキーを使用してkms:Decrypt を実行するために明確なアクセス権限を要求されます。 これによって、意図しないデータアクセスを大幅に減らすことができます。 

Azure と GCP での CMK の使用 

Azure と GCP のストレージソリューション (それぞれストレージアカウント、Cloud Storage バケット) を使用する場合には、状況が大幅に異なります。復号操作の実行に使用されるプリンシパルが、データアクセスの要求を開始するプリンシパルではないためです。これについて詳しく見ていきます。 

 AWS の使用経験があって Azure や GCP をこれから使い始める場合には (よくあることです)、先に述べた点を認識しておくことが大切です。なぜなら、AWS と同様に、データにアクセスするためには CMK を使用する権限を持っている必要があると思い込んでいるかもしれないからです。

この思い込みのせいで、機密性の高い Azure ストレージアカウントや GCP の Cloud Storage バケットは、プリンシパルが CMK へのアクセス許可を持っていない限り、サブリクション内またはプロジェクト内のすべてのストレージデータへのアクセス権限を付与されたロールを持つプリンシパルから保護されているのだと信じてしまうかもしれません。 しかし、現実は異なっています。

データにアクセスするプリンシパルが要求を開始するプリンシパルと異なっており (これについては後で説明します)、アクセスするプリンシパルはバケットへのアクセス許可を別個に付与されるため、要求を開始するプリンシパルは CMK を使用する権限を必要としません。

Azure での CMK の使用

Azure での CMK は、Key Vault で作成されます。 

CMK を使用してストレージアカウントを暗号化するためには、まず、マネージド ID を作成する必要があります。 その後、マネージド ID はストレージアカウントに関連づけられ、CMK を使用して暗号化と復号化のアクションを実行するために使用されるプリンシパルになります。

注意していただきたいのは、以下の個別のユースケースで CMK を使用できるようにするためには、Key Vault で消去保護を有効にする必要があったことです。

私たちは、ストレージアカウントを作成しようとしたときにこのエラーメッセージが表示されたことにより、正しく「偶然に」この要件を発見できました。

Azure のドキュメントでは次のように説明されています。「ストレージアカウントに関連づけられたマネージド ID は、Azure Key Vault 内の顧客管理キーにアクセスするために、少なくとも wrapkey、unwrapkey、get の権限を付与されている必要があります」 

そのため、以下の権限を与えられたカスタムロールを作成する必要があります。 

次に、そのロールを使用してマネージド ID へのロールの割り当てを作成します。

次に、ストレージアカウントを設定する際に、暗号化に使用したい Key Vault 内の CMK と、暗号化と復号化のためにストレージアカウントに関連づけるマネージド ID を選択します。

GCP での CMK の使用

GCP の場合も Azure と同様の仕組みですが、わずかに異なっています。 

暗号化と復号化を実行するプリンシパルは、Cloud Storage サービスエージェントです。Cloud Storage サービスエージェントのメールアドレスは、Cloud Storage の [設定] ページで探すことができます。 

その結果、こちらで説明されているように、バケットの暗号化で使用するキーに関する「クラウド KMS 暗号鍵の暗号化 / 復号化」のロールを Cloud Storage サービスエージェントに割り当てることができます。

だいたいこのような手順です。 これで Cloud Storage のサービスエージェントは、CMK によってコンテンツの暗号化と復号化を実行するためにキーを使用できるようになりました。

セキュリティ上の意義

この記事で説明した暗号化に関する権限のパラダイムの違いは、AWS の権限管理のアプローチと、Azure および GCP が採用する RBAC (ロールベースのアクセス制御) との違いに対応しています。 AWS のアプローチの方が、管理は複雑かもしれませんが、アクセス権限に関しては、より多くの制御メカニズムを提供しています。 

これは、このアプローチがセキュリティ上の利点にも欠点にもなり得るという好例でもあります。 

暗号化されたリソースにアクセス権限を付与する場合には、Azure と GCP のアプローチのほうが、オブジェクト自体に権限を付与するだけで十分であるため管理は容易です。 また、それぞれのプリンシパルの暗号化された資産に対する権限の管理など、考慮するべきこともより少なくなります。 チームがデータアクセスのコンパートメント化をより容易に行えるようになるため、この簡潔さはセキュリティの面では好ましいものです。 

さらに、キーに対する権限の管理が複雑であると、攻撃者がキーを操作し、乗っ取って、効果的なランサムウェア攻撃を行えるようになるというシナリオが意図せずに生じてしまう可能性もあります。 

一方で、CMK を使用して、KMS キーへのアクセス権限を要求するセキュリティ境界を確立することはできません。 データアクセス権限が誤って付与された場合 (このようなことは必ず起こります)、暗号化でそれを防止することはできません。 

このような比較では勝ち負けに注目しがちですが、この場合は、はっきりと勝敗を決めることは非常に困難です。 しかし、明らかなことが 1 つあります。2 つのアプローチの違いと、それぞれの長所と短所を理解しておくことが「キー」となるのです (洒落を言っているわけではありませんよ)。 

まとめ

データ保護とアクセス管理は、クラウド環境のセキュリティに不可欠な基盤であり、さまざまなコンプライアンス基準に準拠するためにも欠かせません。 

Azure や GCP で暗号化を始める場合は、AWS 担当者としての経験が豊富であろうとなかろうと、この記事で説明した違いを覚えておく必要があります。 サブスクリプションやプロジェクト内のプリンシパルに付与するデータアクセス権限には細心の注意が必要です。 

通常と同様に、最小権限の原則に基づき、プリンシパルには職務に必要な権限のみを、望ましくはカスタムロールを使用して適切な範囲に限り、付与するようにします。 可能であれば、リソースレベルの権限のみを付与するべきです。 

もっと詳しく知りたい場合は、当社のクラウドセキュリティのページをご覧になるか、当社までご連絡ください。