社内のActive Directoryのドメイン管理者が信用できません


私の会社のAD管理者は、もともと、飲み会の席で
「○×の部署の奴らは、夕方になるとデリヘルのサイトばかり見ている」
といった具合の「管理者ネタ」を開陳するなど、人格的に難のある方でした。

私は彼と職務的に関わりが薄い事もあり、注意する事も無く放っておいたのですが、最近、彼の所属する部署と私の部署の関係が悪化したタイミングで、不審な事がいくつか重なってしまいました。
確たる証拠はありませんが、いまや彼は管理者権限を悪用し、私や同僚のメールの履歴等を不正に収集しているのではと疑っています。杞憂であればそれに越した事はありませんが、安心できるだけの材料(ログ等)もまた十分に得られてないのが現状です。

そこで質問です
(1) 悪意を持ったAD管理者がドメイン内のPCから情報収集を考えた時に取れる行動にはどのような物があるでしょうか
 ・リモートデスクトップ、管理共有などはすぐに思いつきますが、それ以外にもあれば
 ・LAN上での盗聴など、ADに直接関係無い事項は除外して下さい
(2) (1)のような行為が「確かに行われた」事実をログに残すためにはどのような手段があるでしょうか

回答の条件
  • 1人2回まで
  • 登録:2008/06/20 01:50:09
  • 終了:2008/06/23 23:26:21

ベストアンサー

id:memo77 No.1

memo77回答回数238ベストアンサー獲得回数202008/06/20 08:22:47

ポイント100pt

1.PCで行った操作はすべて知ることができます。

キーロガーを動作させることもできますし、画面を定期的にキャプチャすることも、ローカルのファイルを見ることもできます。

メールボックスをコピーすることも、閲覧したサイトのキャッシュを取得することも可能です。


2.あなたがAD管理者でない限り、AD管理者を相手になにかをすることはできません。基本は

・会社として管理規定を決める。

・複数の担当者を配置し、相互監視するルールをつくる。

・日常的な管理者アカウントによるログオンは禁止し、必要なときのみ管理者アカウントでログインし、ログを取る。

・管理者アカウントを使用した際の操作は記録できるものは記録し、できないものは他者の目視の下で作業する。

といった感じです。



まあ、相手を疑ったり責めたりしても組織としていい結果は出ないので、「社会的に内部統制やコンプライアンスの遵守が求められている」ので、会社全体でその取り組みを進めながら、部分として「情報セキュリティポリシーの策定とそれにともなう管理者権限の抑制を行う」のが基本です。


ただ、おそらく管理既定を決めたり複数体制を作ることのできない会社なのではないでしょうか?

短絡的でそこそこ効果のある手段は複数担当にすることです。

それにしても、今後それでよいというわけではないので、目線を遠くにおいて組み立てることを進めます。


なにはともあれ、管理者として姿勢の基本は

「何かあったときに、すべて管理者ができたら、管理者のせいだと言われてしまう。自分の身を守るために、管理者としてやることはすべて監視してください。」

とういものなんですけどね。


あまりオススメはしませんが、何かにつけ偉い人に「管理者は全部見られるでしょ?○○さんがやったんですよ」と言って、相手に「それが物理的にできないこと」を証明する必要があるように追い込むという手もあります。ただ、経営者は「ITはよくわからん。管理者は仕方ないんじゃないか」と諦めてることも多いかな。

制御することは可能なんですが、それにも一定の技術がいるんですよね。

お金があるならベンダーさんに入ってもらう手もあります。


http://www31.atwiki.jp/memo77/

id:flowergift

ご回答ありがとうございます。

ご提案いただいた、情報セキュリティ対策の一部として、管理者アカウントが適切に運用されるよう仕組み作りを行う、という話については、筋が通っており大変良いと思いました。参考にさせていただきます。ありがとうございます。

なお、情報セキュリティ規定は内部規定として存在するものの、諸般の事情により十分に機能していない、というのが実情です。これを良い機会ととらえて改善のための提案をしていきたいと考えています。

また、長期的な対策は上記のように進めるとして、とりあえず現在、何が起こっているか確かめたいという事もあり、私の手元の環境では以下のようにしました。

