ワークフローのIPアドレス制限は1つの設定では足りない

ワークフローのIPアドレス制限は、どこまで閉じればいいのか

ワークフローの本番稼働を来月に控え、情報セキュリティ部門から条件が1つ付く。社外からの利用は認めない。

管理画面にはIPアドレス制限の設定があります。ただし、この制限は1つかけて終わりではありません。どの入口から来た接続かと、どこで判定するかで、かかり方が変わります。

許可する範囲を入れて保存するだけ、と思って画面を開いて、承認者の顔ぶれを思い出したところで手が止まります。営業本部長は外出が多く、金額の大きい稟議はその段を通ります。社外を閉じたときにいちばん影響が出るのは、この段です。

許可するIPを固定の出口に寄せる、という定番の答えはよく効きます。それでも、有効化した日に自分で入れなくなる事故と、社外を閉じたのに承認が通る道は残ります。

本記事では、ワークフローのIPアドレス制限を入口と操作の2つの軸で並べ直します。どこまで閉じるかを決めるときの、たたき台として使ってください。

ワークフローのIPアドレス制限は、どこにかかりますか

かかる先は、接続してくる入口と、判定を行う場所の2つに分かれます。入口はブラウザ、モバイルアプリ、連携経由の3つ。判定を行う場所は、IdP側とワークフロー側の2つです。

ワークフローのIPアドレス制限とは、接続元のグローバルIPアドレスを見て、許可した範囲以外からの操作を遮断する仕組みです。判定するのはログインの時点だけという製品もあり、操作のたびに判定する製品もあります。

本記事では、次の環境を通し例として使います。1,200名の企業で、来月からワークフローを本番稼働させる。国内に拠点が十数か所あり、在宅勤務は週2日まで。自宅からはVPNで社内を経由します。営業本部長は週の半分が外出で、300万円を超える購買の稟議は規程で本部長決裁。人事システムとは夜間のバッチで連携していて、組織と所属が毎朝流れてきます。

1つ目の入口は、ブラウザです。 社内からなら社内の出口IP、在宅からならVPNの出口IP。ここは想像しやすく、許可リストにも入れやすい入口です。

2つ目は、モバイルアプリです。 携帯回線から出れば、社内のIPではありません。社外からの利用を認めないなら、モバイルは実質使えなくなります。

3つ目は、連携経由です。 人事システムからのアクセスは、そのサーバのIPで来ます。ここには、人の操作も混じります。チャットの通知に載った承認ボタンを押したとき、その操作は連携基盤からワークフローへサーバ間で届きます。押した本人が空港にいても、ワークフローから見えるのは連携基盤のIPです。

つまり、社外からの利用を閉じたつもりでも、この道は通ります。塞げるかどうかは、連携経由の操作をIPアドレス制限の対象にできるかによります。

確かめ方は、制限の対象にできるかを聞くより、連携経由の操作が何のIPとして記録されるかを聞くほうが早くなります。連携基盤のIPで記録されるなら、その基盤のIPを許可リストに載せない限り、連携そのものが動きません。載せた時点で、そこを通る承認も一緒に通ります。

判定を行う場所は、これとは別の軸です。SSOを使っていると、認証そのものはIdP側で終わります。IdPにもIPアドレス制限の機能があるため、同じ制限を2か所に置ける状態になります。IdPは入口が増える場所ではなく、判定が入る場所が増える場所です。

どちらか一方でよいのですが、両方に入れている企業もあります。拠点を追加したときに片方だけ直して、もう片方で弾かれる。原因の切り分けに時間がかかるのは、この形です。

通知のリンクは、入口として別に立ちません。通知そのものは制限の外側なので、社外にいても届きます。ただし、リンクを開くのはブラウザなので、開いた先で1つ目に当たります。通知は届くのにリンクだけ開けない、という体験が生まれるのはこのためです。

入口ごとに分けてかけられない製品では、連携元のサーバIPと社内の出口IPが同じ一覧に並びます。連携のために1行足すと、そのIPからは人も入れます。

設定を有効化すると、誰が締め出されますか

いま自分が使っているIPが許可リストに入っていなければ、設定した本人が入れなくなります。いつそうなるかは、判定のタイミングで違います。

有効化する時期は、たいてい本番移行の直前です。トライアルで何を確かめるかは、ワークフローのトライアルは、何を確かめる30日かで整理しています。

