3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@gerrard15
in

IP制限中のサイトでGoogle Search Consoleの所有権を確認する方法（AWS ALB・HTMLファイル方式）

3
Posted at

概要

本番公開前のWebサイトでは、関係者のIPアドレスだけを許可し、一般ユーザーからのアクセスを制限していることがあります。

この状態でGoogle Search Consoleの所有権をHTMLファイル方式で確認しようとすると、Google Site Verifierが確認ファイルへアクセスできず、検証に失敗します。

本記事では、サイト全体のIP制限を解除せず、次の2段階で所有権確認用のHTMLファイルだけを一時的に公開する方法を紹介します。

  • Security Groupで、Google管理のユーザー起点フェッチャー用IPレンジからのHTTPS通信を許可する
  • Application Load Balancer（ALB）で、所有権確認用HTMLファイルへのリクエストだけをターゲットグループへ転送する

実務ではプロジェクト固有のネットワーク構成に合わせて設定しましたが、本記事ではドメイン名、検証トークン、AWSリソース名、ID、IPアドレスをすべてサンプルへ置き換えています。

先に結論

今回の対応イメージは次のとおりです。

Google Site Verifier
  ↓ Google公式IPレンジからのHTTPSのみ許可
ALBのSecurity Group
  ↓
AWS WAF（利用している場合）
  ↓ 対象ホストかつ確認ファイルの完全一致パスのみ転送
ALBのHTTPSリスナールール
  ↓
ターゲットグループ
  ↓
Webサーバー上の確認ファイル

重要なのは、0.0.0.0/0 でサイト全体を公開するのではなく、次の3点を限定することです。

  • 誰から：Googleが公開しているIPレンジ
  • どこへ：所有権確認用HTMLファイルの完全一致パス
  • いつまで：所有権確認に必要な期間だけ

前提

本記事では、DNSがインターネット向けALBを直接参照し、ALBのSecurity Groupで送信元を制限している構成を想定しています。

CloudFront、外部CDN、リバースプロキシなどがALBの前段にある場合は、ALBから見える送信元IPアドレスや設定対象が変わります。実際の構成に合わせて読み替えてください。

また、Search ConsoleのHTMLファイル方式には次の条件があります。

  • URLプレフィックスプロパティで利用する
  • 確認ファイルを認証なしで取得できるようにする
  • ファイル名と内容を変更しない
  • Search Consoleに指定されたURLへ配置する

詳しい要件は、Google Search Consoleの公式ヘルプを確認してください。

なお、ドメインプロパティではDNSレコードによる所有権確認が必要です。DNSを変更できる場合は、Webサイト側のアクセス制限を一時変更せずに済むため、先にDNS方式を検討するのが安全です。

Security Groupの許可だけでは確認できなかった

今回のプロジェクトでは、本番公開前のアクセス制限を次の2か所で行っていました。

  1. ALBのSecurity Groupで、許可済みの送信元だけからHTTPS通信を受け付ける
  2. ALBのHTTPSリスナーで、許可済みの送信元だけをターゲットグループへ転送し、それ以外には固定レスポンスを返す

この構成では、Security GroupへGoogleのIPレンジを追加するだけでは不十分です。

Google Site Verifier
  → Security Group：ALLOW
  → WAF：ALLOW
  → ALBリスナールール：既存の送信元条件に一致しない
  → デフォルトの固定レスポンス
  → Webサーバーへ到達しない

Security Groupで通信を許可しても、ALBへ到達した後にリスナールールで遮断されれば、確認ファイルは取得されません。

同様に、構成によってはAWS WAFやBasic認証など、別レイヤーのアクセス制限で止まることもあります。所有権確認に失敗したときは、「GoogleからWebサーバーまでのどこで止まっているか」をレイヤーごとに確認する必要があります。

対応方針

サイト全体は公開せず、次の条件に限定した一時経路を作ります。

