このドキュメントでは、Linux 仮想マシン（VM）インスタンスへの SSH ログイン アクセスを制御する際のベスト プラクティスについて説明します。
VM インスタンスへの SSH アクセスを効果的に管理するには、ユーザーがアクセスを必要とするときにアクセスを許可し、アクセスが不要になったときにそのアクセスを取り消す必要があります。アクセス権を取り消すプロセスが信頼できない場合や、すべてのリソースが対象とならない場合は、アクセス権を取り消す必要があった後も、不正な行為者がアクセス権を保持できる可能性があります。
以降のセクションでは、アクセス権の有効な取り消しを確実に行い、持続型の脅威から保護するためのベスト プラクティスについて説明します。
- OS Login を使用して、IAM ポリシーに対する継続的なアクセス評価を行う
- 組織のポリシーを使用して OS Login の一貫した使用を適用する
- VM ごとに特権ロールを付与する
- ユーザーが組織を退職したときにユーザー アカウントを停止する
- 特権サービス アカウントが設定されている VM に SSH アクセス権を付与しない
- POSIX プロファイルを事前に作成して、ユーザー名と UID の一貫性を維持する
- root 権限の使用を制限する
このドキュメントでは、Google Cloud に固有のプラクティス、または Google Cloud で SSH を使用する場合に特に関連性の高いプラクティスに焦点を当てて説明します。このドキュメントでは、特定の SSH クライアントまたはサーバーの実装に関するベスト プラクティスについては説明しません。
OS Login を使用して、IAM ポリシーに対する継続的なアクセス評価を行う
Compute Engine の公開 Linux イメージは、SSH 公開鍵認証を許可するように構成されています。ユーザーの公開鍵を承認し、SSH セッションを確立する権限を付与するには、次のいずれかのメカニズムを使用します。
メタデータ ベースの鍵認証: 管理者は、ユーザーの公開鍵を VM またはプロジェクトのメタデータにアップロードするか、メタデータの変更権限をユーザーに付与して、ユーザーがアップロードできるようにします。
単一の VM のメタデータにアップロードされた公開鍵は、その VM に対するユーザーの root 権限のみを付与します。プロジェクト メタデータにアップロードされた鍵は、プロジェクト内のすべての VM に対するユーザーのアクセス権を付与します。
OS Login 鍵の認証: ユーザーは、Google ユーザー アカウントの一部である OS Login プロファイルに 1 つ以上の公開鍵をアップロードします。
管理者は、OS Login 管理者ユーザーまたは OS Login ユーザーの IAM ロールを付与することで、VM に対する root 権限または通常のユーザー権限をユーザーに付与するかどうかを決定できます。
gcloud CLI、Google Cloud コンソールのブラウザ内 SSH クライアント、IAP デスクトップは、使用しているメカニズムを自動的に検出し、それに応じてユーザーの鍵をアップロードできます。
この 2 つのメカニズムの主な違いは、IAM ポリシーに対するアクセスの評価が行われるタイミングです。
メタデータキーの場合、アクセスは鍵のアップロード時に 1 回だけ評価されます。
ユーザーの鍵は VM またはプロジェクトのライフサイクルに関連付けられており、鍵を削除するか、VM またはプロジェクトを削除するまで有効です。ユーザー アカウントを停止または削除しても、鍵の有効性には影響しません。
OS Login では、ユーザーが SSH セッションを確立しようとするたびにアクセスが評価されます。
ユーザーの鍵は、ユーザー アカウントのライフサイクルに関連付けられます。Cloud Identity または Google Workspace でユーザーを停止または削除すると、そのユーザーの鍵を使用して SSH アクセス権を付与できなくなります。
メタデータベースの鍵を使用すると、持続型の脅威にさらされる可能性があります。公開鍵がメタデータからタイムリーに削除されない場合、ユーザーは SSH アクセス権を必要以上に保持する可能性があります。また、組織を離れた後もアクセス権を保持する可能性があります。メタデータを定期的にスキャンすることで、このリスクを軽減できますが、大規模な環境では難しい場合があります。また、メタデータベースの鍵はユーザーに root 権限を付与するため、十分な対応ができない場合があります。
このような持続型の脅威から保護するため、ユーザーがメタデータベースの鍵を使用できないようにします。代わりに、OS Login の使用を強制するようにプロジェクトを構成します。
組織のポリシーを使用して OS Login の一貫した使用を適用する
OS Login は enable-oslogin メタデータキーによって制御されます。プロジェクトまたはインスタンス メタデータで enable-oslogin を TRUE に設定すると OS Login が有効になり、FALSE に設定すると OS Login が無効になります。
プロジェクト レベルのメタデータを変更するには、プロジェクトに対する compute.projects.setCommonInstanceMetadata 権限が必要です。この権限は、Compute インスタンス管理者（roles/compute.instanceAdmin.v1）ロールと Compute 管理者（roles/compute.admin）ロールに含まれています。同様に、インスタンス レベルのメタデータを変更するには、それぞれの VM インスタンスに対する compute.instances.setMetadata 権限が必要です。
インスタンス レベルのメタデータは、プロジェクト レベルのメタデータよりも優先されます。したがって、プロジェクト メタデータで enable-oslogin を TRUE に設定するだけでは、プロジェクト全体で OS Login の使用を強制することはできません。Compute インスタンス管理者またはプロジェクト内の VM インスタンスに対する同等のアクセス権を持つユーザーは、VM インスタンスのメタデータに enable-oslogin=FALSE を追加することで、設定をオーバーライドできます。
OS Login の一貫した使用を適用するには、プロジェクト メタデータで enable-oslogin を TRUE に設定しないでください。代わりに、「組織のポリシーを使用して組織の OS Login を有効にする」を適用して、インスタンスまたはプロジェクトのメタデータで enable-oslogin を false に設定する試みを拒否します。
一時的または VM ごとに特権ロールを付与する
異なるワークロードを実行し、異なるチームによって管理されている VM インスタンスがある場合は、これらの VM を異なる Google Cloud プロジェクトにデプロイし、プロジェクトに共有ネットワークを使用させることで、アクセス管理を簡素化できます。ただし、別々のプロジェクトを使用することは必ずしも現実的ではありません。一部のプロジェクトでは、異なる VM インスタンスに異なるユーザーのみがアクセスできるようにしている場合があります。
プロジェクトにこのような VM インスタンスの組み合わせが存在する場合は、プロジェクト レベルで Compute インスタンス管理者などのロールをユーザーに永続的に付与しないでください。その代わりに、閲覧専用アクセスと特権アクセスを区別します。
- プロジェクト レベルでは、ユーザーに Compute 閲覧者または同等の閲覧専用ロールを付与します。このロールを持つユーザーは、Google Cloud コンソールを使用して VM を参照できますが、SSH 鍵を公開したり VM にアクセスしたりすることはできません。
- ユーザーに Compute OS Login、Compute インスタンス管理者、またはその他の特権ロールを個々の VM に対してのみ、またはジャストインタイムでのみ付与します。
ユーザーが組織を退職したときにユーザー アカウントを停止する
Cloud Identity または Google Workspace でユーザー アカウントを停止または削除すると、ユーザーの IAM 権限が自動的に取り消されます。OS Login は、SSH セッションを確立する前にユーザーの IAM 権限を確認するため、ユーザー アカウントを停止または削除すると、OS Login を使用する VM へのユーザーのアクセス権も取り消されます。
シングル サインオンに外部 IdP を使用するように Cloud Identity または Google Workspace を構成した場合、従業員は外部 IdP と Cloud Identity（または Google Workspace）の両方にユーザー アカウントを持ちます。外部 IdP で従業員のユーザー アカウントを無効にするか削除すると、新しいブラウザ セッションを確立して Google サービスにアクセスする機能が取り消されますが、OS Login にはすぐに影響しません。従業員の Cloud Identity または Google Workspace ユーザー アカウントが有効な限り、OS Login では引き続きユーザーが SSH 接続を認証して確立できます。
ユーザーが組織を離れたときに SSH アクセス権を確実に取り消すには、Cloud Identity または Google Workspace のユーザー アカウントを停止または削除してください。外部 IdP を使用する場合は、OS Login がアクセスを取り消せるように、ユーザーの停止イベントを伝播するように構成します。
特権サービス アカウントが設定されている VM に SSH アクセス権を付与しない
VM インスタンスにサービス アカウントが接続されている場合、VM で実行されているアプリケーションは、VM のメタデータ サーバーから有効期間の短い認証情報をリクエストし、これらの認証情報を使用してサービス アカウントとして機能します。
VM への SSH アクセス権を付与すると、同様の権限が付与されます。アプリケーションと同様に、VM のメタデータ サーバーから有効期間の短い認証情報をリクエストし、接続されたサービス アカウントとして機能できます。
接続されたサービス アカウントを使用して VM に SSH アクセスすると、サービス アカウントとして機能するため、OS Login ではサービス アカウントに対する iam.serviceAccounts.actAs 権限が必要になり、VM インスタンスに接続するたびにこの権限がチェックされます。これにより、OS Login はサービス アカウントのセキュリティを維持し、SSH アクセスが権限昇格に悪用されるのを防ぐことができます。
特権サービス アカウントを持つ VM に関連するリスクをさらに軽減するには、次の代替手段を検討してください。
- ワークロードで Google Cloud リソースへのアクセスが必要な場合を除き、サービス アカウントを VM に接続しないでください。
- 単一目的のサービス アカウントを使用して、ワークロードに必要なリソースへのアクセス権のみを付与します。
- VM とサービス アカウントへのアクセスを永続的に付与するのではなく、ユーザーがジャストインタイム アクセスをリクエストすることを必須にします。
root 権限の使用を制限する
OS Login を使用してユーザーに OS Login ユーザー（roles/compute.osLogin）ロールを付与すると、VM に対する制限されたユーザー権限がユーザーに割り当てられます。一方、ユーザーに OS Login 管理者ユーザー（roles/compute.osAdminLogin）ロールを付与する場合、OS Login ではなくメタデータ ベースの鍵認証を使用する場合、またはユーザーが VM メタデータを変更できるようにする場合は、ユーザーに VM に対する root 権限が暗黙的に付与されます。
VM に対する root 権限をユーザーに付与すると、永続的なリスクにさらされる可能性があります。ユーザーがこれらの権限を悪用して新しいユーザー アカウントを作成したり、バックドアをインストールして VM への永続的なアクセスを維持したりする可能性があります。
この永続的なリスクを軽減するには、root 権限の使用を制限し、root 権限が不要な場合にのみ OS Login ユーザー（roles/compute.osLogin）ロールを付与します。
POSIX プロファイルを事前に作成して、ユーザー名と UID の一貫性を維持する
各 Linux VM は、ユーザー（/etc/passwd）とグループ（/etc/groups）のローカル データベースを維持します。SSH を使用して Linux VM に初めて接続すると、ゲスト環境によって Linux ユーザー アカウントが自動的に作成され、UID が割り当てられます。
メタデータ ベースの鍵を使用する場合、ゲスト環境で Linux ユーザーは Google ユーザー アカウントにリンクされません。また、接続する VM ごとに異なる UID が割り当てられることがあります。マシン間で一貫した UID を適用しない環境で、一貫した UID を前提とする NFS などのプロトコルを使用すると、ユーザーが誤って別のユーザーとしてリモート アクセスを実行する可能性があります（また、不正な行為者が意図的に行う可能性もあります）。
メタデータ ベースの鍵を使用する場合、ゲスト環境で使用するユーザー名を選択することもできます。同僚が以前に使用していたユーザー名を選択すると、その同僚用に最初に作成されたアカウントでログインできます。
このような UID とユーザー名の曖昧さを回避するには、OS Login を使用します。OS Login を使用して Linux VM に初めてログインすると、ゲスト環境は、Google ユーザー アカウントの POSIX プロファイルに基づいて Linux ユーザーを作成します。POSIX プロファイルは Linux ユーザーのテンプレートとして機能し、次のことを定義します。
- 同じ Cloud Identity アカウントまたは Google Workspace アカウントのすべてのユーザーで一意の Linux ユーザー名
- すべての Google Cloud プロジェクトで一意の UID と GID
- ホーム ディレクトリのパス
- ログインシェルなどの追加構成
初めてログインするときに Google アカウントに POSIX プロファイルがない場合は、OS Login によって自動的に作成されます。
OS Login によって割り振られるユーザー名と UID は Google Cloud 環境内で一意ですが、Google Cloud の外部で使用するユーザー名や UID と重複したり、不整合が生じる可能性があります。OS Login のユーザー名と UID を他の環境と整合させる必要がある場合は、自動プロファイル作成に依存しないことをおすすめします。代わりに、Directory API を使用して OS Login POSIX プロファイルを事前に作成し、カスタム ユーザー名、UID、GID を割り当てます。