ドメイン管理者のドメインに個別のログインをすることはベストプラクティスですか?


33

私は通常、自分用に個別のログインを設定し、通常のユーザー権限を持つログインと、管理タスク用に個別のログインを設定します。たとえば、ドメインがXXXXの場合、XXXX \ bpeikesとXXXX \ adminbpアカウントを設定します。率直に言って、自分が管理者としてログインすることを信じていないので、私はいつもそれをしましたが、私が働いたすべての場所で、システム管理者は通常のアカウントをDomain Adminsグループに追加するだけのようです。

ベストプラクティスはありますか?MSの記事で、管理者としてログインするのではなくRun Asを使用する必要があると書かれていますが、実装の例は示しておらず、他の人がそれを行うことはありません。


1
主にLinux / Unixを扱っており、Windowsの専門家ではない人として、これはUACが正確に修正すべきものではないでしょうか?つまり、1つのアカウントを使用できますが、許可されたプロセスのみに管理者権限を付与できます。
Dolda2000 14

@ Dolda2000 UACは、ローカルマシンで管理者として実行する習慣のあるエンドユーザーにとってより便利でした。ローカルマシンでドメイン管理者として実行している場合、追加の懸念事項があります-マシンにウイルスをインストールするよりも資格情報とアクセスがはるかに悪いことに使用される可能性があります。ドメイン全体。
HopelessN00b 14

1
@ HopelessN00b:そして、あなたはUACはそれらのものには適用されないと言っていますか?何故なの?技術的な理由はありますか、それとも実装が単純に不足していますか?
Dolda2000 14

2
@ Dolda2000まあ、UACは、マルウェアがログオンしている管理ユーザーのユーザーコンテキストを使用して、エンドユーザーと消費者のPCにインストールできるという問題を修正することになっています。そして、それは。また、その特定のベクトルがドメイン管理者のユーザーコンテキストを使用してマルウェアをローカルにインストールすることをブロックしますが、制限ユーザーではなくドメイン管理者として実行することに伴うセキュリティ上の懸念の範囲ではありません。
HopelessN00b 14

1
@ Dolda2000 UACは、ローカルマシンでプロセスが特権機能を実行するのを防ぎます。ドメイン管理者としてログインしている場合、特権コマンドを他のマシンでリモートで実行でき、UACプロンプトなしでリモートマシンで昇格して実行されます。したがって、これを悪用するように特別に設計されたマルウェアは、UACプロンプトが表示されることなく、ドメイン全体に感染します(そして、別のリモートマシンを使用してローカルマシンに感染します)。
モンスティエウ

回答:


25

「ベストプラクティス」は通常、LPU(最小特権ユーザー)を指示します...しかし、あなたは正しいです(ETLとJoeは+1です)。

ほとんどの推奨事項は、あなたが言うように行うことです... 2つのアカウントを作成し、それらのアカウントを他の人と共有しないでください。1つのアカウントは、理論的には使用しているローカルワークステーションでも管理者権限を持つべきではありませんが、特に最近ではUAC(理論的には有効にする必要があります)でそのルールに従っています。

ただし、このルートを使用する理由には複数の要因があります。セキュリティ、利便性、企業ポリシー、規制の制限(ある場合)、リスクなどを考慮する必要があります。

維持Domain Adminsし、Administrators最小限のアカウントできれいドメインレベルのグループは、常に良い考えです。ただし、回避できる場合は、一般的なドメイン管理者アカウントを単に共有しないでください。そうしないと、誰かが何かをしてから「そのアカウントを使用したのは私ではない」というシステム管理者の間で指を指すリスクがあります。個人アカウントを持っているか、Cyber​​Ark EPAのようなものを使用して、正しく監査することをお勧めします。

また、これらの行でSchema Adminsは、スキーマに変更を加えてからアカウントを入れ、変更を加え、アカウントを削除しない限り、グループは常に空になっている必要があります。同じことは、Enterprise Admins特に単一ドメインモデルで言えます。

また、ネットワークへのVPNへの特権アカウントを許可しないでください。通常のアカウントを使用し、内部で必要に応じて昇格します。

最後に、特権グループを監査するためにSCOMまたはNetwrixまたは他の方法を使用し、これらのグループのメンバーのいずれかが変更されるたびにITの適切なグループに通知する必要があります。これにより、「ちょっと待って、なぜそんなに突然ドメイン管理者なのか?」等

結局のところ、「ベストプラクティス」ではなく「ベストプラクティス」と呼ばれる理由があります。これについては、ITグループが独自のニーズと哲学に基づいて許容可能な選択を行っています。ジョーが言ったように、単に怠simplyな人もいれば、すでに何百もの毎日の火事が発生したときに1つのセキュリティホールを塞ぐことに興味がないので、気にしない人もいます。ただし、これらすべてを読み終えたので、自分自身が良い戦いと戦うものの1つであり、物事を安全に保つためにできることを行うと考えてください。:)

