Quantcast
Channel: ManageEngine ブログ
Viewing all 376 articles
Browse latest View live

【MicrosoftのMVP解説!Active Directoryのハウツー読本】 第3回 Active Directoryのキホン(2)

$
0
0
Reading Time: 1 minutes
この記事の所要時間: 約 5分

今回の記事のポイント
・ Active Directoryのキホンとなる3つのキーワード (スキーマ、パーティション、管理ツール) について解説

 
本コラムは前回に続いて、Active Directoryを管理していく上で「キホン」となる概念やキーワードについて解説していきます。まだ前回(第2回)のコラムをご覧いただいてない方は、ぜひ前回のコラムと併せてご覧になってください。今回は、「スキーマ」、「パーティション」、「管理ツール」という3つについてピックアップして解説します。

■ スキーマ

スキーマとは、Active Directoryの「オブジェクトに関する定義情報」となるものです。スキーマでは、どの種類のオブジェクトがどのような属性を使用するのかを関連付けて管理しており、オブジェクトの作成時などにはスキーマの情報が参照されます。Active Directoryには様々な種類のオブジェクトがありますが、ここではユーザーを例に考えてみましょう。ユーザーの作成そのものについては別のコラムで紹介しますが、ユーザーを作成してプロパティを確認すると、最初から様々な属性の項目が用意されています。これらが用意されているのは、スキーマ内で「ユーザーで使用する属性はコレとコレと…」というように既定で定義されているためなのです。

スキーマには、「クラス」と「属性」という2つの情報が存在します。このうち、「クラス」がオブジェクトの種類を表すもので、ユーザー、コンピューター、グループなどの様々なクラスが存在します。一方、「属性」は各オブジェクトのプロパティの項目を表すもので、表示名、ログオン名、電話番号、電子メール、などの様々な属性が存在します。スキーマではこの2つの情報を関連付けて、どのクラスでどの属性を使用するかを管理しています。そのため、いつオブジェクトを作成しても同じ属性の項目が使用できるようになっているのです。

■ パーティション

パーティションとは、「Active Directoryデータベース内の論理的な”仕切り”」です。Active Directoryデータベースはntds.ditという単一のファイルで存在し、ドメインコントローラー上で管理されます。しかし、このファイル内には、論理的な仕切りであるいくつかのパーティションを持っており、どの情報がどのパーティション内に格納されるかが決まっています。また、Active Directoryデータベースは可用性を高めるために複数のドメインコントローラー間で複製されますが、パーティションによってどの範囲のドメインコントローラーと複製するのかも異なります。Active Directoryデータベースファイルのパーティション構造、各パーティションに格納される情報、各パーティションがどの範囲のドメインコントローラーに複製されるかをまとめると、以下のようになります。

前回のコラムで、「ドメインはオブジェクトを管理する単位である」と解説しましたが、そう言える理由は上記のようにパーティションによって複製される範囲が異なるためです。ドメインパーティションにはユーザーやコンピューターなどのオブジェクト情報が格納されますが、複製される範囲は同じドメインのドメインコントローラーに限られます。そのため、同じドメイン内に複数のドメインコントローラーを展開した場合には、ドメインパーティションだけでなく、他のパーティションも含めてどのドメインコントローラーも完全に同じ情報を保有することになります。しかし、フォレスト内でドメインを分けた場合、スキーマパーティションと構成パーティションについてはどのドメインコントローラーも同じ情報を保有しますが、ドメインパーティションはドメインによって異なる情報を保有します。

■ 管理ツール

次回のコラムでドメインコントローラーの展開方法について解説しますが、ドメインコントローラーを展開すると、Active Directoryを管理するための様々な管理ツールが一緒にインストールされます。Active Directoryを管理するための管理ツールには次のようなものがあります。

管理ツール 主な用途
Active Directoryスキーマ スキーマの作成および管理
Active Directoryサイトとサービス サイトの作成および管理
Active Directoryドメインと信頼関係 信頼関係の作成やおよび管理
Active Directoryユーザーとコンピューター オブジェクトの作成および管理
Active Directory管理センター オブジェクトの作成および管理

これらの管理ツールを使用してActive Directoryの管理ができるわけですが、これらの管理ツールからおこなう操作は、上記で紹介したパーティションに対する操作であると考えることもできます。例えば、Active DirectoryユーザーとコンピューターやActive Directory管理センターという管理ツールは、オブジェクトの作成や変更をおこなうために使用しますが、それらはパーティションでいうとドメインパーティションに対する操作です。また、Active Directoryドメインと信頼関係という管理ツールは、信頼関係の作成や確認をおこなうために使用しますが、これらは構成パーティションに対する操作であると言えます。このように考えると、単純に操作をおこなうだけでなく、その操作がどの範囲に影響を及ぼすのか?ということについても、イメージがしやすくなるのではないかと思います。

今回は、前回に続いて、Active Directoryの「キホン」となる概念およびキーワードとして、「スキーマ」、「パーティション」、「管理ツール」の3つについて紹介しました。前回のコラムと併せてご覧いただき、それぞれについてのイメージをつかんでいただければと思います。次回はドメインコントローラーの展開方法について解説します。

筆者紹介
新井 慎太朗 (あらい しんたろう)
株式会社ソフィアネットワークに勤務し、2009年よりマイクロソフト認定トレーナーとしてトレーニングの開催やコース開発に従事。前職である会計ソフトメーカー勤務時には、会計ソフトの導入サポート支援や業務別講習会講師を担当。これらの経歴も活かして、ユーザー視点や過去の経験談なども交えながらのトレーニングを提供。主にWindows OS、仮想化技術関連のマイクロソフト認定コースを中心に講師として活動しながら、近年の書籍の執筆などの活動も評価され、2017年からMicrosoft MVP for Enterprise Mobilityを受賞。
主な著作は『ひと目でわかるAzure Information Protection』 (日経BP)、『徹底攻略MCP問題集 Windows Server 2016』『徹底攻略MCP問題集 Windows 10』(インプレスジャパン)、『ひとり情シスのためのWindows Server逆引きデザインパターン』 (エクスナレッジ) など。

 

ゾーホー社員のつぶやき

今回、Active Directoryの基本となる3つの概念について学習する中で、ドメインの作成および管理を行う管理ツール「Active Directoryユーザーとコンピューター」・「Active Directory管理センター」の2つが紹介されました。ManageEngineでは、これらに相当する機能をWebベースで実現できるツールとして、ADManager Plusを提供しています。また、ADManager Plusでは、ドメインの管理に加えてワークフロー機能や権限の委任機能など、管理作業をより効率的に実施するための便利な機能を備えています。

■ 「ADManager Plus」とは?
WebベースのGUIにてActive Directoryのユーザー/コンピューター/ファイルサーバーを管理し、自動化やワークフローなどを容易に実行できるActive Directory運用管理ツールです。さらに、Active Directoryのユーザーを作成時にクラウドベースのOffice 365ユーザーも同時に作成することができるなど、ユーザー管理にかかる工数を大きく削減することが可能です。

(関連資料) ADManager Plusを使用してOffice365管理を効率化
ホワイトペーパーをダウンロード

■ ADManager Plusの製品ページ
https://www.manageengine.jp/products/ADManager_Plus/



▼▼ 過去記事はこちら ▼▼
【MicrosoftのMVP解説!Active Directoryのハウツー読本】第1回 Active Directoryの必要性
【MicrosoftのMVP解説!Active Directoryのハウツー読本】第2回 Active Directoryのキホン(1)

▼▼ 別シリーズのブログ記事もチェック! ▼▼
【MicrosoftのMVP解説!AzureADの虎の巻】第1回 AzureADを利用する意味
【MicrosoftのMVP解説!AzureADの虎の巻】第2回 Azure ADを使って安全にクラウドサービスへアクセスする


Log360がガートナー社のマジック・クアドラント(SIEM部門)に2年連続で掲載!

$
0
0
Reading Time: 1 minutes
この記事の所要時間: 約 2分

ManageEngine Log360は2016年に続き、”2年連続”でガートナー社のマジック・クアドラント(SIEM部門)に掲載されました。

ガートナー社とは、米国に本社をおく業界最大のアドバイザリ企業です。マジック・クアドラントでは、特定のテクノロジー市場における販売会社を、ガートナー社が中立的な立場から「リーダー」・「ビジョナリー」・「ニッチ」・「チャレンジャー」という4つのクアドラントに分類し、その位置づけを公開しています。

なお、Log360は2016年3月に本社リリース、そして2018年9月に日本リリースされた製品で、「ログの統合管理」に特化した簡易SIEMツールとなりますが、リリースの年である2016年、そして2017年と続いて「ニッチ(特定市場志向型)」としての位置づけで掲載されました。

レポートにて、ガートナー社のアナリストはLog360の強みを以下のように述べています:

・ 統合管理ソリューションに関心のあるManageEngineの既存ユーザー、あるいはコストパフォーマンスに優れたシンプルなSIEMツールを探している企業は、Log360やEventLog Analyzerの利用が推奨されます。

・ Log360には、監査とコンプライアンスに関わる機能が数多く提供されています。複数のコンプライアンスに特化したレポートを含めて、1,200以上の定義済みレポートが存在します。

ADAudit Plusは、単一または複数のActive Directory(ドメインコントローラー)を対象とした、認証・アクセスなどの監査に対応しており、内部統制対策としての機能を提供します。

・ Log360は他の多くのSIEMツールと比較すると、シンプルな構造になっているため、直感的に使用することが可能です。また、脅威検知を含む、幅広いコリレーションルールがあらかじめ用意されており、特にWindowsを対象とした定義済みレポートや解析ルールが豊富に備わっています。

>> 原文となるマジック・クアドラントレポートはこちらをご参照ください。(英語)

ガートナー社の免責事項
ガートナーは、ガートナー・リサーチの発行物に掲載された特定のベンダー、製品またはサービスを推奨するものではありません。また、最高の評価を得たベンダーのみを選択するようテクノロジの利用者に助言するものではありません。ガートナー・リサーチの発行物は、ガートナー・リサーチの見解を表したものであり、事実を表現したものではありません。ガートナーは、明示または黙示を問わず、本リサーチの商品性や特定目的への適合性を含め、一切の保証を行うものではありません。

 

< これだけでない!Log360の強みをご紹介します >
Active Directoryに特化した監査レポートを200種類以上ご用意
* PaloAlto/Fortinet/Juniperをはじめとする(*1)代表的なファイアウォール機器を自動で集計・可視化
* ドメインユーザーに対する振る舞い検知機能を搭載
* 異なるデバイス間で発生したログを相関的に分析 (製品側で相関分析のためのデフォルトルールを30種類ご用意)
* TLSで暗号化されたSyslogの収集に対応

(*1) レポートのご用意があるファイアウォール機器については、本社デモサイトにアクセスしていただき、レポートタブをご参照ください。

 



■ Log360の製品ホームページ

https://www.manageengine.jp/products/Log360/

■ Log360の概要資料ダウンロード
https://www.manageengine.jp/download/enter.php?Category=ManageEngine&dl=DL_5&nickname=Log360&No=2645

■ Log360の無料評価版ダウンロード
https://www.manageengine.jp/products/Log360/download.html

Elasticsearchの性能監視で見るべき4つの指標

$
0
0
Reading Time: 1 minutes
この記事の所要時間: 約 5分

こんにちは、ManageEngineエンジニアの園部です。本日は、全文検索エンジンのElasticsearchに関する話題をお届けします。

目次

Elasticsearchは、拡張性の高い分散型オープンソースの検索分析エンジンです。構造化されたデータをリアルタイムに格納・取得可能のため、ログ分析、リアルタイムアプリケーションの監視、クリックストリーム分析などに使用されます。

Elasticsearchの特徴は以下の通りです。

  • HTTP Webインターフェースを備えたマルチテナント機能
  • JSON文書の形式でデータを表示し、REST APIを介して全文検索が可能
  • PHPやRuby、.NetやJavaなどの言語用のWebクライアントに対応

Elasticsearchの最大の特徴である、ビッグデータの収集と解析の機能を最大限に活用する第一歩として、
Elasticsearch環境のパフォーマンス状況を把握し、いつでも最良の環境でElasticsearchを動かすことから始めていきましょう!

監視すべきElasticsearchの指標 4項目とは?

Elasticsearchの監視では、見るべき箇所がたくさんありますが、ここでは、特に重要な4つの指標について詳しくご紹介していきます。

1. クラスタのステータスとノードの可用性

クラスタステータスとノードの可用性
Elasticsearchサーバーのパフォーマンスは、インストールされているマシンによって大きく左右されます。
まずは、主要なパフォーマンス・メトリックを監視することが重要です。

クラスタの状態を把握するには、すべてのノードの

  • CPU使用率
  • メモリ使用率
  • ディスクI/O

等、各Elasticsearchノードのステータスをリアルタイムで監視しましょう。

CPU使用率が急上昇してしまった場合は、まずJava仮想マシン(JVM)を調べるのがオススメです。
ElasticsearchはJVMで実行されるため、Elasticsearchのメモリー使用量を監視するには、JVMメモリーとガーベッジ・コレクションの統計を確認しましょう。

2. インデックスのパフォーマンス

インデックスのパフォーマンス
ワークロードの書き込み負荷が高い場合、インデックスを新しい情報で更新してみると、Elasticsearchのパフォーマンスの監視と分析がしやすくなります。

インデクシングレートの急激な上昇や低下が発生した場合は、
データソースに問題が発生している可能性があります。

また、クラスタ全体のパフォーマンスは、リフレッシュ時間とマージ時間の影響を受けることがあります。
このことから、インデックスのパフォーマンスとして、
リフレッシュ時間の短縮とマージ時間の短縮が推奨されます。

Elasticsearchパフォーマンス監視ツールを使用して、

  • 開始時間
  • ノード内の平均セグメント時間
  • ファイルシステムキャッシュ使用率
  • リクエストレート

など、各ノードの平均のクエリレイテンシーを監視していくことが望ましいです。

3. 検索のパフォーマンス

検索のパフォーマンス
インデックスリクエストとは別に、検索リクエストも重要な要素です。Elasticsearchの監視で重要な検索のパフォーマンス指標は以下の2つです:

・クエリレイテンシー時間とリクエスト率

クエリのパフォーマンスに影響を与える可能性のある要素は数多くあります。
例えば、

  • 内容が誤っているクエリ、効率の悪いクエリ
  • Elasticsearchクラスタ
  • JVMメモリー
  • ガーベッジ・コレクション

などです。

クエリレイテンシーは、ユーザーに直接影響を与える要素となるため、非常に重要です。
状態を常に監視し、異常事態の発生時には真っ先に対処することが重要です。

クエリレイテンシとともにリクエストレートを監視することで、システムがどの程度使用されているかも把握可能です。

・フィルターキャッシュ

Elasticsearchのフィルターはデフォルトでキャッシュされます。
フィルターを使用してクエリーを実行すると、Elasticsearchはフィルタに一致するドキュメントを検索し、その情報を使用して「ビットセット」と呼ばれる構造を作成します。

その後のクエリ実行時に、同じフィルタが設定されている場合は、ビットセットに格納されている情報が再利用されます。

これにより、I/O処理とCPUサイクルが節約されるため、クエリの実行速度が向上します。

フィルターキャッシュの状況を把握し、実行速度改善の仕組みが機能しているかを確認できることが望ましいと言えます。

4. ネットワークとスレッドプールの監視

スレッドのステータス
Elasticsearchノードは、スレッドプールを使用して、スレッドメモリとCPUの消費を管理しています。
スレッドプールはプロセッサー数に基づいて自動的に設定されます。

監視するべき重要なスレッドプールと、スレッドプールに発生する問題の一覧を以下にまとめました。

監視すべき対象スレッド スレッドに起こる4大問題
検索
索引
マージ
バルク
保留リクエストが大量に溜まる
ノードの1つが低速になる
スレッドプールのリジェクト

特に、メモリ使用量が急激に変化している場合や、長時間のガーベッジコレクションが発生している場合は要注意です。

ガーベッジコレクションが多発する原因として考えられるのは、

  • ある1つの特定のプールがストレスを受けている
  • JVMのメモリ不足

等が考えられます。ガーベッジコレクションがボトルネックと感じる場合は、最初にここを確認してみてください。

まとめ

Elasticsearchの性能を十分に活かすために監視しておくべき4つの項目をご紹介しました。
大量データの検索や解析が手軽に実現可能となった昨今においても、土台となるサーバーやアプリケーションの保守の重要性は変わりません。
安定稼働や高速化を実現するための第一歩として、4つの項目の監視を始めることをおすすめいたします。

ポイント
  • 土台の安定性確保のため、クラスタのステータスとノードの可用性を監視しましょう!
  • インデックスのパフォーマンスを監視してElasticsearch本来の機能を安定させましょう!
  • ユーザーに影響が及ぶ前に、検索のパフォーマンスを監視して問題が波及しないようにしましょう!
  • スレッドプールを監視して、データのやり取りで問題が起こらないようにしましょう!

 

※ なお、監視すべきポイントの紹介で使用したグラフイメージは、アプリケーション監視・可視化ツールの『ManageEngine Applications Manager』の画面スクリーンショットを使用しています。
これらのスクリーンショットのグラフは、特別な作りこみが必要なく、監視情報の入力で簡単に作成可能です。

Elasticsearchのパフォーマンス監視要件でお困りの際には、ぜひManageEngine Applications Managerをご検討ください!

▼▼ Webシステムの統合監視なら、ManageEngine Applications Manager ▼▼

Applications Manager 公式ホームページ
Applications Managerのダウンロードはこちら
Applications Manager製品概要資料のダウンロードはこちら
※永年無料版の利用をご希望の方は、30日間フル機能ご利用いただける「評価版」をダウンロードしてください。
30日が過ぎると自動的に5モニターまで監視可能の永年無料版となります。

SIEMという選択(前編) –なぜSIEMが選ばれるのか?

$
0
0
Reading Time: 1 minutes
この記事の所要時間: 約 2分

