ADでまとめて参照できるようになります。このようなログは不正アクセスの検出に役立つだけでなく、様々な法令に基づいて証跡を保持しなければならないようなケースにおいても有効です。ADのログの参照方法や保持方法について解説します。Directory]より確認できます。Directory]-[サインイン]よりそれぞれ参照します。[監査ログ]では、管理作業のジャンルやその操作の結果(成功・失敗)、対象となるユーザーなどを選択し、フィルターできます。Users」というサービス名を選択すれば、該当のログだけが表示されます。特定のログはクリックすると、その詳細を参照でき、日付、アクティビティの種類(どのような操作を行ったか)、状態(成功・失敗)などを確認できます。万が一、不正アクセスが疑われるような事象があった場合、監査ログを参照することで、その事象の確認ができるようになります。ちなみに、下の画面ではゲストユーザーを削除したことを表しています。前回のコラムでは、GUIやCUIの管理ツールを用いたオブジェクトの作成および管理について解説しました。今回は、オブジェクトの監査について解説します。Directoryのオブジェクトに対する操作を記録することです。小規模な環境であれば1人の管理者によって全てのオブジェクトの管理をおこなうことも可能ですが、ある程度以上の規模の場合には複数人の管理者で管理することも少なくありません。このような場合、特定のユーザーに対して必要最低限の管理権限を与えて運用します。複数人で管理することで、設定ミスやインシデントが起きる可能性は高くなることが考えられます。監査の設定をおこない、「誰が」「いつ」「どのオブジェクトに対して」「どのような」操作をおこなったのかを記録することで、設定ミスの早期発見やインシデントが起きてしまった際にどのようなことがおこなわれたかを把握するのに役立ちます。Directoryのオブジェクトの監査をおこなうためには、以下の2つの設定が必要です。Directoryへの書き込みやプロパティの変更などを監視し、操作の内容をイベントログとして出力できます。グループポリシーには、監査を有効化するためのポリシー設定が用意されています。監査をおこなうには、そのポリシー設定を構成し、ドメインコントローラーに対してグループポリシーを適用する必要があります。Directoryのオブジェクトの監査をおこなうためには、次のいずれかのポリシー設定を構成します。情シス担当者であれば、社内システムやインフラの構築/運用/保守や社員PCのトラブルシューティングで、日々サーバーやネットワーク機器を扱っているでしょう。このとき、管理者の方は、各情シス担当者が実際にどんな作業を行っているか把握していますか。現場メンバーが非常に重要度の高いサーバーやシステムに対する操作を行う際、リアルタイムの監視や定期的な監査を実行できているでしょうか。今回は、特権ID利用におけるリスクと監査人に求められる要件に関してご案内します。特権ID利用においてどのようなリスクがあるか、ご存知ですか。特権ID(WindowsのAdministrator権限やLinuxのroot権限)にシステムにアクセスした時にできることをご紹介します。上記一覧を見るとわかるように、特権IDはあらゆる操作ができる「非常に強力な権限」を持っています。それがゆえ、管理におけるリスクも非常に大きいIDであり、性善説の考えに基づき、通常業務で特権IDを使用する情シス担当者に手放しでID管理を任せることは、非常に危険な行為です。実際に特権IDが悪用されて個人情報が漏えいしてしまう事件や、操作ミスによりシステム障害に発展する事件も起きており、会社への信頼/コスト面で膨大な損失を被るケースもあります。このようなリスクを避けるためにも、特権IDを用いた重要システムへの操作については、「立ち合い」を必須とする監査要件が設けられるケースがあるのが現状です。立ち合いが必須になる場合、立ち合い業務に対応する担当者(監査人)にとっては、業務負荷が高まります。多くの場合、監査人は他の業務も兼任しており、作業が必要なタイミングですぐに対応できるとは限りません。情シス担当者にとっては、立会人が作業室にいるタイミングでしか作業を行えないというデメリットがあります。この他、いくら監査人が立ち会ったとしても、実際の操作履歴が残らなければ信頼性に欠けるという課題も残ります。監査という行為そのものが形骸化し、細部まで確認されていなかったり、監査人と作業者が結託して操作ミスを隠蔽していたりする可能性を指摘されると、否定できません。欠ける」という課題があります。上記のようにリスク/課題が多い特権IDについて、特権ID管理ソフトウェアを使用した場合の管理策をご案内します。通常の特権ID管理ソフトウェアでは、特権IDを使って「誰が」「いつ」「どのシステムで」「何を操作したか」記録する機能が備わっています。これにより、情シス担当者の操作内容を全て把握することが可能になります。イベントビューア上に出力されるイベントID:4624は、ローカルコンピューター上で発生したログオン成功イベントを記録しています。このイベントは、アクセスのあったコンピューター上、言い換えればログオンセッションが生成されたコンピューター上に生成されます。対するイベントID:4625は、ログオン失敗イベントが発生した際に生成されるイベントログとなり、こちらについては次回で詳しくご紹介していきたいと思います。イベントID:4624は、以下のOSに出力されます。2003以前の場合、同じ内容のイベントがイベントID:528・540として出力されます。イベントビューア上に出力されるイベントID:4625は、ローカルコンピューター上で発生したログオン失敗イベントを記録しています。このイベントは、ログオンの試行があったコンピューター上に生成されます。イベントID:4625が出力されるOSは、以下の通りです。2003以前の場合、同じ内容のイベントがイベントID:529・530・531・532・533・534・535・536・537・539として出力されます。セキュリティの脅威は日々上昇傾向にあり、ハッカーの攻撃方法はさらに洗練されつつあります。Report」を発表しました。調査レポートには、5万3000件のサイバー攻撃と2,200件のデータ侵害を分析した統計データや、最新のセキュリティインシデントに関する情報が含まれており、その中に以下の内容が記されています。データ侵害の被害を受けた際に、87%のケースでは攻撃の数分後、あるいはさらに短い時間で情報が奪取されていたにも関わらず、半数以上の攻撃は発覚までに1か月以上要しています。検知できないような手法を使用していることを意味します。多くのケースにおいて、データ侵害はフォレンジック分析を専門に行うようなサードパーティーにより検知されます。データの窃取に必要な時間はわずか数分である一方、侵害の方法/ネットワーク内での侵害の過程/侵害経路の発覚には、数か月以上かかる場合があります。侵害が判明するころには、すでに重要なデータが盗まれている可能性が高いのです。SOCが侵害を検知できなかった場合でも、攻撃の兆候は残ります。昨今、ITセキュリティの現場はGDPRなどの厳格なコンプライアンス規定の登場に伴い、変化を遂げつつあります。企業は、重要なデータが窃取される前に検知・対応できるようなソリューションを探し求めており、SIEMはその最適な方法といえます。本ブログでは、クラウド型Webサイト監視サービスSite24x7について紹介します。「Site24x7」の読み方ですが「サイト・トゥウェンティフォー・バイ・セブン」と読みます。Site24x7は、世界のさまざまな場所(50以上)からWebサイトを監視できるWebサービス(クラウド)です。下図はご利用画面のイメージです。Site24x7では次のような監視に対応しています。監視をしているサイトのステータス情報を公開ページとして公開することもできます。次のイメージは公開ページの例です。Site24x7の動画(英語)を紹介します。ご利用の流れは次のとおりです。英語になりますが、ヘルプドキュメントはこちらです。