Gegevenstoegang beveiligen
Als u beveiligde ADO.NET code wilt schrijven, moet u de beveiligingsmechanismen begrijpen die beschikbaar zijn in het onderliggende gegevensarchief of de onderliggende database. U moet ook rekening houden met de gevolgen voor de beveiliging van andere functies of onderdelen die uw toepassing mogelijk bevat.
Verificatie, autorisatie en machtigingen
Wanneer u verbinding maakt met Microsoft SQL Server, kunt u Windows-verificatie gebruiken, ook wel geïntegreerde beveiliging genoemd, die gebruikmaakt van de identiteit van de huidige actieve Windows-gebruiker in plaats van een gebruikers-id en wachtwoord door te geven. Het gebruik van Windows-verificatie wordt aanbevolen voor on-premises databases omdat gebruikersreferenties niet worden weergegeven in de verbindingsreeks. Als u Windows-verificatie niet kunt gebruiken om verbinding te maken met SQL Server, kunt u overwegen om tijdens runtime verbindingsreeks s te maken met behulp van de SqlConnectionStringBuilder.
Belangrijk
Microsoft raadt u aan de veiligste verificatiestroom te gebruiken die beschikbaar is. Als u verbinding maakt met Azure SQL, is Managed Identities voor Azure-resources de aanbevolen verificatiemethode.
De referenties die worden gebruikt voor verificatie, moeten anders worden verwerkt op basis van het type toepassing. In een Windows Forms-toepassing kan de gebruiker bijvoorbeeld worden gevraagd om verificatiegegevens op te geven of de Windows-referenties van de gebruiker kunnen worden gebruikt. Een webtoepassing heeft echter vaak toegang tot gegevens met behulp van referenties die zijn opgegeven door de toepassing zelf in plaats van door de gebruiker.
Zodra gebruikers zijn geverifieerd, is het bereik van hun acties afhankelijk van de machtigingen die aan hen zijn verleend. Volg altijd het principe van minimale bevoegdheden en ververleent alleen machtigingen die absoluut noodzakelijk zijn.
Zie de volgende informatie bronnen voor meer informatie:
| Bron | Beschrijving |
|---|---|
| Verbindingsgegevens beveiligen | Beschrijft aanbevolen beveiligingsprocedures en -technieken voor het beveiligen van verbindingsgegevens, zoals het gebruik van beveiligde configuratie om verbindingsreeks s te versleutelen. |
| Opbouwfuncties voor verbindingsreeksen | Hierin wordt beschreven hoe u verbindingsreeks s bouwt op basis van gebruikersinvoer tijdens runtime. |
| Beveiliging voor SQL Server Database Engine en Azure SQL Database | Bevat koppelingen om informatie over beveiliging en beveiliging te vinden in de SQL Server Database Engine en Azure SQL Database. |
Geparameteriseerde opdrachten en SQL-injectie
Met behulp van geparameteriseerde opdrachten kunt u bescherming bieden tegen SQL-injectieaanvallen, waarbij een aanvaller een opdracht in een SQL-instructie injecteert die de beveiliging op de server in gevaar brengt. Geparameteriseerde opdrachten beschermen tegen een SQL-injectieaanval door ervoor te zorgen dat waarden die zijn ontvangen van een externe bron alleen worden doorgegeven als waarden en niet als onderdeel van de Transact-SQL-instructie. Als gevolg hiervan worden Transact-SQL-opdrachten die zijn ingevoegd in een waarde, niet uitgevoerd in de gegevensbron. In plaats daarvan worden ze alleen geëvalueerd als een parameterwaarde. Naast de beveiligingsvoordelen bieden geparameteriseerde opdrachten een handige methode voor het ordenen van waarden die zijn doorgegeven met een Transact-SQL-instructie of aan een opgeslagen procedure.
Zie de volgende bronnen voor meer informatie over het gebruik van geparameteriseerde opdrachten.
| Bron | Beschrijving |
|---|---|
| DataAdapter-parameters | Beschrijft hoe u parameters gebruikt met een DataAdapter. |
| Gegevens wijzigen met opgeslagen procedures | Hierin wordt beschreven hoe u parameters opgeeft en een retourwaarde ophaalt. |
| Opgeslagen procedures (database-engine) | Beschrijft de voordelen van het gebruik van opgeslagen procedures en de verschillende typen opgeslagen procedures. |
Testaanvallen
Aanvallers gebruiken vaak gegevens van een uitzondering, zoals de naam van uw server, database of tabel, om een aanval op uw systeem te koppelen. Omdat uitzonderingen specifieke informatie over uw toepassing of gegevensbron kunnen bevatten, kunt u helpen uw toepassing en gegevensbron beter te beveiligen door alleen essentiële informatie beschikbaar te maken voor de client.
Zie de volgende informatie bronnen voor meer informatie:
| Bron | Beschrijving |
|---|---|
| Uitzonderingen verwerken en genereren in .NET | Hierin worden de basisvormen beschreven van de verwerking van try/catch/final gestructureerde uitzonderingen. |
| Aanbevolen procedures voor uitzonderingen | Beschrijft best practices voor het afhandelen van uitzonderingen. |
Microsoft Access- en Excel-gegevensbronnen beveiligen
Microsoft Access en Microsoft Excel kunnen fungeren als een gegevensarchief voor een ADO.NET toepassing wanneer beveiligingsvereisten minimaal of niet bestaan. Hun beveiligingsfuncties zijn effectief voor afschrikking, maar moeten niet worden vertrouwd om meer te doen dan het ontmoedigen van het bemoeien van niet-geïnformeerde gebruikers. De fysieke gegevensbestanden voor Access en Excel bevinden zich in het bestandssysteem en moeten toegankelijk zijn voor alle gebruikers. Dit maakt ze kwetsbaar voor aanvallen die kunnen leiden tot diefstal of gegevensverlies, omdat de bestanden eenvoudig kunnen worden gekopieerd of gewijzigd. Wanneer robuuste beveiliging is vereist, gebruikt u SQL Server of een andere serverdatabase waarin de fysieke gegevensbestanden niet kunnen worden gelezen vanuit het bestandssysteem.
Enterprise Services
COM+ bevat een eigen beveiligingsmodel dat afhankelijk is van Windows-accounts en imitatie van processen/threads. De System.EnterpriseServices naamruimte biedt wrappers waarmee .NET-toepassingen beheerde code kunnen integreren met COM+-beveiligingsservices via de ServicedComponent klasse.
Samenwerken met niet-beheerde code
.NET Framework biedt interactie met niet-beheerde code, waaronder COM-onderdelen, COM+-services, bibliotheken van externe typen en veel besturingssysteemservices. Als u met niet-beheerde code werkt, gaat u buiten de beveiligingsperimeter voor beheerde code. Zowel uw code als elke code die deze aanroept, moet een niet-beheerde codemachtiging hebben (SecurityPermission met de UnmanagedCode opgegeven vlag). Onbeheerde code kan onbedoelde beveiligingsproblemen in uw toepassing veroorzaken. Daarom moet u voorkomen dat u werkt met onbeheerde code, tenzij dit absoluut noodzakelijk is.
Zie Interoperating with Unmanaged Code (Interoperating with Unmanaged Code) voor meer informatie.