コードアクセスセキュリティと ADO.NET

[アーティクル]
05/20/2011

.NET Framework はコードアクセスセキュリティ (CAS) に加えてロールベースのセキュリティを備えています。どちらも、共通言語ランタイム (CLR) が提供する共通のインフラストラクチャを使って実装されています。アンマネージコードの場合、ほとんどのアプリケーションはユーザーまたはプリンシパルの権限で実行されます。そのため、悪意のあるソフトウェアやエラーを含むソフトウェアが、システム特権を持つユーザーによって実行された場合、コンピューターシステムが被害を受けたり、機密データが改ざんされる可能性があります。

これに対し、.NET Framework で実行されるマネージコードには、コードそのものに適用されるコードアクセスセキュリティが存在します。コードの実行が許可されるかどうかは、プリンシパルの ID だけでなく、コードの作成元など、コードの ID を表す情報に依存します。これにより、マネージコードが誤用される可能性が低くなります。

コードのアクセス権限

コードは、実行されるときに、CLR のセキュリティシステムで評価される証拠を提示します。通常、この証拠は、URL、サイト、ゾーン、アセンブリの ID を保証するデジタル署名などのコードの作成元に関する情報で構成されます。

CLR は、そのコードに許されている操作の範囲内で実行を許可します。コードは権限を要求できますが、その要求は管理者が設定したセキュリティポリシーに基づいて受理されます。

メモ
CLR で実行されるコード自体に、アクセス許可を与えることはできません。たとえば、コードから要求できる権限は、セキュリティポリシーによって許可されたレベルよりも低い権限だけであり、それを超える権限が付与されることはありません。権限を付与する場合は、まず、権限をまったく付与しない状態から始め、その後で、実行しようとする特定のタスクに必要な最小限の権限を追加してゆくようにします。すべての権限を与えてから、不要なものを 1 つずつ拒否していく方法では、アプリケーションを危険にさらす結果となります。必要以上の権限を付与することによって意図しないセキュリティホールを招く可能性があります。詳細については、「セキュリティポリシーの設定」および「セキュリティポリシーの管理」を参照してください。

CLR で実行されるコード自体に、アクセス許可を与えることはできません。たとえば、コードから要求できる権限は、セキュリティポリシーによって許可されたレベルよりも低い権限だけであり、それを超える権限が付与されることはありません。権限を付与する場合は、まず、権限をまったく付与しない状態から始め、その後で、実行しようとする特定のタスクに必要な最小限の権限を追加してゆくようにします。すべての権限を与えてから、不要なものを 1 つずつ拒否していく方法では、アプリケーションを危険にさらす結果となります。必要以上の権限を付与することによって意図しないセキュリティホールを招く可能性があります。詳細については、「セキュリティポリシーの設定」および「セキュリティポリシーの管理」を参照してください。

コードのアクセス権限には、次の 3 種類があります。

Code access permissions。CodeAccessPermission クラスから派生します。ファイルや環境変数などの保護されたリソースにアクセスして、保護された操作 (アンマネージコードへのアクセスなど) を実行するには権限が必要です。
Identity permissions。アセンブリを識別する特性を表します。アセンブリには証拠に基づいて権限が付与されます。証拠には、デジタル署名やコードの作成元などの情報が含まれます。 ID 権限も CodeAccessPermission 基本クラスから派生します。
Role-based security permissions。プリンシパルが、指定された ID を持っているか、または、指定されたロールに属しているかどうかに基づきます。 PrincipalPermission クラスにより、アクティブなプリンシパルに対する宣言型および命令型の権限チェックが可能となります。

ランタイムのセキュリティシステムは、特定のリソースへのアクセスまたは特定の操作の実行がコードに許されているかどうかを判断するため、呼び出し履歴をたどりながら、各呼び出し元に付与されている権限と、要求されている権限とを比較します。呼び出し履歴に、要求された権限を持たない呼び出し元が 1 つでも見つかった場合、SecurityException がスローされてアクセスが拒否されます。

権限の要求

権限を要求する目的は、そのアプリケーションを実行するために必要な権限をランタイムに伝えると共に、実際に必要な権限以外は付与されないようにすることです。たとえば、ローカルディスクにデータを書き込むアプリケーションは FileIOPermission を必要とします。この権限が付与されていない場合、アプリケーションがディスクへの書き込みを試行した時点で実行に失敗します。ただし、アプリケーションから FileIOPermission を要求した場合、その権限が付与されなければ、最初の段階で例外が生成され、アプリケーションが読み込まれることはありません。

