Megosztás a következőn keresztül:

Kódhozzáférés biztonsága és ADO.NET

  • Cikk

.NET-keretrendszer szerepköralapú biztonságot és kódhozzáférési biztonságot (CAS) kínál, amelyek mindegyike a közös nyelvi futtatókörnyezet (CLR) által biztosított közös infrastruktúra használatával valósul meg. A nem felügyelt kód világában a legtöbb alkalmazás a felhasználó vagy az egyszerű felhasználó engedélyeivel fut. Ennek eredményeképpen a számítógépes rendszerek megsérülhetnek, és a személyes adatok sérülhetnek, ha a rosszindulatú vagy hiba által kitöltött szoftvereket emelt szintű jogosultságokkal rendelkező felhasználó futtatja.

Ezzel szemben az .NET-keretrendszer felügyelt kód végrehajtása magában foglalja a kódhozzáférés biztonságát, amely csak a kódra vonatkozik. Az, hogy a kód futtatható-e vagy sem, a kód eredetétől vagy a kód identitásának egyéb aspektusaitól függ, nem csak a rendszerbiztonsági tag identitásától. Ez csökkenti annak a valószínűségét, hogy a felügyelt kód visszaélhet.

Feljegyzés

A Code Access Security (CAS) elavult a .NET-keretrendszer és a .NET összes verziójában. A .NET legújabb verziói nem tartják tiszteletben a CAS-megjegyzéseket, és cas-okkal kapcsolatos API-k használata esetén hibákat okoznak. A fejlesztőknek alternatív módot kell keresnie a biztonsági feladatok elvégzésére.

Kódhozzáférés engedélyei

A kód végrehajtásakor a CLR biztonsági rendszer által kiértékelt bizonyítékokat jelenít meg. Ez a bizonyíték általában a kód eredetét tartalmazza, beleértve az URL-címet, a helyet és a zónát, valamint a szerelvény identitását biztosító digitális aláírásokat.

A CLR lehetővé teszi, hogy a kód csak azokat a műveleteket hajtsa végre, amelyekre a kód engedéllyel rendelkezik. A kód engedélyeket kérhet, és ezeket a kéréseket a rendszergazda által beállított biztonsági szabályzat alapján tartják be.

Feljegyzés

A CLR-ben végrehajtó kód nem adhat engedélyt magának. A kód például kevesebb engedélyt kérhet és kaphat, mint amennyit egy biztonsági szabályzat megenged, de soha nem kap több engedélyt. Engedélyek megadásakor kezdjen egyáltalán nem engedélyekkel, majd adja hozzá a legszűkebb engedélyeket az éppen végrehajtott tevékenységhez. Az összes engedélytől kezdve az egyes engedélyek megtagadásán át az olyan nem biztonságos alkalmazásokhoz vezetnek, amelyek nem szándékos biztonsági lyukakat tartalmazhatnak a szükségesnél több engedély megadásától. További információ: A biztonsági házirend és a biztonsági házirend kezelése konfigurálása.

A kódhozzáférésnek három típusa van:

  • Code access permissions származik az CodeAccessPermission osztályból. Engedélyekre van szükség a védett erőforrások, például a fájlok és a környezeti változók eléréséhez, valamint a védett műveletek végrehajtásához, például a nem felügyelt kód eléréséhez.
  • Identity permissions olyan jellemzőket jelölnek, amelyek azonosítják a szerelvényt. Az engedélyeket bizonyíték alapján adják meg egy szerelvénynek, amely tartalmazhat olyan elemeket, mint a digitális aláírás vagy a kód eredete. Az identitásengedélyek az CodeAccessPermission alaposztályból is származnak.
  • Role-based security permissions azon alapulnak, hogy egy tag rendelkezik-e meghatározott identitással, vagy egy adott szerepkör tagja. Az PrincipalPermission osztály lehetővé teszi a deklaratív és az imperatív engedély ellenőrzését az aktív tagon.

