およびとは？
|
ホーム ＞ ビジネスに役立つ情報 ＞ 企業経営に関するトピック解説 ＞ 日本版LLCおよびLLPの概要と活用 Page1 本年5月の会社法施行から、合同会社（LLC）の利用が可能になりました。有限責任事業組合（LLP）については、昨年8月から利用が可能となっています。LLCおよびLLPは、実務界からの強い要望により創設された、従来わが国には存在しなかったメリットを有している事業体です。本稿では、LLCおよびLLPの創設の背景やそれぞれの概要、あるいは会計処理などについて説明します。 わが国における合同会社（Limited Liability Company、以下、LLC）と有限責任事業組合（Limited Liability Partnership、以下、LLP）は、適用される法律（LLCは会社法、LLPは有限責任事業組合契約に関する法律。以下LLP法）は異なりますが、両方の制度創設の背景は同一のものであったといえます。 わが国だけでなく、各国においても、産業構造は重厚長大型産業から人的資産集約産業へと大きく変化していると言われています。この変化を背景として、優良企業は、人材確保のために長期雇用を掲げたり、また、人材重視経営や人的組織の再評価が行われたりしつつある状況といえます。 このような状況下において、熟練した技術力や、知識、ノウハウ等の人的資産を競争力の源として事業を展開していこうとする場合には、株式会社制度が必ずしも最善の選択肢となり得ないことも考えられます。人的資産を中心として事業を展開していこうとする場合は、人的資産を持った個性のある人たちの集合体となり、そこでは出資者が自ら経営に参加する「所有と経営の一致」した人的組織がより好ましい事業組織として評価されることになります。また、人的組織においては、組織内の運営をなるべく自治に委ねることが、効果的、かつ迅速な意思決定を行うために必要な条件と考えられます。 このような性格を持った従来からの事業体としては、組合、合名会社あるいは合資会社の制度があります。これらは出資者が原則として事業運営にも参加する人的組織であり、運営の自治も大幅に認められています。しかしながら、組合、合名会社あるいは合資会社は、無限責任のある出資者が存在することを前提としての制度であり、出資者にとってはリスクが大きく、これらを利用することには躊躇するものがあり、限界があったといえます。 したがって、人的資産を有効に活用できる、有限責任と運営の自治を兼ね備えた新しい事業形態の創設が望まれることとなりました。 また、米国やイギリスなどでは、同様の性格を持ったLLC（Limited Liability Company）やLLP（Limited Liability Partnership）が多分野で活発に利用され、経済成長の一要因になっているとも言われ、わが国にもこれらの事業体の創設のニーズが高まりました。 このような背景のもと、新しい事業形態の実現に向け、実務界からの要望を受けた経済産業省は平成14年度末に日本版LLC制度の創設に向けての研究会を発足させ、制度創設に向けての提言を行いました。その頃、会社法制の現代化のための検討が行われていたこともあり、新しい会社法制に取り込む形で日本版LLC（合同会社）創設の法制化の提案がなされました。 しかし、このLLC創設の論議の中で、財務省から「LLCは会社法に基づく会社であり、法人格を有することから法人課税を行う予定である」との見解が出されました。実務界からの有限責任の人的法人（LLC）創設の主たる狙いが、米国などと同様に構成員課税（パス･スルー課税）の適用の容認にあったこともあり、その思惑ははずれることになったといえます。 このことから、実務界および経済産業省は、構成員課税を原則とする組合の一形態であるLLP（有限責任事業組合）制度創設へと方向転換を行いました。平成16年9月にLLPに関する研究会を立ち上げ、同12月に「LLP制度の創設の提案」を公表し、LLPの創設を促進しました。 LLPの制度はただちに法制化され、平成17年4月27日に「有限責任事業組合契約に関する法律（LLP法）」が国会で可決成立され、同年8月1日に施行されました。 LLPは組合の一形態であり、会社（法人格を有する）であるLLCとは法形態は異なりますが、実務界や経済産業省が目論んでいた、有限責任で運営自治が認められ、かつ構成員課税が適用される新しい事業形態として創設され利用されることとなりました。 一方、LLCは平成17年6月29日に成立した会社法における新しい会社形態として、平成18年5月よりその利用が可能となりました。 LLCは当分の間法人課税がなされると思われますが、平成17年6月28日の参議院法務委員会の会社法に対する附帯決議のなかで「合同会社に対する課税については、会社の利用状況、運用実態等を踏まえ、必要があれば、対応措置を検討すること」の旨の決議がなされており、今後の、構成員課税適用への含みが持たされています。 LLCとLLPは会社（法人格を持つ）と組合（法人格を持たない）という法的形態は異なりますが、いずれも営利を目的とし、出資者全員の有限責任が担保され、かつ運営が自治に委ねられている事業体であり、多くの共通点があります。 また、会社法における株式会社制度は有限会社法制との一体化がなされたこともあり、非公開株式会社（株式譲渡制限会社）の規律は従来の株式会社のものに比べ大幅に経営の自由度や定款自治が認められました。この意味では譲渡制限株式会社も程度の差はあるものの、LLCやLLPと同様の性格を持つこととなったといえます。 ホームページに掲載している財務会計の最新情報やセミナー開催の更新情報をメール配信によりお知らせしています。 |
[ 131] あずさ監査法人 | 日本版LLCおよびLLPの概要と活用 Page1
[引用サイト] http://www.azsa.or.jp/b_info/letter/87/01.html
|
ID 管理ID およびアクセス管理 ‐ 基本概念第 6 章: アクセス管理公開日: 2004年9月7日アクセス管理は、適用されているポリシーとの整合性を保ちながらリソースへのアクセスを管理および監視するためのプロセスとテクノロジで構成されます。アクセス管理の構成要素は次のとおりです。•認証•承認•信頼•セキュリティ監査認証Microsoft ID およびアクセス管理プラットフォームでは、認証プロセスでユーザー資格情報を検証する暗号化キーを含めた ID 情報を保存するためのテクノロジとして、Microsoft® Active Directory® ディレクトリ サービスを推奨します。Microsoft Windows Server™ 2003、Microsoft Windows® XP Professional、および Windows Security Services に統合されたアプリケーションは、オペレーティング システムのビルトイン機能を使用して認証を実行します。Windows 認証サービスアプリケーションごとに認証プロトコルを実装する方法は非常に効率が悪く、組織全体にセキュリティの欠陥をもたらすことにもなります。そこで、Windows プラットフォームの認証メカニズムを使用してアプリケーションを構築することをお勧めします。最良の結果を得るために、開発者はアプリケーションの設計プロセスを開始する前に、各種の認証タイプを理解し、これらの認証タイプをサポートする各種のプロトコルとインターフェイスの使用によって派生する影響を把握する必要があります。Windows 認証サービスのアーキテクチャWindows Server 2003 および Microsoft Windows XP には、多くのアプリケーションの認証要件を満たす認証メソッドとセキュリティ プロトコルの完全なセットが実装されています。Microsoft Passport Network、証明書またはスマート カードによる公開キー認証、およびユーザー名とパスワードの組み合せは、それぞれ資格要件が異なるので、ユーザーの操作性もセキュリティ特性も異なります。データ転送メカニズムでも、使用可能な認証プロトコルを定義できます。Microsoft ID およびアクセス管理プラットフォームにおける認証サービスのセキュリティ システムは階層化されています。この階層は、柔軟性が高く、管理が容易な低レベルのインターフェイスから、柔軟性は低いけれども、より簡素なアプリケーション プログラミング インターフェイス (API) による高レベルのインターフェイスまでの幅があります。次の図に、認証プロトコルとアプリケーション API がどのように階層化されているかを示します。図 6.1: Windows オペレーティング システムにおける認証 API とプロトコル階層拡大表示する上図の認証スタックの最上部では、高レベルの API およびサービスがプロセス間通信 (IPC) メカニズムを提供し、アプリケーション データの転送にセキュリティと認証で保護されたチャネルを提供します。このようなサービスと API の例としては、DCOM (Distributed Component Object Model)、リモート プロシージャ コール (RPC)、Microsoft ASP.NET、ASP、WinInet などがあります。Microsoft RPC は強力で効率的な、セキュリティで保護されたプロセス間通信 (IPC) メカニズムで、これによってデータ交換および別のプロセスにある機能の起動が可能になります。このプロセスは、同じマシン上、ローカル エリア ネットワーク上、またはインターネット上のどこにあってもかまいません。WinInet は、インターネット プロトコル経由で SSL (Secure Sockets Layer) などのインターネット セキュリティ プロトコルをサポートするように設計されたアプリケーション プロトコル インターフェイスです。WinInet セキュリティ サポートの実装では、セキュリティで保護されたチャネル (Windows NT® の SSL 実装) セキュリティ プロバイダにセキュリティ サポート プロバイダ インターフェイス (SSPI) を使用します。アプリケーション開発者は、これらのサービスが公開する API によって認証およびデータ保護の方法を完全に管理できる場合もあります。たとえば DCOM API では、開発者は Kerberos プロトコルまたは NTLM (NT LAN Manager) チャレンジ/レスポンスなどの特定の認証プロトコルを選択できます。データに署名 (攻撃者によるデータの改ざん防止) または暗号化 (盗聴者によるデータの盗聴防止) が必要かどうかも指定できます。その他のサービスおよび API は、システム構成の影響のみを受けます。代表的な例である ASP.NET は Microsoft Internet Information Service (IIS) 6.0 が実行されているサーバーにホストされ、シナリオに適合した認証メカニズムを使用するように IIS を構成できます。セキュリティ サポート プロバイダ インターフェイス認証における最も低いレベルのアプリケーション インターフェイスは SSPI です。SSPI は GSS-API (Generic Security Service API) のマイクロソフト バージョンです。GSS-API の詳細については、次の URL にある、「Request for Comments」 Web サイトの RFC 1508 と 1509 (英語) を参照してください。http://www.ietf.org/rfc.htmlSSPI の詳細については、次の URL にある、「The Security Support Provider Interface Revisited」 Web サイト (英語) を参照してください。http://msdn.microsoft.com/msdnmag/issues/01/04/Security/default.aspxSSPI と GSS-API の背後にある概念は、2 者間のネットワーク認証は一般に共通のパターンに従うということです。両者は、1 つ以上の情報の断片を指定された順序で交換する必要があります。両者はハイパーテキスト転送プロトコル (HTTP)、RPC、サーバー メッセージ ブロック (SMB)、IIOP (Internet Inter-ORB Protocol)、DCOM、RMI (Java Remote Method Invocation) などの多くの異なるネットワーク プロトコルの 1 つで通信するので、ネットワーク プロトコル自体に単一の認証ハンドシェイクをハードコードしないほうが賢明です。むしろ、"認証トークン" を生成する一般的なインターフェイスを提供します。認証トークンは、単に認証シーケンスの特定の局面を表すバイナリ データのコンストラクトです。これらのトークンは、使用されているアプリケーション プロトコルにかかわらず交換できます。たとえば RPC では、クライアントとサーバー間のプロトコルを同期するために既にハンドシェイクが使用されています。RPC は、このハンドシェイクに、非透過的な、任意のサイズの認証トークンのためのスペースを提供します。SSPI と GSS-API が実行するほとんどの作業は、これらのトークンを生成して評価することです。前述のように、Windows サーバーおよびクライアントのオペレーティング システムは、さまざまな認証プロトコルを実装します。これらのプロトコルは認証パッケージとも呼ばれる "セキュリティ パッケージ" で、ローカル セキュリティ機関 (LSA) サービスが読み込む DLL で構成されます。SSPI は、Windows サーバーおよびクライアントのオペレーティング システムに同梱されているすべてのセキュリティ パッケージ向けのインターフェイスです。これらのセキュリティ パッケージは、一般に Kerberos Version 5 認証プロトコル、NTLM チャレンジ/レスポンス、ダイジェスト認証、SSL (Secure Sockets Layer)、または TLS (Transport Layer Security) などのネットワーク認証プロトコルを実装します。アプリケーションは、これらのプロトコルを認証に使用して安全でシームレスに Active Directory に統合し、さらにプロトコルの機能を使用してアプリケーション データをセキュリティで保護できます。SPNEGO (Secure Protocol Negotiation) は、必要に応じて認証プロトコル間をネゴシエートする特別なセキュリティ パッケージです。Kerberos Version 5 プロトコルまたは NTLM を SSPI と共に使用するアプリケーションに最適の方法は、これらのプロトコルを直接使用する代わりに SPNEGO パッケージを使用することです。SPNEGO の詳細については、MSDN の次の URL にある、「Windows Security」 (英語) を参照してください。http://msdn.microsoft.com/security/securecode/windows/default.aspxKerberos 認証Kerberos Version 5 認証プロトコルの仕様は、「IETF RFC 1510」 (英語) ページ (http://www.faqs.org/rfcs/rfc1510.html ) にあります。このプロトコルは非常に安全で、かつスケーラブルなので、統合ネットワーク環境の認証に最適です。Microsoft Windows 2000 Server またはそれ以降を実行する Windows サーバーまたはクライアントでは、Kerberos Version 5 認証プロトコルが Active Directory への認証の基本になります。Kerberos は、SMB、HTTP、RPC、およびこれらを使用するクライアントとサーバー アプリケーションにも統合されます。Windows プラットフォームはこの強力なセキュリティ ツールを、シームレスで統合された形式でユーザーに提供します。Kerberos Version 5 プロトコルは、オープン スタンダードに基づいているので、Microsoft ID およびアクセス管理プラットフォームにとって非常に重要です。その他の多くのベンダもマサチューセッツ工科大学 (MIT) のプロトコル実装に基づいた Kerberos Version 5 プロトコルを実装しているので、マイクロソフトおよびマイクロソフト以外のプラットフォームとアプリケーション間の認証の相互運用性を確保できます。Windows は、Kerberos Version 5 プロトコルを構成して相互運用性を確保するための次の 2 つの方法をサポートします。•Windows ドメインと MIT ベースの Kerberos Version 5 プロトコル領域間の信頼関係を構築できます。この関係により、この領域のクライアントは信頼メカニズムを使用して Windows ドメインのネットワーク リソースへの認証を受けることができます。•Windows 以外のクライアントとサーバーは、Active Directory アカウントを使用してドメイン コントローラから認証を受けることができます。イントラネットでは、認証プロトコルの基本特性および Windows クライアント/サーバー オペレーティング システムのプロトコルの実装方法の特性により、Windows プラットフォームへの Kerberos Version 5 プロトコルの実装によってユーザーは SSO を使用できます。Kerberos Version 5 プロトコルがアプリケーションの認証とセキュリティに対する万能ソリューションにならない 1 つの大きな限界は、Kerberos 認証をインターネットで使用するように構成することが実用的ではないということです。この理由については、後述の「Web シングル サインオン」で詳しく説明します。Kerberos Version 5 認証プロトコルの詳細については、Microsoft TechNet の次の URL にある「Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability」 (英語) を参照してください。http://www.microsoft.com/technet/prodtechnol/windows2000serv/howto/kerbstep.mspxSSL (Secure Sockets Layer) 3.0 および TLS (Transport Layer Security) 1.0SSL 3.0 と TLS 1.0 は密接に関係するプロトコルで、2 つのアプリケーション間の通信チャネルをセキュリティで保護するという一般的な問題を解決するために使用します。SSL 3.0 は Netscape Communications 専用のプロトコルで、TLS 1.0 は「RFC 2246」 ( http://www.faqs.org/rfcs/rfc2246.html) で定義される IETF (Internet Engineering Task Force) 標準です。この 2 つのプロトコルは似通っていますが、TLS には重要な改良点があるので、マイクロソフトではできる限りこちらを使用することをお勧めします。TLS と SSL は、共にセキュリティで保護されたデータ チャネルを確立する際にサーバー認証の機会を提供しますが、クライアント認証はオプションです。TLS と SSL プロトコルは、HTTP プロトコル経由でデータ保護と整合性 (暗号化) を提供するために広く使用されています。SSL および TLS のサポートを提供するプロトコルは他にもあります。たとえば、LDAP (Lightweight Directory Access Protocol) は SSL を使用して LDAP over SSL または LDAPS を生成します。さらに、カスタムまたはサードパーティ製のアプリケーションは、SSPI を介して SSL または TLS を直接使用して SChannel セキュリティ パッケージを指定できます。SSL および TLS は、対称暗号化キーによる証明書およびセキュリティで保護されたデータ転送に基づいた認証を提供します。インターネットでは、一般に組織はサーバー認証に SSL と TLS を使用します。クライアントは、次の条件を検証して SSL と TLS でサーバーを認証します。•サーバー証明書は有効です。•サーバーは、サーバーの X.509 証明書に関連付けられた適切なプライベート キーを所有していることを証明しています。•認証を受けるサーバーは、証明書に指定されているサーバーと同じです。SSL および TLS は、X.509 クライアント証明書を使用して Windows Server 2003 プラットフォームでのクライアント認証をサポートおよび統合します。クライアントとサーバーの同時認証は、一般に相互認証と呼ばれます。クライアント認証を完了するために、クライアントは有効なクライアント証明書を提示し、サーバーはサーバー認証のために記述された同じ基準を使用して判定します。クライアントの証明書を検証した後に、Windows Server 2003 はそれを Active Directory アカウントにマップできます。Active Directory では、一対一または多対一のマッピングが可能なので、証明書を柔軟にマップできます。他の認証プロトコルと比較して、SSL および TLS は認証に X.509 デジタル証明書を使用する際に非常に優れたセキュリティ特性を発揮します。注: SSL および TLS は、Windows XP クライアントでは Windows 資格情報マネージャを使用してユーザーに Web SSO を提供します。これについてはこの章で後述します。Passport 認証Microsoft Passport は、デジタル ID の膨大なデータベースに対してユーザーを認証する Web サービスです。各ユーザーは、セキュリティで保護された Web サイトを使用して Passport ID を保持します。Passport は、Web サイトに認証および Web SSO 機能を提供し、多くのマイクロソフト Web サイトおよび一部のマイクロソフト以外のサイトで使用できます。開発者は Passport にリンクするアプリケーションを作成し、登録された Passport ユーザーの接続のみを許容できます。ユーザーの資格情報が有効であることを確認すると、Passport は認証チケットを返します。アプリケーションは、このチケットを解読してユーザーの ID を特定できます。プライバシーの要件により、Passport 認証は一般に提携しているアプリケーションに PUID (Passport Unique ID) のみを渡します。一般に、アプリケーションはローカルに維持されているユーザー アカウントに PUID をマップし、組織における有効なデジタル ID を生成します。Windows Server 2003 では、IIS 6.0 で Passport 認証構成オプションを選択すれば、Passport が完全に統合されます。さらに、Passport ユーザーを Active Directory アカウントにマップすれば、Passport 認証を完全に Windows セキュリティ モデルに統合できます。インターネットに接続されたアプリケーションは、Passport 認証を使用してユーザーが SSO を利用できるようにします。そのために、Passport は HTTP Cookie でエンコードされた認証チケットを使用します。Cookie はブラウザのセッションが終了するまで維持されるので、ユーザーは Passport 認証サービスへのログインを繰り返し要求されることなく、複数のアプリケーションへの認証を受けることができます。Passport の詳細については、MSDN の次の URL にある、「.NET Passport Service Guide Kit」 (英語) を参照してください。ダイジェスト認証ダイジェスト認証は認証パッケージとして Windows Server 2003 に含まれ、「RFC 2617」 (http://www.ietf.org/rfc/rfc2617.txt) に記述されているもう 1 つの標準ベースの認証プロトコルです。ダイジェスト認証は、主に Windows と Windows 以外のプラットフォーム間のインターネット認証に相互運用性を提供します。Windows Server 2003 は、ダイジェスト認証を「RFC 2831」 (http://www.ietf.org/rfc/rfc2831.txt) に記述されている簡易認証とセキュリティ レイヤ (SASL) メカニズムとしても実装します。SASL はアプリケーションと下位プロトコル間のもう 1 つのアブストラクション レイヤで、これによってアプリケーションを変更せずに簡単に別の認証メカニズムを含めることができます。ある意味では、前述の SPNEGO メカニズムに似ています。SASL は、主に LDAP 認証に使用します。ダイジェスト認証は、セキュリティの特徴がマイクロソフトの NTLM プロトコルに似ています。ダイジェスト認証と NTLM は共にチャレンジ/レスポンス プロトコルで、予測不能なデータを含むチャレンジを生成するための認証サーバーが必要です。クライアントは、ユーザーのパスワードから生成したキーを使用してチャレンジを暗号化してレスポンスを作成します。サーバーまたは Active Directory などの信頼されたサードパーティ サービスは、クライアントのレスポンスと ID ストアのユーザーに関連付けられた資格情報に基づいて算出した値を比較し、ユーザーが正しいパスワードを所有していることを検証できます。レスポンスが算出された値と一致すると、ユーザーは秘密のパスワードを知っているとみなされ、認証が成立します。一般に、ダイジェスト認証は強力なパスワードに依存して攻撃からチャレンジ/レスポンス メカニズムを保護しているので、Kerberos Version 5 プロトコルほど安全ではありません。ただし、認証においてプレーンテキストのパスワードをサーバーに提示しないので、フォーム ベースまたは基本認証より優れています。SSL および TLS は、ダイジェスト認証を攻撃から守るためによく使用されます。ダイジェスト認証は、ほとんどのシナリオで Kerberos Version 5 プロトコルほどの拡張性はありませんが、Kerberos プロトコルが使用できないシナリオでも動作します。このような例としては、外部に接続された Web サイトへの認証があります。ダイジェスト認証は、単一の Web URL で到達できる情報を保護する場合にのみ SSO を提供します。ユーザーが別のサイトに移動するか、または同じサイトの別のサーバーに移動した場合にも、通常は資格情報を再入力する必要があります。フォーム ベースの認証フォーム ベースの認証は、Web ページのログオン フォームに依存しており、ほとんどの場合、プレーンテキストのユーザー名とパスワードの形式でユーザーの資格情報を収集します。したがって、この種類の認証は前述の Kerberos Version 5 プロトコルまたはダイジェスト認証と同じ意味でのクライアントとサーバー間の認証プロトコルではありません。フォーム ベースの認証では、サポートするアプリケーションを適切に保護するために細心の注意が必要なので、マイクロソフトでは、SSL を使用せずにフォーム ベースの認証を使用することはお勧めできません。フォーム ベースの認証を使用するアプリケーションの脆弱性が悪用されると、攻撃者にプレーンテキストのパスワード データを読み取られるので、組織全体およびネットワーク自体のアプリケーション データが深刻なセキュリティ リスクにさらされます。フォーム ベースの認証を実行するアプリケーションはユーザーの資格情報をプレーンテキストで受け取るので、Active Directory 以外のユーザー ストアに対して認証を行うように選択することもできます。ID ストアを追加すると ID およびアクセス管理のソリューションが複雑になるので、ほとんどの場合、マイクロソフトではこの方法をお勧めしません。フォーム ベースの認証を実装するアプリケーション開発者は、LDAP バインドまたは "LogonUser()" などの Windows API を使用して Active Directory でユーザーを認証し、オプションでセキュリティ コンテキストを生成することをお勧めします。セキュリティ コンテキストについては、後述の「承認」で説明します。フォーム ベースの認証を実装するアプリケーションは、一般に HTTP Cookie または URL の変更を使用してユーザーに SSO を提供します。ASP.NET では、暗号化を使用して Cookie の権限のない読み取りを防止し、デジタル署名を使用して改ざんを防止する機能を提供します。開発者が Windows プラットフォームでフォーム ベースの認証を使用する方法の詳細については、このシリーズの「ID 認識 ASP.NET アプリケーションを開発する」文書を参照してください。基本認証フォーム ベースの認証と同様に、基本認証はネットワーク リソースに認証する際にユーザーの資格情報を暗号化して保護しないという意味で真のネットワーク認証プロトコルではありません。フォーム ベースの認証と同様に、認証するサーバーはユーザー資格情報をクリアテキストで受け取り、Windows API を使用してユーザーを認証します。フォーム ベースの認証と同様に、この認証テクニックを採用する開発者とシステム管理者は、アプリケーションやサーバーを侵害から保護するためにかなりの作業が必要になります。そのために、マイクロソフトでは、SSL を使用せずに基本認証を使用しないことを強くお勧めします。基本認証には、ダイジエスト認証と同じ SSO 特性があります。シングル サインオン認証において必ず議論される重要な部分は、シングル サインオン (SSO) の概念です。認証プロセスに SSO を組み込むには、次のような方法があります。•デスクトップに統合された SSO•Web SSO•資格情報マッピングまたはエンタープライズ SSOSSO は、ユーザーの資格情報を追加入力する必要がないようにすることのみを目的とし、使用される認証のセキュリティ レベルに関する判断はまったく行いません。SSO の種類によっては、セキュリティ上の理由から他より優位なものがあります。エクストラネット SSO とイントラネット SSO は、エクストラネットまたはイントラネットのシナリオで SSO を実現するためのテクニックを表すために使用する用語です。エクストラネット SSO は一般に Web ベースですが、イントラネット SSO には Web アプリケーション、シッククライアント アプリケーション、ターミナル セションを含む多くの種類のアプリケーションおよびサービスを含めることができます。デスクトップに統合されたシングル サインオンセキュリティで保護されたログオンでは、ユーザーはネットワークに自身の ID を保証する必要がありますが、複数のリソースにアクセスするために繰り返しパスワードを入力するのはユーザーにとって煩わしいことです。Microsoft Windows プラットフォームでは、Active Directory で保持される単一ユーザー ID をネットワーク経由で使用できます。ワークステーションにログオンするための資格情報は、しばしばネットワーク リソースにアクセスするための資格情報と同じなので、ユーザーのログオン資格情報 (ユーザー名とパスワード組み合わせ) は、クライアントのオペレーティング システムのローカル セキュリティ機関 (LSA) にローカルにキャッシュされます。ユーザーがドメインにログオンすると、Windows 認証はネットワーク リソースに認証するときにキャッシュされた資格情報を使用して SSO を提供します。強力なセキュリティは、ネットワーク リソースへのアクセスに認証された ID を提供することをユーザーに要求します。SSO を使用すれば、ユーザーは一度だけシステムから認証を受けるだけで、別途にアカウント ID またはパスワードを入力せずに使用権を保有するすべてのアプリケーションとデータ ソースにアクセスできます。組織のイントラネットの Windows ドメインまたはフォレストにおいて SSO が使用できるように、Kerberos Version 5 認証プロトコル、NTLM、およびスマート カード認証のテクニックは、すべてマイクロソフト クライアントとサーバーのオペレーティング システムのデスクトップ ログオン プロセスに統合されています。Active Directory は、サーバーが各ユーザーに関する情報をローカルに保存する必要なくユーザーの検証を可能にするための、信頼されたサードパーティを提供します。他のドメインのリソースにアクセスする際に Windows Server 2003 のフォレスト間信頼などの高度な信頼メカニズムを使用すれば、他のドメインの ID によって SSO を利用できます。Web シングル サインオン企業が従業員、パートナー、および顧客が使用するエクストラネットとイントラネット ベースの Web アプリケーションを展開する機会が増加するにつれて、ユーザーに SSO を提供することが非常に重要になります。Web アプリケーションは、Web サーバーに依存して認証を実装するという点において、従来の "シック" クライアント/サーバー アプリケーションとは異なります。この依存関係では、単一のアプリケーション (Web サーバー) に認証メカニズムを追加するという共通の方法によって、サーバーがホストする多くのアプリケーションの認証の問題を解決できます。マイクロソフトのサーバーおよびクライアント製品は、イントラネット環境で Internet Explorer と IIS 6.0 に Kerberos Version 5 認証プロトコルを実装することによって、Web シングル サインオン (Web SSO) を提供します。これについては、このシリーズの「イントラネット アクセス管理」文書で説明します。残念ながら、イントラネットのシナリオでは問題なく動作する Kerberos の実装は、組織のエクストラネットでインターネットに接続されたアプリケーションでは正しく動作しません。イントラネットとエクストラネットの Web SSO の違いは、次の 2 つの要因の組み合わせから生じます。•Active Directory ドメイン コントローラなどのインターネットに接続されたキー配布センター (KDC) の展開に内在する問題•多くのブラウザが HTTP 経由の Kerberos 認証をサポートしていないことインターネットに接続された KDC の展開に内在する問題の詳細については本書の範囲外ですが、この問題が展開を妨げる主要な障壁です。2 番目の要因は、一般にエクストラネットの展開にとってより重要な問題です。ソフトウェアに標準を適用できる内部の展開とは異なり、外部アプリケーションにアクセスするために外部の顧客およびビジネス パートナーが使用するブラウザ ソフトウェアの種類とバージョンの両方を検出できる組織は少数です。HTTP 経由の Kerberos 認証をサポートする市販のブラウザは、Microsoft Internet Explorer 6.0 またはそれ以降のみです。HTTP 経由の Kerberos 認証の実装の詳細については、「IETF ドラフト情報仕様」 (http://www.ietf.org/internet-drafts/draft-brezak-kerberos-http-00.txt) を参照してください。複数の Web アプリケーションに対する SSO の問題を解決する標準の方法は、「IETF RFC 2109」 (英語) (http://www.ietf.org/rfc/rfc2109.txt) で定義されているセッション "Cookie" を使用することです。いくつかのソフトウェア ベンダ (ISV) は、複数のエクストラネット Web アプリケーションで Web SSO を使用するためのソリューションを提供しています。前のセクションで詳しく説明した Microsoft Passport サービスも Passport 認証をサポートするサイトで SSO を実現します。Web SSO とエンタープライズ SSO のテクニックを組み合わせることもできます。たとえば、SharePoint Portal Server Web サイトは独自の認証ディレクトリにレガシー アプリケーション データにアクセスするための Web パーツを備えています。この例では、Web SSO テクニックは Web サイトへのアクセスを提供し、エンタープライズ SSO テクニックはレガシー アプリケーション データへのアクセスを提供します。資格情報マッピングとエンタープライズ シングル サインオン エンタープライズ SSO は、資格情報マッピングを使用して SSO を実現するためのすべてのテクニックを定義します。資格情報マッピングは、認証に異なる ID ストアまたはディレクトリが関わっている場合に必要です。クライアントまたはサーバーで実行されるサービスは、アカウントの代わりにターゲット アプリケーションに署名して SSO をシミュレートします。このサービスは、資格情報マッピングのストアまたはデータベースから、アカウント、パスワードなどの適切な資格情報を検索する必要があります。Microsoft BizTalk® Server、Host Integration Server、SharePoint® Portal Server、Windows Credential Manager、および PassLogix、Protocom、Version3 などのソフトウェア ベンダ (ISV) 製品は、認証に独自のディレクトリを使用するレガシー システム、アプリケーションに対して、さらに信頼されていない Windows ドメインのリソースへのアクセスに対しても、さまざまなエンタープライズ SSO テクニックを使用します。多くの組織では複数の信頼されていない ID ストアを使用するので、エンタープライズ SSO によって、SSO がない場合に比べてユーザーの操作性が向上します。エンタープライズ SSO アプローチは、シームレスな操作性を実現し、ヘルプデスクへの問い合わせを最小限に抑えるために、プロビジョニングおよびパスワード管理と統合する必要があります。このアプローチは、総保有コスト (TCO) を最小限に抑えながら最良の操作性を提供します。注: デスクトップに統合された SSO は、推奨されるディレクトリに綿密に統合され、また余分なディレクトリと資格情報マッピングのデータベースに対する追加のプロビジョニングおよび管理を必要としないので、エンタープライズ SSO よりデスクトップに統合された SSO をお勧めします。エンタープライズ SSO による資格情報マッピングの詳細については、このシリーズの「イントラネット アクセス管理」文書を参照してください。Windows 資格情報マネージャWindows XP Professional と Windows Server 2003 には [ユーザー名およびパスワードの保存] 機能があり、これは資格情報の管理機能も提供します。使用する認証の種類によって、このコンポーネントはユーザーの資格情報を保存し、その後のアクセスで再利用できます。図 6.2: [ユーザー名およびパスワードの保存] による複数の資格情報での SSO の使用アプリケーションがユーザーによる資格情報の保存を許可しない場合、ユーザーは手動で [ユーザー名およびパスワードの保存] にアクセスしてリソースに対する資格情報を設定する必要があります。資格情報マネージャは、次の種類の資格情報をサポートします。•Kerberos Version 5 プロトコルと NTLM 認証用のユーザー名およびパスワードの組み合わせ•SSL/TLS を使用するクライアント認証用の X.509 デジタル証明書•Web 認証用の Microsoft Passport 資格情報注: Windows 資格情報マネージャを使用すれば、SSL/TLS X.509 クライアント証明書認証で Web SSO を実現できます。既定では、複数の有効な証明書がある場合は、認証に使用する証明書を選択するためのプロンプトが表示されます。資格情報マネージャでは、特定のリソースに対する認証を行う際に適切な証明書が自動的に表示されます。Windows 資格情報マネージャの詳細については、このシリーズの「イントラネット アクセス管理」文書を参照してください。ページのトップへ承認承認は、ユーザーの権限をリソースのセキュリティ構成と比較することによってリソースへのアクセスを決定するアプリケーションまたはプラットフォームのプロセスです。たとえば、ユーザーがファイル サーバーに認証されると、ファイル サーバーはユーザーがファイル読み取り、書き込み、または削除する権利を持っているかどうかを確認します。Windows Server 2003 オペレーティング システムと Active Directory に統合されているアプリケーションは、オペレーティング システムのビルトイン機能を使用して承認を実行します。Windows Server 2003 は、Windows のアクセス制御リスト (ACL) ベースの偽装モデルおよび新しいロール ベースの承認マネージャの 2 つの承認メカニズムをサポートします。さらに、Microsoft ASP.NET アプリケーションは、承認に ASP.NET ロールを使用できます。この 2 つのメカニズムの詳細については、この章で後述します。Windows の偽装およびアクセス制御リスト (ACL)Microsoft Windows NT 3.1 では、サービスとアプリケーションに承認機能を提供するために偽装と ACL モデルを導入しました。偽装は、シームレスな操作性と容易な管理性を提供するために認証と承認メカニズムを密接に結合した結果生まれました。認証パッケージは、ユーザーを認証してユーザーの "セキュリティ コンテキスト" を作成します。セキュリティ コンテキストはユーザーの ID と権限およびユーザーが所属するグループを表します。認証パッケージがセキュリティ コンテキストを生成すると、アプリケーションまたはサービスにはリソースへのアクセスの許可に使用するセキュリティ コンテキストが与えられます。言い換えると、サービスはサービス自身のコンテキストを使用する代わりにユーザーのセキュリティ コンテキストを使用してユーザーをローカルに偽装してリソースにアクセスできます。 これは、ほとんどのサービスがコンピュータに対して広範な権限を持っているので重要な概念です。たとえば、Windows を実行するサーバーでファイル サービスと印刷サービスを提供するサーバー メッセージ ブロック (SMB) サービスはローカル システムとして動作し、任意のリソースにアクセスできます。ファイルの所有者、ファイル管理者、またはシステム管理者が作成したルールに基づいてファイルへのユーザー アクセスを制限するために、SMB サービスはリモート ユーザーを偽装します。Windows 承認モデルのもう 1 つの部分はオブジェクト ベースの ACL です。オブジェクト用 ACL は、オブジェクトに対してセキュリティ プリンシパル (ユーザーまたはグループ) が持っているアクセス レベルを定義します。たとえば、ファイルの ACL には各ユーザーが持っているファイルの読み取りや削除の権利を定義します。 オペレーティング システム (つまり NT Object Manager) は、このモデルを使用してオブジェクトにアクセスするための最終的な判別子です。NT Object Manager は、ユーザーのセキュリティ コンテキストをオブジェクトの ACL と比較してこれを実行します。オペレーティング システムが最終的な判別子なので、偽装/ACL モデルには複数のアプリケーションがシステム リソースにアクセスするようなシナリオに適したセキュリティ特性があります。ただし、偽装/ACL モデルの次のような領域にはまだ改善の余地があります。•パフォーマンス: 一度に多くのユーザーにコンテンツを配信するサービスでは、偽装を使用してコンテキストを切り換えるコストによってサーバー負荷が増大し、アプリケーションの拡張性に影響することがあります。•柔軟性: 偽装モデルを使用する場合、アプリケーション開発者またはサービス管理者は、ドメイン レベルでグループ メンバシップを変更しないかぎり、ユーザーのために新しいグループまたはロールを作成することはできません。ドメイン管理者は、単一のアプリケーションが多くのグループを作成して使用することに抵抗があるので、アプリケーション開発者は既存のグループで対処しなければならなくなります。•ビジネス ルール: 偽装/ACL モデルは、オブジェクトの承認を適切に表現しますが、時刻またはその他の実行時ロジックなどのビジネス ルールのロジックを表すことは困難です。たとえば、特定の個人が特定の操作を一定時間内のみ実行できるような承認ポリシーを適用するとします。このような問題に対処するために、Windows Server 2003 にはシステム管理者とアプリケーション開発者用の承認マネージャが用意されています。「Windows 2000 Authorization Manager Runtime download」 (英語) は Microsoft.com の次の URL で入手可能です。http://www.microsoft.com/downloads/details.aspx?FamilyID=7edde11f-bcea-4773-a292-84525f23baf7Windows Server 2003 承認マネージャWindows Server 2003 の承認マネージャは、新しいロール ベース アクセス制御 (RBAC) インターフェイスです。承認マネージャは、開発者に以下の機能を提供します。•アプリケーション アクセス制御の管理を簡略化します。•簡単で最適な開発モデルを提供します。•柔軟で動的な承認決定が可能になります。与えられたタスクに対して、承認マネージャのインターフェイスは、ユーザーをアプリケーションの各種ロールに編成し、これらのロールを偽装してアクセス権を与えます。次の図に、アプリケーションにアクセスする 3 種類のユーザーを示します。承認マネージャは、各ユーザーを承認ポリシー ストアに定義されたロールにマップします。図 6.3: 承認マネージャがロールを定義して適用する方法拡大表示する承認マネージャは、各アプリケーションのニーズに基づいて論理的なロールとタスクを定義して保守する機能を提供します。組織の構造に基づいてセキュリティ モデルを表現すると、アクセス制御の管理が簡単になります。さらに、タスクとロールの定義はアプリケーション ワークフローのモデル化を補助し、承認マネージャを介して開発者に最適なアプリケーション中心の環境を提供します。承認マネージャによって、権限を実行時に動的に与えることができます。この機能によって、経費報告アプリケーション、Web ベースのショッピング アプリケーションなどの基幹業務 (LOB) アプリケーションに存在するさまざまな承認問題に対処できます。このようなアプリケーションでは、必ずしも明確に定義された永続的なオブジェクトへのアクセスが承認を決定するわけではありません。代わりに、ワークフローまたはデータベースの照会、電子メール メッセージの送信などの複数の操作を要求します。そのようなアクセスは、トークンのグループ メンバシップだけでなく、経費アプリケーションに提示された金額、ワークフローの完了確認などのビジネス ロジックにも基づいて決定されます。明確に定義された永続的なオブジェクトを持たないアプリケーションでは、ACL を配置する場所がありません。このような動的なアクセス決定は、承認マネージャが提供する (BizRules と呼ばれる) 動的ビジネス ルールの形式で簡単に使用できます。BizRules は、一般に Microsoft Visual Basic® Scripting Edition スクリプトまたは JScript® ルーチンを使用して実装され、アプリケーションの実行時にアクセス許可をチェックするときに実行されます。BizRules が成功すると、アプリケーションは要求された操作を実行します。アプリケーションが使用する論理的なロールとタスクを定義する承認マネージャのポリシーは、Active Directory のアプリケーションのパーティション、ADAM (Active Directory Application Mode)、またはサーバーまたはネットワークの XML ファイルに保存されます。Windows Server 2003 承認マネージャを使用する RBAC の詳細については、TechNet の次の URL にある、「承認マネージャと役割ベースの管理の概要」ページを参照してください。http://technet2.microsoft.com/WindowsServer/ja/library/aabe619a-fb52-4f76-b911-6525ce5264ed1041.mspxアプリケーションが承認マネージャのロール ベースのフレームワークを使用する例としては IIS 6.0 があります。Windows Server 2003 に付属する IIS 6.0 には、IIS 6.0 URL 承認を実装する承認マネージャが統合されています。この統合によって、Web アプリケーションの管理者はカスタム ユーザー ロール、LDAP クエリ、および BizRules に基づいて URL へのアクセスを制御できます。IIS で Web ページへのユーザー アクセスを承認するには、Web アプリケーションが使用するリソースに対する多数の随意 ACL (DACL) を管理する必要があります。Web アプリケーションのリソースには、Web ページ ファイル、データベース レコード、レジストリ キーなどがあります。DACL を保守する管理者には、各オブジェクトが Web アプリケーションに対して有用なタスクを実行するために必要なバックエンドのアクセス許可に関する正確な知識が必要です。 IIS 6.0 の URL 承認では、管理者は Web アプリケーションを構成する URL に対するユーザー アクセスを承認することによってアクセス管理を簡略化できます。クライアントが URL を要求すると、IIS 6.0 の URL 承認はユーザーのロールに基づいてアクセス許可を検証します。必要に応じて、Web アプリケーションは承認マネージャのロール ベースのフレームワークを使用してリソースへのアクセスと操作をさらに制限できます。ASP.NET 承認ASP.NET は、Active Directory グループおよびアプリケーションから派生したロールを使用するロール ベースの承認モデルを提供します。承認マネージャの RBAC と ASP.NET ロール ベースの承認には類似点もありますが、個別のメカニズムによって実装されます。ASP.NET のロールは、より大きなアプリケーション スイートに所属することがほとんどないスタンドアロン アプリケーションに最適です。ページのトップへ信頼パートナーシップを締結して実装したり、個別の外部または内部ディレクトリ構造を使用する場合などは、複数の ID ストアをリンクする必要があります。リンクにより、1 つの ID ストアに対して認証されたユーザーを、デジタル ID を持たない別の ID ストアに対して認証することができるようになります。このような方法は、"信頼関係" と呼ばれます。信頼関係は、独立した "領域" 間に設定されます。領域はセキュリティ境界を定義します。Windows NT と Active Directory 環境では、ドメイン間で信頼を確立できます。Windows Server 2003 では、フォレスト間でさらに高いレベルの信頼を確立できます。ただし、フォレスト内のドメイン間には暗黙の信頼があります。Windows Server 2003 および Active Directory に統合されているアプリケーションは、オペレーティング システムのビルトイン機能を使用して信頼を確立し、維持します。信頼関係を管理する高いレベルでは、信頼関係は領域間の認証方法を提供するだけです。ただし、領域間の認証プロセスおよびその後の承認プロセスが実際に有効に機能するには多くのタスクが必要なので、信頼のメカニズムは複雑になります。ここからは、Windows プラットフォームで使用できる各種の信頼、および信頼を使用して ID とアクセス管理の問題を解決する方法について説明します。外部の信頼Microsoft Windows NT Server 4.0 では、"ドメイン間信頼" の概念が導入されました。現在は "外部の信頼" と呼ばれている Windows NT 4.0 のドメイン間信頼を使用すれば、Windows NT 4.0 ドメインは別の Windows NT 4.0 ドメインをそのドメインに所属するユーザーを認証する機関として信頼できます。外部の信頼は一方向または双方向で、次の図に示されているように、信頼の方向は認証とアクセスが行われる方向を示します。図 6.4: 信頼するドメインと信頼されるドメイン間の関係拡大表示するWindows NT Server 4.0 モデルは非常に柔軟で、必要に応じて部署ごとにボトムアップの基本展開パターンで Windows NT 4.0 ドメインを実装できました。大企業がネットワーク接続するドメインの数が増加するにつれて、外部の信頼関係の管理が深刻な問題になりました。展開されている各ドメインは "n" 個の信頼関係を結ぶ場合があるので、管理する信頼関係の総数は展開するドメインの数が増加するに従って急激に増加します。4 個のドメインを維持する小規模企業で管理する信頼関係は 12 ですが、10 個のドメインを維持する大企業では 55 の信頼関係を管理する必要があります。100 のドメインを維持する企業では、膨大な数の信頼関係を管理する必要があります。Windows 2000 Server フォレスト大規模組織の信頼管理を簡略化するために、Microsoft Windows 2000 Server では Active Directory フォレストの概念が導入されています。Active Directory フォレストでは、必要に応じて Windows NT Server 4.0 のボトムアップの信頼モデルの柔軟性を残していますが、次の図のように、トップダウンの信頼がはるかに容易に管理できるようになっています。図 6.5: 単一の Windows 2000 Server フォレスト拡大表示するこの図は、単一の Windows 2000 Server フォレストで構成される組織を示します。フォレスト内の信頼関係は暗黙の信頼で、双方向の外部の信頼と同じ機能を提供しますが、同じフォレストにドメインを追加したときに自動的に作成されます。フォレスト内のドメインは階層的なので、組織の業務形態をネットワークに反映できます。残念なことに、Windows 2000 Server には信頼関係に対する決定的な解答はありませんでした。Windows 2000 Server では、ほとんどの企業でネットワークとリソース全体を単一のフォレストがカバーする展開を想定していました。しかしながら、このようにならない多くの理由があります。たとえば、組織全体のリソースを管理する中央の信頼された管理グループを持たない非常に大きな組織もあります。そのような組織では、当然、ディレクトリ サービス アーキテクチャを実装する必要がある組織の部署間にセキュリティ境界があります。もう 1 つの一般的な例は、イントラネットとエクストラネットのフォレストを区別する必要性です。エクストラネットをイントラネット フォレストのドメインとして設計することもできますが、多くの組織では、セキュリティ上の理由によって、エクストラネットとイントラネット間を隔離することを望んでいます。Windows ドメインとフォレストのセキュリティ境界の特性の詳細については、Microsoft.com の次の URL にある、「Creating and Enhancing Security Boundaries」 (英語) を参照してください。http://technet2.microsoft.com/windowsserver/en/library/778caeb4-0755-4fbb-be10-fd37a3687d771033.mspxWindows 2000 Active Directory を含む複数のフォレストを持ち、別のフォレストのドメインとの信頼を使用する組織では、別のフォレストのすべてのドメインに対して明示的に信頼を確立する必要があります。Windows 2000 Server のこの構成方法は、すべてのドメイン間に信頼を確立しなければならなかった Windows NT Server 4.0 に比べて多少簡単になりましたが、より良いソリューションが必要であることは明白でした。Windows Server 2003 フォレストの信頼Windows Server 2003 では、複数のフォレストを簡単に展開するために "フォレストの信頼" という概念を確立しました。管理者は、フォレストの信頼を使用して 2 つの Active Directory フォレストを 1 つの信頼関係で連合し、シームレスな認証と承認を実現できます。フォレストの信頼は、2 つのフォレストのルート ドメイン間の信頼リンクで、各フォレストのすべてのドメイン間に推移性の信頼が確立されます。たとえば、フォレスト A がフォレスト B を信頼する場合、フォレストの信頼によってフォレスト A のすべてのドメインはフォレスト B のすべてのドメインを信頼します。次の図に、この概念を示します。図 6.6: Windows Server 2003 フォレストの信頼関係拡大表示するただし、フォレストの信頼はフォレスト間では推移しません。つまり、フォレスト A がフォレスト B を信頼し、フォレスト B がフォレスト C を信頼する場合、フォレスト A が自動的にフォレスト C を信頼することはありません。Windows Server 2003 のフォレスト間信頼の使用と構成の詳細については、Microsoft TechNet の次の URL にある、「Planning and Implementing Federated Forests in Windows Server 2003」 (英語) ページを参照してください。http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/directory/activedirectory/fedffin2.mspxフォレストの信頼を使用するWindows Server 2003 では、フォレストの信頼によってフォレストの連合という概念を実現しました。前述のように、フォレストの信頼によって 2 つのフォレストのすべてのドメイン間で推移性の信頼が実現します。フォレストの信頼は、 2 つのフォレストのルート ドメイン間に確立されます。 フォレストの信頼は、一方向または双方向の信頼です。上図では、フォレスト A とフォレスト B に双方向の信頼が確立されています。したがって、フォレスト A のユーザーはフォレスト B のリソースの認証を受けることができ、フォレスト B のユーザーはフォレスト A のリソースの認証を受けることができます。フォレストの信頼では認証の他に承認も可能なので、各フォレストのリソースの所有者は相手のフォレストのプリンシパルを DACL およびグループに追加したり、そのグループに基づいてロールを作成できます。信頼の代わりにシャドウ アカウントを使用するセキュリティの要件によっては、フォレスト間の Windows 信頼メカニズムを使用できないこともあります。そのような場合は、他方のアカウントを反映するシャドウ アカウントを適切なディレクトリに作成します。シャドウ アカウントは、一般に特定のアプリケーションまたはシナリオが必要とする範囲の ID 情報をソース領域から反映します。セキュリティ要件を満たすために、機密性の高い ID 属性は提示されません。機密情報には、ユーザーの社会保険番号、パスワードなどがあります。従業員にシャドウ アカウントを使用するという考え方は直感的ではありませんが、従業員の認証に組織の Active Directory のイントラネットのインスタンスを使用しながら、従業員がエクストラネットを使用できるようにする場合を考えると理解できます。 エクストラネットで従業員を認証するには、次の 2 つの方法があります。•境界領域のネットワーク (DMZ、非武装ゾーン、スクリーン サブネットとも呼ばれます) からイントラネットへのフォレストまたはドメインの信頼を使用します。•境界領域ネットワークにシャドウ アカウントを作成します。最初の方法では、境界領域ネットワークとイントラネットを分離するファイアウォールを通過するパスを許可するポートを多数開く必要があります。この方法は多くの組織で採用できますが、境界領域ネットワークとイントラネットを完全に分離する必要がある組織もあります。厳密にネットワークを分離する必要がある組織には、シャドウ アカウントを使用する方法が適しています。シャドウ アカウントは、Microsoft Identity Integration Server 2003 Enterprise Edition (MIIS 2003) などの自動化メカニズムを使用して作成することをお勧めします。エクストラネットなどに存在するセキュリティが脆弱なサーバーに対してパスワードを使用しない認証メカニズムを有効にした場合などでも、シャドウ アカウントをネットワーク セキュリティに追加できます。この例としては、SSL (Secure Sockets Layer) 3.0 および TLS (Transport Layer Security) 1.0 のクライアント証明書認証に基づいた認証、RSA Security Inc. 社の SecureID 二要素認証などの使い捨てパスワードによる認証メカニズムなどがあります。公開キー基盤 (PKI) での信頼公開キー基盤 (PKI) はデジタル証明書、証明機関 (CA)、およびその他の登録機関 (RA) で構成されるシステムで、電子取引の双方の当事者の有効性を公開キーによる暗号を使用して検証および認証します。ただし、そのためには、双方の当事者が証明書の発行元 (多くの場合、CA) を信頼する必要があります。Windows ユーザー、コンピュータ、およびサービスにおける証明機関に対する信頼は、信頼されたルート証明機関のストアにルート証明書のコピーおよび有効な証明書へのパスが存在している場合に確立されます。有効な証明書パスとは、証明書パスのすべての証明書が失効または有効期限切れではないことを意味します。証明書パスには、証明書階層の下位 CA からルート CA までの各 CA に発行されたすべての証明書が含まれます。たとえば、ルート CA の証明書パスは、自己署名による証明書 1 つだけです。階層内のルート CA の直下にある下位 CA の証明書パスは、自身の証明書とルート CA 証明書の 2 つの証明書を使用します。コンピュータおよびコンピュータがホストするアプリケーションに対して PKI 信頼を確立する最も簡単な方法は、信頼されたルート証明機関のストアにルート証明書をインポートすることです。たとえば、架空の Contoso Pharmaceuticals 社の Web サーバーのルート証明機関ストアに Fabrikam Inc. 社のルート証明書 CA をインストールすると、Contoso 社の Web サーバーは Fabrikam 社の CA から発行されるすべての有効な証明書を信頼します。このプロセスでは、取引の信頼に関する部分のみが確立され、Web サーバーにおける ID またはコンテキストは確立されません。ID からコンテキストへのマッピングを作成するには、証明書の情報を Active Directory のセキュリティ プリンシパルにマッピングするなどの操作が必要です。Active Directory 証明書マッピングを使用した相互認証の詳細については、Microsoft Windows 2000 Server Web サイトの次の URL にある、「Windows 2000 ホーム ‐ ユーザー アカウントへの証明書のマッピング」ページを参照してください。http://www.microsoft.com/japan/windows2000/techinfo/planning/security/mappingcerts.asp信頼されたルート証明書機関のストアのメカニズムは簡単に展開できますが、Contoso 社と Fabrikam 社のような 2 つの組織に連合された信頼を確立する場合などの複雑なシナリオのセキュリティ要件を満たすことができない場合があります。たとえば、Contoso 社と Fabrikam 社の両方のユーザーが、有効な証明書を提示して Contoso 社の Web サイトにアクセスできるシナリオでは、外部の Active Directory に Contoso 社と Fabrikam 社の両方の証明機関から発行された証明書のマッピング情報が保存されます。1 つの方法は、E=fred@fabrikam.com などの証明書のサブジェクトに基づいてマッピングすることです。この方法の問題は、信頼が "無制限" になることです。無制限の信頼では、Contoso 社は Fabrikam 社を完全に信頼するので、サブジェクトが E=fred@contoso.com の証明書を発行しなくなります。ここで、fred@contoso.com は Fabrikam 社のユーザーではなく、Contoso 社のユーザーです。この場合、証明書の所有者は Contoso 社のサイトの機密データにアクセスできてしまいます。この問題の原因は、PKI 信頼が本質的に脆弱であるためではなく、証明書の定義の範囲が広すぎることにあります。この問題を解決するには、Fabrikam 社が @contoso.com ドメインではなく @fabrikam.com ドメインに証明書を発行できるような厳密に制御できる PKI の信頼メカニズムを確立する必要があります。限定従属Windows 2000 ネットワークでは、CA 階層でクロス証明書は使用できませんでした。唯一の代替手段は、特定の CA を信頼する証明書信頼リスト (CTL) を定義して証明書の使用を制限することでした。Windows 2003 Server で導入される限定従属は、基本ポリシー、名前付け、およびアプリケーションの制約を使用して CA 階層をクロス証明するプロセスです。これによって、パートナーの CA 階層または同じ組織の 2 次階層が受容する証明書を制限できます。限定従属を使用すれば、CA 管理者はパートナーの PKI が発行する証明書の中で CA 管理者の組織が信頼する証明書を明確に定義できます。また、限定従属を使用すると、ポリシーのガイドラインに基づいて組織の証明書の発行を区画化して制御することもできます。限定従属を使用すれば、個別の信頼階層の CA 間の信頼も確立できます。この種類の信頼関係も "クロス証明書" と呼ばれます。このような信頼関係を使用すれば、限定従属は下位の CA 以外にも使用できます。階層間の信頼は、1 つの階層の下位の CA と別の階層のルート CA を使用して確立することもできます。限定従属では、PKI ドメインの内部およびドメイン間に信頼条件を追加することによって信頼階層を拡張できます。限定従属を使用すれば、信頼階層の限定従属 CA ごとに証明書の発行および使用方法を制御するルールを設定できます。証明書の定義の範囲が広すぎるという前述の問題を解決するために信頼の条件を使用する方法の例としては、Contoso 社と Fabrikam 社の階層間にクロス証明書を確立する際に名前空間の制約を使用することです。これによって、Contoso 社は fabrikam.com ドメインを指定した Fabrikam CA の証明書のみを受容することができます。限定従属の詳細については、Microsoft TechNet の次の URL にある、「限定従属」ページを参照してください。http://www.microsoft.com/technet/prodtechnol/windowsserver2003/ja/library/ServerHelp/db43554f-7432-4f50-945b-43882753cdf0.mspxページのトップへセキュリティ監査 監査によって、アクセス管理イベントおよび ID オブジェクトの変更を監視できます。セキュリティ監査は、一般に問題およびセキュリティ違反の発生を監視するために使用します。総合的なセキュリティ監査と報告には、Windows セキュリティ イベント ログ、WMI (Windows Management Interface)、MOM (Microsoft Operations Manager) などの製品のテクノロジを使用できます。ディレクトリ サービスを監査するActive Directory と ADAM は、Windows Server 2003 監査に完全に統合されています。Windows セキュリティ イベント ログは、ディレクトリ オブジェクトと属性への変更、およびディレクトリ オブジェクトと属性、スキーマ、グループ ポリシーの承認ポリシーを記録します。成功、失敗、または操作の試行に基づいた監査可能なイベントの構成を正確に制御できます。認証を監査する前述の Windows 認証メカニズムは、すべて Windows セキュリティ イベント ログに監査情報を生成します。生成する監査の内容 (認証の成功、または失敗など) は、グループ ポリシーを使用して構成するか、またはサーバーごとに手動で構成します。Windows Server 2003 では、認証イベントを認証の種類に基づいて分類して厳密に制御できます。たとえば、ある種類の監査がコンソールのログオンを追跡し、別の種類の監査がネットワーク リソースへの認証試行を追跡します。認証の監査は、常に一意のセキュリティ プリンシパルまで追跡できます。ユーザーが ID ストアに認証されると、次の段階はアクセスできる内容を指定することです。承認は、リソースへのアクセスを制御するプロセスです。承認を監査するWindows サーバー プラットフォームは、承認アクションの監査を完全にサポートします。偽装/ACL モデルでは、NT オブジェクト マネージャが監査の構成に基づいてリソースへのアクセスの監査を報告します。この構成は、グループ ポリシーを使用して適用するか、またはサーバーごとに手動で適用します。監査はシステムが生成するので、監査イベントはシステム セキュリティ イベント ログに記録されます。監査の構成は厳密に指定でき、ファイルへのアクセス試行の失敗のみを監査するように指定することもできます。認証と承認のメカニズムは綿密に統合されているので、承認の監査ではリソースにアクセスするセキュリティ プリンシパルが一意のセキュリティ ID (SID) で指定されます。承認マネージャは、実行時監査と承認マネージャ ポリシー変更の監査の両方をサポートします。実行時監査では、成功または失敗の監査を使用してアプリケーションの初期化、コンテキストの作成と削除、およびオブジェクトへのアクセスを報告します。承認マネージャ ポリシー変更監査では、ポリシーおよびポリシーの定義を含めたポリシー ストアの変更を報告します。単一のセキュリティ領域または Active Directory フォレスト内の認証および承認は、比較的簡単なプロセスです。ただし、ID およびアクセス管理では 2 つの個別のセキュリティ領域をリンクする必要がある場合が多く、そのためには、ディレクトリ サービス間または組織間に何らかの形式の信頼を実装する必要があります。次の章では、この要件について説明します。信頼を監査するWindows Server 2003 は信頼の構成を詳細なレベルで完全に監査します。信頼に関しては、作成、削除、および変更に関するイベントを監査できます。信頼監査のイベントは、セキュリティ イベント ログに記録されます。この章では、複数の ID ストアでユーザーを認証して承認する方法について説明しました。次の章では、独立した複数の ID ストアにおいて確実に複数のデジタル ID を作成する方法について説明します。ページのトップへ6 of 8目次•第 1 章: 「基本概念」の紹介•第 2 章: 用語とイニシアチブ•第 3 章: Microsoft ID およびアクセス管理のテクノロジ•第 4 章: ディレクトリ サービス•第 5 章: ID ライフサイクル管理•第 6 章: アクセス管理•第 7 章: アプリケーション•謝辞 プロファイル (個人情報) の管理 |お問い合わせ先 |TechNet の情報を無料ニュースレターで入手© 2007 Microsoft Corporation. All rights reserved. 使用条件 |商標 |プライバシー |日本での個人情報の取り扱い |
[ 132] ID およびアクセス管理
[引用サイト] http://www.microsoft.com/japan/technet/security/guidance/identitymanagement/idmanage/p1fund_5.mspx