セキュリティの脅威は日々上昇傾向にあり、ハッカーの攻撃方法はさらに洗練されつつあります。
アメリカの通信大手であるVerizon社のビジネス管理部門”Verizon Enterprise Solutions”は、データ侵害に関する調査レポート「Verizon 2018 Data Breach Investigations Report」を発表しました。その中に、以下の内容が記されています。

侵害の60%は、攻撃を受けてから発覚まで1か月以上要しています。そのうち87%の侵害については、攻撃をうけた数分後、あるいはそれより短い時間の間に、すでに情報漏洩が起きていたにも関わらずです。

これはつまり、攻撃者はSOC (Security Operation Center) も検知できないような手法を使用していることを意味します。
多くのケースにおいて、データ侵害はフォレンジック分析を専門に行うようなサードパーティーにより検知されます。データの窃取に必要な時間はわずか数分である一方、侵害の方法/ネットワーク内での侵害の過程/侵害経路の発覚には、数か月以上かかる場合があります。つまり侵害が判明するころには、すでに重要なデータが盗まれている可能性が高いのです。

出典:Verizon 2018 Data Breach Investigations Report (ゾーホー翻訳)

たとえSOCが侵害を検知できなかった場合でも、攻撃の兆候は残ります。昨今、ITセキュリティの現場はGDPRなどの厳格なコンプライアンス規定の登場に伴い、変化を遂げつつあります。企業は、重要なデータが窃取される前に検知・対応できるようなソリューションを探し求めており、SIEMはその最適な方法といえます。

< SIEMが必要となる3つの理由 >

  1. セキュリティツールに対する横断的な調査:社内ネットワークの保護のために、いくつかのセキュリティツールを併用している企業は少なくないかと思います。例えば、ファイアウォール・IDS/IPS・脆弱性スキャナー・ウイルス対策ソフトなどがその一例です。しかし、攻撃の兆候をいち早く検知するためには、システムや機器のログを「個々」ではなく「横断的」に追跡することが求められます。そこで、異なるフォーマットのログを一元的に管理し、串刺し検索ができるようなツールの導入が推奨されます。SIEM製品は複数のデバイスのログを一元的に管理することができ、さらに相関的に分析することで、ネットワーク状況の可視化や不審な動きの検知に役立ちます。
  2. 継続的な監視:セキュリティの確保には、ファイアウォールのルールやアクセス制御リストといった設定が不可欠です。そして、これらの重要なセキュリティポリシーは設定後そのままとするのではなく、定期的に監視し、意図しない変更が加えられていないことを確認する必要があります。SIEM製品は定期的なレポーティング機能を提供しており、継続的にログを監視して、重要な構成変更や平常時と異なる不審な挙動の有無を監視します。
  3. サービスデスクツールとの連携:企業は様々なツールを使用してIT運用の効率化を図ります。例えば、サービスデスクツールはITサービスやシステムに関するインシデントを管理する際に使用されます。そこで、サービスデスクツールとの連携を行い、疑わしいログが生成時に自動で適切な担当者へ割り当てることが可能なSIEM製品を導入することで、異常を検知後に速やかな調査につなげることが可能です。

以上が、SIEMが必要となる理由についてのご紹介です。次回の記事では、SIEM製品を選定する際の基準について解説します。

>> SIEMという選択(後編) – SIEM製品を選択する基準とは?


関連製品をCHECK! >> 低コストな簡易SIEMソフトなら「Log360」

 

 

【MicrosoftのMVP解説!Active Directoryのハウツー読本】 第4回 ドメインコントローラーの展開方法

$
0
0
Reading Time: 1 minutes
この記事の所要時間: 約 4分

今回の記事のポイント
・ ドメインコントローラーの展開方法について解説
・ ドメインコントローラーとRODCの違いについて解説

 
皆さんこんにちは。Active Directoryのコラムを担当している新井です。これまでのコラムでは、ワークグループとドメインの違いや、Active Directoryの概念やキーワードなどについて解説してきました。今回は、Active Directoryドメインの環境における主要なコンポーネントであるドメインコントローラーの展開方法について解説します。

■ ドメインコントローラーの展開

ドメインコントローラーを展開する前に、決定しておくべきことがいくつかあります。その中でも最も重要なのが「配置構成」の決定です。配置構成では、どの展開パターンでドメインコントローラーを構成するかについて、3つの選択肢の中から選択します。その3つの展開パターンをまとめると、以下のようになります。

■ ドメインコントローラーの展開方法

ドメインコントローラーの展開には2つのフェーズがあり、1つ目のフェーズとなるのが役割の追加です。Windows Serverをドメインコントローラーとして構成するためには、WebサーバーやDHCPサーバーとして構成するときと同様に、役割の追加が必要です。役割の追加は、Windows Serverの管理ツールである「サーバーマネージャー」から「管理」、「役割と機能の追加」の順にクリックし、表示されるウィザード内で「Active Directoryドメインサービス」のチェックボックスをオンにして進めるだけです。この役割の追加によって、Windows ServerにActive Directory Domain Servicesという名前のサービスが登録されます。

2つ目のフェーズは、構成ウィザードの実行です。1つ目のフェーズとして役割のインストールをおこないましたが、それだけではまだサービスが開始されません。ドメインコントローラーとして動作させるためには、構成ウィザードを実行する必要があります。役割のインストールが完了すると、構成ウィザードを実行するためのリンクが表示されるため、それをクリックして構成ウィザードを開始します。構成ウィザードの実行時には、事前に解説した配置構成を含む、いくつかのパラメーターを設定します。「既存ドメインにドメインコントローラーを追加」のパターンにおいてはその他のパラメーターとして、どのドメインに追加するのかの指定やそのための資格情報の入力、DNSやRODCなどの展開オプション、データベースのインストールパスなどの指定が求められます。

■ ドメインコントローラーの展開オプション

ドメインコントローラーを構成する際には、RODC (Read Only Domain Controller:読み取り専用ドメインコントローラー) と呼ばれる展開オプションがあります。レプリケーションのしくみについては次回以降のコラムで解説しますが、ここでは通常のドメインコントローラーとRODCの違いについて紹介しておきます。通常のドメインコントローラーは、データベースに対して変更をおこなうことができるドメインコントローラーです。したがって、ユーザーアカウントの作成やプロパティの変更などの操作が可能であり、おこなわれた変更内容は他のドメインコントローラーに複製されます。一方、RODCはデータベースに対して読み取りの権限のみを持つドメインコントローラーです。したがって、RODCではデータベースの参照や他のドメインコントローラーからの複製を受け取ることはできますが、RODCからデータベースに対して変更をおこなうことはできません。

RODCは、管理者が不在であったり、セキュリティ的な懸念事項がある拠点に対してドメインコントローラーを構築する際のオプションとして考えて頂くと良いでしょう。拠点などにドメインコントローラーを構築する際に上記のような懸念事項がある場合には、拠点内のドメインコントローラーでの誤った変更操作が他のドメインコントローラーに複製されてしまったり、ドメインコントローラーおよびデータベースそのものが物理的に盗難されてしまうといった可能性が考えられます。そのようなリスクを軽減するための展開オプションとしてRODCという選択肢が用意されているのです。RODCとして運用すれば、そこからデータベースに対する変更はおこなわれることはありませんし、拠点内で使用するユーザーなどのパスワードのみをRODC上に保有して運用することができます。

今回はドメインコントローラーの展開方法について解説しました。次回は、複数のドメインコントローラー間でおこなわれる複製のしくみについて解説します。

筆者紹介
新井 慎太朗 (あらい しんたろう)
株式会社ソフィアネットワークに勤務し、2009年よりマイクロソフト認定トレーナーとしてトレーニングの開催やコース開発に従事。前職である会計ソフトメーカー勤務時には、会計ソフトの導入サポート支援や業務別講習会講師を担当。これらの経歴も活かして、ユーザー視点や過去の経験談なども交えながらのトレーニングを提供。主にWindows OS、仮想化技術関連のマイクロソフト認定コースを中心に講師として活動しながら、近年の書籍の執筆などの活動も評価され、2017年からMicrosoft MVP for Enterprise Mobilityを受賞。
主な著作は『ひと目でわかるAzure Information Protection』 (日経BP)、『徹底攻略MCP問題集 Windows Server 2016』『徹底攻略MCP問題集 Windows 10』(インプレスジャパン)、『ひとり情シスのためのWindows Server逆引きデザインパターン』 (エクスナレッジ) など。

 



▼▼ 過去記事はこちら ▼▼
【MicrosoftのMVP解説!Active Directoryのハウツー読本】第1回 Active Directoryの必要性
【MicrosoftのMVP解説!Active Directoryのハウツー読本】第2回 Active Directoryのキホン(1)
【MicrosoftのMVP解説!Active Directoryのハウツー読本】第2回 Active Directoryのキホン(2)

▼▼ 別シリーズのブログ記事もチェック! ▼▼
【MicrosoftのMVP解説!AzureADの虎の巻】第1回 AzureADを利用する意味
【MicrosoftのMVP解説!AzureADの虎の巻】第2回 Azure ADを使って安全にクラウドサービスへアクセスする

 

SIEMという選択(後編) – SIEM製品を選択する基準とは?

$
0
0
Reading Time: 1 minutes
この記事の所要時間: 約 3分

記事の前編では、企業がSIEMを選択すべき理由について解説しました。後編となる今回は、SIEM製品を選定する際の基準についてご紹介します。

■ SIEM製品の選定で重要となる「予算面」

SIEM製品を選定する際、予算というのは非常に重要な検討項目の一つです。SIEM製品によっては、処理するログ流量がライセンスの課金対象となっているものもあれば、監視対象となるデバイス数に基づき課金されるものもあります。デバイス数に基づく価格設定となっており、ログ流量には影響されない場合、生成されるログのボリュームの量にかかわらず金額が一定となるため、コストの見積もりが容易になります。

しかし、予算以外にも重要な事項はもちろん存在します。そのいくつかを、以下でご紹介したいと思います。

SIEM製品を選定する際に考慮すべき4つの事項

1.対応デバイスの範囲:ルーター・スイッチ・ファイアウォール・IDS/IPSなどのネットワークデバイスに加え、アプリケーション、サーバー、ワークステーション、さらにはクラウドサービスなど、様々なデバイス・サービスが企業で利用されています。SIEM製品を導入する際には、監視対象とするデバイスを一つのツールで包括的に管理できるかどうか、さらにデバイスの登録に多くの工数を必要としないかという点も併せて確認することが大切です。

ManageEngine Log360は、750を超えるデバイスからのログ収集に対応しています。また、「追加フィールド機能」を使用することで、正規表現を使用した解析ルールを自由に定義することができ、可視性を高めることが可能です。

 

2.ログを分析・可視化するレポーティング機能:SIEM製品の特長として、複数ログに対する横断的な分析への対応が挙げられます。ログ管理プロセスを自動化し、重要なメッセージを監視することで、脅威の早期検知に寄与します。そのためには、セキュリティ面だけでなく、対応が必要なコンプライアンスの双方に対して有用なレポートがデフォルトで搭載されており、効率よくログの可視性を高めることができるSIEM製品が推奨されます。また、重要性の高い情報を一画面に集約したダッシュボード画面と、そこから必要な情報を数クリックで掘り下げて確認できるドリルダウン機能が含まれていることで、分析に伴う作業の効率性をさらに高めることが可能です。

ManageEngine Log360には、サポートデバイスを対象とした1,000以上の定義済みレポートが用意されています。また、PCI-DSS・SOX・GDPRをはじめとする各種コンプライアンスに対応したコンプライアンスレポートにより、コンプライアンス対応をスムーズに行うことが可能です。

 

3.フォレンジック分析:ログ分析にかかる時間は、攻撃を検知するまでにかかる時間と比例します。記事の前編でもご案内しましたが、「攻撃の検知」は「攻撃の遂行」と比べて大幅に時間がかかる傾向にあります。したがってSIEM製品に求められるのは、幅広いデバイスから受信する大量のログを取りこぼしなく収集し、それを相関的に分析するとともに、疑わしいログが発生した際に即座に通知を行うような機能の搭載です。また、インシデントが発生した際に過去のログを遡って調査ができるよう、ログを長期保管できる仕組みも大切です。

ManageEngine Log360コリレーション機能を使用することで、異なるデバイス、異なるログ種別から発生したログを相関的に分析して、ネットワーク間で発生している不審な動きを検知することが可能です。また、ログの長期保管を行う場合は、アーカイブ化を行うことで圧縮した状態での保存ができ、さらに必要に応じて暗号化や改ざん検知の設定を行うことで、よりセキュアにデータを保持できます。

 

4.柔軟なカスタマイズ:たとえSIEM製品にセキュリティ(コンプライアンス)レポート、アラートプロファイルや相関分析のルールが豊富に組み込まれていたとしても、それが企業の運用ルールに合致していない、あるいは使いづらいなどで利用が難しい場合、無駄なものとなってしまいます。そこで、アラートプロファイルのしきい値を微調整したり、レポートの項目を変更するなど、企業に合わせた柔軟なカスタマイズが必須です。故にSIEM製品には、「豊富なレポートの提供」と、それに対して簡単に変更を加えられる「カスタマイズ性」の2点が備わっていることが求められます。

ManageEngine Log360コリレーション機能は、企業の運用に合わせて自由にしきい値を変更したり、ルールの再定義を行うことが可能です。

 

以上がSIEM製品を選定する際の基準についてのご紹介でした。

なお、本記事で登場した「Log360」とは、ManageEngineが提供する簡易SIEMソフトであり、あらゆるログの収集・長期保管、そしてActive Directoryログの可視化を低コストで実現します。
SIEM製品を検討されており、少しでもLog360にご興味を持っていただきましたら、ぜひ30日間の無料評価版にて実際の操作感をお確かめください。

▼ManageEngine Log360の評価版をダウンロード▼
https://www.manageengine.jp/products/Log360/download.html

▼ManageEngine Log360の概要資料をダウンロード▼
https://www.manageengine.jp/download/enter.php?Category=ManageEngine&dl=DL_5&nickname=Log360&No=2645


<< SIEMという選択(前編) – なぜSIEMが選ばれるのか?


関連ホワイトペーパーをCHECK! >> コリレーション機能を活用したサイバー攻撃の検知
関連ホワイトペーパーをCHECK! >> 情報セキュリティ対策に必要な重要アラートTOP5

Linuxのセキュリティ対策とパッチ管理:あなたは本当に安全ですか?

$
0
0
Reading Time: 1 minutes
この記事の所要時間: 約 2分

本ブログは、Aravind Ekanath氏による記事を翻訳、一部加筆したものです。リンク表記箇所については、原文から引用しております。

サイバーセキュリティ対策に取り組む際、多くの企業が「どのOSが最も安全なのか?」という疑問を抱くと思います。主要なOSの数から考えても、選択肢はそう多くありません。3大OSの中で、最も安全なOSはどれでしょうか?ビジネス利用において、広く普及しているOSは次の3つです。

  • Microsoft Windows:3大OSの中で最も普及していますが、脆弱性が最も多く存在します。
  • macOS:UnixベースのOSで、Appleシステムを動かします。
  • Linux OS:すべてのLinuxディストリビューション(ディストリ、ディストロとも)を含みます。

NetMarketShareの統計によると、88%のコンピューターでWindowsが使用されています。この高い普及率によって、Windowsはマルウェアの標的になりがちです。2017年の、WannaCryやNotPetyaがその典型的な例と言えます。また、“感染しにくい”と言われているmacOSも、決して安全ではありません。実際、近年ではmacOSのマルウェアが増加しています。そうなると、残る選択肢はLinuxOSのみとなります。WindowsやmacOSと異なり、LinuxOSはオープンソースで開発されているため、 より安全です。加えて、バグやバックドアがないよう、国際的なユーザーコミュニティがコードをレビューしている点も、その高い安全性に寄与しています。

LinuxOSは、現在、最も安全なOSの1つです。そのため、多くのサーバーは、通常、Windows OSではなくLinux OSで開発されています。WIREDに掲載されている記事によると、世界中のWebサーバーの67%でLinuxOSが使用されています。Linuxのセキュリティを破るのは容易ではありませんが、それでもrootアクセスを仕込まれたアプリケーションがシステムにインストールされることなどによって、マルウェア攻撃に晒される可能性があります。これらのアプリケーションは、Linux OSに悪質なパッケージを蔓延させます。AV-TESTが公開したレポートによると、2016年の第2四半期末までに、Linuxのみで検出されるマルウェアの数が前年の2倍に増えたといいます。このような背景から、LinuxOSへのパッチ適用が、いかに重要かを認識する必要があります。

Linuxの脆弱性対策とは?

Linuxのパッチとホットフィックスは、バグと脆弱性に対処するために定期的にリリースされます。例えば、Red Hat Enterprise Linux(RHEL)は、今年、452件のセキュリティアドバイザリーをリリースしました。

Linux OSのセキュリティを高めるパッチ管理

手作業で、OSベンダーが公開するセキュリティアップデートを確認・配布するのはとても手間がかかります。特に、多くのIT資産を所有している場合は、負担がより大きくなります。IT管理者が本当に必要としているのは、多くのアプリケーションのパッチを一元管理できる、Linuxのパッチ管理ソリューションです。このようなソリューションを活用することによって、はじめてLinuxのセキュリティ対策が万全だと言えるでしょう。

Desktop Centralによって実現できること

Desktop Centralは、豊富な機能を備えた資産管理ソフトです。特にグローバルでは、GartnerのCustomers’ choiceに選ばれるなど、高く評価されています。Desktop Centralを利用することによって、管理対象のIT資産に対して、パッチを一元管理することできます。Desktop Centralの便利機能の一例を紹介します。

  • Linux、Windows、macOSのパッチ管理の自動化
  • パッチテストによるパッチの承認
  • パッチ配布のスケジュール設定
  • パッチ、インベントリ、端末設定などに関する豊富なレポート

