Beveiligingsoverzicht
Het beveiligen van een toepassing is een doorlopend proces. Er is nooit een punt waar een ontwikkelaar kan garanderen dat een toepassing veilig is tegen alle aanvallen, omdat het onmogelijk is om te voorspellen welke soorten toekomstige aanvallen nieuwe technologieën zullen opleveren. Omgekeerd betekent niet dat niemand nog beveiligingsfouten heeft ontdekt (of gepubliceerd) in een systeem, dat er geen bestaat of zou kunnen bestaan. U moet de beveiliging plannen tijdens de ontwerpfase van het project en plannen hoe de beveiliging gedurende de levensduur van de toepassing wordt gehandhaafd.
Ontwerpen voor beveiliging
Een van de grootste problemen bij het ontwikkelen van beveiligde toepassingen is dat beveiliging vaak een nadenk is, iets dat moet worden geïmplementeerd nadat een project code-complete is. Het niet bouwen van beveiliging in een toepassing aan het begin leidt tot onveilige toepassingen, omdat er weinig wordt nagedacht over wat een toepassing veilig maakt.
De implementatie van de beveiliging op het laatste moment leidt tot meer bugs, omdat software onder de nieuwe beperkingen wordt onderbroken of opnieuw moet worden geschreven om onverwachte functionaliteit mogelijk te maken. Elke regel herziene code bevat de mogelijkheid om een nieuwe bug te introduceren. Daarom moet u vroeg in het ontwikkelingsproces rekening houden met beveiliging, zodat deze kan worden voortgezet in combinatie met de ontwikkeling van nieuwe functies.
Threat Modeling
U kunt een systeem niet beschermen tegen aanvallen, tenzij u alle mogelijke aanvallen begrijpt waarop het wordt blootgesteld. Het proces van het evalueren van beveiligingsrisico's, bedreigingsmodellering genoemd, is nodig om de waarschijnlijkheid en gevolgen van beveiligingsschendingen in uw ADO.NET toepassing te bepalen.
Bedreigingsmodellering bestaat uit drie stappen op hoog niveau: inzicht krijgen in de weergave van de kwaadwillende persoon, het karakteriseren van de beveiliging van het systeem en het bepalen van bedreigingen.
Threat modeling is een iteratieve benadering voor het beoordelen van beveiligingsproblemen in uw toepassing om te zoeken naar beveiligingsproblemen die het gevaarlijkst zijn omdat ze de meest gevoelige gegevens blootstellen. Zodra u de beveiligingsproblemen hebt geïdentificeerd, rangschikt u deze in volgorde van ernst en maakt u een set met prioriteit tegen de bedreigingen.
Voor meer informatie raadpleegt u de volgende bronnen:
Bron | Beschrijving |
---|---|
De threat modeling-site op de Security Engineering-portal | De resources op deze pagina helpen u inzicht te krijgen in het threat modeling-proces en het bouwen van bedreigingsmodellen die u kunt gebruiken om uw eigen toepassingen te beveiligen |
Het principe van minimale bevoegdheden
Wanneer u uw toepassing ontwerpt, bouwt en implementeert, moet u ervan uitgaan dat uw toepassing wordt aangevallen. Deze aanvallen zijn vaak afkomstig van schadelijke code die wordt uitgevoerd met de machtigingen van de gebruiker die de code uitvoert. Anderen kunnen afkomstig zijn van goedbedoelde code die door een aanvaller is misbruikt. Bij het plannen van de beveiliging wordt altijd uitgegaan van het slechtste scenario.
Een tegenmaatregel die u kunt gebruiken, is om zoveel mogelijk muren rond uw code te plaatsen door met minimale bevoegdheden uit te voeren. Het principe van minimale bevoegdheden geeft aan dat een bepaalde bevoegdheid moet worden verleend aan de minste hoeveelheid code die nodig is voor de kortste duur van de tijd die nodig is om de taak uit te voeren.
De aanbevolen procedure voor het maken van beveiligde toepassingen is om te beginnen met helemaal geen machtigingen en vervolgens de smalste machtigingen toe te voegen voor de specifieke taak die wordt uitgevoerd. Als u echter begint met alle machtigingen en vervolgens afzonderlijke machtigingen weigert, leidt dit tot onveilige toepassingen die moeilijk te testen en te onderhouden zijn, omdat er mogelijk beveiligingsgaten bestaan door onbedoeld meer machtigingen te verlenen dan vereist.
Zie de volgende bronnen voor meer informatie over het beveiligen van uw toepassingen:
Bron | Beschrijving |
---|---|
Toepassingen beveiligen | Bevat koppelingen naar algemene beveiligingsonderwerpen. Bevat ook koppelingen naar onderwerpen voor het beveiligen van gedistribueerde toepassingen, webtoepassingen, mobiele toepassingen en bureaubladtoepassingen. |
Code Access Security (CAS)
Code Access Security (CAS) is een mechanisme waarmee de toegang die code heeft tot beveiligde resources en bewerkingen beperkt. In .NET Framework voert CAS de volgende functies uit:
Hiermee definieert u machtigingen en machtigingensets die het recht vertegenwoordigen om toegang te krijgen tot verschillende systeembronnen.
Hiermee kunnen beheerders beveiligingsbeleid configureren door sets machtigingen te koppelen aan codegroepen (codegroepen).
Hiermee kunt u code inschakelen om de machtigingen aan te vragen die nodig zijn om uit te voeren, evenals de machtigingen die nuttig zijn om te hebben, en geeft u op welke machtigingen de code nooit mag hebben.
Verleent machtigingen aan elke assembly die wordt geladen, op basis van de machtigingen die zijn aangevraagd door de code en op de bewerkingen die zijn toegestaan door beveiligingsbeleid.
Hiermee kan code worden gevraagd dat de aanroepers specifieke machtigingen hebben.
Stelt code in staat om te eisen dat de bellers beschikken over een digitale handtekening, zodat alleen bellers van een bepaalde organisatie of site de beveiligde code kunnen aanroepen.
Dwingt beperkingen af voor code tijdens runtime door de verleende machtigingen van elke aanroeper op de aanroepstack te vergelijken met de machtigingen die bellers moeten hebben.
Als u de hoeveelheid schade wilt minimaliseren die kan optreden als een aanval slaagt, kiest u een beveiligingscontext voor uw code die alleen toegang verleent tot de resources die nodig zijn om het werk uit te voeren en niet meer.
Voor meer informatie raadpleegt u de volgende bronnen:
Bron | Beschrijving |
---|---|
Beveiliging van codetoegang en ADO.NET | Beschrijft de interacties tussen beveiliging van codetoegang, beveiliging op basis van rollen en gedeeltelijk vertrouwde omgevingen vanuit het perspectief van een ADO.NET toepassing. |
Beveiliging van codetoegang | Bevat koppelingen naar aanvullende onderwerpen waarin CAS in .NET Framework wordt beschreven. |
Databasebeveiliging
Het principe van minimale bevoegdheden is ook van toepassing op uw gegevensbron. Enkele algemene richtlijnen voor databasebeveiliging zijn:
Maak accounts met de laagst mogelijke bevoegdheden.
Sta gebruikers geen toegang tot beheerdersaccounts toe om alleen code te laten werken.
Retourneer geen foutberichten aan de serverzijde naar clienttoepassingen.
Valideer alle invoer op zowel de client als de server.
Gebruik geparameteriseerde opdrachten en vermijd dynamische SQL-instructies.
Schakel beveiligingscontrole en logboekregistratie in voor de database die u gebruikt, zodat u wordt gewaarschuwd voor beveiligingsschendingen.
Voor meer informatie raadpleegt u de volgende bronnen:
Bron | Beschrijving |
---|---|
SQL Server-beveiliging | Biedt een overzicht van SQL Server-beveiliging met toepassingsscenario's die richtlijnen bieden voor het maken van beveiligde ADO.NET toepassingen die gericht zijn op SQL Server. |
Aanbevelingen voor strategieën voor gegevenstoegang | Biedt aanbevelingen voor het openen van gegevens en het uitvoeren van databasebewerkingen. |
Beveiligingsbeleid en Beheer istratie
Het onjuist beheren van cas-beleid (Code Access Security) kan mogelijk zwakke plekken in de beveiliging creëren. Zodra een toepassing is geïmplementeerd, moeten technieken voor het bewaken van de beveiliging worden gebruikt en moeten risico's worden geëvalueerd wanneer er nieuwe bedreigingen ontstaan.
Voor meer informatie raadpleegt u de volgende bronnen:
Bron | Beschrijving |
---|---|
Beveiligingsbeleidsbeheer | Biedt informatie over het maken en beheren van beveiligingsbeleid. |
Aanbevolen procedures voor beveiligingsbeleid | Bevat koppelingen waarin wordt beschreven hoe u beveiligingsbeleid beheert. |