• [アーティクル]

セキュリティ

大論争 : 隠すことによるセキュリティ

Jesper M. Johansson and Roger Grimes

 

概要:

  • 隠すことによるセキュリティを定義する
  • 隠すことによるセキュリティ対策を評価する
  • Administrator アカウント名を変更することの価値を判断する
  • 十分な情報に基づいてリスクを考慮した決定を下す

"隠すことによるセキュリティ" という言葉は、セキュリティに詳しい人、特に自らを専門家と考える人からは、よくひんしゅくを買います。一部の集団の間ではほぼ禁句と見なされている、

この隠すことによるセキュリティは、Wikipedia の説明 (en.wikipedia.org/wiki/Security_through_obscurity 参照) にもあるように、非常に意見が分かれるセキュリティの 1 つの側面を表しています。今後、この対策を実装している人の努力を "所詮は隠すことによるセキュリティ" と笑い物にする文章をよく目にすると思います。

簡単に言うと、隠すことによるセキュリティは、ケルクホフスの原理に反しています。この原理は、システムはその設計自体がセキュリティで保護されている必要があり、敵対者に設計が知られていないからセキュリティで保護されていると考えるべきではないというものです。ケルクホフスの原理は、基本的に "秘密はそう長い間秘密ではいられない" ことを前提としています。

これを示す非常に良い例があります。Windows NT® LAN Manager (NTLM) 認証プロトコルの設計は、最初のうちは非公開であると考えられていました。UNIX オペレーティング システム向けの相互運用製品である Samba を実装するために、Samba チームはこのプロトコルをリバース エンジニアリングする必要がありました。その結果、NTLM に関する最も包括的なドキュメント (monyo.com/technical/samba/translation/ntlm.en.html) が作成されると同時に、多くのバグが発見されました。セキュリティの大部分が暗号化によって形造られたこと、および非常に多くの非公開設計の詳細が明らかになっていることから、多くのセキュリティ専門家は、あらゆる情報セキュリティがケルクホフスの原理に従っていると考えています。

ですが、隠すことによるセキュリティは常に悪なのでしょうか。この記事では、隠すことによるセキュリティについて説明し、なぜ多くの人がこの対策を時間の無駄 (またはその逆) と考えるのか、およびなぜこの議論の答えが、例によって最初に思ったよりも複雑になるのかを解明するための手掛かりを提供します。

隠すことによるセキュリティの概要

既定の設定を変更しない (Steve Riley)

私は名前の変更に関しては、"変更しない" 側を支持します。実際には、これはセキュリティの問題ですらなく、システム管理の問題です。また、私はシステム管理について、以前よりも長い時間考えるようになったので (管理とセキュリティが同じカテゴリで扱われるようになったからです)、システムの脆弱性が高まる可能性のある操作は一切行わないという考えを以前よりも支持するようになりました。既定の設定を変更すれば、脆弱性が高まることは目に見えています。人々が既定の設定を変更する理由は 2 つ (いや、3 つですね) あります。

  • 変更によって機能の要件が満たされることがわかっている。
  • 変更によってセキュリティが強化されることを想定している。
  • (注意 : これは良識を疑うような理由です) だれかが雑誌の記事で読んだと言っていた。

1 つ目の理由で既定の名前を変更する必要がある場合は、変更して問題ありません。多くの場合、このような変更はテストを経て実装されるので、システムが不安定になることはほとんどありません。

2 つ目の理由で既定の名前を変更する場合は、少し立ち止まって考え直してみてください。このような変更は、ソフトウェアの製造元によってほぼまったくテストされていないので、その製造元も変更後のシステムの動作を予測できません。さらに通常は、真のセキュリティを提供する、より優れた方法が他に存在します。

悪意のある人物に偶然アカウント名が知られても、どうということはありません。パスワードの力によって、システムはその人物から保護されます。Administrator や Guest などの既定のアカウント名を、簡単に推測できない名前に変更するよう促される場合は、強力なパスワードやパスフレーズを使用したくないという願望が込められていることがほとんどです。本当の問題 (秘密が漏れやすいこと) を解決すれば、(既定の名前の変更による) 脆弱性を回避できます。

