セキュリティ

共有アカウントのパスワード管理について

Chris Stoneff

概要 :

• 特権アカウントのパスワードを共有するリスク
• パスワードの格納方法
• 共有パスワードの管理と保護
• 規制遵守

目次

問題を理解する
長いほど良い
ドメインによる侵害
弁明
規制策定者の意図
自動化によるアプローチ
検討事項

管理者が対応に追われているもので一般的なものの 1 つに、共有している特権アカウントのパスワードを定期的に変更する作業があります。

たとえば、Administrator アカウントや root アカウント、Firecall アカウント、プロセス アカウントなどです。組み込みの Administrator アカウントまたは root アカウントは、Windows®、Linux、および UNIX のすべてのバージョンに組み込まれているアカウントで、常に同じセキュリティ ID (SID) またはユーザー ID (UID) を持っています。Firecall アカウントは、セキュリティで保護されたシステムに対して緊急にアクセスが必要な場合に使用できるアカウントです。このような Firecall アカウントや Administrator アカウントは、特権のないユーザーが、問題発生時に主要システムにアクセスするのに使用することがあります。プロセス アカウントは、サービス、タスク、COM+ アプリケーション、埋め込みアイテム (スクリプトやログインが必要な他のバイナリ ファイル) の実行に使用するアカウントです。

現在、多くのシステムはインストール スクリプトやイメージを使用して展開されています。また、ワークステーションやサーバーでは、Administrator という同じ名前のアカウントと同じ 8 文字のパスワードが使用されていて、そのパスワードは、おそらくシステムの展開時に設定してから一度も変更されていないでしょう。そのため、複数形の passwords ではなく単数形の password を使用しました。

ベスト プラクティスに従って、または規制遵守の一環として、このようなアカウントのパスワードを変更せざるを得ない状況に追い込まれている管理者もいるでしょう。たとえば、このような規制遵守の対象になるものには、米国企業改革法 (SOX)、クレジット カード業界 (PCI) のセキュリティ基準、または医療保険の相互運用性と説明責任に関する法律 (HIPAA) などがあります。このようなアカウントのパスワードを把握している管理者や技術者が退職したときには、セキュリティ侵害やクレジット カードを処理できなくなる危険性を恐れて、パスワードを変更することがあります。このような要因はありますが、企業自体のセキュリティと保護する必要がある企業データのセキュリティを確保できるかどうかは、管理者がこのようなアカウントのパスワードを変更するかどうかにかかっています。

問題を理解する

このようなアカウントとパスワードを管理する際には、次の 3 つの事項を理解しておく必要があります。

1. パスワードが古くなると、パスワードの安全性が弱まります。
2. 一般的に、パスワードは長いほど、解読するのが難しくなります。
3. コンピュータがドメインに属しているだけでは、コンピュータの認証方法は変わりません。すべてのドメインは、ワークグループという概念に基づいています。

「パスワードが古くなると、パスワードの安全性が弱まります」という表現は誤解を招く可能性があります。これは、「コンピュータに侵入する意思がある場合、それを実現するのに必要なのは時間だけです」という意味です。「パスワードを解読するには、どれくらいの時間がかかりますか」という質問に対する明確な回答はありませんが、次の質問は、特定のシステムのパスワードを解読するのに必要な時間を特定するのに役立ちます。

• そのパスワードは何人の人が把握していますか。
• そのパスワードを把握している人は、現在も在籍していますか。
• そのアカウントのパスワードを把握している人が退職している場合、その人は円満に退社しましたか。
• フロッピー ディスク、CD ドライブ、DVD ドライブ、またはネットワークからブートするアクセス許可を拒否していますか。
• コンピュータのユーザーは、ローカルの Administrators グループのメンバですか。
• 社内の全システムの特権アカウントで同じパスワードを使用していますか。

まずは、1 つ目の質問から見てみましょう。秘密を知っている人が多ければ多いほど、その秘密が公知となる可能性は高くなると言えます。私は、共有しているパスワードに同じ値を設定して、IT スタッフと研修中のスタッフに、そのパスワードを通知した方が、パスワードを要請されたときに、その都度入力するよりも都合がよいと思っている管理者がいる企業で働いたことがあります。当然の結果ですが、このようなことを続けていくうちに、その企業では、承認されていない設定を使用しているコンピュータが増え、通常のネットワーク ユーザーが、このような特権アカウントでログインできるようになりました。