Annak megállapításához, hogy a kód jogosult-e egy erőforrás elérésére vagy egy művelet végrehajtására, a futtatókörnyezet biztonsági rendszere áthalad a hívásveremen, összehasonlítva az egyes hívók megadott engedélyeit az igényelt engedélyekkel. Ha a hívásverem bármely hívója nem rendelkezik az igényelt engedéllyel, a hívás ki lesz dobva, SecurityException és a hozzáférés megtagadva.

Engedélyek kérése

Az engedélyek kérésének célja, hogy tájékoztassa a futtatókörnyezetet arról, hogy az alkalmazás milyen engedélyeket igényel a futtatáshoz, és hogy csak azokat az engedélyeket kapja meg, amelyekre ténylegesen szüksége van. Ha például az alkalmazásnak adatokat kell írnia a helyi lemezre, szüksége van FileIOPermissionrá. Ha ez az engedély nem lett megadva, az alkalmazás sikertelen lesz, amikor megpróbál írni a lemezre. Ha azonban az alkalmazás kéri FileIOPermission , és az engedély nem lett megadva, az alkalmazás a kivételt a kezdetkor generálja, és nem töltődik be.

Olyan esetekben, amikor az alkalmazásnak csak a lemezről kell adatokat olvasnia, kérheti, hogy soha ne adjon meg írási engedélyeket. Hiba vagy rosszindulatú támadás esetén a kód nem károsíthatja azokat az adatokat, amelyeken működik. További információ: Engedélyek kérése.

Szerepköralapú biztonság és CAS

A szerepköralapú biztonság és a kód által elért biztonság (CAS) implementálása növeli az alkalmazás általános biztonságát. A szerepköralapú biztonság alapja lehet Egy Windows-fiók vagy egy egyéni identitás, amely az aktuális szál számára elérhetővé teszi a biztonsági tagra vonatkozó információkat. Emellett az alkalmazásokra gyakran szükség van ahhoz, hogy a felhasználó által megadott hitelesítő adatok alapján hozzáférést biztosítsanak az adatokhoz vagy erőforrásokhoz. Az ilyen alkalmazások általában ellenőrzik a felhasználó szerepkörét, és ezen szerepkörök alapján biztosítanak hozzáférést az erőforrásokhoz.

A szerepköralapú biztonság lehetővé teszi, hogy egy összetevő futásidőben azonosítsa az aktuális felhasználókat és a hozzájuk tartozó szerepköröket. Ez az információ ezután cas-szabályzattal van leképezve a futtatáskor megadott engedélyek halmazának meghatározásához. Egy megadott alkalmazástartomány esetében a gazdagép módosíthatja az alapértelmezett szerepköralapú biztonsági szabályzatot, és beállíthat egy alapértelmezett biztonsági tagot, amely a felhasználót és a felhasználóhoz társított szerepköröket jelöli.

A CLR engedélyeket használ a felügyelt kódra vonatkozó korlátozások kikényszerítésére szolgáló mechanizmus implementálásához. A szerepköralapú biztonsági engedélyek mechanizmust biztosítanak annak felderítésére, hogy egy felhasználó (vagy a felhasználó nevében eljáró ügynök) rendelkezik-e egy adott identitással, vagy egy adott szerepkör tagja. További információ: Biztonsági engedélyek.

A létrehozott alkalmazás típusától függően érdemes lehet szerepköralapú engedélyeket is implementálni az adatbázisban. További információ az SQL Server szerepköralapú biztonságáról: SQL Server Security.

Szerelvények

A szerelvények alkotják az üzembe helyezés, a verziókövetés, az újrafelhasználás, az aktiválás hatókörkezelése és a biztonsági engedélyek alapvető egységét egy .NET-keretrendszer alkalmazáshoz. A szerelvény olyan típusok és erőforrások gyűjteményét biztosítja, amelyek az együttműködésre és a logikai funkcióegységek kialakítására épülnek. A CLR-ben egy típus nem létezik a szerelvény környezetén kívül. A szerelvények létrehozásával és üzembe helyezésével kapcsolatos további információkért lásd : Programming with Assemblies.