事故の形は、いつも同じです。許可リストに社内の出口IPを入れて保存する。設定していた本人は、その日は自宅から入っていた。保存してリロードすると、もう入れません。

ログインの時点だけ判定する製品では、その日は何も起きません。 すでに通っているセッションはそのまま使えるため、正常に設定できたように見えます。発現するのは翌朝のログインで、しかも自宅から試した人だけ。気づくのが遅れるぶん、こちらのほうが厄介です。

保存する前に警告を出す製品もありますが、無ければ操作としてそのまま成立します。

戻し方を自社に残せるかどうかは、製品が管理の操作を別扱いにできるかによります。管理者が全員同じ条件で入れなくなれば、直せる人が誰もいません。ベンダーへの依頼になり、そのあいだ設定は凍ります。

この事故は、起きてから直すのではなく、起きない形を先に作るしかない側です。 置ける手は3つあります。

1. 有効化の操作を社内から行う
2. 社内と自宅の両方を許可リストに入れておく
3. 管理の操作を別扱いにできるかを、選定のときに見ておく

許可リストに書くIPは、自社で決められますか

クラウドプロキシやSASEを経由している場合、許可リストに書くIPは自社のものではありません。サービス側が公開しているレンジで、予告付きで変わります。

自社のネットワークを何も変えていなくても、許可リストが合わなくなる。原因が外側にある型です。

レンジの変更通知は、たいていネットワークの担当者側に届きます。ワークフローの許可リストを直すのは情シスの別の人。その2つがつながっていないと、変更の日に朝から入れなくなります。

もう1つ、レンジの広さの問題があります。共用の出口を使っている場合、そのレンジからは同じサービスを使う他の利用者も出てきます。 遮断できているのは、自社と無関係な範囲だけになる可能性もあります。

固定のグローバルIPに出口を寄せられるなら、ここは消えます。

社外から承認できないと、何が止まりますか

止まるのは承認と、急ぎの参照です。申請と管理設定はほとんど社内で起きるので、社外を閉じても表に出てきません。

申請は席で書くもので、社外での起票は出張中の経費精算くらいです。管理設定は社外から開ける必要が薄く、社内のIPだけに限りたい操作です。

承認は、逆です。承認者は役職が上がるほど席にいません。営業本部長の段に来た稟議は、本部長が外出しているあいだ待ち続けます。

参照は、過去の申請を開く操作です。監査法人とのやり取りや、社外での問い合わせ対応で必要になります。頻度は低く、しかし必要なときは急ぎます。

承認が止まっても、申請が消えるわけではありません。翌朝に本部長が席に着けば、そこから動きます。代理承認を置く、一定の期間で上位者へ引き上げる、社外を許すロールを別に作る。運用でも設定でも軽減できます。承認の停止は、対策できる側です。

参照は、移せません。 監査法人と対面している場で過去の稟議を開くのは、その人がその場でやるしかない操作です。代理を立てる先がありません。外に出る頻度は低いのに、対策の置き場所が無いのは参照のほうです。

ここまでの整理には、抜け道が1つあります。連携経由の操作です。承認が止まらないのは良いことに見えて、要件の側から見れば、閉じたはずの経路が開いている状態です。

弾かれたアクセスの記録は、後から作れますか

作れません。拒否されたアクセスのログが残るかどうかは製品ごとに違い、残らない場合でも証跡は作れますが、作れるのは有効化のときだけです。

監査で問われるのは、アクセス制限を設定していたかどうかだけではありません。その期間、実際に社外からのアクセスがなかったかどうかも聞かれます。設定画面の画像は、前の問いの答えにしかなりません。

後の問いに答える道は、3つあります。

1. 拒否されたアクセスのログを出す
2. 許可されたアクセスの記録を出して、接続元のIPが全件許可した範囲に入っていることを示す
3. 有効化の日に社外から接続し、弾かれることを確認した記録を残しておく

拒否のログが残らない製品では、2と3で組みます。

なお、拒否のログの件数がゼロだったとしても、それだけでは証跡になりません。社外から試した人がいなかったのか、記録されていないだけなのかを区別できないためです。

不可逆なのは、後から遡って弾かれた事実を作れない一点です。 有効化のときに接続テストの記録を残しておけば埋まりますが、半年後には作れません。