最近の統計によると、Linuxユーザーの75%が Ubuntu、Debian、Red Hat、CentOSといった、主要なLinuxディストリビューションを使用しています。多くのパッチ管理ソフトは、これらのLinuxディストリビューションをサポートしていません。一方、Desktop Centralは、WindowsとmacOSだけでなく、これらのLinuxディストリビューションもサポートしています。日本でも、新たにRed Hat、CentOSのサポートを近日開始する予定です。

サービスを作ろう – ITの品質向上とコスト削減からとらえたITIL®

$
0
0
Reading Time: 1 minutes
この記事の所要時間: 約 6分

当連載記事について
当連載記事では、ITIL®の研修を多く手掛ける専門家が、分かり易い口語体でより実際的な観点からITIL®を解説しています。サラッと読みながらもITIL®に基づいた考え方をより実践的なレベルへ落とし込むことができます。また、ITIL®に準拠するための機能を備えたITサービスマネジメントツール「ManageEngine ServiceDesk Plus」を提供するゾーホージャパンより、欄外コラムとしてツールの詳細や関連機能の説明を行います。ITIL®の概念を把握しつつ、ツールを活用した場合のイメージを広げる際の一助となりましたら幸いです。
※ITIL® is a Registered Trade Mark of AXELOS Limited.

 

はじめに

第四回第五回でITサービスの品質とコストについて確認しました。今回はいよいよITサービスを作ることを考えていきたいと思います。

ITサービスを作成するためのステップ

実は、ITサービスについては様々なことを明確にする必要があります。ざっと挙げただけでも、「市場」「顧客」「成果」「サービス(とそれを構成している要素)」「サービス間の関係」「価格」などがあります。ITIL®では、これらを8つのステップで明確にしていきつつ、ITサービスを決めていくんですね。

が、この8つのステップをそのまま書くと抽象的でわかりにくいのです。ただでさえ眠くなる話なのに、本当に寝てしまう。なので、私なりにかみ砕いて説明していきます。

まず、ステップはこちら。

(1)顧客がどのくらいいるか確認する
(2)これらの顧客がやりたいこと(顧客成果)を理解する
(3)顧客がやりたいことを目標として数値化する
(4)その数値を満たすようなITサービスを考える(合わせて既存ITサービスが流用できるか考える)
(5)実際にITサービスを使ってくれそうな顧客がどのくらいいるか確認する
(6)そのサービスによってもたらされる顧客成果が何かを決める
(7)ITサービスを構成するものを特定する
(8)ITサービスの組み合わせを決める

そして最後に価格を決める。

では、これらのステップを説明してくことにします。

8ステップの説明

ステップ1:顧客がどのくらいいるか確認する

これは業界や地理、人口統計や企業関係から確認します。人口統計などの文言でわかると思うのですが、ここで言う「顧客」はかなり広い範囲でとらえます。インターネットが普及している世の中なので地域に依存しないとはいえ、極端に言えば世界中ですからね。かなり範囲は広くなります。

ステップ2:これらの顧客がやりたいこと(顧客成果)を理解する

これは「ITを使って」やりたいことではありません。単純にやりたいことです。例えば「手軽に音楽を聴きたい」とか「自宅で仕事したい」とか、第五回目の記事で記載した例で言えば「携帯電話のマニュアルをわかりやすくしてほしい。(わかりやすい携帯電話のマニュアルが見たい)」とかです。

ステップ3:顧客がやりたいことを目標として数値化する

例えば、手軽に音楽を聴きたいのであれば、「通勤時間中に聴ける“楽曲数”を増やす」という案が挙げられるかもしれませんし、わかりやすい携帯電話のマニュアルが見たいのであれば、「マニュアルを見て理解するのにかかる“時間”を減らす」というニーズが存在するかもしれません。このように「数」や「時間」で数値化します。

ステップ4:その数値を満たすようなITサービスを考える(合わせて既存ITサービスが流用できるか考える)

ここでは、ステップ3で考えた数値が目標になるわけですよね。その目標を目指してサービスを考えます。例えば、

・通勤中に聴ける楽曲数が制限されないよう、インターネットから音楽をダウンロードできるようにする(音楽配信サービス)
・文章だけではなく視覚的に理解できるよう、動画マニュアルを閲覧できるようにする(動画配信サービス)

などです。そしてサービスを考えるときに、既存のITサービスを流用できるかどうかも確認する。既存のITサービスを流用できたら楽ですからね。流用できなければ、新規サービスの開発となるわけです。

ステップ5:実際にITサービスを使ってくれそうな顧客がどのくらいいるか確認する

ここでは、ステップ4で考えたITサービスを実際に使ってくれそうな顧客がどのくらいいるか考えます。というのも、顧客にとっては「わかりやすいマニュアル」が見られればよいので、何も動画にこだわらないからです。場合によっては、動画なんかよりも大きな紙で整理されたマニュアルの方がよいかもしれません。

ということで、顧客成果は何も1つのサービスで満たされるとは限りません。その中で、ステップ4で考えたITサービスを買ってくれる顧客がどのくらいいるか確認するんですね。

ステップ6:そのサービスによってもたらされる顧客成果が何かを決める

例えば、音楽配信サービスであれば、「いつでもどこでも好きな音楽を楽しめること」であり、携帯電話マニュアルの動画配信サービスであれば、「直観的でわかりやすいマニュアルを見ながら素早く理解できること」となります。

ステップ7:ITサービスを構成するものを特定する

次に、ITサービスを構成する要素を特定します。具体的には、「必要な人材」「スキル」「ハードウェア」「ソフトウェア」「お金」などです。そして、ステップ6で特定した「成果」と「ITサービス(およびこれらのITサービスを構成する要素)」を紐づけます。

ステップ8:ITサービスの組み合わせを決める

さらに、ITサービスには複数のITサービスが関わることが多いです。例えば、音楽配信サービスであれば、メインとなる音楽を配信するサービス以外に、課金サービス、認証サービスなども必要でしょう。マニュアルの動画配信サービスであれば、メインの動画配信サービス以外に、動画を作成/編集するサービスが必要かもしれません。というようにITサービスは複数のITサービスがまとまっていることが多いので、そのまとまりを明確にします。

そして、この後にITサービスの売価を決めることになり、これらの活動はすべてサービスストラテジというフェーズで行われることになります。

最後に

本当は今回お話したステップが、サービスストラテジのどのプロセスで行われるのかも解説した方がよいとは思うのですが、かなり複雑になります。概要としてのプロセスの流れは第五回に話しているので、今回は割愛させていただきます。次回はサービスデザインにある保証のプロセスのお話をします。

>>記事一覧:ITの品質向上とコスト削減からとらえたITIL®

執筆者情報
日本クイント株式会社 コンサルタント 吉村友秀(よしむら ともひで)
主要資格:ITIL® エキスパート、公認情報システム監査人(CISA)

 



ServiceDesk Plusのサービス・カタログ管理機能について

連載コラムをご一読頂き、ありがとうございます。ManageEngineでは、ITIL®準拠のためのITSM機能を網羅した「ServiceDesk Plus」というツールを提供しています。

今回の記事では、ITサービスを作成する際のお話が出てきました。ここで作成されたサービスは、その後にITIL®の「サービス・カタログ管理」というプロセスで処理されていくことになります。関連して、ServiceDesk Plusの「サービス・カタログ管理」機能については、第4回記事のコラムでもご紹介しました。

ServiceDesk Plusでは、企業/組織のITサービスを、カテゴリーごとの一覧で管理することができます。前回は、サービスを追加/編集/削除する際の管理画面をご紹介しましたが、今回は登録されたサービス一覧がどのように見えるかをご紹介します。

上図の例だと、「メール」というカテゴリーに含まれる各サービス(「メーリングリストの作成」「メールアカウントの作成」etc.)が右側に一覧表示されています。

これらのサービスは、ユーザが利用するためのリクエストフォームと連動しています。例えば、「メーリングリストの作成」というサービスをクリックし、次のようなフォームを呼び出すことが可能です。

フォームの項目は任意でカスタマイズできる他、ここで送信されたリクエストについては以下のような設定も行えます。

・リクエスト追加時に、特定の担当者へ通知する
・リクエストを処理する担当者を自動で割り当てる
・リクエストを遂行する際の「承認者」を設定する

なお、ITIL®が言うサービス・カタログには、「各サービスのスペック詳細」がまとめられているかと思います。これについて、ServiceDesk Plusの管理画面でも「サービスの名称」と共に「説明書き」を追加することはできますが、メインは「サービス要求管理」を行うためのフォーム設定機能となります。

ですので、スペックの詳細や各サービス間の依存関係などは別の方法でまとめて頂き、それらをサービス要求の受付フォームとしてツール上に反映していくことをメインにご活用頂くのが良いかと思います。

<ツールを触ってみたくなったら>

ServiceDesk Plusは、プログラミングの知識が無くてもカスタマイズや設定が行えるように設計されています。検証用に30日間無料で使える評価版(オンプレミス版/クラウド版の両方)もご用意していますが、そこまで真剣に検証できないという方には「体験デモサイト」がお勧めです。

グローバル共用のデモサイトなので、英語のデモデータが登録されていますが、GUIは日本語として表示されますので、ぜひお試しください。

>>体験デモサイトにログイン(※クリック後、実際のツール画面が開きます)

本日ご紹介した「サービス・カタログ」機能については以下よりご覧頂けます。

その他、下記の情報もぜひご利用ください。

<製品について情報収集したい方>

<製品について質問したい方>


AD監査の負荷をツールで大幅軽減!【1】 ADAudit Plusってどんな製品?

$
0
0
Reading Time: 1 minutes
この記事の所要時間: 約 2分

ADAudit Plusは、Microsoftが提供するディレクトリ サービスであるActive Directoryを監査するレポートツールです。本製品を使うことで、Windowsドメイン上で管理されているドメインコントローラー/メンバーサーバー/ファイルサーバーなどのリソース、そしてユーザーやグループ、グループ ポリシーなどのオブジェクト情報から、

簡単に」かつ「見やすい

監査レポートを生成することが可能です。

本製品の特徴として、インストールから利用開始までおよそ10分間で行うことができるという導入の簡単さが挙げられます。監査に必要な手順はたったひとつ、「ドメインコントローラー」の登録のみです。以下に、ドメインコントローラーに関して必要となる設定情報についてご案内します。

dc

図:ドメインコントローラー追加画面

1. ドメイン名を入力します。
2. ドメインコントローラーよりログを取得する際に使用するアカウント情報を入力します。
※Domain Admin以上の権限が必要です。
3. 対象ドメインに対するドメインコントローラーを選択します。

また、ADAudit Plusはイベントログを収集して監査を行います。そのため、必要な監査ログが出力されるよう、監査ポリシーの設定が必要となりますが、ADAudit Plusでは、必要な監査ポリシーの設定も、同画面からワンクリックで行うことが可能です。

dc2

図:ドメイン設定画面

このようにユーザーは複雑な設定を一切行う必要がなく、ドメインコントローラーを登録していただくだけで、直ちにリアルタイムのログ収集・監査を行うことが可能です。

では実際にどのようにレポートとして表示されるのか、ADAudit Plusの画面を一部紹介していきます。

ws000891

図:ダッシュボード画面

ダッシュボード画面からは、重要なレポート情報を一目で確認することができ、さらに自由に追加・削除することが出来る高いカスタマイズ性を持っています。また、画面右側には、最近のアラート通知情報や総数などが表示されています。

次に[レポート]タブからは、200を超える定義済みレポートを表示することが可能です。各レポートは「ログオン失敗」や「最近のユーザー作成」というようにカテゴライズされており、レポート名をクリックすると、データがすべて「ユーザー名」、「クライアントIPアドレス」というような項目に自動的に振り分けられた形で確認することができます。また、ADAudit PlusはクライアントのIPアドレスを取得した際、自動的に名前解決を行うことでホスト名の情報も取得することが可能です。

ws000890

図:[ログオン失敗]画面

ADAudit Plusにて用意されているその他のレポートや機能の詳細については、順次ブログにて紹介していきたいと思います。

※本記事にて掲載しているスクリーンショットは、ADAudit Plusビルド5000に基づいています。

なお実際に操作して各機能をご確認されたい場合は、30日間無料でフル機能をご利用いただける評価版もございますので、是非一度ADAudit Plusをご評価いただければと思います。

製品ホームページ  >> Active Directoryログ監査レポート・ログ管理ツール | ADAudit Plus
ADAudit Plus無料評価版のダウンロードはこちらから >> ADAudit Plus 評価版ダウンロード

( → 次のページへ移動 )

 


☆☆導入から設定までを解説したスタートアップガイドはこちら
☆☆☆ADAudit Plusの概要を紹介した資料はこちら

AD監査の負荷をツールで大幅軽減!【2】 リアルタイムのログ収集

$
0
0
Reading Time: 1 minutes
この記事の所要時間: 約 2分

Active Directoryにて発生するイベントの中で、発生次第すぐに通知を受けたいイベントはありませんか?多くのIT担当者の方にとって、そのような要注意イベントは少なからず存在しているかと思います。そして発生次第すぐ、というのは、3分後、5分後のことをいっているのではなく、イベントが発生した「その瞬間」、という意味です。

多くのイベントログ収集ツールは、スケジュールベースで一定間隔ごとにドメインコントローラーからイベントを収集する仕組みを採用していますが、その場合、5分から30分ほどのインターバルのログ取得間隔が必要になります。つまり、たとえ特定のイベントに対する変更に関連付けたアラートを設定していたとしても、アラート通知は、実際のイベントが生成されてから最低でも5分以上かかる場合があり、時にその5分が致命的となる可能性があります。

ADAudit Plusはこの問題を解決するために、Windows Serverが採用している、Microsoft独自のアルゴリズムを使用した技術をベースに、リアルタイムのイベント収集・アラート通知を行うことが可能です。

この技術の仕組みとして、以前から使用されているAPI機能を活用した方法となりますが、各ドメインコントローラーのセキュリティログに「ステート変更」シグナル信号を送り続け、ADAudit Plusで定義している基準に一致したイベントが発生した場合に、プル サブスクリプションモデルを使用して、イベントを収集します。これにより、ADAudit Plusはリアルタイムでイベントの収集を行ったり、特定のイベントが発生した際には即座にアラート通知を行うこと可能となります。

この技術の最大のメリットとして、不要なログを取得しないためドメインコントローラーへの負荷軽減となり、エージェントも必要としないため構成変更を行なう必要もありません。また、ドメインコントローラーが停止した際に、復旧後にはその間に発生しているイベントもADAudit Plusサーバーが取得できるという点もメリットであります。

なおリアルタイム監査の有効化は、Webクライアント画面上の[ドメインコントローラー設定]から行うことが可能です。

realtime

図1 ドメインコントローラー設定画面

[ドメインコントローラー設定]画面には、[イベント取得間隔]を設定する項目があります。イベント取得間隔には2つのモードがあり、「リアルタイムモード」と「スケジュールモード」のいずれかから選択することが可能です。

ws001216

図2 イベント取得間隔のモード

ここで「リアルタイムモード」を選択することで、遅延のない、即座のイベントログ収集が可能になります。なお基本的にはリアルタイムモードでのログ収集を推奨していますが、「スケジュールモード」を選択することで、5分単位でのスケジュール設定を行うことも可能です。

schedule

図3 スケジュールモード

もし、少しでもADAudit Plusにご興味を持っていただけましたら、「30日間の無料トライアル(評価版)」を是非お試しください。
評価期間中は、技術サポートもご利用可能です。

※本記事にて掲載しているスクリーンショットは、ADAudit Plusビルド5000に基づいています。

製品ホームページ  >> Active Directoryログ監査レポート・ログ管理ツール | ADAudit Plus
ADAudit Plus無料評価版のダウンロードはこちらから >> ADAudit Plus 評価版ダウンロード

( → 次のページへ移動 )

 


☆☆導入から設定までを解説したスタートアップガイドはこちら
☆☆☆ADAudit Plusの概要を紹介した資料はこちら

【GDPR対策をDIYするブログ】第6回 GDPRにおけるIT対策

$
0
0
Reading Time: 2 minutes
この記事の所要時間: 約 8分

第6回 GDPRにおけるIT対策

「GDPR対策をDIYするブログ」へお越しいただきありがとうございます。

前回の第5回は「ギャップ分析と対応策の検討を行う」について説明しました。

今回、第6回はGDPR要件に対するギャップへの対応として大きな役割を果たす「GDPRにおけるIT対策」についてご説明します。

1. 個人データ取扱の保護

GDPR第32条 取扱いの保護 では個人データを組織的および技術的に適切に適切な対策を行うことが求められています。また、第33条では、個人データ保護違反時には72時間以内にデータ保護監督機関に通知することが義務付けられています。

■「取扱いの保護」において求められる「IT対策」

GDPR第32条 1項において「IT対策」として求められる事項として以下4つが挙げられています。
(a)  個人データの仮名化及び暗号化
(b)  現行の機密性、完全性、可用性並びに取扱いシステム及びサービスの復旧を確実にする 能力。
(c)  物理的又は技術的事故の場合に時宜を得た方法で可用性を復旧し、個人データにアクセスする能力
(d)  取扱いの安全を確実にするため技術的及び組織的対策の効果を定期的に点検、審査及び評価するプロセス。

■個人データの仮名化及び暗号化

ここではGDPRにおける「仮名化」と「暗号化」そして「匿名化」について解説します。

・「仮名化」と「暗号化」
個人データが特定可能なメールアドレスや氏名などの情報について特定不可能な文字や英数字などに置き換える処理を施したものを指します。また、一定の処理を施すことで個人データに戻すことができる状態を指します。「仮名化」の一つの例として「暗号化」があります。

・「匿名化」
「仮名化」と比較される用語になりますが、仮名化は一定の処理を施すことで個人データに戻すことができる状態を指しますが、「匿名化」は特定不可能な処理を施したデータから個人データに戻すことができない状態であることを指します。統計データとされたものがその一例です。

GDPRの上では「匿名化」された情報は、個人データに該当せず、GDPRの適用対象外となります。

■「機密性」「完全性」「可用性」と復旧