Erős névvel ellátott szerelvények

Az erős név vagy digitális aláírás a szerelvény identitásából áll, amely magában foglalja az egyszerű szöveges nevét, verziószámát és kulturális adatait (ha van ilyen), valamint egy nyilvános kulcsot és egy digitális aláírást. A digitális aláírás egy szerelvényfájlból jön létre a megfelelő titkos kulcs használatával. A szerelvényfájl tartalmazza a szerelvényjegyzéket, amely tartalmazza a szerelvényt alkotó összes fájl nevét és kivonatát.

A szerelvény erős elnevezése egyedi identitást ad egy alkalmazásnak vagy összetevőnek, amelyet más szoftverek explicit módon használhatnak. Erős elnevezési őrök gyülekeznek ellen, hogy meghamisítása egy szerelvény, amely tartalmaz ellenséges kódot. Az erős elnevezés biztosítja az összetevők különböző verziói közötti verziószámozás konzisztenciáját is. A globális szerelvény-gyorsítótárban (GAC) üzembe helyezendő erős névszerelvényeknek kell lenniük. További információ: Erős névvel ellátott szerelvények létrehozása és használata.

Részleges megbízhatóság a 2.0-s ADO.NET

A ADO.NET 2.0-ban az SQL Server .NET-keretrendszer adatszolgáltatója, az OLE DB .NET-keretrendszer adatszolgáltatója, az ODBC .NET-keretrendszer adatszolgáltatója és az Oracle .NET-keretrendszer adatszolgáltatója mostantól mind részben megbízható környezetben futtatható. A .NET-keretrendszer korábbi kiadásaiban csak System.Data.SqlClient a teljes megbízhatóságú alkalmazások támogatták.

Az SQL Server-szolgáltatót használó, részben megbízható alkalmazásoknak legalább végrehajtással és SqlClientPermission engedélyekkel kell rendelkezniük.

Részleges megbízhatóság engedélyattribútum-tulajdonságai

Részleges megbízhatósági forgatókönyvek esetén a tagok segítségével SqlClientPermissionAttribute tovább korlátozhatja az SQL Server .NET-keretrendszer adatszolgáltatója számára elérhető képességeket.

Az alábbi táblázat az elérhető SqlClientPermissionAttribute tulajdonságokat és azok leírását sorolja fel:

Engedélyattribútum tulajdonság Leírás
Action Biztonsági műveletet hajt végre vagy állít be. Öröklődve innen SecurityAttribute: .
AllowBlankPassword Engedélyezi vagy letiltja az üres jelszó használatát egy kapcsolati sztring. Az érvényes értékek true (az üres jelszavak használatának engedélyezéséhez) és false (az üres jelszavak használatának letiltásához) érvényesek. Öröklődve innen DBDataPermissionAttribute: .
ConnectionString Egy engedélyezett kapcsolati sztring azonosít. Több kapcsolati sztring is azonosítható. Megjegyzés: Ne adjon meg felhasználói azonosítót vagy jelszót a kapcsolati sztring. Ebben a kiadásban a .NET-keretrendszer konfigurációs eszközzel nem módosíthatja kapcsolati sztring korlátozásokat.

Öröklődve innen DBDataPermissionAttribute: .
KeyRestrictions Azonosítja kapcsolati sztring engedélyezett vagy nem engedélyezett paramétereket. A kapcsolati sztring paramétereit az űrlapparaméter <neve>= azonosítja. Több paraméter is megadható pontosvesszővel (;). Megjegyzés: Ha nem adja meg a tulajdonságot, de a tulajdonságot AllowOnly nem adja megKeyRestrictionsKeyRestrictionBehavior, akkor PreventUsagenem engedélyezett további kapcsolati sztring paraméterek használata. Öröklődve innen DBDataPermissionAttribute: .
KeyRestrictionBehavior A kapcsolati sztring paramétereket azonosítja az egyetlen engedélyezett további paraméterként (AllowOnly), vagy azonosítja a nem engedélyezett (PreventUsage) további paramétereket. A AllowOnly az alapértelmezett formátum. Öröklődve innen DBDataPermissionAttribute: .
TypeID Egy származtatott osztályban való implementáláskor egyedi azonosítót kap ehhez az attribútumhoz. Öröklődve innen Attribute: .
Unrestricted Azt jelzi, hogy az erőforrásra vonatkozó korlátlan engedély deklarálva van-e. Öröklődve innen SecurityAttribute: .

