Tetrationでポリシーのコンプライアンスチェック
Tetration 「Policy Analysis」がポリシー精緻化を可能に
前回のブログ『ISEとTetrationでアプリケーションへのアクセスをコントロール』でも書きましたが、Tetrationはセンサーエージェントから収集したフロー情報に基づき事実ベースでアプリケーションが必要とするホワイトリストポリシーを提示します。しかしそれをそのままホワイトリストポリシーとして実行（強制）する前に管理者による「ポリシーの精緻化」のステップが必要です。Tetrationが提示するポリシーはあくまで「事実ベース」つまり実際に発生したフローをベースにしますので、多くの場合本来不必要なポリシーも含まれていたり、逆に本来必要なポリシーが含まれていなかったりするからです。
Tetrationには「Policy Analysis」という機能があります。センサーエージェントはホワイトリストポリシーの提示後も継続してホストが発生させているフローの情報をほぼリアルタイムで解析装置側に送ります。つまり、発生しているフローを定義済みのホワイトリストポリシーに照らし合わせて比較することでそのフローがポリシーに合致しているのか違反しているのか、宛先まで届いているのかドロップしているのか、といったことを知ることができます。これが「Policy Analysis」の機能です。管理者はこれをうまく活用することでポリシーの精緻化をより簡単に、より正確に行うことが可能となります。
「Policy Analysis」では分析結果としてフローを4つのカテゴリーに分けて表示します。
1. Permitted
Permittedはポリシー通りのフローで、かつドロップすることなく宛先に届いているフローのことです。当たり前ですが正常な環境ではフローの大半がこのPermittedに分類されることになります。もしそうでなければ何らかの異常が発生していること考えてよいでしょう。
2. Escaped
Escapedはポリシーにないフローで、かつドロップすることなく宛先に届いているフローのことです。一見ポリシー違反のフローと言えるかもしれませんが、ホワイトリストポリシーの生成時に利用したフローデータの収集期間が短く、本当はアプリケーションに必要なフローなのにその期間には発生しておらずホワイトリストポリシーから漏れてしまってるフローかもしれません。不要なフローであればポリシーはそのまま、必要なフローであればポリシーに追加する、という精緻化の作業が必要となるでしょう。
3. Misdropped
Misdroppedはポリシー通りのフローですが宛先には届いていないフローのことです。これは送信元と宛先の両方のホストにセンサーが入っている場合にのみ検知できるカテゴリーです。Misdroppedが検知されるケースでは、送信元と宛先の間にあるFirewallの設定間違いなどでそのフローをドロップしてしまっている、もしくはその逆で本来発生すべきでないフローなのでFirewallでドロップしているがTetrationでホワイトリストポリシーに入れてしまっている、といった状況があり得ます。Misdroppedが多発している場合はポリシーが正しいかどうか、経路中にあるFirewallの設定が間違っていないか、などを確認するようにしましょう。
4. Rejected
Rejectedはポリシー通りのフローですがポリシー通りにドロップされているフローのことです。「Deny」として定義されているポリシーに合致するフローなのでポリシー通りにドロップされているということです。これはホワイトリストポリシーの実行（強制）を始めると増えるカテゴリーになります。ポリシーによってドロップされるフローが増えるからです。
Policy Analysisではこれら4つのカテゴリーを縦軸：フロー数、横軸：時間としてグラフで表示します。Permittedは青色、Escapedは橙色、Misdroppedは赤色、Rejectedは灰色の折れ線でそれぞれ表示され、グラフ上部のカテゴリ名が書いてあるボタンを押すと表示から消すこともでき、見たいカテゴリのみをグラフ上に描画することも可能です。
任意の時間軸をクリックすることでその時間帯に発生しているフローの詳細を確認することもできます。
このスクリーンキャプチャからは時間、フローのカテゴリ、送信元/送信先のIPアドレスやポート番号などフローの詳細な情報を確認できますが、ここに表示された項目はごく一部の情報で、これ以外にもホストのタグ情報など様々な項目を表示させることも可能です。ポリシーの精緻化やセキュリティポリシーの策定などにおいて大いにお役立ていただけると思います。ぜひご活用ください。
