Sdílet prostřednictvím

Zabezpečení přístupu kódu a ADO.NET

Rozhraní .NET Framework nabízí zabezpečení na základě role i zabezpečení přístupu kódu (CAS), které jsou implementované pomocí společné infrastruktury poskytované modulem CLR (Common Language Runtime). Ve světě nespravovaného kódu se většina aplikací spouští s oprávněními uživatele nebo hlavního subjektu. V důsledku toho můžou být počítačové systémy poškozené a privátní data ohrožena, když uživatel spustí škodlivý nebo chybový software se zvýšenými oprávněními.

Naproti tomu spravovaný kód spuštěný v rozhraní .NET Framework zahrnuje zabezpečení přístupu kódu, které platí pro samotný kód. Zda je kód povoleno spustit, závisí na jeho původu nebo jiných aspektech identity kódu, nikoli výhradně na identitě uživatele. Tím se snižuje pravděpodobnost, že spravovaný kód může být zneužitý.

Poznámka:

Zabezpečení přístupu kódu (CAS) je zastaralé ve všech verzích rozhraní .NET Framework a .NET. Nedávné verze rozhraní .NET neuznávají poznámky CAS a způsobují chyby, pokud se používají rozhraní API související s CAS. Vývojáři by měli hledat alternativní způsoby provádění úloh zabezpečení.

Přístupová oprávnění kódu

Při spuštění kódu prezentuje důkazy, které systém zabezpečení CLR vyhodnocuje. Tento důkaz se obvykle skládá z původu kódu, včetně adresy URL, webu a zóny a digitálních podpisů, které zajišťují identitu sestavení.

CLR umožňuje kódu provádět pouze ty operace, které má kód oprávnění provádět. Kód může požádat o oprávnění a tyto požadavky jsou dodrženy na základě zásad zabezpečení nastavených správcem.

Poznámka:

Kód spuštěný v CLR nemůže udělit oprávnění sama sobě. Například kód může požadovat a udělit méně oprávnění, než umožňuje zásada zabezpečení, ale nikdy nebude udělena více oprávnění. Při udělování oprávnění začněte bez oprávnění a pak přidejte nejužší oprávnění pro konkrétní úlohu, která se provádí. Začít se všemi oprávněními a poté jednotlivá zamítat vede k nezabezpečeným aplikacím, které mohou obsahovat neúmyslné bezpečnostní díry kvůli udělení více oprávnění, než je potřeba. Další informace najdete v tématu Konfigurace zásad zabezpečení a správy zásad zabezpečení.

Existují tři typy přístupových oprávnění kódu:

  • Code access permissions odvodit z CodeAccessPermission třídy. Oprávnění se vyžadují pro přístup k chráněným prostředkům, jako jsou soubory a proměnné prostředí, a k provádění chráněných operací, jako je přístup k nespravovanému kódu.
  • Identity permissions představuje charakteristiky, které identifikují sestavení. Oprávnění jsou udělena sestavení na základě důkazních materiálů, které mohou zahrnovat položky, jako je digitální podpis nebo původ kódu. Oprávnění identit jsou také odvozena ze základní třídy CodeAccessPermission.
  • Role-based security permissions jsou založeny na tom, zda má hlavní subjekt zadanou identitu nebo je členem zadané role. Třída PrincipalPermission umožňuje deklarativní i imperativní kontroly oprávnění vůči aktivnímu principálu.

Pokud chcete zjistit, jestli je kód autorizovaný pro přístup k prostředku nebo k provedení operace, systém zabezpečení modulu runtime prochází zásobník volání a porovnává udělená oprávnění každého volajícího s oprávněním, které požadujete. Pokud některý volající v zásobníku volání nemá požadované oprávnění, je vyvoláno SecurityException a přístup se odmítne.

Požádat o oprávnění

Účelem vyžádání oprávnění je informovat modul runtime, která vaše aplikace potřebuje ke spuštění, a zajistit, aby přijímala pouze oprávnění, která skutečně potřebuje. Například pokud vaše aplikace potřebuje zapisovat data na místní disk, vyžaduje FileIOPermission. Pokud toto oprávnění nebylo uděleno, aplikace se nezdaří při pokusu o zápis na disk. Pokud však aplikace požaduje FileIOPermission a toto oprávnění nebylo uděleno, aplikace na začátku vygeneruje výjimku a nenačte se.

