IAP経由のSSHはどこまで監査できるのか。OS LoginとVMログを実測した

Terraform-GoogleCloud - この記事は連載の一部です

パート 45: この記事

パート 46: Cookieに backend-a と書いても backend-a2 へ届く。ALBのセッションアフィニティを実測した

パート 47: Cloud Monitoring ダッシュボード実践｜既存ダッシュボードの活用からCustom Dashboard・Terraform管理まで

概要
#

外部IPを付けず、tcp/80 も開けずに、VM 上の HTTP を見たい。IAP の SSH ポートフォワードでできます。許可するのは IAP の範囲からの tcp/22 だけです。

ただ、そのあとに困ることが2つあります。

誰に何の権限を渡せばいいのか。 公式の手順どおりに書いたつもりで、自分では繋がるのに他の人が繋がらない、ということが起きます。

誰が何をしたか、どこまで残るのか。 踏み台を置かない構成なので、監査の材料がどこにあるのか分かりにくくなります。

この2つを実測します。接続手順そのものはサンプルの README にあるので、ここでは扱いません。

Google Cloud の Compute Engine を触ったことがある人向けです。外部IPなしの VM への接続経路を決めようとしている場面を想定しています。IAP の Web アプリ向け機能と、Organization Policy による追加要件は扱いません。

検証環境
#

Terraform v1.14.3、hashicorp/google v7.46.0
Google Cloud SDK 562.0.0
Ops Agent 2.70.0、Debian 12

使用するコードは Advanced-Examples/07-iap-ssh-port-forwarding です。

cd Advanced-Examples/07-iap-ssh-port-forwarding
cp terraform.tfvars.example terraform.tfvars
# project_id と iap_member を書く
terraform init
terraform apply

terraform apply が終わると、接続用のコマンドが出力されます。

Apply complete! Resources: 15 added, 0 changed, 0 destroyed.

Outputs:

http_tunnel_command = "gcloud compute ssh tf-adv-iap-forward-vm --zone=asia-northeast1-a --tunnel-through-iap -- -N -L 127.0.0.1:8080:127.0.0.1:80"
iap_ssh_command = "gcloud compute ssh tf-adv-iap-forward-vm --zone=asia-northeast1-a --tunnel-through-iap"
internal_ip = "10.70.0.2"

terraform apply のあと、別に3つ確認します。差分が残っていないこと、nginx と Ops Agent が動いていること、sudo なしで HTTP が返ることです。

$ terraform plan -detailed-exitcode
No changes. Your infrastructure matches the configuration.   # exit 0

$ gcloud compute ssh tf-adv-iap-forward-vm --tunnel-through-iap --command='
    echo "ops-agent: $(systemctl is-active google-cloud-ops-agent)"
    echo "nginx: $(systemctl is-active nginx)"
    curl -s -o /dev/null -w "curl: %{http_code}\n" http://127.0.0.1/'
ops-agent: active
nginx: active
curl: 200

Ops Agent は startup.sh が入れます。apply 後30秒で active になり、後述の auth.log の収集設定も入った状態で立ち上がりました。

構成はこれだけです。