レイヤー 一時対応
Security Group Google管理のユーザー起点フェッチャー用IPレンジから、HTTPSポートへの通信を許可する
ALBリスナー 対象ホストかつ所有権確認ファイルの完全一致パスだけを転送する
WAF 既存設定を維持し、検証リクエストが遮断されていないことを確認する
Webサーバー Search Consoleから取得したHTMLファイルを指定URLへ配置する

対応手順

1. 所有権確認ファイルを配置する

Search ConsoleでURLプレフィックスプロパティを追加し、HTMLファイル方式を選択します。

ダウンロードしたファイルを、Search Consoleに表示されたURLで取得できる場所へ配置します。ファイル名と内容は変更しないでください。

以下は確認用コマンドの例です。

SITE_HOST_VALUE="example.com"
VERIFY_FILE_VALUE="googlexxxxxxxxxxxxxxxx.html"

curl -sS -D - \
  "https://${SITE_HOST_VALUE}/${VERIFY_FILE_VALUE}"

まずは許可済みの送信元からアクセスし、HTTPステータスが 200、レスポンス本文が次の形式になっていることを確認します。

google-site-verification: googlexxxxxxxxxxxxxxxx.html

Googleは所有権を維持するために確認トークンを定期的に再確認します。そのため、所有権を維持する間は、確認ファイルをWebサーバーから削除しないでください。

2. GoogleのIPレンジをSecurity Groupへ一時追加する

Googleは、Google Site Verifierを含むユーザー起点フェッチャーのIPレンジをJSONで公開しています。対象となるフェッチャーとIPレンジの参照先は、Google User-Triggered Fetchersで確認できます。

IPレンジは更新される可能性があります。記事や過去の作業記録に記載された固定値をコピーせず、作業時点の公式JSONを取得してください。

今回のプロジェクトではALBがIPv4構成だったため、ipv4Prefix だけをSecurity Group登録用JSONへ変換しました。

curl -fsSL \
  "https://developers.google.com/static/crawling/ipranges/user-triggered-fetchers-google.json" |
python3 -c '
import ipaddress
import json
import sys

source = json.load(sys.stdin)
networks = [
    ipaddress.ip_network(item["ipv4Prefix"])
    for item in source["prefixes"]
    if "ipv4Prefix" in item
]
ranges = [
    {
        "CidrIp": str(network),
        "Description": "Temporary Google Site Verifier"
    }
    for network in ipaddress.collapse_addresses(networks)
]
json.dump([{
    "IpProtocol": "tcp",
    "FromPort": 443,
    "ToPort": 443,
    "IpRanges": ranges
}], sys.stdout, indent=2)
' > ./google-site-verifier-ingress.json

生成したJSONを確認します。

python3 -m json.tool \
  ./google-site-verifier-ingress.json

AWS CLIの接続先アカウント、リージョン、対象Security Groupを確認してから、インバウンドルールを追加します。

AWS_REGION_VALUE="YOUR_AWS_REGION"
ALB_SECURITY_GROUP_ID_VALUE="YOUR_SECURITY_GROUP_ID"

aws ec2 authorize-security-group-ingress \
  --region "${AWS_REGION_VALUE}" \
  --group-id "${ALB_SECURITY_GROUP_ID_VALUE}" \
  --ip-permissions file://./google-site-verifier-ingress.json

追加したルールを確認します。

aws ec2 describe-security-group-rules \
  --region "${AWS_REGION_VALUE}" \
  --filters "Name=group-id,Values=${ALB_SECURITY_GROUP_ID_VALUE}" \
  --query "SecurityGroupRules[?Description=='Temporary Google Site Verifier'].{RuleId:SecurityGroupRuleId,CIDR:CidrIpv4}" \
  --output table

IPv6を利用している場合

ALBがdualstack構成の場合は、公式JSONの ipv6Prefix も確認し、Security GroupのIPv6ルールへ反映する必要があります。