このようなパスワードを把握している人が全員退職していなくて、会社に対する満足度と忠誠心が高ければ、このアクセスによる危険性は多少軽減されます。けれども、対処しなければならない悪意のあるユーザーはいつ現れるかわかりません。パスワードを把握しているユーザーが仲たがいした状態で退職した場合、このアカウントを使用してネットワークに入り込む方法を把握している規制できない悪意のある分子を抱えることになります。

ハード ドライブ以外のデバイスからブートするアクセス許可を拒否していない場合、Windows PE などの承認されていないイメージを使用してブートしたり、コンピュータのファイル システムから直接読み取って、セキュリティで保護されたコンピュータの記憶域にアクセスできるさまざまな Linux システムを使用してブートしたりするのを許可することになります (多くのセキュリティ侵害は、内部的な要素に起因しています。全スタッフと研修中のスタッフが現在も会社で働いていたとしても、パスワードとシステムのセキュリティが確保されていることの保証にはなりません)。

前任者のアカウントを使用してログインできるという理由で、そのアカウントを使用してネットワークにログインしている人は少なくありません。単にシステム パスワードを変更しないという悪習を指摘してるだけだと考えれば興味深いことかもしれませんが、このようなユーザーが悪意を持っていた場合、ユーザーがシステムに対して及ぼす可能性のある損害を考えると恐ろしことでもあります。

DVD ドライブやネットワークからのブートを許可すると、ユーザーの操作を監査できなくなります。たとえば、Linux のブート ディスクやネットワーク イメージを使用すると、ファイル システムに直接アクセスできることがあります。複数のシステムで特権アカウントに同じユーザー名とパスワードを使用している場合、そのシステムには大きな欠陥があることになります (ただし、これらの項目については、後で詳しく説明します)。

適切なパスワードの有効期限と長さは、パスワードの解読に使用する方法によって異なります。強引な方法を使用したパスワードの解読に対応する場合、問題となるのは時間です。パスワードの変更頻度が低いほど、パスワードを解読しようとしているユーザーがパスワードを取得するのにかけられる期間が長くなります。

また、長いパスワードを使用すると、パスワードには、さまざまな文字が含まれるようになるので、パスワードの解読には時間がかかります。パスワードの長さが 7 文字以下であるのか、8 ～ 14 文字であるのか、または 15 文字以上であるのかは重要な検討事項です。パスワードが 15 文字以下で Windows を使用している場合は、システム構成またはグループ ポリシーで、LAN Manager (LM) ハッシュを無効にしていますか。

パスワードの長さが、どのようなものに影響があるのかについてですが、Windows の場合は明快です。マイクロソフトのハッシュ処理についての歴史は省略しますが、マイクロソフトでは、LM ハッシュとメッセージ ダイジェスト 4 ハッシュ (MD4) という 2 種類のハッシュを採用しています。マイクロソフトでは、既定で LM ハッシュを使用します。ハッシュの格納を明示的に無効にしない限り、すべてのパスワードの値は 14 文字まで格納されます。格納される 14 文字のパスワードは、2 つの 7 文字の値で構成された文字列に分けられます。1 つ目の文字列は前半の 7 文字で、2 つ目の文字列は後半の 7 文字です (図 1 参照)。

図 1 ハッシュ テーブルの例

このようにパスワードの長さが 7 文字しかないと、パスワードは単一の LM ハッシュに格納されることになります。マイクロソフトでは、何年にもわたって、8 文字以上のパスワードを使用するように推奨してきましたが、その理由は、パスワードが 2 つの LM ハッシュ値に分けられるには、パスワードの長さが 8 文字以上である必要があるからです。

ただし、LM ハッシュは、一般的に知られているので、簡単に裏をかくことができるという点に注意する必要があります。現在、LM ハッシュは、旧バージョン (Windows NT® 4.0 などの下位レベル システム) との互換性を確保するために使用されています。