情報セキュリティの基本的な考え方となっているCIAすなわち、「機密性」「完全性」「可用性」を保つことがGDPRの上でも求められています。また、「可用性」の一部にはなりますが、GDPRでは個人データを扱うシステム並びにサービスの復旧についても言及しています。

CIAについては、総務省が公開する情報を参考に見てみましょう。

・「機密性」
機密性(Confidentiality)とは、許可された者だけが情報にアクセスできるようにすることです。許可されていない利用者は、コンピュータやデータベースにアクセスすることができないようにしたり、データを閲覧することはできるが書き換えることはできないようにしたりします。

・「完全性」
完全性(Integrity)とは、保有する情報が正確であり、完全である状態を保持することです。情報が不正に改ざんされたり、破壊されたりしないことを指します。

・「可用性」
可用性(Availability)とは、許可された者が必要なときにいつでも情報にアクセスできるようにすることです。つまり、可用性を維持するということは、情報を提供するサービスが常に動作するということを表します。

出典:総務省 国民のための情報セキュリティサイト「情報セキュリティの概念」
http://www.soumu.go.jp/main_sosiki/joho_tsusin/security/business/executive/02.html

「機密性」の観点では基本的な対策として「ID管理」や「アクセス管理」
「完全性」の観点では、「ログ管理」や「改ざん検知」
「可用性」の観点では、データの「バックアップ」、システムの「冗長化」、予備機の設置
などがIT対策として重要と考えます。

■「技術的対策」「組織的対策」の定期点検および審査

前述のCIA「機密性」「完全性」「可用性」と復旧に関して、適切に安全が保たれているかを定期的に点検、審査、および評価することが要求されます。

これを満たすうえでの有効な対策として以下が挙げられます。
・セキュリティリスクアセスメント
・脆弱性診断
・バックアップリカバリテスト
・サイバー攻撃対策訓練
・BCP訓練

ニュートン・コンサルティング社では、BCP訓練をはじめサイバー対策訓練やセキュリティリスクアセスメント、脆弱性診断のサービスが提供されています。

BCP訓練・演習支援サービス
https://www.newton-consulting.co.jp/solution/bcm/exercise.html

サイバー攻撃対応演習・訓練サービス
https://www.newton-consulting.co.jp/solution/cyber/cyber_exercise.html

■Zohoが提供するGDPRに有効なIT対策ツール「ManageEngine」

弊社ゾーホーが提供するGDPRのIT対策を支援するIT運用管理・セキュリティ管理ソフトウェア「ManageEngine」ではGDPRの様々な事項について対策を支援します。提供している製品およびGDPRへの対応について記載しているページを以下に一覧しています。ご参考ください。

・Active DirectoryのID管/ADManager Plus
https://www.manageengine.com/products/ad-manager/gdpr-compliance-tool-for-active-directory.html

・Active Directoryのログ監査/ADAudit Plus
日本語ページ:
https://www.manageengine.jp/products/ADAudit_Plus/features-gdpr.html

英語ページ:
https://www.manageengine.com/products/active-directory-audit/gdpr-compliance-tool.html

・統合ログ管理/EventLog Analyzer

日本語ページ:
https://www.manageengine.jp/products/EventLog_Analyzer/gdpr-compliance-reports.html

英語ページ:
https://www.manageengine.com/products/eventlog/general-data-protection-regulation-gdpr-solution.html?feature

・ITヘルプデスク管理/ServiceDesk Plus
https://www.manageengine.com/products/service-desk/gdpr-service-desk-software.html

・特権ID管理/Password Manager Pro
https://www.manageengine.com/products/passwordmanagerpro/release-notes.html

・サーバーネットワーク統合監視/OpManager
https://www.manageengine.com/network-monitoring/opmanager-gdpr-compliance.html

・サーバーアプリケーション/Applications Manager
https://www.manageengine.com/products/applications_manager/appmanager-gdpr-compliance.html

・ネットワークトラフィック監視/NetFlow Analyzer
http://help.netflowanalyzer.com/distributed-monitoring/whats-new

・クラウド型サーバー監視/Site24x7
https://www.site24x7.com/gdpr.html

・ネットワークコンフィグ管理/Network Configuration Manager
https://www.manageengine.com/network-configuration-manager/release-notes.html

・ファイアウォールログ管理/Firewall Analyzer
https://www.manageengine.com/products/firewall/release-notes.html

 

最後に1つご案内させていただきます。

今後、GDPR対策を進める上で、対応を迫られている組織の担当者が1日で対応方針を決定したい。その場でコンサルタントに相談しながら不明点を解決し、自社に戻って実装を進めたいという場合には、以下ニュートン・コンサルティング社が提供するGDPR講座の参加をご検討ください。

ニュートン・コンサルティング GDPR講座
GDPRセミナー(EU 一般データ保護規則)ツール完全提供!
~完全準拠ツールをすべて提供&GDPRの概要と取組む際の勘所~
https://www.newton-consulting.co.jp/academy/curriculum/201804gdpr.html
場所:ニュートン・コンサルティング株式会社

「GDPR対策をDIYするブログ」第6回は「IT対策」について書きました。
次回GDPR対策をDIYするブログ第7回は、最終回として「ルール決定と文書化」についてご説明します。

 

■ZohoにおけるGDPRへの取組の紹介

弊社ゾーホージャパンはグローバル企業Zoho Corporation傘下の日本法人です。GDPR施行の前日2018年5月24日Zoho CorporationのCEOは次の動画による声明を行っています。

https://m.youtube.com/watch?v=IovXB__qQPQ

動画におけるZoho CorporationのCEO Sridhar Vembu による声明内容(和訳)

ご挨拶申し上げます。
ゾーホーは、一企業として、お客様のプライバシーを真剣に考えています。それに向け、我々はビジネスモデルを変更しました。お客様のプライバシーを侵害しないためにも、お客様の明確な許可なくお客様のデータを第三者に売却したり、開示したりすることは決して行いません。この点は今までの我々の対応と全く変わりありません。GDPRはお客様のプライバシーを守るための我々の取り組みをより強いものにさせました。
さらに、これを念頭に置いて、我々はGDPRレベルの運用をワールドワイドのお客様に向け拡大し適用しました。これはヨーロッパの規制ではありますが、GDPRに定められたGDPRレベルのプライバシー保護をワールドワイドのお客様に拡大する宣言をします。
この取り組みは、私たちのお客様のプライバシー保護のための取り組みなのです。
そう。プライバシーを選ぶなら、是非ゾーホーを。
ありがとうございます!

この弊社CEOの声明では、GDPRレベルのセキュリティポリシーをWWの顧客や拠点に対して適用するという宣言を行いました。

また、ZohoではGDPRに対してあらゆる取り組みを開始しております。

GDPR Readiness – Zoho
https://www.zoho.com/jp/lp/gdpr.html(日本)
https://www.zoho.com/lp/gdpr.html

当ブログを運営するIT運用管理セキュリティソフトウェアのManageEngineにおいてもGDPR対応を支援するソリューションを提供しております。
GDPRの要件とManageEngineの対応を示した情報などを以下ページにて公開しております。

GDPR対応ソリューション-準拠に向けたポイント- | ManageEngine
https://www.manageengine.jp/solutions/gdpr/lp/(日本)

GDPR Compliance – Solutions – Checklist – Software | ManageEngine
https://www.manageengine.com/gdpr/index.html

 

GDPRをDIYするブログ 連載目次
第1回 GDPRの概要と日本における現状
第2回 GDPRへ対応するための作業ステップと事前準備
第3回 DPOの設置、プライバシーポリシー・Cookieポリシーの作成
第4回 データマッピングおよび処理者へGDPR対応状況の確認
第5回 ギャップ分析と対応策の検討を行う
第6回 GDPRにおけるIT対策(今回)

保証と開発 – ITの品質向上とコスト削減からとらえたITIL®

$
0
0
Reading Time: 1 minutes
この記事の所要時間: 約 8分

当連載記事について
当連載記事では、ITIL®の研修を多く手掛ける専門家が、分かり易い口語体でより実際的な観点からITIL®を解説しています。サラッと読みながらもITIL®に基づいた考え方をより実践的なレベルへ落とし込むことができます。また、ITIL®に準拠するための機能を備えたITサービスマネジメントツール「ManageEngine ServiceDesk Plus」を提供するゾーホージャパンより、欄外コラムとしてツールの詳細や関連機能の説明を行います。ITIL®の概念を把握しつつ、ツールを活用した場合のイメージを広げる際の一助となりましたら幸いです。
※ITIL® is a Registered Trade Mark of AXELOS Limited.

 

はじめに

第七回では保証と開発についてお話したいと思います。

保証とは

突然、「保証」という単語が出てくるので何のことかわからないと思います。そこで、まずITIL®が言う保証というものが何かを説明します。

ITIL®に出てくる「保証」とは、「可用性(ITサービスが使いたいときに使えること)が確保されている状態」、「求められているキャパシティ(処理速度などの性能)が満たされている状態」、「被災したときでも継続的にITサービスを使用できる状態」、「ITサービスのセキュリティが確保されている状態」という4つが確保されていることを意味します。

そして、これらの状態を作るためにITIL®では、サービスデザインというフェーズにそれぞれの状態を作り出すための活動(プロセス)が用意されています。そのプロセスの名前が、「可用性管理プロセス」、「キャパシティ管理プロセス」、「ITサービス継続性管理プロセス」、「情報セキュリティ管理プロセス」というものになります。

可用性管理プロセスとは

では、先に紹介した4つのプロセスとは、それぞれどんなプロセスなのでしょうか?可用性管理プロセスから説明します。

まず、プロセスの名前にもなっている「可用性」について。可用性とは、「使いたいときにITサービスを使える状態」のことです。可用性が高いというのは使いたいときにいつでも使える。可用性が低いというのは使いたいときに使えないという状態のことです。ただし、ITIL®が言う「使いたいとき」というのは、「SLAで顧客とサービス・プロバイダが合意した時間内で使いたいとき」という意味になります。そうしないと、どのITサービスも24時間365日で使える状態にしないとなりませんから。

そして可用性管理プロセスとは、このSLAで合意された範囲内で「使いたいときに使える状態を維持できるように設計する活動」ということになります。具体的に言えば、ネットワーク機器が1台故障し、それによりITサービスが止まってしまっては困るので、ネットワーク機器を冗長化する(1台が壊れてももう1台でITサービスが使えるようにしておく)とかですね。それを設計するのが可用性管理プロセスです。

キャパシティ管理プロセスとは

次にキャパシティ管理プロセス。キャパシティ管理プロセスの名前にある「キャパシティ」が何かといえば、「器」だと思ってください。コップがあって、そのコップに水が180ml入れられるとします。そうしたら、コップのキャパシティは180ml(分の水を入れられる)ということになります。これをITサービスに当てはめ、1秒間に1万個のタスクが処理できるCPUがあったとしたら、そのCPUのキャパシティは「1秒間で1万個のタスク処理量」ということになります。

他にもサーバであれば、HDD容量もサーバのキャパシティといえるでしょう。ネットワークであれば、「HTTPによる1000アクセスに対して1秒以内にレスポンスを返す」などのレスポンスタイムも、処理速度という観点ではキャパシティの一つといえます。そして、このキャパシティを設計しているプロセスがキャパシティ管理プロセスということになります。

ITサービス継続性管理プロセスとは

3つ目がITサービス継続性管理プロセス。「継続性」とは、被災してもITサービスを止めないという意味があります。一方で、止まってしまったら復旧させるということも含まれています。とはいえ、地震、台風、津波、竜巻などの自然災害や、最近ではハッキングによるシステム破壊など、サービスを停止する災害はいろいろあります。国や地域によっても異なるでしょう。

なので、最初に自分の企業にとって、何が災害なのかを決めないといけません。これを決めるところからITサービス継続性管理プロセスはスタートします。そして何が災害なのかを決めたら、その災害が発生する頻度を考え、発生した場合に及ぼされる影響も考える。例えば地震が起きても建物が耐震構造になっているから被害は発生しないということもあるでしょうし、被災してITサービスが止まり、経済的な損失が発生する場合もあるでしょう。よって、一口に影響を考えると言っても、かなり複雑になります。

とはいえ、影響を明らかにできれば、会社として対策をしなければならない災害が明確になります。あとはその災害が発生した際の対応策(耐震構造にするとか、電源が落ちたときの復旧手順を用意しておくとか)を考えておき、訓練によってその手順が問題ないかをチェックします。これがITサービス継続性管理プロセスです。

情報セキュリティ管理プロセスとは

最後に情報セキュリティ管理プロセス。「情報セキュリティ」とは、内外からの不正アクセスを防ぐことで、情報漏洩やデータの改ざんを防ぎ、ITサービスの停止や破壊から守ることなどを指します。そしてこれらの情報セキュリティを脅かす事態からITサービスを保護するための設計プロセスが、情報セキュリティ管理プロセスです。ただ、ITで情報セキュリティの設計をするというと、ネットワーク経由での不正アクセスに対応するためにファイアウォールを設置するとか、認証システムを導入するなどの話になりがちです。

もちろんこれらも対策しなければなりませんが、情報セキュリティとしては一部にすぎません。なぜなら、個人情報が保存されているHDDを社員が引っこ抜いて持ち出してしまえば、ファイアウォールなど意味がありませんから。

なので、情報セキュリティ管理プロセスでは、ITシステムだけではなく人の教育も含めて、どうすれば情報が漏洩せず(機密性が保たれて)、必要なときに利用できて(可用性を維持して)、いかに正確な状態に保っておけるか(完全性の確保)を考えて設計していくプロセスとなります。よって、情報セキュリティ管理プロセスの活動を行うと、いわゆる情報セキュリティ管理方針や、情報セキュリティ管理規定・手順といわれるルールや文書が作成されることになります。

これら4つのプロセスが保証のプロセスといわれるものです。

ITIL®にとっての開発

