This document describes best practices for auditing SSH access to Linux virtual machine (VM) instances.
Cloud Audit Logs let you analyze past activity and can be an important source of information when investigating suspicious activity affecting your Google Cloud resources.
The following sections contains best practices that can help you maintain a non-repudiable audit trail:
The document focuses on practices that are either specific to Google Cloud or of particular relevance when using SSH on Google Cloud. The document doesn't cover best practices for specific SSH client or server implementations.
Enable data access logs for IAP
To make sure that IAP adds an entry to the Cloud Audit Logs whenever a user attempts to establish an SSH connection, enable data access logs for the Cloud Identity-Aware Proxy API. Data access logs are disabled by default. Unless you have concerns about log volume, enable data access logs for all projects that contain VM instances.
Monitor audit log entries related to SSH usage
SSH usage can impact the security of VMs and their workloads, so it's important to keep an audit trail for both successful connection attempts and failed access attempts. This is especially important in production environments, where SSH usage should be considered a sensitive action.
To track SSH access and possibly to find suspicious behavior, make sure that you monitor log entries related to SSH, including the following:
| Service | Method | Description |
|---|---|---|
| IAP | AuthorizeUser |
Indicates a connection attempt through IAP TCP-forwarding. Log entries contain details about the user's device, satisfied access levels, and unsatisfied access levels. |
| OS Login | google.cloud.oslogin.v1.OsLoginService.CheckPolicy |
Indicates a login attempt. |
| OS Login | google.cloud.oslogin.OsLoginService.v1.StartSession |
Indicates the start of a OS Login 2FA challenge |
| OS Login | google.cloud.oslogin.OsLoginService.v1.ContinueSession |
Indicates the completion of a OS Login 2FA challenge |
| Compute Engine | v1.compute.projects.setCommonInstanceMetadata |
If the field projectMetadataDelta contains an entry for `ssh-keys`, then
this log entry indicates that an SSH key was added, removed or modified in project metadata.
|
| Compute Engine | v1.compute.instances.setMetadata |
If the field projectMetadataDelta contains an entry for `ssh-keys` or `sshKeys`,
then this log entry indicates that an SSH key was added, removed or modified
in instance metadata.
|
| Compute Engine | google.ssh-serialport.v1.connect |
Indicates a connection attempt to the serial console |
| IAM |
beta.compute.instances.setIamPolicy,
v1.compute.instances.setIamPolicy
|
Indicates a change to the IAM policy of a VM instance. An IAM policy change might affect users' ability to modify instance metadata. |
| IAM |
SetIamPolicy |
Indicates a change to the IAM policy of a project. An IAM policy change might affect users' ability to modify project metadata and the project's Data Access audit logs configuration. |
All audit log records contain a principalEmail field that identifies the principal
that initiated the activity.
To get a complete picture of activity on your VMs, configure your VMs to export
/var/log/messages and SSH server logs to Cloud Logging, for example
by using Ops Agent.
Notice that depending on the Linux distribution you use, SSH server logs might
be written to different log files (typically, /var/log/auth.log or /var/log/secure),
and that these log files aren't covered by the
default configuration used by Ops Agent.