第2回 Azure ADを使って安全にクラウドサービスへアクセスする【MicrosoftのMVP解説!Azure ADの虎の巻】

Reading Time: 1 minutesこの記事の所要時間: 約 5分 ◆ 今回の記事のポイント ◆ ・ Azure ADを利用したSSO(シングルサインオン)ガセキュリティに与える影響について解説 皆さんこんにちは。前回からAzure Active Directoryのコラムを担当している国井です。 前回、Azure Active Directory (Azure AD) を利用することで、それぞれのクラウドサービスにアクセスするたびにユーザー名・パスワードを入力しなくてもよくなる、という話をしました。このような仕組みを「シングルサインオン」と呼びますが、今回はシングルサインオンを行うことがセキュリティに与える影響についてお話します。 シングルサインオンは1回のユーザー名・パスワードの入力操作でどこにでもアクセスできる仕組みです。そのため、利用者側 (ユーザー) から見れば、ブラウザーでユーザー名・パスワードがキャッシュされているのと、Azure ADを使ってシングルサインオンしているのは、どちらも同じに見えます。そのため、Azure ADの利用を社内で検討するときは「わざわざAzure ADを利用するメリットがあるのか?」という議論もあるでしょう。 この質問に対する、セキュリティ面から見た答えは「まったく違います」。...

ADAudit Plus , セキュリティ , 一般 1 min read

セキュリティ基準を設けることの重要性

Reading Time: 1 minutesこの記事の所要時間: 約 1分 セキュリティ管理者に求められる重要なポイントの一つに、Active Directoryのセキュリティ対策における、現在の自分たちの立ち位置を正確に把握することが挙げられます。そのためには、Active Directoryに関する情報を広範囲にわたり収集することが大切です。 Active Directoryに対するセキュリティ基準の策定 まずは、現在行われているセキュリティ設定の中でコンプライアンスに準拠しないもの、または全体のセキュリティ要件を満たさないものを洗い出し、対策をとることが求められます。 以下が、調査と対策のために見るべき設定の一例です: ・ 特権を有するセキュリティグループ ・ ユーザーの権利 ・ パスワードポリシー ・ アカウントロックアウトポリシー ・ Active Directory 委任 ・ グループポリシー 委任...

ADAudit Plus , ADManager Plus 1 min read

UberのセキュリティインシデントからみるGDPR準拠へのポイント

Reading Time: 1 minutesこの記事の所要時間: 約 2分 年々利用者を増やしており、特に海外では多くの人に親しまれているUberですが、昨年、その人気が危ぶまれる出来事が発生しました。 Uberは、欧州連合(EU)の中でその成長率を維持するために、広報、法的課題、マーケティング活動に多くのリソースを費やしてきました。そのような活動の中、2017年11月掲載のUberのブログにて、2016年10月ごろに受けたサイバー攻撃を公開せず、隠ぺいしていたことが明らかとなりました。同社はブログにて、昨年10月に5000万人のユーザー情報と700万人のドライバーの名前、メールアドレス、電話番号、運転免許証の番号が流出し、漏洩した情報に対する一切の黙秘を条件に、ハッカーへ10万ドルを支払っていたことを報告しました。もともとこのようなセキュリティ違反は重大なインシデントとなりますが、EUの一般データ保護規則(GDPR)が施行された今、Uberにとっては、EUで再び信頼を得るための大きな障壁となり得ます。 ● どのようにして攻撃が発生したのか? Uberのエンジニアは、開発のためにGitHubコーディングサイトを使用していましたが、ハッカーはそのサイトの抜け穴を利用してログイン情報を取得後、個人データを抜き出しました。Uberは、すでに今後の攻撃を阻止するための対策を講じていると主張していますが、今回ポイントとなるのは、セキュリティ違反を直ちに公表しなかったという点です。実際、問題が発生したタイミングでは違反を報告する義務はありませんでしたが、GDPRが施行された今、欧州で同様のことが発生した際には、企業にとって深刻な事態となります。 ● GDPR施行後に問題が発生した場合はどうなるのか? 今回の問題では、EU市民の個人データが多数漏洩してしまいましたが、GDPRは、このような問題に対して重いペナルティを課しています。例えば、制裁金として、最大2000万ユーロ(約26億円)、あるいは年間売り上げの4%のいずれかのうち、高額な方を支払う必要があります。また、違反があったことを直ちに公表しなかったという事実は、EU市民の信頼を大きく損なうことにつながるでしょう。 ● GDPRを遵守するために必要なこと 今回のセキュリティ違反を踏まえて、2018年5月25日に施行されたGDPRを遵守するために求められることを、以下に挙げていきたいと思います。 セキュリティ違反が発生した際には、速やかに検知し、被害を最小限に留めるための措置をとること。また、発生72時間以内に、監督機関へ報告をおこなうこと。いずれかを怠った場合、GDPRの違反につながります。 データが保管されている場所(物理、仮想、クラウドなどに関わらず)に対して、企業は不正なアクセスからデータを保護し、安全性を継続的に検証するためのセキュリティ対策を講ずること。 カスタムアプリケーションやサービスを使用している場合は、同様に監査対象とすること。企業はセキュリティの穴を防ぐため、これらのアプリケーションやサービスで起こっている活動を監査し、記録する必要があります。 ● GDPRへの準拠にManageEngineはどのように貢献できるのか? ManageEngineでは、GDPRに準拠するためのツールとして、以下を提供しています。   関連情報をCheck! >> GDPR対応ソリューション