隠すことによるセキュリティには、問題がまったく緩和されない対策は含まれていません。たとえば、組織のネットワークの境界に設置されているルーターで、ネットワーク ニュース転送プロトコル (NNTP) をブロックして、従業員がニュースグループを購読しないようにしても、Secure Shell (SSH) の送信接続が許可されていれば、隠すことによるセキュリティが実装されているとは言えません。SSH はすべてのプロトコルをトンネルできるので、問題となる部分は隠されません。この効果の低い緩和策のメリットは、正当なユーザーがセキュリティ ポリシーに違反することなく正当なタスクを実行できることのみです。このような対策は、隠すことによるセキュリティではなく、単なる効果の低い無意味な対策です。

"隠すことによるセキュリティ" の "セキュリティ" とは、その対策によってなんらかの保護を受けることができることを示しています。ただし、もう 1 つのメッセージが含まれており (これが問題なのですが)、実際には、攻撃を受ける可能性がある部分を取り除くわけではありません (基本的に、攻撃者は、この部分を糸口にしてシステムにアクセスします)。

たとえば、脆弱性のある Web サーバーを所有しているとします。公になっているバグを突破口にし、TCP ポート 80 を経由すれば、このシステムを攻撃できます。この突破口を塞ぐには、Web サーバーに修正プログラムを適用するか、Web サーバーを停止します。どちらの場合も、このバグを利用した攻撃を完全に回避できます。また、ファイアウォールや IPsec を使用し、選択された一部のコンピュータを除くすべてのコンピュータに対してポート 80 を閉じることによって、部分的に攻撃を回避することもできます。完全に攻撃を回避できるわけではありませんが、問題は大幅に緩和されます。

一方、隠すことによるセキュリティでは、攻撃を受ける可能性がある部分を取り除くのではなく、単にその部分を隠します。たとえば、Web サーバーのポートを 80 から 81 に変更することによって、Web サーバーでポート 81 が使用されていることを知っているユーザーのみが、その Web サーバーにアクセスできるようにする場合があります。ここで議論は終わりません。実際は、Web サーバーのポートを 81 に変更しても、回避できるのは一部の攻撃のみであり、たいていはエンド ユーザーに不便を感じさせるだけです。高い技術を持つ侵入者は、単純にポート スキャナと Web バナー取得ツールを大量のポートに対して実行し、標準以外のポートを使用している Web サーバーを検出します。攻撃を受ける可能性がある部分を取り除いたわけではなく、単に (一時的に) 隠しただけなので、該当するポートを検出すれば、攻撃者はその部分を突いてサーバーを攻撃できます。

これは、隠すことによるセキュリティを試すことすら推奨されないという意味でしょうか。その答えは "ケース バイ ケース" です。情報セキュリティ分野における他のすべてのことがそうであるように、結局はリスク管理が最も重要なのです。考慮すべき重要な要素を理解するために、隠すことによるセキュリティ対策をもう 2、3 種類紹介した後、"Administrator アカウント名を変更する" という対策について詳しく説明します。

セキュリティ対策を評価する

隠すことによるセキュリティの例は数多く存在します。システム管理者やネットワーク管理者が実装するものもあれば、ソフトウェア開発者から始まるものもあります。ただし、どの対策も、脆弱性を潜在的な攻撃者から隠すことによって、その脆弱性を緩和することを目的としています。

これらの対策のうち、まったく良い効果をもたらさないものもあるのでしょうか。隠すことによるセキュリティ対策は、すべて悪だと言い切れるのでしょうか。少なくとも一部の対策を支持する人は確実に存在します。たとえば、Windows® エクスプローラでは、ドライブ文字を隠すことができます。多くの環境 (最も顕著なのは学校のコンピュータ室) では、この手法を利用して、ハード ドライブにデータが保存されないようにしています。もちろん、それでも多くのアプリケーションはハード ドライブにデータを保存できるので、究極的なセキュリティ対策と比較すると、その価値はほとんどありません。ただし、この対策を実装した施設からは、ハード ドライブ上のデータが減少したという声がよく聞かれます。