1. Windowsファイアウォールとは別のパケットフィルタリングソフトを導入し、自ホストへのTCP接続要求を(RDPを除いて)全て遮断。アウトバウンド方向の通信も、必要なもののみ残して他は遮断。

 ・Windowsファイアウォールと別のソフトを導入したのは、アウトバウンド方向の通信に対しても制限を行いたかったため。

 ・ドメインコントローラとの通信は入出力とも遮断 (これは一時的な措置です)

  ログオンスクリプトの実行履歴や、適用されるポリシのログを取得する方法が不明だったため、やむなくこのようにしました。

2. リモートデスクトップの接続要求のみをCygwinのinetd(+tcpd)で受けるようにし、接続ログを採取。

3. リモートレジストリのサービス、管理共有を停止。

また、tasklist.exeの出力結果などを他のコンピュータとざっと比較したところ、一応、怪しいプロセスは居ないように見えました。といってももともとドメイン管理者の管理下にあったPCであるという事を考慮すると、標準コマンドが置き換わっていたり、カーネルモードrootkitが入っていたりするとお手上げですので、ほんの気休めですが……。ひとまずこれで様子を見ようかと思っています。(一応、RootkitRevealerを用いた簡単な確認程度は行いました)

2008/06/23 01:25:20

その他の回答(2件)

id:memo77 No.1

memo77回答回数238ベストアンサー獲得回数202008/06/20 08:22:47ここでベストアンサー

ポイント100pt

1.PCで行った操作はすべて知ることができます。

キーロガーを動作させることもできますし、画面を定期的にキャプチャすることも、ローカルのファイルを見ることもできます。

メールボックスをコピーすることも、閲覧したサイトのキャッシュを取得することも可能です。


2.あなたがAD管理者でない限り、AD管理者を相手になにかをすることはできません。基本は

・会社として管理規定を決める。

・複数の担当者を配置し、相互監視するルールをつくる。

・日常的な管理者アカウントによるログオンは禁止し、必要なときのみ管理者アカウントでログインし、ログを取る。

・管理者アカウントを使用した際の操作は記録できるものは記録し、できないものは他者の目視の下で作業する。

といった感じです。



まあ、相手を疑ったり責めたりしても組織としていい結果は出ないので、「社会的に内部統制やコンプライアンスの遵守が求められている」ので、会社全体でその取り組みを進めながら、部分として「情報セキュリティポリシーの策定とそれにともなう管理者権限の抑制を行う」のが基本です。


ただ、おそらく管理既定を決めたり複数体制を作ることのできない会社なのではないでしょうか?

短絡的でそこそこ効果のある手段は複数担当にすることです。

それにしても、今後それでよいというわけではないので、目線を遠くにおいて組み立てることを進めます。


なにはともあれ、管理者として姿勢の基本は

「何かあったときに、すべて管理者ができたら、管理者のせいだと言われてしまう。自分の身を守るために、管理者としてやることはすべて監視してください。」

とういものなんですけどね。


あまりオススメはしませんが、何かにつけ偉い人に「管理者は全部見られるでしょ?○○さんがやったんですよ」と言って、相手に「それが物理的にできないこと」を証明する必要があるように追い込むという手もあります。ただ、経営者は「ITはよくわからん。管理者は仕方ないんじゃないか」と諦めてることも多いかな。

制御することは可能なんですが、それにも一定の技術がいるんですよね。

お金があるならベンダーさんに入ってもらう手もあります。


http://www31.atwiki.jp/memo77/

id:flowergift

ご回答ありがとうございます。

ご提案いただいた、情報セキュリティ対策の一部として、管理者アカウントが適切に運用されるよう仕組み作りを行う、という話については、筋が通っており大変良いと思いました。参考にさせていただきます。ありがとうございます。

なお、情報セキュリティ規定は内部規定として存在するものの、諸般の事情により十分に機能していない、というのが実情です。これを良い機会ととらえて改善のための提案をしていきたいと考えています。

また、長期的な対策は上記のように進めるとして、とりあえず現在、何が起こっているか確かめたいという事もあり、私の手元の環境では以下のようにしました。

1. Windowsファイアウォールとは別のパケットフィルタリングソフトを導入し、自ホストへのTCP接続要求を(RDPを除いて)全て遮断。アウトバウンド方向の通信も、必要なもののみ残して他は遮断。

 ・Windowsファイアウォールと別のソフトを導入したのは、アウトバウンド方向の通信に対しても制限を行いたかったため。

 ・ドメインコントローラとの通信は入出力とも遮断 (これは一時的な措置です)

  ログオンスクリプトの実行履歴や、適用されるポリシのログを取得する方法が不明だったため、やむなくこのようにしました。