問題が起きる時点と、手を打てる最後の時点は、同じではありません。いちばん離れているのが、監査で問われる証跡です。問われるのは半年後で、手を打てるのは有効化の日しかありません。

社外を閉じるやり方は、何通りありますか

一律で閉じる、操作で分ける、入口で分ける。3つのどれかになります。いちばん軽いものはありません。

セキュリティのチェックシートに並ぶ「IPアドレス制限：可」の1行は、この3つのどれができるのかを区別しません。要件を満たせるかどうかは、その1行では決まりません。 比較表の項目が揃ってしまう理由は、比較表の○が揃ってしまう4つの領域で扱っています。

本番移行の1か月では、何が起きましたか

許可リストを作るところまでは、表を埋める作業でした。詰まったのは、その後です。

移行の2週間前。 社内の出口IPとVPNの出口IPを並べて、許可リストの原案を作りました。

移行の前日。 制限を有効化しました。翌朝、人事システムからの夜間バッチが落ちていました。連携元のサーバIPが一覧に入っておらず、連携経由のアクセスも制限の対象だったためです。

移行の初週。 営業本部長の承認が2件止まりました。空港で通知メールのリンクを開いて、そこで弾かれています。通知そのものは届いていました。

移行の1か月後。 社外を許すロールを別に作りました。承認だけを社外から通せる形に変えて、申請と管理設定は社内のIPだけに残しています。切り替えを一度に行うか段階を踏むかについては、新システムへの切り替えは「一斉リリース」か「段階リリース」どちらが良いのかで扱っています。

半年後。 内部監査で、期間中に社外からのアクセスがなかったことを示す資料を求められました。拒否されたアクセスのログは残っていませんでした。許可されたアクセスの記録を全件洗って、接続元のIPが許可した範囲に収まっていることを示す形になりました。

社外からの承認を認めるかどうかは運用の話であり、制限をかけるかどうかを先に決めれば代理承認や引き上げで吸収できる、という見方があります。しかし運用で吸収できるのは止まった申請までです。証跡は、有効化の手順に織り込むしかありません。

なお、どの入口に分けてかけられるか、拒否のログが残るかは仕様として確かめられる話です。一方、社外での承認をどこまで認めるかは、情報セキュリティの規程を持っている側でしか決まりません。

まとめ

IPアドレス制限を1つの設定として考えると、入口の数だけ抜けが残ります。

• かかる先は入口と判定点に分かれる。入口はブラウザ・モバイルアプリ・連携経由の3つで、IdPは入口ではなく判定が入る場所
• 連携経由には人の操作も混じる。チャットから承認できる形が有効なら、社外を閉じても承認は通る
• 有効化で締め出されるかは判定のタイミングで違う。ログイン時だけ判定する製品では、翌朝まで気づかない
• 社外を閉じて止まるのは承認と急ぎの参照。承認は代理承認や引き上げで移せるが、参照は移せない
• 拒否されたアクセスの記録は後から作れない。残らない製品では、有効化の日の接続テストが証跡になる

社外を閉じるかどうかを決める前に、入口を並べて、どれを分けてかけられるかを見ておくことになります。

よくある質問

チャットや通知メールから承認できる形は、IPアドレス制限で止まりますか

止まらない製品があります。チャットの承認ボタンやメールの返信で承認する形では、操作が連携基盤からサーバ間で届くため、押した人の接続元は見えません。社外からの利用を認めない要件を立てているなら、連携経由の操作を制限の対象にできるかを確かめることになります。対象にできない場合に取れる手は、その連携機能を使わない設定にするか、承認だけは連携経由でも認めると規程の側で書くかのどちらかです。

IdP側でIPアドレス制限をかけていれば、ワークフロー側は不要ですか

認証の入口を絞るだけなら足ります。分かれるのは、認証を通った後です。IdPが判定するのはログインの時点なので、その後にセッションが続いているあいだは判定が入りません。操作のたびに接続元を見る形を要件に含めるなら、ワークフロー側にも要ります。

モバイルアプリだけ、社外から使えるようにできますか

入口ごとに分けてかけられる製品なら選べます。ブラウザは社内のIPだけに限り、モバイルアプリは社外からも通す形です。ただし、そのぶん端末を管理する話が別に立ちます。紛失したときにアクセスを止める手段をどこに置くかは、ワークフローの外側で決めることになります。