Windows 上で実装される、隠すことによるセキュリティ対策としてもう 1 つ挙げられるのは、管理用ネットワーク共有 (C$ や Admin$ など) の無効化です。この方法を使用すると、攻撃者がリモートでコンピュータに接続できなくなると考えられていますが、実際には、この意図した効果が得られないだけでなく、管理用共有を使用できるアカウントを持つユーザーは、まったく同じ共有をリモートで再度有効にできます。ただし、多くの組織からは、これらの共有を無効にすることによって、組織のネットワーク上でマルウェアが検出される確率が低下したという報告が寄せられています。

見当違いの対策の例として最も紹介したいのは、Windows の [デバイス : ログオンなしの装着解除を許可する] という設定です。この値を [無効] に設定すると、ログオン画面に [コンピュータの装着解除] ボタンが表示されなくなります。この設定は、攻撃者が簡単にコンピュータを取り外すことができないようにすることを目的としています。もちろん、侵入者は、このボタンが表示されているかどうかにかかわらず、コンピュータとドッキング ステーションの両方をバッグに詰め、それらを持ち去ることができます。したがって、この設定は、惜しくも隠すことによるセキュリティとは言えません。

もう 1 つのわかりやすい例は、[ドメイン コントローラ : サーバー オペレータがタスクのスケジュールを割り当てるのを許可する] という設定です。この設定は、まさにその名前が示すとおり、Server Operators グループに属しているユーザーがタスクのスケジュールを割り当てるのを許可します。この問題には慎重に対処する必要があります。その理由は、このようなタスクがローカル システムとして実行される場合があり、ローカル システムとして実行されるタスクのスケジュールを割り当てることができるのは、管理者のみであるからです。もちろん、サーバー オペレータはさまざまな手段で自らを管理者に昇格させる可能性があるので、実際にはこの設定を使用してサーバー オペレータがタスクのスケジュールを割り当てることができないようにしても、ほとんど効果はありません。

ただし、多くの組織はこの設定を好みます。その理由は、組織のエンジニアに、管理者ではなくサーバー オペレータの役割を与えることによって、それらのエンジニアが誤ってサーバーを破壊する可能性を低下させることができるからです。このこと自体は、いくらかのメリットをもたらす可能性があります。

では、この議論に対してどのような判決を下せばよいでしょうか。言うまでもなく、いくつかの問題は非常に複雑になる可能性があります。私たちは、隠すことによるセキュリティ対策について、充実した議論を交わしました。Roger は、これらの対策を実装することは効果的であるという主張を断固として支持しています。一方 Jesper は、ひいき目で見ても、ほとんどの場合、これらの対策は時間の無駄になると考えています。では、隠すことによるセキュリティの事例として、最も引き合いに出され、論争の的になっている、Administrator アカウント名を変更するという対策について考えてみましょう。Roger はこの対策を支持し、Jesper はそれに反対しています。セキュリティ分野で有名な Aaron Margosis と Steve Riley も、補足記事「Administrator アカウント名を変更する」と「既定の設定を変更しない」で、それぞれこの議論に参加しています。

Administrator アカウントを隠す

Administrator アカウント (相対識別子 (RID) 500) 名を、一般の人に知られていない名前に変更することは、セキュリティ専門家が推奨する対策として挙げられることが多く、マイクロソフトのいくつかのセキュリティ強化ガイドにも記載されています。また、グループ ポリシーには、Administrator アカウント名を変更するための設定が含まれています (図 1 参照)。この対策は、Administrator アカウント名を変更すれば、攻撃者が実際の管理者としてログインするのが困難になるという考え方に基づいています。もちろん、グループ ポリシーを使用してこの操作を行うことには、明らかな問題点があります。それは、Administrator アカウント名を変更すると、そのグループ ポリシー オブジェクトが適用されたすべてのコンピュータに同じ名前が登録されることです。これでは、このセキュリティ対策によって提供されるあいまいさの価値が低下してしまいます。