参照:

http://www.microsoft.com/en-us/download/details.aspx?id=4868

http://technet.microsoft.com/en-us/library/cc700846.aspx

http://technet.microsoft.com/en-us/library/bb456992.aspx


最小特権は、主に管理者以外のアカウントに適用されます。下位の特権を持つcredによって侵害されたダーティシステムでcredが使用される場合、資格の分離は最小のprivの観点からは役に立ちません。
ジムB

確かに、「LPU」は必要に応じて特権グループにのみアクセスを許可することも意味すると考えています。多くのIT部門。無数のアクセス要求を処理するよりも簡単であるという理由だけで、DAアクセスを許可します。
TheCleaner

28

知る限りでは、ドメイン/ネットワーク管理者がワークステーションにログオンするための標準のユーザーアカウントを持ち、日常的な「ユーザー」タスク(電子メール、ドキュメントなど)を実行し、適切な名前の管理アカウントを持つことがベストプラクティスと見なされますグループメンバーシップを使用して、管理タスクを実行できるようにします。

これは私が従おうとしているモデルですが、既存のITスタッフがこの方法で慣れていない場合は実装が困難です。

個人的に、この方向への移動を控えるITスタッフを見つけた場合、彼らは怠け者であるか、経験の浅い、またはシステム管理の慣行を理解していないかのどちらかだと思います。


12

これは、セキュリティ上の理由からベストプラクティスです。他の人が述べたように、それはあなたが誤って何かをしたり、ネットワークを閲覧することからあなたが危うくなることを防ぎます。また、パーソナルブラウジングが受ける可能性のある損害を制限します。理想的には、日々の仕事にローカル管理者権限さえも持たず、ドメイン管理者をはるかに少なくすべきです。

Pass the HashまたはWindows認証トークンのハイジャックに対抗することも非常に便利です。()適切な侵入テストはこれを簡単に証明します。つまり、攻撃者がローカル管理者アカウントにアクセスすると、その権限を使用して、ドメイン管理者トークンを使用してプロセスに移行します。それから彼らはそれらの力を効果的に持っています。

これを使用している人の例については、私の会社はそうです!(200人、6人の運用チーム)実際、ドメイン管理者には-THREE-アカウントがあります。1つは日常使用用、もう1つはPC管理/ソフトウェアのローカルインストール用です。3番目はドメイン管理者アカウントで、サーバーとドメインの管理専用に使用されます。もっと妄想的で安全なものにしたいのであれば、おそらく4番目が適切でしょう。


3つのアカウント...面白い...私は...私の会社で迫り来るドメイン変更のためにそれを考慮する必要があります
pepoluan

1
私の会社でも同じです。通常のデスクトップアカウント、クライアントコンピューターのローカル管理者アクセス用の管理者アカウント、および個別のサーバー管理者アカウント。両方の管理者アカウントは、電子メールもインターネットアクセスも取得しません。1つの問題は、サーバー管理者アカウントがワークステーションのローカル管理者権限を必要とするか、UACがサーバー管理者アカウントとしてRunAsを使用してMMCをローカルで実行することを妨げることです。(サーバーに対してRDPを使用して、そこからすべてを実行できますが、デスクトップアカウントで実行されるデータをコピー/貼り付けまたは比較する必要がある場合、それは実際に妨げになります。)
Tonny 14

管理作業のためにDomain Admins RDPをサーバーに接続することで、非常にうまくやっています。コピー&ペーストは、実際にRDP全体で驚くほどうまく動きます。そして、その単一サーバーには、すべての管理ユーティリティがすでにインストールされています。しかし、それは言われています... Domain Adminsグループにはデフォルトでローカル管理者権限があります。トークンの盗難などを防ぐために、これらの資格情報はデスクトップに触れないことを好みます。
クリストファーカレル

8

私の以前の会社では、すべてのシステム管理者が2つのアカウントを取得したと主張しました。

  • ドメイン\ st19085
  • DOMAIN \ st19085a(管理者の「a」)

同僚は最初は気が進まなかったが、「私たちはウイルス対策を手に入れた」というウイルスの脅威についての典型的な質問が古いウイルスデータベースによって暴かれた後、経験則になりました...

  • 前述のように、RUNASコマンドを使用できます(以前はバッチスクリプトを使用し、カスタムメニューを表示し、RUNASコマンドで特定のタスクを起動していました)。

  • もう1つは、Microsoft管理コンソールの使用です。必要なツールを保存し、右クリックして[ 実行]を選択し、ドメイン管理者アカウントで起動できます。

  • 最後になりましたが、私はドメイン管理者としてPowerShellシェルを起動し、そこから必要なものを起動していました。