Ve scénáři, kdy aplikace potřebuje jen číst data z disku, můžete požádat, aby nikdy nebyla udělena žádná oprávnění k zápisu. V případě chyby nebo škodlivého útoku nemůže kód poškodit data, na kterých pracuje. Další informace najdete v tématu Žádosti o oprávnění.

Zabezpečení na základě rolí a CAS

Implementace zabezpečení na základě role i zabezpečení s přístupem ke kódu (CAS) vylepšuje celkové zabezpečení vaší aplikace. Zabezpečení na základě role může být založeno na účtu systému Windows nebo vlastní identitě a zpřístupnění informací o objektu zabezpečení pro aktuální vlákno. Kromě toho se aplikace často vyžadují k poskytování přístupu k datům nebo prostředkům na základě přihlašovacích údajů zadaných uživatelem. Tyto aplikace obvykle kontrolují roli uživatele a poskytují přístup k prostředkům na základě těchto rolí.

Zabezpečení na základě role umožňuje komponentě identifikovat aktuální uživatele a jejich přidružené role za běhu. Tyto informace se pak mapují pomocí zásad CAS k určení sady oprávnění udělených za běhu. U zadané domény aplikace může hostitel změnit výchozí zásady zabezpečení založené na rolích a nastavit výchozí objekt zabezpečení, který představuje uživatele a role přidružené k danému uživateli.

CLR používá oprávnění k implementaci svého mechanismu pro vynucování omezení pro spravovaný kód. Oprávnění zabezpečení založená na rolích poskytují mechanismus pro zjišťování, jestli má uživatel (nebo agent jménem uživatele) konkrétní identitu nebo je členem zadané role. Další informace naleznete v Oprávnění zabezpečení.

V závislosti na typu aplikace, kterou vytváříte, byste také měli zvážit implementaci oprávnění na základě rolí v databázi. Další informace o zabezpečení na základě role v SQL Serveru naleznete v tématu Zabezpečení SYSTÉMU SQL Server.

Sestavení

Sestavení tvoří základní jednotku nasazení, správy verzí, znovupoužití, určení rozsahu aktivace a bezpečnostních oprávnění pro aplikaci .NET Framework. Sestavení poskytuje kolekci typů a prostředků, které jsou vytvořeny tak, aby spolupracovaly a vytvořily logickou jednotku funkcí. Pro CLR neexistuje typ mimo kontext sestavení. Další informace o vytváření a nasazování sestavení naleznete v tématu Programování se sestaveními.

Sestavení se silným názvem

Silný název nebo digitální podpis se skládá z identity sestavení, která zahrnuje jeho jednoduchý textový název, číslo verze, informace o jazykové verzi (pokud jsou k dispozici), veřejného klíče a digitálního podpisu. Digitální podpis se generuje ze souboru sestavení pomocí odpovídajícího privátního klíče. Soubor sestavení obsahuje manifest sestavení, který obsahuje názvy a hodnoty hash všech souborů, které tvoří sestavení.

Silné pojmenování sestavení dává aplikaci nebo komponentě jedinečnou identitu, kterou může jiný software použít k explicitnímu odkazu na ni. Silné pojmenování chrání sestavení před podvržením škodlivými sestaveními obsahujícími nepřátelský kód. Silné pojmenování také zajišťuje konzistenci správy verzí mezi různými verzemi komponenty. Musíte sestavení opatřit silným názvem, pokud budou nasazena do globální mezipaměti pro sestavení (GAC). Další informace naleznete v tématu Vytváření a používání sestavení se silným názvem.

Částečná důvěra v ADO.NET 2.0

V ADO.NET 2.0 může rozhraní .NET Framework Zprostředkovatel dat pro SQL Server, rozhraní .NET Framework Zprostředkovatel dat pro OLE DB, rozhraní .NET Framework Zprostředkovatel dat pro ROZHRANÍ ODBC a rozhraní .NET Framework Zprostředkovatel dat pro Oracle nyní běžet v částečně důvěryhodných prostředích. V předchozích verzích rozhraní .NET Framework byla podporována pouze System.Data.SqlClient v méně než plně důvěryhodných aplikacích.

Minimálně částečně důvěryhodná aplikace používající poskytovatele SQL Serveru musí mít spouštěcí a SqlClientPermission oprávnění.

Vlastnosti atributu oprávnění pro částečnou důvěru