理想としては、より長いパスワードを使用するのが望ましいですが、現時点では、少なくとも LM ハッシュが作成されない 15 文字以上のパスワード (厳密には、パスフレーズ) を使用することをお勧めします。ご使用の環境で 15 文字以上のパスワードの使用を義務化するのが適していない場合は、イメージ作成処理 (ローカル ポリシーを使用) と Active Directory® グループ ポリシーの両方で LM ハッシュの格納を無効にすることをお勧めします。

このポリシーは、[コンピュータの構成\Windows 設定\セキュリティの設定\ローカル ポリシー\セキュリティ オプション] にあります。"ネットワーク セキュリティ: 次のパスワードの変更で LAN Manager のハッシュの値を保存しない" ポリシーの設定を [有効] に設定します。

大文字と小文字の使用だけでなく、数字や特殊文字の使用を検出するポリシーを適用すると良いでしょう。また、可能であれば、パスワードの文字数が 15 文字以上であるかどうかを検出するポリシーを適用することをお勧めします。

長いほど良い

現在、コンピュータへの侵入に使用する手法に、レインボー テーブルと呼ばれるものがあります。この手法では突破口として LM ハッシュを使用しますが、長いパスワードを使用すると、レインボー テーブルの有効性を無効にできます。

セキュリティの専門家であるはずの管理者が、レインボー テーブルについて、ほとんど知らない (または、まったく知らない) という事実には驚きました。レインボー テーブルの作成方法はさまざまですが、対象のアルゴリズムによって異なります。しかし、レインボー テーブルは単に 0 ～ 14 文字の LM ハッシュ値を事前に計算した一覧にすぎません。

レインボー テーブルを使用した攻撃の対策では、攻撃者が LM ハッシュを取得しなければならないという点を利用できます。このことは、許可しているシステムのブート方法 (CD、DVD によるブートを許可しているかどうか)、ユーザーがローカルの Administrators グループのメンバであるかどうか、という質問と関連があります。このような LM ハッシュは、pwdump などのフリーウェアを使用して、ものの数秒で取得できます。レインボー テーブルを使用した攻撃では、取得した LM ハッシュを検索して、パスワードを特定します。

私の個人的な好奇心を満たすために、システムの組み込みの Administrator アカウントにパスワードを設定しました。このパスワードは 14 文字にし、さまざまな大文字と小文字の文字だけでなく、特殊文字と数字を含めました。インターネットから無料でダウンロードしたレインボー テーブルを使用すると、システム上の全アカウントのパスワードのハッシュ値を取得することができ、Administrator のパスワードの解読には 2 分もかかりませんでした。

1 つ目の LM ハッシュ値を取得し、2 つ目の LM ハッシュ値を取得後、これらの値を組み合わせてパスワードを入手する処理を見るのは、かなり興味深いものでした。繰り返しになりますが、これより前の部分で説明したようにグループ ポリシーを使用して LM ハッシュを無効にしていれば、この攻撃を完全に阻止することができなかったとしても、大幅に制限することができます。

ドメインによる侵害

ドメインに参加しても問題は解決しません。というのも、ドメインに参加しているコンピュータの認証方法も同じだからです。繰り返しになりますが、すべてのドメインはワークグループの概念に基づいています。しかし、これは、必ずしも理解しやすいものではありません。このテーマについては多くの雑談を交わしましたが、私は管理者に対して、「コンピュータへのアクセスに必要なものはユーザー名とパスワードである」ということを頻繁に指摘していることに気付きました。このことを踏まえて、ワークグループにおける Windows の機能について説明しましょう。

システムにアクセスするときには、リモート システムにユーザー名とパスワードを提示する必要があります。Windows では、統合認証を使用して、この処理が行われます。つまり、別の Windows システムにアクセスする際には、現在ログインしているユーザー名とパスワードが使用されるということです。ですから、リモート システムに同じユーザー名とパスワードが格納されていれば、別の Windows システムにアクセスする際にユーザー名とパスワードの入力を求められることはありません。

