統一ルールベースの使用例
ここでは、アクセスコントロールポリシーに定義できるルールの例を示す使用例をいくつか紹介します。
ユースケース - アプリケーション制御とコンテンツ認識 オーダーレイヤー
この例では、統一されたアクセスコントロールポリシーの例を示しています。アプリケーションとコンテンツを1つのOrdered Layerで制御します。
ルールについての説明：
|
ルール |
説明 |
|---|---|
|
1 |
一般的なコンプライアンスセクション - 許容できないWebサイトやアプリケーションへのアクセスをブロックします。 |
|
2 |
危険な実行ファイルをブロックするセクション - 危険性の高い実行ファイルのダウンロードをブロックします。 |
|
3-4 |
クレジットカードデータセクション - クレジットカード番号のアップロードをファイナンス部門のみ許可し、HTTPS経由でのみ実行します。それ以外のクレジットカードはブロックします。 |
|
5 |
VPNセクションで機密データをブロックするセクション - 組織のVPN経由で接続したリモートユーザには、情報メッセージが表示されます。 |
|
6 |
クリーンアップ ルール - 先のルールのいずれかに一致しないすべてのトラフィックを許可します。 |
ユースケース - Webトラフィック用インライン・レイヤー
この使用例では、Webトラフィックを制御するアクセスコントロールポリシーの例を示しています。WebサーバのルールはInline Layerにあります。
ルールについての説明：
|
ルール |
説明 |
|---|---|
|
4 |
インラインレイヤーの親ルールです。Actionは、インラインレイヤーの名前です。パケットが親ルールにマッチした場合、インラインレイヤのルール4.1にマッチングが続きます。パケットが親ルールにマッチしない場合、ルール5でマッチングが続きます。 |
|
4.1 |
パケットがルール4.1にマッチした場合、そのパケットに対してルールアクションが行われ、それ以降のルールマッチは行われません。ルール4.1でパケットがマッチしない場合、ルール4.2へ進みます。インラインレイヤの残りのルールも同じロジックです。 |
|
4.5 |
もしOrdered Layerのどの上位ルールもパケットにマッチしない場合、明示的なCleanup Ruleが適用される。Cleanupルールは、デフォルトの明示的ルールである。ルールは変更または削除することができます。各インラインレイヤーと順序レイヤーの最後のルールとして、明示的なクリーンアップルールを設定することをお勧めします。 |
ユースケース - コンテンツ認知度 オーダーレイヤー
この例では、組織からのデータのアップロードとダウンロードを制御するポリシーを示しています。
ルールベースの下に、いくつかのルールの説明があります。
ルールについての説明：
|
ルール |
説明 |
|---|---|
|
1-3 |
規制遵守セクション - 実行可能ファイルやクレジットカードのアップロードとダウンロードを制御します。 Contentの方向を設定できます。ルール1ではDownload Traffic、ルール2ではUpload Traffic、ルール3ではAny Directionです。 ルール1は、ファイルタイプである実行ファイルを制御します。ファイルタイプのルールは、コンテンツタイプのルール（ルール2～7）よりもルールベースの上位にあります。これにより、コンテンツタイプよりもファイルタイプの方が早くマッチングされるため、ルールベースの効率が向上します。 |
|
4-5 |
個人識別情報セクション - 社会保障番号や医療記録のアップロードとダウンロードを制御します。 ルール4のルールアクションはInformです。社内ユーザが社会保障番号の入ったファイルをアップロードすると、ユーザにメッセージが表示されます。 |
|
6 |
人事セクション - 給与調査情報の社外への送信を制限します。 ルールアクションはAskです。機密性の高いコンテンツが検出された場合、ユーザはそのアップロードが組織のポリシーに準拠していることを確認する必要があります。 |
|
7 |
知的財産セクション - ソースコードが外部へ送られる際に制御するルールのグループ。 ルール7はインライン・レイヤーの親ルールである (オーダーレイヤーとインラインレイヤー)。Actionは、インラインレイヤーの名前です。 パケットがルール7.1にマッチした場合、マッチングは停止します。 ルール7.1でパケットがマッチしない場合、ルール7.2へ進みます。同様に、一致しない場合は次の7.3へ進みます。マッチングはインラインレイヤーの最後のルールで停止します。各インラインレイヤーの最後のルールとして、明示的なクリーンアップルールを設定することをお勧めします。 |
ユースケース - アプリケーションとURLのフィルタリング オーダーレイヤー
このユースケースは、インターネットの閲覧をモニタおよび制御する典型的なポリシーの URL フィルタリングおよびアプリケーション制御ルールの例を示しています。(Hits, VPN とInstall On のカラムは表示されていません)。
ルールについての説明：
|
ルール |
説明 |
||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
1 |
Liability sites- カスタムPotential_liabilityグループのサイトとアプリケーションへのトラフィックをブロックします。UserCheckBlocked Messageはユーザに表示され、トラフィックがブロックされた理由を説明します。参照: ブロックサイト。 シナリオ：責任問題を引き起こす可能性のあるカテゴリに関連するサイトをブロックしたい。これらのカテゴリのほとんどはアプリケーション・データベースに存在するが、カスタム定義されたサイトも含まれなければならない。どうすればいいですか？ カスタムグループを作成し、該当するすべてのカテゴリとサイトをそのグループに追加することでこれを行うことができます。セキュリティゲートウェイで Identity Awareness を有効にすると、URL フィルタリングと一緒に使用して、アクセスロールに適用するルールを作成できます。アクセスロールオブジェクトを使用して、ユーザ、マシン、ネットワークロケーションを1つのオブジェクトとして定義します。 この例では
カスタムグループを作成するには
これで、アクセス・コントロール・ルールベースでLiability_Sitesグループを使用できるようになります。 ルールベースに、次のようなルールを追加します。 SmartConsoleのSecurity Policiesビューで、Access Control Policyにアクセスします。
|
||||||||||||||
|
2 |
High risk applications- 高リスクカテゴリのサイトやアプリケーションへのトラフィックをブロックし、iTunesアプリケーションをブロックします。UserCheckBlock Messageはユーザに表示され、トラフィックがブロックされた理由を説明します。 |
||||||||||||||
|
3 |
Allow IT department Remote Admin- |
||||||||||||||
|
4 |
Allow Facebook for HR- |
||||||||||||||
|
5 |
Block these categories- 以下のカテゴリへのトラフィックをブロックします：ストリーミングメディア、ソーシャルネットワーキング、P2Pファイル共有、リモート管理。UserCheckBlocked Messageはユーザに表示され、トラフィックがブロックされた理由を説明します。
|
||||||||||||||
|
6 |
Log all applications- URLフィルタリングおよびアプリケーションコントロールのカテゴリのいずれかに一致するすべてのトラフィックをログに記録します。 |
