Udostępnij za pośrednictwem

Zabezpieczenia dostępu kodu i ADO.NET

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 kodu niezarządzanego większość aplikacji jest wykonywana z uprawnieniami użytkownika lub konta. 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. pl-PL: Niezależnie od tego, czy kod może być uruchamiany, zależy od pochodzenia kodu lub innych aspektów jego tożsamości, a nie wyłącznie tożsamości głównego podmiotu. 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 do kodu

Po wykonaniu kodu przedstawia on dowody oceniane przez system zabezpieczeń CLR. Zazwyczaj ten dowód składa się ze źródła kodu, w tym adresu URL, witryny i strefy, oraz podpisów cyfrowych, które potwierdzają 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. Zaczynając od przyznania wszystkich uprawnień, a następnie stopniowego odmawiania poszczególnych, prowadzi do powstania niezabezpieczonych aplikacji, które mogą zawierać niezamierzone luki bezpieczeństwa z powodu przyznania 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 zgromadzeniu na podstawie dowodów, takich jak podpis cyfrowy lub pochodzenie kodu. Uprawnienia tożsamości pochodzą również z klasy bazowej CodeAccessPermission .
  • Role-based security permissions opierają się na tym, czy podmiot ma określoną tożsamość lub jest członkiem określonej roli. Klasa PrincipalPermission umożliwia sprawdzanie uprawnień deklaratywnych i imperatywnych względem aktywnego podmiotu.

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 rzucony SecurityException i dostęp zostanie odrzucony.

Zażądaj 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 to uprawnienie nie zostało przyznane, aplikacja wygeneruje wyjątek na początku i nie zostanie załadowana.

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ą bazować na koncie Windows lub tożsamości niestandardowej, co sprawia, że informacje o podmiocie 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 dotyczące 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.

Zgromadzenia

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, obejmującej jego prostą nazwę tekstową, numer wersji, informacje o kulturze (jeśli podano), a także klucz publiczny i podpis cyfrowy. Podpis cyfrowy jest generowany na podstawie pliku zestawienia 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. Musisz nadać zestawom silną nazwę, które zostaną wdrożone do 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, Dostawca danych .NET Framework dla SQL Server, Dostawca danych .NET Framework dla OLE DB, Dostawca danych .NET Framework dla ODBC i Dostawca danych .NET Framework dla Oracle mogą teraz działać w częściowo zaufanych środowiskach. W poprzednich wersjach programu .NET Framework tylko System.Data.SqlClient była obsługiwana w aplikacjach o mniejszym niż pełne zaufaniu.

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

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

W przypadku scenariuszy częściowego zaufania można użyć elementów SqlClientPermissionAttribute, aby dodatkowo ograniczyć możliwości dostępne dla dostawcy danych .NET Framework 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 elementu SecurityAttribute.
AllowBlankPassword Włącza lub wyłącza użycie pustego hasła w łańcuchu 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 elementu DBDataPermissionAttribute.
ConnectionString Identyfikuje dozwolone parametry połączenia. Można zidentyfikować wiele ciągów połączeń. Uwaga: nie dołączaj identyfikatora użytkownika ani hasła do parametry połączenia. W tej wersji nie można zmienić ograniczeń ciągów połączeń przy użyciu narzędzia konfiguracji programu .NET Framework.

Dziedziczone z elementu DBDataPermissionAttribute.
KeyRestrictions Identyfikuje parametry łańcucha połączenia, które są dozwolone lub niedozwolone. Parametry połączenia są identyfikowane w formie <nazwa parametru>=. Można określić wiele parametrów rozdzielonych średnikami (;). Uwaga: jeśli nie określisz parametru KeyRestrictions, ale ustawisz właściwość KeyRestrictionBehavior na AllowOnly lub PreventUsage, nie są dozwolone żadne dodatkowe parametry połączenia. Dziedziczone z elementu DBDataPermissionAttribute.
KeyRestrictionBehavior Identyfikuje parametry połączenia jako jedyne dozwolone dodatkowe parametry (AllowOnly) lub wskazuje dodatkowe parametry, które są niedozwolone (PreventUsage). Wartość domyślna to AllowOnly. Dziedziczone z elementu DBDataPermissionAttribute.
TypeID Pobiera unikatowy identyfikator tego atrybutu po zaimplementowaniu w klasie pochodnej. Dziedziczone z elementu Attribute.
Unrestricted Wskazuje, czy zadeklarowane jest nieograniczone uprawnienie do zasobu. Dziedziczone z elementu SecurityAttribute.

Składnia ConnectionString

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 Parametry połączenia.

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

Ważne

Firma Microsoft zaleca korzystanie z najbezpieczniejszego dostępnego przepływu uwierzytelniania. Jeśli łączysz się z usługą Azure SQL, tożsamości zarządzane dla zasobów platformy Azure to zalecana metoda uwierzytelniania.