図 1 Administrator アカウント名の変更

図 1** Administrator アカウント名の変更 **(画像を拡大するには、ここをクリックします)

ここで、もう 1 つ重要なことを認識しておく必要があります。それは、正当なアカウントを持つユーザーは、管理者アカウント名が Administrator から変更されているかどうかにかかわらず、その管理者アカウント名を取得できるということです。Administrator アカウントの RID は常に 500 です。アカウントを持つすべてのユーザーは、単純に RID が 500 のアカウントを照会することによって、そのアカウントの実際の名前を確認できます (図 2 参照)。

図 2 Administrator から変更されたアカウント名の確認

図 2** Administrator から変更されたアカウント名の確認 **(画像を拡大するには、ここをクリックします)

Roger の見解

Administrator アカウント名を変更することへの反論として私がよく耳にするのは、セキュリティ プリンシパルのアカウント名を、そのアカウントに関連付けられているセキュリティ識別子 (SID) に変換して RID を確認するのは簡単であるという主張です。実際の Administrator アカウントの RID は常に 500 なので、攻撃者がユーザー アカウント名を SID と RID に変換して、簡単に 500 という RID を見つけることができるなら、なぜわざわざ Administrator アカウント名を変更するのでしょうか。

実際はそれほど単純にはいきません。ユーザー アカウント名を SID と RID に変換するには、NetBIOS または LDAP 用のポートにアクセスできる必要があります。ほとんどの境界ファイアウォールでは、インターネットを経由したこのようなアクセスが許可されないので、攻撃者は完全にファイアウォールを回避するまで変換を実行できません。さらに、ドメイン コントローラ (DC) を除く、Windows XP 以降のバージョンがインストールされているコンピュータに対して、匿名で SID 変換を実行することはできません。最も外部にさらされている (危険性の高い) コンピュータに対して、アカウント名から SID への変換を実行するには、認証済みの資格情報を使用する必要があります。

変換攻撃を開始するには、非常に数多く実装されている多層防御の壁を乗り越える必要があります。また、攻撃者がこれらの壁を乗り越えたとしても、最終的にはアカウント名が変更されていない場合と同じ地点にたどり着くことになります。Administrator アカウント名を変更すると、セキュリティを強化でき、これによってシステムが脆弱になることはまずありません。

もう 1 つの秘密 攻撃者が管理者アカウント名を把握していない場合は、そのアカウント名も、パスワードと同様、解き明かす必要がある "秘密" となります。確かに、ユーザー アカウント名が管理者のパスワードと同じくらい複雑である可能性はそれほど高くありませんが、このもう 1 つの障害が存在することによって、パスワードを推測および解読するという課題は飛躍的に複雑になります。パスワードの侵入テストを行ったことがあれば、ユーザー名とパスワードの両方を推測するためにどれほど多くの作業が必要であるかはご存知でしょう。既に困難な作業に、もう 1 つ複雑な作業が追加されることによって、作業はさらに困難になります。

自動化されたマルウェアとスクリプト キディによる攻撃を阻止する 私は Windows のセキュリティ防御に 22 年間携わっており、5 年前から、8 つの Windows ハニーポット (おとりのシステム) を実行し、インターネットに公開しています。この 5 年間で、Administrator (*NIX システムの場合はルート) 以外のユーザー アカウントを使用する、自動化されたマルウェア (このソフトウェアによって攻撃の大半が行われています) が確認されたことは一度もありません。Administrator アカウント名を変更すれば、Administrator という名前に依存するすべてのマルウェアによる攻撃を即座に回避し、セキュリティ リスクを軽減できます。

スクリプト キディについても同じことが言えます。私の知る限り、Windows のハッキングに関する優れたマニュアルには、アカウント名から SID への変換を利用する手法が記載されていますが、どういうわけか、私がスクリプト キディを混乱させるために公開した、"偽の" Administrator アカウントが実装されたハニーポットを攻撃するための手法は見たことがありません。優れたハッカーは、発見した Administrator アカウントが本物の Administrator (RID 500) であるかどうかを必ず検証するはずですが、彼らはこのことを検証していません。理由はわかりませんが、ハッカーが怠けているか、これが人間の一般的な習性なのでしょう。

