Google Cloud Platform へのアクセス権の取り消し

このドキュメントでは、Google Cloud Platform プロジェクトへのユーザーのアクセス権を取り消すためのベスト プラクティスについて説明します。このドキュメントには 2 つのセクションがあります。1 つ目のセクションでは、アクセス権の取り消しを容易にするようにプロジェクトを設定する方法について説明しています。2 つ目のセクションでは、さまざまなタイプのリソースへのユーザーのアクセス権を取り消すための段階的な手順について説明しています。

背景

Google Cloud Platform リソースにとって重要なのは、他のユーザーのアクセス権を削除する必要がある場合です。従業員が会社を辞めたり、請負業者との契約が終了したり、共同作業者が他のプロジェクトに移ったりする場合、いくつかの作業を行ってリソースへの不要なアクセス権を完全に取り消す必要があります。

これらのプロセスの一部はオプションです。セキュリティ上のニーズ、使用中のプロダクト、アクセス権が取り消されるユーザーの信用に応じて、これらのステップのいずれを実行するかを決定する必要があります。このドキュメントを使用して、自分のニーズに合う、GCP の使用に関するポリシーと手順を作成してください。

プロジェクトを設定する

設定時に慎重に選択することで、プロジェクトでユーザーのアクセス権を取り消す際の効率性、安全性が向上します。

VM へのアクセスを制限する

Google Compute EngineGoogle Kubernetes EngineApp Engine フレキシブル環境で使用されるような仮想マシン(VM)は、攻撃にさらされる可能性が高くなります。いずれかのユーザーが VM へのアクセス権、特にルートアクセス権または管理者アクセス権を持っている場合、VM に変更を加えないように保証することは非常に難しく、以後アクセスできるようなバックドアが残ってしまいます。VM にアクセスできるユーザーを、明確かつ具体的な必要性のあるユーザーに限定してください。デフォルトでは、プロジェクトの編集者と所有者は、プロジェクト内のすべての VM に対して管理アクセス権を持っています。

個々のユーザーにログイン アクセス権を付与する前に、ユーザーが必要とするアクションを考慮し、可能であればそのニーズを満たせる他の方法を見つけるようにします。コードをデプロイするためにすべてのデベロッパーに毎回ログイン アクセス権を付与する代わりに、ChefPuppetSalt のようなツールを使用してデプロイを管理することを検討してください。

認証情報のローテーションの準備をする

プロジェクト レベルの認証情報を簡単かつ中断することなくでローテーションできるようにプロジェクトとリソースを設計する必要があります。これらの認証情報は、サービス アカウントキー、OAuth クライアント シークレット、データベース ルート パスワードなどのアプリケーション固有のシークレットなど、プロジェクト自体に関連するシークレットです。今すぐ計画し、新しい認証情報を必要とするすべてのアプリケーションに簡単にデプロイできるようにしてください。

API キーを制限する

API キーを作成して管理する際に、それらを使用できるウェブサイト、IP アドレス、アプリのセットを制限します。API キーは、すべてのプロジェクト メンバーに表示されるため、アクセスへの課金を取り消すために、制限なしのキーはすべてローテーションするか削除する必要があります。詳細については、API キーを安全に使用するためのベスト プラクティスを読み、使用方法を適宜計画してください。

アクセス権を取り消す

プロジェクトの設定段階でうまく選択することで、それ以降のプロセスにおいて、ユーザーのアクセス権を効率的かつ安全な方法で取り消すことができます。

プロジェクト メンバーシップからアカウントを削除する

  1. Google Cloud Platform Console で、IAM 権限ページに移動します。

    IAM 権限

  2. アカウントを削除するプロジェクトを選択します。

  3. メンバーリストから、削除するアカウントを含む行の横にあるチェックボックスをクリックし、[削除] をクリックします。または、削除するアカウントの横にあるごみ箱のアイコンをクリックします。

プロジェクト認証情報をローテーションする

サービス アカウント キー

サービス アカウントは特別なタイプの Google アカウントで、Google API のデータにアクセスして認証を受ける必要がある人間以外のユーザーを表します。

プロジェクト オーナーのみが、新しいサービス アカウントや、既存のサービス アカウントのキーを作成できます。アクセスが取り消されるユーザーがプロジェクト オーナーである場合、既存のサービス アカウント キーをすべてローテーションする必要があります。そのユーザーがプロジェクト オーナーでない場合は、この手順はスキップできます。ただし、ソースコード レポジトリやアプリケーション構成など、セキュアな Google Cloud Platform ツール以外のいずれかの場所からサービス アカウント キーにアクセスできるユーザーがいるかどうかを考慮してください。

  1. Google Cloud Platform Console で、API 認証情報ページに移動します。

    API 認証情報

  2. [認証情報を作成] をクリックして、[サービス アカウント キー] を選択します。

  3. [サービス アカウント] メニューから対象のアカウントを選択します。

  4. 作成する [キータイプ] を選択します。ほとんどの状況では、JSON が推奨されますが、キータイプに依存するコードとの下位互換性のために P12 も使用できます。

  5. [作成] をクリックします。新しいキーを含むファイルがブラウザから自動的にダウンロードされます。このキーを必要とするアプリケーションにキーをデプロイします。

  6. 新しいキーが正常に動作することを確認したら、認証情報ページに戻り、そのサービス アカウントに関連付けられている古いキーを削除します。

