ネットワークアクセス保護（NAP）ポリシーの“例外”を要求されたら：ITpro

これは断るべきでしょう・・・これ断らなかったら、後で運用で死にますよ。

社内でのネットワークアクセス保護（NAP）の展開が完了したと思ったら、あなたよりずっと偉い誰かがポリシーの例外を要求してくる…。これは断るわけにはいきません。

まぁ、これはしょうがない・・・

あるいは、ネットワークに非NAP 対応マシンが何台かあり、それらのマシンをポリシーから簡単に除外できる方法が必要な場合もあります。時にはベンダーが社内に来て、午後の間ずっとネットワークアクセスを必要とするかもしれません

まぁRADIUSを使っていれば色々属性をつけてポリシーをいじれますよね。

　いずれにせよ、ポリシーの例外の管理は、NAP 展開を成功させる上で重要な部分を占めています。NAP はRADIUS をベースにして構築されるため、さまざまな属性に基づいて例外ポリシーを作成できます。以下に、よく発生する3 つのシナリオを示します。

とりあえず、非NAPの場合はデフォルト制限付きにして、その後パッチ適用状況やウイルス対策などを確認した上で非制限ポリシーをわりあてるようにしないと、いきなり制限なしは飛びすぎでしょ・・・ｗ

1番目の最も一般的なシナリオは、非NAP 対応コンピュータに関するものです。NAP ポリシーには、マシンがNAP 対応かどうかに関する条件文を含めることができます。これは、NAP 対応のマシンには正常性を徹底する一方で、NAP 対応ではないマシンのアクセスも許可できる便利な方法です。

MACアドレスで認証、そしてフルアクセスはまずいでしょ・・・って思う・・・

3 番目の例は、少しの間だけ社内に来てネットワークアクセスを必要とするベンダーに関するものです。この場合、コンピュータにもユーザーにも、ルールを作成するためのグループのメンバーシップがありません。NAP 展開が完了した場合、または積極的な実施スタンスをとっている場合、「非NAP 対応」ルールは存在しない可能性があります。このようなとき、短期的なユーザーを除外する簡単な方法は、MAC アドレスによる方法です。
この場合は、コーリングステーションID というRADIUS クライアントプロパティを使用する新しいルールを作成します。このルールとは、「MAC アドレスによる除外：コーリングステーションIDが‘0015B7A6F653’と一致する場合にアクセスを許可する」というもので、ルールが適切に並んでいれば、ビジターの接続試行は最初にこのルールと一致し、MAC アドレスに基づいたネットワークアクセスが可能になります。