はじめに
ネットワークの運用作業で、ファイアウォールのポリシーや ACL の設定追加、変更、削除（以降、ポリシー設定）はよくあるのではないでしょうか。そして、なかなか大変なこと（詳細は後述）も多いです。この大変さを解消する手段の候補として自動化が挙げられます。
ただ、以前の記事「自動化の難易度は機能とパラメーターのセットで考える 」でも少し触れたのですが、自動化するのがとても難しい作業だと思っています。
この難しさは、大きく以下の２つに分かれると捉えています。
そもそもの作業の難しさ
それをさらに自動化しようとしたときの難しさ
仮に自動化したとしても、解決したかった課題がおいてけぼりにされて残ったままだと、徒労に終わってしまうかもしれません。
この手の作業ってどんなことが課題になりがちなんだっけ、と自分が立ち止まって考えるために、ポリシー設定作業そのものの難しさと、それを自動化しようとしたときの難しさについてまとめます。
なお、本記事で何か特別な良い方法を示すのではなく、主観的な難しさや大変さを述べるのみですのでご了承ください。
本記事で挙げる難しさを解消する手法やプロダクトがすでにあるかもしれませんが、そのような特別な仕組みがないベーシックな環境を想定しています。
いきなりまとめ
ちょっと長い記事なので先に簡単にまとめます。
ポリシー設定作業はそもそも難しい。特に要件から設定を導き出すのが難しい
難しいことを自動化するのは難しい。さらに、手動の効率化の延長に自動化がないこともある
1. 要件から設定を導き出す難しさ
通信要件をもとにして、どの機器にどのような設定を入れればいいか導き出すことの難しさについてです。
これが一番難しいかもしれません。
1.1. そもそもの難しさ
運用体制にもよりますが、どこからか「この通信を通してください」という依頼が来て、それを受けて作業に取り掛かる体制を想定します。
依頼内容は例えば以下のようなものです。
送信元IPアドレス
宛先IPアドレス
宛先ポート番号
アクション: 許可/拒否
依頼元はエンドツーエンドの通信要件のみに関心があり、その間にどのようなネットワーク機器があって、どういう設定になっているかは気にしません（というケースを想定）。このこと自体は良しあしではなく、体制上の特性です。
関心の違い（一例）
この場合、依頼を受けた側は実際のどの機器にどういう設定をすればいいか導き出す必要があります。頭の中は以下のような感じです。
「ここからここへの通信だから、FW101とFW801のポリシー、それからL3機器の RT101とRT102のACLが関係しそうだ」
「あれ、、そもそもルーティング的には通ってるかな。どれどれ・・。あぁ大丈夫か」
「それぞれの現状のポリシーをドキュメントで確認しよう」
「FW101とFW801に追加が必要だな。既存のアドレスオブジェクトやサービスオブジェクトで賄えるかな・・？」
「サービスオブジェクトは既にあるな。アドレスオブジェクトだけ作成が必要だ。つまり設定はこんな感じだな」
こういった過程がなかなか大変です。机上でのチェックならなおさらです。レビューする人にとっても。
ちなみに、調べ上げた結果、依頼の通信要件がすでに満たされていることもあり得ます。
1.2. 自動化の難しさ
設定の導出を自動化するには、これまで人がどうやって導き出していたのかをロジック化する必要があります。
与えられたパラメーターを投入すること自体は自動化で担保できたとしても、そもそもパラメーターが誤っていたら「正しく間違える」のようなことになってしまいます。「Garbage In, Garbage Out」にも通じます。
2. 順番を考慮する難しさ
ポリシーの類は上から順に評価されますが、それを考慮することの難しさについてです。
2.1. そもそもの難しさ
ポリシー設定は、ネットワーク機器の設定としてはかなり順序性に気を遣う設定です。
極端な例では、「全ホスト許可」のルールの後に「特定ホストのみ許可」があっても隠れてしまって、意味がありません。隠れたほうのルールを「シャドウルール」と呼ぶこともあります。
機器側の機能としてシャドウルールを検出できる場合もあります。しかし、机上で脳内で判断するのはなかなか難しいものです。
他にも、禁止のポリシーの後に許可をしても意味がないというケースもあります。
ここまでは「そうしないと意図する挙動にならない」という事情でした。
一方で「新規ポリシーを2行目に追加しても3行目に追加してもどっちでもいい」というようなケースもあります。どっちでもいいので制約がなくて楽という反面、制約がないので迷いが生まれるという面もあります。これも何かしらのルールがあるのが理想ですね。
2.2. 自動化の難しさ
先に挙げた「シャドウルール」を避けるような、相応のロジックが必要になります。機器側にシャドウルールを検出してくれる機能があれば、それを自動化の処理の中で応用する方法はあるかもしれません。そうでない場合は、ネットワーク的な計算処理を自前で作成することになり、まるでネットワーク機器側の機能の一部を書くような難しさも垣間見えてきます。
「ある程度どこに追加してもいい」という場合も、人の気分ではなく何かしらのルール化、ロジック化が必要になります。
3. 設定の自由度からくる難しさ
何かと名前付けが必要なポリシー関連の設定の難しさについてです。
3.1. そもそもの難しさ
ポリシー関連の設定は名前付けの嵐です。
アドレスオブジェクト名、アドレスグループ名
サービス名、サービスグループ名
ポリシー名
個人的な感覚ですが、ネットワーク機器の設定として名前を自由に決められる項目は多くないように思います。description くらいでしょうか。ポリシー関連の設定になると自由度が増して、それと同時に「どうしよう・・」という迷いや「適当でもいいかな」という気持ちが芽生えやすい気もします。
あまり適当にしてしまうと、ポリシーの目的が分からずに後で消せなくなったりもします。
名前を自由に決められることは、便利な反面、命名規則などのルールがないと混乱のもとになり得ます。これがある種の難しさの一因かなとも思います。
3.2. 自動化の難しさ
すでに名前付けの難しさを挙げましたが、自動化するには名前付けをルール化する必要があります。
なんとなくで決めていた場合は、いよいよどうするかを決めることを迫られる場面です。
4. グループ化の難しさ
ちょっと細かい話になりますが、アドレスグループのようにオブジェクトをグループ化することは、時々悩ましいことを引き起こすことがあります。
4.1. そもそもの難しさ
たとえば、/32 のアドレスオブジェクトを束ねて、以下のアドレスグループが作成されていたとします。
アドレスグループ: WebServers
アドレス: 10.0.1.1/32
アドレス: 10.0.1.2/32
アドレス: 10.0.1.3/32
このようにグループ化しておくと、何かと管理しやすくなり、効率化にもつながりますね。
さらに、上記のアドレスグループが以下のようにポリシーに適用されているとします。
送信元: any
宛先: WebServers
サービス: HTTP
アクション: 許可
この状態から、以下の通信要件を「削除」する場合についてです。
送信元: any
宛先: 10.0.1.3/32
サービス: HTTP
アクション: 許可
10.0.1.3/32 は WebServers のメンバーです。ですが、安直に WebServers から 10.0.1.3/32 を削除すると、WebServers を指定している他のポリシーにも意図せず影響が出てしまいます。
他のポリシーに影響が出ないようにするには、グループ化の仕方を見直すなどの対応が必要になります。
4.2. 自動化の難しさ
影響がない削除の方法をロジック化するのはなかなか難しそうです。
極端かもしれませんが、宛先の指定がアドレスグループではなく 10.0.1.1/32、10.0.1.2/32、10.0.1.3/32 であれば、このポリシーの宛先から 10.0.1.3/32 を削除すればいいだけなのですが。
この件については「（グループ化のように）手動前提の効率化の延長に自動化があるとは限らない」という点に気付かされます。
5. 作業当日の確認の難しさ
ポリシー変更に限りませんが、作業当日の事後確認の難しさについてです。
5.1. そもそもの難しさ
難しいというよりは、不安という表現の方が適切かもしれません。
必要な設定が揃って手順も完璧！と思って迎える当日も、不安は残ります。そもそも要件から正しい設定を導き出せていたか、それを正しく設定できたかを確認する、事後確認があるためです。
事後確認が必要なこと自体は、ほかの多くの作業に共通することで、たとえばルーティング設定であればL3レベル疎通確認を行います。
ポリシー設定の場合はそれより上のレイヤーを含む確認が必要です。そのため、確認に必要なバリエーションが多かったり、再現が難しい場合もあったりします。この辺りが難しさの要因です。
もちろん、今回の設定に関係ない（はずの）通信に影響がないかも気がかりポイントです。
5.2. 自動化の難しさ
「この通信は通るはず or 通らないはず」というチェックを、エンドツーエンドのエンド側にいる人がやっていた場合、「そこにいる人」からの通信を再現する難しさがあります。
オフィスで利用するような Windows PC から疎通確認を行っていたのを自動化したい場合、ほかの自動化の仕組みとは異なる仕組みが必要かもしれません。例えば他は Python で、エンドだけ PowerShell など。
自動化のために確認方法自体を見直す必要がある場合もあるでしょう。
番外編: ドキュメントの維持の難しさ
これまであげたパラメーターや作業とは少し毛色が異なるので番外編として扱いますが、細かいドキュメントを正しく維持することの難しさについてです。
ドキュメントが正しくメンテナンスされていない場合は、現状のポリシーをドキュメントで確認することができません。この場合は、実機の設定を確認する必要があります。複数の機器の設定を確認するとなると、やはり相応の手間になります。
ドキュメントを正しくメンテナンスしていればいい話、というのはその通りです。ですが、リッチなドキュメントとして管理しようとすると、それだけメンテナンスの負荷も高くなります。
形式
読み手の負荷
メンテナンスの負荷
コンフィグだけ取っておく
高め
低め
ポリシーを表形式にする
低め
高め
表形式の場合、メンテナンスされているのであれば読み手も安心です。そうでなく設定ドリフトがあることが予見される場合、一気に緊張感が高まります。結局、実機を見たほうがいいという心理が働きます。
仮に動的ルーティングの設定であれば、ルーティング情報は機器同士でやりとりがされて、コンフィグに表れるのはルーティングプロトコル自体の設定です。
それに対して、ポリシーの設定の類は機器同士で情報をやり取りすることはなく（そういう高度な仕組みがある場合を除く）、機器ごとのコンフィグにポリシー設定（様々なオブジェクト、ポリシー）が表れます。このような経緯もあり、ポリシー設定は表現するべき情報が多く、リッチなドキュメントにしようとすると負荷がかかりやすくなるのではないか、と思っています。
とにかく「ドキュメントのメンテナンスが大変な割には、役立つ場面がない」というのは避けたいところです。
おわりに
今回はポリシー変更作業とその自動化にフォーカスをあてましたが、総じて以下のようなことが言えるかなと思います。
自動化対象の作業のそもそもの難しさが、自動化の難しさに強く反映されることがある
自動化によって解決したい課題が、その難しさの中にある場合がある
自動化しやすい部分だけに終始すると課題がおいてけぼりになることがあるため、整理整頓と見極めが必要
いわゆる「スモールスタートでやっていきましょう」となった場合でも、難しさや課題を見据えて始めるかどうかは、重要なことだと感じています。