プロのハッカーによる攻撃もほぼすべて阻止する これを聞いてほとんどの皆さんは驚くと思いますが、数年間ハニーポットを実行していると、自動化された攻撃、スクリプト キディ、およびプロのハッカーの違いがすぐにわかります。過去 5 年間で、私のハニーポットに対する何百万もの攻撃が報告されましたが、偽の Administrator アカウントが実装されたハニーポットに対して SID 変換が行われた例は 1 つもありません。

もちろん何人かの犯罪のプロは SID 変換を企てたと思いますが、おそらくそれもごく一部の少数派です。また、この変換方法は文書化および公開されていません。なぜプロのハッカーがその作業を行わないのでしょうか。おそらく、ハッカーたちは、大半の人が取り組んでいないことに対して努力する理由がわからないのだと思います。

警告を単純化する 対立するもう一方の立場は、Administrator アカウント名を変更することが一般的になれば、その手法はあいまいではなくなり、価値が失われると主張しています。つまり、マルウェア、スクリプト キディ、およびプロのハッカーが今まで取っていた作戦を変更し、単なる Administrator 以外の名前を探すようになるという考え方です。これはもっともな主張です。さいわい、基本的な条件は変わりません。まず、Windows の非常に強い特権を持つアカウントの名前が Administrator ではなくても、悪意のあるハッカーは複雑な作業を行う必要があります。これは事実です。また、悪意のあるハッカーが複雑な作業を行う必要がある場合、実際にハッカーがその作業を行う可能性はほとんどありません。その理由は、補完し合う他のいずれかの多層防御手法によって、その悪意のある行為が検出されやすくなるからです。

このことを根拠に、私が名前の変更に賛成する最後の理由を示します。Administrator アカウント名を変更し、さらにその名前を持つ別のアカウントを作成すると (図 3 参照)、優れた警告メカニズムが提供されます。イベント監査機能によって、既定の名前を使用したログオンの試行が検出されたら、すぐにそのイベントを調べることができます。

図 3 Administrator というおとりのアカウントにログオンさせることで早期に警告を受け取ることができる

図 3** Administrator というおとりのアカウントにログオンさせることで早期に警告を受け取ることができる **(画像を拡大するには、ここをクリックします)

イベント ログには、特に意味を持たない "不正な" ログオンが多数記録されます。通常それらは、ユーザー (または Windows) が誤ったパスワードなどを使用してログオンしようとしたことを示しているだけですが、Administrator アカウント名を変更しないとしたら、どのようにして正当なログオンの試行を不正なログオンの試行と区別すればよいのでしょうか。Administrator というログオン アカウントが存在しない状態で、そのアカウント名を使用したログオンの試行が検出された場合、そのログオンはおそらく不正な目的で試行されています。早期に警告を受け取って影響を小さくすることは、今日の防御にとって大きな価値があると言えます。

Jesper の見解

Administrator アカウント名を変更する (Aaron Margosis)

Jesper は、理想としては非常に正しい意見を述べています。それは、ブルート フォース攻撃を使用した推測に耐えられる強力なパスワードを設定し、さらに -500 ローカル管理者アカウントを非常時の回復にのみ使用すればよいという意見です。ただし、実際にはどちらも実現されていません。

Jesper は、セキュリティ関連の普及活動に尽力し、パスフレーズに関するすばらしい連載記事 (「パスフレーズ vs. パスワード」第 1 部 (go.microsoft.com/fwlink/?LinkId=113157)、第 2 部 (go.microsoft.com/fwlink/?LinkId=113159)、第 3 部 (go.microsoft.com/fwlink/?LinkId=113160)) を執筆しましたが、多くのシステム管理者は、強力なパスワードの最新の構成方法を理解していません。

