このページでは、Cloud Storage XML API に対するリクエストの認証に使用できる、ハッシュベースのメッセージ認証コード（HMAC）キーについて説明します。HMAC キーを使用すると、既存のコードを再利用して Cloud Storage にアクセスできるため、他のクラウド ストレージ プロバイダと Cloud Storage の間でデータを移動する場合に便利です。
概要
HMAC キーは、アカウント（通常はサービス アカウント）に関連付けられた認証情報の一種です。HMAC キーを使用し、HMAC-SHA256 署名アルゴリズムを使用して署名を作成します。作成した署名は、Cloud Storage XML API に対するリクエストに含まれます。署名は、指定されたリクエストが HMAC キーに関連付けられているアカウントによって承認されていることを示します。
HMAC キーはアクセス ID とシークレットの 2 つで構成されます。
アクセス ID: 特定のアカウントに関連付けられた英数字の文字列。
サービス アカウントに関連付けられている場合、この文字列の長さは 61 文字です。
ユーザー アカウントに関連付けられている場合、この文字列の長さは 24 文字です。
アクセス ID の例を次に示します。
GOOGTS7C7FUP3AIRVJTE2BCDKINBTES3HC2GY5CBFJDCQ2SYHV6A6XXVTJFSAシークレット: 40 文字からなる Base-64 でエンコードされた文字列で、特定のアクセス ID に関連付けられています。シークレットは、自分と Cloud Storage だけが知っている事前共有キーです。シークレットを使用して、認証プロセスの一環として署名を作成します。シークレットの例は次のとおりです。
bGoa+V7g/yqDXvKRqq+JTFn4uQZbPiQJo4pf9RzJ
アクセス ID とシークレットの両方が HMAC キーを一意に識別しますが、署名の作成に使用されるため、シークレットのほうが遥かに機密性が高くなります。
リソースに対して restrictAuthTypes 制約を有効にして、HMAC キーで署名されたリクエストのアクセスを制限することもできます。
シークレットの保管
サービス アカウントに HMAC キーを作成すると、そのキーのシークレットが一度だけ提供されます。シークレットはそれに関連付けられているアクセス ID と一緒に安全に保管する必要があります。シークレットを紛失した場合、Google Cloud もそれを回収することはできません。したがって、リクエストの認証を続けるには、サービス アカウントの新しい HMAC キーを作成しなければなりません。
ユーザー アカウントの HMAC キーを作成するには、ユーザー アカウントを使用して Google Cloud コンソールにログインします。resourcemanager.projects.get IAM 権限を持つプロジェクトを選択して Cloud Storage の [設定] に移動し、[相互運用性] タブを選択します。作成したキーのシークレットは、resourcemanager.projects.get 権限のあるプロジェクトの [相互運用性] タブで確認できます。
シークレットを保管するためのベスト プラクティス
HMAC キー シークレットを共有しないでください。HMAC キー シークレットは、アクセス認証情報と同様に扱う必要があります。
セキュリティ保護のため、キーのローテーションの一環として定期的にキーを保存する必要があります。
他の人が自分の HMAC キーを使用していると思われる場合は、当該の HMAC キーを直ちに削除して新しいキーを作成してください。
HMAC キーを変更する場合は、新しい HMAC キーでコードを更新してから、古いキーを削除してください。削除された HMAC キーはすぐに無効になり、復元できません。
制限事項
HMAC キーを使用できるのは、JSON API ではなく XML API に対してリクエストを送信する場合のみです。
サービス アカウントごとに設定できる HMAC キーは最大 10 つです。削除されたキーはこの上限にカウントされません。
作成後、サービス アカウントの HMAC キーが使用可能になるまでに最大で 30 秒かかります。サービス アカウントを削除した後、それに属する HMAC キーは引き続き最大 5 分間機能します。逆に、HMAC キーを所有するサービス アカウントの削除を取り消すと、HMAC キーが再び使用可能になるまでに最大で 5 分かかることがあります。
リソースに
restrictAuthTypes制約を有効にすると、そのリソース内の指定されたアカウント タイプに HMAC キーを作成または有効化できなくなります。
ユーザー アカウントの HMAC キーからの移行
通常は、ユーザー アカウントではなくサービス アカウントに HMAC キーを関連付けることをおすすめします。特に本番ワークロードでは、このオプションを使用してください。
サービス アカウントを使用したほうが、管理上の監視が強化されます。また、個々のユーザーが保持するアカウントのセキュリティとプライバシーに対する影響もありません。
サービス アカウントを使用すれば、ユーザー アカウントへの依存に伴うサービス停止（たとえば、ユーザーがプロジェクトから抜けたり退社したりして、そのユーザー アカウントが無効になった場合）のリスクを軽減します。
現在ユーザー アカウントに関連付けられている HMAC キーを使用していて、サービス アカウントに移行する場合は、次の点に注意してください。
プロジェクトにサービス アカウントが設定されていて、そのサービス アカウントに HMAC キーが関連付けられている必要があります。
そのサービス アカウントには、Cloud Storage でアクションを実行するために必要な権限が付与されている必要があります。
Storage Object Admin役割にはオブジェクトを操作するための包括的な権限が含まれていますが、実行するアクションごとに別々のサービス アカウントを使用することをおすすめします。たとえば、読み取りに使用するサービス アカウントにはStorage Object Viewerの役割を付与し、書き込みに使用する別のサービス アカウントにはStorage Object Creatorの役割を付与することができます。サービス アカウントをテストして正常に動作することを確認してから、更新を本番環境に push してください。
本番環境の処理がサービス アカウントの HMAC キーに移行したら、次の Cloud Monitoring 指標を調べて、ユーザー アカウントに関連付けられた HMAC キーが使用されなくなっていることを確認します。
指標 説明 storage.googleapis.com/authn/authentication_countリクエストの認証に HMAC キーが使用された回数。 次のラベルを設定して、移行中にまだ使用されているユーザー アカウント キーを追跡できます。
access_id: リクエストを行ったアクセス ID を示します。鍵のローテーション中にaccess_idを使用して、鍵間のトラフィックの移動を見ることもできます。authentication_method: キーがユーザー アカウント キーかサービス アカウント キーかを示します。
ユーザー アカウントの HMAC キーが使用されなくなっていることを確認したら、それらの HMAC キーを削除してください。これにより、不適切なデータアクセスのリスクが軽減されます。
ユーザー アカウントが Cloud Storage リソースへのアクセスに使用されなくなった場合は、そのアカウントに付与された Cloud Storage へのアクセス権を取り消します。
必要であれば、ユーザー アカウントの HMAC キーに
restrictAuthTypes制約を有効にして、セキュリティをさらに強化することもできます。