Pro scénáře částečné důvěryhodnosti můžete pomocí členů SqlClientPermissionAttribute dále omezit možnosti, které jsou k dispozici pro zprostředkovatele dat .NET Framework pro SQL Server.

Následující tabulka uvádí dostupné SqlClientPermissionAttribute vlastnosti a jejich popisy:

Vlastnost atributu oprávnění Popis
Action Získá nebo nastaví akci zabezpečení. Zděděno z SecurityAttribute.
AllowBlankPassword Povolí nebo zakáže použití prázdného hesla v připojovacím řetězci. Platné hodnoty jsou true (pro povolení použití prázdných hesel) a false (zakázání použití prázdných hesel). Zděděno z DBDataPermissionAttribute.
ConnectionString Identifikuje povolený připojovací řetězec. Je možné identifikovat více připojovacích řetězců. Poznámka: Do připojovací řetězec nezahrnujte ID uživatele ani heslo. V této verzi nemůžete změnit omezení řetězce připojení pomocí nástroje pro konfiguraci rozhraní .NET Frameworku.

Zděděno z DBDataPermissionAttribute.
KeyRestrictions Identifikuje parametry připojovacího řetězce, které jsou povolené nebo nepovolené. Parametry připojovacího řetězce jsou identifikovány ve formě <název parametru>=. Lze zadat více parametrů oddělených středníkem (;). Poznámka: Pokud nezadáte KeyRestrictions, ale nastavíte KeyRestrictionBehavior vlastnost na AllowOnly nebo PreventUsage, nejsou povoleny žádné další připojovací řetězec parametry. Zděděno z DBDataPermissionAttribute.
KeyRestrictionBehavior Identifikuje parametry připojovací řetězec jako jediné povolené další parametry (AllowOnly) nebo identifikuje další parametry, které nejsou povoleny (PreventUsage). AllowOnly je výchozí možnost. Zděděno z DBDataPermissionAttribute.
TypeID Získá jedinečný identifikátor pro tento atribut při implementaci v odvozené třídě. Zděděno z Attribute.
Unrestricted Určuje, jestli je deklarováno neomezené oprávnění k prostředku. Zděděno z SecurityAttribute.

Syntaxe připojovacího řetězce

Následující příklad ukazuje, jak použít connectionStrings prvek konfiguračního souboru, aby bylo možné použít pouze konkrétní připojovací řetězec. Další informace o ukládání a načítání připojovací řetězec z konfiguračních souborů najdete v tématu Připojovací řetězce.

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

Důležité

Microsoft doporučuje používat nejbezpečnější dostupný tok ověřování. Pokud se připojujete k Azure SQL, Spravované identity pro prostředky Azure jsou doporučenou metodou ověřování.

Syntaxe omezení klíčů

Následující příklad povolí stejný připojovací řetězec, povolí použití možností připojovacího řetězce Encrypt a Packet Size, ale omezuje použití jakýchkoli jiných možností připojovacího řetězce.

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

Důležité

Microsoft doporučuje používat nejbezpečnější dostupný tok ověřování. Pokud se připojujete k Azure SQL, Spravované identity pro prostředky Azure jsou doporučenou metodou ověřování.

KeyRestrictionBehavior s PreventUsage syntax

Následující příklad povoluje stejný připojovací řetězec a umožňuje všechny ostatní parametry připojení s výjimkou User Id, Password a 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>

Důležité

Microsoft doporučuje používat nejbezpečnější dostupný tok ověřování. Pokud se připojujete k Azure SQL, Spravované identity pro prostředky Azure jsou doporučenou metodou ověřování.

KeyRestrictionBehavior s použitím syntaxe AllowOnly

Následující příklad umožňuje dvě připojovací řetězec, které také obsahují Initial Catalog, Connection Timeout, Encrypt, a Packet Size parametry. Všechny ostatní parametry připojovací řetězec jsou omezené.

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

Důležité

Microsoft doporučuje používat nejbezpečnější dostupný tok ověřování. Pokud se připojujete k Azure SQL, Spravované identity pro prostředky Azure jsou doporučenou metodou ověřování.

Povolení částečné důvěryhodnosti pomocí vlastní sady oprávnění

