SaaSのIP許可リスト変更管理|拠点・VPN・外部連携を止めない更新手順
SaaSの管理画面やAPIを接続元IPで制限している環境では、拠点移転、回線更改、VPN出口の変更、プロキシ更新、クラウドNATの切替が、そのまま業務停止につながります。新しい固定IPを登録するだけでは、在宅勤務者、予備回線、外部委託先、バッチ処理、Webhook受信後の折り返し通信など、見えていない経路を取りこぼします。
安全な変更は、利用者・管理者・API・外部連携の接続元を棚卸しし、新旧IPを一時的に併用したうえで、経路別の業務結果とログを確認し、切り戻し条件を保ったまま旧IPを削除する流れです。IP許可リストは製品ごとに意味が異なります。本人確認を省略する信頼済み範囲、範囲外ログインを拒否する制限、条件付きアクセスポリシーの場所条件を同じものとして扱わないことが出発点です。
本記事のポイント
- 変更前は利用者・管理者・API・バッチ・委託先を接続元の公開IPv4・IPv6、対象SaaS、所有者へひも付けて棚卸しします。
- 新旧IPを一時的に併用し、通常ログインだけでなく特権管理、APIの業務反映、低頻度処理、予備回線を経路別に検証します。
- 旧IPは新IPの疎通だけで削除せず、旧経路への正規依存がゼロと確認し、削除後の再テストと台帳更新まで行います。
変更前に接続元と製品ごとの制御範囲を棚卸しする
最初に確認するのはIPアドレスの一覧ではなく、どの人・端末・処理が、どの出口から、どのSaaS機能へ接続しているかです。社内LANからのブラウザ利用だけを見ても、VPN経由の在宅勤務、モバイル回線、予備回線、拠点間ネットワーク、クラウド上のジョブ、CI/CD、iPaaS、委託先の固定IPが残ります。SaaS側のサインインログやAPIログ、プロキシ、VPN、NAT、ファイアウォールのログを突き合わせ、観測できた接続元と契約・構成上存在する接続元を分けて記録します。
台帳には、公開IPv4・IPv6またはCIDR、経路の名称、利用者・システム、対象SaaS、対象機能、所有者、回線・クラウド資源、変更日、確認方法、予備経路、旧IP削除条件を残します。NAT配下の端末から見えるプライベートIPではなく、SaaS側が実際に観測する公開送信元を登録します。IPv4だけを切り替える計画でも、端末や回線がIPv6を優先していないかを確認します。
製品の設定名だけで制御の強さを判断してはいけません。Salesforce Trailheadでは、組織の信頼済みIP範囲は異なるIPからのログイン時に求められる本人確認を省略する用途として説明される一方、プロファイルのログインIP範囲はログインできる場所を制限します。OktaのNetwork ZoneはIPアドレス、IP種別、地理的位置、CIDR、ASNなどで境界を定義し、サインオンポリシーやルーティングルール等で使います。Microsoft Entraの条件付きアクセスでは、場所は公開IPまたはAuthenticatorが提供するGPS情報で判定され、Named locationsをポリシー条件として利用します。
| 棚卸し対象 | 見落としやすい経路 | 確認する証拠 | 変更時の責任者 |
|---|---|---|---|
| 利用者ログイン | 在宅VPN、出張、予備回線、モバイル、IPv6 | サインインログ、VPN接続ログ、予定利用者 | SaaS管理者・ネットワーク担当 |
| 特権管理 | 緊急管理アカウント、委託管理者、別拠点 | 管理者一覧、MFA、緊急経路のテスト | 情報システム責任者 |
| API・バッチ | クラウドNAT、CI/CD、iPaaS、夜間ジョブ | APIログ、NAT・プロキシログ、実行履歴 | アプリ・連携担当 |
| 外部委託先 | 委託先VPN、共有出口、再委託、保守端末 | 契約範囲、接続申請、最終利用、期限 | 委託元・委託先責任者 |
| 障害時の代替 | バックアップ回線、別リージョン、手動運用 | 切替試験、連絡網、利用期限、復旧手順 | 変更責任者・承認者 |
Google Workspaceのコンテキストアウェアアクセスでは、アクセスレベルの条件として公開IPサブネットのIPv4・IPv6・CIDRを指定できます。既にGoogle Workspaceで場所や端末条件を組み合わせている場合は、コンテキストアウェアアクセスの設計と段階適用も確認し、IP変更だけで他の端末条件や組織部門への割り当てを崩さないようにします。
IPは有効な制御材料ですが、IPだけで正規利用者や安全な端末を証明できるわけではありません。NIST SP 800-207は、ネットワーク上の場所だけを理由に資産や利用者へ暗黙の信頼を与えない考え方を示しています。管理者MFA、端末状態、アカウントの役割、アプリの機密度、セッション監視と組み合わせ、許可IP内なら無条件に安全という設計にしないことが重要です。
新旧IPの併用期間と切り戻し条件を先に決める
切替計画は「新IPを追加し、問題がなければ旧IPを削除する」だけでは不十分です。新旧を併用できるか、設定反映にどの程度の時間差があるか、一つの範囲を編集するのか別範囲として追加するのか、同時登録数やCIDRの制限があるかを製品ごとに確認します。既存範囲を上書きすると、保存直後から旧経路が使えなくなる製品もあるため、可能なら新しい範囲を別項目として先行登録します。
併用期間は一律の日数ではなく、すべての正規経路が少なくとも一回は新IPから動作し、旧IPへの依存が観測できる期間を含むように決めます。常時利用の管理画面は当日確認できますが、月次バッチ、週次同期、障害時だけ使う予備回線は通常業務の観測だけでは判定できません。頻度が低い処理は、変更窓の中で明示的にテストするか、旧IP削除を次の実行確認後まで保留します。
切り戻し条件は作業前に数値と事象で固定します。たとえば、管理者が二つ以上の独立経路からログインできない、主要APIの成功率が通常範囲を下回る、認証エラーが連続する、外部連携の業務データが反映されない、SaaS側ログに想定外の旧IPまたは未知のIPが出る場合です。「担当者が不安を感じたら」ではなく、誰がどの証拠で中止・切り戻しを決めるかを明記します。
| 判断項目 | 変更前に決めること | 合格証拠 | 切り戻しの例 |
|---|---|---|---|
| 設定方法 | 新規範囲の追加か既存範囲の編集か | 新旧IPが同時に登録されている画面・API結果 | 旧設定を保存済み値へ戻す |
| 管理者経路 | 主経路と独立した緊急ログイン方法 | 別回線・強い認証での管理ログイン | 緊急経路から旧IPを再登録 |
| 利用者影響 | 対象グループ、拠点、勤務形態、問い合わせ窓口 | 代表利用者のログインと主要操作 | 対象ポリシーの除外または旧経路復帰 |
| API・連携 | テスト対象、期待結果、再送可否、停止許容時間 | HTTP成功だけでなく業務データの反映 | NAT・プロキシ・許可範囲を旧構成へ戻す |
| 旧IP削除 | 最低観測期間、低頻度処理、最終承認者 | 旧IP利用ゼロと全経路の新IP成功 | 削除を延期し、依存経路を追加調査 |
API連携の変更では、IP制限以外の秘密情報や署名検証も同時に動かすと原因切り分けが難しくなります。APIキーを更新する場合はAPIキーの棚卸し・ローテーション手順、Webhookの署名secretを変える場合はWebhook署名シークレットの段階切替として別の変更に分けます。IP、認証情報、アプリ設定を同じ窓で一括変更しないことが、短い切り戻しにつながります。
7ステップで新しい送信元へ切り替える
- 変更対象と凍結範囲を確定する。対象SaaS、ポリシー、利用者、拠点、VPN、プロキシ、NAT、API、委託先を一覧にし、変更窓の間に別担当者が同じ許可リストやネットワーク出口を変更しないよう担当を固定します。
- 現行設定と実ログを保存する。現在のIP・CIDR、設定の意味、割り当て先、優先順位、最終更新者を取得します。画面のスクリーンショットだけでなく、可能なら設定エクスポートやAPI応答、サインイン・APIログを保存します。
- 新しい公開送信元を事前確認する。回線事業者やクラウド設定表の値だけでなく、予定するVPN・プロキシ・NATを経由した確認通信で外部から見えるIPv4・IPv6を確認します。複数出口や自動フェイルオーバーがある場合は全経路を試します。
- 新IPを旧IPと並行登録する。影響の小さい範囲またはテストグループから追加し、設定反映を確認します。範囲外を拒否する制御では、緊急管理経路を先に確保してから保存します。
- 接続元別に業務結果まで試験する。通常利用者、特権管理者、API、バッチ、iPaaS、委託先、予備回線から接続し、ログイン成功だけでなく検索、更新、ファイル、通知、データ同期、再送など主要処理の完了を確認します。
- 監視しながら主経路を新IPへ切り替える。SaaSのサインイン・監査・APIログ、VPN・プロキシ・NATログ、業務監視を同じ時間軸で確認します。未知のIP、旧IPの継続利用、認証エラー、処理遅延があれば削除へ進みません。
- 旧IPを削除し、もう一度全経路を確認する。低頻度処理と障害時経路を含む完了条件を満たした後、承認を得て旧IPを削除します。削除後も管理者・利用者・API・外部連携を再テストし、台帳、構成図、監視、委託先の申請情報を更新します。
管理画面ログインの試験は、現在ログイン済みのブラウザでページを開くだけでは不十分です。新しいセッション、対象ユーザー、対象端末、想定するMFAで認証をやり直し、ポリシーが評価されたログを確認します。APIはHTTP 200だけで合格にせず、対象レコードの作成・更新、ファイル取得、後続ジョブ、重複防止、エラー再送まで見ます。
SAMLやSSOを使うSaaSでは、IP変更による認証失敗と証明書・メタデータの問題を混同しないようにします。証明書更新を伴う場合はSAML署名証明書の更新と切り戻しを別計画にし、IP変更の試験では現行のIdP・SP設定を固定します。
| 試験経路 | 最低限の操作 | 確認ログ | 失敗時に疑う点 |
|---|---|---|---|
| 一般利用者 | 新規ログイン、閲覧、更新、ファイル操作 | サインイン、ポリシー判定、監査ログ | 別出口、IPv6、対象グループ、条件の優先順位 |
| 特権管理者 | 新規ログイン、設定閲覧、緊急経路 | 管理操作、MFA、リスク・場所判定 | 範囲外拒否、緊急アカウントの対象漏れ |
| API・バッチ | 認証、読取、更新、後続処理、再送 | API、NAT、ジョブ、業務データ | 別NAT、非同期処理、古い実行環境 |
| 外部委託先 | 契約範囲内の操作と終了確認 | 接続申請、SaaSログ、委託先確認 | 共有VPN、再委託、申請と実IPの差 |
| 予備回線 | フェイルオーバー、管理者ログイン、主要業務 | 回線切替、公開IP、SaaS判定 | 予備側の未登録IP、DNS・プロキシ差 |
旧IP削除後もログ・期限・例外を閉じる
旧IPの削除前に、SaaS側で旧IPからの正規アクセスがゼロであることを確認します。ただし「ログにない」ことだけで安全とは言えません。月次処理や障害時だけ使う経路が観測期間中に動いていない可能性があるため、台帳上の全経路にテスト結果または廃止証拠が必要です。所有者不明の経路は、正常と推定して削除するのではなく、隔離、追加調査、期限付き保留のいずれかへ明示的に分類します。
IP許可リスト変更の完了は、新しいIPからログインできた時ではなく、旧IPに依存する正規経路がゼロだと確認してから旧範囲を削除できた時です。
削除後は、許可リスト、条件付きアクセスポリシー、ネットワーク構成図、VPN・プロキシ・NAT台帳、監視対象、委託先申請、障害対応手順を同じ変更番号へひも付けます。旧IPを期限なしの例外として残すと、後から第三者へ再割り当てされたアドレスや、廃止した委託先経路を許可し続けるおそれがあります。やむを得ず残す場合は、対象機能、所有者、理由、期限、補完統制、次回確認日を設定します。
IP範囲を広くして障害を回避する方法は、原因切り分けを難しくし、許可範囲を恒久化しがちです。ログで必要な送信元を確定し、最小のCIDRへ戻します。Webアプリ側のWAFや例外ルールも同時に見直す場合は、WAFを観測から段階導入する方法のように、まずログで影響を確認してからブロックへ移行します。
よくある質問
SaaSのIP許可リスト変更前にどの接続元を棚卸ししますか?
社内LANだけでなく、在宅VPN、予備回線、モバイル、IPv6、特権管理者、クラウドNAT、プロキシ、API・バッチ、CI/CD、iPaaS、外部委託先を棚卸しします。SaaS側が実際に観測する公開送信元と、利用者・システム・所有者・対象機能を結び付けます。
新旧の送信元IPをどの期間併用しますか?
一律の日数ではなく、すべての正規経路が新IPから少なくとも一回成功し、旧IPへの依存がないと確認できる期間を確保します。月次処理や障害時経路は通常の観測だけで判定せず、明示的に試験するか次回実行まで旧IP削除を保留します。
管理画面ログインとAPI連携をどうテストしますか?
管理画面は新しいセッションで対象ユーザー・端末・MFAを使ってログインし、ポリシー判定ログを確認します。APIは認証とHTTP応答だけでなく、読取・更新、後続ジョブ、業務データ反映、再送まで確認し、SaaSログとNAT・プロキシログを同じ時刻で照合します。
IP変更で接続できないときにどう切り戻しますか?
独立した緊急管理経路から旧IPを再登録するか、ネットワーク出口を旧構成へ戻します。作業前に現行設定、旧CIDR、対象ポリシー、NAT・VPN構成を保存し、誰がどのエラー率・業務影響で切り戻すかを決めておきます。
IP許可リストだけでSaaSを安全にできますか?
十分ではありません。共有出口の内側にある未管理端末や侵害済みアカウントはIPだけでは区別できません。MFA、端末状態、最小権限、アプリの機密度、セッション監視と組み合わせ、ネットワーク上の場所だけで暗黙に信頼しない設計にします。
旧IPをすぐ削除できない場合はどう管理しますか?
放置せず、対象機能、依存する処理、所有者、残す理由、補完統制、削除期限、次回確認日を記録します。アクセスログを監視し、依存処理の移行または廃止を完了させ、承認後に最小範囲へ縮小して削除します。
製品ごとの公式仕様を確認する
- Salesforce Trailhead:組織へのアクセスを制御する
- Okta Documentation:Network zones
- Okta Documentation:Manage network zones
- Microsoft Learn:Conditional Access network assignment
- Google Workspace 管理者ヘルプ:コンテキストアウェアアクセス レベルを作成する
- Google Workspace 管理者ヘルプ:アクセスレベルをアプリに割り当てる
- NIST SP 800-207:Zero Trust Architecture
- Microsoft Learn:Azure NAT Gateway overview
SaaSのIP許可リストは、一度決めて終わる境界ではありません。接続元の所有者と利用目的を見える状態にし、新旧経路を重ねて試し、ログと業務結果で旧経路の終了を判断できれば、拠点やVPN、クラウド構成を変えても管理画面と外部連携を止めにくくなります。