ADAudit Plus , Desktop Central , EventLog Analyzer 1 min read

【JPCERT/CC提唱】不審なタスク作成の調査

Reading Time: 1 minutesこの記事の所要時間: 約 3分 攻撃者がコンピューターに侵入後、不正なプログラムを実行するために、タスクスケジューラを悪用するケースがあります。タスクスケジューラとは、WindowsOSにて標準搭載されている機能であり、決められた時間、あるいは一定の間隔にて、プログラムやスクリプトを実行することが可能な「タスク管理ツール」です。タスクスケジューラの脆弱性として、2014年9月に「CVE-2015-0098」が報告されており、この脆弱性を利用することで特別に細工されたアプリケーションの実行、および以下の操作を行うことが可能です。 ・ プログラムをインストールする ・ データを表示、変更、削除する ・ 管理者権限をもつアカウントを作成する 上記のような不正な操作を検知するための手段として、不審なタスクが生成されていないことを、定期的にタスクスケジューラにて確認する方法があります。以下では、設定されているタスクの確認方法についてご案内します。   1.タスクスケジューラの確認方法 1) スタート > 管理ツール > タスクスケジューラ を開きます。 2) タスク スケジューラ ライブラリ をクリックします。 3)...

ADAudit Plus 1 min read

【JPCERT/CC提唱】特権をもつアカウントの使用を監視

Reading Time: 1 minutesこの記事の所要時間: 約 3分 近年、高度サイバー攻撃による国内被害が増加しています。高度サイバー攻撃では、攻撃者は明確な目的をもっており、その目的を達成するため、プロセスを踏んで組織内ネットワークに侵入し、長期的な攻撃を繰り返します。 図1 高度サイバー攻撃のプロセス   攻撃者がコンピューターへ侵入後、自由にリソースへアクセスするため、まずはドメイン管理者やサーバー管理者権限のアカウント情報の入手を試みます。その方法の一つとして、ドメイン認証で使用されるKerberosに対する仕様上の脆弱性を利用する場合があり、その攻撃手法やツールはインターネットで公開されていることから、誰でも、比較的簡単にActive Directory環境への攻撃を行うことが可能です。なお、脆弱性(MS14-068)については、以下のブログ記事にてご紹介していますので、興味のある方は、ご一読いただければと思います。 ▶「MS14-068」の脆弱性とは?JPCERT/CCが推奨するログの活用方法と併せてご紹介   1.特権をもつアカウントの使用を監視する方法 ドメイン管理者権限などの、特権が割り当てられているアカウントが使用された場合、イベントID 4672が記録されます。意図していないアカウントに対して、このイベントログが出力されていた場合、MS14-068の脆弱性が悪用され、攻撃者が不正に権限昇格をおこなったことが考えられるため、攻撃検知のための監査対象として有効です。 図2 イベントID4672のイベントログ   以下では、イベントID 4672を出力するための監査ポリシーの設定手順についてご案内します。 ≪イベントログ出力のために必要な監査ポリシーの設定≫ コンピューターの構成 > Windowsの設定 > セキュリティの設定...