flowchart LR
    ME["手元
127.0.0.1:18080"] -->|"tcp/22"| IAP["IAP
35.235.240.0/20"]
    IAP --> SSHD["sshd
VM 10.70.0.2（外部IPなし）"]
    SSHD -->|"-L で張ったチャネル"| NGX["nginx
0.0.0.0:80"]
    OTHER["同じVPCの別VM
10.70.0.3"] --x SSHD
    NET["インターネット"] --x SSHD

届く矢印は1本だけです。 残り2本が届かない理由は別々で、次の節で分けて確かめます。

Firewall は1本しかありません。

$ gcloud compute firewall-rules list --format="table[no-heading](name,sourceRanges.list(),allowed[].map().firewall_rule().list())"
tf-adv-iap-forward-vpc-allow-iap-ssh  35.235.240.0/20  tcp:22

届くことと、届かないことを確認する
#

トンネルを張って、クエリ文字列に識別子を入れたリクエストを3回送ります。同じリクエストを、手元と VM のログの2か所で追うためです。

$ gcloud compute ssh tf-adv-iap-forward-vm --tunnel-through-iap -- -N -L 127.0.0.1:18080:127.0.0.1:80
（別の端末で）
$ curl -s -o /dev/null -w '%{http_code}\n' "http://127.0.0.1:18080/?probe=TUNNEL-MARK-1"
200

VM 側の nginx に、その識別子が残ります。

$ sudo grep TUNNEL-MARK /var/log/nginx/access.log
127.0.0.1 - - [12/Sep/2026:05:05:25 +0000] "GET /?probe=TUNNEL-MARK-1 HTTP/1.1" 200 250 "-" "curl/7.81.0"
127.0.0.1 - - [12/Sep/2026:05:05:25 +0000] "GET /?probe=TUNNEL-MARK-2 HTTP/1.1" 200 250 "-" "curl/7.81.0"
127.0.0.1 - - [12/Sep/2026:05:05:25 +0000] "GET /?probe=TUNNEL-MARK-3 HTTP/1.1" 200 250 "-" "curl/7.81.0"

送信元が 127.0.0.1 です。 トンネルの転送先を VM 自身のループバックにしているためで、nginx から見ると自分宛の通信になります。このログだけでは、誰が送ったリクエストかを特定できません。あとで監査ログと比べるときに効いてきます。

nginx 自体はループバック限定ではありません。0.0.0.0:80 で待っています。

$ sudo ss -ltn | grep ':80 '
LISTEN 0 511 0.0.0.0:80 0.0.0.0:*

届かない理由は2つあります。同じ VPC の別VMからは、Firewall で許可していないからです。インターネットからは、このVMに外部IPが無いからです。

どちらも待受アドレスとは関係しません。

トンネルを閉じると到達できなくなります。

$ curl --max-time 5 http://127.0.0.1:18080/
（到達不可）

同じ VPC の別の VM からも届きません。確認用の VM を一時的に立てて、内部IP へ直接送りました。

$ # 10.70.0.3 から 10.70.0.2 へ
$ curl --connect-timeout 5 "http://10.70.0.2/?probe=SAMEVPC-MARK"
（到達不可）
$ bash -c "exec 3<>/dev/tcp/10.70.0.2/22"
（到達不可）

nginx にもその識別子は残っていません。

$ sudo grep -c SAMEVPC-MARK /var/log/nginx/access.log
0
$ sudo grep -c TUNNEL-MARK /var/log/nginx/access.log
3

tcp/22 すら同じ VPC からは通りません。 Firewall の送信元が 35.235.240.0/20、つまり IAP の範囲だけだからです。「外部IPが無いから守られている」のではなく、通す先を IAP に限っている構成です。

権限: `osLogin` だけでは足りない
#

ここからが本題です。修正前のサンプルが iap_member に渡していたのは2種類のロールで、付与先は3か所でした。

roles/iap.tunnelResourceAccessor   # プロジェクトとインスタンスの2か所
roles/compute.osLogin              # プロジェクト

プロジェクトとインスタンスの二重付与は不要です。 プロジェクトに付けると全VMへ接続できるので、インスタンス単位の付与は制限になりません。最小権限を主題にするなら、インスタンス単位だけにします。実測でも、プロジェクト単位を外して接続できました。

これで足りるかを、権限を絞った主体で確かめます。オーナー権限の自分で試しても分かりません。オーナーは必要な権限をだいたい含んでいるからです。

検証用のサービスアカウントを作り、借用しました。借用するには、自分に対象 SA への roles/iam.serviceAccountTokenCreator が要ります。

gcloud iam service-accounts add-iam-policy-binding <検証用SA> \
  --member="user:you@example.com" --role="roles/iam.serviceAccountTokenCreator"

VM に付いているサービスアカウントと、接続主体として借用するサービスアカウントは別物です。前者は VM の実行 ID、後者は「権限を絞った利用者」の代わりです。

$ gcloud compute ssh tf-adv-iap-forward-vm --tunnel-through-iap \
    --impersonate-service-account=<検証用SA>
sa_101585152189875547132@compute.6046415367025813942: Permission denied (publickey).

接続できません。 OS Login のプロファイル自体は取得できます。

$ gcloud compute os-login describe-profile --impersonate-service-account=<検証用SA>
sa_101585152189875547132	3788356900

原因は公式ドキュメントにありました。

roles/iam.serviceAccountUser — All users, if the VM has a service account — Set up OS Login

このサンプルの VM は専用のサービスアカウントを持っています。VM にサービスアカウントが付いていると、接続する側にもこのロールが要ります。 足すと82秒後に通りました。

resource "google_service_account_iam_member" "vm_sa_user" {
  service_account_id = google_service_account.vm.name
  role               = "roles/iam.serviceAccountUser"
  member             = var.iap_member
}

OS Login のプロファイルは取得できるのに、SSH 接続は Permission denied (publickey) で失敗します。 原因が権限だと気づきにくい失敗です。

`sudo` は通らない
#

繋がったので、README に書いてあった確認手順を実行しました。

$ sudo systemctl status nginx --no-pager
sudo: a password is required

OS Login のアカウントにパスワードはありません。パスワードを求められた時点で、この手順は使えません。

roles/compute.osLogin の定義がそのままの理由です。公式のロール表も、管理者として入るなら roles/compute.osAdminLogin としています。

$ gcloud iam roles describe roles/compute.osLogin --format="value(description)"
Access to log in to a Compute Engine instance as a standard (non-administrator) user.

$ gcloud iam roles describe roles/compute.osAdminLogin --format="value(description)"
Access to log in to a Compute Engine instance as an administrator user.

同じ主体に roles/compute.osAdminLogin を足すと、108秒後に通るようになりました。変えたのは権限だけです。

$ sudo -n true; echo $?
0

`groups` を見ても分からない
#

ここが紛らわしいところです。sudo が通る前と後で、groups の出力が同じでした。

$ groups
sa_101585152189875547132 video

$ getent group google-sudoers
（空）

分かれ目はファイルの有無です。

$ sudo ls -la /var/google-sudoers.d/
-r--r----- 1 root root 49 Sep 12 04:47 sa_101585152189875547132
-r--r----- 1 root root 50 Sep 12 04:39 techcat222_techcat222_com

$ sudo cat /var/google-sudoers.d/$(whoami)
sa_101585152189875547132 ALL=(ALL) NOPASSWD: ALL

権限を足したあとのログインで、この主体のファイルが作られていました（タイムスタンプが 04:47）。グループを見て「sudo できない」と判断すると誤ります。 ただし今回見たのはファイルの有無と sudo の成否の対応だけで、書き込みの契機までは追っていません。

権限を上げるか、`sudo` を要らなくするか
#

osAdminLogin に上げれば README の手順は通ります。ただ、確かめたいのは「nginx が動いているか」です。それは sudo なしでできます。

$ systemctl is-active nginx
active
$ curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1/
200

このサンプルの主題は最小権限での接続なので、確認手順から sudo を外すほうを選びました。管理作業が要るサンプルなら逆の判断になります。

ログ: 何が残り、何が残らないか
#

1回の接続が4か所に記録を残し、どれも単独では足りません。 先に置き場所を並べます。

sequenceDiagram
    participant ME as 手元
    participant OL as OS Login
    participant IA as IAP
    participant SD as sshd（VM）
    participant NG as nginx（VM）

    ME->>OL: ListLoginProfiles / CheckPolicy
    Note over OL: 誰が・どのVMへ・いつ。接続元IPは無い
    ME->>IA: トンネルを張る
    Note over IA: AuthorizeUser: 接続元IPと対象インスタンス
    IA->>SD: tcp/22
    Note over SD: auth.log: 接続が成立したか
    ME->>NG: 18080 への curl（トンネル経由）
    Note over NG: access.log: 送信元は 127.0.0.1

上の2つは Google Cloud の監査ログです。OS Login は既定で出ていましたが接続元IPがなく、IAP の AuthorizeUser は有効にするまで0件でした。

下の2つは VM のログで、Ops Agent を入れるまで Cloud Logging に届きません。 順に見ます。

Google Cloud 側の監査ログから見ます。設定は既定のままで、プロジェクトと組織のどちらにも auditConfigs がありません。

フォルダ階層は権限が足りず確認できていません。

ログ	既定の設定で	有効にすると
`oslogin.googleapis.com`（`CheckPolicy` / `ListLoginProfiles`）	50件	—
`iap.googleapis.com` の `AuthorizeUser`	0件	出る（接続1回につき1件）
`iap.googleapis.com` の `SetIamPolicy`	1件（Terraform の操作）	—

Data Access ログは既定で無効です。oslogin のデータプレーンだけは設定なしで出ていました。ただしフォルダ階層の auditConfigs は権限が足りず確認できていないので、上位から効いていた可能性は否定できません。

IAP 側は、有効にすると出ます。今回は ADMIN_READ / DATA_READ / DATA_WRITE の3種類を有効にしてから、SSH とトンネルを1回ずつ実行しました。

$ # auditConfigs で iap.googleapis.com の ADMIN_READ / DATA_READ / DATA_WRITE を有効化
$ gcloud logging read 'protoPayload.methodName="AuthorizeUser"' --freshness=20m
10:34:31  iap.googleapis.com  AuthorizeUser  you@example.com
10:34:26  iap.googleapis.com  AuthorizeUser  you@example.com

公式の Best practices for auditing SSH access が、これを挙げています。「IAP TCP-forwarding を通した接続試行」を示すログです。実測と一致しました。

DATA_READ と DATA_WRITE だけのときは、10分・4回の試行で0件でした。 どの種類が効いたかまでは切り分けていません。伝播の影響も分離していないので、今回の環境で3種類にしたら出た、というところまでです。

中身には、ほかのログに無いものが入っています。

principal : you@example.com
resource  : 8199665158944494794      （gce_instance / asia-northeast1-a）
callerIp  : 240f:73:5420:...          ← 接続元のIP
metadata  : {"iap_tcp_session_info": {"phase": "SESSION_START"}, "device_state": "Unknown"}

接続元IPと対象インスタンスが残ります。 OS Login のログには接続元IPがありません。

なお IAP の監査ログ一覧に AuthorizeUser は載っていません。公式ドキュメント同士で記載が食い違っています。 一覧にないことを根拠に「記録されない」と判断すると間違えます。

CheckPolicy の中身です。

principal: you@example.com
resource : .../instances/tf-adv-iap-forward-vm
request  : {"instance": "tf-adv-iap-forward-vm", "policy": "ADMIN_LOGIN", ...}
response : {"success": true}

誰が・どの VM へ・いつ権限を確認したかが分かります。借用したサービスアカウントも別の主体として記録されます。

ただしこれは権限の確認であって、SSH 接続が成立した記録ではありません。 この記事の前半で Permission denied (publickey) になった試行でも、CheckPolicy は出ていました。接続できたかどうかは、VM 側のログ（後述）を見る必要があります。

policy の LOGIN と ADMIN_LOGIN は、利用者が管理者権限を要求したかどうかではありません。 今回の接続では、毎回 LOGIN と ADMIN_LOGIN の両方が確認されました。

ADMIN_LOGIN の結果は、そのログインで sudo を使えるようにするかの判断に使われます。sudo を実行したかどうかは、このログからは分かりません。

  you@example.com         policy=ADMIN_LOGIN  success=True   20件
  検証用SA                 policy=ADMIN_LOGIN  success=None   13件   ← 拒否
  検証用SA                 policy=ADMIN_LOGIN  success=True   12件   ← 権限付与後

success が欠落している行があります。権限を足す前の主体のもので、足したあとは True が入りました。false がフィールドごと消えていると読むのが自然です。

ただしこれは今回の対応関係からの解釈で、欠落が常に拒否を意味するとは確かめていません。また ADMIN_LOGIN の欠落は「sudo が使えない」であって、ログイン自体の拒否とは別です。

IAP のメトリクスは見つからなかった
#

このプロジェクトで iap.googleapis.com で始まるメトリクスは1件も取得できませんでした。名前の当て違いを疑って接頭辞を総なめしましたが、iam や ids は出るのに iap だけありません。

公式のメトリクス一覧にも iap.googleapis.com の節がありません。この2つが根拠で、IAP 関連の指標が一切存在しないと確かめたわけではありません。

VM のネットワーク指標には通信が出ます。ただしトンネルの中身は見えません。

compute.googleapis.com/instance/network/received_bytes_count を60秒の ALIGN_DELTA で並べたものです。

05:05  722      ← この分にトンネルで HTTP を3回送った
05:06  13391    ← この分に SSH でログを確認した
05:07  1147

どの通信がどれだけ寄与したかは、この値からは分けられません。 同じ分に SSH の制御通信も入ります。

このリクエストに限れば、nginx へ届く部分は VM のループバックで完結します。NIC を通るのは IAP からの暗号化された tcp/22 です。nginx のログが 127.0.0.1 と記録するのと同じ理由です。

なお VM 全体では、Cloud NAT 経由の外向き通信や Ops Agent の送信も同じ NIC を通ります。

通常の SSH とトンネルを見分けられるか
#

OS Login の監査ログでは見分けられません。 同じ時間帯に1回ずつ実行した並びが、完全に同じでした。

トンネル（`-N -L`）	通常の SSH（`--command`）
`ListLoginProfiles`	`ListLoginProfiles`
`CheckPolicy LOGIN True`	`CheckPolicy LOGIN True`
`CheckPolicy ADMIN_LOGIN True`	`CheckPolicy ADMIN_LOGIN True`

ポートフォワードは認証が終わったあとに張るチャネルです。この監査ログからは「SSH した」としか読めません。VM 側のログを送れば話が変わります（後述）。

では VM 側はどうか。段階を追って測りました。

Ops Agent を入れても、既定では sshd の記録は来ない
#

以下は、この記事の検証で踏んだ経過です。 サンプルのコードには修正を入れたので、いま apply すると最初から動きます。踏んだ順に書くのは、同じ症状が出たときに切り分けやすいからです。

Ops Agent を入れただけでは足りませんでした。まず権限です。

$ systemctl is-active google-cloud-ops-agent
active
$ gcloud logging read 'resource.type="gce_instance" AND resource.labels.instance_id="<VM>"'
（0件）

active なのに1件も届きません。 コードには scopes = ["logging.write"] と書いてあります。しかし VM のサービスアカウントは、ロールを1つも持っていませんでした。スコープは「その資格情報で何を要求してよいか」の上限で、書き込みを許すのは IAM 側です。

$ gcloud projects get-iam-policy <project> --filter="bindings.members:<VMのSA>" --format="value(bindings.role)"
（空）

logging.logEntries.create を含むロールが要ります。今回は roles/logging.logWriter を付けました。付けた瞬間に、溜まっていたエラーが一斉に出てきました。

Permission 'logging.logEntries.create' denied on resource
'//logging.googleapis.com/projects/<project>/logs/ops-agent-fluent-bit'

Cloud Logging にはエージェント自身のエラーログも送れないので、VM の外からは気づけません。VM の中には残っています。スコープとロールの両方が要ります。

権限を足すと syslog が届き始めました。ただし sshd の記録はありません。

$ # Cloud Logging の syslog に含まれる sshd の行
0
$ # VM 上の /var/log/auth.log に含まれる sshd の行
123

Debian の rsyslog が、認証系を syslog から外しているためです。

*.*;auth,authpriv.none    -/var/log/syslog
auth,authpriv.*            /var/log/auth.log

Ops Agent の既定の収集対象は syslog です。sshd と sudo の記録は auth.log にあるので、明示的に足さないと来ません。

サンプルでは startup.sh がこの設定を書きます。作り直して確かめたところ、apply だけで sshd の記録が Cloud Logging に届きました。

/etc/google-cloud-ops-agent/config.yaml に書いて、エージェントを再起動します。

logging:
  receivers:
    auth:
      type: files
      include_paths: [/var/log/auth.log]
  service:
    pipelines:
      auth_pipeline:
        receivers: [auth]

$ sudo systemctl restart google-cloud-ops-agent

`auth.log` を送ると、VERBOSE で見分けられる
#

届くようになりました。まず既定の LogLevel INFO です。通常セッションとトンネルを1回ずつ実行しました。

sshd[5046]: Accepted publickey for you_example_com from 35.235.248.48 port 41621 ssh2   ← 通常
sshd[5059]: Accepted publickey for you_example_com from 35.235.248.48 port 35027 ssh2   ← トンネル

認証の行は同じ形です。 ここだけを見ると区別がつきません。

LogLevel VERBOSE にすると分かれます。設定して反映し、実際の値を確認してから測ります。

$ echo "LogLevel VERBOSE" | sudo tee /etc/ssh/sshd_config.d/99-verbose.conf
$ sudo systemctl reload ssh
$ sudo sshd -T | grep -i '^loglevel'
loglevel VERBOSE

auth.log を空にしてから、同じ2つを実行しました。

### sshd[6090]（通常）の子プロセス 6099
Starting session: command for you_example_com from 35.235.248.48 port 43337 id 0

### sshd[6103]（トンネル）の子プロセス 6112
（0行）

ポートフォワードだけのセッションは、子プロセスが1行も出しませんでした。 シェルやコマンド実行があると Starting session が出ます。

ただしこれは「Starting session が無ければポートフォワードだ」という判定にはなりません。 何もしない -N だけの接続でも同じく出ません。今回比べた2つの起動方法の間で差が出た、という結果です。

LogLevel DEBUG まで上げると、チャネルの種類が直接出ます。

# ポートフォワード
sshd[5210]: debug1: server_input_channel_open: confirm direct-tcpip

# シェルやコマンド実行
sshd[5227]: debug1: server_input_channel_open: ctype session rchan 0 win 2097152 max 32768

direct-tcpip がポートフォワード、session がシェルまたはコマンド実行です。ただし DEBUG について OpenSSH の man はこう書いています。

“Logging with a DEBUG level violates the privacy of users and is not recommended.” — sshd_config(5)

今回の2つを区別するだけなら VERBOSE の差で足りました。 ポートフォワードそのものを判定したいなら、チャネルの種類が出る DEBUG が要ります。

`sudo` で実行したコマンドは残る
#

sudo の記録も auth.log に残ります。

sudo: you_example_com : PWD=/home/you_example_com ; USER=root ;
      COMMAND=/usr/bin/grep -c sshd /var/log/auth.log

sudo を経由しないコマンドは残りません。シェル履歴は別の話です。

まとめ
#

roles/compute.osLogin と IAP のロールだけでは接続できなかった。 VM にサービスアカウントが付いている場合、接続する側に roles/iam.serviceAccountUser が要る。OS Login のプロファイルは取得できるのに Permission denied (publickey) で弾かれる
IAP のトンネル権限は、インスタンス単位だけで足りる。 プロジェクトにも付けると全VMへ接続できてしまう。roles/compute.viewer も不要だった
osLogin では sudo が通らない。 「standard (non-administrator) user」だから。osAdminLogin に上げるか、確認手順から sudo を外す
groups では sudo の可否を判別できない。 /var/google-sudoers.d/<ユーザー名> の有無と対応していた
オーナーで試すと、これらに気づけない。 オーナーは必要な権限を含む。権限を絞った主体を作って確かめる
誰が・どの VM へ・いつ権限を確認したかは OS Login の監査ログに残る。 ただしこれは権限チェックの記録で、SSH 接続が成立した証拠ではない。今回の接続では LOGIN と ADMIN_LOGIN の両方が毎回確認された。sudo を実行したかは分からない
トンネル1本ごとの認可は AuthorizeUser に残る。 Data Access ログを有効にする必要がある。今回は ADMIN_READ / DATA_READ / DATA_WRITE の3種類を有効にして確認できた（後者2つだけのときは0件）。接続元IPと対象インスタンスが入る。IAP の監査ログ一覧には載っておらず、公式ドキュメント同士で記載が一致していない
このプロジェクトで IAP のメトリクスは取得できず、公式の一覧にも節が無かった
通常の SSH とポートフォワードは、OS Login の監査ログでは見分けられない。 VM 側の auth.log を送り LogLevel VERBOSE にすると、今回比べた2つは Starting session の有無で分かれた。ただしその欠如はポートフォワードの証拠ではない（-N だけの接続でも出ない）。判定したいならチャネルの種類が出る DEBUG が要るが、公式が推奨していない水準
Ops Agent は active でも書き込み権限が無いと1件も送れない。 スコープだけでは足りず、自分のエラーログすら出ない
Ops Agent の既定では auth.log を収集しない。 Debian は認証系を syslog から外すため、sshd と sudo の記録は明示的に足す