最近まで、パスワードは複数の文字セットからランダムに選択された 8 つの文字で構成されていましたが、ムーアの法則によって、その構成方法は時代遅れになりました。ユーザー (およびシステム管理者) の教育は最も力が注がれていない分野であり、強力なパスワードというトピックがテレビのニュースの話題を独占しない限り、おそらく今後も軽視され続けるでしょう。

現在の世の中では、パスワードの推測に 6,000 億年もの時間は必要なく、多くの場合は昼食の間に完了してしまうので、1,000 倍の時間がかかるようにすることで、真の価値がもたらされる可能性があります。また、Administrator アカウント名を利用しようとする多くの自動化された攻撃は、アカウント名を変更することによって回避できます。

通常、Administrator アカウント名を変更する作業にそれほど多くの時間と手間はかかりません。先ほど述べたとおり、通常は単純な GPO の設定によって実装できるからです。実際、米国政府が規定した Federal Desktop Core Configuration (csrc.nist.gov/fdcc) では、-500 アカウント名の変更が要件として挙げられています。この名前の変更は、要件として挙げられている多くの設定の 1 つに過ぎませんが、他の要件に比べて、それほど多くの時間や注意を必要としません。また、人々がセキュリティの価値に関する誤った認識を持ってしまう場合もあります。いまだに、"管理者アカウント名を変更したから、もう修正プログラムを管理する必要はない" という声を耳にします。

組織全体でアカウント名を同じ名前に変更することは、どれほどの価値をもたらすでしょうか。若干の価値はありますが、その価値は大きくありません。その理由は、Administrator を想定した、自動化された攻撃をブロックできても、新しい名前を知らない人が、一連の潜在的な攻撃者に含まれるからです (組織全体で、ローカル管理者アカウント (名前を変更しているかどうかにかかわらず) に同じパスワードを使用している場合、リスクは高くなります。このようなリスクに対処することは、より大規模で重要な問題です。-500 アカウントを無効にすることも 1 つの方法ですが、これによってドメイン アカウントを使用できない場合の重要な回復手段が失われてしまいます)。もう 1 つ指摘しておきたいのは、マイクロソフトのセキュリティ ガイドでは長い間既定のアカウント名の変更が推奨されているので、この操作は十分にテストされており、サポートも万全であるという点です。

ここまでの説明から、隠すことによるセキュリティ対策が、単独では十分な防御策にならないことがおわかりいただけたと思います。これらの対策は、その他のセキュリティ対策を強化でき、Roger のデータがそのことをはっきりと示しています。組織のセキュリティ対策の実装コストがそれほどかからない場合は、隠すことによるセキュリティをそれらの対策から除外しないことをお勧めします。

Administrator アカウント名の変更に賛成する意見もあれば、この考えに反対する妥当な意見もあります。この話題に入る前に、Roger の最後の主張がきわめて妥当であることを認めておかなければなりません。ただし、厳重に管理されている環境では、回復が必要な非常時にのみ Administrator アカウントが使用されるので、このアカウントを使用したログオンが行われた場合は、その詳細を調査する必要があります。

過剰な対策 Administrator アカウント名を変更することによって、このアカウントのパスワードがリモートで推測される危険性を軽減できます。ただし、Administrator アカウント名の変更によって妨害を受けるのは、他にそのコンピュータの承認済みアカウントを保有していないユーザーのみです。このような攻撃者は、たいてい一連のランダムなパスワードを使用して Administrator アカウントにログインしようとしますが、アカウント名とパスワードのどちらを誤って推測した場合でも、同じエラー メッセージが表示されます。

つまり、Administrator アカウント名の変更に関する最も重要な主張の 1 つである、スクリプト キディを阻止できるという考えには不備があります。元の Administrator アカウント名から別の名前に変更しても、スクリプト キディはその変更に気付かないので、すぐには攻撃を終了しません。スクリプト キディは、同じ一連のランダムなパスワードを使用して推測を行った後、攻撃できる可能性のある次の標的に移ります。