ADAudit Plus 1 min read

Active Directoryのログオン認証を監査するには(後編)

Reading Time: 1 minutesこの記事の所要時間: 約 1分   本投稿の前編では、イベントビューアーを使用したログオン認証の監査方法についてご案内しましたが、後編では、弊社製品ADAudit Plusを使用した場合の確認方法についてご紹介します。 楽々!わかりやすい!ADAudit Plusを使用したログオン認証イベントの確認方法 ADAudit Plusには、200以上の定義済みレポートがあると記載しましたが、ドメイン認証を使用したログオンに関するレポートとしては、以下の15つをご用意しています。 一覧からお分かりいただける通り、一言に「ログオンレポート」といっても様々な観点でのレポートがあり、ログオン失敗理由別、ドメインコントローラー別、ユーザー別と確認することが可能となっています。 各レポートからは、「いつ」「誰が」「どこから」ログオンしたのか、失敗の場合は「なぜ失敗したのか」という詳細な内容まで確認することができ、さらに、ADAudit Plus側でコンピューターアカウントによるログオンイベントは自動で除外するため、純粋にユーザーによるログオン認証イベントを確認することが可能です。 ▼ ログオン監査機能を動画で紹介  イベントビューアーから確認する場合は、フィルターをかけたうえで、さらに一つ一つ目で見て判断を行う必要がありました。しかし、ADAudit Plusはそれらをすべて自動で行ってくれるため、システム管理者は複雑な作業の一切を行う必要がなく、ADAudit Plusにログインし、レポート名をクリックするだけで、監査を行うことが可能となるのです。 もし、ManageEngineが提供するActive Directory監査ログ分析ツール「ADAudit Plus」について、少しでもご興味を持っていただけましたら、「30日間の無料トライアル(評価版)」を是非お試しください。評価期間中は、技術サポートもご利用可能です。 無料で使えます[機能制限なし] ダウンロードはこちら | 概要資料はこちら 前編へ移動...

ADAudit Plus 1 min read

Active Directoryのログオン認証を監査するには(前編)

Reading Time: 1 minutesこの記事の所要時間: 約 5分 目次 イベントビューアーを使用したログオン認証イベントの確認方法 イベントログ出力のために必要な監査ポリシーの設定 もっと簡単に確認できるツール Windows 9x系のOSでは、ユーザー名とパスワードの入力が必須ではなく、Escキーを押すことで、省略してログオンすることができました。それは、Windows 9x系のOSが個人での利用を前提につくられており、本人以外が使用する可能性、およびそこへの配慮が重要視されていなかったためです。しかし、企業でのコンピューターの使用が一般的となっている現代では、複数の人が同じコンピューターを使用する場合もあれば、ネットワーク越しに不正にコンピューターへアクセスされ、社内の情報が奪取されるという場合もあります。このような状況において、誰もがコンピューターにログオンできるという状態はまず避けなければいけないことであり、安全な使用のためには、コンピューターへログオンするアカウントの管理、および不審なログオン認証が行われていないかの監査が必要とされています。 ワークグループ環境の場合、各コンピューターが独立して存在しているため、管理や監査が困難となります。例えば、運用ポリシーに則った適切なパスワードが設定されているか、パスワードが定期的に変更されているか、といったことを把握しようとした場合、システム管理者は一台一台の設定状況を確認する必要があります。そこで、ある程度のネットワークの規模が大きくなる場合は、Active Directory環境で管理することにより、効率的にユーザーの認証・管理を行うことができます。なお、Active Directoryの概要や必要性については、以下のブログ記事にてご案内しておりますので、興味のある方は、ご一読いただければと思います。 【 連載:ADについて学ぼう 】 では、Active Directory環境において、意図したアカウントによるログオンが行われているか、不審なログオン失敗の履歴が存在していないかということを確認するためには、どうすればよいでしょうか。本投稿の前編では、イベントビューアーを使用した確認方法について、ご案内していきたいと思います。 イベントビューアーを使用したログオン認証イベントの確認方法 Active Directory環境において、ユーザーがログオンすると、認証情報がドメインコントローラーに送られ、認証情報の検証を行います。そして、ドメインコントローラー側で認証データが正しいことが確認できた場合はチケットが発行され、今後クライアントは、このチケットを使用してリソースにアクセスすることができるようになります。ログオンの成功・失敗を決定する、この「事前認証」の結果は、以下のイベントIDにて、イベントビューアー上に出力されます。 4768 Kerberos 認証チケット (TGT)...