Składnia ograniczeń kluczowych

Poniższy przykład umożliwia korzystanie z tej samej konfiguracji połączenia, pozwala na użycie opcji Encrypt i Packet Size w parametrach połączenia, ale ogranicza użycie jakichkolwiek innych opcji konfiguracji połączenia.

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

Ważne

Firma Microsoft zaleca korzystanie z najbezpieczniejszego dostępnego przepływu uwierzytelniania. Jeśli łączysz się z usługą Azure SQL, tożsamości zarządzane dla zasobów platformy Azure to zalecana metoda uwierzytelniania.

KeyRestrictionBehavior ze składnią PreventUsage

W poniższym przykładzie jest używany ten sam parametry połączenia i zezwala się na wszystkie inne parametry połączenia z wyjątkiem User Id, Password i 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>

Ważne

Firma Microsoft zaleca korzystanie z najbezpieczniejszego dostępnego przepływu uwierzytelniania. Jeśli łączysz się z usługą Azure SQL, tożsamości zarządzane dla zasobów platformy Azure to zalecana metoda uwierzytelniania.

KeyRestrictionBehavior ze składnią AllowOnly

W poniższym przykładzie są włączone dwa ciągi połączenia, które zawierają również parametry Initial Catalog, Connection Timeout, Encrypt i Packet Size. Wszystkie inne 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>

Ważne

Firma Microsoft zaleca korzystanie z najbezpieczniejszego dostępnego przepływu uwierzytelniania. Jeśli łączysz się z usługą Azure SQL, tożsamości zarządzane dla zasobów platformy Azure to zalecana metoda uwierzytelniania.

Włącz częściowe zaufanie z niestandardowym zestawem 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, który ma Zone o LocalIntranet, administrator systemu może skopiować zestaw uprawnień LocalIntranet, zmienić jego nazwę na "CustomLocalIntranet", dodać uprawnienia System.Data.SqlClient, zaimportować zestaw uprawnień CustomLocalIntranet przy użyciu Caspol.exe (narzędzie zasad zabezpieczeń dostępu kodu) i ustawić zestaw uprawnień LocalIntranet_Zone na CustomLocalIntranet.

Przykładowy zestaw uprawnień

Poniżej przedstawiono przykładowy zestaw uprawnień dla dostawcy danych .NET Framework dla 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>

Ważne

Firma Microsoft zaleca korzystanie z najbezpieczniejszego dostępnego przepływu uwierzytelniania. Jeśli łączysz się z usługą Azure SQL, tożsamości zarządzane dla zasobów platformy Azure to zalecana metoda uwierzytelniania.

Weryfikowanie dostępu do kodu ADO.NET przy pomocy uprawnień zabezpieczeń

pl-PL: W przypadku scenariuszy częściowego zaufania można wymagać uprawnień CAS dla określonych metod w kodzie, określając SqlClientPermissionAttribute element. Jeśli to uprawnienie nie jest dozwolone przez obowiązujące polityki restrykcji bezpieczeństwa, 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 ciągu połączenia. Symuluje odmawianie nieograniczonych uprawnień do System.Data.SqlClient, co jest implementowane przez administratora systemu 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 ciągu 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. Jeśli zawsze zaczynasz od tego, by nie przyznawać żadnych uprawnień, tym samym zmniejszasz prawdopodobieństwo, że w zestawie uprawnień powstaną luki.

Poniższy kod pokazuje, jak SqlClient wykonuje żądanie zabezpieczeń, co wywoła 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("secure-connnection-string1", "secure-connnection-string2");
      }

      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: {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.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.

Ważne

Firma Microsoft zaleca korzystanie z najbezpieczniejszego dostępnego przepływu uwierzytelniania. Jeśli łączysz się z usługą Azure SQL, tożsamości zarządzane dla zasobów platformy Azure to zalecana metoda uwierzytelniania.

Współdziałanie z kodem niezarządzanym

Kod uruchamiany poza środowiskiem CLR jest nazywany kodem niezarządzanym. 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ż kompatybilność wsteczną z istniejącymi składnikami COM, zapewniając dostęp za pośrednictwem interop COM. Składniki COM można dołączyć do aplikacji .NET Framework przy użyciu narzędzi międzyoperacyjnych COM w celu zaimportowania odpowiednich typów COM. Po zaimportowaniu typy COM są gotowe do użycia. Obsługa międzyoperacyjności dla COM umożliwia klientom COM dostęp do kodu zarządzanego poprzez eksportowanie metadanych zestawu do biblioteki typów i rejestrowanie zarządzanego składnika jako składnika COM. Aby uzyskać więcej informacji, zobacz Advanced COM Interoperability (Zaawansowane współdziałanie modelu COM).

Zobacz też