ConnectionString szintaxis

Az alábbi példa bemutatja, hogyan használhatja a connectionStrings konfigurációs fájl elemét, hogy csak egy adott kapcsolati sztring lehessen használni. A kapcsolati sztring konfigurációs fájlokból való tárolásáról és lekéréséről további információt a Kapcsolati sztringek című témakörben talál.

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

Fontos

A Microsoft azt javasolja, hogy a legbiztonságosabb hitelesítési folyamatot használja. Ha azure SQL-hez csatlakozik, az Azure-erőforrások felügyelt identitásai az ajánlott hitelesítési módszer.

KeyRestrictions szintaxis

Az alábbi példa ugyanazt a kapcsolati sztring teszi lehetővé, engedélyezi a kapcsolati sztring Packet Size és a Encrypt beállítások használatát, de korlátozza az egyéb kapcsolati sztring lehetőségek használatát.

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

Fontos

A Microsoft azt javasolja, hogy a legbiztonságosabb hitelesítési folyamatot használja. Ha azure SQL-hez csatlakozik, az Azure-erőforrások felügyelt identitásai az ajánlott hitelesítési módszer.

KeyRestrictionBehavior preventUsage szintaxissal

Az alábbi példa ugyanazt a kapcsolati sztring teszi lehetővé, és minden más kapcsolati paramétert engedélyez, kivéve a , Passwordés Persist Security Infoa User Id.

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

Fontos

A Microsoft azt javasolja, hogy a legbiztonságosabb hitelesítési folyamatot használja. Ha azure SQL-hez csatlakozik, az Azure-erőforrások felügyelt identitásai az ajánlott hitelesítési módszer.

KeyRestrictionBehavior AllowOnly szintaxissal

Az alábbi példa két olyan kapcsolati sztring tesz lehetővé, amelyek szintén tartalmaznak Initial Catalog, Connection Timeout, Encryptés Packet Size paramétereket. Minden más kapcsolati sztring paraméter korlátozva van.

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

Fontos

A Microsoft azt javasolja, hogy a legbiztonságosabb hitelesítési folyamatot használja. Ha azure SQL-hez csatlakozik, az Azure-erőforrások felügyelt identitásai az ajánlott hitelesítési módszer.

Részleges megbízhatóság engedélyezése egyéni engedélykészlettel

Egy adott zónához tartozó engedélyek használatának System.Data.SqlClient engedélyezéséhez a rendszergazdának létre kell hoznia egy egyéni engedélykészletet, és meg kell adnia egy adott zóna engedélykészleteként. Az alapértelmezett engedélykészletek(például LocalIntranet) nem módosíthatók. Ha például olyan kód engedélyeit szeretné belefoglalniSystem.Data.SqlClient, amelyhez LocalIntranetZone tartozik, a rendszergazda átmásolhatja az engedélykészletet LocalIntraneta "CustomLocalIntranet" névre, hozzáadhatja az System.Data.SqlClient engedélyeket, importálhatja a CustomLocalIntranet engedélykészletet a Caspol.exe (Code Access biztonsági házirend eszköz) használatával, és beállíthatja a CustomLocalIntranet engedélykészletétLocalIntranet_Zone.

Minta engedélykészlet

Az alábbiakban egy, az SQL Server .NET-keretrendszer-adatszolgáltatójának engedélykészletét vettünk fel egy részben megbízható forgatókönyvben. További információ az egyéni engedélykészletek létrehozásáról: Engedélykészletek konfigurálása Caspol.exe használatával.

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