これは、Administrator アカウントのパスワードが、攻撃に耐えられるほど強力であれば、アカウント名を変更しても、それ以上の価値はもたらされないことを意味します。たとえば、Administrator アカウントに、大文字と小文字、数字、およびキーボード全体から選択した記号で構成される 15 文字のパスワードを設定したとします。このパスワードをネットワーク経由で推測するには、約 591,310,404,907 年かかります。ちなみに、これは宇宙が存在する年数の約 43 倍の年数です。

ここで、Administrator アカウント名を変更することによって、推測にかかる時間を 1,000 倍にしてみましょう。これによって、パスワードの推測にかかる時間は 591,310,404,906,787 年 (宇宙が存在する年数の 43,161 倍) になります。さて、セキュリティは強化されたと言えるでしょうか。3 桁分ですが、もちろん強化されています。攻撃者がパスワードを推測できる可能性を、いくらかでも低下させることはできたでしょうか。いずれにせよ、その効果は非常にわずかです。つまり、実質的には、元の Administrator アカウント名を使用した場合とそれほど差はありません。アカウント名を変更すると、そのアカウント名の使用を試みるマルウェアを撃退できるからといって、アカウント名を変更しなければそのマルウェアを撃退できないと解釈するのは誤りです。実際は、強力なパスワードを使用 (することをお勧めします) すれば、アカウント名にかかわらず、マルウェアを必ず撃退できると言ってもよいでしょう。

多くのセキュリティ ガイダンスでは、Administrator アカウント名の変更を要件として挙げていますが、これは価値の高いセキュリティ対策とは言えず、さらには妥当な対策とも言えません。このような情報によって、この対策を実装するかどうかについて、リスクを考慮した適切な判断を下すことができなくなります。セキュリティ ガイドでは、まったく効果のない設定や、存在すらしない設定を要件として挙げていることが非常によくあります。最終的に、セキュリティを強化するには、これらの要件を 1 つずつ確認し、実際に問題を分析して、要件として挙げられた緩和策が理にかなっているかどうかを評価する必要があります。ここで 1 つ重要なことを思い出してください。それは、攻撃者がある機能を標的にしていても、それだけでは、その機能に変更を加える十分な理由にはならないことです。機能を変更する必要があるのは、変更を加えなかった場合にその機能が攻撃を受けることが十分に予想される場合のみです。

強力なパスワードを設定すれば、アカウント名が変更されたかどうかにかかわらず、攻撃の成功率は事実上ゼロになります。このため、強力なパスワードを設定している限り、セキュリティ上の理由でアカウント名の変更が必要になることはありません。さらに、私と同じように、コンピュータに加える変更が少ないほど、そのコンピュータの安定性は高くなるという原則 (ちなみに、これは一般に定着している事実です) に従って活動している場合、その原則は、当然 Administrator アカウントを変更しない理由としても適用できます。

価値の低い緩和策に焦点を移す 隠すことによるセキュリティを利用した、価値の低い緩和策に移行することの問題点は、組織の焦点を価値の高い緩和策から移さなくてはならないことです。たとえば、Administrator アカウント名を変更する時間と手間を、他の対策に費やすことはできません。その他の対策によって、Administrator アカウント名の変更よりも高い価値がもたらされる場合、組織はその価値を得る機会を逃すことになります。実際のコストには影響しないように思えるかもしれませんが、50,000 個の Administrator アカウント名を変更することを想像すれば、この意味をおわかりいただけるのではないでしょうか。

なお悪いことに、価値の低い緩和策に移行すると、組織の経営陣が手を休めてしまう可能性が非常に高くなります。経営陣は、隠すことによるセキュリティ緩和策によって提供される最低限の価値を必ずしも理解していない場合があり、追加の作業を行わない可能性があります。これは、組織にとって非常に大きなリスクになります。このリスクは、経営陣が、単純に時間と手間をかけて、実装している緩和策の価値を理解すれば、高い確率で回避できます。

