通信要件レビューで見ているのは「IPアドレス」ではない
インフラ系のレビューの中で、もっとも多いテーマのひとつが「通信要件の追加・変更」です。
新たな会社とのデータ連携が始まるとき。
相手先のEOSL対応でサーバIPが変更になるとき。
サービス追加に伴い、新しい通信経路を開ける必要があるとき。
そういった場面で、ファイアウォールやアクセス制御の設定変更が発生します。
インターネットを経由するフロント通信であっても、VPNや専用線を使うバック通信であっても、私が見る観点は基本的に同じです。
私が見ているのは、この2点だけ
① 通信元・通信先・ポートが「必要最低限」になっているか
② 通信経路または通信内容が暗号化されているか
今回は①について書きます。
「必要最低限」とは何か
通信レビューでよく出てくるのが、IPアドレスの範囲です。
例えば /32 という表記。
これはCIDR表記で「単一ホスト」を示します。
つまり、1つのIPアドレスだけを許可する設定です。
形式的には、/32 であれば「かなり絞っている」と言えます。
一方、/20 のように広いネットワーク範囲で開けたい、という申請が来ることもあります。
ここで難しいのは、
/32なら安全、/20なら危険、とは単純に言えないことです。
形式チェックと実質判断は違う
もちろん、
- IP範囲が過度に広くないか
- 不要なポートが開いていないか
- 双方向になっていないか
といった形式的なチェックは必要です。
しかし、もっと重要なのは、
そもそもその通信は業務上必要なのか？
という問いです。
/32であっても、業務的に不要な通信であれば、それは「必要最低限」ではありません。
逆に、/20であっても、
- 相手側のシステム仕様上どうしてもその範囲になる
- 業務継続のために合理的な理由がある
のであれば、許容される場合もあります。
つまり、「必要最低限」の定義は規程に明文化されているわけではなく、都度判断になります。
ここがレビューの難しさであり、面白さでもあります。
ドメイン指定は本当に安全か
最近は「IPではなくドメインで指定したい」というケースもあります。
一見すると、IPベタ書きよりも目的が明確で、業務との紐付けもしやすい。
しかし注意が必要です。
DNSで名前解決された結果、実際には広範囲のIPに到達可能になることがあります。
CDNを利用している場合は、実質的に世界中のIPが宛先になることもあります。
それでも私は、
- 業務との対応関係が明確
- 通信対象の意味が説明できる
という点で、ドメイン指定の方が「必要性の説明」はしやすいと感じています。
結局のところ、レビューはIPの数字を見ているのではなく、
その通信が業務として正当かどうか
を見ています。
通信を開けるということ
通信を許可するということは、システムに「穴を開ける」ということです。
それは外部攻撃のリスクにもなり得ますし、内部不正による情報持ち出しの経路にもなり得ます。
だからこそ、
- どこから
- どこへ
- 何のために
という説明ができるかどうかが重要になります。
レビューはネットワーク設定の確認作業ではありません。
業務とリスクのバランスを確認する作業だと、私は考えています。
暗号化の観点については、また別の記事で書こうと思います。