執筆時点（2026年7月）の公式JSONには、IPv4とIPv6の両方が含まれています。ただし、構成に合わないアドレスファミリーを機械的に追加するのではなく、次の項目を確認してから適用してください。

  • DNSのA・AAAAレコード
  • ALBのIPアドレスタイプ
  • Security Groupのクォータと現在の使用状況

なお、この公式JSONはGoogle Site Verifier専用ではなく、Google管理のユーザー起点フェッチャーで使用されるIPレンジです。そのため、Security Groupの送信元制限だけに頼らず、次のALBルールで公開パスも限定します。

3. 所有権確認ファイル専用のALBルールを追加する

AWSマネジメントコンソールから、対象ALBのHTTPSリスナーへ一時ルールを追加します。

EC2
→ ロードバランサー
→ 対象のALB
→ リスナーとルール
→ HTTPSリスナー
→ ルールを追加

設定例は次のとおりです。

項目 設定例
ルール名 Temporary Search Console Verification
優先度 既存のアクセス制限ルールより先に評価される未使用値
ホストヘッダー example.com
パス /googlexxxxxxxxxxxxxxxx.html
アクション 対象のターゲットグループへ転送

ホストヘッダーとパスはAND条件にします。パスにはワイルドカードを使わず、Search Consoleから取得したファイル名へ完全一致させます。

優先度が高い一時ルール：
  example.com
  AND /googlexxxxxxxxxxxxxxxx.html
  → ターゲットグループへ転送

既存ルール：
  許可済みの送信元
  → ターゲットグループへ転送

デフォルト：
  固定レスポンス

ALBのリスナールールは、優先度の数値が小さい順に評価されます。一時ルールが既存のアクセス制限ルールより後ろにあると、確認ファイルまで到達しない可能性があるため注意してください。

条件や優先度の仕様は、AWSのリスナールール追加手順で確認できます。

既存のアクセス制限ルール、デフォルトアクション、WAF設定は変更しません。

4. Search Consoleで所有権を確認する

一時設定を追加したら、Search ConsoleでHTMLファイル方式の「確認」を実行します。

確認に成功したら、次の状態まで確認します。

  1. 対象プロパティの所有権確認が完了している
  2. 必要なGoogleアカウントへ適切な権限を付与できている
  3. 追加したアカウントで対象プロパティを開ける

複数人で運用する場合は、共有アカウントへ依存せず、Search Consoleの「ユーザーと権限」から各利用者を追加します。

所有者とフルユーザーでは実行できる操作が異なります。Googleの権限一覧を確認し、必要最小限の権限を付与してください。

5. 確認後の一時設定をどうするか決める

HTMLファイル方式では、Googleが確認トークンを定期的に再確認します。そのため、所有権確認の成功後に一時ALBルールとSecurity Groupルールを削除すると、公開前の期間中はGoogleが確認ファイルへ再アクセスできなくなり、一定期間後に所有権が失効する可能性があります。

確認後の運用は、次のどちらかに決めておきます。

一般公開まで所有権を維持する場合

確認ファイルだけを許可する一時設定を維持し、サイトの一般公開時に削除します。

公開までの期間が長い場合は、Googleの公式IPレンジが更新される可能性も考慮してください。長期運用では、HTMLファイル方式を一時対応とし、DNS方式などアクセス制限に依存しない確認方法へ切り替えることも検討します。

確認後すぐにアクセス制限を戻す場合

一時設定を削除し、一般公開後に所有権の状態を確認します。必要に応じて、再度所有権を確認します。

削除するときは、最初に所有権確認用の一時ALBリスナールールだけを削除します。既存の送信元制限ルールやデフォルトルールを誤って削除しないよう、ルール名、条件、優先度を確認してから操作してください。

続いて、Security Groupへ追加したルールを削除します。追加時に生成したJSONをそのまま使えば、対象を限定して一括削除できます。