2. リモートデスクトップの接続要求のみをCygwinのinetd(+tcpd)で受けるようにし、接続ログを採取。

3. リモートレジストリのサービス、管理共有を停止。

また、tasklist.exeの出力結果などを他のコンピュータとざっと比較したところ、一応、怪しいプロセスは居ないように見えました。といってももともとドメイン管理者の管理下にあったPCであるという事を考慮すると、標準コマンドが置き換わっていたり、カーネルモードrootkitが入っていたりするとお手上げですので、ほんの気休めですが……。ひとまずこれで様子を見ようかと思っています。(一応、RootkitRevealerを用いた簡単な確認程度は行いました)

2008/06/23 01:25:20
id:keroronX No.2

keroronX回答回数211ベストアンサー獲得回数42008/06/20 11:40:12

ポイント60pt

何ができるかということについては、管理共有とリモートデスクトップができれば「何でもできます」


具体的には、リモートデスクトップでドメイン管理者権限でログインできれば、スパイウェア系の監視ソフトのインストールすら可能ですので、キーロガーや画面キャプチャまで含めてPCの全動作を記録できると考えてよいと思います。(オンラインバンクのパスワードとかすら取り出せるということです)


また管理共有だけでも、メールデータとかはすべてローカルから奪えますので、保管しているメールデータはすべて「見られる」と考えて間違いないと思います。上記のリモートデスクトップと併せれば、スナップショット系のバックアップソフトをインストールすることで、メールを消したとしても全て復元できるので、保管・削除の有無すら関係なくなります。


会社側の考え方としては、会社のPCはあくまでも業務だけに使うことを大前提にしていると思いますので、上記のような手段を使って情報収集をしても(これらツールを使うことについて会社の許可を得ていれば)、それは「不正に収集」とはみなされない可能性が高いです。



また「行われた」事実のログですが、少なくともリモートデスクトップでログインすれば「イベント」としてwindows標準のログに残すことが可能ですが、そのための設定変更は少なくともローカルの管理者権限がないと実行できません。


もし会社のポリシーで各ユーザにローカルの管理者権限が与えられているのであれば、ローカルセキュリティポリシーから監査内容について、「ローカルポリシー」-「監査ポリシー」-「ログオンイベントの監査」の「成功・失敗」を有効にすれば、イベントビューアからどのようにログインされているのかを見ることができるようになります。


また同じ場所にある「オブジェクトアクセスの監査」も有効にすれば、誰がどのファイル・フォルダを閲覧したのかもログに取ることができます。


上記のログについては、ひょっとしたらドメインのグループポリシーで有効にされているかもしれませんので、一度イベントビューアの「セキュリティ」を見てみることをお勧めします。(ただし特にオブジェクトアクセスの監査を行っている場合は、ログが膨大で見辛いです。)

id:flowergift

ご回答ありがとうございます。

情報収集の正当性についてですが、管理や情報漏洩対策などの適切な目的のために正しく運用されているのであれば、情報収集をされても問題無いと考えています。今回は、私の見当違いであることを祈っています。

ローカルセキュリティポリシの確認項目についてご教授いただきありがとうございました。

ログオンイベントの成功・失敗の確認は行えるようになりました。また、「オブジェクトアクセスの監査」はすでに成功・失敗とも有効となっており、チェックボックスがグレーアウトしており無効にできない状態になっていました。一応、イベンロビューアの「セキュリティ」で、それらしき監査ログが生成されているのは確認できました。

他にも確認するべき項目があれば、ご教授いただければ幸いです。

2008/06/23 01:34:43
id:redwing1 No.3

redwing1回答回数541ベストアンサー獲得回数32008/06/22 21:53:44

ポイント10pt

とれる対応は暗号化することくらいですね。メールとか、見られてはまずい書類とかを暗号化しておいておくのです。といってもportで監視されているとどうしょうもないですが、のぞきみている程度ならこれでOKでしょう。