ディスクからのデータの読み取りだけを必要とするアプリケーションでは、書き込み権限が決して付与されないように要求できます。バグが存在していたり、悪意のある攻撃を受けたとしても、操作の対象となるデータに損害を与えることはありません。詳細については、「アクセス許可の要求」を参照してください。

ロールベースのセキュリティと CAS

ロールベースのセキュリティとコードアクセスセキュリティ (CAS) の両方を実装することで、アプリケーションの全体的なセキュリティを高めることができます。ロールベースのセキュリティには、Windows アカウントまたはカスタム ID を使用できます。セキュリティプリンシパルに関する情報には、現在のスレッドからアクセスできます。また、ユーザーによって指定された資格情報に基づいて、データやリソースへのアクセスを提供するアプリケーションも少なくありません。このようなアプリケーションは、通常、ユーザーのロールを調べ、そのロールに基づいてリソースへのアクセスを許可します。

ロールベースのセキュリティを使用することで、コンポーネントが、現在のユーザーおよびそのユーザーに関連付けられているロールを実行時に特定できるようになります。この情報を CAS ポリシーを使ってマッピングすることによって、一連の権限が実行時に判別されます。特定のアプリケーションドメインでは、ホストが既定のロールベースセキュリティポリシーを変更し、ユーザーおよびそのユーザーに関連付けられたロールを表す既定のセキュリティプリンシパルを設定できます。

CLR にはマネージコードに制限を適用するためのメカニズムが、権限を使用することによって実装されています。ロールベースのセキュリティ権限により、ユーザー (またはユーザーのために行動するエージェント) が特定の ID を持っているかどうか、または特定のロールに所属しているかどうかを検出するメカニズムが実現されます。詳細については、「アクセス許可」を参照してください。

開発しているアプリケーションの種類によっては、データベースに対するロールベースの権限の実装も考慮する必要があります。 SQL Server におけるロールベースのセキュリティの詳細については「SQL Server のセキュリティ (ADO.NET)」を参照してください。

アセンブリ

アセンブリは、.NET Framework アプリケーションの配置、バージョン管理、再利用、アクティベーションスコープ、およびセキュリティ権限の基本単位です。アセンブリは、互いに連携して動作するように作成された一連の型やリソースを提供し、"機能" の論理上の単位を成すものです。 CLR から見て、型がアセンブリのコンテキスト外に存在することはありません。アセンブリの作成と配置の詳細については、「アセンブリを使用したプログラミング」を参照してください。

厳密な名前付きアセンブリ

厳密な名前 (デジタル署名) は、アセンブリの ID (単純なテキスト名、バージョン番号、および使用可能な場合はカルチャ情報) と、公開キーおよびデジタル署名で構成されます。このデジタル署名は、対応する秘密キーを使用してアセンブリファイルから生成されます。アセンブリファイルにはアセンブリマニフェストが格納されており、そこに、アセンブリを構成するすべてのファイルの名前とハッシュが含まれます。

アセンブリに厳密な名前を付けることで、アプリケーションやコンポーネントに一意の ID が与えられます。他のソフトウェアは、その ID を使用することで、対応するアプリケーションまたはコンポーネントを明示的に参照できます。アセンブリに厳密な名前を付けると、悪意のあるコードを含むアセンブリのなりすましから保護することができます。また、異なるバージョンのコンポーネント間でバージョンの整合性をとることもできます。グローバルアセンブリキャッシュ (GAC) に展開されるアセンブリには、厳密な名前を付ける必要があります。詳細については、「厳密な名前付きアセンブリの作成と使用」を参照してください。

ADO.NET 2.0 での Partial Trust (部分信頼)

ADO.NET 2.0 では、.NET Framework Data Provider for SQL Server、.NET Framework Data Provider for OLE DB、.NET Framework Data Provider for ODBC、および .NET Framework Data Provider for Oracle のすべてが、部分的に信頼された環境でも実行できるようになりました。 .NET Framework の以前のリリースでは、信頼性のレベルが full-trust よりも低いアプリケーションでは System.Data.SqlClient のみがサポートされていました。

SQL Server プロバイダーを使用する部分的に信頼できるアプリケーションは、少なくとも、Execution アクセス許可と SqlClientPermission アクセス許可が必要です。

Partial Trust (部分信頼) のアクセス許可属性プロパティ

部分信頼のシナリオでは、SqlClientPermissionAttribute メンバーを使用して、.NET Framework Data Provider for SQL Server が使用できる機能をさらに制限することができます。

メモ
.NET Framework Data Provider for SQL Server では、SQL Server 2000 の SQL デバッグを有効にして SqlConnection を開くために Full Trust (完全信頼) セキュリティ権限が必要です。ただし、SQL Server 2005 の SQL デバッグでは、このクラスは使用しません。詳細については、SQL Server 2005 オンラインブックを参照してください。

使用可能な SqlClientPermissionAttribute プロパティとその説明を次の表に示します。

アクセス許可属性プロパティ	説明
Action	セキュリティアクションを取得または設定します。このプロパティは、SecurityAttribute から継承されています。
AllowBlankPassword	接続文字列内で空白のパスワードの使用を許可または禁止します。有効な値は、空白のパスワードの使用を許可する true および空白のパスワードの使用を禁止する false です。このプロパティは、DBDataPermissionAttribute から継承されています。
ConnectionString	使用できる接続文字列を指定します。複数の接続文字列を指定できます。メモ接続文字列には、ユーザー ID やパスワードを含めないでください。このリリースでは、.NET Framework 構成ツールを使用して接続文字列制限を変更することはできません。このプロパティは、DBDataPermissionAttribute から継承されています。
KeyRestrictions	許可または禁止する接続文字列パラメーターを指定します。接続文字列パラメーターは、<parameter name>= の形式で指定します。セミコロン (;) で区切って、複数のパラメーターを指定できます。メモ KeyRestrictions が指定されておらず、KeyRestrictionBehavior プロパティが AllowOnly または PreventUsage に設定されている場合は、接続文字列パラメーターを追加できません。このプロパティは、DBDataPermissionAttribute から継承されています。
KeyRestrictionBehavior	接続文字列パラメーターが、追加を許可された唯一の接続文字列パラメーター (AllowOnly) か、または追加を禁止された接続文字列パラメーター (PreventUsage) かを指定します。 AllowOnly が既定です。このプロパティは、DBDataPermissionAttribute から継承されています。
TypeID	派生クラスで実装すると、この属性の一意の識別子を取得します。このプロパティは、Attribute から継承されています。
Unrestricted	このリソースに対する無制限のアクセス許可が宣言されているかどうかを示します。このプロパティは、SecurityAttribute から継承されています。

ConnectionString の構文

次の例では、特定の接続文字列のみ使用できるようにするために、構成ファイルの connectionStrings 要素を使用する方法を示しています。構成ファイルからの接続文字列の格納および取得の詳細については、「接続文字列 (ADO.NET)」を参照してください。

<connectionStrings>
  <add name="DatabaseConnection" 
    connectionString="Data Source=(local);Initial 
    Catalog=Northwind;Integrated Security=true;" />
</connectionStrings>

KeyRestrictions の構文

上述の接続文字列の使用を許可し、Encrypt、Packet、Size 接続文字列オプションの使用も許可する一方で、その他の接続文字列オプションの使用を禁止する例を次に示します。

<connectionStrings>
  <add name="DatabaseConnection" 
    connectionString="Data Source=(local);Initial 
    Catalog=Northwind;Integrated Security=true;"
    KeyRestrictions="Encrypt=;Packet Size=;"
    KeyRestrictionBehavior="AllowOnly" />
</connectionStrings>

KeyRestrictionBehavior を PreventUsage に設定する場合の構文

上述の接続文字列の使用を許可し、User Id、Password、および Persist Security Info を除く他のすべての接続パラメーターを許可する例を次に示します。

<connectionStrings>
  <add name="DatabaseConnection" 
    connectionString="Data Source=(local);Initial 
    Catalog=Northwind;Integrated Security=true;"
    KeyRestrictions="User Id=;Password=;Persist Security Info=;"
    KeyRestrictionBehavior="PreventUsage" />
</connectionStrings>

KeyRestrictionBehavior を AllowOnly に設定する場合の構文

Initial Catalog、Connection Timeout、Encrypt、および Packet Size パラメーターも含まれる 2 つの接続文字列の使用を許可する例を次に示します。その他の接続文字列パラメーターは、すべて制限されます。

<connectionStrings>
  <add name="DatabaseConnection" 
    connectionString="Data Source=(local);Initial 
    Catalog=Northwind;Integrated Security=true;"
    KeyRestrictions="Initial Catalog;Connection Timeout=;
       Encrypt=;Packet Size=;" 
    KeyRestrictionBehavior="AllowOnly" />

  <add name="DatabaseConnection2" 
    connectionString="Data Source=SqlServer2;Initial 
    Catalog=Northwind2;Integrated Security=true;"
    KeyRestrictions="Initial Catalog;Connection Timeout=;
       Encrypt=;Packet Size=;" 
    KeyRestrictionBehavior="AllowOnly" />
</connectionStrings>

カスタムアクセス許可セットを使用した Partial Trust の有効化

特定のゾーンに対して System.Data.SqlClient アクセス許可を有効にするには、システム管理者がカスタムアクセス許可セットを作成して、目的のゾーンに指定する必要があります。 LocalIntranet などの既定のアクセス許可セットは変更できません。たとえば、Zone が LocalIntranet であるコードに System.Data.SqlClient アクセス許可をインクルードするには、システム管理者は LocalIntranet アクセス許可セットをコピーして名前を "CustomLocalIntranet" に変更し、System.Data.SqlClient アクセス許可を追加します。次に、Caspol.exe (コードアクセスセキュリティポリシーツール) を使用して CustomLocalIntranet アクセス許可セットをインポートし、LocalIntranet_Zone のアクセス許可セットを CustomLocalIntranet に設定します。

サンプルアクセス許可セット

部分信頼のシナリオでの、.NET Framework Data Provider for SQL Server 用アクセス許可セットの例を次に示します。カスタムアクセス許可セットを作成する方法の詳細については、「Caspol.exe によるアクセス許可セットの構成」を参照してください。

<PermissionSet class="System.Security.NamedPermissionSet"
  version="1"
  Name="CustomLocalIntranet"
  Description="Custom permission set given to applications on
    the local intranet">

<IPermission class="System.Data.SqlClient.SqlClientPermission, System.Data, Version=2.0.0000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1"
AllowBlankPassword="False">
<add ConnectionString="Data Source=(local);Integrated Security=true;"
 KeyRestrictions="Initial Catalog=;Connection Timeout=;
   Encrypt=;Packet Size=;" 
 KeyRestrictionBehavior="AllowOnly" />
 </IPermission>
</PermissionSet>

セキュリティアクセス許可を使用した ADO.NET コードアクセスの検証

部分信頼のシナリオでは、SqlClientPermissionAttribute を指定することによって、コード内の特定のメソッドに対する CAS 特権を要求できます。制限されたセキュリティポリシーによって、実際にはその特権が許可されていない場合は、そのコードを実行する前に例外がスローされます。セキュリティポリシーの詳細については、「セキュリティポリシーの管理」および「セキュリティポリシーの実施」を参照してください。

例

次のサンプルは、特定の接続文字列を必要とするコードの作成方法を示しています。このサンプルは、System.Data.SqlClient に対する無制限の権限を拒否する機能をシミュレートします。この機能は、実際には、システム管理者が、CAS ポリシーを使用して実装します。

セキュリティに関するメモ
ADO.NET の CAS 権限を定義する場合、最も制限の厳しいケース (権限なし) から開始し、その後で、コードが実行する特定のタスクに必要な特定の権限を追加するというのが、適切なパターンです。逆に、すべての権限を与えてから特定の権限を拒否してゆく方法は、安全ではありません。同じ接続文字列を表現する方法が多数あるためです。たとえば、すべての権限を与えた後で接続文字列 "server=someserver" の使用を拒否しても、"server=someserver.mycompany.com" という接続文字列は使用可能です。常に権限をまったく与えない状態から開始することで、権限セットのセキュリティホールを減らすことができます。

ADO.NET の CAS 権限を定義する場合、最も制限の厳しいケース (権限なし) から開始し、その後で、コードが実行する特定のタスクに必要な特定の権限を追加するというのが、適切なパターンです。逆に、すべての権限を与えてから特定の権限を拒否してゆく方法は、安全ではありません。同じ接続文字列を表現する方法が多数あるためです。たとえば、すべての権限を与えた後で接続文字列 "server=someserver" の使用を拒否しても、"server=someserver.mycompany.com" という接続文字列は使用可能です。常に権限をまったく与えない状態から開始することで、権限セットのセキュリティホールを減らすことができます。

SqlClient でセキュリティ確認要求を実行する方法を、次のコードに示します。CAS の権限が適切に設定されていない場合、SecurityException がスローされます。 SecurityException の出力は、コンソールウィンドウに表示されます。

Imports System
Imports System.Data
Imports System.Data.SqlClient
Imports System.Security
Imports System.Security.Permissions

Namespace PartialTrustTopic
   Public Class PartialTrustHelper
      Inherits MarshalByRefObject
      Public Sub TestConnectionOpen(ByVal connectionString As String)
         ' Try to open a connection.
         Using connection As New SqlConnection(connectionString)
            connection.Open()
         End Using
      End Sub
   End Class

   Class Program
      Public Shared Sub Main(ByVal args As String())
         TestCAS("Data Source=(local);Integrated Security=true", "Data Source=(local);Integrated Security=true;Initial Catalog=Test")
      End Sub

      Public Shared Sub TestCAS(ByVal connectString1 As String, ByVal connectString2 As String)
         ' Create permission set for sandbox AppDomain.
         ' This example only allows execution.
         Dim permissions As New PermissionSet(PermissionState.None)
         permissions.AddPermission(New SecurityPermission(SecurityPermissionFlag.Execution))

         ' Create sandbox AppDomain with permission set that only allows execution,
         ' and has no SqlClientPermissions.
         Dim appDomainSetup As New AppDomainSetup()
         appDomainSetup.ApplicationBase = AppDomain.CurrentDomain.SetupInformation.ApplicationBase
         Dim firstDomain As AppDomain = AppDomain.CreateDomain("NoSqlPermissions", Nothing, appDomainSetup, permissions)

         ' Create helper object in sandbox AppDomain so that code can be executed in that AppDomain.
         Dim helperType As Type = GetType(PartialTrustHelper)
         Dim firstHelper As PartialTrustHelper = DirectCast(firstDomain.CreateInstanceAndUnwrap(helperType.Assembly.FullName, helperType.FullName), PartialTrustHelper)

         Try
            ' Attempt to open a connection in the sandbox AppDomain.
            ' This is expected to fail.
            firstHelper.TestConnectionOpen(connectString1)
            Console.WriteLine("Connection opened, unexpected.")
         Catch ex As System.Security.SecurityException

            ' Uncomment the following line to see Exception details.
            ' Console.WriteLine("BaseException: " + ex.GetBaseException());
            Console.WriteLine("Failed, as expected: {0}", ex.FirstPermissionThatFailed)
         End Try

         ' Add permission for a specific connection string.
         Dim sqlPermission As New SqlClientPermission(PermissionState.None)
         sqlPermission.Add(connectString1, "", KeyRestrictionBehavior.AllowOnly)

         permissions.AddPermission(sqlPermission)

         Dim secondDomain As AppDomain = AppDomain.CreateDomain("OneSqlPermission", Nothing, appDomainSetup, permissions)
         Dim secondHelper As PartialTrustHelper = DirectCast(secondDomain.CreateInstanceAndUnwrap(helperType.Assembly.FullName, helperType.FullName), PartialTrustHelper)

         ' Try connection open again, it should succeed now.
         Try
            secondHelper.TestConnectionOpen(connectString1)
            Console.WriteLine("Connection opened, as expected.")
         Catch ex As System.Security.SecurityException
            Console.WriteLine("Unexpected failure: {0}", ex.Message)
         End Try

         ' Try a different connection string. This should fail.
         Try
            secondHelper.TestConnectionOpen(connectString2)
            Console.WriteLine("Connection opened, unexpected.")
         Catch ex As System.Security.SecurityException
            Console.WriteLine("Failed, as expected: {0}", ex.Message)
         End Try
      End Sub
   End Class
End Namespace

using System;
using System.Data;
using System.Data.SqlClient;
using System.Security;
using System.Security.Permissions;

namespace PartialTrustTopic {
   public class PartialTrustHelper : MarshalByRefObject {
      public void TestConnectionOpen(string connectionString) {
         // Try to open a connection.
         using (SqlConnection connection = new SqlConnection(connectionString)) {
            connection.Open();
         }
      }
   }

   class Program {
      static void Main(string[] args) {
         TestCAS("Data Source=(local);Integrated Security=true", "Data Source=(local);Integrated Security=true;Initial Catalog=Test");
      }

      static void TestCAS(string connectString1, string connectString2) {
         // Create permission set for sandbox AppDomain.
         // This example only allows execution.
         PermissionSet permissions = new PermissionSet(PermissionState.None);
         permissions.AddPermission(new SecurityPermission(SecurityPermissionFlag.Execution));

         // Create sandbox AppDomain with permission set that only allows execution,
         // and has no SqlClientPermissions.
         AppDomainSetup appDomainSetup = new AppDomainSetup();
         appDomainSetup.ApplicationBase = AppDomain.CurrentDomain.SetupInformation.ApplicationBase;
         AppDomain firstDomain = AppDomain.CreateDomain("NoSqlPermissions", null, appDomainSetup, permissions);

         // Create helper object in sandbox AppDomain so that code can be executed in that AppDomain.
         Type helperType = typeof(PartialTrustHelper);
         PartialTrustHelper firstHelper = (PartialTrustHelper)firstDomain.CreateInstanceAndUnwrap(helperType.Assembly.FullName, helperType.FullName);

         try {
            // Attempt to open a connection in the sandbox AppDomain.
            // This is expected to fail.
            firstHelper.TestConnectionOpen(connectString1);
            Console.WriteLine("Connection opened, unexpected.");
         }
         catch (System.Security.SecurityException ex) {
            Console.WriteLine("Failed, as expected: {0}",
                ex.FirstPermissionThatFailed);

            // Uncomment the following line to see Exception details.
            // Console.WriteLine("BaseException: " + ex.GetBaseException());
         }

         // Add permission for a specific connection string.
         SqlClientPermission sqlPermission = new SqlClientPermission(PermissionState.None);
         sqlPermission.Add(connectString1, "", KeyRestrictionBehavior.AllowOnly);

         permissions.AddPermission(sqlPermission);

         AppDomain secondDomain = AppDomain.CreateDomain("OneSqlPermission", null, appDomainSetup, permissions);
         PartialTrustHelper secondHelper = (PartialTrustHelper)secondDomain.CreateInstanceAndUnwrap(helperType.Assembly.FullName, helperType.FullName);

         // Try connection open again, it should succeed now.
         try {
            secondHelper.TestConnectionOpen(connectString1);
            Console.WriteLine("Connection opened, as expected.");
         }
         catch (System.Security.SecurityException ex) {
            Console.WriteLine("Unexpected failure: {0}", ex.Message);
         }

         // Try a different connection string. This should fail.
         try {
            secondHelper.TestConnectionOpen(connectString2);
            Console.WriteLine("Connection opened, unexpected.");
         }
         catch (System.Security.SecurityException ex) {
            Console.WriteLine("Failed, as expected: {0}", ex.Message);
         }
      }
   }
}

コンソールウィンドウに表示される出力の例を次に示します。

Failed, as expected: <IPermission class="System.Data.SqlClient.
SqlClientPermission, System.Data, Version=2.0.0.0, 
  Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1"
  AllowBlankPassword="False">
<add ConnectionString="Data Source=(local);Initial Catalog=
  Northwind;Integrated Security=SSPI" KeyRestrictions=""
KeyRestrictionBehavior="AllowOnly"/>
</IPermission>

Connection opened, as expected.
Failed, as expected: Request failed.

アンマネージコードとの相互運用性

CLR の外部で実行されるコードはアンマネージコードと呼ばれます。したがって、CAS などのセキュリティメカニズムをアンマネージコードに適用することはできません。アンマネージコードの例としては、COM コンポーネント、ActiveX インターフェイス、Win32 API 関数があります。アンマネージコードを実行する場合は、アプリケーションの全体的なセキュリティが損なわれないよう特別な考慮をする必要があります。詳細については、「アンマネージコードとの相互運用」を参照してください。

.NET Framework は、COM 相互運用機能を介したアクセスを提供することによって、既存の COM コンポーネントとの下位互換性をサポートしています。 COM 相互運用ツールを使って適切な COM 型をインポートすることにより、.NET Framework アプリケーションに COM コンポーネントを組み込むことができます。インポートが完了すると、COM 型を使用できるようになります。アセンブリのメタデータをタイプライブラリにエクスポートし、マネージコンポーネントを COM コンポーネントとして登録することで、COM クライアントからマネージコードにアクセスすることもできます。詳細については、「高度な COM 相互運用性」を参照してください。

参照

その他の技術情報

ADO.NET アプリケーションのセキュリティ保護

ネイティブコードと .NET Framework コードのセキュリティ

Code Access Security

Role-Based Security

コード アクセス セキュリティと ADO.NET