管理にかかるコストの大きさ 最後の考慮事項ですが、緩和策がどれくらい適切に実装されるかによって、管理コストは非常に大きくなる可能性があります。グループ ポリシー オブジェクト (GPO) を使用して Administrator アカウント名を変更した場合、コストは非常に小さくなります。この方法によって全員が新しい名前を知ることができるので、展開コストはほぼゼロです。ただし、先ほど述べたように、アカウントを持つユーザー全員がその名前を知ることになるので、最小限の価値しか提供されません。したがって、この緩和策から最大限の価値を得るには、ホストごとに異なる名前を使用する必要があるので、システムの管理コストは非常に大きくなります。

passgen (protectyourwindowsnetwork.com/tools.htm) などのツールを使用して、ネットワーク上のすべての Administrator アカウントに 100 文字の完全にランダムなパスワードを設定し、毎日の管理作業に異なるアカウントを使用した方が、管理コストははるかに小さくなります。純粋に Administrator アカウントを障害回復のみに使用する (Windows Small Business Server 2003 を使用する場合は除きます) と考えれば、ネットワーク管理システムへの影響はまったく発生しません。さらに、攻撃者がいずれかの Administrator アカウントのパスワードを正確に推測することは、太平洋の底に沈む 1 本の針を見つけることよりも困難になります。また、強力な一意のパスワードに重点を置くことによって、スクリプト キディは好きなだけパスワードの推測を続けることができます。

結局はリスク管理が重要

事実上、隠すことによるセキュリティ対策はすべて、今回紹介した方法で分析できます。どの対策にも利点と欠点があり、適切な対策は組織によって異なります。結局、このことがリスク管理上の問題になります。つまり、解決策の実装にコストをかけて、そのリスクを緩和する価値があるかどうかを判断する必要があります。情報資産の保護に関するすべての決定は、十分な情報に基づき、リスクを考慮して行う必要があり、白か黒を選択すれば済むことはほとんどありません。

確かに、いくつかの決定は既に下されています。たとえば、クレジット カードの情報を暗号化しないこと、またはクレジット カードの検証コードを保管しないことのいずれかを選択する場合、どちらを選択した場合でも、可能な支払い形式にクレジット カードが含まれなくなる可能性があります。この決定がビジネスに及ぼす可能性のある悪影響は、選択の幅が狭くなることです。つまり、これは間違いなくリスクを考慮した決定ですが、その決定を下すのは非常に簡単です。

同様に、物理的な店舗の店内ネットワークのバックエンドを制限のないワイヤレス ネットワークに接続する人はいないと思いますが、この接続に関する決定は、リスクを考慮した決定ではありません。リスクを考慮した決定と言えるのは、ある人がその行為を行うことを選択し、ある人が実際にその行為を行った場合、ある人がその結果 (残念ながら実際に起こることはないと思われますが) による不利益を被る場合です。

ここで重要なのは、対処する必要がある問題、その問題への対策、および各対策の利点と欠点を明確に示すことです。これにより、十分な情報に基づいてリスクを考慮した決定を下すために必要な情報が得られます。この情報がなければ、勘に頼って決定を下すことになるので、良い決定になることはほとんどありません。

Jesper M. Johansson は、セキュリティ ソフトウェアの開発に取り組むソフトウェア アーキテクトで、TechNet Magazine の編集にも携わっています。管理情報システムの博士号を持ち、セキュリティ分野で 20 年以上の経験があります。また、エンタープライズ セキュリティの Microsoft MVP でもあります。最新の著書には、『Windows Server 2008 Security Resource Kit』があります。

Roger Grimes (セキュリティの CPA、CISSP、MCSE) は、Microsoft ACE チームのシニア セキュリティ コンサルタントで、これまでに、コンピュータ セキュリティに関する 8 冊の書籍、および 200 を超える雑誌記事を執筆しています。セキュリティ カンファレンスで頻繁に講演を行っており、InfoWorld のセキュリティ コラムニストでもあります。

© 2008 Microsoft Corporation and CMP Media, LLC.All rights reserved; 許可なしに一部または全体を複製することは禁止されています.