ITIL®には、ライフサイクルとして5つのフェーズがあるという話を第二回の記事でお話しています。が、その5つのフェーズに「開発」という活動がないことはお気づきでしょうか?やはり、世間でITの仕事をしているといえば、まだまだ「プログラムを書いている」とか「ソフトウェアを作っている」というイメージがあり、いわば開発はITの花形のようなものです。しかし、ITIL®にはその花形がない。さみしいですね(笑。

では、なぜ花形がないのか、その理由は明確にはわかりません。少なくとも、AXELOSから出版されているITIL®の用語集にある「開発」の説明にも「(ITIL®の書籍では)詳細に説明されていない」と記載されており、開発についてITIL®は触れていないというのが事実です。その理由として、私が想像するに2つほど挙げられると思っています。

  1. ITIL®が目指していることの一つは、サービス品質の向上です。開発とは、実際にITを作り込む作業になりますが、品質の向上は実際に作る作業ではなく、作られたものをテストすることで担保されます。よって、テストをITIL®のプロセスで管理していけばよいと思っているのではないでしょうか。ちなみに、テストを管理する具体的なプロセスにはリリース管理および展開管理プロセスと、サービスの妥当性確認およびテストプロセスがあります。
  2. 設計書がアウトプットされる「開発」を管理するノウハウは、すでにPMBOK®、PRINCE2®などといった形で世の中に存在しています。このことから、ITIL®は「サービス品質を担保すること」を主軸に考え、開発自体は既存のPMBOK®、PRINCE2®といわれるプロジェクト管理手法を使って実施することを前提としているのではないでしょうか。つまり、サービスデザインのプロセスを使ってしっかりと設計し、その設計通りに開発されているかどうかをテストでチェックすることで品質を担保しようと考えていると思われます。

最後に

ということで、ITIL®のサービスデザインのフェーズでは「可用性」「キャパシティ」「継続性」「情報セキュリティ」を確保するという観点で設計をしていきます。次にITIL®のフェーズにはありませんが、その設計を元にITサービスを形作る活動(開発プロセス)が行われます。そして、後は本番環境に移行すればよいのですが・・・。実は、すでにこの時点でお金がかかっているんですよね。ということで、次回は再び私の大好きなお金の話になります(といってもお金を増やす方法ではないので期待しないでください)。

>>記事一覧:ITの品質向上とコスト削減からとらえたITIL®

執筆者情報
日本クイント株式会社 コンサルタント 吉村友秀(よしむら ともひで)
主要資格:ITIL® エキスパート、公認情報システム監査人(CISA)

 



SLA機能について

連載コラムをご一読頂き、ありがとうございます。ManageEngineでは、ITIL®準拠のためのITSM機能を網羅した「ServiceDesk Plus」というツールを提供しています。

今回は、可用性管理プロセスの話で少し出てきた「SLA」機能について、ご紹介します。第4回のコラムで、ServiceDesk Plusのサービス・カタログ機能がリクエストフォームと連動しており、各リクエストフォームにはSLAを設けることができると説明しました。

この時、実際の設定画面は下図のようになります。

図中の「フォームデザイナー」というタブでは、リクエストフォームに追加したい項目や、リクエストフォームを公開したいユーザグループの情報を設定できます。例えば、外出時に営業メンバーがモバイル端末を持ち出す申請をフォーム上で行うのであれば

・「貸出日程」という項目を追加
・「営業メンバーのグループ」のみがフォームを閲覧できるように指定

などが可能です。

そして、赤枠で示している「ワークフロー」というタブでは申請に対する承認フローの設定などを行えるのですが、この他にSLAの指定もできます。このSLAには、下図のようにリクエストが送信されてから「一次回答」が返されるまでの期日と、「最終的な解決」に至るまでの期日が設定できます。

例えば、請求業務システムやお客様への一斉メール配信システムを日常業務で頻繁に活用する企業であれば、これらのシステムが止まることで業務に支障が出てしまいます。

サービスデスク担当者は様々なリクエストに順次対応しているとはいえ、こういったリクエストの優先度を上げて「2時間以内には最初の回答をしてほしい」「2営業日以内には問題を解決してほしい」といった、事業レベルでの取り決めを、SLAとして反映させることができます(※なお、期日を設定する際は、業務時間を「考慮する/しない」が選択できます)。

さらに、各期日が過ぎる前後には通知先を指定してエスカレーションを行うことも可能です。

上図の場合だと、一次回答期日から1時間経過したタイミングで別のサービスデスク担当者(デモ技術者2)へエスカレーションが設定されています。たまたま最初の担当者が気づけなかった場合でも、これでリクエストが放置されるというリスクを低減できます。

さらに、解決期日から1時間経過したタイミングで、グループのリーダー(デモ技術者3)へエスカレーションすることで、「スムーズに解決できていないみたいだけど、何か重度の障害なのかな」といったことを、よりスキルの高い担当者に認識してもらえます。

さらに解決が遅延し、事業レベルの判断が必要となる可能性がある場合は、図中のように「中村部長」へエスカレーションするといった設定が必要かもしれません。

<ツールを触ってみたくなったら>

いかがでしょう。ServiceDesk PlusのSLA機能は、対応期日を起点とし、それが守られなかった場合のエスカレーションやアクション設定を行うという、シンプルなものです。しかし上手に活用すると現場の運用やユーザの満足度が大きく改善されるかもしれません。

本日ご紹介した設定は、プログラミングの知識が無くても簡単に試すことができます。検証用に30日間無料で使える評価版(オンプレミス版/クラウド版の両方)もご用意していますが、そこまで真剣に検証できないという方には「体験デモサイト」がお勧めです。

グローバル共用のデモサイトなので、英語のデモデータが登録されていますが、GUIは日本語として表示されますので、ぜひお試しください。

>>体験デモサイトにログイン(※クリック後、実際のツール画面が開きます)

ログイン後、管理画面から「SLA(サービスレベル契約)」というリンクをクリックしてください。

その他、下記の情報もぜひご利用ください。

<製品について情報収集したい方>

<製品について質問したい方>

FIDO U2F対応の物理セキュリティキーによる特権ID管理強化のススメ

$
0
0
Reading Time: 1 minutes
この記事の所要時間: 約 5分

あのGoogle社が2017年より自社向けに物理セキュリティキーを導入していることは、既に複数の記事で言及されていますので、ご存知の方が多いかもしれません。

グーグル、社員への物理セキュリティキー導入でアカウント保護に効果(ZDnet Japan)

記事によれば、物理セキュリティキーの導入以来、Google社で働く8万5000人以上の従業員の内、「仕事用アカウントをフィッシングで乗っ取られた」という被害報告をした人はいないそうです。これは、社員数の規模から考えるとすごいことですよね。

その後、Google社は「Titan Security Key」という物理セキュリティキーの販売を開始しています。このTitan Security Keyは、フィッシングに耐性のある、FIDO標準の2段階認証プロセスを実装しているとのこと。

あのGoogle社をフィッシングの被害から守っているというアカウント認証の仕組み。一般従業員アカウントもそうですが、サイバー攻撃者から狙われやすい「特権ID」に対しても採用したいと考えるシステム管理者の方は、多いのではないでしょうか。

実は、2018年11月28日の新版リリースにより、ManageEngineが提供する特権ID管理ツール「Password Manager Pro」も、FIDO U2Fの2段階認証を採用している物理セキュリティキー「YubiKey(Yubico社)」との連携機能を実装しました。当記事では、こちらの機能と併せて、詳細をご紹介致します。

目次

 

物理キーとは?Password Manager Proと連携した際の使用感

冒頭から何度も「物理セキュリティキー」と言っていますが、実物を見たことがない人は「物理?何のこと?」と思うかもしれません。一言で説明すると、「暗証番号」や「パスワード」のような情報としてのキーではなく、物理的なキーのことです。以下は、弊社で実際にPassword Manager Proとの連携を検証する際に使用したYubiKeyです。

パッと見ると分かり辛いかもしれませんが、下画像のようにデバイスの接続部分はUSBポートに差し込めるようになっています。

では、さっそくPassword Manager Proと連携させた場合の動作を見ていきましょう。

まず、IDとパスワードの組み合わせで1段階目の認証を行います。ここまでは、通常の認証と同じ操作となります。

認証が通ると、その後に2段階目の認証画面が表示されます。

ここで、Password Manager Proに登録済みのYubiKeyを差し込み、金属部分にタッチします。

すると、自動でセキュリティキーが生成され、Password Manager Proの管理画面(下画像)へログインすることができます。

この連携機能は、YubiKey4、YubiKey4 Nano、YubiKeyなど、Yubico OTPをサポートしている機器が対象となっています。実際の機器は、Amazonなどでも販売されており、5,000円程で購入できますので、ご興味のある方はぜひ連携設定を行ってみて下さい。

Password Manager Proナレッジ:YubiKey(2段階認証)の設定方法

なお、Password Manager Proは、30日間無料で使える評価版(サポート付き)も提要しておりますので、「まずは検証したい」という方はぜひお試しください。

>>Password Manager Pro評価版ダウンロードページ

また、訪問やオンラインによる製品説明/ご提案を行っております。必要に応じて、こちらもご利用頂けますと幸いです。

>>特権ID管理 訪問/デモ依頼窓口

その他、Password Manager Proについて情報収集を行いたい方のための資料やセミナーとして、下記がございます。「まずは製品の概要を知りたい」と思われた方は、ご参照ください。

Password Manager Proの概要が分かる資料
セミナー一覧

 

FIDO U2Fとは?どういうメリットがあるのか

ところで、「そもそもFIDO U2Fって何?」と思った方もいらっしゃるかと思います。筆者も完全に仕組みを理解しているとは言えないのですが、はじめて単語を聞く方のために簡単な説明をしたいと思います。

まず、U2F(ユーツーエフ)とは、「Universal 2nd Factor」の略称です。IDとパスワードでユーザー認証を行う他、安全性を高めるための第2要素としてUSBキーやUSBトークン等の小型機器を用いて認証を行う方式で、「FIDOアライアンス」という業界団体が策定しました。

FIDO(ファイド)というのは、「Fast IDentity Online」の略称です。FIDOアライアンスは、Webサイトやモバイルサービスの認証がより簡単かつ安全になるよう、技術の標準化を目指して設立された業界団体で、多くの著名な企業が加盟しています(YubiKeyを提供しているYubico社も、その内の1社です)。

FIDO アライアンス メンバーページ(英語)
※メンバー一覧を見ていると、NTT docomoやLINEも加盟しているのが分かりますね(2018年12月現在)。

ここで、「パスワード以外の要素を用いた2段階認証であれば、モバイル端末を用いた従来のワンタイムパスワード(OTP)方式で十分なのでは?」と思う方がいらっしゃるかもしれません。

しかし、従来のOTP方式では「フィッシングや中間者攻撃という手法からは完全に守られない」という限界があるようです。例えば、ユーザーが偽のWebサイトに「ID」「パスワード」「ワンタイムパスワード」を全て入力してしまったら…、サイバー攻撃者によって即座にアカウントを乗っ取られてしまいます。

一方、U2F機器の場合は、「公開鍵暗号方式」を採用しているようです。以下は、Yubico Blogの翻訳掲載ページからの抜粋です。

登録後、ユーザーがログインを試みるとサービスプロバイダーがチャレンジをクライアントに送ります。クライアントは他の情報のうち、チャレンジのソースに関する情報をコンパイルします。これは(秘密鍵を使用して)U2Fデバイスによって署名され、サービスプロバイダーに送り返されます。U2Fのようなリアルタイムのチャレンジ・レスポンス方式は、フィッシングや様々な形態の中間者攻撃のようなOTPの脆弱性に対処します。

引用元:OTP VS. U2F: 強固な認証からより強固な認証へ

このように、記事内では、FIDO U2Fのメリットとして「公開鍵暗号方式による強固なセキュリティ」が挙げられています。

Google社が明かしている通り、「フィッシングによる従業員のアカウント乗っ取りが起きていない」という事実も、この方式によって実現されたところが大きいのでしょう。「ネットの海だからこそ自由にハッキングを行える」というサイバー攻撃者にとっては、シンプルであるものの「物理的なキーを盗み出す」ということのハードルが想像以上に高いということですね。

U2Fのプロセスについては、Yubico社のWebサイト等でも紹介されていますので、気になる方はぜひご参照ください。

What is U2F?(英語)

おわりに

いかがでしょうか。企業/組織にとってセキュリティの要となる「特権ID」。今回ご紹介した連携機能を活用すれば、よりセキュアに管理していけるかもしれません。ぜひ、Password Manager Proと併せてご検討下さい。

ご一読頂き、ありがとうございました。


【関連情報】

Password Manager Pro製品サイト

YubiKey(物理セキュリティキー)との連携機能ページ

YubiKeyによる2段階認証の設定方法(Password Mnager Proナレッジ)

関連プレスリリース

Zabbixでネットワーク装置のコンフィグも管理する方法とは?【連携してみた02】

$
0
0
Reading Time: 4 minutes
この記事の所要時間: 約 16分

こんにちは、ManageEngineのエンジニアもどきの園部です。

本日は、「連携してみたシリーズ」の2本目としまして、「Zabbix」と、永年無料版※もある当社のネットワーク機器コンフィグ管理ソフト「Network Configuration Manager」を連携し、Zabbixで、機器のコンフィグバックアップ状況や、機器のコンフィグに変更があったかを表示する方法をご紹介していきます。

Zabbixでネットワーク機器を監視しているシステム管理者様は多いのではないかと思います。
1つの製品上で機器の死活やパフォーマンス管理に加えて、コンフィグの管理までできたら、ネットワーク運用管理の手間がより減るのではないでしょうか?

今回はこれを、昨今話題のあのスクリプト言語のフレームワークなんかも織り交ぜて、実現していきたいと思います。

よろしくお願いいたします!

 

目次

コンフィグ管理とは?

まずは用語の確認から。

コンフィグ 管理
コンフィグ=コンフィグレーション ⇒ 設定
==> 設定管理 すること

単純に「コンフィグ管理」と言った時、多くの場面で、「ネットワーク機器」を対象にしていることが多いようです。

つまるところ、ネットワーク機器の設定を管理しましょう!ということですね。

社内ネットワークなど、多くの機器が接続する可能性があるネットワークでは、たいていの場合、スイッチやルータ等のネットワーク機器にコンフィグ設定がされています。
その中身は、その機器がどのように動作して、通信を処理すべきかという設定がされていることが多いようです。

設定をする理由は、利便性であったり、セキュリティ強化のためであったり、様々です。
また、コンフィグ設定一つ誤ったために、ネットワークに接続不可になったり、セキュリティ的な脅威にさらされたりしてしまうことがあります。

このように、ネットワーク機器のコンフィグ管理はとても重要ですが、

  • 【設定の手間】複数台の機器にそれぞれ設定をし、どんな設定をしたか把握しなければならない
  • 【管理の手間】複数台のネットワーク機器を導入している場合、それぞれを管理しなければならない
  • 【人為的ミス等による脅威】重要なネットワーク機器に、意図しない設定が反映されてしまうかもしれない

などの問題がしばしば発生することがあります。

大きいネットワークでは数十台、数百台のネットワーク機器が存在する場合もあり、それらの機器に一つずつログインをして、設定を施し、それぞれの内容を把握し、定期的にバックアップを取って……というのは、小規模ネットワークの場合や、担当者が多い企業では良いかもしれませんが、そうでない場合は現実的ではありません。

そこで、登場するのが、コンフィグ管理ソフトウェアです。

コンフィグ管理ソフトを使用してこれらの作業を一元管理していくことにより、コンフィグ管理の手間や人為的なミスをなくすことができます。

さて、前置きが長くなってしまいましたが、ここから本題の、Zabbixでこのコンフィグ管理を実現するための準備を始めていこうと思います。

まずは現状の確認

まずは、当社社内のZabbix、Network Configuration Managerでの運用のご紹介です。

Zabbix

当社社内のZabbixでは、社内のネットワーク機器の死活とステータスを監視しています。環境はZabbixバージョン3.4です。(Zabbix4.0が大変気になっている今日この頃)

これらの機器は、以前『ZabbixにSNMPだけでなくNetFlow監視で得たトラフィックの内訳情報も表示するには?』というタイトルでご紹介した方法で、SNMP+NetFlow、sFlowで監視しています。

ZabbixとNetwork Configuration Managerの連携 - 連携前のスクリーンショット
全体感

ZabbixとNetFlow Analyzerの連携で作成したトラフィック内訳監視グラフ
自作のトラフィック監視用ウィジェット

このダッシュボードに、コンフィグの状態も併せて見られるような項目を追加していきたいと思います!

Network Configuration Manager

Network Configuration Managerで、前回までの「本社」というネットワーク機器を含めた社内のネットワーク機器のコンフィグを管理しています。
(なお、製品名が長いので、以下NCMと省略させていただきます…。NCMってなんだっけと思ったらカーソルを合わせてみてください!)

NCMで今回実施しているコンフィグ管理は以下の通りです。

  1. 設定したコンフィグを定期的にバックアップ(「コンフィグバックアップステータス」の監視)
  2. コンフィグが変更されたかどうかのチェック(「最近のコンフィグ変更」の監視)
  3. StartupコンフィグとRunningコンフィグの差分をチェック(「Startup – Running 不一致の機器」の監視)

Network Configuration Managerのスクリーンショット
NCMダッシュボード

他にも様々な管理を行っていますが、まずは上記3点の管理状況をZabbix内でも見られるようにしていきたいと思います。

コンフィグ管理 in Zabbix の実装方法

※※前置きを飛ばして、実装用スクリプトを見たいかたはここをクリック!※※

さて、本題のコンフィグ監視の実装方法ですが、冒頭でも述べた通り、コンフィグ管理ソフトのNCMとZabbixを、NCMのREST APIを使用することによって連携していきます。

肝心の実現方法については、少し考えなおしました。
前回のフロー監視では、データ取得用のPHPファイルを、Zabbixの外部チェック機能で実行していくことにより、NetFlow AnalyzerのデータをZabbix側に流し込むようにしました。これにより、過去のフローデータをグラフで視覚的にさかのぼって障害調査をしたり、Zabbix側でしきい値等を用意して障害検知を実施できるようになりました。

しかしコンフィグ管理では、まずは現状を知ること(現在のコンフィグの変更有無/現在のコンフィグのバックアップ状況等‥‥)に大きな意義があるのではと考えました。

そこで、できるだけ軽量のスクリプトで、最新のコンフィグ管理データを、NCMから素早く取得して表示することを考えます。
このような条件の中で、思いついたのが、Javascriptです。

というわけで、Javascriptでデータを取得し、HTMLページに表示させたものを、「URLウィジェット」としてZabbix上に表示させる方法を考えていこうと思います!

ZabbixのURLウィジェット
ZabbixのURLウィジェット

 

使用した技術

今回は、最近の流行?に便乗して、昨今話題のJavascriptフレームワーク『Vue.js』を使用していきます。

Vue.jsの解説をするためのブログではない(そもそも執筆者がJavascript初心者のため解説できない)ので、詳しい説明はできないのですが、JSフレームワークの中では比較的敷居が低く、記述がシンプルに済むようですね!
Vue.jsを触るのが初めてだったので、公式のドキュメント類を何度も拝見しました。資料が充実しており、資料の大半が日本語化されているので、大変簡単に導入できた印象です。

さて、それではまず、「1. コンフィグバックアップステータス」を表示するウィジェットを作成していきます。

HTMLファイル

LastBackupsListWidget.html

<html>
<head>
<title>最新のバックアップウィジェット</title>
<meta charset="utf-8">
<script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script>
<script src="https://unpkg.com/axios/dist/axios.min.js"></script>
</head>

<body>

<div id="bk-data">
<table>
<tr class="list-header">
 	 <td>機器名</td>
 	 <td>タイムスタンプ</td>
 	 <td>バックアップステータス</td>
</tr>
<tr v-for="backup in bkdata.rows" class="list-table">
 	 <td>{{ backup.cell[2] }}</td>
 	 <td>{{ backup.cell[4] }}</td>
 	 <td>{{ backup.cell[5] }}</td>
</tr>
</table>
</div>
<script src="getLastBackupsList.js"></script>

</body>
</html>

Javascriptファイル

getLastBackupsList.js

var ncm = new Vue({
el: '#bk-data',
data:{
 	 bkdata:[]
},
created: function() {
this.getData();

},
methods: {
getData: function() {
axios
.get(
 	 "http://NCMのホスト:NCMのポート/api/json/ncmbackup/getLastBackupsList?apiKey=NCMアカウントのAPIキー"
)
.then(response => {
 	 this.bkdata = response.data;
})
.catch(error => {
 	 window.alert(error);
});
}
},
})

動作としては、Vue.js+axiosでREST APIを実行、その応答をdataの部分に格納し、その中から、機器名、時間、メッセージ等の必要なデータだけをHTML上で表示するようにしています。

上記2つのファイルを、ZabbixサーバーのWebサーバーであるApacheに配置します。(デフォルトではZabbixサーバーの /var/www のあたりにあるかと思います。)
前回のPHPファイル同様、ApacheはZabbixが稼働するサーバーであれば必ず入っているものであるので、別途何かをインストールする必要はありません。

さて、上記のHTMLファイルにアクセスしてみると、いかがでしょうか。

Network Configuration Manager REST APIをHTMLとJavascript上から実行

NCMでバックアップを取得する設定にしている機器の、バックアップ実行ステータスが無事に表示されていることが確認できるかと思います。

では、このURLをZabbixのURLウィジェットでZabbixダッシュボードに埋め込みしてみます!

ZabbixとNetwork Configuration Managerの連携 - APIデータをZabbixに表示

……うーん。内容は問題ないが、味気ない。そして見づらい。

どうせなら見た目にもこだわって、完全にZabbixウィジェットに擬態しよう!
というわけで以下のCSSファイルを追加。

style.css

table{
 	 border-collapse:collapse;
 	 width:100%;
}

.list-header td {
 	 color: #768d99;
 	 height: 100%;
 	 overflow: hidden;
 	 white-space: nowrap;
 	 padding: 6px 5px;
 	 vertical-align: bottom;
 	 border-bottom: 2px solid #dce2e5;
 	 text-align: left;
}

.list-table td {
 	 padding: 6px 5px;
 	 position: relative;
 	 border-bottom: 1px solid #ebeef0;
}

td {
height:1.1em;
 	 font-size:75%;
 	 padding: 5px 10px;
}

tr{
 	 border-bottom:1px solid #dce2e5;
}

h4 {
 	 font-size: 1.167em;
 	 color: #3c5563;
 	 font-weight: bold;
 	 margin: auto;
 	 padding: 10 0;
}

HTMLファイルのヘッダー部分にも以下の一行を追加。

<link rel="stylesheet" href="style.css" type="text/css" />

すると、以下のような見た目になりました。これは中々良いのでは!?(自画自賛)

ZabbixとNetwork Configuration Managerの連携 - スタイル適用

同様にして、「2. コンフィグが変更されたかどうかのチェック」と、「3. StartupコンフィグとRunningコンフィグの差分をチェック」に対応するウィジェットも作成します。

ZabbixとNetwork Configuration Managerの連携 - 複数のウィジェット設置
上段:❶コンフィグバックアップステータス/下段右:➋最近のコンフィグ変更/下段左:❸Startup-Running不一致の機器

これで無事、Zabbix画面でコンフィグ管理情報も表示させることに成功しました!
今回は、Zabbixへのデータ保存ではないものの、見た目に少しこだわって作成をしましたので、Zabbixの見た目や操作感に慣れているユーザー様でも、違和感なくコンフィグ管理の初めの一歩をお試しいただけるのではないかと思います。

作成したスクリプト

各JSファイル内の以下の箇所

http://NCMのホストNCMのポート/api/json/hogehoge/hogehogehogehoge?apiKey=NCMアカウントのAPIキー

をご利用のNCMの情報(ホスト名、ポート番号、APIキー)に書き換えていただくだけで、そのままコピペしてご利用いただけます!

是非ご利用ください!

「コンフィグバックアップステータス」ウィジェット

▼ HTML

<html>
<head>
<title>最近のバックアップステータス</title>
<meta charset="utf-8">
<link rel="stylesheet" href="style.css" type="text/css" />
<script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script>
<script src="https://unpkg.com/axios/dist/axios.min.js"></script>
</head>
<body>
<div id="bk-data">
  <table>
  <tr class="list-header">
    <td>機器名</td>
    <td>タイムスタンプ</td>
    <td>バックアップステータス</td>
  </tr>
  <tr v-for="backup in bkdata.rows" class="list-table">
    <td>{{ backup.cell[2] }}</td>
    <td>{{ backup.cell[4] }}</td>
    <td>{{ backup.cell[5] }}</td>
  </tr>
  </table>
</div>
<script src="getLastBackupsList.js"></script>
</body>
</html>

▼ Javascript(getLastBackupsList.js)

var ncm = new Vue({
  el: '#bk-data',
  data:{
    bkdata:[]
    },
  created: function() {
    this.getData();
    
  },
  methods: {
    getData: function() {
      axios
        .get(
          "http://NCMのホスト:NCMのポート/api/json/hogehoge/hogehogehogehoge?apiKey=NCMアカウントのAPIキー"
        )
        .then(response => {
          this.bkdata = response.data;
        })
        .catch(error => {
          window.alert(error);
        });
    }
  },
})

「最近のコンフィグ変更」ウィジェット

▼ HTML

<html>
<head>
<title>最近の変更一覧</title>
<meta charset="utf-8">
<link rel="stylesheet" href="style.css" type="text/css" />
<script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script>
<script src="https://unpkg.com/axios/dist/axios.min.js"></script>
</head>
<body>
<div id="recent-change">
  <table>
  <tr class="list-header">
        <td>機器名</td>
        <td>タイムスタンプ</td>
        <td>変更されたコンフィグ</td>
  </tr>
  <tr v-for="change in apidata.rows" class="list-table">
        <td>{{ change.cell[2] }}</td>
        <td>{{ change.cell[1] }}</td>
        <td>{{ change.cell[5] }}</td>
  </tr>
  </table>
</div>
<script src="getRecentChangeList.js"></script>
</body>
</html>

▼ Javascript(getRecentChangeList.js)

var ncm = new Vue({
  el: '#recent-change',
  data:{
    apidata:[]
    },
  created: function() {
    this.getData();
    
  },
  methods: {
    getData: function() {
      axios
        .get(
          "http://NCMのホスト:NCMのポート/api/json/hogehoge/hogehogehogehoge?apiKey=NCMアカウントのAPIキー"
        )
        .then(response => {
          this.apidata = response.data;
        })
        .catch(error => {
          window.alert(error);
        });
    }
  },
})

「Startup – Running 不一致の機器」ウィジェット

▼ HTML

<html>
<head>
<title>Startup-Running不一致一覧</title>
<meta charset="utf-8">
<link rel="stylesheet" href="style.css" type="text/css" />
<script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script>
<script src="https://unpkg.com/axios/dist/axios.min.js"></script>
</head>

<body>
<h4>コンフィグ不一致の機器</h4>
<div id="conf-conflict">
  <table>
  <tr class="list-header">
    <td>機器名</td>
    <td>メッセージ</td>
  </tr>
  <tr v-for="conflict in apidata.rows" class="list-table">
        <td>{{ conflict.cell[3] }}({{ conflict.cell[11] }})</td>
        <td>{{ conflict.cell[7] }}</td>
  </tr>
  </table>
</div>
<script src="configConflicts.js"></script>
</body>
</html>

▼ Javascript(configConflicts.js)

var ncm = new Vue({
  el: '#conf-conflict',
  data:{
    apidata:[]
    },
  created: function() {
    this.getData();
    
  },
  methods: {
    getData: function() {
      axios
        .get(
          "http://NCMのホスト:NCMのポート/api/json/hogehoge/hogehogehogehoge?apiKey=NCMアカウントのAPIキー"
        )
        .then(response => {
          this.bkdata = response.data;
        })
        .catch(error => {
          window.alert(error);
        });
    }
  },
})

ZabbixとNetwork Configuration Manager連携 - 全体のスクリーンショット
ウィジェット作成後の全体のスクリーンショット

まとめ

Zabbixでのネットワーク統合監視に、ネットワーク機器のコンフィグ管理機能を追加する方法として、ネットワーク機器コンフィグ管理ソフトの「Network Configuration Manager」と連携する方法をご紹介しました。

SNMPでの機器の死活、パフォーマンス監視に加え、設定等の管理も実施することで、健全でより安全なネットワーク環境に一歩近づくのではないでしょうか。

コンフィグ管理を導入することにより、手間の削減であるのはもちろん、人為的なミス等のリスクも回避することができます。

是非、既存のネットワーク監視にプラスして、コンフィグ管理を実施いただき、快適なネットワーク監視ライフを体感してみてください!

▼▼ 関連記事 ▼▼

▶ シリーズ【連携してみた】
ZabbixにSNMPだけでなくNetFlow監視で得たトラフィックの内訳情報も表示するには?【連携してみた01】

▶ 連載【ZabbixとOpManagerから学ぶ!統合監視の世界】
はじめに
01.Zabbixをインストールするまでの流れ
02.OpManagerをインストールするまでの流れ
03. 監視ソフトをインストールしたサーバー自身を監視する方法
ちょっと余談01. SNMP, WMI, CLIの違いについて
04.Zabbixで監視する機器を登録する方法
05.OpManagerで監視する機器を登録する方法

関連リンク

Zabbix公式ホームページ
Zabbixのダウンロードはこちら
Network Configuration Manager公式ホームページ
Network Configuration Managerのダウンロードはこちら
Network Configuration Manager APIはこちら
Network Configuration Manager製品概要資料のダウンロードはこちら

※永年無料版の利用をご希望の方は、30日間フル機能ご利用いただける「評価版」をダウンロードしてください。30日が過ぎると自動的に2デバイスまで監視可能の永年無料版となります。

月に1度の恒例行事!2018年12月度のMicrosoftセキュリティ更新プログラムの概要

$
0
0
Reading Time: 2 minutes
この記事の所要時間: 約 8分

皆さま、こんにちは。
ManageEngine Desktop Centralの製品担当の植松です。
本日も2018年12月度のMicrosoftセキュリティ更新プログラムの概要と、パッチ管理に強みのある資産管理ソフトManageEngine Desktop Centralについてご紹介いたします。 

【概要】
Microsoftは、2018年12月12日(日本時間)に以下のソフトウェアに関するセキュリティ更新プログラムを公開しました。
・Adobe Flash Player
・Internet Explorer
・Microsoft Edge
・Microsoft Windows
・Microsoft Office、Microsoft Office Servers および Web Apps
・ChakraCore
・.NET Framework
・Microsoft Dynamics NAV
・Microsoft Exchange Server
・Microsoft Visual Studio
・Windows Azure Pack (WAP)

今回のセキュリティ更新プログラムでは39件の脆弱性が修正されていますが、脆弱性の深刻度が「緊急」に指定されているものは9件ございます。
脆弱性の概要については以下の表をご覧ください。

脆弱性の概要 KB番号 深刻度 概要 影響を受ける製品 参考URL
CVE-2018-8540 KB4470491 KB4470492 KB4470493 KB4470498 KB4470499 KB4470500
KB4470502 KB4470600 KB4470601 KB4470602 KB4470622 KB4470623
KB4470629 KB4470630 KB4470633 KB4470637 KB4470638 KB4470639
KB4470640 KB4470641 KB4471102 KB4471321 KB4471323 KB4471324
KB4471327 KB4471329
緊急 .NET Framework のコード挿入の脆弱性 Windows Server 2008以降 https://portal.msrc.microsoft.com/ja-JP/security-guidance/advisory/CVE-2018-8540
CVE-2018-8583 KB4471324 KB4471327 KB4471329 KB4471332 緊急 Chakra スクリプト エンジンのメモリ破損の脆弱性 ChakraCore
Microsoft Edge
https://portal.msrc.microsoft.com/ja-JP/security-guidance/advisory/CVE-2018-8583
CVE-2018-8611 KB4471318 KB4471319 KB4471320 KB4471321 KB4471322 KB4471323 KB4471324 KB4471325 KB4471326 KB4471327 KB4471328 KB4471329 KB4471332 重要 Windows カーネルの特権の昇格の脆弱性 Windows 7以降
Windows Server 2008以降
https://portal.msrc.microsoft.com/ja-JP/security-guidance/advisory/CVE-2018-8611
CVE-2018-8617 KB4471321 KB4471323 KB4471324 KB4471327 KB4471329 KB4471332 緊急 Chakra スクリプト エンジンのメモリ破損の脆弱性 ChakraCore
Microsoft Edge
https://portal.msrc.microsoft.com/ja-JP/security-guidance/advisory/CVE-2018-8617
CVE-2018-8618 KB4471321 KB4471324 KB4471327 KB4471329 KB4471332 警告
緊急
Chakra スクリプト エンジンのメモリ破損の脆弱性 ChakraCore
Microsoft Edge
https://portal.msrc.microsoft.com/ja-JP/security-guidance/advisory/CVE-2018-8618
CVE-2018-8624 KB4471321 KB4471324 KB4471327 KB4471329 KB4471332 警告
緊急
Chakra スクリプト エンジンのメモリ破損の脆弱性 ChakraCore
Microsoft Edge
https://portal.msrc.microsoft.com/ja-JP/security-guidance/advisory/CVE-2018-8624
CVE-2018-8626 KB4471320 KB4471321 KB4471322 KB4471324 KB4471329 KB4471332 警告
緊急
Windows DNS Server のヒープ オーバーフローの脆弱性 ChakraCore
Microsoft Edge
https://portal.msrc.microsoft.com/ja-JP/security-guidance/advisory/CVE-2018-8626
CVE-2018-8629 KB4471321 KB4471323 KB4471324 KB4471327 KB4471329 KB4471332 警告
緊急
Chakra スクリプト エンジンのメモリ破損の脆弱性 ChakraCore
Microsoft Edge
https://portal.msrc.microsoft.com/ja-JP/security-guidance/advisory/CVE-2018-8629
CVE-2018-8631 KB4470199 KB4471318 KB4471320 KB4471321 KB4471323 KB4471324
KB4471327 KB4471329 KB4471332
警告
緊急
Internet Explorer のメモリ破損の脆弱性 Internet Explorer 9以降 https://portal.msrc.microsoft.com/ja-JP/security-guidance/advisory/CVE-2018-8631
CVE-2018-8634 KB4471321 KB4471323 KB4471324 KB4471327 KB4471329 KB4471332 緊急 Microsoft 音声合成のリモートでコードが実行される脆弱性 Windows 10
Windows Server 2016以降
https://portal.msrc.microsoft.com/ja-JP/security-guidance/advisory/CVE-2018-8634
CVE-2018-8557 KB4467680 KB4467686 KB4467691 KB4467696 KB4467702 KB4467708 緊急 Chakra スクリプト エンジンのメモリ破損の脆弱性 ChakraCore
Microsoft Edge
https://portal.msrc.microsoft.com/ja-JP/security-guidance/advisory/CVE-2018-8557
CVE-2018-8588 KB4467680 KB4467686 KB4467691 KB4467696 KB4467702 KB4467708 緊急 Chakra スクリプト エンジンのメモリ破損の脆弱性 ChakraCore
Microsoft Edge
https://portal.msrc.microsoft.com/ja-JP/security-guidance/advisory/CVE-2018-8588
CVE-2018-8589 KB4467106 KB4467107 KB4467700 KB4467706 重要 Windows Win32k の特権の昇格の脆弱性 Windows7
Windows Server 2008
https://portal.msrc.microsoft.com/ja-JP/security-guidance/advisory/CVE-2018-8589
CVE-2018-8609 KB4467675 緊急 Microsoft Dynamics 365 (on-premises) version 8 Remote Code Execution Vulnerability Microsoft Dynamics 365 (on-premises) version 8 https://portal.msrc.microsoft.com/ja-JP/security-guidance/advisory/CVE-2018-8609

これらの脆弱性を悪用された場合、アプリケーションプログラムの異常終了や攻撃者によるコンピューター制御など、様々な被害が発生する可能性があります。
またCVE-2018-8611の脆弱性について、Microsoft社は脆弱性悪用の事実を確認済みと公表しているため、被害が拡大する可能性があります。

【対策】
上記の脆弱性への対策としてはMicrosoftが提供しているセキュリティ更新プログラムを適用する必要があります。 

さて前回のブログでは、パッチ自動配布タスクの作成方法(パッチ配布を自動化する方法)についてご紹介いたしました。今回のブログでは、前回のブログ内で告知した通り、「パッチの拒否」機能をご紹介いたします。

「パッチの拒否」機能は、「業務システムがJavaの特定のバージョンでしか動作がサポートされていない…!」といったケースにおいて、非常に有用です。設定方法も非常にシンプルで、事前に作成したコンピューターグループに対して、パッチを拒否したいアプリケーションや特定のバージョンなどを指定するだけで完了します。

具体的な設定方法は以下の2ステップです。
①パッチの拒否を行うグループを設定
②パッチを拒否するアプリケーションやバージョンを指定

①パッチの拒否を行うグループを設定 

「カスタムグループ」というグループ作成機能で事前に作成したグループを設定します。業務システムが動いているサーバーなどを事前にグループにしておく必要があります。「カスタムグループ」で作成したグループは、「パッチの拒否」機能以外においても利用可能です。「カスタムグループ」機能の詳細については次回のブログにてご紹介いたします。

② パッチを拒否するアプリケーションやバージョンを指定

上記のように、アプリケーション単位での拒否をはじめ、特定のバージョンを指定して拒否することも可能です。

 最後になりますが、パッチを拒否することによって、脆弱性が放置されるリスクが伴います。そのため脆弱性の緩和対策を別途実施し、脆弱性による影響を最小限に抑える必要があることをご留意ください。

以上です。本日は2018年12月度のMicrosoftセキュリティ更新プログラムの概要と、Desktop Centralの「パッチの拒否」機能をご紹介いたしました。 

Desktop Centralについて、少しでもご興味を持っていただけましたら、「30日間の無料トライアル(評価版)」を是非お試しください。評価期間中は、無償で弊社の技術サポートを受けられます。
<<Desktop Centralのダウンロードページ>>
https://www.manageengine.jp/products/Desktop_Central/download.html

それではSee you next month!

【参照先URL】
Microsoft社
2018 年 12月のセキュリティ更新プログラム
https://portal.msrc.microsoft.com/ja-jp/security-guidance/releasenotedetail/6c54acc6-2ed2-e811-a980-000d3a33a34d

Microsoft社
2018 年 12月のセキュリティ更新プログラム (月例)
https://blogs.technet.microsoft.com/jpsecurity/2018/12/12/201812-security-updates/ 

一般社団法人 JPCERT コーディネーションセンター (JPCERT/CC)
2018年 12月マイクロソフトセキュリティ更新プログラムに関する注意喚起
https://www.jpcert.or.jp/at/2018/at180050.html 

IPA 情報処理推進機構
Microsoft 製品の脆弱性対策について(2018年12月)
https://www.ipa.go.jp/security/ciadr/vul/20181212ms.html


SCCMに代わる、手頃で手軽なエンドポイント管理ソフトとは?

$
0
0
Reading Time: 1 minutes
この記事の所要時間: 約 3分

本ブログは、Angsuman Hazarika氏による記事を翻訳、一部加筆したものです。リンク表記箇所については、原文から引用しております。

IT資産管理ソフトを使用せずにエンドポイント管理を行うのは、かなり難しいです。Microsoftはエンドポイント一元管理市場をリードしていますが、System Center Configuration Manager (SCCM)の代替となる良いソフトはあるのでしょうか?低コストで、すぐに使いこなせるソフトはあるのでしょうか?ソフトウェア配布や、パッチ配布、役割の管理、クライアント管理などの”単純”な作業は本当に簡単なのでしょうか?

Desktop CentralがSCCMに代わる最良のソリューションだと言える理由は6つあります。


1)簡単なクライアント/エージェント設定