Pokud chcete povolit používání System.Data.SqlClient oprávnění pro konkrétní zónu, musí správce systému vytvořit vlastní sadu oprávnění a nastavit ji jako sadu oprávnění pro konkrétní zónu. Výchozí sady oprávnění, například LocalIntranet, nelze změnit. Pokud chcete například zahrnout System.Data.SqlClient oprávnění pro kód, který má Zone hodnotu LocalIntranet, může správce systému zkopírovat sadu oprávnění pro LocalIntranet, přejmenovat ji na CustomLocalIntranet, přidat System.Data.SqlClient oprávnění, importovat sadu oprávnění CustomLocalIntranet pomocí Caspol.exe (Nástroj zásad zabezpečení přístupu kódu) a nastavit sadu LocalIntranet_Zone oprávnění na CustomLocalIntranet.

Sada ukázkových oprávnění

Následuje ukázková sada oprávnění pro zprostředkovatele dat .NET Framework pro SQL Server v částečně důvěryhodném scénáři. Informace o vytváření vlastních sad oprávnění najdete v tématu Konfigurace sad oprávnění pomocí 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>

Důležité

Microsoft doporučuje používat nejbezpečnější dostupný tok ověřování. Pokud se připojujete k Azure SQL, Spravované identity pro prostředky Azure jsou doporučenou metodou ověřování.

Ověření ADO.NET přístupu kódu pomocí bezpečnostních oprávnění

Pro scénáře částečné důvěryhodnosti můžete vyžadovat oprávnění CAS pro konkrétní metody v kódu zadáním znaku SqlClientPermissionAttribute. Pokud tato oprávnění nejsou povolena zásadami zabezpečení s omezeným přístupem, vyvolá se výjimka před spuštěním kódu. Další informace o bezpečnostní politice naleznete v Správa bezpečnostních zásad a Osvědčené postupy pro bezpečnostní zásady.

Příklad

Následující příklad ukazuje, jak psát kód, který vyžaduje konkrétní připojovací řetězec. Simuluje odepření neomezených oprávnění na System.Data.SqlClient, které by správce systému implementoval pomocí zásad CAS v reálném světě.

Důležité

Při navrhování oprávnění CAS pro ADO.NET je správným vzorem začít s nejvíce omezujícím případem (vůbec žádná oprávnění) a pak přidat konkrétní oprávnění potřebná pro konkrétní úlohu, kterou kód potřebuje provést. Opačný vzor, počínaje všemi oprávněními a zamítnutím konkrétního oprávnění, není zabezpečený, protože existuje mnoho způsobů vyjádření stejného připojovacího řetězce. Pokud například začnete se všemi oprávněními a pokusíte se zakázat použití připojovací řetězec "server=someserver", bude řetězec "server=someserver.mycompany.com" stále povolený. Tím, že vždy začnete tím, že neudělíte žádná oprávnění, snížíte riziko, že v sadě oprávnění jsou díry.

Následující kód ukazuje, jak SqlClient provádí poptávku po zabezpečení, která vyvolá SecurityException , pokud nejsou splněna příslušná oprávnění CAS. Výstup SecurityException se zobrazí v okně konzoly.

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

Tento výstup by se měl zobrazit v okně konzoly:

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.

Důležité

Microsoft doporučuje používat nejbezpečnější dostupný tok ověřování. Pokud se připojujete k Azure SQL, Spravované identity pro prostředky Azure jsou doporučenou metodou ověřování.

Interoperabilita s nespravovaným kódem

Kód, který běží mimo CLR, se nazývá nespravovaný kód. Mechanismy zabezpečení, jako je CAS, se na nespravovaný kód nedají aplikovat. Příklady nespravovaného kódu zahrnují komponenty COM, rozhraní ActiveX a funkce Windows API. Při provádění nespravovaného kódu se vztahují zvláštní aspekty zabezpečení, abyste neohrožovali celkové zabezpečení aplikace. Další informace najdete v tématu Spolupráce s nespravovaným kódem.

Rozhraní .NET Framework také podporuje zpětnou kompatibilitu s existujícími komponentami MODELU COM tím, že poskytuje přístup prostřednictvím zprostředkovatele komunikace modelu COM. Komponenty modelu COM můžete začlenit do aplikace rozhraní .NET Framework pomocí nástrojů zprostředkovatele komunikace modelu COM k importu relevantních typů modelu COM. Po importu jsou typy modelu COM připravené k použití. Propojení COM také umožňuje klientům COM přístup ke spravovanému kódu tím, že exportuje metadata sestavení do knihovny typů a registruje spravovanou komponentu jako komponentu COM. Další informace naleznete v tématu Pokročilá interoperabilita modelu COM.

Viz také

  • Last updated on