Domain Adminを利用しない運用

　同じ理由で、さらに高い権限を持つドメイン管理者用のDomain Adminアカウントの利用もリスクを伴う。こちらはセキュリティパッチ配布のためにDomain Adminsグループ権限を使うケースが多いため、運用の変更には抵抗感が強いかもしれないが、セキュリティのためには運用の「文化」を変える必要がある。

　必ずしもパッチ配布はDomain Admin権限でなければならないものではない。高い権限のアカウントの利用は特定の運用管理端末のみに限定し、ユーザー端末にはログインしない（アカウント情報をキャッシュさせない）運用が望ましい。

　ルールが守られているかどうかは認証サーバのログでチェックできる。なお、パッチ配布用の専用アカウントを作成し、そのアカウントを監視対象として不正利用を検知できるようにしておくのも効果的だ。

攻撃基盤構築から目的遂行までの活動を止める方法

　次に攻撃基盤構築と攻撃目標の遂行を図る活動への対策の落とし穴になりがちなポイントと対策を見てみよう。

　全ての通信がプロキシサーバを経由するように設計し、ウイルスのコネクトバック通信をファイアウォールで遮断することにより、およそ半数のウイルス活動を無効化できる。しかし、業務部門からプロキシ非対応のアプリケーションを使いたい、必要なポートは開けてほしいといった要請があると対応せざるを得ず、やがてフィルタリングルールが形骸化する傾向が見られる。

　これがセキュリティの弱点になる可能性が高い。組織全体での議論により、内部から外部への通信は必ずプロキシを経由し、利用ポートは必要最低限に限定することを徹底することが大事だ。

　プロキシサーバの認証機能は、やはりウイルスのコネクトバック通信をブロックする効果が高い。しかし、利用状況把握や監査のためだけに利用し、対策として不十分な場合が見受けられる。

　また、ユーザーPCのWebブラウザのオートコンプリート機能から窃取した認証情報が利用されると無力だ。Windowsの旧式シングルサインオン機能であるNTLM認証を利用する場合、ウイルスは悪用可能な機能を既に備えるためリスクが高い。

　対策はNTLM認証よりも安全性が高い認証方式を利用し、オートコンプリート機能は禁止する運用（グループポリシーで設定可能）にすることがまず薦められる。その上で認証ログを分析し、異常に多数のアドレスへのアクセスがないかなどを確認するとよい。

　ウイルスの外部通信にはCONNECTメソッドが使われる場合が多い。業務上でCONNECTメソッドはSSL通信のための「443/TCP」を使う以外はほとんどないので、それ以外のポートやプロトコルでのCONNECTメソッドによる要求をプロキシサーバで拒絶するとよい。プロキシサーバのACLを変更（追加）するだけだ。

　ウイルスは、外部C&Cサーバと常時接続することがほとんどだ。いったん通信を全部遮断して、業務端末から再接続しない状況を作り上げてみると、再接続しようとする端末は感染した可能性が高いと判断できる。

　ただし、業務停止は組織全体で一斉に行うことは難しいはずだ。部門別などで日を決めて、時間外にPCをONにしたまま帰ってもらって実行するとよい。

　以上、10の落とし穴への対策を効果が高い順に簡単に紹介した。これら対策はIPAの「『標的型メール攻撃』対策に向けたシステム設計ガイド」に詳しい。「攻撃者に狙われる設計・運用上の弱点についてのレポート」とともに参考にされることをお薦めする。