SCCMのクライアント設定方法は複雑で、BITSバックグラウンド転送の制限、クライアントキャッシュ、クライアントポリシー、コンプライアンス、ハードウェア/ソフトウェア、さらにその他10以上のコンポーネントなど、かなり多くの項目の設定が必要です。
一方、Desktop Centralのクライアント設定は、エージェントをインストールするだけなので、簡単で迅速な実装が可能です。手間のかからないクライアント管理ソフトを探している方にとって、Desktop Centralは最良のSCCM代替ソリューションです。

 

2)簡単なパッチ管理

SCCMを介してソフトウェアをアップデートするには、多くの事前準備が必要です。例えば、サイトシステムサーバーでのIISの実行、WSUSサーバーのインストール(必須のホットフィックス3095113および3159706でバージョン3.2および4のみ)、リモートサイトを管理するサイトサーバーへのWSUS管理コンソールのインストール、 クライアントコンピューター上のWindows Update Agentクライアントのインストール、ソフトウェアの更新ポイントと配布ポイントのインストールと構成などです。
Desktop Centralを介したソフトウェアアップデートは、アップデートを入手することと同じくらい簡単です。全ての工程が簡単なので、煩雑な設定作業が不要です。
コンピューターをスキャン⇒アップデートを確認⇒ソフトウェアをアップデート
たったこれだけです。簡単で効率的ですよね。

 

3)サードパーティアプリケーション対応

Desktop Centralは、200以上のサードパーティアプリケーションに対応しています。タイムリーに更新し、ネットワークを安全かつ最新の状態に保つことができます。一方、SCCMには当該機能がなく、ネットワーク全体のサードパーティアプリケーションの管理が制限されるため、脆弱性が残ります。

 

4)パッチの拒否

Desktop Centralでは、特定のパッチの適用を拒否することができます。例えば、アプリケーションのパフォーマンスを維持するために古いシステムを使用している場合、Javaのアップデートをさせないことが可能です。

 

5)禁止ソフトウェアの自動削除

Desktop Centralには、禁止ソフトウェアに対する2つの機能があります。1つは、クライアントコンピューターで検出された禁止ソフトウェアを自動的にアンインストールする機能です。2つ目は、禁止されたexeファイルをブロックする機能です。ネットワーク内のシステム上ですでに実行中のファイルも含みます。これも、SCCMにはない機能です。

 

6)お手頃な価格設定

価格は、あらゆるソフトウェアの選定において大事なポイントとなります。Desktop Centralでは、最大25デバイスまで管理可能な無料版をご用意しておりますので、価格に関する問題はクリアできるでしょう。もっと多くの対象デバイスをお持ちの場合は、ライセンスをご購入いただけば、LANおよびWAN上のデスクトップを年間19.8万円から管理いただけます。
一方、SCCMのスタンダードエディションは、16コア2プロセッサのサーバーが管理対象の場合、254,400円で最大2つのオペレーティングシステム環境(OSE)を管理できます。データセンターエディションには693,600円かかります。Software Assuranceを利用する場合は、コアごとに追加料金も支払う必要があります。

 

Desktop CentralはユーザーフレンドリーなUIと、豊富な機能によって多くのお客様にご利用いただいております。Desktop Centralでは、 Wake-on-LANやリモートでのトラブルシューティング、Active Directoryレポートなど、エンドポイント管理のあらゆる面に対応できる機能があります。
無料のエンドポイントセキュリティソリューションガイドをダウンロードして、Desktop Centralがエンドポイントセキュリティをどのように維持できるかを学びましょう。

財務管理の重要性- ITの品質向上とコスト削減からとらえたITIL®

$
0
0
Reading Time: 1 minutes
この記事の所要時間: 約 7分

当連載記事について
当連載記事では、ITIL®の研修を多く手掛ける専門家が、分かり易い口語体でより実際的な観点からITIL®を解説しています。サラッと読みながらもITIL®に基づいた考え方をより実践的なレベルへ落とし込むことができます。また、ITIL®に準拠するための機能を備えたITサービスマネジメントツール「ManageEngine ServiceDesk Plus」を提供するゾーホージャパンより、欄外コラムとしてツールの詳細や関連機能の説明を行います。ITIL®の概念を把握しつつ、ツールを活用した場合のイメージを広げる際の一助となりましたら幸いです。
※ITIL® is a Registered Trade Mark of AXELOS Limited.

 

はじめに

再び「財務管理」、私の好きなお金の話です(笑。

第五回の記事「サービス・プロバイダも生活がかかっている」では、サービスストラテジ(SS)のフェーズでサービスに対する需要を予測し、それに合わせた投資をすることで無駄を防止すると話しました。また、第六回の記事「サービスを作ろう」では、ITサービスの売価を決める話をしました。いずれもお金の話なのでITサービス財務管理プロセスが関係します。今回はその続きの話です。

<「財務管理」を含むプロセス図>

ITサービス財務管理プロセスで行うことは何か?

まず、ITサービス財務管理プロセスが対象とするものは何かというと、それは「お金」です。ただ、お金と言ってもITIL®ですから、あくまでも「ITサービスに係るお金」です。組織全体のお金の管理は、経理部門で行うと思いますが、その中でもITサービスに係る部分のみ、ITサービス財務管理プロセスで扱うというわけです。

次に、ITサービス財務管理プロセスで行う主な活動は何かというと、「予算業務」、「会計業務」、「課金」の3つです。このうち「予算業務」と「会計業務」が、いわゆる予実管理に相当するとご理解いただいて、差し支えないと思います。「課金」は、お金を請求して回収する活動を指します。

「予算業務」と「会計業務」について

ということで、まずは「予算業務」と「会計業務」のご説明をします。先ほども記載した通り、「予算業務」と「会計業務」は予実管理だという話をしました。なので、行うことは「予算を組んで、その予算に基づいてお金が使われたということを管理する」そして、「使ったお金の用途を明確にする」ことになります。行うことはこれだけです。

しかし、ITIL®が目指しているのは「コストの削減」です。これは、削減したコストの一部を使ってサービスの品質向上に役立てることを考えているからでしょう。ということは実績管理の他に、おのずと「予算」が重要になってくるということです。なぜなら、実績の管理だけではいくら投資に回せるかわからないからです。

だから、どのサービス(の拡張/維持/追加等)に、どれだけの期間でどれだけの金額を投資するか(つまり「投資予定額」)や、その投資予定額に対して、どれだけの期間でどれだけの金額を回収するのか(つまり「回収予定額」)を決める。そして、それらの予定額に対して、実績として「どれだけ投資されたか」「どれだけ回収できたか」を確認するということになります。

もちろん、実際には細かい経費も管理していくことになるとは思いますが、大枠でとらえた場合は、これらの投資予定額、回収予定額とそれに対する実績の管理が「予算業務」と「会計業務」ということになるでしょう。

「課金」について

もう一つ、ITサービス財務管理プロセスでは「課金」という業務があります。課金とは顧客に請求して、その請求したお金を回収することが含まれます。が、そもそも課金するためには、売価が決まっていないとなりません。

では、売価はどこで決めるのか。売価も、もちろんお金に関することなのでITサービス財務管理で決めます。どうやって決めるのかというと、まず、ITサービスに対して課金方針(課金の有無やコストの回収率等)を決めます。そして、この方針に沿って、最終的にITサービスに値付けすることになります。

当然、売価決めはITサービスに対して行うため、SPM(サービス・ポートフォリオ管理)が行うITサービスの新規追加、廃止、変更とも連携する必要があります。もちろん、ITサービスに対する需要も関係してくる。需要が少なければITサービスが成り立たないし、多ければそれに耐えられるITサービスにしなければならないから、お金がかかる。つまり投資額が増える。なので、「予算業務」、「会計業務」、「課金」という3つの業務がメインなのです。

課金については、主にITサービスが始まってから活動するので「サービスオペレーション(SO)」のフェーズに含む方が適切と思われるかもしれないですが、投資や回収も含めて金銭的な戦略を考えるプロセスなので、サービスストラテジに位置づけられているのです。

<サービス・ライフサイクルの5フェーズ>

それが「サービスデザイン(SD)」とどう関係するの?

ところで、今回の記事は第八回です。第七回では、「サービスデザイン」というフェーズの4つのプロセス(可用性管理プロセス、キャパシティ管理プロセス、ITサービス継続性管理プロセス、情報セキュリティ管理プロセス)のお話をしました。

ITサービス財務管理は「サービスストラテジ」のプロセスなので、「何をいまさらこのタイミングで説明しているのか?」と思われる方がおられると思います。確かにその通りで、サービスストラテジの話なのでもっと前のタイミングで話してもよかったのですが…、お金の話は忘れられてしまうんです。

私はITIL®の講師もしているのですが、(短絡的な表現になってしまうかもしれませんが)「ITIL®ではお金の話は全てITサービス財務管理プロセスですよ」と説明して、翌日に「お金に関する情報はどこのプロセスに渡せばよいですか?」と受講生に聞いても、だいたい「どこ?」「プロセス?」という反応が返ってきます。たぶん、「お金」は身近にありすぎ、かつ「管理して当然」という思いがあるので、改めてITIL®のプロセスとして位置付けられても聞き流されてしまうのだと思います。

そして、さらに言うと、サービスデザインのフェーズまで来て初めてコストらしいコストがかかってくるんです。サービスストラテジでは戦略を立てるための工数(つまりコスト)がかかってます。が、実際にはそのコストはあまり組織の中で考慮されない。少なくともITサービスには紐づけない。間接費のように共通費用として扱われていますから。

しかし、サービスデザインのフェーズになれば、もっと具体的にITサービスに紐づく形でコストがかかってくる。ITサービスを設計するために専門家が活動するし、設計用のツールも購入する。また、ITIL®のフェーズではないですが、設計の横で開発プロセスも開始され、そうなれば当然開発費用がかかってくる。サービスストラテジより先のフェーズではITサービスに対するコストが如実に現れてくる。にもかかわらず、ITIL®ではITサービス財務管理プロセスがサービスストラテジにあるため、お金に関する活動の連携が抜けてしまうことがある(正確に言うと明確に意識されないことが多い)。だから、改めてサービスデザインを扱っているこのタイミングでお話しています。

あともう一つ、改めてこちらも意識してほしいことがあります。先ほども書いたようにITサービス財務管理プロセスには、「予算業務」と「会計業務」があって、それらの業務で予実を管理している。ということは、サービスデザイン以降で実際にかかったコストはすべてITサービス財務管理プロセスに連携しないとならない。そしてITサービス財務管理プロセスはその実績をもとに、「今後も予定通りITサービスの開発や提供をし続けてよいか」を考えなくてはならない。

だから、ITサービス財務管理プロセスは、サービスストラテジのプロセスではあるものの、フェーズに限らず常にどのタイミングでも様々なプロセスと連携して予実を管理していく必要がある。そうやって、ITサービス財務管理プロセスが予実を管理することができれば、お金の可視化につながり、お金を可視化できればコストが無駄になっている部分がわかるようになる。当然コストの削減にもつながるということになります。

ITIL®が目指していたことの一つは「コストの削減」ですからね。企業活動の中では、お金の予実管理は当たり前のことなので、ITIL®で話をしても見過ごされてしまいます。しかし、ITIL®の成り立ちから考えたら聞き流してよいプロセスではないということです。だからあえてサービスデザインの話をした後に、改めてお金の話(ITサービス財務管理プロセス)の話を持ち出してみました。

最後に

次回は、サービスを本番環境に移行するサービストランジションのフェーズについてお話します。

>>記事一覧:ITの品質向上とコスト削減からとらえたITIL®

執筆者情報
日本クイント株式会社 コンサルタント 吉村友秀(よしむら ともひで)
主要資格:ITIL® エキスパート、公認情報システム監査人(CISA)

 



ServiceDesk Plus導入時のコスト削減ポイント

連載コラムをご一読頂き、ありがとうございます。今回の記事では、「ITサービス財務管理」というプロセスが「サービスストラテジ(SS:戦略)」というITIL®の最初のフェーズに含まれているということ、そしてこのプロセスが「ITサービスのコスト削減」を行う上で重要であるにも関わらず、意外と見落とされがちだという事が紹介されていました。

普段、なんとなくITIL®の用語を使っているだけではなかなか認識できないポイントですが、改めて説明されるととても納得感がありますね。

さて、ITIL®とは関連しませんが、お金の話題になったところで、今回のコラムでは「ServiceDesk Plusを導入する際のコスト削減ポイント」についてお話いたします。

ServiceDesk Plusは、ITIL®に準拠するための機能を備えたITSMツールです。そのため、ITIL®に則った業務プロセスの整理を行う上で、スクラッチからシステム開発を行うよりは遥かに効率的な実装が可能です。

しかし一方で、「とりあえずツールさえあれば何となる」という発想から「ツールの導入そのものが目的」となってしまうことは、あまりお勧めできません。当社はメーカーの立場なので、ともすれば「ツールライセンスさえ売れれば何でもいいのでは?」と思われるかもしれませんが、やはりそうではありません。

ServiceDesk Plus導入による業務効率化やコスト削減のメリットを最大限に感じ、長期的なご利用をご決定頂くことで、はじめてお客様とメーカー双方のメリットが生まれると考えるためです。そのためには、ツール導入に先行する初期アセスメントが重要な鍵となります。

ServiceDesk Plusは、導入やカスタマイズが簡単で、価格帯も安価です。とは言え、どんなプロジェクトでも目標設定が曖昧であったり、担当者が片手間でしか作業できなかったりする場合は、ROIが測定できなかったり、プロジェクトの進捗遅延が発生したりしてしまいます。

よくあるケースとして、下記のような例が挙げられます。

・当初は自力での実装を目指していたが、担当者が兼務のため工数を割けず、ツールのライセンスだけお蔵入りになってしまった

・計画時の設計が甘く、後からどんどん実装内容の変更を行ったために実装支援費が2倍になってしまった

上記は、ServiceDesk Plusの特長を上手く生かせなかったケースと言えます。導入費&運用コストを抑え、プロジェクトをより効果的に遂行するために、アセスメント力の高いSIerを選定したり、最初に自社向けのツール運用トレーニングをしっかり受けて、内製的な運用スキルを向上させたりすることをお勧めします。

<相談をしたくなったら…>

ManageEngineはメーカーの立場なので実装支援は行っておりませんが、アライアンス先と提携してご提案することは可能です。もし、「何から手を付けていいか分からない」などのお悩みがございましたら、以下もお気軽にご利用ください。

>>【訪問/デモ依頼窓口】ITSMツール 導入課題相談

 

その他、下記の情報もぜひご利用ください。

<製品について情報収集したい方>

<製品について質問したい方>

ログの相関分析でサイバー攻撃の兆候をいち早く検知

$
0
0
Reading Time: 1 minutes
この記事の所要時間: 約 3分


増えつづけるサイバー攻撃

2017年に世界で猛威を振るった「WannaCry」を代表に、今年12月には実名制Q&Aサイトを運営する米Quoraで約1億人のユーザー情報が漏洩するなど、昨今、サイバー攻撃関連のニュースは注目を集めてきました。

攻撃が成功する要素は、大きく2つ挙げられます。1つはセキュリティホールといわれる抜け穴の存在、そしてもう1つは悪意ある内部関係者の存在です。この2つに対して、企業の大半はなんらかの対策を講じているにも関わらず、被害件数は一向に衰える気配をみせません。

以下は、NICTサイバーセキュリティ研究所がまとめた分析結果です。2017年に観測されたサイバー攻撃関連の通信は計1,504億パケットにも上り、1 IPアドレスあたり、年間約56万パケットが計測されている計算となります。中でも2016年以降から、その量が顕著に増え続けているのがグラフから明らかです。

【ダークネット観測統計 1 IPアドレスあたりの年間総観測パケット数】

出典:NICTER観測レポート2017の公開

組織で導入されているITインフラストラクチャは多岐にわたり、近年はクラウドとオンプレミスが混在した運用も珍しくありません。ITリソースには、スイッチ・ルーター・ファイアウォール・コンピューターなど、多様なネットワークデバイスが含まれます。そのすべてに対して、出力されるログを個々に監視し、攻撃の兆候を検知することは、システム管理者にとって簡単なことではありません。


ログをためて終わり、そんな状況になっていませんか?

「なにか問題が起きたときのため、とりあえずログをためておこう」
そのような考えの元、ひとまずログをためているという企業は少なくないかと思います。実際、有事の際に被害の発生経路や要因を調査するためのトレーサビリティを確保することは重要であり、JPCERT/CCでも最低1年間のログ保管が推奨されています。

【標的型攻撃対策におけるログ保管の種類と推奨期間】

※ 「ログを活用した高度サイバー攻撃の早期発見と分析 (プレゼンテーション資料)」を参照の上、編集・加筆

しかし、ログの長期保管により攻撃が判明した時に調査を行うことができたとしても、攻撃を未然に、あるいは早期に検知し、被害を最小限に留める「セキュリティ対策面」までは対応できません。そこでSIEMのような相関分析に対応しているツールを使用することで、異なるデバイスのログを一元的に保管するだけでなく、それらのログを相関的に分析して攻撃の兆候を検知することが可能です。

< あわせてCHECK! >
SIEMという選択(前編) – なぜSIEMが選ばれるのか?
SIEMという選択(後編) – SIEM製品を選択する基準とは?

そこで、今回はManageEngineが提供する簡易SIEMソフト「Log360」の相関分析(コリレーション)機能についてご案内していきたいと思います。


解説!Log360のコリレーション機能

ネットワークの攻撃は常に変化を遂げており、予測が難しいものとなります。従来から存在しているパスワードクラック等の被害は今なお存在していますが、一方でランサムウェア攻撃といった新しい手法の登場など、攻撃は年々多様化しています。それらの攻撃を常に把握することは困難ですが、対策の一つとして攻撃の兆候をいくつかの具体的なステップに落とし込み、「一般的なパターン」を定義して監視する、ということが有効な手段として挙げられます。

Log360のコリレーション機能は、定義したルールを元にログ種別をまたいで相関的に分析し、一致した場合はメールによる通知を瞬時に行うことが可能です。また、攻撃の可能性がある基本的な兆候として、30のルールがデフォルトで組み込まれています。例として、デフォルトルールの1つである「ブルートフォース攻撃」の検知方法をご紹介します。

< ブルートフォース攻撃の検知 >
ブルートフォース攻撃とは、最も基本的な攻撃である一方、ネットワークに不法侵入する手段として、今なお効果的です。典型的なブルートフォース攻撃では、侵入者はネットワークに不正アクセスするため、ログオン認証情報として考えられる文字列の組み合わせを網羅的に入力していきます。また、一つ一つ手で入力すると大変な時間がかかってしまうため、総攻撃を仕掛けるプログラムを生成して、コンピューター側で自動的に入力チェックを繰り返す処理を実行するケースもあります。このトライアンドエラーの方法は、対策を行っていない場合に致命的となり得ます。
EventLog Analyzerでブルートフォース攻撃を検知する方法:EventLog Analyzerのコリレーション機能では、デフォルトにて一つのデバイスに対して10分以内に10回以上ログオン失敗イベントが発生し、次の10分以内にログオン成功イベントが発生した場合に、ブルートフォース攻撃の可能性があると判断します。

なお、EventLog Analyzerがブルートフォース攻撃を検知した場合、以下のように表示されます。

特長1) 発生件数を時系列でグラフ化
いつ・何件の疑わしいイベントが発生したかという件数の遷移をグラフで表示
特長2) 発生イベントをタイムラインで表示
攻撃の兆候として一致すると判断された一連のイベントを、タイムラインで表示
特長3) フォレンジック分析に対応
同じ時間内に関連のユーザーまたはデバイスによって実行されたイベントの一覧をワンクリックで抽出