OAuth クライアント ID のシークレット

OAuth クライアント ID のシークレットからは、プロジェクトに直接アクセスできません。ただし、攻撃者は、アプリケーションのユーザーの代わりに Google から提供された OAuth 更新トークンを盗んで、クライアント ID のシークレットを保持することで、アプリケーションがもともと要求したのと同じスコープ内でユーザーの Google アカウントにアクセスできます。

プロジェクト オーナーと編集者はすべて、OAuth クライアント ID のシークレットを閲覧できますが、読み取り権限では閲覧できません。アクセス権を取り消しているユーザーがオーナーまたは編集者でない場合は、この手順はスキップできます。ただし、ソースコード レポジトリやアプリケーション構成など、セキュアな Google Cloud Platform ツール以外のいずれかの場所からクライアント ID シークレットにアクセスできるユーザーがいるかどうかを考慮してください。

  1. Google Cloud Platform Console で、API 認証情報ページに移動します。

    API 認証情報

  2. 変更する OAuth 2.0 クライアント ID の名前をクリックします。選択した ID の詳細を表示する [クライアント ID] ページが開きます。

  3. [クライアント ID] ページで [シークレットをリセット] をクリックします。

  4. 確認ダイアログで [リセット] をクリックすると、古いシークレットをすぐに取り消して新しいシークレットを設定できます。アクティブ ユーザーは、次回のリクエスト時に再認証する必要があります。

  5. 新しいシークレットを必要とするすべてのアプリケーションに新しいシークレットをデプロイします。

API キー

API キーは、プロジェクトやユーザーのデータに対するアクセスを提供しませんが、Google による API リクエストの課金対象を管理します。すべてのプロジェクト メンバーが、プロジェクトの API キーを閲覧できます。制限なしのキーがある場合は、いずれかのユーザーのプロジェクトへのアクセス権を取り消す際、キーを削除または再生成する必要があります。

  1. Google Cloud Platform Console で、API 認証情報ページに移動します。

    API 認証情報

  2. [認証情報を作成] をクリックし、[API キー] を選択します。

  3. 新しく作成されたキーがダイアログに表示されます。置き換えるキーを使用して、このキーを任意のアプリケーションにデプロイします。

  4. アプリケーションが新しいキーで正常に動作することを確認したら、認証情報ページに戻り、古い制限なしのキーを削除します。

VM へのアクセス権を取り消す

アクセス権を取り消しているユーザーがプロジェクト VM へのログイン アクセス権を持っていない場合は、この手順は省略できます。

  1. そのユーザーがアクセス権を持つすべてのプロジェクト レベルの SSH 認証鍵を削除します。

  2. そのユーザーが SSH アクセス権を持つ VM ごとに、すべてのインスタンスレベルのキーを削除します。

  3. ログイン アクセス権を持つすべての VM からそのユーザー アカウントを削除します。

  4. ユーザーが VM にバックドアからアクセスできるようにインストールした可能性のある疑わしいアプリケーションがないかどうか調べます。VM 上で実行されているコードのセキュリティが不明な場合は、再作成し、必要なアプリケーションをソースから再デプロイします。

  5. VM ファイアウォールの設定が、計画された構成または予期された構成から変更されていないことを確認します。

  6. カスタムベース イメージから新しい VM を作成する場合、新しい VM のセキュリティを損なうような変更がベースイメージに対して行われていないことを確認します。

Cloud SQL データベースへのアクセス権を取り消す

プロジェクトで Cloud SQL リソースが使用されていない場合は、この手順は省略できます。

  1. Google Cloud Platform Console で、SQL インスタンスのページに移動します。

    SQL インスタンス

  2. アクセスを取り消すデータベースのインスタンス ID をクリックします。

  3. [アクセス制御] をクリックします。このタブで、[承認済みネットワーク] の IP アドレスと [App Engine の承認] の下にあるアプリのリストが予想どおりの内容であることを確認します。アクセス権を取り消しているユーザーがここにリストされているネットワークまたはアプリケーションにアクセスできる場合は、それらのユーザーはこのデータベースにアクセスできます。

  4. [ユーザー] をクリックします。このタブでは、ユーザーがアクセス権を持つアカウントのパスワードを削除または変更します。これらのユーザー アカウントに依存するアプリケーションは、必ず更新してください。

App Engine を再デプロイする

App Engine アプリは、関連付けられたプロジェクトのエディタであるサービス アカウントにデフォルトでアクセスできます。App Engine のリクエスト ハンドラは、新しい VM の作成、Cloud Storage のデータの読み取りや変更などの操作を行うことができます。App Engine にコードをデプロイできるユーザーは、このサービス アカウントを使用してプロジェクトにバックドアを開くことができます。デプロイ済みのアプリのコードの整合性が気になる場合は、バージョン管理システムから既知の良好なチェックアウトを使用して、モジュールを含むアプリを再デプロイできます。

他のリソースに対する権限を確認する

ユーザーがアクセスしている可能性のあるプロジェクト内の他のリソースについて検討し、それらのオブジェクトの権限が安全であることを確認します。確認するリソースは次のとおりです。

次のステップ

Google Cloud のセキュリティの概要を読む。