Fontos

A Microsoft azt javasolja, hogy a legbiztonságosabb hitelesítési folyamatot használja. Ha azure SQL-hez csatlakozik, az Azure-erőforrások felügyelt identitásai az ajánlott hitelesítési módszer.

ADO.NET kódhozzáférés ellenőrzése biztonsági engedélyekkel

Részleges megbízhatósági forgatókönyvek esetén cas-jogosultságokat igényelhet a kód bizonyos metódusaihoz egy SqlClientPermissionAttribute. Ha a korlátozott biztonsági szabályzat nem engedélyezi ezt a jogosultságot, a kód futtatása előtt kivétel lép érvénybe. A biztonsági szabályzattal kapcsolatos további információkért tekintse meg a biztonsági házirendek kezelésével és a biztonsági házirenddel kapcsolatos ajánlott eljárásokat.

Példa

Az alábbi példa bemutatja, hogyan írhat olyan kódot, amely egy adott kapcsolati sztring igényel. Szimulálja a korlátlan engedélyek System.Data.SqlClientmegtagadását, amelyekhez a rendszergazda cas-szabályzatot implementálna a valós világban.

Fontos

Ha CAS-engedélyeket tervez ADO.NET, a helyes minta az, hogy a legszigorúbb esettel (egyáltalán nem rendelkezik engedélyekkel), majd adja hozzá a kód által végrehajtandó adott tevékenységhez szükséges engedélyeket. Az ellenkező minta, kezdve az összes engedélytől, majd egy adott engedély megtagadásával, nem biztonságos, mert sokféleképpen fejezheti ki ugyanazt a kapcsolati sztring. Ha például az összes engedéllyel kezd, majd megkísérli megtagadni a kapcsolati sztring "server=someserver" használatát, a "server=someserver.mycompany.com" sztring továbbra is engedélyezve lesz. Ha mindig úgy kezdi, hogy egyáltalán nem ad meg engedélyeket, csökkenti annak az esélyét, hogy lyukak vannak az engedélykészletben.

Az alábbi kód bemutatja, hogyan SqlClient hajtja végre a biztonsági igényeket, ami azt jelzi SecurityException , hogy a megfelelő CAS-engedélyek nincsenek-e érvényben. A SecurityException kimenet megjelenik a konzolablakban.

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

Ezt a kimenetet a Konzol ablakban kell látnia:

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.

Fontos

A Microsoft azt javasolja, hogy a legbiztonságosabb hitelesítési folyamatot használja. Ha azure SQL-hez csatlakozik, az Azure-erőforrások felügyelt identitásai az ajánlott hitelesítési módszer.

Együttműködés nem felügyelt kóddal

A CLR-en kívül futó kódot nem felügyelt kódnak nevezzük. Ezért a nem felügyelt kódra nem alkalmazhatók biztonsági mechanizmusok, például a CAS. A COM-összetevők, az ActiveX-felületek és a Windows API-függvények nem felügyelt kódra mutatnak példákat. A nem felügyelt kód végrehajtásakor különleges biztonsági szempontok vonatkoznak, hogy ne veszélyeztesse az alkalmazás általános biztonságát. További információ: Interoperating with Unmanaged Code.

.NET-keretrendszer támogatja a meglévő COM-összetevők visszamenőleges kompatibilitását is a COM-interopon keresztüli hozzáférés biztosításával. COM-összetevőket beépíthet egy .NET-keretrendszer alkalmazásba a COM interop eszközökkel a megfelelő COM-típusok importálásához. Az importálás után a COM-típusok használatra készek. A COM-interop lehetővé teszi a COM-ügyfelek számára a felügyelt kód elérését úgy is, hogy exportálják a szerelvény metaadatait egy típustárba, és regisztrálják a felügyelt összetevőt COM-összetevőként. További információ: Advanced COM Interoperability.

Lásd még