このように、Log360のコリレーション機能を使用することで、より多面的にログを監視することができ、サイバー攻撃の早期検知に役立ちます。

《関連ホワイトペーパー》

相関分析を活用した脅威イベントの早期検出

攻撃の速やかな検知・特定に有効とされる「相関分析」。
本ホワイトペーパーでは、相関分析のプロセス、セキュリティ対策における相関分析の役割、そしてLog360に搭載されているコリレーション機能についてご紹介します。
>> ダウンロードはこちらから (PDF) <<

 

 


☆☆Log360の製品ホームページはこちら
☆☆☆Log360の概要を紹介した資料はこちら

休日をゆっくり過ごしませんか?ネットワークの管理を自動化する方法とは

$
0
0
Reading Time: 1 minutes
この記事の所要時間: 約 7分

自動化のイメージ

こんにちは、ManageEngineエンジニアもどきの園部です。

もうすぐクリスマスや年末年始のシーズンですね!お休みの計画は立てましたか?

……え?クリスマスも年末年始も仕事?
担当のシステムやネットワークに問題が起きたら呼び出されるから休んでいる気がしない??
・・・(´・ω・`)

大事な休日をゆっくりと過ごすため、ネットワーク管理の自動化を始めてみませんか?

というわけで、今回は、IT運用管理の自動化について考えてみたいと思います。

目次

まずは通常業務の自動化

(何故こんなことまで自分がやらなくてはいけないのか……)
(今日もやりたかった仕事に手が付けられなかった……)

日々同じことを繰り返すだけの作業に対して、そう思ったことはありませんか?
しかしそのような業務は、大抵の場合、必須とされていることが多いのではないでしょうか。
また、個人の采配で勝手にやめられないものが大半であると思います。

自分で融通の利かない、かつ納得がいかない状況に置かれたとき、人はじれったさとイライラを感じやすいものです。

しかし!状況を悲観するにはまだ早い!
このような時間のかかるルーティン業務こそ、もっとも自動化を始めやすい部分なのです!

例をもとに、ネットワーク管理の日々の業務を自動化できる状況と、その方法を見ていきましょう。

例えば、次のようなネットワーク管理者の状況を考えます。

Aさんは、社内の注文管理システムを管理する部署に所属しています。
その中でもAさんは、ネットワーク機器と、システムが稼働しているサーバー、サーバー内で稼働しているWebサーバーとアプリケーションのプロセスの死活を確認します。

注文管理システムでは、連携企業からの注文が直接入る仕組みになっています。連携企業は複数あり、それぞれ休日が異なるため、Aさんの会社が休みの日にも注文が入ります。
Aさんと所属部署で、これまでの傾向からアクセス集中が見込まれる時間帯やシーズンのデータを基に、該当の期間には予め待機サーバーを起動させて、負荷分散をします。

この業務の例の場合、大きく分けて2つの業務をしていることが読み取れます。

  • ネットワーク機器、サーバー、プロセスを常時監視している
  • 定期的に待機サーバーの起動または停止等をしている

まずは、これらの定型業務を自動化する方法を確認しましょう。

ネットワーク機器・サーバー・プロセスの監視

これらは、ネットワーク監視、サーバー監視用のツールを用いることで簡単に自動化できます。

ネットワーク監視、サーバー監視製品には、無料のものから、数千万するものまで、様々な種類があります。

その中でも、ネットワーク機器、サーバー、サーバーの中のプロセスの3種類の監視を満たすためには、

  • ネットワーク機器、サーバーが同じコンソールで管理・監視できる
  • サーバーの中のプロセスの起動状況を確認できる

ことが、製品選びの上で外せない条件になります。

また、ツールの導入の上でとんでもない工数がかかったり、ツールの保守で業務が増えたりしたら本末転倒です。
このため、製品は、導入が簡単であり、操作画面もわかりやすいものであることが望ましいと言えます。

待機サーバーの起動または停止

Aさんの例の場合、負荷が高くなるタイミングのデータを基にして手動で待機サーバーを起動、停止するとのことでした。

このような作業を自動化するには、ネットワーク監視製品が、定期的にサーバーの起動や再起動等の操作を定期的に実行できる機能を持っている必要があります。

決まっている動作を「毎週水曜日の午前6時」であったり「毎月25日の0時」など、細かく指定して定期的に実行できるものを選びましょう。

障害対応の自動化

ネットワーク障害対応のイメージ

先ほどのAさんの例の続きを考えます。

以前、Aさんの企業が休日の間に、注文管理システムの本体サーバーに異常が発生し、システムの一部が停止していたことがありました。
この時連携企業から受けた注文はシステムに入っておらず、のちに発覚し問題になったことがあります。
現在は、監視ツールで異常を検知したら電話での音声通知を受ける仕組みになっており、異常事態の場合は急いでサーバーのもとにかけつける態勢になっています。

休日に障害対応で駆けつけなければならないのは、とても大変です。

休日にまで障害対応に追われる前に、障害を予兆検知して予防できたら理想ですよね。
また、障害が発生しても、自動で復旧してくれるような態勢ができていたら、より良いかと思います。

この場合、ネットワーク管理を自動化する上で必要になることは、

  • ネットワークの異常を、インパクトが大きくなる前の状態で検知すること
  • 障害を検知した際に、適切な行動を自動でとれること

と考えられます。

予兆の検知

“予兆の検知”と聞くと、

「機械学習?マシンラーニング??」
「AI??」

といったように、難しく捉えられがちです。

しかし、上のような、サービスダウンが発生してしまうようなインパクトの大きい問題の場合は、その前から、サーバーのCPUやメモリの使用率高騰がずっと続いていたというようなことが多いです。

このため、予兆検知の第一歩として、ネットワーク機器のサーバーのリソースを確実に監視していくことから始めましょう。
これにより、大きな影響のある障害を減らしていくことができます。

障害検知時の対応自動化

「この時はこう」
「あの時はこれ」

という、状況に応じて色々な対応をとれるようにしようとすると、以下のようなものを思い浮かべませんか?

if(val1 != 1000){
 val2++;
 ……
}else{
 ……
 ……
}

そう、プログラムです。

予めプログラムで、状況を場合分けして、それに応じた対応を決めていたら、何でもできるかもしれません。

しかし、ネットワーク管理者はプログラマーではない場合が多いです。たとえプログラミングに詳しい担当者がいたとしても、プログラムの作成には、時間がかかるものです。

このことから、ネットワーク監視ツールでの自動化を考える場合、対応フローが、プログラムの必要なく簡単に作成できるものであることが望ましいです。

また、すでに独自のプログラムを持っている場合、それも同時に活かせるようなツールであれば、応用が利きます。

自動化後に確認すべき点

これまでの条件を満たすネットワーク監視ツールを導入したとして、ネットワーク監視や障害対応を自動化しても、丸投げにすべきではありません。

そもそもの障害原因の特定や、環境の改善のためには、

  • いつ、どんな問題が発生したのか
  • 自動化によって、いつ何が実行されたのか

を把握しておくことが大切です。

これにより、問題が発生する傾向や頻度をつかむことができます。

頻発している場合は、根本原因を特定して発生しないようにするなどの、環境の改善活動に繋げることができます。

OpManagerの場合

ご参考までに、当社のネットワーク統合監視ソフトの「ManageEngine OpManager」での、自動化例をご紹介します。

ネットワーク機器・サーバーの監視登録

OpManagerでは、複数ベンダーのネットワーク機器やサーバーを、細かい設定の必要がなく監視を開始することができます。

装置のディスカバリー(装置登録)から、監視したい機器があるネットワークの範囲を入力していくと…
OpManagerディスカバリー画面
自動で機器ベンダーや機器タイプが識別され、監視が開始されます。
OpManager 装置監視画面

こうして、面倒な設定や手間がなく、ネットワーク機器やサーバー、プロセスの正常性を常に監視することができます。

2. 待機サーバーの起動または停止

定期的に何かを確認し、状況に応じて適切な行動をとるという業務も、OpManagerで自動化することができます。
OpManagerの「ITワークフロー」機能を使用して、
「○○の場合は●●」
「△△のときは▲▲」
というフローを組んで、自動で実行できるようにしましょう。

[ワークフロー]タブから[新規ワークフロー]をクリックすると……
OpManager_ITワークフロー

難しいプログラミングの必要がなく、アイコンのドラッグアンドドロップだけで簡単にワークフローができます。
上の例の場合、このワークフローが実行されたときに

  • 待機サーバーの稼働確認
    →稼働していなければサーバー起動
  • Webサーバーの起動確認
    →起動していなければ、Webサーバープロセスを起動
  • ・・・・・
  • ・・・・

というように、状況確認→実行という、普段の業務プロセスを、順々に実施し、状況に応じて適切な行動が実行されるように設定しています。

予兆検知

OpManagerで、障害が発生する前に自動で対処し、インパクトの大きい問題が発生する回数をできるだけ減らしましょう。

前段で、正常性監視のために追加したネットワーク機器、サーバーにしきい値を設定します。
これにより、いきなりダウンからの検知ではなく、CPU・メモリ使用率の高騰などのパフォーマンス低下の時点でキャッチすることができます。
OpManager しきい値の設定

また、Aさんの例の場合は、注文管理システムが、もしもWebブラウザーからアクセスするタイプだったとしたら、
注文システムのURLの死活と応答時間も併せて監視追加するのもおすすめです。

そうすると、URLの応答時間の監視から、サーバーの処理速度低下を検知することができます。
OpManager URL監視 OpManager URLの応答時間監視

しきい値を違反したものは、アラート(障害情報)としてまとめて表示されます。アラート発生と同時に通知設定をしたり、またはプログラムを個別に実行する等の設定をすることができます。
OpManager 通知プロファイル

また、上でご紹介したワークフローは、定期実行の他、OpManagerのアラート(障害情報)を基にしても実行することができます。
ワークフローを設定することで、障害情報からより細かい行動を設定して自動化することができます。

レポート

OpManagerでは、

  • 「すべてのイベント」レポート
  • 「ワークフローログ」レポート

を作成し、ネットワーク環境内で発生した問題と、実行されたワークフローの履歴を閲覧、レポートとして出力することが可能です。
OpManager すべてのイベントレポート

また、レポート機能では、監視対象サーバーやネットワーク機器の、休暇期間中のパフォーマンスも、あとからレポートとして簡単に図表化することができます。
OpManager レポートビルダー

まとめ

ネットワークの管理を自動化するために必要なネットワーク管理・監視ツールの条件について、これまで考えてきました。

ポイント

ネットワーク監視ツールの導入により…

  • ネットワーク機器、サーバー、プロセスを常時監視
  • 障害の予兆を検知
  • 状況に応じて対応フローを自動実行
  • 自動化後のレポート出力して分析

できることが大切!

「1分1秒でも停止したら困る!」というシステムは世の中にたくさんあります。
しかし、1人の人間は、1分1秒も休まずに働き続けることはできません。

ネットワーク管理ツールをうまく活用して自動化をしていくことで、世の中のネットワーク管理者が休暇を満喫できるようになれば幸いです。

関連リンク

OpManager公式ホームページ
OpManagerのダウンロードはこちら
OpManager製品概要資料のダウンロードはこちら
※永年無料版の利用をご希望の方は、30日間フル機能ご利用いただける「評価版」をダウンロードしてください。30日が過ぎると自動的に10デバイスまで監視可能の永年無料版となります。

▼▼ 関連記事 ▼▼

▶ 連載【ZabbixとOpManagerから学ぶ!統合監視の世界】
はじめに
01.Zabbixをインストールするまでの流れ
02.OpManagerをインストールするまでの流れ
03. 監視ソフトをインストールしたサーバー自身を監視する方法
ちょっと余談01. SNMP, WMI, CLIの違いについて
04.Zabbixで監視する機器を登録する方法
05.OpManagerで監視する機器を登録する方法

【2018年版】今年の最悪のパスワードは?

$
0
0
Reading Time: 1 minutes
この記事の所要時間: 約 4分

毎年恒例のセキュリティ製品を提供する米国SplashDataによる、「ワースト・パスワード100」の2018年版が2018年12月14日に発表されました。SplashDataは、インターネット上に流出した500万以上のパスワードの統計をとり、ハッキングされやすいパスワードをリスト化しています。

https://www.teamsid.com/100-worst-passwords-top-50/ (1-50位)
https://www.teamsid.com/100-worst-passwords/ (50-100位)

トップ10には、おなじみの顔ぶれが並んでいます。

順位 パスワード
1 123456
2 password
3 123456789
4 12345678
5 12345
6 111111
7 1234567
8 sunshine
9 qwerty
10 iloveyou

6年連続で「123456」がトップとなりました。今年は著名人の名前がパスワードに使われているケースも多く、なかにはトランプ大統領にちなんだ「donald」も23位にランクインしています。上記のトップ10からもわかるように、今だに多くの人が分かりやすい文字列や単語をパスワードとして使い続けているようです。

このような状況に対してSplashDataは、以下のようにアドバイスしています。

SplashData offers three simple tips to be safer from hackers online:
1. Use passphrases of twelve characters or more with mixed types of characters.
2. Use a different password for each of your logins. That way, if a hacker gets access to one of your passwords, they will not be able to use it to access other sites.
3. Protect your assets and personal identity by using a password manager to organize passwords, generate secure random passwords, and automatically log into websites.

SplashDataからの呼びかけ内容
  • ■1 アルファベットや数字などを含む12文字(12桁)以上のパスワードを使う
  • ■2 サービスごとに異なるパスワードを使うことで、パスワードが漏えいしても被害を最小限に抑えることができる
  • ■3 パスワード管理ソフトウェアを使い、ランダムなパスワードを生成することで資産と個人情報を保護できる

これを機に、自分が使っているパスワードが「ワースト・パスワード100」にランクインしていないか、確認してみてはいかがでしょうか。

総務省が推奨する「安全なパスワード」とは?

SplashDataでは、12文字以上のアルファベットと数字などを含むパスワードを使用するよう呼びかけていますが、総務省では、これらに加えて、名前や英単語をそのまま使用しないよう注意を促しています。

総務省が推奨する具体的なパスワードの作成条件は以下となります。

総務者が推奨する「安全なパスワードの作成条件」
  • ■1  名前などの個人情報からは推測できないこと
  • ■2 英単語などをそのまま使用していないこと
  • ■3  アルファベットと数字が混在していること
  • ■4  適切な長さの文字列であること
  • ■5 類推しやすい並び方やその安易な組合せにしないこと

さらに、パスワードは他人に見られることのないように厳重に保管することや、パスワードの使い回しはやめるよう記載があります。

ツールを活用したパスワード管理方法とは?

SplashDataや総務省が推奨する安全なパスワードの条件をご案内してきましたが、世の中にはいろんなサービスがあるので、よくないとわかっていても、共通のパスワードや覚えやすく推測もしやすいパスワードを使っているケースは多いでしょう。定期的にパスワード変更をさせるようサービス側で設定していても、パスワードの作り方がパターン化し、特定のパスワードを使い回すケースも多いようです。

こういったパスワードの問題をZohoが提供するZoho Vaultで解決することができます。Zoho Vaultは、アカウント/パスワードを安全に保管できるクラウドサービスで、対象のサービスにワンクリックでログインできるため、パスワードを覚える必要がありません。そのため、特定のパスワードの使い回しを防止できます。組織間でのパスワード共有にも対応しており、企業単位でパスワード管理の向上につなげることも可能です!

さらに、特権IDに特化したパスワード管理では、ManageEngineが提供するPassword Manager Proというツールがあります。Password Manager Proには、セキュリティ強度の高いパスワードをランダムで生成し、ワンタイムパスワードとして利用したり、定期的な変更を行ったりする機能が備わっています。

また、パスワードを表示せずPassword Manager Proの画面からワンクリックで管理対象機器にログインさせる機能も備わっているため、より安全な特権ID管理を実現できます。

【参考資料】
・「SplashData’s Top 100 Worst Password of 2018」

SplashData’s Top 100 Worst Passwords of 2018


・「安全なパスワード管理 国民のための情報セキュリティサイト」
http://www.soumu.go.jp/main_sosiki/joho_tsusin/security/business/staff/01.html


 

【関連リンク】
☆Zoho Vaultの製品ホームページはこちら
☆ManageEngine Password Manager Proの製品ホームページはこちら

Viewing all 376 articles
Browse latest View live