法的には私物ではなく、業務なので、見ること自体を禁止することはできないと思います。それを業務ではなく、私的に使っていることが問題なので、経営陣に被害をとどけるしかないでしょう。届けられないような被害なら、あなたが悪いのです。

id:flowergift

ひょっとすると誤解されておられるかもしれませんが、今回の質問は「会社のコンピュータを私的利用していたら管理者に見られて言いふらされて困っている」という類の話ではありません。もしそのような話なら論外だと私も考えていますので、最初から質問しません。

今回の質問は「Windowsのドメイン管理者が自由に使える(ADに関連する)バックドアはどんな種類があるか(RDP、管理共有以外に)」、「それらのバックドアの使用状況をローカルコンピュータ上でログに取る方法にはどのようなものがあるか」という趣旨です。他の事項は関係ありませんので、よろしくお願いいたします。

2008/06/23 02:04:23
  • id:memo77
    独自にソフトウェアがインストールできるようですので、それほど厳しい環境ではないようですね。
    会社的にドメイン管理者に無断でソフトウェアをインストールするのが認められているならその対応でもいいと思います。


    ただし、同じことをうちの会社でやったら、あなたのドメインアカウントは停止+PCの使用禁止+始末書。
    場合によっては解雇ですね。
    なぜなら、ドメコンと接続を切るということはウイルス対策やPCのステータス管理に穴を開けることであり、無断でソフトウェアをインストールすることはセキュリティポリシーに反してるからです。
    管理共有も管理者がPCの状態を適切に保つために必要だと判断しているのであれば、管理者がアクセスしたログを記録し監査するべきで、遮断するべきではありません。


    不適切な対応をしてくる相手に対して不適切な対応をするということは、あなた自身が弱みを抱えるということで、マイナスになりこそすれ、プラスにはなりません。
    逆に、「同じ会社内で、なぜそこまでして隠す必要があるの?」と追求を受ける可能性もあります。
    もちろん「見ていい」といっているわけではないです。
    もし過去見られていたのだとすれば、いま隠したからといって情報の流出量にそれほど差はないでしょう。
    それなら拙速な対応で弱みを作るよりも、正攻法でいくのをオススメします。
  • id:flowergift
    コメントありがとうございます。

    今回の一連の対応も含め、既存の利用規定を逸脱した行為は行っていません。

    しかしながら、memo77さんにコメントを頂いてから、社内PCの運用のあるべき姿についてあらためて考え直した所、今回の私の対応は適切ではなく、改善のための新たな提案の邪魔になるものだとの認識に至りました。(当の提案者がこのような運用をしていては、提案に説得力が無くなってしまうため)

    また、今回質問するに至った問題の、そもそもの問題は「情報収集の有無」そのものではなく「管理者アカウントが適切に運用される事を保障する仕組みが存在するか」という点である事にも思い至りました。よって、仮に今回の質問のような目的が達せられ、ローカルコンピュータ側でログを採取できるようになったとしても意味が無いとの認識に至りました。
    さらに考えを進めると、これは、管理者アカウントに限った問題ではなく、社内PC環境が適切に運用される事を保障するためには何をしなければならないか? という話になりますね。

    上記の話は、今読み返すと、最初にご指摘を頂いていますね。十分に理解していなかったようです。お恥ずかしい限りです。

    そういうわけで、結局のところ私の手元環境はすべて元通りにしました。

    これを機会に、少しでも改善を図れるよう実のある提案に結び付けたいと思います。今回は勉強になりました。ご回答いただいた皆様、ありがとうございました。
  • id:memo77
    いるか、ありがとうございました。
    よい結果が出ることをお祈りします。

この質問への反応(ブックマークコメント)

トラックバック

  • 悪意を持ったネットワーク管理者の対処方法 はてなの質問ピックアップ 2008-06-26 13:01:31
    社内のActive Directoryのドメイン管理者が信用できません 私の会社のAD管理者は、もともと、飲み会の席で 「○×の部署の奴らは、夕方になるとデリヘルのサイトばかり見ている」 といっ
  • kozihの日記 - [AD] 2009-01-06 12:09:52
    [AD] AD環境でログオン・ログオフの履歴 for Windows Server 2008 - GStudio Blog Const AUDIT_SUCCESS = 8 ’ Create Objects Set objShell = WScript.CreateObject("WScript.Shell") Set objNetwork = WScript.CreateObject("WScript.Ne
「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません