Zabezpieczenia dostępu kodu i ADO.NET

Artykuł
03/02/2024

Program .NET Framework oferuje zabezpieczenia oparte na rolach, a także zabezpieczenia dostępu do kodu (CAS), z których oba są implementowane przy użyciu wspólnej infrastruktury dostarczanej przez środowisko uruchomieniowe języka wspólnego (CLR). W świecie niezarządzanego kodu większość aplikacji jest wykonywana z uprawnieniami użytkownika lub podmiotu zabezpieczeń. W związku z tym systemy komputerowe mogą być uszkodzone, a dane prywatne zostały naruszone, gdy złośliwe lub wypełnione błędem oprogramowanie jest uruchamiane przez użytkownika z podwyższonym poziomem uprawnień.

Z kolei kod zarządzany wykonywany w programie .NET Framework obejmuje zabezpieczenia dostępu do kodu, które dotyczą samego kodu. Niezależnie od tego, czy kod może być uruchamiany, czy nie zależy od pochodzenia kodu, czy innych aspektów tożsamości kodu, a nie wyłącznie tożsamości podmiotu zabezpieczeń. Zmniejsza to prawdopodobieństwo nieprawidłowego użycia kodu zarządzanego.

Uwaga

Zabezpieczenia dostępu kodu (CAS) zostały wycofane we wszystkich wersjach programu .NET Framework i .NET. Najnowsze wersje platformy .NET nie honorują adnotacji CAS i generują błędy, jeśli są używane interfejsy API związane z usługą CAS. Deweloperzy powinni szukać alternatywnych sposobów wykonywania zadań zabezpieczeń.

Uprawnienia dostępu kodu

Po wykonaniu kodu przedstawia on dowody oceniane przez system zabezpieczeń CLR. Zazwyczaj ten dowód składa się z źródła kodu, w tym adresu URL, witryny i strefy oraz podpisów cyfrowych, które zapewniają tożsamość zestawu.

ClR umożliwia kodowi wykonywanie tylko tych operacji, do których kod ma uprawnienia do wykonania. Kod może żądać uprawnień, a żądania te są honorowane na podstawie zasad zabezpieczeń ustawionych przez administratora.

Uwaga

Kod wykonywany w środowisku CLR nie może udzielić uprawnień do samego siebie. Na przykład kod może zażądać i udzielić mniejszej liczby uprawnień niż zezwalają zasady zabezpieczeń, ale nigdy nie zostaną przyznane więcej uprawnień. Podczas udzielania uprawnień rozpocznij od braku uprawnień, a następnie dodaj najwęższe uprawnienia dla wykonywanego zadania. Począwszy od wszystkich uprawnień, a następnie odmawianie poszczególnych prowadzi do niezabezpieczonych aplikacji, które mogą zawierać niezamierzone otwory zabezpieczeń przed udzieleniem większej liczby uprawnień niż wymagane. Aby uzyskać więcej informacji, zobacz Konfigurowanie zasad zabezpieczeń i zarządzania zasadami zabezpieczeń.

Istnieją trzy typy uprawnień dostępu do kodu:

Code access permissions pochodzą z CodeAccessPermission klasy . Uprawnienia są wymagane w celu uzyskania dostępu do chronionych zasobów, takich jak pliki i zmienne środowiskowe, oraz do wykonywania chronionych operacji, takich jak uzyskiwanie dostępu do kodu niezarządzanych.
Identity permissions reprezentują cechy identyfikujące zestaw. Uprawnienia są przyznawane zestawowi na podstawie dowodów, które mogą zawierać elementy, takie jak podpis cyfrowy lub skąd pochodzi kod. Uprawnienia tożsamości pochodzą również z klasy bazowej CodeAccessPermission .
Role-based security permissions są oparte na tym, czy podmiot zabezpieczeń ma określoną tożsamość, czy jest członkiem określonej roli. Klasa PrincipalPermission umożliwia sprawdzanie uprawnień deklaratywnych i imperatywnych względem aktywnego podmiotu zabezpieczeń.

Aby określić, czy kod jest autoryzowany do uzyskiwania dostępu do zasobu, czy wykonywania operacji, system zabezpieczeń środowiska uruchomieniowego przechodzi przez stos wywołań, porównując przyznane uprawnienia każdego obiektu wywołującego do żądanego uprawnienia. Jeśli jakikolwiek obiekt wywołujący w stosie wywołań nie ma żądanego uprawnienia, zostanie zgłoszony, a SecurityException dostęp zostanie odrzucony.

Żądanie uprawnień

Celem żądania uprawnień jest informowanie środowiska uruchomieniowego o uprawnieniach wymaganych przez aplikację w celu uruchomienia i upewnienie się, że otrzymuje tylko uprawnienia, których faktycznie potrzebuje. Jeśli na przykład aplikacja musi zapisywać dane na dysku lokalnym, wymaga FileIOPermission. Jeśli to uprawnienie nie zostało przyznane, aplikacja zakończy się niepowodzeniem podczas próby zapisania na dysku. Jeśli jednak aplikacja żąda FileIOPermission i że uprawnienie nie zostało przyznane, aplikacja wygeneruje wyjątek na początku i nie zostanie załadowany.

W scenariuszu, w którym aplikacja musi tylko odczytywać dane z dysku, możesz zażądać, aby nigdy nie udzielono mu żadnych uprawnień do zapisu. W przypadku usterki lub złośliwego ataku kod nie może uszkodzić danych, na których działa. Aby uzyskać więcej informacji, zobacz Żądanie uprawnień.

Zabezpieczenia oparte na rolach i usługa CAS

Implementowanie zabezpieczeń opartych na rolach i zabezpieczeń z dostępem do kodu (CAS) zwiększa ogólne bezpieczeństwo aplikacji. Zabezpieczenia oparte na rolach mogą być oparte na koncie systemu Windows lub tożsamości niestandardowej, dzięki czemu informacje o podmiotu zabezpieczeń są dostępne dla bieżącego wątku. Ponadto aplikacje są często wymagane do zapewnienia dostępu do danych lub zasobów na podstawie poświadczeń dostarczonych przez użytkownika. Zazwyczaj takie aplikacje sprawdzają rolę użytkownika i zapewniają dostęp do zasobów na podstawie tych ról.

Zabezpieczenia oparte na rolach umożliwiają składnikowi identyfikowanie bieżących użytkowników i skojarzonych z nimi ról w czasie wykonywania. Te informacje są następnie mapowane przy użyciu zasad CAS w celu określenia zestawu uprawnień przyznanych w czasie wykonywania. W przypadku określonej domeny aplikacji host może zmienić domyślne zasady zabezpieczeń oparte na rolach i ustawić domyślny podmiot zabezpieczeń reprezentujący użytkownika i role skojarzone z tym użytkownikiem.

ClR używa uprawnień do implementowania mechanizmu wymuszania ograniczeń dotyczących kodu zarządzanego. Uprawnienia zabezpieczeń oparte na rolach zapewniają mechanizm wykrywania, czy użytkownik (lub agent działający w imieniu użytkownika) ma określoną tożsamość lub jest członkiem określonej roli. Aby uzyskać więcej informacji, zobacz Uprawnienia zabezpieczeń.

W zależności od typu tworzonej aplikacji należy również rozważyć zaimplementowanie uprawnień opartych na rolach w bazie danych. Aby uzyskać więcej informacji na temat zabezpieczeń opartych na rolach w programie SQL Server, zobacz Zabezpieczenia programu SQL Server.

Zestawy

Zestawy tworzą podstawową jednostkę wdrażania, kontroli wersji, ponownego użycia, określania zakresu aktywacji i uprawnień zabezpieczeń dla aplikacji .NET Framework. Zestaw udostępnia kolekcję typów i zasobów, które są tworzone do współpracy i tworzą jednostkę logiczną funkcji. W clR typ nie istnieje poza kontekstem zestawu. Aby uzyskać więcej informacji na temat tworzenia i wdrażania zestawów, zobacz Programowanie przy użyciu zestawów.

Zestawy o silnych nazwach

Silna nazwa lub podpis cyfrowy składa się z tożsamości zestawu, która zawiera jego prostą nazwę tekstową, numer wersji i informacje o kulturze (jeśli podano) oraz klucz publiczny i podpis cyfrowy. Podpis cyfrowy jest generowany na podstawie pliku zestawu przy użyciu odpowiedniego klucza prywatnego. Plik zestawu zawiera manifest zestawu, który zawiera nazwy i skróty wszystkich plików tworzących zestaw.

Silne nazewnictwo zestawu daje aplikacji lub składnikowi unikatową tożsamość, która może być używana przez inne oprogramowanie w celu jawnego odwoływania się do niego. Silne nazewnictwo chroni zestawy przed fałszowaniem przez zestaw, który zawiera wrogi kod. Silne nazewnictwo zapewnia również spójność wersji między różnymi wersjami składnika. Zestawy o silnej nazwie, które zostaną wdrożone w globalnej pamięci podręcznej zestawów (GAC). Aby uzyskać więcej informacji, zobacz Tworzenie i używanie zestawów o silnych nazwach.

Częściowe zaufanie w ADO.NET 2.0

W ADO.NET 2.0 program .NET Framework Dostawca danych dla programu SQL Server, Dostawca danych .NET Framework dla OLE DB, Dostawca danych programu .NET Framework dla ODBC i platformy .NET Framework Dostawca danych dla programu Oracle mogą teraz działać w częściowo zaufanych środowiskach. W poprzednich wersjach programu .NET Framework obsługiwana była tylko System.Data.SqlClient w aplikacjach o pełnym zaufaniu.

Co najmniej częściowo zaufana aplikacja korzystająca z dostawcy programu SQL Server musi mieć uprawnienia i SqlClientPermission wykonywanie.

Właściwości atrybutu uprawnień dla częściowego zaufania

W przypadku scenariuszy częściowego zaufania można użyć SqlClientPermissionAttribute członków, aby dodatkowo ograniczyć możliwości dostępne dla programu .NET Framework Dostawca danych dla programu SQL Server.

W poniższej tabeli wymieniono dostępne SqlClientPermissionAttribute właściwości i ich opisy:

Właściwość atrybutu uprawnień	opis
`Action`	Pobiera lub ustawia akcję zabezpieczeń. Dziedziczone z SecurityAttributeelementu .
`AllowBlankPassword`	Włącza lub wyłącza użycie pustego hasła w parametry połączenia. Prawidłowe wartości to `true` (aby włączyć używanie pustych haseł) i `false` (aby wyłączyć używanie pustych haseł). Dziedziczone z DBDataPermissionAttributeelementu .
`ConnectionString`	Identyfikuje dozwolone parametry połączenia. Można zidentyfikować wiele parametry połączenia. Uwaga: nie dołączaj identyfikatora użytkownika ani hasła do parametry połączenia. W tej wersji nie można zmienić parametry połączenia ograniczeń przy użyciu narzędzia konfiguracji programu .NET Framework. Dziedziczone z DBDataPermissionAttributeelementu .
`KeyRestrictions`	Identyfikuje parametry połączenia parametrów, które są dozwolone lub niedozwolone. parametry ciągu Połączenie ion są identyfikowane w formularzu <>nazwa parametru=. Można określić wiele parametrów rozdzielonych średnikami (;). Uwaga: jeśli nie określisz `KeyRestrictions`parametru , ale dla właściwości ustawiono `KeyRestrictionBehavior` wartość `AllowOnly` lub `PreventUsage`, nie są dozwolone żadne dodatkowe parametry parametry połączenia. Dziedziczone z DBDataPermissionAttributeelementu .
`KeyRestrictionBehavior`	Identyfikuje parametry parametry połączenia jako jedyne dozwolone dodatkowe parametry (`AllowOnly`) lub identyfikuje dodatkowe parametry, które nie są dozwolone (`PreventUsage`). Wartość domyślna to `AllowOnly`. Dziedziczone z DBDataPermissionAttributeelementu .
`TypeID`	Pobiera unikatowy identyfikator tego atrybutu po zaimplementowaniu w klasie pochodnej. Dziedziczone z Attributeelementu .
`Unrestricted`	Wskazuje, czy zadeklarowane jest nieograniczone uprawnienie do zasobu. Dziedziczone z SecurityAttributeelementu .

składnia Połączenie ionString

W poniższym przykładzie pokazano, jak używać connectionStrings elementu pliku konfiguracji, aby umożliwić używanie tylko określonego parametry połączenia. Aby uzyskać więcej informacji na temat przechowywania i pobierania parametry połączenia z plików konfiguracji, zobacz ciągi Połączenie ion.

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

Składnia keyRestrictions

Poniższy przykład umożliwia korzystanie z tych samych parametry połączenia, umożliwia korzystanie z Encrypt opcji i Packet Size parametry połączenia, ale ogranicza użycie innych opcji parametry połączenia.

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

KeyRestrictionBehavior ze składnią PreventUsage

W poniższym przykładzie jest włączona ta sama parametry połączenia i zezwala na wszystkie inne parametry połączenia z wyjątkiem User Idparametrów i PasswordPersist 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 ze składnią AllowOnly

W poniższym przykładzie są włączone dwa parametry połączenia zawierające również Initial Catalogparametry , Connection Timeout, Encrypti Packet Size . Wszystkie inne parametry parametry połączenia są ograniczone.

<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>

Włączanie częściowego zaufania za pomocą niestandardowego zestawu uprawnień

Aby umożliwić korzystanie z System.Data.SqlClient uprawnień dla określonej strefy, administrator systemu musi utworzyć niestandardowy zestaw uprawnień i ustawić go jako zestaw uprawnień dla określonej strefy. Nie można modyfikować domyślnych zestawów uprawnień, takich jak LocalIntranet, . Na przykład aby uwzględnić System.Data.SqlClient uprawnienia do kodu z ZoneLocalIntranetwartością , administrator systemu może skopiować zestaw LocalIntranetuprawnień dla , zmienić jego nazwę na "CustomLocalIntranet", dodać System.Data.SqlClient uprawnienia, zaimportować zestaw uprawnień CustomLocalIntranet przy użyciu Caspol.exe (narzędzie zasad zabezpieczeń dostępu kodu) i ustawić zestaw LocalIntranet_Zone uprawnień na CustomLocalIntranet.

Przykładowy zestaw uprawnień

Poniżej przedstawiono przykładowy zestaw uprawnień dla programu .NET Framework Dostawca danych dla programu SQL Server w częściowo zaufanym scenariuszu. Aby uzyskać informacje na temat tworzenia niestandardowych zestawów uprawnień, zobacz Konfigurowanie zestawów uprawnień przy użyciu 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>

Weryfikowanie dostępu ADO.NET kodu przy użyciu uprawnień zabezpieczeń

W przypadku scenariuszy częściowego zaufania można wymagać uprawnień cas dla określonych metod w kodzie, określając SqlClientPermissionAttributeelement . Jeśli to uprawnienie nie jest dozwolone przez zasady zabezpieczeń z ograniczeniami, zostanie zgłoszony wyjątek przed uruchomieniem kodu. Aby uzyskać więcej informacji na temat zasad zabezpieczeń, zobacz Security Policy Management and Security Policy Best Practices (Najlepsze rozwiązania dotyczące zarządzania zasadami zabezpieczeń i zabezpieczeń).

Przykład

W poniższym przykładzie pokazano, jak napisać kod, który wymaga określonego parametry połączenia. Symuluje odmawianie nieograniczonych uprawnień do System.Data.SqlClientprogramu , które administrator systemu implementuje przy użyciu zasad CAS w świecie rzeczywistym.

Ważne

Podczas projektowania uprawnień cas dla ADO.NET prawidłowym wzorcem jest rozpoczęcie od najbardziej restrykcyjnego przypadku (brak uprawnień w ogóle), a następnie dodanie określonych uprawnień wymaganych do określonego zadania, które musi wykonać kod. Odwrotny wzorzec, zaczynając od wszystkich uprawnień, a następnie odmawiający określonego uprawnienia, nie jest bezpieczny, ponieważ istnieje wiele sposobów wyrażania tego samego parametry połączenia. Jeśli na przykład zaczniesz od wszystkich uprawnień, a następnie spróbujesz odrzucić użycie parametry połączenia "server=someserver", ciąg "server=someserver.mycompany.com" będzie nadal dozwolony. Zawsze zaczynając od przyznania żadnych uprawnień, można zmniejszyć prawdopodobieństwo, że w zestawie uprawnień znajdują się otwory.

Poniższy kod pokazuje, jak SqlClient działa żądanie zabezpieczeń, co zgłasza, SecurityException jeśli odpowiednie uprawnienia CAS nie są spełnione. Dane SecurityException wyjściowe są wyświetlane w oknie konsoli.

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);
         }
      }
   }
}

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

Te dane wyjściowe powinny zostać wyświetlone w oknie Konsola:

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.

Współdziałanie z kodem niezarządzanymi

Kod uruchamiany poza środowiskiem CLR jest nazywany kodem niezarządzanych. W związku z tym do niezarządzanych kodu nie można zastosować mechanizmów zabezpieczeń, takich jak CAS. Składniki modelu COM, interfejsy ActiveX i funkcje interfejsu API systemu Windows to przykłady kodu niezarządzanego. Specjalne zagadnienia dotyczące zabezpieczeń mają zastosowanie podczas wykonywania niezarządzanych kodów, aby nie zagrażać ogólnym bezpieczeństwu aplikacji. Aby uzyskać więcej informacji, zobacz Interoperating with Unmanaged Code (Współdziałanie z niezarządzanymi kodami).

Program .NET Framework obsługuje również zgodność z poprzednimi wersjami istniejących składników COM, zapewniając dostęp za pośrednictwem międzyoperacjności modelu COM. Składniki MODELU COM można dołączyć do aplikacji .NET Framework przy użyciu narzędzi międzyoperajowych MODELU COM w celu zaimportowania odpowiednich typów MODELU COM. Po zaimportowaniu typy COM są gotowe do użycia. Międzyoperacyjna modelu COM umożliwia również klientom MODELU COM dostęp do kodu zarządzanego przez wyeksportowanie metadanych zestawu do biblioteki typów i zarejestrowanie składnika zarządzanego jako składnika COM. Aby uzyskać więcej informacji, zobacz Advanced COM Interoperability (Zaawansowane współdziałanie modelu COM).