「〇〇サービスの管理画面が外部からアクセスできるようになっていました」いつ聞いてもドキッとする事例です。 今回は、外部からアクセスできるべきでないサイトを監視するジレンマについて考えてみます。
外部からアクセスできないことを担保するとは
パブリックなサイトについて、アクセスができていることを監視する手段はいくつかあります。HTTPならレスポンスコードで確認できますし、TCPならセッション成立できるかで確認できます。アクセスできない = HTTPでのアクセスができなければ満たされます。
- HTTP(S)でのアクセス(L7): レスポンスコードで確認
- TCP, UDPでのアクセス(L4): セッション成立で確認
- ICMPでのアクセス(L3): パケットが届くかで確認
- DNS: ドメイン解決できるかの確認
では外部からアクセスさせたくない社内用のサイトなどを、外部からアクセスできないことを担保するにはどうすればいいでしょうか。監視サービスに「成功失敗の逆転判定」があれば一番簡単です、最高!しかしそんな都合のいいことはなく、例えばDatadogのSyntheticMonitoringに逆転判定はありません。
ということで、逆転判定がない場合に外部からアクセスできないことをどう担保するかが今回のテーマです。
逆転判定がない状態で外部からアクセスできないことを監視する
外部からアクセスできるか監視は「アクセスできることを成功」とすればよいのに対して、外部からアクセスできないこと監視は「アクセスできないことを成功」とします。どのようにアクセスできなくするか、インフラ管理の視点とアプリケーションの視点で考えてみます。
インフラ管理の視点でアクセスできないようにする
インフラ管理の視点でアクセスできないようにするなら、ファイアウォールでアクセスを拒否するが基本です。いわゆるセキュリティグループなどで、TCPに対してIP制限をかけることで外部からのアクセスを拒否します。パブリックネットワークならこのようになります。
| アクセス方法 | アクセスできるか | 備考 |
|---|---|---|
| HTTPでのアクセス | × | TCPで拒否されるのでアクセスできない |
| TCPでのアクセス | × | TCPで拒否されるのでアクセスできない |
| ICMPでのアクセス | × | そもそも許可しないのでアクセスできない |
| DNS | 〇 | ドメイン解決はできる |
もう少しネットワークアーキテクチャで解決する方法としては、DNS解決+IP制限という手もあります。例えばVPNや社内からのみアクセスできればよくネットワーク整備できているなら、サイトをプライベートDNSに登録して、プライベートIPでアクセスできるようにするという方法です。そもそも外部からのアクセス経路がないので、外部からアクセスできないことを担保できます。
| アクセス方法 | アクセスできるか | 備考 |
|---|---|---|
| HTTPでのアクセス | × | 外部に公開されていない |
| TCPでのアクセス | × | 外部に公開されていない |
| ICMPでのアクセス | × | 外部に公開されていない |
| DNS | × | 社内DNSでのみ解決できる |
IP制限で防御するのはいわゆる境界型防御の考え方です。境界型防御は侵入された場合に内部からのアクセスは制約かけることが抜けがちなため、そもそもポリシーベースでアクセスコントロールを行うことも検討できるでしょう。とはいえ、いったん手法としてはここまでで出そろっていますね。インフラ視点で外部アクセスさせないなら次のようになります。
- TCPレベルでIP制限する
- プライベートネットワークに配置して、アクセスも内部から完結させる
インフラ管理の視点では「なるべく低いレイヤーでアクセスを拒否する」ことを優先的に選びます。これはネットワーク監査もしやすく、AWS Configなどクラウドポリシーチェックツールでも違反検知しやすいので自然な選択でしょう。
アプリケーションの視点でアクセスできないようにする
アプリケーション視点でアクセスできないようにするなら、HTTPリクエストに対してアクセスを拒否するが思いつきます。いわゆるWAFやHTTPリスナーなどで、リクエスト元に対してIP制限をかけることをで外部からのアクセスを拒否します。1パブリックネットワークならこのようになります。
| アクセス方法 | アクセスできるか | 備考 |
|---|---|---|
| HTTPでのアクセス | × | WAFで拒否されるのでアクセスできない |
| TCPでのアクセス | 〇 | セッションが張れる |
| ICMPでのアクセス | × | そもそも許可しないのでアクセスできない |
| DNS | 〇 | ドメイン解決はできる |
WAF/HTTPリスナーにきたリクエストに対して制御するので、TCPレベルでは疎通できます。
アクセスできないことを監視する
視点を把握した上で、逆転判定がない外部アクセス監視サービスを用いて「外部からのアクセス監視ができない」ことを監視する方法を考えます。
インフラ視点
TCPレベルでアクセスを拒否しているなら、TCP/HTTP監視ともに失敗します。しかし逆転判定ができない場合、アクセスできないことを監視できません。2 ファイアウォールでアクセスを拒否している場合、TCP接続ができないことを監視できないんですよね。
アプリケーション視点
WAFやHTTPリスナーでアクセスを拒否しているなら、HTTPリクエストを送信してレスポンスコードで拒否されたか監視できます。例えば403や404が返ってきたら成功として監視できます。Datadogならこの手法で監視できます。
アプリケーション視点でWAFやHTTPリスナーでアクセスを拒否するなら、アクセスできないことが監視できますね。
頻度課題
アクセスできないことを担保するのは一定の頻度で実行できる必要があります。事故る時は意図しない時なので、例えばデプロイ時に1回だけじゃ意味が薄いのですね。常時ある程度の頻度で監視され続けるのがいいです。
外部からアクセスできるようにするジレンマ
外部からアクセスできないことを監視できないと、いずれ事故る、事故ったサービスはこれまで数多く見てきました。これに対する私の結論は「外部からアクセスできないことを監視するしかない」です。外部からアクセスできないことを担保するにはHTTP(L7)で拒否するしかない。インフラ的にはそもそもTCPレベルでアクセスできないようにIP制限すればいいのに!
これが、私が考える外部からアクセスできないことを監視するジレンマです。
WAFでIP制限されても、インフラ視点でみるとTCP的にはIP制限がかかってないので一見するとアクセスできる状態です。いくらWAF/HTTPリスナーでアクセスを拒否していても、TCPレベルでアクセスできるのは納得感がありません。ネットワークセキュリティポリシーは低レイヤーで解決するのが最も効率的で理由も説明しやすいので、「アクセス制限されているか確認しています。ファイアウォールが空いているようですが大丈夫ですか?」「HTTPリスナー/WAFでIP制限しています」「いや、ファイアウォールあいてますけど、なぜわざわざWAFで?」「アクセスできないことを外部から担保したいので」「ファイアウォールで閉じてもいいのでは?」「いえ、TCPで止められると監視できず... 省略」といったやり取りを100回ぐらいすることになります。そして、いずれ疲れてもういいや、ファイアウォールで拒否しよ。となるのですが、アクセスできないことを監視できなくなるので、何か手を見つけないと気づかないうちに「アクセスできる状態になっていました」となります。
他にどのような手があるか
ファイアウォールでTCPアクセスを拒否しつつ、アクセスできないことを監視する方法を考えます。
自前監視
外部からの監視サービスを使うのではなく、自前で監視すればいいです。自前処理なら、ファイアウォールであってもなんでもアクセスできなければ監視失敗として通知できます。ただ、マネージドサービスのようにお任せできなくなります。外部からのアクセスができないことをするサービスが増えるので、それがちゃんと動いているか監視する手間が増えるのはトレードオフです。適当にサーバーレスで実行すればいいものの、作った瞬間から負債です。作るのは簡単なのですが、運用が課題になりがちですね。
マネージドサービスで監視は難しい。逆転判定ください。
内部からしかアクセスできない設計
外部ネットワークにそもそも公開せず、内部ネットワークに閉じ込めるのもいいですね。最も望ましいですが、クラウド上のサービスならクラウドとオフィスをうまくつなぐなり、何かしらでトンネル掘るなりがんばる必要があります。会社としてレベルの制約がかかりやすいので、なかなか難しいケースも多いです。
軽減案
ファイアウォールなどでTCP接続をできなくして、「アクセスできないことを監視する」ことをあきらめた場合の軽減案も考えてみましょう。
定期的なペネトレーションテスト
そもそも外部からアクセスできないかのテストですね。課題は頻度とコストです。ペネトレーションテストをさくっと簡単に1hや5分に1回できるなら、単純にTCP接続できなくするのはアリです。
ログ分析監視
ファイアウォールなど防御層のログ分析です。ネットワークフローログ的なものになるとブロックしたログだけ分析する手間・頻度が課題になります。WAFとかならブロックしたログだけ出せたりしますが、フローログはそうもいかない。ログ分析を監視したい頻度程度まで高頻度に回せるならアリです。
まとめ
ジレンマ伝わりますかね。手は打てる、だがあっさり単純な方法が見つからない。悩ましいです。
