近年、高度サイバー攻撃による国内被害が増加しています。高度サイバー攻撃では、攻撃者は明確な目的をもっており、その目的を達成するため、プロセスを踏んで組織内ネットワークに侵入し、長期的な攻撃を繰り返します。攻撃者がコンピューターへ侵入後、自由にリソースへアクセスするため、まずはドメイン管理者やサーバー管理者権限のアカウント情報の入手を試みます。Directory環境への攻撃を行うことが可能です。脆弱性(MS14-068)については、以下のブログ記事にてご紹介していますので、興味のある方は、ご一読いただければと思います。4672が記録されます。意図していないアカウントに対して、このイベントログが出力されていた場合、MS14-068の脆弱性が悪用され、攻撃者が不正に権限昇格をおこなったことが考えられるため、攻撃検知のための監査対象として有効です。4672を出力するための監査ポリシーの設定手順についてご案内します。Plusを使用した場合の確認方法についてご紹介します。Plusには、200以上の定義済みレポートがあると記載しましたが、ドメイン認証を使用したログオンに関するレポートとしては、以下の15つをご用意しています。一覧からお分かりいただける通り、一言に「ログオンレポート」といっても様々な観点でのレポートがあり、ログオン失敗理由別、ドメインコントローラー別、ユーザー別と確認することが可能となっています。Plus側でコンピューターアカウントによるログオンイベントは自動で除外するため、純粋にユーザーによるログオン認証イベントを確認することが可能です。イベントビューアーから確認する場合は、フィルターをかけたうえで、さらに一つ一つ目で見て判断を行う必要がありました。Plusにログインし、レポート名をクリックするだけで、監査を行うことが可能となるのです。Plus」について、少しでもご興味を持っていただけましたら、「30日間の無料トライアル(評価版)」を是非お試しください。評価期間中は、技術サポートもご利用可能です。9x系のOSでは、ユーザー名とパスワードの入力が必須ではなく、Escキーを押すことで、省略してログオンすることができました。9x系のOSが個人での利用を前提につくられており、本人以外が使用する可能性、およびそこへの配慮が重要視されていなかったためです。企業でのコンピューターの使用が一般的となっている現代では、複数の人が同じコンピューターを使用する場合もあれば、ネットワーク越しに不正にコンピューターへアクセスされ、社内の情報が奪取されるという場合もあります。このような状況において、誰もがコンピューターにログオンできるという状態はまず避けなければいけないことであり、安全な使用のためには、コンピューターへログオンするアカウントの管理、および不審なログオン認証が行われていないかの監査が必要とされています。ワークグループ環境の場合、各コンピューターが独立して存在しているため、管理や監査が困難となります。運用ポリシーに則った適切なパスワードが設定されているか、パスワードが定期的に変更されているか、といったことを把握しようとした場合、システム管理者は一台一台の設定状況を確認する必要があります。Directory環境で管理することにより、効率的にユーザーの認証・管理を行うことができます。Directoryの概要や必要性については、以下のブログ記事にてご案内しておりますので、興味のある方は、ご一読いただければと思います。Directory環境において、意図したアカウントによるログオンが行われているか、不審なログオン失敗の履歴が存在していないかということを確認するためには、どうすればよいでしょうか。本投稿の前編では、イベントビューアーを使用した確認方法について、ご案内していきたいと思います。Directory環境において、ユーザーがログオンすると、認証情報がドメインコントローラーに送られ、認証情報の検証を行います。ドメインコントローラー側で認証データが正しいことが確認できた場合はチケットが発行され、今後クライアントは、このチケットを使用してリソースにアクセスすることができるようになります。ログオンの成功・失敗を決定する、この「事前認証」の結果は、以下のイベントIDにて、イベントビューアー上に出力されます。本投稿の前編では、JPCERT/CCが発行している資料をもとに管理専用端末の必要性についてご説明しました。後編では、弊社製品を使用した場合におけるソリューションについてご紹介します。Proとは、特権ID利用時の「申請/承認フロー」「操作画面の録画」「パスワードの非表示運用/自動更新」機能などを提供するツールであり、本製品を踏み台としてITリソースへアクセスすることで、特権IDへのアクセス経路を一本化することが可能です。Proサーバーに限定し、管理専用端末として位置付けることで、JPCERT/CCが提唱している運用を可能とします。Proを踏み台としてドメインコントローラーへアクセスすることで、操作内容はすべて動画として記録されるため、内部からドメインコントローラーに対して怪しい操作をしていないかということを、簡単に確認することができます。Proサーバを設置することにより、管理専用端末を経由したドメインコントローラーへのアクセスが「本来の挙動」となり、それ以外のサーバーからのドメインコントローラーへのアクセスは「不審な挙動」となります。Plus」を使用して検知を行います。ドメイン参加しているコンピューターがドメイン認証を使用してログオンする場合、まずはドメインコントローラーと通信を行い、認証をおこなう必要があります。外出先などでドメインコントローラーにアクセスできない環境の場合でも、一時的にドメインユーザーを使用して端末にログオンすることができるように、Windowsではログオン資格情報をキャッシュして保持しています。ログオンのキャッシュ機能が有効になっている場合、ログオンに成功したときの資格情報が、デフォルトで10個までキャッシュされます。10個を超えた場合、古いものから削除され、常に最新10個の情報が有効となります。この機能があることにより、ドメインコントローラーと通信ができない環境でも、ドメインユーザーを使用したログオンが可能となります。それは、利用者にとっては便利な機能となりますが、場合によっては危険を伴う可能性があります。ドメイン参加している端末に不正侵入されてしまった際に、キャッシュ情報から、管理者アカウントの情報まで盗まれてしまうというリスクが考えられます。そこで、JPCERT/CCでは、管理者アカウントを使用してドメインコントローラーに接続し、管理を行う端末を「管理専用端末」として限定して運用する方法を推奨しています。以下では、JPCERT/CCが提供している資料をもとに管理専用端末設置の必要性についてご説明します。管理者アカウントの認証情報が保持されている端末はサイバー攻撃の対象となりやすいため、管理者専用端末を用意し、管理者アカウントを使用したドメインコントローラーやサーバーの管理を、専用端末に限定する方法が推奨されています。ファイアウォールやルータなどを使用して、管理専用端末の通信先を制限することで、サイバー攻撃のリスクをより軽減することが可能です。以下の図は、Microsoft社が推奨しているセグメント化の例となります。セグメントごとにファイアウォールを設置し、それぞれをきちんと管理していくことは、すべての企業にとって容易なことではありません。そこで、JPCERT/CCの資料には、補足として以下の内容が記載されています。Directory環境では、多くの場合ローカル管理者アカウントではなく、ドメイン管理者アカウントを使用されるのではないかと思います。ドメイン管理者アカウントは、ドメイン内の全ての端末にアクセスでき、リソースを参照することができる便利なアカウントであるため、つい多用されがちです。一方で攻撃者側からすれば、管理者アカウントの情報を窃取することでドメイン内のリソースに自由にアクセスできてしまうため、恰好の的といえるでしょう。そこで、本投稿を読んでくださっている皆さまに質問です。管理者アカウントを複数の端末に対して使用するほど、例えばPass-the-Hash攻撃などで、キャッシュされたパスワード情報が盗まれた際、管理者アカウントの情報が窃取されるリスクが高まります。そのため、管理者アカウントは限定した端末のみに対して使用することが大切です。アカウントを利用した端末の妥当性の調査」では、イベントID4624,4625,4768,4769,4776のイベントが記録されたアカウントやクライアント端末を確認し、運用で意図しない認証が行われていないかということを確認する必要があると記載されています。その理由として、管理者アカウントを使用する端末をあらかじめ限定しておいた場合、それ以外の端末から管理者アカウントを使用した不正な認証が行われた際に、検知がしやすくなるからです。管理者アカウントを使用する端末を限定していない場合、悪用されたとしても異常として判断しにくく、検知が遅れてしまう可能性があります。機能の利用が有効です。機能を使用した確認方法についてご案内したいと思います。