これは「パススルー認証」と呼ばれることがあり、ワークグループ内だけでなく、ドメイン間でも機能します。ただし、最悪の場合は、システムからユーザー名とパスワードが要求されることがあります (つまり、ログイン情報を再入力する必要があります)。

ワークステーションやサーバーをドメインに追加し、Active Directory が中央アカウント リポジトリになっても、ローカルのセキュリティ アカウント マネージャ (SAM) やローカルのアカウント ストアが消えてなくなるわけではありません。このようなローカル SAM に生じる変化は、SAM が管理とセキュリティ保護の対象から外れて、問題の要因となることです。システムの組み込みの Administrator アカウントや root アカウントのパスワードを最後に変更したのは、いつですか。できたら、すべてのアカウントのパスワードの有効期間を確認できるレポート ユーティリティをダウンロードして、その結果が監査に合格するかどうかを確認してみてください。

意味がよくわからない場合は、任意のドメイン ワークステーションに、管理者特権のあるドメイン アカウントを使用してログオンしてください。システムでコンピュータの管理ユーティリティを起動し、ToldYouSo という名前のローカル ユーザーを作成します。このアカウントのパスワードを設定したら、このアカウントをシステムのローカルの Administrators グループに追加します。それから、別のドメイン ワークステーションでも、同じ手順を実行します。

どちらかのワークステーションに、ローカル アカウント ToldYouSo でログオンし、\\systemName\c$ というパスを使用して、もう 1 台のコンピュータにアクセスします。このようにすると、管理用共有にアクセスすることが可能で、しかもパスワードの入力を求められることもありません。この例に皆さんが驚いていないことを願います。この例に驚いた方がいる場合は、ぜひ、ここから学んでください。再度、繰り返しになりますが、システムがドメインに参加していても、システムがワークグループに参加しているときと同様に動作するという事実は変わりません。

共有している特権アカウントのパスワードをめったに変更しない場合、そのアカウントは危険にさらされていることになります。このような場合、ネットワーク全体を侵害するのに必要なのは時間だけです。

弁明

管理者と話をすると、その人が CIO であっても、このようなアカウントのパスワードを変更しない主な理由として、次のようなことを挙げています。

• 何千台ものシステムがあるので、これらのアカウントのパスワードを変更する時間的な余裕と人的な余裕がない。
• 必要な予算がない。
• Administrator アカウントを完全に無効にしているので問題ない。
• これまでにシステムが侵害されたことはないので、パスワードを変更しないことは問題ではない。
• 監査担当者がパスワードを変更していないことに気付かない。

最初の 2 項目については声を大にして言いますが、これらは正当な弁明にはなりません。どのような理由であれ、この問題に対応していない企業が私の個人情報を保持している可能性があると考えるとぞっとします。

ネットワーク上のすべてのシステムに機密情報が格納されているわけではありませんが、このようなシステムのユーザーは、社会保険番号、医療記録、財務データなどの機密情報にアクセスできる可能性があります。システムの管理者であれば、キー ロガーや画面をキャプチャするユーティリティをインストールしたり、グループ ポリシーを無効にしたり、さまざまなサブシステムに shim を導入してデータを取得して転送したりすることが可能です。悪意のあるユーザーが、このようなことを個人コンピュータ レベルで行っている場合は、Administrator というアカウントを使用するので、このようなユーザーを特定するのは困難です。

Windows で組み込みの Administrator アカウントを無効にしても、このアカウントを使用してログオンできなくなるわけではない、ということはご存じですか。次の例を試してみてください。システムをセーフ モードで再起動し、組み込みの Administrator アカウントでログオンします。この場合、おそらく、オリジナルのイメージでアカウントに与えられたパスワードを使用してログオンできます。この動作の詳細については、マイクロソフト サポート技術情報の資料「[HOWTO] Administrator アカウントを無効にした後でコンピュータにアクセスする方法」(support.microsoft.com/kb/814777) を参照してください。

規制策定者の意図

SOX、PCI、HIPAA などの規制に対応するのは、目が回るような作業です。各規制は拡大解釈が可能で明確に定義されていないので、その要件を理解するのは困難です。ですが、このような規制では、概してこれから述べるようなことを目的としていると言えます。

