まいど！大阪オフィスで働いております折口です。
- 本日はマネージドプレフィックスリストの活用例について、前編と後編の2部構成で投稿させて頂きます。
- 前編：活用例
- 後編：設定方法や注意点について
1. マネージドプレフィックスリストについて
- VPCの一機能であるマネージドプレフィックスリストを利用することで、CIDRブロックをリストとして、定義することができます。
- 例えば、自社、保守先のベンダーといったようなグループ単位でリスト化しておくことができます。
- 定義化したプレフィックスリストはセキュリティーグループやルートテーブル の設定で利用することができるため、管理上においてのメリットがあります。
- 参考情報：AWS公式ドキュメント ”プレフィックスリスト”
2. 運用ケース
- サンプルの運用ケースを一つ用意しましたので、マネージドプレフィックスリストを使用しなかった場合と使用した場合の違いを見ていきましょう。
2-1. 構成例
2-2. 運用例
- 公開サーバーがあり、運用保守において、セキュリティーグループで接続元のIPアドレス制限を行っている。
- 接続元は自社ネットワークと運用保守を行うベンダー数社から接続を行っている。
- 運用保守で利用している通信は「SSH」と「HTTP」を利用している。
3. マネージドプレフィックスリストを利用しなかった場合
- マネージドプレフィックスを利用せず、運用ケースをセキュリティーグループに落とし込んだ場合、以下のルールになります。
3-1. セキュリティーグループの設定（マネージドプレフィックスリスト無し）
| No | タイプ | プロトコル | ポート範囲 | ソース | 説明 |
|---|---|---|---|---|---|
| 1 | SSH | TCP | 22 | 10.10.x.x/24 | from my network |
| 2 | SSH | TCP | 22 | 10.11.x.x/24 | from my network |
| 3 | SSH | TCP | 22 | 210.x.x.x/32 | from vender.a tokyo |
| 4 | SSH | TCP | 22 | 210.x.x.x/32 | from vender.a nagoya |
| 5 | SSH | TCP | 22 | 210.x.x.x/32 | from vender.a osaka |
| 6 | SSH | TCP | 22 | 192.x.x.x/32 | from vender.b tokyo |
| 7 | SSH | TCP | 22 | 192.x.x.x/32 | from vender.b nagoya |
| 8 | HTTP | TCP | 80 | 10.10.x.x/24 | from my network |
| 9 | HTTP | TCP | 80 | 10.11.x.0/24 | from my network |
| 10 | HTTP | TCP | 80 | 210.x.x.x/32 | from vender.a tokyo |
| 11 | HTTP | TCP | 80 | 210.x.x.x/32 | from vender.a nagoya |
| 12 | HTTP | TCP | 80 | 210.x.x.x/32 | from vender.a osaka |
| 13 | HTTP | TCP | 80 | 192.x.x.x/32 | from vender.b tokyo |
| 14 | HTTP | TCP | 80 | 192.x.x.x/32 | from vender.b nagoya |
- 実際のケースによってはFTPなどの通信や拠点数がより増えますと、セキュリティーグループのルール数はより増える傾向になります。
4. セキュリティーグループの設定（マネージドプレフィックスリストあり）
- それではマネージドプレフィックスリストを利用して、「自社」「運用保守ベンダーA」「運用保守ベンダーB」の3グループをリストとして、定義してみましょう。
4-1. マネージドプレフィックスリストの定義
- 3グループをリストとして、登録した場合、マネージドプレフィックスリストの設定は以下となります。
| プレフィックスリスト 名 | エントリ | 説明 |
|---|---|---|
| pl-my.network | 10.10.x.x/24 | my network |
| 10.11.x.x/24 | my network | |
| pl-vender.a | 210.x.x.x/32 | from vender.a tokyo |
| 210.x.x.x/32 | from vender.a nagoya | |
| 210.x.x.x/32 | from vender.a osaka | |
| pl-vender.b | 192.x.x.x/32 | from vender.b tokyo |
| 192.x.x.x/32 | from vender.b nagoya |
※注意点として、マネージドプレフィックスリストには最大エントリの考え方がありますが、後編にて、記載させて頂きます。
4-1. セキュリティーグループの設定（マネージドプレフィックスリストあり）
- 定義したマネージドプレフィックスリストを用いて、セキュリティーグループを設定した場合、以下となります。
| No | タイプ | プロトコル | ポート範囲 | ソース | 説明 |
|---|---|---|---|---|---|
| 1 | SSH | TCP | 22 | pl-my.network | 自社ネットワーク |
| 2 | SSH | TCP | 22 | pl-vender.a | 運用保守ベンダーA 東京拠点 |
| 3 | SSH | TCP | 22 | pl-vender.b | 運用保守ベンダーB 東京拠点 |
| 4 | HTTP | TCP | 80 | pl-my.network | 自社ネットワーク |
| 5 | HTTP | TCP | 80 | pl-vender.a | 運用保守ベンダーA 東京拠点 |
| 6 | HTTP | TCP | 80 | pl-vender.b | 運用保守ベンダーB 東京拠点 |
- セキュリティーグループのソースがCIDR表示からプレフィックスリスト名に変わりますので、どこに対しての通信なのかが分かりやすくなった事とセキュリティーグループのルール数が「14ルール」から「6ルール」とシンプルにすることができました。
5. まとめ
- 今回のケースにおいては一台のサーバーを対象としていますが、これが複数台あり、それぞれごとに接続元が異なる場合、セキュリティーグループのルールが煩雑になる恐れがあります。
- もし、セキュリティーグループをAWSマネジメントコンソールから変更しており、何ルールも変更しないといけないといった運用をされていた場合、設定が漏れてしまって繋がらなかったといったトラブルに発展する可能性も考えられます。
- マネージドプレフィックスリストを利用し、設定ルールの簡素化と分かりやすさを向上させることはトラブルを未然に防ぐことができるといった管理上のメリットがあります。
以上、マネージドプレフィックスリストを活用例の前編となります。 次回はこのマネージドプレフィックスリストの設定方法や注意点について、記載させて頂きます。
Yusuke Origuchi
Photographer & Cloud Engineer
Photographer & Cloud Engineer
