第 3 章 - スマート カードを使用した管理者アカウントのセキュリティ保護
最終更新日: 2007年10月22日
ダウンロード
「スマート カードを使用した安全なアクセス計画ガイド」の入手
Microsoft® Windows Server™ 2003 を使用すると、組織はひと揃いある特定のアカウント セキュリティ機能を利用して管理アカウントをセキュリティ保護できます。 Windows Server 2003 なら、管理者がスマート カードでログオンするという要件以外にも、次に挙げる 2 次的な作業のスマート カード認証もサポートされます。
net use コマンドを使用してマッピングされたドライブを作成する。
コマンド プロンプトで runas と入力して、Secondary Logon サービスを使用する。
Active Directory インストール ウィザード (コマンド プロンプトで dcpromo と入力するとアクセスできます) を使用して、Active Directory® ディレクトリ サービスをインストールする。
Windows Server 2003 リモート デスクトップ セッションによりログオンする。
Windows Server 2003 ターミナル サーバー セッションによりログオンする。
注 : Microsoft Windows® 2000 では、認証用のスマート カード アクセスはサポートされますが上記の追加機能はサポートされません。これらは Windows Server 2003 でしか利用できません。
トピック
スマート カードを使用して管理者アカウントをセキュリティ保護するためのアプローチ 問題点と要件 ソリューションの設計
スマート カードを使用して管理者アカウントをセキュリティ保護するためのアプローチ
Windows Server 2003 では 2 次的な作業のスマート カード認証がサポートされているため、ユーザー アカウントと管理者アカウントを最適に分離することができます。 日常的な作業を行う場合、管理者は非管理者アカウントでワークステーションにログオンできます。 管理タスクを行わなければならない場合は、管理者はスマート カードを使用して、2 次的作業としてその操作を認証できます。 管理者がユーザー名とパスワードを入力する必要がある場合よりも、または一度ログオフして管理者アカウントで再ログオンする必要がある場合よりも、こちらの方が安全で便利な方法です。
管理者アカウントおよびグループの特定
管理者用のスマート カードを実装するには、2 要素の認証を必要とする管理者アカウントを組織が特定する必要があります。 この手順を正確に実行するには、Windows XP および Windows Server 2003 内のさまざまな管理者アカウントおよびグループの特性を理解する必要があります。
グループを利用すると、管理者は複数のユーザー アカウントを同時に管理できるようになります。 Microsoft Windows NT® 以降のオペレーティング システムには、ビルトイン管理者権限が付いたセキュリティ グループが含まれています。
これらのセキュリティ グループは、ローカル グループ (ワークステーションやメンバ サーバーなど、ドメインに参加しているコンピュータ上) または既定のグループ (ドメイン コントローラ上) にすることができます。 管理者アカウントは、これらの 1 つまたは複数のセキュリティ グループのメンバシップを介して権限を受け取ります。
ローカル グループ
ドメインに参加しているコンピュータ上のローカル グループには、さまざまなレベルの管理者権限があります。次のような組織があります。
Administrators。 このグループのメンバは、ローカル コンピュータを完全に制御できます。 管理者ユーザー アカウントは、既定ではこのグループのメンバです。 コンピュータがドメインのメンバである場合、そのドメインの Domain Admins グループもこのグループのメンバになります。
Backup Operators (すべてのコンピュータタイプ)。 このグループのメンバは、NTFS ファイル システムのアクセス許可をバイパスして、ファイルとフォルダのバックアップを作成することができます。 Backup Operators も、メンバ サーバーをシャットダウンできます。
Power Users。 このグループのメンバは、ローカルのワークステーションまたはメンバ サーバー上のリソースに対する管理者権限を制限されています。 また、メンバ サーバーをシャットダウンすることもできます。
Print Operators。 このグループのメンバは、プリント サーバー、プリンタ、および印刷ジョブを管理できます。 また、メンバ サーバーをシャットダウンすることもできます。
Windows Server 2003 の既定のグループの詳細については、マイクロソフトの Web サイトの「既定のローカル グループ」トピックを参照してください。
組織のセキュリティ ポリシーで、Administrators、Server Operators、および Power Users グループの中の、ログオンと管理を行う場合にスマート カードの使用を必須とするメンバを定義する必要があります。
既定のグループ
各ドメインには、ドメイン コントローラ上で管理機能を提供する既定のグループが多数存在します。 これらのグループには、次のようなものがあります。
Administrators。 このグループのメンバは、ドメイン コントローラ全体で管理操作を完全に制御できます。 管理者アカウントおよび Domain Admins グループは、既定でこのグループのメンバです。
Backup Operators。 このグループのメンバは、NTFS ファイル システムのアクセス許可をバイパスして、ファイルとフォルダのバックアップを作成することができます。 ドメイン コントローラにローカルでログオンしてシャットダウンすることもできます。
Server Operators。 このグループは、ワークステーション上の Power Users グループと同様に、ドメイン コントローラ上での管理者権限が制限されています。 ドメイン コントローラにローカルでログオンしてシャットダウンすることができます。
Print Operators。 このグループのメンバは、プリント サーバー、プリンタ、および印刷ジョブを管理します。 ドメイン コントローラにローカルでログオンしてシャットダウンすることもできます。
Account Operators。** **このグループのメンバは、ユーザー アカウントとグループを管理する権限を制限されています。 対話型でログオンできますが、ドメイン コントローラをシャットダウンすることはできません。
既定のグループの詳細については、マイクロソフトの Web サイトの「既定のグループ」トピックを参照してください。
組織のポリシーで、これらのグループのすべてのメンバに対して、管理を行う場合にスマート カードの使用が必要になるように規定してください。
ドメインおよびフォレストの既定のグループ
既定のグループ以外にも、Active Directory フォレストを作成すると次のセキュリティ グループが設定されます。
Domain Admins。 このグループのメンバは、ドメイン内のすべてのオブジェクトを完全に制御できます。 フォレスト内の後続のドメインにもそれぞれ Domain Admins グループが含まれています。
Enterprise Admins (フォレストのルートドメインのみ)。** **このグループのメンバは、フォレスト内のすべてのオブジェクトを完全に制御できます。
Schema Admins (フォレストのルートドメインのみ)。 このグループのメンバは、スキーマのクラスと属性を作成でき、スキーマの Operations Master を管理できます。
注 : セキュリティを強化するには、上記の 3 つのグループのメンバシップを最小に保ちます。
これらのグループのすべてのメンバに対して、管理を行う場合にスマート カードの使用が必要になるようにしてください。
対話型ログオンでスマート カードを必要にする
対話型ログオンでスマート カードが必要になるようにするには、2 通りの方法があります。 次のいずれかを構成します。
[Active Directory ユーザーとコンピュータ] のユーザー アカウントのプロパティ。
特定のコンピュータまたは特定のコンピュータのグループのグループ ポリシー。
ほとんどの環境では、グループ ポリシーを使うのが最も管理しやすいアプローチです。
ユーザー アカウントのプロパティ
対話型ログオンでスマート カードを必要にするために、ユーザー アカウントを構成することができます。 それには、[Active Directory ユーザーとコンピュータ] でユーザーをダブルクリックし、[アカウント] タブをクリックして、[アカウントオプション] の下の [対話型ログオンにはスマートカードが必要] チェック ボックスをオンにします。 このオプションを選択すると、ユーザーのパスワードがランダムな複合値に変わり、[パスワードを無期限にする] プロパティが設定されます。 その後スマート カード要件をオフにする場合は、ユーザーのパスワードもリセットする必要があります。
スマート カード要件を設定するとユーザーのパスワードが不明な値にリセットされるため、ユーザーはドメインにログオンする際にユーザー名とパスワードの組み合わせを使用できなくなります。 したがって、ユーザーはユーザー名とパスワードでは Microsoft Exchange Server 2003 の Microsoft Outlook® Web Access などのプログラムにログオンできません。
登録中の場合には、スクリプトを使ってこの設定を有効にできます。 ただし、この方法を用いるには、選択した個人のスマート カード要件を有効および無効にする適切なスクリプトを開発する必要があります。
ユーザー アカウントのスマート カード要件が選択されると、管理者は保護されたサーバーだけでなく、ドメイン内のどのコンピュータにもスマート カードを使用して対話的にログオンする必要があります。 すべてのコンピュータにスマート カード リーダーが備わっていない場合は、これでは不便になる可能性があります。
ユーザー アカウントのプロパティでスマート カードの使用を強制している場合、管理者は Windows 2000 Server を実行しているコンピュータをリモートで管理できません。 Windows 2000 Server のターミナル サービス セッションではスマート カードのリダイレクションはサポートされていません。したがって、管理者はローカルでログオンして Windows 2000 を実行しているコンピュータを管理する必要があります。管理者がサーバーとは別の場所にいる場合、この要件は非常に不便なものになります。
グループ ポリシー
特定のコンピュータで対話型ログオンを行う場合にスマート カードが必要になるようにし、ユーザーがスマート カードを取り出したときの動作を制御するには、グループ ポリシー設定を使用するとより簡単に管理できます。 このような設定で構成されたグループ ポリシー オブジェクト (GPO) を作成して、スマート カードでのログオンを必須とするコンピュータが属している組織単位 (OU) にこの GPO をリンクさせます。 グループ ポリシー内のスマート カード オプションへのパスは、「コンピュータの構成\Windows の設定\セキュリティの設定\ローカル ポリシー\セキュリティ オプション」です。設定は、[対話型ログオン: スマートカードが必要] および [対話型ログオン: スマートカード取り出し時の動作] です。
注 : この設定を使用するには、Windows XP Service Pack 2 またはこの設定用の更新プログラムが必要です。 詳細については、マイクロソフト サポート技術情報「Windows XP のセキュリティ設定 "対話型ログオン: スマート カードを必要とする" に関する更新。」を参照してください。
セキュリティを最大にするには、対話型ログオンでスマート カードが必要になるようにし、スマート カードを取り出したときのポリシーを、ワークステーションがロックされるかユーザーがログオフされるように設定します。 これらのグループ ポリシー設定は、管理者に適用されるカスタマイズされた GPO の一部にする必要があります。 GPO は、サイト、ドメイン、または OU レベルに適用できます。 ほとんどの場合、スマート カード設定を適用する GPO は OU に適用されます。
注 : マイクロソフトでは、スマート カード設定またはその他のポリシーの変更を含める目的で、既定のドメイン コントローラ ポリシーまたは既定のドメイン ポリシーは変更しないことをお勧めしています。 必ず新しい GPO を作成するか、またはスマート カード ログオンのグループ ポリシー設定を設定するために存在する GPO を使用してください。
スマート カード用のグループ ポリシー設定は対話型ログオンを制御するものです。ネットワーク上のサーバーへのアクセスには影響しません。 対話型ログオンには、リモート デスクトップまたはターミナル サービスによるログオンが含まれます。
マイクロソフトでは、管理者用のスマート カードを IPsec やグループ ポリシーなど他の制御メカニズムと組み合わせて実装し、Microsoft 管理コンソール (MMC) ツールなどのリモート管理ツールと組み合わせてサーバー管理を行うのはやめることをお勧めしています。
複数のドメインおよびフォレストでのスマート カード アクセスの管理
管理者用のスマート カードを実装するには、複数のドメインおよびフォレストに関連する問題を理解する必要があります。 たとえば、1 つ以上のフォレストの Domain Admins グループのメンバである管理者は、管理者権限を持つフォレストごとに 1 枚ずつスマート カードが必要になる可能性があります。 したがって、このような管理者は複数のスマート カードを携帯しなければならない必要が出てきます。
スマート カードに 1 つ以上の証明書を含めることはできますが、Windows Server 2003 では現在、各証明機関 (CA) の証明書ルートごとに 1 つのスマート カード ログオン証明書 (スマート カードのスロット 0 にある証明書) しか受け入れることができません。 この制約があるため、一部のネットワーク管理者は、組織がフォレスト間の関係を信頼するかどうかに関わらず、複数のスマート カードを持つ必要があります。
サーバーのセキュリティ保護
ファイルおよびプリント、データベース、電子メール、ディレクトリなどのサービスを実行するコンピュータには、ワークステーションよりも高いレベルのセキュリティが必要です。 特に、次のような役割を担うコンピュータを管理するすべてのアカウントに対して、スマート カード認証を使用することを検討してください。
ドメイン コントローラ
データベース サーバー
証明書サーバー
ファイル サーバーとプリント サーバー
ドメイン コントローラのセキュリティ保護
ドメイン コントローラは、2 要素の認証の使用対象として最も重要なコンピュータです。なぜなら、このコンピュータにはすべてのドメイン アカウント情報が含まれており、それらの情報を制御し、各アカウントにセキュリティ ルールを適用する役割を担っているからです。 ドメイン コントローラが攻撃者によって侵害された場合、攻撃者は次に新しいアカウントを作成することも、権限をエスカレートすることも、管理者としてすべてのドメイン コントローラにアクセスすることもできるようになります。
データベース サーバーのセキュリティ保護
データベース サーバーには組織の運営に重要な情報が格納されます。 この格納された情報は、データ アクセス要求の追跡監査による厳格なチェックインおよびチェックアウトの対象となる可能性があります。 データベース サーバーの例としては、ソフトウェア企業のソース コード、飲料メーカーの秘密のレシピ、または顧客の口座情報が格納されるサーバーなどがあります。 スマート カード認証により、すべてのデータベース サーバーへのアクセスをセキュリティ保護する必要があります。
組織は、高セキュリティのサーバーを特定し、そのサーバーの担当者と打ち合わせてサービスまたは予定されたタスクを実行するアカウントのタイプを変更するか、アクセス制限とユーザー制限がより強力な特別なセキュリティ グループにアカウントとサーバーを置く必要があります。
証明書サーバーのセキュリティ保護
証明機関および証明書サービスをホストするサーバーには、高レベルのセキュリティが備わっている必要があります。 証明機関が侵害されると、組織の整合性が損なわれ、発行された証明書がすべて安全ではなくなります。 証明書サービスをホストしているサーバーは、ネットワークおよび物理アクセスの両方に対して最優先度のセキュリティを用意する必要があります。
ファイル サーバーとプリント サーバー
ファイル サーバーには、重要な企業文書および機密情報をホストできます。 この情報が侵害されると、将来の収益が損なわれるか、規制機関からの処罰の対象になる場合があります。 スマート カード認証により、請求書や銀行小切手を印刷するプリント サーバーを確実にセキュリティ保護する必要があります。
Windows Server 2003 のセキュリティ機能の詳細については、マイクロソフトの Web サイトの「Windows Server 2003 セキュリティ ガイド」を参照してください。
スマート カード リーダーをサーバーに取り付ける
グループ ポリシーで対話型ログオン時のスマート カードの使用を必要にするには、そのポリシーを適用するすべてのサーバーにスマート カード リーダーを取り付ける必要があります。 ほとんどのラックマウント型コンピュータには背面に USB ポートがあり、スマート カード リーダーの取り付けに適しています。 取り付けたスマート カード リーダーはラックの前面に設置すれば、ユーザーがアクセスしやすくなります。 スマート カード リーダーにはきちんとラベルを付けて、どのリーダーがどのサーバーに属しているか管理者がわかるようにしておくことが重要です。
別のサーバーにログオンしなければならない場合には、管理者は最初のリーダーからスマート カードを取り出して、別のコンピュータに取り付けられたリーダーに挿入する必要があります。 このような不便さのせいで、リモート デスクトップ機能を備えたサーバーを管理する方がはるかに魅力的に感じられます。
スマート カードの配布
管理者用スマート カードの配布プロセスを計画する場合、次の作業を行ないます。
スマート カードの配布対象とする適切なグループを作成する。
登録エージェントの役割を果たすセキュリティ管理者を任命する。
カードを搬送する適切な方法を選択する。
厳格な ID チェックを実行する。
選択した管理者アカウントを含むステージング セキュリティ グループを作成する必要があります。 また、セキュリティ グループには有効化されたアカウントを含める必要があります。 登録プロセスには、管理者アカウントをステージング グループから有効化グループに移す作業も含まれます。
配布プロセスでは、セキュリティ管理者の任命が必須です。 その後、セキュリティ管理者は次の作業を実行します。
スマート カードを登録ステーションに渡す。
登録エージェントとしての役割を果たす。
ID チェックを実行する。
この ID チェックは厳格に行われる必要があります。 セキュリティ管理者が、パスポートや運転免許証などの適切な身分証明書によって管理者を個別に確認し、ライン マネージャが、管理者が本人であることを確認します。
また、組織は管理者の背景もチェックする必要があります。このチェックは、財務部門、または規制要件の対象となる組織では特に重要です。管理者の背景セキュリティ チェックの詳細については、マイクロソフトの Web サイトの「セキュリティの監視および攻撃検出計画ガイド」を参照してください。
スマート カードを有効にする
スマート カードは、施設の通行を許可するパスを発行しているオフィスなど、安全な場所で発行する必要があります。 セキュリティ管理者は、2 台のスマート カード リーダーを取り付けた登録ステーションをセットアップして、自分のスマート カードでログオンします。
管理者の ID の確認を完了したら、セキュリティ管理者は管理者のユーザー アカウント用の証明書要求を作成します。 新しいスマート カードを開いて、要求された証明書をインストールします。 次に、管理者アカウントを待機グループから有効化グループに移します。 最後に、カードのシリアル番号を書き留めてから、カードを管理者に手渡します。
その次には、管理者が PIN リセット ツールを使用して既定の PIN をリセットするか、PIN アンブロック ツールとアクティベーション Web サーバーを併用して新しい PIN を設定します。 これで管理者のスマート カードを使用できるようになります。
スマート カードを管理する
スマート カードの実装は 1 回限りで済む業務ではありません。スマート カードに埋め込まれたセキュリティ証明書は管理する必要があり、また、管理者がスマート カードを忘れたとか、なくしたとか、盗まれた場合には対処する必要もあります。 スマート カードの管理業務に適用できる手続きと適切な予算を確立しておく必要があります。
例外管理
組織は、管理者がスマート カードを忘れるか、紛失するか、盗まれた場合の対処方法について計画を立てておく必要があります。どのような計画を採用するかは、組織が施行しているスマート カード ログオン要件によって異なります。
組織が Active Directory のユーザー アカウントを使用してスマート カード ログオン要件を設定している場合は、そのような状況でもユーザーの例外を簡単に認可することができます。例外を認可するためには、アカウントからスマート カード ログオン要件を削除し、[ユーザーは次回ログオン時にパスワードの変更が必要] の設定が有効になっていることを確認してから、パスワードをリセットします。次に、アカウントの所有者にパスワードを供与し、妥当な期間が経過した後に、ログオン要件を再度有効にします。この方法を適用するには、[Active Directory ユーザーとコンピュータ] でユーザー名をダブルクリックして、[アカウント] タブの [アカウント オプション] の下で、[対話型ログオンにはスマート カードが必要] チェック ボックスをオフに、[ユーザーは次回のログオン時にパスワード変更が必要] チェック ボックスをオンにします。[OK] をクリックし、ショートカット メニューでユーザー名を右クリックし、[パスワードを変更する] を選択してパスワードを設定し、これらの要件を管理者に適用します。
組織がグループ ポリシーを使用してスマート カード ログオン要件を設定している場合、この時点ではユーザーを例外として認可する方法はありません。そのため、管理者がスマート カードを忘れるか紛失した場合に従うことができる、組織に適したポリシーを決めておく必要があります。
カードを忘れた場合は、さまざまな対処方法が考えられます。たとえば、スマート カードを忘れてきた管理者は自宅に取りに戻らなければならないというポリシーを決めることもできます。
組織がスマート カード インフラストラクチャをアウトソースしている場合は、社内の特定のユーザー アカウントに関連付けられた証明書が格納された数枚の汎用スマート カードを用意しておくことを、管理者に義務付けるポリシーを施行することもできます。ユーザーがスマート カードを紛失したら、管理者は一時的にこうした汎用スマート カードの 1 枚をユーザーに供与します。そしてその際には、汎用アカウントでリソースにアクセスするために行われる行為はすべてユーザーの責任になることを理解してもらいます。このようなポリシーでは、汎用スマート カードを管理する管理者は、カードをユーザーに供与する前に毎回スマート カードのパスワード PIN 番号をリセットすることをお勧めします。
組織自体でスマート カード インフラストラクチャを管理している場合は、短い有効期間の証明書を新たに汎用ユーザー アカウントに発行することができます。この方法で例外管理を行う場合、管理者は先の場合と同様に、汎用アカウントを使用してリソースにアクセスする行為に対し責任を負うことになります。
最後に、管理者がスマート カードを紛失した場合、管理者に新しいスマート カードを発行するとともに管理者の以前の証明書を失効させるポリシーを策定することをお勧めします。
証明書の失効
秘密キーが侵害された場合、スマート カードのユーザーが割り当てを変更した場合、またはユーザーが会社を退職した場合など、さまざまな状況で証明書を失効させなければならない場合があります。 証明書を失効させると、失効処理により証明書に関する詳細が証明書失効リスト (CRL) の場所に公開されます。 この場所は、通常は URL またはネットワークの UNC パスです。
発行された証明書には、認証サーバーが CRL と照らし合わせて証明書のステータスを確認できる配布ポイントの一覧が含まれています。 証明書の失効の詳細については、マイクロソフトの Web サイトの「証明書を無効にし、CRL を公開する」トピックを参照してください。
証明書の更新
スマート カード上のデジタル証明書の失効日は、スマート カード証明書を作成する証明書テンプレートの設定に左右されます。 スマート カードの証明書の有効期間は、通常半年から 2 年です。
証明書が有効期間の終わりに近づくと、更新を行って、所有者がその証明書を継続して使用するかまたは交換できるようにする必要があります。 証明書を更新する場合、更新請求者は既に証明書を所有している必要があります。 更新処理では、更新要求が提出されると現在の証明書の情報が取り込まれます。 この後、新しいキーで証明書を更新するか、現在のキーを使用します。
証明書の自動登録
証明書の自動登録は、Windows Server 2003, Enterprise Edition の証明書サービスの機能です。既存の証明書を使用して更新要求に自動的に署名を行い、新しい証明書を取得します。 この機能は、きわめて多数の証明書を管理する場合に便利です。 証明書の自動登録の詳細については、マイクロソフトの Web サイトの「Certificate Autoenrollment in Windows Server 2003」 を参照してください。
スマート カードの使用状況を監視する
管理者は、サーバーの再起動、ユーザー アカウントの管理、ファイル許可の構成など、高度な権限が与えられた処理を実行する場合、スマート カード対応のアカウントを使用します。 悪意のある管理者またはトレーニングをあまり受けていない管理者の場合、ネットワーク インフラストラクチャに損害を与える可能性が大いにあります。 そのため、セキュリティ ログを監視して、管理者がスマート カードでログオンおよびログオフする日時を記録する必要があります。
セキュリティ イベント ログの監視と評価を実行できる Microsoft Operations Manager (MOM) 2005 などのエンタープライズ管理ツールを、スマート カードの使用状況を監視する作業に利用できます。 セキュリティ イベント ログの監視方法の詳細については、マイクロソフトの Web サイトの「セキュリティの監視および攻撃検出計画ガイド」 を参照してください。
問題点と要件
このセクションでは、スマート カードで管理者アカウントをセキュリティ保護するソリューションの設計中に Woodgrove National Bank が遭遇した問題点と要件について説明します。
背景
Woodgrove National Bank は、厳密な管理制御と安全なアクセスを必要とする重要なサーバーを多数所有しています。 管理者は現在、ユーザー名とパスワードでこれらの重要なサーバーへのアクセスを認証しています。 権限のないユーザーが盗み出した資格情報で重要なサーバーにアクセスしようとしたこともありました。
ビジネス上の問題
Woodgrove National Bank は、ビジネスの継続性および管理者責任の問題として、次の 3 つの問題を特定しました。
責任。 管理者が資格情報を共有することがよくあるため、IT 部門では、ユーザー名とパスワードを認証に使用している管理者がサーバーに重大な変更を加えたかどうか確認できません。
資格情報の保護。 管理者の資格情報を盗み出した悪意のあるユーザーが、企業の評判に深刻な影響を与えたり、ダウンタイムを引き起こして財務上のコストを発生させる可能性があります。 スマート カード認証にすれば、管理者の資格情報が盗まれる可能性は大幅に小さくなります。
ビジネスの継続性。 Woodgrove National Bank は、ネットワーク構成を変更してビジネス サービスを中断させることはできないため、スマート カード ソリューションの実装段階では慎重に計画されたアプローチが不可欠になります。
技術的な問題
Woodgrove National Bank の IT 部門は、スマート カード ソリューションを実装するために克服する必要がある技術的な問題として、次のような問題を特定しました。
スマートカードリーダーのサポート。 管理者がスマート カードでアクセスする必要のあるすべてのサーバーで、スマート カード リーダーをハードウェア上サポートできる必要があります。
最善の運用方法を実装する。 スマート カードの完全性は、長期の管理とメンテナンスを効率的に実行できるかどうかに左右されます。 Woodgrove National Bank の IT 部門は、Microsoft Operations Framework (MOF) で紹介されている最善の運用方法を実装する必要があります。
スマートカードで制限されたサーバー上で管理者権限により実行される予定されたタスク。** **Woodgrove National Bank は、管理者レベル権限でアカウントを使用する予定されたタスクを実行しています。 Woodgrove National Bank は、このようなアカウントを見直し、可能であれば管理者権限を必要としないアカウントを使用する必要があります。 また、Woodgrove National Bank は恒久的な例外グループを実装して、そのグループに予定されたタスクを実行するアカウントを含め、これらのアカウントがスマート カード ログオンの要件から除外されるようにする必要があります。
UNIX との統合。 Woodgrove National Bank は異機種環境で運用が行われているため、UNIX を実行するコンピュータにスマート カードを統合することが懸案事項です。 Woodgrove National Bank は、Windows と UNIX の両方に使用できる統合スマート カード認証を提供している CyberSafe Limited の TrustBroker など、各種製品の調査を計画しています。
セキュリティ問題
スマート カードを使用して管理者アカウントをセキュリティ保護する目的は、セキュリティと信頼性の向上にあります。Woodgrove National Bank の IT 部門は、このソリューションを展開する前に解決しなければならない次のようなセキュリティ上の問題を特定しました。
配布と有効化。** **スマートカードの配布と有効化は、ソリューション全体の整合性を維持するために重要です。 Woodgrove National Bank には世界中に営業所があるため、 Woodgrove の IT 部門は 1 つの送付元だけからスマート カードを配布することはできません。 スマート カードの受領者の確認が、プロジェクトの整合性を維持するために重要な要因となります。 Woodgrove National Bank は、人事 ID データを使用してスマート カードが必ず正しい相手に発行されるようにするセキュリティ チームの立ち上げを計画しています。
最小の権限で管理者権限にアプローチ。 Woodgrove National Bank は、現在のネットワーク管理モデルを見直し、完全な管理者権限を持つユーザー アカウントとサービス アカウントの数を減らす必要があります。 管理者が自分の職務を実行するために必要な権限だけが割り当てられる必要があります。 管理者アカウント数を分析して削減すれば、スマート カード ソリューションの展開、監視、および継続的な管理に役立ちます。
サービスアカウントの管理。** **Woodgrove の IT 部門は、プログラム サービス アカウントを見直し、セキュリティ上管理者を必要とするサービスをできる限り減らしました。 多くのプログラムに、アップグレードまたは交換のマークが付けられています。
完全な信頼関係にある各フォレストに 1 枚ずつのスマートカード。 Woodgrove National Bank には、双方向の信頼関係でリンクされた 2 つのフォレストがあります。 スマート カードには複数の証明書を持たせることができますが、Windows Server 2003 では、対話型ログオン用スマート カードのスロット 0 にある証明書しか使用しません。 この設計では、リンクされていない複数のフォレストにまたがって作業するネットワーク管理者は複数のスマート カードを持つ必要があります。 ただし、スマート カードを持つ管理者は、信頼するフォレストのセキュリティ制限によってアクセス権が無効にならない限り、管理者を認証するフォレストと完全な信頼関係にあるすべてのフォレスト内のリソースにアクセスできます。
PIN 管理。 ユーザーが簡単に PIN を変更できれば、スマート カード ソリューションのセキュリティと整合性が向上します。 そのため、Woodgrove National Bank の IT 部門は、選択したスマート カード ベンダから適切な PIN 管理ツールを入手しました。
ソリューション要件
初期パイロットを見直した上で、Woodgrove の IT 部門は具体的なソリューション要件を策定しました。 Woodgrove National Bank が展開する、スマート カードがある管理者アカウントをセキュリティ保護するためのこのソリューションでは、次のことを行える必要があります。
セキュリティ保護されたサーバーに対話型ログオン、2 次的ログオン、またはリモート デスクトップ ログオンするには、有効なスマート カードの使用が必要になるようにする。
安全かつタイムリーな方法でスマート カードを配布して有効化する。
セキュリティ保護されたサーバーへのアクセスを監査し、結果のセキュリティ データを中央のリポジトリで収集する。
スマート カードの使用を管理および監視できるようにする。
スマート カードを紛失するか盗まれた場合、侵害された証明書は即座に失効させる。
継続的な管理を行うための構造を示す。
Woodgrove National Bank は、当初の計画で判明したいくつかの主要なビジネス上、技術上、およびセキュリティ上の問題を特定しました。 Woodgrove の IT 部門は、これらの問題を解決するためのレビューを実施し、対策と修正のテストを行いました。 Woodgrove National Bank は、ソリューションの展開段階用の詳細な計画を作成しました。
ソリューションの設計
スマート カード ソリューションが解決しなければならないビジネス上、技術上、およびセキュリティ上の問題を理解したら、ユーザーの環境に適したソリューションを設計することができます。 この設計プロセスでは、重要な要素を特定してソリューションを計画するための要件を論理的に分析します。
Woodgrove National Bank は、この評価を実行しました。 このセクションでは、Woodgrove National Bank のシステム設計者が検討した当初計画から判明した問題点、到達した結論、および設計に関する決断について説明します。
このセクションでは、Woodgrove National Bank の IT 部門がスマート カードを使用して管理者アカウントをセキュリティ保護するために行った設計上の選択の概要を示します。 ソリューションの概念と前提条件について詳細に説明し、Woodgrove National Bank が計画したアーキテクチャについて説明します。
ソリューションの概念
提案されたソリューションでは、すべてのサーバー管理者の活動で、スマート カードに格納された証明書とそれに対応する PIN を提示することで行われる管理者の ID の認証が必要になります。 このソリューションでは、グループ ポリシー設定、X.509 バージョン 3 (v3) ユーザー証明書、スマート カード、およびスマート カード リーダーを組み合わせて使用します。 このソリューションでは、スマート カードに X.509 v3 証明書をインストールする必要があります。
サーバーにログオンするには、管理者はコンピュータに取り付けられたスマート カード リーダーにスマート カードを挿入します。 カードを挿入すると、PIN の入力を求めるプロンプトが表示されます。 管理者はここでスマート カードの PIN を入力します。 PIN が正しければ、管理者は管理者権限でサーバーにアクセスできます。
ソリューションの必要条件
この種のプロジェクトに関わる場合、多数の前提条件を満たす必要があります。前提条件として、プロジェクト チームの編成、ユーザー ベースとの打ち合わせ、テストまたはパイロットの実装、ソリューションの要件を満たすためにハードウェアとソフトウェアをアップグレードする必要などがあります
管理チームとの打ち合わせ
ユーザー サービスを変更する場合にまず考慮すべきことは、関連するユーザーおよびグループと打ち合わせを行うことです。 一方、ユーザーはこのサービスから何を期待でき、何を期待できないかを理解しておく必要があります。 相互に協議してユーザーの期待を把握することが、ユーザー側の受け入れの鍵になることがよくあります。 プロジェクトを合理的な方法で最終的に成功させるには、測定できる目標を設定する必要があります。 このような目標には、盗まれた資格情報に関連するセキュリティ関連のインシデントの低減などが含まれることもあります。
Woodgrove National Bank は、複数の国/地域で操業しており、地域別にサポート センターがあります。 初期設計チームは、すべての地域の管理チームを広範囲に調査して、スマート カード ソリューションの候補サーバーを特定しました。 また、許容時間内にソリューションの前提条件を満たすためにアップグレードすることができないサーバーも特定しました。
プロジェクト チームの編成
この種のプロジェクトを実装できる適切な人員とスキルを用意できていることを確認します。 プロジェクト チームは、次の代表的な職務に就いている人間からの情報を必要とすることがよくあります。
プログラム マネージャ
情報システム設計者
システム アナリストまたはインテグレータ
システム エンジニア
製品リリース マネージャ
製品テスティング マネージャ
サポートまたはヘルプ デスク マネージャ
ユーザー サポートの専門家
セキュリティ管理者
代表的な職務と MOF の役割との関係については、マイクロソフトの Web サイトの「The Microsoft Solutions Framework Supplemental Whitepapers – IT Occupation Taxonomy」(英語) を参照してください。
社内に利用できるスキルを持つ人間がいない場合は、追加人員を採用する必要があります。 プロジェクトでは通常、すべての段階ですべての人員が必要になるわけではないので、プロジェクトの全期間を通じて個々の人員の利用状況を決める必要があります。
ソリューション アーキテクチャ
スマート カード ソリューションを実装して管理者アカウントをセキュリティ保護するには、次のものが必要です。
Active Directory
グループ ポリシー
Windows Server 2003, Enterprise Edition、公開キー基盤 (PKI)
Windows Server 2003 を実行しているサーバー (スマート カード リーダーを設置済み)
登録ステーション
スマート カードの個人情報
PIN 管理ツール
Woodgrove National Bank は、このソリューションを実装する前に次の手続きを実行しました。
[呼び出しの認証レベル] ドロップダウン リストから [呼び出し] を選択します。
すべての管理対象サーバーを Windows Server 2003 にアップグレードして、ターミナル サービスを使用する対話型ログオンをサポートできるようにした。 この要件はアプリケーションの互換性に左右されます。
スマート カード証明書のユーザー テンプレートをカスタマイズして、適切な許可を設定した。
スマート カードの強制的実施、一時的な除外、および恒久的な除外用のグループ ポリシー オブジェクト (GPO) を作成してテストした。
Woodgrove National Bank の IT 部門は、次の課題に対するソリューションも実装しました。
スマート カードの配布
スマート カードの有効化
スマート カードの管理とサポート
例外の管理
スマート カードの配布
Woodgrove National Bank の IT 部門は、スマート カードを配布する前に、管理者を Active Directory ステージング セキュリティ グループに置きました。 セキュリティ管理者のチームは、管理者の ID を確認してスマート カードを配布することを求められました。 管理者が自分のカードを受け取ると、IT 部門はその管理者をステージング グループからスマート カード ユーザー グループに移しました。 次に管理者は、アクティベーション Web サーバーにアクセスして、自分のスマート カードを有効にし、PIN を変更する必要があります。
スマート カードの有効化
管理者はスマート カードを保留状態で受け取ったため、使用する前にカードを有効化する必要があります。 スマート カードを有効化するには、管理者はカードをスマート カード リーダーに挿入し、チャレンジを入力して、PIN を変更します。
スマート カードの管理とサポート
Woodgrove National Bank の管理者は技術的な面で優れたグループですが、スマート カード展開チームはヘルプ デスクと密接に連携する必要がありました。 ヘルプ デスクの担当者は、どんな問い合わせにも対処できるように適切な指示を求めました。
例外管理
Woodgrove National Bank は、カードの紛失、盗難、または忘れた場合に対処するための企業ポリシーを作成しました。カードを紛失するか盗まれた場合、IT 部門は割り当てた証明書をすべて失効させ、24 時間以内に新しいカードを発行します。スマート カードを仕事場に持ってくるのを忘れた管理者に関しては、仮のスマート カードを発行します。証明書は失効しますが、これは同じ期間中スマート カードが無効になるということではありません。Woodgrove は、セキュリティ ポリシーに合致するように CRL ポリシーを見直す必要があります。
証明書の失効
Woodgrove National Bank の管理者用のスマート カード ログオン証明書は、イントラネットの URL を使用して CRL に移動し、失効した証明書をチェックします。 IT 部門は、CRL をホストする Web サイトの高可用性を確保するために、Windows ネットワーク負荷分散 (NLB) を実装しました。
証明書の更新
Woodgrove National Bank の IT 部門は証明書の更新プロセスを開発しました。このプロセスでは、管理者のマネージャがスマート カードの更新要求を承認する必要があります。 マネージャが要求を承認した後、現在の証明書により証明書要求への署名が行われてスマート カード証明書が更新されます。
ソリューションの監視
Woodgrove National Bank では、Microsoft Operations Manager (MOM) 2005 を使用してセキュリティ イベント ログを収集および分析し、ソリューションの可用性とパフォーマンスを監視します。 スマート カード ソリューションは MOM に統合され、セキュリティ イベント ログを監視して警告を発し、使用状況レポートを作成します。 Woodgrove National Bank は、四半期ごとにサービスを見直すため、MOM データからレポートを生成する計画を立てています。
ソリューションの動作
このセクションでは、スマート カード ログオンの認証中に発生する詳細なプロセスについて説明します。
管理者が、コンピュータに取り付けられたスマート カード リーダーにスマート カードを挿入し、Microsoft Graphical Identification and Authentication DLL (MSGINA) とコンピュータにより、ユーザーに PIN を入力するように求めるプロンプトが表示されます。
MSGINA は PIN をローカル セキュリティ機関 (LSA) に渡し、コンピュータはこの PIN を使ってスマート カードにアクセスします。
クライアント側の Kerberos パッケージが、X.509 v3 証明書と秘密キーを管理者のスマート カードから読み取ります。
Kerberos パッケージは、認証サービス要求をドメイン コントローラ上で動作するキー配布センター (KDC) サービスに送り、認証とチケット許可チケット (TGT) を要求します。 認証サービス要求は、ユーザーのセキュリティ識別子 (SID) を一覧表示する特権属性証明書 (PAC)、ユーザーがメンバであるグループの SID、および事前認証データと一緒になっているチケット保証サービス (TGS) の要求で構成されています。
KDC は、ユーザーの証明書の証明書パスを検証し、証明書が信頼されたソースからのものであることを保証します。 KDC は、CryptoAPI を使用して、管理者の証明書からドメイン コントローラ上のルート ストアにあるルート CA 証明書への証明書パスを構築します。 次に CryptoAPI を使用して、事前認証データ フィールド内に署名入りデータとして含まれている認証システム上のデジタル署名を検証します。 ドメイン コントローラは署名を検証し、管理者の証明書の公開キーを使用して、その要求が公開キーの所有者から出てきたものであることを確認します。 KDC はまた、発行者が信頼済みで、NTAUTH 証明書ストアに表示されていることも確認します。
KDC サービスは、管理者の証明書の [サブジェクトの別名] フィールドに指定されたユーザー プリンシパル名 (UPN) に基づいて、Active Directory からユーザー アカウント情報を取得します。 KDC は、Active Directory から取得したユーザー アカウント情報から TGT を構築します。 TGT には、管理者のセキュリティ識別子 (SID)、管理者が所属するドメイン グループの SID、および (マルチドメイン環境の場合)、ユーザーがメンバであるユニバーサル グループの SID が含まれます。 TGT の認証データ フィールドには SID の一覧が含まれています。
注 : SID は、Windows NT 以降のコンピュータ上のローカル セキュリティ アカウント データベース内または Active Directory 内でユーザー アカウントまたはグループ アカウントが作成されるときに、各ユーザーまたはグループ用に作成されるセキュリティ識別子です。 SID は、ユーザー アカウントまたはグループ アカウントの名前が変更されても変わることはありません。
ドメイン コントローラが TGT をクライアントに返します。 クライアントまたはカードが TGT の暗号を解読し、秘密キーを使って KDC の秘密キーを取得します。 この手順は、使用するカードまたは証明書によって異なります。
クライアントが KDC からの応答を確認します。 最初に、KDC の証明書から信頼済みのルート CA への証明書パスを構築して KDC の署名を確認し、次に KDC の公開キーを使って応答の署名を確認します。
次の図は、以上のプロセスを示したものです。
.gif)
図 3.1: スマートカードログオン認証のプロセス
画像を画面全体に表示 Woodgrove National Bank の IT 部門は、スマート カード認証を必要とするサーバーが含まれる組織単位に GPO をリンクしました。 この GPO は、次のコンピュータ構成設定に変更を適用します。
.gif){kind=link}
対話型ログオンでスマート カードの使用を必要にする
スマート カードを取り出すと、アカウントが強制的にログオフされる
このように設定しておくと、管理者がスマート カードを共有したり、ログオン中のサーバーが無人の状態で放置されることを防ぐことができます。
ソリューションの拡張
Woodgrove National Bank は、スマート カード ソリューションをサーバーおよびアプリケーションの変更管理プロセスに統合する計画を立てています。 この計画では、変更管理プロセスの各段階を認証して、プロセスをワークフローに統合します。 たとえば、Woodgrove Web サーバーに変更を加える場合、2 人以上の Web 管理者の検証が必要になります。
まとめ
スマート カードを使用して管理者ユーザー アカウントを認証すると、重要なコンピュータへの不正なアクセスが減り、サーバー管理の整合性と信頼性が向上します。 管理者用のスマート カードを実装すれば、セキュリティ インシデントが低減して管理手順の質が向上するため、組織には利益となります。
目次
- 概要
- 第 1 章 - はじめに
- 第 2 章 - スマート カード テクノロジ
- 第 3 章 - スマート カードを使用した管理者アカウントのセキュリティ保護
- 第 4 章 - スマート カードを使用したリモート アクセス アカウントのセキュリティ保護
- 付録 A - 関連リンク
- 謝辞