まず、特権アカウントと情報に常時アクセスできるユーザーを保証し、これを実現するための手段を提供する必要があります。これは、どのような場合においても適切な対応です。というのも、特権アカウントは、任意のシステムであらゆる処理を実行する権限を持っているアカウントだからです。それが組み込みの Administrator アカウントと Firecall アカウントです。これらのアカウントは、おそらくヘルプ デスクのスタッフ全員と管理者全員が把握しています。

このような共有アカウントのパスワードを管理するソリューションを実装するということは、組み込みの Administrator アカウントの監査証跡をゼロから作成するようなもので、流動的なパスワードを使用できるようになります。ソリューションは自動化されるので、このようなアカウントのパスワード変更に何週間もの時間をかけて生産性が低下することはありません。また、このソリューションでは監査機能が提供されるので、最終的に、企業では監査の合格率が高まります。

自動化によるアプローチ

このようなアカウントに対応する最も効率的な方法は、複数のアカウントで同じパスワードを共有することがないように、アカウントを定期的に変更することです。共有のパスワードを使用している場合、あるシステムが侵害されると、別のシステムも侵害されることになるでしょう。ですから、共通のローカル アカウントやドメイン アカウントは存在しないようにすることをお勧めします。

このようなアカウントのパスワードを管理して、無作為な文字列を割り当てる自動化されたソリューションを使用する際には、監査担当者から最低条件として課せられているものだけを対象にするのではなく、それ以上の条件も対象とすることをお勧めします。15 文字、20 文字、127 文字のように長いパスワードを設定できる (図 2 参照) 場合に、何の努力もしないで 8 文字のパスワードを使用するのは適切ではありません。

図 2 非常に長いパスワードを自動的に作成する機能を使用する (画像をクリックすると拡大表示されます)

また、図 3 に示すように、特権アカウントは毎日ランダムに変更することをお勧めします。90 日ごとに実行しなければならない理由はないので、隔月または毎日実行できる場合は、そのようにすることをお勧めします。とにかく、この処理を自動化すれば、管理者であるあなたの作業が増えることはありません。また、これを定期的に行えば、ユーザーはツールの監査対象の取得インターフェイスからパスワードを回復する必要があるので、これまでにはなかった監査証跡を実現できます (書面に記載したパスワードを封筒に入れて、オフィスの片隅にある金庫に保管している場合、そのようなパスワードについては、パスワード管理ソリューションを使用した場合のような監査証跡を得ることはできません)。

図 3 特権アカウントを毎日ランダムに変更する (画像をクリックすると拡大表示されます)

パスワードを回復したら、一定期間経過後に、そのパスワードを再度ランダムに設定できることを確認します。ここでは先ほどのスケジュール設定したアトランダムなジョブではなく、(数か月ではなく数時間だけ有効な) 1 回限りのパスワードの作成について話しています。この場合も、ユーザーは、ツールの監査対象の取得インターフェイスからパスワードを回復する必要があるので、監査証跡を実現できます。

検討事項

共通アカウントのパスワード管理に関する問題には対応する必要があります。つまり、確実かつ定期的にパスワードを変更する方法を見つける必要があります。また、このソリューションは拡張性と柔軟性を備えていて、また、パスワードへのアクセスをセキュリティで保護し、ツールとツールのユーザーによるすべての操作を監査する必要があります。さらには、共有アカウントの情報を使用したシステムの侵害を防ぐため、すべてのシステムに一意なパスワードを発行する必要があります。

この問題に長年取り組んでいるベンダは数多く存在しますが、この分野には新たなベンダも参入しています。この問題に対応するツールを購入する際には、ご自身で調査を行い、ご使用の環境に適していることを確認してから購入することをお勧めします。

Chris Stoneff は、セキュリティとシステム管理に関するソフトウェアを開発している Lieberman Software (liebsoft.com) のプロダクト マネージャです。彼を最も駆り立てるのは、物事のしくみを理解することだけでなく、なぜ物事がそういうしくみなのかを知ることです。