aws ec2 revoke-security-group-ingress \
  --region "${AWS_REGION_VALUE}" \
  --group-id "${ALB_SECURITY_GROUP_ID_VALUE}" \
  --ip-permissions file://./google-site-verifier-ingress.json

削除結果を確認します。

aws ec2 describe-security-group-rules \
  --region "${AWS_REGION_VALUE}" \
  --filters "Name=group-id,Values=${ALB_SECURITY_GROUP_ID_VALUE}" \
  --query "SecurityGroupRules[?Description=='Temporary Google Site Verifier']" \
  --output json

結果が [] であれば削除完了です。最後に、ローカルの一時JSONファイルも削除します。

rm ./google-site-verifier-ingress.json

確認ファイル自体は、所有権を維持する間はWebサーバー上に残します。

完了チェック

  • Search Consoleの所有権確認が成功している
  • 必要なユーザーが対象プロパティへアクセスできる
  • 一時設定を維持するか、すぐに戻すかを決定している
  • 削除する運用の場合、一時ALBリスナールールを削除している
  • 削除する運用の場合、Google向けに追加したSecurity Groupルールを削除している
  • 0.0.0.0/0 や ::/0 の意図しない許可が残っていない
  • ローカルの一時JSONファイルを削除している
  • 所有権を維持する間、確認用HTMLファイルをWebサーバー上に残している

トラブルシューティング

VPNへ接続しても解決しない

Search Consoleで「確認」を押したときのリクエストは、操作しているPCではなくGoogleのサーバーから送信されます。

そのため、操作端末をVPNへ接続して確認ファイルへアクセスできても、Google Site Verifierが同じ経路を利用できるわけではありません。

Security Groupを許可しても確認に失敗する

Security Groupが制御するのは、ALBへ到達するまでの通信可否です。ALBへ到達した後にも、WAFやリスナールールなど別の判定があります。

次の順番で、リクエストがどこまで到達しているかを確認します。

  1. DNSが対象ALBを参照しているか
  2. ALBのSecurity GroupがGoogleからのリクエストを許可しているか
  3. WAFが対象リクエストを遮断していないか
  4. 一時ALBルールが既存のアクセス制限ルールより先に評価されているか
  5. ターゲットグループが正常か
  6. Webサーバーが確認ファイルへHTTP 200を返しているか

Webサーバーのアクセスログに何も残らない

ALBの固定レスポンスで処理が完了した場合、リクエストはターゲットグループへ転送されません。そのため、Webサーバーのアクセスログだけを確認しても原因を特定できません。

ALBアクセスログ、WAFのサンプルリクエスト、リスナールールの評価順も確認してください。

Security Groupのルール上限に収まらない

Googleの公開IPレンジは変動し、Security Groupにはルール数のクォータがあります。

上限に収まらない場合は、安易に全IPアドレスを許可せず、次の方法を検討します。

  • DNS方式など、ネットワークの一時開放を必要としない所有権確認方法へ変更する
  • AWSのクォータと現在の使用状況を確認する
  • 公開経路やアクセス制限の設計自体を見直す

まとめ

IP制限中のサイトでSearch Consoleの所有権を確認するときは、GoogleのIPレンジをSecurity Groupで許可するだけでは不十分な場合があります。

今回のポイントは次の3つです。

  • アクセス制限がSecurity Group、WAF、ALBリスナー、Webサーバーのどこにあるかを分解して確認する
  • Google公式IPレンジと、ホスト名・所有権確認ファイルの完全一致パスを組み合わせて公開範囲を絞る
  • 所有権確認後は、Googleによる定期的な再確認を考慮して、一時設定を維持する期間を決める

本番公開前のアクセス制限を維持したまま、外部サービスからの到達だけを許可したい場合は、「誰から」「どのパスへ」「いつまで」を分けて設計すると、安全に作業しやすくなります。

参考

3
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?