ADAudit Plus 1 min read

【JPCERT/CC提唱】 管理専用端末を用いたセキュアな運用(後編)

Reading Time: 1 minutesこの記事の所要時間: 約 2分 本投稿の前編では、JPCERT/CCが発行している資料をもとに管理専用端末の必要性についてご説明しました。後編では、弊社製品を使用した場合におけるソリューションについてご紹介します。 Password Manger ProとADAudit Plusを併用した対策 Password Manger Proとは、特権ID利用時の「申請/承認フロー」「操作画面の録画」「パスワードの非表示運用/自動更新」機能などを提供するツールであり、本製品を踏み台としてITリソースへアクセスすることで、特権IDへのアクセス経路を一本化することが可能です。本記事にて、特権IDとは管理者アカウント(例:Administrator)を指しますが、管理者アカウントを使用したドメインコントローラーへのアクセスをPassword Manger Proサーバーに限定し、管理専用端末として位置付けることで、JPCERT/CCが提唱している運用を可能とします。また、Password Manger Proを踏み台としてドメインコントローラーへアクセスすることで、操作内容はすべて動画として記録されるため、内部からドメインコントローラーに対して怪しい操作をしていないかということを、簡単に確認することができます。 ▼ Password Manger Proの申請/承認ワークフロー このように、管理専用端末としてPassword Manger Proサーバを設置することにより、管理専用端末を経由したドメインコントローラーへのアクセスが「本来の挙動」となり、それ以外のサーバーからのドメインコントローラーへのアクセスは「不審な挙動」となります。この「不審な挙動」について、次にご紹介するログ監査ツール「ADAudit Plus」を使用して検知を行います。 図2 Password...

ADAudit Plus , Password Manager Pro 1 min read

【JPCERT/CC提唱】 管理専用端末を用いたセキュアな運用(前編)