6
これは基本的に、私が言ったことがあるすべての場所で使用した(そして他のすべての人に強制した)実装です。コンピューターにログオンし、他のすべてのユーザーと同様に、通常のユーザーとして日常のタスクを実行します。あなたは管理者権限が必要な場合には、Run As/ Run as Administratorと、管理者ユーザーアカウントを使用しています。すべてに1つのアカウントを使用することはセキュリティ上の悪い慣行であり、私の経験では、反対する人は、とにかくすべてを管理者として実行することから隔離する必要のある人々です。
HopelessN00b 14

@ HopelessN00bによって+1偉大な観測:「オブジェクト人々が最も必要はとにかく管理者として、すべてを実行しているから隔離する人々である」
mr.b

実際にあなただけの管理を実行するために、ロックダウンされています別のワークステーション使用されなければならない
ジム・B

4

私は両方の方法でそれを行う場所で働いてきましたが、一般的には別のアカウントを持つことを好みます。joeqwertyの気の進まないユーザー/顧客が考えるように思われることに反して、実際にはそのようにはるかに簡単です:

ドメイン管理活動のために通常の毎日のアカウントを使用することの長所:はい、すべての管理ツールはrunasなしで私のワークステーションで動作します!W00t!

ドメイン管理活動のために通常の毎日のアカウントを使用することの短所:恐れ。;)デスクトップ技術者は、マシンの問題を見つけられないため、マシンを見るように求められます。ログインすると、ウイルスが発生します。ネットワークケーブルを抜き、パスワードを変更します(他の場所)。携帯電話プロバイダーから個人用ブラックベリーの仕事用メールを受け取らない理由をマネージャーが尋ねると、その際にDOMAIN ADMINパスワードをサーバーに保存することを説明します。など。あなたの高度な特権パスワードは、ウェブメール、VPN、このウェブページへのログインなどに使用されます。(Ew。)(公平に言うと、私のアカウントは「パスワードの変更」ウェブページからブロックされていたので、少なくともそうでした。ウェブページが同期した古いLDAPパスワードを変更したい場合は、同僚の机に。)

ドメイン管理アクティビティに別のアカウントを使用する利点:意図。そのアカウントがされて意図などの管理ツール、のためではなく、電子メール、ウェブメール、VPN、Webページのログインなどのためので、あまり私の通常の「ユーザー」の活動がリスクにドメイン全体を暴露していることを恐れています。

ドメイン管理アクティビティに別のアカウントを使用することの短所:管理ツールにはrunasを使用する必要があります。それだけではありません。

TL; DRバージョン:別のアカウントを持っているのは簡単です。最小限の特権であるため 、ベストプラクティスでもあります。


2

Least Privで十分なはずですが、そうでない場合は、ユーザーと同じ権限を持つアカウントを使用する場合、ユーザーが実行する問題に苦しむ可能性が高いことも考慮してください-そして、自分のアカウントでデバッグできますあまりにも-彼らはそれらを見る前にしばしば!

「それは私のために働く」と言ってチケットを閉じる管理者ほど悪いことはありません:)


+1は、ユーザーレベルのアカウントを毎日使用すると、トラブルシューティングの効率が向上することを認識したためです。
私は言うモニカの復元

1

理論的には、日々の活動に最上位の管理者ログオンを使用しないことが最善です。ウイルスなどの多くの理由があります-ウイルスが発生し、ドメイン管理者ログオンを実行している場合、ウイルスはネットワークにアクセスする簡単な方法、フルアクセスがあります!間違いの可能性は確かに簡単ですが、それが最大の課題とは思いません。キャンパス内を巡回してトップ管理者でログオンすると、誰かがあなたの肩越しにパスワードを探している可能性があります。そのようなことのすべての種類。

しかし、それは実用的ですか?その規則に従うのは難しいと思うが、それに従うことを望む。


0

実際の経験に基づいて2セントを追加します。

毎日の仕事に管理者アカウントを使用していることを知っておいておくと、何をするにしても非常に慎重になります。そのため、メール/リンクをクリックするだけでなく、トリプルチェックなしでアプリケーションを実行するだけではありません。私はそれがあなたのつま先を保つと思います。

日常業務に最小特権アカウントを使用すると、不注意になります。


それは素晴らしい理論ですが、私の経験では機能しません(少なくとも誰もがそうではありません)。私は同僚が誤って本番システムから大量のデータを削除しているのを見ました(コマンドラインの間違った場所に空白で十分です)。
ジェラルドシュナイダー

理論ではなく、ここでそれを実践しています;-)私の経験では、あなたはそのような特権を与える人々を吟味し、尋ねるために彼らを引き渡すだけではありません。
badbanana
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.