ドメイン管理者のアカウントポリシー（PCI監査後）

私たちのクライアントの1つはTier 1 PCI会社であり、彼らの監査人はシステム管理者およびアクセス権として私たちに関して提案をしました。

約700のデスクトップ/ 80サーバー/ 10ドメインコントローラーの完全にWindowsベースのインフラストラクチャを管理しています。

彼らは、3つの個別のアカウントを持つシステムに移行することを提案しています。

DOMAIN.CO.UK\UserWS  
DOMAIN.CO.UK\UserSRV  
DOMAIN.CO.UK\UserDC  

• どこWSが唯一のワークステーションにログオンするアカウントです、ワークステーション上のローカル管理者であります
• どこSRVは唯一の非DCサーバーにログオンするには、サーバー上のローカル管理者であることをアカウントです
• ここで、DCはドメインコントローラーのみにログオンするアカウント、実質的にはドメイン管理者アカウント

その後、間違ったアカウントから間違ったタイプのシステムへのログオンを防ぐためのポリシーが適用されます（これには、DC以外のマシンのドメイン管理者アカウントの対話型ログオンの削除が含まれます）

これは、侵害されたワークステーションがドメイン管理者のログオントークンを公開し、それをドメインコントローラに対して再利用できる状況を防ぐためです。

これは、日常業務に対する非常に侵入的なポリシーであるだけでなく、比較的ありそうもない攻撃/悪用に対処するためのかなりの量の作業であるように見えます（これはとにかく私の理解であり、おそらくこの悪用の実行可能性を誤解しています） 。

他の管理者の意見、特にここでPCI登録会社に関与していて、同様の推奨事項を経験している管理者の意見を聞いてみたいです。管理者ログオンに関するポリシーは何ですか。

記録のために、現在、通常使用するドメインユーザーアカウントと、追加の権限が必要なときに昇格するドメイン管理者アカウントがあります。正直なところ、私たちは少し怠け者であり、多くの場合、日々の運用にドメイン管理者アカウントを使用していますが、これは技術的には会社のポリシーに反しています（ご理解いただけると思います！）。

Tier 1 PCIベンダーにいます。このようなものがありますが、いくつか違いがあります。

監査人は実際には非常に現実的な問題を説明しようとしていますが、その意味とニーズ分析を説明する非常に貧弱な仕事をしています。

現在、パスワードのハッシュまたは既存のトークンを使用してシステムを侵害する方が効果的です。簡単に言えば、攻撃者はもはやユーザー名とパスワードを必要としません。システムを攻撃する簡単な方法があります。 どんな状況でも、このタイプの攻撃はありそうもないと仮定したり結論を下したりしてはなりません。ハッシュ攻撃は、事実上の攻撃ベクトルになりました。

ハッシュ攻撃は実際にはスマートカードアカウントでは悪化しますが、これは皮肉なことです。ほとんどの人は、スマートカードを実装するとシステムのセキュリティが向上すると期待しているためです。

パスザハッシュ攻撃によりアカウントが侵害された場合、通常の対応はアカウントのパスワードを変更することです。これにより、認証に使用されるハッシュが変更されます。また、攻撃者のハッシュが失敗し始めるため、通常のパスワードの有効期限/変更は侵入を表面化するかもしれません。ただし、スマートカードの場合、パスワードは「システム管理」であるため（ユーザーが認証のためにパスワードを入力することはありません）、ハッシュは変更されません。つまり、スマートカードアカウントでは、パスワードを使用するアカウントよりもはるかに長い間、侵入に気付かない可能性があります。

私が検討する緩和策は次のとおりです。

• 多くの大企業が特権の高いアカウントに使用しているスマートカード対応アカウントの場合、頻繁にアカウントのパスワードを変更してください。これにより、ハッシュが変更されます。また、アカウントを有効にするスマートカードを外してからスマートカードを有効にして、ハッシュを変更することもできます。Microsoftはこれを24時間ごとに実行しますが、これが環境に与える潜在的な影響を評価し、追加の問題が発生しないように健全なスケジュールを確立する必要があります。

• ワークステーションでは、可能であれば管理目的でドメインアカウントを使用しません。UACタイプの操作の昇格に使用できるローカルアカウントがあります。これは、ほとんどの標高要件の99.9％を満たします。ワークステーションは、統制された変更管理の欠如、およびJava JREとFlashの存在により、ホットな攻撃ベクトルになる傾向があります。

  この方法は、ローカルアカウントのパスワードを管理および強制するための正式なメカニズムがあり、パスワードは各システムで一意であり、誰かがパスワードを要求するための安全な方法があるためです。この機能を実行できる商用アプリケーションもあります。

• ワークステーションにローカルアカウントソリューションを提供できない場合は、はい、ワークステーションへの管理アクセスには別のドメインアカウントを使用し、サーバーへの管理アクセスにはそのアカウントを使用しないでください。別のオプションは、LocalSystemを使用してアクティビティを実行するリモートの非対話型サポート管理ツールと、Windowsとは別の認証メカニズムを使用することです。

• 最高特権アカウント（エンタープライズ管理者、ドメイン管理者など）には、ジャンプサーバーのみを使用してください。このサーバーは、最も制限の厳しいセキュリティ、変更管理、および監査の対象となります。他のすべてのタイプの管理タイプの機能については、個別の管理アカウントを持つことを検討してください。ジャンプサーバーは、LSAプロセスからプロセストークンをクリアするために毎日再起動する必要があります。

• ワークステーションから管理タスクを実行しないでください。強化されたサーバーまたはジャンプサーバーを使用します。

• ジャンプボックスとしてVMを簡単にリセットすることを検討してください。これは、各セッション後にメモリをクリアするためにリセットできます。

参考文献：

https://blogs.technet.com/b/security/archive/2012/12/06/new-guidance-to-mitigate-determined-adversaries-favorite-attack-pass-the-hash.aspx

マイクロソフトセキュリティインテリジェンスレポート、ボリューム13、2012年1月-6月
http://www.microsoft.com/security/sir/archive/default.aspx

「Pass-the-Hash攻撃に対する防御」セクションをお読みください。

恐ろしいpass-the-hash攻撃を
打ち負かすhttps://www.infoworld.com/d/security/defeat-dreaded-pass-the-hash-attacks-179753