Reading Time: 1 minutesこの記事の所要時間: 約 2分 ドメイン参加しているコンピューターがドメイン認証を使用してログオンする場合、まずはドメインコントローラーと通信を行い、認証をおこなう必要があります。しかし、外出先などでドメインコントローラーにアクセスできない環境の場合でも、一時的にドメインユーザーを使用して端末にログオンすることができるように、Windowsではログオン資格情報をキャッシュして保持しています。ログオンのキャッシュ機能が有効になっている場合、ログオンに成功したときの資格情報が、デフォルトで10個までキャッシュされます。そして10個を超えた場合、古いものから削除され、常に最新10個の情報が有効となります。 この機能があることにより、ドメインコントローラーと通信ができない環境でも、ドメインユーザーを使用したログオンが可能となります。それは、利用者にとっては便利な機能となりますが、場合によっては危険を伴う可能性があります。例えば、ドメイン参加している端末に不正侵入されてしまった際に、キャッシュ情報から、管理者アカウントの情報まで盗まれてしまうというリスクが考えられます。 そこで、JPCERT/CCでは、管理者アカウントを使用してドメインコントローラーに接続し、管理を行う端末を「管理専用端末」として限定して運用する方法を推奨しています。以下では、JPCERT/CCが提供している資料をもとに管理専用端末設置の必要性についてご説明します。 管理者専用端末設置の必要性 管理者アカウントの認証情報が保持されている端末はサイバー攻撃の対象となりやすいため、管理者専用端末を用意し、管理者アカウントを使用したドメインコントローラーやサーバーの管理を、専用端末に限定する方法が推奨されています。さらに、ファイアウォールやルータなどを使用して、管理専用端末の通信先を制限することで、サイバー攻撃のリスクをより軽減することが可能です。以下の図は、Microsoft社が推奨しているセグメント化の例となります。 図1 セグメント化の例 ● DCセグメント ドメインコントローラーおよびドメイン管理者権限を使用する端末(管理専用端末)だけを設置 ● サーバセグメント インターネットに公開しない重要なサーバおよび各サーバの管理専用端末だけを設置 ● クライアントセグメント 一般ユーザが使用する業務用端末を設置 ※ JPCERT/CC 「ログを活用したActive Directoryに対する攻撃の検知と対策」より引用 しかし、セグメントごとにファイアウォールを設置し、それぞれをきちんと管理していくことは、すべての企業にとって容易なことではありません。そこで、JPCERT/CCの資料には、補足として以下の内容が記載されています。 前提条件を満たすのが難しい場合は、運用ルールで制限することによって一定の効果が期待できる...

ADAudit Plus , Password Manager Pro 1 min read

【JPCERT/CC提唱 】複数の端末にアクセスしたアカウントを監査

Reading Time: 1 minutesこの記事の所要時間: 約 4分   Active Directory環境では、多くの場合ローカル管理者アカウントではなく、ドメイン管理者アカウントを使用されるのではないかと思います。ドメイン管理者アカウントは、ドメイン内の全ての端末にアクセスでき、リソースを参照することができる便利なアカウントであるため、つい多用されがちです。しかし、一方で攻撃者側からすれば、管理者アカウントの情報を窃取することでドメイン内のリソースに自由にアクセスできてしまうため、恰好の的といえるでしょう。そこで、本投稿を読んでくださっている皆さまに質問です。 「管理者アカウントを使用する端末は、きちんと管理されていますか?」 管理者アカウントを複数の端末に対して使用するほど、例えばPass-the-Hash攻撃などで、キャッシュされたパスワード情報が盗まれた際、管理者アカウントの情報が窃取されるリスクが高まります。そのため、管理者アカウントは限定した端末のみに対して使用することが大切です。 JPCERT/CCが2017年7月に公開した資料『ログを活用したActive Directoryに対する攻撃の検知と対策』の「4.3.2. アカウントを利用した端末の妥当性の調査」では、イベントID4624,4625,4768,4769,4776のイベントが記録されたアカウントやクライアント端末を確認し、運用で意図しない認証が行われていないかということを確認する必要があると記載されています。その理由として、管理者アカウントを使用する端末をあらかじめ限定しておいた場合、それ以外の端末から管理者アカウントを使用した不正な認証が行われた際に、検知がしやすくなるからです。一方、管理者アカウントを使用する端末を限定していない場合、悪用されたとしても異常として判断しにくく、検知が遅れてしまう可能性があります。 JPCERT/CCが挙げていた、イベントID4624,4625,4768,4769,4776のイベントをイベントビューアーから確認する場合、カスタム ビュー機能の利用が有効です。一時的にログを確認する場合には、[ セキュリティ ]を右クリックして [ 現在のログをフィルター ]を選択することで、フィルターをかけることも可能ですが、監査は継続的に確認することが求められるため、以下ではカスタム ビュー機能を使用した確認方法についてご案内したいと思います。 ■ JPCERT/CC推奨のイベントIDを確認する方法 (イベントビューアー使用時) 1.[ 管理ツール ]...

ADAudit Plus 1 min read